ted@grebyn.com (Ted Holden) (06/03/90)
Sorry to be a while getting back. Several people posted articles indicating they had no idea WHY tasking as a language feature is a bad idea. 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. 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. Then, you will have the enviable task of approaching some gentleman with stars on his shoulders (or, worse, a committee), and explaining to him/them why you need Ada/Ada9x changed again, and he/they'll reply "No problem at all, babe; give us about ten years. Don't call us, we'll call you." Your friend Al, of course, working on a similar problem in private industry, will simply write up a slightly different version of some Pascal or C++ tasking library. Probably take him about 2 weeks. Ted Holden HTE
vladimir@prosper (Vladimir G. Ivanovic) (06/04/90)
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