[antlr-interest] philosophy about translation

Kay Roepke kroepke at classdump.org
Thu Nov 2 08:49:30 PST 2006


On 2. Nov 2006, at 17:10 , Andy Tripp wrote:

> No, I don't mean "...*dont need* to be an expert", but rather "dont  
> need to know about the layers below". Java is great
> because it doesn't require any knowledge about memory management,  
> for example. The tool should let you
> only be an expert *at one level of abstraction*. I can program in  
> Java without knowing (almost) any details about
> any of the underlying layers.

IMHO the problem with this approach is that people who started out  
with no knowledge about memory management at all, will not get it  
afterwards, most of the time. They've been spoiled. The fact that I  
sometimes would like not having to care about memory management  
doesn't say that I want to have to use it all the time. Sometimes I  
need to be able to specify data locality for performance reasons.  
Java, AFAIK, doesn't allow me to do that, so it's out.
In other words, Java not only doesn't require the knowledge, it  
actively prevents you from gaining that knowledge. To return briefly  
to the distinction of "great" vs. "popular" and what constitutes  
greatness:
Whatever you may think of Perl and Larry Wall, one motto is  
describing this situation perfectly: "Making easy things easy and  
hard things possible."
Java isn't great (for me), because it locks me in. I'd prefer a  
system/language that makes the normal case easy, allows me to be  
sloppy if I wanted to just hack it down to get it working. But at the  
same time it shouldn't get in the way if I want to write very tight  
code - tight in terms of memory usage, code size and runtime  
performance.

> Maybe. From my experience, almost always when someone says "I need  
> to set individual bits by hand,
> so Java isn't a good fit", it turns out that in fact he does not  
> need to set individual bits by hand, and Java will
> work just fine. He just thinks he needs to bit-twiddle because  
> that's how he's used to doing things, and he
> wouldn't even think to just use an array of booleans because he  
> can't make that mental leap.

I shudder at the thought of a bitvector as an array of booleans.  
Sure, if I have an vector of YES/NO information I think of it as  
exactly that, and I might even implement a very quick and dirty  
version that way (if there isn't already a class that handles this  
particular case for me - I'm thinking in OO terms here, but the same  
applies to procedural languages), but eventually I would want to  
optimize it. If you then tell me that the language cannot do it, I  
think I'm justified in saying "What a crappy language is this?". The  
fact that this person thinks he must fiddle with bits is based on  
experience: The array approach is slow and wasteful, whatever the  
language.
I'm no child, I'm a programmer - why prevent me from accessing  
computer specific details from me?

For the record, any Java program I have used has amazed me with a  
huge waste of resources. A comparable C/C++-based implementation has  
in all cases been order of magnitude faster and at the same time  
consumed *a lot* less memory. If have yet to see a snappy Java program.
If the issue is maintenance, mainenance requires discipline, but the  
quality of it isn't limited to any language.

As to what "average" programmers get or don't get, I think that is  
simply an issue of education. If you present stuff in the right way,  
motivate people by relating to stuff they are already familiar with,  
you'd be surprised how much a "dumb average programmer, that is so  
much worse than me"(tm) can learn. To say MI, ASTs, operator  
overloading et al, are out of reach of the majority of programmers,  
is in my opinion just one thing: arrogant. (This is not meant to  
insult anyone, please don't get me wrong!)
Sorry for the outburst, but I always get sort of angry when I hear/ 
read something like this, because it implies a certain "screw them"- 
attitude.

Anyway, if you think it possible to build a product that handles all  
the AST mucking behind the scenes, allowing you to specify rules to  
reliably translate source-to-source, then by all means do it. If it  
uses ANTLR behind the scenes, congratulations! In essence, if you've  
got an idea, pursue it. Great things have always come from those  
ideas and computers are built for exactly this purpose:

"Making easy things easy and hard things possible."

cheers,
-k





More information about the antlr-interest mailing list