Tak jak w temacie. Czy ten cały pan Seliga faktycznie wie o czym mówi? Czy to on jest jakimś tam konkretnym wyznacznikiem poziomu w świecie programowania? Mnie osobiście ten człowiek irytuje, wydaje się być zażenowany całym światem a prowadząc jakąś prezentacje mówi 15 słów na dwie sekundy, przyśpieszony oddech - jakby stał przed jakimś co najmniej agresywnym bokserem albo po prostu jakby był na prochach.
0
0
Też mnie to zastanawia. Widziałem jego występ na jutube gdzie mówi o rekrutowaniu do pracy. Sprawia antypatyczne wrażenie gościa, który wszystko wie lepiej. To znaczy teoretycznie jest możliwe, że faktycznie jest tak zajebisty :) Praktycznie, to miałem do czynienia z takim jednym gościem przekonanym o swojej wszechwiedzy i była to mordęga na co dzień. Każdy poza nim robił wszystko źle, nie licząc osób, które przypadkiem robiły coś w podobny sposób. W sumie wniosek z tej prezentacji o rekrutowaniu jest dla mnie następujący - jeśli rekrutuje Cię ktoś taki jak on i działa Ci to na nerwy, to szukaj innej roboty.
0
Zadaj sobie pytanie czy jest sens przejmować się zdaniem 1 gościa.
1
Uczciwie będzie powiedzieć: po owocach ich poznacie. Używacie Jiry? Ja tak i moim zdaniem szału wielkiego nie ma ;) , chociaż niewątpliwie to oprogramowanie odniosło duży sukces (w końcu, żeby go nie używać, musiałbym zmienić pracę, może więcej niż jeden raz ;) ). Udział w tworzeniu czegoś takiego to poważniejsza sprawa niż zajęcia zapewne 99 % programistów w Polsce.
6
Poczytalibyście "Java Concurrency in Practice" a nie wypisujecie głupoty na forach internetowych.
3
Fakt, może jest trochę irytujący i zbyt pewny siebie. Nie wszystko co mówi ma sens i czasem mocno przesadza. Nie boi się jednak wypowiadać na tematy które inni pomijają szerokim łukiem. Generalnie nie chciałbym z nim pracować ze względu na jego osobowość, ale na jutrzejszą prezentację mam zamiar się wybrać, mimo że nie chodzę regularnie.
0
Jak byście mi nie napisali to bym w ogóle nie wiedział kto to jest ;-)
2
w sumie calkiem niedawno sie skusilam na przesluchanie prezentacji ktora na tym forum byla przytaczana dosc czesto :)
dosc mieszane uczucia mam, oczywiscie z paroma zdaniami trudno sie nie zgodzic, pare jest typowo subiektywnych, jeszcze inne to bzdury ale wszystko wypowiadane jako prawdy objawione. generalnie jest dosc irytujacy, antypatyczny i troche ma sie ochote mu z liscia dac za styl wypowiedzi 'kto to ja nie jestem i jak bardzo mam racje' ;)
10
Słuchałem jego prezentacji i zgadzam się z @katelx.
Para bzdur, które szczególnie mi utkwiły w pamięci:
-
"Poznasz dobrego programistę po tym jak używa IDE i że nie używa myszy". Nie. Po tym co najwyżej poznasz, czy ktoś klepie dużo kodu. Można znać wszystkie skróty w IDE i klepać beznadziejnie słaby kod. Można też nie znać wielu skrótów, bo 95% czasu spędza się na myśleniu i czytaniu kodu / dokumentacji, a nie pisaniu. Klepanie w klawisze to raczej mały ułamek czasu spędzanego w pracy. Poza tym, używanie myszki do pewnych zadań np. do przeglądania i nawigowania po kodzie (np. Ctrl+click) jest dużo wygodniejsze niż klawiatury i to czy komuś wygodniej używać tylko klawiatury, czy tylko myszy, czy na przemian, to już kwestia bardzo subiektywna.
-
"Każdy kod z wait i notify zawiera błąd". Teza oparta na założeniu, że każdy programista jest słaby. Założenie to oczywiście jest nieprawdziwe, bo istnieje cała masa kodu z wait i notify, który działa poprawnie (choćby we wnętrzu bibliotek JDK). Dobry programista wie, jakie zagrożenia może nieść taki kod i potrafi go odpowiednio zweryfikować. Drugi problem jest taki, że Pan Seliga nie proponuje tu zbytnio alternatywy. Wysokopoziomowe struktury z java.util.concurrent? Super, tylko one wcale nie są mniej niebezpieczne ani łatwiejsze w użyciu. Programowanie lockless / na atomicach? Wait/notify/synchronized to przy tym często bułka z masłem. Aktorzy / model reaktywny? Proste tylko w przykładach pokroju hello, w realnych systemach potrafią też być z tym niezłe jaja np. jak zgubisz komunikat, przyjdzie w złej kolejności albo wyślesz nie tam gdzie trzeba. Po prostu wymieniamy jedne zagrożenia na inne. Prawda jest taka, że jak mamy do czynienia ze współbieżnością, to wkraczamy na teren, gdzie żyją smoki i serio niewiele da się na to poradzić.
0
Krolik napisał(a):
Słuchałem jego prezentacji i zgadzam się z @katelx.
- "Każdy kod z wait i notify zawiera błąd". Teza oparta na założeniu, że każdy programista jest słaby. Założenie to oczywiście jest nieprawdziwe, bo istnieje cała masa kodu z wait i notify, który działa poprawnie (choćby we wnętrzu bibliotek JDK). Dobry programista wie, jakie zagrożenia może nieść taki kod i potrafi go odpowiednio zweryfikować. Drugi problem jest taki, że Pan Seliga nie proponuje tu zbytnio alternatywy. Wysokopoziomowe struktury z java.util.concurrent? Super, tylko one wcale nie są mniej niebezpieczne ani łatwiejsze w użyciu. Programowanie lockless / na atomicach? Wait/notify/synchronized to przy tym często bułka z masłem. Aktorzy / model reaktywny? Proste tylko w przykładach pokroju hello, w realnych systemach potrafią też być z tym niezłe jaja np. jak zgubisz komunikat, przyjdzie w złej kolejności albo wyślesz nie tam gdzie trzeba. Po prostu wymieniamy jedne zagrożenia na inne. Prawda jest taka, że jak mamy do czynienia ze współbieżnością, to wkraczamy na teren, gdzie żyją smoki i serio niewiele da się na to poradzić.
odnoście tego java.util.concurrent to jest to jednak wielki krok na przód - bo już nie musisz pisać tak podstawowego a jak bardzo złożonego w środku ConcurrentHashMap - tylko przykład. Wiele mechanizmów z tego package nadal jednak wymaga od nas wiedzy na temat JMM - np: happens before relationship czy visibility w tym modelu. Tutaj z pomocą przychodzi rxJava(tutaj race condition to nadal potencjalny wróg) która uwalnia od całej zabawy z executorami i callback hellem, akka tak samo, pozwala na tworzenie takich aplikacji przez zwykłych śmiertelników(np mnie) - już nie musisz znać internalów jvm(fuck yeah !)
"Każdy kod z wait i notify zawiera błąd". Teza oparta na założeniu, że każdy programista jest słaby.
Nie chodzi o założenie że każdy programista jest suaby, tylko chodzi o to że praca na takim poziomie jest po prostu bardziej error prone niż robienie tego samego za pomocą np: executorów czy rxjavay - jest zwyczajnie więcej rzeczy które można zyebać - ot wszystko. Wystawiając zwykłe restowe api jesteś w stanie się pomylić a co dopiero w takich przypadkach jak concurrency :D
Tak samo wymyślanie koła na nowo - po co pisać jakiś mechanizm który już ktoś wymyślił, przetestował i wystawił dla community ? Także jak jakiś agent(nie, nie taki z akki) pisze kolejny mechanizm do synchronizacji mając pod ręką Semaphor - przykre trochę.
jak zgubisz komunikat, przyjdzie w złej kolejności albo wyślesz nie tam gdzie trzeba
Jasne, ale Ty nie wymieniasz starych problemów na nowe(w przypadkach o których pisałeś), ale usuwasz część problemów. Bo przecież pisząc mechanizm dostarczania wiadomości od zera dalej musiałbyś się martwić o delivery, nie ? W momencie w którym korzystasz z np: Akki nie martwisz się o internale, ale bardziej skupiasz się na architekturze. I to jest spoko, chyba ?
#duzyofftop trza bylo mnie nie banowac
Odnośnie samego krula, to widać w tym trochę marketingu. A sam nie jest chyba przykładem osoby z jakimiś super zdolnościami interpersonalnymi :D
1
Nie demonizowałbym pana Seligi. To prawda, że jego prezentacja o zatrudnianiu programistów JAVA zawierała kilka kontrowersyjnych tez, jednak generalnie mówiła prawdę na temat wielu kandydatów, którzy szukają pracy w branży. Każdy kto miał okazję prowadzić rekrutacje, może mieć podobne wrażenia. Pan Seliga spłodził jakiś czas po tej sławnej prezentacji kolejną, gdzie nieco spuścił z tonu, bardziej obrazowo przedstawił swoje stanowisko oraz kontynuował temat. Polecam obejrzeć również tą drugą prezentację:
Btw. Temat można spokojnie przenieść do działu "kariera", ponieważ tematyka prezentacji pana Seligi ściśle dotyczy tej tematyki. Każdy powinien obejrzeć te prezentacje i wyciągnąć z nich coś dla siebie.
3
Nie chodzi o założenie że każdy programista jest suaby, tylko chodzi o to że praca na takim poziomie jest po prostu bardziej error prone niż robienie tego samego za pomocą np: executorów czy rxjavay - jest zwyczajnie więcej rzeczy które można zyebać - ot wszystko
Z tym się właśnie nie zgadzam. Serio w wielu przypadkach już tak miałem, że mogłem walnąć wszystko w jednego synchronized i miałbym kłopot z głowy; 100% gwarancji, że będzie działać prawidłowo. Rozwiązuję problem współbieżności przez wymuszenie jej braku. W przypadku executorów, rxjavy czy aktorów jest całe mnóstwo rzeczy, które można zepsuć i których nawet nie będzie na pierwszy rzut oka widać, że są zepsute. Choćby parę przykładów:
- kod, który do executora wrzuca więcej niż konsumuje
- wywoływanie Future#get (może blokować)
- wywołanie innego blokującego kodu w kontekście puli o ograniczonej liczbie wątków (np. wewnątrz aktora)
- poleganie na kolejności wykonania zadań przez executor
- oparcie kodu na założeniu, że executor jest jednowątkowy i omyłkowe użycie executora wielowątkowego
- rzucenie niewyłapanego wyjątku w kodzie wewnątrz Runnable
- poleganie na kolejności zdarzeń otrzymanych przez aktora
- wywołanie wspólnego kodu operującego na wspólnych danych (z efektami ubocznymi) z poziomu więcej niż jednego aktora
Mam wymieniać dalej?
Ostatnio piszę kod z użyciem async/await i kod faktycznie wygląda fajnie i prosto jak jest już napisany i przetestowany, ale liczba pułapek w tym modelu programowania jest olbrzymia i wcale nie mniejsza niż przy starym klasycznym synchronized/wait/notify.
Powodem odejścia od synchronized/wait/notify nie jest chęć ułatwienia programowania, a zwiększenie wydajności. Sprzęt działa asynchronicznie i blokowanie jest zabójcze dla wydajności.
0
Krolik napisał(a):
Ostatnio piszę kod z użyciem async/await i kod faktycznie wygląda fajnie i prosto jak jest już napisany i przetestowany, ale liczba pułapek w tym modelu programowania jest olbrzymia i wcale nie mniejsza niż przy starym klasycznym synchronized/wait/notify.
Powodem odejścia od synchronized/wait/notify nie jest chęć ułatwienia programowania, a zwiększenie wydajności.
Od początku do końca zgadzam się z tym zdaniem. Seliga w tej kwestii akurat nie ma racji.
1
Mnie zaciekawiła jedna rzecz. On tam chwali bibliotekę Guavę i uważa to za najważniejszą bibliotekę Javową (czy jakoś tak), i że każdy ją musi znać i używać a jak nie używa to nie jest profesjonalistą (on tak nie powiedział dokładnie tylko użył co prawda innych słów, ale mniej więcej w tym tonie).
Czy zgadzacie się z tym stanowiskiem? (tylko pytam, sam nie jestem programistą Javy, ale zastanowiło mnie tak silne uwielbienie do konkretnej biblioteki i chcę się dowiedzieć, czy inni niż Seliga programiści podzielają tę opinię).
0
LukeJL napisał(a):
Czy zgadzacie się z tym stanowiskiem?
Na chwilę gdy była kręcona tamta prezentacja Guava rzeczywiście była najnowocześniejszą i najlepszą opcją. Była pokryta imponującą ilością testów jednostkowych oraz była do 2011 roku rozwijana tylko przez Google. Z resztą Guava nadal solidnie się trzyma, znalazłem statystyki wg których jest używana w 15.6% topowych Javowych projektów na githubie.
http://blog.takipi.com/we-analyzed-60678-libraries-on-github-here-are-the-top-100/
5
Nie jestem Javowcem, ale prezentacja bardzo mi się podobała. Może dlatego, że nie biorę do siebie zdania jednej osoby i umiem sam przemyśleć to co usłyszę? Dużo rzeczy w tej prezentacji też specjalnie było przejaskrawionych żeby "dotarły". Wiele osób włącznie z Wujkiem Bobem stosuje takie praktyki :) Trzeba umieć myśleć za siebie i jak ktoś ma inne zdanie to nie brać tego do siebie.
0
Używam sporo Guavy, bo projekt Java 7.
Ale nie powiedziałbym, że ją wielce znam.
Jak potrzeba to chwila googla i lecę dalej.
0
Krolik napisał(a):
że mogłem walnąć wszystko w jednego synchronized i miałbym kłopot z głowy; 100%
Ale nie możesz tak zrobić :D badum tss ! nie po to się bijemy o każdy ms, łączymy parę requestów w jeden, tylko po to że potem gdzieś ktoś zrobić
synchronajzd(){
//a yebne se taki duzy
}
kod, który do executora wrzuca więcej niż konsumuje
wywoływanie Future#get (może blokować)
wywołanie innego blokującego kodu w kontekście puli o ograniczonej liczbie wątków (np. wewnątrz aktora)
poleganie na kolejności wykonania zadań przez executor
oparcie kodu na założeniu, że executor jest jednowątkowy i omyłkowe użycie executora wielowątkowego
rzucenie niewyłapanego wyjątku w kodzie wewnątrz Runnable
poleganie na kolejności zdarzeń otrzymanych przez aktora
wywołanie wspólnego kodu operującego na wspólnych danych (z efektami ubocznymi) z poziomu więcej niż jednego aktora
większość z tych problemów uświadczysz w środowisku wielowątkowym, a nie w technologia-specyfic, czy to akka czy rxjava, JMM jest wszędzie taki sam.
Powodem odejścia od synchronized/wait/notify nie jest chęć ułatwienia programowania, a zwiększenie wydajności. Sprzęt działa asynchronicznie i blokowanie jest zabójcze dla wydajności.
Jasne, wszystko ma być reaktywne i tak możemy uratować świat :D (nie, nie robie se jaj)
To weź mi jeszcze @Krolik wytłumacz, dlaczego netfix stworzył rxjave do wewnętrznych rozwiązań skoro mogli osiągąć lepsze efekty robiąc wszystko bez abstrakcji na podstawowe api ? w dodatku, według Ciebie, mogli to zrobić szybciej, lepiej i w ogóle bardziej kolorowo ?
2
@Krolik
wywoływanie Future#get (może blokować) -> jest CompletableFuture z możliwością zarejestrowania eventa jak się policzy ;)
Ja się tak generalnie z Seligą zgadzam w wielu punktach, szczególnie w tych na które pewnie początkujacy biadolą że czego to on nie wymaga. Ale to wynika z tego, że początkujacym często sie wydaje że dużo wiedzą, bo nie wiedzą jak dużo nie wiedzą :D
Z tym wait i notify to jest kwestia trochę innego poziomu abstrakcji. Żeby zrobić coś podobnego do java.util.concurrent musimy napisać tonę kodu z wait i notify i napisanie tego bez błędów zajmie bardzo dużo czasu albo będzie zbugowane. I pod tym względem raczej sie tego unika, chyba że ktoś klepie jakieś big data czy htf i te cykle stracone na synchronizacji na wyrost go bolą. Ale wiadomo że optymalizuje się kiedy jest taka potrzeba a nie na wyrost :)
7
Zdaje się, że Seliga szefuje firmie, za pracę w której 80% Javowych juniorów z tego kraju oddałoby trzy nerki i dwie wątroby. Z ofert wynika też, że juniorom pracą tyle, ile midom, a od seniorów wymagają 12 lat doświadczenia - co jest miłą odmianą dla panujących w naszym kraju patologii w postaci seniorów z dwuletnim stażem.
Ma prawo mieć wymagania jakie ma, i mówić o nich. A, że to nie są wymagania reprezentatywne dla wszystkich firm - tego już każdy zainteresowany powinien się domyśleć.
2
Z tym wait i notify to jest kwestia trochę innego poziomu abstrakcji. Żeby zrobić coś podobnego do java.util.concurrent musimy napisać tonę kodu z wait i notify i napisanie tego bez błędów zajmie bardzo dużo czasu albo będzie zbugowane. I pod tym względem raczej sie tego unika, chyba że ktoś klepie jakieś big data czy htf i te cykle stracone na synchronizacji na wyrost go bolą. Ale wiadomo że optymalizuje się kiedy jest taka potrzeba a nie na wyrost :)
Zgoda. Tylko że na innym poziomie abstrakcji rozwiązuje się inne problemy. A Seliga trochę to przedstawiał w sposób - jeśli piszesz kod z wait/notify, to na pewno masz tam błąd, używasz złego narzędzia i jesteś słabym programistą. Pokaż mi złożony system rozproszony, w którym nie ma synchronized/wait/notify, a są za to różne "nowoczesne" zabawki jak Executor, RxJava, ListenableFuture, ConcurrentHashMap, aktorzy, async/await (to akurat już niestety nie w Javie; a jedynie w C# / Scala), a jest wielce prawdopodobne, że też się znajdą jakieś błędy wielowątkowe, a udowadnianie poprawności takiego systemu jest również bardzo trudne i wcale nie jestem przekonany czy łatwiejsze niż analizowanie kodu niskopoziomowego. I paradoksalnie zastosowanie np. ConcurrentHashMap* poza ścieżką krytyczną, gdzie wystarczyłoby wpakować coś w jedną sekcję synchronized bywa bardziej skomplikowane i bardziej błędogenne niż ten jeden paskudny synchronized. Podobnie synchronized jest generalnie nieco bezpieczniejsze niż ReentrantLock z java.util.concurrent, czy zabezpieczenie jakichś współdzielonych danych mutowalnych będzie bezpieczniejsze przez synchronized, niż przerobienie tego na lockless z użyciem atomiców (też java.util.concurrent).
Z drugiej strony nikt rozsądny nie używa chyba wait/notify to budowania skomplikowanych systemów, tak jak nie pisze się systemu ERP w assemblerze. Bo to nie ten poziom abstrakcji, jak słusznie piszesz. Dobry programista zna różne narzędzia i stosuje odpowiednio do sytuacji. Myślę, że, gdyby tak to Seliga przedstawił, to nie byłoby żadnych kontrowersji. A niestety wygląda to trochę tak, jakby dopiero co przeczytał tę Java Concurrency in Practice...
- Notabene ConcurrentHashMap używa blokad pod spodem i można się wpakować w równie wielke bagno wydajnościowe co przy nadużywaniu synchronized... Cliff Click pokazał gdzieś kiedyś, że można napisać znacznie lepszy CHM. Używając tych wysokopoziomowych zabawek i tak trzeba rozumieć jak są zrobione pod spodem.
To weź mi jeszcze @Krolik wytłumacz, dlaczego netfix stworzył rxjave do wewnętrznych rozwiązań skoro mogli osiągąć lepsze efekty robiąc wszystko bez abstrakcji na podstawowe api ?
Ale czy ja gdzieś piszę, że abstrakcje są złe? Próbowałeś pisać kiedyś kod asynchroniczny na gołych Future'ach (jeszcze najlepiej bez Guavy)? Synchronized/wait/notify to jest przy tym kaszka z mleczkiem. Serio. Istnieją różne abstrakcje, które mają różne wady / zalety i różne zastosowania. Zresztą synchronized/wait/notify to już też jest pewna abstrakcja i wyższy poziom niż np. gołe blokady czy operacje atomowe. Ja się wcale nie dziwię, że Netflix sobie coś takiego zbudował, ale nie oznacza to przecież, że automatycznie każdy projekt musi tego używać.
synchronajzd(){
//a yebne se taki duzy
}
Jeżeli przez 99,99% czasu będzie i tak wywoływany przez jeden wątek, a umieszczony został tylko po to aby ochronić dane w jakiejś wyjątkowej, mało prawdopodobnej sytuacji, to koszt będzie znikomy. Właściwie poza obsługą tej brzegowej sytuacji koszt może być nawet dokładnie 0, tj. tego synchronized nie będzie ostatecznie w kodzie maszynowym, bo JVM ma supermoce i potrafi robić synchronized bez synchronized... :P
0
Krolik napisał(a):
okaż mi złożony system rozproszony, w którym nie ma synchronized/wait/notify, a są za to różne "nowoczesne" zabawki jak Executor, RxJava, ListenableFuture, ConcurrentHashMap, aktorzy, async/await (to akurat już niestety nie w Javie; a jedynie w C# / Scala),
To ja powinienem napisać, żebyś mi pokazał taki system napisanym na gołym api jdk < 1.5 . To jest nie możliwe, a jeżeli ktoś się tego podjął, to polecam wyyebac architekta. Jeżeli to co piszesz jest prawdą.. Java Concurrency in Practice ? a wyyebac mozna, java.util.concurrency ? wyyebac mozna.
Tworzenie aplikacji nie używając jakichś frameworków zawsze będzie prowadzić do tworzenia chociażby wewnętrznych rozwiązać (libow, frameworkow).
Szczególnie, w przypadku wspomnianych systemow rozproszonych - co z circuit breakerem, co w każdym kliencie będziesz robił osobno ? nie zrobisz jak najbardziej generyczne rozwiązanie zaimplementujesz niżej ! hmm,to może jakieś metryki, dla każdego klienta osobno ? nie, zrobisz generyczne wsadzisz niżej. Tak samo z rozwiązaniami w środowisku wielowątkowym - z tym że tutaj po prostu gorzej, bo najpierw powinno działać, potem dopiero powinno być generyczne.
Także napisze to jeszcze raz, ** nie jest możliwe napisanie dużej aplikacji (nie pisze już nawet o czymś bardziej skomplikowanym) która nie będzie budowana na coraz to bardziej generycznych blokach/rozwiązaniach** . O blokach mam na myśli, rozwiązania które naturalnie zamieniają się w utilsy, takie jak np: semaphore , cyclic barrier czy latche - już nawet nie pisze o takich podstawowych elementach jak concurrenthashmap . I takie wewnętrzne liby/frameworki potem ewoluują w rxjave, akke czy μjavaactors
1
W ostatni wtorek na WJUGU był pan Wojciech Seliga z tematem 5-10-15 lat w karierze developera. Nie wiem czy było nagrywane i czy było w internecie, ale powiem moje odczucie.
Po pierwsze, prowadzący nie był już tym samym aroganckim dupkiem którego pamiętamy z pierwszej prezentacji confitury. Bardzo stonował i nie lekceważył ludzi.
Pierwsze co można było wyciągnąć z tej prezentacji to fakt że ta pierwsza o podstawach java developera, to tak naprawdę dobry technicznie mid. Wygląda na to że o chodziło jednak o zmotywowanie młodych do nauki, co może mieć sens patrząc z obecnego punktu widzenia jak mnożą się tematy "Otwożyłem dzisiaj książkę do javy, kiedy mogę iść do pracy i kiedy dostanę pozycję seniora?".
Ale jej cel był inny. Uświadamiał że developer to nie tylko skille techniczne i nowe frameworki, ale przedewszyskim skille miękkie. Postrzeganie całości projektu, dążeniu do jego ukończenia itd. Bardzo motywujące.
0
Widzisz, muszę sobie obejrzeć jakąś nowszą prezentację. Skoro Pan Wojciech ewoluuje to może będę musiał dokonać rewizji swojej opinii.
2
To ja powinienem napisać, żebyś mi pokazał taki system napisanym na gołym api jdk < 1.5 . To jest nie możliwe, a jeżeli ktoś się tego podjął, to polecam wyyebac architekta. Jeżeli to co piszesz jest prawdą.. Java Concurrency in Practice ? a wyyebac mozna, java.util.concurrency ? wyyebac mozna.
Mam dziwne wrażenie, że chyba jednak nie zrozumiałeś nic z tego, co ja napisałem.
Ja nigdzie nie argumentuję przeciw używaniu java.util.concurrent. Ba, ja nawet nie pamiętam kiedy ostatnio użyłem synchronized w kodzie.
Polemizuję tylko ze stwierdzeniem Seligi, że jak ktoś pisze kod używając wait/notify, to na pewno ma tam błąd.
Jeśli tak jest, to tym bardziej będzie miał błąd używając np. aktorów, atomiców, współprogramów (coroutines), reentrant locków czy współbieżnych HashMap, bo one wcale nie są łatwiejsze, a część z tych mechanizmów jest niżej-poziomowa niż wait/notify. Wait/notify to już jest pewna abstrakcja.
Bardzo ostatnio modny model programowania oparty na asynchronicznym przekazywaniu komunikatów (np. C# async/await, Akka actors, Goroutines, model współbieżności stosowany w Erlangu) jest dualny w stosunku do programowania blokującego z wait/notify i nie jest ani łatwiejszy, ani trudniejszy - występują w nim dokładnie te same problemy, co w klasycznym programowaniu wielowątkowym; ba a nawet da się formalnie przekształcić program z jednego modelu w drugi. Async/await nawet takie przekształcenie oferuje - piszesz kod jak blokujący, a pod spodem jest nieblokujący.
Po pierwsze, prowadzący nie był już tym samym aroganckim dupkiem którego pamiętamy z pierwszej prezentacji confitury. Bardzo stonował i nie lekceważył ludzi.
Zgadzam się. Było znacznie lepiej. Choć nadal momentami używał angielskich wtrąceń, co mnie osobiści drażni.
Natomiast trochę zaprzeczył sam sobie, twierdząc, że nie rozumie implicitów Scali na podstawie jakiegoś projektu, który zapewne był napisany zwyczajnie słabo (skoro było tam 10 poziomów zagnieżdżenia flatMap i jeszcze jakieś nulle latały). Z kolei wcześniej twierdził, że jak widzi jakiś dziwny kod, to stara się zrozumieć, dlaczego tak został napisany. No a w przypadku implicitów się nie postarał... Dlatego wyszedł z niego taki trochę "Blub programmer". Z migracją 2.10 na 2.11 to też jakieś bajeczki są, bo język jest w 100% kompatybilny wstecznie. Gdybym nie zarządzał dużym projektem, który kompiluje się równocześnie i do 2.10 i 2.11 z tych samych źródeł, to może bym mu uwierzył ;)
Ten jego argument o niby wyższości Javy, wynikającej z tego, że można dać dowolny kod Javy juniorowi i zrozumie o co chodzi, też jest bardzo słaby. W Javie można napisać bardzo nieczytelny kod - polecam źródła Hadoopa. O... i tam jest bardzo dużo wait/notify :P Z Javą jest trochę jak z asemblerem - pojedyncze instrukcje są proste i niby widać wprost co kod robi, ale zrozumieć całość, patrząc na te proste instrukcje, wcale nie zawsze jest łatwo.
0
Krolik napisał(a):
Polemizuję tylko ze stwierdzeniem Seligi, że jak ktoś pisze kod używając wait/notify, to na pewno ma tam błąd.
Jeśli tak jest, to tym bardziej będzie miał błąd używając np. aktorów, atomiców, współprogramów (coroutines), reentrant locków czy współbieżnych HashMap, bo one wcale nie są łatwiejsze, a część z tych mechanizmów jest niżej-poziomowa niż wait/notify. Wait/notify to już jest pewna abstrakcja.
- o prawie bym nie zauważył tej odpowiedzi :D tak to jest jak się pisze z kilku kont DDDD:D
Tu nie ma z czym polemizować bo to stwierdzenie jest po prostu głupie. Ja też nie uważam że ten człowiek miał racje w któreś z kwestii które poruszył - jedynie użył sporej ilość buzz wordów które warto znać.
Nadal uważam jednak że pisanie opierając się o istniejące mechanizmy jest łatwiejsze i bezpieczniejsze, sam fakt że community przetestowało.
0
Tu chyba jest to wystapienie o ktorym @Krolik mowi - moze momentami przesadza, ale generalnie z nim sie zgadzam, widac u niego ten przeskok w mysleniu pomiedzy poziomami o ktorym mowi.
0
WhiteLightning napisał(a):
Tu chyba jest to wystapienie o ktorym @Krolik mowi -
Nie, to już jest "ugładzony" Seliga, jak chcesz zobaczyć o czym pisał @Krolik to spójrz tu:
Poza tym te video, które dałeś zostało nagrane po wypowiedzi @Krolik więc nie mógł o nim mówić.