[antlr-interest] A postmortem of my use of antler

[Andy Tripp]

Richard Clark wrote:
> On Tue, Mar 11, 2008 at 10:42 AM, Andy Tripp <antlr at jazillian.com> wrote:
>
>   
>>  I don't think that getting a 10-line ANTLR grammar working should be
>>  much more difficult than getting a 10-line Java/C/whatever program working.
>>     
>
> To disagree with you (gently), someone who cut their teeth on LISP
> will probably have a hard time with their first 10-line
> Java/C/Ruby/etc. program (and vice versa). There's a whole different
> way of thinking involved.
>   
Someone writing their first 10-line program in a language that's new to 
them will almost
surely not be relying on their knowledge of some other language that 
they know. Instead,
they'll probably be typing in a simple (Hello, world) program from a 
textbook or
from their notes in a class, or from some documentation.

When it comes to "getting it working", it's all about the quality of the 
error messages.
Javac's messages are great...probably something like "missing semicolon" 
with a little
arrow showing where the problem is.
>   
>>  How many times do we see people ask "why isn't this 10-line grammar
>>  working?" or "how do I print out an AST nicely?"
>>     
>
> These kinds of questions are parts of the learning process, not
> necessarily de facto evidence of a problem with ANTLR. Where we can
> help is identifying common misperceptions about ANTLR and describing
> those parts in the correct way (e.g. how to think about structuring
> your lexer definitions) and defining key ideas in a way that people
> can become more self-sufficient with the documentation.
>   
Look at, say, the development team for javac. You've got dozens of 
people working for
over a decade on it, with only part of the work being on the "hard 
stuff" - the parsing and
bytecode generation. There are also people working, full time for years, 
on making it
"user friendly". ANTLR doesn't have that. Obviously, Terence isn't 
superhuman and can't
do it all. But unless you've got someone doing that work, ANTLR will not 
be as user-friendly
as it could be.
> I would not, as has been suggested, try to lay a simpler face on
> ANTLR. The tool is designed very cleanly and simply; there's a clear
> connection between when you write in the grammar and what you get from
> ANTLR (assuming your mental model of the app is correct.) Putting a
> "simplifying" layer on top can introduce assumptions that actually
> make the result harder to understand and work with.
>   
Again comparing to, say, javac: There's a clear connection and mental 
model there, too:
you put in valid Java syntax and get out a working program. There is 
*no* bytecode in the
mental model. By contrast, with ANTLR, you start off expecting to 
provide a valid grammar
as input and a working lexer/parser as output - that's the mental model 
you want. What you
actually often get as output is generated code for a grammar which you 
must look at and understand
in order to get your working parser.

I realize having ANTLR generate readable code is better than not (see 
lex and yacc). My point is
that I think ANTLR could be made easier to use, to the point where you 
really don't need to
understand the generated code. Sounds impossible, I know, but it's 
possible to write Java
without understanding bytecode. I don't picture an additional 
"simplifying layer", just many years
of hard "usability" work with real users working on real problems.
> The hardest part of writing good conceptual documentation is to make
> sure it's absolutely correct. I'm happy to draft it, if I can get
> reviewers who really know ANTLR all the way through (Kay, Ter, etc.)
>   
I prefer documentation that's not conceptual, but rather concrete. I 
also prefer documentation
that's understandable over documentation that's absolutely correct. But 
hey, that's just me I guess.
> ...Richard
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20080311/b46b664d/attachment.html