Vyplatí se učit C++?

[zboj]

Problem tehlech elixiru, haskellu atd. je, ze autor neni beznym programatorem, ktery by dokazal porozumet tomu, co bude idealni pro normalniho programatora, ktery nema IQ 158. Oni mysli jinak, ty jejich jazyky jsou takovy.. proste vyhovuje to jim, jejich mozky v tom dokazou "videt", ale 99% programatoru tohle nezvladne a vsechno jim bude trvat tisic let. Proto se to nikdy poradne nerozsiri a bude to pouzivat jen uzka skupina programatoru. Svetu bude porad vladnout C++, Java, C# a ted mozna i Swift. Swift je presne prikladem jazyka, ktery by masa mohla prijmout, protoze nevymysli zadne nesmyslne syntaxe a celkove nepusobi takovym akadamickym dojmem. S chuti bych se do neho ponoril, kdybych jen nemel pochybnosti okolo ARC (https://swiftopinions.wordpress.com/2014/09/29/to-swift-and-back-again/) a hlavne kdyby byl port pro nejaky poradny framework ala Qt.

V principu ano, ale i Swift má jisté konstrukce, které "normální programátor" (přinejmenším zde na fóru) nechápe. Jinak co za problém má ARC?

P.S. Port nějakého frameworku časem bude, je to na komunitě.

[Reklama]

[noef]

Tak zrovna ta Scala, prestoze je z akademickeho prostredi, je zamerena dost prakticky. Bezi na tom i velke veci, tusim Twitter a LinkedIn, jestli si dobre pamatuju. Kdyby byla "vice akademicka" (predpokladam, ze myslite ciste FP), tak by asi nemela ani takovy uspech, jako nyni. Diky tomu, ze je to hybrid, lze s ni zacit v podstate psat "jak v Jave" a casem muze normalni programator pribirat vice a vice ficur z jinych svetu.

Elixir jsem myslel, ze je pribuzny s Erlangem, ktery je take komercne pouzivany (telco). O Haskellu nevim, tam to bude asi podstatne horsi, nez u predchozich. Ale po zkusenostech ze skoly s nim si nemyslim, ze by bylo potreba nadprumerne IQ. Po par tydnech (rozhodne ne intenzivniho studia) jsme byli snad vsichni v tom schopni premyslet (tj. napsat tymovy projekt, tusim AI nejake deskovky).

[zboj]

Problem tehlech elixiru, haskellu atd. je, ze autor neni beznym programatorem, ktery by dokazal porozumet tomu, co bude idealni pro normalniho programatora, ktery nema IQ 158. Oni mysli jinak, ty jejich jazyky jsou takovy.. proste vyhovuje to jim, jejich mozky v tom dokazou "videt", ale 99% programatoru tohle nezvladne a vsechno jim bude trvat tisic let. Proto se to nikdy poradne nerozsiri a bude to pouzivat jen uzka skupina programatoru. Svetu bude porad vladnout C++, Java, C# a ted mozna i Swift. Swift je presne prikladem jazyka, ktery by masa mohla prijmout, protoze nevymysli zadne nesmyslne syntaxe a celkove nepusobi takovym akadamickym dojmem. S chuti bych se do neho ponoril, kdybych jen nemel pochybnosti okolo ARC (https://swiftopinions.wordpress.com/2014/09/29/to-swift-and-back-again/) a hlavne kdyby byl port pro nejaky poradny framework ala Qt.

Ten odkazovaný článek je rok a půl starý. ARC ve Swiftu je determinističtější než v ObjC, neb nemá autorelease pool (viz kód verze pro Linux). Jinak co do rychlosti typicky vychází (as of Dec 2015) nejrychlejší C++, pak Swift, pak Go a nakonec Java), kód se ale nesmí zprasit. Swiftu bych se nebál, třeba na ARM je cca. 4x rychlejší než Java (testováno na RPi).

[tomaszav]

.....tusim..... ,........jestli si dobre pamatuju........ , ........predpokladam....., ...... by asi nemela .......

.....jsem myslel, .......nevim, tam to bude asi.......,  .......si nemyslim, ze by bylo ......

<ot>sry,ja vic v diskuzich ocenuju fakta/zkusenosti/znalost nez dohady/drby/pocity</ot>

[Kit]

<ot>sry,ja vic v diskuzich ocenuju fakta/zkusenosti/znalost nez dohady/drby/pocity</ot>

Ono to vyjde zhruba nastejno, protože to, co jeden vydává za dohady/drby/pocity, to jiný vydává za fakta/zkusenosti/znalost.

[Reklama]

[noef]

<ot>sry,ja vic v diskuzich ocenuju fakta/zkusenosti/znalost nez dohady/drby/pocity</ot>

Ono to vyjde zhruba nastejno, protože to, co jeden vydává za dohady/drby/pocity, to jiný vydává za fakta/zkusenosti/znalost.

Bohuzel...

.....tusim..... ,........jestli si dobre pamatuju........ , ........predpokladam....., ...... by asi nemela .......

.....jsem myslel, .......nevim, tam to bude asi.......,  .......si nemyslim, ze by bylo ......

<ot>sry,ja vic v diskuzich ocenuju fakta/zkusenosti/znalost nez dohady/drby/pocity</ot>

Myslim, ze uz ted venuji jednomu prispevku vice casu, nez vetsina ostatnich, kteri prispivaji. Diskuze o tom, zda by se nekdo mel naucit dalsi jazyk, je IMO prave o dojmu a pocitu, jestli to dotycnemu k necemu bude a samozrejme nazory na jazyky a technologie budou vzdy take silne subjektivni. (Plus teda jedno spojeni se vaze k mlhavemu vyjadreni predchoziho prispevku, pokud bych to spojeni vynechal, tak "natvrdo" podsouvam svoji interpretaci a vydavam ji za neco, co dotycny mozna ani nemyslel.)

Pokud vas ale tolik trapi moje nedostatecne asertivni vyjadrovani, tak si jednoduse odmyslete ta vatova slova. Zdroje o uziti Scaly jsou k nalezeni zde. Vse, co jsem napsal, sedi k clanku na wiki - Elixir a Erlang.

Pokud neco nevim na 100% (napr. necetl jsem dany clanek pred pul hodinou), tak proste nemam ve zvyku to tak prezentovat.

PS: Nemusite se obtezovat s vyzobavanim slovnich spojeni, ktera vas tak drazdi. Vim ze tu jsou a je mi to jedno. Pokud vam vadi muj styl psani, tak prosim moje prispevky nectete .

[hehe]

https://www.quora.com/Is-LinkedIn-getting-rid-of-Scala

[atakdalekeokzakrokem]

https://www.quora.com/Is-Twitter-getting-rid-of-Scala

[noef]

https://www.quora.com/Is-LinkedIn-getting-rid-of-Scala

Tak pokud je pravda, jak o tom nekdo pise, ze duvodem pro Scalu byl "cool faktor" . Ne, vazne, pokud ze Scaly chteli jen zaklady paralelniho pristupu (asi future, iteratee apod.) a dal se neposunuli, tak je celkem pochopitelne, ze s novou Javou neni pro ne duvod zustavat u Scaly. Stejna situace by byla, kdyby si firma vyzkousela C++ a pak se vratila k C, protoze jim plne stacilo a vyvojari stejne v C++ tapali. Neni to chyba jazyka nebo technologie, pokud ji nekdo nasadi spatne.

Nevim, jestli se mam vubec obtezovat s vyvracenim "Swift je 4x rychlejsi nez Java". Mozna, pokud plati podminka "kód se ale nesmí zprasit" a zaroven se investuje nekolikanasobne vice casu do vyvoje (tj. kod se "doprasi" low-level optimalizacemi), pak to asi muze platit, ikdyz stale pochybuji o univerzalnosti tvrzeni. Vyhoda Javy/C# je prave v tom, ze rychle (= levne) dostanete pomerne rychle fungujici reseni, ktere muzete zase levne (ve srovnani s C++) rozsirovat. Z mala zkusenosti*, co mam s C/C++ vs Java/Scala, mi vyslo, ze toto "pomerne rychle fungujici reseni" je ve vetsine pripadu rychlejsi, nez reseni v C++ vyvinute za stejny cas.

*: Muj vzorek je ale maly. Celkem by me zajimalo, jestli existuje nejake srovnani zohlednujici krome vysledneho vykonu take napr. dobu a cenu vyvoje.

[tomaszav]

..... z mala zkusenosti.....


Tak kdyz necemu nerozumim, nebo nemam zdroj tak o tom nemuzu diskutovat prece

[kilimanjar]

..... z mala zkusenosti.....


Tak kdyz necemu nerozumim, nebo nemam zdroj tak o tom nemuzu diskutovat prece

Zdrojem jsou právě ty zkušenosti. A Vy nějaké máte?

[zboj]

https://www.quora.com/Is-LinkedIn-getting-rid-of-Scala

Tak pokud je pravda, jak o tom nekdo pise, ze duvodem pro Scalu byl "cool faktor" . Ne, vazne, pokud ze Scaly chteli jen zaklady paralelniho pristupu (asi future, iteratee apod.) a dal se neposunuli, tak je celkem pochopitelne, ze s novou Javou neni pro ne duvod zustavat u Scaly. Stejna situace by byla, kdyby si firma vyzkousela C++ a pak se vratila k C, protoze jim plne stacilo a vyvojari stejne v C++ tapali. Neni to chyba jazyka nebo technologie, pokud ji nekdo nasadi spatne.

Nevim, jestli se mam vubec obtezovat s vyvracenim "Swift je 4x rychlejsi nez Java". Mozna, pokud plati podminka "kód se ale nesmí zprasit" a zaroven se investuje nekolikanasobne vice casu do vyvoje (tj. kod se "doprasi" low-level optimalizacemi), pak to asi muze platit, ikdyz stale pochybuji o univerzalnosti tvrzeni. Vyhoda Javy/C# je prave v tom, ze rychle (= levne) dostanete pomerne rychle fungujici reseni, ktere muzete zase levne (ve srovnani s C++) rozsirovat. Z mala zkusenosti*, co mam s C/C++ vs Java/Scala, mi vyslo, ze toto "pomerne rychle fungujici reseni" je ve vetsine pripadu rychlejsi, nez reseni v C++ vyvinute za stejny cas.

*: Muj vzorek je ale maly. Celkem by me zajimalo, jestli existuje nejake srovnani zohlednujici krome vysledneho vykonu take napr. dobu a cenu vyvoje.

Netřeba se obtěžovat s psaním příspěvků, mnohem lepší je ověřit si to nad vlastním kódem a ten si pak nejlépe nechat někým zkontrolovat, neb nikdo nemůže vědět vše a celkem základní nedostatek může vést u benchmarku k chybným závěrům.

[zboj]

https://www.quora.com/Is-LinkedIn-getting-rid-of-Scala

Tak pokud je pravda, jak o tom nekdo pise, ze duvodem pro Scalu byl "cool faktor" . Ne, vazne, pokud ze Scaly chteli jen zaklady paralelniho pristupu (asi future, iteratee apod.) a dal se neposunuli, tak je celkem pochopitelne, ze s novou Javou neni pro ne duvod zustavat u Scaly. Stejna situace by byla, kdyby si firma vyzkousela C++ a pak se vratila k C, protoze jim plne stacilo a vyvojari stejne v C++ tapali. Neni to chyba jazyka nebo technologie, pokud ji nekdo nasadi spatne.

Nevim, jestli se mam vubec obtezovat s vyvracenim "Swift je 4x rychlejsi nez Java". Mozna, pokud plati podminka "kód se ale nesmí zprasit" a zaroven se investuje nekolikanasobne vice casu do vyvoje (tj. kod se "doprasi" low-level optimalizacemi), pak to asi muze platit, ikdyz stale pochybuji o univerzalnosti tvrzeni. Vyhoda Javy/C# je prave v tom, ze rychle (= levne) dostanete pomerne rychle fungujici reseni, ktere muzete zase levne (ve srovnani s C++) rozsirovat. Z mala zkusenosti*, co mam s C/C++ vs Java/Scala, mi vyslo, ze toto "pomerne rychle fungujici reseni" je ve vetsine pripadu rychlejsi, nez reseni v C++ vyvinute za stejny cas.

*: Muj vzorek je ale maly. Celkem by me zajimalo, jestli existuje nejake srovnani zohlednujici krome vysledneho vykonu take napr. dobu a cenu vyvoje.

P.S. Je to univerzální tvrzení pro generický kód, ono se totiž v těch jazycích ani moc prasit nedá (nepočítám využití ASM apod., to jde všude a benchmark by v tom psal jen debil). Vsadím boty, že kód nevyužívající knihovny (psané pro většinu jazyků zhusta - proč asi - v C nebo přímo ASM), tj. testující jen kvalitu překladače, v Javě rychlejší nebude ani omylem. "Argument" o low-level a delším času na vývoj je ničím nepodložený rádobyargument nemající váhu. V tomto případě je ostatně validním argumentem jen kód.

[Ivan Nový]

Ne.

Znas CLR, nauc se F#, to te posune uplne jinam. Souhlas s kolegou vyse co mluvil o haskellu atd.

Rozsiri ti to schopnost premyslet a uvazovat lepe o programech.
Naucit se c++, ti vezme hlavne hodne mentalnich sil s technicistnima vecma, ktere te ale tak daleko neposunou, protoze jsou c++ specific.

Veci co frci v F#, Clojure, Haskellu, se ted dostavaji do JavaScriptu a tim padem i do mainstreamu.

Vsak uz i C++ a Jave jsou lambdy vid, a to je teprve zacatek. To jak ted kazdej jde do FRP a Observables (RxJS,....) je taky dost posun v tom jak se co dela.

lambdy to je goto moderních programovacích jazyků, když někde potřebujete použít lambda výraz, znamená to, že aplikaci máte špatně navrženu a řešíte něco ad hoc, a aplikace se postupně stává nerošiřitelná a neudržovatelná. Kompaktní zápis je téměř vždy na škodu, zavádí magii a manýru do kódu, vytváří se tím vlastní jazyk programátora, který ztěžuje porozumění ostatním, roste redundance kódu, programátor pak místo na řešení problémů zaměřuje svou pozornost na vytváření efektních figur, přičemž není schopen je uzavřít do znovupoužitelných funkcí, protože mají jen ornamentální povahu a nenesou svůj vlastní obsah a vytvářejí šum v kódu. Jsou pak obdobou endogenních virů biologických systémů.

Budou-li programovat stroje, tak budou používat funkcionální jazyky, protože ty umožňují řešit problémy bez existence mentálního modelu problému, který strojům zatím není přístupný. A určitě kód naprogramovaný stroji nebude optimální a nebude rozšiřitelný, pokud bude potřeba změna, stroj starý kód zahodí a systém vygeneruje celý znovu, ostatně tak funguje i biologická evoluce, když hledá řešení. Bude to mít zajímavé důsledky, změny nebudou přinášet jen zlepšení, ale často zhoršení funkčnosti, protože proces generování bude založen na nějaké heuristice, která bude obměňovat dříve vygenerovaný systém a testovat dosažení požadované změny. Počet pokusů bude ovlivňován náklady a tlačen dolů, takže zákazník bude platit podle kvality náhodně dosaženého řešení.

[noef]

..... z mala zkusenosti.....

Tak kdyz necemu nerozumim, nebo nemam zdroj tak o tom nemuzu diskutovat prece

Zacinam mit podezreni na trolla. Podle ceho soudite, ze nerozumim Jave/Scale? Nebo clovek musi rozumnet C++, aby byl schopen srovnat vykon (ne je psat) dvou implementaci v Jave a C++? Jednalo se o mensi projekty, ale nevidim duvod, proc se nepodelit o zkusenost, od toho tu snad je toto forum.

Z benchmarku, co jsem nasel, to vypadalo zatracene vyrovnane pro Javu a C++. Akorat s tim rozdilem, ze C++ varianta byla narocnejsi na vytvoreni. Myslim si, ze vykon C++ je casto precenovany. On se magicky nikde nenabere, pokud mate pomaly algoritmus, tak v Jave bude diky JITu s velkou pravdepodobnosti mnohem rychlejsi, nez v C++. Pokud mate rychly alogritmus, tak budto to nabouchate rychle v Jave a ono to bude prumerne rychle, anebo musite nasobne dele v C/C++ zatracene dobre naplanovat praci s pameti (odtud to "low-level"), abyste prekonali JIT a GC v Jave. Pak tedy samozrejme muzete zvolit i profesionalnejsi pristup v Jave, dosahnout velice solidniho vykonu, ale s kratsim casem na vyvoj.

Nevim, jestli se citite urazen vyrokem, ze C++ je spatlanina (pejsek a kocicka), ale je to bohuzel pravda. A rozhodne to nerikam proto, abych "vyhral" diskuzi. Podobny nazor mam i na JavaScript, ve kterem nyni prevazne pracuji. A prestoze Java mi prijde o trochu lepsi, tak ma take hodne much (nejvetsi asi generika, ve srovnani s C# je to slabota, a to .NET moc nemusim).

...
P.S. Je to univerzální tvrzení pro generický kód, ono se totiž v těch jazycích ani moc prasit nedá (nepočítám využití ASM apod., to jde všude a benchmark by v tom psal jen debil). Vsadím boty, že kód nevyužívající knihovny (psané pro většinu jazyků zhusta - proč asi - v C nebo přímo ASM), tj. testující jen kvalitu překladače, v Javě rychlejší nebude ani omylem. "Argument" o low-level a delším času na vývoj je ničím nepodložený rádobyargument nemající váhu. V tomto případě je ostatně validním argumentem jen kód.

Pokud ma jazyk rychle knihovny, tak pro spravne pouziti jazyka zvolime rychlou knihovnu - nemusime sami psat v C/C++/asm a dosahneme stejneho vysledku, jako nekdo v C++, ktery bude znovu kulatit kolo a velmi dlouho vyvijet neco, co uz pro jine technologie existuje "zadarmo". Co si pamatuju, tak v Jave volat prilist casto nativni kod je hodne nevyhodne, tim bysme si v benchmarku nepomohli (leda by se cely vypocet, ne casti, pocitali externe). V C++ lze jit opravdu nizko, ale rucne optimalizovat na urovni ASM a byt lepsi nez prekladac uz nyni obcas byva problem. Navic casova narocnost takoveho ukonu ve srovnani s prekladacem je rozdil mnoha radu.

To myslite vazne s tim, ze v C++ se vyviji rychleji nez v Jave/C#? Proto tyto "vyssi" jazyky vznikly, aby odstinily od bremene rucni udrzby pameti a programator se mohl soustredit na ukol misto reseni technickych detailu.

Validnim argumentem pro obecne tvrzeni je pouze kod? Pokud guru stravi tisic hodin ladenim dokonaleho trideni pro tabulku vitezu v singleplayer hre v asembleru a prijde pepa a zboucha to v Jave za pet minut, tak prestoze reseni od profika nese vyrazne lepsi vysledky, je nanic, protoze nikdo nezaplati 1k hodin specialisty na jednoduchy nekriticky ukol, pokud to zvladne stredoskolak za 5 minut.

Vzhledem k tomu, ze v C++ lze pouzit ASM, tak si troufam rict, ze vzdy pujde napsat rychlejsi nebo stejne rychle reseni jako v Jave. Pokud uplne ignorujeme cas (tim padem penize) potrebny pro vyvoj, pak je C++ vzdy lepsi nebo stejne dobre jako Java. Ne, jsem si zcela jisty, ze pri srovnavani jazyku nemuze byt jedinnou metrikou rychlost v benchmarcich, jinak by jsme totiz zustali navzdy u datlovani kodu ve strojovem jazyce.

Abych rekl pravdu, tak me take prekvapilo, jak srovnatelne si Java oproti C++ casto vede. Nejak tak podvedomne, asi pod vlivem nikdy nekoncici kampane odpurcu o pomalosti a nenazranosti Javy, jsem predpokladal, ze to bude alespon jednou tak pomale. Videt je to napr. v tomto clanku (ta pomalost Javy pro mensi narocnost je dana tim, ze se meril i start JVM, coz je IMO spatne).