Fundacja Eclipse wyszła naprzeciw programistom borykającym się z problemem tworzenia czytelnego kodu. Wprowadziła na rynek nowy język programowania, który ma być ich rozwiązaniem. Twórcy Xtend zapewniają, że pomoże on również uzupełnić biblioteki Javy o funkcje które są konieczne, ale nie zawarte w pakiecie.
Xtend został udostępniony w formie plug-inów do środowiska programistycznego IDE wyposażonego w JDT. Według twórców, kompilacja Xtend „sprowadza jego kod do czytelnego kodu języka Java”. Nie oznacza to, że nie będzie już takich udogodnień IDE jak kolorowanie składni czy uzupełnianie treści. Programiści nadal będą mogli z nich korzystać.
Jednym z istotnych uproszczeń jest intuicyjny dostęp do pól obiektów. Biblioteka Xtend opisywana jest jako „cienka warstwa nakładana na JDK”.
Xtend ma szansę na sukces. Przyszłość należy do prostych i intuicyjnych rozwiązań.
Więcej dodatkowych warstw! Będzie szybciej działać!
Tak, programujmy w kodzie maszynowym, będzie bardzo szybko.
Jak się nie ma argumentów, to trzeba rzucić populistyczne hasło związane ze skrajnością…
PO jakoś to wychodzi, ale odbiorców mają na niskim poziomie intelektualnym.
Na technicznym serwisie to nie przejdzie…
Nie napisałem prawdy? Od razu będziesz mieć plik wykonywalny, bez tracenia czasu na jakieś pierdoły związane z dodatkowymi poziomami abstrakcji jak kompilacja. Zobacz jakie panowanie nad sprzętem i systemem operacyjnym, C++ od razu wysiada. Powinieneś rozważyć taką przesiadkę.
A poważnie odnosząc się do treści artykułu Xtend jest dodatkowym przeźroczystym poziomem abstrakcji, który znika po translacji do plików Java. A że przy okazji uprzyjemnia i przyśpiesza programowanie w porównaniu do zwykłej Javy to już duża korzyść, nawet jeśli dobry programista Javy mógłby napisać to trochę lepiej. Przeważnie bezwzględna szybkość nie jest istotna, wystarczy, że program działa dostatecznie szybko.
> Przyszłość należy do prostych i intuicyjnych rozwiązań.
BASIC wraca do łask? Programowanie klient-serwer w LOGO? Super!
Raczej C++ – szybkie, rozbudowane składniowo (np. wielokrotne dziedziczenie, którego żaden inny liczący się język nie wspiera), przenośne i lekkie.
Wymaga tylko jednego: porządnego projektanta dla budowanego systemu, bo DA SIĘ w C++ zaprojektować go źle. Zresztą jak i w Javie, tylko tam nie da się popełniać podstawowych błędów, ale kosztem ograniczonych możliwości.
Dlatego ciency projektanci i programiści wolą Javę/.net.
@o_o
A ty urwałeś się z choinki? Uważasz, że za sprawą cudownego języka (przez Ciebie przytaczany c++) programy będą same się pisać, będą z definicji szybkie, przenośne i lekkie i może jeszcze powiesz, że bezbłędne? No sory, ale chyba chyba trochę pofantazjowałeś… Teraz podstaw pod c++ i jave dowolną inną nazwę języka programowania a otrzymasz ten sam sens (a dokładniej brak sensu) w Twojej wypowiedzi. Pamiętaj, że język programowania to tylko narzędzie, za pomocą narzędzi można coś zbudować dobrego jak i coś mało pożytecznego. Nie ma sensu przypisywać językowi (javie lub c++) jakichś cudownych właściwości, bo i tak używają ich zwykli popełniający błędy ludzie, którzy mają raz lepsze a raz gorsze dni.
rozwiń myśl proszę, bo mam wrażenie, że Ty jesteś cienki jednak jesteś Ty 🙂 Jakie są te sławetne ograniczone możliwości? 🙂
Masochiści wybiorą multiskomplikowany język o wątpliwej przyszłości, inni do swoich celów wybiorą C, Pythona czy Javę 🙂
"Jakie są te sławetne ograniczone możliwości? 🙂 "
Choćby brak dostępu do wielu funkcji systemu operacyjnego, szczególnie do tych dostępnych w jednym, a niedostępnych w innym systemie.
Jaki brak? JNI nie ma czy co?
Gdy piszę w C, to w celu zrealizowania określonych funkcjonalności nie muszę tworzyć fragmentów w Javie. Natomiast tworząc w Javie – czasem trzeba C użyć. Wg mnie jak najbardziej jest to ograniczenie.
Zamień C z ASM a Jave z C w twim tekscie to zobaczysz swoj rozmiar glupoty
Mam system operacyjny, bibliotekę standardową i bibliotekę dostarczaną przez kompilator i dzięki temu asemblera mogę nie używać jeśli nie chcę. Sytuacja Java – JNI jest inna.
JNI może używać dowolnego języka, do którego kompilator potrafi wygenerować odpowiednią bibliotekę łączoną dynamicznie. Są bindingi do Delphi, Haskella itp.
"np. wielokrotne dziedziczenie, którego żaden inny liczący się język nie wspiera"
Kłamiesz. Choćby Java, Python, Ruby i Scala mają wielokrotne dziedziczenie lepiej zrealizowane niż C++, tylko Ty o tym nic nie wiesz, po poza świat swojego ukochanego C++ nie wyjrzysz.
"szybkie"
Jasne, na maszynce z jednym rdzeniem może. Tylko era tych maszynek się powoli kończy. Kilka razy już widziałem jak system po przepisaniu z C++ na Javę skopał tyłek oryginalnej wersji i to mi wystarczy.
"przenośne"
Jak ograniczysz się do pewnego małego podzbioru języka i biblioteki standardowej, to pewnie tak. Jak dołączysz cokolwiek zewnętrznego to nagle okazuje się, że przenośność ogranicza się do trzech najpopularniejszych systemów, a jak dołączysz kilka kolejnych bibliotek, to zwykle nawet na jednym w wielu wersjach są kłopoty.
"lekkie"
Szczególnie STL i Boost wrzucający 100 kopii tego samego kodu do pliku wynikowego.
"Dlatego ciency projektanci i programiści wolą Javę/.net"
Pewnie jacyś ciency programiści wolą Javę/.NET, podobnie jak jacyś ciency programiści wolą C++, bo mają czubek nosa powyżej czubka głowy. Generalnie w językach mainstreamowych średni poziom jest kiepski, bo są to języki obowiązkowe na wielu uczelniach, czyli każdy "coś tam umie" zarówno z C++ jak i Javy.
Implementować w wydajny sposób w C++ jest bardzo trudno – wszędzie czają się pułapki, a składnia jest dużo trudniejsza niż w Java. Nawet w C jest trudno zrobić optymalnie o wiele prostsze rzeczy – można się wydajnościowo wywalić na nadużywaniu malloc() i free(), ale można i wycisnąć bardzo dużo.
Niezależnie od tego, Java okazuje się statystycznie szybsza – potrafi przecież optymalizować w locie kod maszynowy (do pewnego stopnia oczywiście), a poprawne wzorce są rozpropagowane i używane przez deweloperów.
Czasami dla śmiechu mówiłem, że Java to język dla cieniasów (pedziów), w porównaniu do C++/C implementowanym na rożnych platformach i architekturach, ale nie jest to prawda, bo w Java pisze się systemy o większej złożoności w tym samym czasie niż te pisane w C/C++, więc trudność jest ta sama. Przez 8 lat pisałem w C/C++ (na różne platformy, w różnych narzędziach), by przesiąść się na Java (czasami wracając do C++), więc wiem co mówię. C++ bardzo lubię, ale nie jest to jeżyk dla biznesu i implementacji usług.
To że Java jest statystycznie szybsza to oczywista nieprawda. Ja na przykład nie znam ANI JEDNEGO szybkiego programu desktopowego napisanego w Javie, natomiast jest takich wiele napisanych w C lub C++. Twierdzenie, że jest szybsza, bo kompilacja w locie… to zaklinanie rzeczywistości.
A wyrokowanie na temat wydajności javy na podstawie programów desktopowych to jak puszczenie bąka w towarzystwie.
To zawyrokujmy na podstawie np. silników baz danych, albo serwerów WWW, poczty,… Czegokolwiek, byle w miare złożonego, oraz powszechnie dostępnego. Nie interesują mnie programy, których szybkości działania nie będę mógł sam obejrzeć (bo to np. program do użycia wewnątrz tylko jednej firmy i nie mam do niego dostępu).
Wymienisz z nazwy jakieś szybkie Javowe programy?
"Wymienisz z nazwy jakieś szybkie Javowe programy?"
Z tych co widze regularnie to na pewno szybkie sa Tomcat, Cassandra, OpenGrok,
IntelliJ, javac. Pewnie sporo os-fanow doda, ze sporo szybkiego towaru w Androidzie
jest sklepanego w Javie. No i pewnie co 4-ty serwis WWW ktorego uzywasz ma pod spodem Jave.
Amazon, Facebook i Twitter mają swoje silniki baz danych napisane w czystej Javie (oops, Twitter w Scali, ale to też Java). Są opensource, więc można sobie samemu sprawdzić. Wydaje mi się, że to w zupełności wystarczająca rekomendacja.
Wśród silników SQLowych z kolei Javowe H2 i HSQLDB są znacznie szybsze niż MySQL i PostgreSQL. Też są opensource, też możesz sobie sprawdzić.
Odnośnie serwerów WWW, to z szybkich jest chociażby Jetty, Netty i Tomcat. Netty jest bardzo zbliżone do Nginx (zarówno prostotą jak i wydajnością). Tomcat z kolei jest bardziej funkcjonalny, wydajnością nie ustępuje Apache HTTPD.
Java jest wystarczająco szybka, że wiele poważnych instytucji używa jej w HPC (High Performance Computing) np. CERN, a niektórzy nawet w systemach tradingowych.
H2 i SQLDB nie mają właściwości ACID, więc nawet jeśli są stworzone w mniej wydajnym języku, mają prawo być szybsze o MySQL i PostgreSQL, które właściwości ACID wykazują.
H2 ma lepsze ACID niż PostgreSQL (pełne serializable kontra snapshot serializable – snapshot serializable jest o jedno "oczko" słabsze).
A to ciekawe. Najpierw piszesz, że kompilacja w locie to zaklinanie rzeczywistości, a potem stawiasz warunki na dostępność programu. To ja ci powiem tak: pokaż mi aplikację w C++, która ma złote sznurki po bokach i jak je pociągniesz to słychać takie "MUUUU".
To jest odpowiedź na twoim poziomie.
Zdefiniuj co to znaczy "szybki program desktopowy". Bo tak to sobie można długo dyskutować, jak każdy ma inną definicję. Dla mnie Eclipse czy IntelliJ IDEA, choć są duże w sensie funkcjonalności i długo się włączają (5-10 sekund), są bardzo szybkimi programami. A np. taki OpenOffice Impress napisany w C++ nie jest dla mnie szybkim programem bo się zacina przy zwykłym pisaniu tekstu w ramce tekstowej. I to że startuje o 2s szybciej niż Eclipse nie ma żadnego znaczenia.
To tylko dowód na to, że w każdym języku można napisać powolną aplikację. Porównaj szybkość Visual Studio i Eclipse. Niebo, a ziemia ;).
Nie zauważyłem znacznej różnicy w wydajności. Eclipse wstaje wolniej i to.. tyle. Ale co z tego, jak go odpalam raz na dzień? Za to Eclipse kompiluje Javę szybciej niż VS kompiluje C++. Znacznie szybciej. Tak gdzieś ze 20x-100x. Menu i okienka wyskakują tak samo szybko w obu tj. natychmiast. RAMu zżerają na tyle mało, że mogę mieć odpalone 4 instancje równolegle, tylko po co?
Widać nie każdy ma na tyle mocny sprzęt, żeby móc sobie pozwolić na Eclipse ;). Nie mówię, że u Ciebie jest jakaś różnica. Wiem, że u mnie 4 instancje to od 3 za dużo.
Co do kompilacji – bez komentarza. Porównujesz dwie całkiem różne operacje.
Eclipse potrzebuje ok. 512 MB wolnego RAMu do pracy z dużym projektem. 4 GB RAMu do laptopa kosztuje 80 zł.
Widać za bardzo przywykłem do vima, żeby docenić "szybkość" pracy z Eclipse. Z którym nie pracuje mi się komfortowo (a mam sporo więcej niż 512MB).
Może windows+vs jest tak samo powolne jak eclipse, ale porównaj to z GUI stworzonym np. w Qt, to szczęka ci opadnie i raz na zawsze uaktualnisz sobie znaczenie słowa "szybkość".
Czasy aplikacji na desktopy minęły. Wszyscy idą w WWW. Czy w Qt da radę zrobić coś na wzór Java web Start? Nie. Czy w Qt da rade wykorzystac hibernate i zrobic gui w HTML? Nie. Więc?
Gui , na widok ktorego szczeka opada robi sie dzis w Javie (Android)
"Kilka razy już widziałem jak system po przepisaniu z C++ na Javę skopał tyłek oryginalnej wersji i to mi wystarczy."
Prawdopodobnie robili to ludzie, którzy mieli już większe doświadczenie w danej działce, niż osoby piszące pierwotną wersję. Dlatego udało im się kolejną wersję zrobić lepiej. Gdyby zrobili w C++ mogliby uzyskać jeszcze szybszy.
Niektórzy mają problem z ogarnięciem, że w javie nie jest możliwe napisanie aplikacji szybszej niż w C/C++. Zwyczajnie takiej możliwości nie ma.
Jest możliwe. Wystarczy wykorzystywać intensywnie operacje, które w Javie są znacznie szybsze niż w C++: alokacja na stercie, synchronizacja wątków, wywołania polimorficzne, wywołania między modułami ładowanymi dynamicznie.
Nie. To zwyczajnie technicznie nie jest możliwe. Java może być co najwyżej równie szybka co C/C++. Wszakże w czym jest napisana maszyna wirtualna javy? HotSpot bodajrze w C++, mylę się?
Mylisz się. Pisanie w danym języku nie oznacza zrobienia Hello Worlda, tylko użycie różnych jego możliwości. W przypadku C++ będzie to np. dziedziczenie i RTTI. Różne rodzaje rzutowania. Kolekcje (STL). W javie są odpowiedniki. Napisz programy wykorzystujące te cechy w obu językach i porównaj czas wykonania. Java wygra.
Dotarło, czy jesteś odporny na fakty?
Nawet nie trzeba zaawansowanych funkcji.
string.h przegrywa wydajnoscia z java.lang.String i to sromotnie.
Napisz jakikolwiek kod w javie. Kompilujesz go do bytecodu. Odpalasz na maszynie wirtualnej napisanej w C/C++. Nie ma możliwości, żeby cokolwiek uruchomionego na tej maszynie przekroczyło wydajność kodu napisanego w C/C++.
Jesteś odporny na fakty?
"Jesteś odporny na fakty?"
Jestes odporny na wiedze? As tez jest napisany w C.
A tu masz kawalek w pythonie ktory generuje binarke w assemblerze
robiaca inc %eax, "print chr(0x40)". Zaczynasz juz lapac roznice miedzy
interpretacja a kompilacja?
Doskonale łapię tą różnicę.
Zrozum – nie osiągniesz wyższej wydajności w Javie niż w C++. Zawsze mogę te same mechanizmy, które oferuje Java zaimplementować pisząc aplikację w C++. DOKŁADNIE te same mechanizmy – jeśli będzie to konieczne.
Więc Java może być co najwyżej tak samo wydajna jak C++. Jak pokazuje praktyka – zwykle jest znacząco mniej wydajna.
Jeszcze szybszy jest assembler, czemu w nim nie pisać?
Bardzo dobry programista zaimplementuje, prawie zawsze bardziej wydajniej algorytm. Ale przeciętny może już to zrobić lepiej w Javie, samodzielne napisanie mechanizmów które mamy wbudowane w Javie to spory wydatek czasu. (A niestety najczęściej trzeba wszystko samemu pisać, bo albo brak bibliotek, albo dostępne biblioteki są słabe i pełne błędów). Do tego aby w C++ doprowadzić do używalności aplikację zużyje się kilka razy więcej roboczogodzin. Najczęściej zysk na wydajności jest niewielki, a w przypadku braku czasu lub umiejętności tylko traci się na wydajności.
"Zawsze mogę te same mechanizmy, które oferuje Java zaimplementować pisząc aplikację w C . DOKŁADNIE te same mechanizmy – jeśli będzie to konieczne."
To wróć jak zaimplementujesz dokładny, generacyjny garbage collector, **niepowodujący pauz** i **defragmentujący pamięć** i działający z heapami wielkości większej niż 384 GB dla Cpp. I bez narzucania czegokolwiek programistom – ma działać dla każdego prawidłowego, standardowego kodu Cpp . Taki jak ma Azul Zing dla Javy.
Albo łatwiejsze zadanie: zaimplementuj w C ORMa niewymagającego dodatkowej fazy preprocessingu kodu źródłowego. Ma w runtime brać dane do mapowania bezpośrednio z klas, jak to robi Hibernate.
Do czasu jak nie dowiesz się jak to zrobić nie postuj na forum, bo się tylko ośmieszasz.
@mikolajs
Zgadzam się w 100%. Nie lubię tylko kłamliwego stwierdzenia, że coś w Javie może być szybsze niż w C.
@wladca_kodu
Wykazałem, że nawet najlepszy kod w Javie nigdy nie prześcignie najlepszego możliwego rozwiązania danego problemu w C – więc zmieniasz temat na czas implementacji.
To całkowicie odmienna kwestia.
Wróć jak napiszesz ten superszybki kod w javie ;].
PS GC w javie lubi przyciąć w najmniej spodziewanym momencie – to jedna z zalet javy ;]?
Ale o co ci chodzi ? o te 5-10%?
Chłopcze nie ma czegos takiego jak najlepszy kod. Zmieniam procka na inny i juz twoj C jest w d…
5-10% Chyba sobie żartujesz.
Jasne, że można zmienić procka. Ale dla Javy czy .neta na desktop potrzebowałbyś superkomputer.
VS 2010 masz napisane w .NET i jakoś nie potrzebuje superkomputera. To samo AutoCad.
Owszem potrzebuje. Może ty jesteś przyzwyczajony do nieustannej powolnej pracy, ale ja nie. Zainstaluj w wolnym czasie Linuksa i zobacz jak działają porządne środowiska i interfejsy użytkownika.
Masz na mysli KDE? Tej kobyly w ogole nie idzie uzwac, a niby w C++ zrobione…
Używam Linuksa i wiem , ze Java dziala na nim szybciej niz na Windowsie, wiec?
no własnie, a pozniej z takim podejsciem program do glupich faktur potrzebuje 8 rdzeni i 16 ramu – brawo, brawo !
Jak sie programiki robi we Flashu…
Powiedziałbym, że jest odwrotnie: to C++ nie może być tak szybkie jak Java z tego banalnego powodu, że kompilator javy (JIT czyli ten bytecode -> native code) może robić optymalizacje na podstawie sposobu wykonywania programu podczas gdy w przypadku C++ optymalizacje mogą być wykonywane tylko na etapie kompilacji a kompilator ma zerową wiedzę o tym jakimi ścieżkami przebiegnie wykonanie. 😛
A tak w ogóle, to dyskusja na poziomie przedszkolaków opowiadających o tym, czyj ojciec jest silniejszy.
Chyba nie bardzo rozumiesz co PodskakujacyBalrog napisał.
Te wszystkie mechanizmy Javy wchodzące w skład JVM są napisane… w C. Więc zwyczajnie wykonanie bajtkodu przez program w C *NIE MOŻE* być szybsze niż sam program w C wykonujący te same operacje.
Jeśli wymyślisz jakikolwiek magiczny mechanizm Javy, to zawsze można go zaimplementować w tym programie w czystym C i nadal jego złożoność będzie mniejsza.
Oczywiście można się spierać, czy implementacja w czystym C pochłaniająca podobną ilość roboczogodzin będzie tak samo wydajna jak bytekod Javy odpalany przez JVM.
Praktyka jednak pokazuje, że Java przegrywa tu z C sromotnie, szczególnie w dziedzinie interfejsu użytkownika.
Jeśli chodzi o C++, to jest on porównywalny wydajnościowo do C. Różnice są niezauważalne, jeśli na skali umieścimy Javę czy .neta z kosmicznymi wartościami obniżania wydajności.
"Te wszystkie mechanizmy Javy wchodzące w skład JVM są napisane… w C. Więc zwyczajnie wykonanie bajtkodu przez program w C *NIE MOŻE* być szybsze niż sam program w C wykonujący te same operacje. "
Ty naprawde jestes idiota.
Jesli jedynie interpretujesz bytekod to to jest faktem.
Ale KOMPILAT MOZE BYC SZYBSZY nic C.
"Jeśli wymyślisz jakikolwiek magiczny mechanizm Javy, to zawsze można go zaimplementować w tym programie w czystym C i nadal jego złożoność będzie mniejsza."
Do tego jestes z tych idiotow, ktorzy uwazaja, ze wszystko da sie robic w C, dlaczego wiec nie w asm? Jeszcze szybciej.
"Wykazałem, że nawet najlepszy kod w Javie nigdy nie prześcignie najlepszego możliwego rozwiązania danego problemu w C – więc zmieniasz temat na czas implementacji."
Wykazales, ze nie masz pojecia o czym mowisz. Nie mozesz byc szybszy niz optymalny jezyk maszynowy. Natomiast nawet najbardziej optymalny kod C jest ograniczony wydajnoscia kodu wyprodukowanego przez kompilator (podobnie zreszta jak i w przypadku Javy).
U podstaw javy stoi maszyna wirtualna napisa w C++. Pisząc w C++ zawsze mogę napisać ją ponownie. Więc kod na niej bazujący nigdy nie będzie szybszy od kodu w C++. To oczywiste.
Na szczęście mój system jest napisany w C, środowisko w C++, więc nie potrzebuję superkomputera, żeby cieszyć oczy ładnym javowym rozwiązaniem ;).
Kolejne bzdury. Mój kod w Javie dzieki temu, że JIT potrafi skompilowac go w zależności na jakim procesorze uruchamiam zawsze będzie szybszy od twojego pisanego w c.
Jeżeli jest potrzeba, Java użyje MMX, gdy ty wymusisz użycie MMX, to twoje zabawki przestają działać na 90% procków (ARM) , im więcej ficzerów użyjesz w swoim C tym na mniejszej ilosci sprzetu bedzie dzialac. A moj programij zabangla na Pentium, 486, czy najnowszych 100core chińczykach.
Nie oszukuj sie, nie dosc ze mozesz moj kod przescignac pisac tylko na jeden procek, to jeszcze musisz zrobic doktorat by tego dokonac.
Oczywiście, że mogę uzyskać taki sam efekt. Np. napiszę wirtualną maszynę, która będzie kompilowała kod w zależności od tego na jakim procesorze zostanie uruchomiony. I napiszę ją w C/C++.
Z jakiego środowiska graficznego napisanego w javie można wygodnie korzystać? Tych szybkich napisanych w C++ jest całkiem sporo ;).
Zupełnie cie nie rozumiem. Procek 4core ma prawie kazdy. 24GB RAM to 600 PLN (tyle co procek). Dzis nie ma sie co szczypac, ze jakis program w javie zajmuje 100-200 MB, bo to jest zwyczajnie śmieszne. Komórki za chwile będą miały Tegrę 3 z 4 rdzeniami i minimum 2GB RAM.
Z jakiego środowiska graficznego napisanego w javie można wygodnie korzystać? A choćby z WindowsBuilder Pro , który bije nawet ten z Qt bo potrafi wygenerować kod pod akcje, a w Qt musisz pisac z palca by sygnaly powiazac (jak nie masz sygnalow to sie nie da graficznie powiazac do slotu).
WindowBuilder potrafi graficznie zbindowac kontrolki z polami klas. Jakis kreatorek C++ to potrafi?
"Zupełnie cie nie rozumiem. Procek 4core ma prawie kazdy. 24GB RAM to 600 PLN (tyle co procek)."
Co nie zmienia faktu, że nawet wtedy dobry kod w javie nie będzie szybszy od dobrego kodu w C/C++.
"Z jakiego środowiska graficznego napisanego w javie można wygodnie korzystać?"
Miałem na myśli środowisko graficzne dla użytkownika (KDE, GNOME, AERO), a nie dla developera aplikacji z GUI. Coś duzego, w javie, dla Kowalskiego. Gra? Program do obróbki grafiki?
Java dla developera jest przyjemna, nie jest dla odbiorcy. U którego program "muli" – choć może odnoszę takie wrażenie, gdyż nie mam 24GB ramu.
PS
QtDesigner też potrafi generować kod pod akcje – "przejdź do slotu" (jeśli to masz na myśli). Dla mnie marginalny problem, bo z niego nie korzystam ;].
Zrozum. Soft w Javie pisze się dla biznesu. Soft w C++ kolegom po znajomości. Koszt rozbudowy sprzętu jest żaden w porówaniu z kosztami optymalizacji i utrzymania C++. MS wyskakuje z jakims bajobongo i sie z tym swoim C++ kołami nakrywasz.
Można złośliwie powiedzeieć, że pisząc w C++ pisze się dla biedoty, której nie stać na wyciągnięcie 100$ na nowy procek i RAM. Ja sie od takich ludzi trzymam z daleka.
Poza tym wiekszosc backendu pod web to Java. Tu tez koszta sprzetu sa mikroskopijne w porownaniu z kosztami softu.
C++ umarł w czasach kiedy na PC zaczely wychodzic procki 2x core. To samo teraz z komórkami. Im wiecej RAMu i rdzeni w prockach w standardzie (pc ze sklepu nie dla idiotow) tym C++ sromotnie przegrywa.
To, że C++ bierze w łeb widać było po wszystkich testach z udziałem Bulldozera, gdzie żaden soft pisany w tym gownianym jezyku nie radzil sobie z 8 rdzeniami.
"Zrozum. Soft w Javie pisze się dla biznesu. Soft w C++ kolegom po znajomości."
W biznesie o wyborze produktu często decyduje ten, który go wcale używał nie będzie i nie będzie mu przeszkadzało jak beznadziejnie powolny program otrzyma.
Koledze po znajomości natomiast robi się program tak, żeby nadawał się do wygodnego używania, albo nie robi się wcale.
Java ma jedną główną przewagę: REKLAMĘ! Wszystkim producentom sprzętu opłaca się promocja rozwiązań niewydajnych, bo dzięki temu sprzedadzą droższe serwery.
Twierdzenia o nie-wykorzystywaniu wielu rdzeni przez C++ za to wykorzystywaniu przez inne to bzdury. Wiele dziedzin po prostu nie chce dać się podzielić na wątki i to niezależnie od użytego języka.
Patrzysz od strony developera – ok, java jest dla Ciebie wygodna, nie wymaga myślenia, kodzi się szybko – zgadzam się.
Ja patrzę od strony użytkownika. Nie podoba mi się, że na sprzęcie na którym każda super gra napisana w C++ pójdzie bezproblemowo – mała gierka w javie muli :).
"Można złośliwie powiedzeieć, że pisząc w C++ pisze się dla biedoty, której nie stać na wyciągnięcie 100$ na nowy procek i RAM. Ja sie od takich ludzi trzymam z daleka. "
Trochę się zagalopowałeś 😉
Pokaż mi która firma na zwraca uwagi na koszty? Wiele firm ma jakieś komputery, które nie koniecznie chce wymieniać na nowsze, a ulepszyć się specjalnie nie da, więc musiałoby im bardzo zależeć na nowym sofcie aby kupić nowe komputery. Do tego trzeba wymienić starego XP i przeszkolić ludzi.
Nie pisz, ani nigdy nie mów jako programista, że nie chce ci się napisać wydajny soft i niech lepiej sobie ktoś kupi lepszy sprzęt, bo wiele osób może źle to zrozumieć.
Co innego gdy mówisz firmie, mogę napisać soft za 500 000 w Javie, będzie gotowy za 10 miesięcy, jednak wymaga 2GB RAM, albo mogę zrobić za 1000 000 w ciągu 1,5 roku i wtedy nie musicie kupować nowego RAM. Wtedy firma sobie policzy i powie: OK bierzemy w Javie. I tak to najczęściej wygląda. Każda normalna firma będzie żałować tych 100$ na nowy procek, bo jest od tego aby zarabiać.
"Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of JVM."
Trochę przekręciłem cytat, ale jakoś świetnie mi tu pasowało 🙂
Zdajesz sobie sprawę z tego, że jak przepiszesz JVM w C++, to wyjściowy program będziesz musiał napisać w Javie? 🙂
Najpopularniejsza JVM już jest napisana w C++. A pisać na niej można m.in w pythonie (nawet na jvm nie jest się ograniczonym do javy).
Od strony C++ można więc zaimplementować dowolny potrzebny mechanizm jvm na potrzeby konkretnej aplikacji – wszystko w C++.
Tak, na JVM można uruchomić Pythona. Ale nie C++, przynajmniej nie w obecnym kształcie.
Na .NET można i C++, więc mogła by powstać wersja podobna na JVM, tyle, że poza nieco inną składnią byłaby dalej Javą 🙂
A widziałeś to dotnetowe C++? No właśnie.
Widziałem, ale wolałem używać C# 😉
dotnetowe C++/CLI ma kosmiczną zaletę, można mieszać w jednym pliku źródłowym kod zarządzany z natywnym – zupełnie inna bajka niż JNI.
Jest to zaleta, nie zmienia to faktu jednak, że aniC++/CLI, ani Managed C++ to nie jest "zwykłe" C++.
Nic nie wykazałeś. Java jest językiem tak samo kompilowanym jak C – do kodu maszynowego. Java może być szybsza, jeśli kompilator Javy zastosuje lepsze optymalizacje niż kompilator C. I na odwrót. Tu jest pełna symetria. Jedyna różnica jest taka że te kompilatory są mocne w różnych rzeczach – np. Java lepiej optymalizuje kod wielowątkowy, którego kompilator C w ogóle nie umie zoptymalizować, natomiast dobre kompilatory C potrafią robić fajniejsze rzeczy z upychaniem różnych struktur tak by się w cache L1 mieściły. Kumasz?
A coś takiego jak najlepsze możliwe rozwiązanie (od strony wydajnościowej) jest całkowitą utopią. Możesz sobie takie coś zrobić dla kodu na 10 linii, ale nie dla projektu na 100k linii.
Czyli zakładasz, że ktoś napisze dobry kod w javie i porówna go ze znacznie gorszym kodem w C++. Ok.
Ja uznaje, że znacznie uczciwszym porównaniem jest założenie, że kod w javie i kod w C++ będzie napisany dobrze. I jak pisałem – matematycznie niemożliwym jest, żeby dobry kod w javie był lepszy od dobrego kodu w C/C++.
"Ja uznaje, że znacznie uczciwszym porównaniem jest założenie, że kod w javie i kod w C++ będzie napisany dobrze. I jak pisałem – matematycznie "
Taaak? A gdzie indziej twierdzisz, że wcale nie odnosisz się do praktyki, tylko tak teoretycznie sobie opowiadasz, że przy czasie do nieskończoności. To co, uczciwszym porównaniem jest założenie, że porównujemy dobry kod w Javie z kodem w C++, którego napisanie wymaga de facto napisania Javy od zera?
Chyba się z lekka zaplątałeś w swoich bredniach?
Tak, pisałem o teorii. Najlepszy możliwy kod w javie vs najlepszy możliwy kod w C/C++. To moim zdaniem uczciwe. Nawet jeżeli w C/C++ przepiszemy Javę od 0 – to nadal mieści się w ramach teorii.
"Tak, pisałem o teorii. Najlepszy możliwy kod w javie vs najlepszy możliwy kod w C/C++. To moim zdaniem uczciwe."
No to w takiej teorii to nic nie wiemy bo nie każdy JVM jest napisany w C/C++ (a u ciebie to cholernie silne założenie); są też takie, które mają komponent sprzętowy.
Możesz skończyć bredzić i wrócić na Ziemię?
Nie każdy ;). Najwydajniejszy JVM z jakiego dane mi było korzystać – sunowski. Jaki lepszy mi proponujesz na laptopie wykorzystywać do uruchamiania superwydajnych aplikacji javowych, tak żeby nie przycinały ;)?
"Najwydajniejszy JVM z jakiego dane mi było korzystać – sunowski."
No właśnie – a dla większości osób profesjonalnie zajmujących się Javą to jest najmniej wydajny.
"Jaki lepszy mi proponujesz na laptopie wykorzystywać do uruchamiania "
A co ja, wróżka jestem? Nawet nie wiem co tam masz, czy nie wdepnąłeś w jakieś SWT na Linuksie albo coś jeszcze gorszego.
Ja pracowałem na Eclipse na Asusie EEE901 (sprawdź sobie parametry) i mimo dość długiego startu, potem wcale nie mulił. Ale to na Windows.
Wyłączając 10 linijkowe benchmarki, kod C/C++ występujący w świecie realnym prawie zawsze jest mocno nieoptymalny. Nawet w przypadku projektów takich jak np. Berkeley SPICE 3f4, w które wpakowano tysiące roboczogodzin naprawdę mocnych programistów w optymalizację.
Dlatego np nie ujrzysz C++ w jajku Linuksa.
Sam C++ nie jest zły, ale niesie ze sobą taki bałagan, że przy dość skomplikowanym projekcie źródła nie różnią się niczym od stogu siana.
@PodskakujacyBalrog
Bo ty piszesz o sytuacji teoretycznej, a ja o praktycznej. Co do szybkości można zawsze odwołać się do benchmarków takich jak:
http://shootout.alioth.debian.org/
Benchmarki te jednak nie pokazują sytuacji przy tworzeniu wielkich projektów. Czemu nikt nie napisze takiego Eclipsa w C?
" Czemu nikt nie napisze takiego Eclipsa w C?"
Gdyż nikomu się nie chce? Java jest bardzo wygodna dla developera (choć sam wolę Pythona). Nigdzie nie twierdziłem inaczej.
Jako użytkownik natomiast nie lubię programów w Javie.
Java jest mniej wydajna w projekcikach takich jak hello world, jednowątkowych i prostackich benchmarkach, gdzie jeden programista może sobie podłubać i zoptymalizować. Niestety czasy procesorów jednordzeniowych mamy dawno za sobą.
Na takich prockach jak Bulldozer wystarczy, że w Javie skleję poprawny kod a i tak okaże się szybszy od twojego statycznego.
Java nie wymaga znajomosci voodoo. Java jedynie wymaga poprawnego i czytelnego kodu. Reszte zalatwia VM.
Duże projekty również pisane są w C/C++, jeśli priorytetem jest wydajność.
Java tak samo jak każdy język wymaga dobrego kodu. Faktem jest, że w jej przypadku dobry kod napisać łatwiej.
Wydajność nigdy nie jest priorytetem. Top 500 firm to Java. Priorytet to stabilność i szybkość wyjścia w rynek. Optymalizacja C++ nigdy się nie opłacała, bo zawsze można dołożyć drugi procek za kilka dolców zamiast płacić kasę specowi od C++.
C++ miał szansę na zdobycie smartfonów – niestety nie udało się. Za kilka miesięcy wyjdzie Tegra 3 w smartfonach. Nie wyobrażam sobie optymalizowania kodu C++ na te 4 rdzenie. Java to lekarstwo na grypę C++.
Użytkownikowi na desktopie też powiesz, żeby dołożył sobie jeden procek, bo pisząc swój kalkulator w Javie chciałeś szybko wejść na rynek?!
W tym właśnie problem: Java ma swoje nisze – ale TYLKO niesze. Java/.net zupełnie nie nadaje się na desktop, ani nigdzie tam, gdzie programista i sprzęt nie są w ręku jednego zamawiającego.
Jeżeli wyda na mój kalkulator w Javie 5k PLN to wymiana procka to pikuś.
"Niestety czasy procesorów jednordzeniowych mamy dawno za sobą." – powiedz to pracownikom zus/urzedow/szkol a/biura itd, itp
O ile wiem, w większości z nich dalej rządzi cienki klient 80×25 a logika jest na serwerach. Przynajmniej w większości urzędów.
"zaimplementować pisząc aplikację w C++. DOKŁADNIE te same mechanizmy – jeśli będzie to konieczne. "
Ah, bo Ty z tych co twierdza, ze poniewaz kazdy jezyk jest kompletny w sensie turinga wiec wszystkie sa rownowazne, bo we wszystkich sie da?
Tak, oczywiscie, masz absolutna racje, poniewaz jezyki kompilowane daja kod natywny wiec wszystkie teoretycznie daja DOKLADNIE to samo.
Czyli asm == C == Java == dowolny inny jezyk kompilowany.
Nie. W javie nie zawsze możesz uzyskać ten sam efekt co w C/C++. Natomiast w C/C++ zawsze możesz uzyskać to samo co w javie.
Java jest kompilowana do kodu natywnego w locie. Dodatkowo czesc kodu jest testowana na wydajnosc i podmieniana w razie potrzeby. Funkcje i pętle są inlinowane w razie potrzeby.
Kod w Javie np:
for (i=0;i<1000000000000;i++)
for (j=0;j<1000000000000;j++)
for (k=0;k<1000000000000;k++) { continue; }
Zostanie wycięty do 0 i program skończy się w kilka ms.
Ten sam kod w C++ będzie się wykonywać setki lat.
Tak, że nie , nie można uzyskać w C++ tego co masz w Javie.
Ok, dodaj sobie pętlę while(1); to kod w javie też będzie się wykonywał w nieskończoność.
Co chcesz udowodnić? Że w każdym języku można napisac beznadziejny kod?
"Tak, że nie , nie można uzyskać w C++ tego co masz w Javie."
Oczywiście, że można. Można napisać wirtualną maszynę. Tak jak zrobił to np. Sun (który napisał ją właśnie w C++).
Nie, chce zwrocic uwage, że w Javie zaleca sie pisanie kodu milego dla oka a nie kompilatora. Kod i tak zostanie zoptymalizowany i będzie działaś równie szybko jak ten z C/C++ a duuuuuużo mniejszym nakładem sił i środków.
"który napisał ją właśnie w C++"
Mógł napisać w ASM albo LOGO, co mnie to obchodzi? Gdyby nawet VM napisali w brainfucku i tak wielkiej różnicy w wydajności względem kompilatorów C by nie było.
Coś mi się wydaje, że jesteś w głębokiej fazie zaprzeczania rzeczywistości. Czasy są takie, że nie ma czasu rozwiązywać problemów jakie niesie ze sobą C++.
Więc mówisz o czymś całkiem odmiennym. Ty mówisz o jakości kodu uzyskanego w tym samy czasie w obu językach. To nie jest w żaden sposób to samo co porównanie dobrego kodu w javie i dobrego kodu w C/C++.
Czasy są takie, że użytkownicy nie lubią korzystać z niewydajnych aplikacji w javie. Aplikacji nie-użytkowych.
Masz jakieś dane na poparcie tej tezy inne niż "wydajemisię"?
"To nie jest w żaden sposób to samo co porównanie dobrego kodu w javie i dobrego kodu w C/C++. "
Ale zdajesz sobie sprawę, że podstawiając asm zamiast C/C++ uzyskujemy coś nie do przebicia? _Dobry_ kod asm jest szybszy od wszystkiego. Myślę, że powinieneś brać jako kryterium również czas potrzebny do uzyskania dobrego kodu, bo czas wbrew pozorom kosztuje i to słono.
Nigdzie nie pisałem nic o czasie. Odnosiłem się tylko do tego, że aplikacja w javie nie może być szybsza od aplikacji w C/C++. Zakładając, że obie są napisane dobrze.
Czyli pisałeś o krasnoludkach i sierotce Marysi. My piszemy o rzeczywistym świecie.
Nie. Pisałem o teorii ;). Której wy staracie się kłamliwie zaprzeczyć.
Jeszcze szybciej pisze się aplikacje w Perlu/Pythonie. Wy wybraliście niższy poziom abstrakcji, ja wybieram jeszcze niższy. Kwestia potrzeb.
Ale zaprzeczanie faktom to kłamstwo, niezależnie od upodobań.
Pisałem i w Perlu i w Pythonie, i w Javie i śmiem się nie zgodzić. W językach dynamicznych pisze się szybko tylko na początku, później przychodzi spłata długu z odsetkami: refactoring.
Z innej beczki – teoria, która nie uwzględnia praktyki jest bezużyteczna. Dlatego śmieszą mnie dywagacje "a co by było gdyby budżet projektu był nieskończony a programiści mieli kryształowe kule przepowiadające co naprawdę chciał klient".
"Nie. Pisałem o teorii ;)"
Kłamiesz. Pisałeś, że javie nie jest możliwe napisanie aplikacji szybszej niż w C/C++. Zwyczajnie takiej możliwości nie ma., potem jeszcze dodałeś, że To zwyczajnie technicznie nie jest możliwe. a teraz jak kilka osób wykazało, że bredzisz to uciekasz w głupawe bajanie o teorii, czy jeszcze lepsze o "dobrym" kodzie. Przy czym "dobry" kod w Javie to po prostu dobry kod w Javie a dobry kod w C++ to jakiś abstrakcyjny konstrukt, którego nikt nigdy nie napisał i nie napisze, chyba że akurat pisał JVM.
I nadal to zdanie podtrzymuję: "w javie nie jest możliwe napisanie aplikacji szybszej niż w C/C++. "
Wy porównujecie dobry kod w javie, z kiepskim w C++. Dlatego upieracie się, że java może być wydajniejsza.
I porównując dwa kody o różnej jakości – chcecie coś wykazać. To śmieszne.
Też potrafię napisać beznadziejny kod w javie i upierać się, że java jest wolniejsza niż bash ;].
"Wy porównujecie dobry kod w javie, z kiepskim w C++. Dlatego upieracie się, że java może być wydajniejsza.
I porównując dwa kody o różnej jakości"
Nie. My porównujemy realnie istniejący kod w jednym i drugim. Ty żądasz porównywania bytów nieistniejących, takich jak idealny kod w jednym czy drugim. Do tego w oparciu o nieprawdziwe w ogólności założenie, że JVM jest napisana w C czy C++.
Jak już pisałem – nie miałem do czynienia z wydajniejszą jvm niż tak od Sun(Oracle).
A ta jest napisana w C++ i "muli" ;).
bzdura, kompilator C/C++ przy włączonej optymalizacji usunie te pętle w ramach dead code elimination.
a w czasie dzialania tez usunie (gdy zaladuje zewnetrzny skrypt)? w C++ wystrczy dać w tej petli jakas lipna funkcje i juz jej nie wytnie.
Lipne funkcje też są wycinane (przynajmniej przez GCC).
Buhaha, zwłaszcza jak są zdefiniowane w odrębnej jednostce kompilacji albo są wirtualne.
Jeśli bardzo chcesz, to w javie też sobie zrobisz krzywdę. Czego to dowodzi? Niczego 🙂
Dowodzi tylko, a może aż tego, że kompilatory Javy wykonują pewne optymalizacje, których nie potrafią wykonywać kompilatory C++. I dlatego, wyłączając abstrakcyjny przypadek, kiedy ktoś cały kod optymalizuje ręcznie, wcielając się niemal w kompilator, realny kod w Javie ma szanse działać szybciej niż realny kod w C++.
akurat VC++ ma możliwość ustawienia Link Time Code Generation, wiec to, że było kilka różnych jednostkach kompilacji nie ma na tym etapie znaczenia.
POmyliło ci sie chyba ze skryptami. Java jest kompilowana do bytecodu, ale w czasie uruchomienia jest skladana do kodu natywnego z uwzglednieniem optymalizacji na dany procesor. Tego nie potrafi żaden C czy c++. Co z tego, że JIT jest napisany w C? On ma tylko poskładać do kupy, uruchomić i w zależności od testów zoptymalizować kod w czasie działania programu.
Nawet silniki do gier 3d zaczęły powstawać w Javie. http://jmonkeyengine.com/
Jako, że Java jest prosta jak but, każdy kto ogarnia minimum powinien umieć zrobić w tym grę. I co ciekawe, taka gra bez marszczenia jajek pójdzie na Mac, PC, Linux, Android. To nie czasy Pentium, gdzie wchodziły pierwsze akceleratory grafiki i liczył się tylko procek.
Zyjesz kolego w czasach dinozaurów.
@jkl
"Java jest kompilowana do bytecodu, ale w czasie uruchomienia jest skladana do kodu natywnego z uwzglednieniem optymalizacji na dany procesor. Tego nie potrafi żaden C czy c++. Co z tego, że JIT jest napisany w C?"
JIT jest napisany w C – można w C napisać go po raz drugi (a więc i aplikację uwzględniającą dodatkowe optymalizacje w locie). Więc C, czy C++ jak najbardziej to "potrafią". Kwestia czasu poświęconego na implementację. Nie twierdzę, że java jest zawsze mniej wydajna – tylko, że nie może być wydajniejsza.
"Nawet silniki do gier 3d zaczęły powstawać w Javie."
Polecam pograć w minecrafta. Gra świetna(bez cienia ironii) – szkoda, że java 😉 (co można często boleśnie odczuć).
"Więc C, czy C++ jak najbardziej to "potrafią". Kwestia czasu poświęconego na implementację."
Ale wiesz, że skoro już odlatujesz w taki surrealizm, to JVM można od zera przepisać w kodzie maszynowym (to tylko kwestia czasu poświęconego na implementację, co nie?) i cała twoją "argumentację", że skoro napisano JIT w C to Java nie może być szybsza od C o kant dupy potłuc można.
Ale tu nikt nie kłóci się nad przewagą w szybkości assemblera nad C.
Ty za to kłócisz się o przewagę Javy nad C/C++, co jest matematyczną bzdurą.
Tyle, że czas tworzenia kodu w asemblerze jest kilkaset razy większy niż w C++ czy Javie.
A pomiędzy Javą a C++ różnica jest znikoma i najczęściej wynika z marnych umiejętności programisty, który umie poprawnie powielać schematy w Javie, ale w C++ się gubi i tworzy projektowe potworki.
Zatrudnij zespół fachowców od C++, to będziesz miał lepszy kod niż w Javie, pod wszystkimi względami: dalszy rozwój, szybkość, czytelność.
"Ty za to kłócisz się o przewagę Javy nad C/C++, co jest matematyczną bzdurą."
To jest wystarczająco często po prostu faktem, żebym się nie zastanawiał czy jak zatrudnię inny zespół od C++ to dostanę coś lepszego, czy tylko bredzenie internetowych mędrków od zarządzania pamięcią przez memmove(), że powinienem zatrudnić zespół jeszcze lepszy.
"A pomiędzy Javą a C++ różnica jest znikoma"
def factorial(n: BigInt) = (BigInt(1) to n).par.product
Napisanie i przetestowanie tego kodu w Scali zajęło mi ok. 15 sekund. Dla niewtajemniczonych – ten kod liczy silnię z n równolegle na wielu rdzeniach. Napisz równoważny kod w C++ i policz ile czasu Ci zajęło. Uwzględnij czas ściągania niestandardowych bibliotek, napisania kodu zarządzającego pamięcią i wątkami, następnie debugowania tego aby działało stabilnie. Dolicz łączny czas kompilacji i linkowania projektu. Jeśli się zmieścisz w 2,5 minuty (= 10x więcej) to jesteś mocarz.
"Napisanie i przetestowanie tego kodu w Scali"
Fajnie, tylko to nie jest Java. Pomijając cały debilizm "dowodzenia" czegokolwiek takimi onelinerami.
Dobra, masz rację, wyciąganie Scali jest nie fair – bezbronnego się nie kopie…
Jak to nie Java? Scala jest napisana w Javie i kompiluje się do bytecodu JVM. Można więc potraktować ją jako dodatkową bibliotekę. (możliwe jest korzystanie z bibliotek napisanych w Scali przez programy pisane w Javie)
"Jak to nie Java? Scala jest napisana w Javie i kompiluje się do bytecodu JVM."
Po prostu nie Java. I już. Wszystko jest ostatecznie napisane w kodzie maszynowym, ale nie uciekaj w balrogizm.
"ale nie uciekaj w balrogizm"
Cholerny offtop ;). Ale spodobało mi się to określenie :). Chyba zacznę z niego sam korzystać ;).
"HotSpot bodajrze w C++, mylę się?"
Wiesz o czym w ogole mowisz? I co do czego porownujesz?
Gdyby wiedział to by nie wyskakiwał z takimi tekstami.
Gdybyście rozumieli co za sobą pociąga fakt, że u podstaw javy stoi maszyna wirtualna napisana w C++ – nie wyskakiwalibyście z takimi tekstami ;].
A ty ciągle mylisz język z kompilatorem.
Dokładnie to w C, przynajmniej JVM od Oracle/Sun.
Ale oni chyba nigdy nie zrozumieją implikacji tego faktu 😉
Ten argument ma tyle sensu, co twierdzenie, że "assembler nie może być szybszy od C, bo program działa pod kontrolą systemu operacyjnego napisanego w C".
Nie. To twierdzenie programistów Javy ma tyle sensu, co stwierdzenie, że kod w C jest szybszy od kodu w asm. A też być szybszy nie może.
Udowodnię teraz, że program w assemblerze nie może być szybszy od programu w C. Posłużę się przy dowodzie lematem Balroga. Tezę można sformułować następująco – dla każdego programu w asemblerze można napisać program w C nie ustępujący mu wydajnością. Dowód jest prosty – tworzę program o treści<pre>int main (int arg,char *argv[]) {
asm("movl %ecx %eax;…");
return 0;
}</pre>QED.
Następnie, korzystając z tego samego lematu, udowodnię, że program w asemblerze nie może być szybszy od skryptu w bashu. Ponieważ bash jest kompletny w sensie Turinga, jestem w stanie napisać w bashu funkcję optymalizuj(), która dla każdego podanego na wejściu skryptu bashowego zwraca równoważny mu optymalny program w kodzie maszynowym. Ten program nie może być wolniejszy od programu w assemblerze. QED.
Niestety, w swoim "dowodzie" opierasz się na intuicji a nie na logice. Na chłopski rozum prawdą jest to co piszesz, ale na chłopski rozum prawdziwe jest też rozumowanie "skoro każda liczba naturalna jest całkowita a są liczby całkowite niebędące naturalnymi, to liczb całkowitych musi być więcej; zwyczajnie nie ma innej możliwości". Co, jak wiadomo, na gruncie logiki jest fałszywe. Ale od początku.
Wydaje mi się, że raczej w C, ale nie ma tutaj znaczenia w czym jest napisana JVM. Mogłaby być równie dobrze być napisana w Visual Basicu. Tak samo nie ma znaczenia w czym napisany jest kompilator C++. Na końcu i tak dostajemy kod maszynowy wykonywany przez procesor. Tak więc musisz udowodnić, że kod maszynowy przetłumaczony z kodu w Javie nie może być szybszy od kodu maszynowego przetłumaczonego z C++.
Nie możesz – maszyna wierualna Javy dysponuje informacjami, które są tracone na etapie kompilacji kodu C++.
Patrz dwa powyższe akapity.
BTW. Wyrażenia "zwyczajnie takiej możliwości nie ma", "to oczywiste" wcale magicznie nie sprawią, że Twój "dowód" będzie mniej błędny.
Na koniec ciekawostka. Jest maszyna wirtualna Pythona napisana w Pythonie (PyPy), która wydajnością bije CPythona, mimo, iż sama do uruchomienia wymaga interpretera Pythona. Paradoks?
PS. Możliwe, że chcesz dowieść, że dysponując t→∞, jesteś w stanie napisać program w C++ przewidując wszystkie możliwe styuacje, np. każdą funkcję przepisując na n→∞ możliwych dposobów, tak że każdy będzie optymalny dla pewnej kombinacji parametrów wejściowych i w trakcie wykonania przełączać się między implementacjami. W takim razie masz rację, jednak praktyczna wartość takiego dowodu dąży do zera.
Bardzo ładna odpowiedź. Brawo.
Wybacz, że resztę wypowiedzi pominę, ale sam sobie odpowiedziałeś ostatnim akapitem.
"PS. Możliwe, że chcesz dowieść, że dysponując t→∞, jesteś w stanie napisać program w C++ przewidując wszystkie możliwe styuacje, np. każdą funkcję przepisując na n→∞ możliwych dposobów, tak że każdy będzie optymalny dla pewnej kombinacji parametrów wejściowych i w trakcie wykonania przełączać się między implementacjami. W takim razie masz rację, jednak praktyczna wartość takiego dowodu dąży do zera."
Ależ ja od początku tego (i tylko tego) właśnie dowodzę. Nigdzie nie odnosiłem się do praktyki. Tylko do tego, że w teorii nie jest możliwe, żeby Java była szybsza od C/C++.
"Ależ ja od początku tego (i tylko tego) właśnie dowodzę."
Tyle że nawet tego to twoje pseudologiczne bredzenie nijak nie dowodzi, choćby dlatego, że istnieją procesory mające sprzętowe wsparcie dla Javy i już całe to swoje opowiadanie o tym, że Java "matematycznie" nie może być szybsza niż C++ bo JVM możesz se nawinąć na rulon.
"Nigdzie nie odnosiłem się do praktyki. "
Najpierw napisałeś, cytuję, w javie nie jest możliwe napisanie aplikacji szybszej niż w C/C++. Zwyczajnie takiej możliwości nie ma., zredukowałeś to obok do matematycznie niemożliwym jest, żeby dobry kod w javie był lepszy od dobrego kodu w C/C++. a teraz nagle się okazuje, że dobry kod w C++ to taki, którego praktycznie nie da się napisać, bo wymaga JVM w każdej aplikacji.
PS. Nie wiem czy el.pescado cię strollował propozycją stablicowania każdej funkcji, czy pisał to na poważnie (raczej trollował, bo to mądry człowiek jest), ale twoja reakcja jest prześliczna.
"a teraz nagle się okazuje, że dobry kod w C++ to taki, którego praktycznie nie da się napisać, bo wymaga JVM w każdej aplikacji."
Czytanie ze zrozumieniem w narodzie zamiera. Jeśli najoptymalniejsze rozwiązanie tego wymaga – to tak właśnie powinno to wyglądać. Nie odnosiłem się nigdzie do praktyki.
Jeśli mam się do niej odnosić – moje programy napisane w javie mulą ;]. Wiem, że powinienem dostawić 16GB ramu, ale zwyczajnie nie chce mi się z powodu javy.
PS A wyśmiewane przez javowców tablicowanie jest tak przydatne ;]
"Jeśli najoptymalniejsze rozwiązanie tego wymaga – to tak właśnie powinno to wyglądać. Nie odnosiłem się nigdzie do praktyki. "
Kłamiesz. Twierdziłeś od początku, że technicznie niemożliwe jest napisanie szybszej aplikacji w Javie niż w C++, teraz uciekasz w jakieś bajdurzenie, że "najoptymalniejszy" kod w C++ nie będzie wolniejszy niż "najoptymalniejszy" kod w Javie.
Co też jest bzdurą, przeczytaj wyżej dlaczego.
Nie uciekam w żadne bajdurzenie ;). Przecież od początku pisałem to samo. To że niektórzy nie posiedli zdolności czytania ze zrozumieniem – to nie moja broszka ;].
To pokaż mi w cytatach tutaj jak piszesz o "najoptymalniejszych". Albo w komentarzach z których te cytaty pochodzą? Nie potrafisz? Jaka szkoda.
Już pomijając, że nawet dając ci ten przywilej i uznając, że zapomniałeś napisać, że nie chodzi o realia tylko walenie konia teorią, też nie masz racji.
Nie. Powiedziałeś:
Co można interpretować następująco: "Każda aplikacja w C/C++ jest szybsza od dowolnej aplikacji w Javie". To co innego niż "Dla każdej aplikacji w Javie teoretycznie jest możliwe napisanie równoważnej jej aplikacji w C/C++ tak, że ta ostatnia jest co najmniej równie wydajna".
Teoretycznie mógłbyś mieć rację, ale tak się składa, że w kilku tych przypadkach drugi system pisali inni programiści. Można się spierać, że byli po prostu lepsi, no ale jak to się ma do twierdzenia o_O, że programiści Javy to debile.
Wielokrotne dziedziczenie? Zazwyczaj w C++ wielokrotne dziedziczenie kończy się wirtualnym dziedziczeniem a to z kolei powoduje kolejne problemy. Wiem ze swojej praktyki, że jak ktoś w C++ dziedziczy wielokrotnie to albo są to bardzo małe i proste klasy albo musi dziedziczyć wielokrotnie bo całość jest źle zaprojektowana.
no, i jeszcze brak definiowanego w standardzie c++ ABI, wiec jak sobie wyeksportujesz z dynamicznej biblioteki KLASY, to nie masz żadnej pewności, że program skompilowany na innej wersji kompilatora poprawnie odwoła się do exportów biblioteki. I zaczyna się zabawa z exportowaniem klas abstrakcyjnych by skorzystać z interfejsu przez vtable-a lub wrapowanie metod w funkcje C, by je exportować jako "C" bez manglowania.
Fakt, to nie jest miłe, choć tak na prawdę rzadko jest to poważny problem.
Ale my tu o szybkości mówimy, a nie o wadach języka.
W Javie nie masz za to np. makr, co jest straszliwie upierdliwe jak piszesz coś większego od hello world.
Spójrz wyżej na post jarka. Dobrze cię określił, jeśli uważasz brak makr za wadę.
Najgorsze co się światu IT przytrafiło to były makra C, później niestety odziedziczone przez C++.
nic złego w makrach nie ma dopóki korzysta się z nich do kompilacji warunkowej, a nie zastępuje kod prostych funkcji typu MIN(a,b),MAX(a,b), itp
Makra w C zostały wymyślone po to by ułatwić przenoszenie nieprzenośnego kodu pomiędzy maszynami jednej firmy.
Powoduje to,że w skrajnuch przypadkach na 10 maszyn masz 10 różnych plików z kodem. Z czasem ich liczba rośnie (przybywa nowych maszyn) a ty po 100 maszynie strzelasz sobie w baniak bo sie okazalo ze we wszystkich 100 wymieniono pierdolnik A na pierdolnik B i trzeba zaktualizować te 100 plików oraz przetestowac kod bazujacy na nich. Jako ze w firmie nie jestes sam, w łeb strzelaja sobie kolejni programisci.
Myślę, że powinno się wprowadzić jeszcze jedną warstwę nad Xtend o nazwie Pretend.
Wtedy nauczymy się tylko języka Pretend, potem skompilujemy go do Xtend, a następnie skompilujemy i otrzymamy Java.
W ten sposób zamiast jednego języka Java będzie się można nauczyć jeszcze dwóch dodatkowych, by programiści nie musieli się nudzić.
;-))
Język Pretend to świetny pomysł!
Wtedy już dosłownie każdy będzie mógł udawać, że jest świetnym programistą.
Każdy swój brak będzie mógł zasłonić ograniczonymi możliwościami języka. A brak inwencji narzuconym liniowym podejściem do projektowania. Ot języki Javo i .neto-podobne.
Masz kolego jakiś kompleks?
On już kiedyś przyznał, że programiści Javy i .NET zjedli mu obiad. I śniadanie. I kolację też.
Tak? Nie wiedziałem.
Ty lepiej pokaż co napisałeś to każdy oceni jakim ty jesteś programistą.
Pokazałbym, ale lubię anonimowość.
Choć jeśli używasz Linuksa na desktopie, to jest duża szansa, że i mojego kodu.
Co do komercyjnej pracy, to też jest cień szansy, że się z nią spotkałeś w internetach.
a ja myślałem, że Ty jesteś zadeklarowanym opensource-owcem, a tu nie chcesz pokazać swojego kodu. wstyd – a fee
A ja osobiście uważam, że Javie już nic nie pomoże. Ten super "elastyczny" jak kij od miotły język już dawno przestał nadawać ton w świecie programowania, Oracle woli zajmować się wojnami patentowymi niż samą Javą, kolejna aktualizacja pewnie za kolejne kilka lat i może dogonią C# w wersji 3. Android zamula przez Jave, aplety w przeglądarkach powodują, że można smażyć na kompie jajka, super fajne beansy pisane dla Pani Krysi z trzeciego piętra są nudne jak flaki z olejem… no może jako pewien ekosystem jest ok, ale może lepiej wykorzystywać w nim coś lepszego niż samą Jave, może JRuby, Scalę. Z zamiłowaniem obserwuję jak TIOBE Index pokazuje na wykresie spadek popularności tego języka, nie to żebym komuś źle życzył, ale Java już dawno się wypaliła i nie widzę sensu żeby jej używać.
C#/.net jest jeszcze gorsze, bo poza powolnością i idiotycznym jak na dzisiejsze czasy modelem zapewniania przenośności (maszyna wirtualna), jest jeszcze… oficjalnie zupełnie nieprzenośny poza windows.
moze poczytaj o xna
hint: xbox to nie windows.
Xbox to Windows! http://en.wikipedia.org/wiki/Xbox
"The Xbox runs a custom operating system which was once believed to be a modified version of the Windows 2000 kernel. It exposes APIs similar to APIs found in Microsoft Windows, such as DirectX 8.1. The system software may have been based on the Windows NT architecture that powered Windows 2000; it is not a modified version of either." spod linka ktory sam podales.
xbox to nie windows, choc faktycznie istnieje port windowsa… ce – http://www.geekzone.co.nz/content.asp?contentid=2…
Szczegoly nikogo nie obchodza. Jest to galaz WinNT cz CE wiec Windows.
male pytanie – widziales kiedys windowsa ce?
probowales na nim uruchomic jakikolwiek soft z windowsa xp, czy 95 na tym?
pewnie kde/gnome to dla ciebie tez windows, bo przeciez dziala pod x window system 😉
prosze, miast trollowac – wyjdz…
Widziałęm, próbowałem, gdy wyszedł WP7 podziękowałem.
Teraz siedzę na Androidzie.
Poza tym pisałem, że mnie to nie obchodzi. Cała platforma MS dla mnie nie istnieje.
dobrze ze miguel de icaza o tym nie wie, tj. ze jego mono jest zupelnie nieprzenosne poza windows 😉
w koncu promowane ostatnio mono na ajfony czy androidy (dostepne za zdecydowanie zbyt duza cene) to jego zrodlo utrzymania…
ps. tez nie przepadam za tym srodowiskiem, ale przynajmniej nie staram sie zaklinac rzeczywistosci na wlasna modle tylko dlatego, ze ta rzeczywistosc mi nie pasuje…
Łączę się z tobą w bulu.
PS. Java zawdzięcza popularność dzięki swojej stabilności. Dzięki temu biblioteki pisane na początku istnienia Javy działają do dziś, czego nie można powiedzieć o sh1cie MS.
Tak, rozumiem cię. MS wydaje WinRT i twój skill w hackowaniu Meny start w C# na uja sie teraz zda. Tez bym pewnie wylewal takie zale gdybym kilka lat temu poszedl w C# a nie w Jave.
Poza tym JVM jest wiele wydajniejsze od .NETowskiego VM , nawet Mono jest wydajniejsze od .NET.
Po pierwsze metro nie ma zastąpić aero, przynajmniej narazie. Po drugie:
>Poza tym JVM jest wiele wydajniejsze od .NETowskiego VM , nawet Mono jest wydajniejsze od .NET.
[potrzebne źródło]
Z tymi źródłami jest najgorzej. Bo jak porównać VM? Zwycięzca będzie zależny od zastosowania.
Swego czasu szukałem porównania wydajności V8 (Javascript), Dalvika i JVM… i muszę przyznać, że chyba nie umiem korzystać z Google, bo nic sensownego nie znalazłem:)
"Z zamiłowaniem obserwuję jak TIOBE Index pokazuje na wykresie spadek popularności tego języka, nie to żebym komuś źle życzył, ale Java już dawno się wypaliła i nie widzę sensu żeby jej używać"
Problem w tym, że na razie nikt nie zrobił nic lepszego (zwłaszcza jeśli wymieni się frontend na coś lepszego niż Java, np. na Clojure). A TIOBE ma niejawną metodykę opartą na bzdurnych założeniach. Jego wyniki nijak mają się do faktycznej popularności (mierzonej np. liczbą nowych projektów, ilością powstającego kodu, czy zapotrzebowaniem na programistów). Znacznie lepszą metryką już są ogłoszenia o pracę, a tu od lat dominuje Java i zapewne jeszcze długo będzie.
Nie wiem, co ludzie widzą w tego typu językach. Cała frajda jest właśnie w pisaniu w C++ i C 😉 Całe jądro Linuksa jest napisane w C (no, może trochę w asmie), a KDE w C++ (z Boostem co prawda, ale C++).
A co Ci taką frajdę sprawia?
Nie wiem, co jest fajnego w tego typu językach co ten z newsa, bo nie zaglądałem do opisu. Ale wiem, że w wielu alternatywnych językach są konstrukcje o jakich programistom C i C++ się nie śniło. Ot, ten sam system, który dwie osoby piszą w C++ w rok, jedna osoba może zrobić w 3 miesiące, i będzie działał stabilniej. W C++ ciągle się rozwiązuje problemy nieistniejące w innych językach (np. o prawidłowej implementacji singletona w C++ pisano rozprawy naukowe i nadal nikt nie wie jak to dobrze zrobić), zamiast pisać kod realizujący właściwą funkcjonalność.
Z tym singeltonem trochę przegiąłeś – Boost wprowadził go chyba do Cx0
boost::mutexed_singleton
Sprawny programista C++ jest prawie tak samo sprawny jak programista Java – tylko czasem nie wie dlaczego dostaje core dump'y i musi się trochę pomęczyć ;), ale ile frajdy się ma jak się uda!
Jasne i każdy dostęp do singletona to zajęcie i zwolnienie mutexa. No i musisz w związku z tym wiedzieć, czy Twój program jest jednowątkowy, czy wielowątkowy, żeby użyć właściwego singletona (kompilator nie ma pojęcia o tym czym jest mutex i nie wywali go za Ciebie w procesie optymalizacji, tak jak to robi Java). I musisz uważać na biblioteki łączone dynamicznie (w Boost dają do tego jakieś paskudne makro). Nie pisałem, że nie da się tego zrobić, tylko że nie da się tego zrobić *dobrze*.
Twoje twierdzenie o 4-krotnie szybszym tworzeniu w Javie, przez dwukrotnie mniej osób i to lepszych produktów niż w C++ można obalić metodą niewprost:
Gdyby tworzenie w Javie było takie proste a efekty tak doskonałe, oprogramowanie Javowe momentalnie wyparłoby to stworzone w C/C++. Kto by nie chciał używać programu lepszego, a jednocześnie pozwalającego naprawiać ewentualne błędy (o ile w wersji Javowej w ogóle takie by się trafiły) kilkakrotnie szybciej? Tendencji do wypierania programów w C/C++ programami Javowymi jednak nie widać.
Jeszcze pewnie ma to szanse zdarzać się w dużych firmach, gdzie o użyciu programu decyduje nie ten, który będzie się później w codziennej pracy musiał irytować jak to beznadziejnie działa… Ale – jak myślisz – dlaczego np. w programach dla zwykłego użytkownika, np. programach desktopowych, Java nie ma "należnej" sobie pozycji?
"Ale – jak myślisz – dlaczego np. w programach dla zwykłego użytkownika, np. programach desktopowych, Java nie ma "należnej" sobie pozycji? "
Przy bardzo wielu użytkownikach danego systemu, wysiłek stworzenia wydajniejszej aplikacji kosztem większej ilości poświęconego na to czasu jest opłacalny. Każda aplikacja działająca wydajniej wyprze podobną w możliwościach ale wolniej działającą.
Problem tylko w tym, że tam gdzie trzeba szybko napisać aplikację tak by działała bezbłędnie i stabilnie, a dodatkowo liczy niski koszt wytworzenia to Java deklasuje C++. A takie aplikacje to większość tego co się pisze. To co widzimy na desktopach to margines wytwarzanego oprogramowania.
"Tendencji do wypierania programów w C/C++ programami Javowymi jednak nie widać. "
Właśnie że widać, C++ został już dawno wyparty przez Javę i C#, ale nie tam gdzie Ty patrzysz 😉
"o ile w wersji Javowej w ogóle takie by się trafiły"
A można napisać dużą aplikację, zupełnie unikając błędów?
"Problem tylko w tym, że tam gdzie trzeba szybko napisać aplikację tak by działała bezbłędnie i stabilnie" <- a sa aplikacje działające bezbłędnie ? chyba Hello World
"a sa aplikacje działające bezbłędnie ? chyba Hello World "
Czasami też na początku mają błędy 😉
O bezbłędności pisałem jako idei do której dążymy. (zobacz ostatnie zdanie)
Java nie ma mocnej pozycji na desktopach, bo Sun praktycznie olewał ten fragment rynku za długo. Problemem nie była nawet wydajność a bardziej niedofinansowany Swing (błędy i paskudny wygląd), brak możliwości uruchamiania wielu aplikacji na jednej JVM (powolny start i większa niż konieczne zajętość pamięci), słaba integracja z desktopem (ikonki w trayu, kłopotliwy deployment) itp. Mimo to, w sektorze aplikacji korporacyjnych, Java na desktopie występuje dosyć często – w ciągu ostatniego tygodnia w dwóch sklepach widziałem typowe Swingowe paskudne coś.
Do tego SWT w cale nie lepsze. Ciekawe wydaje się tylko QJambi, gdy ktoś włożył w to trochę kasy, to mielibyśmy fajne przenośne GUI dla Javy.
Tyle, że SWT możesz użyć w Eclipse RAP. Nie spotkałem się jeszcze z toolkitem takim jak SWT, który działa na desktopie i w przeglądarce.
Apache Pivot działa na desktopie i w przeglądarce.
U minie żadne z demo ze strony apacha nie działa 🙁
No fajnie a graficzny builder i binding do beansów mają? Bo takich toolkitów jest od groma.
Pivot wymaga javy do działania RAP nie. Pivota nie uruchomisz na Androidzie.
To samo zjawisko z XP kontra W7. Niby W7 lepszy a firmy i tak nie chcą się przenosić.
Twój argument jest chybiony. To, że pies złapał kość i nie chce oddać, nie oznacza, że też będzie ci smakować jak mu zabierzesz.
Brutalna prawda jest taka, że w dzisiejszych czasach jeśli za jęykiem/platformą nie stoi duża korporacja to z niczym owym na dużą skalę nikt się nie wbije. Mamy Jave, C/C++, C#, Javascript – za każdym z nich stoi albo tradycja albo korporacja. Python, Ruby to zawsze będzie druga, trzecia liga.
Warto zwrócić uwagę na fenomen nodejs czy byłby tak popularny jakby nie javascript który znają praktycznie wszyscy ?
"Warto zwrócić uwagę na fenomen nodejs czy byłby tak popularny jakby nie javascript który znają praktycznie wszyscy ?"
A czy to coś w ogóle jest jakkolwiek popularne czy to meteor z blogaskowym hype'm, o którym za dwa lata nikt nie będzie pamiętał?
"A czy to coś w ogóle jest jakkolwiek popularne czy to meteor z blogaskowym hype'm ?" Sam Pan Bóg raczy wiedzieć. Niemniej:
1. hype jakoś tam z popularnością w parze idzie.
2. zdaję się że amplituda hype/prawdziwej popularności rośnie szybciej niż dla ROR parę lat temu
3. MS zasponsorował port nodejs na Windows mimo, że miał bardziej koszerne (dla nich) rozwiązanie pod ręką https://github.com/jacksonh/manos
Z tym "praktycznie wszyscy" bym nie przesadzał. Wiele osób słyszało o js, sporo osób coś w nim napisało (metodą Kopiego i Pasta;), ale tak naprawdę nie ma pojęcia o tym języku. Sam się zdziwiłem jak mało wiem, kiedy porzuciłem jQuery.
Bardzo lubię ten język, ale czasem potrafi nieźle napsuć krwi (ach to this) i jednak po stronie serwera korzystam z bardziej tradycyjnych php 🙁 i pythona.
Akurat za Pythonem stoi duża korporacja. Gdyby nie Google Python byłby zapewne nieco mnie popularny.
Poza tym korporacje wybierają to w czym programiści chcą pisać. Google w Androidzie zdecydowało się na Javę ze względu na popularność tego języka.
Wypowiadacie się praktycznie o wszystkim, ale nie o C++0x , może ktoś doświadczony zarzuci jakąś opinią? Chętnie poczytam.
Moim zdaniem ten język jest skazany na wymarcie. Zmiany w nowym standardzie są dobre dla ludzi od lat używających C++. Dla nowych zwiększają ilość wiedzy potrzebnej do opanowania języka. Mimo istnienia boost, C++ daleko do sytuacji w Java gdzie mamy większą dostępność gotowych do użytku bibliotek.
To że c++ wymrze wieszą tak od 15 lat, to tak samo następny rok rokiem linuksa na desktopie.
Dobra, przyznaję, Źle się wyraziłem, nie C++ wymrze tylko stanie się równie popularne co Lisp 😉
Rok linuksa na desktopie mam od 10 lat non stop 🙂
Gdyby Microsoft nie uczynił z C++ głównego języka implementacji aplikacji na Windows, C++ miałby podobną popularność co Lisp, albo pewnie i mniejszą. Wystarczy zobaczyć, jak nikła jest popularność C++ na platformach od Apple.
Apple i C/C++ – popularność tego połączenie jest akurat niewiadomą – całą logikę czy np. rendering grafiki czy dźwięku można napisać bez żadnego problemu w C/C++ i połączyć to z Objective-C, a w nim musisz jedynie zainicjalizować aplikację i poczytać niektóre interesujące Cię delegaty. Także, nie wiadomo jak dużo kodu deweloperzy tworzą w Obj-C, a jak w C/C++ bo to tylko kwestia preferencji, a nie jakiejś specjalnej konieczności,
C++0x wprowadził wiele fajnych rzeczy z aspektów programowania funkcyjnego (chociażby lambdy) jednak to dalej ten sam imperatywny C++ a kod kompiluje się jeszcze dłużej (nie sądziłem, że to w ogóle możliwe). Może lepiej niech się wypowie ktoś kto lubi imperatywne języki, pewnie będzie miał bardziej obiektywne spojrzenie…
Ja tam lubię C++11 i od razu się na niego przerzuciłem. Pętle for oparte na zakresie, inicjalizacje tablic, wyrażenia lambda, typy auto, decltype to coś, co naprawdę stanowi większą wygodę dla programisty. A to, że się kompiluje dłużej, to mały problem, bo kompiluje albo developer, albo kompilujesz to sam, ale raz na apdejt. Ważna jest szybkość działania programu, a dzięki usprawnieniom takim jak właśnie inicjalizacja tablicy (w liście inizjalizacyjnej konstruktora), czy rvalue reference kod może być naprawdę szybszy.
Co do javy – szanse widzę tylko w niektórych programach. Zauważcie, że miejsca, gdzie się pojawia Java, to małe programy, typu JDownloader, których szybkość nie ma wielkiego znaczenia. Środowiska graficzne, programy codziennego użytku, programy systemowe, usługi, jądro – to wszystko MUSI być pisane w C/C++, inaczej po prostu ludzie uciekną od tego w popłochu. Dlaczego jądro Linucha jest pisane w C? Bo jest pisane przez świetnych programistów oraz jest pisane w C.
"Co do javy – szanse widzę tylko w niektórych programach. Zauważcie, że miejsca, gdzie się pojawia Java, to małe programy, typu JDownloader, których szybkość nie ma wielkiego znaczenia"
Jest dokładnie na odwrót. Java jest głównym elementem takich aplikacji jak Facebook, Twitter, Amazon, GMail i raczej są to bardzo duże aplikacje o bardzo dużym obciążeniu i wysokich wymaganiach wydajnościowych.
Wow. Kilkadziesiąt komentarz i właściwie nikt nie odniósł się do komentowanej treści. Szacun.
Bez względu na opinie poszczególnych osób Java jako język i jako platforma jest powszechnie używana. Powszechnie nie znaczy oczywiście, że wszędzie i do wszystkiego i że to dobrze bądź źle, że tak jest. Ale fakt jest ciągle faktem – nawet jeśli się na nie podoba. Obecnie są przynajmniej dwa duże i ważne (czytaj dochodowe) sektory, gdzie Java jest mocno obecna – sektor aplikacji dla korporacji i dużych przedsiębiorstw oraz Android.
Projekty takie jak Xtend o ile się przyjmie i rozwinie … to wielka fajna pomoc dla deweloperów, którzy chcą albo muszą 🙂 pisać na JVM. Jak dla mnie chociażby dla samych lambda wyrażeń i extension methods warto przyjżeć się Xtend. Brakuje mi tego w Javie i mam nadzieję, że prędzej czy później znajdzie się "oficjalnie" w języku – a póki co taki pre-compilator załatwi sprawę nieźle.
Oczywiście trudno powiedzieć czy obecnie warto używać tego w prawdziwych projektach. Być może jeszcze nie… ciekawe, czy projektem zainteresuje się jakiś duży gracz? IBM? Google? Oracle pewnie nie… Czas pokaże. Tak czy siak je jestem na tak 🙂
IMHO lepiej użyć Scali niż Xtend. Składnia Xtend wzoruje się na Scali, ale nie ma jej możliwości.
Przyjrzałem się temu Xtend i jakoś nie przemawia do mnie. Wygląda, że to tylko lukier syntaktyczny dla Javy. Na dzień dzisiejszy to w zasadzie zabawka, którą można w czasie wolnym obejrzeć. Ale w przyszłości kto wie.
Lambdy będą w Java 8, już niedługo. Ale jeśli już używać niszowego języka (używanie niszowego języka siłą rzeczy ma pewne wady), to ja bym wybrał coś co wyznacza trendy, a nie podąża za nimi. Czyli Scala.
ehhh, ja jednak uważam, że masło jest lepsze od margaryny.
Trochę poza tematem, przepraszam:
Stoczona została mała wojna o wyższości jednego języka na drugim np javy nad c++czy odwrotnie. Na temat c++ usłyszałem już wiele złego: np. że w tym to w ogóle lepiej nie programować bo to ślepa uliczka albo że c++ to całkowite zadupie programistyczne i dopiero zewnętrzne biblioteki "ucywilizowały" go trochę albo c++ to bagno i wielu wartościowych programistów się zmarnowało poświęcając czas temu językowi, tonąc coraz bardziej w tym bagnie i tak dalej … Jakieś zdanie mam, jestem jednak zwykłym amatorem więc zachowam je dla siebie.
Nie mogę jednak znaleźć odpowiedzi na pytanie: jaka jest sensowna alternatywa dla tego języka?. Co może i powinno według was całkowicie go zastąpić "tu i teraz" np. jeśli chodzi o aplikacje biurowe, aplikacje do obróbki materiałów audio/video, silniki gier itp. czyli coś w czym można ogarnąć duże projekty ale nie gigantyczne?
Jest np język D, ale pomimo tego, że istnieje dość długo nie zdobył popularności. Np. jeśli nie chcę już dłużej tworzyć w c++, nie chcę też uczyć się javy i c#, na co warto poświęcić swój czas?
Jeżeli nie Java czy C# (c# – nie polecam, chyba , że pracujemy dla MS), to pozostaje ci wędkowanie.
Język musi mieć duże zaplecze korporacyjne. Bez tego nie ruszysz. Można napisać soft nawet w LOGO, tylko co zrobisz gdy ktoś będzie chciał ktoś kupić od ciebie kod oferując grubą kasę? Zadaj sobie to pytanie i spróbuj odpowiedzieć.
Hm, wynika z tego z tego że jest jeden słuszny język i jest nim java?
Java to nowy COBOL. Kod zawsze znajdzie nabywcę. Za dużo ludzi zna Javę by było się czego obawiać.
Najpierw pluć na C++, więc wszyscy nowi programiści, nawet ciency, wybierają Javę.
Potem atak ilością: wszyscy używają Javy więc musi być lepsza!
Znane zagrywki.
Jak masz do wyboru zwykłą szczoteczkę lub elektryczną to wybierzesz tę elektryczną 🙂
kernel_loops pytał o zamiennik C++ w wybranych zastosowaniach. :
"aplikacje biurowe, aplikacje do obróbki materiałów audio/video, silniki gier itp."
a na to padają teksty w stylu:
" Za dużo ludzi zna Javę by było się czego obawiać."
Jezu Chryste, czego obawiać, bezrobocia, dokształcania? Jak ma się to do pierwotnego pytania? Napinacie się jakby od tego zależały kariery języków i wasze, a meritum zero. Wiem, że jest soft biurowy, a co z silnikami gier, grafiką, CAD? W czym się pisze nowy kod? Jakieś konkrety?
My piszemy CADa w Scali.
Coraz więcej gierek wychodzi na Javowy JMonkeyEngine.
Silniki oparte o C++ to relikt przeszłości.
Nie wszyscy tylko wszyscy najwięksi.
Java to ogromna baza bibliotek często ze źródłami gotowych do użycia i przede wszystkim działających. Od wersji 1.0. Tego nie masz ani w C/cpp ani w c#.
Po prostu naucz się kilku języków programowania w tym przynajmniej jednego wspierającego funkcyjny paradygmat programowania. Poszerzysz horyzonty i będziesz mógł wybrać język do przedsięwzięcia. Żaden język nie jest taki, że można go dobrze i wygodnie dostosować do każdej dziedziny zastosowań.
No i co najważniejsze będziesz w stanie sam coś powiedzieć odnośnie programowania w wybranym języku, nie będziesz musiał się podpierać opiniami innych ludzi. Punkty widzenia mogą być czasem bardzo skrajne, mogą zresztą wynikać z osobistych uprzedzeń i doświadczeń z przeszłości. Komuś coś tam 10 lat temu coś nie wyszło, wyrobił swoje zdanie i do tej pory może głosić dziwne rzeczy na temat danego języka.
Racja, ale dodam, że poza językiem jest jeszcze otoczka bibliotek, platform, api itp. Ogarnięcie tego w stopniu pozwajacym na pisanie czegoś konkretengo zajmuje więcej czasu niż nauka samego języka.
Punkty widzenia są różne, bez wątpienia. Jednak pewne cechy języka, np w wyniku których popełnia się w nim mniej błędów a równocześnie proces tworzenia czegokolwiek jest dłuższy i wymaga więcej troski, nie podlegają punktom widzenia a przynajmniej nieczęsto. Miałem też to na myśli.
Teoretyczne masz rację, ale tak naprawdę wszystko zależy od człowieka w jaki sposób rozłoży akcenty. Jednemu nie przeszkadzają wskaźniki, drugi uzna to za źródło wszystkich kłopotów.
Gdyby tak nie było, nie powstałaby taka dyskusja w tym temacie 🙂
"jeśli nie chcę już dłużej tworzyć w c++, nie chcę też uczyć się javy i c#, na co warto poświęcić swój czas? "
Bardzo sobie ograniczyłeś możliwości. Akurat nie chcesz używać najpopularniejszych języków do rozwiązań które wymieniłeś 🙂
D nie jest popularny bo nie może korzystać z bibliotek w C i C++. To ograniczenie jest barierą dla spopularyzowania wielu ciekawych języków. Ciekawym rozwiązaniem które omija te problemy jest Vala, ale to pieśń przyszłości. (choć na przykład Unity powstaje częściowo w tym języku). Jeżeli chcesz się ograniczyć do wymienionych zastosowań to na Twoim miejscu zostałbym przy C lub C++.
Wiem o tym, jednak te kilka języków, mimo ich przeważającej popularności, nie stanowi i nie będzie stanowić żadnego absolutu.
Podałeś konkretny przykład i o to chodziło. A jakie języki według was dzięki swym właściwościom zapewniają większą wykrywalność błędów, bo to mnie mocno ciekawi, może namiar na jakieś ciekawe materiały na ten temat?
Nowy c++ napawa jakimś optymizmem, miło, że ten język powoli ewoluuje ale czy będzie to kiedyś język, w którym mniej doświadczony/wprawny koder nie zrobi sobie kuku albo nie odstrzeli stopy:)?
Co do początkowego pytania, nie liczyłem na konkretną odpowiedź i tym razem. Pamiętam jaj na wykładach/laboratoriach wrogowie c++ mocno go opluwali, ale nie potrafili podać konkretnej alternatywy. Zło, którego w prosty sposób nie może/potrafi zastąpić nic innego, co za ironia …
Jest naprawdę wiele ciekawych języków. Jest C–, który prezentuję filozofię powolnej kompilacji, ale szybszego działania, jest też właśnie D. Ale przede wszystkim – wybór języka zależy od typu programu, który chcesz napisać. Chcesz pisać program, który operuje w internecie, jest klikalny i prosty w kodzeniu – wybierz Javę lub C#. Chcesz napisać program, który nie musi być super-szybki, ale się musi dobrze dogadać z systemem (operacje na plikach, etc etc), ma być łatwy w utrzymaniu i – poniekąd – przenośny – wybierz Pythona (np. portage Gentoo jest napisane w tym języku i bardzo to sobie chwalę). Chcesz napisać program, który ma być szybki, pobierać i przetwarzać szybko dane, operować na wskaźnikach – wybierasz C++, który łączy wygodę programowania i szybkość działania kodu. Chcesz kodzić jądro Linuksa, niskopoziomowy program, sterownik, jakiś programik systemowy – bierz C.
"Nowy c++ napawa jakimś optymizmem, miło, że ten język powoli ewoluuje ale czy będzie to kiedyś język, w którym mniej doświadczony/wprawny koder nie zrobi sobie kuku albo nie odstrzeli stopy:)?"
Dla mnie zmiany w C++ są niewystarczające, a początkującym w cale nie ułatwi nauki, tylko wręcz utrudni.
Właśnie i Javie i C# mniej doświadczony programista zrobi zazwyczaj mniej krytycznych błędów niż w C/C++. Jednak każdy język wymaga wiedzy i umiejętności. Można by pewnie zrobić język w którym niezwykle trudno robiłoby się błędy, ale skutkowałoby to utratą wyrazistości i wydajności.
"Ciekawe" macie spostrzeżenia na temat języków programowania. Czy naprawdę nie ma tu żadnego programisty funkcyjnego?