"DCI" in Ruby is completely broken • Hacker News Board

Re: "DCI" in Ruby is completely broken

#31

Post by zzzeek » Wed, Jan 02, 2013, 7:08 PM UTC

ryeguy wrote: post #29

You know, I've been thinking about this kind of thing lately. All of this mixin, traits, monkey patching hoopla is completely nonexistent in functional programming languages. To add a new method to an object you just..write a function that takes that piece of data. Imagine a language where a call looked like this: user.doSomething(1, 2, 3) But it's just syntax sugar for this function application: doSomething(user, 1,…

how is that not what Python already is:

    >>> class Foo(object):
    ...     def __init__(self):
    ...         self.x = 1
    ...         self.y = 2
    ...     def bar(self):
    ...         return self.x + self.y
    ... 
    >>> Foo().bar()
    3
    >>> f = Foo()
    >>> Foo.bar(f)
    3
    >>>

Re: "DCI" in Ruby is completely broken

#32

Post by Tuna-Fish » Wed, Jan 02, 2013, 7:15 PM UTC

ryeguy wrote: post #29

You know, I've been thinking about this kind of thing lately. All of this mixin, traits, monkey patching hoopla is completely nonexistent in functional programming languages. To add a new method to an object you just..write a function that takes that piece of data. Imagine a language where a call looked like this: user.doSomething(1, 2, 3) But it's just syntax sugar for this function application: doSomething(user, 1,…

That's how it works in D.

Re: "DCI" in Ruby is completely broken

#33

Post by Tuna-Fish » Wed, Jan 02, 2013, 7:18 PM UTC

zzzeek wrote: post #31

ryeguy wrote: post #29

You know, I've been thinking about this kind of thing lately. All of this mixin, traits, monkey patching hoopla is completely nonexistent in functional programming languages. To add a new method to an object you just..write a function that takes that piece of data. Imagine a language where a call looked like this: user.doSomething(1, 2, 3) But it's just syntax sugar for this function application: doSomething(user, 1,…

how is that not what Python already is: >>> class Foo(object): ... def __init__(self): ... self.x = 1 ... self.y = 2 ... def bar(self): ... return self.x + self.y ... >>> Foo().bar() 3 >>> f = Foo() >>> Foo.bar(f) 3 >>>

But you cannot do it the other way, eg:

    def foo(bar, baz):
        print bar.baz + baz

    f = Foo()
    f.foo(3) # error

Re: "DCI" in Ruby is completely broken

#34

Post by cube13 » Wed, Jan 02, 2013, 7:20 PM UTC

lnanek2 wrote: post #21

minimax wrote: post #8

I'm not a Ruby programmer, so maybe I'm misunderstanding the article -- are we talking about changing an object's class hierarchy after it's already been instantiated and then complaining that it's the performance aspect that is pathological? That sounds like a completely insane way of writing software to me.

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 just initialize the the duck with everything it could possibly need to be a duck, rather than adding things dynamically.

Re: "DCI" in Ruby is completely broken

#35

Post by cdcarter » Wed, Jan 02, 2013, 7:34 PM UTC

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…

You could do it on the object level or the class level.

Metaprogramming like this generally is most useful for powering "DSLs" and other ways of expressing not-quite-imperative-code in Ruby.

Re: "DCI" in Ruby is completely broken

#36

Post by zzzeek » Wed, Jan 02, 2013, 7:37 PM UTC

Tuna-Fish wrote: post #33

zzzeek wrote: post #31

Earlier quoted context omitted.

how is that not what Python already is: >>> class Foo(object): ... def __init__(self): ... self.x = 1 ... self.y = 2 ... def bar(self): ... return self.x + self.y ... >>> Foo().bar() 3 >>> f = Foo() >>> Foo.bar(f) 3 >>>

But you cannot do it the other way, eg: def foo(bar, baz): print bar.baz + baz f = Foo() f.foo(3) # error

Claiming "f.foo" should work when "foo" is a freestanding function strikes me as nonsensical, as the "." operator is a namespace operator, suggesting names that are within the namespace of "Foo". Though Postgresql supports this pattern (http://www.postgresql.org/docs/9.2/static/xfunc-sql.html#XFU...). I think it's awkward there too, and has the caveat "it's unwise to give a function that takes a single composite-type argument the same name as any of the fields of that composite type." - basically it breaks namespacing.

Re: "DCI" in Ruby is completely broken

#37

Post by andrzejkrzywda » Wed, Jan 02, 2013, 7:41 PM UTC

I'm "thinking in DCI" for 2 years now.

At GameBoxed (http://gameboxed.com/) we've got a Rails app that uses a lot of .extend on every request. It's in production for 1.5 year now.

It's a backend for multiple social games (one backend app for many CoffeeScript frontends).

It's not huge in terms of traffic and performance needs. We implemented it with a DCI-like architecture in mind. It was helpful at the beginning. DCI wasn't the only way to implement it, but it was the simplest way for us at that time.

We've had some performance problems, but they were never related to the usage of .extend. If it was a performance problem, we would probably consider removing the .extends (not a big deal), switch to Java, do more caching, there are so many options.

Again, we don't have huge performance needs, we've maybe 40 req/s at peak times.

DCI is much more than .extend, it's a huge shift in thinking about the OOP architecture.

If we (as Ruby community) agree that it's an architecture worth trying, then maybe it makes sense to introduce better optimisations techniques to the current Ruby implementations?

Anyway, it's great to see the discussion happening. DCI may not be ready to use right now, but it's more of a change in thinking than in the implementation.

I definitely wouldn't call it completely broken in Ruby.

Here are some of my posts on DCI in Ruby:

http://andrzejonsoftware.blogspot.com/2011/02/dci-and-rails....

http://andrzejonsoftware.blogspot.com/2012/01/dci-and-rails-...

http://andrzejonsoftware.blogspot.com/2011/08/dci-patterns-h...

Re: "DCI" in Ruby is completely broken

#38

Post by CrLf » Wed, Jan 02, 2013, 7:46 PM UTC

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?

"Computers are so fast today that does this benchmarking business really matter?"

Famous last words.

Computers are much faster than they were years ago, but look at how much crap they have to deal with... So much crap in fact that we barely notice they are indeed much faster. So much crap that hardware can barely keep up.

Performance is never mission critical until it becomes mission critical, and that usually happens all of a sudden. It's that moment a few days into production when the system becomes unbearably slow and the rest of the company is breathing down your neck asking "WTF is going on?! Fix it, NOW!".

It's problematic enough when you are just creating to many objects and making processor caches irrelevant, but if your performance issues are baked directly into your coding style... good luck with that.

Re: "DCI" in Ruby is completely broken

#39

Post by bascule » Wed, Jan 02, 2013, 7:47 PM UTC

andrzejkrzywda wrote: post #37

I'm "thinking in DCI" for 2 years now. At GameBoxed ( http://gameboxed.com/ ) we've got a Rails app that uses a lot of .extend on every request. It's in production for 1.5 year now. It's a backend for multiple social games (one backend app for many CoffeeScript frontends). It's not huge in terms of traffic and performance needs. We implemented it with a DCI-like architecture in mind. It was helpful at the beginning.…

What does extend give you that delegation doesn't?

Re: "DCI" in Ruby is completely broken

#40

Post by andrzejkrzywda » Wed, Jan 02, 2013, 7:50 PM UTC

bascule wrote: post #39

andrzejkrzywda wrote: post #37

I'm "thinking in DCI" for 2 years now. At GameBoxed ( http://gameboxed.com/ ) we've got a Rails app that uses a lot of .extend on every request. It's in production for 1.5 year now. It's a backend for multiple social games (one backend app for many CoffeeScript frontends). It's not huge in terms of traffic and performance needs. We implemented it with a DCI-like architecture in mind. It was helpful at the beginning.…

What does extend give you that delegation doesn't?

At a code level - no need to write the delegation methods/macros.

At the design level - flat hierarchy

At an abstract level - thinking in terms of objects, not classes.