8 ms·
I found the following comment very insightful in a past discussion: https://news.ycombinator.com/item?id=11042400 https://news.ycombinator.com/item?id=11042400
by gadrev 8y ago
I found the following comment very insightful in a past discussion:
https://news.ycombinator.com/item?id=11042400 https://news.ycombinator.com/item?id=11042400
I reproduce the relevant part:
Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code.
State > Coupling > Complexity > Duplication. I find that
to be a very sensible ordering of concerns to keep in mind when addressing any of those.
- kornish 8y agoExcellent quote! Saw this comment a couple years ago, agreed strongly, and been looking for it since — thanks for resurfacing.
- Trufa 8y agoInteresting indeed but the part that stuck with me the most is: >> Existing code exerts a powerful influence. Its very presence argues that it is both correct and necessary. I read the article in 2016 and that phrase stuck with me ever since, I had never thought about it but it's such a simple and self evident fact but so easy to miss. It's a powerful concept to know. Both when writing and when refactoring code.
- hamandcheese 8y agoThis too is one of the few pieces of programming wisdom that I find unforgettable.
- nothingisnil 8y agoDeleted not to please downvoters.
- genezeta 8y agoThe point is not whether it is correct and necessary, but that its existence makes the argument that it is indeed so. What you mention is actually the insight that "it may not be". But you reach that idea _against_ the argument its presence is making. That is, you find some code. Its presence says "I'm here for a reason", your answer of "maybe it's just because..." comes as, precisely, an _answer_ to that argument. Neither the argument itself nor your answer are necessarily and always correct. This doesn't argue that point, just that the presence of a piece of code makes such an statement.
- deleted 8y ago[deleted]
- codetrotter 8y agoThe article explains what is meant. > We know that code represents effort expended, and we are very motivated to preserve the value of this effort. And, unfortunately, the sad truth is that the more complicated and incomprehensible the code, i.e. the deeper the investment in creating it, the more we feel pressure to retain it (the "sunk cost fallacy"). It's as if our unconscious tell us "Goodness, that's so confusing, it must have taken ages to get right. Surely it's really, really important. It would be a sin to let all that effort go to waste."
- your-nanny 8y agoI think it is a mistake to call this a sunk cost fallacy. the other stuff is true, but it's not the same thing as the sunk cost fallacy
- nullisnullish 8y agoI really enjoyed you insighful comment. I can't understand all those furious downvoters. Perhaps they are a bad abstraction.
- bothareright 8y ago
- djsumdog 8y agoIf you're working to get a certain task done at your job, yes I can see wanting to minimally touch the code. If something gets bad enough, I will refactor the whole damn thing, but only at jobs where there are unit tests. If there are no unit tests, this truly becomes an impossible task and it's best not to touch anything you don't need to. You have to have good tests if you ever want to tackle technical debt.
- vkjv 8y agoI've heard this called "bunny code." It doesn't matter if it's good or bad, it'll reproduce.
- k3lsi3r 8y agoI don't fully understand the state part. Could someone provide an example of what the OP is talking about? thanks!
- epai 8y agoWell, more state in code usually makes it more difficult to do things like run the code concurrently. You have to worry about managing data races when there is a lot of shared state, whereas in stateless code no complex managing is needed
- newfocogi 8y agoAlthough this is true of stateful code, I think an even more fundamental, but related, reason to reduce state is this: code that is stateless always behaves the same way so it can be characterized and reused more easily than code that changes behavior depending on the state. This is the reason it is good for concurrent programming, but it also means it has a more concrete/consistent nature.
- kilburn 8y agoSay you write some software that manages a shopping cart. a) You can "store" (even if it's in-memory) just the products and their quantities. Then each time you need to display the cart you go and compute the corresponding prices, taxes, discounts, whatever. b) You can store each cart line, whether it has discount(s) or not, as well as its taxes and the cart's global taxes and discounts and whatever else you can imagine. Option "b)" is probably more efficient (you are not constantly recomputing stuff) but you will be better off in the long term by going with option "a)": - Your cart management and your discount/tax computation are less coupled now (the cart doesn't really need to know anything about them) - You have less opportunities for miscalculation because everything is in one "logical flow" (computeDiscounts()/ computeTaxes()) instead of being scattered (some stuff is computed when you add an item or when you remove it, or when you change the quantity, or when you specify your location, etc..). The code will most probably just be simpler with option "b)". The article argues that you should sacrifice the performance in cases like this. I agree.
- amelius 8y agoThere is a quote by Linus Torvalds that is relevant here: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."
- bch 8y ago"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they’ll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
- MattyRad 8y agoWhen referring to "state" are we talking about just mutable state? Or are we talking about both mutable and immutable state as being equally undesirable? Because in my experience immutable state is fine, and often desirable, whereas mutable state is almost always toxic. I could be convinced otherwise, for sure, but it might be worthwhile to make the distinction between the two.
- cutety 8y agoNot the OP, but as someone who has also found it to ring true, ideally the less state the better, immutable or mutable. But, if I had to choose which kinda of state I’m managing, I’ll take a bunch of immutable structures over a few mutable ones any day. We all know the issues that arise out of mutable state, values getting changed for seemingly no reason, race conditions literally sapping every little bit of will to live you had, mutable state doesn’t scale well (at least from a complexity standpoint). Now you’ve gotta worry about locks, and all that fun stuff if you try to do any kind of non trivial concurrent programming. Now, I’m not saying immutable data structures are literally the silver bullet, but they do almost completely solve all the above mentioned issues with mutable state. But, they too, have their own issues. Working with immutable structures can be significantly slower, especially as the amount of state grows, any modifications mean you have to create a new structure and copy data, and now you’re also going to be having a lot more memory being used, and that’s not mention the conceptual differences you have to adjust to if you’ve never worked with strictly immutable structures before (“what do you mean I can’t just update this array index with arr[i] = 2?”). But, in my experience, debugging can be orders of magnitude easier, concurrency is something that is actually enjoyable to work with, and not a chore of mutex checking, and hoping some random thread isn’t going to fuck up all the data, and given the power of modern computers, the memory bloat that comes along with immutability isn’t really an issue anymore. But, I’m also one of those people that thinks functional programming is the one true path, so I may be a bit biased/misinformed on some crazy mutability benefits that make the bullshit worth it.
- andai 8y agoI heard that since the future is more and more cores, instead of faster ones, functional programming is going to become increasingly necessary.
- asdffdsa321 8y agoI disagree, simpler code can be better if the library is well known. Otherwise we would never be using utility libraries. Though yes, coupling indiscriminately is problematic
- oh-kumudo 8y ago100% with State. It is just my personal experience, to keep track of all states, it takes O(n^2) of my brain power, and the same order of magnitude tests to cover it up.
- userbinator 8y agoI would say they are all related concerns but my order would probably be Complexity > Duplication > State > Coupling. In nearly all the refactorings I've done, reducing complexity and duplication will tend to automatically take care of the other concerns.