Reading Comprehension [LWN.net]

Reading Comprehension

Posted Oct 22, 2005 21:29 UTC (Sat) by GreyWizard (subscriber, #1026)
In reply to: This is a tool issue by b7j0c
Parent article: Technologies to Watch: A Look at Four That May Challenge Java's Development Dominance (O'ReillyNet)

this talks well, but where's the beef? what are these vestigal features of perl? "TMTOWTDI" and "vestigal" should not be conflated.

Reading Perl Best Practices, which is chock full of descriptions of features the reader is advised never to use, might save you from making ignorant comments like this one in the future.

...well, once gain, java is for you.

Only poor reading comprehension skills could lead you to that conclusion. Let's review what I actually wrote: "Extra features have a cost in terms of environment complexity and comprehension that is worth paying only if they actually provide extra power." Does this address the issue of consistency across features in any way? No. Does it say features should impose a runtime cost even when they're not being used? No. Does it say features that provide extra power do not belong in the language? No. Quite the reverse in fact.

Take the time to read what you're responding to unless you enjoy making a fool of yourself.

no one cares why you ignore engineering practices. code review is an essential part of delivering quality. this is invariant.

While most code can benefit from peer review if the luxury of time is available, it is only actually essential for delivering high quality code when the skills of the programmers involved are weak, the tools are inferior or both. When you find your organization competing with one that puts emphasis on solving customer problems rather than dotting the i's and crossing the t's of some "engineering practices" checklist, you'll find reason to care quite a bit about why some people ignore them.

in a decade my engineering organization has gone from 10 to 4000.

That you seem to regard this as a good thing reveals much.

(Log in to post comments)

Reading Comprehension

Posted Oct 23, 2005 5:40 UTC (Sun) by b7j0c (subscriber, #27559) [Link]

>> Reading Perl Best Practices, which is chock full of descriptions of
>> features the reader is advised never to use, might save you from making
>> ignorant comments like this one in the future.

no, you claimed VESTIGIAL features of perl. this is quite different than a best practice. still awaiting an example. see, i get "reading comprehension" just fine.

>> Let's review what I actually wrote: "Extra features have a cost in terms >> of environment complexity and comprehension that is worth paying only if >> they actually provide extra power."

TMTOWTDI **IS** the power of perl. its also why perl's backwards-compatibility is well-rgarded. its why you see things likes regexes and tr exists side-by-side - perl was born out of sysadmin prgramming and was designed to migrate sh programmers. you can tell me simple flow-control reodering is a vestigial artificat but every language provides that sugar. i cannot think of one feature of perl that is completely pointless.

>> While most code can benefit from peer review if the luxury of time is
>> available, it is only actually essential for delivering high quality
>> code when the skills of the programmers involved are weak, the tools are
>> inferior or both

don't you think it would be a good idea to know what people are coding should they quit, get hit by a cement truck, or go on vacation when an emergency strikes? this is a side-effect of code review. you should drop your position against peer review, it is untenable. the bridge you crossed today had its design peer reviewed. the structure and effects of the chemical compounds in your medicines were peer reviewed. its what engineers do.

>> >> in a decade my engineering organization has gone from 10 to 4000.

>> That you seem to regard this as a good thing reveals much.

it reveals a few things, like we built a service that has incredible demand (incidentally using a LOT of perl...gee, how did we do that? didn't we know perl was garbage?). and we were rewarded for it.

Reading Comprehension

Posted Oct 23, 2005 23:00 UTC (Sun) by ncm (subscriber, #165) [Link]

I'm afraid you guys are both wrong, albeit a little big right. Code review really is important, but it really isn't done where it's needed most -- not even, I'll bet, in b7j0c's organization. Perl really is a horrendous language for anything that's going to be looked at by somebody else (or, indeed, ever again). That b7j0c has put years into learning every nook and cranny of Perl doesn't change that any normal engineer probably can't read his code -- but probably could read GreyWizard's Python code.

Would b7j0c's employer get along with many fewer than 4000 IT staff if their code wasn't Perl? We don't get to do the experiment, but it would be hard to believe his employer's problems are bigger than Google's, and Google does. However, Python is only incrementally better than Perl for big projects. Like Perl, it's hundreds of times slower than need be, but more importantly, it offers little help in managing the complexity of a big project.

Python, Perl, PHP, and Ruby often beat Java anyway because (a) Java's notion of such help is actually a hindrance, (b) the culture around Java specifically encourages and rewards gross inefficiency and extravagant complexity, (c) because Java's runtime apparatus squanders its potential speed advantage compensating for lost cache locality, and (d) because most projects really aren't, or shouldn't be, as big as the Java Full Employment Policy leads people who use and manage Java development to pretend.

Reading Comprehension

Posted Oct 24, 2005 4:32 UTC (Mon) by b7j0c (subscriber, #27559) [Link]

>> Perl really is a horrendous language for anything that's going
>> to be looked at by somebody else (or, indeed, ever again).

i am already dealing with one poster providing unsubstantiated claims about perl. if you want to chime in, provide something concrete, and don't go digging up perl golf results or obfuscation contests, every language is subject to willful syntax vandalism.

as it stands i also code daily in php (vastly inferior to perl, which it is trying to ape in many ways), and ruby (syntactically sweet, but lacking a CPAN equivalent), so i don't feel i'm speaking from a perl penalty box.

i'm not a complete fanboi though, as you will see from this thread i am highly critical of the perl6 process.

Clarification

Posted Oct 25, 2005 2:41 UTC (Tue) by GreyWizard (subscriber, #1026) [Link]

Code review really is important, but it really isn't done where it's needed most

Whether review is important depends on context. For example, when doing innovative work in a new market code quality is less important than rapid development. Customers are more willing to tolerate faults and aren't quite sure what they want so much of the code will need to be discarded as requirements become more clear. Time spent perfecting it before then is wasted. As a project matures the balance changes of course. Review is one effective tool among many for improving code quality. Nevertheless the claim that high quality code cannot be produced without review is false in general. (You didn't make that claim but it was what I was responding to.)

With regard to the complexity of big projects, what is it you believe Python lacks? Bruce Eckel seems to disagree: "Python [is] a language which can build large, complex systems [...]". Large, complex and successful projects such as Zope must also be explained away.

Reading Comprehension

Posted Oct 29, 2005 15:37 UTC (Sat) by rwmj (subscriber, #5474) [Link]

I suppose I ought to inject a bit of fact into this discussion.

I used to work in a Perl shop[1], and we did code reviews regularly -
I conducted them usually twice a week. We rarely had a problem
with the code: all code had warnings and tainting and "use strict"
turned on. People were discouraged from deliberately writing
obfuscated code - but that's just standard practice in any
organisation worth anything. Everyone there was to some degree
able or expert in Perl.

Reading and reviewing other peoples' Perl was not a problem I
can recall having. Figuring out logical bugs in the code was
the hard issue, and that'd be just the same in any language.

Rich.

[1] http://www.schoolmaster.net/ - many tens-to-hundreds of thousands of lines of Perl code.

Still no comprehension

Posted Oct 25, 2005 2:01 UTC (Tue) by GreyWizard (subscriber, #1026) [Link]

no, you claimed VESTIGIAL features of perl. this is quite different than a best practice. still awaiting an example. see, i get "reading comprehension" just fine.

Do you now? Then I suppose your inability to understand that aspects of a language best practices recommend avoiding entirely are vestigial almost by definition must stem from a stunning lack of common sense instead. And no, I'm not going to do your homework by giving examples. Educating yourself about Perl is your own responsibility and anyway I'm not interested in reading your dim witted excuses on a feature by feature basis.

its also why perl's backwards-compatibility is well-rgarded.

Backward compatibility is available in almost every language and is entirely irrelevant to this discussion.

don't you think it would be a good idea to know what people are coding should they quit, get hit by a cement truck, or go on vacation when an emergency strikes?

When working with a small team of skilled programmers using a language that facilitates clear code I have no trouble picking up where someone else left off.

you should drop your position against peer review, it is untenable.

What position against peer review would that be? I said, "While most code can benefit from peer review if the luxury of time is available, [...]" which is in fact praise of peer review. Your comments are more evidence of your lack of reading comprehension skills. Like many good things peer review has a cost in terms of developer attention that is often but not always worth paying. Choosing a cluttered programming language also has a cost but yields no benefit. Resources not spent compensating for a bad choice there can be applied to increasing code quality, shipping on a shorter deadline or some combination in between.

using a LOT of perl...gee, how did we do that?

By working harder, not smarter. A language less inclined to distract you would have allowed you to accomplish more. Also, you were lucky enough not to have competition wielding more effective tools. You say working with 3,999 like minded people is a reward? Clearly your lack of common sense serves you well as a defense mechanism.