なぜ Tcl を使うべきではないのか (日本語テキトー訳)


Date: Fri, 23 Sep 94 19:14:52 -0400
From: [email protected] (Richard Stallman)
Message-ID: <[email protected]>
Subject: Why you should not use Tcl
Newsgroups: gnu.announce,gnu.utils.bug,gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme,comp.windows.x.apps,comp.unix.misc

Why you should not use Tcl

Richard Stallman, GNU Project

As interest builds in extensible application programs and tools, and some programmers are tempted to use Tcl, we should not forget the lessons learned from the first widely used extensible text editor--Emacs.

機能拡張可能なアプリケーションプログラムやツールを組み込むとき、 Tcl を使うよう誘惑されているプログラマーたちがいるが, 我々は最初に広く使われた機能拡張が可能なテキストエディタ -- Emacs -- から学んだ教訓を忘れるべきではない。

The principal lesson of Emacs is that a language for extensions should not be a mere "extension language". It should be a real programming language, designed for writing and maintaining substantial programs. Because people will want to do that!

Emacs の最も重要な教訓は、機能拡張のための言語は単なる「機能拡張用言語」では あるべきではない、ということだ。 それはちゃんとしたプログラムを記述したりメンテナンスしたりするために設計された 本物のプログラム言語であるべきだ。 なぜなら、人々はそういうことをしたがるだろうから!

Extensions are often large, complex programs in their own right, and the people who write them deserve the same facilities that other programmers rely on.

本来、機能拡張は巨大で複雑なプログラムになりがちであり、 そういったプログラムを書く人は、他のプログラマーたちが 頼りにしている同じ設備(facility)の援助を受けるに値する。

The first Emacs used a string-processing language, TECO, which was inadequate. We made it serve, but it kept getting in our way. It made maintenance harder, and it made extensions harder to write. Later Emacs implementations have used more powerful languages because implementors learned from the problems of the first one.

最初の Emacs は文字列処理言語 TECO を使ったが、それは不適当だった。 我々はそれで間に合わせたが、それは我々の邪魔になりつづけた。 それはメンテナンスや機能拡張を書くことを一層難しくした。 (こういったことがあったので) Emacs の実装者たちは最初の Emacs の問題から学んで、 後の Emacs ではより強力なプログラム言語を使った。

Another lesson from Emacs is that the way to make sure an extension facility is really flexible is to use it to write a large portion of the ordinary released system. If you try to do that with Tcl, you will encounter its limitations.

Emacs から得られた次の教訓は、機能拡張の設備(facility)が 本当に柔軟かどうかを確かめるには、 それを使って本来の公表されたシステムの大部分を書いてみればいい、ということだ。 もし Tcl でそれを試せば、その限界に突き当るだろう。

Tcl was not designed to be a serious programming language. It was designed to be a "scripting language", on the assumption that a "scripting language" need not try to be a real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow. Tcl is ok for writing small programs, but when you push it beyond that, it becomes insufficient.

Tcl はまじめなプログラム言語となるように設計されていなかった。 それは「スクリプト言語」となるよう設計された。 「スクリプト言語」は本物のプログラム言語である必要はない、との仮定の元に。 その通りで、 Tcl にはその能力がない。 Tcl は配列を欠いているし、連結リストを作るのに必要な構造体も欠いている。 Tcl は数字(を処理する機能)がある振りをする。それは動きはするが、低速に違いない。 Tcl は小さなプログラムを書くには十分だ。 しかしそれ以上を望むなら、Tcl では不十分になる。

Tcl has a peculiar syntax that appeals to hackers because of its simplicity. But Tcl syntax seems strange to most users. If Tcl does become the "standard scripting language", users will curse it for years--the way people curse Fortran, MSDOS, Unix shell syntax, and other de facto standards they feel stuck with.

Tcl はその単純さゆえにハッカーの心に訴えかける独特な構文を持つ。 しかし Tcl の構文はほとんどのユーザーにとっては奇妙だろう。 もし Tcl が「標準スクリプト言語」になれば、ユーザはそれを何年も呪いつづけるだろう -- 人々が Fortran や、MSDOS や、Unix シェルの構文や、 彼らが押し付けられていると感じている他のデファクトスタンダードたちを呪ったように。

For these reasons, the GNU project is not going to use Tcl in GNU software. Instead we want to provide two languages, similar in semantics but with different syntaxes. One will be Lisp-like, and one will have a more traditional algebraic syntax. Both will provide useful data types such as structures and arrays. The former will provide a simple syntax that hackers like; the latter will offer non-hackers a syntax that they are more comfortable with.

こういった理由から、GNU プロジェクトは GNU ソフトウェア内で Tcl を使うつもりはない。 その代わりに、我々は意味は似ているが違った構文を持つ2つの言語を提供したい。 1つは Lisp 風で、1つはもっと伝統的な代数風の構文を持つだろう。 この2つは構造体や配列のような便利なデータ型を提供するだろう。 前者では、ハッカー好みの単純な構文を提供するだろう。 後者では、ハッカーではない普通の人々に、彼らがより快適に感じる構文を提供するだろう。

Some people plan to use Tcl because they want to use Tk. Thankfully, it is possible to use Tk without Tcl. A Scheme interpreter called STk is already available. Please, if you want to use Tk, use it with STk, not with Tcl. One place to get STk is from ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z

Tk を使いたいがゆえに Tcl を使おうとする人もいる。 ありがたいことに、 Tcl なしで Tk を使うことは可能だ。 STk を呼び出す Scheme インタプリタは既に入手可能だ。 Tk を使いたいのなら、Tcl と共にではなく、STk と共に使ってほしい。 STk は、 ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z から取得できる。

訳注

訳文の正確さには全く責任が持てません。正確さを期すには対置された原文を参照してください。

なお、下線部は私の誤訳の可能性が特に高い部分です。

参考