It even looks good, and I say that as someone who has a strong distaste for plain text. It reminds me of the most impressive linguistic feat someone's ever seen (although this one actually uses extra spaces...): https://news.ycombinator.com/item?id=28651093
Can anyone remind me what Tcl is good for anymore? I know a lot of EDA tools use it as the backend for builds but once the software writes the Tcl script for me, I've never had to make any changes to it more complex than variable names or options.
It is homoiconic without parenthesis soup. It also supports removing commands to the point of being non-Turing complete. That makes it useful as a configuration language for non-trusted input that can be extended as needed.
I've been writing a lot of lisp lately, and I don't know that homoiconicity is in and of itself a virtue. It's nice to have, I suppose, but I don't see what it really brings to the table other than a time-saving hack for reading configuration from disk.
I don't think homoiconicity itself is the most important thing. I think the real power of Lisp comes from a bunch of other features, and a non-homoiconic language would be approximately equal in power to Lisp if it had these features:
1) A public API for manipulating the AST in the standard library. Most languages have some AST API defined as internals of their compiler/interpreter, but it is a private API, not a public API in their standard library. (Lisp's AST is almost trivial; but a language could have some kind of complex ADT-based or object-oriented AST and it would still be okay, so long as the AST is a public API in the standard library.)
2) The AST should be extensible, so you can define new types of nodes.
3) Ability to write arbitrary code (compile-time macros) which gets executed at compile time, and which can read the AST, and generate a replacement AST.
4) Compile-time macros are written in the same language (or almost the same language) as runtime code, rather than some special language (compare the C preprocessor to C).
5) Some form of syntax extensibility
6) Code to execute at compile-time, new AST node types, syntax extensions, etc, can be defined in the same program which uses them, as opposed to being segregated to some kind of "compiler plugin" with some kind of special build process
7) Some kind of "quotation syntax", where you write some code, and instead of actually being compiled, instead code to generate its AST is compiled. For example, 1+1 might evaluate to 2, %ast(1+1) (to pick a possible syntax at random) might evaluate to the AST for 1+1.
8) Some kind of "backquote syntax", to make it easy to write code templates (this is basically just (6) with ability to make substitutions in a hygenic way).
9) All of the above should be able to expressed with syntactic succinctness. Don't be afraid to add special syntax, or even some embedded DSLs, if it makes the above easier to express. (For the language designer/implementor, much of this may simply be dogfooding point 5 above.)
Now, homoiconicity means Lisp can give you (1)-(9) with less work (for the language implementor) than a non-homoiconic language might require. But not everyone likes the simplistic syntaxes which homoiconic languages tend to have, and there is no reason why a language with an Algol-like or C-like or Pascal-like syntax couldn't give you (1)-(9) as well, albeit with a bit more work. Indeed, if you took any existing language and added (1)–(9) to it (if any of them weren't already there), and made sure to do it in an easy to use way, you'd basically end up with a language roughly equivalent to Lisp in power.
For example, Amira is a package that has been around about 30 years and uses it to script rendering. On the other hand a competitor (Carl Zeiss), a decade ago did a rewrite of their software and choose python (among others) as a scripting language. Nikon also developed their own language that resembles basic/C#.
Asking your users to script in TCL rather than something like python is sadistic, and a position advocated by aging neckbeards.
> Asking your users to script in TCL rather than something like python is sadistic, and a position advocated by aging neckbeards.
Right. It's almost impossible to reason about a language that has no meaningful grammar. Finding bugs is hard, automatically finding problems nearly impossible.
Tcl did give us one important thing -- Tk -- via `wish`, which was an important step in informing how people might want to add GUIs to scripts.
But actually still committing to teach it in this day and age is really perpetuating bad habits when there are better options out there -- even PowerShell is a better choice.
Eh, I don't know. I wouldn't choose Tcl today for such a use case, maybe Lua. But you could certainly do worse than Tcl. Like a half-thought out custom language. Anyone ever coded nastran DMAP? Or Tex macros? I'd be ecstatic to have TCL over that.
I've seen a materials testing machine whose method to script custom test sequences was a "programming language" that was displayed as text but you couldn't actually type things in. You'd have to select constructs such as a for loop or conditional from a drop down box, then a dialog would appear asking you for the parameters of the loop (start, end, etc).
Actually, I think I even prefer Tcl to Excel's VBA.
What is it good for, or what is it used for? I think Tcl's biggest downfall is the fact that it suffers from Excel syndrome in that It works well for a small set of problems and OK for a bigger set of tangential problems.
Tcl is Tool Command Language, and it's pretty good at routing commands to all of your JTAG, GPIB, Serial port, and whatnot devices. It has a REPL that is easy to use, and sits in the same runtime as all of your code. You can kind of think of it as a shell terminal for your devices. It's also apparently pretty compact all things considered. But it's typing is about as strong as wet toilet paper, which is cool when you have commands to send, receive, and parse out. But since it's also a programming language, you get into situations where someone writes all of the code to communicate with all of the devices in a nice little mini-library for everyone else to use. Since Tcl is a programming language, everyone is expected to develop all of the test and debug code in TCL.
For some projects, we'll prototype a feature in Tcl, but the firmware implementation will be way simpler and more concise. That's mostly because doing anything with an array, or any type of math function requires a mess of syntax. The quintessential example would be incrementing a value in an array. In C, it would look like:
myArray[i]++;
But in Tcl, it goes a little something like this:
lset myArray $i [expr [lindex $myArray $i] + 1]
Now imagine doing things with descriptive variable names and it gets pretty messy.
I have always found the man page for TCL to be an amazingly concise description of the language.
https://manpagez.com/man/n/Tcl/
Seriously, why aren't more manpages like that.
It even looks good, and I say that as someone who has a strong distaste for plain text. It reminds me of the most impressive linguistic feat someone's ever seen (although this one actually uses extra spaces...): https://news.ycombinator.com/item?id=28651093
Note that a web-enabled version can be found at the end of page https://wiki.tcl-lang.org/page/Tcl+Tutor
Is there a tcl implementation targeting javascript that has upvar and uplevel and can access javascript objects?
Can anyone remind me what Tcl is good for anymore? I know a lot of EDA tools use it as the backend for builds but once the software writes the Tcl script for me, I've never had to make any changes to it more complex than variable names or options.
https://wiki.tcl-lang.org/page/Who+says+Tcl+rules%2E%2E%2E
Tk
Moreover, every Python installation with Tkinter has Tcl built in. You can directly interact with that Tcl interpreter from the Python side.
“Tcl tends to get ported to weird places like routers.”
-Larry Wall (inventor of Perl), on Usenet.
The test suite for SQLite is written in Tcl. It's also an option for customizing Fossil SCM installations.
Same for various GNU[0] test requirements (DejaGnu[1]). Tcl at its core[2].
[0] https://www.gnu.org/software/automake/manual/1.16.1/html_nod...
[1] https://www.gnu.org/software/dejagnu/manual/index.html
[2] https://en.wikipedia.org/wiki/DejaGnu
It is homoiconic without parenthesis soup. It also supports removing commands to the point of being non-Turing complete. That makes it useful as a configuration language for non-trusted input that can be extended as needed.
I've been writing a lot of lisp lately, and I don't know that homoiconicity is in and of itself a virtue. It's nice to have, I suppose, but I don't see what it really brings to the table other than a time-saving hack for reading configuration from disk.
I don't think homoiconicity itself is the most important thing. I think the real power of Lisp comes from a bunch of other features, and a non-homoiconic language would be approximately equal in power to Lisp if it had these features:
1) A public API for manipulating the AST in the standard library. Most languages have some AST API defined as internals of their compiler/interpreter, but it is a private API, not a public API in their standard library. (Lisp's AST is almost trivial; but a language could have some kind of complex ADT-based or object-oriented AST and it would still be okay, so long as the AST is a public API in the standard library.)
2) The AST should be extensible, so you can define new types of nodes.
3) Ability to write arbitrary code (compile-time macros) which gets executed at compile time, and which can read the AST, and generate a replacement AST.
4) Compile-time macros are written in the same language (or almost the same language) as runtime code, rather than some special language (compare the C preprocessor to C).
5) Some form of syntax extensibility
6) Code to execute at compile-time, new AST node types, syntax extensions, etc, can be defined in the same program which uses them, as opposed to being segregated to some kind of "compiler plugin" with some kind of special build process
7) Some kind of "quotation syntax", where you write some code, and instead of actually being compiled, instead code to generate its AST is compiled. For example, 1+1 might evaluate to 2, %ast(1+1) (to pick a possible syntax at random) might evaluate to the AST for 1+1.
8) Some kind of "backquote syntax", to make it easy to write code templates (this is basically just (6) with ability to make substitutions in a hygenic way).
9) All of the above should be able to expressed with syntactic succinctness. Don't be afraid to add special syntax, or even some embedded DSLs, if it makes the above easier to express. (For the language designer/implementor, much of this may simply be dogfooding point 5 above.)
Now, homoiconicity means Lisp can give you (1)-(9) with less work (for the language implementor) than a non-homoiconic language might require. But not everyone likes the simplistic syntaxes which homoiconic languages tend to have, and there is no reason why a language with an Algol-like or C-like or Pascal-like syntax couldn't give you (1)-(9) as well, albeit with a bit more work. Indeed, if you took any existing language and added (1)–(9) to it (if any of them weren't already there), and made sure to do it in an easy to use way, you'd basically end up with a language roughly equivalent to Lisp in power.
TCL is also used in a lot of bots
See https://news.ycombinator.com/item?id=4120200 article and discussion from 2012.
Certainly a trend to move away from it.
For example, Amira is a package that has been around about 30 years and uses it to script rendering. On the other hand a competitor (Carl Zeiss), a decade ago did a rewrite of their software and choose python (among others) as a scripting language. Nikon also developed their own language that resembles basic/C#.
Asking your users to script in TCL rather than something like python is sadistic, and a position advocated by aging neckbeards.
https://www.thermofisher.com/us/en/home/electron-microscopy/...
> Asking your users to script in TCL rather than something like python is sadistic, and a position advocated by aging neckbeards.
Right. It's almost impossible to reason about a language that has no meaningful grammar. Finding bugs is hard, automatically finding problems nearly impossible.
Tcl did give us one important thing -- Tk -- via `wish`, which was an important step in informing how people might want to add GUIs to scripts.
But actually still committing to teach it in this day and age is really perpetuating bad habits when there are better options out there -- even PowerShell is a better choice.
Eh, I don't know. I wouldn't choose Tcl today for such a use case, maybe Lua. But you could certainly do worse than Tcl. Like a half-thought out custom language. Anyone ever coded nastran DMAP? Or Tex macros? I'd be ecstatic to have TCL over that.
I've seen a materials testing machine whose method to script custom test sequences was a "programming language" that was displayed as text but you couldn't actually type things in. You'd have to select constructs such as a for loop or conditional from a drop down box, then a dialog would appear asking you for the parameters of the loop (start, end, etc).
Actually, I think I even prefer Tcl to Excel's VBA.
Some major FPGA tools still use it.
It's the fastest way to write an app with a GUI and you can easily make a Windows executable with only an 8MB overhead (with freewrap).
What is it good for, or what is it used for? I think Tcl's biggest downfall is the fact that it suffers from Excel syndrome in that It works well for a small set of problems and OK for a bigger set of tangential problems.
Tcl is Tool Command Language, and it's pretty good at routing commands to all of your JTAG, GPIB, Serial port, and whatnot devices. It has a REPL that is easy to use, and sits in the same runtime as all of your code. You can kind of think of it as a shell terminal for your devices. It's also apparently pretty compact all things considered. But it's typing is about as strong as wet toilet paper, which is cool when you have commands to send, receive, and parse out. But since it's also a programming language, you get into situations where someone writes all of the code to communicate with all of the devices in a nice little mini-library for everyone else to use. Since Tcl is a programming language, everyone is expected to develop all of the test and debug code in TCL.
For some projects, we'll prototype a feature in Tcl, but the firmware implementation will be way simpler and more concise. That's mostly because doing anything with an array, or any type of math function requires a mess of syntax. The quintessential example would be incrementing a value in an array. In C, it would look like:
myArray[i]++;
But in Tcl, it goes a little something like this:
lset myArray $i [expr [lindex $myArray $i] + 1]
Now imagine doing things with descriptive variable names and it gets pretty messy.
To add to the confusion what TCL calls arrays are not what other languages call arrays.
The above syntax is needed for lists, not arrays.
If you want to increment a value in a TCL array all you need to do is:
However that array is basically a dictionary, a hash map of (integer in this example) keys to values.
TCL associative arrays are hash maps that have to be global. They are definitely one of the worst part of the language.
Most people use dicts on modern TCL instead.