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

11–20 of 34 posts

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

#11

Post by raganwald »

bphogan wrote: post #2

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

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.

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

#12

Post by cbs »

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.

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

#13

Post by adgar »

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…

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

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

#14

Post by peteretep »

ww520 wrote: post #6

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

Design Patterns are names given to ways of doing things, so that programmers can talk about the same things.

Any time you forget that, or start using phrases like 'Anti-Pattern', you lose (unless you're an expensive consultant, then you're about to get paid!). This appears to be the current forefront of Java development methodology (based purely on what I've read on HN).

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

#15

Post by DanielRibeiro »

adgar wrote: post #13
DanielRibeiro wrote: post #9

Earlier quoted context omitted.

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…

> 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 "dynami…

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

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

#16

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

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

#17

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

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.

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

#18

Post by shepmaster »

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…

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

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

#19

Post by dasil003 »

shepmaster wrote: post #18
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…

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.

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

#20

Post by dasil003 »

raganwald wrote: post #11
bphogan wrote: post #2

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

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

The trouble is that no one's reading books anymore :(
Post reply on HN