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 can write a script and never use a function. I can write SQL and never use a function.
I don't think you can, UNLESS we get into semantic arguments of what a function is. SQL is implemented with functions in a different language.
Are you thinking that "function" is anything that literally has the "function" keyword?
> Categories specifically contain "morphisms". Then FP completely gets category theory wrong by trying to claim that functions are immutable.
CT is an abstract mathematical concept. In order to use it, you have to FIND the categories in the real world using the definition. CT isn't something usable on its own unless you are doing high level abstract math and doing proofs etc.
In other words, CT is APPLIED to Computer Science and then we can talk about functions as morphisms. They don't compete with each other, but rather CT is a way to understand the structure of computation. FP is building on top of that (pure FP, Haksell, Idris, etc). If you want to disprove how FP is doing CT incorrectly, that is not going to be easy.
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-...
Not sure if the Q was directed at me, but I just skimmed your write-up. Here is a new word to add to 'logic, data, coding': mapping. ETL is mapping wrapped in IO, is it not? Btw, { data, computation, mapping, and interaction (aka 'glue') } seems to cover all the bases for me.
So, on one hand, we have structured, semi-structured, and unstructured source of truth silos of information that we seek to unify (which is the case you are considering). The other possibility is an unstructured pool of data that is annotated to some degree with metadata, from which we can derive (online or offline, as necessary) application specific 'databases'. Naturally the latter case is a better fit for greenfield systems, and the former the 'legacy' of ad-hoc growth.
I don't think anyone would seriously object to viewing the act of mapping elements from one set to another - the T of ETL - as application of functions, for that's precisely what it is. (Don't really know anything about C.T. to have an informative input in that regard.)
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://hackernews.hn/item?id=31957194
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 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.
