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 systems. 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 software foundations. 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 making mistakes. 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 Compared

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.
• •

Cousins: csh, Visual Basic, and Javascript. Characteristics: 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 sed. 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
o Perl vs. Javascript. Perl and Javascript have a similar "C" like favor. Both have an object oriented programming style (a new addition of Perl.) 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 "C." 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 withstanding.