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.

Reply via email to