October 27th, 2006

this week in comp.lang.lisp

Don't believe the haters. It's still fun to read comp.lang.lisp! This week had some nice articles.

  • Paolo Amoroso pointed out a great resource in <877iyp350t.fsf@plato.moon.paoloamoroso.it>:
    For MOP nirvana and enlightenment, see:
      Open Implementations and Metaobject Protocols
      by Gregor Kiczales and Andreas Paepcke
    If I had to pick a subtitle, I would say "MOPs demystified".  Print
    the document and read it on your favorite chair in a quiet room.

    From the "Introduction" section of the referenced PDF:

    The work presented in this book is based on the observation that much of the complexity in current application programs comes from the application programmer having to 'code around' deficiencies in the underlying operating system, programming language, object system or other substrate software. This happens when the application programmer would like a specific feature or behavior that the substrate does not provide.

    But this book does not propose that substrate software should just "have more features to please more programmers." Instead, it suggests that substrates should be open in a way that allows programmers access to and control over the substrate's implementation in a way that allows the programmer to tailor the substrate to the needs of a particular application. This is called open implementation.

    Looks good.

  • Much of the time on comp.lang.lisp, novices react to criticism with defensiveness and hostility, and treat any questioning of their behavior as a personal attack. That's why it was refreshing to see <1161788613.364200.98730@e3g2000cwe.googlegroups.com>:
    > I saw your explanation to other noobs. Made no sense to me. Instead of
    > searching for a pithy way of synopsizing what is going, it actually
    > would be easier simply to learn what is going on. In full. The shortcut
    > thinking of your synopsis is too lossy, and macro-writing requires
    > precise understanding of what is going on.
    You remind me of my early experiences learning French. It was often the
    case that students who thought they were speaking French could easily
    understand eachother while the francophones around them found them
    difficult to understand. This was caused by the students having access
    to English grammar and phonetics when interpreting the "French"
    utterances. For example, beginners have no trouble with, "le brun
    chaisses" even though the gender of the article is wrong, the adjective
    is in the wrong place, and so on.
    All that to say, I'm sorry that it seems I still have not entirely
    figured out defmacro's treatment of arguments. I thought I had, and I
    thought I was putting it in terms other newbies could understand.
    Thanks for pointing out that I'm still missing something.

  • Robert Strandh gave the best summary I've yet seen of CLIM in <6wodrywdsw.fsf@serveur5.labri.fr>:
    CLIM has a "command loop" that is at a higher level than an event loop
    and that:
      * acquires a command.  You might satisfy this demand by clicking on
        a menu item, by typing the name of a command, by hitting some kind
        of keystroke, by pressing a button, or by pressing some visible
        object with a command associated with it ;
      * acquires the arguments required by that command.  These arguments
        are often associated with a "presentation type", and visible
        objects of the right presentation type can be clicked on to
        satisfy this demand.  You can also type a textual representation
        of the argument, using completion, or you can use a context menu ;
      * calls the command on its arguments, usually resulting in some
        significant modification of the "model", i.e. the data structure
        representing your application logic ;
      * calls a redisplay routine (which might use incremental redisplay)
        to update your views of the model.
    Writing a CLIM application therefore consists of:
      * writing CLIM commands that modify the model independently of how
        those commands are invoked, and which may take application objects
        as arguments ;
      * writing display routines that turns the model (and possibly some
        "view" object) into a collection of visible representations
        (having presentation types) of application objects ;
      * writing completion routines that allows you to type in application
        objects (of a certain presentation type) using completions ;
      * independently deciding how commands are to be invoked (menus,
        buttons, presentations, textual commands, etc). 
    By using CLIM as a mediator of command invocation and argument
    acquisition, you can obtain some very modular code indeed. 

Keep digging for the ponies!



If you're reading this in some other place than Planet Lisp, go take a peek at Planet Lisp.

For each blog to which Planet Lisp subscribes, I made a little graph showing how frequently that blog has had its posts in Planet Lisp. It appears in the right-hand sidebar of the page. There are twenty-six bars, and each bar represents two weeks, so the graph goes back a year. Each vertical pixel represents one post, except when there are zero posts (I still write out one pixel of the bar, in a lighter gray) and when there are more than 16 posts (I write out 16 pixels, with a red strip across the top). Here are a few examples:

  • Zach Beane
  • Gary King
  • Paul Dietz

(Come back, Paul!)

The idea is from Tufte, and the choice of bars is from sparkline.org. The code is, of course, written in pure Lisp and uses skippy to write out GIF files.

It's a little embarrassing to have so many flatliners, so I may use this info to prune some feeds in the near future.