pgustafs

If you're a programmer, I wouldn't worry too much about examples of morphisms from math (unless you're interested in the math for its own sake). You already know tons of morphisms -- every function in any programming language is a morphism (e.g. square x = x * x is a morphism Num -> Num).

By the way, if you're interested in categories, you might like this post about using monoids for GPU parsing: https://raphlinus.github.io/gpu/2020/09/05/stack-monoid.html

(Monoids are the simplest examples of categories)

> If all HoTT does is give a theory that's mutually interpretable with ZFC, that's not interesting.

"If all python does is give a theory that's mutually interpretable with x86 assembly, that's not interesting."

The point is to have better language support for expressing the things you want to reason about. I don't find it so far-fetched to be interested in better ways of reasoning about equality of types (both as a programmer and as a mathematician).

From https://gitlab.haskell.org/ghc/ghc/-/wikis/linear-types :

"The centrepiece of our design is to avoid code duplication. Crucially, the same types can be used in linear and non-linear contexts. For example, the linear-base library uses the same types as base. So libraries developed with linear-base will be compatible with libraries developed with base."

A little arithmetic:

6.4T USD / 128M US households = 50K USD/household

50K USD/household/ 9 years = 5.5K USD/household/yr

The funny thing (that I'm sure you're aware of) is that 'prefer composition over inheritance' is an instance of 'prefer referential transparency', an idea from FP that you should always know what a variable is referencing. In OOP, this means that inheritance is bad because it's not always clear what functions are inherited and/or overloaded.

The goal is to make a collaborative dev environment using immutable one-line functions. Define any pure function by building it up incrementally from one-liners, no need for a local environment at all.

The backend for HN is written in a Lisp dialect...

Just do whichever one is more interesting to you. If you like the Haskell, keep going. There's plenty of time to do SICP after Haskell. If you're bored with Haskell, try SICP or whatever strikes your fancy. The limiting factor for learning is interest not time.

Write down your motivation for reading the book. Do whatever you want until you feel like taking a break. After the break, write down reflections on what happened. Repeat.

This works for anything, not just reading books.

I'm currently working on developing a double category of hybrid systems with applications to parallel composition and model reduction in robotics. We should have a math paper up on the arxiv within a month, and a robotics paper up shortly thereafter.

Sure, it's not like you have to call them, but all the ones I've tried have employed anti-patterns for cancelling meals and worse ones for cancelling subscriptions.

Amen. Same problem with Blue Apron and every other meal kit delivery startup.

Thanks for the link and your opinion!