Java vs C++

Witam, chciałbym się dowiedzieć który język jest praktyczniejszy. Który z nich ma większą 'moc', tj. pozwala nam na rozwiązanie większej ilości problemów itd. Ktoś gdzieś kiedyś pisał że jest to Java i odniósł się do głupich Programming Challenges, w których nie wszystkie ćwiczenia dało się napisać w c++ a w javie tak (?). Nie wiem czy to prawda, dlatego chciałbym aby ktoś mi to rozjaśnił.

Wszystko co napiszesz w Javie jest do napisania w C++, ale nie wszystko warto pisać w C++, NIE MA czegoś takiego jak język, który pozwala na rozwiązanie większej ilości problemów. Jeśli tak mamy patrzeć to jest to C++. Natomiast jeśli mamy patrzeć na praktyczność to jest to Java, bo łatwiej się w niej pisze, i głównie w Javie powstają aplikacje klasy enterprise. Wszystko zależy od tego co chcesz robić, i tak z biegiem czasu przesiądziesz się na inny język, będziesz musiał znać kilka...

1. NIe wierz we wszystko co ktoś gdzieś napisał.
2. Oba języki sa Turing Complete
3. Ale z pewnością pisanie sterownikow do np. linuxa jest w Javie bardziej niemożliwe niż w C++ .
4. W Javie łatwiej ci się będzie nauczyć jeśli niewiele programowania umiesz
5. Oba języki są dośc stare i mnóstwo przykładów w internecie pokazuje tak naprawdę: jak nie należy programować. Z tym, że w C++ jest IMO gorzej.

"Ktoś gdzieś kiedyś pisał że jest to Java i odniósł się do głupich Programming Challenges, w których nie wszystkie ćwiczenia dało się napisać w c++ a w javie tak"
bzdura

W Javie nie napiszesz systemu komputerowego, kompilatorów, przeglądarek i sterowników, czy wydajnych gier na PC i Konsole, a w C++ już tak. Jest więcej zastosowań C++. Obecnie uczę się C++17, jak dla mnie bez obiektowości łatwiej załapać podstawy. Nawet nie ma książki do Javy która nie wymaga znajomości C++.

Wesoły Mleczarz napisał(a):

W Javie nie napiszesz systemu komputerowego, kompilatorów, przeglądarek i sterowników, czy wydajnych gier na PC i Konsole, a w C++ już tak. Jest więcej zastosowań C++. Obecnie uczę się C++17, jak dla mnie bez obiektowości łatwiej załapać podstawy. Nawet nie ma książki do Javy która nie wymaga znajomości C++.

Bzdury, nie cierpię Javy, ale wszystko to, co napisałeś wyżej w Javie da się napisać.

W ogóle, trzeba się uczyć programować, nie języka. Więc wybierz język (najlepiej Pythona) i naucz się porządnie programować. A jak jakiś projekt będzie wymagał Javy czy C++, to się nauczysz...

Wesoły Mleczarz napisał(a):

W Javie nie napiszesz systemu komputerowego, kompilatorów, przeglądarek i sterowników, czy wydajnych gier na PC i Konsole, a w C++ już tak. Jest więcej zastosowań C++. Obecnie uczę się C++17, jak dla mnie bez obiektowości łatwiej załapać podstawy. Nawet nie ma książki do Javy która nie wymaga znajomości C++.

Moja ulubiona gra jest Javie (MineCraft/ ViveCraft) -chlip chlip.
Kompilator Javy jest Napisany w Javie.
Kompilator Kotlina jest w Javie (i w Kotlinie).
Przeglądarki są w javie (słabe ale są).
Tylko sterowniki słabo - normalna java do hard RT się nie nadaje.

Wszystko się sprowadza do rozwiązania kilku równań matematycznych i to nieważne jaki język do tego użyjesz, a rozwiążesz każdy problem.

Taki będzie działa ten kompilator jak ten system JavaOS, niby można ale. Rozumiem fanbojstwo niektórych z was i ożenek z Javą aż po grób. Nie bez powodu to forum w innych miejscach sieci ma opinię pro Javowego ;) Czasami mam wrażenie, że tak boicie się aby nie stracić posadki programisty Javy, że nie jesteście w stanie nauczyć się drugiego, czy innego języka programowania.

Usuń wszystko z komputera co jest napisane w c++ a pozniej na odwrót i bedziesz widział potęge c++.

Czasami mam wrażenie, że tak boicie się aby nie stracić posadki programisty Javy, że nie jesteście w stanie nauczyć się drugiego, czy innego języka programowania.

A to nauka kolejnego języka programowania jest powodem do wyrzucenia z pracy? Po godzinach to można i w COBOLu pisać dla przyjemności - co to kogo obchodzi?

Wesoły Wąż napisał(a):

Wszystko się sprowadza do rozwiązania kilku równań matematycznych i to nieważne jaki język do tego użyjesz, a rozwiążesz każdy problem.

Każdy problem algorytmiczny - na sucho, tak.

Ale nie każdy problem jest algorytmiczny. Problem może być np. z dostępem do urządzeń wejścia-wyjścia.
Na przykład możemy mieć język skryptowy, kompletny w sensie Turinga i w ogóle. Ale działa we własnej małej piaskownicy i nie udostępnia np. interfejsu do generowania grafiki. I co zrobisz? Nic nie zrobisz. Przynajmniej nie w tym języku.

Albo musisz użyć biblioteki X. Biblioteka okazuje się jednak że intensywnie wykorzystuje model obiektowy języka Y, a ty chciałeś pisać w Z. I co zrobisz? Nic nie zrobisz. Przynajmniej nie w Z.

Dlatego nie, nie wszystko sprowadza się do „rozwiązania kilku równań matematycznych”, i jest ważne jakiego języka używasz. Z wielu powodów.

chciałbym się dowiedzieć który język jest praktyczniejszy. Który z nich ma większą 'moc', tj. pozwala nam na rozwiązanie większej ilości problemów itd

Na nogach dojdziesz do wielu więcej miejsc niż jadąc samochodem. Chodzenie na nogach ma więc większą moc niż jazda samochodem. Czy to czyni je praktyczniejszym?

To ja może trochę o tej Mocy, chociaż wiem że wątek i tak zaraz zejdzie na GC i inne oczywistości.

1. Programming Challenges
   Da się w obu językach. Większość tego typu serwisów wspiera oba te języki. Sam rozwiązuję zadania głównie w Javie.

C++:

• trzeba trochę podrasować I/O: Wymuszanie wysokiej wydajności iostream
• ma typ unsigned - przydaje się w algorytmach
• programowanie funkcyjne na razie chyba raczkuje (aczkolwiek chętnie usłyszę że nie mam racji)

Java:

• ma więcej wbudowanych kontenerów,
• ma BigDecimal / BigInteger,
• ma jedną formę przesyłania obiektów (prostsza składnia) zamiast n form (w C++ masz wskaźniki, przez wartość, smart pointery, const/nie const, referencje...) - w Javie skupiasz się na problemie a nie na języku
• typ tablicowy ma rozmiar

1. Praktyczność.
   Trudne zagadnienie. Zależy co jest Twoim priorytetem.

a) jeśli przenośność uruchamialnego programu na każdym popularnym systemie to Java jest lepsza - udostępniasz plik .jar i ktoś sobie to uruchamia jednym poleceniem. W C++ musisz dostarczyć odrębny EXE dla każdego systemu.

b) jeśli przenośność uruchamialnego programu na konkretnym systemie, to C++ jest lepsze - nie wymaga żadnych dodatkowych pakietów na docelowej maszynie (Java wymaga JRE - w tej czy innej formie).

c) jeśli przenośność na poziomie źródeł, to w Javie musisz się mniej martwić o środowisko, ponieważ dużą część tych tematów załatwia Ci JDK - w nim masz GUI, obsługę unicode, wątki i kontenery wielowątkowe, (powiedzmy) uniwersalną obsługę systemu plików, generator dokumentacji, monitor aplikacji i jest mniejsza różnorodność kompilatorów, więc mniejsze prawdopodobieństwo że komuś coś się nie skompiluje

d) jeśli dostęp do natywnych rozwiązań popularnego systemu (pamięć współdzielona, log systemowy, wywołania systemowe, moduły kernela, sterowniki) to w samej Javie może to być niemożliwe, albo na poziomie "odkrycie atomu" o ile nie masz API. Sytuację ratuje JNI, JNA, JNR.

e) jeśli dostęp do natywnych API bardziej niszowego systemu to o ile w ogóle masz JRE na tej maszynie, może się okazać, że jesteś sam (jeśli nie ma dostępnego wrappera)

f) jeśli chodzi o ogólny rynek pracy to Java dzisiaj wygrywa jeśli chodzi o liczbę ofert. Nie wiem jak z zakresem pensji.

g) szacuję (nie badałem), że jeśli chodzi o pracę w HPC to w Javie pracy pewnie będzie mniej ofert. Przykład na UK indeed.com:

• "c++ hpc" - 41 ofert
• "java hpc" - 17 ofert

h) w gamedev raczej przyda się bardziej C++

i) w HFT raczej rynek skłania się ku Javie (@katelx coś o tym wspominała). Pewnie ze względu na łatwość dołączania pluginów i większą kontrolę nad nimi.

Jedyny język programowania jaki może kiedyś zagrozić Javie to Javascript/Node lub Python. Ewentualnie powstanie coś nowego lepszego od programowania obiektowego i funkcyjnego.

Jest rok 2018, w C++ o ile mi wiadomo nadal nie ma sensownego, popularnego dependency managera. Żadnego mavena, ivy. Co jakis czas ktoś nowy ogłasza, potem to i tak jakby umiera (conan).
Z perspektywy typowego javowca, który między śniadaniem a lunchem dociąga do projektu 4 biblioteki do logowania, jedną do FFT i trzy do jsona to troszkę absurdalne.

skoro juz zostalam wspomniana to odezwe sie w tej bezsensownej dyskusji (bo tak naprawde tu nie ma o czym dyskutowac, java jest duzo latwiejsza i duzo popularniejsza, chcesz szybko zarabiac to ucz się javy).
pewnie wzbudzi to kontrowersje ale z mojego doswiadczenia wynika ze dobrze zoptymalizowana java jest generalnie szybsza od dobrze zoptymalizowanego c++, pisze tu o duzych, zlozonych systemach pisanych przez kumatych ludzi, nastawionych na low latency/high throughput a nie o prostych benchmarkach udowadniajacych kto ma wiekszego.
swoja droga to nie ma czegos takiego jak uhft w standardowym c++, bo wiekszosc standardowych abstrakcji jest za wolna, alokatory pisze sie samodzielnie a poleganie na UB jest na porzadku dziennym. z java czy c# jest zreszta podobnie, uzywany jest bardzo maly podzbior jezyka/frameworka, co ma znaczenie to umiejetnosc sprowadzenia problemu do O(1), brak pauz, cache-friendly struktury, no-copy i/o i przede wszystkim dobry sprzet/siec.

> java
> przede wszystkim dobry sprzet

placeg napisał(a):

Który z nich ma większą 'moc', tj. pozwala nam na rozwiązanie większej ilości problemów itd.[...] Nie wiem czy to prawda, dlatego chciałbym aby ktoś mi to rozjaśnił.

Powtarząjąc innych i odpowiadając - C++ ma większą 'moc'.
C++ ma też zdecydowanie najwięszy udział wśród języków wykorzystywanych w turniejach algorytmicznych.

W świecie hardcorowych projektów też głównie C++, ewentualnie C (AI, rakiety, systemy operacyjne, roboty, łaziki, computer vision etc.). Trochę jest to przygnębiające, że przez ostatnie kilka dekad nie powstało nic lepszego co by się przyjeło na tym poziomie. Obecnie Rust chyba trochę kandyduje ale nie wiem na ile to hype a na ile realnie ma szanse.

Obecnie Rust chyba trochę kandyduje ale nie wiem na ile to hype a na ile realnie ma szanse.

Rust jest zdecydowanie bardziej ludzki od C++ i ma te same zalety nad językami zarządzanymi. Rustowy postęp to zdecydowanie lepsza składnia i zachowanie kompilatora - ilość gwarancji które daje Rust jest znacznie większa (mechanizm ownership i borrowing, mało upierdliwych UB i implementation defined), a komunikaty błędów od kompilatora są bardziej przyjazne i pomocne. Jeśli miałbym wybierać między C++, a Rustem to zdecydowanie (bezapelacyjnie, jak Bogusław Linda) wybrałbym Rusta. Więcej - teraz piszę hobbystycznie program w Ruście. Ogólnie jednak numerem 1. dla mnie jest Scala :)

jarekr000000 napisał(a):

Jest rok 2018, w C++ o ile mi wiadomo nadal nie ma sensownego, popularnego dependency managera. Żadnego mavena, ivy. Co jakis czas ktoś nowy ogłasza, potem to i tak jakby umiera (conan).
Z perspektywy typowego javowca, który między śniadaniem a lunchem dociąga do projektu 4 biblioteki do logowania, jedną do FFT i trzy do jsona to troszkę absurdalne.

Tak, tooling to jeden z największych problemów c++. A kolejny może nawet większy to masa betonowych ludzi. Którzy na takiego conana odpowiadaja klasykiem

Mimo że sam nie wyobrażam sobie dzisiaj pisać w czymś starszym niż c++11, to jednak zmiany c++11,14,17 mimo że wiele rzeczy uproszczają, to sprawiły że c++ stał się znacznie cięższy Javy.

Weź pokaż i wytłumacz
http://en.cppreference.com/w/cpp/language/value_category
osobie piszącej w Javie.

W pracy ostatnio kilku core java programistów, musiało się dokształcić, żeby móc pomóc w c++'owych projektach. I teraz hasła w stylu

• tu musi byc ref
• tu const ref
• tu value i move
• tu masz const ref to nie dawaj move
• tu masz ref i powinienes move
• tu masz ref i nie powinienes move
  itp.....
  są na porządku dziennym.
  Nie dziwie się, że ich zdanie o c++ jest tylko jedno, c++ = WTF

A w javie, przesyłam parametr, to przesyłam i tyle.

katelx napisał(a):

java jest duzo latwiejsza i duzo popularniejsza, chcesz szybko zarabiac to ucz się javy).
Zgadzam się w 100%. Chociaż w Polskich warunkach, powiedziałbym, chcesz szybko dużo zarabiać ucz się js.

pewnie wzbudzi to kontrowersje ale z mojego doswiadczenia wynika ze dobrze zoptymalizowana java jest generalnie szybsza od dobrze zoptymalizowanego c++, pisze tu o duzych, zlozonych systemach pisanych przez kumatych ludzi, nastawionych na low latency/high throughput a nie o prostych benchmarkach udowadniajacych kto ma wiekszego.

Aplikacje o których mówisz i tak się pisze zupełnie inaczej. To nie jest typowa java/c++. Bo co to za c++ kiedy 90% czasu spędzasz z godboltem patrząc jak kompilator zrobił i tak co innego niż myślałeś.
A w Javie, pokaż ten zoptymalizowany kod to ide o zakład że, 95% z programistów Javy na pierwszy rzut okiem nie pozna że, to Java.

amd napisał(a):

• tu musi byc ref
• tu const ref
• tu value i move
• tu masz const ref to nie dawaj move
• tu masz ref i powinienes move
• tu masz ref i nie powinienes move
  itp.....
  są na porządku dziennym.
  Nie dziwie się, że ich zdanie o c++ jest tylko jedno, c++ = WTF

No spoko, ale chyba nie sądzisz, że programista C++ też sie nad tym zastanawia. Fakt, C++ jest expert-friendly, ale jak już jesteś bardziej "expert" niż "junior", to serio takie problemy znajdziesz tylko na 4programmers...

A ja mam takie pytanie, czy w ogóle ma powstać jakiś nowy standard języka C w przyszłych latach? Jest coś zaplanowane? Jak rozumiem C jest mniejsze i trochę prostsze od C++?

W 2011 roku wyszła nowa wersja C (C11). Poprzednia była z roku 1999. Pełna lista jest tutaj: https://en.wikipedia.org/wiki/ANSI_C#History_and_outlook
Ekstrapolując te bardzo niewielkie dane można sądzić iż nowa wersja C wejdzie za kilka bądź kilkanaście lat.

Dzięki za odpowiedź. A czy te wersje C89, C99, C11 są kompatybilne wstecz? Czy twórcy C już ustalili z góry, że C nigdy nie doda programowania obiektowego jak C++ i Objective-C w przyszłych nowych standardach? No bo jeśli, nie jest kompatybilne wstecz z poprzednimi standardami, a można by było trochę ulepszyć ten język kopiując do niego bardziej nowoczesne rozwiązania, to czemu nie.

W życiu pewne są tylko śmierć i podatki. Jednak jest wysoce wątpliwe, by jakakolwiek obiektówka weszła do C. Masz przecież Objective-C, C++, D i Rusta do wyboru. C jest językiem do którego łatwo robić bindingi i to jest jego siła. Wprowadzenie własnej obiektowości spowodowałoby, że integracja z innymi językami (np Javą, Pythonem, C++em) byłaby trudniejsza.

Kompatybilność między wersjami C jest bardzo wysoka, ale możliwe że niepełna. Ewentualne niekompatybilności są spowodowane raczej kwestiami bezpieczeństwa, niż wprowadzaniem nowych bajerów. Oczekiwanie, że C po tylu latach od stworzenia zmieni kierunek rozwoju jest co najmniej absurdalne.

@placeg: A ja spróbuję dojść do sedna, bo sam od czasu do czasu lubię zadać takie pytanie, na które można odpowiedzieć, ale ta odpowiedź tak naprawdę nic nie daje.

Z tonu postu rozumiem, że raczej jesteś początkującym (swój pozna swego :P). Pytanie, które zadałeś jest trochę zbyt ogólne, taki temat rzeka, wiem jednak z czego to wynika - czasami człowiek nawet nie wie o co zapytać. Moja odpowiedzią będzie: języki do pewnego stopnia są do siebie podobne, ale tak jak traktor i jeep. Jedno i drugie ma 4 koła, silnik, żłopie paliwo i jeździ po bezdrożach. Tylko tutaj trzeba zauważyć, że oba narzędzia są używane przy różnych problemach (nie twierdzę, że zawsze, bo są problemy, które rozwiążesz i tu i tu). Java przyjęła się w X, C++ w Y i tyle.

Pytanie brzmi: o co konkretnie chciałeś zapytać? O to który wykorzystuje się w jakich zadaniach? Który łatwiejszy do nauki?

Naucz się Javy i C++ i po problemie.

vpiotr napisał(a):

To ja może trochę o tej Mocy, chociaż wiem że wątek i tak zaraz zejdzie na GC i inne oczywistości.

Ogólnie się zgadzam, ale:

1. Programming Challenges
   Da się w obu językach. Większość tego typu serwisów wspiera oba te języki. Sam rozwiązuję zadania głównie w Javie.

C++:
[...]

• programowanie funkcyjne na razie chyba raczkuje (aczkolwiek chętnie usłyszę że nie mam racji)

Proszę bardzo; nie masz racji. :) A poważnie -- co uznasz za nieraczkujące programowanie funkcyjne?

Java:

• ma więcej wbudowanych kontenerów,

Jakie kontenery ma Java, których nie ma C++? Pytam poważnie, bo nie wiem (Java nie jest moją 'weapon of choice').

[...]

• typ tablicowy ma rozmiar

W C++ też każdy typ tablicowy ma rozmiar... (tablica.size()). Oczywiście nie mówimy to u surowych tablicach z C (których nie ma sensu używać, jeśli programujesz w C++).

1. Praktyczność.
   [...]

A tu to już się cąłkiem zgadzam. :)

koszalek-opalek napisał(a):

vpiotr napisał(a):

• programowanie funkcyjne na razie chyba raczkuje (aczkolwiek chętnie usłyszę że nie mam racji)

Proszę bardzo; nie masz racji. :) A poważnie -- co uznasz za nieraczkujące programowanie funkcyjne?

Np. takie z niemutowalnością kontenerów i lazy evaluation.

Java:

• ma więcej wbudowanych kontenerów,

Jakie kontenery ma Java, których nie ma C++? Pytam poważnie, bo nie wiem (Java nie jest moją 'weapon of choice').

Jednowątkowe:
LinkedHashMap, LinkedHashSet, EnumMap, EnumSet, WeakHashMap

Wielowątkowe - tego jest dużo więcej, np.:
ArrayBlockingQueue, ConcurrentLinkedQueue, DelayQueue, LinkedBlockingDeque, LinkedBlockingQueue, LinkedTransferQueue, PriorityBlockingQueue, SynchronousQueue

W C++ też każdy typ tablicowy ma rozmiar... (tablica.size()). Oczywiście nie mówimy to u surowych tablicach z C (których nie ma sensu używać, jeśli programujesz w C++).

Oczywiście chodziło mi o typ tablicowy (char[]), nie o tablicę (std::array). Co kto czego używa to inna sprawa.