James G. Sack (jim) wrote:
Andrew Lentvorski wrote:
..
Refactoring requires that you understand the old code, write tests,
refactor while gaining no new functionality, and only *then* pull out
bad subsystems and redo them.
That's a whole lot of unfun coding. Writing a second system with less
functionality and *still* no tests is much more fun.
While the developers deserve 90% of the blame, to some extent, I blame
C/C++. C/C++ makes refactoring code much more annoying than it needs to
be. The crappy preprocessor is mostly to blame.
I'm not sure what you mean by crappy? It's certainly pretty complex --
maybe too complex? What sort of faults yield crappiness?
The fact that there is path coupling between internal and external
files. The fact that the preprocessor does textual substitution rather
than syntactic substitution.
What does:
#include <stdio.h>
mean? Which stdio.h? From where? In what order?
What does FALSE mean in:
if a == FALSE b = 2;
Which file defined it? What happens when 2 files defined it?
An editor has to effectively parse the *entire* project every time it
needs to work out the smallest syntactic problem. This is why most
C/C++ IDE's have to rely on precompiling for any decent level of
performance.
Java's JAR's were definitely a step in the right direction. The
signature and linkage information are *bound together*. And depending
on a JAR does not mean that the JAR's *it* depends on can alter the
meaning of your source code.
Oh! Hey =-O .. wud-n-it be kinda neat if the preprocessor could be
reimplemented in (say) python?
Dear, Deity, no. That doesn't solve the underlying problem of the
preprocessor isn't syntactically part of the language.
C++ templates were that attempt. They fail miserably. They eventually
became Turing-complete in their own right in order deal with not being
syntactically C.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
