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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13035 invoked from network); 6 Feb 2022 05:06:43 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Feb 2022 05:06:43 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A40999C0AA; Sun, 6 Feb 2022 15:06:40 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 04FCE9B7AF; Sun, 6 Feb 2022 15:06:26 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="V+PPsGs8"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 1D5729B7AF; Sun, 6 Feb 2022 15:06:24 +1000 (AEST) Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) by minnie.tuhs.org (Postfix) with ESMTPS id D180F9B68F for ; Sun, 6 Feb 2022 15:06:22 +1000 (AEST) Received: by mail-oo1-f49.google.com with SMTP id w5-20020a4a9785000000b0030956914befso9850153ooi.9 for ; Sat, 05 Feb 2022 21:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=/g8KiZGn9bTKbcic2zl10yCRzKPzNpNtxucmlVhiNKI=; b=V+PPsGs8XgCE8Fbc/fO3IToooLk8fJjTeZLyWz60t+/C6uf/6PfCK20lnataixq10g 9D7Z6qPF6rgxnP+pEorxB6HLxDH6X2qZuXBMEGd8FQJg3iyUNuzP+7a7Bk2OTsX/zGnV 8x7NF+9scWV2meGlot/yblVmUztMqbDmvWEtLKNucakFOdwh3a99/32Na5lKVpDxQU8u YuFqbZfmSH/IEsu4fNcPSKKETtUznUJPK1Op63KIurpkZEyuLw3mlLAjBI9EawUcYdUo y+PE+70c/r0EbVRWEYqvCYj4RZxhyNczssLWuqnqFAM3h+2RF3goWKcElamRR7zt/JIi eKvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=/g8KiZGn9bTKbcic2zl10yCRzKPzNpNtxucmlVhiNKI=; b=p3sZCxd9y46eTWhS1cJDruxIwRvzDJFqWNEbliqh35I1Qce6ZigajBbhVz8EMpfGFF jt3Uq4ysilvO8azwB8Oo6j9i45tNpFTewyQtnh3GGppInBzQ0VSoiaev6fPUOdOlO6uL 76kYGVyyTUMULTpr4ke2OQ3X/lfnQ3S3rT/ArzPYYjHHluxOXEF1xyjVJ3c8goLZTNWf 5VN2y0jyPViIznz43OF7Y8/qUDX07L6aCYykDNvK3dolO9eOamTWoAGrm4YREzn8gf+U ALeE/EiaZihVeijIrg/Y/4gxmHWGG6XTfFotyaxmAbIx45Rrun0bWXX6dOzPcl37p+i+ 6xGQ== X-Gm-Message-State: AOAM531Da8EjdqvS3hHcIZwI+Ge7PeWU9LYOp9bYu0dmMi7o9ZedzqzO G58bePYVHw6B02Yx43XNjPsSEK3/QHw= X-Google-Smtp-Source: ABdhPJzIus3O3cIZ8/BcDOKxC0iSJe/NLTzdcgEtdISsLICxhnXOLkM3AIEwM/NIDWg+ytXmoxghZg== X-Received: by 2002:a05:6870:8643:: with SMTP id i3mr1654004oal.91.1644123982104; Sat, 05 Feb 2022 21:06:22 -0800 (PST) Received: from [192.168.1.215] (035-134-121-000.res.spectrum.com. [35.134.121.0]) by smtp.gmail.com with ESMTPSA id a4sm2064496oaa.42.2022.02.05.21.06.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Feb 2022 21:06:21 -0800 (PST) Content-Type: multipart/alternative; boundary="------------BPXwtO9iJyc0tCcFYjiP2vwa" Message-ID: Date: Sat, 5 Feb 2022 23:06:20 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US To: Rob Pike 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: Will Senn In-Reply-To: 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" This is a multi-part message in MIME format. --------------BPXwtO9iJyc0tCcFYjiP2vwa Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sure. It's gone off topic, quite a ways. I wasn't really castigating, just marveling at the hubris. On 2/5/22 10:52 PM, 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. > > --------------BPXwtO9iJyc0tCcFYjiP2vwa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Sure. It's gone off topic, quite a ways. I wasn't really castigating, just marveling at the hubris.

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

--------------BPXwtO9iJyc0tCcFYjiP2vwa--