in reply to Re^6: RFC: feature proposal re code in @INC
in thread RFC: feature proposal re code in @INC

But then that would not be Perl. It would be a subset of Perl almost certainly guaranteed not to make use of its expressive power.

A technical writer doesn't set out to make use of all the "expressive power" of the English language; (s)he seeks clarity and aims to be understood by his/her target audience. So, too, a programmer should aim for clarity, and only write what will be understood. In both cases, using simple language wherever possible is going to make life easier for the person trying to understand later on.

Now your claims fundamentally amount to the belief that there's an implication between feature-richness and tendency to write "bad" code. Of course such a cause-effect relationship does exist, but although it is difficult to quantify this kind of things, my judgment, and the common perception here, are that it is of a much much smaller entity than you seem to think.

I can only speak for my own experiences; but they've been almost uniformly bad. It's not just that feature-richness provides a tendancy to write bad code; it's the general fact that giving someone more than they need becomes awkward. Look at the tendancy for long cords to become tangled; it's the same principle with coding -- more is not better. In both cases, the snarls and tangles don't have to happen: but they do happen on a regular basis.

Actually, in my experience, bad code I had to deal with was not bad because of the (ab)use of "advanced" features. It was bad because of "basic" shortcomings, e.g. no use of strict and warnings, unchecked opens and so on.

Those are very annoying problems to solve; but not hard ones. Depending on the needs of the program, you might, for example, replace all uses of open() with a version with exception handling of some sort (dies, warns, throws an exception object).

The problems I'm facing deal more with the fact that the code itself tells me almost nothing about what the code does; it's all run time decisions that are hidden by as many layers of abstraction as possible. Checks for things that can't happen are layered in with things that can and must be checked; and the run time state has become a total maze of objects, global flags, internal stacks, and code hidden in code references and closures.

In particular "bad" code -in my acceptation- indeed often features string evals, always in situations in which it is not needed by any means. And I can understand your concerns with tied, variables, although variables do not tie themselves on their own. But I still can't understand what scares you in closures. Care to give an example?

Well, closures are coderefs, and that means guessing *which* code a variable currently refers to. Add to that the burden of figuring out the scoping of the closure, and you've got much more cognitive burden than tracing a simple function call. Unless there's no reasonable way around it, I much prefer the simple and obvious solution.

And of course, all of my complaints are interrelated. It's not just closures in and of themselves; it not just the ties, it's not even just the evals (though they really suck!). It's the fact that I'm dealing with codrefs (and occasionally closures) that are generated at run-time by evals with class names being returned by objects that are determined by hash lookups to tied variables that are eventually tied to something or other using hash lookups and evals; a very simplified version of the main loop runs something like this: 

while ( @list ) {
      $x = shift(@list);
      ($a,$b) = @$x;

      if ( ref($a) eq "CODE" ) {
          &$a($b); # modifies @list
      } else {
           $a->$b; # $a may be a class or an object;
                   # modifies @list 
      }
} # end of evil code that tells me nothing

[download]

As you can tell, the main section of the code does nothing other than provide some run-time scaffolding to obscure what's going on. The closures and coderefs, the object syntax, the ties, the evals: they all combine to make something hard to understand practically impossible to understand. Any one of them by themselves would be bad enough (especially eval), but together they make it all just horrible.

I'm gaining very little personal benefit from most of Perl's advanced or interesting features, because I need to write Perl that's accessible to a beginner perspective wherever practical to do so. So far, it's been practical to do so, with exactly one exception in two years.1 On the other hand, every time there's a new feature added to perl, there's one more feature I have to remember to watch out for, just in case some idiot has (ab)used it.

--
Ytrew

1 I once wrote a pair of redefine() and restore() functions that override and restore the definition of a function at run time. I use it to simplify testing, by doing separate unit testing of parent functions from their child functions. (ie. If the children return a given value, does the parent function correctly?).

I carefully separated the potentially confusing code out into it's own module, documented the functions and their intended purpose, and documented the codebase as well.

Replies are listed 'Best First'.
Re^8: RFC: feature proposal re code in @INC
by blazar (Canon) on Feb 01, 2006 at 08:46 UTC
    A technical writer doesn't set out to make use of all the "expressive power" of the English language; (s)he seeks clarity and aims to be understood by his/her target audience. So, too, a programmer should aim for clarity, and only write what will be understood. In both cases, using simple language wherever possible is going to make life easier for the person trying to understand later on.

    Granted. I'm not claiming that programming must be an exercise targeted at making use of all the expressive power of a language. I think that one should use all the support that the language of choice has to offer in terms of expressive power to gain clarity.

    I think we both agree that a programmer should "only write what will be understood", the difference being that you mean "by someone who has only a minimal knowledge of the language", whereas I mean "by someone who is reasonably confident with the language".

    You can see yourself that your English prose while probably not being the most sophisticated, is definitely not aimed at, say, a baby. Indeed it does make use of quite a lot of English's expressive power. Why should it be different for programming languages? I don't expect the programmer who is to take up my work to be, say, Abigail but I don't want him/her to be a complete newbie either. (S)he must be able to parse the reasonably "complex" constructs I may want to use to attain clarity.

    Well, closures are coderefs, and that means guessing *which* code a variable currently refers to. Add to that the burden of figuring out the scoping of the closure, and you've got much more cognitive burden than tracing a simple function call. Unless there's no reasonable way around it, I much prefer the simple and obvious solution.

    Letting aside that closures are not necessarily coderefs (who told you that?) and that a coderef needs not necessarily be stored in a variable, if so, then -especially if variables are given sensible names, which is what one should do in any case- it shouldn't be more difficult to find the actual code than with a "regular" sub. If a sub(ref) is a closure around some lexical that's not as closely scoped as possible, and possibly even hard to trace, then it's just a bad use of a closure, exactly like an unchecked use of an open is a bad use of it. It's not that closures are bad, just like opens are not bad, a priori.

    You're also talking about "the simple and obvious solution", disregarding the fact that a solution in terms of a closure may be the logically simplest and most obvious one. Personally I find that in many cases such a solution provides the maximum clarity and the right level of encapsulation.

    And of course, all of my complaints are interrelated. It's not just closures in and of themselves; it not just the ties, it's not even just the evals (though they really suck!). It's the fact that I'm dealing with codrefs (and occasionally closures) that are generated at run-time by evals with class names being returned by objects that are determined by hash lookups to tied variables that are eventually tied to something or other using hash lookups and evals; a very simplified version of the main loop runs something like this:

    Well, I have already expressed my feeling and POV about this, although you seem to differ and I guess I have no chance to convince you. However I'm stressing the concept once (and only once!) more: I'd just call that bad programming. It's not Perl to blame for offering closures and ties and string evals, it's the programmer who abused them to write bad code who's to blame, period!

    More features means more degrees of freedom, and thus an enlarged phase space. This also means that there are corners of it that yield more obfuscation and there are corners of it yielding more clarity. It's up to the programmer to decide where to place his code...

    PS: since you "sign" your posts anyway, you're a named anonymonk, thus somewhat a fake one: why don't you register instead?

[reply]
      I don't expect the programmer who is to take up my work to be, say, Abigail but I don't want him/her to be a complete newbie either. (S)he must be able to parse the reasonably "complex" constructs I may want to use to attain clarity.

      I try to follow the writer's rule: "write for your expected audience"; and you seem to have a more sophisticated expected audience than I do. In my case, most of the programmers in my workplace who will be asked to maintain my code just aren't very experienced with perl. If they can't understand it, they'll just come back and ask me; I'll end up maintaining it myself. By using simpler constructs, I improve the odds that someone besides me will be able to maintain the code.

      Letting aside that closures are not necessarily coderefs (who told you that?) and that a coderef needs not necessarily be stored in a variable,

      Argh... but in some sense, you're making my point for me. How on earth can I try to teach people who barely speak English how closures work if a native speaker with a university education (me) who reads the man pages constantly can't understand all the nuances? It's not like the man page was very clear on the topic, either. Better not to use something than to abuse it, in my opinion.

      if so, then -especially if variables are given sensible names, which is what one should do in any case- it shouldn't be more difficult to find the actual code than with a "regular" sub. How would it be less difficult? There's a deeper burder of proof involved for each call. If I see "foo()", I know that the function foo is called. If I see &$coderef, and I believe $coderef contains a reference to the function foo, I still to find out for sure if that's true; it's one more step for me to investigate. Additionally, since Perl lets me change the definition of foo() at runtime, I have to verify that that hasn't happened. If perl didn't allow me the "freedom" to redefine the codebase at runtime, I wouldn't have to check for someone doing that. The more loose ends rattling around, the greater the odds one will go flying and hit someone. :-)

      More features means more degrees of freedom, and thus an enlarged phase space. This also means that there are corners of it that yield more obfuscation and there are corners of it yielding more clarity. It's up to the programmer to decide where to place his code...

      But because of the way language elements interact, for every choice that leads to enhanced clarity, you've got many, many other choices that lead to obfuscation. The odds favour code becoming incomprehensible unless the programmer is very careful. You seem to assume all programmers are experts, and follow your notion of good programming practice; this is most decidedly not the case. Most programmers are bad; some are medicore; a few are good. Why not optimize for the common case?

      PS: since you "sign" your posts anyway, you're a named anonymonk, thus somewhat a fake one: why don't you register instead? I did, a long time ago -- my registered handle is "Ytrew". But I don't have my password at work, and besides, if I gain 5 more XP, my title will change: and I like being called a "monk". :-)

      --
      Ytrew

[reply]
        I try to follow the writer's rule: "write for your expected audience"; and you seem to have a more sophisticated expected audience than I do. In my case, most of the programmers in my workplace who will be asked to maintain my code just aren't very experienced with perl. If they can't understand it, they'll just come back and ask me; I'll end up maintaining it myself. By using simpler constructs, I improve the odds that someone besides me will be able to maintain the code.

        Maybe spend some of your time bringing your co-workers up to speed? I usually find teaching stuff a more effective use of my time than coding to the lowest common denominator or turning myself into a bottleneck.

[reply]

In Section Meditations