| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Um... no.
Um... no.
Posted Oct 21, 2005 17:16 UTC (Fri) by GreyWizard (subscriber, #1026)In reply to: Technologies to Watch: A Look at Four That May Challenge Java's Development Dominance (O'ReillyNet) by philips
Parent article: Technologies to Watch: A Look at Four That May Challenge Java's Development Dominance (O'ReillyNet)
But when you come to age, when you start feeling confident in harnessing all computing power available - sandboxes are out of game.
Perhaps when *you* come of age, in addition to mastering the rules of grammar and punctuation, you'll have a chance to participate in the development of a large piece of software. You won't be using Assembly or Perl. (I'm only casually familiar with Ruby, so I'll give it the benefit of the doubt with respect to your claim that it's as brain-damaged as Perl.) You'll learn that Python provides all the features and power Perl does without the multiple personality disorder. More to the point, you'll discover that having more than one way to do everything is not so much the opposite of programming in a sandbox as it is a reliable recipe for unmaintainable code.
(Log in to post comments)
This is a practices issue
Posted Oct 22, 2005 5:15 UTC (Sat) by b7j0c (subscriber, #27559) [Link]
I hear this lameo comment again and again, and not just with reference to perl, but with C++, PL/SQL etc etc etc
So lets turn this around and ask why no one in your organization is reading code multiple times prior to delivery. Coding cabals develop memes, and unreadabiliyt typically implies a violation of style, not correctness per se. If a new coder works outside of those memes and style guidelines, you correct them early and keep moving.
Many large perl systems later, I have no problem reading a coworker's perl.
This is a tool issue
Posted Oct 22, 2005 17:40 UTC (Sat) by GreyWizard (subscriber, #1026) [Link]
I hear these "lameo" comments again and again: one can write good or bad code in any language; it's a pracitces issue; style guidelines and discipline can work around the problem. All true but irrelevant. When they get to choose, smart programmers select the best tool available. They don't choose arbitrarily on the grounds that they can achieve the same result by applying extra discipline. The best tool is a programming language that makes the right thing to do simple and as obvious as possible -- not to protect poor programmers from their limitations but to free good programmers from distractions. Extra features have a cost in terms of environment complexity and comprehension that is worth paying only if they actually provide extra power.
Most programming languages have vestigal features but Perl is unusual because the culture around it elevates them to virtues. There may be more than one way to do it, but in fact there is only one appropriate way to do it in any particular circumstance. You implicitly acknowledge this by suggesting that there is a correct style for each "cabal" of programmers. Why should you have to enforce style guidelines? That's work the language should do for you.
No one is reading code multiple times prior to delivery in my organization because everyone is too busy solving actual customer problems. Rather than genuflecting to a priesthood of style or waxing eloquent about memes we choose tools that don't burden us with needless complexity. Because of that we can deliver the same quality of work faster or higher quality work on the same deadline compared to our competitors. If you work for one of them keep your resume up to date.
This is a tool issue
Posted Oct 22, 2005 18:51 UTC (Sat) by b7j0c (subscriber, #27559) [Link]
>> Most programming languages have vestigal features but Perl is unusual>> because the culture around it elevates them to virtues.
this talks well, but where's the beef? what are these vestigal features of perl? "TMTOWTDI" and "vestigal" should not be conflated.
>> but in fact there is only one appropriate way to do it in any particular
>> circumstance.
then java is for you.
>> Why should you have to enforce style guidelines? That's work the
>> language should do for you.
so following your line of reasoning the syntax should dictate the one true sequence of glyphs to describe each code segment....well, once gain, java is for you. its a bondage language. there are very strict rules, they sometimes don't make sense, but they are consistent to the point of obstinance, as opposed to c++, which is multi-paradigm by design and enforces paradigms only when it makes sense, and often at coder discretion (you-pay-for-only-what-you-use, another canon of c++ design).
>> No one is reading code multiple times prior to delivery in my
>> organization because everyone is too busy solving actual customer
>> problems.
no one cares why you ignore engineering practices. code review is an essential part of delivering quality. this is invariant. in a decade my engineering organization has gone from 10 to 4000. you don't get there by trusting everyone's code.
Reading Comprehension
Posted Oct 22, 2005 21:29 UTC (Sat) by GreyWizard (subscriber, #1026) [Link]
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.
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.