I think the reaction by many people would still be same 30 years later today. Tooling and standardization sure helped with C++, but the authors pointed out the psychological and sociological barriers involved. While some of these barriers have eroded in the past decades (evolving imperative languages incorporated more and more functional aspects over time), but pure functional languages are still perceived as "too clever" by many.

I also wonder how the literate programming approach taken with the Haskell solution compares to the "test harness" used by the C++ implementation in terms of documentation. It has been shown that people read code differently from prose and tests suites are somewhat comparable to the "executable specification" that literate programming provides, with the former aligning more closely with reading the implementation.

It'd be interesting to conduct a similar study today with more contemporary contestants like Haskell, C++20, Rust, Python (it's about prototyping after all), Java, C#/F#, and Julia. It'd also be intriguing to learn whether the perception of the functional solutions changed over time.

"Clever" code is an anti-feature.

Writing code is already hard enough as-is due to the complexity imposed by business requirements. On top of that, reading and debugging code is significantly harder than writing it. It is extremely easy to end up with an incredibly clever codebase, which in practice is just a completely unmaintainable mountain of technical debt.

Take for example something like the Fast Inverse Square Root algorithm [0]. It is incredibly clever, but if you randomly come across it most developers won't be able to easily understand how it works. The well-known variant uses undefined behavior, gives a suboptimal result, and doesn't have any meaningful comments. In other words: it cannot be maintained. Having one or two of those in places where they are absolutely necessary isn't a too bad, but imagine having to deal with bugs in a codebase where you come across stuff like this every single day.

Writing clever code is easy. It is far harder and way more important part to write simple code.

[0]: https://en.wikipedia.org/wiki/Fast_inverse_square_root

That's not an anti-feature because of cleverness. It's a failure of engineering. Just like everything else, clever code needs to be encapsulated behind a good interface, be well documented, be well tested.

> if you randomly come across it most developers won't be able to easily understand how it works

So document it.

> uses undefined behavior

So fix the undefined behavior. Use memcpy or bit_cast.

> gives a suboptimal result

That's probably intentionally sacrificing accuracy for speed. Document it.

> doesn't have any meaningful comments

Then add it.

Clever algorithms is never the problem by itself. It's undocumented unencapsulated clever algorithms with unknown bugs.

Maybe the best example of this would be memcpy. It's extremely clear what it does, but the implementations would surely be "clever" code. And yet you don't need to know anything about SSE to use it.