History of Perl
o PERL = Practical Extraction and Report Language
o PERL = Pathologically Eclectic Rubbish Lister
o Developed in the mid-80s by Larry Wall as a replacement for an overtaxed awk.
At the time Larry Wall was trying to produce reports from Usenet-news file
o First version of Perl released to a large group of users was in 1988
o Developed a groundswell of user interest over the years.
o Remains "Freeware," but is not associated with any of the formal free UNIX
o Close association between Perl and O'Reilly and Associates. Recently released a
special version of Perl for Windows-NT
Ideology of Perl
o Perl incremental historical development parallels the way Larry Wall intended it
to be used: piecewise, rough-cut, get the job done. No extra points for elegance.
o Larry Wall's unspoken opposition: formalized abstract programming.
o Computer Science as an academic discipline has made a claim about what will
produce "better programming" (better = stable, maintainable, efficient, etc.)
Professor-types have engaged in research projects to develop programming
languages that embody abstractions.
Pascal/Modula - languages that by design prevent the programmers from
LISP/PROLOG - languages that impose on the programmer particular data
structures Object-oriented programming as a scheme to make data space
(memory) safe for everyone.
o Perl doesn't ignore better models of programming design, but it provides much
more freedom to the programmer than academics would prefer. In effect, Perl is
the teenage rebellion, to the academic establishment
o The symbol of Perl is a Camel - the analogy is quite meaningful.
o Programming abstraction is a good idea, so long as it isn't raised to ideology.
Perl is an example of a category of languages that are in between the rigor of
languages like C++ and crude scripting tools that come with for example word
processing and spreadsheet software.
o Untyped language, one variable can hold more than one kind of data
(numbers, strings, pointers).
o Dynamic memory allocation - programmer doesn't have to worry
about the size of arrays, strings, etc.
o "Interpreted" rather than complied (development cycle doesn't involve
a separate compilation process.
o Slower than dedicated development languages like "C" and "C++", but
faster than scripting tools like csh.
o "Forgiving" - instead of generating syntax errors, Perl will try to
"make sense" of incomplete code.
Comparing Perl to other UNIX tools
o Perl has most of the file and directory access abilities of "C", so that reach
files and file contents more easily that UNIX shells. The price is that the
syntax is more complex than csh, but much more forgiving than "C."
o Perl vs. sed and awk
Like sed and awk, Perl has an "internal compiler." Unlike UNIX
shells, Perl first goes through (parses) your program and optimizes it.
As a result, Perl is much faster than any shell.
Perl can open up a file and manipulate it with tools similar to "C". So
Perl can easily perform text changes that would be difficult to do in
Perl can hold the entire contents of the file in memory, so it can
perform complex or repetitive operations easily.
Comparing Perl to other web tools
Both have an object oriented programming style (a new addition of
There is sharp disagreement on important syntax. Working in both
languages will drive you nuts.
o Perl vs. Java.
Most comments above apply. Java is a structured language based
on "C++". Perl is much more lax about it's syntax.
o Perl vs. HTML
HTML is founded on paired tags; Perl uses syntax inherited from
HTML tends to only support commands with local effects. Perl
isn't limited by this restriction. Cascading Style sheets will give
HTML more global control.
When to use Perl instead of other shell scripts?
When your manager forbids it -- but do consider replacing them. Seriously, there
is considerable "establishment resistance" to Perl - Microsoft being one good
example. You may have to fight for your Perl.
One good reason is when you already have an existing application written in
another language that's (well) done, or you have an application language
specifically designed for a certain task (e.g. prolog, make).
For various reasons, Perl is probably not well suited for real-time embedded
systems, low-level operating systems development work like device drivers or
context-switching code, complex multithreaded shared-memory applications, or
extremely large applications. You'll notice that Perl is not itself written in Perl.
The native-code compiler for Perl may reduce the limitations given in the
previous statement to some degree, but understand that Perl remains
fundamentally a dynamically typed language, and not a statically typed one. You
certainly won't be chastised if you don't trust nuclear-plant or brain-surgery
monitoring code to it. And Larry will sleep easier, too -- Wall Street programs not