The opening translation in March made me feel at a loss. When I saw the name, I felt it was very helpful for programming. Five famous programming quotes, as well as explanations, attracted my interest.
Next, read the first paragraph, the author selected quotes that are at least 20 years old, that must be timeless, classic Tips, great. After reading a few sub-headings and a cursory glance at the descriptions of key concerns, I became more interested.
But when I threw myself into translating, I screwed myself up. The whole translation, it’s a little long, and there’s a long sentence. However, this is not a problem, when you finish reading this article, I am sure you will strike a chord, as to what chord? Must be based on the resonance of your coding ability, with this curiosity, please have a good look.
My translation ability is limited, sometimes with the help of translation software, so the translation of the place, please understand, you can go to see the original, and I communicate more. A weekly translation, I stick to my insistence.
Original address: https://medium.com/young-coder/5-famous-programming-quotes-explained-4da607906c1
By Matthew MacDonald
5 famous programming quotes, explained
By understanding these timeless insights, you will become a better developer.
Being a good programmer is all about accepting yourself to a life of constant learning (live and learn). A great source of new features, new languages, new tools, new frameworks — never stop learning. But computer science is also a surprisingly traditional field, based on time-tested principles. We’ve added object orientation, modern hardware, and artificial intelligence. Yet, despite all the changes, many of the insights of a previous generation are still valid today (much like our modern aphorism).
In this article, I’ve dissected some of my favorite quotes from computer science. The only condition I set was that every good quote had to be at least 20 years old. Because ancient technologies quickly become useless, the ancient precepts of our programming ancestors have more staying power.
- About the Indirection
“All problems in computer science can be solved in another indirect way.” — David Wheeler
Here is a compSCI reference that is rarely explained by developers but is often reused. But this is one of my favorite programming truths because it gets to the heart of coding.
The easiest way to start thinking about Indirection is to imagine hierarchies. For example, suppose you have A small project that needs to put component A into component B:
Both are standard components, so you can’t break them and change how they work. You can build an entirely new component, but that requires a lot of work and unnecessary duplication. A better approach is to add a layer between the two parts — an adapter that fits both components and transforms between them. (This is the adapter pattern in design mode)
Now, it would be nice and useful if Indirection just added a new layer to combine incompatible parts. But the idea of building around a problem to solve it is a concept that extends from bottom to top. You see it when you try to adapt a new data model to an old user interface; You’ll see it when you try to install a legacy application on a new Web back-end server; You’ll see it when you need to bind higher-level features (like logging and caching) or coordinate higher-level services (like messaging and transactions); At the top of the pyramid, you’ll be exposed to a few topics like machine learning (when you can’t code the behavior you need, write another layer of code to help you figure it out).
Many people will tell you that programming is all about writing explicit instructions in a language that even a computer can understand. But David Wheeler’s famous quote reveals a better insight: good programming is climbing the ladder of abstraction to reach the most general solution.
Related quotes:
Indirection is powerful, but complexity comes at a price. Wheeler’s follow-up comment on indirection is rarely quoted:
But another problem often arises — David Wheeler
This truth has kept programmers in business ever since.
- About simple
Simplicity is a prerequisite for reliability. — Edsger Dijkstra
Many wise programmers warned us not to make our code too complex. But few have illustrated the cost of complexity more clearly than Edsger Dijkstra, a Dutch computer science pioneer.
The takeaway here: You don’t choose simplicity as a gift to the future. You don’t do it because you’re looking forward to the opportunity to reuse your code, or because you want to make it look cleaner during code reviews, or because you want to make it easier to modify (although all of those benefits are valuable!). . You do this because simplicity is a prerequisite. Without simplicity, you will never have reliable code you can rely on to conduct your business or process your data.
To accept Dijkstra’s argument, we need to redefine what “good code” means. Not the shortest code. It’s not necessarily the fastest code. Definitely not the smartest code. Code that can be trusted.
Related quotes:
One of the best ways to keep your code simple is to remember that less is more. Dijkstra provides a metric to help us keep this in mind:
“If we want to count lines of code, we should think of them not as’ generated lines, ‘but as’ spent lines.'” — Edsger Dijkstra
- About readability and rewriting
“Reading code is harder than writing code.” — Joel Spolsky
At first glance, this quote from software legend and StackOverflow co-founder Joel Spolsky seems correct, but it seems superficial. Yes, the code can be dense, short and verbose. It’s not just someone else’s code. If you look at work from a year ago, you might need some time to sort out the logic you once knew so well.
But Mr Spolsky’s insight is different. The danger of code that you can’t read isn’t just obvious (it’s hard to change and improve). Instead, the bigger danger is that complex code seems worse than it really is. In fact, it’s so good to try to understand what someone else has already written that you might be tempted to make what Spolsky calls the worst mistake of all — deciding to rewrite the code from scratch.
This is not to say that rewriting cannot improve the architecture of the system. They absolutely can. But these improvements have come at a huge cost. They reset test and debug errors for a fixed amount of time, both activities taking longer than pure coding. Rewriting is tempting because they are one of the most common biases in software development: we underestimate the effort to do things that are conceptually simple. That’s why the final 5% project takes 50% of the time. Simple things can be very time-consuming! There seems to be nothing easier than solving a problem you’ve already solved.
So, if you shouldn’t rewrite everything to make it perfect, what’s a better solution? The answer is to have every developer participate in constant size refactoring. This provides you with small, continuous code improvements – truly rewarding and with little risk. You can improve readability as you code.
Related quotes:
If you’re still unsure about the importance of readability, Martin Fowler can help you solve the problem from a perspective:
“Anyone can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler
In other words, a programmer’s job is not just to write code, but to do things that make sense.
- About the repeat
“Don’t repeat yourself. Every piece of knowledge must have a single, unambiguous, authoritative representation in a system.” — Andy Hunt and Dave Thomas
Every self-respecting programmer knows that repetition is the root of all evil. If you’re writing the same thing in different places, you’re doing extra work, testing and debugging. Even worse, you are introducing inconsistencies – for example, if one part of the code has been updated and other similar code has not been updated synchronously. The program may cause your program to deviate, and your deviated program is no longer a viable solution.
But duplicate code isn’t the only place where it can wreak havoc. This version of the famous “Do not Repeat Yourself” (DRY) rule extends the no-repetition principle to cover other possible hidden contradictions. We’re not talking about code duplication anymore. We’re also talking about repetition in systems — the many different ways that systems have code knowledge. They include:
- The code statement
- Code comments
- Developer or customer documentation
- Data schema (for example, database tables)
- Other specifications, such as test plans, workflow documents, and build rules
All of these layers can overlap each other. And when they do, they are likely to introduce different versions of the same reality. For example, what if the documentation describes one way of working, but the application follows another way? Who owns the truth? What if the database tables don’t match the data model in your code? Or do comments describe the operation of the algorithm that is not consistent with how it is actually implemented? Every system needs a single, authoritative one, and everything else must be highly unified.
The truth about competing versions, by the way, is not just about problems in small-scale projects or poorly designed code. One of the best examples comes with the battle between XHTML and HTML5. One camp argues that the specification is an official fact and that browsers need to be corrected to comply with it. Another school claims that browser behavior is the de facto standard, because that’s what designers had in mind when they wrote web pages. In the end, the browser version of the truth won. In that sense, HTML5 browsers do just that — including shortcuts, the errors they allow and the errors they accept.
Related quotes:
The possibility that code and annotations contradict each other has led to a heated debate about whether annotations do more harm than good. Advocates of extreme programming are openly skeptical:
“Code never lies; Code comments sometimes do.” – Ron Jeffries
- About the problem
“There are only two things in computers: cache invalidation and naming things.” — Phil Karlton
At first glance, this line seems funny, but it’s common programming jokes. Something that sounds difficult (cache invalid) can be immediately associated with something that sounds easy (name things). Every programmer puts in hours of work to solve a ridiculously trivial problem, such as passing arguments in the wrong order or case-insensitive variables (thanks to JavaScript). As long as humans need to collaborate with machines to complete tasks, programming will become a mash-up of high-level systems planning and trivial typing errors.
But if you look again at Phil Karlton’s quote, there are more issues that need to be addressed. Naming things isn’t hard, because programmers’ lives are often ruined by small headaches. This is also because the naming problem is virtually every programmer’s most important concern: software design. In other words, how do you write clean, clean, consistent code?
There are many ways to get the error name. We’ve all seen data types named after variables (myString, obj), abbreviations (PC for product catalogs), trivial implementation details (swappable_name, formUserInput), and even nothing at all (ret_value, tempArray). It’s easy to fall into the trap of naming a variable based on what you’re using it for at the time, rather than what it contains. Booleans are particularly tricky – when progress marks the start of progress, does it indicate that you need to display progress information in the user interface, or flag something different entirely?
But variable names are just the beginning. Named classes raise the issue of how to divide code into separate parts. Naming a public member will affect how you work displaying an interface that allows one part of your application to interact with another. Locking these names not only describes what a piece of code can do, but also determines what it will do.
Related quotes:
“There are two things about computer science: cache invalidation, things naming, and one-to-one errors.” — Leon Bambrick
Like this list and want to improve your skills? Check out 5 Books that Can Help You Become a Better Programmer, which I’ll be translating next week.
conclusion
I’m glad you stuck with me until the end. Is there anything you want to change about your programming process? Simple lines, readability, the DRY principle, will stick in your mind, and finally the illusion that cache invalidation is hard and naming is easy.
The DRY principle, and the simplicity of naming, are two things I’m really impressed with. Because I maintain the program, there are really repeated operations of the code, change one place, forget to change another place, the result is often tested against; It makes me want to reconstruct the impulse, just a few days ago to solve this old problem. And naming. You can’t just look at it for months and not know what it means.
Finally, the author left a menu and 5 books to help you become a better programmer. The material for next week has been found. Will you make an appointment?
When your talent can not support your ambition, it should calm down to learn