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

[Barry Smith]

> 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 <dalcinl at gmail.com> wrote:
> 
> 
> 
> On Sun, 31 Jul 2022 at 17:07, Matthew Knepley <knepley at gmail.com <mailto:knepley at gmail.com>> wrote:
> On Sun, Jul 31, 2022 at 9:06 AM Lisandro Dalcin <dalcinl at gmail.com <mailto:dalcinl at gmail.com>> wrote:
> On Sun, 31 Jul 2022 at 16:41, Jacob Faibussowitsch <jacob.fai at gmail.com <mailto:jacob.fai at gmail.com>> 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/ <http://ecrc.kaust.edu.sa/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220731/77959a34/attachment.html>