Perl career progression

Daniel Pittman daniel at
Mon Sep 8 22:49:06 CDT 2003

On Tue, 09 Sep 2003, Nathan Bailey wrote:
> Daniel Pittman <daniel at> wrote:


> he was speaking in the context of perl owning both ends of the pipe,
> i.e. there is little value in going from perl, to XML, to the socket,
> to XML and back to perl. XML conversion is expensive and adds little
> value to this transaction.

XML is used far too often, by people who think it solves a number of
problems, and often is wasteful.

The classic example, of course, was someone enthusing to me about XML
and how it made their floating point number matrix completely

...which, of course, it didn't, because they read back an ASCII version
of their numbers into a different machine representation, with different
precision and...

> You add an interesting dimension (reusability in different languages)
> which is a very pertinent point for larger architectures (i.e. where
> things might be SOAP'd out, for example) but I think not as relevant
> where everything is happening in perl in the back end (despite my
> boss' reading of Gartner reports, I do not believe perl is going to
> become a legacy language any time soon :-)

I don't mean to suggest that Perl is in any way endangered by
anything[1], or that it will be replaced as a language.

What I am trying to point out is that if the application "all in Perl"
today is big enough to need IPC, it's big enough that designing for the
future is a good plan.

>>Most things do better with a simple loosely structured, loosely typed
>>ASCII based, line oriented protocol like SMTP, in my experience.
> *IF* you are looking for interoperability across languages.  But that
> isn't the most efficient mechanism if both ends are (and are likely to
> stay) perl.

This falls under the heading of designed for the future. It's not hard
to extend an SMTP-style protocol with support for UTF-8 data, in a
backward-compatible fashion.

>>something that I have to replace with a Java based[2] fizz-bang
>>solution and that has to unpack your IPC, five years from now. :)
> If perl was vended by a vendor then life-time of the language would be
> a concern, but why would Java kill perl?  

Sorry, that wasn't my meaning.

For 'Java', substitute 'Perl6', and then think about your on-the-wire

Did using the easy serialization format when it was all Perl5 mean that
you had to rebuild *all* your application to Perl6 when it was released,
or could you replace one part independently.

Anyway, my meaning was that using a defined protocol rather than a
language specific serialization format or whatever may be a bit less
efficient[2], but it makes your code a lot more portable and

> I think they fill different niches (Java is good for enterprise code
> -- I wouldn't write an ERP in perl, but perl is great for integration,
> especially with Internet services ala Net::*).

There was this time when I had to do the work of replacing a Perl daemon
with a C daemon, where it had been Perl to Perl IPC before.

Rewriting the C daemon in Perl was not an option, and we ended up
writing a parser for the very limited set of wire formats that the Perl
stuff sent.

At the time, this marginally beat out writing a real protocol for the C
side, then interfacing them with another Perl daemon that just
translated one format to another.

So, I guess that my advice boils down to:

    If your project is big enough to need IPC, it's big
    enough to need language portability for each component.


[1]  Wel

More information about the Melbourne-pm mailing list