Paul Barry

Web Programming Languages and Frameworks are like Operating Systems and Editors

April 30, 2008

I’ve been doing some work recently with Facebook, building a Facebook app, and I have to admit that Facebook is a pretty well developed site. There is a lot of functionality. Things work pretty well, I’ve never gotten any errors while using the site. They’ve built a decent framework that allows people to develop their own apps for Facebook that work and feel like part of the rest of Facebook. It’s fast enough, although not blazingly fast. And it’s written in PHP.

I know PHP and know Ruby on Rails even better. If before Facebook came into existence, if someone approached me and explained what the idea for Facebook was, all the features they were planning on building, and they said they wanted to build it in PHP, I’d say you are nuts, building a site that complicated in PHP would be a nightmare. But obviously that wasn’t a problem for the developers who built Facebook.

People talk about the question “Do languages matter?”. You have some people expounding on the virtues of Lisp macros who will say absolutely and then you have others saying all languages are turing complete and there is basically no difference. Some people believe the Sapir-Whorf is true and applies to computer programming, others don’t. But at the end of the day, there are good web applications built in PHP, Ruby, Java, .Net, Python, Smalltalk, Cold Fusion, etc. and there are bad web applications built in all of those languages, including Ruby on Rails.

So what can be taken away from that observation is that languages matter to programmers, in the same way that operating systems and editors matter to programmers. You can be productive developing web applications with Java and IntelliJ on Windows, Ruby on Rails on Mac OS X or Common Lisp and Emacs on Linux. The important thing is to find which combination makes you the most productive and then be part of a team that shares that mindset. That’s not to say that all members of a team must use the same language, framework, OS and editor, but it is important for a team to share a common philosophy of software development. The language and framework that appeals to you individually is a strong indication of what your philosophy of software development is.

The fact is that I’ve found Ruby on Rails to be the best language and framework combination for me. If I am building a web application any level of complexity, I will be able to build it better and faster in Ruby on Rails than with PHP, Java or any other language and framework. But that applies to me and many other developers who have embraced Ruby on Rails, but not everyone and not for every web application. If you asked me to develop a web application in PHP instead of Ruby on Rails, that would be like asking Paul Graham to build a web application in Java using IntelliJ instead of Lisp and Emacs, or just as bad as the inverse, asking a Java developer to build a web application using Lisp and Emacs. I think in any of those cases, you’d end up with an inferior product than you would if you let each of those people use what they know and love best.

So based on that, from the perspective of a CTO trying to make a decision on which technology stack to adopt, you would say it doesn’t matter. What matters is that you attract good developers. The key is being able to put together a team of good developers, regardless of the language. But the choice of language does matter because of the community surrounding a language. For example, I would imagine that putting together a team of good Cold Fusion developers would be difficult. For Java or .Net, there is an abundance of developers, but the challenge will be sifting through that abundance to find the truly good ones. This is one area where I believe Ruby on Rails has an advantage. If you could somehow determine the number of total developers for each language and the number good developers for each language, I think you would see that although there are less Ruby on Rails developers, a much higher percentage of them are good developers. I believe Ruby on Rails has a higher Good-Developer-to-Developer ratio than Java, .Net or PHP, and if finding good developers is your goal, that is the number you should care about.

Posted in Technology | Topics Ruby, Facebook, PHP

Calling Methods During Class Definition

April 17, 2008

One of the features I like most about Ruby is the ability to execute code during the definition of a class. Here’s a simple example:

class Foo
  puts "hi"

A more useful example is that you can call a method and self is set to the class you are defining.

class Foo
  def self.whoami
    puts "You are #{self}"
class Bar < Foo

This prints You are Bar. This is a feature that isn’t common to most languages, for example, you can’t do it in PHP, Python(I don’t think, Pythonistas jump in there if I’m wrong), Java or even Groovy. The reason why this kind of method is so helpful is this how you can write code that writes code. This is the closest thing Ruby has to Lisp macros. You see this used in Ruby in with the attr_accessor method and in Rails with many methods, belongs_to and has_many being the most obvious examples.

This allows you to define the metadata about a class in the most DSL-like syntax. It would be really great to see this kind of thing in Groovy.

Posted in Technology | Topics Python, Ruby, Java, PHP

The Edge of Innovation

April 11, 2008

If you are a programmer that deals with web applications and you keep up with the latest trends, then there is no doubt you will at least have heard of Ruby on Rails. You might be at the level where you have read about Ruby on Rails and played with it a bit, but you really haven’t immersed yourself the Ruby/Rails way. Maybe you know how to build web applications with Java, .Net or PHP, and you think “Rails is nice, but there’s nothing Rails can do that you can’t do in X”.

If you are in this camp, it may be because you aren’t willing to adapt your ways to Rails. To really understand the benefits of Rails, you have to not only learn Rails, but learn the best practices followed by good Rails programmers, like Skinny Controller, Fat Model, REST and Behavior Driven Development. You don’t see the true benefit of Ruby until you start to fully embrace concepts like these. The only way to learn concepts like these is to read blogs, listen to podcasts, talk to other Ruby programmers at work, user groups and conferences and most importantly, you have to actually write code that reflects what you have learned. You must put aside your preconceived notions about what is right and what is wrong and surrender to the flow. You must unlearn what you have learned.

So if you haven’t experienced this transformation first hand yet, and someone asks you “What is the biggest advantage to Ruby on Rails”, I would be willing to bet your answer would be productivity. This is the way I think many people involved with technology, who don’t fully grasp the Rails Way, perceive Rails. They believe, with some cynicism, that because of the dynamic nature of Rails, you can develop applications faster. They’ll also probably say the downside is that Rails can’t scale.

But anyway, I’m hear to say that productivity is the most over-rated benefit of Rails. The real advantage to Rails is that it is written in Ruby, which is a very powerful language that will change the way you think about programming. It’s funny, I’ve thought to myself a number of times about how interesting it is that Ruby fundamentally changes the way you think about programming and that “Thinking in Ruby” would probably be a great book. But ironically, Bruce Eckel, the author of the “Thinking in…” line of programming books, seems to be happy with Python and not willing to give Ruby a chance. Who knows, that article is a few years old now, so maybe he’s changed his attitude towards Ruby since then. I know mine has.

It’s hard to quantify the advantage that “Thinking in Ruby” brings. The simplest way I can state it is that you will look at problems differently and come up with better solutions, solutions you may not have thought of if you were programming in other languages. The way I support this claim is by looking at some of the web application development innovations that have come out of the Ruby community.

The first is Rails itself. Rails has been copied, ported, attempted to be ported or talked about being ported to almost every other mainstream language you could think of, including Groovy, PHP, JavaScript, Perl, Java and .Net. This phenomenon is unique to Rails, I can’t think of any other web application framework that can say that. If not the whole framework itself, parts of it such as convention over configuration, migrations and embracing REST have influenced the way web application development is done in almost every language.

Another example is HAML. HAML is a truly new and different take of the problem of generating HTML from a combination of dynamic code and HTML. It is a new idea and it has been ported to PHP, Python, and .Net. Whenever you have a framework or library that is being ported to other languages, it shows that the framework being ported contains new and good ideas about programming. In other words, it is a contribution to the paradigm of web development and a clear sign that the original language that the framework was implemented is at the edge of innovation.

Another example is Behavior Driven Development. This example is even more interesting because the idea originally started in Java with the JBehave framework. Even though the idea for behavior driven development started with Java, the idea didn’t really take off until it was implemented in RSpec. They are fairly similar in terms of syntax. Here’s an example from the JBehave website:

public class CheeseBehaviour extends UsingJMock {
    public void shouldRequireTheUseOfMocks() {
        // given
        Mock cheese = new Mock(Cheese.class);
        Sheep sheep = new Sheep((Cheese)cheese.proxy());


        // when

        // then

and here it is converted to RSpec:

describe Sheep do
  before do
    @cheese = mock(Cheese)
    @sheep = mock(Sheep, :cheese => @cheese)
  it "should squelch when it eats cheese" do

For whatever reason, JBehave really never took hold in the Java community, but RSpec has in the Ruby community. RSpec has been ported to .Net, PHP and Groovy. All of those projects describe their code as a port of RSpec, not JBehave. Again it is Ruby influencing the wider web application development community.

Post World War II, the center of the art world was New York City and it was there that the modern art movemement was born. New York was where innovation in the art world was happening. In that time period if you wanted to be a serious artist, you had to go to New York to experience the movement first hand. Today, I believe the Ruby community is leading the way in innovative techniques for web application development. There is certainly innovation happening in other languages like Python, Smalltalk and Erlang as well, but I don’t think any one other language/community is doing as much as Ruby. As far as I can tell, languages like Java, .Net and PHP are doing nothing to innovate web application development. They are simply lagging behind, playing catch up and trying to figure out how implement new features pioneered in the Ruby community and others as closely as possible, given the limitations of the language. So if you are a web developer, I suggest you ask yourself this question. Are the languages and frameworks you are working with leading others to come up with new ideas? Are the languages and frameworks that you are working helping you come up with new ideas? If not, embrace Ruby and someday you will discover an elegant solution to a problem, one that you may not have without Ruby.

A language that doesn’t affect the way you think about programming is not worth knowing. – Alan Perlis

Posted in Technology | Topics Javascript, Java, Ruby, .Net, PHP, RSpec, Python, Rails, HAML