Om is a novel, maximally-simple concatenative language

Looks like Forth but more complicated to me...

FWIW, I've been playing around with Joy (Manfred von Thun's concatinative language) and there's definitely "something there" IMO.

For one thing, I've come around to the view that syntax is waaaay over-emphasized in our current languages. The way I like to put it is syntax is a MacGuffin, "an object, device, or event that is necessary to the plot and the motivation of the characters, but insignificant, unimportant, or irrelevant in itself." You have to have some syntax to write programs, but not nearly as much as we typically use. I haven't dug into Om yet, but Joy feels like the simplest useful language. (BrainF*ck is simpler but harder to use, Lisp and Forth are more complex.)

For another, the concatinative systems seem to be simpler to reason about than Lambda Calculus-based systems (most current PLs.) What I mean is, these languages fulfill Backus' vision of FP systems wherein you can derive programs by doing algebraic manipulation of programs. (You can do this in any language, of course, but Joy et. al. seem to make it especially easy.) I suspect this has something to do with Category Theory (see http://conal.net/papers/compiling-to-categories/ )

All this to say, if you haven't already, do have a look at Concatinative languages.

> I think that Forth only works with people who've started with assembly programming. Someone who started with a high level language suffered that sort of brain damage that make them unable to feel complexity even when it coils around them and give them a hard time breathing.

What I find interesting about Forth is that it is a language that is simultaneously a high level language and a low level language. It encourages the programmer to write high level programs but if they need to write low level assembly routines for maximal performance, they can (though they may need to write their own Forth interpreter to do so).

I believe that the viral spread of c and unix is possibly the worst thing that ever happened to computing. There is a quote attributed to a physician named Vincent Felitti in the context of addiction: it's hard to get enough of something that almost works. This is the story of c. It is neither a high level language nor a low level language and is thus the worst of both worlds. We've added a staggering amount of complexity to work around the limitations of c, which have also infected most of our other supposedly high level languages, e.g. java, go, rust, etc. To your point though, because we know no other way, we can't even see that much of this complexity is largely unnecessary.

Much of this goes back to Gabriel's observations in the rise of worse is better: https://www.jwz.org/doc/worse-is-better.html. What I think Gabriel doesn't fully articulate is that worse is better is an essential feature of market capitalism. The most profitable customers are addicts. Most of the time, you can't just sell them something that is complete garbage. The best thing to sell is something that is almost good enough and that the customer is not empowered to improve themselves. Then they have to keep coming back to you for updates. Why would you sell a customer a complete program that does exactly what it is meant to do and nothing else when you could sell them something incomplete that you can keep repeatedly selling back to them?

This is the water that we swim in, and it sure seems to me that we're all having a hard time breathing.

I’ve sold many an incomplete product and made money from improving it over time.

From my perspective, exploiting addicts and capitalism never entered into it; that’s just how MVP and customer-focused development work. Making money from the MVP validates the general direction and developers are incentivized to improve utility to generate additional cash flow.

Projects that seek to deliver a complete and optimal solution day one generally fail because the creators don’t have a complete and optimal understanding of customer need. Plus it takes forever and creators need to eat while working.

The advantage is that the language isn't stackful.

This is about more than just underflow, there isn't a stack at all. Missed arity is a syntax error, not a mistake in reasoning about the program state.

I'm not sold on Om's solution, I doubt the author was either since it's frozen in time. I have long wondered about a good prefixed concatenative language, without really getting anywhere. Om seems too much like inside-out Joy, although I'm not sure I could justify that impression in detail.