Žena zkouší učit se programovat, úspěšně prošla pokusy s KTurtle (to ji moc bavilo ;) a teď se (s mojí lehkou pomocí) pere s Javou.
Kupodivu ji to celkem baví, i když není žádný „matematický“ typ. Docela problém je ale se sháněním cvičebních úloh – jednak jsou občas moc složité, jednak drtivá většina úloh jsou nějaké matematické záležitosti, což je pro moji humantně vzdělanou ženu dost nezáživné – kromě vymýšlení algoritmu by si ještě musela nastudovat příslušnou část matematiky :(
Nevíte náhodou někdo o nějaké dobré sbírce úloh (ideálně online, ale knížka by taky byla dobrá), kde by byly úlohy:
1. uspořádané podle obtížnosti
2. začínající úplně jednoduchými úlohami (např. vypište větu obsahující číslo tak, aby byla gramaticky správně podle čísla)
3. alespoň trochu zajímavé (tj. pokud možno ne moc matematické a trochu žensky hravé, ideálně o nějakých kytičkách ;)))
?
Zatím jsem se koukal na knížku Algovize od L. Kučery, na stránku UVa Online Judge [1] a zepár stránek kde je aspoň pár úloh [2]
Pokud někdo víte o něčem lepším, byl bych moc vděčný za tip!
Dík.
[1] http://uva.onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8&category=3
[2] http://www.ki.fpv.ukf.sk/~rhraska/
P.S. existují i různé stránky věnované specificky problému „IT a ženy“ :) jako např. http://www.zkusit.cz, ale většinou jsou to jenom taková povídání o tom, jak jsou ženský v IT potřeba a jak je to pro ně šance – ale pořádný pomůcky, jak čím a kde začít se tam člověk nedočte :(
A co třeba toto?
http://knihy.pecinovsky.cz/
Mám k dispozici i rukopis v PDF z doby kdy kniha vznikala kdyby jste na to chtěl mrknout. Kdyžtak mi napište na mail. Na konci každé kapitoly jsou úkoly. Řeší se tam věci typu jak ze základních geom. tvarů poskládat auto, strom, dům apod., ale i složitější věci.
notoric@seznam.cz
Ještě mě napadlo, že jestli chce žena zůstat u Javy, tak jsou docela dobré úlohy na želví grafiku. Implementace želví grafiky do Javy je jednoduchá a ty úlohy mají výhodu v tom, že je výsledek (aˇt už dobrý nebo špatný) hned vidět. Nějaké pěkné úlohy vycházely ve starších Elektronikách a také je na netu česká učebnice pro školy i s příklady (musím dohledat).
Kdybych já chtěl dnes seznámit někoho se základy programování za podmínek, že dotyčný se nechce moc mořit s matematikou, chce co nejdříve mít nějaké hmatatelné výsledky a chce si zprvu nejdříve spíše hrát a pak – výhledově – se třeba dostat k něčemu komplikovanějšímu (pokud ho to chytne a bude chtít), doporučil bych mu Squeak a jet podle SBE (Squeak by Example). Nic lepšího pro tyto účely IMHO vymyšleno nebylo.
Jen takové malé rýpnutí – Python, Javu apod. autoři vymýšleli s tím, že chtěli vytvořit nástroj pro opravdovou práci a ne jen na hraní. Vymysleli různé konstrukční prvky, ale v rámci úspor je udělali z nevhodného materiálu a v nevhodném meřítku – takže se na opravdovou práci příliš nehodí a na hraní je to zase zbytečně těžkopádné – zkrátka taková Cheva v 20násobném měřítku a papundeklovém provedení.
Smalltalk (resp. Squeak) vymýšleli primárně na hraní pro děti (viz projekt Dynabook). Ale nechtěli nic ošidit, pojali to velkoryse a navíc zvolili kovové provedení – takže se to dá snadno použít i na poměrně sofistikovanou práci. Prostě něco jako stavebnice Merkur. :-)
No neviem s tym Squeakom. Asi pred rokom som si ho stiahol a skusal, ale po chvili som ho zavrhol. Podla mojho nazoru je to tam moc zviazane s danym grafickym prostredim. Programator musi v dnesnej dobe vediet v akom subore ma zdrojak, ako ho skompiluje a ako ho bude debugovat. Myslim, ze kto zacne programovat v Squeaku sa toto nenauci. Podla mojho nazoru zacat programovat v Squeaku je ta najhorsia alternativa – je to slepa ulicka. Ak potom bude chciet clovek prejst na iny jazyk bude musiet zacinat uplne odznova. Ale mozno sa mylim a tesim sa na pripadny clanok o Squeaku od pana Tisnovskeho :-)
Dnesni IDE se pomoci ruznych outlineru s prehledy trid snazi programatory od pohledu na program jako mnozinu zdrojovych souboru odprostit (osobne mi nikdy neprisly ani trochu prehledne a nenaucil jsem se je pouzivat). Programator preci chce co nejmene bolestive napsat kod, ktery dela to, co po nem pozaduje, spustit ho a pripadne odladit. To, ze Smalltalk to dela bez zbytecnych obezlicek, prece nelze brat jako nevyhodu – urcite ne pro zacatecniky. Ano, Smalltalk se ovlada jinak nez bezna IDE, ale i vzhledem k jeho stari, zamyslete se nad tim, neni to chyba spis tech ostatnich IDE ;-)
U lidi, z nichz maji byt programatori, by Smalltalk nemel byt jediny a pravdepodobne ani prvni jazyk. Ale setkat by se s nim urcite meli, stejne jako treba s programovanim v assembleru rekneme na jednocipech, kde jsou systemove prostredky silne omezene.
Programování je ze své podstaty činností tvůrčí (resp. mělo by jí býti). Squeak jeho uživatele neomezuje – naopak, snaží se ho v jeho tvůrčí činnosti všemi prostředky podporovat. Navíc je celý vybudován velmi logicky a neobyčejně přehledně – od základních primitiv, až po poměrně luxusní, nadupané objekty; navíc abstrahuje od konkrétního HW a návrh založený na virtuálním stroji nejen dává celému prostředí snadnou přenositelnost, ale díky tomu, že jakoukoli součást celého systému máte k disposici k prostudování v neopakovatelně přehledné a výborně zdokumentované formě, může se uživatel stále učit, jak konkrétní věc, jež ho zrovna zajímá, funguje a jak to udělali profesionálové, a to na „obecném počítači“ – virtuální stroj toho nabízí a od hostitelského systému požaduje opravdu minimum. Kdo chce, může se na tom naučit a pochopit prakticky vše – je to takový model reálného počítačového systému. Od vykreslení úsečky až po velmi luxusní GUI, od práce se znaky až po činnost překladače… Navíc kteroukoli věc může snadno změnit a hned uvidí efekt, který to má, uvědomí si vazby, skrz něž se ta jeho modifikace distribuuje celým prostředím.
Na co pro boha motat začátečníkovi hlavu nějakými zdrojáky, projekty apod.? Dnes se to dělá nějak, zítra se to bude dělat úplně jinak. Když jsem začínal já s počítači, dělalo se to taky jinak. To jsou naopak ty nejmarginálnější věci, které pochopí za pár minut – když ví, co je ale podstatou jeho práce.
Ano – dnešním trendem je nacpat mladým do hlavy, kam kliknout, aby se zkompiloval projekt, jak se trasuje, jak se refaktoruje, jak rozdělit projekt na jednotlivé soubory… Ale už se v tom zápalu tak nějak zapomene vysvětlit, jak se vlastně programuje. Takže tu máme armádu vývojářů, kteří se přou o to, jaké IDE je lepší, jaký jazyk je lepší, jaký OS je lepší, ale ve skutečnosti jsou to žabomyší spory, protože to kvalifikovaně posoudit nedokážou.
Dnešní programátoři totiž vůbec neumějí programovat. 2/3 by mohly házet s cikány lopatou ve výkopu, protože na programování ve skutečnosti ani nemají schopnosti. Skutečnou náplní jejich práce je multiplikace problémů – na počátku je problém, z něhož jejich činností vzejdou dva další, aniž by se původní problém podařilo uspokojivě vyřešit, atd. A proč? Protože sice vědí, jak rozdělit projekt do souborů, jak k němu připlácnout knihovny, ale nějak jim uniká, že jejich činností nemá být rozdělování projektu do souborů, ale řešení problému. Vůbec není podstatné a ani nutné učit, jak se obsluhuje sporák, jak se pracuje s kuchyňskou vodovodní baterií, s lednicí… Podstatné je naučit se vařit – když toto dotyčný pochopí, docvakne mu už samo, jak a na co použít mixér, elektrickou troubu, či gril. Ale naopak to nefunguje a je to na současném softwaru vidět na každém kroku.
S prominutím – má-li nějaký uchazeč o programátorské povolání problém s pochopením „v akom subore ma zdrojak, ako ho skompiluje a ako ho bude debugovat“ a přechod k jiné organisaci by pro něj představoval zásadní problém, řekl bych mu tolik, že s krumpáčem a lopatou nadělá nejspíše méně škod, než při programování, na něž očividně nemá mentální schopnosti.
Mnohokráte jsem se setkal s „argumentem“, že „to a to v praxi nepotká, tak proč se to učí, proč se neučí hlavně to, co bude dělat v praxi, proč se zabývá něčím, v čem (už) nikdo nedělá…“ Ve skutečnosti je to ten nejhloupější argument, protože to je v protikladu s optimálními didaktickými postupy. Naopak – člověk musí poznat více přístupů, nových i starých, masově používaných i exotičtějších, jinak v životě nebude schopen získat o dané problematice přehled, nepřijde na to, co je podstatné a co ne, co se dá dělat jinak a kdy je to šikovné dělat to tak, neuvědomí si, že program nemusí být nutně členěn na soubory obsahující jeho různé komponenty, nenapadne ho, že je to vlastně takový anachronismus, přežívající do dnešních dob někdy z 50. let, kdy se to ani jinak dělat nedalo, a že existují i mnohem modernější a logičtější přístupy, a to i přes to, že jejich vznik se datuje mnohokráte do let před narozením dotyčného.
Nejsou žádné slepé uličky – každá ta ulička vede někam dál, jenom po ní třeba od jistého okamžiku nikdo nešel, protože usoudil, že je to za daných podmínek neperspektivní. Ale každý by měl mít možnost oťukat si to sám. Spousta lidí např. odsuzuje Pascal jako přežitý, nevhodný, zastaralý… Ale kolik z nich to může říci z posice kvalifikovaného odborníka a kolik jich to říká jen proto, protože to slyšeli od jiných, nebo dokonce za zápory označují to, co je naopak u toho jazyka ve skutečnosti kladným rysem, ale ve svém diletantismu si to ani neuvědomují?
Zcela souhlasim. Sam bych to nenapsal lip. Bohuzel dnesni vyuka programovani se casto zvrhava ve vyuku obsluhy IDE. Dokonce i na MFF. Napriklad kdyz my jsme meli cviceni k C/C++ tak vsechno probihalo u tabule, proste jsme dostali zadano neco `naprogramovat do sesitu' a pak se u tabule diskutovala ruzna reseni. Stejnym zpusobem jsme meli o rok driv zaklady algoritmizace v Pascalu. Za sebe musim rict ze me to naucilo docela hodne (a to jsem si myslel, kdyz jsem tam sel ze uz programovat docela umim).
Dnes (resp. pred 2ma lety kdy jsem jeste delal cvicitele) se to dela tak ze polovinu tech cviceni budete mit v pocitacove ucebne (nejspis aby se amortizoval nakup techniky a M$ prostredi), kde si kazdy neco pise do pocitace. Vysledek je ze se hodina zvrhne do reseni problemu typu ‚kde mam na co clicknout a proc to udelalo to ci ono‘. Takto a pak jeste opisovanim programu do pocitace se promrha
nejmin polovina casu, coz zpusobi se studentum musi davat jednodussi zadani (ovsem ta prace co s tim meli v nich budi dojem ze je to slozite), ti mene zkuseni pak ulohu ani nedokonci, protoze sice treba maji spravne myslenku ale behem te doby se nedostanou (i s dopomoci) pres zacatecnicke chyby. Kdyz pak na konci nekdo predvadi sve spravne reseni tak ho neposlouchaji protoze stale bojuji se svym programem. Pak jsou frustrovani a z jednoduchych veci zacnou mit fobie, slozitejsi radsi rovnou neposlochaji. Pritom kdyby pracovali na papiru a pocitac je neterorizoval tim ze tu a tamhle maji syntaktickou chybu tak by si pri zaverecnem porovani ruznych pristupu vsimli ze to maji skoro dobre a vetsinou i kde maji tu chybu.
Podle meho nazoru je nesmysl ucit ovladat IDE, krome zakladniho uvodu jak to spustit a do ktereho okna psat program a jak ho prelozit a krokovat a jak zobrazit help. To se da ukazat behem 2 hodin (na jednom pocitaci, treba na prednasce) a se zbytkem by se mel prumerne inteligentni clovek poprat sam (pocitacove laboratore jsou studentum pristupne i mimo vyuku). Jestli ani po tydnu snazeni nezvlada zakladni obsluhu tak by mel radsi jit delat neco manualniho a netrapit se s pocitaci.
No ve Squeaku nic takoveho jako soubor=trida skutecne neni, ale vzdyt mnoho dnesnich programatoru se na projekt diva jako na celek – proste maji v Eclipse nalevo/napravo zobrazeny strom s balicky a v nem jednotlive tridy, mnozi dokonce ani ten zdrojak nedokazou na disku najit (nekecam – zazil jsem jednoho takoveho „klikose“, ktery nejenze nedokazal zkompilovat projekt z prikazove radky, ale ani nedokazal najit zdrojak jedne tridy, ktery jsem po nem potreboval).
To se přece vůbec nevylučuje. ;-) Otázkou bylo, co doporučit začátečníkovi – zde bych s Lispem opravdu váhal. Mám sice knížku pro úplné programátorské začátečníky, kde se k výkladu používá Lisp a je to psáno tak, že by to pochopila i stará Weittingerová, ale v prvních kapitolách si čtenář jen hraje na papíře s čtverečky s čárkami, představující různé funkce a predikáty, pak si začne malovat různé stromy a jimi modelovat různé datové struktury a algoritmy a teprve pak se začne s tím, že tohle všechno se dá dělat i na počítači s pomocí Lispu. Pravdou je, že samotného by mne docela zajímalo, jak by to takový začátečník typu „tabula rasa“ přijal a jak by se pak díval na algolské, tj. z jeho pohledu exotické jazyky. :-) Možná, že třeba na stavebních nebo strojních fakultách by se takový experiment dal realizovat. S ohledem na vlastnosti AutoCADu by to pro tyto studenty mohlo být zajímavější a užitečnější, než jim cpát do hlavy C++ – jak se to děje nyní např. na ČVUT.
[Lisp is] „the greatest single programming language ever designed.“
„I think if you can have one language on your system, of the ones that have been around for a while, it should be Lisp.“
--- Alan Kay, duchovní otec Smalltalku
A ještě jeden od téhož autora pro ty, kteří se pořád ohánějí tím, že v současnosti se používá to a to, což má být pro výuku rozhodující:
„The best way to predict the future is to invent it.“
To je možná ještě šílenější představa, než u toho Lispu. :-)
Mimochodem – o Forthu jsem se poprvé dozvěděl někdy ve svých 10 letech z jakéhosi populárního článku ve VTM nebo něčem takovém a první, co mě napadlo, bylo, že takovou šílenost snad nikdo nemůže myslet vážně. Koho by tenkrát bylo napadlo, že jednou takový forthovský systém celý napíšu v Assembleru from scratch (teď mě tak napadá, že to celé bylo taky v jednom zdrojáku – jak trestuhodné! :-) na svou omluvu snad mohu říci, že to je relativně malý program, nějakých 80 KB spoře komentovaného Assembleru) a programování v oblasti embedded ve Forthu mě jednou bude živit… :-) Na tom je krásně vidět, jak si život s člověkem častokráte zašpásuje.
Na modifikaci myšlení je Forth opravdu skvělý nástroj – je to jazyk, ve kterém nešikovná analýza problému = záruka, že se v tom člověk zamotá tak, že už se z toho nevymotá. :-) Opravdu jazyk, u něhož je třeba „Thinking Forth“, jak se i nazývá skvělá knížka od Lea Brodieho, kterou bych doporučil místo všelijakých blbostí typu „C# za měsíc“ a podobně, ikdyž se nejedná o mainstreamový jazyk. Důsledky této vlastnosti mohou být jen dva – buď to člověk vzdá, nebo se – ať to zní sebeneuvěřitelněji – fakt naučí problémy analyzovat, faktorizovat a strukturovat tak, že je to jednoduché, přehledné a efektivní.
Forthisti ovšem pracují obvykle jako samotářští vlci a o své zkušenosti se dělí toliko v odborných diskusích a dříve i časopisech (Forth Dimension, bohužel již nějakých 10 let nevychází, přestože ho i neForthisti ze Silicon Valey považovali za jeden z nejlepších odborných počítačových časopisů a dodnes v jeho archivu člověk nachází podnětné myšlenky a postupy). Důvodem IMHO je, že forthista pracuje jako malíř – stojí před ním úkol něco ztvárnit, pak přemýšlí, jak to ztvární, jaké výrazové prostředky použije, jakou techniku malby použije, a nakonec se pustí do díla – udělá si pár skic, zkusí si, jestli jím zamýšlené barvy budou vyhovovat, připraví si podklad, namíchá si ty barvy a pustí se do díla. Co forthista, to osobnost, a troufám si říci, že by se po nějaké době studia dal podle forthovského kódu poznat rukopis konkrétního člověka asi nejbezpečněji ze všech programovacích jazyků. :-) Každý forthista nějak začne, ale každý si po nějaké době a zkušenostech vypěstuje osobitý styl, který může být dosti na překážku teamové práci. Ta spoluúčast vývojáře na tvorbě syntaxe je tu prostě ještě svůdnější a neodbytnější, než u Lispu.