[antlr-interest] philosophy about translation

Anthony W. Youngman antlr at thewolery.demon.co.uk
Thu Nov 2 01:21:32 PST 2006


In message <45496671.9010008 at jazillian.com>, Andy Tripp 
<antlr at jazillian.com> writes
>Anthony W. Youngman wrote:
>
>> In message <4548F943.7070906 at jazillian.com>, Andy Tripp 
>><antlr at jazillian.com> writ
>> I wouldn't describe "popular" as "great".
>
>I would say popularity is a pretty good indicator or "greatness". By 
>"popular", I mean "widely seen
>as good from a technology point of view". So Java is "popular" that 
>way: a lot of people use it
>because of its technical merits. COBOL is widely used, but almost no 
>one uses it because of its
>technical merits.

Actually, I think you'll find that COBOL has technical merits that the 
average programmer has been brainwashed into ignoring. COBOL does what 
it was designed for very well. I've written an accounts package in 
FORTRAN. I've also written one in DATABASIC (which pinched a lot of 
ideas from COBOL). No question as to which one was the right tool for 
the job ...

And I've also used a version of DATABASIC where some bright spark 
rewrote the system primitives in C. Blech!!!! the number of times I've 
seen people scream because they got bitten by subtle bugs ...

Come to think of it, how many people get bitten by subtle bugs in Java 
because they don't understand that, underneath, it's written in C++? As 
someone said, not many, because it's been well tested, but that's still 
a few too many ...
>
>>> Yes, a few people want to add stuff back, but most do not. It's just 
>>>that the few are very vocal.
>>> The vast majority don't want MI, operator overloading, or built-in 
>>>AspectOrientedDesign.
>>> And of course, those who want them think they're "above average", 
>>>but  then so does almost
>>> everyone.
>>>
>> What about those who don't WANT those things, but NEED them?
>
>Every time I've heard anyone say they NEED MI, operator overloading, or 
>Aspects, I've thought
>that they really don't need them, they're just not good enough 
>programmers to see a clean way
>to do without them. I've been programming for 25 years without ever 
>NEEDING any of these,
>and so have most other programmers.
>
I programmed for many years without needing pointers. FORTRAN didn't 
have them, so I tended not to use them in C. I notice you said *MOST* 
other programmers. You're jumping to conclusions - because "all the 
programmers I know are too stupid to live without these features" you 
conclude that these features "mostly aren't needed". So you'd like to 
see them removed from any tool you use ... :-(
>>
>>>
>> So - you're quite happy to see Antlr crippled to suit you, ignoring 
>>the NEEDS of those who need its power!
>
>Don't worry, I can't cripple ANTLR.  But yes, I'd be happy to see 
>ANTLR4 become a "crippled" version,
>in the same sense that Java is a "crippled" version of C++.
>
And as I said, you're quite happy to ruin the tool for all those people 
who need that power ...
>>>>
>>>>
>>> But required knowledge of the tool's internals limits the "average" 
>>>user's productivity.
>>> If I had done AST-based translation, I'd be spending way to much 
>>>time worrying about the details
>>> of the AST, rather than the syntax and semantics of the two 
>>>languages. I demand to spend 95% of
>>> my time on *what* to do, rather than *how* to do it. With ASTs, I 
>>>found myself spending
>>> 95% of my time on *how*.
>>>
>> In other words, as you said earlier, ASTs are the wrong tool for you. 
>>So you seem happy to delete ASTs from Antlr because *you* don't need 
>>them, irregardless of what other people *NEED*.
>
>Yes, just as I railed against operator overloading and MI in C++, and 
>found bliss in Java.
>I don't much care that other people think they *NEED* MI. They can 
>always stick with C++.
>
Or you could find some other language instead of Java? You'd much rather 
inconvenience all the other Java programmers by removing features they 
need, rather than convenience yourself by finding something that suits 
you better?
>>>>
>
>> Let's ask a question ... how can a tool be "great" if it *relies* on 
>>other tools even for its existence?
>
>Sure, of course! Virtually all software relies on other tools 
>(compilers, operating systems, etc) for their existence.
>
>>
>> A C compiler can compile itself. Can a Java system build itself? How 
>>much of Java is actually written in Java? (Oh and I'm including the 
>>supporting libraries here!)
>
>Almost all of Java is written in Java. The only part that's not is the 
>lowest layer, which is OS and hardware specific.
>
Assembler is written in assembler, pretty much without exception. C is 
written in C, pretty much without exception.

The reason for demanding that a great tool be written in itself is 
exemplified by my databasic example above - the primitives for the 
version I initially used were written in machine code, and followed the 
spec. The C rewrite introduced loads of subtle bugs, because the 
characteristics of the C environment were different. How much of Java 
DEPENDS on the lowest layer? How much knowledge do you need to 
understand that layer?
>>
>> Antlr v3 is due to be rewritten in Antlr v3. To my mind, that's a 
>>"necessary but not sufficient" condition for greatness.
>
>Wow. Only software that's written in itself can be "great"? Are you 
>really saying that?
>
Yes I am. Because otherwise it requires you to understand much more than 
you want about the execution environment. Note my comments about subtle 
bugs. Because it requires the system guys to be *experts* in two 
completely different environments!

I note that you think a "great tool" is one that means you *don't* 
*need* to be an expert. By your logic, Java therefore has to be a crap 
tool for Java system programmers ...

Which is why, in the system I want to build with Antlr, it's very 
important to me that AS MUCH AS POSSIBLE of the system is built using 
DATABASIC, because that's what the programmers using it will have 
experience in. *THAT* is why a great tool must be built using itself.
>>>>
>>
>> But what if the problem can only be specified in terms of formal 
>>language theory?
>
>Then you'd have a different situation. But surely you're not saying 
>that a language-to-language translator
>can only be specified in terms of formal language theory, are you?
>
>> There is something called "intelligence". If you don't have 
>>sufficient intelligence, you *cannot* learn certain things. You want 
>>to give a programmer a tool, so you can set him a problem he is 
>>INCAPABLE of comprehending. I hope I never have to rely on (or even 
>>USE) code written by a coder like that !!!
>
>Well, virtually every coder in the world is like that. Only a handful 
>of people in the world know the details of what their
>compiler is doing as they use it every day. Same goes for the OS and 
>the hardware. Same goes for  the car you drive
>and just about everything other non-trivial machine you use: you use it 
>without knowing much about how it works.
>That's what makes the world go round :)
>
You miss the point. Let's take the car example. There's a big difference 
between what I wrote and you responded to. As far as I can see, you're 
saying that if a guy has a driving licence, you're quite happy to get 
him to repair your car brakes ... WHAT...!!!

You do not give a problem to someone to solve, if they do not have the 
mental capacity to understand the problem. You do not ask a guy to 
repair the brakes on your car if he has no experience of being a 
mechanic, even if he does have a driving licence (and there's a lot of 
people I would hate to have service my car, even if they do have a 
mechanics qualification, because they learnt to follow the diagrams in 
the book and didn't learn to work through what was *actually* 
*happening*!).
>>>
>> And then the programmer needs a pointer to write to a bit of 
>>hardware, and throws Java out in disgust because his "great" tool is 
>>useless for the job at hand ...
>
>Right. And probably gets fired if his boss finds out that he's trying 
>to write a bit directly to hardware.
>He thinks he needs to do that, and he thinks he's smart, but he's not. 
>That's pretty rare these days to
>have anyone feel that they need direct access to the hardware. We're 
>many levels beyond that now.
>
Given the ability of many bosses, I bet the boss gave him the job, and 
told him to use the wrong tool ...
>>
>> Because javac is meant to convert java source accurately to java 
>>bytecode. While Antlr is meant to (and does) accurately convert its 
>>sourcecode into a lexer/parser/treewalker, it is also designed to let 
>>do things beyond the power of the tool. Both fit their design aims  - 
>>javac creates a java program, Antlr creates an extensible 
>>lexer/parser/treewalker. Both are *good* tools, that doesn't 
>>necessarily mean they are *great* tools.
>>
>> At the end of the day, I think your definition of "great" is badly 
>>flawed - "a great tool lets a mediocre programmer do a decent job". A 
>>great programmer could probably outperform that mediocre programmer 
>>without that tool.
>
>Heh, it's been a while since I heard the "A great programmer can write 
>better code than the compiler" line.
>Used to hear that a lot 20 years ago, not much any more.

I gather the statistics still hold true. The best programmers still 
outperform the average ones by about 1000% ... that's a MASSIVE 
difference.
>
>>
>> The greater the tool, the greater the level of maturity required to 
>>be able to use it safely.
>
>If you want to use that meaning for "great", that's fine. But I do 
>disagree. If you had one space shuttle
>that was completely safe and automated, that would be a "greater" tool 
>than one that requires maturity, IMO.
>Especially if you have millions of shuttle pilots, and not just a few.

You've obviously not read Dick Feynmann then ... :-) even *I* could fly 
the space shuttle :-)

Hint - in a former life, the Shuttle's pilot was known as "George" :-)
>
>> And the fewer the number of programmers who are capable of reaching 
>>that level of maturity ... you go on about the "dangerous features" of 
>>C++ as opposed to Java. A mature C++ programmer would NOT USE those 
>>features if they weren't needed. Indeed, a mature C++ programmer would 
>>probably use Java if those features weren't needed.
>
>Haven't heard that one in a while either. Yes, yes, I know, it's not 
>C++ that's dangerous, it's just those *other* guys
>who are bad programmers and are misusing it. And we Java fans are just 
>not manly enough to handle
>MI and operator overloading.
>
>>
>>
>> Too many programmers use features like kids eat candy - the more the 
>>better! A great programmer likes a tool like a candy shop - but he has 
>>the self control to only take what he needs - not the entire shop!
>
>Yea, yea, heard it all before. It's all those *other*, less-intelligent 
>programmers that are using operator overloading
>to apply the "+" operator to the "Person" class. We smart programmers 
>know that we *NEED* operator overloading
>for our matrix multiplication. Bleh. :)
>
Fine. Since Java is such a great language, let's see you write the BIOS 
for all new computers in it ... what? you mean all new computers will be 
bricks if you do? What a crap tool ...

Oh - and as for "we smart programmers", you do realise you've just 
disqualified yourself as a member of that set? You used the word "we"! 
If the "other" guy respects you, he'll do as you say. I've done some 
crazy things in my time, like using a goto in C :-) But when other 
programmers have said "you shouldn't do that" I've just said "well, you 
do better". Usually, they've looked at the problem to be solved, and 
backed down. If you're a smart programmer, you'll show the other guy how 
to do it better. If you can't, he's smarter than you thought!

"Perfection is achieved, not when everything that is necessary has been 
added, but when everything that is unnecessary has been taken away".

I *know* I'm an expert in DATABASIC. I would *like* to *think* I'm a 
guru, but until somebody like Jim, or Rob, or Monty, tells me I am (and 
I probably wouldn't believe Monty), then I'm not! And even then, I 
wouldn't believe them unless other people I trusted agreed with them.

Ask Loring what unnecessary stuff can be removed from Antlr. Ask Ter. 
Ask Jim. Ask Monty. Ask the people *YOU* *RESPECT* *AS* *EXPERTS* (or 
aren't there any such on this list? :-)

I think you'll find everything in Antlr is there because it's needed. 
Like ASTs for example - I think they happen to be a perfect solution to 
my problem :-)

I know Antlr doesn't do what you want. So stop trying to drive screws 
with a hammer, and go find yourself a screwdriver :-) Don't try and ban 
hammers :-)

(Incidentally, one of the features I found Antlr lacked - or rather 
seemed incredibly complex to implement - in v2 was a stream rewriter - I 
wanted a state engine to flip token types - certain types may or may not 
follow other types and I could do it a lot easier in a stream rewriter 
than by tracking state in the lexer. Maybe that would be a useful tool 
for you, maybe not.)

Cheers,
Wol
-- 
Anthony W. Youngman - anthony at thewolery.demon.co.uk



More information about the antlr-interest mailing list