changes for next PETSc release

[Matthew Knepley]

On Mon, Mar 17, 2008 at 12:27 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>  >> 2) properly name-space PETSc by putting a Petsc in front of all PETSc
>  >> objects, function names etc
>  >>      (this will require changing a few names also to keep them below
>  >> the 32 character limit). This will
>  >>      be very painful change for some users who are not comfortable
>  >> ever changing code, hence I hesitate
>  >>      to do it, but it is the right thing to do and should have been
>  >> done originally.
>  >
>  > I guess I still do not see the need for this. NIMROD is a not a
>  > sufficient
>  > driver in my mind.
>
>     You are an elitist who thinks that important ideas can only come
>  from important/smart people. This I disagree strongly with, one should
>  look everywhere, even at the local dump, for good ideas. NIMROD is
>  not the driver, it is merely the spark.

I will be more specific. I think there is no good idea connected with this
requirement of NIMROD. In fact, I think it is a very very bad idea. They are
using a language with namespaces (F90) but they ignore them. Then they
wonder why uses a product from a language without namespaces (C) they
have a problem. The wrong strategy is to do something complicated in the
deficient language. The right thing to do is something easy in the language
with support.

Why can't we just do an F90 binding with namespaces? That would fix NIMROD
and not disrupt the community who has not complained (and who is much
much bigger).

>  > If we really want namespaces, use a real language that
>  > has namespaces. There are plenty. If we are still using C, I say we
>  > stick
>  > with the old division. The imposition of this much pain on the
>  > overwhelming
>  > majority of users seems unjustified.
>
>     You seem to be saying we should stick with a bad decision I made
>  many years ago, just because it is painful to change. When did you
>  suddenly become conservative?

No, I am saying that the fix is crap because it is complicated, entails
enormous changes to the code, and is ugly. I think the correct fix is
to use nice mechanisms in languages that support them, like C++.
I am completely against forcing weak language mechanisms to do
complicated things, which is why I hate all those template tricks.

Also, we should look at history. We have made mistakes in the past
when changing the interface (KSPSolve() with no arguments) which
were painful. I want to make sure what we choose to do is as simple
and non-painful as possible.

   Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener