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/ <http://www.cse.buffalo.edu/~knepley/>
