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!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Languages don't  matter.  A mathematical refutation
Date: Sat, 04 Apr 2015 13:44:49 -0700
Organization: A noiseless patient Spider
Message-ID: <87pp7j62ta.fsf@jester.gateway.sonic.net>
References: <b3592526-729a-4198-a630-696542b3f3be@googlegroups.com>
	<87h9t95cly.fsf@jester.gateway.sonic.net>
	<04f0759d-0377-4408-a141-6ad178f055ed@googlegroups.com>
	<mfkt8l$u4j$1@dont-email.me> <871tk1z62n.fsf@theworld.com>
	<w19y3129v8q1.jkn83uwyte4p$.dlg@40tude.net>
	<87oan56rpn.fsf@jester.gateway.sonic.net>
	<ojcuhapfmqleoec1r4fu7ierr3p85in78r@4ax.com>
	<877fts7fvm.fsf@jester.gateway.sonic.net>
	<cutvhal9n5jobh5ojsof28r9hncdjabbvk@4ax.com>
	<87twwv66pk.fsf@jester.gateway.sonic.net>
	<32ecaopodr1g.1xqh7ssdpa2ud.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="c694756f1077760bb5296aae16c74092";
	logging-data="19288"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+LZN02LJNAJsK7padNBwmS"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:+5x0XBl2PKkByUCFFQHZRGtUGqQ=
	sha1:A7NiPe97RiPzBB/WxYVbf7wKSwk=
Xref: news.eternal-september.org comp.lang.ada:25425
Date: 2015-04-04T13:44:49-07:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> In Ada memory management is automatic

Do you mean something other than stack allocation and "new"?  For most
of us, automatic memory management means gc.

> Indeterministic time is of minor importance compared to
> indeterministic behavior in general, which means the program being
> non-testable and unmaintainable.  

Dennis said specifically, his program needs determinstic time.  Some
programs are like that.

> Since GC cannot be statically analyzed, because if it could be, you
> would not need GC,

That's a cool observation, thanks for it.

> having it non-testable eliminates all means of quality assurance. End
> of story.

I don't think that's right.  Being unable to statically analyze GC means
you can't prove your program will never crash from memory exhaustion.
In avionics, that may be intolerable and you better not use GC.  In
other areas (example: compilers), you may care more that your program
never computes a wrong result than that it never crash, so if after
reasonable testing it doesn't seem to have memory leaks, you are fine
and GC is great.