Perl 6 Programming/Perl History
Perl 1 - 5
The Perl programming language was created by Larry Wall, a linguist and a computer systems administrator for NASA in 1987. Perl is a dynamic programming language which for much of its history was considered to be a "scripting language" or a command-line administration tool. However, as of version 5 of the language, Perl has been considered to be a powerful and useful general-purpose programming language that is consistently popular among web developers, system administrators and hobbyist programmers.
The Perl programming language was developed as an open-source free-software project, and has gradually expanded until the release of Version 5, the current state-of-the-art in Perl. Through all these developments, Perl has remained backwards compatible with previous versions. The Perl 5 interpreter can read, understand and execute (for the most part) programs that were written in Perl 1, Perl 2, Perl 3 and Perl 4. Unfortunately this made a mess of the internals of the Perl 5 interpreter and made many programming tasks harder then they need to be.
Another tripping point was the Perl 5 language specification; it wasn't a specification at all. The Perl interpreter itself was the standard, and whatever behavior the interpreter had was considered to be the "standard" behavior. The only way to duplicate all the strange and idiosyncratic behavior of the Perl language was to use that standard software only.
The time was ripe for a rewrite of the Perl language from the ground up. Backwards compatibility would be forfeited so that many fundamental problems with the language could finally be resolved and many necessary new features could be added. The new version would be called Perl 6, and would be completely different from Perl 5 but at the same time would unmistakably be the same language. Unlike Perl 5, which developed organically over time and was completely idiosyncratic, Perl 6 would start out as a set of specifications first, and would be instantiated in multiple separate and equal implementations.
Perl 6 started with a long period of community involvement and an RFC process. Community members were asked to contribute ideas and suggestions for the new language. Larry went through the suggestions, saved the good ones, removed the bad ones, and tried to bring everything together in a unified way. Perl 5 had been criticized for being "hacky" and inconsistent, so Perl 6 should avoid that from the very beginning. Once all the suggestions were tabulated and discussed, Larry released a series of design documents known as the Apocalypses. Each Apocalypse was numbered to roughly correspond with a chapter in the book "Programming Perl" and were meant to be a revelation of the concepts and trade-offs that were being considered in the design of Perl 6. From these documents (which were short on specifics), Damian Conway produced a corresponding series of explanatory documents called Exegeses. While an Apocalypse revealed some of the design, an Exegesis explained what that meant to the everyday programmer in terms of the code that would be written. Later, as the design matured, design specifications called the Synopses were created to synthesize and document the design of Perl 6. The Synopses currently stand as the official design documents for the Perl 6 language.
Perl has always been a flexible and capable programming language. One of the most important mantras of the Perl team is There Is More than One Way To Do It (TIMTOWTDI). Perl 6 is a very flexible language that combines a number of different programming paradigms to support various programmers and varying programming tasks. Because of this TIMTOWTDI philosophy, Perl 6 is a very big programming language with lots of different features and capabilities.
Another way to say this is that Perl gives you plenty of rope, but you have to be careful not to trip yourself with it. There are lots of big ideas floating around in Perl 6, but not all of them are going to be useful for all programming tasks. Also, there are plenty of things that are possible in Perl 6 that might not be considered "best practices" by the programming community at large. It's important to learn not just how to write certain things in Perl 6, but when to write things in certain ways. Without that knowledge, programs could easily descend into meaningless unreadable gibberish.
Throughout this book we'll try to show you some best practices and try to talk about where each feature is and is not useful.