[antlr-interest] philosophy about translation

[Andy Tripp]

Kay Roepke wrote:

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

Right, just as the car driver is spoiled by not having to know how the 
car works....i.e. "spoiled" is a good thing here.

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

And you can tinker under your car's hood all you want, no problem.
The main point is that the automatic transmission is a good design, 
because it hides the user from the underlying
"gears" layer. At home, I prefer to drive a stick because it's fun. But 
at work, I don't prefer to see bytecode, because
I don't find that fun.

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

If you're talking about the C "register" keyword, C and C++ don't 
usually allow you to do that anymore either :)
Most modern C and C++ compilers ignore the "register" keyword, or so 
I've heard.

> In other words, Java not only doesn't require the knowledge, it  
> actively prevents you from gaining that knowledge. 

Yes, just as the automatic transmission prevents you from even knowing 
how many gears your car has.
That's not a big issue with cars, as most people can shift as well as an 
automatic.
But with programming languages it's important, because most of the time,
when people access those underlying layers (doing their own memory 
management, guessing which
variables should be "register", etc), they don't do it as well as the 
machine.

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

Just stick with Java long enough to "get it". I went through several 
weeks of trying to "really get" OO, and it was tough going.
After a couple of months, I was as comfortable with Java as with C/C++. 
After a year or so, I felt that
I was several times more productive in Java, and there was no turning back.

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

That's a great example. You make the assumption that an array of 
booleans is somehow going to be slower or use more memory
than a bitvector. You've got to let that old thinking go, Luke! You 
worry about your application and pick the appropriate
data structure for it. Let the compiler and runtime be smart about 
performance and memory management. It is better at
those things than you are (and certainly better than you think it is).

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

Just write yourself a 10-line benchmark and run it. Be sure to subtract 
out the JVM startup and class loading time
(assuming you're doing server-side work and don't care about the few 
seconds of startup time). Just be careful
because if your benchmark isn't complicated enough, the JIT will 
optimize all your code away :)

> 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!)

I sure wasn't saying that those are "out of reach" - I was saying that 
they're misused more often than not.

> 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

Thanks!
Andy

>
>
>