It seems that a new bout of Perl5 vs Perl6 is running its course again. I won't add links as the number of blogs, posts, tweets and general opinions has now exceeded the number where I can remember who said what and which bits I agreed with.
Sometimes I am very slow to recognise the obvious - and this is a case in point. The Perl5 vs Perl6 discussion nearly always runs on from or is part of a 'why don't people use Perl' lament. Lots of reasons are put forward, invariably without any real evidence base. That's because, of course, we don't really have the means to gather the evidence. So at best we have to rely on the anecdotal observations of our fellow users of Perl to weight our own opinions. Or maybe we are arrogant enough to be certain that we alone have determined the one true explanation. We all do this sometimes.
So, in this spirit, I'll add my own dash of grist to the mill as the current lament grinds down to the usual unsatisfactory conclusions.
The fact that Perl is not considered for many projects has nothing to do with the features offered by the language or some perceived confusion over Perl5 vs Perl6. Perl has no obvious coherent set of tools for building, testing, deploying and managing your project or application in a reasonable way. Perl being Perl I have no doubt that someone will point me to a selection of modules and approaches that allow this but that, I feel, misses the point. The selection would be the personal choice of a seasoned developer. Knowing how to achieve something is not the same as having a de-facto toolkit.
No-one develops deployable applications in .NET or Java using a text editor and some hand crafted helper scripts. I'm not sure what the Python folks use and perhaps I should find out. But my general point is that when people discuss the selection of a language for a project, they are really selecting a 'platform' that includes the whole development and maintenance environment.
The thing that I have been slow to recognise is that there has been a project running for quite some time that attempts to start building a modern working environment for Perl. That is Padre. Padre is not just an editor or a graphical debugger, though those two components are essentials. It offers the chance to build a coherent toolkit for managing a project that uses Perl as a language. The future of Perl as a common viable alternative for general application development rests with Padre or son of Padre . Bringing the benefits of modern Perl5 and next generation Perl6 to a wider audience.
Great read!
ReplyDeleteComparing a java and perl deployment is humbling...
"Perl has no obvious coherent set of tools for building, testing, deploying and managing your project or application in a reasonable way."
ReplyDeleteYes it does ;) .. it's called "unix".
The only unreasonable thing about this IDE is that the choice of tools is staggering, and it's hard to make (smart and headstrong) people comply with your own selection.
"No-one develops deployable applications ... " might be true about .NET ... but it's the fault of the braindead Windows console that there are so few.
Perl is the victim of it's own early success: now it's the language "for the old farts" that manage the pesky legacy apps, lead your QA department or keep your network afloat, on whose lawn is perilous to walk and whose jokes don't really make sense without checking wikipedia first.
Emil, sure, /usr/bin/perl is the scripting tool for holding your "unix" platforms together. Just because a language has found a particular niche in one specific area doesn't define the boundaries for use of the language. Part of my whole point is that there isn't a widely accepted deployment and maintenance model for use outside this 'niche'. I'm referring to Perl as a language available on multiple platforms, not the well developed and widely deployed usage of Perl as a unix sys admin and scripting tool. If that's what you see as the sum total of possibilities for Perl the language then yes, I guess that the shortcomings of the Windows console might loom large in your consideration of how applications are deployed.
ReplyDeleteYour comment reflects what does seem to be a widely held view - because Perl is a widely used tool in unix administration roles, that's all it is good for.
"Perl has no obvious coherent set of tools for building, testing, deploying and managing your project or application in a reasonable way."
ReplyDeleteWith all respect to the above disagreement, I have to say I mostly agree with this statement. I've consulted on quite a few Perl projects, and inevitably each teams has solve the problem of deployment and codevelopment in varied ways. I'm not going to say Java's way is better, but a CTO can buy a Java deployment book and send team members to training and you will get a standard outcome. For the management level people this is a big deal.
Having a standard, community accepted approach for the full ecosystem of activities required to run a successful development to production workflow would really help us (and a few books on that as well). Since this is Perl you are free to do something else of course, but from a CTO or CEO point of view having such a unique codebase is not a good thing.
Miyagawa's recently released Carton seems like it might be a solution for the deployment problem. (Carton:deploying Perl application::cpanm:installing CPAN modules)
ReplyDelete'/usr/bin/perl is the scripting tool for holding your "unix" platforms together' ... I meant "unix" is the IDE for Perl :)
ReplyDeletePerl deployment is a problem because you can deploy Perl code on a myriad distinct platforms, and there already are a myriad good enough deployment solutions. The problem is 40 years of Unix, not Perl. Let's talk C deployment, or Lisp deployment :), not to mention the PHP method of dumping everything you need in your htdocs folder.
Java easy to deploy ? Yes, if you have a team leader willing to break your fingers ( metaphorically ;) ) if you don't stick to the procedure ... same as Perl.
The only foolproof method I found for deploying Java apps was to compile them into an .exe with gcj (yes, required BASH script :) ) and distribute that file.
The Padre team is doing an excellent work. I'm using it at home daily and did not crash on me at all since last year :), and the "session" is a good enough replacement for "project". It's not Eclipse or Visual Studio, but I am not sure I want it to become Eclipse/Netbeans for Perl, same I don't want Perl to become Java, since Java has it's own problems with having a myriad variations of servers, plugins, middleware and deployment solutions, problems one can ignore by sticking with a single provider and the tools or libs it publishes.
Fantastic read ! The overall structure of Perl derives broadly from C. Perl is procedural in nature, with variables, expressions, assignment statements, brace-delimited blocks, control structures, and subroutines.
ReplyDeleteforum widget