neat! will check it out!

I'm happy to answer your questions

@tsulej , are the plots themselves reified?

@smith.adriane can you elaborate a little bit what do you mean by reified plots?

Generally plots are represented by nested maps consisting data, scales, aesthetics, configuration + some functions (this means that these are not pure data). Based on above you render chart on canvas as a separate step.

basically just wondering if there is a data model for the charts/graphs/etc.

kind of, but rather generated and not simple to write by hand. I'm going to change it though.

what I would be looking for is some sort of data model that does a good job describing different charts. it doesn't really matter if the descriptions are meant to be produced by hand.

eg. • here's all the type charts • here's the data they can expect • here's all the different ways to customize them • maybe some specs for the chart descriptions and the acceptable input data

vega/vega-lite does it perfectly well

It matters less to me if there are actually implementations of drawing all of the charts. I've been working on this graphics library for a while, https://github.com/phronmophobic/membrane and would love to just implement the graphics for a given chart spec library

There was discussion to introduce vega/vega-lite spec to cljplot, but first I need to make rendering backend closer to this (if it's possible, I don't know)

vega* requires a whole ecosystem of non jvm stuff and it's unclear how extensible it is from clojure land

but vega contains well defined specification which can be adopted to other backends

how many backends do they have?

I focused mostly on rendering at the beginning and stopped there since I hit the dead end with data manipulation and data dimensionality representation (called aesthetics in ggplot2 or enconding in vega*)

they have one backend 🙂

Vega advertises itself as a grammar or language, the rendering engine comes at the end of the desctiption

i actually have a copy of the grammar of graphics that I haven't read yet

me too

yea, it definitely seems like a good starting point, but I am wary of large specifications that only have one implementation. it makes it very easy for the spec and the implementation to start to bleed into one another

https://github.com/vega/schema/blob/master/vega-lite/v4.14.1.json

true

and it's huge

personally I prefer ggplot2 approach but nothing stops one to build another, grammar level on the top of rendering library to store/exchange/reuse chart description

hmm, https://github.com/rstudio/cheatsheets/blob/master/data-visualization-2.1.pdf seems cool

it is, but it's highly declarative: map data and add this, add that etc.

declarative sounds great. in clojure, that's just data

The key thing for Vega and Vega-Lite is these things are interactive - they are not simple static things lke ggplot2. If all you want is ggplot2 like stuff, then a good way now may be to just use ggplot2 via Clojisr

what's the support like for adding interactivity to a vega-lite plot via clojure?

It comes for free

like if I wanted to add a custom interaction?

there is something like signals: https://vega.github.io/vega/docs/signals/

Depends on what it is. There is a lot of support for that in Vega-Lite

(and event streams)

And in Vega as well (since Vega-Lite compiles down to Vega)

It doesn't cover all aspects - for example, various external controls that depend on recomputing the input data are not typically covered

I will have to take some time to digest all this

if you want to see reimplementation of vega-lite or lattice (R) examples in cljplot- take a look here https://github.com/generateme/cljplot/tree/master/sketches - I made it to test my concepts (even with kind of interactivity through java2d)

yea, I've been poking around with that

but as I said cljplot shouts for deep refactoring

That sort of 'interactive' control requires some form of reactive components coupled to the data streams TBH, it is really difficult to 'compete' with what the IDL folks are doing. They have a lot of resources and a boatload of talent

this is deep true

that's true, but I feel like I would also be giving up a lot of control. Like I don't think it would have been difficult (not impossible) to make this project using vega-lite, https://blog.phronemophobic.com/treemap/treemaps-are-awesome.html

Any time you opt for some form of 'declarative' coding, you give up control. Vega sits on top of D3 as its primary backend, It gives up the total control you have in D3, but you get back a great deal in the form of consistency simplicity (I know - Vega does not seem simple, but compared to D3? yeah)

Vega-Lite also give up some control as it is layered on top of Vega and targets simplifying a lot of the nuts and bolts of generating a simple chart (kind of like ggplot2 in that regard)

I think you can do what looks like declarative coding in clojure that is really just manipulating data. my experience is that you get a lot of the benefits of declarative coding, but you still retain the flexibility

I don't think tree maps are available in Vega-Lite (yet), but they are definitely in Vega: https://vega.github.io/vega/examples/treemap/

Only up to a point. Otherwise you wouldn't 'need' things like core.logic

the treemap project wasn't about drawing a traditional treemap, it was about augmenting the treemaps in different ways, including interactivity

Functional stuff often looks declarative but it really isn't. There is still an explicit flow

well, you have interactivity for free in vega

we might be talking about different things with respective to writing declarative code in clojure. what I'm referring to is when you're working with just data. data has no explicit flow and hopefully, the what is decoupled from how