Linked by Thom Holwerda on Sun 28th Jul 2013 14:06 UTC
General Development "There is a reason I use 'old' languages like J or Lush. It's not a retro affectation; I save that for my suits. These languages are designed better than modern ones. There is some survivor bias here; nobody slings PL/1 or Cobol willingly, but modern language and package designers don't seem to learn much from the masters. Modern code monkeys don't even recognize mastery; mastery is measured in dollars or number of users, which is a poor substitute for distinguishing between what is good and what is dumb. Lady Gaga made more money than Beethoven, but, like, so what?" This isn't just a thing among programmers. The entire industry is obsessed with user numbers, number of applications, and other crap that is meaningless when you consider programming to be art. When I post a new item about some small hobby operating system, the comments will be filled with negativity because it's no Windows or iOS, whereas only ten years ago, we'd have lively discussions about the implementation details. And then people wonder why that scene has died out.
Thread beginning with comment 568212
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Art or engineering?
by galvanash on Sun 28th Jul 2013 21:54 UTC in reply to "Art or engineering?"
galvanash
Member since:
2006-01-25

I absolutely love to code, it is my favorite hobby, but I am not really sure it qualifies as art. In my view it is more like math or chess, where certain solutions can be beautiful or brilliantly designed or executed. The heart of coding is more logic than creativity.


I disagree. Its exactly like any other form of language.

There is writing like textbooks, documentation, instruction manuals, etc. - things meant to convey information as clearly and economically as possible. These kinds of things are extremely important and there is skill to doing them well, but few would consider the results "art".

Then you have poetry and other forms of creative writing, where the point is not just to convey information, but to convey it in ways that elicit an emotional response in the reader. That response may be triggered by your choice and flow of words, it may be triggered by clever grammatical choices or other "tricks" of language, or it may be that you are just using arbitrarily imposed restrictions to challenge your creative skills (iambic pentameter, haiku, basic rhyming, etc.)

Programming has exactly the same form and function.

Some people approach it as a straight-forward instruction manual - write exactly what is needed to convey the proper information to make the machine do what is intended. This is more analogous to the "textbook" example above. People who approach it like this consider the machine to be the intended audience - they want it to be readable by humans, but there is no effort put towards creative use of the language.

Others like to program creatively, they are not just trying to achieve a particular result, they are trying to do it in ways that fulfill their creative drive. They are writing for the humans reading their code, and they want their code to elicit an emotional response.

The heart of coding depends on the writer's intent...

My favorite example of this is Duff's Device:

http://en.wikipedia.org/wiki/Duff's_device

This is a straightforward copy of items from an array to mmaped output register:

send(to, from, count)
register short *to, *from;
register count;
{
do
*to = *from++;
while(--count>0);
}


This is art:

send(to, from, count)
register short *to, *from;
register count;
{
register n = (count + 7) / 8;
switch(count % 8) {
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while(--n > 0);
}
}


Edited 2013-07-28 22:08 UTC

Reply Parent Score: 2

RE[2]: Art or engineering?
by Vanders on Sun 28th Jul 2013 23:45 in reply to "RE: Art or engineering?"
Vanders Member since:
2005-07-06

That's the most useless use of Duff's devices I've ever seen. It's performing a word-by-word copy but has additional addition, a whole bunch of extra comparisons and is vastly less readable. What precisely is that supposed to gain over the "naïve" implementation, precisely?

Reply Parent Score: 3

RE[3]: Art or engineering?
by galvanash on Mon 29th Jul 2013 01:15 in reply to "RE[2]: Art or engineering?"
galvanash Member since:
2006-01-25

That's the most useless use of Duff's devices I've ever seen.


I don't see how, since this is the intended use of Duff's device - those are the exact examples straight from Tom Duff's usenet post in 1983...

My question would be where you have seen a useful use of Duff's Device? It wasn't really intended to be useful, more of an oddity really. It has been used in actual product code, but very rarely and on modern processors it is pretty much pointless.

It's performing a word-by-word copy but has additional addition, a whole bunch of extra comparisons and is vastly less readable. What precisely is that supposed to gain over the "naïve" implementation, precisely?


Its over 50% faster on the hardware it was written for (VAX), but that isn't what makes it art. It is the creative intermingling of a switch and a while loop, taking advantage of case fall through in the C language to allow the code to jump into the middle of the unrolled loop to handle the remainder in the last pass.

My point isn't that this is good code, its not. But it is arguably "art" in the truest sense - it leverages the rules of the language it is written in a very unique way, leaving the reader to puzzle out what is going on. It in a sense has a hidden meaning, one that is not obvious at first pass. It seemingly does something that appears to violate the rules of the language, but in fact does not - it is perfectly legal C code.

Those are not traits of good code, in fact they are traits of bad code... But they are traits of art.

Reply Parent Score: 4

RE[2]: Art or engineering?
by dpJudas on Mon 29th Jul 2013 01:30 in reply to "RE: Art or engineering?"
dpJudas Member since:
2009-12-10

This is art:

"send(to, from, count)
register short *to, *from;
register count;
{
register n = (count + 7) / 8;
switch(count % 8) {
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while(--n > 0);
}
}
"
I would rather call it a technique. And strictly speaking a convoluted and somewhat dangerous technique. It trades off readability for speed, assuming a certain type of CPU architecture and compiler.

The code might actually run slower on many newer architectures and compilers where the compiler might have vectorization passes which converts it into SIMD instructions. The cleverness of the code may confuse such a pass, thus using a much slower technique than what is otherwise possible. It also assumes that simply calling memcpy(to,from,count) isn't mapped directly to a compiler intrinsic, as it is on many modern compilers.

That doesn't mean it wasn't clever, back when this approach would be a good idea, but you always have to trade off cleverness/optimizations against readability for other developers and compiler passes.

To me, the main difference between art and craftsmanship/engineering is that in art you might write the above purely for the beauty of the code itself, while craftsmanship there's usually always one technique that is the better choice for a particular problem. In most cases that means that the common well understood solution is usually better (in the example to call memcpy), unless there's something special about this spot in the program that justifies deviating from the standard practice.

Of course, part of the fun for me on a hobby basis is to try deviate and see where it gets me. ;)

Reply Parent Score: 4

RE[3]: Art or engineering?
by galvanash on Mon 29th Jul 2013 02:00 in reply to "RE[2]: Art or engineering?"
galvanash Member since:
2006-01-25

I would rather call it a technique. And strictly speaking a convoluted and somewhat dangerous technique. It trades off readability for speed, assuming a certain type of CPU architecture and compiler.


I actually agree completely. But that isn't the point.

The code might actually run slower on many newer architectures and compilers where the compiler might have vectorization passes which converts it into SIMD instructions. The cleverness of the code may confuse such a pass, thus using a much slower technique than what is otherwise possible. It also assumes that simply calling memcpy(to,from,count) isn't mapped directly to a compiler intrinsic, as it is on many modern compilers.


All quite true.

That doesn't mean it wasn't clever, back when this approach would be a good idea, but you always have to trade off cleverness/optimizations against readability for other developers and compiler passes.


Again I agree, but it doesn't have a wikipedia entry just because it was clever - it has a wikipedia entry because someone wrote it, and those who read it appreciated the inventiveness that went into writing it. There is something to it beyond just performing its intended function...

That is what makes it art - it isn't terribly useful and never was (you could do almost the exact same thing with 2 loops). Art doesn't have to be useful, it just has to elicit a response of some kind.

To me, the main difference between art and craftsmanship/engineering is that in art you might write the above purely for the beauty of the code itself, while craftsmanship there's usually always one technique that is the better choice for a particular problem.


Exactly. I agree completely. I was just illustrating an example of the former.

Reply Parent Score: 3