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]
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.
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.
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.
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 ↗
kevin_thibedeau · · focus · HN ↗
CamperBob2 · · 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.
wduquette · · focus · HN ↗