posco

The amazing page computes binary relations between pairs of regular expressions and shows a graphical representation of the DFA.

It’s a really incredible demonstration of some highly non-trivial operations on regular expressions.

Great implementation is genius.

But they are paying $2/kwhr aren’t they? They are socializing those costs.

Am I misunderstanding something?

Perhaps they would remove it if they are concerned their platform could be incentivizing wrong, dangerous or stupid behavior and they worry about the brand damage that does or have ethical problems profiting off that.

Predicting 50% can be validated: if I say a coin will be heads 50% of the time, I know more than nothing: I know more than someone who incorrectly claims it will be heads 75% of the time.

And we can quantify in various ways how much better the 50% prediction is than the 75% prediction.

Somewhat related: this scala library I coauthored is named after the Paige compositor:

https://github.com/typelevel/paiges

A big reason to use IO as a value (which IMO is a better name than IO monad), is the same in all languages: reasoning about immutable values is easier than side effects. If we can take complex IO operations and use composition tools exactly the same as other immutable values, it’s very nice.

Of course, in my experience, this is so foreign to people who haven’t worked with it for a time it is very difficult to sell in small reply.

Having this with rust could be a very powerful combo.

“ In any case, the model makes a testable prediction. If the sunspots are less frequent over the coming 20 years, she was right!”

Interesting goal posts: scientist working on carbon’s effect on the climate need to consider all kinds of other potential explanations despite their predictions of continued short term warming coming true. This person is in the fortunate position that she should be believed, not doubted as a coincidence as mainstream scientists should be, if her prediction comes true in a decade.

And if she’s wrong I guess we just say “...fuck...”

No, but surprisingly frequently this property holds: if your function is generic enough, there is only one (or a small number) of possible implementations that type check.

Leveraging this rules out bugs.

The global Mode is gone in 0.9.0. And there is an implicit from Grouped to TypedPipe, so you don't need to call .toTypedPipe (that directly seems less likely to cause problems, especially given we have mapValues and filter on Grouped, so we should avoid needlessly leaving the Grouped representation).

Quick point:

1) Scalding has a DObject like type: ValuePipe[+T]. 2) The reason you must explicitly call .group to go to a keyed type is that is costly to do a shuffle, this makes it clear to people when they do trigger a shuffle. If you don't like that, make an implicit def from TypedPipe[(K, V)] to Grouped[K, V] 3) You can easily use scalding as a library, but most examples use our default runner. We use it as a library in summingbird. But you are right, a nice doc to help people see what to do might help people (hint: set up an implicit FlowDef and Mode, do your scalding code, then call a method to run the FlowDef).

If you're interested in scalding, Edwin Chen's awesome recommendation post can't be beat:

http://blog.echen.me/2012/02/09/movie-recommendations-and-mo...