Sorry, hit send too early :) > It may be worth it if there are significant benefits in safety and static > analysis or if the tooling means contributors really have fewer moving parts.
Well for one, C ships with quite possibly the leanest standard library out there. A good chunk of the contents of _p_PetscObject exist because we needed to reimplement (from scratch!) some extremely basic functionality. A few examples off the top of my head: 1. Reference counting. Why write it yourself when you can just use std::shared_ptr. 2. The various dynamic arrays (e.g. composed scalars). Why write it yourself when you can just use std::vector. 3. The various type-names. Why manage these yourself when you can just use std::string. 4. Inheritance. No explanation needed. OK C++ is obviously not the only language that solves these problems but my point is C’s (lack of) standard library extremely limiting. Not to mention the cause of a huge number of newby bugs, because you have to reinvent the wheel on data structures that have been around since the stone ages. Best regards, Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) > On Jul 31, 2022, at 12:31, Jacob Faibussowitsch <[email protected]> wrote: > > Responding to 2 things here: > >> Jacob, would you consider VTK to be "Modern C++"? It was designed in the 90s >> and I think C++11 isn't widely used (architecturally) since it was first >> allowed a few years ago. > > > I don’t know, I have personally never interacted or read their codebase. > Certainly any library that is pre-C++11 will have old C++ cruft. To give a > counter-example, I would consider Kokkos or Thrust to be relatively modern > C++ libraries. > >> Does clang work with a high enough level of abstraction in its >> representation of C++ to map directly to Python classes, for example. > > Sure, we can walk the Clang AST. But then we are in the business of writing a > domain-specific language, and are firmly tied to a compiler. From my time > writing the clang linter I am personally very comfortable with libclang but I > can tell you that it: > > A. Takes a while to get up to speed. AST closely align with the source but > are not overly “friendly". As an example, try walking the AST backwards (to > for example find wherever a variable is written to). You’ll find this is a > monumental undertaking. > B. Many small idiosyncrasies to learn that are somewhat sparsely documented. > There are also no real “examples” to copy/learn from. > >> Does Python have any useful high-level representation that could be used so >> that we write in Python and generate from its representation? > > Yes, Python exposes the “ast” module for direct introspection of Python code > https://docs.python.org/3/library/ast.html. You can then use this to generate > arbitrary code. Team green uses this in their WARP library > (https://github.com/NVIDIA/warp) to generate CUDA kernels from python src. > But doing so has enormous pitfalls, mostly to do with optimization. Python > famously optimizes almost nothing because you can never be sure that an > expression doesn’t have a side-effect. > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > >> On Jul 31, 2022, at 12:09, Barry Smith <[email protected]> wrote: >> >> >>> My issue with C++ is not the language itself, but the lack of discipline of >>> C++ developers. There are disastrous stories we all know well. But there >>> are successful ones, like VTK/ParaView. >> >> I fear that it would be difficult to learn and maintain discipline in PETSc >> C++ developments. We are largely self-taught, want functionality quickly, >> and the google approach to learning C++ and implementing PETSc will be a >> disaster. We would need to have a starting mechanism that prevents the >> monkeys with machine guns. >> >> To do multiple language mappings properly, I think we need to start with a >> language with a powerful, high-level useful AST (or some similar >> representation) that automated tools can scarf through to generate language >> bindings and verify the code is properly written from day one. Rather than >> picking the language based on its syntax, flexibility etc, we should pick it >> based on this property. Does clang work with a high enough level of >> abstraction in its representation of C++ to map directly to Python classes, >> for example. Does Python have any useful high-level representation that >> could be used so that we write in Python and generate from its >> representation? Rust? Zig? Carbon? Fortran 2035? >> >> >> >>> On Jul 31, 2022, at 10:26 AM, Lisandro Dalcin <[email protected]> wrote: >>> >>> >>> >>> On Sun, 31 Jul 2022 at 17:07, Matthew Knepley <[email protected]> wrote: >>> On Sun, Jul 31, 2022 at 9:06 AM Lisandro Dalcin <[email protected]> wrote: >>> On Sun, 31 Jul 2022 at 16:41, Jacob Faibussowitsch <[email protected]> >>> wrote: >>> >>>> Please don't take my words as advocacy for C++ >>> >>> I’m going to pretend like I didn’t read this :) >>> >>> Whatever the final decision is, PETSc should keep providing a plain C API. >>> C is lingua franca, C++ is not. Many other programming languages have >>> runtime FFIs mostly based on the C ABI guarantees (Java, Python, MATLAB, >>> Rust, Julia, etc). C++ may be great for development, but I do not consider >>> it great for crossing language boundaries. >>> >>> Maybe the right approach for petsc4py is to first get nice and modern C++ >>> bindings implemented by wrapping the C interface. And then map these C++ >>> bindings to Python. >>> >>> My crystal ball says that such a C++ binding would eventually be thrown >>> away just as in the case of MPI. >>> >>> MPI C++ failed because it provided little added value. But if a PETSc C++ >>> API would become the base of bindings for other OO languages, then there is >>> value in maintaining these C++ bindings. >>> Furthermore, these C++ bindings could serve as the foundation for a >>> reimplementation of PETSc in C++, if that ever happens. And that can be >>> done gradually. >>> >>> PS: Modern C++ is a great language to implement stuff. People using C++ is >>> another story, it is like giving a machine gun to monkeys. Well, at this >>> point, I could say exactly the same about Python. >>> My issue with C++ is not the language itself, but the lack of discipline of >>> C++ developers. There are disastrous stories we all know well. But there >>> are successful ones, like VTK/ParaView. >>> >>> >>> -- >>> Lisandro Dalcin >>> ============ >>> Senior Research Scientist >>> Extreme Computing Research Center (ECRC) >>> King Abdullah University of Science and Technology (KAUST) >>> http://ecrc.kaust.edu.sa/ >> >
