Front page | perl.bootstrap |
Postings from July 2000
Re: Why we're here
From: Ken Fox
July 24, 2000 19:57
Re: Why we're here
Message ID: 397D013B.317FB10C@vulpes.com
Nathan Torkington wrote:
> email@example.com 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
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?