Dlaczego Java jest taka "hardkorowa"?

0

Słuchajcie - co chwila na forum pojawiają się wpisy w stylu

PYT: chcę uczyć się czegoś. Chyba Java jest najlepsza, bo można mieć 30 tysięcy miesięcznie. Czy dam radę?
ODP: tak, ale do po wieeeelu latach, dopiero jak zaczniesz wymiatać

I tak się zastanawiam - czy Java jest naprawdę takim kosmicznym tworem, którego opanowanie na poziomie średnio zaawansowanym trwa kilka lat i jest możliwe jedynie dla największych bystrzaków, czy jest to może raczej powtarzany przez wszystkich slogan, nie mający większego poparcia w faktach.

Od razu zaznaczam - nie chodzi mi o osobę totalnie zieloną, która zaczyna w branży po jakimś kursie weekendowym/bootcampie i stara się dostać pracę jako junior. Zastanawiam się raczej, na ile trudne jest opanowanie Javy przez osobę z doświadczeniem i biegłą umiejętnością programowania.

Zawsze uważałem, że język jest tylko narzędziem, którego opanowanie jest 100 razy prostsze, niż ogarnięcie samego procesu tworzenia aplikacji, przekładania zadań na konkretne procedury, obmyślania sposobów rozwiązania danych problemów itp. Podobnie jak z prowadzeniem auta - jak się nauczysz jeździć, to po przesiadce do innego samochodu przez chwilę poczujesz się trochę niepewnie, ale po krótkim przyzwyczajeniu się możesz jechać dalej. A czytając to, co ludzie piszą na temat Javy - mam wrażenie, że jest to przesiadka z seicento do wojskowego transportera opancerzonego przewożącego wyrzutnię rakiet nuklearnych ;)

4

Zawsze uważałem, że język jest tylko narzędziem, którego opanowanie jest 100 razy prostsze, niż ogarnięcie samego procesu tworzenia aplikacji, przekładania zadań na konkretne procedury, obmyślania sposobów rozwiązania danych problemów itp.

I tak jest.

mam wrażenie, że jest to przesiadka z seicento do wojskowego transportera opancerzonego przewożącego wyrzutnię rakiet nuklearnych

I to też trochę prawda ;)

Wynika to z faktu, jakie aplikacje i jak pisze się w Javie. W javie nie robi się stronek osiedlowego warzywniaka, tylko duże biznesowe aplikacje. Problemem nie jest nauka samej Javy, tylko ogarnięcie całego ekosystemu. Nikt praktycznie nie pisze tych dużych aplikacji "w gołej javie", tylko wrzuca się tam już na start kilka frameworków i bibliotek a potem to juz tylko puchnie.
W efekcie wskakujesz do projektu i niby umiesz przeczytać kod który tam jest, bo znasz javę, ale jednocześnie masz tam całą masę rzeczy framework-specific (konfiguracje Springa, Springowe komponenty, mapowania JPA, jakaś komunikacja JMSem, JAX-RS/JAX-WS, jakaś Kafka, może Spark), coraz częściej też integracje z serwisami typu Amazon WS itd. To nie jest jakaś specjalna specyfika javy, a raczej to, że javę stosuje się do takich projektów.
To trochę ludzi odstrasza, chociaż moim zdaniem niepotrzebnie. Bo realistycznie i tak większość kodu to jest czysta java, a te około-frameworkowe rzeczy to mały wycinek. Ot np. kilka linijek konfiguracji i jesteś podłączony na jakieś eventy z kafki i potem ich obsługę piszesz już w zupełnym oderwaniu od tego skąd one przychodzą. No ale ludzie czasem panikują ;]

0

nie znam zbytnio javowych frameworkow, moze to w nich lezy problem.
ja po paru latach kodowania w c# przesiadlam sie na jave bez dodatkowego douczania sie na wstepie - pewnego dnia lead powiedzial ze mam cos w javie zrobic, dal mi link do opisu jak sciagnac i odpalic projekt, polecil na ktore klasy mam spojrzec i dalej juz bylo z gorki. na poczatku googlowalam troche skladnie, przeczytalam na wyrywki pare bardziej zaawansowanych tematow i stalam sie javowcem :)

0

No i mam dwie odpowiedzi, z czego obie sobie przeczą...
@Shalom pisze, że bez frameworków oraz innych dodatków raczej Javy się nie rusza, za to @katelx twierdzi, że sobie dobrze radzi, chociaż prawie wcale nie zna/nie używa tych dodatków...WTF? ;)

2

Oboje mają rację...

0

Ja kodziłem 3 lata komercyjnie w Javie praktycznie nie dotykając Springa ani Hibernate'a. Przykładowe zadania w Javie to:

  • w e-podróżniku komunikacja z czytnikiem kart płatniczych, czytnikiem monet i czytnikiem banknotów
  • w Sabre stworzyłem rozproszone GC do EJB 2 - tzn mechanizm pingowania i ubijania stanu po stronie serwera, bo temu brakowało pamięci po tym jak klienci się rozłączali nie zamykając wcześniej poprawnie sesji
0
Shalom napisał(a):

Wynika to z faktu, jakie aplikacje i jak pisze się w Javie. W javie nie robi się stronek osiedlowego warzywniaka, tylko duże biznesowe aplikacje.

Pytanie - czy (a jeśli tak, to co) stoi na przeszkodzie, żeby po opanowaniu Javy robić w niej w razie potrzeby mniejsze zadania?
Rozumiem, że nie ma sensu się uczyć Javy żeby zrobić prostą apkę typu książka telefoniczna albo pasjans, ale czy w sytuacji, w której ktoś ma już Javę opanowaną, to napisanie w niej takiej apki będzie o wiele trudniejsze / bardziej skomplikowane, niż napisanie chociażby w C++ / Qt / Delphi?

2

No i mam dwie odpowiedzi, z czego obie sobie przeczą...

Wcale sobie nie przeczą. Pisałem, że te około-frameworkowe rzeczy to jest pewien wycinek całej aplikacji. Zwykle to jest infrastrukura + integracja między serwisami. Jeśli ktoś klepie stricte logikę aplikacji, to może nigdy tego nie dotknąć na dobrą sprawę. Ot bierze sobie jakieś DAO i wyciąga dane i nie interesuje sie tym że pod spodem jest jakaś integracja z bazą danych, S3 czy czymś innym. Analogicznie pisze sobie obsługę dla jakichś eventów i nie ma znaczenia czy idą one z JMSa, Kafki czy z czegokolwiek innego. Jak ktoś klepie kod z głową, to nic nie "przecieka" dalej, tylko w module który np. odbiera dane transluje się to na własne obiekty domenowe i nikt dalej już nie widzi tego powiązania z taką czy inną technologią.
Nie zmienia to faktu, że ktoś te integracje też musi klepać ;)

czy w sytuacji, w której ktoś ma już Javę opanowaną, to napisanie takiej apki w Java będzie o wiele trudniejsze / bardziej skomplikowane, niż napisanie chociażby w C++ / Qt / Delphi?

Nie, ale klepnąć prostą webową aplikacje w Pythonie można mieć dosłownie w kilku linijkach, analogicznie w PHP, ale już w Javie będzie to bardziej rozwlekłe.

0

klepnąć prostą webową aplikacje w Pythonie można mieć dosłownie w kilku linijkach, analogicznie w PHP, ale już w Javie będzie to bardziej rozwlekłe

A desktopy? Żeby nie komplikować - zawęzimy do Windowsów. Też jest taka dysproporcja?

0

W Javie chyba desktopów nikt nie pisze.

2

Java sama w sobie nie jest niczym trudnym. Ba, do Javy 8 to był bardzo prostacki język w którym względnie trudno o pomyłkę na poziomie języka - większość problemów brała się z algorytmów i sposobie implementacji. W sumie ciągle jest dosyć prosta.

Tyle tylko że znajomość składni to jedno. Do tego dochodzą znajomości bibliotek (łatwe), frameworków (trudniejsze), serwerów aplikacyjnych (trudniejsze) i samej wirtualnej maszyny Javy, dziwnych protokołów itp.

0
cerrato napisał(a):

No i mam dwie odpowiedzi, z czego obie sobie przeczą...
@Shalom pisze, że bez frameworków oraz innych dodatków raczej Javy się nie rusza, za to @katelx twierdzi, że sobie dobrze radzi, chociaż prawie wcale nie zna/nie używa tych dodatków...WTF? ;)

wiekszosc potrzebnych dodatkow piszemy po prostu sami. nie uzywalam w praktyce zbyt wielu popularnych frameworkow/bibliotek ale to nie znaczy ze za kazdym razem pisze bubble sorta od zera ;)

slayer9 napisał(a):

W Javie chyba desktopów nikt nie pisze.

stawiam ze prawie kazdy szanujacy sie duzy bank ma pare gui w swingu ;)

1

I że parę dashboardów w CERNie to też swing albo JavaFX.

1

W programowaniu Java język jest banałem. Nie ma co porównywać skomplikowania składni Java do takiego C++ z wszystkimi naleciałościami, Delphi (czy tam wciąż jest ten *&^%$ jednoprzebiegowy kompilator?), czy nawet C#. Java jest językiem z założenia banalnym ze stosunkowo nielicznymi naleciałościami (porównując do innych technologi tego typu). Kasa nie jest płacona za znajomość języka, tylko za znajomość całej otoczki - komunikacja, architektura, kolejki, bazy danych, usługi chmurowe, autentykacja, bezpieczeństwo aplikacji, znajomość domeny (biznes) w której się programuje i masa innych rzeczy wielokrotnie bardziej złożonych niż jakakolwiek konstrukcja składniowa w Java. Programowanie w Java, to 2 książki - jedna o tym co oferuje język, druga o tym czego z tej pierwszej nie używać. Wszystko dookoła jest już dużo trudniejsze do przyswojenia.

0

Dla mnie Java była dość trudna na pierwszy język programowania, rozejrzałem się po Ruby i Python i po wyborze języka zdecydowanie ten drugi dużo łatwiej mi się ogarnia. Nigdy nie miałem styczności z programowaniem, często mówili, że PHP i Python jest najłatwiejsze, aby wejść w programowanie i wydaje się to być prawdą.

1

No i mam dwie odpowiedzi, z czego obie sobie przeczą...
@Shalom pisze, że bez frameworków oraz innych dodatków raczej Javy się nie rusza, za to @katelx twierdzi, że sobie dobrze radzi, chociaż prawie wcale nie zna/nie używa tych dodatków...WTF? ;)

Bo w Javie robi się wszystko - i to wszystko w biznesowej skali (poka mi taki inny ekosystem). Tutaj masz wszystko, masz SAP'a, Oracla czy IBM'a i ich eCommercowe rozwiania które są wielkości średniego państwa (przy okazji generując podobne dochody) - i to będą właśnie te miejsca gdzie masz masę frameworków, generowania kodu w locie, masę magi (którą tak kocha @jarekr000000).
Masz też miejsca w których robi się soft-latency systemy żeby zarabiać pieniążki dla giełdowych spekulantów - tutaj nie uświadczysz frameworków bo ich nie potrzeba, logika jest znikoma - tak samo jak zajętość w old-genu (card-marking kosztuje nie ? ;D ), a może być szybko bo jest JIT.

Także odpowiedzi sobie nie przeczą ;)

1

Bo w Javie robi się wszystko - i to wszystko w biznesowej skali

A dlaczego akurat Java? Z czego wynika, że akurat ona znalazła się w takim miejscu? Czy jest to po prostu takie bezmyślne powtarzanie schematu - jeśli robimy coś wielkiego to MUSIMY w Java, czy z czegoś konkretnego to wynika?
Mam świadomość, że teraz to żyje własnym życiem i samo się napędza: fachowcy pracują w Java, bo tego wymaga rynek,a z kolei rynek szuka Javovców, bo ... no bo tak musi być, Java to jedyna opcja, bo wszyscy w niej robią (ale dlaczego???) i najlepsi programiści z pewnych dziedzin pracują w Java. Tylko dlaczego tak się stało?

4

Tylko dlaczego tak się stało?

Spisek!

A tak na serio to najpierw trzeba sobie uświadomić jak wyglądają korpo-projekty. Typowy korpo-projekt ma kod w rozmiarze liczonym w setkach tysięcy linii kodu, gdzie kod sprzed 5 lat miesza się z kodem napisanym wczoraj. W typowym projekcie są typowi programiści, czyli wcale nie wymiatacze. Są juniorzy, którzy piszą słaby kod, ale wielu seniorów też klepie dziadostwo. W gąszczu tak ogromnej ilości średniawego kodu nie tylko trzeba się odnaleźć, ale też go poprawiać i rozszerzać o nowe funkcjonalności.

Jaki język może sprawdzić się w powyższym scenariuszu?

  1. Kaczo-typowany typu JavaScript, PHP czy Python? Raczej nie, bo kacze typowanie zabija statyczną analizę i pomoc od IDE czy innych automatów do orania kodu. Poprawianie dużych ilości kodu bez porządnego wsparcia niezawodnymi automatami jest antyproduktywne.
  2. C/ C++? Kodzenie w nich nie ma sensu, bo mnóstwo czasu będzie tracone na głupotach typu błędy w zarządzaniu pamięcią, arytmetyce wskaźników czy indeksów (wszystko jedno - i tak jest dramat), konstruowaniu skomplikowanych szablonów czy makr preprocesora, które nie tylko są wrzodem na tyłku podczas próby refaktorowania, ale nawet przy samej błędnej próbie użycia, która będzie skutkować upośledzonymi komunikatami błędów.
  3. Rust? Jest lepszy niż C i C++, ale dalej jest sporo mniej wygodny niż Javka, a na pewno jest mniej wygodny niż Scala. Rust pilnuje wskaźników i indeksów (np sprawdza indeksy tablic i rzuca wyjątkiem przy wyjściu poza dozwolony zakres), ale np nadal nie ma automatycznego odśmiecania pamięci. Garbage collection to świetny wynalazek zwiększający produktywność programisty i dlatego wszystkie języki programowania nastawione na wysoką produktywność są oparte o GC.
  4. Java/ C#? Te są aktualnie używane i się sprawdzają. Są na tyle proste, że można stworzyć solidne narzędzia do statycznej analizy kodu i solidne wsparcie od IDE.
  5. Scala? Mój ulubiony język :) Zwięzły, szybki i statycznie typowany. Jednak szerokie spektrum możliwości nie jest w 100% zaletą, bo niedoświadczony programista ma więcej okazji, by pójść złą drogą (tzn nadużyć mechanizmy języka).

Co do reszty języków, typu Haskell czy Erlang to się nie wypowiem, bo w nich nic większego nie robiłem. Jednak są na tyle mało popularne, że ciężko oczekiwać by korporacje miały jakiś interes w promowaniu takich języków. Pchanie się w język w którym nie ma sensownej podaży programistów to ryzykowne posunięcie.

0
cerrato napisał(a):

Bo w Javie robi się wszystko - i to wszystko w biznesowej skali

A dlaczego akurat Java? Z czego wynika, że akurat ona znalazła się w takim miejscu? Czy jest to po prostu takie bezmyślne powtarzanie schematu - jeśli robimy coś wielkiego to MUSIMY w Java, czy z czegoś konkretnego to wynika?
Mam świadomość, że teraz to żyje własnym życiem i samo się napędza: fachowcy pracują w Java, bo tego wymaga rynek,a z kolei rynek szuka Javovców, bo ... no bo tak musi być, Java to jedyna opcja, bo wszyscy w niej robią (ale dlaczego???) i najlepsi programiści z pewnych dziedzin pracują w Java. Tylko dlaczego tak się stało?

Java w momencie swojego startu była prostsza niż C i miała przyjemniejszą składnię od Delphi. Dodatkowo JVMka była całkiem rewolucyjnym pomysłem jeśli chodzi o zarządzanie pamięcią.

0

Piszą w Javie, ponieważ Java jest łatwiejsza od C++ i była tworzona na wzór C++, aby podebrać większość programistów C++. Tak samo C# mógł wyglądać inaczej, ale Microsoft chciał podebrać programistów Javy, więc są tak podobne do siebie. Na zachodzie i za wielkim oceanem Jave stopniowo zastępuje Scala, Kotlin, Groovy i inne nowe języki. Ale Polska jest trzecim krajem świata i jak ludzie raz się czegoś nauczą jak kartofli, to będą to jeść do końca życia. Dlatego dominuje w tym kraju Java i PHP. Do własnych projektów wybierają Kotlin, Rust, Go, Swift, Elixir, do biznesu to w czym jest najwięcej programistów w Polsce czyli PHP i Java większe biznesy. Widzę, że Wappalyzer pokazuje mi już pod YouTube nie tylko Python ale JVM i Scala. Twitter też przepisali z Ruby na Scala.

1
cerrato napisał(a):

A dlaczego akurat Java? Z czego wynika, że akurat ona znalazła się w takim miejscu? Czy jest to po prostu takie bezmyślne powtarzanie schematu - jeśli robimy coś wielkiego to MUSIMY w Java, czy z czegoś konkretnego to wynika?

Dlaczego Java? Bo w czasie jak powstawał ten Język, alternatywą było pisanie w C(++), Perl, (Object) Pascalu i to nie w takich współczesnych ciotowatych wersjach ze smart pointerami tylko w hardcorowej C++ grypserze, gdzie co chwila jakiś "pro senior" wpadał na pomysł "sprytnego" iterowania po tablicy obiektów przesuwając wskaźnik o ileś tam bajtów, albo stawiał sobie za punkt honoru użycie konstrukcji składniowej, którą tylko on będzie rozumiał (przez chwilę). Dodaj do tego brak porządnych narzędzi do programowania, wyszukiwania błędów, czy nawet wersjonowania kodu i masz z grubsza obraz problemu. Tak oczywista możliwość wzięcia sobie skompilowanej biblioteki i użycia jej w aplikacji desktop działającej na Linux, albo Windows, albo jakiejś JEE, albo nawet na karcie kredytowej to coś, o czym wcześniej można było sobie jedynie pomarzyć. C++ jest przenośny na poziomie kodu, ale dość łatwo sprawić, żeby przestał być.

A teraz użycie Java w większości projektów jest oczywiste z bardzo prostych powodów:

  • Jest bezpieczne - 99% aktualnych projektów jest mniej lub bardziej kopią czegoś co już w Javie napisano.
  • Dostępność ludzi - spróbuj zgromadzić 20 osób do pracy przy projekcie w dajmy na to Haskellu, to zrozumiesz problem.
  • Dostępność bibliotek i osnów :D @WeiXiao
  • Dostępność narzędzi (IDE, serwery, debuggery, profilery, zaciemniacze kodu, formatrery, podświetlacze składni, analizatory statyczne, generatory kodu i w pip innych)
  • Wsparcie społeczności
  • Kompatybilność / interoperacyjność - to już trochę mniejszy problem od czasu jak świat przeszedł na REST, ale kiedyś co narzędzie to własny protokół komunikacji i potrzeba pisania własnego "klienta" jeżeli akurat dla twojego języka producent nie dostarczył odpowiedniej biblioteki.
0

Jave może zastąpić teraz jedynie Kotlin lub Swift, a Go raczej już przegrał walkę. Musiał by powstać szybki kompilowany język programowania bez wskaźników i z odśmiecaniem pamięci, który nie posiada nulla(Rust, Kotlin, Scala) i jest prosty składniowo. Najlepiej składnia zbliżona do Pythona, oraz żeby nie miał tyle różnych możliwości co Scala.

1

Scala w ręku doświadczonego programisty to bardzo porządne narzędzie. Niestety jednak w szkołach i uniwersytetach uczy się podejścia mocno imperatywnego przez co wejście w Scalę jest trudniejsze niż wejście w kolejny język mocno imperatywny. Ponadto mimo iż Scala pozwala na pisanie w wielu stylach to podział wśród Scalowców jest w zasadzie tylko na dwie kategorie:

  • klasyczna Scala, czyli mieszanie OOPa z FP. Scala powstała właśnie po to, by udowodnić iż takie połączenie ma sens. Cały stos technologiczny od twórców Scali jest oparty właśnie o podejście łączące OOP z FP.
  • funkcyjny ekstremizm w postaci scalaz, typelevel/cats czy tym podobnych oraz ekosystemu wokół nich. Tutaj rezygnuje się z OOPa na rzecz typeclass opartych o implicity przy każdej okazji, co się da opakowuje w monady, stosuje nieskończone rekurencje itp itd Ten sposób programowania ma największy próg wejścia, ale to zajęcie dla pasjonatów. Nie jest to kierunek promowany przez twórców Scali i oficjalnego scalowego stosu technologicznego.

Właśnie poczytałem o Swifcie na Wiki i moim zdaniem wybór zliczania referencji zamiast "klasycznego" odśmiecania pamięci w zasadzie eliminuje Swifta z branży korpo-kobył. Zliczanie referencji pociąga za sobą spore problemy. Przytoczę dwa:

  1. Problemy z cyklicznymi referencjami. Trzeba się z nimi pałować jeśli już na takie coś natrafimy.
  2. Zliczanie referencji w środowisku wielowątkowym wymaga atomowych operacji, a te są bardzo kosztowne.

Więcej informacji jest tutaj: swift language - How does garbage collection compare to reference counting?

Zamiast zwalać na przeciętnego programistę zabawę z (niepełno)sprytnymi wskaźnikami lepiej udoskonalać klasyczny model odśmiecania pamięci i minimalizować przestoje spowodowane odśmiecaniem w tle. W tym kierunki idą nowe garbage collectory w Javie: http://openjdk.java.net/projects/shenandoah/ http://openjdk.java.net/projects/zgc/ Kotlin jest językiem (głównie) na JVMa, więc piszący w Kotlinie za jakiś czas bez problemu będą w stanie skorzystać z tych udoskonalonych algorytmów GC.

0

Właśnie poczytałem o Swifcie na Wiki i moim zdaniem wybór zliczania referencji zamiast "klasycznego" odśmiecania pamięci w zasadzie eliminuje Swifta z branży korpo-kobył. Zliczanie referencji pociąga za sobą spore problemy. Przytoczę dwa:

tak, ale nie do końca.

coś tam jednak komercyjnie robią

a co do reference-counting, to netty sobie chwali
http://netty.io/wiki/reference-counted-objects.html

0

tak, ale nie do końca.
coś tam jednak komercyjnie robią
https://github.com/apple/swift-nio

Framework obsługujący łączność między serwerem, a klientem to jednak sporo mniej niż korpo-kobyła.

a co do reference-counting, to netty sobie chwali
http://netty.io/wiki/reference-counted-objects.html

A czy netty zostało napisane przez przeciętnych korpo-ludków? Profesjonaliści poradzą sobie z wieloma rzeczami, ale nie oznacza to, że przeciętniakom też dobrze z tym pójdzie.

0

Framework obsługujący łączność między serwerem, a klientem to jednak sporo mniej niż korpo-kobyła.

Dlatego napisałem "cośtam" - a nie "full wypas ikomerce frejmłork"

A czy netty zostało napisane przez przeciętnych korpo-ludków? Profesjonaliści poradzą sobie z wieloma rzeczami, ale nie oznacza to, że przeciętniakom też dobrze z tym pójdzie.

nie wiem dla kogo pisany był ten framework.

3

Jaka tam hardcorowa, podobno wystarczy tylko 34,99 zł "...żeby dostać upragnioną posadę" :) >>> LINK <<<

1 użytkowników online, w tym zalogowanych: 0, gości: 1