Wideo z rantem na ORMy. Kto z was podniósł rękę?

Chciał bym abyście obejrzeli początek tego filmu jakieś 2 minuty i odpowiedzieli na ankietę.

możesz jakiś skrót tego video dać, w dwóch, trzech zdaniach o czym to jest i czemu ORM to anty-wzorzec? (nie mówię, że nie, ale jestem ciekaw po prostu).

Nazwa tematu nijak się ma do treści wątku.

Przykro mi nie mogę edytować tytułu.

Yegor dobrze prawi na wiele tematów, zresztą w podejściu do annotacji, magii itp. mamy podobne zdanie (widać po postach jak ewoluował, ale zaczął tą kupę zwalczać jak ja jeszcze pisałem swoje aspekty).
Niestety - poglądy na rolę kobiet w IT, które publikuje są dośc kontrowersyjne - dlatego raczej na konferencjach w europie/ameryce przez jakiś czas się go nie zobaczy.

Możesz mi wytłumaczyć w którym to momencie dobrze prawi ?

Eee, a to jest ten Yegor od bloga. Nie pamiętam o co chodziło dokładnie, ale pamiętam, że jakieś lamerskie bzdury tam pisał. Nic dziwnego, że skończył w przemyśle konferencyjnym.

EDIT: jednak znalazłem: Getery i setery to zło, immutable ponad wszystko, ORMy wielką pomyłką

Na 42:30 minucie zaczyna się robić ciekawie.

Gość poza tym, że nie wie jak działa Hibernate to pokazuje oczywiste problemy podejścia JPA/Hibernate. Wideo jest słabe - nawet całego nie obejrzałem : lepszy jest POST
http://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.html
Cały jego blog to ataki na przyjęte techniki i słusznie, zgadzam się, że mamy strasznie dużo bzdur w użyciu. Jest troszkę obiektowym faszystą - więc czasami nie wie jak (moim zdaniem) wybrnąć
http://www.yegor256.com/2015/07/28/checked-vs-unchecked-exceptions.html i pisze (z mojego punktu widzenia) bzdury. Natomiast problemy identyfikuje dobrze.
Część artykułów to jakby nie patrzeć to o czym sam krzycze: http://www.yegor256.com/2016/04/12/java-annotations-are-evil.html, http://www.yegor256.com/2014/10/03/di-containers-are-evil.html.

Jest obrazoburcą więc wielu prawdziwym lamerom gula skacze - bo nijak się im nie zgadza z tym co im podpowiedzieli koledzy, którzy się nauczyli z książek z lat 90tych. Atakuje ich ulubione Cargo. Fakt czasem błądzi, czasem bredzi, ale nie jest lamerem jak dla mnie. (Nie znam jego całej tórczości, więc może są tam jakieś gorsze herezje). To dotyczy guntu technicznego.

Natomiast za takie teksty (ma ich wiecej) jest u mnie przegrany:
http://www.yegor256.com/2017/07/04/sexism.html

Gość poza tym, że nie wie jak działa Hibernate to pokazuje oczywiste problemy podejścia JPA/Hibernate

Jakoś w ogóle to do mnie trafia......

Przecież on ma jakieś chore wywody na temat tego, że to rzeczywistości nie oddaje.

Przecież hermetyzacja nie ma nic wspólnego z oddawanie podobieństwa do realnych przedmiotów.
Hermetyzacja istnieje po to żeby lepiej zarządzać zależnościami jak i całe OP.
Java to język wieloparadygmatowy chociaż obiektowość jest uważana za jej największy atut.

O co tu chodzi?

Dupa i dupa, nie lubię javy, chciałem się tego uczyć, a okazało się, że jest płytkie jak borland z templatami na gui.

Nadziany Pomidor napisał(a):

O co tu chodzi?

Dupa i dupa, nie lubię javy, chciałem się tego uczyć, a okazało się, że jest płytkie jak borland z templatami na gui.

I nauczyłem się APL :)

Nie będę się wypowiadał na temat modelowania rzeczywistości obiektowo... bo to szybko prowadzi do paradoksów.

Natomiast jeśli chodzi o Hibernate / ORM javowy to wbrew temu co Yegor mówi... setName czasem updatuje rekord w bazie danych i to jest chore.
Aby wiedzieć czy zupdatuje czy nie i w którym momencie - musisz znać konktekst, gdzie się zaczęła transakcja(sesja), czy obiekt jest nadal podłączony do sesji. Naiwna intepretacja mówi, że nie musisz się tym martwić JPA/HIbernate martwi się za Ciebie. W praktyce to jest częste źródło błedów i nic nie ma wspólnego z hermetyzacją - to jest BASIC, aby znaleźć problem musisz jak śledczy przeszukać cały kod, bo na zwykłym wywołaniu metody i interfejsie obiektu nie możesz polegać.

Niestety to co zwykle się tworzy z Hibernate to taki rozkrok - zwany Anemic Domain Model - te obiekty ani nie są tak totalnie głupie, tak żeby po prostu być DTO do bazy danych, ani też nie mają całej logiki, aby być pełnymi obiektami biznesowymi. Zresztą tu wiadomo wraca wykład : "Encja na twarz...".

Nadziany Pomidor napisał(a):

O co tu chodzi?

Dupa i dupa, nie lubię javy, chciałem się tego uczyć, a okazało się, że jest płytkie jak borland z templatami na gui.

O cześć Zenek. Piętnaście lat prawie minęło od kiedy ostatnio podzieliłeś się uwagami na temat Javy: http://pl.comp.lang.java.narkive.com/0J3D2PRH/java-dupa

Nie no, lubię jave, ale framework swing ssie widać to i to nie wina javy jako gui, a jako podstawa wygląda.

Jako, że w c++ mogę sobie natywnie i to łatwiej niż pod pythona naklepać kod, to ja zawsze będę jave lubił.

kurde wywalili mnie z cs go bo zapomniałem grać, bo odpisywałem jpd.

Kupiłem (i czytałem) jego książkę - tę "Elegant Objects". Jest trochę krejzolowa, ale na pewno ciekawa i widać że ma jakieś oryginalne koncepcje.
Co mówi o ORM-ach to nie wiem. O geterach czy seterach to widzę że ma jakieś koncepcje, ale nie zgadzam się że uniwersalne.

jarekr000000 napisał(a):

Gość poza tym, że nie wie jak działa Hibernate to pokazuje oczywiste problemy podejścia JPA/Hibernate.

No właśnie - problemy jakichś tam bibliotek Javowych, nie problemy wzorca czy idei ORM.

• To nie wina ORM, że Java czy tam inny C# używają tego samego słowa kluczowego do określania typów zawierających logikę jak i nie. Gdyby można było robić jakiś record Book zamiast class Book, to może by całego tego gadania o obiektowości by nie było.
• To nie wina ORM, że twórcy niektórych z nich próbują z nich zrobić jakieś masterframeworki, w których przy odczycie danych można pzypadkiem zaparzyć kawę albo wygenerować HTMLa i go serwować z wbudowanego serwera HTTP.
• To nie wina ORM, że ludzie biorą te persistence modele, które powinny służyć do komunikacji na linii aplikacja <-> baza i opierają na nich logikę aplikacji. A to z kolei jest przyczyną tych wszystkich błędów, że jak się kliknie checkbox w GUI, to nagle zmieniają się losowe dane w bazie, bo akurat jakiś event od zmiany wartości na widoku miał dodany przypadkiem commit transakcji. Przy sensownej architekturze, w której obiekty warstwy danych nie docierają do GUI o takie cyrki trudniej. (Tylko sensowna architektura to prosta architektura, a jak coś jest proste, to nie trzeba do tego oddzielnego stanowiska.)

Ja też z tym "walczę". Tylko ja widzę, gdzie leży faktyczny problem i nie bredzę, że są nim narzędzia, a nie ludzie. To programiści dostają do ręki nowy młotek i nagle próbują nim rozwiązać każdy problem waląc na oślep.
A z drugiej strony, nie wszystko musi być obiektem. Jeśli nie ma logiki, a jedynie proste przechowywanie danych, irzepisywanie wartości wprowadzonej w jakimś GUI do wartości w jakimś źródle danych. Do tego nie trzeba mieć metod w rodzaju rename czy changeAuthor, tu wystarczą gettery i settery. Tu by wystarczyły rekordy... ale ich nie ma, więc używa się klas.

Jest obrazoburcą więc wielu prawdziwym lamerom gula skacze - bo nijak się im nie zgadza z tym co im podpowiedzieli koledzy, którzy się nauczyli z książek z lat 90tych. Atakuje ich ulubione Cargo. Fakt czasem błądzi, czasem bredzi, ale nie jest lamerem jak dla mnie. (Nie znam jego całej tórczości, więc może są tam jakieś gorsze herezje). To dotyczy guntu technicznego.

Widzi problemy, ale nie przyczyny. Jest jak kobieta z tego dowcipu:

Przychodzi kobieta do lekarza i skarży się na ból.
- Gdzie panią boli? - pyta się lekarz.
- Wszędzie - odpowiada kobieta.
- Jak to wszędzie, proszę być bardziej dokładnym.
Kobieta dotyka kolana palcem wskazującym:
- Tu mnie boli.
Następnie dotyka lewego policzka:
- O tu mnie boli.
Potem dotyka prawego sutka:
- O tu też mnie boli - mówi z grymasem bólu kobieta.
Lekarz popatrzył na kobietę ze współczuciem i pyta się:
- Czy Pani jest naturalną blondynką?
- Tak.
- Tak myślałem - kontynuuje lekarz - ma pani złamany palec.

Wiesz jak nazywają się ludzie, którzy nauczyli się programowania z książek w latach 90tych?
Architekci. I tak, oni są złem tego świata. Mają władze, wybierają stos technologiczny, narzucają architekturę i nigdy nie przyznają się do błędu, nawet jeśli z daleka widać, że przyjęte rozwiązania się po prostu nie sprawdzają, powodują ogromny narzut czasowy na implementację prostych rzeczy, a rozwiązywanie banalnych błędów wymaga zdolności magicznych.
Jak to dobrze, że nie mam takich kolegów.

Wiesz jak nazywają się ludzie, którzy nauczyli się programowania z książek w latach 90tych?
Architekci. I tak, oni są złem tego świata. Mają władze, wybierają stos technologiczny, narzucają architekturę i nigdy nie przyznają się do błędu, nawet jeśli z daleka widać, że przyjęte rozwiązania się po prostu nie sprawdzają, powodują ogromny narzut czasowy na implementację prostych rzeczy, a rozwiązywanie banalnych błędów wymaga zdolności magicznych.

Z drugiej strony... to właśnie dzięki takim architektom i programistom forsującym overengineering jest aż tak wielkie zapotrzebowanie na programistów. Przecież bez overengineeringu do uzyskania tej samej funkcjonalności potrzeba by było wielokrotnie mniej pracowników.
Na architekta, który stara się realizować zadania w sposób jak najprostrzy trudno trafić, bo pracuje w pojedynkę, albo w małym zespole.

Przed przeczytaniem dyskusji nawet rozważałem obejrzeć jakiś filmik, ale po komentarzu somekinda nie widzę sensu. Ktoś może streścić treść z filmu albo napisać te pytania?

Niby nie ocenia się książki po okładce, ale tytuł wideo sugeruje, że autor będzie bronił obranej tezy. Równie dobrze mógłby twierdzić, że "piły mechanicznej są złe, bo zna przypadek jak drwalowi ucięło nogę". Osobiście:

• szkoda było mi czasu na obejrzenie tego wideo
• nie widzę nic złego w stosowaniu ORMów