| ▲ | taeric 16 hours 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. |
|
| ▲ | godelski 12 hours ago | parent | next [-] |
| > something that looks simple.
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 |
|
| ▲ | nomel 16 hours ago | parent | prev | next [-] |
| 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 |
| |
| ▲ | b_e_n_t_o_n 12 hours ago | parent [-] | | Heh, I'm pretty sure Rich Hickey is a fan of React and the Clojure community uses it heavily with Clojurescript. | | |
| ▲ | grayrest 7 hours ago | parent [-] | | 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. | | |
| ▲ | b_e_n_t_o_n 6 hours ago | parent [-] | | Thank you for the lore :) I thought I could recall some post/article where Rich Hickey said something positive about React but I can't find it. Maybe I made it up in my head idk. |
|
|
|
|
| ▲ | selcuka 16 hours ago | parent | prev | next [-] |
| 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"). |
| |
| ▲ | motorest 12 hours ago | parent | next [-] | | > 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. | | |
| ▲ | swiftcoder 2 hours ago | parent | next [-] | | > 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. | |
| ▲ | selcuka 12 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | lmm 7 hours ago | parent | next [-] | | > 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. No, they do it because it's simpler. | |
| ▲ | b_e_n_t_o_n 6 hours ago | parent | prev | next [-] | | Maybe they do it because they like React? :) | |
| ▲ | motorest 11 hours ago | parent | prev | next [-] | | > 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. No, not really. There is more to picking up a tool than some rando's simplistic drive-by judgement. For example, say you have a React SPA managed by a team which built and manage their whole platform, from the CICD pipelines to the hosting solution. All your infrastructure was built around providing a React app and it's backing services. You are then suddenly faced with a need to implement a feature where a user after clicking on a link navigates to a page that just shows static text. Now think. If you implement that page with React then that's a one-point task. Just create a component, fill it with text, post a PR, done. What level of effort does it take you to implement that with another technology? If you go with the simplistic take that plain HTML is better, now you need to set aside time to sort out support for styling, sort out where and how to deploy those assets, work on a process to automate the deployment, etc etc. Now your simplistic drive for simplicity turned into something between a week and a month's worth of work requiring infrastructure changes and adapting deployment strategies, all of this requiring not-so-trivial QA and testing work. What problems did you solved? Can you describe your system as simpler, and keep a straight face? | | |
| ▲ | selcuka 9 hours ago | parent [-] | | You gave an example where the use of react would be justified to prove your point. You could have also given one where it isn't. The article is about the latter. | | |
| ▲ | motorest 8 hours ago | parent | next [-] | | > You gave an example where the use of react would be justified to prove your point. You could have also given one where it isn't. The article is about the latter. Not really, the article is about a belief some other approach would be preferable based on superficial and specious reasoning. My example proved that this kind of superficial and simplistic analysis fails to account for critical aspects which are key to explain why a decision was made. This doesn't go away by complaining that I refuted your point while I could easily not refute it. The whole argument is silly, if you think about it. What could possibly possess anyone to believe they are the only ones who know better and everyone else in the world who disagrees is stupid and doesn't know what they are doing? | |
| ▲ | philipwhiuk 4 hours ago | parent | prev [-] | | > The article is about the latter. And yet fails to provide a single example. |
|
| |
| ▲ | tpm 8 hours ago | parent | prev [-] | | > They do it because someone else told them so. Alternatively, they do it because if you are holding a React, everything looks like it should be implemented using a React. While the finished product might be more complex than needed, it is less complex for them, because they have used a tool they understand well. |
| |
| ▲ | politelemon 11 hours ago | parent | prev [-] | | The argument is valid and doesn't need over analyzing. Using react for simple simple things makes it not simple. | | |
| ▲ | motorest 10 hours ago | parent [-] | | > The argument is valid and doesn't need over analyzing. No, it isn't. A big part in your failure to understand the problem is your refusal to look at what you're doing, which you try to dismiss as "over analyzing". As if reaching the conclusion that a simplistic proposal brings unacceptable tradeoffs means you are looking where you shouldn't. > Using react for simple simple things makes it not simple. Did you actually took any time to think through that assertion? I don't think so. For starters, you didn't even stopped to think why React is used at all. Why was that? |
|
| |
| ▲ | taeric 16 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | marcosdumay 15 minutes ago | parent [-] | | 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. |
| |
| ▲ | b_e_n_t_o_n 12 hours ago | parent | prev [-] | | 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... | | |
| ▲ | godelski 11 hours ago | parent | next [-] | | 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. | | |
| ▲ | b_e_n_t_o_n 10 hours ago | parent | next [-] | | I wasn't trying to pick the analogy apart, I thought it was quite a good one and was running with it. I think it breaks apart though when you start talking about minor differences in wrenches though - it's not like the difference between Vue and Solid will make a significant difference when building an app. But between a screwdriver (jQuery) and a power drill (js framework), that can be very significant. | |
| ▲ | 10 hours ago | parent | prev [-] | | [deleted] |
| |
| ▲ | selcuka 12 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | b_e_n_t_o_n 12 hours ago | parent [-] | | Yeah for sure. Sometimes my drill is not charged and it's easier to grab a screwdriver and give it a few quick turns (https://benton.codes/blackberry), or maybe I can't fit the drill in some space. But normally I'll use the drill even though it's overkill, because I got other stuff to do :P |
| |
| ▲ | 15155 11 hours ago | parent | prev | next [-] | | Sometimes torque is a bad thing. | |
| ▲ | rpcope1 7 hours ago | parent | prev [-] | | 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. |
|
|
|
| ▲ | quickthrowman 16 hours ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | taeric 16 hours ago | parent | next [-] | | 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. | |
| ▲ | kccqzy 16 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | imiric 6 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | ks2048 16 hours ago | parent | prev | next [-] |
| [dead] |
|
| ▲ | yeahs000 16 hours ago | parent | prev [-] |
| [dead] |