Steve Klabnik's response to critiques of his Ruby OOP post
blog.steveklabnik.com
Steve Klabnik's response to critiques of his Ruby OOP post
1–10 of 34 posts
Re: Steve Klabnik's response to critiques of his Ruby OOP post
#2It'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.
Re: Steve Klabnik's response to critiques of his Ruby OOP post
#3Actually, 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.
Re: Steve Klabnik's response to critiques of his Ruby OOP post
#4It'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…
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.
Re: Steve Klabnik's response to critiques of his Ruby OOP post
#5I 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.
Re: Steve Klabnik's response to critiques of his Ruby OOP post
#6Can someone explain why "Design patterns don’t suck, Design patterns in Java suck"?
Re: Steve Klabnik's response to critiques of his Ruby OOP post
#7Can someone explain why "Design patterns don’t suck, Design patterns in Java suck"?
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.
Re: Steve Klabnik's response to critiques of his Ruby OOP post
#8Can someone explain why "Design patterns don’t suck, Design patterns in Java suck"?
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.
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.
Re: Steve Klabnik's response to critiques of his Ruby OOP post
#9Can someone explain why "Design patterns don’t suck, Design patterns in Java suck"?
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 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
Re: Steve Klabnik's response to critiques of his Ruby OOP post
#10I 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.