This is a hidden killer feature
HN user
jfischoff
yeah
This is the plan I think, or something like it.
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.
The videos for BayHac 2014 have not been (officially) released.
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.
The package management story in Haskell, I don't want to say broken, is just too complicated for beginners, err actually everyone.
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.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.
They do not allow medical devices.
Flu: Still beats me why this would be useful other than general interest (which sometimes is enough I guess).
Babies
Pretty good points, I have few comments.
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
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"
And what is right job for whitespace?
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.
Haskeller at IMVU.
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.
The library in question was using unsafePerformIO to open a file handle. It was just a bug.
Haskeller at IMVU.
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 :)
I'll expand on the details.
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.
There are no useful laws for magmas. Monads have a fair amount of structure for something so simple.
I like this article.
Something to remember, is you can never finish more things then you start by definition.
I would not like to hire someone who always finished everything regardless of how mistaken they were when they started.
We will we all finish fewer things then we start. By itself it't not that useful of a metric.
what makes it a different breed?
Edit: I misread what you wrote. I thought you were saying there was something fundamentally different about the type checker, but more that reload experience is different then what you get with Yesod.
Don't you mean template <typename HasABinaryAssociativeOperationAndLeftIdentityAndRightIdentity>
Nope. Some of the best programmers I have worked with were in their 40's.
Yes had a one gb fail.