Re: language design tradeoffs

bks@s27w007.pswfs.gov (Bradley K. Sherman) writes:
|> 1) Just say NO to else!
|> ... Nested and multiple elses are the devil's playground.


When designing code, I very seldom use else statements, but when actually
coding, I just about always use the else statement (or default case) as a
trap. The reason is that if the code gets to that state, I have failed to
anticipate some transition of the software (either compiler glitch, system
glitch, or my own error, not that I make any of those mind you :-) ).
This little trick catches more than a few errors.


|> 2) Delimit the code, not the comments.
|> I'm prepared for _every_ keystroke in a computer language to be
|> exact. I'd like more freedom in constructing the commentary.


I don't see how that helps. Instead of bodies of code optionally
separated/ terminated by comments we get comments optionally
separated/terminated by code. One problem of heavily commented code, is
the tendency of programmers to modify code without updating the comments
correctly. I suspect that if languages could express a programmer's
concepts more eloquently, then comments would become quite rare, as you
couldn't beat looking directly at the code. Of course it might be a
little while before we get to this point :-).


|> 3) No macros or overloading.


I personally am not a big fan of operator overloading, but it does seem to
have its uses. If operator overloading could be made type safe (I'm not
saying that it can't, but I'm just not sure how, replies are welcome here)
then it would introduce a certain amount of notational convenience. It
might be nice to be able to handle matrices, complex numbers, polynomial
functions, ... with normal notation. The problem I have with that, is
that if different users specify different operator overloading schemes
(for the same type that is), I'm not sure how code could be rendered
compatible. This is a bit contrived, so bear with me, but suppose user X
overloads the <= operator in relation to sets to test if set A has fewer
elements than set B. If user Y then uses the <= operator to test if set A
is a subset of set B, maintenance problems for the two bodies of code
would be pretty nasty (unless of course noone ever supports code written
by another programmer).


|> 4) No lines of over 79 columns allowed.
|> Nothing is harder to read than code which disappears off the
|> sides of the screen, or worse, slops over onto the next line
|> completely ruining the advantages of careful composition.


I just can't stomach this one (sorry). This smacks of my favorite (well
not quite) features of cobol and fortran punch card mentality. This does
not seem to be the sort of thing I'd like to see in any language I use.


Bill
--
| maniattb@cs.rpi.edu - in real life Bill Maniatty
--

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