> This paper is an experiment in side-stepping operating systems, and pushing functionality into the runtime of high-level programming languages. The question we try to answer is how much support is needed to run an application written in, say, Smalltalk or Python on bare metal, that is, with no underlying operating system.
We spent a lot of time these last 40–50 years chasing performance above all else, prioritising it before safety, expressiveness & development time.
I think that modern computers are so amazingly fast that a little cleverness can go a long way, permitting us to run more safely and write more quickly with more powerful languages. Honestly, I wish we had been doing that for decades at this point — computers were actually plenty fast even in the 90s!
> We spent a lot of time these last 40–50 years chasing performance above all else, prioritising it before safety, expressiveness & development time.
I would agree with this for operating systems, but I just don't see this being true for application development. I am thinking Electron and deep levels of abstraction introduced by the Web.
I don't think it's at all true that major consumer operating systems have chased performance as even a mid-tier priority for ~25 years, at least. The only major counterexample I can think of is iOS. OSX/macOS probably does the best job as far as desktop operating systems, but even it has long stretches where it just gets worse. KDE and Gnome desktops haven't been particularly good compared to contemporaries in the 20ish years I've been using them off-and-on (though KDE's gotten back to non-terrible territory, at least). Chasing performance on the desktop, for a user, largely means "regressing" to older or older-style software and abandoning the mainstream. The full-featured modern stuff, despite not really doing that much more than the older stuff, is far heavier and slower.
What I was getting at can be reduced to a single word — a single letter, even: C. The fact that any software is written in C (or C++) is IMHO sufficient proof that the developers care more about performance than they do about anything else.
I think that still holds even if they demonstrably do not care about performance all that much! You are quite right: current software is heavier and slower than it used to be and than it needs to be; it is also less safe and is more difficult to develop than it needs to be.
The popularity of things like Java or JavaScript is another disfunction: although they are very different from one another, they are similar in that they have poor syntax, frighteningly bad ergonomics and poor semantics. They require too much boilerplate (in very different ways) and are insufficiently expressive and powerful. They are not even as much safer as they should be, given their memory safety!
Operating systems in the sense of kernels might still be focused on performance, but the whole GUI layer of every major OS (maybe except macOS, which might explain why most of its utility programs are still so snappy and nice to use relative to much of the competition) is full of virtual-machine languages, scripting languages, and so on. Look at Gnome—they've wrecked their performance in no small part (so far as I can tell) by integrating JavaScript so heavily into the shell, and show no signs of reversing course. The parts of the OS typical users directly interact with, and its basic GUI utility programs, are increasingly not written in C, C++, or similarly high-performance languages with tight memory and performance control, but VM languages, languages with (relatively) big, heavy runtimes, and interpreted langs.
It's bad that so many applications have given up on even halfway caring about respecting the user's computing resources, but IMO it's much worse if you can't even boot to your damn GUI desktop without a pile of JavaScript being loaded into memory.
JavaScript delenda est. It is to the 2010s as Java was to the 2000s and C was to the 1990s: unjustly popular, and a step backwards from better, deployable technologies. Its deep design flaws are obscured by its superficial design flaws.
Choosing JavaScript is a very different mistake than choosing C (it is at least memory safe, which counts for something). But it is deeply disheartening to imagine how many man-centuries (or man-millennia?) of work have gone into the ramshackle apparatus which is the JavaScript ecosystem while better ecosystems wither and starve for lack of involvement.
> We spent a lot of time these last 40–50 years chasing performance above all else, prioritising it before safety, expressiveness & development time.
I'm not sure I agree with this assessment. Certainly some developers have been targeting performance (particularly compiler devs. Arguably UI devs). However, in corporate development, performance has ALWAYS come second to development time. The only time performance matters is.. well, when it does :). That is to say, it only matters when slow things are causing unhappy clients or missed deadlines.
BeOS on a 166Mhz Pentium with 128MB of RAM (luxury!) felt positively spacious. Like you were lavishing it with far more resources than it needed and so rarely risked even approaching its limits, so far as maintaining UI responsiveness while multitasking, at least.
No, the modern computers aren't that fast. Try running a BFS over a large matrix in python and then in cpp. You'll understand why perf matters. I realised this during one of my college assignments.
I spent the first 15 years of my programming life in these environments (CADR and the Symbolics machines at MIT and other labs; Interlisp-D , Smalltalk and Cedar/Mesa at PARC).
They are the most productive environments I’ve ever used for development, no question in my mind. OTOH they were terrible for deployment: user hostile and expensive.
Also a lot of programming is defensive: against poor or inexperienced developers including oneself. When you can casually change anything you can get into trouble, either by breaking things or by simply embedding unexpected dependencies your code.
Back in the 90s we hit a massive wall on three fronts using Smalltalk: collaboration between developers (no file system to share code); no change control; deployment to users (stripping down images to make applications).
We had a pile of hacks but integrating changes took all the productivity of Smalltalk away.
However, tools like Envy/Developer fixed a lot of it. It still didn't fix everything but at least sorted code integration and source code versioning. Not sure if the product still exists though.
I loved using Smalltalk but in a team environment its useless and keeping your code disentangled from the underlying environment is a nightmare.
There is no separation between “application” and “system software”. While super powerful it made it hard to update the system and the applications separately. Multiple programs could make conflicting changes.
In addition, lisp programs (at least in these environments) don’t have “main”. I think it’s no big deal to start a program as “(foo)” but that’s surprisingly user hostile.
I worked with someone (who shall remain nameless) who ran in the same image for several years. There were random state variables scattered in his environment that affected the performance of his system in unreproducable ways.
> In addition, lisp programs (at least in these environments) don’t have “main”.
But they have similar mechanisms.
In Symbolics Genera 'programs' are called 'activities'. They can be started by keyboard shortcut, command, an application menu or by a general function, where the activity is an argument. Usually each 'activity' runs a command loop.
Additionally images have named lists containing functions, which are executed on certain event. For example if an image starts, a 'cold boot' list will be executed. If one has registered starting application programs (activity) - remember activities have names like editor, listener, mail client - they will be started by the operating system after a boot.
If a user logins on a Lisp Machine an init file gets executed. That init file can also contain general forms which start activities.
Out of the topic, but I was always wondering, where can I follow all new CS papers like this one. Is there any sites I can follow like HN, any suggestions?
Just yesterday I stumbled into `Out of the Tar Pit` which is turns out to be a very life-changing for many people and was thinking, why I haven't seen it before in my career
I wish we could have Lisp Machines for our desktops. Single language for the whole stack, so easy to scope the source and reason about the choices made by developers. No software bloat at all.
25 comments
[ 5.5 ms ] story [ 62.7 ms ] threadI think that modern computers are so amazingly fast that a little cleverness can go a long way, permitting us to run more safely and write more quickly with more powerful languages. Honestly, I wish we had been doing that for decades at this point — computers were actually plenty fast even in the 90s!
I would agree with this for operating systems, but I just don't see this being true for application development. I am thinking Electron and deep levels of abstraction introduced by the Web.
I think that still holds even if they demonstrably do not care about performance all that much! You are quite right: current software is heavier and slower than it used to be and than it needs to be; it is also less safe and is more difficult to develop than it needs to be.
The popularity of things like Java or JavaScript is another disfunction: although they are very different from one another, they are similar in that they have poor syntax, frighteningly bad ergonomics and poor semantics. They require too much boilerplate (in very different ways) and are insufficiently expressive and powerful. They are not even as much safer as they should be, given their memory safety!
Our industry is appallingly immature.
It's bad that so many applications have given up on even halfway caring about respecting the user's computing resources, but IMO it's much worse if you can't even boot to your damn GUI desktop without a pile of JavaScript being loaded into memory.
Choosing JavaScript is a very different mistake than choosing C (it is at least memory safe, which counts for something). But it is deeply disheartening to imagine how many man-centuries (or man-millennia?) of work have gone into the ramshackle apparatus which is the JavaScript ecosystem while better ecosystems wither and starve for lack of involvement.
JavaScript delenda est.
I'm not sure I agree with this assessment. Certainly some developers have been targeting performance (particularly compiler devs. Arguably UI devs). However, in corporate development, performance has ALWAYS come second to development time. The only time performance matters is.. well, when it does :). That is to say, it only matters when slow things are causing unhappy clients or missed deadlines.
Difficult to believe with how unresponsive modern UIs are.
As I recall, it was pretty snappy! I think it would still have been sufficiently snappy had its OS been written in Smalltalk or Lisp …
They are the most productive environments I’ve ever used for development, no question in my mind. OTOH they were terrible for deployment: user hostile and expensive.
Also a lot of programming is defensive: against poor or inexperienced developers including oneself. When you can casually change anything you can get into trouble, either by breaking things or by simply embedding unexpected dependencies your code.
We had a pile of hacks but integrating changes took all the productivity of Smalltalk away.
However, tools like Envy/Developer fixed a lot of it. It still didn't fix everything but at least sorted code integration and source code versioning. Not sure if the product still exists though.
I loved using Smalltalk but in a team environment its useless and keeping your code disentangled from the underlying environment is a nightmare.
In addition, lisp programs (at least in these environments) don’t have “main”. I think it’s no big deal to start a program as “(foo)” but that’s surprisingly user hostile.
I worked with someone (who shall remain nameless) who ran in the same image for several years. There were random state variables scattered in his environment that affected the performance of his system in unreproducable ways.
But they have similar mechanisms.
In Symbolics Genera 'programs' are called 'activities'. They can be started by keyboard shortcut, command, an application menu or by a general function, where the activity is an argument. Usually each 'activity' runs a command loop.
Additionally images have named lists containing functions, which are executed on certain event. For example if an image starts, a 'cold boot' list will be executed. If one has registered starting application programs (activity) - remember activities have names like editor, listener, mail client - they will be started by the operating system after a boot.
If a user logins on a Lisp Machine an init file gets executed. That init file can also contain general forms which start activities.
Just yesterday I stumbled into `Out of the Tar Pit` which is turns out to be a very life-changing for many people and was thinking, why I haven't seen it before in my career