Of Oysters and Perls, or Perl in the Enterprise

by Robert Pratte

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.


13 Comments

Piers Harding
2006-05-17 01:14:55
Hi Robert,


As I have been involved in the use of Perl (first), Python, and Ruby in the Enterprise world of SAP over the last 6 years, I have seen a distinct change in the attitude of late. It seems to me that scripting languages in general are becomming more important => for example.

Within the forums of SDN, SAP themseleves have recognised that this is something that is important to their customers by creating an area to accommodate.


Cheers.

Aristotle Pagaltzis
2006-05-17 01:17:22

Sorry, but “Enterprise software” is a social, not technical, phenomenon.

Dick Davies
2006-05-17 02:15:55
Though I loved her dearly,
Perl's stuck with too much legacy cruft now, I'm afraid.


That coupled with a hideous OOP syntax is why I personally looked elsewhere.
Even if adding a 'class' keyword was enough, I'd still be stuck with years of legacy perl scripts that are effectively written in a different langugage.


And when I realised perl6 was going to be a different language, it was a small step to learn a new language *without* all that baggage. Perl5 was Good Enough for a lot of jobs. Oddly, it's Perl6 being on the horizon that makes it more appealing to pack the whole thing in.

Aristotle Pagaltzis
2006-05-17 12:25:45
Dick: Python and Ruby are less crufty than Perl 5, but they are still only marginally stronger languages. Perl 6 is a whole different league. It's not even in the same ballpark. It's going to kick so much ass that it's going to take people years until they realise the full extent of what it enables.


(I'm fully serious here. I've had an article percolating in the back of my head for a while now, giving just one demonstration of the kind of mindblowing that P6 is going to be. I need to get around to it.)


2006-05-17 16:12:54
Perl 6 is a whole different league. It's not even in the same ballpark. It's going to kick so much ass that it's going to take people years until they realise the full extent of what it enables.


A language that takes years to understand the implications of is NOT a good language for control systems. A good control systems language is one that can be verified against the specification with a minimum of effort, and proven correct. The more things that are possible in the language, the more things that can go wrong. Control systems hate the abstract: simple, concrete truths are what keep people alive. The more complexity you allow, the more risk you have to manage. Simple and correct is best.


I'm fully serious here. I've had an article percolating in the back of my head for a while now, giving just one demonstration of the kind of mindblowing that P6 is going to be.


Control systems don't need to be "mindblowing". They need to be boring: completely predictable, boringly accurate, and pedantically correct. They need to be designed based on principles that are tried and true, in practice as well as in theory. Novel, clever, and mindblowingly cool ideas belong in prototypes: but not in mission critical systems. Only once the all downsides of the hot new idea have been discovered, and the concept has been fully explored and proven after years of testing and analysis, is any component safe enough for inclusion a life critical system. "Mindblowing coolness" takes a second seat to "provably correct and known to be safe" for mission critical applications.


Perl 6 will be a big, complicated language that's hard to understand, by your own admission. Perl 6 may be good for many things, but control system are not one of them. For many people, control systems designers especially, that's not a good thing.

Aristotle Pagaltzis
2006-05-17 18:16:06

None of what you’re claiming follows from anything I wrote. By your logic, Haskell is a big and hard to understand language that isn’t “provably correct” (I’d be interested in hearing how that works), because it took people years to explore the language and they’re still coming up with new ways to exploit it smartly. That is what you’re saying, right?

Perrin Harkins
2006-05-17 18:18:50
Native compilation? Perl is already faster than Python and (much faster than) Ruby, and competes well with Java. What problem are you trying to solve?
Dennis Ingram
2006-05-17 21:17:27
It does happen. I was the team leader for a project that developed over a period of 7 years or so a large system that provided financial settlement functions, customer management, a help desk and a data warehouse. It most certainly fits into the "enterprise category". We did most of it in Perl.


We did not however start by selecting Perl - rather we started with C++ and a forms and report builder that came with the database. What happened was that we used Perl for one small part of the system, and to cut a long story short, found development was way, way faster. We fit into the category of a small team (8) with more to do than we could handle, so what followed was a mass conversion to scripting languages and Perl in particular.


There is no way we could have achieved what we did using C++, or I believe Java. These days I do not cut much code, but as the company architect am facilitating expansion of Perl into other systems, including those that process transactions.


So speaking from experience, my opinions on the subject are:


- Perl is a really good choice for "enterprise" development. Brave one, maybe, for those who don't understand it - you don't get fired for picking Java. Desperate teams that can't keep up (like ours was) just use it. And don't forget.


- Agree about the name/marketing. Something like Ruby on Rails would be a great help. Don't ask me, I don't do marketing :-)


- Don't give a toss about IDEs. Perl is so productive on its own a text editor does just fine. If it were a compiled language, maybe. Thankfully it isn't.


- Don't see that any additional frameworks are needed - that's what CPAN is for. In fact, that is the single massive advantage that Perl has that I always use for a selling point - CPAN. No other language has that huge library of free software available. The need to write your own softwware diminishes every day.


- Can never understand why people complain about Perl's object support. OO was never about the syntax, either you get or you don't. Perl has all that is needed to do what you need to do. But then I don't believe everything needs to be an object so what do I know.


- Glad Perl 6 is coming, because it shows the language has a future. Little bit worried it will be too complicated and turn people off, I guess time will tell. Will be interesting to see the end result of the Parrot project. Maybe in the future everyone will code in Ruby and use CPAN modules...


Anyhow, just thought I would throw out a concrete example.


Cheers



DynamicLangsRock
2006-05-18 07:33:45
A Language should let you express yourself without getting in the way. Perl certainly excels at that. Sure, you can shoot yourself in the foot with it, but then you can get killed riding a bicycle - it's not the bicycle's fault !!
I'm surprised people find Perl's OO syntax troublesome but have no issues typing Cast expressions in Java a million times ! Classic example of the language getting in the way
of my thought process.
Think about it - whereas Java crowd considers Reflection to be an 'Advanced' thing, Perl folks been doing that stuff (and more) via symbol tables for year and make no noise about it. It that turns you off, maybe it's because you belong to the programming masses - not the crowd of hacking elites ;)
mariuz
2006-05-20 05:27:21
I think perl should go the ruby/php way , keep the things very simple
And forget about CORBA, WS-* , SOAP (thouse are dead horses - REST in peace)


What perl need is more docs , more articles , killer apps (like phpbb,RoR) in short new cool projects (watch what mono people are doing with many projects they have:beagle,sharpdevel,banshee ...)


2006-05-22 13:32:19
Perl 6 is a whole different league. It's not even in the same ballpark. It's going to kick so much ass that it's going to take people years until they realise the full extent of what it enables.


...just one demonstration of the kind of mindblowing that P6 is going to be...


It's that 'going to be' that keeps bothering me; Perl 6 has been 'going to be' mindblowingly ass-kicking for something like five or eight years now, and I'm just tired of waiting around. I'll be using Perl 5 forever, but I'll be greatly surprised if Perl 6, assuming it ever does happen, is even usable, much less useful.

Peter
2006-05-24 21:26:41
I've been working in a F500 now for about 3 years. Our group was consumed by the larger IT group. The manager asked what tools I used and one of them was Perl. She'd never heard of it. In the group of 15 other IT developers no one said anything. Never mind that our headquarters pays a company which uses Perl to filter out spam from our email. I was a bit dumbfounded. Everyone uses these gui tools that take them days/weeks that would take minutes/hours in Perl. Oh well. I hate to say it but I don't see a future in Enterprise until someone starts to SELL it. They have to offer support ... never mind that the support is worthless (as we've gotten from other vendors). Oh .. I see people criticizing Perl 5 (anyone used Perl 4). Personally I have no complaints. Given the wealth of CPAN, what I consider the ease of doing things in Perl ... I think it's darn good. I recently had to do a web service using SOAP. My job was to query the service, parse results to merge with templates (TT2) and send out email. I was running rings around our java developer who took forever to do simple stuff. In the end the production server would not even work with the web serivce so they turned it into a REST app. I wonder if these people critizing Perl ever really learned it.
Jason
2007-09-12 09:06:54
I'm trying a new module out from CPAN called Log4perlmeba. What I'm trying to do is automate logging to a log file 11 fields, some of which will have to be passed as parameters. the total of all these fields in character length is 4275 characters at max, some of the fields reaching as high as 4000 bytes. Is this module a good choice for this? Is there a limit of how many characters in length your parameters can be when sending them to a module? I know cgi files max at 256, is it the same?