5 ms·

Both of you miss the most obvious difference between Clojure and all mainstream languages: it's a lisp. I've had so many programmers look at code I write and p

Both of you miss the most obvious difference between Clojure and all mainstream languages: it's a lisp. I've had so many programmers look at code I write and proclaim: "wow that looks impossible because of the parenthesis" and that would never touch anything like it because it seems so different. Some people do take the time to learn how it works, but many just have a knee-jerk reaction to it and then forget about the language itself.

joelbluminator 6y ago
Can you blame them though? Look at Python/Ruby where even non developers can sometimes understand the code and then look at some crazy Haskell/Lisp expression.
- capableweb 6y ago
  Yes, I do blame them for this because if you spend 10 minutes, any programmer can learn "some crazy lisp expressions" because they are not that crazy. This knee-jerk reaction you're having is exactly the ones I'm talking about :)
  - joelbluminator 6y ago
    So you're saying there's absolutely no loss of readability in something like Lisp opposed to Python?
    - capableweb 6y ago
      I'd argue that because of the lightweightness of Lisp syntax compared to C-like languages, Lisp languages are easier to read. But then I'm a professional Clojure developer who used to do Golang, JavaScript and some other languages, but since couple of years ago only do Clojure and ClojureScript development, so I'm obviously biased. But then Python is probably the worst example to compare Lisps to, as Python sees whitespace as a significant character that can affect if the program can run or not.
    - monsieurbanana 6y ago
      Is there? I'm not convinced. I think a lot of the readability issues come from lisp syntax being unfamiliar, not from some intrinsic impenetrability. And then even more from being associated with functional programming, also unfamiliar to a lot of people. Look at common lisp nested for loop[0]. Are they really that hard to read? And then there's the minimalism of lisp syntax. Once you know how to call a function and the few data literals (list, vectors, set, ...), you know 90+% of the syntax. Compare with python, where you also need to learn class syntax, annotation syntax, for loops, if, while, comprehensions, etc. And the list keeps growing, there's new features being added continuously. In lisp, if the language introduces a new construct, it's still going to be just symbols in between two parenthesis. [0] https://lispcookbook.github.io/cl-cookbook/iteration.html#loop-3 https://lispcookbook.github.io/cl-cookbook/iteration.html#lo...
    - blandflakes 6y ago
      I'm sympathetic to the parents that it's not as bad as people say, but I'd definitely agree with you that syntax at least to me provides a lot of value. Of course, too much syntax is a problem in the other direction.
snotrockets 6y ago
I don’t think it’s the parents, but the s-expression themselves. LISPs forces you to maintain the stack for the parse tree in your head, something humans aren’t that great at — s-expressions are the programming language equivalent of center embedding, which is quite alien for human languages (the depth is three at most: compare that to your favorite lisp program)
- capableweb 6y ago
  You might be right in the first part, and the "fear" of s-expressions are only expressed as a fear of parenthesis. But on the second part I think that's the same as for most languages. You end up with nested scopes at the same degree as any c-like language really. But most lisp programmers tend to break out into new functions a bit earlier than let's say JS programmers. I'd argue that normally you'd have to keep track of less depth in a normal Clojure program than you would in a JS program, simply because of how a programmer usually works in those languages.
- kazinator 6y ago
  That's true if you write everything on one line. But how could you fail to notice that most Lisp code is written on multiple lines and indented? The structure is visually laid out, so as not to be maintained in anyone's head.
  - deleted 6y ago
    [deleted]
  - snotrockets 6y ago
    Line breaks only shorten lines, they do not change the reading direction. Yes, you can start at the bottom and read upwards, but that's unnatural for most. Compare: something.first().second().third() With: (third (second (first (something)))) The end from read must you to understand, and it gets more complicated as your code does. No wonder Clojure's threading macro is so popular, as it would allow you to write it as: (-> something first second third) Fun fact: Lisp was never supposed to be written with S-expressions. They were intermediate representation, for bootstrapping. McCarthy designed M-expression, with function notation, inflix, and sugar'd cond and list; but all that was omitted due to lack of time, and we were left with S-exps.
jeofken 6y ago
It’s just like C or JS but the first paren goes to the left of the function name.
- Blikkentrekker 6y ago
  With function calls, yes. What makes it different is that syntactic constructs are also expressed with the same syntax and there is no special syntax, so control flow constructs use a syntax similar to function calls. This is particularly exuberant in Arc where what in many languages would be: if (<cond1>) { <then expr1> } else if (<cond2>) { <then expr2> } else if (<cond3>) { <then expr3> } else { <else expr> } Would instead be: (if <cond1> <then expr1> <cond2> <then expr2> <cond3> <then expr3> <else expr>) Note the complete lack of syntax beyond a keyword having 7 arguments in order, which many find nonconsecutive to reading, and also error prone as accidentally making a typo can completely change the meaning of the program. It is thus that most Lisps have somewhat more redundant syntax: (cond [<cond1> <then expr1>] [<cond2> <then expr2>] [<cond3> <then expr3>] (else <else expr>)) Personally, I wouldn't mind that a mandatory `->` be required in between the conditions and the expression to further guard against accidental typos. I find that redundancy in syntax guards against accidental mistakes, though I have nothing against the parentheses and in fact favor them.
  - bionhoward 6y ago
    Pattern matching in rust: match x { <cond1> => <expr1>, <cond2> => <expr2>, <cond3> => <expr3>, _ => <expr>, } let message = match maybe_digit { Some(x) if x < 10 => process_digit(x), Some(x) => process_other(x), None => panic!(), }; Seems useful. Python's getting match soon too! https://doc.rust-lang.org/reference/expressions/match-expr.html https://doc.rust-lang.org/reference/expressions/match-expr.h...
  - kaliszad 6y ago
    Clojure specifically doesn't have the bracket wrapper around condition-expression pairs but syntax highlighting/ formatting considers it and aligns stuff nicely. I don't think, it is a problem that it basically is a list or function call with arguments. I do think, adding `->` just like that would be a problem because it would be very inconsistent with the syntax of Clojure.
Kototama 6y ago
I have a theory: it's because Blurp progammers learn to equate parentheses with complex (mathematical) expressions. The view of many parentheses at once must trigger an acceleration of their heart pulse.
kaliszad 6y ago
Well yes. Clojure in general tends to have less special syntax and in general is designed very consistently. What I find very useful is the threading macro ->> and -> which basically is a pipeline: (-> something (manipulation-of-something) (nextmanipulation) (anothermanipulation)) instead of: (anothermanipulation (nextmanipulation (manipulation-of-something something))) Often, you can remove some parenthesis in the first case as well. I really love this. It is also very easy to just wrap it in a let or a function. This alone should open the eyes of anybody, who has written at least some Shell script somewhere or does some data analysis. If it doesn't, maybe the person isn't actually that great of a thinker or a practitioner and you would be better off around other people professionally. Frankly, who are the people, who cannot grok moving the opening parenthesis before the method/ function? I don't think I have ever met anybody like that - I only read/ hear about such people in comments or at conferences and I haven't heard a name yet.

joelbluminator 6y ago

Can you blame them though? Look at Python/Ruby where even non developers can sometimes understand the code and then look at some crazy Haskell/Lisp expression.

capableweb 6y ago
Yes, I do blame them for this because if you spend 10 minutes, any programmer can learn "some crazy lisp expressions" because they are not that crazy. This knee-jerk reaction you're having is exactly the ones I'm talking about :)
- joelbluminator 6y ago
  So you're saying there's absolutely no loss of readability in something like Lisp opposed to Python?
  - capableweb 6y ago
    I'd argue that because of the lightweightness of Lisp syntax compared to C-like languages, Lisp languages are easier to read. But then I'm a professional Clojure developer who used to do Golang, JavaScript and some other languages, but since couple of years ago only do Clojure and ClojureScript development, so I'm obviously biased. But then Python is probably the worst example to compare Lisps to, as Python sees whitespace as a significant character that can affect if the program can run or not.
  - monsieurbanana 6y ago
    Is there? I'm not convinced. I think a lot of the readability issues come from lisp syntax being unfamiliar, not from some intrinsic impenetrability. And then even more from being associated with functional programming, also unfamiliar to a lot of people. Look at common lisp nested for loop[0]. Are they really that hard to read? And then there's the minimalism of lisp syntax. Once you know how to call a function and the few data literals (list, vectors, set, ...), you know 90+% of the syntax. Compare with python, where you also need to learn class syntax, annotation syntax, for loops, if, while, comprehensions, etc. And the list keeps growing, there's new features being added continuously. In lisp, if the language introduces a new construct, it's still going to be just symbols in between two parenthesis. [0] https://lispcookbook.github.io/cl-cookbook/iteration.html#loop-3 https://lispcookbook.github.io/cl-cookbook/iteration.html#lo...
  - blandflakes 6y ago
    I'm sympathetic to the parents that it's not as bad as people say, but I'd definitely agree with you that syntax at least to me provides a lot of value. Of course, too much syntax is a problem in the other direction.

snotrockets 6y ago

I don’t think it’s the parents, but the s-expression themselves. LISPs forces you to maintain the stack for the parse tree in your head, something humans aren’t that great at — s-expressions are the programming language equivalent of center embedding, which is quite alien for human languages (the depth is three at most: compare that to your favorite lisp program)

capableweb 6y ago
You might be right in the first part, and the "fear" of s-expressions are only expressed as a fear of parenthesis. But on the second part I think that's the same as for most languages. You end up with nested scopes at the same degree as any c-like language really. But most lisp programmers tend to break out into new functions a bit earlier than let's say JS programmers. I'd argue that normally you'd have to keep track of less depth in a normal Clojure program than you would in a JS program, simply because of how a programmer usually works in those languages.
kazinator 6y ago
That's true if you write everything on one line. But how could you fail to notice that most Lisp code is written on multiple lines and indented? The structure is visually laid out, so as not to be maintained in anyone's head.
- deleted 6y ago
  [deleted]
- snotrockets 6y ago
  Line breaks only shorten lines, they do not change the reading direction. Yes, you can start at the bottom and read upwards, but that's unnatural for most. Compare: something.first().second().third() With: (third (second (first (something)))) The end from read must you to understand, and it gets more complicated as your code does. No wonder Clojure's threading macro is so popular, as it would allow you to write it as: (-> something first second third) Fun fact: Lisp was never supposed to be written with S-expressions. They were intermediate representation, for bootstrapping. McCarthy designed M-expression, with function notation, inflix, and sugar'd cond and list; but all that was omitted due to lack of time, and we were left with S-exps.

jeofken 6y ago

It’s just like C or JS but the first paren goes to the left of the function name.

Blikkentrekker 6y ago
With function calls, yes. What makes it different is that syntactic constructs are also expressed with the same syntax and there is no special syntax, so control flow constructs use a syntax similar to function calls. This is particularly exuberant in Arc where what in many languages would be: if (<cond1>) { <then expr1> } else if (<cond2>) { <then expr2> } else if (<cond3>) { <then expr3> } else { <else expr> } Would instead be: (if <cond1> <then expr1> <cond2> <then expr2> <cond3> <then expr3> <else expr>) Note the complete lack of syntax beyond a keyword having 7 arguments in order, which many find nonconsecutive to reading, and also error prone as accidentally making a typo can completely change the meaning of the program. It is thus that most Lisps have somewhat more redundant syntax: (cond [<cond1> <then expr1>] [<cond2> <then expr2>] [<cond3> <then expr3>] (else <else expr>)) Personally, I wouldn't mind that a mandatory `->` be required in between the conditions and the expression to further guard against accidental typos. I find that redundancy in syntax guards against accidental mistakes, though I have nothing against the parentheses and in fact favor them.
- bionhoward 6y ago
  Pattern matching in rust: match x { <cond1> => <expr1>, <cond2> => <expr2>, <cond3> => <expr3>, _ => <expr>, } let message = match maybe_digit { Some(x) if x < 10 => process_digit(x), Some(x) => process_other(x), None => panic!(), }; Seems useful. Python's getting match soon too! https://doc.rust-lang.org/reference/expressions/match-expr.html https://doc.rust-lang.org/reference/expressions/match-expr.h...
- kaliszad 6y ago
  Clojure specifically doesn't have the bracket wrapper around condition-expression pairs but syntax highlighting/ formatting considers it and aligns stuff nicely. I don't think, it is a problem that it basically is a list or function call with arguments. I do think, adding `->` just like that would be a problem because it would be very inconsistent with the syntax of Clojure.

Kototama 6y ago

I have a theory: it's because Blurp progammers learn to equate parentheses with complex (mathematical) expressions. The view of many parentheses at once must trigger an acceleration of their heart pulse.

kaliszad 6y ago

Well yes. Clojure in general tends to have less special syntax and in general is designed very consistently. What I find very useful is the threading macro ->> and -> which basically is a pipeline: (-> something (manipulation-of-something) (nextmanipulation) (anothermanipulation)) instead of: (anothermanipulation (nextmanipulation (manipulation-of-something something))) Often, you can remove some parenthesis in the first case as well. I really love this. It is also very easy to just wrap it in a let or a function. This alone should open the eyes of anybody, who has written at least some Shell script somewhere or does some data analysis. If it doesn't, maybe the person isn't actually that great of a thinker or a practitioner and you would be better off around other people professionally. Frankly, who are the people, who cannot grok moving the opening parenthesis before the method/ function? I don't think I have ever met anybody like that - I only read/ hear about such people in comments or at conferences and I haven't heard a name yet.