lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 13/11/2012 00:10, Paul K wrote:
Though far less fun, this all makes me think at an opposite contest,
namely one judging the clearest implementation of software things difficult
to express clearly.

I like this idea, although "clearest" can be too in the eye of the
beholder. Which implementation is the clearest?

function sqrt(x)
   local function good(guess) return math.abs((guess^2) - x) < 1e-5 and
guess end
   local function better(guess) return (guess + x / guess) / 2 end
   local function try(guess) return good(guess) or try(better(guess)) end
   return try(10)
end

or

function sqrt(x)
   local guess = 10
   while math.abs(guess^2 - x) >= 1e-5 do
     guess = (guess + x / guess) / 2
   end
   return guess
end

One is clearly shorter, although I like "try(guess) return good(guess) or
try(better(guess))", which succinctly describes the algorithm. One can come
up with a shorter version:

function sqrt(x)
   local function try(guess) return math.abs((guess^2) - x) < 1e-5 and guess
     or try((guess + x / guess) / 2) end
   return try(10)
end

but, I'm not sure if it's any more clear than the original, more verbose,
version.

Paul
Yes, you are very right. My definition of clear code is code that mirrors the 
model it expresses. As stupid examples, if there are 3 elements in the model, 
then they're should be 3 elements in code, if there is a panel of choice, then 
same things, if there is a process across a set of elements, then there should 
be a traversal loop in code (and not a self-calling func, lol), etc. Then, for 
several reasons (efficiency, brevity, style, or just that the language does not 
let us say what we mean in a straitforward manner...) we can change that; and 
that is the point where comments and/or doc enter the game: to say what the code 
really means, behind its possibly misleading appearance.
In an, hum, "ideal" language, maybe, for code directly expressing the model 
directly, then there may be no need for code comments properly speaking, but 
still instead docs to explain its purpose of the piece of software and code 
conception (according to the author's views on the domain or topic).
That's my perspective. But indeed it lets wide open the field of subjectivity! 
However, there is also certainly a space for objective criteria, and experiments 
on the topic. [*]
At another level, the conception of the model itself may completely change the 
level of difficulty (which probably has much to do with the level of 
abstraction), bit I have no idea how we may judge /that/.
Denis

[*] The only one I have ever heard of was about python's end-of-headline ':' (useless visual noise for me), supposed to help understanding according to a study made (iirc) at the lab where G. van Rossum worked then. It is mentionned somewhere, but I have no idea of the actual process and interpretation of the experiment.