Wpis z mikrobloga

#programowanie i głównie #java
Spodziewam się gigantycznej ilości hejtów, ale co tam... (uwaga, długie)
Czy tylko ja uważam że takie praktyki: http://koziolekweb.pl/category/inzynieria-oprogramowania/ekstremalna-obiektowosc-w-praktyce/
Jak i sporo więcej, jest momentami chora?
Ja rozumiem że dla was w javie EE nic się nie liczy, kod ma wyglądać jak księżniczka i może być wolny i ramożerny.
O ram tak właściwe martwić się nie trzeba, jest tani, ale jak widzę dziwne praktyki które mogą znacznie spowolnić kod ale podobno są "ładniejsze" (większość po rozbudowanie wygląda jak plątanina znaków dla mnie...) to jednak mnie coś bierze. Nowe Xeony na drzewach nie rosną, a czasem środowisko może zmusić nas do używania tylko 1 wątku z ograniczonym czasem.

Tworzę czasem dla siebie, lub innych apki w javie, nigdy nie miałem jakiegoś problemu z wydajnością, za to zawsze słyszę od innych jakie to javowe apki są wolne, pobieram... i są wolne, ale nie dlatego że java, tylko wszyscy pchają te dziwne praktyki do kodu na desktopy, już to co robicie w web devie mnie nie interesuje, tam zawsze panowały dziwne zasady by wszystko było jak najwolniejsze, ale to nie ja za to płace więc...

np: http://koziolekweb.pl/2012/01/20/ekstremalna-obiektowosc-w-praktyce-czesc-9-nie-uzywaj-getterowsetterowwlasnosci/
Jak najbardziej zgadzam się z tym że obiektowość to nie get/set, tylko głównie metody które na tych danych już operują.
Ale jak czytam żeby użyć refleksji zamiast stworzyć settera, a do reprezentacji danych użyć toString to jednak mnie coś bierze.
Jak najbardziej tworząc np grę zrobię raczej render(); w obiekcie, niż będę pobierać dane modelu z obiektu getterem, ale nie będę przecież toStringiem reprezentował wyniku np zadania, kiedy to ma być graficzne.
Tak samo kiedy chce stworzyć możliwość zmiany np koloru oczu to nie będę wchodzić tam refleksją tylko dlatego że ktoś coś takiego wymyślił, będzie to znacznie wolniejsze rozwiązanie... (no nowości aka unreflect z MethodHandle znacznie to poprawiają, ale refleksje to dalej refleksje...) tylko stworzę normalną metodę setEyeColor.
Tak samo stworzę metodę getLocation dla gracza/potworka, bo jak inaczej mam stworzyć API dla mojej gry? (ale pewnie obiekt były kopią, immutable do tego)

dalej: http://koziolekweb.pl/2012/01/14/ekstremalna-obiektowosc-w-praktyce-czesc-8-opakowywanie-kolekcji-w-klasy-specyficzne-dla-kontekstu-wykorzystania/
Znowu, zgadzam się że lepiej stworzyć metodę np containsEffect(...) niż getEffects() o ile to możliwe, a jak już zwracamy... to albo kopię, albo opakowaną w unmodifiable, ale po co tworzyć własny dziwny obiekt i zaprzęgać do pracy klasy anonimowe które nie dość że zjedzą ram to spowolnią kod, bo każde wywołanie musi stworzyć nową instance klasy, przekazać parametry i potem odwoływać się do pół klasy, co jest wolniejsze niż do pół lokalnych. (oczywiście nadzieja w JIT-cie, ale javowcy chyba za bardzo na tym polegają czasem, tutaj powinno sobie poradzić, z tym że przez pierwsze minuty używania apka tak tnie że można iść zrobić kawę i obejrzeć odcinek serialu...)

http://koziolekweb.pl/2011/12/19/ekstremalna-obiektowosc-w-praktyce-czesc-7-nie-uzywaj-klas-o-wiecej-niz-dwoch-polach/
He he, czyli co, tak dla jaj zamiast Vector z int x,y,z stworzę 1 wektor w 2D a potem dodam kolejny z 3D i ponownie spowolnie kod? no i oczywiście bez getX() tylko printX() do strumienia i ze strumienia sobie odczytam i dopiero użyje?
I oczywiście będzie to czytelniejsze?

http://koziolekweb.pl/2011/11/06/ekstremalna-obiektowosc-w-praktyce-%E2%80%93-czesc-3-opakowuj-wszystkie-prymitywy-i-stringi/
To podobnie... różnica wydajności obiektów vs prymitywów jest ogromna, JIT czyni cuda, ale bogiem nie jest, więc po co od razu pisać nie wydajnie? Czasami obiekty się przydają, ale kiedy nie ma to żadnego zastosowania logicznego... to po co.
Tym bardziej jeśli mamy za każdą operacją klonować obiekt, GC w javie radzi sobie wyśmienicie dobrze z małymi tymczasowymi obiektami, ale to dalej czuć jak ci RAM raz na 2 sekundy rośnie do 2GB i spada do 300MB to obserwuje dość często..

Tak samo nie rozumiem używania takich zabawek:
http://koziolekweb.pl/2016/06/19/pattern-matching-w-javie-z-javaslang-iii/ http://koziolekweb.pl/2016/06/18/pattern-matching-w-javie-z-javaslang-ii/ http://koziolekweb.pl/2016/06/17/pattern-matching-w-javie-z-javaslang-i/
Momentami dają całkiem ciekawy efekt, ale narzut pamięciowy i wydajnościowy jest ogromny, każdy warunek zamiast być prostym ifem lub switchem jest masą obiektów z masą branchy i masą klas.

I chyba największa głupota jaką tam wyczytałem, a potem rozmawiałem z autorem:
http://koziolekweb.pl/2016/04/04/czy-da-sie-pisac-kod-bez-jawnego-uzywania-if/
Twierdzi że jeśli zastąpimy if-y streamami i innymi konstrukcjami, to kod nagle nie będzie złożony i będzie w nim mniej branchy...
Co jest najgłupszą rzeczą jaką słyszałem od kiedy dowiedziałem się co to komputer, "czego nie widać tego nie ma" takie jest chyba motto autora bloga, bo chyba każdy rozgarnięty człowiek wie że pod tymi metodami kryje się cała masa branchy.
(nie wiem czy gdzieś jest jeszcze kopia tej rozmowy w której uparcie tego bronił)

Do tego autor sam wszędzie łamie wszystkie zasady które opisuje, w jednym miejscu pisze by wcięcia/bloki w kodzie ograniczyć do jednego poziomu, a zaraz w innym miejscu trzepie ich kilka: http://koziolekweb.pl/2016/05/03/jak-napisac-takewhile-w-javie-8/

========================

I to co jakiś czas temu mnie wyprowadziło z równowagi - nie ze względu na kod, ale przez autora:
http://koziolekweb.pl/2016/06/16/lenistwo-ponad-wszystko/
w "Prawdziwie leniwe obiekty" jakiś czas temu, zamiast jakiegoś interfejsu istniał Integer, autor bloga był zawzięcie przekonany że magicznym cudem biblioteczka która nie edytuje kodu w czasie kompilacji stworzy klasę rozszerzającą Integer, zgłosiłem mu to, w odpowiedzi dostałem że się nie znam i to zadziała:

wszystkim działa, a tobie nie... Trochę ogarnij javę, to pogadamy.

Po czym kod został zmieniony na to co widać...
http://www.wykop.pl/wpis/18260751/koziolek666-testujesz-te-kody-ktore-wrzucasz-bo-al/
A do tego klasy proxy są też wolniejsze, no i wspierają tylko interfejsy.

Czy na prawdę nie można pisać kodu jednocześnie wydajniejszego od gówna, a jednocześnie wystarczająco czytelnego i poprawnego by nie było problemów z rozbudową? Tym więcej patrzę na JaveEE tym bardziej mam wrażenie że wszyscy tu dążą to jak największego zużycia pamięci, jak najwolniejszego kodu ale za to zdającego bezsensowne testy robione przez inne programy najciekawiej wyglądającego, bo czytelnym to nie wiem czy można to nazwać. W żadnym innym języku/technologii czegoś takiego nie widziałem. Blisko jest chyba tylko Java w wersji skrypt razem z swoimi bibliotekami typu "isArray"

Uczę się javy kilka lat, umiem coraz więcej, wliczając w to sporo czasu poświęconego na naukę samego bytecode i tego co się dzieje niżej, tego jak działa GC, trochę o samym VM i JIT, ale tego co się dzieje wyżej w javieEE chyba nigdy nie zrozumiem.
Kocham język za standardy i składnie, ale chyba będę musiał go porzucić, bo nie potrafię aż tak niewydajnie tworzyć by się dostosować do reszty. http://memytutaj.pl/uploads/2015/08/28/55e04de3719b9.jpg

Nikt tego pewnie nie przeczyta, ale przynajmniej będę wiedział że jestem jedynym wyrzutkiem tego typu i czas zmienić język na jakiś normalny.
  • 57
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@MicNeo: Zauważ że pisałem o różnych "platformach", ale fakt, w jednym komentarzu chyba tak wyszło :D
Jak na razie hibernate w apce na androida jeszcze nie widziałem, pewnie nie odpala, i dlatego, szukając po google potwierdza to to co myślę, są ludzie co chcieli już tego użyć ale im nie działało, chwała androidowi...
  • Odpowiedz
Jeżeli chcesz dyskutować z jego kompetencjami


@lerner:

"Ja rozumiem że dla was w javie EE nic się nie liczy, kod ma wyglądać jak księżniczka i może być wolny i
  • Odpowiedz
@fegwegw: @blue94: Ale hibernate JEST bardziej wymagające, jak mamy ograniczone zasoby to użycie hibernate może spowolnić aplikacje.
np: http://phpdao.com/hibernate_vs_jdbc/ i w google więcej, nowszych lub starszych. (losowy link)
Do tego hibernate na starte robi testy, które potrafią trochę potrwać, nawet kilka, kilkanaście sekund.
Oczywiście tworząc pod EE, pod różne serwisy bardziej liczy się bezpieczeństwo, niezawodność, i jak najbardziej... z hibernate jest o to łatwiej. Ale kiedy tworzymy zwykłą apkę czy głupią
  • Odpowiedz
Tylko dlaczego ludzie coraz częściej utożsamiają pisanie zwykłych aplikacji do javy EE, i zaczynają używać praktyk z Javy EE w aplikacjach czysto pod Jave SE.


@GotoFinal: podejrzewam, że dlatego, że JavaEE i Spring to tak z 95%, albo i więcej rynku programistów Java (pomijając Androida)
  • Odpowiedz
Czyli to co chce przekazać we wszystkich postach, to że tak nie zawsze jest... że coraz częściej widzę hibernate tam gdzie być go nie powinno, np jak już pisałem - w mojej dzisiejszej robocie.


@GotoFinal: Sugerujesz że możliwość błędnego użycia technologii jest jej wadą?
  • Odpowiedz
@GotoFinal: " Tylko dlaczego ludzie coraz częściej utożsamiają pisanie zwykłych aplikacji do javy EE, i zaczynają używać praktyk z Javy EE w aplikacjach czysto pod Jave SE."

Bo czysta JavaSE to margines rynku. Wolę żeby pisali ten "nieoptymalny kod w JavieSE" i tego się uczyli, bo potem i tak jeśli zostaną w świecie Javy to przejdą w ten czy inny sposób na JEE lub pochodne i nie zazdroszcze superuberzoptymalizowanego kodu
  • Odpowiedz
@GotoFinal: Istnienie czegoś takiego jak isArray wynika z tego, że java w wersji skrypt jest dynamicznie typowana.

Jeżeli chodzi o OOP to głównie liczą się interfejsy. Kod ma być łatwy do modyfikacji i utrzymania, a interfejsy znacząco w tym pomagają. Czasem poświęca się trochę wydajności na rzecz powyższych atutów. No chyba, że głównym czynnikiem aplikacji ma być szybkość i wydajność - ale wtedy raczej nie korzysta się z javy.

Co
  • Odpowiedz
@GromLoL: Trochę mnie to smuci że java żyje EE, ale niestety o tym wiem.
I nie piszę też że kod ma być super-hiper zoptymalizowany, oj wtedy to bym miał znacznie więcej uwag, ale kod ma być też właśnie łatwy w utrzymaniu i dobrze by było jak by opierał się na znanych praktykach, inaczej firma wprowadzi się w róg i potem musi szkolić tych ludzi, co kosztuje. Bo ktoś sobie wybrał
  • Odpowiedz