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

Re: Working Group Proposal

Bennett Todd
July 20, 2000 15:01
Re: Working Group Proposal
Message ID:
(NB: I don't necessarily agree with all the statements that I'm not
rebutting, I'm just trying to cut off where I don't think I've got
anything substantive to add).

2000-07-20-16:04:23 John Porter:
> Bennett Todd:
> > > [...] 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.

I think the vast majority of the big stuff that came in with perl5
has proven itself to be brilliant; the harmonious additions of
dynamic loading of extensions, gracefully tied to O-O namespace
mgmt, have worked; CPAN's success is the proof in the pudding.

> And "carefulness" aside, the design can not be considered
> "clean" but by some stretch of the imagination.

Design comes in two parts; there's the design of what features are
offered, and then there's the design of how they're implemented. I
don't see a lot of bathwater accompanying the baby in perl's
language design; while there are vestigial bits here and there, I
don't see anything that I'd like to see squashed so badly that I'm
willing to lose most backwards compatibility to do it.

The design of the implementation may be long in the tooth, and it
could be that we'll be able to achieve more dramatic improvements
there. I'd sure be less worried about trying to radically overhaul
what's under the hood, than trying to completely redesign the
visible language.

And unless the visible language is fairly radically redesigned,
writing perl6 in perl5 would make it much, much easier to solve the
bootstrapping problem --- i.e. the perl6 implementation would remain
pure perl5 until perl6 was able to bootstrap itself --- and provide
us a nice touchstone for backwards compatibility.

> > 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.

You're right, I had it backwards. If e.g. perl6 added features that
made it easier to write perl6, that could make a case for doing the
bootstrap the hard way without necessarily implying that perl6
couldn't retain reasonable backwards compatibility with perl5. But
I'm at a loss for what such features could be.

> Perl6 doesn't make Perl5 disappear.

Here's a very important matter: while perl6 doesn't make perl5
disappear, it _does_, if I understand matters correctly, gravely
threaten perl5.7; not only by dividing the development effort onto
two fronts, but by creating a substantial incentive to avoid having
perl5 be a moving target. Anything else I can imagine would be
shaping things for a schism.

> > 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.

You're right, I did, my apologies; I shouldn't have done that, it's
the nastiest sort of flame-baiting. What happened was I got so
caught up in trying to find a way to express myself that I wandered
off and started replying to things that I thought were implications
of what you were saying. I was wrong. I'm sorry.

-Bennett Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About