[ANN] Session 0.1.3 - A live-coding environment for Clojure

[kovas boguta]

Session is a live coding environment, built on Datomic and Om.

repo: https://github.com/kovasb/session
video: https://vimeo.com/89899023
blog post: https://medium.com/p/1a12997a5f70

I've been working on Session for some time, but have held off on a
formal announcement for the simple reason that it was not clear that
its design was capable of delivering on its ambitious goals.

Om, and the principles behind it, are a game-changer for projects like
Session. After rewriting Session in Om, its pretty clear that this is
going to work. Om was the missing piece.

As reflected in the version number, Session is still very alpha. But
with foundational issues finally out of the way, I'm happy to announce
this as an active project rapidly moving forward.

Shout-out to my KTC studio-mates David Nolen and Tims Gardner, who've
been very helpful getting to this point.

Here's to hoping this thread won't be filled with bug reports about
installation issues :)

-Kovas

[Paul Mooser]

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 ? 

[adriaan...@gmail.com]

Woow

Looks very attractive. Let's see if I can put this to good use in the near future :)
How easy/feasible would it be to get this running in Light table as a plugin (which is node-webkit based) ? Would the underlying archtecture of session allow this? You would get some nice text editing and other project managment features bassicly for free.

greetz

Op maandag 24 maart 2014 21:02:07 UTC schreef Paul Mooser:

[kovas boguta]

On Mon, Mar 24, 2014 at 5:02 PM, Paul Mooser <taro...@gmail.com> wrote:
> 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 ?

Session uses Om, https://github.com/swannodette/om

You should definitely check it out to understand the rendering model.

Session's renderer is entirely client side, and in clojurescript. This
is a plus in the simplicity column.

The software engineering of actually adding new renderers to session
is a (temporary) pain, which is a minus. (Basically you need to clone
yantra, https://github.com/kovasb/yantra, and used that cloned copy in
Session).

The main difference is that Session's renderer exposes the full power
of the browser platform. You can do arbitrary, interactive,
client-side stuff. That is difficult to pull off if you are sending
bits of HTML from server to client.

One thing I really like about Om is that there is no intermediary
format/layer between the user-facing API and the platform. In
Mathematica, and in Gorilla, there is a base layer of primitives that
the user compiles to, and then the system interpretes in terms of the
platform. In both cases, the system is a black box from the point of
view of primary language; if the system doesn't provide a primitive,
you have to pop open the black box and deal with a completely
different world (C++ in Mathematica's case, Javascript in Gorilla's).

In Om there is no black box or impedance mismatch. Just clojurescript
programming all the way down to the platform's capabilities. The user
can create constructs at parity with the built-ins.

[kovas boguta]

On Mon, Mar 24, 2014 at 5:18 PM, <adriaan...@gmail.com> wrote:

> How easy/feasible would it be to get this running in Light table as a plugin
> (which is node-webkit based) ? Would the underlying archtecture of session
> allow this? You would get some nice text editing and other project managment
> features bassicly for free.

Good question!

Maybe an expert in LT can chime in? I'm not familiar enough with the
internals to judge, and hoping if this is possible then the community
can take the lead in making it happen.

Session does have some requirements: A JVM to websocket against, and a
datomic transactor to connect to.

I would also be *quite* happy to just reuse LT's paredit widget in
Session, but have no idea how to make that happen.

[John Jacobsen]

As a refugee (spy?) from the Python community, it's very exciting to see something similar to iPython Notebook, but based on / supporting the Clojure ecosystem.  iPN has been making shockwaves in the Python world and in scientific computing in general for some time.

Having only watched the video and skimmed the blog post so far, my first thought is that it would be nice to see support for rendering Markdown and math formulae (TeX), like iPN has.  Any thoughts about how this might be accomplished?

Really looking forward to playing with this and seeing it grow.

John

[Gaofeng Zeng]

gorilla-repl and session is very cool, I can use it in our log data statistics. thank your!

[Sven Richter]

Hi,

This looks pretty awesome. Do you plan to integrate some authentication mechanism. I just imagined running session on my server and being able to access it from everywhere around the world, always having a repl available instantly.

But obv. I dont want everybody to access it.

Best Regards,

Sven

[kovas boguta]

On Mon, Mar 24, 2014 at 9:53 PM, John Jacobsen <eigen...@gmail.com> wrote:
> Having only watched the video and skimmed the blog post so far, my first
> thought is that it would be nice to see support for rendering Markdown and
> math formulae (TeX), like iPN has. Any thoughts about how this might be
> accomplished?

Hi,

The answer is: Om widgets! It is very easy to incorporate an Om widget
into Session.

So you if you want some new kind of display format, like for formulas,
make an Om widget for it and do a pull request for me to add it into
Session.

Sometime this week I'll document the internals a bit, so that it will
be clear how to add new widgets directly into Session yourself just by
forking the repo etc.

> Really looking forward to playing with this and seeing it grow.

Awesome :)

[kovas boguta]

On Tue, Mar 25, 2014 at 6:09 AM, Sven Richter <sve...@googlemail.com> wrote:
> Hi,
>
> This looks pretty awesome. Do you plan to integrate some authentication
> mechanism. I just imagined running session on my server and being able to
> access it from everywhere around the world, always having a repl available
> instantly.
> But obv. I dont want everybody to access it.

Hi,

Yes, absolutely. I have the same use case (except the server being in the cloud)

I also want to support a workgroup-type setup. A group of people
sharing a global index of sessions & data, doing computations and
sharing amongst the group.

Having Datomic on the backend really simplifies making this happen,
since it provides a place to put all that user info.

I imagine making something password protected could be as simple as
transacting a datom into Datomic.

[Jony Hudson]

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

[kovas boguta]

On Tue, Mar 25, 2014 at 3:05 PM, Jony Hudson <jonye...@gmail.com> wrote:
> 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.

I'm highly in agreement with this POV.

The way most JS libraries to do it, which is you supply a DOM element
to the lib and then it populates it with more content, drives me
completely insane. It makes things impossible to compose or
algorithmically generate, you gotta write logic yourself to built up
the structure and tie everything together.

> 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

I think this is a real benefit of the Gorilla way. You can create
renderers at the REPL itself, since the rendering happens within the
same evaluation environment.

I think this is a sound idea, and not necessarily an either/or choice.
I'm thinking about a way to have some form of rendering within the
evaluation environment as well, but it requires more hammock time. One
obvious use case is elliding large outputs.

Also, it would be pretty interesting to see if Session's renderers
could be reused inside Gorilla. It would be great if we could
standardize on the rendering side of things, so content created in
these systems can flow between them.

Anyway thanks for chiming in!

[Marc Limotte]

I do like that Gorilla is distributed as a lein plugin, so I can easily start it up in the context of my project alongside my classpath and my code.  Would a plugin make sense as an option for Session?

marc

--
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
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
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.
For more options, visit https://groups.google.com/d/optout.

[kovas boguta]

If someone can figure out how to include the datomic transactor within
a lein plugin, then its a possibility that can at least be considered.

Overall though, I'm not sure its worth the effort. Session is more of
a standalone app, like Light Table. If anything, the packaging should
move towards that scenario, rather than the other way.