From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_05,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ames!think!zaphod.mps.ohio-state.edu!rpi!uupsi!grebyn!ted From: ted@grebyn.com (Ted Holden) Newsgroups: comp.lang.ada Subject: Re: tasking in language a bad idea Message-ID: <20104@grebyn.com> Date: 4 Jun 90 02:42:48 GMT Organization: Grebyn Timesharing, Vienna, VA List-Id: 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