Many courses on the history of computing are designed for a general student audience, and as such, include fewer technical details than one might find in a typical CS course. While this approach is appropriate in some contexts, it risks losing the interest of the students who could perhaps benefit most from the subject-namely, future computer scientists. This paper describes a technically-oriented History of Computing course which we taught at the University of Utah in 2008. Like other History of Computing courses, ours included a significant amount of writing and discussion. However, inasmuch as our course was created specifically for CS students, we also incorporated several "hands-on" programming exercises and demonstrations, giving students actual experience with the computing environments of the past. Students and faculty alike have responded enthusiastically to this dual-faceted approach.

Teaching software engineering is difficult because the true benefits of a disciplined software process and the production of significant artifacts are most meaningful when programming-in-the-large, with varying levels of team experience in the context of a professional organization. Using the same techniques when programming-in-the-small can often lead to the students feeling that it is better to not use any process because the effort and tedium of producing artifacts is so great compared with the relatively simple task of writing the code for the target solution. This paper describes our solution, a curriculum that exposes the students to both lightweight traditional and lightweight agile processes. We describe two offerings of the class and conclude from the positive student feedback that we have found the correct balance.

Anecdotal evidence from several sources, primarily in industry, indicates that two programmers working collaboratively on the same design, algorithm, code, or test perform substantially better than the two would working alone. In this technique, often called "pair programming" or "collaborative programming", one person is the "driver" and has control of the pencil/mouse/keyboard and is writing the design or code. The other person continuously and actively observes the work of the driver-watching for defects, thinking of alternatives, looking up resources, and considering strategic implications of the work at hand. A course in Web programming was taught at the University of Utah in Summer Semester 1999. In this course, the students worked in pairs, continuously collaborating on all programming assignments. Using the technique, the students applied a positive form of "pair-pressure" on each other, which proved beneficial to the quality of their work products. The students also benefited from "pair-learning", which allowed them to learn new languages faster and better than they had experienced with solitary learning. "Pair-learning" also reduced the workload of the teaching because the students no longer relied primarily on them for technical support and advise.

This paper presents an innovative allocation strategy for parallel programs composed of communicating processes whose resource requirements vary during program execution. The primary difference between this and previous work is the incorporation into the allocation process of the estimation of variation in resource requirements over time. Experimental results are presented that compare this model with previous work and indicate that this method achieves superior allocation results without any increase in computational complexity. Results indicate a high correlation between the improvement achieved and the degree of process clustering in the parallel program.

Abstract Most current Common Lisp compilers generate more efficient code when supplied with data type information. However, in keeping with standard Lisp programming style, most programmers are reluctant to provide type information; they simply allow the run‐time type system to manage the data types accordingly. To fill this gap, we have designed and implemented a type inference system for Common Lisp (TICL). TICL takes a Lisp program that has been annotated with a few type declarations, adds as many declarations as possible, and produces a type declared program. The compiler can then use this information to generate more efficient code. Measurements indicate that a 20 per cent speed improvement can generally be achieved.