At 09:45 PM 10/23/2001, Perrin Harkins wrote: >Matt Sergeant wrote: > >>OK, so what are we missing? > > >Based on the comments I've seen here over the years, and some on Slashdot, >the thing that seems to worry people the most is the lack of an obvious >message queue API in Perl. I've seen plenty of implementations, but there >isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order.
I think it's more than that. It's more of a general all around 'feeling' as I've said before. It's about people and it's about the standards. The thing about "Enterprise" applications is that there are many components to what "enterprise" means.... J2EE compromises a lot of standards and frameworks all in one and to read the books about them all would take several weeks at least. But at least I know that when I read a book on EJB, I know this is the plan and it's stable etc... whereas someone's particular idea of a transaction engine in Perl is just someone's idea of a transaction engine in Perl. It may be a good idea, but it's really quite scary to build a large system around something that may not have a lot of success stories around it. This is why Perrin's article is so good. Because it starts getting more high profile success stories out there. There really are otherwise not that many about Perl when compared to Java. And even then, let's also consider the programming base. When I advertise for Perl programmers, they generally just know how to do Web apps and it's pulling teeth to even get OO and Mod_perl capability. It has to be taught after such programmers are brought in. But with Java, it's quite rare to find a Java programmer that hasn't programmed at least their own minimal RMI server before. I have little doubt that this is because of the sheer amount of documentation for making an RMI server plus the fact that it is a true "standard" so people feel comfortable that it is supported in a large community. Remember that my email said, I "feel" better about coding middleware in Java than in Perl. Just as I "feel" better about coding front-end in Perl. This is a "feeling" and isn't necessarily something that can be quantified -- it is also about perception which is something that cannot be ignored. And part of it is about "soft" issues like knowing that I can find Java programmers at a dime a dozen who have done middleware coding before in Java. I think more success stories would help. I also think official endorsement by key members of the Perl community (eg Larry) would help certain projects. ie I believe SOAP::Lite is now the defacto standard SOAP Library for Perl that people would recommend anyone to use no? So why is it still SOAP::Lite and not moved and advocated into the SOAP namespace where it belongs and make it the defacto standard SOAP engine for Perl if it's proven itself? Of course, choice is part of what makes Perl fun. But fun isn't for everyone. eg when it comes to such niche libraries as middleware tools, it's not so fun to have choices if none of the choices are very easy to evaluate. It's much nicer for a programmer to be able to reliably choose a tool they feel is backed by a strong community beyond just the immediate few people who may have done X middleware for one project or group of projects for one company. I really would like to see a generally endorsed P2EE project which includes SOAP::Lite as an interoperable webservices engine, a messaging engine, and transaction engine. Authentication engine and Session engine would be quite useful to include as well. Oh and Moseley's (sp?) servlets in Perl project would be a cool one to include as well. That would make it compete pretty much head to head with J2EE. And then success stories on top of P2EE. Later, Gunther