dtype-next VS py4cl

Related (?): https://github.com/cnuernber/dtype-next/blob/master/test/tec...

Tablecloth by generateme is a friendly & expressive table-processing library built on top of tech.ml.dataset & dtype-next, Chris Nuernberger's high-performance data libraries.

There is one other detail here that I found out w/r/t arrays - Clojure's aset implementation returns the previous value; it isn't a faithful wrapper of the JVM's array set value instruction. Due to this if you are using aset on primitive arrays you end up boxing every value you are setting which at least in my tests leads to a performance disadvantage when compared to a tight loop using Java. This is why I have a specialized class implementing an aset that returns void.

If this is something common and the work is numeric, I would highly recommend exploring dtype-next buffer abstraction and tensors. The tensor api supports a nice APL-like substrate for working in index space without having to have the underlying storage "be" a boxed datastructure. You also get the option of off-heap / native tensors that can be zero-copy shuttled between other runtimes.

dtype-next - Major discoverability upgrades for the tech.v3.datatype and tech.v3.datatype.functional namespaces. Similarly to tmd, Cursive and Calva users now get full intellisense help with these main namespaces. Furthermore the FFI bindings now support linting with clj-kondo.

One thing about the readme that is incorrect - [dtype-next](https://github.com/cnuernber/dtype-next)'s ffi does in fact support callbacks :-). It is used as the backend to [libpython-clj](https://github.com/clj-python/libpython-clj) where you certainly can call clojure functions from python.

There are some interesting efforts concurrent with scicloj work by Chris Nuernberger specifically dtype-next, and the earlier tech-jna stuff. It's the same stuff underlying libpython-clj and libjulia-clj. recent talk.

This is great work. One of the things that has been on my mind working through our numerics stack is how to extend the number tower to complex numbers or more generally to arbitrary algebras. This project seems to me to be sort of a type-system-in-a-box that we can use to add arbitrary typing to Clojure where necessary/ideal. Thanks for sharing.

py4cl and cl4py rely on uiop:launch-program and python's subprocess respectively. These are portable to the extent uiop and subprocess are portable and do not require any additional installation.

If you want to use Python libs from CL, see py4cl: https://github.com/bendudson/py4cl the other way around, calling your efficient CL library from Python: https://github.com/marcoheisig/cl4py/ There might be more CL libraries than you think! https://github.com/CodyReichert/awesome-cl (or at least a project sufficiently advanced on your field to join forces ;) )

FYI you can call Python from CL: https://github.com/bendudson/py4cl and CL from Python: https://github.com/marcoheisig/cl4py/

If you don't know Emacs, see other editors: https://lispcookbook.github.io/cl-cookbook/editor-support.ht... If you want the more Smalltalk-like experience I'd go with the free LispWorks version: it has many GUI panes that allow to watch and discover the state of the program.

I personally couldn't stay long with Hylang. You won't get CL niceties: more language features, performance, standalone binaries, interactive debugger (all the niceties of an image-based development)…

I ended up using a fair bit of matplotlib through college and with colleagues. I too don't want to use python, but I also don't like throwing away its libraries, and I'm too lazy to invest in other* plotting ecosystems. In effect, I use up using matplotlib through py4cl/2.

Note that it is not my aim to replace the python ecosystem; I think that is far too lofy a goal to be of any good. My original intention was to interoperate with python through py4cl/2 or the likes, but felt that one needs a Common Lisp library for "small" operations, while "large" operations can be offloaded to python libraries through py4cl/2.

If performance is absolutely not a concern, then third option is using python libraries through py4cl/2. To put it differently, if calling python from lisp is not the bottleneck, then this is a feasible option.

I encourage people to try out Common Lisp because, unlike with Hy, you will get: speed, ability to build binaries, truly interactive image-based development (yes, more interactive than ipython), more static type checks, more language features (no closures in Hy last time I checked), language stability… To reach to Python libs, you have https://github.com/bendudson/py4cl My comparison of Python and CL: https://lisp-journey.gitlab.io/pythonvslisp/

> Not sure if such a thing already exists for CL

couple of solutions exist for this

https://github.com/bendudson/py4cl

https://github.com/pinterface/burgled-batteries

Ahh, makes sense. Well, if you ever wanna steal some of python's thunder, libpython-clj worked great for me lol. Supposedly py4cl fills a similar role in Common Lisp.