Dragan Djuric

i like in depth optimisation posts like this post. however it starts by expressing disagreement with the statement that idiomatic common lisp is much faster than idiomatic clojure, but in the end doesnt do much to dispell this. all it does is it shows how much in depth knowledge of clojure and jvm you need in order to still be slower than a very simple implementation in common lisp. i myself am quite new to common lisp, and comming from the machine learning and scientific computing background, i am VERY impressed by its speed, interactiveness, and just general neatness of programming. i don't think there exists a language that comes close to this. i wish there were more members from ml and scientific community involved in the common lisp community. in fact there is one person in the clojure community who i would love to try common lisp: https://dragan.rocks/

I recently published a series of 16 blog posts Deep Learning from Scratch to GPU that does exactly that! [0] I also started working on a book titled "Deep Learning for Programmers"[1] that takes it even further! You can subscribe today and start reading the drafts as they are written. [0] https://dragan.rocks [1] https://aiprobook.com

I would think Clojure vs. Java would be used given immutability. I like both Haskell and Racket for math, especially this article on geometric algebra with Haskell: https://crypto.stanford.edu/~blynn/haskell/ga.html I am personally learning Shen[1] because Lisp, optional typing (great type system), and the formal work done within it, and for it in proving, verification and other related endeavors. It seems to tick the Haskell, Lisp, Prolog and logic boxes for me. Its portability is great[2], however, it is still young and building libraries. I am thinking on trying to mimic the DL work done by Dragan Djuric[3] for Clojure in Shen. We'll see how that goes... [1] http://www.shenlanguage.org/ [2] https://shen-language.github.io/ [3] https://dragan.rocks/

> It's not Clojure-dead It never ceases to amaze me. Almost every single time, whenever there's a post or a comment on HN that mentions Clojure or Clojurescript, there's always someone from outside of the Clojure community attacking the language, saying things that are simply untrue. Like people are afraid of it becoming too successful. It's not some zero-sum game - the success of one language ecosystem doesn't mean that your other, the more favorite tool would be immediately forgotten. Somehow I don't see Clojure people attacking other languages; they instead learn and borrow from them. - Python people would be like: "you can't do machine learning stuff...", and what Clojure people say? Instead of fighting Python, they're like: "We can¹, and also We have nothing against Python, we'll figure out a way to talk to it from Clojure.²" - Golang people would be: "CSP be is cool," Clojure people: "Awesome, we'll borrow it just the way how you did it. Also, we like Golang, we're going to write a Clojure interpreter and linter in it.³" - R people: "Clojure is data-driven? Pfff... you know nothing about statistics ...." Clojure people: - "Oh yeah R is cool, btw. we've just figured out a way to interop from Clojure⁴." - Elixir people: "BEAM is way better than your JVM crap...", Clojure people: "Not really, but okay, we see your point, we'll build Clojure on BEAM⁵" - JS/TS people say things like "Modern Javascript is so nice, who needs Clojure now?" They get excited about stuff…

Oh, so many things. The parallelism isn't actually that powerful, and in 2019 there's very little to set it apart. The building blocks are great, e.g. immutability everywhere, but few of the built-in primitives are actually usable (hidden unconfigurable thread pools etc). Stack traces still regularly horrible. Libraries are regularly abandoned. ClojureScript integrating with npm etc is more stress than you'd like. Core development is haphazard and proudly so. Types are nice, and spec is still up in the air, and slow, and not widely implemented, and will probably be rewritten several more times before being abandoned. Hiring is harder than a dozen other languages. All that said, there is still amazing stuff happening. I hold out some hope that Dragan's work might spark a bigger stats/ML community on top of Clojure, for example: https://dragan.rocks/ Every day I can still write code and think "yay, that's cute", and be thankful for the dynamism and clarity it can enable. But I wouldn't recommend it to anybody, for anything really, and I feel sad realising that.

In my experience, it works just fine. Clojure for the frontend is the best-in-class frontend dev environment that I've worked with. Instant hot code reloading, a browser-connected repl, great debugging tools, and a really nice collection of libraries for getting stuff done. I've never had to use native APIs for iOS and Android, so I can't speak to that from experience, but I know that there's some really nice machine learning work that's done in Clojure[0]. One of the main bits of Clojure philosophy is to just embrace the host platform, and our company has done that very successfully. I think I agree that there are compromises, but on the whole I've come out pretty far ahead with the tools I get to use. My point, though, wasn't to proselytize for Clojure (even though I do love it!), but to point out that there are ecosystems that have made significant progress towards this idea of convergence, and that some people (me in particular) are very happy to be moving in that direction. I'm excited to see progress on the OS front. [0]https://dragan.rocks/

If you're interested in high-performance Clojure, these articles are good: https://dragan.rocks/articles/18/Fluokitten-070-map-reduce-primitive-a… Fluokitten and Neanderthal are great for high performance numerics. Can't really get any faster than Neanderthal (which uses MKL and the GPU for compute). And fluokitten can make working with arrays a bit nicer, in that it'll look a bit more like working with sequences, though you still need to be careful about the functions you use with it to avoid boxing. https://clojure.org/reference/java_interop Read the section about type hints and working with primitive types and the optimization tips section.

The book looks interesting and the associated libraries (neanderthal for e.g.) But while going through your performance comparison [1], I feel something is off. I am not that familiar with libpython-clj and how it works, but looks like you are loading python from within the JVM and in turn the python is loading the C++/fortran OpenBLAS libraries to get the numerical calculations done for the Correlation Coefficient. I suspect this multi-level indirection is creating it's own performance overhead. For now, I don't believe the performance benchmark are telling us the true story :-) But after saying all that, I love how concise is the clojure implementation is. [1] https://dragan.rocks/articles/20/Clojure-Numpy-Cupy-CPU-GPU

The follow up article addresses this concern. Similar results https://dragan.rocks/articles/20/Clojure-Numpy-Cupy-CPU-GPU-2

Besides TornadoVM, http://javagl.de/jcuda.org/ https://dragan.rocks/software/ https://blogs.oracle.com/javamagazine/post/programming-the-gpu-in-java

Check out Neanderthal[0], it seems to have support for some subset of sparse matrices and it's faster than ND4J[1] to boot. [0]: https://neanderthal.uncomplicate.org [1]: https://dragan.rocks/articles/18/Neanderthal-vs-ND4J-vol1

There's Incanter[1], but I've never used it, so can't comment on how good or complete it is. And of course there are the article author's libraries: https://dragan.rocks/software/ [1] https://data-sorcery.org/

Much more productive than with OpenCL where "Hello World" is 170 lines of code. See http://dragan.rocks/talks/EuroClojure2016/clojure-is-not-afraid-of-the… Down/up arrows move you through slides, while left/up arrows move you through sections. Normally, you'd press down-down-down until there are no more slides, and then right to cross to the next section. ESC gives you the bird's view of the structure.

Corresponding blog post: http://dragan.rocks/articles/16/Clojure-is-not-afraid-of-the-GPU-slide…