To není potřeba si představovat, stačí se podívat na ejabberd. Je z něj po (více než) deseti letech jeden z nejúspěšnějších jabber serverů (ne-li úplně nejúspěšnější).
Z komercnich veci pak napriklad ITA, ti maji codebase starou dvacet let, stale upravuji, stale funguji (neni to ciste FP, stejne jako naprosta vetsina OOP kodu neni ciste OOP).
Ano, ale to je aplikační doména, která je dostatečně abstraktní na to, aby to šlo naprogramovat elegantně. Je to svět sám pro sebe, vytvořený tvůrci toho projektu. Zajímavé bude sledovat, jak se to osvědčí v prostředí modelování reálných firemních procesů a nelogických požadavků na úpravy, mimo logiku aplikace, které v tomto prostředí běžně vznikají.
Osobně proti FP nic nemám, celkem mi toto paradigma vyhovuje, ale pořádek v kódu bych si od něj automaticky nesliboval. Samozřejmě nejlepší na něm je vazba na teorii kategorií.
No dal jsem realny priklad dlouhodobeho projektu, na ktery byl dotaz
Jinak ja FP pouzivam presne na "modelování reálných firemních procesů a nelogických požadavků na úprav", protoze mi to umoznuje rapid turnaround. Nejsou tam hodnotove objekty, "jen" mapy/vektory/mnoziny, takze u uprav nehrozi nutnost masivniho refaktoringu (ostatne i celkove je kod o dost kratsi). Otestovani se da udelat prakticky nazivo upravou bezici aplikace (to neni vlastnost FP, spis konkretniho jazyka), dobre se to testuje. Kdyz potrebuji pro nejake hodnoty constraints, tak se to proste implementuje funkci - predikatem - ktera si to pohlida.
A navic - takova relacni databaze, na kterych je velka cast businessu postavena - a tyto databaze (zejmena ty s SQL) maji k FP mozna ponekud prekvapive velmi blizko.
169 Odpovědí
44807 Zhlédnutí