Keeping these amazing old systems around and usable is so very important to counteract the continual reinvention of the wheel that the industry is prone to (aka 'computing is a pop culture')
Even the hobbits fail - Frodo claims the ring at the last minute and it is only the intervention of Providence (in the guise of Gollum) that saves the day.
It's great. The movable boxes and links between them remind me a lot of the Self programming language which I love, and the way the boxes wiggle when you pick them up is just genius.
Ideally this story should be changed to this URL which has further comments by the author attached to it. Also The Conversation is a legitimate Australian academic site.
I’d be interested if you could expand on why the modern Smalltalks feel wrong, because on paper they have more features etc. Not arguing - genuinely interested.
Cool. That video of the bouncing atoms demo is fascinating.
It seems like a revisiting of the experience of the Self team between the second and third generation of Self VMs[1], though the underlying hardware might be just a little faster :) Do you think this tradeoff of peak performance vs interactivity is inherent in Tuffle's approach? Or can Truffle realistically aim for the best of both worlds?
One interesting aspect of the Self VM is that it can save the JIT generated native machine code together with the Self code in the image/snapshot, so that you can load a pre-warmed set of objects. Is that possible within the Truffle framework?
I vaguely recall some mention in one of the docs I read a while back that you were having difficulties with the JIT causing noticable pauses/latency in interactive environments like Morphic, comparison to the OpenSmalltalkVM.
Am I recalling correctly, and if so is it still the case?
And more generally, in comparison to the OpenSmalltalkVM, what are the TruffleSqueak downsides? The upsides seem nicely obvious!
My experience of doing morphic stuff in both Squeak and Self, is that in Squeak there was a bit of a disconnect between the instance side and the class side - you could click together morphs, but in the end you had to write code in morphic classes to reconstruct those morphs.
There wasn't any automatic way to go from the morph instances to equivalent morph constructors, or any way to save the morph instances to copy and use later. So I ended up ignoring the instance manipulation and just coded morph creation methods.
In this way, the morph class hierarchy became much like a hierarchy of factories.
This mattered when I was doing a GUI to run on my Compaq iPaq because a lot of morphs (such as menus) were being created afresh each time they were needed. This was really slow and I only made it usable by caching the created menus and only displaying them when needed.
On Self I would have just copied the previously constructed menuMorph prototype and displayed it (if of course I had been able to port the huge pile of C++ that is the Self VM to the iPaq :)
This was ages ago though and I haven't played properly with modern Squeak or Cuis.
Unfortunately the version in Squeak is, in my opinion, fancy looking but a backwards step from the Self version in terms of the underlying system. Morphic doesn't seem to really fit all that well with class based systems.
I used the Squeak browser plugin with a class of university students in the late 90s - it worked really well. Native speed, much more interactive GUI than the browsers at that time, and I could update their essentially desktop app between classes and not have to get it reinstalled by IT.
I did have to do some persuading to get IT to install the plugin in the first place though.
It was doomed tech in hindsight though, together with all the other plugins.