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
Dancer being my current fave :-)
21–30 of 50 posts
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
Dancer being my current fave :-)
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…
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.
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…
And most people don't, does one really need to be that advanced to appreciate Perl? I hope not
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…
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.
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…
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.
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 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...)
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…
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.
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.
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.
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
[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.
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…