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,NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12082 invoked from network); 6 Feb 2022 04:59:07 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Feb 2022 04:59:07 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A74C79BF73; Sun, 6 Feb 2022 14:59:04 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 811959B7AF; Sun, 6 Feb 2022 14:58:47 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 3917A9B7AF; Sun, 6 Feb 2022 14:58:43 +1000 (AEST) Received: from smtp99.iad3a.emailsrvr.com (smtp99.iad3a.emailsrvr.com [173.203.187.99]) by minnie.tuhs.org (Postfix) with ESMTPS id C968F9B68F for ; Sun, 6 Feb 2022 14:58:41 +1000 (AEST) X-Auth-ID: halbert@halwitz.org Received: by smtp21.relay.iad3a.emailsrvr.com (Authenticated sender: halbert-AT-halwitz.org) with ESMTPSA id BCF77237AA for ; Sat, 5 Feb 2022 23:58:40 -0500 (EST) Content-Type: multipart/alternative; boundary="------------kSbUn686WUDPYMjyritajcfq" Message-ID: <6b7bfa10-65b1-a56e-e143-c8663532b934@halwitz.org> Date: Sat, 5 Feb 2022 23:58:40 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US To: tuhs@minnie.tuhs.org 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> From: Dan Halbert In-Reply-To: X-Classification-ID: 60454b26-87d4-4f16-9a95-8a2921ef1323-1-1 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a multi-part message in MIME format. --------------kSbUn686WUDPYMjyritajcfq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit  Thank you, Rob. I composed a similar reply, and debated whether to send it. You hit all the right points more succinctly and directly. --Dan H. On 2/5/22 23:52, 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. > > --------------kSbUn686WUDPYMjyritajcfq Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit  Thank you, Rob. I composed a similar reply, and debated whether to send it. You hit all the right points more succinctly and directly.  --Dan H.

On 2/5/22 23:52, 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 <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 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.

--------------kSbUn686WUDPYMjyritajcfq--