Learning perl - for experienced programmers

[Dan Stromberg]

Hi folks.

I know a variety of languages, from assemblers to VHLL's, but I'd like to
learn at least the fundamentals of perl 5.

I'd like to find a web article, magazine article or brief book that will
provide a very dense, pithy introduction.

I don't want a bunch of long examples, which seems to rule out the black
book - I can figure out how to combine things fine, and I feel like long
examples usually get far away from the heart of matters. Just code
snippets is fine.

For example, my favorite introduction to a language was the dense
introduction to C in an appendix at the back of Andrew Tanenbaum's Minix
book - is there something like that for perl? It might even come under
the name of a reference, perhaps.

Is such a resource available?

 

[Paul Lalli]

I know a variety of languages, from assemblers to VHLL's, but I'd like to
learn at least the fundamentals of perl 5.

I'd like to find a web article, magazine article or brief book that will
provide a very dense, pithy introduction.

I suggest the following:
http://perldoc.perl.org/perlintro.html for a brief introduction to the
syntax of the language
http://perldoc.perl.org/perlretut.html for a tutorial of Regular
Expressions, which are somewhat unique to Perl, and
http://perldoc.pelr.org/perlfunc.html to have handy to look up what
functions exist (but I wouldn't recommend actually reading the whole
thing top to bottom).

Paul Lalli

 

[cartercc]

Hi folks.

I know a variety of languages, from assemblers to VHLL's, but I'd like to
learn at least the fundamentals of perl 5.

For two good, quick reads, I'd recommend the O'Reilly books, Learning
Perl and Learning Perl Objects and Modules, both by Schwartz. Each
chapter can be digested in about half an hour (for an experienced
programmer) and contains several useful exercies. Additionally, they
can be picked up used for very good prices.

In my job, I use ColdFusion, Perl, and Java. Each language has its good
uses and bad uses. Perl is very good for one off scripts of less than
25 - 50 lines. In fact, it's very, very good for that. If you're
dealing with an application of 100 lines or more that will stick around
for a while, I'd run like hell from Perl. (Within the past year, I
inherited a great mass of Perl scripts, around 70 or so, each
containing 500 or more lines of code, and it's absolutely not
maintainable, nor maintained. As it breaks, we are rewriting in
something else.)

I love Perl, but I think of it as a finely tuned sports car. If you're
hauling building materials, get a truck.

CC

 

[John Bokma]

book - is there something like that for perl? It might even come under
the name of a reference, perhaps.

Is such a resource available?

Programming Perl, 3rd edition. It's a tough read, but worth it and IMO
matches exactly your description (been there, done that, only with the
purple version).

 

[Randal L. Schwartz]

cartercc> For two good, quick reads, I'd recommend the O'Reilly books, Learning
cartercc> Perl and Learning Perl Objects and Modules, both by Schwartz. Each
cartercc> chapter can be digested in about half an hour (for an experienced
cartercc> programmer) and contains several useful exercies. Additionally, they
cartercc> can be picked up used for very good prices.

The latter is now named "Intermediate Perl". We optimized The Name That Was
Too Long To Pronounce into something much more apropos.

In addition to those, I have nearly 250 magazine articles at
http://www.stonehenge.com/merlyn/columns.html that are free for the reading.

print "Just another Perl hacker,"; # the original

 

[Matt Garrish]

For two good, quick reads, I'd recommend the O'Reilly books, Learning
Perl and Learning Perl Objects and Modules, both by Schwartz. Each
chapter can be digested in about half an hour (for an experienced
programmer) and contains several useful exercies. Additionally, they
can be picked up used for very good prices.

Might be a little too easy for an experienced programmer. It sounds
like he'd be better off jumping straight into the documentation, or
going for the Camel or Cookbook.

In my job, I use ColdFusion, Perl, and Java. Each language has its good
uses and bad uses. Perl is very good for one off scripts of less than
25 - 50 lines.

I don't follow the logic of that. It sounds like you need a lesson in
OO Perl if you can only write procedural code that can't be maintained
(and I've never heard of a language that is only good until a certain
number of lines has been passed, to be honest).

Basic design practices are basic design practices. If you'd like some
examples of hideous and unmaintainable Java code there's plenty I'm
sifting through at my current job. A language is only as bad as the
person writing it.

Consider also that to most people the benefit of perl is cpan and the
active community, and that the modules you're using to make your
scripts so short are probably many thousands of lines of maintainable
code (or not, as not everything in cpan smells like roses).

Matt

 

[David H. Adler]

Programming Perl, 3rd edition. It's a tough read, but worth it and IMO
matches exactly your description (been there, done that, only with the
purple version).

That's MAUVE, thank you very much.

dha

 

[John Bokma]

That's MAUVE, thank you very much.

http://www.answers.com/MAUVE

It certainly doesn't match the colour from the Wikipedia article though


CC0099 (too "grey)/FF0099 (too pink) [1] comes closest but that's based
on the memory I have of the book and the settings of my monitor :-D.

BTW, not saying your wrong, but names of colors, and perception of
colors is a hard thing (I often describe colors as: a kind of
purple, with some grey mixed into, and too much green, now that confuses
people).

http://www.oreilly.com/catalog/wdnut/excerpt/web_palette.html

 

[cartercc]

Might be a little too easy for an experienced programmer. It sounds
like he'd be better off jumping straight into the documentation, or
going for the Camel or Cookbook.

(1) The books are cheap. My local bookstore has a pile of the Llama
books (3ed) for under $10.00 (US). (2) They are a pretty easy
introduction for someone who already knows the questions, and is just
looking for the answers. Different people have different learning
styles. I keep a copy of the Camel book by my side when writing code,
and a copy of the other two on my bed side table for light reading
before going to sleep. And after years, I still find that they remind
me of useful things I had forgotten.

Basic design practices are basic design practices. If you'd like some
examples of hideous and unmaintainable Java code there's plenty I'm
sifting through at my current job. A language is only as bad as the
person writing it.

True, but something about Java lends itself to good engineering, and
something about Perl lends itself to bad engineering. Plus, with Java,
you can easily run javadoc and get something in a standard format.
There's probably something like that for Perl, but it's not a part of
the core language.

Consider also that to most people the benefit of perl is cpan and the
active community, and that the modules you're using to make your
scripts so short are probably many thousands of lines of maintainable
code (or not, as not everything in cpan smells like roses).

I started off by writing CGI scripts. ColdFusion is a closed,
proprietary language, to which I have a strong opposition on
philosophical grounds. However, if all you're doing is displaying
database content in web pages, ColdFusion beats Perl with one arm and
four fingers tied behind its back.

Don't get me wrong. I like Perl very much. I can't use ColdFusion (or
Java) for what I do with Perl. It's just that Perl isn't the best
solution to every conceivable problem, and you need different tools in
your toolbox to be able to solve different kinds of problems.

CC

 

[Sherm Pendley]

I know a variety of languages, from assemblers to VHLL's, but I'd like to
learn at least the fundamentals of perl 5.

I'd like to find a web article, magazine article or brief book that will
provide a very dense, pithy introduction.

You might have a look at the Camel, aka "Programming Perl".

Or, just open a terminal and run 'perldoc perl'. It's sort of a "table of
contents" for the included Perl documentation. The docs listed there are
intended to be read in order, but nothing's stopping you from skipping down
to whatever level you feel comfortable with.

If you're using ActiveState's Perl for Windows, it installs HTML-formatted
copies of the same docs, and places a shortcut to it on the Start menu.

sherm--

 

[John Bokma]

True, but something about Java lends itself to good engineering, and
something about Perl lends itself to bad engineering.

It's the person who makes the decision to do it the bad way, not the
language.

Plus, with Java,
you can easily run javadoc and get something in a standard format.
There's probably something like that for Perl, but it's not a part of
the core language.

AFAIK it is, it's called POD. And AFAIK it was there before Java was born

I started off by writing CGI scripts. ColdFusion is a closed,
proprietary language, to which I have a strong opposition on
philosophical grounds. However, if all you're doing is displaying
database content in web pages, ColdFusion beats Perl with one arm and
four fingers tied behind its back.

I doubt this

Don't get me wrong. I like Perl very much. I can't use ColdFusion (or
Java) for what I do with Perl. It's just that Perl isn't the best
solution to every conceivable problem, and you need different tools in
your toolbox to be able to solve different kinds of problems.

Yup true.

 

[John Bokma]

[ perldoc ]

If you're using ActiveState's Perl for Windows, it installs
HTML-formatted copies of the same docs, and places a shortcut to it on
the Start menu.

And it's also available in CHM format:
http://htmlhelp.berlios.de/books/chm.php (5.8.6)

 

[Matt Garrish]

(1) The books are cheap. My local bookstore has a pile of the Llama
books (3ed) for under $10.00 (US). (2) They are a pretty easy
introduction for someone who already knows the questions, and is just
looking for the answers.

But as per the request of "dense and pithy", those two don't spring to
mind. They're more the "ease your way into programming and perl" type
books that, for an experienced programmer, can be tiresome to read
(perhaps not so much the second, but certainly the llama). He seemed
pretty explicit in his question that he's not looking for the gentle
ease-you-way-in approach to perl.

Different people have different learning
styles. I keep a copy of the Camel book by my side when writing code,
and a copy of the other two on my bed side table for light reading
before going to sleep.

You and I have very different ideas of what constitutes a good light
read before bed, then... : )

True, but something about Java lends itself to good engineering, and
something about Perl lends itself to bad engineering. Plus, with Java,
you can easily run javadoc and get something in a standard format.
There's probably something like that for Perl, but it's not a part of
the core language.

You'll have to provide some explicit demonstrations of how Java lends
itself to anything if you want to convince me. I've been around the
block enough times to know there's enormous amounts of garbage Java
code out there, and that it doesn't inspire bad programmers to do
anything more than write bad Java code.

I don't magically change the way I think of coding when I start writing
Java. What I do do is alter the way I code slightly to account for how
that language is structured. Perl's OO design isn't perfect, but it is
good enough that you should be able to do just about anything you need
or would in another language. And to be honest I prefer some of the
flexibility it provides to stricter OO languages.

I'm not trying to convince you that Perl is the best language for every
problem, I'm simply pointing out that your assertion that Perl is only
good for x number of lines is naive. I have two Perl web apps, one that
exceeds 5000 lines of code in total in all the modules and the other
that's probably well over 15000, and both are incredibly easy to
maintain and extend as needed. Lines of code is not something I
consider when choosing Perl over another language (except that I can
usually write a similar application in far less than if I use Java or
C#), nor is maintenance, because if you can't write maintainable code
in one language it's unlikely you can do it in another as the
principles aren't language specific.

Matt

 

[cartercc]

I'm not trying to convince you that Perl is the best language for every
problem, I'm simply pointing out that your assertion that Perl is only
good for x number of lines is naive.

I offered my opinion. You might consider it naive. That's okay, it
doesn't bother me in the slightest.

I have two Perl web apps, one that
exceeds 5000 lines of code in total in all the modules and the other
that's probably well over 15000, and both are incredibly easy to
maintain and extend as needed.

And I have six years of Perl web apps, and I was very explicit in what
I said: if all you're doing is filling a web page with content from a
database, a special purpose tool (like ColdFusion) is ideal for the
job. I certainly wouldn't say that all web applications are the same.
I'll also confess that I have written a number of web apps in Perl that
are totally en-extensible and impossible to maintain. Writing
maintainable code takes a certain amount of experience and maturity,
and I don't think any programmer starts off with experience and
maturity.

Lines of code is not something I
consider when choosing Perl over another language (except that I can
usually write a similar application in far less than if I use Java or
C#), nor is maintenance, because if you can't write maintainable code
in one language it's unlikely you can do it in another as the
principles aren't language specific.

Why, then, do you think that Java has become so popular for big
industrial applications, in contrast to Perl? If you look at job sites
(e.g., dice.com) you can form an opinion as to which languages are
being used for what. What does the industry use Java for, and what does
it use Perl for? Some languages are better for some things, and other
languages are better for other things. I totally agree with you about
the terseness of Perl, but Java incorporates some things that appeal to
the software sweatshops (or factories, if you prefer that term) like
jar, javadoc, single inheritance, strict variable typing, different
access modifiers, etc. Yes, these things are a pain in the arse, but
being able to forward engineer from UML diagrams (for example) is a
nice thing to have in your toolkit.

I don't really disagree with anything you've said. I think an IT
professional needs to be proficient in several languages. To me, a
person that takes the position that one language is The Silver Bullet
isn't leveraging the different technologies available to him.

CC

 

[John Bokma]

Why, then, do you think that Java has become so popular for big
industrial applications, in contrast to Perl? If you look at job sites
(e.g., dice.com) you can form an opinion as to which languages are
being used for what. What does the industry use Java for, and what does
it use Perl for? Some languages are better for some things, and other
languages are better for other things. I totally agree with you about
the terseness of Perl, but Java incorporates some things that appeal to
the software sweatshops (or factories, if you prefer that term) like
jar, javadoc, single inheritance, strict variable typing, different
access modifiers, etc.

My oh my, weren't you the one who wasn't aware of POD? If you think that
"the industry" selects a language because it's well fitted for the tasks
at hand you are more then naive.

 

[David H. Adler]

That's MAUVE, thank you very much.

http://www.answers.com/MAUVE

It certainly doesn't match the colour from the Wikipedia article though


CC0099 (too "grey)/FF0099 (too pink) [1] comes closest but that's based
on the memory I have of the book and the settings of my monitor :-D.

BTW, not saying your wrong, but names of colors, and perception of
colors is a hard thing (I often describe colors as: a kind of
purple, with some grey mixed into, and too much green, now that confuses
people).

http://www.oreilly.com/catalog/wdnut/excerpt/web_palette.html

My fingers played a trick on me. I meant "magenta". And before you tell
me *that*'s wrong too, my memory is that O'Reilly tended to
differentiate between the first two editions of the Camel/Llama by
referring to them as "magenta" and "teal".

I will, however, steadfastly maintain that the original editions were
NOT purple.

dha

 

[cartercc]

My oh my, weren't you the one who wasn't aware of POD? If you think that
"the industry" selects a language because it's well fitted for the tasks
at hand you are more then naive.

John, I don't want this to sound ugly. I had decided to ignore your
remark. I formed the conclusion that you had no idea what you were
talking about. Please let me explain myself, and then maybe you will
understand what I am talking about.

Many times, software and software products have what is called an
application programming interface, or API. The API constitutes the
public interface of the language or application. 'Interface' consists
of the properties and methods of the product, that is, the public and
private members of the product, the public and private methods of the
interface, the different kinds of constructors, detailed information
including since, deprecated, version, return values, parameters, and so
on. This is what is known as external documentation. For the Java API,
see http://java.sun.com/reference/api/.

There is also what is called internal documentation. Internal
documentation consists of the programmer written comments embedded with
within the source code, or contained in separate text or README files
included with the application. Both external and internal documentation
are important, because they serve different purposes. The overall
purpose is the same, to document the code, but an API is more specific
and standardized than POD.

The javadoc utility produces a Java API of your code. You can write an
application, run javadoc, and WITHOUT ANY FURTHER EFFORT ON THE
PROGRAMMER'S PART have a full API of your application. POD is an HTML
type of utility which, by contrast with javadoc, requires the
programmer to document his code. As an example, with a Perl module, the
programmer typically would have his lexical variables at the top of the
script, the dispatch logic next, and his user defined subs at the
bottom. The programmer, in order to use POD, would have to separately
document each variable and each sub. By contrast, in a Java pacakge,
the utility produces documentation which describes each variable, its
access and type, each method, its type and return value, the
constructors of the instantiable classes, and so on.

I am very well aware of the Perl criticisms of a compiled, strongly
typed language like Java, or C, or C++, and you don't have to lecture
me about these differences. My point is that Java and Perl are
different languages, with different advantages and weaknesses. In some
ways, Perl is superior to Java, and in other ways, Java is superior to
Perl. One of the advantages to Java is the utility to automatically
generate an API with no effort on the programmer's part. Yes, I know
that the programmer is required to declare the type of the variable or
reference, and the type and return values of each method, can only
return one value from a method, and so on. I'm not going to takes sides
in this debate. I think the effort is similar, Java requires it up
front while Perl leaves the programmer free to neglect it if he
chooses.

"The industry" selects, usually, the best tools at hand for any
particular job. "The industry" is not a monolithic structure, but the
sum of all the parts. I am part of the industry, you are part of the
industry, we all are part, just like we are all part of "the economy."
Just as you can look at all the individual transactions and talk about
"the economy" or "the market" you can look at all the software
architects, engineers, and programmers, and make statements about "the
industry."

I live in an area where there are a lot of technology jobs in banking
and insurance. Many of these use COBOL. The schools, colleges, and
universities in my area still churn out COBOL programmers. I know COBOL
programmers, and even though I don't know COBOL, I understand why 'the
industry' uses COBOL -- it's the best tool for the job at hand. Not
Java, and not Perl.

I hope I didn't insult you by this explanation. If you don't know about
APIs, you might want to investigate. One last thing -- Java has tools
that let you draw UML diagrams, such as class diagrams, and generate
code. I teach OO programming in Java at a local university (hence my
verbosity) and I see a lot of harm in using these kinds of tools in
learning a language. I see a lot of managers who have been taught OO
development, but don't have the programming background to understand
the nuts and bolts. HOWEVER, these kinds of foward engineering tools
(as in Rational Rose or Eclipse, for example) can be great timesavers
for the journeyman programmer. With Perl, I think this kind of tool
would be impossible, because of the free from nature of the language. I
don't see this as either a detriment or an advantage, but simply an
aspect of the tool which makes it better or worse for some particular
job.

Best, Charles Carter.

 

[anno4000]

[big snip, just picking one paragraph]

I live in an area where there are a lot of technology jobs in banking
and insurance. Many of these use COBOL. The schools, colleges, and
universities in my area still churn out COBOL programmers. I know COBOL
programmers, and even though I don't know COBOL, I understand why 'the
industry' uses COBOL -- it's the best tool for the job at hand. Not
Java, and not Perl.

No, COBOL is the best tool for no job on earth except for maintaining
COBOL programs.

For many years, COBOL was the *only* tool for certain IO-heavy and
table-oriented tasks that come up in financial and administrative
computing. At least it was the only COmmon Business Oriented
Language and claimed to be specially fit for these purposes. People
believed it and developed large code bases in COBOL. In reality,
the FORTRAN of the day would have worked as well, if not better.

Now people are stuck with it. The language offers nothing that modern
languages don't implement in much more convenient ways.

For similar reasons the scientific community is largely still using
and maintaining FORTRAN, not because anyone believes it is the *best*
language but because for a long time it was *the* language.

Anno

 

[Peter J. Holzer]

Many times, software and software products have what is called an
application programming interface, or API. The API constitutes the
public interface of the language or application. 'Interface' consists
of the properties and methods of the product, that is, the public and
private members of the product, the public and private methods of the
interface, the different kinds of constructors, detailed information
including since, deprecated, version, return values, parameters, and so
on.

Correct so far.

This is what is known as external documentation.

Not to anyone I've ever talked to. The documentation is a description of
the API, not the API itself. The method "boolean delete()" of the class
java.io.File is part of of the J2SE core API. The text "boolean
delete(): Deletes the file or directory denoted by this abstract
pathname." is not part of the API, it is part of the description (or, in
this case, specification) of the API. You can change the description
without changing the API (or vice versa).

For the Java API, see http://java.sun.com/reference/api/.

You will notice that it says "This document is the API specification of
...." not "This document is the API of ..."

There is also what is called internal documentation. Internal
documentation consists of the programmer written comments embedded with
within the source code, or contained in separate text or README files
included with the application. Both external and internal documentation
are important, because they serve different purposes. The overall
purpose is the same, to document the code, but an API is more specific
and standardized than POD.

The javadoc utility produces a Java API of your code. You can write an
application, run javadoc, and WITHOUT ANY FURTHER EFFORT ON THE
PROGRAMMER'S PART have a full API of your application.

I have an API by coding it. What Javadoc does - and this is very useful
- is creating a framework of documentation from the source code, by
simply listing all the fields and methods of the class.

POD is an HTML type of utility which, by contrast with javadoc,
requires the programmer to document his code.

I strongly debate that Javadoc doesn't require the programmer to
document his code. It can extract some interesting facts about the API
from the source code (such as parameters and return type of methods or
the super class of a class), but that's not much more than you can get
with grep. The most interesting questions ("what does it do?" and "why
does it do that?") have to be documented by the programmer.

What Javadoc does very well (and pod doesn't do at all) is that it makes
it glaringly obvious if the programmer neglected to document something.
There's a big empty rectangle in his manager's browser, and the manager
will say to the programmer "Fill this rectangle, or you will be fired."

"The industry" selects, usually, the best tools at hand for any
particular job.

I don't believe this. "The industry" seldom selects the best tools. It
selects tools which are good enough and require little change.

As to why Java was widely accepted, I don't think it was because it was
the best tool for any particular job. I believe some of the reasons
were:

* It was touted as a simpler version of C++. C++ was already used a lot,
so that was little change.

* It promised platform independence.

* Applets were seen as possibility to distribute feature-rich
applications to users over the web.

* There was a big player (Sun) behind it. A respectable company, not
some long-haired academic.

* It's a statically typed language. Statically typed languages are seen
as more professional than dynamically typed languages. In any case,
"the industry" is used to them (COBOL, FORTRAN, Pascal, C, C++, ...)

* It has separate compiler/interpreter stages: You can deliver some
binary ".class" files to your customers and don't have to show them
the source code. Just like you delivered binary executables and
libraries from your C programs.

hp

 

[cartercc]

I strongly debate that Javadoc doesn't require the programmer to
document his code. It can extract some interesting facts about the API
from the source code (such as parameters and return type of methods or
the super class of a class), but that's not much more than you can get
with grep. The most interesting questions ("what does it do?" and "why
does it do that?") have to be documented by the programmer.

I certainly didn't mean to imply that a programmer shouldn't document
his code. I believe strongly that a programmer should document his
code. I faithfully document my code, and I agree that the 'why' is the
most important of all. 'What' is not always obvious from the code, and
that should be documented as well.

What Javadoc does very well (and pod doesn't do at all) is that it makes
it glaringly obvious if the programmer neglected to document something.
There's a big empty rectangle in his manager's browser, and the manager
will say to the programmer "Fill this rectangle, or you will be fired."

I'd phrase this a little differently. javadoc builds a framework within
which the programmer can document his code. It DOES NOT replace
internal documentation, or supplement internal documentation, but
fulfills a different purpose. When coding, which would you really
rather have at hand, the language API or a series of textual
explanations on the Active State variety? (I confess that about 75% of
my Perl programming is on Windows, but that is dictated by the users I
support, not by my preference, so I use Active State very heavily.)

I don't believe this. "The industry" seldom selects the best tools. It
selects tools which are good enough and require little change.

The word 'best' has many definitions. Being good enough and not subject
to change may make a technology 'best' as well as being free or being
supported by a big company. Actually, saying that 'the industry'
selects the 'best' tool is a little tautological, as you can define
'best' by what 'the industry' selects.

As to why Java was widely accepted, I don't think it was because it was
the best tool for any particular job. I believe some of the reasons
were:

* It was touted as a simpler version of C++. C++ was already used a lot,
so that was little change.

* It promised platform independence.

* Applets were seen as possibility to distribute feature-rich
applications to users over the web.

* There was a big player (Sun) behind it. A respectable company, not
some long-haired academic.

Or a long-haired non-academic.

* It's a statically typed language. Statically typed languages are seen
as more professional than dynamically typed languages. In any case,
"the industry" is used to them (COBOL, FORTRAN, Pascal, C, C++, ...)

* It has separate compiler/interpreter stages: You can deliver some
binary ".class" files to your customers and don't have to show them
the source code. Just like you delivered binary executables and
libraries from your C programs.

You forgot to mention security. I agree with everything you said about
Java. You can also make a similar list for Perl. The solution is to be
able to use a number of different technologies and choose the best one
for the job.

CC