The Lisp Curse
winestockwebdesign.com
Come on, everyone! Let's beat the dead horse one more time!
winestockwebdesign.com
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.
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?
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.
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.
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.
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.
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)
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.
Thank you for wasting our time.
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.
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.
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.
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 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.
Disclaimer: I guess by association I'm affiliated with this group[1].
Scheme has first class anonymous functions, while Ruby has blocks, which are a hack around MRI's slow function calls.
Is this really the reason? I thought Ruby has blocks because Smalltalk has blocks.
Nope.
The creators of C were witness or party to some earlier languages, but they weren't well versed by any means.
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.
(for the record, I like Lisp)
This suggests lisp code is less approachable for second authors, precisely because of its expressiveness.
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 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 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.
On the other hand, if the job is to create artificial intelligence, then it is Lisp that is the right tool for the job.
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.
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.
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
(GET "/:name" [name]
(str "Hello " name))
(context "/:name" [name]
(GET "/email" []
(str name "@example.com"))
(GET "/greet" []
(str "Hello " name)))
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.
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.
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.
Lisp is so powerful that problems which are
technical issues in other programming languages
are social issues in Lisp.
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.
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.
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.
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.
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.
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.
I'm not claiming this is the main problem with Lisp; only that it's one of them.
I'd say the squint test does apply to the written word.
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.
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.
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.
There is no "long term" unless the short term system survives.
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’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.
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.
What if the things you build in it are all largely similar, mostly small variations on a common theme?
It's the difference between "Foo is a great language", and, "Foo is a great language for building applications that do Bar."
Why no rails in lisp? I think the essay gives a good answer to that question.
Why is that good? Decidability is a nice property of a type system...
The fact that some people actually think an undecidable type system is an advantage is simply an astounding disconnect from reality.
http://www.seas.upenn.edu/~liminjia/research/papers/lambda-e...
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.
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?
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.
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.
Even Python 2.7 versus 3.x belies that.
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.
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.
See http://onyxneon.com/books/modern_perl/ for another view of Perl 5 history.
"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.
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.
(On the balance, though, it's still one of my favorites.)
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.
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 */
Does that help? If you have further questions, contact info is in my profile.
Although I think the only one I want is Penlight, so that is probably overkill. :)
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.
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
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).
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?
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.
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.
How is code not a structured value? Do you mean that instead of some properly typed AST you only have lists, symbols etc?
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.
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.).
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.
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 + " ");
(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.
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 ++ " "
(print (++ a (++ " " (++ b (++ " " (++ c " "))))))
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]
(print (++ a " " b " " c " "))
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.
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.
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.
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.
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.
Then there's ITA, recently acquired by Google, I assume you've heard of them? All Lisp, as far as I know.
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).
Thanks for your thoughts, and if you reply again I'll be interested to read it.
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.
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).
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.
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.
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 ].
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.
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.
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.
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.
There are features that complicate the language and simplify programs and vice versa.
Is it something like "The curse of lisp is that it is too expressive"? Genuine question. Please help.
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.
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.
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.
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.
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.
I'm mainly a C++ programmer, and yet I use Emacs for everything but C++ (IRC client, LaTeX or text editor, Haskell IDE...).
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.
No meaningful experience with Clojure, but it probably inherits some library culture from running on the JVM as well.
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.
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 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...)
I intend to publish more tools and set up more infrastructure to make collaboration and delegation easier, but it all takes time.