Why tasking in a language is such a bad idea

Why tasking in a language is such a bad idea

[Ted Holden]

 
 
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

Re: Why tasking in a language is such a bad idea

[Vladimir G. Ivanovic]

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