Give them a text terminal on a very limited timesharing system; running an older OS, and encourage them to make it their only computer usage.

Have them complete assignments on various 8bit micros, and then on 68Ks.

Use Unix.

But, like, Unix Unix. Ed Unix.

Give folks and understanding of the history of computing, the depth and breadth of existing tool chains, and the capabilities and limitations of vintage designs.

And, only after they have that historica perspective, do you toss anything modern at them.

Let people live their life, and write their code, in less than 1MB of RAM on a 12-bit or 16-bit minicomputer before moving on to something powerful enough to encourage bad decisions.

The history of modern computing isn’t very long, it can be learned and lived and in doing so, we’ll get better engineers, with the ability and perspective to write better software.

There are several reasons for this (and about a million reasons against it, but that’s for another day)

1) learning a programming language doesn’t make you an engineer.
2) how can we avoid past mistakes if we never discuss them?
3) how can we write better tools for the next generation of computers if we’ve never used the best tools from the last generation of computers?

4) we’ve been using the same rough architecture for a long time. Eons in the computer word, and we are long overdue for a change, but most modern computer education presents x86-64 as if it is without flaw, and the inevitable path for our future, instead of just one option among many.

5) Abstraction is good. Learning how to solve a specific problem in a specific case is okay. Learning how to solve a class of problems across multiple cases is better.

So, should we force burgeoning computer scientists and engineers to qualify on a pdp -8 and an Altair 8800, and write assembly for an Apple II before we let them get to a Linux box?

No. Probably not. It’d drive a bunch of people away from the industry, and probably not actually help many folks.

But we should totally offer living history classes, and for folks that are serious about low-level development, they should be strongly encouraged.

I’ll give an example of what I would like to see more of:

- teach students roughly how an Atari 2600 works.

- give them a bucket full of off the shelf parts

- give them four weeks to design a game console and make it play a computer game.

Or:

- give students the source code of a modern program

- give students a compiler that will compile that source, and an environment that will run that compiler, but that is resource constrained enough that the code doesn’t run well

- work with students to discover ways to optimize the code so that it’ll run well on the resource constrained hardware

- run it on less resource constrained hardware. Compare benchmarks.

@ajroach42 I feel like there's elements of this idea that are actually good - we need to fight the idea that RAM and CPU are cheap - and some ideas that... do we really need to teach people based on the write/compile/execute cycle involving punch cards and taking two days (one to punch and compile the source deck, the next to execute the object deck)?

Some resource-constrained and historical context education is useful, but some stuff just makes no sense in 2018.

@ajroach42 Where I'd say artificially imposing the old limitations makes the most sense is... teach people to assume their code is running on a microcontroller, and it ships on mask ROM.

You've got limited resources, hard real-time constraints, and you can't fix it if there's a bug. Good luck!

@bhtooefr @ajroach42 Perhaps a useful middle ground is using something like a Raspberry Pi as a dev platform.

It doesn't have to be all circuit-level dev to learn something about constraints, while still offering reasonable platform for editing, compiling and running code.

If you started with an original Model B (can you still get those?), transition to a Pi 3 has a noticeable boost in performance. You could just unplug the card from one, put into the other, and run.

@tool_man @ajroach42 The problem is that a Pi is still really modern levels of abstraction. It lets you avoid learning how things really work, still.

Also, the particular manifestations of jank that the RPi platform offers mean that you could run into plenty of hardware-caused Heisenbugs, not good for a learning tool.