Fifteen Eighty Four

In days of 8-bit computers, one would sometimes encounter individuals who knew everything about a particular device or piece of software. Single programmers wrote entire applications or games, and some could debug their work by looking directly at a core dump (a printout of the numbers stored in the computer’s memory). Some even managed to take computers beyond their specifications by exploiting design loopholes that the manufacturers hadn’t foreseen or intended. It would be fair to classify such individuals as ‘experts’.

Fast forward twenty five years, and the picture is far less clear. The complexity of computers and software has grown to such an extent that even relatively small smartphone applications are created by teams of developers, and nobody understands every aspect of a CPU chip, much less an entire PC or tablet. Who now should be classified as an expert? One possibility is that an expert is a person who may sometimes need to look up the details of a rarely used command or feature, but who is never confused or frustrated by the behaviour of the system or software in question (except where there is a bug), and never needs help from anyone, except perhaps on rare occasions from its creators.

The complexity of computers and software has grown to such an extent that even relatively small smartphone applications are created by teams of developers, and nobody understands every aspect of a CPU chip, much less an entire PC or tablet.

This rather stringent definition makes me an expert in only two areas of computing: the Fortran programming language, and the mathematical computation system Maple. An argument could be made for the typesetting system LATEX, but whilst this has a large number of expert users, there is also a much smaller group of more exalted experts, who maintain the system and develop new packages and extensions. It would be fair to say that I fall into the first category, but not the second.*

How does one achieve expert status? Some software actively prevents this, by hiding its workings to such an extent that fully understanding its behaviour is impossible. Where it is possible to gain expert status, I have experienced two very different routes, both starting during my time as a research student, when it became clear that Fortran and Maple would be useful in my work. There were several parallels. I knew a little about both, having used them for basic tasks as an undergraduate. However, working out why things went wrong and how to fix them was time-consuming and unrewarding, since it often relied on magic recipes obtained from unreliable sources, and in many cases I didn’t really understand why these worked, any more than I understood why my own attempts had not. I realised then that knowing a little was at the root of these problems. Partial knowledge, supplemented by contradictory, outdated and even downright bad advice from websites and well-meaning individuals (some of whom invariably labour under false pretences of their own expert status) is not an efficient way to approach scientific computing. In fact it’s just a recipe for frustration. In the case of Fortran, fixing this turned out to be easy, because there are lots of good books on the subject. Reading one of these eliminated all of my problems with the language at a stroke. I can’t claim that I remembered every command and its syntax, nor do I know them all now. This is hardly surprising — the Fortran Language Standard (a very terse document that sets out everything the language provides) now extends to more than 600 pages. Instead, the book provided a general picture of how things work in Fortran, and showed the right way to go about tackling a problem. This investment in time has since paid itself back hundreds of times over.

The route to expert status in Maple was far more challenging. Its own help pages give a very comprehensive description of individual commands, but they are intended as a reference guide, and if it’s possible to become an expert using these alone, then I never discovered the correct order in which to read them. I found a number of books on Maple in the university library, but most were too basic to be useful, and others focused on particular applications. None seemed likely to give me the general picture — the feel for how things work — that would make Maple into the time-saving resource it was intended to be.

The picture became clearer after I taught Maple to students in three different courses. Nothing encourages learning better than the necessity to teach someone else! Investigating the problems that students experienced gave me new opportunities to properly understand Maple, and eventually the few remaining gaps were filled in by the Programming Guide. This is a complex document, similar in length to the Fortran Language Standard, but with more examples. Personally I would only recommend it to readers with experience of programming language specifications. Students now started to ask how I came to know so much about Maple, and whether there was a book that would teach them the same. Since no such book existed, I decided to write one myself. As the old adage goes, if you want something doing properly, do it yourself. The project soon began to evolve as I tried to set down everything that the majority of Maple users need to know. I’ve always hated books that skirt around important but difficult topics, so where before I might have used a dirty trick to circumnavigate a problem, now I felt compelled to research exactly what was going on, and to try to explain it in a simple, concise way. When the first draft was complete, I approached Cambridge University Press (CUP). The editor arranged for reviews by four anonymous referees**, and by Maplesoft’s own programming team. This led to several major improvements. My colleague, Dr Martyn Hughes, also deserves a mention for his efforts in reading and commenting on four different drafts. Meanwhile, Maplesoft continued to release new editions of their software, and the drafts had to be revised to keep up with these. The cover was created by one of CUP’s designers, with instructions that it should not look too ‘treeish’ — one might be surprised by the number of books that have been written about Maple syrup, and it would be a shame for Understanding Maple to be mixed up with these by potential readers browsing the internet. Then there were the minor details: how wide should the pages be? What font should be used? Should disk be spelled with a ‘c’ or a ‘k’? Could quotes from other sources be used without the threat of legal action over copyright infringement? One rights holder laughably tried to charge $200 for a fragment of text from one of their books. Needless to say, no greenbacks were forthcoming.

The resulting book is concise, with all the key concepts needed to gain an understanding of Maple, alongside numerous examples, packed into a mere 228 pages. It gives new users a solid introduction, and doesn’t avoid difficult topics. It isn’t perfect (in fact I have already started to list revisions that will be made if a second edition is published in the future) but I’ve seen very few problems that can’t be solved with the material it contains. Only time will tell if Understanding Maple will it create new experts. At the very least, I would certainly like to think it will make Maple far easier to grasp, and help new users to avoid some of the traps that caught me out many years ago.

Find out more about Understanding Maple and order your copy today

*One can always identify an expert LATEX user by the fact that they know enough to realise that they are not a ‘real’ expert.

**Actually not wholly anonymous; the name of the referee who made the most suggestions for improvements was left in one of the documents sent to me by CUP, so a grateful mention can be made here of Michael Monagan, one of the original creators of Maple.