Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: Re: perl2exe - no more secrets

by Anonymous Monk
on Feb 24, 2003 at 01:54 UTC ( [id://237997]=note: print w/replies, xml ) Need Help??


in reply to Re: perl2exe - no more secrets
in thread perl2exe - no more secrets

Learn how to program properly, and forget about perl2exe!

As long as this is the attitude of the Perl community, Perl will never be used for enterprise application development. I see frequent discussions asking for examples of commercial apps, large apps, and graphical apps. Granted, there are a couple examples out there but they are mostly low-profile and by most standards unsuccessful.

What Perl needs to take it to the next level is a good native compiler. I understand why people are against this, but I believe through the increased use and associated publicity of Perl it would in fact help the oss movement more than it would hurt it.

There are plenty of good reasons for native compilation, pretending that the only reason is to hide low-quality code is very ignorant. I'm still not sure this was your point though, so I apologize if I misinterpreted.

Then again, you could argue Perl has found its place already and shouldn't try to expand beyond its role. I personally think world domination is a much better goal ;-).

Replies are listed 'Best First'.
Re: Re: Re: perl2exe - no more secrets
by jasonk (Parson) on Feb 24, 2003 at 01:58 UTC

    While you are right that many enterprise users want a perl compiler, perl2exe is not a compiler. What it gives you is an executable that contains the perl binary, required libraries, and your script. It allows you to create standalone binaries, but it does not compile your perl to a native application, it simply bundles it with an appropriate perl interpreter.

Re: Re: Re: perl2exe - no more secrets
by perrin (Chancellor) on Feb 24, 2003 at 16:12 UTC
    Enterprise development? It sounds more like you're talking about packaged commercial applications. Enterprise development usually means something built in-house that is specific to a business. These days it often means putting the company's business on the web, which would not involve a compiler.

    I agree that the inability to effectively compile Perl works against it being used to build packaged commercial software, but that's a fairly unusual thing to choose Perl for. That realm seems pretty well locked up by C++. Perl is more at home on the server side, where this sort of thing is not an issue.

      Sorry, wrong buzzword. You got my point though :)

      As for using perl for packaged commercial software, I mostly agree with your point. Personally I wouldn't use perl for such a project but there are those who definately would like to. I think it also applies to the server-side. Sadly, not every company wants to give the source out to every product they sell. This leads them to other languages. Is this good or bad? Hard to say, but people shouldn't be surprised when some companies don't consider perl and option because of it.

Re: Re: Re: perl2exe - no more secrets
by CountZero (Bishop) on Feb 24, 2003 at 16:48 UTC

    A very good explanation why a "good native compiler" will not be better than the Perl.pl to Perl.exe utilities we already have, can be found in " Why Not Translate Perl to C?".

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      A very good explanation why a "good native compiler" will not be better than the Perl.pl to Perl.exe utilities we already have, can be found in " Why Not Translate Perl to C?".
      Except that that explanation is baloney. People have been compiling dynamic languages (such as LISP) for decades. Yeah, it's hard. But it does make programs much faster.

        You didn't understand me correctly: I'm not saying that compiled Perl is as fast/slow as interpreted Perl, but that "a good native compiler" will be hard pressed to be faster than Perl compiled with the existing utilities, eg. dump Perl into C and compile this C code.

        CountZero

        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      Yeah, I read that one a while back and I completely disagree with it. It sounds kind of like this to me:

      the Perl vm is pretty good for a vm and it might take a little effort to write a better compiler, so perl's perfect again, so yeah, move along. what do you mean that doesn't make any sense? well, you obviously don't know what you're talking about. See this function? it's fast in perl. If I poorly write a c-equivalent, it's slow. So why don't I write it well? because perl is good. Perl rox0rs.

      The end.

      It's very possibly to write a native compiler for Perl that would produce faster, more efficient code. Nobody seems to want to do it though, probably because they don't want to deal with the negative response from the community. So instead they focus on the next-gen scripting languages.

        Big words, no evidence. If it's so very possible to write a native compiler that produces faster, more efficient code, what's keeping you from writing it?

        When you have finished your compiler, come back and show us to be wrong. Otherwise, just shut up.

        Abigail

A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://237997]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (2)
As of 2024-03-19 06:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found