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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11421 invoked from network); 6 Feb 2022 04:52:56 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Feb 2022 04:52:56 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 9D61B9BAE3; Sun, 6 Feb 2022 14:52:53 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id B7D2B9B7AF; Sun, 6 Feb 2022 14:52:27 +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="gtTmimIs"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 8A5A59B7AF; Sun, 6 Feb 2022 14:52:25 +1000 (AEST) Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by minnie.tuhs.org (Postfix) with ESMTPS id CFFDD9B68F for ; Sun, 6 Feb 2022 14:52:24 +1000 (AEST) Received: by mail-pj1-f49.google.com with SMTP id m7so9590546pjk.0 for ; Sat, 05 Feb 2022 20:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qm0HLbk+F8wfNJqyh6424v3L0idulVDPfYKvJX6F0t8=; b=gtTmimIsfFz66QPC+8vUPwuphWxaPyKtUTyQzoYuWxQlPWnyEtv+iBbnAnfCkpXWHG 8IVLZrixL+7K9IpuxQtB63qOq56LChRVY6y1WTmiGO8vB4Geuie4fDBtpc0E6igkiaXf 3iDcam3voGfbDzkaAEatxwkp7NQoMBTYCeWQzlzn8btcgX/stlqwySbWqsvtoUKJh6QR rrSyvPBn33PQdR3H7EXTITHuDvLGKVBryYJpMNaY0PF9IFMAwmXKja8R4l8tHenhlPWc 9hJg8HN1e1gIF51zhIeHqL2GpOSH+/l/ONImQllZTnYGv4yCCqm2lvA6V9W6nbV50lmD qPbw== 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=qm0HLbk+F8wfNJqyh6424v3L0idulVDPfYKvJX6F0t8=; b=afPdK5Sohyxz1ckIxysraqPSIjQaC72K1UxOgwfIXaehtGhsgqv+jCLhVARmAkJ9zR 4qn1PmofncUimJRBCkGsBLkFi80/ZVOJLD1Nu8P3ZnkKoJ4uK0NBHzfxFP42FCTyjXaN +bzyS7SKyV+4oLp//BzLng2wlpFipZcA+OIMtl7wAC8MgagTkehX2wddQxoEAw2ZrsTM OZPSoka02Cj/YjjufqZCOMzfxys2iAn27u0H6m9DMJYY/QoiCFbMfCG6iIums9D8VQc0 vLljkz2y0Tne45IsWzHr/Aa5G117hC5OHNdmhCP/Y0Mz8fYodIlUIa8I3EPkMMi4WHEx I1Mg== X-Gm-Message-State: AOAM5332fqaVZL6qeJvkeLuWKycwUX6ztW2yUWQeI+WM4TYDTcbrBpQi 4UYnoqoudVJ1RBqZ/h2BBhcOVPqZk56eeY3eNHM= X-Google-Smtp-Source: ABdhPJwWXnUXyLlJ0JXCMXQLCdciu5roxl5Up9r43Jjtfyg9Brkz9zGSQ+8mVNR4YGC0p4MTD0KUpJc0lwtzKBP/bp4= X-Received: by 2002:a17:903:11c9:: with SMTP id q9mr10865897plh.144.1644123143882; Sat, 05 Feb 2022 20:52:23 -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: <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> From: Rob Pike Date: Sun, 6 Feb 2022 15:52:12 +1100 Message-ID: To: Will Senn Content-Type: multipart/alternative; boundary="000000000000f54c7305d7523f28" 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" --000000000000f54c7305d7523f28 Content-Type: text/plain; charset="UTF-8" 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. > > > --000000000000f54c7305d7523f28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Be careful with your castigations. Yes, there is lots of o= ld working code, but keep in mind that that code has often not been as wide= ly tested and deployed as much of the software that runs today. The fact th= at it worked well on old hardware doesn't mean it will be suitable for = modern networked remotely administered multicore machines pounded on by mil= lions of people.

And speaking of multicore, it's possible to wr= ite 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&= #39;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 envi= ronment.

Lately this list has a lot of attitude an= d prejudice pretending to be wisdom and superiority.

-rob


On Sun, Feb 6, 2022 at 12:11 PM Will Senn <= ;will.senn@gmail.com> wrote:<= br>
=20 =20 =20
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 th=
is.  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 withou= t 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.


--000000000000f54c7305d7523f28--