>You can't just compose two functions because they're both written in a functional programming language. Obviously not, the types have to be compatible just li

>You can't just compose two functions because they're both written in a functional programming language. Obviously not, the types have to be compatible just like how a lego piece must be compatible. >The programmer has to have the foresight to make their types compatible. Just like a lego builder needs to have the foresight to see whether two lego components are compatible. The analogy still fits. > I think the novelty of the Unix pipe for interoperability is that they (typically) work on one agreed-upon kind of data: human readable, white-space separated. So a lot of tools "just work" with each other. The agreed upon data is just a type. Unix pipes compose functions that take in strings as input and deliver strings as output. The spaces is just an oversight, the whole thing would have been more clean if the type was designed to represent multiple pieces of data like a tuple of words rather than a single string with words divided by spaces. >you could certainly fail to do this with functional programming. Just like how two lego pieces can't compose if they're not compatible pieces facing the right direction. Sockets and plugs must be compatible. A functional program still fits the analogy of legos perfectly. Take a look at lego pieces here: https://brickarchitect.com/2019/2019-most-common-lego-parts/ https://brickarchitect.com/2019/2019-most-common-lego-parts/ There exists lego parts that can never compose with certain other parts. Just like functions and function composition. What you're not seeing is how other styles of programming such as OOP or procedural programming fail to fit the analogy and literally become like organ transplantation. Let's take a look at object composition. How does that work in the context of legos? It's like a lego block with a mutating hole in it and once you can put different things in that hole and that changes the overall lego block. Also with OOP and procedural programming you get lego blocks that can mutate. Lego blocks can transform themselves and other lego blocks. They form an interconnected network of entities that are constantly mutating. To fit the analogy of a lego block you need unchanging blocks. The entire field of Procedural programming and OOP is basically the art of building systems with mutating primitives that constantly change. Imagine constructing buildings using bricks that change shape. Now imagine refactoring code that does this.... Organ transplantation. Also you really just need to try it. Doing the type of grafting and refactoring that's an intrinsic part of programming literally becomes lego-like once you program using the functional style. To really see the big picture I suggest you exclusively try the point free style using Haskell. That being said. There are still massive tradeoffs to doing functional programming. But if your goal is to program like you're using lego blocks, functional programming is the path.