The Perl Journal September 2003
There was a time when interpreted languages like Perl just weren't serious contenders for the really important jobs, the jobs where a failure could endanger human life, or even just open the door to loss of money or property. Interpretation was slow, and "quick-and-dirty-solution" languages like Perl didn't have the trust of project managers. If it was done in Perl, it wasn't a real application, or so the prejudice went.
Today, things are different. The Web has done its part to prove the reliability of Perl, and Moore's Law has eliminated much of the speed gap that kept Perl out of the critical areas. Programmers working on important tasks trust Perl now, and they choose it because it gives them advantages that they don't get from purely compiled languages.
For instance, once you've gotten used to Perl's quick run/test/debug cycle, you never want to wait for a compiler again. This has taught Perl programmers that the true measure of a program's reliability sometimes has more to do with how "fixable" and "tweakable" the program is than a program's raw performance. All code will break someday. A reliable program is one that you don't dread fixing. Perl makes it so easy to make quick changes, you never really dread digging into your source code.
But even in the early days, Perl made some inroads into highly critical areas—like, in this issue, the system Richard Hogaboom describes, that as far back as 1995, used Perl to track the positions of aircraft on the ground at the Atlanta International Airport. For my money, keeping aircraft from colliding is about as critical a job as a programming language can do. It uses some pretty nifty calculus (well, nifty to a math-challenged guy like me), and I can honestly say that it's the only piece of Perl code I've ever seen that needs the speed of light encoded as a constant. I think it proves the point that Perl is up to the job when failure is not an option.
No language guarantees fault-free code. That's up to programmers—and it's no harder to write absolutely dependable code in Perl than it is in C++, Java, or Fortran.
Back in the summer of 1998, TPJ published the article "Just the FAQs: Understand References Today," by Mark-Jason Dominus, that examined the new Perl 5 references feature, which is fundamental to managing complicated, structured data. Eventually, the article became the basis for the perlreftut man page and an important part of Perl's core documentation.
Like you, we think that chopping up established Perl documentation is bad for the language and bad for the community—and it's not the way things ought to be done. That's why the article should remain part of the documentation.
In this spirit, we want to ensure that the article is freely available for your use whenever Perl references are discussed. So if you want to use this article for whatever purposes, feel free to do so without having to ask permission from the CMP lords and lawyers that be, or even us lowly editors. We hope this will keep useful information accessible to Perl users both now and in the future.
Kevin Carlson
Executive Editor
The Perl Journal