Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - KarelI KarelI

Stran: 1 [2]
16
Vývoj / Re:Ideálny programovací jazyk
« kdy: 10. 05. 2019, 20:11:33 »
Naopak od C++11 se o to neni potreba starat a funguje to. Narozdil od GC jazyku jako java navic i deterministicky

Ještě k té deterministické dealokaci - dobře že to zmiňuješ, protože to názorně ukazuje posunuté myšlení C++ programátorů. Deterministická dealokace je sama o sobě zbytečná, řešený problém si ji sám o sobě nežádá. Ovšem v C++  je to způsob, jak uvolnit zdroje, takže se tak používá na vše. Jenže už se nemyslí na to, že to má neblahý vliv na výkon dealokace. Ta kdyby se nedělala pro každý objekt zvlášť, ale pro větší bloky, tak je to mnohem výhodnější a právě to je moment, ve kterém získává GC navrch - uklízí až když je to nutné, což je v běžných scénářích mnohem výhodnější než se starat o každý mazaný objekt.

17
Vývoj / Re:Ideálny programovací jazyk
« kdy: 10. 05. 2019, 19:49:36 »
Naopak od C++11 se o to neni potreba starat a funguje to.

Na jednoduchých algoritmech možná ano, ale jak to začne být složitější, tak se ukáže, že shared_ptr mají netriviální režii, takže se to přepíše na kombinaci unique a raw pointerů, s tím související redesign aby byla pořešena životnost objektů atd. Prostě není pravda, že není potřeba se starat.

18
Vývoj / Re:Ideálny programovací jazyk
« kdy: 10. 05. 2019, 19:46:30 »
GC (tracing) dává smysl ve spojení s kvalitní escape analýzou, pokud všechno, kde to je technicky možné, alokuju na zásobníku, nemusím toho moc na haldě alokovat a běh GC se pak znatelně neprojeví. Nicméně správa paměti v C++ je taky dost dobře promyšlená.

Když už zmiňuješ GC optimalizace, tak je dobré myslet na to, že new/delete má také nějakou režii a ta má také dopad na výkon. Snaživý C++ programátor o takové režii ví, takže se pustí do věcí jako object pooly apod. čímž si svůj kód dodatečně zaplevelí, algoritmus zesložití a přitom se může lehce stát, že optimalizovaný GC dá mnohem lepší výsledky.

19
Vývoj / Re:Ideálny programovací jazyk
« kdy: 10. 05. 2019, 19:42:18 »
Naopak C++ je ve správě paměti od jedenáctky super. Člověk nad tím má kontrolu a přesto se o moc nemusí starat.
Do jedenáctky byly dva způsoby jak objekt vytvořit a o něco více způsobů jak ho předat parametrem do funkce. Od C++11 je těch způsobů založení 4 a předání nesčetně více. To vše jsou věci, kde musí programátor dělat rozhodnutí, kde se to musí předělávat při refactoringu, kde se to musí nějak řešit při předávání do knihoven apod. Rozhodně bych tak komplexní věc nenazýval "...moc nemusí starat".

Tak bavíme-li se o algoritmu, tak předpokládám, že pracuji s nějakými "strukturami", které se alokují/dealokují samy. Od toho máme konstruktory a destruktory. Zrovna s algoritmy mám v C++ problém z jiných důvodů, než je správa paměti.
V C++ se nepracuje se samotnými strukturami, ale s jejich hodnotami, odkazy, pointery (několika druhů) apod. To sebou nese spoustu rozhodnutí, které v jiných jazycích nejsou vůbec potřeba, nemají (většinou) žádný vztah k řešenému problému a jsou vynuceny jazykem. Bohužel musím dodat, že to co se kde použije je u většiny programátorů čirý cargo cult.

20
Vývoj / Re:Ideálny programovací jazyk
« kdy: 10. 05. 2019, 17:22:11 »
Syntaxe by se měla držet osvědčených zvyků ohledně operátorů, závorek atd., některé nové jazyky to zbytečně prohazují. Dál základní OOP, funkcionální prvky, aby stačilo říct "co" místo "jak". Takže streamy (ale jednodušší než v javě), lambdy, konstantní objekty...

Rozhodně musí mít GC, ruční správa paměti je ve většině případů špatná věc. Stejně tak by se programátor neměl starat o to, zda budou data na stacku nebo heapu, tohle zvládne překladač či runtime dost dobře sám. C++11 jasně ukazuje, že je špatný nápad tím prasit jazyk a že z toho cesta nevede. Smart pointery, move semantika atd. to ve výsledku ještě zhorší.

A bylo by hezké, kdyby měl nějak snadno zvládnuto ORM, JSON, HTTP, prostě napojení na běžné okolní prostředí.
Skoro přesně jsi popsal Go :)

Na to jsem myslel, proto jsem měl napsat, že jediná správná syntax je prefixová, čili
Kód: [Vybrat]
int i = 0
Z dokumentace zrovna vidim
Kód: [Vybrat]
var i, j int = 1, 2
vždyť to je strašný.
Dále už bylo mnoho napsáno o řešení výjimečných stavů v go...

21
Vývoj / Re:Ideálny programovací jazyk
« kdy: 10. 05. 2019, 17:18:25 »
Rozhodně musí mít GC, ruční správa paměti je ve většině případů špatná věc.
Fakt?
Ano. U jednoduchých algoritmů to moc nevadí, ale jakmile je to složitější, tak v konečném důsledku ten GC programátor píše pokaždé znova. Je to v tom algoritmu skryto, zbytečně ho to zesložiťuje a v kombinaci s případnými smartptr to nakonec může být i pomalejší.
Čili otázka není zda GC ano či ne, ale zda má být jednou v runtime nebo ho má psát programátor.

22
Vývoj / Re:Ideálny programovací jazyk
« kdy: 10. 05. 2019, 17:04:18 »
V první řadě je otázka, co to znamená ideální, nejspíš nejde udělat jazyk, který by se hodil na všechno. Ale když vezmu mainstream, tak je rozhodně nejdůležitější, aby byl jednoduchý, asi tak na úrovni javy (i ta má věci navíc, jako je třeba vestavěná synchronizace).

Syntaxe by se měla držet osvědčených zvyků ohledně operátorů, závorek atd., některé nové jazyky to zbytečně prohazují. Dál základní OOP, funkcionální prvky, aby stačilo říct "co" místo "jak". Takže streamy (ale jednodušší než v javě), lambdy, konstantní objekty...

Rozhodně musí mít GC, ruční správa paměti je ve většině případů špatná věc. Stejně tak by se programátor neměl starat o to, zda budou data na stacku nebo heapu, tohle zvládne překladač či runtime dost dobře sám. C++11 jasně ukazuje, že je špatný nápad tím prasit jazyk a že z toho cesta nevede. Smart pointery, move semantika atd. to ve výsledku ještě zhorší.

A bylo by hezké, kdyby měl nějak snadno zvládnuto ORM, JSON, HTTP, prostě napojení na běžné okolní prostředí.

Stran: 1 [2]