Writers of all stripes enjoy engaging in the most cynical readings of human behavior because they think it makes them appear hyper-rational. But in fact here is a perfect example of how trying to achieve that makes you irrational. Human emotion is real. It is an observable phenomenon. It observably influences behavior. Therefore to fail to account for it when discussing coupling and relationships is the opposite of cold rationality; it is in fact a failure of empiricism.

L’Hote on Kate Bolick’s “All the Single Ladies”.

As programmers, we spend a lot of time just carting data from one place to another. Sometimes that’s the entire purpose of a program or library (data conversion whatevers), but more often it’s just something that needs to happen in the course of getting a certain task done. When we’re sending a request, using a library, executing templates or whatever, it’s important to be 100% clear on the format of the data, which is a fancy way of saying how the data is encoded.

Let’s do the tacky dictionary thing:

encoding (plural encodings)

1. (computing) The way in which symbols are mapped onto bytes, e.g. in the rendering of a particular font, or in the mapping from keyboard input into visual text.

2. A conversion of plain text into a code or cypher form (for decoding by the recipient).

I think these senses are a bit too specific—if your data is in a computer in any form, then it’s already encoded. The keyboard doesn’t even have to come into it.

Read more

coworker: If it were a critical task, how long to get that UI up and running?
me: Probably about the same amount of time if it were non-critical, all things considered
me: Maybe a little longer
me: Stress tends to make tasks drag out

Reference.

An employee of the company who mantains Mongo, who appears to be assigned Erlang driver maintenance lately, seems to deduce that the tests fail¹, and so changes an API which has been stable for 2 years in order to “make the tests pass”, despite also changing the tests.

WAT.

1. they don’t. ↩

Practical Common LISP by Peter Seibel

My rating: 4 of 5 stars

Just what Common Lisp needed: a book that doesn’t bubble at the mouth, frothing over how every other language is attempting to be CL but failing; a book that doesn’t tell you how macros mean you can write EVERY LANGUAGE EVER in CL; a book that doesn’t tell you how CL’s macros are the best thing since sliced bread, then follow it up with totally shit examples of what macros are actually used for; a book that actually tours the standard library in a semi-sensical fashion, and covers practical things you might actually want to do, and in the meantime does a pretty decent justice to the rather large language that is Common Lisp.

In short, a rather good book, suitable for total beginners to Lisp and Common Lisp.

I found that it lost traction at times—sometimes it degenerated into a little bit of a reference, and you felt like you were reading a dictionary—but fairly quickly it recovered and had your attention again (while still being didactic). Similarly, the practicals in the last few chapters were almost too well-architected; I really just felt like I was building the target application, sort of learning the techniques, but ultimately it wasn’t necessarily interesting.

Finally, the topics glossed over in the conclusion are probably more important to someone wanting to build real applications with Common Lisp (i.e. relating to “practical Common Lisp”) than some of the stuff that could probably be gleaned from an evening with the HyperSpec—finding libraries and deploying applications are two very big question marks for any Lisp developer. This is partly a result of developments in these areas being even more recent than the book (e.g. QuickLisp development began in 2010, after the book’s last copyright year of 2009).

All in all, an excellent introduction to the world of Common Lisp.