This guy is insane, everything he writes is a lame rant about how life sucks since the demise of Symbolics.
However, I will have to say that I was initially excited about Clojure and each day become more disappointed because it really does carry with it all the baggage of Java. I had vowed to avoid CLASSPATH hell the rest of my programming days and Clojure often makes me feel like I'm lying to myself.
Yeah, you're being unfair, especially if you've used both Python and Java and consider them equivalent in terms of laborious configuration details. When I say CLASSPATH hell I mean the whole configuration mess that is maintaining a java environment. If you have any tips on making this not suck in Clojure it would be great to hear them, otherwise I am switching back to Python.
"I don’t care if everybody really _is_ more productive in Clojure than in Common Lisp."
That's where the author lost me. I'm willing to entertain the argument that a hybridization of Java and Lisp is not nearly as effective as one would hope - but the universal ultimate goal is MAKING THINGS.
Sure, just as the universal goal of companies is making money. However, sometimes it's smarter to take losses in the short term if it encourages long-term growth and sustainabiltiy. Back in programming terms, sometimes you have to constrain the things a language can make, so development will focus on using and combining the right primitives rather than tacking on new and unneccessary ones that will burden the language's future development path. Especially for mega-scale projects, considering the future usability of the language can be more important than considering the present usabiltiy.
Well hopefully they realize it won't take over the world and they are okay with that.
The minute you start doing actual work for paying clients is the minute that compromises sneak in. Certainly the last thing these people would want is for the LISP community to become like the PHP community where the few nuggets of good code are drowned out by flood of sewage. Maybe someone thinks you couldn't write code that bad in a pure LISP, but believe me you would see some pretty horrendous crap if LISP had 10% marketshare of, let's say, web programming.
Frankly, this fear just sounds too much like "Oh no, I'd hate to see anything tinge my precious baby!"
What's wrong with there being poorly written code in your favorite language? Unless these Lispers also do web development, they likely won't come in contact with the hypothetical bad Lisp-on-web code. So why should they care? Also, how is the good code drowned out? Assuming that the screening process for a job picks out good PHP developers, it isn't that hard for one to find good PHP code in the form of frameworks and libraries.
Well sure, to normal people yes. But to understand the mentality, just consider for a second that the OA is foaming at the mouth of a language that is merely inspired by LISP.
wrt the PHP thing, well, I cut my teeth on PHP, and frankly I didn't learn much by reading code I found early on. After doing it for a couple years (and completing an MIT-based CS degree) I started to discover the flaws for myself and I was eventually well-trained enough to be able to find the good code. If you know what to look for it's easy. However what's popular in PHP world (ie. what you find on Google) is not necessarily good. Compared to Ruby or Python, or hell, even Perl, it's just way harder to find good PHP code to learn from for a beginner.
Strange, most people on comp.lang.lisp seem to use Common Lisp on UNIX, Linux, Mac OS X, JVM. Many edit in Emacs or VIM. Most use some kind of X11 window system.
"The latter is not my standard of comparison (Symbolics Genera, the state of the art, is." ...
There were plenty of cool things about lisp machines. But obviously the world's taken a different direction. Nothing wrong with being an idealist sometimes, though.
Nothing wrong with being an idealist, sure. There is something wrong when someone goes out of his way to criticize something for no reasons other than "it doesn't fit how I think things should be".
For a proper criticism, I would have liked at least a little more explanation of the advantages of actually using Lisp all the way down.
I'll try my hand at that: having a system built out of a few simple types of parts interacting in tons of different ways also leads to flexibility and power. Ant hives and bee colonies work in similar ways, one individual alone is useless and will probably die soon, and having a whole mass of ants just meandering around won't get you anything. Now, create a few (by which I mean very very few) rules for what happens when an ant meets another ant, and immediately you get a structure out of it.
For example, ants have the property of laying down pheromones. The interaction rule is knowing to follow another ant's pheromones (there are some subtleties with detecting certain types, for sure, like danger signals, but we'll keep things simple). If an ant doesn't have a trail of pheromones to follow, it will wander using its senses to find food.
Combine all of this and you end up with a system that gives you the quickest way to a food source. Simply because ants who have found the shortest route to a food source will probably return soonest, and other ants follow the pheromone trails they lay down.
Note that there's no real comparison method where all the ants sit down, compare notes, and try to figure out who has the shortest path. It emerges naturally.
It is interesting, how if someone doesn't like something they seem to see it as their mission to make sure no one else uses it? (or it appears that way, what I think it really means is self promotion, and its easier to tear down then build up when building your profile in public).
Actually in this article, when I re-read it, I think it is written in a sort of ironic/fun tone.
Although I love clojure, I understand the disappointment in not being "lisp all the way down" - there is something satisfying about the purity of that approach, if it is practical. Maybe one day...
I think it's a great language. As much as I value purity from an academic standpoint, I also need to eat. I'd rather see a 90%-pure Lisp that I can get a job in than a 100%-pure Lisp that I can't.
Moreover, I think Clojure will get more Lispy, rather than less, over time. In 2015, I think far fewer people will be programming in Java full-time, and the JVM will be optimized as a VM to support higher-level languages rather than to support Java as a primary language.
If he got anything right, it's the "good enough" thing. There's a sense of reality in clojure, of compromises and of practicality.
There's also a sense of abandonment of some of lisp's dreams. There is definitely a break from the way lisp was, and it's clearly deliberate (defn vs defun for example). But at the same time, this _is_ a lisp for the XXI century. Old dreams needed to die for progress' sake.
I strongly disagree though about the importance of understanding everything all the way down. It's not a bad thing per se, but pales in comparison to being able to work easily with what others have made. Another compromise, and one well chosen in my opinion. The vastness of java space compensates more then a hundred times the lack of transparency.
So at what point of abandoning some of the fundamental ideas do you have something else entirely?
I hate all this "dream" talk, it's not a dream it's been implemented. If you don't want to use it fine, but don't pretend to be taking all the good and leaving the bad. Imho having to deal with Java classes is just substituting one bad for another (or worse).
Well, you can either have just "perfect" implementations of an obscure language very few people are coding in, or you can also have an implementation of a similar language that is imperfect while actually gaining mindshare for both languages.
Who's more likely to bother looking at some other version of lisp, someone whose experience is C++, Perl, and Java, or someone who's used Clojure?
This isn't the perfect as the enemy of the good so much as the perfect not willing to let the good be its friend.
But it's not the pure genius of Symbolics LISP. The genius of the Lisp machines is in their extensibility and consistency all the way down. (This has nothing to do with Lisp, BTW, but rather with the design of the system and runtime. The syntax is nice, but largely irrelevant.)
The closest I've ever come to day to day use of a Lisp machine is Emacs. It is wonderfully different from "worse is better" systems like UNIX and Clojure/Java. With a few keystrokes, I can use my tool to change my tool... instantly. Everything is as deeply aware of everything else (if it needs to be). The result is an extremely comfortable environment where anything seems possible. (I recently switched from bash + ansi-term to eshell. UNIX is much nicer when you can see it through a lisp-colored shell.)
Anyway, I guess this isn't really related to the article... but if your view of programming consists of strings being passed along pipelines and huge, monolithic cathedrals that claim to be "IDEs", you are not seeing the whole picture.
My standard of comparison for any technology will always be everything previously achieved by mankind, rather than what is available on the market today.
Exactly the right attitude, except here it seems to be harming this guy's life.
I find it strange that the original author only suggested proprietary alternatives (Lisp Machines, Mathematica), noting that Common Lisp itself not immune from these same criticisms. What's also interesting is this:
Java itself, at its helm had/has people such as Guy Steele who knew that since people would be unwilling to adopt languages such as Common Lisp or Smalltalk, best they could hope would be to "sneak" many of the features these languages originated (reflection, generic programming, garbage collection, DSLs, object orientation) to the people who would benefit the most from them. Java was a great covert vehicle for this "feature-sneaking", with its C-like syntax and enterprise buzzwords.
Now with Scala and Clojure (as well as Jython and JRuby), it seems like this an even more ambitious to sneak powerful programming tools and paradigms (dynamically typed languages, functional languages) to the professional programmer community, this time by saying "this is just a jar/war file".
If the goal is adoption of proper Lisp-from-ground up architecture, then sure this "sneaky" approach isn't going to get anyone there. But what if the goal is better code and more productive coders?
How much impact had Guy Steele on the design of Java? My guess was always that Java was mostly designed when he arrived and he was hired for his experience in standards and his writing capabilities. Given that Mr. Steele co-wrote a book on C, worked on the standard for High Performance Fortran, the CL standard, and other things.
The Clojure user who is missing some routine or other will run crying to Java for help, rather than implementing the feature himself correctly.... Clojure pisses on everything I’ve ever loved about Lisp.
In other words, Clojure bypasses a major part of what everyone hated about Scheme and Common Lisp, the unfortunate combination of inclination, culture, and fragmentation that prevented the natural development of a library ecosystem like the ones enjoyed by Perl and Java. Furthermore, this guy's comments reveal that for some Lisp hackers, at least, the bias against libraries was real and not accidental. To guys like this, the desire to just install a library and get the job done stands right beside "too many parentheses" as a stupid noob concern that a real Lisper will grow out of. Let's hope Clojure represents a symbolic moving-on from this self-defeating and chauvinistic attitude.
not really. The Symbolics Lisp Machine came with a huge library of thousands of class and 30000+ functions.
Additionally it had compilers for Fortran, C, Pascal and others. It could compile things like TeX and X11 on the Lisp Machine.
He just does not want to build on the JVM. I can understand that. The JVM is optimized for Java and nothing else. SUN has not done much to support other languages (functional, dynamic, ...) on top of the JVM (Microsoft does that with its .net infrastructure, though). Using the JVM for Lisp is fine, because it is there. But it is ugly, since it is alien for Lisp. More alien than x86 is for Lisp.
His complaint is that the JVM libraries are not coded in Lisp: opaque routines having no underlying Lispiness. He would rather have no libraries at all, so every programmer needing library functionality has to "implement the feature himself correctly," where "correctly" means "in Lisp." His aesthetic sense has run amok and is out to destroy everything that isn't a "crystalline pyramid," regardless of how useful it is.
Additionally it had compilers for Fortran, C, Pascal and others.
Until this wacko logs in and deletes them, or replaces them with trojans to teach you a lesson about intellectual rigor ;-)
The JVM is optimized for Java and nothing else.
That's true, but x86 is optimized for C and nothing else, so how can you do any better (in real life?) At least the JVM has potential. Sun has realized that dynamic language performance is important, and they're busy improving support for languages like Jython and JRuby. Lisps will benefit from that work.
I retain a great deal of affection for environments like Squeak, like Emacs, where you can stand as high up or as low down as you like in the system. Emacs has primitives written in C, of course, and Squeak doesn't cooperate real well with the rest of the world, but it's still a very powerful idea.
It makes me a little sad that one cannot learn Java programming by e.g. loading up Eclipse and saying "what's the code for this thing?", in the way that Squeak, Emacs, many Forths, R, and yes Symbolics Lisp permitted.
Could there be a more self-defeating way to make this argument? This is the kind of thing that makes people write psychoanalytical essays about Lisp programmers.
I have never heard any Clojure proponent encourage anyone to implement functionality at the Java level. I don't program in Clojure or Java, but it's obvious to me the idea is that the JVM is just the "operating system" for Clojure.
So you would not write hybrid Java and Clojure programs? You would not reuse and extend Java classes? Strange. I thought Rich went to the JVM because the eco system is so rich ;-) and not just because it happens to have a code execution environment and a garbage collection implementation.
When you're writing Clojure code, you generally are supposed to prefer Clojure features and idioms. Functions like proxy and gen-and-save-class exist because sometimes you have to create classes to use other Java APIs.
Of course, I find myself wondering - in what world is such a thing most likely to happen? In a world where lisp sits in obscurity, or one where some "revolting" lisp actually gets a significant developer base? :)
However, I will have to say that I was initially excited about Clojure and each day become more disappointed because it really does carry with it all the baggage of Java. I had vowed to avoid CLASSPATH hell the rest of my programming days and Clojure often makes me feel like I'm lying to myself.