Thinks...
perl before swine
Thunk on or about 13th February 2004
Warning: lots of programming references.
Perl
One of my new year's resolutions was to do some more programming. I have made a good start on this one and have actually done some.
The in-house language where I work is Perl. If you have never heard of it this thinks is probably not for you, but a friend of mine named Greg Kable once described it to me as a write-only language, his point being that it is really easy to write but hell to debug. I think this is a little severe but some of it is remarkable obscure.
Going Dotty
Anyway, I haven't done a great deal of Perl programming so this has been a bit of an adventure for me. I would like the reader to consider the following (slightly edited) explanation of the range operator (".."), taken from "Programming Perl" (aka The Camel Book).
In a scalar context, .. returns a Boolean value. [...] Each [...] maintains its own Boolean state. It is false as long as its left operand is false. Once the left operand is true, the range operator stays true until the right operand is true, after which the range operator becomes false. (The operator doesn't become false until the next time it is evaluated. It can test the right operand and become false on the same evaluation as the one where it became true ... but it still returns true once). [...] The right operand is not evaluated while the operator is in the false state and the left operand is not evaluated while the operator is in the true state.
Fortunately, it gives an example:
next line if (1 .. /^$/); # skip header lines
Actually, it does make sense when you sit down and work it out, but it is typical of Perl to have a single operator to do the job of a couple of if statements. One of the systems programmers claims to have seen a loop containing a construct along the lines of:
($a .. $b) .. $c
If you can work out what that one does you're a better Perl programmer than either of us, Gunga Din. The .. operator also has a cousin called ... but you don't want to know about that. And, no, that wasn't an ellipsis.
Call yourself a programmer?
We've been looking to hire Perl programmers recently (anyone out there wanting a job?) and people who really know the language are quite a small subset of those who think they know the language. The boys over in the server team have put together a fiendish Perl test (including such beauties as the ... operator) which has given a number of prospective applicants a new perspective on their knowledge of the language.
I have been involved in the process, so I have been obliged to study the test in detail. It's a tad embarassing if you can't explain to someone why they are wrong. (When I joined the company a bit over two years ago, I failed this test comprehensively. I'm not quite sure why I'm the one with the job of marking it.)
Never mind the quality, feel the width
On the same 'square peg/round hole' principle I have been asked to take over code reviews and quality control for the current project. I suppose it sort of makes sense - you want your best Perl programmers doing the actual programming. And I'm a pretty good programmer if I'm working with something I know (like C) and the basics don't change.
Thus I have been trying to bone up on Perl coding efficiency. In C, I have a fairly good sense of what is efficient, but in C you're a lot closer to the operating system. Perl belongs to the "don't you worry about that" school of programming. A lot of the curly stuff is under the hood, and this makes it difficult to know when you are writing efficient code.
The Camel Book informs us, for example, that print with a comma operator may be faster than using string concatenation, as it doesn't have to allocate memory space for the new string. Sounds fair to me. Then it qualifies this statement On the other hand, depending on the values and the architecture, the concatenation may be faster. Try it. Gee, thanks very much.
Wrap
A rather rambling thinks this time. Put it down to today being Friday 13th. You can't be lucky every time.
Valentine's Day tomorrow. One of these days, I'm going to look up just who that man was and what made him the patron saint of the annual flower massacre. Happy Valentine's day!