diary at Telent Netowrks

(proclaim '(inline skates))#

Fri, 24 Feb 2006 00:45:59 +0000

(proclaim '(inline skates))

Not my joke (Marty Hall's old .signature, iirc) but somehow appropriate. If you want to read about the skating it's in my other blog which this is not the place to plug. (But oh well, what the hell. It's at coruskate.blogspot.com and lately it's mostly about my ankles.)

I have been making sort of halfhearted efforts to get some Lisp done lately, but they been mired by the compound effects of having forgot a fair amount of stuff, not really having quite enough time to get it all back in short-term memory, and indecisiveness. So here's a slightly handwavey question which may inspire debate, motivated by my recent $dayjob experiences hacking Perl.

One of the advantages of Lisp (and of rapid prototyping generally), it's often said, is about the ability to defer decisions (like "what is the best machine representation for this variable?") until they become important - which quite often is not at all. Which is true.

But here I am trying to design some CLOS stuff and finding that I don't want to start writing any code at all until I know exactly what it'll look like. And I certainly don't have the same trouble in Perl (it's fair to say, I think, that I've used the two languages about equally much, though I daresay my CL is a little rustier right now). What's the difference? I'm not sure, but I think it's naming. Or, perhaps, namespacing. It seems more difficult than it needs to be to defer decisions about naming things, because the scope of a name is a package - which is conventionally quite big - whereas the whatever-it-is that name refers to may actually be quite small. Say, a method on an object somewhere: whereas in Perl I can define a method to be called as $book->bind without needing to worry about whether I will later want $hand->bind; $foot->bind and if so, is it conceptually the same thing (so should be the same GF and requires the same argument list) or is it something else entirely (in which case it will need naming differently). In CL I am having to anticipate the likely future direction of the system to make decisions that in another language I could make with reference only to what I currently know. XP devotees will tell you that's wrong, and I'd tend to agree.

I should note, before I get a pile of mail telling me I've missed the point, that I know the goal is protocol-based design. I think that's a good thing. I just wish the language made it a little easier to do useful work in the early days before it's obvious what the protocols are going to be. I don't mind a language that makes me think - I just don't like it when I have to have thought before I even start to write code. How is that supposed to fit with "rapid prototyping"?

(There is a style of CLOS programming that never hits these problems, because everything gets named with a classname- prefix. I don't think it's a win. Tim Moore wrote a very good article about that in The Magazine^WWeb Site That Used To Have A Silly Name.)

The new version of trivial-sockets is almost exactly like the previous#

Tue, 28 Feb 2006 21:26:18 +0000

The new version of trivial-sockets is almost exactly like the previous one. In fact the only differences are

I was going to do some more stuff to it: I looked at the patches on http://www.cliki.net/trivial-sockets?v=18 and found that one of them involves an API change and the other doesn't work (at least, ext:accept-tcp-connection doesn't work on udp sockets on my cmucl installation, and I don't expect it would generally). So, as this is all a distraction from what I'm actually supposed to be doing anyway, I put them aside for another time.

The package will appear on cclan nodes as soon as I remember how to do that packaging thang.

I am the world's biggest plist fan#

Tue, 28 Feb 2006 22:12:29 +0000

I am the world's biggest plist fan. Possibly. Anyway, as part of the same tidying up process that led to the release of trivial-sockets 0.3, also new to the world but not to me is net-telent-date 0.42, which has the additional function decode-universal-time/plist. Just because I can't always remember the order of the values in a decoded universal-time (and sometimes you just want the month and year anyway).

(let ((dt (net.telent.date:decode-universal-time/plist (get-universal-time))))
  (format nil "~2,'0D:~2,'0D:~2,'0D ~D/~D/~D"
	  (ref dt :hour) (ref dt :minute) (ref dt :second)
	  (ref dt :year) (ref dt :month) (ref dt :day)))
=> "22:19:16 2006/2/28"
[ Please see also my previous apology for the name of this package ]