russellallen

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.

Yes indeed. People will think it is some sort of Linux distro.

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.

Its great to see this here.

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.

Hypermodern Python seems to have a lot more steps to it than Ye Olde Python, where you put a hello.py file somewhere and did 'python hello.py'.

Yes, yes, I know. But...

It’s an era only just ending now with the emergence of Truffle/Graal.

As I understand it, when Sun developed Java, they ditched Self. Some of the Self team left, and created a Smalltalk VM using the Self VM techniques called Strongtalk. Sun belatedly realised they needed a fast VM, and rehired the team which formed the basis of the HotspotVM.