Honours: Reading
The links following each entry are to my summary and comments on each of the papers I researched in preparation for my honours project in Computer Science at Monash University. Links that don't work means I haven't typed my summary yet.
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
B
- Bonar, J. and Soloway, E., Preprogramming Knowledge: A Major Source of Misconception in Novice Programmers. 1985, In Human Computer Interaction Volume 1 Number 2 pp 133-161 [Link]
- Brooks, R. Towards a theory of the cognitive processes in computer programming in Journal of Man-Machine Studies, 1977 volume 9 pages 737-751 [Link]
- Bruckman, A. and Edwards, E., Should We Leverage Natural-Language Knowledge? An Analysis of User Errors in a Natural-Language-Style Programming Language. 1999, CHI Papers, pp 207-214 [Link]
- Brusilovsky, P. Towards and Intelligent Environment for Learning Introductory Programming Editors : Lemut, E. and Du Boulay, B and Dettori, G. in book : Cognitive Models and Intelligent Environments for Learning Programming, Publisher: Springer-Verlag, 1993, pp 114 - 124 [Link]
- Brusilovsky, P. and Kouchnirenko, A. and Miller, P. and Tomek, I. Teaching programming to novices: a review of approaches and tools. Proceedings of ED-MEDIA'94 - World Conference on Educational Multimedia and Hypermedia. Vancouver, Canada, Jun 25-30, Ottman, T. and Tomek, I. (eds), pp 103-110 [Link]
C
- Conway, D. Criteria and Consideration in the Selection of a First Programming Language Technical Report no 93/192, Monash University, December 1993 [Link]
D
- Du Boulay, B. Some Difficulties of Learning to Program. in book Studying the Novice Programmer, Editoris: Soloway, E. and Spohrer, J.C. Publishers: Lawrence Erlbaum Associates, 1989, pp 283 - 299 [Link]
- Du Boulay, B. and Matthew, I. Fatal error in pass zero: how not to confuse the novices. Journal of Behaviour and Information Technology, 1984, Vol 3. No. 2 pp109-118 [Link]
- Dyck, J. and Mayer, R. BASIC versus Natural Language: Is There One Underlying Comprehension Process? CHI'85 Proceedings, Comference on Human Factors in Computing Systems, San Francisco, April, 1985 [Link]
E
- Eisenstadt, M. and Lewis, M. Errors in an Interactive Programming Environment: Causes and Cures. in Novice Programming Environments: Explorations in Human-Computer Interaction and Artificial Intelligence, Chapter 5, 1992, Editors: Eisenstadt, M. and Keane, M. and Rajan, T., Publisher: Lawrence Erlbaum Associates. [Link]
- Endres, A. An Analysis of Errors and Their Causes in System Programs in IEEE Transactions on Software Engineering Vol SE-1 No 2, June, 1975 [Link]
G
- Gugerty, L. and Olson, G. Debugging by Skilled and Novice Programmers. in proceedings - CHI'86, April, 1986, Publishers ACM pages 171-174 [Link]
H
- Hsi, S. and Soloway, E. Learner Centered Design in SigCHI bulletin Volume 30, Number 4 October 1998, pp 53 - 55 [Link]
J
- Joni, S.A. and Soloway, E. But My Program Runs! Discourse Rules for Novice Programmers in Journal of Educational Computing Research, Volume 2 Number 1, 1986, pages 95-128 [Link]
L
- Levy, S.P. Computer Language Usage in CS1: Survey Results SIGCSE Bulletin, volume 27 Number 3, pp 21-26 1995 [Link]
M
- Mayer, R. The Psychology of How Novices Learn Computer Programming. 1986, Studying the Novice Programmer, Baywood Publishing Co. Inc., pp 129-159 [Link]
- Mayer, R. Cognitive Aspects of Learning and Using a Programming Language in book Interfacing Thought, Editor: Carroll, J. MIT Press, London, 1987 pp 61 - 79 [Link]
- McIver, L. Syntactic and Semantic Issues in Introductory Programming Education, PhD Thesis, January, 2001. [Link]
- McIver, L. The Effect of Programming Language on Error Rates of Novice Programmers. Proceedings, Twelfth Annual Meeting of the Psychology of Programming Interest Group. Corigliano Calabro, Italy, April, 2000.[Link]
- McIver, L. and Conway, D. Grail: A Zeroth Programming Language, Proc. International Conference on Computers in Education 1999 [Link]
- McIver, L. and Conway, D. Seven Deadly Sins of Introductory Programming Language Design. 1996, Proc. Software Engineering: Education and Practice (SE:E&P'96), University of Otago, Dunedin, NZ, pp.309-316, IEEE Computer Society [Link]
- McQuire, A. and Eastman, C. The Ambiguity of Negation in Natural Language Queries to Information Retrieval Systems in Journal of the American Society for Information Science, Vol 49 Number 8, 1998, pp 686-692 [Link]
- Mody, R. P. C in Education and Software Engineering SIGSCE Bulletin Volume 24 No 3 September 1993, pp 45 - 56 [Link]
- Moylan, P. J. The Case Against C Technical Report EE9240, Centre for Industrial Control Science, Department of Electrical and Computer Engineering, The University of Newcastle, NSW 2308 Australia, July 1992 [Link]
- Murnane, J.S., The Psychology of Computer Languages For Introductory Programming Courses. 1993, New Ideas in Psychology Vol. 11 No. 2, pp 213-228 [Link]
P
- Pane, J. F. and Myers, B. A., The Influence of the Psychology of Programming on a Language Design: Project Status Report. Proceedings, Twelfth Annual Meeting of the Psychology of Programming Interest Group. Corigliano Calabro, Italy, April, 2000. pp 193-205 [Link]
- Pane, J. F. and Ratanamahatana C. and Myers, B. A., Studying the language and structure in non-programmers' solutions to programming problems. Int. J. Human-Computer Studies (2001) 54, pp 237-264 [Link]
- Pea, Roy D., Language-Independent Conceptual "Bugs" in Novice Programming, Journal Educational Computing Research, Volume 2(1), 1986 [Link]
- Pennington, N. Comprehension Strategies in Programming in book - Empirical Studies of Programmers: Second Workshop, Publisher: Ablex Publishing Corporation, New Jersey, 1987, pp 100-112 [Link]
- Perkins, D.N., Hancock, C., Hobbs, R., Martin, F. and Simmons, R. Conditions of Learning in Novice Programmers. 1986, Studying the Novice Programmer, Baywood Publishing Co. Inc., pp 261-279 [Link]
S
- Soloway, E. A Cognitively-Based Methodology for Designing Languages/Environments/Methodologies, In Proceedings of the First ACM SIGSOFT/SIGPLAN Software Engineering Symposium of Practical Software Environments, ACM Press 1984 pp 193-196 [Link]
- Soloway, E. and Bonar, J. and Ehrlich, K. Cognitive Strategies and Looping Constructs: An Empirical Study in book Studying the Novice Programmer, Editors: Soloway, E. and Spohrer, J.C. Publisher: Lawrence Erlbaum Associates, 1989, pp 191 - 207 [Link]
- Spohrer, J. C. and Soloway, E. and Pope, E., Where the Bugs Are. Proceedings, 1985, CHI, pp 47-53 [Link]
Top
30/4/2002
Bonar, J. and Soloway, E., Preprogramming Knowledge: A Major Source of Misconception in Novice Programmers. 1985, In Human Computer Interaction Volume 1 Number 2 pp 133-161
Natural language is often used to 'fill the gaps' in programming language knowledge, as NL knowledge is relatively complete, as opposed to novices programming language knowledge. There are many common errors translating loops from NL to PL (and so on, assume continuous testing of conditions). The reason NL is fallen back to so often is that there are many similarities between PL and NL - both can do step by step, loops, conditions, etc; they both share common words even though the use of those words is different. A common error that novices make is assuming that the program knows that an increment should be done automatically, as it is done in maths.
Top
12/6/2002
Brooks, R. Towards a theory of the cognitive processes in computer programming in Journal of Man-Machine Studies, 1977 volume 9 pages 737-751
Categorises method finding behaviour into 3 types:
- Statements of a general solution to the problem, in terms that are not constructs or legal programming statements
- Statements noting the similarity to a previous solution
- Solutions to the problem written in a metalanguage
It was observed that an experience programmer spent 21.2% of the time solving a problem in method-finding activities, 6.9% understanding the problem, and 71.9% coding.
Top
Bruckman, A. and Edwards, E., Should We Leverage Natural-Language Knowledge? An Analysis of User Errors in a Natural-Language-Style Programming Language. 1999, CHI Papers, pp 207-214
This paper analysed an online programmable MUD MOOSE Crossing, used mostly by children. This MUD was programmable in a language called MOOSE, specifically designed to be close to English - the aim was to make the language as natural language like as possible, yet maintain a regular syntax1. (pg 208 para 2)
It was found that children as young as 7 have been able to program using this language, and they find it easy to read each other's programs. (pg 210 para 1)
This paper analysed the errors made by a random selection of the students, having categorised the errors into the following categories: syntax, guessing a command, literal interpretation of a metaphor, and operator precedence/combination. (abstract)
314 of 2970 total errors were natural language related, but, 41.1% were recovered easily, and 20.7 recovered with some difficulty. (pg 214 para 4)
The conclusion of this study that utilising pre-existing natural language knowledge was useful for programming language design for novice programmers. (pg 214 para 4)
1 Moose language designed by Amy Bruckman with guidance from Pavel Curtis, Mitchel Resnick, Brian Silverman, and assistance from MIT students Austina DeBonte, Albert Lin and Trevor Stricker.
-
My comments
Errors made due to natural language use, seem to be easier to recover than non-natural language errors. As C is not very similar to English, semantic errors would be easier to identify and recover if presented in a more natural language, especially for novice programmers, who don't have experience of languages much different to their spoken/written language. As natural language is claimed to be useful in programming language design, it would be just as useful for students to analyse their programs written in a cryptic language in a language that they comprehend easier, allowing for clearer analysis of semantic problems and algorithms, rather than getting 'bogged down' due to incomprehensible syntax.
Top
12/6/2002
Brusilovsky, P. Towards and Intelligent Environment for Learning Introductory Programming Editors : Lemut, E. and Du Boulay, B and Dettori, G. in book : Cognitive Models and Intelligent Environments for Learning Programming, Publisher: Springer-Verlag, 1993, pp 114 - 124
Mentions that teaching support should contain the following elements:
- Program design and coding
- using pre-stored examples and previous solutions to build new programs
- program debugging and investigation
- Querying about the description of language features (online help)
They developed an AI tutoring system that integrated a visual tool that can step through programs, and an interactive environment for program development, as well as an intelligent pogramming environment. He comments that this approach can be used to develop an intelligent programming environment for C, or any other language.
Top
14/5/2002
Brusilovsky, P. and Kouchnirenko, A. and Miller, P. and Tomek, I. Teaching programming to novices: a review of approaches and tools. Proceedings of ED-MEDIA'94 - World Conference on Educational Multimedia and Hypermedia. Vancouver, Canada, Jun 25-30, Ottman, T. and Tomek, I. (eds), pp 103-110
Defines methodologies to help teaching novice programming:
- Incremental - subsets allow greater understanding of each subset before moving on
- Mini-language - may be good for learning concepts but is not a typicaly working language. Is small and simple
- Sub-language - provides commands and queries to aid in learning the 'full' language - may be difficult to limit to the sub-language
Notes that Execution of a program should visually reveal the semantics of the language constructs, and visual cues enable novices to understand semantics which help prevent the development of misconceptions.
KyMir developed to reduce wasted time by teacher and students due to trivial technical problems. Uses marginal notes by beginners to write and debug programs without I/O commands.
Top
13/6/2002
Conway, D. Criteria and Consideration in the Selection of a First Programming Language Technical Report no 93/192, Monash University, December 1993
For a language to be representing a paradigm, the syntax should be concise and semantics straightforward. Fo communicating ideas, the jargon should be consistent with a natural expression of ideas, and transparent enough to not bog the students down in the implementation of those ideas. When a language and environment are used for practicing and experimenting with concepts, they should be powerful to support and encourage experimentation, flexible to allow several different ways to solve a problem, robust to be bug-free or graceful in failure, intelligent to identify and assist good programming styles and simple enough for a novice to gain proficiency easily.
Compilers or editors with serious bugs complicate the learning task, as do compilers that do not implement the language completely, or overlap two languages (C and C++).
Interactive programming environments are an easier introduction to programming for complete novices, but are typically not used in more advanced programming or in 'real-life'.
The choice of an introductory language relies on the importance of:
- syntactic and semantic simplicity
- commercial viability
- power/expressiveness
- Language paradigm
Top
14/5/2002
Du Boulay, B. and Matthew, I. Fatal error in pass zero: how not to confuse the novices. Journal of Behaviour and Information Technology, 1984, Vol 3. No. 2 pp109-118
References a couple of efforts to detext and address semantic errors in PASCAL programs, including their own. Prototype Error checker:
- syntactic error checking, then semantic error checking once syntax is ok
- Outputs problem area of program with verbose common
- My Comments
Doesn't convert code to be more readable, but does give a clearer idea of where and what the problem is.
Top
12/6/2002
Du Boulay, B. Some Difficulties of Learning to Program. in book Studying the Novice Programmer, Editoris: Soloway, E. and Spohrer, J.C. Publishers: Lawrence Erlbaum Associates, 1989, pp 283 - 299
Propose that there are 3 main kinds of errors:
- Misapplication of analogy - try to get more out of something, ie - a variable is like a box, many students think it can therefore hold more than one value
- Overgeneralisation - what works for one type of thing should work for another - ie seperating the actions in a for loop with semicolons may lead to students seperating parameters in function calls with semicolons.
- Inexpert handling of complexity in general and interaction in particular - sub-sections of programs are incorrectly interleaved.
It is also commented that students often think the program/computer will do what they mean, rather than what they say. They suggest that using normal english words in a language and in fact in teaching a language when referring to the program can mislead students, encouraging them to think that the computer has the human ability of inferring what is meant from what is said.
They note that the use of compiled languages causes other problems for the novice and there are usually few debugging aids to help the diagnosis of errors, and the run-time system has little or no access to source code in order to construct useful error messages.
Assignment is difficult - one misconception A = B, means that B is linked to A, and any changes that happen to A in future, also affect B. They also mention that students don't assume that the variable will 'remember' it's previous value unless explicitly changed, or the contents of the memory erased. They note that a common mistake is not initialising counters to 0, or some other value, the analogy being that a 'box' is empty until you put something in it, so it must be 0 to begin with. Some students think that the assignment A = 8 + 3 means that A actually holds the unevaluated expression, rather than the result.
Students find arrays difficult - getting confused with rows and cells, indices and values. Loops cause beginners many troubles, FOR loops as the counter is incremented 'behind the scenes' at the end of each cycle. It is commented that a WHILE loops is often seen as generating an interrupt when it's condition becomes false, exiting the loop no matter where inside the control is.
I/O also causes problems as in most languages, the fact that there is some kind of assignment is hidden. Students often do not understand that a READ instruction will halt execution until it receives something typed by the user.
Top
14/5/2002
Dyck, J. and Mayer, R. BASIC versus Natural Language: Is There One Underlying Comprehension Process? CHI'85 Proceedings, Comference on Human Factors in Computing Systems, San Francisco, April, 1985
Study found evidence that the same cognitive processes are used to comprehend English and Basic procedural statements. Many of the errors made and misconceptions therefore seem to be due to the unfamiliarity of the language.
- My Comments
Thus presenting C programs in a more familiar language may help. The paper by R. Mayer 1987 found the same evidence.
Top
12/6/2002
Eisenstadt, M. and Lewis, M. Errors in an Interactive Programming Environment: Causes and Cures. in Novice Programming Environments: Explorations in Human-Computer Interaction and Artificial Intelligence, Chapter 5, 1992, Editors: Eisenstadt, M. and Keane, M. and Rajan, T., Publisher: Lawrence Erlbaum Associates.
This paper discussed the types and relative frequencies of errors that novices made using a language called SOLO, that was specifically designed to be accessible to beginners. They compared the errors that resulted with the analysis of LOGO errors done by duBoulay (1979) and produced a table:
| Type of Error | LOGO | SOLO |
| Spelling/Typing/Misquoting | 28 | 34 |
| Wrong number of arguments passed | 18 | 18 |
| No line number | 12 | 9 |
| Call to undefined procedure | 12 | 9 |
It was also proposed that pre-empting the above problems would reduce the errors by 43.3%, leaving a greater proportion of error free code. 1069 of 2468 problematic lines of code contained the above mentioned errors. Or another way of looking at it 6960/9428 (73.8%) of a program have trouble free lines, which would increase to 8029/9428 (85.2%) if the problems above were pre-empted.
-
My Comments
The errors that they found are picked up by most C compilers - they are more syntax errors, and we are only considering semantic errors. They found that the errors mentioned above if pre-empted (or picked up by the compiler) were eliminated, 85.2% of the total lines in a program are error free, leaving the remaining lines to have problems, possible sematic, possibly other syntactical errors that they didn't consider.
Top
13/6/2002
Endres, A. An Analysis of Errors and Their Causes in System Programs in IEEE Transactions on Software Engineering Vol SE-1 No 2, June, 1975
Concludes that syntax errors comprise less than 15% of all errors in systems programs (as opposed to application programs). The study was conducted on DOS (VS) Relase 28) released to customers in middle 1973. It analysed the types of errors discovered during internal tests of the componentsi before being released. Obviously this was written by experienced programmers. Errors were classified as follows:
- A - Errors inunderstanding requirements - wrong problem was solved
- B - Errors in translating algorithm to language
- C - Errors in code that must not remain and some can be removed by non-programmers.
It was found that 46% of errors are in group A, 38% in group B. It is proposed that using better programming methods and more comprehensive testing tools could avoid about half of the errors, the other half attacked by better methods of program definitions, and understanding basic system concepts.
Top
12/6/2002
Gugerty, L. and Olson, G. Debugging by Skilled and Novice Programmers. in proceedings - CHI'86, April, 1986, Publishers : ACM pages 171-174
This paper analyses a study done where debugging behaviour of expert and novice programmers was analysed and compared. The programs the programmers were to debug were all syntactically correct and produced output when run. It was found that simple programs both novices and experts found most of the errors (experts 89% of the time, novices 72%), however experts found the bugs on average in 7 mins, where novices were 18.2 minutes. It was also discovered that experts found a bug on their first test 56% of the time, whereas novices only 21%. It was found that novices introduced more errors into the programs when making changes to test for bugs. only 1 expert added a bug to the simple programs in the process of fixing the program.
The more difficult Pascal program test had a similar outcome - 9/10 experts found the error on average in 14.2 minutes. 5/10 novices found the error on average in 33.1 minutes (a maxiumum of 40 minutes was allowed for this test). No expert added a bug, and 3/5 of the novices who couldn't find the error added a bug of their own.
It was proposed that experts found errors more reliably and more quickly than novices due to the ease of understanding the program and what is supposed to do.
Top
13/6/2002
Hsi, S. and Soloway, E. Learner Centered Design in SigCHI bulletin Volume 30, Number 4 October 1998, pp 53 - 55
States that learners need more guidance at the beginning, but these supports need to change as they build competance, and become more independent in their learning. Many issues were raised during the workshop:
Some Do's of Designing for Learning:
- Provide feedback
- provide multiple representations and links between them
- consider prior knowledge of users
- design for prior knowledge and diversity
Top
13/6/2002
Joni, S.A. and Soloway, E. But My Program Runs! Discourse Rules for Novice Programmers in Journal of Educational Computing Research, Volume 2 Number 1, 1986, pages 95-128
This paper studies working programs that are badly designed and coded - which is not all that applicable to the AntiCompiler project. However a couple of comments are useful. It was seen that novice programmers incorrectly initialised variables - either by not doing so, or doing so more than once (init'ing a variable each time within a loop when it was meant to be done outside a loops is a semantic error). It is also noted that novice programmers 'merge goals' - single integrated plan to acheive more than one goal - often leading to programs with more bugs.
Top
13/6/2002
Levy, S.P. Computer Language Usage in CS1: Survey Results SIGCSE Bulletin, volume 27 Number 3, pp 21-26 1995
Many schools have turned to C/Scheme/Ada/C++ as a first programming language, as they are more 'real world' than languages designed for teaching (Pascal,Smalltalk). in 1994 31.8% of languages taught in CS1 was C, the most popular of all the languages looked at (ada 28.1%, C++ 12.3%, Scheme 10.5%). 16% of instructors believed that language was not important, it was simply a tool. Many courses are focussed on learning the language, rather than learning the concepts. Instructors using C and C++ feel it is important to use a language that is used in industry, ADA instructors feel it is most important to teach good software engineering concepts, and Scheme instructors preferred students to write interesting programs sooner.
A comment by one repondant to the survey summed up what many others had said: "It doesn't matter much in CS1 (which language), since students are still mastering the basics found in most languages. In CS1, the emphasis should be on problem solving, algorithm development and logical thinging; not on the intricacies or advanced features of a particular language."
Top
14/5/2002
Mayer, R. The Psychology of How Novices Learn Computer Programming. 1986, Studying the Novice Programmer, Baywood Publishing Co. Inc., pp 129-159
Meaningful learning instaed of rote learning is where learner connects new material with existing knowledge in memory - a process called assimilation.
new material response
--------------> Short Term Memory ------------->
| ^
| |
| | existing knowledge
| | |
| | |
| | |
| | |must be in here for learning to occur
\/ | | or memorisation by rote will happen
Long Term Memory <------
Elaboration in own words can help the learner connect new material to that existing in long term memory.
- Own Comments
If phrasing in own ords helps lind to exiting constructs, then phrasing a C program in a more familiar language should also aid in learning.
Top
13/6/2002
Mayer, R. Cognitice Aspects of Learning and Using a Programming Language in book Interfacing Thought,
Editor: Carroll, J. MIT Press, London, 1987 pp 61 - 79
Learning a new language requires syntactic knowledge and semantic knowledge, and mappings between these two kinds of knowledge. (note - see logbook for paper ref) It requires building semantic knowledge and syntactic knowledge simultaneously, consequently students may 'map' it onto their existing natural language knowledge and representations of constructs (pre-conceptions).
The tests used in this paper consist of presenting statements in BASIC and natural language. The first test concluded that success with BASIC representation was highly correlated to underlying conceptual knowledge. The second test showed that the time needed for comprehension of a BASIC program was strongly related to the complexity (number and difficulty of transactions, and number of statements in the program). The third test indicated novices that learned BASIC under standard instructional conditions (book) seemed to gain conceptions that were wrong or incomplete. Finally it was shown that instruction of the transactions (concepts) improved the conceptual knowledge of the poor students, improving their ability to use BASIC to solve problems, and showed a strong relationship between knowing the correct transactions for BASIC statements, and solving programming problems. This shows that a novice's wrong conceptions must be replaced with more useful ones.
Top
McIver, L. The Effect of Programming Language on Error Rates of Novice Programmers. Proceedings, Twelfth Annual Meeting of the Psychology of Programming Interest Group. Corigliano Calabro, Italy, April, 2000.
Study found simpler/intuitive language may reduce semantic logic errors. Classified errors only as syntactic or semantic.
Top
McIver, L. and Conway, D. Seven Deadly Sins of Introductory Programming Language Design. 1996, Proc. Software Engineering: Education and Practice (SE:E&P'96), University of Otago, Dunedin, NZ, pp.309-316, IEEE Computer Society
Syntax vs semantics complicates the teaching of a programming language (C) and therefore the learning. Proposes 2 things for better language design - Start where the novices are (use a language they know), provide better error diagnosis (current compilers can't find semantic errors, such a tool would improve teachability and learnability).
Top
12/6/2002
Mody, R. P. C in Education and Software Engineering SIGSCE Bulletin Volume 24 No 3 September 1993, pp
45 - 56
This article discusses the negative aspects of C as a language for learning programming, citing many problems such as inconsistencies, pointers, unnatural representations. He proposes that parallel programming is more natural than sequential programming. C is a medium level language, that does not support modularity, abstraction, data hiding, boolean operations, weakly typed, and unverifiable, and it is difficult to do any complex mathematical work.
Top
12/6/2002
Moylan, P. J. The Case Against C Technical Report EE9240, Centre for Industrial Control Science, Department of Electrical and Computer Engineering, The University of Newcastle, NSW 2308 Australia, July 1992
Modularity is about data encapsulation and information hiding, although C supports primitive modularity (different files), and uses header files to link them together. Modularity is acheiveable only if rigid rules are followed, but most programmers do not stick to them as the compiler does not enforce them.
The author has noted that even he, an experienced programmer takes twice as long to get a C program working, as an equivalent in a better designed language, due to twice the amount of time spend debugging C programs.
Top
Murnane, J.S., The Psychology of Computer Languages For Introductory Programming Courses. 1993, New Ideas in Psychology Vol. 11 No. 2, pp 213-228
This paper discussed the history of the design of languages, and proposed 2 different models of programming language - one linguistically easy to comprehend, and another specifically designed for the field (lambda calculus).
"From late 1950's ... almost all language development has been driven by technical considerations - theories originating in Computer Science or in advances made in the application area itself." pg 213 para 1)
C was designed to enhance the utility of the language, Pascal to reduce the possibility of errors, or to pass the responsibility for solving the problem to the language (Prolog). (pg 214 para 1)
Many studies discuss natural language, as ideas or as a source of ambiguity and misunderstanding, but they don't generally consider theories of language aquisition. (pg 215 para 2)
"The readability of programs is far more important than the writability . . . It is vital that the syntax of a programming language should reflect human though patterns, rather than the more 'elegant' but much more obscure patterns of, for example, the lambda calculus." 2 (pg 216 para 3)
"... there is no reasont o accept a teaching tool (computer language) into which no particulat Educational Psychology (learning theory) has gone." (pg 217 para 2)
It is proposed that while all children can naturally and easily aquire language, only some learn to think scientifically. As children don't have to 're-learn' the grammar of their natural language, it follows that language design may benefit from being as close to their natural language as possible. (pp218 - 219)
"Many of the problems in current programming languages (where the syntax is highly restricted) are in fact semantic in origin despite the avowedly context-free grammar." (pg 220 para 2)
Students using Hypertalk 3 find it very 'natural' and insoluble problems are no where near as frequently encountered as in Logo or Logowriter. They have problems, but manage to find a way around them. (pg 221 para 1)
2 Tremblay, G.P. and Sorenson, P.G. The Theory and Practice of Compiler Writing 1985 New York: McGraw-Hill
3 HyperTalk closely resembles English, but was developed over a number of versions, and is not developed with a strong linguistic base.
-
My comments
Most languages were not developed with any thought for language aquisition - research done in linguistics on human languages. Therefore most languages are hard to understand for those not used to scientific thinking. Readability of programs is more important than using a language designed to do very specialised tasks elegantly, as humans have to understand it. This is even more important with novice programmers. Children easily learn languages, and don't have trouble remembering the grammar of their natural language. A common complaint from novice programmers is that they cannot remember the grammar of that programming language, and each time they write a program, they have to relearn it. Students find natural language oriented programming languages easier to learn, and easier to solve problems in. It therefore follows that a program in C, represented in a language closer to the students' natural language would help comprehension and debugging of that program.
Top
Pane, J. F. and Myers, B. A., The Influence of the Psychology of Programming on a Language Design: Project Status Report. Proceedings, Twelfth Annual Meeting of the Psychology of Programming Interest Group. Corigliano Calabro, Italy, April, 2000. pp 193-205
2 studies - looking at how novice/non-programmers devise solutions to programming prblems, - how boolean pbolems are solved and interpreted. Proposed that programming languages force programmers to present solutions unnaturally. Stated that technical demands/innocations drive language design, not focussed on ease of learning/usability.
HCI principles:
- Consistent
- Simple
- prevent errors
- help getting started
- 'speak' the user's natural language
are generally not applied in language design. Reiterated that loops are not represented in languages ina way that matches a user's mental model.. Found that common boolean names used in language cause errors are they are ambiguous in natural language.
Studies found novice programmers preferred:
- rule/event based
- aggregation not iteration
- lists, not arrays
- Boolean avoided (instead used a set of rules)
- NOT had varying precedence
- AND was misinterpreted very often
- My Comments
Most languages are 'too precise' requireing programmers to present solutions in an unnatural way, that does not match their mental model. In particular boolean operators and looping constructs cause the most problems, as they are not represented naturally, or are ambigious in the natural representation. HCI principles are important in language design, and are not considered, language design being driven by technical demands. Of particular importance to this project is 'speaking the user's language', where we aim to present C in a more 'natural' way.
Top
Pane, J. F. and Ratanamahatana C. and Myers, B. A., Studying the language and structure in non-programmers' solutions to programming problems. Int. J. Human-Computer Studies (2001) 54, pp 237-264
"'conventional' programming languages require the programmer to make tremendous transformations from the intended tasks to the code design" p 239
Proposes that languages are easier to learn if the language better matches the beginners existing problem solving language. The mismatch between programming language expressing a solution (ie summing) and the natural way people think about the solution makes it difficult for novices to learn a language, even making programming tasks more difficult for experts. Found a mix of styles were used to solve problems (event-based, constraint oriented, OO, etc) so it might be good not to limit a language to a single style.
- My Comments
Programming requires much precision in the language, natural language is much more imprecise, it is not usually intuitive for novice programmers to be precise, therefore represneting precise constructs in a more imprecise language may facilitate better understanding of how to be precise, and better educate as to what the language requires.
When novices get stuck they resort to natural language solutions. C is very far from natural language and is therefore hard to learn. User interface design is very much geared to how the programmer naturally things about the solution, programming languages are rarely designed to take advantage of the programmer's knowledge of natural language. Representing a program in 2 ways may help students reach a higher level of comprehension as they learn and understand things in different ways.
Top
Pea, Roy D., Language-Independent Conceptual "Bugs" in Novice Programming, Journal Educational Computing Research, Volume 2(1), 1986
Identifies classes of bugs:
- Parallelism - conditions continually evaluated, many lines of code running concurrently
- Intentionality - expect program to look ahead and evaluate code further into the execution than currently
- Egocentrism - intelligence to know what the programmer wanted (uninitialised variables are initialised correctly by the program)
Considers language independent 'bugs', and shows the difficulty in give instructions to the computer. Novices work intuitively as if conversing with humans. Proposes that the prior 'bug' categories occur due to a 'super-bug' - the computer controlling a mind that can reason, look ahead, and extrapolate (probably due to how interaction in NL work). Proposes that a repeated statement that is evaluated once is odd in NL "if you want to, I'll take you" - available all the time, not just once.
- My Comments
Broad bug categorisation, different to others, proposes that novices may attribute (subconsciously) intelligence to the computer as if they were interacting with a person in natural language. Unlike many studes, this aimed to be language independent. States that many structures/concepts in programming are not intuitive and not used in programming as they are in NL.
Top
13/6/2002
McQuire, A. and Eastman, C. The Ambiguity of Negation in Natural Language Queries to Information Retrieval Systems in Journal of the American Society for Information Science, Vol 49 Number 8, 1998, pp 686-692
It was found that the higher the number of disjunction, conjunctions and prepositions used in a statement with a negation, the higher the ambiguity of the statement. ie (Books on NLP but not semantics and parsing since 1989). It was noted that negation is difficult, due to the ambiguity of which components are negated and which aren't.
My Comments
In programming, precedence may also be a problem, depending on the language, and how it conflicts with the user's natural use of negation.
Top
13/6/2002
Pennington, N. Comprehension Strategies in Programming in book - Empirical Studies of Programmers: Second Workshop, Publisher: Ablex Publishing Corporation, New Jersey, 1987, pp 100-112
The study analysed comprehesion of 5 aspects of a program:
- Operations - reading/assigning
- Control Flow - order of actions
- Data Flow - transformations of data objects throughout the program
- State - the state of the rest of the program when a specific place is reached
- Function - main goals and subgoals of a program and the role of procedures
It was found that the most errors were on questions about state and function aspects, fewer on data clow, and the least on control flow and operations. This study was done on experienced programmers.
Top
Perkins, D.N., Hancock, C., Hobbs, R., Martin, F. and Simmons, R. Conditions of Learning in Novice Programmers. 1986, Studying the Novice Programmer, Baywood Publishing Co. Inc., pp 261-279
This paper presented two types of learning, some causes of problems in learning programming.
Two types of learners -
- Stoppers - more common of the two, who get to a problem, and stop. They don't look for ways to solve the problem, they give up.
- Movers - they keep trying solutions, more extreme ones don't stop to discount attempts that didn't work, and subsequently often repeat their solutions, going around in circles.
Often with instruction both types of students can work out solutions. (pp 265 - 267)
It was suggested that a lack of confidence stemming from the students knowledge that they didn't understand how the language works, often causing them to give up, or tinker - try solutions at random. (pg 270 para 2)
One common error is that students project their intentions into the code, not noticing that the code doesn't actually do what they think it does. (pg 271 para 2)
It was proposed that students lacking a clear mental model of the language (primitives/syntax/use etc) were unable to break a problem down. This problem was often made worse as they attempted understanding of how to implement it in the language during coding, instead of working it out in advance. (pg 275 para 3)
-
My comments
Students often attempt to code a solution without thought of how to implement it in the language. This happens more often when they are unfamiliar with the language they are using. Being able to convert their program into something more understandable would allow clearer understanding of the program as they have written it, as they would be less likely to assume the program is doing what they want it to, where that assumption is made due to not understanding the language correctly, and thus skimming over the program when debugging.
Having a tool that can give pointers in a more accessible language would help those types of learners who just get stuck and give up, and those who try solutions at random without really trying to understand how this affects their program. The tool would provide instruction in the form of presenting their current solution clearer than in the language they have problems understanding.
Top
13/6/2002
Soloway, E. A Cognitively-Based Methodology for Designing Languages/Environments/Methodologies, In Proceedings of the First ACM SIGSOFT/SIGPLAN Software Engineering Symposium of Practical Software Environments, ACM Press 1984 pp 193-196
Suggests that Expert Programmers have the following knowledge that novices dont:
- Programming Plans - typical program fragments representing common tasks in programming - eg loops
- Rules of programming discourse - conventions of programming
Also analyses how designers design - noting the experts tend to have better information management skills - being able to remember constraints and assumptions better than novices. Proposes that the design of a language/environment/method should be a better cognitive fit between the user and the l/e/m.
Top
13/6/2002
Soloway, E. and Bonar, J. and Ehrlich, K. Cognitive Strategies and Looping Constructs: An Empirical Study in book Studying the Novice Programmer, Editors: Soloway, E. and Spohrer, J.C. Publisher: Lawrence Erlbaum Associates, 1989, pp 191 - 207
The study was based on a problem where a program needs to be written to read in numbers until it reads the integer 99999, it then should print out the correct average (not counting the final 99999). Novices, intermediate and advances students were all tested. Program plans were written and found that all three groups preferred the READ/PROCESS method (82%, 91%, 67% in order) over the PROCESS/READ method. Impelmenting the programs shows similar preference: READ/PROCESS (86%, 72%, 60%). All groupd were tested with two representations of the language - one that supported READ/PROCESS (loop ... leave ... again) which found that a higher percentage got the programs correct (24%, 61%, 96% = av 52%) as compared to the other group (for, repeat, while) (14%, 36%, 69% av = 33%).
Pascal and C both support the second type - PROCESS/READ methods as in a while loop.
Top
30/4/2002
Spohrer, J. C. and Soloway, E. and Pope, E., Where the Bugs Are. Proceedings, 1985, CHI, pp 47-53
Proposes in 200 examples of novice programs, only 'collaborated' effors are the same. Produced a program PROUST which identifies semantic bugs 75% of the time for moderately complex programs. Explains that research in this area is important for 2 reasons - 1 looking at bugs provides a window into misconceptions, 2 useful in devloping a detailed model of how students learn programming. Most novice programmers try to merge goals' as in real life which leads to a much harder to implement solution, therefore many more bugs. Especially seen in proceedures, ordering and looping. Classified errors as:
- goal drop out - where errors exit loops/programs - goal is abandoned
- goal fragmentation - where flow gets unsequences due to one goal or test taking over where they should have been seperate.
- My Comments
Classified buggy programs, and discussed 'merged goals - noting that students use their natural ability to combine steps resulting in more buggy programs. The project may help students to be more precise and break their merged goals down, if they see it represented in a language that is more familiar.
Top