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')
There are more reasons why smalltalk failed to become popular:
- expensive commercial licenses over free Java/C/C++
- multiple vendors with incompatible versions
- closed nature and hard to integrate with existing tooling (editors, vcs, OS)
- poor story for Web, Java had applets and JS was native
- slower and memory hungry compared to C++
- lack of type safety compared to Java/C# or Ocaml
> closed nature and hard to integrate with existing tooling (editors, vcs, OS)
This is probably the big reason - Smalltalk is its own OS and GUI, and didn't play well with others until relatively recently.
> poor story for Web, Java had applets and JS was native
This only became relevant after Smalltalk was already very niche.
> slower and memory hungry compared to C++
So was Java back then, and, thanks to free-as-in-beer and being easier to integrate into build tooling and the workflows developers were used to, it had a much bigger impact.
> lack of type safety compared to Java/C# or Ocaml
The way Smalltalk works, this is more a feature than a bug. It's a given it'll result in more runtime errors if types are abused, but that's also one of the reasons so much early progress on automated unit testing started there.
I am quite sure that if Visual Age product line hadn't been rebooted into Eclipse, and IBM Smalltalk replaced by WebSphere, IBM J9, things would have worked otherwise.
IBM's Developer portal from 1998 - 2002 shows quite well how much IBM was partnering with Sun spreading the Java gospel.
C# only came to be after Microsoft's misadventure, and OCaml never mattered that much in 2000.
> And which of those supposed explanations would also suggest that Python should be unpopular?
Python was free and open source, had one of the best interop with other tools and excellent open ecosystem. Python now have better type safety via mypy than Smalltalk ever had.
> And which of those supposed explanation would also suggest that JS should be unpopular
JS is destined to be popular, it has monopoly in browser. It is the only reason why it is popular.
> Think again.
I worked on Smalltalk project for a year and I know how limited and closed it is. Smalltalk had combination of all these factors that made people choose C/C++/C#/Java for performance, JS for browser, Perl/Python/PHP for scripting and Visual Basic for GUIs. There were hardly any places where Smalltalk was a better choice.
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.
Ah yes, fair point. I think it’s Gandalf that says the Hobbits are stouter than even the Wise know or something to that effect but, like you say, they aren’t impervious to the charm of the ring. Except perhaps Sam, with his abundance of hobbit-sense and love for Frodo.
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.
By adding an author profile and a list of other Singularity Hub articles by the author, they make it look like the author is part of the Singularity Hub community, but the two articles that he has written are both from The Conversation.
The Conversation literally has a button you can click to help you copy & paste the article.
And there's attribution at the end of the Singularity Hub repost. There's nothing shady going on here.
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.
It's probably a personal thing but the main point is this:
- Pharo and Squeak are both one full screen application with their own window manager inside. And that window manager is terrible and slow. I can't even alt-tab between windows. The old "Visual SmallTalk Enterprise 3.1" from 95 leverages all window handling to the OS and is quick and snappy. It also has a native look if that is your thing. This contributes a lot to the developer experience: shortcuts and code completion are quick and snappy, you can easily deal with the separate windows, etc. In Pharo everything is so slow compared to this and not very developer friendly. Maybe someone can show me what I have been doing wrong but this is my main gist.
Dolphin Smalltalk from Object Arts allows alt-tabbing between native windows. The formerly commercial professional version has been released as open source. It is Windows only, but it apparently runs well via Wine on Linux and Mac. Though the executable is 32-bit only, and lightly maintained, it provides an aesthetically pleasing and responsive development environment.
I am guessing that there's not much motivation to change this because of the desire to run anywhere. They can run inside an SDL window on a computer, but, with little modification, you can also get everything running on bare metal, in a browser canvas, or on a mobile device. Visual Smalltalk Enterprise, on the other hand, only ran on Windows.
Personally, I'd welcome something that can do a decent job at cross-platform native-like UI. But I'm not terribly hopeful. As far as cross-platform UI goes, Electron seems to have sucked all the air out of the room.
Yeah I understand it's easier to make it run everywhere but more choices would be nice. Yeah VSE only runs on Windows, that is one of the many negatives about it.
Original Smalltalk was always "full screen" so it is strange to argue this way. Anyway, there are still Dolphin Smalltalk and Smallltalk/X (jv-branch) under active development that use OS windows manager. Pharo will allow working this way soon as well. On the other hand, it has own downsides if you work in multiple images at once and mix their windows together.
Yeah the original was, but many following that weren't "full screen". As I said it's a personal preference. I did hear that Pharo is working on something like that so I hope it will be implemented soon.
I thought that Dolphin was not developed anymore, that is nice to hear. I'll have to check it out again. Which of the two would you recommend?
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!
> 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?
GraalVM and TruffleSqueak have evolved quite a bit, but it is still the case. With libgraal, TruffleSqueak warms up much faster, and we were able to further improved the performance of TruffleSqueak. If you'd like to give it a try, it should be fairly easy to get started: https://github.com/hpi-swa/trufflesqueak#getting-started
> And more generally, in comparison to the OpenSmalltalkVM, what are the TruffleSqueak downsides? The upsides seem nicely obvious!
TruffleSqueak passes quite a lot of Squeak's SUnit tests (see [2]), but is of course not 100% compatible yet. Proper support for some plugins (e.g. FFI, OSProcess, ...) is still missing.
Apart from that, I'd say that TruffleSqueak has to live with the design decisions made in Truffle, but we can build on and reuse all of GraalVM components (e.g. JIT, GC, ...). The OpenSmalltalkVM, on the other hand, is more flexible, but you have to implemented everything from scratch.
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?
> It seems like a revisiting of the experience of the Self team between the second and third generation of Self VMs, though the underlying hardware might be just a little faster :) Do you think this tradeoff of peak performance vs interactivity is inherent in Truffle'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 completely agree. Mario Wolczko, who worked on the Self VM at that time, is part of the extended GraalVM team. So the knowledge and experience is there, it only has to be implemented. The GraalVM team is thinking about ways to support snapshotting and a couple of other things. Their profile-guided optimizations [1] is probably the closest to that and definitely a way into the right direction. So I'd say it is possible to make performance of GraalVM languages much more predictable, maybe to the extent that it doesn't matter anymore for interactivity.
> and we were able to further improved the performance of TruffleSqueak
Is there an overview somewhere which allows comparison with fig. 4 of your ACM 2019 publication? Anyway in that publication SOMns using the same technology - as far as I understand - showed a completely different performance pattern; does this still apply, and what is/was the reason for this?
> Is there an overview somewhere which allows comparison with fig. 4 of your ACM 2019 publication?
We have set up a benchmarking infrastructure for performance tracking, but it is unfortunately not public (yet). Also, we have switched from GraalVM EE/JDK8 to GraalVM CE/JDK11 a couple of months ago, which makes it hard to compare recent with older results. But what I can say it that performance on GraalVM CE/JDK11 is currently better than on GraalVM EE/JDK8 a year ago. I expect it to be faster on EE as well, but I'd need to measure by how much.
> Anyway in that publication SOMns using the same technology - as far as I understand - showed a completely different performance pattern; does this still apply, and what is/was the reason for this?
Correct. First, SOMns does not support a real Smalltalk system and does not support some crucial mechanisms (e.g. changing the class of an object). So TruffleSqueak must check the class of an object in quite some cases, which is a slight, unavoidable overhead. More importantly, SOMns has some primitives that Squeak does not, for example for comparing strings. That's for example another reason why SOMns is so much faster in the JSON benchmark. For your curiosity, here's a screenshot of the benchmark results for a current TruffleSqueak and SOMns (note that they ran on different versions of GraalVM, I think you can somewhat compare the TruffleSqueak numbers to "GraalSqueak-CE" in fig. 4 of the paper):
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.
While being class based does make Squeak's Morphic a bit more awkward than Self's, the big difference is that it is a hybrid system that can run older MVC (Model View Controller) applications with little or no modification. That means that there are two different ways of doing most things and someone looking for examples to copy might run across the MVC version instead of the "proper" Morphic version.
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.
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.
I think it's a very enthusiastic post. Anything can be over engineered - and generally young enthusiastic programmers are keen to learn about the options.
id be tempted to clone the structure of the posts, and replace the images with some stock photos of supermodels lying down on modernist furniture with cobras and other snakes wrapped around them or lying on the floor nearby.
Its not the language python, its the ... how to build a project that others can use. Its the scaffolding that 'just' knowing how to program does not teach you but working in a real environment forces you to learn.
Just skim-read but it seems to cover the sensible parts - all of this applies if you are writing 100,000 lines of code or 3 lines of hello.py
I am trying to write thedevmanual.com which is basically all of that - what it takes to run in real life. it is of course opinionated, and in lockdown :-(
