Visual tools meetings (please comment)

[daslu]

This post is about Clojure visual tools. It will offer a plan for creating some dialogue around this topic.

TL;DR: We are looking to organize a series of meetings, and seeking some initial feedback – in the comments below and in the survey.

Here, by Clojure visual tools we mean interactive tools that allow their users to involve data visualizations in their Clojure workflows. There are quite a few active projects in this area, of different kinds and flavors.

The Visual Tools session (recording) on the re:Clojure Data Science Special (Dec. 5th) was about that. Seven tool creators spoke very briefly about their projects (@mauricioszabo: Chlorine/Clover, Chris Badahdah: Portal, @vlaaad: Reveal, @Christopher_Small: Oz, @daslu: Notespace, @jsa-aerial: Saite, Awb99: Goldly). Then, we had a discussion. We have had a similar session on May 11th, 2020, but this time it was public. This is only a partial list of the active projects in this area, who could make it this time on short notice.

Alongside the amazing creativity we have experienced, it was an opportunity to realize how important it might be to collaborate.

Each tool has its own special details. But there are a lot of common problems. Creating some common stack, or at least some layers of compatibility, would have a few benefits: the efficiency of code reuse, allowing users to seamlessly switch tools, and allowing us to grow a community-driven collection of visual components.
In addition to the dialogue between tool creators, at the Scicloj study groups and workshops we have met quite a few friends who were interested in learning more about the tools, and possibly contributing to them.
How could we support more dialogue between tool creators and with other friends in the community?

In this post, we’re suggesting a series of meetings to support that. It might be something like the following:

• A weekly study session. There, a group of interested Clojurians will meet to learn about tools and their internals, not only as users but also as potential contributors.
• A monthly open status meeting. There, tool maintainers can share their innovations, and discuss future directions.

This is just a suggestion – let us see what kind of agenda and periodicity might work.

What do you think?
Please comment on the survey and the comments below.

[prnc]

Fantastic!
This is a very interesting space with many avenues to pursue, some of the things that strike me as worthwhile (rough draft):

1. How to make the (end) user experience better.
2. Defining a set of abstractions and protocols around which collaborative effort can be built.
3. Bit more out there: Two way communication between text and visual
4. What is a specifically Clojure-idiomatic way of interacting with those tools e.g. I have preference for the visual following evaluation rather than rendering files etc.
5. How to go beyond notebook format
6. Lower barrier to entry: how do I integrate those tools for a general purpose programming in Clojure — so both technical aspects but also teaching, explaining, demoing etc.
7. How to leverage what we already have in Clojure for building open ended informational systems: protocols, multimethods, namespaced keywords, metadata, spec etc.
8. Organisational challenges — coordinating efforts across libraries as a community

This is just to summarise some things I’m seeing.
I’m mostly a grateful of all the existing tools that have already started explorations on some of those paths.

Thank you!

[prnc]

Oh, and also…
Given that those are “visual tools” I think it would be cool to involve some designers/front-end developers etc. which may mean going beyond the circle of the typical recipients of these messages.

So if you know any…

[Lukas_Domagala]

I’m coming into this as a code consumer of these tools, specifically omni-trace.
Up until now I have managed to get integration working with Portal, Reveal, Oz and Clerk without having to write too much tool specific code, because vega is already a common factor. What I’m trying to do next is communication from the tool back into the running jvm, which makes things a lot harder. The difficulty comes from the fact that cljs does not play well with other cljs and that there is no common way to create new views in those tools.
One of the “good” things about my difficulties is that I have read a lot of code inside all of the tools, so I hope I can help show where they do things similarly and where they could “easily” work together on common issues.

I really like the idea of common sessions, especially when it comes to making things a little more standardized where useful, so that clojure beginners can have an easier time understanding the space and new solutions can be built on top of existing tools.

[coconutpalm]

Topics:

• A common way to attach/enumerate/invoke visualizers for a value; a Specs; a Malli; a predicate; a java.lang.Class (and subclasses).
• Visualizers may use a windowing library (JavaFX/Swing/SWT) or may display in a web browser. We need to accommodate these use-cases at least by including an attribute on a visualizer “handle” with this metadata.
• Most of these tools need to walk cells, vars, or other Clojure constructs (let expressions?) and compute the dependency graph among these in order to support minimal recalculation. It would be nice to have a shared library for this.
• After computing the dependency graph, many of us would appreciate a data-flow/frp/cells library of some sort to actually perform the recalculation. React/reagent handle some of this in the browser but the problem is more general than this—particularly including server-side elements as well.
• If I store data in a database (let’s say Datomic, XTDB or similar), it would be really nice for that data to participate in the data-flow dependency graph. e.g.: when data is updated in the database, it would be nice for anything observing affected data to be automatically notified so it can recalculate/redisplay.
• Data-flow elements are dynamic. They come and go as the UI changes, as network connections change, when an autoscaler scales up/down, etc. Elements crossing network boundaries need to be tolerant of faults, timeouts, etc.

[coconutpalm]

Some of our tools include a browser-hosted Clojure code editor. This is another possible collaboration point. It sure would be nice for this kind of thing to grow into a Clojure-based pro-level code editor any of us would be happy to live in. Even if the foundation happens to be Codemirror 6.

[mauricioszabo]

Wonderful discussion, as always! So to address some of the points:

@prnc

• Defining a set of abstractions and protocols around which collaborative effort can be built.
• Bit more out there: Two way communication between text and visual

This would help my projects so much! For now, at Chlorine/Clover I have a request/response that renders a result. That result can call the REPL again, and update the state for the result, and that itself will update it. For “REPL side events” I have what I call a “patchable” result - if something returns a “patchable” result, it’ll be rendered but it can be “patched” in the future with newer data (at that way, the result can be updated without any request from the editor). I’m kinda refactoring everything right now so it’ll be easier to understand this code, and also customize it in any way too.

@coconutpalm

Some of our tools include a browser-hosted Clojure code editor. This is another possible collaboration point. It sure would be nice for this kind of thing to grow into a Clojure-based pro-level code editor any of us would be happy to live in. Even if the foundation happens to be Codemirror 6.

I would love to help on a hackable, browser-based, text editor for the browser if that makes sense :). Currently, the foundation that powers Chlorine and Clover does not depend on a specific editor in any way, so it’s possible to integrate everything that currently works on Atom and VSCode into this editor you’re doing

[coconutpalm]

Hi Mauricio,

Nextjournal has an amazing start already here.

My side project reimagines Clojure in a Smalltalk-esque way where everything is dynamic, indexed, and editable–including library dependencies. Ultimately I’d like the UI to be able to (safely) edit itself, which is where the browser-based editor widget comes in.

Status:

Auto-reload (via filesystem watch) works right now.

Dynamic library dependencies (based on Pomegranate though I keep flirting with porting over Boot’s pods) works. This enables each module to load its own dependencies at the top of the module’s root namespace–so modules’ dependencies are only resolved and loaded if that module is require’d.

NRepl (and cider) let you edit the program live right now.

The UI is in SWT so every platform has native widgets. SWT’s browser widget is Webkit so high fidelity, deep integration with the web / clojurescript ecosystem–particularly with self-hosted Clojurescript–is possible. That’s where I intend to drop Clojure/script editing.

Right now I’m working on the module/library/plugin system. I’ll probably extend Pomegranate to support Git dependencies but I haven’t decided for certain yet. (Maven dependencies aren’t well-suited to live editing. )

Next up after I finish this is browser integration and live editing.

They say Emacs is an operating system that happens to include a great editor. I think there’s a lot of wisdom in that quip. I want to get the foundation as close to “right” as possible so the editor can fall into place.

The code isn’t “released” to the community yet and is developed in my dot.emacs.d monorepo but feel free to take a look. It’s officially part of the fuse-code project. I currently use it as a handy code scratchpad.

-Dave

[daslu]

Hi.

Coming back to this discussion – we hope to organize something soon.

Following an inspiring discussion with @Lukas_Domagala, let us discuss for a moment the desired social platform we could use for our study groups and dev groups around visual tools.

In this post, I suggested my very opinionated view:
https://clojureverse.org/t/which-social-platform/
Comments and other views would help so much.

[daslu]

Following a chat with @Lukas_Domagala, just opened a #visual-tools Zulip stream and a Slack channel by the same name.

We hope Zulip will serve for study sessions, organizational memory, and ongoing discussions, and Slack will possibly serve for quick chats and an entry point for new friends.