Ada advocacy

669 views
Skip to first unread message

tonyg

unread,
Mar 20, 2012, 8:54:38 AM3/20/12
to
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?

Ludovic Brenta

unread,
Mar 20, 2012, 9:54:05 AM3/20/12
to
tonyg wrote on comp.lang.ada:
Maybe you could start here: http://www.adaic.org/advantages/

--
Ludovic Brenta.

Marc C

unread,
Mar 20, 2012, 10:39:38 AM3/20/12
to
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)

Ludovic Brenta

unread,
Mar 20, 2012, 11:13:09 AM3/20/12
to
Marc C wrote on comp.lang.ada:
+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.

Georg Bauhaus

unread,
Mar 20, 2012, 11:42:06 AM3/20/12
to
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.

Yannick Duchêne (Hibou57)

unread,
Mar 20, 2012, 12:34:41 PM3/20/12
to
Le Tue, 20 Mar 2012 16:13:09 +0100, Ludovic Brenta
<lud...@ludovic-brenta.org> a écrit:
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

Yannick Duchêne (Hibou57)

unread,
Mar 20, 2012, 12:35:49 PM3/20/12
to
Le Tue, 20 Mar 2012 17:34:41 +0100, Yannick Duchêne (Hibou57)
<yannick...@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.

Jeffrey Carter

unread,
Mar 20, 2012, 2:31:47 PM3/20/12
to
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 ne...@netfront.net ---

Shark8

unread,
Mar 20, 2012, 4:06:31 PM3/20/12
to
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).

an...@att.net

unread,
Mar 20, 2012, 5:42:24 PM3/20/12
to
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 <tonyt...@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=

Shark8

unread,
Mar 20, 2012, 7:05:36 PM3/20/12
to an...@anon.org
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.

Shark8

unread,
Mar 20, 2012, 8:32:01 PM3/20/12
to
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.

Robert Love

unread,
Mar 20, 2012, 9:58:22 PM3/20/12
to
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.

Per Sandberg

unread,
Mar 21, 2012, 1:37:08 AM3/21/12
to
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.

an...@att.net

unread,
Mar 21, 2012, 4:59:23 AM3/21/12
to
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.

tonyg

unread,
Mar 21, 2012, 6:44:18 AM3/21/12
to
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.

KK6GM

unread,
Mar 23, 2012, 12:13:48 PM3/23/12
to
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). :)

Peter C. Chapin

unread,
Mar 25, 2012, 7:10:13 AM3/25/12
to
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

david

unread,
Jun 13, 2013, 11:33:17 AM6/13/13
to
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.

david

unread,
Jun 13, 2013, 11:34:40 AM6/13/13
to
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!

johannes falcone

unread,
Jun 17, 2013, 7:39:12 PM6/17/13
to

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

johannes falcone

unread,
Jun 17, 2013, 7:42:03 PM6/17/13
to
ada has tasklets and uses 16 cpu easily I heard..

johannes falcone

unread,
Jun 17, 2013, 8:07:47 PM6/17/13
to
you should gather a few guys here and add them to the project working remote

kick butt

tmo...@acm.org

unread,
Jun 17, 2013, 8:09:59 PM6/17/13
to
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.

Leo Brewin

unread,
Jun 17, 2013, 8:14:59 PM6/17/13
to
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

Jeffrey Carter

unread,
Jun 17, 2013, 8:59:32 PM6/17/13
to
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
Message has been deleted

Peter Brooks

unread,
Jun 18, 2013, 1:55:23 AM6/18/13
to
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.

Robert A Duff

unread,
Jun 18, 2013, 1:15:07 PM6/18/13
to
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

Bill Findlay

unread,
Jun 18, 2013, 1:43:12 PM6/18/13
to
On 18/06/2013 18:15, in article wccvc5b...@shell01.TheWorld.com,
"Robert A Duff" <bob...@shell01.TheWorld.com> wrote:

> Peter Brooks <peter.h....@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;


Robert A Duff

unread,
Jun 18, 2013, 3:22:38 PM6/18/13
to
Bill Findlay <yald...@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

Bill Findlay

unread,
Jun 18, 2013, 3:30:35 PM6/18/13
to
On 18/06/2013 20:22, in article wcczjun...@shell01.TheWorld.com,
"Robert A Duff" <bob...@shell01.TheWorld.com> wrote:

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.

nevil...@gmail.com

unread,
Jun 19, 2013, 3:29:57 AM6/19/13
to
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

johannes falcone

unread,
Jun 19, 2013, 3:22:17 PM6/19/13
to
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?

Jacob Sparre Andersen

unread,
Jun 19, 2013, 3:34:23 PM6/19/13
to
johannes falcone <vispha...@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

Ludovic Brenta

unread,
Jun 19, 2013, 3:36:51 PM6/19/13
to
johannes falcone <vispha...@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.

Shark8

unread,
Jun 19, 2013, 4:16:04 PM6/19/13
to
On Wednesday, June 19, 2013 1:34:23 PM UTC-6, Jacob Sparre Andersen wrote:
> johannes falcone <vispha...@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.

Yannick Duchêne (Hibou57)

unread,
Aug 27, 2013, 9:34:29 AM8/27/13
to
Le Tue, 18 Jun 2013 19:15:07 +0200, Robert A Duff
<bob...@shell01.theworld.com> 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.


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

Yannick Duchêne (Hibou57)

unread,
Aug 27, 2013, 9:39:54 AM8/27/13
to
Le Wed, 19 Jun 2013 09:29:57 +0200, <nevil...@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?

Bill Findlay

unread,
Aug 27, 2013, 10:08:02 AM8/27/13
to
On 27/08/2013 14:34, in article op.w2g9br0kule2fv@cardamome, "Yannick
Duchêne (Hibou57)" <yannick...@yahoo.fr> wrote:

> Le Tue, 18 Jun 2013 19:15:07 +0200, Robert A Duff
> <bob...@shell01.theworld.com> a écrit:
>
>> Peter Brooks <peter.h....@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

unread,
Aug 27, 2013, 10:13:50 AM8/27/13
to
On 27/08/2013 15:08, in article CE427152.35271%yald...@blueyonder.co.uk,
"Bill Findlay" <yald...@blueyonder.co.uk> wrote:

>
> Just for histrical accuracy, ...

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

J-P. Rosen

unread,
Aug 27, 2013, 5:25:01 PM8/27/13
to
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
Message has been deleted

Maciej Sobczak

unread,
Aug 28, 2013, 3:45:15 AM8/28/13
to
> 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

Dmitry A. Kazakov

unread,
Aug 28, 2013, 3:45:25 AM8/28/13
to
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

Georg Bauhaus

unread,
Aug 28, 2013, 4:58:44 AM8/28/13
to
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.


Dmitry A. Kazakov

unread,
Aug 28, 2013, 5:42:53 AM8/28/13
to
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.

G.B.

unread,
Aug 28, 2013, 7:42:16 AM8/28/13
to
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.

Dmitry A. Kazakov

unread,
Aug 28, 2013, 7:59:13 AM8/28/13
to
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.

G.B.

unread,
Aug 28, 2013, 8:49:51 AM8/28/13
to
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?

Dmitry A. Kazakov

unread,
Aug 28, 2013, 10:07:34 AM8/28/13
to
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.

Eryndlia Mavourneen

unread,
Aug 28, 2013, 11:06:14 AM8/28/13
to
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)

Yannick Duchêne (Hibou57)

unread,
Aug 28, 2013, 12:44:38 PM8/28/13
to
Le Wed, 28 Aug 2013 13:42:16 +0200, G.B.
<rm-dash-...@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).

Dmitry A. Kazakov

unread,
Aug 28, 2013, 1:25:59 PM8/28/13
to
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-...@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.

Dmitry A. Kazakov

unread,
Aug 28, 2013, 1:30:52 PM8/28/13
to
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.
Message has been deleted

Dmitry A. Kazakov

unread,
Aug 29, 2013, 3:15:21 AM8/29/13
to
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"
> <mai...@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).

Yannick Duchêne (Hibou57)

unread,
Aug 29, 2013, 10:47:04 AM8/29/13
to
Le Wed, 28 Aug 2013 19:25:59 +0200, Dmitry A. Kazakov
<mai...@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-...@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.

Robert A Duff

unread,
Aug 29, 2013, 11:28:34 AM8/29/13
to
"Yannick Duchêne (Hibou57)" <yannick...@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

Robert A Duff

unread,
Aug 29, 2013, 11:46:18 AM8/29/13
to
"Yannick Duchêne (Hibou57)" <yannick...@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

Dmitry A. Kazakov

unread,
Aug 29, 2013, 3:15:49 PM8/29/13
to
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
> <mai...@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.

Jeffrey R. Carter

unread,
Aug 29, 2013, 5:43:30 PM8/29/13
to
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: ne...@netfront.net ---

Jeffrey R. Carter

unread,
Aug 30, 2013, 12:47:58 AM8/30/13
to
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.

johannes falcone

unread,
Aug 30, 2013, 3:36:50 AM8/30/13
to
Thank you for the info.

Robert A Duff

unread,
Aug 30, 2013, 12:54:26 PM8/30/13
to
"Jeffrey R. Carter" <spam.jrc...@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

Jeffrey R. Carter

unread,
Aug 30, 2013, 1:49:22 PM8/30/13