Clojure IMO is not truly dynamic, at least not to the extent of Python/Ruby. I like to refer to Clojure as a "dynamic enough" language.
For example, once defined, types cannot be modified by adding new members (deftype that is). If you want to add a new field to a deftype in Clojure, you have to redefine the entire type. Existing instances of that type must also be recreated to take advantage of the new time. Contrast this with Python's foo.__class__.bar = 42. Sure defrecord allows some of these features, but the way it accomplishes this is much different from the way it is done in other languages. In addition, some languages like Python allow you to do crazy stuff like reflect over the stack to inspect locals in parent stack frames. This is something that is not possible in Clojure, thankfully. These are just two examples where Clojure is much more restricted than the "normal" dynamic language. As mentioned, Clojure also allows for optional type hinting that allows the compiler to emit code that is very close to the bytecode emitted by javac. This allows for even better performance, at the cost of having to specify the type of a few locals here and there. All that being said, the idea that "dynamic languages are slow" is basically a myth. The truth is that it is often harder to write good JITs for dynamic languages, but as LuaJIT and PyPy have shown this, is not a unsolvable problem. Lastly, the performance gains from having a "best in the world" GC should not be underestimated. In functional languages you often create and destroy objects much faster than in other languages. Therefore the performance cost of a object allocation can greatly impact performance. Hotspot has one of the fastest GCs on the planet...Clojure benefits greatly from this. Timothy On Tue, Feb 18, 2014 at 8:31 PM, Mikera <mike.r.anderson...@gmail.com>wrote: > For Clojure at least, it is a combination of things, including: > - The quality of the optimisations that the JVM itself does during JIT > compilation. Virtual method calls for example are crazily fast. > - The JVM garbage collector - which is seriously good. > - The ability to use type hints and primitive types (effectively allowing > some static typing for performance in focused areas) > - Use of Java for much of the underlying infrastructure (e.g. Clojure's > collections are written in Java) > - A certain amount of type inference (e.g. for numerical primitive > expressions) > - Intelligent use of the host capabilities (for example, most of Clojure > "dynamic" feel is achieved through clever use of Java interfaces, which is > much faster than the map-based method lookup in many other dynamic > languages). > - A fairly decent compiler (Clojure is almost always compiled, rather than > interpreted). The bytecode generated is generally quite good, though there > is still room for improvements :-) > - Macros can do clever things at compile time to reduce runtime overhead > > Some of these are just about good implementation (either within the JVM or > Clojure itself). > > Other advantages are perhaps more intrinsic to Lisp. I think that macros > are the best example here. > > Apart from that, other dynamic languages probably make things hard for > themselves. In particular, I think it would be hard to get Lisp-like > performance in any dynamic language that makes pervasive use of runtime > monkey-patching - simply because the runtime overhead of implementation > lookup would always be a performance killer. > > On Wednesday, 19 February 2014 10:59:16 UTC+8, Andy C wrote: >> >> Hi, >> >> There are many performance benchmarks showing that compiled CLISP is >> almost as fast as C++ or Clojure as Java. >> >> Being a dynamically typed language though, I wonder how it is possible. >> Is it because the compiler is able to sort out actually used types and >> assemble appropriate byte code or the cost of calling virtual methods is >> negligible. >> >> I probably should check out generated JVM byte code to see the answer >> firsthand but still would appreciate a higher level answer. >> >> Thanks in advance, >> Andy >> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- "One of the main causes of the fall of the Roman Empire was that-lacking zero-they had no way to indicate successful termination of their C programs." (Robert Firth) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
