Wpis z mikrobloga

Kiedyś usłyszałem od pewnego znajomego javowca, który śmiał się z rekrutujących, że "nigdy nie widział dobrze napisanego programu wielowątkowego".

Jak kiedyś usłyszę jeszcze raz coś takiego, to wyśmieję, świadczy to o zupełnej niekompetencji (a miał wtedy okolice 4-5 lat doświadczenia).

To jest równoznaczne do przyznania się do niepełnosprawności programistycznej, sama maszyna Javy operuje na natywnych wątkach OS, a nie mieć świadomości co się pisze i tego, że frameworki działają pod spodem na ciekawych mechanizmach wielowątkowych woła o pomstę do nieba ( ͡° ͜ʖ ͡°)

#java #programowanie #programista15k #it
  • 9
@programista15cm: Tak, znam to i książkę kiedyś próbowałem przeczytać xD Ale samo stwierdzenie, że czegoś się nie widziało, świadczy przede wszystkim o ignorancji.

Ale to był typ człowieka, co pytał noobów co zwróci kolekcja (dajmy na to mapa) jak nie będzie wartości w kolekcji :) Ja mu odpowiedziałem: to zależy od implementacji. A ten na to: no jak to, NullPointerException xDDDD
Ja mu odpowiedziałem: to zależy od implementacji.


@PolishPsycho: Technicznie oczywiście masz rację. Ale to jest taka odpowiedź wymijająca, która odpowiada na każde pytanie "jak coś działa" ale niewiele wnosi. A akurat jeśli chodzi o kolekcje Javowe, to one najczęściej implementują jakiś interfejs ogólny np. List albo Map, a te interfejsy mają swoje *kontrakty*. I każda implementacja musi przestrzegać takiego kontraktu. Kontrakt bardzo dokładnie definiuje co należy zrobić, gdy nie ma elementu.
@Krolik: No ale sam napisałeś, że nie było to opisane w specyfikacji, więc na czym mieli się opierać? Kontrakt tworzy na interfejsie sam autor, a kontrakt na kolekcjach w javie jest praktycznie dowolny :)

Już nie pamiętam czy to dotyczyło mapy bo było to dość dawno, ale sens rzucenia NPE jest oczywisty - rozróżnienie, czy wrzuciłeś wcześniej nulla w wartości czy nic :) - wiadomo, powinno się sprawdzać containsKey but still...
że "nigdy nie widział dobrze napisanego programu wielowątkowego".


@PolishPsycho: pewnie to skrót myślowy. Często programy wielowątkowe nie wyglądają na takie, bo concurrency jest zrównoleglane bardzo prosto np. najpopularniejszym przypadkiem użycia jest request HTTP/obsługiwana wiadomość/cokolwiek per osobny wątek. Przy zdrowo rozsądkowym podejściu tj. share nothing/dużo immutability i użyciu bezpiecznych bibliotek dla dostępu współbieżnego (logger, metryki, klienci) pisze się tak samo jak w przypadku programyujednowątkowego. Dalej mamy kilka poziomów konstrukcji wielowątkowych np.:
*
@PolishPsycho:

Co do wielowątkowości masz całą bibliotekę java.util.concurrent. Blokujące kolejki, executory, completable future itp. da się użyć w zastąpieniu do async/await.


Nie, to jest co najwyżej namiastka. Brakuje choćby czegoś takiego jak selector, współbieżność kooperatywna, prawdziwe IO asynchroniczne. Nie da się też spawnować zadań bez alokacji na stercie. Wszędzie musisz robić callbacki bo nie możesz sobie poczekać na future bo inaczej zablokujesz wątek. I też łatwo narobić wyścigów bo nie masz