If Scheme is so good why MIT drops it?

[ACL]

On Jul 24, 2:06 pm, Raffael Cavallaro
<raffaelcavall... at pas.espam.s.il.vous.plait.mac.com> wrote:
> On 2009-07-23 23:51:02 -0400, Carl Banks <pavlovevide... at gmail.com> said:
>
> > On Jul 23, 5:52 pm, Rui Maciel <rui.mac... at gmail.com> wrote:
> >> fft1976 wrote:
> >>> How do you explain that something as inferior as Python beat Lisp in
> >>> the market place despite starting 40 years later.
>
> >> Probably due to similar reasons that lead php to become remotely relevant
> > .
>
> > Well, the only reason PHP became relevant because it was an
> > easy
>
> ^^^^^^^^
> ^^^^^^^^ (emphasis added)
>
> > to
> > deploy solution in a single application domain, the web, that happened
> > to explode.
>
> i.e., Python "beat" lisp because it is ~70% of lisp in a form that is
> much more palatable to the average programmer, just as php became
> popular because it is powerful enough to do websites and, most
> importantly, apprehensible to mediocre programmers and even some
> non-programmers.
>
> --
> Raffael Cavallaro

I actually think that the thing holding lisp back is 'bus factor'.

Lets assume I have a java project and a lisp project:

Java project:
I have maybe 10 or 12 people on my team working on various subsystems
of my project. There are probably one or two 'technical leader' types
in the group, and a bunch of others who are sort of 'serfs', banging
out java classes. Lets say one of my important guys gets totally
splattered by a bus... I've still got another one left! I can rely on
the other guy to keep things afloat while I train up a new leader
type.

Lisp project:
I don't need as many people. I have 3 or 4 people, and one person is
my technical leader and lisp guru. Guru is probably in charge of more
difficult macros and (because of that), also in charge of the overall
design (macros are design patterns embodied in code). Lets say he gets
totally annihilated by the bus. What do I do now? I had all my eggs in
one basket and my project is now stalled.

I think that (for example) when people are saying that lisp macros
make projects difficult to understand, or that lisp hackers are much
harder to find than other programmers, what they are really showing is
that because of the nature of the language, lisp projects get
organized in a different way. This different way of organization is
especially hard on corporate projects, because managers are expected
to plan for when some important guy drops dead.

The problem with lisp is that if you hire too many extra hackers, you
end up with a bunch of people sitting around twiddling their thumbs.

This may also explain why it gets touted as an academic language. In
academia if a professor who is leading some important research drops
dead, who cares? Most likely no one had interest as to whether the
university would make a profit on this particular research endeavor
(except maybe the deceased, as he would like to get grant funding).

So I guess then we can give some tips for making lisp more acceptable
for 'paying gigs'.
1.) If you are a lisp hacker, it is your duty to be lazier and write
less code. We need to make it so that these projects need sizable
teams of people to complete.

2.) Write down everything that you do, everything you are going to do.
Maybe draw some object diagrams of your important/fancy macros, make
sure these are stored with the source. (You'll note that an iterative
approach to programming isn't really conducive to making a lot of
diagrams of stuff...)

I don't know what this has to do with python or scheme or people
dumping scheme for python.
Honestly, I seriously doubt that any undergraduate programming course
will give you enough actual programming experience to make you
seriously proficient in the language (research projects not counted).
The language used to teach the material is a cursory detail.