“A perfect API”

3 thoughts on ““A perfect API””

1. I’m hard pressed to think of better names. The framers of category theory deliberately chose a set of names disjoint from classical set theory and first order predicate calculus to avoid confusion when category theory is used to reason about set theory.

   I’ve got used to the idea that these funny names are really just a label for one or two “operators;” operators which are often higher-order functions.

   I’ve been trying to learn more about category theory lately:

   https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/

   I finally realized one of the biggest mistakes I was making was confusing sets with the category of sets. I kept trying to think of categories as fully-connected cyclic directed graphs (CDGs), because that is their graphical representation. But a CDG is a set-theoretic concept.

   A CDG might be a helpful visualization for simple categories, but a category is really defined entirely by the axioms. In the category of sets, each “node” might represent a single infinite set object, with infinite arrows emanating from it toward infinite other nodes representing other infinite sets, the idea of a CDG breaks down pretty quickly when reasoning about such large objects.

   I have recently been told that a set in the category of sets is similar to a type in type theory, and this is how Haskell models types. I don’t understand how a category of sets might differ from type theory, but still I found that thinking of types in this way really explains a lot about how the type system is modeled in Haskell, and why certain terms were chosen over what could have been more descriptive terms.

   Could it be possible that because JavaScript does not provide the kind of type system that Haskell does, it doesn’t make much sense to keep borrowing the terminology from Haskell that are usually used to describe types and type classes?

   LikeLike

   Reply

2. There are competing goals here between the needs of computer scientists and those of engineers. Most developers (engineers) have little mathematical training (and usually little compsci background with many having come from different fields) and the mathematics that they do know is completely result oriented and/or based on simple formulas committed to memory. While we talk about abstraction a lot I don’t think we mean it in a rigourous sense. It’s more that we have learned it as a way to simplify something purely for the result of that simplification. Understanding something from first principles is nice but not really a necessity. If the computer scientists say this or that algorithm is efficient in terms of time or space or whatever then that’s good enough for us to use and teach others.

   So right now I’m looking at this stuff not from the point of view of mathematics but one of trying to uplift my coding skills. Most of my colleagues have internalised toolsets like lodash and redux because they’ve made their day to day jobs simpler not because they care for the theoretical underpinnings. The problem with lodash in particular is that it’s tantalisingly close to being a well engineered toolset but falls drastically short in that department because it’s developers didn’t know any theory. It’s the tool makers that need to know this stuff. The users simply want to use the fruits of that theory but from a much lower knowledge base.

   So the fantasyland specification is being implemented by various libraries, the best known is Ramda. Ramda is a less popular equivalent to lodash but vastly better engineered library. It was designed with high level composability in mind (given the constraints of working with the JavaScript language). It builds on the algebraic approach of category theory.

   Here’s my problem. I’m actually interested to know this stuff a bit deeper but I’m not that mathematically inclined. I like algebra to a point but I don’t like remembering to many rules. So when I hear about a type or type class I think about it as an interface to memorise. When I hear about a high level concept I grab the nearest low level instance of that concept as a placeholder. Yes I get that a Functor is like a container and that it implements map() in its interface or API. I get that an array is a Functor but so is anything else that implements this method / operator. I don’t claim to understand anything deeper yet. Hence I would find it easier to remember a concept mainly by what it does rather than what role it plays higher up in theory.

   My names for Functor, Setoid, Semigroup etc would be something like Mappable, Equatable, Concatenatable etc. This would aid my memory at least at this early stage but that wouldn’t prevent me from learning a different naming system sometime in the future if it proved to be necessary or useful. My goal is to learn the theoretical minimum to be useful/dangerous.

   We all have capacity to take on greater cognitive load, I just think that engineers have less capacity in this area than mathematicians, mainly because they are thinking about different things and are working over different domains. Hence mathematicians tend to fall back on to familiar turf like algebra while engineers fall back to imperative coding (ie. spaghetti code and bull shit).

   LikeLike

   Reply

3. Monoid = Reduceable

   LikeLike

   Reply