> 31. Simplicity does not precede complexity, but follows it.

> 58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

All that said, I've definitely seen cases where trying to insulate the user from the reality of what's happening behind the scenes often dramatically increases complexity. When it's done poorly, in increases complexity not only for the designer and programmer, but the user as well. One well-known example is the progress bar. After 30 years of lying to users about how long that file copy, download, or compile would take, many recent designs simply exclude it and include an animated spinner instead.

In order for something to get clean, something else needs to get dirty.

I think taming complexity might be closer to getting something clean.

But I also think -- counter to the "conservation of complexity" thing -- you can get make a mess and get EVERYTHING dirty.

They go hand-in-hand as you reach the endgame. Once you’ve reached a level of irreducible complexity this law comes into play.

Maybe it only comes into play if you try to decrease over all complexity of a system. After a certain point complexity can't be reduced but can only be redistributed.

Once simplified, you still have the option to move the essential operations to one side of the equation or the other.

A program in 1985 likely wrote its own routines for memory management, math, graphics, and so on. Those add complexity. A program in 2020 almost certainly doesn't. The complexity is hidden behind nice interfaces, and more importantly, it's shared among 1000 different programs on my computer.

We traded inline complexity in 1000 places for complexity in <math.h>. That's not the fair trade that "conservation" implies.

Let's say you have some physics problems to solve. Doesn't knowing Maxwell's Equations decrease overall complexity? I don't think anyone would claim you should only learn first principles, and any other formulation only uselessly pushes the complexity around.

It is literally looking at json schemas and API specs and the connecting fields together. A date-time field is connected to another API's date-time.

Essentially, you are implying that enabling no-code integration with thousands of 3rd party services is easy.

Classic case of: https://danluu.com/sounds-easy/

APIs are unreliable. Schemas change with no warning. Data you expect might be missing and data you don’t expect might show up. You would be surprised how often things don’t work as you’d expect them to.

Zapier sounds like theyre maintaining these integrations so that they are tested and they work? That alone is a lot of work.

These days though, many more are maintained by the API providers themselves, since it benefits them to provide a no-code solution for their users to link their API to thousands of others - a service provider can only build and maintain so many direct integrations themselves. https://zapier.com/platform

If the API provider is already maintaining the integration, it's a matter of automation providers moving towards a standard for how to express integrations as the ecosystem matures.

   {N} file(s) copied.

   match N with
   | 0 -> "No files copied"
   | 1 -> "1 file copied"
   | _ -> "{N} files copied"