fenics team mailing list archive

["tomtzigt" <tomtzigt@xxxxxxxxxxxxxxxx>]

Matt:

  I think I understand where you are coming from but I just want to make
sure: are you saying that the support systems that surround a typical code
are frequently anemic and are rehashed where it should have been redone?

  I am very interested in hearing your thoughts on how you have solved the
build and configuration problem: we spent millions of dollars a year on this
problem, and if there is a solution, I would like to know!

Theo

P.S. the reason why make is still so ubiquitous is that when you start with
an OS port, particularly in the old UNIX days, you tend to bootstrap the
whole development with make. You have your hands full with getting the
kernel going that you really didn't have time or interest in first rewriting
your build environment. Now all the developers are proficient with make, and
the rest is then simple familiarity. This is still happening today when
folks are creating new sw development environments for embedded devices. 
  

-----Original Message-----
From: Matthew Knepley [mailto:knepley@xxxxxxxxxxx] 
Sent: Monday, September 26, 2005 9:43 PM
To: tomtzigt
Cc: 'Robert C. Kirby'; 'Anders Logg'; 'Kevin Long'; karpeev@xxxxxxxxxxx;
'Discussion of FEniCS development'
Subject: Re: [fenics-dev] Re: FEniCS

"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