fenics team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxxxx>]

Kevin Long <krlong@xxxxxxxxxx> writes:

> On Tuesday 27 September 2005 10:17, Matthew Knepley wrote:
>>
>>   Solved is something I reserve for math problems (even there it is dicey),
>> but engineering solution "do better". We definitely kick autoconf's butt,
>> and nothing comparable exists in Windows since they have such ironfisted
>> control. I will talk about this at FEniCS '05.
>
> Matt,
>
> I wholeheartedly agree with your contention that the abysmal state of systems 
> codes can be improved by the same sort of careful CS design we're trying to 
> do in our FE codes. 
>
> For example, a few years back, Paul Boggs and I did this with GUI design: we 
> wrote a code that read an XML description of the task the GUI was to 
> accomplish and produced the Java components to carry it out. Our foray into 
> GUI-land was spurred by a desire within Sandia to have GUI interfaces for 
> optimization. Since we had no intellectual interest in writing such a GUI, we 
> decided to slay the beast once and for all by writing a single code to write 
> GUIs for us. Unfortunately, once we did the proof-of-concept code we were 
> never able to find a suitable programmer to hand it off to for transition to 
> production: the good Java coders at Sandia didn't think at the level of 
> abstraction required to understand our approach. Paul and I of course wanted 
> to get back to mathematical software, so we dropped it and the code now lies 
> on a disk somewhere unused. I still think it was a nice piece of CS work, 
> though.

  Very cool. I know that Paul DuBois had a similar effort at Livermore, but
of course it made Python GUIs from XML.

> This same basic idea -- solve a general problem once, abstractly -- can be 
> applied throughout systems programming as you have done with your configure 
> system. As bad as they are, even the horrible autoconf/automake system and 
> the less-horrible-but-still-bad make system were first attempts at 
> generalizing certain systems tasks rather than writing a bunch of one-off 
> scripts.

  True, even Perl was beautiful once. I respect the original autoconf, I just
think it betrayed its mission. Reading the original help, the idea was to TEST
everything, rather than read a sort of database of settings as Larry Wall's
competitor at the time did. However, all too often, autoconf goes back to the
database approach when the going gets tough. I'd like a roundtable at the
FEniCS get together about abstractions for build since I still do not have
great ones there.

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