[antlr-interest] philosophy about translation

[Micheal J]

Hi,

> Anthony W. Youngman wrote:
> 
> >
> > I think you've missed my point :-) "Regardless of how inherently
> > beautiful it is, if a lot of programmers don't easily "get 
> it", then 
> > it's not that great."
> >
> > If it really *is* great, then the chances are the majority of
> > programmers *can't* 'easily "get it" '.
> 
> I disagree. Object Oriented Design is, and always was, great, for 
> example. Yet it languished in Smalltalk80 for all those 
> years, and didn't even really catch on completely with C++, 
> and only became mainstream 
> with Java. I myself didn't really "get" OO,
> even using C++, until Java came along. It took a mix of a great idea 
> *and* a good implementation for OO to become mainstream.

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.

So, I'm tending to agree with Anthony here. Great tools often require
in-depth domain expertise that the majority simply don't have.

> > 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.

> > 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.

> 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".

Micheal