作者：Larry Wall
翻译：ㄚ琪 ，这一篇觉得真难翻，可能是对Perl 还不懂，所以请多多指教！
原文：Programming is Hard, Let’s Go Scripting…
我认为对很多人来说指令码很像下流的东西，我无法解释这件事，但是当我看到它的时候我就会知道，以下是一些广为流传的事迹：
简单的语言
"每件事都是字串"
快速原型法
胶水语言(Glue language)
程序控制
紧凑/简洁
更坏的-就是-更好的
特定领域的
"内含动力(Batteries included)"
…在这里我没有看到任何的中心，至少在技术条件上，如果我必须选一个比喻，那么就像是一个简单的交流道系统跟一个慢车道那样，甚至有一些是可选的快车道。
简单的交流道
但基本上指令码不是一个技术术语，当我们称某些东西是指令码语言时，我们主要是在做语言跟文化的判断，而非技术上的判断。
我认为指令码是人文学科的一环，这是我们语言的根本，所以谈谈这个根本…
过去
假如你回到爱达·勒芙蕾丝的时代并且问她指令码跟程式的差异，她大概会认为你很好玩，然后这样说：嗯，脚本是你给演员看的，但是节目是给观众看的，爱达是一个聪颖的淑女…
自从她之后，我们似乎越来越困惑关于我们所看的指令码的意义，它甚至也困扰了我，而我应该算是一个专家了说。
所以我恐怕我所能做的就是给你我自己对过去、现在及未来的浅见，让我警告你们在这里我可能会一些我的偏见。
BASIC
现在我认为BASIC最初的目的被证明是一种主要的指令码语言，特别是它的扩充版本DEC把他放在它的迷你电脑上叫做BASIC/PLUS，而且顺便加了递回函式跟参数，我一开始的时候就是做BASIC的程式设计师，有些人会说我被永久地伤害了，这些人无疑是正确的。
但我不会为此道歉，所有的程式语言设计者都有他们一些怪癖在，我只是比大多数人在这方面还要好一些而已 :-)
RSTS BASIC/PLUS
尽管这样当我还是使用PDP-11的一个RSTS程式设计师时，我确实把BASIC当作指令码语言，至少在快速原型跟程序控制的条件上来说是这样，我确定我的大脑已经永久反常了，Perl的语句修饰符(statement modifiers)直接利用了BASIC/PLUS，甚至有一些可爱的符号加在变数的尾端用来分办字串跟整数与浮点数。
但是你可以做极限编程，事实上我有一个大学好友还跟我结队编程，我们上了一个编译器设计的课程并且从恐龙书（注：Compilers: Principles, Techniques, and Tools (2nd Edition)
Unix?
我记得有一天我们的电脑中心收到一封来自贝尔实验室的信告诉我们可以便宜取得Unix V6的带子，只要$100是因为他们最近会推出V7的版本，我们彼此相望并且说，为什么我们会想要用这个称作Unix的东西呢？我们已经有了RSTS。
JAM (no not that one)
我第一个指令码语言是用BASIC写的，我在电脑中心第一个工作是写一个我叫做JAM的语言，Jury-rigged All-purpose Meta-language的缩写，这是我一生的故事…
JAM事一个很像PHP且彻底的文字处理语言，除了HTML那时候还没被发明出来之外，我们很多次用它来做BASIC的多样化巨集处理，不像PHP，在一个命名空间拥有3,000个函式，我们不会为一件事而有这样的记忆体。
LISP
不知识好是坏，当我去念研究所时，我学了语言学，所以我唯一使用的电脑语言是LISP，这是我个人的麦卡锡时代。
LISP适合作为指令码语言吗？虽然你可以很快速地用它来写东西，但是我却不会好心地把LISP当成是指令码语言，按照政策来说，LISP从来没有真正地照顾到一般人。
当然一般人也不会原谅LISP不迎合他们。
Pascal, Ada
当我进入行业之后，针对一个离散事件模拟器我用Pascal写一个编译器，并且垂涎着即将出世的Ada规格，作为一个语言学家，我不认为Ada是一个大型语言，现在的英文跟日文才是大型语言，Ada 只是一个中型的语言。
Unix, shell
几年后，我终于结识了Unix和各种的指令码语言，好吧，更精确地说是BSD跟csh。
BSD, csh
是啊，是啊，我知道，我更加的脑残了…
我也学了一点点的C。
C
那就只是一点点的C，我还在学习那些函式库。
shell + awk + sed + find + expr…
但是Unix shell语言的挫败直接引导了Perl的建立，而我却没有时间来说，本质上我发现shell的指令码受限于它的很多动词没有在它的控制下因此彼此严重地互相抵触，而且名词非常地缺乏限于字串跟档案跟谁-知道-什么(who-knows-what)的类型。
C xor shell
更具破坏性的就是那种一维的宇宙观心态：你不是用C来写程式就是用shell来写，因为他们是截然不同的连续体的两端，当我意识到指令码不必总是得看成跟程式是对立的，应该有一种语言可以在这两者间都做得很好的时候，Perl诞生了，这开辟了一个巨大的生态区隔，你们很多人有看过我旧的翻盖图有两个manipulexity跟whipuptitude维度。
Tcl
Perl之后就是Tcl，在某种意义上它是比Perl更纯的指令码语言，Perl在方便的时候只是假装每样东西是字串，但Tcl真的相信它是一个控制的比喻，字串的比喻往往会有较差的表现影响，但这不是Tcl被冷落的原因，我想，有两个原因。
首先是Tcl留在Unix的心态，控制工具是创见工具的死对头，所以他们没有很多的最佳化，毕竟快速的元件总是可以用C来写不是吗。
第二个原因就是缺乏合适的体面的扩充机制，所以最终你会期望有单独的执行档，像incr-tcl等等。
虽然我必须说我非常赞美Tcl语义的委派模式，但是却落入跟LISP一样的陷阱就是期望每个人使用一个真正的语法。
Python
Tcl之后就是Python，这是来自美国广播公司给Guido启发的领感，但是Python社群的心里却完全否认来自Perl的启发，然而我并不是完全够资格来评论Python，我并未真正了解Python，我只是偷了它的物件系统到Perl 5，我自己需要忏悔。
Ruby
我比较够资格来评论Ruby–那是因为Ruby的很多语法的处理从Perl那里借来，用Smalltalk语义来分层，我总是把Ruby看成是Perl这个生态区隔的最接近的对手，不只是因为借来的观念，而是因为Perl跟Ruby这两者有比Python更多的功能化的程式支援，换句话说，我认为Ruby搞砸了它声明的语法等等。
*sh
与此同时Bourne shell扩充进Korn shell跟bash，这两者我都没有很多的处里，谢天谢地，当你只是不断地加入专门的句法功能的时候，我要说的是shell的持续发展只是显示一个语言是如何的糟糕。
PHP
我们也看到了PHP的崛起，因为它采用较差的就是较好的方法来让人赞叹这新的深度，总的来说，PHP似乎也犯了跟早期Perl相同进展的错误，只是较慢而已，比较好的一件事就是它的打包，而当我说打包，我的意思不是命名空间。
JavaScript
然后有JavaScript，一个不错得简洁设计，它有些问题，但是长期执行下JavaScript实际上可能成为Perl 6执行于其上的合适平台，Pugs已经是JavaScript后台的一部分了，虽然不幸地去年遇到了一些问题(bitrot)，我认为当新的JavaScript引擎出来时，我们可能看到JavaScript后台新的兴趣出来。
Monad/PowerShell
我也看了一点Microsoft的单子(Monad)，而我很高兴注意到它的物件管道很像Perl 6，我只是希望他们不要申请专利。
Lua, AppleScript
还有其他指令码语言的广泛使用，不幸地，我必须承认我从来没有仔细研究Lua或AppleScript，可能是因为我不是一个Mac的游戏设计者。.
其实，我怀疑它比要带到现在这个阶段所要题的还深。
现在
当我看到现在的情况，我所看到的是各个不同的指令码社群表现了很多像在丛林中的邻近部落一样，有时交易，有时交战，但总的来说，仅维持使用自满隔离的方式。
我倾向于采取人类学观点来看这些东西，你们当中在这里有很多人是Perl的程式设计师，但你们当中有些人是来自其他语言部落的，并根据您的部落的历史，如果你是C语言的程式设计师，你可能会认为字串是指向位元阵列的指标，或是假如你是一个功能性的程式设计师你会认为是一个列表(list)，又或者你是Java的程式设计师你会认为是一个物件，我以大写字母T来把字串看成是一个文字。
Text
我从后现代的观点来读这个词，当然，后现代这个词本身是上下文相关的，有一些人认为，后现代主义的手段多了权力的庸俗，有些人认为Perl也是如此。
不过，我把后现代主义解释为一个文字，不论口头或书面，是一种需要两端情报的沟通行为，有时在中间也是如此，我不想讨论一个白痴的电脑语言，我想要我的电脑语言可以了解我输入的字串。
Perl是一个后现代语言，很多保守派人士会认为后现代是一个相当自由的概念，所以相当讽刺的是我对后现代的观点主要就是来自于语言学跟传教士所教导的翻译一样，他们灌输的一件事就是没有原始人类语言这样的事情，其中他们的意思基本上是所有人类语言是Turing完成。
当你离开所谓的原始部落并且分析他们的语言，你会发现他们的结构几乎跟任何其他人类语言一样的复杂，基本上如果你工作的够久你就可以说任何的人类语言，人类语言是Turing完成的就是这样。
因此，人类的语言不同，并不太能说清楚，但你又必须说，在英语中，你被迫区分单数的复数，在日本，你不必区分单复数，但你必须选择特定礼貌等级，不只考虑到你正在交谈的人尊重的程度，还要考虑到你所说得人或事的尊重程度。
所以让你不得不说语言不同，显然，如果你的语言强迫你说什么，你就不能在某特定的领域简洁的使用你的语言，这使我们回到指令码。
对不同的指令码语言来说有多少不同的方法是简洁的？
在俄国有多少的罗宋汤煮法？
语言设计者有很多的自由，我要指出一些事情。
早期系结 / 延迟系结
系结一词就是你决定何时呼叫一个已知的程序名称的程序，在早期的计算里，大部分的细节为了效率的理由都相当早完成，不是在编译时间就是最后的连结时期完成，在静态类型的语言你仍会看到这样的方法，然后在像Smalltalk这样的语言，我们开始看到一个趋势，这段时期大部分的指令码语言正趋向延迟系结，那是因为指令码语言正试着按我的意思去做(dwimmy，o What I Mean缩写)，而最按我的意思去做的决定通常就是晚一点决定因为你会有比较多的语义跟更多实际的上下文可以使用，否则，你需要预测未来，而这又很难。
所以指令码语言自然倾向移往物件导向的观点，这样细节会直到方法调度时间才会发生，虽然你仍然可以看到像C++跟Java那样语言的冲突伤痕，C++将预设的方法型别做为非虚拟的，所以你必须说明确的虚拟来取得延迟系结，基本上Java有final类别的符号，它强迫在编译时期呼叫类别来约束，我认为这两种方法有很大的错误，Perl 6 会产生不同的错误，在Perl 6里所有的方法预设都是虚拟的，只有作为一个整体的应用程式可以告诉优化程序来将类别定案，大概只有你知道所有的类别如何被程式中其他的模组所使用。
单分派 / 多重分派
在某种意义上，多重分派是一种拖延系结更长时间的一种方法，你不仅要拖延系结直到你知道物件的型，而且也要在你挑选一个程序呼叫前知道所有参数的型态，Python跟Ruby只有单分派，而Dylan可以做多重分派，在这里Perl 6 强迫 呼叫者要有明确的清晰度，我认为这是程式设计师很重要的区别要记住，因为单分派跟多重分派是非常不同的哲学思想，而且是基于不同的隐喻。
对于单分派的语言，你基本上送一个讯息给一个物件，然后这个物件决定如何处理该讯息，然而对于多重分派来说，没有特权的对象，所有含括在这呼叫中的物件都有相同的权重，所以可将多重分派看成是完全被动的对象之一种方法，但是假如物件没有决定如何系结，那么它是什么？
嗯，这是有点民主的事，所有这些程序的名称放在一起，举行一次政治会议，（嗯，不是真的，但是这是解释隐喻如何的运作），每一个程序是大会的一个代表，所有有意参选的程序将他们的名字放在帽子里，然后所有的程序投票看谁是最好的候选者，以及下一个最好的以此类推，最后程序自己决定最好的程序来呼叫。
因此基本上，多重分派就像民主政治一样，除了所有其他的其外，这是做后期系结最糟糕的方法。
但我确实认为这是真的，而且很可能随着时间的流逝成为真实，我花了很多时间在这个多重分派问题上，因为我觉得大型程式是隐含在单分派模式下的命令-控制模式的变异来的，大体来说我认为计算机领域正朝向那种较好决策模式就像由一群虫子或鱼类来做那样，这种决策单一的个体是无法控制的，而整体来说虫子的这种紧急行为不知怎地会比任何个体所做的决策还要聪明的多。
及早求值(eager evaluation) / 惰性球值(lazy evaluation)
大部分语言的求值策略，包括Perl 5在内，这些语言的计算所有运算式都尽可能地慢，Haskell就是一个很好的例子，它会直到被强迫才会做计算，这样做的好处是你可以无限制地做很多很酷的事而不会用完记忆体，嗯，至少，直到有人要求程式来计算整个列表，然后，你几乎在该区以任何语言，除非你有一个真正的图灵机。
所以无论如何，我们在perl 6试验一种及早和惰性的混合体，有趣的是，这个区别在Perl 5的纯量环境对比串列环境的观念非常地漂亮，所以在Perl 6纯量环境是及早的而串列环境是惰性的，当然预设情况下，假如你喜欢你可以强迫纯量是惰性的或串列是及早的，但是只要你的回圈在你进入无线回圈前有一些其他方法可以跳出的话你可以说像1..Inf的事。
及早类型(eager typology) / 惰性类型(lazy typology)
通常被称作静态跟动态，对调整旋钮来说也同样有不同的立场，我比较喜欢渐进型别方法有很多原因，效率是其中一个原因，人们通常认为强型别是一个原因，但是放型别到Perl 6的主要原因是不能是强型别，但却是多重分派，记住我们政策性的惯用隐喻吗？当不同的参选者放他们的名字进帽子中，他们有什么区别？嗯，每个参选者都有他们自己的政见，这些政见里的要点就是他们想回应的引数型别，我们都知道政客只善于回应他们想要有的引数型别…。
Perl 6稍微比Perl 5惰性有另一种方式，我们还有内容的概念，但是内容决定的时间已经改变，在Perl 5，电脑通常知道再编译时期哪一个引数是纯量的，哪一个引数是串列的，但是Perl 6延迟这个决定直到方法系结时间，概念上来说就是执行时期，而非编译时期，这对你来说可能似乎是奇怪的事，但是它却可以修正很多Perl 5次优的设计，例如原型(Prototypes)，还有外显参考的需要， 还有其它恼人的小事情，像是在常见的问题中所见的事。
有限的结构(limited structures) / 丰富的结构(rich structures)
Awk、Lua跟PHP全都限制了它们的复合结构到关联阵列，这有利也有弊，而且awk这样做的事实让它跟Perl有所不同的原因之一，以及排序阵列跟杂凑阵列的差异，我只是想他们的不同点，我想很多其他人也这样做。
符号(symbolic) / 言语(wordy)
Arguably APL也是一种指令码语言，主要是象征性的，另一种极端的语言是避免用标点符号而改用文字，像是AppleScript跟COBOL,以及在较小的程度上所有的Algolish语言使用文字来C延伸语言用括弧来表示区块，我喜欢这里平衡的作法，每一个符号和识别符做他们最擅长的，我喜欢的是在程式设计师选择很多实际的话来表达手头上的问题，我不希望看到的仅仅是语法用字，这种句法函子只是掩盖了真实的话，我知道这一点是当我从Pascal跳到C的时候，大括弧表示区块，这只是视觉上的权利而已。
其实还有语言做得比COBOL更糟，我记得有一个Pascal变种需要你的关键字大写这样子他们才能引人注目，No, no, no, no, no！你不会想要你的函式受人注目，这是错误的喊话：IF! foo THEN! bar ELSE! baz END! END! END! END!
无论如何，我们在erl 6提高了那里使用标点符号，哪里我们不用的标准，我们摆脱了一些实际上并没有很重要的标点符号，像是条件表示式周围的括号以及许多的符号变数，而且我们也正在使所有其余的标点符号更有效的使用，每个符号根据霍夫曼编码(Huffman coding)已经足以证明其存在的必要。
奇怪的是，我们有一个正在引入新标点符号的地方，在sigil之后你可以增加一个twigil或是secondary sigil[注1]，就像sigil告诉你一个物件的基本结构，twigil告诉你有一个特定的变数有一个奇怪的范围，这是从Ruby那边偷来的一个主意，它使用sigils来表示奇怪的范围，但是藉着在我们的sigils后隐藏twigils，我们让这两个世界更好，加上一个可扩展的twigil系统来表达奇怪的范围是我们之前尚未想过的。
我们扩展了很多思考，我们在思考我们尚未知道如何思考的语言部份，但是对于新的语言在语法的部份保留空间就像是一种对国家公园及国家森林保留一些我们的土地一样，或者像一个考古学家不是挖考古遗址的一半，因为我们知道我们的后代将有比我们更好的分析工具一样。
真正设计一个未来的语言需要包括很多的谦卑，正如科学一样，你必须假设在很长的一段时期，你所思考的很多东西是真实的，却变成不尽然如此，换句话说，假如你现在没有做最好的猜测，你就不是真的在做科学，回顾过去，我们知道APL有太多奇怪的符号，但是我们不会清楚在开始的时候APL是否尚未试过。
注1：这个sigil、twigil跟secondary sigil好像没看到怎么翻成中文，这是Perl 6加了secondary sigil (twigil)功能，以用来指代不同scoping的变数，例如：
$*foo为全域变数，$=foo为pod变数，$.foo为object attribute accessor。
参见http://sunnavy.net/entry/00386cfe4c1611dfbc4a58baa9a5093e
编译时期 / 执行时期
许多动态语言会在执行时期评估程式码，Perl也采用另一个方向并且在编译时期执行很多的程式码，这会跟操作定义弄混，举个例说，你不会想要在你的BEGIN区块内做很多的档案I/O，但这样会引导我们讨论别的差异：
宣告 / 操作
大部分的指令码语言都是站在操作端那边的，我认为Perl 5有一个简单的物件系统直到我见到Lua为止，在Lua里一个物件只是一个杂凑，而且假如它有含程式码的话还有一点语法糖来呼叫一个杂凑元素，这就是所有的，它们甚至没有类别，任何类似的继承都必须透过明确的授权才能处理，那是Lua设计者所做的选择以便让语言很小而且可以嵌入，对他们来说，或许这是正确的选择。
Perl 5总是比Python或Ruby有更多一点的宣告，我总是强烈地感到隐式范围只是在自找麻烦，而且范围变数宣告应该很简单地清楚辨认，那就是为什么我们有my，它很短是因为我知道我们常用它，霍夫曼编码，保持常用的事简短，但不要太短，像0就太短了。
Perl 6有许多不同的范畴，所以我们会有更多像my跟our之类的宣告，但外表会骗人，虽然这语言表面上来看有很多的宣告，但是我们让大部分的宣告在台面下运作以保持弹性，举例来说当你宣告一个变数的型别，你只要用Perl 5的一种格式用tie来做，主要的不同在于你系结实作到变数是在编译时期而不是在执行时期，这是很有效率的，或至少有最佳化的潜能。
非可变类别 / 可变类别
在Java里类别是封闭的，而这是Java可以执行相当快的理由之一，相对来说Ruby的类别是开放的，这意味着你可以在任何时期增加新的东西，保持这种开放的选择或许也是Ruby执行很慢的原因之一，但是这样的弹性却也是为什么Ruby有Rails的原因。
Perl 6在这里有一个很有趣的非可变泛型跟可变类别的混合体，以及一个有趣的策略在谁被允许何时关闭类别，举例来说，类别不被允许自行关闭或是了结，抱歉，为了某些原因我一直在谈论Perl 6，由于事实在设计Perl 6时我必须考虑到所有这些层面。
类别基础 / 原型基础
这里有另一个允许两个方法可以谈论的层面，你们有些人可能对无类别语言像是Self或是JavaScript熟悉，不像类别那样，物件只是从他们的祖先复制或是授权给其他的物件，对于很多模型来说，这是比较接近真实世界的运作方式，真实的生物在他们再一次生产时只是在复制他们的DNA，它们没有自己的DNA，而@ISA列会告诉你父物件含有他们其余的DNA。
Perl 6的中介物件协定预设是类别基础的，但它也有足够的弹性来设定原型基础的物件，你们有些人在Perl 5有玩过Moose，Moose基本上是Perl 6物件模式的原型，反正在语义方面，语法有一点不同，希望在Perl 6可以更自然一点。
被动资料、全域一致性 / 主动资料、局部一致性
你对资料和控制的看法会随着你的大脑如何地功能化或物件导向而决定，人们的思考相异，有些人很数学性地思考，用可证明的普遍真理来措辞，功能化的程式设计师不太关心堆叠跟堆积之间内隐的计算状态的实作，只要事情看起来很单纯且不受副作用影响。
其他的人用社交的方式思考，它是依据每个合作实体都有他们自己的自由意志，储存在每个个别物件的计算状态对他们来说相当的重要，在某些地方不会关闭连续性的堆积。
当然，我们中的一些无法决定我们是要跟随福尔摩斯的逻辑或是华生博士的交际，幸运的是，指令码既不是很逻辑的也不是很交际的，因为这两种方法可能对一般人来说更平易近人。
资讯的隐藏 / 范畴的界定 / 附件
最后假如你正在设计一个电脑语言，有无限多的方法可以来封装资料，你必须决定哪些是重要的，什么是最好的方法可以让程式设计师实现关注点分离？
物件 / 类别 / 层面 / 闭合 / 模组 / 样板 / 特性
你可以使用这些不同传统的封装机制的任一种。.
交易 / 反应 / 动态范畴
或者你可以以时间为基础的不同领域方式来隔离资讯。
程序 / 执行绪 / 设备 / 环境
你可以附加资讯到不同的OS观念。
荧幕 / 视窗 / 面板 / 选单 / 图示
你可以在你的GUI隐藏资讯在不同地方，是啊！我知道，每件东西都是物件，但有些物件可能更合适。
句法范畴 / 语义范畴 / 语用学范畴
资讯可以附加各种不同抽象的程序包括很奇怪范畴的词汇，但是假如你想得够仔细的话，你会知道词汇范畴也是动态范畴很有趣的一种，或是没有正确执行的递回，一个state变数是真的比my变数还要单纯的词汇，因为它分享了所有呼叫的词汇范畴，但是即使state变数复制了闭合的拷贝，只有全域变数才是真正的词汇，只有在你指涉到全域变数到一给定的词汇范畴，想想看吧。
因此我们大部分的范畴恰好是连接到一特定的句法范畴的语义范畴。
你可能会想知道什么是语用学范畴(pragmatic scope)，那是使用者的程式储存在他们大脑中的范畴，或是他们大脑中的某些替代品，像是游戏盒那样，在一定的意义上，大部分Internet上的网页是语用学范畴的一部分，正如大多数资料库中的资料一样，语用学范畴的特征就是你不会真正知道容器的生命周期，它只是在那里的某个地方，并且最终将由委大的垃圾收集器(Great Garbage Collector )收集所有那些别人遗忘的资讯，Google的暂存只能维持这么久，最后我们会忘记每一个网址的意义，但是我们一定不会忘记网址的原则(principle of the URL)，那会带领我们到下一个自由的国度。
use Lingua::Perligata;
假如你允许一个语言在词汇范畴内变异它自己的文法，你如何利落地追踪？Perl 5发现了一个非常糟糕的方式来做，但即便如此我们已经结束了像Perligata跟Klingon这样的Perl 的方言，假如我们真做对了它会像什么？
要正确地处理包括处理语言的演进到一个或一系列的语用学范畴内，你必须能够命名你的方言，有点像一个网址，所以需要有一个普遍的基础语言，来歪曲普遍的根本语言到你喜欢的方言，这真的很接近Perl6愿景的中心，我们不把Perl 6看成是一个单一的语言，而是视为一个相关家系的基础语言，作为一个家系，会有共享的文化价值在姊妹语言跟后代语言之间来回地传递。
我希望你们对这些自由度会感到非常害怕，我敢肯定还有其他方面会更为可怕。
但是…我认为这是一个可管理的问题，我认为还是把Perl 6当成是指令码语言可以很容易的就上路是可能的。
我认为它可以管理是因为，对每一个维度来说，它不只是一个二元决策，而是被定位在设计时期、编译时期或甚至是执行时期的旋钮，对一给定的维度X，不同的指令码语言可以做不同的选择，将旋钮设在不同的位置。
You can’t even think about X!（你甚至不能考虑X！）
There’s only one way to do X!（只有一个方法做X！）
There’s more than one way to do X!（有一个以上的方法做X！）
There are too many ways to do X!（有太多的方法做X！）
你可以在这里认识一些口号。
卷缩
所以我不建议所有的指令码语言把所有的维度都考量进来，即使是Perl 6尝试这样做，指令码范例不是这些维度的任一种，根据不同的理论宇宙是10个或20个维度铺设成的，但是通常我们只能得到三个半维度，其余的可以说是被卷缩，或许我们可以活在一个指令码的宇宙中。
在大部分的指令码语言中我们称Perl 6在大部分的时间有大部分的维度卷缩起来，但是不像真实的宇宙那样，需要使用巨大的机器还使这些维度变直，我们只需要直接保持我们的宣告就可以使这些维度变直，嗯，我们可以试试看，在哪里失败，我们就可以依靠文化来让事情变直。
举例来说，这正是Perl 5已经发生过的，我们有这个宣告，use strict; use warnings;，但它的文化，决定执行他们的使用，正因如此，我们已经决定，大部分的Perl 6也应该是预设如此，它是蜂巢决策之一，再这个例子里蜜蜂会变成较语言设计者还要聪明，而这也应该如此。
未来
嗯，所以指令码的未来是什么？
就我完全公正的意见里，那就是Perl 6. :-)
虽然严肃一点来说，预测这个生态环境会结束许多小语言以及一些主要的语言是无风险的，有些语言像AppleScript有独特的生态区位而且也不可能继续成长，其他的语言习惯他们原来的区位外，总是有一些通才，像是乌鸦跟小嘲鸫，跟专才像是企鹅跟渡渡鸟。（或许不会一直都是渡渡鸟…）
在通才之间，传统的观点认为愈差就愈好的方法是比较可以适应的，就个人而言，我对这个论点感到有点厌倦：我的愈差就愈好比你的愈差就愈好还要好因为我的愈好是更糟的！难道愈差就愈好这个方法总是会赢这是真的吗？现在我们正试图在Perl 6偷用愈好就事愈好得循环并且希望可以在还回到经验可靠的愈差就愈好的方法前可以出人头地，不论是否可行，只有时间可以证明一切。
你真有毅力翻这么长的好文章
感谢！:)
这一篇真的很长，也颇难翻的，算是培养耐力吧！