On Sun, Sep 11, 2011 at 02:50:56PM -0700, Ted Dunning wrote: > On Sun, Sep 11, 2011 at 2:37 PM, Gilles Sadowski < > gil...@harfang.homelinux.org> wrote: > > > Discussions on this list are sufficiently tense that we probably don't need > > to have a flame war on OO. :-} > > > > And I would hate to start that given that I think the discussions go too > long in any case. > > > > As for not being focused on the end user, I don't think that it is true. > > > > Well, the recent discussion of exceptions for Cholesky decomposition was a > great example. The suggestion was to throw an exception that basically said > "one number that you have no idea of is less than another idea that is an > obscure combination of stuff you input". The argument was that this was > "more precise". The user centered exception is "you input was not positive > definite".
My bad; I tried to be (too) nice to the end-user as per the numerous times repeated argument that they should not have to turn to the source code in order to figure out why their input was wrong (by input, I mean the "threshold"). If the threshold is not the end-user's business, then why allow to set it? If allowing to set it, why not report that changing it might change the behaviour? Is there is a way to deduce _the_ correct value of the threshold given the input matrix? > > Another example comes from the random distributions. The current design > separates generating values from evaluating CDF's even though users think of > those as operations on the same object. I remember that one round of this discussion happened when I started to contribute to CM. And I had been in favour of providing an interface to generated data inside the distribution objects. This led to a "sample" method being available in all those objects. Is it still not satisfactory? > Moreover, there is an intricate > lattice of (unique) implementations and interfaces that the user has to > figure out when all they want is a distribution. This isn't user centered > design. And it doesn't facilitate improvement or back compatibility. We all agree that when a single implementation of an interface exists, it should replace it. I bet that your patch to fix this will be readily applied. ;-) > > Sometimes, it's so focused towards user applications that any other > > consideration is overriden. > > > > I can't remember such a case. You don't have to remember one; the discussion happening right now about preset tables for "FastMath" is a perfect example of rushing to please a user. > > > One of the dangers of only focusing on end-users is adding features > > without > > rhyme or reason; that will ultimately leads to unnecessarily complex and > > consequently unmaintainable code, resulting in the death of the project, > > with the consequence that the beloved user will be left with nothing. > > > > That isn't user centered. User centered means implementing what the user > actually needs and will use. Need and use of a function means that it has > at least some reason. Rhyme comes from the design elements which cannot be > forgotten. IMO, this is backwards: I don't think that a general-purpose library can be based purely on practical requirements; there needs to be an overall design, which the end-user might not care about, but which will guarantee long-term viability. If the design is sound, then forgotten elements can be added easily; if they can't, that means that it's time to refactor, as I said in the previous message. > Adding frills and filips is the opposite of user centered design. What I meant is: trying to twist the design to accomodate what does not fit. [For example, compare the root solvers in CM 2.2 and in trunk.] Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
