With all of the recent hoopla surrounding other languages, it sometimes seems as if Perl is being left behind. When will Perl 6 be mainstream, where are the frameworks to provide ease-of-use like other languages, and will Perl stay ahead of the curve into Web 2.0 and 3.0 applications? More importantly, to me, is the question of when Perl will make it as an enterprise-class language? Sure, Perl is widely used in large systems, but usually for testing, systems administration, CGI, and “glue.” What about large, critical applications, however? How many architects and managers have considered Perl lately when it came time to look at an alternative to Java or C++? Moreover, if they aren’t considering Perl, what are the reasons - what are the areas that need to be addressed in order to turn Perl into a respectable corporate contender?
This isn’t the first time the question has come up, but why are people frothing over Python or Ruby when Perl still has so much to offer? What can Perl do? How about a catchy name? Joking aside, there was a fair amount of marketing that made Java so popular (at least with management) and more people probably know the phrase ‘Ruby on Rails’ than could tell you anything about it. Perhaps, like Java, Perl could have its own ‘enterprise’ version. This isn’t a new thought, others have brought it up in the past, including P5EE and Enterprise Perl. Personally, I think that it should be called Perl In the Enterprise (PIE), but that is mostly because I think that, like sex, food is a good selling point.
A catchy name might turn the head of a non-technical manager, but what goodies would an Enterprise level Perl need to have under the hood to keep the attention of a serious Enterprise developer? This is perhaps the point where opinions will diverge, but I think that I am fairly safe in listing better error handling, logging, and threading as top priorities for a bigger, better Perl. Adding assertions, native compilation, and a snazzy IDE would sweeten the pot even further. Finally, some nice frameworks for web, CORBA, and SOA would be nice.
At this point, several members of the Perl community (if not CPAN contributors) are probably saying to themselves, “Wait, most, if not all, of these things are available in one form or another already.” For the most part, they would be correct. However, adoption of some of these technologies hasn’t been what it should, particularly in that Perl hasn’t taken over the Enterprise on its way to world domination. Over the next few months, I’d like to look at what choices the Enterprise developer has for addressing these needs.
Moreover, I would like to stress that the term Enterprise isn’t just a way to calm hyperactive management in large organizations, but that it can reflect an attention to detail and the notion of “failsafe” that allows other, more interesting languages to displace that spinster Ada as what people would rather have running the navigation systems of the submarine they are on when exploring underwater Arctic caves. That said, I think it goes without saying that features such as error handling and excellent logging facilities are equally attractive to companies spanning the range from startup to blue chip.
Well, that is really it for this first installment. Not a lot of meat here, but just some ideas to get everyone thinking. Stay tuned as I start looking at projects and modules out there in-depth. Finally, if your organization uses Perl for Enterprise class applications, and don’t mind discussing how Perl has or hasn’t met needs and expectations, drop me a line.