A FP není superior nad OOP a vice versa, oboje jsou stejně použitelné a silné strategie, každá ale hledí na problém trošku z jinýho úhlu.
Takový ten biologický vs matematický pohled...
S tim nesouhlasim. Ano, v jistem smyslu jsou dualni - kazdy OOP program/pattern lze prevest do FP tak, ze misto predavani dat (typicky v nejakych objektech) do jinych objektu budeme predavat funkce (operatory) opacnym smerem. Jinak receno, v OOP vybalujes (delegovanim) vstupni data z objektu, v FP nabalujes (skladanim) funkce, ktere nad daty pracuji.
Ale FP ma v tomhle mirnou vyhodu, protoze predavani funkci identity je v programu mnohem lepe videt nez predavani identickych dat. Takze v OOP pristupu snadno vzniknou mezivrstvy, ktere by v FP bylo mozne trivialne odstranit.
Druha, taky znacna vyhoda FP, plyne z toho, ze je postavene na matematicke teorii (a nikoli tolik na intuici navrharu jazyka) a tudiz je o neco rigoroznejsi. Take to vede k tomu, ze nektere koncepty, ktere existuji treba v Jave jako duplicitni (napr. navratova hodnota a vyjimka) je mozne v FP modelovat jako stejnou/podobnou vec.
Oba problemy by sly asi odstranit, ale muselo by se OOP koncipovat trochu jinak (coz ale asi nema smysl z historickych duvodu). Jak uz to tak byva, vyvoj temer vzdy probiha od slozitejsiho k jednodussimu.
Konecne, je take mozne, ze FP vede k lepsi znovupouzitelnosti. V FP jsou to datove typy, ktere tvori API mezi jednotlivymi funkcemi, narozdil od interfacu v OOP. Vyhoda je v tom, ze datove typy jsou samopopisne (protoze nemaji chovani), zatimco interface je napul definovany chovanim prislusne implementace (ono vubec interface toho moc o chovani objektu nerika). Je to podobne jako v Unixu - prikazy Unixu maji take sva vstupni/vystupni data (typicky samopopisny text) jako API, a proto jsou velmi znovupouzitelne.