@dwardoric

In 2005, I was at a talk by Alan Kay. His ‘big reveal’ in the middle was that his talk was delivered entirely from Squeak.

This was after he had shown a full-screen video. The entire video decoder was written in Smalltalk and run in a bytecode interpreter, not even a JIT.

For most modern apps there is a very small set of things that are so performance critical that they need to be written and optimised in a low-level language. For everything else, you can and should use an environment that favours ease of use and extensibility over performance because the extra overhead will not show up to users at all.

I still don’t know how Electron apps manage to be slow. V8 runs JavaScript at least an order of magnitude faster than Squeak ran Smalltalk and my laptop is at least an order of magnitude faster than the one Kay used in his talk. None of the slowness is due to using a high-level language, it!s due to building a huge pile of the wrong abstractions on top.

@dwardoric A couple of years later, I was working on a Smalltalk environment that used the Objective-C runtime so it could interoperate at the method level with Objective-C.

It had a JIT compiler, a thing I called a ‘just too late compiler’ (which did ahead-of-time compilation of a program when it exited so you had a native version when you started it next time that you could subsequently patch with new changes). And a slow AST interpreter that was mostly there for debugging.

I was using it to write a couple of desktop apps and didn’t notice for a couple of months that a build of the compilers had failed and I had been using the interpreter all of the time. That was one of my ‘computers are really fast now’ moments.

The other was when I was writing my third (I think, might have been the second) book. The publishers’ ePub was not good on the previous one, so I wrote my own tool to parse my LaTeX, build a tree, do a bunch of transforms, and emit HTML. I wrote it in Objective-C, but in a very high-level style with no thought to efficiency, thinking that I would optimise it later. The first time I ran it over the entire book, it took 250ms. And a big chunk of that was library load time.