carroll%seatac@BOEING.COM (Jeff Carroll 544-6349) (09/10/88)
In article <525@accelerator.eng.ohio-state.edu> accelerator.eng.ohio-state.edu!kaa.eng.ohio-state.edu! rob@tut.cis.ohio-state.edu (Rob Carriere) writes: >In article <4203@adobe.COM> burgett@steel.UUCP (Michael Burgett) writes: >> [ C is not a numerical language, fortran is, so ] >>just face it, to program effectively >>you just might have to learn more than one language.... (shock! disbelief!!) > >And having done so, you might then find that there is a language that >does almost everything you want, could do everything you want with >*only small changes*, and is already better than anything else around. >Can you blame people for then trying to get these minor changes done? >I am not talking about anything like a PL/1 syndrome, because I like C >for its simplicity, and I'd much rather do some work than have the >language bloated, but there are a couple of minor changes that would >greatly improve the utility of C in the numerical field. > >Rob Carriere >Face it, C is just to damn *_GOOD_* for you systems guys to keep it >all to yourselves... :-) In the beginning, scientists were the only people who had computers, and the only people who programmed them. Then they had languages like FORTRAN and ALGOL; admittedly crude, but that was at least in part because the scientists/programmers had other, more important applications to worry about - their applications. Then people started using computers for financial applications, and there were languages like COBOL. Those were crude too, but that was also because the people inventing the tools had their application in mind, and because the art of programming a computer was still in its infancy. As that art grew more and more sophisticated, people started to devote more and more time and energy to it, and then came people who spent ALL their time doing it: the computer scientists. Soon there were university programs in computer science, and then sub-specialties within computer science. Which brings us to the systems programmer. The systems programmer is a specialist in making a sophisticated machine tractable to users. Systems programmers gave us C, and many of us are grateful to them for it. But now people like Mr. Burgett are making mutiny on the ship of computation. Having forgotten that the operating system exists for the benefit of the user, they operate under the illusion that operating systems, systems programming, and the tools of the systems craft exist for their own sake, and they are telling us users to butt out, as if we were trespassing on someone else's property. Someday, maybe we will have concert halls and arenas where people will go to watch and applaud performances by systems programmers, which might be funded by the Ford Foundation, or the National Endowment for the Humanities. Until then, though, we all have work to do, and systems programmers might be well advised to swallow their pride and give their customers what they want. Jeff Carroll Electromagnetics Staff Boeing Advanced Systems Box 3707, MS 4C-01 Seattle 98124 (206)544-6349 carroll%seatac@boeing.com 8524622@uwav1.bitnet
gwyn@smoke.ARPA (Doug Gwyn ) (09/20/88)
In article <8809092242.AA20696@BOEING.COM> carroll%seatac@BOEING.COM (Jeff Carroll 544-6349) writes: >... give their customers what they want. [Presumably "they" means "the customers".] The above policy tends to produce products that are not in the customers' genuine best interests. What the customers think they want and what they would rationally desire if they were better informed are seldom the same thing. A major part of the system analyst's job is to help customers identify their actual requirements and to evaluate how well various alternative proposed solutions meet their actual (long-term) needs. I don't know how this relates to use of C for numerical programming other than that what a Fortran programmer thinks is essential may very well not be, in another programming language.
rob@kaa.eng.ohio-state.edu (Rob Carriere) (09/20/88)
In article <8537@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <8809092242.AA20696@BOEING.COM> carroll%seatac@BOEING.COM (Jeff Carroll 544-6349) writes: >>... give their customers what they want. >[Presumably "they" means "the customers".] That's what the grammar says (most recent applicable entity). >The above policy tends to produce products that are not in the >customers' genuine best interests. [ system analists are necessary ] > [ C is not FORTRAN, so sys ana's, not F programmers should look at > features ] Marvelous. Now how does this answer the complaint that those helpful, friendly, necessary system people are 1) telling numerical people to f*** off, and 2) on their more polite days not displaying any interest in the needs of numerical programmers? And then I seem to detect a assert( num_programmer == fortran_programmer ) somewhere in your code. Slight prejudice? Rob Carriere
burgett@steel.COM (Michael Burgett) (09/20/88)
In article <8809092242.AA20696@BOEING.COM> carroll%seatac@BOEING.COM (Jeff Carroll 544-6349) writes: | As that art grew more and more sophisticated, people started to |devote more and more time and energy to it, and then came people who spent |ALL their time doing it: the computer scientists. Soon there were university |programs in computer science, and then sub-specialties within computer science. and then there was light.... | Which brings us to the systems programmer. The systems programmer |is a specialist in making a sophisticated machine tractable to users. Systems |programmers gave us C, and many of us are grateful to them for it. ^^^^^^^^^ Hmmm, all the lore I've read, and been told tells of C evolving as a tool used for systems programming, that being what it was intended and designed to do (and does quite wonderfully I might add...) | But now people like Mr. Burgett are making mutiny on the ship of |computation. Having forgotten that the operating system exists for the benefit |of the user, they operate under the illusion that operating systems, systems |programming, and the tools of the systems craft exist for their own sake, ^^^^^^^^^^^^^^^^^^^^^^^^ |and they are telling us users to butt out, as if we were trespassing on |someone else's property. Yes they do justify their own existence, Un*x would not have been ported to so many platforms, nor be as popular as it is today if it had not been written in C. Do you want to change yacc and lex all around too since you seem to feel that it's wrong to have tools dedicated to doing one job well instead of many mediorce? | Someday, maybe we will have concert halls and arenas where people |will go to watch and applaud performances by systems programmers, which |might be funded by the Ford Foundation, or the National Endowment for the |Humanities. Until then, though, we all have work to do, and systems programmers |might be well advised to swallow their pride and give their customers what |they want. Flames to you too buddy. My original posting (albeit, I do tend to have a rather large sarcastic streak) was intended to point out that "fixing" C at expense of what it was intended to do is a mistake and should be avoided, look to other languages that are good at specific things, and use them at what they are best designed for. 'Tis a poor programmer indeed that only has one tool in his toolbox. The role of ANSI is not to extend and enhance, but to standardize current practice, and you don't do that by inventing things that don't currently exist in the language. As far as I'm concerned, "fixing" a working compiler, used by as many people as C, should be done just as one would attempt to pet a lion -- very carefully. --Mike Burgett adobe!burgett@decwrl.dec.com "Squid and red bean stew served daily..." "Obviously, *noone* share my opinions, so why should my employer?" :')
gwyn@smoke.ARPA (Doug Gwyn ) (09/21/88)
In article <615@accelerator.eng.ohio-state.edu> rob@kaa.eng.ohio-state.edu (Rob Carriere) writes: >Marvelous. Now how does this answer the complaint ... First of all, don't replace my words with your mistaken summary of them (the "[...]" stuff you put under my attribution in your response). Next, the relevance of my comment was that many things various members of the "numerical programming community" have said they need to be added to C are not in fact necessary and some of them would be a bad idea for the language as a whole. Some of the requests are reasonable, and some have in fact been acted on by X3J11. The one system programmer who suggested that C should only be used for system programming, that prompted your initial response, certainly does not speak for the entire C community. In fact I do a large amount of numerical programming in C.
henry@utzoo.uucp (Henry Spencer) (09/22/88)
In article <8809092242.AA20696@BOEING.COM> carroll%seatac@BOEING.COM (Jeff Carroll 544-6349) writes: >... Until then, though, we all have work to do, and systems programmers >might be well advised to swallow their pride and give their customers what >they want. Systems programmers are, by and large, in the business of giving the customers what they want. ANSI standards committees, however, are not. Sensible standards committees focus on standardizing existing, well-proven practice, not on redesigning the language to try to make everybody happy. The two groups are complementary. If you do not like the way C is now, ask your systems programmers -- or the ones at your compiler supplier -- to give you something closer to your needs. After getting what you think you need, and using it for a couple of years, you will be in a much better position to propose it (or, more likely, some debugged variant of it) to a standards committee. -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
nather@utastro.UUCP (Ed Nather) (09/25/88)
In article <1988Sep22.163950.13700@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > Sensible standards committees focus on standardizing existing, well-proven > practice, not on redesigning the language to try to make everybody happy. True. Look how thoroughly trigrams were proven before they were included in the new ANSI standard for the C language. -- Ed Nather Astronomy Dept, U of Texas @ Austin {backbones}!{noao,ut-sally}!utastro!nather nather@astro.as.utexas.edu
gwyn@smoke.ARPA (Doug Gwyn ) (09/25/88)
In article <3162@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: >In article <1988Sep22.163950.13700@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: >> Sensible standards committees focus on standardizing existing, well-proven >> practice, not on redesigning the language to try to make everybody happy. >True. Look how thoroughly trigrams were proven before they were included >in the new ANSI standard for the C language. First, please note that there is NOT an ANSI standard for the C language. Next, trigraphs were indeed an attempt to make someone (Europeans) happy, and they have failed miserably to do so, which reinforces Henry's point. X3J11 will have to decide whether or not trigraphs, some alternative similar facility, or no such facility will be in the next draft of the proposed ANS for C. There are pending public review comments on this.
nather@utastro.UUCP (Ed Nather) (09/26/88)
In article <8578@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: > >In article <1988Sep22.163950.13700@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > >> Sensible standards committees focus on standardizing existing, well-proven > >> practice, not on redesigning the language to try to make everybody happy. > > X3J11 will have to decide whether or not trigraphs, some alternative > similar facility, or no such facility will be in the next draft of the > proposed ANS for C. There are pending public review comments on this. If they follow Henry's excellent advice, "no such facility" is the only choice. There is no "well-proven practice" to standardize. -- Ed Nather Astronomy Dept, U of Texas @ Austin {backbones}!{noao,ut-sally}!utastro!nather nather@astro.as.utexas.edu
henry@utzoo.uucp (Henry Spencer) (09/28/88)
In article <3162@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: >> Sensible standards committees focus on standardizing existing, well-proven >> practice, not on redesigning the language to try to make everybody happy. > >True. Look how thoroughly trigrams were proven before they were included >in the new ANSI standard for the C language. Yeah, and they've turned out to be a mess and a major problem. I didn't say that X3J11 was entirely sensible! It can, however, be much worse -- sometimes a standards committee really gets the bit between its teeth. Look at ANSI Basic. (To quote Mike O'Dell: "my goodness, the little munchkins on that committee were busy!") X3J11's attempts to invent things have been relatively infrequent, especially if one stretches the rule a little and allows C++ experience to count as C experience. (Bear in mind that there are more C compilers in the world than just PCC, and a number of innovative-looking things in the X3J11 drafts actually have been tried in one compiler or another.) -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.ARPA (Doug Gwyn ) (10/03/88)
In article <1988Sep27.173354.16502@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: [Re: trigraphs] >Yeah, and they've turned out to be a mess and a major problem. Actually there are no known *technical* problems with trigraphs. The problems are all psychological and political. Basically, the introduction of trigraphs made it appear that X3J11 was trying to *completely* solve the host character representation issue. (Perhaps X3J11 indeed thought that it did, but if so it was mistaken.) This biased the understanding of people reviewing the early dpANSes, leading to unrealistic expectations, complaints, and suggestions that further complicated the situation. I believe that the decision to introduce the notion of "multibyte character sequences" was partially influenced by the trigraph precedent (mostly, however, by the fact that many vendors had already been trying to make something like MBCs work). A recent object from an ISO member shows that trigraphs are still causing confusion and undue expectations. Unless it is overridden during the forthcoming reviews, I plan to clarify just what trigraphs really do (vs. what can still be solved in other ways) in the committee responses to the third round of public comments. Once I have the explanation typed up, I'll try to remember to post it here.