|
in reply to In Need of Mentoring
For example, I know what I am doing should work with Perl as old as Perl 5.8.8, and I do a <use 5.008008;> to verify this.
Eh, no. That use statement doesn't verify anything in that regard. It does prevent someone with 5.8.7 to run your code though.
However, should I make sure my code works with earlier versions of Perl?
That depends. Who are you programming for? Who are your customers? Do you have to make a sacrifice to support 5.6? If so, what do you get out of it?
many CPAN modules are fairly old, and their coding style is dated.
You know, if I'm considering downloading something from CPAN (or from anywhere else, whether it's free or paid), I seldomly give a flying fuck whether the coding style is outdated or not. The only thing that matters is "does it solve my problem"? If it solves my problem, I don't care whether it's written by someone old enough to remember perl4 (and written as it were perl4), or by a grasshopper easily impressed by the words "Modern::Perl". Hell, it doesn't matter whether it's written in COBOL, Haskell or Javascript. It either solves my problem (ok!) or not (not ok!).
If you buy some meat, do you care whether the butcher uses modern knives, and do you avoid a butcher who has used the same knife for 20 years? Would you refuse to have your packages delivered by FedEx if they'd use a plane which was designed in the 20th century, opting for the bicycle courier who has written "use strict" on his 2009 bicycle frame? Do you only listen to music produced in the past couple of months? |
Re^2: In Need of Mentoring
by qazwart (Scribe) on Jan 16, 2012 at 02:18 UTC
|
You know, if I'm considering downloading something from CPAN (or from anywhere else, whether it's free or paid), I seldomly give a flying fuck whether the coding style is outdated or not. The only thing that matters is "does it solve my problem"
I normally don't give a FF either. It works, I'm happy. If it doesn't, I find a different module. However, I'm not using a module. I'm creating a new one, so I want to do it right. Coding style changes over time, but older modules don't reflect it. For example, many modules use @EXPORT which is now considered a bad technique because it invades the user's namespace. You're not even suppose to use @EXPORT_OK. Instead, your code is suppose to be object oriented.
I've seen modules that manipulate $^W to turn on warnings. I'm sure that was a good technique at one time, but we now have use warnings;. The use of the C Style for loop gets debated a lot. It's now considered bad programming, and I believe it's going to be removed from Perl 6. Yet, I was taught that for (;;) is a much better way to mark an infinite loop over while (1).
And, even basic coding styles change. We're now suppose to eliminating extra parentheses because it's more readable. When I learned programming, it was the more parentheses the better. Better adding an extra set rather than relying on a mistaken idea of operator precedence because it makes your code more readable. When I first learned Perl, I was taught the correct way to create variables was to $camelCase them. They're easy to type and very readable. Don't use $underscore_variable_names because it's no more readable, longer, and harder to type. Yet, Rule #27 by Conway is to use underscores for separating multiple words in Perl variable names.
Nor, can I rely on perldoc. How should I declare something is a base class? Should I use the @ISA list, use parent, or use base? I believe we're suppose to say use base, but if you look at perlboot, it tells you to use @ISA and use var.
This is why I've asked about mentoring. Like 90% of the Perl programmers out there, I'm isolated from the community. Most of the other people around me are C#, C++, or Java developers. They have no idea about Perl.
A few years ago, the head of development decided that my Perl scripts should too be put through a code review process. I thought it was a great idea. After all, our software depends upon it. It should be reviewed. The problem was finding someone who could review it. At my first code review, everybody else admitted they didn't know enough Perl to actually review my code. However, one person in the group had a friend at the bank, and his friend knows a good Perl programmer who's helped him out before. He'll have his friend forward the code to this Perl programmer for comments.
A few days later, I get an email from this friend asking me to review on my own code.
| [reply]
[d/l]
[select] |
|
|
You mention several "changes" that you perceive in code over the time, and you seem to imply that most of them are "improvements".
I for one do not see the move from what you call old style to OO-style an improvement if it is done only for that reason. OO-style has its merits in a lot of cases but it being more moderd by perception is never a good reason to refactor code. Never.
The thing I miss in you very elaborate and well readable posts is what I think is the most important thing in module code: consistency. Reading your posts, I have a gut fealing that your documentation is in good shape. You seem to be capable of explaining your thoughts and goals which imho is an indication that you do so in the docs too.
As others have said, your target audience is important. If you are backporting new(ish) features from perl5.12 to perl5.older, you really care about what versions run the code on what architectures. CPANTESTERS is your help there as I presume you do not have 100+ perl releases running on 40+ architectures. If you are indeed making your code to run on 5.6, some more modern syntax won't even be available.
If your code is aimed at maintenance by many (a public git repo is a nice start), make your style guide public. Explain where your decisions stem from and "force" a style on the other coders. Using Perl::Tidy (perltidy) - and providing a working .perltydyrc can help the others. With what I started: consistency is way more important to be able to read code from others that to follow the style-du-jour.
Enjoy, Have FUN! H.Merijn
| [reply] |
|
|
For example, many modules use @EXPORT which is now considered a bad technique because it invades the user's namespace. You're not even suppose to use @EXPORT_OK. Instead, your code is suppose to be object oriented.
Oh, this is such a load of bullshit.
If you're picking up things like this from your "mentoring", please, immediately log out to Perlmonks to never return, and cancel all your mailing list subscriptions. You would become a better Perl coder if you don't listen to people and parrot their unfounded opinions.
Exporter doesn't invade any name space. Exporter exports exactly what the user asks for. It just that some people cannot grasp the notion of defaults -- Exporter has a way for the user to say "gimme your defaults", and for the exporting module to say "these are my defaults" (@EXPORT). People confuse that with "invading your namespace". But they're either mistaken, or just parrot others without thinking.
Second, making code OO just to avoid using Exporter seems like very bad advice to me.
The use of the C Style for loop gets debated a lot. It's now considered bad programming, and I believe it's going to be removed from Perl 6.
I've no idea about the latter, but considering a C style for loop to be bad programming is of course, utterly crap. It's like saying "using keys and each is bad style programming, you should use values". There are many cases where it's useful to know the index, or where you actually may not process all the elements in order and in isolation.
We're now suppose to eliminating extra parentheses because it's more readable.
That's a new one to me. Which church did you go to, and which preacher said this?
Yet, Rule #27 by Conway is to use underscores for separating multiple words in Perl variable names.
You know, Conway isn't a prophet, and his book isn't a gospel. Read the introduction, he even says so. By all means, if you prefer camel case, use camel case.
This is why I've asked about mentoring.
Actually, it looks like you want a preacher. You seems to desperately trying to avoid deriving your own conclusions, and you seem to want someone who can think for you. Which is the entire concept of religion: having someone else think for you.
It's ok to listen to arguments. Listen to arguments from multiple sides. But do draw you own conclusions. Which neither implies going with the loudest people, or with the majority.
Given your state of mind, I'd say getting a mentor is about the worst that can happen to you.
| [reply] |
|
|
++ for that great story about the friend of a friend :)
| [reply] |
Re^2: In Need of Mentoring
by chromatic (Archbishop) on Jan 15, 2012 at 23:18 UTC
|
You almost make it sound as if coding style were merely a matter of fashion and not a matter of correctness. Consider the difference between a C-style for loop and iteration.
| [reply] |
|
|
It's both. As I pointed out, perlbool teaches people who want to learn object oriented programming to use var and use @ISA. If I look at Perldoc, there's use parent. And, at one time I was told this is how you create a constant:
*PI = \3.14159;
our $PI;
Now we have use constant.
And, there is a fashion in coding just as much as there is in the dresses in Vogue. We use to tell people to parenthesize everything because it was more readable. Now, we tell people to eliminate unnecessary parentheses because it clutters code and makes it less readable. Variable names use to be camelCase, now we are suppose to use underscores. And, what is the best way to do an infinite loop? Do you use for(;;) or while (1)
Or should that be while ( 1 ) ; because the style is now to leave a space around parentheses and various punctuation marks because it's more readable. However, when I was learning C, I was told to get rid of spaces around parentheses because it made my code harder to read.
I'm just happy I never learned about use English; until I was told that it shouldn't be used because it makes your programs run slower and it doesn't really make your programs more readable anyway. | [reply]
[d/l]
[select] |
|
|
Or should that be while ( 1 ) ; because the style is now to leave a space around parentheses and various punctuation marks because it's more readable. However, when I was learning C, I was told to get rid of spaces around parentheses because it made my code harder to read.
From what you've said, you've been programming long enough to have formed your own opinion. Have you?
One of the lessons I learnt quite early on in my career -- thanks to a boss (and mentor) who favoured independent thought over group-think -- was that I should arrive at my own conclusions rather than accepting received wisdom. His words were (roughly):
Listen to others arguments -- when they can be separated from opinion -- but draw your own conclusions.
That has stood the test of time -- nearly 25 years -- and continues to serve me well.
It allows me to perceive group-think; badly justified 'rules'; the latest greatest fads; and preserved-in-aspic dogma; for what they are: lazy thinking and/or born-again over-corrections. Let your own powers of reason be your guide.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
|
|
It's both.
The engineering part of programming allows us to learn from our mistakes. Things we did back in the '90s in Perl turned out to be more trouble than they're worth. Similarly things done in the '00s. I'm sure we'll look back on stuff done in the '10s with the same disdain, but if we're learning and evaluating based on what we've learned, I think we have a reasonable chance to improve.
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
|
|
"LOL" == what a dog's tongue does on a hot day.
You've made it clear what your slobberings are worth
| [reply] |
|
|
|
|
Nah, FWIW I ++ed it. Also FWIW, I think the OP should just put the thing on CPAN, none of this github etc crap. (Don't give in to the CPANazis.)
| [reply] |
|
|
Consider the difference between a C-style for loop and iteration.
Yeah, what about it? Is one of them incorrect? I know C programs with for loops that are correct, are you implying iteration is incorrect?
| [reply] |
|
|
| [reply] |
|
|
|
|
Re^2: In Need of Mentoring
by tobyink (Canon) on Jan 16, 2012 at 08:04 UTC
|
If I buy some meat what I do care about is whether the butcher uses modern meat, or tries to sell me some meat that's been hanging around his shop for 20 years.
| [reply] |
|
|
| [reply] |
|
|
Perl 5.14 is only eight months old. I've eaten meat older than that for sure. (Many salamis are aged at least that long.)
Besides which, I wasn't planning on eating Perl.
| [reply] |
|
|
|
|
