The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Michael Kjörling" <e5655f30a07f@ewoof.net>
To: tuhs@tuhs.org
Subject: [TUHS] Re: Clever code
Date: Mon, 12 Dec 2022 09:48:12 +0000	[thread overview]
Message-ID: <2e17a845-5541-445f-a7f2-7b98879cd488@home.arpa> (raw)
In-Reply-To: <8F5B431B-3789-42C7-8E34-0B6A417B41CF@iitbombay.org>

On 11 Dec 2022 18:15 -0800, from bakul@iitbombay.org (Bakul Shah):
> Agree that clear code is preferable to complicated code. But in practice
> people sacrifice clarity for performance improvement all the time. Look
> at the kernel code of any modern os. Everybody pays lip service to this
> but most anything other than toy programs ends up getting needlessly
> complicated over time.

Performant code does not need to stand in opposition to clear code.
And if you are writing performance-critical or size-critical code
(such as the QNX microkernel that someone brought up), then of course
you might end up needing to do things in non-obvious ways; that's not
the point here. Clever is fine IMO _where the cleverness provides an
actual benefit in a real-world scenario_, and an operating system
kernel (and a language standard library) is a rather special type of
program where sometimes you have to do things in somewhat non-obvious
ways because of the environment the code is meant to execute in. But a
significant portion of the time, where I see "clever" code there is
_no_ significant benefit to the cleverness; it's often more about
"showing off", or saving a few source code characters at the expense
of at-a-glance readability, than it is about actual usefulness and
necessity.

Necessary complexity in order to solve the problem, combined with
things like performance requirements, may sometimes require clever
code. At that point, there is a benefit to the cleverness. But one can
still aim to write the clever code _clearly_, with everything from
comments to good variable and function names to formatting that
enhances readability by for example grouping related operations
together in the source code to keeping related parts grouped together
and separate from other code. Just such a simple thing as that I often
add extra parenthesis over and beyond what's actually required based
on operator precedence, because doing so makes it clearer what goes
together and unless the compiler is severely braindead by modern
standards, doing so costs _nothing_ past the compilation stage.

-- 
✍  Michael Kjörling                  🏡 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”


  parent reply	other threads:[~2022-12-12  9:48 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-10 19:38 [TUHS] Stdin Redirect in Cu History/Alternatives? segaloco via TUHS
2022-12-11  0:22 ` [TUHS] " Clem Cole
2022-12-11  2:37   ` segaloco via TUHS
2022-12-11 13:59   ` Michael Kjörling
2022-12-11 14:28     ` Steve Nickolas
2022-12-11 15:04       ` Dan Cross
2022-12-13  1:54         ` Larry McVoy
2022-12-11 17:18     ` Adam Thornton
2022-12-11 18:54       ` Michael Kjörling
2022-12-11 19:55         ` Dave Horsfall
2022-12-11 20:03           ` Larry McVoy
2022-12-11 23:22             ` segaloco via TUHS
2022-12-12  2:15             ` [TUHS] Clever code (was " Bakul Shah
2022-12-12  2:44               ` [TUHS] " Steve Nickolas
2022-12-12  3:09               ` Andrew Warkentin
2022-12-12  3:34                 ` Larry McVoy
2022-12-12  5:00                   ` Kevin Bowling
2022-12-12  5:26                   ` Andrew Warkentin
2022-12-12 15:02                     ` Larry McVoy
2022-12-12 15:29                     ` Clem Cole
2022-12-12 15:39                       ` Dan Cross
2022-12-12 16:04                       ` Larry McVoy
2022-12-12 16:26                         ` Clem Cole
2022-12-12 22:20                         ` Liam Proven
2022-12-12 23:10                           ` segaloco via TUHS
2022-12-12 23:24                             ` Larry McVoy
2022-12-13  2:00                       ` Andrew Warkentin
2022-12-13 13:37                         ` Larry McVoy
2022-12-13 23:00                           ` Andrew Warkentin
2022-12-14  1:05                             ` Larry McVoy
2022-12-14  1:40                               ` segaloco via TUHS
2022-12-14  6:32                                 ` Rich Morin
2022-12-14  2:01                               ` Andrew Warkentin
2022-12-14  7:49                                 ` arnold
2022-12-14 11:54                                   ` Brad Spencer
2022-12-14 12:08                                     ` [TUHS] Re: (TUHS -> COFF?) Re: Clever code Michael Kjörling
2022-12-14 15:14                                     ` [TUHS] Microware's OS-9 (was: Clever code) G. Branden Robinson
2022-12-14 22:41                                       ` [TUHS] " John Cowan
2022-12-14  9:46                               ` [TUHS] Re: Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives? Harald Arnesen
2022-12-15 18:33                                 ` Liam Proven
2022-12-16 10:42                                   ` Harald Arnesen
2022-12-18 14:05                                     ` Liam Proven
2022-12-18 15:08                                       ` Stuff Received
2022-12-19 11:47                                         ` Liam Proven
2022-12-20  8:30                                       ` Andrew Warkentin
2022-12-20 11:57                                         ` Liam Proven
2022-12-15  0:29                 ` Bakul Shah
2022-12-15  2:54                   ` Larry McVoy
2022-12-15  5:36                     ` Bakul Shah
2022-12-15 14:02                       ` Dan Cross
2022-12-15 14:06                         ` Larry McVoy
2022-12-15 14:18                           ` Dan Cross
2022-12-15 14:02                       ` Larry McVoy
2022-12-15  8:01                     ` Andrew Warkentin
2022-12-12  9:48               ` Michael Kjörling [this message]
2022-12-12 21:34             ` [TUHS] " Dave Horsfall
2022-12-12 21:46               ` Chet Ramey
2022-12-13  3:30 [TUHS] Re: Clever code Rudi Blom
2022-12-13  3:41 ` Warner Losh
2022-12-13  3:53 ` Dave Horsfall
2022-12-13  4:03   ` George Michaelson
2022-12-13  8:05     ` Ralph Corderoy
2022-12-13  9:45       ` Dagobert Michelsen
2022-12-13  7:47   ` Ralph Corderoy
2022-12-13 19:56     ` Dave Horsfall
2022-12-13 11:46   ` John P. Linderman
2022-12-13 14:07     ` Douglas McIlroy
2022-12-13 14:31       ` arnold
2022-12-13 14:48         ` Ralph Corderoy
2022-12-13 15:10         ` Douglas McIlroy
2022-12-13 15:34           ` Stuff Received
2022-12-13 15:56             ` Ralph Corderoy
2022-12-13 23:02           ` Harald Arnesen
2022-12-14  7:31           ` arnold
2022-12-15 18:06           ` Marc Donner
2022-12-15 18:08             ` Marc Donner
2022-12-13 15:52 ` Bakul Shah
2022-12-13 16:14   ` Ralph Corderoy
2022-12-13 16:30     ` Bakul Shah
2022-12-13 17:58 Noel Chiappa
2022-12-13 18:51 ` G. Branden Robinson
2022-12-13 20:14   ` segaloco via TUHS
2022-12-13 20:58     ` Warren Toomey via TUHS
2022-12-14  2:28     ` Luther Johnson
2022-12-13 18:02 Noel Chiappa

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=2e17a845-5541-445f-a7f2-7b98879cd488@home.arpa \
    --to=e5655f30a07f@ewoof.net \
    --cc=tuhs@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).