Proč je Java za zenitem

Co za efektivní jazyky a platformy používají burzovní systémy a banky? To je oblast, kde mám za to, že Java vládne.

Znam nekolik bank, kde pouzivaji javu. Znam jeden obrovsky automobilovy koncern, kde kde se java pouziva k systemum, ktere ridi vyrobu (a jsou to casto desktop aplikace).

Ze je neco v jave 3x pomalejsi nez v C(++) je proto, ze to nekdo blbe napsal.

Je, ale, pravda, ze java je na muj vkus trochu zatuhla, to se ale nekomu muze jevit jako vyhoda, komu vadi konzervativnost a chuda syntaxe javy, muze pouzit treba scala.

Java je multiplatformni, proto ji nelze srovnavat s .net, je chudsi, prave proto ze je odstinena od vlastniho operacniho systemu.

Objective-C je zrudnost.

Ale souhlasim, ze situace s javou pod oraclem, neni nejlepsi.

Nejake data mate?
Zopar vasich tvrdeni mi pride dost argumentacne nepodlozenych
1) Prozatímním ostrůvkem zůstává Android. Ostruvek si spojujem s niecim dost malym btw akyze je momentalne podiel Androidu na trhu?
2) Na serverech čím dál více kraluje .NET, zase mate nejake data, tu je nejaka statistika http://blog.websitesframeworks.com/2013/03/programming-language-statistics-in-server-side-161/ zopar zaverov :
Java is server-side programming language leader in high traffic sites.
ASP.NET language usage is decreasing.

Vase usudok o zpracování obrovského množství dat je dost mimo. Niektore z technologii ktore su celkom in momentalne su prekvapujucu napisane v tomto "vlastne uz mrtvom" jazyku vid Hadoop, Neo4j.
Pride mi, ze mate celkom nechut k Jave a vase zavery su tym celkom ovplyvnene. Cisto prakticky existuju lepsie jazyky ako Java ale zrovna C++ k nim nepatri. Jazyk by mal mat aj nejaku vnutornu konzistenciu a C++ je mix vsetkeho co by sa asi tak hodilo. Ale toto je pre zmenu zase moj osobny pocit a to v C++ programujem dost a nemam ziadny "odpor" voci nemu.

Je jasný, že Java má horší šanci se prosadit, když MS všude a za každou cenu tlačí svoje. Ostatně to platí pro i ostatní jazyky.

PHP je oblíbené proto, že je jednoduché s ním začít, dokonce i ten co o PC a programovaní neví vůbec nic. C, C++ je o výkonu. Ale pořád du jsou další a i nové starší jazyky, které mají také co nabídnout a používají jen v menšině.

Jinak zásadní výhody Javy vidím v multiplatformnosti právě na desktopu!

A jaky jazyk byste doporucil na rychle a prijemne vyvijeni na desktop pro Linux.

@1 COBOL a CICS? :-)

Jinak ja rad s autorem nesouhlasim. Je hlavne otazka, proc to resit, kdo ma zenit a kdy. Programovaci jazyky jsou podobne jinym lidskym kulturam. Imperia rostou a zanikaji.. a malokdy z objektivnich pricin.

Java je stale #1, a neni nic, co by ji mohlo v blizke dobe nahradit. Pokud je za zenitem, pak C++ (ktere ma autor zjevne tak rad, ze napsal tento zapisek) uz rozhodne take. Ze se stane COBOLem se vedelo uz v dobe jejiho vzniku - co bylo na Jave predevsim nove byla siroka standardni knihovna, jinak vsechno ostatni uz mel v te dobe treba Common Lisp. A samozrejme nalakali programatory na (zdanlivou) kompatibilitu s C/C++...

Ze se v C++ programuje lepe moc neverim - trvalo desetileti, nez se kompilatory C++ stabilizovaly (a dosahly urovne kompilatoru C), a u noveho standardu to bude take chvili trvat. Nastroje, ktere ma Java, treba v IDE, nelze dohnat pres noc. Nepopiram, ze C++ ma svoje nezastupitelne misto (desktop aplikace, hry, vypocty). Ale je stale mensi, zda se mi, ze vsech stran se tam tlaci neco jineho.

C# je pokrocilejsi nez Java, co do vlastnosti jazyka, ale je vazane na MS platformu. Myslim, ze ani vlastne neni tak rychle - akorat se vyuziva nativnich knihoven pro GUI, a tim je to na desktopu prijatelne.

Objective C - prijde mi, ze podobne kvalitnich jazyku existuje velka spousta.

Do spicky se taky dost tlaci Python. Kdybych dnes delal jakekoli vypocty nebo vyzkum, pouziju Python. A bude to rychle - tech par high-level operaci bude volat rychle (a male) jadro napsane v C/C++.

1) Spousta lidi, co delaji data-mining, implementuje algoritmy v Pythonu, R, Jave, apod. C pouzivaji opravdu jen opravdu ti, co potrebuji vyzdimat kazdou sekundu procesoroveho casu. Z vlastni zkusenosti muzu rict, ze rychlost vypoctu spis ovlivnuje volba vhodne datove struktury nez jazyk jako takovy.

2) Presun k mobilnim zarizenim prave preje Jave, protoze opet dochazi k roztristeni HW platforem. Nativni preklad muze fungovat tak u applu, kde vyrobce nabizi tri zarizeni.

3) Existuji nejaka relevantni cisla k tomu .NETu na serveru? Ve svem okoli vidim spis opak, ...

Burzovní systémy a banky jiz davno bezi prakticky jenom v Jave :) .. mozna je blog napsany mimozemstanem , ktery se posunul v case o 50let zpatky a pise o (z naseho pohledu) budoucnosti.

2) tak , tak .. dnes svetem vladne Pyton a Java. C++ je priserne, kdyz tak pure C. .NET je loknute ve svete Microsoftu

to, ze java je za zenitom ("is dead") pocut uz asi 10 rokov; ono mimo zenitu su skor tvrdenia z clanku :-) to je pravda, ze java je cobolom, ale to tak vsetci tusia uz dlhsie.

ok, php je skvela vec na male weby, to je uplne prirodzene, ale na com asi bezia tie nemale? mnoho z nich je na jave a dalsie pribudaju: slavny bol prechod twitteru z ruby on rails na jvm/scala, naposledy slovenska banka vub zmigrovala internetbanking na wicket

ok, java je mrtva na desktope, to je tiez uz dlhsie jasne, vynimkou su fakt len eclipse/netbe­ansy/idea. paradoxne, netbeansy rozhodne ficia, a to su dokonca pod oraclom.

ok, science vyuziva vsetko mozne, len nie javu, lebo predsa len tie ceremonie okolo syntaxe su nic moc (v porovnani s pythonom)

ok, sat je urcite pomalsi v jave nez v c(++) je tiez pravda, cele je to o tom, aky tool vezmem na aky problem: na performantne veci turbojazyky (aj ked aby sme neupadli do paradoxu z temy na fore, kde vysvitlo, ze nasobenie matic islo v jave pomaly, lebo ho autor prasacky naprogramoval)

to tvrdenie o kralovani .net na webe chce citation, imho je to haustvrdenie: ja vidim na okoli ovela viac startovanej javy nez .netov na serveroch. to, ze .net zmizol z dohladu je tiez zapalny argument: jvm je tu s nami do skonania sveta a existovalo mnoho ludi, co si radostne odmigrovali do scaly a tesia sa z featur

nazvat android "ostrovkom" je uz roflny argument, hlavne ked ten ostrovcek zerie odhadom polovicu mobilneho trhu

neistota rozvoja javy pod oraclom je detto mimo misu: o tom sa vyspevovalo v casoch kupy sunu, ale dnes sa oracle stara o javu viac nez dost: releasuje sa, vyvoj je otvoreny, a oracle uspesne releasol uz dve major verzie. zmienene netbeans navyse nabrali take tempo vyvoja, ake pod sunom ani nezazili.

zaverecny argument, ze "java 8 nic noveho neprinasa" je detto lol: po X rokoch snivania dohrmeli lambdy, co je najvacsia syntakticka zmena od javy 5 (2004), nehovoriac o paradigme

ak sledujete a programujete v jave, tak rozhodne kuzlo nestratila: pozrite sa, ako sa deje zjednodusovanie a streamlining vo vsekych oblastiach (porovnajte kody projektov v J2EE a posledne Java EE), pozrite sa co vsetko robi spring

a nehovoriac o tom, ze pozrite sa, co sa deje na poli alternativnych jazykov nad jvm

Je to lepší než android.

ale i kdyby java umirala tak pomohla na svet jazykum jako scala, groovy...

Chtel jsem se na tu javu autora zeptat, takze diky za prispevek. Par poznamek

ten prozatimni ostruvek android je dnes temer(?) nejrozsirenejsi platforma a velmi rychle roste

co se tyce oraclu, tak chapu, ze obava ze zariznuti vyvoje driv byla, ale dnes mi to prijde jen jako FUD, mozna me nekdo opravi...?\

argumentovat pomalym vyvojem javy na prikladu C++ je ponekud usmevne

http://en.wikipedia.org/wiki/Java_performance

[8] Pletete si frontend s backendem, kde vládne IMS/DB2/DATACOM + CICS. A ne, tyhle produkty v javě napsané opravdu nejsou.

Trošku mě uniká, co všichni mají s tím Oraclem a jeho zásahy do vývoje. Však nezávisle na Oracle je k dispozici více implementací JVM i knihoven, včetně OpenJDK (což sice z 99% je to stejné jako Oracle JVM, ale nesmí se to říkat moc nahlas :-). Navíc veškeré změny v Javě prochází veřejným schvalovacím procesem, takže to není tak, že se někdo z Oracle špatně vyspí a vyškrtne já třeba lambdy.

Jinak můj osobní názor - samotný jazyk Java má své mouchy, ale hlavně je tady JVM a jazyky postavené nad ním - prakticky nezávislé na samotné Javě. A to je už velmi dobrá platforma.

Autor je dobrej srandista. Nepochybne bude o hodne vecech dost vedet, ale totalni zaslepenost je holt totalni zaslepenost, ta se bohuzel nevyhyba ani inteligentnim lidem s urcitym rozhledem v oboru a ma bez problemu stejny efekt jako 50 IQ dolu. Pobavil me ten "ostruvek Android". (Je fakt, ze se zivim programovanim pro Android v Jave a C++ a v Jave se mi proste pise lepe, ale zadny fanatik rozhodne nejsem. Silny odpor mam jen k hardcore C++.)

Autor ma asi hodne predsudky a je vidno, ze pochadza z windows sveta... Skusil autor niekdedy nieco ako maven+java a porovnat si to s "jednoduchostou" vyvoja vo svete c++, ci .NET? To je podla mna neporovnatelne. Vo svete MS technologii si neviem predstavit, ako jeden projekt otvorim v roznych MS visual srackach bez spatnej kompatibility a nieto este skompilovat ten isty projekt z konzoly, alebo nejakeho third party continuous integration serveru. Robil som davnejsie presne rok vyhradne v .NET a ked vysla v priebehu toho roku tretia cverzia .NET v platnost vo firme, tak som datl vypoved a zalozil si vlastnu firmu postavenu vyhradne na open source. Kodim si spokojne pod *linux systemami, spokojne v eclipse, ci netbeans a ked je zle, tak z konzoly cez vim editor fixnem nejaky bug, spravim si komit a server jenkins to za mna odtestuje a ak som to spravil dobre, tak aj nasadi. Toto v MS svete si neviem predstavit (pripustam, ze uz nemam rozhlad, lebo 7 rokov som windows videl len u rodicov na notebooku). Aktualne sice javu zcasti opustam (mierim na erlang na jeden zo serverovych komponentov), ale pri GUI "utilitkach" si neviem predstavit vyvoj v nicom inom, ako v jave. Co do rychlosti vyvoju i vysledku. 99% napisaneho kodu nemusi bezat rychlo, ale funkcne. A na to 1%, ktore ma bezat rychlo si posvietim, ked zistim, ze bezi pomaly a uzivatel musi cakat. Tam zvacsa potom staci na to pozriet a pouzit "inu datovu strukturu" a ide to dostatocne rychlo.

@6: "Do spicky se taky dost tlaci Python. Kdybych dnes delal jakekoli vypocty nebo vyzkum, pouziju Python. A bude to rychle - tech par high-level operaci bude volat rychle (a male) jadro napsane v C/C++."

Takhle se kdysi programovalo na osmibitech, většina programu se napsala pohodlně v BASICu, a kritické kousky jako rutiny ve strojovém kódu, takže vlastně žádná změna :-D

@dewovfghw Mám-li pocházet z nějakého světa, je to "Cocoa svět". V Javě jsem dělal roky. Pletete si PŘEDSUDKY a DETAILNÍ ZNALOSTI. Ale jinak pěkný věcný komentář, hlavně to s tím 1% procentem kódu, co má být super rychlý. Přesně tak tomu totiž často v projektech je.

[19] Potom je otazka, ci popisujete skusenosti s javou, alebo skusenosti s hibernate, ejb, spring a inymi srackami (pardon za vyraz). Ja pouzivam javu a ako kniznice pouzivam len veci, ktorych kod som si aspon otvoril a preskroloval par zdrojakov. Hibernate a ine veci nemam rad. Prichadzam teda do styku primarne s javou a so "standardnou kniznicou", co java poskytuje. Tam nie je nic pomale, alebo rychle podla mna. Cokolvek, co clovek nakodi je len o tom, ako to nakodi. Ja beriem ako pouzitie javy vyhodu v tom, ze ked niekde pride k problemu napriklad s nenastavenou premennou, tak to nehodi segfault, alebo inu mne nic nehovoriacu vec, ale pekne vynimku so stacktracom. Pripustam, ze segfolt a stacktrace je ekvivalentny pri dostatocnych vedomostiach. Nesuhlasim vsak s nazorom, ze java v aktualnom stave sveta smeruje k vymretiu. Stale je to jeden z mala jazykov s "ludskym pristupom" na inych platformach ako MS. Beriem, ze squeak prostredie (smalltalk jazyk) je fajn, ale to je prostredie, o ktorom nema povedomie mozno ani polovica tuna diskutujucich. Myslim, ze vymretie javy nehrozi a urcite nehrozi na ukor nejakych proprietarnych (pardon, tvorcom nativne nepodporujucich) veci, ako je .NET.

@dewovfghw Však netvrdím, že Java vymře. Jen se prostě zakopala do svých pozic a těžko je nějak významně rozšíří. To není dobře nebo špatně, to je prosté konstatování. Ani nechci porovnávat Javu s .NET (ať už technicky nebo koncepčně). Osobně píšu často multiplatformně (OS X, iOS, Win...), takže je asi jasné, co volím. Jistě, když píšu pro server, často sáhnu po Javě (podle toho, co tam běží), ale pro end-user aplikaci fakt ne. Evidentně máte přehled, tak snad chápete, o co mi jde. (Zkušenosti popisuju s Javou jako takovou, různé knihovny je třeba hodnotit zvlášť.)

@zboj: ak ste robili v jave, bolo by namiesto generickych bulvarnych tvrdeni omnoho podnetnejsie na diskusiu keby ludia hovorili "robil som X rokov v Jave, vadi mi X, ale v jazyku Y sa to robi pomocou Z trikrat jednoduchsie / krajsie / rychlejsie"

napr:
ahojte, volam sa perceptron, v jave robim 10 rokov a srdia ma anonymne vnutorne triedy, lebo je syntakticka uchylacina, zle sa to vysvetluje, je to neprehladne, a navyse v groovy / pythone sa to riesi lambdami/closures.

@perceptron Zjistěte si, co to znamená "být za zenitem" ;) Pak doporučuji kvanta článků třeba na Infoworld, které tvrdí to samé. Podle této "logiky" je bulvární úplně vše.

A zrovna anonymní vnitřní třídy jsou velmi hezká věc. Ale asi to byl jen příklad.

> Jenže Java jen zaplnila mezeru na “trhu” jazyků.

Zvláštní, takový zaplácnutí mezery a jak se mu daří ;-)

> Současná situace Javě příliš nepřeje.

Zdroj?

> Posun vývoje k mobilním a embedded aplikacím přeje spíše nativnímu kódu.

Nativní kód je vhodné používat až teprve v momentě, kdy managed kód nestíhá nebo je nutné mít vše _opravdu_ pod kontrolou (např. uvolňování a alokace paměti). Nevidim důvod psát mobilní aplikaci, která komunikuje s nějakou business aplikací (ERP, CRM...) v C++, když jí můžu napsat v klidu v Javě (Android) nebo něčem .NETovém (C# pro WP/WinRT). Aplikace bude chodit jak po másle a bude hotová raz dva.

Co se C++ týče, na MSDN je video z nějaké loňské nebo předloňské akce, kde přednášející rozebíral vhodnost použití native kódu (tj. používání C++) a managed kódu. Link jsem bohužel někde zašantročil, zájemce nechť hledá na Channel9.

> Na serverech čím dál více kraluje .NET, kdysi chudší kopie Javy (nejen C#, ale celá koncepce), jež však rychle svůj vzor dohnala, předehnala a zmizela mu z dohledu.

Tohle bych rád viděl rozepsané více do detailu - jaké servery, v jaké kategorii firem, atp. Stejně tak můžu tvrdit, že na serverech se jede tvrdě na Linuxu/Unixu. Bez toho, abych uvedl detaily je mé tvrzení jen tvrzení.

~~~~~~~~~~~~~­~~~~~~~~~~~~~~~~~~~~~~~~­~~~

Kouknou, autorskej, voni jsou chytrej člověk, študovanej... ale co takhle, kdyby šli někam mezi lidi a vokoukli, jak to chodí ve velkým světe, kde se točej velký prašule? ;-)

ok, sice s autorom nesuhlasim skoro v nicom, ale dajme tomu, ze plati :

"Java pomaly umiera"

ja vravim, fajn, este ze to bude tak pomaly , ze vydrzi do mojeho dochodku :)

@Psíkus Co to je "velký svět"? Mám zkušenosti jen z Německa a USA (v komerční sféře). Lepší už to nebude...

@zboj Myslim ze tim velkym svetem bude spis myslena velikost/dulezitost projektu, nez kde sedi koder.

Tak pro zajimavost - onehda jsem napsal jednoduchy programek, ktery vytvori konvexni trojuhelnikovou obalku mnozine bodu. V jave mi to zpracuje 65k bodu lehce pod sekundu, obalka ma zhruba 200 plosek.

Tak jsem to zkusil cvicne prepsat do c++. Stahnul jsem VS expres 2013, ma to jen 9x vic nez netbeans, na disku to sezralo sileny giga. Algoritmus je efektivni, datove struktury pouzivam ze std. Samozrejme jsem musel vyresit spoustu dalsich veci jako pointery a reference, pak to odladit, zkratka o neco vic prace. A vysledek - 2x delsi vypocet. Jasne, mohl bych to silene profilovat, resit nejaky cachovani existujicich objektu, ja nevim co vsechno a mozna bych se dostal pod tu javu, ale me staci ze vim, ze to budu mit napsany rychle bez zdlouhaveho ladeni a reseni problemu minuleho stoleti a vykon bude dost dobry.

"Velké informační systémy a kritické aplikace (burzovní systémy, banky, řízení letového provozu, vesmírné projekty) využívají efektivní jazyky a platformy. Java tak zbyla pro středně velké projekty, kterých je ale najvíce a u kterých je velký tlak na čas a na nízké náklady."

Musím se smát. Sám sice programuju v C++, ale vidím proč je java jasně lepší právě na obří komplexní systémy, které ve skutečnosti jsou doménou javy (neznám žádný reálný enteprise systém na serveru v C++ nebo ve funkcionálním jazyku, zato nespočetně jich je v javě). Můžeš nějak rozvést co tě vedlo k tomu napsat tohle? Třeba banky nebo řízení letového provozu na javě nejčastěji běží.

P.S. Implementace solverů nebo další ultraspeciálních programů nepočítám mezi obří systémy.

@zboj,
zacnem najblizsie k ruke: co presne znamena "byt za zenitom"? Je to nieco, co konstatujete v "ztratila sve kouzlo"?

ak je to v argumentoch clanku, tak tie su, ako poznamenalo viacero ludi, vysoko diskutabilne (odtial tiez ta moja poznamka k bulvarnosti, plus ten zapalny clanok). mozete dat odkaz na nejake clanky z infoworldu, ktore mate na mysli?

este som inak uvazoval: ak je to o zakopanych poziciach, konkretne o tych gui aplikaciach, tak je to presne tak, ako ked v c/c++ skoro nikto neuvazuje o pisani webovej aplikacie. neda sa cakat nejaky dramaticky posun, ale to neznamena, ze su tie jazyky za zenitom.

a podobne: o objective by pred par rokmi nik nepovedal, ze sa z neho stane shooting star, a pozrite co s tym spravil iOS. spekulacie su teda na vode, a mozno sa stane, ze o 5 rokov ked android pobezi na desktope, budeme z javy top3 platforma pre okienkove aplikacie

vyjasnenie: posledna veta mala byt v tagu [drogy]...[/drogy]

A ostatní jmenované jazyky (C#, C++, Objective-C) nejsou za zenitem? Jakou mají například podporu pro bezpečné paralelní programování? Nebo pro resource-safe programování? Jak jsou složité?

> Například řešení SAT je v Javě zhruba třikrát pomalejší než v C(++).

I když se použije ruční správa paměti?

Tiez suhlasim s tym, ze mi to pride vzhladom k temam co autor obvykle rozobera a povysenostou s akou sa diva okolo seba az s podivom, ze napisal nieco taketo. Ziadny zdroj, pri takto postavenych tvrdeniach by som cakal viac.

PS : Teraz ma napadlo, ze existovalo cosi ako Mars Rover

@Míček To je dobrá otázka. .NET obecně se také dostal do fáze řekněme "zralosti", v článcích na zahraničních stránkách věnovaných IT (např. I-programmer) se často píše o odklonu Microsoftu od .NET. C# tedy možná za zenitem je také. C++ je evergreen a vzhledem k dynamice jeho rozvoje v poslední době za zenitem rozhodně není. ObjC dtto, i když jen na platformách Applu. Paralelní programování je hlavně o knihovnách. U C++ zmíním aspoň paralelní knihovnu Microsoftu. ObjC má Grand Central Dispatch a vysokoúrovňové třídy kolem něj. Hezké přednášky o GDC byly na WWDC už před pár lety.

Trochu stupidní dotaz - co je SAT?

Ta dynamika C++. Ja kdyz to vidim, tak mam pocit ze to tezko nekdo zachrani, rozvoj prisel pozde imho. Ja treba napisu set a vse ok, pak zavolam insert a dostanu kryptickou hlasku s dvaceti zanorenyma sablonama kdesi v nejakym obskurnim headeru a jelikoz jsem zkusenej, tak v tech zavorkach rozpoznam operator < . Jako kdo do toho dneska pujde kdyz nemusi? Kolik let trva, nez v tom clovek dosahne aspon nejake produktivity? Vzdyt to je past vedle pasti.

@zboj [26] přesně jak píše jehovista, "velkej svět" je míněn ve smyslu projektů, ne lokality. Nemam pocit, že by v tomhle segmentu Java umírala, byla za zenitem nebo něco podobnýho.

[33] .NET dozrál a MS se od něj zjevně odklání, alespoň tak soudím dle prezentací na MS akcích (záznamy na Channel9). Snad někdo místní ví víc, MS technologie nejsou zrovna můj obor.

@zboj
opat budem neodbytny: tvrdite, ze c++ je evergreen a vdaka dynamike vyvoja nie je za zenitom, ale ked to porovnam s javou, tak ta splna obe kriteria: je evergreen a dynamika vyvoja existuje (ak si pozriete changelogy od jdk5). alebo mate nejake exaktne priklady, kde vidite, ze c++ rastie viac (napr. z hladiska syntaxe mam pocit, ze C# je na tom oproti jave este lepsie|

[33] Neda mi nereagovat na jednu vetu, kusok vytrhnutu z kontextu:

> Paralelní programování je hlavně o knihovnách.

Dovolim si tvrdit, ze nie. Paralelne programovanie je mozne dosiahnut vdaka knizniciam a vhodne napisanemu kodu, ale ak chce clovek EFEKTIVNE paralelne programovat, tak nesmie pouzit asembler, vo vacsine pripadov nesmie pouzit c/c++ v polovici pripadov nesmie pouzit C# a ani Javu, ale potrebuje pouzit vhodnejsi jazyk (zalezi od typu ulohy). Osobne mam skusenost s prologom, lisp-om a aktuálne robím v erlangu (snažím sa). Jazyk dokaze poskytnut az neuveritelne veci ohladne paralelnosti.

Pre priklad uvediem sprosty priklad:

Potrebujem na kazdy prvok pola (mnoziny, listu, mapy, cohokolvek) aplikovat nejaku funkciu. Proste mam pole cisel a potrebujem kazde cislo odmocnit... Skuste tuto ulohu spravit "paralelne" pomocou vhodnej kniznice a potom sa pozriete na R-project, lisp, alebo ine jazyky a ako narocne je to zapisat tam.

Ale ako som pisal hore, kus som vytrhol vasu vetu z kontextu a tak moj prispevok prosim berte len ako naznacenie, ze kniznica malokedy nieco vyriesi, ked zakladne veci sa robia v jazyku velmi zle, ak ich chcem robit "paralelne". Proste musim vela pisat pre malo muziky...

Javu bych přirovnal k VHS nebo MS-DOSu - zastaralá už v době vzniku, ale se silnou komerční podporou. Ovšem mluvit o nějakém zenitu je vždycky zrádné. Je tu dost velká, navíc platformě nezávislá podpora a velké množství vývojářů, kteří Javu a její knihovny umějí. Nadto jejich počet stále stoupá. Což je velmi nezanedbatelná deviza. Mobily a rostoucí výkon embedded zařízení spíše dává prostor pro další růst Javy.
Pokud jde o ty vědecko-technické, výpočetně náročné projekty, tak zde velmi významnou roli hrál, hraje a jak se zdá tak bude hrát i nadále Fortran. C(++) v této oblasti vnímám spíše jako krok zpátky - z principu není možné pro něj vyvinout tak dobré překladače jako pro Fortran, který v rychlosti generovaného kódu kraluje už neuvěřitelných 60 let. Sám jsem byl nucen se jako student Fortran naučit a musím seznat, že to, k čemu byl vyvinut, tedy vědecko-technické výpočty, se v něm skutečně dělá příjemněji než v jiných jazycích - oproti C výrazně příjemněji. Samozřejmě se bavíme o Fortranu 90/95 a výš.

netreba si mylit java jazyk a java svet.
Java jazyk je kus stary, niektore veci mi chybaju a som lenivy. Preco mam napisat 5 riadkov kodu, ked to iste viem napisat v C# na jeden (cez linq). Verim ze podpora lambda vyrazov (+ kniznice, ktore ich vyuziju) posunie opat javu dopredu. Je to len syntakticky cukor, ale zvysi rychlost pisania kodu/skratenia kodu/zvysenie citatelnosti. Preto si nemyslim, ze jazyk java je za zenitom.

Java platforma je naozaj vyborna, vznikaju nove a nove pristupy, kniznice, riesenia. Je otvorena a ziva. Je najvhodnejsia pre busniness aplikacie a vacsie stranky. Nepoznam nic lepsie (.NET svet ma len jedneho prispievatela a nuti vas ist jeho cestou)

Sa tu hadate o jazykoch(skor cela platforma), ktory je lepsi. Ked chcete lowlevel, zoberte asm alebo c. Chcete rychlu nativnu apku, mate c++. Chcete matiku mate python. Chcete vysoky paralerny vykon? erlang. atd

Dobry programator sa pozna tym, ze si vie vybrat spravny nastroj na ulohu, ktoru dostal. Tiez nejdete mobil rozoberat sekerou (aj ked vyborna na sekanie dreva). Zacnite si to miesat a budete sa zbytocne hadat o zbytocnostiach.

[33] Paralelní programování je také (především) o jazyku, což je ovšem problém jak na straně C/C++, tak i Javy, která kromě trošku obskurních zámků tvorbu paralelních algoritmů nepodporovala. Teď se to trošku zlepšilo v JDK8 (lambdy), ale tyto jazyky prostě na tvorbu skutečně paralelních algoritmů připraveny nebyly :-(

[36]

"Potrebujem na kazdy prvok pola (mnoziny, listu, mapy, cohokolvek) aplikovat nejaku funkciu. Proste mam pole cisel a potrebujem kazde cislo odmocnit... Skuste tuto ulohu spravit "paralelne" pomocou vhodnej kniznice a potom sa pozriete na R-project, lisp, alebo ine jazyky a ako narocne je to zapisat tam."

Objective-C: instanci NSArray nebo NSSet můžete poslat zprávu

- (void)enumera­teObjectsWithOp­tions:(NSEnume­rationOptions)op­ts usingBlock:(void (^)(id obj, NSUInteger idx, BOOL *stop))block

kde options jsou: NSEnumeration­Concurrent and/or NSEnumeration­Reverse

Víc systémově to asi podporované být ani nemůže.

Statistiky zalozene na Alexa datach su dlhodobo zname svojou nepresnostou.
Vsetky dolezitejsie stranky a projekty su za takou maskaradou roznych cache-i, proxy, clusterov a pod., ze sa z response neda zistit, akou technologiou je vlastne samotny content generovany. Napriklad vsetci vedia ze je facebook na php, ale z response sa to zistit neda..
A presne na tomto su Alexa data zalozene.
Dalo by sa povedat, ze su to statistiky beznych mensich stranok, ktore maju vystaveny verejne priamo web server.
Preto aj PHP tvori takmer 80% a to, ze ma .NET take vysoke cislo je pre mna usmevne, znamena to totiz, ze to pouzivaju amateri co si nezabezpecuju poriadne servre..
Dalsia vec je, ze si treba ujasnit pojem "bezi na". Napriklad banky. Ano, banky bezia na jave a ano, banky bezia na inych systemoch. Java je totiz najpouzivanejsi integracny middleware. Vsetky tie ESB integracne platformy su taktiez postavene na jave. Java bola aj dlhodobo najpouzivanejsi frontend nastroj, ale to sa trocha meni s prichodom "MVVM" a angular-style frameworkov, java sa tak presuva na rest-servisnu vrstvu a stava sa tak front-middleware.
Za zenitom ale rozhodne nieje.
A v clanku uplne chyba spomenute aj raketovo rastuce pouzivanie server side javascriptu.

Tento komentar pisem ako dlhorocny front a middleware vyvojar v jave, ktory pracoval na projektoch mobilnych operatorov, bank a statnej spravy. A vsade je tam java. A vsade su tam aj ine systemy a ine jazyky. A vsetky navzajom spolupracuju.

[41] Dělat matematiku v Pythonu je naprostá hovadina.

Co pozoruji ve světě korporací já, tak Java se už tak 5 let pohybuje na stejné úrovni, podobně jako C. C++ šlo výrazně dolů, naopak nahoru se dere Javascript. Objective-C potkávám převážně jen pro iOS. Zajímavé jsou alternativní jazyky na JVM a Ruby, právě ty si prošly velkým vzestupem a nyní se mnoho známých a publikujících vývojářů vrací k Javě. Osobně mezi imperativními jazyky neočekávám nějaké dramatické změny, ty přijdou až s nějakou skutečně jinou architekturou počítačů umožňující skutečné logické programování. Prolog je už hodně stará záležitost, pak tu jsou ještě rule enginy, ale nového už dlouho nic a je to vina hlavně chybějícího efektivního hw s jinou architekturou než jsme zvyklí.

[buffer] Posuzovat pouzivanost jazyka v ruznych prostredich z pohledu vyvojare je dost zavadejici. Samozrejme taky muzu na zaklade pracovnich zkusenosti, inzeratu a pohovoru rict, ze vsechno bezi na Jave. Jenze to same muze rict i C# vyvojar. C# vyvojar si hleda C# projekty a jine ho proste nezajimaji. A kdyz vidi kde se to vsude pouziva, tak muze pronest uplne stejny vyrok.

@45 Neni:
http://www.sagemath.org/
http://pandas.pydata.org/
http://statsmodels.sourceforge.net/
http://scikit-learn.org/stable/

Pro vedce, ktere nezajima programovani, zastane Python pomerne pohodlne roli univerzalniho jazyka.

@Karell Nevím, jestli je kovexní obálka ideální příklad pro testy rychlosti. Nicméně ze zvědavosti jsem to zkusil na 100,000 bodech. Nejrychlejší je podle očekávání clang (s naprosto přímočarým algoritmem). VS nativně v těsném závěsu. .NET s řízeným kódem a nativními daty zhruba dvakrát pomalejší. Dtto s řízenými daty 5-6 pomalejší. A Java (8) dvacetkrát. Přitom jsem v .NET schválně nepoužil hodnotové typy. Možná jste to v tom VS jel před Debug místo Release, to způsobuje řádové rozdíly. (Pointry jsem neřešil, nenapadá mě, kde by se tu měly použít.)

[48] Nedovedu si představit, jak bych něco, čehož výpočet napsaný ve Fortranu a spuštěný na 256procesorovém poči trvá týden, dělal v Pythonu.

[50, Viky]

A) I věc, která není napsána ve fortranu a nespouští se týden na nějakém xsetprocesorovém počítači celý týden, tak to pořád může být matematika.

B) Dělat matematiku je:

1)Formuluje se matematický problém - v něčí hlavě, nebo na papíře.
2)Problém vyřeší za pomoci nějakého čistě matematického balíku (Mathcad, Mathematica, Maple). Jednotlivé kroky, nebo celé řešení se vizualizuje.
3) Začne přemýšlet nad technickou realizací a problém se řeší v něčem jako je Matlab + specializované toolboxy. I tady se jednotlivé kroky, nebo celé řešení vizualizuje.
4) Předchozí řešení odpoutá od matematických balíků a udělá se prototyp v nějakém jazyce s rychlým vývojem.
5) Nakóduje se řešení nějakém jazyce s rychlým během (dnes typicky C, historicky a dnes už spíše málokdy Fortran)

To jsou kroky při práci s matematikou. Nemusí se vždy udělat všechny (to by bylo spíše netypické, spíše se mezi těmi kroky přeskakuje, nebo se ty za sebou jdoucí slučují do jednoho kroku.
A právě v krocích 3 a 4 je python silný. V kroku 4 je úžasný a pro méně náročné inženýry dokáže v kroku 3 nahradit i ten Matlab.
A na krok 5 vůbec dojít nemusí. Pokud aplikace běží na dedikovaném PC a stíhá, tak kdo by platil krok 5?

To, že se fortran hodí na krok 5, neznamená, že se hodí na kroky 1-4. Mám tady položit nějakou hloupou otázku typu - jak dlouho by mi trvalo udělat vizualizace ve fortranu - a na základě toho usuzovat, že se fortran pro "dělání matiky" nehodí?

@Mirek SAT je testování splnitelnosti výrokových formulí. Používá se například v umělé inteligenci, návrhu integrovaných obvodů nebo testování korektnosti softwaru. Jde o NP-úplný problém, pro nějž ale existují superrychlé algoritmy. Typicky se nějaký komplexní problém převede na SAT, vyřeší a pak se z valuace dekóduje řešení. Hezký příklad praktického využití je třeba SATPLAN (viz wiki, google).

@Karell Kvůli těm hláškám teď kdekdo přechází na clang. Kdo do toho půjde? Kdokoliv, kdo nemůže použít třeba právě Javu. Například při vývoji pro iOS nebo WinRT.

[49] @zboj
V tom pripade me zajimaji konkretni casy. Nevim jestli jsem rekl jasne, ze je to ve 3D. Napsal jsem to docela primitivne, takze alokuju linie a trojuhelniky, ktery ty linie sdili. Z toho pak stavim obalku rozsirovanim o jednotlive body. V jave si to muzu dovolit, takze nad tim nejak zvlast nepremyslim (to je ostatne cely vtip psani ve vyssim jazyce).

Jak jsem psal, 65k bodu, java8 - 400ms (-server), VS2013 C++ x64 release kolem 1600ms. Zkousel jsem hrat si s jednotlivyma optimalizacema, ale efekt byl nemeritelny.

Me nejde ani tak o to, jestli to je vhodny priklad pro mereni rychlosti, ale o pouziti takove platformy pro moje ulohy, na ktere pobezi ten program dostatecne rychle aniz bych se musel matlat s detaily. K cemu je mi nejaky mikrobenchmark, kdyz to v realu vyhori na necem uplne jinym?

Takze tesim se na vase cisla.

@zboj: nalinkujte mi prosim, tie clanky z infoworldu o tom "po zenite", co ste spominali vyssie, a zapadli v diskusii, vdaka.

@karel @zboj: nedate sem zdrojaky? v predoslych diskusiach sa ukazalo, ze v porovnavani vykonnosti nie je zdrojak ako zdrojak :-)

Perl, jedině Perl !!!

[51] Ono se to taky dá pěkně doplnit, na frontendu používat Python (popř. Python notebook pro práci podobnou Maplu) a vlastní výpočetní jádro udělat ve Fortranu. Fortran je na úlohy typu "přečti soubor s několika obrovskými maticemi a na základě toho vyjeď další soubor s výsledky" používán pořád, dokonce se několik pracovišť drží stále Fortranu 77 (podle mě kvůli poněkud starší vývojářské základně a snaze o využití existujících modulů asi jim na drcení čísel F77 stačí).

@28 - Samozřejmě když něco napíšte v programovacím jazyku, který znáte a používáte, a pak se rozhodnete to přepsat do jazyka u kterýho si nejste tak jisti, že v něm to napíšte mnohem hůř. Nejdříve se v tom dobře naučte a pak v tom zkoušejte takovéto pokusy. A nedomnívám se, že byste musel použít nějaké zvláštní speciality. Dále by stálo proletět konfiguraci kompilátoru VS jestli tam není něco navíc a popřípadě vyzkoušet starší verzi kompilátoru nebo úplně jinej kompilátor např. mingw.

"Java se pomalu stává Cobolem dnešní doby."

http://www.itworld.com/career/341879/cobol-will-outlive-us-all

@58 - ze jsem tak smely, muzu se zeptat z ceho usuzujete, ze v c++ si nejsem jisty? Jak dlouho bych se mel ucit, myslite ze 16 let je malo? V MS jsem proste prepnul na release, pak jsem zkousel ruzne volby rucne, ale nic z toho nemelo meritelny efekt.

Jinak pokud plati co rikate, tak to znamena, ze kdyz nekdo razi tezi "pis to v C++ protoze je rychlejsi", tak to ve skutecnosti znamena "pis to v C++, pak to cely prekopej a extremne zoptimalizuj, pak vyzkousej vsemozny kompilatory a jejich verze a jejich volby a pak to bude rychlejsi (mozna)". To si myslim, ze je treba si uvedomit a necham na kritickem posouzeni kazdeho, jak efektivni je to v porovnani s pristupem "napis to jednoduse v jave a JIT se postara a nejspis to dopadne docela dobre".

Asi to schytam, ale zde je kod a vzorovy vstup :-). Jsem se nejak spletl, tech bodu je necelych 43k.
http://pastebin.com/i0pYegQR
http://www.uschovna.cz/zasilka/QIE842PC3GKFAVJ9-4AN/

Prosim pokud bude nekdo navrhovat vykonnostni zlepseni, at si to nejdriv zkusi/zmeri...

Kdo si stěžuje na tristní stav vývoje softwaru v 90. letech by si měl sakra uvědomit, že na vině je hlavně zrůdnost jménem UNIX, která napřed zašlapala do země skutečně kvalitní výpočetní systémy a pak dokázala být z uživatelského hlediska tak odporná, že se pro lidi stal lepší alternativou GUI obal nad MS-DOSem.

Kdo žvaní o paralelním programování a přitom netuší o existenci čehokoli jiného než dementní vonneumannovské architektury a zuřivě obhajuje babylonské věže typu C++, Java, by se měl sakra zamyslet a přečíst si nějakou literaturu (Kogge, cokoli o dataflow, Symmetric Lisp, ...)
Protože paralelní programování není ani o jazyku, ani o knihovnách, ale o tom mít architekturu, ke které nebyly chabé snahy o paralelismum přivařeny narychlo, když nastala potřeba.

Peace.

V objective C som programoval asi 3 app pre iphone takze nie som expert, ale myslim ze sa mu da prist na chut a povedal by som ze ho mam radsej ako javu. Trosku problem je ze najnovsia implementacia objektive c bezi len na apple alebo apple virtuale, na ubuntu bol kompilator ale najnovsie prvky tam nesli. Na win som ani kompilator nenasiel. K jave si vzdy spomenem co povedal moj sef ked sme prerabali kod z c++ do javy "5 krat pomalsie a 5 krat narocnejsie na hw"

@Karell Stačí přepnout na Release a pustit "without debugging", protože i to má vliv na rychlost.

[64] proboha uz me prestante ucit jak mam prekladat, ja to fakt nemam pusteny poprve

@63 skoda, ze ten tvoj sef nepovedal, ze ten kod bol zly aj v povodnej forme v C++. Ten argument je ako moja noha....

Zaroven dodavam, ze Java je Cobolom uz teraz. Skusal niekto z vas vytvorit a nasadit aplikaciu na mainframe ako je System z alebo midrange AS/400? (Tip: pri vyvoji si mozete vybrat medzi niekolkymi assemblermi, Cobolom, C/C++ a Javou). Co myslite, co sa da najjednoduchsie debugovat aj na vasom lokalnom stroji, nepotrebuje to rekompilovat na architekturu, ktoru ste nazivo ani nevideli a staci to na "velke zelezo" nahrat cez FTP a zabudnut? Bingo, Java!

@63: preco ste potom prerabali kod do niecoho, co je 5x pomalsie a 5x narocnejsie na hardver? :-)

@67: +1 To by aj mna zaujimalo :)

Povodny kod bol v c/c++ a fortran tusim vyrabany od 1987. Neviem preco sa prechadzalo na javu mozno preto ze java bola multiplatformova a chceli prejst z win na linux, z oracle na nieco lacnejsie, urobit krajsie gui. Nemyslim ze bol kod zly, bezal roky bez chyb. Neskusal som nasadzovat kod na mainframe, najsilnejsi stroj bol proliant, bezal tam oracle tak som napisal kod v pl/sql.

@Karell Jsem si připadal jak když jsem opravovával kód po studentech na zkoušce :) Tady by student letěl v rámci preflightingu, protože to nešlo přeložit podle normy. Jinak jsem jen opravil pár zbytečných kopírování (hlavně u shared_ptr), čímž se to urychlilo o cca. 10%. Takže - ve VS nativně zhruba 2 sekundy, přeloženo do CLI 2,2 sekundy, a teď pointa - stejný kód na stejném stroji přeložený clangem: 300 ms. Nemám tu verzi v Javě, tak nemůžu porovnat, ale zkuste clang s libc++. MS to prostě kazí. Předpokládám, že různé jiné benchmarky Java vs. C++ také používají VS a pak to takto dopadá.

@zboj - to je ten rozdil kdyz nekdo pise aby prosel zkouskou a kdyz se tim zivi. Tam se plati za jiny veci nez zda je to dle normy :-). Nicmene, jsem to u sebe opravil.
Ten test kompileru je zajimavy, na clang se zkusim o vikendu mrknout. Javu dam asi nekam na git pac se mi to nechce davat do jednoho souboru.
Jeste jsem delal pro zajimavost delal test v C#, dava to kolem 600ms.

@Karell A kolik ms běží to C++? Ještě můžete zkusit překlad do CLI (pure), to by mělo být podobné jako C#.

C++ kolem 1600ms. Nevim co se presne deje kdyz se preklada do CLI, s /clr to dava kolem 2000ms, /clr:pure dava 2220ms, nevim co si o tom myslet.
Stejne si rikam, ze s tim c++ je neco divnyho, jestli tam nemam nejak blbe pouzity kontejnery nebo je neco divnyho v knihovnach nebo tak neco...

Pure dělá jen CLI, /clr míchá nativní kód s CLI. Problém bude asi v knihovně, VS má dobrý překladač, ale STL na ho... Při překladu s /clr(:pure) se používá jiná (horší) verze STL. Ten kód je asi v zásadě v pohodě, clang dělá víc optimalizací a má superrychlou STL.

@Karell: Hlavní problém toho C++ kódu je v tom, že často dereferencuje/ko­píruje shared_ptr. Protože je dereference/ko­pírovaní shared_ptr thread safe, je to atomická operace sychronizovaná mezi thready. I když to ten kód vůbec nepotřebuje, pořád se tam provádí atomický increment/decre­ment. Trochu jsem to upravil, tahle verze je u mě asi o 25% rychlejší:
http://pastebin.com/R0CkHvr4
Nicméně pokud bys to chtěl ještě výrazně zrychlit, musel by ses zbavit thread safe smart pointerů v Line. Takhle nějak to vypadá v profileru (je to se zakázaným inlinováním, aby byly vidět funkce, takže to není na 100% stejné, jako když se inlinuje):
http://www.pictureshack.us/images/28500_profiler.png

Nejni mi jasné, jestli autor myslí Javu jako platformu, nebo Javu jako jazyk (syntaxi). Pro JVM lze vyvíjet v různých jazycích.
Co se týče oné, řekněme, stagnace jazyka, tak autoři Javy jsou zřejmě názoru, že překotné zavádění novinek snižuje robustnost jazyka/platformy. A asi maji pravdu. Je lepší, když je jazyk na danou fičuru připraven od začátku, než když se to tam dodatečně naroubuje.
Vývoj asi není tak překotný jako u C#/NET, ale to může být bráno i jako plus. Připadá mi, že MS to dělá stylem "dáme tam to, co zrovna letí a je IN", aby to bylo přitažlivé.
No a taky kompatibilita napříč MS světem není bůhví jaká. Např. kompatibilita DX9 vs. 10. Visty měly v základu DX10, ale nebylo to zpětně kompatibilní s DX9. Muselo se zvlášť doinstalovat DX9.
Na MS mě štve, že něco zavede a pak to následně zruší a vývojáři trhněte si. Např. MDX (Managed DX), XNA, kompatibilita WP7 - WP8.
Nedivím se, že pak vznikaj projekty jako MonoGame umožňující multiplatformní vývoj. Čímž se obloukem dostávám z5 k tématu (omlouvám se za menší odbočku). Takže bych to s tim posunem k nativnímu kódu neviděl tak růžově.

@Karell: Tady máš verzi, která je o dalších asi 40% rychlejší:
http://pastebin.com/wrHt2nBD
Dalo by se to zoptimalizovat ještě mnohem líp, ale už me to nebaví :-)

Pracujem ako CTO v jednej nemenovanej spolocnosti.

Dost sa tu riesi ktory jazyk je rychlejsi. Z pohladu praxe to pre mna nie je primarny ani sekundarny ciel, aby skompilovany kod bezal co najrycchlejsie (pokial sa nerobi komplikovany vypocet na cas) Pre co su pre mna managovane jazyky zaujimave (u nas C# vsade - cloud, wp7,8, xamarin - Android, iOS) je podla priority:
1. Blbuvzdornost/bez­pecnost kodu - ziadne chyby pri neinicializovanych premennych ako v C++ (ked nieco ide v debugu ale nie release atd), tazko hladatelne memory leaky(aj ked aj u manageovanych jazykov musi clovek vediet pracovat s pamatou), array boundaries checks, a pod
2. Rychlost vyvoja - jednoduchsie debugovanie, mensie naroky na vzdelanie zamestnancov, sustredenie sa na jadro problemu, jednoduchsie paralelne programovanie ako v C++ a pod
3. Rychlost behu - aspon na mobile je ako tak dolezita, na cloude moc nie. Tam vacsinou su "brzdou" aj tak IO operacie, SQL, NoSQL...

Nechcel by som enterprise apps pisat v c++, myslim ze c#/java s nami bude este dlho.

@mixal11 To jsou většinou (proti)argumenty z minulého století. Zrovna rychlost jsem řešit nechtěl, ale ukazuje se, že když je něco v Javě třeba zhruba stejně rychlé jako v C++ ve VS a pak se ten samý kód přeloží clangem, tak je taky třeba třikrát rychlejší. Záleží hodně na implementaci STL apod. Jinak spíše než rychlost je u Javy problém paměť. Nejen větší nenažranost, ale principiální omezení dané generačním kolektorem (viz nedávný článek na java.cz). Právě pro mobilní aplikace to je hlavní kritérium.

Chápu velmi dobře argument "menší nároky na vzdělaní zaměstnanců", i když v případě C++ vs. Java to je spíše o tom, že javisti by se museli učit něco jiného. Někdo bez konkrétních znalostí se stejně rychle a dobře naučí Javu i C++ (nebo stejně špatně). Různé předsudky ne jedné straně a glorifikování Javy na straně druhé škodí. Nehledě na to, že "soustředění se na jádro problému" je zejména o knihovnách, ne konkrétním jazyce.

@gamer a ostatni. Tak ja se velmi omlouvam, zkoumal jsem, cim to gamer tak urychlil a naprosto zasadni zmena u VS kompileru je nahrazeni istream >> double obycejnym sscanf. Na tom to uplne vyhorelo, a jelikoz nemam profiler, tak jsem to nezmeril. Takze muzeme vzit zpatky vsechny uvahy o kvalite MS stl atd., mozna neni cely tak spatny, ale v parsovani doublu neco shnileho je. Rozdil v mem pripade dela ze 1600ms nejakych 470ms.

Jinak samozrejme, kdyz budu optimalizovat algoritmus, jinak resit zivotnost instanci apod., tak se dostanu na lepsi cisla, ale to uz jsme u toho, nakolik investovat do optimalizaci a nakolik zachovat jednoduchost kodu. Jakmile na tom zacne spolupracovat vic lidi ruznych kvalit/zkusenosti, tak se bude vyplacet drzet kod spis jednoduchy.

A mimochodem, v poslednich letech casto narazim na clanky, ze se programator nema snazit napovidat kompileru tim, ze parametry prijima pres const & (jde o tu referenci) a na tomto prikladu to skutecne nema vliv (spravne mam rict na VS2013 :-) ). I (ne)pouziti u shared_ptr nema meritelny vliv. Na netu toho najdete dost na to tema.

Takze diky za prinosnou debatu.

Ty streamy jsou součástí těch knihoven. Rozhodně by to chtělo znovu zkusit v clangu. Jinak řešit příliš optimalizaci je ztráta času. Většinou je důležitější čitelnost. Existuje pár základních pravidel, která je nutné v C++ dodržovat, aby kód nevypadal, že ho psal Tatar, ale jinak se klidně může nechat optimalizace na překladači. Dobrý překladač a novinky z C++11 dělají divy. Dokonce ve VS při překladu do CLI je výsledek někdy efektivnější než stejný kód v C#, protože frontend C++ dělá pár optimalizací navíc (i v clr:safe). Jen se to nesmí pokazit nějakou knihovnou, třeba STL/CLR, což je ještě o řád příšernější než STL pro clr:pure.

@zboj:
vy ste adresovali (opat) rychlost behu, ale radostne ste odignorovali prve dva, ktore su omnoho prioritnejsie: blbuvzdornost / bezpecnost kodu, a rychlost vyvoja, nehovoriac o domene problemu. Tu sa veselime s matematickym problemom konvexneho obalu, ale v praxi existuju aj ine, menej matematicky orientovane problemy, kde o performance az tak nejde. Mixal11 hovori o enterprise aplikaciach, ktore su tradicne mimo dosahu C++ (alias zlozitejsie portaly).

ono istym sposobom aj jazyk je kniznica, a tie enterprise aplikacie su prikladom. aby som ale nebol nekriticky voci syntaxi javy: ked si porovnate reaktivne programovanie v scale (akka) s javou, tak rovnako zistite, ze niekde vas syntax a limitacie jazyka otravuju viac a niekde menej.

a este: mobilne aplikacie a java tradicne nie su problem performancu vm, ako discipliny vyvojarov.

To s tym, ze "tabula rasa sa nauci dobre Javu aj C++" je opat, imho, argument typu wishful thinking bez argumentov a bez opory v praxi, co bolo vidied v debate pod inym blogpostom.

tolko k predsudkom :-)

@perceptron S rychlostí začal někdo jiný, o ni mi tu nešlo, i když nakonec jsem rád, že se ukázalo, jak velké rozdíly jsou v implementaci překladačů/knihoven pro C++. A to učení není wishful thinking, to jsou reálné zkušenosti z praxe s nováčky. Ono asi jde hlavně o způsob výuky nebo tréninku. Doména problému je jistě důležitá. Argument blbuvzdornosti moc neberu, blb by prostě programovat neměl. Bezpečnost kódu a rychlost vývoje - jistě, jen by tedy někdo musel dokázat, že je v tomto na tom Java lépe než jiné alternativní jazyky. Když si vezmu moderní knihovny a postupy, tak vývoj v Javě, C#, C++ i ObjC je stejně rychlý a bezpečný (opět ověřeno na projektech) a jediné relevantní kritérium je oblast nasazení. Multiplatformní mobilní aplikaci například nebudu psát v Javě, protože by to nejelo na iOS. U serverové aplikace mě bude zajímat předpokládaná zátěž. Pokud bude extrémní, zvolím C++ (jako Facebook), jinak to může být Java nebo PHP. Obecně kdo přejde u serverové aplikace z Javy na C++ ušetří zhruba polovinu serverů (tj. náklady na správu, elektřinu...). Cokoliv co jede na jednom serveru (nižší liga) a má být naimplementováno za pakatel pochopitelně využije něco jiného.

pre mna ten clang je tiez poucny :-)

mohli by ste realne skusenosti s novacikmi rozsirit? to ma zaujima (aj v kontexte debaty z predosleho postu), kedze tiez sa stretavam s vyucbou novacikov, ake konkretne techniky a materialy ste pouzili?

ad blbuvzdornost: to nie je binarny svet. ako bolo vidiet v tejto diskusii, existuje siroka zahrada, kde su ludia, ktori vedia programovat, a nie su blbci, ale zaroven nie su velmajstri 69. levelu. dokazom je tato diskusia, kde je vidiet vylepsenia robiace velky rozdiel v aspektoch vyvoja (detto java na forach roota)

blbuvzdornost zalezi aj na tom, kolko programatorov akej kvality za aku cenu viete zohnat. prechod z javy na c++ na serverovej aplikacii je samozrejme mozny, ale prax (= pocet viditelnych nasadenych projektov na webe) ukazuje, ze to robi len malokto: usetrite mozno na elektrine, ale zaplatite viac na tych supermanov v c++, ktori to budu programovat a z hladiska kodu to udrziavat. (vid facebook, co ma domenu a peniaze na to, aby vyvinul in house PHP->CPP prekladac a uspesne ho nasadil.)

@perceptron No, clang je prostě extrémně kvalitní (nejen překladač, i libc++). Na ARM je ten výsledný kód ještě mnohem efektivnější než z VS (testováno na VS2012 cca. před rokem, ale tehdy byl i clang nedotažený).

K nákladům - ano, jistě, vše je o vyvážení. O dobré vývojáře je nouze obecně. A kolik se čím ušetří je v každém projektu jiné.

Výuka - materiály na začátku žádné. Důraz byl na formulování problému, základní algoritmizaci, velice jednoduchou syntax. Už tady se ukáže, kdo na to má. V další fázi příklady v pseudokódu (např. z knížky Norviga o AI, ale jen to nejjednodušší), kde se ukáže, co jak konkrétně napsat (důraz na zákeřné aspekty psaní kódu). Potom už následuje seznámení s knihovnou a nakonec syntax jazyka obecně. Zde je třeba přiznat, že až s verzí C++11 dohnalo C++ Javu v přehlednosti a čitelnosti kódu. Pozdější materiály zahrnují knihy Scotta Meyerse (teď vyjde aktualizovaná veze, která bude vhodnější). Vše cílí na kód vyšší úrovně (maximální jednoduchost, v podstatě jen volání knihoven, žádné explicitní optimalizace, žádné šablony atd.). Sám píšu ve dvou "módech": vysokoúrovňový kód (jednoduchost nade vše) a knihovny (kompaktní kód se šablonami, maximální optimalizací, sem tam i holý ukazatel), které pak ten kód vysoké úrovně využívá. Tolik ve zkratce. Celé se to osvědčilo při vývoji komponent pro větší podnikový IS. Stejně se postupuje v případě C# a ObjC.

no ano, len vy ste povedali velmi tazky argument, ze "obecne ak prejdete na serveri z c++ na javu, usetrite na hardveri a elektrine", comu ja jednoducho neverim bez rovnako tazkych argumentov

lebo ja mozem zakontrovat, ze sice mam 2x viac serverov a platim viac elektriny, ale nemusim platit 3000 euroveho C++kara, ked mam rovnako sikovneho 1200 euroveho Javaka

s tym suvisi aj to, ze ked vidim, ze pocet C++ webov v porovnani s Java/.NET webmi je neviditelny, tak asi to ma sakramentsky dovod.

a tym padom taketo extremne argumenty su .. extremne.

---

k tym vyucbam, to ma este zaujima: ake znalosti ma clovek na vstupe vasej vyucby charakterizovany "nekdo bez konkretnich znalosti" a ako dlho trva u vas jeho vyucba?

Zboj: Váš přístup se mi líbí. Pořádáte nějaké kurzy kromě výuky na VŠ, případně bylo by možné vás vidět "v akci" na nějaké přednášce?

Kedysi som uvazoval pouzit toto: http://gwan.ch/ - tu ide o vyuzitie prostriedkov na maximum.

Pekna vec ale v zasade ma neboli 500 Eur za servery namiesto 100 mesacne. Skor by ma bolelo to, ze na to zase nezozenem ludi a na webe nie je dost examples.

ale nemam s tym skusenosti. Na jeden specializovany projekt mam svoj server nad socketmi napisany, ked bude cas asi ho nahradim IIS/WebSocketmi z dovodov uvedenych vyssie.

"ObjC - že prý zrůdnost. Jistě, někteří tak tvrdí, většinou ti, co nenávidí Apple (což je ale záležitost pro psychiatra). ObjC nemůže za to, že bylo Applem koupeno. Z technického pohledu se jedná o geniální jazyk právě syntaxí (vysokou čitelností)."

...co to? ...vysoká čitelnost ObjC? To prostě není pravda. Jak vás to proboha napadlo? Znám X programátoru, DOBRYCH PROGRAMATORU co odmítli v ObjC programovat kvůli jeho nečitelnosti? Jak může někdo říct že je to čitelný jazyk????
B.

@bullhead Je čitelnější než ty s céčkovou syntaxí. Jde o způsob zápisu selektorů, ve spojení s rozumnou konvencí pojmenovávání metod se píše něco jako:

stringByFetchin­gURL: ... timeout: ...

Tím hned vidím typ návratové hodnoty i parametrů. Analogicky bych mohl mít metodu pro binární data:

dataByFetchingURL: ... timeout: ...

V C/Javě bych měl fetch(..., ...) a věděl bych (bez dokumentace) prd. C# aspoň umožňuje pojmenování parametrů.

Problém je evidentně v definici "dobrého programátora" :-)

Ako .NET programator som si vyskusal Android studio. Velmi pekne IDE, super veci. Ale ta pomalost. Ta pamatova narocnost (cca 3-4x ako moje VS2013 s kopcom pluginov). ... kde je ta efektivnost Javy ? Mam pocit ze na desktope su C# aplikacie rychlejsie a menej nenazrane.

@zboj
mozete plz odpovedat mne a Edovi Bedovi k tomu vzdelavaniu?

@perceptron Doménové znalosti. Většinou jde o matematiky nebo logiky (to se odvíjí od projektu). Během tří měsíců jsou schopni naučit se syntax a pracovat s knihovnami. Kdo po třech měsících nedosáhl uspokojivé úrovně, letí. 90% projde.

@Eda Beda Na VŠ už nejsem, přešel jsem do komerční sféry. Jezdím na semináře/konfe­rence/worksho­py, takže "v akci" budu například v srpnu na Dublin City University.

@bullhead Na Objective C som si musel zvyknut. Precital som si 2 knihy a nechal ho na rok tak lebo sa mi zdal desny. Nie je to ako nieco co poznam z C alebo z Javy. Na druhej strane som cital vela komentarov ze to je najlepsi programovaci jazyk sucasnosti tak som ho po roku znovu skusil a zistil som ze sa v nom daju napisat (ak viem ako) nadherne samopopisne funkcie. Mozno ma za to co teraz napisem ako kovany javaci komentarmi ukamenujete, ale myslim ze by sa v nom dal pisat kod podbny prirodzenej reci.

@strepty Přesně to je ta čitelnost, která Javě a C++ chybí. Jen to chce dodržovat určité konvence.

@strepty:
mate priklad?

@perceptron nieco taketo

matematickyModul = [[MatematickyModul alloc] init];
[matematickyModul spocitajCislo: 5 aCislo: 2];

cize v preklade
matematickyMo­dul.spocitajCis­la(5,2);

čitelnost objc - tohle je psáno z hlavy a princip to asi ukazuje - podle mne citelne bez extra znalosti syntaxe kdyz se clovek oprosti od toho "jak ma prece kod vypadat"

NSArray *myArray = [NSArray new];
// fill the array
// ...
// array filled

CLLocation *currentLocation = self.location­Manager.locati­on;
MyContext *localContext = [MyContext contextWithLa­titude:curren­tLocation.coor­dinate.latitu­de longitude:curren­tLocation.coor­dinate.longitu­de];

[myArray enumerateObjec­tsWithOptions:NSE­numerationCon­current usingBlock:^(My­ObjectType *obj, NSUInteger idx, BOOL *stop) {
[obj updateForIndex:idx inContext:local­Context];
}];

[99]: klidne vam poslouzim jako testovaci kralik, o ObjC jsem cetl pred asi 10 lety, cili rozhodne nemam extra znalost syntaxe :-). Pro predstavu - dokazal jsem si opravit neco v cizim kodu v javascriptu nebo PHP aniz bych o tech jazycich neco extra vedel. Dokazal jsem optimalizovat nejaky maticovy algoritmus ve fortranu aniz bych o tom jazyku neco vedel.

Ale tenhle priklad, to mi prijde jako soutez v dosazovani kryptickych operatoru na nahodna mista. Dovedu rozklicovat nejaky promenny, parametry, cosi se deje nad nejakym polem, ale o co presne se ten kod snazi, to mi zustava v huste mlze.

Ono je sice hezky, ze to je udajde citelny, podobny lidske reci, ale okamzite mi vrta hlavou, proc se takove jazyky, tak malo rozsirily, kdyz to ma udajne tolik vyhod?

@Karell Kdo umí číst (anglicky), ten to snad pochopí na první pohled, ne? :) BTW Operátory tam žádné nejsou.

K rozšíření: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

keby apple pouzivalo python, mozno by bol treti prave ten :-)

1) Clang je IMHO kompilátor, který je určen k vyhynutí. Jeho architektura mu dává jistou stopku v možnostech optimalizace, která zatím moc nevadí. Ale časem se stane svěrací kazajkou. Pak se bude několik let přešlapovat, až se clang opustí. I když desetiletí s námi clang ještě bude.

2) Problém Javy je hlavně v jeho nejasnosti, kdo ho udržuje, kdo vydává standardy Javy, tedy kdo je standardizátor, stejně jako párva a patenty. Souhlasím naprosto s tím, že Java se stala druhým Cobolem, tedy jazykem, který bude mít velký význam ani ne tak kvůli kvalitě jazyka, ale kvůli nutnosti udržovat již existujícíc projekty. Jinak se Java zakopala na své nice, přičemž z řady jiných musela tvrdě ustoupit pro nekvalit (jazyka nebo programátorů, to je fuk).

3) C++ skutečně renesanci prožívá. Jeho velkým plusem je, že nikdo na nikoho nehrozí patenty a licencemi, když C++ používáte či umplementujete. Je jasné, kdo ho standardizuje, jsou jasné standardy. Navíc není konkurenční jazyk v jeho nice – tedy maximálně efektivní výstupní binárka plus efektivní vývoj.

4) V C++ se dá programovat stjeně efektivně a rychle jako v Javě, ObjectiveC či jiném vyšším jazyku. Chce to ale větší zkušenosti. C++ je jazyk velmi logický, v zásadě se stačí naučit několik filozofických pravidel, a ty C++ realizuje po celém jazyce bez výjimek.

5) ARM procesor má špatnou instrukční sadu, která se hrozně špatně optimalizuje. V zásadě kvalita optimalizace závisí do značné míry na programu a problému, stejně jako na rozsahu. Někdy zvítězí to, jindy ono za kompilátor. Snaha za každou cenu udržel fixní a malou velikost strojových instrukcí vede k tomu, že ARM nedokáže ani přímo uložit jakoukoli konstantu do registru, skoky a adresy v paměti o více jak pár kilobajtů už chtějí instrukce navíc, atd. Extrémně důležité je u ARMu zvolit správnou volací konvenci, a dodnes se s tím experimentuje. Jenom Linux a gcc má několik verzí volacích konvencí, které si můžete zkompilovat.

6) ObjectiveC je jazyk, který je výsledkem boje o objektové rozšíření C. Na jedné straně bylo C++ kopírující Simulu, na druhé straně ObjectiveC kopírující Smalltalk. Problém s ObjectiveC je licence a Apple. Jazyk sám je až druhořadý, i když těžko mít rád ObjectiveC, protože Smalltalk je Smalltalk, doporučuji si ho zkusit.

7) Volba programovacího jazyka závisí nejenom na problému, ale též na vývoji. Pokud jste dobrý vývojář (či skupina dobrých vývojářů) a děláte one man show, můžete zvolit kvalitní, byť náročnější jazyk. Pokud jste velký tým a potřebujete napsat nějaký podnikový systém, pak musíte dbát i na láci, tedy zvolit jazyky méně schopné pro blbé, jako třeba tu Javu. Lidský faktor je důležitější při volbě jazyka, než technický.

8) V zásadě všechny běžné programy, které se dnes dělají v mainstreamu nejsou nic jiného, než práce pro cvičenou opici. Proto jde spíše o ekonomiku, které je podřízeno vše, než o kvalitu a znalosti lidí. Naučit se programovat na úrovni pro mainstream programování zvládne každý, kdo není mentálně retardovaný. Není to nic složitého, ani náročného. Protože bouchání formulářů, volání knihoven, psaní dotazů do databáze a sem tam otestovat hodnotu, zda je v platném rozsahu – to se opravdu naučí i cvičený šimpanz s třetinou mozku. Jazyky se pak volí podle toho.

Miloslav Ponkrác

Jeste na to koukam, ten posledni blok - pochopil jsem to tak, ze kazdemu objektu z myArray to do promenne inContext priradi localContext, je to spravne?

K Tiobe - je tam zrejme, ze se nastup ObjC kryje s nastupem iPadu (a mozna iphone), do te doby to byl jazyk naprosto okrajovy, takze to dost zkresluje skutecnou chut lidi v nem programovat.

@karell

nikoli, následující kontrukce

[myArray enumerateObjec­tsWithOptions:NSE­numerationCon­current usingBlock:^(My­ObjectType *obj, NSUInteger idx, BOOL *stop)
{
[obj updateForIndex:idx inContext:local­Context];
}];

znamená že se každému prvku myArray pošle (systém se může rozhodnout že tak učiní paralelně pro víc prvků najednou pokud jsou k tomu podmínky - viz ty options) zpráva (message)

"updateForIndex:in­Context:"

tj. aby se updatoval
* pro index hodnoty idx a
* bral přitom ohled na lokální kontext podle podle localContext

Co se ve skutečnosti s danou instancí objektu stane si pochopitelně napíšete v implementaci příslušné třídy sám.

Neboli to doslova znamená "obj! Update for index idx in context localContext."... neboli "objekte obj! Updaduj se pro index hodnoty idx v kontextu localContext.". porovnáno s kódem "[obj updateForIndex:idx inContext:local­Context]" je to podle mne dobře čitelné, pokud tam člověk přestane hledat syntaktické prvky a magie a syntaktická koření "standardních" jazyků.

objectivec malo milion prilezitosti byt slavne vdaka syntaxi a krase a dokonalosti, ba dokonca ved vraj webobjects bol svojho casu velmi progresivny stack (neskor prepisany do javy :-)))

on len mal extremne stastie na to, ze ho apple vdaka monopolu vyhrabalo z pozicie zabudnuteho jazyka a pouzilo, za normalnych okolnosti (ako ukazuje tiobe) by sa plahocil niekde dole

detto "slavny vdaka velkemu hracovi" sa stalo s javou, akurat samozrejme, ta mala 10+ rokov extremne silne pozicie na serveri.

Výběr programovacího jazyka není žádná hitparáda ani přísně racionální děj ale klasická evoluce - tj. historie plná náhod, kde nějaká výhybka přehozená z malicherné příčiny před mnoha lety je daleko podstatnější než přísně spočítané dnešní potřeby.

Jediné na co zde chci já upozornit je že ObjC není žádné nesrozumitelné zvěrstvo ale dobře srozumitelný jazyk - a co už zde nemám čas ani prostor anichuť dál ukazovat - nechť si to zájemci najdou sami - i velmi dobře promyšlený a progresivní jazyk který hezky balancuje mezi níže úrovňovým (je to furt C) a výšeúrovňovým (objekty, protokoly, paralelizace) přístupem. To že zůstává stejně jako Apple v určité exkluzivní "niche" je skutečnost která se může změnit zase spíš náhodou.

@107

Musel som na rychlo zbuchat appku na iPhone, zdrojaky mame v C#, volba jasna na Xamarin/Mono ale casto citam zdrojaky v ObjectiveC.

ObjectiveC je pekny superset Ccka, lightweight s modernymi features a peknou standardnou kniznicou. Skoda, ze konvencie/ter­minologia v tomto jazyku su tak vzdialene C#/Jave/C++, mozno by som v nom aj zacal robit. Druha nevyhoda, je viazanost na Apple platformu.

@108: já jsem si na ty konvence rychle zvyknul a rád, ovšem předtím jsem psal hlavně v Perlu a javascriptu a před tím v Delphi (Borland Pascal), hodně SQL a PL/pgSQL, naprotitomu Javu a C# jen velmi okrajově a C/C++ v podstatě vůbec. Takže mám možná výhodu že si sebou nenesu v prodloužené míše určité konvence, resp. nesu jiné než většina ostatní ;-)

ObjectiveC je pro mne radost psát, a máte pravdu, standardní knihovny a UIKit a další frameworky pro iOS jsou taky fajn a vesměs koncepčně vymyšlené - to je zase ta výhoda omezenosti platformy.

ObjC: Dřív byl problém se správou paměti. Člověk by řekl, že retain/release pochopí i trotl, ale zde byl můj odhad úplně mimo, vývojáři to neskutečně patlali. Pak ObjC dostalo properties a já si říkal - fajn, konečně klid. Prd. Zase tuny kódu špatně (iOS neměl GC). Až s ARC se situace zlepšila. To je poučení i pro psaní kódu v C++ - i relativně dobrý programátor se může ve správě paměti ztratit. Proto by mělo jít new explicitně zakázat.

S článkem plně souhlasím, myslím si, že poslední hřebíček do rakve Javě přibyl nový multiplatformní .NET, který právě opouští dílny Microsoftu.
Javě ani moc nepomohlo, že Microsoft drží politiku bez Javy, pro všechna IoT zařízení, Mobilní zařízení, Industry verze systémů, ARM tablety a také některé typy serverů.
Dále pak situaci ještě popíchly laboratoře z Cernu, které již nějakou chvíli vydávají volně šiřitelný jazyk Root, který je plně kompatibilní s C a C++, vlastně se jedná o rozšíření těchto jazyků do interpretované podoby (mnohem rychlejší, nežli Java i Phyton a Julia) a zároveň obohacený o zajímavé výpočetní a vykreslovací funkce.
Na universitě do nás hustí Javu a mohu říct, že je to utrpení ne jen v tom něco sepisovat, ale už vůbec mít Javu instalovanou.
Osobně nechápu, že těm ignorantům v Oracle ještě nedošlo, že by to s tou Javou měli zabalit, protože i pro Android lze psát v C# a C++, takže Java jako taková je prostě zbytečná.