Hi all, Le 04/01/2015 02:07, Gilles a écrit : > On Fri, 02 Jan 2015 14:45:15 -0700, Phil Steitz wrote: >> I am thinking about submitting a proposal or two for Austin. I >> could update / extend the pool/dbcp talk I did last year or try a >> [math] talk. I would love to have company developing and / or >> presenting either of these. Is anyone else interested in working on >> a talk on either of these? Any suggestions on content? >> >> For [math] I have always wanted to do a high level overview followed >> by some real world examples. It would be great to make the examples >> part a community effort. > > It reminded me that I had yet to improve one toy example in the > "src/userguide/java/org/apache/commons/math3/userguide" section > of the repository. > It also occurred to me that I don't know how to compile and run > the applications stored there. :( > Is there a maven incantation to do so?
No as maven does not know about this directory (and should not IMHO). > >> >> For [pool] / [dbcp] I did the boring part last year - summary of >> changes in the 2.x versions, migration, etc. - so this year I could >> focus on examples and best practices. Again, a great thing to work >> together on. >> >> Another crazy idea I have had is a talk on how hard it is to design >> stable APIs, using [math] as an example. > > Is it really hard? Isn't it rather that some developers just lack > the willpower to support less than ideal APIs? :-} Yes, it is hard. > >> That talk would also call >> out some of the special challenges that you run into modelling >> mathematical objects using OO constructs. > > That would be interesting. > Are mathematical concepts really more special to model than other > concepts? No, the problem is that low level reusable components intended to be used by lots of different users for lots of different needs are difficult to set up. You have to meet conflicting needs and the developers do not know in advance how their code will be used. In many cases, things start with "someone scratching an itch" because open-source developers are the first users of their stuff. The resulting API is biased towards this first need. Low level reusable components developers have to make lots of efforts to design something clean enough to anticipate other uses. Even experienced low level reusable components developers don't succeed in this part. > I rather think that the issues arise from trying to sort out the > general from the particular, trying to implement generic algorithms > to solve as many practical problems as possible. Perhaps, but it is really an important need for reusable components. Another problem is that not moving forward (typically still staying in the 3.X series instead of starting 4.0) creates additional constraints. Trying to patch something wrong is much more difficult than rewriting it, and sometimes it is even completely impossible if wrong design choices cannot be changed. > This quite naturally lead to desing decisions that may be challenged > by the appearance of unforeseen cases (or better programming skills). Exactly. However, I prefer to say that here is the problem, and it is a challenge we have to consider rather than saying it is something we don't want to cope with so we ignore the problem and don't care about users apart from our own needs. > >> Might be a little painful >> to develop, but also maybe a little cathartic ;) > > It would certainly be useful to understand where the pain really > comes from. There is an old joke I have heard numerous times in different activities (including outside of software development): remove the user and everything gets way better. best regards, Luc > > > Regards, > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
