cik@l.cc.purdue.edu (Herman Rubin) (07/26/90)
This appeared in comp.lang.fortran. The article quoted appears after my comments. A language is a means of communication. Unlike hardware tools, languages can be even interspersed. To someone who knows more than one language, sentences, phrases, and even words in different languages can be strung together in a meaningful fashion. The hardware is the tool. The communications scheme should be such as to enable the programmer to make use of the tool. This is not possible now. It seems that the various groups of language designers seem more concerned with restricting the language than in having it a means of communication. We have functional languages, object-oriented languages, numerical processing languages, list processing languages, statistical languages, etc. None of them is any good if the problem does not fall in the slot. These languages tend to have unnatural restrictions in their syntax. We need a language with reasonable syntax with which we can communicate with the computer. It will necessarily have to contain a super-assembler. Such a beast, with a flexible macro processor, and a user-rewritable flexible syntax, would enable someone like me to produce good code at a comparable rate to the HLLs. HLL features can be added; I have no opposition to that. But we cannot afford languages like the present analogues of Basic English, where the language takes the position that something cannot be said. ---------- In article <1990Jul25.210639.20509@murdoch.acc.Virginia.EDU>, gl8f@astsun8.astro.Virginia.EDU (Greg Lindahl) writes: > In article <11029@chaph.usc.edu> ajayshah@aludra.usc.edu (Ajay Shah) writes: > > >I recently hit a research group which worked exclusively in > >fortran, and had to write fortran for a while, and was it a > >nightmare!! A language which has no data structures to speak of, > >no dynamic allocation, no recursion, everything passed by > >reference, no checking for number/type of arguments to > >functons/subroutines, no control over scoping..not to mention the > >silly syntactic irritations. > > If you were using FORTRAN 77 to write programs which need the features > it doesn't have, you're using the wrong tool. Use another one. If you > are writing programs for which F77 is good, use it. It just so happens > that the programs I write fit the F77 model well. > > BTW, checking the number/type of arguments to functions/subroutines is > something which can be done. The Sun compiler doesn't do it, but > running the code through f2c does. > > Followups to alt.religion.computers. > > -- > "In fact you should not be involved in IRC." -- Phil Howard -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)
nick@lfcs.ed.ac.uk (Nick Rothwell) (07/27/90)
In article <2408@l.cc.purdue.edu>, cik@l.cc (Herman Rubin) writes: >A language is a means of communication. Unlike hardware tools, languages >can be even interspersed. To someone who knows more than one language, >sentences, phrases, and even words in different languages can be strung >together in a meaningful fashion. > >The hardware is the tool. The communications scheme should be such as to >enable the programmer to make use of the tool. The communications scheme should be such as to enable the programmer to express and solve his problem. No? Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick ~ ~~ ~~ ~~ ~~ Hey, son, get that DeLorean off the track! And ~~ ~~ ~~ ~~ ~ what have you done with all my lovely harpsichords?
utoddl@uncecs.edu (Todd M. Lewis) (07/28/90)
I think there is a real tendency to confuse the notion of language
as a tool to communicate (like people talking) with the notion of
formal languages used to specify programs. The former is really
a protocol while the second is instantiated as a statement. The
remarkable (and useful) similarities of the two obscure their
differences. Do you really want the computer to start second-guessing
your intentions based on its interpretation of the current operating
context? To add more than the common safety checks ("Are you sure [y/N]?"
type messages) would require far more than a quantum leap in system
complexity--it would have to _understand_itself_ to be able to
_understand_ what you want it to do. To really specify something
unambiguously, a sequence of commands--a program, is not easy at all.
Software isn't stupid because it "does not let users communicate their
needs". The formal language that controls that software is either
inadequate in itself, or too alien to the user to allow efficient
control. The common ways to approach the problem are (1) improve the
formal language so adequate commands are possible (this may involve
adding function to the software, but we aren't talking about that),
(2) alter the language so it more closely parallels the user's
normal way of communicating (the ever-popular "natural language
interface"), and last-but-by-no-means-least (3) alter the user
to more closely parallel the software's normal way of communicating.
This last one usually costs about $300 to $500 per day for several
days and involves traveling to the other coast.cik@l.cc.purdue.edu (Herman Rubin) (07/29/90)
In article <5374@castle.ed.ac.uk>, nick@lfcs.ed.ac.uk (Nick Rothwell) writes: > In article <2408@l.cc.purdue.edu>, cik@l.cc (Herman Rubin) writes: .......................... > The communications scheme should be such as to enable the programmer > to express and solve his problem. > > No? With enough work, I could interpret any machine and any of the current languages in any other, assuming that memory problems do not occur. It 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. Now I do not believe that a language which can accomplish all this can be produced which is completely portable. But it is necessary to take these things into account in designing the language. Making it extensible can enable local modifications to be made. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)
cg@myrias.com (Chris Gray) (07/31/90)
In article <2416@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >It 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. > >Now I do not believe that a language which can accomplish all this >can be produced which is completely portable. But it is necessary >to take these things into account in designing the language. Making >it extensible can enable local modifications to be made. It seems to me that Herman has a completely different set of needs (from a programming language) than I do. Hence, his opinions on what a good programming language needs differ from mine. 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. Most programs that I work on are well over 10,000 lines, and, usually, no one part is much more important than any other (there are of course hot spots, but there are lots of them, rather than just one or two). I don't agonize over a small piece of code, either to make it as short as it can be or to make it as fast as it can be. 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 (like critical sections and timing-related bugs in my IOP code), etc. As someone who has designed, implemented and regularly uses his own compiler (don't ask - its only available on CP/M and the Amiga), I also disagree with Herman's ideas about very loose syntax, extensibility, etc. Such a beast would have very poor error handling, and hence would be quite unfriendly to work with (even worse than pre-ANSI C!!). It would, also, in my opinion, be DANGEROUS to work with - the compiler would have to trust the programmer implicitly (just like in assembler), so would have few opportunities to point out things that don't make sense. I wouldn't want such a language to be used in things like nuclear reactors, railroad control systems, etc. It could be fine for Herman's fine detail fiddling, but its not for me! -- Chris Gray Myrias Research, Edmonton +1 403 428 1616 cg@myrias.COM {uunet,alberta}!myrias!cg
phipps@garth.UUCP (Clay Phipps) (08/17/90)
In article <avhch3ro@myrias.com> 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 !!!!]