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 @stevekrouse https://www.inkandswitch.com/end-user-programming/ by @szymon_k https://malleable.systems by @J. Ryan Stinnett 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, @Tudor Girba @Konrad Hinsen. 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 😬 [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

I am not aware of anything like that that has actually been tried on a large enough scale. The closest I have seen proposed recently is https://playb.it/. I suspect that in today's economic environment, it is not obvious how to develop such a platform commercially, nor as an Open Source commons, but I'd love to be proven wrong.

a web browser? 🙃

don’t have a video off hand but I believe Jonathan Blow has talked about this as well. The pitfalls of universally reference-able packages & package versions in an OS environment, vs each one just bringing their requirements with them

The idea of packaging apps with all their dependencies has been proposed and implemented many times. What's new in @Kartik Agaram proposal is "long with all the tools needed to edit, build and run them". That implies full transparency, which is very far from how we use containers nowadays.

PICO-8 is a great point. It has editing tools and everything right within the same 128x128px screen. The Android development environment is a thought-provoking answer as well. .apk is a single file. Can you run it just by passing it to the Android environment? Even if it opens in the IDE, hitting one keystroke to get to the simulator doesn't seem such a big deal. Seems akin to the Borland tools from the '90s which were pretty nice. Which has me wondering what other requirements I need to add 😛 I think a key piece is: the only way to run the app is from within the development framework. It's impossible to run in isolation. Zooming out to a whole computer is a way to trivially satisfy these criteria. Hence my attempt to start out focused on a single app that the end-user is using.

I've read something similar about scratch, students don't like to learn with a toy environment since they know professionals don't use that. They want to learn "the real stuff"

I know the feeling. When I learnt to program the most important thing was that my program had a custom icon and appeared under Programs on the Start menu - like Real Software. What it actually did not so important.

I think DOS-like (https://github.com/mattiasgustavsson/dos-like) fits into this also. It comes with a C compiler (tcc)

@Kartik Agaram Thanks for sharing this MVP sketch! Indeed as you guessed, it overlaps with bits and pieces of ideas I've had for how we might achieve more malleability. 😄 I'm not aware of any efforts that have actually built this kind of "tools packaged with apps" scheme on the scale you're describing... While we surely agree it's perhaps not the most elegant approach, it would at least bring some tools closer to hand for more people, so it does seem like a step worth trying. (Of course, the tools this plan would provide are still meant for expert programmers, so it doesn't much help other kinds of people quite yet, but anyway, it's still more than exists today.) It would be ideal if such an approach could understand and automate as much of the build pipeline as possible... perhaps in your model, that's handled by the integration with a common framework? Capturing those data flow dependencies so that making a change in the tools can get as close to becoming live with as little human work as possible seems like it would bring a large benefit to user modification.

How about « no build pipelines »?

Ah sure, that's one way to remove the issue. 🙂 I am perhaps mentally blending my own ideas of meeting existing apps where they are (which may require contending in some way with build pipelines) vs. a wholly new framework which perhaps outlaws them from the start.

See The build is always broken. I think "no build pipelines" should be the default for anything aimed at end users. That doesn't exclude exceptions, in well-motivated cases.

@Kartik Agaram This sounds like Squeak/Pharo running baremetal on a machine (like the original Smalltalks)? Alan Kay has often mentioned that Squeak contained all the tools to build a better version of itself - basically a kernel of an object-based VM, plus a set of classes/objects that encompassed the system they wanted to build (a personal computer for all ages). I've been slowly investigating how easy it would be to run Squeak directly on a raspberry pi or other small computer (maybe with a minimal linux system to support some hardware drivers)

Yes, I've been enamored lately by the Smalltalk way. As I said to a friend recently, I no longer think God programs in Lisp. Smalltalk seems a more likely answer.

@Kartik Agaram have you seen Stephen Kell's talk "The Smalltalk Hiding in C"? I think it's very relevant to this thread

Is it maybe a dead-end to tie it to a specific language? I mean, as long as we're talking about writing an entire new programmable environment, it seems to me that creating some kind of easy-to-use, highly-documented API would be the ideal route, and then you can use any language you like. Otherwise you're going to have to do it all over again when the language you've written it for goes out of date/style/use.

@Kartik Agaram Well, as Alan Kay has often said in his talks/emails, Smalltalk was great for its time 30-40 yrs ago, but today we should do better by programming the whats instead of the hows. That also matches God's proclamation "Let there be light" 😉

@Naveen Michaud-Agrawal in a lot of ways we should have a better smalltalk by now rather than the tedium imposed by the "modern" options. Rust is arguably the only real innovation in language in the last few years and it's only freed us of trying to determine when to

free

and language designers from piling more trash onto the garbage collection design.

Oh Processing is an extremely successful version of this btw.

Thanks for reminding me of Processing! This does seem awfully close. Just start with a page like https://hello.processing.org/display/#@-KxziqduWvnsowVNxaPv and reduce the friction to opening up the program in the editing environment. Right now I have to download the code, open it somehow, copy it to clipboard, open tutorial, switch to editor, paste. (There's also the sandboxing component, which isn't really exercised here. But I think my MVP was too ambitious, as often happens.)

The one thing about processing is it is harder to modify the environment itself, I like the philosophy behind Mu, MakePad and Picotron (https://www.lexaloffle.com/picotron.php) where you get most of the code of the environment as part of the environment and are encouraged to modify for your needs

I hadn't seen Picotron before, thanks. I thought Pico-8 isn't open source? Is Picotron different? Otherwise I don't follow what you mean by getting most of the source of the environment.

Picotron isn't released yet so I don't know many details, and I'm not sure if Joseph White even knows at this point. It will likely not be fully open-source, but he says most of picotron is made in picotron and it's highly customizable/hackable. So I imagine most of the Lua code shipping with the environment with the core exe/C code being closed source

I see, so it sounds like it'll be different than Pico-8 in that regard. Exciting! Also cool that it's in Lua. I'm just starting to play with it for multiple reasons (random tinkering around this thread, learning Arcan)