3 ms·

> Lua was one of the very few reasonable choices. There are a ton of reasons why you might not want to stick TCL, Guile, or Python inside your application. Tha

by bch 6y ago

> Lua was one of the very few reasonable choices. There are a ton of reasons why you might not want to stick TCL, Guile, or Python inside your application. That sounds quite editorial - can you list some of the “ton of reasons”? C. 2000 Tcl was already 12 years old, received a major performance upgrade w 8.4[0], and was liberally licensed. [0] https://www.linux.com/news/tcltk-840-release-announcement/ https://www.linux.com/news/tcltk-840-release-announcement/

klodolph 6y ago
It seems like people have forgotten how bad TCL is, as a language. Everything is a string, except variables, which can be arrays of strings. You want a number? String. You want an object? String. You want a data structure? String. TCL is a bad choice for almost anything. It is only marginally more usable than using a shell. It seems like the only reason you would use TCL is so you could throw together a GUI in front of a command-line program, or maybe stick a very bare-bones scripting interface inside something else.
- detaro 6y ago
  "luckily", someone created cmake so younger generations get to experience this problem too...
  - klodolph 6y ago
    CMake is definitely worse than TCL, having used both.
- nrclark 6y ago
  I wrote a lot of TCL code in 2015-2017, and it was better than I thought going into it. TCL has first-class lists and maps, and they're not string-based under the hood at all. It's true that TCL was "all string all the time" in the early days, but now it's more like Python - you represent those types as a string, but that's not the internal storage. I think TCL gets a really bad rap. Once you get past the unusual syntax, it's pretty nice to work in. Almost Python level nice. It supports classes, exceptions, first-class functions, and has some concepts I've never seen in other languages (such as upvar). It's easy to embed, or easy to use standalone. Installation is small and portable. And it feels like if Lisp and Bash had a baby together, conceived with love. TCL in 2005 might have been a beast. TCL in 2020 is way better than you might expect. And it persists also, with a stable ecosystem as an embedded language in various CAD/EDA tools.

by bch 6y ago

klodolph 6y ago

It seems like people have forgotten how bad TCL is, as a language. Everything is a string, except variables, which can be arrays of strings. You want a number? String. You want an object? String. You want a data structure? String. TCL is a bad choice for almost anything. It is only marginally more usable than using a shell. It seems like the only reason you would use TCL is so you could throw together a GUI in front of a command-line program, or maybe stick a very bare-bones scripting interface inside something else.

detaro 6y ago
"luckily", someone created cmake so younger generations get to experience this problem too...
- klodolph 6y ago
  CMake is definitely worse than TCL, having used both.
nrclark 6y ago
I wrote a lot of TCL code in 2015-2017, and it was better than I thought going into it. TCL has first-class lists and maps, and they're not string-based under the hood at all. It's true that TCL was "all string all the time" in the early days, but now it's more like Python - you represent those types as a string, but that's not the internal storage. I think TCL gets a really bad rap. Once you get past the unusual syntax, it's pretty nice to work in. Almost Python level nice. It supports classes, exceptions, first-class functions, and has some concepts I've never seen in other languages (such as upvar). It's easy to embed, or easy to use standalone. Installation is small and portable. And it feels like if Lisp and Bash had a baby together, conceived with love. TCL in 2005 might have been a beast. TCL in 2020 is way better than you might expect. And it persists also, with a stable ecosystem as an embedded language in various CAD/EDA tools.