in reply to How do you view programming
For me, coding(*) is neither art nor science nor engineering.
The first thing that many think of when they think of 'Art', is creativity and whilst coding undoubtedly involves a good deal of creativity, I think that there are more defining terms and attributes of 'Art' that cannot easily be applied to code.
The greatest value--in monetary terms--in Art, is uniqueness. I doubt we will ever see a piece of elegant, avant-garde or modern Perl code going under the hammer at Sotheby's and fetching a fortune. The value in code is in it replication. Sell many copies and make a reasonable buck. Give away many copies and make the world a better place. One-off pieces of code are often fun to write, and can even be the source of some remuneration, but noone is ever going to get rich from it. In art, a limited edition is always worth considerably more than a mass reproduction. In code, the opposite (usually) holds true.
That leads to another difference. Works of art can rarely, if ever, be reproduced en-masse and retain either their aesthetic appeal or monetary value. The very nature of programs means that they can always be reproduced in quantity, and that ability is often intrinsic in their value.
Art is usually the work of an individual, though occasionally you do get collaborations between 1, 2 or 3 artists--I'm thinking about the traditional use of the term as applied to painters, sculptors and the like as opposed to those in the performing arts for whom the road to proficiency, fame and wealth takes a different course. Whilst programming can be an individual affair, it can also be a collaborative affair, and often on a large scale. Mores the pity:)
The produce of artists is usually valued for it's aesthetic worth, and usually with huge multiples over the intrinsic costs of it's components. Even if you incorporate the artists time, it rarely makes a dent upon the huge multipliers that are applied to works of note.
At a cursory glance, this seems appealing. Further examination shows that it doesn't hold water. The main aim of science is discovery & classification, and the determination--through step-wise refinement and/or disapproval of theorems--of explanations and fundamental rules for natural phenomena. At least until the much vaunted Quantum bit computer makes it's debut, there's little about programming that can be classified as natural:)
There are a few exceptions of course. Turing discovered a few fundamental truths and few others since have complemented his findings. On the other hand, there have been very few if any truly new discoveries in programming since the days of Ada Lovelace. Almost everything we do is a rediscovery, rehash or minor variation on stuff that was invented long ago and was, for the most part, long since written down and structured, by the likes of Donald Knuth.
Mostly what we coders do is just futz with stuff. Re-inventing, re-structuring and recombining, but mostly futzing:)
This has the strongest appeal of all. In many ways the processes and procedures of the coder appear superficially similar to those performed by engineers in many disciplines. We take a limited selection of usually small, independent pieces, string them together in to larger pieces and then mass produce them for consumption or use. Whether it's the nuts and bolts that go into the making of a car or airplane; the brick & mortar, concrete, steel and glass of the civil engineer; or the transistors, nand, nor and not gates of the electronics industry. They all bear a remarkable resemblance to the machine instructions, keywords, library functions and classes of software development.
However the similarities begin to fade under closer scrutiny. The fundamental difference is metrics. It is nearly always possible to quantify the nature of any single component or subsystem in engineering and further, to describe it in such a way that you could give the same description (think engineering drawing for example) to any engineer in any of many companies world-wide and they would produce the same thing. The process of machining a piece of metal is a process of setup, cut, measure, possible cut again and you have it. There is skill involved. The semi-experienced lathe or grinder operator learns to make all his final cuts before measurement in the same direction to negate the effects of backlash in the drive screw. The even more experienced operator will learn to cut slightly more than his measurements imply, to allow for tool wear. However, even these skills can be measured, formulated and encoded such that CAD/CAM software will automatically account for tool wear when it supplies the dimensions of the part to fully automated turret lathes and the like. There are even standard formulae for accounting for the distorting effects of expansion due to the heat created by the cutting process itself. All these things have--as yet--no equivalent in the development of software. Heck. To date, we still don't have reliable metric for pre-determining how long it will take to write yet-another-shopping cart/database update/sort routine.
To me, it's a craft. As someone's signature line has it--Programmers are the carpenters of the modern age!.
Like the woodworker--and I apologise for re-using this analogy, but like all the best ones, it has a lot of mileage in it--the coder creates each piece anew. Whilst the metal worker can happily select any piece of the designated raw material for his work, the woodworker cannot. He has to deal with the produce of nature, complete with it's variable grain, texture, and strength. He must check for knots, sapwood, and insect damage. Even when he is making yet-another chair leg, table top or window frame just like the previous 2 dozen. Each one is individual.
So it is with coding. Whilst it's hard to see the raw ingredients of a program as natural--they are!
The requirements of most pieces of code are based upon subjective rather than quantitative criteria.
We tend to put the house number/road name fields above the town/city name or post/zipcode. Even though it would actually make more sense to do it the other way around. Give me the Zipcode first and I can complete at least the state field for you, probably the town/city as well. In the UK, the postcode usually selects right down to a handful of houses in a given street. So why does every dratted on-line form put the postcode at the bottom of the form? (The same is probably true for Zipcodes/postcodes in other countries also, but I am not familiar enough with them to know for sure).
Personally, I think that the invention of hierarchical directory structures has done our industry more harm than good. Without their invention, file systems that allowed useful designation of, and selection by, meta-data would do away with much of the nonsense that hierarchical directory structures cause. Further discussion on that is for another time and place, but think how much simpler it would be if you could ask the file system to show you all the files on your hard drive that you had edited in the last five days. Yes. You can write a program to do it, but it should be as easy as a glob(myEditor, -5).
Programming based on human, usually traditional, subjective criteria rather than logical or quantitative ones.
The other 'raw ingredient' in the coding process is very natural. It's the human brain, and it's capacity to see patterns and apply them. It's the innate ability of the human brain to detect and isolate patterns that make it unlikely that either woodworking or coding will go the way of metal-working and become a process primarily carried out by the robots and computers. The advent of software that can reliably detect the flaws in a piece of wood, or read between the lines of a program specification, and then translate either into the required end product are a long way off.
Hopefully, that will remain the case at least until after I retire. As for all you youngsters out there...good luck:)
Examine what is said, not who speaks.
The 7th Rule of perl club is -- pearl clubs are easily damaged. Use a diamond club instead.