x.f(y, z) has just as many parens as (f x y z). And Haskell particularly comes with so many syntax quirks. There is a lot of cruft you need to learn to get to the underlying functional core of haskell. Lips you can get 100% of the cruft out within a few days / 1 week. And the rest is just understanding programming concepts.
I don't use any LISP on a regular basis, but it still amazes me how often people are willing to dismiss a language based on parens.
It reminds me of a friend who would never try food from any other country because: Look at all the weird colors and ingredients. I'm not trying that.
In the end, no one will ever force anyone to try something - but my view in life is if everyone raves about something, and my main concern with it is by (my own admission) superficial. I still go and give it a try.
SICP gives you a new view on programming regardless of whether you ever touch lisp again or not.
x + y * z
(+ x (* y z))
What you are also glossing over are the precedence rules for operators. In this case it works in favor of your point and LISP indeed needs more parens.
However in other situations, you might need to re-parenthesize (language with flat precedence like APL) or consult your favorite chart[0] in order to figure out what is going on.
[0] http://en.cppreference.com/w/c/language/operator_precedence
Wouldn't agree per se, I'd rather formulate "it gives the user-land a lot of freedom & powers for introducing syntax quirks". You can code super-clean Haskell, or you can roll in 2 dozen language extensions and libraries with a 100+ custom operators, and use TemplateHaskell --- then yeah the syntax will begin to look horribly "quirky". Many practitioners end up limiting themselves in this regard after a while, or insist on "going back to basics" as much as feasible
The super-cleanest Haskell still has a ton of syntax to learn compared to Scheme. If your goal is to teach concepts of programming, almost any time spent on the syntax of a particular language is time wasted. Particularly so during a semester in university.
Similarly, if you won't be using FP for your day job, and would be using it for the insight gained (and have never used it), a language where you can begin learning concepts without needing to internals a bunch of syntax or infix operator precedence rules is also the better choice.
A handful of keywords (same as any language), fewer (mandatory) parens & braces than any other language, no (mandatory) semicolons, the same sort of indentation one tends to apply in any language anyway --- Essential-Haskell's "ton of syntax" in a nutshell.
Precedence rules for the built-in `Num` and `Bool` operators are equivalent to all languages. Other operators are either custom-defined (outside the scope of language's "syntax") or entirely inessential convenience-vehicles such as for composition (unnecessary, just handy in practice) or avoiding even more parens (dito) --- of which there are 2. Any tutorials or text-books that rely on such or other operators as part of "syntax" are, in that respect, simply a bit flawed.
What repetition are you referring to?
To each their own...
For code that non-haskellers have to work with I would just write everything out which is what lisp does and probably results in better code. Otherwise there still is a balance, I think. Like
Lispy:
n <- textInput (set textInputConfig_inputType "number"
(set textInputConfig_initialValue "0" def))
n <- textInput $ def & set textInputConfig_inputType "number"
& set textInputConfig_initialValue "0"
n <- textInput $ def & textInputConfig_inputType .~ "number"
& textInputConfig_initialValue .~ "0"Only on hacker news do people think there are objective opinions! The syntax is, let's say, "divisive" which is enough of a reason to think that if you want functional programming to grow, something needs to change about it.
(a b c d)
f x y z
Basically, f $ x = f x and is applied with lowest operator precedence (0) and is right associative. Therefore, f $ x y $ z = f (x y $ z) = f((x y) z)
f (x y) z
What you have there is loaded with ambiguity that has to be resolved by semantics. And after the dust settles, you're left without variadic functions.
Partial evaluation and currying are very valuable techniques. They are still succinct if there is a visible, explicit partial application operator to denote a function that is constructed by binding arguments around an expression.
But golergka said that Lisp's syntax is the clearest, not the smallest. And while that's probably something that depends on one's knowledge and past experience, I think there's something to it. The parens mean that it's unambiguous, and there is very little work on the reader's part to figure out where an expression begins and ends.
There's no operator precedence to keep in mind, no special whitespace rules, etc. It's about as minimal as you can get while still being completely explicit about syntactic constructs.
The question is, is it the _only_ syntax that Haskell offers and that the full language is built upon?
- there's no universal syntax for everything [1]
- lisp entice you to make tiny dsl as sets of correlated functions on some domain for which there's no syntax .. [related to 1]
- close to zero magic
- parsing complexity removed and built-in, jump straight into problem solving [3]
- some advanced academics don't see classic math as the ultimate notation (one sicp author made SICM for langrangian mechanics) he likes the consistency and smallness of sexps [related to :3
[1] I know, people like infix math
[2] I failed an ADA exam because I couldnt find how to typecase a 1-char string to a char type.. try to guess
[3] instead of how cute is my <incompatible-and-not-more-powerful-lang-of-the-day> looking.. Also Brown Uni. had a chapter on not wasting time on syntax in education. Although they made pyret lang since .. but syntax is not the only reason.
There are two clues in this sentence (mentioning SML and not OCAML, "something like that") that suggest you do not regularly program in a "something like that" language. I wrote my first Haskell program over a decade ago. I find Haskell very hard to read. The grammar is very complicated[1] and is actually context-sensitive[2].
[1] https://www.haskell.org/onlinereport/haskell2010/haskellch10... [2] http://trevorjim.com/haskell-is-not-context-free/
That is a junk argument. No one needs context-sensitive grammars. I think designing a language that cannot be parsed with an LL(1) or LALR parser is just dumb. It guarantees that your compiler will be slow right from the start. In addition that applies to all the tooling - syntax highlighting and navigation in the editor, linters, pretty-printers, etc. And in practice the tooling is not just slow but also has a ton of bugs around corner cases.
Still hard to beat for creating domain-specific languages, though, and a carefully designed DSL can rule out nondeterminism and side effects.