[Columbus-pm] has anyone perused 'Higher Order Perl', on monks and gripes

Jonathan Hogue jon at hogue.org
Fri Dec 2 14:54:34 PST 2005


On 12/2/05, J Alexander <jalex at pobox.com> wrote:
> First, my disclaimers - Perl is open source, module developers are likely not
> paid, the community is a little more democratic than .Net or Java, and I
> wouldn't be part of perl mongers if I didn't like it.  I do use perl some
> still for fun, but for work I use Java and most scripting can be done in
> shell easily enough.  Since java jdk 1.5 came out with regex support that
> rivals Perl's, I have dumped a lot of perl parsing code for a java version.
> =)
I'm not sure the open source factor matters as much as the specific
qualities of perl that make it hard for a large corporation to
maintain. Examples of this include Linux/Apache. Also, missing is the
very large corporate support for Perl as a development platform....
(ie, Sun and IBM's support for Java)

>
> Perl, as a language, is great.  I think my problem is that portability and
> maintenance of the Perl installation is a major pain the rear for me, even
> with the CPAN module or ppm in windows (although that does take care of many
> of my major issues - ppm).
We have a dedicated team who supports this and other stuff. But I
think a lot of companies would rather trust SUN or IBM to assure the
quality of the library set than rely on a group of open source
developers to do it... This is one of the values a large IT shop could
provide to Perl to make it more palitable to a company like where I
work. We would be more willing to accept open source code if IBM
guaruntees that it will work. (and pays large financial penalties
greater than or equal to the loss caused by bugs/failures)

> I don't think Perl needs a VM specifically, but more modules/additions should
> have been pure-perl (in Perl, for Perl, no compiling needed).  Module
> contributors aren't frequently evaluated or really accountable, (recent
> thread on perlmonks.org with some intelligent discussion on this).  Modules
> shouldn't have to go to the system libraries, or depend on 'expect' to be
> installed to use perl-expect.  This destroys portability.
A larger set of core library functionality would go a long way. ie,
move the extra CPAN modules into the core Perl distribution. However,
only certified-stable and pure only modules should be brought in.

> I want something that runs on linux and windows, mac, etc.  I spend most of my
> effort in Java nowadays because of this.  I keep toying with the idea of a
> perl2class application that will (miraculously) dump a Perl script and all of
> it's C/C++ dependent modules and junk to a single .class file.  Since I don't
> see how that could work, I just whine. =)
If I hit the lottery, I'm going to donate a large portion of it to the
Perl Foundation for the sake of accelerating Perl 6. It solves a bunch
of these kinds of problems. In fact, because of the language
architecture, you could compile your perl code into java byte code.
(Although because of design decisions made in each language and
therefore VM, Perl will never run as fast Java on the Java VM, and
Java will never run as fast as Perl on the Perl 6 VM).

> I like perl a lot, but I would rather use it like I use Jython/Groovy in Java.
> Even then, I am getting hooked on Groovy and may just use that instead of
> perl.</rant>
Java classes could be written to add certain perl-isms.... ie, Jerl. I
wonder if there is significance that on a Perl users group, we agree
that it's easier to use Java in the corporation?


More information about the Columbus-pm mailing list