Premshree's (品速力) Personal Weblog

etc.

I love strong, dynamically typed languages—like Python, and Ruby. (Folks have managed to convince Guido about the advantages of static typing, so much so that optional static typingmay be availablein future versions of Python. Period. The dynamic typing vs. static typing issue has been fucked around at all possible angles; I don’t intend to discuss this much.) This is not to say that I hate all other programming languages. However, there are languages—like PHP—that I loathe. I have good reasons—and quite silly ones as well—none of which I intend to discuss at the moment.

Yahoo uses PHP a lot. Anyway, I realize that a lot of folks at Yahoo, I’m sure, don’t like the language. The Python-Ruby-whore that I am—and now that I’ll be working with Yahoo—I began to wonder if making a case for Python at Yahoo would work. The answer, unfortunately, I think, is NO.

I came across Making the Case for PHP at Yahoo!, presented at PHPCon 2002. I didn’t know about the stuff Yahoo used in its early days—its own proprietary language (which lacked subroutines, by the way), homegrown RPC, etc. (At this time, Yahoo! People Search was written in Python, if I’m correct.) It’s clear that something else was required. That something else did not have to be PHP; it just had to be something else—something much better that what was being used. In essence, this was not really a case for PHP at all—it was a case for choosing another language. It so happens, I presume, that the lobbying (excuse my strong and, rather incorrect, use of the word) group, happened to be PHP enthusiasts.

The language criteria, taken straight from that presentation, were: C/C++ extensions (Python is good at this. Ruby, a lot of people contend, is even better); loops/conditionals; complex data-types; pleasant syntax (heh, I can’t help but remind you that Python is probably what comes closest to pseudocode); runs on FreeBSD; high performance; robust, sand-boxed; interpreted (or dynamically compiled); low training costs; i18n support; clean separation of presentation/content/app semantics; doesn’t require CS degree to use. Twelve of them. What programming language fits the bill? Pretty much any programming language, no? Come to think of it, what were the options available anyway? PHP, probably, was a good move.

Okay, so now we’ve graduated from a subroutine-less language to PHP. Now do we have a strong enough case to switch to Python?

I really don’t think so. Yes, Python will serve all the purposes (and more, if need be) that PHP currently serves. Reason enough? No. One important issue I have not considered here is that of performance. This whole business of choosing a language probably boils down to this, I guess. Well, a perfunctory look at comparing the benchmarksof Pythonand PHP reveals that Python generally has a better rank than PHP. (The originalGreat Computer Language Shootout page seems down.) However, the difference isn’t good enough to warrant adoption. The standard disclaimer accompanying benchmarks—that they are debatable—goes without saying. (Well, even though I said it, actually.)

Please note that I have discussed this at a highly abstracted level. We could go into the details, but I’m really in no mood to do that—I don’t see it serving any conceivable purpose. Now I wonder if there was any point in discussing all this in the first place.

If you think you have valid, pragmatic reasons to believe that Yahoo should migrate all its stuff to Python, I would really like to know.

Ok explain one thing to me, out of the zillions of sites out there, how many use PHP and how many use Python? After you know the ratio, please explain to me why the ratio is so. You have then answered your own question as well.

When you know that people get into Yahoo only because they're "good", I find it ridiculous that they took a decision to use PHP simply because of the job market share. There must be _some_ technical reasons :|

I've been working at a larger company for a few months now - larger than what I'm used to, at least. There might be the tendency to move toward integration, but every department seems to move at a different pace. And often towards a different idea of what "unity" might mean.

Department A is already migrating to solution C from solution B, which was the new unified platform a couple of years ago, while for some strange reason Department R have been using a mutant variation of solution A for six years, and have chosen to completely skip straight to solution D, which somebody mentioned in a meeting last month. Naturally, Department Q had some serious problems with the migration to Solution B, and chose to completely ignore the company-wide "unified solution". They've started working on Solution ω. I hear that Ed has already finished a draft of something he calls Solution ω, though. It looks like Department Q's Solution ω, but it is completely incompatible with any of the solutions mentioned so far.