Re: Perl Contempt in My Workplace

I think, a "good programmer" will not only write in the comments what one or two particular obscure lines do, but more importantly, he inserts a little paragraph describing the method of solving the problem and why he is doing it that way. That helps tremendously... because it's one thing to be able to write code. I'm a beginner at perl, and I feel like I can pretty much write anything I need at this moment, but reading and understanding a code that someone else has written requires a lot deeper knowledge of a language. I look at perl code that others have written, and it looks like a foreign language to me sometimes.

Anyone who knows a couple of programming languages already can easily pick up perl in a matter of weeks like I did. So, why are employers afraid of perl? They aren't afraid because someone can't learn to write perl; they're afraid because the next guy will have to be able to read perl. And reading requires a lot more studying and a lot greater knowledge. That's something you can't just learn in two weeks. You have to know all the various frameworks or libraries and intricacies of a language. That requires years of experience. That's why employers are afraid. BUT I think, if you write extensive comments in your perl programs, even a dummy will be able to understand what this program is for and why it does what it does. If you put that much effort into commenting, I think he will change his mind. Write an example program, and show it to him. Show him that even someone who knows nothing about perl can read it and understand it, because that's how you write perl code. He'll change his mind!

Comment on Re: Perl Contempt in My Workplace

Replies are listed 'Best First'.
Re^2: Perl Contempt in My Workplace by graff (Chancellor) on Jan 17, 2022 at 09:22 UTC
Whenever I have an opportunity to mentor people in writing code, I tell them about this habit I've had ever since I became a reasonably good Perl programmer: Every time you open a new, empty file that will contain source code, the first thing you should write into that file is commentary: a description of what this chunk of source code is supposed to do; its inputs and outputs; a synopsis of its usage and (where appropriate) an explanation of its default and optional behaviors. (Doing this as POD is the Best Thing Ever.) Don't start writing the actual code until that part is done. (If, as the code gets written, you change your mind about anything, update the description accordingly.) I've found myself repeatedly relying on this habit when it comes to being able to quickly grok code that I wrote years ago, or months ago, or just last week. It's also very helpful in keeping things clear in my head as I work on the code I'm writing this week.	[reply]

Replies are listed 'Best First'.

Re^2: Perl Contempt in My Workplace
by graff (Chancellor) on Jan 17, 2022 at 09:22 UTC

Whenever I have an opportunity to mentor people in writing code, I tell them about this habit I've had ever since I became a reasonably good Perl programmer:

Every time you open a new, empty file that will contain source code, the first thing you should write into that file is commentary: a description of what this chunk of source code is supposed to do; its inputs and outputs; a synopsis of its usage and (where appropriate) an explanation of its default and optional behaviors. (Doing this as POD is the Best Thing Ever.)

Don't start writing the actual code until that part is done. (If, as the code gets written, you change your mind about anything, update the description accordingly.)

I've found myself repeatedly relying on this habit when it comes to being able to quickly grok code that I wrote years ago, or months ago, or just last week. It's also very helpful in keeping things clear in my head as I work on the code I'm writing this week.

[reply]