> Nobody really wants to write `[* 5 5]` do they?

I do. The advantage being that if you suddenly realize that you want to do super-duper-multiplication instead of regular multiplication, you can just change the name instead of having to rewrite the entire expression. And honestly, having a few random functions be called differently from others feels gross.

You never used lisp-like languages did you?

There’s no use arguing. As the ancient Lisp proverb says, when the programmer is ready, the parens will disappear. Until then, you’re just wasting your breath.

No because the syntax is so awful. Programming languages are consumed by machines but written by humans. You need to find a middle ground that works for both. That's (one of the reasons) why we don't all program in assembly any more.

Lisp and similar are just "hey it's really easy to write a parser if we just make all programmers write the AST directly!". Cool if the goal of your language is a really simple parser. Not so cool if you want to make it pleasant to read for humans.

I've never used a Lisp either, but I get the impression that "forcing you to write the AST" is sort of the secret sauce. That is, if your source code is basically an AST to begin with, then transforming that AST programmatically (i.e. macros) is much more ergonomic. So you do, which means that Lisp ends up operating at a higher level of abstraction than most languages because you can basically create DSL on the fly for whatever you're doing.

That's my impression, at least. Like I said, I've never actually used a Lisp. Maybe I'm put off by the smug superiority of so many Lisp people who presume that using Lisp makes them better at programming, smarter, and probably morally superior to me.

As someone who writes a lot of Scheme, I agree that the math syntax is not good. There have been proposals to add infix expressions (https://srfi.schemers.org/srfi-105/) but nobody seems to want them, or can agree on specifics.

However, code that is mostly function calls is fine for me, since those would have parentheses anyways in C++/Rust/whatever. In that case it makes the language more regular, which is nice for writing macros.

I'd be curious to hear your opinion on wisp (https://srfi.schemers.org/srfi-119/srfi-119.html) and the Readable project (https://srfi.schemers.org/srfi-110/srfi-110.html) which are significant indentation syntaxes for Lisp languages that are still closely related to the AST and allow for easy macro writing.

Earlier last year, I "quietly" introduced an infix support macro into TXR Lisp.

I devised a well-crafted macro expansion hooking mechanism (public, documented) in support of it.

It works by creating a lexical contour in which infix expressions are recognized without being delimited in any way (no curly brace read syntax translating to a special representation or anything), and transformed to ordinary Lisp.

A translation of the FFT routine from Numerical Recipes in C appears among the infix test cases:

https://www.kylheku.com/cgit/txr/tree/tests/012/infix.tl?id=...

The entire body is wrapped in the (ifx ...) macro and then inside it you can do things like (while (x < 2) ...).

In completing this work, I have introduced an innovation to operator precedence parsing, the "Precedence Demotion Rule" which allows certain kinds of expressions to be written intuitively without parentheses.

Everything is documented in detail:

https://www.nongnu.org/txr/txr-manpage.html#N-BEB6083E

Wisp looks pretty good! I'd have to try it (or see longer examples) to know for sure but it's exactly the sort of thing I meant.

I like the syntax with the parenthesis man. The consistency is the thing.

This view is false because what is hard to parse for machines also presents difficulty for humans.

We deal with most languages (Lisp family and not) via indentation, to indicate the major organization, so that there isn't a lot left to parse in a line of code, (unless someone wants to be "that" programmer).

> This view is false because what is hard to parse for machines also presents difficulty for humans.

Yes definitely to some extent, but they aren't perfectly aligned. Most languages make things a bit harder to parse for machines but easier for humans. Some get it wrong (e.g. I would say OCaml is hard to parse for humans, and some of C's syntax too like the mental type declaration syntax). I don't think you could say that e.g. Dart is harder to parse for humans than Lisp, even though it's clearly harder for machines.

If they were perfectly aligned, you could easily parse 128 levels of parentheses without any line breaks or indentation.

Every rule for inferring a hiddnen, implicit structure within a sequence of tokens makes things harder, even on the scale of just a few tokens in one line within an indented structure.

> Lisp and similar are just "hey it's really easy to write a parser if we just make all programmers write the AST directly!".

Its not just that, it makes syntax more uniform and it allows adding all sorts of features using the same parens syntax where other languages have to invent all sorts of special symbols to distinguish between things.

It makes it easier to parse for both machines and humans. This is why I asked if you ever wrote in lisps, because it takes some time to adjust but once you do it all makes sense.

Many languages tried to make programming look like a human-readable text, they all failed in one way or another. Because writing program instructions requires specific structure and s-expressions do that extremely well.