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.
The relationship between a language and its toolchain, and why Perl 6 scares the hell out of Adam Kennedy
Tags:
1 Comment
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.
Perlbuzz
- Perlbuzz news roundup for 2012-12-03
- Perlbuzz news roundup for 2012-11-26
- Perlbuzz news roundup for 2012-11-19
- Perlbuzz news roundup for 2012-11-12
- Perlbuzz news roundup for 2012-11-05
- Perlbuzz news roundup for 2012-10-29
- vim-perl needs your help
- Perlbuzz news roundup for 2012-10-22
- Perlbuzz news roundup for 2012-10-15
- Perlbuzz news roundup for 2012-10-09
Mechanix
- Low-tech high-speed OS X program launching
- Fixing my #1 bash annoyance
- Handling multiple SSH keys in your SSH config
- Cool vim plugin of the day: surround.vim
- When to use JPEG, when to use PNG
- Git is my hero
- Downloading video with Awk
- Creating Excel files with Perl
- Scrabble cheating with Perl one-liners
- Use Getopt::Long even if you don't think you need to
Contact
- Email andy@petdance.com
- Twitter Perlbuzz
Other Perl Sites
- perl6.org
- Rakudo.org, home of Rakudo Perl 6
- Modern Perl
- Proud To Use Perl
- The official Perl wikis
- News at The Perl Foundation
- use.perl.org
- jobs.perl.org
- Perlcast, the Perl podcast
- Yet Another Perl Game Hacker
Archives
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
These are the same comments that I left at the use.perl.org 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.