Category Theory, The essence of interface-based design - Erik Meijer

Also nice: Erik Meijer Explains it well: ▶ this video (check out FP101 on edx) Statebox guys doing stuff with category theory, blockchain and petrinets: [link] [link] Graphical linear algebra: [link] Jules Hedges working on game theory : [link]

in “An invitation to category theory” · View on HN

> I prefer the academic truth, validated by renowned peers in the industry, presented at acknowledged conferences, to random opinions on the Internet. You don't even know who wrote the IEEE definition and who validated it. Second this isn't academic truth. This is just some arbitrary chosen standard chosen by industry. Not academic at all. In mathematics, the ultimate logical form of academia there is a term for "interfaces". It's called categories, and there's a entire theoretical framework behind it called "Category Theory". This theory of "interfaces" goes beyond just OOP and category theory can be used to foundation-ally describe all of mathematics and function as a sort of replacement of set theory. Don't worship authority for authorities sake. If the IEEE declared 1+1=3 would you believe it? Instead use your own brain. Do my arguments have merit? Does the IEEE definition seem inconsistent? Does my definition make logical sense? If you can think of these things on your own merits instead of blindly following the IEEE then you'll see that the definition of OOP is just something academia hasn't really thought about deeply from a theoretical and mathematical standpoint. OOP is more like a term that comes from applied engineering with very little theoretical foundation. If you want some sort of authority I googled some authoritative talk about category theory explained to programmers: ▶ this video I'm sure maybe you heard of haskell and category theory? Haskell is a purely functi

in “C++ is the next C++” · View on HN

Erik Meijer gave a talk called "Category Theory, The essence of interface-based design" ▶ this video Fundamentally, category theory is seen as some sort of holy grail of programming. The hope is that learning about only one API will let you interact naturally and composably with any interface conforming to that design.

in “Basic Category Theory” · View on HN

I watched a talk by Erik Meijer [1] recently where he mentioned that an implementation of a tuple such as (C# syntax mine, but illustrates the point) class Tuple<T1, T2> { public Tuple(T1 t1, T2 t2) { } public T1 Item1 => default(T1); // null for reference-types public T2 Item2 => default(T2); // null for reference-types } is a perfectly type-safe implementation of a tuple that's completely nonsense. I'm curious as to how you might actually encode into the type system that the values that come out of Item1 and Item2 are actually the values you put in. I would love to see tests at the interface level (or typeclass level for Haskellers) rather than the implementation level, to enforce that all implementations of an interface satisfy laws like this. In Haskell, this would mean that you could enforce things like monadic laws which we all assume to be true anyway. [1] ▶ this video

in “Static typing will not save us from broken software” · View on HN

Yes! This isn't an accident. Erik Meijer, who contributed extensively to the Reactive Framework at Microsoft, has been very vocal about his use of category theory for software design. ( ▶ this video ) He currently runs Applied Duality which is uses category theory as its guiding design principle ( [link] )

in “How we used Category Theory to solve a problem in Java” · View on HN