in reply to All in one

I'm going to agree with duff here, something like the map with double curly braces or a scary combination of a regex and multiple if's &&'s ||'s or's and various other operators has a downside. Maybe it's fast, maybe it was fun for the programmer to invent and maybe it makes him/her happy, but it's a maintainance problem. Every time a user runs into this new idiom, they have to try to grok it, and that takes time.

Furthermore, simple statements rather than complex ones can be extended more easily to do other things -- which is usually what needs to be done from a maintainance perspective. Another problem is that the idioms that rely on niche corners of the language make porting between different versions of the language, or (more so) different languages

This goes back to the earlier meditation on "elegance", where some one posted that one-liners are more elegant, and that clear and elegant were two different things.

IMHO - first a program should be accurate and up to performance specs - then it should be easily extensible - then it should be readable - then it should be short - then it should be clever (in that order, and hopefully the top three goals are always met)

There is zero room for obscurity in my book. I find it to be rather unprofessional, and detrimental to the inclusion of Perl in non-Perl-elite circles. There is a lot of bias against Perl, and while these statements are cool, when used in excess, they are to the detriment of the language in foreign camps. Just read any of the anti-Perl bias for the Python and Ruby folks. These languages are a lot alike, and really, they percieve Perl as an evil. Think about that, next time one decides to ponder one-liners and whether clarity and brevity are one in the same. I'll say they are not.

I'll also agree with Abigail here that OO-jumping (especially Java-esque OO) over 15 subroutines and 15 files is a horrible way to do things. I'm not trying to steer people here. Simple maintainability is about transparency. Whatever is a barrier to groking the code should be removed. Sometimes this involves consolidation, sometimes expansion.

Perl elegance? It's a Zen thing. Consider the pebble.

Replies are listed 'Best First'.
Re: Re: All in one
by hardburn (Abbot) on Jan 13, 2004 at 14:34 UTC

    I'll also agree with Abigail here that OO-jumping (especially Java-esque OO) over 15 subroutines and 15 files is a horrible way to do things.

    This is one reason why a good design layout is important, probably with UML. You can view the complete design at once and immediately see how each class relates to the others, all in one diagram. No need to jump between a bunch of files.

    I remember first looking at the Freenet Project (external link), which has a reference implementation that is an excelent OO design. However, there isn't any sort of design document for how all these objects interact (at least, there wasn't back then--this might have changed). Figuring out this beast meant wading through a huge directory structure of Java classes, which may have little or no documentation on their own. I can get through a Perl obfu easier than I could work my way through that.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

[reply]
[d/l]
      This is one reason why a good design layout is important, probably with UML. You can view the complete design at once and immediately see how each class relates to the others, all in one diagram. No need to jump between a bunch of files.
      I wasn't talking about the situation where you proudly show your design in a conference room using a spiffy powerpoint presentation. I was more thinking of a situation where it's 11:45 PM, the bug needs to be fixed at 9 AM or the customer (who's 6 timezones ahead of you) will have to be paid damages and you are trying to figure out what piece of code is mangling your data incorrectly.

      I've yet to see a UML diagram that indicates where the bugs are.

      Abigail

[reply]

        I wasn't talking about the situation where you proudly show your design in a conference room using a spiffy powerpoint presentation.

        Nor was I. I was addressing the point that heavy OO is hard to work through because the complete design is scattered throughout a large number of files. UML helps here because even a crappy design will at least show all the crap in one place, provided the code matches what is in that diagram.

        ----
        I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
        -- Schemer

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

[reply]
[d/l]
      This is one reason why a good design layout is important, probably with UML. You can view the complete design at once and immediately see how each class relates to the others, all in one diagram. No need to jump between a bunch of files.

      You are partially right. UML does provide a nifty design file, but it does not proclude the creation of architectures that have dependencies on thousands of objects, evil beasts that require jumping through 15 methods to achieve reality.

      Note about UML -- Many times, though, UML is generated after-the-fact (from code using Rational's software) and in absense of actual design, planning, and API/design documentation. And this is encouraged in the industry. So when design is no longer a seperate step, it ceases to be design. Personally, I do design on whiteboards and with pencils, translate later, and if you start with UML you have already started too low-level. I like to work down from modular components that each have seperate purposes. The insides of those modules can be designed once their behavior and interfaces are defined, but mainly I care first about how the system acts, and what it is. Is it primarly an event loop, etc? I don't care if there is a SuperConductingEventLoopManagerDelegate, for instance. That's way too low level for the design phase.

      All of these processes (well, maybe not UML) are important everywhere, regardless of programming language, when projects rise about simple-helper-script level. I see a lot of UML thrown together at random, essentially boxes and arrows, and folks tend to call that a design. Well, no, a design is only such when you have a *good* configuration of boxes and arrows.

      As a final point, it's wise to note that Sun itself is guilty of the file-jumping I speak of. See how many pages of the J2SDK documentations you have to read to fully understand a particular method call. The calls and dependancies fly absolutely all over the place.

      If anything, if neglect of Perl side leads to obfuscation through compaction, Java leads to obfuscation through expansion and objects will multiply like rabbits. Is there a moral here? Nope. Just watch out for dragons.

      When was in college, I wanted to be a Software Architect. Java, in fact, was something I liked. Then, somehow, it scared me...I still love software design, and I'd do it all day if I could...but I am aware of the dragons of every approach, and even what the industry embraces hardest (Java, UML, XML/SOAP, etc) are only suitable if they can be employed well by those who know they have limitations. Zealots of any particular one-sided approach are the most dangerous foe to good programming. XML everywhere, SOAP everywhere, OO everywhere. Got to pick the best of both worlds...and design should not presume to pick certain tools above others until they can be weighed fairly.

      Again, Programming is looked upon as an Engineering Process. That's good, but the rules aren't nearly hard and fast as the physics of bridge design. There is a lot of art there, and a lot of gray areas. Hard and fast rules are often the enemy of innovation, but so are lack of any sort of rules. Yeah, it's a Zen thing.

      Ok, I guess I forgot what I was talking about :)

[reply]

        Many times, though, UML is generated after-the-fact (from code using Rational's software) and in absense of actual design, planning, and API/design documentation.

        Definately agree here. Such "reverse engineering" of code into a UML diagram is really anti-design. If such tools are used at all, they should only be on old projects that were created without the benifit of a UML (or similar) diagram. If your project has a requirement to generate UML, do it before actual code is written.

        See how many pages of the J2SDK documentations you have to read to fully understand a particular method call.

        I don't miss the days of having to intilize at least two objects just to read a file line-by-line :)

        Java, in fact, was something I liked.

        Same here. I was enticed by its clean (though impure) object system. But that blasted API got to me after a while.

        ----
        I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
        -- Schemer

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

[reply]
[d/l]

In Section Meditations