Ideálny programovací jazyk

[Idris]

Měl jsem na mysli hlavně velikost známou až v runtimu. Jedna věc jsou dočasné proměnné. Ty jsou v pohodě, i když najednou nutně potřebujeme registr pro frame pointer. Druhá věc je ale vracení objektu neznámé velikosti hodnotou. Volající neví kolik paměti vyhradit a volaný to taky nezvládne alokovat bez větších problémů. Musel by ten zásobník přeskládat. Neznám žádné volací konvence, které by něco takového uměly.

Já ty lowlevel detaily dobře neznám a C++ jsem viděl naposledy tak před deseti lety, takže mi asi spousta věcí uniká, ale čistě od stolu mě překvapuje, že je to problém. Přijde mi, že by stačily dvě čísla na začátku: velikost Derived a offset Base v rámci Derived. Pokud potřebuju Derived někam zkopírovat, vím jeho velikost a víc nepotřebuju. Pokud potřebuju šahat do Base, vím jeho offset, což je taky všechno, co potřebuju.

Polymorfismus na zásobníku principiálně řešit nejde. Proto je jediný obecně použitelný způsob dělat to, co dělá Go a některé jiné překladače/runtimy: escape analýza a na zásobniku jen to, co nezpůsobí problém. Ono, upřímně, alokací na haldě, které tam skutečně být musí, bývá typicky hodně málo a alokátory jsou natolik efektivní (včetně tracing GC), že autorům překladačů/runtimů nestojí za to se nějakým zásobníkem zabývat. Občas někdo uprasí nějaký šílený hack (nový runtime pro ObjC má intrinziky kolem správy paměti až na úroveň asembleru), ale v 99% případů se to nevyplatí.

[Reklama]

[Mirek Prýmek]

Ok, už asi trochu tuším, o co jde Dík.

[KarelI KarelI]

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í.

[Mirek Prýmek]

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

[Idris]

Rozhodně musí mít GC, ruční správa paměti je ve většině případů špatná věc.

Fakt?

[Reklama]

[Idris]

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

 

[KarelI KarelI]

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.

[KarelI KarelI]

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 = 0Z dokumentace zrovna vidim

Kód: [Vybrat]

var i, j int = 1, 2vždyť to je strašný.
Dále už bylo mnoho napsáno o řešení výjimečných stavů v go...

[Idris]

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.

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á.

[Cikáda]

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ší.

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. Opravdu se mi dlouho v C++ nestalo, že bych měl problém s pamětí a zároveň nemám pocit, že by to kód nějak prasilo.

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.

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.

[nula]

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í.

No lol... tak to urcite.. to je pekna snuska...
Naopak od C++11 se o to neni potreba starat a funguje to. Narozdil od GC jazyku jako java navic i deterministicky, takze neni potreba jakekoli komplikovanejsi veci ojebavat pres manualni spravu pameti. Jak je videt na vetsich komplikovanejsich java projektech.

Jn, problemy, na ktere lze pouzivat ORM.. na to c++ potreba neni, to je pravda.. tam bohate staci python.

[KarelI KarelI]

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.

[KarelI KarelI]

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.

[KarelI KarelI]

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.

[Cikáda]

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".

Ano, ale zdaleka ne všechny musí člověk používat. O tom je C++, neplatím za to, co nepoužívám. A nejkrásnější je na tom, že nikdo nikoho nenutí všechno používat. Takže opravdu se o to programátor starat nemusí.

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.

Proč by se nemělo pracovat se samotnými strukturami? Co je "hodnota třídy"?

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.

V jiných jazycích nejsou potřeba, ale jiné jazyky většinou neposkytují takový výkon. Ony to ty "jiné jazyky" většinou dělají, ale jaksi "pod kapotou", tudíž když to neudělají dobře, tak to nemám jak ovlivnit.

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.

Tak shared_ptr většinou není moc proč používat. Pokud někdo používá shared_ptr, aby nemusel řešit životnost objektů, tak C++ fakt není pro něj. To je jako kupovat si Ferrari s tím, že s ním budu jezdit po poli...