[juol]

Sigh.

Implemented a scheme in my undergraduate days (in C), had a small love affair with LISP in general (but none with girls ... probably related).

I'll be opinionated here:

It's not readable. It really isn't. You have to be in the thick of it to see the trees. Idiomatic doesn't cut it.

Operator heavy Haskell is more readable. Most of the modern functional languages read closer to the spoken word.

I'd rather be presented with a legacy OO code base, than an LISP one if the LOC was anything significant.

I hope I don't come across as disgruntled, I am but a mere man, and I know my limits.

And still have fond memories of bedding LISP.

[weavejester]

"Implemented a scheme in my undergraduate days (in C), had a small love affair with LISP in general... It's not readable. It really isn't."

Hang on. Your opinion is that Clojure isn't readable because you didn't find other Lisps readable when you were an undergraduate? But you haven't actually tried Clojure yourself?

I have tried Clojure, and my opinion is that it's easily the most readable programming language I've found.

Clojure has very strong opinions about complexity, which in Clojure parlance is a measurement of interconnectedness between components. The language is built around the idea of reducing complexity, about making things isolated and independent. Idiomatic Clojure code therefore tends to have a very flat structure consisting of isolated functions and data structures. It has a very high degree of code reuse, because it explicitly rejects encapsulation.

Clojure's syntax may be unusual, and individual forms are more information dense than many languages, however the structure of Clojure code is often much easier to understand, and for any non-trivial piece of code, that's the hardest part of comprehension.

When I come across a new Clojure library, I'll often find myself reading a bit of the docs, then heading into the source code to get an idea of how it operates. I rarely do this with an object orientated language, as OOP code tends to be deeper, more interconnected, and because of encapsulation, have more methods to understand. Java in particular is terrible for this.

[eccp]

I've written applications using Java, Groovy, Clojure and Scala (in that order) and after Clojure, coding Scala felt specially horrible (yet another syntax to learn! ++: \ ~> and so on...).

Maybe Clojure feels odd for a few hours when coming from C-like syntax, but it becomes so obvious later on. I remember I felt terrified by the parens because I had not written anything serious in it.

[vorg]

> I've written applications using Java, Groovy, Clojure and Scala (in that order)

I'd say the most natural pathways for Java programmers upgrading their language skills are:

* from Java, to Groovy, to Clojure

* from Java, to Groovy, to Scala

* from Java, direct to Clojure

* from Java, direct to Scala

Once someone reaches Clojure and Scala, they seem unwilling to give up what they've gained (the simplicity and macros of Clojure, or the higher-order typing of Scala) to switch to something else, even when that something offers more.

[frowaway001]

> yet another syntax to learn! ++: \ ~> and so on...

Syntax? Not seeing any syntax here.

[nickik]

So you did a little lisp in your undergraduate days and now you are a expert, compared to all the people who write clojure on a daily bases and are happy with it?

Also LISP (I assume you are talking about Scheme or Common Lisp and not the 60s langauge) is not the same as Clojure. It does share some syntax and some ideas but its also very diffrent in many ways.

You might prefer your legacy java in the simple case, buts lets talk again when that java code has to do concurrency or other complex problems.

> Most of the modern functional languages read closer to the spoken word.

Its actually a absolut non-goal of clojure to 'read like the spoken word'. Its a goal of clojure to write code in a simple way, simple meaning a speration of concerns were each part is easy to reason about.

[namdnay]

> lets talk again when that java code has to do concurrency

For single-instance applications, sure. But for scalable systems, 90% of your concurrency is handled by whatever message broker you're using anyway. Tasks, Async processing, Blokcing Queues etc etc - they're all handled by your JMS provider.

[nickik]

Sure, if you have a one of solution you can take out and it works for you then it does not matter if you use clojure, php or java.

However often you find that its not enougth for you and then you will have to write some costume code yourself. You might think one message passing system is enougth but then its more and now you have to manage message from three subsystems in your application.

Ill use a langauge that makes things easy when things are easy and not very hard if they are hard.

[jbooth]

Doing concurrency right is very, very easy in just plain Java. ExecutorService is all you need, it's even 100% FP as long as you remap "anonymous class with 1 method" to "lambda" in your head.

[weavejester]

Executors solve a specific concurrency problem (i.e. futures), but they're not a general solution for cross-thread communication.

[jbooth]

Well, then there's BlockingQueues as noted above. Callables, Runnables and BlockingQueues are a great setup for CSP-style concurrency.

[fnordsensei]

I ran into LISP during my university days as well and was pretty much force fed it. I didn't want to touch it with a ten foot pole after that. However, for various reasons, I ended up using Clojure to prototype a rather large project, and was surprised at how different it felt to work with it compared to my university days, in a positive way. Might be that I had matured, I dunno.

I don't feel that there's anything particularly magical with the paren being on the left hand side of the verb that automatically makes it less readable than when it is on the right hand side of the verb.

[platz]

I think its also the indentation along with everything is an expression, formatted as a list kind of thing.

Especially that alternating pairs business.

Having to know what is a macro and what is not affects understanding how arguments are evaluated, and basically everything is an argument differentiated only by position.

I've head one should read a lisp function not from the top town or outside in, but rather from the most indented part first, and then work your way up and out to discover the definitions.

[Morgawr]

>Having to know what is a macro and what is not affects understanding how arguments are evaluated, and basically everything is an argument differentiated only by position.

The whole point of macros is that they are written in the same syntax as everything else (because of homoiconicity you can operate on your code as native data), you don't need to know what is a macro and what is not for 90% of the code you write. There are very little cases in Lisp languages in general where the difference between a macro and a function are evident, and in Clojure even less (compared to another dialect like, let's say, Common Lisp).

There are some times where that might be useful, but that's why we have a repl and macroexpand.

[platz]

Yes, they have the same syntax, but the semantics are different:

"that macro function is called and is passed the unevaluated operand forms. The return value of the macro is then evaluated in its place.

If the operator is not a special form or macro, the call is considered a function call. Both the operator and the operands (if any) are evaluated, from left to right." - http://clojure.org/evaluation

There are many macros and special forms in clojure where you have to understand that the arguments are not evaluated first - and if you try to reason about what happens as if they were eagerly evaluated you get the wrong answer or an error

[calibraxis]

> I've head one should read a lisp function not from the top town or outside in, but rather from the most indented part first, and then work your way up and out to discover the definitions.

That's why the pipeline operator (->>) is common. Then you just read it from up to down.

[davidw]

I wonder what some of the design guys would say about the information contained here and its readability:

https://github.com/stuarthalloway/programming-clojure/blob/m...

https://github.com/tcltk/tcl/blob/master/generic/tclCompile....

Grabbed at random. I think the larger indentation and fewer parens do make a difference when you squint at things.

Of course, I also think as a professional programmer, if something does the job, get over it and get on with it. I use Erlang myself, which also gets lots of syntax complaints.

[siscia]

I write clojure and a little bit of C and I find the clojure part extremely more readable...

[davidw]

Is it because it simply does a lot more with less code, though?

Just squinting at the code to see the shape of it rather than worrying about the contents, the C blocks look more distinct, to me.

[siscia]

probably every let's say "method" are cleaner, and you can actually say what is happening.

C is more dispersive...

Thought I code way more clojure than C

[thro1237]

Completely agree. Wrote some non-trivial amount of code in Clojure. But when I go back, it would take a long time to understand each line that I myself wrote. Java, for all its verbosity was readable. Going back to Python now.

[oskarkv]

It really is readable, to me at least. I just wanted to say that because some people will perhaps read your comment and take it as true, because they too struggle with it at the moment, and then discard Clojure. But I'm just in love with it---yes, the syntax.

[ehurrell]

I've spent some time writing Clojure recently and I like it, though I think there can be readability difficulties quite easily, things can at times get twisted into a functional way of doing things (the capacity for abuse of this is maybe less than OO, but can be difficult to untangle). Obviously this varies with the coder, I've kept it to small projects and it has worked well.

[cbp]

Cool story bro.

But if I may, I believe treating inanimate objects as women puts them off more than LISP.