On May 8, 2012, at 2:56 AM, Julian Leviston <[email protected]> wrote:
>
> Humans parsing documents without proper definitions are like coders trying to
> read programming languages that have no comments
One of the under appreciated aspects of system like TeX with the ability to do
embedded programming, or a system like Self with its Annotations as part of the
object, or even python's .__doc__ attributes is that they provide context for
the programmer.
A large part of the reason that these are under appreciated is that most
programs aren't sufficiently well factored to take advantage of these
capabilities. As a human description of what the code does and why will
invariably take about a paragraph of human text per line of code, a 20 line
function requires a pamphlet of documentation to provide sufficient context.
Higher order functions, objects, actors, complex messaging topologies,
exception handling (and all manner of related nonlocal exits), and the like
only compound the context problem as they are "non-obvious". Most of the FP
movement is a reaction against "non-obvious" programming. Ideally this would
result in a positive "self-evident" model, but in the real world we end up with
Haskell monads (non-obvious functional programming).
In the end the practical art is to express your code in such a way as the
interpretation of the written word and the effective semantics of the program
are congruent. Or in human terms "you say what you mean, and the program does
what it says". I have a code sample I use in programming interviews which
reads effectively
function(name) {
method = this[name]
return method.apply(this,arguments.after(0));
}
And the question I typically ask, after showing the definitions of after I ask
the simple question if I call this function as
fn('add', 1, 2)
What is the value of arguments.after(0)
In about 2 out of 25 interviews for senior level devs I get the right answer.
For almost all non-programmers I've talked to, with the little bit of context
"programmers often start counting from 0" they get the right answer, without
having read the formal definition in the base language 2 lines earlier. What
I've learned in asking this question in interviews is that the context one
carries with them often colors their interpretation of the question. Usually 5
out of 25 will be confused because their favorite framework defines "after" to
mean something else entirely, and can't grok the new contextual definition.
The interesting bit is the other 18 people who either fail to answer the
question entirely, don't know how functions pass arguments, or come up with
bizarrely wrong answers. Usually these 18 fail because they can not interpret
what the program does in the specific context of a function call. They don't
have a model of the state machine in their head. No amount of formal
definition will let them process that information. These programmers get by
through cribbing and trial and error. As one described his methodology: "I feed
it inputs until I get what looks like the right answer".
For these people precise definitions, formal language, clever idioms, or finely
tuned mathematical constructs do not matter, because they flip burgers with
more care. And therein lies the crux of the issue, we may be smart enough to
understand these machines, but the majority of people working in industry do
not. And the programmers who become managers at large firms choose obtuse,
inexpressive, cumbersome languages like Java, because they're hiring those 23
I'm turning down.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
