[TUHS] Clever code (was Re: Re: Stdin Redirect in Cu History/Alternatives?

[Bakul Shah <bakul@iitbombay.org>]

On Dec 11, 2022, at 12:04 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> 
> 
> On Mon, Dec 12, 2022 at 06:55:31AM +1100, Dave Horsfall wrote:
>> On Sun, 11 Dec 2022, Michael Kj??rling wrote:
>> 
>>> By definition, if you write code as cleverly as you can, then you aren't 
>>> clever enough to debug it...
>> 
>> Indeed...
>> 
>> I've always used the maxim "Write code as though the next person to 
>> maintain it is an axe-wielding psychopath who knows where you live".
> 
> My main job, for the 20 years until I retired, was to keep telling 
> people that code that you wrote 6 months ago might as well have been
> written by someone else.  Optimize for reading the code, not writing
> the code.  It's read many.
> 
> 99.9% of the time, I detest clever code.  .1% of the time, I need it.
> The problem is that smart engineers adore writing clever code.  They
> usually, eventually, wise up.

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. As an example, building "Unix as a service" as
user processes on top of a small microkernel could provide the same
functionality using much clearer and much less code but it would be
slower so we don't do it. Plan9 sort of went in that direction and it
is much simpler (but that could also be because it is not hacked on so
much).

I do prefer clever/smart design to locally clever/smart code. For example,
using Schönhage-Strassen algorithm for multiplying very large numbers.
Or transforming a problem to use a much more efficient data structure
or making equivalent transforms which may be more efficient to compute.
Such code may not be immediately clear but with proper documentation
it is not difficult + you can solve much larger problems. But agreed
these come up much less often.