[mikewarot]

The key thing about those type of systems was the ability to reach down into the system and edit the code of the system currently in operation.

Here's a demonstration of Symbolics Open Genera (TM) 2.0, demonstrated running in a virtual machine. It is noted by the author of the video in the first minute or so that even in emulation, it is much faster than the original machines. - https://www.youtube.com/watch?v=o4-YnLpLgtk

Oberon also had a similar attribute, in that they kept the names of functions to operate on objects visible.

The same was true of the Canon Cat, Hypercard, Ted Nelson's Xanadu project, Smalltalk, and a number of other early computing systems.

The main feature common to all of these systems is that they all preserve context. In Genera, Oberon, Canon Cat, Hypercard, and SmallTalk the source was always available. (as far as I know). In Xanadu, the main functionality of the web was present, but it wouldn't allow the broken links (and lost context) that now plague the web.

I think a future platform could take code in a number of languages, compile it to an abstract syntax tree, but preserve the context required to recreate the source. In fact, it's reasonable that you could import a routine in a language you aren't familiar with, and reverse the compilation to get it expressed in an equivalent (but less elegant) form in your language of choice, along with the original comments.

There's nothing stopping an open source project from taking elements of these existing systems and moving forward from that basis. It might be profitable to include ideas such as Coloring of the Source text to label intent, such as in ColorForth.

Also, consider "Literate Programming" - Literate programs are written as an uninterrupted exposition of logic in an ordinary human language, much like the text of an essay, in which macros are included to hide abstractions and traditional source code.

You could also add the ability to store graphics and other data along with the source code.

Of course, if you are required to run code you didn't write and don't trust, your operating system must provide means to run it only against the files or folders you wish to let it operate on. The principle of least privilege needs to be supported at a fundamental level. This is one of the big shortcomings of the Unix model.

Sorry it was a bit of a ramble, but this seemed to be a call for ideas, so I ran with it.

PS: In the past, getting your vision of Computing required building a machine, and then getting it manufactured. Now it just requires that you make it work in a VM, Raspberry Pi, or web browser window.

It is MUCH easier to try out and/or create alterative systems now that it has ever been in the past.

[pjmlp]

You can get a bit of that Oberon experience on Windows via PowerShell, .NET and COM.

Now if Windows team would get over their COM worship, it would be even better.

[jodrellblank]

Why would you reach down into the system and edit the code of the system currently in operation? Because it doesn't already do what you want. Isn't it a bit pathalogical to start by building a system which doesn't do what you want, then building in the tools to let you fix it, so you can use those make it do what you want? Why not skip all the middlemen and make what you want in the first place?

If you arrive at "we can't do that because everyone wants different things", you're in this weird place where you can't build one system to suit everybody so as a fix for that you will ... make one dev system to suit everybody? Why is that going to work out any better? If people are going to have to build the system they want anyway, why not skip all the middlemen and leave people to build the system they want from scratch their own way?

"Well we can't do that, having to build everything from scratch is hard, people don't want that. And we don't know what people want (and can't be bothered to ask) and won't try to build it for them, but we can give everyone Our Blessed System and Our Blessed Tooling which we presume they will want to use, while we abandon them to have to build what they actually want using it". It's patriarchal and preachy and still unhelpful. The kind of person willing to put up with your system and language and its edge-cases and limitations instead of making their own, is quite likely the same person who would have put up with your spreadsheet and its edge-cases and limitations if only you'd built it.

It's the "all progress depends on the unreasonable person" meme; you need the person who can't tolerate a system which isn't perfect and demands to be able to tune it to their perfection, but is simultaneously fine with a customizable-system built by someone else for someone else's ideas. Then you say "ah but they can rebuild as much of the system as they want!" they're now having to build it themselves from scratch but based on what you built, which is even more work for them, not less.

And the whole thing says little about working with other people/organizations; everyone building their own thing isn't great for that. One could argue that Microsoft did a lot of good for the world by strongarming companies into .doc and .xls formats for interchange, in a similar way that HTTP/HTML did (but more tyrannically). Microsoft-Word-documents-over-email should probably go down in history as one of the big enablers of distributed human organization, like the telephone. Moreso than SMTP alone or TCP/IP alone which enabled computers to connect, not people. More than HTTP/HTML which ordinary people can't use without setting up a webserver and publishing first.

> "I think a future platform could take code in a number of languages, compile it to an abstract syntax tree, but preserve the context required to recreate the source. In fact, it's reasonable that you could import a routine in a language you aren't familiar with, and reverse the compilation to get it expressed in an equivalent (but less elegant) form in your language of choice, along with the original comments."

Would that even work? What about "code is primarily for people to read"; loss of indentation, of alignment, of variable names if you're changing language with different variable naming rules, loss of separate files/folder/module-context of how it was built in the first place, and loss of idiomatic patterns from changing one language to another, or to languages with different scoping behaviour. Look at the image in The Article for the square root code[1], can you decompile the syntax tree for a language which doesn't have a complex number type? What about one which doesn't have a short-float for the result, or has different floating point precision assumptions? What does "F and I2 need to be regular-heap-consed to avoid the extra-pdl lossage" mean for JavaScript or Python or Clojure? What's the magic 0.4826004 for, without any comments next to it?

And that square root function alone is a screenful of code, the very idea of being able to rebuild the system to your desires falls out the window if it's going to take you a lifetime to do that, and if not then we're back to my original paragraph where you're building a massive programmable system so someone can tweak one or two tiny things occasionally, which seems hella overkill.

> "Of course, if you are required to run code you didn't write and don't trust, your operating system must provide means to run it only against the files or folders you wish to let it operate on. The principle of least privilege needs to be supported at a fundamental level. This is one of the big shortcomings of the Unix model."

The XKCD comment that malicious code can ransomware all my documents and upload them to the cloud, but at least it can't add a new printer. One of the big shortcomings of the principle of least privilege is the effort of carefully and precisely describing the privileges needed - see the complexity and quantity of SELinux rules for a whole system. Even then you get immediately to the point where "my editor can edit all my text files" and that's now a large blast radius.

[1] https://cdn.substack.com/image/fetch/w_1456,c_limit,f_auto,q...

[skissane]

> Why would you reach down into the system and edit the code of the system currently in operation? Because it doesn't already do what you want. Isn't it a bit pathalogical to start by building a system which doesn't do what you want, then building in the tools to let you fix it, so you can use those make it do what you want? Why not skip all the middlemen and make what you want in the first place?

Because what you want is not set in stone for all time. Needs and desires change, and often what you think you want is different from what you actually want, but discovering that can take time.

I spend so much time trying to work out things like "when I click this button in the UI, what does that actually end up doing in the backend?" I wish I could right-click on a UI element and it would take me directly to the backend code which actually implements it. And a system like that should be much quicker to change – it should be much quicker for a new developer to get up to speed with it and start implementing things, rather than spending days (even weeks) trying to understand how it all fits together.

[mikewarot]

>One of the big shortcomings of the principle of least privilege is the effort of carefully and precisely describing the privileges needed - see the complexity and quantity of SELinux rules for a whole system.

SELinux was a terrible thing to inflict upon the world. Capabilities are more like cash in your wallet.... you pick what you want to use in a transaction, and hand it over... never worrying that the rest of your money would somehow get siphoned off later.

Static rules aren't what capabilities are about. Run this program, oh.. it wants a file? Here... it can have this. The default access would be nothing (or in a more modern context, it's config file) The program wouldn't directly access files, but would use dialog boxes to do I/O, or you could drop them in via batch, etc.