Re: tasking in language a bad idea

Re: tasking in language a bad idea

[Ted Holden]

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

Re: tasking in language a bad idea

[diamond@tkovoa]

I can't believe that my first post to comp.lang.ada is a follow-up
to T _ _    to  _ _ _ _ _   I can't say it.  Anyway,
In article <20104@grebyn.com> ted@grebyn.com (Ted Holden) writes:

>The
>whole point was that a library is FAR easier to modify than a political-
>football/white-elephant/sacred-cow is.

Do you mean the way printf() and scanf() have had their syntax improved?
Do you mean the way gets() was deleted entirely, or at least had the
size parameter added?
Libraries are easier to fix in theory, but not in the real world.

Tasking is the I/O of the 90's.  Its specs still aren't debugged,
but it's close enough to belong in programming languages, and
laughable to exclude it.

-- 
Norman Diamond, Nihon DEC     diamond@tkou02.enet.dec.com
Proposed group comp.networks.load-reduction:  send your "yes" vote to /dev/null.

Re: Executible Program size (was Re: tasking in language a bad idea)

[Andy DeFaria]

>/ hpclapd:comp.lang.ada / ted@grebyn.com (Ted Holden) /  7:42 pm  Jun  3, 1990 /

>>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.

HP's version of  Ada does  NOT include any of the  tasking support code for
any program that does not use any tasking constructs.  Thus is satisfies #1
and nullifies #2.   I suspect that many other  Ada compilers  also do this.
Perhaps earily versions of Ada compilers used to  leave it in.  When is the
last time that you have used an Ada compiler Ted?

Re: tasking in language a bad idea

[Charles H. Sampson]

In article <20104@grebyn.com> ted@grebyn.com (Ted Holden) writes:
> 
>Check out the 750 "problems" listed on the AdaWoe bulletin board...
>
     I case anyone is being misled by the repeated references to Ada's
"750 problems", these are the unfiltered "problems" submitted during
the 9X comment period.  There is much duplication and overlapping among
them.  For example, one subject that I'm particularly interested in is
the subject of approximately 10 of these revision requests.  Others can
be questioned as to their appropriateness, such as a request for a
standard way to access command line parameters.  (Not all operating
systems use command line parameters.)  In short, after allowing the
world to submit revision requests for Ada-9X, the number of actual
issues that resulted is substantially less than 750.

Charlie Sampson, CSC

Executible Program size (was Re: tasking in language a bad idea)

[Paul A. Varner]

In article <20104@grebyn.com> ted@grebyn.com (Ted Holden) writes:
>Yes.  He is misguided.... [Stuff Deleted]
> 
>The authors are misguided.... [Stuff Deleted]

First, What makes a person misguided?  Is it because he doesn't agree
with your views???  Let me know WHY they are misguided.

>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.

Secondly, this is a function of the COMPILER not the language.  I agree that
Ada compilers can be pretty lacking in features and pretty stupid.  However,
they are getting there.  Using the test that you posted earlier.  I compiled
"Hello, World" in Ada, C, and Pascal on my 286 machine using Janus Ada, Turbo
C, and Turbo Pascal.  All three executible files were in the same ballpark.
Here are the results in file size:

     Janus ada   : HELLO.COM - 7265 bytes
     Turbo C     : HELLO.COM - 6048 bytes
     Turbo Pascal: HELLO.EXE - 3296 bytes

I fail to see the several hundred K bytes that you mentioned above.

Paul Varner
pvarner@blackbird.afit.af.mil

Re: tasking in language a bad idea

[Ken Thompson]

In article <1930@cod.NOSC.MIL> sampson@cod.nosc.mil.UUCP (Charles H. Sampson) writes:
>In article <20104@grebyn.com> ted@grebyn.com (Ted Holden) writes:
>> 
>>Check out the 750 "problems" listed on the AdaWoe bulletin board...
>>
>     I case anyone is being misled by the repeated references to Ada's
>"750 problems", these are the unfiltered "problems" submitted during
>the 9X comment period.  There is much duplication and overlapping among
>them.  For example, on
>Charlie Sampson, CSC

I am not a fanatic on either side of the Ada language issue. I like most
all of what they tried to do with it. I don't really like how some turned
out. I would say that 750 unfiltered problems/wish lists/etc is a relatively
small number. I wonder how many of these types of things 
the ANSI C committee had to wade through. My impression was a whole lot.

				Ken


-- 
Ken Thompson  GTRI, Ga. Tech, Atlanta Ga. 30332 Internet:!kt4@prism.gatech.edu
uucp:...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!kt4
"Rowe's Rule: The odds are five to six that the light at the end of the
tunnel is the headlight of an oncoming train."       -- Paul Dickson