8 ms·

The only time I’ve dealt with Tcl in recent memory was for some MacPorts portfile stuff. Anybody using it for something else and can speak to why you’d use it

The only time I’ve dealt with Tcl in recent memory was for some MacPorts portfile stuff. Anybody using it for something else and can speak to why you’d use it today? Genuinely curious; I don’t hate the language but can never bring myself to enjoy it either.

metadat 2y ago
Eggdrop IRC bots. Even 25 years since I first created one, Eggdrop is still the best and most reliable + flexible IRC bot platform, and comes with native support for Tcl.
frankjr 2y ago
Curious as well. The only time I've seen it used in the wild is Redis' test suite. https://github.com/redis/redis/tree/unstable/tests/integration https://github.com/redis/redis/tree/unstable/tests/integrati...
aidenn0 2y ago
Tk based GUIs work across pretty much all desktop platforms and are much less resource intensive than electron and friends.
- criddell 2y ago
  Is Electron really considered a competitor to Tk based GUIs? In my (limited) experience, Tcl/Tk is great for basic stuff but I don't think you could do even a small part of what you can do with an html + css + javascript GUI.
  - aidenn0 2y ago
    1. Tk can do a lot more than you think 2. I have seen very basic GUIs in electron just for the cross-platform nature of it.
  - nmadden 2y ago
    It used to be the other way around. It’s been a while since I did much UI work, but the web always felt incredibly frustrating for layout compared to Tk. (I think CSS finally has something approaching Tk’s grid layout manager?) There are fewer frameworks for Tk, but I think it has most things you’d need. Maybe some of the finer control over fonts etc is lacking.
    - criddell 2y ago
      > most things you’d need Say you wanted to write a CAD app like https://www.onshape.com https://www.onshape.com. There’s no way you could do it Tcl/Tk, is there?
      - deleted 2y ago
        [deleted]
      - oldlaptop 2y ago
        Most of what I'd call the UI - all the toolbars and pseudo-floating-windows - is basic bread-and-butter Tk stuff. The 3D context and CAD kernel would be the tricky bits. There are extensions floating around to work with OpenGL (or whatever), but I don't see doing the heavy CAD-kernel lifting in Tcl - that would likely have to be in C, or whatever. (Just as it presumably is for Onshape.)
        deleted 2y ago
        [deleted]
        zvr 2y ago
        You are correct. Having written such a thing, you do all your basic UI in Tcl/Tk and have a custom widget doing all OpenGL/whatever rendering. The rest of the code treats it as a canvas-like widget.
      - WillAdams 2y ago
        It's 2D only and Mac OS-specific, but there is: https://github.com/revarbat/TkCAD https://github.com/revarbat/TkCAD
  - Karrot_Kream 2y ago
    I agree with you but a lot of the demand for GUI tools is small tools. Think something like Postman: it's really just a code editor widget to put in some request metadata and a table view storing requests. This is the kind of tool that something like Tcl would be great at and really doesn't need the sophistication of HTML+CSS+JS.
- catherinecodes 2y ago
  Absolutely. It's even been remarkable stable--programs written 20 or 30 years ago work without any kind of modification.
jamal-kumar 2y ago
Last use I remember seeing for it was in scripting Intel FPGAs https://www.intel.com/content/www/us/en/docs/programmable/683432/22-2/command-line-scripting.html https://www.intel.com/content/www/us/en/docs/programmable/68...
- duskwuff 2y ago
  Tcl is widely used in EDA automation in general - it's not just an Intel thing. Xilinx, Synopsys, Cadence, and Mentor all use Tcl extensively, for example.
  - jamal-kumar 2y ago
    Super interesting, what's the rationale behind its use there?
    - duskwuff 2y ago
      That's what it was created for, believe it or not. And it's been used there since the early '90s; there were very few other embeddable scripting languages at the time, so it caught on quickly.
    - bsder 2y ago
      John Ousterhout realized that every single EDA tool at Berkeley wound up implementing a crappy extension language. So, he implemented a language so that there could be a single, not-so-crappy extension language for the Berkeley EDA tools. He made C integration particularly easy (something the lisps of the time didn't really do). As his students spread out, each company they hit had a shitty extension language and they lobbied to get it replaced with Tcl and thus Tcl spread. The issue with languages is that memory, CPU, and disk in the early 1990s are still fairly expensive. You need a language that is small yet still complete. Even today, the only languages that really fit that bill are Scheme/Lisp, Tcl, and Forth. The memory limitations releasing are why you see the "stringly-typed" scripting languages like Tcl, Perl, etc. from the late 1980s transition to "dynamically typed" languages in the 1990s like Python, VB, later Ruby, Javascript, etc. Tk popped up because GUI development at the time was utter shit (web doesn't exist, VB6 doesn't exist, etc.). It is really hard to describe just how much better Tk was than anything else in the time frame.
neves 2y ago
When I had contact with TCL for a networking class in the 90's I already knew Python and didn't like that "everthing is a string" pathos. For me the greatest TCL contribution was Ousterhout's dichotomy: https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy or by the author himself: https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pdf https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pd...
vFunct 2y ago
It's the scripting language of the EDA industry. If you're designing computer chips, you're using TCL. Cadence and Synopsys standardized on TCL 30+ years ago. It's strength is that you get to operate EDA tools as if they were shell script commands, like run_my_task -option_a -option_B If you aren't designing computer chips, you have no reason to use it. It's a horrible language. The sooner the EDA industry can get rid of TCL, the better.
- doublerabbit 2y ago
  > If you aren't designing computer chips, you have no reason to use it. It's a horrible language. What an unfair statement to make; by no means is it an horrible language. Just because it doesn't fit your tastes doesn't make it "horrible". That's like me saying having to start a line of Python with three spaces is annoying design which makes it an horrible language. Take your statement elsewhere.
  - vFunct 2y ago
    30 years of TCL here. It really is the worst. I immediately moved my scripts to Python 1.0 when Python arrived on the scene because TCL (and PERL) were so horrible.
    - doublerabbit 2y ago
      > 30 years of TCL here. It really is the worst. If it's personal preference, than fine. But that doesn't make it a horrible language for all. I enjoy TCL and Perl and I'm 35. I don't touch Python because I don't enjoy it. And I coded with it when it was in early 2.0x in 2003. I'd rather learn Java.
- Karrot_Kream 2y ago
  I'm curious why you feel this way. A long time ago as a college student I used Tcl in an EDA internship. It was awful for reasons completely unrelated to Tcl. There was a library of tool-specific primitives. The primitives were badly documented, badly tested, and nobody actually understood how any of it worked except cargo-culting and copy-pasting each others' scripts. Code only worked on the happy path and there was almost no thought given to edge cases. There was no culture of code review so nobody scrutinized your code to find out whether you were using Tcl in the right way or not. I'll grant, though very lightly, that Tcl has more accessible metaprogramming facilities than Python which makes it easier to misuse than Python. Similar to how Ruby in the hands of a undereducated/bad Ruby programmer is also quite gross. But I had the same issues using Perl in the EDA industry. The conclusion I came to was that code standards were just abysmal in EDA because code was largely seen as a cost-center activity rather than a profit-center activity as the real output was the ETL or the device and not the code that went into it. I re-learned Tcl when I was older and when my time in EDA was a faint memory and I found the language a joy. It was remarkably easy to get started in and really easy to build an application out of. This experience further made me reflect on how bad the code culture in EDA was. So I'm curious what specifically you'd see the EDA industry move to and how you think it would fix the problems EDA currently has with Tcl. Python, is the successor I imagine? That said my actual time in EDA was very short so I welcome the opinion of an actual insider.
wduquette 2y ago
I think of Tcl as Lisp for C programmers; by which I mean, Tcl give you the metaprogramming capabilities you get with Lisp in a language that looks more like C, plays well with C, is much more straightforward than your typical shell language, and has a cross-platform GUI. A skilled Tcl programmer can do magic. I spent ten years, from 2005 to 2015, programming almost entirely in Tcl/Tk and I loved it. Since then I mostly use it for casual scripts rather than for writing apps; but it's still my #1 choice when I need to do some scripting to automate something at the OS level.
- wduquette 2y ago
  I should add...Tk is the easiest GUI toolkit I've ever used (and I've used a bunch of them). It's got all the basic stuff you need, either built-in or readily available. But it comes from the classic desktop GUI world, you have to work at it to make it look nice, and it's a pain to do webpage-like layouts with it. I wouldn't do an end-user GUI in Tk at this point; but for in-house tools that need a GUI and don't need to be on the web it's hard to beat.
  - progmetaldev 2y ago
    For strictly developer tools, or for those used to older OS desktops or simplistic widgets, it's really hard to beat Tk. It's been around so long that if you've dealt with it before, it might feel dated, but it's also easy to figure out exactly what it does. I got my start using Tkinter with the O'Reilly Programming Python book (the more expanded book from Learning Python), using Python 2.x (probably 2.4 based on the 2008 or so timeframe I bought it). While at that point I had used C#.Net with their GUI builder, as well as Java's AWT and Swing, and Tkinter felt so much more natural when writing a GUI through code.
deleted 2y ago
[deleted]
bch 2y ago
Standard fare: BigIP iRules in F5 network appliances (and A10 appliances)[0], orchestration in Argonne National Labs super computer[1], Tealeaf[2], Python Tkinter[3] … I use it day to day because it’s got a great balance of Lispyness and simple scriptyness, and a great C interface. It’s got a fine REPL, and can be built up (by writing in C) with extensions that are 100% first-class canonical Tcl, in good part (wholly?) because Tcl is such a simple language[4], and homoiconic[5]. A joy to develop in and use. [0] https://community.f5.com/kb/technicalarticles/irules-concepts-tcl-the-how-and-why/275910 https://community.f5.com/kb/technicalarticles/irules-concept... [1] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf [2] https://www.acoustic.com/pdf/Acoustic-Experience-Analytics-%28Tealeaf%29-FOSS-Notices-File.pdf https://www.acoustic.com/pdf/Acoustic-Experience-Analytics-%... [3] https://docs.python.org/3/library/tkinter.html https://docs.python.org/3/library/tkinter.html [4] https://www.tcl-lang.org/man/tcl/TclCmd/Tcl.htm https://www.tcl-lang.org/man/tcl/TclCmd/Tcl.htm [5] https://stackoverflow.com/questions/6492704/what-exactly-does-homoiconicity-mean https://stackoverflow.com/questions/6492704/what-exactly-doe...
vodou 2y ago
Quite common in space industry. It is the script language used in many (all?) SCOS-2000 based mission control systems. Yes, is is actually used to control satellites and spacecrafts.
robinsonb5 2y ago
I used it a few weeks ago to fetch and display access timing histograms in an FPGA project.
wduquette 2y ago
I should also note that Richard Hipp, the creator of SQLite, says that SQLite is coded in Tcl. The database engine itself is coded in C, of course; but the vastly larger test suite is mostly coded in Tcl; and it's the test suite that makes SQLite the reliable engine that it is. The test suite persists; the engine's been re-written in whole and in part.
- bch 2y ago
  Indeed, SQLite started life as simply a Tcl extension[0] that “escaped into the wild”. Redis was initially prototyped in Tcl too, and ‘antirez has nice things[1] to say about Tcl. [0] https://sqlite.org/tclsqlite.html https://sqlite.org/tclsqlite.html [1] http://antirez.com/articoli/tclmisunderstood.html http://antirez.com/articoli/tclmisunderstood.html
  - wslh 2y ago
    I'm curious about why they chose Tcl, particularly over languages like Python or Perl. Were there specific aspects of Tcl that made it appealing for SQLite and Redis, or was the choice more about familiarity with Tcl? Either way, I'd love to understand what they found interesting or advantageous about Tcl in these projects. BTW, I chose Tcl/Tk in the past because it was the easier way I found to quickly built an UI on Unix/Linux.
    - oldlaptop 2y ago
      The Redis protocol reads a lot like Tcl code.
    - progmetaldev 2y ago
      Most likely for the same reason you found. Once you know it, it's very easy to use, and it's available in most distributions (if not all). So both familiarity with Tcl, while having that ability to build out quick and stable GUI tests, including the lack of churn in the GUI framework. For myself, having to readapt to a GUI framework when I'm just trying to get something visual up and running to make life slightly easier, makes something like Tk much more beneficial for just getting work done. A bit ugly, but anyone technically inclined will figure it out quickly, without constantly having to change up libraries. I only speak for myself and put my 2 cents in, I don't speak for anyone else, but for general tooling targeted at developers it seems perfect.
smartmic 2y ago
I often use the tool that is closest to another tool I am using. The closeness may be due to a common heritage, both technical and cultural. A common thread between the two is often high quality, maturity, cross-fertilization, long-term commitment, etc. Now when it comes to Tcl, I use it for the above reasons because it is so convenient for writing scripts to use SQLite. In other words, it is my go-to wrapper for many SQLite applications. This is mainly related to (rapid) prototyping use cases. From https://sqlite.org/tclsqlite.html https://sqlite.org/tclsqlite.html : > The SQLite library is designed to be very easy to use from a Tcl or Tcl/Tk script. SQLite began as a Tcl extension and the primary test suite for SQLite is written in TCL. SQLite can be used with any programming language, but its connections to TCL run deep.
- oldlaptop 2y ago
  If there's any better relational database API, in any language, than SQLite's Tcl interface, I've not seen it yet. (And the reasons SQLite's Tcl interface is so good would either be hard to replicate without Tcl, hard to replicate without SQLite, or both.)
forinti 2y ago
I used it a few times, mainly because of Freewrap. With very little code I was able to write a Windows app with GUI that I could distribute easily as an executable: - A backup app for an online sales application (inputs items and spits out a file); - An app to fix files in a buggy POS for a large retail chain (this might have been used in thousands of machines, I can't recall the details now); - A small app to copy Forms/Reports to the server, fire compilation, and push the new file to git; - A wrapper for gs to help a media department easily join many PDFs into one file. All these have a page or maybe two of code.
- progmetaldev 2y ago
  I don't know if you'll see this, since it was a couple days ago, and I've been reviewing multiple posts. I think what you describe is exactly what got me into programming (beyond a hobby, which was brought on by BASIC games in the 80's), but also what really hooked me into writing code for a living. These all seem like a huge deal, unless you don't understand business and their needs. I can easily see how all four solutions could provide enormous value. For myself, these are the types of things that I got involved in programming professionally for. I think it's impressive that you were able to take a language like Tcl (not traditionally taught in university), and able to find a useful library to implement your logic. Beyond BASIC games in the very early 80's, Visual Basic and the "hacking" tools for AOL, were a huge inspiration for myself. I dipped my toes into some weird libraries to solve some issues, that are still used today, in companies that you would never expect to be using something so simple and crude, but sturdy. Crash out with a useful message if something is wrong, do nothing on failure. Not for regular consumers, but perfect for internal staff that load data into a database, and can understand "row X is not compatible with this data type", or "This transformation rule fails because X occurred," being some rule that can't be expressed through SQL where the data is stored (but was able to be imported).
  - cmacleod4 2y ago
    This reminds me of something I wrote in Tcl at my previous employer - a little utility that could decode an in-house data format and display it in an understandable way. Quite a few other people found it useful for debugging issues.
IshKebab 2y ago
The only reason to use it today is because you're forced to by the EDA industry. Otherwise there are far far better options. That also means this release is basically irrelevant for the next 10 years because that's about how long it takes the EDA vendors to update their bundled TCL versions.
- cmacleod4 2y ago
  It's unfortunate that people who dont "get" Tcl feel forced to use it because they are in EDA. I used to have the opposite problem. My employer would not allow me to write anything mission-critical in Tcl because they thought other people would not be able to maintain it. But now that I'm retired I can write as much Tcl as I like, which is quite a lot :-)
  - oldlaptop 2y ago
    From the (little) I've seen of that world, I'm not sure the EDA vendors understand Tcl very well either; I wouldn't want to work with scripts for Cadence's schematic capture tool, and that's not because of Tcl, it's because their scripting interface is a disaster. (Exposing C++ iterators at the script level, for example.)
    - vFunct 2y ago
      Ironically the schematic capture scripts were likely written in SKILL (LISP-like language) and not TCL. SKILL is much better than TCL for data processing. TCL's strength is in command control flow.
  - IshKebab 2y ago
    I "get" TCL - it's a neat hack. Arguably even an elegant hack. I can see how it would be fun to play with, in the same way that BASIC was. But most of my work isn't playing and I don't want it to be built on hacks.
fullstop 2y ago
I use it for "expect" because it just works.
- dvzk 2y ago
  Same. I learned Tcl recently for /usr/bin/expect. I wasn't happy to be forced into using yet another esoteric language, but Tcl itself is strangely fun: it's like a more expressive and functional Lua.
  - fullstop 2y ago
    Ha, I was in the same position. It's fantastic at scripting serial consoles. Oddly enough, Lua is also near and dear to my heart. It's a great language to embed to allow non C or C++ folks the ability to extend software or to do so dynamically.
stackghost 2y ago
>Anybody using it for something else and can speak to why you’d use it today? Genuinely curious; I don’t hate the language but can never bring myself to enjoy it either. For a long time it was the only way to get a decent IRC bot going, because eggdrop[0] was a Tcl wrapper around a small C core, but the only place I've seen it in the wild other than IRC bots was in the Xilinx toolchain and once when I was in undergrad some TA was using it to get telemetry from Tektronix oscilloscopes in the robotics lab. [0] https://www.eggheads.org/ https://www.eggheads.org/
throw0101b 2y ago
> Anybody using it for something else and can speak to why you’d use it today? It was often used as an embedded language (e.g., in F5 load balancers), especially in the pre-Lua days.
BoingBoomTschak 2y ago
Copy-pasting a "hype" checklist I made some eons ago: * Extremely consistent and elegant syntax - whole syntax/grammar is described in 12 rules in a single man page (Tcl(n)) of 150 lines and there's no reserved keyword. Nearer to CL than Python on that point. * Homoiconic through strings (like almost every language with eval) but most importantly, through "list-like" strings. * Official man pages! No web-only and spec-like doc like cppreference nor lackluster "minimalist" stuff like pydoc (compare `pydoc print` with `man n puts`, for example). * One of the simplest if not the simplest interaction with C, letting you write C plugins very easily (with critcl and swig to help). * Not slow, not fast. In the same ballpark as cpython or Perl; doesn't need a tracing garbage collector, refcounting does the job since no cycles are possible by design (worse for throughput, but lighter runtime). * Fun type system that is superficially "everything is a string" (like sh) but in reality "everything is a tagged union with on-the-fly conversion when needed and a guaranteed string representation". Allows for transparent serialization (`puts $mydict stdout` <=> `set mydict [read stdin]`), like CL's read/write. * Powerful introspection through `info` (mainly). Allows for stuff like getting the name/body/arglist of a procedure, get all the registered procedures, know if a variable exists, get information on the stack frames and their content, etc... Together with `trace`, you can even write an internal debugger in few lines. * Procedure arguments are passed by pointer with a copy-on-write system: don't modify the argument and you don't get any memory copy. To you, it just looks like regular passing by value. * Modifying the procedure arguments is done via `upvar`: in Tcl, a variable reference is just a name (string) attached to a relative stack frame number, quite elegant considering the language's core concepts. * If you use at least the builtin extensions (thread, http, tdbc, tcltest, msgcat) and the very basic tcllib/tclX/tclUdp/tklib packages, you're almost set for life. Personally, I also recomment the very convenient tclreadline, tdom, pipethread, tablelist and tclcurl. * Channels is one of the cleanest I/O implementation I've ever used with some cool features: - Transformations allowing filters like deflate/zlib/gzip or TLS to be put on a channel (see `transchan` for the API). - Reflected aka virtual channels, to make your own channels. Basically like glibc/BSD's unportable fopencookie/funopen or CL's gray streams. - Centralize a lot of ioctl/fcntl mess and even more (like defining the EOF char) in `chan blocked/configure/pending`. - Integration with the event loop via `chan event/postevent` allows for a nice callback oriented approach to sockets and pipes. - Other third-party channel types include pty (expect), random, memory or fifo (memchan). * Builtin event loop (see `after`, `vwait`, `socket -server` and `chan event`) for powerful and seamless concurrency/command scheduling. Much simpler than Python's very "AbstractBeanFactory" asyncio. * An elegant thread extension consisting of an interpreter per thread and no raw access to other thread's memory. Comes with both simple (`thread::send/broadcast/transfer`) and performant (`tsv`) synchronization/communication facilities. * Finally a sane, light and portable (even more with Tile) GUI toolkit: Tk. * One of the fastest Unicode aware regex implementations, written by Henry Spencer himself. Has its own greater-than-POSIX-ERE syntax called ARE, not as complete as PCRE (lacking lookbehind constraints, most importantly), but still great for an hybrid NFA/DFA engine. Performance comparison with Perl: https://github.com/mariomka/regex-benchmark/pull/44 https://github.com/mariomka/regex-benchmark/pull/44. * `uplevel` (eval a script in a different stack frame) and `tailcall` (replace the current procedure with another command) let you augment the language by implementing control structures and keywords yourself. Inferior to CL's synergy between unhygienic macros, "naked AST" style homoiconicity, symbols as first-class objects, gensym and quasi-quoting, but still quite powerful. * Safe interpreters let you do very fun things like config files in Tcl with limited access to the machine and master interpreter. * Recent versions (>= 8.5) really embraced FP with: - Real lambdas (but not closures, these have to be emulated) through apply. - Purer hash maps (dict) than ugly sticking-out-like-a-sore-thumb arrays. - Lisp style prefix arithmetic (allowing for `* 3 [+ 1 2]` instead of `expr {3 * (1 + 2)}`) including sane behaviour for more than two (reduce) or zero (neutral element) arguments. - Builtin map/filter (lmap) with 8.6. See https://wiki.tcl-lang.org/page/Functional+Programming https://wiki.tcl-lang.org/page/Functional+Programming for more. * Multiple more-or-less powerful OO systems (now based on the builtin TclOO): [incr Tcl] for C++ style OO, XoTcl for a take on CLOS or Snit for something Tk oriented. * Some massive issues on the top of my head: lacking a LSP/SLIME equivalent, the warts of the weird type system (no way to differentiate between atoms and single element lists or evenly sized lists and dicts), missing metaprogramming facilities like quasi-quoting, no official support for UDP and UNIX domain sockets, no GC for class instances (cf https://core.tcl-lang.org/tips/doc/trunk/tip/550.md https://core.tcl-lang.org/tips/doc/trunk/tip/550.md), no FFI in core, subtly broken exec (cf https://core.tcl-lang.org/tips/doc/trunk/tip/424.md https://core.tcl-lang.org/tips/doc/trunk/tip/424.md and https://core.tcl-lang.org/tips/doc/trunk/tip/259.md https://core.tcl-lang.org/tips/doc/trunk/tip/259.md) Here are some project I made with it, still worth using compared to CL which is my true love, simply because its stdlib is better suited for a lot of tasks: https://git.sr.ht/~q3cpma/mangadex-tools https://git.sr.ht/~q3cpma/rymscrap https://git.sr.ht/~q3cpma/lemonbar-tcl https://git.sr.ht/~q3cpma/tcl-misc
natrys 2y ago
I use it to write long running little scripts. It's better than shell, and imo more useful out of the box than Lua. They are basically for I/O (often using sqlite which it has great integration with, or using expect which is also great) so I don't care about performance, but I like that it requires much less memory compared to say Python for that kind of little things (there is also jimtcl which is also neat in this regard).
badsectoracula 2y ago
Some time ago i was playing with a Raspberry Pi and wanted to write some code in there. The Gtk3-powered Geany was WAY too slow (like, type and wait for the letter to appear slow). I recompiled it to use Gtk2, it was much faster but also it was buggy (the code display was getting messed up). Nedit (based on Motif) on the other hand was both very fast (faster than the Gtk2 Geany) and bug-free - it worked perfectly. But i wanted Geany because of the file browser sidebar. So i wrote a small Tcl/Tk script to display a list of files using a filter in a directory and call Nedit to edit them when you doubleclicked. Also added a few buttons to call make, make clean, open a terminal, make a new file, etc and worked perfectly. A few years since then i made a few improvements and modifications to this script and use it on my main PC whenever i want to work on C source code - though i use Krita instead of Nedit here (Krita has its own file browser sidebar but i find the way it works annoying - and doesn't have all the extra stuff i've added over time to the script). The neat bit is that it reads a Tcl file from the home directory for "global" configuration (e.g. which editor to use, how to run terminal commands, etc) and then a Tcl file from the current directory for project-specific stuff, all of which having access to the main script's own procs for things like calling terminal commands, showing a few dialogs, etc. I've uploaded the latest version of the script to my website a few days ago[0]. I've been mainly using it with Linux but a couple of years ago i also used it a bit with Windows using MSYS2 (with Notepad++ for the editor) and worked fine. There is a screenshot on the site. [0] http://runtimeterror.com/tools/projfiles/ http://runtimeterror.com/tools/projfiles/
pjmlp 2y ago
Back in the late 90's we used it on our startup, several of companies at the time were trying the luck on Tcl based application servers, AOLServer being the most well known. There was Vignette, and we at Intervento had our Safelayer product, loosely based on AOLServer. Apache and IIS plugins for hosting Tcl interpreter, running on Aix, HP-UX, Solaris, Red-Hat Linux, Windows 2000/NT, with support for Oracle, Informix, DB2, Sybase SQL Server, Microsoft SQL Server, Access (only for test purposes). Development environment was based on Emacs, eventually there was one written in Visual Basic specifically for the product, with project templates and other kinds of goodies. However we eventually hit the limits of using Tcl, and having to rewrite parts of the platform in C. As it was, being a gold MSFT partner gave us access to .NET before it was announced to the world, and a plan to rewrite our product into C# took place. With the learnings of these experiences, and customisations done at client sites, the founders eventually moved on and created one of the best products for no code development still going strong nowadays, OutSystems. Never used Tcl again since those days.
- fraber 2y ago
  AOLServer (now Naviserver again) is still the base for the largest open-source project management system: ]project-open[ (https://www.project-open.com/ https://www.project-open.com/)
  - pjmlp 2y ago
    Interesting, didn't expect it to still be around.
jasomill 2y ago
It has expect[1], a nice tool to automate terminal applications. Two examples: - Adding convenience features to the Cisco IOS CLI (e.g., ^D to exit). - Implementing the back end of a native WPF Windows GUI application that downloads spooled print jobs from a third-party system that only provides remote spooler access through a full-screen interactive terminal application running over ssh. This application also makes use of another nice Tcl feature, its trivially-implemented remote protocol[2]. [1] https://core.tcl-lang.org/expect/index https://core.tcl-lang.org/expect/index [2] http://corex.tcl-lang.org/tcllib/doc/tcllib-1-18/embedded/www/tcllib/files/modules/comm/comm_wire.html http://corex.tcl-lang.org/tcllib/doc/tcllib-1-18/embedded/ww...

metadat 2y ago

Eggdrop IRC bots. Even 25 years since I first created one, Eggdrop is still the best and most reliable + flexible IRC bot platform, and comes with native support for Tcl.

frankjr 2y ago

Curious as well. The only time I've seen it used in the wild is Redis' test suite. https://github.com/redis/redis/tree/unstable/tests/integration https://github.com/redis/redis/tree/unstable/tests/integrati...

aidenn0 2y ago

Tk based GUIs work across pretty much all desktop platforms and are much less resource intensive than electron and friends.

criddell 2y ago
Is Electron really considered a competitor to Tk based GUIs? In my (limited) experience, Tcl/Tk is great for basic stuff but I don't think you could do even a small part of what you can do with an html + css + javascript GUI.
- aidenn0 2y ago
  1. Tk can do a lot more than you think 2. I have seen very basic GUIs in electron just for the cross-platform nature of it.
- nmadden 2y ago
  It used to be the other way around. It’s been a while since I did much UI work, but the web always felt incredibly frustrating for layout compared to Tk. (I think CSS finally has something approaching Tk’s grid layout manager?) There are fewer frameworks for Tk, but I think it has most things you’d need. Maybe some of the finer control over fonts etc is lacking.
  - criddell 2y ago
    > most things you’d need Say you wanted to write a CAD app like https://www.onshape.com https://www.onshape.com. There’s no way you could do it Tcl/Tk, is there?
    - deleted 2y ago
      [deleted]
    - oldlaptop 2y ago
      Most of what I'd call the UI - all the toolbars and pseudo-floating-windows - is basic bread-and-butter Tk stuff. The 3D context and CAD kernel would be the tricky bits. There are extensions floating around to work with OpenGL (or whatever), but I don't see doing the heavy CAD-kernel lifting in Tcl - that would likely have to be in C, or whatever. (Just as it presumably is for Onshape.)
      - deleted 2y ago
        [deleted]
      - zvr 2y ago
        You are correct. Having written such a thing, you do all your basic UI in Tcl/Tk and have a custom widget doing all OpenGL/whatever rendering. The rest of the code treats it as a canvas-like widget.
    - WillAdams 2y ago
      It's 2D only and Mac OS-specific, but there is: https://github.com/revarbat/TkCAD https://github.com/revarbat/TkCAD
- Karrot_Kream 2y ago
  I agree with you but a lot of the demand for GUI tools is small tools. Think something like Postman: it's really just a code editor widget to put in some request metadata and a table view storing requests. This is the kind of tool that something like Tcl would be great at and really doesn't need the sophistication of HTML+CSS+JS.
catherinecodes 2y ago
Absolutely. It's even been remarkable stable--programs written 20 or 30 years ago work without any kind of modification.

jamal-kumar 2y ago

Last use I remember seeing for it was in scripting Intel FPGAs https://www.intel.com/content/www/us/en/docs/programmable/683432/22-2/command-line-scripting.html https://www.intel.com/content/www/us/en/docs/programmable/68...

duskwuff 2y ago
Tcl is widely used in EDA automation in general - it's not just an Intel thing. Xilinx, Synopsys, Cadence, and Mentor all use Tcl extensively, for example.
- jamal-kumar 2y ago
  Super interesting, what's the rationale behind its use there?
  - duskwuff 2y ago
    That's what it was created for, believe it or not. And it's been used there since the early '90s; there were very few other embeddable scripting languages at the time, so it caught on quickly.
  - bsder 2y ago
    John Ousterhout realized that every single EDA tool at Berkeley wound up implementing a crappy extension language. So, he implemented a language so that there could be a single, not-so-crappy extension language for the Berkeley EDA tools. He made C integration particularly easy (something the lisps of the time didn't really do). As his students spread out, each company they hit had a shitty extension language and they lobbied to get it replaced with Tcl and thus Tcl spread. The issue with languages is that memory, CPU, and disk in the early 1990s are still fairly expensive. You need a language that is small yet still complete. Even today, the only languages that really fit that bill are Scheme/Lisp, Tcl, and Forth. The memory limitations releasing are why you see the "stringly-typed" scripting languages like Tcl, Perl, etc. from the late 1980s transition to "dynamically typed" languages in the 1990s like Python, VB, later Ruby, Javascript, etc. Tk popped up because GUI development at the time was utter shit (web doesn't exist, VB6 doesn't exist, etc.). It is really hard to describe just how much better Tk was than anything else in the time frame.

neves 2y ago

When I had contact with TCL for a networking class in the 90's I already knew Python and didn't like that "everthing is a string" pathos. For me the greatest TCL contribution was Ousterhout's dichotomy: https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy or by the author himself: https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pdf https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pd...

vFunct 2y ago

It's the scripting language of the EDA industry. If you're designing computer chips, you're using TCL. Cadence and Synopsys standardized on TCL 30+ years ago. It's strength is that you get to operate EDA tools as if they were shell script commands, like run_my_task -option_a -option_B If you aren't designing computer chips, you have no reason to use it. It's a horrible language. The sooner the EDA industry can get rid of TCL, the better.

doublerabbit 2y ago
> If you aren't designing computer chips, you have no reason to use it. It's a horrible language. What an unfair statement to make; by no means is it an horrible language. Just because it doesn't fit your tastes doesn't make it "horrible". That's like me saying having to start a line of Python with three spaces is annoying design which makes it an horrible language. Take your statement elsewhere.
- vFunct 2y ago
  30 years of TCL here. It really is the worst. I immediately moved my scripts to Python 1.0 when Python arrived on the scene because TCL (and PERL) were so horrible.
  - doublerabbit 2y ago
    > 30 years of TCL here. It really is the worst. If it's personal preference, than fine. But that doesn't make it a horrible language for all. I enjoy TCL and Perl and I'm 35. I don't touch Python because I don't enjoy it. And I coded with it when it was in early 2.0x in 2003. I'd rather learn Java.
Karrot_Kream 2y ago
I'm curious why you feel this way. A long time ago as a college student I used Tcl in an EDA internship. It was awful for reasons completely unrelated to Tcl. There was a library of tool-specific primitives. The primitives were badly documented, badly tested, and nobody actually understood how any of it worked except cargo-culting and copy-pasting each others' scripts. Code only worked on the happy path and there was almost no thought given to edge cases. There was no culture of code review so nobody scrutinized your code to find out whether you were using Tcl in the right way or not. I'll grant, though very lightly, that Tcl has more accessible metaprogramming facilities than Python which makes it easier to misuse than Python. Similar to how Ruby in the hands of a undereducated/bad Ruby programmer is also quite gross. But I had the same issues using Perl in the EDA industry. The conclusion I came to was that code standards were just abysmal in EDA because code was largely seen as a cost-center activity rather than a profit-center activity as the real output was the ETL or the device and not the code that went into it. I re-learned Tcl when I was older and when my time in EDA was a faint memory and I found the language a joy. It was remarkably easy to get started in and really easy to build an application out of. This experience further made me reflect on how bad the code culture in EDA was. So I'm curious what specifically you'd see the EDA industry move to and how you think it would fix the problems EDA currently has with Tcl. Python, is the successor I imagine? That said my actual time in EDA was very short so I welcome the opinion of an actual insider.

wduquette 2y ago

I think of Tcl as Lisp for C programmers; by which I mean, Tcl give you the metaprogramming capabilities you get with Lisp in a language that looks more like C, plays well with C, is much more straightforward than your typical shell language, and has a cross-platform GUI. A skilled Tcl programmer can do magic. I spent ten years, from 2005 to 2015, programming almost entirely in Tcl/Tk and I loved it. Since then I mostly use it for casual scripts rather than for writing apps; but it's still my #1 choice when I need to do some scripting to automate something at the OS level.

wduquette 2y ago
I should add...Tk is the easiest GUI toolkit I've ever used (and I've used a bunch of them). It's got all the basic stuff you need, either built-in or readily available. But it comes from the classic desktop GUI world, you have to work at it to make it look nice, and it's a pain to do webpage-like layouts with it. I wouldn't do an end-user GUI in Tk at this point; but for in-house tools that need a GUI and don't need to be on the web it's hard to beat.
- progmetaldev 2y ago
  For strictly developer tools, or for those used to older OS desktops or simplistic widgets, it's really hard to beat Tk. It's been around so long that if you've dealt with it before, it might feel dated, but it's also easy to figure out exactly what it does. I got my start using Tkinter with the O'Reilly Programming Python book (the more expanded book from Learning Python), using Python 2.x (probably 2.4 based on the 2008 or so timeframe I bought it). While at that point I had used C#.Net with their GUI builder, as well as Java's AWT and Swing, and Tkinter felt so much more natural when writing a GUI through code.

deleted 2y ago

[deleted]

bch 2y ago

Standard fare: BigIP iRules in F5 network appliances (and A10 appliances)[0], orchestration in Argonne National Labs super computer[1], Tealeaf[2], Python Tkinter[3] … I use it day to day because it’s got a great balance of Lispyness and simple scriptyness, and a great C interface. It’s got a fine REPL, and can be built up (by writing in C) with extensions that are 100% first-class canonical Tcl, in good part (wholly?) because Tcl is such a simple language[4], and homoiconic[5]. A joy to develop in and use. [0] https://community.f5.com/kb/technicalarticles/irules-concepts-tcl-the-how-and-why/275910 https://community.f5.com/kb/technicalarticles/irules-concept... [1] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf [2] https://www.acoustic.com/pdf/Acoustic-Experience-Analytics-%28Tealeaf%29-FOSS-Notices-File.pdf https://www.acoustic.com/pdf/Acoustic-Experience-Analytics-%... [3] https://docs.python.org/3/library/tkinter.html https://docs.python.org/3/library/tkinter.html [4] https://www.tcl-lang.org/man/tcl/TclCmd/Tcl.htm https://www.tcl-lang.org/man/tcl/TclCmd/Tcl.htm [5] https://stackoverflow.com/questions/6492704/what-exactly-does-homoiconicity-mean https://stackoverflow.com/questions/6492704/what-exactly-doe...

vodou 2y ago

Quite common in space industry. It is the script language used in many (all?) SCOS-2000 based mission control systems. Yes, is is actually used to control satellites and spacecrafts.

robinsonb5 2y ago

I used it a few weeks ago to fetch and display access timing histograms in an FPGA project.

wduquette 2y ago

I should also note that Richard Hipp, the creator of SQLite, says that SQLite is coded in Tcl. The database engine itself is coded in C, of course; but the vastly larger test suite is mostly coded in Tcl; and it's the test suite that makes SQLite the reliable engine that it is. The test suite persists; the engine's been re-written in whole and in part.

bch 2y ago
Indeed, SQLite started life as simply a Tcl extension[0] that “escaped into the wild”. Redis was initially prototyped in Tcl too, and ‘antirez has nice things[1] to say about Tcl. [0] https://sqlite.org/tclsqlite.html https://sqlite.org/tclsqlite.html [1] http://antirez.com/articoli/tclmisunderstood.html http://antirez.com/articoli/tclmisunderstood.html
- wslh 2y ago
  I'm curious about why they chose Tcl, particularly over languages like Python or Perl. Were there specific aspects of Tcl that made it appealing for SQLite and Redis, or was the choice more about familiarity with Tcl? Either way, I'd love to understand what they found interesting or advantageous about Tcl in these projects. BTW, I chose Tcl/Tk in the past because it was the easier way I found to quickly built an UI on Unix/Linux.
  - oldlaptop 2y ago
    The Redis protocol reads a lot like Tcl code.
  - progmetaldev 2y ago
    Most likely for the same reason you found. Once you know it, it's very easy to use, and it's available in most distributions (if not all). So both familiarity with Tcl, while having that ability to build out quick and stable GUI tests, including the lack of churn in the GUI framework. For myself, having to readapt to a GUI framework when I'm just trying to get something visual up and running to make life slightly easier, makes something like Tk much more beneficial for just getting work done. A bit ugly, but anyone technically inclined will figure it out quickly, without constantly having to change up libraries. I only speak for myself and put my 2 cents in, I don't speak for anyone else, but for general tooling targeted at developers it seems perfect.

smartmic 2y ago

I often use the tool that is closest to another tool I am using. The closeness may be due to a common heritage, both technical and cultural. A common thread between the two is often high quality, maturity, cross-fertilization, long-term commitment, etc. Now when it comes to Tcl, I use it for the above reasons because it is so convenient for writing scripts to use SQLite. In other words, it is my go-to wrapper for many SQLite applications. This is mainly related to (rapid) prototyping use cases. From https://sqlite.org/tclsqlite.html https://sqlite.org/tclsqlite.html : > The SQLite library is designed to be very easy to use from a Tcl or Tcl/Tk script. SQLite began as a Tcl extension and the primary test suite for SQLite is written in TCL. SQLite can be used with any programming language, but its connections to TCL run deep.

oldlaptop 2y ago
If there's any better relational database API, in any language, than SQLite's Tcl interface, I've not seen it yet. (And the reasons SQLite's Tcl interface is so good would either be hard to replicate without Tcl, hard to replicate without SQLite, or both.)

forinti 2y ago

I used it a few times, mainly because of Freewrap. With very little code I was able to write a Windows app with GUI that I could distribute easily as an executable: - A backup app for an online sales application (inputs items and spits out a file); - An app to fix files in a buggy POS for a large retail chain (this might have been used in thousands of machines, I can't recall the details now); - A small app to copy Forms/Reports to the server, fire compilation, and push the new file to git; - A wrapper for gs to help a media department easily join many PDFs into one file. All these have a page or maybe two of code.

progmetaldev 2y ago
I don't know if you'll see this, since it was a couple days ago, and I've been reviewing multiple posts. I think what you describe is exactly what got me into programming (beyond a hobby, which was brought on by BASIC games in the 80's), but also what really hooked me into writing code for a living. These all seem like a huge deal, unless you don't understand business and their needs. I can easily see how all four solutions could provide enormous value. For myself, these are the types of things that I got involved in programming professionally for. I think it's impressive that you were able to take a language like Tcl (not traditionally taught in university), and able to find a useful library to implement your logic. Beyond BASIC games in the very early 80's, Visual Basic and the "hacking" tools for AOL, were a huge inspiration for myself. I dipped my toes into some weird libraries to solve some issues, that are still used today, in companies that you would never expect to be using something so simple and crude, but sturdy. Crash out with a useful message if something is wrong, do nothing on failure. Not for regular consumers, but perfect for internal staff that load data into a database, and can understand "row X is not compatible with this data type", or "This transformation rule fails because X occurred," being some rule that can't be expressed through SQL where the data is stored (but was able to be imported).
- cmacleod4 2y ago
  This reminds me of something I wrote in Tcl at my previous employer - a little utility that could decode an in-house data format and display it in an understandable way. Quite a few other people found it useful for debugging issues.

IshKebab 2y ago

The only reason to use it today is because you're forced to by the EDA industry. Otherwise there are far far better options. That also means this release is basically irrelevant for the next 10 years because that's about how long it takes the EDA vendors to update their bundled TCL versions.

cmacleod4 2y ago
It's unfortunate that people who dont "get" Tcl feel forced to use it because they are in EDA. I used to have the opposite problem. My employer would not allow me to write anything mission-critical in Tcl because they thought other people would not be able to maintain it. But now that I'm retired I can write as much Tcl as I like, which is quite a lot :-)
- oldlaptop 2y ago
  From the (little) I've seen of that world, I'm not sure the EDA vendors understand Tcl very well either; I wouldn't want to work with scripts for Cadence's schematic capture tool, and that's not because of Tcl, it's because their scripting interface is a disaster. (Exposing C++ iterators at the script level, for example.)
  - vFunct 2y ago
    Ironically the schematic capture scripts were likely written in SKILL (LISP-like language) and not TCL. SKILL is much better than TCL for data processing. TCL's strength is in command control flow.
- IshKebab 2y ago
  I "get" TCL - it's a neat hack. Arguably even an elegant hack. I can see how it would be fun to play with, in the same way that BASIC was. But most of my work isn't playing and I don't want it to be built on hacks.

fullstop 2y ago

I use it for "expect" because it just works.

dvzk 2y ago
Same. I learned Tcl recently for /usr/bin/expect. I wasn't happy to be forced into using yet another esoteric language, but Tcl itself is strangely fun: it's like a more expressive and functional Lua.
- fullstop 2y ago
  Ha, I was in the same position. It's fantastic at scripting serial consoles. Oddly enough, Lua is also near and dear to my heart. It's a great language to embed to allow non C or C++ folks the ability to extend software or to do so dynamically.

stackghost 2y ago

>Anybody using it for something else and can speak to why you’d use it today? Genuinely curious; I don’t hate the language but can never bring myself to enjoy it either. For a long time it was the only way to get a decent IRC bot going, because eggdrop[0] was a Tcl wrapper around a small C core, but the only place I've seen it in the wild other than IRC bots was in the Xilinx toolchain and once when I was in undergrad some TA was using it to get telemetry from Tektronix oscilloscopes in the robotics lab. [0] https://www.eggheads.org/ https://www.eggheads.org/

throw0101b 2y ago

> Anybody using it for something else and can speak to why you’d use it today? It was often used as an embedded language (e.g., in F5 load balancers), especially in the pre-Lua days.

BoingBoomTschak 2y ago

Copy-pasting a "hype" checklist I made some eons ago: * Extremely consistent and elegant syntax - whole syntax/grammar is described in 12 rules in a single man page (Tcl(n)) of 150 lines and there's no reserved keyword. Nearer to CL than Python on that point. * Homoiconic through strings (like almost every language with eval) but most importantly, through "list-like" strings. * Official man pages! No web-only and spec-like doc like cppreference nor lackluster "minimalist" stuff like pydoc (compare `pydoc print` with `man n puts`, for example). * One of the simplest if not the simplest interaction with C, letting you write C plugins very easily (with critcl and swig to help). * Not slow, not fast. In the same ballpark as cpython or Perl; doesn't need a tracing garbage collector, refcounting does the job since no cycles are possible by design (worse for throughput, but lighter runtime). * Fun type system that is superficially "everything is a string" (like sh) but in reality "everything is a tagged union with on-the-fly conversion when needed and a guaranteed string representation". Allows for transparent serialization (`puts $mydict stdout` <=> `set mydict [read stdin]`), like CL's read/write. * Powerful introspection through `info` (mainly). Allows for stuff like getting the name/body/arglist of a procedure, get all the registered procedures, know if a variable exists, get information on the stack frames and their content, etc... Together with `trace`, you can even write an internal debugger in few lines. * Procedure arguments are passed by pointer with a copy-on-write system: don't modify the argument and you don't get any memory copy. To you, it just looks like regular passing by value. * Modifying the procedure arguments is done via `upvar`: in Tcl, a variable reference is just a name (string) attached to a relative stack frame number, quite elegant considering the language's core concepts. * If you use at least the builtin extensions (thread, http, tdbc, tcltest, msgcat) and the very basic tcllib/tclX/tclUdp/tklib packages, you're almost set for life. Personally, I also recomment the very convenient tclreadline, tdom, pipethread, tablelist and tclcurl. * Channels is one of the cleanest I/O implementation I've ever used with some cool features: - Transformations allowing filters like deflate/zlib/gzip or TLS to be put on a channel (see `transchan` for the API). - Reflected aka virtual channels, to make your own channels. Basically like glibc/BSD's unportable fopencookie/funopen or CL's gray streams. - Centralize a lot of ioctl/fcntl mess and even more (like defining the EOF char) in `chan blocked/configure/pending`. - Integration with the event loop via `chan event/postevent` allows for a nice callback oriented approach to sockets and pipes. - Other third-party channel types include pty (expect), random, memory or fifo (memchan). * Builtin event loop (see `after`, `vwait`, `socket -server` and `chan event`) for powerful and seamless concurrency/command scheduling. Much simpler than Python's very "AbstractBeanFactory" asyncio. * An elegant thread extension consisting of an interpreter per thread and no raw access to other thread's memory. Comes with both simple (`thread::send/broadcast/transfer`) and performant (`tsv`) synchronization/communication facilities. * Finally a sane, light and portable (even more with Tile) GUI toolkit: Tk. * One of the fastest Unicode aware regex implementations, written by Henry Spencer himself. Has its own greater-than-POSIX-ERE syntax called ARE, not as complete as PCRE (lacking lookbehind constraints, most importantly), but still great for an hybrid NFA/DFA engine. Performance comparison with Perl: https://github.com/mariomka/regex-benchmark/pull/44 https://github.com/mariomka/regex-benchmark/pull/44. * `uplevel` (eval a script in a different stack frame) and `tailcall` (replace the current procedure with another command) let you augment the language by implementing control structures and keywords yourself. Inferior to CL's synergy between unhygienic macros, "naked AST" style homoiconicity, symbols as first-class objects, gensym and quasi-quoting, but still quite powerful. * Safe interpreters let you do very fun things like config files in Tcl with limited access to the machine and master interpreter. * Recent versions (>= 8.5) really embraced FP with: - Real lambdas (but not closures, these have to be emulated) through apply. - Purer hash maps (dict) than ugly sticking-out-like-a-sore-thumb arrays. - Lisp style prefix arithmetic (allowing for `* 3 [+ 1 2]` instead of `expr {3 * (1 + 2)}`) including sane behaviour for more than two (reduce) or zero (neutral element) arguments. - Builtin map/filter (lmap) with 8.6. See https://wiki.tcl-lang.org/page/Functional+Programming https://wiki.tcl-lang.org/page/Functional+Programming for more. * Multiple more-or-less powerful OO systems (now based on the builtin TclOO): [incr Tcl] for C++ style OO, XoTcl for a take on CLOS or Snit for something Tk oriented. * Some massive issues on the top of my head: lacking a LSP/SLIME equivalent, the warts of the weird type system (no way to differentiate between atoms and single element lists or evenly sized lists and dicts), missing metaprogramming facilities like quasi-quoting, no official support for UDP and UNIX domain sockets, no GC for class instances (cf https://core.tcl-lang.org/tips/doc/trunk/tip/550.md https://core.tcl-lang.org/tips/doc/trunk/tip/550.md), no FFI in core, subtly broken exec (cf https://core.tcl-lang.org/tips/doc/trunk/tip/424.md https://core.tcl-lang.org/tips/doc/trunk/tip/424.md and https://core.tcl-lang.org/tips/doc/trunk/tip/259.md https://core.tcl-lang.org/tips/doc/trunk/tip/259.md) Here are some project I made with it, still worth using compared to CL which is my true love, simply because its stdlib is better suited for a lot of tasks: https://git.sr.ht/~q3cpma/mangadex-tools https://git.sr.ht/~q3cpma/rymscrap https://git.sr.ht/~q3cpma/lemonbar-tcl https://git.sr.ht/~q3cpma/tcl-misc

natrys 2y ago

I use it to write long running little scripts. It's better than shell, and imo more useful out of the box than Lua. They are basically for I/O (often using sqlite which it has great integration with, or using expect which is also great) so I don't care about performance, but I like that it requires much less memory compared to say Python for that kind of little things (there is also jimtcl which is also neat in this regard).

badsectoracula 2y ago

Some time ago i was playing with a Raspberry Pi and wanted to write some code in there. The Gtk3-powered Geany was WAY too slow (like, type and wait for the letter to appear slow). I recompiled it to use Gtk2, it was much faster but also it was buggy (the code display was getting messed up). Nedit (based on Motif) on the other hand was both very fast (faster than the Gtk2 Geany) and bug-free - it worked perfectly. But i wanted Geany because of the file browser sidebar. So i wrote a small Tcl/Tk script to display a list of files using a filter in a directory and call Nedit to edit them when you doubleclicked. Also added a few buttons to call make, make clean, open a terminal, make a new file, etc and worked perfectly. A few years since then i made a few improvements and modifications to this script and use it on my main PC whenever i want to work on C source code - though i use Krita instead of Nedit here (Krita has its own file browser sidebar but i find the way it works annoying - and doesn't have all the extra stuff i've added over time to the script). The neat bit is that it reads a Tcl file from the home directory for "global" configuration (e.g. which editor to use, how to run terminal commands, etc) and then a Tcl file from the current directory for project-specific stuff, all of which having access to the main script's own procs for things like calling terminal commands, showing a few dialogs, etc. I've uploaded the latest version of the script to my website a few days ago[0]. I've been mainly using it with Linux but a couple of years ago i also used it a bit with Windows using MSYS2 (with Notepad++ for the editor) and worked fine. There is a screenshot on the site. [0] http://runtimeterror.com/tools/projfiles/ http://runtimeterror.com/tools/projfiles/

pjmlp 2y ago

Back in the late 90's we used it on our startup, several of companies at the time were trying the luck on Tcl based application servers, AOLServer being the most well known. There was Vignette, and we at Intervento had our Safelayer product, loosely based on AOLServer. Apache and IIS plugins for hosting Tcl interpreter, running on Aix, HP-UX, Solaris, Red-Hat Linux, Windows 2000/NT, with support for Oracle, Informix, DB2, Sybase SQL Server, Microsoft SQL Server, Access (only for test purposes). Development environment was based on Emacs, eventually there was one written in Visual Basic specifically for the product, with project templates and other kinds of goodies. However we eventually hit the limits of using Tcl, and having to rewrite parts of the platform in C. As it was, being a gold MSFT partner gave us access to .NET before it was announced to the world, and a plan to rewrite our product into C# took place. With the learnings of these experiences, and customisations done at client sites, the founders eventually moved on and created one of the best products for no code development still going strong nowadays, OutSystems. Never used Tcl again since those days.

fraber 2y ago
AOLServer (now Naviserver again) is still the base for the largest open-source project management system: ]project-open[ (https://www.project-open.com/ https://www.project-open.com/)
- pjmlp 2y ago
  Interesting, didn't expect it to still be around.

jasomill 2y ago

It has expect[1], a nice tool to automate terminal applications. Two examples: - Adding convenience features to the Cisco IOS CLI (e.g., ^D to exit). - Implementing the back end of a native WPF Windows GUI application that downloads spooled print jobs from a third-party system that only provides remote spooler access through a full-screen interactive terminal application running over ssh. This application also makes use of another nice Tcl feature, its trivially-implemented remote protocol[2]. [1] https://core.tcl-lang.org/expect/index https://core.tcl-lang.org/expect/index [2] http://corex.tcl-lang.org/tcllib/doc/tcllib-1-18/embedded/www/tcllib/files/modules/comm/comm_wire.html http://corex.tcl-lang.org/tcllib/doc/tcllib-1-18/embedded/ww...