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.
Permalink for comment 568236
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?"
Member since:

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