

Steve Klabnik's response to critiques of his Ruby OOP post - tannerburson
http://blog.steveklabnik.com/2011/09/09/better-ruby-presenters.html

======
jarrett
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.

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:

[http://steve-yegge.blogspot.com/2006/03/execution-in-
kingdom...](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-
nouns.html)

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.

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.

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.

~~~
bphogan
This is absolutely my thought, but I was not able to express it as well. :)

------
tptacek
I stopped taking this post seriously when I got to "objects > functions" (at
least in Ruby). I think it may be an elaborate gag.

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.

Also, "structured programming" isn't "Programming 1.0" to "object oriented
programming"'s "Programming 2.0". That is not how it works, Steve.

~~~
exogen
And if you'd rather cowboy up some code than stick with the abstractions your
team is already using, I'd be glad you left the project.

I'm not defending these exact examples or anything, but come on. Any kid out
of school can toss some code into a project that just works. It takes some
discipline to write reusable code that people know where to look for later.

~~~
bphogan
It takes more discipline to decide not to do something.

In the case of Rails, it's a _framework_ and the patterns of that framework
are established. I know to look for models in the models directory,
controllers in the controllers directory, and helpers in the helpers
directory. When I come into someone else's project, it's nice to know where
things are. I've inherited lots of code from consultants who know "best
practices" and move from one project to the next. Some of these projects
barely resemble Rails anymore.

It's led me to ask the question "If Rails isn't good enough, then why are you
using it?"

~~~
jasonlotito
> It's led me to ask the question "If Rails isn't good enough, then why are
> you using it?"

That's a pretty poor question. Rails is a framework, and for the most part it
works. However, that doesn't mean it's the one and true way of doing things.

Granted, I generally agree with the article. Helpers are a step backwards.

~~~
tptacek
Why?

The sole purpose of a helper is to keep code out of templates and presentation
out of controllers.

How could they do a better job of that than they do now?

Remember, the article you're agreeing with says that helpers are bad because
they are "just functions". This is, in a word, crazy. It's one thing to design
with objects; it's another thing to turn _all your functions into classes_ so
you can pretend you're OO.

~~~
fjfish
So put the code in the model, where it belongs ... I rarely use helpers for
anything but formatting-fu - everything else is in the model. I rarely use
helpers, period.

------
bphogan
It's nice that Steve and others want to make Ruby on Rails applications better
and faster.

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.

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.

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".

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.

~~~
raganwald
Your points are cogent, however blogs are more like conversations than books.
With a book, you iterate a few times with your editor(s), you pass drafts
around, and hopefully discover which examples aren’t clear before you publish.
Everything else must wait for the second edition.

With a blog post, you can revise the original based on feedback, but the odds
are that none of the people who read it the first time will see the revision.
A follow-up post is the best way to expand/expound/correct yourself.

I agree that the first post could have been _even better_ , but given the
first post being what it was, putting out a second post seems like the right
thing to do.

~~~
dasil003
The trouble is that no one's reading books anymore :(

------
rlander
" 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?"

" ... functions don’t provide a sufficient amount of power to tackle hard
problems."

" objects > functions"

Why start an otherwise well written post with such trollish statements?

There's a lot more substance in the following paragraphs but instead everyone
is focusing on those.

------
jerf
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 _actually_ 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 _object_.)

Your homework is to spend three months with Haskell learning _idiomatic_
Haskell. Yes, it's not OO. Suck it up. You won't truly understand OO until you
also understand not-OO.

~~~
shepmaster
Steve states: "objects > functions. At least in the context of getting stuff
done in Ruby".

I completely agree that one should write idiomatic code. When you write
Haskell, you write idiomatic Haskell. When you write Ruby, you should write
idiomatic Ruby. Objects _are_ idiomatic Ruby.

~~~
chc
Objects are not idiomatic in this particular case in Ruby. That's why we
haven't been doing things this way for the past several years. Ruby's pseudo-
functions (actually private methods on Object) and class/module functions
_are_ idiomatic. They are part of the Ruby language, and people use them all
the time. Not only is this _not_ the idiom in Rails, even vanilla Ruby
projects avoid this, despite the lack of a framework pushing them in that
direction. Ruby is _very_ strongly OO, but idiomatic Ruby doesn't go out of
its way to call attention to this fact. We don't fastidiously box every block
just to make sure everything goes through an object interface, nor do we write
1.+(2) just to make it really clear to everyone that 1 is an object and + is a
method. To create accessors, we just call attr_accessor — we don't do
AttrAccessor.new(self).

The code Steve suggests here would be more idiomatic in Java than in Ruby.
That's what this reminds me of — Java's endless array of classes-that-want-to-
be-functions. Next somebody's going to realize that you might want to present
dictionaries in different ways, so obviously you're going to want a
DictionaryPresenterFactory to create a DictionaryPresenter to your
specifications (because just having a method with that functionality would not
be sufficiently OO, _obviously_ ).

------
ww520
Can someone explain why "Design patterns don’t suck, Design patterns in Java
suck"?

~~~
tptacek
That statement is almost the opposite of true. The GoF patterns were invented
to paper over the inadequacies of Java and C++ and make them behave more like
languages like Ruby and Python.

I think Norvig's presentation should be required reading in order to obtain
your Ruby or Python programming license:

<http://norvig.com/design-patterns/>

Think of all the countless lives that could be saved.

~~~
DanielRibeiro
That is not entirely true. GoF patterns have tons of examples in Smalltalk,
which is as dynamic as Ruby/Python.

But they _are_ more verbose and awkward to use in statically type languages,
languages without first class functions (unlike Smalltalk, Ruby and Python),
and methods like doesNotUnderstand, method_missing or __getattr__.

And languages with mixins/metaprogramming support can do pretty much all
patterns in a much better way (this is easy to see on the paper[1] where
Gregor Kiczales implements the patterns in AspectJ and see how much simpler
they become when you have mixins).

The biggest problem with patterns is that people start with them, instead of
refactoring to them when needed [2], which leads to a lot of over engineering
(which is a form of premature optimization, and we all know what Knuth said
about that).

Uncle Bob (creator of Selenium, author of Clean Code) talked about it
recently: <http://cleancoder.posterous.com/patterns-of-reality>

[1] <http://dl.acm.org/citation.cfm?id=582436>

[2] <http://www.industriallogic.com/xp/refactoring/>

~~~
adgar
> dynamic dispatch (thin of doesNotUnderstand, method_missing and __getattr__)

Dynamic Dispatch has a very well-defined meaning. It means dispatching based
on the runtime type of a variable rather than the declared, static type. The
three methods you mention just happen to exist in languages that feature
_only_ dynamic dispatch.

I'm not sure if there's a formal term for the methods you refer to, but they
aren't "dynamic dispatch".

~~~
DanielRibeiro
Actually there is. This is a reification of the call stack (so it is a
reflection trait of the language) called _method lookup alteration and
interception_ [1]

But thanks for pointing it out. I've edited the original comment to avoid
confusion.

[1]
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91....](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.1021&rep=rep1&type=pdf)

------
adgar
_Actually, come to think of it, Djikstra [sic] wouldn’t even write any code,
because it’s beneath him, but you get the idea._

This is ridiculous. Of course Dijkstra wrote code. He authored the first
implementation of an ALGOL 60 compiler, if I'm not mistaken.

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.

~~~
shepmaster
I think that he's referring to a quote from Dijkstra: "Computer science is no
more about computers than astronomy is about telescopes." [1] Said another
way: it's just a joke :-).

[1]
[http://thinkexist.com/quotation/computer_science_is_no_more_...](http://thinkexist.com/quotation/computer_science_is_no_more_about_computers_than/334131.html)

~~~
dasil003
That's a nice quote, but if you could create a telescope that created more
powerful telescopes then it'd be a better analogy.

~~~
DanI-S
Aside: you can, sort-of.

[http://www.sciencedaily.com/releases/2009/02/090220172053.ht...](http://www.sciencedaily.com/releases/2009/02/090220172053.htm)

~~~
dasil003
touché

