vega-lite VS py4cl

Box zoom would need to be added to Vega-Lite first, and there has been some discussion around it in https://github.com/vega/vega-lite/issues/4742. Bottom line is that there's nothing blocking its implementation, someone just needs to do the work in Vega-Lite. And once released in Vega-Lite, Altair would pick it up automatically with how we generate the Altair API from the Vega-Lite schema.

I also have difficulties with Gnuplot and Matplotlib. I like Vega that allows me to create visualisations in a declarative way. If I really need something special I go with d3.js, which had a really steep learning curve but with ChatGPT it should have become easier for beginners.

[1] https://vega.github.io/vega-lite/

To ensure you do not miss this: LiveBook comes with a Vega Lite integration (https://livebook.dev/integrations -> https://livebook.dev/integrations/vega-lite/), which means you get access to a lot of visualisations out of the box, should you need that (https://vega.github.io/vega-lite/).

In the same "standing on giant's shoulders" stance, you can use Explorer (see example LiveBook at https://github.com/elixir-explorer/explorer/blob/main/notebo...), which leverages Polars (https://www.pola.rs), a very fast DataFrame library and now a company (https://www.pola.rs/posts/company-announcement/) with 4M$ seed.

Nice, would be nice to have it integrated in GitHub markdown.

Looks similar to Vega or Vega-lite(https://vega.github.io/vega-lite/). Definitely as rich as D3.js but gets the job done for simple visualisations.

Vega-lite can do this https://vega.github.io/vega-lite/

The underlying data is from an online betting site. Data analysis was done in Python and I used Vega/Altair for the visualisation.

I have a bunch of data that I want to plot. I'm using lisp-stat, which is pretty good, for data frames and analysis. However, lisp-stat uses vega-lite for plotting and to put it mildly, vega-lite is fucking awful.

I wish the author all the best in developing his library; at the moment it seems quite incomplete, so if you want SVG charts today, I recommend Observable Plot[1] or Vega-Lite[2]

[1]: https://github.com/observablehq/plot

[2]: https://vega.github.io/vega-lite/

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.