Well, that blog seems to be down at the moment. And, while I've done a bit of playing around with Clojure I haven't done enough to have a strong opinion on it one way or another. I liked some of what I saw, but I was also a bit down on it mainly because of a factor Unne mentions: I'm just much more familiar with CL. If I did enough Clojure I might feel quite differently about that. I do agree with you about the limitations of the JVM, but of course there are also some big advantages to being on the JVM. But I also think there's an analogue to that in how I think about "Lisp all the way down." I'd also say in response to Unne that part of the reason Clojure hasn't come in for as much stick as a lot of other Lisp variants is that it gives the impression of not being completely half-baked. It also gives the impression of differing from CL in ways that might be pretty useful. The problem with a lot of the little Lisps people write is that they're taking something that would be a worthwhile learning project, but that probably doesn't need to be released into the wild, and offering it as if it were some sort of reasonable alternative to CL. That doesn't bother me much actually, but it gets under some people's skin pretty badly.
Anyway, since I haven't read the blog post, and I haven't done enough Clojure to have a strong opinion about it (yet- I keep meaning to try to write something non-trivial in Clojure but I've got too much on my plate at the moment) I mainly wanted to comment on the "Lisp all the way down"/"language bigotry" thing. First, you offer an "on the one hand... but on the other hand" position that's pretty hard to disagree with. I mean- certainly any practical CL implementation and the libraries one uses with it are going to use FFI to some extent. At the same time there are certainly going to be cases where you would prefer that a library be in CL, even considering the practicalities. So where most people are going to differ is where those lines are best drawn.
I do think that you're ignoring an important difference between using a piece of software and using a library though. If you want a piece of bulletin board software, and if one exists that does everything you want, and if you aren't going to want to customize it by a whole lot, beyond the customizations it is meant to support easily, then I can't see much reason to care what it's written in. Imean- you just install it and use it. End of story.
The situation is a bit different when you're using a library, and I'd say that if I'm programming in CL I'd pretty much always prefer a library written in CL, all other things being equal. There are some distinct disadvantages to using FFI. Debugging is trickier, for one thing, but there's also often an impedance mismatch between CL and the foreign language that takes some pretty clever programming to completely hide. And even after you've managed to hide those differences pretty well- well, you might want to alter the library you're using, but not want to have to write a lot of C or (shudder C++) to do it. Or you might want to reach down into the imlementation level from CL for some rreason, in ways that using an FFI makes difficult.
Of course for some types of thing this isn't much of an issue. If you only need a narrow interface to the functionality the library provides, and if that functionality is pretty much "settled"- I mean if it is functionality where there's a pretty clear right way to do things- and if your app is mostly about something else and isn't going to be very intertwingled with what the library is doing for it, and if the library itself is really solid... well, even in that case it would probably be better to have a library in CL, but it might not be enough better that it makes sense for anyone to actually write such a library.
My first programming jobs were in real-time graphics. Actually, the first sizable piece of code I ever wrote was a software renderer for Windows- this was just around the time that hardware acceleration was becoming available in the consumer market, but it wasn't widespread. Anyway, I managed to get a job doing graphics based on that sample code, but I pretty much immediately had to learn to program to some high level APIS, as we needed hardware acceleration (and some frighteningly expensive dedicated hardware) and had to be more productive than doing straight opengl would have let us be. I haven't done any professional graphics programming since 2002 (and even that was just a short term contract), but I've followed a lot of the developments, and I've been interested to see some pretty sophisticated open source libraries appear. I've also done a bit of idle thinking about how one would go about using CL to do graphics programming.
I think that using FFI to call opengl is not a hard decision at all. It might be nice to have an opengl analogue written entirely in Lisp, but it's hard to imagine that the advantages of something like that would make it worthwhile to write one. Gl is pretty close to a graphics assembler, and using an FFI to call it seems pretty obviously the right thing to do. But if you wanted to write a game, for instance, you probably wouldn't want to write straight gl. You'd want to use a higher level library. And in that case it would be a lot better to have an engine written in CL (assuming you could get performance where you wanted it.) On the other hand, if you were working as a single programmer, even if you were working full-time, you probably wouldn't have the time to write both the engine and the game. So as a matter of practicality you probably would wind up using some existing graphics library or game engine. But it would be noticeably less good than having something written in CL on top of an FFI to gl or some other low-level graphics API.
I guess this is sort of an extreme example. There aren't a lot of places where people use libraries as extensively, and want to change them as much as they do when using libraries meant to structure things like games and other graphics applications. But I think it's instructive to think about, both because it is an extreme example, and also because of the difference between the low-level APIs, like gl, and the higher level APIs, like those found in 3D and game engines. There aren't a lot of drawbacks to using FFI with the former, but I think there would be significant drawbacks to using FFI for the latter.