6 ms·
> it also forces you to think about how your change is going to affect the whole system. That's a good thing. How do you reconcile that with software's pervasiv
by ethanhunt_ 14y ago
> it also forces you to think about how your change is going to affect the whole system. That's a good thing.
How do you reconcile that with software's pervasive idea of abstractions, which lets us avoid exactly what you say is a good thing?
- michaelochurch 14y agoAbstraction is a good thing, but what I'm talking about here is object-oriented programming. An "object" is something of which one has incomplete knowledge. OOP is, I would argue, about managing incomplete knowledge, on the (correct) assumption that if systems get large, it will be inevitable that people don't understand all the details of what they're working with. Good abstractions deliver a lot of value. Files and sockets, for example, should be treated as objects, because the client should (usually) be agnostic of how the things are actually implemented. So OOP isn't all bad. What's messy is a paradigm that gives an unbounded right to inject complexity. Programmers don't have enough autonomy in most corporations to do things right, so the result in most cases of Brownian-motion requirements is an increasingly gnarly pile of hacks. What Haskell does well (being both functional and statically-typed) is punish that style of development while it occurs, making it so that the kludge isn't always the path of least resistance.