K problematice výuky programování v běžných vývojových nástrojích Aleš Keprt Ústav informatiky, Moravská vysoká škola Olomouc Jeremenkova 1142/42 772 00 Olomouc – Hodolany
[email protected] Abstrakt. Příspěvek diskutuje problematiku výuky programování v běžných (zejména komerčních) vývojových nástrojích. První část textu stručně popisuje současnou situaci ve výuce nových programátorů, především na českých vysokých školách. Ukazujeme, že ve výuce programování nelze vystačit jen se speciálními školními výukovými nástroji a musí se používat i nástroje běžné, tj. určené pro vývoj softwaru v praxi. Tím je dán kontext a rámec pro druhou, hlavní část textu, která na vzorovém příkladě Visual Studia diskutuje zejména slabá místa běžných vývojových nástrojů z pohledu potřeb výuky. Pojmenováváme a diskutujeme několik konkrétních problematických či chybějících funkcí, které jsou z pohledu studenta či jeho učitele důležité. Klíčová slova: výuka programování, Visual Studio, vývojové nástroje
1 1.1
Úvod do problematiky Situace v českém školství
S rozvojem počítačů a stále větším rozšiřováním jejich využívání v různých oblastech praxe úzce souvisí i neustálá potřeba dalších a dalších programátorů. Zůstaneme-li konkrétně v České Republice, vidíme, že programování počítačů se dnes běžně vyučuje nejen v rámci informatických studijních oborů na vysokých školách, ale i v dalších studijních oborech a stejně tak i na školách středních a základních. Výuka programování má přitom mnoho různých podob. V rámci studia informatiky a dalších oborů zaměřených na počítače můžeme na všech školách vidět strukturu výuky sestávající z více samostatných výukových předmětů, které společně tvoří pilíře znalostí a tvůrčích dovedností budoucích programátorů. Konkrétní struktura předmětů se na jednotlivých vysokých školách liší, avšak můžeme mezi nimi vysledovat mnohé paralely. Naopak existující odlišnosti mezi školami nejsou ani tak důsledkem jejich jiného zacílení (na jiný segment praxe), ale spíše výsledkem tvůrčí činnosti a osobních preferencí pedagogů, kteří studijní programy a předměty sestavili a vyučují. Velký díl „osobitosti“ studia programování na každé vysoké škole je dán také historickým vývojem, tj. pramení z toho, odkud a jak studium informatiky na daném místě vznikalo, z kterých příbuzných oborů vzešel pedagogický sbor apod. Počítače jako takové a i samotné jejich programování je přitom stále se vyvíjející proces. Vše se stále mění, modernizuje, zdokonaluje a se změnami v programování
více či méně ruku v ruce dochází i ke změnám v jeho výuce. Tyto změny jsou pak i dalším důvodem rozdílnosti jednotlivých škol – některé jsou více konzervativní, jiné více pokrokové a odvážné nasazovat do výuky programování nové výukové prostředky a postupy. Na tomto místě je vhodné zmínit také počin organizace ACM (Association for Computing Machinery), nejznámějšího vědeckého spolku v našem oboru. ACM se otázkou „Jak vyučovat informatiku a computer science?“ systematicky zabývá už od 60.let 20.století a jednou za čas vydává podrobně zpracované doporučení, jak by měl vypadat celý studijní program informatiky. Poslední vydání Computing Curricula 2005 (a s aktualizacemi v letech následujících) přitom už rozlišuje pět samostatných studijních oborů neboli tzv. poddisciplín1: Computer engineering – počítačový hardware Computer science – počítačová věda (tj. informatika) Information systems – informační systémy Information technology – informační technologie Software engineering – softwarové inženýrství I zde na českých školách se s různými názvy informatických studií setkáváme často, náplň studia však se samotným názvem až tak nesouvisí a jde spíš o pouhou „slovní kosmetiku“; všechny obory od computer science až po software engineering se u nás obvykle umisťují pod společnou nálepku „informatika“ nebo „informační technologie“. (Podobná situace je však vidět i na mnoha jiných místech ve světě.) 1.2
Proč tomu tak je
Popis v předchozích odstavcích má poněkud kritický nádech a může působit dojmem, že „všechno je špatně“ (v české výuce informatiky). Do jisté míry je samozřejmě důvodem k znepokojení už samotný fakt, že na mnoha školách se dlouhodobě ignorují doporučení ACM a vytvářejí se jiné nestandardní studijní konstrukce. Prvním důvodem je samozřejmě malá odbornost učitelů – ti se v rámci své vědecké práce typicky věnují na špičkové úrovni zcela jiným projektům než je problematika výuky programování a reálná úroveň výuky tak samozřejmě logicky zaostává za doporučeními expertů ACM, kteří se tímto zabývají intenzivně a dlouhodobě. Na druhou stranu současný stav ve výuce programování je dán i specifiky českého prostředí. Absolventi škol totiž budou pracovat ve zdejších firmách a cílem škol je zejména připravit je k tomu. S výjimkou hl. m. Prahy a možná dvou až tří dalších největších měst není expert v programování či informatice v Česku dobře uplatnitelný, zaměstnavatelé naopak žádají především levnou pracovní sílu ve formě „obyčejných dělníků“ programování a pokud možno ve velkém množství. Totéž podporuje i český systém financování vysokých škol, kde je opět podporována především kvantita a ne kvalita. V případě opačného postupu, tedy při případném kladení důrazu na kvalitu absolventů, by mohl nastat problém s jejich nedostatečnou kvantitou. Ne každý student totiž má nadání a píli na to, aby ve škole zvládl i složitější metody programování. Na doporučeních ACM je přitom zajímavé, že některé na první pohled složitější věci doporučuje jakožto jednodušší – jde například
o objektově orientované programování coby náplň úplně prvních hodin výuky začátečníků. Toto téma bylo už také bohatě diskutováno na dřívějších konferencích Objekty a je nad rámec tohoto příspěvku. Analýzou současné situace na vysokých školách a diskuzí o rozdílech „teorie a praxe výuky“ se zabývá i samotný dokument ACM, díky čemuž vidíme, že situace v Česku není v principu nikterak jiná než situace jinde ve světě.
2
Vývojové nástroje Běžné a školní nástroje
2.1
Předchozí kapitola popsala situaci ve výuce programování z několika základních pohledů. V dalším textu se budeme soustředit konkrétně na samotný proces programování ve výuce a speciálně pak na problematiku vývojových nástrojů tam používaných. Tyto nástroje se dnes vyskytují obvykle ve formě IDE (integrated development environment), čili integrovaných vývojových nástrojů. Pro potřeby dalšího textu si je rozdělme na dva typy:
Běžné: to jsou všechny ty, které se používají v komerční praxi. Školní: ty jsou určeny speciálně k výuce a ne k použití v praxi.
Ať už k výuce programování přistoupíme jakkoliv, někde v jejím průběhu určitě použijeme i běžné vývojové nástroje. Bez ohledu na to, zda je budeme ve výuce používat už od začátku, nebo výuku začneme s pomocí nástrojů školních a ty běžné přidáme až v jejím dalším průběhu, určitě nemůže absolvent vyjít ze školy bez jejich znalosti, protože by byl v praxi problematicky uplatnitelný. Zde musíme znovu zmínit i výuku programování vysokoškoláků neinformatiků, středoškoláků a žáků základních škol. Ti totiž nemají výuku programování složenou z více samostatných předmětů, ale typicky jen jeden předmět „informatika“ či „programování“ a v jeho omezeném čase musí zvládnout vše. Tito studenti se samozřejmě v konečném důsledku naučí daleko méně než systematicky připravovaní informatici, nicméně jde o poměrně velké množství studentů a část z nich skutečně bude programování v budoucnu živit a proto je třeba se jejich situací také zabývat. Tito studenti ve výuce většinou používají právě ony běžné vývojové nástroje a pro nedostatek času je u nich vynechaná výuka na těch školních. 2.2
Důvody existence vývojových nástrojů
Z výše uvedené definice typů nástrojů je vidět, že obě možnosti se navzájem nevylučují. Kvalitní nástroje však typicky patří právě do jedné kategorie a je to na nich poznat na první pohled. Důvodem existence běžných nástrojů je samozřejmě neustálá potřeba lidské společnosti vytvářet další nový počítačový software. Co je však důvodem existence těch školních? Těch důvodů je více a pokusíme se identifikovat alespoň několik základních:
Cena, snaha řešit potřeby výuky bezplatnými nástroji Přílišná složitost běžných nástrojů, nepřehlednost pro začátečníky Absence či nedostatek vestavěných „pomocníků“ pro začátečníky
Fakt, že vývoj softwaru je komerční proces a tedy také vývojové nástroje jsou komerčním artiklem, je typickou překážkou v jejich používání na školách. V posledních letech je tento problém však na ústupu, protože v oblasti programování se silně prosazují vývojové i další nástroje, které lze používat zdarma. Horší je situace u druhého bodu – s pokračujícím vývojem existujících nástrojů také roste jejich složitost. U mnoha z nich je jejich rozsáhlost a tedy i složitost už hodně daleko za hranicí toho, co dokáže běžně pochopit začátečník, speciálně pak při samostudiu. Třetí bod pak charakterizuje fakt, že běžné komerční nástroje typicky nenabízejí žádné pomůcky (či obecně přidanou hodnotu) pro výuku, ale soustředí se jen na dosažení maximální produktivity při práci již „vyučeným“ programátorům. Přitom právě jednoduché pomůcky, inteligentní vestavění pomocníci („wizardi“) nebo například kontextová ve stylu „co je to příkaz if“), které jsou v praxi naprosto zbytečné či nadbytečné, jsou často výhodným pomocníkem začátečníkům při prvních krůčcích v tak cizím a neintuitivním prostředí, jakým je svět počítačů a jejich programování. Čili důvodů ke vzniku specializovaných „školních“ vývojových nástrojů je dostatek. 2.3
Možnosti synergie
Zajímat nás samozřejmě musí také otázka synergie, tj. zda je možno sjednotit vývojové nástroje pro praxi a nástroje pro výuku dohromady a to takovým způsobem, aby z toho byl větší užitek než při jejich existenci a používání samostatně. Výuka na školních nástrojích probíhá z toho důvodu, že jsou vhodnější pro výuku hlavně jejich začátcích, kdy jsou potřeby a celková situace studentů někde jinde, než kde se nachází potřeby zkušeného programátora. Kdybychom funkce a obecně řečeno výhody školních nástrojů měli i v běžných nástrojích, ušetřili bychom jistý čas v dalším studiu, kdy bude ve výuce probíhat přechod ze školního na běžný nástroj. Případně u paralelně probíhajících kurzů v různých nástrojích by se studentovi situace značně zpřehlednila, kdyby mohl ve všech těchto kurzech používat jeden společný nástroj. Problematika dosažení synergie samozřejmě naráží na to, že například kurz funkcionálního programování probíhající v prostředí Common Lisp není vhodné spojovat s kurzem programování ve Visual Basicu pomocí Visual Studia. Tyto dva nástroje jsou odlišné nejen z důvodu školního či komerčního zaměření, ale ze samotné podstaty jiného stylu programování. Na to tedy pamatujme a v dalším textu se zaměřme speciálně na tu část výuky, která probíhá v prostředích s podobným stylem programování – může to být třeba právě Visual Basic, který je hodně oblíbeným jazykem zejména v kurzech pro začátečníky, neinformatiky a děti.
3
Visual Studio ve výuce
Microsoft Visual Studio je nejběžněji používaný vývojový nástroj při programování ve Windows, je tedy vhodným kandidátem na příklad běžného vývojového nástroje a my nyní prozkoumáme jeho možnosti a slabiny použití při výuce. Visual Studio je dostupné v mnoha verzích a edicích placených i zdarma. Vyučuje se v něm především programování v C++, C# a Visual Basicu a kromě prvního ze tří jmenovaných se většinou používá ve výuce i jako nástroj jediný. (Pro C++ existuje i řada jiných nástrojů, z nichž některé mohou být ve výuce výhodné už pro svou jednoduchost. Pro C# a Visual Basic je výběr nástrojů značně omezen, proto se většinou používá jen Visual Studio.) Z výše uvedeného plyne, že by bylo jistě příjemné mít ve Visual Studiu funkce podporující výuku a práci naprostých začátečníků. Podívejme se na některé konkrétní příklady situací, které Visual Studio neřeší buď vůbec, nebo je z pohledu začátečníka řeší nedostatečně. 3.1
Komplikovaná syntaxe jazyka
Když v C++ či C# nenapíšete středník na konci příkazu, překladač obvykle ohlásí chybu „Expected semicolon.“, případně pokračuje s překladem na dalším řádku a zahlásí jinou nesrozumitelnou chybu někde v další části zdrojáku. Co na tomto příkladě vidíme: Za prvé je to komplikovaná syntaxe programovacího jazyka. Ačkoliv příkazy nemusejí být na jednom řádku, typicky se tak píší. Komplikovanost pro začátečníka spočívá v přílišné volnosti syntaxe. Visual Basic například vyžaduje, aby každý příkaz byl na samostatném řádku (až na pár výjimek), takže chyby tohoto typu tam nenastávají. Navíc samozřejmě odpadá potřeba středníku za každým příkazem. Ještě větší problém může mít začátečník v pascalu či Delphi, kde se středník nepíše za příkazy, ale jen mezi příkazy, takže v některých speciálních případech za příkazem středník není. 3.2
Chybějící nebo nedostatečná nápověda syntaxe
K předchozímu bodu se úzce pojí i další problém: Pokud za příkazem chybí onen středník, překladač vypíše chybu překladu a IDE nijak nepomůže studentovi s jejím pochopením či opravou. Zůstaneme-li u chybějícího středníku, IDE by mělo studentovi srozumitelně a celou větou sdělit, co se děje a jak dál postupovat. Navíc by tato zpráva měla být pokud možno v češtině. (Tato teze vychází z předpokladu, že existuje nějaká poměrně nevelká skupina chyb, které se zcela typicky objevují u začátečníků a přitom jsou dobře identifikovatelné přímo počítačem.) K chybové zprávě překladače „Expected semicolon.“ by tedy mělo IDE přidat vysvětlení ve stylu: „Program je v tomto místě nesrozumitelný. Pokud zde měl být konec příkazu, musíte napsat středník. Na konci každého příkazu se píše středník.“ Podobně počítačem rozpoznatelných chyb je jistě více. Typické je taky narazit na problém překlepu jména třídy či špatné velikosti písmen. Je-li v systému třída či
jmenný prostor System, překladač zahlásí chybu, chceme-li ve zdrojáku použít Sistem či system. IDE by se pak mělo postarat o pomoc studentovi tím, že mu nabídne opravu ve stylu: „Slovo Sistem je neznámé. Pravděpodobně jde o překlep a chtěl jste napsat System.“ U delších názvů tříd, které se v .NETu vyskytují běžně, by se velmi hodila výše zmíněná nápověda k chybné velikosti písmen, ale i dalších překlepů, jako např. Process místo Proces apod. Zatímco zkušený programátor si okamžitě překlepu všimne a v mžiku jej opraví, začátečník si marně láme hlavu, co je špatně, a obvykle hledá chybu úplně jinde. 3.3
Nedostatečná podpora projektorů a interaktivních tabulí
Ve výuce nejde jen o samostatnou práci studentů. Součástí práce učitele je často i předvádění práce s IDE na projektoru nebo pomocí interaktivní tabule a zde narážíme na problém, že Visual Studio jakožto i další vývojové nástroje nijak nepodporují tuto činnost. Učitel nemá možnost jednoduše otevřít dva pohledy do IDE – jeden standardní na monitoru a druhý s daleko větším fontem na projektoru. Nemůže nechat na projektoru svítit stejný náhled a dál pracovat na jiné části projektu. Na počítači s dvěma monitory a dostatečně výkonným hardwarem (především dostatkem operační paměti) je možno problém obejít například otevřením souborů ve dvou instancích Visual Studia, nastavením většího písma v jednom z nich a jeho přesunutím na druhý monitor. Výsledek je pak lepší – studenti už mohou vidět jiný náhled, než na jakém učitel pracuje, avšak naopak nemohou vidět online práci učitele a změněné nastavení Visual Studia nejde jednoduše uložit (nelze mít dvě různá nastavení zároveň aktivní u jednoho uživatele). Na tomto poli je ještě jistě co dohánět. 3.4
Chybějící nápověda sémantiky jazyka
Podobně jako u výše zmíněných syntaktických chyb by IDE mohlo studentovi pomáhat i s pochopením sémantiky. Na rozdíl od syntaktických chyb, ty sémantické nezpůsobí chybu překladače, takže na první pohled nejsou vůbec vidět. IDE by mohlo začínajícím studentům chápání programů usnadnit pomocí „našeptávače sémantiky“, který by například po najetí kurzorem myši nad nějaký příkaz srozumitelně oznámil, co daný příkaz dělá. Například u „int i = 1;“ by se objevilo vysvětlení „1. Založí proměnnou i typu int. 2. Vloží do proměnné i číslo 1.“ A slovo int by mohlo být podtržené a po kliknutí na něj by se vypsala srozumitelná stručná nápověda o tomto datovém typu. Tj. ne na dvě obrazovky dlouhý vyčerpávající popis datového typu System.Int32, který se otevře až po 10-15 sekundách čekání v samostatném okně MSDN, ale stručné a jasné vysvětlení pro začátečníka ve stylu: „int: datový typ pro celé číslo se znaménkem. Rozsah je přibližně +/- 2 miliardy.“ A teprve zde by byla možnost kliknout si pro další informace do MSDN. Speciálně u Visual Studia je dlouhodobě problematický i samotný styl nápovědy MSDN, zejména její nabobtnalost, naprostá nesrozumitelnost pro začátečníky a strašlivá pomalost při otevírání jednotlivých stránek nápovědy. Minimálně
inteligentní cache posledně navštívených stránek by situaci dosti pomohla. (Dokladem o tom, že zde „něco není v pořádku“ je i fakt, že je často rychlejší použít online nápovědu, která využije standardní cache www prohlížeče, než nápovědu MSDN nainstalovanou na vlastním počítači.) 3.5
Celkově chybějící čeština
Úplně prvním problémem, na který studenti obvykle narazí, je určitě chybějící čeština. Visual Studio je dostupné jen v několika světových jazycích, jiné nástroje jsou často pouze v angličtině. Ačkoliv by bylo pěkné, aby studenti programování uměli základy angličtiny, v praxi tomu tak často není, speciálně pak u dětí. Cizojazyčnost v principu vždy bude velkým nepřítelem „průměrného studenta“. Přeložit do češtiny je však potřeba především delší texty a nápovědu k jazyku a vestavěným třídám a funkcím; základní položky v menu jako File nebo Exit obvykle chápe i jazykově méně zdatný student a jejich přeložením do češtiny žádný opravdu velký přínos nezískáme. Konkrétně Visual Studio má v poslední verzi 2010 k dispozici i český překlad. Má však dva zásadní nedostatky, které jeho užitečnost značně snižují: Lze jej použít jen ve vyšší placené edici a nejde o kompletní překlad všech textů i s nápovědou MSDN. O něco lepší situace s překladem může být konkurenčních u open source nástrojů, kde se na vývoji jazykových mutací může podílet celá řada dobrovolníků. Zejména u nápovědy je překládání komplikováno především jejím velkým rozsahem. Překládání vývojových nástrojů do jiných jazyků obecně má však jeden zásadní problém: Je to dvojsečná zbraň. Student programování zvyklý a zhýčkaný svým rodným jazykem ve vývojovém prostředí bude mít o to větší problémy v reálném prostředí programátorské praxe, stejně tak mu nepomohou různá vývojářská fóra na internetu apod. Všechny nápisy by v podstatě musely být zobrazeny vždy současně ve dvou jazycích, aby bylo možno efektivně pracovat v týmu a používat rady a poznámky zveřejnění na internetu. Úplně počeštění celého vývojového prostředí je tedy jak nereálně obtížné, tak kontraproduktivní. 3.6
Učitelem řízené projekty
V předchozích sekcích jsme se většinou zaměřovali především na potřeby začátečníků, což je i logické vzhledem k tomu, že právě začátečníci mají s programováním největší problémy a právě oni nejvíc potřebují speciální vlastnosti vývojových nástrojů. Po zvládnutí základů se z úspěšných začátečníků stávají mírně pokročilí a ti začnou již mít trochu jiné potřeby. Jednou z chybějících funkcí vývojových nástrojů obecně je typicky zcela nulová podpora učitelem řízených projektů. Pojem „řízení učitelem“ není nikterak exaktní a může mít u studentských projektů mnoho podob. V prvé řadě chybí podpora pro projekty, kde student má jen dopsat část kódu do existující kostry programu. Chybí možnost zamknout nebo i skrýt části projektu apod. Po odevzdání hotového projektu pak chybí jakákoliv podpora pro automatizované ověření správnosti řešení. Na zde zmíněné věci je jistě možno
vytvořit vlastní studijní framework, nebo alespoň do jisté míry, je však s podivem, že samotní autoři Visual Studia nemají vůbec potřebu získávat větší market share prostřednictvím bohatší podpory studentů. 3.7
(Ne)ladění
Ladění programů a s ním související věci jako krokování, breakpointů apod. patří k velmi důležitým součástem programátorské práce. Konkrétně Visual Studio má v tomto ohledu velmi dobrou pověst – obsahuje poměrně velké množství rozličných funkcí pro ladění programů nativních i řízených ve všech jím podporovaných programovacích jazycích. Zkušenost ukazuje, že tyto nástroje používají spíše pokročilejší programátoři, zatímco studenti jen málo a speciálně začátečníci v této oblasti dost tápou. Důvodem tohoto „školního neladění“ může být zřejmě i nedostatečné věnování se problematice ladění ve výuce; téma „Jak efektivně ladit programy“ se v rámci kurzu programování mnohdy neobjeví vůbec, zvláště pak v kurzech pro začátečníky. Druhým problémem je však i přílišná složitost ladicího systému a strohost jeho uživatelského rozhraní. Pro příklad si představme situaci, kdy řízený program v Basicu či C# obsahuje chybu, nastane neošetřená výjimka a program lidově řečeno „spadne“. Visual Studio se namísto pádu programu dostane do ladicího režimu a programátor má celou řadu funkcí k analýze a opravě chyby. Začátečník by v tomto okamžiku však potřeboval jakousi pomocnou ruku v podobě lepší nápovědy (samozřejmě v češtině) a uživatelské rozhraní by mohlo v ladicím režimu nabídnout alespoň základní funkce v podobě například 5 cm velkých barevných tlačítek, kterými by program studenta sám navedl, jak dál postupovat. Podobně při krokování (tj. ladění bez výskytu chyby) by nějaká srozumitelnější forma velkých barevných tlačítek s českou nápovědou pomohla řadě studentů překonat strach a pustit se do ladění. Odhlédneme-li od specifických potřeb začátečníků, studenti obecně zřejmě budou mít v souvislosti s laděním i další potřeby, které jsou stejné jako u programátorů v praxi. Výhodná je například funkce „edit and continue“, tj. možnost opravy běžícího programu a pokračování na změněném kódu bez restartu celého procesu. Visual Studio ji však nepodporuje na 64bitových počítačích. Dodnes taky chybí například možnost sledování nativních programů v C/C++ ve virtuálním stroji, který by automaticky kontroloval dodržování velikosti polí nebo sledoval, který příkaz zapisuje kam do paměti, díky čemuž by bylo vidět, co se v programu děje s pointery, odkud se paměti vzala ta či ona hodnota apod. Stejně tak není zatím možno krokovat programy dozadu a tím se pokusit vysledovat, odkud se chyba v programu vzala. Zmíněné zatím v praxi (ve Visual Studiu) nemožné metody ladění by se hodily například do situací, kdy se nám chyba nějak zjevně projeví až daleko později, než kdy vznikla. Zvlášť v nativních programech pracujících s pointery je pak někdy již dost těžké místo vzniku chyby dohledat.
3.8
Jazyky C a C++
Jazyky C a C++ jsou dnes v praxi nejpoužívanějšími jazyky pro tzv. nativní programování. Jejich základní společná vlastnost, kterou se odlišují od většiny dalších dnes ve školství populárních programovacích jazyků, je absence automatické správy paměti. Narazí-li student začátečník na výuku takového jazyka, jednou z velkých překážek mu bude práce s pointery a paměťové chyby. Visual Studio v tomto směru vždy nabízelo mnoho pomůcek k detekci a identifikaci paměťových chyb, avšak jejich pochopení a používání nepatří k nejjednodušším a z tohoto důvodu bohužel nejsou moc užitečné pro začátečníky. Opět zde chybí lepší komunikace Visual Studia směrem ke svému uživateli – programátorovi či studentovi. Zde mimochodem vidíme typický jev u rozsáhlých počítačových programů. Autoři velkých softwarových produktů opomíjejí potřebu sebepropagace těchto programů směrem k jejich uživateli – vývojové prostředí jakoby ani nechtělo, aby jej uživatelé plně využili. Vše se soustředí jen na technickou povahu věci a samotná přítomnost ladicí či jiné pokročilé funkce vývojového prostředí je konečným stavem. Dalo by se říci, že programům chybí „duše“ – poskytují stále širší a širší pole funkcí a přitom je jim zcela jedno, jestli to někoho z jejich uživatelů vůbec zajímá. Tato problematika jde však daleko za rámec tohoto textu.
4
Závěr
V tomto příspěvku jsme se zabývali problematikou používání běžných komerčních vývojových nástrojů ve výuce programování. V první části jsme si stručně popsali současnou situaci ve výuce programování, především v českých vysokých školách. Tím jsme nastínili kontext a rámec pro další část textu, kde jsme na vzorovém příkladě Visual Studia diskutovali jeho využitelnost pro výuku. Visual Studio je známý a hodně používaný vývojový nástroj, a to jak v praxi tak ve výuce. Pokusili jsme se zde konkrétně pojmenovat několik jeho slabých míst z pohledu potřeb výuky, přesněji řečeno očima studenta a očima jeho učitele.
Reference 1. ACM: Computing Curricula 2005: The Overview Report. http://www.acm.org/education/curricula-recommendations/ 2. Microsoft: Microsoft Visual Studio. http://www.microsoft.com/cze/msdn/vstudio/2010/ http://msdn.microsoft.com/en-us/vstudio/
Annotation On Teaching of Programming with Common Development Tools Paper discusses the topic of teaching programming with common commercial development tools. First part of text briefly describes current situation in teaching of programming, especially on Czech colleges. We show that it isn’t fully possible to teach programming with only special school-oriented tools and must soon or later also use common commercial tools. This gives us context and framework for the second and main part of paper, which takes Visual Studio as an example development tool and discusses primarily its weak points from teaching point of view. We name particular problematic or missing functions, which are important from student’s or teacher’s point of view.
