You're not free from the need to specify how to parse the strings just because your whole human readable system is stringly typed.
It comes with the same drawbacks (the lack of static typing is similar to strings with Unix; you have to be aware of the details of the data coming in and out because there is no type system to save you - unlike Haskell), but the benefit is easier composition.
In either case you have to compose functions With the correct types otherwise you hit an error. The difference with dynamic types and static types is when this error occurs. Run time for dynamic types and compilation time for static types. Either way some type of error will always occur regardless.
Though I agree with you if you have a limited number of types things become easier to deal with.
But being able to specify interfaces for lambdas is absolutely fantastic. Something like: "this function takes an object and returns a function that can take either a string or a number and returns a number" is easy to do in Typescript, and useful for figuring out where the lego block fits.
I.e. this will warn (inc "hello") in clj-kondo
Good interfaces enable unexpected things.
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/
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.
That kind of sounds like a structure of living cells. They're more complex than a structure of lego blocks, but they can do a lot more too.
Don't take that as an argument in favor of OOP though. Building with legos is a lot easier to get right than building with cells would be.
The key lies in your choice of primitives. Do you start off with a set primitives that are extremely complex or a set primitives that are simple but complete in the sense that you can build entities of unlimited complexity by composing simpler primitives?
I would say the latter method is easier. But there's no reason why the former method won't work. Biological evolution has built many examples of working machines with primitives of unimaginable complexity.
Basically, it's the infinite monkey theorem.
There's no reason you can't do this with functional programming, but obviously you can do it with non-functional programming too, and you could certainly fail to do this with functional programming.