Front page | perl.bootstrap |
Postings from August 2000
Re: I'm a lurker too ...
Thread Previous
|
Thread Next
From:
Dan Sugalski
Date:
August 7, 2000 13:01
Subject:
Re: I'm a lurker too ...
Message ID:
4.3.2.7.0.20000807155509.00da8b50@24.8.96.48
At 12:48 PM 8/7/00 -0700, Gary Richardson wrote:
>On Mon, 07 Aug 2000, you wrote:
> > 1. A Perl to C or Perl to machine code compiler. Perl is fast, but
> > compiled C is an order of magnitude faster. (And I vote for data types,
> > i.e. my int $num, so that a compiler do its job that much better.)
>
>Compiling perl will only cut down on initial loading (I am guessing).
Incorrectly, actually. It's quite possible that a perl2C or perl2something
backend (likely one that connected to a real compiler's optimizing backend,
like gcc or DEC's GEM backend) would get you faster code in spots, though
whether it was overall fast enough to be worth it's an open question.
Not likely to be done to start just for portability reasons. Building a
portable interpreter's enough fun--building backends for all the
architecture/OS combos perl runs on would be a major pain.
> > 3. Visual Perl. Just like Visual Basic and Delphi, but its Perl and runs
> > almost everywhere, not just windows.(I know ActiveState is working on a
> > product called Visual Perl, but I'm note sure this will be just like VB
> > or if it will run on non-windows platforms.)
>
>See Perl/TK and/or GTK.
>
>Perl runs just about everywhere, as does TK, there for Perl/TK runs just
>about everywhere..
Incorrect assumptions. Many Unices, yes. Windows, mostly. VMS, sort of.
That leaves out a lot of perl's platforms. (Mac, anyone?)
This is more an add-on, though it wouldn't hurt to do simultaneous
development to get the appropriate hooks from perl to make it easier.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk
Thread Previous
|
Thread Next