Vlákno názorů k článku Flat assembler: vývojářský nástroj ze staré školy od o6g - assembler je prilis nizkourovnovy, C, Golang jsou podle...

assembler je prilis nizkourovnovy, C, Golang jsou podle me tak akorat a C++, Rust uz to s abstrakci trochu prehaneji.
co si myslite vy o prilisne/nedos­tatecne abstrakci, je objektove programovani zas takova pomoc, nebo templatovani, metaprogramovani, nezdrzuje to spis cloveka?

no to mi pripadne jako tvrzeni, ze pro dopravu je kolo moc pomale a letadlo zase moc velke a blbe se parkuje doma na predzahradce ;) IT je strasne rozsahla oblast a je asi rozdil nekde nasazovat nejaky PIC* a na strane druhe lepit obrovske enterprise systemy. Asi bych si nedovolil rict, co je akorat na tak obrovske skale.

* pro PICy nejaka cecka existuji, samozrejme. Jen je typicke, ze priklady jsou ukazovany pro PIC16 nebo PIC18, proc asi? :)

Na škále dopravních prostředků s kolem a letadlem by mrňavé PICy s 25 bajty RAM a zásobníkem na dvě návratové adresy nejlépe vystihlo "A jak dlouho ještě budete driftovat?"

Rust je příklad jazyka, který (schválně) není OOP, ale některé vlastnosti OO jazyků implementuje (zapouzdření atd.) - osobně nejsem taktéž příznivcem OOP, ale je třeba si položit otázku, co přesně má daná abstrakce řešit a proč bych ji (ne)měl potřebovat. Doporučuju se podívat třeba sem: https://www.thecodedmessage.com/tags/beyond-oop/

Metaprogramování je nástroj jako každý jiný. Nemá smysl si tu otázku pokládat takto obecně.

Golang

Z toho seznamu budu reagovat pouze na golang. Za mě super jazyk v původní podobě. Přesně věděl, kde chce být, co chce řešit a co řešit nechce. Silně a staticky typový jazyk, s velmi snadnou možností si vyrobit vlastní typy. Jméno a Příjmení jsou odlišné datové typy, i když je to string. Funkce přijímající jméno nepřijme příjmení. Nezkompiluje se to. A je to tak správně.

V přednáškách Kevlin Henney vysvětloval, jak tohle použít. Super vysvětlení. Snadno pochopitelné, velmi snadno se potom píšou programy, kde všechno je vlastní datový typ. Krásné jednoduché a velmi kompaktní programy.

Potom přišel někdo, kdo vůbec nepochopil tento princip a přišel s tím, že nutně potřebujeme generika. Tak tam jsou generika. Zcela zbytečně, přidává to další bordel, který tam vůbec nemusí být. A ještě k tomu syntaktický. Kdyby někdo udělal knihovnu pro generika (což jde, protože tam jsou interfaces), tak to nebude komplikovat zdroják.

Před x lety jsem slyšel námitku, že tam nejsou výjimky. No nejsou no, protože vlastně vůbec není jasné, co je to výjimka. Programátor má ošetřit všechny stavy a ne jen jít zlatou cestou. Opět, když se poctivě ošetřují všechny stavy na místě, kde vznikají, výsledkem je pěkný a kompaktní program. A pokud opravdu někdo nutně potřebuje výjimku proto, aby tento error stav mohl nechat probublat vejš, tak tohle v golangu udělá velmi snadno. Není potřeba tam nic cpát. No, takže očekávám, že do deseti let bude mít golang výjimky.

asi jo, ale zase do toho nemichaji jako pejsek s kocickou vsechno tak, jako v C++. Takze Go sice narusta ale zatim nijak zavratne (fingers crossed).

Co je horsi - generika zpusobila, ze uz vyvojari nevedi, jak se funkce prekladaji. Ztraci se tam to kouzlo jazyku C/Go, kde +- lidi tusili, co se deje pod kapotou. U generik ne, tam je pozdnejsi urceni, co a jak se bude prekladat.

Otázka zní, zda vůbec je u Go tohle tak podstatné. Ani programátoři v C to do detailu často nevědí.

tak kdyz rekneme A, tak musime rict i B. Pokud to neni podstatne (a mnohdy neni), tak to neni nahrada za assembler. A pokud to je nekdy podstatne a potrebujeme to vedet (zrovna nedavno se tady resilo preteceni), tak to jazyk nema skryvat, aby to byla nahrada za assembler.

[06g]
Myslim, ze v C++ je to vic o programatorovi jak se rozhodne jej pouzivat, nez o jazyku samotnem. Zrovna C++ nabizi ruzne moznosti, ale nic si sam od sebe primo nevynucuje. (napr v C# mate uz jako vstupni bod programu tridu, podobne v Jave. V C++ porad je to jen funkce). A to i presto, ze se C++ dost meni* a podle meho mineni nekdy trochu zbytecne**.

Jsou programatori, kteri C++ pouzivaji vicemene jako C s prisnejsi typovou kontrolou. A je opacny extrem, kdy kdyz se kod nejezati spicatymi zavorkami, neni to podle nich to prave C++ (je pak super takovy kod cist a jeste vetsi balada je to ladit). Ja jsem toho nazoru, ze vsechno ma svuj cas a sve misto a sablony se maji pouzivat stridme. To vsechno C++ umoznuje.

* A ja se obavam, ze se meni proto, ze B. Stroustrup a lide, kteri maji vliv na vyvoj C++ maji fedry z agresivniho nastupu nekterych radoby nastupcu tohoto jazyka a taky menici se mentalite programatoru. A tak se snazi prizpusobit. Kdyz jsem pred casem cetl vyjadreni Stroustrupa o potrebe vetsi ochrany pameti, delalo se mi nejak nevolno ...

** Napr. Zavedli se anonymni funkce, misto toho, aby se trochu vice propracoval koncept funktoru. Jsem presvedcen, ze vylepsene funktory mohli nabydnout velmi podobne moznosti, jako maji funkce napr. v jazyce Lua. Funktor je objekt. funkce - v C++ - je porad jen funkce, i kdyz umi zdilet kontext.

15. 5. 2024, 23:03 editováno autorem komentáře

C++ má za mě proti C pár velkých výhod
* věci jako std::unique/sha­red_ptr, std::unique_lock a podobné objekty, které vážou uvolnění nějakého zdroje na životnost objektu a je tak těžší udělat memory leak
* dědičnost a abstraktní třídy na to, aby některé objekty šli implementovat dvojím způsobem, třeba pro účely testů, řešení přes tabulky pointerů na funkce v C je dost hnusné

Šablony se občas hodí, ale jejich nadužívání s argumentem, že jsou rychlejší než virtální funkce se mi nelíbí - kód v hlavičkách se překládá pro každý soubor, následně při linkování vypadne jako duplicitní, občas se inlinuje, občas ne a primární problém je často volat funkci miliardkrát, takže přínos šablon je potom jen to, že program běží ještě pomaleji v debugu, dlouho se překládá a hůř se ladí, nehledě na to, že to občas ani není čitelné. Navíc generický kód se bez specializací špatně optimalizuje pro časově kritické operace. Neříkám, že se to občas nehodí.

V neobjektových jazycích jako Julia a Rust jsem psal příliš málo na to, abych je komentoval.