Preface

The word ‘craft’ in the title of this book has been chosen deliberately. There have been books published with titles such as ‘The Art’ or ‘The Science’ of programming, but I feel that neither of these titles is really appropriate for a textbook like this. In Art, you have a blank canvas and are free to express yourself as the spirit moves you in order to produce Beauty; in Science, you are constrained by ‘the laws of physics’ to produce Truth. A craft, on the other hand, is less free than Art but less constrained than Science. Truth and Beauty are both involved in the process, but Art provides a blank canvas which is rarely found in real-life programming. There is almost always some previous system which has to be conformed to: an existing database or file format, or the peculiarities of a particular operating system. Science searches for Truth, but there is little truth in most programs; only fairly trivial programs are susceptible to correctness proofs at present. Most programs are unwieldy beasts, made like Frankenstein’s monster from leftover fragments of previous generations of programs, and neither Art nor Science takes account of this.

Craft skills are concerned with making the best out of available resources. If you are given some wood and asked to make a piece of furniture from it, you have to work within the confines of what that wood will allow. If the wood is knotty at a particular place, you may have to revise your initial plans in order to work around the knots, or you may have to discard some of the wood and find some more which matches the piece you’ve been given. Craftsmanship is concerned with the ability to work around problems like this. In programming, you are rarely presented with a clean sheet and invited to design the next world-beating program; you are usually presented with an existing program and a list of problems to be resolved. How you choose to solve those problems is a measure of your craftsmanship. The existing program will undoubtedly be full of ‘knots’ which you have to work around. A good craftsman will be able to produce an elegant result from a knotty problem. ‘Elegant’ is often treated as a synonym for ‘artistic’; I feel that the word ‘crafty’ is, in its original sense, a more accurate translation.

Craftsmanship depends on having a good set of tools to hand. In the realm of programming, the tools are techniques, algorithms, ways of doing things, ways of approaching particular types of problem, and of course programming languages which support those approaches. Object-oriented programming is the latest addition to the craftsman-programmer’s toolkit. It is not an ultimate solution in the Scientific sense of ensuring that programs which use it will be guaranteed to be correct; it is not an Artistic solution that frees you from the need to fit in with what already exists. It is a Crafty solution that allows you to design things in such a way that when they are broken you will be able to take them apart and fix them, and when they need extending you will be able to add on the extra features with a minimum of effort.

How this book is organised

Many programming textbooks that I’ve seen concentrate on teaching the features of a particular language, and use numerous small ‘blank canvas’ examples to illustrate those features. What seems to be ignored all too often are the real-life situations where the problems deal with an existing legacy of programs or data which must be maintained and modified in some way. What I’ve tried to do in this book is to concentrate on a relatively small number of examples which are capable of improvement and to refine them throughout the book. The result is that the order of topics is primarily example driven; new topics are introduced by adding extra ‘bells and whistles’ to existing examples. The examples start with the traditional ‘Hello world’ program and gradually get more and more elaborate, culminating in two reasonably sized examples: an electronic diary and a spreadsheet. Although these are only about a thousand lines of code each in their final versions, they nevertheless show the sort of maintenance problems that arise in ‘real world’ applications and illustrate how careful design can alleviate such problems.

The book is in three parts. The first part deals with the fundamentals of Ada programming: how to do input and output, how if statements and loops work, what procedures, functions and packages are all about, how to define your own data types, how to handle exceptions. At this stage the examples are necessarily tiny; although I deal with program design in chapter 3 when I reach the first example large enough that design merits a separate discussion, the next few chapters concentrate more on introducing the building blocks of Ada using variations on earlier examples. Instructors should of course continue to emphasise the design techniques I’ve introduced when students are expected to develop new programs as exercises. At the end of the first part, an electronic appointments diary provides a larger example which merits a chapter entirely devoted to design and debugging, although at this stage the design is deliberately na‹ve.

By the end of the first part, the reader will have been presented with two examples which will be carried further in the next two parts: an electronic appointments diary and a simple desk calculator. These next two parts concentrate on introducing maintenance problems and introducing new approaches and techniques for dealing with these problems. In my experience the real problems of programming only become apparent when you have to maintain an existing legacy of code, and you only learn to design programs so that they are capable of being maintained in the future when you yourself have been on the receiving end of maintenance problems.

The second part deals with abstract data types; it begins by taking the example from the end of the first part and proposing some possible maintenance scenarios. I use these as an excuse for revising the designs I’ve already proposed in the first part. The early chapters in the second part deal with improving the appointments diary from chapter 8, while the last chapter returns to the calculator example from the first part. Some new implementation techniques are introduced: linked lists, generics, opaque types and recursion are all investigated. The effort involved in dealing with the proposed maintenance scenarios should reveal what a mess poor programming practices can get you into, and should hopefully provide an incentive to master ways of designing programs so that this sort of effort will be minimised if you ever have to make maintenance changes to programs that you write.

The third and final part is concerned with using the object-oriented programming features of Ada 95 to develop extensible programs. The features of Ada described here provide the essential difference between Ada 83 and Ada 95. This part considers maintenance scenarios which affect not just the (re)implementation of existing features but also the capacity of the current design to accommodate new requirements. What happens when you want your existing appointments diary to cope with different types of appointment? What if at some future date you want to incorporate a new type of appointment into your existing systems? What if you want to extend your existing calculator to cope with the extra requirements of a spreadsheet? What if you want a spreadsheet that updates itself in real time? These are the sort of maintenance problems that arise most commonly in the real world; implementation is irrelevant to users, but the ability to add new features is crucial. And it is up to the craftsman-programmer to reach into his or her toolbox and to craft a solution with the tools available; the final part of this book shows how it’s possible.

In my opinion, the best way to learn any programming language is to use it to do something that interests you. I first learnt to program because I was interested in John Conway’s ‘Game of Life’ which was popular in the early 1970s, and I wanted something that would let me find out the eventual fate of the R-pentomino. I never succeeded in this because I got sidetracked into programming as an end in itself! Electronic diaries and spreadsheets should be familiar enough applications to all readers, and I hope that this will make them reasonably interesting. They’re large enough to be challenging, but not so large as to require a book twice the size of this one. Adopting a project of a similar size (e.g. a text editor) and working on it in parallel with studying this book is the best way I can think of to become a good Ada programmer. Consider the traps and pitfalls I introduce in my examples and think about similar traps and pitfalls that might befall you in your own programs. Practice makes perfect, after all.

Who this book is for

I’ve aimed this book squarely at the beginning programmer learning Ada 95 as a first language, mainly because Ada is becoming one of the most popular languages used in introductory programming courses. I teach one of these myself. If you’re an experienced programmer you might find the going a bit slow in the first couple of chapters, but Ada is sufficiently different from most other languages that it’s worth reading these chapters anyway just in case you miss something important. If you’re an experienced programmer it won’t take you long to get through them. At the end of the book there is also a glossary and a set of appendices for reference; the final version of the packages developed in the text is also included as Appendix D. You can get the full set of examples from the website for this book (http://www.it.brighton.ac.uk/staff/je/adacraft/) or by anonymous FTP from ftp://ftp.brighton.ac.uk/pub/je/adacraft. They’ve been tested using the GNAT compiler, which is also freely available by anonymous FTP from New York University (see chapter 20 for details).

Since I’m assuming that the average reader has no previous Ada experience, I’ve completely ignored Ada 83. Mentioning Ada 83 in a book for someone with no prior knowledge who wants to learn Ada 95 would just be confusing. This leaves readers who are experienced Ada 83 programmers in a delicate position; the temptation will be to say `oh yeah, I know this stuff!’ and to skip to the next chapter. If you’re in this situation, be warned that there are lots of new things in Ada 95 that weren’t in Ada 83. I’ve included a summary of the syntax of Ada as Appendix A which also includes references to the chapters where each feature of the language is covered; readers with a knowledge of Ada 83 can use this to locate information about new features of Ada 95. However, you may well find that by skipping chapters to get to the ‘interesting’ bits you will miss the descriptions of some of the underlying features, in which case you’ll have to go back for another look at the bits you skipped over the first time. Also, since the examples are built up a little bit at a time, you’ll sometimes find you need to go back a few chapters to look at the early stages of the examples.

Ada is a big language. I can’t make any claims that this book provides a complete coverage of the language; the closest you’ll get to a complete coverage is the Annotated Reference Manual. I can, however, guarantee that this book is easier to read than the Annotated Reference Manual! The examples in this book have been carefully chosen to allow me to use them to introduce most of the features of Ada. The topics I’ve omitted are by and large minor details; the final chapter of the book tells you what I’ve left out and why, and it points you towards several different sources of information if you want to find out about the things I didn’t tell you. Despite the omissions, I hope you will find this an interesting, informative and enjoyable book.

— John English (email: je@brighton.ac.uk)
Brighton, October 1995

Contents

This file is part of Ada 95: The Craft of Object-Oriented Programming by John English.
Copyright © John English 2000. All rights reserved.
Permission is given to redistribute this work for non-profit educational use only, provided that all the constituent files are distributed without change.
$Revision: 1.2 $
$Date: 2001/11/17 12:00:00 $