That is just a strings on the screen. What is the internal in-memory representation of this? The pointers to functions and agruments, as is should be?
Btw, there was a link here to a blog-post from a jruby developer who argued that JVM is a crap for a dynamic languages (read: for anything except what it is) Why would you think it is perfect for a Lisp?
Do we need to start again about bad-by-design FFI, rudimentary and inefficient network and disk support, and so on?
Yes, it is well situated to some in-house development, but not for everything.
I know, some people believe it is good even for things like Cassandra, but I cannot imagine database system without things like efficient and low-level implementation of network layer (epoll/kuqueue support, tunable buffers, intellectual error handlers) and especially disk routines (O_DIRECT, proper caching and the like).
> The pointers to functions and agruments, as is should be?
Effectively, yes. What would you expect to be able to do with this in a "real lisp" that you can't do in clojure?
> Btw, there was a link here to a blog-post from a jruby developer who argued that JVM is a crap for a dynamic languages (read: for anything except what it is) Why would you think it is perfect for a Lisp?
irrelevant JVM rantings - it is just a calling names. ^_^
I can do it too - the widely used and popular implementation of an outdated, bureaucratic-designed concept which is situated well to simple and bureaucratic in-house application development and became bloated with badly-designed and poorly implemented so-called enterprise stuff which most people tent to reuse without thinking just because they heard (very good marketing) that everyone else did.
It have a fundamental problem being designed as an isolated from an OS blob (same as Flash, btw) which is proved to be dramatically inefficient for most of task other that very basic and general computation.
It was a complete failure as an in-browser technology, desktop-technology, and even server technology in the case of highly-loaded or low-latency systems. It is still in use because of almost parabolic increase in the x86 processors power and the same-curved decrease in the costs of CPUs and RAM. That is why projects like Cassandra are there - hardware is so fast and cheap that you can use even a bloated and crappy tools.
In the mobile segment - J2ME and Dalvik VM have no relations with JVM. ^_^
Given that you've drifted completely off topic, I presume that you accept that your initial comment was completely incorrect and needlessly inflammatory?
Btw, there was a link here to a blog-post from a jruby developer who argued that JVM is a crap for a dynamic languages (read: for anything except what it is) Why would you think it is perfect for a Lisp?
Do we need to start again about bad-by-design FFI, rudimentary and inefficient network and disk support, and so on?
Yes, it is well situated to some in-house development, but not for everything.
I know, some people believe it is good even for things like Cassandra, but I cannot imagine database system without things like efficient and low-level implementation of network layer (epoll/kuqueue support, tunable buffers, intellectual error handlers) and especially disk routines (O_DIRECT, proper caching and the like).