From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: *
X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_20,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Xref: utzoo comp.software-eng:3016 comp.lang.ada:3370 comp.lang.c:26496 comp.lang.fortran:2949 comp.lang.lisp:2854 comp.lang.misc:4314 comp.lang.modula2:2137 comp.lang.pascal:3186 comp.lang.scheme:1129
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.software-eng,comp.lang.ada,comp.lang.c,comp.lang.fortran,comp.lang.lisp,comp.lang.misc,comp.lang.modula2,comp.lang.pascal,comp.lang.scheme
Subject: Re: problems/risks due to programming language, stories requested
Message-ID: <14258@lambda.UUCP>
Date: 2 Mar 90 23:27:22 GMT
References: <1004@micropen>
List-Id: <comp.lang.ada>

>From article <1004@micropen>, by dave@micropen (David F. Carlson):
> [... explicit breaks in the C switch construct ...]
> Dijkstra notes that no programming language can prevent a poor programmer from
> creating bad programs.

He also notes that the choice of programming language can have a strong
effect on the quality of the resulting code.  (His indictment of PL/I
as being similar to flying a widebodied jet with all the windows taped
over and no labels on the thousands of controls was quite apropos.)
This effect of the language choice is mainly psychological - and it
CAN be overcome (which is the main thrust of many of Dijkstra's works).
But, be honest, how many programmers do you know who _really_ construct
their programs abstractly _before_ even selecting their implementation
language?  This is the proper way (a' la Dijkstra) to make sure the
you aren't negatively impacted by the language - you select the proper
language for the job at hand - you don't mangle the job to fit the
language.

Dijkstra's statement, while true, should not be used to excuse poorly
designed language features (as you are trying to do).  A better design
for C would have been _not_ to require breaks after each case and to
provide some other syntax for the representation of multiple choices
on the same case.  It's easy to see these kinds of design errors
in retrospect (C _is_ nearly 20 years old you know).

J. Giles