7 ms·

Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature. If you're going to sell people on the benefits of functional progr

by c3534l 10y ago

Yeah, but it's goddamned ugly and unreadable. It considers repetition to be a design feature. If you're going to sell people on the benefits of functional programming, I think you should really be pushing more for SML or Haskell or something like that.

deleted 10y ago
[deleted]
siscia 10y ago
Repetition of what? I don't see any repetition on those snippets... What are you referring to?
- jasonkostempski 10y ago
  Maybe they had mistaken the breakdowns for user input? I did for a second.
- c3534l 10y ago
  Everything is nested in the form of (fn arg arg) and relies solely on indentation to create some modicum of differentiation.
golergka 10y ago
Unreadable? Personally, I think that Lisp has the clearest possible syntax - because it basically doesn't have any. It's just straight ASTs - something that I have to visualize myself in other languages wich have more syntax sugar.
- tromp 10y ago
  Lisp has the minimal syntax for lists: (a b c d) where other languages require separating commas, but Haskell has minimal syntax for function application: f x y z with no parenthesis needed. (Technically, this is a triple application ((f x) y) z, masked by the convention of application being a left-associative binary operator.)
  - chirau 10y ago
    How would you write f((x y)z) in Haskell?
    - deleted 10y ago
      [deleted]
    - scriptdevil 10y ago
      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)
    - tromp 10y ago
      f (x y z)
    - vq 10y ago
      If by (x y) you mean x(y) then I would write it like this: f (x y) z
  - kazinator 10y ago
    That is "minimally punctuated syntax". What we want is a "minimal correspondence between written syntax and the AST"; that is what is really meant by "Lisp has minimal syntax". 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.
  - wtetzner 10y ago
    Right, Haskell's function application syntax is more "minimal" that Lisp's, at least in the simple case. 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.
- lmm 10y ago
  It makes e.g. arithmetic expressions look rather awkward.
  - golergka 10y ago
    That's if you choose to think abiut them as arithmetic expressions and not function applications. If you work with arithmetic expressions a lot, you should probably use appropriate domain language - in fact, you can build it in Lisp itself.
    - lmm 10y ago
      You can write a reader macro (in lisps that permit them, otherwise you've got no hope) but that's just lisp-speak for "program that parses strings". A language where you can use infix notation within the language is much nicer.
karmajunkie 10y ago
That's a pretty subjective opinion... I don't have much trouble with lisp but Haskell makes my eyes bleed. Of course I'm not a Haskell programmer, so it stands to reason that those who are find its syntax enjoyable. To each their own...
- Tarean 10y ago
  I think haskell's syntax is extremely beautiful. However code that uses two dozen operators in half as many lines is incredibly ugly in any language and doing that can be quite tempting in haskell. 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)) Operators for precedence: n <- textInput $ def & set textInputConfig_inputType "number" & set textInputConfig_initialValue "0" Alias for function: n <- textInput $ def & textInputConfig_inputType .~ "number" & textInputConfig_initialValue .~ "0"
- c3534l 10y ago
  > That's a pretty subjective opinion 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.
  - karmajunkie 10y ago
    yeah, I don't think that's true. Neither Clojure nor Haskell seem to have any problems finding adherents, nor does the functional paradigm itself seem to be in danger of... anything. Your personal distaste for parens isn't much evidence to support the idea that they are antithetical to the growth of functional programming, nor my own distaste for Haskell evidence of the same.
deleted 10y ago
[deleted]
simplify 10y ago
I find lisp to be the most beautiful and readable language. Lisp has practically zero syntax; all code can be written equally. You can even create your own "syntax" / language features without waiting years for the approval of a committee (I'm looking at you, JavaScript). What repetition are you referring to?
BoiledCabbage 10y ago
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
agumonkey 10y ago
sml is uber cute, probably the only syntax I enjoy more than sexps. I never got the people with problems regarding lisp thin syntax. - 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.
sedachv 10y ago
> I think you should really be pushing more for SML or Haskell or something like that. 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.html https://www.haskell.org/onlinereport/haskell2010/haskellch10... [2] http://trevorjim.com/haskell-is-not-context-free/ http://trevorjim.com/haskell-is-not-context-free/
- c3534l 10y ago
  I do like OCaml, but have never had the opportunity to write more than a few toy programs for fun. I put SML in there just to be like "and other ML-family functional programming languages." Haskell is complicated, but some complication is needed and that's more of a learning-curve problem. If humans were capable of simple, we'd all be typing 1s and 0s. We do better with grouping, context, similar things being similar and dissimilar things being dissimilar. I don't think Lisp is the way forward for functional programming.
  - sedachv 10y ago
    > Haskell is complicated, but some complication is needed and that's more of a learning-curve problem. 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.
davexunit 10y ago
Lisp is not a functional programming language.
- drdre2001 10y ago
  How? Functions are first class in lisp.
  - crimsonalucard 10y ago
    First class functions do not make a programming language functional.
  - davexunit 10y ago
    Functional programming is but one of the many paradigms that you can use in Lisp, along with imperative, object-oriented, relational, etc. When you say a language is a functional language, you are saying that it is the paradigm supported, which is not the case here.
    - concede_pluto 10y ago
      Lisp has lots of mutable types and lots of ways to smuggle them into and out of a procedure. I'd say pure functions are tolerated but not supported. Still hard to beat for creating domain-specific languages, though, and a carefully designed DSL can rule out nondeterminism and side effects.
      - davexunit 10y ago
        A language need not force purity to allow for purely functional programs. Besides, purely functional languages all need a way to cheat to actually do anything useful. Any nontrivial program needs a mix of paradigms.

by c3534l 10y ago

deleted 10y ago

[deleted]

siscia 10y ago

Repetition of what? I don't see any repetition on those snippets... What are you referring to?

jasonkostempski 10y ago
Maybe they had mistaken the breakdowns for user input? I did for a second.
c3534l 10y ago
Everything is nested in the form of (fn arg arg) and relies solely on indentation to create some modicum of differentiation.

golergka 10y ago

Unreadable? Personally, I think that Lisp has the clearest possible syntax - because it basically doesn't have any. It's just straight ASTs - something that I have to visualize myself in other languages wich have more syntax sugar.

tromp 10y ago
Lisp has the minimal syntax for lists: (a b c d) where other languages require separating commas, but Haskell has minimal syntax for function application: f x y z with no parenthesis needed. (Technically, this is a triple application ((f x) y) z, masked by the convention of application being a left-associative binary operator.)
- chirau 10y ago
  How would you write f((x y)z) in Haskell?
  - deleted 10y ago
    [deleted]
  - scriptdevil 10y ago
    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)
  - tromp 10y ago
    f (x y z)
  - vq 10y ago
    If by (x y) you mean x(y) then I would write it like this: f (x y) z
- kazinator 10y ago
  That is "minimally punctuated syntax". What we want is a "minimal correspondence between written syntax and the AST"; that is what is really meant by "Lisp has minimal syntax". 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.
- wtetzner 10y ago
  Right, Haskell's function application syntax is more "minimal" that Lisp's, at least in the simple case. 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.
lmm 10y ago
It makes e.g. arithmetic expressions look rather awkward.
- golergka 10y ago
  That's if you choose to think abiut them as arithmetic expressions and not function applications. If you work with arithmetic expressions a lot, you should probably use appropriate domain language - in fact, you can build it in Lisp itself.
  - lmm 10y ago
    You can write a reader macro (in lisps that permit them, otherwise you've got no hope) but that's just lisp-speak for "program that parses strings". A language where you can use infix notation within the language is much nicer.

karmajunkie 10y ago

That's a pretty subjective opinion... I don't have much trouble with lisp but Haskell makes my eyes bleed. Of course I'm not a Haskell programmer, so it stands to reason that those who are find its syntax enjoyable. To each their own...

Tarean 10y ago
I think haskell's syntax is extremely beautiful. However code that uses two dozen operators in half as many lines is incredibly ugly in any language and doing that can be quite tempting in haskell. 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)) Operators for precedence: n <- textInput $ def & set textInputConfig_inputType "number" & set textInputConfig_initialValue "0" Alias for function: n <- textInput $ def & textInputConfig_inputType .~ "number" & textInputConfig_initialValue .~ "0"
c3534l 10y ago
> That's a pretty subjective opinion 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.
- karmajunkie 10y ago
  yeah, I don't think that's true. Neither Clojure nor Haskell seem to have any problems finding adherents, nor does the functional paradigm itself seem to be in danger of... anything. Your personal distaste for parens isn't much evidence to support the idea that they are antithetical to the growth of functional programming, nor my own distaste for Haskell evidence of the same.

deleted 10y ago

[deleted]

simplify 10y ago

I find lisp to be the most beautiful and readable language. Lisp has practically zero syntax; all code can be written equally. You can even create your own "syntax" / language features without waiting years for the approval of a committee (I'm looking at you, JavaScript). What repetition are you referring to?

BoiledCabbage 10y ago

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

agumonkey 10y ago

sml is uber cute, probably the only syntax I enjoy more than sexps. I never got the people with problems regarding lisp thin syntax. - 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.

sedachv 10y ago

> I think you should really be pushing more for SML or Haskell or something like that. 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.html https://www.haskell.org/onlinereport/haskell2010/haskellch10... [2] http://trevorjim.com/haskell-is-not-context-free/ http://trevorjim.com/haskell-is-not-context-free/

c3534l 10y ago
I do like OCaml, but have never had the opportunity to write more than a few toy programs for fun. I put SML in there just to be like "and other ML-family functional programming languages." Haskell is complicated, but some complication is needed and that's more of a learning-curve problem. If humans were capable of simple, we'd all be typing 1s and 0s. We do better with grouping, context, similar things being similar and dissimilar things being dissimilar. I don't think Lisp is the way forward for functional programming.
- sedachv 10y ago
  > Haskell is complicated, but some complication is needed and that's more of a learning-curve problem. 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.

davexunit 10y ago

Lisp is not a functional programming language.

drdre2001 10y ago
How? Functions are first class in lisp.
- crimsonalucard 10y ago
  First class functions do not make a programming language functional.
- davexunit 10y ago
  Functional programming is but one of the many paradigms that you can use in Lisp, along with imperative, object-oriented, relational, etc. When you say a language is a functional language, you are saying that it is the paradigm supported, which is not the case here.
  - concede_pluto 10y ago
    Lisp has lots of mutable types and lots of ways to smuggle them into and out of a procedure. I'd say pure functions are tolerated but not supported. Still hard to beat for creating domain-specific languages, though, and a carefully designed DSL can rule out nondeterminism and side effects.
    - davexunit 10y ago
      A language need not force purity to allow for purely functional programs. Besides, purely functional languages all need a way to cheat to actually do anything useful. Any nontrivial program needs a mix of paradigms.