[HN Gopher] Moldable Live Programming for Clojure
       ___________________________________________________________________
        
       Moldable Live Programming for Clojure
        
       Author : simonpure
       Score  : 85 points
       Date   : 2023-06-18 14:35 UTC (8 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | fayten wrote:
       | Clerk has some pretty detailed documentation that is worth
       | looking over: https://book.clerk.vision
       | 
       | Emmy and Clojure2d have also adopted clerk for their docs with
       | impressive results:
       | https://clojure2d.github.io/clojure2d/docs/notebooks/noteboo...
       | 
       | https://emmy.mentat.org
        
         | sritchie wrote:
         | Thanks for the Emmy shout-out!
         | 
         | Clerk has been fantastic for rendering 2D and 3D... I just
         | finished a 3D graphics API and am frankly blown away at how
         | great Clerk made this experience.
         | 
         | Here are my recent 3D rendering "tester" Clerk notebooks (over
         | MathBox), for fun:
         | 
         | - https://emmy-
         | viewers.mentat.org/dev/examples/manifold/pq_kno...
         | 
         | - https://emmy-
         | viewers.mentat.org/dev/examples/mathbox/functio...
         | 
         | - https://emmy-viewers.mentat.org/dev/examples/manifold/fdg
         | 
         | - https://emmy-
         | viewers.mentat.org/dev/examples/manifold/pq_kno...
         | 
         | And another Clerk notebook with a bunch of calculus etc in 2D
         | scenes, over Mafs.dev:
         | 
         | - https://emmy-viewers.mentat.org/dev/examples/mafs
        
       | 082349872349872 wrote:
       | > [it eschews] _Reproduction problems coming from out-of-order
       | execution_
       | 
       | Wouldn't immutability and lexical scoping go a long way here?
       | What am I missing that would explain why notebook people (in
       | general, not this project) have not long ago decided that
       | exposing execution order is a bug?
        
         | thom wrote:
         | I do like the idea of more hierarchical notebooks. Traditional
         | top to bottom notebooks are a recipe for bugs and
         | reproducibility issues, but so is working too much in the
         | Clojure REPL so I'm surprised to hear it here. But obviously
         | you need _some_ way to avoid reloading all data and retraining
         | all models on every change.
        
         | slowmovintarget wrote:
         | There is an expectation of top to bottom, in-order execution
         | from a notebook. The point of it being a "notebook" is that
         | it's like a scientists journal where they write the equations,
         | solve them, write notes on the solution, and proceed from
         | there.
         | 
         | The execution order is implied from the skeuomorphism of the
         | notebook form.
         | 
         | This is why the notebook paradigm is not generally suitable for
         | software development. They're well suited to using code to get
         | answers from data, for learning, and for trying things out. But
         | you wouldn't use them for building your next SaaS product
         | (unless that product is a site for hosting notebooks..., or
         | you're making Mathematica).
        
       | hlship wrote:
       | I've been using Clerk quite a bit lately and found it quite
       | useful. Although I'm normally in a REPL loop, having control over
       | the output ends up being very useful, and the ability to paginate
       | long results, or graph them, it's great.
       | 
       | I'm also using it for some Clojure mentoring/training, so
       | providing my mentees with runnable, changeable examples to
       | explore jumpstarts their understanding.
       | 
       | I wish I could share images easily here; one of my exercises is
       | looking for a solution to a chess puzzle on a 4x4 board. The
       | board state is a map, but with a little meta-data, Clerk will
       | present it as a 4x4 chess board (that is, there's a function that
       | renders the board map to HTML which is presented).
       | 
       | Under the covers, Clerk is doing a lot of work to analyze each
       | code block in a notebook, to determine dependencies so that it
       | can efficiently recalculate changes and control execution
       | ordering.
        
         | thom wrote:
         | Ah so it's not just rerunning too to bottom each time? It just
         | works out changes and runs from there forward?
        
           | hlship wrote:
           | Yes, and it caches results on the file system, so results
           | persist between executions AFAIK. That comes in handy for one
           | of my notebooks that has to slurp up Splunk data for 20
           | minutes.
        
             | thom wrote:
             | Nice, yeah, I am not a fan of retraining models on my
             | workstation in the UK's current heatwave.
        
       | koito17 wrote:
       | Clerk is nice, but I'd like to point out Nextjournal offers a
       | free-tier service and makes sharing and collaboration pretty
       | effortless. It behaves like Clerk except it's "contenteditable",
       | so to speak, and you don't need any local setup.
       | 
       | It's a really nice way to introduce people Clojure without
       | needing them to download anything (not even a text editor) and
       | get started playing with data.
        
       | sleepycatgirl wrote:
       | Clojure is a cute lisp, and lisp is cute. So.. Double cute? (Even
       | if I very much prefer CL, Clojure is still a comfy option
       | nonetheless)
        
       ___________________________________________________________________
       (page generated 2023-06-18 23:01 UTC)