[raphaelss]

It reminded me of two unrelated things: Erlang and FFTW.

Erlang due to its error handling philosophy and FFTW due to the following:

Question 4.1. How does FFTW work?

The innovation (if it can be so called) in FFTW consists in having a variety of composable solvers, representing different FFT algorithms and implementation strategies, whose combination into a particular plan for a given size can be determined at runtime according to the characteristics of your machine/compiler. This peculiar software architecture allows FFTW to adapt itself to almost any machine.

For more details (albeit somewhat outdated), see the paper "FFTW: An Adaptive Software Architecture for the FFT", by M. Frigo and S. G. Johnson, Proc. ICASSP 3, 1381 (1998), also available at the FFTW web page. [1]

[1] http://www.fftw.org/faq/section4.html#howworks

Edited for one more comment:

The last paragraph also reminds me of Alan Kay with its focus on the interaction between systems and not their specific logic.

[fa]

FYI: FFTS [1] in many (most?) cases outperforms FFTW, without runtime calibration. It gets there by using a smarter algorithm algorithm. It doesn't have the bells and whistles of more complete libraries—e.g., restricted to power-of-two transforms for now—but hopefully this will change.

[1] http://anthonix.com/ffts/

[oh_sigh]

Is that outperforms on all architectures/"runtimes"?

[brudgers]

I was reminded of consensus reads for a replicated database value. The independence of implementation would be at the hardware not algorithm level. As is typical, Sussman's ideas inspire thought