choćby dlatego, że połączenie w dowolnym momencie może ci się wywalić
Czyli połączenie się zmieni - dla tego samego, prawidłowego połączenia powinieneś otrzymać ten sam wynik ;-)
Dokładnie, bo połączenie jest stanowe - i jakkolwiek byś się nie starał to tego nie zrobisz.
Zresztą nawet nie o to chodzi - odnoszę wrażenie, że usilnie próbujesz "obalić" FP,
Moim celem nie jest obalanie FP (bo sam napisałem, że jest fajne) ponieważ zanim ono zrobiło się popularne kilka mądrych osób łopatą siłą nałożyła mi do głowy wiele rzeczy, które później zobaczyłem w tymże paradygmacie (choćby to, żeby dbać o jak najczystsze funkcyjnie metody, nie trzymać stanów tam gdzie nie trzeba itp.).
Zareagowałem wtedy, kiedy zobaczyłem podane kilka regułek "do wierzenia" jak to zrobił @Kamil Żabiński w swoim poście. Na prosty przypadek - ktoś spieprzył obsługę wyjątku i OP postanowił się wyżalić - kolo przedstawił trzy reguły zupełnie oderwane od najważniejszego zagadnienia - co się pisze.
Przy czym nawet takie abstrakcje jak TCP nie wpływają na samą ideę FP; gdybyś zasymulował połączenie do bazy w różnych stanach (np. w prawidłowym, w broken pipe itd.), to Twoja funkcja dla każdego z tych stanów powinna działać deterministycznie - a to już jesteś w stanie bez problemu zaprogramować i przetestować.
Połączenie może zmienić stan w dowolnym momencie, a odczyt z socketa nie jest operacją atomową - więc nawet jak przekażesz aktywne połączenie to w którymś momencie . To miałem na myśli przez "w rzeczywistym świecie".
A FP nie jest uniwersalnym zbiorem prawd (...)
Kto twierdzi, że jest?
Odsyłam do wyżej wspomnianego postu i do sytuacji. Zauważ, że nigdzie nie atakuję FP jako takiego (nawet nazywam fajnym), tylko zauważam, że są jednak sytuacje gdy zasady trzeba naginać.