Tcl is way too smart of a language for its own good. I love how everything is a string or can be hacked on a string, so you can basically do levels of metaprogramming that reach unheard of levels
All of which I used many years to go to write "Snit", a quite nice object system for coding up Tcl objects and Tk widgets. Snit's a TCL library that takes a nice, easily readable description of your desired object type (the instance variables, the methods, and so forth), translates it immediately into standard TCL, and then evaluates that to define your type. Basically, it's a macro system for defining object types. (I say "object types" rather than "classes" because there is no inheritance.)
I loved your 'expand' utility - and wrote a truly heinous Tcl to PHP framework/translation layer using it, because I preferred Tcl to PHP at the time - still do, but the early hatred for PHP has muted - that powered an application at the college I attended for an embarrassingly long time.
I've always thought of Tcl as a type of Lisp. Clearly, the relationship isn't direct, but it allows a lot of the same things that Lisps do. Plus, the way one nests commands is similar.
And it shares a lot of the same metaprogramming that Lisps have - more so than the vast majority of other languages.
I think of it as an alternate take on Lisp's metaprogramming. A form of cosmic-horror take that will drive you insane, yes, but Lisp-like metaprogramming nevertheless. Stare too long into Tcl's deadlights and you will want to be there.
As someone who did enough of both (in fact, Tcl was my gateway to Lisp), I'd say yes and no.
Classical Lisp (Scheme/CL) has much more elegant core concepts/semantics, but often much more clunky stdlibs and small/outdated batteries. This shows in unexpected places like the way homoiconicity has a big caveat: comments break the "code as tree" contract, forcing you to revert back to the useless "code as string" middle ages.
I know that because I had a need to hack together an horrible replacement for the thing I miss the most from Lisp: quasiquoting (<a href="https://git.sr.ht/~q3cpma/tcl-misc/tree/e4ba1bb4fcca729337b9a728455c9600cb5a56be/item/util.tcl#L40" rel="nofollow">https://git.sr.ht/~q3cpma/tcl-misc/tree/e4ba1bb4fcca729337b9...).
------
So, despite the fact that I'd probably recommend Janet to people who want Tcl without Tk, these days, I still like it. Do note that compared to its competitors (Ruby, Python, Perl), its POSIX support is _really_ bad. There's no way in core to do signal handling or open a UNIX socket (and dead TclX that doesn't use namespaces isn't a replacement). Even SBCL has sb-posix.
qalmakka · · focus · HN ↗
srean · · focus · HN ↗
wduquette · · focus · HN ↗
srean · · focus · HN ↗
<a href="https://wiki.tcl-lang.org/page/Snit%27s+Not+Incr+Tcl" rel="nofollow">https://wiki.tcl-lang.org/page/Snit%27s+Not+Incr+Tcl
wduquette · · focus · HN ↗
sea6ear · · focus · HN ↗
wduquette · · focus · HN ↗
RHSeeger · · focus · HN ↗
And it shares a lot of the same metaprogramming that Lisps have - more so than the vast majority of other languages.
qalmakka · · focus · HN ↗
bitwize · · focus · HN ↗
BoingBoomTschak · · focus · HN ↗
Classical Lisp (Scheme/CL) has much more elegant core concepts/semantics, but often much more clunky stdlibs and small/outdated batteries. This shows in unexpected places like the way homoiconicity has a big caveat: comments break the "code as tree" contract, forcing you to revert back to the useless "code as string" middle ages.
I know that because I had a need to hack together an horrible replacement for the thing I miss the most from Lisp: quasiquoting (<a href="https://git.sr.ht/~q3cpma/tcl-misc/tree/e4ba1bb4fcca729337b9a728455c9600cb5a56be/item/util.tcl#L40" rel="nofollow">https://git.sr.ht/~q3cpma/tcl-misc/tree/e4ba1bb4fcca729337b9...).
------
So, despite the fact that I'd probably recommend Janet to people who want Tcl without Tk, these days, I still like it. Do note that compared to its competitors (Ruby, Python, Perl), its POSIX support is _really_ bad. There's no way in core to do signal handling or open a UNIX socket (and dead TclX that doesn't use namespaces isn't a replacement). Even SBCL has sb-posix.