People of Lava pokazuje telewizor z Androidem

A Javę/.NET co wyprze ?
Clojure :OD ?

Jakbyś 15 lat temu napisał „a visual basic co wyprze? java :OD?”, też pewnie wszyscy by się śmiali :>

Być może w zastosowaniach w jakich obecnie są wykorzystywane dane języki, wiele się nie zmieni, ale wchodzą zupełnie nowe nisze, które w krótkim czasie stają się mainstreamem. Obecnie to programowanie na urządzenia mobilne (gdzie rządzi Objective-C i Java aktualnie) czy programowanie w chmurze (tu nie ma jeszcze chyba lidera), ale takich nowych obszarów będzie się pojawiać więcej i nowe języki będą przejmować kontrolę.

Każdy język po jakimś czasie zostaje zepchnięty do niszy.
Jednak na razie nic nie wskazuje na to, aby Javie to groziło w ciągu najbliższych 10 lat. Wiadomo już, że .NET jej nie zabił, wiadomo też że języki skryptowe takie jak Ruby też nie. Bardziej możliwe, że Java zostanie zjedzona przez jakiś język na JVM, ze względu na zachowanie kompatybilności z dotychczasowym kodem. Clojure jest zbyt egzotyczny, ale Scala… teoretycznie ma jakieś tam szanse.

Królik: Chciejstwo też można leczyć.

Jakie chciejstwo? Ja wcale nie chcę aby Scala stała się następną dużą rzeczą, choć już narobiła dużo szumu. Scala i Clojure powinny pozostać IMHO niszowe. Przynajmniej będą postrzegane jako języki dla pro, a nie dla dzieci klepiących frontendy web.

Królik: ja klepie frontendy webowe. Chcesz się zmierzyć na dowody osobiste ?

Chciejstwo to głoszenie przepowiedni na najbliższe 10 lat.

Jakich przepowiedni? Między przepowiednią a stwierdzeniem, że obecnie nie widać jakichkolwiek oznak wypierania Javy skądkolwiek, jest duża różnica. Raczej widać trendy odwrotne. Dzięki Googlowi Java może się rozpanoszyć nieźle na urządzeniach mobilnych.

@Bastian: Nie bierz tego do siebie, ale generalnie pisanie frontendów webowych, czy w ogóle jakichkolwiek aplikacji w oparciu o gotowe frameworki to nie jest zajęcie wymagające wybitnego intelektu. Wiem, bo niegdyś pisałem. Mam też ciągle styczność z ludźmi, którzy wpisują sobie takie rzeczy w CV, a jako programiści są tragiczni (rekrutuję). Wystarczy zahaczyć o jakiekolwiek rzeczy trącące podstawową algorytmiką, programowaniem współbieżnym czy inżynierią oprogramowania i leżą. Być może Ty jesteś wyjątkiem. Na szczęście programowanie na sklejaniu gotowców się nie kończy i są ciekawe wyzwania. Do takich wyzwań właśnie Java i C++ się nadają… słabo.

Dzięki Googlowi Java może się rozpanoszyć nieźle na urządzeniach mobilnych.

Jeszcze kilka pozwów ze strony Oracle i Java na urządzeniach mobilnych będzie oznaczała, jak wcześniej, jedynie gry w J2ME.

A Ty wierzysz w to, że Google się obrazi, spakuje zabawki i pójdzie do innej piaskownicy?

@Królik: ale wiesz, że Oracle pozwało Google o patenty związane z obsługą Javy, np. plików class, prawda?

To, czy Google się obrazi czy nie, może nie mieć znaczenia.

Skończy się na tym, że Google zapłaci Oraclowi aby się odczepił (czyli wykupi licencję) i tyle. Tak jak większość tego typu spraw.

@Oo: chcesz powiedzieć, że aplikacje webowe piszesz/pisałbyś w C++?

Poza tym Java czy .net nie nadają się ani na desktopy, ani do małych i średnich aplikacji webowych. Są po prostu masakrycznie wolne i zbyt zasobożerne

Java ma pewne wady, ale zupełnie nie takie, o jakich piszesz. Ale po kolei:

1. Masakrycznie wolne? Mit obalany wielokrotnie, Java jest w tej samej lidze co C/C++; pewne operacje wykonuje wielokrotnie szybciej (new, przekazywanie stringów), na innych nieco dostaje (sprawdzanie tablic, zbyt częsta alokacja na stercie). Jednak gra jest nierówna, bo Java musi być fail-fast, a C++ może oszukiwać za pomocą „undefined behaviour”. Mimo to różnice rzadko przekraczają 2x przy dobrze napisanym kodzie.

2. Zbyt zasobożerne? Po czym wnosisz? Zbyt zasobożerne to mogą być pewne aplikacje jak się nie umie programować albo dołącza się tony zbędnych bibliotek. Sam JVM nie daje narzutów większych niż kilka MB. Co to jest kilka MB, kiedy większość ludzi ma zainstalowane po 1 – 4 GB RAMu?

Ale przecież wieloplatformowe jest także C++, o ile używa się odpowiednich bibliotek (np. Qt)

Nie było, nie jest i nie będzie. Zacznijmy od tego, że nie jest nawet w pełni „jednoplatformowe”, tzn. na jednej platformie przy upgradzie wersji Qt albo kompilatora masz duże szanse się wysypać. Patrz: migracja KDE z Qt 3 na 4. Albo spróbuj zmigrować jakiś duży projekt kompilowany GCC 3.x na GCC 4.x.

C/C++ jest jak najbardziej wieloplatfomowe. Jedynie gotowe biblioteki nie zawsze są dostępne na wszystkie platformy, ale nie trzeba z nich korzystać, oczywiście przysparza to masę roboty ale właśnie dzięki C/C++ można napisać cały system z oprogramowaniem na każdy sprzęt. To zasadniczo jest właśnie profesjonalizm, tworzenie systemów wbudowanych. Zaś pisanie aplikacji z niewykorzystaniem gotowych bibliotek to jak wspomniał @oO zwykłe wyrobnictwo. Oczywiście nie jest też proste i nie ujmuje nakładu pracy takich ludzie, jednak nie jest to bardzo zaawansowane i profesjonalne programowanie.
Java i .Net potrzebują środowisk najczęściej właśnie napisanych w C/C++. Tak naprawdę ciężko porównywać tak różne technologie, C/C++ kompiluje się do postaci w pełni binarnej dostosowanej do architektury danego sprzętu. Można zoptymalizować taki program dowolnie. Zaś przy Java i .Net jesteśmy ograniczeni tym co przygotowali nam autorzy środowiska. Jakby się nie kombinowało nie uzyska się większej wydajności niż w pełni natywny kod.

P.S. Co do „Mit obalany wielokrotnie” to te dowody bardzo słabe. Z reguły przedstawiali je programiści Java który nie potrafili zoptymalizować programów w C/C++ (bądź specjalnie tego nie robili).

@makak C nie jest przestarzałe, to że coś jest dla Ciebie trudne nie znaczy że jest zacofane. Przy C/C++ liczy się efekt końcowy, lepsza optymalizacja, wydajność i mniejszy rozmiar programu, jest to postawione ponad wygodę programisty. Wiadomo że przy C/C++ trzeba się wielokrotnie bardziej napracować niż przy Java i .Net ale to nie programiście ma być dobrze tylko odbiorcy programu.

C a C++ to dwa różne języki i nie należy ich mylić. C++ jest wieloplatformowe, jeśli zgodzisz się na ograniczenie się do niewielkiego podzbioru języka, z którym poradzą sobie co bardziej egzotyczne kompilatory. Nawet przenoszenie kodu z VS na GCC i na odwrót potrafi przysporzyć niezłych problemów. I to całkowicie abstrahując od bibliotek. Popatrz sobie na Mozilla C++ portability guide.

C++ można napisać cały system z oprogramowaniem na każdy sprzęt

No zgoda i co z tego?
JVM też można napisać na każdy sprzęt.

To zasadniczo jest właśnie profesjonalizm, tworzenie systemów wbudowanych

Tworzenie systemów wbudowanych jest względnie łatwe. W ogóle programowanie niskopoziomowe jest dość łatwe. Nie wiem, jak to może świadczyć o profesjonalizmie bądź jego braku.

http://www.yosefk.com/blog/low-level-is-easy.html

Jakby się nie kombinowało nie uzyska się większej wydajności niż w pełni natywny kod.

Truizm. I zarazem tautologia, bo Java kompiluje się do kodu natywnego.

P.S. Co do “Mit obalany wielokrotnie” to te dowody bardzo słabe. Z reguły przedstawiali je programiści Java który nie potrafili zoptymalizować programów w C/C++ (bądź specjalnie tego nie robili)

Często spece od C/C++ nie potrafili podać lepszych implementacji.
http://blog.zabiello.com/2009/03/28/scala-lang

A nawet jeśli jest tak jak twierdzisz, to i tak nie ma to znaczenia. Żyjemy w czasach, gdzie aplikacje pisze się w takich wynalazkach jak:
- JavaScript
- ActionScript
- PHP
- Python, Ruby

Wszystko to języki o rząd wielkości powolniejsze niż Java i nikomu to nie przeszkadza. Z kolei na serwerach coraz bardziej liczy się skalowalność a nie surowa wydajność na jednym rdzeniu. Tu C++ jest zjadany na śniadanie przez choćby Erlanga, Scalę czy nawet Javę. Może pochwalisz się, jakie to cudowne optymalizacje kompilatory C++ potrafią robić na kodzie wielowątkowym?

C++ jest wieloplatformowe, jeśli zgodzisz się na ograniczenie się do niewielkiego podzbioru języka, z którym poradzą sobie co bardziej egzotyczne kompilatory

Analogicznie – Java jest wieloplatformowa, jeśli zgodzisz się na ograniczenie do niewielkiego podzbioru języka, z którym poradzą sobie co bardziej egzotyczne JVM.

Truizm. I zarazem tautologia, bo Java kompiluje się do kodu natywnego.
A nie do bytekodu, wykonywanego przez JVM?

Analogicznie – Java jest wieloplatformowa, jeśli zgodzisz się na ograniczenie do niewielkiego podzbioru języka, z którym poradzą sobie co bardziej egzotyczne JVM.

No i właśnie to jest bzdura. Każda JVM certfikowana przez Suna (Oracle), jest w 100% zgodna ze standardem (licząc z dokładnością do bugów, ale są one niezmiernie rzadkie). Jeżeli jesteś producentem JVM, to żeby mieć prawo do nazywania tego Javą, musisz poddać swój produkt oficjalnej certyfikacji.
Ostatnio bez ani jednej zmiany odpaliłem aplikację pisaną i skompilowaną pod Windows, która z założenia nie miała być przenośna, pod… AIXem. Więc to nie jest tylko teoria.

Ponieważ nie ma certyfikacji na kompilatory C++, to każdy sobie rzepkę skrobie. Ba, nie wiadomo nawet jaki to jest dokładnie bezpieczny podzbiór C++. Wyjątków można używać? Dużo osób twierdzi, że nie. hash_map można? Też nie. Pokaż mi JVM, na której nie wolno używać wyjątków albo na której nie działa HashMap.

Do tego dochodzi problem bibliotek. Biblioteka standardowa C++ jest niezmiernie uboga (nawet licząc Boosta), stąd bez zewn. bibliotek nie da się sensownie programować. Teraz bierzesz 5 różnych bibliotek od różnych producentów i się nagle okazuje, że cała wieloplatformowość ogranicza się do Windows + Linux.

A nie do bytekodu, wykonywanego przez JVM?

Dla obu języków sekwencja jest identyczna:
1. kod źródłowy -> bajtkod
2. bajtkod -> kod natywny

W C++ obie czynności robi za jednym zamachem kompilator, w Javie jest to rozdzielone pomiędzy javac i JVM HotSpot 1 lub HotSpot 2.

No i właśnie to jest bzdura. Każda JVM certfikowana przez Suna (Oracle), jest w 100% zgodna ze standardem (licząc z dokładnością do bugów, ale są one niezmiernie rzadkie).
(…)
Pokaż mi JVM, na której nie wolno używać wyjątków albo na której nie działa HashMap.

J2ME/CLDC.

Ponieważ nie ma certyfikacji na kompilatory C++

Na całe szczęście. Kojarzysz Apache Harmony?

GTAIV używa .NET, więc coś w tym musi być

Sorry Reddie, ale w J2ME są zarówno wyjątki jak i hashmapy. J2ME to jest osobna specyfikacja. Też wiadomo, co jest dostępne, a co nie, też jest certyfikowana.

Apache Harmony nie jest certyfikowane, ale jest w 99.9% zgodne. Nie słyszałem, żeby programiści Androida skarżyli się na jakieś problemy z kompatybilnością. Prawdopodobnie jeśli zapadnie ugoda między Oracle i Google, będzie w 100% kompatybilna i certyfikowana.

@Królik: uops, faktycznie. Tzn. dokładnie rzecz biorąc to jest hashtable, ale odpowiada mniej więcej za to samo. Tym niemniej chyba nie powiesz, że to co jest tutaj daje pełną zgodność z innymi JVM:
http://download.oracle.com/javame/config/cldc/ref-impl/cldc1.1/jsr139/allclasses-frame.html

Co do Apache Harmony: wątpię, bo Google IIRC nie miało zbyt wiele wspólnego z tym projektem. Duża część zasobów

Napisałem, że to jest osobna specyfikacja. Taka okrojona Java. Ale w ramach tej okrojonej Javy znowu, język wszędzie obowiązuje taki sam. W C++ problemy zaczynają się na poziomie składni języka. Do tej pory są problemy z pełną zgodnością z ANSI/ISO C++ 2003.

@królik Google zostało pozwane przez Oracle za Jave a Novell za Mono nie…czyli java jest bardziej zagrożona patentami nie ? Tym się nie przejmują antymonowi hipokryci ?

@Królik: język wcale nie jest taki sam. W J2ME nie ma np. generics.

Język jest taki sam. Jest zgodny z Java 1.4.

Natomiast kompilatory C++ nie są zgodne z __żadną__ wersją standardu. Zawsze są jakieś głupie odstępstwa – albo czegoś nie robią do końca dobrze (zwykle w zakresie templates), albo dopuszczają coś o co nikt ich nie prosił (np. alokacja tablic o zmiennym rozmiarze na stosie). Jakoś dziwnym trafem nikt nie robi „Java portability guides” ani „Java style guides”, tak jak robią Google i Mozilla (i pewnie wiele innych firm) dla C++, w których zabraniają np. alokacji w konstruktorach.

Wiadomo że przy C/C++ trzeba się wielokrotnie bardziej napracować niż przy Java i .Net ale to nie programiście ma być dobrze tylko odbiorcy programu.

Odbiorcy programu zazwyczaj jest dobrze, jak mniej zapłaci. A czas pracy programisty jest znacząco bardziej kosztowny od dodatkowego procka w komputerze, na którym soft chodzi.

Odbiorcy programu zazwyczaj jest dobrze, jak mniej zapłaci.

Ewnetualnie jak dostanie więcej ficzerów lub ładniejsze GUI. Co sprowadza się do jednego.

@tomaszkubacki: Brawo, wlasnie odkryles, ze Stallman bredzil i/lub sial FUD odnosnie Mono. Zaskoczony?

Zjadło mi nawiasy.
Miało być:

C++ nie oferuje nic ponad parę (C + jakiś wysokopoziomowy język), gdzie jakiś wysokopoziomowy język to np. {Python, Ruby, Clojure, Scala, F#}.

C może i jest ponadczasowe, ale na skalarne procesory, bo C to przenośny assembler na takie właśnie procesory. A te zaczynają powoli być przestarzałe. Ponadczasowy to jest lisp.

@królik to napisz z zespołem jakąś większy program w C to zrozumiesz dlaczego lepiej pisać w C++ lub Javie. A składanie aplikacji z modułów C w połączeniu z językiem skryptowym to dopiero gehenna (wyszukiwanie błędów i pisanie testów same problemy). C jest świetny do sterowników lub gdy czas jest mniej ważny niż wydajność aplikacji (chociaż takie benchmarki jak http://shootout.alioth.debian.org/ dają do myślenia).

Przy C/C++ liczy się efekt końcowy, lepsza optymalizacja, wydajność i mniejszy rozmiar programu, jest to postawione ponad wygodę programisty. Wiadomo że przy C/C++ trzeba się wielokrotnie bardziej napracować niż przy Java i .Net ale to nie programiście ma być dobrze tylko odbiorcy programu.

A jak klientowi zależy na szybkim wprowadzeniu aplikacji bez bugów?
Aplikacje korporacyjne pisze się prawie tylko w językach zarządzanych.

Mikołaj: ten post to chyba nie do mnie. Jakie jezyki skryptowe? Wymieniłem tylko 2, żeby zwolennicy skryptowych się nie obrazili. Pozostałe 3: Clojure, Scala i F# nie są językami skryptowymi (choć można powiedzieć, że łączą zalety Javy/C# ze skryptowymi, ale są statycznie typowane). Chodziło mi tylko o pokazanie, że jestem raczej zwolennikiem pisania całości w językach wysokopoziomowych (blisko LISPu), a tam gdzie trzeba zejść do sprzętu, można skrobnąć jakiś mały modulik w C.

A C++ lepiej unikać, bo tam masz praktycznie wszystkie te samy problemy co w C i na dodatek złudne poczucie bezpieczeństwa – nie skaluje się to do dużych aplikacji. Proteza na protezie zamiast porządnie zaprojektowanego wysokopoziomowego języka.

@mc: W zestawie, który wymieniłem jest jeden z rodziny LISPów – Clojure jest bardzo blisko LISPa. Scala też, w sensie mechaniki, tylko ma inną składnię.

Te nowoczesne (proste w użyciu dla klepaczy kodu i myślące za nich) technologie na potrzeby np. JVM pisane są właśnie w C++

Tak, a kompilatory C++ w C, a pierwsze kompilatory C w assemblerze. To nie jest żaden argument.

Ale jeśli to aplikacja desktopowa, to używanie Javy/.neta jest po prostu bezczelnym sraniem na użytkownika końcowego.

Możesz rozwinąć? Używam kilku desktopowych aplikacji Javowych i uważam, że nie mają sobie równych. Np. JEdit albo IntelliJ IDEA. Zasobożerności czy powolności nie zauważyłem. Za to zauważyłem ślamazarność OpenOffice’a. Kurna, to g*** się przycina jak piszę tekst na slajdach. Nigdy, ale to nigdy najcięższe IDE Javowe na starej Javie i starym kompie tak mnie nie wpieniło zacinaniem się.

Kiepscy programiści zwalają winę na język. A prawda jest taka, że zarówno w Javie jak i w C++ można pisać szybkie i lekkie aplikacje dekstopowe. Tylko trzeba umieć.

Te nowoczesne (proste w użyciu dla klepaczy kodu i myślące za nich) technologie na potrzeby np. JVM pisane są właśnie w C++

To weź sobie otwórz katalog z JRE i zobacz ile kodu jest natywnego (skompilowanego C++) a ile napisanego w Javie (archiwa .jar). Tylko niewielki trzon JVMa jest napisany w C++. Cała otoczka jest napisana w Javie. Dlatego dużo łatwiej przenieść JVM na nowa platformę niż .NET – mniej kodu do portowania.

Fakt 1) Wszystkie biblioteki GUI w Javie ssą pod Uniksami, co do jednej. – Skutek: Prawie nikt nie pisze normalnych aplikacji w Javie. Ja przynajmniej nie odczuwałem potrzeby na żadną taką aplikację od długieeeeego czasu. Kiedyś testowałem Azureus, ale był mega wolny. Eclipse również mega wolny. Netbeans – używalny, ale ślamazarny. Ssą to znaczy, że nie tylko są wolne, ale i także się nie integrują, jednak to nie jest problem Javy jako języka.

Fakt 2) Języki zarządzalne w teorii nie muszą być wcale wolniejsze (ale to zależy też od języka) od natywnych odpowiedników. Czy kod się kompiluje statycznie, czy JITuje w trakcie uruchomienia – to nie ma większego znaczenia. Kompilatory dla tych nowoczesnych języków nie zdążyły jeszcze po prostu dostatecznie dojrzeć. Mono oferuje nawet tryb kompilacji zwany AOT – z programu w C# powstaje *całkowicie statyczna* binarka, podobnie do takiej jaka by powstała po uruchomieniu GCC. Powtarzam: w teorii nie wolniejsza od czegoś skompilowanego przez GCC. Nawet pewnie by się dało zrobić kompilator C#a dla backendu GCC – wyłączając pewne dynamiczne funkcje tego języka. Kontynuacja w kolejnym podpunkcie.

Fakt 3) Niektóre języki zawsze będą wolniejsze od innych – nie ważne jak dobry kompilator powstanie. Np. brak silnego typowania ogranicza możliwość kompilatora do podjęcia decyzji w trakcie samej kompilacji – Javascript, Python do pewnego stopnia zawsze będą wolne. Nie lubię też Javy z powodu jakie ograniczenia narzuca na programistę np. brak możliwości tworzenia struktur, wszystko na stercie, brak wskaźników, dziwne rozróżnianie int od Integer – ogólnie czuć te ograniczenia – wiesz jak coś zrobić dobrze i szybko, a język na to nie pozwala. C# te rzeczy poprawia – według mnie C# w teorii może być dużo szybszy od Javy właśnie przez to, że można napisać kod, który jeden w jeden będzie działać binarnie tak jak taki napisany w C++. Pewną przeszkodą w porównywaniu wydajności może być odśmiecacz (Garbage Collector), który w pewnych przypadkach przyspiesza, a w innych wadzi – ale odśmiecacz można też dorzucić i do C i C++ – w D jest by design.

Fakt 4) Wprawdzie mówi się, że C jest szybkie, ale pokuszę się o stwierdzenie, że C++ jest jeszcze szybsze. C zachęca używania wskaźników, gdzie C++ potrafi wstawić po prostu struktury. (templates vs. macros) C++ jest szybszy, bo pozwala robić te same rzeczy jakie potrafi C, ale w łatwy i wygodny sposób. W C programista (np. ja ^^) często nie wybiera najwydajniejszego rozwiązania z takich właśnie powodów. Ktoś mi kiedyś zarzucił po takim stwierdzeniu, że chyba kompletnie nie znam się na programowaniu. Chciałbym przypomnieć, że C++ to nadbudówka C – większość „bardzo poprawnych” programów w C się poprawnie skompiluje. Nie używając RTTI, polimorfizmu … używjąc szablonów mamy całkiem szybki arsenał.

Opinia: Według mnie korporacyjność Javy i .NET są dużymi przeszkodami dla szerokiej adaptacji tych środowisk – osobiście przekonałem się do C#’a, ale szczerze mówiąc nie palę się do używania tych rozwiązań właśnie przez to nakierunkowanie na Windows – z powodu Microsoftu, niedokończone implementacje w postaci Mono… Java z kolei nie używa technicznie pociągających rozwiązań. Zaletą dla niektórych może być prostota – nie dla mnie. Ze swoimi wadami i ograniczeniami nadal przyjemnie mi się programuje w C/C++ – wszelkie moje potrzeby GUI realizuje Qt, które bez jednej zmiany w kodzie pozwala zrobić binarkę zarówno na Windows jak i Linuksa – po co mi więcej?

Uff

@Rsh
Nic dodać, nic ująć.

Ale fakty do wyznawców javy czy .neta nie dotrą.

Np. brak silnego typowania ogranicza możliwość kompilatora do podjęcia decyzji w trakcie samej kompilacji – Javascript, Python do pewnego stopnia zawsze będą wolne

Niekoniecznie. Po prostu inaczej się je kompiluje – wykorzystuje się tracing – nie wiem jak to przetłumaczyć na polski. Przykładem może być kompilator TraceMonkey Mozilli.

Nie lubię też Javy z powodu jakie ograniczenia narzuca na programistę np. brak możliwości tworzenia struktur, wszystko na stercie, brak wskaźników, dziwne rozróżnianie int od Integer

Nie wszystko jest tworzone na stercie – w pewnych przypadkach JVM może zdecydować się zaalokować obiekt na stosie. Typy proste („int”) zostały wprowadzone właśnie ze względu na wydajność. Z resztą autoboxing został dodany już do Javy 5.

Pewną przeszkodą w porównywaniu wydajności może być odśmiecacz (Garbage Collector)

Polecam poczytać artykuły dot. JVM. Sporo ich można znaleźć np. na stronach IBM.

Ale fakty do wyznawców javy czy .neta nie dotrą.

Fakty, czyli benchmarki? O ile średnio rzeczywiście może wyjść że kod napisany w C++ jest nieco szybszy od kodu w Javie, trzeba też wiedzieć jak to się przekłada na rzeczywistą szybkość oprogramowania. Gdyby numeryczna wydajność miała decydujące znaczenie, pewnie do dzisiaj pisałoby się w Fortranie. Tymczasem wydajność wielu aplikacji jest IO-bound, czy wręcz user-bound i kwestia użytego języka programowania niewiele tu wnosi.

Post Scriptum.

Opinia: Według mnie korporacyjność Javy i .NET są dużymi przeszkodami dla szerokiej adaptacji tych środowisk

Java i .NET zostały szeroko zaadaptowane. Spójrz chociaż na ogłoszenia o pracę.

Java i .NET zostały szeroko zaadaptowane. Spójrz chociaż na ogłoszenia o pracę.

Oczywiście źle to sformułowałem. Zgadza się, jest dużo ofert o pracę, ale ja myślę o takich środowiskach geekowskich bardziej i adaptacji 4fun. Widzę mój desktop i widzę C/C++. Spójrz na pulpit Windowsa, nadal większość C/C++. Pulpit MacOSX? To są wybory programistów bez narzucania przez firmę. To jest adaptacja poprzez wybór …

@el.pescado: Możesz podlinkować do co ciekawszych artykułów może? Byłbym wdzięczny.

Jeśli chodzi o środowiska geekowskie to wystarczy popatrzeć na projekty OpenSource. Większość to C i Java (przynajmniej na Ohloh i SourceForge). Natomiast jeśli chodzi o środowiska hackerskie powiązane z uczelniami, to dominują wszelkiej maści języki funkcyjne: CL, Clojure, Scala, F#, OCaml, Haskell.

W C++ programowałem kiedyś dużo i dziękuję: fajnie się robi w tym proste rzeczy, ale robienie czegoś poważniejszego, w zespole, to masakra. Języki, w których przez pomyłkę dowolny fragment kodu może niejawnie uszkodzić dowolną strukturę danych, nie skalują się do dużych projektów. W ogóle ten język to prowizorka, trudno w nim znaleźć jakiś feature, który by nie był pod jakimś względem problematyczny (niestety projektanci C++ chyba nie słyszeli o czymś takim jak ortogonalność). Jeśli ktoś wybiera programowanie w C++ z powodu rzekomego „braku ograniczeń” w C++, to oznacza, że albo nie zetknął się jeszcze ze złożonymi problemami programistycznymi, albo nie zna żadnych innych elastyczniejszych języków, albo lubuje się w skomplikowanych rozwiązaniach (jest taki typ programistów, którzy myślą, że jak napiszą jakiś skomplikowany kawałek kodu, to że są tacy pro).

Można się spierać, że Java nie ma paru rzeczy jakie ma C++, ale już w przypadku porównania C++ ze Scalą (na JVM) w kategorii „język wysokiego poziomu” C++ to zabawka.

PS: Swing w Javie to porażka dla użytkownika. Pełna zgoda. Sun totalnie olał swojego czasu GUI w Javie. Traktował GUI bardziej jako dodatek aby można było robić narzędzia konfiguracyjne a nie porządne aplikacje. No, ale jest przecież SWT… a ono się integruje bardzo ładnie.

@el.pescado
„Java i .NET zostały szeroko zaadaptowane. Spójrz chociaż na ogłoszenia o pracę.”

W tym właśnie problem, bo powinny być stosowane w wąskim segmencie rynku, a nie wpychane na siłę wszędzie gdzie się da, od tak, bo są trendy i jest dużo słabo wykwalifikowanej siły roboczej.

A brak wskaźników w Javie to tragedia tej platformy. Po prostu katastrofalny błąd projektowy, który uniemożliwia normalne tworzenie w tym czegokolwiek.

A brak wskaźników w Javie to tragedia tej platformy. Po prostu katastrofalny błąd projektowy, który uniemożliwia normalne tworzenie w tym czegokolwiek.

LOL. Java ma wskaźniki, dziecko. Java nie ma arytmetyki wskaźnikowej. Pokaż mi uzasadnione użycie arytmetyki wskaźnikowej w C++.

A co do słabo wykwalifikowanej siły roboczej, to nie zauważyłem, aby koderzy C++ byli jakoś lepiej wykwalifikowani. Wystarczy spojrzeć na denną w działaniu jakość kodu OpenOffice czy co niektórych aplikacji KDE. Niestety najczęściej są to zadufani w sobie kolesie, którzy myślą, że skoro rozkminili wskaźniki i dziedziczenie wirtualne, to potrafią programować. Tacy goście są bardziej niebezpieczni w projekcie, niż koderzy Javy, którzy nauczyli się Javy dla kasy.

W tym właśnie problem, bo powinny być stosowane w wąskim segmencie rynku, a nie wpychane na siłę wszędzie gdzie się da, od tak, bo są trendy i jest dużo słabo wykwalifikowanej siły roboczej.

Nikt Javy na siłę nigdzie nie wpycha, tylko po prostu Java potrafi lepiej wykorzystać drogie zasoby niż C++.

@Królik:

Tacy goście są bardziej niebezpieczni w projekcie, niż koderzy Javy, którzy nauczyli się Javy dla kasy.

Pełna zgoda. Co gorsza jak już rozkminią, to czują silną wewnętrzną potrzebę użycia każdej psychodelicznej, zaciemniającej kod, konstrukcji C++ w projekcie. Szczególnie zabawny jest kod gościa, który przeżywa akurat fascynację template’ami.

Powinni nakręcić film p.t. „Java – Zamknięty umysł”.

Widzisz, zaawansowani programiści Javy i ich zabawki się szybko rozwijają. Mamy różne fajne nowe rzeczy jak JavaFX, Groovy, Clojure czy już wspomniana przeze mnie wcześniej Scala. W ramach nich z kolei jest rozwijanych wiele technologii jak choćby ScalaZ, Lift albo Squeryl, które swoją innowacyjnością popychają całą dziedzinę do przodu.

Natomiast jak programiści C++ pakowali zapytania SQL w (non-unicode) stringi 20 lat temu, tak będą pakowali je przez kolejne 20 lat.

BTW: Cały czas czekam na uzasadniony przykład użycia arytmetyki wskaźnikowej w C++. No, oO, dawaj.

W tym właśnie problem, bo powinny być stosowane w wąskim segmencie rynku

Właśnie C++ powinno być stosowane w wąskim segmencie rynku.

a nie wpychane na siłę wszędzie gdzie się da

Java nigdzie nie jest wpychana na siłę. Może .NET trochę, ale raczej na obszarze zastosowań Javy.

od tak, bo są trendy i jest dużo słabo wykwalifikowanej siły roboczej.

Wiem, że czasy kiedy bajty były cenniejsze od złota, wszystko pisało się w asemblerze a Fortran był największą ekstrawagancją były romantyczne, ale świat się zmienia i trzeba pogodzić się z faktem że nie trzeba być nie wiadomo jakim h4xxorem żeby napisać notatnik. Podobnie jak 90% softu użytkowego.

@Rsh: co do artykułów, Java theory and practice: Garbage collection and performance – kilka ciekawostek odnośnie garbage collectora. Co do zamkniętego umysłu – w tym wypadku akurat obóz C++ zamyka się na wszelkie alternatywy;)

@el.pescado: Dzięki za linka, zaraz przeczytam, ale chciałem się odnieść do tego co mówiłeś o tracingu. Temat jest niezwykle ciekawy owszem i niecierpliwie będę oczekiwał rozwoju w tej dziedzinie – jednak z tego co piszą ludzie nawet zajmujący się tym temat, nie ma żadnego hurra optymizmu na temat ostatecznej optymalizacji ani czy lepszy jest tracing czy inne rozwiązania … i nie wiem czy to jest problem tej samej natury, ale śmiem podejrzewać, że sprowadzenie takiego dynamicznego kodu do postaci względnie statycznej jest równoznaczne z którymś z problemów NP-trudnych z jakimi boryka się aktualna algorytmika. Rozwiązania jakie istnieją nie są optymalne i nigdy prawdopodobnie nie będą, więc o ile w teorii pewnie można zrobić taki odpowiedni tracing, to zapomnij o sensownej złożoności. Przy czym chętnie będę wyprowadzony z błędu. Natomiast w przypadku silnie typowanych języków z nutką dynamizmu sprawa jest dużo bardziej komfortowa – szczególnie C# tak jak pisałem. Java może i zgadywać czasami co wrzucić na stos, ale ja jej nie ufam. (wybaczcie)
Pozdrawiam.

Arytmetyka wskaznikow to jeszcze pikus. Ale C++ ma cos lepszego – swoj wlasny duplikat arytmetyki wskaznikow (jak ktos np. czytal C++ FQA, to wie, ze niezbyt udolne duplikowanie funkcjonalnosci C to takie hobby tworcow jezyka). Zdarzylo mi sie osobiscie zrobic obsuwe releasujac nastepujacy kawalek kodu:

costam = *(wektor.begin() + a1 – a2);

Oczywiscie a1 i a2 sa dobrane tak, ze odwolujemy sie do elementu istniejacego w naszym std::vectorze. Dobrze znajacy C++ od razu dostrzega, ze cos tu moze pojsc nie tak – od czasu do czasu kod klienta wysypywal sie (jakis runtime-check, chyba nawet nie wyjatek). Dalem ciala. Ale nie znam innego jezyka, ktory potrafilby tak mocno kopnac w dupe za cos tak idiotycznego.

PS Oczywiscie powinno byc *(wektor.begin() + (a1 – a2)) – niech zyje przeladowywanie operatorow i sensowne runtime-checki!

Coście się do Java przyczepili? Że rt.jar ma dużo klas i ogólnie JVM to głównie sam bytecode?
A kompilatory dla C/C++ optymalizujące w trakcie wykonywania to co innego robią niż JIT w JVM?
A widzieliście z czego się FireFox głównie składa? Z JavaScriptu + XUL pracującego na jego własnej „maszynie wirtualnej”.