Haskell “enforces” typeclass coherence by asking that you define all the instances for a type in the same module (really, file) where you define that type. Whenever you import anything from that module, you bring all these instances into scope. It “works”, but it’s a kludge - when defining the type
Foo a, you can’t anticipate (nor are you necessarily aware of) all the instances you might wish to give for
Foo. We want an “open universe” where people can after the fact discover common structure and layer it onto existing data types. I feel this is an important property for a language ecosystem.
On this blog I’ve mused about the problems with snail mail: anyone with knowledge of your address gets a lifetime ability to cause mail and packages to show up at your house, as many times as they want. Email has the same problem with virtual message delivery. The result is that our inboxes, both physical and virtual, are filled mostly with content whose delivery we never actually authorized. They are mostly noise, and we spend lots of time just processing that noise because there is some amount of signal that we do want to be aware of and respond to with higher fidelity.
Whether notifications are appropriate depends on the signal to noise ratio of the channel. Twitter, email, facebook, and any general purpose communication channel are all poor candidates for having notifications turned on, because most of the messages are either not relevant or do not require immediate action. It’s better to check in on these when you’re not doing something else or want to take a break from the “real work” you’re doing or “real life” you’re living.
First: a story. Alice and Bob are sent to an earth-like planet and given the task of finding its highest point. Unfortunately, they are initially given only stone-age era technology to work with. The planet is foggy and visibility is only 20 feet or so. Alice and Bob adopt different approaches:
Some random notes I wrote for myself.