It is a long story, feel free to send me an email, but I'll summarize. I think it "sticks" technically but find it hard to see how it works as a business.

I spent a lot of time working in the semantic web space heading in the direction of "low/no code" and was struck at how logic-basic programming (not just constraint languages but production rules and other approaches) has been dead in the water since the 1980s despite the tools getting much better and numerous but isolated success stories.

Lately I got into the Arduino hobby and I've developed a number of things that are basically "traverse an object graph in program memory with several cursors" while doing a few streams of I/O.

(Imagine I have a SPI lightstrip on my car and program memory has a set of dingbats, color palettes, a picture of a McLaren F1 and instructions to put it all together. For now I tell the driver to use the cruise control, someday it reads from maybe the CAN bus, GPS and accelerometer and runs a Kalman filter to stick the GFX to the ground)

In a program like that the functions divide neatly into several layers and everything can be statically allocated and the more I think about it, the more I think the way C thinks about functions (return values, calling conventions, etc.) is not a good fit for the problem. I have no need for the stack, can allocate a few registers for the interrupt handlers, etc.

Thus I think "C sucks" and I am no fan of gas (designed by somebody who hates assembly language but doesn't see the C-thulhu in old-school C compilers.)

There are lots of papers where people apply theorem proving to assembly and seem to have an easier time than they do with languages like C. Maybe the behavior of the system is better defined, maybe you get into combinatorical problems with automatic allocation, etc.

My C programs statically allocate as much as possible and have notes that say what color the functions are and informally justify that the thing works. I feel like a dork knowing how much wasted activity the C code is doing behind my back and think about re-writing it in AVR-8 assembly with even more detailed notes...

... so if those "notes" were a machine-readable proof that the memory allocation and other things in the program were correct and otherwise the system could SMT solve for things I don't want to code by hand that would be sweet.

(A positive in this application is that the program is going to be small but the compiler is going to run on a much bigger machine.)

As a business though I don't believe it.

Even a Pascal-like or FORTRAN-like language without any real technical innovation is a bad enough sell for this market; Arduino using C is good for "education" because learning some C is useful, even if it teaches bad habits like BASIC.

Portability is a problem too. I think AVR-8 is beautiful but it is a dead end but when the going gets tough I am going to swap in an RP2040 and add some transistors to shift levels.

On top of that, expecting people to learn multiple new technologies is a big ask. I am sure many people think "C sucks" but jumping to the system I envision means learning assembly language, theorem proving, and a few other things. I could write many C programs in the time it would take to get that system up to the point where I could use it, and the investment would be several times that before other people could use it.