On Wednesday, April 30, 2014 4:44:53 PM UTC+1, Stefan Karpinski wrote: > > I think this suggestion was based on Jacob's personal experience – which > others seem to have also had – that after a bit of time letting the > language wash over you Julia, things that seemed problematic > or disconcerting early on have a way of not seeming important anymore. > That might or might not happen for you with this particular issue. >
I understand, but I think it helps to counter arguments that have been made before resorting to more prosaic explanations. After all, we don't all have the same experiences, but we can all agree on whether homogeneous arrays are more efficient. IMO it didn't help the discussion and detracted from from the valid points I made (which, granted, annoyed me). Hence my rebuttal. > Personally, I don't think library code should be forcing arrays to have > concrete element types. Is the library going to raise an error? If so, > you're needlessly forcing the user to either not use the library or modify > it to excise the pointless check. That seems bad. Is it going to print a > warning but let you continue? That's going to be annoying, although at > least I guess the user definitely knows they have a array with abstract > element type. But is this really your place to warn them? This seems to > treat the user like a child – shouldn't a library assume that the user is > doing things for a reason and not by mistake? Since the main concern with > heterogeneous arrays is performance, I feel that should be discovered via > benchmarking or other performance analysis tools, not because some library > is feeling avuncular. > > The Julian approach. Catchy. I can certainly understand your point of view on this. However, why shouldn't it be the library's place to tell it's users how to make it run faster? The argument of treating the user like a child is an exaggeration, of course. You're treating them like someone who doesn't appreciate the efficiency savings of homogeneous arrays over heterogeneous ones. For the people that applies to, I suspect they'd appreciate the tip. I suppose the only real argument is that some advanced users may have a real need to pass in a heterogeneous array, and the library wouldn't let them. But then you're weighing up that risk against helping less advanced users (and even advanced users who've accidentally allowed an array to be heterogeneous) use it efficiently. It's not a clear cut decision; it's very subjective. Yes, benchmarking is another useful tool that help users improve performance, but it's not an argument as to why libraries shouldn't. So I think this is a situation where we can agree to disagree. An avuncular library - catchy too! The TypeCheck package sounds good. Does it check for homogeneity of arrays? Even so, for a library that would be impossible to catch when the heterogeneous array was be being passed in through the API, so then you're again relying on users to run that on their particular program. Will they?
