Knuth: Computer Programming as an Art (1974)
paulgraham.com
Knuth: Computer Programming as an Art (1974)
1–10 of 110 posts
Re: Knuth: Computer Programming as an Art (1974)
#2Re: Knuth: Computer Programming as an Art (1974)
#3I believe the title should be "Knuth: Computer Programming as an Art"...
Re: Knuth: Computer Programming as an Art (1974)
#4Re: Knuth: Computer Programming as an Art (1974)
#5Re: Knuth: Computer Programming as an Art (1974)
#6I believe the title should be "Knuth: Computer Programming as an Art"...
Submitters: please use the original title except when it is misleading or linkbait. This is in the HN guidelines: https://news.ycombinator.com/newsguidelines.html
Re: Knuth: Computer Programming as an Art (1974)
#7Re: Knuth: Computer Programming as an Art (1974)
#8Well not only that but we actually stuffed two misnomers in there. It is not really a science, and it is not really about computers. Chip design, graphics, storage, input devices is more about computers as such.
Re: Knuth: Computer Programming as an Art (1974)
#9> Meanwhile we have actually succeeded in making our discipline a science, and in a remarkably simple way: merely by deciding to call it "computer science." Well not only that but we actually stuffed two misnomers in there. It is not really a science, and it is not really about computers. Chip design, graphics, storage, input devices is more about computers as such.
Re: Knuth: Computer Programming as an Art (1974)
#10When the most efficient solution to a problem isn't known we rely on art and design to fill the void. When the path to the most efficient solution of a problem is known we rely on "science" or technical procedures to deduce the best possible answer.
For many problems in programming we know the best possible solution. However, for most of the apps we build to solve problems in the name of entrepreneurship or business, no efficient solution is known. In fact, in these situations, the problem isn't even clearly defined. When we don't know the "best" solution we use intuition and creativity to come up with a solution that we only intuitively know to be somewhat efficient.
Programming isn't the only area where this occurs. All of engineering relies on art and design to solve problems where the most efficient solution isn't known.
For example, what is the shortest distance between point A and point B? The answer is a straight line. There is no design or art as part of this solution because a straight line is mathematically proven to be the most efficient possible answer. The answer, in essence, was calculated and thus no "art" or design was involved. Utilizing art in this case would be as pointless as drawing an artsy squiggly line between point a and point b.
Now, allow me to modify the problem to make it a little more complex. Instead of calculating the shortest path between two points, how do I find the most efficient way to transport a person from point A to point B?
The most efficient answer is mind boggling complex, you have to account for the personalities and definitions of "efficient" for every possible person you can transport, energy, speed, obstacles etc etc. There probably is a most efficient solution but know one knows it.
Here, where it is very hard for us to deduce the most efficient solution we rely on Art.
With "art" we can come up with multitudes of solutions to the problem on how to transport a person from point a to point b. Cars (thousands of different models), flying vehicles (thousands of different innovations as well) are two possible examples out of many forms of locomotion. The reason why there are so many models/solutions is because we can never concretely determine which "solution" was the most efficient.
This is what we mean when we use the word "Art" in the context of "The Art of Programming" or "The Art of combat." We are essentially describing a problem domain space that is so complex our pathetic human minds our reduced to a sort of aimless wandering (aka creativity) to come up with a solution that isn't even the most efficient one.
I use the word aimless because we iterate over our solutions endlessly in an endless quest to arrive at the best solution. The "quest" is essentially endless because our "path" is aimless. We will never ever create the most efficient OS or iphone app of all time because we don't even know what the hell that even means. Instead we are cursed to iterate endlessly over our programs creating version after version for all eternity.
The majority of problems in the real world rely on a bit of "art" to arrive at a solution. In fact, most of the problems where an "efficient" solution is known are just theoretical conjectures that only exist in an idealized virtual universe.
I see this as a good thing. Art is fun.