[antlr-interest] philosophy about translation

Andy Tripp antlr at jazillian.com
Tue Oct 31 06:29:20 PST 2006


Micheal J wrote:

> [snip]
>
>Many would argue that Java is a limited implementation of OO principles as
>pioneered in LISP et al and later Smalltalk. Everything inherits from
>System.Object is plain ugly and, no multiple inheritance?. AOD (AspectJ and
>cousins) can be viewed as a series of hacks to try and simulate some of the
>important OO bits that were thrown out to make Java.
>  
>
I view Java's decision to do a "limited implementation" by avoiding 
things like multiple inheritance
as exactly what made it successful. By avoiding being "completely pure", 
Java is accessible
to average programmers. And that's why Java is popular and Smalltalk and 
LISP are not.
It's also why people prefer Java over C++.

>So, I'm tending to agree with Anthony here. Great tools often require
>in-depth domain expertise that the majority simply don't have.
>  
>
Sometimes they do, but sometimes they don't. Compilers never require 
in-depth
domain expertise. I know almost nothing about byte-code generation, yet 
I use javac
every minute or two. I think the world would benefit from an ANTLR tool 
that was like that.

>  
>
>>>You say you're probably in "the top 2% of programmers". In other
>>>words, if you think a tool "is great", the chances are that 
>>>      
>>>
>>a lot (the 
>>    
>>
>>>majority?) of programmers WON'T easily get it - in fact - 
>>>      
>>>
>>quite likely 
>>    
>>
>>>- CAN'T "get it" AT ALL!
>>>      
>>>
>>I think a tool can be great while being simple enough for most 
>>programmers (e.g. Java).
>>    
>>
>
>Not without limiting it's power.
>  
>
Yes, just as Java's power is "limited" by not supporting MI, pointers, etc.
I love to have my power "limited" by not giving me lots of rope to hang 
myself with.
And so do most people, judging by the popularity of Java over C++ and 
every high-level
language over assembly.

>  
>
>>>So don't dismiss tools because they're hard to grasp. My brother
>>>thought Emacs was a user-friendly disaster-area until he 
>>>      
>>>
>>really needed 
>>    
>>
>>>a power-editor. Then he realised how friendly it really was ...
>>>      
>>>
>>I'm not dismissing anything - just griping :)
>>
>>I think Terence could make a huge leap forward by not thinking about 
>>ANTLR as "a tool to automate what
>>a guru would have written by hand", but rather "a tool that hides all 
>>the details of language manipulation, so that
>>most any programmer can do it".
>>    
>>
>
>Don't think so. My point about domain expertise is relevant here. Joe
>Average just can't start developing language recognition tools with an
>appreciation of the theory that underlies that subject area.
>  
>
Sure he could. Joe average could easily write:
a + b --> a.add(b)
and have his tool do the rest (and maybe warn him about cases that might 
match that he hadn't
thought about).

I've had a programmer working with me for a few months now, and he's had 
no trouble writing
translation rules without every learning ANTLR grammar or knowing 
anything about language
recognition tools.

>  
>
>>Most programmers use a 
>>compiler without 
>>ever knowing much more than
>>"it generates some lower-level code from my code". Similarly, 
>>it would 
>>be nice if most programmers working on
>>language transformation could use ANTLR without knowing much 
>>more than 
>>"it generates a lexer/parser from
>>my grammar".
>>    
>>
>
>The analogy isn't quite apples-to-apples. Programmers using a compiler [for
>a programming language like C/C++] have to understand the syntax and
>semantics of the language the compiler recognises. Plus the rules for using
>other related tools such as linkers, loaders etc. True, an IDE and the OS
>can hide much of that these days but they still exist. 
>
>Similarly with ANTLR. ANTLR users have to understand the syntax and
>semantics of the grammars they develop. ANTLR projects involve *two*
>languages - ANTLR's grammar language and a general purpose programming
>language such as Java/C/C#/ObjC etc.
>
>Beyond that, it's the same user experience: "I feed in some code and this
>tool (compiler or ANTLR) generates a whole lotta stuff I don't need to
>understand".
>  
>
No, there's a real difference. Yes, you have to know java syntax and 
semantics to use javac.
And you have to know ANTLR syntax and symantics to use ANTLR. But with 
ANTLR, it's
not enough to know the syntax and semantics of ANTLR. To do anything 
useful, you almost
always have to know something about the internals of what ANTLR is 
doing. I find that I
often have to look at the generated code to figure out what went wrong 
or how to do what
I want to do. I *never* have to look at java byte code - I'm completely 
hidden from that
by the design of the compiler.

>Micheal
>
>  
>



More information about the antlr-interest mailing list