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.
Hopefully we can also get real module interfaces[0] in the not-too-distant future so we can at least lessen some of the spurious diamond dependency problems that tend to crop up once in a while.
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.
Certainly it's not going to be a panacea, but if you are familiar with O'Caml or SML you can hopefully sort of see how it's going to be of immense help when dealing with "trivial" package upgrades and such.
Hopefully Yesod will also (if/when this Backpack thing comes to fruition) expose some sort of stable interface for, say, the 5.x series. I think Michael has been very good about keeping things compatible, given the current constraints on the ecosystem, so I imagine he'd be very interested in declaring a stable interface explicitly if that were possible.
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).
Note that it's not optimal either, a small variation in a root dependency can trigger the recompilation of the whole tree, even if the change is backward-compatible.
> 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.
People on HN would probably be a good target for this device as most hackers understand data much better than the general population... But a random test here and there... I'm not convinced.
However, medicine needs to develop and home diagnosis and early detection along with encouraging and active lifestyle is the future. There are some tough challenges ahead. Maybe this is a step in the right direction, but as I said, I'm not 100% convinced by this device as i feel it kind of misses the point and focuses on some random fairly unimportant tests.
Well let's say your CRP went to a 100, your nose is running and you have a a cough... what would you do?
> Doctors mathematical abilities are less than legendary.
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.
