Why You Should Not Use Tcl (1994) | Hacker News Reader

Why You Should Not Use Tcl (1994)

groups.google.com

43 pointsaragonite52 comments

I had to use TCL at a company where Prof. Ousterhout was on the board. I had used it a bit at university but I was coming from a Python job so, naturally, I hated its syntax BUT:

1. The project was in ancient C++ for many reasons and even the most modern C++ is at least 5x more difficult to write code in than TCL. So why write code that runs once in the life of the program in C++? There's often plenty of code that doesn't benefit from being compiled - that looks for a configuration file, reads and validates lines and calls functions to build initial datastructures...setup code, string handling. You save a millisecond or two by doing it in C++ but only once in a program that runs for hours - why waste all that dev/debug effort?

If you choose judiciously then you can end up doing a lot of your performance insensitive, setup-type code in TCL and a great deal of the time you'll be able to debug and fix bugs in an interpreted language without recompiling anything.

2. Python, though great, has a global interpreter lock. TCL fits in with threaded programs excellently. This can be a make-or-break feature.

3. TCL's syntax which I dislike, seems to map excellently into C - calling C from TCL just seems a lot easier than in python.

> 2. Python, though great, has a global interpreter lock. TCL fits in with threaded programs excellently. This can be a make-or-break feature.

Tcl's threading and event management are indeed standout features. It excels in threaded programs, thanks to its robust C API, especially functions like Tcl_ThreadQueueEvent ( https://www.tcl.tk/man/tcl9.0/TclLib/Notifier.html ).

There is another currently new hacker news thread [1] referencing this post [2] where the influence of the performance of the GIL is evaluated. It seems not so large, of course depending on the tasks performed by the interpreted part.

At a former workplace we had a C/C++ application which allowed integration of customer code via TCL which worked well and had acceptable performance even with the TCL code in a hot path of the application code.

Inspired from this I once did a C/Perl integration, but the Perl code was minimal (just user exists with special case handling) and Perl is another language disliked by many today. But the program was written around the 2000 and Perl was more widespread without additional installations on the target systems and far better than any ksh/sed/awk combination.

But it worked well too.

[1] https://news.ycombinator.com/item?id=41006946

[2] https://www.maartenbreddels.com/perf/jupyter/python/tracing/...

Recent and related:

A brief interview with Tcl creator John Ousterhout (2023) - https://news.ycombinator.com/item?id=41017367 - July 2024 (56 comments)

Previous discussions of current submission:

Why you should not use Tcl (1994) - https://news.ycombinator.com/item?id=14944103 - Aug 2017 (52 comments)

Why you should not use Tcl (1994, "The Tcl War") - https://news.ycombinator.com/item?id=7071479 - Jan 2014 (1 comment)

Here's another good TCL War discussion from July 3 2016:

https://news.ycombinator.com/item?id=12025218

https://vanderburg.org/old_pages/Tcl/war/

Also part 2:

https://vanderburg.org/old_pages/Tcl/war2/index.html

https://news.ycombinator.com/item?id=12027092

DonHopkins on July 3, 2016 | parent | context | favorite | on: The Tcl War (1994)

>Around the time leading up to the TCL war, Lua was peacefully and quietly born in a manger at the Pontifical Catholic University of Rio de Janeiro, Brazil:

>"In 1993, the only real contender was Tcl, which had been explicitly designed to be embedded into applications. However, Tcl had unfamiliar syntax, did not offer good support for data description, and ran only on Unix platforms. We did not consider LISP or Scheme because of their unfriendly syntax. Python was still in its infancy. In the free, do-it-yourself atmosphere that then reigned in Tecgraf, it was quite natural that we should try to develop our own scripting language ... Because many potential users of the language were not professional programmers, the language should avoid cryptic syntax and semantics. The implementation of the new language should be highly portable, because Tecgraf's clients had a very diverse collection of computer platforms. Finally, since we expected that other Tecgraf products would also need to embed a scripting language, the new language should follow the example of SOL and be provided as a library with a C API."

http://www.lua.org/doc/hopl.pdf

https://news.ycombinator.com/item?id=29379272

>For Netscape in 1995, I believe Python would have been a better choice than JavaScript, but Lua would have been an even better choice, given how much smaller, simpler, and more efficient Lua is, and the eventual excellence of LuaJIT. (If only Lua indexed its array from 0 instead of 1...)

But Python and Lua didn't "look like Java" enough for Netscape. [...]

From the discussion yesterday I wrote in response to the question "What have been the pros and cons of Tcl for you, compared with other scripting languages if you have experience with them?":

https://news.ycombinator.com/item?id=41019519

>DonHopkins 11 hours ago | parent | context | favorite | on: A brief interview with Tcl creator John Ousterhout...

>Here's a transcript of a keynote I gave to the Toronto Usenix symposium, where I talked about the pros and cons of TCL/Tk, from developing multi-player SimCity with it around 1993.

>A lot has changed since then, but in 1993 it was so much better than Motif and every other alternative in so many ways.

https://www.donhopkins.com/home/catalog/simcity/keynote.html

[...]

And a discussion of "Guile - The Failed Universal Scripting Language (lists.gnu.org)" from April 14, 2010:

https://news.ycombinator.com/item?id=1265104

https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00...

With this in-depth post by the late Tom Lord:

https://news.ycombinator.com/item?id=1266032

>Huh. Well, that's me (Tom Lord). So, what can I add here for HN? [...]

Where Tcl and Tk Went Wrong (2010)

https://news.ycombinator.com/item?id=14941525

https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...

Extending Tcl (tcl.tk)

https://news.ycombinator.com/item?id=17059077

http://wiki.tcl.tk/6276

And this discussion of "The Birth of TCL":

https://news.ycombinator.com/item?id=31111220

http://www.tcl.tk/about/history.html

Where I posted this excerpt from something Tom wrote about on his blog:

https://news.ycombinator.com/item?id=31117713

DonHopkins on April 22, 2022 | parent | context | favorite | on: The Birth of Tcl

The Tcl War (1994) (vanderburg.org) https://news.ycombinator.com/item?id=12025218

https://vanderburg.org/old_pages/Tcl/war/

https://news.ycombinator.com/item?id=17060181

pwg on May 13, 2018 | parent | context | favorite | on: Extending Tcl

Why you should not use Tcl

https://wiki.tcl.tk/16730

DonHopkins on May 14, 2018 [–]

And with that diplomatically worded message, RMS kicked of The Infamous TCL War.

That was Stallman's response to Sun bombastically pushing TCL as the official scripting language of the web, BEFORE Live Oak / Java was a widely known (or evangelized) thing.

At the point anybody started talking about a Java/TCL bridge, it was already all over for TCL becoming the "ubiquitous scripting language of the Internet".

Sun's unilateral anointment of TCL as the official Internet scripting language trigged RMS's "Why you should not use Tcl" message, which triggered the TCL War, which triggered Sun to switch to Java.

After the TCL war finally subsided, Sun quietly pushed TCL aside and loudly evangelize Java instead. The TCL community was quite flustered and disappointed after first winning the title "ubiquitous scripting language of the Internet" and then having the title yanked away and given to Java.

Any talk of bridges were just table scraps for TCL, the redheaded bastard stepchild sitting outside on the back porch in the rain, smoking a cigarette and commiserating with NeWS and Self.

Tom Lord's description of what happened is insightful and accurate:

https://web.archive.org/web/20110102015130/http://basiscraft...

>The Infamous Tcl War

>[...] Mr. Ousterhout had, a few years prior, developed Tcl while on the faculty of UC Berkeley - mainly, I think, to have a handy tool for other research and only secondarily as an experiment in language design. And he topped it off with Tk. Tcl/Tk took off in a huge way. It was easy to understand. The source code, written in Mr. Ousterhout's methodical and lucid style, was a joy to read. At the time, about the most convenient option for developing a GUI to run on a unix system was to write C code against the Motif toolkit - an ugly, expensive, and frequently disappointing process. With Tcl/Tk in hand, people started handing out new "mini-GUIs" for this and that, like candy. Tcl/Tk started to find application in some rather intense areas, like, for example, the "control station" software for some oil rigs. It was a smash hit.

>Meanwhile, I don't think I'm letting too many cats out of the bag here, the informal Silicon Valley social network of well placed hackers were quietly and unofficially circulating some very interesting confidential whitepapers from Sun Microsystems. One of their researchers, a fellow called Mr. Gosling, had dusted off a language he'd once led the design of called "Oak". Oak was originally intended for use in embedded systems. Its basic premise was that devices ought to be Turing complete and hackable, whenever possible. Oak's approach to statically verifiable byte-code comes from that origin. Mr. Gosling came out of Carnegie Mellon University and the attiude behind Oak was popular there. As one grad student had quipped a few years earlier: "If a light switch isn't Turing Complete I don't even want to touch it."

>In light of the rising star of web browsers, the folks at Sun conceived the notion of offering up a derivative of Oak to serve as the extension language for browsers. (It is probably worth mentioning here that Mr. Gosling was earlier well known for making one of the very first unix versions of Emacs.) Oak was re-named "Java" and the rest of its history is fairly well known.

>I've read, since then, that up to around that point Brendan Eich had been working on a Scheme-based extension language for Netscape Navigator. Such was the power of the hegemony of the high level folks at Sun that the word came down on Mr. Eich: "Get it done. And make it look like Java." Staying true to his sense of Self, he quickly knocked out the first implementation of Mocha, later renamed Javascript. This phenomenon of Sun's hegemony influencing other firms turns out to be a small pattern, as you'll see.

>Mr. Ousterhout was hired by Sun (later he would spin off a Tcl-centric start-up). The R&D; team there developed a vision:

>Java would be the heavy-lifting extension language for browsers. The earliest notions of the "browser as platform" and "browser as Microsoft-killer" date back to this time. Tcl, Sun announced, was to become the "ubiquitous scripting language of the Internet". Yes, they really pimped that vision for a while. And it was "the buzz" in the Valley. It was that pronouncement from the then-intimidating Sun that led to the Tcl wars.

>Mr. Eich, bless his soul, brute-forced passed them, abandoning Scheme and inventing Javascript. [...]

https://news.ycombinator.com/item?id=38412049

The funny thing for me about this popping up from time to time is, that I like both Tcl and Scheme a lot. Each for their purpose. While certainly not beautiful and never ment to be an implementation language for large-scale applications, Tcl does a wonderful job for its designated tasks. The syntax might seem bizarre, but there is actually a great and simple system behind it, I strongly recommend to read the chapter about the syntax in the book by Ousterhout. Like Lisp Tcl is actually a homoiconic language. And like lisp you can create your own syntax, as required. On top, basic control like function calling, looks more like natural language, little syntax required.

Of course, as programming language, Scheme is much better, and it is the language I use for day to day work. In that respect Stallman is right. However he missed a few important points and that is why Tcl is still so popular, probably more so than Scheme, if you just count users. Tcl didn't just bring a language to the table, it also has an excellent implementation which always was freely available and could be embedded into any software project. It has a nice range of very powerfull tools, Tk obviously the most fameous one. Still today it is one of the most popular GUI toolkits. And that is where Stallman with the GNU project failed. Had they at that time or in the following years provided a comparable Scheme implementation, it would have been extremely popular for application writers. Assuming of course, that it had been licensed under LGPL so that any application could use it. But it took most of the 30 years after this post for Guile becoming an option there.

Tcl is/was worth it for Expect alone, which is humorously best described as "AutoHotKey but for your command line". That sentence feels way more anachronistic than it is.

Of course, these days, Python also has Expect-like capabilities, so.

My only issue with Tcl is that aweful, aweful language that one way or the other managed to become the language of choice for EDA tools. I hate it with a passion.

Other than that, it’s fine…

Just to add an opposing viewpoint:

I first encountered Tcl when tinkering with Quartus, and initially hated it with a passion. Once I eventually figured out which types of brace to use in which context, and started to appreciate having variables and conditionals available in .sdc files, the loathing started to give way to a grudging respect.

Now I really appreciate the elegant simplicity, the ridiculous ease with which it can be integrated into a C/C++ project, the ability to script JTAG communication with a running project (complete with Tk-based UI), the lack of dependence on any online repository or source of truth.

But especially I appreciate the lack of churn, which means the same scripts will work with the current release of Quartus as well as a version from more than a decade ago (needed because newer versions dropped support for newer devices.)

I understand how you feel, but if EDA had settled on Python, many of the same things we see would still be prevalent. They would be slightly reduced due to Python being a slightly less dynamic language than TCL but I am not sure it would matter.

The problem with EDA automation software is that it has been historically written by people with low skill in software development. Their domain of expertise is hardware. These shops also have not had for the most part a cohesive culture that spanned projects. For an org that focuses on digital design, the other 80% of that task is verification, but this has been prone to outsourcing and has had more churn on project to project.

I could be wrong, as I am outsider in this industry but this is what I see from my interaction with the EDA space. It puts up with horrible bugs, tools are hard to compose, the installers are crufty and target ancient OS versions. The secrecy within in the industry itself has made it a very late participant in open source.

So much conspires against any language that EDA would adopt.

I dunno I think the actual EDA tools are pretty good (I've used VCS and Questa mostly). Bugs are quite rare, the GUIs are pretty sophisticated and surprisingly usable given how niche software it is. They're even starting to support recent OSes (though you have to use the lowest common denominator so we're still on RHEL 8).

I think they mainly just don't really care about improving the scripting interfaces. TCL is an industry standard at this point and it is a shit language but it's not the main thing you're doing.

In my experience it's really the customers have low skill in software, so they won't even be asking for anything better than TCL. Hacky Bash scripts are the standard here so if anything TCL is an upgrade.

This is an industry where CI is a novelty. I still have to deal with people who think CI should be a very quick sanity check and the testing should mainly be manual.

It was great for us, AOL and Vignette back in 1999.

But it is also the reason why I don't use any dynamic language without JIT for production code, unless I have no say in the matter.

We took advantage of being a MSFT gold partner, moved into .NET when it wasn't yet known to the world, and our founders eventually moved on, and OutSystems was born out of our learnings.

The irony is, Tcl stands for Tool Control Language, it was created to control the EDA tools of the time. So it is no coincidence, that it is popular in the EDA world. I,for myself, quite like it for the intended tasks.

The other irony is, considering that article, that the Cadence analog tools (Virtuoso, Allegro) are using a nice Scheme dialect called "Skill" for that purpose. So not the whole EDA world is centered around Tcl.

"The Tcl scripting language grew out of my work on design tools for integrated circuits at the University of California at Berkeley in the early 1980's. "

History of TCL, https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php

I have hated industrial automation software from a particular manufacturer, but Structured Text, while a crappy language, was the least of my issues. The tools were really bad and the provided codebase amateurish.

Maybe it's a similar situatuon with these expensive proprietary EDA tools often being quirky?

Proprietary and non-proprietary are quirky across the board. For any piece of software, you literally keep hundreds of official releases, sub releases and patch releases, and if the design support team knows what they're doing, they provide was to specify the right version for each design module.

I can live with it: these tools are very complex and they don't have a lot of users. It's hard to make the bug free.

But you don't make software buggy deliberately. It's different for Tcl. Some people made a conscious decision to create that POS language and others thought it was a great idea to add it to their software.

This is a standard Usenet comment from Stallman, so I don't take it that seriously.

Tcl achieved many things, including the Tkinter GUI with a native look in Windows. Other projects like Python rely on it in the shrinking set of included batteries.

I would prefer if Lisp had won, especially in scientific code, but the C-API is not good enough. Unfortunately, currently Python is popular, so one thing is clear: People want a low level C-API in C with a published low-level interface. All other attempts have mostly failed in terms of popularity, so languages that want to take on Python better take note.

I would like to point out that the Tcl C API is exceptionally well-written and provides a robust low-level interface that many developers appreciate. For those interested, you can find the documentation here: https://www.tcl.tk/man/tcl9.0/TclLib/index.html

See also Ousterhout's reply:

https://groups.google.com/g/comp.lang.tcl/c/7JXGt-Uxqag/m/vQ...

Ousterhout's main argument seems to be:

> This is the proposition that you should use two languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions.

Thankfully, today, we have great programming languages, like Python, that people enjoy using both for large software systems and for writing small-ish scripts.

So, I suppose Stallman was right? I definitely agree with him that Unix shell syntax is awful.

>Thankfully, today, we have great programming languages, like Python, that people enjoy using both for large software systems

Python is absolutely terrible to use as a stand alone language. Almost everywhere it is used (ML, Data Science, Scientific computing, etc.) it is used to call C or C++. The amount of serious Python software that doesn't makes extensive use of calling to other languages is very small.

Python alone has very severe shortcomings, that make it totally unsuited for stand alone development.

> Python is absolutely terrible to use as a stand alone language. Almost everywhere it is used (ML, Data Science, Scientific computing, etc.) it is used to call C or C++. The amount of serious Python software that doesn't makes extensive use of calling to other languages is very small.

I have worked on lots of huge python codebases, so I don't buy this argument.

For example, all of YouTube, Instagram, Dropbox, Spotify, Reddit, Pinterest, Quora and Netflix is mostly build in Python.

Do many of the libraries that are optimized for speed call some C and C++ code? Sure. But so do many Java libraries. And ML libraries these days have to call CUDA code anyway, so you can't even do "stand alone development" in C.

That is that what I have observed too.

Python seems to be used more often to call performance optimized libraries (NumPy, opencv, TensorFlow) and so on.

I have seen TCL and LUA more often used the opposite way around: A complied core (e.g. C or C++) which allows extensions to be written quickly in the scripting language.

Both seems to work well but the use case is a different one.

So many citations needed.

For what specifically? Python is absurdly slow, for naive array task you can easily get a 100x to 1000x speedup compared to any native language. The GIL doesn't really help either...

I think my comments are pretty well accepted and substantiated if you look at what people are actually using python for. Right now AI is big, Python is at the center of that, to glue C++ together...

Well you made a bunch of claims. So, any of them?

>Python is absolutely terrible to use as a stand alone language.

Follows from the others.

>Almost everywhere it is used (ML, Data Science, Scientific computing, etc.) it is used to call C or C++.

See the big libraries in those fields. Do you think tensorflow or numpy are native python. If you are using python for scientific computing you will be using libraries which call out to native code.

>The amount of serious Python software that doesn't makes extensive use of calling to other languages is very small.

Given the above and that Python is most prominently found in those fields it seems pretty certain. There is standalone Python software, but usually only as a replacement for shell scripts or for relatively small applications.

>Python alone has very severe shortcomings

To name a few: GIL, lack of common default types (e.g. C like integers), enormous interpreter overhead, no mandatory typing (which introduces a whole range of runtime errors impossible in strictly typed languages). These alone make it totally unusable for many applications, unless you call to an external library.

>that make it totally unsuited for stand alone development.

See above.

>Python is absurdly slow, for naive array task you can easily get a 100x to 1000x speedup compared to any native language.

Personal experience.

>The GIL doesn't really help either...

It really does not...

>Right now AI is big, Python is at the center of that, to glue C++ together...

See e.g. what numpy, tensorflow, pytorch are written in. Spoiler, the matrix multiplication isn't implemented in python.

It's just too fast and loose. It is apparent and it says it on the tin. It was designed as a scripting language. Exactly the same holds for JS which is much worse.

I have no idea why these languages are considered "easy". I find them a pain to use for anything larger than a couple hundred lines of code.

For what exactly? He's right - the biggest users of Python use it as a convenient way of driving C (Pytorch, Blender, Numpy, Pandas, etc.).

On its own it is simply too slow.

These days in ML it's more often "a convenient way" of driving CUDA. So I guess there are no "standalone programming languages".

It's a silly argument, though. If you have a million lines of Python code, and some of it calls some library that contains lower-level code, does that mean Python is a "scripting language"? I wouldn't say so.

I disagree, Python is exactly the glue language that Ousterhout was describing.

Ousterhout is talking about Tcl, a language that doesn't even have arrays. Or numbers.

Did you ever try writing a large 1mil+ line codebase in Tcl or Bash? I'm pretty sure you'd prefer Python.

I can't say I enjoy large software systems written in Python.

I can't understand why anyone would decide to write anything complex in Python.

Python is the glue. Many Python packages, which need performance, have big pieces in C. Just as he described.

Stallman is always right, if you're willing to wait long enough.

Which means he is a real visionary, doesnt it?

I think so.

if Stallman is the answer, it must be a pretty intolerant question.

the joke is the Stallman fanbois downvoting the comment about Stallman being intolerant of opposing opinion.

Hahaha

If you go through the linked discussion on google groups you'll find Guido van Rossum advocating for using python :P

Was he though? I don't really see Scheme, Guile, etc. really being the embeddable language of choice. These days it seems to be Lua.

> auth required pam_faillock.so preauth silent deny=3 unlock_time=never fail_interval=900

I have seen other security theater types suggest this. What a completely stupid idea. If an attacker or even a well meaning script triggers this on the account you have sudo with you are now locked out forever.

Using fail2ban with a temp ban is enough to stop brute force attempts.

I have to agree with RMS that 1994 Tcl was pretty terrible. I remember cursing the lack of structs while using it for a larger program. All of this has been largely fixed in more recent versions.

On the other hand, 1994 Tcl/Tk was the best way to create simple user interfaces, and is (IMHO) much better than current tooling.

It's worth noting that we're in 2024, not 1994. While it's true that writing extensions for Tcl is necessary for richer data structures, it's definitely not an impossible task. As a mediocre programmer myself, I've managed to write 15 extensions in the past year. I love Tcl and find its C API to be exceptionally well-written and user-friendly.

Oh for sure ... I used Tcl recently (2019) on a project and it's fine now. I feel that Tk has got worse somehow though.

Tcl needs to change to a Lisp Like syntax and add a package manager to survive.

My thoughts.

It's funny to read that comment, when the argument includes:

      Tcl has a peculiar syntax that appeals 
      to hackers because of its  simplicity. 
      But Tcl syntax seems strange to most users.

That could be used to describe (emacs) Lisp too!

There has been a time when I had to write a great number of scripts, a part of them in TCL and a similar number in Scheme.

Writing in Scheme was very straightforward and foolproof, even if sometimes it was slightly more verbose, e.g. due to extra parentheses.

On the other hand, writing in TCL had exactly the same problems as writing in some UNIX shell language, where very similarly looking programs can have subtle semantic differences that lead to very different results, due to the complex quoting rules.

Therefore it was far more difficult to avoid bugs in complicated TCL programs than in complicated Scheme programs.

So... Racket?

anyone else notice that the 2nd reply to this was from Hal Finney? Wild.

Reply on news.ycombinator.com