shell perl tcl python 和rubby

以前用过tcl，最近在一个项目中用到了perl.

这里我简要描述一下我的心得。

主要的角度，是从使用者来看。

这些语言虽然都是解释性语言，但所处层次不同。

从使用者层次如下：

TCL -- 测试人员使用。

PYTHON RUBBY -- 开发人员使用

PERL  -- 如配置管理人员，perl是对shell的包装

Shell   -- 通过shell进行硬件配置和管理的人员

=======================

但，如果在这些语言的解释器的实现角度来看

TCL -- 测试人员使用 ，更加高层。

PYTHON  -- 开发人员使用，更加进一步集成的脚本语言，更加适合程序员使用，面向对象等特性

PERL  RUBBY -- Shell的一种替代

Shell   -- 通过shell进行硬件配置和管理的人员

==============================

比如，以前完成的一个项目，是用于测试的，现在来看，选择TCL是非常合理的。TCL的语言，简洁明了，功能简单，而且解释器也简单，很容易扩展，与C语言融合得非常好。解释器也是采用C语言完成，扩展，只需要编写扩展库就可以了，TCL本身就是一个C语言库，与perl 不同，Tcl参数，就是一个以语言结构体。

所以，在一个C程序中，如果使用了TCL，你感觉不到任何不舒服。

因为目就是为测试，所以每句话的判断，也很简单。

 Perl是这些语言里，最难用的，最强大的。

一开始我不太明白这种语言是干什么用的。后来，接手项目后，得到的是一堆批处理脚本。

这些Shell脚本的问题在于，Shell在任何一种操作系统中，虽然叫Shell，但都是操作系统内核的一部分，如果你设计操作系统，你也得这么干。

这样，问题就来了，Shell的断点调试，几乎是不可能的。虽然，在unix下，你可以在shell中，调试另一个shell，但也不是很方便。

总之，程序员，反正我是不太习惯。

这种情况下，Perl那就是不二选择，因为Perl与Shell是紧密相关的。Perl就是干这个的，Perl调Shell是相当简单的。

而Perl是一种真正的语言，活在内核之外，所以，可以有各种手段来单步跟踪或调试。

不过，打开perl的代码，特别是token.c和perly.y，两个核心文件，你顿感手脚冰凉，痛感人生短暂。

不由得想起看TCL核心代码时，多么如闲庭信步。

但冷静下来，再看看Perl的使命：跨平台的Shell包装语言。

我们，就原谅他吧，谁家代码一开始跨平台，肯定会越来越难看，更何况是跨各种平台的Shell呢？

另外难看的原因，还因是Perl内部是有虚拟机的，与TCL不同，TCL直接用的C语言的结构体，所有的变量都是字符串。因为TCL不需要考虑效率问题。

但PERL中，有些东西，用C语言来描述，过于困难，所以，他有自己的虚拟机，也是合理的选择。而且也能保证效率。（读者细思考一下，会明白会什么多个虚拟机，还会快，因为这里的虚拟机，与臭名昭著的JAVA虚机不是一种意思）。

这就使得PERL的代码更难读。以前我在一个项目中，把C语言链表，存入二进制文件，就使用了虚拟内存块的方法，因为要在两个内存空间，转换地址，所以，每个地方都需要强转，所以，代码写出来一堆宏。

Perl的内核就是这个样子。说实话，我是一行也不想看。

当然，Perl后来，被赋予了许多功能。在Cpan你能找到各种扩展。

写一个Perl扩展是相当困难的。这个前面我的解释，你看了就会明白，会什么Perl扩展不好写。

所以，老实说，我应当选TCL作来与用户界面的关联层。然后，在TCL层，再调用PERL.但没找到这样的方案。算是异想天开吧。

要是有人知道如何能做到，请告诉我，不胜感激。

Python，很多方面，很象TCL，而不是PERL。

因为Python的使命，就是一门语言，它没有必要与 Shell绑死。

这使得Python很成功。我也较喜欢，虽然没怎么用过。

据说，PYthon也有虚拟机，但我不清楚。据我所知，要扩展Python与Tcl 类似，很容易。Python与C语言融合得据说与TCL类似，非常好。

程序员，如果要完成什么任务，最好的选择就是Python，因为Tcl 主要就是写测试脚本，功能相对简单，虽然有面向对象的扩展，但我建议测试人员还是不要用。没必要。

Python天生就是面向对象的，因为它就是给程序员用的，没有别的想法，不需要告诉不是程序员的人，这是怎么回事。

所以，目的明确，设计得就可以优雅。

Perl这方面，命是比较苦的。Perl不是给程序员用的。它的目标群体是操作，给操作计算机的人用的。比如我们配置管理（CM）人员。既要天天写各种脚本，完成具体的批处理任务，比如控制Clearcase，打包工具，Shell,等等所有的附着于操作系统的软件系统，协同完成一个维护性任务。

做这种事情，没有比Perl 更合适的了。但你想直接把PERL集成到你的C语言工程中，难度还是相当相当大的。

比如最近，我的打包项目中，需要检查CM做出来的二进制.out与研发团队提供的是否一致，以确保研发人员按照规章提交了代码，编写了一个二进制比较软件。

我先用C语言编写了DLL，把文件中不同之处提取出来，然后把这个DLL包装成为PERL扩展，对接到PERL中，再利于PERL中的Date模块，来比较这些不同是不是日期。

这里，有两点：1.所有的应用系统，最终交给PERL来调度；2. 字符串处理，是PERL的老本行，对吧。

用了Perl以后，发现，许多C语言里实现起来很困难的事情，对PERL来说，不算事。

说到这，我还是说的是，选择什么，还是看自己的行当是什么。

测试人员，就应当选TCL.

研发人员，需要做许多脚本性的工作，那就用给程序员开发的脚本语言：Python，rubby.

介于研发，和底层维护人员之间的具体配置人员，最好选PERL。PERL，丑陋，但的确强大。

ruby ，还没有用过。我打算先看看它的原码，再说。

不过，具体来说，ruby，在我来看，象是一个给程序员用的PERL.

强大——完全照着Perl学的；但优美。

Perl和php，我都是深恶痛绝那个$符。 一切向钱前这种思想，难道还不够害人吗？但我不清楚，这两门语言的发明者是怎么搞的。

再说$符，在语多unix里，就是promote符，Shell的前导符。这根本就是个错误。我想不通。

所以，对于程序员来说，我建议，不要用PERL了，如果想达到Perl那么强大，可以用ruby.

但要知道，ruby不会给这个世界带来什么创新——语言学从乔姆斯基的发现到今天，再也没有突破，也没看到有突破的希望。

所以，不必迷信，只是谁不喜欢长得好看点呢？

但如果你是配置人员，还是老老实实用PERL吧。