Le PERL est mort
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Le PERL est mort

on

  • 1,617 views

This talk covers the history of Perl from its humble beginnings as a basic scripting language to

This talk covers the history of Perl from its humble beginnings as a basic scripting language to

Statistics

Views

Total Views
1,617
Views on SlideShare
1,614
Embed Views
3

Actions

Likes
2
Downloads
6
Comments
0

1 Embed 3

https://si0.twimg.com 3

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Perl's grown up a lot over the years. I'll be talking about how things were through a couple of stages in Perl's history, and then skip ahead to where we are now.\n\nTo be clear, I'll be talking about Perl as used in medium to large businesses. If you're just tinkering about, or your needs aren't that demanding, a lot of what I'll be talking about at the end of this talk will seem overkill. That's okay. There are other tools which fulfill less demanding needs. I'd be glad to point these out after the talk. \n
  • This is the 1995 era, which you'll remember as the dot com bubble. There was a rush to get things done without much regard for keeping things going ten years down the line. As such there's a lot of ad hoc and ugly hacks. Thankfully things have moved on since this time.\n\nThere are many things about this era of Perl's history that I'm glad to see we've past. It's now easier than ever to install modules, and easier than ever to develop and maintain them. But I would be lying if I said that some of these things aren't haunting us still. \n
  • Ah, CGI.pm. What a mess. It's slow, you mix your HTML and code and CSS and layout code and logic all together. Sigh. This is a bad thing because changes can affect unrelated parts of the code. And it's harder to give designers something they can use without being scared away by the business logic. \n\nAnd it's slow. CGI is most commonly implemented by forking a process for each request. Each and every request. perl startup is slow. So we have some weird optimizations happening here. This makes things harder to maintain (this is in the module itself).\n\nBut even with really fast quad-core boxes equipped with SSDs, the module still makes a mess of things. It has \n
  • mod_perl is great for what it was meant to do—writing Apache modules in Perl. But what does this mean? If you want to access the request/response cycle directly, or write an authentication module for Apache in Perl, you'd use mod_perl. It's very fast, because the code is compiled once. So, used properly, this bit of software still has many uses. \n\nHowever, it's also very low-level, and this means that there's more coding needed to do common tasks than would be needed with higher level tools. \n
  • Matt's Script Archive is, on its own, partly responsible for Perl having a reputation for being an unmaintainable mess of a language. It's a site containing a collection of Perl programs meant for usage on the Web. This would be okay on its own, but the programs are buggy in some spots and outright insecure in others. \n\nHowever, because they're freely available and fulfill common tasks, they became quite popular. And because they were (are?) popular, they served as examples from which many folks learned their Perl. As the code is rather terrible, this is rather undesirable. \n
  • Matt's Script Archive is, on its own, partly responsible for Perl having a reputation for being an unmaintainable mess of a language. It's a site containing a collection of Perl programs meant for usage on the Web. This would be okay on its own, but the programs are buggy in some spots and outright insecure in others. \n\nHowever, because they're freely available and fulfill common tasks, they became quite popular. And because they were (are?) popular, they served as examples from which many folks learned their Perl. As the code is rather terrible, this is rather undesirable. \n
  • Early in the history of Perl 5, we had CPAN. But it was the early days, before Moose and Catalyst and even Class::DBI. There were a few Getopt modules, a few basic modules for classes or objects, and ORMs were not really very common in any language. Two common modules that we did have at this time are DBI and POE, though they're generally the only exceptions. Even DateTime was only released in 2003 as an alpha. \n\nSo at this point we have a culture of reinvention, a culture that hasn't had the time to come into its own and fully realize or utilize the potential of CPAN. \n
  • Sometimes language designers make mistakes. They're human. It happens. A few misfeatures which are thankfully going away or that have gone away are switch.pm and pseudohashes. I don't want to dwell on these since they're going away. The only thing you really need to know about these "features" is that you're better off without them. If you're really curious, you can look them up yourself. \n\nBeyond that, there are things like formats. They're still in the language, but are pretty much universally accepted as not the best way to do things these days. We have tools like tempting languages for the things we once used formats for. \n
  • At this stage, things are starting to improve but Perl still hasn't really come into its own as a maintainable apps language. There's several important things happening here, some of which had unexpected results. \n
  • Around the early 2000s we started to see experts in support communities guiding new folks to strict and warnings, language features that help the programmer write better code. This is important, as new folks need the guidance these features provide. \n\nIn addition, Perl's strong tradition for testing really started to take off around this time. It's still going strong, with the QA hackathon every year drawing some of Perl's brightest developers. \n\nIncidentally, the QA hackathon is also where a lot of work on the toolchain happens. By "toolchain" here I mean the tools for holding and installing Perl modules. As Perl became more popular, we needed more robust tools. And smart people stepped up to write them. Today their efforts are a large part of what makes Perl the mature apps language it is. \n
  • Ah, CPAN. My favorite Perl feature. It's in the early 2000s that we start to see some awesome tools, tools that people still use today to do really common and basic things.\n\nChances are that if you did asynchronous programming in Perl at this time, you used POE. It's still going strong after more than 10 years of development (though these days it has a lot of competition). It does nearly everything, with modules for almost anything you can think of. \n\nConversely, it's maddeningly difficult to do date/time calculations correctly without DateTime. Another one of Perl's de facto standard modules, it's also one of the oldest and most mature. I and many other Perl hackers turn to it for all temporal work. \n \nHowever, we still had a long way to go at this point. CPAN was still young, so there were few de facto tools for various jobs. Competition is a good thing, indeed, but at the early stage CPAN was at it was more harm than good. \n
  • Perl Best Practices is probably the singular example of a galvanizing book in the Perl community. Many developers love it, many hate it. The standards described in it are obligatory at many shops around the world, despite many developers wishing the book was never written. \n\nA lot of the suggestions it gives (particularly regarding CPAN modules) are outdated or just bogus. I wouldn't give it to a new developer and tell them to follow it to the letter. I don't know anyone who would. \n\nBut that's not the point. The point is the book got people really thinking about code standards in the Perl community, and inspired them to devise their own best practices, their own evolving set of standards. In a way, Perl Best Practices laid the groundwork for the modern Perl movement. So, despite being crazy in a lot of ways, PBP really helped the industry. \n
  • To clear up some rumors: Perl 6 is not Perl 5. They are different languages in the same lineage, incompatible but complementary. Perl 6 is Larry's sixth Perl, no less Perl than the Perl 5 I've been talking about and will continue talking about for the remainder of this talk. \n\nSo what's it have to do with Perl 5, then? More than you would think. For one thing, it kickstarted and rejuvenated development on Perl 5. But what I'm going to focus on later is that through various circumstances, Perl 6's development directly led to a major revolution in Perl 5's support for OOP. This revolution is still going today, and it's televised on presentingperl.org. Consider it a bit of foreshadowing, if you're looking for a literary context in which to place this talk. \n
  • There's a lot of names for the current movement happening in the Perl community: modern Perl, enlightened Perl, the Perl renaissance. They all basically refer to the same thing: a mature usage of CPAN combined with Perl's rich history of testing and documentation. All of these things bring Perl from "scripting language" to full apps language.\n\nOne of the mottoes of this era is TMTOWTDIBSCINABTE, or "Tim toady bicarbonate". It stands for "there's more than one way to do it, but sometimes consistency is not a bad thing either". It refers to all the choices available on CPAN, and the benefits in choosing the best tools to do a job.\n\nAs this movement is largely defined by the liberal application of CPAN libraries, it makes sense to cover a few important ones. A typical Web application stack uses Catalyst for MVC, Plack for app middleware (connects Catalyst to different Web servers, with some pluggable awesome in between), Moose as an object system, and DBIx::Class for the ORM. These aren't the only choices, but they're probably the most popular. If you want to hire a mature Perl dev, these are your best choices. They're what the community has standardized on. \n
  • Catalyst grew out of older Perl Web frameworks. It's a framework that uses the MVC framework: model, view, controller. In this configuration, Catalyst represents the controller. A templating system like Template Toolkit or Mason is used for the view, and an ORM like DBIx::Class is used for the model. \n\nA major benefit of working with Catalyst is its flexibility. It's a very pluggable framework, partly due to its design and partly due to using Moose. All of this flexibility does make things mote complicated, though. So if you're wanting to write a small app with just a few pages, Catalyst isn't for you. \n
  • PSGI is a protocol for connecting a Perl app and a Web server. It's server independent, and can work in many different configurations: CGI, mod_perl, FastCGI, etc.\n\nBut it's not just glue. The Plack namespace on CPAN has a growing collection of tools to make Web development in Perl easier and less horrible. Chances are if you're writing Web code with Perl these days and you're not using cGI.pm that you are using Plack in some way. \n
  • Moose is Stevan Little's object system for Perl 5. Remember how I said that Perl 6 was instrumental in the development of Perl 5? This is what I was mostly referring to. Moose is one of the best things to happen in a long time for Perl, and the community has mostly adopted it as the de facto (bicarbonate) object system for Perl 5. \n\nWhat makes Moose so great? Usually I could not care less for computer science topics, as they very rarely translate into concepts directly applicable in a working programmer's life. However, Moose is very research-based, including the metamodel found in CLOS. This metamodel gives Moose much of its power, but it doesn't stop there. Moose also has awesome features like roles, or composable pieces of behavior. Roles are what most people really want when they (mis)use inheritance. But that's a subject for another talk. \n
  • Much along the lines of Catalyst and Moose, DBIx::Class is an extremely flexible ORM, written and maintained by a team of developers who aren't afraid of SQL. It allows a developer to be completely abstracted from the database if they want, but at the same time grants the flexibility to give literal SQL queries that populate objects. \n\nBeyond this, it's capable of automatically reading the database schema, at runtime, and generating the necessary classes to allow you to get up and running as quickly as possible.\n\nIt has well-designed resultset support, only pulling data from the database when necessary. And when the built in methods don't do enough, it's trivial to add new methods to row objects, and these work just as well as the built in CRUD methods. \n
  • \n\n
  • \n\n
  • \n\n

Le PERL est mort Presentation Transcript

  • 1. Le PERL Est Mort Perl !r"gh # A$s
  • 2. Ye Olde Perl
  • 3. Ye Olde PerlCGI.pm
  • 4. Ye Olde PerlCGI.pmmod_perl
  • 5. Ye Olde PerlCGI.pmmod_perlMatts Script Archive
  • 6. Ye Olde PerlCGI.pmmod_perlMatts Script ArchiveBring Your Own Everything
  • 7. Ye Olde PerlCGI.pmmod_perlMatts Script ArchiveBring Your Own EverythingLanguage warts
  • 8. CGI.pm
  • 9. CGI.pmBuilt-in HTMLgeneration
  • 10. CGI.pmBuilt-in HTMLgenerationNo separation ofconcerns
  • 11. CGI.pmBuilt-in HTMLgenerationNo separation ofconcernsSlow (weirdoptimizations aroundthis)
  • 12. mod_perl
  • 13. mod_perl API for Apache
  • 14. mod_perl API for Apache Good for changing the request/response cycle
  • 15. mod_perl API for Apache Good for changing the request/response cycle Subpar for writing actual applications— too low level
  • 16. Matts Script Archive
  • 17. Matts Script Archive
  • 18. Matts Script Archive
  • 19. Matts Script ArchiveAmong the first popular places to find reusablebits of code
  • 20. Matts Script ArchiveAmong the first popular places to find reusablebits of codeEasy to deploy, fulfilled common tasks, so verypopular
  • 21. Matts Script ArchiveAmong the first popular places to find reusablebits of codeEasy to deploy, fulfilled common tasks, so verypopularTerribly buggy and insecure
  • 22. Matts Script ArchiveAmong the first popular places to find reusablebits of codeEasy to deploy, fulfilled common tasks, so verypopularTerribly buggy and insecureBut because of their popularity, they becamethe example of Perl code to the outside world
  • 23. BYOE
  • 24. BYOEImmature CPAN means few good choices forcommon tasks
  • 25. BYOEImmature CPAN means few good choices forcommon tasksThis means lots of DarkPAN reinvention ofcommon tasks
  • 26. BYOEImmature CPAN means few good choices forcommon tasksThis means lots of DarkPAN reinvention ofcommon tasksAdditionally, this hastened adoption of Matts"code".
  • 27. Language warts
  • 28. Language wartsSwitch
  • 29. Language wartsSwitchPseudohashes
  • 30. Language wartsSwitchPseudohashesFormats
  • 31. Less Icky 2000s Perl
  • 32. Less Icky 2000s PerlSome best practices
  • 33. Less Icky 2000s PerlSome best practicesCPAN starting to mature
  • 34. Less Icky 2000s PerlSome best practicesCPAN starting to matureStill no PBP!
  • 35. Less Icky 2000s PerlSome best practicesCPAN starting to matureStill no PBP!Perl 6
  • 36. Some Best Practices
  • 37. Some Best Practicesstrict and warnings
  • 38. Some Best Practicesstrict and warningsTests
  • 39. Some Best Practicesstrict and warningsTestsToolchain
  • 40. CPAN Starting to Mature
  • 41. CPAN Starting to MaturePOE
  • 42. CPAN Starting to MaturePOEDateTime
  • 43. CPAN Starting to MaturePOEDateTimeStill too much TMTOWTDI in other areas
  • 44. Still No PBP!
  • 45. Still No PBP!Its very controversial
  • 46. Still No PBP!Its very controversialMany of itssuggestions suck
  • 47. Still No PBP!Its very controversialMany of itssuggestions suckBut the importantthing is it started adialog.
  • 48. Perl 6
  • 49. Perl 6Separate language toPerl 5, but still Perl
  • 50. Perl 6Separate language toPerl 5, but still PerlRejuvenated Perl 5dev
  • 51. Perl 6Separate language toPerl 5, but still PerlRejuvenated Perl 5devForeshadowing forfuture of Perl 5 OOP(dun dun dun!)
  • 52. Modern Perl (2005-)
  • 53. Modern Perl (2005-)Many names, same general idea
  • 54. Modern Perl (2005-)Many names, same general ideaTMTOWTDIBSCINABTE
  • 55. Modern Perl (2005-)Many names, same general ideaTMTOWTDIBSCINABTEMature, disciplined use of CPAN, languagefeatures
  • 56. Modern Perl (2005-)Many names, same general ideaTMTOWTDIBSCINABTEMature, disciplined use of CPAN, languagefeaturesTypical app stack: Catalyst, Plack, Moose,DBIx::Class
  • 57. Catalyst: MVC for Perl
  • 58. Catalyst: MVC for PerlPluggable, flexible
  • 59. Catalyst: MVC for PerlPluggable, flexibleGreat for large apps
  • 60. Catalyst: MVC for PerlPluggable, flexibleGreat for large appsFlexibility handlescomplexity
  • 61. Plack/PSGI
  • 62. Plack/PSGIPlack/PSGI is awesome middleware forconnecting your app to your web server. Thinkof WSGI from Python or Rack from Ruby.
  • 63. Plack/PSGIPlack/PSGI is awesome middleware forconnecting your app to your web server. Thinkof WSGI from Python or Rack from Ruby.Lots of useful tools, too, like debugging toolsand logging and session handling etc.
  • 64. Moose
  • 65. MooseMature, flexible,powerful object systemfor Perl 5
  • 66. MooseMature, flexible,powerful object systemfor Perl 5Large, maturecommunity
  • 67. MooseMature, flexible,powerful object systemfor Perl 5Large, maturecommunityBased in solid research
  • 68. MooseMature, flexible,powerful object systemfor Perl 5Large, maturecommunityBased in solid researchEvolved from Perl 6development
  • 69. DBIx::Class
  • 70. DBIx::ClassORM that respectsdatabases
  • 71. DBIx::ClassORM that respectsdatabasesResultsets!
  • 72. DBIx::ClassORM that respectsdatabasesResultsets!Easy to customize rowclasses with methods
  • 73. Questions?
  • 74. ColophonTitle image: http://www.flickr.com/photos/caribb/4310691752/in/photostream/Cave writing: http://www.flickr.com/photos/the-consortium/3057208323/in/photostream/Old machinery: http://www.flickr.com/photos/mon_oeil/438670665/in/photostream/Fail meter: http://www.flickr.com/photos/16854395@N05/2420602334/in/photostream/Light switch complicator: http://www.flickr.com/photos/lenore-m/510420532/in/photostream/Stone tools: http://www.flickr.com/photos/salsaboy/3228329709/in/photostream/Perl Best Practices (c) 2005 OReilly Media
  • 75. Colophon IICamelia TM Larry Wall: https://raw.github.com/perl6/mu/master/misc/camelia.txtMoose: http://www.flickr.com/photos/russosborne/1684252182/Catalyst logo used under license.DBIx::Class logo (c) Mark Keating