Hello.
On Sun, 04 Jan 2015 12:09:35 +0100, Luc Maisonobe wrote:
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).
I think that we should have some way to
1. automatically compile its content (so that we can ensure that the
source tree does not contain any non-compilable stuff) and
2. run selected classes (so that users easily see CM code at work)
It looks like it should not be too difficult (for an experienced
maven user, which I'm not) to create a profile for doing just that.
[I've seen there is an "exec" plugin that could do (2), but I
couldn't find where one can specifytan alternate source for
compilation.]
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.
I wanted to stress exactly what you expand below, i.e. that needs are
changing, and that if we want to combine all the qualities of good
code (a.o. code that evolves with the developers' community, with
the users' community, with the language's state-of-the-art, with the
computers' power, etc.) we have to modify the APIs; it is a never
ending, but creative, task.
The alternative is, as I wrote above, to stick with less-than-ideal
APIs, and _that_ is not hard; but it is a dead end.
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.
That's what I wrote below: "trying to implement generic algorithms
to solve as many practical problems as possible".
Thus: it is good to have generic, reusable, code (e.g. just from a
maintenance POV), but it at some point, it will conflict with
unexpected usage. Hence API change will be in order.
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 totally and did not say otherwise.
The wrong way would be to have duplicate code all over the place to
tak care of each new usage. Since we try to avoid that, we'll need
to refactor when the "genericity" in one direction conflicts with
unanticipated usage.
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.
From a development POV, I thinks so too.
For black-box users, it is not. [They don't care about what's in the
box as long as it does the job; and "no duplicate code" is, for
instance, not a requirement. But this a short-term view, since
maintenance will suffer and loss of quality will ensue.]
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.
+1
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.
So, we perfectly agree: i.e. we do not have the willpower to maintain
old cruft! :-)
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.
Sure (including us!).
But my question was real: we cannot make the user disappear, nor
all the reasons why we write programs, so we have to let the APIs
evolve. Why is there such pain in doing so?
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
