Re: Larry's Apocalypse 1
At 11:39 AM 4/10/2001 +1000, Damian Conway wrote: >> Of course all of this has been discussed. (See >> http://archive.develooper.com/perl6-language-io%40perl.org/, >> especially RFCs 100 and 14.) > >And is already available in a nearby parallel dimension: > > http://www.yetanother.org/damian/Perl5+i/open.html Yes, but the agency *has* disavowed all knowledge... :-P Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Larry's Apocalypse 1
"Greg Boug" <[EMAIL PROTECTED]> writes: > 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) Of course all of this has been discussed. (See http://archive.develooper.com/perl6-language-io%40perl.org/, especially RFCs 100 and 14.) Jon
Re: Larry's Apocalypse 1
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> While I don't know if Larry will mandate it, I would like this code:
>
>open PAGE, "http://www.perl.org";
>while () {
> print $_;
>}
>
> to dump the HTML for the main page of www.perl.org to get dumped to
stdout.
>
Now I would like to get some of the metadata for that page like expiration
date, length, content type, etc. How?
Moreover, the http server would return a "404" in case the remote document
is not found (probably not under the example above, but...) I would like
ability to trap such type of remote exceptions.
jc
RE: Larry's Apocalypse 1
> >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 () {
> 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...)
Re: Larry's Apocalypse 1
On Mon, Apr 09, 2001 at 12:58:23PM -0400, Andy Dougherty wrote: > > Let's leave -e alone for now and worry about handling specific > incompatibilities when we in fact have some specific incompatibilities to > worry about. Amen. Tim.
RE: Larry's Apocalypse 1
John Porter wrote > > I'm sure you don't want to write "$a = new Integer '32'". > > Of course. That would be unbearably absurd. > But how often do you have to write expressions that > operate on three or more URLs? Or even two? > How many perl instrinsics return URLs? How many > perl intrinsics operate on URLs in any way? > > > A related question is why we want to tie objects. Afterall, > > you can use methods on an object without ever tying it! > > HTF does tying have anything to do with the current thread? Since you ask so politely: Tying is a mechanism by which a programmer can make an object look like a built-in. This can be useful. I was looking at the "http:...' as a specific example of a general mechanism by which a programmer can make a class behave like a built-in wrt its ctor. I see this ability to define a new type of literal as being analagous to tying. They are both special cases of the general concept of using magic to hide the fact that you're using a class. Obviously they are very different in the specifics. You may be right that there are no useful literals other than strings, integers, reals and lists. OTOH, if we are going to construct a meta-language which supports multiple syntaxes, then it is very likely that each application-specific language would have its own literals. The question becomes whether perl itself should have this ability. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
Re: Larry's Apocalypse 1
At 12:31 PM 4/9/2001 -0600, Dan Brian wrote: > > There won't be any magic toggles to make typeglobs come back if they go > > away, or anything of that sort. Default behaviours like warning and > > strictness may vary depending on whether perl thinks it's parsing a module > > specifically written for perl 6 or not, but that's a far cry from parsing > > perl 5 code generally. > >OK, I follow. > >So are we resolved on why we need a flag for the interpreter (back to the >one liners)? No, we don't. Since the proposed functionality is to enable perl 5's level of warnings and strictness unless we know otherwise (i.e. none), there's not much point. If one puts the module keyword in a one-liner, one deserves the behaviour one gets. And if you *want* strictness and/or warnings on, the current M flag will work just dandy for you, as it does with perl 5. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Larry's Apocalypse 1
> There won't be any magic toggles to make typeglobs come back if they go > away, or anything of that sort. Default behaviours like warning and > strictness may vary depending on whether perl thinks it's parsing a module > specifically written for perl 6 or not, but that's a far cry from parsing > perl 5 code generally. OK, I follow. So are we resolved on why we need a flag for the interpreter (back to the one liners)?
Re: Larry's Apocalypse 1
At 12:02 PM 4/9/2001 -0600, Dan Brian wrote: > > Still, I'll be really, *really* surprised if most perl code require any > > rewriting to run under perl 6. TomC's got quite a cache of old perl code, > > and I've got some mildly hairy perl 5 code that I want perl 6 to eat > > without complaint. > >OK. But by the current thread, this ability of perl6 to interpret perl5 >needs a toggle, No. No it doesn't. Perl 6 is *not* going to interpret perl 5 specific code. Period. That's what the p526 backend for perl 5's B:: is going to be for. Perl 6 will parse and run perl code that meets the perl 6 spec, one that I expect will encompass most normal code we have now. There won't be any magic toggles to make typeglobs come back if they go away, or anything of that sort. Default behaviours like warning and strictness may vary depending on whether perl thinks it's parsing a module specifically written for perl 6 or not, but that's a far cry from parsing perl 5 code generally. >That is, the syntax will not be compatible. That turns out not to be the case. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Larry's Apocalypse 1
> Still, I'll be really, *really* surprised if most perl code require any > rewriting to run under perl 6. TomC's got quite a cache of old perl code, > and I've got some mildly hairy perl 5 code that I want perl 6 to eat > without complaint. OK. But by the current thread, this ability of perl6 to interpret perl5 needs a toggle, be it a package/module declaration, a #! switch, whatever. That is, the syntax will not be compatible. Whether the perl6 interpreter is *able* to 'do' perl5 is not so much the issue as how it will do it. So already you have broken perl5 insomuch as it has to be interpreted *as* perl5. From here on out, it's just a matter of implementation. Do you use a switch, do you use a different interpreter. Does the switch actually just fork another interpreter? I suppose the talk of a ubiquitous "meta-language" which allows you to write perl with whatever syntax you choose would solve this, but I am highly skeptical of anybody's ability to define such a language that would accomodate obfuscated perl5. Imagine how that would look. > Yeah, but innovation at the cost of legacy's not a great idea either. Don't > forget we have an enourmous legacy base--every single person who programs > in perl now. This is probably our last chance for a big language upheaval > for quite a while, but that doesn't mean that we're actually going to have > that much of one. Well, it is going to be substantial. Again, if we need to differentiate at interpreter startup, regardless of the implementation, it is going to be substantial. Otherwise, perl6 should just be able to know the difference when it encounters small syntactical differences, and we wouldn't be having the conversation.
Re: Larry's Apocalypse 1
At 11:16 AM 4/9/2001 -0600, Dan Brian wrote: > > This one here's been bugging me for a bit. Larry never said that perl 6 > > would assume its input code was perl 5. Perl 6 will always assume its > input > > is perl 6. The said (and I'm still trying to dig up the quote) is that > > we'll be enabling warnings and strict by default (as opposed to the off by > > default now) if and only if perl can tell it's parsing code for a module. > > (Via the "module" keyword) > >Actually, the quote in "Apoc1" reads: > >--- That is, Perl 6 must assume it is being fed Perl 5 code until it >knows otherwise. And that implies that we must have some declaration that >unambiguously declares the code to be Perl 6. I must've been looking at an older rev or something, and I'm pretty sure Larry's talked about this sort of thing elsewhere. Perl 6 is a new release of perl, it's not a completely different language. Perl is, still, perl. >Without throwing more hornets into the nest, I think it's worth >considering that by and large, most people using both perl6 and perl5 will >opt to differentiate right on the command-line or #!. I know I will. It >isn't *that* difficult to keep 2 local interpreters lying around. Or 3; I >still have a perl4 somewhere. Or four or five... I think at this point you can throw a version or two of Tcl and Python on the ubiquitous interpreter heap. Still, I'll be really, *really* surprised if most perl code require any rewriting to run under perl 6. TomC's got quite a cache of old perl code, and I've got some mildly hairy perl 5 code that I want perl 6 to eat without complaint. >I understand why lots of people freak when considering that perl6 will be >totally different. But I don't. Simple migration is good. Legacy at the >cost of innovation is not. Yeah, but innovation at the cost of legacy's not a great idea either. Don't forget we have an enourmous legacy base--every single person who programs in perl now. This is probably our last chance for a big language upheaval for quite a while, but that doesn't mean that we're actually going to have that much of one. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Larry's Apocalypse 1
> This one here's been bugging me for a bit. Larry never said that perl 6 > would assume its input code was perl 5. Perl 6 will always assume its input > is perl 6. The said (and I'm still trying to dig up the quote) is that > we'll be enabling warnings and strict by default (as opposed to the off by > default now) if and only if perl can tell it's parsing code for a module. > (Via the "module" keyword) Actually, the quote in "Apoc1" reads: --- That is, Perl 6 must assume it is being fed Perl 5 code until it knows otherwise. And that implies that we must have some declaration that unambiguously declares the code to be Perl 6. Without throwing more hornets into the nest, I think it's worth considering that by and large, most people using both perl6 and perl5 will opt to differentiate right on the command-line or #!. I know I will. It isn't *that* difficult to keep 2 local interpreters lying around. Or 3; I still have a perl4 somewhere. I understand why lots of people freak when considering that perl6 will be totally different. But I don't. Simple migration is good. Legacy at the cost of innovation is not.
Re: Larry's Apocalypse 1
> >I'm still trying to figure out why the flag needs to change. What's wrong > >with -e? It seems perfectly serviceable. > > Because Larry said that by default Perl 6 would assume that its input was > in Perl 5...? So we need a way to tell it that it isn't. This one here's been bugging me for a bit. Larry never said that perl 6 would assume its input code was perl 5. Perl 6 will always assume its input is perl 6. The said (and I'm still trying to dig up the quote) is that we'll be enabling warnings and strict by default (as opposed to the off by default now) if and only if perl can tell it's parsing code for a module. (Via the "module" keyword) This all might change, of course, but that's my understanding of things as they stand now. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Larry's Apocalypse 1
At 09:48 AM 4/9/2001 -0700, Peter Scott wrote: >At 12:38 PM 4/9/01 -0400, Dan Sugalski wrote: One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go the multiflagged way, why not reflect `-e' to get the `-6' flag? At the very least, I want a short flag! >>> >>>But by the time people learned to use '-6' we'd have Perl 7 out. >> >>I'm still trying to figure out why the flag needs to change. What's wrong >>with -e? It seems perfectly serviceable. > >Because Larry said that by default Perl 6 would assume that its input was >in Perl 5...? So we need a way to tell it that it isn't. Why? Perl is perl. Version 6 will have some of the bits twiddled some relative to version 5, but I don't know that too many people feed one-liners with globs in them to perl other than the odd JAPH. Things like perl -i.bak -pe "s/foo/bar/" will work in perl 6 just as well as in perl 5. Larry's tweaking the language some, not switching to Python... ;) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Larry's Apocalypse 1
On Mon, 9 Apr 2001, Peter Scott wrote: > >I'm still trying to figure out why the flag needs to change. What's wrong > >with -e? It seems perfectly serviceable. > > Because Larry said that by default Perl 6 would assume that its input was > in Perl 5...? So we need a way to tell it that it isn't. perl -M6 -e ... -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
On Mon, 9 Apr 2001, Peter Scott wrote: [ -e vs. --cmd vs. -6] > Whatever we come up with, let's figure out how to avoid having to change it > the next time we change Perl. I don't think this is getting us anywhere useful. What happens if perl7 is sufficiently different from perl6 in such a way that you could imagine needing to distinguish for a one-liner between perl6 and perl7? This would be exactly the perl5/perl6 problem we face now. And, I hasten to point out, this is very similar to the perl4/perl5 problem we faced some time ago. Like most challenging design issues, there is probably no single ideal solution, and it's rather pointless to endlessly debate it in a vacuum. One needs to consider each issue individually against the larger backdrop of the goal of being mostly compatible. Perl's history is rich with examples of both keeping and breaking compatibility. Perl6 is likely to continue in that tradition. Let's leave -e alone for now and worry about handling specific incompatibilities when we in fact have some specific incompatibilities to worry about. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
At 12:38 PM 4/9/01 -0400, Dan Sugalski wrote: >>>One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go >>>the multiflagged way, why not reflect `-e' to get the `-6' flag? At >>>the very least, I want a short flag! >> >>But by the time people learned to use '-6' we'd have Perl 7 out. > >I'm still trying to figure out why the flag needs to change. What's wrong >with -e? It seems perfectly serviceable. Because Larry said that by default Perl 6 would assume that its input was in Perl 5...? So we need a way to tell it that it isn't. -- Peter Scott Pacific Systems Design Technologies
Re: Larry's Apocalypse 1
At 09:35 AM 4/9/2001 -0700, Peter Scott wrote: >At 09:36 AM 4/9/01 +0200, Ariel Scolnicov wrote: >> > > Hmm... programs that have perl one-liners inside them might be >> > > troublesome. >> > >> > Why not: >> > >> > perl -e 'perl 5 one-liner' >> > >> > perl --cmd 'perl 6 one-liner' >> > >> > i.e. maintain the "-e" switch as a backward compatibility flag, with a new >> > cmd line flag for perl 6. >> >>One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go >>the multiflagged way, why not reflect `-e' to get the `-6' flag? At >>the very least, I want a short flag! > >But by the time people learned to use '-6' we'd have Perl 7 out. I'm still trying to figure out why the flag needs to change. What's wrong with -e? It seems perfectly serviceable. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Larry's Apocalypse 1
At 05:21 PM 4/9/2001 +0100, Simon Cozens wrote: >On Mon, Apr 09, 2001 at 11:48:43AM -0400, John Porter wrote: > > > Yes, we could throw damned well everything into > > > Perl, and you might want to consider that "equally valid". > > > > I might, but I wouldn't. That's precisely why I'm arguing > > against adding URLs as an intrinsic type! > >Then you are indeed agreeing with Greg, whose statement that sometimes >minimalism is the right way to go you dismissed as being completely >contrary to Perl philosophy. Can you see why this is confusing? I think you might be getting a bit too black'n'white here. Arguing against one particular proposal doesn't make one minimalist, any more than arguing for a proposal makes one a maximalist. There's plenty of space in the middle. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Larry's Apocalypse 1
At 09:36 AM 4/9/01 +0200, Ariel Scolnicov wrote: > > > Hmm... programs that have perl one-liners inside them might be > > > troublesome. > > > > Why not: > > > > perl -e 'perl 5 one-liner' > > > > perl --cmd 'perl 6 one-liner' > > > > i.e. maintain the "-e" switch as a backward compatibility flag, with a new > > cmd line flag for perl 6. > >One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go >the multiflagged way, why not reflect `-e' to get the `-6' flag? At >the very least, I want a short flag! But by the time people learned to use '-6' we'd have Perl 7 out. Whatever we come up with, let's figure out how to avoid having to change it the next time we change Perl. -- Peter Scott Pacific Systems Design Technologies
Re: Larry's Apocalypse 1
On Mon, Apr 09, 2001 at 11:48:43AM -0400, John Porter wrote: > > Yes, we could throw damned well everything into > > Perl, and you might want to consider that "equally valid". > > I might, but I wouldn't. That's precisely why I'm arguing > against adding URLs as an intrinsic type! Then you are indeed agreeing with Greg, whose statement that sometimes minimalism is the right way to go you dismissed as being completely contrary to Perl philosophy. Can you see why this is confusing? -- Last week I forgot how to ride a bicycle. -- Steven Wright
Re: Larry's Apocalypse 1
Simon Cozens wrote: > > Uhm, no. Not at all. Just because there's more than one way to do it, > doesn't mean that one must consider *all* ways equally worthy when one > simple solution presents itself. Huh? If I'm against one extreme, I must be for the other? No, I'm reasonable. Like you. > (I suggest you have a look over the code to GNU Hello a few times. :) I would argue that part of the philosophy of Perl is that sometimes perl isn't the best tool for the job. Sometimes it *is* better to spawn sort, or awk, or ps. IOW, just because Perl isn't a minimalist language, doesn't mean it admits no minimilism in its universe. But such an argument would be irrelevant to this thread. > Besides, you're not separating the *use* of a programming language > from its design. Yes, I am, because I am only talking about its "use", i.e. the face that it presents to the programmer. (It's "character".) > A minimal approach to design *is* a good idea. Of course it is. I didn't think there was any question there. > Yes, we could throw damned well everything into > Perl, and you might want to consider that "equally valid". I might, but I wouldn't. That's precisely why I'm arguing against adding URLs as an intrinsic type! Once again, you seem to want to think that we disagree. -- John Porter Like music? Then you're gonna love this. I was into these dudes before anybody. Asked me to be the manager.
Re: Larry's Apocalypse 1
I don't think that extreme positions ("minimalist!" "bloater!")
helps here. I think the important question to ask about any given
feature is: what will it let me do? Features with no good answer to
this question obviously have no place in core. Attempting to align
with one or another philosophical camp before pragmatically evaluating
the benefits of something seems a waste of everyone's time.
Nat
Re: Larry's Apocalypse 1
On Mon, Apr 09, 2001 at 10:37:19AM -0400, John Porter wrote: > Greg Boug wrote: > > Sometimes a minimalist approach > > is the right way to do it... > > If one believes that, wrt programming languages, then one > is opposed to the philosophy of Perl. Oh well. Uhm, no. Not at all. Just because there's more than one way to do it, doesn't mean that one must consider *all* ways equally worthy when one simple solution presents itself. (I suggest you have a look over the code to GNU Hello a few times. :) Besides, you're not separating the *use* of a programming language from its design. A minimal approach to design *is* a good idea. Yes, it's "one way to do it". Yes, we could throw damned well everything into Perl, and you might want to consider that "equally valid". Fine. But "the philosophy of Perl" goes on down at the business end, where people use it, and the important philosophy of the design and implementation side is how to best allow people to use Perl in whatever ways they want. There might well be one good and easy approach which enables that, and if so then Greg is right. -- Relf Test Passed.
Re: Larry's Apocalypse 1
David Grove wrote: > Does your "A" stand for "A" or "Another"? The latter. Sorry, guess I shouldn't have abbreviated it. > The second point is that, John, you forget that Rebol actually did have > some degree of kewlness to it I don't think I'm forgetting that. I'm just resisting the temptation to say "If you want Rebol, you know where to find it." > datatypes of HTTP, FTP, MAIL, and the like. I'm not saying we should go > that far, since OOP can simulate this for us, but only that it did have > some kewlness of its own. Base data types don't have to be limited to > strings and numbers... As I understand it, those other datatypes are not fundamental, but are pre-defined extension types, i.e. built using the language's type extension mechanism. Part of the reason they're there is to illustrate the language's type extension mechanism. (Or am I wrong?) Perl6 may well have an analogous feature. -- John Porter
Re: Larry's Apocalypse 1
Dan Sugalski wrote: > 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. Absolutely. Can we engrave that in a PDD sometime soon? >open PAGE, "http://www.perl.org"; That's very fine, IMHO. It puts the polymorphism in open(). The URL is still just a string. As it should be. -- John Porter
Re: Larry's Apocalypse 1
Greg Boug wrote: > Sometimes a minimalist approach > is the right way to do it... If one believes that, wrt programming languages, then one is opposed to the philosophy of Perl. Oh well. > The problem is to make sure when > using a minimalist approach that you don't make it too small... If you don't make it as small as *possible*, regardless of the practical consequences, then you're not taking a minimalist approach. > Oh, and BTW, please define "better"... That's a secondary issue. > I'm gonna assume that "better" means "what Larry determines > to be a useful addition to the language"... That's not a useful definition, because it would be tautological. -- John Porter
RE: Larry's Apocalypse 1
At 12:31 PM 4/9/2001 +1000, Greg Boug wrote:
> > David Whipp wrote:
> > IOW, simply to have AWTDI is one of the worst reasons to add a
> > feature. If it doesn't make the language *better*, LEAVE IT OUT.
>
>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.
>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. :)
> > So are we to the point of making LWP a built-in?
> > I hope not.
>
>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.
While I don't know if Larry will mandate it, I would like this code:
open PAGE, "http://www.perl.org";
while () {
print $_;
}
to dump the HTML for the main page of www.perl.org to get dumped to stdout.
>*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.
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...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Larry's Apocalypse 1
John Porter <[EMAIL PROTECTED]> wrote:
> David Whipp wrote:
> > > A language that doesn't have everything is actually easier to
program
> > > in than some that do.
> >
> > The obvious reply is: "There's more than one way to do it"
>
> To which the obvious reply is:
>
> 'Although the Perl Slogan is "There's More Than One Way
> to Do It", I hesitate to make 10 ways to do something.'
> - Larry Wall
>
> IOW, simply to have AWTDI is one of the worst reasons to add a
> feature. If it doesn't make the language *better*, LEAVE IT OUT.
Does your "A" stand for "A" or "Another"? If "Another", then this may have
some merit. If "A" then it is a horrible misapplication of a good quote
and a dangerous excuse for myopia (regardless of the topic or thread,
which I haven't followed so don't defend it to me).
> > I'm sure you don't want to write "$a = new Integer '32'".
>
> Of course. That would be unbearably absurd.
> But how often do you have to write expressions that
> operate on three or more URLs? Or even two?
> How many perl instrinsics return URLs? How many
> perl intrinsics operate on URLs in any way?
> So are we to the point of making LWP a built-in?
> I hope not.
Two points come to mind.
The first is that many programmers "born" after 1990 tend to think of OOP
as THE way of programming, or the natural end of programming evolution;
whereas many born before that time think of it as simply another way
(sometimes better, sometimes an unsurmountable hassle) of looking at or
applying data and functionality. Programmers of "functional languages"
used to think that theirs was the final step in prorgramming evolution
until OOP came along. Punchcard programmers thought that COBOL was "where
it's at". OOP programmers will get a stiff clue as programming evolves
even further.
I think that one of Perl's major benefits is that it doesn't have a
dependence upon one particular methodology, as does Java, C#, Python,
Ruby, and other new languages. When the next paradigm comes along, those
languages will have their "old fogeys" just like COBOL... some have tried
and failed to bring that back into the mainstream by making it OOP. Perl,
C, and a few others have the ability to rebound from this, and evolve into
the next generation without overhauling the base language. The OOP-only
languages will cease to evolve, according to a historical perspective of
what languages have evolved to become successful over the long term,
because they can only change by blowing up every program ever written in
that language.
(If you want an opinion on what the next step in evolution might be, I'd
say it would be from OOP to terse; or from verbose to perlishly
quick-and-dirty... having the ability of going for small scripts [not
suitable for OOP languages] as well as for large applications [not well
suited to functional-only or linear languages]... meaning I see Perl
itself as a foreshadow of the next generation.)
If "features" like this were optional for clarity for people who needed to
see OOP for the sake of OOP, no problem. But I'd caution anyone who wanted
to take away Perl's flexibility to evolve. I'd also caution that forcing
this level of verbosity on a Perl programmer is a good way of turning
him/her back to C or off to Python. Besides, this is programmer-level hard
typing, and something that we've learned through experience is an
overrated concept.
(I'm agreeing with John, but giving a reason for it.)
The second point is that, John, you forget that Rebol actually did have
some degree of kewlness to it (before it went commercial), with its basic
datatypes of HTTP, FTP, MAIL, and the like. I'm not saying we should go
that far, since OOP can simulate this for us, but only that it did have
some kewlness of its own. Base data types don't have to be limited to
strings and numbers... that would be tantamount to C's asciiz being
considered a true string with real strings being "unnecessary". It doesn't
matter to me that these become intrinsic... that's not the purpose of this
post. It does matter that we keep our optinos open and look at Perl6
objectively ("as opposed to subjectively", not "as opposed to
functionally").
p
Re: Larry's Apocalypse 1
"David Whipp" <[EMAIL PROTECTED]> writes: > > One-liners run on a Perl 6 binary should just be Perl 6 code. Do we > > really have to worry about backwards compatibility with one liners? > > > > Hmm... programs that have perl one-liners inside them might be > > troublesome. > > > Why not: > > perl -e 'perl 5 one-liner' > > perl --cmd 'perl 6 one-liner' > > i.e. maintain the "-e" switch as a backward compatibility flag, with a new > cmd line flag for perl 6. One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go the multiflagged way, why not reflect `-e' to get the `-6' flag? At the very least, I want a short flag! -- Ariel Scolnicov
