hello fellow devotees,
i have a minor crisis in my perl programming career.
i am in a situation where i am required to write code such that a beginner who has never done any programming before can understand exactly what it does.
by this point you may be thinking something along the lines of 'good code documents itself' etc..., but what it means is, in terms of this requirement, not using 'complicated' data stuctures, which have defined as anything more complicated than a list of lists. not using references, not using any OO, not using any special variables (other than $_ or @_) and not using any other 'esoteric' perl (apparently, recursion is esoteric perl...). the list goes on.
there may be one way to do it, but there is also a good way and a bad way.further, i can't use strict (it'll cause countless problems with legacy code) and -w is a no-no too. (remember, these are things imposed on me)
i have studied my perl hard, and continue to do so, but this is making me flag. why learn what you can't apply (although, i do love learning for the sake of learning)?
my point, if there is one, is how do you cope when your team lead and boss know less perl than you, they can't write good code, and marginalise you for knowing more than they do?
i love perl. the joy i get from it is immeasurable. if i conform to these requirements am i still programming perl?
Re: to perl or not to perl
by footpad (Abbot) on Jun 07, 2001 at 02:18 UTC
|
You could:
Try to help them understand why you would rather use strict and warnings. (Of course, this means you'll need to know that.)
I doubt "Because the Perlmonks say so" will be entirely sufficient. If you can demonstrate a business case, one outlining the benefits for detecting common mistakes early and so forth, you should be able to make headway. Most bean-counter types understand better return on the investment.
Perhaps you could propose a test scenario, one comparing your current practices against the results of using strict & warnings. If it works, then you'll have something concrete to work with.
Also, it may help to propose a transition plan, one that updates your legacy code over time. That can be an effective way to rewrite stuff without slowing down the entire process.
Use strict and warnings to develop your contributions to the project and then deactivate those before turning it in. I'm not too fond of that idea myself, but at least your work gets some benefit.
Failing the above, put up with it until you find a position with a more enlightened organization. (I'm not sure it's productive to be in a place where you're marginalized for wanting to use better coding practices.)
As far as programming Perl if you're conforming to the (sub)standards they demand, I don't see why not. It's still Perl and you're still learning something about it. Just keep learning the best practices on your own and be ready to move if there's an opportunity.
--f
| [reply] |
|
As far as programming Perl if you're conforming to the (sub)standards they demand,
I don't see why not. It's still Perl and you're still learning something about it.
I just want to second this advice. So often, what I hear instead is along the lines of
"Just throw up your hands, yell 'You people are so clueless', and stalk out in a huff."
adamsj
They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen
| [reply] |
|
I think we've all seen this requirement before over and over again. Particularily when we work in multi-faceted teams where everyone comes from a different background and learned the language for various reasons.
My current contract is an investment bank with serious in-house perl experience. Yet the team where I am had never even heard of strict as a concept, did not use -T or -w, did not use any OO methods, did not have a working perl debugger working, and used CGI by seeding print statements throught the subroutines.
When I started here, I was appalled. I thought I had regressed to babyperl (thank you, monk who used the term on the CB yesterday, I'd give you credit if I knew who you are). Quickly I adjusted to the new problems I had to deal with, such as living in fear of scoping problems and willy-nilly use of local to make up for the lack of strict.
Here is the philosophy I approached in this case to cope with the situation:
I am a contractor employed to:
- do what the client wants me to do within some ethical bounds
- add value to the price my client pays by providing the greatest amount of features possible.
Point 1) helps me remember that the client needs to be able to understand my work - like posting Monk is facing.
Point 2) helps me remember that it is sometimes a good thing to warn the client of the dangers of such behaviour as not using strict, and of the increase in effectiveness and portability that the client will enjoy from improving the team's adherence to general standards.
After 9 months on the job, we have finally managed to convince the group's manager (retired perl/sql coders) that better behaviour was good for everyone, and we now have fully strictified templates, and even managed to teach these old dogs about the benifits of templates and OO design.
Summary: We need to do what our managers want us to do. If there is a better, safer, smoother way to do it, we need to give a meaningful defense for that method, and see if we get a bite. But in the end, IMHO, we need not to try to force our own concept of standards down the throats of uninterested people faced with thousands of lines of well spaghetti-ized legacy code.
Hope this little story helps.
--Hackmare
| [reply] |
Re (tilly) 1: to perl or not to perl
by tilly (Archbishop) on Jun 07, 2001 at 06:25 UTC
|
Well strict is lexically scoped so it can be added
bit by bit without worrying about legacy code.
However my best advice is to define a subset of Perl that
you think allows you to program Perl well which you also
think you could teach fairly quickly. For me that list
would include scalars, arrays and hashes. Basic
programming constructs I would insist on include
functions, foreach, my, and package. I would insist
on the basic array operations, push, pop, shift, and
unshift. I would include simple REs. The global
variables $_, @_ and $! would be acceptable. I would be
willing to use wantarray wisely, with it being my
responsibility to put scalar at places where something
is used in scalar context but a beginner might not
realize it.
To that I would throw in the semi-magical invocations
needed for use, strict, vars, and exporting a
function from one namespace to another with Exporter.
I would add perldoc to the requirements, and say that
for some set of modules that the public interface as
documented in the documentation is fair game. What
set of modules depends on what you are doing. And it
would be allowed to write your own perlpod documentation
inline.
Stop.
There is a lot missing. An awful lot. But the above list
is enough to program fairly cleanly. It offers constructs
to keep life sane. It offers options to reuse existing
wheels. It is powerful enough to keep you productive. But
it is still a list that that you could bring someone up to
speed on fairly fast. It does not offer many major
conceptual barriers for someone who does not have your
background. There is enough room there to work on your
programming style.
Now what is missing? Well references. Objects. Slices.
Closures. Typeglob games. Most of the special variables.
The intricate details of pack. Complex RE tricks. The
need to know most of the precedence table. (Use parens.)
And so on.
Can you convince them of this compromise? I don't know.
You can try. I think you have a chance. I was in a
vaguely similar position. I voluntarily did something
like that, and it worked well. So well, in fact, that
we are using a lot more Perl than we used to. It also
helped that I later got to help train several co-workers.
But even if you cannot get everything on this list, look
on the bright side. It is a perfect chance to go out and
pick up books like Code Complete or the Pragmatic Programmer
and learn about how to write better code. Most what you
can learn about clarity of code doesn't need a lot of
language features to apply, and is darned useful...
On the other hand it might be looked at as motivation to
polish your resume a little... | [reply] |
Re: to perl or not to perl
by tinman (Curate) on Jun 07, 2001 at 02:38 UTC
|
Hello, utopian.. I wish I could say your crisis is uncommon, but in my personal experience, I've faced a similar challenge...
There are some things that you can do.. not all of these are related to programming Perl, obviously, but have a bearing on your workplace environment (dare I say politics) as well...
Firstly, ask yourself (and your managers) about why you need Perl.. Obviously, there is a situation in which Perl seems to be a good fit to solve a problem.. in that case, you should use Perl to its fullest capacity, or risk reducing it to the level of C or Java or any other language... Most people pick Perl because it has something to offer that not too many other languages do... if you always have to contort Perl to be understandable by a person familiar with another language, you're probably negating the reason for picking Perl in the first place....
Further to this point, -w and use strict, among other things, are part and parcel of the language.. would these people contemplate writing Java without using the class libraries ? of course not... the same situation applies here.. I think that a break with a bad tradition is a good thing, and to support not using these useful language features merely perpetuates bad practices...(I temper this by saying that I share your pain with regard to non strict compliant code... converting all of it hurts.. :o)
The next point, these restrictions may be put in place because no one else in the organization knows Perl yet (and they worry about having another person maintaining your code).. Good code walks and peer review sessions can go a long way towards easing those barriers to entry for a person new to programming (for Perl or any other language)
In answer to your final question, even baby Perl is still Perl... use strict and -w are, after all, merely coding practices that make life simpler and easier for you, the programmer... there is nothing in Perl that prevents you from writing entire production systems without these or any other features... that is one of the good things about Perl, it doesn't dictate the way you should write your code (just try coding any which way you want on Pascal or Modula-2, for example...). If what you want to be doing is writing Perl, then you can still learn a lot, despite these restrictions.. (one of the dumber restrictions I had to deal with earlier was that I couldn't pass a variable number of arguments to a sub.. I always needed to fix the number and have a prototype... just to give one example)..
I have no doubt that once the persons in charge see what is Perl (and you!) are capable of, they'll be willing to give more autonomy in coding practices... Its a hard road, I know... but there are very good reasons for using all the features that you mentioned as being on the no-no list, and with time, it shouldn't be too difficult to convince management of your case...
Good luck..!
| [reply] |
Re: to perl or not to perl
by DrSax (Sexton) on Jun 07, 2001 at 07:08 UTC
|
I have read the other comments I have seen on this, and would add the following:
If I wanted to show a non-Perl programmer how easy Perl is, I would use some of the things you refer to as complicated. For instance:
- Well designed objects make your code look easier, not harder, because you can code a high-level interface that hides the complexity of what lies beneath.
- You can then surround your code with lots of comments. I use a colorizing editor which greys them out, including when you print. The contrast makes the code look very clean.
- Use variables everywhere, especially with meaningful names, rather than implicits: $_ and the like. Unobfuscate your code to the point where, though not self-documenting, it is at least highly readable, especially in the context of its comments.
I think you can make a good case for Perl as a serious development language in an environment that is not exactly Perl-friendly.
Brian - a.k.a. DrSax | [reply] [d/l] |
|
I'll second the part about not using implicit variables. I do this for my own benefit as well, as I am inexperienced enough that I don't always understand what they're going to do.
If you can't get away with any object-oriented stuff, try putting must of your functions in subroutines. That way the main part of your program will just be a series of subroutines:
&get_field_ids();
&get_field_values();
&build_message();
&send_email();
If you name the subroutines well, it should be reasonably obvious what's going on, especially if you add comments.
Chumley
"What are the facts? Again and again and again--what are the facts? Shun wishful thinking, ignore divine revelation, forget what 'the stars foretell,' avoid opinion, care not what the neighbors think, never mind the unguessable 'verdict of history,' -what are the facts, and to how many decimal places? You pilot always into an unknown future; facts are your only clue. Get the facts!"
-- Lazarus Long | [reply] [d/l] |
|
I strongly disagree not using the implicite variables
(mainly $_ and @_, but also @ARGV, ARGV, STDIN and STDOUT).
Using them all the time adds needless clutter in your
program, making it harder to find out what's going on.
Do you really think:
@foo = grep {$_ =~ /qux/} @bar;
reads better than
@foo = grep {/qux/} @bar;
It doesn't mean you should always use implicite variables,
far from that. But never using them is like writing shell
scripts without using pipes.
-- Abigail | [reply] [d/l] [select] |
|
Re: to perl or not to perl
by mirod (Canon) on Jun 07, 2001 at 09:42 UTC
|
What your boss can or cannot understand is totally subjective so I am afraid you will have to argue each feature with him. You can start with the kind of "baby Perl" that he has defined and try introducing new features slowly, showing him how they work and why they are useful, maybe by writing snippets 2 different ways, one that conforms to the current directives and a simpler (and obviously easier to understand) one which introduces a new feature.
This way not only will your boss learn more Perl but you will learn how to teach it.
One thing I would definitely not compromise on would be the use of strict and -w though. These make the code safer, cleaner and easier to read. Declaring a variable (and initializing it if need be) is the perfect place to comment its role. And I really don't see how they can be described as making the code more complex. What part of my $total=0; does your boss not understand? Especially if written as:
my $total=0; # the sum of all prices
| [reply] [d/l] [select] |
Re: to perl or not to perl
by converter (Priest) on Jun 07, 2001 at 02:40 UTC
|
Tough spot. Sounds like you're being micro-managed by an insecure superior. The tough guy in me would ask the manager "Who's the programmer here, you or me?" but the older I get, the less often I listen to that voice.
Maybe I'm cynical, but I doubt this situation will improve for you. You'd probably be better off looking elsewhere before things get worse and you find yourself saying and doing things you'll regret.
| [reply] |
Re: to perl or not to perl
by chromatic (Archbishop) on Jun 10, 2001 at 08:12 UTC
|
i am required to write code such that a beginner who has never done any programming before can understand
exactly what it does.
My editors rarely expect me to write English such that a person who speaks only Mandarin could understand the point of my book or article.
(I find the argument that "Perl is hard to read" similarly toothless.)
tilly and Abigail and many other posters are correct. You should establish what the coding standards are and work within those. I hope your company encourages good communication between programmers such that you can learn from each other.
I would rather have one new programmer willing and able to learn than ten seasoned programmers unwilling even to ask me what my latest idiom means. Any organization that treats its programmers like stagnant morons will soon retain only people who refuse to learn.
You can write staggeringly useful programs in a small subset of Perl, but rare is the program over 50 lines that can't be improved with hash slices, for example.
If you have to, be subversive. Show your fellow programmers another way to do it, and say, "Here is what it does, here is why it is better, maybe we should consider it." It's subversive because you're teaching them and appealing to a hopefully-just-dormant sense of curiosity.
Best of luck.
| [reply] |
Re: to perl or not to perl
by bluto (Curate) on Jun 07, 2001 at 19:20 UTC
|
If you haven't been at the company long, or it hasn't been
in existance long, you may have a chance to win them over
to your side -- slowly -- assuming that they are a little
wet behind the ears with managing programming projects and
are teachable. "Incramentalism" works great in politics,
why not in programming? Over time slowly insert new
idioms into the code, add 'use strict' to old code, clean
things up...
It sounds like the company is established though, due to the
exsitance of "magical" legacy code that must not be
touched. If you've been there a while and have built up
some respect, have a go at it -- you may convince them.
I was in a job once where I didn't, no matter how hard
I tried, and it was a long painful lesson.
FWIW, there is nothing wrong with writing code
that a beginner
who has never coded before can understand -- as long as
the code is about 20 lines long. Complex problems
generally require complex solutions (unless they're already
on CPAN), and inexperienced beginners won't understand
them even
if you've written them in the academics' choice of Pascal
or some form of pseudocode.
Penny-pinching (pound-foolish) companies will meet
their doom before too long, hopefully your's isn't.
The company I was at died a meager death.
| [reply] |
Re: to perl or not to perl
by Abigail (Deacon) on Jun 09, 2001 at 15:44 UTC
|
Let me start out by saying that coding standards are good. As long as the
serve two purposes: increasing the quality of the code, and making it
easier for people to read/understand other peoples code.
Dumbing down to the lowest common denominator, however, isn't very useful
in my opinion. Personally, I would refuse to work under the rules laid
down. Not using strict or -w could be circumvented for
a while; just develop your code with use strict; and
use warnings 'all';, and just before checking in, change the
use to no, but that breaks down as soon as someone else
touches your code, or you have to work on someone elses code. Most of
the other rules are downright absurd.
I would step to the manager and declare that apparently she has hired
a big bunch of people not up to the task (programming Perl), and that I
will not dumb down to their level. For me to be useful, I will have to
work with peers - not morons. Depending on her reaction, I would seek
work elsewhere. Be it in the same department, same company, or at some
other company. I would make it clear to her she carries responsibility
for hiring incompetent people, and that I don't have any qualms in venting
that opinion to her boss. In fact, I'd probably state this in email,
Cc-ed as far up the chain as appropriate.
The success of this of course depends on your reputation/experience, your
salary (the more you get paid, the less eager they are to have you perform
suboptimally) and the power of the manager.
Of course, there's always the difference between theory and practise.
What will they do if you write quality code, breaking the coding standards?
Fire you? On what grounds? And then don't forget that rm is an
excellent debugging tool - specially if you have to debug someone elses
code.
-- Abigail
| [reply] |
|
And then don't forget that rm is an excellent debugging tool - specially if you have to debug someone elses code.
This is great advice. I wish I'd had the nerve to take it back when I needed it.
adamsj
They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen
| [reply] |
Re: to perl or not to perl
by brotherTwitch (Initiate) on Jun 07, 2001 at 19:17 UTC
|
My sympathies - I have been in a similar position in the
past, and found that no amount of "dumbing down" of my code
made it possible for the uninitiated to make sense of it.
In fact, in the long run, it resulted in a poorly coded app
that behaved like one, and that _still_ did not meet the
requirement of "understandable by intellectually superior
graphic designers" ;^)
all jabs aside, your issue, like mine, is really not one of
meeting an unrealistic expectation - it's an issue of trust.
Your employer doesn't trust you to write good code - and
expects you to generate only code that he can proof for
him/her self. You really have a limited number of choices.
- put up with it and draw the paycheck
- quietly look for a job working for more intelligent people
- screw the requirement and write code so brilliant
there is no option but to use it (even if it does
look like wizardy to your boss)
For me, I ended up losing the job. It was financially
painfull, but I became able to speak and to sleep again -
It was really in my best interest in the long term.
Do yourself a favor and find yourself someone to work for
who is in possession of a brain. It is doubtfull that this
person will ever come to trust you to do your job if s/he
doesn't now.
May the manifold blessings of Eureka! visit you often-
BrotherTwitch
Edit 2001-06-16 ar0n -- Removed <pre> tags
| [reply] |
Re: to perl or not to perl
by seanbo (Chaplain) on Jun 07, 2001 at 18:36 UTC
|
I have a great idea for you. Send your boss the following email.
Boss,
Please visit Perlmonks before trying to impose any further restrictions on my programming. You will find this site extremely helpful in your understanding of the perl language and some of the simple concepts you currently find advanced.
Respectfully,
utopian
seanbo
Ahh..the odd dog is a strange beast indeed, nobody wants him, but he always seems to be there. | [reply] |
|
|