The more I work with Ruby and Ruby on Rails, the more I begin to understand (though not necessarily agree with) a lot of the vitriol that has been aimed at PHP over the years by developers using other more rigorous languages.
A few weeks back I ran into this little speed bump while working with Ruby on Rails, where I was trying to do a multiple assignment like this
Most seasoned Rubyists will be waving their arms around and yelling “NOOOOOO!!!”
But coming from a PHP background this seemed perfectly okay to me.
I was working on a Ruby on Rails project with Netbeans today when I went to fire up webbrick to test something in the app.
I immediately got an error like this
=> Booting WEBrick...
=> Rails application started on http://0.0.0.0:3000
[2008-03-18 16:36:59] INFO WEBrick 1.3.1
=> Ctrl-C to shutdown server; call with --help for options
[2008-03-18 16:36:59] INFO ruby 1.8.6 (2007-03-13) [i386-mswin32]
[2008-03-18 16:36:59] WARN TCPServer Error: Bad file descriptor - bind(2)
C:/ruby/lib/ruby/1.8/webrick/utils.rb:73:in `initialize': Bad file descriptor - bind(2) (Errno::EBADF)
from C:/ruby/lib/ruby/1.8/webrick/utils.rb:73:in `new'
from C:/ruby/lib/ruby/1.8/webrick/utils.rb:73:in `create_listeners'
from C:/ruby/lib/ruby/1.8/webrick/utils.rb:70:in `each'
from C:/ruby/lib/ruby/1.8/webrick/utils.rb:70:in `create_listeners'
from C:/ruby/lib/ruby/1.8/webrick/server.rb:75:in `listen'
from C:/ruby/lib/ruby/1.8/webrick/server.rb:63:in `initialize'
from C:/ruby/lib/ruby/1.8/webrick/httpserver.rb:24:in `initialize'
from C:/ruby/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/webrick_server.rb:58:in `new'
... 7 levels...
from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
from C:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
Here’s some excerpts from DHH’s post and comments yesterday on 37 signals
- The short answer is that we don’t document our projects. At least not in the traditional sense of writing a tome that exists outside of the code base that somebody new to a project would go read …
- Further more, I don’t really find it necessary for the kind of work that we do. Our biggest product, Basecamp, is about 10,000 lines of code. That really isn’t a whole lot in the grand scheme of things. Everything we do is build is also using Ruby on Rails, which means that most Rails programmers would know their way around our applications straight away. It’s the same conventions and patterns used throughout.
- Finally, we write our application in a wonderfully expressive and succinct programming language like Ruby that leads itself very well to a programming style like the one Kent Beck preaches in Smalltalk Best Practice Patterns. Keep your methods short and expressive. On average, our models have methods just four lines long. Adding documentation to a method should usually only be done when you’re doing something non-obvious that can’t be rewritten in an obvious way.
- [comment] Wim, yes there’s RDoc. I just generally don’t use it for projects. When methods are only an average of 4 lines long written in a language like Ruby, it’s often faster and better to merely browse the code base rather than rely on explicit commenting.
Keep in mind that I’m no Ruby on Rails genius, and from the little I’ve done I can see where DHH is going with this. But I’ve always thought that this argument of a language being so succinct and clear that you don’t have to write comments is just a bit silly for a couple of reasons.
- I believe that you don’t write code for machines, you write code for people (other developers). So any help you can give them in navigating your code is typically good to have. It saves them time and their employers money … that is what being a great consultant is about, you have to be thinking in terms of how to help your clients’ business and saving them money falls in that category.
- People who use this line of argument are either too lazy to comment and are trying to justify it …
- … or don’t understand that there are developers of all skill levels in the industry. So whereas, someone with your skill level would be able to navigate your code quickly, someone who wasn’t as good might take longer …why not avoid that.
Note, that I’m not of the school of thought of commenting just for the sake of it, like I’ve heard some “blub programmers” do. However, I do think that you should always be thinking of other developers when you code and if commenting can get them to a point where they can modify your code in 1 minute instead of a minute and a half … then you should comment.
In the end, I guess its a bit unfair to criticize DHH, because its not clear that he doesn’t comment his code much … though its easy to infer that. I just know from my experience that people who say things like he says have a tendency to have 3 lines of comments in some piece of code 500 lines long.
But if you’re a “rockstar developer, I guess everyone has to dance to your tune, wherever you are right?
Quick note to say that I just discovered the brand new Ruby Reddit which is really fortuitous now that I’m spending a lot of time with Ruby on Rails. From there I found the “Ten Essential Ruby Gems” … which I am installing and screwing with as I type :]
Many thanks to Reginald Braithwaite who runs the immensely popular software development blog Raganwald for his post about the Ruby Reddit.
I spent the whole weekend reading about Rails setup and deployment, discovering Ngnix + mongrels as a new Rails hosting setup option and started getting in depth with Rails with Obie Hernandez’s “The Rails Way“.
I don’t know much about the guts of PHP or Rails (that is something I am working very hard to remedy) but I was fascinated by this google group post “Rails is shitty” … Continue reading