On Monday, 24 March 2014 21:02:07 UTC, Paul Mooser wrote: > This looks great - I saw your talk at one of the clojure conferences, and > I'm glad you've continued to work on this! > > I'm curious as to whether your approach to rendering is similar to that > used in gorilla repl (http://gorilla-repl.org) ? Is it similarly > extensible ? >
Let me add my thoughts to this question, and more generally about the overlap between Gorilla and Session. I've chatted a bit with Kovas, so hopefully I won't misrepresent his ideas too badly here, but if I do he can always chime in a tell me I'm full of widgets :-) I'll probably end up saying more about Gorilla than Session here, as that's what I know more about. I think broadly, the renderers are going after things in the same direction: they both view values as primary, are not driven by side effects, and thus seek to capture whatever you want to view as a data structure. And they both respect the idea of composition and aggregation of values, by which I mean the way you aggregate things in the rendered output is just the way you'd aggregate the values. I think these are the core ideas which make both of the renderers powerful. We both abstract away the web-browser, but we do it in different ways. Gorilla tries to not replicate anything that the browser already provides, so gives Clojure code the power to write arbitrary HTML snippets (and a few higher-level pre-baked things like latex, vega), and compose them together with a very simple set of high-level operations. Essentially, the only new trick I'm teaching the browser is how to aggregate HTML in a way that respects and mirrors the way Clojure values work. Session take a different approach, which is to completely insulate Clojure code from the web-browser, by defining a Clojure-side grammar for everything that can be rendered. And then it backs this up by allowing the user to implement the elements of this grammar very neatly with Clojurescript/Om. I think both are interesting approaches, with different advantages and disadvantages. Specifically, with respect to extensibility, my aim with Gorilla was to make it as extensible as possible from the Clojure side, as I'm primarily interested in using it for pure Clojure work. As Kovas noted, this involves a compromise, in as much as the amount of interactivity in the rendered output is limited. For the sort of work I do (data analysis, statistics, modelling), interactivity of that sort is more gimmick than useful. Or to put it differently, the enormous amount of interactivity already offered by the REPL is enough :-) But I think for applications where this sort of interactivity is useful, then Session is really hitting the nail on the head. I think we'll see some really cool stuff coming up from it! More generally, for me at least, the stuff Kovas is doing with "loops" and computations being stored as database transactions is what's really exciting about Session. I've deliberately aimed with Gorilla to break no new ground, and keep stuff simple (in the Jony Hudson sense of simplicity, meaning simple enough that Jony Hudson can implement a working version in the small amount of time he has to do this!). I want something I can do my work with, and I've been using a notebook interface for long enough that I'm used to all of its warts. But I think the idea behind Session has the potential to open up new workflows that are more powerful than the 'notebook workflow'. The idea of notebooks being stored as collections of first class, computable data - so the results of one notebook can be used in another - and proper versioning of repeated interactions with the code are really, really interesting. I think it remains to be seen how they work out in practice, as there's also something nice about storing your notebooks as files which can go in version control, or attach to an email easily. But I think it's very exciting that Session is trying to go beyond the standard notebook idea. So, yeah, congrats to Kovas for getting this release out - I'm looking forward to seeing what comes from it :-) 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/d/optout.