planck

Planck ClojureScript REPL
pyrmont 2019-05-25T12:39:18.001800Z

@mfikes I like what Ray did with pulling the shared code out of the repl namespace and putting it in a namespace both the REPL and the pREPL can use.

mfikes 2019-05-25T12:43:15.003200Z

Yeah, my long-term hope for Replete is that there can be one code path, all based on pREPL (to simplify maintenance). Of course, if that pans out for Replete, it could also be an avenue for pREPL in Planck. 🙂

pyrmont 2019-05-25T12:48:01.007700Z

I guess the ideal is that Planck becomes an evaluation library that basically handles the interfacing with JSC (and maybe low level things like sockets?) and then Replete maybe becomes a UI layer that supports UIKit, web, CLI, etc?

mfikes 2019-05-25T12:54:25.009500Z

@mike858 I suppose native Repletes could use Planck if Planck ever split off a library. But the idea for Planck splitting off a library is for the purposes of general use by any native application that wants to embed ClojureScript.

pyrmont 2019-05-25T12:55:34.009700Z

Gotcha.

mfikes 2019-05-25T12:56:09.010400Z

@mike858 The idea was first voiced by Bruce Hauman and David Nolen (evidently 4 years ago) in https://gist.github.com/mfikes/c7da1e7dfded26c7ceb9

mfikes 2019-05-25T13:00:02.010900Z

@mike858 I suppose there was no ticket for this idea. Now there is 🙂 https://github.com/planck-repl/planck/issues/936

mfikes 2019-05-25T13:03:15.012Z

That ticket, and https://github.com/planck-repl/planck/wiki/Hybrid-ClojureScript-Native-Libraries would be fundamentally new things in the world, offering value where there probably isn't currently a good solution.

pyrmont 2019-05-25T13:09:45.018200Z

Yeah, I confess my interest is probably a bit orthogonal to everyone else's. I'm attracted to the use of Planck on the server in ways that I think are probably duplicative of JVM Clojure. On the low-spec computers I use, JVM Clojure's startup is most certainly not in the sub-second range and I find it's a significant barrier to wanting to hack on code for small projects. Basically, I want an environment I can use in place of scripting languages like Ruby, Python, etc.

mfikes 2019-05-25T13:12:18.021Z

Yeah. One area that is very similar to that is the notion of protoyping "IoT" devices where you want to use Clojure, but you need an extremely tiny footprint. Along the lines of https://www.espruino.com, but probably perforce a little larger.

mfikes 2019-05-25T13:14:29.024800Z

(FWIW, ClojureScript won't work on the Espruino JavaScript runtime... it is not fully capable to handle the closures and other JavaScript emitted by the ClojureScript compiler.)

mfikes 2019-05-25T13:15:38.026700Z

But yeah, the ability to just write code and run it is key. The notion that ClojureScript is a compiler can be hidden, just like it is in Clojure.

pyrmont 2019-05-25T13:15:59.027500Z

I also think—and this is probably projection more than anything else—that something like Planck can be a great way for new users to get into Clojure. Planck is such a simpler and more pleasant setup experience and you're immediately able to start running code. Maybe as someone that studied at university in the early 2000s during the heyday of Java I'm scarred for life in a way other programmers aren't but I still recoil at needing to install Java to do anything. I realise so much of the power of Clojure comes from being able to tap into the Java ecosystem but, again, for small scale projects, I don't feel I need it and actively dislike needing to run it just to be able to execute Clojure.

mfikes 2019-05-25T13:16:55.028300Z

Yeah, Replete is also really good in the "it just installs and works" department, while also trying to simplify things even further for new users.

mfikes 2019-05-25T13:17:14.028700Z

Replete is in the MAS now, for crying out loud 🙂

mfikes 2019-05-25T13:18:33.031300Z

(Replete, Planck, Lumo, etc, are really all largely the same thing, sharing lots of common code, but with different UIs, VMs, etc.)

pyrmont 2019-05-25T13:18:50.031800Z

Speaking of duplication, I've actually been wondering the past week if there's a way Planck could be made to translate calls to certain Java libraries (really <http://java.io|java.io>) so that you could run code like Ring without needing to have it be rewritten.

mfikes 2019-05-25T13:19:14.032100Z

Yeah, I was thinking the same 🙂

mfikes 2019-05-25T13:19:34.032700Z

Maybe a --translate and then any use of <http://java.io|java.io> gets turned into <http://planck.io|planck.io> or somesuch.

pyrmont 2019-05-25T13:19:41.032900Z

Ha!

pyrmont 2019-05-25T13:19:48.033300Z

Yeah, that'd be cool.

mfikes 2019-05-25T13:20:06.034100Z

Another side-thought I had on that is that it might be doable as a separate library.

mfikes 2019-05-25T13:20:23.035Z

A <http://java.io|java.io> namespace that delegates to <http://planck.io|planck.io>, for example.

mfikes 2019-05-25T13:21:02.036600Z

That's essentially the pattern Andare took: It used the same napespaces to make core.async to work in self-hosted.

pyrmont 2019-05-25T13:22:25.039Z

And I've also been wondering (based partly on that hybrid libraries gist from David) the extent to which NPM libraries can be made more accessible from Planck. That is obviously duplicative of Lumo and that's probably what I should just be using but: (a) Lumo doesn't work on ARM; (b) I'm not much of a JavaScript programmer and find the JS in Lumo kind of impenetrable (to be clear, my fault).

pyrmont 2019-05-25T13:24:12.041100Z

Yeah, I didn't even think of replicating the approach Andare took but that seems like a simple solution :)

pyrmont 2019-05-25T13:24:48.042300Z

Yeah. David's talking about something else but since you linked it from an issue about NPM module use in Planck, I think that's why it got the gears turning in that respect.

mfikes 2019-05-25T13:25:53.043200Z

Right, anyone could publish a library that exposes a <http://java.io|java.io> namespace, but is meant to be used with Planck to implement it, by simply delegating calls.

mfikes 2019-05-25T13:27:15.044100Z

Another argument could be had for bundling something like that with Planck, but if it can be a separate lib, that might be worth trying first. Probably much simpler to pull off than https://github.com/abiocljs

pyrmont 2019-05-25T13:31:15.046700Z

Ha! I was thinking about the possibility of something like this and there you go—it already exists :) But yes, a separate library seems like a better first step.