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: fac41,9a0ff0bffdf63657
X-Google-Attributes: gidfac41,public
X-Google-Thread: 1108a1,9a0ff0bffdf63657
X-Google-Attributes: gid1108a1,public
X-Google-Thread: f43e6,9a0ff0bffdf63657
X-Google-Attributes: gidf43e6,public
X-Google-Thread: 103376,4b06f8f15f01a568
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Why C++ is successful
Date: 1998/08/08
Message-ID: <dewar.902579285@merv>#1/1
X-Deja-AN: 379140633
References: <dewar.902415458@merv>
 <6qg3on$kjq$2@reader1.reader.news.ozemail.net>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 902579585 15665 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada
Date: 1998-08-08T00:00:00+00:00
List-Id: <comp.lang.ada>

Jason says

<<Question: how does the pointer structure of a program get corrupted?
Not by being "incorrect", since a language that implements garbage
collection (properly) doesn't give programs control over the pointer
structure of objects in memory.  That's a compiler managed detail.  So,
all you are saying is that programs can't be guaranteed to fufil their
specification if they are compiled with a buggy compiler or if they run
on memory hardware that's prone to errors.  That isn't a garbage
collection problem, it's a general problem of implementation.

Perhaps you are thinking of languages like C++ that have pointers and
manual memory management and hence offer eminent chances for incorrect
programs to corrupt their pointer structure with dangling references
and memory leaks.  If so, you are right; 100% safe garbage collection
for C++ is indeed impossible.  Not so for other languages.
>>


I am thinking of languages which provide at least escape hatches for low
level mucking. Note that even languages that you think of as being very
safe often contain such escape hatches:

1. Java allows interface to C
2. SNOBOL-4 allows dynamic loading of asm functions
3. Ada allows low level mucking using chapter 13 features
4. Even SPARK has an escape catch for arbitrary low level code

Obviously not all code requires such mucking, but in the real world, nearly
every large application has some such low level mucking somewhere.

THe combination of GC with this kind of low level mucking is what is
dangerous. Of course if the LLM is carefully controlled, and isolated,
and well tested etc. then things can be controlled, but once you have
these features, it is all too common for them to be overused, and to 
be inadequately controlled.

An amazing number of programmers these days work by writing approximate junk
code, and then spend amazing amounts of time trying to bash the code into
shape using a debugger. I fear that this approach, always worrisome, becomes
positively frightening in a GC+LLM environment :-)