Vlákno názorů k článku Zaučování juniorů trvá roky, ale stojí to za to, říká Maria Matějka z projektu BIRD od Franta Kučera - Ten projekt začal v roce 2000. Rust je...
-
Ten projekt začal v roce 2000. Rust je z roku 2012, ale popularitu začal získávat až mnohem později. Jazyk D je z roku 2007. Jazyk Go 2009. Takže tyhle jazyky vůbec nebyly ve hře, protože neexistovaly. A k nějakým postupným přepisům jsem spíš skeptický. V úvahu připadalo C, C++ a Java. Zajímalo by mne, jak vypadalo rozhodování mezi C a C++. Určitě padaly argumenty, že C++ je moc složité a ošklivé, že s „čistým céčkem“ to bude jednodušší a kód srozumitelnější. Bylo by fajn si udělat nějakou upřímnou retrospektivu a vyhodnotit, zda to „čisté céčko“ stálo za to a jestli by SBRM (RAII) v C++ nepřineslo víc užitku. Je to také otázka, jestli se chceme radši potýkat s komplexitou programovacího jazyka, který se používá celosvětově a je k němu dostatek informací, nebo s komplexitou daného projektu, který zná jen pár lidí.
P.S. Případně se může vyjádřit nějaký zapřisáhlý lispař nebo haskellista, jestli by jejich oblíbený jazyk nebyl v tomhle případě lepší volbou :-)
-
Podle mě použít C byla blbost už tehdy. C++ měla být jasná volba. Nejde ani o to používat std kontejnery, ale třeba generika v C++ prostě stojí za to, a jestli potřebuju použít třeba linked list, tak ho chci implementovat jen 1x a ne na to mít plno maker, jak je v C zvykem. 1 implementace se totiž dobře testuje. To samé použití zámků, atd...
Dnes už by podle mě volba padla asi na rust - výkon to má víc než dostatečný na to, jaké garance ten jazyk poskytuje.
Na druhou stranu chtít po nich to do čehokoliv jiného přepsat je podle mě blbost. Já mám taky projekty v C++, které přepisovat do ničeho jiného nebudu - není na to čas ani motivace.
-
Tehdy byla ideologie, že "správný programátor zvládal C, zatímco C++ byla jenom pro ty, kdo neuměli spárovat malloc s free" ...
Výsledkem bylo, že každý C projekt měl svůj framework a způsoby, jak řešit věci, které v C++ byly vyřešené, přirozené, automatické a otestované.
Zajímalo by mě, zda tam byly i technické požadavky, které C++ eliminovaly. Chápu, že C++ má svoje nedostatky a třeba stále chybějící řešení pro supressed exceptions je naprostá katastrofa. Ale udělat projekt násobně komplexnější a pak si stěžovat na neefektivitu a náklady a během 25 let s tím nic neudělat...?
Ano, přepsat je blbost, pokud náklady převáží zisk. Ale tenhle projekt se relativně aktivně vyvíjí a zjevně má s volbou jazyka problémy. V případě přechodu na C++ nebo Rust může být změna postupná. Část může zvládnout LLM, pokud je kolem slušné testování...
-
Na druhej strane, C++ bolo značne pokročilé už vtedy, pre mňa je mílnikom moment, keď Andrei Alexandrescu vydal Modern C++ Design. A on publikoval už predtým, pamätám si kde som v C++ Users Journal čítal o RAII a aj to, kedy som tam bol naposledy. A boli aj ďalšie knihy o tom ako programovať v C++ od ďalších významých autorov. Navyše C++98 už existovalo, to síce nebolo ešte ako C++11, ale už jeho samotná existencia bola veľkou vecou.
-
DannyStříbrný podporovatelJenze on fakticky zacal jeste driv. V roce 2000 byla vydana verze 1.0.0. Copyright info toho prvniho release hovori o roce 1998, kdy i C++98 byla fakt horka novinka, zejo... :)
-
njn :-) Žiadnym spôsobom nekomentujem výber jazyka v tom projekte, iba dávam dodatočný kontext. Alebo aspoň jeho časť, ktorá je mi známa. C++ som v tej dobe používal už niekoľko rokov, tak som to prežíval a nie iba spätne o tom čítal.
Dodatok iba pre úplnosť: Aj pred C++98 pochopiteľne C++ existovalo :-)
27. 6. 2025, 12:13 editováno autorem komentáře
-
Jen doplním, že RAII vymyslel Bjarne Stroustrup v 80. letech. Takže ten náskok mělo C++ oproti C už tehdy.
Já trochu chápu tu snahu držet se „čistého C“ – znamená to menší závislosti, jednodušší kompilátor, jednodušší jazyk, vše jsou jen struktury a funkce, primitivní hodnoty nebo ukazatele na předešlé. Dokud v tom člověk píše malé věci, tak fajn. Je to velký pokrok oproti assembleru (který jiní v té době ještě běžně používali). Ale někdy ta inherentní komplexita řešené úlohy je tak vysoká, že vyhřezne v podobě statisíců nebo milionů řádků aplikačního kódu, které tam být nemusely a které jsou špatně čitelné a obsahují mnoho duplicit. Při použití složitějšího/mocnějšího jazyka, musí sice programátor ovládat ten složitější jazyk, ale ten aplikační kód je pak jednodušší. (pak se to ještě částečně dá řešit nějakou šikovnou knihovnou)
Protiargumentem může být Linux (nebo jiná jádra operačních systémů psaná v C). Jenže to je projekt, který dobře škáluje, protože většinu tvoří ovladače různého hardwaru a autora moc nezajímá, co se děje v jiných subsystémech nebo i jiných ovladačích kolem něj, takže ty řádky jako by pro něj nebyly (kromě pomalejšího sestavení celku). Ale i tak to funguje jen díky obrovské disciplíně a často je těžké udržet v hlavě ten mentální model kódu, nad kterým člověk pracuje.
-
DannyStříbrný podporovatel
A je nejakych ~110 tisic radku mala nebo velka vec? :-) A jinak zrovna Birda bych klidne k tomu kernelu i tim fungovanim v tomto klidne prirovnal, take tam mate ruzne v zasade nezavisle subsystemy... dokonce ani malokdy pouzijete vsechny zaraz.
-
Podľa riadkov sa to asi posudzovať nedá. Aj jednotlivec je schopný vyznať sa vo vyšších desiatkach tisíc riadkov, zvlášť ak je to stabilný projekt, na ktorom pracuje roky alebo dokonca dlhé roky.
Ale záleží aj na tom, aký druh projektu to je, nízkoúrovňové veci sú samozrejme náročnejšie. Takže potom záleží na použitých abstrakciách, ktoré to pochopenie zjednodušujú. Ktoré neviem, či v C sú. Potom štýl písania, testovania, dokumentácie, atď.
Naozaj veľké projekty majú desiatky miliónov riadkov kódu. Niektoré výnimočné majú aj sto a viac.
Takže 110tis. riadkov môže byť podľa zvoleného uhlu pohľadu pokojne najväčší malý projekt alebo najmenší veľký projekt.
-
DannyStříbrný podporovatel
No, ano... tady se ta diskuze trosku rozbredla do abstraktna, ale mejme na pameti, ze clanek se venuje jednomu naprosto exaktne identifikovanemu softwaru, ktery se dlouhe roky stabilne vyjiji. A software je to pomerne specificky - uz tim, co dela a jake jsou na nej kladene pozadavky (krom jineho treba rychlost konvergence s velkymi pocty peeru/prefixu).
