Wydawało mi się, że używanie wyjątków do sterowania flow programu jest dość powszechnie uznane za złe, jednak potem przeczytałem dość długą dyskusję o sensie używania Optionali (że nieczytelne itp). Sam jeszcze nawet juniorem nie jestem, więc do niedawna jeszcze w moim projekcie przy braku użytkownika leciał UserNotFoundException, no ale uznałem w końcu, że to strasznie głupie i tak stopniowo przebiegała przebudowa:
Pierwsze co przyszło mi do głowy to Optional (a konkretniej Option z vavr):

private Option<UserEntity> findUserById(long id) {  
    return Option.of(repository.findOne(id)); 
}

Oczywiste zalety to brak głupich wyjątków oraz nullchecków. Problem zaczyna się, kiedy jest jakiś dłuższy proces gdzie więcej niż jedna rzecz może pójść nie tak (powyżej jedyne co to użytkownika może nie być). Zostając w temacie niech będzie przykład logowania gdzie po podaniu nazwy i hasła ma zostać zwrócony token. Coś w stylu
String login(String username, String password)

Co może nie wyjść? np brak użytkownika, niepoprawne hasło. Samo Option tutaj nie pomoże bo skąd mamy potem wiedzieć co nie wyszło?
Tutaj z pomocą przychodzi Either, kolejna super rzecz z vavra oraz enum z możliwymi błędami:

enum UserError {  
  WRONG_PASSWORD,USERNAME_NOT_FOUND
}

Teraz starczy zmienić powyższą sygnaturę na
Either<UserError, UserToken> login(String username, String password)

Z biegiem czasu praktycznie wszystkie metody u mnie zwracają Either, albo tam gdzie starcza to Option. Dzięki temu część funkcji można fajnie skrótowo zapisać z pominięciem ifów (tak na prawdę te ify są tylko wewnątrz Either i Option). Dla przykładu to logowanie:

return findUserByUsername(username)  
        .flatMap(user -> checkPasswordFor(candidatePassword, user))
        .map(UserEntity::getUuid)  
        .map(tokenManager::generateTokenFor);

Z minusów, niestety trzeba nauczyć się nowego API i trochę innego sposobu myślenia. Dodatkowo dla niektórych pierwotnie to może się wydawać mniej czytelne.

Oczywiście nie neguje wyjątków całkowicie. Są miejsca gdzie powinny one zostać np łapie i odpowiednio rzucam dalej SQLException jakby coś złego było z bazą (bo to faktycznie jest sytuacja wyjątkowa)

Wpis powstał trochę na zasadzie dzielenia się moich przemyśleń przy tworzeniu swojego projektu, na jakie problemy trafiłem i jak je rozwiązuje. Sam za dużo doświadczenia jeszcze nie mam (niedługo ledwie stanę się juniorem(oby)) więc bardzo chętnie powymieniam się uwagami.

Jeśli komuś będzie chciało się to czytać to pewnie w przyszłości coś jeszcze napisze ;)

Trochę inny wpis w temacie #mon ...

Miałem pisać o tym, jak nienawidzę własnego frontu, i jak to najprostsze zmiany i dodanie najprostszych funkcjonalności to męka, i że chociaż back jest daleki od ideału to jednak wprowadzanie zmian podobnego kalibru zajmuje mi 1/10 czasu, co we froncie... Pomimo, że back ma dużo więcej linijek kodu... I że front to pierwsza rzecz, którą zamierzam przepisać.

I o tym napiszę. Ale nie teraz. Napiszę wtedy, kiedy wreszcie uda mi się wprowadzić do frontu tę funkcjonalność, jaką chcę. Jak już tyle zrobiłem, to chociaż dokończę przed wzięciem się za przepisywanie...

Teraz zatem o czym innym.

Ech. Jeszcze jakiś czas temu miałem reakcję alergiczną na to, jak ktoś promował X w dosyć mocno agresywny sposób, tzn twierdząc, że "zacznij stosować X, a zobaczysz, jak twoja produktywność natychmiast wzrośnie", czy "stosowanie X jest warunkiem bycia kompetentym", czy "jakiś tam ficzer w X jest podobny do jakiegoś tam ficzera w alternatywie do X, tylko lepszy", etc etc. Nierzadko także w równie agresywny sposób krytykując alternatywy X. A już najbardziej mnie odrzucało, jeśli ten sam ktoś zaczynał obnosić się z tym, jaki to jest kompetentny bo stosuje i promuje X. A, niestety, z moich (niewielkich) doświadczeń tego rodzaju podejście jest chroniczne.

W związku z tym irytowałem się i nie miałem ochoty tak postępować, gdy ktoś głosił, że nie należy używać properties (bo tell, don't ask), że nie należy używać globali i staticów tylko dependency injection, że należy pisać testy, dużo testów, że należy pisać testy przed kodem, że należy stosować TDD... a jeszcze dawniej (w czasach WinXP i IE6) przez jakieś kilka lat uparcie używałem Internet Explorera, gdyż irytowała mnie nagonka na Microsoft, snobowanie się na nienawidzenie "Micro$hit" i zalecanie wszędzie Firefoxa. (Teraz już używam liska, ale nie Chrome; chociaż z innych powodów)

Obecnie jednak świadomie postanowiłem odejść od tej mentalności. Zacząłem się poważnie zastanawiać, czy nie jestem po prostu aroganckim ignorantem, ludzie, którzy promują te wszystkie patterns, paradigms, etc wiedzą, co robią, zaś moim podejściem krzywdzę tlko i wyłącznie siebie. Nie - nie oznacza to, że staram się wszystkie te paradigms i patterns stosować w tym projekciku oraz unikać tego, co jakiś tam guru określa mianem anti-pattern - ale z innych przyczyn, mianowicie boję się paralysis by analysis; stwierdziłem po prostu, że lepsze jest wrogiem zrobionego, zaś tę grę traktuję jako poligon treningowy, a nie pokazanie się, jaki to wspaniały kod piszę. Czyli: uznałem moje niestosowanie tych patternów za słabość, z której powoli chcę wychodzić, a nie jako swój punkt honoru, jak było dawniej.

Do czego taka mentalność może zaprowadzić, jednak?

Na 1szym roku studiów mieliśmy OCamla. Pani Ćwiczeniowiec nie mogła się powstrzymywać, żeby co chwila nie czynić uwag, jak to OCaml jest gorszy niż Haskell. Już się grupa nawet podśmiewała z niej z tego powodu. Krótkie Googlowanie wykazało, że w Internecie jest podobnie: co temat o Haskellu, to ktoś musi piać, jaki to wspaniały język, jak to wszystko w Haskellu robi się szybciej i wygodniej, aniżeli w innych językach, etc. Oczywiście wówczas nie nastawiło mnie to do Haskella zbyt pozytywnie.

Teraz muszę. Kolejny przedmiot tego już ode mnie wymaga. Ponieważ niektóre koncepty są nietrywialne, czytam sobie http://learnyouahaskell.com/ , by się douczyć... A tam znowu podobne kwiatki:

A lot of people coming from OOP get confused by typeclasses because they think they are like classes in object oriented languages. Well, they're not. You can think of them kind of as Java interfaces, only better.

Oraz:

Because it's not in capital case it's actually a type variable. (...) This is much like generics in other languages, only in Haskell it's much more powerful because it allows us to easily write very general functions if they don't use any specific behavior of the types in them.

Argh. Zaczynam się irytować. Ale, ale - przecież postanowiłem zmienić swoją mentalność. Może więc Haskell rzeczywiście jest świetny, a to ustawiczne pianie na Haskella nie jest bezpodstawne?

https://www.reddit.com/r/Prog[...]red_the_one_language_to_rule/ <- Okazuje się, że jak ktoś już się nauczył Haskella, to w innych językach pisze tylko, jeśli naprawdę musi, że 95% pisania w innych językach to wynajdywanie koła na nowo, bo robi to, co w Haskellu jest już "solved problem", że wszystkie ficzery i "best practices" z innych języków to tylko cień tego, co jest w Haskellu, że w Haskellu pisze wyraźnie szybciej oraz z mniejszą ilością bugów, niż w innych językach, że choć przesiadka z Haskella na inny język jest oczywiście możliwa, to jednak to jest tak, jakby zacząć kodzić z rękami związanymi z tyłu pleców, więc po co jeśli się nie musi, etc etc. Nie wszyscy w tym wątku tak twierdzą, ale najwięcej upvote'ów ma post piejęcy na Haskella. (Tenże sam człowiek twierdzi dalej, że dzięki wspaniałemu systemowi typów Haskella jego kod nie ma bugów - znowu: arogancja, czy rzeczywiście prosta konsekwencja ścisłych związków Haskella z matematyką i w szczególności z dowodami poprawności?)

Sam nie wiem. Z jednej strony czuję się poirytowany (śmierdzi to fanbojstwem). Z drugiej strony... Jaka byłaby różnica między mną odrzucającym teraz wyższość Haskella nad C# niż mną piszącym dawniej takie wątki na forum czy odrzucającym wyższość TDD nad nie-TDD? W obu wypadkach jest to samo: (a) nie mam argumentów merytorycznych (b) nie chce mi się uczyć (c) irytuje mnie agresja, z jaką jest to promowane.

Wybrałem C# do backendu tej gry... po prostu dlatego, że był to jakiś wybór. Wybór mainstreamowego rozwiązania do danego zastosowania wydawał się być najsensowniejszy, dopóki sam nie będę miał tyle doświadczenia, by wiedzieć lepiej. A oprócz tego, w porównaniu z "dziwnymi" rozwiązaniami takimi, jak wt czy właśnie Haskell, pewnie .NET jest "dojrzalszy", ma lepszą dokumentację, jest bardziej nastawiony także na początkujących (jak ja) i przez sam wzgląd, że więcej ludzi tego używa, trudniej się na czymś naciąć. Poza tym ze wzgl. na powszechność nauczenie się tego da mi najwięcej. No i chyba w ogóle nie jest to zła platforma. Czyli, wybór najpraktyczniejszy. (Takie było moje rozumowanie za tym wyborem). Za dużo już też napisałem, by teraz nagle chcieć wszystko przepisać w Haskellu. (Z drugiej strony Prof od Haskella twierdzi, że Haskell już nie jest hipsterski, że już idzie w mainstream - bo taki świetny?)

Gdybym miał jednak zaczynać od zera... Czy jest, czy nie jest prawdą, że wybór inny niż Haskell to po prostu skazanie siebie na więcej męczącej pracy, poświęcenie na tę pracę więcej czasu i nawalenie więcej błędów? Nie mam danych, by ocenić.

A i tak przepisać to będę musiał prędzej czy później. Przepisać albo porzucić.

Oto jest więc pytanie... Czy ta sama zmiana w mentalności, która każe mi teraz uznać, że design patterns zostały jednak prawdopodobnie wymyślone nie bez kozery, a jeśli nie stosuję TDD, to nie dlatego, że TDD ssie i jest dobre jedynie jako zabawka fanbojów Roberta C. Martina, ale raczej dlatego, że po prostu nie umiem i powinienem prędzej czy później nadrobić ten brak w kompetencjach... Czy z powyższych powodów ta sama zmiana w mentalności nie wymuszałaby także uznania, że jeśli piszę w C# a nie w Haskellu, to wynika to tylko z moich braków w Haskellowych kompetencjach i powinienem się douczyć Haskella i potem już wszystkie nowe projekty pisać w Haskellu, o ile z innych powodów nie będę musiał pisać w czym innym? Albowiem z mojej perspektywy obie sytuacje wyglądają na niepokojąco podobne.

Jak myślicie, ile to będzie osób na jedno miejsce?

Sabre nagoniło sobie masę kandydatów, większość zostanie odrzucona ale cieszmy się i radujmy :)

Czyżby koniec dyskusji o algorytmie mnożenia? Jeszcze tylko jedna mała hipoteza do udowodnienia i będziemy mieć O(n log n):)
https://www.wired.com/story/m[...]-the-perfect-way-to-multiply/
#links #theory

@Hispano-Suiza: twój ulubiony język