Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: peton 28. 12. 2015, 10:48:52
-
Ahojte rootaci,
mam taky mensi dotaz. Oplati sa v dnesnej dobe ucit C++? Ja mam nejake tie zaklady zo skoly este, ale uz si pamatam len tak letmo. Primarne som .net/c# programator a rozmyslam, ci nezakusnut do niecoho ineho resp. nejaky novy jazyk. Co odporucate. Dakujem
-
Určitě, ale připrav se na to, že se to musíš učit jako by jiný jazyk na světě neexistoval. Je to celoživotní partnerka. Pokud se začneš učit C++ vedle C#, Javy, pythonu, PHP a dalších rádobyjazyků, pak ho nikdy nepochopíš a nikdy ho nebudeš umět.
C++ je královská disciplína.
-
Ahojte rootaci,
mam taky mensi dotaz. Oplati sa v dnesnej dobe ucit C++? Ja mam nejake tie zaklady zo skoly este, ale uz si pamatam len tak letmo. Primarne som .net/c# programator a rozmyslam, ci nezakusnut do niecoho ineho resp. nejaky novy jazyk. Co odporucate. Dakujem
Áno oplatí sa aj v dnešnej dobe učiť C++, teda aspoň podľa mňa, pretože sa naučíš veľa dôležitých vecí a ten jazyk by mal poznať aspoň "z vlaku" asi každý programátor. Bol to môj vôbec prvý jazyk s ktorým som sa stretol a môžem povedať že neľutujem, potom mi všetko ostatné prišlo o dosť jednoduchšie :), ale na tvojom mieste by som sa skôr pozrel na niečo také ako TDD napríklad, to je celkom zaujímavé, úplne odlišné rozmýšlanie, v konečnom dôsledku aj clekom užitočné :) a tam na jazyku moc nezáleží (kľudne skombinuj aj s učením C++), teda ak chceš niečo nové :)
-
No ja som si celkom dost presiel Ceckom na skole. Potom trochu C++. Uvazoval som aj nad Javou, kedze ta je podobna C#. Ale tazko sa je ucit, ked clovek nevie na com, citanim knizok to len tak nepjde, treba aj nieco tvorit
-
Ahojte rootaci,
mam taky mensi dotaz. Oplati sa v dnesnej dobe ucit C++? Ja mam nejake tie zaklady zo skoly este, ale uz si pamatam len tak letmo. Primarne som .net/c# programator a rozmyslam, ci nezakusnut do niecoho ineho resp. nejaky novy jazyk. Co odporucate. Dakujem
Urcite se to oplati. Ja se zrovna taky vrhnul na C++ (drive jsem v nem umel docela obstojne, ale jen podle stare normy). A musim uznat ze moderni C++ je uz docela pouzitelne :). Ale stale radeji kodim v jazyku D.
-
Pokud tě primárně živí C#/.NET, tak bych se spíš soustředil na ostatní levely vývoje, např. SW architektura, návrhové vzory, TDD, refactoring, verzování a další záležitosti, které s vývojem souvisí. Přibírat k tomu C++ považuji za nevhodné, protože je to krok stranou.
-
Ne. Pro rozšíření obzorů jsou tu jazyky jako Smalltalk, Lisp, Haskell - pokud neplánuješ, že C++ se stane tvým hlavním jazykem,
tak Ti nemá co nabídnout.
Zaměř se na věci které Ti mohou něco dát. Ať už je to jeden z výše jmenovaných jazyků (různá paradigmata), nebo na oblast návrhu, TDD, apod.
-
a co java?
-
Ahojte rootaci,
mam taky mensi dotaz. Oplati sa v dnesnej dobe ucit C++? Ja mam nejake tie zaklady zo skoly este, ale uz si pamatam len tak letmo. Primarne som .net/c# programator a rozmyslam, ci nezakusnut do niecoho ineho resp. nejaky novy jazyk. Co odporucate. Dakujem
Moderní C++ se vyplatí, stejně jako z nativních jazyků ještě Go a především Swift.
-
Ahojte rootaci,
mam taky mensi dotaz. Oplati sa v dnesnej dobe ucit C++? Ja mam nejake tie zaklady zo skoly este, ale uz si pamatam len tak letmo. Primarne som .net/c# programator a rozmyslam, ci nezakusnut do niecoho ineho resp. nejaky novy jazyk. Co odporucate. Dakujem
Moderní C++ se vyplatí, stejně jako z nativních jazyků ještě Go a především Swift.
proc Swift?
-
Určitě, ale připrav se na to, že se to musíš učit jako by jiný jazyk na světě neexistoval. Je to celoživotní partnerka. Pokud se začneš učit C++ vedle C#, Javy, pythonu, PHP a dalších rádobyjazyků, pak ho nikdy nepochopíš a nikdy ho nebudeš umět.
C++ je královská disciplína.
Asi jako Bash, věnujete mu tolik energie, a zápisy jsou tak sofistikovaně nesrozumitelné, že už pak nikdyy nemáte odvahu zahodit ty nesmysly, co jste se tak obtížně naučil a vše pak děláte v něm, i když pro danou úlohu to není zrovna optimální :-)))
-
Ahojte rootaci,
mam taky mensi dotaz. Oplati sa v dnesnej dobe ucit C++? Ja mam nejake tie zaklady zo skoly este, ale uz si pamatam len tak letmo. Primarne som .net/c# programator a rozmyslam, ci nezakusnut do niecoho ineho resp. nejaky novy jazyk. Co odporucate. Dakujem
Moderní C++ se vyplatí, stejně jako z nativních jazyků ještě Go a především Swift.
proc Swift?
Protože je nejmodernější. Nevýhodou je, že není (zatím) pro Windows.
-
Ak ta zaujima low level (mcu, OS, ovladace..), alebo hry tak ano. Na web nie. Java sa oplati vediet kvoli androidu, prip. ked chces robit banking a take veci.
-
Ať se nám to líbí a nebo ne, tak naneštěstí se dnes jako nejpraktičtější jeví naučit se dobře JavaScript. Pokud vám nevadí Microsoft a chcete jazyk který realizuje "klasickou" dědičnost, tak se naučte TypeScript a mrkněteš na "definityle typed" věci. Z hlediska zaměstnatelnosti, o kterou jde nakonec především, se toto jeví jako velmi dobrá volba. Doplnit znolstí HTML5+CSS3 a C# a práci seženete v každém velkém městě, bez ohledu na to kde vás osobní okolnosti donutí žít ;)
-
Ať se nám to líbí a nebo ne, tak naneštěstí se dnes jako nejpraktičtější jeví naučit se dobře JavaScript. Pokud vám nevadí Microsoft a chcete jazyk který realizuje "klasickou" dědičnost, tak se naučte TypeScript a mrkněteš na "definityle typed" věci. Z hlediska zaměstnatelnosti, o kterou jde nakonec především, se toto jeví jako velmi dobrá volba. Doplnit znolstí HTML5+CSS3 a C# a práci seženete v každém velkém městě, bez ohledu na to kde vás osobní okolnosti donutí žít ;)
Zivot neni jen o praci, a diky nam programatrum tu praci ani mi sami casem mit nebudem :D automatizace je budoucnost, ale je to budoucnost pro par vyvolenych a ostatni na pracak
-
karel
tak to je daleka hudba buducnosti. zatial nie je naznak toho, ze by pocitace programovali programy. tie pocitace progrmuju stale ludia
-
Zivot neni jen o praci, a diky nam programatrum tu praci ani mi sami casem mit nebudem :D automatizace je budoucnost, ale je to budoucnost pro par vyvolenych a ostatni na pracak
[/quote]
Ale budete mít práci, protože pojištění, které bude firma platit za použití autonomních kreativních robotů a daně z nich, budou časem tak velké, že práce člověka vyjde levněji. Jen si stroje a lidé vymění úlohy, rutinní činnnosti budou dělat lidé a kreativní činnosti stroje, nebo jejich symbionti, lidé s mentálními implantáty, které jim zprostředkují databázi sdílených znalostí a schopností :-)))
-
To s tou automatizací si už možná mysleli kdysi před rozmachem počítačů elektrotechnici. To jsou takoví programátoři doby minulé v podstatě. Taky si tehda říkali, jak tou svou prací přijdou o práci, když dělají na těch mikroprocesorech :-) no ale dali práci programátorům. My taky předáme štafetu, postupně.
-
Zivil jsem se nekolik let jako python developer a pripadal si, ze jsem polobuh, prace byla, plat slusny, umel jsem vsechno. Aspon jsem si to o sobe myslel.
V novém zamestnani jsem zacal ucit programovat v C++ multithreaded sitove aplikace a moduly do pythonu. Teprv tehdy jsem si uvedomil, jak malo jsem toho predtim umel. A neuveritelne vzrostla moje hodnota na trhu prace.
Takze ano, z vlastni zkusenosti mohu doporucit ucit se C++.
-
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.
-
a co JAVA? vyplati sa?
-
a co JAVA? vyplati sa?
Jave se rika Cobol dnesni doby. Oproti C# to je o dost slabsi.
Ale ma vybornou VM. Pouziva se skoro vsude. Volnych jobu na to je asi nejvic ze vsech platforem.
Prachu za to platej dost.
A na JVM se da pouzivat vice zajimavych jazyku, viz treba zmineny Clojure.
-
a co JAVA? vyplati sa?
Ne
-
a co JAVA? vyplati sa?
Ne
Z tehle lidi se mi chce brecet. Jednoznacna odpoved bez vysvetleni...
Musis brat co pro tebe znamena vyplati se. Pokud chces byt na urovnich nekterych zdejsich guru, ktery uznavaj jen cecko nebo dokonce assembler, protoze proste linux nebo jedou stylem ruznych obscurnich jazyku, protoze proste jit s proudem je out, tak se opravdu java nevyplati.
Pokud chces neco vydelat a mit moznost karierniho postupu, jdi do javy nebo C# a na to navazany vyssi technologie. Firmy si davno spocitaly, ze vytvaret slozite bussines appky je v vyssich jazycich levnejsi a proto jedou predevsim.
Nicmene toto nezamenuj za vyjadreni, ze java je nej/uber a vsespasna. Kazda technologie se hodi na neco. Na nizke veci C/C++, na jednoduchy webiky PHP, na bussines aplikace Java napriklad.
a co JAVA? vyplati sa?
Jave se rika Cobol dnesni doby. Oproti C# to je o dost slabsi.
Toto jen ciste pro moji zajimavost. C# znam jen povrchne. Myslite, ze je slabsi jazyk jako takovej nebo celej framework .NET (proti Jave EE a jeji implementacim).
Dekuji
-
Co to je ucit se c++? Pointrovou aritmetiku by měl každý programátor umět a máš jí zmáknutou za pár dní.
-
tak C++ nie je len o pointrovej aritmetike. C++ je uplne ine myslienie, ine paradigma, nez nejaka Java, alebo C#
-
Syntax a pointry se fakt naucis za par dni. Nicmene syntax jazyka ti je k nicemu pokud k tomu neznas celej ekosystem kolem toho. To je na mesice aktivniho programovani (a dele, podle hloubky).
-
Co to je ucit se c++? Pointrovou aritmetiku by měl každý programátor umět a máš jí zmáknutou za pár dní.
Mezi C++ a C# jsou obrovské rozdíly ve stylu programování. Pointerová aritmetika v tom hraje jen minimální roli.
-
Stručně můj názor:
Ten, kdo neumí C++, je jen programátor, zatímco ten, kdo C++ umí, je pan Programátor.
A je jedno, v čem programuje!
-
Mně zase fascinuje to kvantum odborníků, kteří vědí, že C++ je lowlevel
Není.
Je to jako s javascriptem. Javascript je vlastně taky hodně lowlevel. Bez knihoven, node.js, JQuery, Angularu, Reactu a dalších nadstaveb by v tom taky programovali jen páni Programátoři.
C++ není jen standardní knihovna a (šílenej) boost - není to jen hromada nepřehledného kódu jak si někteří C++ guru a obdivovači B. Stroustrupa představují. V C++ jde psát i hezký kód a pomocí dobrých knihoven i pěkně čitelný, který se může co do rychlosti vývoje rovnat s Javou.
Problém je, že těch dobrých a známých knihoven moc není.
-
Souhlasim, ale presne jak rikate. Jde to kdyz jsou knihovny, ale moc jich neni. Java/C# na tohle nabizi nejen knihovny, ale uceleny technologie.
Vazim si kazdyho kdo neco umi, tudiz i lidi co ovladaji C++. Nicmene je nutne brat v potaz to, ze vytvoreni javovske aplikace bude z 90% rychlejsi kvuli dostupnym technologiim a vetsi blbuvzdornosti. S spousti retez -> aplikace v jave/C# jsou levnejsi -> vetsina firem co chteji slozitejsi informacni system voli javu/C# -> vetsi poptavka na trhu prace.
Clovek, kterej ma na to ovladnout C++ a da se na rychle porozumi architekture technologii a vyhoupne se nad radovy programatory. Tim chci rict jsou i javysti, pred kterejma smekam protoze spravne navrhnout velkej informacni system vyzaduje stejny ne-li vyssi naroky nez na dobryho cppckare.
-
Stručně můj názor:
Ten, kdo neumí C++, je jen programátor, zatímco ten, kdo C++ umí, je pan Programátor.
A je jedno, v čem programuje!
Nepravda. C++ je složité, ale není to jediné kritérium odlišující lopatu od profíka.
-
Ten kdo umi LISP je pan Programator (viz SICP), ten kdo umi ASM je pan Programator, atd... nikdy nepochopim proc se kvuli nekolika lamam ktere za cely zivot neumi vytahnout hlavu ze sve vlastni zadeke musi vzdy zvrhnout jakakoliv diskuze v absolutni frasku.
-
Nevšiml jsem si, zda v tomto vláknu bylo zmíněno RAII. To je asi největší výhoda C++ proti jazykům s GC paměti. Zdůrazňuji tu paměť, protože GC neřeší prostředky operačního systému (handly, soubory, sokety) a databázové prostředky (spojení, příkazy, result sety).
Je smůla, že C++ nemá standardní API pro sokety a databáze. Boost nepočítám, protože to není standard.
Jak by mohlo vypadat SQL API pro C++ v duchu RAII, ilustruje třeba knihovna SOCI. Je možné napsat něco jako
std::string jmeno, prijmeni, rodne_cislo = "123456";
SOCI::SQL(db,jméno,heslo) << "select jmeno,prijmeni from tabulka where rodnecislo=:rc", into(jmeno), into(prijmeni), use(rodne_cislo);
První objekt je databázové spojení, které lze uložit do proměnné nebo neuložit a rovnou na něm provést příkaz sql pomocí přetíženého operátoru <<. Pomocí přetíženého operátoru "," jsou zadány vazby na C++ proměnné. Funkce "into" a "use" balí proměnné různých typů do objektů řešících konverzi dat. Prostředky samozřejmě uvolňují destruktory.
Podobně elegantně jsou řešené připravené dotazy i resultset s více řádky, které je navíc možno iteratovat v knihovně STL.
V Javě s JDBC by stejný dotaz vypadal asi takto, s použitím try ... finally pro bezpečné zavření spojení:
Connection c = DriverManager.getConnection(db,jmeno,heslo);
try {
PreparedStatement ps = c.prepareStatement("select jmeno,prijmeni from tabulka where rodnecislo=?");
ps.setString(1, rodne_cislo);
ResultSet rs = c.createStatement().executeQuery("select jmeno,prijmeni from tabulka where rodnecislo=?");
if (rs.next())
{
jmeno = rs.getString(1);
prijmeni = rs.getString(2);
}
} finally {
c.close();
}
Petr123: kdo umí Assembler a C++, je pan Programátor, ale dělá většinou mizerně placený embed jako alarmy, docházkové terminály nebo jiná mačkátka s displeyem, v lepším případě nějaké řízení strojů, i když na to jsou jiné jazyky než C++. A v některých starších firmách se (rovněž za bídné peníze) dělá Win32 desktop ve Visual C++ (MFC) nebo Delphi.
-
Souhlasim, ale presne jak rikate. Jde to kdyz jsou knihovny, ale moc jich neni. Java/C# na tohle nabizi nejen knihovny, ale uceleny technologie.
Vazim si kazdyho kdo neco umi, tudiz i lidi co ovladaji C++. Nicmene je nutne brat v potaz to, ze vytvoreni javovske aplikace bude z 90% rychlejsi kvuli dostupnym technologiim a vetsi blbuvzdornosti. S spousti retez -> aplikace v jave/C# jsou levnejsi -> vetsina firem co chteji slozitejsi informacni system voli javu/C# -> vetsi poptavka na trhu prace.
Clovek, kterej ma na to ovladnout C++ a da se na rychle porozumi architekture technologii a vyhoupne se nad radovy programatory. Tim chci rict jsou i javysti, pred kterejma smekam protoze spravne navrhnout velkej informacni system vyzaduje stejny ne-li vyssi naroky nez na dobryho cppckare.
S tým návrhom súhlasím, to je dosť umenie a vôbec to nie je jednoduché navrhnúť a potom ďalej spravovať, rozširovať, udržovať veľký systém. Taký človek musí jednak vedieť perfektne programovať a musí vedieť veľmi veľa o softwerovom inžinierstve.
-
S tým návrhom súhlasím, to je dosť umenie a vôbec to nie je jednoduché navrhnúť a potom ďalej spravovať, rozširovať, udržovať veľký systém. Taký človek musí jednak vedieť perfektne programovať a musí vedieť veľmi veľa o softwerovom inžinierstve.
Navrhnout aplikaci žádné umění není. Největší průser je právě to rozšiřování, což programátor neovlivní, stejně jako rozporuplné zadání. Tady má výhodu menší firma nebo živnostník, protože toho nikdo nenutí na nesmylné požadavky kývnout. Pokud se nejde se zákazníkem dohodnout, tak ať jde jinam. Průser větších firem je v tom, že nesmyslné zadání častěji z hlavy "analytika" nebo "architekta" než z hlavy zákazníka. Analytik totiž skutečnou analýzu neprovádí, jen zapisuje průběh schůzky se zákazníkem, nemá ponětí, co se honí v hlavě zákazníka a po skončení schůzky končí práce analytika. Skutečná analýzaje zůstane na programátorovi a to bez kontaktu se zákazníkem. Poslední slovo má "analytik" (většinou vedoucí vývoje nebo projektový manager), který je přesvědčen, že zákazníka pochopil.
-
Hento porovnanie sql je neferove, lebo v c++ by si musel ukazat ako vyzera ODBC.
Btw mna fascinuje odbornik na c++ co nevie citat..
-
Hento porovnanie sql je neferove, lebo v c++ by si musel ukazat ako vyzera ODBC.
Nejde o SQL, ale obecně o desktruktory v C++ a RAII. Java má sice finalizer, ale ten je v praxi na nic. A tak se v Javě používají obyčejné metody pro vytváření a rušení prostředků, tak jak se v používaly obyčejné funkce v C před vynálezem C++.
Btw mna fascinuje odbornik na c++ co nevie citat..
Kde v předchozím příspěvku tvrdím, že jsem odborník ? Ani pořádně neovládám virtuální desktruktory při vícenásobné dědičnosti nebo novinky v C++14.
-
A když se ti nelíbí příkad se SOCI, tak jiný příklad s appendem do textového souboru (řekněme, že chceme schválně soubor pokaždé zavřít při zjišťování, kde program spadne):
C++:
std::ofstream("log.txt", ofstream::app) << " funkce xy, parametr " << param;
Java:
FileWriter wr = new FileWriter("log.txt", true);
try { wr.write("funkce xy, parametr " + param); } finally { wr.close(); }
Pokud nebazírujeme na 100% uvolňování prostředků, jde to podobně stručně jako v C++. Ale o tom to je v C++ to jde stručně a robustně zároveň.
Např. s hypotetickou třídou kombinující StringBuilder a Writer by šlo napsat toto, ale s rizikem neuvolnění prostředku při výjimce:
new FileAppender("log.txt", true).append("funkce xy, parametr " + param).close();
Nevím, jestli nejnovější JDK má takovou třídu ve stylu C++ streamů, ale není problém ji vytvořit a hlavně zde neřeším API, na rozdíl od tebe s tím ODBC. Pointa mého prvního příspěvku je v tom, že pouze v C++ se destruktor volá automaticky na konci bloku nebo po vyhodnocení výrazu a volá se i v případě výjimky. Takže se nemusí ručně psát try .. finally { volej náhradu destruktoru } a protože to dělá kompilátor automaticky, eliminuje se chyba lidského faktoru.
Vychvalovači Garbage Collectoru zapomínají, že operační paměť není jediný typ systémového prostředku.
-
Porovnavat moznosti jazyka na takovyhle primitivni syntaxy je dost lamerina. Je to jako porovnavat schopnosti auta podle toho jakou ma klilku na dverich.
Spis by me zajimalo jestli ma cpp veci ktery by naplnily Java EE standart. Ma slusny ORM? Ma injectovani? Ma neco jako JTA?
Pokud ano verim ze je v bussinesu pouzitelny.
Jinak ze navrhnout apku dokaze kazdej... Kolik jsi navrhoval vetsich veci? Prave rozsiritelnost je dana navrhem na zacatku.
-
Vychvalovači Garbage Collectoru zapomínají, že operační paměť není jediný typ systémového prostředku.
Tesat.
-
Vychvalovači Garbage Collectoru zapomínají, že operační paměť není jediný typ systémového prostředku.
Prave, proto nechapu proc je zde zminovane RAII a GC, to spolu moc nesouvisi. Jak uz jste sam napsal GC je jen pomucka pro spravu pameti. Neni problem pouzivat GC a RAII zaroven. Samozrejme je potreba pouzivat jazyk, ktery to umoznuje.
-
V Javě s JDBC by stejný dotaz vypadal asi takto, s použitím try ... finally pro bezpečné zavření spojení:
Connection c = DriverManager.getConnection(db,jmeno,heslo);
try {
PreparedStatement ps = c.prepareStatement("select jmeno,prijmeni from tabulka where rodnecislo=?");
ps.setString(1, rodne_cislo);
ResultSet rs = c.createStatement().executeQuery("select jmeno,prijmeni from tabulka where rodnecislo=?");
if (rs.next())
{
jmeno = rs.getString(1);
prijmeni = rs.getString(2);
}
} finally {
c.close();
}
Nebo nějak takto:
try (Connection c = DriverManager.getConnection(db,jmeno,heslo)) {
try (PreparedStatement ps = c.prepareStatement("select jmeno,prijmeni from tabulka where rodnecislo=?")) {
ps.setString(1, rodne_cislo);
ResultSet rs = ps.executeQuery();
if (rs.next()) {
jmeno = rs.getString(1);
prijmeni = rs.getString(2);
}
}
}
-
Nejde o SQL, ale obecně o desktruktory v C++ a RAII. Java má sice finalizer, ale ten je v praxi na nic. A tak se v Javě používají obyčejné metody pro vytváření a rušení prostředků, tak jak se v používaly obyčejné funkce v C před vynálezem C++.
Sice to není úplné RAII, ale při použití rozhraní Autocloseable v Javě zrovna u toho SQL dosáhneš podobného výsledku. A předřečník má pravdu v tom, že zrovna JDBC by se asi nemělo používat tak, že si v jedné metodě otevřeš připojení do databáze, vytvoříš statement, získáš výsledky a potom to všechno zase uzavřeš (i když tady v jednom nejmenovaném seriálu se to používá..:-/)
-
Navrhnout aplikaci žádné umění není. Největší průser je právě to rozšiřování, což programátor neovlivní, stejně jako rozporuplné zadání. Tady má výhodu menší firma nebo živnostník, protože toho nikdo nenutí na nesmylné požadavky kývnout. Pokud se nejde se zákazníkem dohodnout, tak ať jde jinam. Průser větších firem je v tom, že nesmyslné zadání častěji z hlavy "analytika" nebo "architekta" než z hlavy zákazníka. Analytik totiž skutečnou analýzu neprovádí, jen zapisuje průběh schůzky se zákazníkem, nemá ponětí, co se honí v hlavě zákazníka a po skončení schůzky končí práce analytika. Skutečná analýzaje zůstane na programátorovi a to bez kontaktu se zákazníkem. Poslední slovo má "analytik" (většinou vedoucí vývoje nebo projektový manager), který je přesvědčen, že zákazníka pochopil.
Pekne napisane. Ja len doplnim, ze na to vsetko su potrebne skusenosti. Bez toho clovek nema sancu to dobre navrhnut. Niekdedy ani to nepomoze a len sa to lepi aby to nejako fungovalo a casom uz ked to nebude udrzatelne(uz ani vykonny HW nepomaha), tak sa to mozno postavi odznova. Vo velkych firmach sa to velmi casto len lepi bez vecsej snahy to robit dobre.
Casto z jednej a ani druhej strany(zakaznik/dodavatel) sa nemysli na cloveka, ktory bude vysledny projekt pouzivat. Vysledkom toho je, ze program robi to, co ma ale uzivatelska privetivost je mizerna.
-
Sice to není úplné RAII, ale při použití rozhraní Autocloseable v Javě zrovna u toho SQL dosáhneš podobného výsledku.
Přiznám se, že o tomto jsem nevěděl. Většina projektů v naší firmě zamrzla na JDK 1.6. Taky je dobrý switch se stringy.
-
Sice to není úplné RAII, ale při použití rozhraní Autocloseable v Javě zrovna u toho SQL dosáhneš podobného výsledku.
Přiznám se, že o tomto jsem nevěděl. Většina projektů v naší firmě zamrzla na JDK 1.6. Taky je dobrý switch se stringy.
To je škoda, protože Java se docela vyvíjí (i když já osobně za nejlepší na Javě považuju JVM, ne ten jazyk :-). Na druhou stranu znám projekty, které z různých důvodů používají pořád 1.4.2 (a pořád se na nich něco upravuje).
-
Sice to není úplné RAII, ale při použití rozhraní Autocloseable v Javě zrovna u toho SQL dosáhneš podobného výsledku.
Přiznám se, že o tomto jsem nevěděl. Většina projektů v naší firmě zamrzla na JDK 1.6. Taky je dobrý switch se stringy.
Jinak když se podíváš na docku (http://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html), tak ve std. knihovně se to používá kdekoli je možné. A samozřejmě to nebrání využití ve vlastních třídách, dokonce se ani nemusí jednat o žádné skutečné "resources", ale cokoli, kde je zapotřebí mít přesně specifikovaný okamžik volání metody pro uvolnění prostředku.
-
Sice to není úplné RAII, ale při použití rozhraní Autocloseable v Javě zrovna u toho SQL dosáhneš podobného výsledku.
Přiznám se, že o tomto jsem nevěděl. Většina projektů v naší firmě zamrzla na JDK 1.6. Taky je dobrý switch se stringy.
To je škoda, protože Java se docela vyvíjí (i když já osobně za nejlepší na Javě považuju JVM, ne ten jazyk :-). Na druhou stranu znám projekty, které z různých důvodů používají pořád 1.4.2 (a pořád se na nich něco upravuje).
Tak ono to je něco jako using v C#. Na správu všeho kromě paměti by to mělo být povinné (v code guidelines).
-
Tak ono to je něco jako using v C#. Na správu všeho kromě paměti by to mělo být povinné (v code guidelines).
Otazka je, proc rozlisovat mezi spravou pameti a libovolneho jineho prostredku. Podle me GC akorat u patlalu vytvari dojem, ze se o spravu zdroju neni treba starat.
-
Podle me GC akorat u patlalu vytvari dojem, ze se o spravu zdroju neni treba starat.
Podle mne absence GC v C++ vytváří u profesionálů dojem, že o správu zdrojů je nutné se starat.
-
Otazka je, proc rozlisovat mezi spravou pameti a libovolneho jineho prostredku. Podle me GC akorat u patlalu vytvari dojem, ze se o spravu zdroju neni treba starat.
Protože paměť používáš (vytváříš nové objekty) typicky řádově častěji, než otevíráš/zavíráš jakékoli jiné prostředky. A také je mnohem častěji předáváš mezi scope.
Já se tedy mnohem raději věnuji podstatě problému, než řeším technikálie okolo prostředků, které si počítač (VM) může dostatečně dobře ošetřit i sám.
-
Tak ono to je něco jako using v C#. Na správu všeho kromě paměti by to mělo být povinné (v code guidelines).
Otazka je, proc rozlisovat mezi spravou pameti a libovolneho jineho prostredku. Podle me GC akorat u patlalu vytvari dojem, ze se o spravu zdroju neni treba starat.
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 :)
-
Otazka je, proc rozlisovat mezi spravou pameti a libovolneho jineho prostredku. Podle me GC akorat u patlalu vytvari dojem, ze se o spravu zdroju neni treba starat.
Protože paměť používáš (vytváříš nové objekty) typicky řádově častěji, než otevíráš/zavíráš jakékoli jiné prostředky. A také je mnohem častěji předáváš mezi scope.
Já se tedy mnohem raději věnuji podstatě problému, než řeším technikálie okolo prostředků, které si počítač (VM) může dostatečně dobře ošetřit i sám.
Otázka je, co znamená "dostatečně dobře". Pro každou konkrétní aplikaci asi něco trochu jiného.
-
Jinak když se podíváš na docku (http://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html), tak ve std. knihovně se to používá kdekoli je možné. A samozřejmě to nebrání využití ve vlastních třídách, dokonce se ani nemusí jednat o žádné skutečné "resources", ale cokoli, kde je zapotřebí mít přesně specifikovaný okamžik volání metody pro uvolnění prostředku.
Škoda, že to Oracle udělal nekompatibilní s Javou 7, takže třeba na Androidu to půjde použít až tak za pět let. Na druhou stranu existuje Project Lombok (https://projectlombok.org/features/Cleanup.html).
-
Protože paměť používáš (vytváříš nové objekty) typicky řádově častěji, než otevíráš/zavíráš jakékoli jiné prostředky. A také je mnohem častěji předáváš mezi scope.
Já se tedy mnohem raději věnuji podstatě problému, než řeším technikálie okolo prostředků, které si počítač (VM) může dostatečně dobře ošetřit i sám.
Jo, od toho jsou v C++ genericky RAII wrappery jako shared_ptr. Nema cenu se tady nejak extra dohadovat, ja proste nemam Javu rad, a to neni nic moc racionalniho :-) (i kdyz par relevantnich argumentu bych asi z klobouku vytahl).
-
Kde v předchozím příspěvku tvrdím, že jsem odborník ? Ani pořádně neovládám virtuální desktruktory při vícenásobné dědičnosti nebo novinky v C++14.
To som reagoval na toto:
(sry nemal som cas moc)
Mně zase fascinuje to kvantum odborníků, kteří vědí, že C++ je lowlevel
Nikde som nepisal, ze to je low level, ale ze ked ta zaujimaju take veci, tak je to dobre vediet (cize opacne). Pre mna je dobre vediet c++ na takej urovni, aby som si mohol precitat zdrojaky napr v8, ale ked idem robit nejaku formularovu web aplikaciu, tak o c++ neuvazujem. C++ je celkom univerzalne, ale ma svoje muchy a stale plati, ze cas su peniaze. Mimochodom preco si mozilla navrhla vlastny jazyk, ked c++ je take uzastne? Este aj google zvolil taky postup.
Jo, od toho jsou v C++ genericky RAII wrappery jako shared_ptr. Nema cenu se tady nejak extra dohadovat, ja proste nemam Javu rad, a to neni nic moc racionalniho :-) (i kdyz par relevantnich argumentu bych asi z klobouku vytahl).
Ja mam napr velmi rad to co dokaze jvm, ale ze by som mal rad co to znamena v praxi (napr pamatova nenazranost) to sa neda povedat :).
-
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.
-
Protože paměť používáš (vytváříš nové objekty) typicky řádově častěji, než otevíráš/zavíráš jakékoli jiné prostředky. A také je mnohem častěji předáváš mezi scope.
Já se tedy mnohem raději věnuji podstatě problému, než řeším technikálie okolo prostředků, které si počítač (VM) může dostatečně dobře ošetřit i sám.
Jo, od toho jsou v C++ genericky RAII wrappery jako shared_ptr. Nema cenu se tady nejak extra dohadovat, ja proste nemam Javu rad, a to neni nic moc racionalniho :-) (i kdyz par relevantnich argumentu bych asi z klobouku vytahl).
Tak RAII je asi nejlepší způsob správy zdrojů (případně defer, což je to samé v bledě modrém třeba v Go). Navíc plně transparentní. Na druhou stranu chápu lopaty zastávající se GC. Jedem das Seine :)
-
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.
Naopak, byli myšlení patlalové z citovaného příspěvku.
-
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á.
-
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 :D 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 :D.
-
pani, co bolo hlavnou myslienkou mojej otazky? casto sa tu debaty zvrhnu inym smerom. ach
-
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 ;-)
-
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 :D 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 :D.
Právě ten výkon bývá problém.
-
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 :D 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 :D.
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.
-
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ý
-
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 :D 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 :D.
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.)
-
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...
-
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.
-
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
-
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
-
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
-
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 (http://scala-lang.org/) (umožňuje OOP i FP; můžeš si zkusit pohrát např. s aktory z Akka) a kurzy zdarma na Coursera (https://www.coursera.org/course/progfun). Z jiných jazyků nad JVM mě zaujal ještě skoro neznámý Frege (https://github.com/Frege/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).
-
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.
-
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ě.
-
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).
-
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).
-
.....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>
-
<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.
-
<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 (http://www.scala-lang.org/old/node/1658). Vse, co jsem napsal, sedi k clanku na wiki - Elixir (https://en.wikipedia.org/wiki/Elixir_%28programming_language%29) a Erlang (https://en.wikipedia.org/wiki/Erlang_%28programming_language%29).
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 ;).
-
https://www.quora.com/Is-LinkedIn-getting-rid-of-Scala
-
https://www.quora.com/Is-Twitter-getting-rid-of-Scala
-
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" ;D. 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.
-
..... z mala zkusenosti.....
Tak kdyz necemu nerozumim, nebo nemam zdroj tak o tom nemuzu diskutovat prece
-
..... 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?
-
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" ;D. 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.
-
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" ;D. 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.
-
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í.
-
..... 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 (https://bjpelc.wordpress.com/2015/01/10/yet-another-language-speed-test-counting-primes-c-c-java-javascript-php-python-and-ruby-2/) (ta pomalost Javy pro mensi narocnost je dana tim, ze se meril i start JVM, coz je IMO spatne).
-
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í.
Naopak, lambdy činí kód elegantnějším a čitelnějším. BTW goto není špatné, jen není pro patlaly.
-
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í.
Naopak, lambdy činí kód elegantnějším a čitelnějším. BTW goto není špatné, jen není pro patlaly.
naopak lamdy činí kód patlalů čitelnější :-) Jak poznáte kód patlala, když potřebujete udělat změnu, na mnoha místech musíte měnit totéž, nebo téměř totéž a nelze to vyhledat automatizovaně. A právě k tomu vedou lambdy, jsou stejně pohodlné jako goto, proto vedou na prasárny, protože nemusíte přemýšlet, když je používáte.
-
..... 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 (https://bjpelc.wordpress.com/2015/01/10/yet-another-language-speed-test-counting-primes-c-c-java-javascript-php-python-and-ruby-2/) (ta pomalost Javy pro mensi narocnost je dana tim, ze se meril i start JVM, coz je IMO spatne).
Tak spatlanina je i Swift, mnohem větší než C++ :)
-
Jinak trochu odbočení, budoucí programovací jazyky strojů budou docela zajímavé v tom, že například vystačí s jedním datovým typem - integer, případně float a nebudou používat znakové identifikátory proměnných.
-
..... 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 (https://bjpelc.wordpress.com/2015/01/10/yet-another-language-speed-test-counting-primes-c-c-java-javascript-php-python-and-ruby-2/) (ta pomalost Javy pro mensi narocnost je dana tim, ze se meril i start JVM, coz je IMO spatne).
Já se bavil o kvalitě překladače, ne knihoven, těch jsou v každém jazyce 3 p....e různé kvality. Abych to tedy upřesnil, opakuji, že kód napsaný v C++/Swiftu/Go nevyužívající optimalizovaných knihoven je řádově rychlejší než v Javě. To mám podložené kódem provádějícím složité matematické operace nad objekty, pro než neexistují knihovny (možná tak v R). A bavíme se o kódu v daném jazyce, ne v ASM. JIT je opravdu obdivuhodně rychlý, ale má své inherentní hranice.
Jinak mluvit v souvislosti s C++ o nízkoúrovňové správě paměti je záležitost 90. let a nezaslouží si dalšího komentáře. K tématu náročnosti Javy na paměť doporučuju akademické články od lidí z Googlu, jejichž závěr je, že výkon Javy je řádově (sic!) srovnatelný s nativními jazyky, pokud má k dispozici 4x více paměti, jinak rapidně klesá. Což plyne ze způsobu práce GC. Teď už nechám obhajobu C++ na jiných (někteří zdejší přispěvatelé C++ znají poměrně dobře), v diskuzi budu rád pokračovat nad konkrétním kódem.
-
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í.
Naopak, lambdy činí kód elegantnějším a čitelnějším. BTW goto není špatné, jen není pro patlaly.
naopak lamdy činí kód patlalů čitelnější :-) Jak poznáte kód patlala, když potřebujete udělat změnu, na mnoha místech musíte měnit totéž, nebo téměř totéž a nelze to vyhledat automatizovaně. A právě k tomu vedou lambdy, jsou stejně pohodlné jako goto, proto vedou na prasárny, protože nemusíte přemýšlet, když je používáte.
Zajímavý názor. Asi to chce konkrétní kód. Evidentně mluvíme každý o něčem jiném.
-
Já tedy programuju v C++ a nemám pocit, že bych něco dělal dlouho jen proto, že si někdo myslí, že v C++ se to musí programovat dlouho a je to složité. Taky si nepíšu nic v ASM, proč bych to dělal? Používám C++ spíš jako ... Javu. Používám vektory, mapy, stringy, streamy, iterátory atd, pokud už něco někde alokuju, tak na to používám chytré ukazatele, počítání referencí - já vím, že má problémy s cykly a není tedy plnhodnotnou náhradou GC, ale ... 95% problémů to nemusím řešit a GC je vlastně takový kanón na vrabce. Tam kde to musím řešit, tam se vždycky najde nějaké jiné řešení, třeba pomocí jednoduchého GC který řeší konkrétní případ (registrace a odregistrace uzlů do kontejneru stojícího mimo dynamickou strukturu, atd)
Když srovnám Javu a C++ z hlediska pohodlnosti vývoje, tak
- 80% kódu v Javě se dá zapsat stejně v C++ a jeho vývoj bude trvat stejně dlouho
- Java zvládá dobře správu paměti která způsobuje, že nad spoustou věcí nemusím přemýšlel, třeba právě u nějakých hodně propojených struktur, kde hrozí cykly
- naopak C++ má RAII, který mi umožňuje nemyslet na uvolňování jiných resourců (síťová spojení, např., ale třeba různé věci okolo zámků a podobně. Dále samozřejmě různé buildery, které v destruktoru provedou vlastní sestavení výsledku a předání patřičnému příjemci
- V C++ je výhodou generika, v Javě je to spíš hack a výsměnch
- Java pro změnu má obrovské množství knihoven na všechno. Nemusím tak vymýšlet algoritmy, které již někdo vymyslel. Nevýhodou je, že ne všechny ty algoritmy jsou implementovány chytře a vyhovují mým potřebam. V C++ jsem si většinu knihovní báze musel napsat sám
- V C++ lépe řeší různé binární formáty
- V C++ zvládá lépe dědičnost, vícenásobnou dědičnost, virtuální dědičnost - jo, taky to často potřebuju. Java naopak je pochopitelnější pro méně zdatné jedince, protože tohle nemá
- C++ má větší možnosti v definování vlastních operátorů, což otevírá možnosti k většímu přizpůsobení jazyka a přehlednějšímu kódu, přímočařejším zápisům, což ale u méně zdatných jedinců vede k prasení kódu a je kontraproduktivní. Java nic takového nemá, proto prasení kódu redukuje
Tento výčet popisoval zbývajících 20% rozdílů. Pokud někdo programuje rychleji v Javě, než v C++, bude to tím, že se naučil Javu a nenaučil se C++. U mě je to například obráceně.
-
Já tedy programuju v C++ a nemám pocit, že bych něco dělal dlouho jen proto, že si někdo myslí, že v C++ se to musí programovat dlouho a je to složité. Taky si nepíšu nic v ASM, proč bych to dělal? Používám C++ spíš jako ... Javu. Používám vektory, mapy, stringy, streamy, iterátory atd, pokud už něco někde alokuju, tak na to používám chytré ukazatele, počítání referencí - já vím, že má problémy s cykly a není tedy plnhodnotnou náhradou GC, ale ... 95% problémů to nemusím řešit a GC je vlastně takový kanón na vrabce. Tam kde to musím řešit, tam se vždycky najde nějaké jiné řešení, třeba pomocí jednoduchého GC který řeší konkrétní případ (registrace a odregistrace uzlů do kontejneru stojícího mimo dynamickou strukturu, atd)
Když srovnám Javu a C++ z hlediska pohodlnosti vývoje, tak
- 80% kódu v Javě se dá zapsat stejně v C++ a jeho vývoj bude trvat stejně dlouho
- Java zvládá dobře správu paměti která způsobuje, že nad spoustou věcí nemusím přemýšlel, třeba právě u nějakých hodně propojených struktur, kde hrozí cykly
- naopak C++ má RAII, který mi umožňuje nemyslet na uvolňování jiných resourců (síťová spojení, např., ale třeba různé věci okolo zámků a podobně. Dále samozřejmě různé buildery, které v destruktoru provedou vlastní sestavení výsledku a předání patřičnému příjemci
- V C++ je výhodou generika, v Javě je to spíš hack a výsměnch
- Java pro změnu má obrovské množství knihoven na všechno. Nemusím tak vymýšlet algoritmy, které již někdo vymyslel. Nevýhodou je, že ne všechny ty algoritmy jsou implementovány chytře a vyhovují mým potřebam. V C++ jsem si většinu knihovní báze musel napsat sám
- V C++ lépe řeší různé binární formáty
- V C++ zvládá lépe dědičnost, vícenásobnou dědičnost, virtuální dědičnost - jo, taky to často potřebuju. Java naopak je pochopitelnější pro méně zdatné jedince, protože tohle nemá
- C++ má větší možnosti v definování vlastních operátorů, což otevírá možnosti k většímu přizpůsobení jazyka a přehlednějšímu kódu, přímočařejším zápisům, což ale u méně zdatných jedinců vede k prasení kódu a je kontraproduktivní. Java nic takového nemá, proto prasení kódu redukuje
Tento výčet popisoval zbývajících 20% rozdílů. Pokud někdo programuje rychleji v Javě, než v C++, bude to tím, že se naučil Javu a nenaučil se C++. U mě je to například obráceně.
Přesně tohle většina lidí není schopna pochopit...
-
Takže chlape, ty umíš C# a zajímáš se o C++?? Potřebuješ ho ale vůbec? Děláš a nebo chceš dělat na hře, či nějakým low level runtimu pro bůhví co a jde ti o maximální rychlost? Pak jo, di do C++. Chceš se někam posunout? Jo? Tak proč se chceš ty tydýte učit jazyk využívající paradigma který již znáš (a nebo si to aspoň myslíš). Jdi do Haskellu a nauč se FP, pokud se chceš dál vyvinout. A nebo smalltalk pokud chceš pochopit OOP ...
-
Jinak trochu odbočení, budoucí programovací jazyky strojů budou docela zajímavé v tom, že například vystačí s jedním datovým typem - integer, případně float a nebudou používat znakové identifikátory proměnných.
To všechno už tu dávno bylo, jeden datový typ má zapomenutý BCPL, a zásobník (třeba ve Forthu) nepotřebuje žádný identifikátor. Jsi s tou budoucností pěkných pár desítek let pozadu 8)
-
Jak uz tu napsali jini, asi to nema moc smysl, ucit se C++. C++ je na ustupu, vyjma specialnich aplikaci (hry, HW, ruzne algoritmicke knihovny), a dnes jsou ve vetsine prumyslu uz pouzivane jine jazyky.
Takze kvuli praci/kariere to ma smysl snad jedine pokud se chcete specializovat na C++ a ocekavate, ze vas bude bavit sprava vetsinou legacy systemu napsanych v C++. Platove to muze byt zajimave snad leda pokud budete opravdu odbornik (pripadne si k tomu pridate nejakou dalsi znalost - treba HW, programovani her, specificke algoritmy). I kdyz k tomu .NET by se to dalo uvazovat jako kombinace, urcite existuje spousta legacy veci pro Windows napsanych v C++. Ale ja bych do toho nesel pokud bych nepracoval u zamestnavatele, ktery uz C++ v nejake forme pouziva.
Co se tyce "osobniho rozvoje", doporucuji zkusit si spis radikalni jazyky spis nez jazyky navrzene pro prumyslove pouziti - jak tu jini uz psali, treba Haskell, nejaky Lisp (Clojure?), Smalltalk.
-
- V C++ je výhodou generika, v Javě je to spíš hack a výsměnch
- V C++ lépe řeší různé binární formáty
Tohle jsou přesně důvody, proč použít C++. Jsou to specifické situace, kde se pracuje se strukturou nepocházející z Javy a tam jsou potřeba chybějící neznaménkové typy, struktury a někdy i skutečné šablony (při blbém návrhu těch struktur, třeba když existují dvě podobné struktury s jiným pořadím položek). V jednom takovém případě jsem měl implementaci v C++ mnohonásobně výkonnější a přitom pracnost byla nižší. C# je na tom s "interoperabilitou" o něco lépe, protože umí "klasické" struktury i neznaménkové typy.
-
Já tedy programuju v C++ a nemám pocit, že bych něco dělal dlouho jen proto, že si někdo myslí, že v C++ se to musí programovat dlouho a je to složité.
<pošťuchování>Sekretářka co sčítá čísla z buňek v Excelu na kalkulačce, protože jí nikdo neupozornil, že to Excel umí sám, taky nemá pocit, že něco dělá zbytečně dlouho :D Stejně tak C++ programátor co právě strávil dva dny hledáním ošklivé paměťové chyby v programu taky bude tvrdit, že je nesmysl, že v C++ se programuje pomalu ;)</pošťuchování>
No a teď vážně:
V tom tvém výčtu dost postrádám vlastnost Javy, kterou osobně pokládám za killer feature: Anotace. Pokud vím, nic podobného C++ (a asi žádný jiný jazyk?) nemá a přitom je to naprosto geniální věc.
Pak jsou tu aspecty. Skvělá věc, i když, ve špatných rukou, řekl bych, až smrtelně nebezpečná :)
A reflexe. Člověk ji použije jednou / dvakrát za rok max (pokud víckrát, je prase), ale když, tak vytrhne trn z paty. Ta se v C++ dá do určité míry nahradit přes templaty, ale jen do určité míry. A naopak, co v Javě neumí generika se dá částečně obejít reflexí.
Naopak, s generiky žádný velký problém nemám (a za hack považuju spíš C++ generika, ale to je spíš filozofická otázka). Respektive jediný vážnější/nepříjemný problém, na který jsem za svoji praxi narazil je, že nejde napsat T.class.
Podobně vícenásobná dědičnost. Naprosto mi dostačuje možnost implementovat víc interfaces - ani se nepamatuji, kdy naposled mi to nestačilo. A přinejhorším se to dá obejít přes skládání.
Co mě naopak na Javě štve a uvedené není je neexistence výstupních proměnných.
-
a keby som sa chcel posunut dalej vo vyvoji napr. v .NET/C#, co by ste odporucali? Alebo vseobecne v software development. To C++ je mozno trosku fakt z cesty sa ucit, chcel som len ze na svoj osobny rozvoj, ale nema to zmysel. radsej nieco ine.
btw. uvazujem nad kupou knizky z nejakych tychto:
http://www.amazon.com/gp/product/0735667454/ref=s9_simh_hd_bw_p14_d0_i2?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=merchandised-search-11&pf_rd_r=0WKK52JFVGPGZKSQYP19&pf_rd_t=101&pf_rd_p=5d93ad61-3c6e-574d-b199-b95bffe7d849&pf_rd_i=4011
http://www.amazon.com/Writing-High-Performance-NET-Code-Watson/dp/0990583430/ref=sr_1_46?s=books&ie=UTF8&qid=1451342246&sr=1-46
http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_sim_14_6?ie=UTF8&dpID=515iO%2B-PRUL&dpSrc=sims&preST=_AC_UL160_SR131%2C160_&refRID=0A3HQWJGWQ2BXN1TJTC2
-
a keby som sa chcel posunut dalej vo vyvoji napr. v .NET/C#, co by ste odporucali? Alebo vseobecne v software development. T
F#, je to dostatečně jiné, ale furt .net, takže pro vás přímo použitelné
-
a keby som sa chcel posunut dalej vo vyvoji napr. v .NET/C#, co by ste odporucali? Alebo vseobecne v software development. To C++ je mozno trosku fakt z cesty sa ucit, chcel som len ze na svoj osobny rozvoj, ale nema to zmysel. radsej nieco ine.
btw. uvazujem nad kupou knizky z nejakych tychto:
http://www.amazon.com/gp/product/0735667454/ref=s9_simh_hd_bw_p14_d0_i2?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=merchandised-search-11&pf_rd_r=0WKK52JFVGPGZKSQYP19&pf_rd_t=101&pf_rd_p=5d93ad61-3c6e-574d-b199-b95bffe7d849&pf_rd_i=4011
http://www.amazon.com/Writing-High-Performance-NET-Code-Watson/dp/0990583430/ref=sr_1_46?s=books&ie=UTF8&qid=1451342246&sr=1-46
http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_sim_14_6?ie=UTF8&dpID=515iO%2B-PRUL&dpSrc=sims&preST=_AC_UL160_SR131%2C160_&refRID=0A3HQWJGWQ2BXN1TJTC2
C++/CLI, to je .NET a občas se hodí. Případně C++/CX, to přímo komunikuje s .NET přes metadata. Jinak existuje také Swift pro .NET (lepší je ten pro Linux, ale kdyz není zbytí...).
-
Já tedy programuju v C++ a nemám pocit, že bych něco dělal dlouho jen proto, že si někdo myslí, že v C++ se to musí programovat dlouho a je to složité.
<pošťuchování>Sekretářka co sčítá čísla z buňek v Excelu na kalkulačce, protože jí nikdo neupozornil, že to Excel umí sám, taky nemá pocit, že něco dělá zbytečně dlouho :D Stejně tak C++ programátor co právě strávil dva dny hledáním ošklivé paměťové chyby v programu taky bude tvrdit, že je nesmysl, že v C++ se programuje pomalu ;)</pošťuchování>
No a teď vážně:
V tom tvém výčtu dost postrádám vlastnost Javy, kterou osobně pokládám za killer feature: Anotace. Pokud vím, nic podobného C++ (a asi žádný jiný jazyk?) nemá a přitom je to naprosto geniální věc.
Pak jsou tu aspecty. Skvělá věc, i když, ve špatných rukou, řekl bych, až smrtelně nebezpečná :)
A reflexe. Člověk ji použije jednou / dvakrát za rok max (pokud víckrát, je prase), ale když, tak vytrhne trn z paty. Ta se v C++ dá do určité míry nahradit přes templaty, ale jen do určité míry. A naopak, co v Javě neumí generika se dá částečně obejít reflexí.
Naopak, s generiky žádný velký problém nemám (a za hack považuju spíš C++ generika, ale to je spíš filozofická otázka). Respektive jediný vážnější/nepříjemný problém, na který jsem za svoji praxi narazil je, že nejde napsat T.class.
Podobně vícenásobná dědičnost. Naprosto mi dostačuje možnost implementovat víc interfaces - ani se nepamatuji, kdy naposled mi to nestačilo. A přinejhorším se to dá obejít přes skládání.
Co mě naopak na Javě štve a uvedené není je neexistence výstupních proměnných.
V moderním C++ se paměťová chyba vyrábí dost těžko.
-
Co mě naopak na Javě štve a uvedené není je neexistence výstupních proměnných.
Výstupní proměnné považují za velké zlo, které mi v Javě vůbec nechybí a v PHP je nepoužívám. Na to je určen return. Také ti nic nebrání použít jako parametr metody objekt, který poslouží stejně dobře jako reference v C++. V tom případě by ta metoda měla být void.
Ostatně pokud máme k dispozici objekty, je dobré je používat.
-
Výstupní proměnné považují za velké zlo, které mi v Javě vůbec nechybí a v PHP je nepoužívám. Na to je určen return. Také ti nic nebrání použít jako parametr metody objekt, který poslouží stejně dobře jako reference v C++.
V čem je to zlo? Třeba mám metodu a potřebuju z ní dostat třeba dva inty, počet a součet. Return, pokud jsi to ještě nezjistil, umí vrátit pouze jednu hodnotu / objekt. Takže buď na ně musím vytvořit extra třídu (opruz, naprosto zbytečné řádky v kódu a bajty v permgenu).
Nebo někteří experti nadefinují metodu s parametrem typu int[] a předpokládají, že to bude pole o dvou položkách. Strašná prasečina.
Udělat metodu
void zpracuj(int[] vstup, int &pocet, int &soucet);
by bylo naprosto nejelegantnější a nejjednodušší řešení, kdyby to šlo :(
-
Jinak trochu odbočení, budoucí programovací jazyky strojů budou docela zajímavé v tom, že například vystačí s jedním datovým typem - integer, případně float a nebudou používat znakové identifikátory proměnných.
To všechno už tu dávno bylo, jeden datový typ má zapomenutý BCPL, a zásobník (třeba ve Forthu) nepotřebuje žádný identifikátor. Jsi s tou budoucností pěkných pár desítek let pozadu 8)
Ano samozřejmě, ale program nebude generovat člověk, ale stroj, to bude to nové. Programy se nebudou upravovat, stroj je vygeneruje znovu podle změněných parametrů, paramery určí rovněž stroj :-) Jinak to bylo zamyšlení nad tím, jaké jazyky budou k programování používat stroje místo lidí. Vzhledem k tomu, že zpočátku nebudou pracovat s mentálním modelem problému, ale k nalezení programu využívat nějakých evolučních algoritmů, nebudou potřebovat většinu vlastností programovacího jazyka, které využije člověk. Zřejmě dojde i k úpravě instrukčního souboru procesorů, nebo architektury , aby více podporoval evoluční algoritmy.
-
Výstupní proměnné považují za velké zlo, které mi v Javě vůbec nechybí a v PHP je nepoužívám. Na to je určen return. Také ti nic nebrání použít jako parametr metody objekt, který poslouží stejně dobře jako reference v C++.
V čem je to zlo? Třeba mám metodu a potřebuju z ní dostat třeba dva inty, počet a součet. Return, pokud jsi to ještě nezjistil, umí vrátit pouze jednu hodnotu / objekt. Takže buď na ně musím vytvořit extra třídu (opruz, naprosto zbytečné řádky v kódu a bajty v permgenu).
Nebo někteří experti nadefinují metodu s parametrem typu int[] a předpokládají, že to bude pole o dvou položkách. Strašná prasečina.
Udělat metodu
void zpracuj(int[] vstup, int &pocet, int &soucet);
by bylo naprosto nejelegantnější a nejjednodušší řešení, kdyby to šlo :(
Zlo je v tom, že se obchází špatný návrh jazyka. Prostě tam chybí tuple a rozumný způsob jeho rozbalení při přiřazení výstupu z funkce. Tento mechanismus je známý už spoustu let a to, že to nikdo neuměl při návrhu Javy, není omluva. Co navrhuješ, není elegantní, je to jenom jednoduché - a při znalosti současného stavu vývoje programovacích jazyků - prostě hloupé. Bez urážky.
-
Já tedy programuju v C++ a nemám pocit, že bych něco dělal dlouho jen proto, že si někdo myslí, že v C++ se to musí programovat dlouho a je to složité.
<pošťuchování>Sekretářka co sčítá čísla z buňek v Excelu na kalkulačce, protože jí nikdo neupozornil, že to Excel umí sám, taky nemá pocit, že něco dělá zbytečně dlouho :D Stejně tak C++ programátor co právě strávil dva dny hledáním ošklivé paměťové chyby v programu taky bude tvrdit, že je nesmysl, že v C++ se programuje pomalu ;)</pošťuchování>
No jenze mu nekdo tu Javu ukazal a ocekavam ze ji zna(umi scitat v Excelu).
No a teď vážně:
V tom tvém výčtu dost postrádám vlastnost Javy, kterou osobně pokládám za killer feature: Anotace. Pokud vím, nic podobného C++ (a asi žádný jiný jazyk?) nemá a přitom je to naprosto geniální věc.
Tak anotace ma pokud vim i C#, PHP (sice trochu zvlastne ale da se to nazvat anotacemi) i treba jazyk D
-
Zlo je v tom, že se obchází špatný návrh jazyka. Prostě tam chybí tuple a rozumný způsob jeho rozbalení při přiřazení výstupu z funkce. Tento mechanismus je známý už spoustu let a to, že to nikdo neuměl při návrhu Javy, není omluva. Co navrhuješ, není elegantní, je to jenom jednoduché - a při znalosti současného stavu vývoje programovacích jazyků - prostě hloupé. Bez urážky.
Presne tak, tuple je jedine spravne reseni).
-
Výstupní proměnné považují za velké zlo, které mi v Javě vůbec nechybí a v PHP je nepoužívám. Na to je určen return. Také ti nic nebrání použít jako parametr metody objekt, který poslouží stejně dobře jako reference v C++.
V čem je to zlo? Třeba mám metodu a potřebuju z ní dostat třeba dva inty, počet a součet. Return, pokud jsi to ještě nezjistil, umí vrátit pouze jednu hodnotu / objekt. Takže buď na ně musím vytvořit extra třídu (opruz, naprosto zbytečné řádky v kódu a bajty v permgenu).
Obvykle se k tomu použijí dva gettery (i když je, jak známo, sám nepoužívám) nebo použiješ jeden messenger. Také můžeš požadovanou operaci udělat uvnitř objektu a žádné dvě hodnoty ven nebudeš muset vytahovat.
Nebo někteří experti nadefinují metodu s parametrem typu int[] a předpokládají, že to bude pole o dvou položkách. Strašná prasečina.
Pokud je výsledkem vektor [x, y], tak to prasečina být nemusí. Prasečinou je požadovat po jedné metodě výstup dvou nesouvisejících hodnot.
Udělat metodu
void zpracuj(int[] vstup, int &pocet, int &soucet);
by bylo naprosto nejelegantnější a nejjednodušší řešení, kdyby to šlo :(
Tak tohle je prasečina. Je to převzato z C/C++, kde to jinak nejde. Uvědom si, že to jsou procedurální jazyky, zatímco Java a C# jsou objektové. Jsou to různá paradigmata.
Velmi snadno to však můžeš udělat i v Javě. Stačí místo int použít Integer.
-
Výstupní proměnné považují za velké zlo, které mi v Javě vůbec nechybí a v PHP je nepoužívám. Na to je určen return. Také ti nic nebrání použít jako parametr metody objekt, který poslouží stejně dobře jako reference v C++.
V čem je to zlo? Třeba mám metodu a potřebuju z ní dostat třeba dva inty, počet a součet. Return, pokud jsi to ještě nezjistil, umí vrátit pouze jednu hodnotu / objekt. Takže buď na ně musím vytvořit extra třídu (opruz, naprosto zbytečné řádky v kódu a bajty v permgenu).
Nebo někteří experti nadefinují metodu s parametrem typu int[] a předpokládají, že to bude pole o dvou položkách. Strašná prasečina.
Udělat metodu
void zpracuj(int[] vstup, int &pocet, int &soucet);
by bylo naprosto nejelegantnější a nejjednodušší řešení, kdyby to šlo :(
Rozumné jazyky (včetně C++ od verze C++11) mají tuples.
-
No a teď vážně:
V tom tvém výčtu dost postrádám vlastnost Javy, kterou osobně pokládám za killer feature: Anotace. Pokud vím, nic podobného C++ (a asi žádný jiný jazyk?) nemá a přitom je to naprosto geniální věc.
Pak jsou tu aspecty. Skvělá věc, i když, ve špatných rukou, řekl bych, až smrtelně nebezpečná :)
A reflexe. Člověk ji použije jednou / dvakrát za rok max (pokud víckrát, je prase), ale když, tak vytrhne trn z paty. Ta se v C++ dá do určité míry nahradit přes templaty, ale jen do určité míry. A naopak, co v Javě neumí generika se dá částečně obejít reflexí.
No já jsem takový trochu staromódní. Přijde mi cokoliv co v runtime saha dynamicky na definice tříd jako prasečina. Anotace tam patří, byť je to nástroj a asi se někdy hodí. Trochu mě vadí jejich dvojkolejnost. Jsou v tom jak "jakési atributy" - deprecated, override, atd, ty najdeme i v C++ ať už přímo v normě, nebo v nějakých implementacích přes #pragma (dá se to řešit před #define), a pak jsou tam runtime, které mají povahu spíš třídní konstanty...?
V C++ jsem schopen přetrpět RTTI, které umožňuje zeptat se objektu, zda náhodou neumí ještě nějaké jiné rozhraní (osobně na to mám vlastní systém, který ale v defaultu pro moji lenost nakonec zpravidla sáhne po RTTI - dynamic_cast ).
Vím že reflexe jsou super třeba na serializaci. I tak se mi častokrát vyplatilo mít oddělený formát od vnitřní reprezentace, což samozřejmě vedlo k nutnosti implementovat si vlastní serializaci - měl jsem speciální tabulku zvanou SerializeTypeInfo - přiřazovalo se k třídám identifikátory a uměl z objektu vytvořit identifikátor + zavolat serializaci a z identifikátoru vytvořit objekt a deserializovat ho. Hlavní výhodou bylo, že jsem mohl mít vícero tabulek a vícero identifikátorů pro případ, že bych generoval vícero formátů, kde každý objekt se dle typu formátu identifikoval jinak.
Reflexi a anotace a cokoliv kolem .class beru trochu jako pornografii. Program odhaluje svůj vnitřek až moc a vede to pak na limitace budoucích změn. Asi jako že taky nepřistupujeme k proměnným přímo ale používáme getry a nikdo nepřemýšlí proč je to dobrý nápad.
-
Rozumné jazyky (včetně C++ od verze C++11) mají tuples.
Já si zpravidla definuju třídu nebo strukturu (třídu public). Třeba jen kvůli názvům proměnných i z nějakého dokumentačního důvodu.
Jinak zrovna pro dva argumenty šlo použit
std::pair<int,int>
make_pair(a,b)
pro tři se omezeně dalo použít
std::pair<std::pair<int, int>, int >
make_pair(make_pair(a,b),c)
pro čtyři pak ještě
std::pair<std::pair<int, int>, std::pair<int, int>>
make_pair(make_pair(a,b),make_pair(c,d))
Ono se pak blbě zjišťuje, co je první, druhý, třetí argument, takže jaký je problém s?
struct vysledek {
int soucet;
int pocet;
};
vysledek zpracuj(int[] vstup);
vypadá to hned čitelněji, hlavně pak při zpracování výsledku
A ono to je lepší používat i pro vstupní proměnné, třeba taková funkce co má 20 argumentů, to je fakt šílenost. Je lepší to narvat do struktury a taky si je mohu pojmenovat a vím co je co.
Oproti Jave je vysledek stále jen v C++ lokální proměnná, není třeba ji alokovat pomoci new
-
Zlo je v tom, že se obchází špatný návrh jazyka. Prostě tam chybí tuple a rozumný způsob jeho rozbalení při přiřazení výstupu z funkce. Tento mechanismus je známý už spoustu let a to, že to nikdo neuměl při návrhu Javy, není omluva. Co navrhuješ, není elegantní, je to jenom jednoduché - a při znalosti současného stavu vývoje programovacích jazyků - prostě hloupé. Bez urážky.
Presne tak, tuple je jedine spravne reseni).
Viacerí to vidíte príliš čierno-bielo. Ja by som nepovedal, že tuple je jediné správne riešenie. Práve tuple je dobrý možno len na nejaké špeciality, teda skoro nikdy :) Aj keď teraz možno preháňam, lebo sa nepohybujem v oblastiach, kde je naozaj užitožný a prehľadný zároveň.
S tuple je to ešte neprehľadnejšie, lebo výstupné premenné majú aspoň nejaký názov, podľa ktorého je jasné, o čo ide, tuple nemá nič, len poradové číslo. Navyše ak chcem volať nejakú metódu, kde tie parametre nie sú čisto výstupné, ale sa použije aj ich aktuálna hodnota (napr. pričítavanie) tak by musl byť tuple na vstupe aj na výstupe a hodnoty by sa museli kopírovať.
V c# je to pekne vyriešené, že v deklarácii funkcie, aj pri jej volaní treba explicitne písať, keď je nejaký parameter výstupný, alebo vstupný aj výstupný.
-
Obvykle se k tomu použijí dva gettery (i když je, jak známo, sám nepoužívám) nebo použiješ jeden messenger. Také můžeš požadovanou operaci udělat uvnitř objektu a žádné dvě hodnoty ven nebudeš muset vytahovat.
Dva gettery mohu použít, pokud je to nějaká relativně jednoduchá operace. Ale často má člověk složitý processing, jehož výsledkem je víc hodnot a psát a volat ho x-krát by znamenalo duplikaci kódu i zbytečně strávený procesorový čas.
O messengeru jsem psal. Vede zbytečnému kódu navíc => méně přehledný program => prasárna.
Tuples by byly dobré, _pokud_ by v Javě měly rozumnou podporu na úrovni jazyka a nemuselo se to z nich tahat ručně. Ale psát program stylem "vím, že na nultém indexu je součet a na prvním počet" je ultra prasárna, to mi nikdo nevymluví.
Uvnitř objektu: To je použitelné opět jen v hodně malém množství příkladů.
Pokud je výsledkem vektor [x, y], tak to prasečina být nemusí. Prasečinou je požadovat po jedné metodě výstup dvou nesouvisejících hodnot.
Speciálně proto jsem psal ten příklad s výstupem "počet" a "součet", aby bylo jasné, že se mi nejedná o tenhle případ s vektorem. Ale počet a součet jsou související hodnoty. Viz výše - typicky to potřebuješ pokud máš nějaký netriviální processing a rozepisovat to do víc metod by bylo nevhodné.
Tak tohle je prasečina. Je to převzato z C/C++, kde to jinak nejde. Uvědom si, že to jsou procedurální jazyky, zatímco Java a C# jsou objektové. Jsou to různá paradigmata.
Velmi snadno to však můžeš udělat i v Javě. Stačí místo int použít Integer.
Takže žádný reálný argument (vyžaduje více kódu, je nepřehledné, vede k chybám, ...), jen kecy. Když tam místo int napíšu Integer, tak to sice bude "objektové" (takže OK?), ale nijak si nepomůžu, protože přiřazením do parametru se ta proměnná ve volající funkci nezmění.
-
Reflexi a anotace a cokoliv kolem .class beru trochu jako pornografii. Program odhaluje svůj vnitřek až moc a vede to pak na limitace budoucích změn. Asi jako že taky nepřistupujeme k proměnným přímo ale používáme getry a nikdo nepřemýšlí proč je to dobrý nápad.
Jako s alkoholem: V malých dávkách neškodí v jakémkoli množství. Pokud se však program skládá z propletených reflexí a anotací, ztrácí čitelnost. O to hůř se do něj zasahuje při modifikaci.
O tom, že gettery/settery jsou stejně špatný nápad, jako přímý přístup k proměnným, jsem už psal mnohokrát a není důvod to dále rozebírat.
-
Rozumné jazyky (včetně C++ od verze C++11) mají tuples.
Já si zpravidla definuju třídu nebo strukturu (třídu public). Třeba jen kvůli názvům proměnných i z nějakého dokumentačního důvodu.
Jinak zrovna pro dva argumenty šlo použit
std::pair<int,int>
make_pair(a,b)
pro tři se omezeně dalo použít
std::pair<std::pair<int, int>, int >
make_pair(make_pair(a,b),c)
pro čtyři pak ještě
std::pair<std::pair<int, int>, std::pair<int, int>>
make_pair(make_pair(a,b),make_pair(c,d))
Ono se pak blbě zjišťuje, co je první, druhý, třetí argument, takže jaký je problém s?
struct vysledek {
int soucet;
int pocet;
};
vysledek zpracuj(int[] vstup);
vypadá to hned čitelněji, hlavně pak při zpracování výsledku
A ono to je lepší používat i pro vstupní proměnné, třeba taková funkce co má 20 argumentů, to je fakt šílenost. Je lepší to narvat do struktury a taky si je mohu pojmenovat a vím co je co.
Oproti Jave je vysledek stále jen v C++ lokální proměnná, není třeba ji alokovat pomoci new
Stačí vzít std::tuple. Nebo tu strukturu kvůli pojmenování. Jinak třeba Swift umožňuje pojmenovat prvky tuplu.
-
Neumi anotace i nejaky novy JavaScript (prisahal bych, ze jsem to nekde cetl)? V anotacich nevidim problem, pokud jsou vhodne pouzity - napr. knihovnami - tak mohou byt velmi uzitecne. To stejne reflexe nebo generovani/upravovani bytekodu za behu - muze to velmi zprijemnit pouzivani knihovny.
Typ tuple se casto povazuje za prasecinu, zvlaste kdyz to vraci nejake API, je to jako mit nepojmenovane vystupni promenne. Ve Scale se to doporucuje resit pres case class - immutable trida, kterou lze pohodlne definovat na jednom radku. Nebylo neco takoveho planovane i pro Javu?
Nekdo tu psal, ze v C++ nepouziva nic low-level ani ASM. Ja ale nikde nepsal, ze se to bezne pouziva, pouze, ze pokud se to neuzije, tak moc velke (zedne?) vyhody oproti Jave/C# nebudou. Pametova narocnost bude urcite vyssi, ale jak je videt, tak se vyplati.
K nevyhodam Javy - lepsi generika (ne na urovni C#, ale rozhodne pouzitelnejsi, lze napr. instancovat gen. typ), vicenasobnou dedicnost (traity) i vlastni operatory Scala podporuje (z dalsich vlastnosti umi napr. makra pro prekladac, patern matching nebo implicitni parametry). Jak jsem zminil vyse, nekdy je oznacovana jako nastupce Javy, ikdyz tomu moc neverim. Ale rozhodne je hezke videt, jak Scala a dalsi jazyky tlaci vyvoj Javy kupredu :).
-
No já jsem takový trochu staromódní. Přijde mi cokoliv co v runtime saha dynamicky na definice tříd jako prasečina. Anotace tam patří, byť je to nástroj a asi se někdy hodí. Trochu mě vadí jejich dvojkolejnost. Jsou v tom jak "jakési atributy" - deprecated, override, atd, ty najdeme i v C++ ať už přímo v normě, nebo v nějakých implementacích přes #pragma (dá se to řešit před #define), a pak jsou tam runtime, které mají povahu spíš třídní konstanty...?
Aha, takže vůbec netušíš, k čemu se anotace dají použít. No, to se pak nedivím, že ti přijde Java vlastně jako C++ :)
Tak z hlavy různá šikovná využití:
- specifikace ORM na objektu (co ne, co ano, do jakého sloupečku, jak, vazby mezi entitami, ...)
- deklarativní validace na objektu
- deklarativní mapování controllerů, metod, parametrů, ... v MVC (Spring)
- (spolu aspecty) deklarativní security, deklarativní transakce, ...
- atd.
Výhoda je, že anotacemi se toho moc sprasit nedá, teda asi by se dalo, ale člověk by se musel moc snažit. Všechna použití co jsem zatím potkal byla spíš ku prospěchu věci.
-
kam sa zas zvrtla ta diskusia???
-
kam sa zas zvrtla ta diskusia???
Tím bych to uzavřel
-
kam sa zas zvrtla ta diskusia???
tak jak vždycky :) už jste se podíval na ten F# ?
-
Obvykle se k tomu použijí dva gettery (i když je, jak známo, sám nepoužívám) nebo použiješ jeden messenger. Také můžeš požadovanou operaci udělat uvnitř objektu a žádné dvě hodnoty ven nebudeš muset vytahovat.
Dva gettery mohu použít, pokud je to nějaká relativně jednoduchá operace. Ale často má člověk složitý processing, jehož výsledkem je víc hodnot a psát a volat ho x-krát by znamenalo duplikaci kódu i zbytečně strávený procesorový čas.
Jenže uvedená ukázka je typická pro procedurální programování. Když budeš psát objektově, tak takovou funkci ani nebudeš potřebovat. K čemu potřebuješ současně součet i počet? Z objektu mi obvykle stačí jen jedna hodnota. Výsledek.
Speciálně proto jsem psal ten příklad s výstupem "počet" a "součet", aby bylo jasné, že se mi nejedná o tenhle případ s vektorem. Ale počet a součet jsou související hodnoty. Viz výše - typicky to potřebuješ pokud máš nějaký netriviální processing a rozepisovat to do víc metod by bylo nevhodné.
Protože nepracuješ s objektem, ale s polem. Když budeš psát objektově, ...
Velmi snadno to však můžeš udělat i v Javě. Stačí místo int použít Integer.
Když tam místo int napíšu Integer, tak to sice bude "objektové" (takže OK?), ale nijak si nepomůžu, protože přiřazením do parametru se ta proměnná ve volající funkci nezmění.
Nepoužívám to a chování jsem odhadl. Teď jsem si na to napsal test, který mi dokázal, že to tak nefunguje. V tomhle máš tedy pravdu. Stále je tu však možnost napsat si messenger nebo to napsat pořádně a místo pole udělat standardní objekt.
Stále se motáme kolem toho, že procedurální kód se v Javě píše docela blbě. Zcela určitě to byl záměr.
-
Já tedy programuju v C++ a nemám pocit, že bych něco dělal dlouho jen proto, že si někdo myslí, že v C++ se to musí programovat dlouho a je to složité. Taky si nepíšu nic v ASM, proč bych to dělal? Používám C++ spíš jako ... Javu. Používám vektory, mapy, stringy, streamy, iterátory atd, pokud už něco někde alokuju, tak na to používám chytré ukazatele, počítání referencí - já vím, že má problémy s cykly a není tedy plnhodnotnou náhradou GC, ale ... 95% problémů to nemusím řešit a GC je vlastně takový kanón na vrabce. Tam kde to musím řešit, tam se vždycky najde nějaké jiné řešení, třeba pomocí jednoduchého GC který řeší konkrétní případ (registrace a odregistrace uzlů do kontejneru stojícího mimo dynamickou strukturu, atd)
Když srovnám Javu a C++ z hlediska pohodlnosti vývoje, tak
- 80% kódu v Javě se dá zapsat stejně v C++ a jeho vývoj bude trvat stejně dlouho
- Java zvládá dobře správu paměti která způsobuje, že nad spoustou věcí nemusím přemýšlel, třeba právě u nějakých hodně propojených struktur, kde hrozí cykly
- naopak C++ má RAII, který mi umožňuje nemyslet na uvolňování jiných resourců (síťová spojení, např., ale třeba různé věci okolo zámků a podobně. Dále samozřejmě různé buildery, které v destruktoru provedou vlastní sestavení výsledku a předání patřičnému příjemci
- V C++ je výhodou generika, v Javě je to spíš hack a výsměnch
- Java pro změnu má obrovské množství knihoven na všechno. Nemusím tak vymýšlet algoritmy, které již někdo vymyslel. Nevýhodou je, že ne všechny ty algoritmy jsou implementovány chytře a vyhovují mým potřebam. V C++ jsem si většinu knihovní báze musel napsat sám
- V C++ lépe řeší různé binární formáty
- V C++ zvládá lépe dědičnost, vícenásobnou dědičnost, virtuální dědičnost - jo, taky to často potřebuju. Java naopak je pochopitelnější pro méně zdatné jedince, protože tohle nemá
- C++ má větší možnosti v definování vlastních operátorů, což otevírá možnosti k většímu přizpůsobení jazyka a přehlednějšímu kódu, přímočařejším zápisům, což ale u méně zdatných jedinců vede k prasení kódu a je kontraproduktivní. Java nic takového nemá, proto prasení kódu redukuje
Tento výčet popisoval zbývajících 20% rozdílů. Pokud někdo programuje rychleji v Javě, než v C++, bude to tím, že se naučil Javu a nenaučil se C++. U mě je to například obráceně.
Neco takoveho jsem chtel napsat. Take pouzivam C++ defakto jako Javu. Ti C++ hejtri videli C++ jen z rychliku nekdy pred 20 lety.
-
Jinak co se tyce te reflexe a anotaci, tak pokud to nekdo opravdu potrebuje si muze udelat vlastni preprocesor a vygenerovat dodatecne zdrojaky.
Pro anotace by to pak chtelo i nejaky support v IDEcku, aby to moc nebylo do oka. Ono hodne lidi si mysli, ze tyhle preprocesory je spatny napad, ze uz to neni C++, ale podle me to je naopak chytrost programatora.
-
co si myslite o tych knizkach co som postol?
-
Stačí vzít std::tuple. Nebo tu strukturu kvůli pojmenování. Jinak třeba Swift umožňuje pojmenovat prvky tuplu.
Jj pojmenovani tuple si swift propujcil z jazyka D. Celkem pekny jazyk ten swift, zda se ze okopirovali jen to nejlepsi z vetsiny jazyku (mysleno pozitivne).
-
Stačí vzít std::tuple. Nebo tu strukturu kvůli pojmenování. Jinak třeba Swift umožňuje pojmenovat prvky tuplu.
Jj pojmenovani tuple si swift propujcil z jazyka D. Celkem pekny jazyk ten swift, zda se ze okopirovali jen to nejlepsi z vetsiny jazyku (mysleno pozitivne).
Přesně tak, a autoři se tím ani nijak netají. Žádný jiný jazyk nenabízí to, co Swift, na jednom místě. Navíc se překládá do LLVM IR a má pekelně rychlou standardní knihovnu. Hodně se inspiroval jazykem Go od Google.
-
... zda se ze okopirovali jen to nejlepsi z vetsiny jazyku (mysleno pozitivne).
Bez kopirovani by snad nebyl pokrok, mely bychom jen hodne sisatych kol, ale zadna auta :D. Nektere firmy v tom vynikaji - treba Blizzard, proste vyberou dobre vlastnosti stavajicich her, krasne to nalesti a uspech je na svete (take to neminim negativne).
-
dakujem za "konstruktivnu" debatu, ktora zas ako vzdy viedla k niecomu uplne inemu, ako to byva na roote. Vacsinou prispevky k nicomu. Su tu ale aj prispevky, ktore sa naozaj tykaju temy, co som rad a dakujem za rady.
-
co si myslite o tych knizkach co som postol?
nepůsobí na mě dojmem, že by vám mohly otevřít úplně nové obzory
-
co si myslite o tych knizkach co som postol?
Nejvíc mě oslovila ta posledně jmenovaná, tedy Code Complete. Tedy alespoň podle obsahu samplu, který jsem si stáhl.
-
dakujem za "konstruktivnu" debatu, ktora zas ako vzdy viedla k niecomu uplne inemu, ako to byva na roote. Vacsinou prispevky k nicomu. Su tu ale aj prispevky, ktore sa naozaj tykaju temy, co som rad a dakujem za rady.
Tak ... klasika ... :)
Jinak se mozna zkus vyhecnout a dat sanci Clojure. Vyuzijes to dneska prakticky v celem mainstreamu: nad JVM, nad CLR i na JavaScriptovymi enginy (tedy v node.js i prohlizecich). Ten pohled na programovani, ktery Rich vymyslel, me hodne rozsiril obzory i v jinych jazycich.
-
Navrhnout aplikaci žádné umění není. Největší průser je právě to rozšiřování, což programátor neovlivní, stejně jako rozporuplné zadání. Tady má výhodu menší firma nebo živnostník, protože toho nikdo nenutí na nesmylné požadavky kývnout. Pokud se nejde se zákazníkem dohodnout, tak ať jde jinam. Průser větších firem je v tom, že nesmyslné zadání častěji z hlavy "analytika" nebo "architekta" než z hlavy zákazníka. Analytik totiž skutečnou analýzu neprovádí, jen zapisuje průběh schůzky se zákazníkem, nemá ponětí, co se honí v hlavě zákazníka a po skončení schůzky končí práce analytika. Skutečná analýzaje zůstane na programátorovi a to bez kontaktu se zákazníkem. Poslední slovo má "analytik" (většinou vedoucí vývoje nebo projektový manager), který je přesvědčen, že zákazníka pochopil.
Skusali ste uz vratit diplom, ked podla vas nie je umenie navrhnut aplikaciu? Potom ze sa vam zle aplikacia rozsiruje ...
-
mna by zaujimalo, teda smerujem otazku na tych co mi odporucili FP, ze ako sa to da uplatnit v beznom zivote, v praci a ci sa to da sklbit aj s normalnymi jazykmi, napr F# so C#.
-
Navrhnout aplikaci žádné umění není. Největší průser je právě to rozšiřování, což programátor neovlivní, stejně jako rozporuplné zadání. Tady má výhodu menší firma nebo živnostník, protože toho nikdo nenutí na nesmylné požadavky kývnout. Pokud se nejde se zákazníkem dohodnout, tak ať jde jinam. Průser větších firem je v tom, že nesmyslné zadání častěji z hlavy "analytika" nebo "architekta" než z hlavy zákazníka. Analytik totiž skutečnou analýzu neprovádí, jen zapisuje průběh schůzky se zákazníkem, nemá ponětí, co se honí v hlavě zákazníka a po skončení schůzky končí práce analytika. Skutečná analýzaje zůstane na programátorovi a to bez kontaktu se zákazníkem. Poslední slovo má "analytik" (většinou vedoucí vývoje nebo projektový manager), který je přesvědčen, že zákazníka pochopil.
Skusali ste uz vratit diplom, ked podla vas nie je umenie navrhnut aplikaciu? Potom ze sa vam zle aplikacia rozsiruje ...
Však si své tvrzení sám vyvrátil. Pokud navrhne aplikaci tak, že se následně blbě rozšiřuje, je i blbě navržena.
-
mna by zaujimalo, teda smerujem otazku na tych co mi odporucili FP, ze ako sa to da uplatnit v beznom zivote, v praci a ci sa to da sklbit aj s normalnymi jazykmi, napr F# so C#.
Radši už nic nezkoušej a zkus třeba prodávat počítače. Všechno složitější je asi nad tvé možnosti.
-
mna by zaujimalo, teda smerujem otazku na tych co mi odporucili FP, ze ako sa to da uplatnit v beznom zivote, v praci a ci sa to da sklbit aj s normalnymi jazykmi, napr F# so C#.
Radši už nic nezkoušej a zkus třeba prodávat počítače. Všechno složitější je asi nad tvé možnosti.
A jde ti dobře ten prodej počítačů?
FP ti dá hlavně nadhled, jak funguje další paradigma. Do OOP si pak můžeš z FP propašovat například immutable objekty.
-
mna by zaujimalo, teda smerujem otazku na tych co mi odporucili FP, ze ako sa to da uplatnit v beznom zivote, v praci a ci sa to da sklbit aj s normalnymi jazykmi, napr F# so C#.
FP se teď cpe všude mozně, od Javy po Swift. Vzniká z toho kočkopes, nicméně určitě není na škodu základy FP znát, přinejmenším část se dá úspěšně uplatnit i v OO jazycích, zejména při konkurenčním programování. Kód v FP bývá také kratší, ale prý méně čitelný (posledně uvedené není můj názor, ale mnozí si stěžují).
-
mna by zaujimalo, teda smerujem otazku na tych co mi odporucili FP, ze ako sa to da uplatnit v beznom zivote, v praci a ci sa to da sklbit aj s normalnymi jazykmi, napr F# so C#.
Radši už nic nezkoušej a zkus třeba prodávat počítače. Všechno složitější je asi nad tvé možnosti.
A jde ti dobře ten prodej počítačů?
FP ti dá hlavně nadhled, jak funguje další paradigma. Do OOP si pak můžeš z FP propašovat například immutable objekty.
Ani číst, ani programovat, co?
-
Hoši, a co si tak najít babu?
-
Dobří programátoři a linuxáci babu nikdy nemají. To je pro lemply, kteří mají čas a nic neumí.
-
mna by zaujimalo, teda smerujem otazku na tych co mi odporucili FP, ze ako sa to da uplatnit v beznom zivote, v praci a ci sa to da sklbit aj s normalnymi jazykmi, napr F# so C#.
ve funkcionálních jazycích se některé věci dělají tak nějak líp, třeba paralelismus a překladače, kód v F# by měl být bezpracně integrovatelný se zbytkem .net, takže pokud se vám v tom opravdu bude něco dělat lépe můžete to prakticky využít (snad) snadno, ale hlavně je funkcionální programování dobré k rozšíření obzorů, někteří zdejší diskutující by to potřebovali jako sůl
-
Prosím neplést FP v takových jazycích jako F# se skutečným FP ... Nejblíže skutečnému FP má dnes Haskell a Elm. To ostatní jsou parodie které si obvykle jen něco z FP vezmou, ale plně ho neimplementují a tím pádem výsledný dojem a funkcionalita jsou výrazně odlišné od "více" FP jazyků.
A k čemu ti bude FP v praxi? K hovnu, v praxi se s FP v 95% ani nesetkáš (a často ani ne s OOP ... hmm). Takže, k čemu ti to bude? Rozšíří ti to obzory a budeš schopen se dívat na problémy z více různých úhlů (neeeee nezačneš chápat ostatní paradigmata jak tady psal velký profesionál Kit). A za další, budeš připraven na budoucnost. Dosáhli sme limitu výkonu na jedno jádro, nyní začne rozšiřování výkonu procesorů do "šířky" (více jader) a tím pádem bude nutné psát silně paralelní aplikace. To aktuální jazyky fakt ale fakt nedávají. Jediná cesta ven je "pure" OOP a "pure" FP. Oboje paradigmata perfektně zvládají paralelismus. Takže, studiem FP se připravíš na budoucnost.
Taková poznámka, je výrazně vetší šance že se prosadí pure FP než pure OOP. Především proto že všichni už zapoměli jak vlastně to pure OOP vypadá ...
-
Navrhnout aplikaci žádné umění není. Největší průser je právě to rozšiřování, což programátor neovlivní, stejně jako rozporuplné zadání. Tady má výhodu menší firma nebo živnostník, protože toho nikdo nenutí na nesmylné požadavky kývnout. Pokud se nejde se zákazníkem dohodnout, tak ať jde jinam. Průser větších firem je v tom, že nesmyslné zadání častěji z hlavy "analytika" nebo "architekta" než z hlavy zákazníka. Analytik totiž skutečnou analýzu neprovádí, jen zapisuje průběh schůzky se zákazníkem, nemá ponětí, co se honí v hlavě zákazníka a po skončení schůzky končí práce analytika. Skutečná analýzaje zůstane na programátorovi a to bez kontaktu se zákazníkem. Poslední slovo má "analytik" (většinou vedoucí vývoje nebo projektový manager), který je přesvědčen, že zákazníka pochopil.
Skusali ste uz vratit diplom, ked podla vas nie je umenie navrhnut aplikaciu? Potom ze sa vam zle aplikacia rozsiruje ...
Však si své tvrzení sám vyvrátil. Pokud navrhne aplikaci tak, že se následně blbě rozšiřuje, je i blbě navržena.
Ani nie, len nepochopil, aka je pracovna napln architekta a analytika + sa pochvalil, ze nevie vytvarat aplikacie.
-
dakujem za "konstruktivnu" debatu, ktora zas ako vzdy viedla k niecomu uplne inemu, ako to byva na roote. Vacsinou prispevky k nicomu. Su tu ale aj prispevky, ktore sa naozaj tykaju temy, co som rad a dakujem za rady.
A jakou diskusi jsi k takové hloupé otázce čekal?
-
neexistuje hlupa otazka, ale len hlupa odpoved ;)
-
mna by zaujimalo, teda smerujem otazku na tych co mi odporucili FP, ze ako sa to da uplatnit v beznom zivote, v praci a ci sa to da sklbit aj s normalnymi jazykmi, na :-\pr F# so C#.
Moderni aplikace pro browser uz se jinak ani nedelaji. Viz redux
Clojure se pouziva i v enterprise. Viz stranky cognitectu. Klasicky blog o wallmartu kde popisuji jak jim to pomohlo s black friday.
Ostatni se taky bezne pouziva.
Vetsinou FP pomaha pochopit, ze je potreba mit jednoduchy (idealne zadny :) stav a ostrazitosti k jinym zbytecnym slozitostem.
Hezky o tom mluvi Rich Hickey v te prednasce co jsem postnul vyse. Simple made easy
-
neexistuje hlupa otazka, ale len hlupa odpoved ;)
A co říkáš na tu knihu Code Complete?
-
Viacerí to vidíte príliš čierno-bielo. Ja by som nepovedal, že tuple je jediné správne riešenie. Práve tuple je dobrý možno len na nejaké špeciality, teda skoro nikdy :) Aj keď teraz možno preháňam, lebo sa nepohybujem v oblastiach, kde je naozaj užitožný a prehľadný zároveň.
S tuple je to ešte neprehľadnejšie, lebo výstupné premenné majú aspoň nejaký názov, podľa ktorého je jasné, o čo ide, tuple nemá nič, len poradové číslo. Navyše ak chcem volať nejakú metódu, kde tie parametre nie sú čisto výstupné, ale sa použije aj ich aktuálna hodnota (napr. pričítavanie) tak by musl byť tuple na vstupe aj na výstupe a hodnoty by sa museli kopírovať.
V c# je to pekne vyriešené, že v deklarácii funkcie, aj pri jej volaní treba explicitne písať, keď je nejaký parameter výstupný, alebo vstupný aj výstupný.
Především "výstupní parametr" v pravém slova neexistuje (jakkoliv se v tomto významu to slovo používá). Parametr funkce, metody, programu říká, jak nebo z čeho má probíhat výpočet. K výstupu z funkce je určena návratová hodnota. Na jednu stranu rozumím argumentu, že ty výstupní hodnoty v tuple nejsou pojmenované, ale to přece platí i pro funkci, která vrací jednu hodnotu. Jaký má výstupní hodnota význam, je popsáno v dokumentaci, případně to vyplývá z názvu. Příkladem dobrého použití dvou návratových hodnot je třeba funkce divmod() v Pythonu. Je obecně dobrý nápad mít vícero výstupních hodnot? Podle mě moc ne, ale když se to nepřežene, problém v tom nevidím. Docela dobře to má řešeno Go, tam se výstupní hodnoty v deklaraci funkce dají pojmenovat. Přesto se domnívám, že podstatně lepší je použít něco jako Either (Haskell a spol.). Neomezené míchání "vstupních a výstupních parametrů" považuju ovšem za vůbec nejhorší řešení, jakkoliv je bez diskuse nejflexibilnější. Pak je ovšem otázka, proč se nezbavit návratové hodnoty úplně, protože ta se pak stává poněkud nadbytečnou.
-
neexistuje hlupa otazka, ale len hlupa odpoved ;)
Je tučňák lepší než vidlička?
-
neexistuje hlupa otazka, ale len hlupa odpoved ;)
Je tučňák lepší než vidlička?
Tučňáka bez vidličky nesežereš. A žabinec bez brčka neusmažíš!
-
A co říkáš na tu knihu Code Complete?
ta sa mi tiez pozdava, len je to knizka z roku 2004 myslim, a neviem, ci by nebolo lepsie nejaku novsiu.
-
neexistuje hlupa otazka, ale len hlupa odpoved ;)
A co říkáš na tu knihu Code Complete?
-
Především "výstupní parametr" v pravém slova neexistuje (jakkoliv se v tomto významu to slovo používá).
No, návratová hodnota je převzata z matematiky kdy funkce vrací jednu hodnotu, nebo vektor nebo matici. Ale já tvrdím že návratová hodnota neexistuje. Místo toho mám radši, když součástí argumentů je reference na místo, kam se má výsledek uložit. Umožňuje to mít funkci která má víc návratových hodnot ... když už může mít víc vstupních parametrů.
PS: Je to lehce silvestrovský příspěvek abych pošťouchnul zdejši evangelisty, nicméně třeba C++ takto návratovou hodnotu implementuje pro typy větší než integer. Podobný koncept používám u future/promise. Při otázce, zda je lepší, když funkce vrací future, nebo když ji předám promise volím spíš druhou možnost.
-
mna by zaujimalo, teda smerujem otazku na tych co mi odporucili FP, ze ako sa to da uplatnit v beznom zivote, v praci a ci sa to da sklbit aj s normalnymi jazykmi, napr F# so C#.
Samozrejme, ze se FP da v praxi uplatnit, ale jako koncept spis nez v konkretnim FP jazyce. FP uci dobremu navrhu, protoze stavi programovani na mnohem pevnejsi matematicke zaklady. Napriklad vezmi si LINQ v C# - to ma dobre API proto, ze se za nim skryvaji monady. Dobre to ukazuje treba knizka https://www.manning.com/books/functional-programming-in-scala (https://www.manning.com/books/functional-programming-in-scala).
-
No, návratová hodnota je převzata z matematiky kdy funkce vrací jednu hodnotu, nebo vektor nebo matici. Ale já tvrdím že návratová hodnota neexistuje. Místo toho mám radši, když součástí argumentů je reference na místo, kam se má výsledek uložit. Umožňuje to mít funkci která má víc návratových hodnot ... když už může mít víc vstupních parametrů.
Hloupost.. V matematice funkce zobrazuje z jedne hodnoty do jine, a formalne funkce s vice parametry prijimaji n-tici (tuple), a stejne tak mohou n-tici vratit (alternativne se da oboji - vice vstupnich i vice vystupnich parametru - resit pres currying, tedy vraceni funkci).
Klasicky priklad funkce kde je uzitecne vratit vic argumentu je celociselne deleni. V matematice je to jedno, ale v pocitacich chceme delit jenom jednou, ne dvakrat.
PS: Je to lehce silvestrovský příspěvek abych pošťouchnul zdejši evangelisty, nicméně třeba C++ takto návratovou hodnotu implementuje pro typy větší než integer. Podobný koncept používám u future/promise. Při otázce, zda je lepší, když funkce vrací future, nebo když ji předám promise volím spíš druhou možnost.
To jak to ktery jazyk implementuje je irelevantni, u jazyka je asi podstatnejsi pohodli programatora. Stejne jako u vraceni tuplu vs predavani parametru odkazem, future jsou spis funkcionalni, kdezto promises jsou imperativni konstrukt.
-
Já tedy programuju v C++ a nemám pocit, že bych něco dělal dlouho jen proto, že si někdo myslí, že v C++ se to musí programovat dlouho a je to složité. Taky si nepíšu nic v ASM, proč bych to dělal? Používám C++ spíš jako ... Javu. Používám vektory, mapy, stringy, streamy, iterátory atd, pokud už něco někde alokuju, tak na to používám chytré ukazatele, počítání referencí - já vím, že má problémy s cykly a není tedy plnhodnotnou náhradou GC, ale ... 95% problémů to nemusím řešit a GC je vlastně takový kanón na vrabce. Tam kde to musím řešit, tam se vždycky najde nějaké jiné řešení, třeba pomocí jednoduchého GC který řeší konkrétní případ (registrace a odregistrace uzlů do kontejneru stojícího mimo dynamickou strukturu, atd)
Když srovnám Javu a C++ z hlediska pohodlnosti vývoje, tak
- 80% kódu v Javě se dá zapsat stejně v C++ a jeho vývoj bude trvat stejně dlouho
- Java zvládá dobře správu paměti která způsobuje, že nad spoustou věcí nemusím přemýšlel, třeba právě u nějakých hodně propojených struktur, kde hrozí cykly
- naopak C++ má RAII, který mi umožňuje nemyslet na uvolňování jiných resourců (síťová spojení, např., ale třeba různé věci okolo zámků a podobně. Dále samozřejmě různé buildery, které v destruktoru provedou vlastní sestavení výsledku a předání patřičnému příjemci
- V C++ je výhodou generika, v Javě je to spíš hack a výsměnch
- Java pro změnu má obrovské množství knihoven na všechno. Nemusím tak vymýšlet algoritmy, které již někdo vymyslel. Nevýhodou je, že ne všechny ty algoritmy jsou implementovány chytře a vyhovují mým potřebam. V C++ jsem si většinu knihovní báze musel napsat sám
- V C++ lépe řeší různé binární formáty
- V C++ zvládá lépe dědičnost, vícenásobnou dědičnost, virtuální dědičnost - jo, taky to často potřebuju. Java naopak je pochopitelnější pro méně zdatné jedince, protože tohle nemá
- C++ má větší možnosti v definování vlastních operátorů, což otevírá možnosti k většímu přizpůsobení jazyka a přehlednějšímu kódu, přímočařejším zápisům, což ale u méně zdatných jedinců vede k prasení kódu a je kontraproduktivní. Java nic takového nemá, proto prasení kódu redukuje
Tento výčet popisoval zbývajících 20% rozdílů. Pokud někdo programuje rychleji v Javě, než v C++, bude to tím, že se naučil Javu a nenaučil se C++. U mě je to například obráceně.
Buďme rádi, že Java existuje, výběh pro patlaly se hodí. Noční můrou by bylo, kdyby se tato sorta lidí pokoušela psát aplikace v C nebo C++. Člověku, co zná jen Javu (a tudíž ji fanaticky hájí a vynáší do nebes, jako noef), se nedá vysvětlit, že C++ je stejně high level jazyk. Prase se taky těžko přesvědčuje, aby se neválelo ve vlastních ho..ech.
-
V některých případech kompilátor C++ (aspoň GCC 4.8) může vysypat rychlejší strojový kód se strukturou v návratové hodnotě než s voláním odkazem. Např. právě u toho dělení a modula. Samožná definice struktury v C++ je "zadarmo" narozdíl od Javy (žádný bytecode, konstruktor, alokace, je to jen informace pro kompilátor). Při vrácení struktury se kdysi vytvořila struktura na zásobníku před voláním funkce a do funkce se poslal odkaz, takže to bylo stejné, jako by se totéž udělalo ručně s jednotlivými položkami struktury. Voláním odkazem se tedy téměř nic nezískalo. Moderní kompilátor ale dokáže víc: pokud se funkce inlinuje, což bude případ dělení / modulo, pak může výsledek v registrech rax/rdx rovnou použít v dalším výrazu a bude zhruba stejně efektivní, jako by dělění a modulo byly součásti většího výrazu a přitom se provede pouze jedna operace dělení. Tedy získáme něco, co dřívě šlo získat pouze naprogramováním celého výrazu v assembleru.
Obecně se v C++ vyplatí napsat kód nejprve bez zbytečných prasáren, nechat si vyjet assembler (gcc -s) a teprve při nespokojenosti optimalizovat prasárnami. GCC 4.8 optimalizuje jak ďábel a řekl bych že lépe než Visual C++.
-
V některých případech kompilátor C++ (aspoň GCC 4.8) může vysypat rychlejší strojový kód se strukturou v návratové hodnotě než s voláním odkazem.
To je vynikajici poznamka! Jeste markantnejsi je to v jazycich s GC, napriklad Common Lisp ma moznost vraceni vice navratovych hodnot prave z toho duvodu, ze by sice bylo pomerne snadne vratit seznam, akorat seznam by znamenal alokaci na halde, kdezto vice navratovych hodnot se ulozi na zasobnik.
-
<trolling>Buďme rádi, že Java existuje, výběh pro patlaly se hodí. Noční můrou by bylo, kdyby se tato sorta lidí pokoušela psát aplikace v C nebo C++.</trolling>
Člověku, co zná jen Javu (a tudíž ji fanaticky hájí a vynáší do nebes, jako noef), se nedá vysvětlit, že C++ je stejně high level jazyk.
<trolling>Prase se taky těžko přesvědčuje, aby se neválelo ve vlastních ho..ech.</trolling>
Opravdu? Vidim tu snahu o trolling, protoze vas prispevek nejen, ze je jak od lopaty, navic je nepravdivy. (Coz nabizi otazku, zda opravdu neni od lopaty, ze...) Rozhodne neznam jen Javu, nejnovejsi verzi jsem dokonce snad ani nepouzil. Usekl jste si pekny trapas, vzdyt primo v tomto vlaknu propaguji Scalu a alternativni pristupy nekolikatou stranu (zminl jsem napr. i Haskell, Frege a F#).
A ze bych Javu vychvaloval, nebo dokonce "vynasel do nebes", to myslite opravdu vazne? Protoze asi nejste prilis bystry, tak mi nezbyva, nez se citovat:
... 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). ...
Ja nepopiram high-level aspekt C++, jen jsem rikal, ze pokud pouzivate tento high-level pristup, tak je jedno, jestli delate v C++ nebo v Jave, dosahnete vykonostne stejneho vysledku (dokonce tu nekdo zminoval nejakou studii od Googlu). Pokud se pujde vice "low-level", tak velkym rozdilem bude cas a narocnost vyvoje vymenou za lepsi vykon. Tzn. napsat projekt v C++ vyjde zadavatele v kazdem pripade draz, nez v Jave. Vysledny produkt u high-level pristupu, pominu-li pametovou narocnost, bude davat stejne rychle stejne vysledky a tudiz je rozdilem pouze cena prace. Vzhledem k tomu, ze Java je navrzena tak, aby v ni mohl zacit delat skoro kdokoliv (az se nabizi ono drazdive slovo "opice"), se neni cemu divit, ze hodinova sazba zacinajiciho Javisty a CPPisty se asi budou pomerne dost lisit. No a u "low-level" pristupu s rucnim tunenim pristupu k pameti a opravdovymi zisky na vykonu to vyjde zakaznika velmi draho, protoze hodinova cena C++ profika je velmi vysoka. A tak se deje, ze vsichni, pokud neni opravdu zbyti (hry*, embeded), voli variantu malinko pomalejsi aplikaci + vice pameti (ktera je nyni smesne levna) a mene programovani (ktere je stale velmi drahe).
Predchozi tvzreni podporuje i Tiobe index. Nevim tedy, jak moc je realne vypovidajici, ale C++ vykazuje celkem patrny trend - dlouhodoby postupny pokles.
*: U indie her se davno pouzivaji "pomale" jazyky jako C# a Java. Co je zajimave, ze uz i do AAA her zacinaji prorazet, prestoze spise jen pro skriptovani a UI, jazyky a technologie jako Adobe Air (v podstate Flash, UI v MMORPG, napr. Tera), Lua (napr. addony ve WoW) nebo JavaScript (skriptovani v Unity Enginu).
PS: Patlat a bastlit se da v jakemkoliv jazyku, to ze delate v C++ z vas lepsiho programatora nutne nedela ;).
-
Lua (napr. addony ve WoW) nebo JavaScript (skriptovani v Unity Enginu).
Souhlasím s tou Lua. Na skriptování nestvůr a jiných věcí asi není nic vhodnějšího.
PS: Patlat a bastlit se da v jakemkoliv jazyku, to ze delate v C++ z vas lepsiho programatora nutne nedela ;).
No hlavně nedělá horšího, pomalejšího nebo dražšího....
... i když, aby C++ programátor byl přínosný, musí být dobrý, a pokud je dobrý, nebude levný. Ale to možná platí i jinde.
-
Lua (napr. addony ve WoW) nebo JavaScript (skriptovani v Unity Enginu).
Souhlasím s tou Lua. Na skriptování nestvůr a jiných věcí asi není nic vhodnějšího.
PS: Patlat a bastlit se da v jakemkoliv jazyku, to ze delate v C++ z vas lepsiho programatora nutne nedela ;).
No hlavně nedělá horšího, pomalejšího nebo dražšího....
... i když, aby C++ programátor byl přínosný, musí být dobrý, a pokud je dobrý, nebude levný. Ale to možná platí i jinde.
To platí všude :)
-
<trolling>Buďme rádi, že Java existuje, výběh pro patlaly se hodí. Noční můrou by bylo, kdyby se tato sorta lidí pokoušela psát aplikace v C nebo C++.</trolling>
Člověku, co zná jen Javu (a tudíž ji fanaticky hájí a vynáší do nebes, jako noef), se nedá vysvětlit, že C++ je stejně high level jazyk.
<trolling>Prase se taky těžko přesvědčuje, aby se neválelo ve vlastních ho..ech.</trolling>
Opravdu? Vidim tu snahu o trolling, protoze vas prispevek nejen, ze je jak od lopaty, navic je nepravdivy. (Coz nabizi otazku, zda opravdu neni od lopaty, ze...) Rozhodne neznam jen Javu, nejnovejsi verzi jsem dokonce snad ani nepouzil. Usekl jste si pekny trapas, vzdyt primo v tomto vlaknu propaguji Scalu a alternativni pristupy nekolikatou stranu (zminl jsem napr. i Haskell, Frege a F#).
A ze bych Javu vychvaloval, nebo dokonce "vynasel do nebes", to myslite opravdu vazne? Protoze asi nejste prilis bystry, tak mi nezbyva, nez se citovat:
... 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). ...
Ja nepopiram high-level aspekt C++, jen jsem rikal, ze pokud pouzivate tento high-level pristup, tak je jedno, jestli delate v C++ nebo v Jave, dosahnete vykonostne stejneho vysledku (dokonce tu nekdo zminoval nejakou studii od Googlu). Pokud se pujde vice "low-level", tak velkym rozdilem bude cas a narocnost vyvoje vymenou za lepsi vykon. Tzn. napsat projekt v C++ vyjde zadavatele v kazdem pripade draz, nez v Jave. Vysledny produkt u high-level pristupu, pominu-li pametovou narocnost, bude davat stejne rychle stejne vysledky a tudiz je rozdilem pouze cena prace. Vzhledem k tomu, ze Java je navrzena tak, aby v ni mohl zacit delat skoro kdokoliv (az se nabizi ono drazdive slovo "opice"), se neni cemu divit, ze hodinova sazba zacinajiciho Javisty a CPPisty se asi budou pomerne dost lisit. No a u "low-level" pristupu s rucnim tunenim pristupu k pameti a opravdovymi zisky na vykonu to vyjde zakaznika velmi draho, protoze hodinova cena C++ profika je velmi vysoka. A tak se deje, ze vsichni, pokud neni opravdu zbyti (hry*, embeded), voli variantu malinko pomalejsi aplikaci + vice pameti (ktera je nyni smesne levna) a mene programovani (ktere je stale velmi drahe).
Predchozi tvzreni podporuje i Tiobe index. Nevim tedy, jak moc je realne vypovidajici, ale C++ vykazuje celkem patrny trend - dlouhodoby postupny pokles.
*: U indie her se davno pouzivaji "pomale" jazyky jako C# a Java. Co je zajimave, ze uz i do AAA her zacinaji prorazet, prestoze spise jen pro skriptovani a UI, jazyky a technologie jako Adobe Air (v podstate Flash, UI v MMORPG, napr. Tera), Lua (napr. addony ve WoW) nebo JavaScript (skriptovani v Unity Enginu).
PS: Patlat a bastlit se da v jakemkoliv jazyku, to ze delate v C++ z vas lepsiho programatora nutne nedela ;).
Doufám, že se shodneme, že níže uvedený kód - odvar bottlenecku z jedné reálné javovské aplikace později přepsané do Go - je high-level. Takže vyzývám všechny, co si myslí, že umí Javu, a mají pět minut volného času, aby předvedli, jaký kód v Javě bude stejně rychlý. Porovnám to pak na x86, ARM, MIPSu a PowerPC.
class Complex {
public:
double re;
double im;
Complex(double r, double i) : re(r), im(i) {}
Complex operator+(const Complex& x) const {
return Complex(re + x.re, im + x.im);
}
};
...
std::vector<Complex> list;
for (auto y = Complex(0, 0); y.re < 10'000; y = Complex(y.re + 0.0001, y.im + 0.0001)) {
list.emplace_back(y);
}
auto x = Complex(0, 0);
for (const auto& y : list) { x = x + y; }
std::cout << x;
-
Doufám, že se shodneme, že níže uvedený kód - odvar bottlenecku z jedné reálné javovské aplikace později přepsané do Go - je high-level. Takže vyzývám všechny, co si myslí, že umí Javu, a mají pět minut volného času, aby předvedli, jaký kód v Javě bude stejně rychlý. Porovnám to pak na x86, ARM, MIPSu a PowerPC.
class Complex {
public:
double re;
double im;
Complex(double r, double i) : re(r), im(i) {}
Complex operator+(const Complex& x) const {
return Complex(re + x.re, im + x.im);
}
};
...
std::vector<Complex> list;
for (auto y = Complex(0, 0); y.re < 10'000; y = Complex(y.re + 0.0001, y.im + 0.0001)) {
list.emplace_back(y);
}
auto x = Complex(0, 0);
for (const auto& y : list) { x = x + y; }
std::cout << x;
V Javě to na rozdíl od C# naráží na absenci hodnotových typů a na absenci specializace generik. Tj. hádám, že v Javě bude třeba udělat specializovaný seznam pro třídu Complex; uvnitř takový seznam může být implementován jako dvě pole doublů.
-
Doufám, že se shodneme, že níže uvedený kód - odvar bottlenecku z jedné reálné javovské aplikace později přepsané do Go - je high-level. Takže vyzývám všechny, co si myslí, že umí Javu, a mají pět minut volného času, aby předvedli, jaký kód v Javě bude stejně rychlý. Porovnám to pak na x86, ARM, MIPSu a PowerPC.
class Complex {
public:
double re;
double im;
Complex(double r, double i) : re(r), im(i) {}
Complex operator+(const Complex& x) const {
return Complex(re + x.re, im + x.im);
}
};
...
std::vector<Complex> list;
for (auto y = Complex(0, 0); y.re < 10'000; y = Complex(y.re + 0.0001, y.im + 0.0001)) {
list.emplace_back(y);
}
auto x = Complex(0, 0);
for (const auto& y : list) { x = x + y; }
std::cout << x;
V Javě to na rozdíl od C# naráží na absenci hodnotových typů a na absenci specializace generik. Tj. hádám, že v Javě bude třeba udělat specializovaný seznam pro třídu Complex; uvnitř takový seznam může být implementován jako dvě pole doublů.
Pravda. Čili je to naopak, než co tu opakovaně (nesmyslně) zaznělo: V Javě, ne C++, se musí za účelem dosažení řádově srovnatelné rychlosti "prasit".
-
Porovnám to pak na x86, ARM, MIPSu a PowerPC.
A tak se deje, ze vsichni, pokud neni opravdu zbyti (hry*, embeded), voli variantu malinko pomalejsi aplikaci + vice pameti (ktera je nyni smesne levna) a mene programovani (ktere je stale velmi drahe).
???
Pravda. Čili je to naopak, než co tu opakovaně (nesmyslně) zaznělo: V Javě, ne C++, se musí za účelem dosažení řádově srovnatelné rychlosti "prasit".
Jste si to spatne interpretoval - pokud chcete optimalizovat kdekoliv, tak spadnete k praseni. Pokud vyberete specifickou ulohu, u ktere z vlastnosti technologie vyplyva neefektivita... Uplne stejne se to muze udelat i naopak a "shodit" nejen C++ ale jakykoliv jazyk, jak ze jsou nevykone.
Pokud tohle povazujete za produkcni kod (reagujete na muj prispevek, takze asi ano), tak stejne pouzijete specializovanou knihovnu a neresite to takto kulatenim kola. Ocekavate, ze Java implementace bude pomalejsi, ale to jsem ja v prispevku, na ktery reagujete napsal, ze to tak casto bude :D. Rozdil je v tom, pokud bude opravdu rozdil ve vykonu i s pouzitim spec. knihovny, ze v Jave to zboucha kdejaky stredoskolak za chvilku, kdezto v C++ si za to reknou trochu vic a chvilka to byt nemusi. Vyhoda je, ze v Jave casto jen z JITu dostanete zadarmo vykon, pro ktery musite v C++ "makat".
-
Porovnám to pak na x86, ARM, MIPSu a PowerPC.
A tak se deje, ze vsichni, pokud neni opravdu zbyti (hry*, embeded), voli variantu malinko pomalejsi aplikaci + vice pameti (ktera je nyni smesne levna) a mene programovani (ktere je stale velmi drahe).
???
Pravda. Čili je to naopak, než co tu opakovaně (nesmyslně) zaznělo: V Javě, ne C++, se musí za účelem dosažení řádově srovnatelné rychlosti "prasit".
Jste si to spatne interpretoval - pokud chcete optimalizovat kdekoliv, tak spadnete k praseni. Pokud vyberete specifickou ulohu, u ktere z vlastnosti technologie vyplyva neefektivita... Uplne stejne se to muze udelat i naopak a "shodit" nejen C++ ale jakykoliv jazyk, jak ze jsou nevykone.
Pokud tohle povazujete za produkcni kod (reagujete na muj prispevek, takze asi ano), tak stejne pouzijete specializovanou knihovnu a neresite to takto kulatenim kola. Ocekavate, ze Java implementace bude pomalejsi, ale to jsem ja v prispevku, na ktery reagujete napsal, ze to tak casto bude :D. Rozdil je v tom, pokud bude opravdu rozdil ve vykonu i s pouzitim spec. knihovny, ze v Jave to zboucha kdejaky stredoskolak za chvilku, kdezto v C++ si za to reknou trochu vic a chvilka to byt nemusi. Vyhoda je, ze v Jave casto jen z JITu dostanete zadarmo vykon, pro ktery musite v C++ "makat".
Na mnohých příkladech je jasně vidět, že JIT mnoho výkonu nepřináší, a je jedno, je-li to způsobeno nedostatkem jazyka, nebo posunutým periheliem Merkuru. Knihovna nebyla použita schválně, a specializovaný seznam pro komplexní čísla v ní stejně není.
V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.
P.S. Rád si počkám na high-level kód v Javě "shazující" C++ (ale budu čekat dlouho, neb neexistuje, opět šlo jen o mlácení prázdné slámy...).
-
Vyhoda je, ze v Jave casto jen z JITu dostanete zadarmo vykon, pro ktery musite v C++ "makat".
Moje zkušenost v Linuxu je taková, že i triviální čistě aritmetický kód (bez nadměrných přístupů k memberům a k prvkům polí) je rychlejší v C++ než v Javě. To ale silně závisí na JIT a na překladači C++. U kompilátoru C++ nezáleží na časové náročnosti samotného překladu, záleží jen na výsledném strojovém kódu. JIT musí zvolit kompromis mezi časem překladu a výsledkem.
Naopak "makat" a dělat prasárny musím v Javě, aby výkonově dohnala přehledný ručně neoptimalizovaný kód v C++. Např. se to týká práce s binárními formáty, jak už tu někdo zmínil.
-
V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.
Microsoft už na to asi přišel, protože v jeho novém jazyce Cx pro WinRT je GC nahrazen počítáním referencí, kompiluje se do strojového kódu a hlavní API je stařičký COM.
-
Vyhoda je, ze v Jave casto jen z JITu dostanete zadarmo vykon, pro ktery musite v C++ "makat".
Moje zkušenost v Linuxu je taková, že i triviální čistě aritmetický kód (bez nadměrných přístupů k memberům a k prvkům polí) je rychlejší v C++ než v Javě. To ale silně závisí na JIT a na překladači C++. U kompilátoru C++ nezáleží na časové náročnosti samotného překladu, záleží jen na výsledném strojovém kódu. JIT musí zvolit kompromis mezi časem překladu a výsledkem.
Naopak "makat" a dělat prasárny musím v Javě, aby výkonově dohnala přehledný ručně neoptimalizovaný kód v C++. Např. se to týká práce s binárními formáty, jak už tu někdo zmínil.
Pro C++ doporučuju clang, překládá rychleji než GCC a generuje kód pro všechny možné architektury (díky LLVM).
-
V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.
Microsoft už na to asi přišel, protože v jeho novém jazyce Cx pro WinRT je GC nahrazen počítáním referencí, kompiluje se do strojového kódu a hlavní API je stařičký COM.
To jo, ale to RC v podání MS je docela tragédie. Ono celé WinRT je dost podivné, knihovny jsou nativní, ale s overheadem se volají z .NET nebo dokonce JS. Už aby byl na Windows Swift :)
-
V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.
Microsoft už na to asi přišel, protože v jeho novém jazyce Cx pro WinRT je GC nahrazen počítáním referencí, kompiluje se do strojového kódu a hlavní API je stařičký COM.
Počítání referencí bývá obecně pomalejší než tracing GC. Viz třeba Taking Off the Gloves with Reference Counting Immix (http://research.microsoft.com/pubs/202163/rcix-oopsla-2013.pdf).
Nicméně Microsoft kromě RyuJITu pracuje i na projektu LLILC (https://github.com/dotnet/llilc) (LLVM based MSIL Compiler).
-
To jo, ale to RC v podání MS je docela tragédie. Ono celé WinRT je dost podivné, knihovny jsou nativní, ale s overheadem se volají z .NET nebo dokonce JS. Už aby byl na Windows Swift :)
Já jsem měl právě pocit, že WinRT jde udělat krom .NET i nativně v Cx nebo v C++ a pak je to normální binární EXE volající DLL a COM, jako hra pro DirectX. Je to ale jen pocit. Přiznám ale, že jsem to zatím prakticky neověřoval a možná ani nebudu. Protože po hrubém prostudování API jsem došel k závěru, že pro mou aplikaci stačí Win32 + DirectX s targetováním Windows 7 a speciální port pro Windows 8 nic extra nepřinese.
-
Nechci bejt pedant, ale počítaní referencí JE GC ... A to že je pomalejší je podobná blbost jako to že to není GC. Když naivní implementaci RC porovnáváš s super hyper generačním tracing GC, je jasný kdo vyhraje. Když ale misto naivni implementace RC použiješ nějakou silně optimalizovanou implementaci, a že takový sou, vykon bude stejný, s tím rozdílem že RC bude mít minimální latenci.
-
V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.
Microsoft už na to asi přišel, protože v jeho novém jazyce Cx pro WinRT je GC nahrazen počítáním referencí, kompiluje se do strojového kódu a hlavní API je stařičký COM.
Počítání referencí bývá obecně pomalejší než tracing GC. Viz třeba Taking Off the Gloves with Reference Counting Immix (http://research.microsoft.com/pubs/202163/rcix-oopsla-2013.pdf).
Nicméně Microsoft kromě RyuJITu pracuje i na projektu LLILC (https://github.com/dotnet/llilc) (LLVM based MSIL Compiler).
Je pravda, že ve WinRT je RC pomalé (a nejen RC), až je skoro nepoužitelné. Rychlé RC vyžaduje především velmi dobrou statickou analýzu kódu. Některé implementace mají i runtime optimalizaci (inspekce stacku), ale statická analýza (tj. v čase překladu) je základ.
(P.S. GC je rychlostí řádově srovnatelné s RC jen tehdy, má-li k dispozici cca. 4x více paměti, jinak výkon rapidně klesá. Nemusí to být vždy problém, ale třeba na RPi...)
-
Nechci bejt pedant, ale počítaní referencí JE GC ... A to že je pomalejší je podobná blbost jako to že to není GC. Když naivní implementaci RC porovnáváš s super hyper generačním tracing GC, je jasný kdo vyhraje. Když ale misto naivni implementace RC použiješ nějakou silně optimalizovanou implementaci, a že takový sou, vykon bude stejný, s tím rozdílem že RC bude mít minimální latenci.
jistě, správně mělo být něco jako "tracing GC"
-
To jo, ale to RC v podání MS je docela tragédie. Ono celé WinRT je dost podivné, knihovny jsou nativní, ale s overheadem se volají z .NET nebo dokonce JS. Už aby byl na Windows Swift :)
Já jsem měl právě pocit, že WinRT jde udělat krom .NET i nativně v Cx nebo v C++ a pak je to normální binární EXE volající DLL a COM, jako hra pro DirectX. Je to ale jen pocit. Přiznám ale, že jsem to zatím prakticky neověřoval a možná ani nebudu. Protože po hrubém prostudování API jsem došel k závěru, že pro mou aplikaci stačí Win32 + DirectX s targetováním Windows 7 a speciální port pro Windows 8 nic extra nepřinese.
Jen upřesním, že žádné Cx neexistuje, jen C++/CX, což je C++ s rozšířenou syntaxí z C++/CLI. Jinak ano, překládá se do nativního kódu.
-
No oni klasické GC navíc defragmentují paměť. Je to možné hlavně proto, že mají pod kontrolou všechny pointery. Měl jsem v C++ napsaný jednoduchý GC který dynamicky udržoval kostru v grafech referencí a tedy fungoval i s cykly (spouštěl se, jen když někdo zrušil referenci, která byla označena jako kostra grafu, a tehdy se snažil sestavit novou kostru a uvolnit všechny objekty, které se ocitly z kostry nedosažitelné), ale nepřišlo mi, že by byl rychlejší. Ony to totiž zdržují zejména alokace, tedy hledání volného místa ve fragmentované paměti a dealokace, tedy update tabulky volného místa.
V čistem C++ nejde moc dobře pod rukama programu defragmentovat paměť. Díky existenci raw pointerů nemám jistotu, že s pamětí zrovna někdo nepracuje (a i přes chytré ukazatele se raw pointery používaji, takovým nejtypičtějším raw pointerem je this)
-
Nechci bejt pedant, ale počítaní referencí JE GC ... A to že je pomalejší je podobná blbost jako to že to není GC. Když naivní implementaci RC porovnáváš s super hyper generačním tracing GC, je jasný kdo vyhraje. Když ale misto naivni implementace RC použiješ nějakou silně optimalizovanou implementaci, a že takový sou, vykon bude stejný, s tím rozdílem že RC bude mít minimální latenci.
Jak jsem psal, dobrá statická analýza zrychlí RC natolik, že si člověk overheadu správy paměti ani nevšimne. Latence je samozřejmě nižší a hlavně se hodně snižuje "high water mark". Ideální pro embedded apod. Jinak GC je i žádný úklid paměti, jak se lze (se vší vážností) dočíst na Wikipedii. To jen tak pro usmání. Jinak já taky občas zapomenu napsat "tracing" a píšu jen "GC". Snad si přesto rozumíme.
-
No oni klasické GC navíc defragmentují paměť. Je to možné hlavně proto, že mají pod kontrolou všechny pointery. Měl jsem v C++ napsaný jednoduchý GC který dynamicky udržoval kostru v grafech referencí a tedy fungoval i s cykly (spouštěl se, jen když někdo zrušil referenci, která byla označena jako kostra grafu, a tehdy se snažil sestavit novou kostru a uvolnit všechny objekty, které se ocitly z kostry nedosažitelné), ale nepřišlo mi, že by byl rychlejší. Ony to totiž zdržují zejména alokace, tedy hledání volného místa ve fragmentované paměti a dealokace, tedy update tabulky volného místa.
V čistem C++ nejde moc dobře pod rukama programu defragmentovat paměť. Díky existenci raw pointerů nemám jistotu, že s pamětí zrovna někdo nepracuje (a i přes chytré ukazatele se raw pointery používaji, takovým nejtypičtějším raw pointerem je this)
To je sice pravda, ale týká se to jen konzervativních GC. Ty asi nebyly myšleny (protože je jasné, že jsou pomalejší).
-
V širším kontextu se ukazuje, že jazyky s VM jsou slepou uličkou vývoje a připravily nás o celou jednu dekádu.
Microsoft už na to asi přišel, protože v jeho novém jazyce Cx pro WinRT je GC nahrazen počítáním referencí, kompiluje se do strojového kódu a hlavní API je stařičký COM.
Počítání referencí bývá obecně pomalejší než tracing GC. Viz třeba Taking Off the Gloves with Reference Counting Immix (http://research.microsoft.com/pubs/202163/rcix-oopsla-2013.pdf).
Nicméně Microsoft kromě RyuJITu pracuje i na projektu LLILC (https://github.com/dotnet/llilc) (LLVM based MSIL Compiler).
Ten článek je nádherná názorná ukázka, proč nedělat věci složitě, když to jde mnohem jednodušeji. Pro RC připadá v úvahu několik úrovní optimalizace a i bez "deferred RC" a podobných podivností lze dosáhnout téměř úplné eliminace. Což ovšem neznamená, že to tak každá implementace má (např. Swift má co dohánět). Je to hodně low-level magie, ale celkem poučná (když to člověk pochopí).
-
Když ale misto naivni implementace RC použiješ nějakou silně optimalizovanou implementaci, a že takový sou, vykon bude stejný, s tím rozdílem že RC bude mít minimální latenci.
V tom článku pochopitelně porovnávají ty nejlepší implementace RC (k roku 2013) a výkon není stejný.
Pokud znáte nějaký novější článek, kde už RC dohnalo tracing kolektory, tak můžete dát odkaz.
-
Když ale misto naivni implementace RC použiješ nějakou silně optimalizovanou implementaci, a že takový sou, vykon bude stejný, s tím rozdílem že RC bude mít minimální latenci.
V tom článku pochopitelně porovnávají ty nejlepší implementace RC (k roku 2013) a výkon není stejný.
Pokud znáte nějaký novější článek, kde už RC dohnalo tracing kolektory, tak můžete dát odkaz.
Článek ne, ale zdroják překladače ObjC. Když to shrnu:
1. Dělá se escape analýza a co nezdrhne, jde na stack (Go to tak dělá standardně, čímž dost ulehčuje svému (tracing) kolektoru).
2. Dělá se statická analýza nepotřebných Xrementů (X=ink|dek), ty se vyhodí. Tímto se ušetří nejvíc.
3. Runtime optimalizace na stacku eliminuje Xrementy. Doporučuji vyhledat autoreleaseReturnValue a retainAutoreleasedReturnValue. Tímto se optimalizuje předávání objektů po stacku nahoru (po stacku dolů se triviálně nic aktualizovat nemusí).
Autoři onoho článku trochu zaspali dobu, deferred RC je přes dvacet let stará technika určená pro algebraické datové struktury. A o statické analýze asi nikdy neslyšeli.
Stačí si napsat kód vytvářející hodně objektů v cyklu a něco s nimi dělat. Neoptimalizovaný překlad do LLVM IR má na polovině řádků aktualizaci čítače referencí. To by opravdu zdržovalo (a právě odtud pramení ten nešťastný mýtus, že RC je pomalé). Po optimalizaci nebude aktualizace skoro nikde, jen u přiřazení do nějakého vnějšího objektu, typicky kolekce.
-
Největší problém reference countingu je obecně sdílení jedné proměnné mezi jádry procesoru. Je třeba používat interlocked increment/decrement. Ve svém kódu jsem to řešil tím, že objekt si eviduje, zda je sdílený mezi vlákny nebo ne, a pokud ne, pak se použije normální přičítání, které je rychlejší. Ale když v tom člověk udělá chybu, pak crash.
Teď testuju jiný způsob, kdy místo počítání referencí loguju to thread-local bufferu seznam všech pointerů, kde se mění reference. Jakmile buffer dojde, vezmu globální zámek, projdu buffer, upravím všechny countery, ty které dosáhnou nuly uvolním, vrátím globální zámek. Totéž se udělá před ukončení threadu. Ale nemám ještě žádné testy. Mělo by to mít výhodu, že evidování referencí si provádí každý vlákno samo, nevýhodu, že uvolnění objektu může dojít mnohem později, jestli vůbec (když při běhu nedojde k naplnění bufferu a thread nikdy neskončí)
-
Největší problém reference countingu je obecně sdílení jedné proměnné mezi jádry procesoru. Je třeba používat interlocked increment/decrement. Ve svém kódu jsem to řešil tím, že objekt si eviduje, zda je sdílený mezi vlákny nebo ne, a pokud ne, pak se použije normální přičítání, které je rychlejší. Ale když v tom člověk udělá chybu, pak crash.
Teď testuju jiný způsob, kdy místo počítání referencí loguju to thread-local bufferu seznam všech pointerů, kde se mění reference. Jakmile buffer dojde, vezmu globální zámek, projdu buffer, upravím všechny countery, ty které dosáhnou nuly uvolním, vrátím globální zámek. Totéž se udělá před ukončení threadu. Ale nemám ještě žádné testy. Mělo by to mít výhodu, že evidování referencí si provádí každý vlákno samo, nevýhodu, že uvolnění objektu může dojít mnohem později, jestli vůbec (když při běhu nedojde k naplnění bufferu a thread nikdy neskončí)
To vypadá jako objevení dvou kol. Stařičký NeXTstep měl flag single-/multithreaded. A OpenStep zavedl vláknově lokální autorelease pooly. Obé už je bohužel legacy technology.
-
1. Dělá se escape analýza a co nezdrhne, jde na stack (Go to tak dělá standardně, čímž dost ulehčuje svému (tracing) kolektoru).
Tohle JVM běžně dělají, myslím, že i Jikes RVM to umí - tj. očekával bych, že pokud to nevypnuli, tak to dělají.
2. Dělá se statická analýza nepotřebných Xrementů (X=ink|dek), ty se vyhodí. Tímto se ušetří nejvíc.
Pro haldu toto implementují (říká se tomu update coalescing) a stack vůbec nepočítají.
-
To vypadá jako objevení dvou kol. Stařičký NeXTstep měl flag single-/multithreaded. A OpenStep zavedl vláknově lokální autorelease pooly. Obé už je bohužel legacy technology.
Vsadim se, že každý mluví o něčem jiném. Jestli ten flag měl per object, pak možná, ale neberu to jako vymýšlení kola, spíš jako řešení problému. Autorelease pool se obávám, že je něco jiného. Log změn referencí si přestav jako dva statické buffery pointerů, do jednoho píšu pointery u kterých se zvýšila reference do druhého u kterých se snížila reference. Jakmile jeden z nich je přeplněn, pak s jedním zámkem aktualizuju všechny reference a buffery resetuju. Mělo by to doufám snížit množství LOCKů sběrnice. Změna reference by měla být stejně rychlá jako singlethread reference counting a přitom MT safe.
PS: nenárokuju si patent, určitě to už někdo vymyslel a používá, já řeším pouze určitý problém
-
Teda pánové, to nemáte na Silvestra lepší zábavu? Ale když už, měl bych jen takový lama dotaz. Když je tedy C++ rychlejší než Java, jak na vývoj tak rychlost výsledné apky, jak tu dokazuje Zboj, proč se tedy tak hojně Java používá? Je to tím, že je pro ni více knihoven na vše možné, než pro C++ a tím pádem je vývoj na ni přeci jen rychlejší, nebo je Java jen takový omyl, takové Cimrmanovské "tudy ne, přátelé"? Jinak já mám Javu rád. Neptejte se proč, když máte něco/někoho rádi, nehledejte v tom logiku..
-
To vypadá jako objevení dvou kol. Stařičký NeXTstep měl flag single-/multithreaded. A OpenStep zavedl vláknově lokální autorelease pooly. Obé už je bohužel legacy technology.
Vsadim se, že každý mluví o něčem jiném. Jestli ten flag měl per object, pak možná, ale neberu to jako vymýšlení kola, spíš jako řešení problému. Autorelease pool se obávám, že je něco jiného. Log změn referencí si přestav jako dva statické buffery pointerů, do jednoho píšu pointery u kterých se zvýšila reference do druhého u kterých se snížila reference. Jakmile jeden z nich je přeplněn, pak s jedním zámkem aktualizuju všechny reference a buffery resetuju. Mělo by to doufám snížit množství LOCKů sběrnice. Změna reference by měla být stejně rychlá jako singlethread reference counting a přitom MT safe.
PS: nenárokuju si patent, určitě to už někdo vymyslel a používá, já řeším pouze určitý problém
Jasně, není to úplně to samé, autorelease pool je jen pro dekrementy a není to buffer, nýbrž spojový seznam. Ale podobnost není čistě náhodná :)
-
Teda pánové, to nemáte na Silvestra lepší zábavu? Ale když už, měl bych jen takový lama dotaz. Když je tedy C++ rychlejší než Java, jak na vývoj tak rychlost výsledné apky, jak tu dokazuje Zboj, proč se tedy tak hojně Java používá? Je to tím, že je pro ni více knihoven na vše možné, než pro C++ a tím pádem je vývoj na ni přeci jen rychlejší, nebo je Java jen takový omyl, takové Cimrmanovské "tudy ne, přátelé"? Jinak já mám Javu rád. Neptejte se proč, když máte něco/někoho rádi, nehledejte v tom logiku..
Všechny jazyky s VM jsou cimrmanovské "tudy ne" ;)
-
1. Dělá se escape analýza a co nezdrhne, jde na stack (Go to tak dělá standardně, čímž dost ulehčuje svému (tracing) kolektoru).
Tohle JVM běžně dělají, myslím, že i Jikes RVM to umí - tj. očekával bych, že pokud to nevypnuli, tak to dělají.
2. Dělá se statická analýza nepotřebných Xrementů (X=ink|dek), ty se vyhodí. Tímto se ušetří nejvíc.
Pro haldu toto implementují (říká se tomu update coalescing) a stack vůbec nepočítají.
1. Jenže v JVM to funguje mizerně, viz můj kód výše v tomto threadu (.NET to má implementované slušně).
2. Ale coalescing je něco jiného.
-
Teda pánové, to nemáte na Silvestra lepší zábavu?
Ne, jsem "dobrý programátor", tedy aspoň podle kritéria uživatele Dobřety.
-
1. Dělá se escape analýza a co nezdrhne, jde na stack (Go to tak dělá standardně, čímž dost ulehčuje svému (tracing) kolektoru).
Tohle JVM běžně dělají, myslím, že i Jikes RVM to umí - tj. očekával bych, že pokud to nevypnuli, tak to dělají.
2. Dělá se statická analýza nepotřebných Xrementů (X=ink|dek), ty se vyhodí. Tímto se ušetří nejvíc.
Pro haldu toto implementují (říká se tomu update coalescing) a stack vůbec nepočítají.
1. Jenže v JVM to funguje mizerně, viz můj kód výše v tomto threadu (.NET to má implementované slušně).
2. Ale coalescing je něco jiného.
1. To myslíte ten kód s vektorem a komplexními čísly?
2. Podle wiki (https://en.wikipedia.org/wiki/Reference_counting#Dealing_with_inefficiency_of_updates):
A dramatic decrease in the overhead on counter updates was obtained by Levanoni and Petrank.[4][5] They introduce the update coalescing method which coalesces many of the redundant reference count updates. Consider a pointer that in a given interval of the execution is updated several times. It first points to an object O1, then to an object O2, and so forth until at the end of the interval it points to some object On. A reference counting algorithm would typically execute rc(O1)--, rc(O2)++, rc(O2)--, rc(O3)++, rc(O3)--, ..., rc(On)++. But most of these updates are redundant. In order to have the reference count properly evaluated at the end of the interval it is enough to perform rc(O1)-- and rc(On)++. The rest of the updates are redundant.
Což mi přijde jako to, co jste popsal.
-
Teda pánové, to nemáte na Silvestra lepší zábavu? Ale když už, měl bych jen takový lama dotaz. Když je tedy C++ rychlejší než Java, jak na vývoj tak rychlost výsledné apky, jak tu dokazuje Zboj, proč se tedy tak hojně Java používá? Je to tím, že je pro ni více knihoven na vše možné, než pro C++ a tím pádem je vývoj na ni přeci jen rychlejší, nebo je Java jen takový omyl, takové Cimrmanovské "tudy ne, přátelé"? Jinak já mám Javu rád. Neptejte se proč, když máte něco/někoho rádi, nehledejte v tom logiku..
To já nevím, ale základem pokroku je, že lidé zkouší slepé uličky a často neexistuje univerzální pravda.
-
1. Dělá se escape analýza a co nezdrhne, jde na stack (Go to tak dělá standardně, čímž dost ulehčuje svému (tracing) kolektoru).
Tohle JVM běžně dělají, myslím, že i Jikes RVM to umí - tj. očekával bych, že pokud to nevypnuli, tak to dělají.
2. Dělá se statická analýza nepotřebných Xrementů (X=ink|dek), ty se vyhodí. Tímto se ušetří nejvíc.
Pro haldu toto implementují (říká se tomu update coalescing) a stack vůbec nepočítají.
1. Jenže v JVM to funguje mizerně, viz můj kód výše v tomto threadu (.NET to má implementované slušně).
2. Ale coalescing je něco jiného.
1. To myslíte ten kód s vektorem a komplexními čísly?
2. Podle wiki (https://en.wikipedia.org/wiki/Reference_counting#Dealing_with_inefficiency_of_updates):
A dramatic decrease in the overhead on counter updates was obtained by Levanoni and Petrank.[4][5] They introduce the update coalescing method which coalesces many of the redundant reference count updates. Consider a pointer that in a given interval of the execution is updated several times. It first points to an object O1, then to an object O2, and so forth until at the end of the interval it points to some object On. A reference counting algorithm would typically execute rc(O1)--, rc(O2)++, rc(O2)--, rc(O3)++, rc(O3)--, ..., rc(On)++. But most of these updates are redundant. In order to have the reference count properly evaluated at the end of the interval it is enough to perform rc(O1)-- and rc(On)++. The rest of the updates are redundant.
Což mi přijde jako to, co jste popsal.
1. Ano. I když se vyhodí ten vector, Java alokuje na haldě (což nechápu).
2. Tak to jsem to asi popsal špatně, páč to je něco úplně jiného. To slučování (coalescing) eliminuje mezikroky bez efektu, zůstane první a poslední. Já mluvil o elision, tedy nezůstane nic. Typicky když předávám objekt stackem nahoru a vím, že nakonec zanikne, dělám jen alokaci a pak free, žádné RC. Terminologií tracing GC dělám jen sweep. Což je rychlejší. Zastánci generačních GC tvrdí, že takových objektů je většina. A pokud takový objekt někam zdrhá (escape), i tak ušetřím jednu atomickou RC operaci.
-
To slučování (coalescing) eliminuje mezikroky bez efektu, zůstane první a poslední. Já mluvil o elision, tedy nezůstane nic. Typicky když předávám objekt stackem nahoru a vím, že nakonec zanikne, dělám jen alokaci a pak free, žádné RC.
Aha, díky. V tom článku reference ze stacku úplně ignorují a pro reference z heapu dělají pouze to slučování - nikoliv elision - tj. ten jejich výsledek by zřejmě šel vylepšit (pokud by použili nějakou lepší statickou analýzu).
-
To slučování (coalescing) eliminuje mezikroky bez efektu, zůstane první a poslední. Já mluvil o elision, tedy nezůstane nic. Typicky když předávám objekt stackem nahoru a vím, že nakonec zanikne, dělám jen alokaci a pak free, žádné RC.
Aha, díky. V tom článku reference ze stacku úplně ignorují a pro reference z heapu dělají pouze to slučování - nikoliv elision - tj. ten jejich výsledek by zřejmě šel vylepšit (pokud by použili nějakou lepší statickou analýzu).
Přesně to si myslím taky. A úplně obecně, domnívám se, že ať už je o 10% rychlejší RC nebo tracing GC, v běžné aplikaci krátkodobé objekty žijí na zásobníku a ty ostatní se vytvoří, dají do nějaké kolekce a pak jen čtou (což opět nezatíží GC ani RC). Čili nakonec se rozdíl v rychlosti nijak viditelně neprojeví.
-
Moc nechapu, o cem se tu hadate - nekde jsem cetl clanek, ze tracing a reference counting jsou navzajem dualni (analogicke) pristupy, a tudiz pro ne existuji stejne optimalizace, a u obou lze dosahnout stejnych vysledku za stejnych kompromisu.
-
Moc nechapu, o cem se tu hadate - nekde jsem cetl clanek, ze tracing a reference counting jsou navzajem dualni (analogicke) pristupy, a tudiz pro ne existuji stejne optimalizace, a u obou lze dosahnout stejnych vysledku za stejnych kompromisu.
To je ovšem velmi mylné. Jde udělat hybridní GC kombinující oba přístupy, ale stejné optimalizace opravdu nemohou mít. Jako zdroj základních informací nechť poslouží wiki, tam se můžeš o kopě různých optimalizací dočíst. Přičemž pouze jedna z nich vyžaduje statickou analýzu, ty ostatní sou záležitostí běhu. Jako příklad uvedu slučování operací na counterem, pozdržování provedení operací nad counterem, RC bez nutnosti atomických INC a DEC v paralelním prostředí, RC v provedení pro distribuované systémy. Je toho prostě strašná kopa, ale záměrně všichni RC opomíjejí a omlacují všem okolo benchmarky s naivním RC. Je to na stejné úrovni jako dokazovat že tracing GC je pomalí na příkladu naivního mark & sweep ...
Jediný místo kde se RC dnes více používají sou realtime systémy, protože tam je prostě latence kritická.
Další výhoda RC je velmi snadná hardwarová akcelerace. U tracing řešení by to šlo také udělat, bylo by to ale mnohem více složitější ( == dražší procesor)
-
To je ovšem velmi mylné.
LMGTFY - clanek http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon04Unified.pdf (http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon04Unified.pdf) jsem jen prohledl, ale nemam duvod tomu neverit. Asi bude lepsi hadat se primo s autorem. ;-)
-
nejdete si zalozit nove vlakno na rozoberqnie c++ a javy? :)
PS: stastny Novy rok a nech na roote byva viac konstruktivnych debat :P
-
Moc nechapu, o cem se tu hadate - nekde jsem cetl clanek, ze tracing a reference counting jsou navzajem dualni (analogicke) pristupy, a tudiz pro ne existuji stejne optimalizace, a u obou lze dosahnout stejnych vysledku za stejnych kompromisu.
Četl jsem jen abstrakt toho článku. Ale IMO to, že jsou duální ještě neznamená, že na běžných programech jeden nebude lepší než ten druhý.
-
Nechci bejt pedant, ale počítaní referencí JE GC ...
Ano i ne, je samozrejme pravda ze RC je GC, ale je velmi normalni pouzivat pojmy RC a GC jako dva pristupy ke sprave pameti. A ja osobne to uznavam, protoze kazdy vi co je tim mysleno.
A to že je pomalejší je podobná blbost jako to že to není GC. Když naivní implementaci RC porovnáváš s super hyper generačním tracing GC, je jasný kdo vyhraje. Když ale misto naivni implementace RC použiješ nějakou silně optimalizovanou implementaci, a že takový sou, vykon bude stejný, s tím rozdílem že RC bude mít minimální latenci.
To neni pravda, nezalezi jen na samotne implmentaci RC a GC ale i zejmena na typu ulohy. Jsou prace, ktere ukazuji ze i RC muze mit horsi latency nez GC. Osobne si myslim ze nelze prohlasit ani RC ani GC jako vyteze. S tim rozdilem ze GC nabyzi par veci navic, takze pro to jej casto preferuji.
-
Teda pánové, to nemáte na Silvestra lepší zábavu? Ale když už, měl bych jen takový lama dotaz. Když je tedy C++ rychlejší než Java, jak na vývoj tak rychlost výsledné apky, jak tu dokazuje Zboj, proč se tedy tak hojně Java používá? Je to tím, že je pro ni více knihoven na vše možné, než pro C++ a tím pádem je vývoj na ni přeci jen rychlejší, nebo je Java jen takový omyl, takové Cimrmanovské "tudy ne, přátelé"? Jinak já mám Javu rád. Neptejte se proč, když máte něco/někoho rádi, nehledejte v tom logiku..
Duvod proc je Java tak rozsirena je ze je podobna C++, ale ma podle me mnohem lepsi krivku uceni, to znamena ze se ji clovek snadneji nauci a je v ni "produktivnejsi" mnohem rychleji. Stejne plati i pro PHP.
-
Nechci bejt pedant, ale počítaní referencí JE GC ...
Ano i ne, je samozrejme pravda ze RC je GC, ale je velmi normalni pouzivat pojmy RC a GC jako dva pristupy ke sprave pameti. A ja osobne to uznavam, protoze kazdy vi co je tim mysleno.
A to že je pomalejší je podobná blbost jako to že to není GC. Když naivní implementaci RC porovnáváš s super hyper generačním tracing GC, je jasný kdo vyhraje. Když ale misto naivni implementace RC použiješ nějakou silně optimalizovanou implementaci, a že takový sou, vykon bude stejný, s tím rozdílem že RC bude mít minimální latenci.
To neni pravda, nezalezi jen na samotne implmentaci RC a GC ale i zejmena na typu ulohy. Jsou prace, ktere ukazuji ze i RC muze mit horsi latency nez GC. Osobne si myslim ze nelze prohlasit ani RC ani GC jako vyteze. S tim rozdilem ze GC nabyzi par veci navic, takze pro to jej casto preferuji.
Nepochybuju že takové úlohy se najdou, budou ale asi stejně vzácné jako věrný holky ... takže nic co je třeba brát vážněji v úvahu.
Tracing GC maj obvykle nursery, to ale mohou mít i RC GC, takže co se týče kousků který umí jsou na tom silně podobně (stejně).
Říkat GC a RC a přitom myslet pod GC tracing GC a pod RC RC GC je dost blbost. Nepochybuju žě ty chápeš co říkáš, plno idiotů kolem tebe ale tak bystrých nemusí být a poté tě můžou překvapit sračkama na styl: ten jazyk nemá GC, používá pouze RC ...
-
Podle mne: C++ se minimalne v ramci osobniho rozvoje oplati naucit. Problem je, ze c++ je spise zmet nekolika jazyku a ma spousty zakouti - takze casto se v tom clovek zbytecne zamota i kdyz nemusi. C++ se IMHO nepouziva na vsechno prave proto, ze je to az "multiparadigmaticky" (nadnesene) jazyk a zacatecnici(a vlastne i nejen ti) casto zabrednou do temnych zakouti a kombinuji prilis mnoho pristupu(misto jedne vybrane/dohodnute podmnoziny) a vysledek je pak tezce citelny. Takze pokud by ses do toho chtel dostat, tak je vhodne byt "opatrny". Existuji spousty prednasek, i od tvurcu. Knizky(effective c++, effective modern c++), ktere jsou docela pekne napsane a pokud by programatori ve vetsine pripadu pouzivali tyto doporuceni, tak si myslim ze by se C++ pouzivalo stejne dobre a casto jako Java. Nebo by tu pro Javu ani nebylo misto.
Otazka je jestli to budes nekdy potrebovat. Mozna by se oplatilo podivat i po funkcionalnich jazycich. I kdyz osobne si nemyslim, ze by se v dohledne dobe obecne pristup zmenil. Mozne to ovsem je.
-
Nedělám si srandu, ale dokážu v C++ generovat webové stránky stejně snadno jako v PHP. Tedy není to stejný, je to spíš vždycky kombinace vygenerování dat -> šablonovací jazyk -> webvoka. Donedávna jsem používal Seznamácký Teng, teď mám rozpracovaný jiný šablonovací jazyk, ale v zásadě je to fuk, normálně se v tom dá pracovat.
https://qrlogin.cz
https://btcseer.novacisko.cz
oba jsou to C++ webové servery, i když spíš hodně poháněné javascriptem.
-
https://qrlogin.cz
https://btcseer.novacisko.cz
Snad jsi lepsi programator nez grafik a designer...
-
https://qrlogin.cz
https://btcseer.novacisko.cz
Snad jsi lepsi programator nez grafik a designer...
Kdyby to bylo hezký, tak to vypadá nedůvěryhodně :) - ne grafiku a design (grafický) není muj skill, ale pokud se chce někdo graficky vyřádit... qrlogin je na githubu, jeho dílo rád zamerguju a zveřejním.
-
http://www.abclinuxu.cz/blog/Poutnik/2015/12/je-cplusplus-pouzitelny-i-pro-male-projekty
-
Tohle rozhodně doporučuji vidět celé
https://www.youtube.com/watch?v=ltCgzYcpFUI
-
Kdyby to bylo hezký, tak to vypadá nedůvěryhodně :)
Doufám, že to byla ironie :) Vypadá to krásně technokraticky, asi jako když jeden můj známý spravuje věci zásadně izolačkou(funguje to? funguje), ale na běžného uživatele to zrovna dvakrát důvěryhodně nepůsobí, spíš přesně naopak. Tuhle stránku věci by bylo opravdu lepší buď přenechat některému z těch untermensch webdesignerů nebo sáhnout po nějaké free šabloně. Obal prodává a první dojem se nevyplácí podceňovat.
-
Kdyby to bylo hezký, tak to vypadá nedůvěryhodně :)
Doufám, že to byla ironie :) Vypadá to krásně technokraticky, asi jako když jeden můj známý spravuje věci zásadně izolačkou(funguje to? funguje), ale na běžného uživatele to zrovna dvakrát důvěryhodně nepůsobí, spíš přesně naopak. Tuhle stránku věci by bylo opravdu lepší buď přenechat některému z těch untermensch webdesignerů nebo sáhnout po nějaké free šabloně. Obal prodává a první dojem se nevyplácí podceňovat.
Byla to ironie... ale tak nějak jsem spoléhal na open source komunitu, celý projekt je free včetně zdrojáků na githubu, ono totiž sakra jde o hlavně o bezpečnost a já bych netroufnul něco garantovat v uzavřeném projektu a nést za to zodpovědnost. Snahou bylo ukázat funkční a jednoduché řešení. Nic víc. Budu mi stačit, když se to ujme jako systém, který bych chtěl třeba taky používat (třeba při přihlášení do diskuze na rootu :D ) - prostě není cílem něco prodávat, ale spíš demonstrovat technologii. Ale uznávám, že to může vypadat hezčí, jenže já jsem prostě programátor a ne grafik. Nicméně jak píšu, je to free na githubu a každou pěknou úpravu s radosti zamerguju a nasadím (a klidně dopíšu do credits autora, nebo spíš se tam může dopsat sám)