Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C)

rfg@monkeys.com (Ronald F. Guilmette) wrote:


<snip>


>The problem is with languages and their standards. They are just too
>big. That's because most of the consumers of these languages are just
>too greedy for more and more features, and because they are just too
>ignorant of the inherent limitations of the human brain to understand
>these complex behemoths we call `modern programming languages'.


Big? I don't think that it's a problem of big...


>Hell! Even the people who sit on the drafting committees for these
>recent langauges don't know _all_ of the details of what they are
>voting for most of the time.


ROTFL.. This same thing happens any time when a number of people get
together to do design work. Design doesn't happen in comittee.


>I see only one solution. We must at some point introduce some
>disipline into the process of crafting languages and their standards.
>There is one good way to do that which would also result in the
>languages themselves being not only smaller, but less buggy. We need
>to insist that language standardization committees write complete
>FORMAL SPECIFICATIONS for the arcane and baroque languages that they
>are trying to standardize. If we (the consumers) did this, you would
>quickly see the wheat being separated from the chaf, and large numbers
>of overly complex features being tossed overboard (like so much
>ballast), much to the benefit of the average programmer-on-the-street
>who has to code in these unfortunate and massively over-engineered
>travesties of programming languages that we have today.


HTML has formal specifications, that doesn't mean that there aren't
several ways to do the same thing. Formal specification isn't a
pancea to solve the problems of modern language design.


<snip>


>There seems to be something about the adult human mind that yearns for
>com- plexity in much the same way as the mind of a child yearns for
>candy. We must eventually learn to disipline ourselves against this
>or else we will ultimately drown in a sea of complexity of our own
>making.


I think that it's more than that. I think that the Adult human mind
in most cases isn't diciplined enough to spend the time to create an
elegant design for a language. It requires a great deal of dicipline
and effort to create a language that meets all of the needs and fits
into an elegant design. The problems with C++ and Ada as well as PL/I
and COBOL is that the elegance of the languages have been lost over
time with too many cooks making the broth.


Unfortunately, that seems to be the nature of any human endeavour.
I'm called into large corporations to fix the "designs" that were
created by committee on a regular basis. I'm always amazed at just
how easy it is to solve the problems that a very large number of
people can't solve. Problems that the people have been trying to
solve for long periods of time and arguing about in meeting after
meeting for months. But that's why I get paid the big bucks... Big
bucks that would have been unnecessary if they have just allowed the 2
or 3 guys that knew the technology a chance to do the work without the
political forces joining in for the sake of "politics."


Wilbur
[This is drifting away from compilers, unless it drifts back I'll encourage
people to take this to comp.lang.misc. -John]






--

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