Actually, the worst thing about this article isn't the hot air. The worst thing is that I think I would agree with it, if it had ever managed to get to the point.
Because the job of the OS is to manage computer hardware resources.
'JSON' and 'SQL' (whatever that means) are not hardware resources.
Next stupid article, please. This one is broken.
JSON and SQL are closer to preimages of data and computation manifolds respectively that are projected (or fibrated) via Kan
For example:
> The act of “unbundling” functions (lambdas) from their traditional containers is really what Serverless and the Functional Programming movements are trying to do
I have no idea where the author got this impression about the functional programming movement (insofar as such a thing exists) is trying to do. For a reasoned view on functional programming, check "Why functional programming matters"
> In FP, you are either writing functions or doing something else (like gluing or wiring functions together). Simply put, a monad is an industry-generic term for that “something else”.
That is meaningless. A monad is a precisely defined mathematical object in category theory.
> Technically, monads are instances of special ‘containers’ called monoids (sets) that manage the above activities.
This part of the article manages to completely misunderstand or misrepresent what monoids are. They are not just "sets", they are sets with additional structure on them.
> Incidentally, the most troublesome spot for both OO and FP has been homotopy type theory, which is similar to the debate over the mutant creatures that emerge from relational joins
Uhh, no? HOTT does not come from relational joins, it comes from a desire for a constructive viewpoint of mathematics in which one can encode proofs well, so we can check proofs on our computers.
> .. databases and programming will converge — and something called the Curry-Howard correspondence suggests we cannot ignore this forever.
I don't understand what this is trying to say, but on a simple reading, this is blatantly false. While curry howard provides a way to connect proofs in proof systems to lambda calculus, _(relational) databases don't use lambda calculus_. Instead, they're based on (surprise surprise) relational algebra, for which I don't know of a curry howard style analogue.
> Meanwhile, the geometry community will talk in terms of topos, sheaves and data (note how a spreadsheet is sorta both code and data at the same time).
Wow, that is _such_ a misrepresentation of how mathematicians use "data". The word "data" is usually meant to encode "some structure owned by the mathematical object". One often reads sentences like "the galois group encodes data about the field", the "data" is not the "dual of code" or some such nonsense.
> That’s probably why applying algebraic “lambda calculus” to geometric problems (remember XML?) tends to be a rather unpleasant programming endeavor.
Why is XML geometric? What is this guy talking about? Can he even define a category? (Forget a topos)
> Vendor software is often needed to establish a “standard” way to assign names to lambdas so we can find them. Mathematically speaking, this is the job of homotopy. On the other side of the Yoneda “tunnel” we find something called an Eilenberg-Moore (EM) category (technically the flip side of Kleisli) and other alluring blobs like Serre subcategories and Segal spaces. None of which get much play in computer science.
Thi is once again, meaningless. Homotopy is a geometric idea about deformations, which in homotopy type theory gets utilized to define equality. But again, this has nothing to do with naming!
Also, elinberg-moore and kleisli categories are very well known. Open any category theory text, this will a part of the adjoints chapter. Indeed, you can search on hackage and find packages for it: https://hackage.haskell.org/package/streaming-0.2.2.0/docs/S... for example.
> In category theory, we call these “adjoints”, as in “joins”. If you ask the memoization crowd they sometimes actually do think in terms of SQL joins. In the database world, this is like joining keys of a schema.
What? Adjoints are not about joins. They are kind of generalization of inverses. Once again, this just reads like technobabble
> Haskell devs have to manually tinker with adjunctions and monads because in-memory data support is pretty dumb
What in memory support? What do monads have to do with anything in memory? Monads are a structure that we use to structure code, it has nothing directly to do with "memory data support" or whatever this guy is on about.
> If we follow Yoneda and accept that topology (geometry) and algebra are two different worlds, then we can “attach” functions to the fabric (geometry). But in a “serverless” world, what is this fabric?
What in the world is he on? How does Yoneda (where I presume he is referring to the Yoneda lemma) say this? Also, more importantly, much of Category theory exists to explore the _duality_ between algebra and geometry, it says nothing about them being "two different worlds". The very existence of Algebraic Topology means that geometry and algebra are married to each other --- not to mention the other objects mentioned in the technobabble above (topoi, grothendeick categories) arose from Algebraic Geometry, which, guess what, combines geometry and algebra...
At any rate, the entire point of the post is to sell their "Multix 2": https://www.codecraft.ai/
From this post, I have lost all confidence in whatever it is they are building...
- Adjoints are all about joining things hence the name; much like chasing dependencies (arrows) between cells in a spreadsheet and then going back to the relational database where the sheet was extracted from. You have seamlessly jumped from algebraic morphisms to geometry without even thinking about it
- Homotopy is about finding "paths" between things and therefore imply some relative naming (coordinate) scheme is possible. The segments of a path arise due to torsors. Hence homotopy is associated with paths. UNIX paths and URLs come to mind
- Homotopy is not about finding paths, it is an equvalence relation _between paths_. a path is _homotopic_ to another. Homotopy is also a _continuous object_, unlike torsors, which are discrete objects (a continuous torsor is an affine space).
So, while UNIX paths and URLs are "paths" in the sense of torsors, they have _nothing_ to do with homotopy (as it is classically defined). Unless you are using some weakened notion of homotopy that I am unaware of, in which case I'd love links.
