[TUHS] more about Brian...

Will Senn will.senn at gmail.com
Sun Feb 6 15:06:20 AEST 2022

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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220205/02605bce/attachment.htm>

More information about the TUHS mailing list