Subject: Re: Apps in Lisp (was: Re: help! absolute beginner)
From: Erik Naggum <>
Date: 1998/12/15
Newsgroups: comp.lang.lisp
Message-ID: <>

* Raymond Toy <>
| Can someone remind my why gzip, tar, MPEG, MP3 need to be in lisp?

  the key is "mind share".  when you have deal with a number of things in
  some clearly inferior language, such as C, you lose in a big way.  for
  instance, I'm currently struggling with MD5 checksums.  there's a C
  function I can call with a block of data, but the interface is all wrong
  and very hard to use from a Lisp point of view.  MD5 was obviously¹
  designed in assembly language on an Intel processor, and I thik it would
  make sense to publish that code instead of the god-awful C code they did
  publish.  however, the MD5 algorithm itself, which works only on 512-bit
  blocks of data, doesn't need a support apparatus in C.  but because it
  was written in C, the support apparatus was also written in C.  _that's_
  what's wrong.  I can certainly live with a low-level algorithm in C or
  assembly or whatever, but I can't use it today because the interface was
  designed to be usable from C, not designed to be usable from any

| I can see why graphics and translation would be useful in lisp, but
| what's wrong with just running the external utilities for gzip, tar,
| etc.?

  that they are external (in the Unix process sense).

| Forgive me for being slow, but what does it mean to put all of these in
| lisp?

  leveraging the implementation experience so no new protocol needs to be
  written in C just because it uses stuff that has already been implemented
  in C.

  I'm all for using black boxes through foreign function interfaces, but
  when I actually need to do something that the people who thought in the
  inferior language couldn't think of, I have to do it my own way.  e.g.,
  there's a great domain name resolver out there, but, not surprisingly, it
  is written in C and has this stupid interface which you can't just give a
  list of requests to process in parallel, which really is quite easy given
  the protocol design, and return once it's done.  it's _too_ low-level,
  and it was written in the days of non-threading code that only needed to
  look up individual domain names at a time.  another simple example is the
  `ident' protocol, which is trivial, but which is also implemented in a
  stupid locking fashion.  I ended up writing an implementation for it in
  Allegro CL where I send the stream (socket) to a separate Lisp process as
  a run-reason, and it does its work and fills in a slot in the subclass of
  stream that keeps this information in a way that suspends the process if
  it requests the slot-value of this slot until it is known, which means
  the caller can predict whether it will block or not, and doesn't have to
  time out waiting for a machine that won't answer before it can service
  the request.  all very stream-lined, and not something you would have
  thought of in C in the first place.

  so, in brief, the differences in philosophy between Lisp and C make it
  quite important to have a Lisp handle on things.  sometimes, C is enough
  and the function is simple enough, but not very often, in my experience.

  man who cooks while hacking eats food that has died twice.