Om is a novel, maximally-simple concatenative language
om-language.org
om-language.org
Most other concatenative languages are Joy/Factor-esque stack languages, so to see an entirely different vision with your prefix notation is an absolute delight . Your panmorphic type system is also genius (the only other language I know of that has something similar is TCL). The way you treat whitespace separators in your syntax is also very clever, I love that it basically enables one to encode strings without a dedicated literal syntax element.
Anyway, I just wanted to let you know how much I appreciate your design and implementation efforts. I hope your rewrite is going well, and I look very much forward to its eventual release...
By the way, your language has been a big inspiration for my own designs. Thanks!
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.
People enjoy using simple things in a "worse is better"/paradox of choice way. Unfortunately, simple doesn't do threading, exceptions, side-effects, or C library linkage. Simple doesn't scale when you need a deploy button, a backup and restore button, firewall rules API, monitoring logic, or a scale-to-5000-stateless-nodes-behind-a-proxy supervisory service.
> Recursion is very efficient in the Om language, due to (a) the "eager" evaluation model enabled by prefix concatenative syntax...
How is the syntax of any relevance for the evaluation model?
Once the AST is parsed, the syntax is gone and we're just left with pairs of 'operator' and 'operand'.
Look at what lengths one has to go constructing a Y combinator when syntax does not allow to refer to the current expression to simply describe recursion.
Why french?
- "Piece of art" didn't communicate engagement with the item as art
- "Work of art" is often used to mean a masterpiece
- "Artwork" is a neologism of the sort I avoid
Finally, "objet d'art" communicates appreciation as art, but not necessarily any artistic quality, and it's a phrase people use in this context.
While we're asking irrelevant questions, why are the majority of your comments questions and criticisms of trivial matters of wording? Obviously, we agree that words are important, but it's equally important to engage with the intended meaning of those words.
It may be derived from French, but it has a distinct meaning in English. You might as well ask why someone is using French when they say they're going to see a ballet. It's a feature of English (and really, most languages) that foreign words and phrases are often imported and given connotations distinct from both the meaning in the language of origin and from other words or phrases in English. Once that adoption is widely recognized, is it really not English?
Sure, you're not going to want to start up a major project with a long-abandoned language experiment, but frankly it's not much of a step down from even an active language experiment.
I suppose it's got a greater chance of being harder to get going, but so much of that depends on how it was built in the first place that simply being older isn't enough information make much of a guess on that either.
> …the software is currently at a very early "proof of concept" stage, requiring the addition of many operations (such as basic number and file operations) and optimizations before it can be considered useful for any real-world purpose.
This is pretty different from your characterization as a finished experiment.
(That said, I did a lot of Forth programming in the old days, and while I am utterly intrigued by Factor, I've never managed to write anything useful in it...)
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration [1]
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.
[1] https://www.cs.virginia.edu/~evans/cs655/readings/ewd498.htm...
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.
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.
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.
The one real advantage that prefix notation has is that it is familiar, since it is so widespread in mathematical notation. Though that particular advantage would optimize the experience of using a language for people new to programming or that particular language, whereas it might realistically make more sense to optimize for the experience of people already familiar with a language, since those will constitute the vast majority of development time in any serious language, and I would argue that postfix notation has an advantage there in most domains.
So, changing the compiler from targeting a stack / finite state machine (no register allocation - see zero address format) to registers (NP complete to allocate the registers)?
Alternatively, changing the available static / compiled features of a language is usually offered with compiler flags or keywords. Concatenative languages are already Turing complete up the restrictions on functions as such to being total.
I mean other than the conservative approximation being to assume it is not?
Is there a reason concatenative languages aren't (naturally) primal chordal graphs? "Naturally" is not distinctive, but concatenative languages can be compiled to registers & induce the Core Register Allocation problem that was proven NP complete by use of primal chordal graphs.
Or consider large-scale code analysis and refactoring tooling - perhaps having that should be a bootstrap target, a unit of absorption is app repo, and a key threshold is ability to refactor source? Or not repo, but arbitrary scale. So Language Server Protocol blended with dynamic loading and calling convention? Smalltalkish "live" image environment with piles of mutating forked repos? That sort of cross-checks - ask a "programmer apprentice" ai, err, or simply a programming team, "I'd like capabilities foo with characteristics bar", a set of forked repos might be an unremarkable outcome. So that might suggest a language bootstrap target of ffi plus refactoring-LSP client?
FFI is an unremarkable bootstrap target, and a refactoring-LSP client gives control over both sides, so maybe next, how to move code across the line? AST scraping and transliteration? Polyglot direct memory access to data types? Suggesting as targets maybe high-end "can exercise and analyze compiler output" ffi, and rich AST tooling? Language implementation, with its specs and test suites, can be a nice context for such work. Which might bring us back around to an emphasis on early implementation of other languages, but with maybe an increased focus on interoperation with existing implementations? Control of config, build, and linkage, might also need emphasis?
Hmm, fun, tnx! [1] https://github.com/trailofbits/vast [2] https://news.ycombinator.com/item?id=33387149
It emits "{Hello, world!}" which is like emitting "func main() { print("hello, world!" } }"
A hello, world for this language would take "hello, world" as an operand to some operator that spits out strings. That example is not there.