 |
|
Professor
Office: Athabasca Hall 308
Phone: 780 492 5290
Fax: 780 492 1071
hoover@cs.ualberta.ca http://www.cs.ualberta.ca/~hoover
|
H. James Hoover Professor Office: Athabasca Hall 308 Phone: 780 492 5290 Fax: 780 492 1071 hoover@cs.ualberta.ca http://www.cs.ualberta.ca/~hoover |
| Technology, like music, is enriched by variety. |
| Henry Petroski in Small Things Considered: Why there is no perfect design, p 192. |
| The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry... |
| Henry Petroski |
| A program is similar to a musical score. A musical score is not simply a bunch of squiggles on the page. It is a description, in a special language, that describes a process for generating music. Composers don't write music, they write instructions for generating music. Those instructions then need to be interpreted by a performer who understand the language. Music scores are static descriptions of a dynamic process. The mark of an expert musician is that they can look at a score and hear the music without actually having to perform it. The same is true for an expert programmer. Now here's the big difference between a program and a musical score. In a musical score the instructions tell the performer what state the music is in at any instant of time. The opening of the score for Beethoven's 5th says to play G three times followed by E. You can open a score at any point and know immediately what the music sounds like at that point. A musical score is a sequence of states that the music is in. The meaning of the score is out in the open for all to see. A program doesn't describe the sequence of states. It describes the sequence of transitions that are made between states. A program is a set of instructions of how to change the current state into the next state. It's as if the opening of Beethoven's 5th was described as follows: "Start at G. Play a note. Play a note. Play a note. Go down a minor third (3 semi-tones). Play a note." You would not be able to simply look at the score and see or hear what the music sounds like mid-piece. In a program, the meaning is all between the lines! |
| H. James Hoover, Freshman Introduction to the Foundations of Computing, 2006 |
| Computer architecture, like other architecture, is the art of determining the needs of the user of a structure and then designing to meet those needs as effectively as possible within economic and technological constraints. Architecture must include engineering considerations, so that design will be economical and feasible; but the emphasis in architecture is upon the needs of the user, whereas in engineering the emphasis is upon the needs of the fabricator. |
| Fred P. Brooks, Jr., Architectural Philosophy, W. Buchholz, Ed. Planning a Computer System. McGraw-Hill, 1962 |
| To be a programmer is to develop a carefully managed relationship with error. There's no getting around it. You either make your accommodations with failure, or the work will become intolerable. |
| Ellen Ullman, The Myth of Order, Wired, April 1999 |
| In trying to understand the Linux phenomenon, then, we have to look not at a single innovator but to a sort of bizarre Trinity: Linus Torvalds, Richard Stallman, and Bill Gates. Take away any of these three and Linux would not exist. |
| Neal Stephenson, In the Beginning was the Command Line, Cryptonomicon, 1999 http://www.cryptonomicon.com/beginning.html |
| H. Aspirateur De James |
| Translation of my name from English into French courtesy of AltaVista and Systran. See, you have to live with the odd error. |
| Dilbert's Project Uncertaintly Principle: If you understand a project, you won't know its cost, and vice versa. |
| My Erdös number is 2. |
| You can have efficiency or robustness but not both. Most organizations have neither. |
| H. James Hoover |
| "What we find difficult about mathematics is the formal, symbolic presentation of the subject by pedagogues with a taste for dogma, sadism and incomprehensible squiggles." |
| J. E. Gordon, Structures or Why Things Don't Fall Down, p29, Penguin Books, 1978. |
| The proponents of UML have it wrong. Diagrams are more inconsistent and ambiguous in other disciplines than the UML acolytes would have you believe. You need only visit a construction site to see that! Diagrams cannot replace text for complex objects. There is no circuit diagram for a modern processor. At best the diagrams are a road map to the thousands of equations that specify the circuit. Diagrams have their place, don't make them do more than they are useful for. |
| H. James Hoover |
| Of all the misguided scientific endeavours, none are more pathetic than the search for the philosophers' stone, a substance supposed to change base metals into gold. The supreme object of alchemy, ardently pursued by generations of researchers generously funded by secular and spiritual rulers, is an undiluted extract of wishful thinking, of the common assumption that things are as we would like them to be. It is a very human belief. It takes a lot of effort to accept the existence of insolvable problems. The wish to see a way out, against all odds, even when it is proven that it does not exist, is very, very strong. And most of us have a lot of sympathy for these courageous souls who try to achieve the impossible. And so it continues. Dissertations on squaring a circle are being written. Lotions to restore lost hair are concocted and sell well. Methods to improve software productivity are hatched and sell very well. All too often we are inclined to follow our own optimism (or exploit the optimistic hopes of our sponsors). All too often we are willing to disregard the voice of reason and heed the siren calls of panacea pushers. |
| W. M. Turski, "And no philosophers' stone, either", in Information Processing 86, H. J. Kugler, ed. Elsevier Science (North Holland), 1986, pp. 1077-1080. |
| System debugging, like astronomy, has always been done chiefly at night. |
| Frederick P. Brooks, Jr. The mythical man-month, 20th anniversary edition. Addison Wesley, 1995, pg 244. |
| "A doctor can always bury his mistakes. An architect can only advise his client to plant ivy." |
| Frank Lloyd Wright |
| In academia, in industry, and in the commercial world, there is a widespread belief that computing science as such has been all but completed and that, consequently, computing has matured from a theoretical topic for the scientists to a practical issue for the engineers, the managers, and the entrepreneurs. [...] I would therefore like to posit that computing's central challenge, "How not to make a mess of it," has not been met. On the contrary, most of our systems are much more complicated than can be considered healthy, and are too messy and chaotic to be used in comfort and confidence. The average customer of the computing industry has been served so poorly that he expects his system to crash all the time, and we witness a massive worldwide distribution of bug-ridden software for which we should be deeply ashamed. For us scientists it is very tempting to blame the lack of education of the average engineer, the shortsightedness of the managers, and the malice of the entrepreneurs for this sorry state of affairs, but that won't do. You see, while we all know that unmastered complexity is at the root of the misery, we do not know what degree of simplicity can be obtained, nor to what extent the intrinsic complexity of the whole design has to show up in the interfaces. We simply do not know yet the limits of disentanglement. We do not know yet whether intrinsic intricacy can be distinguished from accidental intricacy. To put it bluntly, we simply do not know yet what we should be talking about, ... The moral is that whether computing science is finished will primarily depend on our courage and our imagination. |
| Edsger W. Dijkstra, Communications of the ACM, Mar 2001, Vol. 44, No. 3 |
|
|
