Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!kth.se!sunic!mcsun!ukc!mucs!logitek!hrc63!mrcu!paj From: paj@mrcu (Paul Johnson) Newsgroups: comp.object Subject: Re: Syntax Change Not Paradigm Shift Message-ID: <902@puck.mrcu> Date: 16 Apr 91 10:40:24 GMT References: <47.UUL1.3#913@acw.com> Reply-To: paj@uk.co.gec-mrc (Paul Johnson) Organization: GEC-Marconi Research Centre, Great Baddow, UK Lines: 120 In article <47.UUL1.3#913@acw.com> scott@acw.com (Scott Guthery) writes: >Sorry, Jargonauts, a syntax change is not a paradigm shift. There is nothing >- I repeat, nothing - new in object-oriented programming save a lot of >obfuscating New Age Babel [sic]. A syntax change is not a paradigm shift. A paradigm shift is not a syntax change. As has been noted in previous articles here, what is new in OO programming is the paradigm rather than the *semantic* constructs that support it. The assertion that things like dynamic binding are purely syntactic is bogus. It is trivially true that both COBOL and Eiffel are turing-complete and therefore equivalent from the mathematical point of view, but I know which one I would rather program in. >The decennial syntax changes characteristic of non-commercial >programming insure full employment for otherwise useless coders who >have run out of new ideas but seek to remain employed in >monkey-at-the-typewriter rewriting of old ones. I am not quite sure whether to take this conspiracy theory seriously. Mr Guthery, do you mean this as a joke or do you actually believe in a sinister conspiracy of computer programmers trying to ensure job security? If the latter, I can prove that they are connected with they Illuminati of Baveria and assasinated President Kennedy in order to gain control of the initial attempts to define Ada. >Every routine in the NIH C++ Class Library can be found in assembly language >libraries (for every machine you care to name), Fortran libraries (Fortran I, >II, III, IV, DEC, IBM, etc.), C libraries (AT&T, BSD, Sun, HP, Mach, Next, >Xenix, etc.), Pascal libraries (ISO, Turbo, DEC, etc.), PL/I libraries (IBM, >Unisys, Standard), Lisp libraries (east coast, west coast, Common, Portable, >E, etc.), and Basic libraries (True, Microsoft, HP, etc.). Its been a while since I dug through the NIH libraries, but as I recall it implemented common data types like linked lists, sets, dictionaries etc. If this is the case, why did every C program I wrote seem to include yet another hand-crafted linked-list? Was it just out of ignorance? Perhaps you could point me to some of these wonderful libraries? I may have to write in C again some day (shudder) and would like it to be as easy and flexible as Eiffel. BTW, the X window widgets (starting with the Xt library) are an attempt to gain the benefits of OO while staying in C. The result is unusually flexible (because they used OO) and incredibly hairy (because they did it in C). >And I'll bet I can find them in Eiffel libraries, Objective-C >libraries, Common Loops libraries, and Smalltalk libraries (Xerox, >Digitalk, Tektronix, etc.). Yup, the first thing any OO language needs is a set of library classes for that language. Why is this a bad thing? >It constantly amazes me that they continue to pay us for this text >mongering and it embarrasses me that we accept the money. It constantly amazes me that someone continues to pay you for this flame mongering and it embarrasses me that you accept the money. >In the commercial realm where real computing is done and where the vast >majority of both the cycles and the dollars of computing are found, one >doesn't find this mindless pursuit of endless transliteration. COBOL is >sufficient and has been for years. There is, you see, a real job to get >done. By `real computing' you seem to mean problems which are well understood and can be completely specified in advance. That is all that COBOL is good for. The commercial shops you admire so much get the job done by throwing programmers at the problem. Outside the code grinding world, where requirements change and flexibility is important, COBOL is almost unused, and this is because it cannot be used effectively. >Sooner or later people who have had experience with and understand software >will become general managers. Their memory of software trends will be longer >than the current generation of general managers. They will remember the >promises of high level languages, structured programming, subroutine >libraries, portability, artificial intelligence, and modular programming. >They will see through the smoke and recognize the same old scam dressed up in >a new vocabularly. And they will say, "Prove it." Then we'll be really >stuck. You seem to have a fundemental misunderstanding of the way computer languages have developed. Your argument seems to be that SLOC/day productivity seems to be about the same no matter what kind of language is used (you did not say that, but it has been noted elsewhere, and higher productivity is the promise of just about everything). We are still having projects come in over budget and behind schedule (which is what managers try to prevent). Portability is still a problem. Therefore HLLs were not an improvement over machine code, and that similarly OOLs are not an improvement over HLLs. This is bogus. Today we can tackle programming projects of a complexity undreamed of twenty years ago. Just as improvements in computer storage and speed have been utilised so that people are still screaming for faster, bigger, cheaper computers, so the improved complexity management of computer languages has been utilised so that people still want systems to manage more and more complexity. No matter what else happens, people will still want to push the outer limits of complexity management and build more and more complicated systems. >But we did give ample warning, didn't we? Always, always beware of a field of >endeavor that feels it must put "science" in its name: political science, >social science, computer science. At University I was in the Computing Maths dept, and my degree is in `Computing Systems'. Whats in a name? Paul. -- Paul Johnson UUCP: !mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@gec-mrc.co.uk | Fax: +44 245 75244