5 ms·

Steve Klabnik's response to critiques of his Ruby OOP post

34 points by tannerburson 15y ago

bphogan 15y ago
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.
- tannerburson 15y ago
  I agree, the original piece was a decent explanation of how to refactor some helper type code into a more Presenter like model. But he completely skipped out on the question of why it's a useful thing, and when it's a good fit. If that post had been by DHH or another Rails core member, we'd see it instantly picked up into the current cargo-cult trend of the month. That said, I do appreciate Steve's work on finding ways outside of "the one true path" to simplify Ruby code, and hope he'll continue writing these sorts of things going forward. If nothing else, the discussion surrounding the technique and it's alternatives is extremely worthwhile.
- raganwald 15y ago
  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 15y ago
    The trouble is that no one's reading books anymore :(
adgar 15y ago
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 15y ago
  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_about_computers_than/334131.html http://thinkexist.com/quotation/computer_science_is_no_more_...
  - dasil003 15y ago
    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 15y ago
      Aside: you can, sort-of. http://www.sciencedaily.com/releases/2009/02/090220172053.htm http://www.sciencedaily.com/releases/2009/02/090220172053.ht...
      - dasil003 15y ago
        touché
- wglb 15y ago
  He also wrote THE Multiprogramming system. His software, of which these are two examples, have low enough error rates that anybody who seriously evaluates today's software would do a double-take.
tptacek 15y ago
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 15y ago
  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 15y ago
    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?"
    - urbanautomaton 15y ago
      You should try to avoid subverting a framework's conventions if you're going to use it, sure, but Rails' helpers seem more like an absence of convention. They're a dumping ground for methods that are crying out to be properly structured. Surely not even the most fervent Rails advocate would claim that it is complete and unimprovable. Every single helper module is mixed in to every single view instance, no matter how irrelevant it may be. There's therefore no reason to carefully choose where to put your helper functions, because they're all available, all the time. This means that a new coder coming along has no idea where to look for helper functions that might be relevant to a particular view he's creating - they could be in literally any helper, or even be helper-ified controller methods. This in turn means you end up with duplicated functionality, orphaned functions, and obsolete cruft stinking up the joint. As a result, any even slightly professional team must develop their own conventions regarding the placement of helper functions. These conventions need to be communicated somehow, and how better to do that than through the code itself? Once you've got a pile of helper functions that are bound by a common cause, why not give that cause a name?
ww520 15y ago
Can someone explain why "Design patterns don’t suck, Design patterns in Java suck"?
- tptacek 15y ago
  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/ http://norvig.com/design-patterns/ Think of all the countless lives that could be saved.
  - Woost 15y ago
    Is there an actual presentation version of it? I've tried reading through those slides, but I lose concentration after about the 3rd one because it's too disjointed.
  - DanielRibeiro 15y ago
    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 http://cleancoder.posterous.com/patterns-of-reality [1] http://dl.acm.org/citation.cfm?id=582436 http://dl.acm.org/citation.cfm?id=582436 [2] http://www.industriallogic.com/xp/refactoring/ http://www.industriallogic.com/xp/refactoring/
jerf 15y ago
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 15y ago
  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 15y ago
    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).
jarrett 15y ago
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-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... 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 15y ago
  This is absolutely my thought, but I was not able to express it as well. :)
rlander 15y ago
" 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.

34 points by tannerburson 15y ago

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.

tannerburson 15y ago
I agree, the original piece was a decent explanation of how to refactor some helper type code into a more Presenter like model. But he completely skipped out on the question of why it's a useful thing, and when it's a good fit. If that post had been by DHH or another Rails core member, we'd see it instantly picked up into the current cargo-cult trend of the month. That said, I do appreciate Steve's work on finding ways outside of "the one true path" to simplify Ruby code, and hope he'll continue writing these sorts of things going forward. If nothing else, the discussion surrounding the technique and it's alternatives is extremely worthwhile.
raganwald 15y ago
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 15y ago
  The trouble is that no one's reading books anymore :(

adgar 15y ago

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 15y ago
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_about_computers_than/334131.html http://thinkexist.com/quotation/computer_science_is_no_more_...
- dasil003 15y ago
  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 15y ago
    Aside: you can, sort-of. http://www.sciencedaily.com/releases/2009/02/090220172053.htm http://www.sciencedaily.com/releases/2009/02/090220172053.ht...
    - dasil003 15y ago
      touché
wglb 15y ago
He also wrote THE Multiprogramming system. His software, of which these are two examples, have low enough error rates that anybody who seriously evaluates today's software would do a double-take.

tptacek 15y ago

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 15y ago
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 15y ago
  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?"
  - urbanautomaton 15y ago
    You should try to avoid subverting a framework's conventions if you're going to use it, sure, but Rails' helpers seem more like an absence of convention. They're a dumping ground for methods that are crying out to be properly structured. Surely not even the most fervent Rails advocate would claim that it is complete and unimprovable. Every single helper module is mixed in to every single view instance, no matter how irrelevant it may be. There's therefore no reason to carefully choose where to put your helper functions, because they're all available, all the time. This means that a new coder coming along has no idea where to look for helper functions that might be relevant to a particular view he's creating - they could be in literally any helper, or even be helper-ified controller methods. This in turn means you end up with duplicated functionality, orphaned functions, and obsolete cruft stinking up the joint. As a result, any even slightly professional team must develop their own conventions regarding the placement of helper functions. These conventions need to be communicated somehow, and how better to do that than through the code itself? Once you've got a pile of helper functions that are bound by a common cause, why not give that cause a name?

ww520 15y ago

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

tptacek 15y ago
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/ http://norvig.com/design-patterns/ Think of all the countless lives that could be saved.
- Woost 15y ago
  Is there an actual presentation version of it? I've tried reading through those slides, but I lose concentration after about the 3rd one because it's too disjointed.
- DanielRibeiro 15y ago
  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 http://cleancoder.posterous.com/patterns-of-reality [1] http://dl.acm.org/citation.cfm?id=582436 http://dl.acm.org/citation.cfm?id=582436 [2] http://www.industriallogic.com/xp/refactoring/ http://www.industriallogic.com/xp/refactoring/

jerf 15y ago

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 15y ago
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 15y ago
  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).

jarrett 15y ago

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-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... 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 15y ago
This is absolutely my thought, but I was not able to express it as well. :)

rlander 15y ago

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