Y Store now C++

[Paul Graham <address@hidden>]

--Sundar Narasimhan wrote:
>    >Maybe it would be enough for an advanced language to do things that can be
>    >done in other languages, but do them so much more quickly and provide
>    >such a better solution in the end than would a conventional language that
>    >the clear choice would be the advanced language.
>    >
>    >I have read Paul Graham's essay on how Lisp enabled his company to produce
>    >better online stores faster than anyone else could.  If there were more stories
>    >like this, I think the industry would take notice that, although they could
>    >do the same kinds of things with languages like C++, some other language
>    >could make their programmers so much more productive that it would be insane
>    >to do things "the old way."
> 
> Well, I have no clue about the marketing side of this, but allow me to
> be a bit contrarian here. I remember going to Paul's talk at the Franz
> conf., and he mentioned that yahoo was re-writing some of his Lisp
> code in C/C++? (Paul?). 

I should mention that they actually have just done this.  A 
rewritten version (C++ and Perl) just launched in Jan.  
However,

(a) The reason they rewrote it was entirely that the 
current engineers didn't understand Lisp and were too
afraid to learn it. 

(b) The resulting program is a new world's record case
of Greenspun's Tenth Rule.  The Yahoo Store Editor called
compile at runtime on s-expressions made on the fly.
To translate this into C++ they literally had to write a
Lisp interpreter.

(c) Even then, they had to drop some features (involving
advanced uses of closures).

> ITA, the other alleged Lisp success
> story.. also says much the same thing.. they don't really use Lisp
> except for certain key things, 

Using a language for these "certain key things" is exactly what 
it  means to "really use" it.  

> and the rest of the stuff is wired in C
> to prevent consing effects (I could have this wrong, so someone can
> jump in and correct me). We (at Ascent) use Lisp too, but our db, and
> X access is done thru Forth! Why do you think history is replete with
> people trying to re-write working code (see what happened at Ars
> Digita :) .. and don't give me that "people are stupid" argument
> again!

Kind of hard to answer that question without it...

> 
> The point of this is that.. you can't get "enterprise" managers to
> notice if you say "oh.. this language is great for nxn matrix
> multiplies, but is zilch for everything else". The other noodly things
> like creating tree controls or coolbars or connecting to Oracle in
> your apps ARE important in their eyes, becaues they've spent oodles of
> $$ integrating that piece of code that some "wizard" wrote in the 70's
> to talk to everything else -- and have learnt their lessons as a
> result!
> 
> If you want to gain mind/market share, you have to drive platform
> standards, and you can't drive platform standards if you attempt to
> solve just one or two problems better than anyone else (even 100x
> better does NOT matter!). 
> 
> I therefore would venture that the so-called "advanced" languages are
> not so advanced after all.. if they force you back to "assembler days"
> to solve these other problems that they view as peripheral to their
> mission. And frankly -- I think we have enough new languages as it
> is.. 

And we have enough theorems too, presumably?

> why not just take Common Lisp and *fix* it! 

Do you have any idea how long the future is?  Do you really
think people in 1000 years want to be constrained by hacks
that got put into the foundations of Common Lisp because
a lot of code at Symbolics depended on it in 1988?

> (Assembling the
> original Common Lisp standards drivers and calling it CL2 -- or Lisp++
> would be a great start).
> 
> As to marketing new languages.. you only have two choices these days:
> 1. go open source, and hope other people solve these other problems for
> you (since you, as a language designer may not have time to write
> that db2 driver :)
> 2. keep it secret and convince MSFT or IBM to be your distribution
> channel.. 
> 
> And why is this choice so binary? Why isn't MSFT or IBM "embracing and
> extending" Perl.. or Python? Could it be because such languages are
> not platform threats? Yet?
> 
> How to get noticed? Easy -- threaten an existing business -- write a
> better office suite, or distributed transaction platform, or
> relational database.
> 
> 
> 
>