Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.steveklabnik.com

Post reply on HN
Print view View original

21–30 of 34 posts

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

#21

Post by shepmaster »

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.

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

#22

Post by shepmaster »

cbs wrote: post #12
ww520 wrote: post #6

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

To rephrase the quote: Design patterns can be good in the appropriate situations, but Java's heavy use of them has soured people on them altogether. They're often used ad absurdum in Java, to the extent where even in situations you don't need the complex functionality they support, you're stuck using them (often incorrectly because you don't need them) and they become a burden instead of useful.

In addition to your point, when writing in a language like Java, the overhead of writing code makes doing things the right way (in this case, using a design pattern) harder.

Steve's example of the Strategy pattern is a good example of this. Contrast using this pattern in C (function pointers), in Java (inner anonymous classes conforming to an interface) and in Ruby (a block).

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

#23

Post by DanI-S »

dasil003 wrote: post #19
shepmaster wrote: post #18

Earlier quoted context omitted.

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

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

Aside: you can, sort-of.

http://www.sciencedaily.com/releases/2009/02/090220172053.ht...

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

#24

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

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

#25

Post by dasil003 »

DanI-S wrote: post #23
dasil003 wrote: post #19

Earlier quoted context omitted.

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

Aside: you can, sort-of. http://www.sciencedaily.com/releases/2009/02/090220172053.ht...

touché

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

#26

Post by bphogan »

exogen wrote: post #10
tptacek wrote: post #5

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

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.

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

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

#27

Post by bphogan »

jarrett wrote: post #17

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://…

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

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

#28

Post by urbanautomaton »

bphogan wrote: post #26
exogen wrote: post #10

Earlier quoted context omitted.

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.

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

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?

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

#29

Post by jasonlotito »

bphogan wrote: post #26
exogen wrote: post #10

Earlier quoted context omitted.

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.

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

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

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

#30

Post by tptacek »

jasonlotito wrote: post #29
bphogan wrote: post #26

Earlier quoted context omitted.

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

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

Post reply on HN