Hi Lucas, I think, regarding integration with Gorilla, the real decision to be made is around interactivity. For non-interactive charts, it would be ideal to separate out the code that generates the chart from the code that messes with the DOM. Gorilla would then just use the charting code, and do its own DOM manipulation. It would probably also be ideal if the charting code ran server-side (CLJ) for Gorilla's purposes.
It sounds, though, that this is probably not the goal for your library. If you are aiming to build something that can handle interactive visualisations, and handle changing data, then I guess there's going to be much more interaction between the charting code and the DOM manipulation code. I'm not sure how that would fit in with Gorilla - but as a general design point (which would also ease Gorilla integration) there might be some value in making the interface between "charting" and "DOM manipulation" explicit, so that it is possible to plug in different approaches to DOM manipulation. That's not to say that this is realistically possible, just that I'd put it on the wishlist :-) My current plan with Gorilla was to steer clear of interactivity, for two reasons: one, that for the sort of stuff I do myself, it's not really that useful (or, as I've said before: the interactivity you already get at the REPL is plenty); and two, because it looks like it's really, _really_ hard to get right! That said ... I recognise that people do do things that would be improved by interactivity, so if it is possible to make it work cleanly, then it is something I'd be keen to support in Gorilla :-) Jony On Sunday, 14 December 2014 12:26:17 UTC, Lucas Bradstreet wrote: > > Hi Jony, > > I'm a fan of Gorilla REPL. I'd love to have this work supported with > it. Is it easy to support Clojurescript based renderers within > GorillaREPL? It would be nice to support interactive figures with this > kind of use case (in addition to SVG based plots, of course). > > From the responses thus far, it appears that ggplot is the gold > standard for composable, customizable charts. Once we get the > dataframe format right, I'll invest some time into learning what I can > from it. We certainly want any implementation to be as data driven as > possible. > > Thanks, > > Lucas > > > On 13 December 2014 at 22:42, Jony Hudson <jonye...@gmail.com > <javascript:>> wrote: > > I think it would be great, and a very useful contribution to the Clojure > > world, to have a flexible plotting library. My perspective, at risk of > going > > a bit off-topic, and from the biased position of a Gorilla REPL author > ... > > > > > > When I think about the sort of programming I do as a scientist - data > > analysis, modelling, numerics, statistics - I have a few requirements: > > > > > > - For me, having a notebook interface is essential. It's how I think. > It's > > the interactivity of the REPL, plus rich output, plus note-taking. > > > > - I'd like to write my code in a civilised language. Ideally one that > puts > > data first, because that's at the heart of the problems I solve. > > > > - I want to be able to make things run fast when I need to. So I need > some > > ability to write "low-level" code on occasion. > > > > - I'd rather not re-write the whole world, so libraries are good. > > > > - I want to be able to plot things the way I want them. > > > > > > If I think about the possible contenders, written as (Notebook > interface, > > language, low-level language escape hatch) then the ones I'm familiar > with, > > and are advanced enough to use day-to-day for work, are: > > > > > > (Gorilla REPL, Clojure, Java) > > > > (IPython, Python, C) > > > > (R, R, C) > > > > (Mathematica notebook, Wolfram language, > > sort-of-C/sort-of-Java/sort-of-.NET) > > > > > > In terms of the interface, obviously Gorilla REPL is the best of the > bunch > > :-) From a language perspective, my opinion is Clojure/Java wins this > > hands-down. Preaching to the choir here, but Clojure is great for > > data-oriented programming, and importantly for me, it's _really_ easy to > > drop into Java when it matters. Library-wise, all are strong. Each has > their > > own advantages, but I'd say the Clojure/Java ecosystem has enough that, > for > > what I do, I rarely get stuck. For plotting Mathematica and R are > leagues > > ahead. I'm not familiar with the latest developments in Python, but last > I > > looked I didn’t see anything doing it the way I think it should be done. > > > > > > Which, brings me to why I’m sharing all of this unsolicited opinion … > it’s > > because I think a really strong plotting library would position Clojure > > alongside the very best environments to do science and technical > > computing/data science (or whatever it is we’re calling “thinking about > data > > with a computer” these days). Gorilla/Clojure works great for me, but I > do > > fire up R and Mathematica frequently for more advanced plotting. So, a > > full-featured plot library is something I’d love to see happen, and > would be > > interested in working towards. > > > > > > In terms of what such a library would look like, while there’s value in > > debating the best way to do it, there’s also value in copying the best > > that’s out there! So I agree with Matt that a ggplot2-alike emitting SVG > is > > a good thing to start with. ggplot2 does a great job of making plots > > composable, easily customised etc. And SVG can be rendered to anything, > and > > Gorilla supports it natively. The key point, to my mind, would be how to > > make the ggplot API more data-driven, rather than the OO approach that > it > > takes. > > > > > > So, to summarise my ramble: I think this would be great, and it’s > something > > I’d like to be involved with. I’d been planning to give some thought to > just > > this after the end of term. Although, I don’t know how that will work > out, > > realistically … if everyone on this list manages to do what they’re > planning > > to do over the holiday break then January will be a golden age of > Clojure! > > > > > > > > Jony > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clo...@googlegroups.com > <javascript:> > > Note that posts from new members are moderated - please be patient with > your > > first post. > > To unsubscribe from this group, send email to > > clojure+u...@googlegroups.com <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google > Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to clojure+u...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
