Perl career progression

[Nathan Bailey]

Daniel Pittman <daniel at rimspace.net> wrote:
>"Template Engines" or "Content Management Systems" are probably what you
>mean here, I think.

Probably more the former, although what I'd really like is a portal
toolkit of the standard of Zope or Zend, but perl doesn't have one as
yet, does it Scott? ;-)

>> Damian once said "Never use XML if you own both ends of the pipe." 
>Damien Moore?  Anyway, that's not a great argument, I think.

Conway -- 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.

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 :-)

>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.

>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?  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::*).

>Yes, very much so. The document isn't very general. It wouldn't cut it
>here at QHRS, for example, because we don't use most of your
>technologies or not in the same way you do.

*nod* When there is more than one way to do it(tm), standards are not
quite so straightforward :-)  Nonetheless, any suggestions towards
generalisation that make it more broadly useful are very welcome.

ta,
N