Adrian Holovaty and David Heinemeier Hansson
Adrian (left) and David (right)

Yesterday, all the developers from work went to Snakes and Rubies, in Chicago. It was rather fun. This was a seminar/conference for Ruby on Rails and the Django framework for python.

Adrian Holovaty is one of the three developers who created the Django framework for Python; initially for use on the Lawrence, KS local events and information site.

David Heinemeier Hansson is the developer who initially began development on the Rails framework for Ruby two years ago, though at this point there are other collaborators, I believe. Rails is used in projects linked off 37 Signals.



Both presentations were neat, though I will say that I was initially disheartened when David’s Rails presentation consisted almost entirely of code screenshots. That, at least at first, steered me away and gave me a far better feeling for Adrian and his Django presentation. It took a little while to get over that and listen without rancor.

Both technologies are really sweet. For those unaware, they both provide a method to use their respective languages, Ruby and Python, to quickly rock out websites and web applications. What I took away from the event is that they’re both well-thought and extendable technologies, but Django is aimed to be more of a general purpose site builder for sites with dynamic content and interrelations between that content, whereas Rails is aimed more specifically at the web application construction aspect of things.

I don’t know if this is a fair characterization or not, but it’s what I took away.

The difference in presentational style makes things difficult when trying to choose one over the other — Adrian’s Django presentation was very engaging and entertaining. It was very much a proselytizing thrust. David’s Rails presentation was just… code. His assumption of the format was that people already were familiar and knew about the framework, and the presentation aspect of the seminar was just fluff or feature displays as a prelude to the QA portion. It was harder to learn what I, as a developer, could really do with the framework.

The entire trip home was essentially spent discussing the pros and cons of both as far as we could determine. We’ll have to just try them both it seems. Very few of our developers know Python and none know Ruby at work — it will be interesting.

One other thing to mention, there was a lot of PHP bashing going on. Very much in the same religious wars vein as Mac v. PC or Linux v. BSD. Some of it was valid, but most of it was cheap shots. I just want to mention that what a lot of the PHP bashers fail to realize is it’s the programmers who write bad PHP code. If you treat PHP as if it were C++ or some other functional language, the coding requirements to write good code are the same. For reference, I have never heard C bashing (aside from bemoaning the use of pointers) from anyone, even though it has a lot of the same issues as PHP. So I say the put-downs were a little off the mark — it is equally possible to write bad code in Ruby and Python as it is in any other language.

Having said that… I had an epiphany prompted by one of David’s comments — he characterized PHP as the Devil, always prompting you to do bad things. My ephiphany was: This is true, because PHP is basically lazy man’s C++.

Examples:

  • There is no strong typing, you can do all the nasty C++ stuff you got D’s for in college, and furthermore, there’s no compilation. So there’s no incentive to actually test your code or think about validation or error checking. At least with C you get errors or odd behavior when you try to use an int as a char, and if you have an eventual parse error, you know right off the bat.
  • In PHP the language construction is half-assed about being half-assed. You kind of have C-style objects, but they’re not strict so if you really want you can refer to private data (which only became truly private in PHP5.)

You’re set up in a situation where you want to write bad code in the form of shortcuts, inlining what should be functions, and straight declaring what should be objects. It just sets you up, as a developer, to be a poor coder.

The thing I think people really miss is that you can ignore those promptings and write the good code anyway.

In any event, two of the valid criticisms brought up, namely verbosity and length of applications, are issues I’d like to get rid of. PHP, like C++ and C, almost requires that your code be extensive and long. For that reason alone, I’m willing to look at another language solution.