On Sat, 2003-07-12 at 20:17, Mark A. Hershberger wrote:
> Ron Johnson <ron.l.johnson@cox.net> writes:
>
> > Gak!!!! I *hate* "clever" programming.
> >
> > The next person (who may not be an expert in the language) that
> > reads the code and modifies it, can do so with a higher likelihood
> > of not adding new bugs.
>
> If you have the capability to program quickly, but feel constrained
> to program slowly to accommodate some unknown future reader, you are
> only hurting yourself and whoever you are writing the code for.
No, I am creating a net benefit. As soon as I had to read my own
code, 6 months and 3 projects after I last thought about it, I cursed
myself for being "clever".
Now, I bend my cleverness towards writing (1) readable, (2) simple,
(3) short code. It's quite doable, and someone who has to add
functionality doesn't have to undo "clever code" to make the new
requirements fit the old code.
> Further, if you have to hire someone to maintain code, you had better
> hire a competent person, or you don't get my sympathy.
Well, duh.
> By the way, The best book for understanding Perl Idioms (what you call
> "clever" programming) is Effective Perl Programming. At under 250
> pages, it is relatively thin.
>
> Highly recommended.
I'll check it out. Is it written for non-Perl-newbies?
> >> Perl assumes you are reasonably intelligent.
> >
> > That is incredibly condescending.
> >
> > They may assume that humans are fallible, but really, what language
> > *really* assumes that you are stupid?
>
> I can be condescending without meaning to. I do get frustrated,
> though, by these arguments about Perl enabling un-maintainable code.
It's the programmer's attitude, not the language, that makes
something unmaintainable. However, any language (C is a prime
example) that hands you tequila and a gun, and takes your shoes
and pants off, should be used with circumspection.
For example, we developed a customer service app. Purely record
oriented, no "bit fiddling". But, some brainless manager said,
"C is portable, use it!" Of course, we then went on to use dozens
of VMS system calls and now the code is as portable as a granite
mountain.
And... there's billions of malloc(sizeof())s, memcpy(sizeof())s and
free()s cluttering up the code. Total waste. COBOL, DEC BASIC (a
very structured language) and even FORTRAN would have been excellent
choices. But we had to use C, and thus a good proportion of the
bugs were related to field overflows, null terminations, etc.
> If you or your programmer creates unmaintainable code, you have a
> problem.
How can I disagree?
> If you or your programmer doesn't understand the language being used,
> you've got a problem.
Some understand "the language" better than others.
> I wouldn't hire a newbie Python programmer to maintain my code, so
> why should I feel sympathy for someone who hires an incompetent Perl
> programmer?
>
> I know quite a few extremely competent Perl programmers.
Ok, hire all Perl Wizards. Then, when you leave (for whatever
reason), and, somehow, a competent non-Wizard somehow gets hired,
he's stumped, and, under pressure to make the changes, does what
looks right, and a subtle bug gets introduced
> I've also heard people say over and over again that they weren't
> capable of maintaining their own code. That reflects poorly on the
> programmer rather than the language.
Given enough time, anyone can re-analyze code and make the changes.
Since most programmers are under time constraints, it is best to
write the code clearly the 1st time. Part of "writing code clearly
the 1st time" is judicious use of "cleverness".
-- +-----------------------------------------------------------+ | Ron Johnson, Jr. Home: ron.l.johnson@cox.net | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | | | | 4 degrees from Vladimir Putin +-----------------------------------------------------------+ ___________________ Nolug mailing list nolug@nolug.orgReceived on 07/12/03
This archive was generated by hypermail 2.2.0 : 12/19/08 EST