document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

Revert "My Lisp Experiences and the Development of GNU Emacs.md"

Browse Source
This commit is contained in:
Xingyu.Wang 2018-08-20 10:48:25 +08:00 committed by GitHub
parent c2f1839461
commit 672888ae62
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 111 additions and 109 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

111
sources/talk/20140412 My Lisp Experiences and the Development of GNU Emacs.md Normal file
View File

@ -0,0 +1,111 @@
My Lisp Experiences and the Development of GNU Emacs
======
> (Transcript of Richard Stallman's Speech, 28 Oct 2002, at the International Lisp Conference).
Since none of my usual speeches have anything to do with Lisp, none of them were appropriate for today. So I'm going to have to wing it. Since I've done enough things in my career connected with Lisp I should be able to say something interesting.
My first experience with Lisp was when I read the Lisp 1.5 manual in high school. That's when I had my mind blown by the idea that there could be a computer language like that. The first time I had a chance to do anything with Lisp was when I was a freshman at Harvard and I wrote a Lisp interpreter for the PDP-11. It was a very small machine — it had something like 8k of memory — and I managed to write the interpreter in a thousand instructions. This gave me some room for a little bit of data. That was before I got to see what real software was like, that did real system jobs.
I began doing work on a real Lisp implementation with JonL White once I started working at MIT. I got hired at the Artificial Intelligence Lab not by JonL, but by Russ Noftsker, which was most ironic considering what was to come — he must have really regretted that day.
During the 1970s, before my life became politicized by horrible events, I was just going along making one extension after another for various programs, and most of them did not have anything to do with Lisp. But, along the way, I wrote a text editor, Emacs. The interesting idea about Emacs was that it had a programming language, and the user's editing commands would be written in that interpreted programming language, so that you could load new commands into your editor while you were editing. You could edit the programs you were using and then go on editing with them. So, we had a system that was useful for things other than programming, and yet you could program it while you were using it. I don't know if it was the first one of those, but it certainly was the first editor like that.
This spirit of building up gigantic, complicated programs to use in your own editing, and then exchanging them with other people, fueled the spirit of free-wheeling cooperation that we had at the AI Lab then. The idea was that you could give a copy of any program you had to someone who wanted a copy of it. We shared programs to whomever wanted to use them, they were human knowledge. So even though there was no organized political thought relating the way we shared software to the design of Emacs, I'm convinced that there was a connection between them, an unconscious connection perhaps. I think that it's the nature of the way we lived at the AI Lab that led to Emacs and made it what it was.
The original Emacs did not have Lisp in it. The lower level language, the non-interpreted language — was PDP-10 Assembler. The interpreter we wrote in that actually wasn't written for Emacs, it was written for TECO. It was our text editor, and was an extremely ugly programming language, as ugly as could possibly be. The reason was that it wasn't designed to be a programming language, it was designed to be an editor and command language. There were commands like ‘5l’, meaning ‘move five lines’, or ‘i’ and then a string and then an ESC to insert that string. You would type a string that was a series of commands, which was called a command string. You would end it with ESC ESC, and it would get executed.
Well, people wanted to extend this language with programming facilities, so they added some. For instance, one of the first was a looping construct, which was < >. You would put those around things and it would loop. There were other cryptic commands that could be used to conditionally exit the loop. To make Emacs, we (1) added facilities to have subroutines with names. Before that, it was sort of like Basic, and the subroutines could only have single letters as their names. That was hard to program big programs with, so we added code so they could have longer names. Actually, there were some rather sophisticated facilities; I think that Lisp got its unwind-protect facility from TECO.
We started putting in rather sophisticated facilities, all with the ugliest syntax you could ever think of, and it worked — people were able to write large programs in it anyway. The obvious lesson was that a language like TECO, which wasn't designed to be a programming language, was the wrong way to go. The language that you build your extensions on shouldn't be thought of as a programming language in afterthought; it should be designed as a programming language. In fact, we discovered that the best programming language for that purpose was Lisp.
It was Bernie Greenberg, who discovered that it was (2). He wrote a version of Emacs in Multics MacLisp, and he wrote his commands in MacLisp in a straightforward fashion. The editor itself was written entirely in Lisp. Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
So Bernie saw that an application — a program that does something useful for you — which has Lisp inside it and which you could extend by rewriting the Lisp programs, is actually a very good way for people to learn programming. It gives them a chance to write small programs that are useful for them, which in most arenas you can't possibly do. They can get encouragement for their own practical use — at the stage where it's the hardest — where they don't believe they can program, until they get to the point where they are programmers.
At that point, people began to wonder how they could get something like this on a platform where they didn't have full service Lisp implementation. Multics MacLisp had a compiler as well as an interpreter — it was a full-fledged Lisp system — but people wanted to implement something like that on other systems where they had not already written a Lisp compiler. Well, if you didn't have the Lisp compiler you couldn't write the whole editor in Lisp — it would be too slow, especially redisplay, if it had to run interpreted Lisp. So we developed a hybrid technique. The idea was to write a Lisp interpreter and the lower level parts of the editor together, so that parts of the editor were built-in Lisp facilities. Those would be whatever parts we felt we had to optimize. This was a technique that we had already consciously practiced in the original Emacs, because there were certain fairly high level features which we re-implemented in machine language, making them into TECO primitives. For instance, there was a TECO primitive to fill a paragraph (actually, to do most of the work of filling a paragraph, because some of the less time-consuming parts of the job would be done at the higher level by a TECO program). You could do the whole job by writing a TECO program, but that was too slow, so we optimized it by putting part of it in machine language. We used the same idea here (in the hybrid technique), that most of the editor would be written in Lisp, but certain parts of it that had to run particularly fast would be written at a lower level.
Therefore, when I wrote my second implementation of Emacs, I followed the same kind of design. The low level language was not machine language anymore, it was C. C was a good, efficient language for portable programs to run in a Unix-like operating system. There was a Lisp interpreter, but I implemented facilities for special purpose editing jobs directly in C — manipulating editor buffers, inserting leading text, reading and writing files, redisplaying the buffer on the screen, managing editor windows.
Now, this was not the first Emacs that was written in C and ran on Unix. The first was written by James Gosling, and was referred to as GosMacs. A strange thing happened with him. In the beginning, he seemed to be influenced by the same spirit of sharing and cooperation of the original Emacs. I first released the original Emacs to people at MIT. Someone wanted to port it to run on Twenex — it originally only ran on the Incompatible Timesharing System we used at MIT. They ported it to Twenex, which meant that there were a few hundred installations around the world that could potentially use it. We started distributing it to them, with the rule that “you had to send back all of your improvements” so we could all benefit. No one ever tried to enforce that, but as far as I know people did cooperate.
Gosling did, at first, seem to participate in this spirit. He wrote in a manual that he called the program Emacs hoping that others in the community would improve it until it was worthy of that name. That's the right approach to take towards a community — to ask them to join in and make the program better. But after that he seemed to change the spirit, and sold it to a company.
At that time I was working on the GNU system (a free software Unix-like operating system that many people erroneously call “Linux”). There was no free software Emacs editor that ran on Unix. I did, however, have a friend who had participated in developing Gosling's Emacs. Gosling had given him, by email, permission to distribute his own version. He proposed to me that I use that version. Then I discovered that Gosling's Emacs did not have a real Lisp. It had a programming language that was known as ‘mocklisp’, which looks syntactically like Lisp, but didn't have the data structures of Lisp. So programs were not data, and vital elements of Lisp were missing. Its data structures were strings, numbers and a few other specialized things.
I concluded I couldn't use it and had to replace it all, the first step of which was to write an actual Lisp interpreter. I gradually adapted every part of the editor based on real Lisp data structures, rather than ad hoc data structures, making the data structures of the internals of the editor exposable and manipulable by the user's Lisp programs.
The one exception was redisplay. For a long time, redisplay was sort of an alternate world. The editor would enter the world of redisplay and things would go on with very special data structures that were not safe for garbage collection, not safe for interruption, and you couldn't run any Lisp programs during that. We've changed that since — it's now possible to run Lisp code during redisplay. It's quite a convenient thing.
This second Emacs program was ‘free software’ in the modern sense of the term — it was part of an explicit political campaign to make software free. The essence of this campaign was that everybody should be free to do the things we did in the old days at MIT, working together on software and working with whomever wanted to work with us. That is the basis for the free software movement — the experience I had, the life that I've lived at the MIT AI lab — to be working on human knowledge, and not be standing in the way of anybody's further using and further disseminating human knowledge.
At the time, you could make a computer that was about the same price range as other computers that weren't meant for Lisp, except that it would run Lisp much faster than they would, and with full type checking in every operation as well. Ordinary computers typically forced you to choose between execution speed and good typechecking. So yes, you could have a Lisp compiler and run your programs fast, but when they tried to take `car` of a number, it got nonsensical results and eventually crashed at some point.
The Lisp machine was able to execute instructions about as fast as those other machines, but each instruction — a car instruction would do data typechecking — so when you tried to get the car of a number in a compiled program, it would give you an immediate error. We built the machine and had a Lisp operating system for it. It was written almost entirely in Lisp, the only exceptions being parts written in the microcode. People became interested in manufacturing them, which meant they should start a company.
There were two different ideas about what this company should be like. Greenblatt wanted to start what he called a “hacker” company. This meant it would be a company run by hackers and would operate in a way conducive to hackers. Another goal was to maintain the AI Lab culture (3). Unfortunately, Greenblatt didn't have any business experience, so other people in the Lisp machine group said they doubted whether he could succeed. They thought that his plan to avoid outside investment wouldn't work.
Why did he want to avoid outside investment? Because when a company has outside investors, they take control and they don't let you have any scruples. And eventually, if you have any scruples, they also replace you as the manager.
So Greenblatt had the idea that he would find a customer who would pay in advance to buy the parts. They would build machines and deliver them; with profits from those parts, they would then be able to buy parts for a few more machines, sell those and then buy parts for a larger number of machines, and so on. The other people in the group thought that this couldn't possibly work.
Greenblatt then recruited Russell Noftsker, the man who had hired me, who had subsequently left the AI Lab and created a successful company. Russell was believed to have an aptitude for business. He demonstrated this aptitude for business by saying to the other people in the group, “Let's ditch Greenblatt, forget his ideas, and we'll make another company.” Stabbing in the back, clearly a real businessman. Those people decided they would form a company called Symbolics. They would get outside investment, not have scruples, and do everything possible to win.
But Greenblatt didn't give up. He and the few people loyal to him decided to start Lisp Machines Inc. anyway and go ahead with their plans. And what do you know, they succeeded! They got the first customer and were paid in advance. They built machines and sold them, and built more machines and more machines. They actually succeeded even though they didn't have the help of most of the people in the group. Symbolics also got off to a successful start, so you had two competing Lisp machine companies. When Symbolics saw that LMI was not going to fall flat on its face, they started looking for ways to destroy it.
Thus, the abandonment of our lab was followed by “war” in our lab. The abandonment happened when Symbolics hired away all the hackers, except me and the few who worked at LMI part-time. Then they invoked a rule and eliminated people who worked part-time for MIT, so they had to leave entirely, which left only me. The AI lab was now helpless. And MIT had made a very foolish arrangement with these two companies. It was a three-way contract where both companies licensed the use of Lisp machine system sources. These companies were required to let MIT use their changes. But it didn't say in the contract that MIT was entitled to put them into the MIT Lisp machine systems that both companies had licensed. Nobody had envisioned that the AI lab's hacker group would be wiped out, but it was.
So Symbolics came up with a plan (4). They said to the lab, “We will continue making our changes to the system available for you to use, but you can't put it into the MIT Lisp machine system. Instead, we'll give you access to Symbolics' Lisp machine system, and you can run it, but that's all you can do.”
This, in effect, meant that they demanded that we had to choose a side, and use either the MIT version of the system or the Symbolics version. Whichever choice we made determined which system our improvements went to. If we worked on and improved the Symbolics version, we would be supporting Symbolics alone. If we used and improved the MIT version of the system, we would be doing work available to both companies, but Symbolics saw that we would be supporting LMI because we would be helping them continue to exist. So we were not allowed to be neutral anymore.
Up until that point, I hadn't taken the side of either company, although it made me miserable to see what had happened to our community and the software. But now, Symbolics had forced the issue. So, in an effort to help keep Lisp Machines Inc. going (5) — I began duplicating all of the improvements Symbolics had made to the Lisp machine system. I wrote the equivalent improvements again myself (i.e., the code was my own).
After a while (6), I came to the conclusion that it would be best if I didn't even look at their code. When they made a beta announcement that gave the release notes, I would see what the features were and then implement them. By the time they had a real release, I did too.
In this way, for two years, I prevented them from wiping out Lisp Machines Incorporated, and the two companies went on. But, I didn't want to spend years and years punishing someone, just thwarting an evil deed. I figured they had been punished pretty thoroughly because they were stuck with competition that was not leaving or going to disappear (7). Meanwhile, it was time to start building a new community to replace the one that their actions and others had wiped out.
The Lisp community in the 70s was not limited to the MIT AI Lab, and the hackers were not all at MIT. The war that Symbolics started was what wiped out MIT, but there were other events going on then. There were people giving up on cooperation, and together this wiped out the community and there wasn't much left.
Once I stopped punishing Symbolics, I had to figure out what to do next. I had to make a free operating system, that was clear — the only way that people could work together and share was with a free operating system.
At first, I thought of making a Lisp-based system, but I realized that wouldn't be a good idea technically. To have something like the Lisp machine system, you needed special purpose microcode. That's what made it possible to run programs as fast as other computers would run their programs and still get the benefit of typechecking. Without that, you would be reduced to something like the Lisp compilers for other machines. The programs would be faster, but unstable. Now that's okay if you're running one program on a timesharing system — if one program crashes, that's not a disaster, that's something your program occasionally does. But that didn't make it good for writing the operating system in, so I rejected the idea of making a system like the Lisp machine.
I decided instead to make a Unix-like operating system that would have Lisp implementations to run as user programs. The kernel wouldn't be written in Lisp, but we'd have Lisp. So the development of that operating system, the GNU operating system, is what led me to write the GNU Emacs. In doing this, I aimed to make the absolute minimal possible Lisp implementation. The size of the programs was a tremendous concern.
There were people in those days, in 1985, who had one-megabyte machines without virtual memory. They wanted to be able to use GNU Emacs. This meant I had to keep the program as small as possible.
For instance, at the time the only looping construct was ‘while’, which was extremely simple. There was no way to break out of the ‘while’ statement, you just had to do a catch and a throw, or test a variable that ran the loop. That shows how far I was pushing to keep things small. We didn't have ‘caar’ and ‘cadr’ and so on; “squeeze out everything possible” was the spirit of GNU Emacs, the spirit of Emacs Lisp, from the beginning.
Obviously, machines are bigger now, and we don't do it that way any more. We put in ‘caar’ and ‘cadr’ and so on, and we might put in another looping construct one of these days. We're willing to extend it some now, but we don't want to extend it to the level of common Lisp. I implemented Common Lisp once on the Lisp machine, and I'm not all that happy with it. One thing I don't like terribly much is keyword arguments (8). They don't seem quite Lispy to me; I'll do it sometimes but I minimize the times when I do that.
That was not the end of the GNU projects involved with Lisp. Later on around 1995, we were looking into starting a graphical desktop project. It was clear that for the programs on the desktop, we wanted a programming language to write a lot of it in to make it easily extensible, like the editor. The question was what it should be.
At the time, TCL was being pushed heavily for this purpose. I had a very low opinion of TCL, basically because it wasn't Lisp. It looks a tiny bit like Lisp, but semantically it isn't, and it's not as clean. Then someone showed me an ad where Sun was trying to hire somebody to work on TCL to make it the “de-facto standard extension language” of the world. And I thought, “We've got to stop that from happening.” So we started to make Scheme the standard extensibility language for GNU. Not Common Lisp, because it was too large. The idea was that we would have a Scheme interpreter designed to be linked into applications in the same way TCL was linked into applications. We would then recommend that as the preferred extensibility package for all GNU programs.
There's an interesting benefit you can get from using such a powerful language as a version of Lisp as your primary extensibility language. You can implement other languages by translating them into your primary language. If your primary language is TCL, you can't very easily implement Lisp by translating it into TCL. But if your primary language is Lisp, it's not that hard to implement other things by translating them. Our idea was that if each extensible application supported Scheme, you could write an implementation of TCL or Python or Perl in Scheme that translates that program into Scheme. Then you could load that into any application and customize it in your favorite language and it would work with other customizations as well.
As long as the extensibility languages are weak, the users have to use only the language you provided them. Which means that people who love any given language have to compete for the choice of the developers of applications — saying “Please, application developer, put my language into your application, not his language.” Then the users get no choices at all — whichever application they're using comes with one language and they're stuck with [that language]. But when you have a powerful language that can implement others by translating into it, then you give the user a choice of language and we don't have to have a language war anymore. That's what we're hoping ‘Guile’, our scheme interpreter, will do. We had a person working last summer finishing up a translator from Python to Scheme. I don't know if it's entirely finished yet, but for anyone interested in this project, please get in touch. So that's the plan we have for the future.
I haven't been speaking about free software, but let me briefly tell you a little bit about what that means. Free software does not refer to price; it doesn't mean that you get it for free. (You may have paid for a copy, or gotten a copy gratis.) It means that you have freedom as a user. The crucial thing is that you are free to run the program, free to study what it does, free to change it to suit your needs, free to redistribute the copies of others and free to publish improved, extended versions. This is what free software means. If you are using a non-free program, you have lost crucial freedom, so don't ever do that.
The purpose of the GNU project is to make it easier for people to reject freedom-trampling, user-dominating, non-free software by providing free software to replace it. For those who don't have the moral courage to reject the non-free software, when that means some practical inconvenience, what we try to do is give a free alternative so that you can move to freedom with less of a mess and less of a sacrifice in practical terms. The less sacrifice the better. We want to make it easier for you to live in freedom, to cooperate.
This is a matter of the freedom to cooperate. We're used to thinking of freedom and cooperation with society as if they are opposites. But here they're on the same side. With free software you are free to cooperate with other people as well as free to help yourself. With non-free software, somebody is dominating you and keeping people divided. You're not allowed to share with them, you're not free to cooperate or help society, anymore than you're free to help yourself. Divided and helpless is the state of users using non-free software.
We've produced a tremendous range of free software. We've done what people said we could never do; we have two operating systems of free software. We have many applications and we obviously have a lot farther to go. So we need your help. I would like to ask you to volunteer for the GNU project; help us develop free software for more jobs. Take a look at [http://www.gnu.org/help][1] to find suggestions for how to help. If you want to order things, there's a link to that from the home page. If you want to read about philosophical issues, look in /philosophy. If you're looking for free software to use, look in /directory, which lists about 1900 packages now (which is a fraction of all the free software out there). Please write more and contribute to us. My book of essays, “Free Software and Free Society”, is on sale and can be purchased at [www.gnu.org][2]. Happy hacking!
--------------------------------------------------------------------------------
via: https://www.gnu.org/gnu/rms-lisp.html
作者：[Richard Stallman][a]
选题：[lujun9972](https://github.com/lujun9972)
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://www.gnu.org
[1]:https://www.gnu.org/help/
[2]:http://www.gnu.org/

109
translated/talk/20140412 My Lisp Experiences and the Development of GNU Emacs.md
View File

@ -1,109 +0,0 @@
我的Lisp体验和GNU Emacs的开发
（Richard Stallman的演讲稿，2002年10月28日，国际Lisp会议）。
由于我的常见演讲都没有与Lisp有任何关系，因此它们都不适用于今天。所以我将不得不放弃它。由于我在与Lisp相关的职业生涯中做了足够的事情，我应该能够说些有趣的事情。
我第一次使用Lisp是在高中时阅读Lisp 1.5手册。就在那时，我的想法是因为可能有类似的计算机语言。我第一次有机会和Lisp做任何事情的时候是我在哈佛大学的新生，我为PDP-11写了一个Lisp解释器。这是一个非常小的机器 - 它有类似8k的内存 - 我设法用一千个指令编写解释器。这为我提供了一些数据空间。那是在我看到真正的软件之前，它做了真正的系统工作。
一旦我开始在麻省理工学院工作，我开始与JonL White一起开展真正的Lisp实现工作。我在人工智能实验室雇用的不是JonL，而是来自Russ Noftsker，考虑到将要发生的事情，这是最具讽刺意味的 - 他当然一定非常后悔。
在20世纪70年代，在我的生活因可怕的事件而变得政治化之前，我只是为了各种程序而一个接一个地进行扩展，其中大多数与Lisp没有任何关系。但是，在此过程中，我写了一个文本编辑器，Emacs。关于Emacs的有趣想法是它有一种编程语言，用户的编辑命令将用这种解释的编程语言编写，这样你就可以在编辑时将新命令加载到编辑器中。您可以编辑正在使用的程序，然后继续编辑它们。所以，我们有一个对编程以外的东西有用的系统，但你可以在使用它的时候对它进行编程。我不知道它是否是第一个，但它肯定是第一个这样的编辑。
这种构建巨大而复杂的程序以便在您自己编辑中使用，然后与其他人交换这种精神的精神，激发了我们在AI实验室进行的自由合作的精神。我们的想法是，您可以将任何程序的副本提供给想要其副本的人。我们与想要使用它们的人共享程序，它们是人类的知识。因此，尽管没有有组织的政治思想与我们将软件与Emacs的设计共享的方式联系起来，但我确信它们之间存在联系，也许是一种无意识的联系。我认为这是我们在AI实验室生活的方式的本质，它导致了Emacs并使它成为现实。
最初的Emacs里面没有Lisp。较低级别的语言，非解释性语言 - 是PDP-10汇编程序。我们写的解释实际上并不是为Emacs编写的，它是为TECO编写的。这是我们的文本编辑器，并且是一种非常难看的编程语言，尽可能难看。原因是它不是一种编程语言，它被设计成一种编辑器和命令语言。有一些命令，如'5l'，意思是'移动五行'，或'i'然后是一个字符串，然后是一个ESC来插入该字符串。您将键入一个字符串，该字符串是一系列命令，称为命令字符串。你会用ESC ESC结束它，它会被执行。
好吧，人们想用编程工具扩展这种语言，所以他们添加了一些。例如，第一个是循环结构，它是<>。你会把它们放在周围，它会循环。还有其他神秘的命令可用于有条件地退出循环。为了制作Emacs，我们（1）添加了具有名称的子程序的工具。在此之前，它有点像Basic，子程序只能用单个字母作为名称。这很难用大型程序编程，因此我们添加了代码以便它们可以有更长的名称。实际上，有一些相当复杂的设施; 我认为Lisp得到了TECO的放松保护设施。
我们开始使用相当复杂的设施，所有这些都是你能想到的最丑陋的语法，并且它起作用了 - 人们无论如何都能够在其中编写大型程序。显而易见的教训是，像TECO这样的语言并没有被设计成编程语言，这是错误的方法。您构建扩展的语言不应该被认为是事后的编程语言; 它应该被设计为编程语言。实际上，我们发现用于此目的的最佳编程语言是Lisp。
是伯尼格林伯格，他发现它是（2）。他在Multics MacLisp中编写了一个版本的Emacs，并且他以直截了当的方式在MacLisp中编写了他的命令。编辑器本身完全是用Lisp编写的。事实证明，Multics Emacs取得了巨大成功 - 编写新的编辑命令非常方便，甚至他办公室的秘书也开始学习如何使用它。他们使用了某人编写的手册，其中展示了如何扩展Emacs，但并没有说这是一个编程。所以那些认为自己无法编程的秘书并没有被吓跑。他们阅读了手册，发现他们可以做有用的事情并且他们学会了编程。
因此，伯尼看到了一个应用程序 - 一个对你有用的程序 - 里面有Lisp，你可以通过重写Lisp程序来扩展它，实际上是人们学习编程的一种非常好的方式。它让他们有机会编写对他们有用的小程序，这在大多数领域是你不可能做到的。他们可以鼓励他们自己的实际用途 - 在最困难的阶段 - 他们不相信他们可以编程，直到他们达到程序员的程度。
那时，人们开始想知道如何在他们没有完整服务Lisp实现的平台上得到这样的东西。Multics MacLisp有一个编译器和一个解释器 - 它是一个成熟的Lisp系统 - 但是人们希望在其他尚未编写Lisp编译器的系统上实现类似的东西。好吧，如果你没有Lisp编译器，你就无法在Lisp中编写整个编辑器 - 如果它必须运行解释的Lisp，那就太慢了，尤其是重新编译。所以我们开发了一种混合技术。我的想法是编写一个Lisp解释器和编辑器的低级部分，以便编辑器的部分内置Lisp工具。这些将是我们认为必须优化的任何部分。这是我们已经在原始Emacs中有意识地实践的一种技术，因为我们在机器语言中重新实现了某些相当高级别的特性，使它们成为TECO原语。例如，有一个TECO原语来填充段落（实际上，要完成填充段落的大部分工作，因为一些耗时较少的部分工作将由TECO程序在更高级别完成） 。您可以通过编写TECO程序来完成整个工作，但这太慢了，所以我们通过将其中的一部分放在机器语言中来优化它。我们在这里使用了相同的想法（在混合技术中），大多数编辑器都是用Lisp编写的，但是必须以特别快的速度运行的某些部分才能在较低级别编写。因为我们在机器语言中重新实现了某些相当高级别的功能，使它们成为TECO原语。例如，有一个TECO原语来填充段落（实际上，要完成填充段落的大部分工作，因为一些耗时较少的部分工作将由TECO程序在更高级别完成） 。您可以通过编写TECO程序来完成整个工作，但这太慢了，所以我们通过将其中的一部分放在机器语言中来优化它。我们在这里使用了相同的想法（在混合技术中），大多数编辑器都是用Lisp编写的，但是必须以特别快的速度运行的某些部分才能在较低级别编写。因为我们在机器语言中重新实现了某些相当高级别的功能，使它们成为TECO原语。例如，有一个TECO原语来填充段落（实际上，要完成填充段落的大部分工作，因为一些耗时较少的部分工作将由TECO程序在更高级别完成） 。您可以通过编写TECO程序来完成整个工作，但这太慢了，所以我们通过将其中的一部分放在机器语言中来优化它。我们在这里使用了相同的想法（在混合技术中），大多数编辑器都是用Lisp编写的，但是必须以特别快的速度运行的某些部分才能在较低级别编写。完成填写段落的大部分工作，因为一些耗时较少的工作部分将由TECO计划在更高层次完成。您可以通过编写TECO程序来完成整个工作，但这太慢了，所以我们通过将其中的一部分放在机器语言中来优化它。我们在这里使用了相同的想法（在混合技术中），大多数编辑器都是用Lisp编写的，但是必须以特别快的速度运行的某些部分才能在较低级别编写。完成填写段落的大部分工作，因为一些耗时较少的工作部分将由TECO计划在更高层次完成。您可以通过编写TECO程序来完成整个工作，但这太慢了，所以我们通过将其中的一部分放在机器语言中来优化它。我们在这里使用了相同的想法（在混合技术中），大多数编辑器都是用Lisp编写的，但是必须以特别快的速度运行的某些部分才能在较低级别编写。
因此，当我编写第二个Emacs实现时，我遵循了同样的设计。低级语言不再是机器语言，它是C. C是便携式程序在类Unix操作系统中运行的一种好的，高效的语言。有一个Lisp解释器，但我直接在C中实现了专用编辑工作的工具 - 操作编辑缓冲区，插入前导文本，读取和写入文件，重新显示屏幕上的缓冲区，管理编辑器窗口。
现在，这不是第一个用C编写并在Unix上运行的Emacs。第一部由James Gosling撰写，被称为GosMacs。他身上发生了一件奇怪的事。起初，他似乎受到原始Emacs的共享和合作精神的影响。我首先向麻省理工学院的人们发布了最初的Emacs。有人希望将它移植到Twenex上运行 - 它最初只运行在我们在麻省理工学院使用的不兼容的分时系统。他们将它移植到Twenex，这意味着全世界有几百个可能会使用它的安装。我们开始将它分发给他们，其规则是“您必须将所有改进发回”，这样我们才能受益。没有人试图强制执行，但据我所知，人们确实合作。
起初，戈斯林似乎参与了这种精神。他在手册中写道，他称Emacs计划希望社区中的其他人能够改进它，直到它值得这个名字。这是采用社区的正确方法 - 要求他们加入并使计划更好。但在那之后，他似乎改变了精​​神，并把它卖给了一家公司。
那时我正在研究GNU系统（一种类似Unix的自由软件操作系统，许多人错误称之为“Linux”）。没有在Unix上运行的免费软件Emacs编辑器。然而，我确实有一位朋友曾参与开发Gosling的Emacs。戈斯林通过电子邮件允许他分发自己的版本。他向我建议我使用那个版本。然后我发现Gosling的Emacs没有真正的Lisp。它有一种被称为'mocklisp'的编程语言，它在语法上看起来像Lisp，但没有Lisp的数据结构。所以程序不是数据，而且缺少Lisp的重要元素。它的数据结构是字符串，数字和一些其他专门的东西。
我总结说我无法使用它并且必须全部替换它，第一步是编写一个实际的Lisp解释器。我逐渐调整了编辑器的每个部分，基于真正的Lisp数据结构，而不是ad hoc数据结构，使得编辑器内部的数据结构可以由用户的Lisp程序公开和操作。
唯一的例外是重新显示。很长一段时间，重新显示是一个替代世界。编辑器将进入重新显示的世界，并且会继续使用非常特殊的数据结构，这些数据结构对于垃圾收集是不安全的，不会安全中断，并且在此期间您无法运行任何Lisp程序。我们已经改变了 - 因为现在可以在重新显示期间运行Lisp代码。这是一件非常方便的事情。
第二个Emacs计划是现代意义上的“自由软件” - 它是使软件免费的明确政治运动的一部分。这次活动的实质是每个人都应该自由地做我们过去在麻省理工学院做的事情，共同开发软件并与想与我们合作的任何人一起工作。这是自由软件运动的基础 - 我拥有的经验，我在麻省理工学院人工智能实验室的生活 - 致力于人类知识，而不是阻碍任何人进一步使用和进一步传播人类知识。
当时，您可以制作一台与其他不适合Lisp的计算机价格相同的计算机，除了它可以比它们更快地运行Lisp，并且在每个操作中都进行全类型检查。普通计算机通常迫使您在执行速度和良好的类型检查之间做出选择。所以，是的，你可以拥有一个Lisp编译器并快速运行你的程序，但是当他们试图获取car一个数字时，它会得到无意义的结果并最终在某些时候崩溃。
Lisp机器能够以与其他机器一样快的速度执行指令，但是每条指令 - 汽车指令都会进行数据类型检查 - 所以当你试图在编译的程序中得到一个数字的汽车时，它会立即给你一个错误。我们构建了机器，并为它配备了Lisp操作系统。它几乎完全是用Lisp编写的，唯一的例外是在微码中编写的部分。人们开始对制造它们感兴趣，这意味着他们应该创办公司。
关于这家公司应该是什么样的，有两种不同的想法。格林布莱特希望开始他所谓的“黑客”公司。这意味着它将成为一家由黑客运营的公司，并以有利于黑客的方式运营。另一个目标是维持AI Lab文化（3）。不幸的是，Greenblatt没有任何商业经验，所以Lisp机器组的其他人说他们怀疑自己能否成功。他们认为他避免外来投资的计划是行不通的。
他为什么要避免外来投资？因为当一家公司有外部投资者时，他们会接受控制，他们不会让你有任何顾忌。最后，如果你有任何顾忌，他们也会取代你作为经理。
所以Greenblatt认为他会找到一个会提前支付购买零件的顾客。他们会建造机器并交付它们; 通过这些零件的利润，他们将能够为更多的机器购买零件，销售这些零件，然后为更多的机器购买零件，等等。小组中的其他人认为这不可行。
然后Greenblatt招募了聘请我的Russell Noftsker，后来他离开了AI Lab并创建了一家成功的公司。据信拉塞尔有商业天赋。他通过对群体中的其他人说：“让我们放弃格林布拉特，忘记他的想法，我们将成为另一家公司。”他展示了这种商业天赋。在后面刺伤，显然是一个真正的商人。那些人决定他们组建一家名为Symbolics的公司。他们会得到外部投资，没有顾忌，并尽一切可能获胜。
但格林布拉特没有放弃。无论如何，他和忠于他的少数人决定启动Lisp Machines Inc.并继续他们的计划。你知道什么，他们成功了！他们得到了第一个客户，并提前付款。他们建造机器并出售它们，并建造了更多的机器和更多的机器。尽管他们没有得到团队中大多数人的帮助，但他们确实取得了成功。Symbolics也取得了成功的开始，所以你有两个竞争的Lisp机器公司。当Symbolics看到LMI不会掉在脸上时，他们开始寻找破坏它的方法。
因此，放弃我们的实验室之后在我们的实验室中进行了“战争”。除了我和少数在LMI兼职工作的人之外，当Symbolics雇佣了所有的黑客时，遗弃了。然后他们引用了一条规则并且淘汰了为麻省理工学院做兼职工作的人，所以他们不得不完全离开，只剩下我。人工智能实验室现在无能为力。麻省理工学院与这两家公司做了非常愚蠢的安排。这是一份三方合同，两家公司都许可使用Lisp机器系统源。这些公司被要求让麻省理工学院使用他们的变化。但它没有在合同中说MIT有权将它们放入两家公司获得许可的MIT Lisp机器系统中。没有人设想AI实验室的黑客组织会被彻底消灭，但确实如此。
因此，Symbolics提出了一个计划（4）。他们对实验室说：“我们将继续对可供您使用的系统进行更改，但您无法将其置于MIT Lisp机器系统中。相反，我们将允许您访问Symbolics的Lisp机器系统，您可以运行它，但这就是您所能做的一切。“
实际上，这意味着他们要求我们必须选择一个侧面，并使用MIT版本的系统或Symbolics版本。无论我们做出哪种选择，都决定了我们改进的系统。如果我们研究并改进了Symbolics版本，我们就会单独支持Symbolics。如果我们使用并改进了MIT版本的系统，我们将为两家公司提供工作，但是Symbolics认为我们将支持LMI，因为我们将帮助它们继续存在。所以我们不再被允许保持中立。
直到那时，我还没有站在任何一家公司的一边，尽管让我很难看到我们的社区和软件发生了什么。但现在，Symbolics迫使这个问题。因此，为了帮助保持Lisp Machines Inc.（5） - 我开始复制Symbolics对Lisp机器系统所做的所有改进。我自己再次写了相同的改进（即代码是我自己的）。
过了一会儿（6），我得出结论，如果我甚至不看他们的代码那将是最好的。当他们发布了发布说明的beta版时，我会看到这些功能是什么然后实现它们。当他们真正发布时，我也做了。
通过这种方式，两年来，我阻止他们消灭Lisp Machines Incorporated，两家公司继续进行。但是，我不想花费数年和数年来惩罚某人，只是挫败了一个邪恶的行为。我认为他们受到了相当彻底的惩罚，因为他们被那些没有离开或将要消失的竞争所困扰（7）。与此同时，现在是时候开始建立一个新社区来取代他们的行动和其他人已经消灭的社区。
70年代的Lisp社区不仅限于麻省理工学院人工智能实验室，而且黑客并非都在麻省理工学院。Symbolics开始的战争是麻省理工学院的战争，但当时还有其他事件正在发生。有人放弃了合作，共同消灭了社区，没有多少人离开。
一旦我停止惩罚Symbolics，我必须弄清楚下一步该做什么。我必须制作一个免费的操作系统，这很清楚 - 人们可以一起工作和共享的唯一方法是使用免费的操作系统。
起初，我想过制作一个基于Lisp的系统，但我意识到这在技术上不是一个好主意。要拥有像Lisp机器系统这样的东西，你需要特殊用途的微码。这使得以其他计算机运行程序的速度运行程序成为可能，并且仍然可以获得类型检查的好处。没有它，你将被简化为类似其他机器的Lisp编译器。程序会更快，但不稳定。如果你在分时系统上运行一个程序就好了 - 如果一个程序崩溃，那不是灾难，这是你的程序偶尔会做的事情。但这并不能很好地编写操作系统，所以我拒绝了制作像Lisp机器这样的系统的想法。
我决定改造一个类似Unix的操作系统，让Lisp实现作为用户程序运行。内核不会用Lisp编写，但我们有Lisp。因此，操作系统GNU操作系统的开发使我编写了GNU Emacs。在这样做的过程中，我的目标是实现绝对最小化的Lisp实现。节目的规模是一个巨大的问题。
那些日子里，1985年有人拥有一台没有虚拟内存的1兆字节机器。他们希望能够使用GNU Emacs。这意味着我必须保持程序尽可能小。
例如，当时唯一的循环结构是'while'，这非常简单。没有办法打破'while'语句，你只需要执行catch和throw，或者测试运行循环的变量。这表明我在努力保持小事做多远。我们没有'caar'和'cadr'等等; “挤出一切可能”是从一开始就是Emacs Lisp精神的GNU Emacs的精神。
显然，机器现在变大了，我们不再这样做了。我们放入'caar'和'cadr'等等，我们可能会在其中一天进行另一个循环构造。我们现在愿意扩展它，但我们不想将它扩展到常见的Lisp级别。我在Lisp机器上实现了一次Common Lisp，我对此并不满意。我不太喜欢的一件事是关键字参数（8）。他们对我来说似乎不太好看; 我有时候会这样做，但是当我这样做时，我会尽量减少。
这不是与Lisp有关的GNU项目的结束。后来在1995年左右，我们开始考虑启动一个图形桌面项目。很明显，对于桌面上的程序，我们希望编程语言能够编写大量内容以使其易于扩展，就像编辑器一样。问题是应该是什么。
当时，为了这个目的，TCL正在被大力推动。我对TCL的看法很低，主要是因为它不是Lisp。它看起来有点像Lisp，但在语义上它不是，而且它不那么干净。然后有人向我展示了一则广告，其中Sun试图聘请某人在TCL工作，使其成为世界“事实上的标准扩展语言”。我想，“我们必须阻止这种情况发生。”因此我们开始将Scheme作为GNU的标准可扩展性语言。不是Common Lisp，因为它太大了。我们的想法是，我们将有一个Scheme解释器，设计为以与TCL链接到应用程序相同的方式链接到应用程序中。然后我们建议将其作为所有GNU程序的首选可扩展性包。
使用像Lisp这样强大的语言作为主要的可扩展性语言，可以获得一个有趣的好处。您可以通过将其翻译成主要语言来实现其他语言。如果您的主要语言是TCL，则无法通过将其翻译成TCL来轻松实现它。但是如果你的主要语言是Lisp，那么通过翻译来实现其他东西并不困难。我们的想法是，如果每个可扩展的应用程序都支持Scheme，您可以在Scheme中编写TCL或Python或Perl的实现，将该程序转换为Scheme。然后，您可以将其加载到任何应用程序中，并使用您喜欢的语言进行自定义，它也可以与其他自定义项一起使用。
只要可扩展性语言很弱，用户就必须只使用您提供的语言。这意味着喜欢任何特定语言的人必须竞争应用程序开发人员的选择 - 说“请，应用程序开发人员，将我的语言放入您的应用程序，而不是他的语言。”然后用户根本没有选择 - 无论哪个他们正在使用的应用程序带有一种语言，并且它们被[该语言]所困扰。但是，如果你有一种强大的语言可以通过翻译来实现其他语言，那么你就可以让用户选择语言了，我们不再需要语言大战了。这就是我们希望'Guile'，我们的计划翻译，会做的。我们去年夏天有一个人在完成从Python到Scheme的翻译工作。我不知道是不是' 已完全完成，但对于对此项目感兴趣的任何人，请与我们联系。这就是我们未来的计划。
我没有谈过自由软件，但让我简要地告诉你一些关于这意味着什么的信息。自由软件不涉及价格; 这并不意味着你是免费获得的。（您可能已经支付了一份副本，或者免费获得了一份副本。）这意味着您拥有作为用户的自由。关键是你可以自由运行程序，自由学习它的功能，可以随意改变它以满足你的需求，可以自由地重新发布其他人的副本并免费发布改进的扩展版本。这就是自由软件的含义。如果你使用非免费程序，你就失去了至关重要的自由，所以不要这样做。
GNU项目的目的是通过提供免费软件来取代它，使人们更容易拒绝自由践踏，用户主导，非自由软件。对于那些没有道德勇气拒绝非自由软件的人来说，当这意味着一些实际的不便时，我们试图做的是提供一个免费的替代方案，这样你就可以在没有混乱的情况下转向自由。实际上的牺牲。牺牲越少越好。我们希望让您更轻松地生活在自由，合作中。
这是合作自由的问题。我们习惯于思考自由和与社会的合作，好像他们是对立的。但在这里他们是在同一边。使用免费软件，您可以自由地与其他人合作，也可以自由地帮助自己。使用非自由软件，有人会主宰你并让人们分裂。你不能与他们分享，你不能自由地合作或帮助社会，而不是你可以自由地帮助自己。分裂和无助的是使用非自由软件的用户状态。
我们已经制作了大量的免费软件。我们做过人们说我们永远做不到的事情; 我们有两个免费软件操作系统。我们有很多应用程序，显然我们还有很长的路要走。所以我们需要你的帮助。我想请你自愿参加GNU项目; 帮助我们开发更多工作的免费软件。看看 http://www.gnu.org/help 找到如何提供帮助的建议。如果您想订购商品，可以在主页上找到相关链接。如果你想阅读哲学问题，请查看/哲学。如果您正在寻找可以使用的免费软件，请查看/directory，其中列出了大约1900个软件包（这是所有免费软件的一小部分）。请写更多信息并为我们做出贡献。我的论文“自由软件和自由社会”正在出售，可以在www.gnu.org上购买。快乐的黑客！
--------------------------------------------------------------------------------
via: https://www.gnu.org/gnu/rms-lisp.html
作者：[Richard Stallman][a]
选题：[lujun9972](https://github.com/lujun9972)
译者：[geekmar](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://www.gnu.org
[1]:https://www.gnu.org/help/
[2]:http://www.gnu.org/