
Where Lisp Fails: at Turning People into Fungible Cogs - fogus
http://www.loper-os.org/?p=69
======
trapper
Surely if lisp makes a programmer N times more efficient then it would be easy
to study scientifically. Have there been any studies comparing productivity?

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.

~~~
randallsquared
_libraries should be n times faster to make or duplicate_

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.

~~~
xpaulbettsx
I agree - I really think that when it comes down to it, Lisp isn't popular
because it's _harder to read_. Even if it's more terse and far more elegant,
the mental tax of trying to understand another person's code is far higher
than C, where there's only "the dumb way" to do something.

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_ )

~~~
nocman
As a person who started learning Lisp after years and years of using mostly
mainstream languages, I have to at least partially disagree. I will say this,
however: Lisp is, at first, difficult to read for many people. But I think it
is mainly difficult to read for people who are used to reading programs
written in languages with Algol-like syntax (C, C++, Java, Perl, etc). If
you've been writing programs for 5, 10, or 15 or more years mostly in
languages that all have that common ancestry, it is understandable that your
brain will (at first) work against you when reading something like Lisp.
However, after using it for a reasonable period of time, I found that it
became much easier to read. And now I don't find it any more difficult to read
than any of the mainstream languages that I have used in the past.

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.

~~~
joe_the_user
I program in C++/etc but also in SQL. SQL is terse logical language. Everyone
may has SQL but I think given constraints of being a logical language SQL is
far more readable than lisp - but I've only read bits of lisp online.

~~~
jules
I find CSS to be far more readable than SQL.

~~~
silentbicycle
I'm not clear what point you're making. CSS isn't a logical language, and they
don't really have enough in common to compare them. (And FWIW, I find SQL
clearer than Nahuatl.)

~~~
jules
> CSS isn't a logical language, and they don't really have enough in common to
> compare them.

s/CSS/Lisp/

------
javert
I think the comments here about the free software community, and particularly
the Linux example, are _really_ off base.

 _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.)

~~~
tolenka
The success of Linux deserves serious consideration, but breathless marvel at
Linux and its development practices is entirely misplaced.

 _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 ?
    

This isn't intended to be a Linux-tirade -- but I wanted to illustrate that
Linux is _not_ "lightyears ahead of the typical industrial development
process" when compared against other existing kernel projects.

~~~
javert
I agree with what sandGorgon said.

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.

~~~
tolenka
_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._

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.

------
mark_l_watson
I enjoyed reading the article but don't really agree with quite a bit of it. I
do agree that single individuals or very small teams most often make great
breakthroughs, and that languages like Java do yield more "fungibilty."

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.)

------
plinkplonk
I am surprised this piece of trashy fanboi writing is so high on the HN front
page. The whole site is full of "lisp is the coolest. Everything else sucks"
type borderline trollish posts, endlessly recycling the "lisp is better than
everything else" meme. As usual, the HN discussion is better than the crummy
article, which may be the desired end result aftr all.

------
luckydude
As a hiring manager, who has managed and fired lisp people, I sort of see both
sides of this.

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.

------
lunchbox
Lisp is the Ron Paul of programming languages.

