> Perhaps you would want to control when it happens? Certainly it could be built as a compiler advice system.
Yes, absolutely. That's why I really like how CL's (declare) form works, particularly with optimization settings.
> Why implement one version and write rules to translate it? Because the first version is usually simpler. The rules can be used repeatedly. So I wind up with code that's smaller. Do Not Repeat Yourself.
To me, this is doing the exact opposite. Well-factored code should have only one instance of a concept's implementation. With good factoring, both in terms of functions and macros, you should find writing translation rules redundant.
> How willing are you to trade simple code for longer, more optimized code?
Extremely, if warranted. When rewriting code to use greater performance optimizations, the original code should remain available, as a drop-in replacement for the optimized code. E.g., you might have files like:
foo-knowngood.c
foo-optimized.c
In your makefile (or equivalent build system), selection of which foo to compile and link in ought to be a simple matter of setting an environment variable. If left unspecified, -knowngood is the default suffix used.
That way, the same set of unit tests can detect discrepencies between foo-knowngood and foo-optimized. It would additionally help if foo-optimized included comments indicating the logic behind the optimizations. Literate programming would come in handy here, since it is the tricky code that requires the greatest amount of documentation detail.
> Abstraction abstraction abstraction.
As a professional software engineer, I can also make the claim that overly abstract code is every bit as difficult to read as alien hieroglyphics. If it takes me longer to read a chunk of highly abstract code than it'd take me to just rewrite it from scratch at a more reasonable level of abstraction, I will. You can have spaghetti code with high-level languages just as easily as you can with low-level code.
Thanks for the response. Very interesting subject matter!
> Have you been burned by
> Have you been burned by tail-call elimination?
Actually, yes, in rare circumstances, I have. :-)
> Perhaps you would want to control when it happens? Certainly it could be built as a compiler advice system.
Yes, absolutely. That's why I really like how CL's (declare) form works, particularly with optimization settings.
> Why implement one version and write rules to translate it? Because the first version is usually simpler. The rules can be used repeatedly. So I wind up with code that's smaller. Do Not Repeat Yourself.
To me, this is doing the exact opposite. Well-factored code should have only one instance of a concept's implementation. With good factoring, both in terms of functions and macros, you should find writing translation rules redundant.
> How willing are you to trade simple code for longer, more optimized code?
Extremely, if warranted. When rewriting code to use greater performance optimizations, the original code should remain available, as a drop-in replacement for the optimized code. E.g., you might have files like:
foo-knowngood.c
foo-optimized.c
In your makefile (or equivalent build system), selection of which foo to compile and link in ought to be a simple matter of setting an environment variable. If left unspecified, -knowngood is the default suffix used.
That way, the same set of unit tests can detect discrepencies between foo-knowngood and foo-optimized. It would additionally help if foo-optimized included comments indicating the logic behind the optimizations. Literate programming would come in handy here, since it is the tricky code that requires the greatest amount of documentation detail.
> Abstraction abstraction abstraction.
As a professional software engineer, I can also make the claim that overly abstract code is every bit as difficult to read as alien hieroglyphics. If it takes me longer to read a chunk of highly abstract code than it'd take me to just rewrite it from scratch at a more reasonable level of abstraction, I will. You can have spaghetti code with high-level languages just as easily as you can with low-level code.
Thanks for the response. Very interesting subject matter!