Re: Why we're here

On Mon, Jul 24, 2000 at 10:53:47PM -0400, Ken Fox wrote:
> Nathan Torkington wrote:
> > [email protected] writes:
> > > Let's focus on making perl, as possible Perl, better. Make it faster,
> > > more maintainable. But don't change the language into something that
> > > isn't Perl.
> 
> > Fears about great changes to Perl are, imho, unfounded.  The biggest
> > changes will be made on the insides.  The language itself will be
> > different, but not to the point of removing dollar signs and replacing
> > punctuation operators with uppercase keywords:
> 
> Argh. I'm conflicted here. I like Perl the way it is, but obviously I'd
> like it to be "better". Making things better often breaks them and the
> more I like something the less I can tell when I'm breaking it. I'm
> perfectly happy to have Larry decide what Perl is. That seems to be the
> consensus and I'm glad we're not debating it.
> 
> *However*, there are two points to Perl that are most important for me
> and they're both in conflict with the ideas of "don't change Perl" and "let
> Larry guide us".
> 
> 1. The Perl community. Creative, nurturing, proud, intelligent, diverse,
>    funny, generous, etc. This is the main reason I use Perl -- I want to
>    be a part of the community. There are more role models than you can
>    shake a stick at. (And because of the anti-role models I'm sure they've
>    all had sticks shaken at them... ;)
> 
>    This influence wants me to be able to dream, explore, invent and share
>    the experience with the community. Perl, the implementation, should make
>    playing with Perl, the language, enjoyable. The Author of the story has
>    created the Perl universe, but I read that as the *beginning* of the
>    story.
> 
> 2. The Perl philosophy. There's more than one way to do it. I'm not talking
>    syntax here, I'm talking semantics, patterns and idioms. Perl easily
>    expresses procedural, functional, object-oriented and symbolic styles.
>    State machines, lambda functions, closures, exceptions, iterators, ...
>    I've rarely read about algorithms that would be hard to implement in
>    Perl. Maybe I'm not well-read, but it still seems Perl is doing
>    something differently and much better than most languages.
> 
>    This influence drives me to change the tool to better fit the problem.
>    When I'm in problem solving mode, I want the best tool and often that's
>    Perl with a little bit of domain-specific sugar thrown in. I think it
>    would be fabulous to be able to stretch Perl even further.
> 
> I don't want to admit that I want to change Perl. Am I waxing pathetic here
> or do others feel the same?

One of Larry's goals for Perl5 was to allow the core language to stabilize
by implementing a powerful extension mechanism.

That's worked amazingly well, all things considered.

I am quite sure that Larry will use the leasons learned to carry that
concept further forward in Perl6.

Tim.