| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
Perl should stay Perl.
Maintainer: Simon Cozens <simon@brecon.co.uk> Date: 4 Aug 2000 Mailing List: perl6-language@perl.org Number: 28 Version: 1 Status: Developing
We've got a golden opportunity here to turn Perl into whatever on earth we like. Let's not take it.
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 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''.
Some things just don't need heavy object orientation. 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.
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.
Just because Perl has a map operator, this doesn't make it a
functional programming language. Perl has always been squarely
procedural, and so things like reduce and curry and other cookery
terms are somewhat out of place; they can be far more easily and
appropriately implemented as extension modules 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.
Perl is really hard for a machine to parse. 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.
Just don't go raving mad, OK?