🚀 go-pugleaf

I've answered the ``maintainability'' objection before: Don't throw out
your original code after you've optimized it. Stick it inside #ifdef
SLOW_N_NATURAL or whatever your favorite language uses for comments.
If you change the original, ``natural'' code, throw away the efficient
version and rewrite it from scratch.

In article <6004@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
> This code is hard to maintain at best, but one precondition for
> readability and maintainability is that, as far as possible, the
> formula written in Algol (or whatever) look as much like the formula
> in the book as possible.  No other way can you read it, check it,
> or understand it.
> 
> If this means that I call sin(a[i,j-1]) six times in a single
> expression, so be it.

	{ register float t = sin(a[i][j-1]);
	  x = t * foo(t,t+1) + bar(t,t-1) - t; }
#ifdef SLOW_N_NATURAL
	x = sin(a[i][j-1]) * foo(sin(a[i][j-1]),sin(a[i][j-1])+1)
	     + bar(sin(a[i][j-1]),sin(a[i][j-1])-1) - sin(a[i][j-1]);
#endif

As I understand the efficient code much better than the slow 'n' natural
code, I would leave the original out entirely. In fact, I doubt any
programmer would need to duplicate more than one percent of a program
in this fashion.

> Optimising the code, extracting common
> subexpressions, calling pure functions only once, and all that
> stuff, is the job of the compiler.  That's why it's there.  That's
> why the first major higher-level language was called FORmula TRANslator.

The compiler is allowed to help but it simply isn't as good as a human.

> Don't make people fit machines; make machines fit people.

Unfortunately, researchers in artificial intelligence report that we
have absolutely no idea how to make machines fit people. 

---Dan