Comment by taeric
2 months ago
I'm not entirely clear what the argument being made is. Simple tools are simple, sure.
But there is an awful lot of complexity in otherwise simple things. Just look at hand tools and see the difference between a power drill and a power driver. And realize that asking which one is simpler is a bit of a red herring. Even better, try and guess which one was created first.
I think, often times, people mistake the results of something from the tools that went into it. Such that it can be tempting to think that simple looking creations were made with simple tools. As often, the opposite is the case. It takes complicated tools to build something that looks simple.
Maybe the argument was that you put more effort and work into what you are building than you do that which you use to build it? I think that is largely fair.
That is actually somewhat in focus when discussing a pen versus the "penzilla." For one, building a pen is a surprisingly difficult thing to do. Especially at scale. For two, people rarely want to have a pen for the sake of owning a pen. Instead, you want to write something.
Which is very different than something being simple.
There's a lot of old sayings that capture this sentiment. "Simplicity is complexity resolved" (Brancusi), "Good design is invisible) (???), "The best craftsman leaves no trace." (Chinese Proverb??).
My favorite is "Sprezzatura"[0]. The act of making something look simple. IME, the mark of a true expert is they make their work look trivial. As if anyone could do it. It's bittersweet that this is the reality, because we seem to have fooled ourselves into thinking things are as simple as it looks ("pun" intended). It's a dangerous trap. Over estimating difficulty will prevent us from trying, but underestimating will make us foolishly spin our wheels. But I think we've built a system where we just normalize wheel spinning. It's true, most wheels are made for spinning. But if they're freely spinning in the air then your car is going nowhere.
[0] https://en.wikipedia.org/wiki/Sprezzatura
Thx
> Just look at hand tools and see the difference between a power drill and a power driver. And realize that asking which one is simpler is a bit of a red herring. Even better, try and guess which one was created first.
I would assume the power drill was created first if you include human powered drills, screws came much later than pretty much every other kind of simple machine, and until machine tools were invented, screws as fasteners didn’t really exist outside of specialized applications. They were used for presses and applying force.
John Henry was competing against a steam powered rock drill in the folk tale about him.
If you define power tools as tools driven by electric motors, I would still guess that the drill came before the driver, as rivets seem to be more popular in the steam engine to electric transition period than bolts or screws were.
Slightly confusing things is the fact that a modern drill is almost always a driver too, unless it’s a specific kind of drill like a hammer drill or core drill. Confusing things even more, there are drill bits that are meant to be used with an impact driver, a tool that is used to tighten or loosen fasteners.
As for which is simpler, drill vs (impact) driver, it’s hard to say. A drill has a clutch, and an impact driver has a spring mechanism that applies rotational force when the motor is at its limit. I’d say both are fairly complex, the impact driver is probably a bit more complex than a drill.
I’m curious about the development and history of power tools but it can be difficult to find information about it.
Your progression of "confusing things" happening several times is exactly what I was hoping to elicit. And is why I think it is a bit of a red herring to ask which is simpler.
Love this kind of comment, where one commenter poses a thought experiment about something I'm unfamiliar with, another commenter explains it in full seriousness.
Here's semi related talk about simple/complex and easy/hard [1].
[1] "Simple Made Easy" - Rich Hickey (2011) https://news.ycombinator.com/item?id=23905051
Heh, I'm pretty sure Rich Hickey is a fan of React and the Clojure community uses it heavily with Clojurescript.
Rich Hickey had nothing to do with it. He did put a lot of the initial work to get Clojurescript up and running but for many years the majority of cljs maintenance and shepherding was done by David Nolan. Not sure now; I've been out of the loop for years.
The Clojurescript community was the first group adoption of React outside Facebook (early on they had community news blog post and mentioned it) but that because the React rendering model fit the Clojure data model. I was active in the NYC Clojure meetup at the time (Rich was from upstate and would only come in for big announcements, and David was local) and we had 4 or 5 months where there was active discussion among the web devs after the talk on how to make cljs actually work. My memory is Brandon Bloom is the one who made the React connection. David picked up the idea and promoted it to the wider community.
1 reply →
I think this is not the point of the argument. Power driver solves a problem, but not everyone has that problem. Some jobs just need a drill.
The article argues that while React solves a problem, not everyone actually has a problem that requires the complexity of React (i.e. "Build pyramids if you must").
> The article argues that while React solves a problem, not everyone actually has a problem that requires the complexity of React (i.e. "Build pyramids if you must").
I think this argument isn't valid. The problem that React solves is creating reactive user interfaces. React is trivial to use in it's happy path. The tool's complexity is a red herring because using the tool is trivial and effortless.
To me, this argument is based on specious reasoning. Take for example vending machines. They are trivial to use: pick a product, pay, see it drop and pick up your item. It's dead simple. Does it make any sense to whine that buying items from an automated system is a problem not everyone has, and that the vending machine is far more complex than a seller behind a counter? No. What makes sense is the complexity from the user's perspective, and what effort it requires them to achieve the goals they set forth to achieve. And React makes it trivially easy to put together highly performant reactive web apps.
Sure. The point is, people use React for everything, even static web sites, not only for creating reactive user interfaces. They do it because someone else told them so.
8 replies →
> The problem that React solves is creating reactive user interfaces
The problem that React originally aimed to solve was creating reactive user interfaces in facebook's monorepo monolith where 1,000+ software engineers are constantly churning code.
This is potentially not the same problem that you are envisioning there, and it tends to put rather different constraints on the solution.
3 replies →
The argument is valid and doesn't need over analyzing.
Using react for simple simple things makes it not simple.
1 reply →
Right, my point was more that thinking you can guess the simplicity of a solution based on the complexity of the tools used to build it is a bit misleading. If only because most simple tools are far more complicated than that allows.
Similarly, I would argue that using complex tools to build something generally results in less complicated outcomes. Our computers are basically evidence of that.
Yes, the modern world is a confusing thing.
Difficulty of use and reliability don't seem to have any relation to complexity on mass-distributed products. Costs depend almost exclusively on scale, and not on inherent properties.
But why would I want to use a screwdriver when I could use my power drill? Like sure, the screwdriver works, but it's more effort and slower...
Actually there's lots of times I want to use my hand driven driver rather than a motorized one.
I agree with the other comment mentioning analogies have their limits. Are we going to pick them apart just so we can avoid listening? Communication is lossy. Are we having a conversation or just trying to win a game of our own design?
I add that because how I interpreted taeric's point of a drill and a driver is just a variation of "apples and oranges." You can concentrate on how they're both round fruit or you can recognize there's differences. I mean walk into any machine shop or go to your uncle that likes to make things and have them explain why they have so many wrenches of the same size but in different styles. Often the subtle differences are the most important part. Hell, how many people even know what those numbers do on the power drill? Making use of them really ups your game. Same with adjusting the power level on your microwave. Yet I rarely see people use these things which are highly effective and help avoid many common mistakes.
2 replies →
Analogies have their limits. That being said, there is always a learning curve. Imagine a situation you want your 5 year old to assist you, but you don't want to teach them how to safely use a power drill.
1 reply →
Sometimes torque is a bad thing.
I see you've never seen or dealt with a head blown out of a fastener. A drill has basically no feel, and things escalate quickly especially for marginal fasteners.
3 replies →
The argument is that certain tools introduce complexity into a project by the mere act of using them. A power drill has many more knobs and features that the user must be aware of than, say, a screwdriver. Sometimes those features are required, but often developers will gravitate towards such tools even when they're not.
In software development this applies not just to external tools, but to abstractions in general. We might be tempted to create or depend on an abstraction that solves many problems in a generic way, when in reality this could be avoided. The appeal is to reject this temptation whenever possible.
Simplicity is an amorphous quality without a clear path towards it. It's often debatable whether a system is simple or complex, given that most software is built on extremely complex machinery we take for granted. But the least we can do is to be mindful of practices that lead to a net increase of complexity, use critical thinking instead of blindly following trends, and, sometimes, take the more difficult road for the sake of preserving simplicity.
[dead]
[dead]