Comments on: What’s on your Stack? http://www.clevegibbon.com/wordpress/2008/03/11/whats-on-your-stack/ Stuff you pick up on the way... Thu, 02 Jul 2009 15:03:28 +0200 http://wordpress.org/?v=2.8 hourly 1 By: yunta http://www.clevegibbon.com/wordpress/2008/03/11/whats-on-your-stack/comment-page-1/#comment-163 yunta Thu, 20 Mar 2008 15:19:14 +0000 http://www.clevegibbon.com/wordpress/archives/91#comment-163 Those tools (parsers generators) really suck.... They are all written with old mindset: that things should work fast. Unix history proved that correct order of development stages is (after "the art of unix programming"): 1. Make it work 2. Make it right 3. Make it fast Applications rarely get to 3rd stage, and if they do - it's because stage 2 was a failure :) I want to work fast with my tools. If I have to wait 2 minutes more just to get more meaningful error message - it's ok. Because I would waste more time on interpretation of less intelligent message. I used to work with yacc-like parser generator for ruby (racc). As yacc it handles LR grammars. 70% of its error messages require me to imagine entire parsing process, to check for ambiguities or other inconsistencies. And that is a terribly difficult task comparing to everyday rails challenges. I believe it's just impossible for usual java-slave-worker. It's much better with ANTLR. It has nice GUI where you can see ambiguous parsing paths on graphs. But it's LL, so it's somehow... limited. I dream about real GLR parser generator with GUI like antlrs. Generator that can handle ambiguities. Not necessarily fast. Currently, when I'm about to write DSL - I prefer to play with ruby, like this: http://yunta.dainet.pl/programming/ruby-as-configuration-language/ But I still believe it is possible to write parser generator with grammars easier to build than internal DSL with ruby. Those tools (parsers generators) really suck….
They are all written with old mindset: that things should work fast.
Unix history proved that correct order of development stages is (after “the art of unix programming”):
1. Make it work
2. Make it right
3. Make it fast
Applications rarely get to 3rd stage, and if they do – it’s because stage 2 was a failure :)
I want to work fast with my tools. If I have to wait 2 minutes more just to get more meaningful
error message – it’s ok. Because I would waste more time on interpretation of less intelligent message.
I used to work with yacc-like parser generator for ruby (racc).
As yacc it handles LR grammars.
70% of its error messages require me to imagine entire parsing process, to check for ambiguities or other inconsistencies.
And that is a terribly difficult task comparing to everyday rails challenges.
I believe it’s just impossible for usual java-slave-worker.
It’s much better with ANTLR. It has nice GUI where you can see ambiguous parsing paths on graphs.
But it’s LL, so it’s somehow… limited.
I dream about real GLR parser generator with GUI like antlrs.
Generator that can handle ambiguities. Not necessarily fast.

Currently, when I’m about to write DSL – I prefer to play with ruby, like this:
http://yunta.dainet.pl/programming/ruby-as-configuration-language/

But I still believe it is possible to write parser generator with grammars easier to build than internal DSL with ruby.

]]>