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

[Scott Kruger]

<humor>

I have to put in a good work for Fortran.   There are many parallels in
capability with modern C++, and it only requires disregarding every
implementation method you previously know and mapping them onto keywords
that have different meanings in every other language.   The tooling is
comparable to C and C++ in many ways, and once the clang team debugs PGI's
fortran parser, flang will be every bit as good as clang (should occur
within the next funding cycle.  Or two).   For hiring young scientists to
work on future PETSc, we'd be able to tap into the surprisingly large pool
of STEM graduates who are unable to get jobs at AI startups.   We have a
prototype https://gitlab.com/NIMRODteam/nimrod-abstract that we'd love to
get feedback on.

</humor>

On Tue, Jul 26, 2022 at 8:21 AM Jed Brown <jed at jedbrown.org> wrote:

> I have to put in a good word for Rust. There are many parallels in
> capability with modern C++, but the compiler enforces many good practices
> (and guarantees safety), compiler error and warning messages are really
> useful, and the tooling is phenomenal on multiple fronts, from packaging to
> refactoring to documentation and testing. We have a prototype
> https://github.com/petsc/petsc-rs that we'd love to get feedback on.
>
> On Tue, Jul 26, 2022, at 8:07 AM, Jacob Faibussowitsch wrote:
>
> >  And for programmers today who program by googling, googling does not
> distinguish between good modern C++ solutions and crappy 15 year old
> solutions that still work but should not be used today.
>
> Sure, all jokes aside the difference between old and modern C++ is broadly
> speaking:
>
> 1. If you find yourself specifying the type, you are using old C++ ->
> always prefer auto, and duck typing
> 2. If you find yourself managing memory directly, you are using old C++ ->
> always prefer smart pointers
> 3. If you find yourself calling begin/end, acquire/release, do/undo
> function pairs you are using C -> prefer to wrap everything in RAII types.
>
> The ability to forgo types and write generic algorithms that only require
> *functionality* (and being able to assert this at compile-time) rather than
> a specific type name. Having an explicit memory ownership model that is
> enforced by construction via smart pointers. Making it impossible not to
> clean up after yourself via RAII.
>
> All “modern” C++ does is make the above more ergonomic and easier to do.
>
> Best regards,
>
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
>
> > On Jul 26, 2022, at 09:55, Barry Smith <bsmith at petsc.dev> wrote:
> >
> >
> >
> >> On Jul 26, 2022, at 9:43 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++ :)
> >
> > As joke, this is good, but reality is that C++ has 30 years of
> accumulated junk, and I don't know of any automated way to prevent the use
> of that junk from being used in PETSc, there is no C++ compiler flag
> --std-no-old-junk. And for programmers today who program by googling,
> googling does not distinguish between good modern C++ solutions and crappy
> 15 year old solutions that still work but should not be used today.
> >
> >>
> >>> 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.
> >>
> >> 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.
> >
> > PetscCall is because C does not have exceptions. Presumably, a modern
> C++ PETSc would use exceptions for all error handling so would not need
> PetscCall and friends at all? The stack on error would be handled in a
> modern C++ way.
> >>
> >> 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/
> >>>>
> >>>
> >>
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220726/f2a7b24f/attachment.html>