DrewAdams

Cette page est aussi disponible en franglais ;-): Français:DrewAdamsFrançais

EMACS

“Many of the subsequent enhancements were done simply because something occurred to me that I could easily do or someone suggested something, and it seemed like a cool idea. Our mindset was that cool ideas were fun to pursue, even if we couldn’t think of a practical use or need right away.” – DanMurphy, inventor of TECO, The Beginnings of TECO, 2009-10-31
The “spirit of building up gigantic, complicated programs to use in your own editing, and then exchanging them with other people” – RichardStallman, Lisp conf speech, 2002-10-28 (taken slightly out of context).

See EmacsHistory for info on the various Emacs incarnations mentioned here, and [1] for the Emacs family tree.

Where's the Glue?

EMACS exists because I felt free to make individually useful small improvements on a path whose end was not in sight. – RMS, EMACS: The Extensible, Customizable Display Editor, http://www.gnu.org/software/emacs/emacs-paper.html

That’s not a bad summary of what free/open software development is all about, IMO:

  • freedom to modify (source)
  • individually useful changes
  • small changes
  • on a path, but one without a clear destination

The fact that useful software changes can be individually useful and small, without being part of an overall predefined design, is maybe not an explicit tenet of the philosophy of free software development, but it is in fact a precondition and a consequence of such development. The idea that individually useful changes are likely to lead to something that is useful in the aggregate is important – and not obvious, in terms of modularity and group design & development.

This free/open software development model (combine individually useful changes, without necessarily adhering to a predefined design) reminds me of the Unix philosophy (vs what came before it) of producing small, modular programs that can easily be combined to produce more powerful functionality (vs monolithic, swiss-army-knife, do-all systems/functions). Here’s the question:

What makes Unix (or GNU/Linux) so modular – so propitious to the combination of small programs?
  • character streams as both input and output (what one program outputs, another can input)
  • pipes (glue programs together: outputs to inputs)

The same question, applied to functional programming:

What makes (pure, lazy, higher-order) functional programming so modular – so propitious to the combination of small programs?
  • higher-order functions (glue simple functions together to make complex functions)
  • lazy evaluation (glue whole programs together: outputs to inputs)

IOW, it’s about modularity, and modularity is all about glue: the ability to combine pieces.

For a fabulous essay on the modularity and “glue” of functional programming, see John Hughes’s classic, Why Functional Programming Matters: http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf or http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html From the Introduction (emphasis added):

The special characteristics and advantages of functional programming are often summed up more or less as follows. Functional programs contain no assignment statements, so variables, once given a value, never change. More generally, functional programs contain no side-effects at all. A function call can have no effect other than to compute its result. This eliminates a major source of bugs, and also makes the order of execution irrelevant – since no side-effect can change the value of an expression, it can be evaluated at any time. This relieves the programmer of the burden of prescribing the flow of control. Since expressions can be evaluated at any time, one can freely replace variables by their values and vice versa – that is, programs are “referentially transparent”. This freedom helps make functional programs more tractable mathematically than their conventional counterparts.
Such a catalogue of “advantages” is all very well, but one must not be surprised if outsiders don’t take it too seriously. It says a lot about what functional programming is not (it has no assignment, no side effects, no flow of control) but not much about what it is. The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous. To those more interested in material benefits, these “advantages” are not very convincing.
Functional programmers argue that there are great material benefits – that a functional programmer is an order of magnitude more productive than his conventional counterpart, because functional programs are an order of magnitude shorter. Yet why should this be? The only faintly plausible reason one can suggest on the basis of these “advantages” is that conventional programs consist of 90% assignment statements, and in functional programs these can be omitted! This is plainly ridiculous. If omitting assignment statements brought such enormous benefits then FORTRAN programmers would have been doing it for twenty years. It is a logical impossibility to make a language more powerful by omitting features, no matter how bad they may be.
Even a functional programmer should be dissatisfied with these so-called advantages, because they give him no help in exploiting the power of functional languages. One cannot write a program which is particularly lacking in assignment statements, or particularly referentially transparent. There is no yardstick of program quality here, and therefore no ideal to aim at.
Clearly this characterisation of functional programming is inadequate. We must find something to put in its place – something which not only explains the power of functional programming, but also gives a clear indication of what the functional programmer should strive towards.

An analogy is then drawn with the “no GOTO!” arguments in favor of structured programming – and the conclusion is that it is its modularity, not its lack of GOTO, that gives structured programming its advantage. The rest of the paper explores the modularity advantages provided by higher-order functions and lazy evaluation.

I heartily recommend this 40-year old paper. I guarantee that it is an eye-opener, no matter how familiar you are with functional programming and programming-language design.

Here, BTW, is what John himself says about this paper:

This paper shows how two key features of functional languages—higher-order functions (which take other functions as arguments) and lazy evaluation (which defers computations until their results are really needed)—combine to let programmers break algorithms into small, flexible, reusable parts. It argues that functional languages support the development of reusable software much better than conventional languages, in other words.

At the time I wrote it, researchers were more likely to emphasize mathematical reasoning and the absence of side-effects—but it’s difficult to sell a programming paradigm on the things it lacks! The perspective in my paper has influenced many researchers since, and can perhaps be said to lie partly behind a focus in recent years on “domain specific embedded languages”. These are flexible libraries of functions that permit programmers to solve problems of a certain class just by combining library functions, in effect working in a special purpose programming language for that particular kind of task.

I wrote the paper in 1984 as a post-doc, but misjudged its significance completely. I thought it would be unpublishable, because it contained no difficult research results, just a manifesto and some nice programming examples. So I circulated it privately to friends, who passed it on to others, and soon I found it turning up in the most unexpected places. Finally, after five years, I was invited to submit it to the Computer Journal. —http://www.cse.chalmers.se/~rjmh/citations/my_most_influential_papers.htm

Coming back to free/open software development – By analogy, what is the “glue” that makes this kind of development work? What makes it possible to glue many small, individually useful software changes together and still get something worthwhile accomplished? How does this work, even in the absence (some might argue especially in the absence) of a predefined design? That’s a question for reflection. Some may hark back to Adam Smith for an answer; others, to Mikhail Bakunin; still others, to Karl Marx. I’d say that the question is open, but these are at least part of the “glue” answer:

  • open source code (your output is my input)
  • Internet communication (pipes, if you will)

 

I Use Emacs

… though sometimes I think Emacs uses me. In fact, Emacs and I have used each other since the mid 1980s.

First, I used Gosling Emacs (we just called it Emacs), with Mock Lisp. Mock Lisp was fun – er, a mess. No real lists at all. No real arguments to functions – just error-prone global-variable pseudo-arguments. In fact, about the only thing it had in common with Lisp was the parentheses. Fun, though.

But Gosling Emacs was Emacs, in any case: an extendable text editor that you could do what you want with. It impressed me quite a lot, after years (don’t ask!) programming with other editors of various sorts (I said, don’t ask!). I was impressed with its programmability – on the fly, no less (interpreted language). I was particularly impressed with TAGS – hit a key on a name in a program somewhere and shazzam!…takes you to the defining source code. Magic. Cool. Handy.

The other remarkable thing I noticed about Emacs was that it was self documenting. Long before objects began orienting themselves with an eye to fashion, Emacs objects spoke to you about themselves. And, though Emacs’s hyperlinked Info manuals might seem, well, ordinary now, next to the Web, at that time there was no Web, and online hyperlinked documentation didn’t even exist – except for Emacs Info. Cool it was.

Anyway… From Gosling Emacs we moved to GNU Emacs, with EmacsLisp, when it came along. We also used Zmacs, on Symbolics Lisp machines. I programmed mostly in Lisp then anyway (Franz and Common), so these Emacs versions were great to have.

Over the years, I’ve customized the hell out of Emacs. At first it was just new commands, functions, and key bindings, but when Epoch (French Wikipedia page) came out (with proportional fonts, colored faces, frames, images, menus, and such) there was suddenly a lot more you could do to make Emacs (Epoch) fit your individual needs or dreams. The combination of these new, powerful features with the somewhat limited out-of-the-box user interface positively ignited user customization, and I was no exception.

The downside of doing a lot of customization is having to redo it when a new Emacs version comes out and lots of basic stuff has changed so that things are incompatible. I’ve been there & done that way too many times. The last couple of major releases, I’ve ended up abandoning useful stuff I wrote just because I didn’t have the time to upgrade it. That’s OK; some of it deserved to be left behind.

And Emacs has improved greatly over the years. I still use Emacs 20, as well as later versions through the latest development builds. When feasible and not too much trouble, I try to make my EmacsLisp code compatible across versions.

 

My Emacs Lisp Stuff

My EmacsWiki Elisp Libraries:

This page describes my EmacsLisp libraries: DrewsElispLibraries.

NOTE: You can be pretty sure that my libraries are untampered with, because their wiki pages are locked except to EmacsWiki administrators.

Recent Developments

One place to start:

Icicles – Explore, explore, explore…

Another place to start:

OneOnOneEmacs – Frames, yes! Emacs windows, no! Try it. Pages linked from OneOnOneEmacs:

Some other EmacsWiki pages to look at:

Screen Shots

Here are some screenshots of my Emacs.

 

My Contributions to EmacsWiki, Chronologically

Emacs Wiki Index and Statistics

CategoryHomepage