Subject: Re: Apps in Lisp (was: Re: help! absolute beginner) From: Erik Naggum <erik@naggum.no> Date: 1998/12/15 Newsgroups: comp.lang.lisp Message-ID: <3122753560354984@naggum.no> * Raymond Toy <toy@rtp.ericsson.se> | 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 language. | 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. #:Erik -- man who cooks while hacking eats food that has died twice.