Any plan to extend oz? about oz

[BorisVSchmid]

FWIW, I like the vega-lite data spec as it broadens the pool of examples available online. There is a ton more vega or vega-lite written on the web than whatever a DSL would make of it.

[behrica]

I share the view, that an API layer is not worth the effort, maybe even counter productive.

The beauty of using vega-lite / vega from clojure is, that it can be expressed as pure nested clojure maps. I think using clojure keywords instead of strings, makes it even more readable. So writing your example above as clojure maps with keyword looks very good to me:

{ :data {:values dat}
  :mark  :bar
  :encoding {
    :x { :field  "a" :type  :nominal}
    :y  {:field  "b" :type  :quantitative}}}

An API would make sense in statically typed language, as then you could expect the auto completion in the IDE to work perfectly. But this is not the case for clojure.

[metasoarous]

Hi @randomizedthinking. Thanks for asking.

I have thought about this a bit, and am open to the possibility. However, my experience with constructor layers like Altair has been that they can be more trouble than they're worth. The abstractions have a tendency to break down as things get complicated, and as minimal as vega-lite already is, I worry that its a disservice to coax users into adopting some library specific api, rather than learning the underlying vega-lite.

For example, looking at the vegalite API and cutting out the unecessary details, I'm not sure the abstraction is really worth it's weight.

vegalite() %>%
  add_data(dat) %>%
  encode_x("a", "ordinal") %>%
  encode_y("b", "quantitative") %>%
  mark_bar()
 
{ "data": {"values": dat},
  "mark": "bar",
  "encoding": {
    "x":{ "field": "a", "type": "nominal"},
    "y": {"field": "b", type": "quantitative"}}}

Still, I'm open to hearing an argument in defense of something like this if any oz users care to make one.

[randomizedthinking]

I understand your point. My feeling is that even a thin layer of abstraction would help users to adopt vega/vega-lite. For your example, I think most users would prefer the abstracted one over the raw vega-lite data spec.

Given the underlying design of vegalite is very reasonable, it is up for discussion whether we would like to re-design or adopt a new DSL to wrap vega-lite data spec, or go with a direct-translation approach.

[metasoarous]

Thanks for chiming in @BorisVSchmid. You more clearly spell out the sentiment I had in mind when I said that "I worry that its a disservice to coax users into adopting some library specific api..."

I'm still not entirely closed to the idea, but I'm also unlikely to highlight such an API as the "way to get started", and would likely put such constructors in their own namespace (oz.builder?).

[randomizedthinking]

Agreed that vega-lite data spec is well designed. My personal feeling is that when there are advanced options like layers involved, it is not so straightforward to set the spec correct easily. @metasoarous, the oz.builder namespace could be an reasonable approach.

[metasoarous]

Layers are actually a great example of how things can go wrong here though. In Altair I once tried to create a visualization with two layers, each of which had a different data source, and while this is perfectly acceptable in Vega-Lite, Altair hadn't considered that use case in its constructors, and I couldn't get it to work without manually crafting the Vega-Lite by hand. So I guess this is all the more to the point of my reservation, which is that where constructors might have the most value (the non-trivial stuff) is precisely where assumptions are most likely to be violated.

Again, I'm not totally writing the idea off; Just highlighting why I want to consider it carefully.

Thanks again for bringing this up for discussion.

[metasoarous]

I agree @behrica.

@randomizedthinking Have you looked at Hanami/Saite's plot templating functionality? That's probably the closest thing to something I'd consider including in Oz. There are some ergonomics of that system I find a little offputting (all-caps in places), or I'd probably have tried it with Oz already. At the end of the day though, I haven't really needed something like it. But if there's inspiration to push something forward in this direction that meshes well with Oz, I'd consider it.

Thanks again folks!