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
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: newbie, Spark 2014 or Ada 2012
Date: Fri, 10 Jul 2015 17:12:03 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <mnpfvj$khe$1@loke.gir.dk>
References: 
 <974c8db0-c9e8-49d4-8db1-3417ec49217b@googlegroups.com><87k2uenkcw.fsf@nightsong.com><f9be08b2-83fb-4161-a380-80b1efe6df47@googlegroups.com><mndhuj$jqd$1@dont-email.me>
 <87615x9s3o.fsf@jester.gateway.sonic.net><mnevpv$e9i$1@dont-email.me>
 <mnfi3h$c6f$1@speranza.aioe.org><mng275$73n$1@dont-email.me>
 <mng47i$ctt$2@dont-email.me><mnh6ua$avf$1@loke.gir.dk>
 <87pp438tm6.fsf@jester.gateway.sonic.net><mnjuum$it2$1@loke.gir.dk>
 <87d2028dfy.fsf@jester.gateway.sonic.net><mnmcl1$fgb$1@dont-email.me>
 <878uap8539.fsf@jester.gateway.sonic.net>
NNTP-Posting-Host: rrsoftware.com
X-Trace: loke.gir.dk 1436566324 21038 24.196.82.226 (10 Jul 2015 22:12:04 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Fri, 10 Jul 2015 22:12:04 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:26755
Date: 2015-07-10T17:12:03-05:00
List-Id: <comp.lang.ada>

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:878uap8539.fsf@jester.gateway.sonic.net...
...
> Yeah, it's a different development style, as the Chris Smith essay I
> linked to earlier describes.  With Python-like languages, it's SOP to
> write code expecting it to crash, then then rely on the extensive
> runtime type and data checks to quickly diagnose and fix the crashes.
> You can get a module to be pretty solid after a few iterations of this.

I've always used Ada this way (especially on low importance programs). 
There's of course one more step (get rid of the compile-time errors), but 
that's way better than spending lots of time building test harnesses. Ada's 
extensive runtime checks catch most of the rest of the errors.

I hate compile-time errors as much as the next guy, but I hate debugging 
programs a lot more. I expect my programs to work the first time I run them, 
and most do. (And, after a few off-by-one errors, the only programs that 
don't work are the ones that ultimately solved the wrong problem. No 
programming language or system could do anything about that.)

What I want is more compile-time detection of errors to increase the 
likihood that the programs work immediately (or tell me precisely why they 
didn't work). Once you've reached runtime, it's too late for the computer to 
provide much help in getting the program to do what's intended.

                            Randy.