---------- Forwarded message ---------- From: Bryce L Nordgren <bnordg...@gmail.com> Date: Wed, Jun 27, 2012 at 3:54 PM Subject: Re: [Nix-dev] Improving the Developer Experience in the Nix Community To: 7c6f4...@mail.ru
On Wed, Jun 27, 2012 at 2:47 PM, Michael Raskin <7c6f4...@mail.ru> wrote: > >> Many webapps will need to specify that "a" database library is present, > but may not care which one. > >Heh: if the web app is so "careless" to not specify which database to use, > >there's no reason why other system components should care about a busted > web app. > > The point is: sometimes it can use whatever is available without > rebuild, so why not let user test various options faster? > Usually if a webapp does not care what specific database it is connecting to, it means that either: it has been carefully designed to only use SQL queries which work on all databases; or it can detect the difference and respond accordingly. This almost never means the webapp is busted. What it does expose is that while Nix is very good at managing tightly-coupled packages, it has no vocabulary for expressing loosly coupled packages. > > >> > - There is a simple way to derive a version of package with dependency > >> > versions changed (for use with subsituters, mainly) > >> Can you expand on this here? How would such a feature help? > >> Should I have to recompile all my *.jar files just because I upgraded > my runtime environment? I hope the answer is no! :) > >The answer depends on whether your runtime environment upgrade just > broke your jar files. > > Oh, let me create a new path with substituted dependencies and check > quickly! > > And if it doesn't break, I still save time w.r.t. a full rebuild. > +1 In addition, it's unlikely to break. Java's whole schtick is interoperability. Even though 99% of java software deployment is in binary closure form, the deployment is usually successful--even when deploying across OSes. Java binaries are loosely coupled to the JVM, and NOT coupled to the libraries composing the JVM. (e.g., it is never of any benefit to recompile a pure java app merely because one upgraded xwindows, triggering a rebuild of the JVM) The entire purpose of the JVM is to provide that adaptation and isolation layer. Same with pure python, pure ruby, pure perl, pure anything with a VM. > > >> > - There is a way to replace subsituted package with a "better" > >> > substitution or native build > >> Continuing with a Java theme: the Java Advanced Imaging interfaces have > a (default) pure java implementation as well as a native (accelerated) > implementation. > >If two application choices are equivalent, then there is no basis for > choice and either suffices. > >Coin flipping is as logical as any other choosing: revisit the meaning of > "equivalent" if you don't > >like what the coin sez. > An "Interface" is a best practice in object oriented programming. It applies here because some packages may either define (and export) an interface required by another package, or implement one defined elsewhere. The Interface never serves the purpose of helping you "choose" a particular implementation. Different implementations almost never solve the problem in an equivalent way. Interfaces let you declare that the package makes certain guarantees about the methods available and the call signatures exported from a package, without specifying all of the implementation details. They are used when there is more than one way to skin the cat.
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev