loqi

> I bet someone wrote something equivalent to InclinedPlane's comment about it at one time

Doubtful, because an equivalent statement would sport an equivalent truth value for an equivalent statement of support. Substitute "aether theory" for "dark matter" in InclinedPlane's comment, and his assertion of its wide confirmation would be trivially false. Many physicists at the time believed the aether theory to be true, but confirmation remained (rightly) elusive, despite very sophisticated attempts.[1]

I feel the need to point out that the periodic table was also built up from observed effects without knowing what the stuff actually was. It wasn't the first attempt at categorizing the elements. Mendeleev's table was special because, like dark matter and unlike aether theory, it had positive predictive value. It made predictions about the properties of unknown elements that turned out to be correct.

[1]: http://en.wikipedia.org/wiki/Michelson%E2%80%93Morley_experi...

Weak argument for obviousness: As I understand it, the basic idea is to use a copying GC that pins everything pointed to by stack or registers. I had the same idea earlier this week, after spending a few days' spare cycles thinking about GC and having read virtually none of the literature.

Agreed on the clarity of presentation, though.

I know it was probably just a figure of speech, but I'll take that bet. If, one year from now, some huge Wall Street-esque conspiracy to pump Bitcoin has been exposed, I pay you $115 (1 BTC's worth of USD at the current rate). If no such conspiracy has been exposed, you pay me 1 BTC. Sound fair?

You can also get type signatures non-interactively with ghc's -ddump-types flag.

    {"follows": ["ben", "billy-jo", "anon"]
    ,"message-counts": {"billy-jo-ben": 2}}

At a glance, is the order of follows relevant? Should it be preserved? Is "anon" the same kind of thing as "ben" or "billy-jo"? Is the key in message-counts another name, or some collection thereof?

That's the most unfortunate Python 3 change I've seen. I use byte codecs like hex, zlib, and base64 quite a bit more than text codecs. In Python 2, a programmer with forward-compatible habits can write

  from __future__ import unicode_literals
  from io import open

with the understanding that migration to Python 3 will remove that boilerplate. But taking a similar approach for byte codecs requires knowledge and reference of the right module name (instead of the encoding name) and the names of the corresponding encode and decode functions (instead of just encode and decode). So we've got

  .encode('base64') -> import base64; base64.b64encode()
  .encode('zlib')   -> import zlib; zlib.compress()
  .encode('hex')    -> ?

and unlike the text boilerplate, it's a permanent uglification. I don't know of an idiomatic replacement for the last one off the top of my head. Hopefully it's something nicer and more symmetrical than

  ''.join(map('{:02x}'.format, foo)).encode('ascii')

Potential silver lining: http://blog.sethroberts.net/2011/02/25/the-baltimore-shipyar...