Subject: Perl FAQ part 1 of 0..9: General Questions [Periodic Posting]
From: Tom Christiansen <[email-masked]>
Date: 17 Mar 1997 23:04:10 GMT
Newsgroups: comp.lang.perl.misc,comp.lang.perl.announce

NAME
    perlfaq1 - General Questions About Perl ($Revision: 1.10 $)

DESCRIPTION
    This section of the FAQ answers very general, high-level
    questions about Perl.

  What is Perl?

    Perl is a high-level programming language with an eclectic
    heritage written by Larry Wall and a cast of thousands. It
    derives from the ubiquitous C programming language and to a
    lesser extent from sed, awk, the Unix shell, and at least a
    dozen other tools and languages. Perl's process, file, and
    text manipulation facilities make it particularly well-suited
    for tasks involving quick prototyping, system utilities,
    software tools, system management tasks, database access,
    graphical programming, networking, and world wide web
    programming. These strengths make it especially popular with
    system administrators and CGI script authors, but
    mathematicians, geneticists, journalists, and even managers
    also use Perl. Maybe you should, too.

  Who supports Perl?  Who develops it?  Why is it free?

    The original culture of the pre-populist Internet and the
    deeply-held beliefs of Perl's author, Larry Wall, gave rise to
    the free and open distribution policy of perl. Perl is
    supported by its users. The core, the standard Perl library,
    the optional modules, and the documentation you're reading now
    were all written by volunteers. See the personal note at the
    end of the README file in the perl source distribution for
    more details.

    In particular, the core development team (known as the Perl
    Porters) are a rag-tag band of highly altruistic individuals
    committed to producing better software for free than you could
    hope to purchase for money. You may snoop on pending
    developments via news://genetics.upenn.edu/perl.porters-gw/
    and http://www.frii.com/~gnat/perl/porters/summary.html.

    While the GNU project includes Perl in its distributions,
    there's no such thing as "GNU Perl". Perl is not produced nor
    maintained by the Free Software Foundation. Perl's licensing
    terms are also more open than GNU software's tend to be.

    You can get commercial support of Perl if you wish, although
    for most users the informal support will more than suffice.
    See the answer to "Where can I buy a commercial version of
    perl?" for more information.

  Which version of Perl should I use?

    You should definitely use version 5. Version 4 is old,
    limited, and no longer maintained. Its last patch (4.036) was
    in 1992. The last production release was 5.003, and the
    current experimental release for those at the bleeding edge
    (as of 27/03/97) is 5.003_92, considered a beta for production
    release 5.004, which will probably be out by the time you read
    this. Further references to the Perl language in this document
    refer to the current production release unless otherwise
    specified.

  What are perl4 and perl5?

    Perl4 and perl5 are informal names for different versions of
    the Perl programming language. It's easier to say "perl5" than
    it is to say "the 5(.004) release of Perl", but some people
    have interpreted this to mean there's a language called
    "perl5", which isn't the case. Perl5 is merely the popular
    name for the fifth major release (October 1994), while perl4
    was the fourth major release (March 1991). There was also a
    perl1 (in January 1988), a perl2 (June 1988), and a perl3
    (October 1989).

    The 5.0 release is, essentially, a complete rewrite of the
    perl source code from the ground up. It has been modularized,
    object-oriented, tweaked, trimmed, and optimized until it
    almost doesn't look like the old code. However, the interface
    is mostly the same, and compatibility with previous releases
    is very high.

    To avoid the "what language is perl5?" confusion, some people
    prefer to simply use "perl" to refer to the latest version of
    perl and avoid using "perl5" altogether. It's not really that
    big a deal, though.

  How stable is Perl?

    Production releases, which incorporate bug fixes and new
    functionality, are widely tested before release. Since the
    5.000 release, we have averaged only about one production
    release per year.

    Larry and the Perl development team occasionally make changes
    to the internal core of the language, but all possible efforts
    are made toward backward compatibility. While not quite all
    perl4 scripts run flawlessly under perl5, an update to perl
    should nearly never invalidate a program written for an
    earlier version of perl (barring accidental bug fixes and the
    rare new keyword).

  Is Perl difficult to learn?

    Perl is easy to start learning -- and easy to keep learning.
    It looks like most programming languages you're likely to have
    had experience with, so if you've ever written an C program,
    an awk script, a shell script, or even an Excel macro, you're
    already part way there.

    Most tasks only require a small subset of the Perl language.
    One of the guiding mottos for Perl development is "there's
    more than one way to do it" (TMTOWTDI, sometimes pronounced
    "tim toady"). Perl's learning curve is therefore shallow (easy
    to learn) and long (there's a whole lot you can do if you
    really want).

    Finally, Perl is (frequently) an interpreted language. This
    means that you can write your programs and test them without
    an intermediate compilation step, allowing you to experiment
    and test/debug quickly and easily. This ease of
    experimentation flattens the learning curve even more.

    Things that make Perl easier to learn: Unix experience, almost
    any kind of programming experience, an understanding of
    regular expressions, and the ability to understand other
    people's code. If there's something you need to do, then it's
    probably already been done, and a working example is usually
    available for free. Don't forget the new perl modules, either.
    They're discussed in Part 3 of this FAQ, along with the CPAN,
    which is discussed in Part 2.

  How does Perl compare with other languages like Java, Python, REXX, Scheme, or Tcl?

    Favorably in some areas, unfavorably in others. Precisely
    which areas are good and bad is often a personal choice, so
    asking this question on Usenet runs a strong risk of starting
    an unproductive Holy War.

    Probably the best thing to do is try to write equivalent code
    to do a set of tasks. These languages have their own
    newsgroups in which you can learn about (but hopefully not
    argue about) them.

  Can I do [task] in Perl?

    Perl is flexible and extensible enough for you to use on
    almost any task, from one-line file-processing tasks to
    complex systems. For many people, Perl serves as a great
    replacement for shell scripting. For others, it serves as a
    convenient, high-level replacement for most of what they'd
    program in low-level languages like C or C++. It's ultimately
    up to you (and possibly your management ...) which tasks
    you'll use Perl for and which you won't.

    If you have a library that provides an API, you can make any
    component of it available as just another Perl function or
    variable using a Perl extension written in C or C++ and
    dynamically linked into your main perl interpreter. You can
    also go the other direction, and write your main program in C
    or C++, and then link in some Perl code on the fly, to create
    a powerful application.

    That said, there will always be small, focused, special-
    purpose languages dedicated to a specific problem domain that
    are simply more convenient for certain kinds of problems. Perl
    tries to be all things to all people, but nothing special to
    anyone. Examples of specialized languages that come to mind
    include prolog and matlab.

  When shouldn't I program in Perl?

    When your manager forbids it -- but do consider replacing them
    :-).

    Actually, one good reason is when you already have an existing
    application written in another language that's all done (and
    done well), 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 new 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 chastized 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. :-)

  What's the difference between "perl" and "Perl"?

    One bit. Oh, you weren't talking ASCII? :-) Larry now uses
    "Perl" to signify the language proper and "perl" the
    implementation of it, i.e. the current interpreter. Hence
    Tom's quip that "Nothing but perl can parse Perl." You may or
    may not choose to follow this usage. For example, parallelism
    means "awk and perl" and "Python and Perl" look ok, while "awk
    and Perl" and "Python and perl" do not.

  Is it a Perl program or a Perl script?

    It doesn't matter.

    In "standard terminology" a *program* has been compiled to
    physical machine code once, and can then be be run multiple
    times, whereas a *script* must be translated by a program each
    time it's used. Perl programs, however, are usually neither
    strictly compiled nor strictly interpreted. They can be
    compiled to a bytecode form (something of a Perl virtual
    machine) or to completely different languages, like C or
    assembly language. You can't tell just by looking whether the
    source is destined for a pure interpreter, a parse-tree
    interpreter, a byte-code interpreter, or a native-code
    compiler, so it's hard to give a definitive answer here.

  What is a JAPH?

    These are the "just another perl hacker" signatures that some
    people sign their postings with. About 100 of the of the
    earlier ones are available from
    http://www.perl.com/CPAN/misc/japh .

  Where can I get a list of Larry Wall witticisms?

    Over a hundred quips by Larry, from postings of his or source
    code, can be found at http://www.perl.com/CPAN/misc/lwall-
    quotes .

  How can I convince my sysadmin/supervisor/employees to use version (5/5.004/Perl instead of some other language)?

    If your manager or employees are wary of unsupported software,
    or software which doesn't officially ship with your Operating
    System, you might try to appeal to their self-interest. If
    programmers can be more productive using and utilizing Perl
    constructs, functionality, simplicity, and power, then the
    typical manager/supervisor/employee may be persuaded.
    Regarding using Perl in general, it's also sometimes helpful
    to point out that delivery times may be reduced using Perl, as
    compared to other languages.

    If you have a project which has a bottleneck, especially in
    terms of translation, or testing, Perl almost certainly will
    provide a viable, and quick solution. In conjunction with any
    persuasion effort, you should not fail to point out that Perl
    is used, quite extensively, and with extremely reliable and
    valuable results, at many large computer software and/or
    hardware companies throughout the world. In fact, many Unix
    vendors now ship Perl by default, and support is usually just
    a news-posting away, if you can't find the answer in the
    *comprehensive* documentation, including this FAQ.

    If you face reluctance to upgrading from an older version of
    perl, then point out that version 4 is utterly unmaintained
    and unsupported by the Perl Development Team. Another big sell
    for Perl5 is the large number of modules and extensions which
    greatly reduce development time for any given task. Also
    mention that the difference between version 4 and version 5 of
    Perl is like the difference between awk and C++. (Well, ok,
    maybe not quite that distinct, but you get the idea.) If you
    want support and a reasonable guarantee that what you're
    developing will continue to work in the future, then you have
    to run the supported version. That probably means running the
    5.004 release, although 5.003 isn't that bad (it's just one
    year and one release behind). Several important bugs were
    fixed from the 5.000 through 5.002 versions, though, so try
    upgrading past them if possible.

AUTHOR AND COPYRIGHT
    Copyright (c) 1997 Tom Christiansen and Nathan Torkington. All
    rights reserved. See the perlfaq manpage for distribution
    information.

-- 
	Tom Christiansen	[email-masked]
Your csh still thinks true is false.  Write to your vendor today and tell
them that next year Configure ought to "rm /bin/csh" unless they fix their
blasted shell. :-)   --Larry Wall in Configure from the perl distribution