Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
— Greenspun's Tenth Rule
— Greenspun's Tenth Rule
There are only two hard things in Computer Science: cache invalidation and naming things.
— Phil Karlton
— Phil Karlton
Цитаты о программировании
There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.
— Leon Bambrick
— Leon Bambrick
A language that doesn't affect the way you think about programming, is not worth knowing.
— Alan Perlis
— Alan Perlis
Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies.
— Matthias Felleisen
— Matthias Felleisen
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
— Brian Kernighan
— Brian Kernighan
Цитаты о программировании
Programming languages teach you not to want what they cannot provide. —Paul Graham, ANSI Common Lisp
Use the good features of a language; avoid the bad ones.
— Brian W. Kerninghan, Phillip J. Plauger, The Elements of Programming Style
— Brian W. Kerninghan, Phillip J. Plauger, The Elements of Programming Style
Experience is the mother of all science. This general truth is certainly valid for the art of programming. Only by experience and practice can one learn the innumerable tricks and dodges that are so useful and often essential in a good program.
— Gerard Bodifée, Astronomical Formulae for Calculators (предисловие)
— Gerard Bodifée, Astronomical Formulae for Calculators (предисловие)
There are 3 main time limits (which are determined by human perceptual abilities) to keep in mind when optimizing web and application performance.
[...]
- 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
- 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
- 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.
— Jakob Nielsen, Usability Engineering
[...]
- 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
- 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
- 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.
— Jakob Nielsen, Usability Engineering
Some people, when confronted with a problem, think, “I know, I’ll use threads,” and then two they hav erpoblesms.
— Ned Batchelder
— Ned Batchelder
I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already.
— SICP
— SICP
[...] This is what I call a leaky abstraction. TCP attempts to provide a complete abstraction of an underlying unreliable network, but sometimes, the network leaks through the abstraction and you feel the things that the abstraction can’t quite protect you from. This is but one example of what I’ve dubbed the Law of Leaky Abstractions:
All non-trivial abstractions, to some degree, are leaky.
Abstractions fail. Sometimes a little, sometimes a lot. There’s leakage. Things go wrong. It happens all over the place when you have abstractions.
— Joel Spolsky, The Law of Leaky Abstractions
All non-trivial abstractions, to some degree, are leaky.
Abstractions fail. Sometimes a little, sometimes a lot. There’s leakage. Things go wrong. It happens all over the place when you have abstractions.
— Joel Spolsky, The Law of Leaky Abstractions
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
— Tom Cargill, Bell Labs
— Tom Cargill, Bell Labs