10 ms·

Modern Perl: The Book: The (draft) PDF

85 points by another_ali 16y ago

ddemchuk 16y ago
Ok, I am a solid PHP developer, pretty advanced with Ruby, and can do front end code and JQuery with my eyes closed. Should I be interested in Perl? Is there any reason to learn it if I know these other languages? I am genuinely curious
- revoltingx 16y ago
  Well, if you are advanced with Ruby then you're probably set. However, Perl is still an excellent language for building scalable web systems in no time. With 'Modern Perl' you get 'Ruby on Rails' style of programming in Perl, and with Perl you get the tons of libraries in CPAN. I wouldn't recommend learning Perl if you already know Ruby. For the same reason I wouldn't learn Python or Ruby because I know Perl. I'd learn something different like Erlang.
  - jamesbritt 16y ago
    With 'Modern Perl' you get 'Ruby on Rails' style of programming in Perl What exactly does that mean? Optional parenthesis on method invocations? Considerable use of convention over configuration? Built-in object mapping to database schemas?
    - revoltingx 16y ago
      Optional parenthesis on method invocations? Yes, but that comes with Perl. (I don't find that even remotely useful. I like to know if a variable is calling a method or a member simply by looking at the code.) Considerable use of convention over configuration? Not sure what you mean here. Built-in object mapping to database schemas? Yes. I'm also referring to the clean MVC/OO style project architecture. Here's how I described it in another thread: With modern Perl, code is usually clean and free of crazy syntax. With a OO architecture where the base classes do most of the work (such as auto authentication, auto encoding/decoding, auto DB joins, etc.) and you do business/game logic in the upper modules.
      - jamesbritt 16y ago
        "With modern Perl, code is usually clean and free of crazy syntax. With a OO architecture where the base classes do most of the work (such as auto authentication, auto encoding/decoding, auto DB joins, etc.) and you do business/game logic in the upper modules." Ah, OK. That just sounds like Ruby, though, nothing special to Rails about that.
        revoltingx 16y ago
        Last time I checked, Rails provides a lot of built-in functionality for building web apps. But perhaps I got Rails confused with Ruby with my brief experience with it. I thought Rails provided the tools to auto-create your project structure in an MVC style. If you use something like Catalyst of CGI::Application you get built in things like MVC project structure, auto populate a 'class' from a table entry, etc. Basically, you get all those built-in functionality for building web apps that you would in Rails. But, I very briefly played with Rails, so I may have its definition confused.
        jamesbritt 16y ago
        I see. So CGI::Application (and Catalyst) is a built-in part of modern Perl. Interesting.
- msbarnett 16y ago
  On the one hand, I tend to think that learning a new language or tool kit is always a valuable experience. On the other hand I switched from Perl to Ruby as my go-to scripting language about 6 years ago and haven't felt like there were any niches which Perl serviced that Ruby failed to, for my uses. Still, I'd say try it out for a few small things; you might find that Perl better fits the way you think, and if not, at least you can say you know a bit of Perl if anyone ever asks.
  - drac 16y ago
    By and large, I've had the opposite problem making a lasting switch from Perl to Ruby. I know Perl better than most other languages in my toolbox, and it's my default prototyping and one-off utility language. I don't find a lot of niches (for my typical uses, of course) that are served better by Ruby, so it's been really difficult to switch away from Perl.
- sigzero 16y ago
  I like Perl. Given what you have said above it would be hard for me to say "Yes, give Perl a try" except to say "You should give Perl a try." The reason I say that is because a programming language is just like a religion. You will like it or you will not (even with its quirks).
- rtra 16y ago
  some interesting comments on Perl: http://lambda-the-ultimate.org/node/3564 http://lambda-the-ultimate.org/node/3564 This is also good: http://www.perl.com/pub/2007/12/06/soto-11.html http://www.perl.com/pub/2007/12/06/soto-11.html
- deleted 16y ago
  [deleted]
- jamesbritt 16y ago
  I went from Perl to Ruby about 10 years ago, and I can't say there's anything I miss. Certainly, at the start, running Web apps was easier in Perl because most servers had mod_perl out of the box. But for day-to-day tasks I found I much preferred Ruby. The reasons for this, though, are as likely personal aesthetics as anything else. Nowadays Phusion Passenger makes Rack-based Web apps snake-simple, and using JRuby gives me all of the Java libs out there (including Swing for insanely-easy cross-platform GUI apps when teamed with Monkeybars), as well the option to deploy Web apps as war files to Java app servers. At this point the interest in Perl would have to be due to some intrinsic language feature that might help broaden your ideas about programming in general (the way that, say, Haskell or Io might).
- hernan7 16y ago
  My recommendation as a (mostly) Perl programmer is, learn AWK first if you are not familiar with it. If your line of work is mostly website development, it's probably better to stick with PHP and Ruby in my opinion. Maybe look around CPAN a bit, see if you find any libraries that you think might be useful, and are not available on PHP or Ruby.
- jbjohns 16y ago
  Personally if you're looking to learn another language I wouldn't bother with Perl. It's close enough to what you already know that you probably wont learn much [1]. You'll get more milage out of trying something like Smalltalk (Squeak is free and a decent environment) if you want to really learn OO inside out, Haskell if you want to learn functional (this will bend your mind for a while at first, don't give up!), Erlang could be interesting but very unlike most other things. [1] You can probably learn things in Perl that you couldn't in PHP but if you pick a more pure language the lessons will stick out more. Perl also has a lot of extremely bad practices by default.
scalyweb 16y ago
I've been working with Perl on and off since 1997 and similar to many I've been disgusted by some of the code I've come across created during that time. Perl has come a long way even since version 5.0.0 and is quite a different character these days. The problem I've had with recommending the language is that unlike C which really hasn't changed(at least to me), Perl has slowly evolved but many of the books in print still point to the older version. While Perl is excellent in maintaining backward-compatibility with earlier versions, knowing and learning the "modern" versions has been a more painful task then it should be. I think this book changes that. I just spent about 30 minutes skimming through it. It's only 260 pages in clear and articulate English. Should this be THE new Perl book? Could be...I think this coupled with Effective Perl Programming that came out a few months ago are great for getting onboard or returning to the world of Perl. Hats off to you Chromatic for your work on this. There may not be any reasons to learn Perl if you already know Ruby/Python/Tcl/Lua but you certainly won't be worse for it if you do. At the end of the day, it's just another tool and I love having access to so many great ones these days.
rjurney 16y ago
I took a six month break from Perl. I know it better than any other language. I recently started using it again for one offs. I love Perl. It is so much fun to be totally fluent in a language. Then I wrote a one page app in it. Oh my god, I can't believe anyone still uses Perl. Its strange. I love it. I hate it. Its great. Its a piece of shit. I am familiar with Modern Perl practices... I just can't understand why anyone without a massive legacy codebase bothers.
- chromatic 16y ago
  I just can't understand why anyone without a massive legacy codebase bothers. With modern Perl 5, some CPAN modules, and a little bit of discipline, I can write a thousand line application to the delight of my client without the language, the libraries, or the tools ever getting in my way. I can't say that of any other language.
- jrockway 16y ago
  My experience is the opposite. I've used Perl for one-page web apps. I've used Perl for one-hundred-page web apps. I've used Perl for HTTP load testing. I've used Perl for high performance messaging. I've used Perl for writing desktop apps. Every time I do it, I finish and say, "this is great". The code is easy to read. The code is easy to extend. The code is easy to test. The code is easy to deploy. And I had fun making it. And it's fast. For stitching together complex apps that need to interact with the outside world and not randomly die, Perl is the best tool there is. Incidentally, people tend to think the opposite -- Perl is for text munging oneoffs, not for complex apps. This isn't my experience, though. Perl is great for gluing things together, but it's not the best tool for performing compute-heavy work on data. Situations where Perl has served me well: "Produce a CSV file from this data derived from a web page and this database and this C-based analytics library." "Open up as many HTTP connections to this server as possible." "Accept connections from 30,000 clients, and send them a JSON message when a certain event occurs." "Allow someone to interactively edit a complex data structure on the web." "Send a message to server a, poll server b until the message comes back, and report the latency to a monitoring tool over XMLRPC, and write the result to a database." etc. These worked well because of the great tools I have available in Perl. Moose, with MooseX and roles, to keep my code organized. Bread::Board for making it easy to wire components together, without sacrificing modularity. 100s of Test:: modules to make it easy to exercise all my code ("unit" and "integration" are both really easy with Perl). EV for high-performance IO. Coro for making the async-IO code look "normal". AnyEvent for writing modules that do async IO, without requiring the author to make a decision about which event loop to use. Plack for making all my web apps look the same to the server. Tatsumaki for making streaming easy. Catalyst for making big apps easy. DBIx::Class for making complicated database queries easy. KiokuDB for making my in-memory data persistent. Situations where Perl has not served me well: "Write a language independent API that adds a tiny bit of business logic over a network protocol." "Load data via a proprietary and buggy C-based library, do complex transformation and normalization, and write the fixed data to a new file." Why did Perl fail? In the first case, because there is a mental hangup of linking Python or Java with -lperl, even though it's easy to write the C to expose Perl modules to *. It's easier to write your simple "value-add" in C, because then everyone can use it and they feel like they are not making any political decision. And it turns out that C is not that difficult if you are willing to think like a defensive programmer when programming in it! In the second case, Perl was slow. Writing an XS binding is straightforward, but not trivial. Creating objects, something you need to have at least somewhat-organized code, billions of times is... pricey. Doing a lot of work on a lot of data just isn't very fast. So I use Haskell for this type of work instead. It's trivial to write a binding to a C library (you can do it interactively with ghci and :load, no compilation necessary!), and you can write an expressive, maintainable, abstract program to operate on your data without sacrificing any runtime speed. In conclusion, you might be doing it wrong. Or you might have picked a bunch of tasks that Perl is bad at and not stopped to notice how good it is at everything else.
kevinpet 16y ago
This looks interesting and I'm always happy to see good documentation appear, even if for a language I rarely use. My one suggestion would be a PDF typeset for on-screen reference. The font size is very hard to read at "best fit" on a 1152px high screen, even when maximized. If you wanted to match the print page numbers, you could cut down the margins on the electronic version.
- chromatic 16y ago
  I thought about that earlier today. This PDF will become the printed version, but I can render a version for letter-sized paper and another for A4. If I had a good sense of what's most readable on screen, I'd do that too (though the epub version is easiest). There's no strict need to keep the page numbers identical across versions.
tszming 16y ago
For web developments, be sure to check out the Mojolicious framework (created by the founder of Catalyst). When used with PSGI and Moose, a lot of interesting stuffs can be built. http://mojolicious.org http://mojolicious.org
- adrianhoward 16y ago
  Folk should also take a look at Catalyst http://www.catalystframework.org/ http://www.catalystframework.org/, Dancer http://perldancer.org/ http://perldancer.org/ and Jifty http://jifty.org/ http://jifty.org/ - they're all nice to work with. Dancer being my current fave :-)
  - tszming 16y ago
    Thanks for introducing me to jifty, looks cool.
adrianhoward 16y ago
Glad to see the book - and it looks a good read. Perl really has evolved as a language & community over the last few years and it's still my go-to language for my own projects. Despite having been mostly Python/PHP on the dev side the last couple of years - and being a huge Ruby fan. The core of the language still has some warts - but there's still some interesting stuff to play with. Three reasons to have a look at the language if you haven't before (or take another look if you've been away from perl for a few years): * Moose - http://moose.perl.org http://moose.perl.org - is becoming the de facto OO layer on top of Perl's basic OO system. It has some interesting features that you don't see in most other OO languages (Roles for example.) * CPAN - http://search.cpan.org http://search.cpan.org - the library of perl modules. Interesting for a couple of reasons. First it's scope is amazing. When I need to talk to some weird API there's usually something there to help. Cuts development time enormously. Second - the infrastructure of CPAN itself is fascinating. The way that things like http://cpantesters.org http://cpantesters.org, http://search.cpan.org http://search.cpan.org, the standard methods for building libaries and modules, etc. all work together is an interesting software ecology. Worthy of study. Lessons to be learned there for gems et al. * Testing. The testing infrastructure in perl is _amazing_. It's the best I've used in any language. That's because it's evolved around a language/framework agnostic testing protocol TAP (http://en.wikipedia.org/wiki/Test_Anything_Protocol http://en.wikipedia.org/wiki/Test_Anything_Protocol) that allows many different styles of testing to co-exist in the same test running framework. Really nice stuff.
- gaius 16y ago
  The testing infrastructure in perl is _amazing_. It's the best I've used in any language. Well, it has to be, because it's too difficult to second-guess when Perl will DWIM and when it won't. So you have to move a whole lot of complexity out of where it should be, the compiler, and into your own head and your own code. Check out Haskell's QuickCheck for this done right.
  - adrianhoward 16y ago
    No. That really isn't the issue that I see at all. I've used Haskell's QuickCheck. Declarative testing is lovely. But it's one particular approach to testing - suitable for finding a class of problems and bugs. TDD via an xUnit framework is another approach - suitable for finding another class of problems and bugs (after, of course, driving the design - which is it's main purpose). Style/lint testing is another approach to finding a different class of problems and bugs. Load testing is another approach to finding a different class of problems and bugs. The most languages it's an annoying pain to get different kinds of testing framework. TAP and Perl's testing framework makes that really easy. In Haskell if I want to combine doing TDD with HUnit and declarative testing with QuickCheck - I have to do work to get both frameworks running and integrated at the same time. In Perl if I want to combine doing TDD with Test::Class and declarative testing with Test::Lectrotest (the QuickCheck style testing library for Perl - http://search.cpan.org/dist/Test-LectroTest http://search.cpan.org/dist/Test-LectroTest) it comes out of the box - because they both output TAP. I can even interleave declarative styles test inside my xUnit tests - because the both output TAP. If I discover I need to write some custom test library to poke at some specific corners of my app - I can just output TAP and it's instantly integrated with the rest of my test framework. Stupidly useful.
mhd 16y ago
Quickly browsing through it, it looks quite okay. I'm just a bit sad that "modern Perl" is OO Perl, and not more in the style of Higher-Order Perl.
- chromatic 16y ago
  I'm just a bit sad that "modern Perl" is OO Perl, and not more in the style of Higher-Order Perl. There's an element of practicality. Perl doesn't force the use of any specific paradigm, but as it's not a pure functional language, the dominant paradigm for maintainable, large applications tends to be OO.

85 points by another_ali 16y ago

Ok, I am a solid PHP developer, pretty advanced with Ruby, and can do front end code and JQuery with my eyes closed. Should I be interested in Perl? Is there any reason to learn it if I know these other languages? I am genuinely curious

revoltingx 16y ago
Well, if you are advanced with Ruby then you're probably set. However, Perl is still an excellent language for building scalable web systems in no time. With 'Modern Perl' you get 'Ruby on Rails' style of programming in Perl, and with Perl you get the tons of libraries in CPAN. I wouldn't recommend learning Perl if you already know Ruby. For the same reason I wouldn't learn Python or Ruby because I know Perl. I'd learn something different like Erlang.
- jamesbritt 16y ago
  With 'Modern Perl' you get 'Ruby on Rails' style of programming in Perl What exactly does that mean? Optional parenthesis on method invocations? Considerable use of convention over configuration? Built-in object mapping to database schemas?
  - revoltingx 16y ago
    Optional parenthesis on method invocations? Yes, but that comes with Perl. (I don't find that even remotely useful. I like to know if a variable is calling a method or a member simply by looking at the code.) Considerable use of convention over configuration? Not sure what you mean here. Built-in object mapping to database schemas? Yes. I'm also referring to the clean MVC/OO style project architecture. Here's how I described it in another thread: With modern Perl, code is usually clean and free of crazy syntax. With a OO architecture where the base classes do most of the work (such as auto authentication, auto encoding/decoding, auto DB joins, etc.) and you do business/game logic in the upper modules.
    - jamesbritt 16y ago
      "With modern Perl, code is usually clean and free of crazy syntax. With a OO architecture where the base classes do most of the work (such as auto authentication, auto encoding/decoding, auto DB joins, etc.) and you do business/game logic in the upper modules." Ah, OK. That just sounds like Ruby, though, nothing special to Rails about that.
      - revoltingx 16y ago
        Last time I checked, Rails provides a lot of built-in functionality for building web apps. But perhaps I got Rails confused with Ruby with my brief experience with it. I thought Rails provided the tools to auto-create your project structure in an MVC style. If you use something like Catalyst of CGI::Application you get built in things like MVC project structure, auto populate a 'class' from a table entry, etc. Basically, you get all those built-in functionality for building web apps that you would in Rails. But, I very briefly played with Rails, so I may have its definition confused.
        jamesbritt 16y ago
        I see. So CGI::Application (and Catalyst) is a built-in part of modern Perl. Interesting.
msbarnett 16y ago
On the one hand, I tend to think that learning a new language or tool kit is always a valuable experience. On the other hand I switched from Perl to Ruby as my go-to scripting language about 6 years ago and haven't felt like there were any niches which Perl serviced that Ruby failed to, for my uses. Still, I'd say try it out for a few small things; you might find that Perl better fits the way you think, and if not, at least you can say you know a bit of Perl if anyone ever asks.
- drac 16y ago
  By and large, I've had the opposite problem making a lasting switch from Perl to Ruby. I know Perl better than most other languages in my toolbox, and it's my default prototyping and one-off utility language. I don't find a lot of niches (for my typical uses, of course) that are served better by Ruby, so it's been really difficult to switch away from Perl.
sigzero 16y ago
I like Perl. Given what you have said above it would be hard for me to say "Yes, give Perl a try" except to say "You should give Perl a try." The reason I say that is because a programming language is just like a religion. You will like it or you will not (even with its quirks).
rtra 16y ago
some interesting comments on Perl: http://lambda-the-ultimate.org/node/3564 http://lambda-the-ultimate.org/node/3564 This is also good: http://www.perl.com/pub/2007/12/06/soto-11.html http://www.perl.com/pub/2007/12/06/soto-11.html
deleted 16y ago
[deleted]
jamesbritt 16y ago
I went from Perl to Ruby about 10 years ago, and I can't say there's anything I miss. Certainly, at the start, running Web apps was easier in Perl because most servers had mod_perl out of the box. But for day-to-day tasks I found I much preferred Ruby. The reasons for this, though, are as likely personal aesthetics as anything else. Nowadays Phusion Passenger makes Rack-based Web apps snake-simple, and using JRuby gives me all of the Java libs out there (including Swing for insanely-easy cross-platform GUI apps when teamed with Monkeybars), as well the option to deploy Web apps as war files to Java app servers. At this point the interest in Perl would have to be due to some intrinsic language feature that might help broaden your ideas about programming in general (the way that, say, Haskell or Io might).
hernan7 16y ago
My recommendation as a (mostly) Perl programmer is, learn AWK first if you are not familiar with it. If your line of work is mostly website development, it's probably better to stick with PHP and Ruby in my opinion. Maybe look around CPAN a bit, see if you find any libraries that you think might be useful, and are not available on PHP or Ruby.
jbjohns 16y ago
Personally if you're looking to learn another language I wouldn't bother with Perl. It's close enough to what you already know that you probably wont learn much [1]. You'll get more milage out of trying something like Smalltalk (Squeak is free and a decent environment) if you want to really learn OO inside out, Haskell if you want to learn functional (this will bend your mind for a while at first, don't give up!), Erlang could be interesting but very unlike most other things. [1] You can probably learn things in Perl that you couldn't in PHP but if you pick a more pure language the lessons will stick out more. Perl also has a lot of extremely bad practices by default.

scalyweb 16y ago

I've been working with Perl on and off since 1997 and similar to many I've been disgusted by some of the code I've come across created during that time. Perl has come a long way even since version 5.0.0 and is quite a different character these days. The problem I've had with recommending the language is that unlike C which really hasn't changed(at least to me), Perl has slowly evolved but many of the books in print still point to the older version. While Perl is excellent in maintaining backward-compatibility with earlier versions, knowing and learning the "modern" versions has been a more painful task then it should be. I think this book changes that. I just spent about 30 minutes skimming through it. It's only 260 pages in clear and articulate English. Should this be THE new Perl book? Could be...I think this coupled with Effective Perl Programming that came out a few months ago are great for getting onboard or returning to the world of Perl. Hats off to you Chromatic for your work on this. There may not be any reasons to learn Perl if you already know Ruby/Python/Tcl/Lua but you certainly won't be worse for it if you do. At the end of the day, it's just another tool and I love having access to so many great ones these days.

rjurney 16y ago

I took a six month break from Perl. I know it better than any other language. I recently started using it again for one offs. I love Perl. It is so much fun to be totally fluent in a language. Then I wrote a one page app in it. Oh my god, I can't believe anyone still uses Perl. Its strange. I love it. I hate it. Its great. Its a piece of shit. I am familiar with Modern Perl practices... I just can't understand why anyone without a massive legacy codebase bothers.

chromatic 16y ago
I just can't understand why anyone without a massive legacy codebase bothers. With modern Perl 5, some CPAN modules, and a little bit of discipline, I can write a thousand line application to the delight of my client without the language, the libraries, or the tools ever getting in my way. I can't say that of any other language.
jrockway 16y ago
My experience is the opposite. I've used Perl for one-page web apps. I've used Perl for one-hundred-page web apps. I've used Perl for HTTP load testing. I've used Perl for high performance messaging. I've used Perl for writing desktop apps. Every time I do it, I finish and say, "this is great". The code is easy to read. The code is easy to extend. The code is easy to test. The code is easy to deploy. And I had fun making it. And it's fast. For stitching together complex apps that need to interact with the outside world and not randomly die, Perl is the best tool there is. Incidentally, people tend to think the opposite -- Perl is for text munging oneoffs, not for complex apps. This isn't my experience, though. Perl is great for gluing things together, but it's not the best tool for performing compute-heavy work on data. Situations where Perl has served me well: "Produce a CSV file from this data derived from a web page and this database and this C-based analytics library." "Open up as many HTTP connections to this server as possible." "Accept connections from 30,000 clients, and send them a JSON message when a certain event occurs." "Allow someone to interactively edit a complex data structure on the web." "Send a message to server a, poll server b until the message comes back, and report the latency to a monitoring tool over XMLRPC, and write the result to a database." etc. These worked well because of the great tools I have available in Perl. Moose, with MooseX and roles, to keep my code organized. Bread::Board for making it easy to wire components together, without sacrificing modularity. 100s of Test:: modules to make it easy to exercise all my code ("unit" and "integration" are both really easy with Perl). EV for high-performance IO. Coro for making the async-IO code look "normal". AnyEvent for writing modules that do async IO, without requiring the author to make a decision about which event loop to use. Plack for making all my web apps look the same to the server. Tatsumaki for making streaming easy. Catalyst for making big apps easy. DBIx::Class for making complicated database queries easy. KiokuDB for making my in-memory data persistent. Situations where Perl has not served me well: "Write a language independent API that adds a tiny bit of business logic over a network protocol." "Load data via a proprietary and buggy C-based library, do complex transformation and normalization, and write the fixed data to a new file." Why did Perl fail? In the first case, because there is a mental hangup of linking Python or Java with -lperl, even though it's easy to write the C to expose Perl modules to *. It's easier to write your simple "value-add" in C, because then everyone can use it and they feel like they are not making any political decision. And it turns out that C is not that difficult if you are willing to think like a defensive programmer when programming in it! In the second case, Perl was slow. Writing an XS binding is straightforward, but not trivial. Creating objects, something you need to have at least somewhat-organized code, billions of times is... pricey. Doing a lot of work on a lot of data just isn't very fast. So I use Haskell for this type of work instead. It's trivial to write a binding to a C library (you can do it interactively with ghci and :load, no compilation necessary!), and you can write an expressive, maintainable, abstract program to operate on your data without sacrificing any runtime speed. In conclusion, you might be doing it wrong. Or you might have picked a bunch of tasks that Perl is bad at and not stopped to notice how good it is at everything else.

kevinpet 16y ago

This looks interesting and I'm always happy to see good documentation appear, even if for a language I rarely use. My one suggestion would be a PDF typeset for on-screen reference. The font size is very hard to read at "best fit" on a 1152px high screen, even when maximized. If you wanted to match the print page numbers, you could cut down the margins on the electronic version.

chromatic 16y ago
I thought about that earlier today. This PDF will become the printed version, but I can render a version for letter-sized paper and another for A4. If I had a good sense of what's most readable on screen, I'd do that too (though the epub version is easiest). There's no strict need to keep the page numbers identical across versions.

tszming 16y ago

For web developments, be sure to check out the Mojolicious framework (created by the founder of Catalyst). When used with PSGI and Moose, a lot of interesting stuffs can be built. http://mojolicious.org http://mojolicious.org

adrianhoward 16y ago
Folk should also take a look at Catalyst http://www.catalystframework.org/ http://www.catalystframework.org/, Dancer http://perldancer.org/ http://perldancer.org/ and Jifty http://jifty.org/ http://jifty.org/ - they're all nice to work with. Dancer being my current fave :-)
- tszming 16y ago
  Thanks for introducing me to jifty, looks cool.

adrianhoward 16y ago

Glad to see the book - and it looks a good read. Perl really has evolved as a language & community over the last few years and it's still my go-to language for my own projects. Despite having been mostly Python/PHP on the dev side the last couple of years - and being a huge Ruby fan. The core of the language still has some warts - but there's still some interesting stuff to play with. Three reasons to have a look at the language if you haven't before (or take another look if you've been away from perl for a few years): * Moose - http://moose.perl.org http://moose.perl.org - is becoming the de facto OO layer on top of Perl's basic OO system. It has some interesting features that you don't see in most other OO languages (Roles for example.) * CPAN - http://search.cpan.org http://search.cpan.org - the library of perl modules. Interesting for a couple of reasons. First it's scope is amazing. When I need to talk to some weird API there's usually something there to help. Cuts development time enormously. Second - the infrastructure of CPAN itself is fascinating. The way that things like http://cpantesters.org http://cpantesters.org, http://search.cpan.org http://search.cpan.org, the standard methods for building libaries and modules, etc. all work together is an interesting software ecology. Worthy of study. Lessons to be learned there for gems et al. * Testing. The testing infrastructure in perl is _amazing_. It's the best I've used in any language. That's because it's evolved around a language/framework agnostic testing protocol TAP (http://en.wikipedia.org/wiki/Test_Anything_Protocol http://en.wikipedia.org/wiki/Test_Anything_Protocol) that allows many different styles of testing to co-exist in the same test running framework. Really nice stuff.

gaius 16y ago
The testing infrastructure in perl is _amazing_. It's the best I've used in any language. Well, it has to be, because it's too difficult to second-guess when Perl will DWIM and when it won't. So you have to move a whole lot of complexity out of where it should be, the compiler, and into your own head and your own code. Check out Haskell's QuickCheck for this done right.
- adrianhoward 16y ago
  No. That really isn't the issue that I see at all. I've used Haskell's QuickCheck. Declarative testing is lovely. But it's one particular approach to testing - suitable for finding a class of problems and bugs. TDD via an xUnit framework is another approach - suitable for finding another class of problems and bugs (after, of course, driving the design - which is it's main purpose). Style/lint testing is another approach to finding a different class of problems and bugs. Load testing is another approach to finding a different class of problems and bugs. The most languages it's an annoying pain to get different kinds of testing framework. TAP and Perl's testing framework makes that really easy. In Haskell if I want to combine doing TDD with HUnit and declarative testing with QuickCheck - I have to do work to get both frameworks running and integrated at the same time. In Perl if I want to combine doing TDD with Test::Class and declarative testing with Test::Lectrotest (the QuickCheck style testing library for Perl - http://search.cpan.org/dist/Test-LectroTest http://search.cpan.org/dist/Test-LectroTest) it comes out of the box - because they both output TAP. I can even interleave declarative styles test inside my xUnit tests - because the both output TAP. If I discover I need to write some custom test library to poke at some specific corners of my app - I can just output TAP and it's instantly integrated with the rest of my test framework. Stupidly useful.

mhd 16y ago

Quickly browsing through it, it looks quite okay. I'm just a bit sad that "modern Perl" is OO Perl, and not more in the style of Higher-Order Perl.

chromatic 16y ago
I'm just a bit sad that "modern Perl" is OO Perl, and not more in the style of Higher-Order Perl. There's an element of practicality. Perl doesn't force the use of any specific paradigm, but as it's not a pure functional language, the dominant paradigm for maintainable, large applications tends to be OO.