Victims of Complexity

Originally presented on June 5th 2021, at ClojureD.

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
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!
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)
34. CONNECTION MANAGEMENT IN CIDER
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
42. LET’S SOLVE THIS PROBLEM WITH REGULAR EXPRESSIONS…
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
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.
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
72. THE END