2 ms·

>> Selecting your own definition for a word Is that accurate? I said: >> To complicate something is to combine and intertwine it with other concerns. To fold

>> Selecting your own definition for a word Is that accurate? I said: >> To complicate something is to combine and intertwine it with other concerns. To fold them together is to complicate them. The dictionary defines complicate as: >> to make complex, intricate, involved, or difficult With etymology: >> complicat- folded together complicate combine, entangle. intertwine earlv 17th century >> instead of actually giving a shit about the perspectives of those who disagree with you Now i resent that because i took the time to try and steelman your bad argument. >> they couldn't be without copy/pasting their implementation for every single array type you wanted to implement them for Not true, as i said there’s always been options for this: >> if we need them to be generic over argument types - in the absolute worst case (so not using go generate to help us here or an interface… Behind the scenes in the compiler, the syntactic sugar of generics are ultimately performing what you would do with “go generate“. >> in every project that wants to use them I don’t follow, why aren’t we allowed to create a library for code reuse like https://github.com/logic-building/functional-go/blob/master/fp/take.go https://github.com/logic-building/functional-go/blob/master/... has done for example?

alainx277 5y ago
I think the code you linked shows exactly why generics are needed for these kinds of methods. By introducing a single generic, you could reduce it from 500 lines to 20, and make it work for all types, not just the built-in ones. It would also remove the need to have different method names. I think that makes it less complex, as the developer doesn't need to think about the exact underlying type of the array when calling Take (which is irrelevant to its implementation).
- CraigJPerry 5y ago
  >> By introducing a single generic, you could reduce it from 500 lines to 20 No one is writing 500 lines of code - just as when you use the generics syntax you don’t write the code that is generated by the compiler in response. You could save about 10 lines, specifically these 10: https://github.com/logic-building/functional-go/blob/master/internal/generatefp.go#L238 https://github.com/logic-building/functional-go/blob/master/... You would still need the comparable ~40 lines of “generic” code: https://github.com/logic-building/functional-go/blob/master/internal/template/basic/take.go https://github.com/logic-building/functional-go/blob/master/...

alainx277 5y ago

I think the code you linked shows exactly why generics are needed for these kinds of methods. By introducing a single generic, you could reduce it from 500 lines to 20, and make it work for all types, not just the built-in ones. It would also remove the need to have different method names. I think that makes it less complex, as the developer doesn't need to think about the exact underlying type of the array when calling Take (which is irrelevant to its implementation).

CraigJPerry 5y ago
>> By introducing a single generic, you could reduce it from 500 lines to 20 No one is writing 500 lines of code - just as when you use the generics syntax you don’t write the code that is generated by the compiler in response. You could save about 10 lines, specifically these 10: https://github.com/logic-building/functional-go/blob/master/internal/generatefp.go#L238 https://github.com/logic-building/functional-go/blob/master/... You would still need the comparable ~40 lines of “generic” code: https://github.com/logic-building/functional-go/blob/master/internal/template/basic/take.go https://github.com/logic-building/functional-go/blob/master/...