since developing object oriented software is so cumbersome in C and we are all resistent to doing it in C++

[Alex Peyser]

Have y'all considered a different approach? 

I've had endless trouble integrating petsc into my system because the "object-
oriented" C is both only partially "object oriented" while simultaneously 
making access to the underlying functionality obscure. Some "objects" have 
some methods, and others are missing; some have the same functionality through 
higher level interfaces or lower level interfaces... and so on.

Maybe you need to split this into two projects -- one a set of normal C 
interfaces to the kernels, communications, etc -- the underlying functionality 
-- and a separate "object oriented" layer on top of it written in whatever 
language you prefer (I find python to be a very, very evil language, but y'all 
seem to have a taste for it).

This would both allow the functionality to be adapted to multiple overlaying 
interfaces, and keep the low overhead to initial adoption. It seems that the 
current approach is a shoe horn of both very low level and high level behavior 
into the same programming paradigm -- which always leads to a coding mess.

It seems particularly ugly to bind low level languages such as C++ and Fortran 
onto a higher level, interpreted language like Python -- binding C onto python 
which then binds onto C! And then binding any other language would be a 
sequence of binding X onto C++ to bind onto python to bind onto C!

Alex Peyser

On Friday 04 December 2009 11:42:35 pm Barry Smith wrote:
>     Suggestion:
> 
> 1) Discard PETSc
> 2) Develop a general Py{CL, CUDA, OpenMP-C} system that dispatches
> "tasks" onto GPUs and multi-core systems (generally we would have one
> python process per compute node and local parallelism would be done
> via the low-level kernels to the cores and/or GPUs.)
> 3) Write a new PETSc using MPI4py and 2) written purely in Python 3000
> using all its cool class etc features
> 4) Use other packages (like f2py) to generate bindings so that 3)
> maybe called from Fortran90/2003 and C++ (these probably suck since
> people usually think the other way around; calling Fortran/C++ from
> Python, but maybe we shouldn't care; we and our friends can just be 10
> times more efficient developing apps in Python).
> 
>     enjoy coding much better than today.
> 
>   What is wrong with Python 3000 that would make this approach not be
> great?
> 
> 
>     Barry
> 
> When coding a new numerical algorithm for PETSc we would just code in
> Python, then when tested and happy with reimplement in Py{{CL, CUDA,
> OpenMP-C}
> 
> The other choice is designing and implementing our own cool/great OO
> language with the flexibilty and power we want, but I fear that is way
> to hard  and why not instead leverage Python.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091207/e2c01c1d/attachment.sig>