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 568236
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Art or engineering?
by dpJudas on Mon 29th Jul 2013 01:30 UTC 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