fenics team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxxxx>]

"tomtzigt" <tomtzigt@xxxxxxxxxxxxxxxx> writes:
>   Another sobering statistics is that for every line of code in the main
> branch there are three lines of code needed in the infrastructure (build
> system, regression system, QA, release engineering, etc.). The bigger your
> system gets the more inertia the support system exerts on the core. Given
> these statistics, and limited resources, you are effectively forced to
> concentrate on doing few problems well. But you can expand your world of
> influence by 'solving' integration problems with other efforts. This has a
> secondary benefit and that is that trying to solve the integration problem
> you get a close up view of another 'interpretation' of the same problem:
> both in terms of software engineering as well as in mathematics. This
> experience is very valuable and is gained in much less time then if you had
> to do the whole package yourself. As the saying goes: A fool learns from his
> own mistakes, but a genius learns from mistakes other people make.

  While this might convince a lot of people that configure, build, and packaging
are inherently complex, I believe that no real hard thinking has been put into
these components. Instead, we see slavish reproduction of what shuold have been
throw away ideas and prototypes. Witness the longevity and dominance of make.
Hopefully we have the courage to reinvent these broken systems in the same way
that we plan to reinvent numerics. To reiterate, I do not believe that WE need
to concentrate on a few problems, unless by that you mean first order nonlinear
PDEs. We should allow anyone to easy construct and solve these. Its important
to motivate ourselves with problems, but not to make them the focus of the system.

     Matt
-- 
"Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness