[petsc-dev] PETSc future starting as a new design layer that runs on top of PETSc 3?

[Matthew Knepley]

On Tue, Jul 26, 2022 at 8:44 AM Jacob Faibussowitsch <jacob.fai at gmail.com>
wrote:

> > even more importantly we would need a huge amount of education as to
> what to use and what not to use otherwise our hacking habits will fill the
> source code with bad code.
>
> As long as you never type “new” and “delete” then you are using modern C++
> :)
>
> > Based on Jacob's contributions even "modern" C++ requires lots of macros.
>
> Not really. Most of the macros are in service of making C++-ish code work
> from C, and are used as a convenience. If I didn’t have to make the C++
> callable from C, then we could remove many of the macros.
>

But the start of this thread made clear that this is _exactly_ what we want
to do, engage in incremental development.

   Matt


> Admittedly PetscCall() and friends would need to stay (unless we mandate
> C++23 https://en.cppreference.com/w/cpp/utility/basic_stacktrace) but now
> that they are uniform it would also not be difficult to factor them out
> again.
>
> Best regards,
>
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
>
> > On Jul 26, 2022, at 09:26, Barry Smith <bsmith at petsc.dev> wrote:
> >
> >
> >   With C++ we would need good security guards on the MR who prevent use
> of the "bad old C++" paradigms and only allow use of proper modern
> techniques; even more importantly we would need a huge amount of education
> as to what to use and what not to use otherwise our hacking habits will
> fill the source code with bad code.
> >
> >  Based on Jacob's contributions even "modern" C++ requires lots of
> macros. Macros are horrible because it makes using automatic
> transformations on the source code (that utilize the language structure and
> are not just regular expression based) almost impossible. We've been doing
> some refactoring recently (mostly Jacob with PetscCall and now I am adding
> more variants of PetscCall) and we have to do them in a semi-automatic way
> with regex and manual fixes which is painfully slow and prone to error;
> plus results in the code not being updated everywhere so outdated parts
> remain hidden away for future developers to trip over.  I would really like
> to use a language without macros, not one where macros are central and
> unavoidable.
> >
> >
> >
> >> On Jul 26, 2022, at 9:07 AM, Jacob Faibussowitsch <jacob.fai at gmail.com>
> wrote:
> >>
> >> IMO C++ is the pragmatic choice here.
> >>
> >> - Anyone with a C compiler is virtually guaranteed to have a C++
> compiler these days, so no extra toolchain burden on users.
> >> - Our configure and build system already has all the infrastructure in
> place for C++ builds.
> >> - We already do half-C-half-C++ in the codebase, so users would
> actually never notice.
> >> - Modern C++ truly isn’t the unwieldy beast that C++03 was. Algorithms,
> the container library, and all the additional type safety no longer
> requires the insane template verbosity that it once did.
> >> - C++ has by far the widest user-base and adoption among all choices
> given, and given the heavy buy-in from corporate America we are guaranteed
> that C++ will see continued support for years (if not decades) to come.
> >>
> >> Best regards,
> >>
> >> Jacob Faibussowitsch
> >> (Jacob Fai - booss - oh - vitch)
> >>
> >>> On Jul 26, 2022, at 08:30, Matthew Knepley <knepley at gmail.com> wrote:
> >>>
> >>> On Mon, Jul 25, 2022 at 4:34 PM Barry Smith <bsmith at petsc.dev> wrote:
> >>>
> >>>  A  major problem with writing a completely new version of a large
> code base is that one has to start with nothing and slowly build up to
> everything, which can take years. Years in which you need to continue to
> maintain the old version, people want to continue to add functionality to
> the old version, and people want to continue to use the old version because
> the new version doesn't have "the functionality the user needs" ready yet.
> >>>
> >>> Is there an approach where we can have a new PETSc
> API/language/paradigm but start with a very thin layer on the current API
> so it just works from day one?
> >>>     • to this would seem to require if PETSc future is not in C, there
> has to be a very, very easy way and low error-prone way to wrap PETSc
> current to be called from the new language. For example, how petsc4py wraps
> seems too manual and too error-prone. C++ can easily and low-error prone
> call C, any other viable candidates?
> >>> This looked like the most promising thing about Zig. We could develop
> the new modules alongside the existing C, and throw them away
> >>> if we decide it is not worth it.
> >>>
> >>>  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
> >>>
> >>> https://www.cse.buffalo.edu/~knepley/
> >>
> >
>
>

-- 
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

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220726/3ba119ac/attachment-0001.html>