Slashdot Mirror
'Retro Programming' Teaches Using 1980s Machines
Death Metal Maniac writes "A few lucky British students are taking a computing class at the National Museum of Computing (TNMOC) at Bletchley Park using 30-year-old or older machines. From the article: '"The computing A-level is about how computers work and if you ask anyone how it works they will not be able to tell you," said Doug Abrams, an ICT teacher from Ousedale School in Newport Pagnell, who was one of the first to use the machines in lessons. For Mr Abrams the old machines have two cardinal virtues; their sluggishness and the direct connection they have with the user. "Modern computers go too fast," said Mr Abrams. "You can see the instructions happening for real with these machines. They need to have that understanding for the A-level."'"
That could teach them a thing or two about commerce and trade, I suppose.
SJW: Someone who has run out of real oppression, and has to fake it.
Makes a lot more sense than starting them off in some poo like Java where they never need to know about the real hardware.
Trolling is a art,
I feel us programmers have gotten too far away from the lower level aspects of the craft and are now too higher level focused. While, this isn't a bad thing (why should you rewrite a framework everytime you start a new application) - it really perverts ones respects for how things work and efficency.
I am getting back into assembly programming after 8 years of C# and it is a bit of a shift in thought. My college switched from C/C++ to Java my senior year for incoming freshman - a real shame. Programming is totally different when you have no respect of memory management.
Uhm, we were saying that in the 1980s. At Bletchley Park they should be teaching with machines that actually are old.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
You would get exactly the same "feel" as you get with an old C=64 or Atari or Amiga machine. If your goal is to get down to the bare metal, then go ahead and do so. There's no need to dust-off old machines that are on the verge of death (from age).
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
... if you want to know how computers work, learn microcontrollers with the Atmel 8 bit family of controllers (ATMEGA8, for example). These things are wonderfully documented, there is a free C/ASM development environment with emulator (single-step, breakpoints, etc.). The real deal is just a few dollars for a development board (or get an Arduino, same thing). You don't get the absolutely down to the transistor insight, but that's really just a few experiments with TTL gate chips and LEDs away.
They each took on the role of a different part of the machine - CPU, accumulator, RAM and program counter - and simulated the passage of instructions through the hardware.
The five shuffled data around, wrote it to memory, carried out computations and inserted them into the right places in the store.
It was a noisy, confusing and funny simulation and, once everyone knew what they were doing, managed to reach a maximum clock speed of about one instruction per minute.
I wish I had a teacher like this while in [US public] school.
More Twoson than Cupertino
Yes, it makes sense. The students get an intimate feel for writing programs without being able to waste resources ramapantly.
You do not have a moral or legal right to do absolutely anything you want.
We ran some older machines in my first programming course. When you can see the direct results in speed (or lack of) it can help teach better approaches. Writing a game and seeing the screen flicker when you ask the CPU to do too much is good modivation to find a more effectient approach. One our our instructors also did something like this with visual sorting procedures. If you can see the difference in speed between one sorting approach and another, it sinks in.
One of the great things about the early micros (and probably the even-earlier minis) is that they were Knowable. With a little time, an intelligent person could become familiar with the workings of the entire architecture. I used to have a map of every memory location in the 64KB of ye olde C64 (most of it was user RAM of course) explaining what each byte was for. POKE a different value to a certain address, and the background color changes. PEEK at a certain address and it tells you the current hour. You could learn this... all of it. Obviously that's just not possible with modern computers (probably not even modern phones); no one person can grok the whole system.
http://alternatives.rzero.com/
Yes, it makes perfect sense for two reasons.
A) It teaches people how to use unfamiliar hardware/software. Chances are the thing you are going to be running at your job is not going to be the thing you studied in university for.
B) It teaches kids how to not make mistakes in coding. Make a big enough mistake and the entire system goes down. Compilers are also a lot less fault tolerant.
C) It teaches kids how computers actually work by pealing back layers of abstraction. Think about it, has the average person under 20 ever used a CLI? For anything? I think the closest people come these days to actually using a CLI is typing in something on the Windows "Run" dialog.
D) It puts things in perspective. It shows how you don't need a Core i7 to play games, that a graphics card with 100 times the memory of the entire computer isn't required to make art, etc.
E) Its fun. The old computers had a lot more easter eggs built in and little tiny quirks. These days you get a Dell/HP/Gateway/Acer/Asus/etc slap Windows/Linux/OS X on it and its the same as any other Windows/Linux/OS X box, but the old computers all had little things different, some things were frustrating of course, but when you don't have to do it for any too serious of work, it can be kinda fun digging out the old Commodore 64.
Taxation is legalized theft, no more, no less.
It's not about "understanding low-level programming" - it's about having a direct connection between what you do and what happens. No virtual machine, no garbage collector, no super-fast compile/link/run/modify cycle (s you're going to take a few minutes to THINK about why something didn't work instead of just doing the "quick fix let's test it and see if we got it right this time" route).
The article never said they were using Windows.
If you want to get an intimate feel for writing programs without being able to waste resources, try embedded systems programming. The microchip 10F series has only a few dozen bytes of ram, and a couple hundred words of flash. And no hardware multiply. Making it do useful things is an art. Oh, and unlike some relic from the 70's, you can actually get a job programming for tiny microcontrollers.
That said, it does seem like a cool class. One I'd like to take, but for personal interest, not professional development.
How will the student then apply his knowledge to modern languages such as Java, C# ?
It's really pretty simple. After seeing what a computer can do with code intimately optimized for the machine it's running on, they will be exposed to the status quo in Java or C# and their heads will explode. Problem solved on our end!
Edlin should be a mandatory part of the course for the full immersive effect.
Or was that the 70's? Gosh I can't remember now cuz I'm so old.
Actaually the BBC PC isn't far from the perfect embedded system trainer.
From the Wilkipedia.
"The machine included a number of extra I/O interfaces: serial and parallel printer ports; an 8-bit general purpose digital I/O port; a port offering four analogue inputs, a light pen input, and switch inputs; and an expansion connector (the "1 MHz bus") that enabled other hardware to be connected. Extra ROMs could be fitted (four on the PCB or sixteen with expansion hardware) and accessed via paged memory. An Econet network interface and a disk drive interface were available as options. All motherboards had space for the electronic components, but Econet was rarely fitted. Additionally, an Acorn proprietary interface called the "Tube" allowed a second processor to be added. Three models of second processor were offered by Acorn, based on the 6502, Z80 and 32016 CPUs. The Tube was later used in third-party add-ons, including a Zilog Z80 board and hard disk drive from Torch that allowed the BBC machine to run CP/M programs."
Four A2Ds 8 bits of GIO, and switch inputs. All available from Basic on a machine with a Floppy, Keyboard, and Monitor. Sweet.
I so wanted one of these back in the day. Too expensive and not really available in the US at the time.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Absolutely. Better teach them C so they will know how data structures and memory management work.
Languages that try to do everything may help you write code faster but can be treacherous.
Let's see a simple example. In Python there is a subtle matter of memory management that can be dangerous to the untrained programmer. When you copy a list like this: a = b you are creating a pointer to the other list, when you copy like this: a = b[:] you are allocating memory for a new list and copying the contents.
When you know C, the difference between the two copy instructions above is obvious, but if you don't know what is memory management this can become very difficult to understand. I bet there are many bugs created by Java, Python, and other modern languages that come from this inability to understand how the language works under the hood.
Working on old computers can be fun for some people, but to train programmers nothing beats learning C. C is close enough to the hardware to let one understand the details of how software runs, yet abstract enough to represent any typical von Neumann computer.
Yes, it makes great sense. WHen getting started, it really helps if you're forced to deal with the low level, and more if you can actually see the low level.
I've spent a large part of my career writing software realted to tape drives. It really helped me getting started that I could sit down in front on an old IBM 9-track reel-to-reel to test my code. Not the most useful thing for production data storage, but terrific for seeing problems with production code. Miss the end-of-tape marker? Flap-flap-flap-flap doh!
Similarly, writing and debugging production assembly code made me very comfortable with debugging and crash analysis on higher-level languages, even if I didn't quite have matching source. And that experience in turn lets me understand "what really happens" with a language like C# or Java, and for example explain to people why, for example, the .NET file rename function is no substitute for the Win32 file rename system call, despite the fact "they both just rename a file". STuff that should be obvious to even a junior programmer but, well, isn't.
Socialism: a lie told by totalitarians and believed by fools.
Amongst our weaponry are such things as...I'll start over.
Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
from the link: "using 30-year-old or older machines."
from the fine article: "First released in 1981; discontinued in 1994 using 30-year-old or older machines."
I recently (three weekends ago) fired up my Commodore PET 2001 (a *genuine* pre-1980 computer) and have been writing a Forth for it. It's really a lot of fun, and I'm finding that 30 years experience in various high-level languages has improved my "6502 assembler golf" game a lot. It's very incomplete, but the inner interpreter mostly works. Feel free to throw down on it here
Charlie
never ask a question you don't want to know the answer to
Seriously, how is this useful in modern computing, other than as a "Back in my day..." quote?
Learning how to use older/simpler machines is an excellent way to learn about a number of fundamental concepts. Modern computing, for all its advances, still operates off the same fundamental principles as it did fifty years ago; it's simply become orders of magnitude more complex.
Now, while it's perfectly possible to learn how to do this sort of thing using emulation or specialized training software, there's real value to having an appreciation of the history of the field you're planning to enter, and working with machines that were once considered state-of-the-art is a very effective way to gain a sense of just how insanely far computing has come. Note, too, that simply because you're never going to be called upon to program a PDP-8 in real life doesn't mean that you can't learn a fair amount of generally-applicable knowledge about hardware, logic, branching, execution, input, output, and instruction sets. In fact, by pulling yourself out of a familiar environment, you're forced to pay attention to important things that you'd otherwise happily ignore--like "well, how does what is in my head actually get into a computer's inner workings?"
Finally, always remember that programming is a subset of computer science. Even if all you ever expect to do is write code, a deeper knowledge of what goes on between the compiler and the electrons is going to be quite useful--and will make you a better coder, to boot.
Obliteracy: Words with explosions
New cars are wonderfully simple under the hood, once you strip away all the plastic. Ever taken apart an old carburetor before? Ever try to get it back together in working order? Give me a FI computer, airflow sensor, and fuel injector any day. Not surprisingly, cars went from a maintenance interval of 1,000 miles with a life expectancy of 50,000 miles to a maintenance interval of 10,000 miles and a life expectancy of 250,000 miles by *avoiding* complexity.
10 years ago when I went through University, the core of the mandatory Assembly programming course was taught on the PDP-11 architecture, then 30 and now 40 years old.
Granted it's not quite the same. We used emulators and not the real things. Also it was for different motivations. The prof felt it was simpler to teach the cleaner PDP-11 instruction set than the 80x86 or 680x0, although the course did eventually also extend to both. Also he happened to be an expert in systems like the PDP-11.
However the idea of using old systems as teaching aids is hardly new - or news IMO.
You don't understand - this is Bletchley Park, you know, the codebreakers during WW2. Old habits die hard. They *could* tell you, but then they'd have to kill you.
I was in AP computer science over a decade ago. We used C++ using the "apstring" and "apvector" classes that were similar to the STL.
We of course had to implement bubble short, quicksort, insertion sort, and so.
It was fairly slow on our computers (386s/486s/maybe one pentium!) and you could REALLY see a visible difference between the difference sorts. It was very obvious.
I rewrote the sorts using standard C arrays instead of apvector. Even on those ancient computers, the differences were suddenly almost gone. Bubblesort using straight arrays was faster than apvector quicksort--at least for fairly small arrays. I don't remember the specifics anymore, but you had to be sorting IIRC several thousand things before there was much of a recognizable difference.
So yeah, that made a big impression on me. Then again that class, and intro classes in college were the last time I've had to write my own sorting algorithm...
I think it's a good thing that people who have maybe only used 2ghz+ computers are given a chance to experience something else. I guess a better question would be, why is expanding your horizons ever a bad thing?
How will the student then apply his knowledge to modern languages such as Java, C# ?
Do you believe that a school should teach Java, or teach programming?
BTW, C++ can kernel-mode C programming jobs aren't going away, and tend to pay better than Java jobs as the talent pool is growing smaller. Especially for kernel-mode programming, very few schools are turning out bright young talent with any relevent skills in that area, so the labor pool is aging out but the demand isn't shrinking.
Socialism: a lie told by totalitarians and believed by fools.
The model-T was even stranger: http://en.wikipedia.org/wiki/Model_T
-- I have a private email server in my basement.
They're A-level students, i.e. the final two years of school, ages 16-17 and 17-18. It's probably more interesting than making some crappy VB application, which is what I remember the A-level computing students doing (I didn't do the subject, I did extra maths instead -- it was much more useful for finding a place on a good CS course at university).
I don't know what the A level syllabus is, but I suspect it is more about learning how computers work in preparation for a university degree than about learning how to program in any particular language. Quite frankly I think they should keep things as fundamental as possible at this stage. Students can always go to community college if they wish to learn how to set up outlook, operate excel or write java etc.
Nullius in verba
And yet, when that routine needs to run three billion times per execution, it completes a few hours faster than a slightly less-efficient algorithm! That's a significant improvement for any company today working with large-scale data. A lesser programmer simply wouldn't be able to do the job.
You do not have a moral or legal right to do absolutely anything you want.
Yes, lots. While I appreciate the old joke that "carburetor is a French word, meaning 'leave it alone'", I never found carburetors to be capricious, only more complex than 'screwdriver mechanics'. You have to know how the carburetor works, and you have to have the correct service manual, and you have to have the tools to assure the precision parts are all in spec.
The only difference with carburetor overhaul was you couldn't fudge a 'close enough' job and escape notice. This made carburetors a dividing line between wrench twiddlers and real mechanics. Most other parts of an older engine could be reassembled 'close enough' and work fine -- for now; they just wouldn't last as long. Carbs assembled that way would tell you immediately, hence got a reputation.
What changed around 1985, the beginning of the 'simpler' and 'lower maintenance' era we're in now, is the complex high-precision bits multiplied and got sealed off. You didn't pull everything apart to the last bolt and wire anymore. You had a series of black box sections that were removed and replaced when out of spec. That's everything as complicated as, or more complicated than, a carburetor.
Apply the same rule of 'remove and replace' to carburetor cars, and they'll be just as 'simple' to work on as you claim new cars are. You'll still be a Barbie saying "math is hard!", but you won't be spouting bullshit about 50,000 mile life expectancies. Seriously, that's just rubbish. Any decently maintained old car that wasn't a known lemon rolled over the odometer easily before you /started/ thinking it was getting time for overhaul.
Oh, and unlike some relic from the 70's, you can actually get a job programming for tiny microcontrollers.
Just last year, I was working for a company (A fairly large one) and they were still running programs written in DEC FORTRAN 77 on Vaxen. A part of my job was to port these programs to an.......Alpha.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano