4 ms·

> Here. Extremely enjoyable to code in and easy to integrate with C which makes integrating with arbitrary libraries and syscalls simple. This is definitely a

> Here. Extremely enjoyable to code in and easy to integrate with C which makes integrating with arbitrary libraries and syscalls simple. This is definitely a sweet-spot for TCL. It's not surprising that TCL doesn't get more attention when this use case has been so stable for so long.

tptacek 11y ago
Perhaps because Lua is a better language and, like Tcl, was custom-built for that sweet spot.
- mzs 11y ago
  I've not done any Lua but my oldest son has and he showed me. It really did not stand-out in my mind compared to say python. I guess it's pretty simple, embeddable, interoperable with C. It really was a great first language for him really but so would have js really. Tcl is pretty neat though. It has this feel like lisp and very simple rules plus everything can be a string, which is prefect for gluing text output together between tools.
  - tptacek 11y ago
    I've done a lot of Tcl work; two successive companies I worked at used it as their embedded language. It has its charms, but I would have a hard time working at another company that in 2015 chose Tcl over Lua. Issues I have with Tcl: * The syntax is as idiosyncratic as a Lisp, but has few of the advantages that Lisps get for homoiconicity. * uplevel/upvar is a janky way to get metaprogramming. Compare metaprogramming in Tcl to that of Japanese Tcl errr Ruby. * The Tcl runtime is outmoded. I could probably think of others. There's also the fact that Tcl's vaunted integration with C code has pretty much become par for the course in high level languages. I didn't find writing Ruby extensions to be any more painful than writing Tcl extensions. Modern high level languages also expose full-featured FFIs, so you often don't even need bindings. Tcl was ahead of its time! It was a good embedded high level language before virtually every large project recognized the need for embedded languages. And the event-based model that Tk forced on it turned out to be pretty useful for network servers. It was a great choice in the late 1990s.
    - mzs 11y ago
      Good points, I'd moved to python for embedding and shimming myself and then got bit cause SWIG had forced Cpython when there were other options later. I do still very much like the simple syntax though.
      - tptacek 11y ago
        I like it sometimes more and sometimes less. For instance, the "everything's a string" parsing rules mean comments can cause parse errors.
        mzs 11y ago
        Ha, that's the very reason I used it at first! #!/bin/sh # the next line restarts using tcl \ exec tcl "$0" "$@" ... I just go so annoyed with is it /usr/bin/perl or /usr/local/bin/perl or ... And is it awk or nawk or ... And somebody told me this trick with Tcl and I was like, "I'll just use it for this simple script and be done with it."
- srean 11y ago
  That is exactly how I think of Lua. Lua stole Tcl's thunder and added its own. Perhaps the only thing missing is a community wide standard macro system that works with Luajit, without that Tcl can still do an one up on Lua with its uplevel.

tptacek 11y ago

Perhaps because Lua is a better language and, like Tcl, was custom-built for that sweet spot.

mzs 11y ago
I've not done any Lua but my oldest son has and he showed me. It really did not stand-out in my mind compared to say python. I guess it's pretty simple, embeddable, interoperable with C. It really was a great first language for him really but so would have js really. Tcl is pretty neat though. It has this feel like lisp and very simple rules plus everything can be a string, which is prefect for gluing text output together between tools.
- tptacek 11y ago
  I've done a lot of Tcl work; two successive companies I worked at used it as their embedded language. It has its charms, but I would have a hard time working at another company that in 2015 chose Tcl over Lua. Issues I have with Tcl: * The syntax is as idiosyncratic as a Lisp, but has few of the advantages that Lisps get for homoiconicity. * uplevel/upvar is a janky way to get metaprogramming. Compare metaprogramming in Tcl to that of Japanese Tcl errr Ruby. * The Tcl runtime is outmoded. I could probably think of others. There's also the fact that Tcl's vaunted integration with C code has pretty much become par for the course in high level languages. I didn't find writing Ruby extensions to be any more painful than writing Tcl extensions. Modern high level languages also expose full-featured FFIs, so you often don't even need bindings. Tcl was ahead of its time! It was a good embedded high level language before virtually every large project recognized the need for embedded languages. And the event-based model that Tk forced on it turned out to be pretty useful for network servers. It was a great choice in the late 1990s.
  - mzs 11y ago
    Good points, I'd moved to python for embedding and shimming myself and then got bit cause SWIG had forced Cpython when there were other options later. I do still very much like the simple syntax though.
    - tptacek 11y ago
      I like it sometimes more and sometimes less. For instance, the "everything's a string" parsing rules mean comments can cause parse errors.
      - mzs 11y ago
        Ha, that's the very reason I used it at first! #!/bin/sh # the next line restarts using tcl \ exec tcl "$0" "$@" ... I just go so annoyed with is it /usr/bin/perl or /usr/local/bin/perl or ... And is it awk or nawk or ... And somebody told me this trick with Tcl and I was like, "I'll just use it for this simple script and be done with it."
srean 11y ago
That is exactly how I think of Lua. Lua stole Tcl's thunder and added its own. Perhaps the only thing missing is a community wide standard macro system that works with Luajit, without that Tcl can still do an one up on Lua with its uplevel.