云风的 BLOG

比特币的脚本语言也是使用的Forth语言，也许会给Forth语言的推广起到作用吧。

中学时我也迷过Forth语言，:)

2010年毕业后，我就接触了forth语语言，2012年后开始用C。真心感觉forth就是鸦片，一旦使用一生相伴。forth真心是个牛逼的胶水语言，牛逼到可以把不同计算机胶水起来。不过forth标准在多任务上有待说明

最近看到一个8th语言，挺不错
(8th-dev.com)，它是基于forth的。

本人早在80年代就使用forth，当时是fig-83标准。
文章无论翻译的如何好，均不如自己亲自用forth写个小程序的感受更确切。forth的特点不太容易用语言表达，可谓“妙不可言”。
现在在windows上比较好用的是Win32Forth。支持多线程和对象编程，非常好用。
有一句老话或许能在某种程度上可以描述一下Forth：如果C语言让你感觉它是最好的程序设计语言，那么forth会让你感觉你自己是最好的程序设计师。
至于forth程序的运行速度是否比C更快，取决于程序设计师自己。因为设计师可以直接使用汇编提高自己的关键程序段。

云风没翻译的后半部分(硬件)

Visitor：人们是怎么看待他们进行开发工作的硬件平台的，是一种资源还是一种限制？如果你认为它是一种资源，你是否会想要优化这些代码并压榨每个硬件的极限？如果你认为它是一种限制，你是否会在写代码的时候怀着一个想法，你的代码将来会运行在一个更强大的新硬件上？这不是一个假设，因为现在的硬件更新换代非常快。

Chuck:一个非常敏锐的观察，软件必然与它的硬件互相匹配。PC上的软件都在期盼更快更强大的电脑，但是对于嵌入式系统来说，软件更期望硬件系统能在项目周期里保持稳定。并且不是所有的软件都需要从一个项目转移到另一个项目。所以这里的硬件是一种强制性的约束，但并不意味着是一种限制。但是，对于PC来说，硬件是一种将会增长的资源。而并行处理的出现改变了这一想法。应用程序们无法像对付单个电脑那样压榨多个电脑的资源极限，这使得它们无法跑得更快。重写历史遗留下来的软件来适应并行处理的办法显然是不现实的，期待某天出现更聪明的编译器能拯救这一切，反倒是更有可能。

Visitor：现存问题的根源是什么？

Chuck:是速度！在一个应用程序中，电脑必须做很多事，这些事可以被单个处理器以多任务的方式完成，也可以同时被多个处理器完成。后者更快，而且同时期的软件需要那种速度。

Visitor：解决方案是在硬件上，还是在软件上，又或是两者兼有？

Chuck:把多个处理器粘合到一起没什么难度的，所以硬件上的问题已经解决了。如果软件能够用硬件这种方式来编程，那么问题就解决了。但是话又说回来了，如果软件能以这样的方式重写一遍，那软件就足够高效，也就不需要使用多处理器了。现在的问题是，要用多处理器来运行未经修改的历史遗留软件。这需要一种仅在传说中出现过的非常聪明的编译器。

让我更吃惊的是，70年代写的软件现在无法被重写。一个可能的原因是，在那些日子里，软件是令人激动的，所有的编程工作在第一时间就被完成了，程序员们怀着极大的乐趣每天工作18个小时。但是现在，编程只是一个朝九晚五的工作，就像日程表上的团队任务的一部分，没什么乐趣可言。所以他们加了另一个软件层来避免重写旧的软件。这至少比重写一个愚蠢的文字处理器更有乐趣。

Visitor：在普通的计算机上，我们已经拥有了强大的计算能力，但是在这些系统上，到底做过多少有实际价值的计算？它们又做过多少移动、格式化数据的事？

Chuck:说的没错。大多数计算机只是在移动数据，并不是在计算。不仅仅是移动数据，还有压缩，xx，加密（encrypting, scrambling.）。At high data rates, this must be
done with circuitry so one wonders why a computer is needed at all.

Visitor：我们能从中学到什么？我们应该用另一种不同的方法制造硬件？
Don Knuth曾经发出过一个质疑：在一秒钟的时间里，计算机内部到底发生过什么？他说，我们所发现的，能改变很多事。

Chuck:我的计算机芯片认识到了这一点，在它拥有一个简单但很慢的乘法运算的时候，它并不常用。在内核之间传递数据和存取内存才是最主要的操作。

Visitor：一方面，你有一种能使人们开发他们自己的词汇表，并且不需考虑硬件问题的语言；另一方面，你有一个非常小的、能紧密连系硬件的内核。一个很有意思的问题是，forth是怎么连接这两者之间的断层的？在某些机器上，在你和你的forth内核之间真的没有用操作系统连系起来？

Chuck:没有，forth是真正独立的，这个内核已经包含了所有必需的东西。

Visitor：但是它为使用forth编程的人抽象了硬件。

Chuck:是的。

Visitor：LISP机也做过类似的事，但是并没有变得流行起来。forth倒是不声不响的完成了这个工作。

Chuck:不过，LISP并没有包含I/O。事实上，C也没有包含I/O。正因为它没有包含I/O，所以它才需要一个操作系统。而forth在一开始的时候就包含了I/O。我不相信那些大多数普遍的情况，当你面对一个新型的机器时，你需要这个新机器的唯一原因就是，你需要它的特别之处。而你要做的，就是利用它的这些特性，你需要工作在输入输出这个底层层面上，而且你也能够做到这点。

Visitor：Kernighan和Ritchie曾经为C而争论过是否需要一个最小的公因子使porting变得更容易，而你已经找到更容易的Port方式了。

Chuck:我有几种标准的方式去做那些事。我有一个词——我先假设它已经存在了——它能从一个Port上取得8个bit。它在不同的计算机上会用不同的方法被定义，但是它在堆栈上应该拥有同样的功能。

Visitor：也就是说，forth相当于C加上标准I/O库？

Chuck:嗯，但是在早期我是用标准FORTRAN库工作的，它糟糕得可怕。它只有错误的词，而且极其昂贵和笨拙。它很容易就能定义出一大堆执行I/O操作的指令，而且还是你不需要的那种排在前头的预定义协议（protocol）。

Visitor：你觉得你自己在这种情况下浪费了很多不必要的时间？

Chuck:在FORTRAN里，是这样。当你在处理Windows的时候，这里没什么你能做的，它们不会让你控制I/O的，所以我远离了Windows。即便如此，即便没有Windows，对forth来说，奔腾处理器仍然是最复杂难用的机器。它有过多的指令，还有过多的硬件特性，例如the lookaside buffers and the different kinds of caching这些你完全无法忽视的东西。你只能用自己的方式走自己的路，而且为了使forth在它上面跑起来，必要的初始化代码也是最困难最笨拙的。即使它只需要被执行一次，我仍然要花费很多的时间试着弄明白怎样才能使它正确的运作。我们曾经在奔腾的芯片上独立运行过forth，所以我们明白这有多么麻烦。这个过程延续了差不多10年，也在某种程度上去适应Intel在硬件上作出的变更。

Visitor：你提到forth能支持异步操作，你能解释一下什么是异步操作吗？

Chuck:好吧，这里有几种解释。forth总是有着多重编程，多重读取的叫做协作的能力。我们有一个词叫pause，如果你有一个任务，并且它运行到了一个无事可做的阶段，它会说pause，然后调度程序会分配资源给循环中的下一个任务。如果你不说pause，你会独占整个计算机，但事实上绝不会出现那种情况，因为这是一个专一（dedicated ）的计算机。它在运行单个应用程序的时候，其他的任务也是友好的。我猜在那些古老的日子里，所有的任务都应该是友好的。这就是一种异步，这些任务都可以运行，做它们自己的事，而不需要同步。

forth的其中一个特性是，那个名叫pause的词能被隐藏在底层词中。每一次你试着读写磁盘时，这个pause将会为你执行，因为磁盘组知道它不得不等待这个操作的结束。

在新的芯片里，我开发的多核芯片有着同样的哲学。每个计算机都是独立运行的，当你的计算机上有一个任务，而旁边的计算机有另一个任务时，他们在同一时刻运行，但却能彼此交流。这就相当于一个多线程计算机上的任务所做的事。

forth只是非常好的因子化这些独立的任务。事实上，在多核计算机里，我使用并不是完全一样的程序，但是我能用同样的方式因子化这些程序，使它们能并行跑起来。

Visitor：这些联合起来的多线程中，是否每一个线程都有它自己的堆栈？是你给它们分配的吗？

Chuck:当你在做一个任务转换时，有时候你所需要做的全部事情，只是把词保存在栈顶，然后修改堆栈指针。有时候你不得不把堆栈转移出去，并加载一个新堆栈，但是如果出现那种情况，我会给它一个深度非常浅的堆栈

Visitor：你故意限定了堆栈的深度？

Chuck:是的。最初，堆栈的深度相当随意。我设计的第一个芯片有一个256个深度的堆栈，因为当时我认为这个堆栈已经很小了。我设计的其中一个堆栈只有4个深度。现在我选定8或10作为一个好的堆栈深度。so my minimalism has gotten stricter over time.

Visitor：我将期待它走向另一条路。

Chuck:不过，在我的VLSI设计应用中，我专为递归设计了一种芯片，我不得不设置了大约4000的堆栈深度。为了做到这一点，需要一种完全不同的堆栈，一种用软件实现的堆栈。但是，在奔腾芯片上，它能成为一个硬件堆栈。

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

应用程序设计

Visitor：你带来了一个观念，forth是针对例如微型计算机网络协作（智能微尘）的理想语言。你认为哪种应用程序适合那些微型计算机？

Chuck:当然是需要互相交流的程序。但是我才刚刚开始学习怎么让独立的计算机群能联合完成一个更大的任务。我们设计的多核电脑实在是很小，它们只有64个词长的内存。好吧，为了显得它们更不一般，它们拥有128个词长的内存：64 RAM，64 ROM。每个词都能支持4个指令，在一个给定的计算机里只有512个指令，所以任务变得相当的简单。现在你拿来一个任务，类似于TCP/IP，堆栈并因子化这个任务，把它分给若干个计算机，用这种方式，你能用不超过512个指令的计算机执行这些操作。这是一个美妙的设计问题，也是我目前正在使用的工作方式。

我认为这就是几乎所有应用程序的真实写照。当一个应用程序被分解成独立的片段时，它就变得相当容易编写，即使是运行在单个的连续执行的处理器上。就像视频画面通常做的那种分解成帧的方式一样。同样，我也认为这是压缩和解压缩图像的真实写照。但是我才刚刚开始学习怎样去做这些。

Visitor：你是否试过其他一些并不适合它的领域？

Chuck:当然是历史遗留软件。我被那些个遗留软件纠结过，但是我认为还不如重新规划需求，这种方式更加自然，更接近我们大脑思考的方式。我其中一个动机就是想有一个小内核。我的想法是，意识产生于它们的交流，而不是它们中任何一个的操作。

遗留软件是一个不受重视但很严重的问题，它只会变得越来越糟，不仅仅在银行，还在航空和其他技术界。这个问题就是几百万行的代码，而这些代码能被forth用几千行代码重写。不要考虑用聪明的机器去翻译这些代码，那只会制造出更庞大的代码。而且没有办法能使那些代码有效的运作，这些代价和冒险是相当可怕的。遗留代码有可能成为我们文明衰落的原因。

Visitor：这听起来像是你在打赌未来的10-20年里，我们将看到越来越多的软件产生于代码之间的散漫衔接。

Chuck:嗯，是的。我很确定会出现这种情况。RF交流相当不错，他们谈论你身体里的微小因子，那些对事物的确定、对事物的感知，并且这些因子能通过RF（或者声音）进行交流。它们做不了太多事，它们只是一些分子，所以这能显示这个世界是怎么运行的。它也是我们人类社会组织起来的方式。我们有60多亿独立的因子在这里协作。

Visitor：选择贫乏的词汇将导致糟糕的设计和缺乏可维护性的程序。用数百个词编写一个大型应用程序会不会导致出现某些不被外人理解的隐语？你是怎么避免这个问题的？

Chuck:我是记不住那些词的，如果你想去记住它们，你会把自己的脑子记到打结。在一个程序里，我有这个词——现在我已经忘了它叫什么了——但是我曾经定义并且修改过它，而它最终的意思是“相反的”。就像你有一个叫right的词，但是它却向左走，那将是极其可怕的混乱。我做了一番心里斗争，最后还是重命名了这个词，否则它会成为程序中干扰你认知的不可理解的部分。

我喜欢使用完整的英文单词，而不是缩写。我喜欢把它们拼出来。另一方面，我也希望它们足够短小。不久你就能用完短小又含义丰富的英文单词，然后你就该去做点别的事了。我讨厌用前缀的方式命名——这是一种无脑的方式，并且它试图创造出让你可以不断重复使用完全相同的老名字的名字空间。在我看来，这是一种逃避。这是一种辨别词名的简单方法，但你能够有更加聪明的办法。非常多的forth程序都有清晰的词汇表，你能很容易的重用这些词。在这个语境里，这个词做了这个；在那个语境里，它又做了别的。但在我的VLSI设计里，以上这些全都不适用了。我需要至少上千个词，并且它们还不是英文单词，它们都是信号名字或别的什么。我不得不完全改变我以往的做法。现在它变得完全不可读了。但是在另一方面，它里面充满了类似nand、nor、xor之类的逻辑门。尽管如此，我还是在使用这些词。

现在，我看到其他人在使用forth，我也不想自命是唯一的forth程序员。
他们其中一些人能很好的给事物命名，但另一些人却做的很糟。
一些人能写出很易读的句子，而另一些人认为这样做完全没必要。
一些人能定义出很短的词，而另一些人却能定义出一个占据了满满一页的词。
forth没有规则的限制，但却有风格的选择。

forth与 C 、Prolog、ALGOL、FORTRAN的不同点在于，这些常规语言总是期望着要把所有可能的结构和语法在一开始就构造出来。这就产生了一些非常笨拙的语言。我认为C就是一个包含了括号、braces、冒号、分号以及所有一切的笨拙语言。而forth排除了这些不必要的东西。

我没有解决这个一般性的问题，我只是提供了一个工具，其他人可以用它解决他们遇到的任何问题。它拥有完成任何一件事的能力，但没有完成所有事的能力

Visitor：微处理器应该包含源代码吗,那样一来它们甚至能在十年之后保持稳定?

Chuck:没错，在微电脑里包含源代码的这种做法能使它们很好的文档化。forth是紧凑的，所以才能使这种做法得以实现。但下一步是包含编译器和编辑器，那样一来微电脑的代码在不需要另一台电脑或操作系统的情况下，就能被检查和修改，否则时间长了就有丢失源代码的可能。colorForth是我这种做法的一个尝试。全部所需的只是以K为单位的源代码，这样就能很容易的储存在闪存上，它将会在久远的未来里发挥它的作用。

Visitor：语言的设计和用这种语言编写的软件在设计上有什么连系吗？

Chuck:一种语言就决定了它的使用方式。人类的语言真实的证明了这一点。看看罗曼语（法语，意大利语）、西方语言（英语，德语，俄语）和东方语言（阿拉伯语，汉语）的区别，这些语言影响了他们的文化和世界观。语言的种类影响了说什么和怎么说。其中，英语显得尤其简洁并且变得流行。

人机语言也是如此，第一批语言(COBOL, FORTRAN) 太verbose，之后的语言(Algol, C)有着非常严格的语法。这些语言必然会导致庞大、笨拙的描述法则。它们能表达任何事物，但是做的很糟糕。

forth解决了这些问题，它有着自由的语法，它鼓励紧凑、高效的描述，最小化了对注释的需求，而注释会导致不正确的描述，并分散对代码本身的注意力。

forth还有一个简单高效的子程序调用方式。在C语言里子程序调用需要昂贵的建立和恢复，这就阻碍了子程序的广泛使用，并且鼓励了制定详尽的参数来分摊调用的花费，但这会导致庞大复杂的子程序。高效的子程序调用允许forth程序能够被高度因子化分解成许多小的子程序，而forth程序本身也确实是这样做的。我个人的风格是一行长度的定义，数百个简短的子程序。在这种情况下，代码里名字的命名就显得非常重要了，就像 a mnemonic device 和一种达到可读性的方法。可读的代码意味着更少的文档，稀少的语法意味着学习forth的代价很小。这些对于我而言，意味着个人的创造力和令人愉悦的代码。其他人却只看到它的短处，害怕在管理层面上失去控制和标准化的缺乏。我认为管理层面的失败比语言的缺陷更加严重。

Visitor：你说“大多数的错误是出在语法上”，你是怎么避免forth编程中其他类型的错误的？类似逻辑错误、可维护性错误，还有糟糕的类型判断。

Chuck:forth里出现的大多数错误都是与堆栈管理相关的。举个例子，如果你不慎在堆栈上遗留了某个不应该呆在那里的东西，而它马上就能让你摔个狗吃屎。每个词都应该有一个对堆栈内容的描述，这很重要。它会告诉你，它往堆栈上放进了什么，又从堆栈上拿出了什么。但这只是一个描述，你不能完全的信任它。有些人会在使用这些词之前对它们进行测试，并观察堆栈上的情况。其实有个最基本的解决方法，那就是因子化。如果你有一个一行长的词，当你读它的时候，你就能在脑子里演绎出它在堆栈上的表现，并且还是正确的。你可以测试它，并观察它是否如你所想的那样工作，但即便如此，你最好还是提防堆栈上有可能出现的错误。dup和drop这两个词在forth程序里是无处不在的，并且它们必定能被正确使用。在脱离语境测试这些词的时候，你只需要放进它们需要的参数，然后观察他们输出的结果。另外，当你用从底往上的方式开始编程时，所有你定义的词都能正确的工作，因为你已经测试过它们了。还有，forth里只有极少几个条件语句，一个if-else-then结构，一个begin-while结构。我要教给你们的哲学是，精简程序中的条件语句的数量。比起一个需要测定某个数值之后再决定做这个还是做那个的词，还有更好的方法，那就是，你有两个词：一个做这个，一个做那个，然后你选择合适的那一个。但是在C语言不是这样做的，因为调用的代价太昂贵了，所以他们更趋向于根据输入的参数，让同样的程序做不同的事。这就导致了那些历史遗留软件里所有的bug和复杂性。

Visitor：试图解决执行不力的情况？

Chuck:嗯。循环是不可避免的，但是循环可以变得很容易。一个forth循环，准确的说，一个colorforth循环，是非常简单的，只有一个单独的入口和一个单独的出口。

Visitor：你会给初学者什么样的忠告，使他们能更愉快更高效的编程？

Chuck:可以肯定的是，这个忠告不会出乎你的意料之外，我会说，你应该学着去写forth代码，即使你不打算成为专业的forth程序员。因为它会教会你一些东西，并且给你一个更好的视角去观察你现在所使用的语言。比如我现在要写一个C程序，即使我以前从没写过C程序，但我会用forth那种一大堆简短子程序的风格去写它。即使这样做会付出某些代价，但我认为这种代价对于可维护性来说是物有所值的。另一件事就是KISS原则，在设计一个航空器、或是写一个应用程序、甚至是一个文字处理器的时候，有一个无法避免的趋势是添加特性、再次添加特性、再三添加特性……直到变得不可能进行维护为止。我给他们的建议是，针对不同的市场，做出一大堆的文字处理器。用微软的WORD写一个简单的Email显然是很傻的行为。所有可能用到的功能之中，有99%是不必要的。你应该有一个Email编辑器。以前应该曾经有过，但现在的趋势不是这样。我是觉得很奇怪的。

保持简单。如果你碰到一个应用程序，如果你就是这个设计团队中的一员，试着说服其他人保持简单。不要预期，不要设计一个你认为将来某一天可能会出现的情况，你只要处理好你当前的问题，过早的预期是没有必要的。你可能会预期到10件事的发生，但最后其中只有一个发生了，所以你浪费了太多的努力。

Visitor：你是怎样理解简单的？

Chuck:近段时间出现了一个关于复杂性的学科，其中就包含了如何测量复杂性。而我喜欢的那个描述（我不知道这里是否还有其他的另一个）就是最短的那一个。或者你有两个概念，较短的那个描述就是更简单的。如果你能为某个东西想出一个较短的定义，你就想出了一个更简单的定义。

但是任何描述都离不开语境，所以上面所说的在这种很微妙的情况下是失败的。如果你想在C里面写一个非常短的子程序，你也许会说这很容易，但是你要依赖于C编译器、操作系统和准备执行这个程序的电脑的存在。所以，你不是在做一个简单的东西，当你考虑到更广阔的环境时，你是在做一个精致的、复杂的东西。我想它就像“美女”，你没法定义它，但是当你看到它的时候，你就知道是它了，简单就是这样的一个东西。

Visitor：那团队编程怎么进行呢？

Chuck:团队编程？你过虑了。一个团队的第一项工作就是把问题分解成相对独立的部分，然后把每一部分分配给团队成员，而团队领导者的职责就是保证各部分能再次结合到一起。有时候两个人需要协同工作，在互相探讨一个问题时能使得问题更加清晰明确，但是过多的交流反而又转回到问题本身。团队思考并没有解放创造力，当若干个人在一起工作时，必然只有一个人在做这个工作。

Visitor：这是否对每一类项目都有效？如果你不得不写一个含有丰富特性的东西呢，例如OpenOffice.org，这个听起来够复杂了吧？

Chuck:某些类似于OpenOffice.org的东西将被因子化成多个子项目，把每一个分配给一个单位去做，并且他们之间能有足够的交流来保证程序的兼容性。

Visitor：你觉得怎样才是一个优秀的程序员？

Chuck:一个优秀的程序员能迅速写出优秀的代码。优秀的代码就是正确、紧凑和可读。“迅速”的意思是以“小时”或“天”的时间单位来计算。而一个糟糕的程序员只会在嘴上谈论这个问题，把时间浪费在计划上而不是编程上，而且还总想升迁到一个不再需要编程和调试的岗位。

Visitor：你对编译器的看法是什么？你觉得它们掩盖了程序员的真实能力吗？

Chuck:编译器可能是所有写出来的代码当中最糟糕的。可能它们被某个以前从未写过一个编译器的人写出来，并且这个人以后也不会再去维护这个编译器。越是精心制作的语言，就越是复杂，bug丛生、无用，指的就是编译器。但是一个简单语言的简单编译器是一个非常有用的工具——除非你只是想看使用说明书。比编译器更重要的是编辑器，多样的编辑器让每一个程序员都选择了他自己喜欢的，而这极大的破坏了协作的努力。这就促进了从一个到另一个的手工作坊式的转译。

编译器作者的另一个失败之处就是他们的编译器都有着自己独特的关键字符，所以键盘无法变得更小更简单，而源代码则不能通用。但是一个程序员的能力跟这些工具是不相关的，所以他能迅速掌握它们的特点并生产出优秀的代码。

Visitor：软件应该怎样文档化？

Chuck:在我眼里，注释的价值远远没有其他人认为的那样重要。原因如下：
@注释应该是精简的，但它们经常是隐秘的，然后你不得不去猜测它们到底是什么意思。
@注释应该是verbose，但它们却淹没了它们所要解释的代码。这实在是很难把代码和注释联系起来。
@注释经常被写得很糟糕，程序员的文字表达能力是很难判定的，特别是当他们的母语不是英语的时候。术语和语法错误经常使注释不可读。
@最关键的是，注释经常是错误的。注释的修改很可能不会与代码的修改同步。虽然代码会被重点回顾，而注释少有这种待遇。一个错误的注释比没有注释更糟。读代码的人必须先判断，注释和代码到底哪个才是正确的。

注释经常被错误的理解了，它们应该解释代码的目的，而不是代码本身，解释代码本身是无用的。并且如果注释是错误的，那就是彻底的欺骗了。注释应该解释为什么代码是现在这样，它想要做的是什么，以及一些用来实现它的花样技巧。

colorForth把注释因子化到了一块阴影区域，把它们从代码中移了出来，这就使代码更加可读。然后它们立刻可以用来阅读或更新。这种方式也根据代码的长度，限制了注释的长度。

注释不能代替准确的文档，一个文档必须对代码模块的解释写得非常详细，这将远远超出注释所能做到的。A document must be written that explains in prose the code module of interest. It should expand greatly the comments and concentrate on literate and complete explanation. Of course, this is rarely done, is often unaffordable, and is easily lost since it is separate from the code.

Visitor：引用自http://www.colorforth.com/HOPL.html:
“forth专利的问题曾经被详尽讨论过，但是软件专利引起了太多的争议性，而且看起来很需要最高法庭的判决，在此之后，NRAO不再继续做这种低效的事了。现在，这个权力归还给了我，我不认为想法应该被专利化。事后证明，forth的唯一机会是在它曾经繁荣过的公众领域，”

Visitor：软件专利至今还是有争议的，你对专利的想法还是跟当初一样吗？

Chuck:我从来就没有支持过软件专利。这听起来就像是要专利化一个想法，而且专利化一个语言是特别恼人的。一个语言只有在它被使用的时候才有成功的可能。任何阻碍它使用的行为都是愚蠢的。

Visitor：你觉得专利化一项技术是阻止还是限制了它的扩散？

Chuck:推销软件很不容易，因为复制软件很容易。公司们做了很多努力去保护他们的产品，甚至采用了使软件无法使用的手段。我对这个问题的回答是，卖硬件送软件，买一赠一。硬件是很难复制的，再加上配套的软件，会显得更有价值。专利是处理这种问题的一个办法，它证明了新发明带来便利的价值。但这需要一种脆弱的平衡，劝阻那些不必要的专利，并连系到以前较早的艺术/专利。要执行以上所说，就要耗费巨大的津贴。近来一些大公司提议修改专利法来排斥单干的发明家，单干的要悲剧了，

云风大哥。。。膜拜一下~~

不错！支持云风大哥翻译好文章！

人名应该是Chuck Moore吧？

谢谢你的翻译！很精彩。

路过，学习了~

Chunk: 哦，我在六十年代去了趟 Stanford ，那里有组研究生正在写一个 ALGOL 编译器——Burroughs 5500 用的版本。当时我想他们不过才三四个人，就三四个人坐在那写一个编译器，我那个内牛满面啊。

我想，“靠，他们要能做，我也能做。”然后我就干了。其实一点也不难。当年写编译器还是有点神秘西西的。

========

这段翻译得太好了。。。内牛满面。。

.......

Forth 的相对性能取决于机器模型。Forth 通常使用 ITC 或 DTC 的模式并不完全切合 x86 的机器模型。用 SC 模式就应该能达到 C 的速度。若换个机器，可能结果就不一样。

而且在 x86 上，基础库也需要根据新指令集仔细的改进。

不过我个人感觉 Forth 首先追求的是紧凑和可移植性，其次才是运行效率。

forth很好啊

Forth 太有趣了。
可读性太差,没法推广

grad student不是毕业生，是研究生。

看了下performance页面，还是比不上C的运行速度呀 :(

建议在wave去创一个项目。。
参照这个。。
http://mmdekq.appspot.com/media/agZtbWRla3FyDAsSBU1lZGlhGME-DA/NF2C_Wave.html

真的很难得，这样痴迷于编程!