Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The choice that is being described I believe is the choice between code that is easy to modify, and code that is transparent to someone who is new to the code base. For code to be easy to modify it must also be easy for the modifier to understand. However it need not be easy for an uninitiated programmer to figure out.

    As an example, my first experience of functional techniques lead to 20 minutes of head scratching until I finally found the section of code that did the work, and figured out how it worked. Until I figured that out, I could understand nothing. After I figured that out, I could make my modifications quite easily.

    Now that was a simple example. But it happens in far more complex systems as well. Peter Naur's essay Programming as Theory Building gives a good explanation. Unfortunately it is hard to track that down due to copyright issues. Essentially what it says is that while building a well-designed software system, you're creating a theory of how that software system works. A developer who understands that theory will generally know exactly where to look to figure out how something works, and where specific changes should be made. However someone who lacks the theory will have extreme difficulty.

    This phenomena is not to be confused with anti-patterns such as spaghetti code or the ravioli code that you're describing. And the key difference is that when an experienced developer is asked to explain a change, it becomes evident fairly quickly that there is a fairly simple structure underlying the decisions that are being made. With the anti-patterns there is no such structure evident.

    In fact I really like the analogy between programming and theory building. Because it illustrates both what is right and wrong about OO programming. What OO programming does is give you specific building blocks to make the connection between your software theories and your code obvious. However those building blocks have fairly severe limits. If your software theories need to include ideas that don't fit within that framework, then you have problems.