Behavioral programming is a relatively new programming paradigm that excels at isolating behavior in event-driven systems. What would it look like in Clojure?
The ocelot game works like this: a developer has written a feature, and presents it to an ocelot.
Not a real ocelot. Ocelots are playful. But they’re wild animals. Their claws easily poke holes in things. We want to poke holes in code.
The ocelot is a role played by a developer who tries to poke holes in another developer’s code. Specifically, they try to change the code in such a way that the feature breaks while still passing the unit tests.
When I first became interested in functional programming, a more experienced engineer told me: “you know functional programming doesn’t really amount to much more than procedural programming.” As I insisted on the benefits of map, filter and reduce, he simply shook his head. “You’re thinking in the small. Go look at a large real-world application.”
It took some time for me to see what he meant. My preferred language, Clojure, is a functional language. But too often it is used to build top-down, imperative applications. This negates the value proposition of functional programming: isolating side effects, local reasoning, and system composition.
This is the second post in the series “Have Clojure UIs Taken the Wrong Path?”. The first post is here.
How do we choose between building an application using a hypermedia approach versus the client-side SPA? This post won’t answer that question. But it will say how not to make that choice.
A common heuristic is the spectrum that stretches between old fashioned “Multi Page Apps” (MPAs) for basic use cases, to Single Page Applications for rich client interactivity.
The Clojure community has focused on React-based solutions for complex front-end clients such as Reagent, Rum, Om, Re-frame, and Fulcro.
For all their differences, they follow a very similar architecture, making heavy use of client-side state and using RPC for client-server communication. We will call this the “React+” approach.
But is this the right choice?
I will suggest the answer may be negative. My suspicion is that as web UI libraries advance, the problems they solve are not essential. Rather, the problems are accidental; they are generated by the React+ architecture.
Andy Hunt and Dave Thomas tell us: 'it’s critical that you write code that is readable and easy to reason about.' This seems uncontroversial; it is the rare point on which software engineers typically agree. Or do they?
The library locker antipattern occurs when we try to add functionality to a library function, but do so without separating concerns.