[Info-vax] Userland programming languages on VMS.

[Johnny Billquist]

On 2022-01-30 19:40, Arne Vajhøj wrote:
> On 1/30/2022 1:26 PM, VAXman- at SendSpamHere.ORG wrote:
>> In article <memo.20220130154429.12544b at jgd.cix.co.uk>, jgd at cix.co.uk 
>> (John Dallman) writes:
>>> In article <st4sup$gh9$1 at gioia.aioe.org>, maher_rjSPAMLESS at hotmail.com
>>> (Richard Maher) wrote:
>>>
>>>> And if you can program some MACRO then you need a Garbage Collect
>>>> to cover up your lack of skill in managing memory.
>>>
>>> Not really. Programs written in assembly languages tend to have much
>>> simpler memory management schemes than ones written in high-level
>>> languages. If the program is at all complex, some memory allocation and
>>> deallocation macros are usually written, and one can make those complain
>>> about mismatched allocates and frees.
>>
>> BS.  If/when memory is allocated it needs to be deallocated when it is no
>> longer needed.  Same goes for pushing things on the stack -- push data on
>> and pop data off.  Assembly language programmers are generally just 
>> better
>> at those sorts of things because the results of mucking up are not 
>> pretty.
> 
> ...
> push
> ...
> pop
> ...
> 
> is manageable.
> 
> So is:
> 
> ...
> allocate
> ...
> deallocate
> ...
> return
> 
> The problem arise with the more complex flows where the allocating
> routine pass the pointer on to something and return expecting some
> other code to deallocate.

That is usually because of languages with very poor data ownership 
models, which usually is a side effect of object oriented languages.

Complex flow itself isn't really creating any problems. It's all about 
knowing who owns the data. But when you don't even know what code might 
execute, known what data even exists, or who owns it, becomes a murky 
pool. GC to the rescue (if you like calling that a rescue).

   Johnny