On the subject of art and programming, I really like how Fred Brooks described it in "The Mythical Man-Month":<p><i>The delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of imagination. Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself.</i><p>I wrote more on this subject in "Why I Love Coding" <a href="http://henrikwarne.com/2012/06/02/why-i-love-coding/" rel="nofollow">http://henrikwarne.com/2012/06/02/why-i-love-coding/</a>
Programming is much more of a craft than it is either an art or a science. Good craftsmanship combines beauty with utility, as does good coding.<p>Programmers work with abstractions, rather than with wood or clay. And their craft is as cerebral and intellectually demanding as an art or a science. But it's still a craft.
Great read. Indeed programming is not a 'gentle art', I would say it's a 'brutal art'.<p>There was an article outlining a continuum between art and science, where engineering was somewhere in the middle. Art is the least rigorous of them, while science has the most rigor.<p>Being a science enthusiast, reading on quantum physics, evolutionary biology, etc., I've learned more/less how scientists think. It has a lot to do with coming up with not only good explanations, but explanations that are extremely hard to vary. Explanations that risk falling apart if you try to change any aspect of it. This together with a mountain of evidence supporting said explanation, makes for good science.<p>Art on the other hand, is arguably vague by definition. Art that is doesn't leave room for interpretation is often bland. Art also has a huge human component, whereas science tries to do away with it.<p>In my opinion, programming can easily be both an art and a science. There's no need to constrain it to either one. On one hand, you have the mathematical theory of information, describing a hard-to-vary explanation that is backed up with great math(s). On the other, you have an infinite set of tools from which you can craft whatever your imagination is capable of coming up with. Programming, having its foundations in mathematics, leverages its infinite potential, and with it the possibility of creating both works of art, and scientific facts. It is this universe of possibility that takes only the toughest of minds to venture and explore.
Art can occur when the same person is both the source of the requirements for the program, and the implementor of the program. Much of the art is in the coming up with the specification: that is the concept in the art. The concept can be skillfully rendered into code. Concept + skillful rendering = art.
" The moral of this story, it seems to me, is that we should make use of the idea of limited resources in our own education. We can all benefit by doing occasional "toy" programs, when artificial restrictions are set up, so that we are forced to push our abilities to the limit. We shouldn't live in the lap of luxury all the time, since that tends to make us lethargic."<p>I love the way Knuth expresses himself.
I take for Science the natural and social sciences (see Wikipedia article on Science). In other words, Physics and all its sub divisions. In this respect, programming is not a science. CS is mostly a sub division of Math (also, not a science). Programming is a mix of engineering (that is finding an optimal solution given a set of known tools to a non-universal problem) and art - anything that allows for creativity in the forming of a finalized product. Most engineering disciplines have an aspect of art in them, but programming is perhaps the most artful thanks to the incredibly wide range of close-to-optimal solutions. But programming is also one more thing: a social process, the process of organising people and their work (which is neither science, nor math, nor art).
I'm only 3 months into coding but I've already heard about Knuth's books. This is a great intro to his writing, I'd like to read more.
Why is it that "it's more art than science" gets so much use, whereas "it's more science than art" is never used? We use the former to explain why a given process is not deterministic -- for example, appraising artwork, drafting a business plan. Why is it never necessary to explain that a process is deterministic?
Love this part, "In fact, when I first picked up a dictionary in order to study the words "art" and "science," I happened to glance at the editor's preface, which began by saying, "The making of a dictionary is both a science and an art.""
Knuth has a very abstract and fuzzy definition of "Art." Personally I feel "art" possesses a more concrete definition.<p>When 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.<p>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.<p>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.<p>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.<p>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?<p>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.<p>Here, where it is very hard for us to deduce the most efficient solution we rely on Art.<p>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.<p>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.<p>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.<p>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.<p>I see this as a good thing. Art is fun.
I've always felt writing working software was like creating art. I am pleased when something works and does something interesting after a long effort.
> 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."<p>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.
I start having a real tough time with this "code as art" argument when "code" becomes little more than gluing some Rails bullshit together.
"A knowledge of the Science of Number is of minor importance; skill in the Art of Reckoning is absolutely indispensible."<p>I laughed out loud at that.
I lived the day to see YC giving credit to PG for an article written by Knuth.<p>What's next? Symphony No. 9 by Paul Graham? Theory of Relativity by Paul Graham? The Bible? :-)
"How did they develop their skill? The best film makers through the years usually seem to have learned their art in comparatively primitive circumstances, often in other countries with a limited movie industry. And in recent years the most important things we have been learning about programming seem to have originated with people who did not have access to very large computers. The moral of this story, it seems to me, is that we should make use of the idea of limited resources in our own education. We can all benefit by doing occasional "toy" programs, when artificial restrictions are set up, so that we are forced to push our abilities to the limit. We shouldn't live in the lap of luxury all the time, since that tends to make us lethargic. The art of tackling miniproblems with all our energy will sharpen our talents for the real problems, and the experience will help us to get more pleasure from our accomplishments on less restricted equipment."<p>So true. Robert Rodriguez filmed El Mariachi with almost no resources. It's why the demoscene produced - and still produces - such amazing creations within its self-imposed strict limits. It's one of the reasons why the Raspberry Pi is so popular and why you see the most beautiful ARM assembly on the Gameboy.<p>And conversely I think it's why Web development is collapsing under the weight of too many shiny things. It's lethargic and living in the lap of luxury. I watched a video the other day of AirBNB talking about the evolution of its Web site. The 2008 version was fine: Rails, a database and dynamic page output. The 2015 version was insane: Rails, React, Node, all sorts of dependencies, some stuff I'd never heard of but that the speaker assured was good, complex mobile optimization when you could instead, you know, just write lean and mean mobile-friendly HTML.<p>Limit yourself instead and see what happens - the results might just be awesome.
If we define an art as strive to reach an aesthetic global optimum, by balancing form and meaning (syntax and semantics, if you wish, design and implementation) with attention to every single detail, then [some] programming is an art without a slightest doubt.
"According to most dictionaries "science" means knowledge that has been logically arranged and systematized in the form of general "laws.""<p>Ahh yes, the logical arrangement.<p><pre><code> Programming Law #1: Thou shalt tab to indent.
Programming Law #2: Nested loops shall indent deeper to the right.
</code></pre>
How about the six laws of depth in art?<p><pre><code> 1. Perspective - 2-point, 3-point...
2. Lower on canvas is closer, higher is further away
3. Atmosphere - clearer is closer, blur is further
3b. Color intensity - higher saturation is closer
4. Chiaroscuro - the next alternation is further (combination of #2 and #5)
5. Overlap - this behind that
6. Scale - bigger is closer
</code></pre>
Art has plenty of laws, some very complex, but you won't find them in Google. You have to find the artists' artist and mix her color 5000 times, like roll-on-your-head Shaolin Temple skull-hardening. Return to the 36th Chamber and draw with charcoal attached to the end of a long stick of bamboo, then ring the bell, for another style has died.