41–50 of 89 posts
So if I wanted to write CLI applications in Clojure, is this my best bet? Cause the JVM is about the least suitable platform I have ever worked with for CLI apps...which is most of what I do. I'm constantly in this pickle of wanting to use Clojure but defaulting to Ruby because the JVM is so terrible at it.
Why C but not llvm? Structured code generation is always better than string-based one.
Some other advantages of C over LLVM IR:
ABI compatibility with C automatically. In LLVM IR, being ABI-compatible with C is often a considerable headache and you have to do different things on each platform.
You can use C libraries by #including their header files (the way many C libraries were designed to be used), instead of hardwiring all that information (macro expansions, enum values, typedefs, inline functions, struct definitions, etc.) from their header files in your code generator.
You have the option of switching C compilers; you're not as locked into a single backend.
With a bit of care, you can make your output much more readable. LLVM IR demands either SSA form (most front-ends don't want to do this) or herds of allocas, loads, and stores everywhere. In C, you just say "int x;" to declare an int, and just "x" to refer to it.
You can use C features like bitfields, designated initializers, short-circuit operators (&&, ||), compound assignment (+=, -=, etc.), and so on. You can do all these things in LLVM IR, but you have to lower them yourself.
Earlier quoted context omitted.
More moving parts being more error prone is not generally a controversial opinion.
This argument can just as easily be used to support a claim that generating C via string manipulation can very well be less error prone than relying on a huge, complex API like LLVM. It is not a given that there are "more moving parts" in generating C output from a compiler than in using LLVM.
While that's a true enough statement by itself, your snipe conveniently skips half of the process in question.
As someone who doesn't use Clojure, but watches it fairly closely, I'd say the least appealing part of Clojure is its reliance on the JVM. As such, I'd say efforts such as these are greatly welcomed.
So if I wanted to write CLI applications in Clojure, is this my best bet? Cause the JVM is about the least suitable platform I have ever worked with for CLI apps...which is most of what I do. I'm constantly in this pickle of wanting to use Clojure but defaulting to Ruby because the JVM is so terrible at it.
If the startup slowness is your problem, look into Nailgun: http://www.martiansoftware.com/nailgun/ If that's not your problem with the JVM, what is?
So if I wanted to write CLI applications in Clojure, is this my best bet? Cause the JVM is about the least suitable platform I have ever worked with for CLI apps...which is most of what I do. I'm constantly in this pickle of wanting to use Clojure but defaulting to Ruby because the JVM is so terrible at it.
You could also use node.js with Clojurescript, if you're willing to accept the compromises of Clojurescript.
For those interested in Lisp implementations which compile to C, providing cross-platform benefits and a nice FFI, gambit-c and chicken are performant, mature implementations of the Scheme programming language.
So if I wanted to write CLI applications in Clojure, is this my best bet? Cause the JVM is about the least suitable platform I have ever worked with for CLI apps...which is most of what I do. I'm constantly in this pickle of wanting to use Clojure but defaulting to Ruby because the JVM is so terrible at it.
So if I wanted to write CLI applications in Clojure, is this my best bet? Cause the JVM is about the least suitable platform I have ever worked with for CLI apps...which is most of what I do. I'm constantly in this pickle of wanting to use Clojure but defaulting to Ruby because the JVM is so terrible at it.
If the startup slowness is your problem, look into Nailgun: http://www.martiansoftware.com/nailgun/ If that's not your problem with the JVM, what is?