What’s on your Stack?
Yesterday I attended a talk on DSLs and towards the end of it we started looking at external DSLs. I’m going to skip over that topic for now, but as a result tutorial headed by Rebecca Parsons moved into the area of lexers, grammars, parsers, language design and a little bit of compiler theory. Good stuff.
What became abundantly clear to me is that although the room was jammed packed full of smart people, only about half of us knew what lexers and grammars were. This got me thinking about assumed knowledge. I’d also assumed that the majority of application developers knew at least Java or .NET. Not so. There were a lot of attendees that were pure Ruby, Perl or another.
Looking back, my language stack consists of 5 years of assembler/C, 10 years of C++, and 10 years of Java, where there was gradual hand-over from one language to the next. On the way, I dabbled in Smalltalk, Eiffel, ML, Prolog, and more seriously in .NET and Ruby. The very nature of the language meant that I needed to know about compilers and language design. Also, as part of my thesis I had to swallow context free grammars and chomsky, to write a header file parser that performed the static design analysis of large C++ systems. But the only reason I did this is because I had to, and the tools available to me then were yacc(grammar)/lex(lexical analysis).
Now, if you don’t use these types of languages and parse very simple grammars, there is no need to get your hands dirty. However, Rebecca was spot on when she pointed out that tools such as yacc/lex and to a lesser degree antlr, have received bad press as being archaic, blunt tools with magical powers that are wielded by the chosen few. In reality, there hasn’t been much cause for the masses to use them. Will the drive for external DSLs where you want to create your own language make them more popular? I doubt it. I think people will still opt for internal DSLs that are written essentially in the host language (e.g. rSpec, JMock, and so on).
But I have to realise now that those guys/gals born in the eighties and heaven forbid the nineties, are operating off a completely different programming stack. Their minds are in different places and their toolset is somewhat orthogonal to mine.
Strange. I suddenly got older very fast…
Technorati Tags: dsl
March 20th, 2008 at 4:19 pm
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.