Mam doświadczenia z książek "Little Schemer" i "How to Design Programs". Wiele osób chyba myśli, że programowanie funkcyjne da im wolność i nie będą już musieli używać tych paskudnych obiektów i klas tylko łatwych do zrozumienia funkcji. Oczywiście można programować w taki najbardziej naiwny sposób w stylu (fold(map(filter x))) tylko czym to się różni od pradawnego programowania proceduralnego z funkcjami. Te dwie książki, o których pisałem są przeznaczone dla początkujących ale żeby je zrozumieć trzeba poświęcić dużo czasu. Przekazywanie rekurencyjne funkcji która kolekcjonuje wartości, reprezentacja obiektów za pomocą lambd, jakieś nieoczywiste abstrakcje Y-combinatory. To wszystko nadaje się na uczelnie/ do zabawy a nie do problemów prawdziwego życia. Programiści mają programować a nie uczyć się matematycznych teorii, rachunku lambda czy czego tam jeszcze.
Czyli tak de facto nie masz żadnego doświadczenia komercyjnego związanego z programowaniem funkcyjnym, a jednocześnie bezpośrednio uderzasz w cały paradygmat mówiąc, że nadaje się jedynie na uczelnie/do zabawy. Ma sens, weźmy na przykład takiego Netflix'a - jak powszechnie wiadomo, mała firemka skierowana głównie na marnowanie swoich zasobów poprzez wprowadzanie języków korzystających z paradygmatu, który do niczego się nie nadaje.
Wyprowadzając Cię z błędu, wiele osób nie myśli, że programowanie funkcyjne da im wolność i nie będą musieli używać obiektów i klas. Przykładowo taka Scala łączy oba paradygmaty i na rynku trzyma się całkiem dobrze, a wręcz ostatnimi czasy umacnia. Jedne problemy da się łatwiej rozwiązać w jednym paradygmacie, inne w drugim, nie ma na to reguły i złotego środka. Wiadomo za to, że nie bez powodu niektóre koncepty z programowania funkcyjnego przenikają do języków czysto obiektowych, na przykład Javy.
Lambdy są już dostępne w większości mainstreamowych językach, nie musisz stosować żadnych "nieoczywistych abstrakcji Y-combinatory", nie musisz znać żadnej matematycznej teorii czy "czego tam jeszcze". Można wykorzystywać Monady, Funktory czy inne Monoidy nie mając żadnych podstaw matematycznych. Inną kwestią jest to, że nie bez powodu mówi się, że programy napisane czysto funkcyjnie są łatwiejsze do utrzymania i rozwoju, oczywiście ten aspekt ma związek z tym, że duża część powstającego kodu obiektowego jest po prostu słaba jakościowo.