Quotes
Thu, Feb 22, 2001; by Ehud Lamm.
This page is dedicated to quotes that I think are worth discussing. I want to keep them seperate from any discussion held on this site, so that others (and myself) can use them for teaching or other purposes.
It is best if all quotes here are linked back to their source, if that's not possible and the quotation is of value, this rule can be relaxed.
Contributions are welcome.
Assortment of short witticisms (local).
Syntactic sugar causes cancer of the semicolon, and other Alan J. Perlis epigrams
The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities. -- Edsger Dijkstra, How do we tell truths that might hurt?
APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums. -- Edsger Dijkstra, How do we tell truths that might hurt?
About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead. -- Edsger Dijkstra, How do we tell truths that might hurt?
Projects promoting programming in "natural language" are intrinsically doomed to fail. -- Edsger Dijkstra, How do we tell truths that might hurt?
I have reaffirmed a long-standing and strongly held view:
Language comparisons are rarely meaningful and even less often fair. A good comparison of major programming languages requires more effort than most people are willing to spend, experience in a wide range of application areas, a rigid maintenance of a detached and impartial point of view, and a sense of fairness. -- Bjarne Stroustrup, The Design and Evolution of C++
...there is no agreement on what a programming
language really is and what its main purpose is supposed to be. Is a programming language a tool for instructing machines? A means of communicating between programmers? A vehicle for expressing high-level designs? A notation for algorithms? A way of expressing relationships between concepts? A tool for experimentation? A means of controlling computerized devices? My view is that a general-purpose programming language must be all of those to serve its diverse set of users. The only thing a language cannot be and survive is a mere collection of neat features. -- Bjarne Stroustrup, The Design and Evolution of C++
It is my firm belief that all successful languages
are grown and not merely designed from first principles. -- Bjarne Stroustrup, The Design and Evolution of C++
I think that any language that aspires to mainstream use must provide a broad base for a variety of techniques -- including object-oriented programming (class hierarchies) and generic programming (parameterized types and algorithms). In particular, it must provide good facilities for composing programs out of separate parts (possibly writing in several different languages). I also think that exceptions are necessary for managing the complexity of error handling. A language that lacks such facilities forces its users to laboriously simulate them. -- Bjarne Stroustrup, LinuxWorld
LinuxWorld.com: What is your advice to designers of new programming languages?
Dennis Ritchie: At least for the people who send me mail about a new language that they're designing, the general advice is: do it to learn about how to write a compiler. Don't have any expectations that anyone will use it, unless you hook up with some sort of organization in a position to push it hard. It's a lottery, and some can buy a lot of the tickets. There are plenty of beautiful languages (more beautiful than C) that didn't catch on. But someone does win the lottery, and doing a language at least teaches you something. -- Dennis Ritchie, LinuxWorld
What doesn't exist are really powerful general forms of arguing with computers right now. So we have to have special orders coming in on special cases and then think up ways to do it. Some of these are generalizable and eventually you will get an actual engineering discipline. -- Alan Kay, Educom Review
We have also obtained a glimpse of another crucial idea about languages and program design. This is the approach of stratified design, the notion that a complex system should be structured as a sequence of levels that are described using a sequence of languages. Each level is constructed by combining parts that are regarded as primitive at that level, and the parts constructed at each level are used as primitives at the next level. The language used at each level of a stratified design has primitives, means of combination, and means of abstraction appropriate to that level of detail. -- Abelson & Sussman, SICP (section 2.2.4)
All I can really say by way of a reasonably short comment is that inheritance is a very flexible mechanism. It's possible and in fact fairly common to misuse it, but that's not a reason to distrust it systematically as seems to have become the fashion. -- Bertrand Meyer, ITWorld.com
One problem I have with a good deal of the literature is that it is based on a view of inheritance strongly or even solely determined by knowledge of the mechanisms of C++ and Java. I think that to understand the scope of inheritance one must look beyond these two languages, which are each the products of a specific time, a specific frame of mind, a specific market, and a specific frame of mind. One should learn from them but not be restricted by their view of the world. -- Bertrand Meyer, ITWorld.com
Don't you hate code that's not properly indented? Making it part of the syntax guarantees that all code is properly indented! -- Guido van Rossum, Slashdot
In a sense, the whole history of new programming languages and class libraries for Windows has involved the struggle to reduce the windows hello-world program down to something small, sleek, and elegant. -- Petzold, Programming Microsoft Windows with C#, Microsoft Press, 2002, p. 47
The next big programming language will be slower than what it replaces. -- Todd Proebsting, Disruptive Programming Language Technologies
Whereas some declerative programmers only pay lip service to equational reasoning, users of functional languages exploit them every time they run a compiler, whether they notice it or not. -- Philip Wadler, How to declare an imperative
Another line of development stemming from Algol 60 has led to languages such as Pascal and its descendants, e.g. Euclid, Mesa, and Ada, which are significantly lowerlevel than Algol. Each of these languages seriously restricts the block or procedure mechanism of Algol by eliminating features such as call by name, dynamic arrays, or procedure parameters. -- John C. Reynolds.
The Essence of Algol. In Jaco W. de Bakker and J. C. van Vliet, editors, Algorithmic Languages, pages 345-372, Amsterdam, 1981. North-Holland.
In the programming-language world, one rule of survival is simple: dance or die. It is not enough
to make a beautiful language. You must also make it easy for programs written in your beautiful
language to interact with programs written in other languages. --Simon Peyton Jones. Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell. Presented at the 2000 Marktoberdorf Summer School. In "Engineering theories of software construction", ed Tony Hoare, Manfred Broy, Ralf Steinbruggen, IOS Press, ISBN 1 58603 1724, 2001, pp47-96.
There is a race between the increasing complexity of the systems we build and our ability to develop intellectual tools for understanding that complexity. If the race is won by our tools, then systems will eventually become easier to use and more reliable. If not, they will continue to become harder to use and less reliable for all but a relatively small set of common tasks. Given how hard thinking is, if those intellectual tools are to succeed, they will have to substitute calculation for thought. -- Leslie Lamport.
There are many ways of trying to understand programs. People often rely too much on one way, which is called ``debugging'' and consists of running a partly-understood program to see if it does what you expected. Another way, which ML advocates, is to install some means of understanding in the very programs themselves. -- Robin Milner, Foreword to The Little MLer.
let me re-assert that the question of whether there are limitations in principle of what problems man can make machines solve for him as compared to his own ability to solve problems, really is a technical question in recursive function theory. -- J. McCarthy, Towards a Mathematical Science of Computation .
Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late
binding in all aspects. -- Alan Kay, Is Software Engineering and Oxymoron? In the Croquet User Manual.
|
