Clojurians Log v2

imo, you've lost the distinction between them (and simple and easy are not either/or)

easy is a measure of familiarity. simple is a measure of disentanglement.

Yeah I dont get it either. I don't think Rich's intent in the talk was to imply ease and simplicity are mutually exclusive. Ideally you want things to be simple and easy :)

"suck" is vagueness masking the ends of those scales (unfamiliarity and entanglement). what sucks about those? unfamiliarity sucks because you don't know how to do things or what things mean. emotionally, unfamiliarity makes us feel like we are lacking agency. it can even make us feel shame. (recognizing this feeling and leaning into it as a path towards improvement is imo an important thing to learn as a human. unfortunately, knowing that does not make it any easier. :) entanglement sucks because making novel combinations of things or using one part of a system without dragging in the whole thing are difficult, or perhaps even impossible, which makes you less powerful as a user.

Talk's definition of simple vs easy was simple, but not easy to grasp. You are trying to make it easy 🙃

And simple is an objective measure, which sucks definitely isn't.

Reading from a file in Java pre v 8 is simple, slurp is easy. You can build easy from simple, but it's really hard to get from easy to simple.

Let me justify this a little more: when things are not simple they are complected. The main symptom of things being complected is that they are hard to pull apart To me this means for uses where you don't need to pull things apart, there is little friction. For use cases where you do, there is a lot of friction. That is the upside of complection. intended usage tends to require little effort. In a properly decomplected system there aren't use-cases that are optimized for. The upside is that now you can do anything, nothing is artificially harder than it is intrinsically. The downside is that applying a decomplected toolset to a problem will have constant glue overhead.

I agree in so far that the main effort is not in starting simple but in keeping things simple, which can be quite hard. But it is always hard work to make complicated tasks look simple. That applies to nearly every endeavor..

I'm thinking really concretely about things like "lein uberjar" or "mvn compile" versus the deps workflow where you accept an overhead to some tasks in exchange for an overall simpler system

That's where the comparison comes from - mvn compile is complected, deps workflow is not (dependency resolution is not complected with the build process)

Deffo, deps.edn is simple, lein is easy.

I think it takes active effort to make an easy thing also simple, but also that it sometimes requires accepting glue overhead. Like making an uberjar is as much effort as making a jlinked image or assembling things into directories or anything else

But in a system that prioritizes ease, only the considered up front tasks end up being easy. Things that weren't prioritized end up being hard

Maybe I'm just trying to say that's a "design smell?"

I see it as easy is an emotional response/feeling. It's not a real property of the code. What's hard for you can be easy for me for example. Simple is a property of the code itself, the ability for different parts of the code to change without impacting other parts, and for those parts to be able to be combined arbitrarily together in many ways where those combinations naturally work.

The way I see it is when designing a system you need to decide what objective matters the most. Best example I have is how to organize a library: if your objective is to find books by a specific author then organizing by authors is simple, but this organization makes it complex to find a book by title. In business I notice complexity creep when someone attempts to achieve multiple objectives at the same time. It is a trap we can't resist falling into. If I just add this check here we can hit two birds with one stone. Then you discover this check alone is not enough, you need to add more because some other downstream process now depends on the output from this one, and then you end up with a jumbled difficult to understand mess. Doing things simply requires courage because the easy solutions are irresistible and people will push you, your instincts will push you to take the easy path. Sometimes you do it without realizing. A very good practice is to ask for any process, system, and decision: what is the single objective that we need to achieve?