[petsc-dev] "Libraries don't have to suck"

Karl Rupp rupp at mcs.anl.gov
Sat Dec 8 20:05:04 CST 2012


Hey,

this thread is sufficiently young such that I add some interesting 
statement from LLVM rather than opening a new thread:

"Another major aspect of LLVM remaining nimble (and a controversial 
topic with clients of the libraries) is our willingness to reconsider 
previous decisions and make widespread changes to APIs without worrying 
about backwards compatibility. Invasive changes to LLVM IR itself, for 
example, require updating all of the optimization passes and cause 
substantial churn to the C++ APIs. We've done this on several occasions, 
and though it causes pain for clients, it is the right thing to do to 
maintain rapid forward progress. To make life easier for external 
clients (and to support bindings for other languages), we provide C 
wrappers for many popular APIs (which are intended to be extremely 
stable) and new versions of LLVM aim to continue reading old .ll and .bc 
files."

as well as

"Despite its success so far, there is still a lot left to be done, as 
well as the ever-present risk that LLVM will become less nimble and more 
calcified as it ages. While there is no magic answer to this problem, I 
hope that the continued exposure to new problem domains, a willingness 
to reevaluate previous decisions, and to redesign and throw away code 
will help. After all, the goal isn't to be perfect, it is to keep 
getting better over time."

(Page 3 in [1])

The whole article is a good read. Modularity and reusability don't seem 
to be something compiler people outside LLVM have really cared about (I 
haven't checked this claim, though).

Overall, the take-away is that they also argue in favor of preserving a 
clean and consistent design even though it requires to sacrifice 
backwards compatibility. Also, they are aware of the hassle for their 
users and try to make the transition less painful. A similar model 
should work with PETSc, e.g. by using pragma messages to point at 
deprecated functionality for a while. This would allow users to still 
obtain an executable when moving to a newer version, but at the same 
time gives them a clear indication that they should migrate to using the 
new interface soon (and not necessarily *immediately*).

Best regards,
Karli


[1] 
http://www.drdobbs.com/architecture-and-design/the-design-of-llvm/240001128
[2] http://blog.llvm.org/2011/12/nvidia-cuda-41-compiler-now-built-on.html


On 11/26/2012 06:08 PM, Jed Brown wrote:
> Point in favor of evolutionary libraries over the Matryoshka dolls that
> arise when interfaces are frozen forever.
>
> http://akkartik.name/blog/libraries2




More information about the petsc-dev mailing list