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

@blue94:

kod musi wyglądać jak księżniczka bo przy takich projektach zazwyczaj pracuje więcej niż jedna osoba.

No właśnie, więc zamiast wyglądać jak księżniczka, powinien wyglądać jak kod. Prostu do zrozumienia, rozbudowy, nauki, a nie księżniczka z wodotryskami i masakryczną ilością zbędnych dodatków.
Chodzi mi właśnie o takie nadmiarowe dodawania składni która nie jest potrzebna i znana tylko przez kilku dziwnych ludzi, weź potem takich znajdź lub zrób szkolenia czy też
  • Odpowiedz
@blue94: Co do serializacji.... jak używali jakiejś wbudowanej serializacji to trochę rak, jak już się robi, to z jakimś sensownym powszechnym standardem... jest np message pack, albo można nawet stworzyć własny, ale wtedy zrobić dokumentacje i fajny sensowny kod, bez żadnych refleksji i innych pierdół.
Wtedy problemu by nie było... Ale też nie widzę twojego problemu, wbudowana serializacja chyba jest ustandaryzowana?
No chyba że to janusze ot-tak losowo używali funkcji,
  • Odpowiedz
@GotoFinal: masz 100% racji. Jak przeczytałem to:

Prezenter może dostać się do obiektu via refleksja względnie odpowiednio zinterpretować wyniki z metody toString


to aż zachcialo mi się płakać. Do tej pory pobieżnie czytałem ten blog jak trafiałem na niego na mirko i czasami odkładałem sobie coś na później, ale teraz widzę, że to jest stek jakichś korpobzdur. Dzięki Bogu mam dość doświadczenia, żeby móc to zauważyć, bo jeszcze bym się
  • Odpowiedz
@blue94: .net dobrze sobie radzi na linuksie. Nie mam wiarygodnego porównania szybkości między platformami, ale mam co dzień przed oczami realny i namacalny dowód, że c# na linuksie potrafi być na tyle szybki, że nie warto trudzić się z c++ (ze względu na większy koszt programistów i bardziej skomplikowany kod). A .NET Core może tę sytuację tylko polepszyć.
  • Odpowiedz
@blue94: sposobów zapisywania daty to nawet w jsonie widziałem od raka, raz liczba - ilość ms, albo... ilość sekund, czy nawet minut, albo nawet każda jednostka jako osobne pole... więc to wszędzie można się posrać jak autor kodu był kreatywny :D Tylko jednak bez dokumentacji w tekstowym szybciej się połapać.
  • Odpowiedz
@blue94: Ale księżniczki są sztucznie ładne ( ͡° ʖ̯ ͡°)
Albo to co piękne skrywa się pod nadmiarem niepotrzebnych świecidełek i innych dupereli ( ͡º ͜ʖ͡º)
  • Odpowiedz
@GotoFinal: tak, pamiętam jak pisałem apkę na androdia i problem był właśnie z datą. Pikanterii sytuacji dodawało że apka była dla kanadyjskiej firmy. Oni wystawiali RESTa, czas odpowiedzi średnio ~6-12h. Po 2 tygodniach udało się dojsc do wniosku że coś z-----i na RESTcie z datami, mimo że się upierali że u nich wszystko ok ( ͡º ͜ʖ͡º)
  • Odpowiedz
@GotoFinal: Jeżeli chodzi o interfejsy itd to odnosiłem się bardziej do tego bloga niż Twoich wypowiedzi bo generalnie uważam, że masz tu rację.

A jeśli chodzi o jave to wydaje mi się, że w kwestii szybkości dużą rolę odgrywa występowanie maszyny wirtualnej (nie zagłębiałem się w ten temat, popraw mnie jeśli się mylę). Słabości javy wychodzą szczególnie jeżeli chodzi o embeded. Ja sam lubię javę, choć nie znam jej na
  • Odpowiedz
@super_c: Co do JS, już wyżej tłumaczyłem, że chodzi mi o zabawki tego pokroju: https://www.npmjs.com/package/isarray wszystkie te super małe biblioteczki, dość znany "problem" z node.
Zazwyczaj w innych językach powstaje 1 większa biblioteczka, ewentualnie z modułami by nie były zbyt wielkie.
Duże dependów to tylko dużo możliwych problemów.

Java potrafi być szybka - ale nie jak robimy benchmarka typowych algorytmów z masą wskaźników i bajtów w c++, tylko tam gdzie mamy masę skomplikowanych
  • Odpowiedz