Re: Definable operators

Craig Burley <burley@tweedledumb.cygnus.com> writes:
>I've lately been considering that perhaps there are no good
.....<snip very long post>.......
>bounds-checking, interval arithmetic, and include the kinds of
>linguistic improvements I've been going on about.
>
>After all, if a bit-banging programmer like me sees the writing
>on the wall, surely _something_ has to be going on out there! ;-)


These are all excellent points, and to be considered. The elimination
of unnecessary complexity is to everyone's benefit. The problem
arises in the definition of "unnecessary complexity" -- because when
you program in the "large" and/or work with inherrently complex
problems, the tools made available by most "simple" languages just
don't cut the mustard.


Take C++ vs Java for example. The authors have done a good job of
cutting a lot of "unsafe" feature from C++. But, the result is, in
many ways, a "toy" language. O.k. for small problems or simple
problems, but it breaks down for larger problems. Those "unnecessary"
features are just what is needed for really hard problems.


On the other hand, C++ is an atrocity (even if it *is* one of the most
useful languages around). Its adherrence to C, the inconsistency
between primitive objects and "classes", the lack of gargage
collection, the unsafe arrays, etc., etc..


Eiffel is a *lot* better in many ways -- but also has its drawbacks.
Some of which it shares with C++. Some of which, like Java, it has
because it cut out too much.


What we need is *not* a simple language, but a large, powerful
language which is simple to use and understand. And where the
features are orthogonal enough that not knowing or using a feature
does not impact either the programmer's time (unless he/she is
learning the feature, of course) or the program the programming is
writing.


As an example of the above, consider the control structures that you
find in almost all modern procedural lanaguages. Are these ALL of the
control structures you could need or want? Certainly not! In fact, I
know of more than 50 different control structures (including modifier
statements like "break" or "continue") which are appropriate for a
procedural language (yes, I do consider OO languages procedural
because you write procedural code in the methods).


You can argue that these control structures are not needed. And in
theory you are both correct and incorrect. It has been shown that
very simple control structures are adequate to write any program.
But, it has also been shown, that for any set of control structures,
there are programs which grow exponentially in size when compared to
the use of another control structure. That is not surprising, but
what I find is that these situations occur much more often than people
realize. So perhaps, in some ways, the problem is not languages that
are too complex and have too many features, but rather languages which
are too simple and have too few features.


Another point is that this idea that "there should only be ONE way to
do something" has taken disasterous hold in the minds of most people
involved in language design (excepting Perl). The disadvantage of
that meme is that since there IS only one way to do something it is
invariable very difficult. Also, you can't say what you mean.


As an example of both of the above, consider the fact that about 80%
of the conditionals in most programs do not have an "else" clause, and
also consider the fact that many, many (if not most?) programmers are
"negation challenged". You could then add two new conditional control
structures to a language to complement the traditional "if" statement.
I call these "when" and "unless". They are identical to an "if"
without an "else" clause (and do not allow an "else" clause) except
that "unless" is the same as "if (not (x))" and "when" is the same as
"if (x)". The advantage here, is that by the addition of new features
to a language, you can allow the programmer to say exactly what he/she
means. It also has the advantage that negated conditionals are
eliminated (in about 40% of the conditionals) which reduces
programming errors. It means that inadvertant "else" clauses cannot
be added or subsumed by "accident".


I have used macros to generate such conditionals in C/C++ for years
and have found them to work very well. Perl also provides the
"unless" (but does allow an "else" clause, so loses some of the
benefit). I strongly believe that by adding such new control
structures to a procedural language, you reduce code complexity.
Because you map the code to problem with less "shoehorning".


I think that such a language can be designed -- but you will never get
it from any committee, and if designed and released it will probably
not catch on. And, certainly, you can't get such a language by adding
features at random. But, I think that you CAN get such a language.
And, you can make it "safe" and "efficient" -- both from a
programmer's standpoint and a problem standpoint.


Michael Lee Finney
[To forstall nitpickers, we know that perl allows unless ... else. -John]


--

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