First off, an apology to Matt Harrison, who seemed to be deeply offended by my Perl vs Python article. That was not my intent. For the record, Matt did give a great presentation. The fact that he went so fast was because he was given less time than he thought he had, and I think he was trying to make up for it. His slides were killer, especially those that had a built-in Python shell. My post was only meant to reflect a few thoughts that I was having, and was not meant to convey a professional comparison of two things that I have no right to compare professionally. By the end of a few comments and replies, I had expressed some personal biases that I have. I tried to express them in as opinions, not facts, and I hope they were construed as such. Matt, I hope you didn't take it personally.
This post isn't meant to be a professional comparison of two languages either. I have yet to see a single line of Ruby code, mostly because I do not yet have the time, but I do have the inclination. I just wanted to express a few observations that I've made so far at the conference.
I met a lot of Ruby programmers there. I knew some beforehand as well, and there have been some recurring themes with these people. First of all, while none of them have said "I'm proud of the language that I have chosen to work in", at least not in actual words, you could see that sentiment just by listening to them talk. These people love the language that they work in, and they are very clearly proud of Ruby's many accomplishments. I talked to one gentleman in particular about Puppet, which he seemed to believe would replace cfengine in very short order. Interestingly, the one project that seems to be dropping in popularity is Ruby on Rails, which once seemed to be the thing that Ruby folk were most proud of.
I've also noticed that Ruby programmers generally refer to the language as "fun". I've lost track of the number of times I've heard the words "Ruby" and "fun" used in the same sentence. I've also found a lot of Perl programmers that have switched to Ruby, and they seem to be the ones that use those two words together the most.
Something else that I noticed at the conference was kind of new to me, which may be because I haven't been paying much attention to Ruby, except in extremely general terms. Whenever Ruby or a project in Ruby was mentioned, it was almost always accompanied by a statement about performance. And no, I did not hear a single soul (including and especially Ruby programmers) talk about good performance. Now, I know that performance isn't everything. Fact of the matter is, the best program written in assembly will always outperform anything written in any other language. So why don't we write everything in assembly? Because writing in assembly sucks, that's why. Performance isn't the only thing that counts.
One interesting thing that I noticed in Phil Windley's presentation about Apache was an offhand comment about Ruby. Phil's talk was really about using mod_perl with Apache. At one point he explained something about the request lifecycle, and said something to the effect of, "that's right Ruby programmers, this thing that you're all of a sudden so excited about, we've had for years in mod_perl." And maybe I was just imagining it, but it seemed that a lot of the people in the room were thinking, "and that's not all!"
Again, not a professional comparison. Not much of a comparison at all, really. Just observations. I don't think there are any conclusions to be drawn here except that Ruby programmers love and are proud of their language, and that Perl programmers still say smug things about their language. That's all. Thank you, drive thru.
If you're referring to the comments Matt left on your earlier blog entry, my impression is that he was only trying to understand your viewpoint. He was not the least bit offended.
ReplyDeleteLike Matt, I don't understand why forced indentation is a problem, even though it bothers so many coders. I would argue the reverse: why must I use redundant curly braces? My code already expresses the same information through indentation.
Let me tell you an interesting experience I had a couple of years ago. My wife's favorite recipe management program is an open source utility named Gourmet Recipe Manager. One day she told me about a few annoyances in the program and I decided to see if I could get them fixed. Without ever looking at the code before, I discovered and solved the problems in minutes, then sent the author a patch. I've had similar experiences with other Python software, even in code that was arguably written badly.
Most public Python code seems to have a property that I have not seen achieved in any other language I have tried: most of the time, I can pick up a .py file and understand it all by itself, without any familiarity with the code it depends on. To me, that is a *huge* time saver. When a problem occurs in open source Python code, I am likely to spend a few minutes with it and find a way to fix it. When a problem occurs in the other languages I use often, it is likely that I will spend several days on it.
Of course there are exceptions, and of course my perception might be wrong, so please challenge me.
You said earlier that in Python, function follows form, but I strongly disagree; to me, that implies Python coders spend a lot of brain cycles thinking about the appearance of their code, which they do not. The Python philosophy is more like this: form is hardly important and only leads to petty differences, so everyone ought to skip this issue by forming code about the same way and talk about function instead. That philosophy only works out if the standard form applies cleanly to many types of programs, and I think it does.