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.

Reply via email to