Software Engineering for Students A Programming Approach

396 Chapter 32 ■ Conclusion
may have written some time ago that is in some way similar to the new program. They
retrieve the listing and copy those parts that are useful. Another similar approach is to
use memories of old programs. Experienced developers build up Aladdin’s caves of
memories of the designs that they have created. The provision of catalogs of reusable
design patterns explicitly exploits this approach.
No review of approaches would be complete without a mention of hacking. As we
have seen, this term has two distinct meanings. One meaning describes the act of getting
admittance to a secure computer system in order to steal money or secrets or to
cause mayhem. The other meaning, used in this book, describes a style of programming.
Hacking means plunging into a solution to a problem without any design whatsoever.
A hacker takes the program specification and immediately starts to write down
programming language instructions. Probably the hacker will not even pause to write
them down – they will immediately start to key in instructions to the computer.
Hacking makes use of intuition, creativity and individuality. It dates from the early days
of programming, when programming was regarded as an individual creative act and
when there were no well-established design methods. Nowadays hacking is often
frowned upon as being unsystematic and undisciplined. So hacking is either famous or
notorious, depending on your point of view. One of the places where hacking still has
some credibility is in open source development (Chapter 25).
LISP programmers have long championed a design strategy which lies somewhere
between hacking and the disciplined approaches described in this book. Perhaps this is
because the application areas in which LISP is used (such as artificial intelligence, AI)
demand an exploratory approach in which programs may be written in order to try to
demonstrate a theoretical premise. Thus AI tries to solve “ill-formed problems” – it is
difficult to determine when (or if) we have solved such problems, because they are only
partially understood. Moreover, LISP programmers regularly embark on the design and
construction of programs they don’t know how to write. This kind of exploratory programming
clearly requires a great deal of help from the language and its programming
environment, and a flexibility in the way in which ideas can be expressed which is not
found in such languages as Java and C.
For example, in LISP you can use variables without declaring their type, or define
functions which can take arbitrary numbers of arguments. You can define and use functions
which call other functions that haven’t been written yet. You can edit, test and
debug a program incrementally even while the program is running. And, very importantly,
LISP blurs the distinction between program and data – which is the reason for
LISP’s much maligned bracketed syntax. It is this dynamic, rather than static, approach
to program construction which enables and supports exploratory programming. Erik
Sandewall has described this method of program development as structured growth:
“An initial program with a pure and simple structure is written, tested, and then
allowed to grow by increasing the ambition of its modules. The growth can occur both
horizontally, through the addition of more facilities, and vertically through a deepening
of existing facilities”. Sandewall argues against the view that this could be considered
as hacking under another name, on the grounds that “even if some kinds of
program changes are dangerous and/or bad, that does not prove that all of them are”.