Re: Looking for new language features

Randall Hyde <rhyde@cs.ucr.edu>
13 Sep 2000 20:22:50 -0400

          From comp.compilers

Related articles
Looking for new language features lingolanguage@hotmail.com (William Rayer) (2000-08-27)
Re: Looking for new language features etoffi@bigfoot.com (2000-09-08)
Re: Looking for new language features joachim_d@gmx.de (Joachim Durchholz) (2000-09-08)
Re: Looking for new language features rhyde@cs.ucr.edu (Randall Hyde) (2000-09-09)
Re: Looking for new language features guerby@acm.org (Laurent Guerby) (2000-09-09)
Re: Looking for new language features mq@maq.org (2000-09-11)
Re: Looking for new language features rosing@peakfive.com (Matt Rosing) (2000-09-11)
Re: Looking for new language features rhyde@cs.ucr.edu (Randall Hyde) (2000-09-13)
Re: Looking for new language features viczh@uic.edu (Victor Joukov) (2000-09-15)
Re: Looking for new language features adrian@dcs.rhbnc.ac.uk (2000-09-17)
Re: Looking for new language features mr@peakSPAMLESSfive.com (Matt) (2000-09-21)
Re: Looking for new language features georg.lokowandt@sap.com (Georg Lokowandt) (2000-09-23)
Re: Looking for new language features vbdis@aol.com (2000-09-28)
Re: Looking for new language features rhyde@cs.ucr.edu (Randall Hyde) (2000-10-01)
[4 later articles]
| List of all articles for this month |

From: Randall Hyde <rhyde@cs.ucr.edu>
Newsgroups: comp.compilers
Date: 13 Sep 2000 20:22:50 -0400
Organization: Posted via Supernews, http://www.supernews.com
References: 00-08-13000-09-048 00-09-07500-09-084
Keywords: design

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


Post a followup to this message

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