I think we need many different little languages and a substrate “language” (kernel) to bolt them all together. Note that, in electronics, there is/was something called “design rules” which is something more-than-type. In web-site design, one uses “input validation” which is like type-checking but on a very per-project basis. It would be nice to be able to bolt design-rule checkers together using a palette of existing components. Again, it seems that one should want a palette of components to help build up design rule checkers and completely different palette of components to build up actions. I would expect to use different “syntaxes” for each concern and would expect to use IDE layers to deal with each kind of issue separately then let the IDE automagically stitch them together. This is just another way of saying “I would like to use a different language (SCN in my words) to deal with each kind of issue”. Would I use text-based SCNs exclusively? No. But, for text-based SCNs, I would use Ohm-JS and for diagrammatic SCNs I would start by using draw.io. Both kinds of syntaxes are “easy” now, so there is no reason not to build project-specific SCNs. We have been indoctrinated to believe that “one language to rule them all” GPLs is the way to go. I don’t agree. duplicated in https://publish.obsidian.md/programmingsimplicity/2023-05-31-Bolting+Little+Languages+Together

I really want to see a resurgence of little languages too! I was wondering what you think this “substrate” language looks like and how these small language compose and interact together?

I have held this point of view for a few years as well. And started playing with Racket to try it out in practice. Today I am less convinced that this is a good approach. In the meantime, I discovered the importance of good and language-aware tools. Not just syntax-aware editors, but in particular debuggers. Either you need to adapt a debugger to every single little language, or you have to compile those languages to some unified substrate in a way that makes debugging at the substrate level possible in practice. I haven't seen either approach work so far.

I blame the tools not the approach. Deep down, I blame this on the fact that all languages are the same - they are all based on a single Pattern - synchrony. (Longer response pending...)

It's possibly a tooling issue, but then, pragmatically speaking, if I can't build those tools myself (if only for lack of resources) and nobody else is doing it, then I am stuck.

Looking forward to the longer response — how different do you see these languages being, especially semantically? While some programmers seem to be able to adjust between (existing) languages quickly, working in a shop that uses JavaScript and PHP — it's a real struggle for others. There are a surprising amount of differences that go way beyond syntax (i.e. JavaScript's reference semantics vs. PHP's copy-on-write) that can trip people up in surprising ways, and that's between two languages that are relatively similar. Part of the issue is, as you said in a previous comment, we are smashing together coding and architecture and design, etc. Are you suggesting that any given person or team would only need a single SCN? (Except for the "integrators" or whatever they'd be called?)

Little Networks and Little Languages, a collection of point-form notes “as is”. I am using Kinopio (hint: Kinopio looks weird and foreign at first, but is well-suited to riffing on ideas) https://kinopio.club/little-languages-qR324zwZ6Kvh390StgXMF