reinman

Yeah this article takes some strange positions

Functions are at best glorified cat containers. I can write a script and never use a function. I can write SQL and never use a function. The Turing tape never mentions "functions" So functions are hardly the bedrock of computing that some claim it is

Categories specifically contain "morphisms". Then FP completely gets category theory wrong by trying to claim that functions are immutable. Which is it?

Instead of chasing strawmen, why not address some of the issues raised in the article directly? Code reuse? Integration? Use of convergence hardware? Interactivity?

Cat concepts are a bit language agnostic.

Forth is a tad exotic. Multix lets you use ordinary Typescript/Node

Tight budget lol

I am curious where you think categories might fit with regard to database tech - cats kinda live in the space between code and data so they don't really fit with trad databases or trad code https://multix.substack.com/p/solving-data-integration-with-...

I'd say that categories are perhaps more universal - FP is a big piece of that though https://multix.substack.com/p/solving-data-integration-with-...

It was a poke at a very smart but also very annoying FP troll @dibblego

For a while, FP noobs were terrorized by a bunch of FP thugs on Twitter

Yes, there is a long-standing debate in categories about this "reduction" problem but that is mostly theoretical

In practice, you only need to break down enough to interface w existing APIs

The morphisms are controlled by the crafting system, which is really a higher order type system

No you don't need to achieve god-like powers any more than GitHub is the source of all code on the planet (it doesn't have to be all or nothing).

Even the crafting rules themselves contain FP chains. In my real world work, I use a mix of crafting, FP chains and old school functions.

Cats live in the world somewhere between code and data

This version incorporates HN feedback from earlier A-B testing article aimed at the FP community. Mainstream programmers don't really care all that much about FP. It's pretty clear to me now that Cats and FP serve different markets anyway

Earlier version here (I think the article is now flagged anyway) but such is the nature of the interwebs that only controversial articles get attention https://news.ycombinator.com/item?id=31957194

Yes anything that says "Functional Programming" in the title tends to attract a certain type of developer tackling a certain type of problem, usually program verification etc.

Not mainstream programming for sure

Crafting is particularly useful in testing

For example, suppose you just need to isolate and test a function but you won't want to manually write a test harness

A crafting system could build the upstream dependencies and then deliver you the results - no code changes needed

Good points. See my enterprise data integration example below

Cats kinda live between trad code and databases, so they are really good at integration across systems. Zapier and other no-code approaches are nice but don't go deep enough and eventually you hit a wall. So cats are the "next level" down from such systems without having to abandon such tools entirely and go back to the old ways

yes - the industry is so scattered that FP tends to attract a niche solving very specific problems such as program verification

And those concerned with speed on hardware are probably not the ones who want the flexibility and interactivity of high level languages

So there is quite a stir about dependent types in academia these days

Remember that coming up w the names for types is half the battle. Whether something is a "string" or an "Address" or an "InputField" is really a multi-dimensional type problem

The server in turn may need to issue crafting requests to load stuff from disk

The nice thing about crafting is that stuff gets cached in inventory as a side effect. You can toss inventory as a way to clear the cache

For example, in Multix the browser can issue a crafting request for page contents

The fact the HTML might sit on a remote server is a crafting detail left to the categorical machine

I have some examples on Twitter

The type system is where the "cookbook" lives

So in a way, if you go through all the work of setting that up you should be rewarded with some sort of crafting. After all, the type checker is kinda doing some of that work anyway

HN skepticism is warranted and deserves decent answers

FP > lambda because it avoids wrapper functions by using chains

However functions still have single entry/exit that limit reusability of the contents

Cat crafting > FP because it can avoid functions entirely

Any new tech deserves well-deserved criticism imo. It's the only way for devs to judge noise for signal

One real world example I am doing for a large customer is data integration across 10-20 large databases and APIs. Categories are ideal for this because they give you the adhoc interactivity of what you would get with SQL but when I am dealing with a bunch of different vendor databases, SQL is not an option. Plus I need to join against APIs and would rather use Typescript for that

A simple example of "crafting" is to resolve the database "connection" parameter to a routine. The problem with working w databases is that every query expects you to have established a connection first - and the minute you make a code change, you lose your database connection(s). This gets much harder when dealing with joins across 10-20 databases at the same time

Then what do you do w the results? Well, you probably want to cache them. This is where persistent memory comes in

My DB query results - regardless of the database - are usually a Typescript array - and I am not about to stuff them into another database. But I don't want to lose the array from memory every time I make a code change either. Persistent memory is a good place to stuff that array

Sending the love back ! When I first learned this cat stuff I was a TOP hater so everyone giving me grief is just well deserved karma coming back to haunt me

There you go. Mostly false premise to false conclusion because FP itself has a bunch of issues. Mathematically speaking, a lot of FP is analogous to building a relational query but wiring the joins manually each time. A bit tedious perhaps

Not co-pilot, but dependent types on steroids. Multi-dimensional dependent types to be more precise. https://www.youtube.com/watch?v=3iKwq9iRHWk

But that's why I boiled things down to Minecraft style crafting. Mainstream programmers don't have time to learn category theory or dependent type theory etc. ... or even care.

The Lambda Conference stuff caters to a small group of programmers that are already happy with FP etc. for whatever they are doing (usually program verification, not mainstream coding)

There is a notion of "categorical thinking" where you try to free your brain from the urge to compartmentalize. Imagine the smartphone example

I removed the jabs at the Aussies - that is dirty laundry I really don't need to be bringing up here as no one cares anymore

(repost from similar question above)

Categories are about composition. Crafting is also about composition - using inference rules. https://en.wikipedia.org/wiki/Category_theory

The classic schematic representation of X Y Z shown on the above wiki page is basically a crafting rule to create Z. That is, if the AI knows about a "path" (think back to your homotopy training) from X and Y to Z then it can craft a Z from X,Y if it needs to

Yes this is exactly reverse to how we normally think about the caller/callee relationship

Fair enough, I needed to improve the answer

The main claim is that crafting > functions because crafting does not have the single entry/exit drawback that functions have

Yeah the west coast doesn't do humor anymore. I lived in San Francisco / Seattle years ago but I avoid all that now. They take offense at everything so everyone frowns in the stores. Coming from Eastern Europe, I recognize the creepy Soviet vibe and this is reflected in the pretty nauseating HN community

Miami is WAAAY cooler

Enjoy this article before it gets pulled

Awesome retro dialup modem yes but this stuff goes much further back than 1990s

Actually 1960s

Categories are about composition. Crafting is also about composition - using inference rules. https://en.wikipedia.org/wiki/Category_theory

The classic schematic representation of X Y Z shown on the above wiki page is basically a crafting rule to create Z. That is, if the AI knows about a "path" (think back to your homotopy training) from X and Y to Z then it can craft a Z from X,Y if it needs to

You as the developer are the one who has to decide which tech is worthy of your attention. And Cats are trying to compete with FP for your attention

Reducing or eliminating "functions" means reducing or eliminating the refactoring problem