Currently package are referred to by unique hash that sort of works this way, but there are few unfortunate restrictions in GHC and cabal that need to be lifted to allow future installations to not conflict with past installations (multiple instances of the same version, right now there can only be one foo-0.1.0.0 even though it also has a unique hash).
I think for modules to help here, the interface would have to not change between versions, useful for ByteString, not so much for Yesod.
As it stands now, cabal's constraint solver will prevent the installation of a package that indirectly depends on two different versions of the same package. This is too bad, because it is not necessarily true the package will fail to install.
Ideally cabal could somehow know which types are exported and which are not. In lieu of that, I personally I would prefer to have a chance of a successful install, and get a compiler error if things really do conflict, instead of a conservative constraint solver error.
Sandboxing is merely a stop-gap to reproducible builds (I hope). Nix style multiple instances of the same version of an installed package will lead to better reuse, thus faster builds.
If the fingerprints can be made precise enough, binary caches can be distributed from trusted parties, similar to what other package managers do.
> But i'm so tired of those preordering-sites.. really, i want to order your stuff. now.
Agreed, but unfortunately the business environment has changed. The cost to start a business has decreased so much it is much harder to convince investors to drop a few million into something when there are so many cheaper alternatives.
Additionally everyone is doing preorders, and you are not, you are probably at an disadvantage.
> And if you need additional funding to make your vision happen, sites like kickstarter offer a clean and generally well understood way of making that happen.
> It's not easy to interpret these numbers and you have to have quite a deep understanding of statistics, i.e you can be in the normal range and be sick, and you can be outside and be healthy. Type i/ii errors, precision, accuracy, calibration etc etc. I'm sure hackernews knows what's up I'm sure.
Doctors mathematical abilities are less than legendary. I would rather own the raw data and choose my own method of analysis.
> It's said about 90% of all diagnosis can be made only on taking the history. Tests are normally only done to assure, quantify, guide treatment etc.
This is an argument for this device. Having something at home that you can use to test on regular basis will give you the rich historical data you need to make a better diagnosis.
The goal is to discover a problem before you are sick enough to feel the need for constant testing.
The tests seem to interest different groups. I imagine these are the first of many different types of tests planned. You are right about glucose, they probably didn't go there yet because of the competition.
A lot of you arguments are "if you want this tested go to the doctor." Really? do you know what a pain in the ass it is to go to the doctor? First I have to take of work, then I have to wait for him. Then I have to talk to a doctor or nurse about my concerns only to have them act like they are unimportant. Of course there is the cost. Honestly as a consumer I find going to the doctor to be one of the most annoying experiences.
Yeah its a bullshit line. There are certain class of functions in Haskell that can be completely derived from their signature (see djinn) but Haskell's type is not strong enough for automatic formal verification.
I would prefer is people just said "I program faster in Haskell"
We manage all deps in our cabal file, and have scripts to make sure that what is in package database matches the cabal file (this way we can upgrade versions without manually unregistering and reinstalling).
Like you said, there is nothing seamless that is part of cabal ... yet. I would like improve our workflow and integrate it into cabal.
Haskell could still benefit from a larger community. We have had to write some key low level tech, but we have been able to do so at an incredible pace.
The /dev/urandom bug mentioned was caught by us because we are one of the few places using Haskell that also has a fairly large user base. If the community was larger we would have run into less issues.
That said, we have run into a surprisingly few amount of issues :)
We have a simple mechanism for controlling access to IO.
There are a series of type classes that provide access to all of the IO based services (mysql, redis, memcache, etc.). All of the request handlers are written to use these type classes not IO. There are two instances of the type classes, one pure for tests using fakes, and one real using IO.
FWIW one reason the service mentioned in the blog was so fast was because of laziness. Because it didn't need most of the request, the work required to parse it was mostly avoided.