16 ms·

Why I'm Tcl-Ish

167 points by blacksqr 6y ago

jascii 6y ago
While TCL is definitely an odd language, with plenty to alienate the modern programmer, there are some killer applications for it. For me the thing that sucked me in was tcl/expect a simple but powerful tool to control CLI's. At one point in my life I was tasked with managing over 3000 various network devices, I couldn't have done it without TCL/Expect!
- cmacleod4 6y ago
  I'm the blogger here - I think my main point is that the perceived oddness is inextricably linked to Tcl's strengths.
  - jascii 6y ago
    I think that goes for a lot of languages that are now often considered "odd". There is something about how an elegant and simple paradigm can help you think about a problem! The first "higer" language I ever learned was Forth, and I never quite got to terms with infix notation, so I might be biassed ;)
  - ci5er 6y ago
    That's a great point, and after re-reading your blog-piece, I'm not sure that point came through so clearly as you just declared it here. A LONG time ago, I used to use it (tcl/tk) to do quick-and-dirty apps on X-windowed Unix boxes and port them to Windows without really knowing much about Windows. (That was handy!) And Expect blew me away back in the day of distributed systems management (I'm more of a programmer than a sys-admin, so I guess it would even be more important to those folks?). The whole "There is no math, only strings" thing, still irritates me to this day, but I suspect you are right - this might be tied to the simplicity and strengths. IDK. Food for though. Interesting piece. I think that I'm the only person I know that still dabbles in TCL after about 15~20 years ago (maybe I need to get out more), but it certainly rocks where it rocks! It is always surprising and pleasant to see a modern piece on it.
- ufo 6y ago
  What made Tcl click for me was thinking that it is basically shell/Bash, except that it's a coherent and sensible design. Just like an unix shell, everything is a string and you don't need to use "double" "quotes" "everywhere" "like" "this". However, in almost every part of the language, the way that Tcl does it is saner than the way the unix shell does it. The infinitude of footguns of Unix shell make us discount it as a serious programming language but Tcl shows that it doesn't have to be that bad :)
  - a1369209993 6y ago
    TBF, half of the supposed footguns are people not understanding the difference between a command shell and a scripting language and trying to write code as if they were using the latter[1], and the other half are defects of specific shell languages rather than shell programming in general[0], but the lack of a decent implementation kind of hamstrings the latter defence. 0: There is no reason why a shell couldn't fix bugs like: $ echo "$X" * $ echo $X foo.txt bar.mp4 it's just that none of the common ones do. 1: especially the incessant stupidity about adding type information to pipes, as if grep were a function rather than the arbitrary binary file /bin/grep
    - fanf2 6y ago
      The Plan 9 `rc` shell is a bit neater than typical Unix shells
- J-Kuhn 6y ago
  If you want to automate stuff on windows with tcl, twapi is great. I prefer Tcl with twapi over AutoHotkey.
pmoriarty 6y ago
In the Lisp world one often hears disdain for strings, and advice to get one's data in to some other representation so that it's safer, more expressive, and easier to work with. Coming from that background, it's interesting to hear of TCL (which I do not personally know how to program in) embracing strings. It would be interesting to read an article that goes in to some depth about the sorts of useful things that TCL's focus on strings makes possible or easy that would be difficult or unnatural to do in other languages.
- kevin_thibedeau 6y ago
  Tcl hasn't been string focused since 8.0 was released 20 years ago. Tcl objects are convertible to and from strings. That conversion can be deferred so a string representation hangs around but it still only uses strings as needed. Nobody says Lisp is string based because everything can be printed as an s-expr.
  - isr 6y ago
    Umm, sorry, no. First of all, lisp sexps have nothing to do with strings (which is why noone says that), whereas in tcl, every data structure has something to do with strings. In tcl, semantically, everything is a string. Yes, the native internal representations of compound structures like lists and dicts are actually very efficient, but you can refer to those structures as if they were a string at any point. And that will often cause the internal representation to switch to a string, and dump the more efficient "native" rep aside. And that can happen when you don't really intend for it to happen (the infamouse "shimmering" problem). Thats the biggest flaw I've found in years of hacking with tcl. It makes it hard to write funcs which take polymorphic data types. Is this a list of lists (where each sublist contains strings) or a list of strings (where each string may have whitespace) You end up creating your own dynamic typing system sometimes. I know I have, and so have others (see the wiki). There is SO much to love about tcl. It really is a lisp smashed into shell. And its so dynamic that you can do really powerful things in it. Its really a lisp,, where the standard data structure is the string, not a linked list. And any func can be an f-expr (basically, sort of a runtime macro, which older lisps used to have). I had a lot of fun redoing things like quasiquote (from lisp) in tcl. Yes, you really can generate tcl code as a template rather than manipulating strings. Combine some sort of diy tagging system with ensembles (so that your code will run specialised funcs all automatically chosen based on your initial tag name). The OO system is basically a toolbox for building any kind of OO system you want on top of it (almost akin to CLOS-inspired systems, in that regard) Stackable io channels so that you can build a virtual filesystem with a various features all composed together (FUSE-like done beautifully, from a scripting lang perspective) Great stuff. It really is a lisp/shell kind of thing, but sometimes its so dynamic that it shoots itself in the foot (shimmering, etc). I wish they had decided to dump backwards compatibility post 8.0, and tried addressing some of horrible warts in the language and runtime, eg: - the syntax rules are simple, but result in non-trivial code looking F UGLY (emphasis on the F). A couple of extensions to that syntax would have made the world of difference. How much more complicated would, say, 15 syntax rules be instead of 12? - shimmering. NO. Stop it. - not everything makes sense as a string rep (filehandles?) - the standard commandset (really each is a DSL in its own right) needed to be revised long ago so that they were more consistent with each other (contrast list cmds with others) Basically, maintaining backwards compatibility has killed tcl, even though it has so many nice features and potential greatness hidden inside. (eg: jimtcl, a hidden gem) Ok, I'm ranting now, I'll stop :-)
rcurry 6y ago
I was introduced to TCL/TK one summer when I was working at Sandia National Labs. I had been mostly doing C and ASM for the first part of my career, but the department I was contracted to was going through a dry spell in terms of funding so I got moved over to work with the GPS folks. I had never worked with TCL/TK before, and it was just such a guilty pleasure - you could slam out just about anything with it, in like no time. "Oh, you need to create a system with user-customizable dashboards for satellite telemetry? No problem, give me a few days..." I only worked with it for a few months, but it was some of the best fun I ever had writing code. I guess I feel the same way about react and node.js these days, but TCL/TK was ahead of its time.
- takeda 6y ago
  I used Tcl (I didn't really used Tk), and I really liked how the language had no statements and everything was a function/procedure. I remember that in the past (I think currently not needed since now it is built in), you could implement yourself try-catch-finally and would work like rest of the language without feeling like it was hacked through use of macros. Edit: Here it is: https://code.activestate.com/recipes/68396-try-catch-finally/ https://code.activestate.com/recipes/68396-try-catch-finally... not needed now since latest version has it built in.
  - sokoloff 6y ago
    upvar and uplevel were mind-blowing to me when I first learned tcl. It was relatively easy to derive new constructs that felt like part of the language.
  - paulwal 6y ago
    http://tcl.tk/man/tcl8.6/TclCmd/try.htm http://tcl.tk/man/tcl8.6/TclCmd/try.htm
zests 6y ago
I wish I had an excuse to really learn TCL. I've used it here and there but have never had an excuse to dive deep.
- bityard 6y ago
  I haven't written any Tcl in years but one of the things I liked about it was that it's not deep at all. Very simple rules, with enough flexibility built-in to (usually) make it do what you want.
  - MaxBarraclough 6y ago
    Sounds like the Forth philosophy.
  - zests 6y ago
    I want to get to the point where I'm comfortable using what makes Tcl special like uplevel/upvar. I can use it as a basic scripting language but I don't really grok what makes it special. Its like knowing how to use lisp but not knowing how macros work. Funnily enough this is actually where I am now with lisp.
- qznc 6y ago
  I think it really makes sense if you want an interactive shell. In contrast to most other languages, you need no parens or other fancy sigils for normal commands. A classic use case is a debugger like gdb. What else, though?
- stevekemp 6y ago
  I think the core ideas behind TCL are so simple and self-consistent that getting "deep" isn't required so much. Instead it's just a case of using it. In the past I used TCL for "expect" and for the Tk graphical toolkit. I can't say I've written anything major in TCL, but I think that's a common-case. Most people use TCL because it is embedded in applications as a scripting language/DSL. When people express interest in TCL I usually point them at antirez's simple writeup which gets a lot of the basics shown of in a simple manner: http://antirez.com/articoli/tclmisunderstood.html http://antirez.com/articoli/tclmisunderstood.html
rwmj 6y ago
Having not used Tcl since the 90s, I recently wrote some small graphical scripts in Tcl, basically tailing a text file, parsing the data, and producing a live animation[1]. The project was successful, but also reminded me about what I disliked about the language in 1994: As long as what you are doing is supported by the core language, it's "fine", but if you need to use an external library or need to do something beyond what the core does, it becomes quite tedious or even impossible. Also structured data is really badly handled. The article mentions defining your own operators and control flow, but is that something you ever really need? (Yes, occasionally, but not very often) I believe now as then that the great contribution of Tcl was Tk (the graphical toolkit), which is fantastic and has bindings in other languages. I really wish GIMP had used Tk and improved it rather than inventing Gtk which is inferior in most ways. Maybe this is all because I'm doing it wrong, writing scripts, and I should stick to its original purpose as an extension language, but it's easy enough to add C extensions to Lua or Python, and at some point you may end up writing a significant sized extension and the language will matter. [1] http://git.annexia.org/?p=libguestfs-talks.git;a=tree;f=2019-fosdem/nbdview http://git.annexia.org/?p=libguestfs-talks.git;a=tree;f=2019...
- cafard 6y ago
  It has been a long time since I fooled with Tcl, but in my recollection writing a function to call an external library wasn't that bad.
  - rwmj 6y ago
    Where Tcl is nice is embedding the Tcl interpreter in a C main program. Lua also does this well. This is the oft-overlooked embedding case which can be difficult in other languages (compared to the normal case where you start out in language X and need to call into a C function to do something low level). For example in Python the embedding case is tricky and lightly documented, and with only a semi-stable API which has changed under us a few times. In nbdkit we do a lot of language embedding (https://github.com/libguestfs/nbdkit/tree/master/plugins https://github.com/libguestfs/nbdkit/tree/master/plugins) including Tcl, Lua, Python and many others.
- 6y ago
forinti 6y ago
It's really nice that you can make an application with a GUI that runs on Linux and that you can also make it into an executable for Windows using Freewrap.
- MaxBarraclough 6y ago
  Sure, but that can be done in C++/Java/Python too. The real question is about the merit of the Tcl language.
  - forinti 6y ago
    Your executable will only be about 8MB plus the size of your source code. You definitely can't do that with Java; probably can't do it with Python either.
aduitsis 6y ago
What clarity of thought! The article gets the point across in just a few concise paragraphs, wholly enjoyable. This is especially refreshing in an era where many similarly themed blog posts are 3-4 times bigger, and full of tangential and confusing rumblings. Many thanks to the author!
J-Kuhn 6y ago
If someone asks me of a small snippet that describes some fundamental thing about TCL, I will respond with this: set a puts $a "Hello World" A command is just a list. Substitution is done before executing it. That's why [set] requires the variable name, not $variable.
- deleted 6y ago
  [deleted]
- adwn 6y ago
  Python: a = print a("Hello World") Rust: fn puts(s: &str) { println!("{}", s); } let a = puts; a("Hello World"); C++: #include <cstdio> auto a = puts; a("Hello World"); Also: every FP language ever. How is that a fundamental thing about TCL? Also probably all shell scripting languages, like Bash: a=echo $a Hello World
  - gecko 6y ago
    The way I'm used to seeing the GP's example made is set a pu set b ts $a$b "Hello!" which I think does a better job showing how the mixture of strings with interpolation allows for some slightly unexpected things.
    - Twisol 6y ago
      Would it be fair to call this a kind of "pervasive eval"?
      - artemonster 6y ago
        you've misspelled "evil" ;)
    - adwn 6y ago
      Yes, you're probably right. Frankly, I'd rather not have this kind or error-prone behavior in my programming languages, not even when scripting. It makes proper handling of strings hard and cumbersome (as evidenced by a lot of software that can't handle spaces in file names because it's calling scripts written in sh or bash), and I don't get the Tcl love professed in the comments here.
triska 6y ago
Tcl is awesome, thank you for sharing this! The design of Tcl is indeed simple and elegant. For example, check out the Tcl man page linked in the article: https://www.tcl.tk/man/tcl8.6/TclCmd/Tcl.htm https://www.tcl.tk/man/tcl8.6/TclCmd/Tcl.htm The 12 stated rules suffice to define the syntax and semantics of the language. And indeed, the Tcl/Tk tandem is great for building applications with convenient graphical user interfaces!
fuball63 6y ago
I love TCL. The author points out my favorite aspect: "it has a radical minimalism". I use it for hobby projects because I work in Python all day professionally and like to mix it up a little in my free time. It feels very different but inhabits the same use case space. That being said, here are some interesting things that tripped me up: - using expr for arithmetic. The author mentions it, and it is cumbersome, but it also exemplifies what makes TCL special - upvar for pass by reference. TCL does pass by reference by the command upvar, which says "take the variable named x in the scope above and assign it to the variable y in this scope". Confusing at first but a nice way to have pass by reference in a dynamic language - docs are hard to read sometimes. The manual and tutorial for TCL are fantastic; the wiki is a little hard to read sometimes. The pages kinda seem like conversations, with authors weighing in on an article and tagging their names to their comments. - lack of structured data. Saw another commenter posted this, and its something I wish TCL had better out of the box support for. The addition if dict was huge. The good news though: it's extremely easy to build a new command set to build a data structure out of dicts. Despite all of this I'm a big fan of TCL. I try to tell as many people I can about it, because it really feels like a breath of fresh air compared to my day job Python. It allows you to be creative (and reckless!) with its power. Edit: going to post the tutorial because it's so essential to getting started: https://tcl.tk/man/tcl8.5/tutorial/Tcl0.html https://tcl.tk/man/tcl8.5/tutorial/Tcl0.html
- _ph_ 6y ago
  In newer TCL (8.5+) you can import mathop to get the typical operators as functions so that you do no longer need "expr".
  - fuball63 6y ago
    Does that happen automatically in some cases? I think I'm on 8.6 and I'm pretty sure I forgot the expr and it worked OK. Could have been a string operation or something, I don't have the code to check on hand.
    - suyjuris 6y ago
mkovach 6y ago
I love TCL, but using it since 7.6. Although now it is mainly for personal scripts and developing proof of concept scripts for work. If fact in 1999 I used TCL (and Expect) on an ISP I worked for to run various tests checking for Year 2K issues and we used the same framework for patching and system building. Talked to somebody I worked with at that place recently, he had found a bit of the old application, and we noticed we have a pretty good Ansible base written in it. I also use it to write fairly easy DSL languages for various things, package them as tclkits, and have binaries that can be run on various machines.
a_lieb 6y ago
The easiest way to think about Tcl is simply, "it's a Lisp, but with strings instead of lists." It turns out that when you make a language like that, you end up something where your code looks and feels like a list of commands (much like a shell script) but is also capable of doing "real" programming stuff where needed without much pain. The test suite for SQLite is (still!) written in Tcl, I think partly for this reason. You probably wouldn't want to write a test suite in bash, but you don't quite get that feeling of "it's just a list of commands."
7thaccount 6y ago
I've found TCL to be pretty pleasant on Windows. It is pretty simple and I love building procedures that can be run as commands as it models my thought process better. I like that it is tiny, but very powerful behind the scenes with some very neat features.
AstroJetson 6y ago
I've been a TCL fan since the mid 1990's. We used TCL as our web server / scripting setup. We were able to attach to our IBM mainframe and deliver custom pages to all of our customers. TCL is still the fastest way for me to make scripts. And as someone else posted, EXPECT was a great tool for testing applications and doing some basic automation. I laugh when the new consultants go "Robot Process Automation" RPA is the wave of the future, I've been doing that for two decades.
unemphysbro 6y ago
Here's a fun little quirk in TCL that cost me about a day of debugging. An unmatched bracket in a comment, depending on the placement, can cause an error. :) https://wiki.tcl-lang.org/page/Why+can+I+not+place+unmatched+braces+in+Tcl+comments https://wiki.tcl-lang.org/page/Why+can+I+not+place+unmatched...
na85 6y ago
For me, Tcl was always just "that thing you had to learn to script your eggdrop" and I always found the esoteric nature of Tcl to be at odds with its claims of being a silent, behind-the-scenes enabler embedded into thousands of products. I suppose I have no reason to doubt the website, but was Tcl really as widespread as claimed? And is there any reason to reach for Tcl today when lua and guile exist?
- bch 6y ago
  Tcl is at the core of F5 (bigip)[0] and A10[1] network edge devices, tea leaf traffic monitoring [2], gnu gcc test suite[3], big finance tools[4], and very large computer management [5], for starters. One could go on with examples of industrial and scientific controls, Hollywood gfx, and EDA (electronic design automation) that may have contributed to the design of whatever device you’re reading this with, etc, but it’d be a long list. It’s battle-hardened, which is important, but it’s also fun, which is important too. [0] https://devcentral.f5.com/s/articles/irules-concepts-tcl-the-how-and-why https://devcentral.f5.com/s/articles/irules-concepts-tcl-the... [1] https://www.a10networks.com/blog/aflex-tutorial/ https://www.a10networks.com/blog/aflex-tutorial/ [2] http://www-01.ibm.com/software/info/tealeaf/ http://www-01.ibm.com/software/info/tealeaf/ [3] https://en.wikipedia.org/wiki/DejaGnu https://en.wikipedia.org/wiki/DejaGnu [4] https://www.fidessa.com/products/training/training-courses https://www.fidessa.com/products/training/training-courses [5] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_slides_2015.pptx https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_slides_201...
  - blacksqr 6y ago
    Nuclear power plant management... [0] Embedded medical device software ... [1] i.e., when the consequences of failure are just too great, a lot of people don't dare pass up Tcl. [0] https://wiki.tcl-lang.org/page/COMPANY%3A+KKG https://wiki.tcl-lang.org/page/COMPANY%3A+KKG [1] https://www.incubelabs.com/ https://www.incubelabs.com/
    - andi999 6y ago
      It was the visualization of the simulator... consequence of failure doesnt seem too great. Btw how does tcl allocate memory? (So is it real time compliant?)
SwSwinger 6y ago
My first job was a telco equipment manufacturer that needed to add a user-facing DSL to their embedded internet OS (the GenX iOS). I later used it with Expect to write a basic automated integration testing suite for the network equipment's CLI. I really disliked TCL at first because the syntax seemed so arbitrary compared to other languages. It's only when you realize that TCL is actually more pure than other languages that you begin to appreciate its beauty. When the man page starts with "The following [12] rules define the syntax and semantics of the Tcl language:", they mean it. Those are the 12 rules. They are followed exactly and in order every time. Beyond those 12 rules, the rest is really DSL to make it look more like a normal programming language. It's very easy to code an entire TCL interpreter in 1000 lines of code. By coding in such a pure style, it made me appreciate how much the quirks of other languages are fundamentally designed to help programmers and not create frustration, which is how I always experienced all the "gotchas" I had to debug.
kanox 6y ago
Unpopular opinon: I've used TCL and didn't like it and wouldn't recommend anyone use it. The shell-like "everything is a string" is seductive at first but in practice you spend way too much time messing up your quoting. It's similar to how sometimes people suggest dropping yaml/json for a "simple ini file": it quickly breaks down and you end up with a custom ill-defined mechanism for nesting values. TCL can handle more than just string variables: you have arrays, dicts and a bazillion libraries implementing object orientation. The result is that manipulating structured data is still more awkward than in any other modern language, except perhaps shell scripting. Unless you're interfacing with a legacy or third-party system please don't use it. If you think you need expect please just use pexpect.
- jeffh 6y ago
  I suspect your experience with Tcl is a bit old. Tcl finally standardized on a single core OO library several years ago. The quoting issues can be a pain, but if you learn to treat it like a language rather than extended shell, you learn the tricks to avoid escaping/quoting issues.
  - kanox 6y ago
    My experience with TCL is from scripting tools which picked it as an extension language many years ago. Tools like that have their own object-like systems and are likely not going to migrate, ever. Maybe if TCL had a single standard OO library in the late 90s it would have been more successful? But I still think that languages with native OO constructs are much better that a shell-like string-oriented interpreter.
- elvis70 6y ago
  I think you haven't used it enough to appreciate its true value.
  - flubert 6y ago
    >...If, in order to "really" enter a programming culture, I need to both "be solving a significant real problem in the real world" and exercising "the freedom to change the language, the compiler, the OS or even the hardware design", then there are very few options for entering this culture indeed. https://yosefk.com/blog/my-history-with-forth-stack-machines.html https://yosefk.com/blog/my-history-with-forth-stack-machines...
myspy 6y ago
Had a look into it due to work and I don‘t like it. Code was hard to read and badly organized. I can‘t remember if it was the languages fault. Wanted to add a testing framework to refactor code. Didn‘t find something good though.
- andrewshadura 6y ago
  A lot of people write Tcl as if it were C or Bash without understanding the language or its philosophy. That, unfortunately, leads to badly written code like that you've seen
birdyrooster 6y ago
How about lets move to jsonnet and call it a day
dmux 6y ago
For those who are web-devs, I'd highly recommend you take a look at Wapp - A Web-Application Framework for TCL [0] by D. Richard Hipp (of SQLite fame). It's simple enough to start with and the source code is a great intro to TCL. [0] https://wapp.tcl.tk/home/doc/trunk/README.md https://wapp.tcl.tk/home/doc/trunk/README.md
lizknope 6y ago
If you work or plan to work in the semiconductor industry with EDA tools (Electronic Design Automation) then Tcl is very popular because it is the built in scripting language for many tools from Cadence and Synopsys. Many companies end up basing a lot of their internal CAD flow on Tcl because it fits together well as wrappers for the commercial software.
nix23 6y ago
For your future work: If someone with 40+ years experience in the industry or gray/white/no hair says something about a technology trust him/her, after 8 month you can agree or not...but the chance is really high you will. And the big joke, old people are not IN because they never heard of "Ruby on Rails", but they already had experience with something like it, and in the long run it just don't work.
sigzero 6y ago
I really enjoy Tcl. I just do. It's hard to explain. I like the quirkiness. I like the community. I watch the emails on the core developers list and all the thought that goes into it.
dustractor 6y ago
My only experience with tcl is through tkinter but out of all the GUIs I've ever written code in, it's the one I prefer. Strange way to learn a language, that. The only complete documentation is on the tcl side of things, so you have to switch between partial docs on the python.org site, partial (and opinionated) docs elsewhere, the only good site is now defunct, and so yeah, if you are determined to figure out tkinter you have to rely on docs in another language and then just -- I don't know how to say this, do the obvious thing, whatever seems most pythonic, most lazy, that is basically how it is intended to be used. Case in point: The way you that you hook up a stringvar to a listbox -- to have multiple items, you just ... set the string to a list. Or put newlines in the string. Simple stuff like that, or the ease with which you can make a simple interface with buttons whose command doesn't have to live in three different locations, you can just write a lambda and be done... but wait! That's how you're supposed to do it? It's not breaking rules? My curiosity about this tcl thing has been growing over the years, and I think this article has given me the push to actually try it on its own.
coldtea 6y ago
Here's a fun feature of tcl. set a "pu" set b "ts" $a$b "Hello World" ---> Hello World In Python terms, this would be as if Python could do: a = "pr" b = "int" a+b "Hello World" ---> Hello World Who needs eval?
- projektfu 6y ago
  Reminds me of foxpro macros
- Spivak 6y ago
  And if anyone didn’t know already this is the behavior of every shell as well. Resolving variables to values is done before the line is executed.
m463 6y ago
I worked on an embedded linux project years ago and perl or python would not work/fit. But tcl would and did.
delvin0 6y ago
Awesome.. gitk is written with Tcl too. More details: final title of https://medium.com/swlh/impressive-sources-codes-that-every-developer-should-see-b68028b36da5 https://medium.com/swlh/impressive-sources-codes-that-every-...
fithisux 6y ago
Tcl has saved my work in the past. I could create very quickly GUI command line programs for my reasearch. Now that I am exposed a bit to Lisp, I wish Tcl also supported a Lisp syntax too. In any case a very powerful language that is easy to learn and use.
Tomte 6y ago
I'm intrigued by Starpack/StarKit, the virtual file system and virtual time. Never used Tcl, so far, but I'm thinking about sacrificing a weekend to playing with it.
themadsens 6y ago
The biggest gripe I have with modern (ie. the post-Sun era) Tcl is the steaming mess that are channels and their encodings. Good luck trying to do anything 8-bit clean with those. For a simpler, cleaner alternative, you might want to take a look at antirez's jim tcl
- dvdkhlng 6y ago
  I have the exact opposite experience WRT Tcl channels when compared to other languages. Handling binary data is pretty trivial, e.g. to read a full binary file into a binary string, you do: set h [open "filename.bin" r] fconfigure $h -encoding binary -translation binary set data [read $h] Then you even have a fantastic way to operate on low-level binary data of any endianness using Tcl's binary scan /binary format instructions [1] (basically what Javascript later invented as DataView). Tcl was one of the first languages I knew that properly and consistently supported multibyte text throughout the full language, including in Tk GUIs. I.e. writing a cross-platform GUI that could handle Japanese character input/output basically "just worked". You could even read ShiftJIS or ISO encodings of japanese text, which was at the time a prerequisite as Japanese Windows versions were non-unicode (everything done in ShiftJIS AFAIR). [edit] here is a real-world example of a trivial script handling binary data [2]: reading binary RGBA 4 bytes/pixel image data and outputting RGB 3b/pixel into a pipe that finally outputs a .PNG image. It's difficult to find a programming language that can do that in less lines and with more clarity. [1] https://wiki.tcl-lang.org/page/binary+scan https://wiki.tcl-lang.org/page/binary+scan [2] https://stech.muecke.pw/opensvn/free/trunk/dkbin/nn-fbtopng https://stech.muecke.pw/opensvn/free/trunk/dkbin/nn-fbtopng
  - themadsens 6y ago
    Yes, I see your point. I can't remember the context that bit me anymore, but I think it had to with being unable to change the defaults with fconfigure for some reason, the channel being implicit or somesuch .
- marttt 6y ago
  I got curious, so here's a link to Jim Tcl: http://jim.tcl.tk/index.html/doc/www/www/ http://jim.tcl.tk/index.html/doc/www/www/
physicsguy 6y ago
I used Tcl by virtue of a software package in the scientific domain I work in called OOMMF which is old but a stalwart and very reliable. I find it an odd language. But the one thing that I think is very cool, is that it's very very simple to get a minimal Tcl interpreter (partcl) that can be embedded into a C/C++ application. It also still comes bundled in to Python for the Tkinter framework. You can even use it in Jupyter Notebooks now
analognoise 6y ago
Tcl is amazing just for Tk's Canvas alone. All other sins are forgiven. I've never found something that easy to use. Tkinter (Tk through Python) is awesome. Since this is HN, if somebody knows a scene graph canvas that's even better and as easy to use, please let me know. I'm primarily interested in EDA (so not games).

167 points by blacksqr 6y ago

While TCL is definitely an odd language, with plenty to alienate the modern programmer, there are some killer applications for it. For me the thing that sucked me in was tcl/expect a simple but powerful tool to control CLI's. At one point in my life I was tasked with managing over 3000 various network devices, I couldn't have done it without TCL/Expect!

cmacleod4 6y ago
I'm the blogger here - I think my main point is that the perceived oddness is inextricably linked to Tcl's strengths.
- jascii 6y ago
  I think that goes for a lot of languages that are now often considered "odd". There is something about how an elegant and simple paradigm can help you think about a problem! The first "higer" language I ever learned was Forth, and I never quite got to terms with infix notation, so I might be biassed ;)
- ci5er 6y ago
  That's a great point, and after re-reading your blog-piece, I'm not sure that point came through so clearly as you just declared it here. A LONG time ago, I used to use it (tcl/tk) to do quick-and-dirty apps on X-windowed Unix boxes and port them to Windows without really knowing much about Windows. (That was handy!) And Expect blew me away back in the day of distributed systems management (I'm more of a programmer than a sys-admin, so I guess it would even be more important to those folks?). The whole "There is no math, only strings" thing, still irritates me to this day, but I suspect you are right - this might be tied to the simplicity and strengths. IDK. Food for though. Interesting piece. I think that I'm the only person I know that still dabbles in TCL after about 15~20 years ago (maybe I need to get out more), but it certainly rocks where it rocks! It is always surprising and pleasant to see a modern piece on it.
ufo 6y ago
What made Tcl click for me was thinking that it is basically shell/Bash, except that it's a coherent and sensible design. Just like an unix shell, everything is a string and you don't need to use "double" "quotes" "everywhere" "like" "this". However, in almost every part of the language, the way that Tcl does it is saner than the way the unix shell does it. The infinitude of footguns of Unix shell make us discount it as a serious programming language but Tcl shows that it doesn't have to be that bad :)
- a1369209993 6y ago
  TBF, half of the supposed footguns are people not understanding the difference between a command shell and a scripting language and trying to write code as if they were using the latter[1], and the other half are defects of specific shell languages rather than shell programming in general[0], but the lack of a decent implementation kind of hamstrings the latter defence. 0: There is no reason why a shell couldn't fix bugs like: $ echo "$X" * $ echo $X foo.txt bar.mp4 it's just that none of the common ones do. 1: especially the incessant stupidity about adding type information to pipes, as if grep were a function rather than the arbitrary binary file /bin/grep
  - fanf2 6y ago
    The Plan 9 `rc` shell is a bit neater than typical Unix shells
J-Kuhn 6y ago
If you want to automate stuff on windows with tcl, twapi is great. I prefer Tcl with twapi over AutoHotkey.

pmoriarty 6y ago

In the Lisp world one often hears disdain for strings, and advice to get one's data in to some other representation so that it's safer, more expressive, and easier to work with. Coming from that background, it's interesting to hear of TCL (which I do not personally know how to program in) embracing strings. It would be interesting to read an article that goes in to some depth about the sorts of useful things that TCL's focus on strings makes possible or easy that would be difficult or unnatural to do in other languages.

kevin_thibedeau 6y ago
Tcl hasn't been string focused since 8.0 was released 20 years ago. Tcl objects are convertible to and from strings. That conversion can be deferred so a string representation hangs around but it still only uses strings as needed. Nobody says Lisp is string based because everything can be printed as an s-expr.
- isr 6y ago
  Umm, sorry, no. First of all, lisp sexps have nothing to do with strings (which is why noone says that), whereas in tcl, every data structure has something to do with strings. In tcl, semantically, everything is a string. Yes, the native internal representations of compound structures like lists and dicts are actually very efficient, but you can refer to those structures as if they were a string at any point. And that will often cause the internal representation to switch to a string, and dump the more efficient "native" rep aside. And that can happen when you don't really intend for it to happen (the infamouse "shimmering" problem). Thats the biggest flaw I've found in years of hacking with tcl. It makes it hard to write funcs which take polymorphic data types. Is this a list of lists (where each sublist contains strings) or a list of strings (where each string may have whitespace) You end up creating your own dynamic typing system sometimes. I know I have, and so have others (see the wiki). There is SO much to love about tcl. It really is a lisp smashed into shell. And its so dynamic that you can do really powerful things in it. Its really a lisp,, where the standard data structure is the string, not a linked list. And any func can be an f-expr (basically, sort of a runtime macro, which older lisps used to have). I had a lot of fun redoing things like quasiquote (from lisp) in tcl. Yes, you really can generate tcl code as a template rather than manipulating strings. Combine some sort of diy tagging system with ensembles (so that your code will run specialised funcs all automatically chosen based on your initial tag name). The OO system is basically a toolbox for building any kind of OO system you want on top of it (almost akin to CLOS-inspired systems, in that regard) Stackable io channels so that you can build a virtual filesystem with a various features all composed together (FUSE-like done beautifully, from a scripting lang perspective) Great stuff. It really is a lisp/shell kind of thing, but sometimes its so dynamic that it shoots itself in the foot (shimmering, etc). I wish they had decided to dump backwards compatibility post 8.0, and tried addressing some of horrible warts in the language and runtime, eg: - the syntax rules are simple, but result in non-trivial code looking F UGLY (emphasis on the F). A couple of extensions to that syntax would have made the world of difference. How much more complicated would, say, 15 syntax rules be instead of 12? - shimmering. NO. Stop it. - not everything makes sense as a string rep (filehandles?) - the standard commandset (really each is a DSL in its own right) needed to be revised long ago so that they were more consistent with each other (contrast list cmds with others) Basically, maintaining backwards compatibility has killed tcl, even though it has so many nice features and potential greatness hidden inside. (eg: jimtcl, a hidden gem) Ok, I'm ranting now, I'll stop :-)

rcurry 6y ago

I was introduced to TCL/TK one summer when I was working at Sandia National Labs. I had been mostly doing C and ASM for the first part of my career, but the department I was contracted to was going through a dry spell in terms of funding so I got moved over to work with the GPS folks. I had never worked with TCL/TK before, and it was just such a guilty pleasure - you could slam out just about anything with it, in like no time. "Oh, you need to create a system with user-customizable dashboards for satellite telemetry? No problem, give me a few days..." I only worked with it for a few months, but it was some of the best fun I ever had writing code. I guess I feel the same way about react and node.js these days, but TCL/TK was ahead of its time.

takeda 6y ago
I used Tcl (I didn't really used Tk), and I really liked how the language had no statements and everything was a function/procedure. I remember that in the past (I think currently not needed since now it is built in), you could implement yourself try-catch-finally and would work like rest of the language without feeling like it was hacked through use of macros. Edit: Here it is: https://code.activestate.com/recipes/68396-try-catch-finally/ https://code.activestate.com/recipes/68396-try-catch-finally... not needed now since latest version has it built in.
- sokoloff 6y ago
  upvar and uplevel were mind-blowing to me when I first learned tcl. It was relatively easy to derive new constructs that felt like part of the language.
- paulwal 6y ago
  http://tcl.tk/man/tcl8.6/TclCmd/try.htm http://tcl.tk/man/tcl8.6/TclCmd/try.htm

zests 6y ago

I wish I had an excuse to really learn TCL. I've used it here and there but have never had an excuse to dive deep.

bityard 6y ago
I haven't written any Tcl in years but one of the things I liked about it was that it's not deep at all. Very simple rules, with enough flexibility built-in to (usually) make it do what you want.
- MaxBarraclough 6y ago
  Sounds like the Forth philosophy.
- zests 6y ago
  I want to get to the point where I'm comfortable using what makes Tcl special like uplevel/upvar. I can use it as a basic scripting language but I don't really grok what makes it special. Its like knowing how to use lisp but not knowing how macros work. Funnily enough this is actually where I am now with lisp.
qznc 6y ago
I think it really makes sense if you want an interactive shell. In contrast to most other languages, you need no parens or other fancy sigils for normal commands. A classic use case is a debugger like gdb. What else, though?
stevekemp 6y ago
I think the core ideas behind TCL are so simple and self-consistent that getting "deep" isn't required so much. Instead it's just a case of using it. In the past I used TCL for "expect" and for the Tk graphical toolkit. I can't say I've written anything major in TCL, but I think that's a common-case. Most people use TCL because it is embedded in applications as a scripting language/DSL. When people express interest in TCL I usually point them at antirez's simple writeup which gets a lot of the basics shown of in a simple manner: http://antirez.com/articoli/tclmisunderstood.html http://antirez.com/articoli/tclmisunderstood.html

rwmj 6y ago

Having not used Tcl since the 90s, I recently wrote some small graphical scripts in Tcl, basically tailing a text file, parsing the data, and producing a live animation[1]. The project was successful, but also reminded me about what I disliked about the language in 1994: As long as what you are doing is supported by the core language, it's "fine", but if you need to use an external library or need to do something beyond what the core does, it becomes quite tedious or even impossible. Also structured data is really badly handled. The article mentions defining your own operators and control flow, but is that something you ever really need? (Yes, occasionally, but not very often) I believe now as then that the great contribution of Tcl was Tk (the graphical toolkit), which is fantastic and has bindings in other languages. I really wish GIMP had used Tk and improved it rather than inventing Gtk which is inferior in most ways. Maybe this is all because I'm doing it wrong, writing scripts, and I should stick to its original purpose as an extension language, but it's easy enough to add C extensions to Lua or Python, and at some point you may end up writing a significant sized extension and the language will matter. [1] http://git.annexia.org/?p=libguestfs-talks.git;a=tree;f=2019-fosdem/nbdview http://git.annexia.org/?p=libguestfs-talks.git;a=tree;f=2019...

cafard 6y ago
It has been a long time since I fooled with Tcl, but in my recollection writing a function to call an external library wasn't that bad.
- rwmj 6y ago
  Where Tcl is nice is embedding the Tcl interpreter in a C main program. Lua also does this well. This is the oft-overlooked embedding case which can be difficult in other languages (compared to the normal case where you start out in language X and need to call into a C function to do something low level). For example in Python the embedding case is tricky and lightly documented, and with only a semi-stable API which has changed under us a few times. In nbdkit we do a lot of language embedding (https://github.com/libguestfs/nbdkit/tree/master/plugins https://github.com/libguestfs/nbdkit/tree/master/plugins) including Tcl, Lua, Python and many others.
6y ago

forinti 6y ago

It's really nice that you can make an application with a GUI that runs on Linux and that you can also make it into an executable for Windows using Freewrap.

MaxBarraclough 6y ago
Sure, but that can be done in C++/Java/Python too. The real question is about the merit of the Tcl language.
- forinti 6y ago
  Your executable will only be about 8MB plus the size of your source code. You definitely can't do that with Java; probably can't do it with Python either.

aduitsis 6y ago

What clarity of thought! The article gets the point across in just a few concise paragraphs, wholly enjoyable. This is especially refreshing in an era where many similarly themed blog posts are 3-4 times bigger, and full of tangential and confusing rumblings. Many thanks to the author!

J-Kuhn 6y ago

If someone asks me of a small snippet that describes some fundamental thing about TCL, I will respond with this: set a puts $a "Hello World" A command is just a list. Substitution is done before executing it. That's why [set] requires the variable name, not $variable.

deleted 6y ago
[deleted]
adwn 6y ago
Python: a = print a("Hello World") Rust: fn puts(s: &str) { println!("{}", s); } let a = puts; a("Hello World"); C++: #include <cstdio> auto a = puts; a("Hello World"); Also: every FP language ever. How is that a fundamental thing about TCL? Also probably all shell scripting languages, like Bash: a=echo $a Hello World
- gecko 6y ago
  The way I'm used to seeing the GP's example made is set a pu set b ts $a$b "Hello!" which I think does a better job showing how the mixture of strings with interpolation allows for some slightly unexpected things.
  - Twisol 6y ago
    Would it be fair to call this a kind of "pervasive eval"?
    - artemonster 6y ago
      you've misspelled "evil" ;)
  - adwn 6y ago
    Yes, you're probably right. Frankly, I'd rather not have this kind or error-prone behavior in my programming languages, not even when scripting. It makes proper handling of strings hard and cumbersome (as evidenced by a lot of software that can't handle spaces in file names because it's calling scripts written in sh or bash), and I don't get the Tcl love professed in the comments here.

triska 6y ago

Tcl is awesome, thank you for sharing this! The design of Tcl is indeed simple and elegant. For example, check out the Tcl man page linked in the article: https://www.tcl.tk/man/tcl8.6/TclCmd/Tcl.htm https://www.tcl.tk/man/tcl8.6/TclCmd/Tcl.htm The 12 stated rules suffice to define the syntax and semantics of the language. And indeed, the Tcl/Tk tandem is great for building applications with convenient graphical user interfaces!

fuball63 6y ago

I love TCL. The author points out my favorite aspect: "it has a radical minimalism". I use it for hobby projects because I work in Python all day professionally and like to mix it up a little in my free time. It feels very different but inhabits the same use case space. That being said, here are some interesting things that tripped me up: - using expr for arithmetic. The author mentions it, and it is cumbersome, but it also exemplifies what makes TCL special - upvar for pass by reference. TCL does pass by reference by the command upvar, which says "take the variable named x in the scope above and assign it to the variable y in this scope". Confusing at first but a nice way to have pass by reference in a dynamic language - docs are hard to read sometimes. The manual and tutorial for TCL are fantastic; the wiki is a little hard to read sometimes. The pages kinda seem like conversations, with authors weighing in on an article and tagging their names to their comments. - lack of structured data. Saw another commenter posted this, and its something I wish TCL had better out of the box support for. The addition if dict was huge. The good news though: it's extremely easy to build a new command set to build a data structure out of dicts. Despite all of this I'm a big fan of TCL. I try to tell as many people I can about it, because it really feels like a breath of fresh air compared to my day job Python. It allows you to be creative (and reckless!) with its power. Edit: going to post the tutorial because it's so essential to getting started: https://tcl.tk/man/tcl8.5/tutorial/Tcl0.html https://tcl.tk/man/tcl8.5/tutorial/Tcl0.html

_ph_ 6y ago
In newer TCL (8.5+) you can import mathop to get the typical operators as functions so that you do no longer need "expr".
- fuball63 6y ago
  Does that happen automatically in some cases? I think I'm on 8.6 and I'm pretty sure I forgot the expr and it worked OK. Could have been a string operation or something, I don't have the code to check on hand.
  - suyjuris 6y ago

mkovach 6y ago

I love TCL, but using it since 7.6. Although now it is mainly for personal scripts and developing proof of concept scripts for work. If fact in 1999 I used TCL (and Expect) on an ISP I worked for to run various tests checking for Year 2K issues and we used the same framework for patching and system building. Talked to somebody I worked with at that place recently, he had found a bit of the old application, and we noticed we have a pretty good Ansible base written in it. I also use it to write fairly easy DSL languages for various things, package them as tclkits, and have binaries that can be run on various machines.

a_lieb 6y ago

The easiest way to think about Tcl is simply, "it's a Lisp, but with strings instead of lists." It turns out that when you make a language like that, you end up something where your code looks and feels like a list of commands (much like a shell script) but is also capable of doing "real" programming stuff where needed without much pain. The test suite for SQLite is (still!) written in Tcl, I think partly for this reason. You probably wouldn't want to write a test suite in bash, but you don't quite get that feeling of "it's just a list of commands."

7thaccount 6y ago

I've found TCL to be pretty pleasant on Windows. It is pretty simple and I love building procedures that can be run as commands as it models my thought process better. I like that it is tiny, but very powerful behind the scenes with some very neat features.

AstroJetson 6y ago

I've been a TCL fan since the mid 1990's. We used TCL as our web server / scripting setup. We were able to attach to our IBM mainframe and deliver custom pages to all of our customers. TCL is still the fastest way for me to make scripts. And as someone else posted, EXPECT was a great tool for testing applications and doing some basic automation. I laugh when the new consultants go "Robot Process Automation" RPA is the wave of the future, I've been doing that for two decades.

unemphysbro 6y ago

Here's a fun little quirk in TCL that cost me about a day of debugging. An unmatched bracket in a comment, depending on the placement, can cause an error. :) https://wiki.tcl-lang.org/page/Why+can+I+not+place+unmatched+braces+in+Tcl+comments https://wiki.tcl-lang.org/page/Why+can+I+not+place+unmatched...

na85 6y ago

For me, Tcl was always just "that thing you had to learn to script your eggdrop" and I always found the esoteric nature of Tcl to be at odds with its claims of being a silent, behind-the-scenes enabler embedded into thousands of products. I suppose I have no reason to doubt the website, but was Tcl really as widespread as claimed? And is there any reason to reach for Tcl today when lua and guile exist?

bch 6y ago
Tcl is at the core of F5 (bigip)[0] and A10[1] network edge devices, tea leaf traffic monitoring [2], gnu gcc test suite[3], big finance tools[4], and very large computer management [5], for starters. One could go on with examples of industrial and scientific controls, Hollywood gfx, and EDA (electronic design automation) that may have contributed to the design of whatever device you’re reading this with, etc, but it’d be a long list. It’s battle-hardened, which is important, but it’s also fun, which is important too. [0] https://devcentral.f5.com/s/articles/irules-concepts-tcl-the-how-and-why https://devcentral.f5.com/s/articles/irules-concepts-tcl-the... [1] https://www.a10networks.com/blog/aflex-tutorial/ https://www.a10networks.com/blog/aflex-tutorial/ [2] http://www-01.ibm.com/software/info/tealeaf/ http://www-01.ibm.com/software/info/tealeaf/ [3] https://en.wikipedia.org/wiki/DejaGnu https://en.wikipedia.org/wiki/DejaGnu [4] https://www.fidessa.com/products/training/training-courses https://www.fidessa.com/products/training/training-courses [5] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_slides_2015.pptx https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_slides_201...
- blacksqr 6y ago
  Nuclear power plant management... [0] Embedded medical device software ... [1] i.e., when the consequences of failure are just too great, a lot of people don't dare pass up Tcl. [0] https://wiki.tcl-lang.org/page/COMPANY%3A+KKG https://wiki.tcl-lang.org/page/COMPANY%3A+KKG [1] https://www.incubelabs.com/ https://www.incubelabs.com/
  - andi999 6y ago
    It was the visualization of the simulator... consequence of failure doesnt seem too great. Btw how does tcl allocate memory? (So is it real time compliant?)

SwSwinger 6y ago

My first job was a telco equipment manufacturer that needed to add a user-facing DSL to their embedded internet OS (the GenX iOS). I later used it with Expect to write a basic automated integration testing suite for the network equipment's CLI. I really disliked TCL at first because the syntax seemed so arbitrary compared to other languages. It's only when you realize that TCL is actually more pure than other languages that you begin to appreciate its beauty. When the man page starts with "The following [12] rules define the syntax and semantics of the Tcl language:", they mean it. Those are the 12 rules. They are followed exactly and in order every time. Beyond those 12 rules, the rest is really DSL to make it look more like a normal programming language. It's very easy to code an entire TCL interpreter in 1000 lines of code. By coding in such a pure style, it made me appreciate how much the quirks of other languages are fundamentally designed to help programmers and not create frustration, which is how I always experienced all the "gotchas" I had to debug.

kanox 6y ago

Unpopular opinon: I've used TCL and didn't like it and wouldn't recommend anyone use it. The shell-like "everything is a string" is seductive at first but in practice you spend way too much time messing up your quoting. It's similar to how sometimes people suggest dropping yaml/json for a "simple ini file": it quickly breaks down and you end up with a custom ill-defined mechanism for nesting values. TCL can handle more than just string variables: you have arrays, dicts and a bazillion libraries implementing object orientation. The result is that manipulating structured data is still more awkward than in any other modern language, except perhaps shell scripting. Unless you're interfacing with a legacy or third-party system please don't use it. If you think you need expect please just use pexpect.

jeffh 6y ago
I suspect your experience with Tcl is a bit old. Tcl finally standardized on a single core OO library several years ago. The quoting issues can be a pain, but if you learn to treat it like a language rather than extended shell, you learn the tricks to avoid escaping/quoting issues.
- kanox 6y ago
  My experience with TCL is from scripting tools which picked it as an extension language many years ago. Tools like that have their own object-like systems and are likely not going to migrate, ever. Maybe if TCL had a single standard OO library in the late 90s it would have been more successful? But I still think that languages with native OO constructs are much better that a shell-like string-oriented interpreter.
elvis70 6y ago
I think you haven't used it enough to appreciate its true value.
- flubert 6y ago
  >...If, in order to "really" enter a programming culture, I need to both "be solving a significant real problem in the real world" and exercising "the freedom to change the language, the compiler, the OS or even the hardware design", then there are very few options for entering this culture indeed. https://yosefk.com/blog/my-history-with-forth-stack-machines.html https://yosefk.com/blog/my-history-with-forth-stack-machines...

myspy 6y ago

Had a look into it due to work and I don‘t like it. Code was hard to read and badly organized. I can‘t remember if it was the languages fault. Wanted to add a testing framework to refactor code. Didn‘t find something good though.

andrewshadura 6y ago
A lot of people write Tcl as if it were C or Bash without understanding the language or its philosophy. That, unfortunately, leads to badly written code like that you've seen

birdyrooster 6y ago

How about lets move to jsonnet and call it a day

dmux 6y ago

For those who are web-devs, I'd highly recommend you take a look at Wapp - A Web-Application Framework for TCL [0] by D. Richard Hipp (of SQLite fame). It's simple enough to start with and the source code is a great intro to TCL. [0] https://wapp.tcl.tk/home/doc/trunk/README.md https://wapp.tcl.tk/home/doc/trunk/README.md

lizknope 6y ago

If you work or plan to work in the semiconductor industry with EDA tools (Electronic Design Automation) then Tcl is very popular because it is the built in scripting language for many tools from Cadence and Synopsys. Many companies end up basing a lot of their internal CAD flow on Tcl because it fits together well as wrappers for the commercial software.

nix23 6y ago

For your future work: If someone with 40+ years experience in the industry or gray/white/no hair says something about a technology trust him/her, after 8 month you can agree or not...but the chance is really high you will. And the big joke, old people are not IN because they never heard of "Ruby on Rails", but they already had experience with something like it, and in the long run it just don't work.

sigzero 6y ago

I really enjoy Tcl. I just do. It's hard to explain. I like the quirkiness. I like the community. I watch the emails on the core developers list and all the thought that goes into it.

dustractor 6y ago

My only experience with tcl is through tkinter but out of all the GUIs I've ever written code in, it's the one I prefer. Strange way to learn a language, that. The only complete documentation is on the tcl side of things, so you have to switch between partial docs on the python.org site, partial (and opinionated) docs elsewhere, the only good site is now defunct, and so yeah, if you are determined to figure out tkinter you have to rely on docs in another language and then just -- I don't know how to say this, do the obvious thing, whatever seems most pythonic, most lazy, that is basically how it is intended to be used. Case in point: The way you that you hook up a stringvar to a listbox -- to have multiple items, you just ... set the string to a list. Or put newlines in the string. Simple stuff like that, or the ease with which you can make a simple interface with buttons whose command doesn't have to live in three different locations, you can just write a lambda and be done... but wait! That's how you're supposed to do it? It's not breaking rules? My curiosity about this tcl thing has been growing over the years, and I think this article has given me the push to actually try it on its own.

coldtea 6y ago

Here's a fun feature of tcl. set a "pu" set b "ts" $a$b "Hello World" ---> Hello World In Python terms, this would be as if Python could do: a = "pr" b = "int" a+b "Hello World" ---> Hello World Who needs eval?

projektfu 6y ago
Reminds me of foxpro macros
Spivak 6y ago
And if anyone didn’t know already this is the behavior of every shell as well. Resolving variables to values is done before the line is executed.

m463 6y ago

I worked on an embedded linux project years ago and perl or python would not work/fit. But tcl would and did.

delvin0 6y ago

Awesome.. gitk is written with Tcl too. More details: final title of https://medium.com/swlh/impressive-sources-codes-that-every-developer-should-see-b68028b36da5 https://medium.com/swlh/impressive-sources-codes-that-every-...

fithisux 6y ago

Tcl has saved my work in the past. I could create very quickly GUI command line programs for my reasearch. Now that I am exposed a bit to Lisp, I wish Tcl also supported a Lisp syntax too. In any case a very powerful language that is easy to learn and use.

Tomte 6y ago

I'm intrigued by Starpack/StarKit, the virtual file system and virtual time. Never used Tcl, so far, but I'm thinking about sacrificing a weekend to playing with it.

themadsens 6y ago

The biggest gripe I have with modern (ie. the post-Sun era) Tcl is the steaming mess that are channels and their encodings. Good luck trying to do anything 8-bit clean with those. For a simpler, cleaner alternative, you might want to take a look at antirez's jim tcl

dvdkhlng 6y ago
I have the exact opposite experience WRT Tcl channels when compared to other languages. Handling binary data is pretty trivial, e.g. to read a full binary file into a binary string, you do: set h [open "filename.bin" r] fconfigure $h -encoding binary -translation binary set data [read $h] Then you even have a fantastic way to operate on low-level binary data of any endianness using Tcl's binary scan /binary format instructions [1] (basically what Javascript later invented as DataView). Tcl was one of the first languages I knew that properly and consistently supported multibyte text throughout the full language, including in Tk GUIs. I.e. writing a cross-platform GUI that could handle Japanese character input/output basically "just worked". You could even read ShiftJIS or ISO encodings of japanese text, which was at the time a prerequisite as Japanese Windows versions were non-unicode (everything done in ShiftJIS AFAIR). [edit] here is a real-world example of a trivial script handling binary data [2]: reading binary RGBA 4 bytes/pixel image data and outputting RGB 3b/pixel into a pipe that finally outputs a .PNG image. It's difficult to find a programming language that can do that in less lines and with more clarity. [1] https://wiki.tcl-lang.org/page/binary+scan https://wiki.tcl-lang.org/page/binary+scan [2] https://stech.muecke.pw/opensvn/free/trunk/dkbin/nn-fbtopng https://stech.muecke.pw/opensvn/free/trunk/dkbin/nn-fbtopng
- themadsens 6y ago
  Yes, I see your point. I can't remember the context that bit me anymore, but I think it had to with being unable to change the defaults with fconfigure for some reason, the channel being implicit or somesuch .
marttt 6y ago
I got curious, so here's a link to Jim Tcl: http://jim.tcl.tk/index.html/doc/www/www/ http://jim.tcl.tk/index.html/doc/www/www/

physicsguy 6y ago

I used Tcl by virtue of a software package in the scientific domain I work in called OOMMF which is old but a stalwart and very reliable. I find it an odd language. But the one thing that I think is very cool, is that it's very very simple to get a minimal Tcl interpreter (partcl) that can be embedded into a C/C++ application. It also still comes bundled in to Python for the Tkinter framework. You can even use it in Jupyter Notebooks now

analognoise 6y ago

Tcl is amazing just for Tk's Canvas alone. All other sins are forgiven. I've never found something that easy to use. Tkinter (Tk through Python) is awesome. Since this is HN, if somebody knows a scene graph canvas that's even better and as easy to use, please let me know. I'm primarily interested in EDA (so not games).