Re: ILC2005: McCarthy denounces Common Lisp, "Lisp", XML, and Rahul



> From: Joe Marshall <prunesquallor@xxxxxxxxxxx>
> I just noticed that one of the big frustrations I have with
> strong-arm typing is that you must have a syntactically complete as
> well as correct program. Sometimes I *want* to run program fragments
> that I *know* will break. I think it is important for a system to
> allow you to play with half-constructed partly broken code.

Hey, if this were contract Bridge, and you were my partner, I'd raise
your bid to slam!

With my style of developing one line of code at a time, bottom-up
tool-building, input-forward unit testing, I virtually never write
anything that would be considered a "complete program". Everything I
write is a fragment that calls previously-written tools (some tools
from the CMUCL or ELISP API, some tools I wrote myself earlier). And
now with BeanShell in Java I've been doing the same kind of software
development in Java too. To make a unit-testing Java IDE, I wrote ELISP
and Java functions whereby I type all my java code in GNU EMACS, select
the region I want, then click a keystroke to pass that region to a FIFO
that is being read by Java for BeanShell parsing and execution.

Line-at-a-time program-fragment development really does relieve me of
the burden of trying to fit my currently-under-test code into a larger
program framework, so I can spend 100% of my mental energy
concentrating on what I'm actually working on and 0% of my energy
wasted trying to fit one new line of code into a complete "program".

And in the course of line-at-a-time or fragment-at-a-time development,
it's trivial to unit-test the error messages, deliberately create code
that will break just to make sure the error message is working, in case
later I ever really do need that error message to tell me about some
subtle bug I put in my mistake. You'd never believe how very many times
I've found my error message is wrong, missing some parameter to match
the format specification, which I can immediately put in to correct the
problem during my unit-testing of the error message. It sure is nice to
get the testing of error messages out of the way immediately after
writing them, before they're ever needed to detect actual bugs in the
actual production code.
.