code as data «
You can arrange a system so its behavior at runtime varies dynamically, depending on content that system sees as data. An easy way to do this is by converting code into data. Obviously this must be what an interpreter does. If you type a piece of text into a UI and execute it, the code for what you type can't have been compiled statically into the app before you launched it, except perhaps in constituent primitives.
When you use a language or development environment willing to convert source code into executable form and run it, this behavior is usually what I mean by dynamic on this page. (Sure, you can say dynamic and mean other things, but ignore that.)
Why do I want to do that? Why do I want to compose new code and run it without a monolithic compile and link cycle? Usually to experiment, so I can verify things work as I expect, in a way keeping feeback fast so my mind stays engaged and productive. Although I use C and C++, those languages notoriously suck for dynamic, interpreted scripts. (You can interpret C, but it's a bit too easy to make mistakes using pointers.)
So my first, primary motive is testing: it's less painful to build comprehensive test suites this way, accreted slowly as a script that does slightly more as you add new parts.
But my secondary motive is simulation: an entire distributed system is a complex thing—very hard to play with and do experiments upon each time you have a whim to try a new variation in situations. Simulating a distributed system in a dynamic language is much less costly than doing it in C and C++. When you create a product in C or C++ intended to run as one node in a system, a test for this—as a distributed network simulation—can be more complex than your product, and probably is.
Usually, for a product in C or C++, it's simply not done. Folks try to get by without system simulations, struggling through use cases only as they occur in real system runs. This typically takes a long time, and results in both poor coverage and slow turnaround time for experiments. The value of scientific method is mostly absent, because it costs too much. Why don't folks always write simulations in a higher level language? Who knows? Apparently faith in minimal testing is a big reason: If nothing seems to go wrong, maybe it's good. How many more bugs can hide in there if I haven't seen them yet? (Well, a lot.)
A third possible motive doesn't (usually) apply in my case: you might ship new code around at runtime in live, deployed systems. This idea sounds dangerous to most folks, even if they didn't fear virus and worm problems. Usually long bake cycles are necessary to qualify candidate code for deployment, so casual live updates won't fly. It only seems a good idea when you experiment in simulations, without risk of customer problems.
stub «
So far this page is just a stub, but a brief intro above should give you the right idea about future direction of content I plan to put here.
