What is Modern Perl(josetteorama.com)
josetteorama.com
What is Modern Perl
http://www.josetteorama.com/perl/what-is-modern-perl/http://www.josetteorama.com/perl/what-is-modern-perl/
45 comments
>>But it isn't as approachable as Python.
Minimalism, is both an advantage and a curse. You may be able to learn python quickly, and that is because the syntax and semantics are designed with a goal to do that. But unfortunately that is not the only problem programmers have, Learning how to program is problem only for first few weeks of your programming career, there after its hardly a problem. Beyond that verbosity becomes a curse, once you begin to understand what 10's of lines of code do, you wonder why you even need 10's of lines of code when something can be expressed more elegantly.
In my experience people complain about learning Perl for the same reasons why they don't get awk/sed/tr and other text processing utilities. Tools like that are a little difficult to start with, but offer tremendous advantages. Skip learning them, and suddenly you put yourself in a situation where you start your eclipse and write Java programs for every small bit of text processing task. That sucks up your time, effort and code forever. So its better to learn tools that are better designed to solve such problems.
>>and I'm not sure why Perl would be better.
Perl and Python are both excellent languages, so you find a range of problems that can be solved in both languages well. But try solving problems that Perl was specifically designed to solve, Pick up the book Higher Order Perl by Mark Jason Dominus(Its Free) and see for yourself how Perl helps you solve a certain kind of problems. I'm sure its the same case with Python too! Its good for academia, as its easy psuedocode.
Problems that can be solved in both Python and Perl can obviously be solved in any of them.
>>So to my mind, Perl is something of a sysadmin tool, better than bash and very useful for a workload focussed on system and file processing, on *nix, without much service to HTTP. I'd love to hear how it pays returns for people more focussed on back-end support of web development.
You have just described a very small subset of problems Perl can solve. Perl is used for developing very large application in nearly almost every industry.
Web programming != Entire Programming world.
Much of the software world never writes a web page. And they do programming too. But like us they don't tweet/Facebook/blog every time they finish writing a class.
Minimalism, is both an advantage and a curse. You may be able to learn python quickly, and that is because the syntax and semantics are designed with a goal to do that. But unfortunately that is not the only problem programmers have, Learning how to program is problem only for first few weeks of your programming career, there after its hardly a problem. Beyond that verbosity becomes a curse, once you begin to understand what 10's of lines of code do, you wonder why you even need 10's of lines of code when something can be expressed more elegantly.
In my experience people complain about learning Perl for the same reasons why they don't get awk/sed/tr and other text processing utilities. Tools like that are a little difficult to start with, but offer tremendous advantages. Skip learning them, and suddenly you put yourself in a situation where you start your eclipse and write Java programs for every small bit of text processing task. That sucks up your time, effort and code forever. So its better to learn tools that are better designed to solve such problems.
>>and I'm not sure why Perl would be better.
Perl and Python are both excellent languages, so you find a range of problems that can be solved in both languages well. But try solving problems that Perl was specifically designed to solve, Pick up the book Higher Order Perl by Mark Jason Dominus(Its Free) and see for yourself how Perl helps you solve a certain kind of problems. I'm sure its the same case with Python too! Its good for academia, as its easy psuedocode.
Problems that can be solved in both Python and Perl can obviously be solved in any of them.
>>So to my mind, Perl is something of a sysadmin tool, better than bash and very useful for a workload focussed on system and file processing, on *nix, without much service to HTTP. I'd love to hear how it pays returns for people more focussed on back-end support of web development.
You have just described a very small subset of problems Perl can solve. Perl is used for developing very large application in nearly almost every industry.
Web programming != Entire Programming world.
Much of the software world never writes a web page. And they do programming too. But like us they don't tweet/Facebook/blog every time they finish writing a class.
I wouldn't sweat it if you are happy with Python. I haven't tried Python myself- I use Perl- but speaking to co-workers who prefer Python, when it comes to a glue language the two appear to be fairly interchangeable. There are some differences, but if all we are talking is glue, just go with what you like.
There is no One True Path.
But there's probably a great deal more value to be had to knowing just one of the big three scripting languages (Perl|Python|Ruby) deeply than in knowing just a smattering of each.
But there's probably a great deal more value to be had to knowing just one of the big three scripting languages (Perl|Python|Ruby) deeply than in knowing just a smattering of each.
I'd love to hear how it pays returns for people more focussed on back-end support of web development.
To pick one thing - Perl's testing infrastructure. It's just awesome. I miss it in other languages.
See http://news.ycombinator.com/item?id=4040005 for a discussion.
To pick one thing - Perl's testing infrastructure. It's just awesome. I miss it in other languages.
See http://news.ycombinator.com/item?id=4040005 for a discussion.
What is modern Perl? Python. (I'll elaborate more here from my earlier one-word answer).
Long-time perl programmer here, until I found Python. Perl is powerful, but Perl is for the programmer, not the programmer's coworkers. It's not even for the programmer 6 months down the line. This is nothing new, and it has become a stereotype in the community.
Yes, this argument has been made and refuted many times, but I argue the reason isn't the language, but the dominant language paradigms.
Perl's "monk" ideal is not sustainable in the long term, and encourages "clever hackers" who can do things with the fewest lines of fundamentally unreadable code. Yes, the language has evolved. Yes, it is slightly easier to read now. But the goals of the community still tend toward the ideals of becoming a master of arcana who can pass his wisdom down to the less experienced.
Give me a language that the commoners can read, that a beginning programmer can feel empowered to learn because he can take one look at the source code of someone truly experienced and know at least a part of what is going on.
You can change Perl all you want, but you cannot get away from the fundamental guiding principles of the language, which encourage antisocial, clever, and magic code.
Long-time perl programmer here, until I found Python. Perl is powerful, but Perl is for the programmer, not the programmer's coworkers. It's not even for the programmer 6 months down the line. This is nothing new, and it has become a stereotype in the community.
Yes, this argument has been made and refuted many times, but I argue the reason isn't the language, but the dominant language paradigms.
Perl's "monk" ideal is not sustainable in the long term, and encourages "clever hackers" who can do things with the fewest lines of fundamentally unreadable code. Yes, the language has evolved. Yes, it is slightly easier to read now. But the goals of the community still tend toward the ideals of becoming a master of arcana who can pass his wisdom down to the less experienced.
Give me a language that the commoners can read, that a beginning programmer can feel empowered to learn because he can take one look at the source code of someone truly experienced and know at least a part of what is going on.
You can change Perl all you want, but you cannot get away from the fundamental guiding principles of the language, which encourage antisocial, clever, and magic code.
I rarely resort to magic code in Perl. I sometimes do because I can't find a better way to do it, and then I comment it as such. Comments are wonderful things when used properly.... If only more programmers in any language used them properly...
I have seen so much really wonderful, readible, maintainable Perl code, that I don't think your characterization works.
You know if I come back a couple months later and don't like my code, I rewrite it based on my objections. It doesn't happen often but it does sometimes. It happens in any language.
If you value maintainability, you will eventually write maintainable code. The only flaw Perl has is in promoting valuing getting things done more than maintainability, but that's a culture of programmers, not the language. You can get good groups together than can write beautiful, maintainable code. I have done it. I know.
I have seen so much really wonderful, readible, maintainable Perl code, that I don't think your characterization works.
You know if I come back a couple months later and don't like my code, I rewrite it based on my objections. It doesn't happen often but it does sometimes. It happens in any language.
If you value maintainability, you will eventually write maintainable code. The only flaw Perl has is in promoting valuing getting things done more than maintainability, but that's a culture of programmers, not the language. You can get good groups together than can write beautiful, maintainable code. I have done it. I know.
> What is modern Perl? Python.
I am also a Perl to Python refugee. For most applications I get far more enjoyment out of Python. But try implementing Higher Order Perl in Python and you won't get past Chapter 1 without some weirdness. Using decorators, lambda, map, reduce, itertools, even generators all feel like bending over backwards to achieve what comes naturally in Perl.
This isn't an attack on Python. I'm just saying, Python is not meant for functional programming any more than Perl excels at OO, and that's why I disagree with your thesis.
>>any more than Perl excels at OO
Check Moose and related on CPAN, modern Perl has probably the best OO among the usual scripting languages (Python, PHP, Ruby, etc).
Check Moose and related on CPAN, modern Perl has probably the best OO among the usual scripting languages (Python, PHP, Ruby, etc).
There is advantage of Perl developers tho. If I hire perl dev I know for sure he is language addict and do stuff efficiently. Because perl developers use Perl not because it paid well (like ruby), but because they like it.
So you say that Python is Perl? It cannot be modern Perl without being Perl.
I think that both Perl and Python programmers disagree with your statement.
I think that both Perl and Python programmers disagree with your statement.
As a Perl and Python developer, I would have to say that my limited experience with Ruby gives me the impression that it's closer to Perl than Python is.
Perl is for having work done in a minimal time. If you want to write code that is easy to read, learn Ada.
Python is probably a better balance. Perl is wonderful for all the small scripts I need every days. When something needs to be reused, it become a module with a good documentation.
I think nobody should read perl code except:
- to learn how to code.
- to modify a program you have written
Obvious trolling from a karma 20 account.
I'll enjoy Python when pypi doesn't frustrate me many times more than CPAN, there is some Python equivalent of Moose (Python 3.5, 4?) and the grammar is extensible like Perl 5 (using CPAN modules).
I'll enjoy Python when pypi doesn't frustrate me many times more than CPAN, there is some Python equivalent of Moose (Python 3.5, 4?) and the grammar is extensible like Perl 5 (using CPAN modules).
[deleted]
[deleted]
I actually own the domain modernperl,net, for trollish reasons actually (www.modernperl.net redirects to Ruby) but if anyone wants it / wants to do something useful with it. I'd be happy to transfer it to you for free.
I think you might want to contact chromatic so this domain could be setup to redirect to his http://modernperlbooks.com/mt/index.html
He gives away his ebook for free, so I guess giving him free domain might be very good for your karma :)
He gives away his ebook for free, so I guess giving him free domain might be very good for your karma :)
I started using Perl around 2006'ish, that was pretty late in the day compared to most Perl hackers. I was primarily a C/C++ Dev, going the OO way. And I was doing Java here and there.
Until one morning a colleague of mine, saw me doing some stuff I was taking really long to finish. He just walked up to my cubicle and just said 'Why dont you use Perl to do this' and then started my crazy journey with Perl. What I really like about languages like Perl/Python and Ruby is how quickly you can go from learning to building something really useful.
Perl has seen atleast 3 major rise in its popularity since its inception. First one among sysadmins, its from these days that you will powerful terse, small but elegant solutions to a range of problems. If you ever get a chance, do browse and read essays from Tom christiansen written during those times. They are just pure gem. The second was during Perl/CGI days. And third was the most recent with the Modern Perl movement. Much of the thanks for this goes to People like Chromatic, Audrey, People of p5p, Moose devs and etc. From each of those times, you will see varying variety of code written. Starting from really amazing one liners to at times some frustrating code during the dot com bubble, to now where Perl code really looks very nice.
Modern Perl really is set of many successful sub projects. And its not just code, it covers everything. Code is just the beginning. To give you an example, these days you have very nice cpan package managers. You can search packages using Metacpan in a very user friendly GUI with nice syntax highlighting. You have awesome documentation, Modern Perl book really is the Perl's equivalent of the K&R book. There is Moose, And there are things like Class::MOP. There are things like DBIx::Class.
In terms of other new breath taking stuff you will see things like Devel::Declare. This allows new syntax extensions to be written using Perl itself. Then as a result you have a range of modules like Moosex::<extensions>,Try::Catch, Gather::Take etc.
In terms of web frameworks your have Catalyst.
So its really these many many successful subprojects together which form 'Modern Perl', if you wish to describe it that way. Its no one thing. Code, documentation, culture, events, infrastructure etc etc all together form the 'Modern Perl' thing.
If you come to the Perl core development, then they have real good time based releases. They are fixing bugs, adding new features, and doing a lot of amazing stuff. There have been pretty neat syntax features added in the past few releases and I guess much of Perl 6 based features will continually seep into Perl 5 as needed over time.
Modern Perl, or other wise. Perl continues to retain its niche. Which is text heavy lifting, automation, rapid prototyping, development, a deep learing curve and larger gains in productivity with time. Its still the go-to tool for most back end tasks. If you wish to get something done faster, with little effort, sanely with little bugs in say over a weekend, You have little alternatives apart from Perl. If you are in dev ops and you have P1 tickets standing on your head pretty often, a tool like Perl is indispensible.
And most importantly its areas of strengths are only growing- Unicode, regular expressions, CPAN, powerful syntax etc. If you ever get a chance Higher Order Perl is one book you must read. It really opens your mind to elegant solution to a range of problems.
But like every other language, you need to invest time and effort incrementally to keep yourself updated.
Until one morning a colleague of mine, saw me doing some stuff I was taking really long to finish. He just walked up to my cubicle and just said 'Why dont you use Perl to do this' and then started my crazy journey with Perl. What I really like about languages like Perl/Python and Ruby is how quickly you can go from learning to building something really useful.
Perl has seen atleast 3 major rise in its popularity since its inception. First one among sysadmins, its from these days that you will powerful terse, small but elegant solutions to a range of problems. If you ever get a chance, do browse and read essays from Tom christiansen written during those times. They are just pure gem. The second was during Perl/CGI days. And third was the most recent with the Modern Perl movement. Much of the thanks for this goes to People like Chromatic, Audrey, People of p5p, Moose devs and etc. From each of those times, you will see varying variety of code written. Starting from really amazing one liners to at times some frustrating code during the dot com bubble, to now where Perl code really looks very nice.
Modern Perl really is set of many successful sub projects. And its not just code, it covers everything. Code is just the beginning. To give you an example, these days you have very nice cpan package managers. You can search packages using Metacpan in a very user friendly GUI with nice syntax highlighting. You have awesome documentation, Modern Perl book really is the Perl's equivalent of the K&R book. There is Moose, And there are things like Class::MOP. There are things like DBIx::Class.
In terms of other new breath taking stuff you will see things like Devel::Declare. This allows new syntax extensions to be written using Perl itself. Then as a result you have a range of modules like Moosex::<extensions>,Try::Catch, Gather::Take etc.
In terms of web frameworks your have Catalyst.
So its really these many many successful subprojects together which form 'Modern Perl', if you wish to describe it that way. Its no one thing. Code, documentation, culture, events, infrastructure etc etc all together form the 'Modern Perl' thing.
If you come to the Perl core development, then they have real good time based releases. They are fixing bugs, adding new features, and doing a lot of amazing stuff. There have been pretty neat syntax features added in the past few releases and I guess much of Perl 6 based features will continually seep into Perl 5 as needed over time.
Modern Perl, or other wise. Perl continues to retain its niche. Which is text heavy lifting, automation, rapid prototyping, development, a deep learing curve and larger gains in productivity with time. Its still the go-to tool for most back end tasks. If you wish to get something done faster, with little effort, sanely with little bugs in say over a weekend, You have little alternatives apart from Perl. If you are in dev ops and you have P1 tickets standing on your head pretty often, a tool like Perl is indispensible.
And most importantly its areas of strengths are only growing- Unicode, regular expressions, CPAN, powerful syntax etc. If you ever get a chance Higher Order Perl is one book you must read. It really opens your mind to elegant solution to a range of problems.
But like every other language, you need to invest time and effort incrementally to keep yourself updated.
I started in 2003 or so, and got into it more seriously because I ended up with customers to support using Perl software. Perl is an amazing language, and with many modern perl approaches, it's wonderful.
This being said like most frameworks it is extremely important to know when to leave the framework or leave things out. While I LOVE working with Moose, my own projects are very heavily stored procedure centric and therefore an ORM like DBIx::Class really does me very little good. DBIx::Class by all reports is an excellent ORM but it's still an ORM. ;-)
There is no better glue language I have ever encountered than Perl We use it in LedgerSMB to glue together stored procedures, web templates (in Template Toolkit), and the web server interfaces. It's a wonderful language and I can't recommend it highly enough.
As for Perl 6, it has joined HURD 1.0 as one of those projects that will be released when pigs fly. I suspect that Perl 5.x will be as far as Perl gets.
This being said like most frameworks it is extremely important to know when to leave the framework or leave things out. While I LOVE working with Moose, my own projects are very heavily stored procedure centric and therefore an ORM like DBIx::Class really does me very little good. DBIx::Class by all reports is an excellent ORM but it's still an ORM. ;-)
There is no better glue language I have ever encountered than Perl We use it in LedgerSMB to glue together stored procedures, web templates (in Template Toolkit), and the web server interfaces. It's a wonderful language and I can't recommend it highly enough.
As for Perl 6, it has joined HURD 1.0 as one of those projects that will be released when pigs fly. I suspect that Perl 5.x will be as far as Perl gets.
David Wheeler (theory) started working on a stored procedure centric project a while back and as a result extracted the DBIx::Class connection logic into DBIx::Connector - which I have a feeling you're already using.
I spent a fair amount of time hanging out in #ledgersmb a while back and in spite of being the project founder of DBIx::Class, I don't think I ever felt I had a convincing argument for using it, so honestly I'm glad you're not doing so (if I ever come up with an O<sproc>M or something I'm sure you'll find out :)
I spent a fair amount of time hanging out in #ledgersmb a while back and in spite of being the project founder of DBIx::Class, I don't think I ever felt I had a convincing argument for using it, so honestly I'm glad you're not doing so (if I ever come up with an O<sproc>M or something I'm sure you'll find out :)
Glad to see you again.
Actually some of your recommendations are pending getting rid of old code (we simply can't move everything to PSGI when we have the mixture of old and new code we have, so it's CGI only for now still). However we are giving hard thought as to the best way to do so and I expect that as we continue that process things will become more PSGI friendly until it is just a matter of changing one sub somewhere.
I should note you have convinced Josh Drake on the merits of DBIx::Class for other projects though.
Finally I think it is worth noting that I think that in the 1.4 tree we've come out (I hope) of the contageous effect of the bad SL code, and so the coding styles which evolved so much during LSMB 1.3 are being formalized and moved to Moose in 1.4.
Actually some of your recommendations are pending getting rid of old code (we simply can't move everything to PSGI when we have the mixture of old and new code we have, so it's CGI only for now still). However we are giving hard thought as to the best way to do so and I expect that as we continue that process things will become more PSGI friendly until it is just a matter of changing one sub somewhere.
I should note you have convinced Josh Drake on the merits of DBIx::Class for other projects though.
Finally I think it is worth noting that I think that in the 1.4 tree we've come out (I hope) of the contageous effect of the bad SL code, and so the coding styles which evolved so much during LSMB 1.3 are being formalized and moved to Moose in 1.4.
I guess the problem with Perl 6 is that it's more of a "fork" than an "increment". Thus, Perl 5.16 (and beyond!).
Thanks for the interesting insight.
There has also been quite a bit of change in the perl Web Framework world as well. IMHO Catalyst is no longer king. Mojolicious has really taken the spotlight. It's fast, the community behind it is really creative and it supports websockets. :D Mojo really does make perl web development fun again.
There is also a Sinatra inspired framework, Dancer.
There has also been quite a bit of change in the perl Web Framework world as well. IMHO Catalyst is no longer king. Mojolicious has really taken the spotlight. It's fast, the community behind it is really creative and it supports websockets. :D Mojo really does make perl web development fun again.
There is also a Sinatra inspired framework, Dancer.
I started picking up Perl (as my first programming language) in 2003 while working in a genetics lab. I used it for years on a number of bioinformatics projects due to its strengths in tackling disparate sources of often irregular information. Recently I've been using it for the Kaggle Facebook competition simply because I can iterate my designs faster than in any other language. I'm looking forward to learning a few of these more newfangled modern appurtenances of Perl.
I really wanted to see what Modern Perl looks like.
Have a look at http://onyxneon.com/books/modern_perl/ This is from the author of the book, there's a nice pdf preview there to show the book off and a way to buy it.
Preview is a slight understatement, it's the full book as both pdf and epub.
It is a bit of a marketing term, though. Not many of the "modern" features are really new to Perl, but basically rather common modules. In the case of Moose, they do change the language use significantly, but mostly it's about showing that Perl can be used beyond small, one-file Unix scripts. And it's been able to do that for quite a while, the Perl 4 days are long gone.
Still, getting some new-found traction is important, and popularizing some great CPAN modules definitely won't hurt.
It is a bit of a marketing term, though. Not many of the "modern" features are really new to Perl, but basically rather common modules. In the case of Moose, they do change the language use significantly, but mostly it's about showing that Perl can be used beyond small, one-file Unix scripts. And it's been able to do that for quite a while, the Perl 4 days are long gone.
Still, getting some new-found traction is important, and popularizing some great CPAN modules definitely won't hurt.
It's actually more than a preview. The entire book is available free of charge in a variety of electronic formats (PDF, ebook, etc.).
There's also the Modern Perl Books blog which delights in rooting around the guts of modern perl (and modern perl debates) -- http://www.modernperlbooks.com/ :)
In perl culture, "Modern Perl" refers to bad programming by a core group of egocentric, sanctimonious developers who are to Perl what Lennart Poettering is to Linux.
There are now dozens of CPAN modules with names like "common::sense" and "Modern::Perl" that provide no useful code, but introduce packaging dependencies and administrative overhead in the name of not having to type "use strict;" out by hand.
Modern Perl is using Moose::Any instead of just using a language that does what you want. Modern Perl involves an average of 130 CPAN dependencies for any give application.
Modern Perl is when perl stopped being perl and started being awful.
There are now dozens of CPAN modules with names like "common::sense" and "Modern::Perl" that provide no useful code, but introduce packaging dependencies and administrative overhead in the name of not having to type "use strict;" out by hand.
Modern Perl is using Moose::Any instead of just using a language that does what you want. Modern Perl involves an average of 130 CPAN dependencies for any give application.
Modern Perl is when perl stopped being perl and started being awful.
Nobody forces you to use Moose or anything else. I happen to think Moose is wonderful because it gives you a very useful declarative constraint system in a dynamically typed language, and it does so without messing up your ability to use other things like Template::Toolkit.
But a lot of these things are not for all projects. I use Moose but not DBIx::Class in most of my projects.
I think Moose is wonderfully designed, but that's just me. you may differ in your opinion and build your own modules your way. There's more than one way to do it!
But a lot of these things are not for all projects. I use Moose but not DBIx::Class in most of my projects.
I think Moose is wonderfully designed, but that's just me. you may differ in your opinion and build your own modules your way. There's more than one way to do it!
I actually despise Moose as much as I despise blindly over-doing OO. To me Modern Perl meant tackling problems in a much more Lisp-inspired way (via lexical scoping, anonymous functions, closures, lists, etc) ... but in Perl. Kind of like "Higher Order Perl."
I had the impression it was more a cultural shift, a renewed interest in Perl and people wielding it much differently. There's a different CPAN web interface[1], a lighter cli client[2], and everyone is on GitHub and writing hundreds of tests. I guess Moose is part of that shift but I'm torn a lot of the time - I support modern Perl but I hesitate to support blindly copying the warts from other languages just to appear modern.
This[3] is a result of searching for common::sense ... yikes.
[1]: http://metacpan.org [2]: https://metacpan.org/module/App::cpanminus [3]: https://metacpan.org/module/Real::Handy
I had the impression it was more a cultural shift, a renewed interest in Perl and people wielding it much differently. There's a different CPAN web interface[1], a lighter cli client[2], and everyone is on GitHub and writing hundreds of tests. I guess Moose is part of that shift but I'm torn a lot of the time - I support modern Perl but I hesitate to support blindly copying the warts from other languages just to appear modern.
This[3] is a result of searching for common::sense ... yikes.
[1]: http://metacpan.org [2]: https://metacpan.org/module/App::cpanminus [3]: https://metacpan.org/module/Real::Handy
Personally, I think Moose' value to the community is much larger than that it just provides good OO.
It pushed a much more declarative approach than usual, that swaps over to other projects (Moo, Mo, even Class::Accessor supports has declarations now). It has a community that is focused on best practices with regards to OO. It put introspection more in the spotlight (like the idea of getting Getopt definitions by introspecting classes).
It is also flexible, which allows for lots of extensions to its functionality. That means a lot of concepts are tried out on CPAN already. Even if someone doesn't use Moose, there is lots of OO knowledge to be found in the ecosystem. Same goes for runtime type constraints/coercions.
Then there's the p5-mop project, that would provide a common core, so many of the things above could find themselves in a much more light-weight and broadly usable variety, with side-effects like less heavy anonymous packages.
Personally, while I'm very excited about where Perl 5 has come so far, I'm even more excited by the things we haven't thought of yet.
It pushed a much more declarative approach than usual, that swaps over to other projects (Moo, Mo, even Class::Accessor supports has declarations now). It has a community that is focused on best practices with regards to OO. It put introspection more in the spotlight (like the idea of getting Getopt definitions by introspecting classes).
It is also flexible, which allows for lots of extensions to its functionality. That means a lot of concepts are tried out on CPAN already. Even if someone doesn't use Moose, there is lots of OO knowledge to be found in the ecosystem. Same goes for runtime type constraints/coercions.
Then there's the p5-mop project, that would provide a common core, so many of the things above could find themselves in a much more light-weight and broadly usable variety, with side-effects like less heavy anonymous packages.
Personally, while I'm very excited about where Perl 5 has come so far, I'm even more excited by the things we haven't thought of yet.
We moved to Moose only in the last year, and the reason was that at the time we started LedgerSMB 1.3, Moose was still relatively immature at least in the versions shipping with supported Linux distros. We felt it was an immature technology with too many dependencies to build our software on at that time (2007). After the 4 year development cycle and a release that happened only slightly after Duke Nukem Forever, we had cleaned up a significant part of the codebase, and Moose had changed.
Moose is a bit heavyweight. It may not be what you want in some applications. However, it strikes me as an inspiring example of design done right, and for that reason it's worth learning.
I think this exemplary aspect is why Moose has had the impact it has, not only being somewhat widely used, but also defining approaches that many other object approaches have borrowed. The fact that things are declarative is very helpful.
Moose is a bit heavyweight. It may not be what you want in some applications. However, it strikes me as an inspiring example of design done right, and for that reason it's worth learning.
I think this exemplary aspect is why Moose has had the impact it has, not only being somewhat widely used, but also defining approaches that many other object approaches have borrowed. The fact that things are declarative is very helpful.
Way to go to start your career here.
Would your opinion be still valid without attacks on 'random' (as in totally unrelated) people?
Your post might've been a well founded rant against the topic at hand, unfortunately you've lost any credibility by default when you added specific and personal insults. Poor taste..
Your post might've been a well founded rant against the topic at hand, unfortunately you've lost any credibility by default when you added specific and personal insults. Poor taste..
"Modern Perl" does not necessarily equals "use Modern::Perl;".
Writing a book on Modern Perl is nuts.
As the author of this post points out, there have been about twenty releases since Perl 5.6, when the book was published. Features like the "switch" and "state" keywords have been introduced. If you look away too quickly, another database interface crops up, or people are doing objects differently. Perl changes so often that writing about it is like trapping a unicorn.
It's impressive that users of a 25-year-old language are not afraid to improve upon it (with the caveat that it stays backwards compatible). But since I started using $OTHER_LANGUAGE I don't have to worry about keeping up to date because language features change twice a decade.
As the author of this post points out, there have been about twenty releases since Perl 5.6, when the book was published. Features like the "switch" and "state" keywords have been introduced. If you look away too quickly, another database interface crops up, or people are doing objects differently. Perl changes so often that writing about it is like trapping a unicorn.
It's impressive that users of a 25-year-old language are not afraid to improve upon it (with the caveat that it stays backwards compatible). But since I started using $OTHER_LANGUAGE I don't have to worry about keeping up to date because language features change twice a decade.
That's a terrible straw man. Everything changes. Javascript is morphing into this weird "Coffee" thing before our eyes. Python pushed a completely new language and is currently supporting two of them. Even python 2.6 looks absolutely nothing like 2.0. People fled whole-hog from perl and python to ruby (another hardly static language) a few years ago, and most of those same people are now retraining their brains on that JavaCoffee thing I mentioned.
C++? Yeah, brand new version out with whole new metaphors (An... rvalue reference?! And what is that -> operator doing there?).
If you want compatibility, you have it. 15 year old perl scripts run fine on 5.14. If you want the community to not invent new stuff... dig yourself a hole I guess.
C++? Yeah, brand new version out with whole new metaphors (An... rvalue reference?! And what is that -> operator doing there?).
If you want compatibility, you have it. 15 year old perl scripts run fine on 5.14. If you want the community to not invent new stuff... dig yourself a hole I guess.
Writing a book on Modern Perl is nuts.
I've written two.
Perl changes so often that writing about it is like trapping a unicorn.
Not really. I document things with staying power. For example, I documented only the parts of smart match that are easy to explain. Everything else is up for debate, and thus not really worth recommending. (Besides, I'm not trying to replace the documentation.)
I've written two.
Perl changes so often that writing about it is like trapping a unicorn.
Not really. I document things with staying power. For example, I documented only the parts of smart match that are easy to explain. Everything else is up for debate, and thus not really worth recommending. (Besides, I'm not trying to replace the documentation.)
Yes, I'm so happy that Java, er, $OTHER_LANGUAGE, changes so (incredibly) slowly :-)
Perhaps there is a happy medium somewhere between these extremes, though.
(there seems to be just a bit of sarcasm in the above post, though -- writing about the moving Perl target is hard, but having a non-moving base one is employed to build on has its own "joys", as well)
Perhaps there is a happy medium somewhere between these extremes, though.
(there seems to be just a bit of sarcasm in the above post, though -- writing about the moving Perl target is hard, but having a non-moving base one is employed to build on has its own "joys", as well)
I've found a lot of embedded wisdom in the "old school" stack. If you edit in vi, add some sed / awk / grep, and learn some bash, you'll find these tools start to come together and leverage one another up substantially. Perl might be more post-Bell Labs but it still was written and used by smart people to Get Stuff Done. It stands to reason that there are large returns on learning it.
But it isn't as approachable as Python. When I needed a glue language, I first looked at "Learning Perl" -- after a few days I concluded that, if this was The Path, then I would never get There. Python was much more approachable, and my code already gathers so many hacks that I'm glad my language forces me to make these at least somewhat intelligible.
I would learn Perl faster now. But for what? I've learned some PHP to meet client demand, and for web development the next language would be RoR. I bet Perl is better than bash for various sysadmin and utility tasks, but bash feels good enough for the simple stuff I do. If I needed to do something really beyond bash I'd turn to Python, and I'm not sure why Perl would be better. I suspect there's a lot of general knowledge embedded in Perl but I'm not sure how that gets extracted and made current among today's toolset for the tasks I have.
So to my mind, Perl is something of a sysadmin tool, better than bash and very useful for a workload focussed on system and file processing, on *nix, without much service to HTTP. I'd love to hear how it pays returns for people more focussed on back-end support of web development.