Bindings for Fortran 20xx, Python 3, Julia? If the bindings are not, more or less, automatically generated, that would be problematic.
> On Jul 26, 2022, at 10:20 AM, Jed Brown <j...@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 <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 <bsm...@petsc.dev >> > <mailto:bsm...@petsc.dev>> wrote: >> > >> > >> > >> >> On Jul 26, 2022, at 9:43 AM, Jacob Faibussowitsch <jacob....@gmail.com >> >> <mailto: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++ :) >> > >> > 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 >> >> <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 <bsm...@petsc.dev >> >>> <mailto: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 >> >>>> <mailto: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 >> >>>>> <mailto:knep...@gmail.com>> wrote: >> >>>>> >> >>>>> On Mon, Jul 25, 2022 at 4:34 PM Barry Smith <bsm...@petsc.dev >> >>>>> <mailto: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/ >> >>>>> <https://www.cse.buffalo.edu/~knepley/> >> >>>> >> >>> >> >> >> >
