Making Programming Easier for Beginners

Introduction

In the days when home computers had BASIC it was common for bright children to write little programs - egg-timers, etc. They gained experience of programming as a concept, but just as importantly they got practise at making mistakes and fixing them.

In the Windows/Mac era this option was no longer available. Some of the older lecturers here say they have noticed a consequent reduction in programming skills amongst our new students.

It's been suggested that the Raspberry Pi might be used as a way to encourage entry-level home programming in the future. And perhaps schools might deliver more programmers to universities. But for now we have to cope with a significant minority of students arriving without programming skills. This leads to student anxiety when they're at their most vulnerable, poor end-of-year results, and perhaps an under-use of computing in their career.

In this document I consider the factors involved with these difficulties. The problem goes beyond being purely cognitive. Some students seem to acquire something like a phobia about the subject (not helped by the public perception of Computing being a male, nerdy, obsessive topic).

Attempted solutions aim to

• Develop programming skills (or aid the transfer of other skills)
• Reduce the anxiety levels associated with the topic thus aiding the learning process.
• Identify the students who'd most gain from extra help once term starts.

What is hard about computing

Computing languages are unlike anything else that students are likely to have done. They're not even like maths. Compilers are unforgiving - always criticising and never praising. Students' programming skills span a wider range than that of any other examined skill, so non-programmers will feel stupid right from the start. Comments similar to the following are common - "It's too hard"; "It's too easy"; "Other people find it easy. Why do I find it so hard?"; "If it mattered we'd have been taught it already"; "arbitrary rules, it's all about jumping through hoops".

It may be that we're trying to teach topics that are known to be difficult but that only a few students will ever need. We teach a compiled language (C++) though few student will use one. Speed of execution is rarely a critical factor in student programs, but a significant factor in our choice of language.

People know which topics students find difficult. It's less clear how to exploit this knowledge. In "When do students learn? Investigating factors in introductory courses" ("JCSC", 2012) it said "we found that instructional time spent on a topic often has a far weaker connection to student learning levels than does instructor emphasis. ... Just spending more classroom teaching time on a concept will not improve student learning as much as an instructor placing greater emphasis on that concept ... For CS1, there were few topics for which there were statistically significant correlations between instructional time and student learning. ... Interestingly, three topics, control structures, subroutines/functions, and types, had weakly negative correlations."

Easing the Learning Curves

One can broadly categorize the problem areas as follows - Algorithms (What to do), Implementation (How to do it) and Psychology (Finding a congenial context within which to learn). Each category has a learning curve that can be made more shallow. Each has been targeted by educationalists

Algorithms

The idea of planning for eventualities that might occur during the planners' absence is not a scenario that students have much experience in. Also programming involves much more failure (error messages) than success, which distresses beginners. Solutions to these difficulties include getting students to

• begin solely with algorithms - flowcharts, paper exercises involving recipes, etc
• begin with easier algorithms - "Add 2 numbers"; "Write a times table". These tasks are boring but at least they let students focus on the implementation.

Implementation

• Re-order the topics (e.g. delay the introduction of functions, Object-Orientation etc.)
• Expand the documentation at the start of the course - offer cribsheets, etc.
• Change the language
• Write tools targeted to help the student with specific, known problem areas (we've written animations and teaching aids - e.g. 'for' loop help
• Use a new language just for the start of the course - Interpreted languages help accelerate the edit-run cycle, reducing the psychological consequences of errors.
  Some sites use Scratch to narrow the gap between algorithms and implementation - the programs are flowcharts. One paper reported that "not only did Scratch excite students at a critical time (i.e., their first foray into computer science), it also familiarized the inexperienced among the with fundamentals of programming without the distraction of syntax".
  Jonathan D. Blake wrote that "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" ((JCSC 26, 6, p.126). Languages like Turtle Graphics make feedback more visual (especially if they use robots - students can then see the physical consequences of their work).

Psychology

• Computer-based Teaching - a supportive development environment can be developed (one that attempts to diagnose errors, for example). But this is likely to be language-specific and expensive to produce
• More Interesting algorithms - If the task is interesting enough, students will be more stubborn when dealing with implementation issues. Students' supposed interest in computer games has been used to incite interest. Lisa Torrey "concluded that the most important interest factors were graphics, usefulness and entertainment value".
• Working in Teams - This might help some to learning without exposing their ignorance to staff. Some students like to be taught via the language of their peers. However, the results are patchy and over-praised by students. Also, girls get a lot more help than boys.
• Offer a choice of slow and fast courses, or easy and hard questions, or extra help. Lisa Torrey found that given a choice, "students disproportionately chose to write less challenging programs than their interest patterns had suggested". She felt that "many students would choose easy programs that happen to contain other interesting factors" ("Student interest and choice in programming assignments", JCSC 26, 6)
  Extra help can be made available
  • Making help available by phone or e-mail, or having a drop-in surgery
  • Offering 1-to-1 tuition
  • Online self-help (or supervised) groups (could offer marks for the quality of involvement; could use Skype).

See Also

• The camel has two humps (working title) Saeed Dehnadi and Richard Bornat, School of Computing, Middlesex University, UK, 2006

Using Scratch to prepare students for programming

Scratch, first launched in 2005, is considered one of the best languages for introducing children to programming. Some universities are beginning to introduce Scratch into introductory courses.

Scratch

Scratch programs are flowcharts that the programmer constructs by dragging blocks around the screen. The blocks are shaped so that they click together if the "syntax" is correct. It lacks methods (functions), so it doesn't use parameters or return values, but it does have Events and Threads, both of which are important in modern computing.

Extensions to Scratch exist that add functions, etc - see for example Build Your Own Blocks. Scratch 2.0 is beginning to be used - it has procedures, webcam support, Lego support and even support for cloud programming.

Harvard

Harvard tried Scratch in a "Harvard Summer School's Computer Science S-1: Great Ideas in Computer Science", the summer-time version of an introductory course at Harvard College. Details are at http://cs.harvard.edu/malan/publications/fp079-malan.pdf. They used Scratch to introduce the idea of programming and set some exercises before moving on to Java - "Though some students spent only 2 or 3 hours on their first problem set, others spent upwards of 20, implementing projects more advanced than any of those written in lecture." One student wrote "Though I did not yet know how to create a for loop, I knew when a for loop was necessary because I had used loops in my Scratch program."

Encouraged by this, the staff introduced Scratch on the full undergraduate course. CS50 is Harvard College's introductory course for majors and non-majors. Typical enrollment is 300 students. Scratch is used in the first two lectures and the first assignment; the rest of the course is taught in C, PHP, and JavaScript. Details are on http://infoscratch.media.mit.edu/SIGCSE2010Workshop

Documention and initial Scratch code is available. See SCRATCH for Budding Computer Scientists (a tutorial).

Berkeley

In 2009 Berkerley trialed a course based on Scratch which they later introduced in an alternative introductory computing course. http://www.eecs.berkeley.edu/news/cso.pdf describes the reasoning behind the course changes, noting that

• Scratch supports some advanced (Web 2.0) ideas. It allows students to upload their finished graphical programs to the web which can then be run online in a web browser, downloaded, modified (or, "re-mixed") and re-uploaded.
• Scratch encourages broader participation - the report gives statistics on female and hispanic participation. They write that "We have a longstanding goal to provide alternative paths to prepare students for CS61a. The traditional path to CS61a, of taking the AP computer science test, suffers from little participation by populations that are typically under-represented in computer science."

Wisconsin

Their notes are at http://pages.cs.wisc.edu/~dusseau/Classes/CS202-F11/. The weekly exercises for this course are online - e.g.

• week 1 - exploring the Scratch website, playing a game and answering a survey
• week 2 - "this homework has two parts. In Part A, you'll use Scratch to draw an interesting picture. In Part B, you'll analyze different scripts written in Scratch and decide if they have the same functionality or not."

This course develops the social networking aspect. One of the first tasks the students are asked to do is upload a photo of themselves.

Rutgers

Their Programming for the Masses course uses Scratch. Though it's not a programming course, students do learn to write short programs. One development of this is the Scratchable Devices project where students can program their household devices. Using devices are equipped with an XBee module connected to Arduino microcontrollers, they can switch lights off and on by clapping, etc.

Ohio State University

In an Outreach course they offer some partly working scratch files ("Save the Turtle", etc) and invite the student to modify them. Their document is worth reading for the exercise - http://www.cse.ohio-state.edu/~paolo/outreach/ScratchSE/LabOverview.doc

Kent State University

Their introduction to computer science uses Scratch then JavaScript. Few details are online - http://www.cs.kent.edu/~volkert/10051/

Conclusions

Pros

• Reputable universities have already done a lot of the work that we'd need to do. Proposals for course-changes, Scratch tutorials and exercises for students are all online.
• Some students have an impoverished mental representation of programs - they don't "chunk". Scratch programs match my internal representation of simple programs - objects are nearly independent and have dynamic internal structure.
• Though not many Universities are officially using Scratch, the more advanced school and OutReach exercises offer sufficient challenges for students-to-be. See for example NeboMusic Polygon Robot exercise

Cons

• Scratch leads more naturally to Object-orientation, a trend that some universities have been distancing themselves from. Moreover, it segues poorly into initial C++ exercises like "get the user to type 2 numbers in. Display the sum" or "print the 5 times table"
• Scratch bypasses most of the language features that C++ students find most difficult.
• Quite a lot of the excitement of using Scratch is the social-network aspect, but this needs some management

C++ function problems

This page shows some of the students' imaginative attempts at solving one part of the 1st year Michaelmas computing course. The task is one that's been on the course for years, but this year we spoonfed them less. The students would have the same difficulties in many other languages, though C++ provides rather more challenges than Matlab (for example) would.

How we introduce functions

We explain functions gradually, using a mixture of explanation and practical work. The explanations include animations, diagrams showing functions as boxes with inputs and outputs, and sections entitled

• Functions
• Standard functions
• More functions

We tell then that they have to do 3 things when writing functions: write a prototype, write the function, and call the function. The practical work begins with a gentle learning curve as follows

• We show them is_even (a function that determines whether an integer is even) and give them a program that uses the function to see which integers in the range 1 to 10 are even. Then we ask them to produce a similar program to identify multiples of 3. This requires them to modify the code trivially, but we insist that they change the name of the routine (so they have to change the call and prototype too).
• We get them to write a times-table program using a timesby7 function that we provide (the program will be similar to the above program)
• We get them to write a program with just a main function, then get them to restructure it without changing its output so that it has main and another function.
• Then we get them to write bigger programs with functions written from scratch
• Then we get them to use library functions.

Common problems include

• Thinking that the prototype

       int fun(int number);
  

  means that they have to call fun with a parameter called "number". We could get them to write the prototype as

       int fun(int);
  

  but that's not considered good style
• Thinking that the prototype

       
       int fun(int number);
  

  calls the routine. We could ask them to prove to us that it does - by adding a cout call to the function.
• Thinking that if a function prints out the answer, that's the same as returning it.

Playing with dice

About half way through their Michaelmas term work when they've already used functions we give the 1st years the following code

int RollDie()
{
   int randomNumber, die;

   randomNumber = random();
   die = 1 + (randomNumber % 6);
   return die;
}

We say

---

Each time the function random() is called, it will return a random positive integer. Work out what the ... function does and how it works.

---

One student didn't know how to search for "%" on a web-page, hence couldn't find where we'd described what the "%" operator did. I worry about students' webskills sometimes.

Then later in the handout we say

---

You've already seen the RollDie function that simulates the rolling of a single die. Copy it into your new file. Now write a function called Roll2Dice to simulate the rolling of 2 dice (call RollDie twice and return the sum of the answers). Before going any further, test it. If it doesn't work, neither will your full program! Here's a main function you could use

  int main() {
     srandom(time(0));
     cout << "Roll2Dice returns "  << Roll2Dice()  << endl;
  }

You'll need to add prototypes for RollDie and Roll2Dice too.

---

This task contrasts with last year's work where after we gave them the code for RollDie() we gave them the code for a routine with the prototype int RollManyDice(int M) (though we didn't provide the prototype or the final return ... line of the function). We made the change because we'd rather students programmed something simple themselves than merely type in more complex code than they don't understand.

Here's a list of solutions that students have tried

1. Several start by writing this prototype

      bool Roll2Dice()
   

   because the first function introduced to them returns a bool.
2. A few start by writing this prototype

      int Roll2Dice(int RollDie(),int RollDie() )
   

   because RollDie is "needed" by Roll2Dice, I presume.
3. Some do this

   int Roll2Dice()
   {
      int randomNumber, die;
   
      randomNumber = random();
      die = 1 + (randomNumber % 12);
      return die;
   }
   

   (returning an integer from 1 to 12) or this

   int Roll2Dice()
   {
      int randomNumber, die;
   
      randomNumber = random();
      die = 2 + (randomNumber % 11);
      return die;
   }
   

   (returning an integer in the range 2 to 12, all the outcomes equally likely) or this

   int Roll2Dice()
   {
      int randomNumber, die;
   
      randomNumber = random();
      die = 1 + (randomNumber % 6);
      return 2*die;
   }
   

   (i.e. rolling a die and doubling the outcome). I think these examples illustrate that common sense suffers when students are struggling with C++.
4. Quite a few people start by writing a new function to simulate the 2nd die.

   int RollDie2()
   {
      int randomNumber2, die2;
   
      randomNumber2 = random();
      die2 = 1 + (randomNumber2 % 6);
      return die2;
   }
   

   Some then try doing

     int total=die+die2;
   

   later in their program rather than calling the functions, not realising that die (in RollDie) and die2 (in RollDie2) are unavailable. At this point some students create global variables die and die2 while still creating the local instances of die and die2 - which silences the compiler but isn't the correct solution.

   Others write a Roll2Dice() function that calls RollDie() and RollDie2() to get the correct answer. Perhaps the existence of 2 dice makes them think they need 2 functions - I suspect they wouldn't write 2 functions to calculate the square roots of 2 numbers, or write 10 functions to roll 10 dice.

5. The next is one of the most common solution, not calling the provided RollDie function at all.

   int Roll2Dice()
   {
      int randomNumber, die, randomNumber2, die2;
   
      randomNumber = random();
      die = 1 + (randomNumber % 6);
      randomNumber2 = random();
      die2 = 1 + (randomNumber2 % 6);
   
      return die+die2;
   }
   

Conclusions

I was hoping for

   int Roll2Dice() {
   int die1=RollDie();
   int die2=RollDie();
   int sum=die1+die2;
   return sum;
}

or even just

  int Roll2Dice() {
  return RollDie() + RollDie();
}

It's easy enough in a handout to explain how to write correct code, but this year we didn't want to tell them exactly what to type. Just about everything that we didn't dictate to them produced errors that revealed a lack of understanding. I think it would be counter-productive to anticipate and correct these misunderstandings by putting a list of what not to do in the handout - it would confuse them. Besides, it's useful to have these conceptual errors exposed as early as possible as long as demonstrator help is available.

Some of the solutions above are correct and the students often understand what they've written, so there's a case for letting them get on with it, but they're going to have bigger problems later if these conceptual hurdles aren't tackled now. (I once looked at a IIB project student's final program. It barely used functions. By factorising repeated code I reduced the line-count to 30% of the original. Worrying).

Some students are clearly just guessing as they go along, looking for any lines of code that look as if it should be copied. It would help if they revised earlier work, or trace their finger along the locus of control, explaining it line-by-line. Others start with a reasonable idea of what to do but make small mistakes that lead to bigger ones as they try to silence the compiler at all costs. It would help if they could identify run-time errors as soon as possible, but iterative development is something they only slowly learn, and besides, not all of them know what results to expect.

Understanding functions remains a problem. We introduce functions by analogy with mathematical functions, but in C++ they can see inside the black-box that is the function, and once they do, they find it hard to treat the function like a black-box ever again (it becomes a physical thing occupying space, rather than a concept). As an educational aid it helps to have an editor that collapses functions.

Frequencies

We get the students to run routines like Roll2Dice() and record the outcomes. They find

   int outcome=Roll2Dice();
   frequency[outcome]=frequency[outcome]+1;

hard to understand, which isn't so surprising given that after 6 hours of practicals

• a few students still don't know how to add 1 to a simple variable.
• more than a few students have "no idea" how to write a line that "creates an array called frequency big enough to store 6 integers". I left one such student to read the documentation for a few minutes, but when I returned to him he was none the wiser. The Arrays section of the doc might be sub-optimal, but it can't be that bad - it's much the same as last year's.

Even those who do understand arrays have trouble with the code quoted above, though they're happy with

   int outcome=Roll2Dice();
   if(outcome==1)
      frequency[1]=frequency[1]+1;
   if(outcome==2)
      frequency[2]=frequency[2]+1;
   ...

I've tried to spell out a 2-page explanation of the shorter version as a Frequently Asked Question but some people don't understand that either. When the penny drops they sometimes remark "that's clever". Then they try to be too clever and do

    frequency[Roll2Dice()]=frequency[Roll2Dice()]+1;

wondering why it fails (they're calling Roll2Dice twice, so the RHS and LHS may refer to different array elements). Having fixed it they put the line in a loop. A few students do this

int tries=0;
while(tries<100) {
   int outcome=Roll2Dice();
   frequency[outcome]=frequency[outcome]+1;
   frequency[outcome]=0;
   tries=tries+1;
}

Why is frequency[outcome]=0; there? Well, one student said that it was in an earlier loop so they thought they'd better put it in this loop too.

In short, there are still many indications that a non-trivial minority of students are just fumbling blindly through. If anything, the changes to the course this year make it easier for demonstrators to identify the students with severe problems - it's harder for students to bluff their way through.

According to "Validating an instructor rating scale for the difficulty of CS1 test items in C++" (Lulis and Freedman, JCSC 27, 2 (December 2011)) "faculty members disagree amongst themselves as to the difficulty level of questions involving functions", much more so than for questions involving other topics.

Online help systems

On 29 June 2011 I'm attending a UCISA symposium on "Advisory and IT Support" about "Producing a service desk good practice guide - Measuring the service desk". A parallel session that I'd also have liked to attend was from University of Lincoln - "A project, led by ICT, focused on changing the ICT and Estates service by embedding a new culture across both departments that delivers excellent, consistent service, underpinned by a robust framework of technology, processes, learning, development and support". As preparation I thought I'd summarise our experiences.

Changes in user skills and expectations regarding the WWW offer challenges and opportunities for information providers, but it's far from being merely a technological issue that can be solved by a new piece of software. As Lincoln has discovered, culture (amongst staff as well as amongst users) and processes matter, and need to be understood. MIT have produced a report on their attempt to update their system - see the Nercomp Hermes presentation.pdf. They say that a culture of "Knowledge Centered Support" involves developing "knowledge as part of problem-solving process - When you solve a user’s problem, document it". Inhibitions to this included

• Wiki markup (or browser support for WYSIWYG editors)
• Time pressure (for frontline support, primarily)
• Different self-imposed “standards” for publication
• Unease with public information, even if there’s nothing inherently confidential
• "Ownership": if I write about it, I might have to support it

Their list of "Lessons Learned" included

• "It's harder to get contributors than we thought"
• "Did not set up a tracking mechanism up front. Can't tell who's looking at what."
• "Get buy-in from decision makers to make "executive" decisions setting expectations for internal IS&T groups to contribute information"
• "Need to be clear about what information goes where, e.g. website versus knowledge base"
• "Ongoing maintenance is required to keep content fresh."
• "There's a need for an advocacy role"

Their project had definite end date and finite resources and a special one-time allocation of funds, which helped to force things forward.

Many of these finding chime with my observations - see the Searching, Culture, Distributed Authorship, and Solutions sections below. My department has had an online help system since 1994, several authors having produced pages. Our oldest page was last modified at "1995-01-06 12:41:20 GMT". A 1997 version of our front page is still online

Oct 1997 (traffic 33k pages/day; click to zoom)

Aug 2010 (traffic 201k pages/day; click to zoom)

Apart from the house styling, you'll see that little has changed on the surface - even in 2010 it was still described as the "hypermedia help system"! In 1996 I wrote a little review of the help system where I mentioned that

• "We are encouraging (not very successfully) admin and teaching staff to maintain their own material."
• "We have regular users of our system who still don't use e-mail let alone the help system, so personalised user education is still necessary."
• "[people are] Over-using brute-force searches"

We had a help-search facility but I don't know what it was - Google hadn't really take off by then. Maybe we already used swish, an earlier version of swish-e a public-domain indexing facility.

Keyword searching wasn't the only option for users - we offered "task-based" and "subject-based" trees of links, and pages had at their foot a list of related pages so that users could browse around. In those days there were several sites (e.g. Yahoo) that maintained a hierarchy of links to pages so that people could browse as an alternative to word-searching when they wanted to find something out. Even in 1996 however, people preferred brute-force searches though their search terms were often more hopeful than precise.

Between 1996 and 2003 the amount of material grew, as did the variety of types (PHP, movies and databases appeared). Our dependance in the help system as a front-line service grew too - in our introductory letter to new undergraduates we wrote "The department has an extensive help system ... which has answers to many questions people ask about the Engineering Department computer system. Please look at this first and if you cannot find an answer there consult the Department's Computer Operators". The success of Google meant that more than ever, users word-searched for information rather than browsed through hierarchies. Google ranks pages in a way that satisfied most users. Customised site-specific searches can be set up using google, but there are difficulties using Google to look for local information because some of it was domain and/or password protected.

The growth in local material hadn't matched growth globally. Many of the documents we wrote in the early years had been superceded by documents elsewhere. Because of the increased performance of the internet there was not even a speed advantage to having local documentation.

Searching

By 2003 it was clear that university establishments might have special requirements when it comes to searching. The Search facilties for UK HE web sites paper (written by a Cambridge webmaster) dates back to 2003 and lists some useful alternatives.

Troubles that people searching our site have are that

• It can be hard to think up useful search terms for questions involving a lack of understanding rather than a simple lack of information
• Many queries involve generic computing terms (e.g. "open", "windows", "word") which makes ranking more difficult.
• Coverage will be patchy with some common questions not covered while other obscure topics might be covered in a depth that swamps the results of searches. If a user fails to find information in their first help-search (which is likely) they'll be wary of using it again. At least Google comes up with something even if it's not locally relevant.

A 2007 consultant's report about the University site noted that local searches still posed problems - "Most of the [users'] complaints about the site fell into three areas:" the first-mentioned being "inadequate search facility: It was generally felt that an external google search yielded more appropriate and better presented results than the search function on the existing University website". The report went on to say that "As a minimum Google search should be implemented across site content .... Adoption of a University-wide meta-tagging is a prerequisite and a major editorial undertaking that should be done as part of the initial content rework". However, this recommendation seems not to have been adopted by the University

Culture

The department's help system has a rather elite target audience who are science-literate, but can be naive computer-wise. Amongst the opinions about the Help System are these -

• That it in some sense belongs to the Computer staff (it does)
• That it in some sense belongs to a small subset of Computer Officers (it doesn't. Any CO or operator can contribute)
• That pages have to be written in HTML using the current house style (they should. Example pages are provided)
• That authors will get mailed if a page is wrong (they will if links go bad, or if mistakes are noticed in a popular page)
• That it's old-fashioned static HTML (most of it is static HTML)
• That material is hard to find

Some of these beliefs inhibit page production

• If a person thinks that they're not allowed to write pages, they might add them to their research group's web site or to their personal pages)
• An author might rather not write a page at all than have to maintain pages long-term.
• If the help system aims to replace work done by people, those people will be out of a job (or at least will have to do less pleasant work)

Some of these beliefs inhibit users trying the help system

• For the 50% of students who use Facebook at least once a day, the help system will look old
• The un-Googly search looks unfriendly

Though the skills that web users employ to further their hobbies aren't always used in their academic work, the gap between the help system and other information systems has widened recently.

Distributed Authorship

From the start, pages in the help system were owned and looked after by many people, though a small number of people write most of the pages. Initially a few central pages were owned by webadmin and the rest were in folders owned by individuals, making for easy management and identification of ownership. Each page mentioned its author, so bug reports could easily be directed to the right person, and (except for the top level) folders didn't contain files with a variety of owners.

There are disadvantages to this (e.g. when people leave, their pages need to be moved) but when we tried having more central pages authored by a role rather than an individual, mail to that role-name was left unanswered. It can take over a year for an incorrect sentence to be removed from a page, even with reminders.

Multiple authorship introduces other problems too - the standard of the HTML varies widely, and also when an author produces a new page they need to tell other authors to link to it.

Solutions

In 2009 a student created a pilot system based on Wordpress blog software, hoping to leave behind some of the above-mentioned beliefs. It shares many design ideas with MIT, though we were unaware of MIT's plans at the time.

• Comments can be added by anyone to pages
• A WYSIWYG editor and form-based input means fewer errors and easier authoring
• Pages can be drafted so that someone else can authorise them.
• There's more automated page- and link-checking
• It's a blog, and blogs aren't old fashioned - they're fun (User 2.0).
• When a new page is created it appears immediately in other pages' "related links" lists
• Authors can add a comment to other pages, mentioning their new page. Better still, each page has an auto-generated "Related Pages" section at the end that lists pages with related tags.
• a Wiki-style option is possible, letting authors reversably change other authors' pages
• A WYSIWYG editor will guarantee more consistent (but not necessarily better) HTML
• The system automatically records authorship
• line managers can list all the pages written by particular authors, along with modification dates.

"The Corporate Blogging Book", Debbie Weil (Piatkus, 2006) looks at issues relating to the introduction of blogs into an e-mail-literate workplace. It mentions inhibitions

• If bosses don't blog, why should the employees?
• Some users and management think that time will be wasted (it will, if the resulting pages aren't used and advertised by staff)
• People who are confident enough writers to post e-mail have doubts about producing web pages (because of larger audience, and uncertainty about etiquette)

The book also mentions advantages, some of which haven't yet been mentioned

• RSS feeds help reduce bulking mailing
• Less distance between "us and them" - students and staff

For more details, see the student's Final Report

Meanwhile, in October 2010 we gave the old material a new front page

Oct 2010 (click to zoom)

Teaching O-O

We teach using Matlab and C++ so we could teach programming in an Object-Oriented way. Post-2008, Matlab's O-O support has become neater, and has more features - listeners; something similar to Java's final, etc, but we don't talk about that aspect of Matlab. Undergraduates define their own C++ classes in the 1st year, but only in an optional 3rd year course do they really get introduced to O-O. There's not really enough time to push multi-paradigm programming at them. They would end up forgetting how to write loops, or whether arrays begin at 0, and they'd more often do things like getting programs to print the final results by putting the output code into a destructor, or using objects merely to modularise code.

In a way you might think engineering suits O-O - re-usable components and interfaces are common to both fields - but engineers also know about K.I.S.S. and over-engineering.

In "Python for Teaching Introductory Programming: A Quantitative Evaluation" (Jayal et al; Italics V.10.1 Feb 2011) they say they "found four experimental studies that compare object oriented approach with the traditional procedural approach". One "by Reges (2006) has found significant gains in student satisfaction and enrolment after replacing the object oriented programming first curriculum with a procedural approach". The other 3 studies found no significant differences. Jayal et al. found that students who started with Python then did Java performed better than students who did Java all the way through the course.

In Back to Basics in CS1 and CS2, Stuart Reges says "Our new version of CS1 looks a lot like a 1980's course taught in Pascal. We have gone back to procedural style programming. I was motivated to do this after attempting and failing to teach a broad range of introductory students at the University of Arizona using an 'objects early' approach. I found that my best students did just fine in the new approach, but the broad range of midlevel students struggled with the object concept". The course begins by using Java with a lot of public static methods. He writes "Our switch to static methods has allowed us to bring back the problem solving aspects of the course that we thought were so important in the 1980's" adding that "even though Java is not an ideal choice for our CS1, we continue to use it because of its payoff in our CS2 course."

If that reasoning applies in a Computer Science course it applies even moreso to Engineering, I'd have thought. So should O-O stand for "Objects-Overrated"?

"Coders at Work" (edited by Peter Seibel, Springer-Verlag, 2009)

"Coders at Work" (edited by Peter Seibel, Springer-Verlag, 2009) has interviews with several famous programmers. Most use Emacs and debug using print statements. Most try to understand code in several ways - bottom-up, top-down, following the effects of a user action (e.g. deleting a character in an editor), looking at data structures, etc. Here are some quotes that might be of use

C++

• "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

C

• "C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine", Allen, p.502
• "the biggest security problem to befall modern computers is C", Cosell, p.557
• "one of the most important revolutions in programming languages was the use of pointers in the C language", Knuth, p.585

Debugging

• "I love strace. Strace, I don't think I could live without", Fitzpatrick, p.79
• "I think an hour of [team] code reading is worth two weeks of QA", Crockford, p.103
• "we have found fuzz testing to be more productive than almost any other kind of testing", Eich, p.138
• "the most important [debug] tools for me are still my eyes and my brain. I print out the code involved and read it very carefully ... So long as I can put print statements in the code, and I can read it thoroughly, I can usually find the bugs", Bloch, p.189-190
• "most of my subjects have found that the hardest bugs to track down are in concurrent code", Seibel, p.xiii
• "the first thing I will try is dropping in print statements to see if it will help me, even though that is probably the least effective for dealing with a complicated bug. But it does such a good job of grabbing the simple bugs that it's worth a try", Steele, p.365
• "I don't know of anybody who [uses print statements] if they have the choice of using a good debugger", Ingalls, p.405

Gender

• "Recently I realized what was probably the root cause of [the glass ceiling]: computer science had emerged between 1960 and 1970. And it mostly came out of the engineering schools ... And the engineering schools were mostly all men in that period", Allen, p.510
• "A lot of people think it's the games and the nerdiness of sitting in front of a computer all day [that making computer science unappealing to women]. It's going to be interesting how these new social networks online will have an effect", Allen, p.513
• "the conventional wisdom at the time ... said that women made good programmers because they pay attention to details ... today ... they're great on teams because they like to collaborate", Allen, p.507, 509

Miscellaneous

• "We installed some buttons on the computer, because you could do that, at the time and one was a panic button. When the program appeared to loop one could just press the panic button", Allen, p.488
• "I remember reading books about languages that I had no way to run and writing programs on paper for languages that I'd only read about", Zawinski, p.2
• "I despise [perl]. It's a horrible language", Zawinski, p.11
• "One of the jokes we made at Netscape a lot was 'We're absolutely 100 percent committed to quality. We're going to ship the highest-quality product we can on March 31st'", Zawinski, p.34
• "On [Google's] top six or seven languages, there's a really strict style guide", Fitzpatrick, p.72
• "I had a friend who had some iptables rule that on connection to certain IP addresses between certain hours of the day would redirect to a 'You should be working' page", Fitzpatrick, p.73
• "most of the security problems that we've seen in operating systems over the last few years are a consequence of ++. In my programming style now I don't use ++ anymore, ever", Crockford, p.106
• "I think threads are an atrocious programming model", Crockford, p.121
• "I'm not an object-oriented, design-patterns guy", Eich, p.138
• "I can't even remember which [UML] components are supposed to be round or square", Bloch, p.181
• "the best existing multithreaded building blocks are in Java", Bloch, p.198
• "I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them", Armstrong, p.213
• "with very difficult problems I quite often start right by writing the documentation", Armstrong, p.231
• "From what I've seen of programmers, they're either good at all languages or good at none", Armstrong, p.235
• "I don't think software is fractal ... I think the things that happen when systems get large are qualitatively different from the things that happen as systems go from being small to medium size", Deutsch, p.421
• "garbage collection fights cache coherency massively", Thompson, p.472

About the programmers

• Jamie Zawinski (Xemacs, Netscape, Mozilla)
• Brad Fitzpatrick (LiveJournal, memcached, Google)
• Douglas Crockford (Yahoo! Invented JSON)
• Brendan Eich (Netscape, Mozilla, Invented JavaScript)
• Joshua Bloch (Chief Java Architect at Google)
• Joe Armstrong (invented Erlang)
• Guy Steele (Lisp)
• Dan Ingalls (Smalltalk)
• L Peter Deutsch (Ghostscript)
• Ken Thompson (Unix)
• Fran Allen (IBM, compilers)
• Bernie Cosell (PDP-1)
• Donald Knuth (TeX, algorithms)

Teaching Aids

The evaluation of new courses isn't always easy, especially when technology's involved. There's the

• Hawthorn Effect - students work harder when they know evaluation is happening
• Novelty Effect - some students like playing with new tech (the effect soon wears off)
• ??? Effect - students are affected by the increased motivation and interest of the staff

It's likely that the course needed an overhaul anyway, so even a less innovative re-write might have been popular

I went to a talk recently about the effect new tech might have on education. One person pointed out that years ago lap-tops were going to revolutionize education, but it hasn't really happened. Before that there was computer-aided-education (too often rote-learning). I think the web has changed things, more by evolution than revolution - information and help's more readily available. For computing there are Forums where sensible questions get quick and informative answers. There are Web pages covering issues that students might get stuck on - pointers, O-O, etc. Students no longer need to struggle on without documentation. Meanwhile however, the method of teaching programming doesn't seem to have changed much. Textbooks have become more varied (more jokes, more games) but the mainstream books haven't changed much. For C++ we suggest that students get Deitel and Deitel. The text (1600 page of it) is multicolored, there are asides in the margin and an associated Web site but the pattern remains of telling students about a concept then getting them to write a program that uses the concept. Some online books like Introduction to Programming Using Java (David J. Eck) have embedded Applets, which can be useful.

I've tried a few things

• C++ function teaching aid
• C++ "for" loop teaching aid
• Simple animations

and a lecturer's written MetaCard animations. I've rewritten the 1st year C++ course and put it online. Though it's traditional in structure, it has links to supplementary material that students wouldn't follow were the links on paper. And we offer short and long versions of the document.

For other subjects I think the availability of Apps (simulations, periodic tables, movies, animations) has assisted greatly. Not so in HE Computer Science. Facilities like Scratch are great, but have their limits. So what's next?

• E-books - Most student work is still submitted on paper, and many handouts are on paper. A local department thinks it would be cost-effective to supply each student with an e-book loaded with course PDFs. The killer app is a program that makes freehand PDF annotaion easy
• Tablets/Slates - In group activities with computers, it's typical for one person to hog the mouse. Tablets make the work more collaborative
• GPS - Field trips, etc benefit from cameras with GPS
• Smartphones - Students seem more likely to do something (e.g. provide feedback) if there's an App for it

but perhaps collaborative tools will make the most difference in the end. Google Docs can be used as a document collaborative tool: it's online, with version control and change tracking - and it's free.