选择Tcl/Tk语言的十大理由---转载自Tcl/Tk中文网

mmxxt 2003-07-29 06:29:13
选择Tcl/Tk语言的十大理由

---------------------------------------
转载自Tcl/Tk中文网
http://tcltk.126.com
介绍Tcl/Tk语言的基本知识,汇集大量关于
Tcl/Tk的中文原创文章,英文翻译文档,开
设有Tcl/Tk中文网论坛。
---------------------------------------

人们使用Tcl/Tk的原因各不相同的,不过总的来说可以归纳为几类。下面所列的就是当前人们选择Tcl/Tk的10个最主要的原因。

1. 开发应用程序的周期短

人们使用Tcl/Tk 最主要的原因是Tcl/Tk使他们的工作能够更快的完成。许多情况下,用Tcl编写的应用程序比用其他语言编写的应用程序运行速度快5-10倍。这在那些包含图形用户界面,字符串操作,积分操作的程序中表现得尤为突出。而且用Tcl编写的应用程序稍加修改就能适应变化的需求。

2. 适于开发图形用户界面

Tcl与Tk工具箱相互配合提供了一整套创建图形用户界面的非常简单而又十分强大的工具。比如Tk的Canvas构件,不但可以十分方便的创建图形显示而且还提供诸如bindings和tags之类功能强大的部件。Text构件则可以提供复杂的超文本功能。在过去,只有Tcl提供了在UNIX下创建图形用户界面的完美的解决方案,这使得它拥有了一大批早期的追随者。如今Tcl可以在Windows,Macintoshi平台上提供同样出色的功能。

3.能够开发跨平台的应用程序

Tcl可以在Windows,Macintosh和几乎所有能想到的UNIX平台下运行,这使它成为开发跨平台应用程序的绝佳工具。举例来说,同样的Tcl脚本可以在UNIX,Windows和Macintosh上显示一个图形用户界面,这个图形用户界面在不同的平台上具有不同的外观,使不同平台上的用户在使用上没有障碍。由于Tcl可运行于所有的主流平台,所以它为那些类似于服务器采用UNIX,桌面采用Windows这样的混合环境提供了卓越的管理和整合工具。

4. 可以方便的扩展应用程序

如果你想创建一个能让用户自行修改和扩充的,功能强大的应用程序,那么你需要在这个应用程序中包含进一个解释性的脚本语言。Tcl/Tk能非常好的实现这个目的。Tcl解释器设计的初衷就是要能够嵌入到各种应用程序中。你可以很容易的将Tcl整合到一个应用程序中。Tcl解释器与应用程序能够很自然的融合在一起,看起来就好像Tcl是专门为编写这个应用程序而设计的语言。

5.具有弹性的整合功能

使用Tcl可以很方便的将已有的部件与应用程序整合起来,使他们能更有效的工作。例如,可以将Tcl用作特殊用途的硬件和协议的控制语言,为陈旧的应用程序添加图形用户接口或网络接口,或者将以前用C/C++编写的代码与新的Java应用程序整合起来,这使Tcl成为网络管理和工业自动化领域的强大工具。

6.为企业应用提供解决方案

随着Tcl8.1的发布,Tcl成为适合于开发大型服务程序和开发用于执行关键任务的企业级应用程序的首选(也是唯一可选)的脚本语言。脚本语言的优势,如快速的开发周期,弹性升级,易于整合,是众所周知的,但是在Tcl8.1之前,还没有一种能够满足企业应用程序需求的脚本语言,这些需求包括对国际化,线性安全,跨平台性,出色的图形用户接口,可嵌入性,因特网访问,数据访问之类的支持。Tcl8.1加入了对国际化的支持和线性安全,使Tcl成为不仅具有脚本语言的所有优势还能满足企业需求的首选脚本语言。

7.易于调试

Tcl是用于实现硬件自动化和软件测试的理想语言并且可能会成为这方面的主导语言。使用Tcl你可以很容易的连接到测试硬件或是一个应用程序的内部API接口,执行测试功能,检查结果,报告错误。Tcl的解释执行使测试环境能够迅速的建立起来,并且能够将测试结果以脚本文件的形式保存以用于以后的测试。如果你正在测试一个软件应用程序,Tcl可以使你直接连接到应用程序的底层API中,这样可以使测试更准确、更全面。

8.易于学习

Tcl是一种非常简单易学的语言,有经验的程序员可以在几天甚至几小时内就可以学会并能开始着手编写应用程序。普通的程序员也能很快的学会Tcl。通常由有经验的程序员编写一些基本的功能,更多普通的程序员应用这些功能来创建自己的应用程序。

9.易于编写网络应用程序

Tcl比任何平台都更易于使用网络设备,编写服务器端和客户端应用程序,只需几行代码,几分钟内就可以创建出来。另外,Tcl还可以很方便的为陈旧的应用程序加入网络接口。

10.庞大的Tcl网络社区

使用Tcl的另一个原因是它具有一个庞大的用户开发者社区,你随时都可以在Tcl网络社区中与别人交换代码、扩展包以及应用程序,还可以得到技术支持。

11.附加一点,Tcl是免费的!

Tcl可以从Tcl Developer Xchang网站上免费的得到,你可以对其代码进行修改以满足自己的需要或者将它用于商业用途。
...全文
1212 23 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
23 条回复
切换为时间正序
请发表友善的回复…
发表回复
tishineq 2004-02-17
  • 打赏
  • 举报
回复
up
mmxxt 2003-09-10
  • 打赏
  • 举报
回复
up
mmxxt 2003-09-09
  • 打赏
  • 举报
回复
up
Nvram 2003-09-05
  • 打赏
  • 举报
回复
关于哪种语言好的争论似乎从没停息,公说公理,婆说婆理。
大家可以在google上搜索"TCL War",这是RMS和TCL的作者的
争论,还有Larry Wall(Perl语言的作者)这样的大师一起参
与,很有意思,呵呵。
Nvram 2003-09-05
  • 打赏
  • 举报
回复
我上面转帖的文章只代表RMS的观点,不代表我个人的观点。我要说的是,我不反对TCL。确实,在我现在所在的公司和曾经所在的公司,TCL语言被广泛用在测试自动化方面,并取得了很好的效果。但是虽然我不反对TCL,但我也不怎么喜欢它。RMS更喜欢类Lisp语言,他在文中提到了Scheme。我曾经研究过这种语言,它确实非常好。Scheme是从Lisp中派生出来的,语法形式跟Lisp很象,但比Lisp简单得多。它最值得一提的特点就是能够用最简单的语法形式表达非常复杂的算法。Scheme语言被作为模型语言在国外大学广泛用在计算机程序设计语言的教学。然而实际使用的并不是很广泛,最值得一提的是Gimp。Gimp是GNU的图形处理工具,使用Guile作为Scheme嵌入式解释器。其实应用扩展语言有很多种,可以分为两大类,一种是将通用编程语言作为应用扩展语言,如Lisp、Scheme、Perl、Python。还有专门设计的应用扩展语言,如TCL、JavaScript、Lua、C-Lang等。前者功能强大,后者的能力有限。但前者学习比较困难,后者容易上手。Lisp是很早发明的语言,只比Fortran晚一点点,由人工智能领域的先驱约翰麦卡西发明,当时麦卡西在MIT的AI实验室,RMS也在,所以RMS对Lisp情有独忠。Lisp作为应用扩展语言除了在Emacs里使用外,另外值得一提的就是AutoCAD。无论是Emacs或AutoCAD,它们都比较难学,但是学会了就会发现,它们都是“万能”应用程序。
mmxxt 2003-09-05
  • 打赏
  • 举报
回复
Tcl简介
 

Tcl是一种非常简单的编程语言,如果你以前曾经学过编程,那么你只要学习几个小时就可以编写出一些有趣的Tcl程序。本文将对Tcl的功能做一个大概的介绍。一般来说,读完本文之后,你就可以开始独立的编写一些简单的Tcl脚本了;不过,要想获得更全面的认识,我们建议你还是去参考几本目前已经出版的Tcl书籍。

基本语法

Tcl脚本由一些被换行符或是分号分开的命令所组成。命令都有相同的基本格式,如下面的例子所示:
expr 20 + 10
该命令计算20加10的和,并返回结果30。你可以把这个例子以及本文中的所有其它的例子键入到tclsh这样的Tcl应用程序中来验证它们;在一个命令结束后,tclsh将打印出它的结果。
每个Tcl命令都含有一个或多个被空格分开的单词,在这个例子中有4个单词:expr,20,+,和10。第一个单词是一个命令名,其余的单词是这个命令的参数。所有的Tcl命令都含有一些单词,但不同的命令对他们的参数有不同的处理方式。expr命令把它的所有参数看作是一个算术表达式,计算表达式的结果,并以字符串的形式返回结果。在expr命令中,单词之间的分隔不是很重要:同样的命令你可以写成这种形式:
expr 20+10
不过,对大部分的命令来说,单词的结构是很重要的。每个单词都会用于不同的目的。所有的Tcl命令都返回结果。如果一个命令产生了没有意义的结果,那么它将返回一个空字符串作为它的结果。

变量

Tcl允许你在变量中保存数值,并且可以在后续的命令中使用这些数值。set命令用于对变量进行读写操作。比如,下面的命令对变量x赋值为32。
set x 32
这个命令返回变量的新值。你可以让set只带一个参数来读出变量的数值:
set x
你不需要在Tcl中声明变量:变量在第一次set的时候被自动创建。Tcl变量没有类型:任何值可以赋给任何变量。
要想在一个命令中使用变量的值,可以采用变量替代,如下例所示:
expr $x*3
当一个字符$出现在一个命令中的时候,Tcl把跟在它后面的字母和数字看作是一个变量名并且将其替换成变量的值。在这个例子中,expr命令接收到的实际参数将是32*3(假设变量x在前面的例子中被set过)。你可以在任何命令的任何单词中使用变量替代,甚至对一个单词多次使用:
set cmd expr
set x 11
$cmd $x*$x

命令替代

你也可以在一个命令的参数中使用另一个命令的结果。这被称之为命令替代:
set a 44
set b [expr $a*4]
当中括号出现在一个命令中的时候,Tcl把中括号之间的所有语句看作是一组Tcl命令。Tcl对这组命令进行解释,并用结果替代中括号之间的文字。上面的例子中,第二个set命令的第二个参数将为176。

双引号和大括号

双引号允许你指定包含空格的单词。我们看下面的这个例子:
set x 24
set y 18
set z "$x + $y is [expr $x + $y]"
在这三个命令都被解释后,变量z的值将是24+18 is 42。双引号之间的所有语句作为一个单词传给set命令。此处需要注意几点(a)引号之间的命令和变量替代仍起作用,(b)引号自身不会被传给命令。如果没有引号的话,set命令会得到6个参数,这将引起错误。
花括号对单词提供另外一种组合信息的方式。它与双引号的不同之处在于:花括号内的替代不起作用:
set z {$x + $y is [expr $x +$y]}
这个命令把变量z赋值为 " $x + $y is [expr $x +$y]"。

控制结构

Tcl提供一整套控制结构包括条件,循环和过程。Tcl的控制结构只是一些将Tcl脚本作为参数的命令。下面的示例创建了一个叫做power的Tcl的过程,实现对一个数求它的n次方:
proc power {base p}{
set result 1
while {$p >0}{
set result [expr $result * $base]
set p [expr $p- 1]
}
return $result
}
这个脚本由一个简单的命令proc所组成,这个proc命令有3个参数:过程名,参数名列表和过程体。过程体是一个Tcl脚本。需要注意的是,第一行末尾的花括号和最后一行花括号之间的语句都被逐字逐句的作为一个参数传给proc。proc命令创建了一个新的叫做power的具有两个参数的Tcl命令。你可以这样来调用power:
power 2 6
power 1.15 5
当power被调用的时候,过程体就被解释了。当过程体执行的时候,它可以变量的形式进入它的参数中:base获得第一个参数,p获得第二个参数。
power过程体中包含3个Tcl命令:set,while和return。while命令完成了这个过程中的大部分工作。它有两个参数,一个表达式($p>0)和一个Tcl脚本写的主体。while命令使用与C语言相似的规则来解释它的表达式参数。如果结果是真(非零),那么它将把函数体作为脚本来执行。他不断的重复这个过程,直到最后表达式的值变为假(零)。在这个例子中,while命令的函数体将result的值与base相乘,然后减少p的值。当p的值减到零的时候,结果就包含了需要的base的n次方值。return命令的作用是退出过程,同时将变量result的值作为过程的结果返回。

命令是如何运作的?

正如你所见到的,Tcl中所有有趣的功能都是靠命令来描述的。声明是命令,表达式由可执行命令来解释,控制结构是命令,过程也是命令。
Tcl命令由3种方式来创建。一组命令由Tcl解释器自身来提供。这些命令称之为内建命令,他们包括到现在为止你已经看到的命令和更多其他的命令(见下面)。内建命令出现在所有的Tcl应用程序中。
第二组命令使用Tcl扩展机制来创建。Tcl提供许多API接口,允许你用C或C++编写一个命令过程来创建一个新的命令。然后你可以通过Tcl解释器来通知Tcl过程实现的命令名,来注册命令过程。以后只要那个特定的名称被当作Tcl命令来使用,Tcl就会调用你的命令过程来执行这个命令。其实内建命令也是使用同样的扩展机制来执行的,只不过它们的命令过程是Tcl库中的一部分。
当Tcl用于嵌入到一个应用程序中的时候,应用程序使用扩展机制把它的主要功能和Tcl结合起来,这样一来那些可用的Tcl命令就因程序的不同而不同。还有大量的扩展包可以和Tcl应用程序组合起来使用。Tk是最著名的扩展之一,它提供了许多强大的创建图形用户界面的工具。而其他的扩展则提供了面向对象的编程,数据库访问,更多的图形功能,及其他的一些特性。用Tcl来创建完整的应用程序的优势之一是它可以很方便的进行扩展,从而可以组合进新的功能或与其它的资源进行通信。
第三组命令是一些由proc命令创建的过程。比如上面创建的power命令。通常,扩展用于较低层的功能,用C语言实现比较方便;而过程用于较高层的功能,用Tcl实现比较方便。

其它的功能

Tcl除了前面的例子中所使用的命令外,还有许多其它的命令,这里举例给出一些内建的Tcl命令所具有的功能:
☆ 更多的控制结构,如if,for,foreach和switch
☆ 字符串操作,包括一个强大的规则表达式匹配工具。不定长字符串可以像数字一样被传递和操作
☆ I/O 输入输出包括磁盘,网络通信通道,和类似串口的设备中的文件。Tcl为在Internet上进行通信提供了非常方便的工具
☆ 文件管理:Tcl提供许多命令来操作文件名,读写文件属性,复制文件,删除文件,创建目录,等等
☆ 分支过程的实现:你可以使用exec命令来运行其他程序,并且可以在它们的运行过程中和它们进行通信
☆ Lists Tcl使创建数值的集合变得很容易,并且可以用许多方式来对它们进行操作
☆ 数组 你可以创建有成对的名称数值组成的结构化数值,同时可以使用不定长字符串来定义这些名称和数值
☆ 可以对时间和日期进行操作
☆ Events允许等待一定的事件发生后再触发Tcl脚本,比如一段时间的延迟或是网络通信中输入的数据变为有效

bjay 2003-09-05
  • 打赏
  • 举报
回复
了解一下。
andersky 2003-09-04
  • 打赏
  • 举报
回复
没有接触过,以前只是听说过
看来要学习了解一下

mmxxt 2003-09-04
  • 打赏
  • 举报
回复
UP
Nvram 2003-09-03
  • 打赏
  • 举报
回复
================ 第2部分 ===============

The GNU extension language plan

Here is the plan for achieving the design goals stated above.

* Step 1. The base language should be modified Scheme, with these features:

** Case-sensitive symbol names.
** No distinction between #f and (), for the sake of supporting Lisp
as well as Scheme.

** Convenient fast exception handling, and catch and throw.
** Extra slots in a symbol, to better support
translating other Lisp dialects into Scheme.
** Multiple obarrays.
** Flexible string manipulation functions.
** Access to all or most of the Unix system calls.
** Convenient facilities for forking pipelines,
making redirections, and so on.
** Two interfaces for call-outs to C code.
One allows the C code to work on arbitrary Scheme data.
The other passes strings only, and is compatible with Tcl
C callouts provided the C function does not try to call
the Tcl interpreter.
** Cheap built-in dynamic variables (as well as Scheme's lexical variables).
** Support for forwarding a dynamic variable's value
into a C variable.
** A way for applications to define additional Scheme data types
for application-specific purposes.
** A place in a function to record an interactive argument reading spec.
** An optional reader feature to convert nil to #f and t to #t,
for the sake of supporting Lisp as well as Scheme.
** An interface to the library version of expect.
** Backtrace and debugging facilities.

All of these things are either straightforward or have already been
done in Scheme systems; the task is to put them together. We are
going to start with SCM, add some of these features to it, and write
the rest in Scheme, using existing implementations where possible.

* Step 2. Other languages should be implemented on top of Scheme.

** Rush is a cleaned-up version of the Tcl language, which runs far
faster than Tcl itself, by means of translation into Scheme. Some
kludgy but necessary Tcl constructs don't work in Rush, and Tcl
aficionadoes may be unhappy about this; but Rush provides cleaner ways
to get the same results, so users who write extensions should like it
better. Developers looking for an extension language are likely to
prefer Rush to Tcl if they are not already attached to Tcl.
Here are a couple of examples supplied by Adam Sah:

*** To pass an array argument without copying it, in Tcl you must use
upvar or make the array a global variable. In Rush, you can simply
declare the argument "pass by reference".

*** To extract values from a list and pass them as separate arguments
to a function, in Tcl you must construct a function call expression
using that list, and then evaluate it. This can cause trouble if the
other arguments contain text that includes any special Tcl syntax. In
Rush, the apply function handles this simply and reliably.

*** Rush eliminates the need for the "expr" command by allowing infix
mathematical expressions and statements. For example, the Tcl
computation `"set a [expr $b*$c]' can be written as `a = b*c' in
Rush. (The Tcl syntax works also.)

Some references:

[SBD94] Adam Sah, Jon Blow and Brian Dennis. "An Introduction to the Rush
Language." Proc. Tcl'94 Workshop. June, 1994.
ftp://ginsberg.cs.berkeley.edu:pub/papers/asah/rush-tcl94.*

[SB94] Adam Sah and Jon Blow. "A New Architecture for the Implementation of
Scripting Languages." Proc. USENIX Symp. on Very High Level Languages.
October, 1994. to appear.
ftp://ginsberg.cs.berkeley.edu:pub/papers/asah/rush-vhll94.*

** It appears that Emacs Lisp can be implemented efficiently by
translation into modified Scheme (the modifications are important).

** Python appears suitable for such an implementation, as far as I can
tell from a quick look. By "suitable" I mean that mostly the same
language could be implemented--minor changes in semantics would be ok.
(It would be useful for someone to check this carefully.)

** A C-like language syntax can certainly be implemented this way.

* Distribution conditions.

We will permit use of the modified Scheme interpreter in proprietary
programs, so as to compete effectively with alternative extensibility
packages.

Translators from other languages to modified Scheme will not be part
of any application; each individual user will decide when to use one
of these. Therefore, there is no special reason not to use the GPL as
the distribution terms for translators. So we will encourage
developers of translators to use the GPL as distribution terms.

Conclusion

Until today, users have not been able to choose which extension
language to use. They have always been compelled to use whichever
language is supposed by the tool they wish to extend. And that has
meant many different languages for different tools.

Adopting Tcl as the universal scripting language offers the
possibility of eliminating the incompatibility--users would be able to
extend everything with just one language. But they wouldn't be able
to choose which language. They would be compelled to use Tcl and
nothing else.

By making modified Scheme the universal extension language, we can
give users a choice of which language to write extensions in. We can
implement other languages, including modified Tcl (Rush), a Python
variant, and a C-like language, through translation into Scheme, so
that each user can choose the language to use. Even users who choose
modified Tcl will benefit from this decision--they will be happy with
the speedup they get from an implementation that translates into
Scheme.

Only Scheme, or something close to Scheme, can serve this purpose.
Tcl won't do the job. You can't implement Scheme or Python or Emacs
Lisp with reasonable performance on top of Tcl. But modified Scheme
can support them all, and many others.

The universal extension language should be modified Scheme.

Request for Volunteers

If you understand Scheme implementation well, and you want to
contribute a substantial amount of time to this project, please send
mail to Tom Lord, lord@gnu.ai.mit.edu.

If you expect to have time later but don't have time now, please send
mail when you do have time to work. Participation in a small way is
probably not useful until after the package is released.
Nvram 2003-09-03
  • 打赏
  • 举报
回复
但是,那应该用什么替代TCL呢?

再转贴:GNU扩展语言计划
作者: Richard Stallman

================== 第1部分 =================

GNU Extension Language Plans
Tom Lord (lord@gnu.ai.mit.edu)
Wed, 19 Oct 94 00:20:18 -0400

GNU Extension Language Plans
Richard Stallman, GNU Project

[Please redistribute widely]

Many software packages need an extension language to make it easier
for users to add to and modify the package.

In a previous message I explained why Tcl is inadequate as an
extension language, and stated some design goals for the extension
language for the GNU system, but I did not choose a specific
alternative.

At the time, I had not come to a conclusion about what to do. I knew
what sort of place I wanted to go, but not precisely where or how to
get there.

Since then, I've learned a lot more about the topic. I've read about
scsh, Rush and Python, and talked with people working on using Scheme
as an extension and scripting language. Now I have formulated a
specific plan for providing extensibility in the GNU system.

Who chooses which language?

Ousterhour, the author of Tcl, responded to my previous message by
citing a "Law" that users choose the language they prefer, and
suggested that we each implement our favorite languages, then sit back
and watch as the users make them succeed or fail.

Unfortunately, extension languages are the one case where users
*cannot* choose the language they use. They have to use the language
supported by the application or tool they want to extend. For
example, if you wanted to extend PDP-10 Emacs, you had to use TECO.
If you want to extend GNU Emacs, you have to use Lisp.

When users simply want "to write a program to do X or Y," they can use
any language the system supports. There's no reason for system
designers to try to decide which language is best. We can instead
provide as many languages as possible, to give each user the widest
possible choice. In the GNU system, I would like to support every
language people want to use--provided someone will implement them.

With the methods generally used today, we cannot easily provide many
languages for extending any particular utility or application package.
Supporting an extension language means a lot of work for the developer
of the package. Supporting two languages is twice as much work,
supposing the two fit together at all. In practice, the developer has
to choose a language--and then all users of the package are stuck with
that one. For example, when I wrote GNU Emacs, I had to decide which
language to support. I had no way to let the users decide.

When a developer chooses Tcl, that has two consequences for the
users of the package:

* They can use Tcl if they wish. That's fine with me.

* They can't use any other language. That I consider a problem.

Sometimes developers choose a language because they like it. But not
always. Sun recently announced a campaign to "make Tcl the universal
scripting language." This is a campaign to convince all the
developers who *don't* prefer Tcl that they really have no choice.
The idea is that each one of us will believe that Sun will inevitably
convince everyone else to use Tcl, and each of us will feel compelled
to follow where we believe the rest are going.

That campaign is what led me to decide that I needed to speak to the
community about the issue. By announcing on the net that GNU software
packages won't use Tcl, I hope to show programmers that not everyone
is going to jump on the Tcl bandwagon--so they don't have to feel
compelled to do so. If developers choose to support Tcl, it should be
because they want to, not because Sun convinces them they have no
choice.

Design goals for GNU

When you write a program, or when you modify a GNU program, I think
you should be the one who decides what to implement. I can't tell you
what language to support, and I wouldn't want to try.

But I am the leader of one particular project, the GNU project. So I
make the decision about which packages to include in the GNU operating
system, and which design goals to aim for in developing the GNU
system.

These are the design goals I've decided on concerning extension
languages in the GNU system:

* As far as possible, all GNU packages should support the same
extension languages, so that a user can learn one language (any one of
those we support) and use it in any package--including Emacs.

* The languages we support should not be limited to special, weak
"scripting languages". They should be designed to be good for writing
large programs as well as small ones.

My judgement is that Tcl can't satisfy this goal. (Ousterhout seems
to agree that Tcl doesn't serve this goal. He thinks that doesn't
constitute a problem--I think it does.) That's why I've decided not
to use Tcl as the main system-wide extension language of the GNU
system.

* It is important to support a Lisp-like language, because they
provide certain special kinds of power, such as representing programs
as data in a structured way that can be decoded without parsing.

** It is desirable to support Scheme, because it is simple and clean.

** It is desirable to support Emacs Lisp, for compatibility with Emacs
and the code already written for Emacs.

* It is important to support a more usual programming language syntax
for users who find Lisp syntax too strange.

* It would be good to support Tcl as well, if that is easy to do.
Nvram 2003-09-03
  • 打赏
  • 举报
回复
转贴:为什么不应该使用TCL
作者:Richard Stallman

==================== 全文 ====================

Why you should not use Tcl
Richard Stallman (rms@gnu.ai.mit.edu)
Fri, 23 Sep 94 19:14:52 -0400

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.

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!

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.

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.

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.

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

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.

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
mmxxt 2003-09-03
  • 打赏
  • 举报
回复
up
mmxxt 2003-08-30
  • 打赏
  • 举报
回复
你是不是没设置好啊
rogueking 2003-08-29
  • 打赏
  • 举报
回复
tcltk在windows下每个程序都有个dos框,非常不爽,所以不用!
mmxxt 2003-08-27
  • 打赏
  • 举报
回复
up
mmxxt 2003-08-24
  • 打赏
  • 举报
回复
up
bit7 2003-08-23
  • 打赏
  • 举报
回复
up
mmxxt 2003-08-20
  • 打赏
  • 举报
回复
tcltk在windows下对中文的支持已经有了很大的改进
现在的最新版本是 ActiveTcl 8.4.4
whoonline 2003-08-19
  • 打赏
  • 举报
回复
但我用的是Python的Tkinter,感觉Tcl/Tk对中文支持太差,而且在windows下不太稳定.
加载更多回复(3)
Tcl_TK编程权威指南pdf 内容简介回到顶部↑Tcl/Tk是第一种能通过Windows、Macintosh和Solaris等主要平台处理企业级任务的脚本语言。本书共分为55章,依次详细讲述了Tcl基础、Tcl高级特性、TK基础、TK组件、TK详解、C语言编程、各版本之间的差异等方面的知识,并通过大量实例,生动翔实地向读者介绍了Tcl/Tk编程,是读者掌握Tcl/Tt的必备参考书。 本书适合各个层次的读者阅读。 目录回到顶部↑第1部分 tcl基础 第1章 tcl的基本知识 tcl命令 hello,world! 变量 命令替换 数学表达式 反斜杠替换 使用花括号和双引号进行分组 过程 一个阶乘的例子 更多有关变量的知识 更多有关数学表达式的内容 注释 有关替换与分组的总结 要点 参考 第2章 开始使用 source命令 unix上的tcl脚本程序 .windows 95的开始菜单 macintosh与resedit console命令 命令行变元 预定义变量 第3章 cgi应用程序--顾客留言簿 html简介 使用cgi创建动态页面 guestbook.cgi脚本程序 定义表单以及处理表单数据 cgi.tcl软件包 接下去的几步 第4章 tcl中的字符串处理 string命令 append命令 format命令 scan命令 binary命令 相关章节 第5章 tcl列表 tcl列表 构建列表 获取列表元素 修改列表 搜索列表 对列表进行排序 split命令 join命令 相关章节 第6章 控制结构命令 if then else switch while foreach for break与continue catch error return 第7章 过程与作用域 proc命令 使用rename来改变命令名 作用域 global命令 通过upvar以名字进行调用 使用upvar来处理变量别名 第8章 tcl数组 数组的语法 array命令 使用数组来构建数据结构 第9章 对文件和程序的操作 使用exec运行程序 file命令 跨平台的文件命名方式 操作文件和目录 文件属性 对i/o命令的总结 打开文件用于i/o操作 读写操作 当前目录-cd和pwd 使用glob来匹配文件名 exit和pid命令 环境变量 registry命令 第2部分tcl高级特性 第10章 引用问题与eval 使用list命令来构建代码 在eval内部利用concat uplevel命令 subst命令 第11章 正则表达式 何时使用正则表达式 正则表达式的语法 高级正则表达式(are) 语法总结 regexp命令 rgsub命令 使用regsub将数据转换为程序 其他使用正则表达式的命令 第12章 脚本库及软件包 确定软件包的位置:auto-path变量 使用软件包 对软件包加载的总结 package命令 基于文件tclindex的库 unknown命令 方便交互 tclshell的库环境 编码风格 第13章 反射与调试 clock命令 info命令 跨平台支持 跟踪变量的值 交互式命令历史记录 调试 scriptics的tclpro 其他工具 性能调校 第14章 名字空间 使用名字空间 名字空间变量 命令查找 嵌套名字空间 过程的进口与输出 回调与名字空间 内省(introspection) namespace命令 转换现有的软件包以使用名字空间 [incrtcl]对象系统 注意事项 第15章 国际化(internationalization) 字符集与编码 消息目录 第16章 事件驱动的编程 tcl事件循环 after命令 fileevent命令 vwait命令 fconfigure命令 第17章 套接字编程 客户端套接字 服务器端套接字 回送(echo)服务 使用http获取一个url http软件包 基本认证 第18章 tclhttpd web服务器 将 tclhttpd与你的应用程序集成 域处理程序 应用执导的url 文档类型 html+tcl模板 表单处理程序 编程参考 标准应用执导(application-dirct)的url tclhttpd发行版 服务器配置 第19章 多解释器与 safe-tcl interp命令 创建解释器 安全解释器 命令别名 隐藏命令 替换 从安全解释器中执行i/o操作 安全基础 安全策略 第20章 safe-tk与浏览器插件 子解释器中的tk 浏览器插件 安全策略与浏览器插件 配置安全策略 第3部分 tk基础 第21章 tk的基本知识 th中的hello,world! tk组件的命名 配置tk组件 tk组件属性与资源数据库 tk命令概要 第22章 tk实例解析 execlog example browser tcl shell 第23章 打包摆放布局管理器(pack) 朝一侧摆放 水平与垂直难叠 空腔模型( cavity model) 打包摆放空间(packing space)与显w空间(display space) 尺寸调整与一expand 挂靠 摆放顺序 选择用于摆放的父组件 取消一个组件的摆放 打包器总结 窗口的堆叠顺序 第24章 栅格摆放布局管理器( grid) 一种基本栅格 跨行列摆放 行列约束 grid命令 第25 章定位摆放布局管理器( place) place的基础知识 面板管理器 place命令 第26章 将命令与事件编联 bind命令 bindtags命令 事件的语法 修饰符 事件序列 虚拟事件 事件关键词 第4部分 tk组件 第27章 按钮与菜单 按钮命令与作用域问题 与tcl变量关联的按钮 按钮属性 按钮操作 菜单和菜单按钮 键盘遍历 操纵菜单和菜单条目 菜单属性 通过名字来指定菜单的软件包 第28章 资源数据库 有关资源的介绍 加载选项数据库 添加单一的数据库条目 存取数据库 用户定义的按钮 用户定义的菜单 第29章 简单的tk组件 框架组件与顶层窗口 标签组件 消息组件 标尺组件 bell命令 第30章 滚动条 使用滚动条 滚动条协议 滚动条组件 第31章 输入条组件 使用输入条组件 输入条组件 第32章 列表框组件 使用列表框组件 列表框组件的编联 列表框组件的属性 第33章 文本组件 文本索引 文本标记 文本标签 文本信息的选择( selection) 标签的编联 文本搜索 嵌入组件 图片的嵌入 查看文本组件的内部信息 文本组件的编联 文本组件的操作 文本组件的属性 第34章 画布组件 画布坐标 hello, world! 最小和最大标尺的例子 画布对象 画布组件的操作 产生postscript输出 画布组件的属性 建议 第5部分 tk详解 第35章 选择和剪贴板 选择模型 selection命令 clipboard命令 选择处理程序 第36章 焦点、焦点的捕获和对话框 标准对话框 定制对话框 使用update命令实现动画 第37章 tk组件的属性 配置属性 尺寸 边界与浮雕效果 焦点的高亮显示 补自(padding)与挂靠(anchor) 第38章 颜色、图片和鼠标指针 颜色 色彩映射与视频种类 位图和图片 文本插入光标 鼠标指针 第39章 字体与文本属性 字体命名 x字体名 字模 font命令 文本属性 栅格化、尺寸调整和布局 一个字体选择应用程序 第40章 send send命令 发送者脚本 通信进程 通过套接字来实现远程eval 第41章 窗口管理器与窗口信息 win命令 winfo命令 tk命令 第42章 管理用户首选项 应用默认设置文件 定义首选项 首选项的用户界面 管理首选项文件 跟踪对首选项变量的修改 对该软件包的改进 第43章 一种操作编联的用户界面 一对协调工作的列表框 编辑界面 保存与加载编联 第6部分 c语言编程 第44章 c语言编程与tcl 基本概念 创建可加载软件包 一个用c语言实现的命令过程 blob命令的例于 字符串与国际化 tolmain和tcl-applnit tk_main 事件循环 从c中调用脚本 第45章 编译tci及扩展模块 标准目录结构 从源代码建立tci 使用占位函数库(stub library) 使用autoconf 扩展模块范例 makefile.in 第46章 使用c语言编写tk组件 初始化扩展模块 组件的数据结构 组件的类命令 组件实例命令 配置和重新配置属性 指定组件属性 时钟的显示 窗口事件过程 最后的清除工作 第47章 c函数库概览 tclc函数库概览 tk c函数库概览 第7部分 各版本之间的差异 第48章 tcl 7.4/tk 4.0 wish 过时废弃的功能 cgct操作 输入焦点的高亮显示 编联 滚动条接日 pack info 焦点 send命令 按钮的内部补白 单选按钮的值 输入条组件 菜单 列表框 没有了geometry属性 文本组件 颜色属性 颜色分配与tk colormodel 画布组件的scrollincrement 选择 bell命令 第49章 tcl 7.5/tk 4.1 跨平台脚本 clock命令 load命令 package命令 多个foreach循环变量 事件循环从tk转移到了tcl 网络套接字 多解释器与safe-tcl grid布局管理器 文本组件 输入条组件 第50章 tcl7.6/tk 4.2 更多的file操作 虚拟事件 标准对话框 新的grid布局管理器 macintosh的unsupportedl命令 第51章 tcl/tk 8.0 tcl编译器 名字空间 safe-tcl 新的lsort tcl_precision变量 2000年约定 http软件包 串行线i/o 独立于平台的字体 tk scaling命令 应用程序的嵌入 本地化菜单与菜单条 cde的边界宽度 本地化的按钮和滚动条 文本组件中的图片 destroy不再产生错误 grid rowconfigure 补丁版本 第52章 tcl/tk 8.1 unicode与国际化 线程安全 高级正则表达式 新字符串命令 dde扩展模块 杂类 第53章 tcl/tk 8.2 trf补丁 更快的字符串操作 空数组名 浏览器插件的兼容性 第54章 tcl/tk 8.3 关于tcl的修改建议 关于tk的改动建议 第55章 有关本书的cd-rom ↓展开全部内容 序言回到顶部↑Tcl为工具命令语言(Tool Command Language)的缩写。它其实是指两样东西:一种脚本语言,以及该脚本语言的解释器。该解释器可以很容易地嵌入到你的应用程序中。Tcl和与之关联的图形用户界面工具包(Tk)是由加州大学的John Ousterhout教授设计并编写的。尽管它是个商用软件包,但你也可以在Internet上找到它(见第VII页),而且可以在自己的应用程序中自由使用这个软件包。Tcl解释器已经从Unix平台移植到了DOS、Windows、OS/2、NT以及Macintosh环境中,而TK工具包也从X window系统移植到了Windows和Macintosh环境中。 1988年,当我在Berkeley做ousterhout教授的博士生时,第一次听说了Tcl。我们当时正在设计一种名为Sprite的网络操作系统。同学们在努力编制一个新式的内核程序,而John编写了一个新的编辑器和终端仿真程序。他使用Tcl作为这两种工具的命令语言,这样用户就可以定义菜单或者对那些程序进行定制。那时还处在使用X10的时代,他计划编写一个基于Tcl的X工具包,以使程序之间通过Tcl命令进行通信,彼此相互协作。对我来说,这种工具之间的相互协作就是Tcl的实质。 这种早期的设想就是让应用程序由包含编译代码的大块实体和一小部分用于进行配置和编写高级命令的Tcl代码组成。John的编辑器皿,还有终端仿真程序tx就遵循了这种模式。虽然这种模式仍然是有效的,但结果表明用Tcl来编写整个应用程序也是可能的。这是因为TclTk的shell程序wish提供了对其他程序、文件系统和网络套接字的存取功能,同时还能够创建图形用户界面。不管怎样,现在发现包含几千行Tcl脚本的应用程序并不稀奇。 我编写这本书的原因就是,虽然自己觉得使用TclTk既有乐趣又高效,但是也有令人头痛的时候。此外,在Xerox PARC工作,那里有许多语言和系统上的专家,我不得不强迫自己去理解Tcl/Tk的长处和弱点。我的许多同事都在他们的项目中采用了TclTk,但是他们也很快指出了它的缺点。因此,我就总结了一套编程技巧以充分利用Tcl/Tk的强大功能,同时回避一些棘手的问题。这本书就是一本帮助你最大限度地利用Tcl/Tk并回避一些我所经历过的令人头痛的问题的实用编程指南。 我接触Tcl语言大概已经有10年的时间了,而本书的第一版也已经出版5年了。在过去的几年中,我一直在John Ousterhout的手下工作,最初是在Sun微系统公司,而现在是在Scriptics公司。我一直使自己在很大程度上保持着一个Tcl程序员的角色,而我们工作组中的其他人员则埋头于Tcl本身的C语言实现。我创建的应用程序有HTML编辑器、EMAIL比用户接口程序、Web服务器以及用户数据库,我们的商务应用就建立在它们的基础上。这些经历在本书中有所反映。本书的大部分内容是有关Tcl脚本编程的,而有关使用C语言来创建Tcl扩展模块的内容没有着重讲述。我有幸一直参与Tcl核心技术的开发活动,希望通过本书能够将自己使用Tcl时获得的切身体会表达出来。 为什么要使用Tcl 作为一种脚本语言Tcl与其他的Unix shell语言,如Bourne Shell(sh)、C Shell(csh)、Korn Shell以及Perl类似。Shell程序可以让你执行其他的程序。它们提供了足够的可编程特性(变量、流程控制和过程),使你可以将现有程序组装成符合自己需要的复杂的脚本程序。Shell程序非常适用于一些日常任务的自动化处理工作。 Tcl解释器可以很容易地添加到你的应用程序中,这种能力将它与其他的shell语言区分开来。Tcl扮演了一种扩展语言的角色,用来配置和定制应用程序。你没有必要再去为自己的新应用程序发明一种命令语言,或是费力为自己的工具提供某种用户可编程特性。其实,你可以通过添加一个Tcl解释器,来将自己的应用程序组织成一组操作原语,并使用这些原语来构造最符合用户需求的脚本程序。这样还可以允许其他的程序通过编程来控制你的应用程序,以使套装应用程序能够很好地在一起工作。 Tcl的C函数库拥有清晰的接口而且便于使用。该函数库实现了基本的解释器,它有一套实现变量、流程控制和过程的核心脚本命令,而且还有一组用来存取操作系统服务以运行其他程序、存取文件系统和使用网络套接字的命令。TclTk提供了一台可以在UNIX、Windows和Macintosh环境中可移植的"虚拟机"。 因为你的应用程序可以定义新的Tcl命令,所以Tcl虚拟机是可扩展的。这些命令与你的应用程序所提供的C或C++过程关联。结果应用程序就分割成一组用编译语言编写的原语,并输出成为相应的Tcl命令。使用Tcl脚本程序可以将这些原语组装成完整的应用程序。脚本语言层可以存取与shell类似的功能以运行其他的程序,可以存取文件系统,还可以直接通过自己定义的Tcl命令来调用应用程序中编译的代码部分。此外,从C编程的层面上来说,你还可以调用Tcl脚本程序、设置和询问Tcl变量,甚至跟踪Tcl解释器的执行。 在Internet上有许多可自由使用的Tcl扩展模块。许多扩展模块都包含了一个提供某种新功能的C函数库,以及该函数库的Tcl接口。这样的例子包括数据库存取、电话控制、MIDI控制器存取,还有expect,它为控制交互式程序增加了一组Tcl命令。 最为著名的扩展模块就是Tk,这是一种图形用户界面工具包。Tk定义了用来创建和操作用户界面组件的Tcl命令。这种基于脚本的用户界面编程方法有三个好处: . 由于快速的响应周期,所以开发迅速,不存在漫长的编译等待过程。 . Tcl命令提供了一种比绝大多数由标准C函数库实现的用户界面工具包更为高级的接口。它只需一小组命令就可以定义简单的用户界面,同时又可以对用户界面进行细化以恰当地实现每一个细节。快速的响应周期又为这种细化过程提供了帮助。 用户界面处理可以从你的应用程序的其余部分分离出来。因而开发人员能够专心致志地实现应用程序的核心部分,然后再颇为轻松地构建出用户界面。Tk组件的核心功能通常能够满足你所有的用户界面需求。不过,你还可以用C语言来编写定制的Tk组件,而且网上还有许多大家提供的Tk组件可以使用。 还有其他可以用做扩展语言选择,这包括VisualBasic、Scheme、Elisp、Perl;Python和Javascript等,你可以依照个人喜好从中进行选择Tcl拥有简单的结构,而且还有些地方类似于C语言,可以通过编制C过程来增添新的Tcl原语。Tcl非常易学,许多有关用户使用Tcl在很短的时间内(例如几个星期)就完成了相当难度的项目,并且他们以前压根就没有接触过Tcl。 当本书第一次出版时,Java轰动了计算机界。Java是一种极为优秀的系统编程语言,长远来看还有可能代替C和C什语言。这对Tcl来说挺好,它在设计时就被用来将由任意系统编程语言编写的构件粘连起来。Tcl过去被设计与C语言一起工作,但是现在已经被改造成能够与Java虚拟机一起工作。在我们提到"C或C++"的地方,现在也可以说"C、C++或Java"了,但是对于Java来说,其细节上还多少存在些差异。这本书并没有描述TcVJava接口,但是你可以在CD-ROM上找到TclBlend。TclBlend将Java虚拟机加载到你的Tc3应用程序中并允许你调用Java方法,它还可以让你使用Java而不是C或C十十来实现Tcl命令。 Javascript是一种来自于Netscape的语言,它被设计用来编写与w曲页面进行交互的脚本程序。由于Netscape的广泛使用,Javascript就显得很重要,然而Tcl提供了一种更为通用的脚本方案,可以在更为广泛的范围中使用。Tcl/Tk的Web浏览器插件提供了一种在浏览器中运行Tcl的方式,结果使得Tcl更像是一种Java的替代品而不是Javascript的替代品。该插件可以让你在浏览器中执行Tcl应用程序,而Javascript则为你提供了对浏览器和HTML显示的精细控制。这种插件将在第20章有所描述。TcI与Tk的版本 TclTk仍在继续演变。请参看http://www.beedub.com/book/来了解有关最新的Tcl版本的更新和消息。由于历史原因,TclTk曾各有各的版本号,但是它们成对发行,并一起工作。这本书的原始版本基于Tcl7.4和Tk 4.0并有几处引用了Tk 3.6的功能。第三版已经进行了更新,它反映了直到Tcl/Tk8.2以来所增添的各种新特性: . Tcl7.5和Tk 4.1的最终发布在1996年5月。这些版本的特点是将Tk移植到了Windows和Macintosh环境。它引入了Safe-Tcl安全机制,以支持网络小应用程序(Applet)的 .安全执行。它还提供了对网络套接字的支持以及一种新的输入输出(I/O)子系统,以支持高性 能的事件驱动I/O。 . Tcl7.6和Tk4.2的最终发布是在1996年的10月。这些版本包含了对S池-Tcl的改进,以及对在Tk 4.1中引进的grid布局管理器的改进。跨平台的支持包括虚拟事件(例如,以<<Copy>>宋代表<Control-c>=、标准对话框,还有更多的文件操作命令。 . Tcl 7.7和Tk 4.3是内部版本,用于开发NetscapeNavigator和MicrosoftInternetExplorer Web浏览器的Tcl/Tk插件。它们的开发工作实际上与Tcl7.6和Tk 4.2并行进行。Tcl/Tt插件已经发布了许多各种平台上的版本,其中包括Solaris/SPARC、Solaris/INTEL、SunOS、Linux、Digital UNIX、IRIX、HP/UX、Windows95、Windows NT以及Macintosh。该浏览器插件支持Web页面中的Tcl小应用程序(Applet),同时使用Safe-Tcl复杂的安全机制来提供安全保证。 . Tcl8.0为Tcl新增了一个运行时用的编译器,这个编译器提供了数倍于Tcl脚本的执行速度。Tcl8.0支持内嵌空字符的字符串。编译器对脚本来说是透明的,但是扩展模块编写入员需要学习一些新的C API才能发挥它的潜力。由于John Ousterhout从Sun微系统公司到了Scriptics公司,发布8.0版的时间推迟了几年。广泛使用的版本8.0p2是在1997年完成的,但是最终的补丁版本8.0.5直到1999年春才发布。 . 在8.0时,Tk更改了版本号以与Tcl相匹配。Tk 8.0包含了一种新的独立于平台的字体机制,它还包含了本地化菜单和菜单条,以及更多的本地化组件,它们在Windows和Macintosh上拥有更好的本地化外观。 Tcl/Tk8.1新特性主要包括对Unicode的完整支持,以及线程安全,这样你就可以将Tcl嵌入到多线程的应用程序中。Unicode是一种新的正则表达式引擎,它提供了在Perl5中所能找到的所有功能。Tk为找到正确的用于显示Unicode字符的字体完成了卓越的工作,它还增加了一种信息目录设施,这样你就可以编写国际化的应用程序。Tcylk 8.1的发布史中还包括了Sun到Scriptics的过渡。第一个alpha版本完成于1997年秋,而最终的补丁版本完成于1999年5月。 Tcl/Tk 8.2主要是一个进行bug修正和稳固化的版本。它对TclC函数库API进行了几处微小增补,这样无须核心补丁程序也能支持更多的扩展模块。Tcl/Tk 8.2很快在1999年夏进入最终版本。 谁应当阅读本书 本书不仅适用于熟练的编程人员,同样也适用于初学者。对于初学者和熟练编程人员来说,我建议大家仔细学习一下策1章"Tcl的基本知识"。Tcl的编程模型被设计成一种简单的模式,它与许多编程语言存在差异。该模型基于字符串替换,你对这一点的正确理解很重要,这样才能避免在复杂情况下遇到麻烦。这本书的其余部分则包含了演示如何高效地使用Tcl与Tt的例子。每一章中都有对其中所描述的Tcl命令和Tk组件进行总结的表格,以供参考。 本书假定你有一些编程经验,但是你如果是个彻头彻尾的新手也能够读下去。对Unix shell的了解将会对你有所帮助,但这并不是必须的。在那些涉及Windows系统的地方,我会提供一些背景信息。第2章详细描述了在UNIX、Windows和Macintosh上使用TclTk的内容。 如何阅读本书 本书最好能在上机实习中使用,可以在计算机上尝试一下书中的例子。TclTk的命令手册尽管完整但却缺少上下文的的相关信息和例子,本书就试图填补在简明手册与现有的文档化或没有很好文档化的Tcl程序之间的空隙。 我推荐使用联机手册来查阅有关的Tcl/Tk命令。它为每个命令都提供了详细的参考指南,但是它没能提供完整的细节,这在每一次发布的版本中都有所不同。HTML版本的联机手册可以在随书的CD-ROM中找到。

23,217

社区成员

发帖
与我相关
我的任务
社区描述
Linux/Unix社区 应用程序开发区
社区管理员
  • 应用程序开发区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧