Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!decwrl!labrea!glacier!jbn From: jbn@glacier.STANFORD.EDU (John B. Nagle) Newsgroups: comp.lang.modula2 Subject: Re: Wirth's paper "From Modula to Oberon" Message-ID: <17457@glacier.STANFORD.EDU> Date: 20 May 88 15:58:06 GMT References: <17451@glacier.STANFORD.EDU> <320@uva.UUCP> <2220@gumby.mips.COM> Reply-To: jbn@glacier.UUCP (John B. Nagle) Organization: Stanford University Lines: 30 In article <2220@gumby.mips.COM> uday@mips.COM (Robert Redford) writes: > > Is there any language that does not have a tragic flaw? Wirth's designs very restrictive languages. He tries to compel people to program in ways that he thinks proper. As he says in the introduction to the original Pascal report, "Along with this dissatisfaction (with previous languages) goes my conviction that the language in which the student is taught to express his ideas profoundly influences his habits of thought and invention, and the disorder governing these languages directly imposes itself onto the programming style of the students." Thus, in a Wirth language, there is ideally only one way to do something, the right way, and many marginally useful things one is forbidden to do. Any flaw in that right way is thus magnified, for there is not likely to be an easy way to escape the problem. Thus such flaws become tragic rather than cosmetic. In C, which in many ways is inferior to Pascal or Modula (either number) in elegance and precision, not to mention safety, one does not often encounter this problem. C has many flaws, but there are usually ways around them. Thus, a major programming effort mounted in C is not likely to run into an unyielding wall of the sort one occasionally encounters in a Wirth language. For this reason, it is important to know, before starting any major effort in a Wirth language, where the unyielding walls that can kill projects lie. Thus it is a good exercise to search any new Wirth language for such flaws early in its life, and to make those walls well known, so that the design constraints they impose can be well understood before it is too late. John Nagle