The future of Lisp
blog.8thlight.com
blog.8thlight.com
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.
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.
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! :)
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.
Clojure is a great lisp dialect, but if you had the resources to write a new runtime, you could probably do better.
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".
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.
As for whether CL was designed by a committee or not, I was trying to communicate Richard Gabriel's account at http://www.dreamsongs.com/Files/clcrit.pdf
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 :)
Mr. Fogus, you know much better that to
post such ignorance to Hacker News.
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.
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.
"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."
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.
(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.
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.
In CL, I prefer iterate.
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.
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 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.
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. :-) )
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.
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.
[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++].
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! :-)
That people speak from their experience. It would seem that the OA just repeats some heard opinions.
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.
Clojure is high performance and has dynamic binding. Typed Racket has shown that you can get static type inference via macros.
Which isn't to say the world doesn't need a Go Lisp. But Clojure certainly delivers (or could deliver) on all your points.
Neither CCL nor ECL seem any deader than usual :-)
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC....
"A review of my misunderstandings of, and obvious lack of experience with, current Lisp-like languages" would perhaps be even more accurate.