freyrs3

You have to appreciate the audacity of some of the portfolio companies in Fund I for getting away hilariously bad business models. They literally fleeced Chris Dixon into funding Pied Piper (dfinity.org) and crypto kittens and he actually bought it. There's definitely some massive sunk cost effect going on with this new fund on a scale we haven't seen before. Anderssen used to be the smart money in VC and now they're doing this fund.

Showing how Yang-Mills and SU(3)×SU(2)×U(1) fall out would be a natural starting point for a proposed unification theory. This model doesn't even try explain the existing particle hierarchy as a special case.

> Ain’t that cool?

Oh it is! Now never use this.

If you want a description of the monad laws in Haskell terms you can Google and find like 80 expositions on the topic of various depths.

If you want a mathematical exposition. "Category Theory" by Awodey page 265 is a concise description.

Their usage in Haskell/OCaml etc is precisely faithful to their category theoretic definitions as can be in a general purpose language.

This debate about naming monads is pretty tiresome after so many years, if one called it "computation builder" it wouldn't change their structure or convey any notion of the laws any better than term monad. A monad at it's core is a set of algebraic relations.

> The way this problem manifests in Haskell is in how incredibly clever it makes you feel to get something done in it. Haskell is different enough from most languages that everything feels like an achievement when writing it. “Look, I used a monad! And defined my own type class for custom folding of data! Isn’t that amazing?“. “What does it do?” “It’s a CRUD app”.

The fallacy here is that type classes, folds and monads are not esoteric structures within the context of Haskell, and using them to structure regular business is pretty mundane. If someone feels a sense of achievement from doing this, they're probably very new to the language. The author of the article has baked in a value judgement about the "normal" way to structure a CRUD application that precludes alternative approaches to structuring application logic.

You could just as well argue that laying out object class hierarchies and using inheritance is "[solving problems] that have nothing to do with what you’re actually trying to achieve."

It has two different parsings:

    avoid (success at all costs)
    (avoid success) at all costs

The first is more apt description of Haskell's design, the later is more of a joke.

It's not a hot technology ( read as overhyped ), but if you're in the analytics space and not using Python/PyData tooling then definitely check that out. It's certainly as mature, if not more so than R.

The academic type theory mentioned in this post is not really terribly important to implementing type systems for general purpose languages. There's this growing divide between the engineering discipline of type systems in general languages and the pure theory people who seem only interested in theorem provers and constructive math.

Strictly speaking Hindley-Milner is the type system that itself admits tractable inference using the usual unification techniques via the Damas-Milner family of algorithms. Gradual typing itself uses type inference in the Damas-Milner family, although it diverges with it's notion of consistency.

This is extremely well done, thanks for taking the time to make a screencast.