I generaly agree with everything you have said Erik. As a rule, fancy code only creates problems. I have only come across one possible exception to this rule. For many years I worked on hand held label printers. These were mass produced so were very cost sensitive. The customer wanted as large a set of characters as possible . This takes up more ROM and leaves less space for code. To fit more charcaters in we used various methods of compressing bit maps. Even so, in a typical product we had 12K of font data and 4K of code. The customer also wanted to do fancy things with the characters like italic, bold and outline styles. No way could we store these as separate fonts, we could not afford the ROM, so they had to be generated algorithmically from the base font data.

The code that did these data manipulations consumed the largest proportion of cpu time available per print cycle so the algorithms they used and the way they were coded had to be as efficient as possible to avoid needing a higher speed and more expensive processor variant. It was important that intermediate values were kept around for the next print cycle because that would need them too. Also the font data was several bytes long so reducing fetch times with indexing was important too and of course the data needed to be de-compressed at the same time too. As much RAM as possible had to be left for the text editor so we could not just read in a few columns of data and work on that.

All in all a very challenging piece of code that required a deep understanding of the processor machine code in order to produce the fastest smallest code (no compiler on earth could look far enough ahead in the code to achieve the same level of optimisation). We were proud of the results and I thought the code could be described as elegant. It did nothing stupid or dangerous but in its own way was rather fancy. Several million units were made and it never crashed.

IAn