Suggestion: Can we manually renumber this "RFC 0"? This should be the
first one at the top of the list, not buried somewhere within. my($.02).
-Nate
Perl6 RFC Librarian wrote:
>
> 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
