It could be the "base" language of PETSc would be used by almost no one except the core PETSc developers. For example, a base in Rust but no rust users. One could push this a bit more to easily support "extensions" written in a variety of languages that are easily usable from any language; for example many types and implementations in Tao written in Python. But then we are reinventing SIDL; which could have worked except for that damn Java, opaque code, and stubbornness. Or bring back COBRA.
> On Jul 31, 2022, at 9:41 AM, Jacob Faibussowitsch <[email protected]> wrote: > > IMO there are 2 stakeholders to consider here: > > 1. “Individual” users > > Lisandro raises excellent points here IMO. A huge chunk of scientific > computing users primarily use Python, and the amount of HPC libraries that > are being built as a Python-frontend-to-Clike-backend is also rapidly > growing. Any language we choose should have excellent interoperability with > Python, since I would wager that outside of HPC specifically not a lot of > people are writing science code in low-level languages. And easily and naturally interact with the numerical and ML python libraries that everyone uses, which is more than just having a good pythonic API. > > 2. “Library” users: > > Another point to consider is how easy it is for *other libraries* to > integrate PETSc. PETSc certainly has a fair chunk of direct users but I > guarantee you that the vast majority of users are indirect via the many many > higher level packages (e.g. Fenics, Firedrake, libMesh, MOOSE) that build on > PETSc. Our choice of language will directly affect their continued buy-in. > There isn’t a language on the planet that doesn’t provide some kind of C/C++ > foreign function interface, but I’m willing to bet the number of languages > providing the same bindings for e.g. Julia or Rust is far lower. > >> Please don't take my words as advocacy for C++ > > I’m going to pretend like I didn’t read this :) > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > >> On Jul 31, 2022, at 09:17, Lisandro Dalcin <[email protected]> wrote: >> >> >> >> On Tue, 26 Jul 2022 at 17:35, Barry Smith <[email protected]> wrote: >> >> Bindings for Fortran 20xx, Python 3, Julia? If the bindings are not, more >> or less, automatically generated, that would be problematic. >> >> >> So far, PETSc exposes a C API. Of course it is object oriented in spirit, >> but it is not object-oriented syntactically, and zero support function >> overload, not default arguments or multiple return values, etc. because it >> is rooted in C. >> >> 1) Then you want to automatically wrap Julia, which is also not >> object-oriented, but sort of method-oriented, featuring multiple dispatch. >> 2) And also Python, which is syntactically object oriented, but has no >> built-in/easy multiple dispatch or even function/method overload in argument >> number and types. >> >> And then you realize you cannot automatically generate an idiomatic, nice >> looking, intuitive wrapper. You have to add "intellectual property" on top >> of the base C API. Exactly as I had to do with mpi4py, although I had the >> now long defunct C++ binding to provide inspiration. >> >> IMHO, the only base language that is more or less amenable for automatic >> Python binding generation is C++. Look at Qt, or perhaps better, >> VTK/ParaView. They do a great job. Why? Because C++ is relatively easy to >> map to Python (as long as your C++ API does not go crazy with templates). We >> have pybind11, for example. >> >> However, if the core of PETSc would become C++... would that still be the >> case that generating Julia wrappers is easy? Maybe yes, if the base PETSc >> C++ API constrains itself to follow a set or rules that would ease the map >> of `object.method(args, ...)` to `method(object, args, ...)` and things like >> that, but I'm not a Julia expert. >> >> PS: Please don't take my words as advocacy for C++ (although it may be the >> second worst choice after C). I'm just pointing out that mapping C -> Python >> is not so easy to automate, unless you are OK with coding Python with a >> wrapper that is C-like and thus very unpythonic. >> >> >> >> -- >> Lisandro Dalcin >> ============ >> Senior Research Scientist >> Extreme Computing Research Center (ECRC) >> King Abdullah University of Science and Technology (KAUST) >> http://ecrc.kaust.edu.sa/ >
