Co w Javie jest trudne

Cześć,

niedawno szczęśliwie znalazłem pracę i zostałem wrzucony w projet bigdata w którym zacząłem klepać w Javie - wcześniej mając z nią zerową styczność.

Projekt jest nowy (start up) i widzę po jego objętości, że dałbym radę go sam w całości przepisać i chyba to zrobię aby poznać każdy jego szczegół i zobaczyć jak się tworzy komercyjne produkty od pierwszej linijki kodu aż do pozyskania klienta.
Mimo iż w Javie wcześniej nic nie robiłem to znośnie daje radę ale bardzo bym chciał się w niej dalej rozwjać - dlatego chciałbym zapytać Was, co w javie wydaje się być na prawdę trudne? Póki co miałem pewne problemy z typami generycznymi, w pythonie czegoś takiego nie ma/nie używałem i był to spory przeskok, natomiast i z tym jakoś idzie. Co waszym zdaniem jest w Javie na prawdę trudne do ogarnięcia?

Pozdrawiam serdecznie :)

IMO to co w każdym języku programowania - wielowątkowość, wydajność, clean code

Programisci Javy z ktorymi trzeba pracowac. .

MateInf napisał(a):

w pythonie czegoś takiego nie ma/nie używałem i był to spory przeskok

Przyznam się jestem w pozycji nieco zdzwionej ...
Nie byłeś w kontakcie również z C++ i C#, bo jakie inne kompilowane (typowane) języki obiektowe się nasuwają ?

Python, jako język dynamiczny, to dość daleko ... nie chciałbym być złym prorokiem, ale jeszcze nieraz kopnie przez różnice
A po drugie że "z klamerkami" vs "z tabulatorami" ...

w Big Data ( w rozumieniu przetwarzania danych) to raczej w tej javie koduje się niż programuje...
w kodowaniu w Javie jedyne co jest trudne to wielowątkowość.

jak checsz robić w Big Data, ale nie w legacy, to raczej bym szedł w kierunku pythona.
ofert java + bigdata - hadoop jest jak na lekarstwo... to nie jest wygodny język do takich rzeczy... java to jest patogus język do pisania wielkich połaci korporacyjnych aplikacji na 500k linii kodu, wielkich jak ziemie polsko lietuvių w wieku 15.

O_o

Projekt jest nowy (start up) i widzę po jego objętości, że dałbym radę go sam w całości przepisać i chyba to zrobię aby poznać każdy jego szczegół i zobaczyć jak się tworzy komercyjne produkty od pierwszej linijki kodu aż do pozyskania klienta.

Raczej przepisanie aplikacji nie pomoże Ci w zrozumieniu, w jaki sposób wprowadzić produkt na rynek. Zainteresuj się product managementem i podejściem lean. Samo zakodowanie to realizacja jakiegoś konceptu, który zapewne chcecie dopiero zwalidować. Java to tutaj może z 1% układanki.

chciałbym zapytać Was, co w javie wydaje się być na prawdę trudne? Póki co miałem pewne problemy z typami generycznymi, w pythonie czegoś takiego nie ma/nie używałem i był to spory przeskok, natomiast i z tym jakoś idzie. Co waszym zdaniem jest w Javie na prawdę trudne do ogarnięcia?

Piszesz o ficzerach języka, a jeszcze jest cały ekosystem dookoła - JVM, biblioteki, frameworki, narzędzia, runtime, integracje, …

W samej Javie najtrudniejsze może być nauczyć się, z czego korzysta się 90% czasu, a z których bajerow nie korzystać - tak rzucam z czapy, chociaż jak usiłowałem przekazać - to jest tylko jakaś kropla :) Bardziej bym się skłaniał w kierunku analizy problemów produkcyjnych, ale to już nie jest tylko na poziomie języka.

Nie ma w niej nic trudnego jeżeli mowa o języku. Wydajność, wielowątkowość i reszta rzeczy, które tutaj są wymieniane są trudne w każdym języku. Pułapki są wyżej - jak poukładać kod w klasy, klasy w moduły, żeby ktoś mógł w to zajrzeć i poprawić jakiś błąd.
W dostarczeniu oprogramowania do użytkownika "kodowanie" jest najmniej problematyczne.

MateInf napisał(a):

Póki co miałem pewne problemy z typami generycznymi, w pythonie czegoś takiego nie ma/nie używałem

Nie, no chyba przeciwnie -- w Pythonie wszystkie funkcje są generyczne... :)

Charles_Ray napisał(a):

Raczej przepisanie aplikacji nie pomoże Ci w zrozumieniu, w jaki sposób wprowadzić produkt na rynek.

Nie znając docelowego ekosystemu nic a nic, nie pomoze w niczym, ani produktowo, ani programowanie, o projektowaniu nie śnię nawet.

Nawet jeśli odwzoruje 1:1 z jednego języka do drugiego, to będzie jak tłumaczenie języka naturalnego translatorem.

Pisalem w java, teraz node/python. Co java trzyma za mordkę to trzyma, bo potwory w JS maja o wiele wiecej p.atku i health'a niz w Javie.

https://docs.oracle.com/javase/specs/jls/se17/html/jls-17.html#jls-17.4

A Java to właśnie taka nie miała być? Izi dla ludzi co przechodzą z innego języka(najlepiej OP/OOP), żeby nie tracić czas na zastanawianie się nad jakimiś zawiłościami?

Czitels napisał(a):

A Java to właśnie taka nie miała być? Izi dla ludzi co przechodzą z innego języka(najlepiej OP/OOP), żeby nie tracić czas na zastanawianie się nad jakimiś zawiłościami?

Dokładnie tak miało być. Java miała być na tyle prosta żeby każdy programista COBOLa był w stanie ją zrozumieć. A COBOL miał być na tyle prosty żeby każdy mógł programować. Tylko że to było 15 lat temu. Gdzieś tam od po drodze w Javie 6 dodano piekło magicznych adnotacji, a w Javie 8 dodano szczątki programowania funkcyjnego, które są rozbudowywane do dziś. Ale jak czytam tu opisy problemów w C# czy C++ to nie rozumiem połowy rzeczy :D myślę że to wynika właśnie z tego że dalej Java jest dużo prostsza niż C# czy C++

BTW chciałbym coś merytorycznego napisać żeby ten wpis nie poleciał za offtop, ale jest mi trudno znaleźć taką rzecz co w Javie jest trudna i nie została jeszcze wymieniona. A wymieniono już:

• Statyczne typowanie i generyki - ale to problem wszystkich statycznie typowanych języków programowania z generykami
• Programowanie asynchroniczne. Jedne języki robią to lepiej inne gorzej. Java raczej robi to gorzej, ale jak się uzyje Akkę czy ogarnie się strasznie pokomplikowane CompletableFuture to można przywyknąć
• programiści Javy uwielbiający magiczne adnotacje i @PostConstruct . Największy rak tego języka, jeśli nawet nie największy rak programowania w ogóle
• od siebie mogę dodać to że Java jest strasznie rozwlekła (co wynika z jej chęci bycia prostą). Trudność czytania dużych projektów przez to jest duża. Jest to drugi główny powód czemu zrezygnowałem z Javy (pierwszym jest @PostConstruct)

No miała być prosta, a teraz wjezdza Project Loom( i ogarniaj różnice, wątki systemowe i wirtualne, structured concurrency itp) project Valhalla(z tymi value classami itp), pattern matching z Sealed Class itp
No i jednak nie jest taka prosta xD

• Maven przy duzej skali projektu, dziwnych zaleznosciach, zewnetrznych repo na artefakty itp.
• microbenchmarking + performance
• tuning GC
• wielowatkowosc
• czytanie kodu z adnotacjami ktorych nie znamy
• to co chyba w kazdym jezyku -> dobre zaprojektowanie architektury/systemu

Dziekuje za merytoryczne odpowiedzi. Czyli de facto, cała rozbudowana otoczka dookoła javy zaczyna być prawdziwym problemem do ogarnięcia a nie sama java(poza niektórymi wyjątkami o których wspomnieliście typu. wielowątkowość, GC..).

Natomiast szkoda mi tych, którzy wchodzą do tego tematu tylko aby nawrzucać syfu na programistów javy bądź jave samą w sobie :P.
Poczytajcie książkę albo pójdźcie na spacer, a jak już nie możecie się powstrzymać to załóżcie sobie osobny wątek do tego, bowiem to nie było tematem mojego pytania :)

@MateInf: Java jest prostym językiem. Tak została zaprojektowana. Owszem później weszło trochę komplikacji, ale większość z nich była również z myślą o uproszczeniu pewnych aspektów. To co jest skomplikowane, w 90% przypadków nie jest używane.
Druga strona medalu wygląda tak, że z prostoty, czy łatwości języka nie wynika w żadnym razie, że tworzenie oprogramowania jest łatwe i proste. Czym innym jest rozwiązanie hipotetycznego, szkolnego problemu typu "znajdź najwyższy wspólny dzielnik 2 liczb naturalnych", czy rozmieszczenie na szachownicy 8 hetmanów bez konfliktów, a czym innym napisanie durnej księgi gości, która działa, da się rozwijać, jest wydajna, da się w niej łatwo znaleźć błąd zgłoszony przez użytkownika i go poprawić.
Nie do końca rozumiem cel jaki chcesz osiągnąć, ale polecałbym zastanowić się nad nauką innych języków opartych o JVM np. Kotlin - możliwości te same, największe bóle Java albo poprawione, albo chociaż przypudrowane. Przy okazji nie spędzisz połowy czasu na generowanie i czytanie kodu, który nic nie wnosi do działania projektu.

Nie widzę też za bardzo sensu w przepisywaniu już istniejącego projektu na coś innego, jeżeli ten projekt nie wymaga takiego działania. Zresztą jeżeli wymaga, to też nie bardzo ma to sens, bo noob nie zrobi tego dobrze.
Może dla odmiany spróbuj zrobić coś prostego - jakaś książka gości, prosty system zarządzania treścią, aplikacja mobilna. Jeżeli wpadniesz na pomysł czegoś prostego i przydatnego, to dużo szybciej się nauczysz, w dodatku będziesz miał dużo większą motywację.

Trudna? Nie.

Ale kultura pisania kodu jaka wytworzyła się wokół Javy jest dość... korporacyjna.

1. Tendencje do overengineeringu i robienia rzeczy na wszelki wypadek. Opasłe biblioteki i frameworki, które tańczą, śpiewają i parzą kawę, ale żadnej rzeczy nie robią dobrze.
2. Religijne wręcz uwielbienie dla interfejsów i luźnego wiązania między komponentami, tudzież różnego rodzaju wzorców. Wszystko musi być podmienialne, rozszerzalne, dynamiczne, konfigurowalne z Yamla zagnieżdżonego w XMLu itp, nawet jak wcale nie musi być. Potem spędzam tydzień nad kodem aby znaleźć, co kod faktycznie robi i które 2% projektu się faktycznie ładuje.
3. Dziedziczenie i głębokie hierarchie klas. Na szczęście powoli się od tego odchodzi, ale lata miną zanim się programiści oduczą złych nawyków wpajanych latami. Bonus za łamanie LSP.
4. Zamiłowanie do magii w runtime. Adnotacje, które wręcz stają się kodem. Bo nie można wywołać konstruktora jawnie, tylko trzeba frameworkiem, bo inaczej nie byłoby po Javowemu.
5. Java jest dość łatwa, więc na rynku jest dużo słabych programistów.
   a) bardzo ciężko znaleźć tych dobrych
   b) nawet jak się starasz, to i tak wcześniej czy później zatrudnisz jakiegoś głąba
6. Duży poziom akceptacji dla kodu, który wygląda jak kupa i działa byle jak. No dobra, przesadzam, nie jest tak źle jak w środowisku PHP.
7. Niemal nikt nie umie / nie chce obsługiwać błędów. Brak pliku? Wyświetlimy użytkownikowi stacktrace. Bonus za brak nazwy pliku w komunikacie.
8. Wzorce obeitkowe wzorcami, ale static w każdym projekcie gdzieś musi być. I singleton. Albo dwa. Tej samej klasy.
9. Powttarzalne buildy są dla leszczy. Build projektu, który działałby zawsze, byłby zbyt nudny. Zróbmy jakiś fajny skrypcik w gradlu, tak żeby projekt się nie budował w co drugi czwartek. Kto pisał, że Java jest nudna?
10. Komentarze w kodzie są złe. Komentarze oznaczają, że kod jest nieczytelny. Dlatego super hero programiści nie piszą komentarzy. Piszą nieczytelny kod bez komentarzy.

Zabawne jest, że Golang jest w sumie bardzo zbliżony do pierwszych Javek, a ma kulturę zupełnie inną.

@Krolik: Trochę masz rację. Lata korpodevelopmentu z liczeniem programistów na sztuki i deadlinami "na jutro" swoje robią. Ogólnie to widzę 2 rodzaje problematycznych programistów:
"U mnie działa i zrobione szybko" - czyli faktycznie o wzorcach projektowych, OOP, SOLID nawet nie słyszeli, a jak słyszeli to nie zrozumieli.
Przeczytali jakąś książkę, typu "Clean Code" i dyskutują tygodniami, czy jakaś metoda w klasie powinna się nazywać clean(), czy removeAll(), a na widok komentarza w kodzie dostają piany na pysku, bo przecież "komentarze to zło", a fakt, że akurat ten kawałek kodu to jakiś przepisany na Java wzór matematyczny i warto by wiedzieć jaki, bo z kodu tego nie wyczytasz w mniej niż tydzień nie ma znaczenia. Praktycznie każdą radę, którą usłyszą i zrozumieją traktują jak nienaruszalny dogmat i zamieniają w groteskę.

Myślę, że składa się na to parę faktów - prostota języka, ale też prostota systemów, które się w dużej części tworzy przy jego użyciu. Ostatecznie naprawdę wiele systemów nie wykracza zanadto poza CRUD i napisanie do nich "u mnie działa" backendu, specjalnym wyzwaniem intelektualnym nie jest.