I have, tucked away, an unfinished essay on pluggable scriptable software, with about half of it devoted to the social (or survival) advantages of such software in the free software world. I don't claim credit for the seed of the idea, I was just trying to flesh out some things that I heard Jim Blandy mention one time.
Chris keeps bugging me to post up the essay even though it's not complete. Maybe I'll do that.
Then sej said:
1) all the external documentation and design documents were no substitute for the direct reality of inspecting the architecture in a debugger. They served as a map for the territory, but were not the territory by any stretch of imagination. A large dose of experimentation, reasoning, and inter-programmer dialogue was required to build up a more detailed understanding of how things actually worked.
This is true. To return to my sawfish example, it was extremely useful to me to have sawfish-client available to examine the data structures of the running window manager, and interact with the window manager in real time and see my results either on the screen or by examining the internals of sawfish using sawfish-client. It was the excellent design of sawfish, combined with the excellent debugger/interpreter, combined with the excellent API documentation, that made working on sawfish easy and fun.
Interpreted languages usually have an advantage over compiled languages here, or at least they do if the language provides some form of eval(). eval() makes available the entire scope of the language from the debugger instead of just limited calls to API functions. This allows richer interaction with the running program.