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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.58.182.137 with SMTP id ee9mr17337449vec.37.1402417919741; Tue, 10 Jun 2014 09:31:59 -0700 (PDT) X-Received: by 10.140.41.35 with SMTP id y32mr114999qgy.1.1402417919682; Tue, 10 Jun 2014 09:31:59 -0700 (PDT) Path: border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!s7no239641qap.1!news-out.google.com!a8ni930qaq.1!nntp.google.com!s7no239640qap.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 10 Jun 2014 09:31:59 -0700 (PDT) In-Reply-To: <175rkz49juygw.xi2489vgfaoa$.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.252.147.203; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 71.252.147.203 References: <3bf7907b-2265-4314-a693-74792df531d1@googlegroups.com> <51e9fd4f-e676-4d2f-9e21-1c782d71092e@googlegroups.com> <5391ffa4$0$6611$9b4e6d93@newsspool4.arcor-online.net> <53942fa4$0$6670$9b4e6d93@newsspool3.arcor-online.net> <234602fb-4571-4b4d-b16c-7a4984511fe4@googlegroups.com> <529e9460-0a3f-476b-9aa4-178dca653a20@googlegroups.com> <175rkz49juygw.xi2489vgfaoa$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: a new language, designed for safety ! From: "Dan'l Miller" Injection-Date: Tue, 10 Jun 2014 16:31:59 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 5085 Xref: number.nntp.dca.giganews.com comp.lang.ada:186808 Date: 2014-06-10T09:31:59-07:00 List-Id: On Tuesday, June 10, 2014 2:44:56 AM UTC-5, Dmitry A. Kazakov wrote: > On Mon, 9 Jun 2014 09:07:07 -0700 (PDT), Dan'l Miller wrote: > > On Monday, June 9, 2014 2:06:27 AM UTC-5, Dmitry A. Kazakov wrote: > >> The language-invented methods here are unsafe because it is not what t= he > >> programmer would normally expect calling them [*]. Thus in both cases = the > >> languages are unsafe. > >> [...snip...] > >> * Robert's definition of unsafety formulated differently: unexpected > >> behavior from familiar syntax ["misuse"]. >=20 > > [Unexpected /=3D undefined] > > No, Dmitry, that is my definition formulated differently, not Robert's.= =20 > > Robert's definition that I was critiquing (and that, in effect, you too > > are critiquing) hinges on *undefined* behaviors in the language > > specification (and constantly remembering to not evoke them is a > > battle-hardened badge of honor in C & C++ culture). *Unexpected* > > behaviors that are well-defined as required in the Ada language > > specification are, by definition, not *undefined* in Ada---hence the ke= y > > point of departure from Robert's excessively-narrow definition of > > "unsafe". >=20 > You draw a line between objectively and subjectively unexpected behavior. No, it is Robert who insists on injecting [objectively] "undefined" into th= is conversation as the sole form of unsafety in a programming language. An= alogous to you, I sweep all undefined behavior, unexpected/unintended behav= ior, gaffs (e.g., =3D where =3D=3D was intended in C), and just plain old b= ad habits into one bucket-o'-stuff that can easily cause deleterious outcom= es (e.g., death or bodily injury). That bucket-o'-stuff is the set of root= -causes of unsafety in imperative programming languages. That bucket-o'-st= uff is a quite-larger proper superset of Mr. Duff's set of root-causes of u= nsafety in imperative programming languages. Btw, the goal of proactively facilitating safeware that Ada partially achie= ves generally tends toward declarative programming (especially at compile-t= ime) that replaces or cross-checks the imperative programming. Imperative = programming by its very nature (except in multistage programming via interp= reters within the compiler) is at run-time. This debate of declarative at = compile-time versus imperative at run-time is the key difference between Ad= a (and to a lesser degree C++ due its numerous undefined behaviors) versus = Objective-C and Swift. > That does not much matter from the software design point of view [*]. The > effect is same. The programmer assumes one thing and the effect is > different. But correctly categorizing [objectively] undefined behavior versus [subject= ively "undefined" to use your term] unexpected/unintended behavior very muc= h does matter to Mr. Duff's definition of unsafe, which I am critiquing as = being too narrow. Likewise, Dmitry, you effectively make the case that Mr.= Duff's definition of unsafe is too narrow by not covering both the [object= ively] undefined and [subjectively "undefined"] unexpected/unintended categ= ories of root causes of unsafety. This is my point as well.