[October 16th, 2021 9:44 PM] ak: Has the utterly brutalist approach to end-user programming ever been tried? Just forcibly package up apps with all their dependencies, along with all the tools needed to edit, build and run them?

For a while now, we've had this notion of "end-user programming" in this community: the ability to modify software while we use it.

https://futureofcoding.org/episodes/033.html by <@U5TCAFTD3> https://www.inkandswitch.com/end-user-programming/ by <@UF6RLAL7J> https://malleable.systems by <@UML4ZEKDK> is also relevant

Here's a sketch for an MVP that provides this experience in the bluntest, most obvious way possible: • Download a framework packaged as a single file, including all necessary dependencies. You download it from an https URL, and that's it, you're good to go. • It only supports *nix platforms on desktop machines. Linux, BSD, maybe Windows Subsystem for Linux. Macs are explicitly out because they're basically not an open platform anymore[1]. And we're going to need an open platform for the sorts of stuff we're planning below. • You can install arbitrary apps from arbitrary sources that run atop the framework. The apps are in interpreted languages and always come with source code. • When you run an app, it always opens on the app first. This is important. There's no REPL or IDE front and center. The interaction modes are whatever the app chooses. • When you run an app, the framework always shows the privileges it has in some consistent part of the screen. The vocabulary and enforcement of those privileges is the major responsibility of the framework. Needing it to be always visible is why you need a desktop machine with a large screen. • The app can ask for privileges, but the framework gives you the ability to lie to the app. Here's a simulated network environment that looks offline or has these honeypots. Here's a simulated file system with almost nothing or a few honeypot files. (Inspired by the Arcan project: https://www.divergent-desktop.org/blog/2020/08/10/principles-overview/#p6) • While running any app, the framework always provides a consistent set of primitives for interacting with the interpreted sources for that app. Imagine a button in the corner that flips a Hypercard over to open an editor on its sources, or something like that. Once you're in the editor you can modify it, run it, get syntax errors, test failures, etc. The editor and build environment themselves are implemented in the framework; for the MVP we'll assume we don't need to support modifying the framework. I wonder how far Glamorous Toolkit is from this sort of experience, <@UE1JQM9HQ> <@UJBAJNFLK>. On one hand it massively over-delivers on the editing framework. The sandboxing stuff is a new frontier with lots of open-ended questions on the best experience to avoid confusing people before they understand how things work.

I'm also thinking about building on something less ambitious for an MVP, like libSDL atop femtolisp or LuaJIT. Maybe also JavaScript :grimacing:

[1] Like, it's great Apple that you eliminated vectors for malicious apps with all the restrictions on installing software. But I already had a perfectly good and healthy and functional relationship with the folks who provide gdb. When you prevent me from installing gdb, that's not cool. It's good to want to protect people from dysfunctional relationships. But to require all relationships to go through a single point is not. /rant