ted@grebyn.com (Ted Holden) (06/04/90)
From: Vladimir G. Ivanovic, Sun >>Several people posted articles >>indicating they had no idea WHY tasking as a language feature is a bad >>idea. >I posted a response, and I gave three or four reasons. You have not replied >to any of them. Why not? Because none of them is important in comparison with the problem I mentioned. >Another person you might consider talking to is Narain Gehani of AT&T Bell >Labs. He is a principle designer of Concurrent C/C++, which has just been >released for research use. Tasking, naturally, is included as a feature of >the language. He might have had some reasons for including tasking. Do you >know what they are? Yes. He is misguided. Stroustrup and others there are on record as being opposed to the idea. >Occam, CSP and and a variety of Lisps include tasking. Why do you think all >these different language designers have included tasking? The authors are misguided, but even so, none of the languages you mention are the end-all-be-all languages that Ada in meant to be. Changing a language spec or constructing a new variant would be FAR less hassle with any of these than with Ada, hence the damage is far less. >>There are several reasons, all of them good. For one thing, it's >>a lot of dead weight to be carrying around for an application which >>doesn't need it. >There are two pretty obvious responses to this objection, both of them >convincing. (1) It's an implementation issue, not a language design issue. >Why can't a compiler, in principle, simply leave out the tasking part if it's >not used? (2) Use a different language. Neither Ada nor your favorite >language is the perfect language for every application. If you don't need >tasking, and your Ada compliler insists on including a lot of extra baggage, >use a different language. 1. Ada versions which I've seen leave out nothing; small programs compile to several hundred K bytes. My understanding has always been that this is required by the nature of the language. 2. I know that. You know that. But does DOD know that? Ada has been officially mandated for everything and everybody. >Reserve Ada for those applications where programming in Ada provides benefits >compared to the alternatives. In general, these are large, embedded, >real-time applications. Check out the 750 "problems" listed on the AdaWoe bulletin board. A great many of them involve real life experiences of people trying to use Ada on real-time systems. Fun reading. >>But the chief one is this: No matter how you define >>it, two years later, there will be an application/hardware platform for >>which the two year old tasking model just won't work. If past >>experience is any guide, it will actually be two MONTHs later. >Let me understand your argument here: Because tasking will change as people >learn, we shouldn't include tasking in a language. OK, but why isn't this >argument applicable to typing, loop constructs, procedure call interfaces, or >any other language design feature? No. The things you mention can easily be written up to work for any and all applications for all time, as they function in C and Pascal. The whole point was that a library is FAR easier to modify than a political- football/white-elephant/sacred-cow is. Ted Holden HTE
diamond@tkou02.enet.dec.com (diamond@tkovoa) (06/04/90)
I can't believe that my first post to comp.lang.ada is a follow-up to T _ _ to _ _ _ _ _ I can't say it. Anyway, In article <20104@grebyn.com> ted@grebyn.com (Ted Holden) writes: >The >whole point was that a library is FAR easier to modify than a political- >football/white-elephant/sacred-cow is. Do you mean the way printf() and scanf() have had their syntax improved? Do you mean the way gets() was deleted entirely, or at least had the size parameter added? Libraries are easier to fix in theory, but not in the real world. Tasking is the I/O of the 90's. Its specs still aren't debugged, but it's close enough to belong in programming languages, and laughable to exclude it. -- Norman Diamond, Nihon DEC diamond@tkou02.enet.dec.com Proposed group comp.networks.load-reduction: send your "yes" vote to /dev/null.
sampson@cod.NOSC.MIL (Charles H. Sampson) (06/05/90)
In article <20104@grebyn.com> ted@grebyn.com (Ted Holden) writes: > >Check out the 750 "problems" listed on the AdaWoe bulletin board... > I case anyone is being misled by the repeated references to Ada's "750 problems", these are the unfiltered "problems" submitted during the 9X comment period. There is much duplication and overlapping among them. For example, one subject that I'm particularly interested in is the subject of approximately 10 of these revision requests. Others can be questioned as to their appropriateness, such as a request for a standard way to access command line parameters. (Not all operating systems use command line parameters.) In short, after allowing the world to submit revision requests for Ada-9X, the number of actual issues that resulted is substantially less than 750. Charlie Sampson, CSC
kt4@prism.gatech.EDU (Ken Thompson) (06/05/90)
In article <1930@cod.NOSC.MIL> sampson@cod.nosc.mil.UUCP (Charles H. Sampson) writes: >In article <20104@grebyn.com> ted@grebyn.com (Ted Holden) writes: >> >>Check out the 750 "problems" listed on the AdaWoe bulletin board... >> > I case anyone is being misled by the repeated references to Ada's >"750 problems", these are the unfiltered "problems" submitted during >the 9X comment period. There is much duplication and overlapping among >them. For example, on >Charlie Sampson, CSC I am not a fanatic on either side of the Ada language issue. I like most all of what they tried to do with it. I don't really like how some turned out. I would say that 750 unfiltered problems/wish lists/etc is a relatively small number. I wonder how many of these types of things the ANSI C committee had to wade through. My impression was a whole lot. Ken -- Ken Thompson GTRI, Ga. Tech, Atlanta Ga. 30332 Internet:!kt4@prism.gatech.edu uucp:...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!kt4 "Rowe's Rule: The odds are five to six that the light at the end of the tunnel is the headlight of an oncoming train." -- Paul Dickson