Relevant, but not terribly interesting in the face of research.

http://doi.acm.org/10.1145/871895.871902

Syntax errors identified that their software attempts to catch before the compiler does:

1. = vs ==
2. == vs .equals
3. mismatching, miscounting and/or misuse of {}. [], ()
4. && vs & and || vs |
5. incorrect semi-colon after an if selection structure before the if statement or after the for or while repetition structure before the respective for or while loop
6. wrong separators in for loops (using commas instead of semi-colons)
7. an if followed by a bracket instead of by a parenthesis
8. using keywords as method names or variable names
9. invoking methods with wrong arguments
10. forgetting parentheses after method call
11. incorrect semicolon at the end of a method header
12. leaving space after a period when calling a specific method
13. >- an =<

http://doi.acm.org/10.1145/611892.611956

At the far right of the diagram are “structure editors,” so called because of internal representations closely related to the tree and graph structures used by compilers and other tools. This greatly simplifies some kinds of language-oriented services, but it requires that programmers edit via structural rather than textual commands. Behind this approach is a conjecture, articulated by Teitelbaum and Reps, that programs are intrinsically tree structured, and that programmers understand and should manipulate them that way. Unfortunately, years of failed attempts, combined with research on program editing and on how programmers really think about programs have refuted that conjecture. From a tool integration perspective, the advantages of complete linguistic analysis are offset by its fragility (in the presence of user editing) and context-dependency (the meaning of code in many languages depends potentially on all the other code with which it will run). Few structure editors are in use today.

At the far left are simple text editors with no linguistic support. Editing is simple and familiar, but there is no real specialization for source code. Integrating a simple text editor with software engineering tools requires complex mappings between structure and text, but these typically result in restrictive and confusing functionality, fragile representations (for example, where the identify of structural elements is not preserved during editing operations), or both.

http://www.cs.berkeley.edu/~maratb/pubs/editor.pdf

Too much to quote.

Over the past twenty years many research studies have discovered useful information about novice programmers, and identified good and bad aspects of today’s programming systems, both visual and textual. However, this body of research is widely distributed throughout the literature and is not well organized, making it difficult to use in guiding the design of new systems. The result is that these research results generally have not been systematically fed back into the design of new programming systems. Instead, the design of new languages and environments has most often been driven by technical objectives, such as ease of parsing, ease of generating fast code, closeness to the machine, ease of proving correctness, etc. Even systems that were designed for novice users or for teaching have not attempted to broadly survey this body of research before making critical decisions about the metaphor or model that the language is based on, the notation that is used in the language, and the environment.

http://www-2.cs.cmu.edu/~pane/cmu-cs-96-132.html

Shortcomings of existing compilers

The idea that weaknesses in the programming environment complicate the learning process for beginning students is not a new one; such shortcomings have been recognized in earlier papers [Ruckert93, Schorsch95]. The underlying problem is that most commercial compilers—particularly for languages like C that cater to a large audience of programmers—are designed for experts rather than novices. As a result, most of these compilers are poorly suited to student use.

In our experience, commercial compilers suffer from the following problems when used in an introductory course:

• The error messages generated by commercial compilers are often uninformative and sometimes misleading. New programmers tend to make certain mistakes more often than others. For example, omitting a required semicolon or right curly brace is a very common error in C programs. Unfortunately, compilers sometimes respond to this error by reporting a seemingly unrelated syntax error several lines below the actual mistake, presumably because the parser does not detect the problem until that point in the source file. Expert programmers understand the problem and know where to look; novices are completely baffled.
• Interactive debuggers typically require students to understand advanced concepts before they are ready to assimilate them. …
• Commercial compilers offer a bewildering set of options and special features that are useless to the novice and occasionally cause consistency problems. …

http://doi.acm.org/10.1145/236452.236560

We also wanted students to learn to use a correct programming style as a matter of habit. We assumed that with CAP continually telling the students to fix their programming style, eventually they would learn to do it correctly from the beginning. Unfortunately, we believe that many students began using CAP as a crutch to merely get by. Rather than incorporating the required programming style rules into their programming habits, some students ignore style altogether knowing that CAP will annotate their code with all the corrections that are necessary. These students have become dependent on CAP and could not program to our standards without it. This is the opposite effect that we wanted. Fortunately, we believe this number to be small, although further testing is warranted to determine if the problem is wide-spread. Additionally, it is likely the result would be the same for these students in the absence of CAP.

http://doi.acm.org/10.1145/199688.199769

The diverse nature of undergraduate curricula in computer science demands a wide range of programming language support. Students are exposed to a variety of programming languages such as Pascal for introductory programming, Modula-2 for concurrent programming, C for systems programming, and Smalltalk or C__ for object-oriented programming. The proliferation of programming language environments, and CASE tools in undergraduate curricula impose an overload of syntax on both educators and students. Our limited teaching time is wasted introducing new syntax and not new concepts.

A solution to these problems requires an environment that provides a wide range of language support under a common syntax, combined with an integrated collection of coding and CASE tools. Such an environment could be used as a “curriculum-cycle” tool for teaching programming at all levels of an undergraduate curriculum in computer science.

Students in the introductory courses appreciate both the language and the easy to use environment much in the same way Turbo [Borland] users do. Shielded from the complexity of having to use several losely-coupled tools, beginners are able to concentrate on the important task of learning the concepts behind programming.

http://doi.acm.org/10.1145/169070.169086

In 1991, the Stanford Department of Computer Science decided to abandon Pascal in its introductory computer science courses and to adopt ANSI C as the language of instruction. We based this decision on several factors: the inadequacy of standard Pascal as a base for teaching modern programming concepts, the need to prepare our students for more advanced courses in which they will be expected to use C for programming projects, and increasing pressure from students and faculty throughout the School of Engineering for instruction in a language that has become the industry standard. We also believe that it is not reasonable to expect students to learn C on their own; students must receive instruction in C in order to become good C programmers. C has several known deficiencies that make it a challenging language to teach.

Over the last five years, however, many schools have begun to move away from Pascal. The reasons behind this shift include:

• Pascal is getting old. There are several modern programming concepts, such as separate compilation, string manipulation, and the use of functions as first-class objects, that are not supported by standard Pascal and that are therefore difficult to teach.
• The restrictiveness of Pascal’s design occasionally forces its users to “program around the language.” Doing so means that students develop certain bad habits—habits that they must later unlearn when they begin to work with more modern languages.
• Pascal is not widely used beyond the introductory sequence, and students are therefore being taught programming style and the discipline of software engineering in the context of a language that they will never again use. The first course must provide an introduction to good programming practice. Unfortunately, the effectiveness of that instruction is compromised when the linguistic tools used to illustrate the underlying concepts are so quickly abandoned.

http://doi.acm.org/10.1145/169070.169361