Steve Klabnik's response to critiques of his Ruby OOP post • Hacker News Board

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

#31

Post by wglb » Sat, Sep 10, 2011, 1:08 AM UTC

DanielRibeiro wrote: post #9

tptacek wrote: post #7

Earlier quoted context omitted.

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.

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 mu…

I remember how we all waited with bated breath for Design Patterns to come out. It was a bit of a disappointment, I recall. Seemed kind of complicated. So now for some of our patterns we need four C++ files per object? Heck with that.

I would disagree that there are tons of Smalltalk examples there. There are in fact a few examples, and they actually don't weigh very much, because they are pretty small, and you don't really need the whole Design Patterns concept if you are a Smalltalk dude. I have a friend who first picked up the book after programming for 17 years in Smalltalk. He put it down after scanning through the first few chapters because it was very self-evident to him.

For young up-and-coming programmers, I recommend setting aside Design Patterns and reading everything you can find written by Peter Norvig. Start with his design patterns essay. The short version of which is that if you need design patterns, (in the sense of the book) then there is something lacking in your language. They are an unnecessarily.

I would never recommend Uncle Bob to anyone looking to improve programmming chops. Read Norvig instead. Uncle Bob came down on the wrong side of TDD and the fellow who failed to TDD his way into a sudoko solution. Peter Norvig comes up with a different notation, not a methodology, not a design pattern, and produced a very elegant solution.

So to improve your programming skills, avoid Uncle Bob, read Norvig, go easy on the methodology.

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

#32

Post by wglb » Sat, Sep 10, 2011, 1:10 AM UTC

adgar wrote: post #3

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. Dijkstr…

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.

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

#33

Post by chc » Sat, Sep 10, 2011, 4:19 AM UTC

shepmaster wrote: post #21

jerf wrote: post #16

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 link…

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.

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

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

#34

Post by fjfish » Mon, Sep 12, 2011, 3:28 PM UTC

tptacek wrote: post #30

jasonlotito wrote: post #29

Earlier quoted context omitted.

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

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.

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.