chris@mimsy.UUCP (Chris Torek) (01/31/88)
The idea of a universal language has appeal: One language for every problem. So does the idea of a universal vaccine: One cure for every illness. Personally, I believe the chances for either are about the same. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
zjat02@apctrc.UUCP (Jon A. Tankersley) (02/01/88)
One cure for every illness? There is one. It is rather permanent, but you never have to worry about catching another disease. Death. And I guess not programming would solve the perfect language problem too :-). -tank-
djsalomon@watdragon.waterloo.edu (Daniel J. Salomon) (02/02/88)
In article <10407@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >The idea of a universal language has appeal: One language >for every problem. So does the idea of a universal vaccine: >One cure for every illness. Personally, I believe the chances >for either are about the same. This is a poor analogy. The function of a programming language is totally different from a vaccine, and so is the development process. A vaccine has strict biological constraints on its size and form, but a programming language has few constraints. Save this cute line for cocktail parties when people are too drunk to analyze it.
eugene@pioneer.arpa (Eugene N. Miya) (02/03/88)
In article <4930@watdragon.waterloo.edu> djsalomon@watdragon.waterloo.edu (Daniel J. Salomon) writes: >In article <10407@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>The idea of a universal language has appeal: One language >>for every problem. So does the idea of a universal vaccine: >>One cure for every illness. Personally, I believe the chances >>for either are about the same. > >This is a poor analogy. The function of a programming language is >totally different from a vaccine, and so is the development process. >A vaccine has strict biological constraints on its size and form, but a >programming language has few constraints. Save this cute line for >cocktail parties when people are too drunk to analyze it. Actually, I believe that Chris has a reasonable analogy. I sent him mail saying so. Vaccines generate antibodies which "recognize" virsues, etc. The constraints of languages are frequently many: strong typing, subscript checking (memory protection), etc. I come to Chris's defense because you posted this rather than mailed to him. Why not argue the superiority of any single natural language like the superiority of English over Chinese like the lingistics people did around Whorf's time. P.S. I agree with Chris's chances. From the Rock of Ages Home for Retired Hackers: --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene
markv@uoregon.UUCP (Mark VandeWettering) (02/04/88)
In article <4930@watdragon.waterloo.edu> djsalomon@watdragon.waterloo.edu (Daniel J. Salomon) writes: >In article <10407@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>The idea of a universal language has appeal: One language >>for every problem. So does the idea of a universal vaccine: >>One cure for every illness. Personally, I believe the chances >>for either are about the same. >This is a poor analogy. The function of a programming language is >totally different from a vaccine, and so is the development process. >A vaccine has strict biological constraints on its size and form, but a >programming language has few constraints. Save this cute line for >cocktail parties when people are too drunk to analyze it. First of all, your tone is not becoming of the normally high level of professionalism that is displayed in this newsgroup. Criticism is part of the intellectual process, insults are not. Confine such comments to newsgroups where such behavior is appropriate (i.e. none). Now, back to Chris' analogy, one that I have used is "Ya don't use a screwdriver to pound nails". Some languages are better for symbolic processing, others are better for operating systems. The type of problems you face dictate the tools you use to solve them. The idea of one perfect language implies that everyone's needs are the same. Sorry Charlie, t'aint so. mark vandewettering
morrison@accuvax.nwu.edu.UUCP (Vance Morrison ) (02/05/88)
This discussion seems to be on the subject at to whether it is possible have a single unified language or not, and I would like to put in my two cents worth. Several of you responded that the single language scenerio was impossible since the applications you need languages for are so varied that a single language could not handle them all efficiently. In my opinion, this is a half-truth, bordering on being wrong. An analogy was drawn between tools and programming languages, namely in the same way as you use different tools to do different jobs, you use different programming languages to do different types of programs. I actually like the analogy of real tools to programming tools because they are in fact very much alike. But I think the above analogy should not liken programming languages to individual tools, it should compare them to a toolbox or a workshop. I have one toolbox (programming language) it has many different types of tools in it (programming features, libraries etc). I can do a large variety of different jobs with the SAME toolbox because I simply select the tools that are necessary for that job and ignore the rest. What I DON'T have, (But what I have to deal with every time I program), are sets of tools that are 'glued' together and can only be used together. Because the tools are are 'glued' together, I have to have many tools that do the same thing in every incompatible set. Thus I have to learn many different ways of doing the same thing. So the essence of the one language approach is this: Every tool (programming feature) should be usable whenever it could be useful, and useing this feature does not require you to restrict the kinds of tools you use (that it it does not box you into a language that does not have some of the features you want.) So in some ways this one language is in fact many special purpose languages inside it. What makes it different that many little languages is that the programmer can 'mix and match' ANY special purpose features to solve the problem at hand. I believe such a unified language is technically possible (administration is a whole different ball game), and in fact I am trying to design such a language right now. Vance Morrison morrison@accuvax.nwu.edu morrison@nuacc.bitnet morrison@northwestern.arpa
hansen@mips.COM (Craig Hansen) (02/05/88)
In article <1535@uoregon.UUCP>, markv@uoregon.UUCP (Mark VandeWettering) writes: > Now, back to Chris' analogy, one that I have used is "Ya don't use a > screwdriver to pound nails". Some languages are better for symbolic > processing, others are better for operating systems. The type of > problems you face dictate the tools you use to solve them. Another expression relevant to language design, is one I heard from Brian Reid: "When all you have is a hammer, everything looks like a nail." Which is to say that it is also the case that the tools that you have dictate the problems you work on and the way you try to solve them. There is a basic problem in language design: a single language that is good for all purposes will be very complex. A language designer, working alone will be unable to design such a language, and it isn't at all clear that a committee of language designers would bring any more effective intellect on the problem. On the other hand, a little language, that solves problems well in a limited problem domain, is within easy reach of an individual language designer. Now a little language, by itself, only works in a limited problem domain, and trying to pound nails with a screwdriver is a waste of effort. UNIX works well because it encourages many small tools and languages to be used together, using pipes and shell scripts as the glue between the little pieces. I think it also helps greatly that UNIX includes effective tools for developing little languages themselves: particularly awk, yacc, cpp. (Personally, I find lex to be utterly worthless, but it's a matter of taste.) [Use The Force: Don't let the Death Star take our UNIX away.] -- Craig Hansen Manager, Architecture Development MIPS Computer Systems, Inc. ...{ames,decwrl,prls}!mips!hansen or hansen@mips.com 408-991-0234
crowl@cs.rochester.edu (Lawrence Crowl) (02/06/88)
In article <1496@mips.mips.COM> hansen@mips.COM (Craig Hansen) writes: >There is a basic problem in language design: a single language that is good >for all purposes will be very complex. Only if you insist that the libraries be considered part of the language or you insist on languages which do not make the notions of type and procedure available to the programmer. >A language designer, working alone will be unable to design such a language, >and it isn't at all clear that a committee of language designers would bring >any more effective intellect on the problem. I believe that only a single language designer can achieve such a language. Such a language requires deep coherency between all aspects of the language, something that is unlikely in a committee. This does not mean that the designer works alone---others provide feedback, but the designer is responsible for all decisions. >Now a little language, by itself, only works in a limited problem domain, and >trying to pound nails with a screwdriver is a waste of effort. UNIX works well >because it encourages many small tools and languages to be used together, >using pipes and shell scripts as the glue between the little pieces. People must also learn an incredible variety of little languages. Most of the little Unix tools work OK with each other, but they do not work well. How many ways are there to delete something in Unix? How many mechanisms for changing the interpretation of shell paramters are there? Unix requires far too much special case, "wizard" knowledge. I am not arguing that anything is better than Unix, only that its many language approach introduces far too many inconsitencies to be the desired solution. -- Lawrence Crowl 716-275-9499 University of Rochester crowl@cs.rochester.edu Computer Science Department ...!{allegra,decvax,rutgers}!rochester!crowl Rochester, New York, 14627
djsalomon@watdragon.waterloo.edu (Daniel J. Salomon) (02/06/88)
In article <1535@uoregon.UUCP> markv@drizzle.UUCP (Mark VandeWettering) writes: >In article <4930@watdragon.waterloo.edu> djsalomon@watdragon.waterloo.edu (Daniel J. Salomon) writes: >>In article <10407@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>>The idea of a universal language has appeal: One language >>>for every problem. So does the idea of a universal vaccine: >>>One cure for every illness. Personally, I believe the chances >>>for either are about the same. > >>This is a poor analogy. The function of a programming language is >>totally different from a vaccine, and so is the development process. >>A vaccine has strict biological constraints on its size and form, but a >>programming language has few constraints. Save this cute line for >>cocktail parties when people are too drunk to analyze it. > >First of all, your tone is not becoming of the normally high level of >professionalism that is displayed in this newsgroup. Criticism is part >of the intellectual process, insults are not. Confine such comments to >newsgroups where such behavior is appropriate (i.e. none). > >Now, back to Chris' analogy, one that I have used is "Ya don't use a >screwdriver to pound nails". Some languages are better for symbolic >processing, others are better for operating systems. The type of >problems you face dictate the tools you use to solve them. > >The idea of one perfect language implies that everyone's needs are the >same. Sorry Charlie, t'aint so. > >mark vandewettering If my comments offended anyone, I apologize. The worst word I used was "drunk", and I didn't apply it to the poster. But I still think that programming languages have little in common with vaccines, hammers or screwdrivers. An analogy with natural languages would be a better one. Do we really need 5,000 natural languages or would one do just as well? If English is missing the words needed for space travelers, should we design a whole new language for space travelers or should we just add the appropriate words to English? Or consider mathematical notations. There once were several different notations for algebra, trigonometry and calculus, but standardizing the notations has helped mathematicians communicate their ideas. Sometimes different fields use the same symbols to mean different things, but this works like scoping rules in a programming language. In different scopes the same symbol can refer to different procedures. A set of mathematical techniques used only by a particular field can be compared to a package of procedures used only at a particular installation. Instead of comparing a programming language to a vaccine, it could be compared to a pharmacy, and one would hope that one's pharmacy stocks all the necessary vaccines. Or one could view a programming language as a toolmaker that can make both screwdrivers and hammers. It may not be possible to devise a universal programming language, but a comparison with vaccines is a poor analogy.
g-rh@cca.CCA.COM (Richard Harter) (02/07/88)
In article <5015@watdragon.waterloo.edu> djsalomon@watdragon.waterloo.edu (Daniel J. Salomon) writes: > >An analogy with natural languages would be a better one... Permit me to intrude with a point here. Computer languages are not languages in the sense that natural languages are languages. Computer 'languages' are really more like recipes for languages. If you look at a natural language such as English, you see that it has a grammar, certain rules of usage and style, etc. You also see a dictionary with thousands of defined words. When I use a natural language I may have to create a special term now and then, but, for the most part I use the same vocabulary that every one else uses. Computer 'languages' are like natural languages with all of the vocabulary stripped out, except for those few words needed to implement the grammar. When one writes a computer program one spends a fair bit of time simply defining the terms that will be used in the program. Each program is a separate language. If people used natural languages the way they use computer languages, any time some wanted to write a book they would first have to write the dictionary to be used in the book. One can envision the following scheme. Language X comes with both a grammar and a dictionary. The dictionary has a large number of things defined in it with complete definitions. For a simple example, i might be defined as an integer used as an index with scope restricted to the block that it is in. Programs in language X have no declarations at all. The compiler for language X does not build a symbol table -- it takes its symbol table from the dictionary. [Naturally there would be provisions for extending the dictionary and for adding additional special purpose dictionaries.] The interesting thing about language X is that all of the programs written in language X share the same vocabulary. In the current fashion in computer languages, each program has its own vocabulary, except insofar as usage is repeated from one program to the next. It does remind one of the tower of Babel, doesn't. This might be a good thing to do. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
djsalomon@watdragon.waterloo.edu (Daniel J. Salomon) (02/08/88)
In article <24112@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: >In article <5015@watdragon.waterloo.edu> djsalomon@watdragon.waterloo.edu (Daniel J. Salomon) writes: >> >>An analogy with natural languages would be a better one... > > Permit me to intrude with a point here. Computer languages >are not languages in the sense that natural languages are languages. But you have to admit that computer languages are more like natural languages than they are like vaccines. That is all I said.
g-rh@cca.CCA.COM (Richard Harter) (02/09/88)
DJ: Daniel J. Salomon RH: Richard Harter DJ: An analogy with natural languages would be a better one... RH: Permit me to intrude with a point here. Computer languages RH: are not languages in the sense that natural languages are languages. DJ: But you have to admit that computer languages are more like DJ: natural languages than they are like vaccines. That is all I said. Well, I wasn't disagreeing -- I was somewhat changing the subject. My point was that it might be profitable to deal with computer languages as though they were natural languages and that, in the same way that natural languages have a large predefined vocabulary of nouns and verbs, so would a computer language. I am not so sure that I understand what it means to compare computer languages to vaccines. I suppose it might be something like this. This of a problem to be solved as an alien irritant in the body. The computer language is analogous to the immune system. The program is the antibody constructed in response to the problem. The nice thing about this analogy is that it implies that each program is an idiosyncratic response to each individual problem. This does seem to correspond depressingly well to the way programs are actually written. I think, however, that the analogy breaks down, because the function of the antibody is to identify the irritant, capture it, and pass it on to be destroyed. The essential function here is a general purpose mechanism of differentiation. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
lee@uhccux.UUCP (Greg Lee) (02/12/88)
From article <5028@watdragon.waterloo.edu>, by djsalomon@watdragon.waterloo.edu (Daniel J. Salomon): > ... > But you have to admit that computer languages are more like > natural languages than they are like vaccines. That is all I said. This is tangential, but natural languages are maybe something like vaccines. One current theory of syntax, arc pair grammar, describes languages as sets of contraints (antibodies?) on sentence structure. That is to say, a grammar characterizes the complement of the permissible sentences. (Good health is the absence of disease.) Greg, lee@uhccux.uhcc.hawaii.edu
djsalomon@watdragon.waterloo.edu (Daniel J. Salomon) (02/15/88)
In article <1566@uhccux.UUCP> lee@uhccux.UUCP (Greg Lee) writes: >From article <5028@watdragon.waterloo.edu>, by djsalomon@watdragon.waterloo.edu (Daniel J. Salomon): > > ... > > But you have to admit that computer languages are more like > > natural languages than they are like vaccines. That is all I said. > >This is tangential, but natural languages are maybe something like >vaccines. One current theory of syntax, arc pair grammar, describes >languages as sets of contraints (antibodies?) on sentence structure. >That is to say, a grammar characterizes the complement of the >permissible sentences. (Good health is the absence of disease.) It seems to me that you are comparing natural language to the human immune system, not to a vaccine. A vaccine is a virus or bacteria look-alike that stimulates the natural defense mechanism of the body. Antibodies are created by the body, they are NOT contained in the vaccine. While it may be fun stretching the imagination to find similarities between languages and vaccines, hammers, screwdrivers, or duck-billed platypuses, I don't think it is a sound basis on which to build a language design.