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

Victims of Complexity

Avatar for Bozhidar Batsov Bozhidar Batsov
June 08, 2021
300

Victims of Complexity

Originally presented on June 5th 2021, at ClojureD.

Avatar for Bozhidar Batsov

Bozhidar Batsov

June 08, 2021
Tweet

Transcript

  1. (ABOUT-BUG)  Bozhidar (Божидар) a.k.a. Bug  Devoted to Emacs

     Author of CIDER, maintainer of nREPL, blah, blah, blah  @bbatsov  bozhidar on the Clojurians Slack (#cider/#nrepl)  @bozhidarb on Reddit (long story)  metaredux.com  emacsredux.com
  2. CIDER 0.26 (AUGUST 2020, CLOJURISTS TOGETHER)  Support for nREPL

    0.8  Code completion  Symbol lookup  First class support for Babashka  Basic support for sideloading (functionality added in nREPL 0.7)  Smarter handling of ClojureDocs data (no downloads the first time you try to use it or automatic data updates)  Auto-trimming of REPL buffers (disabled by default)  Small improvements
  3. NREPL 0.7  Native EDN transport (an alternative to the

    default Bencode transport)  Added the ability to sideload Clojure libraries into a running nREPL server  Now clients can inject the libraries they need without the need for additional manual setup
  4. NREPL 0.8  Built-in completion op  Built-in lookup up

     Added the ability to load middleware dynamically
  5. A SINGLE CONNECTION  Ultimate simplicity  No configuration 

    No ambiguity  No flexibility  You can’t work on multiple projects  You can’t work easily on a ClojureScript project (typically people use two connections for those)
  6. MULTIPLE CONNECTIONS, STATIC DISPATCH  Very simple  No configuration

     No ambiguity  Only one extra command to mark the “current” connection  Some flexibility  You can work on multiple projects  You get to decide which connection to use when
  7. MULTIPLE CONNECTIONS, DYNAMIC DISPATCH  Quite complex  It’s not

    always clear which connection to use (e.g. you can have connections without project or two connections to the same project)  Grouping Clojure and ClojureScript connections together and deciding what to do about things like `cljc` files  Lots of flexibility  You can work on multiple projects  All sorts of workflows are supported out of the box
  8. SESSIONS, TAKE ONE  Quite complex, but supposedly less complex

    than before  Operate on groups of related connections (sessions) instead of connections  Lots of flexibility  You can work on multiple projects  All sorts of workflows are supported out of the box
  9. SESSIONS, TAKE TWO (SESMAN)  Quiet complex  Same as

    before, but now it’s a generic library for session management in Emacs  Session management becomes a third-party library  Less flexibility  You can work on multiple projects  Some workflows get broken, as we now have a more rigid session mapping mechanism
  10. CORE COMPLEXITY  Complexity that touches many parts of part

    of the codebase  Connection management in CIDER  The choice of a REPL server  Request processing API  Choice of data structures  It’s rarely the same as inherent complexity (which is often rooted in the business domain)  It’s the complexity that’s hardest/most expensive to undo
  11. PERIPHERAL COMPLEXITY  Complexity that’s orthogonal to the core functionality

     Configuration options  Things built on the top of the core APIs  Variations of core commands and APIs  The stuff that’s nice to have, but you didn’t really need  Easy to undo, as it’s typically not coupled with anything important
  12. INF-CLOJURE – A CASE STUDY OF SIMPLICITY  No external

    deps  Very basic functionality  All implemented in terms of evaluating Clojure code and processing the raw result  Few configuration options  Works everywhere
  13. MONROE – BACK TO THE BASICS  Fork of CIDER

    predating the birth of cider-nrepl and the modern connection management  Dropped the notion of dedicated buffers for things like documentation, macroexpansion, results, etc  Not coupled with Clojure as strongly as CIDER  Convenience/flexibility vs simplicity
  14. “PERFECTION IS ACHIEVED, NOT WHEN THERE IS NOTHING MORE TO

    ADD, BUT WHEN THERE IS NOTHING LEFT TO TAKE AWAY.” -- ANTOINE DE SAINT-EXUPERY
  15. THE CHECKLIST  How much complexity does feature X add?

     What type of complexity is this?  How big of an (positive) impact it would make?  Do I want to develop it? Can I develop it (properly)?  Does anyone want to develop it?  Do I want to maintain this?  Can I maintain this?
  16. Do I really need this feature? A problem that solves

    Itself! Yes! Have I thought this through? Not really.