| I don't write much Tcl the last few years (mostly Python now, as it pays the bills), but looking from the Python perspective towards Tcl, i see a lot of good things i left behind: * No GIL. Real threads with no silly global locks * A very cool VFS layer, a bit like the stuff you can see in windows powershell with the Registry/Certstore/etc drives * A beautiful implementation really worth a read (no silly 'XXX: don't know what to do, lets print to stderr' inside a library like you find in pythons source) * An extremly consistent language far more than python which does all kinds of junk 'to make parsing easier' even if it makes the language harder * Sandboxing interpreters (doesn't work with python, no chance) * Stacked channels and a cool streams abstraction (Pythons io module is still some way behind its options) * A built in event loop (Python just got one with 3.4...) * A standard lib that mostly takes event driven as given (unlike pythons blocking stuff) * very powerful metaprogramming support (e.g. have some logging code with 'ZERO' overhead when disable at runtime) * good C-API and excellent support for embedding * Stable ABI since more than 10 years (e.g. you can load a binary extension compiled against 8.1 into a current 8.6 interpreter and it just works, one of the reasons many Tcl projects didn't release new versions, no need. Unlike the python nonsense with -2.5,2.6,2.7 versions for every package, okay Python got a partial stable ABI now too, years later) * mostly sane platform abstractions (the world isn't posix everywhere) * packaging with starpacks (python's pyinstaller comes close, but lacks the VFS stuff, years later), a bit like cross-platform OS X app bundles * Non mutable values by default, no pointers, so it is kind of functional * A nice package system that doesn't mix up filesystem layout and namespaces and supports version So if you look at it, it is kind of a weird crossover between ideas you now find in: Go, Node.js, Lisp, Powershell. Just a bit outdated and in need of some love. |