Welcome! Have you found #C0536F336 yet?

Thanks! Nope, I'll join that!

It's not exactly vibrant, but maybe we can change that. 😃

Sure thing! 😄

There's also the vibrant, and highly social, #CBJ5CGE0G.

I am maintainer of https://github.com/scicloj/scicloj.ml , the (only ?) active ML library for Clojure. There are lots of tutorials here to get started: https://github.com/scicloj/scicloj.ml-tutorials I am happy for any feedback or any other help. This library does not do deep learning, but has a ll the usual classical machine learning algorithms. It is meant to be used with a "http://tech.ml dataset", information here.: https://github.com/scicloj/tablecloth ML in Clojure menas as well doing "poly-glot programming". libpython-clj (for python) and clojisr (for R) are 2 great bridges into python and R.

Thanks Carsten! I can see many wrapped goodies in there 🙂 Do you know what the status of djl is?

There are exciting times for Data Science in Clojure, as well thanks to a very innovative notebook concept: https://github.com/nextjournal/clerk So you join at the right moment in time.😀

djl is Java, right ? It is backed by Amazon, so I would say it has its plays. Version 1.0 was just released. So I am "always" questioning to which extend Clojure wrappers of a existing Java library make sense. Specially if the wrapper is a "one man project", while the Java library is a big project. So the wrapper aims at a moving target. (And Clojure can use Java as is via interop) There are "partial" Clojure wrappers for djl: https://github.com/scicloj/clj-djl is based on Java SMILE https://haifengl.github.io/ ... But I would not call it a "wrapper"

I personally do NLP, and have used "special python libraries" which are more high levle then PyTorch or Tensorflow, simpletransformers is one of them. And it's kind of fun to use them via libpython-clj So I never used djl itself, neither teh clojure wrapper of it.

has a plugin concept for models, and the plugin which uses SMILE models is here: https://github.com/scicloj/scicloj.ml.smile Basically we can integrated everything into which has a concept of "train" and "predict" nad is based on tabular data. There is as well a plugin which integrates all sklearn estimators: (it uses libpython-clj internally) https://github.com/scicloj/sklearn-clj So you can do "pipelines" which mixes python and Clojure / java models / estimators

The "wrapping" approach I followed, is based on "wrapping" a "interface", not a concrete model. In sklearn and SMILE all models have the same "interface". So we wrap "one time", and avoid the issue of "following a moving target".

I see, thanks for the intro to that, that's all very sensible.

Yeah DJL is a java thing. It had "deep learning" in the name, hence I asked 😉

I am interested in deep learning in particular, what do you think is the most prominent approach for that in Clojure? I've seen clj bindings to big frameworks like mxnet, but it looks like they're deprecated in the new v2 api unfortunately...if you want to access deep learning frameworks, is python-interop the way to go?

Sry I ask that when you say you haven't used DJL... Nice to hear python interop works atleast, then I know thats one alternative.

If I would do deep learning with Clojure, I would pick any of the "big ones", (deeplearning4j, mxnet, djl) but the Java version (not use a Clojure wrapper) Then I would solve my concrete problem with Clojure->Java interop, likely "isolating" the Java Interop code in some namespaces and give them a "clojure friendly interface". (Maybe even do this in .java files, using a java IDE) So create java classes with some public static methods, which are "clojure friendly". (So I can use feature of a Java IDE) -> a mixed Clojure + Java project. So I would develop a "wrapper" (adhoc), but only for the parts I use. (which is hopefully a small subset of the features of the big framework) This is the same I always do when I use a Java library from Clojure. So the wrapper would be "problem dependent", so for sure not reusable or general and used in a single project only.

Cool idea, I'll keep that approach in mind :)