Live data from Hacker News

Why You Should Not Use Tcl (1994)

groups.google.com

31–40 of 55 posts

Re: Why You Should Not Use Tcl (1994)

#31
post #8

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

Re: Why You Should Not Use Tcl (1994)

#32

Earlier quoted context omitted.

>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 al…

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...

Re: Why You Should Not Use Tcl (1994)

#33

Earlier quoted context omitted.

>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 al…

So many citations needed.

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.

Re: Why You Should Not Use Tcl (1994)

#34

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.

Re: Why You Should Not Use Tcl (1994)

#35

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.)

Re: Why You Should Not Use Tcl (1994)

#37

Earlier quoted context omitted.

>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 al…

So many citations needed.

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.

Re: Why You Should Not Use Tcl (1994)

#38
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.

Re: Why You Should Not Use Tcl (1994)

#39
post #38

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…

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

Re: Why You Should Not Use Tcl (1994)

#40
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.

Post reply on HN