4 ms·

My personal opinion is that one should learn, and become comfortable in, Java before attempting Clojure. Clojure is a very neat little language, but if you don'

My personal opinion is that one should learn, and become comfortable in, Java before attempting Clojure. Clojure is a very neat little language, but if you don't understand what it's doing under the hood on the JVM, a lot of stuff is going to end up being mysterious. Don't get me wrong, I love the language to bits, but a lot of its beauty is in how it takes the existing Java model and does something cool with it - and to understand that, you need to understand what it's working with.

scott_s 18y ago
Interesting. That's the exact same argument I made above with C and systems programming. Clojure has caught my eye, and I'm familiar with Java, but I'm not as familiar with the JVM itself. Any resources that are good overviews of the JVM?
- meredydd 18y ago
  Well, if you want to carry the analogy further, to know Java is to know the basics of how the JVM looks at life. The JVM has concepts of class, inheritance, methods, instances, constructors, and garbage collection baked into it, and they have the same semantics as Java. Arguably, the only difference is one of coding: the JVM codes a Java method as a series of stack-based opcodes, and a class as a set of methods with attributes, but the basic operations are the same. JVM bytecode directly encodes all basic operations: "invoke method X on this class", "declare this method as public and static" - even "if an exception occurs between <this instruction> and <that instruction>, jump <here> to handle it". By contrast, there's a level of indirection between Clojure and the underlying JVM. And so, for much the same reasons as it's a good idea to know some C when doing systems programming, you won't really understand what Clojure is doing (especially not the stack-traces!) unless you understand Java. There's also the practical point that, if you're working on the JVM, you'll be wanting to make use of the massive class libraries available for it. They're all written for native Java, so you'll have to be familiar with Java semantics to use them effectively. (Although the Lispy macro goodness means you can then wrap them up inside a concise functional abstraction when you're using them). If you still want to look at the JVM (for fun, or for implementation reasons), I'd say a good knowledge of Java is enough to just jump head-first into the specification: http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html http://java.sun.com/docs/books/jvms/second_edition/html/VMSp...
  - jimbokun 18y ago
    Just want to second this. I just read much of the spec this summer, and was surprised how directly the byte codes corresponded to Java semantics.

scott_s 18y ago

Interesting. That's the exact same argument I made above with C and systems programming. Clojure has caught my eye, and I'm familiar with Java, but I'm not as familiar with the JVM itself. Any resources that are good overviews of the JVM?

meredydd 18y ago
Well, if you want to carry the analogy further, to know Java is to know the basics of how the JVM looks at life. The JVM has concepts of class, inheritance, methods, instances, constructors, and garbage collection baked into it, and they have the same semantics as Java. Arguably, the only difference is one of coding: the JVM codes a Java method as a series of stack-based opcodes, and a class as a set of methods with attributes, but the basic operations are the same. JVM bytecode directly encodes all basic operations: "invoke method X on this class", "declare this method as public and static" - even "if an exception occurs between <this instruction> and <that instruction>, jump <here> to handle it". By contrast, there's a level of indirection between Clojure and the underlying JVM. And so, for much the same reasons as it's a good idea to know some C when doing systems programming, you won't really understand what Clojure is doing (especially not the stack-traces!) unless you understand Java. There's also the practical point that, if you're working on the JVM, you'll be wanting to make use of the massive class libraries available for it. They're all written for native Java, so you'll have to be familiar with Java semantics to use them effectively. (Although the Lispy macro goodness means you can then wrap them up inside a concise functional abstraction when you're using them). If you still want to look at the JVM (for fun, or for implementation reasons), I'd say a good knowledge of Java is enough to just jump head-first into the specification: http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html http://java.sun.com/docs/books/jvms/second_edition/html/VMSp...
- jimbokun 18y ago
  Just want to second this. I just read much of the spec this summer, and was surprised how directly the byte codes corresponded to Java semantics.