Difference between revisions of "Programming/Quotes"

From Thalesians Wiki
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Kent Beck=
<blockquote>
I'm not a great programmer; I'm just a good programmer with great habits.
</blockquote>
<p style="text-align:right;">&mdash;Kent Beck.</p>
<blockquote>
Write tests until fear is transformed into boredom.
</blockquote>
<p style="text-align:right;">&mdash;Kent Beck. ''Test Driven Development: By Example.''</p>
<blockquote>
Brilliance in a scientist does not consist in being right more often but in being wrong about more interesting topics.
</blockquote>
<p style="text-align:right;">&mdash;Kent Beck.</p>
<blockquote>
Given the choice between an extremely skilled loner and a competent-but-social programmer, XP teams consistently choose the more social candidate. The best interviewing technique is to have the candidate work with the team for a day. Pair programming provides an excellent test of technical and social skills.
</blockquote>
<p style="text-align:right;">&mdash;Kent Beck. ''Extreme Programming Explained: Embrace Change.''</p>
<blockquote>
Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.
</blockquote>
<p style="text-align:right;">&mdash;Kent Beck. ''Extreme Programming Explained: Embrace Change.''</p>
<blockquote>
No matter the circumstance you can always improve. You can always start improving with yourself. You can always start improving today.
</blockquote>
<p style="text-align:right;">&mdash;Kent Beck. ''Extreme Programming Explained: Embrace Change.''</p>
=Grady Booch=
<blockquote>
The task of the software development team is to engineer the illusion of simplicity.
</blockquote>
<p style="text-align:right;">&mdash;Grady Booch. ''Object-oriented Analysis and Design with Applications'', 2nd edition. Addison&ndash;Wesley, 1994.</p>
<blockquote>
Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer's intent but rather is full of crisp abstractions and straightforward lines of control.
</blockquote>
<p style="text-align:right;">&mdash;Grady Booch. Quoted in: Robert C. Martin. ''Clean Code: A Handbook of Agile Software Craftsmanship''. Prentice Hall (1 Aug. 2008).</p>
=Ward Cunningham=
<blockquote>
You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.
</blockquote>
<p style="text-align:right;">&mdash;Ward Cunningham. Quoted in: Robert C. Martin. ''Clean Code: A Handbook of Agile Software Craftsmanship''. Prentice Hall (1 Aug. 2008).</p>
=Emanuel Derman=
<blockquote>
...at AT&amp;T in 1980, the whole firm was embracing C, the simultaneously graceful and yet practical language invented by Dennis Ritchie about ten years earlier at Murray Hill. He had devised C to be a high-level tool with which to write portable versions of UNIX, the operating system also invented there by Ken Thompson and Ritchie. Now everything from telephone switching systems to word-processing software was being written in C, on UNIX, all with amazing style. Eventually, even physicists, who are generally interested only in the number of digits after a decimal point, began to forsake ugly utilitarian FORTRAN for poetically stylish C. Programming was in the late stages of a revolution about which I was just beginning to learn.
</blockquote>
<p style="text-align:right;">&mdash;Emanuel Derman. ''My Life as a Quant: Reflections on Physics and Finance.'' Wiley, 2007.</p>
<blockquote>
When you program well, you are trying to design a machine to perform a task. You design with a man-made programming language&mdash;FORTRAN, Lisp, C++ or Java, for example. Programming is not that different from instructing a friend to perform a task for you. The big difference is that the computer is much more literal than any friend, and so every detail of the task must be specified as though the computer knows nothing about the world.
Until I arrived at the AT&amp;T Bell Labs in 1980, I had never realized how elegant and challenging programming could be.
[...]
What are you doing when you program? You are trying to use a language to specify an imagined world and its details as accurately as possible. You are trying to create this world on a machine that can understand and execute only simple commands. You do this solely by writing precise instructions, often many hundreds of thousands of lines long. Your sequence of instructions must be executed without ambiguity, by an uncomprehending automaton, the computer, and yet, in parallel, must be read, comprehended, remembered and modified by you and other programmers. Just as poetry strives to resolve the tension between form and meaning, so programming must resolve the conflict between intelligibility and concision. In this endeavor, the language you employ is critically important.
</blockquote>
<p style="text-align:right;">&mdash;Emanuel Derman. ''My Life as a Quant: Reflections on Physics and Finance.'' Wiley, 2007.</p>
=Edsger&nbsp;W. Dijkstra=
<blockquote>
The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.
</blockquote>
<p style="text-align:right;">&mdash;Edsger&nbsp;W. Dijkstra. ''Notes on Structured Programming.'' Academic Press, 1972.</p>
=Martin Fowler=
<blockquote>
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
</blockquote>
<p style="text-align:right;">&mdash;Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p>
<blockquote>
Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.
</blockquote>
<p style="text-align:right;">&mdash;Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p>
<blockquote>
If you can get today's work done today, but you do it in such a way that you can't possibly get tomorrow's work done tomorrow, then you lose.
</blockquote>
<p style="text-align:right;">&mdash;Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p>
<blockquote>
A heuristic we follow is that whenever we feel the need to comment something, we write a method instead.
</blockquote>
<p style="text-align:right;">&mdash;Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p>
<blockquote>
When you find you have to add a feature to a program and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.
</blockquote>
<p style="text-align:right;">&mdash;Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p>
<blockquote>
Other than when you are very close to a deadline, however, you should not put off refactoring because you haven't got time. Experience with several projects has shown that a bout of refactoring results in increased productivity. Not having enough time usually is a sign that you need to do some refactoring.
</blockquote>
<p style="text-align:right;">&mdash;Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p>
<blockquote>
I've found that refactoring helps me write fast software. It slows the software in the short term while I'm refactoring, but it makes the software easier to tune during optimization. I end up well ahead.
</blockquote>
<p style="text-align:right;">&mdash;Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p>
<blockquote>
Life being what it is, you won't get your names right the first time. In this situation you may well be tempted to leave it&mdash;after all it's only a name. That is the work of the evil demon Obsfuscatis; don't listen to him. If you see a badly named method, it is imperative that you change it. Remember your code is for a human first and a computer second. Humans need good names.
</blockquote>
<p style="text-align:right;">&mdash;Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p>
<blockquote>
Most programmers, even experienced ones, are poor judges of how code actually performs.
</blockquote>
<p style="text-align:right;">&mdash;Martin Fowler. ''Refactoring: Improving the Design of Existing Code.''</p>
=Chris Heilmann=
<blockquote>
Java is to JavaScript what Car is to Carpet.
</blockquote>
<p style="text-align:right;">&mdash;Chris Heilmann.</p>
=Cory House=
<blockquote>
Code is like humor. When you ''have'' to explain it, it's bad.
</blockquote>
<p style="text-align:right;">&mdash;Cory House. ''Twitter'' (@housecor, Nov 13, 2013).</p>
=Donald Knuth=
=Donald Knuth=


Line 4: Line 141:
In this sense, we should continually be striving to transform ''every'' art into a science: in the process, we advance the art.
In this sense, we should continually be striving to transform ''every'' art into a science: in the process, we advance the art.
</blockquote>
</blockquote>
<p style="textalign:right">&mdash;Donald Knuth. 1974 Turing Aware Lecture. ''Communications of the ACM'' '''17''' (12), (December 1974), p. 668.</p>
<p style="text-align:right;">&mdash;Donald Knuth. 1974 Turing Aware Lecture. ''Communications of the ACM'' '''17''' (12), (December 1974), p. 668.</p>


<blockquote>
<blockquote>
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
</blockquote>
</blockquote>
<p style="textalign:right">&mdash;Donald Knuth. 1974 Turing Aware Lecture. ''Communications of the ACM'' '''17''' (12), (December 1974), p. 671.</p>
<p style="text-align:right;">&mdash;Donald Knuth. 1974 Turing Aware Lecture. ''Communications of the ACM'' '''17''' (12), (December 1974), p. 671.</p>


<blockquote>
<blockquote>
A good technical writer, trying not to be obvious about it, but says everything twice: formally and informally. Or maybe three times.
A good technical writer, trying not to be obvious about it, but says everything twice: formally and informally. Or maybe three times.
</blockquote>
</blockquote>
<p style="textalign:right">&mdash;Donald Knuth. Algorithms, Complexity, Life, and The Art of Computer Programming. ''AI Podcast'' (December 30, 2019).</p>
<p style="text-align:right;">&mdash;Donald Knuth. Algorithms, Complexity, Life, and The Art of Computer Programming. ''AI Podcast'' (December 30, 2019).</p>
 
=Peter Norton=
 
<blockquote>
Assembly language programming is an extravagant waste of not only human talent and should be avoided whenever possible.
</blockquote>
<p style="text-align:right;">Peter Norton. Quoted in "PC Languages: The Living and the Dead", ''PC Magazine'', September 1983, pp. 99&ndash;101</p>
 
=Antoine de Saint Exup&eacute;ry=
 
<blockquote>
Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.
</blockquote>
<blockquote>
It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.
</blockquote>
<p style="text-align:right;">&mdash;Antoine de Saint Exup&eacute;ry. ''Terre des Hommes'' (1939).</p>


=Bjarne Stroustrup=
=Bjarne Stroustrup=
<blockquote>
I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.
</blockquote>
<p style="text-align:right;">&mdash;Bjarne Stroustrup. Quoted in: Robert C. Martin. ''Clean Code: A Handbook of Agile Software Craftsmanship''. Prentice Hall (1 Aug. 2008).</p>


<blockquote>
<blockquote>
Within C++, there is a much smaller and cleaner language struggling to get out.
Within C++, there is a much smaller and cleaner language struggling to get out.
</blockquote>
</blockquote>
<p style="textalign:right">&mdash;Bjarne Stroustrup. ''The Design and Evolution of C++'', p. 207.</p>
<p style="text-align:right;">&mdash;Bjarne Stroustrup. ''The Design and Evolution of C++'', p. 207.</p>
 
=Arthur Whitney=
 
<blockquote>
Only short programs have any hope of being correct.
</blockquote>
<p style="text-align:right;">&mdash;Arthur Whitney.</p>

Latest revision as of 11:15, 17 July 2021

Kent Beck

I'm not a great programmer; I'm just a good programmer with great habits.

—Kent Beck.

Write tests until fear is transformed into boredom.

—Kent Beck. Test Driven Development: By Example.

Brilliance in a scientist does not consist in being right more often but in being wrong about more interesting topics.

—Kent Beck.

Given the choice between an extremely skilled loner and a competent-but-social programmer, XP teams consistently choose the more social candidate. The best interviewing technique is to have the candidate work with the team for a day. Pair programming provides an excellent test of technical and social skills.

—Kent Beck. Extreme Programming Explained: Embrace Change.

Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.

—Kent Beck. Extreme Programming Explained: Embrace Change.

No matter the circumstance you can always improve. You can always start improving with yourself. You can always start improving today.

—Kent Beck. Extreme Programming Explained: Embrace Change.

Grady Booch

The task of the software development team is to engineer the illusion of simplicity.

—Grady Booch. Object-oriented Analysis and Design with Applications, 2nd edition. Addison–Wesley, 1994.

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer's intent but rather is full of crisp abstractions and straightforward lines of control.

—Grady Booch. Quoted in: Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall (1 Aug. 2008).

Ward Cunningham

You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.

—Ward Cunningham. Quoted in: Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall (1 Aug. 2008).

Emanuel Derman

...at AT&T in 1980, the whole firm was embracing C, the simultaneously graceful and yet practical language invented by Dennis Ritchie about ten years earlier at Murray Hill. He had devised C to be a high-level tool with which to write portable versions of UNIX, the operating system also invented there by Ken Thompson and Ritchie. Now everything from telephone switching systems to word-processing software was being written in C, on UNIX, all with amazing style. Eventually, even physicists, who are generally interested only in the number of digits after a decimal point, began to forsake ugly utilitarian FORTRAN for poetically stylish C. Programming was in the late stages of a revolution about which I was just beginning to learn.

—Emanuel Derman. My Life as a Quant: Reflections on Physics and Finance. Wiley, 2007.

When you program well, you are trying to design a machine to perform a task. You design with a man-made programming language—FORTRAN, Lisp, C++ or Java, for example. Programming is not that different from instructing a friend to perform a task for you. The big difference is that the computer is much more literal than any friend, and so every detail of the task must be specified as though the computer knows nothing about the world.

Until I arrived at the AT&T Bell Labs in 1980, I had never realized how elegant and challenging programming could be.

[...]

What are you doing when you program? You are trying to use a language to specify an imagined world and its details as accurately as possible. You are trying to create this world on a machine that can understand and execute only simple commands. You do this solely by writing precise instructions, often many hundreds of thousands of lines long. Your sequence of instructions must be executed without ambiguity, by an uncomprehending automaton, the computer, and yet, in parallel, must be read, comprehended, remembered and modified by you and other programmers. Just as poetry strives to resolve the tension between form and meaning, so programming must resolve the conflict between intelligibility and concision. In this endeavor, the language you employ is critically important.

—Emanuel Derman. My Life as a Quant: Reflections on Physics and Finance. Wiley, 2007.

Edsger W. Dijkstra

The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.

—Edsger W. Dijkstra. Notes on Structured Programming. Academic Press, 1972.

Martin Fowler

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

—Martin Fowler. Refactoring: Improving the Design of Existing Code.

Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.

—Martin Fowler. Refactoring: Improving the Design of Existing Code.

If you can get today's work done today, but you do it in such a way that you can't possibly get tomorrow's work done tomorrow, then you lose.

—Martin Fowler. Refactoring: Improving the Design of Existing Code.

A heuristic we follow is that whenever we feel the need to comment something, we write a method instead.

—Martin Fowler. Refactoring: Improving the Design of Existing Code.

When you find you have to add a feature to a program and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.

—Martin Fowler. Refactoring: Improving the Design of Existing Code.

Other than when you are very close to a deadline, however, you should not put off refactoring because you haven't got time. Experience with several projects has shown that a bout of refactoring results in increased productivity. Not having enough time usually is a sign that you need to do some refactoring.

—Martin Fowler. Refactoring: Improving the Design of Existing Code.

I've found that refactoring helps me write fast software. It slows the software in the short term while I'm refactoring, but it makes the software easier to tune during optimization. I end up well ahead.

—Martin Fowler. Refactoring: Improving the Design of Existing Code.

Life being what it is, you won't get your names right the first time. In this situation you may well be tempted to leave it—after all it's only a name. That is the work of the evil demon Obsfuscatis; don't listen to him. If you see a badly named method, it is imperative that you change it. Remember your code is for a human first and a computer second. Humans need good names.

—Martin Fowler. Refactoring: Improving the Design of Existing Code.

Most programmers, even experienced ones, are poor judges of how code actually performs.

—Martin Fowler. Refactoring: Improving the Design of Existing Code.

Chris Heilmann

Java is to JavaScript what Car is to Carpet.

—Chris Heilmann.

Cory House

Code is like humor. When you have to explain it, it's bad.

—Cory House. Twitter (@housecor, Nov 13, 2013).

Donald Knuth

In this sense, we should continually be striving to transform every art into a science: in the process, we advance the art.

—Donald Knuth. 1974 Turing Aware Lecture. Communications of the ACM 17 (12), (December 1974), p. 668.

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

—Donald Knuth. 1974 Turing Aware Lecture. Communications of the ACM 17 (12), (December 1974), p. 671.

A good technical writer, trying not to be obvious about it, but says everything twice: formally and informally. Or maybe three times.

—Donald Knuth. Algorithms, Complexity, Life, and The Art of Computer Programming. AI Podcast (December 30, 2019).

Peter Norton

Assembly language programming is an extravagant waste of not only human talent and should be avoided whenever possible.

Peter Norton. Quoted in "PC Languages: The Living and the Dead", PC Magazine, September 1983, pp. 99–101

Antoine de Saint Exupéry

Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher.

It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.

—Antoine de Saint Exupéry. Terre des Hommes (1939).

Bjarne Stroustrup

I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.

—Bjarne Stroustrup. Quoted in: Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall (1 Aug. 2008).

Within C++, there is a much smaller and cleaner language struggling to get out.

—Bjarne Stroustrup. The Design and Evolution of C++, p. 207.

Arthur Whitney

Only short programs have any hope of being correct.

—Arthur Whitney.