[Nix-dev] Fwd: Improving the Developer Experience in the Nix Community

[Bryce L Nordgren]

---------- Forwarded message ----------
From: Bryce L Nordgren <bnordgren at gmail.com>
Date: Wed, Jun 27, 2012 at 3:54 PM
Subject: Re: [Nix-dev] Improving the Developer Experience in the Nix
Community
To: 7c6f434c at mail.ru




 On Wed, Jun 27, 2012 at 2:47 PM, Michael Raskin <7c6f434c at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120627/b1227a1d/attachment.html