Some problems are better expressed in paradigms other than OOP. One of the beautiful things about Ruby is that you can use OOP or other paradigms on a case-by-case basis in accordance with what's best for the problem at hand. This article seems to miss the elegance of that.<p>Design patterns and OOP have their place, but this article adheres to them too dogmatically for my taste. It reminds me a little of this:<p><a href="http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html" rel="nofollow">http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...</a><p>When I first started programming, I wanted a set of rules which, if followed strictly, would always guide me towards the perfect architecture. I've since learned that such a set of rules doesn't exist. Instead, we have to rely on our experience and insight to tell us which architecture will solve a given problem elegantly, and which will shoot us in the foot.<p>The OOP absolutists seem to be looking for that same El Dorado I once wanted. Ostensibly, design patterns promise us programming bliss through tried-and-true, universally applicable architectures. But they don't. Oftentimes, they just give you more lines of code than you really need.<p>It sounds like I'm dumping on OOP and design patterns, but I'm not. Like I said, there are plenty of perfectly good applications for them. My point is that it takes a bit of that aforementioned experience and insight to recognize those instances when they're appropriate. Otherwise you're just painting by numbers.
I stopped taking this post seriously when I got to "objects > functions" (at least in Ruby). I think it may be an elaborate gag.<p>All I can say is, if I worked in a Rails shop and checked some code in that used a helper to generate the A-Z index of a collection of models, and my boss told me, "no, you need to move that code to app/presenters/as_dictionary.rb, because that's where I've been putting my code that presents our data as_numbered_lists and as_abbreviated_snippets and as_random_selectons; it's called the Presenter pattern and we use it", I'd look for new projects.<p>Also, "structured programming" isn't "Programming 1.0" to "object oriented programming"'s "Programming 2.0". That is not how it works, Steve.
It's nice that Steve and others want to make Ruby on Rails applications better and faster.<p>But this post should have been the original blog post. You can't get frustrated by your audience "not getting it" if you use terrible examples or if you're lying to simplify.<p>This was a good explanation on the way to use presenters. The original one was not. I still don't plan to run out and use presenters everywhere because the payoff simply isn't there for most of the apps I write.<p>My bigger concern is that, like with most things in Ruby, a certain percentage of folks are going to just run wild with an idea, and even the simplest application is going to have a bunch of presenters in it just because someone said it was "the right way".<p>It's good to explain the real "why" with these concepts. What are the benefits, the drawbacks, and what will I be able to do that I couldn't do before? So I think this followup does a great job of that.
" Why is it in Ruby that everything is an object, even integers, yet as soon as we need to format a date, we all turn into Dijkstra and bust out structured programming?"<p>" ... functions don’t provide a sufficient amount of power to tackle hard problems."<p>" objects > functions"<p>Why start an otherwise well written post with such trollish statements?<p>There's a lot more substance in the following paragraphs but instead everyone is focusing on those.
One of the things that has kept me away from the Ruby community is the way it simply takes as an axiom that OO === good; if it is OO it is good, if it is not OO it is bad. Re-read that and look at how many of his arguments are "X is not an object", with little further discussion of how that <i>actually</i> hurts you, just, "It's not OO" so apparently that concludes the argument that it is bad. (The class method comment links off to someone else who still comes down to a great degree to it not being "objects" properly. Yes, they may be overused, but pray tell what instance information the "sine" function takes? Oh, sorry, sine <i>object</i>.)<p>Your homework is to spend three months with Haskell learning <i>idiomatic</i> Haskell. Yes, it's not OO. Suck it up. You won't truly understand OO until you also understand not-OO.
<i>Actually, come to think of it, Djikstra [sic] wouldn’t even write any code, because it’s beneath him, but you get the idea.</i><p>This is ridiculous. Of course Dijkstra wrote code. He authored the first implementation of an ALGOL 60 compiler, if I'm not mistaken.<p>Though, technically for Dijkstra writing code was a bit beneath him, as he preferred deriving it using his Guarded Command Language. But the point stands. Dijkstra may have been a bit of a dick, but there's no need to libel a dead man.