7 ms·

Clojure is one of the cooler languages out there. There has been one major blocker for me, though: the JVM. I don't want to have anything to do with the JVM. No

by exDM69 14y ago

Clojure is one of the cooler languages out there. There has been one major blocker for me, though: the JVM. I don't want to have anything to do with the JVM. Not because it's bad. It's just that native code is better, especially for the stuff I'm doing. I hope these developments eventually turn into a proper Lisp that you can interface with native C code efficiently. Racket is pretty cool too.

alberich 14y ago
I wonder what would be the advantages of using Clojure without the JVM over, say, Common Lisp. To me, it seems the great advantage of Clojure is its ease of using the large number of java libraries out there. However, if you take those libraries out, wouldn't a mature Lisp implementation like SBCL be much better?
- amouat 14y ago
  There are still some nice things such as destructuring and vectors & maps as base types. The syntax of Clojure is generally a bit cleaner and more concise, though I'm sure some lispers will disagree.
- pjmlp 14y ago
  There a few differences that might be worth still. Clojure is a Lisp-1, and provides better data structures as Common Lisp as far as I am aware. But the JVM benefit is a big one indeed.
  - alberich 14y ago
    I thought that, besides the JVM itself, the advantages of Clojure would be its concurrency model - as CL standard doesn't define anything related to this - and its stronger functional approach. I don't fully grasp the advantages of being a Lisp-1 or Lisp-2 :)
    - pjmlp 14y ago
      > I don't fully grasp the advantages of being a Lisp-1 or Lisp-2 :) It has to do with variable scoping. Lisp-1 only accepts lexical scoping, while Lisp-2 also allows for dynamic scoping. http://www.nhplace.com/kent/Papers/Technical-Issues.html http://www.nhplace.com/kent/Papers/Technical-Issues.html
      - mahmud 14y ago
        Good grief. No. Lisp-N has to do with the number of name spaces in the language. Lisp-1s only have ONE environment; the variables range over all values of the language, integers, functions, vectors, symbols, strings. In Lisp-N, there are N namespaces for each "kind" of value. Common Lisp is called a "Lisp-2" because it separates functions from other values. (it's closer to Lisp-5 or even Lisp-7, forgot which, because it allows that many kinds of "names" without collission. Also above you said Clojure "probably" has better data structures than Common Lisp. That is unsubstantiated.
        yoklov 14y ago
        For what it's worth, Clojure has implementations of Phil Bagwell's HAMT-based hash-maps, vectors, and sets. These are absolutely amazing data structures, and offer functional updates, a list-like API (O(log_32(n)) for most operations, which ends up being less than seven operations in practice, which is similar enough to O(1) for most programmers). I'm not much of a common lisp programmer (mostly sticking with scheme/racket and Clojure), but I don't think they've been ported to Common Lisp (yet), so the claim that Clojure has better data structures than Common Lisp, while somewhat a matter of preference, isn't entirely unsubstantiated.
        mahmud 14y ago
        Common Lisp has hash-tables, vectors, and sets .. had it, in an ANSI-specified document since 1984. The implementation details of these is, well, implementation dependent, be they HAMT or whatever. The language provides a wealth of tools out of the box, but it's the job of the programmer to choose more appropriate tools for the problems at hand. The following is the Common Lisp specification. 12+ implementations, half of them industrial strength, more than half commercial vendors, and everyone of them has to adhere to this spec: http://www.franz.com/support/documentation/8.2/ansicl/ansicl.htm http://www.franz.com/support/documentation/8.2/ansicl/ansicl...
- FrojoS 14y ago
  Prototype on the JVM but compile to C for production or performance critical tests? Ideally, no refactoring required at all. I guess it also helps to work with a dialect with more momentum. E.g. its easier to find support, on- and offline. Since I haven't really used Closure or any other Lisp for more than a tutorial, I might be very wrong, though.
  - Raphael_Amiard 14y ago
    Clojure -> C will very probably be slower than Clojure -> JVM, at least if the compiler is naive.
Raphael_Amiard 14y ago
Why do you prefer native code ? What do you even mean by native code ? The JVM does produce native code, it just does it at runtime (JIT compilation). So maybe you mean static compilation, but then, why is it better for the stuff you're doing ?
- regularfry 14y ago
  I can't answer for the GP, but native code is generally better for me because of the startup time.
- batista 14y ago
  >Why do you prefer native code ? For me, because I don't want to install the JVM, or force users of my stuff to install the JVM. I also don't care about JVM libs. >What do you even mean by native code ? The JVM does produce native code, it just does it at runtime (JIT compilation). I, for one, mean non-JIT, no virtual machine needed, native code. >So maybe you mean static compilation, but then, why is it better for the stuff you're doing ? Less startup overhead. Small binaries. Easily redistributable. No stuff I don't need.
  - sanxiyn 14y ago
    Does GCJ qualify? No JIT, no VM, native code, less startup overhead, easily redistributable.
- exDM69 14y ago
  > Why do you prefer native code ? What do you even mean by native code ? The JVM does produce native code, it just does it at runtime (JIT compilation). By native code I mean binaries emitted by my compiler in a format that my operating system can link and load. I usually write the code in C with some CPU-specific assembly intrinsics for the critical stuff. I tend to write computer graphics and physics simulation stuff which has to be quite fast. A lot of stuff I deal with is moving blobs of binary data from buffer to another (disk, memory, dma, gpu). Or computing a SIMD fused multiply-and-add for a few hundred megabytes of floating point data. Or invert and transpose a hundred thousand 4x4 matrices. Everything the JVM does is acting against me, so better just write native. Sure there are games and physics and whatnot written with Java and other systems, but they are more commonly "low perf" stuff. 2d games and that kind of stuff. And even then they suffer from JIT & GC pauses and other undesirable effects. It always ruins my day when in the middle of a Minecraft session the GC kicks in while running away from a Creeper.
pjmlp 14y ago
There are JVMs with native code generation like you would expect from a normal C compiler, they are just a bit too expensive. Here is one example, http://www.atego.com/products/aonix-perc/ http://www.atego.com/products/aonix-perc/
- exDM69 14y ago
  Yes. Java is getting closer and closer to native code performance. In some rare cases it can even beat C. But this is after billions of dollars have been thrown at trying to make Java fast. If you intend to distribute your software (as opposed to running on your own servers), it would require all the customers to have a fancy JVM. Or buying an expensive license to be able to distribute the runtime with your software.
  - markokocic 14y ago
    > Yes. Java is getting closer and closer to native code performance. In some rare cases it can even beat C. But this is after billions of dollars have been thrown at trying to make Java fast. Why is it a bad thing that someone was willing to pay money to make Java fast. Do you want to say that there haven't been billions of dollars in both money and man-hours thrown at trying to make C/C++ fast? There's no free performance.
    - exDM69 14y ago
      > Why is it a bad thing that someone was willing to pay money to make Java fast. I guess there's someone who wants to pay for that. But I don't think it's money well spent. The Java bytecode is not designed for or suited to fast execution and it's a bad intermediate representation for computer programs to be compiled into native code. The Java byte code was designed to be easy to interpret and was designed at a time when a memory access was faster to execute than an ALU instruction (on cheap h/w where Java was originally intended to be run on). Those days have passed and we should move on to better intermediate representations for computer programs. Like LLVM IR.
      - 14y ago

by exDM69 14y ago

alberich 14y ago

I wonder what would be the advantages of using Clojure without the JVM over, say, Common Lisp. To me, it seems the great advantage of Clojure is its ease of using the large number of java libraries out there. However, if you take those libraries out, wouldn't a mature Lisp implementation like SBCL be much better?

amouat 14y ago
There are still some nice things such as destructuring and vectors & maps as base types. The syntax of Clojure is generally a bit cleaner and more concise, though I'm sure some lispers will disagree.
pjmlp 14y ago
There a few differences that might be worth still. Clojure is a Lisp-1, and provides better data structures as Common Lisp as far as I am aware. But the JVM benefit is a big one indeed.
- alberich 14y ago
  I thought that, besides the JVM itself, the advantages of Clojure would be its concurrency model - as CL standard doesn't define anything related to this - and its stronger functional approach. I don't fully grasp the advantages of being a Lisp-1 or Lisp-2 :)
  - pjmlp 14y ago
    > I don't fully grasp the advantages of being a Lisp-1 or Lisp-2 :) It has to do with variable scoping. Lisp-1 only accepts lexical scoping, while Lisp-2 also allows for dynamic scoping. http://www.nhplace.com/kent/Papers/Technical-Issues.html http://www.nhplace.com/kent/Papers/Technical-Issues.html
    - mahmud 14y ago
      Good grief. No. Lisp-N has to do with the number of name spaces in the language. Lisp-1s only have ONE environment; the variables range over all values of the language, integers, functions, vectors, symbols, strings. In Lisp-N, there are N namespaces for each "kind" of value. Common Lisp is called a "Lisp-2" because it separates functions from other values. (it's closer to Lisp-5 or even Lisp-7, forgot which, because it allows that many kinds of "names" without collission. Also above you said Clojure "probably" has better data structures than Common Lisp. That is unsubstantiated.
      - yoklov 14y ago
        For what it's worth, Clojure has implementations of Phil Bagwell's HAMT-based hash-maps, vectors, and sets. These are absolutely amazing data structures, and offer functional updates, a list-like API (O(log_32(n)) for most operations, which ends up being less than seven operations in practice, which is similar enough to O(1) for most programmers). I'm not much of a common lisp programmer (mostly sticking with scheme/racket and Clojure), but I don't think they've been ported to Common Lisp (yet), so the claim that Clojure has better data structures than Common Lisp, while somewhat a matter of preference, isn't entirely unsubstantiated.
        mahmud 14y ago
        Common Lisp has hash-tables, vectors, and sets .. had it, in an ANSI-specified document since 1984. The implementation details of these is, well, implementation dependent, be they HAMT or whatever. The language provides a wealth of tools out of the box, but it's the job of the programmer to choose more appropriate tools for the problems at hand. The following is the Common Lisp specification. 12+ implementations, half of them industrial strength, more than half commercial vendors, and everyone of them has to adhere to this spec: http://www.franz.com/support/documentation/8.2/ansicl/ansicl.htm http://www.franz.com/support/documentation/8.2/ansicl/ansicl...
FrojoS 14y ago
Prototype on the JVM but compile to C for production or performance critical tests? Ideally, no refactoring required at all. I guess it also helps to work with a dialect with more momentum. E.g. its easier to find support, on- and offline. Since I haven't really used Closure or any other Lisp for more than a tutorial, I might be very wrong, though.
- Raphael_Amiard 14y ago
  Clojure -> C will very probably be slower than Clojure -> JVM, at least if the compiler is naive.

Raphael_Amiard 14y ago

Why do you prefer native code ? What do you even mean by native code ? The JVM does produce native code, it just does it at runtime (JIT compilation). So maybe you mean static compilation, but then, why is it better for the stuff you're doing ?

regularfry 14y ago
I can't answer for the GP, but native code is generally better for me because of the startup time.
batista 14y ago
>Why do you prefer native code ? For me, because I don't want to install the JVM, or force users of my stuff to install the JVM. I also don't care about JVM libs. >What do you even mean by native code ? The JVM does produce native code, it just does it at runtime (JIT compilation). I, for one, mean non-JIT, no virtual machine needed, native code. >So maybe you mean static compilation, but then, why is it better for the stuff you're doing ? Less startup overhead. Small binaries. Easily redistributable. No stuff I don't need.
- sanxiyn 14y ago
  Does GCJ qualify? No JIT, no VM, native code, less startup overhead, easily redistributable.
exDM69 14y ago
> Why do you prefer native code ? What do you even mean by native code ? The JVM does produce native code, it just does it at runtime (JIT compilation). By native code I mean binaries emitted by my compiler in a format that my operating system can link and load. I usually write the code in C with some CPU-specific assembly intrinsics for the critical stuff. I tend to write computer graphics and physics simulation stuff which has to be quite fast. A lot of stuff I deal with is moving blobs of binary data from buffer to another (disk, memory, dma, gpu). Or computing a SIMD fused multiply-and-add for a few hundred megabytes of floating point data. Or invert and transpose a hundred thousand 4x4 matrices. Everything the JVM does is acting against me, so better just write native. Sure there are games and physics and whatnot written with Java and other systems, but they are more commonly "low perf" stuff. 2d games and that kind of stuff. And even then they suffer from JIT & GC pauses and other undesirable effects. It always ruins my day when in the middle of a Minecraft session the GC kicks in while running away from a Creeper.

pjmlp 14y ago

There are JVMs with native code generation like you would expect from a normal C compiler, they are just a bit too expensive. Here is one example, http://www.atego.com/products/aonix-perc/ http://www.atego.com/products/aonix-perc/

exDM69 14y ago
Yes. Java is getting closer and closer to native code performance. In some rare cases it can even beat C. But this is after billions of dollars have been thrown at trying to make Java fast. If you intend to distribute your software (as opposed to running on your own servers), it would require all the customers to have a fancy JVM. Or buying an expensive license to be able to distribute the runtime with your software.
- markokocic 14y ago
  > Yes. Java is getting closer and closer to native code performance. In some rare cases it can even beat C. But this is after billions of dollars have been thrown at trying to make Java fast. Why is it a bad thing that someone was willing to pay money to make Java fast. Do you want to say that there haven't been billions of dollars in both money and man-hours thrown at trying to make C/C++ fast? There's no free performance.
  - exDM69 14y ago
    > Why is it a bad thing that someone was willing to pay money to make Java fast. I guess there's someone who wants to pay for that. But I don't think it's money well spent. The Java bytecode is not designed for or suited to fast execution and it's a bad intermediate representation for computer programs to be compiled into native code. The Java byte code was designed to be easy to interpret and was designed at a time when a memory access was faster to execute than an ALU instruction (on cheap h/w where Java was originally intended to be run on). Those days have passed and we should move on to better intermediate representations for computer programs. Like LLVM IR.
    - 14y ago