|
Re^3: Thread on Joel on software forum : "I hate Perl programmers."
by BUU (Prior) on Jun 16, 2005 at 18:24 UTC
|
Just to nitpick slightly, how exactly does "idiomatic perl" make code hard to read? Isn't the definition of idomatic along the lines of "something that is easily understood"? | [reply] |
|
|
Idiomatic is using the language in the accent of the language. The problem with this is that people unfamiliar with the idiom find it difficult to understand. Consider something like a Swartzian Transform, if you arent particularly familiar with the language just seeing it is going to make a lot of people boggle.
The above might make a lot of sense to you and me, but to some non perl programmer asked to tweak your code while you are on holidy its just gibberish.
Anyway, this is probably not the best example as the ST is a fairly standard tool in the toolbox but i think you get the idea. Just think of all those times youve managed to put some very complex logic on the lhs of a for modifier using only boolean and ternary operators.
---
$world=~s/war/peace/g
| [reply]
[d/l] |
|
|
I don't speak Russian, if I visit Moscow with a tourist's
list of expressions I have no right to get pissed when I
can't understand the locals.
--
In Bob We Trust, All Others Bring Data.
| [reply] |
|
|
"Idiomatic perl" is often more like "perl that a non-expert will never be able to read." Things like map/grep tricks (Schwartzian transform, for example), lots of use of $_, typeglob manipulation, hash-slices, chaining lots of things with and/or constructs, using lots of closures... In short, things that are fine in small doses but get hard to read very quickly. Writing things out in a less compact way is usually seen as more Java/C-like and less idiomatic.
| [reply] |
|
|
Most of what you say I agree with, but I take exception to your "lots of closures" comments.
I've had to maintain code with large doses of lots of closures. Once you know the basic ideas, it is no harder than any other code.
I would draw a parallel to OO programming. If you sit someone down who doesn't understand OO and have them try to learn a large OO system, they'll be lost. Just working out the basic mechanics of where to find the method that gets called HERE (and having an idea of when it matters and when it doesn't) is going to constantly stump them. The fault is not, of course, necessarily with the OO code or design. It is that the programmer in question is lacking the mental toolbox that you need to understand OO code. (Of course it is also possible that the code and design are both terrible.)
Practical techniques that use closures are similar. When you understand, "Oh, he's building up a dispatch table" or "Oh, he's creating an iterator" then suddenly the technique scales and it isn't a problem. Of course, as with any technique, it is possible to create a real mess with closures. But it is also likely that clean code using closures will look like a mess to someone who lacks the right mental toolbox to deal with them.
Note that in both examples what is key is chunking, being able to understand what a block of code is doing so that you can know during maintainance whether you need to dig further there or look elsewhere.
| [reply] |
|
|
|
|
|
|
|
Things like map/grep tricks (Schwartzian transform, for example), lots of use of $_, typeglob manipulation, hash-slices, chaining lots of things with and/or constructs, using lots of closures...
To a Fortran IV programmer used to the 'if not ... goto ...' school of language design, 'if .. then ... else ...' could be viewed as a "trick".
At what point does a standard design feature of a language (Perl) cease to be a "trick" and start to be a feature; a normal , everyday use of the language?
In short, things that are fine in small doses but get hard to read very quickly.
I don't understand this. How does frequency of use affect the readability of a construct?
Do comments become less readable if I use too many of them?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
|
...things that are fine in small doses but get hard to read very quickly. Writing things out in a less compact way is usually seen as more Java/C-like
I'm always bemused by people who advocate making their perl code look more like C. The reason I like perl is precisely because it is not C. If you're looking for suped up C, I'd recommend looking into C++.
| [reply] |
|
|
Isn't the definition of idomatic along the lines of "something that is easily understood"?
On the contrary, it refers to something to which the meaning is not immediately obvious to those not aware of the subtext.
Definition of 'idiom': A speech form or an expression of a given language that is peculiar to itself grammatically or cannot be understood from the individual meanings of its elements, as in keep tabs on. (...) A specialized vocabulary used by a group of people; jargon: legal idiom.
Wait! This isn't a Parachute, this is a Backpack!
| [reply] |