Category theory is a dry hole IMHO. If you look at the main theorems of Category theory, you will find a niche of abstract algebra, that seems to have very little relevance to programming. see https://mathoverflow.net/questions/83437/the-main-theorems-of-category-theory-and-their-applications for a list of the main theorems. I defy you to make a better interactive graphics program using any of those theorems. Frankly speaking the Turing/Von Neumann computer that we have used for the last 50 years is so simple that mathematicians have almost zero interest in studying the incredibly deep problems that beset the authors of large programs. Excel has had a closed arithmetic for over 25 years, yet i can't think of a general purpose language with this feature. Sadly mathematicians today content themselves with mostly inventing their own problems, and thus all the big products in the industry continue to have hundreds of thousands of unrepeatable bugs, and estimates are still way off, and bug fixes continue to break working code with ease.

if the only thing category theory gave software development was the concept of the monad, i think it would be considered pretty successful. while not a lot of languages have adopted the literal monad, many have embraced its mechanics in the form of `async`/`await` and option types

What I find is that most of the math I know has been useful in programming primarily for definitions, not for theorems.

I feel that the more interesting and powerful inventions in computing are outside the purview of mathematics. Sure, there will always be some mathy ideas in there and we can always extract some maths from it, but thinking that computers are 'machines that do math' reduces them quite a bit. It's like if you had absolute knowledge of all maths and nothing else, could you design or create the biological world? The powerful ideas in biology are in the phenomena outside maths. Maths (or even physics) doesn't help in designing these phenomena, even though they don't violate any 'laws of physics'. In my perspective the design of computing 'phenomena' are a similar endeavour.

yes! the language for describing and reasoning about concepts is such a useful thing. it often draws out things i kind of intuitively have in my mind, but then goes way farther than i would have reasoned them through

@Edward de Jong / Beads Project what is a "closed arithmetic"?

Excel has a closed arithmetic where each cell can have a value of varying type, but there are 2 meta-values that a cell can have, undefined and error (denoted #UNDEF and #ERROR) which automatically propagate using a closed arithmetic (in the algebraic sense that all operations stay inside the same set). A predictable, stable arithmetic model that is not present in C for example which has maybe a 32 bit integer number, which cannot store either metavalue. Extending arithmetic has serious consequences, as you can no longer use the arithmetic of the underlying hardware, which means you are going to be 10x slower. So right away you must decide in your language, are you going for maximum performance, or maximum robustness. In my Beads project, i have imitated Excel, and it has vast repercussions, as connections to the outside world have to be converted. But it pays dividends in robustness as every operation has a predictable and consistent result, with zero chance of undefined behavior. Contrast that with other languages where uninitialized variables are basically random number generators, and languages where enums are represented by simple integers and one can accidentally do arithmetic on them.

Well thanks, that's a really comprehensive answer!!! Yes totally agree that numbers (etc) should be user-focused/domain-focused not machine-focused. We can sort out optimisation later.

I'm not sure how to phrase this in a way that doesn't sound flippant (although that's not intended): speed is also important for users. There's a genuine tradeoff that Edward is referring to. A UI where responses take 0.1s is pretty good, but taking 1s is hair-tearingly frustrating...

@Edward de Jong / Beads Project Do Haskell’s

Either

, or Swifts

Result

capture this? Both let you define total functions where outputs are either a result or an error. Function can take these as arguments too, so it seems like they give a closed arithmetic?

yeah, i'm struggling a bit to understand the profundity of this. is the idea just that you have values that will propagate through any operation, such that it's impossible for a computation not to complete, but you also can write your logic without any embellishment?

Mr. Johnson has got the idea. The whole point of a closed arithmetic is to eliminate IF statements. In the old days of computing, every function would have an error return value, and after each function call would be an IF statement to abort the rest of the computation should an error be found. Over time, people got lazy and started to skip the IF statements, and a million bugs were born. fast forward to today, and nobody wants error codes or to write IF statements, so the current idea is to limp along and at least not crash, often foolishly hoping each function never fails. The fundamental issue is that many things can fail. Erlang had an interesting attitude about what to do when an intermediate function encounters a failure; just crash the thread and start all over. A unique philosophy, borne of the harsh crucible Erlang was formed in, that of a headless box that has to run for years. For graphical interactive programs however, restarting suddenly is not a comfortable interaction style, so the crash + start over idea doesn't play there. Haskell's Either construct is merely a wrapper around multiple values and is not the same thing as a closed arithmetic. I am not familiar with Swift's result, but again, these language features are typically tacked on at the end, and are not baked into the core arithmetic like they are in Excel and Beads. Closed arithmetic is a property like being a prime number; it is a mathematical property that is either present or not, and if you don't have it you will pay for that omission sooner or later. I find the Java approach of using Try/Catch to be horrendous as it causes spooky action at a distance, something that bothered Einstein and all people who value sturdiness and understandability.

but isn't this basically an exception? can't an exception be thought of as a return value that dominates every remaining operation in the current scope? the

catch

is where you'd put your `IFNA`/`IFERROR`

I'm currently attending a conference in Applied Category at Oxford. Most of the big names are here. The dry hole analogy made by @Edward de Jong / Beads Project seems fit. So far, I've seen many interesting things but the benefit to CS seems trivial (i.e. you can accomplish the same things w/o resorting to category theory). With CT, however, you are able express much of the same stuff in a way that's more 'clean' and ensures some safety/correctness properties for free. The huge drawback is, obviously, that now your team has to be proficient in abstract math/CT. Is the juice worth the squeeze? Who knows ... ¯\_(ツ)_/¯