[antlr-interest] philosophy about translation

[Andy Tripp]

Anthony W. Youngman wrote:

> In message <452D3180.2070907 at jazillian.com>, Andy Tripp 
> <antlr at jazillian.com> writes
>
>>> "Thinking in trees" does not come automatically.  It is like 
>>> learning LISP or Forth or one of the functional languages (and, for 
>>> that matter, object-oriented programming:  there is a lot of badly 
>>> designed and implemented C++ code out there).  For a time, working 
>>> with trees is like slogging through molasses, and then you get the 
>>> "Aha!" experience and things become easy.  It usually is not about 
>>> designing the perfect tree structure; instead, it is about 
>>> simplifying the recognition problem and expressing target language 
>>> constructs in tree  form.
>>
>>
>> For the record, I had no trouble "getting" LISP when I learned it 25 
>> years ago. When I started with C++, I don't think I
>> really "got" OOD, and only started writing real OO code when learning 
>> Java forced me to. I think the fact that LISP never
>> became "mainstream" means that it failed to be easy enough to grasp. 
>> Regardless of how inherently beautiful it is,
>> if a lot of programmers don't easily "get it", then it's not that great.
>
>
> The trouble is, the "average" programmer is just that, average.
>
> A great programmer can do the work of ten ordinary programmers. The 
> trouble is, he probably does it with tools that are beyond the ability 
> of the ordinary programmer to "get".

Just to be clear, I'm not saying I'm an "average" programmer or looking 
for tools for the "average" programmer.
I might be in the top 2% of all programmers, but I'm not in the top 0.1% 
of language-tools-gurus as Terence is.
So I want tools that helps us good-programmers-but-not-compiler-gurus 
build stuff.
I'm not a Terence looking to automate my parser-creation task;
I'm just an Andy looking to build a language translator while barely 
knowing the difference between LL(*) and LL(k).

Just as a compiler lets the programmer focus 100% on the problem at hand 
(application logic) and 0% on
the underlying level (creation of object or byte code), ANTLR lets me 
focus on the problem at hand
(lexing and parsing) and not the underlying level (creation of 
lexing/parsing code). Unfortunately, I
don't think there's one really good tool for hiding the whole "language 
translation" level. ANTLR treewalking
combined with StringTemplate attempts to do that, but falls short in two 
ways, I think. First, ANTRL treewalking
requires perfect knowledge of the input language structure. And second, 
I don't think treewalking is the better
way to slice the problem, as the problem scales up. In other words, when 
you have a ton on translation logic,
"Here are each of the translation rules I'd like to apply" is a better 
way to approach it than
"Here is what to do at each node of the input structure tree".