scott@acw.com (Scott Guthery) (04/14/91)
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]. 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. 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.). And I'll bet I can find them in Eiffel libraries, Objective-C libraries, Common Loops libraries, and Smalltalk libraries (Xerox, Digitalk, Tektronix, etc.). It constantly amazes me that they continue to pay us for this text mongering and it embarrasses me that we 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. 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. 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. Cheers, Scott +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+**+*+ "Education, which was at first made universal in order that all might be able to read and write, has been found capable of serving quite other purposes. By instilling nonsense, it unifies populations and generates collective enthusiasm." Bertrand Russell +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+**+*+
boissier@irisa.fr (franck boissiere) (04/15/91)
From article <47.UUL1.3#913@acw.com>, by scott@acw.com (Scott Guthery): > > 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.). And I'll bet I > can find them in Eiffel libraries, Objective-C libraries, Common Loops > libraries, and Smalltalk libraries (Xerox, Digitalk, Tektronix, etc.). It > constantly amazes me that they continue to pay us for this text mongering and > it embarrasses me that we accept the money. > Now we can have the an Idea of your ignorance. While you bet that what can be found in NIHCL might be found in Smalltalk and others, you'd better know what you try to speak about. NIHCL is derived from ideas of the Smalltalk classes. -- Franck BOISSIERE boissier@irisa.irisa.fr C.C.E.T.T. B.P. 59 boissiere@ccett.fr 35512 CESSON SEVIGNE CEDEX FRANCE
atherton@unixg.ubc.ca (Bruce Atherton) (04/16/91)
Of course there is nothing new in Object Oriented Programming that has not been done before. There is nothing new in most new ideas, it is the combination that makes the difference. Often the combination seems so obvious in hindsight that many feel sour grapes that they did not think of it first and downplay the significance of the idea. Since you think that "high level languages, structured programming, subroutine libraries, portability, artificial intelligence, and modular programming" are all scams, I suggest you go back to your Babbage Analytical Engine. After all, there is nothing new in computers that wasn't already available with that, was there. For myself, I am glad that laguages exist that explicitly aid me in writing programs the way I have always done. I don't have to try to warp the language to my style anymore. -- UBC Faculty of Law Artificial Intelligence Research (FLAIR) Project atherton@unixg.ubc.ca or | If John were me, and I were John, Bruce_Atherton@mindlink.UUCP | I shouldn't have these trousers on - A.A. Milne
paj@mrcu (Paul Johnson) (04/16/91)
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: <world>!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
johnson@cs.uiuc.EDU (Ralph Johnson) (04/17/91)
In article <47.UUL1.3#913@acw.com>, scott@acw.com (Scott Guthery) writes: After claiming that most class libraries are just reimplementations of the same old thing ... |> 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. This is not true. Most COBOL programs are just reimplementing what has been done hundreds of times before. Most COBOL programs are the usual accounting, inventory, and personel programs. For some reason, existing software never seems to be quite good enough, COBOL programmers prefer to write their own. That's not completely true; one of my friends is a customizer of a large personel program for universities, and he goes from one school to another customizing it. Thus, a number of schools bought the package instead of building their own. However, most COBOL programmers write the same sort of programs over and over. Class libraries for data structures are not really a good example of the power of object-oriented programming. However, they are simple and easy to implement, so lots of people do. A much better example is user interface systems, in particular the frameworks for drawing editors like Unidraw (part of InterViews).
jls@rutabaga.Rational.COM (Jim Showalter) (04/17/91)
>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. Indeed there is. And it's name is "maintenance". 70% of the effort devoted to software in this country is devoted to maintenance. 70% of the software in this country is written in COBOL. Thus, roughly HALF of all intellectual capital expended on software in this country is pissed down a rathole maintaining creaky old COBOL applications. From a business standpoint, this is unjustifiable. New languages and tools DO make a difference. >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. Indeed: "computer science" does have a sort of as-translated-from- the-Ukranian feel to it, akin to "performance art". That's why I'm a software engineer. -- * The opinions expressed herein are my own, except in the realm of software * * engineering, in which case I borrowed them from incredibly smart people. * * * * Rational: cutting-edge software engineering technology and services. *
hsrender@happy.colorado.edu (04/17/91)
In article <47.UUL1.3#913@acw.com>, scott@acw.com (Scott Guthery) writes: > 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. Yeah, when I was a boy we used to have to toggle switches on a com panel. Sure the machine was big, slow, cost millions of dollars, used up enormous amounts of electricity and generated enough heat to warm a football stadium, but we got the job done and we LIKED it! None of this namby-pamby RISC goobledy-floo, where you can wait a few seconds to see your compile finish. In my day, we used to go away for WEEKS because we knew the average turn-around time on a batch day was 3.5 days and the average availability of the machines was 18 hours out of 24. Most of us have to wear glasses now because of years squinting at hex dumps printed by a failing ribbon on a line printer that we had to keep running with wire and chewing gum. Most of us have the pallor of albino cave fish from years spent in climate controlled basements tending machines that cost 500 times as much as we made in a year. None of this simpering about how much my portable PC weighs or how much Sun raised its prices. In my day we used to thank GOD that we had a tool like COBOL, a language that had was supposed to be for humans and whose programs looked like assembly instructions for a Y-12 bidirectional wing-wang oscillator. These days you hear these whining wimps going on about "functional" languages and "logic programming" languages and "object-oriented" languages. Pfah! We had a real job to do and we didn't have any choice: we had to use COBOL because we had spent $50,000 on the compiler and it was the only language that run on our ancient, outmoded hardware supported and we had no money left after trying to maintain hundreds of thousands of lines of poorly written, poorly structured, non-portable code that cost us thousands of hours and dozens of burnt-out programmers. There was a real job to be done and we did it and WE LIKED IT!! hal.
jls@rutabaga.Rational.COM (Jim Showalter) (04/19/91)
When *I* was growing up, we would have KILLED to have a windowless cubicle in basement. We wrote all our code on the back of matchbooks stolen from trash cans, and we had to enter it by weaving our very own core BY HAND. I hear people complaining about how they had to toggle switches: we'd have KILLED to have switches.... Apologies to Monty Python. -- * The opinions expressed herein are my own, except in the realm of software * * engineering, in which case I borrowed them from incredibly smart people. * * * * Rational: cutting-edge software engineering technology and services. *