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

Victims of Complexity

1be785d1d788b82929e55fc83a9f0aaa?s=47 Bozhidar Batsov
June 08, 2021
210

Victims of Complexity

Originally presented on June 5th 2021, at ClojureD.

1be785d1d788b82929e55fc83a9f0aaa?s=128

Bozhidar Batsov

June 08, 2021
Tweet

Transcript

  1. VICTIMS OF COMPLEXITY BOZHIDAR BATSOV

  2. HEY, THERE!

  3. (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
  4. 2020

  5. 2021

  6. NO CLOJURE CONFERENCES SINCE FEBRUARY 2020

  7. THAT MAKES ME VERY SAD

  8. ALWAYS LOOK ON THE BRIGHT SIDE OF LIFE

  9. LOCAL TOURISM

  10. WEDDING

  11. I’VE BUILT A DESKTOP PC AND SWITCHED TO LINUX

  12. AND THEN TO WINDOWS…

  13. THIS PRESENTATION WAS CREATED IN POWERPOINT!

  14. CLOJURED 2017 AND ONE EPIC POWERPOINT FIASCO

  15. I LOVE WINDOWS!

  16. None
  17. None
  18. WHAT ABOUT CIDER?

  19. CIDER 0.24 (FEBRUARY 2020, IN/CLOJURE)  Small improvements

  20. CIDER 0.25 (JUNE 2020, CLOJURISTS TOGETHER)  Small improvements

  21. 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
  22. 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
  23. NREPL 0.8  Built-in completion op  Built-in lookup up

     Added the ability to load middleware dynamically
  24. BETTER USER EXPERIENCE, LESS HASSLE

  25. A FEW QUIET MONTHS

  26. CIDER 1.0 (DECEMBER 2020)  Small improvements

  27. CIDER 1.1 (APRIL 2021)  Small improvements

  28. LESS IS MORE

  29. VICTIMS OF COMPLEXITY BOZHIDAR BATSOV

  30. SIMPLE MADE EASY

  31. OUT OF THE TAR PIT

  32. THE GROUNDHOG DAY DEVELOPMENT METHOD (GDDM)

  33. None
  34. CONNECTION MANAGEMENT IN CIDER

  35. None
  36. 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)
  37. 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
  38. 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
  39. 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
  40. 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
  41. None
  42. LET’S SOLVE THIS PROBLEM WITH REGULAR EXPRESSIONS…

  43. None
  44. WELL-DOCUMENTED COMPLEX CODE IS STILL COMPLEX

  45. NO FEATURES, NO PROBLEMS

  46. IS ALL COMPLEXITY THE SAME?

  47. INHERENT/ESSENTIAL COMPLEXITY VS ACCIDENTAL COMPLEXITY

  48. CORE COMPLEXITY VS PERIPHERAL COMPLEXITY

  49. VERTICAL COMPLEXITY VS HORIZONTAL COMPLEXITY

  50. 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
  51. 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
  52. None
  53. None
  54. CORE COMPLEXITY == HARDER TO COMPREHEND/CHANGE

  55. PERIPHERAL COMPLEXITY == HARDER TO LEARN

  56. THE CORE COMPLEXITY IS THE SCARIER ONE, BUT YOU HAVE

    TO BE WARY OF BOTH
  57. THE GROUNDHOG DAY DEVELOPMENT METHOD (GDDM)

  58. 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
  59. 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
  60. “PERFECTION IS ACHIEVED, NOT WHEN THERE IS NOTHING MORE TO

    ADD, BUT WHEN THERE IS NOTHING LEFT TO TAKE AWAY.” -- ANTOINE DE SAINT-EXUPERY
  61. COMPLEXITY IS A CHOICE

  62. SIMPLICITY IS A CHOICE

  63. KEEP IT SIMPLE

  64. 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?
  65. Do I really need this feature? A problem that solves

    Itself! Yes! Have I thought this through? Not really.
  66. None
  67. START WITH NO

  68. THE FACT THAT SOMETHING SEEMS LIKE A GOOD IDEA DOESN’T

    NECESSARILY MAKE IT A GOOD IDEA
  69. BIAS FOR ACTION

  70. BIAS FOR INACTION

  71. None
  72. THE END