6 Feb
2022
6 Feb
'22
12:40 p.m.
I like the point that malloc()/free() could be seen as a "failure of
automation".
As to the GC and (Go | Rust) vs (C | Java | C++) earlier in this
increasingly-off-topic thread:
perhaps it's an issue of whether that automation is applied at runtime or
compile-time...
(the latter still requiring guidance from the programmer, trading some
programmer-brain-time against cpu-execution-time & memory space?)
On Sun, 6 Feb 2022, 14:28 Rob Pike, <robpike(a)gmail.com> wrote:
I don't understand your disagreement. In what way
is automatic memory
management harder, more unsafe, and less robust than hand-written memory
management using malloc and free?
You seem to think that garbage collection only exists in languages that
have a smell you don't like. Perhaps that's true, but it's been around
for
60 or more years and a lot of important languages use it, while the
programmers that use those languages are often quite capable.
Using malloc and free might be a badge of honor to some, but it's also a
failure of automation.
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.
-rob
On Sun, Feb 6, 2022 at 5:19 PM Ed Carp <erc(a)pobox.com> wrote:
"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(a)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(a)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.