[ Disclaimer: I do not intend to convince anyone of the sweeping claims below, just enumerate some ideas that I have arrived at over the years, as a means of self introduction. ] Hi all! This is great community! I’m into Language Design and Language Design Philosophy. In general I think we have a lot to gain from:

A. Making our most fundamental abstractions simpler, more orthogonal and less complexity-inducing where applicable

B. Aligning our most fundamental abstractions to human perception where applicable.

[ You can stop reading here. That was the essential stuff; all the rest is ellaborations on the above and irrelevant personal stuff. Long boring text about stuff I find exciting follows… ] Considering that Programming languages have quite a long history and all the brilliant insights and abstractions uncovered so far, one might think that most essential stuff under A and B above would have already found their way into current languages/PLD tradition. As far as I can see, that is not really the case at all and this means that: 1. There is a lot to do in the field, and it can change the way we think about languages 2. It’s pretty much ortogonal to other progress related to Future of Coding, so small gains at the core abstractions can make other endeavors, like visual tools etc both more useable and more implementable. 3. The human language capacity runs on its own circuits in the brain and the work it performs does not count towards total cognitive load; it’s like an overpowered graphics gard -- all work that is a good fit for it and is pushed onto it is a great liberation of computational/cognitive resources for the CPU/general cognition. In short: Language Design and Language Design Philosophy can make a huge difference for programmers, end users and end user programmers alike. Many more possibilities remain unexplored than one might generally think. Currently, I am tinkering with a project where I apply language design thinking to Hierarchical State Machines, designing and implementing a UI markup language with a readily graspable runtime visualization. It might be possible to extract some state machine-related generalizations from the work by someone with CS skills. This is my personal perspective/motivation: I wanted to write programs and do stuff with CS for a long time, but dealing with some chronic stuff leaves me with brain fog and little energi to spare most days. Essentially, this means that I just cannot keep more than 20LOC i my head, and can’t really grasp big libraries and frameworks (I forget how to use them faster than I learn, and faster than I can look up stuff on stack overflow). So I pretty much despaired for a long time. But then I found that this also gives me some advantage; I can do something; namely, I can recognize the stuff that is small enough, logical enough and easy to think of enough. Such stuff I can actually keep working on even on bad days. That made State machines and statecharts an instant love. Highly glanceable notations and straight-forward composition also helps a lot (that’s what I’m designing for the UI markup). And stuff that are logical with minimal or no inconsistencies means less to think about; less to have to keep in mind; that is also immensely helpful, so that is why I hope someone can derive a formalism from the generalizations that I derive based of the needs of the design process. Frankly, It feels pretty uncomfortable to talk about what I do without having a working implementation and some loose ends in the theory. But hey, I might not even be able to finish the implementation by myself. So here’s maybe my vision: In the ways that turns out to be possible to me, with the tools and collaboration that I find, I want to make progress towards tools and languages that cover more of their inherent potential.

Welcome to the community. Your post was both emotionally and technically resonant for me — thank you for taking the time (and pushing through the discomfort) to write it. I'll be keen to see your work, whenever you're ready to share it.

The "chronic stuff" must suck, but I'm glad you've found those limitations can help inform better designs.* When at their best, Hierarchical State Machines do force a person to really externalize a system's behavior: you have to address all the possible transitions. One challenge is abstracting well: so that you can hide sub-systems that are in working order. * As a counterexample, my father had a colleague with the exact opposite skill. With savant-level working memory, he was entirely content at the terminal, just the terminal, using sed has his editor directly referencing lines.