Ada Advocacy.

Ada Advocacy.

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

Hi everyone,

In the goal to boost the Ada  programming language, along with the making of
my website, I'm looking for either documents, or links to comparisons
between ada and other languages, description of Ada features that set it
apart from other languages, basically any kind of PR there is out there
about Ada.

If you can just give me URL to places that have this info so I can do a
research and create my own ada advocacy based on the results of my research.

Thanks in advance :-)

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs

Re: Ada Advocacy.

[Luke A. Guest]

On Tue, 26 Aug 2003 20:33:29 +0000, Stephane Richard wrote:

> Hi everyone,
> 
> In the goal to boost the Ada  programming language, along with the making of
> my website, I'm looking for either documents, or links to comparisons
> between ada and other languages, description of Ada features that set it
> apart from other languages, basically any kind of PR there is out there
> about Ada.

Not an URL, but something that I and other programmers have always wanted
to do in C/C++/etc. but cannot is the printing of names of variables ;-)

That's a damn nice debugging feature. It's been a while but I think it's
something like

declare
	test : Integer := 5;
begin
	-- I'm really unsure about the overloaded + operator here, like I said
	-- it's been a while (around 6 years!)
	Write test'Name + " = " + test;
end

should send "test = 5" to the console.

Something like that anyway ;-P Try doing that in C/C++ without a lookup
table :-(

Another thing that's really useful is being able to declare the range of,
say, an integer variable - and with bounds checking it gets caught at
compile & runtime (depending on whether it's accessed with a constant or
not).

The only downside to Ada is the amount of work that has to go into a
simple program just to dump out some text (not very good for beginners) to
the console.

Also meaningful names negates the need for the absolutely disgusting
hungarian notation.

I loved Ada at university and I'm really surprised that it's still not
really used as much as it should be.

Luke.

Re: Ada Advocacy.

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3188 bytes --]

"Luke A. Guest" <laguest@__n_o_s_p_a_m__abyss2.demon.co.uk> wrote in message
news:pan.2003.08.26.21.20.35.693597@__n_o_s_p_a_m__abyss2.demon.co.uk...
> On Tue, 26 Aug 2003 20:33:29 +0000, Stephane Richard wrote:
>
> > Hi everyone,
> >
> > In the goal to boost the Ada  programming language, along with the
making of
> > my website, I'm looking for either documents, or links to comparisons
> > between ada and other languages, description of Ada features that set it
> > apart from other languages, basically any kind of PR there is out there
> > about Ada.
>
> Not an URL, but something that I and other programmers have always wanted
> to do in C/C++/etc. but cannot is the printing of names of variables ;-)
>
> That's a damn nice debugging feature. It's been a while but I think it's
> something like
>
> declare
> test : Integer := 5;
> begin
> -- I'm really unsure about the overloaded + operator here, like I said
> -- it's been a while (around 6 years!)
> Write test'Name + " = " + test;
> end
>
> should send "test = 5" to the console.
>
> Something like that anyway ;-P Try doing that in C/C++ without a lookup
> table :-(
>
> Another thing that's really useful is being able to declare the range of,
> say, an integer variable - and with bounds checking it gets caught at
> compile & runtime (depending on whether it's accessed with a constant or
> not).
>
> The only downside to Ada is the amount of work that has to go into a
> simple program just to dump out some text (not very good for beginners) to
> the console.
>
> Also meaningful names negates the need for the absolutely disgusting
> hungarian notation.
>
> I loved Ada at university and I'm really surprised that it's still not
> really used as much as it should be.
>
> Luke.
>
Excellent input Luke,

Indeed, a language like Ada should be used alot more than what I'm seeing
today.  It's part of the goal of the website I'm creating, to promote Ada,.
so all the good sides like those you mentionned here are excellent points.
Oh and as for that one downside.  I dont recall ever reading anywhere that C
and C++ were a "beginner's" language ;-).

Even if things have changed today and they teach C/C++ in computer schools,
me I learned on Pascal, and the structure you needed to have in Pascal made
for very readable code.  Ada being a superset of Pascal, takes this easy
maintainability aspect of Pascal to the next level.  Making projects tha
much more easier to read and maintain.  It's definitaly not as cryptic as C
and C++ have the potential to be (believe me, I've seen C code that almost
made me wanna give up some important parts of my anatomy. ;-).  Since Ada
has a somewhat predefined if you will structure like you say, if the
variables are named reasonability clear, then it only makes the whole code
that much clearer and quicker to maintain.

Thanks again for the input.....and if, in the course of time, something else
pops in your head, let me know :-)....you and anyone else :-)...even little
things like what Luke said are quite important advantages to Ada.


-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs

Re: Ada Advocacy.

[Luke A. Guest]

On Tue, 26 Aug 2003 22:28:19 +0000, Stephane Richard wrote:

> Excellent input Luke,

Ta ;-)
 
> Indeed, a language like Ada should be used alot more than what I'm seeing
> today.  It's part of the goal of the website I'm creating, to promote Ada,.
> so all the good sides like those you mentionned here are excellent points.
> Oh and as for that one downside.  I dont recall ever reading anywhere that C
> and C++ were a "beginner's" language ;-).

Ah! But, the first program anybody will learn is the "hello world" program
in C & C++ this *is* easy:

printf("hello world\n");

or

std::cout << "hello world" << endl;

not that I said they were beginners languages though ;-/

the same isn't too easy with Ada IIRC. We had a package written by our
lecturers to give us easy access to the text IO functions.

> Even if things have changed today and they teach C/C++ in computer schools,
> me I learned on Pascal, and the structure you needed to have in Pascal
made

I learned C first, then m68k asm, then Pascal (which I don't like) then
C++ and then Ada (I did a bit of Java but not enough to learn it properly
- API wise).

> for very readable code.  Ada being a superset of Pascal, takes this easy
> maintainability aspect of Pascal to the next level.  Making projects tha
> much more easier to read and maintain.  It's definitaly not as cryptic as C
> and C++ have the potential to be (believe me, I've seen C code that almost
> made me wanna give up some important parts of my anatomy. ;-).  Since Ada

Yes, but once you've passed the struct/pointer parts of the learning
process, you've got C in hand.

> has a somewhat predefined if you will structure like you say, if the
> variables are named reasonability clear, then it only makes the whole code
> that much clearer and quicker to maintain.
> 
> Thanks again for the input.....and if, in the course of time, something else
> pops in your head, let me know :-)....you and anyone else :-)...even little
> things like what Luke said are quite important advantages to Ada.

I was wondering recently if variable function/procedure parameters can be
implemented in Ada (i.e. C's ...)? I have found this useful in C.

Luke.

Re: Ada Advocacy.

[Chad R. Meiners]

"Luke A. Guest" <laguest@__n_o_s_p_a_m__abyss2.demon.co.uk> wrote in message
news:pan.2003.08.26.21.20.35.693597@__n_o_s_p_a_m__abyss2.demon.co.uk...
> The only downside to Ada is the amount of work that has to go into a
> simple program just to dump out some text (not very good for beginners) to
> the console.

Really?  I think Put and Put_Line are really simple to use.  Most students I
TA'd at the intro level did not have problems with Ada.Text_IO.  I observed
that students had more difficulty at the intro level with C++ and std:cout.
However this was at a different university so all things were not equal.

-CRM

Re: Ada Advocacy.

[Anisimkov]

"Luke A. Guest" wrote in message

> That's a damn nice debugging feature. It's been a while but I think it's
> something like
>
> declare
> test : Integer := 5;
> begin
> -- I'm really unsure about the overloaded + operator here, like I said
> -- it's been a while (around 6 years!)
> Write test'Name + " = " + test;
> end
>
> should send "test = 5" to the console.

Luke,

What difference between
test'Name and just "test"
?

I see test'Name is just longer for a 3 characters.
Only goal for Test'Name would be compilation time checking.
I do not think that compilation time checking is so necessary for the debug
printing.

The good Ada feature for the debug purpose is an image of enumeration values.
But I do not think that we need image of the object names.

Re: Ada Advocacy.

[David Holm]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

I always found this page interesting: http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html
It shows people that Ada is being used commercial applications and that it is not a dead
language.

//David Holm

On Tue, 26 Aug 2003 20:33:29 GMT
"Stephane Richard" <stephane.richard@verizon.net> wrote:

> Hi everyone,
> 
> In the goal to boost the Ada  programming language, along with the making of
> my website, I'm looking for either documents, or links to comparisons
> between ada and other languages, description of Ada features that set it
> apart from other languages, basically any kind of PR there is out there
> about Ada.
> 
> If you can just give me URL to places that have this info so I can do a
> research and create my own ada advocacy based on the results of my research.
> 
> Thanks in advance :-)
> 
> -- 
> Stéphane Richard
> Senior Software and Technology Supervisor
> http://www.totalweb-inc.com
> For all your hosting and related needs
> 
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Ada Advocacy.

[Dmitry A. Kazakov]

On Wed, 27 Aug 2003 06:44:23 +0600, "Anisimkov" <anisimkov@yahoo.com>
wrote:

>The good Ada feature for the debug purpose is an image of enumeration values.
>But I do not think that we need image of the object names.

Especially because of:

declare
   X : Integer;
   procedure Foo (Y : Integer) is
   begin
       Put_Line (Y'Name);
   end Foo;
begin
   Foo (X); -- What will Foo output, "X" or "Y"?
end;

And in general any sort of identity, a name is one, for objects is a
dangerous thing, which should be avoided, if possible of course.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Ada Advocacy.

[Luke A. Guest]

On Wed, 27 Aug 2003 06:44:23 +0600, Anisimkov wrote:

> I see test'Name is just longer for a 3 characters.
> Only goal for Test'Name would be compilation time checking.
> I do not think that compilation time checking is so necessary for the debug
> printing.

An image of anything is useful.
 
> The good Ada feature for the debug purpose is an image of enumeration values.
> But I do not think that we need image of the object names.

As for enums being able to loop from enum'First to enum'Last is also cool.

Luke.

Re: Ada Advocacy.

[Rod Chapman]

> In the goal to boost the Ada  programming language, along with the making of
> my website, I'm looking for either documents

We have lots of publications about Ada and SPARK both from
conferences (Ada Europe, SigAda, ...) and journals
(IEEE Software, IEEE Transactions, CrossTalk, ...).  All
of them on www.sparkada.com

You should also link to CrossTalk's site probably - there
have been some good Ada-related articles there recently
(Peter Amey in March 2002, Richard Riehle more recently...)
see www.stsc.hill.af.mil

There are also some more Ada-related articles to come in 
CrossTalk I think - watch out for the November 2003 special
issue on real-time systems...
 - Rod, SPARK Team, Praxis Critical Systems

Re: Ada Advocacy.

[Warren W. Gay VE3WWG]

Luke A. Guest wrote:
> On Tue, 26 Aug 2003 22:28:19 +0000, Stephane Richard wrote:
...
> Ah! But, the first program anybody will learn is the "hello world" program
> in C & C++ this *is* easy:
> 
> printf("hello world\n");
> 
> or
> 
> std::cout << "hello world" << endl;
> 
> not that I said they were beginners languages though ;-/
> 
> the same isn't too easy with Ada IIRC. We had a package written by our
> lecturers to give us easy access to the text IO functions.

What is so difficult about:

    Put_Line("Hello World");

or even

    Ada.Text_IO.Put_Line("Hello World");

Even before you can do printf/cout, you have to #include some
header files. I fail to see the difficulty here >:-/
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ada Advocacy.

[Wes Groleau]

>>The good Ada feature for the debug purpose is an image of enumeration values.
>>But I do not think that we need image of the object names.

However, I could imagine the usefulness of something like

   pragma Debug_Output ( Debugging => true, Entity_Name );

where, if Debugging is false, does nothing, otherwise
prints something like

    Entity_Name => (something like Entity_Name'Img)
    at line 345 of filename.adb (line 37 of Package.SubProg)

-- 
Wes Groleau
Genealogical Lookups:  http://groleau.freeshell.org/ref/lookups.html

Re: Ada Advocacy.

[Luke A. Guest]

On Wed, 27 Aug 2003 12:15:34 -0400, Warren W. Gay VE3WWG wrote:

> What is so difficult about:
> 
>     Put_Line("Hello World");
> 
> or even
> 
>     Ada.Text_IO.Put_Line("Hello World");
> 
> Even before you can do printf/cout, you have to #include some
> header files. I fail to see the difficulty here >:-/

Ok, fair enough, but why would so many courses create their own child
packages for I/O? Does it not support printing of different types as
standard?

Luke.

Re: Ada Advocacy.

[Luke A. Guest]

On Wed, 27 Aug 2003 15:12:08 -0500, Wes Groleau wrote:

> 
>>>The good Ada feature for the debug purpose is an image of enumeration values.
>>>But I do not think that we need image of the object names.
> 
> However, I could imagine the usefulness of something like
> 
>    pragma Debug_Output ( Debugging => true, Entity_Name );
> 
> where, if Debugging is false, does nothing, otherwise
> prints something like
> 
>     Entity_Name => (something like Entity_Name'Img)
>     at line 345 of filename.adb (line 37 of Package.SubProg)

Actually, indirectly, you've also shown another example of a really cool
feature of Ada

function blah(a : Integer, b : Float) : Boolean;
...
blah(b => 1.0, a => 10);

It'd be so cool to be able to do this in other languages...

Luke.

Re: Ada Advocacy.

[Dmitriy Anisimkov]

"Luke A. Guest" <laguest@__n_o_s_p_a_m__abyss2.demon.co.uk> wrote in message
> > I see test'Name is just longer for a 3 characters.
> > Only goal for Test'Name would be compilation time checking.
> > I do not think that compilation time checking is so necessary for the
debug
> > printing.
>
> An image of anything is useful.

So, imagine that "Test" is a sintax for get image of name of variable Test.
You definately know the image of variable name when you are writting code.
That is becouse the construction Test'Name is not necessary.

Re: Ada Advocacy.

[Dmitry A. Kazakov]

On Wed, 27 Aug 2003 15:12:08 -0500, Wes Groleau
<groleau@freeshell.org> wrote:

>>>The good Ada feature for the debug purpose is an image of enumeration values.
>>>But I do not think that we need image of the object names.
>
>However, I could imagine the usefulness of something like
>
>   pragma Debug_Output ( Debugging => true, Entity_Name );
>
>where, if Debugging is false, does nothing, otherwise
>prints something like
>
>    Entity_Name => (something like Entity_Name'Img)
>    at line 345 of filename.adb (line 37 of Package.SubProg)

... instantiated at ...,
... with the parameters ...,
... the call stack is ...,
... during winding up the exception ...,
... raised in ... <substitute here the whole list again>,
... the current task is ...,
... invoked at ... (:-))

Almost forgot, I want to redirect debug info into a list box of a
window.
-------------------
I think that nothing can supersede a mature debugger (/=gdb), plus
carefully developed tracing tool integrated into the program.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Ada Advocacy.

[Preben Randhol]

Luke A. Guest wrote:
> Ok, fair enough, but why would so many courses create their own child
> packages for I/O? Does it not support printing of different types as
> standard?

I don't know. Perhaps it is the way they want to teach Ada?

But that you claim Hello world in Ada is so difficult I cannot
understand at all. Please compare:

   with Ada.Text_IO; use Ada.Text_IO;

   procedure Hello is
   begin
      Put_Line ("Hello World!");
   end Hello;

to the C++ version

   #include <iostream>

   int main()
   {
       std::cout << "Hello, world!\n";
   }

Which is more complicated to understand, remember and read for a
complete beginner in programming?

Trying to imagine the questions from a beginner I would think the
following would come up:

   Ada version:

      1. What does with Ada.Text_IO; use Ada.Text_IO; mean

   C++ version:

      1. What does #include <iostream> mean?
      2. What is int main() ?
      3. What is std::cout ?
      4. Why is there << in front of "Hello world" ?
      5. What does \n mean?

The reason I don't think there are more questions to the Ada version is
that it reads well and the beginner probably can relate to what
procedure mean as one have procedures for doing things in other
situations. I also think that Put_Line ("") is understood without
difficulty. Note I'm talking about a person who has not opened a single
computer programming book or have any other knowledge. 

I think I'll try to send these two examples to some people I know that
know nothing of programming and have then try to explain what the
program does for me :-)


Preben
-- 
�I think fish is nice, but then I think that rain is wet.
 So who am I to judge.�
                 - The Hitch Hiker's Guide to the Galaxy (radioplay)

Re: Ada Advocacy.

[Adrian Hoe]

Stephane Richard wrote:
> Hi everyone,
> 
> In the goal to boost the Ada  programming language, along with the making of
> my website, I'm looking for either documents, or links to comparisons
> between ada and other languages, description of Ada features that set it
> apart from other languages, basically any kind of PR there is out there
> about Ada.
> 
> If you can just give me URL to places that have this info so I can do a
> research and create my own ada advocacy based on the results of my research.
> 
> Thanks in advance :-)
> 


I wrote a paper for Ada-Europe 2002 conference. The paper title is 
"Software Development Reengineering - An Experience Report". There are 
some comparison of Ada with other programming languages using 
Maintainability Index. Might provide some interesting facts.

Re: Ada Advocacy.

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]

do you happen to have a URL to your document somewhere?  I'd like to add it
as a link to your site or as a page (with your permission, of course) :-).

-- 
St�phane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs
"Adrian Hoe" <mailbox@nospam.adrianhoe.com.my> wrote in message
news:3f4ef50c_1@news.tm.net.my...
> Stephane Richard wrote:
> > Hi everyone,
> >
> > In the goal to boost the Ada  programming language, along with the
making of
> > my website, I'm looking for either documents, or links to comparisons
> > between ada and other languages, description of Ada features that set it
> > apart from other languages, basically any kind of PR there is out there
> > about Ada.
> >
> > If you can just give me URL to places that have this info so I can do a
> > research and create my own ada advocacy based on the results of my
research.
> >
> > Thanks in advance :-)
> >
>
>
> I wrote a paper for Ada-Europe 2002 conference. The paper title is
> "Software Development Reengineering - An Experience Report". There are
> some comparison of Ada with other programming languages using
> Maintainability Index. Might provide some interesting facts.
>

Re: Ada Advocacy.

[Jon S. Anthony]

"Luke A. Guest" <laguest@__n_o_s_p_a_m__abyss2.demon.co.uk> writes:


> Actually, indirectly, you've also shown another example of a really cool
> feature of Ada
> 
> function blah(a : Integer, b : Float) : Boolean;
> ...
> blah(b => 1.0, a => 10);
> 
> It'd be so cool to be able to do this in other languages...


CL:

(defun blah (&key a b) ...)

...

(blah :b 1.0 :a 10)



/Jon

Re: Ada Advocacy.

[Luke A. Guest]

On Fri, 29 Aug 2003 12:13:15 -0400, Jon S. Anthony wrote:

> "Luke A. Guest" <laguest@__n_o_s_p_a_m__abyss2.demon.co.uk> writes:
> 
> 
>> Actually, indirectly, you've also shown another example of a really cool
>> feature of Ada
>> 
>> function blah(a : Integer, b : Float) : Boolean;
>> ...
>> blah(b => 1.0, a => 10);
>> 
>> It'd be so cool to be able to do this in other languages...
> 
> 
> CL:
> 
> (defun blah (&key a b) ...)
> 
> ...
> 
> (blah :b 1.0 :a 10)

Ok, languages I use...C/C++...smartarse! ;-P

Luke.

Re: Ada Advocacy.

[Adrian Hoe]

Stephane Richard wrote:
> do you happen to have a URL to your document somewhere?  I'd like to add it
> as a link to your site or as a page (with your permission, of course) :-).
> 



http://adrianhoe.com. Currently, there is a link to the abstract. Once I 
got the permission from the publisher to allow me to publish this 
article on my website, I will put it there. :)

Re: Ada Advocacy.

[Dave Thompson]

On Tue, 26 Aug 2003 22:20:36 +0100, "Luke A. Guest"
<laguest@__n_o_s_p_a_m__abyss2.demon.co.uk> wrote:
<snip>
> Not an URL, but something that I and other programmers have always wanted
> to do in C/C++/etc. but cannot is the printing of names of variables ;-)
> 
> That's a damn nice debugging feature. It's been a while but I think it's
> something like
> 
> declare
> 	test : Integer := 5;
> begin
> 	-- I'm really unsure about the overloaded + operator here, like I said
> 	-- it's been a while (around 6 years!)
> 	Write test'Name + " = " + test;
> end
> 
Put[_Line] and test'Image.

> should send "test = 5" to the console.
> 
> Something like that anyway ;-P Try doing that in C/C++ without a lookup
> table :-(
> 
Generating the string label is easy enough in C or C++ using the
preprocessor # (stringize) operator -- as well as just writing it out
by hand for a fixed value.  But the value conversion in C must be
coded knowing the data type, e.g.:
#define STR(x) #x
... printf (STR(test) " = " "%d" "\n", test ); /* for an int */
/* but %ld for long int, %f for a float or double, etc. */
/* and this doesn't work at all for non-builtin types */

In C++ all builtin types have operator<< predefined, and you can
define it yourself for class types (and enums, although those can also
default to builtin integers), in which case this always works:
... cout << STR(test) << " = " << test << endl;

and can be generated automatically from one variable name like:
#define PRINTVAR(x) cout << # x << " = " x << endl;
... PRINTVAR(test)

These can also be modified in obvious ways to do other things than
stdout, like C sprintf to a buffer or C++ << to a stringstream,
display in a GUI messagebox, send via RPC or CORBA, etc.

PL/I has a builtin facility to output any variable(s), or all, with
names -- PUT DATA -- but cannot be used for any other purpose.
Fortran has NAMELIST I/O to do the same thing for pre-chosen groups of
variables, which works bit is a bit clumsy for just one.

> Another thing that's really useful is being able to declare the range of,
> say, an integer variable - and with bounds checking it gets caught at
> compile & runtime (depending on whether it's accessed with a constant or
> not).
> 
Pascal also does this.  C++ doesn't for builtin integer types, but you
can write an integer-like class which does, or better a template which
generates such (lightweight) classes on demand.  Similarly subscripts
are not checked for builtin arrays, but can be for stdlib containers
like std::vector and for array-like classes that you write or generate
from a template.

> The only downside to Ada is the amount of work that has to go into a
> simple program just to dump out some text (not very good for beginners) to
> the console.
> 
> Also meaningful names negates the need for the absolutely disgusting
> hungarian notation.
> 
This is equally true of all languages above (and most if not all
others) for user names.  Although the names in the Ada standard
library(s) are with perhaps a few exceptions more meaningfully (and
consistently) chosen than in pretty much all other common languages.

- David.Thompson1 at worldnet.att.net

Ada advocacy

[tonyg]

I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

Re: Ada advocacy

[Ludovic Brenta]

tonyg wrote on comp.lang.ada:
> I am currently fending off an attempt to have my project
> converted from ADA to some un named monstrosity of a
> language. Reasons listed are ADA is archaic, programmers
> can not be found, it takes too long to develop blah blah
> list goes on. Anyone got any glossy monosyllabillic
> advocacy documents hopefully in an entertaining cartoon
> format?

Maybe you could start here: http://www.adaic.org/advantages/

-- 
Ludovic Brenta.

Re: Ada advocacy

[Marc C]

On Tuesday, March 20, 2012 7:54:38 AM UTC-5, tonyg wrote:
> I am currently fending off an attempt to have my project converted from ADA
>  to some un named monstrosity of a language. Reasons listed are
  <snip>
> programmers can not be found

This one is a pet peeve of mine. Has the project/company actually tried *looking* for Ada programmers?  If they don't seek, of course they're not going to find.  I regularly run into programmers who worked with Ada, liked it, but ended having to move onto other languages. Given the opportunity to go back to it, not a few would, they *just don't know of any available openings*!

And if an organization does deign to advertise, don't expect an Ada developer to take a 25% pay cut and move their family across the country just for the privilege.  We're good engineers, dammit, recognizing talent and developing with Ada will get you a lot.

(Oh, and by what metric is Ada *2012* "archaic"? Python dates from 1989, C++ from 1979, and the likely monstrosity, Java, dates from 1991. The *youngest* of these is over 20 years old. Don't give me no "archaic" BS.)

Marc A. Criley
Ada sub-reddit moderator
(http://www.reddit.com/r/ada)

Re: Ada advocacy

[Ludovic Brenta]

Marc C wrote on comp.lang.ada:
> tonyg wrote:
>> I am currently fending off an attempt to have my project converted from
>> ADA to some un named monstrosity of a language. Reasons listed are
>  <snip>
>> programmers can not be found
> 
> This one is a pet peeve of mine. Has the project/company actually tried
> *looking* for Ada programmers?  If they don't seek, of course they're not
> going to find.  I regularly run into programmers who worked with Ada,
> liked it, but ended having to move onto other languages. Given the
> opportunity to go back to it, not a few would, they *just don't know of
> any available openings*!
> 
> And if an organization does deign to advertise, don't expect an Ada
> developer to take a 25% pay cut and move their family across the country
> just for the privilege.  We're good engineers, dammit, recognizing talent
> and developing with Ada will get you a lot.
> 
> (Oh, and by what metric is Ada *2012* "archaic"? Python dates from 1989,
> C++ from 1979, and the likely monstrosity, Java, dates from 1991. The
> *youngest* of these is over 20 years old. Don't give me no "archaic" BS.)

+1

Some more ammo:

http://qa.debian.org/popcon-graph.php?packages=gnat+gnat-4.1+gnat-4.3+gnat-4.4+gnat-4.5+gnat-4.6&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

This shows that the number of people using gnat on Debian is increasing.
The current number is approximately 1000 (blue line: installations of
the gnat-4.4 package).  This is how many machines:

- run Debian (not a derivative like Ubuntu!)
- *and* have gnat-4.4 installed
- *and* enrolled in the Debian popularity contest
- *and* are connected to the internet.

The overall number of Ada programmers must be at least a couple
orders of magnitude larger.

-- 
Ludovic Brenta.

Re: Ada advocacy

[Georg Bauhaus]

On 20.03.12 13:54, tonyg wrote:
> I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

Do you have anything in your project for which there
is no ready made library in that other language?

Here's a sentence not to be said aloud:

Being a lemming reduces perceived risk.

Re: Ada advocacy

[Yannick Duchêne (Hibou57)]

Le Tue, 20 Mar 2012 16:13:09 +0100, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> Some more ammo:
>
> http://qa.debian.org/popcon-graph.php?packages=gnat+gnat-4.1+gnat-4.3+gnat-4.4+gnat-4.5+gnat-4.6&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
> This shows that the number of people using gnat on Debian is increasing.
Does it count Ubuntu and others Debian derivatives users or strictly  
Debian only?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada advocacy

[Yannick Duchêne (Hibou57)]

Le Tue, 20 Mar 2012 17:34:41 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> Does it count Ubuntu and others Debian derivatives users or strictly  
> Debian only?
Sorry, you already answered in a forward sentence.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada advocacy

[Jeffrey Carter]

On 03/20/2012 05:54 AM, tonyg wrote:
> I am currently fending off an attempt to have my project converted from ADA
> to some un named monstrosity of a language. Reasons listed are ADA is
> archaic, programmers can not be found, it takes too long to develop blah blah
> list goes on. Anyone got any glossy monosyllabillic advocacy documents
> hopefully in an entertaining cartoon format?

Quality is more important than age. Sure, Ada's been around since 1980, which is 
longer than C++ (1982) or Java (early 1990s). But it's a better choice.

I know people who would like to use Ada but are unable to find positions using 
it. If you advertise it, they will apply.

Where we have hard data (they are hard to come by), they show that development 
in Ada takes 1/2 the effort of development in C. So a claim that "it takes too 
long" is false.

-- 
Jeff Carter
"You a big nose have it."
Never Give a Sucker an Even Break
107

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Ada advocacy

[Shark8]

On Tuesday, March 20, 2012 9:39:38 AM UTC-5, Marc C wrote:
> On Tuesday, March 20, 2012 7:54:38 AM UTC-5, tonyg wrote:
> > I am currently fending off an attempt to have my project converted from ADA
> >  to some un named monstrosity of a language. Reasons listed are
>   <snip>
> > programmers can not be found
> 
> This one is a pet peeve of mine.

That is understandable; from the other direction though when *specifically* asking about Ada jobs/projects I get "No, we don't have anything like that" responses mostly. (The few Ada job postings that I have seen want prior-job experience, which I admittedly don't have, due to the former inability to find an Ada job.) 

> Has the project/company actually tried *looking* for Ada programmers?

I think they don't.

> And if an organization does deign to advertise, don't expect an Ada developer to take a 25% pay cut and move their family across the country just for the privilege.  We're good engineers, dammit, recognizing talent and developing with Ada will get you a lot.

Indeed, I think it may be the perception of progress/work. Ada forces a lot of work done up-front, which is starkly contrasted by languages like PHP (i.e. magic fairy-dust typing and error-apathy); oddly I think the fight-the-language/counteract-the-pitfalls contributes to the perception of work (but the thinking is directed at overcoming decencies of the language instead of solving the problem).

> 
> (Oh, and by what metric is Ada *2012* "archaic"? Python dates from 1989, C++ from 1979, and the likely monstrosity, Java, dates from 1991. The *youngest* of these is over 20 years old. Don't give me no "archaic" BS.)
> 
> Marc A. Criley
> Ada sub-reddit moderator
> (http://www.reddit.com/r/ada)

Re: Ada advocacy

[anon]

The main problem is you have forgotten the golden rule the "Customer" or
group that is paying for the program sets the rules. If they say they
prefer non Ada then you should choose a language they like or they will
simply use someone else and you out of a job. Because most will say if
Microsoft does not support Ada, then we do not support Ada. And no matter
how many reasons you can give will every change most people minds.

In <19595886.4450.1332248078686.JavaMail.geo-discussion-forums@vbbfy7>, tonyg <tonythegair@gmail.com> writes:
>I am currently fending off an attempt to have my project converted from ADA=
> to some un named monstrosity of a language. Reasons listed are ADA is arch=
>aic, programmers can not be found, it takes too long to develop blah blah l=
>ist goes on. Anyone got any glossy monosyllabillic advocacy documents hopef=
>ully in an entertaining cartoon format?

Re: Ada advocacy

[Shark8]

On Tuesday, March 20, 2012 3:42:24 PM UTC-6, an...@att.net wrote:
> The main problem is you have forgotten the golden rule the "Customer" or
> group that is paying for the program sets the rules. If they say they
> prefer non Ada then you should choose a language they like or they will
> simply use someone else and you out of a job.

This is true; but how many customers actually care about the implementation language/platform? Unless it's extremely specialized (ie micro-controllers) or a windows application [specifically], that is. 

> Because most will say if Microsoft does not support Ada, then we do not
> support Ada. And no matter how many reasons you can give will every change
> most people minds.

Microsoft *does* support Ada via its .NET platform... unless you want to argue that the "program in your preferred language" bullet-point touting .NET's advantages is false.

Re: Ada advocacy

[Shark8]

On Tuesday, March 20, 2012 6:54:38 AM UTC-6, tonyg wrote:
> I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

http://www.adapower.com/index.php?Command=Class&ClassID=AdvocacyVideos&Title=Ada+Advocacy+Videos

The videos are dated, talking about pre 95 revision, I think... but they make some good points... if I had talent on the drawing/artistic side I think it'd be fun to condence them into a cartoon format.

Re: Ada advocacy

[Robert Love]

On 2012-03-20 12:54:38 +0000, tonyg said:

> I am currently fending off an attempt to have my project converted from 
> ADA to some un named monstrosity of a language. Reasons listed are ADA 
> is archaic, programmers can not be found, it takes too long to develop 
> blah blah list goes on. Anyone got any glossy monosyllabillic advocacy 
> documents hopefully in an entertaining cartoon format?

Good luck.  I'm currently watching NASA throw away many 100K sloc of 
Ada that's worked for 10 years to replace it with C++.  It's being done 
in the name of preparing for the future but really, I think it's a jobs 
program, sad to say.  The C++ guys sometimes sneer at Ada but we find 
it funny that they  haven't fully comprehended the scope of the problem 
 yet.  I'm sure they'll get there eventually but as tax payers (if 
you're US) it's very frustrating.

Re: Ada advocacy

[Per Sandberg]

On Wednesday, March 21, 2012 2:58:22 AM UTC+1, Robert Love wrote:
> On 2012-03-20 12:54:38 +0000, tonyg said:
> 
> > I am currently fending off an attempt to have my project converted from 
> > ADA to some un named monstrosity of a language. Reasons listed are ADA 
> > is archaic, programmers can not be found, it takes too long to develop 
> > blah blah list goes on. Anyone got any glossy monosyllabillic advocacy 
> > documents hopefully in an entertaining cartoon format?
> 
> Good luck.  I'm currently watching NASA throw away many 100K sloc of 
> Ada that's worked for 10 years to replace it with C++.  It's being done 
> in the name of preparing for the future but really, I think it's a jobs 
> program, sad to say.  The C++ guys sometimes sneer at Ada but we find 
> it funny that they  haven't fully comprehended the scope of the problem 
>  yet.  I'm sure they'll get there eventually but as tax payers (if 
> you're US) it's very frustrating.

And some roumurs says: Thare are still small teams of programmers doing backports of some of the NASA C/C++ SW to Ada again, and they are finding "intresting" bugs that are repored back to NASA again.

Re: Ada advocacy

[anon]

First, there is no "Microsoft Ada" or "Microsoft Visual Ada" for.net product. 
Second, besides IBM z/OS Rational Apex Ada and Adacore GNAT there are no 
other 2005 compilers. There are a few Ada 95 compiler but most software 
companies like DEC, SGI, Sun have discontinued their Ada compilers. SGI 
even suggest Adacore's GNAT.

So, Microsoft does not support Ada platform directly. And Microsoft does not 
support any GNU language. Its GNU community that supports some Microsoft 
platforms.

A reasons why people do not support Ada.

Microsoft has been using multi-threads since Windows 1.0 (DOS GUI addon)
which was shipped in early 1985 and with OS/2 1.0 a hardware based 
intrinsic multitasking OS in 1987. So, when Microsoft went into the 
schools, people learned that Windows was a multi-threading operating 
system. And now every Microsoft language and OS platforms support parallel.

But, Ada has always been "Concurrent" aka DOS or batch like programming. 
Aka no multi-threads or parallel design.  Even in Ada 2012 (not adopted 
yet), the parallel is not fully there only some simple multiple CPU 
design structures. 

Now, today, no software customer want to use a language unless that language 
fully support multi-threading and parallel designs. So, until the ARG fully 
embraces a true multi-threads parallel design, Ada will stay a limited usage
language.



In <2012032020582259520-rblove@airmailnet>, Robert Love <rblove@airmail.net> writes:
>On 2012-03-20 12:54:38 +0000, tonyg said:
>
>> I am currently fending off an attempt to have my project converted from 
>> ADA to some un named monstrosity of a language. Reasons listed are ADA 
>> is archaic, programmers can not be found, it takes too long to develop 
>> blah blah list goes on. Anyone got any glossy monosyllabillic advocacy 
>> documents hopefully in an entertaining cartoon format?
>
>Good luck.  I'm currently watching NASA throw away many 100K sloc of 
>Ada that's worked for 10 years to replace it with C++.  It's being done 
>in the name of preparing for the future but really, I think it's a jobs 
>program, sad to say.  The C++ guys sometimes sneer at Ada but we find 
>it funny that they  haven't fully comprehended the scope of the problem 
> yet.  I'm sure they'll get there eventually but as tax payers (if 
>you're US) it's very frustrating.
>

Re: Ada advocacy

[tonyg]

On Tuesday, March 20, 2012 12:54:38 PM UTC, tonyg wrote:
> I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

Thanks for the help Guys. I'll let you know how it goes.

Re: Ada advocacy

[KK6GM]

On Mar 20, 5:54 am, tonyg <tonytheg...@gmail.com> wrote:
> I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

A late reply, but I'd focus on two things.  For management, I'd focus
on SAVING MONEY!  Ada programs should field faster and require less
maintenence cost.  Any manager who doesn't want to offer a better
product at a lower cost is a fool, or at least a problem for the
company.

For the programmers, I'd focus on the professionalism of (a) being
able to become fluent in new (to them) languages, and (b) using a
language that is demonstrably better than the language(s) they are now
using.

The latter point also applies to the "problem" of finding new
programmers.  Any programmer who is looking for employment in a field
in which Ada is a suitable language choice, who won't or can't learn
Ada, is either incompetent (afraid he can't learn a new language), or
a prima dona (refuses to learn a new language), or myopic (incapable
of seeing that exposure to Ada will make him a generally better
programmer).  In short, a programmer that you perhaps wouldn't want in
the first place.

Yes, these are all blanket statements that require modifying ifs, ands
and buts.  But I think the facts support them.  So it's up to you to
marshal those facts and form your arguments.

In summary, your job is to round up data to convince them that they're
brilliant if they continue to use Ada (and rewards will follow), and
idiots if they don't (and bad things will follow). :)

Re: Ada advocacy

[Peter C. Chapin]

On 2012-03-21 01:37, Per Sandberg wrote:

> And some rumors says: There are still small teams of programmers
> doing backports of some of the NASA C/C++ SW to Ada again, and they
> are finding "intresting" bugs that are repored back to NASA again.

Those rumors might be pertaining to the CubeSat work we are doing at 
Vermont Technical College. NASA is allowing us to use some navigation 
software they developed. The software is written in C and, as C programs 
go, is reasonably well done. We are working on converting it to SPARK... 
a process that is ongoing. We have found a few "anomalies" so far---I'm 
not sure I'd call them outright bugs---but we have only translated about 
25% of the code and we are far from completing all the proofs.

Most of the programmers on this project are students and most of the 
progress on it gets made during the summer.

Peter

Re: Ada advocacy

[david]

On Tuesday, March 20, 2012 8:54:38 AM UTC-4, tonyg wrote:
> I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

where are you located? I would welcome an opportunity to program in Ada.

Re: Ada advocacy

[david]

On Tuesday, March 20, 2012 8:54:38 AM UTC-4, tonyg wrote:
> I am currently fending off an attempt to have my project converted from ADA to some un named monstrosity of a language. Reasons listed are ADA is archaic, programmers can not be found, it takes too long to develop blah blah list goes on. Anyone got any glossy monosyllabillic advocacy documents hopefully in an entertaining cartoon format?

I would program in Ada in a NY second!

Re: Ada advocacy

[johannes falcone]

> 
> Good luck.  I'm currently watching NASA throw away many 100K sloc of 
> 
> Ada that's worked for 10 years to replace it with C++.
> 
> you're US) it's very frustrating.

NASA fails

Re: Ada advocacy

[johannes falcone]

ada has tasklets and uses 16 cpu easily I heard..

Re: Ada advocacy

[johannes falcone]

you should gather a few guys here and add them to the project working remote

kick butt

Re: Ada advocacy

[tmoran]

It's bizarre to watch the complaining about Chinese etc hackers, with nary
a mention of junky US software.  Like a little pig continuing to build his
house of straw and squealing loudly when the big bad wolf blows it down.

Re: Ada advocacy

[Leo Brewin]

Greetings,

I have just been reading some of the older posts in this discussion and came across the following objections to Ada (see quoted text below). Does anybody have any opinion on this? Is it correct? Is the original poster confusing the difference between a programming language and an operating system?

Cheers,
Leo

On Wednesday, March 21, 2012 7:59:23 PM UTC+11, an...@att.net wrote:
> A reasons why people do not support Ada.
> 
> Microsoft has been using multi-threads since Windows 1.0 (DOS GUI addon)
> which was shipped in early 1985 and with OS/2 1.0 a hardware based 
> intrinsic multitasking OS in 1987. So, when Microsoft went into the 
> schools, people learned that Windows was a multi-threading operating 
> system. And now every Microsoft language and OS platforms support parallel.
> 
> But, Ada has always been "Concurrent" aka DOS or batch like programming. 
> Aka no multi-threads or parallel design.  Even in Ada 2012 (not adopted 
> yet), the parallel is not fully there only some simple multiple CPU 
> design structures. 
> 
> Now, today, no software customer want to use a language unless that language 
> fully support multi-threading and parallel designs. So, until the ARG fully 
> embraces a true multi-threads parallel design, Ada will stay a limited usage
> language.

Re: Ada advocacy

[Jeffrey Carter]

On 06/17/2013 05:14 PM, Leo Brewin wrote:
>
> I have just been reading some of the older posts in this discussion and came
> across the following objections to Ada (see quoted text below). Does anybody
> have any opinion on this? Is it correct? Is the original poster confusing the
> difference between a programming language and an operating system?

This is typical FUD from "anon" and like most of its posts can be ignored.

-- 
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61

Re: Ada advocacy

[Dennis Lee Bieber]

On Mon, 17 Jun 2013 17:14:59 -0700 (PDT), Leo Brewin
<leo.brewin@internode.on.net> declaimed the following:

>Greetings,
>
>I have just been reading some of the older posts in this discussion and came across the following objections to Ada (see quoted text below). Does anybody have any opinion on this? Is it correct? Is the original poster confusing the difference between a programming language and an operating system?
>
>Cheers,
>Leo
>
>On Wednesday, March 21, 2012 7:59:23 PM UTC+11, an...@att.net wrote:
>> A reasons why people do not support Ada.
>> 
>> Microsoft has been using multi-threads since Windows 1.0 (DOS GUI addon)
>> which was shipped in early 1985 and with OS/2 1.0 a hardware based 
>> intrinsic multitasking OS in 1987. So, when Microsoft went into the 
>> schools, people learned that Windows was a multi-threading operating 
>> system. And now every Microsoft language and OS platforms support parallel.
>> 
>> But, Ada has always been "Concurrent" aka DOS or batch like programming. 
>> Aka no multi-threads or parallel design.  Even in Ada 2012 (not adopted 
>> yet), the parallel is not fully there only some simple multiple CPU 
>> design structures. 
>> 
>> Now, today, no software customer want to use a language unless that language 
>> fully support multi-threading and parallel designs. So, until the ARG fully 
>> embraces a true multi-threads parallel design, Ada will stay a limited usage
>> language.

	M$ Windows 1 to WfW3.11 had no preemption, it was totally cooperative
-- the program had to be coded to give up the CPU and let some other task
take control. Just one step above co-routines.

	"Concurrent" covers many capabilities -- even a single core processor
using preemptive task switching is considered "concurrent" (The term
simplifies to: the tasks each think they have the full processor; they
don't know about other tasks that are taking time with them; true
concurrent/parallel execution is only something fairly recent -- even the
old Cray systems only had parallel arithmetic but didn't run parallel
independent programs, every arithmetic system did the same operation in
sync, just accessing different data). The Amiga had a multi-priority
preemptive OS much before Windows (Windows 95 and Windows NT were the first
/preemptive/ systems from M$). But I'm not surprised that /schools/ could
be bamboozled by M$ -- understanding the intricacies of preemptive tasking
is not something high schools would cognizant of; that's CS major level.

	In a preemptive system, programs do NOT have to be written to give up
the CPU to another. The OS will stop one program and run another based upon
clock interrupts. Early Windows wouldn't -- if you did a 
	while (1)
		continue;
that program would eat the entire computer time and no other task would
ever get the CPU.

	Ada was basically the first LANGUAGE that defined multi-tasking IN THE
LANGUAGE itself. Before it, one had to use OS specific system calls to
create tasks -- if such a call was even available, in contrast to creating
processes at the command line level.

	C/C++ do NOT "embrace" "multi-thread parallel design". They rely on
external libraries of system services to create threads. The Ada /runtime/
may use those same system services, but they are hidden from the programmer
(unless one is trying to do a minimal runtime for a bare board). The
programmer only has to know how Ada defines a task, not how the OS creates
them.

	Actually, unless doing Ada on a bare board, it pretty much HAS to use
the same OS features as any other language is using. That is, Ada tasks
have to become OS threads/processes. If the task swapping was being done by
the Ada runtime without using the OS, than the first task that blocks on,
say, IO [which is handled by the OS] would block ALL tasks in the program
-- since the OS doesn't know about them it can't give them CPU time.

	What I find amazing is the concept of "Real-Time Java" <G>
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Ada advocacy

[Peter Brooks]

On Jun 18, 3:28 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>
>
>         Ada was basically the first LANGUAGE that defined multi-tasking IN THE
> LANGUAGE itself. Before it, one had to use OS specific system calls to
> create tasks -- if such a call was even available, in contrast to creating
> processes at the command line level.
>
The second. Algol68 did.

Re: Ada advocacy

[Robert A Duff]

Peter Brooks <peter.h.m.brooks@gmail.com> writes:

> On Jun 18, 3:28 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>>
>>
>>         Ada was basically the first LANGUAGE that defined multi-tasking IN THE
>> LANGUAGE itself. Before it, one had to use OS specific system calls to
>> create tasks -- if such a call was even available, in contrast to creating
>> processes at the command line level.
>>
> The second. Algol68 did.

Others, too.  Per Brinch-Hansen's Concurrent Pascal, for example.  It
has something-like Ada tasks (no rendezvous; no big loss), and
something-like Ada protected objects (without barriers -- that's
a big loss).

But Dennis is mostly right -- in the olden days, concurrency was mostly
considered an OS issue.

- Bob

Re: Ada advocacy

[Bill Findlay]

On 18/06/2013 18:15, in article wccvc5b49yc.fsf@shell01.TheWorld.com,
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:

> Peter Brooks <peter.h.m.brooks@gmail.com> writes:
> 
>> On Jun 18, 3:28 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>>> 
>>> 
>>>         Ada was basically the first LANGUAGE that defined multi-tasking IN
>>> THE
>>> LANGUAGE itself. Before it, one had to use OS specific system calls to
>>> create tasks -- if such a call was even available, in contrast to creating
>>> processes at the command line level.
>>> 
>> The second. Algol68 did.

Not to mention PL/I.

> Others, too.  Per Brinch-Hansen's Concurrent Pascal, for example.  It
> has something-like Ada tasks (no rendezvous; no big loss), and
> something-like Ada protected objects (without barriers -- that's
> a big loss).

Do you mean conditional critical regions?

They did have barriers, but Brinch Hansen and Hoare differed as to whether
they should be anchored at the start, e.g.:

   region V await C do
   ...
   end region;

or should be allowed anywhere inside the region construct:

   region V do
   ...
      await C;
   ...
   end region;

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada advocacy

[Robert A Duff]

Bill Findlay <yaldnif.w@blueyonder.co.uk> writes:

> Do you mean conditional critical regions?
>
> They did have barriers, but Brinch Hansen and Hoare differed as to whether
> they should be anchored at the start, e.g.:

I don't remember the details.  Barriers in Ada are tied to the entry,
as opposed to being separate from the "monitor".  And I seem to recall
some by-hand management of queues in Concurrent Pascal that is done
automatically in Ada.  But my memory of Concurrent Pascal is hazy!

- Bob

Re: Ada advocacy

[Bill Findlay]

On 18/06/2013 20:22, in article wcczjunns01.fsf@shell01.TheWorld.com,
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:

> Bill Findlay <yaldnif.w@blueyonder.co.uk> writes:
> 
>> Do you mean conditional critical regions?
>> 
>> They did have barriers, but Brinch Hansen and Hoare differed as to whether
>> they should be anchored at the start, e.g.:
> 
> I don't remember the details.  Barriers in Ada are tied to the entry,
> as opposed to being separate from the "monitor".  And I seem to recall
> some by-hand management of queues in Concurrent Pascal that is done
> automatically in Ada.  But my memory of Concurrent Pascal is hazy!

Concurrent Pascal, specifically, only had "bad old" monitors.

CCRs were actually invented before Concurrent Pascal or Modula, so it was a
major disappointment that they were not included in either.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada advocacy

[nevillednz]

On Tuesday, 18 June 2013 15:55:23 UTC+10, Peter Brooks  wrote:
> On Jun 18, 3:28 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
> >         Ada was basically the first LANGUAGE that defined multi-tasking 
> >         IN THE LANGUAGE itself.
> The second. Algol68 did.

c.f. http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#ALGOL_68
    PAR ( # remove PAR for single threaded sort #
      qsort(array[:i-1], cmp),
      qsort(array[i+1:], cmp)
    )

Blink and you might miss it! :-)

See also:
* http://rosettacode.org/wiki/Synchronous_concurrency#ALGOL_68
* http://rosettacode.org/wiki/Matrix_multiplication#Parallel_processing
* http://rosettacode.org/wiki/Generator/Exponential#ALGOL_68

The last example creates kind of a pipeline...

NJoy
NevilleDNZ

Re: Ada advocacy

[johannes falcone]

so ada programs can use 16 core machines without special programming?

or must you pay for something non free like ravenscar?

or is ravenscar free?

Re: Ada advocacy

[Jacob Sparre Andersen]

johannes falcone <visphatesjava@gmail.com> writes:

> so ada programs can use 16 core machines without special programming?

Yes.  And 48 core systems.  And even more if you can find them.

Greetings,

Jacob
-- 
"I Am The Leading Programmer" - J.-P. Rosen
 is abstract tagged limited private

Re: Ada advocacy

[Ludovic Brenta]

johannes falcone <visphatesjava@gmail.com> writes:
> so ada programs can use 16 core machines without special programming?

Correct.

> or must you pay for something non free like ravenscar?
> or is ravenscar free?

Ravenscar is free and is not a product, it is a specification of how you
can restrict Ada to a subset.  In fact Ada itself is also a (language)
specification, not a product.

-- 
Ludovic Brenta.

Re: Ada advocacy

[Shark8]

On Wednesday, June 19, 2013 1:34:23 PM UTC-6, Jacob Sparre Andersen wrote:
> johannes falcone <visphatesjava@gmail.com> writes:
> 
> > so ada programs can use 16 core machines without special programming?
> 
> Yes.  And 48 core systems.  And even more if you can find them.

Here's a 144-core chip; specially designed for [parallel] FORTH code.

Re: Ada advocacy

[Yannick Duchêne (Hibou57)]

Le Tue, 18 Jun 2013 19:15:07 +0200, Robert A Duff  
<bobduff@shell01.theworld.com> a écrit:

> Peter Brooks <peter.h.m.brooks@gmail.com> writes:
>
>> On Jun 18, 3:28 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>>>
>>>
>>>         Ada was basically the first LANGUAGE that defined  
>>> multi-tasking IN THE
>>> LANGUAGE itself. Before it, one had to use OS specific system calls to
>>> create tasks -- if such a call was even available, in contrast to  
>>> creating
>>> processes at the command line level.
>>>
>> The second. Algol68 did.
>
> Others, too.  Per Brinch-Hansen's Concurrent Pascal, for example.  It
> has something-like Ada tasks (no rendezvous; no big loss), and
> something-like Ada protected objects (without barriers -- that's
> a big loss).
>
> But Dennis is mostly right -- in the olden days, concurrency was mostly
> considered an OS issue.
>

Why did you said “no big loss” about the rendez‑vous? What's your known  
issues with rendez‑vous? I never used concurrency a lot until now, so  
that's really a question, because I may  (or may not, I still don't know)  
have to use it.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada advocacy

[Yannick Duchêne (Hibou57)]

Le Wed, 19 Jun 2013 09:29:57 +0200, <nevillednz@gmail.com> a écrit:

> On Tuesday, 18 June 2013 15:55:23 UTC+10, Peter Brooks  wrote:
>> On Jun 18, 3:28 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>> >         Ada was basically the first LANGUAGE that defined  
>> multi-tasking
>> >         IN THE LANGUAGE itself.
>> The second. Algol68 did.
>
> c.f. http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#ALGOL_68
>     PAR ( # remove PAR for single threaded sort #
>       qsort(array[:i-1], cmp),
>       qsort(array[i+1:], cmp)
>     )
>
> Blink and you might miss it! :-)

And what happened to it? Was this all fine or not?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada advocacy

[Bill Findlay]

On 27/08/2013 14:34, in article op.w2g9br0kule2fv@cardamome, "Yannick
Duchêne   (Hibou57)" <yannick_duchene@yahoo.fr> wrote:

> Le Tue, 18 Jun 2013 19:15:07 +0200, Robert A Duff
> <bobduff@shell01.theworld.com> a écrit:
> 
>> Peter Brooks <peter.h.m.brooks@gmail.com> writes:
>> 
>>> On Jun 18, 3:28 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>>>> 
>>>> 
>>>>         Ada was basically the first LANGUAGE that defined
>>>> multi-tasking IN THE
>>>> LANGUAGE itself. Before it, one had to use OS specific system calls to
>>>> create tasks -- if such a call was even available, in contrast to
>>>> creating
>>>> processes at the command line level.
>>>> 
>>> The second. Algol68 did.

Just for histrical accuracy, I'll note that PL/I included language-defined
tasking in 1964. 

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada advocacy

[Bill Findlay]

On 27/08/2013 15:08, in article CE427152.35271%yaldnif.w@blueyonder.co.uk,
"Bill Findlay" <yaldnif.w@blueyonder.co.uk> wrote:

> 
> Just for histrical accuracy, ...

That was meant to be "historical", not "hysterical" ...

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada advocacy

[J-P. Rosen]

Le 27/08/2013 15:34, Yannick Duchêne (Hibou57) a écrit :
> Why did you said “no big loss” about the rendez‑vous? What's your known
> issues with rendez‑vous? I never used concurrency a lot until now, so
> that's really a question, because I may  (or may not, I still don't
> know) have to use it.
It's a one person's opinion, that I certainly don't share.

Rendezvous are a high level concept, easy to use because close to what
you do in real life. Only those who think close to the bare machine have
issues with rendezvous. And don't forget a big plus of rendezvous over
protected objects: termination is (can be) automatic, without devising
some complicated handshaking.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada advocacy

[Dennis Lee Bieber]

On Tue, 27 Aug 2013 15:34:29 +0200, Yannick Duchêne (Hibou57)
<yannick_duchene@yahoo.fr> declaimed the following:

>Le Tue, 18 Jun 2013 19:15:07 +0200, Robert A Duff  
><bobduff@shell01.theworld.com> a écrit:
>
	Wow -- a two month dormancy of the thread! <G>

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Ada advocacy

[Maciej Sobczak]

> Why did you said "no big loss" about the rendez-vous? What's your known  
> issues with rendez-vous? I never used concurrency a lot until now, so  
> that's really a question, because I may  (or may not, I still don't know)  
> have to use it.

The biggest issue with rendez-vous is that it is (the server-side part of it) coupled by the rules of grammar to the top level of task body. That is, all your "accept" statements must be syntactically in the task body that declared appropriate entries.
It looks OK in the book examples, but since it makes code refactoring impossible, things can become ugly pretty quickly. This is kind of ironic, because rendez-vous is described as a high-level feature and high-level features normally add to code clarity. Here you have a high-level feature that is constrained by low-level grammar rules, hence the contradiction.

The "no big loss" statement is justified by the fact that rendez-vous does not offer anything particularly useful to what is already offered by protected objects.

-- 
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Ada advocacy

[Dmitry A. Kazakov]

On Tue, 27 Aug 2013 23:25:01 +0200, J-P. Rosen wrote:

> Le 27/08/2013 15:34, Yannick Duchêne (Hibou57) a écrit :
>> Why did you said “no big loss” about the rendez‑vous? What's your known
>> issues with rendez‑vous? I never used concurrency a lot until now, so
>> that's really a question, because I may  (or may not, I still don't
>> know) have to use it.
> It's a one person's opinion, that I certainly don't share.
> 
> Rendezvous are a high level concept, easy to use because close to what
> you do in real life. Only those who think close to the bare machine have
> issues with rendezvous. And don't forget a big plus of rendezvous over
> protected objects: termination is (can be) automatic, without devising
> some complicated handshaking.

Another plus is that rendezvous need not to be non-blocking and may include
lengthy actions.

Rendezvous could be easily extended on a distributed system, which would be
practically impossible for protected objects.

I think that for distributed and massively parallel systems rendezvous
clearly beat protected objects.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada advocacy

[Georg Bauhaus]

On 28.08.13 09:45, Maciej Sobczak wrote:
>> Why did you said "no big loss" about the rendez-vous? What's your known
>> issues with rendez-vous? I never used concurrency a lot until now, so
>> that's really a question, because I may  (or may not, I still don't know)
>> have to use it.
>
> The biggest issue with rendez-vous is that it is (the server-side part of it) coupled by the rules of grammar to the top level of task body. That is, all your "accept" statements must be syntactically in the task body that declared appropriate entries.
> It looks OK in the book examples, but since it makes code refactoring impossible,

Having the accept statements in one place surely means
you'll find the server side's tasking interface and its
control structure (when acting), in one place.

Note that task can be nested; if bodies other that task bodies
could carry accept statements, that would be an invitation to create
very puzzling software designs. It'd take quite some effort to
find a task type's accept statements.

If, instead, scope is used for actions to go between acceptors,
private packages, separate, etc, then supporting definitions
can go elsewhere, and be refactored as needed, respecting the
needs of visibility of data. This leaves the communications parts
not scattered, but in one tight control struture.

I find this kind of grammatically required modularity normal for
a Has-It type language like Ada; I'd not expect this kind of
stricture when using a more "flexible" I-Can-Roll-My-Own language.


> The "no big loss" statement is justified by the fact that rendez-vous does not offer anything particularly useful to what is already offered by protected objects.

How so? There is no rendezvous via protected objects, since
using it means the program is using a different protocol.
And different types, different objects, likely different
places for shared data, and overall a different way of
communicating data. A handshake (rendezvous )and a mailbox
(PO) seem different to me.

Taken to the extreme of the Ravenscar profile, its lack of
rendezvous demonstrates the relative difficulty that ensues.

Re: Ada advocacy

[Dmitry A. Kazakov]

On Wed, 28 Aug 2013 10:58:44 +0200, Georg Bauhaus wrote:

> On 28.08.13 09:45, Maciej Sobczak wrote:
>>> Why did you said "no big loss" about the rendez-vous? What's your known
>>> issues with rendez-vous? I never used concurrency a lot until now, so
>>> that's really a question, because I may  (or may not, I still don't know)
>>> have to use it.
>>
>>  The biggest issue with rendez-vous is that it is (the server-side part of
>>  it) coupled by the rules of grammar to the top level of task body. That
>>  is, all your "accept" statements must be syntactically in the task body
>>  that declared appropriate entries.
>> It looks OK in the book examples, but since it makes code refactoring impossible,
> 
> Having the accept statements in one place surely means
> you'll find the server side's tasking interface and its
> control structure (when acting), in one place.

The point Maciej does is valid and it is the issue which prevents tasks
from having entries proper methods supporting inheritance and overriding.

BUT, protected objects have problems with inheritance on their own as well
as problems with all other means of restructuring, refactoring, reuse etc. 

It is unfair to blame tasks for something protected objects do not solve
either.

It is good that Ada has both tasks and protected objects. So far nobody
came with anything better, IMO.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada advocacy

[G.B.]

On 28.08.13 11:42, Dmitry A. Kazakov wrote:
> The point Maciej does is valid and it is the issue which prevents tasks
> from having entries proper methods supporting inheritance and overriding.

If that was the point, there still there is a huge difference
between "normal" types with overriding and all on the one hand
and task types on the other, namely that

  task types specify possible orders of method execution   (*)

That's the deal, a reference to an order of events in time,
right in the type. Something that ordinary types don't have.
(Except in the manner of trivial sequentiality of method
bodies.)

I suggest that saying "refactoring" is a far cry from being
a satisfactory solution of (*) from the language point of view.

Re: Ada advocacy

[Dmitry A. Kazakov]

On Wed, 28 Aug 2013 13:42:16 +0200, G.B. wrote:

> On 28.08.13 11:42, Dmitry A. Kazakov wrote:
>> The point Maciej does is valid and it is the issue which prevents tasks
>> from having entries proper methods supporting inheritance and overriding.
> 
> If that was the point, there still there is a huge difference
> between "normal" types with overriding and all on the one hand
> and task types on the other, namely that
> 
>   task types specify possible orders of method execution   (*)

As well as other type could do in order to maintain the object's invariant. 

BTW, this, no doubt, flawed idea is actively promoted by Ada 2012 idea of
preconditions <=> operations that are not applicable in *any* context where
arguments are valid.

As with plain types, one can argue that imposing certain order (as a
precondition) is merely bad design to be avoided when possible.

The corresponding patters for safer abstractions are sessions, transactions
etc, all in the end intended to weaken the preconditions.

> I suggest that saying "refactoring" is a far cry from being
> a satisfactory solution of (*) from the language point of view.

Refactoring *is* a solution, but the problem is that there is no good means
to refactor it easily, safely etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada advocacy

[G.B.]

On 28.08.13 13:59, Dmitry A. Kazakov wrote:
> The corresponding patters for safer abstractions are sessions, transactions
> etc, all in the end intended to weaken the preconditions.

These concepts not being defined in Ada, it is all the more worrying
that efforts in the direction of integrating such higher level
concepts are either

- hooked into closed source and/or patent pending algorithms/language
   like e.g. into Google's experimental App Engine, or

- do not visibly produce any coordinated language design effort,
   assuming the software-dependent industry ever thinks about such

An example of lack of coordination is reflected by OpenMP; the good
things developed with more recent versions of OpenMP still require
doubled (or squared) efforts when programming: both, the sequential
languages like C or Fortran, and the OpenMP capabilities, need to be
used properly. Paraffin cannot be much better than OpenMP here, I
think, since it's a library and needs convention, not language, for
expressing algorithms for Paraffin.  When writing OpenMP annotations,
the mantra is likely "just do the right thing", again dismissing
language design in favor of proud, ego-full programmers who (think
they) do the right thing.

Do you think that current types can handle this at the language
level?

Re: Ada advocacy

[Dmitry A. Kazakov]

On Wed, 28 Aug 2013 14:49:51 +0200, G.B. wrote:

> On 28.08.13 13:59, Dmitry A. Kazakov wrote:
>> The corresponding patters for safer abstractions are sessions, transactions
>> etc, all in the end intended to weaken the preconditions.
> 
> These concepts not being defined in Ada,

It is not clear how to do that.

> it is all the more worrying
> that efforts in the direction of integrating such higher level
> concepts are either
> 
> - hooked into closed source and/or patent pending algorithms/language
>    like e.g. into Google's experimental App Engine, or
> 
> - do not visibly produce any coordinated language design effort,
>    assuming the software-dependent industry ever thinks about such

See above.

> Do you think that current types can handle this at the language
> level?

A [typed] language where synchronization primitives are first class objects
shall have this. Unfortunately nobody knows how.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada advocacy

[Eryndlia Mavourneen]

On Wednesday, August 28, 2013 9:07:34 AM UTC-5, Dmitry A. Kazakov wrote:
> On Wed, 28 Aug 2013 14:49:51 +0200, G.B. wrote:
>   ...
> A [typed] language where synchronization primitives are first class objects
> shall have this. Unfortunately nobody knows how.

The compromise would seem to be the use of task interface types.  These can be used to specify portions of code, which then can be combined into the desired task structure, including sequence, for specific needs.

-- Eryndlia (KK1T)

Re: Ada advocacy

[Yannick Duchêne (Hibou57)]

Le Wed, 28 Aug 2013 13:42:16 +0200, G.B.  
<rm-dash-bau-haus@dash.futureapps.de> a écrit:
>
> That's the deal, a reference to an order of events in time,
> right in the type. Something that ordinary types don't have.

As a comment aside, that's why it happened I missed Ada had coroutines  
(using a task in place of a coroutine is too much).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada advocacy

[Dmitry A. Kazakov]

On Wed, 28 Aug 2013 18:44:38 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Wed, 28 Aug 2013 13:42:16 +0200, G.B.  
> <rm-dash-bau-haus@dash.futureapps.de> a écrit:
>>
>> That's the deal, a reference to an order of events in time,
>> right in the type. Something that ordinary types don't have.
> 
> As a comment aside, that's why it happened I missed Ada had coroutines  
> (using a task in place of a coroutine is too much).

It is an interesting question, but too vague.

1. preemptive or not?

2. implicit state or explicit (bound to some object)

3. how much of the context where given execution path is nested would be
accessible?

4. inheritance issues

Maybe instead of coroutines... Ada does not specify whether tasks should be
native. What about providing tasks scheduled by the RTL (or user), in
addition to the native tasks, not as a replacement. Such tasks would have
many limitations regarding I/O, but no more coroutines would. And they will
be lighter than native tasks.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada advocacy

[Dmitry A. Kazakov]

On Wed, 28 Aug 2013 08:06:14 -0700 (PDT), Eryndlia Mavourneen wrote:

> On Wednesday, August 28, 2013 9:07:34 AM UTC-5, Dmitry A. Kazakov wrote:
>> On Wed, 28 Aug 2013 14:49:51 +0200, G.B. wrote:
>>   ...
>> A [typed] language where synchronization primitives are first class objects
>> shall have this. Unfortunately nobody knows how.
> 
> The compromise would seem to be the use of task interface types.

Interfaces never helped reuse (anything actually).

> These
> can be used to specify portions of code, which then can be combined into
> the desired task structure, including sequence, for specific needs.

This is already possible to do using procedures. Replacing them with
class-wide operations brings nothing. Less, actually, because class-wide
operations on interfaces could not access task object data.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada advocacy

[Dennis Lee Bieber]

On Wed, 28 Aug 2013 19:25:59 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> declaimed the following:


>Maybe instead of coroutines... Ada does not specify whether tasks should be
>native. What about providing tasks scheduled by the RTL (or user), in
>addition to the native tasks, not as a replacement. Such tasks would have

	Of course, that implies that those tasks have no CPU time if their
parent task/scheduler is suspended or blocked. It is the return of Windows
3 <G>

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Ada advocacy

[Dmitry A. Kazakov]

On Wed, 28 Aug 2013 19:33:23 -0400, Dennis Lee Bieber wrote:

> On Wed, 28 Aug 2013 19:25:59 +0200, "Dmitry A. Kazakov"
> <mailbox@dmitry-kazakov.de> declaimed the following:
> 
>>Maybe instead of coroutines... Ada does not specify whether tasks should be
>>native. What about providing tasks scheduled by the RTL (or user), in
>>addition to the native tasks, not as a replacement. Such tasks would have
> 
> 	Of course, that implies that those tasks have no CPU time if their
> parent task/scheduler is suspended or blocked. It is the return of Windows
> 3 <G>

Yes, MS-DOS INT 13, if I correctly remember the number.

The main (only?) use case for co-routines is programming event-driven state
machines as if the I/O were blocking and not an asynchronous one
(completion event). E.g. socket-select stuff. GUI programming could also
use them is some cases (when the user must click through a sequence (tree)
of controls).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada advocacy

[Yannick Duchêne (Hibou57)]

Le Wed, 28 Aug 2013 19:25:59 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Wed, 28 Aug 2013 18:44:38 +0200, Yannick Duchêne (Hibou57) wrote:
>
>> Le Wed, 28 Aug 2013 13:42:16 +0200, G.B.
>> <rm-dash-bau-haus@dash.futureapps.de> a écrit:
>>>
>>> That's the deal, a reference to an order of events in time,
>>> right in the type. Something that ordinary types don't have.
>>
>> As a comment aside, that's why it happened I missed Ada had coroutines
>> (using a task in place of a coroutine is too much).
>
> It is an interesting question, but too vague.

Thanks for the interesting questions :)

> 1. preemptive or not?
No. Otherwise just use task.

> 2. implicit state or explicit (bound to some object)
Implicit. If explicit state is needed, it can be provided by other means.

> 3. how much of the context where given execution path is nested would be
> accessible?
Explicitly bounded.

> 4. inheritance issues
May be disallowed for dispatching operations.

> Maybe instead of coroutines... Ada does not specify whether tasks should  
> be
> native. What about providing tasks scheduled by the RTL (or user), in
> addition to the native tasks, not as a replacement. Such tasks would have
> many limitations regarding I/O, but no more coroutines would. And they  
> will
> be lighter than native tasks.
If you mean kind of green threads, I would say no, as I guess you mean  
something pre‑emptive, and I mean something sequential with no  
concurrency, like with sub‑program invocation in a single task.

There are ways to workaround it with actual Ada, but that's not handy.  
There is the state machine which requires to flatten the conditional  
structures in a case statement, and that does not help readability and  
maintenance; sometime it comes as the most natural way to express things,  
but not always.



-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada advocacy

[Robert A Duff]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Why did you said “no big loss” about the rendez‑vous? 

That's too big a topic to discuss in the margin of this message.  ;-)
Just a few comments:

Protected objects can do almost everything rendezvous can do,
and I find protected objects to be more flexible.

The main thing I miss when using protected objects is the 'terminate'
alternative (as pointed out by J-P).  The 'terminate' alt works only
with accept statements, not with entry calls.  Also, you can do
multi-way waits with accept statements but not entry calls.
These things are a loss, but not a "big" loss.  These limitations
of protected objects could be fixed, and then rendezvous would
be truly superfluous.

Suppose I have task A that wants to communicate with task B.
When programming in Ada 83, I usually found myself adding
another "passive" task in between A and B.  Passive tasks
look something like this:

    loop
        select
            accept E (...);
            do stuff;
        or
            ...
        or
            terminate;
        end select;
    end loop;

It just feels wrong to me for that to be a task.  It's not
really doing anything; it's just sitting around waiting
to be told what to do -- like a protected object.
The "do stuff" above is likely some simple action
like putting data in a queue or taking it out.
A protected object seems better for that -- perhaps it's
"lower level", but it's the RIGHT level.  And with a protected
object, you don't need a 'terminate' alternative in this case
-- protected objects just go away like any passive object
(say, an integer).

With rendezvous, one of the tasks must know about the other
(i.e. know its name), which increases coupling.

One ought to be able to split out pieces of code into
separate procedures -- that's an important tool for abstraction.
Any language design that inhibits that is questionable, IMHO.
As has been mentioned, accept statements must be lexically
within the task body, which damages this capability.

Rendezvous is a hugely complicated mechanism, which leads to
bugs, not to mention inefficiencies.

- Bob

Re: Ada advocacy

[Robert A Duff]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Why did you said “no big loss” about the rendez‑vous?

Here's an example based on something Tucker showed me that helped
convince me of the merits of protected objects over rendezvous:

    protected P is
        entry E1(...);
        entry E2(...);
    private
        State: Enum := This_State;
    end P;

    protected body P is
        entry E1(...) when State = This_State do
        ...
        end E1;

        entry E2(...) when State = That_State do
        ...
        end E2;
    end P;

In task T:

    select
        P.E1(...);
    else
        ... -- (***)
    end select;

P is always in one of two states: willing to do E1, and willing
to do E2.  At (***), we know that at the moment P.E1 was called,
P was not willing to do E1, and was therefore willing to do E2.
It is impossible for P to be in a state where it is not willing
to do either E1 or E2.  (A state visible to clients, I mean.)

It's not easy to program that using rendezvous.  The passive
task has to (actively) loop back around to the select statement,
so there is a small window of time where neither 'accept' is
open.  Small windows of time lead to subtle race conditions.

So you end up adding yet more task(s) to implement simple things
like locks.  So using rendezvous tends to add complexity to
the program.

Using an active entity (a task) to program something that
should be passive (which is what you end up doing with
rendezvous) is an abstraction inversion.  It's like killing
a gnat with a sledge hammer.

- Bob

Re: Ada advocacy

[Dmitry A. Kazakov]

On Thu, 29 Aug 2013 16:47:04 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Wed, 28 Aug 2013 19:25:59 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
> 
>> 1. preemptive or not?
> No. Otherwise just use task.

I rather meant things like asynchronous system traps and task mailboxes.
I.e. when the task gets interrupted to perform some actions and then
continues. I believe an implementation would require distributed overhead
and rather poor latencies.

>> 3. how much of the context where given execution path is nested would be
>> accessible?
> Explicitly bounded.

Visibility of the context would meant additional overhead for switching
co-routines.
 
> There are ways to workaround it with actual Ada, but that's not handy.

Note really. It is impossible to convert callbacks into sequential code
without co-routines.
  
> There is the state machine which requires to flatten the conditional  
> structures in a case statement, and that does not help readability and  
> maintenance; sometime it comes as the most natural way to express things,  
> but not always.

Yes, I don't consider this horror as a workaround.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada advocacy

[Jeffrey R. Carter]

On 08/29/2013 08:28 AM, Robert A Duff wrote:
>
>   Also, you can do
> multi-way waits with accept statements but not entry calls.

You can do

select
    P1.E1; -- An entry call.
then abort
    P2.E4; -- Another entry call.
end select;

to wait for 1 of 2 entry calls, and you can nest another ATC in there to do 3, and so on to whatever depth you like, so 
I don't really see a reason for the language not to provide a multi-way select for entry calls.

> It just feels wrong to me for that to be a task.  It's not
> really doing anything; it's just sitting around waiting
> to be told what to do -- like a protected object.
> The "do stuff" above is likely some simple action
> like putting data in a queue or taking it out.
> A protected object seems better for that -- perhaps it's
> "lower level", but it's the RIGHT level.  And with a protected
> object, you don't need a 'terminate' alternative in this case
> -- protected objects just go away like any passive object
> (say, an integer).

Sure. You should use a passive construct for a passive concept. One of Ada 83's problems was the lack of such a thing. 
Ada 95 added the protected object, which partially solves the problem; however, sometimes you need mutual exclusion for 
something that has to perform a potentially blocking action, and you can't use a protected object for that, so you're 
back to using a task for something passive.

Some Ada-83 compilers, such as the DEC compiler, had "passive tasks", which were essentially protected objects without 
functions and without the restriction on what they could do. I think standardizing that concept would have been a better 
solution than introducing protected objects with their limitations.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python and the Holy Grail

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Re: Ada advocacy

[Jeffrey R. Carter]

On 08/29/2013 08:46 AM, Robert A Duff wrote:
>
>      protected P is
>          entry E1(...);
>          entry E2(...);
>      private
>          State: Enum := This_State;
>      end P;
>
>      protected body P is
>          entry E1(...) when State = This_State do
>          ...
>          end E1;
>
>          entry E2(...) when State = That_State do
>          ...
>          end E2;
>      end P;
>
> In task T:
>
>      select
>          P.E1(...);
>      else
>          ... -- (***)
>      end select;
>
> P is always in one of two states: willing to do E1, and willing
> to do E2.  At (***), we know that at the moment P.E1 was called,
> P was not willing to do E1, and was therefore willing to do E2.
> It is impossible for P to be in a state where it is not willing
> to do either E1 or E2.  (A state visible to clients, I mean.)

That's not quite right. P can also be executing E1 or E2, in which case it is not "willing" to do either. T will end up 
at (***) in both of those cases as well.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python and the Holy Grail

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Re: Ada advocacy

[johannes falcone]

Thank you for the info.

Re: Ada advocacy

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> That's not quite right. P can also be executing E1 or E2, in which case
> it is not "willing" to do either. T will end up at (***) in both of
> those cases as well.

I don't think you mean "P can also be executing...", you mean "some task
can also be executing...".

But anyway, no, unless I'm missing something, there are only two
possible states.  If some task is executing the body of P.E1, then P
must be locked.  So if another task comes along and tries to call one of
the entries, it will try to lock P, and will not proceed until the first
task leaves E1.  At that point, the second task will check the barrier[*],
and find it in one of the two possible states.[**]

The state "inside E1 or E2" is not an externally visible state,
so it doesn't really exist (from the clients' point of view).

In my previous message, I said that for the corresponding "passive task"
attempt to implement the same thing, the "will not accept E1 or E2"
state IS externally visible, because it could be going around the loop
back to the 'select'.  But now you've reminded me that the same thing
happens if the passive task is inside one of the 'accept' statements.

[*]That's one way to think of it, but it doesn't really matter which
task checks the barrier and executes the entry body.  In the so-called
"on behalf of" implementation model, the first task will do those things
on behalf of the second task, and then both tasks will proceed.

[**]Note that on a uniprocessor, the second task won't be running while
the first task is inside E1.  The first task's priority has been raised
to the ceiling of P, and if the second is higher than that, that's a
ceiling violation.

- Bob

Re: Ada advocacy

[Jeffrey R. Carter]

On 08/30/2013 09:54 AM, Robert A Duff wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:
>
>> That's not quite right. P can also be executing E1 or E2, in which case
>> it is not "willing" to do either. T will end up at (***) in both of
>> those cases as well.
>
> I don't think you mean "P can also be executing...", you mean "some task
> can also be executing...".

If we're going to use informal, active phrasing such as "P is willing" we can also say "P is executing" without fear of 
misunderstanding.

> But anyway, no, unless I'm missing something, there are only two
> possible states.  If some task is executing the body of P.E1, then P
> must be locked.  So if another task comes along and tries to call one of
> the entries, it will try to lock P, and will not proceed until the first
> task leaves E1.  At that point, the second task will check the barrier[*],
> and find it in one of the two possible states.[**]

That's even worse. Task T is delayed waiting for the other task to complete execution of P.E1, which can be a long time. 
Those of us who are not language lawyers (especially those who started with Ada 83) expect a conditional entry call to 
send the calling task to the else part immediately if the entry call cannot proceed. (Maybe that's not what the language 
rules say, but that's how it's usually presented.) Once T sees that P is locked, it should go to the else part. If the 
author of T were willing to be delayed waiting to get access to P, T would have used a timed entry call.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python and the Holy Grail

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Re: Ada advocacy

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> On 08/30/2013 09:54 AM, Robert A Duff wrote:
>> "Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:
>>
>>> That's not quite right. P can also be executing E1 or E2, in which case
>>> it is not "willing" to do either. T will end up at (***) in both of
>>> those cases as well.
>>
>> I don't think you mean "P can also be executing...", you mean "some task
>> can also be executing...".
>
> If we're going to use informal, active phrasing such as "P is willing"
> we can also say "P is executing" without fear of misunderstanding.

Fair enough.  You're right -- I didn't misunderstand you.

>> But anyway, no, unless I'm missing something, there are only two
>> possible states.  If some task is executing the body of P.E1, then P
>> must be locked.  So if another task comes along and tries to call one of
>> the entries, it will try to lock P, and will not proceed until the first
>> task leaves E1.  At that point, the second task will check the barrier[*],
>> and find it in one of the two possible states.[**]
>
> That's even worse.

I don't think so.  I'll try to explain why below.

>...Task T is delayed waiting for the other task to
> complete execution of P.E1, which can be a long time.

It can be, but it should not be.  Entry bodies should be kept short
(at least in real-time systems, or other cases where such things
matter).

But in any case, it's what you want in this case -- task T must be
"delayed waiting" until the other task has (quickly, we hope) set the
state to one of the two possible states.  We don't want it to see some
oddball intermediate state.

>...Those of us who
> are not language lawyers (especially those who started with Ada 83)
> expect a conditional entry call to send the calling task to the else
> part immediately if the entry call cannot proceed.

"Immediately" does not mean "in zero time".  Not in Ada RM jargon,
anyway.

In the rendezvous case, the task doing the conditional entry call is
quite likely to take LONGER (in real time) to notice that the entry is
not open (than in the protected object case).  And therefore longer to
jump to the 'else' part.  I have implemented this stuff, and I know what
goes on behind the scenes -- there's (hidden) locking in the rendezvous
case, too, and yes that means that it can take some time to decide to
jump to the 'else'.

>... (Maybe that's not
> what the language rules say, but that's how it's usually presented.)
> Once T sees that P is locked, it should go to the else part.

That semantics doesn't seem like a good idea to me, because "P is
locked" means "P is in the middle of a state change".  The whole point
of locking is to prevent clients from seeing that "in the middle" state.

>...If the
> author of T were willing to be delayed waiting to get access to P, T
> would have used a timed entry call.

A timed entry call with "delay 0.0" has identical semantics to a
conditional entry call.  In both cases (rendezvous and protected
object), the calling task has to lock something before it can decide
whether the call can be done "immediately", and that locking takes
nonzero time.

Think about the semantics of a timed call with "delay
0.000_000_000_000_000_000_001".

- Bob

Re: Ada advocacy

[Yannick Duchêne (Hibou57)]

Le Thu, 29 Aug 2013 23:43:30 +0200, Jeffrey R. Carter  
<spam.jrcarter.not@spam.acm.org> a écrit:
> Some Ada-83 compilers, such as the DEC compiler, had "passive tasks",

Via a representation pragma?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Ada advocacy

[Jeffrey R. Carter]

On 08/30/2013 03:41 PM, Robert A Duff wrote:
>
>
> In the rendezvous case, the task doing the conditional entry call is
> quite likely to take LONGER (in real time) to notice that the entry is
> not open (than in the protected object case).  And therefore longer to
> jump to the 'else' part.  I have implemented this stuff, and I know what
> goes on behind the scenes -- there's (hidden) locking in the rendezvous
> case, too, and yes that means that it can take some time to decide to
> jump to the 'else'.

That's surprising to learn, and useful to know.

The ARM-83 used the called task's place in its execution, as I recall: if the called task was at an accept for the 
called entry, or at a select with an open alternative for the called entry, then the rendezvous took place; otherwise, 
the calling task took the else part. ARM-95 changed that to whether the call was queued: if the call was queued at any 
point, the call is canceled and the caller takes the else part; otherwise the caller remains in the select part.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python and the Holy Grail

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Re: Ada advocacy

[Jeffrey R. Carter]

On 08/30/2013 04:52 PM, Yannick Duchêne (Hibou57) wrote:
> Le Thu, 29 Aug 2013 23:43:30 +0200, Jeffrey R. Carter <spam.jrcarter.not@spam.acm.org> a écrit:
>> Some Ada-83 compilers, such as the DEC compiler, had "passive tasks",
>
> Via a representation pragma?

Yes. I recall reading somewhere that the Ada-80 and -83 design team expected compilers to automatically recognize 
passive tasks, and I recall reading papers on algorithms for doing so, but I think no actual compilers did so.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python and the Holy Grail

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Re: Ada advocacy

[Shark8]

On Friday, August 30, 2013 6:05:38 PM UTC-6, Jeffrey R. Carter wrote:
> 
> Yes. I recall reading somewhere that the Ada-80 and -83 design team expected compilers to automatically recognize 
> passive tasks, and I recall reading papers on algorithms for doing so, but I think no actual compilers did so.


That's very interesting.

Re: Ada advocacy

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> wrote in message 
news:kvofa4$dnc$1@adenine.netfront.net...
> On 08/29/2013 08:28 AM, Robert A Duff wrote:
>>
>>   Also, you can do
>> multi-way waits with accept statements but not entry calls.
>
> You can do
>
> select
>    P1.E1; -- An entry call.
> then abort
>    P2.E4; -- Another entry call.
> end select;
>
> to wait for 1 of 2 entry calls, and you can nest another ATC in there to 
> do 3, and so on to whatever depth you like, so I don't really see a reason 
> for the language not to provide a multi-way select for entry calls.

The idea was extensively studied during the Ada 9x process, and the 
conclusion was that it would be very expensive to implement. (I forget why, 
but there should be papers on the topic somewhere in the Ada 9x documents.) 
Moreover, the hard real-time users were the ones doing the lobbying for the 
feature, and it was abundantly clear that they would not be able to use it 
because of latency issues. (It certainly would have been excluded from 
Ravenscar.)

Your workaround is also insanely expensive, but at least that is obvious 
syntactically ("abort" should "feel" expensive to an Ada programmer in a way 
that an entry call should not.)

                                    Randy.

Re: Ada advocacy

[Shark8]

On Friday, August 30, 2013 6:05:38 PM UTC-6, Jeffrey R. Carter wrote:
> 
> Yes. I recall reading somewhere that the Ada-80 and -83 design team expected compilers to automatically recognize passive tasks, and I recall reading papers on algorithms for doing so, but I think no actual compilers did so.


I did a little searching and it appears that DEC Ada (on OpenVMS) did implement passive tasks; see this: http://odl.sysworks.biz/disk$vaxdocsep953/decw$book/d37aaa15.p142.decw$book

Re: Ada advocacy

[Dirk Craeynest]

In article <adb155d2-cf6d-4db9-8eb2-43471b04e654@googlegroups.com>,
Shark8  <onewingedshark@gmail.com> wrote:
>I did a little searching and it appears that DEC Ada (on OpenVMS) did
>implement passive tasks; see this:
>http://odl.sysworks.biz/disk$vaxdocsep953/decw$book/d37aaa15.p142.decw$book

FYI, in the late 80s early 90s, the Verdix Ada compiler (VADS) also
provided passive tasks and task types (via a pragma).

Dirk
Dirk.Craeynest@cs.kuleuven.be (for Ada-Belgium/-Europe/SIGAda/WG9 mail)

*** 19th Intl.Conf.on Reliable Software Technologies - Ada-Europe'2014
*** June 23-27, 2014 **** Paris, France **** http://www.ada-europe.org

Re: Ada advocacy

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> The ARM-83 used the called task's place in its execution, as I recall:
> if the called task was at an accept for the called entry, or at a select
> with an open alternative for the called entry, then the rendezvous took
> place; otherwise, the calling task took the else part. ARM-95 changed
> that to whether the call was queued: if the call was queued at any
> point, the call is canceled and the caller takes the else part;
> otherwise the caller remains in the select part.

That's not really a change.  If you stick to Ada 83 features, you
get the same behavior.  The reason for the new wording is for
requeue (which is a handy feature).

- Bob

Re: Ada advocacy

[Egil H H]

On Thursday, August 29, 2013 11:43:30 PM UTC+2, Jeffrey R. Carter wrote:
> You can do
> 
> 
> 
> select
> 
>     P1.E1; -- An entry call.
> 
> then abort
> 
>     P2.E4; -- Another entry call.
> 
> end select;
> 
> 
> 
> to wait for 1 of 2 entry calls, and you can nest another ATC in there to do 3, and so on to whatever depth you like, so 
> 
> I don't really see a reason for the language not to provide a multi-way select for entry calls.
> 

There's a race condition here:
1. P1.E1 is not open, P2.E4 is open and starts to execute.
2. P1.E1 becomes open while P2.E4 is still executing.
3. P2.E4 is not aborted, as entries are abort deferred regions
4. P1.E1 and P2.E4 is both executed and run to completion.

Re: Ada advocacy

[G.B.]

On 02.09.13 09:13, Egil H H wrote:
> On Thursday, August 29, 2013 11:43:30 PM UTC+2, Jeffrey R. Carter wrote:
>> You can do
>>
>>
>>
>> select
>>
>>      P1.E1; -- An entry call.
>>
>> then abort
>>
>>      P2.E4; -- Another entry call.
>>
>> end select;
>>
>>
>>
>> to wait for 1 of 2 entry calls, and you can nest another ATC in there to do 3, and so on to whatever depth you like, so
>>
>> I don't really see a reason for the language not to provide a multi-way select for entry calls.
>>
>
> There's a race condition here:
> 1. P1.E1 is not open, P2.E4 is open and starts to execute.
> 2. P1.E1 becomes open while P2.E4 is still executing.
> 3. P2.E4 is not aborted, as entries are abort deferred regions
> 4. P1.E1 and P2.E4 is both executed and run to completion.

Assuming that P1 and P2 are POs (or passive tasks), there is
just one program counter applying to both. Won't this
prevent P1 and P2 from running at the same time?

Re: Ada advocacy

[Egil H H]

On Monday, September 2, 2013 10:41:02 AM UTC+2, G.B. wrote:
> 
> Assuming that P1 and P2 are POs (or passive tasks), there is
> 
> just one program counter applying to both. Won't this
> 
> prevent P1 and P2 from running at the same time?

An asynchronous select statement may be executed concurrently,
or even in parallel on a multi-processor platform.
(and it is with Gnat on Linux)

Re: Ada advocacy

[Martin]

Third (at least)...

Pascal/D80 for Ericsson's D80 processor...developed by Ada's own John Barnes!

My first "pro" job used this...fantastic language, fantastic tools and a fantastic processor. 25 years later and we're just about at the same context switch speed on PowerPC/i7 boards.