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

[Karl Rupp]

Alright, then let's have it this way. :-)




 >>    It won't fix any complaints because people will just live with 
their out-of-date code until we remove the legacy support and THEN they 
will complain. (And by then we'll have half-forgotten what we did so it 
will be harder to help people with their complaints). Far better to 
force them to change immediately then to drag it out.
>
> I agree with Barry here. All these measures are made for conscientious
> users who read the release notes
> and look at warnings. They are wonderful, however like Santa, they
> also do not exist.
>
> It has to work for the worst (automatic conversion), or its not worth it.
>
>     Matt
>
>>     Barry
>>
>> On Dec 14, 2012, at 4:13 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
>>
>>> Hey,
>>>
>>> On 12/13/2012 03:46 PM, Jed Brown wrote:
>>>> I'm sure that users would appreciate one release of deprecation. It's
>>>> not hard to implement when deprecating a routine entirely, but it's
>>>> trickier when changing the interface to an existing routine. It can be
>>>> achieved through a "feature test macro" that asks for the old version,
>>>> though this still requires that the user "change their code" (or
>>>> preprocessor definitions) to build with the new version. Some projects
>>>> include the version number in the API, but that looks ugly and confusing
>>>> to the user, especially after the old version has been removed.
>>>
>>> I'm also in favor of offering a 'grace period' for the main user functions, at least for the most frequently used. I don't have a good strategy for dealing with changes to existing functions at hand, though.
>>>
>>>
>>>> It's technically feasible for PETSc to offer this, but it's still not a
>>>> trivial amount of effort and doesn't fix all the user's complaints.
>>>
>>> If it fixes half of the user complaints we would get otherwise, it's probably already worth the effort...
>>>
>>> Best regards,
>>> Karli
>>>
>>>
>>>>
>>>> On Sat, Dec 8, 2012 at 6:05 PM, Karl Rupp <rupp at mcs.anl.gov
>>>> <mailto:rupp at mcs.anl.gov>> wrote:
>>>>
>>>>     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
>>>>     <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
>>>>     <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
>>>>         <http://akkartik.name/blog/libraries2>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which
> their experiments lead.
> -- Norbert Wiener
>