martelli@cadlab.sublink.ORG (Alex Martelli) (05/05/91)
Somebody (who may not wish to be identified) mailed me a set of questions
whose answers may be of interests to others who are eyeing comp.lang.perl
and wondering if they should jump right in, or give it a miss. So I
though I would answer by posting, so that not only the original asker,
but others could learn of my opinion.
:Pardon me, but as someone unbiased who has jumped into Perl, what do you
:think about it. What's it good for?
It is an extremely powerful, rich and versatile language.
:Can a non-C programmer use it day-in day-out practically speaking?
Yes, I found out there are several 'styles' for using Perl, and while one
or another might be more suited to specific tasks, any 'style' is usable.
That is, you can write perl that looks just like C with several more
powerful constructs, OR you can write perl that looks just like the usual
sh/awk/sed/whatever mixture with better "glue", or of course you can grow
into its own peculiar "native" style, which is partly a mix and party more
powerful than either. In any case, a non-C-programmer with sh/awk exposure
can quickly pick up at least the subset of perl that will allow him/her to
do the same things, and a bit more, and often more comfortably.
:What can't it do?
I have not found any day-to-day programming task that perl can't do. I guess
I never tried to use it to replace SQL queries, or to do graphics, and I do
not plan to try; startup overhead of even a trial script may make it totally
unsuited to trivial utilities best handled by a two-line shell script, or to
those best handled by a ten-line C quickie; and I guess throughput for CPU
bound jobs would be far too slow to think of replacing such 'heavy' C or
Fortran jobs, although I have never tried to benchmark that. But those are
at worst things it SHOULD not do, not things it CAN'T do - for a one-time job,
the coding productivity gain might make it worthwile to pay the runtime price!
:All things considered in a database applications environment under Unix, do
:you recommend everyone, one person or no one learning it?
I recomment everyone should learn it. There are always a million jobs of
data massaging and information extraction, the kinds I used to do in REXX on
an IBM mainframe, then in {,n,g}awk, or in Icon, etc., for which perl is just
THE most suitable tool - you'll gain a factor of two in coding productivity
over gawk, I believ offhande, for average tasks.
:How hard is it to learn compared to other languages?
Easy to get started - a VERY small subset already allows you do express very
substantial tasks - QUITE hard to master, since it's so rich and, at times,
subtle (one day I'll *understand* the *name=something stuff, but I'm still
a LONG way from that, for example!). For somebody starting with familiarity
in sh, awk, sed, tr, etc, and C, like I did, the task is made easier. For
somebody who has never programmed before, Rexx may be an easier beginner's
language - more word-oriented, less funny-squiggle symbols... or ABC...
:And most important, can I maintain somebody else's Perl code easily, unlike C?
No, if you can't maintain a person's code in C, I doubt you'll have much of an
advantage in maintaining Perl code. Maintenance has many dimensions to it,
and while the perl code's compactness may work in its favor, other things,
such as the many possible styles I alluded to before, and the many temptations
for "cleverness" that Perl offers, will work against it. But the main
determinant is semantics: two pieces of code performing the same complicated
job in different languages will generally not be all that different in
difficulty to comprehend them, and given perl's much higher coding productivity
it is quite likely that the Perl code will do a little bit more, since it
will have been SO easy for the programmer to roll that little extra bit in!allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (05/08/91)
As quoted from <818@cadlab.sublink.ORG> by martelli@cadlab.sublink.ORG (Alex Martelli): +--------------- | in sh, awk, sed, tr, etc, and C, like I did, the task is made easier. For | somebody who has never programmed before, Rexx may be an easier beginner's | language - more word-oriented, less funny-squiggle symbols... or ABC... +--------------- Or Python --- although I personally have problems taking seriously a language where indentation is significant. (1/2 :-) +--------------- | :And most important, can I maintain somebody else's Perl code easily, unlike C? | No, if you can't maintain a person's code in C, I doubt you'll have much of an | advantage in maintaining Perl code. Maintenance has many dimensions to it, +--------------- ...or any other language, for that matter. The language doesn't exist that can't be obfuscated, although there are languages which make it harder (i.e. Python, with that indentation-is-significant business) or easier (APL...) +--------------- | difficulty to comprehend them, and given perl's much higher coding productivity | it is quite likely that the Perl code will do a little bit more, since it | will have been SO easy for the programmer to roll that little extra bit in! +--------------- Which can be good (the programmer is less tempted to omit special cases that doen't seem to be needed but may cause things to break in the future) or bad (creeping featurism). Six on one hand, a half dozen on the other. But I use Perl because it lets me get things done quickly and easily --- the most important thing. (...now if only the load average didn't go from 0.6 to 6.0 while running my ACCELL Makefile generator in Perl....) ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH