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]
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.
elhosots · · focus · HN ↗
Kudo’s to Mr Osterhout’s long lived legacy
bch · · focus · HN ↗
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:
[0] <a href="https://en.wikipedia.org/wiki/Log-structured_file_system" rel="nofollow">https://en.wikipedia.org/wiki/Log-structured_file_system[1] <a href="https://man.freebsd.org/cgi/man.cgi?query=bmake&sektion=1" rel="nofollow">https://man.freebsd.org/cgi/man.cgi?query=bmake&sektion=1
[2] <a href="https://en.wikipedia.org/wiki/Raft_(algorithm)" rel="nofollow">https://en.wikipedia.org/wiki/Raft_(algorithm)
[3] <a href="https://en.wikipedia.org/wiki/Ousterhout's_dichotomy" rel="nofollow">https://en.wikipedia.org/wiki/Ousterhout's_dichotomy
[4] <a href="https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf" rel="nofollow">https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf
[5] <a href="https://web.stanford.edu/~ouster/cgi-bin/aposd.php" rel="nofollow">https://web.stanford.edu/~ouster/cgi-bin/aposd.php
CorrectHorseBat · · focus · HN ↗
Karrot_Kream · · focus · HN ↗
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.