6 ms·

> I know some folks sneer a little at Lisp I wonder why. Some developers I know and hold in high regard have almost venerated Lisp, so I've always thought the

> I know some folks sneer a little at Lisp I wonder why. Some developers I know and hold in high regard have almost venerated Lisp, so I've always thought there must be something to it. I just thought it wasn't something you could actually use IRL, but I was wrong. I found this out when I was recently motivated to learn Clojure, and now I am starting to grok their admiration.

blunte 7y ago
It will depend on whom you talk to - perhaps how old they are, and certainly where they come from (experience wise, education wise, etc.) The usual easy excuse is about parens, but that complaint has been put to rest so many times that it's not worth replying to anymore. (And people said the same thing about Python whitespace, but now Python is at or near the top of the pile.)
- gherkinnn 7y ago
  Python has too few parentheses, Clojure has to many. There’s just no winning. Ultimately, these complaints are superficial and serve only to justify one’s laziness.
  - blunte 7y ago
    Clojure has the same number of parens as Javascript, C/C++, Java, and similar languages have parens+squiggle-brackets. (print "foo") vs print("foo"). same same. There's so much more to it than this. I can say without reservation that people who do not take a couple/few weeks to learn a Lisp just do not know what they are missing, and their arguments against it are viewed as children who lack enough experience to know what they are rejecting.
    - deleted 7y ago
      [deleted]
    - wostusername 7y ago
      >(print "foo") vs print("foo"). same same. If you look at things other than function calls, it starts to look different: let x = 5, y = 10 foo(x,y) vs (let [x 5 y 10] (foo x y)) I actually like Lisps and think the S expression syntax is one of their best features, but I'm not going to pretend there are the same number of brackets in Lisps as there are in C family languages.
      - kgwxd 7y ago
        The first example is missing the scope brackets likely enclosing the expressions, and there should probably be a few semi-colons.
        wostusername 7y ago
        >The first example is missing the scope brackets likely enclosing the expressions Sure, but so is the Clojure one. So I guess it's more like: fun bar () { let x = 5, y = 10 foo(x,y) } vs (defn bar [] (let [x 5 y 10] (foo x y)))
        blunte 7y ago
        1st example: 10 symbols: (){=,=(,)} 2nd example: 10 symbols: ([]([]()))
        lkschubert8 7y ago
        The clojure example was not missing the "scope brackets". That's exactly what let is. The equivalent c like in your first example should just be enclosed in brackets.
      - blunte 7y ago
        I can't reply to your lower example because it's too deep, but I would point out that clojure does not have the other symbols - equal and comma. In your lower example, Clojure has only one more non alphanumeric character than the other example. Furthermore, in Lisp, you always know that you have (function-name param param etc). Reading it becomes not just easier - it removes an entire layer of abstraction (syntax rules). Also, with smart editors, you gain the ability to move these around rapidly in ways that you simply cannot do with other languages. Funny thing is, the biggest annoyance I have when not using Clojure is having to type commas between items in data structure. [1 2 3 4 5] just looks so much cleaner than [1, 2, 3, 4, 5]. I forget who wrote it, but they complained of seeing all the mouse turds "," in normal programming languages.
    - emsy 7y ago
      Oh sure what’s the number of parens for (+ 1 (* 2 (/ 3 4))) in C? Granted, you don’t have to bother with precedence in Lisp
      - blunte 7y ago
        I'd bet there have been more bugs related to implicit operator precedence compared to ( ) explicit. And given that it's numeric operations, I'll bet some were very costly...
  - allover 7y ago
    There's a huge difference. The parens in lisps are significantly detrimental to its first impression, and 3rd, 4th ... I have literally never met a developer I can show a lisp code sample to whose reaction isn't "what the hell is that?" It looks totally alien compared to C-style langs, which is what most people learn. With Python, that is not the case at all, basic Python can be interchanged with pseudo-code for the majority of developers from C-style backgrounds. Pretending this problem doesn't exist, only exacerbates it, and really holds back lisp adoption in my opinion.
    - setr 7y ago
      The claimed problem that exists however is... lame. It really boils to "if it doesn't look like C, I'm not learning it", which is a fairly pathetic argument, and not one that can actually be bested with any targeted marketing or discussion. Most developers only learn a new language because they're forced to: at work, or joining an existing project as part of their hobby, or because the library they need requires it, or because its the only option available to them. At the point, the fact that it looks like C, or doesn't, won't matter. And they'll get over it. No one claims Nginx/Apache DSL is great, or terribly C-like. Or even really claim that its un-C-like. But I'll reluctantly learn it (to a minimum need) because I want my damned site up. Most languages are learned like that. Developers who learn a new language for the sake of learning a new language will likely not be drawn in by it being C-like syntax, or not. At least, most who've gone around that rodeo a few times will quickly realize that the superficial syntax isn't that interesting -- It takes 20 minutes to learn the syntax (maybe not APL). You're in it for the different semantics. What you need for mass lisp adoption is to get a hype cycle going, and pathetic justifications for parenthesis isn't going to get you there. Babbling about how hyper-parameterized cooperatively consistent parenthesized datastructures will change the world is likely more effective.
      - tincholio 7y ago
        > It really boils to "if it doesn't look like C, I'm not learning it" I think it's funny that most people who complain about this are likely coming from Java, JS, or Python, not C. And they probably would suffer a lot in C... I've made the jump to Clojure, and to be honest, it's painful going back to other languages, but not just because of the syntax, but rather the lack of expressive power, and the excess of boilerplate. I had to do some Python work last year, and it felt like coding with a straightjacket on.
kgwxd 7y ago
I think the ideas spelled out in rationale are really what sets Clojure apart from all the other lisps. For decades, I got excited every time a new idea around lisp or functional programming and I'd play with them for weeks. Eventually, I'd get to the big question, how do I bring this idea into development environment that solves the hundreds of other ugly real-world problems I have to deal with to make a usable application? Clojure solves that by being hosted. Immutable data structures are great, but when it's the default, it's a huge win in cognitive-overhead. Maybe that feature isn't unique to Clojure but it's certainly not a prerequisite to being called a lips or a functional language. Singly-linked lists are cool, but almost every other type of list is cooler, being able to read, eval and print those as well is really cool.
- defined 7y ago
  > Immutable data structures are great, but when it's the default, it's a huge win in cognitive-overhead. Maybe that feature isn't unique to Clojure but it's certainly not a prerequisite to being called a lips or a functional language. Yes, indeed. TBH, I developed in Erlang for 10 years and, as a result, developed a strong preference for "immutable data structures everywhere". Unlike LISPs that I've seen (admittedly not that many), with Erlang there simply is no global data so no vars to change - it's all done via function parameters and tail recursion (Erlang has TCO baked in, btw).

blunte 7y ago

It will depend on whom you talk to - perhaps how old they are, and certainly where they come from (experience wise, education wise, etc.) The usual easy excuse is about parens, but that complaint has been put to rest so many times that it's not worth replying to anymore. (And people said the same thing about Python whitespace, but now Python is at or near the top of the pile.)

gherkinnn 7y ago
Python has too few parentheses, Clojure has to many. There’s just no winning. Ultimately, these complaints are superficial and serve only to justify one’s laziness.
- blunte 7y ago
  Clojure has the same number of parens as Javascript, C/C++, Java, and similar languages have parens+squiggle-brackets. (print "foo") vs print("foo"). same same. There's so much more to it than this. I can say without reservation that people who do not take a couple/few weeks to learn a Lisp just do not know what they are missing, and their arguments against it are viewed as children who lack enough experience to know what they are rejecting.
  - deleted 7y ago
    [deleted]
  - wostusername 7y ago
    >(print "foo") vs print("foo"). same same. If you look at things other than function calls, it starts to look different: let x = 5, y = 10 foo(x,y) vs (let [x 5 y 10] (foo x y)) I actually like Lisps and think the S expression syntax is one of their best features, but I'm not going to pretend there are the same number of brackets in Lisps as there are in C family languages.
    - kgwxd 7y ago
      The first example is missing the scope brackets likely enclosing the expressions, and there should probably be a few semi-colons.
      - wostusername 7y ago
        >The first example is missing the scope brackets likely enclosing the expressions Sure, but so is the Clojure one. So I guess it's more like: fun bar () { let x = 5, y = 10 foo(x,y) } vs (defn bar [] (let [x 5 y 10] (foo x y)))
        blunte 7y ago
        1st example: 10 symbols: (){=,=(,)} 2nd example: 10 symbols: ([]([]()))
        lkschubert8 7y ago
        The clojure example was not missing the "scope brackets". That's exactly what let is. The equivalent c like in your first example should just be enclosed in brackets.
    - blunte 7y ago
      I can't reply to your lower example because it's too deep, but I would point out that clojure does not have the other symbols - equal and comma. In your lower example, Clojure has only one more non alphanumeric character than the other example. Furthermore, in Lisp, you always know that you have (function-name param param etc). Reading it becomes not just easier - it removes an entire layer of abstraction (syntax rules). Also, with smart editors, you gain the ability to move these around rapidly in ways that you simply cannot do with other languages. Funny thing is, the biggest annoyance I have when not using Clojure is having to type commas between items in data structure. [1 2 3 4 5] just looks so much cleaner than [1, 2, 3, 4, 5]. I forget who wrote it, but they complained of seeing all the mouse turds "," in normal programming languages.
  - emsy 7y ago
    Oh sure what’s the number of parens for (+ 1 (* 2 (/ 3 4))) in C? Granted, you don’t have to bother with precedence in Lisp
    - blunte 7y ago
      I'd bet there have been more bugs related to implicit operator precedence compared to ( ) explicit. And given that it's numeric operations, I'll bet some were very costly...
- allover 7y ago
  There's a huge difference. The parens in lisps are significantly detrimental to its first impression, and 3rd, 4th ... I have literally never met a developer I can show a lisp code sample to whose reaction isn't "what the hell is that?" It looks totally alien compared to C-style langs, which is what most people learn. With Python, that is not the case at all, basic Python can be interchanged with pseudo-code for the majority of developers from C-style backgrounds. Pretending this problem doesn't exist, only exacerbates it, and really holds back lisp adoption in my opinion.
  - setr 7y ago
    The claimed problem that exists however is... lame. It really boils to "if it doesn't look like C, I'm not learning it", which is a fairly pathetic argument, and not one that can actually be bested with any targeted marketing or discussion. Most developers only learn a new language because they're forced to: at work, or joining an existing project as part of their hobby, or because the library they need requires it, or because its the only option available to them. At the point, the fact that it looks like C, or doesn't, won't matter. And they'll get over it. No one claims Nginx/Apache DSL is great, or terribly C-like. Or even really claim that its un-C-like. But I'll reluctantly learn it (to a minimum need) because I want my damned site up. Most languages are learned like that. Developers who learn a new language for the sake of learning a new language will likely not be drawn in by it being C-like syntax, or not. At least, most who've gone around that rodeo a few times will quickly realize that the superficial syntax isn't that interesting -- It takes 20 minutes to learn the syntax (maybe not APL). You're in it for the different semantics. What you need for mass lisp adoption is to get a hype cycle going, and pathetic justifications for parenthesis isn't going to get you there. Babbling about how hyper-parameterized cooperatively consistent parenthesized datastructures will change the world is likely more effective.
    - tincholio 7y ago
      > It really boils to "if it doesn't look like C, I'm not learning it" I think it's funny that most people who complain about this are likely coming from Java, JS, or Python, not C. And they probably would suffer a lot in C... I've made the jump to Clojure, and to be honest, it's painful going back to other languages, but not just because of the syntax, but rather the lack of expressive power, and the excess of boilerplate. I had to do some Python work last year, and it felt like coding with a straightjacket on.

kgwxd 7y ago

I think the ideas spelled out in rationale are really what sets Clojure apart from all the other lisps. For decades, I got excited every time a new idea around lisp or functional programming and I'd play with them for weeks. Eventually, I'd get to the big question, how do I bring this idea into development environment that solves the hundreds of other ugly real-world problems I have to deal with to make a usable application? Clojure solves that by being hosted. Immutable data structures are great, but when it's the default, it's a huge win in cognitive-overhead. Maybe that feature isn't unique to Clojure but it's certainly not a prerequisite to being called a lips or a functional language. Singly-linked lists are cool, but almost every other type of list is cooler, being able to read, eval and print those as well is really cool.

defined 7y ago
> Immutable data structures are great, but when it's the default, it's a huge win in cognitive-overhead. Maybe that feature isn't unique to Clojure but it's certainly not a prerequisite to being called a lips or a functional language. Yes, indeed. TBH, I developed in Erlang for 10 years and, as a result, developed a strong preference for "immutable data structures everywhere". Unlike LISPs that I've seen (admittedly not that many), with Erlang there simply is no global data so no vars to change - it's all done via function parameters and tail recursion (Erlang has TCO baked in, btw).