DanWaterworth

First, write down 36 words. Roll two dice, take six times the number on the first minus the number on the second plus one. That is the position in the list of the first word in the sentence.

Next, write a new list of 36 words, but only include words that make sense given what is already there. Roll again as before and pick as before. Reusing words between lists is fine, but don't include the same word in the same list multiple times.

Rinse and repeat until you have the desired amount of entropy. Each die thrown adds log_2 6 bits.

Edit, just tried this, 36 is a lot of words to come up with. Much easier to write down 6 at the cost of making it twice as long. Unless you have access to lists of nouns, verbs, etc.

Bored now, but came up with "Countries can slowly sit at my feet", 24 bits of entropy (some lists had 36 words others had 6. It's very low, but, if you did that 2 or 3 times, you'd be getting somewhere). Couldn't be easier to remember.

EDIT: by resources, I mean, the specialized logic and chunks of RAM that exist inside FPGAs.

Found it: https://groups.google.com/forum/#!topic/comp.arch.fpga/BTojR...

No, you have a selection bias, you don't notice the abstractions that have worked.

Not necessarily. It could be up to the caller to ensure that the pointer isn't NULL.

Indeed. However, although it's impossible to avoid, you can still take steps to make it less likely.

When you formally verify code, you are showing that a program has a particular specification.

If you want to eliminate errors in your specification, you should aim to make it as simple as possible, so that people with domain knowledge (in this case, people with a correct understanding of PPC) would be able to tell whether your specification is correct.

Instructions aren't free, they still need to be loaded from RAM like data.

Why? Just get the machine to do it.

It's like when you see programmers doing arithmetic in their heads. "You're sitting in front of a glorified calculator!"

I don't know that sarcastic is the correct word, but I certainly wasn't completely serious. Maybe "playfully antagonistic".

I suppose the problem I have here is, if I was designing a language, and composability was a stated goal, then I wouldn't have come up with Go.

> a brilliant article from Rob Pike about using and composing functions to create flexible APIs

I'm sorry, but that API is not something to be proud of.

In what way is Go code composable?

Sounds like you need to implement raft. Do you have any plans in that direction?

I recently wrote a library for testing concurrent code. It's basically fuzz testing of scheduler behaviour to root out race conditions. In most languages, you'd need a special compiler or runtime to do this, in Haskell it's a library.

I really disagree with this. Asides from the fact that tests can't prove the absence of bugs, it's very easy to write a test suite that avoids the unhandled edge-cases; most people do without thinking about it. Your test suite is the tool you have created to search for bugs and should be written in that adversarial mindset rather than as a certification that you actually did your job.

[1] https://hackage.haskell.org/package/blocking-transactions

In essence, the idea is that you are led through the process of implementing: early exit, nondeterminism, threaded state and coroutines using call/cc in scheme. Then monads are introduced as a way of typing those patterns.