Reading Comprehension [LWN.net]

Reading Comprehension

Posted Oct 23, 2005 23:00 UTC (Sun) by ncm (subscriber, #165)
In reply to: Reading Comprehension by b7j0c
Parent article: Technologies to Watch: A Look at Four That May Challenge Java's Development Dominance (O'ReillyNet)

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.

(Log in to post comments)

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.