From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=HTML_MESSAGE, MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24151 invoked from network); 6 Feb 2022 06:40:58 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Feb 2022 06:40:58 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id AC99C9CC48; Sun, 6 Feb 2022 16:40:56 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id D94749B8B1; Sun, 6 Feb 2022 16:40:36 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id A58DA9B8B1; Sun, 6 Feb 2022 16:40:35 +1000 (AEST) Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) by minnie.tuhs.org (Postfix) with ESMTPS id DFE8A9B68F for ; Sun, 6 Feb 2022 16:40:34 +1000 (AEST) Received: by mail-ua1-f54.google.com with SMTP id e17so17871250uad.9 for ; Sat, 05 Feb 2022 22:40:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=67bPtpgTwZZOFMAZb03MZWCYPsdO9D9p/vdw0lL0PlI=; b=lVVrNhk3tjITaEYcsCpwLutmHYCy0S3xhcVhVtJ8JgSvb/uc1Xia/8z6qhtCz24mT/ 0N6DIztfKKeDrRlPnEnOIaAQFujqWuffS9oOoF5UK48XO3cw1Dx1vdK00hzsAYjyv1NN v/jd1C/S/G9uJ0otw8Y1rWAYYnIE0lD3L2tve0TVJFz3xTHpd/O1DWt7/Ko3mLwb84cq ZQuLEL811f0wedeinRJ2Z/Kk1h2+cqSaDFRkCqQ01cuXeZAimKG/NRAcdWFIfZuxBmQo SBVm5Sl/XeprMlLvotRuVtg1ps56KppAn+ycxNn49hX3MKiueiIX4uZ/nddpccKP7CV8 Kl8g== X-Gm-Message-State: AOAM531m+KtuDEnQTP1FSP8EYt4v238PKI5tKA86SG03/HrM6oK2bGXe U1NbuJ7gHb116grmiK+e3Gu+z5v3/6Tjnvnrt7I= X-Google-Smtp-Source: ABdhPJxg2zWVumDXxz3KjS2esVY4IZ4AQIXLMDSKlaub9wKtSI8D7heEUdf3bMvDt6TAyO8Cb5y4Xj/++VIUPp3uAIA= X-Received: by 2002:a67:c10b:: with SMTP id d11mr3118430vsj.39.1644129633873; Sat, 05 Feb 2022 22:40:33 -0800 (PST) MIME-Version: 1.0 References: <20220201155225.5A9541FB21@orac.inputplus.co.uk> <202202020747.2127lTTh005669@freefriends.org> <7C19F93B-4F21-4BB1-A064-0307D3568DB7@cfcl.com> <1nFWmo-1Gn-00@marmaro.de> <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> In-Reply-To: From: Stuart Remphrey Date: Sun, 6 Feb 2022 14:40:20 +0800 Message-ID: To: Rob Pike Content-Type: multipart/alternative; boundary="000000000000cac61705d753c20d" Subject: Re: [TUHS] more about Brian... X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000cac61705d753c20d Content-Type: text/plain; charset="UTF-8" I like the point that malloc()/free() could be seen as a "failure of automation". As to the GC and (Go | Rust) vs (C | Java | C++) earlier in this increasingly-off-topic thread: perhaps it's an issue of whether that automation is applied at runtime or compile-time... (the latter still requiring guidance from the programmer, trading some programmer-brain-time against cpu-execution-time & memory space?) On Sun, 6 Feb 2022, 14:28 Rob Pike, wrote: > I don't understand your disagreement. In what way is automatic memory > management harder, more unsafe, and less robust than hand-written memory > management using malloc and free? > > You seem to think that garbage collection only exists in languages that > have a smell you don't like. Perhaps that's true, but it's been around for > 60 or more years and a lot of important languages use it, while the > programmers that use those languages are often quite capable. > > Using malloc and free might be a badge of honor to some, but it's also a > failure of automation. > > This discussion should probably go to COFF, or perhaps I should just leave > the list. I am starting to feel uncomfortable here. Too much swagger. > > -rob > > > On Sun, Feb 6, 2022 at 5:19 PM Ed Carp wrote: > >> "it's a lot easier, safer, and robust to let the machine do the memory >> accounting" >> >> I disagree. "The machine" is, as you know, is in reality app code >> built on top of frameworks built on top of libraries built on top of >> more libraries built on top of malloc/free calls. While the automated >> testing tools are a lot better than they were when I started coding C >> back in 1985, we're still talking about a *lot* of complexity and a >> lot of layers of code, and programmers today know far less about >> things like boundary conditions, off-by-one bugs, and the like that >> bit us in the ass - hard - and so we learned to watch for those sorts >> of things. >> >> On 2/5/22, Rob Pike wrote: >> > Be careful with your castigations. Yes, there is lots of old working >> code, >> > but keep in mind that that code has often not been as widely tested and >> > deployed as much of the software that runs today. The fact that it >> worked >> > well on old hardware doesn't mean it will be suitable for modern >> networked >> > remotely administered multicore machines pounded on by millions of >> people. >> > >> > And speaking of multicore, it's possible to write code using malloc/free >> > that doesn't leak when run concurrently, but it's a lot easier, safer, >> and >> > robust to let the machine do the memory accounting. And the fact that >> "kids >> > today" can't do it doesn't mean they are lazy or failures, it means they >> > grew up in a different time. And a lot of them are as capable as you >> all, >> > just in a different environment. >> > >> > Lately this list has a lot of attitude and prejudice pretending to be >> > wisdom and superiority. >> > >> > -rob >> > >> > >> > On Sun, Feb 6, 2022 at 12:11 PM Will Senn wrote: >> > >> >> On 2/5/22 6:56 PM, Larry McVoy wrote: >> >> >> >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: >> >> >> >> Hi Thomas, >> >> >> >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: >> >> >> >> I tell you one thing: I never ever experienced any problems with >> >> traditional malloc()/free().?? >> >> >> >> did you ever write a program which does heavy malloc()/free() >> >> on complicated (i.e., shared) data structures *and* runs for >> >> days, perhaps weeks? IMO it's very difficult to do this without >> >> a GC, and you have to exercise quite an amount of discipline >> >> to do it right. >> >> >> >> I've done this and I've employed people who have done this. We're >> >> a dieing breed, the focus seems to be on programming languages and >> >> tools for idiots. People don't want to learn the discipline it takes >> >> to work with malloc()/free(). It's sad. >> >> >> >> >> >> I completely agree. This is ridiculous. Do modern programmer's >> seriously >> >> think that the old code wasn't complex or robust? Sheesh, there's code >> >> out >> >> there that has run through more millions of transactions an hour for >> more >> >> years than most of these folks have been alive. There's also code >> that's >> >> been running without any updates, for decades. Most code written by the >> >> newbreed won't run for a month without surfacing dozens of bugs. >> Margaret >> >> Hamilton would prolly have some choice words for these folks. >> >> >> >> >> >> >> > >> > --000000000000cac61705d753c20d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like the point that malloc()/free() could be seen as a = "failure of automation".

As to the GC and (Go | Rust) vs (C | Java | C++) earlier in this incre= asingly-off-topic thread:
perhaps it's an issue = of whether that automation is applied at runtime or compile-time...


(th= e latter still requiring guidance from the programmer, trading some program= mer-brain-time against cpu-execution-time & memory space?)
<= br>
On Sun,= 6 Feb 2022, 14:28 Rob Pike, <robpi= ke@gmail.com> wrote:
I don't understand your disagreement. In what way is automati= c memory management harder, more unsafe, and less robust than hand-written = memory management using malloc and free?

You seem to thi= nk that garbage collection only exists in languages that have a smell you d= on't like. Perhaps that's true, but it's been around for 60 or = more years and a lot of important languages use it, while the programmers t= hat use those languages are often quite capable.

U= sing malloc and free might be a badge of honor to some, but it's also a= failure of automation.

This discussion should pro= bably go to COFF, or perhaps I should just leave the list. I am starting to= feel uncomfortable here. Too much swagger.

-= rob


On Sun, Feb 6, 2022 at 5:19 PM Ed Carp <erc@pob= ox.com> wrote:
"it's a lot easier, safer, and robust to let the machine do = the memory
accounting"

I disagree. "The machine" is, as you know, is in reality app code=
built on top of frameworks built on top of libraries built on top of
more libraries built on top of malloc/free calls. While the automated
testing tools are a lot better than they were when I started coding C
back in 1985, we're still talking about a *lot* of complexity and a
lot of layers of code, and programmers today know far less about
things like boundary conditions, off-by-one bugs, and the like that
bit us in the ass - hard - and so we learned to watch for those sorts
of things.

On 2/5/22, Rob Pike <robpike@gmail.com> wrote:
> Be careful with your castigations. Yes, there is lots of old working c= ode,
> but keep in mind that that code has often not been as widely tested an= d
> deployed as much of the software that runs today. The fact that it wor= ked
> well on old hardware doesn't mean it will be suitable for modern n= etworked
> remotely administered multicore machines pounded on by millions of peo= ple.
>
> And speaking of multicore, it's possible to write code using mallo= c/free
> that doesn't leak when run concurrently, but it's a lot easier= , safer, and
> robust to let the machine do the memory accounting. And the fact that = "kids
> today" can't do it doesn't mean they are lazy or failures= , it means they
> grew up in a different time. And a lot of them are as capable as you a= ll,
> just in a different environment.
>
> Lately this list has a lot of attitude and prejudice pretending to be<= br> > wisdom and superiority.
>
> -rob
>
>
> On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com= > wrote:
>
>> On 2/5/22 6:56 PM, Larry McVoy wrote:
>>
>> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: >>
>> Hi Thomas,
>>
>> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote:
>>
>> I tell you one thing: I never ever experienced any problems with >> traditional malloc()/free().??
>>
>> did you ever write a program which does heavy malloc()/free()
>> on complicated (i.e., shared) data structures *and* runs for
>> days, perhaps weeks? IMO it's very difficult to do this withou= t
>> a GC, and you have to exercise quite an amount of discipline
>> to do it right.
>>
>> I've done this and I've employed people who have done this= .=C2=A0 We're
>> a dieing breed, the focus seems to be on programming languages and=
>> tools for idiots.=C2=A0 People don't want to learn the discipl= ine it takes
>> to work with malloc()/free().=C2=A0 It's sad.
>>
>>
>> I completely agree. This is ridiculous. Do modern programmer's= seriously
>> think that the old code wasn't complex or robust? Sheesh, ther= e's code
>> out
>> there that has run through more millions of transactions an hour f= or more
>> years than most of these folks have been alive. There's also c= ode that's
>> been running without any updates, for decades. Most code written b= y the
>> newbreed won't run for a month without surfacing dozens of bug= s. Margaret
>> Hamilton would prolly have some choice words for these folks.
>>
>>
>>
>
--000000000000cac61705d753c20d--