The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Ed Carp <erc@pobox.com>
To: Rob Pike <robpike@gmail.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] more about Brian...
Date: Sat, 5 Feb 2022 23:19:55 -0700	[thread overview]
Message-ID: <CACYmRNDzrSvbwnAEAVz=REsdqSs675_pkBhi5dm5iWRCwRVo=A@mail.gmail.com> (raw)
In-Reply-To: <CAKzdPgzSH94Xg=XYYKy6J+dWAD+ZVDzUTNE=YNRkyVRH69PJfA@mail.gmail.com>

"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 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.
>>
>>
>>
>

  parent reply	other threads:[~2022-02-06  6:20 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 20:46 [TUHS] ratfor vibe Will Senn
2022-02-01 15:37 ` arnold
2022-02-01 15:52   ` Ralph Corderoy
2022-02-01 16:58     ` Clem Cole
2022-02-01 17:02     ` silas poulson
2022-02-02  7:47     ` arnold
2022-02-03  5:47       ` [TUHS] more about Brian Rich Morin
2022-02-03  7:44         ` markus schnalke
2022-02-03  8:18           ` Rich Morin
2022-02-04  2:23           ` Adam Thornton
2022-02-04  2:34             ` [TUHS] more about Brian... [really Rust] Jon Steinhart
2022-02-04 13:07               ` Thomas Paulsen
2022-02-04 23:18               ` Dan Cross
2022-02-04  3:28             ` [TUHS] more about Brian Dan Stromberg
2022-02-04  5:11             ` Rich Morin
2022-02-04 21:22               ` [TUHS] Go vs. Rust, and etc. (was: more about Brian...) Greg A. Woods
2022-02-04 21:37                 ` Richard Salz
2022-02-04 22:32                   ` Steffen Nurpmeso
2022-02-04 23:05                   ` Thomas Paulsen
2022-02-04 23:15                   ` Seth J. Morabito
2022-02-05  1:41                     ` Adam Thornton
2022-02-04  7:38             ` [TUHS] more about Brian Andy Kosela
2022-02-04  8:10               ` Steve Nickolas
2022-02-04  8:44                 ` markus schnalke
2022-02-04  9:16                   ` Steve Nickolas
2022-02-04 18:54                 ` John Cowan
2022-02-04 19:45                   ` Thomas Paulsen
2022-02-04 20:28                     ` Hellwig Geisse
2022-02-04 21:03                       ` Jim Capp
2022-02-04 22:30                         ` Steffen Nurpmeso
2022-02-04 22:25                       ` Steffen Nurpmeso
2022-02-06  0:56                       ` Larry McVoy
2022-02-06  1:10                         ` Will Senn
2022-02-06  4:52                           ` Rob Pike
2022-02-06  4:58                             ` Dan Halbert
2022-02-06  5:06                             ` Will Senn
2022-02-06  6:19                             ` Ed Carp [this message]
2022-02-06  6:27                               ` Rob Pike
2022-02-06  6:40                                 ` Stuart Remphrey
2022-02-06  6:44                                 ` Bakul Shah
2022-02-06 19:08                                   ` Steffen Nurpmeso
2022-02-06 12:52                                 ` Ralph Corderoy
2022-02-06 13:14                                 ` Ed Carp
2022-02-06 14:13                                   ` Dan Cross
2022-02-06 14:15                                   ` Larry McVoy
2022-02-06 16:31                                     ` Warner Losh
2022-02-06 18:36                                     ` [TUHS] more about Brian... [ really GC vs malloc/free languages ] Jon Steinhart
2022-02-06 19:27                                     ` Jon Steinhart
2022-02-06 19:33                                       ` Warner Losh
2022-02-06 19:37                                         ` Jon Steinhart
2022-02-06 20:21                                           ` [TUHS] COFF is over there Ralph Corderoy
2022-02-06 16:16                           ` [TUHS] more about Brian Brad Spencer
2022-02-08  5:22                             ` Ed Carp
2022-02-03 18:57       ` [TUHS] ratfor vibe silas poulson
2022-02-04  8:26         ` arnold
2022-02-04 19:41           ` John Cowan
2022-02-10 15:18       ` Ralph Corderoy
2022-02-03  4:00 ` Will Senn
2022-02-03  4:31   ` Al Kossow
2022-02-03  5:16     ` Warner Losh
2022-02-03 20:00   ` Adam Thornton
2022-02-04  6:06     ` Ori Idan
2022-02-04 17:35       ` Adam Thornton
2022-02-04 17:44         ` Will Senn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACYmRNDzrSvbwnAEAVz=REsdqSs675_pkBhi5dm5iWRCwRVo=A@mail.gmail.com' \
    --to=erc@pobox.com \
    --cc=robpike@gmail.com \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).