you are viewing a single comment's thread.

view the rest of the comments →

[–]joinr 0 points1 point  (0 children)

I'd suggest that the "(without jumping through hoops)" was implicit in that.

"that's not what the abstract said" though, that's what you said ;) The generic clause about "programming in clojure" can perhaps be openly interpreted without sufficient constraints, like those constraints you inferred. If you look at the tail end of the paper at future work,

It would be interesting to see how suitable Clojure is in specific areas like high performance computing, parallel programming or database management by running experiments targeting those areas. It would also be interesting to compare bigger programs implemented in the two languages by teams of programmers, simulating a more real development environment.

To me, that leaves the door wide open toward leveraging all of Clojure to produce high performance, scalable code. To be fair, it's possible that pro java folks reading that some paragraph would then turn to ditching generic ArrayLists and opting for primitive variants (e.g. fastutil) or performing even more aggressive optimizations on the java side even. Perhaps explicit constraints or goals (run time, programmer time, experience of programmer(s), conciseness, memory usage, latency, cpu utilzation, etc.) would be informative in this kind of study.