Did Functional Programming Get It Wrong (Part 2) – Minecraft-Style Crafting
multix.substack.com
multix.substack.com
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!
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
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.
FWIW I’m not criticising, I enjoyed some of the ideas and they may well be correct.
Miami is WAAAY cooler
Enjoy this article before it gets pulled
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
"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
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
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.
I _did_ go there and got transported into something straight out of the 90’s , made by a 16-year old boy.
Did not find part 1 of the article, though.
Sorry.
Actually 1960s
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
Not mainstream programming for sure
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
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?'
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
> 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?
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)
Could you elaborate on this? What does it have to do with AI?
Categories are about composition. Crafting is also about composition - using inference rules. https://en.wikipedia.org/wiki/Category_theory
The classic schematic representation of X Y Z shown on the above wiki page is basically a crafting rule to create Z. That is, if the AI knows about a "path" (think back to your homotopy training) from X and Y to Z then it can craft a Z from X,Y if it needs to
Yes this is exactly reverse to how we normally think about the caller/callee relationship
> 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.
The classic schematic representation of X Y Z shown on the above wiki page is basically a crafting rule to create Z. That is, if the AI knows about a "path" (think back to your homotopy training) from X and Y to Z then it can craft a Z from X,Y if it needs to
Reducing or eliminating "functions" means reducing or eliminating the refactoring problem
The main claim is that crafting > functions because crafting does not have the single entry/exit drawback that functions have
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
I argue that is due to granularity of function implementation. After all, if I have:
f(x) = 2x + 3
That is really
g(x) = 2x
h(x) = x + 3
and f(x) = h(g(x)). So by breaking the function into irreducible pieces I have achieved maximum reusability.
It seems like the core argument here is that if we (effectively) break down all functions into their smallest granularities and have some sort of ability to (SQL) "SELECT" / project / join those functions together we'll enable some sort of higher-level ability to construct complex software.
There are three reasons I disagree with this:
1) The universe of irreducible functions is infinite.
2) The universe has state and evolves. This means that the (SQL) "SELECT" / project / join of functions described above must itself necessarily change its behavior with the evolution of the universe, and I suspect this (in itself) is an intractable problem.
3) From an API perspective, 99% of the APIs today do not even form a category. That is, I cannot directly connect one object (API) to another object (API) because no morphism currently exists to enable me to do so. Worse, what that morphism is depends on the product of the domain and range of the APIs being connected. Automatic code traversal via some sort of SELECT is doomed to failure unless the set of morphisms is complete. The alternative is to try to automatically generate the correct morphism based on the SELECT...
... and that is exactly what software developers do. So while Multix has some interesting features built into it, based on the above it appears that the goal of the research is to essentially build a god-like AI that writes the software for us. I think that's really why there is abundant skepticism here.
In practice, you only need to break down enough to interface w existing APIs
The morphisms are controlled by the crafting system, which is really a higher order type system
No you don't need to achieve god-like powers any more than GitHub is the source of all code on the planet (it doesn't have to be all or nothing).
Even the crafting rules themselves contain FP chains. In my real world work, I use a mix of crafting, FP chains and old school functions.