> >The same is true for anything... Sometimes a minimalist approach
> >is the right way to do it... The problem is to make sure when
> >using a minimalist approach that you don't make it too small...
> I think the more important thing is to not add completely redundant
> features without a really good reason, and features in general without a
> good reason.
> Statement modifiers are a good example. They are, arguably, a very
> redundant thing, but they add an awful lot of expressive power to the
> language, and are worth the redundancy.
True... They do speed up the process of writing code, too, given that
you can specify a lot in a small space. :) I just don't want 10 million
of them, is all... ;)
> >Personally, I'd prefer that the feature creep doesn't rear its
> >ugly head with Perl 6...
> Now there's the single biggest pipe dream I've seen in a long while. :)
A guy's gotta dream... ;-)
> >So do I... Not all Perl applications are built around
> >CGI/Web applications... :) That's what "libraries" are
> >for... ;)
> "Any suitably advanced library is indistinguishable from a
> builtin". I, for one, would like to bundle code to handle all
> the common protocols (SMTP, NNTP, NNTP, Mail, HTTP, and SOAP,
> at least) in with perl 6, or with the perl 6 common library.
However, the advantage of keeping it in the for its in now
means that updates can be made without rereleasing the interpreter :)
> While I don't know if Larry will mandate it, I would like this code:
>
> open PAGE, "http://www.perl.org";
> while (<PAGE>) {
> print $_;
> }
>
> to dump the HTML for the main page of www.perl.org to get dumped
> to stdout.
So open has to parse the string for a URL and magically use
a http protocol? Not sure I like that idea... Granted, from a
programmatical point of view that looks neater... But what
about the case where you have a file called "http:" (a legal
filename under unix if I'm not mistaken, granted though, this
is about as stupid as naming a script "test" then wondering
why it doesn't do anything when you type "test"...)
The only way that could work is if programmers could write
handlers for open, so that it could be extended later for
new protocols (see below)
> >*knock knock* Hello? Abstraction? Are you there????
> Don't forget that human language expresses concrete things as
> much or more than it does abstract things. Perl is at least
> partially a human language.
True... But the ability to say "This is a $something" is
an abstraction. You are putting together all the things that
make $something and calling it $something, thus hiding its
makeup.
> Abstraction is nice, but it's abstraction made concrete that does
> the heavy lifting. An abstract bicycle isn't going to get a real
> problem very far...
I agree... I'd prefer the concept of libraries to remain for
things like tcp/ip connections and the like. It allows flexibility
and extendability.
Looking at your open command earlier... Lets say a new protocol
comes out "tomorrow" and takes the world by storm. Lets call it
the fbtp (fscking brilliant transfer protocol)... Your method
would require re-releasing Perl to incorperate this new protocol,
given its wide acceptance.
The current one only requires a re-release of libnet. Much smaller,
less impact, and works for multiple revisions of Perl.
Now, I'm not saying we break out every little part of Perl into
little tiny bite sized chunks. That's stupid. A good percentage of
the language isn't going to change that rapidly... I just don't want
"too many" builtins...
Greg (Pipe dreaming for a Perl that isn't going to be overloaded...)
