--- "Stephen P. Potter" <[EMAIL PROTECTED]> wrote:
> Lightning flashed, thunder crashed and Tom Christiansen
> <[EMAIL PROTECTED]
> m> whispered:
> | Unless that's done completely transparently, you'll
> pretty much screw the
> | pooch as far as "Perl is the Cliff Notes of Unix"
> notion. Not to
> | mention running a very strong risk of butchering the
> performance.
>
> I don't think there is any ruling from Larry that perl
> must remain the
> "Cliff Notes of Unix." In fact, there seems to be a bit
> of a concerted
> effort (partly suggested by Larry, IIRC) to make perl
> *less* Unix-centric
> and more friendly for other environments.
>
> I'm not concerned with performance, per se. I have
> confidence in the
> people who will actually write the code to take care of
> that issue.
> Performance will be a factor in deciding whether this can
> be implemented or
> not. If performance will suffer unacceptably, then this
> won't get
> implemented.
It probably would. Dynamic loading is not cheap, and having
to do a dlopen() and a dlsym() (or a LoadLibrary() and a
GetProcAddress()) to find out the square root of 2 is not
my idea of a _useful_ lightweight programing language.
> | I don't understand this desire to eviscerate Perl's
> guts. Having
> | everything you want just *there* is part of what's made
> Perl fast,
> | fun, and successful. Good luck on preserving all
> three.
>
> This desire stems from having a wonderful mechanism for
> making the core
> more lightweight (hopefully improving performance) called
> loadable
> modules. Larry designed this feature for a reason, and
> has been saying
> since the early perl5 alphas that we could/should migrate
> some things out
> of the core. I'm simply suggesting all the parts that I
> think reasonably
> go together than could be migrated. They can still be
> "there", just in a
> module. If the AUTOLOAD stuff that is being discussed
> works out, you won't
> even know the internals have changed.
AUTOLOAD searches are not cheap either. It can take a lot
of stat() calls to even _find_ the correct module, much
less load it. The average math function in the perl5 core
is about 13 lines of C code. Eviscerating it out of the
core would accomplish nothing.
> I don't understand this desire to not want anything to
> change. This is an
> opportunity to clean up the language, make it more
> useable, and more fun.
Slowing perl down and forcing everyone to add 5 "use"
statements to the top of every program to get any useful
features would neither make it more useful or more fun.
> I would have a lot more fun if perl were a better
> performer and if it was
> easy for me to expand it, contract it, reshape it,
> improve it, etc.
>
> -spp
-- BKS
__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
