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=2.1 required=5.0 tests=BAYES_05,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!sun-barr!newstop!sun!prosper From: vladimir@prosper (Vladimir G. Ivanovic) Newsgroups: comp.lang.ada Subject: Re: Why tasking in a language is such a bad idea Message-ID: <136570@sun.Eng.Sun.COM> Date: 3 Jun 90 21:05:56 GMT References: <20097@grebyn.com> Sender: news@sun.Eng.Sun.COM Reply-To: vladimir@prosper (Vladimir G. Ivanovic) Organization: sun In-reply-to: ted@grebyn.com (Ted Holden) List-Id: In article <20097@grebyn.com>, ted@grebyn (Ted Holden) writes: >Sorry to be a while getting back. Actually, most of us are sorry it was so soon! (I couldn't resist... You left yourself wide open with that one!) >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? 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? Occam, CSP and and a variety of Lisps include tasking. Why do you think all these different language designers have included tasking? >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. Reserve Ada for those applications where programming in Ada provides benefits compared to the alternatives. In general, these are large, embedded, real-time applications. >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? You may have an argument, but you've thrown the baby out with the bath water. As it stands, the logical conclusion of your argument is a language with NO constructs! The rest of your posting did not contain any reasoning that I could discern. Cheers, -- Vladimir Vladimir G. Ivanovic vladimir@sun.com M/S 12-33 vladimir@prosper.ebb.eng.sun.com Sun Microsystems, Inc. vivanovic@sun.com 2550 Garcia Ave. Mountain View, CA 94043-1100 (415) 336-2315 -- Vladimir G. Ivanovic vladimir@sun.com M/S 12-33 vladimir@prosper.ebb.eng.sun.com Sun Microsystems, Inc. vivanovic@sun.com