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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,4afa25b13bea6bcc
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Two dimensional arrays: help
Date: 1998/01/05
Message-ID: <dewar.884014602@merv>#1/1
X-Deja-AN: 312981678
References: <34B0C8A6.B19098B6@a01-unix.gsyc.inf.uc3m.es>
 <dewar.884005840@merv> <68qqlp$25v@top.mitre.org>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 884015100 5147 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1998-01-05T00:00:00+00:00
List-Id: <comp.lang.ada>


Mike said

<<In any computer language or other artistic endeavor, one of the easiest
ways to learn the rules is by examples. In many cases the rules are
so culturally specific that outsiders actually benefit more from
working examples than from the rules at all. In addition, when the rules
change (noteable examples are the loss of efficiency introduced into
unsigned numbers between the rationale and the manual, and the
inconsistency accepted as normal in the ways that stream_io works
on different current versions of gnat), it is impossible to know
the rules except by having access to working examples.
>>

While I agree that programming has aspects of artistry certainly, I strongly
disagree that the analogy means that you should learn programming
*languages* by example.

The trouble is you don't learn rules precisely from examples, you learn
a subset of things that work without really understanding the rules. A
good programmer should aspire to 100% understanding of the subset of the
language they are using, and have an understanding at an appropritae
level of abstraction. I admit immediately that most programmers fail this
requirement!

As for your two off-hand examples, I have no idea what you are talking
about. I know of no "loss of efficiency introduced into unsigned
numbers between the rationale and the manual", you should elaborate.
Certainly the rules in the manual are quite clear, and I see no basis
at all for the claim that it is impossible to know the rules about
unsigned numbers without examples. Remember that the examples in the RM
have absolutely NO normative information at all. If the rules on unsigned
numbers (of course you really mean modular types) are incomplete in the
manual, then examples cannot make up for the incompleteness, indeed any
example that conveyed information not derivable from the RM is plain wrong.
Please justify this suprising allegation with specifics.

Ditto for "inconsistencies" in the way stream_io works in different versions
of GNAT. Again, as far as I know, the stream_io in all versions of GNAT is
consistent with the rules in the RM. If you see inconsistencies, then one of
two things is possible:

(a) you have found a bug, please report it

(b) you have some model of how stream_io might work that is not derivable
from the rules, the stream_io as implemented consistent with these rules
differs from your model. I guess that this is probably the case here, and
it just goes to emphasize what a bad idea it is to try to learn how things
work by guessing from examples rather than reading the rules.

Again, it would be instructive to know exactly what you are referring to,
I suspect it would make a very nice case study showing why learning from
examples is an unreliable way to learn.

Please elucidate both examples.