The future is bright for Tcl! You’d be pardoned for thinking otherwise. It’s not a sexy new language. In fact, it’s ranked outside the Top 50 in the TIOBE Index. But for the right projects – and there are lots of them – it’s a powerful tool that’s been stress-tested for many years and just gets the job done.

Tcl is not resting on its laurels. The simplicity of the Tcl language makes it perfect for Internet of Things (IoT) and electronics design, including Electronic Design Automation (EDA), chip design, and Field-Programmable Gate Array (FPGA) development, and for configuring chips after manufacture. The same features that make Tcl dominant in EDA and FPGA also make it great for DevOps, potentially competing with Bash and Perl as the language of choice for configuration and management of developer operations systems. The power of the GUI and its separation from the compute structures makes Tcl an amazing choice for prototyping. With a port of Tcl/Tk to Android, rapid prototyping can also be done on mobile.

We recently spoke to Clif Flynt, President and CTO of Noumena Corporation, to get his view on the future of Tcl. Clif is the author of the TclTutor package and the books Tcl/Tk for Real Programmers and Tcl/Tk: A Developer’s Guide. In addition to extensive programming work on Tcl, Clif offers Tcl/Tk training sessions with in-class exercises.

Clif first learned to program in high school in machine language on a Monroe 600 programmable calculator with 6 nixie tubes and hand-punched cards. He taught it to play Tic-Tac-Toe–according to him, “badly.” In college he flipped to the opposite end of languages and learned APL.

Clif started programming professionally in FORTRAN in 1978 and quickly added assembler, BASIC, C and C++ to his repertoire. He started shell programming in 1985, picked up Perl in 1995 and finally Tcl in 1996. He’s been a Tcl devotee ever since.

With Clif’s extensive background, we asked him about the future of Tcl. Here’s seven reasons why the future of Tcl is bright.

1:  Tcl is still the king of rapid prototyping

Clif is a big fan of Tcl for rapid prototypes that actually work. NBC Broadcasting studios uses Tcl/Tk to control what you see. They went to GE Research (and others) with a half-baked design and some examples of the clipboards and tapes they were using. The GE engineers took those and hacked out a quick Tk app that had a working clock and could pop up messages like “Commercial break – 30 seconds,” “Resume program,” etc., to demonstrate how it would look and work.

They did this while the sales guys and NBC managers were discussing what a potential schedule would look like. To quote the guy who ran the project, “When you’ve got a working prototype before there’s a schedule, you’ve cinched being awarded a contract.”  

Clif himself states:

“That’s what attracted me to Tcl/Tk. I spent the 1980s and early ’90s developing applications in C, C++, MS Windows and X-Windows. After a few days with Tcl I was building apps in an evening that I’d been budgeting months for.”

2: Tcl is amazing at prototyping Android and IoT apps

Christian Werner introduced Tcl/Tk on the Android platform in early 2014 and that opened a big domain for full-functioned applications that you can develop in an evening or two. One of the big challenges with using Tcl for mobile was in optimizing it for long battery life. Tcl is getting many enhancements to make it a good fit for Android mobile devices.  For example,  Bluetooth 4.0, also known as Bluetooth Low Energy, is supported by Tcl external libraries in Android versions from 4.3.

3: Tcl is awesome for UX-focused design models

One of the design paradigms that Tcl was early to adopt is the hybrid app, where some of the functionality is handled in a compiled language while the user interface and config options are handled in an interpreted language.

The strength of this design is that the computationally heavy parts of a program are generally well understood and stable, while the GUI and options grow as users become familiar with a product and try to do more with it. Thus, putting the stable parts of the code in slow-to-develop compiled languages and the dynamic parts in an interpreter gives development and runtime advantages.

4: Tcl is perfect for DevOps tools configuration

Tcl is great for configuration of DevOps tools, similar to how Bash, Perl, Ruby and more recently JavaScript with node.js are often used in this role. Writing configuration files was the initial purpose for Tcl. Even as newer languages like Groovy start to get used for DevOps, we’re reminded of the strengths of Tcl in this role. In many ways, Groovy looks like another reinvention of the Tcl wheel, but with Algol syntax and Java.

5: Tcl dominates the EDA and FPGA markets + leverages hot IoT trends

You’ll get no argument, Tcl is solid as a mature language in vertical testing and EDA markets. It’s embedded in a lot of commercial products where the users never know Tcl exists. Cisco, for example, uses it extensively internally. Tcl is also the base scripting language for some Cadence tools, Mentor Graphics ModelSim, HP and IBM EDA design.

And this isn’t just FPGA:  it’s all electronic design, including CMOS, NMOS, GaS, etc, which means as sensors and smaller smart connected devices proliferate, Tcl’s utility will continue to spread. Tcl will be an important tool for building IoT devices.

6: Tcl gets the job done, hidden in plain sight

People use Tcl to get the job done and are often quiet about it. For script programmers, Clif finds that Tcl is popular among engineers or scientists who program and get their job done quietly.  Companies using Tcl include A10, Cisco, Fidessa (financial software) Flightaware, F5, Massive (Orcs in Lord of the Rings), and Tivo. Tcl is used in NASA missions and CAD for automotive design. A lot of the telephone voice recognition units use Tcl for things like: “Para Español, Marque Número Dos.

7: Tcl can be taught quickly and is supported with commercial tools

Based on Clif’s extensive experience training people on Tcl, he knows that students “can come up to speed in a day.”

Clif offers Tcl/Tk training sessions with in-class exercises. He gives the students a commercial editor, optimized for Tcl programming, called Komodo. They use it during the training because it provides them with simple syntax checking as well as command completion. These two features are extremely useful for beginner users who forget syntax or how to spell a command. It enhances their ability to concentrate on problem solving with the language, instead of wasting time looking up options or argument order. ActiveState, the developers of Komodo IDE also make a commercial, fully supported distribution of Tcl called ActiveTcl, which is also available for free for community (individuals and non-production) use.

Tcl: the right language in many cases

Tcl is simple to learn and simple to use. Although this simplicity has potential downsides with large projects, it’s a huge advantage for rapid prototyping and as a configuration language. Tcl is a mature language with mature tools. Commercial support is available for both the tools and the language distribution itself. Tcl is being used in new areas such as DevOps and configuration.

The future really is bright for Tcl, a language that gets it done without a lot of flash. And it’s been doing so for a long time. If you don’t already know Tcl, you should give it a look. If you’re already familiar with Tcl, say hi to your old friend again. You’ll remember how good it feels to get working projects done in a day.

7 Reasons the Future of Tcl is Bright

| Mind the Geek| 5,144 views | 19 Comments
About The Author
-

19 Comments

  • Anonymous
    Reply

    1. As it’s correctly stated, it’s ranked outside the Top 50 in the TIOBE
    Index. What follows is you can almost never find libraries/modules
    to solve the task at hand, and if you do, they are frequently buggy and
    unsupported. So, be prepared to reinvent a lot of wheels.

    2. Tcl/Tk is very buggy (it’s a fact, https://core.tcl.tk/tcl/rptview?rn=25
    shows 588 open TCL bugs now), from my experience you’ll hit
    a Tcl/Tk bug per 2000 lines of tcl code you write. Then, even if you
    report it, most probably the fix won’t arrive soon (or not at all). So, get
    ready to code workarounds.

    3. “Putting the stable parts of the code in slow-to-develop compiled languages
    and the dynamic parts in an interpreter gives development and runtime
    advantages.” First, show me a good tutorial how to do it in nontrivial
    cases (I’ve seen how to move 2+2 calculation to C, thanks). Next, if you
    start using C extensions and need it to work cross-platform, welcome
    to cross-platform C development and deployment (it’s _far_ harder than using
    tcl alone).

    4. Tk GUI is fast for prototyping, sure. But if you want to actually use it,
    you’ll discover it’s slow (especially on Windows) and primitive — go on,
    try ttk::treeview to get a feeling (I still can’t believe it was written
    by Joe English who also created excellent starkits/starpacks).

    5. It accumulated some counter-productive and half-backed features over the
    years, and some of them are kept because of “backward-compatibility above
    all else”.

    6. Documentation and support: the wiki is full of outdated and deprecated (or
    just plain wrong) information, comp.lang.tcl usually is a very polite and
    supportive community, but these qualities aren’t enough to help you to
    solve you Tcl/Tk problem.

    7. Do you really think you have a real chance finding any job using it? ;(

    • Tom Radcliffe
      Reply

      I’m Director of Engineering at ActiveState, and ActiveTcl is a great product, so I won’t pretend to be unbiased.

      That said, here are some thoughts on the points you raise:

      > 1. As it’s correctly stated, it’s ranked outside the Top 50 in the TIOBE
      > Index. What follows is you can almost never find libraries/modules
      > to solve the task at hand, and if you do, they are frequently buggy and
      > unsupported. So, be prepared to reinvent a lot of wheels.

      Although Tcl may not be seen as “mainstream”, it is still very popular and is being maintained. Several years back a short blog post by ActiveState (Where is Tcl Hiding: http://www.activestate.com/blog/2010/02/where-tcl-hiding) drew attention to some of the places you might find Tcl.

      Some of the modules may be a little out of date, but if people show interest in some, there’s always an opportunity to update them/work wtih ActiveState to get them up to snuff: http://www.activestate.com/activetcl/tcl-tk-modules.

      > 2. Tcl/Tk is very buggy (it’s a fact, https://core.tcl.tk/tcl/rptview?rn=25
      > shows 588 open TCL bugs now), from my experience you’ll hit
      > a Tcl/Tk bug per 2000 lines of tcl code you write. Then, even if you
      > report it, most probably the fix won’t arrive soon (or not at all). So, get
      > ready to code workarounds.

      All languages have bugs, and much depends on severity of bugs. For instance, Java has hundreds of open bugs, Python has over 5000 (https://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid&ignore=file%3Acontent&%40search_text=&submit=search&status=-1%2C1%2C3), and even Node.JS has 600+ (https://github.com/nodejs/node-v0.x-archive/issues). Again, if you are looking for commercially supported, more seamless Tcl, you can always turn to ActiveState’s ActiveTcl, where bugs are resolved by a company rather than the open source crowd: http://activestate.com/activetcl.

      > 3. “Putting the stable parts of the code in slow-to-develop compiled languages
      > and the dynamic parts in an interpreter gives development and runtime
      > advantages.” First, show me a good tutorial how to do it in nontrivial
      > cases (I’ve seen how to move 2+2 calculation to C, thanks). Next, if you
      > start using C extensions and need it to work cross-platform, welcome
      > to cross-platform C development and deployment (it’s _far_ harder than using
      > tcl alone).

      First, not everyone needs to be cross-platform, so while in the worst case there is no doubt hard problems are hard, for people who aren’t cross-platform (rapid prototypers, for example) or who don’t need C extensions, or who are comfortable developing on more than one platform (which isn’t as hard as many people make it out to be, especially in C) then Tcl is an excellent choice.

      Second, ActiveState provides excellent cross-platform support (Windows 32/64, Linux 32/64, OXS, Solaris, AIX, HP-UX…) for many popular Tcl modules. Some of this support (on older Unixes in particular) is only available in our commercial offerings.

      > 4. Tk GUI is fast for prototyping, sure. But if you want to actually use it,
      > you’ll discover it’s slow (especially on Windows) and primitive — go on,
      > try ttk::treeview to get a feeling (I still can’t believe it was written
      > by Joe English who also created excellent starkits/starpacks).

      Rapid prototyping is an enormously important problem in UI/UX development. Being able to show a user potential UI solutions immediately vastly shortens development time. It’s great that you agree that Tcl/Tk solves that important problem very well!

      But it’s important to realize that compared to many other UI solutions in dynamic languages, Tcl/Tk is no slouch. It is easily six times faster than wxPython, for example. That makes it practical on small-footprint systems where the only other option would be a complied language like C++ or C: http://www.activestate.com/blog/2015/10/python-gui-programming-wxpython-vs-tkinter

      It’s true that no one will ever accuse Tcl of taking Perl’s “Swiss Army Chainsaw” approach to computing, but that’s what makes it easy to learn and practical for people like engineers and scientists to use.

      > 5. It accumulated some counter-productive and half-backed features over the
      > years, and some of them are kept because of “backward-compatibility above
      > all else”.

      As we’ve seen with the Modern Perl movement, practising sound, proven disciplines is the key to clean development in languages with legacy features. Simply because a language contains a feature does not put any obligation on developers to use them, and increasingly programmers in the dynamic languages community are taking this lesson to heart. Furthermore, all languages more than a few years old have some “interesting” legacy bits, and our experience with the Python 2 => 3 transition as well as the long deprecation path in C++ make it clear that the choice between maintaining them and breaking backward compatibility is not an easy or obvious one.

      > 6. Documentation and support: the wiki is full of outdated and deprecated (or
      > just plain wrong) information, comp.lang.tcl usually is a very polite and
      > supportive community, but these qualities aren’t enough to help you to
      > solve you Tcl/Tk problem.

      No question: documentation is a legitimate issue, and ActiveState is working to rectify it. Outdated documentation has always been a problem for open source projects, and Tcl/Tk does not break from tradition in this regard.

      > 7. Do you really think you have a real chance finding any job using it? ;(

      Indeed, there are lots of “real jobs” related to Tcl. In addition to the “Where is Tcl Hiding” mentioned above, Tcl is also being used at large entities like Lockheed Martin, GE aviation, NASA, DataPath, Alcatel-Lucent, and the US military — just to name a few. The ASIC community also heavily relies on it; in fact, Tcl is the de facto scripting language in the FPGA and ASIC EDA world.

      • Anonymous
        Reply

        Excuse me for multiposting here. 🙁

        > ActiveTcl is a great product, so I won’t pretend to be unbiased.
        You (ActiveTcl) are doing a lot for Tcl/Tk community, I’d like to thank you for that.

        > Although Tcl may not be seen as “mainstream”, it is still very popular and is
        > being maintained.
        Ahem, “in fact, it’s ranked outside the Top 50 in the TIOBE Index”. What’s
        your definition for word “popular” (just kidding)?

        > Some of the modules may be a little out of date …
        I’m sorry, but _this_ is underestimation.

        > All languages have bugs, and much depends on severity of bugs.
        Care to name one in TeX? 😉 Seriously, you are right, I’ve probably
        exaggerated the problem, but, IMHO Tcl/Tk defects get less attention than they
        should (and the bugs ratio I reported holds _just for me_.)

        I meant Tcl could be made better by going through reported bugs, fixing (or
        just closing unreproducible, etc.) them and maintaining bugtracker in future.
        What do you think?

        > Again, if you are looking for commercially supported, more seamless Tcl, you
        > can always turn to ActiveState’s ActiveTcl, where bugs are resolved by a
        > company rather than the open source crowd: http://activestate.com/activetcl.
        Do you provide “core tcl” binary distribution that differs from upstream (has
        some bugs fixed)?

        > or who are comfortable developing on more than one platform
        > (which isn’t as hard as many people make it out to be, especially in C) then
        > Tcl is an excellent choice.
        I did that, and it seems to me as hard as many people make it out to be. 😉

        > It’s great that you agree that Tcl/Tk solves that important problem very well!
        Sure. 🙂

        > But it’s important to realize that compared to many other UI solutions in
        > dynamic languages, Tcl/Tk is no slouch. It is easily six times faster than
        > wxPython, for example.
        I didn’t know that, thanks. But why can’t it be compared to C/C++ UI solutions?

        Citing from the wiki:
        > Tk was developed under X Window. The initial ports to Windows and Macintosh
        > relied upon an X Window emulation. But an architectural mismatch between the
        > two systems resulted in relatively poor performance on Windows. The situation
        > is improving, and many in the Tcl community are considering new Tk
        > implementations that would eliminate this problem.

        So, I thought improvement _is_ possible…

        > Simply because a language contains a feature does not put any obligation on
        > developers to use them, and increasingly programmers in the dynamic languages
        > community are taking this lesson to heart.

        This is the argument in languages’ features discussions I actually don’t like
        much. The thing is, you (or your whole team) can decide not to use “bad”
        feature A or B, but you can’t force all other developers in the world to do
        the same, so if you need to use their code, you’d have to rewrite it or “build
        a fence” to protect you clean code from all that dirt. 😉 But if you throw
        these features out of the language, they don’t have a chance to use them. 😉

        > Furthermore, all languages more than a few years old have some “interesting”
        > legacy bits, and our experience with the Python 2 => 3 transition as well as
        > the long deprecation path in C++ make it clear that the choice between
        > maintaining them and breaking backward compatibility is not an easy or obvious one.

        That’s true… But am I obliged to look at things like this forever, then (it’s Tk, I know, but anyway)?

        ttk::treeview .tree
        grid .tree -sticky nsew
        .tree tag configure myfont -font {Arial 28}
        .tree insert {} end -text “first item” -tag myfont
        .tree insert {} end -text “second item” -tag myfont

        Why is it considered “normal”, at all?

        > Indeed, there are lots of “real jobs” related to Tcl. In addition to the
        > “Where is Tcl Hiding” mentioned above, Tcl is also being used at large
        > entities like Lockheed Martin, GE aviation, NASA, DataPath, Alcatel-Lucent,
        > and the US military — just to name a few. The ASIC community also heavily
        > relies on it; in fact, Tcl is the de facto scripting language in the FPGA and
        > ASIC EDA world.

        “Related” isn’t the kind of jobs I was referring to here… I mean, you could
        find a lot of offers like “Java Developer”, “C++ developer”, etc. But Tcl/Tk
        is almost always “related” to something, i.e. you must be EDA engineer (and
        it’s good if you know Tcl a little) or someone like that, Tcl/Tk isn’t
        “primary” skill unlike Java/.NET/C++…

    • Donal Fellows
      Reply

      I see that you are a man or woman without the courage of your convictions to put your name and your professional reputation to what you say. I will therefore not address the majority of your points on the grounds that they appear to be ill-founded bile, straight from the central school of Fear, Uncertainty and Doubt. But there are a few points that I will respond to.

      Cross-platform development in multiple languages *is* harder than in Tcl alone. While it is Tcl’s “fault” that it has a good C API, it isn’t Tcl’s fault that C is rather harder to make portable. C++ is unfortunately worse; though the language has come on in leaps and bounds in recent years, this has created a number of “interesting” problems with making reliable builds using it. Other languages like Java and C# are problematic in other ways (you’re either inside their model or you’re outside it; being outside is a world of hurt).

      If you want no-fee support, one of the better venues is Stack Overflow. Be sure to use the ‘tcl’ tag if you do so, and remember that you need to think carefully to formulate your question in a way that can be answered, as per general Stack Overflow rules. Most questions get answered within a few hours (though longer at the weekend) and the ones that don’t are usually rather specialised, requiring knowledge of additional uncommon tools to answer properly. We’ll let you know (and apologise) if that is the case. More diffuse questions or requests for general assistance are better directed elsewhere, whether to commercial support (e.g., by ActiveState) or to comp.lang.tcl.

      I’m happy to debate the obsolete/deprecated features, but only for concrete cases. I will not discuss vague unspecifics; it’s just not my personality type. 🙂

  • Sean Woods
    Reply

    Dear reader: please ignore Mr. Anonymous. He throws around a lot of strangely specific observations that are downright wrong, horribly out of date, and with a selective memory that rivals a politician with a full frontal lobotomy.

    1) Tcl is used in production in everything from oil platforms to spacecraft. By his (or her?) definition Linux would be considered an abject failure, and the Windows operating system completely unusable. And yet we seem to survive. Tcl has a defect tracking system for the same reason as other major projects. And when something terrible is found it is fixed. Rather quickly, and I speak as one who puts his livelihood on the line developing in Tcl.

    2) (Mr|Ms) Anonymous is just pulling a raw statistic out of air, with no context. Everything from “I’d like the default font to be Comic Sans on Windows” to “I think this might be a problem, at midnight, on the third Sunday of the new moon… but I can’t repeat it” is classified as a “ticket”. You fill find nothing listed as “critical” that has not been addressed. And again, I speak as one who actually uses Tcl. Everyday. For a living.

    3) Well you could do what any other reasonable programmer would do, and look at one of the many C extensions for Tcl that do exist. It’s not like we don’t post the source code. With build instructions. Nor are there entire chapters of books devoted to the subject. Or, maybe posting venom anonymously online works for you? We all have different learning styles, I suppose.

    4) I guess my day to day experience, and that of the users of the software I write is just a delusion. Because we generally find Tk to be fast enough. Yes, I every once in a while manage to do something stupid to slow things down. But our software manages to sling a few thousand screen elements at a go, and present some pretty complex dialogs. But hey, my own experience as a competent programmer is pale in comparison to your brilliance and insight as a keyboard commando.

    5) Examples or go the (bleep) home. The Tcl core does a lot of things right by design. And yes, some of those design elements are 30 years old. I suppose Calculus is getting long in the tooth too. That’s so 18th century. In the core, I’ll arm wrestle anyone who tries to tell me bits of it are too outdated to use. Now… extensions that were written for Tcl is another story entirely. And I do have to concede that my old extension to provide serial port support to pre-osx macs doesn’t compile anymore. And when some time continuum blip puts be back in the 1990s, I’ll have to get right on that.

    6) And I suppose you get your Windows support from Stack Overflow? Yes the Wiki sucks. That’s why there is an entire separate website: http://www.tcl.tk, many books, AND THE ENTIRE “n” section of the Unix help system devoted to Tcl.

    7) Feel free to drop me a Resume. We can’t find enough Tcl developers.

    • Anonymous
      Reply

      Dear reader: please ignore Mr. Sean Woods. He is a Tcl fanboy.

      Who are you to f$#!g “classify” me, and, effectively, call me liar? ;(
      So, I think you deserve the tone of my answer.

      > Tcl is used in production in everything from oil platforms to spacecraft.

      You know, almost _anything_ (COBOL, assembler, … even PHP and VBA 😉 ) is
      used in production almost everywhere… It proves nothing at all!

      > By his (or her?) definition Linux would be considered an abject failure,
      > and the Windows operating system completely unusable.

      No, I didn’t say anything like that.

      My point here is: the language can be simple and elegant (Tcl is!),
      but _in practice_ the language is as good as its libraries,
      so I’m just stating: if you want to program it Tcl/Tk, be prepared
      for low-quality (or absent) libraries. And this is for a reason,
      low popularity means many Tcl/Tk libraries are abandoned
      or barely supported (due to lack of programmers and testers).

      BTW, my “selective memory” brings me some “interesting”
      memories like “conference-based” development, failed GSOC’s (then Tcl
      was still invited there, that is) and “excellent” Tcl/Tk Printing Support. 😉

      > Tcl has a defect tracking system for the same reason as other major projects.
      *What* is this reason?

      > (Mr|Ms) Anonymous is just pulling a raw statistic out of air, with no
      > context. Everything from “I’d like the default font to be Comic Sans on
      > Windows” to “I think this might be a problem, at midnight, on the third
      > Sunday of the new moon… but I can’t repeat it” is classified as a “ticket”.

      I strongly believe defect tracking system is QA tool for large projects, and
      if it’s _unmaintained_, it _doesn’t_ serve its purpose.

      IMHO, if you don’t maintain your defect tracking system and it’s not the
      integral part of your development cycle, you don’t care of the quality _no
      matter_ what you say!

      >You fill find nothing listed as “critical” that has not been addressed.

      So, if it doesn’t hang/crash Tcl, it’s not a bug? 😉

      > And again, I speak as one who actually uses Tcl. Everyday. For a living.

      Good for you (I envy 😉 ). But it doesn’t make you statements true.

      > And when something terrible is found it is fixed.
      > Rather quickly, and I speak as one who puts his livelihood on
      > the line developing in Tcl.

      No, it can be rather slow or not _at all_. _This_ is my point.

      For example (if I remember correctly) obvious regexp engine bugs stood unfixed
      *for years* before Tom Lane came in (we are really lucky that Tcl and
      PostgreSQL use almost the same code for regexp engine).

      Care to _prove_ your point?

      Having no (new) open bugs in trackers (Tcl and Tk) would easily prove it, by
      the way…

      > Well you could do what any other reasonable programmer would do, and look at
      > one of the many C extensions for Tcl that do exist. It’s not like we don’t
      > post the source code. With build instructions.

      I already _did_ that. I’m talking about newbies here.

      So, can you provide a link to a good tutorial how to do it in _nontrivial_
      cases or go the (bleep) home?

      And this: “cross-platform C development and deployment” awaits _everyone_ who wants to do it.

      And there is yet another problem with this approach (multi-language development):
      where to draw a line separating C code from Tcl code?

      > Nor are there entire chapters of books devoted to the subject.
      I’ve read ’em, you know. My sarcastic tone was partially provoked by that…

      > Or, maybe posting venom anonymously online works for you?
      Maybe ignoring arguments and making personal attacks works for you?

      > I guess my day to day experience, and that of the users of the software I
      > write is just a delusion. Because we generally find Tk to be fast enough.

      No, it’s not a delusion, but many toolkits out there are _much_ faster. This
      _problem_ was discussed in the community (remember TkGS?), “but the speed of
      the average PC has washed away most concerns.” Most is not all, unfortunately.

      > Yes, I every once in a while manage to do something stupid to slow things
      > down. But our software manages to sling a few thousand screen elements at a
      > go, and present some pretty complex dialogs.
      My software too, but sometimes it wasn’t achieved without “tricks”. (I
      invested more time than I would with faster toolkit). 😉

      > But hey, my own experience as a competent programmer is pale in comparison
      > to your brilliance and insight as a keyboard commando.
      You’re not the only competent programmer here.

      > Examples or go the (bleep) home.
      Get yourself as many as you like: http://wiki.tcl.tk/883

      > The Tcl core does a lot of things right by design.
      Of course it does, that’s why I love it! 🙂

      > And I suppose you get your Windows support from Stack Overflow?
      Well, this *is* funny (you have to suffer Microsoft support to understand
      it, though). Stack Overflow is usually good enough. 😉

      But I think I see your point…
      I confess I never used any Tcl paid support, did you?

      > http://www.tcl.tk, many books,
      Hmm, I admit http://www.tcl.tk became better, haven’t been there for long
      time…

      > AND THE ENTIRE “n” section of the Unix help system devoted to Tcl.
      Wow, Tcl/Tk even has _documentation_ (just kidding)!

      > Feel free to drop me a Resume. We can’t find enough Tcl developers.
      Where / how are you looking? I always thought there are more capable Tcl
      programmers than jobs out there…

    • Anonymous
      Reply

      Dear reader: please ignore Mr. Sean Woods. He is a Tcl fanboy.

      Who are you to “classify” me, and, effectively, call me liar? ;(
      So, I think you deserve the tone of my answer.

      > Tcl is used in production in everything from oil platforms to spacecraft.
      You know, almost _anything_ (COBOL, assembler, … even PHP and VBA 😉 ) is
      used in production almost everywhere… It proves nothing at all!

      > By his (or her?) definition Linux would be considered an abject failure,
      > and the Windows operating system completely unusable.
      No, I didn’t say anything like that.

      My point here is: the language can be simple and elegant (Tcl is!),
      but _in practice_ the language is as good as its libraries,
      so I’m just stating: if you want to program it Tcl/Tk, be prepared
      for low-quality (or absent) libraries. And this is for a reason,
      low popularity means many Tcl/Tk libraries are abandoned
      or barely supported (due to lack of programmers and testers).

      BTW, my “selective memory” brings me some “interesting”
      memories like “conference-based” development, failed GSOC’s (then Tcl
      was still invited there, that is) and “excellent” Tcl/Tk Printing Support. 😉

      > Tcl has a defect tracking system for the same reason as other major projects.
      *What* is this reason?

      > (Mr|Ms) Anonymous is just pulling a raw statistic out of air, with no
      > context. Everything from “I’d like the default font to be Comic Sans on
      > Windows” to “I think this might be a problem, at midnight, on the third
      > Sunday of the new moon… but I can’t repeat it” is classified as a “ticket”.
      I strongly believe defect tracking system is QA tool for large projects, and
      if it’s _unmaintained_, it _doesn’t_ serve its purpose.

      IMHO, if you don’t maintain your defect tracking system and it’s not the
      integral part of your development cycle, you don’t care of the quality _no
      matter_ what you say!

      >You fill find nothing listed as “critical” that has not been addressed.
      So, if it doesn’t hang/crash Tcl, it’s not a bug? 😉

      > And again, I speak as one who actually uses Tcl. Everyday. For a living.
      Good for you (I envy 😉 ). But it doesn’t make you statements true.

      > And when something terrible is found it is fixed.
      > Rather quickly, and I speak as one who puts his livelihood on
      > the line developing in Tcl.
      No, it can be rather slow or not _at all_. _This_ is my point.

      For example (if I remember correctly) obvious regexp engine bugs stood unfixed
      *for years* before Tom Lane came in (we are really lucky that Tcl and
      PostgreSQL use almost the same code for regexp engine).

      Care to _prove_ your point (having no (new) open bugs in trackers (Tcl and Tk) would easily prove it, by
      the way…).

      > Well you could do what any other reasonable programmer would do, and look at
      > one of the many C extensions for Tcl that do exist. It’s not like we don’t
      > post the source code. With build instructions.

      I already _did_ that. I’m talking about newbies here.

      So, can you provide a link to a good tutorial how to do it in _nontrivial_
      cases or go the (bleep) home?

      > Nor are there entire chapters of books devoted to the subject.
      I’ve read ’em, you know. My sarcastic tone was partially provoked by that…

      > Or, maybe posting venom anonymously online works for you?
      Maybe ignoring arguments and making personal attacks works for you?

      > I guess my day to day experience, and that of the users of the software I
      > write is just a delusion. Because we generally find Tk to be fast enough.

      No, it’s not a delusion, but many toolkits out there are _much_ faster. This
      _problem_ was discussed in the community (remember TkGS?), “but the speed of
      the average PC has washed away most concerns.” Most is not all, unfortunately.

      > Yes, I every once in a while manage to do something stupid to slow things
      > down. But our software manages to sling a few thousand screen elements at a
      > go, and present some pretty complex dialogs.
      My software too, but sometimes it wasn’t achieved without “tricks”. (I
      invested more time than I would with faster toolkit).

      > But hey, my own experience as a competent programmer is pale in comparison
      > to your brilliance and insight as a keyboard commando.
      You’re not the only competent programmer here.

      > Examples or go the (bleep) home.
      Get yourself as many as you like: wiki.tcl.tk/883

      > The Tcl core does a lot of things right by design.
      Of course it does, that’s why I love it! 🙂

      > And I suppose you get your Windows support from Stack Overflow?
      Well, this *is* funny (you have to suffer Microsoft support to understand
      it, though). Stack Overflow is usually good enough. 😉

      But I think I see your point…
      I confess I never used any Tcl paid support, did you?

      > http://www.tcl.tk, many books,
      Hmm, I admit http://www.tcl.tk became better, haven’t been there for long time…

      > AND THE ENTIRE “n” section of the Unix help system devoted to Tcl.
      Wow, Tcl/Tk even has _documentation_ (just kidding)!

      > Feel free to drop me a Resume. We can’t find enough Tcl developers.
      Where / how are you looking? I always thought there are more capable Tcl
      programmers than jobs out there…

  • Anonymous
    Reply

    Dear reader: please ignore Mr. Sean Woods. He is a Tcl fanboy.

    Who are you to f$#!g “classify” me, and, effectively, call me liar? ;(
    So, I think you deserve the tone of my answer.

    > Tcl is used in production in everything from oil platforms to spacecraft.
    Almost _anything_ (COBOL, assembler, … even PHP and VBA 😉 ) is
    used in production almost everywhere… It proves nothing at all!

    > By his (or her?) definition Linux would be considered an abject failure,
    > and the Windows operating system completely unusable.
    No, I didn’t say anything like that.

    My point here is: the language can be simple and elegant (Tcl is!),
    but _in practice_ the language is as good as its libraries,
    so I’m just stating: if you want to program it Tcl/Tk, be prepared
    for low-quality (or absent) libraries. And this is for a reason,
    low popularity means many Tcl/Tk libraries are abandoned
    or barely supported (due to lack of programmers and testers).

    BTW, my “selective memory” brings me some “interesting”
    memories like “conference-based” development, failed GSOC’s (then Tcl
    was still invited there, that is) and “excellent” Tcl/Tk Printing Support. 😉

    > Tcl has a defect tracking system for the same reason as other major projects.
    *What* is this reason?

    > (Mr|Ms) Anonymous is just pulling a raw statistic out of air, with no
    > context. Everything from “I’d like the default font to be Comic Sans on
    > Windows” to “I think this might be a problem, at midnight, on the third
    > Sunday of the new moon… but I can’t repeat it” is classified as a “ticket”.
    I strongly believe defect tracking system is QA tool for large projects, and
    if it’s _unmaintained_, it _doesn’t_ serve its purpose.

    IMHO, if you don’t maintain your defect tracking system and it’s not the
    integral part of your development cycle, you don’t care of the quality _no
    matter_ what you say!

    >You fill find nothing listed as “critical” that has not been addressed.
    So, if it doesn’t hang/crash Tcl, it’s not a bug? 😉

    > And again, I speak as one who actually uses Tcl. Everyday. For a living.
    Good for you (I envy 😉 ). But it doesn’t make you statements true.

    > And when something terrible is found it is fixed.
    > Rather quickly, and I speak as one who puts his livelihood on
    > the line developing in Tcl.
    No, it can be rather slow or not _at all_. _This_ is my point.

    For example (if I remember correctly) obvious regexp engine bugs stood unfixed
    *for years* before Tom Lane came in (we are really lucky that Tcl and
    PostgreSQL use almost the same code for regexp engine).

    Care to _prove_ your point?

    Having no (new) open bugs in trackers (Tcl and Tk) would easily prove it, by
    the way…

    > Well you could do what any other reasonable programmer would do, and look at
    > one of the many C extensions for Tcl that do exist. It’s not like we don’t
    > post the source code. With build instructions.
    I already _did_ that. I’m talking about newbies here.

    So, can you provide a link to a good tutorial how to do it in _nontrivial_ cases or go (bleep) home?

    And this: “cross-platform C development and deployment” affects _everyone_ who wants to do it.

    And there is yet another problem with this approach (multi-language development):
    where to draw a line separating C code from Tcl code?

    > Nor are there entire chapters of books devoted to the subject.
    I’ve read ’em, you know. My sarcastic tone was partially provoked by that…

    > Or, maybe posting venom anonymously online works for you?
    Maybe ignoring arguments and making personal attacks works for you?

    > I guess my day to day experience, and that of the users of the software I
    > write is just a delusion. Because we generally find Tk to be fast enough.

    No, it’s not a delusion, but many toolkits out there are _much_ faster. This
    _problem_ was discussed in the community (remember TkGS?), “but the speed of
    the average PC has washed away most concerns.” Most is not all, unfortunately.

    > Yes, I every once in a while manage to do something stupid to slow things
    > down. But our software manages to sling a few thousand screen elements at a
    > go, and present some pretty complex dialogs.
    My software too, but sometimes it wasn’t achieved without “tricks”. (I
    invested more time than I would with faster toolkit).

    > But hey, my own experience as a competent programmer is pale in comparison
    > to your brilliance and insight as a keyboard commando.
    You’re not the only competent programmer here.

    > Examples or go the (bleep) home.
    Get yourself as many as you like: http://wiki.tcl.tk/883

    > The Tcl core does a lot of things right by design.
    Of course it does, that’s why I love it! 🙂

    > And I suppose you get your Windows support from Stack Overflow?
    Well, this *is* funny (you have to suffer Microsoft support to understand
    it, though). Stack Overflow is usually good enough. 😉

    But I think I see your point…
    I confess I never used any Tcl paid support, did you?

    > http://www.tcl.tk, many books,
    Hmm, I admit http://www.tcl.tk became better, haven’t been there for a long time…

    > AND THE ENTIRE “n” section of the Unix help system devoted to Tcl.
    Wow, Tcl/Tk even has _documentation_ (just kidding)!

    > Feel free to drop me a Resume. We can’t find enough Tcl developers.
    Where / how are you looking? I always thought there are more capable Tcl
    programmers than jobs out there…

  • Anonymous_again
    Reply

    Dear reader: please ignore Mr. Sean Woods. He is a Tcl fanboy.

    Who are you to “classify” me, and, effectively, call me liar? ;(
    So, I think you deserve the tone of my answer.

    > Tcl is used in production in everything from oil platforms to spacecraft.

    You know, almost _anything_ (COBOL, assembler, … even PHP and VBA 😉 ) is
    used in production almost everywhere… It proves nothing at all!

    > By his (or her?) definition Linux would be considered an abject failure,
    > and the Windows operating system completely unusable.

    No, I didn’t say anything like that.

    My point here is: the language can be simple and elegant (Tcl is!),
    but _in practice_ the language is as good as its libraries,
    so I’m just stating: if you want to program it Tcl/Tk, be prepared
    for low-quality (or absent) libraries. And this is for a reason,
    low popularity means many Tcl/Tk libraries are abandoned
    or barely supported (due to lack of programmers and testers).

    BTW, my “selective memory” brings me some “interesting”
    memories like “conference-based” development, failed GSOC’s (then Tcl
    was still invited there, that is) and “excellent” Tcl/Tk Printing Support. 😉

    > Tcl has a defect tracking system for the same reason as other major projects.
    *What* is this reason?

    > (Mr|Ms) Anonymous is just pulling a raw statistic out of air, with no
    > context. Everything from “I’d like the default font to be Comic Sans on
    > Windows” to “I think this might be a problem, at midnight, on the third
    > Sunday of the new moon… but I can’t repeat it” is classified as a “ticket”.

    I strongly believe defect tracking system is QA tool for large projects, and
    if it’s _unmaintained_, it _doesn’t_ serve its purpose.

    IMHO, if you don’t maintain your defect tracking system and it’s not the
    integral part of your development cycle, you don’t care of the quality _no
    matter_ what you say!

    >You fill find nothing listed as “critical” that has not been addressed.

    So, if it doesn’t hang/crash Tcl, it’s not a bug? 😉

    > And again, I speak as one who actually uses Tcl. Everyday. For a living.

    Good for you (I envy 😉 ). But it doesn’t make you statements true.

    > And when something terrible is found it is fixed.
    > Rather quickly, and I speak as one who puts his livelihood on
    > the line developing in Tcl.

    No, it can be rather slow or not _at all_. _This_ is my point.

    For example (if I remember correctly) obvious regexp engine bugs stood unfixed
    *for years* before Tom Lane came in (we are really lucky that Tcl and
    PostgreSQL use almost the same code for regexp engine).

    Care to _prove_ your point?

    Having no (new) open bugs in trackers (Tcl and Tk) would easily prove it, by
    the way…

    > Well you could do what any other reasonable programmer would do, and look at
    > one of the many C extensions for Tcl that do exist. It’s not like we don’t
    > post the source code. With build instructions.

    I already _did_ that. I’m talking about newbies here.

    So, can you provide a link to a good tutorial how to do it in _nontrivial_
    cases or go the (bleep) home?

    And this: “cross-platform C development and deployment” awaits _everyone_ who
    wants to do it.

    And there is yet another problem with this approach (multi-language
    development): where to draw a line separating C code from Tcl code?

    > Nor are there entire chapters of books devoted to the subject.
    I’ve read ’em, you know. My sarcastic tone was partially provoked by that…

    > Or, maybe posting venom anonymously online works for you?
    Maybe ignoring arguments and making personal attacks works for you?

    > I guess my day to day experience, and that of the users of the software I
    > write is just a delusion. Because we generally find Tk to be fast enough.

    No, it’s not a delusion, but many toolkits out there are _much_ faster. This
    _problem_ was discussed in the community (remember TkGS?), “but the speed of
    the average PC has washed away most concerns.” Most is not all, unfortunately.

    > Yes, I every once in a while manage to do something stupid to slow things
    > down. But our software manages to sling a few thousand screen elements at a
    > go, and present some pretty complex dialogs.
    My software too, but sometimes it wasn’t achieved without “tricks”. (I
    invested more time than I would with faster toolkit). 😉

    > But hey, my own experience as a competent programmer is pale in comparison
    > to your brilliance and insight as a keyboard commando.
    You’re not the only competent programmer here.

    > Examples or go the (bleep) home.
    Get yourself as many as you like: http://wiki.tcl.tk/883

    > The Tcl core does a lot of things right by design.
    Of course it does, that’s why I love it! 🙂

    > And I suppose you get your Windows support from Stack Overflow?
    Well, this *is* funny (you have to suffer Microsoft support to understand
    it, though). Stack Overflow is usually good enough. 😉

    But I think I see your point…
    I confess I never used any Tcl paid support, did you?

    > http://www.tcl.tk, many books,
    Hmm, I admit http://www.tcl.tk became better, haven’t been there for long
    time…

    > AND THE ENTIRE “n” section of the Unix help system devoted to Tcl.
    Wow, Tcl/Tk even has _documentation_ (just kidding)!

    > Feel free to drop me a Resume. We can’t find enough Tcl developers.
    Where / how are you looking? I always thought there are more capable Tcl
    programmers than jobs out there…

  • Richard Hipp
    Reply

    The most widely deployed database engine in the world (SQLite – https://www.sqlite.org/) is really a TCL extension that has escaped into the wild. There is no TCL code in SQLite nor do programs that use SQLite require TCL, but TCL is required to build the SQLite amalgamation (sqlite3.c) from canonical sources, and TCL is required for testing of SQLite (https://www.sqlite.org/testing.html). SQLite would not exist except for TCL.

    Behind the scenes, TCL (and Tk) is used by the SQLite development team for many other activities. Most of the SQLite code was written using a customized text editor that is a pure Tk script. The SQLite developers keep in touch using Tcl/Tk-based chat software. The version control system used by SQLite (Fossil – https://www.fossil-scm.org/) does not directly link against Tcl, but it uses Tcl as part of its build process and commonly used command-line options (fossil diff –tk) make use of Tcl/Tk in a separate process.

  • Dan Burke
    Reply

    I’ve been programming for fifty years(1965-Today) and have used numerous
    languages(Fortran-66, Dec-10/20 Assembly, Pascal, C, COBOL, Forth, Perl, Python, Vax-Assembly, R, Fortran 90, and
    last but not least Tcl/Tk). I’m somewhat new to Tcl but have been using it for a couple of years. I rate it as the
    very finest language of them all!

    I wish I had it when I started programming. I’m sure of it’s usefulness and it’s ease of development.

    Thank you to the movers and shakers of Tcl/Tk, You have my greatest respect.

  • Dimitri Minaev
    Reply

    Indeed, Tcl is a great tool for DevOps. I use it for scripting administration tasks and monitoring various parts of the infrastructure. But the developers are so eager to embrace new technologies in their projects that Tcl too often falls behind and doesn’t provide libraries to support these technologies. For example, Memcache and AMQP. While Memcache protocol is text-based and may be easily hacked using sockets, lack of support for AMQP sometimes makes me drop Tcl in favor of Python.

  • Arjen Markus
    Reply

    I am probably an uncharacteristic user of Tcl, as I use it and have been using for data analysis and graphical presentation for many years now. Even for number crunching at a small scale :). It is one of my favourite programming languages. It was fun to read the interview with Clif, even if it does not cover precisely the things I myself do with it. What may not be evident from the interview – but that was about the language itself and its use – is that the Tcl community is surprisingly friendly and relaxed. They are quite willing to help you, if you show at least the intention to learn.

  • Andrew Mangogna
    Reply

    I have used Tcl on and off since the mid 1990’s. I have drifted in and out of using Tcl but in recent years do most of my work in Tcl. There is a simple reason for that. It works! At least for me. Tcl is a distinctly different type of programming language. It is a command language with minimal syntax and is highly dynamic in everything that it does. That Tcl has very minimal syntax means that you need not learn everything about the language before you can begin to solve problems. It is very approachable and simple problems yield simple solutions. That it is very dynamic means that it is capable of being the ultimate glue language between disparate parts that were not necessarily designed to work together. It is, for me, an invaluable tool in my box.

    Sadly, Tcl is a very misunderstood language. It has many deep and serious programming language features and has been enhanced and maintained for many years by very capable people. Yet, old perceptions of what Tcl does and doesn’t do abound. I only hope folks will ignore the FUD that is out there about Tcl and just try the language to see if it solves their problem. I suspect they will be pleasantly surprised.

  • yves guerin
    Reply

    Dear,

    I find a job with Tcl/Tk and my UNIX experience, I worked in the health domain with Cloverleaf (infor), Tcl/Tk is a great language, cisco router used Tcl too. Remember perl and python use tkinter (tk) to get the graphic interface stuff, so it ‘s not so bad 🙂

    Regards

    Yves

  • Amit Dave
    Reply

    I have worked with C/C++, PHP, VB, Fortran, Pascal, Qt, BASIC, Assembly 808x and 68K languages and X-Windows, VC++/Qt GUI devkits. I came across Tcl/Tk around year 2006-07. I started with version 8.2. Believe me, it has solved almost all of my problems. Ranging from Serial port access to network socket based applications, all works and all works flawlessly. On the GUI front it is extremely simple. Your XWindows code of 1000s of lines shrinks to just few lines. Syntax wise it is simpler than Python.

    Whereever one needs testing, repeated testing, tests in different conditions, I feel it has to be Tcl. Its simplicity turns even a non-productive programmer into a delivering engineer. I have not come across any sorts of bugs from version 8.2 onwards. In my client-server application design, server side is entirely Tcl/Tk and works smoothly, without restarting, no memory leakage etc. Extremely simple to learn makes even a new enterant, a useful asset in the project. I have even tried AndroWish (wish on Android). I ported (read: copied 🙂 ) on Android device and it gets going. Cross platform support on Windows/Linux is smooth. My apps run on both Win/Lin environment without trouble.

    There are things like OraTcl package which becomes very handly to interface with the database like Oracle. Packages like tcllib, tdom(for XML), http and tclhttpd are excellent handy tools for server side apps.

    If someone is thinking of a continously running server side apps, gluing Linux commands together, network support, database connectivity, consider development using Tcl/Tk.

  • Gunes Koru
    Reply

    Our research area is biomedical informatics and we enjoy using Tcl/Tk in academic setting to develop prototypes. Though, these are not dock-taped prototypes, they turn out to be really serious and nice executable packages due to the power of Tcl/Tk. Students get it instantly and become productive. There are certainly libraries and documentation. We also enjoy reading the wiki to see a historical evolution of ideas. Other languages do not have a similar resource. The language is east, GUI development support is excellent (other languages have libraries that adopt Tk anyway), the event loops are wonderful. network programming is easy. The only thing we wish is we wish we had started using it earlier! Feel free to contact me if you would like to learn nore about our experiences.
    Dr. Koru
    Information Systems
    University of Maryland, Baltimore County

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>