Hello Jony It would be nice to make some cooperation between the Gorilla's Charsts & Incanter's. Right now, there is discussion in Incanter mailing list, about implementing different backends for charts, so it would be possible to generate them for JFreeChart, D3, etc.
On Sun, Feb 23, 2014 at 6:22 PM, Jony Hudson <jonyepsi...@gmail.com> wrote: > Hi, > > thanks again for the kind words and enthusiasm! Let me try and give my > thoughts on some of the points raised: > > ** Light table plugin (@Patrik) ** > > I would like to see this, as I think LT has a lot of potential. Things > like file-handling UI, nice code editing ... are all difficult problems > that I've not really tackled in Gorilla. Light table has those already, so > I could see it working well. I haven't the foggiest how to do it though! > > > ** Extensible (@Jeff) ** > > Yes, it's good to say this explicitly as I think this is key. At the > moment it's very poor in that regard. Before it happens I think the central > thing to pin down and get right is ... > > > ** Value rendering and interaction (@Jeff) ** > > This, to my mind, is the place where real design decisions have to be > made. There are some free-floating ideas in my head, but nothing really > joined-up yet. > > If we leave aside interactivity for a minute: the one thing that is clear > to me is that having the back-end return plain old Clojure values is a > *good idea*. Things you run just produce values, and the front-end knows > how to present values in a way that's helpful to the user. There should be > no state in the front-end that can be accessed by the back-end, no > messaging etc. This I see as the central idea. It's what makes it possible > to compose plots, (and hypothetically) append tables, make a tree-diagram > with plots as nodes, display formulae in tables etc. Because everything > displayed by the front-end is just a Clojure value, and you can manipulate > those as you wish. > > Ultimately, everything has to end up as something the browser can display. > At the moment, all of this conversion is happening in the browser. I had > resisted having this conversion happening in the back-end because I was > nervous about having the front-end evaluate things on the back-end that the > user hasn't explicitly asked for. But maybe that isn't a problem as long as > the rendering functions are tastefully written (i.e. side-effect free). So > maybe what Jeff suggests is the right idea: allow rendering on the > front-end or the back-end, and make these renderers easy to plug in. > Back-end rendering works well for extensibility too, as renderers could be > plugged in as needed per project. Extending the set of renderers on the > front end, looks less clean - either they'd be baked in, or there'd need to > be some way to inject them at runtime. Perhaps the preference should be for > back end rendering, with a small set of standardised renderers on the front > end? It's still unclear to me how the wiring will work - I think I probably > have to prototype something (maybe table rendering) and see how it looks. > > As for interactivity, I think this is a really tricky one. Wolfram, with > Mathematica, have done a _really_ nice job with this. In case you're not > familiar, the heart of it is a dependency-tracking, reactive variable > system (Dynamic[]). And on top of this they've come up with a nice language > for describing UI. It's extremely impressive, but it's also a pretty large > engineering effort I think. I wonder whether a more modest goal might not > be the right thing to try for (given I don't see us bringing the same > resources as Wolfram to bear on the problem!). I found with monkeycruncher > that you can get almost all of what you might want to do regarding > interactivity with a much more restricted mode of interaction. It had a > "Bret Victor" style "live mode" where you could edit the code and see the > results change live. It also had some neat UI (sliders, colour pickers) to > edit parts of the code fluidly. I found that this worked really well, and > it fits very well with the idea above (edit code, automatically > re-evaluate, generates new value, new value is rendered). > > I'd love to hear your thoughts on all of this :-) > > > ** Implementing client in Clojurescript (@Jeff) ** > > Yes, cljs etc would probably have been a very good fit. But I already had > some code and plenty of experience with javascript and knockout.js (which > is a very lovely piece of software IMHO). I'd be disinclined to port it to > cljs unless there was a compelling reason to do so! > > > ** Core.matrix (@Mikera) ** > > Yes. Definitely should happen! > > > ** Load/save problems (@Fabian) ** > > I can't reproduce this on my machine (Mac OS) with Chrome. It doesn't save > into non-existent directories, but it does give an error message for me on > this. I can load/save worksheets to the root directory. Can you confirm you > can reproduce the problem, and if so perhaps file a Github issue with > details of your setup? > > > ** MathML support (@mmower) ** > > I think this already works, as in I can paste in some MathML and it > renders as a formula. It's so horrible compared to laTeX though I don't see > why you'd want to do it! Get revising that laTeX :-) > > > A long post! Love to hear your thoughts, and thanks for the support :-) > > > Jony > > -- > 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/groups/opt_out. > -- With best wishes, Alex Ott http://alexott.net/ Twitter: alexott_en (English), alexott (Russian) Skype: alex.ott -- 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/groups/opt_out.
