Basically, I think it's a marketing problem.
I've heard Lisp described as an autistic language, and I think there's something to that. I don't think it's for everyone. I'm not on board that macros, homoiconicity and some of the other stated benefits of lisps are worth 'giving up syntax' for and I am far from convinced that lisps are the future of programming.
I'm a huge fan of Rich Hickey and I want to love Clojure, I just can't. It's not for me and it's not a marketing thing. Rich is the best marketing a language could hope for.
You may already have heard about those things - but I just thought I'd mention them on the off-chance you haven't.
Personally I find the syntax a lot easier to read - less giving up syntax than eliminating what's always looked like a bit of a mess to me ^^ Though, horses for course maybe, as you say.
That is there always seems to be at least as much of a subtext of Clojure defining itself by what it isn't as an explicit statement of what Clojure is. So much of what is said about it is said in the context of "Clojure is not Java, or Haskell, or Scala, or Scheme, or Common Lisp" and because that is so much a part of its culture, it has details drawn from 'the best parts' of each and mashed up.
Like Common Lisp, it is a language for working programmers and will trade practical accretion over striving for internal conceptual consistency. Unlike Common Lisp or Scheme, it doesn't have the sort of simple core that lends itself to tutorials from first principles and even if it did, the community tends to be experienced where just jumping into the middle is more the norm.
That's nothing against Clojure. It's just that any sort of gentle introduction to Lisp is probably better sought in those places where it already exists - SICP or the Racket ecosystem or Practical Common Lisp or PG's On Lisp are probably better introductions to what makes Lisp different. Clojure is probably a better second Lisp dialect for many people once they are ready for full tilt production code.
loop/recur is of course much less powerful than TCO, because the JVM doesn't natively support it (it's not trivial, security wise). There are three other Lisps on the JVM that I know of: SISC Scheme is mostly dead but does TCO at a cost in speed, Kawa Scheme has as of late added fine grain control over TCO, and Armed Bear Common Lisp doesn't try, as Common Lisps are not required to.
But loop/recur sure looks to be ultimately inspired by Scheme style use of TCO; I just did a set of functions using it for the first time and everything I learned from SICP/6.001 applied and made that part of it trivial.
> But loop/recur sure looks to be ultimately inspired by Scheme style use of TCO;
To me it looks more like ancient Lisp with prog and goto.
(defun foo ()
(prog ((a 1))
start
(print a)
(when (< a 10)
(incf a)
(go start))))
Is there something in particular you're having a hard time with, out of curiosity? I don't consider myself particularly brilliant but I didn't have a year's worth of trouble with Clojure.
I learned Scheme over 20 years ago and it wasn't that hard to use it for small college projects. But that's different from being comfortable working with large code bases full of unfamiliar code.
Languages shouldn't be judged by how easy it is to write code, or read your own code, but rather how easy it is to jump into someone else's project and figure out what they did. The level of understanding should be enough to see security bugs when they screwed up.
Horrible as c++ might be in many respects, the elaborate and somewhat stereotyped syntax of the code some random person wrote does tell a story.
If the code uses the horrific "one big loop" convention, it's fairly easy at least to get that that is what's going on.
I've only occasionally scanned Lisp code but in my experience of this, it seems like the formatting of the code doesn't a clue about the programming idiom being used. Admittedly, part of this is that Lisp allows more and more powerful idioms. This part seems really cool by itself.
Despite that coolness, I think one has to admit there's a cost here, the cost of a large block of code not being graspable by an outsider.
Perhaps the subset of C++ used reveals something about the development team that wrote it I guess? But there are certainly analogous things in lisp. Is the code macro heavy or light? Was the developer trying to treat the language like an imperative language, or functional? Massive monolith functions, or many small almost mathematical functions? Comments, or no comments?
I think that C++ and Lisp might actually be relatively unique in that respect. You typically don't see much variety in Java (beyond "This code was clearly written by a C developer who wishes he could just use C for this", which comes through loud and clear sometimes), and even less in Python.
Where I ran into trouble was not the strangeness of the syntax, but the sparseness: "It takes a macro to write a decent loop? Isn't that telling you that your basic syntax is ridiculously impoverished?" I mean, yes, you can implement absolutely anything, but in the bare syntax, you're given absolutely nothing.
Second trouble spot: Lack of static types. It makes it hard to reason about a function if I don't know what's passed into it. I have to read the code and guess, from what it does, what the form of the arguments were supposed to be. And every caller has to know it, and to follow it. If they don't, chaos will ensue, unless the function defends itself by checking the arguments. But that means verifying, by examination, that what got passed in is what was expected - not the easiest task.
Now, Lisp people say that this isn't a problem in practice, because as you play with the code, if the wrong thing happens it will throw you into the debugger. But different code paths wind up getting exercised in the wild, and I've spent most of my career in embedded systems. Dropping into a debugger is not an acceptable bug-handling strategy in my world. I'd rather have the compiler catch them.
> "It takes a macro to write a decent loop?"
That's the usual way to introduce a LOOP. As most Lisp implementations are written in Lisp, most syntactic constructs are macros anyway - whether they are at the language or the user level. For many Lisp systems there is really no distinction between both.
> Dropping into a debugger is not an acceptable bug-handling strategy in my world.
For embedded programming Lisp can have a lot of problems:
* lack of compile time safety
* the need for Garbage Collection
* no low-level machine types
* more...
Since the nature of 'embedded' is changing, some of that might no longer be such a big problem. In some areas 'embedded' systems are suddenly actually full-blown connected computers.
All languages must reduce to a limited ISA of primitives (or conversely, all HLL are built on small ISAs). Lisp does a lot of this conversion early on (because it can) while C does this much later (because it can't do it early). You're simply quibbling about how soon to do this conversion. LLVM does the same thing as lisp in that it reduces a seemingly large language into a small set of constructs (and then works to optimize this small core language). I would argue that a smaller core language is better because it is easier to reason about and easier to optimize.
As to embedded, iRobot corporation created a lisp variant called L (based on a subset of common lisp) to use on their embedded processors via a bytecode VM.
http://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf
Check out shen lisp (link below). It has (to my knowledge) the world's only Turing complete static typing system. Racket also has a static variant. Common lisp can be made into the equivalent of statically typed if you (declare) all variables and tell it to fully optimize.
If you want an "until" construct in Lisp, you can create one with macros easily and doing so would be considered fairly kosher. If you want an "until" in C, you could swing it with macros, but you'd be told to buzz off when it came time to receive code reviews for it.
[1] http://www.letras.ufrj.br/poslinguistica/recursion/papers/17...
That is pretty much what I meant. But given that the language expressions people are exposed to in their lives before LISP inherently aren't going to look like LISP, this a "marketing problem" that isn't going to go away. LISP doesn't look like natural language, that won't change and will always be hard for people to get over.