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

[Barry Smith]

   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 <jacob.fai at gmail.com> 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 <dalcinl at gmail.com> wrote:
>> 
>> 
>> 
>> On Tue, 26 Jul 2022 at 17:35, Barry Smith <bsmith at petsc.dev> 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/
>