Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What could a Clojure/LISP editor be like?

Rakhim
January 14, 2019

What could a Clojure/LISP editor be like?

Rakhim

January 14, 2019
Tweet

More Decks by Rakhim

Other Decks in Programming

Transcript

  1. Char editor (Notepad, DOS E) Text editor (vi, emacs, ed)

    Code editor (emacs, acme, vs code, sublime)
  2. Char editor (Notepad, DOS E) Text editor (vi, emacs, ed)

    Code editor (emacs, acme, vs code, sublime) Code editor + dev. env. (IDE) (emacs, vs code, atom, IDEA, Eclipse, Xcode, etc)
  3. Char editor (Notepad, DOS E) Text editor (vi, emacs, ed)

    Code editor (emacs, acme, vs code, sublime) Code editor + dev. env. (IDE) (emacs, vs code, atom, IDEA, Eclipse, Xcode, etc) Visual programming (Node-RED, Scratch, Modkit, Blocky)
  4. • Immediate feedback • Composition • Data flow • Encourages

    FP • Reducing accidental complexity Benefits of a visual approach
  5. • Immediate feedback → REPL • Composition → Higher order

    functions, natural composability • Data flow → it's just data!™ • Encourages FP → duh! • Reducing accidental complexity → we still have lots In the context of LISP/Clojure
  6. • Function promotion
 !#(bla %) → (fn [a] (bla a))

    → (defn real-foo [a] (bla a)) • if → cond • wrap in let, promote let • Namespaces, import • Refactoring • Simple: rename, replace function, change order • Complex: change flow, change data structure IDE level complexity Char editor (Notepad, DOS E) Text editor (vi, emacs, ed) Code editor (emacs, acme, vs code, sublime) Code editor + dev. env. (IDE) (emac/cider, IDEA/Cursive, Eclipse, Xcode, etc)
  7. • Not flexible enough • Not expressive enough • Either

    too simple or too niche • Mouse! Cons of a visual approach
  8. • "Inventing on principle", Brett Victor • "Inspiring a future

    Clojure editor with forgotten Lisp UX", Shaun Lebron • ProtoREPL Check out