TclTutor 3: Computer aided instruction package for learning the Tcl language
msen.com
msen.com
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
-Larry Wall (inventor of Perl), on Usenet.
[0] https://www.gnu.org/software/automake/manual/1.16.1/html_nod...
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.
https://www.thermofisher.com/us/en/home/electron-microscopy/...
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.
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.
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.
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:
incr myArray($i)
Most people use dicts on modern TCL instead.