3 ms·

Do you think it's an actually good language though? I only tinkered around with Tcl (long ago when writing eggdrop bots and more recently while messing around w

by simias 8y ago

Do you think it's an actually good language though? I only tinkered around with Tcl (long ago when writing eggdrop bots and more recently while messing around with FPGA and ASIC build scripts) and while it's serviceable it never struck me as a particularly interesting or elegant scripting language. When given the choice I'll always pick Python or Perl over Tcl. Am I wrong? What did I miss?

qznc 8y ago
I don't think Tcl is in competition with Python or Perl. It is in competition with bash, PowerShell, etc. Its syntax is quicker to type which is good for interactive (REPL) use. Sometimes I'm thinking about a simple build system which is very much like Make but uses Tcl to be cross-platform and scales better to advanced uses. Tcl could also work well in Jupyter notebooks. Once you think about functions, classes, and modules, you better use Python.
- deleted 8y ago
  [deleted]
rkeene2 8y ago
I think it's a good language. It has simple syntax (only 13 syntax rules), great documentation for the API, the language, core commands, and all the packages shipped with the core release. It's very flexible so it can be used in a lot of situations: Embedded into a program as a domain-specific language (DSL), scripting engine in its own right with very complex software written in many different styles, evaluating untrusted code (with Tcl Safe Interpreters). Really the only reason to pick Python over Tcl is that more people have picked Python over Tcl in the past.
eridius 8y ago
I think Tcl is incredibly elegant. It's got a set of very simple syntax rules that compose together to govern everything. You can use Tcl to create your own keywords that are used exactly like the built-in ones and your caller won't ever tell the difference (well, unless they inspect an error backtrace). For example, a try/catch syntax was proposed as TIP 89¹. And many many years ago, as part of the MacPorts project, I implemented the entirety of TIP 89 in pure Tcl. The TIP was proposing actual Tcl keywords, but I implemented exactly the proposed syntax and semantics without a single keyword. I have no idea if that code exists in any form anymore (I haven't been involved with the project in something like a decade), but I'm pretty sure the only observable difference between that and TIP 89 is error backtraces² that cross a frame involving try/catch. Also, virtually every type³ in Tcl can be expressed as a string, and so you can model the entire language mentally as if every value was in fact a string. If you wanted to write your own Tcl interpreter it would be pretty easy to actually implement it this way, though obviously performance would suffer quite a lot. ¹Later superseded by TIP 329 in response to the error options dictionary in Tcl 8.5. ²And FWIW I believe there's no actual spec for what error backtraces look like anyway, I think it's implementation-defined, though don't quote me on that. ³The only type I know of offhand that can't be expressed this way is an array (which is distinct from a list, that is a fundamental building block of Tcl and can absolutely be expressed as a string)
- convolvatron 8y ago
  anyone interested in starting to play around with languages would do well to write out the 'everything is a string' version. its very short and understandable. plus the result is really amenable to inclusion in another program as an extension language (tcl is too, but it has a much bigger footprint)

by simias 8y ago

qznc 8y ago

I don't think Tcl is in competition with Python or Perl. It is in competition with bash, PowerShell, etc. Its syntax is quicker to type which is good for interactive (REPL) use. Sometimes I'm thinking about a simple build system which is very much like Make but uses Tcl to be cross-platform and scales better to advanced uses. Tcl could also work well in Jupyter notebooks. Once you think about functions, classes, and modules, you better use Python.

deleted 8y ago
[deleted]

rkeene2 8y ago

I think it's a good language. It has simple syntax (only 13 syntax rules), great documentation for the API, the language, core commands, and all the packages shipped with the core release. It's very flexible so it can be used in a lot of situations: Embedded into a program as a domain-specific language (DSL), scripting engine in its own right with very complex software written in many different styles, evaluating untrusted code (with Tcl Safe Interpreters). Really the only reason to pick Python over Tcl is that more people have picked Python over Tcl in the past.

eridius 8y ago

I think Tcl is incredibly elegant. It's got a set of very simple syntax rules that compose together to govern everything. You can use Tcl to create your own keywords that are used exactly like the built-in ones and your caller won't ever tell the difference (well, unless they inspect an error backtrace). For example, a try/catch syntax was proposed as TIP 89¹. And many many years ago, as part of the MacPorts project, I implemented the entirety of TIP 89 in pure Tcl. The TIP was proposing actual Tcl keywords, but I implemented exactly the proposed syntax and semantics without a single keyword. I have no idea if that code exists in any form anymore (I haven't been involved with the project in something like a decade), but I'm pretty sure the only observable difference between that and TIP 89 is error backtraces² that cross a frame involving try/catch. Also, virtually every type³ in Tcl can be expressed as a string, and so you can model the entire language mentally as if every value was in fact a string. If you wanted to write your own Tcl interpreter it would be pretty easy to actually implement it this way, though obviously performance would suffer quite a lot. ¹Later superseded by TIP 329 in response to the error options dictionary in Tcl 8.5. ²And FWIW I believe there's no actual spec for what error backtraces look like anyway, I think it's implementation-defined, though don't quote me on that. ³The only type I know of offhand that can't be expressed this way is an array (which is distinct from a list, that is a fundamental building block of Tcl and can absolutely be expressed as a string)

convolvatron 8y ago
anyone interested in starting to play around with languages would do well to write out the 'everything is a string' version. its very short and understandable. plus the result is really amenable to inclusion in another program as an extension language (tcl is too, but it has a much bigger footprint)