C programs of a particular type are known as big wish programs. They have this name because of their similarity to the wish program that is part of Tk.
Unless you are completely new to Tcl/Tk, you are familiar with the program tclsh. With tclsh you can interactively enter Tcl commands and see the results of their evaluation. Or you can name a script file for tclsh to evaluate. The Tcl interpreter within tclsh starts out with all the built-in commands provided by the Tcl package.
The program wish is quite similar to tclsh. The primary difference is that the Tcl interpreter within wish starts out with all the commands provided by both the Tcl and Tk packages. The commands of two packages are combined in one interpreter right from the startup of the program.
A big wish program is one like wish that combines Tcl and one or more packages in one program. Examples include:
...and there are others.
In the early days of Tcl, the construction of a big wish program was the only way to extend Tcl with commands provided by an extension.
One challenge in those days was if you had a Tcl script that made use of commands provided by a package other than Tcl, you had to be careful to choose the right big wish to evaluate that script, so that it had access to all the commands it used. For example, if your script used the signal command, it would need to be run with the tcl program, and not with the tclsh program, because signal comes from TclX.
Tcl 7.5 (released 1996) introduced the load command. This allowed C-coded extensions to be added to a Tcl interpreter dynamically at run time. Also new in Tcl 7.5 was the package command that offered a higher level interface to control the source-ing and load-ing of new functionality into a Tcl interpreter on demand. The authors of extensions started to use the new features to support dynamic loading. At the same time, these extensions continued to support embedding, and continued to be distributed with machinery to build an appropriate big wish program.
One valuable simplification from this time was that scripts no longer needed to be concerned about what program was used to run them. A [package require TclX] in a script would be sufficient to supply the signal command that script needed to function. The [package require TclX] would succeed the same whether the tcl program was running, so TclX was present from startup, or whether tclsh was running, and TclX was dynamically loaded as demanded by the script.
As of 2003, even the custom interpreters like expect, etc. are falling out of favor. Since the commonly available extensions have been available as loadable extensions for quite some time, each package can be pulled into the tclsh program at runtime, as they are demanded by scripts evaluating [package require] commands. This is an example of the extending solution winning out in the embedding vs. extending contest.
The turning point for the change was the release of Tk 8.4.2, which came with the ability to package require Tk. This allowed one to have a single interpreter - tclsh - which could load nearly any combination of extensions.