The Lisp Curse is all the people writing opinionated articles about the Lisp inferiority complex, instead of contributing to existing Lisp software.
There are tons of incompatible, undocumented libraries for Perl, Python and C. This is no correlation to anything. The people who want to use existing libraries use them. Those who want to reinvent the wheel will do that and there is nothing you can do to stop them.
The Lisp Curse does not mean that incompatible libraries exist. The Lisp Curse means that it's so easy for individual hackers to go their own way that getting them to cooperate resembles herding nuclear submarines (i.e., they all need to respect the same formidable power, there'll be plenty of internal politics, et cetera).
My opinion of Emacs being obsolete is one which I got from reading James Gosling, the author of the first Emacs that ran on Unix. I trust that he knows a thing or two on the matter and he didn't rest on his laurels after moving on. Besides, his description of Emacs matches the evidence of the senses.
The alternatives which you mention demonstrate the Lisp Curse rather than refute it, judging from their websites. Climacs doesn't seem to have been updated in nearly three years. Portable Hemlock doesn't seem to have updated in nearly seven years. MCLIDE is Macintosh only. Those three projects are either moribund or unportable, as predicted by the Curse.
> My opinion of Emacs being obsolete is one which I got from reading James Gosling, the author of the first Emacs that ran on Unix. I trust that he knows a thing or two on the matter and he didn't rest on his laurels after moving on. Besides, his description of Emacs matches the evidence of the senses.
So in other words, you have no direct experience with Emacs to compare it to whatever other programming environments you may or may not have used.
> My opinion of Emacs being obsolete is one which I got from reading James Gosling, the author of the first Emacs that ran on Unix.
Mind you he wrote an Emacs in C, complete with a faux-lisp interpreter. That more or less precludes him from being an expert in Emacs.
Keep also in mind he gave Java to the world, some would argue, well after it was obsolete (some people will sustain that Smalltalk 80 made Java obsolete in the early 80's, a full decade before its launch)
Writing Emacs, be it in C or whatever, is hardly a reason to not call Gosling an expert in Emacs, quite the contrary! But you might argue his approach to Emacs is not idiomatic or not consistent with the community and so on, if there is evidence for that.
Even his remarks about object orientation are just a straw man. Perl5 still doesn't have a definitive object model (well, beyond blessed hashes). Library authors have written many competing solutions over the years. Arguably this is a good thing. If someone finds a better way to do something, everyone can benefit without waiting for the Perl core developers to implement it.
Contrast to Python where we have to wait for the core team to implement everything including the core libraries.
I don't know why this idea of writing "Why Lisp Sucks" articles persists. Maybe it makes the authors feel smart and authoritative. I honestly don't know. Can someone fill me in please?
As I wrote in another comment, I wrote the essay because the idea had been bouncing in my mind for some time and I needed to get it down. The disconnect between Lisp's power and its lack of mind share is downright odd given what it can do and how influential it has been.
I wouldn't be surprised if some old-timer on comp.lang.lisp were to relate a heart-rending tale of an inner-city high-school dropout thalidomide baby who was a pity hire at LMI in 1987 and blah blah s-expression this and blah blah Lisp macros that and blah blah his flippers could barely reach the Hyper key and blah blah he did things you people wouldn't believe but blah blah Worse is Better so blah blah... Okay, okay; I believe you.
Then I would read Lisp sites that were still debunking old myths like "Lisp is an interpreted language and its only data structure is lists and it caused the AI Winter."
After a while, people are going to wonder about the disconnect. There's a line in Tim Wilson's song "100 Things Every Man Needs to Know"
"You been married nine time? Hell, maybe it's you."
Yes, Lisp is a pretty powerful language but I don't think that has much to do with its uptake (or lack thereof) in the mainstream.
You and the authors you cite have imagined this genius lone-wolf character together. You harshly criticize the characteristics of this terrible phantom. And then you conjecture that the lack of mainstream adoption of Lisp must be accredited to this stagnant community of loners and miscreants. I assure you, this straw man doesn't exist.
Maybe you've only met one or two in life that gave you a bad impression. You should join #lisp and chat or email Peter Siebel and see if he fits into your stereotype. You might find the experience enlightening.
To answer why there are so many Lisp projects with a single developer you will have to answer why there are so few Lisp developers.
And here's a hint: It's not because the people who tend to like Lisp easily fit into a simple, boring stereotype.
Perl5 has had many OO libs but that has not helped. It is when the community standardizes on best practices and standard libs,such as DBI, that you get big advancements. Recent community efforts around "Modern Perl" and the Strawberry Perl distro are helping the language stay strong.
Another example is JavaScript's recent big leaps forward stemming from the community's embrace of jquery and the best practices from "JavaScript: the Good Parts".
Standards allow others to confidently build bigger and better abstractions. Which is the only way to build increasingly complicated software.
I beg to differ -- would Moose have surfaced had there not been a competing ecosystem of implementations? Of course it's impossible to determine, but my theory is that it takes competition to discover new ideas. It's not often you land on the obvious solution on the first try.
A more concrete example would be the standardization process of Common Lisp. Wouldn't have happened if there was not a vibrant eco-system of competing Lisp implementations. Eventually many of the ideas championed by the major implementations made their way into the CL standard. Now we have a new ecosystem of implementations and a standard for them to follow.
You can implement your own OO system in Python with metaclasses. Perl makes it easy to roll your own, while Python discourages doing so. Compare Perl's TMTOWTDI vs. Python's "There should be one—and preferably only one—obvious way to do it."
Occam's Razor suggests that the reason there is no dialect of Lisp as popular as less expressive languages is that no one happens to have created one yet. What languages are has changed. Languages used to be specs. Now they're open source projects. Open source projects seem to succeed based more on the energy of their initial organizers than anything else. There are only a few big language-project organizers, and none of them happens to have chosen to implement a language that is a dialect of Lisp. That's the sort of thing that's true until it's false. E.g. Clojure could be the counterexample.
Maybe there's more to it than a small sample size, but that seems the likeliest explanation. The second most likely explanation is almost as mundane: that the reason new dialects of Lisp have trouble attracting adherents is that mainstream programmers are put off by s-expressions.
I agree with Peter Van Roy on this - mainstream programmers tend to have an unclear picture of the relationship between syntax and semantics. This goes for both C-style and whitespace based mainstream languages. Every syntax brings along hard-wired semantics like a ball and chain. But the ball is not particularly heavy, in fact sometimes it's light enough to not be much of a bother. This actually explains quite a few things - people tend to be satisfied with whatever language they've become comfortable with (in fact they get angry if somebody actually points out the ball and chain). The few people that actually take the time to learn several dramatically different languages discover that ball and chains come in all different kinds of shapes and sizes.
But I believe there is a sea change going on and Lisp will only benefit from it. That sea change is Functional Programming. Functional Programming is very much concerned with optimal semantics. The more people understand that semantics and syntax are inextricably intertwined the sooner they'll see that Lisp has been and continues to be one of the best ways to rapidly prototype and build optimal semantics.
But this also means Lispers need to constantly look at other languages - the optimal semantics are constantly evolving and changing (Racket and Clojure are doing a good job of adopting better semantics).
On that note, I'd like to say that you've done an incredible job at pointing out that the ball and chain is there to far more mainstream programmers than anyone else I know. Thanks for that.
In fact, when it comes to choosing languages, I think things have changed even more. At justin.tv, we've chosen nearly all of the languages we use because of a particularly good library that each one has (Python, because of Twisted; Ruby because of Rails, etc). The actual features of the languages have been almost irrelevant. We would definitely jump on a Lisp dialect if it happened to have a great library we wanted to use.
I think this is particularly insightful. What you've stated is a raw and pragmatic consideration - what is it that I want to do and what library lets me get that done the fastest?
Coming from justin.tv, this insight may be more start-up perspective oriented than historical reasons for programming language choice.
But I also believe that programming language choice is driven by market or behavioral forces that don't necessarily act in a rational way or lend itself to overly rational analysis.
Another thing that's changed is who is creating the dominant programming languages.
In the programming-language-as-a-spec days, people versed in programming language design created the dominant programming languages. In the programming-language-as-an-open-source-project world, languages tend to be created by people that are relatively clueless about language design at the start (this holds for at least Perl, Python and Ruby). I don't know what the root of such is, but there seems to be some negative correlation between the design integrity of a given language and its popularity (for web hackers at least – Java and C# adhere to the old model).
In contrast, Lisp seems to be fairly popular among folks that are programming languages enthusiasts. So for whatever reason, there's a gap between the folks that are creating new popular languages, and the sort of people that tend to be Lisp fans.
The other bit is that, well, Lisp looks funny. This is something like someone looking at a language that uses Greek or Cyrillic or Arabic alphabets and assuming that they're by default harder languages because they use different characters. In fact, a reasonably clever person can learn a new alphabet in a day. It's a totally artificial barrier for someone who's serious about learning the language since the investment to learn the new alphabet is dwarfed by the work of actually learning the language, but it tends to make it scarier if upon casual inspection. I suspect Lisp pushes some people away via a similar artificial barrier.
My understanding is that prior to creating Perl, Larry Wall had studied (natural language) linguistics, with an aim towards perhaps designing a writing system for some natural language.
I believe he's explicitly rejected the ideas (common in the Lisp world) that extreme conciseness and conceptual orthogonality should be the ultimate goals of programming language design.
Calling him "relatively clueless about language design" seems a little odd.
I think the inverse correlation you've found is easily explained. There are folks who design languages from the perspective of academia and there are folks who design languages from the perspective of practicality, and there is not much overlap in those communities. Perl and PHP are imminently practical languages, but they never would have been put forth by academia, because they are not pure, they aren't interesting in a research sense.
It's difficult to say that with complete conviction. Racket, for example, aims to be very practical. However, most of the research in PL isn't necessarily on entire new language systems as a whole, but maybe a specific feature or category.
Disclaimer: I guess by association I'm affiliated with this group[1].
Matz was a researcher working on compilers and programming languages when he created Ruby, so it doesn't seem obvious to me that he was "relatively clueless about language design" at the start.
He was definitely clueless about the implementation of Ruby. MRI started as a half-assed Scheme implementation, which is easy to see when you read the MRI source code. Scheme has lexical scoping, while Ruby has...python/perl-style scoping.
Scheme has first class anonymous functions, while Ruby has blocks, which are a hack around MRI's slow function calls.
Alternatively, free market theory suggests that the reason there is no dialect of Lisp as popular as less expressive languages is that expressiveness is not a trait that increases fitness, or even might decrease it.
That is true to a degree. I agree with what abstractbill says, that libraries are the dominant factor in most people's language choices (after familiarity of course).
FFIs just always seem to add some amount of friction. Stack traces, runtime error messages and documentation will all be referring to a language you're not using day-to-day, for example.
When you look at lisp code, all you have to go by are the names of functions. The code could do anything, and you won't find out what until you dig. By contrast, other languages have hints like types and standard, well-understood libraries and restrictions on what might happen.
This suggests lisp code is less approachable for second authors, precisely because of its expressiveness.
I agree. Even Stuart Halloway said they use Rails and JRuby for a lot of the projects they do at relevance. He said the reason was because of the community and the lack of equivalently good Clojure web frameworks. Its hard to think of someone who would be more sold on Clojure than him. And yet, he still thinks it makes sense to use Ruby instead of Clojure.
Its very hard to argue against it. If it takes you less time to write a Rails app than to write a Compojure app, which one would you choose? It seems like Rails is the correct answer, unfortunately.
I'm interested to know why you ended that last statement with "unfortunately."
I'm a web developer who currently uses Ruby for my projects, and I've been looking at Clojure. I've looked at Ring, Compojure, and other things, and it all feels like "Hey, Clojure can also do web! Isn't that cool?
I don't think it's unfortunate at all that people use Rails for making web sites. It's what it's for. Want to make a multithreaded concurrent backend queue? Probably not a good fit for Ruby, but sounds to me like a great thing for Clojure.
But I'm interested in your "unfortunately" statement because wonder what I'm missing. What would using Clojure give me, as a web developer?
I meant that unfortunately Clojure will not be gaining very much popularity in web development.
I agree that Rails is a much better web framework than Compojure/Ring. If you are doing web development, it makes sense to use Rails.
You can use Compojure or Enlive for straight web development if you want. But, at this point it is inferior to rails.
So I guess what I meant is, I would like Clojure to be more popular. But, it doesn't look like it will be getting any major attention in web development any time soon.
I'm a biased source, but whilst I agree that Rails is the better option for most professional web development at the moment, the gap has narrowed rapidly over the last year or two.
In my opinion, the current things that Rails framework itself does better than Clojure are:
1. Model Validations
2. Database Migrations
3. Project skeleton/generator scripts
4. Table relationship sugar (belongs_to etc.)
I don't think that's a huge list, and it's actively being worked on. I suspect that we'll have a framework equivalent to Rails sometime early 2012.
Of course, this doesn't address the Rails ecosystem, which will probably be larger and more mature than Clojure's for some time to come. However, not everyone needs the full range of plugins available for Rails, so depending on the project, there may not be any difference between using Clojure and using Rails.
At which point it comes down to whether you prefer Ruby or Clojure as a language.
I wish this had answered my question more though - what is it that I'm missing. I mean, we have been building web frameworks for every new language that comes along. So what is it about web apps that we haven't solved? What does Clojure bring to the table? How will it help me make better web sites for my clients than Rails currently does?
When I switched from PHP to Rails, I did so cos it was easy to see the benefits - in 2004 there were no serious web frameworks, there were no easy ORMS that cut out the trivial crap I had to build from a week down to a day. I could quickly get the simple stuff out of the way so I could write code for the bigger problems.
So now here I am six years later, and I'm really really intrigued by Clojure, but I'm not seeing where it fits. I don't need a different way to build web apps... I need a better way. Otherwise I'm not that interested in taking a step backwards productivity-wise.
So, I'm looking to learn, cos I do think it's a fun language, and I've learned a lot more about programming while learning it. Maybe that's its role.
This is a difficult question to answer, because it ultimately boils down to the philosophical differences between Clojure and Ruby.
Clojure favours discrete components that do one particular job. For instance, protocols were introduced to Clojure to provide efficient polymorphism, and they do not attempt to do anything more than this.
Ruby is an object orientated language, and tends to favour grouping together a wide range of functionality into indivisible components. For instance, classes provide polymorphism, inheritance, data hiding, variable scoping and so forth.
The advantage of the Clojure approach is that it tends to be more flexible. For instance, in Sinatra you can write:
get "/:name" do |name|
"Hello #{name}"
end
And in Compojure, you can write:
(GET "/:name" [name]
(str "Hello " name))
Superficially they look very similar, but their implementation is very different. The Sinatra code adds the enclosed block to a hash map in the current class, whilst the Compojure code just returns an anonymous function. The Clojure approach sacrifices some convenience for greater flexibility. For instance, in Compojure I can write:
Because each route is discrete and independent of any larger construct, I can easily take routes and use other functions and macros to group them together.
I may be wrong, but I don't think there's an easy way of doing this in Sinatra, because routes are bound to a class when they are created.
Thanks. I kinda see where that might lead. It feels much like Rails' nested routes.
There are a ton more questions I'd love to ask, but I feel like I'm taking the thread off topic, so I'll go investigate Compojure a bit more on my own.
Use the right tool for the job. Rails and PHP are pretty good options for web development, and JavaScript is a very good option for small client-side scripts.
On the other hand, if the job is to create artificial intelligence, then it is Lisp that is the right tool for the job.
> Open source projects seem to succeed based more on the energy of their initial organizers
But whomever starts a Lisp language is going to have the usual Lisp suspects looking over his/her shoulder. That's going to dampen most open source organizers' energies, I guess.
So making Lisp more popular would be a matter of getting some hackers on the ground floor of a dialect who are excited about their project. I can't think of a counter-example among the popular languages. If you're right, then it blows away my thesis, but I can't think of a way to test this (aside from watching a Lisp dialect get as popular as Java).
Most of the essay can summarized by this quote from it:
Lisp is so powerful that problems which are
technical issues in other programming languages
are social issues in Lisp.
While this is not a bad essay I'm experiencing a fatigue from reading articles/books/posts about great powers of Lisp and why Lisp is where it is today.
Instead, I'd love to see that mental energy spent on advocacy/defence/adulation/hatred of various Lisp dialects on actually writing great software.
Let's stop looking at Lisp as a religion and instead use it as a great tool to create beautiful things.
Disclaimer: I've used CL, Scheme and Clojure on my various (mostly personal) projects. For the current one, I use Python as it fits better for what I'm doing today. My next project will use whatever it needs to work.
"I'm experiencing a fatigue from reading articles/books/posts about great powers of Lisp and why Lisp is where it is today."
So am I. I wrote the essay because this idea has been banging in my head for some time and I had to let it out. The urgency shows in places. Elsewhere in this thread, others are pointing out that I don't know that much C. Guilty.
Another commenter's suspicion about the "we lost because we're so awesome" theme also has merit. I suppose that Lisp must have some intrinsic problems, but reading about the Lisp Machine period makes the language so enchanting.
Being write-only would explain why there are so few collaborative Lisp projects.
And I don't particularly buy the thesis of this essay that there are few collaborative Lisp projects because it's possible to do anything with a single person. You can always find sufficiently difficult problems that would require a team. Projects in Lisp should be putting projects in other languages to shame. I think there's something about Lisp that makes collaboration too difficult, and I suspect it's the expressiveness itself.
The squint test only passes for one and fails for the other because of your familiarity with the Algol-style language.
I immediately recognized a defun or defmacro in the second, and didn't know wtf was going on in the first. It is a (def-something name (arguments ) &body).
(Also, properly placing curly braces inflames my OCD. It seems like a lot of wasted white space, so I end up stacking them, and then they are impossible to match. So I unstack them, but then everything is all spread out and I don't like that at all.)
So, my point is personal preference and experience there...
Aside from that, there are idiomatic patterns for macros (i.e. let-binding-forms, with-x, def-something, etc.) that you learn and generally stick to.
Then again, I like to read, I am reasonably good at reading, and probably read faster than most.
I dunno, I don't really buy your squint test for languages. While it makes some sense for graphical user interfaces, (most) source code isn't graphical, it's textual, and you wouldn't apply the squint test to the arbitrary written word, would you? Where every page of every book looks the same...
It's true that I wouldn't apply it to prose, but that doesn't mean it's not useful for code, where you often want to look at lots of it and get a gist of what it's doing. Also I often do think of a programming language as a user interface, even if it's not actually made of buttons and icons.
I'm not claiming this is the main problem with Lisp; only that it's one of them.
Excluding books like novels which are written to be read from beginning to end, the easiest to skim-read books have chapter and section divisions, each with intro and concluding paragraphs. They have pictures, charts, and diagrams; they have margin notes summarizing each paragraph; they have color. Each paragraph has a topic sentence, either first or last. The book begins with contents on a single page, then a detailed contents. The written word's come a long way since scrolls were the writing medium.
I'd say the squint test does apply to the written word.
"I think there's something about Lisp that makes collaboration too difficult, and I suspect it's the expressiveness itself."
That goes back to the point of the essay. The expressiveness of Lisp encourages, among other things, the creation of a "little language" for each project. This makes collaboration more difficult. Ergo, it's a social issue rather than a technical issue.
Okay, I see what you mean by that now. I might still quibble that calling it a "social issue" (as opposed to technical) makes it sound like it's not Lisp's fault. A good feature that leads to a bad situation is a bad feature. I want to call out macros for what they are: a feature that contributes to Lisp not being used.
Thinking about it more, I might describe macros as "anti-social" in that they help the programmer but hurt the team. This might be what you meant.
Note that I'm not saying that the idea of macros is bad; only that Lisp's decision to make them look like function calls is bad. I once saw a macro system for Lua that made their invocation look clearly different than normal language.
> A good feature that leads to a bad situation is a bad feature.
Pretty much every technological advancement ever has made it easier for people to get themselves into bad situations (and some people have indeed gotten themselves into bad situations). Cars enable you to move very fast, which enables you to crash and die, and many people have done just that. Clearly, cars have "led" to car accidents, which are surely "bad situations". But would you recommend eliminating or crippling cars for this reason? I don't think so. The solution is for the people who use these tools to become mindful of these dangers, not to get rid of the tools.
... Perhaps you could find some way to make the tools safer without crippling them, and, sure, that would be nice. But what you said was that it was a "bad feature", implying that in the absence of any creative alternative ideas (to remake the feature so that the risks are mitigated while the functionality is retained), it should be thrown out. And in that case, my rebuttal stands.
"The solution is for the people who use these tools to become mindful of these dangers, not to get rid of the tools."
Sure, but after 55 years of Lisp, that hasn't happened. If Lisp is unused because programmers find it hard to resist using a feature anti-socially, then it's time to change that feature.
Of course I have no hope that Lisp will change its macro feature. My interest is in making sure that new language designers realize that Lisp's so-called perfection is the very reason that it languishes.
You've got your squint test backwards. What you should do is leave the letters stand and replace all parentheses and punctuation characters by blanks. What remains is pretty much the semantics-carrying part of the code.
This is what I do when I show people Lispy (pseudo)code in presentations and it works fine. The people who like Algol-style syntax imagine the curly brackets are there and the Lispers imagine they see parentheses.
There's also the tendency among lispers to shoot for the right solution, instead of the working one. I've encountered that a few times in #lisp.
When I write Lisp, I am trying to Get Stuff Done. The Right Way matters, but not until it matters (Everything is fast when n < 10).
So I'd rather advocate by - in due time - rolling out working projects for people to use, pointing, and saying, "Look, this is useful software in Lisp".
c.f., Worse is Better, Worse is Worse, and Worse is Still Better, by rpg.
> Anything that ships is better than the best thing that didn't ship.
Minor strawman... I did not advocate waiting to ship the "best". Rarely are things that ship "short term" systems. Watch the balance. If you have to maintain/update it, you must be mindful of the costs.
I’m always wary of arguments along the lines of “we weren’t successful because we were too awesome”, when there are alternative explanations. Could there possibly be any other reason?
I’ve found Ruby to be very easy to extend, and one complaint I’ve heard is that it’s so easy to write DSLs that everyone has their own incompatible languages. And yet, Ruby is successful. So, how come Ruby is more marketshare than, say, SML? Could it possibly be that most people just find it easier?
It implements most of the unique features of Haskell and OCaml. In some respects, Qi surpasses them. For instance, Qi's type inferencing engine is Turing complete. In a world where teams of talented academics were needed to write Haskell, one man, Dr. Tarver wrote Qi all by his lonesome.
Seriously? Qi is nice, and “better” than Haskell and Ocaml in some respects, but it’s also inferior in many other respects. To port all of Haskell's experimental features to Qi would require teams of people. There's nothing particular to Lisp that would make that orders of magnitude easier. Haskell just has a lot of features.
> So, how come Ruby is more marketshare than, say, SML?
How much of that still applies if you take away Rails (and all the marketshare that came from it, and all the resulting tools, etc.)? Having a killer application makes a big difference.
The killer application of SML seems to be teaching, and awesome compiler research. With all due respect to SMLers, that's much less likely to interest hordes of average web developers.
Separating a language from the things you build in it kinda misses the point of the language. Ruby inspired / allowed Rails. Sadly, Lisp and SML haven't have powered anything of similar popularity.
I have no idea what Rails actually does, but I recently wrote a web application for a school project in Common Lisp, using just libraries (Hunchentoot, LML2 and Postmodern mostly) that aren't really meant to work together in any significant way, and I can't imagine the programming of the application would've been made any easier by using any sort of "framework". And I only wrote one macro if I remember correctly. So perhaps in some sense Lisp doesn't need "rails", good libraries are enough. Anecdotal, I know.
"I'm always wary of arguments along the lines of 'we weren’t successful because we were too awesome.'"
What do you mean by "we?" Implicit in the Lisp Curse is the distinction between the Lisp language and its users. Furthermore, later in that essay, I wrote:
One result of these secondary and tertiary effects is that, even if Lisp is the most expressive language ever, such that it is theoretically impossible to make a more expressive language, Lispers will still have things to learn from other programming languages. The Smalltalk guys taught everyone -- including Lisp hackers -- a thing or two about object oriented programming. The Clean programming language and the Mozart/Oz combo may have a few surprises of their own.
Note the use of the words "even if" in that first sentence. That means that I'm open to the idea of there being a more expressive programming language than Lisp. Especially after taking a look at languages such as Clean and Mozart/Oz (which I learned about by reading Hacker News). And if such a programming language doesn't exist, then (as I wrote in that paragraph) Lispers would still have to have a measure of humility.
Remember that the essay focuses on expressive power, but no one claims that that is the only thing that matters in a language. I did not imply that much. Paul Graham has noted that libraries are probably more important than the base language, nowadays. I took pains to point out that Lisp hackers aren't innocent. Re-read the section where I compared Lisp hackers being satisfied with Emacs and Smalltalk hackers having stellar development environments.
It's not good, it's very bad. Haskell researchers spent years, in fact, attempting to make sure that it was both decidable and ran in less than exponential time.
The fact that some people actually think an undecidable type system is an advantage is simply an astounding disconnect from reality.
This is also an issue in Dependent Types. But the case is not as clear cut as you paint it as some argue that the expressibility lost and complexity gained in the system by forcing type checking to terminate is not worth it in practice.
Type annotations have reduced those cases to very rare instances, but yes there are still cases where the type checker can produce exponential runtime.
"So, how come Ruby is more marketshare than, say, SML? Could it possibly be that most people just find it easier?"
Marketing. Hype. And the familiarity of Ruby's Algol-like syntax.
Recall that before Ruby (and Python) became popular, the scripting language world was ruled by Perl. And most programmers were pretty happy with that. Perl was a mature language. It had tons of libraries. And it generally did what people wanted.
Then, out of nowhere, started a litany of "Perl sucks!" screeches, mostly coming out of the mouths of Python and Ruby fans. By now they've repeated that mantra so often that it's become dogma throughout much of the rest of the programming world, even (and often especially) for people who've never even written a line of Perl.
Ruby and Python took that anti-Perl hatred and rode it all the way to the bank.
Sure, Ruby also had Rails.. which was yet more hype. PHB's started ordering their websites to be written in it, despite having not the faintest clue what it was. Much the same happened with Java.
As for Lisp and SML. They suffer from being "just too weird".
It'll be interesting to see what happens with F# in the long run, as it suffers from much the same "weirdness" as SML (being based on OCaml, which itself was based on SML). Will having a megacorp behind it make enough of a difference?
Then, out of nowhere, started a litany of "Perl sucks!" screeches
Nowhere? Haha, I was there and I'll tell you how it was: a whole bunch of people who'd started writing Perl in 1994 for CGI scripts had cause to revisit their own work a year or 5 years later to maintain it or to add features and found it utterly incomprehensible. The experience burnt us so badly that we all went looking for languages that were less "write only". Python and Ruby had been around for a while at that point, but they got a huge boost from people fleeing Perl. And most of those people are still using Python and Ruby today.
Perl was and still is a great language for what it was intended for: automating system administration tasks, and reporting on them, stuff you can do in 50 lines of code. But for 50,000 line applications worked on over 10 years by dozens of different people, it was never a good choice.
"a whole bunch of people who'd started writing Perl in 1994 for CGI scripts had cause to revisit their own work a year or 5 years later to maintain it or to add features and found it utterly incomprehensible."
You can write garbage in any language. If these people found their own code incomprehensible, it's their own fault.
"But for 50,000 line applications worked on over 10 years by dozens of different people, it was never a good choice."
I've yet to be convinced that Ruby or Python are any better. In many ways they're even worse.
Yes, you can write anything in any language that's Turing complete, but that's not the point. Perl's mantra is "there's more than one way to do it", and so you get code that does it a million different ways. Python emphasizes there being only one right way, and so Python code is inherently more maintainable.
Does every Python programmer use the same sorting mechanism? Object decomposition technique? File layout? Naming conventions? Web framework? Database? Testing strategy? Documentation format? Installation mechanism? Editor?
Semi-enforced consistency of indentation would have contributed very little to the maintainability of any project to which I've contributed. I care more about finding and understanding and modifying code than whether I need to run it through a tidier.
"Out of nowhere"? One of the perennial topics of the mid to late 90s was the idea that Perl needed major fixes to remove common pitfalls (e.g. the object model, syntax warts (nested structures are just horrid), etc) and be more suitable for large projects.
Years passed.
Perl 6 was talked about.
Years passed.
Nothing happened. People gave up and moved on. The same thing's happened to PHP - years of broken things not being fixed eventually causes people to distrust the language's future and prevented it from moving into new niches.
Lisp is more complex, with far more redeeming features, but by now it shares the same failed-promise challenge: I've been writing software for a couple decades, so I missed out on the early history of Lisp, but for most of that time I've kept hearing about how great it is and how it'll soon be as productive as the inferior languages people actually use to get work done - and that point's always been in the future, never the present. Clojure is the only potential exception which I see to that and, to be honest, a large part of that would be due to the Java community's foundation.
I see his point about how everyone rolling their own thing is bad for the Lisp community, but he's got a kind of ridiculous view of C:
"Making Scheme object-oriented is a sophomore homework assignment. On the other hand, adding object orientation to C requires the programming chops of Bjarne Stroustrup."
It really doesn't. You can have a system that uses structs with function pointers, which is how things like Glib work. You can have a compiler that adds special syntax for doing this, which all gets translated into normal C calls; this is how Objective C works. OO is just Not That Hard To Do in any language.
Anyway, Lua is another great example of this curse because there's no module system or standard library to speak of, everyone rolls not only their own object system but their own list functions. The reasons are different though; Lua's design goals are to be a tiny language for embedding, so they sacrifice completeness for being really easy to customize.
Yeah, if you can't implement a basic object system in C, you don't really understand how OOP works anyway.
Also, I definitely agree w/ you about Lua. Great language, but it's so focused on being shape-able into whatever its embedding project needs that the community refuses to settle on conventions for some things. OTOH, it's small & clean enough that running your own fork of it is actually a decent trade-off, whereas doing so with (say) Python would be pretty harsh.
Yeah. The people who are using Lua primarily in an embedded context (and thus have a lot of dependencies, such as threading & graphic libs, already chosen for them) have VERY different priorities than the people using Lua standalone. It pulls the community in two different (and occasionally opposed) directions, and the Lua team doesn't want to alienate either camp.
(On the balance, though, it's still one of my favorites.)
Yes, definitely. The problem I'm running into is that the people writing the module systems are thinking in terms of running it standalone.
I want a way to get a bunch of Lua libraries and cram them into one thing I can easily embed and make available to my embedded Lua interpreter. I can't really visualize how that would work though, so I can't write it yet.
You can compile a set of (Lua) libraries with luac, then insert the bytecode as a string literal in a C program. loadstring works on bytecode, too. With C libraries, link as usual.
There are utilities floating around to reformat the luac.out file (compiler output), but all you really need to do is put
static const char *lua_code = "..."; /* with the body escaped */
If you don't end a line with ;, it will be concatenated to a subsequent string literal at compile time. Oh, and multiple lua files can be compiled into one luac.out.
Does that help? If you have further questions, contact info is in my profile.
That's the core of what I was going to do, but I want to put on top of it something like Bundler, where I can specify which libraries I want (and which ones depend on other ones) and it will build it for me.
Although I think the only one I want is Penlight, so that is probably overkill. :)
>You can have a compiler that adds special syntax for doing this
To be fair, C's base syntax is obtuse enough to make any extended C compiler gratuitously difficult. It wouldn't take a genius, but it would take an unreasonable amount of time and pain.
It's more complication in design than implementation though, and doing it in Lisp instead of C won't help that any. Once you decide what you actually want to write, it's not a whole lot harder to write it in C than Lisp. It's harder, but it's still something that anyone who can do it in Lisp would be comfortable doing in C.
Lua is another great example of this curse because there's no module system or standard library to speak of
I think this, instead of syntax, is the main cause of fragmentation. The more strongly a language community recommends and bundles a module system and a package manager for it, the easier it is to build an ecosystem
Or the explanation could be that Lisp just isn't that great. First of all, it doesn't even make much sense to talk about "Lisp" as if it's a language. The difference between the toy lisp you can write an interpreter for in a page of code and Clojure is night and day. And the other features are actually much more important than just being a Lisp. I'd be afraid to work with the "Haskell" that the smug Lisper of the article slaps out with macros. Not only would it probably not be as well designed as Haskell, unless they copied Haskell's hard work wholesale, but it wouldn't interop well with any other Lisp code.
Secondly, if you actually look at the defining feature of Lisp, S-Exprs and macros, it's not a good idea. Code generating S-exprssions may be more sane than generating C code through string manipulation, but it's still a bad idea and for the same reasons. Code is a human readable format (even if you force it to be S-expressions and pretend it isn't). Code shouldn't be generating other code, it should be generating more structured values. There are composability advantages to doing so and as an added benefit, you don't get stuck with S-expressions as syntax. I predict that in the not too distant future, languages will provide a better alternative to almost every current use of macros (we're already over half way there).
S-expressions are more readable than C-syntax to me. Readability is about familiarity.
The task of comparing English with Russian in terms of readability is not a clear task at all and it's hard to determine how such a judgement would be made.
I would argue that it's just as hard to genuinely judge the readability of S-expr vs. C-syntax.
People whose first language is in Russian obviously find the Cyrillic alphabet to be more readable and wonder why anyone would use anything else. To me Russian looks like scribbling.
Familiarity is probably the prime factor in readability. And it is indeed a subjective one.
But there are also objective factors.
Infix function application allows for easier visual parsing of the expression tree's components. There's a reason mathematicians have been using infix notation for centuries before we had arbitrary other constraints for choosing notation.
In fact, if you look at mathematicians' notation, you will see that not only is it horizontally infix (arguments left and right of the function), it is also vertically infix, and arguments are placed above and below (Sigma, Integrals, etc.).
People have come up with many rationalizations, but really, anything that doesn't have a mostly C/Java-style syntax just pisses off the majority of programmers.
When you look at languages that actually, consistently use infix and mathematical notation (http://nsl.com/k/ray/rayq.k), they seem to give most programmers fits.
Infix also only really works for unary and binary operators, of course.
since 99.9% of every language is in prefix notation i cant buy this.
when mathematicians type f(x,y) they are using prefix notations.
likewise when programmers type run(x, y);
Anecdotally, most advanced mathematicians prefer Lisp because it is more conducive to a mathematical way of thinking. I am a very mathematical programmer and I prefer lisp specifically because I don't have to deal with operator precedence. Everytime you use infix notation you introduce a bunch of unnecessary complexity and often you complicate the ability to use simple recursion.
Gregory Chaitin, eminent mathematician, writes his proofs in Lisp for a reason.
Is it truly easier to write
print(a + " " + b + " " + c + " ");
rather than
(print a " " b " " c " ")
?
I greatly prefer the latter. The first one is weighed down with unnecessary special cases, unnecessary complexity.
The benefits of Polish notation are apparent with math as well. You don't need to reformulate the entire calculation and figure out messy operator precedence rules when you want to add a term. I think RPN lends itself to bug free code and easy modifiability.
To each his own I suppose. C-syntax to me is completely nonsensical and I don't see what problem it is meant to solve. I'm sure Russians view the Latin alphabet in the same way though.
Mathematicians have few prefix functions. Most functions are infix and many in more than one dimension.
I think a statement like "Most advanced mathematicians prefer Lisp" is pretty extraordinary and demands extraordinary citations.
Your comparison was dishonest, as you compared manual concat and print with a function that concats and prints. You really meant to compare full infix (e.g: in Haskell):
print $ a ++ " " ++ b ++ " " ++ c ++ " "
with full prefix:
(print (++ a (++ " " (++ b (++ " " (++ c " "))))))
Which do you find more readable?
The anti-precedence notion behind putting () around each application requires parenthesis even when associativity laws show that there is absolutely no difference between difference precedence interpretations. In this sense, the () are pure noise in this example.
Of course, if you use ++ so many times, you'd prefer to just use (in Haskell) something like:
print . intersperse " " $ [a, b, c]
Lisp's print has to embed the concatenation of its arguments or else it would look as horrible as shown above. It is still disingenuous to compare it as equal.
One consequence of the parenthesis and prefix notation is that n-ary operators are idiomatic in lisps. So, the above example would more likely be written:
For flat expressions, prefix is fine, and using n-ary operators is a great way to flatten many trees. n-ary operators cannot flatten every tree, though. When your tree isn't flat, and is built from primarily binary operators, infix makes the tree structure more apparent. The way we would draw trees on paper is how it would appear in the infix expression.
I think that you're the only person in this thread who openly questions the cheer-leading of Lisp. I respect that. For that, I gave you an upvote. Heretic.
Sure, the pile of Lisp macros that recapitulates most of Haskell would be gnarly and nasty. But would that be due to the intrinsic bogosity of doing it through macros, or would it be due to it coming from a lone hacker who's following the scratch-an-itch school of design?
Code is a human readable format (even if you force it to be S-expressions and pretend it isn't). Here's something for which there's no accounting, as the Romans used to say. Plenty of smart people love S-expressions. Plenty of smart people can't stand them. John McCarthy thought that S-expressions would go away, but no one got around to that in more than half a century. Someone must find them readable.
Code shouldn't be generating other code, it should be generating more structured values. You must know more than me. Something more structured than code?
I think the reason that S-expressions haven't gone away is mostly because of the way they mesh with macros, but anyway the sub-optimality of S-expressions as a syntax wasn't a part of my argument there (I don't like them, but I don't hate them). In that quote, I meant there that all code, even S-expressions, is a human readable expression that defines the thing you're interested in.
Note that it's considered poor form in Lisp to make a square macro that multiplies its parameter by itself. That should be a function. Why? Because numbers have the structure you want them to have. A function that takes a number and multiplies it by itself is just simpler than a function that takes an expression for a number, and pastes it together with an astericks and then returns that to be evaluated. And because the function has a better structure than a macro, it's more composable.
The thing is that this same situation exists with most other uses of macros. In a language with staged computation and maybe a little well tamed syntax extension, I think there would be no place for macros. You can do better.
"Sure, the pile of Lisp macros that recapitulates most of Haskell would be gnarly and nasty."
I don't think you can macro your way to Haskell. Haskell wants a guarantee that if some function takes a function of type Int -> Int, the passed-in function will absolutely positively not do anything in the universe except take an int and return an int, and if that isn't true and that closure can do something else, Haskell breaks. Even if you can macro your way towards restricting arbitrary closures like that, you don't have Lisp anymore; you've got Haskell. Or you don't have Haskell and you do have Lisp. The two are fundamentally opposed at a deep philosophical level.
As someone who has programmed Lisp commercially for a long time, I have to agree with this essay. I've had much the same thoughts over the years.
At one point I was one of five Lisp engineers in a 10-person company. I think we had no fewer than five hairy macros for creating complex UI layouts, because everybody wanted to do it their own way, and you could hack something like that out in an afternoon.
You'd never get the same kind of phenomenon in a Java-based project, because creating something like that in Java is a major undertaking, so you'd have people settle on one that probably came from outside, and a whole ecosystem of sponsors, books and whatnot.
Just very different worlds. But Lisp programmers can't reinvent the wheel all the time, so I'm very glad of things like Cliki, asdf, and Quicklisp that are promoting sharing and standardized libraries.
I think we had no fewer than five hairy macros for
creating complex UI layouts, because everybody wanted
to do it their own way, and you could hack something
like that out in an afternoon.
Even though I have worked in commercial environment other than Lisp (never Lisp so far), there are lots of things that can be hacked out in an afternoon. Yet having five hairy sets of duplicated functionality is something I'd never let stand for long. It seems to be a culture thing rather than a language thing. Is that right?
I don't think you can separate language and culture so cleanly.
Oone of the attractions of Lisp is that you can mold the language so its just the way you like it. That makes it harder, sometimes, to have a group come to a consensus about the way things should be. It's just a tradeoff.
As somebody else pointed out recently, highly empowered individuals can be a downside from a management perspective, and that perspective is not entirely wrong, although it's maybe not the way hackers think.
But it's a tradeoff that has left Lisp with one major app in 40 years (Emacs)? A handful of notable apps... and that's it.
And why, in a space like phones, where one dev can produce an app in a week to months, are there no incredible Lisp applications? This seems like the perfect domain where one to three devs is all it takes to make a world-class app, and theoretically with the awesomeness discussed in the story we would expect at least one Lisp app that was just mind blowing. Of course that hasn't happened.
IMO, what I think happens are those people who are attracted to Lisp are those who like language purity/elegance and bask in it. They tend to be those that over-attribute the power of a language to the productivity of a developer. They have a great language, and are bright people, yet the result is nothing beyond the normal range of expected output. So they then try to create a rationale that combines their belief that they have a super language, with some odd external force that keeps that language from showing its true power to the outside world. Missing perhaps the most obvious thing which is that in terms of expressability/productivity, language is probably a 1.5x multiplier at best. But if they concede that the multiplier on productivity isn't at least 10x, they may have to admit that the beauty of the language is mostly a form of self-gratification.
Well, there are more than a few, but they tend to be highly specialized, knowledge-intensive apps that you've never heard of. Here's a list from one Lisp platform vendor -- I've worked on several of the projects listed there: http://www.franz.com/success/all_customer_apps.lhtml
Then there's ITA, recently acquired by Google, I assume you've heard of them? All Lisp, as far as I know.
I'd put ITA, ViaWeb, and a handful of others in the notable category. Although all I know about ITA is what they do (at a USA Today level), its Lisp (at the very least a large majority), and that they were bought by Google. Maybe ITA can be promoted to the Emacs level?
That vendor list is a nice reference, but I wouldn't be surprised if the D programming language vendor list was near that size. And no one uses D. Just imagine a similar list for virtually any other language commonly discussed on HN, from C/C++, to Java, C#, Python, Ruby, Javascript. I'd be surprised if Smalltalk wasn't 10x the size.
Don't get me wrong, I think its a great language. I just don't think any language gives the benefits that so many people seem to think they do, at least not general purpose languages. DSLs? Sure, they can give huge multipliers -- in their domain or maybe even for a specific domain. But not in general (and maybe those knowledge-intensive apps are those for which the multiplier is higher).
So if I were to learn and use a Lisp and then lure some other non-Lispers I know into a start-up using Lisp, then we would fall into the same problematic cultural patterns? I can see the temptations, but I don't think it would be a forgone conclusion. At least I hope not.
Thanks for your thoughts, and if you reply again I'll be interested to read it.
Thank you. It's stories like this that inspired my essay. I wish that I had saved links to all of those other instances.
Whenever I've read of people complaining about the dearth of code libraries for Lisp, sooner or later, some commenter points out that they would rather roll their own functionality into whatever project they're currently doing. It happens too often to be a coincidence.
> sooner or later, some commenter points out that they would rather roll their own functionality into whatever project they're currently doing. It happens too often to be a coincidence.
I suspect a lot of this has to do with the fact that it took the CL community over two decades to create QuickLisp. It boggles my mind why this wasn't created sooner--perhaps sharing libraries wasn't a high priority because the libraries tended to be spotty to begin with? So you may have had a chicken/egg problem.
An alternative explanation is that Lisp doesn't have a person with a strong vision, program management skills, a thick skin, a diplomatic way to saying no, and a big ass repository.
The same argument is repeated throughout the essay, "Its not that Lisp doesn't have X, it has {X0,X1,..Xn)!" and that is the problem. Using lisp I get no or very low re-use for any code out there. Ergo I must write a lot of it myself. He recognizes it and laments:
"Look more closely: Large numbers of the kind of people who become Lisp hackers would have to cooperate with each other."
At the solution. But here is the rub, the qualities of the lisp user today are, in part, derived from how difficult it is to re-use code. People who could write anything they wanted enjoy the expressive power of lisp and tolerate the requirement to create from whole cloth basic things that should exist already.
Now posit a world where there was the Lisp equivalent of CPAN, and an aggressive authoritarian requirement on documentation, coding standards, and unit testing. Once sufficient mass had built up in this repository, even dweebs who don't know the difference between arrows and monads could use Lisp to make something useful, and they would take on the false mantle of 'lisp hacker' and the population of lisp users would swell and there would be still more things checked in and poof a thriving 'lisp' community, except it wouldn't look at all like the current community.
You make it sound like CPAN has "an aggressive authoritarian requirement on documentation, coding standards, and unit testing" (or at least that Lisp would need that to make a hypothetical LPAN successful).
CPAN definitely does not have that. What it does have are fairly strong social pressures in favor of those things, and extensive frameworks making it easier to provide those things (I'm thinking in particular of cpantesters.org providing free cross-platform unit testing support for all of CPAN).
Oh lordy...this essay effectively summarizes the entire codebase of the lisp application that I work on with a team of 6 or so other developers.
I think what can work though is having an awareness of the power of the language you are working with, and then balancing the usage of that power with readability of code. You can write macros all day that save you precious typing time, but when someone else has to figure out those macros all that saved time is lost. Any language that allows the developer to define the syntax will always be troubled with this concept.
This idea kind of reminds me of the notion that ideas are cheap, and that execution and hard work are what it really takes to create a valuable company.
It seems to me that the hard part of developing language features is developing the documentation and the tools, and it's this work that will drive language popularity much more than the features themselves.
I suspect there are similarities to : Why aren't the smartest people the richest, why dont they get laid the most?
The lisp language 'microkernel' is clearly a fundamentally important construct - the essential core of all computer language.
But lisp needs to interact with the surrounding ecosystem - less than genius level programmers, ugly APIs, non-mathematically perfect OO abstractions, old fashioned data stores. Its actually a lot of work to wrap that... given the impedance mismatch. Perhaps this is the same reason microkernel operating systems have won in theory but not in practice - interfacing to 'the real world'.
Comparing Arc and Scheme [both of which I really enjoy] to the Javascript / node.js 'environment' ... it seems Node.js is more amenable to real work. Its a less expressive / powerful / elegant language - but via Node, Javascript melds beautifully with the async IO model of the OS and gives superb primitives for developing TCP/http services.
Maybe its not the breadth of the libraries available, but the smoothness of the bridge between the language and the real world.
Geeks who apply their smarts and learn something about social interaction do get laid [ to abuse my analogy ].
I think this essay is bull. As someone points out, it is yet another I-am-so-good-that-no-one-wants-me things that LISP people love to throw out. Maybe THIS attitude ("Lisp is Olympia and I, the proud user, is Zeus") is why.
Let's be frank, there are many many excellent languages that do not even attract enough people to have a "community." Icon always comes to mind as example: brilliant language, excellent libraries, but the only believers are myself and a professor. Other than that, Haskell, SML, OCaml have never attracted a significant number of users. They all are brilliant, right? BASH may have more serious products than those great things.
Let's face it, the true Lisp curse has not been discovered, and Lispers' attitude has helped it hide even better. I have my theories; you have yours. And mine are always more correct than yours. It's Lisp land, man. You can't argue against that.
You, a professor... and about 15-20% of anyone who came out of the University of Arizona over a decade or two. :)
I remember writing a java library to do SNOBOL/Icon-style pattern matching in college because I hated the java way so much... every once in a while, I think about doing it again.
Large cooperative programs are usually written once but read many times. For large projects to succeed, the reading part needs to be optimized.
Lisp being too expressive encourages the optimization in the writing part - I can write my own macros/DSL to make writing MY program easier. The readers needing to learn and understand those are their problem. This encourages people to write their own libraries instead of understand and reuse the existing ones since it's always easier to build a mental model of your own writing than the others.
As noted by the others, Scala is starting to have the same problem in regarding in its ease of proliferating DSL.
The beauty of Lisp is in its simplicity. Lisp has the simplest syntax in the world, and the entire language is based upon five simple primitives.
All other mainstream languages complicate matters with operator precedence tables, multiple operator notations (prefix, infix, postfix, postcircumfix, etc), and many other syntactic weirdities.
The simplicity of the language makes it the best language there is for collaboration. Lisp is not to blame here - the community is.
A properly organized community can create standards for the use of macros to prevent their abuse and standardize on libraries to prevent fragmentation. Unfortunately, the Lisp community isn't well organized.
A properly organized community can create standards for the use of macros to prevent their abuse and standardize on libraries to prevent fragmentation. Unfortunately, the Lisp community isn't well organized.
In other words, it's not a technical issue, it's a social issue.
Not all professional programmers are college kids with degrees in C.S. Imperative languages are much easier to get your head around than OO-languages if you don't have a formal training. And lispy abstractions like map and first order functions are even trickier. So I thought it's natural that the more abstract a language, the more difficult it is for it to make it into the corporate world.
That's true but if you want to learn Lisp (anything) well you will have to see examples, talk with peers etc. Everyone discourages too much imperative code in Lisp so this will be very hard to pick up on your own. So to be an effective Lisp-learner you will have to grok map, first order functions and what not.
Common Lisp is both imperative and object-oriented, with one of the most powerful OO systems out there (CLOS). It's a lot less oriented towards functional programming than things like Scala, Haskell, or even Clojure, which is probably more used than CL in the modern "corporate world".
It is past midnight where I live and it has been a long day, and I am sure it is my fault, but I am having some trouble identifying the central point of the essay.
Is it something like "The curse of lisp is that it is too expressive"? Genuine question. Please help.
Close. The Lisp Curse is "Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp." Lisp is so powerful that an individual programmer can do a lot more than he could if he were using another programming language. This seems to encourage fragmentation and provide less encouragement for cooperation.
Thank You. Now I understand what you are trying to say but am having trouble seeing the logic supporting that assertion.
How is lisp so much "more powerful" than (say) Haskell (or Erlang ) to such an extent that problems which are technical issues in Haskell or Erlang are "social issues" in lisp? It seems to be that without some serious convolutions wrt "power" to fit a pre existing bias, lisp is hardly "more powerful" than Haskell ,or SML (or erlang or smalltalk or J or even Lua).
Most of these lisp "power" comparisons seem to focus on easy to beat up languages like PHP or Java and not so much the better designed ones like Erlang or Haskell, which have vibrant communities and plenty of interesting software written in them. Is lisp really "more powerful" than Erlang? or Mozart/Oz? or Haskell?
I suspect pg's ideas of language success depending on the energy of the main Open Source contributor + mainstream programmers aversion to S-expressions may be more accurate.
Maybe all we have to do is wait a year or two and see which of Scala or Clojure dominate on the JVM. The founders of both are very talented and energetic.
If you are right, Clojure should end up "more powerful" than Scala but having (relative to Scala) this "problems which are technical issues in Scala are social issues in Clojure" dynamic. I somehow don't see that happening though.
> If you are right, Clojure should end up "more powerful" than Scala but having (relative to Scala) this "problems which are technical issues in Scala are social issues in Clojure" dynamic.
Part of that is because Clojure isn't starting from scratch when it comes to conventions; there are strong admonitions as far as avoiding side-effects, favoring composable functions over macros, and re-using functionality from the JVM where appropriate.
The reason Lisp programmers don't have a fancy IDE is that they don't feel the need for it. Everyone that really understands what he's doing is using Emacs or their own thing.
In a way it is similar for other languages. Why Ruby doesn't have something like Eclipse? Because it doesn't need one. Even for C/C++, the only reason why there is a Visual Studio is that there are so many entry level programmers that will buy it. Experienced C programmers feel much more comfortable using UNIX/gdb.
On the other hand Smalltalk programmers have an IDE because they need it: it is just the way it works for Smalltalk.
> Even for C/C++, the only reason why there is a Visual Studio is that there are so many entry level programmers that will buy it. Experienced C programmers feel much more comfortable using UNIX/gdb.
That comment is insulting, impossibly overgeneralized, and counterfactual, all in one. Heck, I'd be hard-pressed not to put a gun in my mouth and pull the trigger before trying to work with gdb and anything multithreaded, and for anything more than doing an autopsy on a core dump gdb is still user-hostile and obnoxious. Visual Studio is _so_ much less of a hassle than trying to pore over obfuscatory gdb backtraces.
I pay for a personal license for Visual Studio because it lets me get my work done without wasting my time. And I'm a pretty experienced developer, both on Unix and Windows (though I've moved away from C because it is a poor choice for the development I most enjoy doing).
Ruby uses runtime name resolution. When you use a name "x", it is impossible (in the general case) to figure out what the name refers to statically.
Thus, in Ruby and other dynamic languages, there's much less an IDE can do. Even renaming a variable is an undecidable problem in these languages.
I know plenty of experienced/talented C/C++ programmers, and most of them prefer to use IDE's despite recognizing some of the weaknesses of contemporary IDE's. I've been programming C for 15 years (of these, 10 were professionally) and I would love to use a good IDE.
Unfortunately, I haven't found a good IDE yet and so I make do with emacs. But the moment I find a good IDE with usable refactoring tools while still retaining emacs-level keyboard macros and other useful features of emacs, I'll switch.
> The reason Lisp programmers don't have a fancy IDE is that they don't feel the need for it. Everyone that really understands what he's doing is using Emacs or their own thing.
Actually, I think that Emacs+Slime for CL is one of the fanciest IDEs around.
However, it's also been my (anecdotal) experience that many C++/Java-programming Emacs users have no idea what kind of stuff these fancy IDEs do, the same way most of those IDE users don't have any understanding of the kind of text editing Emacs is capable of.
You're right about Emacs+Slime being nice for CL, but I don't think Emacs is very good for C++ and Java code. Visual Studio (and similar IDEs) have some killer features: Intellisense/autocompletion that "just works", an extremely good debugger, visual representation of the project structure, plugins for refactoring, integration with Qt and GUI editors...
I'm mainly a C++ programmer, and yet I use Emacs for everything but C++ (IRC client, LaTeX or text editor, Haskell IDE...).
The problem with this argument that I see is that Lisp can't make everything easy - there will still be more advanced problems that take collaboration to solve. Thus while other programmers band together to make simple web servers, Lispers should in theory band together to tackle deeper problems. Which would make it more competitive than other languages, not less.
By Lisp, perhaps he was referring also to Scheme and Clojure. Not everyone is aware that they're Lisps, too. (Detailed rationale and citation needed.)
For Scheme, nothing's ever really gotten off the ground. Little more needs to be said on the subject than "R6RS module system debacle." There are meta-module systems for Scheme. I'm waiting for the meta meta-module system.
Clojure, however, has http://clojars.org/ and lein (and cake). I've found that Clojure programmers are way more prone to look for something that exists and (perhaps mostly) fits the bill before rolling their own. I attribute this not to Clojure programmers being smarter or better human beings but to the relative ease of creating, searching, and resolving package dependencies.
Regarding Clojure, perhaps this is because the audience of the language is different than other Lisps. I do think that a lot of Clojure users are first time lispers or old-time lispers that moved to something else and are now coming back thanks to the current "fame" of the language. Simply put, Clojure-ers have an unusual background compared to other lispers.
As far as I'm concerned, I'm quite pleased by the Clojure ecosystem (even though I do hope it will extend) and, coming from Python, don't have too much trouble getting things done (besides struggling with my OOP habits / lisp itself).
The Scheme community is too fragmented for a meta meta-module system to work. Racket and Chicken both have decent module repositories, at least. (Probably some others do, too.)
No meaningful experience with Clojure, but it probably inherits some library culture from running on the JVM as well.
Clojure sure does. Look at something like maven. It has lots of features but alot of people don't like it. All we needed in Clojure were some people to creat good abstraction over maven and boom! we have a great package system.
If you want to live on something like the JVM you have to use all its powers to the max because if you don't its weaknesses will be bigger then the its benefits you get.
It is orders of magnitude better than what we had previously.
The only thing that worries me is that it seems that you are running it mostly by yourself?
Is this true? That must be a lot of work. I hope you can devise a way to have multiple maintainers. (I suppose the source is out there, so everyone could have their own node, but that might defeat the purpose...)
There are tons of incompatible, undocumented libraries for Perl, Python and C. This is no correlation to anything. The people who want to use existing libraries use them. Those who want to reinvent the wheel will do that and there is nothing you can do to stop them.
Lisp Machines aren't magic.
If you think GNU Emacs is "obsolete," you can work on http://common-lisp.net/project/climacs/ or http://common-lisp.net/project/phemlock/ or http://mclide.in-progress.com/ , but don't expect anyone else to share your opinion. GNU Emacs is the best multi-language, multi-platform programming environment available today. Most people somehow manage to avoid the "Lisp Curse" and just work on improving Emacs extensions.