Where Lisp Fails: at Turning People into Fungible Cogs
loper-os.org
loper-os.org
Why is it that in RAD application competitions, "mainstream" languages often win?
Also, if it were truly n times better the library disparity wouldn't exist; libraries should be n times faster to make or duplicate.
I'm asking for evidence here: how can something be so much better and have such a paucity of evidence for it's efficacy? If there really is such scientific evidence for lisps effectiveness I would love to read it & and distribute it to my colleagues in charge of large development teams.
Why don't the lispers organize a RAD competition between lisp and all-comers, surely if lisp is that much more productive you would see the top ten places being lisp dialects.
Would you agree?
In other words, the reason why not is probably "because organizing things is hard work".
Many thousands of programmers spend hours each week in pissing matches online. Why is it none of them feel like truly putting their money where their mouth is?
Writing a "Hello, world" is going to take about the same amount of time in any language that isn't a turing tarpit. At issue is generally some sort of asymptotic advantage, not a guarantee of "language X will always be superior every time always". In fact, for any pair of one easy and one hard problem, I'm pretty confident I could find (or invent, if necessary) two languages that each beat the other for solving one of the problems.
The claimed benefits of a more expressive language generally involve things like better management of application complexity, or greater ability to modify and restructure late in the project. Hammering out a program of a scale such that the programmer can keep an accurate model of the entire thing in mind at one time, and that is only written and never modified, would be more a measure of the programmer's typing speed and the sophistication of the IDE used than anything else.
As for studies, a quick search on google came up with this: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117...
Which concludes that "Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++."
I couldn't find much more in a short time. Perhaps my search terms, "functional programming imperative productivity" were inappropriate.
This paper although makes me think they compared programmers not languages, as the imperative language programmers didn't have any functional experience. It would be interesting to see a comparison between programmers of roughly equal competency.
Despite that complaint, the above is nearly impossible to do in practice. So you have to settle for smaller problems, which can be done in several months perhaps. Even at that, it would take some very difficult collaboration, and would still be a single data point.
Further complicating issues is the academic world vs. industry. Again, ideally you'd want to do the test in industry, with an appropriate team of programmers and managers. But industry doesn't want to waste time with such academic matters, nor does it want to open it's code for analysis.
In other words, it's a very difficult problem to address, despite being seemingly simple on the surface.
Also, though it's not explicit, I feel it's obvious that the researchers had a prior bias toward functional languages.
So, no, I wouldn't agree.
The best study I could think of off hand would be a randomized study of programming productivity (measured somehow) of programming naïve high schoolers. Each subject gets an incentive to learn some language over the course of X weeks and then program something. The sample size would have to be magnificent even to prove a large effect because you'd need to demonstrate control for intelligence/drive and regressing out math scores (or anything similar) would not be convincing really. At the end, you'd still not be able to talk too much about working productivity, but you might have a chance of talking about... anything at all.
Actually, this is an extraordinarily difficult study I think.
Surely, there has to be at least some evidence in it's 50 years? Especially given the claimed huge effect size.
Smart and dumb people have succeeded with all kinds of languages on all kinds of platforms that are widely viewed as amazing and terrible and everywhere in between, on all kinds of projects.
That synopsis of a study is nice but I'm still not convinced all the important variables were isolated.
Oh, they often are... and that's why nearly everyone just builds their own. Ease of building it yourself compared to learning someone else's system is a major reason Lisp is languishing, in my opinion.
If people can't understand the code, they can't contribute, so you don't end up with the network effect of F/OSS contributions that make a language popular (note that I say popular, not better)
I think that, in fairness to Lisp, if you take two people who have never programmed in their life, and if each of the two has a reasonable and approximately equal amount of skill and potential for being a decent developer, and taking those two individuals, you teach one to develop in Lisp, and one in, say Java. Given that situation, I don't think the Lisp developer will find his code more difficult to read really at any stage of his learning (more difficult that is, than the Java developer finds his code to read at a similar stage of learning).
It seems to me, from every testimony I've read from developers who have come to Lisp after extensive careers using other more popular languages, that there is a "breaking in" period where it takes some time to get used to things. However, anyone I've read about who put in any reasonable effort to learn a Lisp (or a language related to Lisp, like Scheme) seems to repeat what others like him or her have said -- you get used to the syntax after a while, and then at the very least it no longer bothers you or gets in your way.
s/CSS/Lisp/
Standardization seems to be anathema to the individuals who are attracted to lisp's power and flexibility. If lisp ever achieved code fungibility, lispers would hate it.
7. Go to, let us go down, and there confound their language, that they may not understand one another's speech.
Genesis 11:6-7 http://www.omniglot.com/babel/english.htm#kj
I am deeply suspicious of explanations that boil down to, Lisp isn't popular because the average programmer isn't smart enough. Let me tell you, anyone smart enough to use C++ in anger is smart enough to use any language.
The real world is highly competitive, and organizations that think they can win by using niche languages, do. There's APL at Morgan Stanley, Ocaml at Jane Street Capital, K at Lehman's (OK, maybe that's not so good an example), F#, Haskell, blah blah. Lisp isn't even on the radar, anywhere. What does that tell you?
The big Lisp success stories all start from the premise of a bunch of programmers who are already hugely experienced in Lisp happening to do this project in it (e.g. Viaweb, Orbitz). But when people with 20 years experience in C complete a project successfully, it isn't blogworthy news...
"obj__parent__name_eq"=foo
obj.parent.name == foo.
http://reference.wolfram.com/mathematica/guide/Patterns.html
I've programmed Python and Lisp, and have begun writing some projects of reasonable size in Mathematica. There are only a couple of major differences between Mathematica and lisp. One is syntax: f[a,b,c] vs (f a b c), as well as some infix syntactic sugar. The other is that arrays are used far more widely in Mathematica than in lisp (but that may be due to the problem domain of mathematica).
Mathematica is lisp + a bunch of a math libraries + vendor support + slightly different syntax + renamed functions. The syntactic differences:
{a b c} -> '(a b c)
f[a,b] -> (f a b)
a == b -> (Equals a b)
(* comment *) -> ;;comment
Lisp is a bit remote from machines and their operating system: GC, data formats, ...
Lisp has many degrees of freedom. It is much harder to control. It is designed for flexibility (even at runtime).
The original Lisp was done for 'symbolic computation with recursive functions': Theorem provers, machine translation, computer algebra systems, knowledge representation, planning systems, ...
If your problem domain fits into above list, then Lisp is likely to be a good candidate language to use. Then there are related domains where Lisp has been used with success: expert systems, algorithmic composition, language implementation (compilers, ...), deductive databases. Again, Lisp may be very useful in these domains.
There are lots of domains where it does not fit that well or is mostly useless. From the domains above you can see that those are not domains that many people work in (compared to web development, database apps, accounting apps, ...). Lisp is quite useful in those domains, but they tend to be a bit remote from the current mainstream.
Viaweb and Orbitz are exceptions. Most Lisp applications are relatively unknown and they are not widely published. Huge successes were for example DART and SPIKE. DART was a logistics system for the military (it is said to have repaid all the government expenses for AI research made) and SPIKE is s scheduling system for telescopes (originally for the Hubble Space Telescope). These applications were not written because some guys knew only Lisp, but because lots of the research applications in planning and scheduling systems were written in Lisp - because in this domain these applications work with symbolic representations of plans.
In C (and c-like languages) that barrier is relatively low, a handful of concepts and a very limited subset of library modules and you can go a long long way.
Oh, that why Perl is languishing too. Well, the problem is how hard it is to learn someone else's system in Perl. If Lisp has that problem, well, there you are.
In other languages, this is just something everyone has to live with, and because of that, libraries face strong selection pressure to be one or more of simple, fast, standard, etc. There is no particular pressure like that in Lisp, since there's a much smaller domain where it's easy to understand why you need a thing, and troublesome to build it. To a much greater degree than mainstream languages, then, there are almost as many "language + standard library" sets as there are Lisp developers. You can see this same effect at work in Python web frameworks, I think.
Let's look at the number of jobs advertised for Perl, Python, Ruby, and Lisp over the last 5 years:
http://www.indeed.com/jobtrends?q=perl%2Cpython%2Cruby%2Clis...
The number of Perl jobs is more than those of Python and Ruby put together. Lisp has so few jobs it doesn't even really show up on the chart.
Then there's Perl's CPAN archive, with over 17,000 modules, with about 30 modules updated or added per day. That much development is a sign of an active, alive community.
So the rumors of Perl's demise are greatly exaggerated.
Take that to its logical extent, and ... wait, which Lisp implementation do you use again? Mine only works with SBCL, crap, nevermind.
When somebody has a really thoroughly debugged C library, it can be like huddling everyone together by a fire for warmth in the tundra. If you don't share, man, that's just cruel.
Yes, of course, many things contribute to success other than language choice. That's my point.
I began to write a reply to your question, but decided that it deserved its own post:
http://news.ycombinator.com/item?id=1016762
What's wrong with that as evidence for lisps superiority?
That isn't really a reply to the question posed. Just more ranting and raving.
Sample: "Yes, my dear bean counters, you can measure productivity. I would no more ask you to stop in your attempts at its measurement than I would ask mosquitoes to stop sucking blood. You can measure productivity – even of Lisp; even of political philosophies. You will simply need to secure a very large bag of beans – one deep enough to hold a bean for every twist and turn of a century of tinkering, politicking, and everything else associated with the messy business of successfully thinking new thoughts."
The best interpretation of this drivel is that you want people to accept your claims of superior productivity just on your say so but not ask for any evidence because asking you back up your unsubstantiated claims of superiority would be "bean counting".
Forget the scientific studies. There is another kind of "evidence" in programming - write code that is evidently superior. The best way to show that (say) Linux is an "inferior" operating system is to build one better. Not talk about making one sometime in the misty future. Build. Then talk.
Endless rants aren't as good. As silentbicycle says elsewhere
"I just take issue with how some particularly vocal Lispers have been sitting on the sidelines going, "Our language is THE BEST LANGUAGE" for decades. ("Sick of being a blub programmer and working in Blub? Try our Language For Smart People.") They're so used to being smug because their language was thirty years ahead of its time, fifty years ago."
One of the most valued metrics of "better" is "how does it fit into the ecosystem". Plan 9 is clearly superior to Linux. It has cleaner interfaces, one person can understand it, lot's of things are unified that were disparate etc. etc. Everyone who uses both extensively berates Linux at every turn.
Mention it in more general spaces as HN, Reddit, Slashdot etc. and you will be told it is a failure, flop, doesn't have program X so it's useless, etc. etc.
Popularity means nothing
http://www.tiobe.com/content/paperinfo/tpci/index.html
The previous winners of the "Language of the Year" award are shown below.
Year Winner
2008 C
2007 Python
2006 Ruby
2005 Java
2004 PHP
2003 C++I have no argument with this,
"Everyone who uses both extensively berates Linux at every turn."
I seriously doubt this. Please provide any evidence you have.
If the makers of plan 9 were to say "Linux is crap" at least they have the credibility to say so. It is noteworthy that they would never say something so stupid. Linux (and yes Plan 9) aren't the acme of perfection. But neither are the "lisp os" es. Raising ancient lisp systems to some unreachable pedestal of perfection , especially by people who've never seen or used on and have just read about them, is dubious
This is just a blogger with lots of crummy blog posts and no code. At best he is incoherent and at worst deluded.
To repeat my point was not that Linux is the best OS ever. But for me (or anyone else) to go around screaming that everything that is popular is all delusion is pointless (and strictly imo) shouldn't be paid any attention.
"The previous winners of the "Language of the Year" award are shown below.
Year Winner
2008 C
2007 Python
2006 Ruby
2005 Java
2004 PHP
2003 C++"
"Popularity means nothing"
Popularity is not everything but it sure isn't "nothing" either.
Only the power of my own ear at Plan9 conferences from people who know a damn sight more about such things than I. I could pull various mailing list posts out, such as the big argument of Rob Pike with Linus but what's the point.
> If the makers of plan 9 were to say "Linux is crap" at least they have the credibility to say so. It is noteworthy that they would never say something so stupid.
From the Plan9 fortune file : "Linux: written by amateurs for amateurs." - D. Presotto
> And the point is?
That the technical merit of the language doesn't determine it's popularity. So choosing what is the "better language" is rendered pointless.
>Popularity is not everything but it sure isn't "nothing" either.
Yes, I read that back after the edit time ran out and wanted to change it. Popularity and userbase isn't the correct metric for quality.
This is (in a strict sense) true and is not the same as "linux is crap". Linus was certainly an amateur when he wrote the first version of the kernel in the sense that was the first OS kernel he wrote) and many people who contribute are not tenured professors(or whatever your definition of "professional" happens to be). The fact remains that an "amateur" teenager in Finland ran rings around the "professionals".
"That the technical merit of the language doesn't determine it's popularity. So choosing what is the "better language" is rendered pointless."
I agree. But that is the point isn't it? You can't choose "the better language" anyway. The mythical Lisp OS isn't really "better" either unless you've made up your mind up front. So why go on and on for years (the blogger not you)about "everything popular is crap and Lisp is the ultimate leet cool thing forever and forever and anyone who doesn't accept this is an idiot" instead of focussing on actually writing some code?
I don't know which professionals rings around were run, but again, who cares, that's just conjecture, the conjuncture was between a need for a free Unix, BSD sat in court, the GPL, LAMP. The result was the cartesian product that remains today.
In the world of worse is better, Plan9 wasn't bad enough !
ha! Great comment! :-) I wish someone would write a book on Plan9 (like the Lion's Commentary book for Unix).
and the intro to plan9 http://lsub.org/who/nemo/9.intro.pdf
and, tbh, I've read the kernel source code and it isn't that hard to follow - which is one of the goals - there's even an LXR http://fxr.watson.org/fxr/source/?v=PLAN9
The obvious interpretation is that he's saying something like "the usual definition of productivity is flawed and myopic, and gets in the way of realizing the power of Lisp". The paragraph you quoted (implied as a representative sample) is indeed pretty much content-free, because it was a gratuitous flourish at the end.
Of course there is indeed a lot of assertion couched in flowery language there, but that's not the same as "because I say so and if you disagree you're a poopyhead" which is what you seem to have gotten from it. You also seemed to miss the part where he argued that multiple major concepts in modern software originated on the Lisp Machine, which would seem to more than qualify as "building something better".
I'm assuming you're not naive enough to think that "better" equates to "successful", which is another issue entirely.
Just the fact of him sayng something like that doesn't make it true. More logic, supporting arguments and evidence is called for to support such claims. Besides He isn't offering any (lucid) alternative definition. Just rant after rant , over a period of years. Which makes the whole post (and link to it on HN) very content free (imo, feel free to disagree and vote accordingly).
Yes , sure Lisp is cool. There I said it. But hey Linux is cool too. So is C. So are a lot of things.
IQ measurements seem to have a similar problem: doing test a, influences your score on test b, because you get more used to the problems presented.. but doing test a and b just marginally increases your general intelligence, which is what you are trying to measure, while it might have a big influence on someone's score in these tests.
With IQ tests, you can expect that doing test c till z will eventually saturate someone.. but that might only work because you generally do not get the answers. In coding, you do get the answer back (whether your code compiles/works or not), so eventually both programmers will just be limited by the speed with which they type.
There are many ways. Off the top of my head:
- to focus on speed of development you could use a practice or warm-up
> provide each with a practice in another language
> provide a sample solution in pseudocode in both functional and imperative style
- To focus on speed of problem solving you could use topcoder data + research of participants programming language backgrounds.
The important thing is that if the effect is large it's easy to spot. According to some, the difference is an order of magnitude. If that's true, it will be trivial to spot.
The other problem with studying this question formally is that it is so psychologically rooted that people almost invariably "find" that their favorite language turns out the best.
Consider Linux: the poster child of successful free software. It is a knockoff of a 1970s operating system well past its sell-by date.
What does that even mean? Linux (as a kernel) does an excellent job at what it is designed to do. I don't know what is meant by "innovation" here. If the author has a fundamentally different kernel design that is actually better, do tell.
On the other hand, at the subsystem level, there is lots of innovation in the Linux kernel. The Completely Fair Scheduler (CFS) is a good recent example.
This is because a herd simply cannot innovate, whether for fun or for profit. Every innovative work of mankind has been the product of one – sometimes two, rarely three – minds.
Linux development is not driven by a "herd". It's driven by a group of pretty elite programmers known as the subsystem maintainers.
All the major patches are done by one expert, and many of them are fairly innovative. Ingo Molnar did CFS. Ted Ts'o does a lot of really high profile work on filesystems. There are many more examples.
The Linux development process is lightyears ahead of the typical industrial development process. Git, which was created by and for Linux kernel hackers, has been instrumental in helping Linux get ahead.
Distributed version control is a fundamental innovation in software development, and Git is the most successful DVCS by far.
(Other than that, I think the author makes a great point, and I agree with him 100%. That's why I have so far avoided working for big software companies.)
Is this is the same git that Torvalds tossed together as a quick hack to replace the proprietary BitKeeper DVCS after the company stopped offering free licenses to Linux developers?
That's innovation in software development process.
I've used both a lot and Git is faster at some things but BitKeeper gets some things right that Git does not, such as renames, per file comments, digging around in the history.
I think the right answer is that we're all better off because of both. BitKeeper was the original DSCM and paved the way, Git is open source, they are both actively moving forward, hard not to like that.
Also, 'disaster' is a bit...harsh. As I heard, he just telnet'd and asked for "help".
All the major patches are done by one expert, and many of them are fairly innovative. Ingo Molnar did CFS. Ted Ts'o does a lot of really high profile work on filesystems. There are many more examples.
Linux is full of examples of poorly designed systems being slipshod replaced for slightly better designed systems that are well behind the state of the art.
In the same time Linux has gone through multiple schedulers (and scheduler flamewars), FreeBSD developers have designed, implemented, tested, and iterated on ULE, and then ULE2, finally (after much review, testing, and careful consideration) merged it and made ULE2 the default scheduler.
The scheduler wasn't adopted until it was investigated from all angles over years, and found to not introduce any significant performance regressions.
The kicker? The previous scheduler was on par with Linux, ULE2 seems to perform considerably better for many workloads (eg, MySQL) on many-core machines.
Innovation isn't magic -- it involves a lot of hard work and careful design by a lot of people.
The Linux development process is lightyears ahead of the typical industrial development process. Git, which was created by and for Linux kernel hackers, has been instrumental in helping Linux get ahead.
Really? I'm not sure what innovations you're thinking of here.
- Solaris' ZFS vs (incomplete) btrfs
- *BSD's kqueue vs. epoll/inotify/dnotify/
- Solaris' zones vs ?
- FreeBSD vimage (network stack virtualization) vs ?
I think what the commenter meant was the cathedral vs the bazaar model of development. Would'nt FreeBSD, NetBSD, etc all be in the same boat as Linux? Granted that Linux has a benevolent-dictator-aka-linus, but that does not make it deviate too much from the bazaar model.
For all its flaws, git (and github) are becoming the preferred choice of hackers everywhere - I'm not staunchly one of them yet, but I can see the charm. Git only enhances the distributed development model that all *nixes are built upon.
If any, Solaris is the only counter-example to Linux - not FreeBSD.
Most other kernel development teams operate with a considerably more conservative approach ("the cathedral") than is engendered by Linux and specifically enabled by dvcs/git ("the bazaar").
In Eric Raymond's essay, he contrasted the two development models as such (quoting wikipedia):
The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC are presented as examples.
The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process. Raymond also provides anecdotal accounts of his own implementation of this model for the Fetchmail project.
http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
I'd say just about every other kernel available today is developed in "the cathedral", although even then I think that Raymond's comparison (and judgments) are a vast oversimplification.
For all its flaws, git (and github) are becoming the preferred choice of hackers everywhere
Some very vocal people, but not what I'd say "hackers everywhere". As a regularly user of hg and git, I'm not particularly convinced that dvcs provides significantly compelling advantages outside of Linux's development model.
If any, Solaris is the only counter-example to Linux - not FreeBSD.
I'm not sure why you'd say that is.
>I'm not sure why you'd say that is.
That was my attempt at classifying the corporate umbrella of Solaris to be THE cathedral vs the bazaar of Linux ... and, as you say, the middle ground of FreeBSD.
I dont have context here, but it was very surprising to read your comment about FreeBSD being closer to the cathedral model. I was aware of GCC and Emacs being unapologetically so, but I thought BSD had a more open development model - the myriad flavors of BSD being a proof of that.
I'm not defending the Linux kernel in comparison to other FOSS projects, especially really excellent ones like FreeBSD and possibly Solaris. Linux and FreeBSD have different comparative advantages over each other. My point is that both are way ahead of your typical Java shop, and way ahead of Windows, and that FOSS and Linux do not deserve the beating given to them by the author of the blog post.
AFAIK CFS is considered >= ULE2 by most people, and I'm not aware of significant regressions introduced by CFS, so the high degree of conservatism you pointed out in the FreeBSD project wouldn't have been warranted in this case. I don't have the background to argue the finer points of this issue, but it's off topic for this thread, anyway.
Also, you quote me talking about Git, and then say, "I'm not sure what innovations you're thinking of here." I'm thinking about git and the large-scale distributed development model that was pioneered by the Linux community.
I think that's a bit unfair to Java shops. =)
AFAIK CFS is considered >= ULE2 by most people, and I'm not aware of significant regressions introduced by CFS, so the high degree of conservatism you pointed out in the FreeBSD project wouldn't have been warranted in this case. I don't have the background to argue the finer points of this issue, but it's off topic for this thread, anyway.
CFS is based on knowledge gleaned from years of work on earlier schedulers by Con Kolivas and Ingo Molnar. In the meantime, the scheduler was replaced several times in the "stable" tree while they "figured it out". It took just as long, made a bigger mess, and ultimately cost more to produce (not to mention all the flamewars and bad blood engendered in the process).
Whether CFS >= ULE2 is a very nuanced question, but it's fair to say that the schedulers are much closer.
MySQL ought to get more credit, they were in BitKeeper long before Linux was.
I don't really agree with the Lisp-centric discussion because I have worked with many fine programmers who used several different languages. The right person makes a bigger impact than language selection.
As far as productivity goes, building a web portal in rails is far faster than using Lisp, and in my opinion will yield more maintainable code.
That said, I am using Common Lisp a lot right now because I am working on a book about AllegroGraph. (BTW, one good "home" for Lisp is back end services.)
If the problem domain fits lisp, yup, no argument, lisp rocks. I used the Xerox lisp machines and it was really cool in the sense that there was no user land or kernel, it was all one thing. Cool for debugging, cool for performance, very cool when it is a fit.
On the other hand, many problem domains are not a good lisp fit. In fact, most fall into that category, in my not so humble opinion.
As a manager, I look at the technology used to produce a product, I think about development costs (a little) and support costs (a lot). One hot shot lisp hacker that can do whatever is cool, but that's in the "little" category. The "lot" is about support and the hotshots aren't that excited about support, it's boring.
There are other threads all over the intertubes about reading and supporting code and the funny thing is that very few, if any, talk about lisp. All the lisp ones are about "how I can do this cool shit really fast and it makes me feel oh so powerful". Yeah, whatever. I'm happy you are happy. But what I, as a manager, need is the ability to take your cool shit and ship it and debug it and support it for the next decade or two and do all that when you, the studly lisp hacker, have moved on.
Not really liking the prospect of doing that with a big steaming pile of lisp.