The trouble is, so much depends on the problem space. For example, my team is building a "real world" clojure application - mostly data transformation and routing - but in the "real world" the actual speed of clojure execution is fairly insignificant compared to I/O.
You could extract just the data transformation bits - call something that parses and validates a big heap of XML, say - but then it wouldn't really represent my real world. Frankly I don't care that much how the clojure code performs, as long as it's not atrocious - and if it is, that probably indicates a logical flaw in our code, not a language issue. My "real world" has mostly been like this for at least the last decade. Computers are fast and cheap, especially compared to good developers! Not meaning to rain on your parade - there is value in good benchmarks, especially to prove that X language isn't _terribly_ slow compared to Y. But they are more often abused than used correctly. I remember endless "Ruby is slow!" arguments when Ruby was newer - and yes, it was slow, but not so slow that it mattered, for the vast majority of "real world" applications. - Korny On 23 May 2013 19:34, "bekon" <aibek.sarimbe...@gmail.com> wrote: > Hello, can anyone give a hint on real-world Clojure application? I would > like to compare applications written in different dynamic JVM languages > with respect to different JVM characteristics. Usually this kind of things > are done by means of benchmarking, however, no benchmarking suite exists > for scripting languages. Available ones are for Java and Scala. There is > also a Programming Languages Shootout Project ( > http://benchmarksgame.alioth.debian.org/), but the applications there are > relatively small and CPU-intensive. Ideally, I would like to have a > real-world applications (but not interactive ones, since it's not trivial > to make it deterministic and will require automatization of the user > behavior) that consume some input and produce some output. In this way I > can profile the underlying JVM and collect metrics of interest. I've tried > to search on GitHub, but failed. If you read a research paper comparing > different JVM languages, what kind of applications you expect to be > compared? I'm looking exactly for those ones. One candidate can be Clojure > itself, since it's written in Clojure (am I right?), but then the question > is what does it mean to "run Clojure on the JVM"? I don't understand how to > run it and how to use the javaagent and collect the metrics of the > underlying JVM. > > Any ideas? > > -- > -- > 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. > > > -- -- 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.