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
