[vegai_]

>After writing Lisp there is just something wrong about how most languages have an additional step in order to generate the AST. Why?

Because it's possible to have a lot better representations of computer code for humans than AST.

[drewr]

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.

[danuker]

Indeed. In popular languages, I always add parens, because I'm second-guessing the parser.

Lisps just embrace the parens :D

[yvdriess]

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.

[medo-bear]

some people really do find lisp to be the optimum and i say this as someone who works a lot in python

i see lisp as similar to (all?) slavic languages, in which spelling is a trivial affair

[eimrine]

As someone who learns Common Lisp and speaks 2 slavic languages, I consider your statement as surprisingly legit.

[ctrlmeta]

> 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?

[blep_]

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.

[kazinator]

> Is this a function call, or a thing that expands into something totally different?

There is editor support for that, or lookup methods at the REPL. Put a cursor on the symbol, hit some key.

I use Vim and TXR Lisp. This one liner:

  :nmap L "_y:execute ":!txr -e \"(doc '" . expand("<cword>") . ")\""<CR>:redraw<CR>

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.

[dj_mc_merlin]

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.