Ja v tom nevidim problem. To chcete ludi drzat v bezpecnej bavlnke jazykov beziacich na nejakej virtualnej masine a smrtelne zranenia nech si potom spravia na vlastne triko? To nedava zmysel. Ak sa nebavime o nejakom uplne brutaln high end programatorovi, alebo databazistovi, ktory programovanie potrebuje len k tomu aby vedel nieco oskriptit, tak systemovy programator *ma* zacat C-ckom. Ak ho nezvladne, tak z neho nebude systemovy programator. Bud nie hned, alebo nikdy.
"To chcete ludi drzat v bezpecnej bavlnke jazykov beziacich na nejakej virtualnej masine a smrtelne zranenia nech si potom spravia na vlastne triko?"
A na to jsi prisel jak? Rikam, ze je dobre zacit zaklady a studentum to zjednodusit. Nejdriv lehke veci, pak tezke veci. Nema smysl je na zacatku trapit problemy, na ktere je casu dost.
"systemovy programator *ma* zacat C-ckom. Ak ho nezvladne, tak z neho nebude systemovy programator. Bud nie hned, alebo nikdy."
A na to jsi prisel jak?
Prave naopak. Dava to smysl.
Dejte detem noze, a trenera. Ti kdoz preziji budou velmi dobre vytrenovani a neprekvapi je uz zadny jiny typ boje.
Navic oproti nozi, C nikoho nezabije pri treninku. A kdo to nevydrzi / nepochopi, no tak by spise pri proramovani skodil a mel by jit delat manazera...
Funkce malloc je součástí specifikace ANSI C, takže tvrdit, že nemá s jazykem C nic společného, je poněkud mimo. A pokud se při výuce C budu vyhýbat dynamické alokaci paměti, tak nevidím valný důvod, proč se ten jazyk vůbec učit. Pro takto základní výuku programování je C zbytečně náročné.
Pro výuku základů programování je C náročné, protože spousta věcí se v něm dělá výrazně složitěji než v jiných jazycích. V jazycích, které lépe zapouzdřují práci s pamětí a s řetězci, je samozřejmě mnohem snazší zvládnout základní prinicipy programování. Psát něco v jazyce, kde každá na pohled trivialita končí na segmentation fault, je pro začátečníka neskutečně frustrující. Ale pokud už se mám učit programovat právě v C, tak je blbost se tématu dynamické alokace vyhýbat. To, že se bez ní mohu v řadě případů obejít, fakt není argument, proč ji nemuset ovládat. A vytahovat v tomto kontextu jako argument bezpečnostně kritické aplikace je hodně mimo mísu. Já bych teda člověku, který nezvládá dynamickou alokaci paměti, nevěřil ani to, že dokáže v C napsat bezpečný Hello World.
"C není není složitý jazyk, jen se v něm snadno dělají chyby."
Chybama se člověk učí -> C je ideální na učení :D
"V pythonu za kratší dobu naprogramujete víc složitějších věcí, což je IMHO pro výuku přínosnější."
Který student bude v praxi přínosnější?
a) Semetrálka 500 LOC, ale během práce na ní si osvojí pointerovou arritmetiku, řetězený seznam a iterace v něm
b) Semestrálka 2500 LOC, ale když na něj někdo bafne ohledně adresování paměti nebo uložení dat v RAMce, zrudne, zpotí se, zalapá po dechu, zezelená a svalí se jak špalek
Pokud A, proč by byla přínosnější výchova k tomu, aby z něho byl B?
Jako semestrální úlohu jsem dělal implementaci standardní unixové utility "wc" (jen ty nejpoužívanější parametry). A i když jsem nesplnil miniální požadovaný počet řádků, dostal jsem pochvalu za velice kompaktní kód. Takže s tím že je C ukecanější nesouhlasím. Ona ta pointrová aritmetika a různé vychytávky C, jako napřiklad přiřazení v podmínce cyklu, hodně kód zkrátí. Jestli je něco ukecaného, tak možná Java....
Před pár dny jsem porovnával můj prográmek s jiným, od čerstvého studenta. Oba v C a dělaly úplně stejnou věc. On tam měl přes 200 řádků. Zhruba půlku jeho kódu jsem zvládl už v deklaracích proměnných, to byly první tři řádky z pěti. Takže ukecaný určitě není jazyk C, ale jedině programátor :-D
V pythonu to naprogramuji rychle, ale po rozšíření projektu mi při změnách datových typů hrábne. Ani kvalitní IDE mi v tom nepomůže, muselo by být věštec. Potřebuji silně typový systém, čím víc compile-time kontrol nabídne (generika, value types, atd.), tím pro mě a pro efektivitu vývoje lepší.
Směrem dolů si ten pythoní kód nespustím na mikročipu, který je také počítač a také se programuje. Ani se tím nenaučím, co se vlastně v počítači děje.
Takže všechno má své pro a proti. Volba jazyka pro výuku musí odpovídat cíli, který se v daném předmětu vyučuje. A ty jsou různé.
Souhlas, ale na ty mikročipy bacha :) https://micropython.org/
C docela vytříbí mysl. Rozhodně super úvod do řádného programování bez zábran. V nejhorším dostanete přes pusu od kompilátoru, Valgrindu nebo si chybu uvědomíte pomocí printf nebo gdb atd. Myslím, že je to rozhodně jeden z lepších možných začátků.
Je ale fakt, že C i Javu často učí lidi, co prostě neumí ty věci poutavě a užitečně vysvětlit. Vždy to je něco ve smyslu "tak si otevřeme Visual Studio (na C) nebo Eclipse (na Javu)" a tím začíná pohroma. Myslím, že pedagogicky lepší je získat aspoň částečnou představu, v jakém prostředí jazyk vznikl. U C i Javy to byl UNIX. Proč tedy nevzít nějaké RaspberryPi s Linuxem a GNU a nepřiblížit se tomuto prostředí touto cestou a jako náhodou můžu třeba i blikat diodou na GPIO nebo tak něco a potrénovat se na binárních kódech, když budu chtít. Ještě jsem neviděl nikoho, kdo by řekl, že je RaspberryPi úplně k ničemu a že to byly vyhozené peníze. Dá se použít i virtuální stroj, když někdo má zrovna Windows nebo nově i Windows Subsystem for Linux. Všechno to je rychlejší začátek, než se pachtit s instalací VSC++ nebo Eclipse. Později třeba využije student silných stránek IDE, ale pro začátek bohatě stačí GEdit, Kate nebo dokonce i nano.
Jinak znám lidi, co začínali na Algolu 60 nebo Fortranu 77. Jeden můj kolega ze studií měl FORTRAN rád, byl to matematik a těm to obecně prostě sedne. I dnes se běžně vyučuje Pascal a může to být kvalitní průprava. Prostě jde o to, kdo a pro koho to jak učí. Jazyk už je potom celkem jedno, když je to něco rozumně využitelného v praxi (jako že pro vědce FORTRAN určitě praktický je).
Kvalitní objektový návrh nějakého reálného procesu, který je má správně rozdělené kompetence, je přehledný, lze jej snadno rozšiřovat, upravovat, používá správné datové komponenty atd. (python, java), tříbí mysl úplně stejně jako technické detaily správy paměti v C. Prostě jsou to dvě různé věci, obě stejně důležité. A s obojím je dobré se dnes seznamovat hned od začátku.
Kecy v klecy ... vsechny skolni projekty sou ze 100% pro jakykoli objektovy programovani naprosto nevhodny, naopak to zcela zastira jak funcionalitu tak zhorsuje citelnost kodu, a vysledkem je patlal, ktere na prinf potrebuje GB ram, protoze to prece musi bejt spravne objektovy a dynamicky ...
To je mor současné doby. My vyrostli na TurboPascalu a vše cpali do polí a struktur. Dnes se místo struktur používají objekty. Ale z nějakého důvodu k tomu lidé mají potřebu dobastlit i metody atd. Zatímco my jsme měli binární vyhledávací strom jako spojový seznam struktur, tak dnes tam lidé nasází objekty a jsou schopni se půl hodiny hádat o tom, zda má být nějaká metoda private nebo public a zda náhodou nemá být v jiné třídě. Do toho začnou házet výrazy typu "friend funkce" a člověk má pocit, že pro samé objekty už ani nevidí data.
Postupem času tak vídám objektové programování u věcí jako je LZSS, fraktály atd. A nechápu proč. Osobně mi objektové programování přijde nevhodné i na úlohy jako "půjčovna videokazet", ale to do toho se silou cpaly objekty už za nás.
Taky, na ZŠ Basic na Didaktiku, na SŠ TurboPascal, na VŠ Delphi, po VŠ C.
Dopadlo to tak, že v jednočipu s oblibou používám makra jako třeba
[code]
#define foreach(index, array) for(index=array; index != NULL; index = index->next)
[/code]
na procházení seznamu struktur na heapu... :D Pár takových maker, spotřeba paměti minimální a přehlednost na úrovni ještě vyšších jazyků...
Souhlas. Nevím, jak to teď na školách vypadá, ale rád bych viděl RPi jako učební pomůcku. Prostředí - Linux je určitě lepší pro výuku než nějaké přeplácané Visual Studio. Dále díky GPIO je RPi ideální na učení low-level C (ovládání PLL, práce s pamětí, ovládání GPIO), hlavně proto že uvidím výsledek mé práce. Změním pár bitů v paměti a začne mi blikat dioda. Samozřejmě si také můžu stáhnout knihovnu a udělat to Pythonu.
Sám seš totální píčovina. V začátcích potřebuješ vědět jak funguje program, větvení, cykly, funkce apod. to vše C má a je to jednoduchý jazyk na naučení. Na základní úlohy, kde potřebuješ rozvinout algoritmické myšlení, to zcela dostačuje. Nepotřebuješ nic jako list comprehensions, generátory, třídy nebo vícenásobnou dědičnost. Sám jsem se C učil z knihy C programming language od autorů K&R a naučilo mě to víc než jakákoliv jiná kniha nebo předmět na VŠ. Ti co začali s Javou nebo jiným high level jazykem pak těžce narazili, když měli řešit úlohu, na kterou neměli knihovnu nebo přímou podporu v programovacím jazyce.
to řikáš, jak kdyby byl jen jeden "programátor".
Volba jazyku na výuku by měla být ovlivněna cílem a množstvím času. Těžko budu datového analytika učit céčko, stejně tak o céčku raději nebudu říkat webaři, aspoň ne v počátcích.
Jsem zastánce toho, že kažý jazyk něco přináší a každá výuka programování má nějaký cíl, který mají studenti splnit. Znám lidi od Colobu, fortranu, kteří to stejné co ty říkáš o javě říkají o céčkařích ;)
To vše má python a je snazší na póužití i pochopení. Navíc python je mnohem praktičtější, takže lidem, co skončí u toho prvního iazyka dá víc, než nepraktické C. Jazyk C je vhodný až pro pokročilé programátory, které už nemusíš složitě učit základní konstrukce, ale potřebuješ je naopak naučit low level věci. Takhle je to efektivnější.
Myslím si, že je potřeba rozlišovat mezi výukou principů programování počítačů - low level Cčko a výukou modelování abstrakcí - python. Obojí by měl programátor umět a jsou to hodně odlišné disciplíny. Někoho pak zaujme to první, někoho to druhé.
Se svým školou povinným synovcem děláme na domácím projektu, ve kterém je potřeba objektový model v pythonu na PC, kde objekty maximálně odpovídají realitě, a low-level Cčko pro připojený jednočip s displejem a ovládáním. Z jeho pohledu jsou to dost rozdílné světy, ač obojí lze nazvat programováním.
Osobně jsem se taky učil na C na základce, ale nijak hloubkově.
Pak když jsem viděl Python, co odstraňoval vše, co mě na C štvalo, byla to láska na první pohled. Nicméně pak když jsem se k C musel vrátit (Arduino a STM32 - nic hloubkového, ale jisté přípravky do výroby) alespoň jsem na to nečuměl jak blbec, ale velice rychle jsem funkční kod spáchal (ano, velice jednoduché věci, žádné velkoalgoritmy), takže jsem vděčen za výuku v C, že není/nebyla k ničemu.
Pak když s tímhle vším jsem šel na výšku a tam mi začli cpát Pascal, to jsem zuřil!!! (ten opravdu je k ničemu)
A jak padlo, větvení, funkce, proměnné apod. jsou všude +- stejné, výuka logiky se tak může dělat v čemkoliv, krom extrémů. A ač milovník Pythonu, jsem rád, že začíáky byly nad staticky typovaným jazykem, člověk si lépe uvědomil, jak to uvnitř vypadá a ocenil, že to v Pythonu odpadlo, stejně tak si ale dával majzla, zda Python dělá to co má a na důležitých místech typy kontroloval.
Počítač není lidská mysl. Je to stroj, který je pro potřeby programování abstrahován. Ano, na algoritmy je třeba lepší Haskell nebo třeba i Python. Na pochopení principů je zase dobré C.
Kdyby počítače byly blízké lidskému myšlení, tak bychom je nemuseli programovat, ale prostě bychom řekli, co chceme a něco blízkého našemu záměru bychom dostali zpátky. Možná by ale taky počítač byl v létě a zimě na dovolené :-) kdo ví. Realita je taková, že bez porozumění funkci počítače na již dost abstraktní úrovni, jako využívá C např. pro user space GNU/ Linux operačních systémů, bude programátor dlouhodobě vždy vědět jen zhruba, co dělá. To přináší všechny problémy, které potom řeší těch několik málo schopných, kteří opraví více chyb, než vytvoří. A o tom je softwarové inženýrství.
Programovat umí každý. Když vám babička nadiktuje recept, tak se dostanete deterministicky k cíli, tedy něčemu co chutná podobně jako od babičky. Ten kumšt je ale v tom jak, proto prostě jídla od babičky chutnají lépe. Ona prostě už ví kde, kolik, jak dlouho a má na to metodu, aby se v určitém čase dobrala výsledku. Programátor je kuchtík, SW inženýr je kuchař a SW architekt je šéfkuchař, který navrhuje menu a kontroluje splnění požadavků.
Můžete mít hodně dobrého kuchtíka, bude krájet cibuli bleskem a vše co je potřeba bude moct zrovna tak uvařit, jako kuchař. Nepřijde ale na to, že některé nové kombinace budou dobře chutnat ještě před skutečnou realizací receptu. To ale ví šéfkuchař a kuchař nový nápad rychle pochopí a správnou mírou realizuje. Nikdo se na tom nemusí sáhodlouze domlouvat.
Vysoká škola nevychovává kuchtíky, ale šéfkuchaře. Někde se naučí krájet tu cibuli, ale vždy jde nakonec o ten lepší nápad, architekturu a jasnou představu co se týče realizace, aby ji mohli kuchtíci efektivně a opakovatelně realizovat.
Rozhodne jako prvni jazyky doporucuji javascript, php, mysql, pripadne assembler. Nema smysl se prplat s deklarovanim promennych, jak se to dela v pascalu, delphi, c, c++ a pod. Tim stravi hodiny zbytecneho casu misto, aby se naucil pouzivat algoritmy.
Myslim si, ze python, java, asp a podobne experimetny patri mezi jazyky, ktere postupne ustoupi na pozadi. Zalezi na tom, jak se dal vyvyne treba js a to php, jestli prevezmou vyhodne zapisy z pythonu nebo ne. Zatim to spis vypada, ze js zamrzl nekde 20 let zpet a od te doby jsou spis jen nejake vychytavky navic. Js by se mel prepsat objektove a sjednotit. Tez by se tam mela sjednotit struktura funkci. Podobne, jak na tom pracuje php. Ale stale mi prijde efektivnejsi udelat program v js, ktery spustite na kazdem pc bez instalace kde ceho, nez se brodit v necem jinem.
JS, PHP - rozšíření C syntaxe, ale skrytý pasti (== vs. ===) a moc daleko od počítače. Takže to je tak pro gympláky.
mysql není jazyk, to je databáze. Kdyžtak SQL, ale to není jazyk na algoritmy, to už můžeš nahodit rovnou Verilog.
assembler jde až na železo, ale bez abstrakce a nepřehledný, začátečníkům bych to nedoporučil.
Deklarace proměnných je naopak žádoucí. Je potřeba mít představu, že data jsou někde nějak uložena, že je rozdíl mezi intem a reálným číslem,... Jak co do velikosti, tak do formátu. A nejsou to hodiny psaní, ale ušetřený hodiny hledání chyb, když kompilátor zařve, že je někde binec. Třeba když se snažíš nacpat hodnotu typu WeightInTons_t do WeightInGrams_t bez konverze...