Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re^4: seeds...

by Anonymous Monk
on Oct 25, 2005 at 15:01 UTC ( #502741=note: print w/ replies, xml ) Need Help??


in reply to Re^3: seeds...
in thread seeds...

I certainly don't "dumb down" my perl code for the sake of those who don't know perl well enough to understand it. Rather I encourage them to learn perl better.

Well, for me, my company's corporate goals don't including "encouraging language elitism". Like most companies, they focus on getting the job done; and if they don't have to train more, that's better. It's a lot harder to train someone to learn all that someone can do with perl (approximately 5-10 years of solid experience). It's more time and money efficient to write your code so that people who aren't perl experts can still understand your code than to spend five years teaching all of them all of the ins and outs of the language, especially one with so *many* wierd exception cases like Perl.

If there's a choice between writing something in plain language, obvious to a reader from any language background, I'll take it.

The example I gave in another thread was:

my %y = %$x;
versus
*y = $x;
Both do roughly the same thing: access the contents of the hash x. The second is far more efficient in terms of operations performed; it also avoids doing a copy, since it's a direct alias into the hash contents. It's therefore "faster", albeit riskier as well, in the case of accidentally overwriting the hash contents.

I very much prefer the first example, because it's more obvious what's going on. The code will fail immediately if $x isn't a hashref. And more to the point, it's obvious to everyone reading it that a hashref is what was expected. In the second line, it's very unclear as to what's expected to happen; in fact, whatever is passed in gets aliased.

I try to code in such a way as to express intent, not just function. If the code reflects my intent, anyone can fix mistakes in the encoding of that intent. The more obvious my code is to more people, the more value it has to my company, because more people can fix it or formally review it to ensure complexity.

I've had business analysts notice mistakes in the business logic of my code; *because* it's written so to be so obvious that even non-coders have a chance at grasping it. It's very satisfying to them to be sure that what they want is what's being coded; and it's reassuring as a coder to me, as well! If you write for perl-gurus only, your code will only be readable by gurus.

There aren't many perl gurus, and their time is expensive, and not worth wasting on testing tasks that could be done by others, if the code was written to a reasonable level.


Comment on Re^4: seeds...
Select or Download Code
Re^5: seeds...
by duff (Vicar) on Oct 26, 2005 at 17:44 UTC
    Well, for me, my company's corporate goals don't including "encouraging language elitism".

    It's hardly language elitism to expect your programmers to know the language they are programming in. Companies exist to make money. One way to make money is by doing something better/faster/cheaper than someone else. By encouraging your programmers to learn the language idioms, you increase their ability to do things better/faster/cheaper.

    It's more time and money efficient to write your code so that people who aren't perl experts can still understand your code than to spend five years teaching all of them all of the ins and outs of the language

    But the thing is that you don't have to spend 5 years teaching them all the ins and outs of the language. You spend a couple of minutes here and a couple of minutes there explaining the things they don't understand. This has the general effect of making everyone more productive programmers because now they can apply the concepts to their own code where otherwise they'd waste time doing things "the long way". (Note that I didn't say "more productive perl programmers". Learning new concepts can make you more productive in other languages as well. Witness the influences of regular expressions on modern programming languages or functional programming on traditionally non-functional languages)

    Taking the reductio ad absurdum route with what you're saying, if several of your programmers had never used grep or map before would you discourage everyone from using grep/map? Or would you encourage those programmers to learn about grep/map? What about other common language features? Where do you draw the line of what's simple and clear and what's not?

    The rest of your post I agree with even if the example is a bit of a strawman. Your last sentence though:

    ...if the code was written to a reasonable level
    Using language idioms is at "a reasonable level" to me. It's fine if some programmers don't use them because they don't know them. But if they're reading code that does use an idiom they are unfamiliar with they should be able to figure it out and incorporate it into future code.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://502741]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (6)
As of 2014-07-29 00:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (211 votes), past polls