This was not a very well written article. It's full of opinions that don't come with good reasoning. It completely omits popular flavors of Lisp, like Racket. And it also shows a hint of critiqueless fanboy-ism with Clojure, when he goes on rambling about how writing Cocoa with Nu is a mess when using Java libraries with Clojure is almost just as bad (or someone has already written a wrapper layer). He also likes to bash C++ and Common Lisp while not really giving good reasons why - I guess it's popular to say bad things about C++/Common Lisp/Java/COBOL/any language with an ANSI or ISO standard.
Not to mention that it doesn't have any insight about the future of Lisp - apart from the fact that the author thinks that Clojure is the ultimate Lisp which is his own opinion.
Hm, I don't really like the tone of that article. He made some good points but just brushing Scheme and Common Lisp (CL) aside as "dead" made it hard to read the rest of article objectively.
I'm not into Scheme but while CL isn't as popular as Python or Ruby there's been an enthusiastic and ever growing community for at least the last 10 years. One of the biggest objections against CL, library support, is getting less and less of a problem by the month.
Also don't forget that Clojure's Rich Hickey donated to the SBCL crowdfunding drive[1]. I'm still waiting for Larry Wall to chip in.
Insulting Perl helped Python and Ruby, but I doubt that insulting Common Lisp and Scheme will help Clojure.
If the Clojure community thinks that its better to attract more Ruby and Java programmers, and alienate other lispers, please, keep producing ignorant crap like this.
Claiming Common Lisp is dead and comparing it to C++? Why should anybody listen to somebody’s extremely narrow minded opinion on THE FUTURE OF LISP, when that person has shown that he knows NOTHING about lisps past and present.
Mr. Fogus, you know much better that to post such ignorance to Hacker News. Keep Clojure awesome, don't let the fanboys spread FUD. Inter-dialect respect, yaw! :)
A reminder: A blog post does not represent the common thoughts of a community any more than a submission to HN represents the thoughts of the submitter.
Mr. Fogus, you know much better that to
post such ignorance to Hacker News.
Save your pontificating for someone else. What I do know is that when someone says something that I disagree with I think about and discuss it and respond or reject based on its own merits. I do know better than to plug my ears and scream "La La La La La" so as not to hear.
Thank you for the response. I agree in general. But so far I haven't seen too much fruit in this discussion, because the lisp community(all dialects) has had this conversation too many times, I appreciate your submissions and blog posts that give us a new way to look at things, there are certainly much better topics for us to discuss. The future of lisp is certainly important enough, but we could have had just a better way of starting it(continuing it actually).
Being overly defensive about your favorite programming language is also not productive. This just one guy's opinion not some "community".
No programming language is beyond criticism (Clojure has plenty of warts), and certainly the mainstream ones are positively filled with teeth-grinding flaws - otherwise you wouldn't see such active work and interest around new programming languages.
I love most lisps I’ve had the pleasure to study. When clojure prospers, I’m happy. When individuals express such opinions clojure does not prosper, because the rest of the otherwise excellent community now has to explain that not all clojure programmers are ignorant fanboys, the same way Common Lisp programmers now have to explain that it's not a dead language that's like C++ with more parenthesis, and scheme isn't all just about teaching, and yes, there are libraries we can use. Its hard enough to use lisp, why make it harder? No lisp dialect needs to push others down in order to prosper, were better than that.
I think the comparison to C++ is apt. Both languages are sensible tools for experts, but unfortunately very complex. In C++, this is naturally due to backward compatibility with C. But in CL, it's the result of design by committee.
Clojure is a great lisp dialect, but if you had the resources to write a new runtime, you could probably do better.
With the risk of making myself sound even more defensive about common lisp that I already did, common lisp was not designed by a committee, it was standardized after a lot of use and discussion within the community.
p.s. And an expert is exactly what I want to become, I have no ambition to be a code monkey. I'm truly sorry if expertise and skill are valued less these days in the tech circles. "Good enough" is not good enough for me. I look up to the experts and brilliant minds of our community and aspire to be as good one day, I don't care much for the general case, i have no use for "a language for everybody".
I applaud that you want to become an expert. Emacs is a good example of a tool that takes a long time to learn, but this effort is well amortized. My intention was not to criticize C++, I think it's the right choice if you have the right people, as is Common Lisp. At the same time, tools with a high barrier to entry obviously have a harder time gaining adoption. Take the LOOP facility, it's obviously powerful, but it baffles beginners.
One issue though. While becoming an expert in C++ can be a fruitful career path, all of the people I know who are using CL for work, are consultants working to maintain old projects. I'm not qualified to say how much money is in this or if it's any fun, but in my experience it's really hard to get a company to agree to CL, because of lack of people. That's why adoptability matters so tremendously.
Tools like Emacs and Common Lisp are exactly the kind that I actively seek. I needed novice friendly tools four years ago when I was starting with python, I don't need them anymore. You're a novice only once, you're an expert for life.
I was already playing around with Scheme and Clojure for at leas two years when I started learning Common Lisp, very few things have been exceptionally hard or foreign for me, loop was definitely not one of them.
That's the reason I get so hot-headed about these kinds of things. I have invested a lot in bettering my self as a programmer. Articles like this one insult years of hard work, and my own effort is just a very small part of it. People have been building these tools and communities for 50 years before I even knew what a computer was, dismissing it so lightheartedly pisses me off. I only hope others understand. Maybe I just have too high standards. Comes with being young I guess :)
It looks like half-serious, half-trolling to me. He (or his troll persona) seems to have written no line of Scheme or Common Lisp ever, and he has obviously no contact to the respective communities.
I can imagine that he has a point with Nu and Cocoa, but I have never worked in that ecosphere, so I cannot judge that.
His comments about REPLs look completely lunatic. Scheme and Lisp practically _invented_ the interactive REPL, and the parenthesis-based syntax makes the implementation of a REPL almost trivial (where does a unit of computation end in Python?). The claim "The s-expressions inherent in Lisp simply won't allow for that." is just bullshit.
So, dear Steven, talk about Clojure, but don't talk so dismissively about things you have no idea of.
A good read, but it is opinionated in an opposite direction to my own experience. Almost half of my consulting work in the last 18 months has used Clojure. Based on the quality of projects written in Clojure and some very good decisions that Rich made, Clojure's developers' market share will continue to grow.
That said, Common Lisp is a great platform and for some applications, Scheme is a fine language choice. Common Lisp has a high learning curve and many developers will not want to invest the resources to master it. About 10% of my consulting work in the last 10 years or so has used Common Lisp and before that I used some form of Lisp for many projects at SAIC starting in the early 1980s. Although the Scheme library situation is getting better, I personally use Scheme for my own small projects that tend to be all new code, often just to think about a problem. Gambit-C with its custom Emacs interface is probably my favorite coding/experimenting environment.
I would say that the future of Lisp is looking good.
What kinds of consulting opportunities are there for Lisp people? I don't see a lot of postings for those skills but maybe it's a more specialized market?
I did think he was a bit harsh on CL - it may be the ultimate "big ball of mud" programming environment but there are some truly lovely parts to it (CLOS/MOP and the loop macro being my favourites).
"APL is like a beautiful diamond - flawless, beautifully symmetrical. But you can't add anything to it. If you try to glue on another diamond, you don't get a bigger diamond. Lisp is like a ball of mud. Add more and it's still a ball of mud - it still looks like Lisp."
It's important to look at the "In programming languages" section - http://en.wikipedia.org/wiki/Big_ball_of_mud#In_programming_... - because there, 'big ball of mud' means something else that one would think at a first glance, and the quoted statement does not use 'big ball of mud' as a negative description; it refers to its malleability.
I agree with CLOS & MOP, but the loop macro is more like a pair of scissors that has been stuck into the Big Ball of Mud; it doesn't fit in with anything else, and makes it harder to use it for what it is really good for.
s/ CLOS and MOP seem like they are welded on to an otherwise good language, whereas loop is beautiful in all its loop DSL glory. /s
(In truth, I find that both have their uses).
Basically, different people disagree about which part of Common Lisp it is that they dislike. Unfortunately, this leads many people to believe that Common Lisp is not a very good language for programming in. To the contrary, people simply end up with very strong opinions about the different parts of Common Lisp that they _do not yet_ understand.
This is largely because it is trivial to implement your own object system or loop construct, so people think about the language in a completely different way. There is a mentality of 'Hey, I could do this better than what the standard does.'
You think about the way languages work differently.
My evidence for this is that I have never seen a C++ programmer complain about the for loop and describe a better for loop, you rarely see java programmers talking about how much better a different object system would be.
Again, this is covered in RPG's "Good news, bad news" (I'm busy, google it) and, to a lesser extent, "The bipolar Lisp programmer".
RPG's main argument is that Lisp is "MIT-style" the Right Thing, while C is "New Jersey-style" solve-the-right-problem-at-the-right-level. In other words, Lisp is like an expensive speaker system that's hard to configure correctly for ordinary sound systems, while C is something that works better for the average user.
The economics upshot of this is: target Lisp at the high-level critical applications Erlang and Haskell are targeting -- big telecom routing logical problems, flexible quant finance modelling, etc. Stop trying to replace the Scripting Language du Jour. You can't compete against C++; it's everywhere from Facebook to Arduino.
I have a blog post about this in the making, but in the meantime, I'd like to point out that there is zero quantifiable evidence to RPG's worse is better thesis. There are many aspects of Lisp/LispMachines vs C/Unix that can account for why they're used where they are, and he completely ignores the obvious ones that people have (and continue to!) complain about: C/Unix is cheap/free and runs everywhere. This wasn't the case for Common Lisp until the early 2000s!
I think RPG's good news, bad news came to the wrong conclusion and made some inappropriate dichotomies (Right Thing vs Worse is Better) that unfortunately have become memes that lead people astray.
> C is something that works better for the average user.
difficulty of using vs. difficulty of using correctly.
(And I'm not even sure worse is better makes sense in a modern context).
Difficulty of using a programming language (regardless of results) is inversely proportional to the amount of time spent writing code in that language. If the majority of users writes C or C++ code all day, C and C++ become 'better for the average user.'
If the majority of your users write Common Lisp or Scheme all day, CL and Scheme become 'better for the average user'.
C and C++ are much more difficult to actually use correctly (without regard for who the average user is), mainly because there are many more ways to screw up when you are working at such a low level.
The myth of Lisp being difficult makes me boggle. There isn't even a syntax to memorize!
Speed, safety, flexibility, dynamic debugging and compilation, optional static typing... You don't even need the higher level aspects of the language to reap benefits from these features. With Quick-lisp if I need a library I just load it and use it (plug and play).
Why not replace my C++ and scripting languages with Common Lisp if I can get the best of both worlds?
The economics of this is that if I already know Common Lisp, and am willing to teach those around me, I am a fool to use anything else.
I have never seen a C++ programmer complain about the for loop and describe a better for loop, you rarely see java programmers talking about how much better a different object system would be.
Amen to that! Except...
I'm a C & C++ developer who sometimes complains about for-loops, and often pines for dynamic dispatch. And any C developer who has written or used a FOR_* macro has complained about for-loops, whether she knows it or not.
I agree with the author that Clojure is great, but I think he overly dismisses Scheme. There's not a standard library for Scheme as a whole, but Scheme is almost an idea, not a language. You have to look at the implementations, and Racket (http://racket-lang.org/) has a great library. I'm always surprised that PLT Scheme/Racket hasn't caught on more.
Also, the whole SRFI project (http://srfi.schemers.org/final-srfis.html) is an attempt to create APIs that are not part of the core language, but are common across implementations that choose to support them.
I don't think this is a reasonable article. Among other things, he offhandedly dismisses Common Lisp. Common Lisp does have at least one implementation that is pretty Mac oriented. Clozure I believe, but don't quote me on that.
He is right that the JVM library set has helped Clojure. I hope to see a Common Lisp port to .NET one day.
One thing this world doesn't need - IMO - is another Lisp trying to be an industrial standard. If Common Lisp by itself doesn't cut it, DEFMACRO your way to what would cut it. If it requires compiler-level modifications, start working on contributions to the best compiler in the area you are working in (I think SBCL is the premier CL implementation, and should be centralized on, but that's just my opinion). Please don't write another Lisp, helping to fragment the market even further. (this is my primary beef with Clojure, too. :-) )
Clozure (http://ccl.clozure.com/) is good at being better than SBCL in some areas (like, its compiler is a lot simpler). But there's room for the current CL implementations. CLISP for example is the only Common Lisp implementation doing JIT compilation. ABCL deploys on the JVM. It would be nice to have a CL deploy to JavaScript. And really nice to have a new JITed implementation that takes ideas from LuaJIT.
Don't forget the commercial CL implementations. Lispworks is pretty awesome.
What's really needed is to treat Common Lisp as a platform like the JVM. And for that to happen the current Free Software system libraries (networking, I/O, threading, Quicklisp, ASDF, FFI) need to continue to be improved, and need to run well on all CL implementations.
And there's no sane interoperability from an algorithmic language like Lisp to a processor-driven language like C or a spaghetti-driven language like C++.
What is sane interoperability? How can a processor "drive" a language? And spaghetti-driven? WTF?
This must be the result of the "release early and often" habit that is often encouraged here. He would probably do better to write in detail about something he has done or is doing, rather than write vaguely about what he has been thinking about.
I spent a lot of time bolting strange things onto Common Lisp systems in the early '90s through a foreign function interface and I thought it was pretty straightforward.
[Note: Strange things being C++ simulations generated by Lisp code directly from systems of nth order ODEs. Other non-Lisp types also wanted to use the simulations, which is why they were in C++].
What was much more fun was the fact that we also had NeWS based user interfaces connected to our Lisp applications by some glue C/RPC code.
Developing in Lisp, C and PostScript on the same codebase was a lot of fun (PostScript being surprisingly Lispish - which I would never have suspected had I not been developing in both at the same time for a couple of years.)
I therefore got quite excited (in an RPN kind of way) by the reference to Forth in the "Let Over Lambda" book featuring on HN today! :-)
Author's dismissal of CL and Scheme stands opposite to the fact that most CLs as well as Racket have tons of libraries right away; plus the general tone in their communities is "Racket/SBCL/whatever is for the doers".
That people speak from their experience. It would seem that the OA just repeats some heard opinions.
I disagree with the author about the lack of market for a fast lisp, essentially a Go Lisp. Clojure's arguably greatest advantage, the JVM, is also a drawback. Think of how long it takes to start the JVM or how sluggish Eclipse is.
I write Lisp primarily because it's the prettiest language and that it allows the greatest amount of freedom.
What we need is a modern CL, inspired by modern dialects like Clojure and Arc, but with design decisions that allow for high performance, e.g. dynamic binding and static type inference. Some have pointed out that solid module support is also important for fast community growth. In other words, I'm arguing for a dialect that centers around the compiler, doing evaluation as a side-effect, perhaps through JIT compilation. The reason this has not been done, I believe, is not because it's impossibly hard (as some people have argued), but because it's a lot of work. Creating a necessary, good run-time from scratch is a large undertaking.
I don't think he talks about Lisp. He seems to talk about another scripting language like Ruby or Python on the JVM or a compiled static language like Go or something else. Maybe.
Steven Degutis is apparently unaware of Clozure Common Lisp which makes Mac development easier and more fun. Or Embedded Common Lisp which makes iOS development easier and more fun.
Neither CCL nor ECL seem any deader than usual :-)
This should be titled "The present state of Lisp", or better yet, "A review of current Lisp-like languages". Compare this with the classic "Good news, bad news", which wasn't about implementations, but about the more general societal dynamics (within the developer community) by which Lisp thrives or stalls.
Not to mention that it doesn't have any insight about the future of Lisp - apart from the fact that the author thinks that Clojure is the ultimate Lisp which is his own opinion.