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, 30 March 2015

Using Software Metrics in Automated Assessment

In an attempt to make assessment of code less subjective I've tried using cccc to gather software metrics for a year's worth (about 40 programs) of interdisciplinary projects, hoping that some of the values will correspond to human-assessed Software quality or the general performance. The task is quite tightly constrained, so I was hoping that differences between metrics might be significant, though the task involved electronics and mechanics too, and students could choose whether to use O-O or not.

The cccc program measures simple features like lines of code, lines of comments, etc., but also it measures "information flow between modules" and "decision complexity". It's easy to use. The only problem in practice is that it needs to be given all and only the code used to produce the students' program. Some students' folders were very messy, and their version control was little more than commenting/uncommenting blocks of code, or saving old files with names like "". Some teams had main programs that incorporated calibration and testing code whilst others wrote separate programs to perform these tasks. I tried to data-cleanse before running cccc, but the project was too open-ended to make comparisons fair.

I can't see any correlations useful to us, though there's a great variety of code statistics (the code/comment ratio ranging from 1.3 to 59 for example). As a rule of thumb (and unsurprisingly) it seems that teams who use more than 1 source file tend to get decent marks. Those with a few physical source files but only one logical file (e.g. a with

#include ""
#include ""

etc.) tended to fare poorly. Here's some sample cccc output along with the human marks.

Num of modules (NOM) 114143051
Lines of Code (LOC) 5656229173017948498291291
McCabe's Cyclomatic Number (MVG) /NOM8078597331120132212
Lines of Comment (COM) 13222316583130814320
LOC/COM 4.282.7810.42.152.7594.03
MVG/COM 0.60.353.60.390.390.66
Information Flow measure/NOM 00002200
Software Mark (human)5653 7167756662
General Performance (human)6550 8065756060

What CCCC measures

CCCC creates web-page reports. It measures

  • Number of modules NOM
  • Lines of Code LOC
  • McCabe's Cyclomatic Number MVG
  • Lines of Comment COM
  • Information Flow measure ( inclusive ) IF4
  • Information Flow measure ( visible ) IF4v
  • Information Flow measure ( concrete ) IF4c
  • Lines of Code rejected by parser
  • Weighted Methods per Class ( weighting = unity ) WMC1
  • Weighted Methods per Class ( weighting = visible ) WMCv
  • Depth of Inheritance Tree DIT
  • Number of Children NOC (Moderate values of this measure indicate scope for reuse, however high values may indicate an inappropriate abstraction in the design)
  • Coupling between objects CBO (The number of other modules which are coupled to the current module either as a client or a supplier. Excessive coupling indicates weakness of module encapsulation and may inhibit reuse)
  • Information Flow measure ( inclusive )
  • Fan-in FI (The number of other modules which pass information into the current module)
  • Fan-out FO (The number of other modules into which the current module passes information)
  • Information Flow measure IF4 (A composite measure of structural complexity, calculated as the square of the product of the fan-in and fan-out of a single module)

McCabe's Cyclomatic Complexity is a measure of the decision complexity of the functions. Information Flow measure is a measure of information flow between modules

See Also

Wednesday, 24 December 2014

"Geek Sublime" by Vikram Chandra (Faber and Faber, 2014)

The author's written some very respectable novels and stories, but he was also a programmer and a computer consultant - a self-confessed geek. The blurb says "What is the relationship between the two? Is there such a thing as the sublime in code? Can we ascribe beauty to the craft of coding?" but only a small proportion of the book directly deals with that. He begins by pointing out some people's attempts to relate programs and arts

  • According to Graham, the iterative processes of programming - write, debug (discover and remove bugs, which are coding errors, mistakes), rewrite, experiment, debug, rewrite - exactly duplicate the methods of artists (p.2)
  • 'Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do' (Donald Knuth - literate programming)
  • "Of all the different types of people I've known, hackers and painters are amongst the most like" (Paul Graham) (p.2)

He points out that US and Indian computer cultures are different

  • In a 2013 interview, the executive chairman of Google, Eric Schmidt, said, "Forty per cent of the startups in Silicon Valley are headed by India-based entrepreneurs" (p.75)
  • This [Indian] educational process, with its obsessive emphasis on examinations and rankings, produces legions of rote learners, mark grubbers, and cheaters. It causes casualties - 7379 students committed suicide in 2010, at increate of 26 per cent over 2005 (p.77)
  • the proportion of undergraduate computer-science degrees awarded to women in the US has declined from 37 per cent in 1984 to 18 per cent in 2010 ... Meanwhile, in India, the trend has gone in the other direction ... in 2003, 32 percent of the Bachelor of Engineering degrees in computer science and 55 per cent of the Bachelor of Science degrees in computer science were awarded to women (p.80)
  • research in countries as varied as Iran, Hong Kong, Mauritius, Taiwan, and Malaysia has yielded results consistent who those found in studies in India, showing that there is nothing about the field of computing that makes it inherently male. Varma's conclusion is blunt: 'The gender imbalance in the United States seems to be specific to the country; is not a universal phenomenon (p.83)

He quotes some interesting facts about computer languages

  • COBOL .. still processes 90 per cent of the planet's financial transactions, and 75 per cent of all business data (p.128)
  • Malboge ... is so impenetrable that it took two years after the language was first released for the first working program to appear, and that program was not written by a human, but generated by a computerized search program that examined the space of all possible Malboge programs and winnowed out one possibility (p.130)
  • The open-source database SQLite, at the time of this writing, has 1177 times the amount of test code as it does program code (p.155)

He deals with Indian theories of aesthetics

  • It is the very artificiality and conventionality of the aesthetic experience, therefore, that makes the unique experience of rasa possible (p.150)
  • The speech of the poet can be effective even when it doesn't obey the rules of everyday language. According to Abhinavagupta, even the denotative and connotative meanings are only aids to the production of rasa, unessential props which can sometimes be discarded (p.155)
  • Indian movies mix emotions and formal devices in a manner quite foreign to Western filmgoers; Indian tragedies accommodate comedic scenes, and soldiers in gritty war movies can break into song ... This is why the Aristotelian unities of British and American films seemed so alien to me (p.161-2)
  • Mary Douglas writes ... 'ring composition is extremely difficult for Westerners to recognise.' ... ... When I was writing my first book, I had never heard the phrase 'ring composition,' but the method and its specific implications and techniques came readily to hand because - of course - I had seen and heard it everywhere. What I wanted within the nested circles or chakras of my novel was a mutual interaction between various elements in the structure (p.165)
  • Shulman writes that in India, reiterations and ring compositions 'speak to a notion of reality, in varying intensities and degrees of integrity, as resonance, reflection, or modular repetition understood as eruption or manifestation (avirbhava) from a deeper reservoir of existence (p.167)

Then he gets into Indian metaphysics and Tantric practices, the role of woman in Indian culture, Sanskrit and the consequences of the Empire. Finally he returns to the literature/programming issue -

  • programmers ... often seem convinced that they already know everything worth knowing about art ... to make art, you don't have to become an artist - that anyhow, is only a pose - you just analyse how art is produced, you understand its domain, and then you code art (p.209)
  • For my own part, as a fiction writer who has programmed, thinking and feeling as an artist is a state of being utterly unlike that which arises when one is coding (p.210)
  • To compare code to works of literature may point the programmer towards legibility and elegance, but it says nothing about the ability of code to materialize logic ... Most discussions of the beauty of code I have encountered emphasize formal qualities of language - simplicity, elegance, structure, flexibility ... But programs are not just algorithms as concepts or applied ideas; they are algorithms in motion. Code is unique kinetic. It acts and interacts with itself, with the world. In code, the mental and the material are one. Code moves. It changes the world (p.221)

Tuesday, 5 August 2014

"The Art of UNIX Programming"

This book's by Eric S. Raymond, published by Pearson Education. Though it dates from 2004 it's still interesting. It filled some gaps in my knowledge.


  • "There is evidence [Hatton97] that when one plots defect density versus module size, the curve is U-shaped and concave upwards" (p.86)
  • "second-system effect" - "the urge to add everything that was left out the first time around" (p.29). "third-system effect" - "after the second system has collapsed of its own weight, there is a chance to go back to simplicity and get it really right. The original Unix was a third system" [after CTSS and Multics] (p.29)
  • "Holding down the shift key required actual effort: thus the preference for lower case, and the use of "-" (rather than the perhaps more logical "+") to enable options" (p.242)
  • "marshalling" means "serialising"
  • "A program is transparent when it is possible to form a simple mental model of its behaviour that is actually predicive for all or most cases" (p.133)
  • "Software systems are discoverable when they include features that are designed to help you build in your mind a correct mental model of what they do and how they work. (p.133)
  • "Threading is a performance hack ... they do not reduce global complexity but rather increase it" (p.159)
  • "Despite occasional exceptions such as NFS and the GNOME project, attempts to import CORBA, ASN.1, and other forms of remote-procedure-call interface have largely failed - these technologies have not been naturalized into the Unix culture" (p.178)
  • "Today, RPC and the Unix attachment to text streams are converging in an interesting way, through protocols like XML-RPC and SOAP" (p.179)
  • "Unix was the first production operating system to be ported between differing processor familes" (p.393)


  • "Emacs stands for Editing MACroS" (p.351)
  • "yacc has a rather ugly interface, through exported global variables with the name prefix yy_. This is because it predates structs in C; in fact, yacc predates C itself; the first implementation was written in C's predecessor B" (p.353)
  • scp calls ssh "as a slave process, intercepting enough information from ssh's standard output to reformat the reports as an ASCII animation of a progress bar" (p.169)
  • "No discussion of make(1) would be complete without an acknowledgement that it includes one of the worst design botches in the history of Unix. The use of tab" . The author said that he "had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history"


  • "Outside of Fortran's dwindling niche in scientific and engineering computing, and excluding the vast invisible dark mass of COBOL financial applications at bank and insurance companies, C and its offspring C++ have now (in 2003) dominated applications programming almost completely for more than a decade. It may therefore seem perverse to assert that C and C++ are nowadays almost always the wrong vehicle for beginning new applications development. But it's true; C and C++ optimize for machine efficiency at the expense of increased implementation and (especially) debugging time" (p.323)
  • "C++ is anti-compact - the language's designer has admitted that he doesn't expect any one programmer to ever understand it all" (p.89)
  • "Python is "generally thought to be the least efficient and slowest of the major scripting languages, a price it pays for runtime type polymorphism" (p.337) "it encourages clean, readable code and combines accessibility with scaling up well to large projects" (p.338)


  • "The OO design concept initially proved valuable in the design of graphics systems, graphical user interfaces, and certain kinds of simulation. To the surprise and gradual disillusionment of many, it has proven difficult to demonstrate the benefits of OO outside those areas" (p.101-2)
  • "Unix programmers have always tended to be a bit more skeptical about OO than their counterparts elsewhere" (p.102)
  • "a lot of programming courses teach thick layering as a way to satisfy the Rule of Representation. In this view, having lots of classes is equated with embedding knowledge in your data. The problem with this is that too often, the 'smart data' in the glue layers is not actually about any natural entity in whatever the program is manipulating - it's just about being glue" (p.102)
  • "One reason that OO has succeeded most where it has (GUIs, simulations, graphics) may be because it's relatively difficult to get the ontology of types wrong in those domains" (p.103)

Quotes by others

  • "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface" (Doug McIlroy)
  • "La perfection est atteinte non quand il ne reste rein à ajouter, mais quand il ne reste rien à enlever" (Antoine de Saint-Exupéry)
  • "C++: an octopus made by nailing extra legs onto a dog" (anon)
  • "Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity" (David Gelernter,"Machine Beauty: Elegance and the Heart of Technology")
  • "When in doubt, use brute force" (Ken Thompson)
  • "If you know what you're doing, three layers is enough; if you don't, even seventeen levels won't help" (Padlipsky)

Tuesday, 6 May 2014

Which computing language for engineers?

At our site we teach general engineering - students amongst other things can learn AI, Economics, and bridge-building. Which language should they be taught? Though their needs are different from those of Computing students and of more specialist (e.g. Electrical) Engineering students, their programming needs may be extensive. In Teaching Introductory Programming in Tertiary Engineering Education M.G. Rashed points out that "Computers are increasingly used for a variety of purposes in engineering and science including control, data analysis, simulations and design optimization. It is therefore becoming more important for engineering students who are computer science non-major, to have a robust understanding of computing and to learn how to program". It's over 15 years since we last changed the primary language (I've found a document from 1996 which addresses the issue - Teaching Programming in the Engineering Tripos). In that time much has changed in the world of engineering, so a review of our language choice is timely.

1985Pascal as a 1st language
1996?Matlab as a 2nd language
1997C++ as a 1st language
???Compulsory computing questions
in the 1st year exams.
2008Vacation C++ exercise
20101st week Lego Mindstorms (Matlab)
2012C++ course flipped - 25% more labs
at the expense of lectures
2014Scratch used in a prelim exercise


Firstly then, what factors could influence our choice, and how have those influences changed over the years? Here are a few -

  • The history and culture of the department - the department tends to teach the fundamentals in a non-specialist way for the first 2 years of a student's career
  • The value of programming in general - When I was taught Latin at school I was told that it was good for me, it trained my mind. Nowadays Mandarin might be taught on the grounds that it's a common language, or Esperanto because it's an easily learnt, well-designed one. Similar differences of opinion apply to the reasons for teaching computing languages. Programming skills might have intrinsic value or be widely transferable. According to its advocators, Computational Thinking "involves a set of problem-solving skills and techniques that software engineers use to write programs ... However, computational thinking is applicable to nearly any subject. Students who learn computational thinking across the curriculum begin to see a relationship between different subjects as well as between school and life outside of the classroom. Specific computational thinking techniques include: problem decomposition, pattern recognition, pattern generalization to define abstractions or models, algorithm design, and data analysis and visualization".
  • The value of programming for engineering - M.G. Rashed thinks that "The primary target in teaching computing is to enable the students to convert engineering problems into pseudo-code. ... The conversion of this pseudo-code into a program written in one programming language is of secondary importance because it is, in principle, an algorithmic procedure and requires less intellectual effort. ... In the teaching practice, the algorithmic problem- solving and implementation tasks are often entangled simply because the students need to test an algorithm they invented by implementing it. Consequently, the choice of the teaching language should be governed by which language provides the best support to the student in performing the implementation part of the problem-solving task by removing any extra stumbling blocks. For this reason the usefulness of the language after graduating or speed of execution will not be the prime factors when making the choice."
  • Requirements of other courses - some other courses assume specific aspects of computing competence.
  • Students' previous experience - A long time ago many students arrived 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, and raspberry Pi kits on sale, 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.
  • Students' expectations -Though they may program less than earlier generations did, they use computers far more. In particular they rather expect there to be an app for everything - to supply documentation, to provide an interface to hardware (instead of a remote being provided, etc). They may hope that what they produce looks rather like an app.
  • Industry relevance - Anecdotal comments from staff suggest that some companies aren't convinced that we are preparing our students for programming. C is more useful for embedded systems than C++. Matlab experience is often requested. One problem is that the needs of industry change, and aren't easy to predict long enough in advance. 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. One student wrote to me that "surely as a professional chartered engineer if you need to do some programming/coding you would hire a professional who would do it in no time at all plus do it correctly" but it would be a shame if the engineer got ripped off because they hired professionals to write trivial or poorly-spec'd software.
  • Language features - ease of use, expressiveness - Despite the popularity of languages such as FORTRAN and C/C++, there has been much debate about the suitability of these languages for education, especially when introducing programming to novices. These languages have not been designed specifically for educational purpose, nor do they make for easy use of the WWW or creation of GUIs. Interpreted languages are growing in popularity (the image is from the M.G. Rashed paper).
  • Programming paradigm - Our approach emphasises the procedural aspects of C++, downplaying O-O in order to introduce more problem-solving practise.
  • Availability of compilers, IDEs, and teaching materials - We've had some trouble providing easily-installed C++ IDEs across platforms. All the teaching materials are on the WWW. Web2 technology has been exploited -
    • Documentation for the 1AC++ Mich course is now WWW-based with online PHP-based teaching aids.
    • A 2nd year C++ course went a step further, incorporating online marking.
    • The Mars Lander project uses CamTools to host documentation and student-staff communication
    Sometimes (to facilitate automated assessment for example) the presentation framework imposes limits on the nature of the course.
  • Availability of teaching staff - With class sizes of 90 or so, computing practicals require several skilled helpers.
  • Learning styles - Teaching remains based on practicals with demonstrator support. There are fewer lectures. Independent study has been encouraged by providing the MDP disc, giving help to students installing compilers on their own machines, and changing teaching material so that documentation is on the WWW, the exercises requiring the minimum of extra libraries.


One needs to assess trends with caution. Wikipedia's Measuring programming language popularity page lists, amongst others

Within education, statistics are perhaps more reliable

  • A Snapshot of Current Practices in Teaching the Introductory Programming Sequence (2011) points out that for CS0 ("an introductory course with no prerequisites, involving at least some programming, that does not count towards the major") Alice was top, though there "is a tremendous variety in approaches". In CS1 the results were: Java 48%, C++ 28%, Python 12%.
  • An InfoWorld article (2014) quotes results from an Association for Computing Machinery survey - "Eight out of the top 10 universities now use Python to introduce programming"; "Python has been growing in popularity in the educational realm for at least the past few years, though this survey is the first to show it has eclipsed Java, which has been the dominant teaching language for the past decade".
  • A Survey of Literature on the Teaching of Introductory Programming (from the ACM Special Interest Group on Computer Science Education, 2007?) gives a useful overview and annotated bibliography. It points out that
    • "Three decades of active research on the teaching of introductory programming has had a limited effect on classroom practice"
    • "Today, C, Java and C++ top the list of the most widely used programming languages, both in industry and education"
    • "Studies have found that market appeal/industry demand/student demand is one of the most important factors affecting language choice in computer science education"

Within the general trends there's significant variation - for example, Stanford have a course based on JavaScript.

Also there's an increasing use of Moocs.

Candidate languages

The SIGCSE report mentioned above says "An appropriate language can only be chosen after course goals and learning outcomes have been specified". FYI, our 2013-14 doc said

The aims of the course are to:

  • Give a good understanding of basic design methods and techniques and emphasise, in particular, the need to produce well-structured, maintainable computer software.
  • Reinforce the IA practical classes in C++ programming and provide a firm foundation for IB practical work.

As specific objectives, by the end of the course students should be able to:

  • Understand the nature of software engineering and the software life cycle
  • Appreciate the need for structured programming in software engineering projects.
  • Be able to write well-structured programs in the C++ programming language to solve practical problems.
  • Understand the sources of errors in numerical programming and how to guard against them.
  • Appreciate the issue of complexity in algorithm design, with particular reference to searching and sorting algorithms.

I think the languages below are the most commonly mentioned at CUED as options -

  • Matlab/Octave - Students use this in week 1. Only in year 2 are they more formally taught it. Matlab has a large range of material produced by univs for ugrads, much of it with a math/engg bias. In a Mathworks newsletter, staff at Vanderbilt University write that "engineers from five major companies ... credited MATLAB with helping them become more efficient and achieve time reductions 'from a week to 15 minutes' and 'from several months to weeks'" citing an automotive engineer’s statement that "MATLAB was a de facto industry standard". Many engineering-related routines and program are available.
  • Python - According to Charles Dierbach ("Journal of Computing Sciences in Colleges" 29, 6 (June 2014)), "The Python programming language has been quickly gaining popularity over the past few years as a language of choice for CS1 courses. Some estimates put the rise in use at forty-percent a year". "The Python programming language has been around since its development by Guido van Rossum around 1991. One of the main features of the language is code readability (sometimes described as "executable pseudocode"). Python is an interactive programming language, using dynamic typing. It is also a hybrid language, supporting the imperative, object-oriented and functional programming paradigms. Although used as a scripting language, it is also used for the development of full-scale programs." The University offer courses in Python for number-crunching, etc. Many engineering-related packages are available.
  • C++/Objective-C/C# - Students use C++ for about 20 hours in year 1 and at least another 8 hours in year 2. In a Cambridge university C++ course it says "Unless you are already a programmer, you are very strongly advised to learn Python first ... learning another programming language would also do. “Programmer” does not mean in Visual Basic, Excel or even most uses of Matlab; it means in Python, Fortran, C, Pascal etc. It surprises most people, but learning simpler languages first often saves time overall. ... You can learn to use any of these (even Fortran) to a comparable level in about 20% of the time that you will need to learn C++"
  • Java - one piece of 3rd year coursework currently requires students to write Java. Their C++ experience is presumed to be a sufficient prerequisite.


Are there advantages in principle in exposing students to several languages? Ultimately it's unavoidable, though perhaps initially it confuses people. We don't compare/contrast languages. We tend to leave that to the students.

Thursday, 27 March 2014

Some educational myths

Well, not myths really, but it's sometimes worth challenging cherished notions

Deep down, students know what's good for them

In "Student interest and choice in programming assignments" (Journal of computing in small colleges 26, 6 (June 2011)) Lisa Torrey surveyed 14 students to find out what motivates their choice of programming exercises. She'd hoped that students would choose programs at the optimal level of challenge but found that "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".

In March 2014's "Assessment and Evaluation in Higher Education", Felton and Mitchell claim (providing some evidence) that "Faculty who lighten workloads and inflate grades buy high SET [Student Evaluation of Teaching] ratings and popularity for their courses". Older staff are less prone to doing this.

The more a topic's taught, the more students will learn

In "When do students learn? Investigating factors in introductory courses" (Journal of computing in small colleges, 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".

The better the teacher's presentation, the more the students learn

In the May 2013 issue of "Psychonomic Bulletin and Review" it reported that "When a presenter is seen to handle complicated information effortlessly, students sense wrongly that they too have acquired a firm grasp of the material". They're more confident, but perform no better.

In "The Times Higher" (30/5/13, p.7) it's reported that "lecture fluency did not significantly affect the amount of information learnt".

Clarity is good

In The secret life of fluency Daniel Oppenheimer wrote that for some exercises, "participants were significantly more likely to detect the error when the question was written in a difficult-to-read font. This suggests that they were adopting a more systematic processing method and attending more carefully to the details of the question".

Monday, 30 December 2013

Supporting LaTeX

When I began working in a university, part of my job was supporting a group who used LaTeX. They used Unix systems, and I maintained LaTeX on them. Installing could sometimes be a slog - fonts were a hassle, and packages kept appearing and re-appearing with inter-dependencies. I produced some handouts to help people with LaTeX. LaTeX2e appeared, which helped.

Time passed. The web was invented, so I put the handouts online, first as postscript docs, then PDF, then HTML/MathML. A web search for Tim Love LaTeX reveals that those docs have been widely copied. Documents like The Not So Short Introduction to LaTeX2e by Tobias Oetiker et al, LaTeX for Complete Novices by Nicola L.C. Talbot and Using Imported Graphics in LaTeX and pdfLaTeX by Keith Reckdahl have taken away the need for books, though the TeX Book is still useful.

As Word improved, LaTeX use seemed to recede, recovering as Linux appeared, LaTeX distributions became more stable, and cross-platform front ends like Kile and Texmaker were developed. pdfLaTeX became the predominant latex processor, DVI files becoming a rarity. As web pages grew in sophistication, LaTeX->HTML convertors became less fashionable (I used to generate PDF and HTML files from LaTeX masters, but tend to maintain the files separately now). The LaTeX page in our help system grew. I started giving talks on LaTeX for beginners and for report writers. Some staff made their undergraduate students learn LaTeX.

The CTAN sites became more comprehensive. A searchable catalogue appeared. Usenet newsgroups became Web forums, and sites like latex-community and tex-latex stackexchange attracted beginners and experts.

The LaTeX community has always been mutually-supportive and widely dispersed. Local support is much less necessary than it used to be, but sometimes it helps provide continuity. A Ph.D student who'd been to my talks and had read my handouts produced a class to support local thesis writers and left it with me when he left. It proved popular - our 3rd most popular help-system page. Another student who'd been to a talk improved the class in 2013 - it's available via our help system.

Thursday, 19 December 2013

Space, time, and C++ source code

In "Scientific American", December 2013, it said of reading texts in general that "When we read, we construct a mental representation of the text that is similar to the mental maps we create of terrain and indoor spaces". Students new to programming may have trouble when facing source code if they create inappropriate maps. I think that the more linear (more like prose) the code is, the easier it is for these students to understand. If execution starts at the top of the file, and ends at the end, so much the better.

Some deviations from linearity are fairly easy for beginners to understand because they're like those used in prose. Difficulties arise when the same part of text is executed multiple times, and/or when there isn't 1-to-1 mapping between the script and behaviour. In one exercise that we give students, we provide the source code of a function to simulate rolling a single dice - int RollDie() - and ask them to write a routine to simulate rolling 2 dice for a board game. Rather than write a function that returns RollDie() + RollDie(), some students create 2 copies of RollDie(), calling them RollDie1() and RollDie2(), then write a function that returns RollDie1() + RollDie2(), so that the conceptual 1-to-1 mapping is preserved. In this case, the fact that real world objects are being simulated may complicate the picture, but using rather more abstract maths proofs as a model introduces other misunderstandings.

In this article I'll consider how some features of C++ hinder the type of mental representation that students are used to. Conceptually, the text of a program is more like assembly instructions for flat-pack furniture than a novel. I'll also point out how some analogies to illustrate how languages work don't help - maths in particular can be a "false friend".


Small loops aren't too hard to understand - a temporary eddy in essentially linear code

while loops are more linear than for loops. In a while loop the lines that are repeatedly run are contiguous and in order; control takes only one step back.

In a for loop, the locus of control passes through the terminating condition, the body of the code, then back to the last statement, then back again, to the terminating condition before executing the body code again


As far as locus of control is concerned, simple functions aren't too bad. They're rather like footnotes - you jump to them and jump back again, carrying on from where you left off. Conceptually you can in-line them. Recursion is more complicated - essentially, multiple copies of the recursing code have to be imagined if the one-to-one correspondence between text and action is to be retained.

False friends - maths and time

  • After
    int y=2;
    int x=y*3;
    what value has x? People familiar with maths might give the answer 12, because they treat x=y*3 as a symbolic assignment, x being re-evaluated whenever needed.
  • In a maths proof, variables are usually symbolic, and at any time can have any value. In contrast, variables in languages like C++ always have a particular value. In
    int i=0;
    while (i<3) {
      cout << i;
    the single textual i variable in the expression i<3 has successively the values 0, 1, 2 and 3. The value changes in a way that the value of maths variables don't. The text in a proof is usually processed linearly - a particular i always means the same thing. Exceptions are in "proof by cases" where the reasoning branches (the "4-color problem" was solved using such a proof - a computer program), and "proof by induction".


The distance between a language and its meaning is emphasised when a small change in the language can greatly change behaviour (and vice versa). C++ has several problems of this nature.

  • int x[12];
    creates an array of integers whereas
    doesn't create an array. It refers to a single element in an array, one which isn't in the array created using int x[12];.
  • The following loop
    int i=0;
    while  (i<3) {
      cout << i;
    terminates, whereas the similar
    int i=0;
    while  (i<3); {
      cout << i;
    runs forever.
  • The lines
    char   c='0';
    int    i=0;
    string s="0";
    produce variables that all look exactly the same when printed using cout, though they're not the same at all.
  • The lines
    if (x < 4)
    if (x << 4)
    do different things. The meaning of "<<" depends on context - here it bitshifts but with cout it does something different. It never means "a lot less than".


  • Introduce students to while loops before for loops.
  • The use of flowcharts might help students who are processing the source code as if it were prose. Alternatively, it might help to use a debugger as a code-animator - see below
  • Code-folding editors are useful - they offer a way to make existing code into a "black-box" once it's stable, so that students don't become distracted by verbose detail.
  • Avoid recursion
  • If the meaning of something depends on context, the students need to be able to identify the limits of that context
  • Be prepared to introduce the idea of idioms. If you're learning English, then analysing the phrase "It is raining" down to the word-level is unhelpful - "what does it refer to?" is a linguistics question. Similarly, breaking down something like
       while(fileInput >> str) {
           cout << str ;  
    into its constituent parts can easily be overdone by beginners who've been told to analyse, but haven't been told when to stop - "what is inside an ifstream"? They do need to know that it reads successive words from a file into the string called str until there are no more words left.