Re: Why we're here
[email protected] (Ken Fox)
| Newsgroups | perl.bootstrap |
|---|---|
| Organization | None Apparent |
| Message-ID | <[email protected]> |
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? - Ken