[plt-scheme] contracts.ss: Can you disable them at runtime?
On May 17, 2007, at 22:12, Shriram Krishnamurthi wrote:
>> > And what if they don't? How about for other people?
>> Then they should leave them on.
> Really? Even when their contracts and/or their tests change the
> O(.) complexity of their programs?
I knew about contracts from Eiffel, but in my late-1990s non-Eiffel
big project, I used logs:
I wrote a fairly complex military logistics system for US DoD. It
took a couple of years, but they liked it, it saved money, the system
ended up winning awards, etc.
The system I wrote at BBN had quite a bit of logging, because I
didn't trust myself, particularly at those moments when folks asked
me to add new functionality very quickly. The logs helped me watch
the decisions the computer was making, and I made the logs friendly
to humans so that logistics experts who were not technologists could
understand the logs too. They really, really liked the logs. The
logs gave them confidence and auditability when things were going
well, and gave them clear insight into problems when things went
wrong from time to time. Happily, the logs did not impact
performance noticeably. They would have never dreamed of asking me
to turn off the logs, because at the moment the system became a black
box they would have stopped trusting it--they certainly knew I was
fallible. I remember that period fondly--we had passionate
developers and passionate users working hand-in-hand.
Later the system was completely rewritten by another company in Java
to comply with an all-Java directive, most likely to wrest control of
future development away from pesky developers (Java developers are a
dime a dozen and easily replaced) and away from domain experts (who
loved to dream up new functionality), and into the hands of tiers of
managers devoted to one master, Microsoft Project. I became an
advisor to the Java transition.
What I remember about the transition was that the logs were not a
part of the new system, and the performance of the new system was
much worse initially, so the end users were newly unhappy: they
waited forever for answers, and couldn't see how those answers were
computed. Eventually the performance problems were mitigated, partly
through the addition of powerful hardware, partly through complex
caching of enormous intermediate query results, and eventually an
independent query facility was backfitted to the design to offer some
measure of cross-check.
The new, glorified data processing system eventually worked, that is,
it computed correct answers, but never as fast as the old system, and
what I missed most was the old system's ability to record its
thoughts for humans to examine.