Inspiring a future Clojure editor with forgotten Lisp UX - Shaun Lebron
ClojureTVCited 3× on HN, 2017–2019
talk · intermediate · evergreen · 2017–2019 on HN
Shaun Lebron surveys 50 years of Lisp editing history and forgotten innovations in structural editing. He argues future Clojure editors could learn from them, and covers ideas like Parinfer.
HN cites it as a summary of known attempts at structural and Lisp editors.
Up next
18 mo on HNRuby Conf 12 - Y Not- Adventures in Functional Programming by Jim Weirich
Confreaks
Recommended 17× on HN · 2013–2026
14 mo on HNThe Soul of Erlang and Elixir • Sasa Juric • GOTO 2019
GOTO Conferences
Recommended 16× on HN · 2019–2024
14 mo on HN"Simple Made Easy" - Rich Hickey (2011)
Strange Loop Conference
Recommended 14× on HN · 2022–2026
13 mo on HN"Making Impossible States Impossible" by Richard Feldman
elm-conf
Recommended 9× on HN · 2017–2026
12 mo on HNWilliam Byrd on "The Most Beautiful Program Ever Written" [PWL NYC]
PapersWeLove
Recommended 11× on HN · 2017–2026
11 mo on HNThe Value of Values with Rich Hickey
InfoQ
Recommended 10× on HN · 2014–2023
12 mo on HNWhy Isn't Functional Programming the Norm? – Richard Feldman
Metosin
Recommended 12× on HN · 2019–2025
11 mo on HNMaybe Not - Rich Hickey
ClojureTV
Recommended 14× on HN · 2018–2025
11 mo on HNSolving Problems the Clojure Way - Rafal Dittwald
Clojure/north
Recommended 10× on HN · 2019–2025
10 mo on HNLecture 1A: Overview and Introduction to Lisp
MIT OpenCourseWare
Recommended 10× on HN · 2019–2026
10 mo on HNConway's Game Of Life in APL
Dyalog
Recommended 11× on HN · 2010–2024
9 mo on HNLecture 1A | MIT 6.001 Structure and Interpretation, 1986
MIT OpenCourseWare
Recommended 11× on HN · 2012–2024
3 comments from Hacker News
Using a Lisp with Parinfer makes the parens automagic without taking away the benefits they provide. link ▶ this video
That's a great suggestion. Which attempts are you familiar with? The ones I'm familiar with are summarized in this talk: ▶ this video
This is called 'projectional editing', an idea that to my knowledge goes back to the 60s. A projectional editor shows you both the original source code, and alternate representations (or, 'projections') of it. Given the right plugins and config, these alternate projections could happen to be more intuitive to grasp/edit than the original source code. One plugin could, for example, remove all the unnecessary semicolons. Another, could remove all the unnecessary punctuations and project the code in an indentation-significant way or vice-versa. Your idea to replace all the `'bar' + foo`s with ``bar{foo}``s would also be possible. It's easy to imagine much more advanced use-cases. A sufficiently advanced editor could detect calls to FRP libraries, and project the data flow as a visual graph (picture all the `flatMaps()` and `scanLatest()s` as nodes on that graph). Or, given access to compile-time type info (via a typescript-style language-server), it could overlay the type of a value with the missing fields being shown as slots to be filled. I can imagine such an editor to mostly "obsolete" the idea of a single syntax for each language in the first place. Like the language but not the syntax? Roll your own syntax! Just configure your own editor plugins. No one would have to know. No one would have to agree with your "taste." Not even your git repo [0]. (See /r/nosyntax/ for more ideas) A projectional editor can also be implemented in the runtime, ala Smalltalk. In that case, the