Date: Fri, 22 Jun 2001 21:05:55 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Anton Berezin <tobez@tobez.org> Cc: Terry Lambert <tlambert@primenet.com>, Dag-Erling Smorgrav <des@ofug.org>, j mckitrick <jcm@FreeBSD-uk.eu.org>, freebsd-chat@FreeBSD.ORG Subject: Re: most complex code in BSD? Message-ID: <3B3415A3.5665B746@mindspring.com> References: <20010622232942.A53155@heechee.tobez.org> <200106222147.OAA28698@usr06.primenet.com> <20010623001612.C53155@heechee.tobez.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Anton Berezin wrote: > I disagree with this opinion. Like any other language, Perl has a > number of idiomatic ways of doing things. Such idioms are immediately > recognized (and used) by any programmer who knows the language. The > problem with Perl is that the sheer number of these idioms is larger > than in the majority of other languages. This leads to a fact, that > Perl itself is a big language, and therefore it is difficult to learn > Perl well. This also means that people who do not know Perl enough, > or at all, get an impression that Perl is a mess, a language without > any style, a write-only language. I've written my share of well-commented perl code, and maintained other perl code. Any new code uses the "idioms" in several of the books -- not the ones Larry Wall wrote to demonstrate the zillion ways you can do something. Old code is always written in the idiom of the program being maintained, if it can be discerned at all. Most perl programs I have seen, even trivial ones, are riddled with bugs. This includes the ETRN script that ships with sendmail, which is probably one of the most heavily used scripts I'm aware of (it fails to time out certain operations). The major problem is that it's considered easy to write programs in perl -- and people who take the easy way out are the type of people who tend to think that it's easier to not comment their code. The perl language is useful for little scripts that do not need to be maintained -- glue code for administrative tasks, etc. -- but for larger projects, maintainability becomes the primary requirement. I don't disagree that perl _can_ be written to be easily maintainable, but it often isn't written in such a way to facilitate maintenance by inexpensive people. An expert in perl could probably read any perl code, no problem; but that is a very steep barrier for a definition of "enough". I personally have no problem understanding or doing anything in perl, thanks in part to tutelage by people like Doug Ambrisko who are true experts, but I dislike it: it offends my aesthetic sensibilities to think that I might be writing code that is opaque to others. The only fix for this would be to pick a reference work, and then give citations for the page numbers where the "idiom" being used id documented. At least that way, you could be sure that someone with the same reference work could read the code via cross-reference. The comments are never enough -- telling them what you are doing is not the same as them being able to then understand the statement following the comment, because the language is, as you admit, very large: this translates to "no common basis for understanding the code". That's bad. > > The lack of "one true way" to do everything means that perl > > is the programming language equivalent of "Standards are > > wonderful, because there are so many to choose from". > > As with any other language, it is good to use the right tool > (the right language construct) for the job. There are just > more tools available. If I look in somone elses carefuly assembled collection of tools in their garage (i.e. their perl code), it would be nice if when they used a hammer, the thing looked like a hammer to everyone else who knew how to use tools. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B3415A3.5665B746>