V OOP se obejdu bez getterů, setterů a veřejných atributů. Ve FP se určitě obejdu bez lens, aniž bych musel psát boilerplates. Přinejhorším si je nechám vygenerovat editorem a upravím na přesnou míru.
Tak pro začátek určitě ano - dokud člověk nezačne nějak víc pracovat s vnořenými strukturami, tak se fakt bez Lens obejde; a ony ty vnořené struktury až tak časté v kódu nejsou. Ostatně i ten příklad s user-agentem - pokud by to byla nějaká REST služba, tak bude mít asi definovaný nějaký interface, takže se k tomu udělají odpovídající struktury v programu a vygeneruje se serializace/deserializace. Ono je docela rozumné, když člověk ví aspoň rámcově, co to dělá, a lensy jsou fakt magie. Na druhou stranu při práci s vnořenými strukturami - a to třeba "generický" json je - je to bez lens silně nepohodlné.
FP programátoři jsou totiž docela neradi, když jim "pure" kód vyhazuje výjimky. Takže když v pythonu napíšu:
someJson['key'][3]['nextkey'] + 1
Tak to může vyhodit výjimku tak zhruba tak ze 7mi důvodů (cca. 3 různé výjimky v pythonu). No a FP programátor sice nutně neprahne po tom každou výjimku ošetřovat, ale docela by rád, aby ta funkce byla "totální" - tzn. pro jakýkoliv vstup to "skončí" (tzn. nevyhodí výjimku, ale něco vrátí). No a kombinace lens a Maybe Monad pak umožňuje tu funkci napsat jako:
f someJson = do
num <- someJson ^? key "key" . nth 3 . key "nextkey"
return (num + 1)
a ač to na první pohled nevypadá, tak tahle funkce je totální a vrátí buď výsledek nebo Nothing a nevyhodí výjimku (pokud to nevyhodí (+)). Bez lens by to asi nějak šlo, kdyby si člověk napsal vhodné funkce, tak by to mohlo i vypadat:
f someJson = do
num <- getKey "key" someJson >>= getNth 3 >>= getKey "nextKey"
return (num + 1)
Ale už to není tak elegantní a hlavně jakákoliv modifikace té vnořené struktury by už fakt byla problém.