Comments on: can hidden complexity be good?

By: numerodix

numerodix — Wed, 02 Jul 2008 09:28:16 +0000

But that is self enforcing A log(n) algorithm is faster than n because it’s more lazy, does less work. Doesn’t matter how long or short the code is, all that matters is how many instructions are executed in the course of the program.

“Beautiful code” is often short code, but it’s by no means a certainty that you can get the most laziness out of the shortest code.

Anyway, fair point I suppose.

By: Andreas Nilsson

Andreas Nilsson — Wed, 02 Jul 2008 08:02:04 +0000

I was merely commenting “High performance code is efficient because it’s the most lazy way to do the job. ” and in general the second half of the second paragraph. So I adressed a single statement, not the general statement about hidden complexity.

By: numerodix

numerodix — Tue, 01 Jul 2008 22:15:30 +0000

I don’t know what you mean by “counter example”. I was saying that if you have a piece of code that does something to specification, and in addition exhibits some behavior that is desirable, but undocumented, this is what I called “hidden complexity”. Ie. you could rewrite the code and it would still perform its primary function, but the “hidden” extra functionality would go away.

In the case of the factorial function, not that I’ve run all of the code samples in ghc, but I imagine they give the same output? Then what are you trying to say?

By: Andreas Nilsson

Andreas Nilsson — Tue, 01 Jul 2008 21:18:45 +0000

Interesting thoughts. In general I agree, but since I do know one interesting counter-example I thought I must share it. Lets stay close to mathematics: Use Haskell to calculate the factorial of n. There are many ways to do this, as can be seen on http://www.willamette.edu/~fruehr/haskell/evolution.html

The interesting solutions the ones by 1: “Combinatory programmer” and 2: “Tenured professor”.

The Combinatory solution is far more complex, but it is quicker And it is kinda elegant to…

/Andreas