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 linuxák - Uvádíte, že se při náboru orientujete hlavně podle...
-
Uvádíte, že se při náboru orientujete hlavně podle schopnosti programovat v C ve více vláknech. Upřímně, implementovat multithreading v C je opravdu těžká úloha. Pokud to chcete po juniorech, tak se nedivím, že trpí, tohle je jednoznačně seniorní práce.
S multithreadingem by vám hodně pomohl Rust, neuvažovali jste o tom? Nemyslím tím přepsat všechno do Rustu, ale třeba zkusit implementovat nějakou novou funkcionalitu v Rustu? Taky by vám to mohlo pomoct s náborem, junioři obecně budou raději psát v Rustu než v C.
-
Mimochodom, zaujímalo by ma, aké ťažké je robiť thready v C. V Jave som robil, tam sa s tým robí výborne. V Rust úplne fantasticky. Ak človek nie je bota a dodržiava best practices pri práci s threadmi, tak je to dobré. C je v tomto nejak extra iné? V C som robil najviac tak multiprocessing a to už dávno, na škole.
26. 6. 2025, 11:02 editováno autorem komentáře
-
C je low level a nema nativni podporu threadu. Je to tam jako psat multithreading v asm. Celou implementaci od znova a nebo pouzit netransparentni libky.
Bud je to na rezimu "hurt me plenty" kdy je treba si napsat odznova ( sadismus akademicke sfery / not invented here ) a nebo pouzit extra knihovny - napr. pthread ( velmi spatne debugovatelna slizka) a nad to si dat spoustu rovnaku na ohejbaku jako valgrind nejaky debugger co umi replay atd.
Cele to ziskava zajimavou dimenzi pokud jde vylozene o cas na realtime systemech.A presne kvuli takovym exkrementum nejsem programator.
-
Rekl bych ze helgrind a drd rozhodne nejsou mysleny jen na single thread debug :-) I kdyz je to jak drevena pinzeta na mikrooperace.
... proto nejsem programator. Protoze to nechci resit. Mam k vecem utilitarni pristup. Nebavi mne sahodlouhe diskuse o tom jestli se vec vyrabi nebo tvori. Protoze narozdil od progrosu je na mne brime funkce dane veci. Programatorum casto chybi reality check. V bode A je vase diskuse ktera nema konce a blizi se brzy bodu B. V bode B uz umiraji lidi nebo se sypou miliardy do kanalu. A nase akademicka particka stale tlacha o nicem. To si reste na meetingu s architekty a ne na krizove porade.
Teprve az kdyz to nasi matlalove domatlaji k nepouzitelnosti a _vec_ nenahraditelna jinak nefunguje tak zacinam programovat a zhodnotim co momentalne doba nabizi za nastroje.
Problemy tohoto typu nejsou ani pro mne zajimave a je to jen nudna iterace toho sameho co jsem v minulosti uz videl. -
Nejde ani tak o thready jako takové, pustit thread v C je triviální, ale jde o všechno kolem. V C je nutné řešit memory management, je potřeba hlídat data races, C nemá ani RAII pro úklid prostředků... Je to problém i při single-thread programování (kromě data races) a při multithreadingu roste kognitivní komplexita tak nějak exponenciálně, je opravdu těžké všechno udržet v hlavě a udělat správně.
Rust nabízí řešení pro memory management, úklid prostředků i data races, tohle všechno hlídá překladač. Nechci se účastnit nějaké flamewar Rust versus cokoliv jiného, ale kdybych stál před rozohodnutím, jestli dělat multitreading v C, nebo to začít postupně předělávat do Rustu, tak je to jasná volba. Zvlášť když vím, že v C tam zůstanou bugy, které Rust odchytí (člověk ty chyby prostě udělá), vývoj v C bude pomalý a neseženu vývojáře, protože v C junioři dělat nechtějí.
-
A v rustu chtějí?
V rustu dělají většinou lidi co už dávno znají C a C++ a nechcou pořád řešit ty samé bugy dokola.
Multithreading není problém ani v C nebo C++, ale prostě to vyžaduje disciplínu a hodně testování, což rust tak trochu usnadňuje, protože v safe kódu garantuje to co v C/C++ garantovat nejde.
-
Psal jsem multithreading kód v C v i Rustu. Moje zkušenost je, že v C je to fakt težké a tomu kódu v C moc nevěřím, nemám jistotu, že je správně. Můžeš si samozžejmě myslet, že jsi mnohem lepší než já a máš v C všechno pod kontrolou, to ti neberu. Nicméně ve chvíli, kdy se jedná o týmový projekt, jsi v C v pasti. Tvoji kolegové totiž nebudou tak dobří jako ty a do hlavy ti nevidí. Proto potřebueš nástroj, který bude co nejvíc věcí hlídat za tebe i za tvé kolegy. To je tak všechno, co ti k tomu napíšu.
-
Prvni vec co opravit na skolach - povinny predmet SW engineering. Dalsi vec rizeni velkych sw projektu.
Napriklad ja 25 let delam jednu a tutez chybu. Otacim logiku veci :-P Vetsinou tam kde je nejaka volba o dvou moznostech tak tam je velka sance ze to nekde hluboko sprasim. Bitshift nebo vyhodnocovani xte podminky kde uz na konci netusim jestli mam ozenit draka nebo zabit princeznu.
-
>>Prvni vec co opravit na skolach - povinny predmet SW engineering. Dalsi vec rizeni velkych sw projektu.
Mám pocit, že na odbore softvérové inžinierstvo sa to učí. (mám to vyštudované) Problém je takéto niečo sa nedá nacpať do jedného predmetu, lebo to je dosť široká oblasť. Stačilo by, aby matfyzáci a elektrikári sa naučili poriadne čítať UML-ko a základné princípy návrhu aplikácii.
-
UML je jen komunikační prostředek, společný jazyk, podobně jako třeba ArchiMate nebo BPMN. Znát „slovíčka“ a „gramatiku“ je jedna věc, ale ještě důležitější je ta myšlenka, kterou se tím člověk snaží vyjádřit.
Kdybych si musel vybrat, tak raději neuměle načmáraný obrázek na tabuli nebo papír, který ale popisuje dobrou architekturu nebo algoritmus, než „gramaticky“ správně zapsaný nesmysl.
Nicméně obdobně jako používáme stejná slova a stavíme věty stejným způsobem, tak je dobré i pro to grafické znázornění používat stejný styl, abychom si lépe rozuměli.
-
>>>Kdybych si musel vybrat, tak raději neuměle načmáraný obrázek na tabuli nebo papír, který ale popisuje dobrou architekturu nebo algoritmus, než „gramaticky“ správně zapsaný nesmysl.
UML diagramy majú za sebou aj techniky, ako ich správne vytvoriť. Problém je, že ich tak 90% počitačových ľudí neovláda. (Sorry za ten termín, ale neviem nájsť lepší) Osobne dávam prednosť správne vytvorenému UML diagramu, ktorý je sémanticky aj gramaticky správne a aj jeho obsah je správny. Že musia ľudia, ktorí tieto techniky neovládajú znova vymýšľať koleso, je skôr škoda. (A áno, robil som aj s BPMN na jednom projekte, len je to menej používané)
-
Nemyslím, že je medzi nami nejaký rozpor v pohľade na našu prácu, iba pár detailov.
UML je jen komunikační prostředek, společný jazyk
Čo bolo podľa vás hlavnou silou v rozvoji ľudstva? Asi sa nedá povedať, že komunikačný prostriedok je "jen".
Znát „slovíčka“ a „gramatiku“ je jedna věc, ale ještě důležitější je ta myšlenka, kterou se tím člověk snaží vyjádřit.
A napriek tomu majú ľudia problém s termínmi a termitmi, dojmami a pojmami, "holínkami" a hodinkami... Snažia sa niečo vyjadriť, ale nepoznajú skutočný význam slov, ktoré používajú, tak sa to, čo chcú vyjadriť, často "stratí v preklade".
Nicméně obdobně jako používáme stejná slova a stavíme věty stejným způsobem, tak je dobré i pro to grafické znázornění používat stejný styl, abychom si lépe rozuměli.
UML je podľa mňa značne nedocenené. Z hľadiska jeho vyjadrovacích schopností a toho, čo prináša samo o sebe. Bez tých ďalších nadväzujúcich vecí ako boli MDA alebo vykonávateľlé UML a ďalšie podobné pokusy, tie som vo svojej poznámke vôbec nebral do úvahy.
V tejto súvislosti si myslím, že jeden z najväčších problémov v programovaní je to, že ľudia rozmýšľajú a komunikujú v jazyku, v ktorom implementujú.
-
Jenomze ten predmet bych radi videl i na pribuznych oborech. Jako treba "Aplikovana informatika","Manazerska informatika", "Teoreticka informatika", Bio/Chem/Med informatika a jine. Mel jsem tu i matfyzaka ktery studoval neco jako aplikovane algoritmy. Velmi sikovny clovek ale totalne nemozny co se tyce nejake spravy kodu nebo best devel practices.
Vubec nejde o UML. To si muzete zkouset na statictejsi aplikace kde se po navrhu logika zasadne nemeni - typicky banky,embedded, aerospace atd. Jde hlavne o ty zminene principy navrhu aplikaci. A co se tyce rizeni projektu jde o to pochopit specifika rizeni SW vyvoje.
Proc mi manazeri stale dokola opakuji problem s tim ze pokud je projekt pozde tak na nej nahazou vic lidi? Idealne externi hiring bez jakkekoliv vazby na projekt? -
> Proc mi manazeri stale dokola opakuji problem s tim ze pokud je projekt pozde tak na nej nahazou vic lidi?
Pretoze maju pocit, ze pomohli ako len vedeli, aby sa projekt dokoncil v stanovenych parametroch. "Urobili sme vsetko, co sa dalo". To, ze cast toho "vsetko" je kontraproduktivna uz taky problem nie je, kedze na to rec nikdy nepride a keby ano, tak sa to okeca.
Manazment nie je obmedzeny fyzickou realitou okolo seba; ale iba soft vztahmi. Takze ked sa zatlaci/ukeca na jednu aj druhu stranu, tak je to v poriadku. Nie je tam ziadny fyzikalny zakon, ze by to tak neslo, ako to maju napr. inzinieri.
-
> V Jave som robil, tam sa s tým robí výborne
Jak v Javě, tak v C platí, že vytvořit nové vlákno je ta jednoduchá část. Napsat program tak, aby spolehlivě fungoval bez různých race conditions, to je ta složitější část. Bez znalosti použitého memory modelu (jak v C, tak v Javě), se některé věci mohou chovat někdy nepředvídatelně. Zápis do paměti v jednom vlákně nemusí být hned viditelný ostatním vláknům. Dokonce jednotlivé zápisy nemusejí probíhat v přesně stejném pořadí. A ani čtení.
Ano, v Javě máme hromadu pomůcek, jako Futures a Executors, které nás odstíní od největších pastí, pak není nutné používat přímo Thread a řešit synchronizaci na každém rohu. Ale i tady, zvlášť při sdíleném stavu, lze narazit.
