Modern Perl: The Book: The (draft) PDF
31–40 of 50 posts
Re: Modern Perl: The Book: The (draft) PDF
#32Glad 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 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.
Re: Modern Perl: The Book: The (draft) PDF
#33Earlier quoted context omitted.
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?
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 d…
Ah, OK. That just sounds like Ruby, though, nothing special to Rails about that.
Re: Modern Perl: The Book: The (draft) PDF
#34Glad 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 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.
I've personally never seen this issue when testing perl code.
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
Actually the perl compiler with use strict; use warnings catches a lot more at compile time compared to most other dynamic languages.
Re: Modern Perl: The Book: The (draft) PDF
#35Earlier quoted context omitted.
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 d…
"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.
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.
Re: Modern Perl: The Book: The (draft) PDF
#36Glad 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 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.
You don't need to guess, never. I can recommend a book which explains how Perl 5 works (and which features to avoid because they're too difficult for novices--and sometimes experts--to use correctly).
Re: Modern Perl: The Book: The (draft) PDF
#37Earlier quoted context omitted.
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 ma…
You listed a lot of things you need to get to get Perl to work for you. In big orgs that would mean a lot of battling. For me it's just not worth the fight when e.g. Python just comes with half those things.
I install Python and most of the libraries I want are included,(batteries included).
I install Perl and most of the libraries I want are included, (batteries also included).
With Perl I've got CPAN available to install any libraries that I may be missing.
Python may have some advantages over Perl, but "alot of things needed to get the language to work for you" isn't one of them. In this respect I think Perl is heads and shoulders above Python.
Re: Modern Perl: The Book: The (draft) PDF
#38Quickly 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.
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.
Re: Modern Perl: The Book: The (draft) PDF
#39Earlier quoted context omitted.
"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.
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. Basica…
Re: Modern Perl: The Book: The (draft) PDF
#40Earlier quoted context omitted.
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 ma…
Greetings jrock, I think you are underestimating your own complexity, you seem to know a lot about lot. And most people don't, does one really need to be that advanced to appreciate Perl? I hope not
I would worry if most programmers couldn't do those things in their $LANGUAGE.