编程与软件工程antirez.com
被误解的 Tcl（2006）
Tcl the Misunderstood (2006)
2012 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Redis 作者 antirez 2006 年写的一篇文章，试图为 Tcl 正名：Tcl 的语法规则极少，几乎一切都是字符串，因此可以像 Lisp 一样做元编程，非常适合嵌入到其他程序里当脚本/命令解释器，也很容易上手。文章解释了 Tcl 为何常被误解为玩具语言。
为什么经久不衰：它出自一位后来写出 Redis 的实践者之手，把 Tcl 的设计哲学讲得清楚透彻，也成了每年 HN 上讨论 Tcl 价值与缺陷的固定引子。
HN 评论精选
Tcl 减少副作用、没有 NULL 值，是一门被低估的实用语言。
Tcl 逼着你创建新数据：想通过 uplevel/upvar 修改上层作用域的变量，你得费更多心思，副作用因此显著减少，数据变换变得显式，认知负担下降、效率提高。Tcl 也没有 Python/C 等语言里那个特殊的 NULL 值，不用为它操心。副作用少、没有统一的“无值”，让我把 Tcl 排在 Haskell 之下、几乎其他所有语言之上。只要懂得如何组织程序，Tcl 用起来很轻松；我在不想受严格类型约束时仍用它做原型。
thesz查看英文原文
Tcl forces you to create new data, because you have to think and work harder to introduce effects on variables in upper scope through the use of uplevel and upvar. This reduces side effects significantly and makes data transformation explicit. Which, in turn, reduces cognitive load and increase productivity. Tcl also does not have distinguished NULL value like Python, C, C++, C# and many other languages. You do not have to account for that. The reduction of side effects and no universal no-value value puts Tcl in my hierarchy of programming languages right below Haskell and above pretty much everything else. Tcl is very easy to use when you know how to structure the program. I still use it for various prototyping when I do not want strict type discipline.
文章写于 2006 年，今天的 Tcl 已增加了协程、OO、lambda 等大量特性。
值得指出的是，文章写于 2006 年，此后 Tcl 增加了不少新特性：协程、健壮的对象系统、尾调用、apply（lambda）、命名空间 ensemble 等。其中一些别的语言早就有，但 Tcl 的持续改进已让它远超文章描述的样子——它不是“玩具”，整体能力与其他脚本工具相当。
jrapdx3查看英文原文
I think it's worth pointing out that in the years since this article was written (2006) quite a few new features have been added to Tcl. A few of the more significant include coroutines, robust object-oriented system, tailcalls, apply (lambdas), namespace ensembles, et.al. Of course some of these features were already present in other languages. However, steady improvements to Tcl have pushed the language well beyond how it was described in the article. Definitely not a "toy" but overall as capable as the other scripting tools out there.
Tcl 作为嵌入式命令解释器的 REPL 体验极佳，兼顾 shell 手感与 Lisp 表达力。
我最喜欢 Tcl 的一点是，Tcl 的 REPL 比 Lua、Python 之类更像普通命令行提示符。要写复杂程序，Tcl 不会是我的首选；但当一个程序自带命令提示符（比如 AutoCAD，或很多游戏的调试控制台）时，Tcl 非常适合敲一次性命令，需要时又有一套简单而强大的编程语言可用。换句话说：POSIX shell 的命令行手感，加上 Lisp 的脚本手感。
repiret查看英文原文
What I like most about TCL is that a TCL REPL feels a lot more like a normal command prompt than Lua or Python or whatever. If I’m going to write a complex program, TCL wouldn’t be my first choice, but if a program I’m using has a command prompt (think autocad or the debug console a lot of games have). Plenty easy for one-off commands, but with a simple and powerful programming language there if you ever need it. Put differently: The command line ergonomics of POSIX shell, with the scripting ergonomics of Lisp
在实际工程（EDA 内嵌 Tcl）中，调试困难、报错信息难以定位，是 Tcl 的真实痛点。
我们工作中用 Tcl 写几个核心脚本，因为公司花几百万授权费的 EDA 工具大多内嵌 Tcl 解释器（我在半导体行业）。我觉得上班时效率最低的就是写 Tcl 代码，改用 TDD 有帮助，但依然让人抓狂：`set env(VAR) "value"` 和 `set $env(VAR) "value"` 两种语法都合法但含义天差地别；Tcl 报错没有前缀，第三方工具把 stdout/stderr 合并成一个日志，根本没法 grep；报错行号是相对过程而不是文件的；纯解释执行，没测到的分支里的语法错误可以潜伏数月。除非有 lint 工具补上其他语言自带的调试健壮性，我无法理解怎么会有人喜欢 Tcl。
engtech查看英文原文
We use TCL for a couple of core scripts at work because most of the tools we spend millions of dollars on in licensing use TCL as their embedded interpreter (I work in EDA/semiconductors). I find the most unproductive use of my time at work is when writing TCL code. Switching to TDD has helped a lot, but I still find the language maddeningly frustrating. I hate that this is both valid syntax with wildly different meanings: set env(VAR) "value" set $env(VAR) "value" I hate that TCL error messages have no prefix, so there is no way to grep for them (the 3rd party tools merge STDOUT and STDERR to a single log). I hate that the TCL error message line numbers are RELATIVE TO THE PROCEDURE instead of relative to the file. I hate that the language is fully interpreted and not compiled, so you can have a syntax error in a code branch that isn't triggered just lying there for months if you don't fully unit test every code path. I do not understand how anyone could like TCL unless they were using a linting tool to give the robustness of debugging that most other languages have. Because of our code base and the 3rd party tools I'm not able to lint our code and it is a brutally painful language to debug.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选