It's not machismo: it's just the design of LISP. Easy to parse, easy to modify, easy to evaluate, data as code, basic primitives that express anything else at least acceptably, and on 50's-60's hardware.
Additionally, building a useful LISP (esp Scheme) is an academic exercise done all over the world that's fairly easy even for amateurs. Building a useful, non-optimizing C++ compiler with only a subset of LISP capabilities is an exercise only undertaken by masochists very dedicated to compiler design. Even a prototype is easier for LISP (a few pages of code) while a prototype of C++ or even C's semantics is much more challenging. So, the empirical evidence counters your claim in terms of completed projects, their complexity, and features received in return.
Lisper just reminded me of some HN commenter who once wrote that "any idiot can build Youtube, it's making it scale that's hard", and that guy gets on my nerves. Sorry about projecting that onto lisper.
Hard to imagine an easier one to interpret. Compiling isn't that difficult if you target C as it basically takes two techniques. Takes a few more to target native and you don't get that in 90 minutes like one Scheme-to-C compiler presentation.
What is your counter-example in terms of mainstream languages that's easier to lex, parse, interpret, compile, or link than LISP? Or even as easy? Even Wirth's languages are more complex and difficult to compile despite being brilliantly simple.
Curious, what was your language's interesting properties?
"I guess I am reluctant to realize how much easier it would have been with a lisp."
It might help if you see a modern example. The recent language impressing me the most with its features is Julia:
Wondering aloud about how they pulled all that off, esp macro's, led someone here to tell me it's actually femtolisp internally:
https://github.com/JeffBezanson/femtolisp
So, they appear to have built a simple LISP, then used it to incrementally build a compiler for a complex language. They just represent the syntax internally in a LISP form and work with it from there. Don't know much more than that but it shows the power of the concept.
Better demo is the one below as it goes step-by-step in stages. One commenter (Orion63) pointed out the author was re-using the proven cheat: "build a LISP, do it all in LISP, profit." Haha. I've considered duplicating that work with different language options.
"All threads started"
In many languages, the threads kind of sleep unless activated explicitly. Do you mean just the activated threads started or did you choose to have them all run at once for some reason?
"shared variables can only be written to by one thread, but read by all"
Good idea. BeOS also had read-many, write-one in form of benaphores: semaphores that only locked for writing. Strategy made it really fast.
"the sequence in which IO is effected is also deterministic"
What do you mean by that?
"compiles to C++"
The compile to C++ was my trick, too, since I knew I couldn't out-code GCC team. Although I wrote mine to avoid using C++ while being compatible lol...
"I guess I should submit it to HN sometime..."
You should. Either that or a forum where people discuss various language tradeoffs.
As an example, here's a guide for writing a Scheme interpreter in a matter of hours: https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_...
It definitely doesn't take it months to walk away with a working implementation. Whether or not the language you've just written is actually useful or preferable to alternatives is a different question, and there I agree with you that communities, libraries, and language maturity can take a long time to build.
Lisp's simple syntax makes it a prime target for creating new dialects (like Clojure) to experiment with semantics.