All of these projects seem to be reaching for an integrated programming language / operating system like the Lisp machines of yore. It was before my time, so I never got to use one, but from what I have read, they were quite amazing to use.
Smalltalk also did this. These days my impression is the most active tendril is https://pharo.org/.
What I find especially interesting about that relative to this Python distro is that the Pharo executable runs in a host OS (e.g. whatever your daily driver is) and can maintain different image files for different Pharo system states. So not only do you have the integrated language/OS (which is very cool on its own), but you also have something that feels like Docker containers.
And it even goes beyond containers because those image files really are the state of the system at the time they're saved, which means you can ask for that file in a bug report and get guaranteed bug reproduction, which is pretty incredible.
No -- the old Lisp machines were inspired by Smalltalk! A complete environment with persistent heap images was one of the innovations brought by Xerox PARC's Smalltalk research.
Actually Smalltalk was earlier inspired by Lisp. Lisp already had persistent heap images in 1960 in the first implementation.
A development environment with persistent heap images was already provided by BBN Lisp in the late 60s. The in-image structure editor for BBN Lisp came in 1968. A "make" like feature came in 1971.
Xerox then took BBN Lisp and developed it as Xerox Interlisp from 1972 onwards. Masterscope then was a source code management system in 1973. 1974 it ran on the Alto with a microcoded implementation. 1976 Interlisp got a window system and a virtual machine specification.
Xerox Interlisp-D then ran on the same hardware (the D-machines) as Smalltalk -> it was another operating system option. It basically appeared at same time as Smalltalk 80. Smalltalk and Interlisp were developed by different teams (with some overlap), in the same company and also for the same hardware.
The MIT Lisp Machines were inspired by the Xerox systems, but were different hardware with a slightly different target audience and different approaches in software development. Xerox was a commercial company with PARC as a research lab. The MIT AI lab was a well funded research lab at an university (MIT). Their more powerful systems were mainly developed for their AI researchers.
For the last month or so I was thinking it would be awesome to have a desktop with a lot of the most common GUI utilities written in python so that average programmers could have a stab at customizing it for their needs. But this is too much work for me and I'm kind of following a different dream right now.
An easy modified Desktop Environment written in Python was one of the goals of the "One Laptop per Child" project. They succeeded[1], it's now separate from the hardware and can run on anything from your phone, raspberry pi, regular computer and the OLPC-machines.
(Another goal was better sandboxing bitween apps. Their project was called Bitfrost and was in many ways the first step towards flatpak that we use today)
Nobody seriously goes into things intentionally making them obtuse.
The current complexity is a product of poor design from a sincere effort for simplicity.
Trying to be easy, lightweight, simple, is the silver bullet way to create a mess and it's why when you see those words in software names it's always just a sprawling stochastic tangle.
The easiest way to avoid the mess is to make things dumb.
I think a few of us thought about that. It seems the "Hello" System[1] wants to got that way. Write most applications in PyQt, have the source somewhat accesible (I would think a direct menu item or button in the "About" dialog would improve on the UX of that, though)
Not sure whether I'd personally go with PyQt. (Or a post-1.x Python feature set in general). What would be neat is some kind of "My first Github" social coding platform, where you could push your homegrown new features, discuss & share them.
I'm going to look at it again. It looks like they weren't forwarding keyboard interrupts to executables gracefully. But instead capturing them themselves.
I haven't needed to intercept ctrl-c and forward it on in a program ever, but it seems like that should be a basic thing a shell should do easily enough.
It also has a C64-inspired interface to a REPL (Lua, yay!) - and it wouldn't need a lot of effort to expose more services to the VM for programmers to use in building better apps.
Would be cool to have a sophisticated desktop environment entirely based on Lua scripting .. especially with a built-in editor. The fulfillment of a lot of dreams.
Ooh, nice; I had half a mind to do something like this a few years ago (called PyOS), but never had the time. My rationale was that getting python code running on boot on a raspberry pi required learning about Linux sysadmin, rather than just coding (which, for high-school students, is important to make it quick and easy to see results). Micropython does this - drop a main.py and/or boot.py and it runs on boot; or you have a repl. Why not on a fully fledged computer?
Like MicroPython [0]? I use that for a few hobby projects.
It works fairly well for all the little things, like the weather station I built with it. Being able to drop to REPL and rewrite functions on the fly is a little magic, too.
There were similar ones done with Perl:
https://www.foo.be/docs/tpj/issues/vol5_2/tpj0502-0009.html
https://blog.sudobits.com/2012/08/18/perl-linux-a-linux-dist...
All of these projects seem to be reaching for an integrated programming language / operating system like the Lisp machines of yore. It was before my time, so I never got to use one, but from what I have read, they were quite amazing to use.