4 ms·

> Branching scales well when we want to extend the program by adding functions but it doesn’t scale well when we want to add types. In languages such as OCaml,

by p4bl0 6y ago

> Branching scales well when we want to extend the program by adding functions but it doesn’t scale well when we want to add types. In languages such as OCaml, when you add a constructor to an algebraic data type (which is the equivalent of adding a type here), the compiler will guide you towards the completeness of all the functions in your codebase that match over your type. So this burden is not on the programmer. > Polymorphism scales well when we want to extend the program by adding types, but it doesn’t scale well when we want to add functions over these types. In the same manner, you can add an abstract method to your base type to have the compiler force you to implement it in every types that you have defined and that extend it. So I guess these are not real problems. The author's two other conclusions are valid however. And I'll add that I believe good software engineering structure programs around data structures rather than functions. So I completely agree with them: long live the switch :).

wffurr 6y ago
The "problem" in each case is that you have to modify code in a bunch of different places instead of one place. Tools help with abstract methods and exhaustive enum checks, but it's the difference between a change in one place vs changes in many places.
- akdas 6y ago
  > The "problem" in each case is that you have to modify code in a bunch of different places instead of one place. And by extension, different places include ones you don't own, and therefore can't change. For example, say you have an interface in your library that consumers of that library implement. If you want to add an operation to that interface, all consumers of your library, ones you don't even know about, have to support that operation. But, if you want to add a new interface, consumers only have to implement that interface if they want to use functionality based around that new interface. (And of course, the same applies in the opposite direction if you're using an operation-first approach.)
akdas 6y ago
> the compiler will guide you towards the completeness of all the functions in your codebase that match over your type. So this burden is not on the programmer. That only works if all the functions you care about are in one codebase. If not, then the changes the article talks about become backwards incompatible changes in your library. > So I guess these are not real problems. If you're designing a library, the approach you take determines what types of additions are breaking changes and which are not.
- p4bl0 6y ago
  I hadn't thought of that when writing my comment. You're right, thanks.

by p4bl0 6y ago

wffurr 6y ago

The "problem" in each case is that you have to modify code in a bunch of different places instead of one place. Tools help with abstract methods and exhaustive enum checks, but it's the difference between a change in one place vs changes in many places.

akdas 6y ago
> The "problem" in each case is that you have to modify code in a bunch of different places instead of one place. And by extension, different places include ones you don't own, and therefore can't change. For example, say you have an interface in your library that consumers of that library implement. If you want to add an operation to that interface, all consumers of your library, ones you don't even know about, have to support that operation. But, if you want to add a new interface, consumers only have to implement that interface if they want to use functionality based around that new interface. (And of course, the same applies in the opposite direction if you're using an operation-first approach.)

akdas 6y ago

> the compiler will guide you towards the completeness of all the functions in your codebase that match over your type. So this burden is not on the programmer. That only works if all the functions you care about are in one codebase. If not, then the changes the article talks about become backwards incompatible changes in your library. > So I guess these are not real problems. If you're designing a library, the approach you take determines what types of additions are breaking changes and which are not.

p4bl0 6y ago
I hadn't thought of that when writing my comment. You're right, thanks.