[defined]

> 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]

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]

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]

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.

[wostusername]

>(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.

[ken]

I once took some small but substantial pieces of code I'd written in Java, ported it to Lisp, and counted the grouping characters in each. Java had fewer parens, but many more grouping characters {}[]() overall. I think it was in the neighborhood of 50% to 100% more.

It's easy to prove anything with a sufficiently small micro-benchmark. But "one line of Java" is not equivalent to "one line of Lisp", and even if it were, nobody writes Lisp code in a style that looks like a one-to-one mapping of some Java code.

This is like complaining that Japanese is inefficient because it has thousands of characters, or that English is inefficient because it takes dozens of characters to say what only takes a couple in Japanese. The concepts aren't exactly the same, and you can't just pick a trivial example and conclude that "this has fewer than that".

[blunte]

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.

[kazinator]

Even math notation dispenses with the silly commas in matrix notation, which so nice it gets used for vectors also.

[kazinator]

That parenthesis around let is important; it precisely delimits the scope for that x and y:

    (let [x 5 
          y 10]
      (foo x y))
    (foo x y) ;; now different x and y!

In C, I'm often doing:

  {
    foo *ptr = ...; // scope this just to this block.

  }

I don't want ptr to be visible other than in that block, especially if it has gone invalid/null.

The braces will be there if you program sanely and care about scope.

[kgwxd]

The first example is missing the scope brackets likely enclosing the expressions, and there should probably be a few semi-colons.

[wostusername]

>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)))

[emsy]

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]

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]

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.

[blunte]

> Pretending this problem doesn't exist

Young children tend to look with disgust upon many meals that adults find especially delicious. Is it a problem with the food, or is it a matter of experience and perspective?

I'm very tempted to give examples, but it's not worth it here. Suffice to say, this falls squarely in the category of "you don't know what you're missing".

In this long essay by Paul Graham - http://www.paulgraham.com/avg.html - if you're willing to search for and begin reading at "The Blub Paradox", you'll get a sense of what I mean.

And then if you want to really be enlightened, at least to concepts that really what matter regarding programming languages, go watch videos from Rich Hickey (Clojure).

[allover]

> "you don't know what you're missing".

I think I do. I've had the argument many times here, code-as-data, metaprogramming, structured-programming. Things I don't want, aren't worth the trade-off, and things I don't want to see colleagues inflicting on others.

I've already watched (almost) every Rich Hickey video (well his main "talks"). I love them, agree with the vast majority of what he says and it has shaped me as a programmer, but I don't agree with the final conclusion being to code using lisps ;)

[Roboprog]

That wasn’t very nice, but it felt spot on.

Curly braces are the chicken nuggets and fries of computer science, lol.

Within about 18 months at university (80s), I learned BASIC, FORTRAN, Pascal and Lisp. Syntax, yeah, whatever.

(We transitioned to C later, to my horror, with an eye towards a future using “C with classes”)

[allover]

> Syntax, yeah, whatever.

The vast majority of the programming world simply doesn't seem to agree.

[setr]

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]

> 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]

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]

> 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).