50 Year Old Computer Still Going

The Angry Mick writes "Geek.com is running a blurb on a 50 year old CSIRAC computer that is apparently still functional, if lurking in an Australian museum. Sporting a whopping 2K of RAM and screaming along at a blistering 300 khz(!) it proves the adage that they really don't make 'em like they used to . . ." Yes, because if they did, they'd be really, really slow.

Comments

I wonder...

[ciupman]

.. how do they cool that thing down?

Running eh?

[Fizzl]

By reading the horde of nested articles, I got the impression that the machine hasn't run in decades, and probably would not if powered.

Correct me if I'm wrong. But please quote a piece that says it is actually running now.

Impressive

[FrostedWheat]

My first computer, the C64 runs at a massive 1Mhz, only about 3 times faster than this machine.

Commodore released the 64 in 1982, this puts it at 20 years of age. That's 30 years between these two machines. When did Moore make that law again? :)

Yikes, imagine what the computer world will be like in 30 years time! Assuming MS haven't screwed it up for everyone.

These computers are not to be laughed at

[Viol8]

It does annoy me that people , even though its in good humour , snigger at these old machines with their "paltry" 2K memory and slow speed. Yeah , sure they're not exactly a Cray. But look at what was done with this one. Skyscraper design , cloud droplet simulation, antenna design! Lets see even the best programmers used to point and drool GUI interfaces and hand holding wizards try and do that in 2K now using little more than paper tape! The people who designed, built and programmed these machines REALLY knew what they were doing and probably forgot more about efficient programming and code compression than todays "top" coders ever knew in the first place.

Re:These computers are not to be laughed at

[Krokus]

Lets see even the best programmers used to point and drool GUI interfaces and hand holding wizards try and do that in 2K now using little more than paper tape! The people who designed, built and programmed these machines REALLY knew what they were doing

I'm pretty sure they would not have snubbed their nose at the idea of being given a machine that had a GUI interface and piles of RAM and storage. Oh, to be able to focus on the problem at hand and not have to be distracted by the limitations of a 64 byte stack!

To belittle the programmers of today because they have not suffered the restrictions of yesteryear is a bit silly. Even today, there are embedded systems programmers who still deal with such restrictions. Do we elevate them to deity status? No, we just sit back and wait for Carmack to speak.

Re:These computers are not to be laughed at

[Viol8]

In reply I would merely point you to the bloatware that exists today on all systems. You call that the work of efficient (read good) coders? I don't.

Re:These computers are not to be laughed at

[fusiongyro]

To back up the parent of the previous post, I know someone who has been programming since the late sixties or early seventies. While that may not be quite 50 years ago, it certainly means he has had some experience with tape storage, even punch card FORTRAN initially, and probably worse though he doesn't talk about it very often.

What does he do now? He is still an application writer, his language of choice being Python and his file format of choice being XML. Frankly, I think this is quite telling: his opinion if I understand it correctly is that since we have the power, we shouldn't waste time writing things lower level than necessary. By using Python and XML he's far, far removed from the ordinary perils of yesteryear like memory management, pure procedural programming, even memory and disk size limitations.

And frankly, while those things are difficult to deal with, they're also very rote and don't leave much expression to the software engineer. People who favor C and to some extent C++ usually admit that there is some pleasure in the sheer amount of control in using the language; it's my opinion that people using Perl, Python and to some extent Java are the people reading books with "Practical" or "Design" in the title, and that's really a better way to do things.

In reply I would merely point you to the bloatware that exists today on all systems. You call that the work of efficient (read good) coders? I don't.

It's an easy attack to make, with some degree of merit. The qualifications for being a coder these days are certainly less strict than they were at one time. However, the observation of the post you were replying to was that the older systems had less to do than modern ones. When you resize your browser window you're doing an operation that, as far as a 386 would be concerned, is non-trivial. Add to that the sheer size of the parsed webpage which generates the pretty view you see, and you've got yourself a lot of graphical things to do, and a huge datastructure in RAM. This is not the kind of problem that can be solved simply by being able to manually manage memory from assembler. This is the kind of problem that requires an intelligent design from the get-go, so that optimizations can be placed in the places where they are required as needed.

Bloatware? Probably. People who needed computers for whatever reason seemed to be getting along with them just fine without GUIs, or multiprocessing, or realtime 3D games. All of these additions is going to consume resources both when written and when used. I won't argue with you that Windows would have been better if it were based on a clean design. Clearly it would have, and on Linux we now have many desktop systems based on (if not a good deal more forethought) at least the trial-and-error process that produced the early GUIs done with a faster turnaround. Unfortunately, the users have come to rely on GUIs, pretty widgets, and browsers that resize. If they were not, perhaps we could cut down on the code quite a bit.

Also, one thing about my friend I mentioned earlier: while his code is extremely well-designed, he seems to have a fundamental lack of understanding of ideas such as UI design and concurrency. None of his programs as far as I have seen have used threading, even the GUI ones, and the few GUI programs I have seen were beyond the ugliness I expect from TK. He wrote an abstraction layer for a database that implemented foreign key constraints, and was at a bit of a loss when I first tried to explain to him that it wouldn't carry over necessarily if multiple copies of his application were running simultaneously. So we all have these problems, and we all try to get better.

If you want to see well designed and implemented code, I recommend you pick up a copy of BeOS. By sacrificing backwards compatibility, they managed to create an operating system from scratch based on object-oriented principals. It's quite amazing when you realize the things that you could do with it that you couldn't do with Windows, yet it was a tiny fraction of the size of Windows when fully installed. For example:

1. Active queries. Linux acquired something similar via FAM but you need application support for it. Basically, you could search for files based on their attributes, and as files were removed or added to the system they would disappear or appear in the query. The query could be used like a directory for all programs that could access one (AFAICT).
2. Device drivers took effect immediately upon placing them in the appropriate system directory (except display drivers).
3. Applications were tiny - the HTML 3.0 compliant browser came in at under a meg for the whole binary. I never saw an app larger that 5 MB.
4. A full install came in at about 300 MB (comparable to OpenBSD) IIRC.

Now I'm going to get some sleep and try to forget about the sorry state of computing we're in right now.

--
Daniel

Re:These computers are not to be laughed at

[Russellkhan]

The values have changed.

In the past, memory and storage were expensive and limited, and processors were slow.

Today, Memory and storage are cheap, and processors are fast.

This has changed the focus. In the past, it was important to get as much done as you could with as little as possible. Today, we sacrifice a bit (perhaps too much) of that because we can afford to. The prime measure of efficiency today is code readablility and reusability. Why do you think OOP is so big these days? Do you think it's more efficient, in the traditional sense of making smaller, faster programs that use fewer resources? Not at all. There are optimizing compilers that do a good job of making OO code efficient, but it sure isn't inherent in the design of the languages. That's not the focus. The focus is on readable, reusable code.

Unclear

[Russellkhan]

The Geek.com article says:
" A half-century old computer, called CSIRAC, is still operating in Australia. The computer, which was Australia's first, ran at a blistering 300 kilohertz, had 2 KB RAM, and 2.5 KB storage."

But the Inquirer article linked by the above Geek.com article says:
"The machine was the fourth computer to be built anywhere in the world, ran at 0.001MHz, and had a massive 2000 bytes of memory and a behemothic 2500 bytes of storage."

Which, by my calcuations, would be 1000 hertz or 1 kilohertz. I tend to believe the Inquirer, since they're running the source article. And besides, the 1977 Apple ][ was only 1 MHz, Don't you think there was a bit more progress than less than doubling in processor speed from 1949 to 1977?

Re:Weather prediction ?

[BitwizeGHC]

That computer could process larger amounts of data than anyone giving weather forecasts on the radio at the time...

It seems laughabel to us now, but back then, it was an advancement. Ever onward and upward, such is the progress of computing.

Re:This is news?!?!?

[nmg196]

It says "typical" not "state of the art". Most desktop PCs *ARE* around 500Mhz and *DO* have only 64mb of RAM.

The article is clearly dated "Dec 10 2002" so it's not "from around a year ago" at all - no idea where you got that from.

Nick...

The trick...

[KC7GR]

...is to combine the best ideas from old and new technology alike, and blend them into an entirely new result. That, to my eyes, is what real "innovation" or R&D is all about.

Some examples: DEC (Digital Equipment), in their heyday, came up with some great techniques for memory management at the hardware level. I'd be curious to know how many of those ideas got rolled over into more current stuff.

Another one; Where would we all be if Xerox's PARC facility had never come up with what has morphed into today's electronic rodent? Heck, IBM was using light pens years before that.

In short; You don't want to just ignore something because it's "old" or "obsolete" (Essence, I loathe that word!). You need to take the good ideas from the old stuff and build on them.

Somehow, I doubt that we would have so many tons of electronic junk choking landfills today if computer and electronics hardware was (a), really built to last, like the old stuff was; And (b), built to be easily upgradeable.