Creating libraries for dependently typed languages is an interesting problem. I worked for a while on making a tree map (like Haskell's Data.Map) that took advantage of dependent types; for example, supplying proofs that a key either exists or does not in tree. There are oodles of things to compute and prove, it's not clear what a nice API would look like. For example, a proof that a key either exists or does not is a much larger data structure than a simple boolean true/false. I am really excited to see what these sorts of libraries will look like.
Name:
Anonymous2014-09-06 10:40
Languages where even the creation of a library is "an interesting problem". Holy fuck, really? I can feel all the genuine and brilliant hard work from the computer scientists living off state funding that went into the creation of dependently-typed language.
Human readable is an oxymoron. Anything is readable by a sentient mind with intelligence (including the other meaning of intelligence as in being intelligent and not a stupid nigger or mindless machine).
Decompilers make machine code human readable. The problem is that there is still no way to quickly ask IDE "Computer, what does this function do? Explain in a few english words."
You would think that several decades of being completely wrong could have an effect, but no... they still refuse to take their heads out of their clouds/arses/$bodily_orifice and realise that the real world has much better solutions already.
>>21 are separate processes, running outside the kernel. The I/O drivers are also separate processes (in the kernel, but only because the brain-dead nature of the Intel CPUs makes that difficult to do otherwise).
Install kentoo, carter.
Name:
Anonymous2014-09-07 23:00
If the GNU kernel had been ready last spring, I'd not have bothered to even start my project: the fact is that it wasn't and still isn't. Linux wins heavily on points of being available now.