Ada 2005 Language Designer

Ada 2005 Language Designer

[G.B.]

Wikipedia names Jean Ichbiah (1 time) and Tucker Taft
(3 times, starting with Ada 95) as Language designer for
the Ada language,
http://en.wikipedia.org/wiki/Ada_(programming_language)

Pedantically speaking, is this entirely/formally correct?
IIRC, Pascal Leroy was heading the 2005 effort, but I have
no clue, really, as to how the "representative designers"
would be named properly there.

Re: Ada 2005 Language Designer

[David Botton]

Jean Ichbiah - Ada 83

Tucker Taft - Ada 95

Jean Ichbiah started Ada 95, and walked off when they refused to accept that they needed to have Object.Method notations and so we had the dark years from 95-2005 of trying to convince ourselves, that leaving it out was not a retarded decision.....

As per a previous thread, not having Object.Method really hurt Ada at a time when it needed it, now it is an uphill battle to get application developers to look at it seriously again. IMO.

David Botton

Re: Ada 2005 Language Designer

[J-P. Rosen]

Le 08/10/2014 16:16, David Botton a écrit :
> Jean Ichbiah - Ada 83 Tucker Taft - Ada 95
Right. Following versions were designed by the ARG, with the name of the
ARG chair, and Randy Bruckardt holding the pen.

> Jean Ichbiah started Ada 95, and walked off when they refused to
> accept that they needed to have Object.Method notations and so we had
> the dark years from 95-2005 of trying to convince ourselves, that
> leaving it out was not a retarded decision.....
Not at all. Nobody suggested O.M at that time, it was the notion of
tagged type (rather than full classes) and the syntax "with null" that
were the official reasons of his departure. Inofficially, the fact that
the language was becoming Tucker's rather than his...

> As per a previous thread, not having Object.Method really hurt Ada at
> a time when it needed it, now it is an uphill battle to get
> application developers to look at it seriously again. IMO.
> 
I don't think so. Syntactic sugar plays little role; what makes Ada
acceptance difficult is that the profession is not mature enough to
understand that it is time to stop programming computers, and start
designing software applications.

-- 
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 2005 Language Designer

[Adam Beneschan]

On Wednesday, October 8, 2014 8:15:26 AM UTC-7, J-P. Rosen wrote:

> > As per a previous thread, not having Object.Method really hurt Ada at
> > a time when it needed it, now it is an uphill battle to get
> > application developers to look at it seriously again. IMO.
> 
> I don't think so. Syntactic sugar plays little role; what makes Ada
> acceptance difficult is that the profession is not mature enough to
> understand that it is time to stop programming computers, and start
> designing software applications.

Actually, I think it played some role.  I do know of one person who I think was very interested, possibly enthusiastic, about Ada before Ada 95 was released; but after it did, his feeling was, in his words, "Ada blew it".  And I think it was due to the unusual syntax choices that were made: not having operations defined as part of some sort of class type, not having Object.Method notation, perhaps the use of "tagged record".  That's just one person, but I'm sure there were others.  I'm not saying this is the biggest factor hindering Ada acceptance, but I'm certain it was a factor and I tend to think it was a factor of some significance.

                                -- Adam

Re: Ada 2005 Language Designer

[Dmitry A. Kazakov]

On Wed, 8 Oct 2014 11:22:50 -0700 (PDT), Adam Beneschan wrote:

> On Wednesday, October 8, 2014 8:15:26 AM UTC-7, J-P. Rosen wrote:
> 
>>> As per a previous thread, not having Object.Method really hurt Ada at
>>> a time when it needed it, now it is an uphill battle to get
>>> application developers to look at it seriously again. IMO.
>> 
>> I don't think so. Syntactic sugar plays little role; what makes Ada
>> acceptance difficult is that the profession is not mature enough to
>> understand that it is time to stop programming computers, and start
>> designing software applications.
> 
> Actually, I think it played some role.  I do know of one person who I
> think was very interested, possibly enthusiastic, about Ada before Ada 95
> was released; but after it did, his feeling was, in his words, "Ada blew
> it".  And I think it was due to the unusual syntax choices that were made:
> not having operations defined as part of some sort of class type, not
> having Object.Method notation, perhaps the use of "tagged record".  That's
> just one person, but I'm sure there were others.  I'm not saying this is
> the biggest factor hindering Ada acceptance, but I'm certain it was a
> factor and I tend to think it was a factor of some significance.

I think that Ada is too radical to be rejected yet not enough to attract
many.

Object.Method notation would do no difference if Ada visibility rules were
designed in a way that one could not be able to see an object yet not its
operations. This in turn is related to the issue why some subprograms are
operations (methods) and other are not and how not all objects are tagged
(and thus the keyword is needed).

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

Re: Ada 2005 Language Designer

[David Botton]

> Actually, I think it played some role.

I know it played a huge role. I know from trying to push Ada at the time. I  had a working VB like environment (Gnavi, which gwindows and gnatcom are part) including Active X controls and time after time I couldn't get people to even consider it based on that alone. Some were familiar with OO in some of the scripting languages and so could deal with out having a Class like notation, but not having Object.Method made everything look clunky to them.

Yes, thy were not enlightened folk, they were trench Applications developers, but they are the majority....

This time around we'll get em'

David Botton

Re: Ada 2005 Language Designer

[Jeffrey Carter]

On 10/08/2014 07:16 AM, David Botton wrote:
> 
> As per a previous thread, not having Object.Method really hurt Ada at a time
> when it needed it, now it is an uphill battle to get application developers
> to look at it seriously again. IMO.

Ada has always had Object.Operation notation, as long as Object was a pkg or task.

-- 
Jeff Carter
"I would never want to belong to any club that
would have someone like me for a member."
Annie Hall
41

Re: Ada 2005 Language Designer

[David Botton]

> Ada has always had Object.Operation notation, as long as Object was a pkg or task.

True

Re: Ada 2005 Language Designer

[Adam Beneschan]

On Wednesday, October 8, 2014 10:13:52 AM UTC-7, Jeffrey Carter wrote:
> On 10/08/2014 07:16 AM, David Botton wrote:
> 
> > 
> 
> > As per a previous thread, not having Object.Method really hurt Ada at a time
> > when it needed it, now it is an uphill battle to get application developers
> > to look at it seriously again. IMO.
> 
> Ada has always had Object.Operation notation, as long as Object was a pkg or task.

A package is not an object, neither in the sense defined by the Ada RM nor in any other relevant sense.  You can't create multiple instances of it.  And being able to create a variable object (or constant object, or expression that produces an object) and use the dot-notation to call an operation of that object is one of the things programmers came to expect of OO languages that Ada 95 didn't give them; Package.Operation notation is not close to the same thing.

(A task is an object, of course; and so is a protected object, which Ada 95 did provide.)

                                 -- Adam

Re: Ada 2005 Language Designer

[Jeffrey Carter]

On 10/08/2014 11:30 AM, Adam Beneschan wrote:
> 
> A package is not an object, neither in the sense defined by the Ada RM nor in
> any other relevant sense.  You can't create multiple instances of it.  And
> being able to create a variable object (or constant object, or expression
> that produces an object) and use the dot-notation to call an operation of
> that object is one of the things programmers came to expect of OO languages
> that Ada 95 didn't give them; Package.Operation notation is not close to the
> same thing.

Pkg as object was a standard technique for implementing OO designs in Ada 83, in
which a pkg represented an object in the design. Multiple instances were
sometimes implemented as instantiations of a parameterless generic pkg. That
seems like a relevant sense of "object" to me.

Of course, you couldn't have components of such things, so they clearly weren't
objects in the Ada sense.

-- 
Jeff Carter
"I would never want to belong to any club that
would have someone like me for a member."
Annie Hall
41

Re: Ada 2005 Language Designer

[Adam Beneschan]

On Wednesday, October 8, 2014 1:35:37 PM UTC-7, Jeffrey Carter wrote:
> On 10/08/2014 11:30 AM, Adam Beneschan wrote:

> > A package is not an object, neither in the sense defined by the Ada RM nor in
> > any other relevant sense.  You can't create multiple instances of it.  And
> > being able to create a variable object (or constant object, or expression
> > that produces an object) and use the dot-notation to call an operation of
> > that object is one of the things programmers came to expect of OO languages
> > that Ada 95 didn't give them; Package.Operation notation is not close to the
> > same thing.
> 
> Pkg as object was a standard technique for implementing OO designs in Ada 83, in
> which a pkg represented an object in the design. Multiple instances were
> sometimes implemented as instantiations of a parameterless generic pkg. That
> seems like a relevant sense of "object" to me.
> 
> Of course, you couldn't have components of such things, so they clearly weren't
> objects in the Ada sense.

And you couldn't pass it as a parameter to any other subprogram, nor return one from a function.  And you couldn't declare a variable of a class type, and then assign one or the other generic instantiation to that variable.  Those inabilities would make a generic instantiation of a package a very poor substitute for an OO-type object. 

But I suppose the original point, that Ada always had Object.Operation notation because you could use a package as an object, may make sense.  In fact, we could make yet another case: Ada has always had Object.Operation notation, as long as Operation was a record component name.  And then we could try to argue that a record component is a kind of operation.  That should be equally convincing.

                              -- Adam

Re: Ada 2005 Language Designer

[Shark8]

On 10/8/2014 3:26 PM, Adam Beneschan wrote:
> And you couldn't pass it as a parameter to any other subprogram,
> nor return one from a function.

That would be an interesting feature.
Sounds about on-par with LISP's macro functionality; and possibly like 
the multi-staged compiler option one of the people on this forum was 
advocating for Ada 202X.

Re: Ada 2005 Language Designer

[Peter Chapin]

In article <5436ED7B.9080109@gmail.com>, OneWingedShark@gmail.com 
says...

> > And you couldn't pass it as a parameter to any other subprogram,
> > nor return one from a function.
> 
> That would be an interesting feature.
> Sounds about on-par with LISP's macro functionality; and possibly like 
> the multi-staged compiler option one of the people on this forum was 
> advocating for Ada 202X.

Passing modules around as if they were ordinary objects is supported by 
some languages such as Scala. In fact Scala allows you to have multiple 
implementations of a module in the same program... similar to having two 
different package bodies for the same specification in a single Ada 
program. You can even store module objects in other data structures, 
e.g., put them in an array. It's actually quite elegant. However, those 
features are distinct from macros or multi-staged programming, at least 
in Scala's case.

Peter

Re: Ada 2005 Language Designer

[Shark8]

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

On 10/8/2014 12:30 PM, Adam Beneschan wrote:
> A package is not an object, neither in the sense defined by the Ada RM
> nor in any other relevant sense.  You can't create multiple instances of it.

Not quite true.

Generic
   First_Name, Last_Name : String;
Package Person is

   --Operations

end Person;

[...]

  Package Employer is new Person( "Robert", "Dewar" );
  Package Employee is new Person( "Dave",   "Smith" );
  [...]
  Employee.Operation_X( [...] );

[-- Attachment #2: www.cs.dartmouth.edu/reports/TR86-104.pdf --]
[-- Type: application/pdf, Size: 763193 bytes --]

Re: Ada 2005 Language Designer

[brbarkstrom]

On Wednesday, October 8, 2014 9:44:20 AM UTC-4, G.B. wrote:
> Wikipedia names Jean Ichbiah (1 time) and Tucker Taft
> 
> (3 times, starting with Ada 95) as Language designer for
> 
> the Ada language,
> 
> http://en.wikipedia.org/wiki/Ada_(programming_language)
> 
> 
> 
> Pedantically speaking, is this entirely/formally correct?
> 
> IIRC, Pascal Leroy was heading the 2005 effort, but I have
> 
> no clue, really, as to how the "representative designers"
> 
> would be named properly there.

Not having been through any formal training in the object.operation
notation struggles, the OO feeling of Ada packages is clear enough.
You define the data structures you want to disclose in the types 
available through the spec, as well as the functions and procedures
the modify those attributes.  A change in notation might be useful
and make the work easier, but it works well enough in the current
instantiation that a user of the ARM can make it work.

So, after we canonize the original developers, we can make it work.

Bruce B.