|
|
|
|
  PERL我选择对了吗？ - perlbb [ 2003-01-07 19:28 | 289 byte(s)]
Re: PERL我选择对了吗？ - ponderh [ 2003-01-13 10:26 | 446 byte(s)]
Re: PERL我选择对了吗？ - ACp [ 2003-01-13 16:07 | 32 byte(s)]
Re: PERL我选择对了吗？ - Blackeye [ 2003-01-14 13:18 | 281 byte(s)]
Re: PERL我选择对了吗？ - Blackeye [ 2003-01-16 02:09 | 20 byte(s)]
Re: PERL我选择对了吗？ - ponderh [ 2003-01-13 15:38 | 145 byte(s)]
Re: PERL我选择对了吗？ - Blackeye [ 2003-01-11 03:52 | 195 byte(s)]
Re: PERL我选择对了吗？ - perlbb [ 2003-01-11 10:09 | 44 byte(s)]
Re: PERL我选择对了吗？ - Blackeye [ 2003-01-12 04:13 | 129 byte(s)]
Re: PERL我选择对了吗？ - ACp [ 2003-01-12 20:26 | 2 byte(s)]
Re: PERL我选择对了吗？ - caosir [ 2003-01-10 02:27 | 22 byte(s)]
Re: PERL我选择对了吗？ - GDD [ 2003-01-08 00:01 | 362 byte(s)]
Re: PERL我选择对了吗？ - perlbb [ 2003-01-09 01:48 | 140 byte(s)]
Re: PERL我选择对了吗？ - perlbb [ 2003-01-09 20:32 | 342 byte(s)]
Re: PERL我选择对了吗？ - perlbb [ 2003-01-10 09:15 | 52 byte(s)]
Re: PERL我选择对了吗？ - perlbb [ 2003-01-11 01:18 | 46 byte(s)]
|
|
|
|
[Original]
[Print]
[Top]
|
PERL我选择对了吗？
我也知道PERL很多很多的好处，但是，就WEB应用而言，在性能上，PERL似乎真的无法战胜PHP与ASP……，我用PERL已经3年了，我不愿意放弃PERL，但是在WEB上，PERL始终没有高性能的表现，期待中的PERL6也推了一年又一年，不要说PERL在别的方面的应用，我只想说WEB上的，真的太失望了……
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
perl的web性能确实一般，尤其是cgi模式极差。perl本来也不是用来实现大流量网站用的。
不是精通一门语言就用它做一切，至少我不拿它做这个。
perl在windows下用activeperl的isapi模式据微软官方说法是加了cache的性能和asp是几乎一样了（微软官方站上的评测，比较古怪吧？微软很少说别人东西好。我主观感觉好像不是非常快）。可以去微软中国站查，是个中文版。
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
在GDD的大作中提到：
>>perl本来也不是用来实现大流量网站用的。
这个么，yahoo!和slashdot都是用perl做的。不如请原帖作者仔细说明一下perl具体哪些方面不能满足高性能要求。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
|
我测试了一个极其简单的用PERL连接MYSQL数据库并显示的小程序，用APACHE2的AB测试，开5个并发连接，测试100个连接，比ASP+ACCSEE的慢了组组10多秒！！
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
你不会想用ACCESS做大流量网站吧。做一个企业级大流量网站是不能用你的桌面电脑做性能测试的。
你提到的这个问题，似乎是在ASP里数据库里连接是保留的，不必每个新连接请求都重新执行连接操作。这个PERL、MySQL也是可以做到的，但我不会。：) 你用mod_perl了吗？
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
mod_perl我自然用了，perl for isapi我也测试了，perlex也测试了，这个确实快，但是是用的缓存，很多时候不正常，比如JS调用……
我用access做测试只是图方便，这只说明了ASP和PERL的效率，不谈数据库的，即便数据库有点因素，但也不会这么多啊！
APACHE有个模块可以将PERL和MYSQL做持续连接，我试过，效果还可以，但只是可以而已，不是特别理想……
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
在perlbb的大作中提到：
＞＞即便数据库有点因素，但也不会这么多啊！
问题可能就是在数据库上，在程序涉及到数据库查询的时候，数据库的表现往往是主要因素。犹其是存在大量连接的时候。连接请求是很占用系统资源的。
还有就是intel平台上的测试意义不大。不必因此失去对perl的信心。slashdot不是跑得好好的嘛。
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
|
Perl 的其它应用比WEB应用恐怕要更广一些, 在WEB应用方面, 其主要缺点恐怕就是每个进程都要与Database新建一个连接, 这会消耗不少资源与时间, 我们正准备试验JSP, 主要是看中其Database connection pool的功能.
|
|
----
===============================
Who am I ?
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
|
不知是APACHE的哪一个模块, 是不是mod_perl, 我对mod_perl还不熟, 另外我们这儿用哪不种方法也不是自己说也算, 头儿说用什么, 咱就用什么.
|
|
----
===============================
Who am I ?
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
我感觉现在的Web应用可用的方案很多, 虽然动态技术发展到现在也已经很多了, 但是有时候人们似乎有复古的倾向, 就是用"静态"的页面技术.
linuxaid原来是jsp, 现在搞成了shtml, 263等的新闻系统都是纯静态的网页...
如果到现在还要用Perl CGI做商业的Web系统, 那么个人认为是一个方向性的错误, 应该考虑有着成熟/博大构架的技术, J2EE或者.NET(传说还不成熟), 这些比较好"骗钱":-)反正有人喜欢被骗.
|
|
|
----
ponderh
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
Perl有它强大的一面，有一篇有名的文章叫Perl拯救了人类基因组计划，只是不接触这方面的东西，不会感受的到
我觉得Perl最强大在于它灵巧，而其极至，就是CPAN。
|
|
----
It's better to burn out than to fade away...
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
|
没看过你介绍的这篇文章，真想看看，但我相信是真的。因我所在的中心正是三大人类基因组中心之一，记得刚来时听人说过，我们用perl作为日常工作语言正是因其强大的字符处理能力，因为基因片断最终也要归为A、C、G、T的组合而已。所以几乎所有的module、script及相关应用（包括web应用）都是用perl写的。
|
|
----
===============================
Who am I ?
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
Perl 如何拯救了人类基因计划
linuxfab 01-04-24 07:51 1276p Lincoln Steinx
--------------------------------------------------------------------------------
译者 : tcwu(tcwu@cmlab.csie.ntu.edu.tw)
作者 : Lincoln Steinx
出处 : http://www.tpj.com/
当基因计划奠基在一片不兼容的资料格式的海洋，快速变化的科技，以及庞大的，在发布当天就已时的资料分析程序上时。Perl 拯救了这一切。虽然它并不完美。Perl 似乎明显的满足了许多基因中心需要，而且经常是当我们遇到问题时第一个想到的工具... Reprinted courtesy of the Perl Journal, http://www.tpj.com/
Lincoln Stein's website is http://stein.cshl.org/
位置:英国剑桥，欧洲最大的 DNA 定序研究中心的会议室
场合:本中心与美国最大的 DNA 定序研究中心的电脑科学家的高阶层会议
问题:虽然这两个中心使用几乎相同的实验技术，几乎相同的数据库，还有几乎相同的资料分析工具，却仍然无法交换或者比较出有意义的结果。
解决方案:Perl
人类基因计划在大约 1990 开始雄心勃勃的开始发展，期望能以国际合作的力量找出人类以及部分实验动物的完整 DNA 序列。这项工作的性质兼具科学与医药。藉由了解生物起源的构造，以及种种令人苦恼的细节，我们希望能够了解有机体如何由一颗卵发展到复杂的多细胞生物，食物如何代谢以及被转换成身体的一部分，以及神经系统如何流畅的工作。从医学的角度来看，从全盘了解完整的 DNA 序列得来的知道，能够有效的加速找出人类疾病(以及可能的疾病)的原因。
经过六年的努力，基因计划已经超越原先的计划日程了。人类以及实验动物的详细基因地图已经完成了(用一连串的标记来安排DNA 是决定完整序列的第一步)。最小的有机体，酵母，已经近乎完成，接着下一个，细小的蠕虫也不远了。几个月以前大规模的人类 DAN 定序工作已经在各中心展开，并且在整年中都会全力进行。
从资讯处理的角度来看，DNA 是一个非常长的字符串且由四个字母构成，分别是 A，T，G，C(这四个字母分别为四种化学物质的缩写，是构成双股螺旋的基础。字符串的长度令人印象深刻但也不是让人特别惊讶: 3 x 10^9 的字母长，或者如果你用一个位来储存每个字母的话，需要 3GB 的储存空间。
3GB 不小但是以今天的标准无疑的可以被管理。不幸的是，这只是储存结果所需要的空间。要得到这些结果所需要的储存空间远远大的多。根本的问题在于，目前的 DNA定序技术一次最多只能读到 500 个连续的字母。为了决定更长的序列，必须将 DNA 定序为一小块一小块部分重迭的片段，称为”reads”，这些拼图般的区域用算法来检查并找出相配的地方。因为 DNA 序列并非随机的(相似但并非完全一样的基本图案在基因中出现很多次)，而且因为 DNA 定序技术有杂讯且倾向于错误，必须针对某个区域作 5 到 10 次，才能可靠的把”reads”片段重组成真正的序列，这增加了要管理的资料的数量。在这之上的是与实验室工作相关的资讯: 谁进行了实验，什么时候完成的，被定序的基因区段，用哪个软件以及哪个版本重组序列，对实验加上的注解，等等。除此之外，一般人通常想要将定序用的机器产生的原始资料储存下来，每 500 个字母会产生 20-30kilobytes 长度的资料档案!
这还并非全部。只决定 DNA 序列是不够的。在这些序列里面，有功能的区域散布在很长的没有功能的区域中。人类 DNA 中有基因，控制区域，结构区域，甚至有些病毒卷入人体中并且变成了化石遗迹。因为基因跟控制区域负责健康与疾病，研究者会想要标示以其注解它们当它们被重组的时候。这类的注解产生了更多的资料需要被追踪与储存。
某些人评估居会有 1 至 10TB 的资讯需要被储存才能看出人类基因计划的结论。 所以 Perl 能做什么呢?从一开始研究者就了解到资讯学将会在基因计划中扮演很重要的角色。一个整合每个基因中心的资讯学核心被建立了。这些核心的任务有两个:提供电脑支持和数据库福对给他们相关的实验室，还有发展资料分析和管理软件给整个基因研究社群。
公平的来说，资讯科学小组一开始的结果是好坏参杂的。有些小组试图在复杂的关联数据库上面建立大型的系统，它们一次又一次的受到生物研究的高度动态的阻挠。当一套系统里里外外运作都与复杂的实验室协定正常配合，被实作出来且经过除错，新的科技已经取代了旧的协定，于是软件工程师又得回到设计版前。
然而，大多数的小组学会了建构模组化的，松散结合的系统，这些系统的部分可以被拿出来或放进去而不需要重新更换整套系统。举例来说，在我的小组里面，我们发现许多资料分析工作牵涉到一连串的半独立的步骤，假想某人想要操作一个刚刚被定只好的位(图一)。首先需要一个基本的品质测试:序列够不够长 ?含糊不清的字符是不是在最大限制以下? 接着有”向量检查”。为了技术上的理由，人类 DNA 在被定序前必须经过细菌处理(这就是”复制”的程序)。并不常发生，但是人类 DNA 有时候会在处理的过程中遗失，而且整个序列包含了细菌的向量。向量检查确保只有人类的基因被记载到数据库里面。接下来是反复序列的检查。人类 DNA 充满了重复的元素，使得将拼图安装在一起变的富有挑战性。重复序列测试试图由一个已知重复序列的数据库找出新序列，倒数第二个测试则是试图找出新的序列靠着对照于一个很大的社群的 DNA 序列数据库。在这时候一个比对成功通常能提供线索找到新序列的功能。完成这些测试之后，序列以及它的资讯已经被收集且载入了实验室的区域性数据库。
将 DNA 序列通过这些独立分析步骤的过程看起来很像一根水管，因此不用多久我们就了解 Unix 系统上面的”pipe”可以操作项工作。我们发展了一个简单的以 Perl 为基础的资料交换格式，叫做”boulderio”，这格式允许松散连结的程序加入资讯到以导管(pipe)为基础的输入/输入字符串流。Boulderio 的基础是一对一对标签/值。Perl 模组让获得输入很容易，取出他们有兴趣的标签，在上面作一些事情，然后丢回输出字符串流。所有该程序不感兴趣的标签被传到标准输出，所以其它的程序可以使用它们。
在这种形式的设计下，分析一个新 DNA 序列看起来像是这样(这并非我们真正在用的程序源代码，但已经很接近了)
name_sequence.pl < new.dna |
quality_check.pl |
vector_check.pl |
find_repeats.pl |
search_big_database.pl |
load_lab_database.pl
1一个包含新的 DNA 序列的档案会一个叫做 "name_sequence.pl" 的 perl script 处理，该程序的任务只是给予这个序列一个新的且唯一的名字并且将他输出成 boulder 格式，它的输出看起来像:
NAME=L26P93.2
SEQUENCE=GATTTCAGAGTCCCAGATTTCCCCCAGGGGGTTTCCAGAGAGCCC......
来自 name_sequence.pl 的输入接着被传入品质检查程序，它会找寻 SEQUENCE 标签，跑品质检查算法，然后把它的结论写到资料字符串流里面。资料字符串流现在看起来像:
NAME=L26P93.2
SEQUENCE=GATTTCAGAGTCCCAGATTTCCCCCAGGGGGTTTCCAGAGAGCCC......
QUALITY_CHECK=OK
现在资料字符串流进入了向量检查。它会从字符串流中取出 SEQUENCE 标签并且执行向量检查算法。资料字符串流现在看起来:
NAME=L26P93.2
SEQUENCE=GATTTCAGAGTCCCAGATTTCCCCCAGGGGGTTTCCAGAGAGCCC......
QUALITY_CHECK=OK
VECTOR_CHECK=OK
VECTOR_START=10
VECTOR_LENGTH=300
这些东西继续通过导管(pipeline)，直到最后 "load_lab_database.pl" 程序核对所有收集的资料，将一些最后的结论是否适合未来适合标记起来，以及把所有的结果送入实验室的数据库。Boulderio 格式的一个很好的特性就是许多个序列的纪录可以被连续的在 Unix 导管里面被处理。用一个”=”表示表示一笔记录的结尾，以及下笔资料的开始:
NAME=L26P93.2
SEQUENCE=GATTTCAGAGTCCCAGATTTCCCCCAGGGGGTTTCCAGAGAGCCC......
=
NAME=L26P93.3
SEQUENCE=CCCCTAGAGAGAGAGAGCCGAGTTCAAAGTCAAAACCCATTCTCTCTCCTC...
=
也可以在纪录中再建立子纪录，这使得我们可以使用结构化的资料型态。
以下为范例源代码，这个源代码处理 boulderio 格式。它有对象导向的风格，纪录被从输入字符串流中拉出来，修改，然后丢回字符串流中。
use Boulder::Stream;
$stream = new Boulder::Stream;
while ($record = $stream->read_record('NAME','SEQUENCE')) {
$name = $record->get('NAME');
$sequence = $record->get('SEQUENCE');
...[continue processing]...
$record->add(QUALITY_CHECK=>"OK");
$stream->write_record($record);
}
(如果你对 boulderio 格式有兴趣，可以在 http://stein.cshl.org/software/boulder/找到更多资讯以及操作它所需要的 Perl 函式库)
有趣的是，好几个资讯小组不约而同的发展出类似 boulderio 的主意。举例来说，好几个参予的小组蠕虫定序计划使用了一个资料交换格式叫做”.ace”。虽然这个格式一开始被设计用来作 ACE(一种生物资料用的数据库)数据库的资料倾印以及重复载入格式，可是它用了一个标签/值格式与 boulderio 很像。很快的，.ace档案被用 Perl 程序导管所处理，并且在最后一个步骤载入数据库。
Perlll 实验室管理的其它部分也找到用途。举个例子，许多中心，包括我的，使用以网页为基础的接口来显示专案状态，并且让研究者采取行动。Perl文稿语言是写作网页 CGI 引擎的完美语言。同样的，Perl 执行邮件数据库查询服务器，管理定期的工作，准备每天晚上的实验室活动总结报告，建立控制机器人的指令档案，以其操作几乎每个忙碌的基因实验室都会需要的资讯管理工作。
就实验室管理来看，资讯核心小组合理的成功了。就发展与散布性的一般用途，事情就没有这么乐观了。 这些问题与那些参与一个大型，松散的组织软件专案的人的问题将会很相似。尽管尽了最大的力，专案仍开始飘移。程序员进行那些令他们感兴趣的想法，需要互相沟通接口的模组被独立的设计，而且同样的问题被以不同的，不能相同的方法解决了好几次。当需要将所有部分放在一起的时刻来临，没有一个能够正常运作。这些情形也发生在基因计划上面。尽管事实是所有人都在同一个专案中工作，没有两个小组采用同样的解法。用来解决已知问题的程序被写了又写好几次。当不能保证一段程序片段工作的比其它地方发展出来的类似程序好的时候，你只能指望夸耀它特殊的使用者接口以及资料格式。一个典型的例子是重组数以千计的短 DNA reads 成为一个排序过的重迭片段的集合用的核心算法，至少有六种不同版本在各地被使用，而且没有任何两个有相同的资料输入或输出格式。
这种缺乏交换性表现出基因中心的严重的困境。没有可交换性，一个资讯小组被锁住只能用他们自家发展的软件。如果其它基因中心做出更好的工具软件来解决同样的问题，前者必须重新更患他们的系统来使用这个新工具。
这个问题长远的解法是提出每个基因软件都该遵循的制式化的资料交换标准。这也让公用的模组可以轻易的被装入或卸下。然而，这样的标准需要时间使大家都认可，而当不同的小组间参与讨论与协商的时候，仍然有紧急的需求要用既有的工具来完成当下的任务。
这时候再度用到了 Perl 并且达成了紧急救援。剑桥高级会议引述这篇文章并且请求商业资料交换的问题。尽管事实上这两个小组的关系是亲密的合作者，而且粗浅的来看，似乎用同样的工具来解决同样的问题，但是再接近一点观察后可以发现他们做的事情没有一件是一样的。
在 DNA 定序专案中主要的软件组件有:
一个追踪编辑器，用来分析，显示小片段的来自DNA定序机器的 DNA reads 色层。
一个 read 组译器，找出 reads 之间重复的部分并且重组他们成为连续的区间。
一个组译器编辑器，观看组译器的结果并且在发现组译错误的时候能改变内容。
一个能够追踪以上一切的数据库。
经过数年时间，这两个小组已经分别开发出在他们手上可以顺利工作的套件。照着类似的基因中心模式，有些组件是自己发展而有些是从外面引进的。如图二所示，Perl 用来当作胶水，把这些软件片段组合在一起。在每对交互作用的模组之间，是一个或多个 Perl 文稿负责将某个组件的输出调整成另一个模组预期的样子。然而，当需要交换资料的时候来临，这两个小组遇到了困难。在他们两组之间，有两种追踪编程器，三种组译器，两种组译器编辑器以及(感谢上帝)一种数据库。如果两个组件之间需要两个 Perl 文稿的话(一个方向一个)，会需要 62 个不同的文稿来满足所有可能的互相交换的工作。每次当其中一个模组的输出或输入格式改变，将要更动检查和修正 14 个文稿。
在这个会议中得的结论在图三。这两个小组决定采用一个共图的资料交换格式，叫做 CAF。CAF 将会包含双方的分析与编辑工具的的交集。对每个模组，有两个模组分别将 CAF 转换成该模组的资料格式，以及将其格式转换成 CAF。这简化了写程序以及维护的工作。现在只需要写 16 个文稿了;当其中一个模组改变了，只有两个模组需要跟着被检查。
这个事件并非独一无二的。Perl 已经变成基因中心的解决方案，当他们需要资料交换的时候，或是翻新某中心的模组来跟其它中心的一起工作的时候。
因此 Perl 已然成为基因中心之间计算的主要软件，就好象胶水将它们连结在一起。虽然基因资讯小组总是在思考有没有其它高阶语言，例如 Python,Tcl 还有最近的 Java，却没有能像 Perl 这样普及的。Perl 如何达成了这样的非凡成就?
我想有以下几个因素:
Perl 非常擅长于切割，扭转，绞，弄平，总结，以及其它的操作文字文件。虽然生物科学开始采用数用分析，然而大部分的资料仍然是文字文件:繁殖名称，注解，评住，目录查阅。甚至DNA序列也是类文字的。互相交换不兼容的资料格式是在文字文件上用创造性的猜测来处理的议题。Perl强大的正规表示式(regular expression)比对以及字符串操作使这个工作变得简单而没有其它语言能相比。
Perl 能容错。生物资料通常是不完全的，栏位可以被忽略，或是某个栏位被预期要出现好几次(举例来说，一个实验可能被重复的操作)，或是资料以手动输入所以有错误。Perl并不介意某个值是空的或是有奇怪的字符。正规表示式能够被写成取出并且更正错误的一般错误。当然这种弹性也可能是各坏处。我将会在之后提后。
Perl 是组件导向的。Perl 鼓励人们将他们的软件写成小模组，不问适用 Perl 函式库模组或是正统的 Unix 工具导向的方式。外部程序能够轻易的被整合进 Perl 程序,靠着管道(pipe),系统呼叫,或是插座(socket)。Perl5 引进的动态载入器允许人们使用 C 的函式，或者让整个编程过的函式库，被使用在 Perl 直译器中。最近的成果是世界各地的智能结晶都会收录在一组模组里面，称为”bioPerl”（请参考 Perl Journal）
Perl 很容易去写并且能很快开发完。直译器让你不需要宣告你所有的函数型式以及资料型态，当未定义的函式被呼叫时只会引起一个错误，除错器也能与Emacs很好的合作并且让你能用令人舒服的交谈式的开发模式。
Perl 是良好的原型语言。因为它快而且脏(quick and dirty)，用 Perl 建构新演算的原型比直接写成一个快的需要编程过的语言来的有意义。有时候发现结果是Perl已经够快了，所以程序变不需要移植;更多情形是某人可以用C写一个小的核心程序，编程成动态载入的模组或是外部的可执行程序，然后其它的部分用Perl来完成。这部分的例子可以参考 http://waldo.wi.mit.edu/ftp/distribution/software/rhmapper/)。
Perl 在写作网页 CGI 方面非常优秀，而且重要性随着各实验将资料发表在网络上之后更是增加。我在基因中心环境下使用 Perl 的经验从头到尾都是值得称赞的。然而我发现 Perl 也有它的问题。它的松散的程序风格导致许多错误，这些在其它严格的语言都会被抓到。举例来说，Perl 让你在一个变数在被指定值之前就能使用，这是个很有用的特性当你需要的时候，但是却是一个灾难当你单纯的打错了辨识名称。同样的，很容易忘记要宣告一个函式里面的区域变数，导致不小心地改到了全域变数。
最后，Perl 的不足之处在于建立图形化的使用者接口。虽然 Unix忠实信徒所有事情都能在命令模式下完成，大多数的终端使用者却不同意。视窗，选单，弹跳的图案已经变成了必要的时尚。
直到最近，Perl 的使用者界面(GUI)发展仍是不成熟的。然而 Nick Ing-Simmons的努力使得 perlTK(pTK) 的整合使得以 Perl 驱动的使用者接口在 X-window上面成为可能。我的伙伴和我曾经在 MIT 基因中心写过几个 pTK 为基础的应用程序供互连网使用者，而且从头到尾都是一个令人满意的经验。其它的基因中心则更大规模的使用 pTK，在某些地方已经成为主要的生产力。
不幸的，我很难过的坦承，几个月以前当我需要将一个我写的 C++ 的图形分析系统放上去，我使用了标准的 Tcl/Tk 函式库而不是 pTK。我做了这个决定因为我希望这个应用程序能广泛流传。我发现 pTK 在输入方面仍然太不稳定:一个 pTK 的新发行版本发现 lurking 的问题。更进一步，我发现即使是经验丰富的系统管理者编程及安装 Perl 模组的时候也会遇到问题，而我担心在安装 pTK 或是我的应用程序所需要的 Perl 模组的时候遇到大问题，而就此放弃。相反的，许多系统拥有 Tcl/TK 函式库;即使没有，安装也是快又无痛的。
总之，当基因计划奠基在一片不兼容的资料格式的海洋，快速变化的科技，以及庞大的，在发布当天就已时的资料分析程序上时。Perl 拯救了这一切。虽然它并不完美。Perl 似乎明显的满足了许多基因中心需要，而且经常是当我们遇到问题时第一个想到的工具。
|
|
|
----
It's better to burn out than to fade away...
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
举个例子，只是为了说明，除了一些常见的用途之外，在某些领域，它的优势非常明显，而且非常受欢迎。
|
|
----
It's better to burn out than to fade away...
|
|
[Original]
[Print]
[Top]
|
|
|
声明: 本页内容为中国Linux论坛的内容镜像，文章的版权以及其他所有的相关权利属于中国Linux论坛和相应文章的作者，如果转载，请注明文章来源及相关版权信息。