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?
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-...
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.
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
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
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
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