Bambi Meets Godzilla
- published to O'Reilly Ruby Blog on Dec 29, 2005
- voluntarily taken down on Dec 30, 2005
- edited and re-published here on Jan 01, 2006
Steve Yegge
Gregory wrote:
> Steve, I'm just suggesting not putting fuel on a fire most Rubyists
> never intended to start in the first place.
>
> There is no need for a crusade or jihad here, on either side of the fence.
>
> This post just seems to be painfully biased with the expressed intent
> of bashing Python. That's just not cool.
>
> Pythonistas are not all tax collectors.
Yes, yes, I know how my "anti-anti-hype" post must have felt. Given that I'm like 600 dog-years old, I sometimes forget the context is missing when I post. I'm going to try once more to explain where I was coming from in that post. If this attempt fails, it's really no big deal -- I can certainly stick to technical blogs.
Incidentally, I'm going to talk about several languages, and eventually make my way back to Ruby at the end. Hang in there.
I think there are some issues we don't often talk about that have a direct impact on our lives as programmers. Like politics, they're tricky to talk about without arousing great, fiery passions. I'll be talking about some of them today. Why would I do that?
Well, first of all, let's get my agenda out in the open. I'm a programmer, and like you, I love building things. And ideally I'd like to build things in my favorite programming language, which happens to be Ruby -- but only by a slim margin, because I love several other languages too, including Python, Scheme, Lisp, the "D" language, C (but not C++), and various others. I like many languages a little bit, and there are only a few languages that I don't like very much.
As it happens, Python is my second-favorite language (well, tied for 2nd with Scheme).
Yup, that's right. You heard me properly. I love Python and I think Guido is brilliant. Matz, too. Those guys are just amazing.
My agenda is really simple: I would like to write the majority of my code, at home and at work, in a great programming language.
Well, it's simple to state. It's not simple to *do*, for some complex and rather painful reasons that should be non-issues, but they're not. Let's look at them a little, and hopefully it will shed a little light on my "uncool" post.
I watched Smalltalk die.
I wasn't particularly invested in Smalltalk at the time, but I had done some programming in it. Smalltalk was (and still is) a superb programming language. And it died after I learned it.
There are some Smalltalk enthusiasts out there who will point to Squeak and other Smalltalk enclaves, and claim it's not dead. This is an important point. Chances are, you don't take Smalltalk very seriously. It's not on your radar. You don't think you'll ever need to learn it. So when I say "I watched Smalltalk die", to you it sounds like I'm talking about ancient history.
To many people, though, especially the ones who loved Smalltalk and whose very livelihoods depended on its commercial success, the failure of Smalltalk is a very painful subject. It's not boring ancient history. It still hurts them, deeply, and they even maintain hope that it may someday experience a glorious return to popularity.
This pain they feel, which you probably do not, is really close to the heart of our discussion. Hurt feelings are why these issues are so hard to talk about. It's very easy for you to say something insensitive about Smalltalk, *especially* if you don't know the language. You can take one look at it and say: "looks dumb", and you've just made someone mad.
In fact discussing it is extra hard because some people are just mad about Smalltalk in general. You can say anything at all about it, and simply bringing the subject up will have made them angry.
Regardless of whether Smalltalk is really dead, or merely a wounded bear in deep hibernation, I think it's clear that Smalltalk is not having a direct impact on the programming world today.
Smalltalk has plenty of indirect impact, of course -- for instance, Ruby inherits a great deal from Smalltalk; all OO languages do to some extent, but Ruby more than many. But you can't walk into an ordinary computer bookseller and expect to find more than a couple of Smalltalk books. And if you want to get a job as a Smalltalk programmer, you will probably have to travel far, and you likely won't have much say in the kind of work you get to do. Smalltalk has retreated into a relatively small set of domains, at least for now.
What killed Smalltalk, anyway? I've read analyses and talked at length with some of the key players. The consensus seems to be that Java killed Smalltalk. And it did so rather decisively. Have you ever watched the short animated film "Bambi Meets Godzilla"? That's pretty much what it feels like now, although it actually happened over a period of several years.
Smalltalk wasn't terribly different from Java, really. It had an unusual all-in-one image model, where it acted like your OS, hosting the language, IDE, and application environment all in one binary. That is widely considered unpopular in retrospect, but the irony is that it's not really much different from the JVM. Smalltalk was commercial, and required user licenses; Java was commercial, but gave end-user licenses away for free. But they were really pretty similar, and yet one wound up being far and away more popular than the other.
You can argue that Smalltalk would have failed fair and square, without Java, but I think most people agree that Java was a key contributor to Smalltalk's failure. And it wasn't a quiet thing, either. Millions of dollars were at stake. There were two large commercial Smalltalk vendors, and a bunch of unhappy about-to-be-ex-Smalltalk programmers, and hallways echoed with roars of protest at how Java, an "obviously" inferior language, had unfairly stolen a market that rightfully belonged to Smalltalk.
It all quieted down eventually, and to most of you, Smalltalk probably feels like a niche academic language that never had any real popularity.
I think Java coming along and smooshing Smalltalk was largely due to marketing. It's not the only factor, of course. Timing was a factor in various ways. Syntax and static typing were both factors, because Java deliberately went after disenchanted C++ programmers, which wasn't a bad strategy at all. And Java had some genuine innovations that helped, too.
But it was marketing that tied all those things together and helped Sun build a worldwide community of millions of Java programmers.
Java wasn't really offering anything that Smalltalk hadn't already been doing for years. (Where have we heard that argument before?)
It seems to me that there are two major contributors to language flamewars.
The first is that most programmers don't like to learn new languages. I don't know why, but true polyglots like me seem to be comparatively rare, maybe 5%-10% of the programmer population. Most folks apparently prefer to master one language and stick with it for life.
The second is economics. Money motivates most decisions in the end. Companies need to make money, programmers need to get paid. You know all the old sayings: time is money, business is war, money (or love) makes the world go 'round, all's fair in love and war.
Programmers fall in love with their languages, so you've got two of the biggest forces in the world at play here: love and money, mixed with either fear or laziness. Is it any wonder people fight over languages?
Well... sort of. It seems like people should be able to use whatever language makes them most happy. But in practice, you can only use your favorite language if it happens to be C++, Java, Perl, or whatever language(s) your employer has decided are the "official" languages.
Most technical employers have a relatively small set of official languages, and you're forbidden from using any others. There are a few odd things about this situation.
One is that most companies couldn't care less about programming languages -- all they want is to get their products built. It's always the engineers who impose the language restrictions. They're not restricting themselves, of course; it's a situation where engineers are governing other engineers by decree, within the same company. I've heard all the reasoning, and it still seems a little odd to me.
Another other odd thing is that most companies are using anywhere from 15 to 40 programming languages, but they only officially recognize two or three of them. They'll claim they're a Java/C++ shop, but have huge gobs of shell-script, awk, PHP, Perl, JavaScript, Tcl, emacs-lisp, vim-script, excel macros, pl*sql, and other languages threaded through their tools, databases, build systems, and so on. Maybe this is less true at Windows-based development shops.
And one last odd thing is that programmers often have to learn at least one new language when they arrive at a new job, but they never have any trouble. Programmers usually think learning a new language will be hard. When it's a job requirement, though, it happens amazingly fast. Programmers are generally pretty smart people.
You'd be amazed at how much resistance the "old guard" of a company will offer if you try to use your favorite language, and it's not on the approved-list. The "old guard" could even be 23-year-old CS grads that have just made a successful startup. "Old" here just means "first".
I've heard their arguments for 20 years. Don't use C++, it's slow (my first company). Don't use Java, it's slow (my second and third.) Don't use Python, it's slow and has that whitespace thing. (All but my most recent.) Don't use Ruby, it's weird (90% of all companies). Language diversity is bad. What if someone has to debug your code in the middle of the night and they don't know that language? (every company, even those that don't work in the middle of the night) Don't use other languages; we don't hire for those skills. We don't trust those languages. We've invested in Fortran or Cobol or C++ or Java or whatever. No, no, no.
"No" always comes from engineers. You build something cool and popular, and your CEO will love you for it. She won't care if it's written in Intercal, as long as it works and your team can keep it working. So why do the engineers care so much? Who knows. I think it's often ego -- they think of themselves as a great Java programmer, or an important Perl luminary, or a famous Python person, and they let their perceived self-image influence other peoples' technical decisions. Whatever the reason, it's a very real force in the workplace, one that plays a large role in the language wars we see on the internet.
Because, hey, if enough companies are *already* using your favorite language, then the problem still exists -- but not for you!
I programmed in assembly language for 5 years at Geoworks; maybe that's why I love all languages a little. Then C/C++ for a while, and then a long 7-year stint with Java.
After 2 or 3 years with Java, I stumbled on Jython, a pretty nifty port of Python to the JVM. I'd been doing my scripting and auxiliary work in Perl. This was before it had ever occurred to me, still being pretty new, that one language could actually be suitable for most programming tasks. Java's not very good at many things Perl is good at, and vice-versa, so I had a big mixture of Java and Perl.
I talked in my anti-anti-hype rant a little about Perl's marketing. It was world-class, and for a while I even thought I liked Perl. The marketing was so powerful that I simply took it for granted that I liked Perl.
Jython was a breath of fresh air, and I started wishing I could replace all my Java *and* Perl with it. Development had stopped on it, though, so it naturally led me to Python. For at least three years, Python was my favorite language, but I was heavily invested in the JVM, so I had to settle for Jython most of the time. It sure was fun, even though it was an old, relatively unsupported version of Python.
During those years, I wondered why Python wasn't as popular as Perl. It seemed like a much stronger language than Perl. That's just my opinion, of course, and there were certainly things I missed from Perl, so I'm not claiming that Python is the be-all, end-all of language design. But it seemed like the best thing out there.
Why wasn't it more popular? It seemed to be getting crushed by marketing forces -- by fiery-eyed Perl zealots who went around and gained converts, one at a time. Perl was acting like a virus, and spreading rapidly, while Python sort of limped along, growing much more slowly. Richard Gabriel, of course, had already pointed out that C and Unix were virus-like in his famous short essay, The Rise of ``Worse is Better''.
Let's be careful here: I believe Python has failed so far, and lots of people have jumped to say that Python "beat" Perl. Sure it did, in a number of quality-related ways. But the most immediately relevant metric to me is popular success in the commercial marketplace, because (remember my agenda?) I want to write my day-to-day code in a great language. I can't just tromp into most companies and announce I'm going to be writing in Python; they'd lynch me. So to this extent, Python has failed. And I really, REALLY wish it hadn't. Because unlike when it happened with Smalltalk, I was invested this time around.
Because Python was my favorite language, I read all the Python books, and wrote a ton of Python code, and lurked on Python newsgroups, and basically soaked up the culture. And over a few years, I developed my own pet theory as to why Python has (so far) failed commercially.
I know you're gonna hate this part, but I'm going to talk a little about culture. Culture is very real. It matters every bit as much as love or money.
French waiters in Paris, on average, behave very, very differently from Japanese waiters in Tokyo. It is absolutely undeniable, and the difference is striking. I've spent plenty of time and eaten at plenty of restaurants in both places.
Once I was dining with a friend, and he whispered across the table: "I'd ask for some salt, but I think our waiter would kill us." Which country do you think was I in?
French waiters are not good or bad people, nor are Japanese waiters. They're just doing what's acceptable in their culture. But their cultures are very, VERY different. Waiting tables usually has a distinct subculture in any country, so I'm really just comparing the subcultures of French waiters in Paris and Japanese waiters in Tokyo.
I'm going to go out on a limb here, and say that I found French waiters in Paris almost terrifying. They huffed and puffed and stomped and glared and slammed the food down and were so comically over-the-top rude that it *had* to be an act, since my friends and I never did anything but politely sit down and point tentatively at menu items.
In contrast, I've seen Japanese waiters go to almost comical lengths to try to accommodate the requests of drunken people on business trips, to the point where I started feeling really un-proud to be an American. Japanese customer service practically defines world-class.
OK, I hope we've established that cultures differ, and they have an enormous impact on your experience with people in that culture.
I think it should be obvious to you that programming languages have subcultures, too. The Perl culture is very different from the Python culture, and both are very different from Ruby culture.
The Python culture has a lot going for it. I was pretty immersed in it. But over time, as I wondered why Python wasn't becoming an overnight phenomenon, I started noticing some cultural behaviors in the Python community that I feel may be partly responsible. This is, of course, just my own opinion, endorsed by nobody.
I pointed out some of these behaviors in my anti-anti-hype blog, and of course some people (Rubyists, Pythonistas, innocent bystanders) assumed I was Python-bashing, because they didn't watch Smalltalk die, and they didn't have the context I'm giving you now.
In reality, I'm actually just flat-out disappointed that Python never captured Perl-like marketplace success -- and if you've been with me so far, you'll know this has real economic ramifications in terms of ability to write Python code in the workplace. And worse, it appears to be an avoidable problem: I think there are certain accepted practices in the Python world that are materially harming Python's adoption in the commercial marketplace.
I could spend a long time justifying each of my claims from anti-anti-hype, but let's just focus on one of them: the tendency to label people as "incorrect". It's just an annoying habit, but one that can easily drive a potential new user away. It's a cultural habit, just like stomping and glaring and saying "psh!" loudly is a cultural habit among waiters in small restaurants in the Quartier Latin district of Paris.
The fact is, it doesn't take very much searching to find examples of this labeling. For instance, Recipe 1.7 of the Python Cookbook ends with a discussion around attributes versus items, and claims that many newcomers to Python "desire confusion" (by asking for uniform access to both), especially if they've come from a JavaScript background.
That seems kinda mean to me. If a programmer is genuinely confused, then fine, they're confused, although there's no need to harp on it. But if programmers are asking for a way to solve problems in a way they're used to, then labeling them as "confused" (a word that dictionaries varyingly define as baffled, perplexed, or unable to think with clarity or act intelligently) seems kinda harsh. Doesn't it?
Similarly, in Chapter 5 of the "Jython Essentials" book, during a discussion of Python's class system, it says: "Sometimes people erroneously see the need to explicitly specify the instance in the method argument list as evidence that object-oriented programming is somehow 'tacked on' to Python."
"Erroneously"? Gosh, this issue seems like a matter of pure opinion, not a fact that one can be either correct or incorrect about. How can an opinion be erroneous? Well, it's a cultural thing. If you have a culture of labeling differing opinions as incorrect, then an opinion can easily be considered erroneous.
There used to be an entry in the Python FAQ, which they removed a year or two ago, that said something along the lines of "Am I allowed to suggest changes to the language?" and the answer was a terse: "No." I can't remember the exact wording, but I found it pretty jarring, and it was there for years before getting cleaned up.
These little things add up, and they're ubiquitous. You may not notice them when reading Python discussions or documentation. I noticed because I was actively reading the write-ups and opinions of people who had tried Python and decided not to use it. Often as not, they said they felt rebuffed, or felt the community wasn't welcoming them, or they cited some other touchy-feely issue that didn't seem like it should have mattered at all. But there it was: a pattern had emerged.
Are all Python folks to blame for this? Of course not. Most Pythonistas people are really nice, warm, genuine, honest, smart people.
But a culture is a culture, and it has a big impact, like it or not. If the initial experience results in frequent enough culture-shock, it'll drive potential new users away.
Feel free to draw your own conclusions about why you use can Perl at most companies, but Python at relatively few. I've given you my take on it, and even if it's not the whole story, I honestly think it's a factor. There's more to marketing than glossy banners and shapeless cartoon mascots. Marketing can work all the way down to the level of individuals in one-on-one interactions.
In 10 years, I really don't want to be able to say: "I watched Python die". There's plenty of room for maybe 5 to 8 really huge languages in the marketplace. I think Ruby's going to be up there soon, and frankly I'd more than welcome Python up there too.
In the meantime, though, I've been half-assuming that you can't change a culture -- that once it's set, it's set. I hope I'm wrong. But my assumption is one of the biggest reasons that I finally switched to Ruby, just recently, over the summer, and committed to it for the forseeable future. (I'm guessing 5 to 10 years.)
The worldwide Ruby culture is the warmest and friendliest I've seen in my long history with programming languages. And Ruby is a sweet language. Other people seem to agree, and are taking steps to market it, which is getting them labeled as "hyper-enthusiasts" by the Sour Grapes camp. It appears to me that Ruby is doing what I wanted Python to do a few years ago, so I've finally learned Ruby and have switched most of my development over to it.
After all, both languages have a long way to go before they catch up with Java in terms of tools, IDEs, books, performance, threading stability, and tons of other stuff. I wanted to make a reasonably educated bet, and choose the language I think is going to be bigger, so it'll work well for me, and so I won't have to fight so hard to use it in my job.
It wasn't hard to learn Ruby. In fact after a few days with it, Ruby felt as comfortable as languages I'd been using for years. I've really been enjoying it. It has a few warts; all languages do. No biggie. It looks as if Matz is intent on fixing them in Rite.
I don't know if I like it more than Python and Scheme. I like it at least as much as those languages, certainly. But Ruby's my favorite (as in "preferred") language now because I can see the trajectory it's on, especially now with Rails, and I believe it's going to be the Next Big Thing -- a Java-like phenomenon. So did Bruce Tate when he wrote "Beyond Java". So do James Duncan Davidson, Dave Thomas, Martin Fowler, and many other people who are a heck of a lot smarter than me. You'd think they're on to something big, wouldn't you? I do.
Java-like worldwide adoption really matters. Without that level of mass-market adoption, Ruby won't get the tools, stability, and CPAN-like library selection that it needs in order to compete with Java and Perl. It's a chicken-and-egg problem that all languages face, and Ruby stands a chance of succeeding where Smalltalk, Python, and other great languages have (to date) failed.
I see Rubyists worrying that Rails is stealing the show. Geez, folks, LET it steal the show. Talk about a free ticket for Ruby success. Java Applets were a way to get Java in front of a million or so programmers, ultimately allowing the Java platform to succeed in all sorts of domains that it might never have seen without the initial "killer app" of Applets.
We live in a world where culture matters, economics matter, and marketing hype matters. They are very real forces that directly affect our quality of life as programmers. You ignore them at your peril, a lesson learned by so many almost-forgotten languages that were stomped by marketing hurricanes like Java and Perl.
I really wanted Python to succeed, and I still wish them the best, but I think they're ignoring marketing. I really want Ruby to succeed, so I get a bit miffed when I hear famous people like Bruce Eckel making uninformed generalizations about both Ruby and the folks who are working hard to make it successful. I think Pythonistas should be focusing on doing the same -- working to make Python successful. I do think it will take a minor cultural adjustment on their part. And they need to start accepting hype as a natural part of the world we live in, a requirement for cutting through the noise. But I think they can do it.
With this context, does my "anti-anti-hype" post start to make a bit more sense? Try re-reading it and see.
If not, well, you can't please everyone. I'm old enough not to mind.