DEV Community: Chris McLeod

Dogmatic DRY and the SRP

Chris McLeod — Mon, 20 Jan 2020 00:26:30 +0000

In the course of development you will certainly come across code where you notice an abstraction can be made. Two code paths look so similar, there is a generalization to be made, the code can be more dry. So you make the abstraction because it feels good!

The problem often is you may not have considered the impact and coincidence of time. You may have based the decision to dry up the code solely on the fact that you can right now.

The real picture is that the components or units of code that are "wet" have been separate up to this one point in time, and perhaps only now, in this one moment, do they look similar enough that a clean abstraction can be made. However, the influences that have driven their "reasons to change" (S in SOLID) up to this point remain and will remain separate.

Had you not made this abstraction today, maybe two days from now, the units of code would appear so different you would never have considered abstracting them in the first place.

If you did go ahead with the abstraction, you are now forcing separate units of code to "reuse" some common "abstraction" even though they are begging to be separated again. Maybe they never had that much in common to begin with. This is because the "commoness" of code is not driven by syntax or a temporary coincidence of common requirements. Common code is determined by code which has the exact same reasons to change.

Now the question becomes, what is a "reason to change". I believe there is a common misconception about the "responsibility" of units of code. The common belief seems to be a unit of code should be responsible for one thing, it should do one thing well. While that is true, consider this, computers do what humans tell them and programs are created by humans (directly or indirectly). The only "reason" a program would change is because a person has new requirements for that unit of code. A unit of code's "reason to change" is not the details of its implementation, but rather the person, or group of people, that influence its scope of requirements. A unit of code should only be responsible "to" a single entity.

So, DRY up your code when you have multiple code paths doing similar things and they have the same reasons to change. If the units of code have the exact same reasons to change, it is much less likely they will want to diverge in their implementation in the next five minutes (or year). When you notice a common unit of code which used to have the same reason to change, now has multiple reasons to change, break it up until each piece has a single reason to change once again. Reasons to change come from people, not implementation details. So another way to look at this is, abstract common code when the requirements for those units of code are defined by one person (or group). Break code apart if you notice multiple people (or groups of people) have competing requirements for a shared unit of code.

Easy Category Theory Part II: Isomorphism

Chris McLeod — Mon, 13 Jan 2020 03:23:37 +0000

Let's start this topic with a metaphor. If you are not familiar with the game of billiards, take a look here to get a basic idea. https://en.wikipedia.org/wiki/Cue_sports

Sometimes in life, there are many details layered on top of something that make it seem as if things are different when they are really the same. Let's take the game of 8-ball. In this game, we have an underlying game of physics: hit balls in the holes. However, we have layered rules on top which make it seem as if there are differences in a billiard ball painted with stripes, and one painted a solid color. When we remove the rules of 8-ball (the extra details), we see that billiard balls are very much the same regardless of how they are painted. That is to say, if our only goal is to hit balls in holes (no extra details), all the balls are the same for these intents and purposes. Once we have removed all the extra details, the billiard balls are all isomorphic.

Isomorphism of objects in category theory is about "sameness". In the previous article we saw that categories are simply property-less objects with arrows between them. Two objects in a category are isomorphic if they are the "same" for all intents and purposes. Strictly speaking, two objects are isomorphic if there exists in the category an arrow from object a to object b, and an arrow from object b to object a that is the inverse of the first arrow.

In the previous article we talked about the idea of "identity". To recap, the identity morphism is the morphism that starts from object a and points back to object a. In terms of isomorphism of objects, if you were to compose the two arrows mentioned in the paragraph above, you would have the identity morphism. That is to say, if an arrow goes from object a to object b and another arrow goes from object b to object a that is the inverse of the first arrow and you compose these two arrows together, you have an arrow from object a to object a, the identity morphism!

Isomorphism is important in category theory because it allows us to disregard extra details that make categories seem different and look at them as the same. This allows us to focus on the properties of categories and not the nuances of their application.

Remember, we talk a lot about objects and arrows and this is not a metaphor. This is because category theory is EXACTLY about objects and arrows. It is so abstract because these primitive objects have no inherent properties. This is also why category theory describes the mechanics of so many things. All the information is encoded in the morphisms.

Typescript Suggestion: unknown

Chris McLeod — Thu, 24 Oct 2019 15:44:22 +0000

All data types coming from "outside" your system should be typed as unknown and mapped through an anti-corruption layer to give them their type inside your system.

sell cookies in nursing homes not neighborhoods

Chris McLeod — Tue, 15 Oct 2019 11:43:55 +0000

Sell your product to an aggregated common market, not a randomly dispersed one. It is efficient to sell your message once to a room full of people who want your product. It is not as efficient to sell a few messages multiple times to people with little in common. Especially when you consider the barriers (physical space/time) between them.

Where does your market congregate with the most density?

Photo by Alex on Unsplash

Easy Category Theory Part I: The Basics

Chris McLeod — Tue, 30 Apr 2019 01:05:51 +0000

Category Theory may be important to learn as functional programming is coming back into the mainstream. If you a have a passion for discovering abstractions, CT promises to be the ultimate abstraction. As I learn category theory, I will add an article to this series in which I will explain the concept I have learned in an attempt to further my own understanding and hopefully help you learn this vast subject as well.

There are plenty of articles, books, papers etc for learning CT. My goal with these articles is not to provide the best explanation or an exhaustive explanation that uses all the mathematical notation. I only hope to provide another explanation that may trigger an epiphany for the more guided learning I hope you are doing. My explanations here are tuned to the way I learn best, metaphors, pictures, and simple language.

The strategy I recommend for learning CT is to use an introductory book as a guide to the concepts to learn and the order in which to learn them. Then consult other resources (YouTube, articles like this one, etc) to chip away at each concept until your understanding is satisfactory and internalized enough to move to the next concept.

Disclaimer: I am not a mathematician and I do not have a degree. I am only just beginning to learn Category Theory and anything I say should be independently verified as correct.

What is Category Theory?

A theory in mathematics is the attempt to seek out patterns and suggest possibilities about these patterns. Then assemble these possibilities into a well-defined set of ideas using mathematical concepts, language, and notation to form statements (axioms) that are taken to be true and built upon to form further axioms.

Category theory is a somewhat special mathematical theory in that the axioms attempt to formalize the structure of all mathematics. The patterns this theory seeks to explain apparently underly every branch of mathematics and more. That is to say, if you were to replace concepts in any branch of mathematics with the most abstract notions of those objects and their rules, you would then be dealing with CT.

What is a Category?

A category has two parts and two rules. The two parts are things and indicators. An indicator is some process which can be supplied with a thing and indicate (point out, surface, return, show) the same or another thing. The two rules for a category are that indicators must be composable with associativity and there must be an identity indicator for every thing.

Composable means if an indicator uses type A things to indicate type B things and another indicator uses type B things to indicate type C things, then there is an indicator that can use type A things to indicate type C things, and that indicator is the composition of the two indicators i.e. If we can go from A->B->C, we can go directly from A->C.

Associativity is defined by saying a group of quantities connected by operators gives the same result whatever their grouping, as long as their order remains the same. In CT this means, you can start following arrows at any point as long as you don't change where they point.

Identity means if I have things and give one to my indicator it will indicate to me that exact thing I gave it.

I use this non-specific language intentionally. It gets difficult to separate the abstract nature of a category from specific examples of a category. For example indicators are often thought of as functions, as in a mathematical function like f(x), something that takes an input and produces an output. However, indicators don’t have to be transformations. Again, the only rules for what qualifies as an indicator are composable with associativity and an identity indicator exists. Relations are also indicators. If I have a 5 and I use the relation ≤, what I have is an indicator which takes things of type "set of all numbers" and indicates all other things of type "set of numbers less than or equal to 5".

Simplifying the Language

Objects: things such as real numbers, words, other categories or even arrows. Pretty much anything an be an object.
Arrows: indicators which are processes that use objects to indicate other objects. They must be composable with associativity.

So using our new language, categories are arrows that use objects of a certain kind to point at other objects of the same kind. These arrows must be associative and composable. The category contains ALL such indicators and objects.

Concept Example

In programming, classes (or more accurately types) are an example of a category. Let’s fill in the blanks:

Category of Types

Objects: Types
Arrows: Hierarchy (inheritance)
Composable: Yes. If type C inherits from type B, and type B inherits from type A, then type C inherits from type A. Notice the order in which these types are defined (grouped, evaluated) does not matter from a hierarchy sense i.e. (C <- (B <- A)). However the order in which they are composed does, i.e. C <- B <- A is not the same as B <- C <- A
Identity: Yes. Type A could inherit from type A in which case you would have type A, though since this is trivial no language that I know of supports it.

Category of Metaphors

Objects: anything
Arrows: mental mapping
Composable: Yes. If I imagine a piece of wood represents a boat, and a boat represents travel, I can imagine a piece of wood represents travel.
Identity: Yes. I can always imagine a piece of wood represents a piece of wood.

What’s Next?

The next article will discuss what it means for two categories to be close enough to the same to be considered equal for most intents and purposes.

Resources

I recommend this book:
https://www.amazon.com/gp/product/052171916X/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

And Bartoz Milewski's (free!) youtube channel:
https://www.youtube.com/playlist?list=PLbgaMIhjbmEnaH_LTkxLI7FMa2HsnawM_