4 ms·

It's been stated a number of times, but 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 l

It's been stated a number of times, but 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.

deleted 10y ago
[deleted]
idobai 10y ago
Lisp is a cult. It doesn't have any benefit but that doesn't matter for cultists. Lisp code is terrible in practice: https://github.com/emacs-mirror/emacs/blob/master/lisp/calc/calc-aent.el https://github.com/emacs-mirror/emacs/blob/master/lisp/calc/...
mnarayan01 10y ago
x + y * z has way fewer than (+ x (* y z)) though. I'm not arguing for one or the other, but e.g. infix operators do have upsides.
- Jach 10y ago
  Fortunately with Lisp this isn't an unsolvable problem. https://github.com/rigetticomputing/cmu-infix https://github.com/rigetticomputing/cmu-infix
- thoth 10y ago
  >infix operators do have upsides 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 http://en.cppreference.com/w/c/language/operator_precedence
dualogy 10y ago
> And Haskell particularly comes with so many syntax quirks 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
- BoiledCabbage 10y ago
  > super-clean Haskell 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.
  - dualogy 10y ago
    > a ton of syntax to learn 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.

deleted 10y ago

[deleted]

idobai 10y ago

Lisp is a cult. It doesn't have any benefit but that doesn't matter for cultists. Lisp code is terrible in practice: https://github.com/emacs-mirror/emacs/blob/master/lisp/calc/calc-aent.el https://github.com/emacs-mirror/emacs/blob/master/lisp/calc/...

mnarayan01 10y ago

x + y * z has way fewer than (+ x (* y z)) though. I'm not arguing for one or the other, but e.g. infix operators do have upsides.

Jach 10y ago
Fortunately with Lisp this isn't an unsolvable problem. https://github.com/rigetticomputing/cmu-infix https://github.com/rigetticomputing/cmu-infix
thoth 10y ago
>infix operators do have upsides 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 http://en.cppreference.com/w/c/language/operator_precedence

dualogy 10y ago

> And Haskell particularly comes with so many syntax quirks 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

BoiledCabbage 10y ago
> super-clean Haskell 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.
- dualogy 10y ago
  > a ton of syntax to learn 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.