Arthur A. Gleckler wrote:
Yes, and people waste an amazing amount of time in C, C++, and Java
because of the need to satisfy the compiler in cases like this.
I'm skeptical of this claim. Not that Scheme isn't more productive than
C/C++/Java, but that reduced compile-time error-checking makes one
more productive. (Of course it is very difficult to measure this.)
Remember, when one changes a program from one completely working state
to another, one always moves through a large number of non-working
states, e.g. when the numbers of parameters don't match, etc. If I'm
experimenting with a new signature for a procedure, why can't I test one
body of code that uses it, a body in which I've changed the calls,
without changing every single call in the entire code base? If I find
out that the new signature was a bad idea, I'd like to be able to revise
my design without once again modifying every call in the entire code
base for the compiler's benefit, not mine.
There are lots of strategies for dealing with this, such as defining
a temporary function with a new name.
When I change the number of parameters to a function/method (I'm doing
so right now in the Kawa implementation) I deliberately do extra work
so the compiler can catch the places I haven't changed. For example
I keep the old method during testing with the 'final' keyword to make
sure I'm changed all the inherited methods, and then I remove it to
make sure I've changed all the call-sites.
But again: I'm not opposed to a "lenient" compiler mode as distinct
from a "strict" mode. Which mode(s) a compiler provides is a
quality-of-implementation issue. However, if you want to develop
solid programs, you want to consistently build in a fairly-strict
mode, and you want your Makefile/IDE to set those options.
(The jury is still out on how to do strict static typing, but
checking number of parameters to known functions is a no-brainer.)
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
