Vlákno názorů k článku Vzdělávání v IT: moc teorie, málo praxe, říkají studenti od Enormoss - Nemám sice VŠ a nejsem programátor. Nicméně občas...

Nemám sice VŠ a nejsem programátor. Nicméně občas něco napíšu v Pythonu, C, a PHP (vše jen jednoduché, žádné krkolomnosti). Baví mě nevíce Python. U C si troufám řící že dokážu číst kód a pochopit jak pracuje - trochu jsem si vylepšil D.J.B Qmail. Bohužel jsem začal s PHP což byla asi největšíc chyba. No nic.

Zajímalo by mě ale, jaký máte názor toto (nevím jak probíhá výuka programování na VŠ, zda tam mají nap. výuku Unix systémů apod.):

Má takový programátor plně chápat jak pracuje systém níže?
Z praxe se mi zdá, že současní programátoři netuší co se děje v systému, když se zavolá např print(), co se stane se správou paměti a co s diskem když potřebuju otevřít soubor atd. Neučí se to, nebo se to dnes navyžaduje?

Pak to může dopadnout tak, že programátor programuje a správce přiděluje více a více paměti virtuálu a CPU, protože to přece je potřeba a je kde brát (ale ono nebude donekonečna).

Poslední dobou mi to připadá, že to je jako ta pověstná digitální demence. Jen používat, používat, používat, ale jak to funguje celé (HW,SW) to je mi fuk.

Z praxe se mi zdá, že současní programátoři netuší co se děje v systému, když se zavolá např print()

1. Řada věcí není přesně specifikovaná a jedná se o implementační detail - je tedy zbytečné se je apriori učit.
2. Dále je řada věcí poměrně komplikovaná (například spuštění Hello world ve vyšším jazyce může vést na volání stovek metod virtuálního stroje).

Ono totiž předčasná optimalizace je také zlo, optimalizovat se mají evidentní průšvihy a ty další až když to funguje a teprve se ukážou. Jinak třeba strávíte hromadu hodin na optimalizaci něčeho, co nakonec průšvih není a milisekunda tam nehraje žádnou roli. V praxi jde pak o peníze vyhozené z okna.

Myslis ze se optimalizaci da nazvat zrychleni neceho o 5 radu? Ja bych to nazval prasetem ktery to napsalo.

Za nasich cias som musel vediet vsetko od toho ako sa vyraba kremikovy procesor cez je ho navh, sposob prace (rozne architektury), assembler, az po OS, uplne vsetko. Potom este samozrejme rozne druhy roznych jazykov, Pascal, C/C++, LISP, Bash, SQL, ...
Samozrejmostou boli rozne druhy IPC ako shared memory, semafory, socket, pipe, file, ... zlaty QNX.
A v tom ze dnesny programatori skutocne nic nevedia o tom ako to bezi pod nejakym rozhranim ma za nasledok ze v niektrych situaciach nechapu preco nieco nefunguje takze v bezvetri sa im dari ale za dazda to uz neustoja.

My měli ještě paralelní realtime Prolog (japonský výmysl) a bylo zajímavé se v tom hrabat. C++ je oproti tomu primitivní jazyk s triviální syntaxí.

Ja je na jednu stranu chápu. Ony technologie jsou dneska hodně složité. Dneska už nevíš kolik taktu ti přesně trvá instrukce, ani embedak už nezná přesně co se děje ve svabech a vmko jazyka si jaksi samo paralelizuje provádění bajtkodu. Takovej progros ani netuší na kterým fs data pristanou a že se data hned po uložení do db nepropisujou. Že než se něco někam zapíše tak mezi drátem a diskem je 30 dalších fyzických a logických urovni. Že disky leží o 15 km dále na nakym logickým fs storage s tisíci parametrama na tuneni.

Na druhou stranu je fakt že by progros měl vědět základy. Jako že OS má jakési diskové cache a že třeba každá databáze má úplně jiné chování a že mít mezi nimi "univerzalni" framework a pak si zmigrovat třeba z sybase na Oracle a z něj na MySQL je fakt totálně mimozni nápad.
Stejně jako chtít stahování zdrojaku přes nezabezpeceny protokol, protože za éry pasnetu to taky tak dělali.
Progrosum prostě chybí dnes už základní it povedomi.

"Progrosum prostě chybí dnes už základní it povedomi."

Nechybí. On totiž (až na vyjímky) z nebe učený nikdo nespadl a dnes je všeho tolik a tak rychle se to mění, že ani není možné, aby měl člověk povědomí o všem.
Ono totiž je otázka, co je vlastně "it povědomí". Plácat o všem, to asi jde, ale mít nějaké "it povědomí" o všem na co se může kdokoliv zeptat, aby ohodnotil něčí "it povědomí", to asi ne

Progros by se nemel divit proc na projekt v rezimu utajeni nemuze stahnout vsechny zdrojaky k sobe a proc pracuje v uzavrene siti.
Progros by mel vedet ze kdyz mu rekne clovek ze na storagi neni misto, ze nemuze jit a argumentovat svemu nadrizenemu hromadou nepouzivanych desktopovych disku ve skladu na odpis.
Progros by mel vedet ze preklada produkt pokazdy na jinem pocitaci s jinymi knihovnami opravdu neni napad a ze je dobre mit jednotne build prostredi.
Progros by mel vedet ze kdyz ta masina na ktere dela neni v cesku ale u nej doma vic jak 3000km daleko, tak ze chvilku trva nez tam ti trpaslici doputuji.
Progros by mel vedet proc neprotlaci 300MB prezentaci k zakaznikovi mailem...

A muzu pokracovat dal.
Ale ma tolerance se dost snizila s praci mezi cizinci. Vazne uz nechci aby kolegove z jedne exoticke zeme zkoumali kde je vga kabel a jak ho nacpat do display portu. Uz je mi znamo ze tihle experti jsou trida v databazich, ale zapojit si dohromady uz jen predinstalovany desktop na to musi mit asistenci. To co zvladne kazda sikovnejsi sekretarka tak oni jsou v koncich.

Samozřejmě, že to má chápat. Na VŠ se to učí. Nicméně podle kódu, ke kterému se člověk dostane, to hodně "programátorů" nezná.

Programátor musí pasivně znát celý počítač na úrovni software, letmé základy hardware a související věci. Tím se rozumí že ho nepřekvapí běžné činnosti, například fungování protokolu TCP/IP.

Právě toto se učí v předmětech které mají v názvu "Operační systémy" - včetně základních komponent linuxového kernelu - minimálně FIT VUT :)

> Z praxe se mi zdá, že současní programátoři netuší co se děje v systému, když se zavolá např print(), co se stane se správou paměti a co s diskem když potřebuju otevřít soubor atd. Neučí se to, nebo se to dnes navyžaduje?

Učí, ale i další věci, které tohle všechno ovlivňují. Asymptotická složitost, zvolená technologie (počínaje knihovnou a konče jazykem/jeho virtuálním strojem).

Že je někdo prase navíc ještě nemusí znamenat, že je neznalý a že někdo něco naprasí ještě nutně neznamená, že je prase. Za optimální kód/technologii ve spoustě případů nedostane vývojář větší odměnu a může to být i naopak. A nezapomeň na to, že dnes spousta programů a systémů je složitějších než dřív, i když zdánlivě dělají totéž. Tím pádem se nerýpají lopatičkou ale bagrem a tomu odpovídá i ta přesnost.

> Pak to může dopadnout tak, že programátor programuje a správce přiděluje více a více paměti virtuálu a CPU, protože to přece je potřeba a je kde brát (ale ono nebude donekonečna).

Četl jsem diskusi, kde si někdo stěžoval, že mu editor Atom žere o 30 nebo kolik % rychleji baterku na notebooku než Sublime Text. Odpovědi se různily od "fakt o tolik" po "proč si to nestrčíš do zásuvky". Ten nový editor je nový (pro 21. století!), cool, používá hipsterské technologie a možná má i skutečné výhody, no ale je pomalý, žere zdroje a nedá se v něm moc pracovat s velkými soubory, no ale on je cool, je zadarmo, má nějaký potenciál, tak se používá. Časem se to o nějaké procento zlepší a lidi si zvyknou, že ta baterka prostě odchází rychleji.

Šlo by Atom napsat v C? Jo, ale za jak dlouho... Obešel by se svět bez Atomu? No, když by musel, ale proč? Mají lidi, kteří programují Atom, skutečné ponětí o "střevech" HW a OS? Někteří určitě,možná i všichni, ale to jim nezabrání dělat co dělají a jak to dělají.

podle mě je princip OOP právě o tom aby se člověk nemusel starat o tom co je "pod tím". Ne proto že programátoři jsou liné "lamy" co to neumí, ale protože i když je člověk sebelepší tak všechno najednou v hlavě mít nemůže a určité odstínění umožňuje soustředit se na konkrétní problém. To že je potřeba mít přehled o základech - složitosti a OS je bez debat. Ostatně jinak bysme všichni programovali v asembleru.

Ano, se vzrůstající složitostí problémů máme přirozenou potřebu používat vyšší abstrakce (větší bagry) a to logicky vede k tomu, že při výpočtech dochází ke zvýšené režii v podobě náročnosti na výkon procesoru, paměť atd. Není to ale jenom problém OOP, FP tím trpí minimálně stejně.