Perhaps there is some language barrier, but this article needs to be heavily edited: at least 50% should be cut.
Remove all the strawman attacks - they just make you sound weird, and makes the article very confusing (not the content, the structure). You obviously feel strongly about them, but the writing is not good enough to make them readable.
For example, random sentences like "The good news is that math doesn’t really care what some Australians or overpaid programmers at Big Tech think."... There's no context for this, so I don't even know what are you even talking about. I'm guessing you're being clever - but I can't agree or disagree with you, because without context it has no meaning. I don't even know who or what you are talking about at all.
Get rid of the strawmen and the personal/political rants. Even when well written, they are boring. Don't tell me why other people suck, show me why your ideas are good. Stop trying to be clever, and just tell me your ideas!
To me this is funny/entertaining w/o taking focus off the topic.
It is the kind of humor you will find in the UK and northern Europe. Dry, and has at least one level of indirection.
I.e. not someone tripping over something and you hear a laughing track dubbed over that – in case you missed that was meant to be funny.
I generally like when a text about a mentally taxing topic is lightly interspersed with such digressions.
Most of my American friends don't grok them and not seldomly react like you – they consider these rants and not funny.
Miami is WAAAY cooler
Enjoy this article before it gets pulled
FWIW I’m not criticising, I enjoyed some of the ideas and they may well be correct.
Bombastic articles get attention but yes I need to tone it down. I don't think anyone cares about the FP cat fights anymore anyway
You bring up an important preface that I forgot to add - thank you. Yes it does seem like I am jumping around and categories have a nasty pedagogical reputation because of how the brain is wired. Categories are a convergent tech but the human brain wants to compartmentalize, so this paper is literally pushing the opposite way we normally process information
https://www.gizmodo.com.au/2017/07/prime-minister-says-the-l...
For a while, FP noobs were terrorized by a bunch of FP thugs on Twitter
> Category Theory (at least applied to computing) studies how instructions are assembled into running programs.
Um, no? As a software engineer who has studied category theory, I use it mostly for denotational reasoning about programs, and to inform type-level decisions. It has nothing to do with "instructions". Perhaps a generous interpretation of this statement would be that monads, one very specific concept in category theory, can be used to model imperative programs—but that would be highly reductionist.
> That’s not to say that FP is useless. FP is obviously quite useful in many situations - but perhaps not be enough to displace the central role of wrapper functions / lambda calculus.
What? Functional programming _is_ lambda calculus. The idea of it displacing lambda calculus makes no sense.
> Why? Mathematically speaking, Category Theory is basically the same as Relational Theory (at least applied to Sets).
Oof. Rel is one category; Set is another.
> There is this fanciful notion of a “computational trinity”- the idea is that devs can somehow write to a single source of “truth” and let artificial intelligence / automation decide how it gets translated to hardware.
No, the trinity refers to the connections between category theory, logic, and programming. It has nothing to do with AI.
Was this article written by an AI?
This is my first thought too. The author sounds like they know FP by swallowing all kinds of info about it from articles around the net regardless of them being right or wrong.
However functions still have single entry/exit that limit reusability of the contents
Cat crafting > FP because it can avoid functions entirely
If you don't get that, maybe you missed something in your training
And yes it has everything to do with AI (not categories per se but the article)
> And yes it has everything to do with AI
No, category theory is not about AI. My training was certainly sufficient for me to refute that connection, and the way you keep referring to my "training" rubs me the wrong way.
Could you elaborate on this? What does it have to do with AI?
Perhaps the greatest irony of FP
BTW academic CT researchers are brilliant but usually aren't programmers
But the hate is warranted. Any new tech needs to be able to stand up to criticism
Functional programming theory has relied heavily on category theory ever since functional programs needed to do IO (around the late 90s), so it's fairly common for programmers to understand some basic category theory these days. After all, many things in programming aren't mathematical functions, so if programmers want invariants, then they do indeed need more mathematical objects than lambda calculus supplies.
A better attack on functional programmers would be that they cargo cult category theory - but I don't think the article author is in a position to make that argument.
Whoever missed this connection, I don't trust him to talk about software.
Can you share part 1? It doesn't seem to exist on your site.
Otherwise it might be confusing to call it part 2 - as people will then think 'Ok, where is part 1?'
1) the original way where you have a grid that you can put items/crafting materials on. If you put particular materials on the grid in the pattern for an item, it will give you the option of taking that item at the expense of the ingrediants 2) when they ported to consoles, they made it with a recipe book, where you choose what you want to make and creation just happens if you can - no need to remember patterns, no need to move items into the pattern. The recipe book shows things that you have some of the ingredients of, and has colour coded backgrounds for all the ingredients or just some.
Either way you craft things that the game already knows about. Building things in the world is different - you just place blocks or items where you want them. I'm not sure how that relates to programming. I can't say I really understood the article.
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
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 only pragmatic argument that I could understand is the hard-wiring “issue”; which IMO is not part of FP and neither OOP but just a consequence that explicit intents are simpler than implicit intents.
I understand that this is to introduce to a novelty approach that Multix offers with cats.
But to be fair, not as sofisticate as Multix, Dependency Injection tries to tackle the hard-wiring constraints of imperative.
What I take from FP is Composition rather than Chaining, which much more flexible than the OOP counterpart, inheritance.
I was expecting to learn something new but I just jump in a spooky vocabulary that rather teach me something just waste my time.
The point stand, Multix might be a fabulous approach in coding, but this article failed to give any practical introduction to it, while claiming his superiority in something that totally didn’t resonate with me.
If your mission is getting Multix adopters I will invite you to shift your focus from language/tone/academical complexity; to something more simple, what does it solve?
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
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
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 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
"Now close your eyes and imagine your codebase like a database - some imaginary glowing network floating in cyberspace - and then imagine your ‘program’ as a ‘query’ of sorts that zaps around this network."
This is similar to what you get with logic programming languages like Prolog: A Prolog program is itself like a database, in that you define facts and rules that you can use to define the relations you want to express, and which themselves can also be readily inspected and reasoned about with the same mechanism.
For example, we can define the predicate member/2 to state under what conditions an element occurs in a list:
member(E, [E|_]).
member(E, [_|Es]) :- member(E, Es).
?- member(X, "abc").
X = a
; X = b
; X = c
; false.
?- clause(member(A, B), Body).
B = [A|_A], Body = true
; B = [_A|_B], Body = member(A,_B).
I also like the premise of the article:
"Software complexity is starting to outpace the human ability to keep track of things."
And indeed: There is hope that several kinds of problems we are facing today can be avoided if we are able to more easily reason about the code itself. For example, by running the code "hypothetically" and analyzing its consequences, we may be able to automatically detect certain classes of errors and failures before they happen in practice.
For instance, I often think about software problems such as those described in https://en.wikipedia.org/wiki/British_Post_Office_scandal, and wonder: Can they be avoided by analyzing the software itself in better ways, and by writing it in such a way that we become able to "ask" the program itself: "Can such a problematic case even arise in practice?" Thus, in analogy to querying a database, we could pose and resolve questions about computations and their logical consequences.
I watched your video “farting around” and saw the mini language and the different terminals, but I still have no idea how that plus all the rhetoric in your blog post amount to something that people might want to use to solve real problems. Have you just connected up a bunch of concepts in your head and assumed that they are world changing? Would you be able to write documentation and examples explaining how people might use these concepts to solve actual problems?
It takes a certain kind of person, independently minded, to go so far down a rabbit hole and not care what people invested in the status quo (the overwhelming majority in tech) might think. And, since I’m also prone to this “style” of working, and also aware of how it interplays with personality, I’ve thought about it quite a bit, and my conclusion is that it’s potentially high reward in terms of innovation but it’s also high risk in terms of actually amounting to something.
It’s hard in tech, because if you were a visual artist your style of work would be rewarded as interesting and provocative but in tech it all has to make some kind of sense and guh can’t have any fun god forbid… it’s almost like we’ve been brainwashed… there’s not a lot of room for concept art in technical architecture (unfortunately).
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
I'm not sure if that reflects the article or my own intelligence. In either case these ideas need better explanation if they want average developers like me onboard.
What I like about FP is that I can reason about the program in my head. Especially with F#'s strong type system. Often I can sit down and plan a simple system just by writing down the types I need to represent my domain. Then I can write down the function signatures/types for the actions I need to get my program working. Then it's like painting by numbers to fill out the function bodies.
This crafting thing sounds like copilot on steroids. Copilot is amazing but is also unreliable. I'm not sure how on earth this is all going to be reliable. It also sounds like it would be harder for me to understand what is going on. To me that's a step backwards.
My brain is fried trying to understand that article. I'm seriously confused.
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
My point is people don't care about these issues and just want to ship code.
At least Go is kind of enough to add good error messages.
And those concerned with speed on hardware are probably not the ones who want the flexibility and interactivity of high level languages