Clojurians Log v2

@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.

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. 🙂

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?

@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.

Gotcha.

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

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

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.

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.

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.

(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.)

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.

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.

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.

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

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

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.

Yeah, I was thinking the same 🙂

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

Ha!

Yeah, that'd be cool.

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

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

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

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).

This gist? https://gist.github.com/swannodette/ebd8b65f887318ba68579b6bea911daf

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

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.

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.

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

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.