Report on a User Test and Extension of a Type Debugger for Novice Programmers

A type debugger interactively detects the expressions that cause type errors. It asks users whether they intend the types of identifiers to be those that the compiler inferred. However, it seems that novice programmers often get in trouble when they think about how to fix type errors by reading the messages given by the type debugger. In this paper, we analyze the user tests of a type debugger and report problems of the current type debugger. We then extend the type debugger to address these problems. Specifically, we introduce expression-specific error messages and language levels. Finally, we show type errors that we think are difficult to explain to novice programmers. The subjects of the user tests were 40 novice students belonging to the department of information science at Ochanomizu University.Comment: In Proceedings TFPIE 2014, arXiv:1412.473

Meaningful Categorisation of Novice Programmer Errors

The frequency of different kinds of error made by students learning to write computer programs has long been of interest to researchers and educators. In the past, various studies investigated this topic, usually by recording and analysing compiler error messages, and producing tables of relative frequencies of specific errors diagnostics produced by the compiler. In this paper, we improve on such prior studies by investigating actual logical errors in student code, as opposed to diagnostic messages produced by the compiler. The actual errors reported here are more precise, more detailed and more accurate than the diagnostic produced automatically

Programming Safety Tips: Why You Should Use Immutable Objects or How to create programs with bugs that can never be found or fixed.

Program safety deals with how to make programs as error free as possible. The hardest errors in a program for a programmer to find are often errors in using memory. There are two reasons for this. The first is that errors in accessing memory almost never show problems in the proximate area of the program where the error is made. The error has no apparent impact when it is made, but often causes catastrophic results to occur much later in the program, in areas of the program unrelated to memory error that caused it. The second reason memory errors are so difficult to find is that the working of memory is often poorly understood by most novice, and many professional, programmers. This makes it difficult for many programmers to even understand why an action causes the error. This article will show an example of a program error that can easily occur when memory access is poorly understood. This leads to program errors that are very easy to fix when they are found, but extremely difficult to find. The article will then explain how many memory errors can be easily avoided by following the very simple rule, “Make all object immutable unless there is a good reason to make them mutable”, and why immutable objects are an essential tool in good, safe programming practice

Instructional strategies and tactics for the design of introductory computer programming courses in high school

This article offers an examination of instructional strategies and tactics for the design of introductory computer programming courses in high school. We distinguish the Expert, Spiral and Reading approach as groups of instructional strategies that mainly differ in their general design plan to control students' processing load. In order, they emphasize topdown program design, incremental learning, and program modification and amplification. In contrast, tactics are specific design plans that prescribe methods to reach desired learning outcomes under given circumstances. Based on ACT* (Anderson, 1983) and relevant research, we distinguish between declarative and procedural instruction and present six tactics which can be used both to design courses and to evaluate strategies. Three tactics for declarative instruction involve concrete computer models, programming plans and design diagrams; three tactics for procedural instruction involve worked-out examples, practice of basic cognitive skills and task variation. In our evaluation of groups of instructional strategies, the Reading approach has been found to be superior to the Expert and Spiral approaches

37 Million Compilations: Investigating Novice Programming Mistakes in Large-Scale Student Data

Previous investigations of student errors have typically focused on samples of hundreds of students at individual institutions. This work uses a year's worth of compilation events from over 250,000 students all over the world, taken from the large Blackbox data set. We analyze the frequency, time-to-fix, and spread of errors among users, showing how these factors inter-relate, in addition to their development over the course of the year. These results can inform the design of courses, textbooks and also tools to target the most frequent (or hardest to fix) errors

Team-oriented process programming

Team-oriented process programming promises to provide significant support for the planning, directing, and controlling of software engineering projects. In this paper we apply process programming to software engineering teams and show how this can provide powerful new capabilities for the management of software projects. We identify key issues which must be addressed to apply process programming to teams, and present our vision for team-oriented process programming

Validation in the Software Metric Development Process

In this paper the validation of software metrics will be examined. Two approaches will be combined: representational measurement theory and a validation network scheme. The development process of a software metric will be described, together with validities for the three phases of the metric development process. Representation axioms from measurement theory are used both for the formal and empirical validation. The differentiation of validities according to these phases unifies several validation approaches found in the software metric's literature