On 1/1/13 4:29 PM, Loup Vaillant-David wrote:
On Tue, Jan 01, 2013 at 03:02:09PM -0600, BGB wrote:
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.
Well, that could be tested. Let's write some code in a procedural
way, and in a functional way. Show it to a bunch of programmers, and
see if they understand it, spot the bugs, can extend it etc. I'm not
sure what to expect from such tests. One could think most people
would deal more easily with the procedural program, but on the other
hand, I expect the procedural version will be significantly more
complex, especially if it abides "step by step" aesthetics.
This sounds like a great idea, and there are probably some PhDs to be
had doing that (if it has not been done a lot already?). At least such
research is starting though. Here is a related article about research
using eye tracking software to find differences between how experts and
novices look at code, with links to videos of eye movements:
http://developers.slashdot.org/story/12/12/19/1711225/how-experienced-and-novice-programmers-see-code
Here is a direct link to Michael Hansen's blog, who is a PhD student
doing related research:
http://synesthesiam.com/?p=218
"As my fellow Ph.D. student Eric Holk talked about recently in his blog,
I’ve been running eye-tracking experiments with programmers of different
experience levels. In the experiment, a programmer is tasked with
predicting the output of 10 short Python programs. A Tobii TX300 eye
tracker keeps track of their eyes at 300 Hz, allowing me to see where
they’re spending their time."
I imagine the same approach could be useful to look into this issue, as
a new way to quantify what different programmers are doing in different
situations. Here is a link to question on eye tracking code, and form
that I see that a search on "eye tracking software opencv" turns up a
bunch of stuff, where the basic theory is that the pupils change shape
depending on where the eyes are looking:
http://stackoverflow.com/questions/8959423/opencv-eye-tracking-on-android
In theory, the more real data we have on how people actually use
software, the better we can make designs for new computing. Eye tracking
is one way to collect a lot of that fairly quickly, and it can do that
in a way that is much better than just recording what a user clicks on.
I'm getting a Samsung Galaxy Note 10.1 tablet as a next step towards a
"Dynabook". I chose that one mostly because it comes with a pressure
sensitive pen as an input device. Apparently, that tablet still is not
as good as a fifteen year old Apple Newton in some ways, and so is yet
another example of technology regressing for reasons of strong copyright
and generational turn-over. Related:
http://myapplenewton.blogspot.com/2012/10/apple-newton-still-beats-samsung-galaxy.html
http://myapplenewton.blogspot.com/2012/12/apple-newton-replacement-candidate.html
But I mention that tablet because one other "feature" is that the
Samsung tablet supposedly uses the built-in front-facing camera to look
to see whether the user's pupils are visible. If the tablet can't see
the users pupils, then it goes into power saving mode. Of course, that
is probably one of the first features I'll turn off in case it got
hacked. :-) Still, there is a lot of possible promise there perhaps
where the tablet could provide information or functionality more
effectively somehow using that information about where I was looking.
I've also heard you can make a fairly cheap eye tracker with a pair of
glasses and some infrared LEDs and receivers, which sounds less
intrusive than using cameras.
Anyway, I feel it is quite possible what would be found from that sort
of eye tracking research on programmers is that, as in other domains of
life, people have various characteristics, preferences, habits, skills,
and so on at some particular time in their life, and those can be
strengths or weaknesses depending on the context. A big part of whether
a programmer is productive probably has to do with whether they are in
"flow", which in turn depends on how their current abilities relate to
the current task (which is why many game developers make levels of their
games progressively harder as players get better at them). So, even if
we find that some programmers look at code differently than others based
on experience or aptitude, that still does not mean that there is likely
to be one type of programmer who is going to solve all the worlds
programming problems, and nor would that mean that there is one kind of
IDE that would satisfy all programmers at all stages of their careers.
(Again, DrScheme/PLTScheme/Racket's language levels are a step towards
this.)
Many of those programmers best at abstraction and with years of
experience might probably just find many of the routine tasks of
commerce fairly boring, having done similar ones before, and so might
eventually start to make careless mistakes or, worse, over-engineer the
solutions into risky messes... So, pervasive eye tracking software for
some business-typical tasks might show the experts looking away as they
got bored while the novices kept on going -- what should we make of that?
So, I'd suspect that whatever eye tracking tells us, we would find that
optimizing "flow" in programming tasks is probably a good argument for
putting together programming teams of people of various abilities. That
way, the code gets looked at and worked with in all sorts of different
ways, and people currently comfortable with different levels of
abstraction or in various roles with different types of responsibility
help each other to be productive together as a team. Frederick Brooks
got at that somewhat with his "surgical team" model of programming. That
also suggests something about priorities for future computing technology
-- somehow emphasizing supporting teamwork in various ways, whether by
indirect Stygmergy (like through GitHub) or direct interaction (like
through Squeak's Nebraska and similar ideas), depending on the group
size. Related:
http://en.wikipedia.org/wiki/Flow_%28psychology%29#Professions_and_work
http://journal.media-culture.org.au/0605/03-elliott.php
--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies
of abundance in the hands of those thinking in terms of scarcity.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
