Path: csiph.com!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: John Ames Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc Subject: Re: Command Languages Versus Programming Languages Date: Mon, 1 Apr 2024 13:44:57 -0700 Organization: A noiseless patient Spider Lines: 18 Message-ID: <20240401134457.000067f2@gmail.com> References: <87edbtz43p.fsf@tudado.org> <20240401111552.00006ddc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Date: Mon, 01 Apr 2024 20:44:59 +0200 (CEST) Injection-Info: dont-email.me; posting-host="6e54db6547ba0cd3cfb65d52cc115a0b"; logging-data="2808884"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/FaVTyt9nYzy6aHoLuR2T4j+gdnNZNDk8=" Cancel-Lock: sha1:GRkrcw/K7QywQKBFNZeVhNuOZ0U= X-Newsreader: Claws Mail 4.2.0 (GTK 3.24.38; x86_64-w64-mingw32) Xref: csiph.com comp.unix.shell:24885 comp.unix.programmer:15632 comp.lang.misc:10305 On Mon, 1 Apr 2024 11:15:52 -0700 John Ames wrote: > And while this is pretty true of scripting languages, it doesn't make > for a good point-of-contrast with "non-scripting" languages; *piles* > of them include support for automatic memory management, and some > (outside of the C family) don't even include facilities for doing it > "by hand." And, in fact, C actually does one specific bit of automatic memory management itself - the stack, which may or may not even *be* a true hardware stack (depending on the architecture,) and which is handled in an entirely transparent fashion* by compiler-generated entry/exit code generated by the compiler for each function. * (Until you go and pass a pointer to a local variable to some piece of code that expects it to still be valid later, natch.)