Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> Maintainer: Simon Cozens <[EMAIL PROTECTED]>
>
> =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.
Agreed. OO should be easy to do. It would be great if it were more
powerful than the OO we have already (which is pretty damned fine),
but it should *not* be required.
> =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.
I want to be able to say 'my Dog $spot' and have the
compiler/optimizer take notice of this and be able to give me more
efficiency. Of course, if everything is way more efficient to do then
maybe any perf gains would be marginal, but it's still nice to have.
It should *not* be required.
> =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 it's been OO as well since 5.0, why not add the possibility of
Functional programming as well.
So long as it doesn't interfere with doing stuff the old way. Damian's
__ syntactic sugar for instance is gorgeously powerful idea that
manages (to my eyes at least) to both support weird functional
programming type stuff *and* neatly Perlish in feel. And with __ in
place it seems to me that the argument for a 'native' reduce isn't so
strong because it becomes easy to write one that does the right thing
without it being a special case.
> =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.
This one hits the nail bang on the head. Again IMHO. Perl is great
because 9 times out of 10 it does The Right Thing. And it does it in
such a spectacular variety of contexts. When I'm doing the canonical
one line hacks then all the lovely DWIMmery lets me be concise and
powerful, when I'm doing large projects then Perl's OO helps me there
too (though it could be *more* helpful). The beauty of Perl, for me,
is that she gets the hell out of my way and lets me express myself
freely in a form that the machine can actually do something with. I
don't have to jump through hoops with Perl, I just Do It, and Perl
does the Right Thing.
This should be our acid test; 'does perl make it easy?' Arguing about
whether more OO or more functional programming style is a good idea or
not is beside the point. Is it easy? Is it possible? Is it 'rich'?
Does it make you smile?
If you're Abigail does it make you want to use it for a Japh?
--
Piers
print reduce {__ . chr(__)} '',74,117,115,116,32,97,32,119,97,110,
110,97,98,101,32,80,101,114,108,32,54,32,104,97,99,107,101,114,46;
