> Why is a stack based language any less able to do that?
Having to juggle the stack at every step (i.e. FORTH) is a mental burden. It forces you to organize your thoughts in a certain - not necessarily harmful - but very specific way.
> Other than that, well, it's a Lisp
A Lisp unworthy of the name; one which encourages users to pepper their code with opaque routines which have no underlying Lispiness. A Lisp which barfs Java stack traces.
Forgive my bluntness, but I was rather hoping to peel back the emotive language and ideological rhetoric and have an objective and technical discussion.
I gauge programming languages by their effectiveness at solving practical problems. Do you believe Clojure's design makes it less effective at solving problems than other Lisps? Or are your objections to it purely ideological?
Yes, Clojure is less effective than other Lisps. And Symbolics Genera remains my standard of comparison. You cannot un-create it. The standard of comparison for a technology will always be everything previously achieved by mankind, rather than what is available on the market today.
Bu I will try to explain my real objections.
"Beauty is the first test: there is no permanent place in the world for ugly mathematics." (G. H. Hardy)
I was drawn into programming at an early age because it seemed beautiful and allowed me to run wild with creative ideas. Thus I insist on systems with a purely minimal amount of accidental complexity - so as to leave the most room in my head for the ideas I am trying to put into practice. I have zero interest in "programming as construction work" - implementing the ideas of others, or for that matter doing anything which isn't in some important sense original. Thus I want my programming environment to resemble pure mathematics, where absolutely nothing is present for which there is not an ironclad and inevitable logical reason, where everything is open to question, and the answer is never "because the drunken intern wrote it that way five years ago."
Most of the "practical problems" programmers supposedly "solve" shouldn't even exist. They are created through the idiocy of other programmers. In particular, I am talking about any situation where the output of one program requires "glue" to match the input requirements of another; or any situation where formats are converted; and many other cases. If the moronic mistakes of the past four decades were undone, most of the people who are calling themselves programmers would have to find honest work.
Screw "practicality." Programmers are the proverbial firemen who start fires when they aren't at the station-house, and gloriously put them out, hailed as heroes every time.
Clojure will never be beautiful because it promotes the use of undigestable foreign matter in Lisp code: primitives on which you cannot pop the hood to reveal more Lisp, with turtles all the way down. Its claim to the name Lisp is in an important sense fraudulent. I rest my case.
Your criticism of Clojure is based upon aesthetic ideals, then, rather than practical or technical considerations. However valid this criticism is, it's not something I have a particularly strong interest in, I'm afraid.
So aesthetics of any kind are foreign to you? Or just in relation to programming? Are you equally eager to sit down on a pile of bricks as on an Aeron?
No, but I'd rather have a fast ugly car than a slow pretty one.
I think I disagree with you on two points. I place a higher emphasis on efficiency than I do aesthetics; I want a language that allows me to do things quickly. I also have a slightly different idea of programming language beauty than you do. I like languages that have an small but expressive syntax and a concise core library. Clojure fits that definition better than any other Lisp I've found, so from my point of view, it's the most beautiful Lisp as well as the most practical.
But aesthetics are subjective, which is why I dislike arguments about them. I don't particularly care what language a library function is written in, just so long as it integrates elegantly with the language I'm working in. You might think that using external libraries is aesthetically displeasing, but that's a subjective opinion.
What I am interested in discussing are technical details about a language, as they are entirely objective. We can discuss whether a particular language produces more concise code than another, and come up with examples to prove it. I like those sorts of discussions, because even if I don't agree, I'll always come away with a better understanding of the favoured language of the other guy.
By contrast, arguments over aesthetics just seem pointless, as neither participant will learn anything or change their view.
Having to juggle the stack at every step (i.e. FORTH) is a mental burden. It forces you to organize your thoughts in a certain - not necessarily harmful - but very specific way.
> Other than that, well, it's a Lisp
A Lisp unworthy of the name; one which encourages users to pepper their code with opaque routines which have no underlying Lispiness. A Lisp which barfs Java stack traces.