FW: Surprising after all these years that this never got a page. Well, here goes...
Ousterhout's Dichotomy, proposed in the early 80's by John Ousterhout as a software development paradigm, asserts that the world of application development is divided into two languages: a compiled language focusing on disk access and efficiency such as C, and a lower-level (*1), typeless or loosely-typed scripting language with a simple, basic syntax. Tcl was created by John originally to fill in the role of that second language. For this reason, Tcl is sometimes referred to as a "glue language," since it sticks lower-level components together with ease.
The motive behind this model is that standard compiled languages are good for writing low-level algorithms to perform the basic computational tasks required, but not very good at all for less computational, more descriptive tasks like defining interfaces. Tcl's implementation of the dichotomy, for example, basically involves writing functions in C and converting them to Tcl procedures using the pretty simple Tcl API, then writing scripts to tie the functions together and create a working application out of it.
This should, in theory, relieve a lot of the code organization problems that things like Object Orientation were designed to help amend. If the dichotomy served its purpose completely, someone using Tcl this way should need neither C++ nor incr Tcl to keep their code clear and modular. This is part of the reason why the Tcl developer's establishment largely eschews the idea of putting an object orientation extention into the Tcl core.
The most basic application is to write most of your application in C, then use something like Tcl/Tk to make a cross-platform GUI. This avoids the need to rewrite your interface 3 times just to distribute it on 3 different platforms.
By the way, many applications provide a miniature language for the user to automate tasks - for example, a macro langauge in a word processor, or even more ubiquitously, UNIX shell scripting and DOS BAT files. Tcl can be and often is used for that sort of purpose, but that usage isn't quite what we're talking about here. Ousterhout's concept is primarily focused on making the application itself written partially in the other language, not for user automation.
Back to theory - the main complaint against the dichotomy is that it supposedly rigidly categorizes "compiled" and "interpreted" languages and strictly defines their roles, when a growing amount of languages compile partially into "virtual machine" code, or at least use a bytecode internally (even Tcl does this!). Many people for this reason declare the underyling premise completely false, so it has picked up names like "Ousterhout's false dichotomy" and "Ousterhout's fallacy" over the years. However, to this day there is no language fluid enough to automate as easily as a scripting language and perform low-level tasks just as efficiently as a low-level one. There need not be an absolutely rigid line between the two types of languages for it to be an effective way of looking at software development
Tcl was originally designed to be used that way, but don't feel stifled by it. There's no clearly defined line between "Tcl script using a few C libraries" and "C application automated by Tcl." For a random example, take WaveSurfer, a basic audio editing and conversion program. That's either a GUI written in Tcl/Tk for the basic functionality of the Snack audio toolkit, or a Tcl/Tk application that happens to use Snack. So there's nothing strict here, it's just a way of thinking about things.
This is a quote from Ousterhout himself in 1994:
I didn't design Tcl for building huge programs with 10's or 100's of thousands of lines of Tcl, and I've been pretty surprised that people have used it for huge programs. What's even more surprising to me is that in some cases the resulting applications appear to be manageable. This certainly isn't what I intended the language for, but the results haven't been as bad as I would have guessed.
But Tcl has long evolved since then, and is better at forming very large applications like that - so if it works for you, great.
I'm a bit hazy on this myself, so feel free to correct me if I got anything wrong. :)
*1 = Excuse me, but didn't you mean "higher level" instead of "lower" up above?