The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Larry McVoy <lm@mcvoy.com>
To: Ed Carp <erc@pobox.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] more about Brian...
Date: Sun, 6 Feb 2022 06:15:58 -0800	[thread overview]
Message-ID: <20220206141558.GO3045@mcvoy.com> (raw)
In-Reply-To: <CACYmRNAKUYwVwbn+mXCAVyySV5sVEbZmN4wvQbQKXx-p+nKM=w@mail.gmail.com>

Let's keep it civil and non-personal, I don't think Rob was pointing 
at anyone, I think he was pointing at some not so forward thinking.

I have to side with Rob on this one, even though I'm squarely in the
I like C best camp.

While I _can_ do all the malloc/free stuff myself (and have decades of
working code to prove it), it's become harder and harder to find other
people who can.  Younger programmers just sort of stare at you with a
"I have to do what?" look.  They think you are a dinosaur for working
like that when other reasonable languages do that work for you.

When I did little-lang.org, granted, not widely used but we used it a
lot, it did all the memory management behind the scenes, used reference
counting so you never had the big GC sweep that some languages used,
worked great.  And super pleasant to not have to do all that memory
management.

Having the languages do more for you, and put up guard rails so people
can't make stupid mistakes, seems to be the way of the future.  It's 
not my future, I love C, it does what I want and I can live with what
it needs me to do to have working code.  But I'm a dinosaur and I 
know it.  I'm not trying to push C where people don't want it.

On Sun, Feb 06, 2022 at 06:14:36AM -0700, Ed Carp wrote:
> Since you made this personal and called me out specifically, I will respond:
> 
> "In what way is automatic memory management harder, more unsafe, and
> less robust than hand-written memory management using malloc and
> free?"
> 
> Because there's no difference in the two. Someone had to write the
> "automatic memory management", right?
> 
> "You seem to think that garbage collection only exists in languages
> that have a smell you don't like."
> 
> I said nothing of the kind. You've got me mixed up with someone else.
> Just because I respond to a thread doesn't mean I agree with
> everything said in the thread.
> 
> "Using malloc and free might be a badge of honor to some, but it's
> also a failure of automation."
> 
> Again, the automation code has to written by *someone*. It doesn't
> just appear by itself.
> 
> "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."
> 
> I read through the thread. Just because people don't agree with each
> other doesn't equate to "swagger". I've seen little evidence of
> anything other than reasoned analysis and rational, respectful
> discussion. Was there any sort of personal attacks that I missed?
> 
> The fact of the matter is, code written with malloc/free, if written
> carefully, will run for *years*. There are Linux boxes that have been
> running for literally years without being rebooted, and mainframes and
> miniframes that get booted only when a piece of hardware fails.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

  parent reply	other threads:[~2022-02-06 14:16 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
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 [this message]
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=20220206141558.GO3045@mcvoy.com \
    --to=lm@mcvoy.com \
    --cc=erc@pobox.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).