ta*******@msn.c om (TTA) wrote in message news:<b5******* *************** ****@posting.go ogle.com>...
[ ... ]
The analogy of becoming a better driver while building a car to
building a compiler to learn the language does not hold very well.
You're writing a compiler FOR the language IN the language. I'm
confused...how does that not teach you better C++?
Almost any major project (and a C++ compiler certainly qualifies) will
be educational, but learning C++ by writing a C++ compiler is a bit
like trying to read books under a microscope -- you miss the forest
for the trees.
You may still need to learn some software methodologies for different
types of projects, but you'd know the language inside-out. But I do
understand your point.
The relationship is not nearly as close as you seem to think -- I've
written compilers (and interpreters) for languages without ever
knowing those languages particularly well. I've also learned some
languages quite well without ever writing a compiler for them.
At least in my experience, your first two translators are more or less
throwaways. In the first, you're so caught up in learning the basics:
parsing, code-generation, etc., that those are really about all you
can learn at that stage. Intentionally or not, the second is largely
a rewrite of the first, using techniques you learned too late in the
first to apply them where you wanted to, and so on -- even when
they're really inappropriate to the project at hand.
The third translator is the first one in which you can start to step
back and look at things more systematically. Chances are that by
then, however, you'll have started to look at most languages as
variations on a couple of themes, and instead of really wanting to
know every detail of a particular language, you start to wish they
(the languages) were more consistent and had fewer of those ugly
details to deal with.
That usually leads to designing and implementing a few languages of
your own. Chances are they'll have some improvements over their
direct predecessors, but also that they'll never be used by anybody
but you and perhaps a few of your close friends.
After that, if you're a programmer who designed a few languages,
you'll do other programming, and occassionally when you look at a
language spec, you'll cringe and think "I'm sure glad I don't have to
write a compiler for that!".
OTOH, if you're really a language designer who happens to porgram,
you'll apparently continue trying to invent a better programming
language. If you're good (and a bit lucky) you might become the next
Dennis Ritchie, Bjarne Stroustrup, Niklaus Wirth, etc. (I can only
speak about this from observation though -- I'm clearly in the
category of a programmer who's designed a few languages).
Of course, there are other choices at each stage: just for example,
there are a few people who really do just write compilers and never
seem to have designed their own languages. For a long time, Walter
Bright seemed to be in that category, but now he's designed a language
of his own too (and it's better than most, I might add).
In the end, I'd say this: a particular language is nothing more than a
particular notation for expressing solutions to problems. Learning a
particular language in exceptional detail only helps you (possibly) do
a (slightly) better job of expressing the solution -- the real task is
in programming is the solution itself. Problem solving transcends
language.
--
Later,
Jerry.
The universe is a figment of its own imagination.
