Front page | perl.bootstrap |
Postings from July 2000
2000-07-20-15:00:13 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. The advantage is of course that they got to take a fresh look at language design. However, that edge didn't buy 'em that much, since lwall promptly swiped all the tasty bits and stuffed 'em into perl5:-). > [...] and was also more carefully designed from the outset. That I disagree with utterly. It was designed in a different fashion, by a designer with a very very different style. Perl has enjoyed the most exquisitely careful and expert design from the very beginning. It just wasn't design by an academic computer-science purist, is all. That's where its lovely fluid expressiveness comes from. 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. > The resemblance could be close enough that converting a perl5 > program to a perl6 program could be a trivial, or automatable, > task. But I believe that this is a good opportunity for things > that are broken to get fixed -- and if bw-compat is lost > sometimes, so be it. If backwards compat is so broken that it makes it a bad choice to write the first implementations of perl6 in perl5 --- more precisely, in the dialect and style that lies in the intersection of the two languages --- 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. > > What sucks, that requires completely breaking any hope of > > backwards compatibility to fix? > > 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. The winner and champion has of course to be scheme or one of the other lispoids, but there are plenty of more conventional-looking choices as well. 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. Failing to be a trivial yacc hack doesn't necessarily qualify as a problem that requires fixing. If it _did_ require fixing, then the next question would be, why not just jump ship and join the Ruby camp. That's the cleanest, handsomest effort I've seen to render a language that works like Perl on a more classical CS foundation. > This, I presume, would entail changes to the grammar that would > likely have the effect of breaking bw-compat. Well, if it made it a better language to program in, then at least I'd be interesting in hearing more about what you have in mind, but 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. -BennettThread Previous | Thread Next