[nickpsecurity]

There's tutorials to manually or automatically derive parsers for whatever you can clearly define. LISP's syntax makes this trivial. From there, you just need a few functions and tree operations for interpreting/compiling. LISP is designed for tree operations with tutorials and code for those. From there, a GC and I/O with many examples in papers and on the web with doc's plus code. Additionally, there's a ton of LISP/Scheme interpreters to draw on.

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.

[tormeh]

Oh, I do agree Lisp is the simplest. No contest there. Hm, I guess it may be because building a new language (with some interesting properties) was my master thesis and it was really unpleasant. I guess I am reluctant to realize how much easier it would have been with a lisp.

[nickpsecurity]

That's a fair point. It's never easy and I had that rough experience, too. I mean, I wasn't a real expert on these things so mine was a reimplementation of existing work but still hard.

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:

http://julialang.org/

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.

https://news.ycombinator.com/item?id=9699065

[tormeh]

My language's main feature was deterministic multithreading, of the synchronous school. It also forced a certain structure: All threads started and the shared variables they can write to have to be in the same area, arguments are always named, and sequence doesn't matter (optional in Python), shared variables can only be written to by one thread, but read by all. In contrast to some other deterministic multithreading solutions, the sequence in which IO is effected is also deterministic, not only the sequence of application to shared variables. The compiler had a typechecker and compiles to C++, using GCC to do the rest. I guess I should submit it to HN sometime...

[nickpsecurity]

That sounds interesting. Might be a decent stab at real-time programming and concurrency as it would need most of that.

"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.