Yahoo Store now C++ (comments by pg from 2003)

Emailer: "ITA [Software Inc.], the other alleged Lisp success story.. also says much the same thing.. they don't really use Lisp except for certain key things"<p>PG: "Using a language for these "certain key things" is exactly what it means to "really use" it."<p>I thought this was a terrific observation about language wars. You can build a website in Ruby or PHP or Python etc., without <i>really using</i> the language. If your code ports nearly line for line from say, A to B, you're probably not taking advantage of the benefits of the language(s). You are using the language, but not <i>really</i> using it.<p>A more concrete example:<p>You can build a website in PHP that also has a chat room written in node.js.<p>In this case you are <i>really</i> using both languages.<p>Alternatively, you can build a website in node.js that also has a chat room written in PHP.<p>In that case you are <i>using</i> both languages, but not <i>really using</i> either.

This is basically a manifestation of the "LISP Curse" - high level functional languages are sufficiently powerful that small teams of really smart people (like us) can crank out amazing applications with relatively low effort.<p>However, to maintain and improve these applications, you need to maintain and grow a pool of really smart people, which is something of a challenge for large companies. We tend to be like cats - very fascinated for short periods of time but unwilling to listen to non-technical direction issued by a bunch of MBA's.<p>It's far easier - for a non-technical person - to assemble a horde of average developers using a pre-packaged toolkit (Java, Microsoft, SAP, or enterprise software packages) and boss them through some form of digitized process map. Let them hire a bunch of their B-school buddies at ACN or Mckinsey to "faciliate" the deployment, for $300 - $500 per hour, and it's a lock.<p>Big companies don't care about technical excellence - they care about ensuring the company, not the developer, controls the code. The truth of the matter - developers are not created equal and you will get a lot farther in a small group if you let your best person carry the ball.<p>Unfortunately we're comparing archers and crossbowmen - the archer took YEARS to train but delivered (for his time) an awesome rate of fire with good accuracy. The Crossbow allowed you to herd together large groups of average peasants and overcome the archer by sheer weight of numbers.

Pure Paul Graham: "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?"<p>In my CS degree we never learned about how language will evolve. We learned how they work, how to write new ones, how to translate between them, but never how to future-proof them.<p>But right now it looks like C will remain the language of the future :)

Sounds like the guys who recently switched from Erlang to Python [1].<p>"Too afraid to learn Erlang" exactly.<p>[1] <a href="http://code.mixpanel.com/2011/08/05/how-and-why-we-switched-from-erlang-to-python/" rel="nofollow">http://code.mixpanel.com/2011/08/05/how-and-why-we-switched-...</a>

I love programming languages and I never miss an opportunity to learn a new one, but I think that anyone who thinks that a programming language can make or break a company doesn't have much clue on how the industry works.<p>I have a lot of respect for pg but the successful sell out of his company had a lot more to do with "the right product at the right time" than it had to do with Lisp.<p>I'm also very disappointed with this kind of condescending claims:<p>"The reason they rewrote it was entirely that the current engineers didn't understand Lisp and were too afraid to learn it. "<p>Or maybe, just maybe, they know a little bit more about the pros and cons of using a mainstream language to ship a product in terms of staffing and tooling and they decided that Lisp just didn't clear that bar.

ironically, Yahoo Mail is now rewriting chunks of their C++ backend in Java, because thats what new grads are taught these days instead of C++.<p>Back in 2003 pretty much all of ymail was in C++ with this crazy templating language that generated C++ code. Now it's all PHP and Javascript on the frontend. I assume that's true for other properties as well but i don't know first-hand.

A few days ago I read this article:<p><a href="http://martinfowler.com/articles/lmax.html" rel="nofollow">http://martinfowler.com/articles/lmax.html</a><p>"10: An interesting side-note. While the LMAX team shares much of the current interest in functional programming, they believe that the OO approach provides a better approach for this kind of problem. They've noticed that as they work to write faster code, they move away from a functional style towards OO style. Partly this because of the copying of data that functional styles require to maintain immutability. But it's also because objects provide a better model of a complex domain with a richer choice of data structures"<p>The world of software is so large and varied that I no longer can just believe the word of experts can be applied to other domains that they probably are not expert or have experience in before. PG with his LISP/Scheme world. Joel Spolsky with his Microsoft background. Martin Fowler with his OOP, Modeling ecosystem. Joshua Bloch with software correctness. Linus Torvalds with his embedded/OS island.<p>Are the things they wrote and spoke, within their domain, correct/make-sense? Perhaps.<p>Can we apply their opinions to other domains? Probably not.<p>I also feel that it's weird when a person always say "use the right tools for the job" but always push for his/her favourite programming language as if the language is always the best tools for anything that pops up in HackerNews. It feels like someone trying to put a square peg in a round hole.<p>Then there's the "let's burn the Agile Consultants" movement around here while promoting alpha-geeks that always change their programming language or web framework or their app-server of choice once every 2 years.<p>Some people don't care with the next programming language probably because they're busy learning Data Mining (Math &#38; Stats), SOA, REST, HTTP protocols, SEO, CSS/HTML, administering Linux server, designing a database model, automating their testing effort, writing i18n-compatible apps, building robust code (in the programming language of their choice). Pretty much getting better in the situations that don't necessarily involve learning a new programming language.<p>Maybe programmers prefer to learn new programming languages as opposed to other things because learning a programming language is easier as opposed to learning Data Mining. Most programming languages are similar in a way they have a subset of common features: functions, type systems, object/classes in some, pointers/reference, iteration/loop, array. It's probably because we're human: we prefer things to be instant.<p>I don't think Ruby is more productive than Java in almost all situations. I'll give Rails the credit for being more productive for a simple CRUD apps if you compare it to most Java frameworks (the newer ones like Play, Spring MVC, Spring Roo, and a slew others are on par).<p>Maybe we shouldn't judge people based on their knowledge of more programming languages.

"Too afraid to learn Lisp"<p>This is sad. Very very sad.

I think the language debate comes down to two classes of people: (1) people who care passionately about languages and code aesthetics, and (2) people who don't really care. Unfortunately, the second class of people are more unified and comprise at least a plurality, so they win.<p>The problem with the first camp is that we all want to use different languages-- Haskell, ML, Clojure, Scala. And these are all good languages! But companies can't afford to have more languages than there are people, not as the latter number grows and as being able to read code becomes more important than being able to write it. So every company needs to limit its white list. Those of us who are passionate about good languages nonetheless disagree on which of those good language to use. And we do ourselves a disservice when we bash Python because it sucks compared to Haskell; the result of this disagreement is we end up having to use C++ or Java.<p>The perversion here is that the reason so many companies coerce their codebases to C++ (i.e. limiting the whitelist) is that they recognize the importance of reading code. Yet they choose languages (C++, Java) where reading average (not bad code, mind you, but 50th-percentile code in a production system) code is extremely difficult. A good C++ programmer can write eventually comprehensible, but not beautiful code; a bad or average one can easily make an illegible and unmaintainable mess. For contrast, a good ML programmer can write beautiful, easy-to-read code while bad ML programmers are practically non-existent because they can't get their code to compile. For bad programmers, ML is that evil little language that caused them to nearly flunk that PL course they had to take in college.<p>What I wonder is how Yahoo managed to get people of sufficient talent to do the project. It seems like one of those hard-but-shitty projects that never succeeds because the people who are competent enough to do it have better options. Do-the-same-thing rewrites are never popular projects, and most people who understand Lisp are not going to be happy about taking on such a project for the sake of C++.<p>(No, I'm not saying that there aren't good programmers who use C++. There are great programmers who use C++. That said, someone who understands functional programming well enough to read Lisp is not likely to be among them; people who understand FP want to use it.)