Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Friday October 02, 2009
04:59 AM

Ovid's First Law of Software Technology

[ #39703 ]

Technologies which aim to "improve" software but cannot be easily explained should be ignored.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • ... 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 [] 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 :)

        • Ovid's "Inheritance versus Roles" paper [] first gave me the confirmation that roles is the way to go, in Perl at least.

          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.