On Jun 27, 2012, at 5:55 PM, Bryce L Nordgren wrote: > > > ---------- 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. >
The idea that SQL is "portable" is a pleasant fiction (having just spent a month digging through ODBC). The abstractions don't exist in most cases for web apps not to care. > 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. > Well tightly coupled is the harder problem to solve accurately: good for nix. > > >> > - 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. > None of which works too well in practice (though java is certainly farther along than other languages). > Same with pure python, pure ruby, pure perl, pure anything with a VM. python isn't compatible with itself because of 3.0. ruby is even more of a mess with rvm and per-user shadow trees that include multiple versions of everything to satisfy the pretense of "pure". Again: java is quite a bit closer than other languages, but the goal of "pure anything" hasn't been sufficiently achieved. > > > > >> > - 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. > If you believe "object oriented" is an adequate definition for "interface" that can also permit a choice between -- otherwise equivalent -- implementations where one happens to run faster, well … we aren't talking about anything real. 73 de Jeff
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
