develooper Front page | perl.bootstrap | Postings from July 2000

Re: Working Group Proposal

John Porter
July 20, 2000 13:04
Re: Working Group Proposal
Message ID:
Bennett Todd:
> John Porter:
> > Bennett Todd:
> > > Has Python indulged in non-backwards compat more than Perl? 
> > 
> > No; but it is considerably more recent, [...]
> That's an advantage and a disadvantage. The disadvantage was that it
> means they are forever playing catch-up, unless they can seriously
> expand their working tools base faster than we can grow CPAN --- or
> unless we decide to toss CPAN and start over from scratch.

Or another possibility: the world loses interest in Perl because
it is incapable of remaining current and relevant.  Then CPAN
stops growing, and Python (or whatever) overtakes Perl with ease.

> > [...] and was also more carefully designed from the outset.
> That I disagree with utterly. 

Perhaps the design of Perl was careful up through v. 3 or 4;
but since then it has grown in a rather ad hoc way.
And "carefulness" aside, the design can not be considered
"clean" but by some stretch of the imagination.

> There's actually a language out there that has that edgy
> computer-science purity of bodily fluids, while enjoying a
> surprising amount of perl's expressiveness (it appeals to me better
> than Python that way, at any rate), and that's Ruby.

Sure, Ruby's nicer than Python (from a Perlist's perspective,
at least); but Ruby has problems of its own.  At any rate, if
it was wise of lwall to steal the tasty bits from Python to make
Perl better, we can do the same wrt Ruby/Perl6.  That is, if
there are any tasty bits to be stolen...

> If backwards compat is so broken that it makes it a bad choice to
> write the first implementations of perl6 in perl5 ...

Faulty premise.  We're talking about writing perl6 (the machine)
in Perl5 (the language).  Compatibility is not an issue here.

> then the gap is too big to hope for much
> backwards compat, much salvaging of our accumulated work from CPAN.
> Lose CPAN and we're just another competitor in a very populous
> field. Perl defined that field, it'd be a shame for us to step to
> the back of the line.

Perl6 doesn't make Perl5 disappear.

> > First and foremost, the proverb that "nothing can parse Perl
> > except perl" must be rendered null and void.
> Why? If you want easy-to-parse, there are a lot of languages out
> there for that. 

People want to have their cake and eat it too; and Perl has
encouraged them by delivering this in ways other languages
never did.  Can you fault the editor writer for wanting to
include *accurate* perl syntax highlighting?

> However, as far as I know, the very essential nature of
> perl that distinguishes it from all other languages,
> its basis in allowing diverse expressions of various
> natural-language-inspired idioms, is not compatible with
> easy-to-parse-with-table-driven-BNF-defined-parser. 
> I've yet to hear someone offer an approach to making a toy parser,
> the kind that computer science researchers love, parse a language
> that offers the comfortable expressiveness that distinguishes perl.

You overstate my position.  I don't want context-free; I
love Perl's context-sensitive nature.  But it should be
easy enough to parse that other parsers could be written
without too much trouble.  As it stands now, it's IMPOSSIBLE.

John Porter

	Aus tiefem Traum bin ich erwacht. Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About