From: ted@grebyn.com (Ted Holden)
Subject: Re: tasking in language a bad idea
Date: 4 Jun 90 02:42:48 GMT [thread overview]
Message-ID: <20104@grebyn.com> (raw)
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
next reply other threads:[~1990-06-04 2:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1990-06-04 2:42 Ted Holden [this message]
1990-06-04 8:30 ` tasking in language a bad idea diamond@tkovoa
1990-06-04 16:31 ` Executible Program size (was Re: tasking in language a bad idea) Andy DeFaria
1990-06-04 18:25 ` tasking in language a bad idea Charles H. Sampson
1990-06-04 21:26 ` Ken Thompson
1990-06-04 19:22 ` Executible Program size (was Re: tasking in language a bad idea) Paul A. Varner
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox