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?

In reply to Re^8: RFC: feature proposal re code in @INC by blazar
in thread RFC: feature proposal re code in @INC by blazar

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.