3 ms·
Such as...? A hypothetically perfect immutable system does not need to be testable, maintainable, or understandable. It becomes a black box.
by rgraciano 12y ago
Such as...?
A hypothetically perfect immutable system does not need to
be testable, maintainable, or understandable. It becomes a black box.
- klibertp 12y agoEven in those perfect conditions right level of abstraction may cause the system to be build with less code and faster. That being said I agree that it's always a trade off; I actually did many refactorings where I threw an abstraction level out instead of adding more of them, resulting in faster and easier to maintain code. It's definitely not good to invest in abstraction blindly.
- mistercow 12y agoIn a perfect immutable system, I'm still going to want my code to be as DRY as possible, because I don't like typing the same thing over and over again. In this perfect hypothetical world, you wouldn't eschew abstraction; you'd just know exactly what abstractions to use to perfectly model the problem you're solving. Those ideal abstractions would be different, since the problem is immutable. Ask yourself this: in this perfect world, would you code with a magnetized needle and a steady hand? Why not?
- rgraciano 12y agoNot sure how the magnetized needle analogy applies here. The point of the hypothetical is to avoid developing your own extra layers of code for future reuse. Avoiding those that others have developed for you already would not make sense. As to the rest of your point, yes. Anything in service of pure development speed would be desirable. If you could abstract and reuse something faster than you could implement it in some other way (eg copy/paste), then it would make sense to do so.