I thought this was worth upvoting because I was stung by how the author views programming. It's worth remembering that "hacking" is typically ill-liked, even by some of those claiming to practice it.
Start with purpose. With the exception of art software projects (which I don't believe Graham has in mind here) all computer programs are designed to accomplish some kind of task.
I suppose this guy is a Java programmer?...
No one cares how pretty the code is if the program won't work.
...that or Perl.
Great paintings, for example, get you laid in a way that great computer programs never do.
#%$hole...
PG could have alluded to the similarity between Math and hacking. The thing that I feel both share is that there is an underlying beauty to a well-crafted result. Truly beautiful results (like original self-printing program in Lisp) withstand the test of time, like a universal truth. Thus a program is not like an egg made by a chef, or even a Porsche made by an engineer.
The flip side is that there's no "way" to write a program. There actually isn't even really a notion of truth. Beauty is in the eye of the beholder. The only constraint I have as a programmer is to (1) not run out of memory and (2) not run out dough (which would force me to quit hacking and get a "real job"). There are some people who think that obfuscated C is art, and there's FP folks like me who would fire someone for writing anything in that godawful language (Which might be unfair. People should only be fired for writing Java on the job). I think this is pretty strong support in favor or programming as an art.
The other piece of evidence I cite is that the academic form of hacking is called Computer Science and we know what they say about anything that has the word "Science" in it...
Basically, the only premise of idleword's argument that holds up is that artists get laid and programmers don't. I will resist fighting fire with fire on this point.
But maybe PG should allude to poets or composers next time. Apparently some painters are real jerks.
There used to be two professions that we call programming today:
Systems Analysis
and (unsurprisingly)
Programming.
Arguably the systems analysis bit was the more interesting of the two, it is the one that I would equate with architecture, and to some extent (but certainly not as much as some would) art.
The other part, the programming part is best equated to engineering and construction.
I find I go through exactly those two phases when making something new. The first part I love to do it's where all the interesting bits are, the problems get solved.
By the time I hit the second phase, the joyful part is over, from there it is just typing stuff in and realizing the vision that I already have in my head and debugging stuff.
Rarely (but it does happen occasionally) do I get back in the 'fun' bits while coding something. That would mean I've made some terrible oversight during the analysis phase.
The analysis phase sometimes also includes some programming, it is where you come up with nifty little programs to test your assumption and where you let your inspiration go wild in order to see if you can solve the problem in an interesting way.
That is the most joyful kind of programming that I know, it is on a white piece of paper without any kind of connection to the real world of data processing. This is were algorithms are born. I love doing that.
This is interesting - I haven't heard this expressed explicitly, but it describes pretty exactly how I feel about "programming".
I've also found that almost all the interesting stuff is in the stuff upfront where I'm sketching out ideas on a notepad - roughly how things will work together, what the running time of different approaches will be and how it will scale, the user flow and interaction, and getting down the trickier algorithms to become reasonably sure that the main idea is feasible.
The rest really is just plumbing and brickwork. It seems like a lot is written online about the different ways to lay bricks, but I've never really felt that that was very interesting, except for resulting reductions in time spent bricklaying. Sometimes it's fun playing around to make extremely abstracted code, or some other challenge, but for the most part, it's pretty repetitive.
Thanks for expressing it, I didn't realize that the cool part used to be a distinct profession.
So if we are going to judge programming as such, then what about all the plumbing and brickwork associated with art? Didn't an analysis of the Mona Lisa detect multiple layers of paint, indicating that the artist had retouched many parts of it? From what I understand, it's common practice.
For some reason, the plumbing and brickwork in programming isn't viewed the same way by all people. Perhaps it's because of the use of low level languages (and by low level, I mean anything less abstract than Ruby, Lisp or Haskell. you can't meaningfully remove boilerplate in the C family of languages.). I personally find it gratifying to refactor code into something more elegant, and I'm sorry if you don't see it that way.
> So if we are going to judge programming as such, then what about all the plumbing and brickwork associated with art?
In 'real' art (painting and sculpture for instance) the execution and the expression are inseparable, in programming you can delineate the one from the other reasonably well.
For instance, a mathematician without any programming skills could sketch out the basis of an algorithm, which could then be implemented by programmers familiar with their particular language.
> Didn't an analysis of the Mona Lisa detect multiple layers of paint, indicating that the artist had retouched many parts of it?
Yes, so ? He didn't get it 'right' or 'satisfactory' the first time and decided to change it.
But there is a reason why artists sign their works and programmers can collaborate, even across vast distances on the same work.
In the end it is all bits.
If Da Vinci had reduced the idea of the La Gioconda to 4 squares and you asked four different painters to create the 4 squares and you'd merge them the painting would probably not be hanging in the Louvre right now.
Even if he had sketched it and sent it off in four pieces as a guide it still wouldn't have worked.
And that process works quite well for software, which indicates to me that the two are fundamentally different.
> For some reason, the plumbing and brickwork in programming isn't viewed the same way by all people.
No doubt.
> Perhaps it's because of the use of low level languages (and by low level, I mean anything less abstract than Ruby or Haskell). I personally find it gratifying to refactor code into something more elegant, and I'm sorry if you don't see it that way.
Refactoring code and optimizations are a step above simply putting layers of stone above each other, effectively you've temporarily switched back to architectural mode.
And I definitely agree with you that that is a gratifying thing to do. But it also indicates to me that I should be more diligent during the design phase because refactoring, no matter how satisfying is an expensive thing to do.
But there is a reason why artists sign their works and programmers can collaborate, even across vast distances on the same work.
In the end it is all bits.
Ok, I have to admit, that is by and far the most compelling difference between art and programming that I've ever heard.
To me the real joy in programming comes when you integrate these two phases. Writing and debugging code should provide you the resistance of the medium to further shape your concept of what is it that you are implementing.
Start with purpose. With the exception of art software projects (which I don't believe Graham has in mind here) all computer programs are designed to accomplish some kind of task.
I suppose this guy is a Java programmer?...
No one cares how pretty the code is if the program won't work.
...that or Perl.
Great paintings, for example, get you laid in a way that great computer programs never do.
#%$hole...
PG could have alluded to the similarity between Math and hacking. The thing that I feel both share is that there is an underlying beauty to a well-crafted result. Truly beautiful results (like original self-printing program in Lisp) withstand the test of time, like a universal truth. Thus a program is not like an egg made by a chef, or even a Porsche made by an engineer.
The flip side is that there's no "way" to write a program. There actually isn't even really a notion of truth. Beauty is in the eye of the beholder. The only constraint I have as a programmer is to (1) not run out of memory and (2) not run out dough (which would force me to quit hacking and get a "real job"). There are some people who think that obfuscated C is art, and there's FP folks like me who would fire someone for writing anything in that godawful language (Which might be unfair. People should only be fired for writing Java on the job). I think this is pretty strong support in favor or programming as an art.
The other piece of evidence I cite is that the academic form of hacking is called Computer Science and we know what they say about anything that has the word "Science" in it...
Basically, the only premise of idleword's argument that holds up is that artists get laid and programmers don't. I will resist fighting fire with fire on this point.
But maybe PG should allude to poets or composers next time. Apparently some painters are real jerks.