From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,70414f56d810c10c
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.58.162 with SMTP id s2mr65618pbq.20.1316599404627;
        Wed, 21 Sep 2011 03:03:24 -0700 (PDT)
Path: 
 lh7ni1754pbb.0!nntp.google.com!news1.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!news.musoftware.de!wum.musoftware.de!news.weisnix.org!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 21 Sep 2011 12:03:21 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: discriminant questions
References: 
 <9f37b726-d80b-4d24-bf3f-28a14255f7fd@s20g2000yql.googlegroups.com>
 <lxfx9rex4bk2$.1w4y7xefoy8ce.dlg@40tude.net>
 <86015926-d652-4265-aedd-413312d399f9@dq7g2000vbb.googlegroups.com>
 <g2js0od1qaec$.foqplblkqpdw.dlg@40tude.net>
 <0d272f62-67d0-4905-972c-8a7e912c5531@en1g2000vbb.googlegroups.com>
 <148cxoyabima2.16mz6xwdph2hj.dlg@40tude.net> <j58l43$jcp$1@munin.nbi.dk>
 <1b7pl1piwc3hl.7q9fyyq8h3m7.dlg@40tude.net>
 <c1dd08a3-70d1-4cc6-82e7-40630d53b635@a7g2000yqb.googlegroups.com>
 <pvjwyqljhfih.1d1hj4pze7bpl$.dlg@40tude.net>
 <3d49749a-1da5-49b9-bc68-5d9befb4ed62@hb5g2000vbb.googlegroups.com>
 <1gti2q424e3tt$.18e95xse1r7j8$.dlg@40tude.net>
 <862244d4-c7ca-4590-ac97-e2988ac27872@f8g2000yqf.googlegroups.com>
 <1rffjj30r3vtr.1ahkfeok7ia0w.dlg@40tude.net>
In-Reply-To: <1rffjj30r3vtr.1ahkfeok7ia0w.dlg@40tude.net>
Message-ID: <4e79b66a$0$6548$9b4e6d93@newsspool4.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 21 Sep 2011 12:03:22 CEST
NNTP-Posting-Host: 04590bcd.newsspool4.arcor-online.net
X-Trace: 
 DXC=L<RmIFTMaQT5TOT9_N5i<V4IUK<Cl32<Q4Fo<]lROoRQ8kF<OcfhCO[0cGjm6MEWaVnc\616M64>ZLh>_cHTX3j]:a6VF4CDTST
X-Complaints-To: usenet-abuse@arcor.de
Xref: news1.google.com comp.lang.ada:18067
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Date: 2011-09-21T12:03:22+02:00
List-Id: <comp.lang.ada>

On 21.09.11 10:08, Dmitry A. Kazakov wrote:

> It was one of key advantages of Ada 83 which tried to stay reference vs.
> value agnostic. It is sad to see, started with Ada 95, the drift towards
> IMO wrong direction under the influence of Java et al.

Java and C# at least try to cover the difference between values
and references by providing semi-automatic switching between
the two.  Whether or not covering the difference between
values and references is better than to state it explicitly
is another question.

Why should Ada not provide for the same sugar?  There are two
answers, one positive, one negative.

There is market force of C++ and the fun of C++ and while it is
at odds with both the rationale and with the advantages
of the original ideas behind Ada 83, Ada++ allows people to feel
better with Ada when they can try to write C++ in Ada.  (See
anonymous pointers, avoiding nesting, abbrvt sntx.)

The language market is driven by attractors.

Accessors are in the class of very fashionable attractors.
Extending the notion only a little, Eiffel now has assigners.
Python has properties.  C# has Get/Set within definitions.
Objective-C introduced dot notation for property/setProperty:
methods. Etc etc.  And Ada?

Wait!  These features do not seem to attract all programmers
alike.  For example, Objective-C's dot notation is not welcome
by all Objective-C programmers.  So there is some resistance.

Ada accessors IMHO violate a specific tradition of Ada,
the language: that intentions should either be stated
explicitly, or else there should be some explicit syntax
directly related.  Now we see

  Function_Name (P) := ...;

Everything that we see in this statement, or rather that
we don't see, is an implication.

This is very popular. Intentions of the designers aside,
and instead the intentions of the programmers into focus:
Omissions allow clever, lazy programming, because it reduces
Ada's prodding you into explicitly stating your intention.
Accessors do so by covering mechanism, not showing it.
We do not even get

  Name [P] := ...;

which would at least follow the stipulated Ada tradition of
having special syntax for special mechanism!


Aspects increasingly help quickly work around language design.
It is cheap and effective, you can get short term market success,
follow each trend. They can always modestly extend SPARK if good
old Ada is needed for sanity, clarity, and honesty of expression ...