[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Performance
- From: David Jeske <jeske@...>
- Date: Tue, 6 Nov 2001 14:12:27 -0800
On Tue, Nov 06, 2001 at 11:43:13AM -0800, Eric Tetz wrote:
> --- brucedickey <brucedickey@micron.com> wrote:
> > Lisp is great at this kind of problem...
> > (the dynamic business rules problem, I mean :) ).
>
> Yeah... I love the article about the three-man team who wrote an
> e-commerce site builder in LISP, then sold to Yahoo for $49 millions
> dollars. When Yahoo was courting them, they actually hired several
> dozen programmers because they thought no one would believe the
> product was built by three guys. They called LISP their "secret
> weapon".
Don't believe everything you read. I know the people have been working
on that code for the last few years and have finally replaced it.
The lisp was impossible to change because weak typed system are so
fragile -- and too much of the information required to work on the
code was only in Paul's head. (what is in that list anyhow?) It was a
maintaniance nightmare. Languages like LISP, Perl, Python, and Lua are
great for prototyping, but it's really hard to maintain and
significantly improve software written in any of them as the internal
software interactions get alot more complex.
A similar story might be told about eGroups.com. We originally wrote
the entire site in Python. However, it started to become a
maintaniance nightmare long before being sold to Yahoo. As a result,
we had to clean up our own mess first and rewrite lots of it in C.
Paul Graham got off lucky not having to live in his own shit. I'm just
surprised he wrote that gloating article misrepresenting the facts.
> Very fascinating and entertaining article (love the "Blub Paradox"):
>
> http://www.paulgraham.com/lib/paulgraham/sec.txt
There is no "secret weapon". Every language has tradeoffs. Languages
like LISP are great when you have 1-2 programmers and can constrain
the scope of changes. Great for prototyping. Keeping up that pace
without making the system flakey is much harder though.
It's really just a question of when you pay. Paul was fond of "someone
else pays later". I'm pretty fond of "pay as I go". Prototype in
Python, and incrementally rewrite lower level code in C as needs
stabilize. This yeilds a performance win and typesafety at the same
time.
YMMV
--
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net