On 1/1/2013 2:12 PM, Loup Vaillant-David wrote:
On Mon, Dec 31, 2012 at 04:36:09PM -0700, Marcus G. Daniels wrote:
On 12/31/12 2:58 PM, Paul D. Fernhout wrote:
2. The programmer has a belief or preference that the code is easier
to work with if it isn't abstracted. […]
I have evidence for this poisonous belief. Here is some production
C++ code I saw:
if (condition1)
{
if (condition2)
{
// some code
}
}
instead of
if (condition1 &&
condition2)
{
// some code
}
-----
void latin1_to_utf8(std::string & s);
instead of
std::string utf8_of_latin1(std::string s)
or
std::string utf8_of_latin1(const std::string & s)
-----
(this one is more controversial)
Foo foo;
if (condition)
foo = bar;
else
foo = baz;
instead of
Foo foo = condition
? bar
: baz;
I think the root cause of those three examples can be called "step by
step thinking". Some people just can't deal with abstractions at all,
not even functions. They can only make procedures, which do their
thing step by step, and rely on global state. (Yes, global state,
though they do have the courtesy to fool themselves by putting it in a
long lived object instead of the toplevel.) The result is effectively
a monster of mostly linear code, which is cut at obvious boundaries
whenever `main()` becomes too long ("too long" generally being a
couple hundred lines. Each line of such code _is_ highly legible,
I'll give them that. The whole however would frighten even Cthulhu.
part of the issue may be a tradeoff:
does the programmer think in terms of abstractions and using high-level
overviews?
or, does the programmer mostly think in terms of step-by-step operations
and make use of their ability to keep large chunks of information in memory?
it is a question maybe of whether the programmer sees the forest or the
trees.
these sorts of things may well have an impact on the types of code a
person writes, and what sorts of things the programmer finds more readable.
like, for a person who can mentally more easily deal with step-by-step
thinking, but can keep much of the code in their mind at-once, and
quickly walk around and explore the various possibilities and scenarios,
this kind of bulky low-abstraction code may be preferable, since when
they "walk the graph" in their mind, they don't really have to stop and
think too much about what sorts of items they encounter along the way.
in their minds-eye, it may well look like a debugger stepping at a rate
of roughly 5-10 statements per second or so. maybe they may or may not
be fully aware how their mind does it, but they can vaguely see the
traces along the call-stack, ghosts of intermediate values, and the
sudden jump of attention to somewhere where a crash has occurred or an
exception has been thrown.
actually, I had before compared it to ants:
it is like ones' mind has ants in it, which walk along trails, either
stepping code, or trying out various possibilities, ...
once something "interesting" comes up, it starts attracting more of
these mental ants, until it has a whole swarm, and then a more clear
image of the scenario or idea may emerge in ones' mind.
but, abstractions and difficult concepts are like oil to these ants,
where if ants encounter something they don't like (like oil) they will
back up and try to walk around it (and individual ants aren't
particularly smart).
and, probably, other people use other methods of reasoning about code...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
