This and other RFCs are available on the web at
http://tmtowtdi.perl.org/rfc/
=head1 TITLE
Perl should stay Perl.
=head1 VERSION
Maintainer: Simon Cozens <[EMAIL PROTECTED]>
Date: Aug 4 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 28
=head1 ABSTRACT
We've got a golden opportunity here to turn Perl into whatever on earth
we like. Let's not take it.
=head1 DESCRIPTION
Perl 6 is our opportunity to give Perl a good spring clean. When you're
spring cleaning a house, you throw out the trash and dust down the
ornaments, but you don't burn it down and build a shopping mall
instead.
I think it's reasonably fair to assume that we're all B<primarily>
working on Perl 6 because we like Perl and we want to make it better,
not because language design is a fun thing to do of an evening. If
that's the case, nobody wins if we bend the Perl language out of all
recognition, because it won't be Perl any more. So let's not do this.
Let's keep Perl recognisably the language we know and love; let's
enhance it, by all means, but let's not turn it into something it isn't.
Specifically, we need to watch out for the following ``attractive
nuisances''.
=over 3
=item Object Orientation
Some things just don't need heavy object orientation. B<Most> things
don't need heavy object orientation, and it's not Perlthink to force
programmers into onerous routine they don't need; I'd hate it to get to
the stage where I can't write a one-liner because I have to instantiate
a class and wibble an object and who the hell knows what else. The CS
types may love it, but I'm a programmer and I don't. Let's keep making
easy things easy.
=item Strong Typing
Much the same applies. Strong typing does not equal legitimacy.
The CS types may love it, but I'm a programmer and I don't.
=item Functional Programming
Just because Perl has a C<map> operator, this doesn't make it a
functional programming language. Perl has always been squarely
procedural, and so things like C<reduce> and C<curry> and other cookery
terms are somewhat out of place; they can be far more easily and
appropriately implemented as extension modules I<post hoc>. By all
means, let's generalise the problem, and make it easier to define your
own syntax, but let's not add the entirety of LISP and ML to the core.
The CS types may love it, but I'm a programmer and I don't.
=item Making Parsing Easier
Perl is really hard for a machine to parse. B<Deliberately>. If you
think it shouldn't be, you're missing something. The syntax
and semantics of the Perl language are supposed to fit your mind, not
the other way around. It's meant to be far, far more like a human
language than a programming language. It's meant to be easy for humans
to understand. Yeah, the upshot of this is that, just like a human
language, you have to use context to resolve ambiguities in lexing, and
the upshot of that is that your tokeniser and parser merge into one. But
that's not a big deal as far as implementation is concerned; it's
standard natural language processing practice. You're going to have a
seriously hard time trying to force Perl into a strict lex/yacc model
without completely killing off its attractiveness, and a lex/yacc model
doesn't really gain you anything special anyway. The CS types may love
it, but I'm a programmer and I don't.
=back
=head1 IMPLEMENTATION
Just don't go raving mad, OK?
=head1 REFERENCES
