> Kudo’s to Mr Osterhout’s long lived legacy

Tcl and Tk are fantastic, and if this is where it ended, John Ousterhout would have secured his place in history - this is only 1 piece of his contributions, though - see too:

  * Log structured file system[0]

  * parallel Make[1] (Adam de Boor from Sprite project, not JO hisself)

  * RAFT consensus protocol[2]

  * Various notable teachings [3][4][5]

[0] https://en.wikipedia.org/wiki/Log-structured_file_system

[1] https://man.freebsd.org/cgi/man.cgi?query=bmake&sektion=1

[2] https://en.wikipedia.org/wiki/Raft_(algorithm)

[3] https://en.wikipedia.org/wiki/Ousterhout's_dichotomy

[4] https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf

[5] https://web.stanford.edu/~ouster/cgi-bin/aposd.php

▲ spijdar 2 hours ago | parent | next [-]

It's unfortunate that Sprite itself didn't really get absorbed into much of anything, and so doesn't have much of a footprint and isn't really remembered outside of LFS and a few even more niche bits.

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

Of course, even by 1992, there were multiple versions of Tcl coexisting... :-)

  eery@cherimoya [11] > ls /sprite/lib/sun4.md | grep tcl
  libtcl.a
  libtcl5.a
  libtcl6.2.a
  libtcl6.3.a

▲ CorrectHorseBat 2 hours ago | parent | prev [-]

I see this praise of tcl/tk a lot on HN, but everyone I know (myself included) absolutely hate working with it in VLSI CAD tools.

	▲	Karrot_Kream 2 hours ago \| parent \| next [-]
		If you write Tcl/Tk from scratch for an application and architect it well, it's great. The way it's injected into VLSI tooling is an abomination. I've done both. This 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.
	▲	wduquette an hour ago \| parent \| prev \| next [-]
		One can create amazing ergonomic scripting APIs in TCL; I've done that. One can also rapidly create horrors without end. I've seen that, too. With great power comes great responsiblity.
	▲	CamperBob2 2 hours ago \| parent \| prev \| next [-]
		Indeed. If AI did nothing for me but deal with Xilinx's shit, I'd still nominate everybody from Hinton to Amodei for Nobels.
	▲	kevin_thibedeau 2 hours ago \| parent \| prev [-]
		I like it better than the alternatives. The challenges come from vendors who had atrocious in house scripting languages (Synopsys) and then shoehorned their architecture into Tcl. You have to deal with a lot of opaque handles for things that should be native objects.