Live data from Hacker News

Modern Perl: The Book: The (draft) PDF

modernperlbooks.com

21–30 of 50 posts

Re: Modern Perl: The Book: The (draft) PDF

#21
post #19

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

Folk should also take a look at Catalyst http://www.catalystframework.org/, Dancer http://perldancer.org/ and Jifty http://jifty.org/ - they're all nice to work with.

Dancer being my current fave :-)

Re: Modern Perl: The Book: The (draft) PDF

#22
post #13

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 an…

I too have the opposite experience :-)

With something like Dancer the simple stuff is just as neat as playing with Sinatra/Ruby - with CPAN to pull upon for large chunks of functionality and a wonderful testing environment.

Much as I love ruby - I can just get stuff done so much faster because of CPAN. Less code to write.

Re: Modern Perl: The Book: The (draft) PDF

#23
post #13

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 an…

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

Re: Modern Perl: The Book: The (draft) PDF

#24
post #13

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 an…

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…

The code is easy to read. The code is easy to extend. The code is easy to test. The code is easy to deploy

I don't doubt that it is, for its author - but that's what all Perl programmers believe.

Why did Perl fail?

For no purely technical reason. It failed because too many people got burned on inheriting horrifying tangles of spaghetti legacy code and vowed, never again. There's just not a critical mass (left) in the Perl community who believe that the target audience of their code is the next programmer who works on it.

Re: Modern Perl: The Book: The (draft) PDF

#25

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 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

#26
post #24

Earlier 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…

The code is easy to read. The code is easy to extend. The code is easy to test. The code is easy to deploy I don't doubt that it is, for its author - but that's what all Perl programmers believe. Why did Perl fail? For no purely technical reason. It failed because too many people got burned on inheriting horrifying tangles of spaghetti legacy code and vowed, never again. There's just not a critical mass (left) in the…

I agree with you up until "There's just not a critical mass (left) in the Perl community who believe that the target audience of their code is the next programmer who works on it."

I think those people left and moved to PHP. All that's left in the Perl community are a bunch of people who think tests and readable modular code are good. (Not everyone implements this really well, but at least it's in mind.)

And by community, I mean "people that write CPAN modules and hang out on IRC", not "people that submitted their resume to the open 'PERL' position". Those people are more than happy to write spaghetti, but it's because the market allows it. Start firing people for writing crap code, and start paying the people that write great code a lot of money, and you'll see a lot of great code -- Perl or otherwise. As it stands now, code quality and pay are not linked, so there is a lot of bad code being written for a lot of money.

(Ask me about 10,000 lines of C++ to encrypt a password and send it over a socket...)

Re: Modern Perl: The Book: The (draft) PDF

#27
post #24

Earlier 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…

The code is easy to read. The code is easy to extend. The code is easy to test. The code is easy to deploy I don't doubt that it is, for its author - but that's what all Perl programmers believe. Why did Perl fail? For no purely technical reason. It failed because too many people got burned on inheriting horrifying tangles of spaghetti legacy code and vowed, never again. There's just not a critical mass (left) in the…

By and large the legacy problem isn't because Perl is a bad language per se - but because it's and old language (in popular usage).

Old code in _any_ language tends to be bad. Popular languages especially since popular languages attract more bad developers (there is a reason there isn't a "Clojure for Dummies" book :-)

I've seen horrible Ruby & Python. I've seen horrible PHP. I've seen horrible Lisp and Smalltalk. I've seen horrible C and C++. Pretty much any language that's been around more than a couple of years and has become popular has really ghastly legacy code.

(And yes - lots of horrible Perl)

There's just not a critical mass (left) in the Perl community who believe that the target audience of their code is the next programmer who works on it

Ironically I think that's the exact opposite of the current problem. The vast majority of the Perl developers I encounter now care very deeply about exactly those topics.

That's because the people who don't care are off playing with the new and shiny toys :-) I absolutely guarantee that in five years we'll have folk complaining about this horrible legacy Rails code - and this is why everybody is now using Clojure (or whatever).

I can pick out problems in the Perl community - but lack of a focus on quality is not one of them.

People see horrible code and think that it's because of a horrible language.

Horrible code is because of horrible (or novice) developers. Or good developers working under horrible management.

Bad legacy code isn't primarily a problem of language. It's a problem of time.

Re: Modern Perl: The Book: The (draft) PDF

#28
post #25

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 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.

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) 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.

Re: Modern Perl: The Book: The (draft) PDF

#29
post #2

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

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.

Re: Modern Perl: The Book: The (draft) PDF

#30
post #13

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 an…

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.
Post reply on HN