The relationship between a language and its toolchain, and why Perl 6 scares the hell out of Adam Kennedy

| 1 Comment

Adam Kennedy has written a very thoughtful article on problems he sees coming up in Perl 6 called "The relationship between a language and its toolchain, and why Perl 6 scares the hell out of me." It's well worth reading even if you're not following Perl 6 that much.

1 Comment

These are the same comments that I left at the journal entry - I apologize for posting them twice - I just think the "Perl 6 modifyable grammars === Perl 5" is an alarmist reaction. These comments based on the article in question and are phrased as a response to it...

I'm afraid that I can't restate your concern without putting words in your mouth - so I won't try. So I will look at this from my own perspective.

I think it would be great to be able to have parsers/editors/refactor-ers that can "statically" (whatever that means) analyze Perl 6 code and do neat(tm) things with the output. I will write the majority of my Perl 6+ code in the standard grammar using the future best practices for doing so because I think there will be great tools that will give great insight into my code. And I think that the standard grammar will make it much easier to do (much more easy than what Perl 5 gave which was nearly nothing). I see no reason why there can't be a standard PPI6 - it is just the standard grammar. Done.

When time permits, or the problem requires it, or when I get bored I may try to modify the grammar to fit my need. Why would I ever assume that if I was writing a grammar modification - that some stock code analyzer would be able to read code written in my new grammar. That would be a foolish assumption to make. It would also be an error on my part to require that it must be able to parse my new dialect.

Now - I assume that there will be those who will write nifty changes to the grammar. I don't know that they will, but I have every reason to assume that somebody will make a useful module that overrides the stock grammar. Why would I now assume that the stock code analyzer would be able to parse this new dialect. Again - it would be a foolish assumption to make. Again - it would be an error to require that the stock analyzer be able to parse the code. But in this case, if they have written a nifty extension to the grammar and it saw sufficient uptake and was widely popular, I would assume that somebody would write a plugin to the stock analyzer that would let the extended grammar parse just as well. And if not, and it was important to me, then i'd try and figure out how to do so. And if the tools aren't capable of being extended, well, then I'd seek out new tools.

I don't mean to be argumentative, but I think the picture painted is far worse than what you have presented. Here's where I put words in your mouth ... you want "easy to parse," "standardized," "refactorable," syntax and you are scared that somebody will extend the grammar, so we shouldn't be able to extend the grammar. Well, all of that request will be available, except for the "shouldn't be able to" part. That part is replaced with "most of the time people won't, but sometimes they will, and if they do, then maybe it isn't all bad for them to."

I think in the rare cases, this will be the fusion powered ultra mega swiss-army chainsaw of death that will make it possible to do the impossible job. Maybe even make it easy. And I won't care if I have to edit the code without the help of a stock analyzer. But most of the time I'll settle for using the ultra swiss-army chainsaw that is called Perl 6 - and will love using PPI6 enabled tools to do so.

Leave a comment

Job hunting for programmers

Land the Tech Job You Love, Andy Lester's guide to job hunting for programmers and other technical professionals, is available in PDF, ePub and .mobi formats, all DRM-free, as well as good old-fashioned paper.