I love Clojure and I think it's the first Lisp to take the language family out of "cons cell and parenthesis hell". My personal opinion is that Clojure with the following changes would take over much of the Lisp space:<p>- Rewrite most of Clojure in Clojure (which has been talked about since the beginning, really) to find the "small core". Thankfully ClojureScript has helped hasten the CiC movement.<p>- Base FFI and code gen on more abstractions so that Clojure living in a .net world or a C/C++ world or a Python world would feel just as cozy as Clojure living on the JVM. Rich Hickey talked about why he abandoned primary CLR support early on. He said he "didn't want to keep writing everything twice". This was probably the best strategy at first, but now one hopes that with ClojureScript + Clojure enough has been learned to discover more ways to factor out the commonalities so that Clojure is more easily retargetable.<p>- Speaking of targets: there should be a first class, fully supported Clojure frontend to LLVM. There are research projects and personal projects in this area, but that's about it. I'd like to see an official LLVM target.<p>- Introduce or surface more abstractions and macros such that the immutability and pure functional underpinnings could be extended, removed, or replaced. This is likely to be the most controversial change, but it would be essential to the possibility of Clojure running on small embedded systems and other environments where the choice of underlying data structures and concurrency algorithms can't come baked in. This is mostly done already (as most things in Clojure are built on top of abstractions), but it still needs a deep look.<p>- Open up the reader. A Lisp without full reader macros is unlikely to win over all potential converts, not because reader macros are this incredibly common thing, but because the personality of most Lisp hackers tends to thinking like "well I don't think I'll need a reader macro, but why would I want a language that won't even give me the option?"
First there are a lot of programmers who come to CL to debate. They read, they study, and then they complain. I've sat in #lisp since about 2007/8 and there have been numerous nicks that show up just to ask a few rather philosophical questions and debate the merits and technical decisions that went into CL. They usually end up leaving and writing blog posts about how terrible a language CL is and how caustic the community is.<p>There isn't a problem with the CL community. There's a problem with the culture surrounding CL that seems to attract trolls.<p>Newbies get answers to genuine questions. I've received a great deal of help over the years from experience CL programmers. Anything from beginner questions to code reviews of various snippets I've been working on. I have received a lot of great advice over the years that has helped me tremendously. And I've seen other newcomers receive the same treatment as well. If you arrive in #lisp of c.l.l and have a genuine question about a problem you are stuck on you will likely attract someone willing to help you. It's a small community but it is friendly.<p>Second, CL was in the end designed to outlive itself. You get full programmatic access to the compiler and reader. It is trivial to add any feature a modern programmer may require that wasn't accounted for in the original specification. CLUEL could certainly have been useful if the author had finished it and put it out into the wild (maybe waiting until it was <i>finished</i> was the wrong choice).<p>I think if you are genuinely interested in learning CL you need to check your ego at the door, so to speak, and just start from scratch. Write programs that solve yours or your users' problems and ask questions in #lisp and on c.l.l if you get stuck. There is a wealth of great literature, papers, tools, and a small, friendly community to help you.<p><i>Edit</i>: I meant to note that the reason the specification hasn't been updated, afaik, is because it doesn't have to be updated. All the tools you need to add the features you require are there in the spec. You can make it into the language you need.
I am not sure it is true that comp.lang.lisp <i>barely tolerates</i> newbies. I have posted there on several occasions and when I say something wrong, I am politely corrected. I have seen a lot of less experienced programmers come there, ask an obviously beginner question, and get helpful answers. Reading through the past few days of posts, I can see a few beginner questions which all received helpful answers.<p>The problem in comp.lang.lisp is the number of trolls -- in other words, the universal problem on Usenet. People come in trying to prove that some other language is superior, or asking questions like "If Lisp is so great why is nobody using it?"
Perhaps the author will find the answer to the "why" of how unwelcoming a community can be in his choice of opening paragraphs. A story that calls some number of his audience as stupid[1] or ignorant[2] for holding a belief is probably not the best way to introduce your soul searching on why the community he was a part of is not a welcoming one.<p>1) the implication if you have read your holy book and still believe then you are a poor thinker.<p>2) if we were in the Middle Ages, the story might be more relevant. I do believe most believers of any religion in the modern era have probably read their own holy book.
As someone who learned a little Lisp in the last few years, I think there is a good collection of books available for the newbie who wants to learn. For Common Lisp, <i>Land of Lisp</i>, <i>Practical Common Lisp</i>, and <i>Ansi Common Lisp</i> all seem good enough to get hacking quickly.<p>Thinking about community effects, I'm not as convinced a community represents a gating factor for hackers. I attend the occasional Clojure meetup (and Clojure/Conj for that matter). The meetups in my area are well-attended and run, although they could be improved with a better introduction and ice-breaker for more introverted attendees (yes, I've just outed my personality type).<p>But from an opportunity mindset, the Clojure community seems to have done an admirable job getting the message out. Multiple good books, the Clojure/conj, and a well-attended meetup in my area all make me feel like I may not only stretch myself and learn new programming techniques, but that I have some hope of advocating for Clojure in my workplace or, good grief, applying for an actual day job where I would use Clojure.<p>It's unclear to me that Common Lisp can offer that.
Honestly, I don't know that CL was ever exactly beloved among Lispers. (Scheme may fit that description better). CL was a pragmatic construct from the beginning, responding to many conflicting demands.
This is a strange article.<p>Let's address his complaints in two basic areas:<p>1. Community.<p>The Lisp community as typified by #lisp and comp.lang.lisp can be remarkably acerbic to the point of toxic, depending on who feels like contributing at the time. Part of this are the annoying trolls that show up; one's patience wears thin. A FAQ document might go a ways. However, there are a large number of people who don't ream newbies out and really are helpful. lispm here on HN is one of the friendliest Lispers out there and actually has helped me out tons.<p>Addendum: r/lisp on Reddit is good for generalish Lisp questions. StackOverflow's common lisp tag almost always gets an answer to most any reasonable question. sbcl-devel mailing list is useful if you want to take the time to posit in-depth technical questions to the SBCL developers. Lispforum, oddly enough, I haven't used much. I simply don't go there much. I should, I suppose. :)<p>2. Technical. I can do no better than quote my /r/lisp post on this (r/lisp is <i>really</i> good for lisp help).<p>---<p>First of all, consistency. A variety of things are peculiar in how they are named. TERPRI? Really?<p>Second, Common Lisp is a (the?) programmable programming language. CLUEL-esque platforms could be used to drive CDR adoption and cleanups of the original language.<p>My primary gripes with CL are the lack of CDR-2, lack of CDR-8, the lack of hierarchical namespaces, the funky naming conventions & expectations[1], and the lack of deeper CLOS integration[2].<p>[1] ELT vs AREF vs NTH, for instance. Or, LOOP for lists vs arrays vs (your data structure here).<p>[2] See CDR-8.
Props to the author for mentioning Chicken Scheme. The community is very friendly indeed. There are lots of eggs and the easy C integration means that one is not usually left wanting for libraries, assuming a minimal knowledge of C.<p>Also, it runs basically anywhere. One could embed it inside an iPhone app, for instance.<p>There are some big things missing still. There is no standard database access library, or an equivalent to Python's WSGI (or Ruby's Rack). Or MongoDB drivers (that's my fault, I promised the community one a couple of months ago).<p>There's also some missing tooling. Better debugging support, for instance. That's mostly avoided by the use of unit tests and the REPL, but is occasionally required. Or profilers. Or code coverage tools. Due to the fact that everything is compiled to C, there are some tools that may be used, but it is still not ideal.
There isn't, as far as I'm aware, another language with CL's popularity that provides either its condition system or the full power of the CLOS (method combination, for instance). These two major subsystems are still significant improvements over what modern languages have to offer.
This reminds me of my experiences with Plan 9. A very cool system, but it's managed to attract some of the absolute worst people in computing. Dare to criticize something and they'll leap down your throat. In the end, I just gave up. We tried to drag things kicking and screaming into the 21st century with source control, 64 bit kernel, automated builds and testing, etc. but nobody wanted it.<p>On the other hand, the mailing list did get a lot of posts that kind of remind me of this: "Hi, I just started using Plan 9, where's emacs? Anyway I have a lot of great ideas on how to fix this OS so you should all start doing these things... I'll set up the wiki and write the newbie guide"
> the surest way for a Christian to lose their faith is to read the Bible, cover to cover.<p>I doubt that, based on my observation of a strong correlation between intense academic study of the Bible and fortitude of Christian faith.
Is this not just another point in a decades long quest to save LISP?<p>Maybe LISP doesn't need saved? Maybe it's okay that a language isn't popular? Maybe It's okay that a language isn't hip? Maybe it's okay if a language doesn't have the latest gee wiz social status? The fact that people keep trying to save LISP every 4 or 5 years could mean it's perfectly fine how it is. I don't see people trying to save the COBOL, or FORTRAN, or <insert favorite esoteric language here> community.
I came to precisely the same realization about ten years ago, after struggling in vain with the culture and quirks of Common Lisp. There's no question that learning Lisp in some form will make you a better programmer but don't get caught up in the cult that surrounds it. Virtually all of Lisp's innovations now been validated and adopted by more mainstream languages and the fact that nobody has picked up the s-expr syntax is telling.<p>These days I focus more on writing useful code and making end users happy and I've found that to be much more satisfying than wringing my hands over the inelegance of everyday languages.