Ichbiah's Letter

Ichbiah's Letter

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!news.aero.org!jordan]

Omnes:

I read Ichbiah's letter to C. Anderson (as I'm sure many of you did).
I came away feeling a bit depressed, since I was seriously swayed
by the accumulated 'force' of Ichbiah's arguments.

I've spent the past few weeks trying to read and comprehend a recent 
mapping spec (v1.4).  I've not addressed any of the tasking related changes.  
I'm quite familiar with Ada'83, have also taught a C++ course) and I'm 
struggling with Ada'9X and wondering what herculean effort will be required 
by the uninitiated C or C++ programmer.

I want 9X to not only succeed, I also want it to be an obvious and superior
alternative to C++ in my lifetime.

I think some of Ichbiah's words 'enjoy' another hearing (I sure relished them):

 (aesthetics)
 "More than most people, I am driven by aesthetic considerations and the 
  strong belief that only beautiful shape can be correct shape." 

 "Alltogether, my impression of the present proposal reminds me of my awe when
  first crossing this bridge in Boston: the Mystic River Bridge. It certainly
  met the requirements but the accumulation and clutter of metal was
  oppressive and threatening and ... my preference will always go to the
  Golden Gate Bridge. The first had engineered features, the second had an
  Architect and a prodigious Architecture with charm."

 (homeric allusion, prophesy?!)
 "(Unlike Cassandra, I speak here with experience. Like Cassandra, however, 
  I may share the dual attributes of being right and not believed.)  

 (upward [in]compatibility)
 "Success of 9X will not happen unless it is a superset of current Ada:
  Existing compilers will have to be maintained for their current 
  applications and the resources do not exist to maintain two separate 
  families of compilers."

 "Moreover, very strict upward compatibility is a prerequisite for the 
  strategy of gradual introduction of 9X features in existing Ada compilers."

 "With the 9X revision process, we were considering a language revision, 
  as opposed to the design of an entirely new language." 

 (focus)
 "The priority for OOP comes from a real market requirement - these features
  will attract new users to Ada - and also from the ability to reuse the
  significant work that was done in libraries of classes for C++ and Turbo
  Pascal.  So it is part of the effort to interface Ada with the outside world
  and to reuse software and methods that are developed outside Ada."

 (complexity)
 "Moreover, the choice of Ada over some competing language such as C or C++
  is not going to depend on the presence of tasking features since these
  competing alternatives do not have any.  On the contrary, the presence in
  9X of features that they do not use could be an argument for not using the
  language as people fear the distributed inefficiencies that are commonplace
  for implementation of new languages (and with the level of change presently
  contemplated, 9X would be a new language to which the fine-tuning that took
  place for Ada in the past ten years would not apply)."

 (hierarchical libraries)
 "The feature may be well-designed, but it is nevertheless dead weight.  In
  addition, it has been shown to undermine one of the most valuable conceptual 
  assets of Ada: the safety of packages (with unwanted self-proclaimed 
  children getting access to the private part)."

 (solution)
 "I think that the 9X program requires a very substantial reorientation to
  succeed: I see more risk in continuing in the present course than in
  attempting a courageous reorientation."

I'd like to hear a response from the '9X team to each of these.  
Or do I ask too much?

--Larry


"Ted Holden delendus est"

Re: Ichbiah's Letter

[Robert Firth]

In article <1qfku0INN5f9@news.aero.org> jordan@aero.org (Larry M. Jordan) write
s:

> (homeric allusion, prophesy?!)
> "(Unlike Cassandra, I speak here with experience. Like Cassandra, however, 
>  I may share the dual attributes of being right and not believed.)  

Yes.  Cassandra, Princess of Troy, was the daughter of King Priam.  The
god Apollo became enamoured of her, and offered her whatever she asked,
in return for her favours.  She demanded the gift of prophecy.

However, in what is perhaps the world's oldest recorded tease game, she
then refused to keep her part of the bargain, so Apollo gave her a second
gift: that, though she would always predict truthfully, she would never
be believed.

> "Moreover, very strict upward compatibility is a prerequisite for the 
>  strategy of gradual introduction of 9X features in existing Ada compilers."

This is the point where I got sad.  Consider, for example, that Ada 9X
adds many new reserved words to the language.  Anyone who has lived
through the evolution of the Cobol language over the past 30-odd years
will be vividly aware what a disaster that is, forcing you to change
not just code but designs, specifications, data dictionaries, system,
software and user documentation, libraries and bindings, tools that
generate Ada as an intermediate language, ...

And to hear a mamber of the new team dismiss this problem as no big deal...

Re: Ichbiah's Letter

[enterpoop.mit.edu!spool.mu.edu!howland.reston.ans.net!noc.near.net!inmet!]

The Ada 9X Mapping/Revision team is in a Distinguished Reviewers meeting
this week, and probably will not see the request for a response to Ichbiah's
letter until next week.  I think they will respond.

Meanwhile, since I sometimes wear the Intermetrics Ada Marketing hat, I 
thought I'd contribute some genuine "words from marketing" to this discussion. 
 
You may find a partial response to some of Dr. Ichbiah's points herein, but 
bear in mind that this is NOT the official mapping team response -- it's just 
my opinion.

Here are some things I will and do say 
in a marketing capacity:

1. The major new features in Ada 9X are OOP, tighter realtime, and hierarchical
libraries.

2. 9X has real OOP, with inheritance and polymorphism.  Ada 9X classes are
not identical to the C++ or SmallTalk versions, but provide the same
capability.  The major distinction is that in Ada 9X, modularity is independent
from hierarchy.  In Ada 9X, OOP is well-integrated with the other language
features, and all of the existing software engineering facilities work smoothly
with OOP.  Ada 9X is an excellent OOP language, even for applications
where maintainability and safety are not overriding issues.

3. Realtime programmers needed facilities for synchronizing that were more
predictable and had lower overhead.  These facilities are provided by Ada 
9X Protected Types.  Protected types can be implemented by very efficient
techniques that avoid process swaps and queueing.

4. Hierarchical libraries reduce the compilation time requirements for large
systems, and provide another effective mechanism for hiding details of
implementations from the users of those implementations.

5. The addition of OOP features, and the use of hierarchical libraries to
reduce compilation times, will make Ada 9X highly competitive with C++ and,
in my opinion, much better than C++.

6. Dr. Ichbiah's diatribe against Ada 9x is unfortunate.  His view that OOP
should be the only major extension has been outweighed by the demands of users
for improvements.  Every proposed change in Ada 9X was requested by the user
community, and the general applicability and importance of the request was
carefully weighed through a open requirements analysis process.  The 
Mapping/Revision team is proud of having meet all of the requirements with 
so few new constructs and with so few incompatible changes.  

Intermetrics made several proposals to further simplify the Ada language, by 
removing complexities and exotic special cases from the base (Ada '83) 
language.  However, the 9X team decided that upwards compatibility was
more important than simplifying the base language, and these simplifying
proposals were dropped.  Ada 9X adds only moderate complexity, and is extremely
 
upward compatible.

7. We will be marketing Ada 9X into markets outside the DOD.  For example,
Ada 9X will have a booth at OOPSLA.  However, in the commercial marketplace
it is very inappropriate to start selling products before they are available.
We will be at Object World and similar conferences as soon as we can promise
an availability date for Ada 9X compiler systems.  (You may note that 
Intermetrics is already demonstrating a class browser for Ada 9X as a
technology -- we will be demonstrating it as a product soon).

8. Perhaps the generals who are now saying "Ada hasn't worked, lets do somethin
g
else" are the ones who never gave Ada a try.  They dodged the mandate for
years, and now are unable to stay in the closet with their other languages,
so they are trying to fight now.  If I owned the Defense Department ;-), I'd
order them to shut up until they have done all of their programs in Ada for
three years; if they still have a problem then, I'd listen.  In a way, I 
consider the currrent outcry a positive sign; it means that the mandate is 
finally beginning to affect the whole DOD, and not just the highly visible 
major weapon systems.

9. I acknowledge that it is very hard to learn Ada 9X from the current
documentation.  The forthcoming reference manual will be usable by a wider 
range of engineers than the current ILS or the earlier mapping documents.  
John Barnes is writing a Rationale which is still more readable, and there
will be training tapes made as well.  Eventually the textbooks, on-line
tutorials, training programs and other introductory material will be 
available.  We'll need all of this stuff as soon as compilers hit the street
but until then, concentrating on the full formal semantics in a reference
format is the best way to pin down the details of the revision.

-- Mike "removing marketing hat, donning flame-proof suit" Ryer
   Intermetrics, Inc.

Re: Ichbiah's Letter

[Robert I. Eachus]

In article <1993Apr14.091604.389@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) 
writes:

  > This is the point where I got sad.  Consider, for example, that Ada 9X
  > adds many new reserved words to the language...

     Usually Robert, you are precise in your use of English.  Where
are the many new reserved words?  (Current proposal is three: aliased,
protected, and tagged.)

     There will be new identifiers in packages STANDARD, SYSTEM, and
TEXT_IO, and there will be new predefined library units.  But those
identifiers are not reserved, and for the most part will only affect
those programs which use new features.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ichbiah's Letter

[Michael Feldman]

In article <EACHUS.93Apr14140822@spectre.mitre.org> eachus@spectre.mitre.org (R
obert I. Eachus) writes:
>In article <1993Apr14.091604.389@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth)
 writes:
>
>  > This is the point where I got sad.  Consider, for example, that Ada 9X
>  > adds many new reserved words to the language...
>
>     Usually Robert, you are precise in your use of English.  Where
>are the many new reserved words?  (Current proposal is three: aliased,
>protected, and tagged.)
>
Hmmm - did I miss something? Did UNTIL go away (as in DELAY UNTIL <time>)?
If so, better tell Barnes to take it out of the intro dicument :-)

Mike Feldman

Re: Ichbiah's Letter

[Alex Blakemore]

In article <1993Apr14.091604.389@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) 
writes:
> Consider, for example, that Ada 9X adds many new reserved words to the langua
ge.

just so no one takes this out of context, Ada9X adds only five keywords:
  aliased  protected  tagged  requeue  until

to the original 63 for a total of 68 keywords
that's less than an 8% increase in keywords in 10 years.
(or less that 1% per year :-)

still far from COBOL's league.
did C++ add new keywords to C?



-- 
Alex Blakemore       alex@cs.umd.edu        NeXT mail accepted
--------------------------------------------------------------
"Without an engaged and motivated human being at the keyboard,
the computer is just another dumb box."      William Raspberry

Re: Ichbiah's Letter

[Alex Blakemore]

ryer@dsd.camb.inmet.com (Mike Ryer) writes:
> since I sometimes wear the Intermetrics Ada Marketing hat, I 
> thought I'd contribute some genuine "words from marketing" to this discussion
. 

> Ada 9X will have a booth at OOPSLA.

nice start

> However, in the commercial marketplace
> it is very inappropriate to start selling products before they are available.

ha ha ha ha :-) :-)

are you sure you work in marketing for a computer software vendor?
what commercial marketplace are you familiar with?
-- 
Alex Blakemore       alex@cs.umd.edu        NeXT mail accepted
--------------------------------------------------------------
"Without an engaged and motivated human being at the keyboard,
the computer is just another dumb box."      William Raspberry

Re: Ichbiah's Letter

[news]

In article <1qfku0INN5f9@news.aero.org>, jordan@aero.org (Larry M. Jordan) writ
es:

[...basically, "Woe is us..."]

and then

>"Ted Holden delendus est"

The thing which amazes me about Ichbiah's letter is the extent to which
he confirms most if not all of what I claimed about Ada9x in my infamous
Ada-woe BBS post.  It appears now that we have Ichbiah and Hoare on the
same side of this question, Grady Booch and all other former Ada players
with brains and talent advertising C++ products and add-ons in the journals,
and little other than lost souls and/or dead wood still in the fold.

Face it.  It's over.  The fat lady has sung...  it's time to go home.


-- 
Ted Holden
HTE

Re: Ichbiah's Letter

[usenet.ufl.edu!eng.ufl.edu!spool.mu.edu!sdd.hp.com!cs.utexas.edu!utnut!no]

I missed the letter that generated this thread. Could someone email it
to me?
--
Matt Kasun  - Developing a Meta-model for dynamic change management

Voice: (613) 837-9627
email: kasun@sce.carleton.ca

Re: Ichbiah's Letter

[Alex Blakemore]

Robert I. Eachus writes:
> Current proposal is three [new reserved words]: aliased, protected, and tagge
d.

the March 29 AARM also lists "until" and "requeue" as reserved words.
Have they been dropped since then?
(I sure hope not, the functionality is important and very difficult to emulate 
in Ada83)
-- 
Alex Blakemore       alex@cs.umd.edu        NeXT mail accepted
--------------------------------------------------------------
"Without an engaged and motivated human being at the keyboard,
the computer is just another dumb box."      William Raspberry

Re: Ichbiah's Letter

[Dave Hawk]

: It's time to go home.
: -- 
: Ted Holden

Yes, please do.

Re: Ichbiah's Letter

[Wes Groleau X7574]

In article <1993Apr15.091100@lglsun.epfl.ch> magnus@lglsun.epfl.ch (Magnus Kemp
e) writes:
>The proposal was made because we opposed the introduction of underlines
>at the end of identifiers--which was supposed to "fix" the problem of
>new reserved words (just add "_" at the end of your identifiers if they
>have become reserved...).

The trailing underscore is a quick fix that can be easily automated.  It is
NOT a good idea to allow it to remain in code when actually doing maintenance
on that code.  There is a tramendous risk of complexity in semantic analysis
if words like "until" or "tagged" are not reserved.

>The trailing underline won.  Here is an example of what will be legal
>(as submitted by the French ISO delegates):
>
>     subtype new_ is integer;
>     constant_ : constant := 0;
>     range_ : constant := constant_;
>     dot_dot : constant := constant_;
>     type is_ is new new_;
>     subtype subtype_ is is_ range range_ .. dot_dot;

I presume you are pointing out that the trailing underscore makes hideous
code legal.  Well, surprise!  Hideous code has always been legal in every
language!  The only reason some of us Ada fans aren't aware of that fact
is that we don't see much of it.  The reason we don't see much of it is
that the people who like to write it prefer C where it's easier to do.

>No_ comment_

Sorry, I just HAD to comment_

Re: Ichbiah's Letter

[Michael Feldman]

In article <450@fedfil.UUCP> news@fedfil.UUCP (news) writes:
>
>Face it.  It's over.  The fat lady has sung...  it's time to go home.
>
Best idea I've heard in a long time. Go home, Ted.

Mike

Re: Ichbiah's Letter

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!usene]

In article <C5J0I4.Dn1@crdnns.crd.ge.com> groleau@e7sa.crd.ge.com (Wes Groleau 
X7574) writes:

>I presume you are pointing out that the trailing underscore makes hideous
>code legal.  Well, surprise!  Hideous code has always been legal in every
>language!

I beg to differ.  The point was not that Ada allowed one to write hideous
and unmaintainable code.  the point was that the 9X team had created an
upward incompatibility, and their recommended workaround was the creation
of hideous and unmaintainable code.

Re: Ichbiah's Letter

[David Emery]

The biggest advantage of the trailing underscore is that it now makes
the absolutely horrible VMS naming conventions ambiguous.  Is
	FOO_.ada 
the package specification for package FOO, or the package body for
package FOO_ ?

				dave

Re: Ichbiah's Letter

[Hu Man]

In article <450@fedfil.UUCP> news@fedfil.UUCP (news) writes:
>
>Face it.  It's over.  The fat lady has sung...  it's time to go home.
>
>Ted Holden


  Good.  Go home, then.

Re: Ichbiah's Letter

[pipex!uknet!warwick!zaphod.crihan.fr!univ-lyon1.fr!scsing.switch.ch!sicsu]

In article <C5J0I4.Dn1@crdnns.crd.ge.com>, groleau@e7sa.crd.ge.com (Wes Groleau
 X7574) writes:
: The trailing underscore is a quick fix that can be easily automated.  It is
: NOT a good idea to allow it to remain in code when actually doing maintenance
: on that code.

Right.  Don't you think maintainers will find code in 2015 with
trailing underlines all over the place?

If the goal is really to allow quick, automatized fixes, wouldn't it
be much easier to change the old identifiers into something that uses
the upper-half of ISO Latin-1 (the 8-bit character set that will
replace ASCII in Ada 9X)?  For example, one could choose to change
systematically "Tagged" (old identifier) into "Tagged_83X" (new
identifier since "tagged" is now, needlessly, reserved) where X is,
say, some _striking_ glyph like the section sign (paragraph sign,
"inverted-P-with-bar", decimal code 167).

The characters found in the upper-half of Latin-1 do not exist in ASCII
(since it is/was 7-bit), so such a scheme is as safe as possible.

This approach wouldn't be a "quick fix," and wouldn't defile the beauty of
Ada.  On the other hand, allowing trailing underlines is an invitation
to abuse.  Further, consider what the Ada 83 Rationale states on the
topic of allowing single underlines _in_ identifiers:

  "... an underline character may appear between two other characters
   of an identifier.  This underline is significant and plays the role
   of _space_ in ordinary prose ... the significance of the underline
   makes SPACE_PER_SON a different identifier from SPACEPERSON or
   SPACE_PERSON ..." (p. 6, emphasis mine)

Now, add three unreadable variants: SPACE_PER_SON_, SPACEPERSON_,
SPACE_PERSON_.  How many Ada programmers (code maintainers) explicitly
look for/count with trailing underlines when reading Ada code?  Now, you
can't just assume that identifiers are sequences of words separated by
underline, since identifiers are sequences of anything from beginning to
end, including underlines (except you still can't have two underlines
in a row).  It is quite likely that a lot of coding guidelines will
simply state that "Thou shall not use trailing underlines."

So what's the use?  Is the "quick fix," changing the language, justifiable?


Keywords vs. more reserved words

: There is a tr[e]mendous risk of complexity in semantic analysis
: if words like "until" or "tagged" are not reserved.

The only problem is merely one of syntax analysis:

  type T is tagged private; -- if "tagged" is_ followed by "limited",
                            -- "private", "null" or "record", it's a keyword

  type T is Tagged .. 10;   -- if it is_n't, it isn't (note the use of an
                            -- underline to remove the ambiguity, like it? :-)

Looking at the grammar, I don't think there is room for ambiguity with
"tagged".  Same thing applies for "until", "protected", "aliased" and
"requeue."

So where is the "semantic complexity"?  Should we plan for future revisions
of the language?  (E.g. resolve against the addition of any more reserved
words, just define keywords if needs be?)
-- 
Magnus Kempe                "No nation was ever drunk when wine was cheap."
magnus@lglsun.epfl.ch                                   -- Thomas Jefferson

Re: Ichbiah's Letter

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!torn!]

alex@cs.umd.edu (Alex Blakemore) writes:
: did C++ add new keywords to C?

Let's see: class, this, template, try, catch, throw, public, private,
protected, overload (since removed), operator, virtual, ...

-- 
-------------------------------------------------------------------------------
John English                    | "There are basically two types of dicks,
Dept. of Computing              |  hard dicks and floppy dicks."
University of Brighton          |    -- from a student essay on storage media
E-mail: je@unix.brighton.ac.uk  | "Disks are divided into sex & tractors."
Fax:    0273 642405             |    -- from one of my lectures (on a bad day)
-------------------------------------------------------------------------------

Ichbiah's Letter

[vincent.diemunsch]

Does anyone knows where I could find Jean Ichbiah's resignation letter to Anderson.
I know it might seem quite annoying for some people to read this, especially those
who, like me likes Ada and try to promote the langage, but I really need to 
understand some important things about the design of Ada 9X.

You may reply privately if you prefer.

Vincent

Re: Ichbiah's Letter

[Jeffrey Carter]

On 10/24/2014 11:20 AM, vincent.diemunsch@gmail.com wrote:
> Does anyone knows where I could find Jean Ichbiah's resignation letter to Anderson.
> I know it might seem quite annoying for some people to read this, especially those
> who, like me likes Ada and try to promote the langage, but I really need to 
> understand some important things about the design of Ada 9X.

It is at

https://duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fweb.elastic.org%2F~fche%2Fmirrors%2Fold-usenet%2Fada-with-null

-- 
Jeff Carter
"Sir Robin the not-quite-so-brave-as-Sir-Lancelot,
who had nearly fought the Dragon of Angnor,
who nearly stood up to the vicious Chicken of Bristol,
and who had personally wet himself at the
Battle of Badon Hill."
Monty Python & the Holy Grail
68

Re: Ichbiah's Letter

[David Botton]

I never saw the original letter, he was exactly on the mark!

<<I was also seeing a risk that the Ada community would not follow if the
intellectual "distance" and the upward incompatibility were too high.>>

Things just keep getting worse at least in terms of intellectual "distance", there is _no_ effort being made by any company right not bring the more general aspect of Ada and its benefits to the average programmer. (I'm going to do my part to change that... I like a challenge)

<<I was also hoping that it would be ultimately possible to dress
the new concepts in a simpler, more regular, more attractive, more beautiful
syntax, which could redeem some of the complexity>>

He is my hero! I knew I was not alone in the universe.

<< I have encountered an unusual degree of intolerance to outside contributions>>

Wow, I thought it was just to me since I tend to make spelling errors, love to be chatty when I write code and am a "street" programmer not an Academic.

<<More than most people, I am driven by aesthetic considerations and the strong belief that only beautiful shape can be correct shape.>>

If I had read this when he was alive I would have made a point to visit him, what a shame I never thought to investigate then. He is like my programming spirit mentor. I think I understand my affinity to Ada now.

I write my API first then make the code fit it later to try and force the beauty in to it.

I can't stomach the ridiculous thin (even hand done) binding that ignores the language idioms and its beauty. Last night I wanted to puke looking at how C like the Ada binding to Cairo was. I saw a hundred ways to make it beautiful.

<<coldly logic, ultimately ugly - the engineers had it their way and had Ada
9X become Ada with null>>

I bow to the master. Finally logic, sense. The crowning reality of why Ada never manages to get ahead beyond a small Niche. Technically right, but in context off the mark.

<<I consider the lack of interfaces to be the most severe
impediment to increasing usage of Ada - witness the absence of a credible
Ada solution for Windows development - and this diversion of resources from
interfaces severely diminishes the chances for Ada's long term success>>

WOW!! If you only knew the ____extreme____ push back I got form inside AdaCore to push for GWindows or other "interfaces" I've come up with to be supported (so I could continue working on them and get paid to do them)... It is my entire argument for 10 years with key people. I wonder if I am related to this guy!!!

<<Ada struck at the right level:
more complex than Pascal - since it offered facilities that the users needed
- - but not as complex as C++.>>

It is still true thanks to C++ getting even more complex the Ada right around 9X as well.

It is _why_ I love Ada and am still sticking it out.

<<So it meant that average programmers could
develop a level of command of its concepts with which they could develop
programs whose structure, actions, and consequences they understood and
mastered - an absolute requirement for reliability.>>

Finally someone who speaks sense and shows why this is more important that pre and post conditions! Which is not a bad thing to add but is not what will ever make Ada the right choice for most projects.

<<We run the risk of missing the window of opportunity.>>

AND THEY DID! They instead made Ada into a niche language. He is a prophet.

I am hoping Gnoga and future efforts like it by others can still get Ada back in the door of the average user project.

I'll do my part! I will try.

<<The words we use influence the concepts>>

So true, I know it is my weak point.

<<The priority for OOP comes from a real market requirement - these features
will attract new users to Ada>>

Yes 95 really blew it.
Ada OO "looked like" doing OO with Perl ! Still only a bit better.

<<part of the effort to interface Ada with the outside world>>

Yip, still a major issue. Look what it took to make GnatCOM work. I had to implement the entire C++ virtual class structures in Ada.

<<the presence in 9X of features that they do not use could be an argument for not using the language>>

And the continual slide to make Ada in to SPARK is going to bury it forever in a niche market if we don't get some work to bring Ada to the applications world. Which there is no funding or support to do by what exists now, all volunteer work.

<<In acknowledgment of the fact that it has not been possible for me to make
an effective contribution, and also in view of my reluctance to be
associated with something whose complexity I disapprove and whose aesthetics I can neither see nor share>>

I am truly wishing I could have sat down with this man and been so honored.

I only wish I had seen this 10 years ago, I would have fought harder and stayed around the Ada community.

Oh well. I think there is another chance and window of opportunity. I'll just make the fight now.

David Botton

Re: Ichbiah's Letter

[David Botton]

Oh my!!! I think I actually may be related to him.

<<He was a descendant of Jews from Thessaloniki who emigrated to France.>>

I am a direct descendant of the chief rabbis of Thessaloniki.

WOW....

David Botton

Re: Ichbiah's Letter

[vincent.diemunsch]

On Friday, October 24, 2014 8:47:10 PM UTC+2, Jeffrey Carter wrote:
> On 10/24/2014 11:20 AM, vincent.diemunsch@gmail.com wrote:
> > Does anyone knows where I could find Jean Ichbiah's resignation letter to Anderson.
> > I know it might seem quite annoying for some people to read this, especially those
> > who, like me likes Ada and try to promote the langage, but I really need to 
> > understand some important things about the design of Ada 9X.
> 
> It is at
> 
> https://duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fweb.elastic.org%2F~fche%2Fmirrors%2Fold-usenet%2Fada-with-null
> 
> -- 
> Jeff Carter
> "Sir Robin the not-quite-so-brave-as-Sir-Lancelot,
> who had nearly fought the Dragon of Angnor,
> who nearly stood up to the vicious Chicken of Bristol,
> and who had personally wet himself at the
> Battle of Badon Hill."
> Monty Python & the Holy Grail
> 68

Perfect ! Thank you very much, Jeff !
Vincent

Re: Ichbiah's Letter

[Mark Carroll]

vincent.diemunsch@gmail.com writes:

> On Friday, October 24, 2014 8:47:10 PM UTC+2, Jeffrey Carter wrote:
(snip)
>> https://duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fweb.elastic.org%2F~fche%2Fmirrors%2Fold-usenet%2Fada-with-null
(snip)
> Perfect ! Thank you very much, Jeff !

Of course, as an Ada novice, it raises the question for me of to what
extent the voiced concerns were actually borne out. I don't yet know
enough to be able to judge for myself so you'll have to forgive me a
little speculation and language comparison here.

For instance, back in the day, I quite liked Modula-3: when I wrote
code, I could be pretty sure of what it would actually do, and the
language definition was clear and succinct. If Ada aims to lend itself
to, say, high-reliability concurrent systems that need to work in
near-real-time, I can imagine that it helps a lot if the programmers can
do what they need by writing code such that any of them can look at it
and be pretty sure of its exact behavior in a running system. It's not
enough for code simply to be correct -- doing the right thing, as
quickly as one would expect -- but it has to be /obviously/ correct to
the reader (or, if not, it better be backed by a spectacular test suite,
which in concurrency becomes tricky when the scheduler's behavior is a
factor).

So, did Ada get all kinds of confusing extra interacting-features stuff
added? Despite any greater consequent complexity in the compiler or
run-time, is it easy for people needing to write really clear, certain
code to avoid those corners of the language and keep with a
solid-feeling subset, or is it all clear enough that there's no need to
hide from scary corners? (Is the extra complexity worth it, or does it
just make it harder to write compilers and textbooks?)

I run into awkward corners in other languages sometimes. For instance,
there's something I find unintuitive about bit-twiddling in Java
(perhaps some of the automatic casting, and not having unsigned ints, is
a factor) which means that I really need to test that kind of code
carefully before being satisfied it's right; I also try to use patterns
like PECS in littering code with "extends", "super", etc. as seems
appropriate but I still get surprises there, too, though at least those
are compile-time ones. In enterprise Java my guarantees are even fewer:
if the object instances I have in hand are proxy objects from Hibernate,
Spring, etc. then they might look simple but they may hide a lot of
auto-magic complexity. Or, in Haskell, while it feels a whole lot
clearer than Java and I can usually be pretty sure that my code /will/
do what I want, the lazy evaluation, advanced compiler optimization, and
techniques like software transactional memory, often leave me far less
confident about /how quickly/ it will do it: if what I imagined the
compiler could achieve is actually going to come to pass.

Basically, if I am learning about modern Ada, I wonder how soon I'll
reach high confidence about what my code that actually compiles will do
when I execute it, or to what extent I'll have to adopt certain
disciplines, or avoid certain things, to achieve that. For instance, I
would imagine that the contract-based programming offered in Ada 2012 is
actually a move toward greater reliability without making the actual
code that does stuff any harder to understand, and the way they seem to
be written in some logic-based language looks encouraging: plenty of
languages have some kind of "assert <Boolean>" statement, but writing
the predicates declaratively means that the "rephrasing" of at least
some aspect of what the code does might (a) make me think more clearly
and deeply about what it does and (b) being a rephrasing, not propagate
bugs in the code to become matching bugs in how I check that things are
as I thought.

-- Mark

Re: Ichbiah's Letter

[Dmitry A. Kazakov]

On Sat, 25 Oct 2014 10:12:03 +0100, Mark Carroll wrote:

> Of course, as an Ada novice, it raises the question for me of to what
> extent the voiced concerns were actually borne out.

There was much truth in what Ichbiah wrote. Newer versions of Ada added
greatly to complexity. Still all underlying concepts were sound and
necessary. But the shape they took was questionable at best.

The only way to maintain complexity of this sort is breaking a new level of
generalisation. Ada's design consistently failed this which led to a blown
up language.

[...]
> So, did Ada get all kinds of confusing extra interacting-features stuff
> added? Despite any greater consequent complexity in the compiler or
> run-time, is it easy for people needing to write really clear, certain
> code to avoid those corners of the language and keep with a
> solid-feeling subset, or is it all clear enough that there's no need to
> hide from scary corners?

Language subsets is a very popular and deeply wrong idea, IMO. It is
frequently promoted by many in Ada community, e.g. notorious claims that
one could choose if he wanted to use OO features or stay strictly
procedural. Exactly this attitude leads to explosion of complexity as you
need all functionality anyway in all popular subsets of single language.

> Basically, if I am learning about modern Ada, I wonder how soon I'll
> reach high confidence about what my code that actually compiles will do
> when I execute it, or to what extent I'll have to adopt certain
> disciplines, or avoid certain things, to achieve that.

The concept of safe language Ada 83 promoted was that disciplines must have
been a side effect of applying the language rather than of persistent
awareness of the programmer moving across the minefield. From the software
engineering POV, you cannot depend on willingness to follow the rules to
obtain predictable result and desired level of quality.

> For instance, I
> would imagine that the contract-based programming offered in Ada 2012 is
> actually a move toward greater reliability without making the actual
> code that does stuff any harder to understand,

Actually most these features significantly decrease code reliability as
accessibility checks did to Ada 95. Ichbiah mentions them. Presently
approximately 50-80% of all run-time faults are due to false-positive
dynamic checks. I don't know how large will be the rate of false-positive
checks with dynamic constraints. This depends on practice and yet to be
seen. However seeing predicates containing Integer'Value (Text) discussed
here, I would suggest it high.

> and the way they seem to
> be written in some logic-based language looks encouraging: plenty of
> languages have some kind of "assert <Boolean>" statement, but writing
> the predicates declaratively means that the "rephrasing" of at least
> some aspect of what the code does

This is another problem with it. Declarations shall *not* contain
implementation of the behavior. New features do exactly the opposite.

A contract should state verifiable constraints on the implementation. It is
not "what" it is "how".

> might (a) make me think more clearly
> and deeply about what it does and (b) being a rephrasing, not propagate
> bugs in the code to become matching bugs in how I check that things are
> as I thought.

There are two related but different concepts:

1. Contract [how]

2. Correctness proof [what]

#2 includes checking contracts. Neither shall produce executable code. Yes,
both are incredible useful.

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

Re: Ichbiah's Letter

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Presently approximately 50-80% of all run-time faults are due to
> false-positive dynamic checks.

This is certainly not true in the code I have been involved with. In
fact I don't recall ever having seen such a fault (assuming, that is,
that 'false-positive' means that it's some non-obvious consequence of
Ada's rules).

Re: Ichbiah's Letter

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyppdg8k7q.fsf@pushface.org...
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> Presently approximately 50-80% of all run-time faults are due to
>> false-positive dynamic checks.
>
> This is certainly not true in the code I have been involved with. In
> fact I don't recall ever having seen such a fault (assuming, that is,
> that 'false-positive' means that it's some non-obvious consequence of
> Ada's rules).

If you use anonymous access types unsafely (that is, to convert them to 
other types), it will happen a lot. If you use anonymous access types 
sparingly (mostly as a stand-in for out parameters in functions, a 
work-around you don't need in Ada 2012), you won't run into *dynamic* 
accessibility checks. (Dynamic checks are only possible in generic bodies 
and with anonymous access types.)

Similarly for the checks associated with class-wide types. If you don't 
derive tagged types in subprograms, you'll never see one of those checks (if 
everything is library-level, no check is possible). And again, almost all of 
those checks are static.

                         Randy.

Re: Ichbiah's Letter

[Jacob Sparre Andersen]

> https://duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fweb.elastic.org%2F~fche%2Fmirrors%2Fold-usenet%2Fada-with-null

Reading the letter, I must say that I disagree with Ichbiah on some of
the Ada 9X features which he wanted dropped:

+ Aliased objects:

  I have more than one program I don't know how I could have implemented
  sensibly without aliased objects.

+ Protected types:

  I've heard of the term "passive tasks", but I simply don't know how I
  should have written some of my more complex tasking applications
  without using protected objects.

- Decimal types:

  Okay. - One place where I must admit that I only know of example
  sources using this.

+ Unsigned types:

  Something I use quite a lot and find it hard to imagine managing
  without.  Also, how would one interface with C et al. without unsigned
  types?

- Access parameters:

  I suspect that allowing "in out" parameters for functions is a better
  idea than having access parameters. - One more where Ichbiah may well
  be right.

- Accessibility (checks):

  It seems like this definitely is a part of the language, which has
  ended up being too complicated for anyone to understand, but I am not
  in a position to say anything sensible about how to avoid them in the
  language.

+ Tagged types and dispatching:

  Well.  Although Ichbiah puts tagged types on his list of complicated
  features, he still argues for them further down in the letter.  I
  suppose that we agree.

+ Barriers:

  One of those features I can't see how one can manage without.

+ Self-proclaimed children:

  What a wonderful term.  And a feature I have used to append
  compatiblity interfaces to existing libraries, without having to go in
  and modify the existing, stable library.

+ Separate compilation:

  It may not be needed for compilation speed, but it is an excellent way
  of managing multiple implementations for the same interface.

I am happy to have seen this letter, but overall, I think Ichbiah was
not ambitious enough in his view of what Ada could become.

I agree with Ichbiah's belief that the availability of good GUI
libraries should increase the use of Ada, but somehow it doesn't
happen. - Maybe because the GUI libraries aren't good enough.


Ichbiah (and many others) argue strongly for upward compatibility from
one version of Ada to the next.  While I can see the point, I still feel
that we as a community should be prepared to learn, and to remove the
worst mistakes we have introduced into the language.  I know that
breaking compatibility will split the development of pre- and
post-change compilers, but are there changes we can make, which might
both reduce the development cost of post-change compilers and increase
the quality of post-change software development?  Interfaces and
anonymous access types are the candidates I can remember being
critisised most, but can we remove them and still create equally good
software?


Greetings,

Jacob
-- 
"Lots of information, strong cast, but a bit weak on the narrative."
              -- Pratchet, Stewart & Cohen reviews a phone directory

Re: Ichbiah's Letter

[Simon Clubley]

On 2014-10-26, Jacob Sparre Andersen <jacob@jacob-sparre.dk> wrote:
>
> - Decimal types:
>
>   Okay. - One place where I must admit that I only know of example
>   sources using this.
>

Can I assume you have never done any accounting work ?

> + Unsigned types:
>
>   Something I use quite a lot and find it hard to imagine managing
>   without.  Also, how would one interface with C et al. without unsigned
>   types?
>

If anything, unsigned integers should be the default integer type and
you should need to ask for a signed integer in the code. (And yes,
I know that in Ada, you just choose a data type to model the problem
at hand. This is more an annoyance of mine from other languages such
as C.)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: Ichbiah's Letter

[invalid]

On 2014-10-26, Jacob Sparre Andersen <jacob@jacob-sparre.dk> wrote:
>> https://duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fweb.elastic.org%2F~fche%2Fmirrors%2Fold-usenet%2Fada-with-null
>
> Reading the letter, I must say that I disagree with Ichbiah on some of
> the Ada 9X features which he wanted dropped:

> - Decimal types:
>
>   Okay. - One place where I must admit that I only know of example
>   sources using this.

In the IBM environment this is essential for financial applications. To
replace existing PL/I or COBOL systems or to allow Ada to be used for new
development in a large percentage of applications, support for decimal types
would have been essential. This is based on IBM's hardware decimal support
which was present from the beginning of S/360 in 1964, which is mostly
absent in other platforms (and should not be confused with floating point
decimal in IEEE or other variations). 

> + Unsigned types:
>
>   Something I use quite a lot and find it hard to imagine managing
>   without.  Also, how would one interface with C et al. without unsigned
>   types?

On a system where C is irrelevant (IBM until very recently) this
(C-interface) ould not have been an issue. Certainly at the time of Ada 95
C was irrelevant in the IBM environment. In general though, the absence of
unsigned types would have been a black mark in contending against PL/I for
example and possibly even COBOL.

> + Barriers:
>
>   One of those features I can't see how one can manage without.

Some hardware and OS don't require barriers. IBM MVS is an example where
this problem is defined away (does not apply) because the hardware and OS
specification precludes the issue from arising.

Re: Ichbiah's Letter

[Jacob Sparre Andersen]

Simon Clubley wrote:
> On 2014-10-26, Jacob Sparre Andersen <jacob@jacob-sparre.dk> wrote:

>> - Decimal types:
>>
>>   Okay. - One place where I must admit that I only know of example
>>   sources using this.
>
> Can I assume you have never done any accounting work ?

Given my claim, it could be true.  Now that you pose the question, I do
actually have a single (simple) business use application using decimal
types.

Most of the accounting work I've done has been in PL/SQL.  But right now
I can't remember if we had access to decimal types there.

Greetings,

Jacob
-- 
"We will be restoring normality as soon as we are sure what is normal anyway."

Re: Ichbiah's Letter

[Dennis Lee Bieber]

On Sun, 26 Oct 2014 17:59:12 +0000 (UTC), invalid <address@is.invalid>
declaimed the following:

>In the IBM environment this is essential for financial applications. To
>replace existing PL/I or COBOL systems or to allow Ada to be used for new
>development in a large percentage of applications, support for decimal types
>would have been essential. This is based on IBM's hardware decimal support
>which was present from the beginning of S/360 in 1964, which is mostly
>absent in other platforms (and should not be confused with floating point
>decimal in IEEE or other variations). 
>
	Scientific Data Systems (later Xerox Data Systems) Sigma series also
supported hardware Decimal (Packed BCD)... True, the Sigma were created by
IBM renegades <G> (they also used EBCDIC)

	I recall the term when most CompSci classes were rolling merrily along
-- all but the COBOL based courses... The Decimal hardware was out of
operation for most of the term.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Ichbiah's Letter

[Shark8]

On 26-Oct-14 11:46, Simon Clubley wrote:
>> + Unsigned types:
>> >
>> >   Something I use quite a lot and find it hard to imagine managing
>> >   without.  Also, how would one interface with C et al. without unsigned
>> >   types?
>> >
> If anything, unsigned integers should be the default integer type and
> you should need to ask for a signed integer in the code.

If anything Ada should have disconnected "signed v. unsigned" and 
"cyclic v. over-/under-flow" instead of having modular-integers.

Re: Ichbiah's Letter

[Shark8]

On 26-Oct-14 10:28, Jacob Sparre Andersen wrote:
> + Separate compilation:
>
>    It may not be needed for compilation speed, but it is an excellent way
>    of managing multiple implementations for the same interface.

Separate compilation -- throwing the implementation in another file -- 
can also be a pretty good way to present a cleaner, shorter "main body" 
to an implementation and keep some "more-complicated but needed" 
processing separated out; example: parsing for a data-type, say on their 
'Input and 'Output attributes.

Re: Ichbiah's Letter

[Randy Brukardt]

"Jacob Sparre Andersen" <jacob@jacob-sparre.dk> wrote in message 
news:87mw8ivlr4.fsf@adaheads.sparre-andersen.dk...
>> https://duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fweb.elastic.org%2F~fche%2Fmirrors%2Fold-usenet%2Fada-with-null
>
> Reading the letter, I must say that I disagree with Ichbiah on some of
> the Ada 9X features which he wanted dropped:
>
> + Aliased objects:
>
>  I have more than one program I don't know how I could have implemented
>  sensibly without aliased objects.
...
> - Accessibility (checks):
>
>  It seems like this definitely is a part of the language, which has
>  ended up being too complicated for anyone to understand, but I am not
>  in a position to say anything sensible about how to avoid them in the
>  language.

If you don't have aliased objects, then you don't need accessibility checks 
(because you can't get the access value of an object). So those two go 
together. Of course, getting the access value of a local object was one of 
the requirements for Ada 9x, so Ichbiah was essentially arguing to ignore 
one of the language requirements. The MRT had some leeway in doing that, but 
hardly enough to drop a number of major requirements.

>+ Tagged types and dispatching:
>
>  Well.  Although Ichbiah puts tagged types on his list of complicated
>  features, he still argues for them further down in the letter.  I
>  suppose that we agree.

No, he argued for Simula classes; the fact that he lost that vote was the 
tripping point for his leaving the Ada 9x process and writing the letter in 
question.

Why he thought that adding a new complex form of visibility was somehow 
better than extending an existing form of type (the Ada 83 derived type) 
still escapes me to this day. (At worst, they're about the same in overall 
complexity.) There may have been compelling arguments in favor of a class 
type, but "complexity" wasn't one of them. (Indeed, I recall arguing that 
basing anything on derived types, a very obscure corner of the language, was 
going to make things harder for Ada users. But the class type would not have 
helped that at all -- something totally new isn't easy to learn, either. And 
the actual problems in practice, particularly overriding, would have been 
just as messed up either way (the syntax has nothing to do with it).)

                                          Randy.

Re: Ichbiah's Letter

[Georg Bauhaus]

On 27.10.14 23:10, Randy Brukardt wrote:
> the class type would not have
> helped that at all -- something totally new isn't easy to learn, either.

If this means "fundamental types" vs "class types", hasn't this
distinction been successful in mainstream languages (no matter what
the type theorists say)?