I think part of it is that with more resources, we can become more “careless,” which leads to bloat. Really clean diagrams!

What we have seen happening over the last 40 years is growth and complexification of both hardware and software, in parallel with increased resource consumption. Not very different from what we have seen in other branches of technology. Or elsewhere in society, law for example. Some people believe that growth and complexification are natural processes of complex system, much like entropy increase in thermodynamics. That's speculation so far, but not unreasonable.

What I am more interested in is stories of simplification, or preservation of simplicity. Successful fight against the supposedly natural tendency towards complexification.

I approach this in 2 steps:

• understand
• (re)invent

[Maybe this is a form of first-principles-thinking?]

This is mostly step (1). Drawing diagrams makes me think harder about how to explain what I observe. I'm sharing the diagrams in the hopes that others might be interested and might be inspired and might kibbitz. Maybe the most striking conclusion thus far is that progress and complexification has been one-sided - aimed almost entirely at satisfying developers' needs. The Production Engineering step is missing from our workflow. We go even so far as to think that children need to learn to develop code using this workflow. Another observation is that the great minds of 1950 were faced with new, poorly-understood hardware, then devised ways to use it. We (the royal we) are at this point again: our problem space is quite different from that of 1950. In 1950, thinking of using more than one CPU was too co$t prohibitive. Today, we can have bowls full of the things. How should our workflow and tools be re-invented? Obviously, we want to use what we already have, instead of starting from scratch again. If we take the view that the existing stuff is just "assembler" for something new, what can we come up with? Another observation is that "sequential programming languages" aren't up to the task of solving today's problems (hence, we get a succession of gotchas, like callback-hell, await, package managers, version hell, etc.)

[first principles thinking: guitarvydas.github.io/2022/05/25/Programming-First-Principles-Thinking.html]

further ... programmingsimplicity.substack.com/p/simplicity?r=1egdky

We need to think again how to layer simplicity over top of this bag.

Exactly. But I doubt there are universal answers to this. I expect simple solutions or frameworks to be domain-specific.

I think innovation and creativity tend to emerge from constrained environments, so I guess some kind of way of forcing that could help.

Yeah, this feels like a solid case where learning recapitulates the historical path. Control flow is just syntactic sugar for GOTO statements; and function calls are just GOTO with a stack, as you suggest.

How to Design Programs has an excellent deep-dive on the whole learned wisdom here. I wish someone had pointed me at this book in undergrad.

htdp.org/2024-11-6/Book/partpreface.html#%28counter.%28figure._fig~3athe-design-recipe%29%29

I would hate to start learning scope and encapsulation with Python, honestly. But it's so convenient to write...

Ah thanks. I’ll take a look. Is the “spoiler” that there’s a reason it has to be this way, or is it worth exploring again?

I also thought a custom editor could reduce the amount of jumping around by just artificially inlining code temporarily.

That would be the scope and encapsulation, yes. I've been chewing on membrane computation one of the anti-encapsulation substrates; instead of a call graph, think reaction pathways.

I’ve not heard of membrane computation.

Strangely though I still think forward gotos make a lot of sense.

Or at least one way I think of it is as train tracks.

I'm really just going off of Isaac's generative poetics from his thesis. I thought he'd written about the 'bag of recombinable operators' as kind of the self-assembling Lego bricks, if the bricks were train tracks in your analogy.

Chapter 4 (Generators in the Wild) is probably closest to where you're going, visual programming abounds

escholarship.org/content/qt7qh3304v/qt7qh3304v.pdf

This is all new to me. Interesting. Basically, I’m trying to find new ways of teaching this. Or coming up with new tools to make it easier to visualize paths in languages that force this style?

—

I could probably draw/mock-up something.

Ah, you're trying to get at something visual, does this example of code folding do the thing?

mastodon.gamedev.place/@johnaustin/113845457744971617

Oh that’s cool. Not exactly only visual. It’s both “what would a textual language look like” and “how could I visualize what I’m doing more easily?” More like, you know how gpu code often unrolls loops? I’d like to be able to do that for code I’m reading. e.g. branches, function calls, struct/type definitions. As opposed to jumping to a different line or file. I think it’s already somewhat possible in existing editors, but not explored deeply as a default feature.

EDIT: oh when I said I could make a mockup, I meant that to explain what I’m thinking about, I could draw something,

Ye, visualization of compiler internals is juicy

• non-programmers learn to sequence steps of a recipe in a flat, numbered manner without using indentation
• when recipes (programs) get big, non-programmers resort to hot-links or node-and-arrow sketches that show data flow (not control flow), or, ... nothing, in which case they get into trouble (aka "... add more tabs to the spreadsheet ...")
• programmers use scoping and indentation of blocks of text because 1950s hardware could only handle text, and, because textual scoping was the best way to structure text to show that some actions were constrained
• when programs weren't so large, programmers laid out software in a non-indented manner (assembler, punch cards, BASIC)
• when programs became big, programmers just did "more of the same", wasting brain power on work-arounds like textual 'imports' statements and complicated namespacing tricks to enable them to continue using 1950s text-only notation
• this approach brought along baggage like "global variable" issues caused by visually-open notations like "{...}" that visually-closed notations like closed figures - boxes and ellipses - would have prevented, given that programmers had already learned how "not to colour outside of the lines" back in kindergarten
• unfortunately programmers continued to find work-arounds to text-only-based issues instead of simply switching to a more suitable representation

Super interesting. I wonder what the data flow recipe arrows look like though.

I’d be curious to experiment with the other representations more. Clearly we don’t have to use just text.

Hotlinks make sense.

data flow notations:

• what I call "0D" (node and wire stuff, scroll down the README to the pictures): github.com/guitarvydas/0D
• FBP: jpaulm.github.io/fbp

control flow notations:

• StateCharts: youtu.be/-6VzMNoHhtU
• drakon-editor.sourceforge.net (click on "learn more..." then the 3 tutorial PDFs)

[more will likely come to me in a few hours - keep prodding me if interested]

Thanks a lot for the references, and thanks for your patience. I imagine I appear as though I’m just walking along already-explored territory.

I don't know if anyone has said it straightforwardly... So I will share my simplistic answer. before whitespace mattered, it didn't. Brackets did. Brackets were hard to read the nesting level of, so people indented the contents. At which point the information conveyed by the indentation made the brackets visually redundant. But it's useful for parsing to know precisely if a new sub-scope is intended, so they made a new, deeper indentation level equivalent to an open bracket, and returning to a previous indentation level equivalent to as many closing brackets as required. As a learner, once I had the idea in my head that a deeper indentation level is a subscope, and the parser is counting spaces to see where it ends, my issues with whitespace went away. If I was trying to teach it, I would show the history. Good luck, and apologies if all that is obvious.

That all makes sense to me. I think part of this is teaching the concept of branching in the first place, in addition to the history.

Also, subjectively, I think it’s hard to read where a scope ends without an end delimiter. Easy to miss one. That’s the part I think something like Ruby does better.

In terms of inventing a new visualizer/extension to a simple IDE, I wonder if it’s worth playing with it.

Always. Play is what we are for. 👍

It’d be best if it led to something, but yes.

I share the desire to make a difference. I have always been most effective at that when I was playing. I think because the effort is sustainable. But if you want something to come of it, just share your prototypes here. You will think of things that are new, or validate other ideas. Either way we win.

That’s true. To be honest, I’d really enjoy an opportunity to work on a team towards a project or paper. It means a lot to get ideas out there.

The weirdest part is not knowing whether a marginal improvement on what the current models can do alone will be rendered obsolete by the next model, so people don't know where to invest their time and effort.

Yeah, indeed. I'm currently in a tiny team iterating very quickly, and even then I feel this. I imagine that for bigger projects it massively raises the uncertainty.

sounds like Electron

also redbean.dev actually

Redbean is a great example for technology that just lacks a good user interface for non-tech users. Imagine an Android app that would open a redbean file for editing, much like a .doc, and allow sharing (by mail or whatever other means). Plus the same for desktop.

Unfortunately I suspect that at least Android creates a few obstacles to such an endeavor.

Yeah my only experience with Electron is in building stand-alone apps, I don't know if it's easy to use it as a generic "platform" that I could use to open small-apps Web pages.

Redbean's pretty cool! Thanks for sharing. It's not exactly what I have in mind, but it's interesting in its own right

I had to think about this: developer.chrome.com/docs/capabilities/web-apis/file-system-access .. not yet commonly available but this might be what you are looking for

I'm working on smallweb.run, which works like an "internet folder".

Once you have it installed, you can create new websites by just creating a new folder and accessing it at <folder-name>.smallweb.localhost .

Apps are able to write data to their own folder, that you can then reuse in any other apps.

You can try it at demo.smallweb.live

The file system API would indeed be great for this. Maybe what I need is the browser 5 years from now 😛 I do feel like there's a tension in the design of the browser, between the traditional vision of browsing the Web, and the modern vision of using it for application distribution. I'm not sure how it will resolve over time.

Pwas are also quite neat. You can even integrate them with the native share sheet on android

developer.mozilla.org/en-US/docs/Web/Progressive_web_apps

Ah yeah true, I should look more into PWAs, it's not something I'm too familiar with as a dev.

Also, Smallweb is very cool, thanks for sharing!

Thanks! We also have a small community at discord.smallweb.run

(it's a smallweb app btw: gh.smallweb.run/discord/main.ts)

(I expected no less :D)

Are there any simple tools for developing simple PWAs ?

That's a nice use case for Cursor and see what it comes up with (I am playing around with cursor currently to see what it can help me create)

Do you have anything to share with Cursor regarding this already Maikel?

No not yet in regards to PWA, but the things that I have created are a basic but complete CRUD nextjs application including api (and database handling), authentication, styling. Also a synthetic data generation tool including data-type detection and various charts. Hopefully soon I'll show a "ghost text form control" that I am building with it for my own project. I am quite impressed with cursor so far. Not that it can do everything alone or that it's perfect. You still need to help it 😅

Cool, looking forward 🙂

val.town is a cool tool to build pwas. I've created this little middleware to convert any http val to a pwa: val.town/v/pomdtr/pwa, installable on ios / android

The last little app I made was with Vite/Svelte and used the filesystem API to save/open JSON files to persist the state. After you write a file, you get a handle that lets you keep writing to it as you make changes, so it works well for this.

If I didn’t like Vite so much (which ships with a server), smallweb seems like it would be a good alt.

A bit of searching around revealed that PWAs are much less complicated than I expected. See e.g. this tutorial.

my slight complain about PWA is the manifest has to be connected via a relative link I think, which then mandates a websever. I would love to be able to install a service worker from a single file binary. Maybe it can be done via DataURL? I have not actually tried hacking that.

maybe it is possible? Someone was thinking the same thing here github.com/GoogleChromeLabs/pwacompat/issues/27

though service workers are themselves on the edge of portability and then adding a hack on top makes me thing you will not be able to rely on it, but in my mind is a value add anyway so you just gotta use them for optional extras (e.g. system notifications, home screen installation, app icon)

Ah I definitely need to do more things with Val. I didn't event think to try it to build little apps 🤔 The thing that stops me is that I'm a big fan of local-first, but maybe I can put that aside in order to experiment

I think the main thing that would stop you from building local first app on val.town is the lack of websocket support. But some libraries like tinybase.org would work just fine

I don't think browsers will ever be powerful enough for systems related stuff, for security reasons it'll always impose friction/limitations. Also I don't think using loopback network is ideal, it's a hack. Something like tauri, but leaner, just providing a native interface/wrapper to the OS own webview seems a more robust way to build and distribute html-based apps. Not sure what's the best cross-platform way to transact data between the webview process and the app's backend without serialization

For me the main advantage of electron over tauri is that you can stream files directly to the browser, you can just use local file paths, while with tauri you have to handle it yourself, it's very inneficient the last I tested

What we usually want from browsers for offline apps is the GUI engine, so there's the possibility of making and distributing a fork of it intended to be an app platform

I also think you could pioneer some kind of portable hardware like a mini computer intended to be used as a sidecar (using display and input interfaces from a laptop/pc) but with all the goodies to be used as an app platform

Could be as small as a thumb drive

To clarify the hardware product idea, imagine it's a headless system with built-in storage and compute, but more focused than a general purpose computer. You'd need drivers, and you could use the driver package to act as a worker of sorts

@Xavier Lambein ive been making lots of local-first things with valtown. its not one or the other

Lu Wilson and so you use it to host code, and like store data in IndexedDB or automerge or something?

no i [just] use it for endpoints and store all the data locally too, usually localStorage. but the real thing that makes the difference is making it simple enough that other people can easily deploy and/or access it too. so that they don't rely on me or my hosting. eg logiverse.social

some more examples at todepond.com/lab

ahh yeah that makes sense, thanks 🙂

hmm, I wonder if RSS is enough for this or if it'd need to be push-based more like XMPP pubsub

Like this?

developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/How_to/Display_badge_on_app_icon

In the last startup I worked at we built an email inbox meets browser kind of thing, specifically for team collab apps (acapela.com). It was not a general solution to the need you're identifying, instead we hardcoded the hell out of it (e.g. re-using users' Notion session cookie to poll their internal API to fetch the notification count)