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) |
[9 later articles] |
From: | "Joachim Durchholz" <joachim_d@gmx.de> |
Newsgroups: | comp.compilers |
Date: | 8 Sep 2000 02:27:42 -0400 |
Organization: | Compilers Central |
References: | 00-08-130 |
Keywords: | design, comment |
> [I hope not. Most languages have too many features already. PL/I
> tried to incorporate every known language feature in the 1960s, and
> ended up so ugly that in reaction people designed deliberately small
> languages like Pascal. Recently bloat has come back into vogue, viz.
> C++. -John]
Let me elaborate a bit:
It's nice to have features, but the PL/I experience has shown that an
intelligent combination of language features is more important than the
list of language features itself.
It's a bit like setting up a palette for painting. You could use all
sorts of colors: oil, acryl, water-based, and whatnot, but you can't
really combine them in a single painting, and in fact you need different
techniques to work well with either type of color, so it's definitely
*not* a good idea to try mixing them all to get the best of all worlds.
Getting back to programming languages: the more features you have, the
more potential interactions exist, it's getting more difficult to fully
understand the language, it's getting more work to decide what language
feature is best to do a given job, and it's more work and also much more
difficult to get the compiler a) correct and b) efficient. It's also
more difficult to read the code: it's easy to restrict oneself to those
features that one knows well, but this option doesn't exist when reading
code: the reader must have a perfect understanding of all language
features that he will encounter, and that's more difficult if the
language is large (and I suspect it's quadratic with number of
features). Besides, if the language gets large, it's getting more
difficult to find people who are fluent with all its semantic details
(there aren't many people out there who can handle all aspects of C++,
for example, and C++ is still quite restricted in terms of "could
have").
Regards,
Joachim
[The problem with PL/I is that each feature by itself is fine, but they
don't fit together. Classic example:
DECLARE (A, B, C) CHAR(3);
B = "123"; C = "456"; A = B + C;
What's in A? Well, PL/I automatically coerces strings to numbers in
an arithmetic context, so it turns B and C into 123 and 456, then it
adds them to get 579. It also converts numbers back to strings, using
a default width, so that's coverted to " 579". Then the string is
truncated to fit, so A gets " ". Oops. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.