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

[Boyce Griffith]

> On Jul 26, 2022, at 9:55 AM, 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.

clang-tidy can help with setting/enforcing C++ coding standards and avoiding some “old” C++ conventions / suggesting “modern” replacements.

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