|
|
|
|
|
|
by p0nce
4201 days ago
|
|
|
> Generics is not the only way to separate data and algorithms. Do you see any way other than the 3 ones discussed in the OP article under the label "Generics"? > When you know where exactly the code will be run, it can be possible to create a better package taking into account the context where it will be run. By concrete, I mean a package in a real-world problem. Basically, abstract things are harder to optimize for a particular case. I could agree with that if time wasn't limited, but imho building custom data structure/algorithms for each problem will precisely leave less time to optimize for performance since reaching a working state first will be longer without reusable abstractions. |
|
|
The one I mainly meant was interfaces. Of course there are also DSLs and code generation.
> I could agree with that if time wasn't limited, but imho building custom data structure/algorithms for each problem will precisely leave less time to optimize for performance since reaching a working state first will be longer without reusable abstractions.
I mentioned that in the summary. It's about tradeoffs. Even if all the cons/pros are listed people could still come to different conclusions, because people value different things. And there's nothing wrong about it.
The amount you need to reimplement depends on the amount of available third-party packages - the more good packages there are the less you need to build those custom data structures.