Re: A quick question
Some of my Smalltalk from the early 80s is still in use, but folks like Dan Ingalls have code from circa 72 in there. And yes, still making a living from it.
233 publicly visible posts • joined 11 Oct 2016
I think a lot of it is simply acquisition of money laundering tokens. Houses, artworks, somewhat unique or at least rare items like original iPhones etc are just symbols of value that can be exchanged with less chance of triggering tracing or taxing.
For those interested in hearing from the people that *made* and *used* the Alto, consider joining the Computer History Museum's shindig tonight (April 26, 7pm PDT, see https://computerhistory.org/events/the-legendary-alto-and-research-at-the-edge) to hear from Butler Lampson, Alan Kay, Charles Simonyi, and others. I'd be there in person if I still lived in the valley.
"I remember looking at it around 1990. RISC OS 2. It looked and acted like pretty much every other X- Windows based GUI floating around at the time in the US."
It really didn't. I was there too, doing UI research work in the UK (IBM UKSC and even at Martlesham!) and the US (ParcPlace! Interval Research! DEC WRL! HP labs!) and so on. Quite aside from anything else RISC OS was significantly faster than any X based UI, and was at least internally self-consistent - something none of the Xwindows systems seem to have mastered even today.
The PARC GUI was originally implemented on custom computers like the Alto (and the Dorado, Dandelion, DandeTiger, etc) as a deliberate approach to seeing what could be possible with The Computer of The Future. They spent money to step 5 years into the future. So yes, expensive hardware originally in order to be able to do something advanced.
As for the code, well yes and no. It was, after all, Smalltalk. The time consuming part was working out what to do, since it hadn’t been done yet. The code for it was actually pretty simple. It had to be because there wasn’t much memory to play with on an Alto. IIRC it was 128kb including the screen memory. You can play with that original code at https://smalltalkzoo.thechm.org/ and see just how simple it was/is.
Of course these days a Raspberry Pi 4 can run Smalltalk around 20,000 times faster than an Alto and can have 64,000 times as much memory for a price equivalent to a diner lunch
Smalltalk was always select-menu-windowmenu until Windows got common enough to start warping people’s minds. So these days it tends to be select on main button, menu on secondary, window on tertiary or alt+secondary etc.
Fun bonus fact - I did the original port of Smalltalk to ARM (it was a launch day language for the Cpu) and had many discussions with the RISC OS team about mouse use & behaviour, menus, etc. I *still* make a living using Smalltalk on ARM.
You do know that modern Smalltalks have all that and more in the debuggers, right? And the dynamic code generation is really pretty damn good at making things fast. It’s all moved on quite a bit since ‘76. PIC message sends are about the same speed as ‘normal ‘ procedure calls.
Given that the original Smalltalk was monochrome (outside a small number of experiments) your colour-blindness issue is implausible.
The UI is one of the great triumphs of Smalltalk. A decent integrated development system with a self reflective language that can debug itself, analyse itself, is far ahead of the tedious text edit, save file, run compiler, try to run result if there was any, run ugly annoying debugger, try to work out what to edit in what file, repeat until exhausted. Making a text only Smalltalk really doesn’t have much value if it loses the live nature of the system.
Thing is, the Alto was running Smalltalk and so making the windows draw in any manner one wanted is pretty easy. It’s a matter of how much performance one has available and in 1972 there wasn’t so much. Not even on an Alto, which was perhaps 5 years ahead of the general state of things.
Later, on slightly faster machines we indeed implemented something you might recognise as rather like QuickDraw. Current Smalltalks do a wide variety of things- host windows working via host apis, BitBLT in a single window, web based displays, driving OpenGL or Cairo, etc. Sometimes all of them.
More than that - a function call is a jump to an address, an instruction known in advance by a typical compiler of dead-text languages. It says ‘go there and follow those instructions ‘. A message send is ‘please Mme. receiver, would you be so kind as to handle this request to find the letter sent to billg’. Depending on what the receiver is, anything might happen as a result- you might have a database dig out the letter, or a prank BOFH object set fire to your chair. The lookup of the action performed is dynamic - at least in a proper language- and that leads to being able to make dynamic environments like Smalltalk.
If your experience is limited to static languages with no live debugging and development then you are missing out on a substantial amount of joy.
At one of the labs I worked at in Silicon Valley we had an a/c failure that resulted in almost indoor snow conditions for a few weeks. People in heavy coats, fan heaters aimed at feet, the works. Combined with 30C outdoors it made for some pretty unpleasant sniffles as the sudden temp changes every time we entered/exited upset noses. “Vasothermal rhinitis “ my doctor called it.
Rented an early Subaru when in N’orlins for a conference. Drove off and eventually needed petrol. Couldn’t find how to open the damn flap.
Nice chap at garage called local dealer- “how do you fill up one o’them Subarus?” “That’s all right sir, it’s pre-installed at the factory.” Smartarse...turned out you pushed the same tiny lever you pulled to open the bonnet.
I had an early NS32032 machine ~1983, though I never got Smalltalk running on it (I wrote a very simple 3D interactive solid modeller on it, terrible performance).
On the other hand I had Smalltalk running on ARM before more than a couple hundred people knew about ARM. And ~25 years ago I was working on a Smalltalk medium-hard real-time OS on custom ARM hardware. It worked quite well, and was intended for a consumer network/media system that would have given us al the useful parts of IOT in the mid 90s. If only bill gates hadn’t stuck his foot in it...
Others have made Smalltalk sorta-OS systems too. So much nicer .
PiHole helps save my sanity.
PiVPN.
An old model A in the garage runs a bunch of weather sensors and publishes MQTT to a broker. Another Pi runs a Smalltalk MQTT client I wrote and displays that data along with a fleet of other sensors around the estate.
Another runs a Smalltalk code repository.
Two Pi4s serve as main development machines, one for 32bit the other for 64bit, though the 32bit setup is really only for Scratch legacy support work for RPT. Several more live in PiTop ceed units for teaching.
Some are setup as MotionEye camera systems.
Another is an ISS backup of sorts.
I do have one or two in the cupboard, including an NIB Pi 2, but the others are damaged for one reason or another and are just in honourable retirement.
If I ever find time I want to play with Asterisk/IncrediblePBX, some home automation stuff to replace my current systems, a laser cutter, a CNC router, 3D printer etc. Lots of work left for Pis.
Not really. It can help if you have it in a tight space, or you are heavily loading it all the time. My main Pi 4 is in a tight space and I do load it quite often and the PWM seems to fire up about once a week for a moment. Give them a decent PSU and attach an SSD (I use a geekworm x820 board) and they are very happy.
If you need more power, pay more money. Easy.