1 files changed, 248 insertions, 0 deletions
diff --git a/pod/perlfaq1.pod b/pod/perlfaq1.pod
new file mode 100644
index 0000000000..2510a4b1f1
--- /dev/null
+++ b/pod/perlfaq1.pod
@@ -0,0 +1,248 @@
+=head1 NAME
+
+perlfaq1 - General Questions About Perl ($Revision: 1.10 $)
+
+=head1 DESCRIPTION
+
+This section of the FAQ answers very general, high-level questions
+about Perl.
+
+=head2 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.
+
+=head2 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.
+
+=head2 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.
+
+=head2 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.
+
+=head2 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).
+
+=head2 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.
+
+=head2 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.
+
+=head2 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.
+
+=head2 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. :-)
+
+=head2 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.
+
+=head2 Is it a Perl program or a Perl script?
+
+It doesn't matter.
+
+In "standard terminology" a I<program> has been compiled to physical
+machine code once, and can then be be run multiple times, whereas a
+I<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.
+
+=head2 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 .
+
+=head2 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 .
+
+=head2 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
+I<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.
+
+=head1 AUTHOR AND COPYRIGHT
+
+Copyright (c) 1997 Tom Christiansen and Nathan Torkington.
+All rights reserved.  See L<perlfaq> for distribution information.