Novice Programmers

As expected, novice programmers seem to have the hardest time learning a new programming language. Their programming knowledge is very much connected to the syntactic and semantic structure of the language (or languages) they know. Canas et al. ([4]) tested two groups of programmers, one with and the other without a debugging utility. Using a debugger was identified as enforcing a more semantic representation, while not using one a more syntactic. They concluded that both mental representations are equally effective.

The new structure of the new programming language seems to interfere with knowledge from the past. Scholtz and Wiedenbeck ([1]) tested a group of novice programmers and found that they often used the syntax of the former known languages (inexperienced programmers even used natural language). Extra training is needed to overcome this.

Syntax errors are quite hard for inexperienced programmers, who often find error messages to be unintelligible (Scholtz and Wiedenbeck [11]).

For more experienced programmers the syntax seems not to be a big problem. Many programmers who already know a programming language simply assume a certain pattern, mostly similar to the previously learned languages, as already mentioned. In other words, programmers have strong expectations about the syntax. The reason why programmers go easy with the syntax seems to be the fact that a program will not compile with a syntax error. Also, the error messages are often quite clear to them. Problems with the syntax are easily resolved with a look in the reference manual (Scholtz and Wiedenbeck [11]).

Semantic errors, on the other hand, are different. A program may compile and even run with semantic errors. To make things worse, error messages which result at run time from semantic errors are not very easy to use to find the errors. As programmers become aware of this they tend to be more careful using them. They make sure that they understand the semantics of a construct first (Scholtz and Wiedenbeck [11]).

Nonetheless, the most important factors are the plans. As Rist ([9]) discovered, they seem to be available for recall after their first creation and tell us how our solution to a problem should look like. But each programming language has its own concepts, it's own style. If the unfamiliar concepts of the language are ignored suboptimal solutions occur and valuable features remain unused. This happens if one is trying to use the same plan as in a known language, or if the focus is on trying to get a working program rather than learning the language concepts [2].

Strategic plans are the most general, language-independent form of plans. Programmers worry very little about them, simply because they are so general. Some plans are so general that they could be applied to almost any problem, like "It strongly suggests to write the program incrementally." (Scholtz and Wiedenbeck [11])

Tactical plans, which are basically the algorithms, are more frequent, yet still language-independent. The key point at this level is how many plans are available to a programmer, how many ways does he know to do something. Needless to say that this is a weak point of novice programmers.

Implementation plans deal with applying the language-independent tactical plans to the target programming language. It is easy when a construct is analogous to the construct of a known language. But things get complicated when a programmer can't figure out how to implement their tactical plan. If even the documentation can't help the programmers revise their tactical plans (Scholtz and Wiedenbeck [11]).

Even if a programmer is able to find a correct construct for what he is planning to do it is nonetheless possible that he uses the construct inappropriately (Scholtz and Wiedenbeck [11]).

This iterative interaction between tactical plans and implementation plans is important. It shows that programmers are not efficient in applying their past planning knowledge to solve problems (Scholtz and Wiedenbeck [11]).