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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,3ef3e78eacf6f938
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Tue, 21 Jul 2009 18:42:30 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
Newsgroups: comp.lang.eiffel,comp.lang.ada
Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
References: <h3sln0$rhm$2@news.eternal-september.org>
 <h41n4c$pm0$1@news.eternal-september.org>  <h42da2$lcr$1@aioe.org>
 <h42he3$nt9$1@news.eternal-september.org>  <h42j7b$rl2$1@aioe.org>
 <d78335ef-fc51-46cc-bb73-031f6e0a16ad@k1g2000yqf.googlegroups.com>
 <h435uc$djn$1@aioe.org> <prv34h.o2c.ln@hunter.axlog.fr>
 <h44l9m$uid$1@aioe.org>
In-Reply-To: <h44l9m$uid$1@aioe.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <4a65eff6$0$30235$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 21 Jul 2009 18:42:30 CEST
NNTP-Posting-Host: 74a5a578.newsspool1.arcor-online.net
X-Trace: 
 DXC=WEULX15WbW]U6b:FjPaGjQic==]BZ:af^4Fo<]lROoRQ^YC2XCjHcbYK@IAnBOcfkX;9OJDO8_SKVNSZ1n^B98iZXkKT`:2S8m]
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.eiffel:381 comp.lang.ada:7254
Date: 2009-07-21T18:42:30+02:00
List-Id: <comp.lang.ada>

Cesar Rabak schrieb:
>  All this
> discussion about avoiding programmer errors can be attained instead of
> creating four nicknames for Float to allow:
> 
> procedure makePointXY(X : Float; Y : Float) is
>    begin
>       null; --Whatever.
>    end;
> 
> procedure makePoint_R_Theta(R : Float; Theta : Float) is
>    begin
>       null; --Whatever.
>    end;
> 
> Do you agree the programmer will find the mistake easily as well?


How is the example you have given different from

  procedure informalHint_H001(A : ANY; B : ANY) is
    begin
      null;
    end;

  procedure informalHint_H002(A : ANY; B : ANY) is
    begin
      null;
    end;

with the procedure names replaced to match some
formal terms from the problem domain, but the types
left as is?
And what should we conclude then?

We need a solid general case here, I think, to get this
argument away from things that are accidental.  What's the
power of a type when it comes to program construction?


Floats are an issue here.  Let my insignificant finger
point at a strange mental, but measurable, line that language
makers and programmers alike draw
- between types reflecting elementary school experience,
- and types that they themselves defin, carefully[*].

Int, float, and char are taken to be meaningful rocksolid
concepts!
To the effect that every other week you see a CERT
advisory putting our noses into a dangerous mud of int
overflows (and buffer overflows), risking entire systems'
operation.
Isn't this a <emphasis void="crescendo">hint</emphasis>
that *not* bothering with elementary types is an
EMBARRASING_MISTAKE of programming men and women!?
Well, at least if programming errors of this careless
kind do not contribute to our staying in business.


[*] Dabbling in basics of mathematics, I noticed that the
more prominent an author is or was, the higher his awareness
of the fact that we *don't* know what numbers are,
or how we manipulate them (Landau, Halmos, Weyl,
Dirichlet/Dedekind---I just looked at some intriguing
material, not the entire stuff).