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.
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. On Wed, Apr 30, 2014 at 11:30 AM, Oliver Woodford <[email protected] > wrote: > On Wednesday, April 30, 2014 3:46:54 PM UTC+1, Jacob Quinn wrote: >> >> function frob(x::Array) >> isleaftype(eltype(x)) || error("Homogeneous array required')? >> >> Though, IMO, this is all a non-issue in my experience. Just specifying >> frob{T<:Real}(x::Vector{T}) gets you exactly what you want--the ability to >> have JIT generate fast, efficient code for a range of types that the user >> can specify. The fact that this has never come up before or in any package >> implementations, to me, indicates that this issue if more of getting used >> to idiomatic Julia and spending some time playing with parametric types and >> the interactions with the type hierarchy. >> > I come from a non-technical background and at first, the idea of >> parametric functions/types was a little wild and hard to wrap my head >> around, but after reading through the manual several times (which has a lot >> of great stuff!) and developing my own non-trivial codebase (Datetime.jl), >> I feel I'm comfortable with use cases and how they work in general. I think >> if you spend some more time developing code, poking around popular packages >> and Base, you'll come to find that there isn't really anything broken here >> (though quite possibly some things that need cleaned up a little). >> > >> Cheers, >> >> -Jacob >> >> > > I have started developing my own non-trivial code base, which is what > prompted me to start this thread. I also have a technical background. > > You don't care whether someone uses homogeneous or heterogeneous arrays. > Maybe you think it's their problem if they make things slow. I want to make > them aware of it. On that we differ. > > What I find absurd is that, rather than accept that different position, > based on the explanation I have given (to make things fast), or make a > point which invalidates my argument, you attempt to explain away this need > by the fact that I am new to the language and that I'm simply not used to > it. > > You have taken a very concrete point that I make, and attempted to dismiss > it with the suggestion that I simply don't know what I'm talking about. Not > at all constructive. > >
