@vzarytovskii@Savlambda Harder to grasp for newcomers? I think it's the opposite, I can tell you from my experience, I still remember many years ago the first time I worked with generics in .Net that it was actually tricky to me to understand why I can be generic in 'T in List<'T> but not in 'T<'V>
@JaggerJo1 @7sharp9_ I don't think it's a massive dependency. It's just a lib, not a framework so it's very easy to remove, just replace the functions by their definition. Then of course, it depends on how many functions you use, but that applies even to small libs.
@CaptnCodr@dsymetweets@_cartermp@ttliu2000 I agree Don, if that's the context. I like the cathedral analogy, except that in this case the preachers seems to be outside the cathedral :) I was always honest about the bricks.
@dsymetweets@_cartermp@ttliu2000 Still, I can hear your critics and will commit to improve the situation awareness, but you have to listen to the other side as well. When many people demand the same thing, don't fall into easy-thinking they are just plain wrong.
@dsymetweets@_cartermp@ttliu2000 Don, what I want to say is, don't take a specific scenario (even if you think it's the most common) and assume that everybody have the same concerns. Requirements are not the same, for a large production code base than for say, exploratory scripting or python like numerical code.
@_cartermp@dsymetweets@ttliu2000 So, in that sense I do think it's less work to use F#+ generic stuff, get a feeling of what is and eventually it makes it very easy to specialize it at the end. I think it's way less painful that going on your own. Of course we can give guidance by writing recommendations in docs
@_cartermp@dsymetweets@ttliu2000 I think writing your own SRTP code is like starting to re-invent the wheel, at the end most people will end up with a similar solution, but it's a very hard and long road, believe me, and at the end you'll have the same problems and end up removing it by specializing your code.
@atsapura@dsymetweets@_cartermp@ttliu2000 I wouldn’t be surprised. A library alone doesn’t solve any problem. It’s both the lib + a good dev who understands how/where/what to use what is needed in order to add value.
@dsymetweets@_cartermp@ttliu2000 No worries. Let's add a recommendation section very visible in the docs and see if we can reach a good level of compromise between both positions.
@dsymetweets@_cartermp@ttliu2000 I think that won't apply to all the generic modules, some of them are very stable and well behaved, with the drawbacks you already mentioned, but in some scenarios they don't apply (scripting, prototyping).
@dsymetweets@_cartermp@ttliu2000 I see what you mean, but that won't be 100% true. That applies to specific modules, not to the whole library. If so, I personally don't have any issue with that.
@dsymetweets@_cartermp@ttliu2000 Here's another basic principle. The less generic your code is, the cleaner error messages you get. That's the tradeoff and you decide where you stand, no one force you. Not even this library. All generic functions have a non-generic counterpart consistently organized.
@dsymetweets@_cartermp@ttliu2000 The key difference with F# core philosophy (and other libs) is we promote good coding by educating rather than hiding. Of course, guidance and good use of the library can still be improved, I would appreciate contributions in that direction as opposed to non-constructive critics.
@dsymetweets@_cartermp@ttliu2000 I do use F#+ in production and we don't have any of those issues. The thing is the lib is not opinionated, you should be responsible of which part of the lib you use, how and in which context. For instance I use generic functions mainly in short scripts.