Bambi Meets Godzilla

by Steve Yegge

Note, Jan 10th 2005 -- I've turned this and the "anti-anti-hype" post back on. Please see the note at the top of anti-anti-hype. -steve

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 a lot of 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.

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 lots of complex and rather painful reasons that should be non-issues, but they're not. Let's look at them briefly, and hopefully it will shed a little light on my "uncool" post.

Death of a beautiful language

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 ancient history.

To lots of people, though, especially the ones who loved Smalltalk deeply 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.

What's really hard is that 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 lots 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 lots of 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.

There were certainly other factors involved. Smalltalk 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. They were really pretty similar, and 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 had a LOT to do with 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 a lot of you, Smalltalk probably feels like a niche academic language that never had any real popularity.

I think Java coming along and smooshing Smalltalk had a lot to do with 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 these 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?)

Love and Money

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 only think learning a new language is hard. When it's a job requirement, it happens amazingly fast. Programmers are pretty smart people, you know.

So why do they fear languages so much? 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!

Return of Godzilla vs. Bambi

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 discovered Jython, which is pretty nifty port of Python to the JVM. I'd been doing a lot of my scripting and auxiliary work in Perl. This is 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 blog 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 just 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 lots 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 lots of Python books, and wrote lots 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", 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 lots of 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 there are lots to be found. You may not notice them at all when reading Python discussions or documentation. I noticed because I was actively looking for people who had tried Python and decided not to use it, and reading their write-ups and opinions. Often as not, they said they felt rebuffed, or felt the community wasn't welcoming them, or some other touchy-feely type thing 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 a lot of 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 -- rather rudely, it would seem to me -- as "hyper-enthusiasts". As far as I can tell, 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.

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 a lot of 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.


2005-12-29 11:47:53
You used the phrases "Perl marketing" and "Java marketing" as if there were some equivalence. I'm curious about what you meant.
Jeff Blaine
2005-12-29 12:43:16
I thought your assessment of the Python community, generalized, was pretty accurate and astute, within the scope of your pointed article. I poked at Python for years before Ruby crossed my path. I've not written a single line of code in either language in over a year, nor 1 Ruby line ever (in contrast to the 10s of kLOC in Python).

Different cultures. It's real, no matter what any offended Pythonista says.

2006-01-10 12:02:37
Yay! Long live diversity!
I'm glad to see these back, even if I didn't agree with them.

Honestly, if there wasn't already steaming controversy at the time these were originally posted, I think a lot of people would have seen them differently.

So i'm glad that you've posted them back here.

Noel Rappin
2006-01-10 21:15:23

I want to start by saying I think you are completely right about culture and language forces. I also watched Smalltalk die and hated it. I also made a similar point about the "exit" thing and Python culture just today. I also agree that most of the Python community can be very pleasant and warm.

So as I'm reading along, agreeing with what you are writing, I was a little surprised to see myself quoted to support a position I didn't mean. In the quote from the Jython Essentials book, "erroneously" is meant to describe the idea that OO programming is tacked-on, not whether the explicit arg list is a good idea or not. I based the sentence on something Guido had written about OO constructs being a deep part of Python -- it was just meant to combat a common argument against using Python as an OO language, not as an argument that the Python mechanism was beyond reproach.

Now, whether the explicit arg list is a good idea, that's clearly a matter of opinion -- especially since my own opinion changes weekly.

Anyway, thanks for the interesting posts, and sorry for the somewhat pedantic correction, but I'm not a "my way or the highway" person by nature, so it's odd to see myself cited that way.


Steve Yegge
2006-01-10 23:44:33
Sorry about that, Noel.

If it makes you feel any better, I've been finding out-of-context quotes like "Ruby's dad could totally beat up Python's dad" attributed to me, which of course I said in a paragraph that was completely tongue-in-cheek. But nobody will know that, and people are going to be flaming me forever now.

Probably my biggest problem I had with my posts (after I posted them) was that I was pointing something out that was difficult for anyone to step forward and address. It's not as if anyone in particular could say "OK, all French waiters are going to stop saying Psh! from now on." Nobody really represents the community, and nobody can guarantee that the experience will always be pleasant. So I felt bad after bringing it up, and I still do.

Anyway, loved your book, and Jython's a great JVM language. I have about 1200 Jython classes on my game server now, and 1600 Java classes. So Jython's pulled almost even, but with only 1/4 the lines of code. Great stuff.

Noel Rappin
2006-01-11 11:43:21
No problem -- I'm just glad to know somebody read and enjoyed the book. It's true that chapter has a lot of Python advocacy in it -- we felt like we had to sell Python to a large segment of the potential audience.

Actually, there's an irony here. At the time I started the book (Summer 2001), I got involved with it because I was tracking Python newsgroups and mailing lists because my work project was in Python. But the reason my work project was in Python was because I had been unable to convince the rest of my team to go along with my first choice -- Ruby. (It was too new and unproven, they thought).

The Badger
2006-01-12 16:51:11

I don't deny that the Python community has its arrogance and its flaws, although I think you've picked on the wrong things. However, some of what you say really demonstrates a blatant lack of self-analysis:

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.

Yes, it is a cultural thing: loudly voicing some hastily considered opinion based on a cursory glance at the evidence is arguably arrogant behaviour, and many cultures interpret such behaviour as regrettable, erroneous, or whatever you prefer to call it. Perhaps those French waiters picked up on something that you remain blissfully unaware of to this very day.

Steve Yegge
2006-01-12 21:32:43
Hello Mr. Badger,

I doubt Python programmers are any more arrogant than other programmers. I certainly didn't intend to make that point, and if I did, I take it back.

I don't think French waiters are arrogant, for that matter. All waiters take a certain pride in their work; I was a waiter for a while at one point. They just act like they do because that's the acceptable thing to do in their culture.

I assume you realize that if I went to the questionable effort of trying to back up my opinions by writing a fat book, nobody would read it. How many examples would I really have to cite before you no longer thought of my opinion as "hastily considered?" Did you perhaps overlook my observation that I wrote almost exclusively in a dialect of Python for 3 years?

Perhaps if you re-read my article with the realization that I'm not calling *anyone* arrogant, you'll draw different conclusions about it?

2006-01-14 00:20:12
A few observations:
1) Do you think that the Python vs Ruby animosity is particularly strong because in many ways (at least superficially) the languages are very much alike and each camp wants their language to 'win' for the reasons you outline? Not the least of which is they really don't want to end up using the other language if theirs should fail to succeed. (Ruby folks really would hate to have to do the indentation-as-syntax thing and Python folks would really hate that there's so many ways to do things in Ruby, for example)
2) (related to #1) Is there really room for success (as in widespread use) for both Ruby and Python given the similarities? (and does this raise the stakes thus leading to the situation feared in #1)
3) Was Python basically a reaction against the 'freewheeling' Perl? Perl was built on the idea that there's more than one way to do it (TMTOWTDI was and is a popular Perl maxim). Python's mantra became "There should only be one way to do it correctly" and that likely has a large influence on Python culture - If there's only one way to do it then you can call other people wrong and feel quite rightous about it. Ruby inherits Perl's TMTOWTDI philosophy and their cultures tend to reflect this more libertarian approach. If there are many ways to achieve the same result then people are less likely to label someone as being 'wrong'.

One wonders, however, if in 10 years Ruby and Python will have evolved into each other. Python, especially, has been borrowing a lot from Ruby in recent years. I hear Python will even have continuations soon.

2006-01-14 04:18:45
A very nice article. I also believe that Ruby and Rails have a great future in front of them, and the comment on culture around the product is very true - in the last 5-6 years I saw several great projects failing because they were not able to support the newbies, and as a result would lose out to a worse project whose owners are prepared to help and change.
Rommel Lagera
2006-01-15 06:41:51

With regards to Python culture, I must agree you are correct. In an official document which I could not remember they mentioned PowerBuilder as one of the Four Horsemen of Apocalypse. Although the scripting language of PowerBuilder could not compare to Python or Ruby, but the GUI data-entry develpoment has no equivalent in any tool I've seen (least code needed). I hope these kind of comments must be removed, at least, from official documents.

By the way, I'm using a mix PowerBuilder (for GUI) and Ruby (for non-GUI processing) for my present coding works.

2006-01-15 08:24:36

I agree with you ... I would rather see Python win than Ruby, simply because of the Perl TMTOWTDI influence in Ruby (the philosophy reminds me of C++ too). It doesn't seem like both can Ruby and Python survive though -- I'm very much on the verge of jumping in feet first into Ruby as it increases its influence.

One thing that's pushing me toward Ruby is that even if (as Noel commented) OO wasn't tacked onto Python, it sure feels that way. I'd really like OO programming to be more fluid, and looking at Ruby's implementation in overview, it seems like they got it right.

2006-01-15 15:32:34

I would rather see Python win than Ruby, simply because of the Perl TMTOWTDI influence in Ruby
But it seems that limiting people's choice is not a good way to win in the market. Perl is big partly because of the TMTOWTDI culture. People tend to be turned off when you tell them there's only one right way; this has been Python's path and while Python's user community is probably still larger than Ruby's, it's still tiny compared to Perl's. Given Ruby's current growth rate, I think you'll see Ruby's community size exceed Python's sometime this year. As others have pointed out, Ruby tends to be more attractive to Perl people than Python (probably because Perl'ers can feel more at home in Ruby's philosophy) and given that the size of the Perl pool is quite large, that also looks like it could be a win for Ruby as some Perl'ers tire of waiting for Perl 6 and look for alternatives.

It doesn't seem like both can Ruby and Python survive though
It often seems this way to me too, but I doubt the 'loser' will completely die away. Also, as I said in my previous comment, it seems as though the two are evolving into each other (now if only there was an option in Python to not use indentation to delimit blocks, I might be convinced to try it again, but of course that would be an admission that there is more than one way ;-)

One thing that's pushing me toward Ruby is that even if (as Noel commented) OO wasn't tacked onto Python, it sure feels that way.

Yes, this was my impression during my short sojourn into Python a few years back. OO just seems much more foundational in Ruby than it did in Python (despite the strong protestations of the Pythonistas). Also Ruby's iterators (yield to block style) has been in the language pretty much from the start so the libraries use that style heavily. Python's generators are relatively recent, so the standard libraries may not make use of them much. In general the largest differentiator between the two is probably Ruby's anonymous code blocks (and the fact that Python's lambda's are crippled). Unless you've spent enough time in Ruby to have the 'aha' moment associated with Ruby's anon code blocks you probably would think that the only differentiator was indentation-as-syntax (which is mostly just an issue of style).

I tend to suspect that the doctrinaire approach of the Python community has a limited appeal.

2006-01-16 23:14:23
Excellent analysis Steve, and its great you have decided to bring back your previous entries. I think the crowd is mature enough to handle difference of opinion.

I suppose in one of the future articles you could turn your critical eye towards the impact of all this new-blood influx on ruby. In some ways Ruby is what it is today because it has been that gem in the rough away from the eyes of the most of the world.

When the said "commercial success" arrives for Ruby, so will the pressures and drawbacks of all the various forces tugging away at the language to take it into new directions etc. It would certainly be interesting to watch.

I have only passing familiarity with both Python and Ruby and I got into Python due to the killer app of a couple years ago (Zope) and ended up using it for my sys-admin and various small hacking projects.

Being new to Ruby, I feel that the attitudes of the community do make a difference, and even though Python community is full of generally nice and helpful people, the general theme is paternalistic. This also manifests itself in reactions to newbies when it comes to an almost allergic aversion to our friend Tim Toady, possibly because the newbies must not go astray, "they must be shown the true way". I'm sure the intentions are actually good, but one must also look at how they are transforming the marketplace as you have pointed out.

I believe this aversion to TMTWTDI fuels the search (obsessive at times) for one true Pythonic way. Which my entry level mind couldn't understand. Because to me there's always another way, there has to be, or I'd feel all claustrophobic, but that is just me. To think there's only one way may lead to dogmatic behaviour in the community at large. On the other hand, it may lead to an everlasting quest for the "one true way". I believe that's why there are so many references to "zen" in the Python and Zope parlance.

I really like your culture analogy which I think is quite apt (IMO). I tend to believe that these two languages are products of two very different outlooks on life itself (no less). And the thinking patterns which they engender mould and shape the communities which they foster, and its all very interesting to watch in that yin-yangy kind of way.

Since we're talking analogies, I should like to think that Ruby is more like the Katana sword (an "Eastern" mindset) , while Python is more like the heavy Long Sword. Each is a tool for survival on the battlefield, yet one shuns heavy armor in favor of agility, grace and mastery of technique (katana). While the other tends to require a minimum amount of bulk and strength to even pick up the sword. The type of individual which this tool fosters is entirely different. Raw strength and an inevitable need for defensive armour is favord over agility and nimbleness ( An occidental outlook on life and things in general including technology).

I'm not a big military hardware fan, but every time I think of Ruby vs Python, this analogy comes to mind (too many episodes of Samurai Jack lol..) . Its nice to see Ruby folks spend time on working/optimized code just to make it more aesthetically pleasing. This is something which is almost unique to Ruby culture from my vantage point, and something I find very attractive. I'm not saying that other languages don't strive towards the underlying aesthetic impulse. The drive to make things "pythonic" is exactly the same thing. It seems to me that the aesthetic sense in the two languages is dissimilar and divergent.

I would even venture to say that the similarities between the two languages are superficial, but then again, this is just un-informed outsider's opinion, so a pinch of salt is recommended :)

Thanks for another excellent and thought provoking article.

Brian Miller
2006-01-20 14:30:21
A curious thing has happened to me in my Ruby evangelism at work. I won the technical battle -- everyone agrees that Ruby is a better language than Tcl -- and yet, we still don't use Ruby. That hasn't happened in any of my previous jobs. Before Ruby I was a Python advocate, and I never got any traction on the technical merits of the language.

On the one hand, this is encouraging, because I'm one step closer to actually working in a language I like. On the other hand, it's depressing that nontechnical factors are the primary determinant of my weak toolset.

Christopher Dunn
2006-02-27 14:46:57
This is a very convincing article. I will stop my Python evangelism and accept Ruby as the future (especially with Ruby2.0, which is a dramatic improvement).

However, Python is still much better for proto-typing C++ code, for it has:

* amazing libraries (some commercial)
* doxygen + pythfilter (produces C++-like docs for my Python proto-type)
* multiple inheritance (this helps for C++ proto-typing sometimes)

There is also the garbage-collection scheme: Python uses reference-counting, which facilitates automatic resource releasing. C++ encourages the RAII idiom because it is stack-based.

In fact, Ruby can cause other problems in C++ interfacing: Ruby uses longjmp() for exceptions, which can bypass C++ destructors.

So Python is very good for C++ proto-typing (and Boo for C#), but Ruby is a better choice for code which is meant to last.

What I don't like about Ruby:

* the module/namespace system (Python's is better)
* the POD doc system (Python's is better, with doc-testing and literate coding)
* block local scoping (fixed in 2.0)
* lack of keyword args (fixed in 2.0)
* weird behavior of 'while' (after block vs. after statement)
* weird range in condition (removed in 2.0)
* hash literals too verbose (fixed in 2.0)

2006-03-02 08:16:23

I sort of relate to your views on a visceral level.

On the question of culture, my favourite book at the moment is Walking the Talk by Carolyn Taylor. I have lived in a number of 'extreme' cross cultural situations over quite a few years, decades in fact...

While relentlessly positive, practical and to-the-point, this book addresses culture in a way you may never have thought possible. It is not about programming languages at all. But if you have ever come up against a business culture that has frustrated you, then you will definitely appreciate what the author has to offer.

The book should come with some sort of warning though, after reading it you probably won't be able to look at culture with the same eyes you use today, and... (you have been warned). [This sounds so much like a shameless plug, I have to say I have no connection with the author or the publishing company].

2006-03-04 14:04:11
What you said is true and is still happening. This mindset in the python community leaks into sub-projects as well:
J cunningham
2006-03-06 08:34:29
I completely agree with you about language cultures, only my impression about the Perl culture is completely the opposite of yours. I will attach a bit of evidence to this effect, but first a little background to give it context.

I am an engineer. I've been programming since the mid-seventies. I started out with Fortan, then learned Pascal, C, assembly (x86) and C++ with which I am regarded by my peers as an expert. I am similarly regarded with Matlab and Octave. I can do things with Gnuplot most people can't. I write LaTex. Along the way I picked up enough Perl and Python to be dangerous. But by far my favorite language (the one I do all my own projects in) is Lisp.

That said, I was trying to solve a simple Perl problem and went to comp.lang.perl for help. Here's the question:

I'm looking for a way to run another program from a system call and get
the output produced into a perl variable without going through a file


produces a string on STDOUT. I want to grab this in a variable but can't
figure out how to do it. Any ideas?

Here's some selections from the responses I got:

perldoc -q system
for me, about the 7th entry.


What part of the explanation on how to do this in the system function
description did you not understand?


Amazingly, how to do this is documented if you look up 'system'
in the documentation.
But I guess being spoonfed is easier.


Give up on programming. You are not suited to it.


And what was even more amazing is a few minutes after I posted my question I remembered about perldocs and got on the track of the answer and posted to that effect only to discovered that I'd been hammered in the mere five minute interval with all this crap.

I had another earlier experience on comp.lang.perl that wasn't as bad, but similar. The bottom line for me was that the people who write Perl are a bunch of arrogant snots that I didn't want to have anything to do with.

Now, every group has its asses, but virtually every single response contained an insult.

And, I've never been back there. What you say is true - the culture really matters.


John M. Gabriele
2006-03-24 12:18:38
Jeff, I've found c.l.perl a little rough around the edges too. Usenet in general can be like that. You will very probably have a vastly better experience on where posts are moderated and useless or rude replies tend to be removed quickly. Perlmonks is an amazingly helpful and friendly place.
Jan Persson
2006-03-31 08:15:08
I think these figures speaks for themselves.

Google for this:
"ruby" : 77 700 hits
"perl" : 591 000 hits
"python" : 1 780 000 hits

You can also look at the TIOBE Programming Community Index ( where Ruby has risen from position 27 last year to position 22 today. In the same list are Perl and Python holding position 6 and 8 respectively.

Has Ruby become mainstream when the hype is over? I doubt it.

Edwin Fine
2006-05-19 14:06:38
I don't care if Ruby has "made it" or is hype. Sure, it's not perfect, but it's good enough for me, and is the best dynamic language I have used. I've written in Perl, which to me has little consistency and does not appeal to me aesthetically, and tried Python, which just didn't do it for me for some reason. Maybe I didn't give it enough of a chance. Sorry. I took to Ruby instantly. Is it better than language X, Y, or Z? Don't know, don't care. I like it. It works for me. I can do things in it with ease that I only dreamed of doing in other languages (and I am sure you can do these magic tricks in many other languages, but the Ruby way just seemed more elegant to me). I selfishly hope it succeeds so that I can keep using it and its newer versions, along with all the others that love Ruby.