This was one of the three keynotes given at YAPC::NA 2010 in Columbus Ohio. It attempts to explain the history of Perl from the point of view of the Modern Perl movement.
This is one of my favorite Larry quotes and so I decided to dig up the source during my research for this talk. And I came upon a whole bunch of great stuff.
These first few slides in this talk (which I haven't actually started yet, this is just the intro) were taken from a talk called "Camel Lot #6, The Once and Future Perl" given by Larry 10 years ago in 2000 at the Atlanta Linux Showcase Keynote In this talk he introduced Perl 6 as a language, described it's goals, the RFC process, etc.
But in doing some more research I found that in fact they were also in a 1994 talk called "The Taming of the Camel" given at the The USENIX Symposium on Very High Level Languages in New Mexico in which Larry introduced Perl 5.
And actually, according to Larry (in the 2000 talk), some of these slides were actually scanned from overhead transparencies and so might even be older than that.
So in this slide Larry talks about how it was "back then", before Perl existed. You had C, which was adept at something Larry called Manipulexity, which is the property where, starting from zero and a couple of simple tools you slowly hand-craft a complex solution to a complex problem. You also had the shell, which was adept at something Larry called Whipuptitude, which is the property where, starting from zero with a large library of easily combined tools, you quickly hack a solution to a moderately simple, but annoyingly tedious, problem that occurs frequently. Notice the void ...
This next slide shows the birth of Perl. Basically Perl was meant to fill the void by being a language well equiped for both Manipulexity and Whipuptitude. Of course, all this took place back in ....
Now fast-forward to 2010, you find yourself in Columbus, OH and while we don't have flying cars, we do have Modern Perl. So, Why the mug? you may ask. Because I believe the road to Modern Perl actually began the day Perl 6 was concieved. I also want to point out that I am saying Modern "Perl" here, and I am making no distinction between 5 or 6. That is because I believe Perl 6 to be just as much a part of Modern Perl as Perl 5 is.
In 1994 Perl got a major facelift and Perl 5 was released. It had lots and lots and lots of new features added in, as you can see. Just to give some context for some of the younger members of the crowd: - this was also the year Python reached 1.0 - Ruby wasn't out yet (but was likely in dev) - PHP was still just a set of C libs - Java 1.0 would still not be released for another year
In 1995, The CPAN is born Even when the internets were shouting that "Perl is Dead", the one thing they would admit is that CPAN is by far the best organized and most extensive collection of free software out there for any language. “The whole intent of Perl 5's module system was to encourage the growth of Perl culture rather than the Perl core.” -- Larry Wall
In 2000, Perl 6 is announced. The Perl 6 announcement and the subsequent path that the community went down really brought forth much of what has become Modern Perl.
In 2001, Perl 5.6.1 was released Perl 5.6.1 might not seem all that interesting, but it actually introduced a lot of features which are used extensively in many key Modern perl projects. It is pretty safe to say that Perl 5.6.1 is the outer boundary of Modern Perl and very few, if any, of the key Modern Perl modules and projects would work on anything prior to it.
Also in 2001, Test::Simple was released, which was followed later by Test::Builder and really started the whole testing revolution in Perl. Testing is an important component of Modern Perl, it is safe to say that perl has one of the strongest testing cultures of any programming language and that this has directly contributed to the rise in quality of Perl modules. In short, if you are writing Modern Perl, you are writing tests. A little side note as well, Test::Simple came out of the perl-qa mailing list, which was started as one of the first early Perl 6 lists. Another way in which Modern Perl and Perl 6 are tied together.
Next, in 2003, Perl 5.8.1 was released Perl 5.8.1 was in some ways "just another release", in many ways Perl 5.8.x is the "support dividing line" for many module authors these days. After all, it is 7 years old, which is ancient in our industry. I think it is also important because in Perl 5.8.1 we got rid of some unsuccessful ideas like pseudo hashes and the old style threads. Deprecation is a good thing which we will see even more later.
In 2004, the Perl 6 Apocolypse 12 was released. In the 10 years since Perl 5 was born, OOP had pretty much taken over the planet, and honestly Perl was behind the curve on this one. The Apocalypse 12 drew out the plans for a really truely perlish OO system, and got a lot of people drooling for what Perl 6 would bring.
In 2004 we also saw the creation of CPANTS. CPANTs is the service which does automatic testing of all CPAN modules and has really helped boost the overall quality of CPAN and has become an invaluable tool for CPAN authors. So, not only do we get a world wide, globally mirrored distribution system, we get extensive automated testing and reporting of results on all major platforms. FOR FREE!
Next in 2005, we got Perl Best Practices. The community can yell all it wants inside the echo chamber, but once it is in print, it is the truth! Perl Best Practices is an important book in the history of Modern Perl because it really showed that TIMTOWTDI, while a great idea, didn't have to also be the central philosophy of development. In a large way this book helped legitimize Perl and give it a more "serious" tone, which, if you are running a business and your livelyhood depends on it, it really a good thing.
2005 also saw the release of a module called PPI. It has been said, and I believe there is also a formal proof somewhere that says Perl is unparseable. The real truth is that is it impossible to statically analyze Perl simply by looking at the source code. You need to actually execute it first. But this didn't stop Adam Kennedy. (BTW, this is an actual picture of Adam wrestling with the Perl syntax tree while developing PPI. Note the calm look in his eyes, its almost like he is smiling.) What Adam realized is that he didn't really want to statically analyze Perl code, he wanted to statically analyze Perl "source". Herein lies the genius of PPI.
Next, PPI made possible the Perl::Critic. Perl::Critic also ties in with Perl Best Practices and general idea that people should write better Perl code. Perl::Critic makes it possible to automate simple code review and enforce best practices. Something other, more easily parsable languages, have had for a while. It is important not to see Perl::Critic as a creativity killer, but as a way to keep the ugly side of TIMTOWDTI at bay, while leveraging all the power that a language like Perl can offer. Like Uncle Ben told Peter, with great power comes great responsibility. Perl::Critic is like an automated Uncle Ben.
In 2005 we also saw the release of two key Modern Perl modules, Catalyst & DBIx::Class It is pretty safe to say that Perl built the web. But that was a long time ago and many other languages had since stepped up to the plate and brought a better game. Catalyst changed all that. Catalyst originally grew as a fork of Maypole, and quickly took on a life of it's own. Eventually falling under the spell of one Matt S. Trout, who is a big fat pussy for not shaving his head. DBIx::Class actually grew as a reaction too (not so much a fork of) Class::DBI. I also think that DBIC is an important milestone in that it was one of the first major "Modern Perl" modules to really shunned the more magic oriented "top down", DWIMish approach. Instead opting for a more reasoned "bottom up" approach based on solid conceptual footings and a strong understanding of RDBMS technology and theory. Catalyst and DBIC are also important in that they have evolved into true community driven projects. Many CPAN modules have multiple contributors, but both of these projects have gone beyond that to become built, maintained and extended by a greater community.
Also in 2005, the Pugs project was started. Pugs was a project started by Audrey Tang after she read a really dense book called "Types and Programming Languages" and decided "Hey, I should implement Perl 6 in Haskall ... FOR FUN". It is safe to say that Pugs brought life back into the Perl 6 project and really helped to solidify a lot of the hand wavey-ness that was still in the synopsis and apocolypses. It became possible for the Perl 6 community to actually test out these ideas and really see how they worked in real code. Really I think that Pugs contributed a lot to Modern Perl, but two key elements worth mentioning here were: Pugs championed the concept of -Ofun (optimized for fun) which is an important component of Modern Perl. After all if you want boring tedium, there are plenty of Java and C# jobs out there. Pugs also gave out commit-bits like first hits of crack, this style of open-ness in projects really caught on in Modern Perl, helped a lot by git and its development model. Pugs is also important to me because it was the incubator in which I created ...
... Moose (which was in early 2006). Moose is what is sometimes called a "disruptive technology". Even though it is not as performant as the existing solutions, it provides enough new features and such that people find it compelling enough to use it anyway. I believe that Moose also caused a paradigm shift, because it was not just as a "drop in" replacement for old style Perl OOP, but was a new way of approaching Perl OOP. And while Moose makes a really serious effort to work well with existing classes written in old style Perl OOP, it does not work well with some of the bad habits and ad-hoc techniques that have developed over the years with TIMTOWTDI-inspired OOP. Moose really pushed Perl 5 and showed how truely flexible it is and how much more life it really still had in it. In short, Moose made Ruby/Python less appealing :)
2006 also saw the release of Strawberry Perl. Anyone who has used Perl on Windows knows that Perl has long been a second class citizen there. But Strawberry Perl fixed that and continues to make it even better today.
Next, in 2007 we finally got Perl 5.10.0. This, along with the new release process that would came later on really broke the P5P out of a rut, and things like the "feature" pragma marked a break with the stranglehold of backwards compat. Remember people, it is still possible to run most of your Perl 1 code with the Perl 5 interpreter. Perl 5.10 also has an important symbolic meaning. If we followed normal versioning conventions, it would have been Perl 6.0. By going with 5.10, it really showed that Perl 5 and Perl 6 were two languages that would coexist with one another and that Perl 5 was anything but dead.
Much to the horror of many, 2007 also saw the release of Devel::Declare One of the super-uber-awesome cool features of Perl 6 was the flexible grammars. Some (myself included) think they are just insane, but that said, a decent macro system would be nice. I jest, because Devel::Declare takes, in some ways, a much saner approach then source filters. Devel::Declare hooks itself into the Perl parser and allows you to override just one small segment of code, whereas a source filter has to actually digest and parse the entire source code. So while this seems pretty crazy, it is actually quite sound, and is made even moreso by the fact that people are working towards making this a true feature of the perl interpreter with a stable public API as well. This also demonstrates an important trend in Modern Perl, the prototyping of new features is done with module extensions before they are allowed into the core. This actually happened in Perl 5.10 with the MRO feature, which was first prototyped in the Class::C3 module. By prototyping features like this outside of core we avoid the technical debt of backwards compat for what may turn out to be a really bad idea.
2007 also saw the release of local::lib How many times have you been on a perlmonks, or IRC and heard: "I can't install modules, my sysadmin wont let me, so how can I parse HTML with a regexpr?" No longer is that a valid statement, local::lib has made it simple to have a project local lib directory in which you install your CPAN modules without needing root access. This, along with some of the more recent modules like perlbrew and cpanm promise to change how we deploy, install and distribute Perl apps.
Next came 2008 and Padre I mean, how can you take a language seriously if it doesnt have an IDE? But actually, having a high quality, open source, configurable editor with the features and capabilities of Padre means a lot. I have recently had the "pleasure" at work of writing some C# with Visual Studio, and while at times it was horrible, the high degree of integration between the editor and the language was really actually kind of nice. And also, Adam Kennedy recently completed his aging grant for a refactoring editor for Perl. While I haven't had a chance to play with it yet, I suspect it will be pretty damn nice.
In 2009 we saw the emergence of the EPO (Enlightened Perl Organization) and Iron Man blogging challange. Everyone knows that bloggability is the measure of a good programming language. Not only did Iron Man help really burst the echo chamber we had all been living in for so long, but it also championed the cause of Modern (or Enlightened) Perl to parts of the Perl community who hadn't really noticed it yet.
2009 also saw the emergence of Plack and PSGI As miyagawa said, coming late means there is a lot of good stuff to steal. Plack is interesting because it (with PSGI) basically is the one true way of writing an interface between a web server and a web app. Which is actually very Pythonic (which makes since because that is where miyagawa stole it from). But Plack also really embraces the spirit of TIMTOWTDI, because: - you can build an app in more than one way - you can deploy in more than one way that was a flexibility we did not have before, and by being clean, clear and consistent on a very small surface area, we actually gained more ways to do it.
And now we are in 2010, the year in which Moose reached 1.00 Not 1 point 0, but 1 hundred. But sshhhh, don't tell the managers that ;) Actually this is important because key projects like Catalyst depend on Moose, and having Moose be at least 1.0, for whatever reason, makes people more comfortable with using it.
and lastly, 2010 also saw the release of Perl 5.12.0 5.12 is important in my mind for two reasons. First it introduced some really nice new features, and improved on some that had been released in 5.10. Further showing that Perl 5 was very much alive and growing. Second, this marked a change in the release process, towards a steadier and more regular schedule. Basically we're on annual releases now with monthly point releases for blead and at least one monthly-ish point release for maint. Having this kind of momentum is a good thing, really it is. And funny thing, this kind of aggressive and regular release schedule, we first saw it in Perl 6 and the Raduko project. Once again there is a synergy between the two projects.
ONWARD INTO THE FUTURE! So, that completes our history lesson, but it is not over. Still to this day there are plenty of exciting developments in Modern Perl. For instance, the previously mentioned perlbrew and cpanm promise to really change the way we interact with perl and CPAN. Modules like DBIx::Connector and Package::Stash which were actually extracted from DBIx::Class and Class::MOP respectively and aim to provide even more re-use for some low-level, difficult to solve problems. Modules like Devel::NYTProf which, like Perl::Critic and the Test:: modules is helping to push the quality of Perl code. Modules like KiokuDB, which is basically an object database and really could not have existed without Moose. Modules like CHI, which is a modern update of the Cache::Cache modules. In short, there is a lot going on out there, but actually right now, I would like to take a step back and look a little deeper at ...
If you are writing Modern Perl, you are writing tests. The testing revolution was a major foundational element to Modern Perl. CPANTS and the automated testing infastructure that CPAN provides also is a major part of what makes Modern Perl so great.
too long has Perl been called line-noise Modern Perl throws off that old cruft and shows Perl to be the powerful and flexible language that it really is Many of the language developments in the later Perl 5 releases are all about improving code quality. Modules like PPI, Perl::Critic aim to do that specifically. Perl Best Practices, duh! And it is important to note that this is not just reactionary because of all the bad Perl code out there, there is plenty of bad code in any language. This is instead a self regulating thing, a way to still retain the free spirit of Perl, but also ensure the standards of quality that the modern business world expects. And as for maintainability it is interesting to note that many Modern Perl projects like Moose, Catalyst and DBIC all shun "deep hacks" in favor of easier to maintain code, and when they do rely upon a deep hack, they try to push it as far to the edge as possible and wrap a clean API around it.
Don't balk at the "theory" in there please. Computers are nothing but layered abstractions each building on the one below. Modern Perl builds upon well tested and solid theories and ideas that have been around for a while now. - Catalyst uses MVC, a tried and true pattern that streches back to the early days of Smalltalk before some of you were born (well, all except Randal) - DBIx::Class was built on a solid set of abstractions that were built on keen understanding of RDBMS - Moose is built on 20 year old LISP technology as well as the battle tested ideas of a dozen other languages - Plack builds upon the great ideas of the Python and Ruby communities. In short, we opt for making sufficiently advanced science, rather then relying on Magic.
Writing larger scale programs is not just about using Modules and OOP, but it about building on larger abstractions and frameworks and re-using more code. A really large Catalyst app will be much smaller then an equivalent CGI.pm app. - By having frameworks like Catalyst, it becomes possible to spend less time thinking about the mechanics of your web code and just build on top of these abstractions - Moose too frees you from the tedium of old school Perl OO and gives you powerful tools like Roles - ORMs like DBIx::Class, Rose::DB, Fey:ORM all make it easier to access your DB, allowing you to write less code while managing greater amounts of data - Even things like templating systems helps to keep code compartmentalized and conceptual pure, which makes it easier to scale up in size.
Most importantly, Modern Perl is optimized for fun. Programming shoudln't be boring and bland, it should be interesting and fun. Perl has long been a playground for the silly (*cough* Damian *cough*) and whacky, and in the Modern era there is no reason that we should loose that fun edge.
Lets stop and talk about a module that I think epitomizes the Modern Perl thinking. Try::Tiny There were many modules before that tried to provide some kind of exception framework. From Error.pm to Exception::Class to TryCatch and it's Devel::Declare madness. All of them either trying too hard, or not trying hard enough, and while they are all good modules written by excellent programmers, none of them really fixed what was broken. But Try::Tiny took a different approach, it went for simplicity, clarity and comprehensiveness. It shunned all things magical and fragile, and instead focused with precision to solve a problem in the Perl language and bring about consistency and stability. Try::Tiny is an elegant module, it's aesthetics are important. It is not too crowded, not too sparse. It does the right thing without you having to know how much it is making your life easier. Try::Tiny helps you to be a better programmer without you even having to realize it, and stays out of your way so you can get on with the task at hand. This module (and modules like it, Moose, Plack, etc) illustrates perfectly how Modern Perl has moved towards more freedom and less coupling, by focusing more on the core problem domain, and really trying to not make decisions for you, but instead give you a set of reasonable and powerful choices. The result is modules that can be used more universally and have a better overall quality.
TIMTOWTDI - There is More Than One Way To Do It This has long been the motto of Perl, TimToady, and it has served the language well. But there is a dark side to TimToady, that leads to a chaos of too many different ways. This not only cuts down on re-use (ex: inconsistent approach to building objects makes it hard to subclass), but is not good for long term maintainability. Perl Best Practices pushes the idea of a more idiomatic Perl, one that is more consistent and therefore maintainable and extensible.
BSCINABTE - But Sometimes Consistency Is Not A Bad Thing Either So with that I propose an extension to TimToady that has been floating around the Moose commmunity for a little while now. Perl is a great language, made even greater by the community that surrounds it. Through consistency can come unity, and through that unity we can keep building upon all that we have to make bigger and better software. Modern Perl should be thought of as a refocusing of the greater community towards a common goal. One that includes Perl 5 right along side Perl 6, Perl 7 and all that will come.
Finally we revisit Larry's old graphic with a the new graphic in which Modern Perl has pretty much filled in the entire circle. In fact, there is very few places in which Modern Perl cannot be used to solve your problems.
stevan_little
fbei_ot
niftycorp
suzukimar
philipschwarz
deepu105
zakky21
yuhei_fujita
texmeijin
os1ma
toricky6
ddemaree
3n
quramy
marktimemedia
danielanewman
sferik
afnizarnur
sachag
bryan
garrettdimon
carmenintech
malarkey