Stories
Slash Boxes
Comments

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
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
05:59 AM

Ovid's First Law of Software Technology

[ #39703 ]

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


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Ovid's First Law of Software Technology 8 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
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 [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 :)

        • Ovid's "Inheritance versus Roles" paper [slideshare.net] 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.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.