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.
drewr|3 years ago
danuker|3 years ago
Lisps just embrace the parens :D
yvdriess|3 years ago
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.
medo-bear|3 years ago
i see lisp as similar to (all?) slavic languages, in which spelling is a trivial affair
eimrine|3 years ago
ctrlmeta|3 years ago
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?
blep_|3 years ago
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.