- Home
- A-Z Publications
- First Break
- Previous Issues
- Volume 3, Issue 4, 1985
First Break - Volume 3, Issue 4, 1985
Volume 3, Issue 4, 1985
-
-
Computer science for geophysicists. Part VII: form and structure in programming
By L. HattonNow I, and hopefully you also, have recovered from the rigours of the last article on 'Comrnunications and Networks', I would like to depart a little from the format of the previous six articles and discuss a topic which is simultaneously far less tangible but, in my view, of far greater importance. The topic is software design as a discipline and its underlying structure. This article took rather longer to write than my enthusiasm for the subject would have suggested, partly because it is very long, partly because of the importance of the material and partly because I have spent much of my free time in the last three months designing a program package which detects (and abuses) naughty non-portable FORTRAN 77 (NAUGHTRAN 77). This in itself arose from a continuing interest I have in something known as software entropy, a brief discussion of which forms part of this article. This is not, as it may seem, my candidate for the most gratuitous usage of the word 'entropy' in a scientific journal, but a real phenomenon, the growth of which imbues undisciplined software development with the longevity of a chocolate tea pot. Even now as you read this, the entropy demons are nibbling away at your favourite program; you have been warned! I shall continue this discussion in both Papers X and XI where I will discuss software portability and some aspects of the theory of computation. I paraphrased the title of this artiele from a little book called The Form of Music by Cole (1969), one of a number which I had to digest a few years ago when the London College of Music was trying in vain to accommodate my ambitions to become a reasonable guitarist. (The worst part was sharing the waiting rooms before examinations with precocious 7-year-olds, who would emerge from a comic just long enough to perform a Bach Lute Suite with staggering virtuosity.) One of the many things which made a considerable impression on me was that something which I had previously considered 'a nice tune' was in fact a masterpiece of design and integration, built on several hundreds of years of accumulated experience. I hope to convince you in this artiele that good software is not just 'a nice tune', but is the result of a highly disciplined revolution which is quietly taking place in computer science and is not accomplished by the simple act of renaming your pet programmer a 'software engineer'. Most of the ideas presented here I have only become aware of since about 1980 through reading some of the works of Dijkstra, Hoare, Wirth and others and they have completely transformed my view of software development from the old semi-macho and essentially puerile 'let me get at the machine' syndrome to that of a highly structured branch of engineering and mathematics. Oddly enough, considering that scientists work with something as beautifully structured as nature, as a body they seem hopelessly unaware that the computer programs necessary to model nature should, indeed must, share the same form, elegance and symmetry; isomorphic rather than parodic. So what is structure? Taking recourse once again to the gargantuan Oxford English Dictionary, the description occupies almost a page of which I will extract 'An organised body or combination of mutually connected and dependent parts or elements'. The key word here of course, is 'organised'. Although the origin of this description is biological, I would define the difference between good and bad software as the above description with and without the word 'organised'. Taking a more controversial step, I would say that structure lies at the heart of all human creativity, principally because structure is essential to widespread understanding and therefore recognition that something is creative. Without structure we have no creativity and without creativity we have no growth; so how come the programming languages ADA and PL/1? For a thoroughly biased viewpoint, read on! I will attempt to approach structure in programming by discussing examples from two of many fields which I believe are intimately associated, those of architecture and music.
-
-
-
Seismic exploration over basalt covered areas in the U.K.
More LessIt is generally expected that the quality of seismic data will be poor in areas where basaltic lavas lie directly upon, or are close to, the surface. All but the major oil companies have avoided exploring such areas. A good example is Northern Ireland, where the surface geology is dominated by extensive Tertiary basaltic lavas. The first part of this article describes seismie surveys carried out by the Northern Ireland Department of Economic Development in 1981 and 1983 (Illing and Papworth 1985). The noise problems are then described with reference to noise tests in western Scotland as well as data from Northern Ireland, and finally some common factors applying to these and similar are as in Libya and Brazil are discussed.
-
Volumes & issues
-
Volume 42 (2024)
-
Volume 41 (2023)
-
Volume 40 (2022)
-
Volume 39 (2021)
-
Volume 38 (2020)
-
Volume 37 (2019)
-
Volume 36 (2018)
-
Volume 35 (2017)
-
Volume 34 (2016)
-
Volume 33 (2015)
-
Volume 32 (2014)
-
Volume 31 (2013)
-
Volume 30 (2012)
-
Volume 29 (2011)
-
Volume 28 (2010)
-
Volume 27 (2009)
-
Volume 26 (2008)
-
Volume 25 (2007)
-
Volume 24 (2006)
-
Volume 23 (2005)
-
Volume 22 (2004)
-
Volume 21 (2003)
-
Volume 20 (2002)
-
Volume 19 (2001)
-
Volume 18 (2000)
-
Volume 17 (1999)
-
Volume 16 (1998)
-
Volume 15 (1997)
-
Volume 14 (1996)
-
Volume 13 (1995)
-
Volume 12 (1994)
-
Volume 11 (1993)
-
Volume 10 (1992)
-
Volume 9 (1991)
-
Volume 8 (1990)
-
Volume 7 (1989)
-
Volume 6 (1988)
-
Volume 5 (1987)
-
Volume 4 (1986)
-
Volume 3 (1985)
-
Volume 2 (1984)
-
Volume 1 (1983)