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

[Jeffrey Johnson]

On Jun 27, 2012, at 5:55 PM, Bryce L Nordgren wrote:

> 
> 
> ---------- 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.
>  

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120627/cb9f666f/attachment-0001.html