[Israel.pm] What hurts you most in Perl?
sweisman at pobox.com
Thu Nov 25 09:33:33 PST 2010
I was trying to think of of my own experience and couldn't think of any
until I saw this. I indeed had a project writing a Salesforce app and using
their SOAP API, using Perl. This was in early 2004, so there wasn't the
massive internal infrastructure Salesforce has today to develop hosted apps.
So I used Perl. Salesforce even had a Perl implementation they released. No
support, but it was useful to have. However, it, and the SOAP::Lite modules
were both pretty deficient. The SF package was full of bugs (which I fixed)
and missing API support (I added some extra methods, but not more than I
needed for my project). Also, it is VERY confusing and poorly documented (of
course). I'm pretty sure there's a very weird module that's not even needed,
but I'm too afraid to remove it because I have no idea what it does.
Personally, I think SOAP sucks and wish it would be sucked down a vortex and
break apart into pure entropy.
Perl SF support really waned after that. While the API continued to accrete
new features. The SOAP::Lite package has been worked on since then, and lots
of bugs have been fixed. But it still had problems parsing input and
generating the desired output.
My little experience did get me a job once. Someone on the
jobs.perl.orglist was looking for someone with Perl and Salesforce
experience who make
the code worked. The SF package was never updated and didn't even function
with the supported API versions. The versions it worked with were EOL'd. I
told them I had a working and fixed module and they hired me to updated the
code to the current API.
I had another job where I had to connect to a CORBA server to retrieve
financial data. The original code was a Windows COM object. It was horrific.
I finally managed to get some internal Java code from them (for the COM
object; don't ask) that sort of documented the CORBA messages. I wrote the
code in Perl with various Win32 modules. It actually worked pretty well, but
the COM module was very limited, and constraining. I ended up reimplementing
the code in native Perl running as a CORBA client. I found this really
obscure but surprisingly good Perl CORBA package, not part of CPAN. It is
kind of convoluted, but unfortunately, CORBA is insanely baroque.
So, the meager Perl CORBA support was frustrating, and the general obscurity
of docs on the CORBA wire protocol. Plus the knowledge that there was no
reason for the devs to do it this way. They were these pretty sharp Russian
guys who had some very good data sources for a very good price.
On Thu, Nov 25, 2010 at 6:30 PM, David Baird <davidlbaird at gmail.com> wrote:
> XML::SOAP is my biggest pet peeve, especially how it restructures the XML
> code when sending a response to a web service, often redefining data with
> different types. If the XML you get says a bit of data is a "short", why
> redefine it as a "long" in the response?
> On Tue, Nov 23, 2010 at 2:22 PM, Gabor Szabo <szabgab at gmail.com> wrote:
>> The other day I was at a client that uses Perl in part of their system and
>> talked a bit about the language and how we in the Perl Ecosystem Group
>> try to promote it at various events.
>> Their "Perl person" then told me he would not use Perl now for a large
>> application because:
>> 1) Threads do not work well - they are better in Python and in Java.
>> 2) Using signals and signal handlers regularly crashes perl.
>> So I wonder what hurts *you* the most in Perl?
>> Gabor Szabo http://szabgab.com/
>> Perl Ecosystem Group http://perl-ecosystem.org/
>> Perl mailing list
>> Perl at perl.org.il
> Perl mailing list
> Perl at perl.org.il
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Perl