Język z przyszloscią?

ktorego jezyka programowania sie teraz najlepiej uczyc? ktory ma tzw przyszlosc? [???]

Masz IMO złe podejście do tematu. Naucz się dobrze jednego dowolnego (polecam pythona), później zajmuj się po kolei po trochu 2 czy 3 innymi. Później każdy następny już to tylko kilka nowych słów kluczowych...

Przyszłość ma C++, Java, C# (i ogółem cały .NET), Python... Chcesz zobaczyć statystyki to wpisz w goglach komercha.

Delphi wymiera niestety ale jescze go uzywają

najlepiej C++, C#, Java, PHP.

a no i assembler zawsze był i bedzie

Assembler był i już go nie ma i nie będzie, chyba że mówisz o programowaniu mikrokontrolerów ewentualnie systemów operacyjnych.

Po pierwsze było wiele razy. Po drugie to:

Przyszłość ma C++, Java

C# wypiera C++, java owszem ale na urządzenia mobilne

Delphi wymiera niestety ale jescze go uzywają

Do czasu istnienia uczelni i szkół delphi i pascal chyba pozostanie

Assembler był i już go nie ma i nie będzie
Będzie i to długo wszędzie tam gdzie prędkość działania będzie miała krytyczne znaczenie.

po cholere znowu ten sam temat? :|

C# wypiera C++, java owszem ale na urządzenia mobilne

Nie tylko na urządzenia mobilne. C# jeszcze długo nie będzie miał czegoś co dorównuje J2EE

Będzie i to długo wszędzie tam gdzie prędkość działania będzie miała krytyczne znaczenie.

Tam gdzie prędkość działania jest krytyczna był i będzie właśnie C/C++.

Coldpeer napisał(a)

po cholere znowu ten sam temat? :|

Bo niektorzy ciagle nie potrafia pomyslec i znalezc miliona podobnych tematow - a kazdy z nich tak samo malo sensowny.

@do autora: naucz sie choc jednego dobrze, naucz sie programowac i wykorzystywac tamten jezyk tak, zeby cokolwiek w nim napiszesz mialo naprawde rece i nogi - to bedzie dobrze - i jezyk nie ma znaczenia...

Dobrze jest się nauczyć różnych języków. Wejdź na ranking TPC, weź 10 języków z góry listy i naucz się programować dobrze w przynajmniej 5 z nich.

Dlaczego Waszym zdaniem "Delphi wymiera"??

Jeśli Java ma większe możliwości i bardzo dobre IDE (Netbeans, Eclipse), i na dodatek to wszystko za darmo, to po co wydawać 15.000,00 zł na Delphi Enterprise? Delphi jeszcze trzyma się na rynku grubych klientów bazodanowych, ale ponieważ coraz częściej zastępuje się je cienkimi klientami webowymi, to popularność musi spadać na rzecz rozwiązań w Java, PHP czy .NET. Widać to na TPC Index.

jest taki maly kruczek, ze w javie pomalu sie robi smietnik i powstaja problemy podobne do tych, z powodu ktorych ludzie zaczeli odchodzic od C++, a takze wiele innych.. rzeczywiscie, technologia i mysl automatyzacji poszla tutaj o wiele dalej, ale mialo to pewne koszty. poza tym ludzie pomalu zaczynaja sie budzic i dostrzegac ze Jave pomimo otwartego community prowadzi czysta komercja Sun'a, dlatego wlasnie zyskuje na popularnosci .Net i C#, poniewaz ludzie wracaja (heh) do Microsoftu, bo tam 'bezpieczniej' i ... mniej udziwnien w technologiach, co zwlaszcza dla "starej kadry", pamietajacej COM itp jest wazne. a zeby bylo jeszce smieszniej, to ostatnio nawet zaczynam slyszec opinie ze ludzie ktorzy przesiedli sie na Jave z powrotem wracaja do C++'a.. taka mala garsc przemyslen i plotek ode mnie..

i pare linkow, polecam przeczytac dla wlasnego 'amusement':
http://darksleep.com/player/JavaAndUnsignedTypes.html
wiecie ze Java kiedys nazywala sie Oak i wcale nie chodzilo o dominacje nad swiatem tylko o ruchome obrazki na stronach http://www.artima.com/weblogs/viewpost.jsp?thread=7555ad=7555
http://java.sun.com/features/1998/05/birthday.html
a tutaj (dosc stary) wywiad z "trzema osobami ktorych nie trzeba przedstawiac", warto przeczytac (i zlosliwie powiem: i porownac chocby ich podejscia do tego co robia)
http://www.gotw.ca/publications/c_family_interview.htm

quetzalcoatl napisał(a)

jest taki maly kruczek, ze w javie pomalu sie robi smietnik

To fakt. Ale taka dola każdego popularnego języka. I tak smietnik ten jest o wiele mniejszy niż np. w WinAPI czy PHP, mimo większych możliwości.

i powstaja problemy podobne do tych, z powodu ktorych ludzie zaczeli odchodzic od C++, a takze wiele innych..

Nie wiem, czemu ludzie odchodzą od C++, ale na pewno śmietnik nie jest tego powodem. Popatrz na PHP - mimo że tam jest b**el do kwadratu, ludzie kochają PHP i całkiem fajnie w tym się programuje pewne rzeczy. A C++ staje się powoli niszowe, bo nie za bardzo ma czym konkurować. Na pewno nie łatwością programowania. Szybkością? Sprawa dyskusyjna.

Jave pomimo otwartego community prowadzi czysta komercja Sun'a

Gdyby ktoś tego nie prowadził, to już dawno mielibyśmy w Javie bałagan jak w PHP. A myślisz że nad jądrem Linuksa to kto pracuje? W wiekszości programiści opłacani przez Novell, IBM itp. Ponoć nawet Microsoft wspiera OpenSource (ale wiem to bezpośrednio od jednego pracownika M$ na niedawnej konferencji, więc to może byc jakaś ściema).

, dlatego wlasnie zyskuje na popularnosci .Net i C#, poniewaz ludzie wracaja (heh) do Microsoftu, bo tam 'bezpieczniej' i ... mniej udziwnien w technologiach, co zwlaszcza dla "starej kadry", pamietajacej COM itp jest wazne

Nie zgadzam się. Java i C# są bardzo podobne, w C# jest może trochę więcej fajerwerków i może parę upierdliwości mniej. Aplikacje okienkowe C# sprawiały też wrażenie, że szybciej chodzą niż client Java 5 (ale już nie 6). .NET jest od pewnego czasu dostarczany razem z Windows, a skoro jest równie dobry jak Java, to oprogramowanie klienckie wielu robi w .NET. Z drugiej strony wydaje mi się, że technologia, która nie oferuje żadnych rewolucyjnych zmian, a jedynie kosmetyczne, nie wyprze z rynku technologii sprawdzonej i dobrze zadomowionej. Dlatego np. serwerowy czy mobilny .NET jest z góry na straconej pozycji. Gdyby go zrobili kilka lat wcześniej, byłoby inaczej. Kliencki ma spore szanse, bo Java nigdy porządnie nie zdobyła rynku aplikacji desktopowych.

. a zeby bylo jeszce smieszniej, to ostatnio nawet zaczynam slyszec opinie ze ludzie ktorzy przesiedli sie na Jave z powrotem wracaja do C++'a.. taka mala garsc przemyslen i plotek ode mnie..

Ciekawe. A jakie są powody dla których wracają? Ja ciągle słysze o tych, co się przenoszą na Javę lub .NET.

wiecie ze Java kiedys nazywala sie Oak i wcale nie chodzilo o dominacje nad swiatem tylko o ruchome obrazki na stronach www?:)

Nie. Chodziło o platformę do budowy softu wbudowanego w urządzenia elektroniczne. Applety były później.
Dzięki za linki. Przeczytałem z zainteresowaniem.

A ten. Nikt nie zakłada, że może Windows straci nieco na monopolu? Że może coraz więcej będzie przeróżnych niksów, a na nich wciąż króluje C... i inne języki, które na Windowsie już odeszły w zapomnienie.

Ktoś powie, że teraz jest łatwiej, mniej bugów, a szybkość traci na znaczeniu. Może i tak. Ale tworzenie rozwiązań i języków, w których radzą sobie sekretarki to chyba taki samobój, co? :>

efbiaj napisał(a)

Ale tworzenie rozwiązań i języków, w których radzą sobie sekretarki to chyba taki samobój, co? :>

To popatrz jak szalenczo rozwinal sie taki np. Basic... Jezyk to jedno, programowanie to drugie. Sekretarka moze pisac w jezyku, ale programowac ot tak sie nie nauczy - wiec zaden samoboj.

Zwłaszcza, że jak czasem popatrzę na to, ile błędów w C/C++ wynika stąd, że można dowolnie grzebać w pamięci... (buffer overflow to chyba najczęściej wykorzystywany błąd podczas ataków) :| Języki, które utrudniają robienie błędów, to dobre języki - o ile nie przesadzą. Czasem to nawet myślę, że jakby wszystko w Javie na przykład było, to może by się wlekło niemiłosiernie, ale w końcu nie byłoby tych wszystkich segment fault i innych takich :]

hm.. no sigsegv by nie bylo, za to bys mial dysk zarzucony logami z wpisami o wyjatkach na 3 strony kazdy.. sek z java w tym, ze java ma pieknie przygotowane biblioteki dzieki ktorym wiele rzeczy robi sie trywialnie i byle gimnazjalista jest w stanie np. stworzyc mikrobaze danych oparta na plikach XML.. ale jak trzeba zrobic cos zgola nowego, bez bibliotek, albo jak trzeba napisac cos bardziej zlozonego - to juz gorzej.. w programach gdzie juz trzeba jakos sie programizmem popisac a nie tylko przeczytaniem 3 tutoriali na krzyz, w javie zaczyna sie robic -trudniej-, ale w innym sensie niz w C++. w C++ bedize trudniej, bo bedzie wiecej kodu gdzie mozna jakas durna literowke przeoczyc, zapomniec ze sie iteratory invaliduja na wektorze jak element skasujesz, czy tez zapomniec gdzies zrobic if(wskaznik!=0).. z reguly, jak sie program napisze dobrze, to po przebrnieciu przez zmudny etap bledow kompilacji, poniejsze bledy sa dosc szybkie do wykrycia - bo wiesz dobrze, ba, musisz wiedziec jak dziala program ktory napisales. a w obecnych rozwiazaniach w javie? 80% zlozonych mechanizmow bazuje na xml+nazwach klas+reflection i defacto nie masz zielonego pojecia jak to w srodku dziala. piszesz totalna bzdure, kompiluje sie, wlacza sie przez 2 minuty, chodzi momencik po czym jak w koncu dana klase zaladuje to produkuje N stron dump'a. poprawiasz bzdure - to samo. po godzinie kopania w dokumentacji okazuje sie ze wlasciwie bzdura byla ok tylko .. to co piszesz to akurat taki specjalny rzadki przypadek i zapomniales ustawic w xml konfiguracyjnym bleble='bum'.. ja przy tym nerwicy dostaje..

moze i jestem maniakiem C++'a, ale Java wniosla jednak pare rzeczy bardzo dobrych: super biblioteki na start i, paradokalnie, reflection, dzieki ktoremu robienie pluginow czy rozszerzen do programow jest banalne. na szczescie juz pare grup pracuje nad reflection dla c++, ale rozbudowywanie obecnych kompilatorow to ciezka sprawa i troche im jeszcze zejdzie. szkoda ze nikt za tym jezykiem nie stoi z taka kasa jak Sun.. potencjal ma o wiele wiekszy. i jeszcze jedna rzecz, ktora Java ma a mi w C++ brakuje STRASZNIE - to kontrola wyjatkow. albo deklarujesz ze metoda rzuca, albo metoda nie ma prawa rzucic.. super, wrecz nie idzie zapomniec czegos obsluzyc.. dlaczego tego w C++ nie wprowadzono i chyba nawet nikt nie mysli zeby wprowadzic :| a wracajac do Javy - mechanizm bardzo fajny, z tym 'ale' ze istnieja -- RuntimeException, ktore .. nie sa sledzone, a zachowuja sie identycznie jak zwykle - leca w gore i rozwalaja wszystko po drodze. No niby wiadomo ze sa takie, ot np. OutOfMemory, ale pisze o tym, poniewaz juz widizalem kilka duzych programow (i w zasadzie coraz czesciej widze podobne), ktorych obsluga bledow byla w calosci oparta o dziedziczenie po RuntimeException.. chyba programistow irytuje ciagle pisanie throws i masa try/catch, i do czego to prowadzi to nie trzeba mowic:) ale to tutaj nie wina mechanizmu, tylko ludzi. zreszta przy w/w opisywanym xml+nazwaklasy+reflection to tez wina ludzi. doslownie tak im sie spodobalo ze wciskaja wszedzie i bez umiaru.. ok, koniec narzekania w tym watku

No, ja dorzucę jeszcze jedną bardzo istotną rzecz, którą Java wniosła w porównaniu do C/C++: system pakietów. Skończyło się piekło plików nagłówkowych oraz skomplikowanych systemów budowania projektu, a używanie przestrzeni nazw jest prostsze niż w C++...

no, akurat to sie nie zgodze.. dwie czy trzy reguly tworzenia .hpp jak np. dobry nawyk zeby dawac #pragma once albo #ifndef-define-endif i cos takiego jak pieklo naglowkow po prostu nie istnieje. w tej kwestii java nic praktycznie nie wprowadzila poza drobnym smaczkiem syntaktyki, w istocie to po prostu odwzorowanie namespace w katalog na dysku i nic wiecej [edit: OK, cos wprowadzila: import blah.* zamiast #include "blah/a.hpp" #include "blah/b.hpp".. ale szczerze mowiac coraz rzadziej widuje korzystanie z import-* bo szalenie potrafi czas kompilacji wydluzyc] usuniecie idei naglowkow mnie osobiscie w javie boli, poniewaz nie ma szans oddzielic interfejsu od implementacji - chcesz obejrzec klase, to sie pan przedzieraj przez kod.. (chyba ze Ci srodowisko zawija, ale nie o tym mowa) w javie jak chcesz komus pokazac interfejs ale nie chcesz pokazywac srodka - musisz i tak tworzyc nowy plik - interfejs - ktory jest w dodatku kompletnie oddzielnym typem :) wracajac do namespace-a-pakiet, c++ tutaj jest bardziej elastyczny, bo pozwala dopisywac nowe rzeczy do namespace'a w dowolnym miejscu, java - jedynie w danym katalogu.. bilans zyskow/straty z obu podejsc jest dyskusyjny i IMHO nieokreslalny

quetzalcoatl napisał(a)

no, akurat to sie nie zgodze.. dwie czy trzy reguly tworzenia .hpp jak np. dobry nawyk zeby dawac #pragma once albo #ifndef-define-endif i cos takiego jak pieklo naglowkow po prostu nie istnieje.

Wszystko pięknie. Schody zaczynają się, gdy "niechcący" musisz użyć dwóch bibliotek, które mają w nagłówkach zdefiniowane INACZEJ TO SAMO makro, a projekt ma np. 1 mln linii. Powodzenia w poprawianiu błędów kompilacji. Również fajne kwiatki powstają jak masz nagłówki niekompatybilne z binarnymi wersjami bibliotek (dotyczy głównie bibliotek instalowanych w systemie). Ogólnie jest to wszystko niepotrzebnie skomplikowane, ale jest to archaizm z czasów C, kiedy kompilatory nie rozumiały pojęcia "moduł". Później już jakoś tak zostało dla kompatybilności wstecz, jedynie okraszone takimi mechanizmami jak prekompilacja nagłówków czy przestrzenie nazw. W Pascalu, Javie, C#, Pythonie, Rubym zrobili to na nowo, moim zdaniem znacznie lepiej i prościej.

w tej kwestii java nic praktycznie nie wprowadzila poza drobnym smaczkiem syntaktyki, w istocie to po prostu odwzorowanie namespace w katalog na dysku i nic wiecej [edit: OK, cos wprowadzila: import blah.* zamiast #include "blah/a.hpp" #include "blah/b.hpp".. ale szczerze mowiac coraz rzadziej widuje korzystanie z import-* bo szalenie potrafi czas kompilacji wydluzyc] usuniecie idei naglowkow mnie osobiscie w javie boli, poniewaz nie ma szans oddzielic interfejsu od implementacji - chcesz obejrzec klase, to sie pan przedzieraj przez kod..

... albo lepiej zajrzyj do javadoc / doxygen / zainstaluj sobie dobre IDE.

Zresztą w C++ w realnych programach też w ten sposób nie ma szans. Sekcja private klasy musi być w pliku nagłówkowym. Zmieniasz implementację jakiś struktur danych i bęc... przekompilowuje Ci się 3/4 projektu, bo zmienił się jakiś głupi .hpp. Poza tym inline między modułami nie działa, jeśli implementacja jest poza nagłówkiem. Template'y też nie działają jak trzeba, jeśli nie są w nagłówkach. Ostatecznie prowadzi to do niezłego bałaganu - część funkcji zdefiniowana w nagłówkach, część w .cpp. Liczne przykłady w implementacji STLa, który jest zaimplementowany tylko jako nagłówki :D Uważasz, że STL to bubel?

wracajac do namespace-a-pakiet, c++ tutaj jest bardziej elastyczny, bo pozwala dopisywac nowe rzeczy do namespace'a w dowolnym miejscu,

tym samym umożliwiając jeszcze większy bałagan. Nie widzę powodu, by to się gdziekolwiek mogło przydać.

Krolik napisał(a)

Wszystko pięknie. Schody zaczynają się, gdy "niechcący" musisz użyć dwóch bibliotek, które mają w nagłówkach zdefiniowane INACZEJ TO SAMO makro, a projekt ma np. 1 mln linii.

argument nie w temacie, tu mowimy o preprocesorze a nie o C++. milion linii kodu predzej w Javie osiagniesz :) a przypne jeszcze jedna latke, propo bibliotek - probowales kiedys w Javie korzystac z dwoch bibliotek ktore implementuja te sama klase np. org.apache.logger.Logger? np. masz w projekcie dwie zaleznosci ktore wymagaja dwoch roznych wersji tej biblioteki. pieknie classloader wariuje. no, kazdy odpowie ze mozna przeciez uzyc odrebnego classloadera. tylko jak tak odpowie, to chyba nie probowal nigdy rzutowac instancji Object otrzymanej z innego classloadera na cokolwiek..

Krolik napisał(a)

Powodzenia w poprawianiu błędów kompilacji. Również fajne kwiatki powstają jak masz nagłówki niekompatybilne z binarnymi wersjami bibliotek (dotyczy głównie bibliotek instalowanych w systemie)

pff.. przyganial kociol garnkowi, jak masz JRE1.4 odpal mi program z JDK1.6. A wole szukanie i latanie C++owego bledu kompilacji niz szukanie i latanie runtimeowego bledu Javy

Krolik napisał(a)

Ogólnie jest to wszystko niepotrzebnie skomplikowane, ale jest to archaizm z czasów C, kiedy kompilatory nie rozumiały pojęcia "moduł". Później już jakoś tak zostało dla kompatybilności wstecz, jedynie okraszone takimi mechanizmami jak prekompilacja nagłówków czy przestrzenie nazw. W Pascalu, Javie, C#, Pythonie, Rubym zrobili to na nowo, moim zdaniem znacznie lepiej i prościej.

wrecz przeciwnie - to jest archaizm z czasow kompilatorow ktore ZNALY pojecie MODUL. i ponownie mowie: pakiet Javy od namespace'a C++ niczym sie nie rozni

Krolik napisał(a)

usuniecie idei naglowkow mnie osobiscie w javie boli, poniewaz nie ma szans oddzielic interfejsu od implementacji - chcesz obejrzec klase, to sie pan przedzieraj przez kod..
... albo lepiej zajrzyj do javadoc / doxygen / zainstaluj sobie dobre IDE.

i tu znowu mieszasz popularne narzedzia z jezykiem. mowimy o jezyku, nie o narzedziach. a przynajmniej ja mowie..

Krolik napisał(a)

Zresztą w C++ w realnych programach też w ten sposób nie ma szans. Sekcja private klasy musi być w pliku nagłówkowym. Zmieniasz implementację jakiś struktur danych i bęc... przekompilowuje Ci się 3/4 projektu, bo zmienił się jakiś głupi .hpp.

tak, to jest bol towarzyszacy bledom projektowym i rozrzutnemu #include'owania wszystkiego co popadnie. zreszta - Java tez tak ma. dawaj wszedzie import blah.* i bediesz mial +30% czasu kompilacji. poza tym Java ma ten sam problem ze zmiana kodu i rekompilacja -- dajmy na to masz klase A{public void func1(); private void func2();} oraz klase B korzystajaca z A. kompilujesz je obie. jest super. a teraz w klasie A usuwasz metode func2. i sie okazuje ze klase B tez musisz przekompilowac. identycznie jak w C++

Krolik napisał(a)

Poza tym inline między modułami nie działa, jeśli implementacja jest poza nagłówkiem

prawda, to wynika wprost ze specyfiki inlineingu... a w Javie nie ma czegos takiego jak inline w ogole. i co, to moze lepiej? :)

Krolik napisał(a)

Template'y też nie działają jak trzeba, jeśli nie są w nagłówkach. Ostatecznie prowadzi to do niezłego bałaganu - część funkcji zdefiniowana w nagłówkach, część w .cpp. Liczne przykłady w implementacji STLa, który jest zaimplementowany tylko jako nagłówki :D Uważasz, że STL to bubel?

czesciowo prawda i nie uwazam. tutaj dopowiem trzy rzeczy:

• template dzialaja szalenie poprawnie
• generics javy sie nie umywaja, wystarczy wspomniec o mechanizmie 'type erasure', polecam poczytac, mozna sie zdziwic
• obecnie co do templateow poleca sie wrecz sposob pisania tylko w .hpp bez uzycia .cpp, templatey z STL to przedszkole, sporz na boost::mpl. ciekawa lektura, polecam
• pisanie template w samym tylko .hpp wynika z ... "lenistwa" tworcow kompilatorow. w standardzie C++ od dawna jest mowa o modulach i statycznych bibliotekach template'ow, czyli o defacto tym co wszyscy by chcieli miec - interfejs template w .hpp, kod template w .cpp, i kompilujemy .cpp i potem template juz jest.. ale utworzenie czegos takiego jest mozliwe - kompilator Comeau posiada to! cala reszta po prostu sie leni, ale moze juz nie dlugo

Krolik napisał(a)

wracajac do namespace-a-pakiet, c++ tutaj jest bardziej elastyczny, bo pozwala dopisywac nowe rzeczy do namespace'a w dowolnym miejscu,

tym samym umożliwiając jeszcze większy bałagan. Nie widzę powodu, by to się gdziekolwiek mogło przydać.

aa, oczywiscie ze mozna zrobic balagan. jak masz mlotek w rece to mozesz wbic gwozdz ale takze sobie huknac nim w glowe. wszystko zalezy od tego czy umiejetnie stosujesz to co jest oferowane. a mozna to zastosowac ot, paradoksalnie, do zwiekszenia hermetyzacji oraz rozszerzalnosci raz napisanego kodu. hermetyzacji - przy pomocy mechanizmu friend, zerknij np. na boost::serialization oraz jego definicje save/load. i to z kolei tez od razu jest przyklad rozszerzalnosci - rozszerza sie implementacje boost::serialization o obsluge nowych typow. bez definiowania wspolnego interfejsu bazowego Serializable, narzucania wirtualnosci, uzywania Reflection itede

Witam

Przez ostatnie kilka postów toczy się dyskusja o tym czy Java czy C++ jest lepszym językiem programowania. Przeciez autor nie pytał się ,który język jest najlepszy ale który jest językiem z przyszłością:). Wydaje mi się ,że głównym kryterium nie ejst tutaj fakt czy dany jezyk ma takie czy inne mechanizmy ale czy jest w stanie na "siebie zarobić ". W przypadku Javy mamy do wyboru masę lepszych, gorszych, darmowych czy komercyjnych narzędzi ,które znacznie przyśpieszają i upraszczaja tworzenie aplikacji. Z językiem C++ ostatni kontakt miałem łąnych pare lat temu dlatego chciałbym się zapytać jak an dzień dzisiejszy przy pomocy tej technologii wyglądałoby stworzenie aplikacji korporacyjnej (webowej czy niewebowej) czy są jakieś frameworki wspomagajace ten proces? I w końcu jak by się miały koszty tworzenia i co wazniejsze utrzymania przykłądowej aplikacji w c++ i javie.

pozdrawiam

ano, tak to jest jak sie 2 fanatykow zaczyna sprzeczac :)

spolecznosc C++ niestety jest wciaz silnie sfragmentowana i wszystkie fajne rzeczy sa zazwyczaj komercyjne, maja kod zamkniety, i sa kiepsko udokumentowane przez to, ale odkad pojawil sie opensource to juz jest troche lepiej.. frameworki sa glownie specjalistyczne, np ace/tao/ciao do aplikacji rozproszonych czy tez gtk/qt czy m$owe atl do tworzenia ui. bazodanowe rowniez sa, w tej chwili nie pamietam, rzadko korzystam. serwerow aplikacji na razie niestety nie ma, ale pare prob juz widzialem. ogolnie, koszty utrzymania beda nizsze po stronie Javy bo obecnie jest baza gotowego/darmowego/otwartego kodu bardziej rozbudowana przez co wszystko sie samo napedza (w sensie rozwoju). jesli chodzi o gotowe biblioteki, c++ jest w tyle o jakies 5-7 lat

Nie jestem fanatykiem Javy, ale mówiliśmy o tym, co wniosła nowego Java do programowania w porównaniu z poprzednim mainstreamowym językiem - czyli C++. Można się spierać czy to, co wniosła, jest naprawdę nowe i dobre, czy nie, ale fakt pozostaje faktem, że jest to obecnie najpopularniejszy język programowania dużych systemów biznesowych i sprawdza się w tym zastosowaniu dużo lepiej niż C++. Do tego rozwija się bardzo dynamicznie i raczej nic nie wskazuje na to, żeby C# miał ją zdetronizować, a już na pewno nie C++.

C++ na pewno nie jest językiem przyszłości. C++ daje bardzo duże możliwości tylko niestety nie tam gdzie jest to potrzebne twórcom aplikacji. Na co mi rozbudowane szablony, które przydają się raz na tysiąc razy, kiedy nie ma dobrego zarządzania pamięcią przyspieszającego rozwój aplikacji o 30-50%? Po co mi wielodziedziczenie (we wszystkich projektach w C++ użyłem może ze 2 razy), kiedy napisanie frameworku ORM w C++ graniczy z niemożliwością z braku reflection?

Zresztą jeśli popatrzeć na wszystko z perspektywy dłuższego czasu to i tak niczego nowego nie wymyślono - wszystko miał LISP 30 lat temu :p.

alez, ja nigdzie nie napisalem ze jestes fanatykiem Javy :) napisalem jedyne ze ja jestem - C++'a :) Tobie typu fanatyzmu nie nadalem, ale przyjmuje ze jakis-tam masz, bo jeszcze mnie czytasz i odpisujesz:) tak w ogole to milo mi szalenie sie rozmawia tylko moze zeczywiscie offtopik-gigant wyszedl..

ale oprzec sie nie moge ;)

mm.. pokolei: zarzadzanie pamiecia w C++ jest bardzo dobre. GC jest nie potrzebny, wystarczy uzywac czegos pokroju boost::scoped_ptr i boost::shared_ptr (defacto template), zero problemow z zarzadzaniem pamiecia, pamietaniem kto jest ownerem i kto powinien zwalniac, zero problemow z przekazywaniem ownershipstwa, zero problemow z GC wlaczajacym sie w najgorszym momencie. jedyne co trzeba, to uzywac shared_ptr<COS> zamiast COS*..

template przydaja sie szalenie, po to aby wyeliminowac niepotrzebny natlok interfejsow i wirtualnosci, a takze zeby tworzyc kod latwy w reuzyciu. a takze do innych celow jakie sie wielu slabiej C++ znajacym nie snilo, a w innych jezykach sa -> boost::spirit, boost::lambda, boost::statechart, czy tez "flagowy" boost::mpl, ktorego niestety jeszcze nie mialem czasu przejrzec, ale to co juz widzialem bylo dosc imponujace -- np. cos jak reflection, tylko w czasie kompilacji, pozwalajace np. warunkowo kompilowac klase z takim-a-nie-innym kodem, jesli inna klasa ma zdefiniowana taka-a-taka metode. polacz to z dziedziczeniem i otrzymujesz mechanizm ze klasa bazowa automatycznie dostosowuje swoja implementacje do child'a i jego wymagan.. a mozna wiecej, duzo wiecej, tak jak mowie w mpl jestem zielony (jeszcze:)

reflection: jest szalenie wygodne, ale nie mozna go uzywac nonstop i do wszystkiego, traci sie wtedy cala dobroc typizacji w czasie kompilacji i trzeba wzsystko recznie sprawdzac i zabezpieczac dynamiczna kontrola typow... reflection w C++ mozna stosowac, ale jest to bardzo upierdliwe, bo trzeba samemu opisywac klase metadanymi albo przepuszac klase tuz przed kompilacja przez parser ktory te metadane automatycznie doda. tak wiec upierdliwe, ale mozliwe, a nawet moze byc automatyczne.

multipleiheritance? najwyrazniej za malo zroznicowane byy te projekty, lub tez nie uzywales nic z nowinek takich jak np. boost :) w javie pseudo-MI stosuje sie co chwila, patrz na interfejsy. czymze to sie rozni? tylko tym, ze MI zezwala, aby w kazdym byly takze pola definiowane. ile razy widziales w javie interfejs ktory musiales zaimplementowac, a ktory defacto skladal sie tylko z setterow/getterow? a gdyby w javie bylo pelne MI, moglbys zamiast tego miec pola. wiele osob psioczy na MI bo 'wprowadza zamieszanie' i rzekomo nie wiadomo co jest od czego.. rzczywiscie, jest jeden bardzo specyficzny przypadek gdzie trudno jest dojsc czy dana rzecz pochodzi z parentaA czy parentaB, ale to najczesciej pojawia sie przy bledzie projektowym... a do czego sie uzywa MI - zajrzyj jak sie pisze programy na komorki z Symbianem (nie mowie o Javowych, tylko o natywnym). cale API jest w C++ i opiera sie na architekturze klient/serwer, gdzie kliencka czesc API jest do "wmixowywana" do Twoich klas wlasnie poprzez MI. wygodniejszego i bardziej hermetyzujacego sposobu na dostarczenie API autentycznie nie widzialem jeszcze.

C++ mogloby byc jezykiem przyszlosci, jesli w koncu poszczegolne wieksze grupy zaczna wspolpracowac ze soba. wszystko, bez wyjatku co ma Java jest do napisania w C++. a przyspieszenie rozwoju systemow nie zalezy od jezyka, tylko od frameworkow i bibliotek jakie sa dostepne. durne reflection z ktorym ciagle rozne grupy kombinuja, jest do napisania jako automat pomiedzy pisaniem kodu a kompilacja.. ale jakos nikt nie moze go doprowadzic do konca, i mimo dorbych wynikow zatrzymuje sie w 3/4 implemetnacji .. bo grupa robocza projekt wlasciwy skonczyla, a inna nie chce ciagnac narzedzia zaczetego przez innych <sciana> troche solidarnosci by wystarczylo.. a poki jej nie bedzie, to rzeczywiscie mozna o C++ zapomniec na hm.. no przynajmniej az Sun zacznie kazac sobei placic za uzywanie JRE :)

edit: przeczytawaszy to, mam wrazenie ze to napisalem juz przynajmniej raz wczesniej, i ze to co piszesz tez juz bylo miedzy liniami.. co by znaczylo ze obu stronom brak argumentow poza-bibliotecznych i poza-finansowych.. i chyba po malu czas wiec konczyc offtopika :)

A może zamiast gdybać lepiej spojrzeć na fakty? Programista Javy jest dużo wydajniejszy niż programista C++. To jest fakt. Co z tego, że C++ ma potencjał skoro za plecami nie stoi Sun, Microsoft czy innego gigant, który by zadbał o rozwój? Mnóstwo języków ma spory potencjał, większy nawet niż C++ a i tak nigdy nie przebiją się do mainstreamu bo brakuje bibliotek/framewroków i do tego nikt do końca nie przetestował jak się taki język sprawdza w praktyce.

dużo wydajniejszy niż programista C++ - w obecnej chwili, niestety, juz tak
Mnóstwo języków ma (..) - spory - wiele, wiekszy - niewiele
a i tak nigdy nie przebiją się do mainstreamu - prawda, pisalem o tym miedzy wierszami
do tego nikt do końca nie przetestował - w kontekscie c/c++ zostal przetestowany doglebnie, o wynikach wydaje mi sie ze tez wspominalem

A wprowadzę zamęt w dyskusji... [browar] uważam, że Delphi jest super miałem okazje pracować w C , C++, i VB. Delphi bardzo mi się podoba i naprawdę wiele można w nim zrobić. Co prawda jestem geodetą i programowania nauczyłem się sam, "nie licząc wydziału EiT na Polibudzie w Poznaniu", i uważam, wiem z praktyki, że Delphi daje możliwości do zarabiania i SKUTECZNEGO programowania. Java na razie daje możliwość efektywnego wykorzystania mobilnych urządzeń ale zaraz się to tak rozwinie, że OPTYMALIZACJA stanie się swojego rodzaju DZIEŁEM SZTUKI a nie koniecznością.....

http://www.tiobe.com/tpci.htm - ranking popularności języków.