[tmtvl]

Yeah it is a personal issue, there are people who really like Lisp syntax (I'm one of them). That doesn't mean anything bad, of course, some people like dark text on a light background, others light text on a dark background. Everyone is different and that's what makes the world so awesome.

I see something like:

  some-var: I64 := a * b - c ^ d ^ e;

...and my brain gives out, while I find:

  (let ((some-var (- (* a b)
                     (^ c d e))))
    (declare (type I64 some-var))
    ...)

...to be much more readable, YMMV.

[adastra22]

How do you look at the latter and know the code structure? Are you counting parentheses? Or are you relying on conventions around white space indentation. If the latter, are you not concerned a misplaced parentheses might make the code different from it appears? There could be bugs not shown in the indentation.

Most lispers I know code in eMacs or other smart editors that provide auto code formatting and colored parens. But why not just make the indentation (or whatever that you really rely upon) the actual syntax, so there CANNOT be hidden bugs of that sort?

Edit: to expand on this, I think it is no coincidence that most lisps remain untyped to this day. Strong typing is about having the compiler enforce type rules so you the developer can’t fuck it up. Weak typing is more convenient, but ultimately a source of bugs. Lisp has, effectively, weak syntax. I don’t like weak syntax for the same reasons I don’t like weak typing.

[dreamcompiler]

> But why not just make the indentation (or whatever that you really rely upon) the actual syntax, so there CANNOT be hidden bugs of that sort?

That's Python. When whitespace matters, any aesthetic reformatting mistake can change the program's meaning. With s-expressions this cannot happen. A lisp code parser is completely deterministic regardless of where the newlines, spaces, and tabs occur. You can remove all the newlines from a 10,000-line Lisp program and the compiler will parse it exactly the same as if it were formatted aesthetically.* You can also write a simple program that takes that godawful one-line program and reformats it aesthetically however you like--the meaning won't change.

IOW in Lisp the aesthetics of the source code do not determine its meaning; aesthetics and meaning are orthogonal properties and you are free to adjust the two independently. This is also somewhat true in languages like C, but rather than several special-case punctuation characters, in Lisp there's only one: The parenthesis. Lisp is thus similar in spirit to HTML where semantics and layout are [mostly] independent.

* With a few obvious exceptions like EOL comments, and newlines that are part of quoted strings.

[xigoi]

> any aesthetic reformatting mistake can change the program's meaning.

Why would you just randomly change indentation? On the contrary, I don't want the indentation to say something else than the code actually does.

> You can remove all the newlines from a 10,000-line Lisp program and the compiler will parse it exactly the same as if it were formatted aesthetically.

But a human won’t. And that’s a problem.

[lispm]

> Why would you just randomly change indentation? On the contrary, I don't want the indentation to say something else than the code actually does.

Because the user may want the development environment to display snippets of code in various places: REPL, debugger, code browsers, inspectors, various editor types, ...

In a Lisp system the code can be data and text. Code formatters can reformat code depending on user preferences, device types (color, font, ...), view sizes, ...

In Lisp often code gets generated (for example via 'Macros') and this code will be automatically layouted in various view (different widths, different fonts, different detail). Code can be small or large, the system may abbreviate parts, which one can expand, if necessary.

Source Code is not necessary static text in a file system. Code can just be list-based data structures and layout is fluid.

In Common Lisp the formatted output of code is also user extensible/customizable, a 'pretty printer' is a part of the language spec:

https://www.lispworks.com/documentation/HyperSpec/Body/22_ba...

If we read a text in a book reading the device, one can also change for example font size and the thing will relayout the text accordingly.

[vindarel]

Use an editor that auto-inserts parens and that indents the code correctly. Now nothing bad can happen. And the parens are used to edit code structurally.

re typing: Coalton brings Haskell-like typing on top of CL. https://github.com/coalton-lang/coalton/ Other lisps are typed: typed racket, Carp… and btw, SBCL's compiler brings some welcome type warnings and errors (unlike Python, for instance).

[tmtvl]

Well I don't like indentation-based syntax because when I write code with such syntax down in a notebook I have this bad tendency to drift to the right as I go lower down the page. And then if I go training or something and return the drift causes me to lose the structure of the code.

With round brackets on the other hand, well... I think my brain just works with round brackets. Like my mind is coded in Lisp or something, I dunno. It would explain why I'm so slow: GC pauses. My mind should really be ported to SBCL or something.

[Kinrany]

Auto code formatting is a must in every language at this point.

[frankjr]

I think you've just accidentally demonstrated why most people don't like Lisp syntax.