Programming is maths! But communicating is art...

I tried to sum up the contents of this post (which will surely be long) in the title.

The discussion came up yesterday after the master's thesis presentation of a friend of mine (Daniel Cukier). His proposal was way too unconventional to pass easily. During the teachers' comments on his thesis, Prof. Valdemar Setzer pointed out that he disagrees on Daniel's sentence that said (from my memory that is brief and unprecise) "The art of programming ...".
Prof. Setzer says he disagrees with Knuth (and Daniel) on the fact that programming is an art.

"Programming is formalizing your ideas in order to make a computer execute them and, therefore, cannot be considered art since it must not be done or influenced by your subconscious and must be an activity on which you are always conscious of your actions."

This is yet another imprecise and crappy translation of what happened but it does not matter. The idea is mainly that if we need to be fully conscious of all our actions when programming, then this activity cannot be considered art since art relies heavily on one's subconscious.

The whole deal led us (me and Mariana Bravo) to a discussion about what part of what we do is art. Because, obviously, both of us believe that some part of it IS art. We couldn't disagree with Prof. Setzer. Indeed, talking to a machine is pretty much the opposite of art. Formalism, logic and maths are key elements to be used very consciously to achieve the goal of writing something that compiles and run as expected in a computer. From this I conclude that writing to execute is not art.
I also claim that this is also the part of computer science that is very well mastered! Programmers are great to write something that execute and does what was wanted.

You can see the proof to this claim on every programming competition out there. ACM-ICPC, Yahoo HackDay, Google Code Jam, Imagine Cup and many others. Those competitions stress this aspect of computer science. They expect the people involved to write a software that executes and does what was expected. And people do GREAT! I have seen amazing codes, amazing solutions and wonderful applications being built on those contests. Yet, every company involved in those contests (to hire the winners) still fights to write better software and are present in tons of conferences trying to achieve better results. The winners of those contests are usually amazing programmers in the sense that they are great to find solutions to a problem and have it compile and run. Why are we still struggling to write better software then?

The answer is not mine. It has been around for ages and loads of people probably already said it before me (and probably much better than me): "Because the greatest problem of software is the maintenance".
During the maintenance, it is no longer THAT important to talk to the machine. The code is already talking to the machine somehow and some part of it should be saying something different. The code now enters a whole new realm. The realm of talking to people.

Having your code talk to people is very similar to having a letter or an email or even a blog communicating your ideas. One could argue that writing with code is bounded to a formalism that breaks the communication and beauty that can be achieved. To which I reply that, for many years, poetry bounded itself to very rigid forms such as Alexandrine, Iambic Pentameters, Dodecasyllabes and others. I believe I can say that nobody would dare deny that there is great art done following those rigid rules.

Uncle Bob says in his Clean Code book: "A good and clean code should read as a newspaper article". He says so because he believes this is the only way one can be quickly parse a code and focus only on what is important to the current matter. It means that complexity should be hidden as much as possible to avoid having to bump into her all the time. It also means (indirectly) that there are TONS of ways to write the same code, that is, to achieve the same computer execution result.
Raymond Queneau is a famous french writer author of "Exercices de styles" (Style exercises) and many others. His book presents 99 versions of the same story written in the same language (French) with different styles. Each of the versions have different writing styles and present the reader with a new experience of the same facts. Writing the book was surely an amazing exercise but reading it is also very interesting. Reading 99 ways to achieve the same result makes you think a lot about what you actually write.

As programmers, we are subjected to such exercise very often. There are dozens of frameworks to achieve the same goal (many times in the same language), there are dozens of libraries that do the same thing but the code is ALWAYS VERY different.
I propose (and will try to) that, as programmers, we force ourselves to take part of this exercise. Our version control systems help to do so and we should be doing it all the time. Write a first version of your code, save it (commit), write a new version of your code (maybe from the first one or not), save it and repeat the action.

Such description of the thing makes me (and you, probably) remind that we already to this over and over and over. Refactoring is exactly the process to rewrite to achieve the same goal but changing the style.
Martin Fowler's definition of Refactoring is "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior". It is not really the same thing I previously stated right? This is where the art comes along.

Here is Fowler's trick: "... to make it easier to understand and cheaper to modify...". This definition is amazingly vague! How the heck do you make something get easier to understand or cheaper to modify? Formally you don't! You can only find out what makes the code easier subjectively. You can only know what makes it cheaper to modify when you actually have to modify it and do it.

Uncle Bob uses the same trick. He says Clean Code helps you write better code and detect bad code. Again, this is highly subjective! And more: it depends heavily on the programmer's ability to communicate through the code with other people. Such ability is heavily related to art!
According to Wikipedia (and please feed me better info if you have them),
"Art is the process or product of deliberately arranging elements in a way that appeals to the senses or emotions".
Again from Wikipedia, "Communication can be perceived as a two-way process in which there is an exchange and progression of thoughts, feelings or ideas towards a mutually accepted goal or direction".

From those definitions, I would say Art is a form of Communication. Moreover Poetry, Literature, Theater, Painting, Sculpting, Music, Dance and other art activities are holders to a communication channel between the artist and the watcher.
Poetry and Literature use words.
Theater and Dance use the human body.
Painting and Sculpting rely on colors and textures while Music bases itself on sounds.

The study of art is therefore heavily related to the study of how to communicate with people from various backgrounds and ideas. This is the art matter that is missing in the computer science courses (at least the one I followed) and the computer related careers.

Regarding literature, someone can put a word after another and make it "run", that is, make sense. But it takes a lot more effort to pass from that to art.
Programming follows the same rule.
Loads of programmers can put an instruction after another but it takes an amazing work to transform that into something that will communicate later on.

My conclusion from this post (more an article than a post) is that computer science courses are very important because they teach you to communicate with the computer. But once you learned (and it takes more time than just the course) to make the computer do what you want, you must learn to communicate with people. Actually, you should probably do both at the same time but the important part is that you always remember that "executing" is poor and communicating can be art.

Now all that I need is to actually incorporate such thinking and begin acting to improve in this sense.