I think it would be reasonable to say PETSc future uses PETSc old (including new features that may be added to PETSc old for a couple of years) but that PETSc old cannot use PETSc future. As Jacob says. Going both ways seems like an unneeded burden.
Barry > On Jul 26, 2022, at 9:55 AM, Jacob Faibussowitsch <jacob....@gmail.com> wrote: > >> engage in incremental development. > > Incremental development that goes the other way though (unless I have > misunderstood) i.e. you have base C-code that is called from C++. If you need > C++ from C, then you need macros to generate the stubs for each instantiated > template, but if you need C from C++ then you can simply overload (no need > for macros). > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > >> On Jul 26, 2022, at 09:51, Matthew Knepley <knep...@gmail.com> wrote: >> >> On Tue, Jul 26, 2022 at 8:44 AM Jacob Faibussowitsch <jacob....@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 <bsm...@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....@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 <knep...@gmail.com> wrote: >>>>> >>>>> On Mon, Jul 25, 2022 at 4:34 PM Barry Smith <bsm...@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/ >
