Pages

A blog about teaching Programming to non-CompSci students by Tim Love (Cambridge University Engineering Department). I do not speak on behalf of the university, the department, or even the IT group I belong to.

Monday 10 January 2011

Which language?

A long time ago many students arrived at our department with some programming experience thanks to home micros running BASIC, and schools equipped with BBC micros. Then skills fell away. More recently, with free Linux being available, there's been a recovery in programming skills, but only amongst the computer literate, meaning that the distribution of our intake's computing skills is more bi-polar than ever.

Meanwhile, the use of computing in engineering has increased enormously, and new, computing-based areas of engineering have emerged. The invention of the WWW and cheap, small processors has led to the use of GPS and intelligent sensors in civil engineering projects. Google Maps and Google Apps enrich projects as well as aid communication between workers. Computer simulations and CAD continue to replace their predecessors.

The curriculum has slowly changed. In 1997 we moved from teaching Pascal as a first language to teaching C++ (well, C really). Later, there were compulsory computing questions in the 1st year maths examination. In 2003 we offered the MDP disc so that students could run a C++ compiler on their home machines. In 2008 we introduced a C++ summer project. In 2010 first years used Lego MindStorms in week 1, programming using Matlab.

Some of these initiatives aimed to inspire students or offer opportunities for those interested in computing. Other initiatives sought to improve the skills of the less capable students, or encourage a more self-taught approach but we still introduce programming concepts formally using a compiled language and a mixture of practicals and lectures. The increased freedom of choice means that students can more easily avoid programming, thus magnifying the bi-polar distribution of our intake's skills. Attempts have also been made to introduce programming into more engineering courses. In recognition of the need for proficiency in more than one language, Matlab/Octave is now taught (a vehicle for teaching about algorithms) to 2nd years.

Though the C++ course has always received above average results in student feedback, exam performance suggests that many people don't revise the subject. Also feedback from staff and older students hasn't been so encouraging - it's said that the course doesn't prepare people for the kind of programming they'll later need. Programming is used increasingly across all engineering disciplines, and C++ isn't the "swiss army knife" that students want.

C++ was never intended as a "teaching language" but it has withstood the test of time. It's used to write anything from operating systems to embedded programs in hardware. It can be used to introduce all the programming paradigms that have emerged over the years - procedural, object-oriented, generic, etc. It's used here in 2nd and 3rd year practicals (interfacing with low-level hardware and electronics), and a 3rd year software project. Though it's not used in very many 4th year projects, knowledge of C++ is useful for projects that involve Java, C# or Objective-C. Its use has become more focussed over the years as alternatives have emerged. In 2009 we adjusted the C++ course to exploit the teaching potential of the web technologies now available.

  • The new version separates the reference and lab-instruction aspects, so that during the practicals students are only told about what they need for the practicals. They are encouraged to experiment as they read, and to look details up online - web-access is assumed.
  • Because it's a web document we can add some interactive tests and offer students novice/expert choices. This also saves 10,000 sheets of paper. We've taken care that the web pages print out well, in case student want paper versions.
  • Some other departments in Cambridge and in the States leave students to their own devices. Without going that far, we'd like to make students more self-reliant and more able to continue work at home. To that end we've dropped the graphics in this course.
  • The theory in particular (but also the exercises in the practicals) used to emphasise Numerical Analysis. This emphasis has been reduced in favour of problem solving, but the need to retain examinable material is a constraint.
  • The impression that demonstrators gained in the past was that some students never recovered from the first impression that computing was hard. Though the material covered is nearly the same as before (casts have been dropped, C++ strings are used more, and classes are used in an exercise rather than just appearing in an appendix), the initial learning curve is shallower and the emphasis is on using C++ to solve problems. No C++ history is mentioned. There are no comprehensive lists of available features.
  • Initially a reduced set of C++ facilities is taught. C++ is an old language. Though new, safer features and notation have been developed to supercede older ones, the old ones are still legal. We introduce the newer or easier approaches first (especially if they're more like the maths or Matlab/Octave equivalents), then other notations later.
    • We introduce i=i+1 long before i++
    • We introduce and, or and not rather than &&, || and ! for logical operations
    • We use braces around the body of while, for and if code, even if the body is only one line of code. This eliminates some common bugs.
    • We use while loops before for loops. Experience has shown that many students never understand for loops, forgetting the notation entirely, thinking that the condition is an "until" rather than "while" condition, or thinking that
         for (int i=0; i<4;i++)
             cout <<i; 
      

      is somehow equivalent to

         int i=0; 
         i<4; 
         i++; 
         cout <<i;
      
    Once the concepts are clear, the more common (albeit more obscure) alternatives are mentioned.

The result's an online C++ course. While I was at it I converted it to Python, trying to change as little as possible - see the Python course

Python is popular within the University, even for "Scientific Computing". I can see its role growing within the Engineering Department too. We're now in a more polyglot, mash-up age. Matlab for example has about 2.5M lines of C, 1M lines of Java, 0.5M lines of Fortran and about 2.5M lines of its own scripting code. But C++ (the Latin of programming languages) remains: though the first official reference guide for the C++ was published over 25 years ago, it's used in modern applications by Halo, Amazon, Google, Mathworks, Microsoft, Apple, etc. According to the October 2010 figures by TIOBE Ranking Index, JAVA and the C family remain the 2 most popular languages.

Before C++ becomes too complacent though, here are some quotes from "Coders at Work" (edited by Peter Seibel, Springer-Verlag, 2009), which has interviews with several famous programmers.

  • "C++ is just an abomination", Zawinski, p.10
  • "[C++'s] syntax is terrible and totally inconsistent and the error messages, at least from gcc, are ridiculous", Fitzpatrick, p.63
  • "I don't like C++; it doesn't feel right", Armstrong, p.224
  • "given the kinds of goals that I have in programming, I think the decision [for C++] to be backwards-compatible with C is a fatal flaw ... C fundamentally has a corrupt type system", Steele, p.355
  • "Google is C++, strictly C++. It's no big deal programming in C++, but I don't like it ... by and large I think it's a bad language", Thompson, p.475

And here's another quote - "We sold our programming soul when we began teaching the pedagogically unsound and intellectually ugly languages C and C++ to beginners" - David Gries (IEEE Computer, October 2006, p.81).

See Also

  • "Language Considerations in the first year CS curriculum" by Jonathan D. Blake (JCSC 26, 6 (June 2011)). He says "Research has shown that assignments that provide early feedback and early success (and that are compelling and visual) are important in improving not just retention, but also gender equity" (p.126). He used to teach Java in years 1 and 2, then taught Ruby followed by Java, then someone else used Python and Java. He found that both Ruby and Python made the transition to Java harder than expected. He tried Groovy then Java, which simplified the transition but introduced other problems. Currently he's using Scala and Java.

No comments:

Post a Comment