How to choose a substrate to build on, and what foundations you need.
I'm getting some great feedback on the FOSDEM "Starting Over" talk. I will re-record it soon and put it on Youtube.
A handful of people on HackerNews got it, although as expected, most didn't, or flicked through the slideshow and started arguing. There was a much more interesting set of responses on Lobsters.
This post grew out of a reply to a comment there.
The commenter said that they enjoyed the talk and had not encountered Oberon before, but they did not understand why I'd picked Dylan as an alternative to Smalltalk... and had I considered building in Javascript in the browser instead?
Part of the plan is to make something that is easy and fun. It will be limited at first compared to the insane incomprehensible unfathomable richness of a modern *nix or Windows OS. Very limited. So if it is limited, then I think it has to be fun and accessible and easy and comprehensible to have any hope of winning people over.
Lisp is hard. It may be the ultimate programming language, the only programmable programming language, but the syntax is not merely offputting, it is profoundly inaccessible for a lot of ordinary mortals. Just learning an Algol-like language is not hard. BASIC was fun and accessible. The right languages are toys for children, and that's good.
Today, I have met multiple professional Java programmers who have next to no grasp of the theory, or of algorithms or any comp-sci basic principles... but they can bolt together existing modules just fine and make useful systems.
Note: I am not saying that this is a good way to build business logic, but it is how a lot of organizations do it.
There is a ton of extra logic that one must internalize to make Lisp comprehensible. I suspect that there is a certain type of mind for whom this stuff is accessible, easily acquired, and then they find it intuitive and obvious and very useful.
But I think that that kind of mind is fairly rare, and I do not think that this kind of language - code composed of lists, containing naked ASTs - will ever be a mass-market proposition.
Dylan, OTOH, did what McCarthy originally intended. It wrapped the bare lists in something accessible, and they demonstrated this by building an exceptionally visual, colourful, friendly graphical programming language in it. It was not intended for building enterprise servers; it was built to power an all-graphical pocket digital assistant, with a few meg of RAM and no filesystem.
Friendly and fun, remember. Accessible, easy, simple above all else. Expressly not intended to be "big and professional like GNU."
But underneath Dylan's friendly face is the raw power of Lisp.
So the idea is that it gives you the best of both worlds, in principle. For mortals, there's an easy, colourful, fun toy. But one you can build real useful apps in.
And underneath that, interchangeable and interoperable with it, is the power of Lisp - but you don't need to see it or interact with it if you don't want to.
And beneath that is Oberon, which lets you twiddle bits if you need to in order to write a device driver or a network stack for a new protocol. Or create a VM and launch it, so you can have a window with Firefox in it.
[Re Javascript]
Oh dear gods, no!
There is an old saying in comp sci, attributed to David Wheeler: "We can solve any problem by introducing an extra level of indirection."
It is often attributed to Butler Lampson, one of the people at PARC who designed and built the Xerox Alto, Dolphin and Dorado machines. He is also said to have added a rider:
"...except for the problem of too many layers of indirection."
The idea here is to strip away a dozen layers of indirection and simplify it down to the minimum number of layers that can provide a rich, programmable, high-level environment that does not require users to learn arcane historical concepts such as "disks" or "directories" or "files", or "binaries" and "compilers" and "linkers". All that is ancient history, implementation baggage from 50 years of Unix.
The WWW was a quick'n'dirty, kludgy implementation of hypertext on Unix, put together using NeXTstations. The real idea of hypertext came from Ted Nelson's Xanadu.
The web is half a dozen layers of crap -- a protocol [1] that carries composite documents [2] built from Unix text files [3] and rendered by a now massively complex engine [4] whose operation can be modified by a clunky text-based scripting language [5] which needed to be JITted and accelerated by a runtime environment [6]. It is a mess.
It is more or less exactly what I am trying to get away from. The idea of implementing a new OS in a minimal 2 layers, replacing a dozen layers, and then implementing that elegant little design by embedding it inside a clunky half-dozen layers hosted on top of half a dozen layers of Unix... I recoil in disgust, TBH. It is not merely inefficient, it's profane, a desecration of the concept.
Look, I am not a Christian, but I was vaguely raised as one. There are a few nuggets of wisdom in the Christian bible.
Matthew 7:24-27 applies.
“Therefore, whosoever heareth these sayings of Mine and doeth them, I will liken him unto a wise man, who built his house upon a rock.
And the rain descended and the floods came, and the winds blew and beat upon that house; and it fell not, for it was founded upon a rock.
And every one that heareth these sayings of Mine and doeth them not, shall be likened unto a foolish man, who built his house upon the sand;
and the rain descended, and the floods came, and the winds blew, and beat upon that house; and it fell, and great was the fall of it.”
Unix is the sand here. An ever-shifting, impermanent base. Put more layers of silt and gravel and mud on top, and it's still sand.
I'm saying we take bare x86 or ARM or RISC-V. We put Oberon on that, then Smalltalk or Lisp on Oberon, and done. Two layers, one of them portable. The user doesn't even need to know what they're running on, because they don't have a compiler or anything like that.
You're used to sand. You like sand. I can see that. But more sand is not the answer here. The answer is a high-pressure host that sweeps away all the sand.
A handful of people on HackerNews got it, although as expected, most didn't, or flicked through the slideshow and started arguing. There was a much more interesting set of responses on Lobsters.
This post grew out of a reply to a comment there.
The commenter said that they enjoyed the talk and had not encountered Oberon before, but they did not understand why I'd picked Dylan as an alternative to Smalltalk... and had I considered building in Javascript in the browser instead?
Part of the plan is to make something that is easy and fun. It will be limited at first compared to the insane incomprehensible unfathomable richness of a modern *nix or Windows OS. Very limited. So if it is limited, then I think it has to be fun and accessible and easy and comprehensible to have any hope of winning people over.
Lisp is hard. It may be the ultimate programming language, the only programmable programming language, but the syntax is not merely offputting, it is profoundly inaccessible for a lot of ordinary mortals. Just learning an Algol-like language is not hard. BASIC was fun and accessible. The right languages are toys for children, and that's good.
Today, I have met multiple professional Java programmers who have next to no grasp of the theory, or of algorithms or any comp-sci basic principles... but they can bolt together existing modules just fine and make useful systems.
Note: I am not saying that this is a good way to build business logic, but it is how a lot of organizations do it.
There is a ton of extra logic that one must internalize to make Lisp comprehensible. I suspect that there is a certain type of mind for whom this stuff is accessible, easily acquired, and then they find it intuitive and obvious and very useful.
But I think that that kind of mind is fairly rare, and I do not think that this kind of language - code composed of lists, containing naked ASTs - will ever be a mass-market proposition.
Dylan, OTOH, did what McCarthy originally intended. It wrapped the bare lists in something accessible, and they demonstrated this by building an exceptionally visual, colourful, friendly graphical programming language in it. It was not intended for building enterprise servers; it was built to power an all-graphical pocket digital assistant, with a few meg of RAM and no filesystem.
Friendly and fun, remember. Accessible, easy, simple above all else. Expressly not intended to be "big and professional like GNU."
But underneath Dylan's friendly face is the raw power of Lisp.
So the idea is that it gives you the best of both worlds, in principle. For mortals, there's an easy, colourful, fun toy. But one you can build real useful apps in.
And underneath that, interchangeable and interoperable with it, is the power of Lisp - but you don't need to see it or interact with it if you don't want to.
And beneath that is Oberon, which lets you twiddle bits if you need to in order to write a device driver or a network stack for a new protocol. Or create a VM and launch it, so you can have a window with Firefox in it.
[Re Javascript]
Oh dear gods, no!
There is an old saying in comp sci, attributed to David Wheeler: "We can solve any problem by introducing an extra level of indirection."
It is often attributed to Butler Lampson, one of the people at PARC who designed and built the Xerox Alto, Dolphin and Dorado machines. He is also said to have added a rider:
"...except for the problem of too many layers of indirection."
The idea here is to strip away a dozen layers of indirection and simplify it down to the minimum number of layers that can provide a rich, programmable, high-level environment that does not require users to learn arcane historical concepts such as "disks" or "directories" or "files", or "binaries" and "compilers" and "linkers". All that is ancient history, implementation baggage from 50 years of Unix.
The WWW was a quick'n'dirty, kludgy implementation of hypertext on Unix, put together using NeXTstations. The real idea of hypertext came from Ted Nelson's Xanadu.
The web is half a dozen layers of crap -- a protocol [1] that carries composite documents [2] built from Unix text files [3] and rendered by a now massively complex engine [4] whose operation can be modified by a clunky text-based scripting language [5] which needed to be JITted and accelerated by a runtime environment [6]. It is a mess.
It is more or less exactly what I am trying to get away from. The idea of implementing a new OS in a minimal 2 layers, replacing a dozen layers, and then implementing that elegant little design by embedding it inside a clunky half-dozen layers hosted on top of half a dozen layers of Unix... I recoil in disgust, TBH. It is not merely inefficient, it's profane, a desecration of the concept.
Look, I am not a Christian, but I was vaguely raised as one. There are a few nuggets of wisdom in the Christian bible.
Matthew 7:24-27 applies.
“Therefore, whosoever heareth these sayings of Mine and doeth them, I will liken him unto a wise man, who built his house upon a rock.
And the rain descended and the floods came, and the winds blew and beat upon that house; and it fell not, for it was founded upon a rock.
And every one that heareth these sayings of Mine and doeth them not, shall be likened unto a foolish man, who built his house upon the sand;
and the rain descended, and the floods came, and the winds blew, and beat upon that house; and it fell, and great was the fall of it.”
Unix is the sand here. An ever-shifting, impermanent base. Put more layers of silt and gravel and mud on top, and it's still sand.
I'm saying we take bare x86 or ARM or RISC-V. We put Oberon on that, then Smalltalk or Lisp on Oberon, and done. Two layers, one of them portable. The user doesn't even need to know what they're running on, because they don't have a compiler or anything like that.
You're used to sand. You like sand. I can see that. But more sand is not the answer here. The answer is a high-pressure host that sweeps away all the sand.