“I would rather write more clunky code now and avoid having my code tossed two years from now by a maintenance programmer who can’t figure out what I did.”
I don’t know that this is possible. Changes in patterns and language features (even legacy languages are gaining new features) will mean that someone will come to your code and need to refactor it for the new system/model/design, etc. It’s not very easy to predict the future and what current style you use that may or may not be desirable in the future.
Optimize for components that can be rewritten, replaced, and repurposed. Put a lot of tests around your code so that during a refactor it’s possible to understand if the refactor is safe. Anticipate that your code will need to be replaced.
The `sqrt` example seems like a bad example. Even if you have written less than 100 lines of Lisp in your life (like I have), it's pretty easy to figure out what that code does if you know what a fixed point and Newton's method are.
It's actually a common criticism of the SICP book. The examples are requiring some math knowledge, since that is the example domain in many places in the book. SICP was written as teaching material for an introductory Computer Science course for university students. It's not a language manual, it's not a programming language tutorial, it's not a Scheme or Lisp book, ...
Here the reader/student has to understand a new programming language (Scheme) and has to understand the example domains, which require some maths knowledge.
The author here probably has more problems understanding how to write mathematical formulas/algorithms in a Functional style. Generally this is nothing Lisp specific, the same programming style could be implemented in typical Functional Programming languages like SML or OCAML. Lisp has a slightly different syntax and no static types - which can be an additional hurdle. But other than that, it's standard mathematical code in a Functional Programming language. Also the book explains it well. So the code should be understandable years later, since it uses the usual mathematical algorithms.
I don’t know that this is possible. Changes in patterns and language features (even legacy languages are gaining new features) will mean that someone will come to your code and need to refactor it for the new system/model/design, etc. It’s not very easy to predict the future and what current style you use that may or may not be desirable in the future.
Optimize for components that can be rewritten, replaced, and repurposed. Put a lot of tests around your code so that during a refactor it’s possible to understand if the refactor is safe. Anticipate that your code will need to be replaced.