Vyplatí se učit C++?

[zboj]

Psal jsem v kontextu Javy. Tracing GC jinak samozřejmě své nevýhody má, je ale třeba hodnotit každou implementaci zvlášť. Například v Androidu je úplně debilní, kdežto v Go (od verze 1.5) hodně kvalitní a bez problémů použitelná i pro velké aplikace. Obecně je nejlepší správa paměti na zásobníku (jako v C++/Go/Swift) a když už musí být objekt alokován na haldě, tak nějaká forma sledování referencí (k tomu existuje množství benchmarků a akademických článků). To ale není téma pro patlaly

Ted nevim, jestli jsem vztahovacnej, nebo z textu citim implicitni zarazeni me osoby do mnoziny patlalu :-) S tebou uvedenym souhlasim, a ackoliv to nemam podlozeno benchmarky a clanky, z intuitivniho hlediska mi prijde GC jako kanon na vrabce. Takova dalsi vrtstva izolace mezi vyvojarem a hw uz imho presahuje mezni uzitek z abstraktniho pristupu k programovani, protoze umoznuje se nestarat o jiz prilis podstatnou soucast programu - pamet.

V podstatě souhlasím, ale zopakuji, že záleží na implementaci. V Go je GC hodně kvalitní, tam bych se nebál přehnané náročnosti na paměť, a v ObjC byl kdysi dávno pekelně kvalitní tracing GC, byl konzervativní a hodně agresivní (kdysi jsem se v tom hrabal ještě na PPC). Apple ale do iOS tracing GC nedal (první iPhone měl jen 128MB, takže by to byla blbost). Teď už by v iOS asi ten jejich původní GC šlapal dobře, ale kód už zahodili (obrazně řečeno) a Swift beztak funguje lépe s tím, co má.

[Reklama]

[Daniel Kozak]

Psal jsem v kontextu Javy. Tracing GC jinak samozřejmě své nevýhody má, je ale třeba hodnotit každou implementaci zvlášť. Například v Androidu je úplně debilní, kdežto v Go (od verze 1.5) hodně kvalitní a bez problémů použitelná i pro velké aplikace. Obecně je nejlepší správa paměti na zásobníku (jako v C++/Go/Swift) a když už musí být objekt alokován na haldě, tak nějaká forma sledování referencí (k tomu existuje množství benchmarků a akademických článků). To ale není téma pro patlaly

Ted nevim, jestli jsem vztahovacnej, nebo z textu citim implicitni zarazeni me osoby do mnoziny patlalu :-) S tebou uvedenym souhlasim, a ackoliv to nemam podlozeno benchmarky a clanky, z intuitivniho hlediska mi prijde GC jako kanon na vrabce. Takova dalsi vrtstva izolace mezi vyvojarem a hw uz imho presahuje mezni uzitek z abstraktniho pristupu k programovani, protoze umoznuje se nestarat o jiz prilis podstatnou soucast programu - pamet.

Tak GC je jeden ze zpusobu jak resit spravu pameti umoznujici memory safety coz je pro me docela uzitecna vlastnost. Osobne zastavam nazor ze nejlepsi je pamet nealokovat a pracovat na zasobniku a v registrech. Ale pokud uz potrebuji pracovat s pameti na halde tak preferuji GC (zejmena kvuli vykonu a bezpecnosti). Samozrejme je dobre pokud mi pouziti GC jazyk nevnucuje a mam moznost pouzivat to co se zrovna pro me potreby nejlepe hodi. Jinak GC je fajn prave proto ze umoznuje se nestarat o tak zanedbatelnou soucast programu jako je pamet .

[petron]

pani, co bolo hlavnou myslienkou mojej otazky? casto sa tu debaty zvrhnu inym smerom. ach

[Daniel Kozak]

pani, co bolo hlavnou myslienkou mojej otazky? casto sa tu debaty zvrhnu inym smerom. ach

Jestli se vyplati ucit C++ (ANO), a pak ses tusim ptal i na Javu (Pokud uz umis C# tak asi ani ne , coz zpustilo tuto diskuzi ;-)

[zboj]

Psal jsem v kontextu Javy. Tracing GC jinak samozřejmě své nevýhody má, je ale třeba hodnotit každou implementaci zvlášť. Například v Androidu je úplně debilní, kdežto v Go (od verze 1.5) hodně kvalitní a bez problémů použitelná i pro velké aplikace. Obecně je nejlepší správa paměti na zásobníku (jako v C++/Go/Swift) a když už musí být objekt alokován na haldě, tak nějaká forma sledování referencí (k tomu existuje množství benchmarků a akademických článků). To ale není téma pro patlaly

Ted nevim, jestli jsem vztahovacnej, nebo z textu citim implicitni zarazeni me osoby do mnoziny patlalu :-) S tebou uvedenym souhlasim, a ackoliv to nemam podlozeno benchmarky a clanky, z intuitivniho hlediska mi prijde GC jako kanon na vrabce. Takova dalsi vrtstva izolace mezi vyvojarem a hw uz imho presahuje mezni uzitek z abstraktniho pristupu k programovani, protoze umoznuje se nestarat o jiz prilis podstatnou soucast programu - pamet.

Tak GC je jeden ze zpusobu jak resit spravu pameti umoznujici memory safety coz je pro me docela uzitecna vlastnost. Osobne zastavam nazor ze nejlepsi je pamet nealokovat a pracovat na zasobniku a v registrech. Ale pokud uz potrebuji pracovat s pameti na halde tak preferuji GC (zejmena kvuli vykonu a bezpecnosti). Samozrejme je dobre pokud mi pouziti GC jazyk nevnucuje a mam moznost pouzivat to co se zrovna pro me potreby nejlepe hodi. Jinak GC je fajn prave proto ze umoznuje se nestarat o tak zanedbatelnou soucast programu jako je pamet .

Právě ten výkon bývá problém.

[Reklama]

[Daniel Kozak]

Psal jsem v kontextu Javy. Tracing GC jinak samozřejmě své nevýhody má, je ale třeba hodnotit každou implementaci zvlášť. Například v Androidu je úplně debilní, kdežto v Go (od verze 1.5) hodně kvalitní a bez problémů použitelná i pro velké aplikace. Obecně je nejlepší správa paměti na zásobníku (jako v C++/Go/Swift) a když už musí být objekt alokován na haldě, tak nějaká forma sledování referencí (k tomu existuje množství benchmarků a akademických článků). To ale není téma pro patlaly

Ted nevim, jestli jsem vztahovacnej, nebo z textu citim implicitni zarazeni me osoby do mnoziny patlalu :-) S tebou uvedenym souhlasim, a ackoliv to nemam podlozeno benchmarky a clanky, z intuitivniho hlediska mi prijde GC jako kanon na vrabce. Takova dalsi vrtstva izolace mezi vyvojarem a hw uz imho presahuje mezni uzitek z abstraktniho pristupu k programovani, protoze umoznuje se nestarat o jiz prilis podstatnou soucast programu - pamet.

Tak GC je jeden ze zpusobu jak resit spravu pameti umoznujici memory safety coz je pro me docela uzitecna vlastnost. Osobne zastavam nazor ze nejlepsi je pamet nealokovat a pracovat na zasobniku a v registrech. Ale pokud uz potrebuji pracovat s pameti na halde tak preferuji GC (zejmena kvuli vykonu a bezpecnosti). Samozrejme je dobre pokud mi pouziti GC jazyk nevnucuje a mam moznost pouzivat to co se zrovna pro me potreby nejlepe hodi. Jinak GC je fajn prave proto ze umoznuje se nestarat o tak zanedbatelnou soucast programu jako je pamet .

Právě ten výkon bývá problém.

No tak GC vetsinou nema problem s vykonem (samozrejme zalezi na typu GC a jeho implementaci). Casto aplikace s GC bezi celkove rychleji nez napriklad za pouziti RC(neustale inkrementovani a dekrementovani dokaze taky svoje). GC ma problem zejmena u RT aplikaci, kde je zadouci aby dana cinnost probehla v urcitem maximalnim case.

[v]

pani, co bolo hlavnou myslienkou mojej otazky? casto sa tu debaty zvrhnu inym smerom. ach

IMHO ne, pokud o tom uvažujete kvůli možnostem uplatnění, tak pro  C# je určitě víc práce, pokud kvůli potřebě zkusit nový, jiný, zajímavý jazyk, tak taky ne protože rozdíl mezi C# a C++ není zas tak velký

[zboj]

Psal jsem v kontextu Javy. Tracing GC jinak samozřejmě své nevýhody má, je ale třeba hodnotit každou implementaci zvlášť. Například v Androidu je úplně debilní, kdežto v Go (od verze 1.5) hodně kvalitní a bez problémů použitelná i pro velké aplikace. Obecně je nejlepší správa paměti na zásobníku (jako v C++/Go/Swift) a když už musí být objekt alokován na haldě, tak nějaká forma sledování referencí (k tomu existuje množství benchmarků a akademických článků). To ale není téma pro patlaly

Ted nevim, jestli jsem vztahovacnej, nebo z textu citim implicitni zarazeni me osoby do mnoziny patlalu :-) S tebou uvedenym souhlasim, a ackoliv to nemam podlozeno benchmarky a clanky, z intuitivniho hlediska mi prijde GC jako kanon na vrabce. Takova dalsi vrtstva izolace mezi vyvojarem a hw uz imho presahuje mezni uzitek z abstraktniho pristupu k programovani, protoze umoznuje se nestarat o jiz prilis podstatnou soucast programu - pamet.

Tak GC je jeden ze zpusobu jak resit spravu pameti umoznujici memory safety coz je pro me docela uzitecna vlastnost. Osobne zastavam nazor ze nejlepsi je pamet nealokovat a pracovat na zasobniku a v registrech. Ale pokud uz potrebuji pracovat s pameti na halde tak preferuji GC (zejmena kvuli vykonu a bezpecnosti). Samozrejme je dobre pokud mi pouziti GC jazyk nevnucuje a mam moznost pouzivat to co se zrovna pro me potreby nejlepe hodi. Jinak GC je fajn prave proto ze umoznuje se nestarat o tak zanedbatelnou soucast programu jako je pamet .

Právě ten výkon bývá problém.

No tak GC vetsinou nema problem s vykonem (samozrejme zalezi na typu GC a jeho implementaci). Casto aplikace s GC bezi celkove rychleji nez napriklad za pouziti RC(neustale inkrementovani a dekrementovani dokaze taky svoje). GC ma problem zejmena u RT aplikaci, kde je zadouci aby dana cinnost probehla v urcitem maximalnim case.

Existuji i tracing GC pro RT (BTW RC je také GC). Nicméně podle benchmarků je tracing GC typicky pomalejší než RC z důvodů, jež zde v různých diskuzích už opakovaně zazněly (ne že bych čtenářům rootu nějak zvlášť věřil, ale vědecké články od zaměstnanců Googlu už nějakou váhu mají). V podstatě jde o to, že překladač agresivně RC optimalizuje (cokoliv, co je v rámci scope "po stacku dolů" RC nijak nezatěžuje). O vše se stará statická analýza (tak ostatně vzniklo ARC). Je třeba ovšem přiznat, že konzervativní tracing GC v některých případech nezaostává příliš. A jak už tu zaznělo, maximum paměti by stejně mělo být na zásobníku, je-li to jen trochu možné, čímž se diskuze o správě paměti na haldě stává bezpředmětnou. (Pro ostatní čtenáře: Kdo ještě nepochopil, jak funguje optimalizace RC v době kompilace, nechť si přečte příslušné články od Googlu, protože já to tu potisící  vysvětlovat nebudu.)

[zboj]

pani, co bolo hlavnou myslienkou mojej otazky? casto sa tu debaty zvrhnu inym smerom. ach

rozdíl mezi C# a C++ není zas tak velký

Mezi Porsche a kombajnem taky není velký rozdíl, má to motor a čtyři kola...

[Daniel Kozak]

pani, co bolo hlavnou myslienkou mojej otazky? casto sa tu debaty zvrhnu inym smerom. ach

IMHO ne, pokud o tom uvažujete kvůli možnostem uplatnění, tak pro  C# je určitě víc práce, pokud kvůli potřebě zkusit nový, jiný, zajímavý jazyk, tak taky ne protože rozdíl mezi C# a C++ není zas tak velký

Problem je ze nevime proc se chce ucit novy jazyk. Napriklad pokud by chtel neco zlepsit(opravit) v C#, tak to pro nej muze byt uzitecne (za predpokladu ze je .NET VM napsana v C++). Pro me (jako PHPckare) to napriklad znamena ze jsem schopen rozumet, psat a opravovat kod pro HHVM ci ruzne extension pro HHVM ci Zend PHP.

[v]

pani, co bolo hlavnou myslienkou mojej otazky? casto sa tu debaty zvrhnu inym smerom. ach

rozdíl mezi C# a C++ není zas tak velký

Mezi Porsche a kombajnem taky není velký rozdíl, má to motor a čtyři kola...

velmi správně, oboje se ovládá prakticky stejně, volant a tak

[v]

pani, co bolo hlavnou myslienkou mojej otazky? casto sa tu debaty zvrhnu inym smerom. ach

IMHO ne, pokud o tom uvažujete kvůli možnostem uplatnění, tak pro  C# je určitě víc práce, pokud kvůli potřebě zkusit nový, jiný, zajímavý jazyk, tak taky ne protože rozdíl mezi C# a C++ není zas tak velký

Problem je ze nevime proc se chce ucit novy jazyk. Napriklad pokud by chtel neco zlepsit(opravit) v C#, tak to pro nej muze byt uzitecne (za predpokladu ze je .NET VM napsana v C++). Pro me (jako PHPckare) to napriklad znamena ze jsem schopen rozumet, psat a opravovat kod pro HHVM ci ruzne extension pro HHVM ci Zend PHP.

jasně, já jsem zmínil dvě motivace, které mi přišly nejpravděpodobnější, to o čem píšete vy je triviální případ a odpověď je ano

[tomaszav]

Dobry je se podivat spis ve svete, jak se to dela (ucit se od tech nejlepsich, zacit je followovat na twitteru), nez tady na rootu. Napr. Rich Hickey je fakt zajimavej http://www.linuxjournal.com/article/10708

Po hromade let s Object Pascalem, C++, C# a ted s Javou a Groovy prozivam podobny “What have I been doing with my life?”.

Clojure je zabava. http://www.joyofclojure.com/
Bezi na JVM i CLR (ikdyz ten CLR port asi nikdo nepouziva

Pokud se chces fakt nekam posunout, koukni na Clojure, Haskell, Ocaml, Elixir a pomuze ti to byt lepsi programatorem i v jinych jazycich.

Kdybych znal jen CLR a jeho ekosystem, asi bych zacal fakt s F#.

Na druhou stranu, nejvic to ted jede v JavaScriptu. Diky node.js je i velmi bezny na serveru a ne jen v browseru a kazdy zajimavy jazyk do nej umi transpilovat (ted uz prestavaji rikat transpilovat a zacinaji zase rikat kompilovat . A diky babel.js clovek muze pouzivat posledni novinky a nechat si to prelozit do EcmaScript5 ktery umi aktualni browsery a node.js.

Pokud nevis kde zacit, sjed videa z kvalitnich konfrenci
https://www.youtube.com/channel/UC_QIfHvN9auy2CoOdSfMWDw
https://www.youtube.com/user/GotoConferences

Projed twitter Martina Fowler, Erika Meijera, ....

A tohle je fakt dobry videt http://www.infoq.com/presentations/Simple-Made-Easy

[noef]

Jak už zmínili ostatní, tak ani C++ ani Java mi jako volba na "vyzkoušení nového jazyka" nepřijde vhodná.

C++ je velmi, až snad neprakticky, komplexní (např. na FITu byl často označován jako jazyk "pejsek a kočička vařili dort"). Pokud opravdu vážně nepřemýšlíš o vývoji profi her nebo pro HW, tak bych se mu velkým obloukem vyhnul.

Java není špatný jazyk (osobně mám věci kolem JVM celkem rád), ale pokud dobře ovládáš C#, tak nevidím moc přínosů ve zkoušení Javy, která je hodně podobná a navíc by sis asi připadal celkem omezený (ve srovnání s C#).

Vyber si nejlépe nějaký jazyk, který umožnuje programovat logicky nebo funkcionálně. Ať se kromě jiné syntaxe také naučíš přístupy, které budeš moc i použít v práci.
  Pokud chceš zkusit něco na JVM, tak můžu doporučit jazyk Scala (umožňuje OOP i FP; můžeš si zkusit pohrát např. s aktory z Akka) a kurzy zdarma na Coursera. Z jiných jazyků nad JVM mě zaujal ještě skoro neznámý Frege - v podstatě Haskell na JVM. Ten jsem bohužel ještě neměl čas zkusit.
  A nebo zůstat blíže domovu a zaexperimentovat si s již doporučovaným F#, nebo se neučit nový jazyk a vyzkoušet nějaké pokročilé věci v C#/.NETu - třeba generování tříd za běhu (do .NETu moc nevidím, ale předpokládám, že to bude podobné jako u JVM).

[yep]

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.