Yahoo Store now C++ (comments by pg from 2003)
people.csail.mit.edu
people.csail.mit.edu
PG: "Using a language for these "certain key things" is exactly what it means to "really use" it."
I thought this was a terrific observation about language wars. You can build a website in Ruby or PHP or Python etc., without really using 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 really using it.
A more concrete example:
You can build a website in PHP that also has a chat room written in node.js.
In this case you are really using both languages.
Alternatively, you can build a website in node.js that also has a chat room written in PHP.
In that case you are using both languages, but not really using either.
(1) If people who wrote their website in Lisp (Viaweb, ITA, Reddit) continue using Lisp, then they are smart and Lisp is powerful.
(2) If those people (or new people) rewrite the website in a different language (C++, Python), then either (a) the new people are dumb (Lisp is too powerful for them!) or (b) the website was not really using features not in the new language (the powerful Lisp features were not used!).
EDIT: As noted by pnathan below, maybe it is more of a No True Scotsman.
What does it mean to really use a programming language? I take it to mean that your task aligns with the strengths of the language. I can use the butt of a screwdriver to drive in a nail, but hammers certainly are better at the task. Programming languages are similar, but defining the strengths of the languages and the needs of your task are monstrously more complex.
One strength, and weakness, of Lisp is its malleability. The language itself can be turned into almost anything you want or need. If your purpose is to demonstrate possibility, few tools are better. At this point you can really use Lisp, because at this point you are free to exercise the strengths that only Lisp has.
Once that possibility is known, though, this strength becomes a form of weakness. The project should now move with purpose, methodically exploring the problem space. You draw attention, hopefully money, and with it more team members. What was a single vision wrought in code now must be the coordinated effort of a large group. You can no longer really use Lisp because the group is too large and sharing the knowledge of a newly built language feature takes more time than the feature saves. So, you stop really using Lisp and just use it, carefully selecting the subset of tools that allow people to work together.
Or, you rewrite, in some language whose strengths are more in line with the needs of your now larger project. Then you are really using that language. I don't see tautology or contradiction here, only shifting requirements that we fail to acknowledge.
Let's say you are sitting at your desk and your boss asks you to code a solution to a problem, let's call it Problem Zebra.
If you flip open your laptop, roll a die labeled with 6 programming languages that you know, and then write code in whatever language you roll, that solves Problem Zebra, that is "using a language".
If you flip open your laptop, and before you start typing you think, "I need to solve Problem Zebra, which is a type of Mammal Problem, and Language Y is often used to solve Mammal Problems because the designers of Y added constructs A and B specifically to help solve Mammal Problems (because that's the genre of problems they focus on at work)," and then you write code in Language Y and use A and B, that is "really using a language".
"The US didn't really use atomic bombs during World War II -- except for those 2 key occasions".
pg is pointing out that using x in key places is really using it. This is a far cry from claiming that whenever x is used it is really being used.
s/really using/exploiting the unique advantages offered by/
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.
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.
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.
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.
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.
But right now it looks like C will remain the language of the future :)
I wouldn't use Lisp in my assembly-line, CRUD factory, but it will serve an artisan quite well.
Lisp certainly includes certain 'timeless' aspects, such as lambdas and homoiconicity, but other features (like conses everywhere, IMO) are simply implementation details of the time Lisp was first created.
I'm concerned that Lisp advocates, by repeatedly saying that Lisp is the final step in language design, the ultimate language,...etc might distract some from looking for additional, newer, insightful concepts in computation and language design.
No programming language will survive a 1000 years. Not many works of science or art, or even human language have.
Programming language research has already grown past Lisp itself, or any other programming language, really. What we have now are logical models, their derivations and their proofs. If any of them can be materialized in an implementation, made practical, or even commercialized, great. Otherwise PL research is happiest as .. logic.
Edit:
اخ محمد، عجبتني رؤية لغتك البرمجية العربية. قمت ايضا بأنشاء بضعة لغات برمجبيات عربيات، معظمهن كلغات شبه لسبية :-)
يسعدني أنها أعجبتك! هلا أريتني لغاتك التي اخترعتها؟ بريدي موجود في البروفايل لو أردت ذلك :)
يسعدني التواصل معك عزيزي. معظم ابحاثي اللغوية مبعثرة في عدة مواقع، واجهزة استودعت في اﻻهمال. ثمة دفاتر هنا وهناك. ساجلب بعضها من المخزون قريبا
حتى ذلك الحين، اتركك في مرحاب البحث والالهام
Another example is from Vinge's novel A DEEPNESS IN THE SKY. He describes a software system thousands of years in the future that still uses the time_t epoch. None of the system's space-faring users know the significance of the date 01970, though a few believe it is the date when computers were invented. :)
20 years after the "discovery" ;) of UNIX, Linus began developing a Linux from scratch. Linux is now 20 years old. Is some college student writing a new operating system that will cut the cruft from Linux? Even Linux is far from a clean slate design because it embraces (and extends) POSIX APIs and UNIX conventions. Will we still be using Linux (or Linux derivative) in 2050? 2010?
[1] Vernor Vinge: “What If the Singularity Does NOT Happen?”
http://longnow.org/seminars/02007/feb/15/what-if-the-singula...
And some thought we measured time from the date of the first moon landing.
More relevantly in the book is the class of people known as programmer-archaeologists who specialise in digging through libraries of software looking for code that already does what they need.
On a time scale of thousands of years, that guess is more than close enough.
"Too afraid to learn Erlang" exactly.
[1] http://code.mixpanel.com/2011/08/05/how-and-why-we-switched-...
X developers x Y time to "really learn Erlang" = Z > 2 weeks
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.
I'm also very disappointed with this kind of condescending claims:
"The reason they rewrote it was entirely that the current engineers didn't understand Lisp and were too afraid to learn it. "
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.
"We chose Lisp. For one thing, it was obvious that rapid development would be important in this market. We were all starting from scratch, so a company that could get new features done before its competitors would have a big advantage. We knew Lisp was a really good language for writing software quickly. [..] And because Lisp was so high-level, we wouldn't need a big development team, so our costs would be lower. [..] with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release." - http://paulgraham.com/avg.html
It was the advantages of using Lisp which gave them the ability to create the right product at the right time, instead of the right product too late, or dreams of the right product, too expensive to hire the team to build it.
The claim isn't really that Haskell might be a success and F# a failure, but only that if you can take advantages of more powerful languages power, you gain some advantages over companies which use less powerful languages - but not a guaranteed make or break difference, just another bit of help.
Given that he's gone from successful founder to successful investor mentoring several thriving startups, your claim that he can't "have much clue how the industry works" feels hollow.
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.
Or maybe, just maybe, the guy who wrote it and was there when it was rewritten knows more accurately what happened than you do. It isn't condescending if it's true.
Obviously, because they used Lisp, they were able to produce the product at time t, and any other language would have produced it at a different time t'.
I claim that they had no idea that t was better than t'. Nobody can.
It was a fluke, like many success stories.
Or maybe, just maybe, they didn't understand the pros and cons of rewriting a mature codebase from scratch.
Or perhaps they couldn't make the lisp code into an indecipherable mess that made them look intelligent for having written it like they could with C++.
Or perhaps they believed that too many parens would make the curly brace Gods smite them.
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.
http://martinfowler.com/articles/lmax.html
"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"
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.
Are the things they wrote and spoke, within their domain, correct/make-sense? Perhaps.
Can we apply their opinions to other domains? Probably not.
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.
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.
Some people don't care with the next programming language probably because they're busy learning Data Mining (Math & 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.
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.
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).
Maybe we shouldn't judge people based on their knowledge of more programming languages.
This is sad. Very very sad.
Another interpretation is that this is like the “comb-over” syndrome. How does a middle-aged man end up with a comb-over, given that everybody knows it’s a lame look? The answer is that it creeps up on him day by day, there is no one moment in time when he asks himself, “Should I comb my hair over?”
Likewise, whenever you see a Greenspunned[1] system, there is rarely a moment in time when some bright and ambitious person decided that the right thing to do was to sit down and implement half of Common Lisp. Instead, they make a series of small daily decisions (add this, change that, add such-and-such a feature, whoops, to fix that bug we need to do this...) that end up accreting into an interpreter for Lisp.
I don’t know the whole story, perhaps they did decide to write such an interpreter right from the start. But it could be that they initially decided to write something very small and specific, but wound up with a comb-over.
[1]: https://secure.wikimedia.org/wikipedia/en/wiki/Greenspun%27s...
I have to ask though: Is Greenspunning such a bad thing?
It seems like this would be true of any non-trivial software system (successful or not).
What's the variant of the 10th rule - something like:
'Every complex system contains an ad-hoc informally specified implementation of Common Lisp. Including Common Lisp'
Yes, because if you knew you needed Common Lisp, you'd just use CL, rather than an ad-hoc informally specified implementation of CL. In general, the half implementation has half the value of the 'real' implementation.
http://help.yahoo.com/l/us/yahoo/smallbusiness/store/edit/ad...
Why would Yahoo want to keep this one property written in Lisp around while the proficiencies within the company (and the general talent pool outside the company) did not include Lisp?
It has nothing to do with being "afraid" of Lisp, it simply didn't make sense to have one random Lisp property. I am pretty certain if Google made this acquisition, the site would be rewritten too.
edit: typo
In case you did not mean "Common Lisp" by "Lisp", try to be more specific next time. The "Lisp" term does not include Scheme, and is not really that much used when talking about Clojure.
What do you mean by "everything-is-a-symbol", anyway?
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.
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.
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++.
(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.)
Though reading code isn't just it, language interop everyone knows how to use is important too. While all the fancy JVM languages have Java interop, it's still a huge pain for every old Java developer who wants to call your Clojure library. They'll end up learning how to do it separately for every language, every time, multiplied by the number of developers who aren't fluent in these languages (most).