But I think the Sprite kernel and the Sprite-specific libraries (Pfs, Pdev, Fs_Select, Td_), as well as the Sprite-specific userspace, were pretty incredibly pieces of software given the limited resources they were created with.
For that matter, John Ousterhout's text editor and terminal emulator, mx and tx, were the substratum that Tcl was built on. There's a single library on Sprite, libmx, which mx and tx are based on. Tcl basically grew as the command language of libmx, originally two separate entities, then by mx 2.4 it was fully incorporated:
eery@cherimoya [1] > cd /sprite/src/lib/mx
eery@cherimoya [4] > grep Tcl *.c
mxCmdAM.c: Tcl_Interp *interp;
mxCmdAM.c: Tcl_Return(interp, Cmd_BindingGet(mxwPtr->cmdTable, argv[1]),
mxCmdAM.c: interp->result = Tcl_Merge(bindingCount, bindings);
mxCmdAM.c: Tcl_Interp *interp;
[...]
eery@cherimoya [10] > grep LIBS ../../cmds/mx/local.mk
LIBS = -lc -lmx -lsx -lcmd -ltcl -lX11
eery@cherimoya [11] > ls /sprite/lib/sun4.md | grep tcl
libtcl.a
libtcl5.a
libtcl6.2.a
libtcl6.3.aThis is partially because when Tcl was first incorporated in VLSI tools it didn't have a good way to organize and modularize code. But this is also because the big VLSI tool shops realize they basically have a monopoly on their integration surface and have no incentive to improve it.
It's easier to freeze the integration surface and maintain backward compatibility than it is to move the surface forward.