Efficiency (revised position)

Joe Armstrong (AL/EAB) joe.armstrong@REDACTED
Mon Feb 7 11:12:26 CET 2005


I have decided to revise my position on effieciency - since what I say
seems to be deliberately misinterpreted :-)

I have often said "program as inefficiently as possible" 
but this simple truth is often mis-interpreted.

A more precise statement would be 

	"You must program "as inefficiently as possible" in an
	"as efficient as possible manner" 

Writing clear programs should be like writing clear English.

You should write them as clearly as possible because one day you might
have to modify them, or some other person might want to re-use your code.

If you don't write yout programs clearly then when you come to re-use them you
will not understand them and you will have to re-write them.- Efficiency and
clarity are very difficult to combine (so the first "as inefficiently as possible",
means "as clearly as possible" - I'm just expressing it this way to
encourage debate (though the irony seems to have been missed by a
non-zero proportion of people who read this)

Writing clear programs is like writing clear English, the same mental processes
are involved.

The best advice on writing clear English is, I think, to be found in the writings of 
George Orwell - In "Politics and the English Language" he writes:

	A scrupulous writer, in every sentence that he writes, 
	will ask himself at least four questions, thus: 

	1. What am I trying to say? 
	2. What words will express it?
	3. What image or idiom will make it clearer?
	4. Is this image fresh enough to have an effect? 

And he will probably ask himself two more: 

	1. Could I put it more shortly?
	2. Have I said anything that is avoidably ugly? 

Now my second point the "as efficient as possible manner" is
really what Orwell says about ugliness - clear code that does not use
the best and more efficient algorithm is just plain ugly.

So what you must do is to programs as clearly as possible choosing the
most efficient algorithms possible.  

What you should not do is to program unclear code with bizarre untested algorithms in the
naive belief that they will be efficient.


More information about the erlang-questions mailing list