The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Bakul Shah <bakul@iitbombay.org>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] more about Brian...
Date: Sun, 06 Feb 2022 20:08:22 +0100	[thread overview]
Message-ID: <20220206190822.WUfVe%steffen@sdaoden.eu> (raw)
In-Reply-To: <10B8CDC8-12FF-4B93-AD34-3393BA5C13D5@iitbombay.org>

Bakul Shah wrote in
 <10B8CDC8-12FF-4B93-AD34-3393BA5C13D5@iitbombay.org>:
 |Just ignore the swagger.
 |
 |I would go further than Rob in that even for sequential
 |programs there is no virtue in sticking to malloc/free if you
 |don't have to. The whole point of automation (for me) is to

Well maybe.  When i do perl or awk i do not even think about that
memory as such exists, mostly.  In so far.

 |delegate all the boring and repetitive work to computers so
 |that I can focus on more interesting things! And solving
 |malloc/free related bugs is boring and repetitive. For

But, you know, this is a philosophy i do not like.

Just like i never understood why Stroustrup gave C++ exceptions
the full power of flexibility instead of allowing only a single
base class but giving the entire C++ environment a toggle to
produce __FILE__/__LINE__ diagnosis out of the box.  Or instead of
even introducing symbols which go the non-preprocessor if(XY) way
and allowing access to these from within code if XY is true.
So you have to invent preprocessor mess in order to be able to
pass debug info down the call chain, or use non-portable ELF or so
related info (which i never did).
But if you do have the information at hand, your program could say

  #?1|kent:steffen$ s-nail -Rf /dev/empty
  s-nail: /dev/empty: No such entry, file or directory
  ...
  #?0!0/NONE#ERROR|:? quit
  ...
  s-nail[info]:    Count cur/peek/all:       4/   1658/     12524
  ...
  s-nail[info]:   0x55ef9a581b50 (72 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1064  There are messages in the error ring, manageable via `errors' command???
  s-nail[info]:   0x55ef9a581ae0 (40 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1035  ????????????????E???????P?X??U??E???????
  s-nail[info]:   0x55ef9a581420 (48 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1064  /dev/empty: No such entry, file or directory????
  s-nail[info]:   0x55ef9a5813b0 (40 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1035  ??X??U??????????,??????? ?X??U??,???^???

even upon receive of a signal.  And this is just a silly wrapper,
not even a complete thing.
It is just like always, "there is no wrong weather, just the wrong
clothes".

 |embedded code in limited space you want to use memory
 |carefully but for most of userland code we don't have to
 |worry about saving every byte. Most userland code is not real
 |time code (and doesn't run on realtime OSes).  That doesn't
 |mean using memory like water -- there is a middle ground.
 |Don't blame the GC for incompetently programmed websites or
 |for layers of code using third party libraries using other
 |third party libraries.

All the new languages [offer] [myriads] of [symbol] [annotations]
in order to improve things, which also aids in giving more info to
the tools.

And, what is maybe more important, all programs written in these
languages are written from scratch.  And even if people tend to
produce bugs here and there, and tend to forget the background of
a problem now and then, or did not know about it when they wrote
the code, ... the experience with programming has improved a lot
compared to times that members of these list went through!

That is of course only my personal opinion.  I like C a lot (like
C++ without everything but classes).

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

  reply	other threads:[~2022-02-06 19:08 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 [this message]
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=20220206190822.WUfVe%steffen@sdaoden.eu \
    --to=steffen@sdaoden.eu \
    --cc=bakul@iitbombay.org \
    --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).