sommar@enea.se (Erland Sommarskog) (05/17/88)
Pam Arnold (pmjc@tut.cc.rochester.edu.UUCP) writes: >This one may beg the question, but if any shop is REALLY SERIOUS about >this sort of problem, why not switch to a more modern language, especially >one that is more tailored to the requirements of software engineering? For >example Modula-2 and Ada (no flames, just add your own to the list). Hear, hear! -- Erland Sommarskog Take C, a third class language ENEA Data, Stockholm and a C programmer, i.e. a third class programmer sommar@enea.UUCP => A ninth class program, a C program.
elg@killer.UUCP (Eric Green) (05/18/88)
in article <3292@enea.se>, sommar@enea.se (Erland Sommarskog) says: > Pam Arnold (pmjc@tut.cc.rochester.edu.UUCP) writes: >>This one may beg the question, but if any shop is REALLY SERIOUS about >>this sort of problem, why not switch to a more modern language, especially >>one that is more tailored to the requirements of software engineering? For >>example Modula-2 and Ada (no flames, just add your own to the list). Because some of us have performance guidelines to meet (like, it has to be finished calculating in 1/30th of a second, i.e. a video frame), and thus can't use something like Module-2 or Ada. Heck, some of us have to use ASSEMBLER! (YOU try processing an entire hi-res video frame... unless you want to go with expensive custom hardware...). Besides, every Ada compiler I've ever seen has been a pig that generated enormous code. Modula-2 would be a good choice, but on the machine I'm using, the "C" compiler generates decent code (ah, that good ole' register optimization parade!), and the only Modula-2 for that particular machine is buggy and doesn't allow access to the operating system (no marks against Modula-2, there... I've used a very good Modula-2 on a VAX... but we must admit that the availability of good Modula-2 compilers is limited). Choice of implementation language should have little effect upon software engineering of a product. The only exception is that there are paridigms reasonable in Lisp that you would never want to try in Fortran.... -- Eric Lee Green {cuae2,ihnp4}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 "Is a dream a lie that don't come true, or is it something worse?"
rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) (05/19/88)
In article <3292@enea.se>, sommar@enea.se (Erland Sommarskog) writes: > Pam Arnold (pmjc@tut.cc.rochester.edu.UUCP) writes: > >This one may beg the question, but if any shop is REALLY SERIOUS about > >this sort of problem, why not switch to a more modern language, especially > >one that is more tailored to the requirements of software engineering? For > >example Modula-2 and Ada (no flames, just add your own to the list). > > Hear, hear! Hear? Yeah, I would like to hear how Modula-2 is in any way an improvement over C. Ada you may have a case for; Modula-2 just seems like a re-write of Pascal -- an ideal language for toy program development. . . . . . . . -- | Ray Lubinsky, UUCP: ...!uunet!virginia!uvacs!rwl | | Department of BITNET: rwl8y@virginia | | Computer Science, CSNET: rwl@cs.virginia.edu -OR- | | University of Virginia rwl%uvacs@uvaarpa.virginia.edu |
pmjc@ur-tut (Pam Arnold) (05/20/88)
In article <2414@uvacs.CS.VIRGINIA.EDU> rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) writes: >In article <3292@enea.se>, sommar@enea.se (Erland Sommarskog) writes: >> Pam Arnold (pmjc@tut.cc.rochester.edu.UUCP) writes: >> >This one may beg the question, but if any shop is REALLY SERIOUS about >> >this sort of problem, why not switch to a more modern language, >> Hear, hear! > >Hear? Yeah, I would like to hear how Modula-2 is in any way an improvement >over C. >| Ray Lubinsky, UUCP: ...!uunet!virginia!uvacs!rwl | For many situations, Modula-2 is NOT an improvement over C. I am not claiming that it is an all-in-all 'better' language. It does, however, require the programmer to use the language 'as is', whereas the C preprocessor allows - some might say encourages - the programmer to virtually remake the language. The original point I was responding to had to do with the difficulties in creating and enforcing style rules in C environments; the relative merits of C *AS A LANGUAGE* are not at issue here. One advantage I will claim for Modula-2 (and for Pascal as well): I haven't seen any other languages in which algorithms may be expressed with such clarity - a terrific plus where maintenance is concerned.
nather@ut-sally.UUCP (Ed Nather) (05/20/88)
In article <2414@uvacs.CS.VIRGINIA.EDU>, rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) writes: > Hear? Yeah, I would like to hear how Modula-2 is in any way an improvement > over C. Ada you may have a case for [...] You might want to read Sir Anthony Hoare's critique of Ada (I don't have the reference at hand, but I still vividly remember its content). His main concern was that Ada was so large different programmers would learn different sub-sets, and would be unable to work on each other's code as a result. He felt only the most dedicated of programmers would ever learn all of it. Has this, in fact, happened? -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.AS.UTEXAS.EDU
markv@uoregon.uoregon.edu (Mark VandeWettering) (05/21/88)
In article <2096@ur-tut.UUCP> pmjc@tut.cc.rochester.edu.UUCP (Pam Arnold) writes: >For many situations, Modula-2 is NOT an improvement over C. I am not >claiming that it is an all-in-all 'better' language. It does, however, >require the programmer to use the language 'as is', whereas the C >preprocessor allows - some might say encourages - the programmer to >virtually remake the language. The original point I was responding to >had to do with the difficulties in creating and enforcing style rules >in C environments; the relative merits of C *AS A LANGUAGE* are not >at issue here. I see this criticism of C often. The preprocessor does indeed allow the programmer to "remake" parts of the language. Doing so however is generally considered VERY poor style. Uses of the cpp should be: 1. Have the benefits of inline code within the syntax of having a "function call". For example, wouldn't you rather see max(a,b) than (a>b)?a:b But we don't wish to have the overhead of a function call for something so trivial... I made extensive use of this to do vector operations in a raytracer I wrote. 2. Replace constants with a symbolic name, to allow reconfiguation quickly... 3. Hide awkward dereferencing of nested pointer structures, esp complicated unions.... >One advantage I will claim for Modula-2 (and for Pascal as well): I haven't >seen any other languages in which algorithms may be expressed with such >clarity - a terrific plus where maintenance is concerned. Sigh, I would say that personal preference is at least as important. Generally, I write some kind of very loose psuedocode when I wish to describe an algorithm. Also, it is not clear that imperative languages are the best language for understanding algorithms. Because of their inherently sequential structure, algorithms developped within a framework of imperative languages tend to not parallelize well. Functional or logic programming languages are seemingly much more "natural" to me, because they separate "what" needs be done from "how" it is to be done. mark vandewettering, more from the desk blotter of...
nevin1@ihlpf.ATT.COM (00704a-Liber) (05/24/88)
In article <2096@ur-tut.UUCP> pmjc@tut.cc.rochester.edu.UUCP (Pam Arnold) writes: >One advantage I will claim for Modula-2 (and for Pascal as well): I haven't >seen any other languages in which algorithms may be expressed with such >clarity - a terrific plus where maintenance is concerned. I have seen the algorithm for quick sort in a functional language and the n-queens problem solved in Icon using reversible assignment statements; these algorithms are expressed there much more clearly than in Modula-2. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
faustus@ic.Berkeley.EDU (Wayne A. Christopher) (05/25/88)
In article <2031@uoregon.uoregon.edu>, markv@uoregon.uoregon.edu (Mark VandeWettering) writes: > Uses of the cpp should be: > 3. Hide awkward dereferencing of nested pointer structures, > esp complicated unions.... Another use that's related to this is replacing things like for (ptr = stuff->things; ptr != NULL; ptr = ptr->next) with foreach_thing(stuff, ptr) This has the advantage of hiding the representation of the set, so that if you change it to a hash table or an array you needn't change all your code. I think it's pretty obvious what it does, even though it does modify the syntax. Of course, it goes without saying that #define WHILE(s) while (s) { #define ELIHW } is an evil thing... Wayne
gast@lanai.cs.ucla.edu (David Gast) (05/27/88)
In article <11671@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes: >You might want to read Sir Anthony Hoare's critique of Ada (I don't have the >reference at hand, but I still vividly remember its content). You might also want to remember that his reviews of Algol 68 were notorious for misreprenting the truth. For example, he would give an example of something that was terribly wrong with Algol 68; the only trouble was that his terrible example would be a syntactic error caught by the compiler. David Gast gast@cs.ucla.edu {ucbvax,rutgers}!ucla-cs!gast
ray@micomvax.UUCP (Ray Dunn) (06/02/88)
In article <12753@shemp.CS.UCLA.EDU> gast@lanai.UUCP (David Gast) writes: [In response to Ed Nather's reference to Tony Hoare] > >You might also want to remember that his reviews of Algol 68 were >notorious for misreprenting the truth. For example, he would give an >example of something that was terribly wrong with Algol 68; the >only trouble was that his terrible example would be a syntactic >error caught by the compiler. > Foul Play! Does "he would give an example" actually mean "he gave (one) example" or, as it implies, that he *habitually* did this. Notorious to whom? David Gast? A particular section of the profession? What are these examples? Can we please be given enough *real* information here to enable an *informed* conclusion to be drawn, and not just go off into the boonies with hearsay?? -- Ray Dunn. | UUCP: ..!{philabs, mnetor}!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090
steven@cwi.nl (Steven Pemberton) (06/08/88)
In article <12753@shemp.CS.UCLA.EDU> gast@lanai.UUCP (David Gast) writes: [In response to Ed Nather's reference to Tony Hoare] > > You might also want to remember that his reviews of Algol 68 were > notorious for misreprenting the truth. For example, he would give an > example of something that was terribly wrong with Algol 68; the > only trouble was that his terrible example would be a syntactic > error caught by the compiler. > In article <1090@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) replies: > Foul Play! > > Does "he would give an example" actually mean "he gave (one) example" or, as > it implies, that he *habitually* did this. No indeed, David Gast is right. Hoare's criticisms of Algol 68 were extremely misinformed and weren't confined to a single occurrence. In fact 'foul play' is exactly what I thought when I read his reports containing the misrepresentations (you must remember that at the time there were language wars going on, mostly three-pronged Pascal-Algol68-PL/I). As an example, he reported that at a conference someone asked if Algol 68 supported triangular arrays, and the reply came that not only did it support triangular arrays, but diamond shape, circular, or any other shape you liked. Hoare then mocked this, by saying that he didn't believe that there'd ever be an application that needed circular arrays. This annoyed me for two reasons. Firstly because I didn't see any reason to reject the idea of circular arrays just on Hoare's say so, but more importantly because of his suggestion that circular arrays were a feature of Algol 68, rather than an outcome of a general, and simple, mechanism (just as in Pascal, you can have arrays of arrays, but unlike Pascal, the bounds of the arrays can be determined at run-time, therefore two dimensional arrays can have any shape you want). On the other hand, I found that many of Hoare's remarks on Ada hit the mark. Steven Pemberton, CWI, Amsterdam; steven@cwi.nl (mcvax!steven.uucp old style).
ray@micomvax.UUCP (Ray Dunn) (06/21/88)
In article <12753@shemp.CS.UCLA.EDU> gast@lanai.UUCP (David Gast) writes: [In response to Ed Nather's reference to Tony Hoare] > > You might also want to remember that his reviews of Algol 68 were > notorious for misreprenting the truth... In article <1090@micomvax.UUCP> ray@micomvax.UUCP I replied: > Foul Play! > > Does "he would give an example" actually mean "he gave (one) example" or, as > it implies, that he *habitually* did this... In article <352@piring.cwi.nl> steven@cwi.nl (or try mcvax!steven.uucp) writes: >No indeed, David Gast is right. Hoare's criticisms of Algol 68 were >extremely misinformed and weren't confined to a single occurrence. > >As an example..... Steven's response partially provides the sort of examples that were missing from David Gast's diatribe and caused me to cry "Foul Play". I received private e-mail from Gast, which, to avoid accusations of lack of netiquette, I will not quote directly unless he cares to give his permission. However it did make passing references to certain orifices of my anatomy and suggested it was up to *me* to do the research to verify *his* unsubstantiated insults, thus showing a certain lack of understanding of due intellectual process. He did get his anatomy correct however, I do have such an orifice, though whether I use it for the same functions as he does, of course, I have no idea. Hoare, with whom I worked briefly in 1965-6 on an implementation of an Algol 60 compiler, was not, if *anything*, uninformed - biased perhaps, endowed with enthusiastic tunnel vision certainly, but definitely not uninformed. These "qualities" are reasonably common in major figures of academia and are often the very factors required to get new ideas through to the skeptical traditionalists. Although not not necessarily always correct, nor always to be condoned, these traits can be understood, and are often balanced by other redeeming factors. Unsubstantiated insults without quotations and verifiability are extremely easy to make, are *never* acceptable, and even if correct, still warrant the cry of "Foul Play"! It would be foolhardy to write off Tony Hoare's opinions and achievements out of hand, merely on the basis of a few flames in USENET. * Disclaimer: To hopefully avoid further pointless gutter-mail, I reserve the right to publish any e-mail received on this subject. -- Ray Dunn. | UUCP: ..!{philabs, mnetor}!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090