Stupid Easy: 7 Deadly [Rails] Sins, Part 3

Written on 9:23:00 AM by S. Potter

This is the third and final part in the Stupid Easy: 7 Deadly [Rails] Sins series. See part 1 and part 2 if you haven't already. I have left the most heinous sin to the end. If you are a serious sinner in this aspect, there is little hope for you unless you take steps now to rectify your behavior in this aspect.

Stupid Easy Ruby

When in Rome, do as the Romans do
That's right. This is the sin of not knowing how to really code in Ruby. Sure some coders that move to Ruby can write code that does what they want it to do, but often at the severe expense of compromising project code maintainability (e.g. making things very unDRY, etc.) or even introducing significant performance issues by not understanding basics about the Ruby language. Instead I see people using Java, Perl, PHP, C# or even Python idioms in Ruby instead of understanding the essence of the language of Ruby, which is distinct from each of these languages in different ways. The same is true for any language/environment you work within. I know former PHP people that moved to Java and do not have the first clue about basic Java idioms that work well. This isn't just to pick on PHP heads as I imagine this occurs from any language migration path. I have simply seen this sin committed most by former PHP coders moving toward Java, Ruby and Python. However, I will say I see a LOT of former Java (massive static language proponents - Joshua Bloch you are a nonobjective snob) developers that do not understand or appreciate the non-static design mentality and they create large class hierarchies and don't understand what a Mixin is (or they pretend to be "cool" and talk alot of about these idioms, but don't really utilize them in the right way themselves). The Ruby mindset is still different from it's more similar looking cousins: Python and Perl, but moving between Python, Perl and Ruby (in any direction) feels more intuitive (at least in my mind). Now I should stress that I can no longer code in Java without pulling my hair out because the thought of creating 5 interfaces and a factory for every three class implementations drives me temporarily insane. The SPI design principle allows Java to be fairly flexible (especially for a statically typed language), but at the expense of my personal sanity now that I prefer to think the non-static way (yes, I still appreciate Python's strongly-typed ways). This is why I prefer to use JRuby, Jython or Groovy scripting in Java environments. There is no magic bullet to stop sinning in this regard if you aren't willing to take a journey to learn and understand Ruby idioms (not just basic *knowledge*). There are no shortcuts, it simply depends on how easily your brain can shift in gears. This doesn't mean people who can't shift gears are "bad" developers, but not well suited to migrating to significantly different environments very often. Just remember the rules in Ruby aren't the same. Think in terms of sending messages to objects that may or may not respond to the message you send, instead of expected interfaces and you are half way there if you are coming from Java, C++ and similar languages. Think of Java as a big government structure with a complicated tax code and Ruby as minimal government with a simplified tax code without loopholes accessible only to the rich! That means in the Ruby world wild things such as adult services can legally be procured between consenting adults, so bend your brain to think that way when working in Ruby...almost anything is possible especially in the realm of metaprogramming that is not possible in the Java world.
That government is best which governs least.
--Thomas Paine
I personally happen to agree with Thomas Paine's statement (at least in the context of programming), but there are various programming philosophies that different languages cater for, so it comes down to your own preference. Pick the ones you can live with at the time and think in terms of and you will be happier for it. Obviously in a programming context some people (e.g. Joshua Bloch, who is still a static language snob) will oppose legal procurement of "adult services". They have a moral objection to these activities and thus do not appreciate the beauty of dynamic design. If you have such moral reservations in programming, do everyone a favor and stay in the Java world or at least static languages! This is the beauty of different opinions. Nobody is right in absolute terms, but you need to make the right choice for yourself. It is the zealots who only accept "absolute correctness" that we should be weary of (on any side of the argument, but including Joshua Bloch). My general philosophy when I had the Java Way ingrained in my brain was that as an API designer I had to protect stupid developers from their own stupidity. Now my philosophy in the Ruby world is that I write APIs for smart developers and if you aren't [Ruby] smart, use at your own risk. Of course, I oppose complication for the sake of appearing to be "smart". But I try to write APIs that allow more advanced Ruby developers to take advantage of language features such as blocks, metaprogramming, etc. as opposed to providing an over-simplified, dumbed-down API that ends up looking ugly to the wiser Ruby developer due to being less DRY than might be possible without restriction.

Ruby Language Pointers

If you haven't acquainted yourself with the pickaxe book you should pay special attention to the following sections: Blocks, Mixins, Inspecting Objects, Inheritance & Messages, Inheritance & Mixins, Classes & Objects Interacting, The Ruby Language. Then I would look at the source code of the ActiveSupport open source project (part of Rails) for techniques that are very useful. Some of these techniques I have discussed in previous blog posts: Ruby Idiom: Reopening Classes, Ruby Idiom: forwardables, Ruby Idiom: Inject-ing Understanding, Ruby Equality, Ruby Higher Order Messaging.

If you enjoyed this post Subscribe to our feed

1 Comment

  1. sidonath |

    Thanks for the interesting and, indeed, very educational series of posts.

    I consider myself a rails-newbie (and a C#/ASP.NET convert) with some prior Ruby experience, so this is the type of articles I needed. The articles which give me an insight into the "most popular" mistakes converts do.

    As for me, it all sums into one sentence: Get a book and stop learn Ruby (on rails) from blogs/tutorials/code snippets. Of course, this sentence is not nearly as illustrative as your examples. Great job and thanks for making me get a Rails book as soon as possible :)

     

Post a Comment