Of Weighty Matters, or Thumbs Still Down for Clojure.
Ah, Clojure.
The nice, clean replacement for Common Lisp -- as some would have you believe.
I haven't forgotten about you.
Clojure is a nice, clean replacement for Common Lisp only if thumbs are nice, clean replacements for cars.
But wait, we're dealing with something more than a mere lightweight hitchhiker on the JVM:
"...Clojure's library is still growing. The Var count has increased by 50% in the last two years... At this rate, Clojure 1.6 will have a bigger standard library than Common Lisp. (The timing depends on how quickly parts of clojure.contrib get assimilated into clojure.core.) I suppose when that happens, Common Lisp will still be perceived as huge and bloated, and Clojure as relatively small and clean."
"Clojure is almost as big as Common Lisp." (Arcane Sentiment)
Looks like this particular thumb already weighs more than my car.
On top of it all: why should we not count all of the definitions available to the programmer in a freshly-installed copy of the development system? Let's add Java's definition count to Clojure's total! It would be perfectly fair.
Now the thumb weighs as much as a loaded freight train...
Would anyone care to post the corrected count?
The main problem with Clojure is the extent to which it abandons the virtues of Lisp in the name of interoperability. Consider case sensitivity, Clojure gives into most of the non-Lisp world by including case sensitive identifiers such as the barely-readable camel case identifiers of Java into the language.
The problem with this is that one of the first steps we must take to get past traditional text languages is to use *speech recognition* as an alternative to keyboards, and the first step towards achieving that is to abandon the semantic meaning of graphical characteristics of our identifiers, such as case.
Some programming languages (namely Haskell) are even worse in this respect because they explicitly enforce case semantics. We can't certainly can't have anything to do with that if we are going to fix computing.
Dear jhuni,
Speech recognition?
Yuck. Count me out.
I don't even care if it were 100% accurate.
I hate talking, and love keyboards.
Yours,
-Stanislav
Dear Stanislav,
You said "I love keyboards." If this is the case then this is an issue on which we differ. I strongly oppose extant text based formats which are our product of a long history of (QWERTY) keyboard use. Using homoiconic languages like Lisp and experimenting with non-keyboard input methods like touch and speech will help us to escape our dependence on text.
I am currently working on building a visual programming editor with Clojure and Piccolo 2D which I discussed in more detail in a reply to Programmer's Editors, Illustrated. I admit that Clojure has flaws such as excess weight and case sensitivity but my current contention is that it is the best environment from which to build an alternative development system which doesn't have these flaws.
Dear jhuni,
I do agree that storing code as plain ASCII text (with all of the resulting idiocies like the "tabs vs. spaces" holy war) is preposterous. But humans invented written language for a reason.
And I am all for experimenting with unusual input devices. But I have yet to hear of anything which even begins to compare with a keyboard - yes, even the monstrous QWERTY - in terms of bandwidth, accuracy, and sheer minimality of physical effort.
Have you ever actually used a speech recognition system to enter serious lengths of text? I urge you to try it. There is no shortage of "working" products of this kind. Or: you could simply re-program your computer to substitute a wrong yet similar-sounding word for every 25th (or so) word you type. This should more-or-less simulate the experience of using the best-known voice recognition systems.
Yours,
-Stanislav
Dear Stanislav,
Lisp identifiers have a one-to-one correspondence with their pronunciation, for example the Emacs Lisp command clipboard-kill-ring-save can be pronounced as "clipboard kill ring save." This correspondence allows for commands to be communicated through sound without ambiguity. The point I was trying to convey in my original reply was that pronounceable identifiers make for good voice commands not that users should be entering serious lengths of text using voice.
The Lisp dialects are the only languages available today which have the features such as homoiconicity and comprehensible identifiers which are necessary to provide an alternative to the plain text file programming paradigm. However, in the name of interoperability Clojure code is sometimes polluted with incomprehensible camel case Java identifiers such as setDefaultCloseOperation, checkCreateClassLoader, ByteArrayInputStream, ArrayIndexOutOfBoundsException, etc. I long for a Lisp which isn't polluted with the idioms of its host platform.
what about stenographic keyboards?
Dear another,
Stenotypes are optimized for natural language rather than general-purpose character input. Therefore entirely uninteresting to me.
Yours,
-Stanislav
That could be interesting for languages with NL input, even though those are generally horrible. (Though I can see their usefulness for specific purposes with non-technical users).
@jhuni: Lack of case sensitivity in the 21st century is ridiculous. It is not like we need a minuscule performance boost by sticking to uppercase or some arcane hacks if there were only some lower power of 2 characters in a symbol. Lisp is great but it is not great because it is lowercase. Don't be a lisp caveman.
Dear Seren Seraph,
The fact that it is the 21th century is all the more reason that we shouldn't be dependent upon text or case. In this day and age we should be using a development environment that is indistinguishable from magic yet we are stuck using archaic text file editors like notepad.
Right, finally an argument here besides the usual "Clojure is a Lisp zombie" and stuff. But wait, what is this argument about? The number of vars? Yes, a perfect point for a millennia-old language with no namespaces support. The sad thing is Clojure actually has namespaces.
Seriously, knock it off. With ignorant posts like this you dilute the rather nice content you are writing.
Dear Alexander Yakushev,
What distinguishes Clojure's namespaces from Common Lisp's packages?
And you seem to misunderstand my argument. Complexity is a bad thing per se. Tools such as namespaces can ease the burden of dealing with complexity, but cannot eliminate it. The net effect of non-essential complexity is to make everyone who comes into contact with a system stupider, by increasing the cognitive load required to fully understand it. If I could only persuade my readers of one thing - it would be this.
Engineering complexity is a form of environmental pollution; perhaps even the worst form of all, because it may yet turn out to be the case that it can kill whole civilizations, not just individual people.
People who only want to “get things done” in engineering — with no care for design elegance and (by implication) the long-term effects of their actions — are not unlike environmental polluters. You write your program, and it appears to run, and you care not one whit that you are taking a steaming shit of kludgy complexity into the brain of every one of a thousand people who will be forced to read and otherwise interact with your creation in the future.
Yours,
-Stanislav
I'd rather have a inelegant but transparent solution than an elegent but opaque solution.
Dear another,
Why not... both ?!
"I'd rather be rich and healthy than poor and ill."
Yours,
-Stanislav
eh. I'm talking about cases where you have an inelegant but easy to understand solution versus a 'beautiful' design that's hard to understand.
Just tried CL's packages. Everything was great except I couldn't use in-package function (I was running clisp REPL). I know that clisp is not the best implementation, but however, isn't such simple thing as packages explained in the specification to implement correctly?
Well, anyway, I wasn't making an argument against CL. Let's suppose that CL and Clojure has equal power of handling and grouping symbols. Does it mean that CL is awfully complex because it's load of symbols is huge as well? Or maybe CL has a "golden, just enough of symbols" and Clojure by overcoming this number suddenly appeared to be unbelievably complex? Seriously, I could expect this kind of argument from a layman Java coder but not from a seasoned Lisp warrior.
How does the number of symbols affects complexity? By pragmatic definition complexity is the number of things I have to keep in my head at one moment of time. Do I have to keep all the symbols? Hell, no, only those I use in this moment of time. This phrase of yours: "Let’s add Java’s definition count to Clojure’s total!" is... I'm sorry to say this aloud, but it is dumb. Let's add definitions from all the existing Common Lisp libraries to CL's total! It would be perfectly fair (if we want to supply our stupid argument with even more stupid claims).
So I see only two situations here. Either you are a troll (in which case I'm being a loser to spend my time) or, as somebody mentioned earlier, you are jealous that for the first time Lisp is becoming more or less mainstreamly successful but this is not "Lisp all the way down to turtles".
Dear Alexander Yakushev,
If you want to experience a (more-or-less) standards-compliant Common Lisp for free, the two logical choices I know of are SBCL and CCL; and SLIME is a must. Common Lisp development without SLIME (or Genera/Zwei, or some future equivalent) is like driving a car without tires. Yes, it will move...
At 978 standard symbols, Common Lisp is not exactly a jewel of simplicity. Until you compare it with supposedly-superior, "modern" knock-offs.
If it is not yet clear to you that I am not trolling, then perhaps there is a catastrophic communications failure here and you ought to be reading someone else - there is plenty of Web to choose from.
As for the relationship between symbol count and complexity: it is not as straightforward as I may have implied, but it does exist. The symbol count which matters is not only the number of symbols one must think about simultaneously in routine work, but the number of distinct symbols which one might ever become aware of while working within a system. Of course, symbol count is not the only interesting measure of the intellectual "weight" of a system, but it is probably the most easily-quantified one.
It is possible to program in Clojure without making heavy use of Java, but it is quite impossible to do serious work in it without knowing Java. Even if one makes use of no Java-containing code written by others: last time I checked, Clojure barfs JVM stack traces. The kind of pieces that you get when a system breaks down actually matters.
I am not entirely unhappy that people have found yet another Lisp-like programming language to experiment with, but I do feel that the situation with Clojure is not unlike that seen in early motor cars, some of which had reins in the place of a steering wheel - but with an added twist: it is as if such cars were to be introduced again, after some cataclysm where technological civilization faded and a second Age of the Horse came. (The AI Winter, death of Symbolics.) Despite well-preserved Toyotas somehow remaining readily available (Common Lisp.)
Yours,
-Stanislav
First of all, yes, I know about SLIME. Clojure harnesses it as well.
The reason why at first I considered you were trolling was the poverty of your initial argument (or better be said, the way you presented it). Now after some word-swapping I heard something I entirely agree with - you should know Java to use Clojure effectively. This of course adds the complexity to Clojure. The question is - does this acquired complexity worth it? I think it does. You gain a platform that is being poured thousands of man-hours every year into, you gain a GC that is being optimized for you, you gain the crossplatformity basically for free. You may call that opportunism but it works after all.
I remember that you are against "just enough" approach. In the long run you are right. Neither do I state that Clojure is the language of the future. I'd be happy to use it for ten years, maybe it bit more. That is a good substitution for waiting for a second come of golden flawless Genera. When Clojure wears itself out we can do something other. Why not use it for the time being?
I must finish posting on my part here. My command of English and limited time does not allow me to write long responses like yours. Thanks for the discussion, I'm glad that it wasn't entirely useless.
Cheers.
What other modern Lisp would you use in production, on a tight deadline and tight budget? Nowadays, pragmatically speaking, there are only 2 options: CL and Clojure. I find CL disgusting (personal opinion here, don't pick on this...). Sure, you could pick a Scheme and write all the libs you need yourself, if you are a team inside a big company with enough resources to "waste" on your work, but what else besides this two could I choose for use in a startup?
(It's a sincere question, no irony here, and I know it's an old thread, so sorry for necromancing it :), but I really enjoyed reading your blog some time ago and re-stumbled upon it now, and realized that you seem to think a lot like I do and might be the right person to ask this question...)
Dear Neuron Q,
> What other modern Lisp would you use in production, on a tight deadline and tight budget?
I use SBCL, a very reasonably modern Common Lisp with plenty of up-to-date libraries available. (With Quicklisp as a very effective replacement for ASDF: auto-installs, resolves dependencies, etc.)
> I find CL disgusting (personal opinion here, don’t pick on this…
I don't particularly enjoy the "design by committee" warts of Common Lisp, but I'll take them over the misery of Java and the JVM any day of the week. (Clojure barfs Java stack traces on error conditions. That's quite enough for me, without even considering all of the other pestilential Java-isms that inevitably infect a Clojure project.)
Yours,
-Stanislav
Thank you for the reply.
So it's either CL's ugliness or Clojure's Java-ness... sigh.
I'd give so much for a Arc-like or Clojure-like Lisp-1 that would be a true independent language, not a hosted language like Clojure or a toy language like Arc that I'd be willing to start working on it myself if I'd find a couple of interested people to give a hand... I don't believe that much in the Lisp-all-way-down philosophy, not because it wouldn't be great, but simply because it's unfeasible, but I'd love a clean simple Lisp that would allow me to do real work and abstract away the details of hardware, OS and everything, be fully self-contained the way CL can feel like.
Unfortunately we make do with what we have, and CL remains the only "clean" Lisp alternative, and unfortunately I instinctively dislike it so much that I's rather pick Scala, Python or Ruby...
[...] everything previously achieved by mankind, rather than what is available on the market today. Edit: Update. This entry was written by Stanislav , posted on Thursday June 25 2009 , filed under Distractions, [...]
Hi Stansilav,
What is your reaction to this?
https://www.kickstarter.com/projects/1751759988/sicp-distilled
Dear Greg,
Same reaction as to the existence of restaurants for coprophagiacs.
Indifference - so long as I don't have to think about it.
Yours,
-Stanislav