Leciwe cechy Javy [Dyskusja]

Jak dla mnie platforma NET straciła swoją siłę i zalety wraz z końcem aplikacji desktopowych. W WinFormsach pracuje się genialnie, w WPF też nieźle, ale już w webowym ASP MVC już średnio - jakoś mi to nie podeszło zupełnie, choć na pewno znajdą się zwolennicy klepania stron w ASP MVC. Jedyne co się może podobać w platformie NET to IMO XAMARIN, ale czy się przyjmie to też trudno powiedzieć (jeszcze trochę mu brakuje do stabilnej, pewnej pracy). Samo Visual Studio też jest świetnym IDE (to IMO najlepszy produkt Microsoftu), ale co z tego, dobre IDE to za mało.

Ty trollujesz prawda?

Mi jako programiście Javy nie przeszkadza pisanie w tego boilerplejtu i posiadania dyskusyjnie gorszej składni dopóki pisze się w niej ciekawe projekty :) A najmocniejszym punktem javy i tak jest jej ekosystem, a nie sam język.

Jednej i drugiej grupie skrajnych zwolenników i przeciwników chyba troszeczkę w główkach się poprzewracało.

Boilerplate i Java?
Hmm czegoś takiego nie zauważyłem

• obecność nulli
• sztucznie dodane programowanie funkcyjne (ale i tak dobrze, że jest)
• checked exceptions, w szczególności przeszkadza jak trzeba je łapać gdzieś w lambdach
• brak akcesorów których wymaga np. jsf czy jpa/hibernate (chociaż tu akurat jest takie coś jak @Access(AccessType.FIELD) )
• czekam na Valhalle

• @Mały Kot te nulle to trochę jak goto w C++. Jest bo jest, ale to nie znaczy że należy korzystać skoro jest tez Optional a pewnie kiedyśtam będzie Either.
• Nie wiem co jest tam sztucznego, szczególnie że Guava już dawno temu dawała podobne możliwości i od dawna można było tak pisać.
• W wielu sytuacjach na te wyjątki w lambdach moze zaradzić:

@FunctionalInterface
public interface CheckedFunction<T,S,E>{
    T apply(S arg) throws E;
}

Bo wtedy w swoich metodach przyjmujesz taki CheckedFunction zamiast Function i już nic nie trzeba łapać przy definicji lambdy.

Dlaczego nulle to takie zło?

Bo bardzo łatwo o NullPointerException. Jakakolwiek (no dobra, może przesadzam) metoda by zaznaczyć, że referencja może być pusta jest dobra. W Scali od zawsze jest Option. W Javie doszło niedawno Optional. W Kotlinie są typy z pytajnikiem.

@scibi92 pisałem o tym juz gdzieś -> bo nulle są niewidzialne. Zwrócenie nulla to największy hardkor jaki mozesz zrobić. Rzucenie checked exception widać. Zwrócenie optionala czy either widać. I musisz to jakoś obsłużyć - musisz się zastanowić co się ma stać kiedy gdzieś coś poszło nie tak. Zwrócenia nulla nie widać a często musiałbyś długo kopać w kodzie żeby dojść do miejsca z którego go ktoś faktycznie zwrócił. W efekcie często w kodzie nikt nie bierze pod uwagę że cos może być nullem i taki obiekt sobie lata aż nie wywali NPE i potem siedzisz i debugujesz szukając skąd to się wzięło.

Shalom napisał(a):

. W efekcie często w kodzie nikt nie bierze pod uwagę że cos może być nullem i taki obiekt sobie lata aż nie wywali NPE i potem siedzisz i debugujesz szukając skąd to się wzięło.

Jest jeszcze jeden gorszy poziom niż tylko rzucenie nulla - przekazanie nulla dalej.

Właściwie nie wiem ile razy widziałem w kodzie taki patent - obsługa Nulla "like a boss"

public UserSettings getUserSettings(User user) {
    if ( user == null) {
       return null;
    } 
..... 
}

Najbardziej lubię jak taki kod ktoś dopisuje "potem" z komentarzem - obsługa nulla.

Chciałem napisać plugin do mavena, który po wykryciu takiego kodu od razu formatuje dysk. To powinien być obowiązkowy plugin - nawet na CI.

Mi po doświadczeniach ze Scalą najbardziej brakuje:

• inferencji typów
• struktury danych immutable (Vector, List, itp)
• case class i pattern matching (wiem że jest JavaSlang ale strasznie topornie to wygląda)
• system makr / metaprogramowania

Jakby jeszcze zostały dodane typy wyższego rzędu to dałoby się uprawiać jakieś sensowne programowanie funkcyjne.

adwy napisał(a):

Mi po doświadczeniach ze Scalą najbardziej brakuje:

• inferencji typów
• struktury danych immutable (Vector, List, itp)
• case class i pattern matching (wiem że jest JavaSlang ale strasznie topornie to wygląda)
• system makr / metaprogramowania

Wygląda na to, że wielu brakuje i zamierzają to wprowadzić (poza makrami - tu mi krótko odpowiedział Mark Reinhold - myślą nad alternatywami (method handlers etc) ).
Wczoraj na Devoxxie w Antwerpii Brian Goetz miał interesującą prezentację na temat przyszłości Javy:

Ogólnie to ciekawe wyjasnienie - nie dodają do Javy za szybko nowych rzeczy bo chcą zobaczyć co się przyjmie i czego ludziom brakuje. Bo dodać coś jest łatwiej - niż potem usunąć (see null - Scala w zasadzie ma go nadal, albo cholerne '==' w JavaSkrypcie. Wiadomo, że kiepskie ale teraz to już trudno usunąć). Całkiem to rozumiem...

ALE

Z takim podejściem jest niestety problem - poczekamy sobie do Javy 10 albo 11 (czyli 2021?). Poczekamy na rzeczy, które już dziś wiadomo, że są dobre i zaakceptowane przez twórców Javy!

W tym momencie rozumiem, że jak mam taki sobie zespół Javowców i dłuższy projekt - to zaciskam zęby i jade w Javie. I będe rypał te equalsy, gettery, settery jeszcze przez następne 5 lat....

5 lat.... a możliwe, że za pięć lat pisanie kodu przez ludzi bedzie już tylko dyscypliną sportową.

Jeśli więc tylko jest jakaś szansa (niekrytyczny podprojekt, mały zgany zespół, projekty domowe) - to po co się męczyć - można sobie troszkę poszaleć. I to już.
Jest Scala, jest Kotlin, Rust, jest Haskell/Frege. Polecam - wyjście z grajdołka Javowego - z pewnością trochę odświeża. Potem sie wraca do Javy i pisze zupełnie inaczej (chociaż ile razy pisze buildera to płaczę :-( ).

A jak ktoś nie zna w ogóle Javy, to może zaczynać od Scala lub Kotlin ?