Kinda Samesies and Modeling

kinda samesies /kaɪndʌ seɪmziz/ (adj) two or more things that are kind of the same

In the last post I did some lazy equivocation. Does remapping caps lock to ctrl have anything to do with abolishing capitalism? No. They're not the same. I might think it's fun to call both "anti-capitalist stances" and somehow claim they're connected, but I don't really think this. It's the kind of nonsense you can do by manipulating text and converting them to numbers and drawing red yarn between everything on a wall in a garage.

This kind of thing can have persuasive or at least self-delusional power, but it's not a great path for making useful models. If like George Box said, "all models are wrong, but some are useful," then the usefulness of a "kinda samesies" situation is potentially worrying. An elaboration on his quote reads "so the question you need to ask is not 'Is the model true?' (it never  is) but 'Is the model good enough for this particular application?'"

So equivocation might be good for the applications of advertising, PR, comedy, puzzles, art, or propaganda. Things that rhyme are kinda samesies. Homophones are kinda samesies. Things spelled similarly and anagrams and so on are all kinda samesies. Things that remind you of other things are kinda samesies. Any two things could be kinda samesies, because there's really no criteria other than someone putting them together.

Varieties of Kinda Samesies Experience

There are mathematical and philosophical ideas of "kinda samesies" that rest on definitions, axioms and whole sets of beliefs about what "things" even are, what things are a part of those things, or how we can call things the same. Stronger versions of kinda samesies can get complicated when you apply rigor and rules to them. Is 2 + 1 "the same" as 3? Who would say that it's "equivalent" and why? Does it matter most of the time? If I was defining both of these rigorously, say with Peano Numbers, then I'd just have "zero" and a "successor" operation to work with. Then I could prove them to both be equal to successor(successor(successor(zero))), or if not "equal," at least be based on a "kinda samesies" construction. Some people in programming claim not only the "=" as an assignment or "==" as a test, but the notion of "equality" to be thrown around too loosely in programming.

If I was Heraclitus, I might think "no man(sic) steps in the same river twice," because it's a different person and a different river each time. Even Heraclitus could not deny the person and the river were kinda samesies as the first time though. Dude thought the world was made of fire, so he could probably get on board under the right circumstances. There's a maybe more familiar version of this in the "Ship of Theseus" where you replace pieces of a boat and after a while wonder if it's the same boat. Very smart people have taken a lot of time wondering if and how it's the same boat, and moderate positions would suggest they're kinda samesies.

In math, there's a difference between defining something intensionally vs. extensionally. In the first, you say that anything having particular traits defines or characterizes the thing. An "extension" is more like describing something by exhaustively listing what belongs to it. If we're programming, the "somethings" defined either way could be used as templates for objects that are at least kinda samesies. Maybe the extensionally defined one would be a "really samesies" though? Again, both are good enough for a lot of useful models, so the difference between kinda and really samesies is probably not worth worrying about.

Math also offers a few intentional (not to be confused with intensional) weakenings to the very samesies "equality." One is "isomorphism," and another one is "adjunction." In isomorphism, the things don't have to be "equal," but they have to be kinda samesies enough to convert from one to the other and back. With an adjunction, the rules loosen up a little more. Converting back and forth gets a little harder. And if all you want to do is convert a set of things to another set, functions, functors, and monads have you pretty well covered. If you're interested in kinda not samesies, then the algebra of lattices is waiting for you.

Within adjunctions, there are a lot of "kinda samesies" things floating around. Not all of them make sense without smashing into a ton of text, but "sum" and "product" are both fairly accessible. They can both be used to figure out parts of a thing. To be a little more concrete, a product could be 21 and 42 being "kinda samesies" because they are 3x7 and 3x7x2, so they have some factors in common (the 3x7 part). For sum, a 3 and 2 might be "kinda samesies" in the sense that 1+2 and 2 both have a 2 in common. If you're working with functions and classes, you can also look at parameters to a function as "products" and if statements (or polymorphic types/subclasses) as "sums" for some interesting reasons, but the important bit is that people care about these kinda samesies things too. They both let us compare degrees of similarity. Oh and hey, again worth noting, philosophers are all over this parts stuff too just like they are with aspects of river and ship related identity.

In the programming languages I work with the most (js and ruby), good enough kinda samesiesness is weak enough to be a lot closer to whatever doesn't throw an error. 2.to_s and  "2".to_s are both kinda samesies enough to work with ruby. Things that work like this are sometimes called "duck typing." And to_s is able to make these both quack convincingly.

Even more informally, programming has inherited a ton of aphorisms and "x's laws" that offer advice and analogies forcefully enough that they become normative styles of working. With the wealth of "kinda samesies" options available, it seems like we accept these and what our particular tools give us. Personally, I think we'd do well to throw out these "laws" or at least radically expand the set.

Some Potentials

If we engage more with a wider array of kinda samesies structures, a few things can happen.

  • A quite strict treatment of definitional equality can give us code built along side its proof.
  • A fairly strict treatment of equality as relating to types can give us caching and some nice guarantees of behavior.
  • A lot of the hype around immutability and rejection taken up a notch with strong ideas of when things are not "kinda samesies" enough leads to databases and codebases (and yes, some cryptocurrency stuff) that reminds me a little of Heraclitus's river.
  • Duck typing can give us a flexible and sometimes guessable system that arguably is "fun" to work in.

Better Modeling Across Kinda Samesiesness

For most things, I sit at the product and sum level being good enough. With that combination, we can model how things happen and define alternatives. If I can put two real life things through the same processes and call a lot of their parts by similar names, then that's the level of kinda samesies that I don't feel slips too hard into equivocation.

At the programming language level, I would enjoy the kinds of guarantees that come with additional rigor. But on the object modeling layer, this place on the spectrum of kinda samesies is pretty comfortable. And it's situated there, that I'd like to make a few claims:

  • refactoring is reformist; rewrites are revolutionary; "strangler apps" are prefigurative
  • tactical unity is a sum; ideological unity is a product
  • total orders are used frequently and often mistakes; ranking and classifying people in particular should be done with a lot of care, oversight, research, and perspectives
  • We should be much more suspicious of what we allow to claim equality without rooting in a basis on the kinda samesies spectrum

Better Modeling Beyond Kinda Samesies

What's missing from a lot of my models is weakened notions of comparison (beyond total orders and classification), perspectives, feedback, and resource constraints. Petri nets, eMergy diagrams, and industry specific tools for things like climate models are all areas that we could be backing much harder.

I'd personally love to spend more time on the following:

  • homeostats and feedback loops
  • sharing/resource allocation
  • defining purpose as something other than growth
  • generative systems (anamorphisms and comonads)
  • rhizomatic (as opposed to hierarchical or arboreal) structures

I don't think I'm alone in hoping for more work in these areas. But I don't think we know how different things could be or have even close to the same level of money going into this kind of work.