Re: Emacs Survey: Toolbars

[Jeremy Bryant <jb@jeremybryant.net>]

In the spirit of this discussion on the merits and possibility of
planning (or not), there is an interesting quote below.
I found it useful for thinking about the special characteristics of
Emacs, and perhaps others on this list will find it interesting to
consider.




attributed (in the Free as in Freedom book)to RMS from a 1979 AI Lab memo


 EMACS could not have been reached by a process of careful design, because such
 processes arrive only at goals which are visible at the outset, and whose
 desirability is established on the bottom line at the outset. Neither I nor
 anyone else visualized an extensible editor until I had made one, nor
 appreciated its value until he had experienced it. EMACS exists because I felt
 free to make individually useful small improvements on a path whose end was not
 in sight.






Although I couldn't locate the original source of exact quote, there is a longer piece
from the 1979 memo from RMS on the same subject.




Implications for the Process of System Design 

It is generally accepted that when a program is to be written, specifications 
should be designed in advance. If this is not done, the result will be inferior. 
Some people know better than this, but none dare to speak up. 

The writing of EMACS was as far from along these lines as can be imagined. It 
is best thought of as a continuous deformation of TECO into something which, 
for users, has no resemblance to TECO. 

And indeed, there are ways in which EMACS shows the results of not having 
been completely thought out in advance, if only in being based on TECO rather 
than Lisp. (Nevertheless, EMACS has shown itself to be reliable and suitable for 
widespread use). If EMACS hadTbeen specified in advance, it would resemble 
the post-EMACS editors described above. However, the post-EMACS editors 
were specified in advance by EMACS itself, and could not have been written if 
not preceded by EMACS (this is not to say that they have copied slavishly; they 
have continued the process of gradual development). And EMACS could never 
have' been arrived at except in the way it actually was. The chain of necessary 
steps leading to EMACS, starting with the display processor, was simply too long 
for anyone to have imagined the final result before the first step had been taken. 
If we had insisted on moving only toward destinations visible at the beginning, 
we would never have got here from there! 

This is true of all the details of the individual commands as well as of the 
structure of the system. Each command in EMACS behaves as it does as a 
result of experimentation by many different users customizing their editors in 



£ MACS June 22, 1979 



21 



MIT Al Lab 



different ways, in the years when the display processor existed but EMACS had 
not yet been begun. This experimentation was possible only because a 
programmable display editor existed. It would not have been possible to design 
the EMACS standard command set without it. 

Nor can one maintain the position that it was right to create EMACS this way 
because it was research, but ordinary system development is a different matter. 
This is because the difference between the two is also a matter of hindsight. 
EMACS was not the result of an intentional "editor research project" (nor would 
such a project have arrived at EMACS, because research projects aim only at 
goals which are visible at the start). The display processor and command 
dispatcher were seen only as an improvement to TECO; no one could have 
known, when any step was taken, how much farther the path would lead. One 
cannot even identify a "first" step, because the development, until the writing of 
EMACS per se, blends smoothly back into the development' of TECO. 

But why isn't such program of exploration doomed to be sidetracked by a blind 
alley, which nobody will realize due to the lack of a planned goal? 'it is the 
extensibility, and a flexibility of mind, which solves this problem: many alleys 
will be tried at once, and blind alleys can be backed out of with minimal real 
loss. 




Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Date: Mon, 21 Dec 2020 00:47:18 -0500
>> Cc: abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
>> 
>>   > I wonder whether the survey stems from lack of vision of emacs
>>   > admin and developers.  For instance, Gcc has a Development Plan.
>>   > Suggestions for changes to the plan are discussed on the Gcc
>>   > mailing list and can be approved or rejected by the Gcc Steering
>>   > Committee. How about Emacs?
>> 
>> GCC has many developers who are paid by various companies.
>> That makes it easier to make plans and actually carry them out.
>
> There's another important difference.  GCC implements programming
> languages defined by evolving standards that are developed by other
> bodies.  The evolution of those language standards largely defines the
> GCC development plans.  Other project, like GDB, Binutils, etc. have
> similar traits: they support hardware and software standards developed
> elsewhere.
>
> But Emacs is its own standard, defined by what we put into it, it
> depends very little on outside developments, and is only tangentially
> affected by those external developments.  So those developments cannot
> determine our plans anywhere near to how the next C++ Standard affects
> GCC development, or the next DWARF2 version and various
> debugging-related features in the next generation of CPUs affect GDB
> development.