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

"DCI" in Ruby is completely broken

tonyarcieri.com

Post reply on HN
Print view View original

61–67 of 67 posts

Re: "DCI" in Ruby is completely broken

#61

Post by bascule »

cube13 wrote: post #34
lnanek2 wrote: post #21

Earlier quoted context omitted.

It isn't so odd in Ruby. Ruby has always been a duck typing land. If it quacks, it is a duck. There's even a method missing handler so you can respond to any method call whatsoever. People can and do add methods directly to even built-in classes as well, the equivalent of modifying the class prototype in Javascript. So method calls are considered more messages in Ruby and saying a class will respond differently to a…

>It isn't so odd in Ruby. Ruby has always been a duck typing land. If it quacks, it is a duck. There's even a method missing handler so you can respond to any method call whatsoever. What's the benefit of this kind of typing, though? I'm pretty much just a C hacker these days, so I'm pretty ignorant about Ruby, but does this apply to the object or to the class? It seems simpler, especially on a conceptual level, to j…

Ruby decouples the method that was requested (the "message" in Smalltalk OO parlance) from the one that is executed. This allows for a number of neat patterns, like forward invocation, where one object can specify a set of messages to be sent to another object (or method!), or delegation, where an object can opt to handle a subset of messages and pass all others on to an underlying object (or method!).

Delegation (especially with the extreme simplicity of SimpleDelegator) seems like the obvious solution here, at least to me, but some people prefer to use cache-busting mixins instead.

Re: "DCI" in Ruby is completely broken

#62

Post by thedudemabry »

voidlogic wrote: post #57
cube13 wrote: post #34

Earlier quoted context omitted.

>It isn't so odd in Ruby. Ruby has always been a duck typing land. If it quacks, it is a duck. There's even a method missing handler so you can respond to any method call whatsoever. What's the benefit of this kind of typing, though? I'm pretty much just a C hacker these days, so I'm pretty ignorant about Ruby, but does this apply to the object or to the class? It seems simpler, especially on a conceptual level, to j…

Side note, duck typing is not inherently slow. Some people assume since many duck-typed languages are slow that there is some causation going on. Go is way faster than Ruby and extensively uses duck typing everywhere (but is also statically typed and not interpreted-). My point is duck typing is not the reason Ruby is so slow.

Interesting point. I never considered whether duck typing was possible in a statically-typed language. I've always used it in concert with interpreted languages. I imagine it could take a significant amount of pain away from systems programming (I'm looking at you, COM).

Re: "DCI" in Ruby is completely broken

#63

Post by LnxPrgr3 »

dogas wrote: post #22

DCI is a paradigm related to design and architecture. Computers are so fast today that does this benchmarking business really matter? If DCI helps to keep your code maintainable, readable, and less buggy, is that a better tradeoff? I would think that 95-99% of the time, the answer is yes. On a side note, if speed is mission critical , then would ruby really be the language of choice to use?

We're not talking micro-optimization to squeeze an extra 0.5% performance out of a system. We're talking about an order of magnitude (or more) slowdown, in a language already not exactly known for its blazing speed.

My question of the day: why isn't more time spent on building abstractions that aren't just convenient but that are also fast? Why does readable, maintainable code have to mean code so slow it effectively turns Core i7s into Pentium 90s?

I don't think it has to mean that at all, but that's exactly the choice a lot of programmers seem to think they're making.

Re: "DCI" in Ruby is completely broken

#65

Post by micampe »

thedudemabry wrote: post #62
voidlogic wrote: post #57

Earlier quoted context omitted.

Side note, duck typing is not inherently slow. Some people assume since many duck-typed languages are slow that there is some causation going on. Go is way faster than Ruby and extensively uses duck typing everywhere (but is also statically typed and not interpreted-). My point is duck typing is not the reason Ruby is so slow.

Interesting point. I never considered whether duck typing was possible in a statically-typed language. I've always used it in concert with interpreted languages. I imagine it could take a significant amount of pain away from systems programming (I'm looking at you, COM).

it's usually called structural typing in more strongly typed languages like Go or Ocaml.

Re: "DCI" in Ruby is completely broken

#67

Post by dasil003 »

lucisferre wrote: post #2

From my experience the main benefit comes from the alignment of particular scenarios, with contexts, the result of which is a single place to reason about the algorithm(s) behind that scenario. I see very little reason for the dogma behind the way role injection is typically handled, yet everyone seems to be attached to doing this in Ruby. This is odd because there are DCI examples in almost every language, each one…

I'm late to the party, but I read all the comments and I think yours is the best.

DCI is a powerful design concept in any class-based language. When behavior gets complex, DCI is the cure for the "kingdom of nouns" that results from a beginner-level understanding of how to apply OOP. In short, DCI is a way to elevate business tasks to first-class citizens.

The singleton method business is purely an aesthetic concern. It definitely makes for more appealing code, but at the cost of an order of magnitude performance hit. All else being equal I love elegant code as much as the next rubyist, but this is simply too high a price to pay and I'm shocked that so many people find this acceptable.

Post reply on HN