Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

But if you look at Haskell's Control.Monad you see why the abstraction is helpful [0]. We get things like foldM, it's similar to how you can fold across more than just lists, you can fold across trees and so on, but for all these different structures like State, Either, etc. And yes you are right to point out that some of them have multiple implementations, State can be combined "backwards" or "forwards" (or both). The trade off is you have to invest the time so these abstractions become natural, but once you do so you can use generic control structures that save tons of implementation time.

[0] https://hackage.haskell.org/package/base-4.9.0.0/docs/Contro...



I guess, but I don't think I need that library? Or at least, not badly enough to complicate the type system.

It adds complexity, so I'm not convinced I'd save any time.


Some might argue that many similarly behaving structures without structural connectivity (also known as, DRY principle) is the very essence of complexity.


Not necessarily. There is often code that works the same way "by coincidence." The simplest example is two constants that just happen to be assigned the same value. In that case, you shouldn't share common code - it's just going to make changes harder. If you modify one constant, you don't want to modify the other.

Having a mathematical concept in common: is that important, or is it a coincidence? Seems like it depends on the domain and maybe on your point of view.

At the end of the day it's about how hard the code is to maintain. Sharing dependencies makes things better if you want to fix a bug in one place. But every dependency has a cost, too, since it's another thing that can break you if it changes.

Too many dependencies and you get something like the "fragile base class" problem where you can't easily change the code, even to fix a bug, because there are so many downstream usages that depend on it working the way it does today.

So, I would not be quick to depend on a common utility library for simple convenience, unless I know how stable and bug-free it is, and that it doesn't have too many dependencies of its own.


Ok, but since I invested time to learn it and can now use it, I can save time every time I do. Perhaps I will pay down my debt eventually, perhaps not. It's a sunk cost and I enjoyed learning about it, so I'm pretty happy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: