I did a little bit of work with GNUstep to try to figure out the real differences between it and Cocoa. So far I haven't run into anything that couldn't be conditionally compiled. I know the last time I tried it on OS X (admittedly, from PB) it didn't like ifdefs for portability (such as switching between IBOutlet and id), but I'm sure that's something people would have complained about enough for them to fix.
My best friend so far has been Google (go figure). So far I haven't run into anything that couldn't be solved with Google, but then I haven't played with NSDistantObject yet.
I just compiled CLisp 2.30 and everything went just fine. I didn't compile libsigsegv to go with it, largely because I have traditionally had problems building it on PPC boxes. Besides, if I run into segfaults, I know I'm doing something wrong -- most of the time, at least.
I did a search for "Lisp DNS" and it turned up a couple of reasonable hits, but not enough to stop me from thinking about coding up a DNS server of my own. If I do any work in Common Lisp, it will likely target CLisp in the areas where it has to, as I don't know of another CLtL1+ Lisp that bootstraps from C. (Unless SBCL does now?)
Got some more work done on the Perl sample code for the possible job. They wanted to see a couple of examples, but I'm going to hand in about half a dozen small-to-medium files. I've purposely chosen things that are easy to test and the behaviours of which are well-known, but that does make it difficult to keep on task sometimes.
Fortunately, I don't have to send it in until early tomorrow morning, so I've got some time to play with it. I don't know whether to write more sample code or to write a test suite for what I've got already. The latter is probably better, so that's likely what I'll do next.
I've been quietly keeping up on the Parrot CVS tree, but I'm winding up with four test failures. It seems odd that Darwin would test clean, but Linux wouldn't. I'm pretty sure it's the GC that's messing things up (in this case, collecting something early, I'm pretty sure). I'll have a deeper look at it after I've got the sample code done.
Still no action on the Arc front. It's not that I doubt Paul Graham and company's ability to pull it off -- it's more that I doubt that it'll happen any time soon. If I had to put money on it, I would say it will likely become publically available in September 2003, though this is one time I'd love to be proven wrong.
I may still start work on an Arc-like language of my own, if for no other reason than to provide a loyal opposition on simple matters such as syntax. I definitely couldn't challenge Paul et al. in any significant way.
Pining, fjords, and all that
I've been through several "I'll hack up something like Arc/no I won't, 'cause I've got X" cycles, and it's only been recently that I've really figured out that I'm after. Or some approximation of that, at least.
What I'm after is a syntax-free (in the same way as Lisp) language that has a reasonable (as in not too big (Common Lisp) and not too small (Scheme)) standard library that includes sockets, as much interaction with the OS as the OS can support (system calls, environment, etc.), a decent garbage collector (even pure reference count would do -- I can break circular dependencies on my own), decent session scripting abilities, incremental compilation, a half-decent debugger and trace facilities, and can easily be built from sources (even if it takes an aeon).
My other big complaint with current implementations of Lisp and Scheme are the function and special form names. Don't get me wrong -- cons, car, cdr, let -- these are all great. call-with-current-continuation and concatenate are far too long, especially with how often the latter is used.
I have played around with a number of naming conventions, and I have to admit a preference towards an abbreviated version of the modern Scheme syntax -- call/cc is a good example, and substr/sh (instead of substring/shared) would be another good one. cat/sh is fine for a shared-string concatenation operation, with cat/cp as the copied string name would work, with plain old cat defaulting to one of the above.
I know that Lisp and Scheme evolved such long function and special form names under the assumption that LispMs and editors would automatically complete them. However, even with (G|X)Emacs, Jabberwocky and other projects out there that specialize in Lisp, we still don't have that.
Rather than trying to redefine computing to suit Common Lisp and friends (as much as I love most of them), I think it's more realistic to define a variant that works well with today's tools, rather than vice versa.