Fair point, and to be honest, it's a common problem in many places. People enjoying a property often fail to communicate it clearly with those who never did. Math, and I believe Lisp has many times more inherited math genes than other languages, is especially guilty of this. It's often a lethal cultural shock.
S-Expressions are fun. When I first learned a Lisp, Scheme in my case, I found them weird but could see the appeal.
When I learned Haskell afterwards, it was the opposite: I thought I'd miss S-Expressions, but I learned to like its more baroque syntax.
S-Expressions have the chief virtue of making even the most crude macro look no different from the most over-engineered builtin to the language from the user's point of view.
And they clearly separate the syntactical space in the language, so that new features (whether as macro or built-in) can always find a space. Compare to the cracks of C they had to fit C++ into.
Haskell might be even worse. The chief obstacle to adding OCaml or-patterns to Haskell (https://stackoverflow.com/questions/24700762/or-patterns-in-...) seem to be finding a syntax that's both pleasant and fits between the strands of the fine web in ascii space of already valid Haskell programs.
...And I never grew to like Haskell. The syntax makes all of your programs look very elegant, but there are no clear delimiters. The syntax for how functions are delimited isn't clearly explained by most sources. And I don't want to type my code and just hope that the magical compiler fairies deduce my meaning. That kind of programming attracts bugs like a man covered in honey.
I don't know what that means, but if the objection is to layout ("the off-side rule"), that's just an alternative to the braces and semi-colons that you'd typically use if it was machine-generated, for instance.
The objection isn't so much to the layout, as it is to the fact that I can't find any documentation as to what the layout is and how the compiler interprets it.
Interesting. I've never bothered to look up the formal specs, but it was never a problem that lead to an ambiguous interpretation of my programs. (I sometimes write programs that the compiler doesn't like. But seldom once that the compiler interprets different from me.)
I usually give types for my top level functions. It's good documentation, and also prevents most of these kind of issues. (For a similar example, human mistakes with operator precedence usually lead to compile-time type errors in Haskell, seldom to runtime problems like in C or C++.)
It's not a huge problem, but lack of understanding of how the compiler delineates blocks of code makes the code hard to reason about. I like to know what the compiler will do with my code, and what is and isn't valid through something other than trial and error. Scheme's perfect regularity makes that easy. Haskell... doesn't.
I am aware that the information exists somewhere, and I think I got a link a bit back, so I'll have to go track that down. But it is absolutely baffling that people don't discuss it more. Would you be able to write Python if nobody told you about the indentation rules? Of course not.
> And I don't want to type my code and just hope that the magical compiler fairies deduce my meaning. That kind of programming attracts bugs like a man covered in honey.
I wrote plenty of Haskell commercially (and for fun). Not once did we run into that problem.
