The author notes that, every time we write a subroutine or a function, we avoid the code duplication (DRY), but we create a new abstraction. The following problems must be considered, before appling DRY:
_ an abstraction could be hard to understand, posing a cognitive load on the developer which reads the code written by another one.
_ the consensus between the developers about the abstraction can be hard to reach.
In my opinion, the DRY is very effective only in one particular field: the implementation of math functions in a computer.
One example is the field the trigonometric functions: they have standard abbreviation (sin for sine, cos for cosine ...) and they accept a standard input (radiants or sexagesimal degrees). These naming and input agreements are applied by textbooks, scientific portable calculators and also by all math libraries, despite the languages in which they are written. For this reason, the trigonometric libraries are highly understandable (from the point of view of the user) and highly reusable.
Another examples of effective DRY are the solvers of non-linear equations. These solvers are different about the internal numerical algorithms (bisection, Newton-Raphson or others), but they usually agree on the input:
_ non linear function pointer.
_ first-trial value or a numerical range containing the root.
Interesting observation! I paraphrase it as: “DRY is a technique employed, heavily, in mathematical expression”. DRY via parameterization is strongly encouraged. I would add that the burden of using this technique should be lessened by creating automated tools to help with auto-DRY and detection.
I remember an old post from this blog:
Author: Martin Sústrik, 250 Bpm blog, 7th Nov 2016, "The Cost of Abstraction", URL https://web.archive.org/web/20191121115100/http://250bpm.com/blog:86
The author notes that, every time we write a subroutine or a function, we avoid the code duplication (DRY), but we create a new abstraction. The following problems must be considered, before appling DRY:
_ an abstraction could be hard to understand, posing a cognitive load on the developer which reads the code written by another one.
_ the consensus between the developers about the abstraction can be hard to reach.
In my opinion, the DRY is very effective only in one particular field: the implementation of math functions in a computer.
One example is the field the trigonometric functions: they have standard abbreviation (sin for sine, cos for cosine ...) and they accept a standard input (radiants or sexagesimal degrees). These naming and input agreements are applied by textbooks, scientific portable calculators and also by all math libraries, despite the languages in which they are written. For this reason, the trigonometric libraries are highly understandable (from the point of view of the user) and highly reusable.
Another examples of effective DRY are the solvers of non-linear equations. These solvers are different about the internal numerical algorithms (bisection, Newton-Raphson or others), but they usually agree on the input:
_ non linear function pointer.
_ first-trial value or a numerical range containing the root.
_ relative tolerance on output.
_ absolute tolerance on output.
Interesting observation! I paraphrase it as: “DRY is a technique employed, heavily, in mathematical expression”. DRY via parameterization is strongly encouraged. I would add that the burden of using this technique should be lessened by creating automated tools to help with auto-DRY and detection.