Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!synoptics!unix!garth!phipps From: phipps@garth.UUCP (Clay Phipps) Newsgroups: comp.lang.misc Subject: Re: What is the language for ? Message-ID: <695@garth.UUCP> Date: 16 Aug 90 18:51:30 GMT References: <1990Jul25.174153.16896@ecn.purdue.edu> <11029@chaph.usc.edu> <5374@castle.ed.ac.uk> <2416@l.cc.purdue.edu> Reply-To: phipps@garth.UUCP (Clay Phipps) Organization: Intergraph APD, in sunny-but-too-dry Palo Alto, CA, USA Lines: 125 In article cg@myrias.com (Chris Gray) wrote: >In article <2416@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) wrote: >> >>[Rubin's ideal language] should be such as to enable the programmer >>to express his problem in a manner that is compatible with the structure >>of his problem and the capabilities of the machine. It should also be >>such that the resulting program is reasonably efficient. [...] >>Making it extensible can enable local modifications to be made. > >Herman has a completely different set of needs (from a programming language) >than I do. [Our] opinions on what a good programming language needs differ. >Herman is concerned about the efficiency and ease of representation of >small pieces of code which are crucial to his overall application. >I am concerned about the readability, maintainability and efficiency of much >larger programs. [...] I let the compiler worry about code size and speed. >I worry about the overall operation and readability of the whole program, >since I am constantly adding new things, fixing bugs (...), etc. In all of Herman's postings over the last 2 years that I have had continuous recent net access, my impression of his work is thus: [1] Attaining the maximum speed provided by the hardware is important. [2] No one but he will ever work on the programs that he writes. [3] He never makes sweeping changes in any program that he writes. [4] He has no collection of users of his programs who present him with new or changed requirements for his programs that he must satisfy. [5] Errors in his programs are not life-threatening nor comparably critical. Were it not for Herman's insistence on all possible speed from apparently arbitrary machine architectures and organizations, numerous programming language design academicians ought to be able to design a language that would suit him. In an era when the size of resident code for single-task operating systems + environments for microcomputers exceeds the size of the resident code for multitasking operating systems for the mainframes of 20 years ago, and the dominant microcomputer software house ("those who fail to learn from history...") is rumored to be The Second Coming Of The Mythical Man-Month ("...shall be destined to repeat it"), the most important challenges in the programming languages field seem to be in designing languages and compilers that can be an asset (not a hindrance) in development, maintenance, and market-driven enhancement of large but reliable and reasonably efficient software products. I suspect that many of us in the business of providing compilers to The Real World adopt this orientation because of an intense desire to quit being bitten by bugs resulting from our own innocent mistakes ("to err is human"), or from the laziness and stupidity of others :-). I believe that despite the admiration that many of us doing language design or compiler work in The Real World feel for certain prominent programming languages academicians, and despite our appreciation for all of the useful ideas that they have contributed to the field, many of us remain skeptical that most academicians will ever overcome their lack of experience with large software projects in The Real World, so as to design programming languages that meet the often less-than-ideal ("life is cruel") requirements of software development and *maintenance* and *enhancement* in The Real World. >I also disagree with Herman [on] very loose syntax, extensibility, etc. >Such a beast would have very poor error handling, It's implausible to me that the people who made the effort to extend the language--if speed freaks like Herman--would make the effort to provide error handling that was up to the standards of an original compiler-writer concerned about the quality of the human interface. I recall clearly that those nifty "one-liners" written in APL by its zealots never seem to have any error-handling other than the system built-in ("DOMAIN" | "INDEX" | "RANK" | "VALUE") "ERROR" two-word diagnostic messages. >and hence would be quite unfriendly to work with >(even worse than pre-ANSI C!!). I'd much rather have a griping compiler than a boss who has just gotten an earful of griping from an important ($$$) user of a shipped product. C is customarily not the former, but can certainly make the latter easy. >It would, also, in my opinion, be DANGEROUS to work with - the compiler >would have to trust the programmer implicitly (just like in assembler), I've long wanted to use language features for expressing my intent in a program in a form that can be checked by the compiler. I have in mind more than just "assert" statements or range-checking, but I'll have to defer that to a future posting. >so would have few opportunities to point out things that don't make sense. Like in passing parameters between separately compiled routines of the large dusty-deck FORTRAN programs still in use today ? >I wouldn't want such a language to be used in things like >nuclear reactors, railroad control systems, etc. That is, like those dusty decks written for good ole FORTRAN ? >It could be fine for Herman's fine detail fiddling, but its not for me! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That depends whether or not Herman is like many university faculty members whose income is raised above subsistence level by consulting. If his "fine detail fiddling" is on statistical failure analysis of nuclear reactors, buildings in active seismic zones, or the incidence of illness among users of proposed "wonder drugs" undergoing testing, the consequences will reach far beyond his ivory tower in Hoosier Country. Herman's contrarian views are useful to those of us who would prefer not to exclude users of our own programming languages through our own oversights, as hidden by personal blind-spots (e.g.: making it impossible or unnecessarily aggravating to perform multiple-precision arithmetic, without intending that things work out that way). Considering that just about everything in language design imposes a cost, or conflicts with some desirable goal, there will probably continue to be plenty of instances in which the cost of accomodating Herman's perceived needs simply exceeds the cost to a language design of doing so, or conflicts with a goal deemed more important by the person who has to make the language design work. -- [The foregoing may or may not represent the position, if any, of my employer, ] [ who is identified solely to allow the reader to account for personal biases.] [Besides, this was posted during test runs executing during the "lunch-hour".] Clay Phipps Intergraph APD: 2400#4 Geng Road, Palo Alto, CA 94303; 415/852-2327 UseNet (Intergraph internal): ingr!apd!phipps UseNet (external): {apple,pyramid,sri-unix}!garth!phipps EcoNet: cphipps [Patience--our delay for receipt of postings is now approximately 2 weeks !!!!]