Re: Looking for new language features

Michael Quinlan at mq@maq.org wrote on 9/11/00 2:17 PM:
> The very well know problem with that approach is that when the next
> person comes along to maintain your programs, he or she has to learn
> your private programming language. And they usually have to do it
> without the benefit of manuals, classes, etc; just access to the source
> for your macros.


Why are "abstract data types" any easier to deal with than "abstract
control types?" I've certainly witnessed the "syntax du jour" problem
that John spoke of, personally, but I've come across the same problems
with "libraries du jour" and "ADTs du jour." The fact that a language
feature can be abused does not imply that it shouldn't be available to
those who can make proper use of said feature. I have a big problem
with language designers who attempt to protect programmers from
themselves. The proper way to handle the issues you describe above is
via corporate style guidelines and proper reviews. Finally, I would
ask "What is worse? Providing a single extensible language what
forces those who follow you to learn your 'funny' syntax in the
framework of a single language, or have the programming team use a
dozen different languages, each (supposedly) good at what it does?"
I've seen projects that involve code written in Make, C, Perl, Awk,
sh, Delphi, BASIC, and SQL. The likelihood that every future
programmer who would have to work on that project would know all these
languages is very low. So the problem doesn't really go away, it just
"shifts gears" in projects like these. (Note that I'm not arguing
that a macro processor would replace all these languages, I'm just
saying that an absence of the macro processor does not guarantee that
the "language du jour" problem goes away).


Randy Hyde

Return to the comp.compilers page.
Search the comp.compilers archives again.