Re: PPIG discuss: Need some help to find more Literatures on Programmer Cognition
S. Lin wrote: Except the above books, I am having trouble finding research papers in this area. Could anyone recommend some possible papers/authors for me? Another book is: Francoise Detienne, Software Design - Cognitive Aspects, Springer, 2002. You can also find many references at: http://www2.umassd.edu/SWPI/ProcessBibliography/bib-codereading2.html -- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: SV: PPIG discuss: long term effect of introductory programming education
Guzdial, Mark wrote: The teachers using these approaches complain that our traditional introductory courses don't prepare students for science learning. They care more about representation (e.g., how you represent a vector is critical for the kinds of algorithms that you write in physics), floating point limitations, and iterative methods, and less about type safety and object orientation. These teachers also complain that they Maybe they should be taught domain-specific programming languages, rather than general-purpose programming languages. In this particular case it sounds like they might be interested in Fortress: http://research.sun.com/projects/plrg/ -- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: PPIG discuss: Slips in programming practice
Sarah Mount wrote: Does anyone know of literature about slips (unconscious mistakes) in programming practice? Andrew Ko Brad Myers, A Framework and Methodology for Studying the Causes of Software Errors in Programming Systems, Journal of Visual Languages and Computing, 16, 1-2, pp. 41-84, 2005. http://www.cs.cmu.edu/~ajko/papers/Ko2004SoftwareErrorsFramework.pdf -- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: PPIG discuss: The Designification of Programming
Frank Wales wrote: How designers are saving the world from programmers, since we apparently don't know how to design things without them: http://lostgarden.com/2006/02/software-developments-evolution.html I've seen criticism like this many time. It usually has some good points (like focusing on customer value), but is often based on some false premises (like the 'programming is production' metaphor). Nearly all critics make three fundamental mistakes. First, they ignore the fact that software is already phenomenal success despite all its inadequacies. It has become a fabric of everyday life (to quote Mark Weiser) without adhering to the critic's favorite solution. Second, they fail to acknowledge that software development is about balancing different constraints (e.g. economical, organizational, legal, psychological, technical) not just the single constraint that they are trying to promote. I usually tease them by pointing out that any solution to a complex problem that assumes a single cause is called a conspiracy theory. Third, they start by basically labelling everybody else involved in software development as incompetent, either to their face or behind their backs. This is not the best foundation for the cooperation that that they seek to establish. Having said that, I acknowledge that there is much that we can and should learn from others, so I try to evaluate and incorporate any criticism into my work. Most of the time, however, it ends up quite different from what the critics had anticipated, mainly because of the abovementioned balance. -- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
PPIG discuss: Logic expressions and user-friendliness
I have a program that that validates input according to logical rules (a kind of predicate calculus, i.e. it uses logic operators such as AND, OR, NOT, EXIST, FOR-ALL). A major restriction is that I have no influence over the rules; they are fully configurable and governed by a standardization commitee. If the input violates a rule, then the rule is presented to the user. The vast majority of users have major problems understanding this feedback, so I am investigating how I can improve the feedback. I would therefore appreciate if anybody could point me to literature that addresses the comprehension of logic expressions in programming language; especially how it relates to novices. -- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
PPIG discuss: Workshop papers?
A year ago I requested that the PPIG 2003-2004 workshop papers be made available through the PPIG website. How is this coming along? PS: I would like to add the PPIG 2005 papers to the request. -- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: PPIG discuss: Typology of software bug/usability problem fixes
Effie Law wrote: I'll much appreciate if you could give me some good references for the following topics: (1) the distinction between software bugs and usability problems (2) typology of fixes for software bugs There are a whole range of software bug taxonomies. Some examples are: IEEE Std 1044-1993: Standard Classification for Software Anomalies, http://standards.ieee.org/reading/ieee/std_public/description/se/1044-1993_desc.html Ram Chillarege et al., Orthogonal Defect Classification, http://www.chillarege.com/odc/odc-papers.html Boris Beizer, Software Testing Techniques, Van Nostrand Reinhold Co., 1990. Cem Kaner Jack Falk Hung Quoc Nguyen, Testing Computer Software, Wiley, 1999. Matt Telles Yuan Hsieh, The Science of Debugging, Coriolis, 2001. Robert Metzger, Debugging by Thinking, Elsevier, 2004. (3) typology of fixes for usability problems -- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: PPIG discuss: Problems sitting on the seat (acquiring the seat) while Programming.
Carl Chilley wrote: *Superman syndrome*. Idea from the 80s whereby you have a full size cardboard cut-out of Superman standing behind you, over one of your shoulders. Whenever you get a problem, you explain what it is to Superman (the cut-out) and, in the vast majority of cases you then see a solution to the articulated problem. There appears to be two reasons for This effect has even been demonstrated in empirical studies. For example, Bartl Dorner [1] concludes that (my translation): Subjects asking questions and giving instructions to themselves, which summarizes and evaluates their own course of action, can altogether better organize the problem-solving process. [1] Christina Bartl and Dietrich Doerner, Die Oekokaefer: Zum Einfluss von Sprache auf die Problemloese- und Gedaechtnisleistung bei der Bearbeitung eines nicht-sprachlichen Problems, Memorandum Nr. 31, Lehrstuhl Psychologie II, Universitaet Bamberg, 1998 -- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: PPIG discuss: Conceptual blending theory and PPIG
John J. Sung wrote: I'm interested in applying the conceptual blending theory (Fauconnier Turner) to analyze the cognition in understanding and using programming languages and development environments. Specifically, I'm trying to analyze So am I, although I am more focussed on idioms. Like you, I have not found much literature on this. Articles on metaphors and semiotics in software are probably the closest you will come at the moment. I am currently conducting some experiments, but it is still too early to say anything about the results. -- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: PPIG discuss: What's your thought on the Free Software Foundation?
On Sun, 2004-09-12 at 20:53, Alex Ngai wrote: What's your thought on the Free Software Foundation? There are lots of open-source projects going on today. I mean, why would people sacrifice so many man-hour into a software project, then give it all to the public free of charge, with the source code!! There are many different reasons. See the following surveys: http://www.osdn.com/bcg/ http://www.infonomics.nl/FLOSS/report/ -- PPIG Discuss List ([EMAIL PROTECTED]) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: PPIG discuss: programmer's view of program structure?
On Fri, 2004-02-13 at 22:47, Marat Boshernitsan wrote: To give a bit more context for my work: I am trying to design an intuitive (to the programmer) data model for representing Java programs as well as a (meta)programming language for manipulating this model. Detienne touches on some of these issues in chapter 5 of Francoise Detienne, Software Design - Cognitive Aspects, Springer Verlag, 2002. You may also consider looking into Aspect Oriented Programming. As you are working with Java, http://aspectj.org/ may be a good place to start. Another point to keep in mind is that the intuitiveness of data models is to some degree dependent on the domain. -- PPIG Discuss List ([EMAIL PROTECTED]) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: PPIG discuss: programmer's view of program structure?
On Fri, 2004-02-13 at 09:37, Marat Boshernisan wrote: Understanding programmer's perception of program structure is central to my Ph.D. research and unless I can find existing studies, I will run user experiments to fill in this gap. However, at the very least, I am hoping to find a starting point for devising such a study. A good starting point is Program Understanding - A Survey by von Mayerhauser and Vans: http://citeseer.nj.nec.com/vonmayrhauser94program.html -- PPIG Discuss List ([EMAIL PROTECTED]) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: PPIG discuss: programming as reflective practice
On Fri, 2004-02-06 at 17:19, Andree Woodcock wrote: If any of you know of any articles/discussion groups/web sites or are engaged in similar lines of activity please let me know Orit Hazzan seems to be doing something similar: http://edu.technion.ac.il/Faculty/OritH/HomePage/TeachingHAoSE.htm -- PPIG Discuss List ([EMAIL PROTECTED]) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: PPIG discuss: Loss of context experienced by programmers
On Fri, 2003-12-05 at 01:01, Brian de Alwis wrote: This loss of context seems to happen for two reasons: they forget what they are doing while browsing and understanding the code (perhaps due to information overload), or are distracted from their original task and unable to remember what they were doing (digression). This reminds me... After having read Graesser, Millis, and Zwaan's Discource Comprehension (Annual Review of Psychology, vol 48, pp. 163-189, 1997) a while back, I attempted to transfer their discontinuities to software development. Below you will find an extract of my notes on cognitive complexity. I do not claim that they are accurate or sufficient or even scientific, but they may help with your focus: Expectancy -- Unexpected information causes interruptions which flushes information in the working memory. Deviations from expected patterns of processing creates discontinuities. Handling such discontinuities requires extra cognitive effort. Inspired by discourse catagories (Graesser et al., 1997), we can classify the discontinuities as follows: o Spatial Discontinuity. The spatial dispersion of necessary information. Functional dispersion results in more difficult tracing of control-flow, in higher coupling, and in lower cohesion. Data dispersion results in more difficult tracing of data-flow, and in lower encapsulation. o Temporal Discontinuity. The difficulty of correlating temporally separated information, or predicting the occurrence of events. o Causal Discontinuity. The difficulty of directly relating a symptom to its cause. This phenomemon intensifies as the software evolves. o Intentional Discontinuity. The difficulty of correlating the intended behaviour with the actual behaviour. A discrepancy between intended and actual behaviour normally signifies an error. o Stylistic Discontinuity. The difficulty of adjusting to changes in the coding style. A coding style is normally designed to reduce the introduction of errors or to signal intend. Deviations in coding style can lower the readability of source code. -- PPIG Discuss List ([EMAIL PROTECTED]) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
Re: PPIG discuss: The truth is out there
Derek M Jones wrote: There was some discussion of developers working on open source at the last conference. People might be interested in: Free/Libre and Open Source Software: Survey and Study FLOSS FINAL REPORT http://www.infonomics.nl/FLOSS/report/ In addition to this, the following may be of relevance (depending on what the discussions were focussing on) The Boston Consulting Group/OSDN Hacker Survey http://www.osdn.com/bcg/ I wonder if these results will do anything to halt the many myths that abound about open source development and developers? Which myths? - Automatic footer for [EMAIL PROTECTED] -- To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss To join the announcements list, mail [EMAIL PROTECTED] subscribe announce To receive a help file, mail [EMAIL PROTECTED] help This list is archived at http://www.mail-archive.com/discuss%40ppig.org/ If you have any problems or questions, please mail [EMAIL PROTECTED]
Re: PPIG discuss: Searching for search strategies
Lindsay Marshall wrote: creative. I would contend that there is a tremendous amount of what amounts to debugging in science and that it often constitutes the largest part of any experimental endeavour : you design an experiment to test a hypothesis and it doesn't work and so you try to find out why. Sounds like debugging to me. In fact it sounds very like debugging someone else's undocumented code without any source... Exactly! When I mentioned science, I was particularly thinking of hypothesis-testing. Furthermore, scholarship is not the only field outside of software development that has to debug stuff (find faults in artifacts). Doctors diagnose, mechanics examines, lawyers interrogates, commissions of inquiry investigates, and so forth. What interests me is what methods they use (for example, scholarship uses Occams razor), what commonalities and differences there are, and most significantly if there are any lessons to be learned by software developers. With regards to scholarship, I am currently reading Peter Naur's Knowing and the Mystique of Logic and Rules, which has an entire chapter devoted to the topic. - Automatic footer for [EMAIL PROTECTED] -- To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss To join the announcements list, mail [EMAIL PROTECTED] subscribe announce To receive a help file, mail [EMAIL PROTECTED] help This list is archived at http://www.mail-archive.com/discuss%40ppig.org/ If you have any problems or questions, please mail [EMAIL PROTECTED]
PPIG discuss: Searching for search strategies
[ Sorry, I could not resist the meta-level subject line. ] I am looking for references about how humans collect information, especially when starting from (near-)scratch. That is, how do we determine where to look, how do we look, and how do we evaluate the relevance of the information. So far, I have mainly been looking at the Decision-Making literature, but they generally assume that you use the available information to search for a solution. I am more interested in how the information is obtained. To put this request into context, I am investigating the possibility of a more rigid foundation for debugging techniques than today's ad hoc approaches. - Automatic footer for [EMAIL PROTECTED] -- To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss To join the announcements list, mail [EMAIL PROTECTED] subscribe announce To receive a help file, mail [EMAIL PROTECTED] help This list is archived at http://www.mail-archive.com/discuss%40ppig.org/ If you have any problems or questions, please mail [EMAIL PROTECTED]
