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.
We had to remote into this old Unix System V box and do a few exercises for our course education. No, its not as far back as these students were going but it was helpful to become familiar with that kind of architecture, because you never know whats still going to be kicking around when you get on the job.
I mean, seriously ? I'm pretty sure you don't need to screw your head on a crippling dinosaur to understand low level programming
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
Next up: Driver's Eduction on the Model T. ;)
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.
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
That's what most people would say when you asked them how something works. Computers, fermentation, a Wok . . . etc.
"Um . . . I dunno . . . "
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
"Because there's no copy and paste, if you do something wrong it takes time to go back and fix it," said Joe Gritton. "You cannot take out sections and move them around."
So they have to worry about bad interfaces and editors. You can do simple assembler programming on modern machines as well. And understanding C__ should give you a good deal of knowledge about the basics of a computer...
I wasn't alone in keeping '286, 386, and '486 boxes around until Pentiums became prolific...and the same goes for dual cores etc...you write code that runs fast on the older generations, and you never hear user-land complaints about your stuff's performance on the new.
.NET....well, now you're only as good as Microsoft is.
Of course, with the advent of
Orwell: "In a Time of Universal Deceit, telling the Truth is a Revolutionary Act"
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/
The five soon discovered that just because a program was simple did not mean the underlying code was straight-forward. To make matters more testing, the BBC Micro offers a very unforgiving programming environment.
My first piece of commercial programming was on a BBC Micro and having that environment didn't teach me anything, it just made programming more of a pain than being able to cut and paste, set debug breaks and so forth. And it doesn't teach any more than using C#/VB because it's a machine designed around using BASIC, which is itself an abstraction (and IIRC, you didn't have functions, so had to endure the horror of GOSUB/RETURN).
These systems have high-level I/O options (keyboard, monitor) that embedded systems don't, while avoiding all of the complexity (multi-level caching, speculative execution, out-of-order execution, etc.) of a modern desktop.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
In my college program on electronics design, we actually did a lot of system-level programming on 8085 machines. We went so far as to build DAC converters to build volt meters out of computers. What it gave us was the ability to understand the basics of CPUs interacting with memory, signals, IOs, assembly language. That said, with two years of that under my belt, I am no closer to understanding any real-world programming that can get me a job, than had I not taken the class.
Yes, the basics of computers are much easier when you don't have massive clock frequencies adding insane complications to applications. No, programming has nothing to do with understanding what JMP does. Do I think it's valuable? Sure. Do I think it'll make any difference on whether you can call yourself a "programmer?" No way.
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.
Wouldn't it be better to use the emulation route? For example, writing a program for the original gameboy, and running it through the emulator. I remember at university we learned assembly on an emulated MIPS. We could focus on the individual instructions, on hardware that was simple and clean, but it all ran on the unix servers (x terminals).
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.
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
I have programmed on TRS-80s and 8088 w/8087s. Compiled C and Read & Go BASIC.
But now I'm programming python on an 8-core Xeon. When I'm writing a stored procedure or a nested loop of two recordsets, I ***STILL*** catch myself thinking about how slowly those instructions would take on a slower machine. "Do you know how LONG that looping will take?... oh. 0.000006 seconds. heh heh. I catch myself "subvocalizing" the loops, and I shy away from something "so resource intensive" and look for another, more efficient solution.
Yes, it's great to learn how a computer does what it does, but if you miss the simple solution because your mind is "read and go"-ing, then you hobble yourself.
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
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.
I was using them at college when they were new.
My first job was writing software that controlled scientific instruments and their was an awful lot of eductaional software written for them because they were designed to be used in schools. The Basic was more structuured and it could use microcassettes or 5 1/4 flopies with its own DOS.
In short, if you are going to use a dinosaur, it is the best dinosaur to choose
> These systems have high-level I/O options (keyboard, monitor) that embedded systems don't...
Some embedded systems have serial I/O and support terminals.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I first used edlin on DOS 1.0 and was kept using it until better alternatives (norton edit, anyone?) appeared. Edlin makes vi seem like a walk in the park. I've used edlin for assembly and Pascal programming, and I say "curse you!" to anyone who jokes about those dark days.
Timex Sinclair 1000 w/ 16KB Expansion Module. Manual included. Original boxes & styrofoam.
If this opportunity sounds interesting to you but you grew up with high level languages, definitely check out the book Code by Charles Petzold. I could really only keep up with the first 500 pages or so, but it is still incredibly insightful and interesting if you want to know how a computer really works. You could basically use it to learn how to build a computer from scratch and program it.
Spoon not. Fork, or fork not. There is no spoon.
I had the same kind of learning back in my days using PIC microcontrollers where I needed to do VERY LOW LEVEL programming and I saw "instructions happening for real", flipping a led's state or the like.
I value that experience a lot!
Laugh if you will, but I find that the most effective demonstration of low-level "how computers really work" programming (short of flipping manual switches PDP style) is Brainfuck.
For Mr Abrams the old machines have two cardinal virtues; their sluggishness and the direct connection they have with the user.
Another hacker learning skill you must obtain, that he forgot to mention, is how to completely master a system. This is different from merely learning enough.
At one point, I could tell you every minute detail of OS-9 (the motorola 6809 CPU OS, not the apple product two decades later) and I also nearly mastered 68hc11 assembly, Z-80 assembler, and the PDP-8.
There is no point trying to teach kids how to master something using, perhaps, the linux kernel, because its too freaking big, at least for a one or two semester course.
The mastery skill requires figuring out what you don't know and then figuring out how to find it. Very much like spatial mapping, I see a blank spot in my map of how it all works, so how will I get from where I know to where I don't know? Also you learn how to learn the philosophy of a complete working system, sort of a C/S ecology mindset. Finally there is a bit of reflective thinking that interacts across now usually broadly separated problem areas, look how the memory allocation system has reflected onto the design of the I/O drivers and vice versa.
Learning how to master a topic is a valuable skill, and at least for CS students, frankly best learned on the smaller older stuff. Too many newbies think asking small specific questions of google is all they need, and think they can scale up to a big project merely by asking more little questions, without thinking thru the big picture.
A fourth thing the dude forgot is that older computers were MORE powerful. Power is what comes out of the barrel of a gun, its not P=I*V or MIPS. A single old MVS mainframe could run a small govt department or a multinational corp.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I don't know about retro programming, but my first experience of hard programming is being introduced to Assembly language using a Hektor computer, originally designed for the UK's Open University. http://www.old-computers.com/museum/computer.asp?c=602&st=1
At least using it and it's plug in sensors module helped you understand what all the moving data to / from the stack and all the rest of the commands was actually doing to the hardware.
Maybe modern versions of this kind of simple kit would help people understand programming more when they start out in it?
Take Nobody's Word For It.
When(and where) I did my undergrad in CS, it was mandatory that we took both the basic and advanced Computer Architecture courses and the intro to Logic and Design course. These were the same courses that electrical and computer engineers took. We designed Clock radio circuits, studied K-maps, Boolean logic, gray codes, wrote our own basic RISC chips(instruction set and layout) using Xilinx(with the option to put them onto FPGA's and run them), studied floating point calculations, studied parallel pipelining, did manual loop unrolling, worked with MIPS emulators, studied multiple assembly languages, and not once did I touch out of date hardware.
I just don't see how using such old computers is anything but a gimmick. Unless you're trying to study some rather obscure architecture for which no emulator exists, I just don't see how it adds much to the educational experience over having a properly designed curriculum
I don't care what you say, all I need is my Wumpabet soup.
They need to go back further than that. First the students have to build a generator, then blow their own glass and seal their own vacuum tubes. Near the end of the semester they'll make silicon wafers and cast their own CPUs.
There's no -1 for "I don't get it."
Another factor is the conceptual model is simpler. It is possible to know the entire layout of one of these classic machines. The CPU, instruction set, registers, I/O chips and memory layout. You can exactly where a program will load in memory. A 6502 has an Accumulator, X register, Y register, 6 flags, a stack pointer and a program counter. It is possible to know exactly how the computer works on both a hardware and software level.
Try that with a PC, what happens when you flip the power switch. Well which BIOS, what POST tests, what hardware? What happens up to the point where the boot sector is loaded? What happens after control has been turned over to the boot loader? What about the hardware? There are so many combinations, so many drivers, etc. How do you even go about teaching these things when you can't be sure of what hardware you will have in the classroom?
The classic machines flatten this out. Even in emulation they are very helpful tools for teaching.
vi +
...I did my computing A-Level on these machines. The school had about 20 of them, networked together with Econet and using a 20 megabyte hard disk for storage. Students had an allocation of 100 K (yes, kilobytes), and I don't think I ever filled mine up...
Now get off my lawn!
Just another wannabe fantasy novelist...
History does indeed repeat itself, but it does so in unique ways such as using upgraded technology but relying on the same tried and true methods. I expect in 10-20 years we'll see something akin to punchcards being used to access unique user-stored information, and personalized execution of code. These days we call them flash drives, or pen drives, or USB sticks.
Om, nomnomnom...
It's true, today's computers ARE too fast for students.
Kids today don't know the joy of being able to slack off for 5 to 10 minutes in class while their screen says "Compiling..."
Wow I used an old 8088 and Basic to do my first programming, dreaming of a day at a PDP. WOW I am getting old.
Kosh: "Understanding is a 3 edged sword, your side, their side, the Truth."
Compucolor II Hit the key labeled Auto . CTRL-A did the same thing I think
Apple ][ PR#6
C=64 Load "*",8,1
No, sorry, you are quite wrong. It is nothing to do with avoiding complexity. It is to do with CAD ensuring that every component is properly designed for the duty, advanced FEA ensuring proper thermal management of the engine, and advanced manufacturing and quality systems delivering accurate parts time after time. The complexity is there all right, delivered by the wonders of advanced computing.
You cannot learn engine design from a TSI engine. You can learn an awful lot from a research engine, single cylinder four-and-a-half inch bore Diesel with almost everything adjustable. You can learn very little (in fact) from a chainsaw engine, despite its only having a few moving parts, because again it is an optimised design. This is why learning on an old BBC Micro is more useful than learning embedded programming (I've done both.) The 6502 and all its works is not a modern, optimised 8 bit processor with a lean instruction set. It is clever, but a bit of a kludge. Assembler on a 6502 forces you to think. Crappy memory architecture causes you to think harder.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
This reminds me of a quote I read from Philippe Khan back in the really old days. He used the original IBM PC (4.77 MHz) to test code (Turbo Pascal) when much faster (8 MHz) machines were available. He said he "liked to watch the computer work".
I don't read your sig. Why are you reading mine?
It is a neat idea, but you could get the same kind of benefits from writing assembly for Pentiums or modern micro-controllers. Easier to find equipment and more relevant and interesting.
"I'm not a quack, I'm a mad scientist! There's a difference." - Dr. Cockroach
I believe it's a general pattern in training, to start with a smaller, simpler system that the trainee can more readily comprehend as a whole. It's easier to be a passenger on a big plane, but easier to learn to fly a small plane, as it's a lot easier to keep track of all the details of a small plane.
I noticed a bunch of low (even 4 digit)/. user ids in this thread -- like the guy who got the CP/M box off craigslist. I think it would be quite interesting to do a correlation between low /. user IDs and opinion on the subject. The hypothesis is that older people will have a softer spot for older machines.
Myself? I think learning to program in older machines is a great idea. But then again I learned to program in Sinclair ZX-81's BASIC language -- back when 16kb was a memory expansion...
Quem a paca cara compra, paca cara pagará.
There IS a benefit to using punch cards once or twice. Especially on an old reader with copper brushes. Hole in card allows brush to connect a circuit signaling a 1. Right down to the bare metal indeed.
I would not suggest using that regularly, but it's a decent lesson.
For my A-level we made our computers from lcd screens and pic chips, and programmed them in assembler... This was just before the millennium, these computers are far more advanced.
This is a good idea, I wish more programming professors actually taught using this kind of method. Currently in Univeristy all the programming professors are saying C#, F#, Java etc... But how does that actually teach programming students. Ask any of them to write a good assembler program and you'll get total crap.
However ask the embedded programmer to write an assembler program and you'll (should) have it in no time!
I think it's an awesome approach. When I was in school in 1992 I took a class called "Computer structure." It was basically an assembly programming course, but we started on a PDP8, programming in machine language on the 12-bit front panel of the machine. One of our projects was to write a program that completely erased all of the memory locations on the machine, including the ones that contained the program. I think I got down to one populated location; it was surprisingly challenging. I did an independent project making a small programmable logic gate out of transistors, and with a bit more $ I could have made a 1-bit memory device. Definitely my favorite class in college. Working at that basic level gives you such a great perspective on what's happening under the hood of today's machines.
Table-ized A.I.
I was learning Pascal on an 8080 in 1997 in High School. It was retro, but not in the way you think is cool - it was in the we have NO money way
Took about 40 bytes of RAM, and 2-3 minutes to input via the front panel switches, and was a blast to play. Cycled lights through the 8-bits of output on the IMSAI front panel. Your job? Flicking an input switch ON just as a lit light passed above, the object being to turn it off. Miss and it turns a light ON again. Kill all the lights and you win. My 4-year old daughter has had access to everything including the latest console games on our big screen TV and she still begged me to fire up that game. Still have the IMSAI, still boots to CP/M 2.2 via 8, 5.25, or 3.5 inch floppy, and can still run that 40 byte game.
Dang whippersnappers are spoiled today, I tell ya....
(sigh) ... back to programming my 4 core Mac with 6 Gigs of RAM and a terabyte disk.
I went to college in the early 1980's and we could only dream about new fangled 1980's technology like the 8088 and 6809 while we cut our teeth on 1970's era 6800 and 8080 processors.
Teaching kids to program has been discussed countless times on Slashdot. The consensus is always the same: Get an old microcomputer!
According to Robert Nielsen, computer programming was taught using the famous Kenbak-1 computer at the Nielsen Electronics Institute well into the 1990's (1997, it think, not bad for a computer from 1972!)
With the computers 5 addressing modes and comprehensive instruction set, it still makes for an excellent teaching tool for advanced students.
An online emulator is available at http://www.neocomputer.org/kenbak
All the original documentation is available from John Blankenbaker's website at http://www.kenbak-1.net/
Required reading for internet skeptics
Just one thing.
How the fuck do you expect to learn something about the CPU if it's hidden beneath 20 abstraction layers?
DOS sure had its advantages.
Because that would be slow. And awful.
I'm reminded of something that happened to me while I was a student assistant at a remote job entry location of a university's computer facilities.
The incoming batch of engineering freshmen were being taught, as was the tradition, to program badly in FORTRAN. An instructor assigned them the problem of counting the ways to make change for a dollar, assuming you had plenty of all the denominations of coins. How did he have them do it? Nested DO loops, one per denomination, with each denomination running from 0 to 100 / the denomination's value, of course!
The result? Bunches of students exceeding the thirty-second time limit for WATFIV jobs so their programs were cancelled before they finished. They'd run them again, of course--maybe the first time was a fluke. (The university ran on a 370/138 at the time....) Then they'd come in and ask how to run in a different job class so they weren't limited to thirty seconds.
I wrote a program in Algol W with a recursive function that would solve the general change making problem. It solved the specific one in 0.01 seconds. A friend and coworker (alas, no longer with us) wrote a non-recursive program in FORTRAN that took less than 0.01 seconds, so that the output showed it as running in 0.00 seconds. Our boss took the listings and output and had a discussion with the instructor. He, and I hope his students, learned something.
Nowadays, they wouldn't. Today's computers would run the horribly inefficient version so quickly that nobody would care, and they'd move on to the next thing.
So I applaud this approach, and hope everyone gets that experience.
I've always wanted a PDP-11. They looked like a real computer, a rackmount box with a front panel, switches and flashing lights. Their architecture remains one of the classics.
I did an operating systems course back in the '80s on LSI-11s.
...laura
http://users.monash.edu.au/~ralphk/burroughs.html
This mainframe could be single-clocked through most of its execution and it brought out all of the registers to the front panel - each LED row was potentially 4 different selectable registers; that is how you isolated the problem and repaired the "bit". Pipelined, superscalar, and it had a relatively modern OS (many OS "firsts")l, the famous B5000 stack Architecture of the 1950s,60s. Its daddy had incandescent bulbs for indicators and core memory. You learned bare metal, or you didn't.
I work at a university, but as staff (not faculty). A few years ago, I had an interesting conversation with a friend of mine (Computer Science professor). As part of his Compiler class, the students construct a simple language then develop a compiler for it. I suggested that his students should be asked to create their language with these limitations: each instruction could only be 80 characters long (max) and could only be written using:
Look familiar? It's the character set from a punch card. LISP and FORTRAN were built using this.
I thought it would be interesting for students to construct a language and compiler with the same limitations from early computing. It keeps the focus on the language, keeping it simple. Would it help the students to build a better understanding of how early programming languages developed, or how languages evolve when (in a follow-up assignment) the students are allowed to incorporate more characters, including upper and lower case letters? And knowing more about computing, could students construct a (functional) punch-card-based language that was better than LISP or FORTRAN?
Well, I thought it would have been interesting.
My friend's response was "what's the point in that?" But after watching this video from the BBC, I think it would have done some good. I'd be interested to hear if anyone else did this in one of their Compiler courses, and what it was like.
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.
I don't understand. Soldiers don't train with halberds, swords and crossbows. Officers don't train with cavalry formations, trebuchets and castle. Engineers don't start off recreating Stephenson's Rocket or the Wright Flier. Cooks don't start off rubbing wood to start a bonfire and roast mammoth meat. Architects do not stick to cathedrals until they "get their chops".
In fact, science is about the only profession that does anything remotely similar for training, and even then, if old experiments are recreated, the setup has as many non-crucial elements replaced with modern equivalents as possible. We didn't bother using 19th century batteries for the Ohm's Law experiment, because it didn't matter where the current came from. We didn't bother sucking up chemicals with our mouth through pasteur pipettes for cholesterol extraction when we had automatic pipetters. We didn't bother using Bunsen burners instead of hot plates for chemistry.
Low level programming for ICs and the like aside, I don't see what about high level programming is so difficult to teach with, say, Eclipse. Possibly linking up the libraries can seem confusing at first, since a default project has a bunch of them already (and generated code for the GUI) but it's not like it won't let you start basic command line app projects.
This class would definitely teach much history, but just because you love reminiscing about back in the day doesn't mean you should inflict it on everyone. Not only does it make the student's job unnecessarily difficult, but it also takes away the motivation that comes from going home, and being able to immediately apply the thing you learned in class on your computer.
Maybe an ad saying you're looking to buy on Craigslist might work. Offer premium prices if you have to, the idea is to offer enough money so people will dig into their garages to look for ancient hardware you need and they don't. Also, talk to some local hazmat-computer recyclers.
Tech Public Policy stuff
speaking as someone who actually took programming classes on those things back in the 1960s, I'm not at all sure one can learn anything on those devices other than a better grasp of computing history. How is playing with paper tape going to teach anyone about how I/O works on modern computers?
If one wants equipment with super-slow execution speeds to let people see what's going on (try an oscilloscope as I did to debug a timing loop once), try finding an old Commodore 64 or Apple II on eBay.
Tech Public Policy stuff
There's a class at Univ.Delaware on this very subject, Computer History, which also covers programming these vintage computers. The instructors website is www.vintagecomputer.net
Atari basic on my Atari 800...
10 print "Commodore 64 sucks"
20 goto 10
If you could reason with religious people, there would be no religious people
I keep wishing I could get my old Microchroma 68 over here from the States so my kids could play with monitor debug ROM and hand-assembled code, but even that is not quite as hands-on as the 8080 (Altair? Imsai?) box we put together in high school industrial electronics.
Of course, making a toggle-switch interface for the Microchroma 68 wouldn't be too hard.
Dang. Now I want to run down to Nihonbashi, visit Marutsu Parts and some of the other places down there, and bring back some modern stuff, PIC or Arduino/ATMEL or low frequency ARM, or, hey, sometimes they even have S08 or ColdFire, although that is a bit more expensive.
Of course, what I really want to do is get my kids to help me wire-wrap an LS/VLS implementation of the 6809. Make it fully static, so you can hand-clock it instead of software single-step, bring the registers out in LEDs and 7-segment hex displays. Toggle switches, of course. That would allow me to teach the whole hardware stack on an architecture that can handle high-level stuff, as well.
I suppose I'd want to do something about the 16 bit addresses so I could handle Kanji, or even Unicode. But building a 6809 superset with instructions that load three or four byte addresses into the index registers wouldn't be too much more work. (Paged memory management is cheap, but indexing into an array larger than 64KB becomes difficult without large addresses. Then again, teaching the kids how to break what should be a simple indexed load into bank calculation plus indexed load is also useful programming experience.)
The big problem, of course is the paper tape or punched cards. I mean, the old tape or floppy disk drives are fun, and can still be hand-built if you really want to, but if you really want to get a feel of the connection between data and digital encoding, there is nothing more in-your-face than seeing the actual bits there as holes in paper.
Don't ask me what I'm going to do to earn a living while I'm having all this fun with the kids.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Computer architecture has changed quite a bit since the 1980s. Remember the RISC versus CISC wars? Remember floating point coprocessors? Remember the segment + offset memory model of early Intel chips? Remember instruction sets that didn't support division? How about Kansas City modulation to tape? This is what they would be learning if the course had any depth at all. (Which I doubt!) Thankfully computer architecture transcended all this stuff, and it's largely irrelevant today. Teach them how a modern computer works instead. Kernels, device drivers, cache strategies and such. Things they could actually use. This whole program sounds like a hipster ploy. Yawn.
Not even close.
Segmented pointers? Trying to work on addresses as if they were unsigned integers so the addressing math is clear?
How do you do a rotate (instead of a shift) in C, especially standard C?
How do you know for sure that you're toggling the most significant non-sign bit of a signed integer?
Etc.
You can get close to the hardware in C, yes, but only if you deliberately throw away portability.
Untangling the portability issues (among many others) generally takes you down to the assembly language level, even in C. Therefore, C is not sufficiently low-level.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Having taught myself to program on a Sinclair ZX81 (1K RAM, Z80 chip) it's primary virtue was that there was nothing to do with it but program it. On startup you had a command prompt: there were no games, no internet,no facebook, nothing but an editor for BASIC programs which were then interpreted. So the first question was always, what am I going to make you do today? Programs written in BASIC were a little slow, so I then learnt Z80 machine code which speeded things up and forced me to learn about registers and memory and so on. 1K of memory wasn't a lot to use, so I then got a book which gave the line by line Z80 for the ROM so I could exploit the routines in ROM in my programs, so I learnt about a (very very simple) operating system. While I'd never give up my current linux laptop, I cant help but feel I wouldn't understand 1/10th of the little I do understand if it wasn't for that ZX81. Thanks Mr Sinclair!
The old stuff worked and did the job. So does the new stuff, but the MS's and Appl's try so hard to isolate the user from the technology that we easily lose sight of what the technology is all about. Sure I can click here and there, cut and paste to my heart's content, but when I was working at the DOS level cmd line, I had to know exactly what the chips were all about so's I could tell them what I wanted them to do. Not at all like that today. It's a bit like the difference between driving a '56 xk140mc on a road rally and piloting an Esplanade along a major interstate.
We also had the AM radio playing frequency scales as FOR-NEXT loops executed. One guy figured out how to generate music notes and had the computer playing "Daisy" - shades of HAL 9000.
We also figured out how to program interterminal communication between 32 teletypes at once - today it would be called instant messaging or online chat.
Our instructor was amazed when we did it, because the system had no apparent support for this feature; we just "figured it out". Nobody thought of patenting software back then - - too bad....
I'm getting an HP2000 simulator up and running running on my Mac Pro, using open source software called SIMH. The guy who decommissioned our HP2000 in 1980 gave me the last a backup tape as an image file, and I have that image running in Windows. He was on the SIMH listserv and passed the files over to me.
I didn't find the cheating poker program I spent three months writing in 1976 (damn), but I did see my younger brother's friends names as authors in other program comments.
I've used SIMH to play blackjack on my Teletype ASR35, just like I did in high school, and that is retro gaming at its finest.
I recently discovered that SIMH can also run IBM System/370 legacy operating systems; apparently one fellow has MVS, CMS and TSO running under Linux on a Dell server. This is my next goal - to simulate the same mainframe environment that I controlled as a computer operator in 1980.
Kids today, they don't know what they're missing...
Ask Me About... The 80's!
I'm have something of a philia for older computers. This would be my dream ;-;
10 a=0
20 poke 53280,a:a=a+1
30 if a>15 then a=0
40 goto 20
When I saw "Bletchely Park" I was imagining they would get to program replicas of the original Colossus.
To have a right to do a thing is not at all the same as to be right in doing it
IMHO, this educational experience is totally worth it for perspective.
When all the constraints are tight, it forces one to consider all the elements of the computer. That's easy to avoid at higher levels of both programming language access, and overall computer capability.
I don't think it's a necessary thing for everybody, but I also don't think we can avoid this stuff entirely. The wizards, who understand real computing at the lower levels are needed to boot-strap new technology innovations.
Without them, we won't have those innovations, or if we do, they will be built on other things and limited in their potential.
Besides all of that, it's the most fun! Older machines rock! It's possible for one person to completely understand them. They are accessible in that way.
Most importantly, it's possible for one to write code and know every detail about it, not depending on other code. That experience is worth a lot, because it shows people the scope of problem areas. They can understand what they don't know, and then work to resolve it. Very valuable skill, largely denied to people working only at higher levels of things.
Blogging because I can...
Wow, that'd be like old-home week for me! I loved my Altairs :-)
Back them programs were still simple enough and short enough that you could stop it at any time and single step through it, examine the registers, read memory locations, change data in those locations, etc-- all from the front panel and see the results on the LED's. Even the "OS" (as it were) itself. I used to run CP/M on mine, mostly. But there were times I'd kick out the OS and just finger-bone something in from the front panel just for the fun of it. And the OP is right, it really does get you closer to the bone so as to be able to get a good, solid understanding of where the hardware ends and the software begins. And if you start *really* digging into things, you learn about the microcode inside the processor too, and how the microcode instructions become machine code instructions. So you learn about the ALU, the various internal switching busses, the I/O bus (for Intel-style systems and such) and working with memory locations, and "magic" memory locations (memory-mapped I/O), and how stuff gets into and out of the internal registers, and how the overflow and carry bits and so-on are really implemented inside the CPU and how they literally control the flow of "bits" from one spot to another, etc--- all of which is really useful information later when software starts getting layered, and bundled, and managed in different ways. Its easier to understand how to peel back the layers when you've had experience at that level to gain the perspective. I have found that its hard to explain it all to people who have never had to interact with the system at that level.
He's stating that in order to perform a rotate you need to use inline asm (he only said assembly language though, but this is doable in C/C++, &/or Delphi for example via the inline asm directive) to do so, and he's correct that it would break C's "intelligent assembler/cross platform code independence" in doing so
No, you wouldn’t, retard. If you know the size of a data word is WORD_SIZE = 32 bits, a bitwise rotate right is simply:
a = (a >> 1) | ((a & 1) << (WORD_SIZE - 1));
And a bitwise rotate left is:
a = (a << 1) | (a >> (WORD_SIZE - 1));
This is perfectly extensible to any platform with only the adjustment of the definition of the WORD_SIZE constant – which, as I said, you would need to know anyway because the results are hardly meaningful if you rotate an element of an unknown size.
But hey... naturally you wouldn’t know this, because your idea of “programming” is building front-ends in Delphi or VB for system functions like “move” or “copy”. Hardly a step above batch programming, really.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.