Příspěvky

... než že zná různé paradigma a patterny z hlavy.

No zrovna znalost patternů z hlavy je důležitá. Patterny jsou často se opakující boilerplate kód. Není to žádná business logika, nic co ta aplikace "dělá" z pohledu užívání. Je to nutné zlo, které je potřeba aby se ty zajímavé části daly poskládat dohromady.
A u téhle nezajímavé vaty chcete, aby vývojář koukl, viděl a a dál o tom nemusel přemýšlet a nijak to řešit.

Clanek k tematu na Lupe: "Programátorům jsme zakázali psát kód, některé jsme museli propustit. AI vyhraje, hlásí další české IT firmy"

https://www.lupa.cz/aktuality/programatorum-jsme-zakazali-psat-kod-nektere-jsme-museli-propustit-ai-vyhraje-hlasi-dalsi-ceske-it-firmy/

"Softwarovým inženýrům jsem zakázali psát kód. Některé jsme dokonce museli propustit, protože nebyli schopní na tento způsob práce naskočit. S každou revolucí se povolání mění. Nabíráme ty, kteří jsou ochotní se rozvíjet," řekl Lupě Jozef Petro, výkonný ředitel Sudolabs.

Od "kdo bude pouzivat AI, toho vyrazim" po "kdo bude psat kod sam, toho vyrazim" behem 3 let, jde to rychleji, nez jsem cekal ;-)

Když se kouknete, co ta firma dělá, tak ten citát nezní až tak překvapivě.

Jinak tohle v našem oboru přece není první stříbrná kulka. A vždycky s tím přišla fáze odezdikezdismu následovaná přísunem rozbitých tlam, zlatých padáků a tuny hnusnokódu. A zatím si to vždycky nějak sedlo, jen ten proces nebyl úplně hezký. Je třeba být na pozoru a krýt si záda.

...
Edit: Ale bral bych i "Je to pitomost, nebude to k nicemu, ale naucim se na tom, jak se dela frontend do gcc a taky pro zabavu", to by byl validni duvod.

Tak nějak. Pokud je cílem jazyk samotny, tak to z principu bude srandaprojekt (a tím nechci shazovat srandaprojekty). Ale pokud z toho má vzniknout nějaký prakticky použitelný jazyk, tak tam musí být nějaký jiný cíl. Nějaká potřeba, kterou ten jazyk naplňuje. Proč bych se měl nějakým jazykem vůbec zabývat? Jaké je jeho určení? Co mi to přinese?

A to je otázka, kterou musíte mít zodpovězenou ještě než začnete ten jazyk navrhovat. Protože na základě toho cíle volíte mezi různými kompromisy. A čím víc porušíte princip nejmenšího překvapení (třeba to v jiném threadu zmíněné dělení nulou je brutální mindfuck), tím lepší pro to musíte mít důvod. Protože za to zaplatíte krvavou daň, takže to musí stát za to.

Doufám, že to ještě nesklouzne k diskusím o Bohu a víře, jako nakonec vždycky

mozna by mohl nadesignovat vlastni nabozenstvi. polyteismus i monoteismus uz mame, mohl by vymyslet nekonecny a stale rostouci pocet bozstev.

Rostoucí počet je celkem běžný. S nekonečným počtem můžou naopak ubývat.

OK, tohle je samozřejmě validní reakce. Tak jako tak to chce měřit a přemýšlet a neoptimalizovat předčasně každou instrukci i za cenu nepřehledného kódu atd.

Až na to že alternativní kód v tom videu nikdy nebyl nepřehledný.

Zase pro programátora zvyklého na klasické oop bude jakýkoliv data oriented kód dost nepřehledný. Protože je to úplně jiné paradigma a jiný styl uvažování.

Komentáře - Proč by proboha někdo chtěl do generovaného výstupu dávat komentáře (api request, response, dokumenty atd.)

Kazdy, kdo s tim potom pracuje rucne. Bandwitvh je chybny argument, protoze kdyby byl validní, pak platí, kdo by chtel data posilat v json kdyz muze binarne.

Není to chybný argument. Ale chce to najít rovnovánu mezi velikostí posílaných dat a srozumitelností, když se něco pokazí.

Tohle je záhlaví datového souboru, které má jen minimální režii. JSON tohle nemá, syntaxe se tedy domlouvá mimo datový soubor. Výměna dat mezi různými subjekty je pak žůžo labůžo. Jedna firma mi místo obvyklého XSD poslala dokumentaci ve Wordu. To má být pokrok? Kde je možnost validace před odesláním?

Pro json máte schéma k dispozici taky. Ano, není zabudované přímo v tom souboru. Jenže když používáte xml tak schéma, které vaše aplikace bude používat, taky domlouváte bokem. Sice můžete validovat vůči schématu, které je v tom souboru, ale stejně tak musíte validovat vůči schématu podle kterého je psaná vaše appka. A při odesílání taky nevalidujete vůči schématu v tom odesílaném souboru ale vůči tomu, co očekává druhá strana.

Jaká moje appka? Snad appka příjemce, která data validuje podle stejného schématu jako já při odeslání. Je to totožné schéma.

Tak to napíšu jinak :
Při přijímání validujete podle schématu který očekáváte a dokážete zpracovat.
Při odesílání validujete podle schámatu který očekává druhá strana (nebo jste slíbil posílat).
Ani v jednom případě není hlavní validace podle schématu přibaleného v tom samotném dokumentu. To přibalené schéma dokáže akorát chytit případný nesoulad mezi schématy odesilatele a příjemce. A to neděláte validací xml, ale porovnáním stringu.

Tohle je záhlaví datového souboru, které má jen minimální režii. JSON tohle nemá, syntaxe se tedy domlouvá mimo datový soubor. Výměna dat mezi různými subjekty je pak žůžo labůžo. Jedna firma mi místo obvyklého XSD poslala dokumentaci ve Wordu. To má být pokrok? Kde je možnost validace před odesláním?

Pro json máte schéma k dispozici taky. Ano, není zabudované přímo v tom souboru. Jenže když používáte xml tak schéma, které vaše aplikace bude používat, taky domlouváte bokem. Sice můžete validovat vůči schématu, které je v tom souboru, ale stejně tak musíte validovat vůči schématu podle kterého je psaná vaše appka. A při odesílání taky nevalidujete vůči schématu v tom odesílaném souboru ale vůči tomu, co očekává druhá strana.

Optimalizovat se občas něco musí. Něco.

Přesně, tight loops a věci, které z profileru vylezou jako priority. Amdahlův zákon je zákon.

Bacha, některé věci z profileru nevylezou. Nebo nejsou na první pohled patrné. Největší přínos dají vhodné datové struktury (a nejsou to ty, co by začátečník čekal).
Jak výkon železa roste, pozoruju několik věcí :
- Je stále těžší ho naplno vytížit (třeba relativní cena cache-missu nebo mispredikce větvení stále roste)
- Asymptotická složitost stále víc mate (třeba O(N) hledání v obyčejném poli je rychlé jako prase)

XML je komplexním řešením.
...
Specifikace XML je asi na 14 stránkách. Je to moc?

Neprotiřečí si to trochu?
Ono je xml a xml. Jedno je jednoduchý formát, který toho vlastně ani moc neumí. No a druhé je ekosystém na ten formát navázaných technologií, který je tak rozsáhlý, že ho zase neumí moc lidí.

Místo GC jsem měl napsat uvolnění objektu z paměti, které se neděje bezprostředně po jeho zneplatnění.

Ne neměl. Ještě že jste napsal GC. Takhle víme, že je to omyl. Že mluvíte o nějakém jazyce s GC a ne o C++.
Kdybyste dál psal o zneplatnění objektu, tak se tu točíme v kruhu. Protože v kontextu C++ to moc nedává smysl a zároveň je to příliš obecné.

Jestli je v C++ nějaká featura, která maskuje že se něco děje, tak jsou to destruktory. Ale na druhou stranu, nečekané divočiny může dělat i nějaká "kill" funkce v C.

Destruktory v C++ jsou děs. Místo spuštění už při zneplatnění objektu se spustí až při jeho fyzické likvidaci.

Úplně nerozumím. Co přesně je to zneplatnění objektu? Šlo by dát nějaký příklad?

V destruktoru uvedu uvolnění nějakého prostředku (paměti, souboru, spojení,...). Na objekt už neexistuje pointer, ale stále si ten prostředek drží a může to způsobit deadlock. Destruktor je spuštěn až aktivací garbage collectoru, a to je pozdě. Jiné jazyky tím netrpí.

C++ a garbage collector? Teda, ne, že by se nepoužívali, ale je to trochu nonsens.

Tak kdy se v C++ spouští destruktor?

V C++ jsem se s GC teda ještě nepotkal, jen jsem slyšel nějaké zvěsti. Takže můj dotaz tak nějak trvá.

Destruktor se spouští, když končí život objektu :
- u lokálních proměnných na konci scopu
- membery struktury se likvidují při likvidaci samotné struktury
- u dynamicky alokovaných objektů se destruktor volá při uvolňování toho objektu (v novém idiomatickém c++ když zanikne unique_ptr, nebo poslední shared_ptr co na ně ukazuje)
- V c++ když na objekt zanikne poslední ukazatel a on je pořád naživu, tak už leakne navždycky(není GC, není kdo by to taky uvolnil). Ale při použití smartpointerů už toho není až tak jednoduché dosáhnout.

Jestli je v C++ nějaká featura, která maskuje že se něco děje, tak jsou to destruktory. Ale na druhou stranu, nečekané divočiny může dělat i nějaká "kill" funkce v C.

Destruktory v C++ jsou děs. Místo spuštění už při zneplatnění objektu se spustí až při jeho fyzické likvidaci.

Úplně nerozumím. Co přesně je to zneplatnění objektu? Šlo by dát nějaký příklad?

Tak já jsem slyšel verzi, že to bylo kvůli nepředvídatelnosti. A že jinak jádro není čisté C, je to subset C++, že šikovným featurám se nebrání, ale musí být vidět co se děje. Což vtable tak nějak nesplňuje (o STL nemluvě).

Tak zrovna linux má ručně psané vtable, které fungují skoro stejně jako ty v C++. Akorát je tam přímo to volání skrz pointer na funkci, takže je vidět rozdíl mezi virtuálním a nevirtuálním callem. Jinak je to ale stejná neprůhledná bariéra jak pro člověka, tak pro překladač.

BTW, samotné volání funkcí dokáže "co se děje" skrýt velmi dobře. A ještě lepší na to jsou v C makra.
Jestli je v C++ nějaká featura, která maskuje že se něco děje, tak jsou to destruktory. Ale na druhou stranu, nečekané divočiny může dělat i nějaká "kill" funkce v C.

Osobně to nikomu neberu, ale kde je ta hranice? Za chvíli někdo může psát testy jestli se compiler chová tak jak se chovat má...

A co třeba testovat, jestli se compiler chová tak, jak čekám? V některých jazycích má až překvapivou volnost (třeba C). Tam může update překladače udělat zajímavé věci. Ono třeba stačí aby se trochu změnila ochota inlinovat a nějaká kritická část kódu může být násobně pomalejší.

A překladačových bugů jsem už taky pár potkal. Ale tohle jsou věci tak nepředvídatelné, že tu preventivní test nepomůže.