Wpis z mikrobloga

@SaintWykopek: bo w porównaniu z językami takimi jak Rust albo Scala, Java to muzeum.

I nie, nie jest wcale "bardzo przyjemnym językiem":
* int vs Integer
* wymazywanie typów generycznych
* dziedziczenie
* null
* static
* brak przeciążania operatorów np. dla BigDecimal
* brak typów unsigned
* wyjątki checked niedziałające dobrze z programowaniem funkcyjnym
* brak dobrego rozwiązania sprzątania zasobów niepamięciowych
* brak systemu makr, metaprogramming czasu kompilacji leży
*
@Krolik: dobrze, że ludzie mają #!$%@? w takie wysrywy, gdyby tak było Java by się nie rozwijała, a wygląda że będzie się rozwijać jeszcze przez długie lata, liczba projektów w Javie rośnie a według tego powinna maleć bo język jest taki mega nieprzyjemny. Pewnie sojowych devów boli że nikt nie chce projektować w ich uber fajnym języku :D
@eovenn: obecny rozwój Javy to raczej pudrowanie świni poprzez dodawanie lukru składniowego, natomiast fundamentalnych błędów projektowych nie da się naprawić ze względu na kompatybilność wsteczną. A z tymi nowymi projektami to nie wiem skąd to wziąłeś, ale np. taki Amazon w AWS coraz mniej rzeczy robi w Javie a coraz więcej w Rust, z kolei Google też stopniowo zastępuje Javę przez Golang, Kotlin, Flutter i inne. To w czym dzisiaj piszą
@SaintWykopek: Bo Java jest językiem a właściwie środowiskiem które dostarcza.
Tu chodzi o gotowy produkt i działający system, a nie o użeranie się z każdym elementem i wymyślanie koła od nowa.
A programiści uwielbiają skupiać się na bzdurach i pisaniu po raz milionowy tego samego.
Stad sukces np Go czy nowych języków - wszystko trzeba klepać od nowa.
Bo Java jest językiem a właściwie środowiskiem które dostarcza.


@yhbgrobdoivbvwamsv: Tak super dostarcza, że łącznie w firmie spędziłem pewnie dobrych parę miesięcy na wyłącznie szukaniu i poprawianiu błędów związanych z:
- wyścigami pomiędzy wątkami
- nieprawidłowym zwalnianiem zasobów (sockety, pliki, wątki, bufory pamięci itp.)
- null pointerami
- niewłaściwą kolejnością inicjalizacji statycznej
- przekombinowniem kodu przez architektów astronautów OOP
- problemami wydajnościowymi nieistniejącymi w innych językach, w tym pauzami GC
-
@Krolik: Połowa problemów opisanych to błędy programisty.
Jedynie konflikt bibliotek to faktycznie problem typowo javowy aczkolwiek w najnowszych wersjach sporo się poprawiło.

Przy czym masz miliard narzędzi żeby te wszystkie problemy rozwiązywać, od łatwego debugowania poprzez flight recorder, tony narzędzi do integracji i analizy.
W projekcie żyjącym dłużej niż miesiąc zdecydowanie bardziej ułatwia to życie niż lepsza składnia
Połowa problemów opisanych to błędy programisty...


@yhbgrobdoivbvwamsv: ... których nie da się normalnie popełnić np. w Rust

Przy czym masz miliard narzędzi żeby te wszystkie problemy rozwiązywać, od łatwego debugowania poprzez flight recorder, tony narzędzi do integracji i analizy.


Czyli jak w socjalizmie bohatersko walczymy z problemami nieznanymi w innych systemach.

W projekcie żyjącym dłużej niż miesiąc zdecydowanie bardziej ułatwia to życie niż lepsza składnia


3 tygodnie debugowania wyścigu zamiast błędu
Połowa problemów opisanych to błędy programisty...


@yhbgrobdoivbvwamsv: ... których nie da się normalnie popełnić np. w Rust

Przy czym masz miliard narzędzi żeby te wszystkie problemy rozwiązywać, od łatwego debugowania poprzez flight recorder, tony narzędzi do integracji i analizy.

Czyli jak w socjalizmie bohatersko walczymy z problemami nieznanymi w innych systemach.

W projekcie żyjącym dłużej niż miesiąc zdecydowanie bardziej ułatwia to życie niż lepsza składnia

3 tygodnie debugowania wyścigu zamiast błędu
A ruscie nie da się złe zamknąć pliku, ciekawa teoria.


@yhbgrobdoivbvwamsv: Normalnie się nie da. Da się dopiero jak napiszesz kompilatorowi ładnie "jestem debeściakiem i wiem lepiej niż Ty że chcę zamknąć używany plik i skraszować program kilka linii dalej", ale najprawdopodobniej to nie przejdzie przez code review, bo recenzentowi to się będzie świecić w kodzie na czerwono.

let file = File::open("plik.txt")?;
drop(file);
writeln!(file, "dane"); // <<<< błąd kompilacji

Jak mowie
@Krolik:

Błędy w logice nie są dużo częstsze. Akurat logika biznesowa najczęściej jest prosta jak konstrukcja cepa. To co się sypie w realnych systemach to właśnie te technikalia że ktoś zapomniał sprawdzić nulla albo zamknąć pliku.


No to spodziewam się teraz, że padnie tutaj jakiś co najmniej półnaukowy dowód (zważywszy na to, kto to napisał), że błędy w logice nie są częstsze, albo, że logika biznesowa jest "prosta". Czegoś nowego się
@Krolik: Oczywiście, ze są xD dlatego mowie ciagle o dużych systemach które żyją więcej niż pare tygodni.

Mam wrażenie ze rozmawiam z juniorem który uważa ze w tej branży wszystko jest proste - input -> output i koniec, nie ma miliarda przypadków w połowie sprzecznych, niepoprawnych zbiorów danych i integracji z systemami które typy danych traktuj jak sugestie.
Czy moje ulubione - kod który co nie powinien przejść review jak w
Oczywiście, ze są xD dlatego mowie ciagle o dużych systemach które żyją więcej niż pare tygodni.


@yhbgrobdoivbvwamsv: A ja piszę o hello world, które napisałem wczoraj:

Tu masz repo: https://github.com/apache/cassandra
A tu masz bugtracker: https://issues.apache.org/jira/projects/CASSANDRA/issues/

Na oko dobre 80% bugów nie byłoby możliwych, gdyby używać silniejszego języka niż Java.

że błędy w logice nie są częstsze, albo, że logika biznesowa jest "prosta".


Z punktu widzenia kodu, błędy w logice są takimni