There are no other homoiconic languages with amazing REPL support.
After writing Lisp there is just something wrong about how most languages have an additional step in order to generate the AST. Why? A tree is a simple structure and describes the shape of code well. I can just write it myself. There is no reason to add weird arbitrary requirements on how you have to present your source code text to the compiler -- just feed it the data structure representing it instead.
Since your code is just a tree now you can also write macros that are just functions. No text substitution or preprocessor jank. This is an amazing simplification and just feels as if it is the way it should be.
Touché. Excuse my ignorance, feel free to correct me, but I've always viewed Prolog as suited to specific tasks, whereas Lisps are more general purpose. There's games in Lisp for example, not a lot, not all of them great, but they're still there. I'm not aware of any Prolog games.
SBCL is also within 2x-4x of C quite a lot so unless you really need every last bit of performance you're fine, as opposed to Prolog's snail-like tendencies. Static typing and turning off safety checks/turning on optimizations can get you very close to as fast as you'll ever need.
Prolog is probably less of a general-purpose language, in the sense that writing things such as games are probably not a very suitable goal for it.
But for any problem involving the exploration of a solution space, prolog is absolutely stellar and actually quite fast, and even faster to write: solvers, irregular data processing, symbolic reasoning... It also lends itself quite well to "I just want to query a database" apps, including websites. Have a look at the "power of prolog" YouTube channel if you are interested.
You underestimate the cognitive burden of resolving syntactic ambiguity with non-lisp languages. So many problems disappear with s-expressions that when I return to a language with a "human" syntax I feel bad that I have to work harder.
Possibly, but I would argue we're not doing a very good job at that. Things like precedent rules plug into what we're used to for mathematical expressions, but that's only a small part of actual programming. Teaching novices without prior PL experience, you notice how much language syntax can get in the way, I get to the core concepts faster with scheme-driven classes than python-driven ones.
Question to HN: have there been recent interesting empirical studies into the impact of PL syntax? I tend to always cite https://dl.acm.org/doi/10.1145/2534973 but newer ones might have superseded it.
> Because it's possible to have a lot better representations of computer code for humans than AST.
Which are those? I assure you I am a human and I find s-expressions to be clean, elegant, easy to read and easy to understand. I have learnt C, Java, C#, PHP, Perl, Ruby, Python, Go, Javascript, C++, Rust over the years and I have not found a syntax that feels better to me, the human.
When I am writing tools for myself I reach out for Lisp because it is the most convenient one to write code in. I don't have to worry about all the syntactic ambiguities and complexities of these other languages. With Lisp, I can focus on solving my problem without being weighed down by complex syntaxes of other languages.
You are saying there are better syntaxes out there? Where can I find this elusive language which has better representations of computer code for humans?
A lot of this is pure preference, and if we try to debate the merits of prefix vs infix operators we're just going to yell MY PREFERENCES ARE RIGHT AND YOURS AREN'T at each other until we get bored.
But there are some places where I think Lisp syntax is objectively worse than the alternatives. Parsing Lisp is easy because it shifts all the hard parts to the semantic layer. Everything looks so similar that you have to do a lot more reading, and memorization, to know what's going on at all.
----
To take a supposedly good example from elsewhere in this thread[0]:
> (do-a-thing b (+ a 5))
Is this a function call, or a thing that expands into something totally different? It matters, because (+ a 5) may not be something so trivial - it may have side effects, or be evalulated multiple times. (If it was a lazily evaluated pure function, there would arguably be no point to having macros at all.)
This one is trivially solvable by making macros visually distinct in some way, e.g. Rust's ! suffix, or C's convention of MACROS_YELLING_AT_YOU. It doesn't matter what the syntax is, as long as it exists.
----
Is (progn a b c) a function call or a special form? What about (proxy a b c) or (pregen a b c), both totally plausible names for functions? It's totally possible, even easy, to tell those things apart if you're paying attention, but you have to actually read the word at the start and comprehend it. In languages with dedicated syntax for this, you can just recognize { and } and instantly know what's going on, no need to involve the word-recognition parts of your brain at all. This sounds trivial - nearly all syntax decisions are - but it adds up when everything in the language is like this.
----
[0] https://news.ycombinator.com/item?id=33469932; I've renamed the macro here to make my point clearer, because the obvious response would be "well obviously someMacro is a macro", but in the real world people do not name their macros that.
lets me look up standard language things by pressing L while the cursor is on a symbol like progn; it launches a browser window on the doc, and jumps to the section. For stuff that is in the code tree being worked on, there is jump to definition via tags.
> In languages with dedicated syntax for this, you can just recognize { and } and instantly know what's going on, ...
If you don't already know the construct, it may be hard to search for it, especially online.
Recently I wanted to see some examples of C++ lambdas in code bases. I tried searching for things like "[](" and "[]{" and whatnot on github; no luck.
> C's convention of MACROS_YELLING_AT_YOU.
Plenty of C macros (that do non-obvious evaluation) get written in lower case.
Even if you think you're sure something is a function call, that tells you little. You might know that it won't clobber the argument expression, but what you often need to know is what the construct does; and in the course of finding that out, you will find out whether it happens to be a macro.
I wrote a response saying what I do to counter these problems.. but actually, I think introducing some form of syntax to differentiate macros would be amazing. I wonder if macro symbols could be pulled automatically from packages and suffixed with ! if they are not so already. A new symbol could be added to the package so as not to internally affect the code. Thanks for the idea.
After writing Lisp there is just something wrong about how most languages have an additional step in order to generate the AST. Why? A tree is a simple structure and describes the shape of code well. I can just write it myself. There is no reason to add weird arbitrary requirements on how you have to present your source code text to the compiler -- just feed it the data structure representing it instead.
Since your code is just a tree now you can also write macros that are just functions. No text substitution or preprocessor jank. This is an amazing simplification and just feels as if it is the way it should be.