Okay, now we're getting somewhere. I'm still not sure about the assumption you make in the first line (1. that it will be poor quality C code 2. that its compilation will result in inefficient machine code) -- we would actually need to test it out in order to find out whether that is true.
Although I can understand your point in the second paragraph. Indeed, C is a language that is nowadays mostly suited for performance-oriented application. The reason the author translates Clojure code into C, and then into machine code is that this is vastly easier than going straight to native code. As you say, there are so many platforms with different sets of instructions that it would be almost pointless to write an optimized compiler directly from Clojure code to all these platforms, particularly since Clojure is still a somewhat obscure language.
The value in doing this is that Clojure promotes good programming practices. In turn, this means that someone who has little experience with embedded systems or hand-optimizing assembly can write better performing code in Clojure -> C -> assembly than if they tried to use C without any experience. Sure, it won't be as fast as if they were an experienced assembly guru, but the difference will only be a factor of 1-2 -- the algorithm is much more important than the compilation, and this is where Clojure shines.
One other use is when a project is not performance-oriented, but development-oriented. A fast development cycle is in a lot of situations much more important than the speed at which the code runs. As Clojure is currently limited to the JVM (and Javascript maybe??), extending this support to C now extends the domain of Clojure to almost anything.
A language from an entirely different paradigm (Functional language, Garbage collection, tons of abstractions and a huge API) cannot ever be a replacement for or even compete on the same playing field C. We are talking apples to oranges here.
These languages are not comparable equivalents. Their specialties are completely opposite. To make their output equivalent, you would have to construct an AI system more advanced than anything that exists today.
Name a place (besides IOS) where this will enable Closure to run that does not already have a JVM? Now tell me if it would be practical to run it there (printer firmware ETC) VS hand coded C.
Speaking of IOS - This IS an area where this may be practical, but that is only because of politics (Apple's tyrannical restrictions). But there are already closure compilers for IOS.
Any embedded device programmer will tell you that a VM in a printer is an expensive novelty. Putting a VM on an embedded device will incur extra overhead in both memory and processor requirements. This will only raise the processor cost by a couple of dollars likely, but quantity is always the problem here. If HP ships 2 million LaserJet X's in a given year, the use of the chip just cost them 4 million dollars extra. Now which is cheaper? hiring 2 C gurus to program the firmware at 150k per year, or I Closure programmer off the street at 90k per year (don't forget the 4 mill in hardware cost differences)?
While I agree with you, all the Ricoh printers in our company have a VM installed.
And I can tell you that a well known mobile company originally from UK, available in most European countries, makes use of Java for Smartcards on their SIM cards.
You made your math wrong. Nowadays, specially if we put outsourcing in the equation, hiring Java developers is way cheaper than hiring C developers, specially since many universities don't teach C any longer.
Although I can understand your point in the second paragraph. Indeed, C is a language that is nowadays mostly suited for performance-oriented application. The reason the author translates Clojure code into C, and then into machine code is that this is vastly easier than going straight to native code. As you say, there are so many platforms with different sets of instructions that it would be almost pointless to write an optimized compiler directly from Clojure code to all these platforms, particularly since Clojure is still a somewhat obscure language.
The value in doing this is that Clojure promotes good programming practices. In turn, this means that someone who has little experience with embedded systems or hand-optimizing assembly can write better performing code in Clojure -> C -> assembly than if they tried to use C without any experience. Sure, it won't be as fast as if they were an experienced assembly guru, but the difference will only be a factor of 1-2 -- the algorithm is much more important than the compilation, and this is where Clojure shines.
One other use is when a project is not performance-oriented, but development-oriented. A fast development cycle is in a lot of situations much more important than the speed at which the code runs. As Clojure is currently limited to the JVM (and Javascript maybe??), extending this support to C now extends the domain of Clojure to almost anything.