jfischoff
The Reader Monad – Part 1
The Haskell Concurrency Primitive Shootout
Rapid Parser Prototyping with BNFC-Meta
Testing PostgreSQL for Fun: How to Iterate Quickly with Haskell
Assume It Worked and Fix Later: How to Make Your App Faster and More Reliable
Are Mutable References Fast?
Existential Quantification Patterns and Antipatterns
The Partial Options Monoid
Type Class Patterns and Anti-Patterns
Understanding Haskell Type Class Instance Selection
Zero Downtime Deployment with Warp
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).
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.
If the fingerprints can be made precise enough, binary caches can be distributed from trusted parties, similar to what other package managers do.
For instance, to install stylish-haskell you will ultimately need the "happy" executable, but cabal is not smart enough to get it for you.
I don't know what a "clean" environment means, nor do I know what you mean by "broken dependencies." Did you:
mkdir stylish-sandbox
cd stylish-sandbox
cabal update
cabal sandbox init
cabal install happy stylish-haskell
cabal copy
cd ..
rm -r stylish-sandbox
That might work.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.
They do not allow medical devices.
Babies
> 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.
I'll stay at home if I can
Cue biometrics reader
I would prefer is people just said "I program faster in Haskell"
Like you said, there is nothing seamless that is part of cabal ... yet. I would like improve our workflow and integrate it into cabal.
I was surprised how fast people were picking up the language when I started
It is way different learning the language surrounded by teachers and a working environment. That was my takeaway.
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.