Create a new account
Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
Technologies which aim to "improve" software but cannot be easily explained should be ignored.
... I'm still not totall clear about this roles nonsense :-) :-)
I knew someone would bring that up :)
Roles are shared behavior with methods which can't conflict. It's tough to get any simpler than that.
I'm partially kidding :-)
I don't really buy your law though. It was tough for me to "get" roles for various reasons. It was tough for me to get declarative Prolog-ish languages when I first encountered them. I know a bunch of people who took a hell of a time to understand OO. I know a bunch of folk who don't really "get" TDD, XP or Scrum.
Yes - there are nice sound bites for all of them. But they don't really "explain". The concepts are often deep - even if they have a simple container.
The actual law should read (and I knew this when I posted my rather hyperbolic comment): "the more difficult it is to explain a technology which aims to "improve" software, the more likely it is that that this technology fails in its goals. Not quite as catchy, though :)
See Aspect-oriented programming [wikipedia.org] for a great example. What's a "pointcut"? What's a "join point"? What's "advice"? Why is "advice" described as "additional behavior"? "Advice", to me, reads "optional behavior". And does AOP require spe
Aspect-oriented programming is used to concisely implement cross-cutting concerns across a high number of classes and methods that would otherwise require immense quantities of hard-to-maintain code spread out over your whole application.
Examples of cross-cutting concerns which are very amenable to Aspect techniques include logging, debugging and performance monitoring.
So what's a "pointcut"? What's a "join point"? Do you really need a custom IDE to use AOP or not? (I've heard both ways)
I should add that posting known hyperbolic comments can often make for great discussions. I see you're getting a few retweets for disagreeing with me :)
I like the simple description above, too.
For me, who learned from the OO gurus and now practice accordingly, I had to see roles as a safe form of (hush!) Multiple Inheritance (hush!) which solves the crippling problem of method name conflicts.
Get More Comments