|
Re^2: top ten things every Perl hacker should know
by Your Mother (Archbishop) on Mar 16, 2006 at 19:57 UTC
|
Brute Force programming is not always a bad idea. Elegant code is often slower and harder to maintain.
I agree with the first premise. The supporting reasons are less good. A complicated Schwartzian transform may well be impossible for a first-year Perl hacker to read but it's 100 times easier to read than the 2 screenfuls of code it replaces if you know what it is. Elegant, to me, means better, concise, more lucid, not too tricky to follow.
| [reply] |
|
|
There's a difference between elegance for elegance sake (ie. doing something tricky because it has a high geek factor) and elegance because it's good programming (e.g. the Schwartzian transform). I was thinking more of high geek factor code. It might parse better if I s/often/sometimes/.
Jack
| [reply] |
|
|
| [reply] |
|
|
Bad example.
A Schwartzian transform in Perl is always more complex than a straightforward sort block. It is good to know about it because it can be lots faster, but it is more complex.
If you do not understand this, then you don't really understand the Schwartzian transform.
(Note that I have to say "in Perl" because other languages, for instance Python and Ruby, have implemented shortcuts to make Schwartzian transforms simpler than the alternative.)
| [reply] |
|
|
It's all right in front of you; in one sweep of your eye. The filtering, the modification, and the sorting (grep, map, sort, and maybe more). There aren't a couple sets of temporary variables and three or more bocks or subroutines to jump around and try to keep in your head at once. It's the same code condensed. I find it easier to read and much easier to debug.
So I do think the ST is a good example of elegance. I'm open to counter examples of what you consider Perl (not Python or Ruby of course!) elegance.
| [reply] |
|
|
|
|
|
|
|
The problem with the "straightforward sort block" is that you often have to surround it with lots of other code to achieve the same results as the ST. At the heart of it, the sort complexity is the same and the difference lies in where you mangle the data into a sortable form and then extract it again. If I understand correctly, it is the Guttman-Rosler Transform that has a simpler lexical sort after the sort keys have benn carefully packed into a string.Cheers, JohnGG
| [reply] |
|
|
|
|
|
Re^2: top ten things every Perl hacker should know
by apotheon (Deacon) on Mar 16, 2006 at 19:16 UTC
|
When you've programmed yourself into a corner, sometimes the quickest fix is to trash everything and start from scratch.
That's very true — but it's also sometimes instructive to keep doggedly at the problem until you solve it without rewriting, even if scrapping the original and starting over would be quicker. That's my experience, at any rate.
| print substr("Just another Perl hacker", 0, -2); |
|
- apotheon
CopyWrite Chad Perrin |
| [reply] |
Re^2: top ten things every Perl hacker should know
by Anonymous Monk on Mar 17, 2006 at 18:16 UTC
|
10. Assume that the person who will have to maintain your code is even more of a NOOB than you are.
I think its reasonable to assume that the person who has to maintain your code is at least an average Perl programmer. The purpose of coding, commenting, and documentation isn’t to teach Perl to beginners.
| [reply] |
|
|
If you're in a programming shop then maybe that's a reasonable assumption. However, I work with a bunch of Telecommuncations engineers. One of the guys is pretty good with MS-Access and VB Script but I'm the only person in the group that knows anything about Perl. And I am not a programmer. The last time I did any serious programming it was on an IBM 360 in PL/1 with punch cards. I'm a general computer/network geek that got saddled with the programming tasks because I'm the resident "Data Guy". In a situation like mine, it's NOT reasonable to assume that the person who comes in behind me one day will know any more Perl that I did when I bought the Perl Bookshelf CD lo these many months ago.
When my boss asked me to take this on, the primary focus was to update some scripts that had been written by one of the IT guys who had since left the company. Trying to figure out what he was doing was next to impossible since he had written the code assuming that he would be the only person to ever maintain it - or so I assume since he didn't indent, didn't use whitespace and didn't comment anything...ever. I had to figure out what groups of programs to look at based on their file names and when they ran - "This output file has a creation time of 20:38 so I'm looking for a program that runs sometime before that."
I have to agree that comments and documentation aren't supposed to be a tutorial but it's nice when a) they exist at all and b) they are comprehensive enough that you can follow the general flow of the program without having to read the code.
Just my opinion...
Jack
| [reply] |
|
|
I think its reasonable to assume that the person who has to maintain your code is at least an average Perl programmer. The purpose of coding, commenting, and documentation isn’t to teach Perl to beginners.
That's making a vastly unwarranted assumption.
Look at the most junior person who is (not "should be, if only my boss would listen", but who is) assigned to maintain perl code: and always ensure that they will be able to read what you write.
An expert can always decipher simple code; a novice often can't decipher "clever code". Programmer time is expensive: don't waste it. Even if it takes 10% longer to simplify your code style (and it probably doesn't, if you're good): it's probably just plain cheaper to write code maintainable by the novice, unless it's going to incur a business cost in terms of performance (unlikely, but possible in some cases). Remember, senior programmer time is expensive: anything that someone lower paid can do is (a) work you're not tied up with, and (b) puts available resources to work productively.
In short, do what's right for your company: not what fits your preconceptions of what a programmer "should be". They're often not the same thing at all...
| [reply] |
|
|
I think its reasonable to assume that the person who has to maintain your code is at least an average Perl programmer. The purpose of coding, commenting, and documentation isn’t to teach Perl to beginners.
Not according to every anecdote I've run across, including those I've been personally involved in. When I was contracting at a large outsourcing firm, my maintenance tasks included SAS, PL/1, and COBOL code. I had never even seen code in any of these before. A much better assumption than assuming the person who has to maintain your code is an average Perl programmer is assuming that she|he will be trying to make sense out of code with Learning Perl in one hand and a jar of ibuprofen in the other
emc
" The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." —Nathaniel S. Borenstein
| [reply] |