Pojem algoritmu je pro první přiblížení irelevantní. Reaktivní a ani interaktivní programy (např. v Greenfootovi nebo pro Arduino) nemívají algoritmický charakter (nebývá to postup vedoucí k výsledku a ani postup výpočtu nemusí být z hlediska programátora jednoznačný – determinovaný). To jsou mýty didaktiků informatiky, kteří v životě nic pořádného nenaprogramovali. Pojem algoritmu začne být zajímavý, když dojde na matematickou logiku a důkazy, ale to snad jedině někde na matfyzu, na základní ani střední škole ne.

„ne všechny jazyky jsou programovací!“ – a ne všechny programovací jazyky jsou algoritmické. Některé jsou např. specifikační (SQL, Prolog…) a jiné připouštějí nejednoznačnost v pořadí elementárních kroků (např. při multithreadingu).

„převod ze zdrojového kódu do spustitelného programu: – interpretace;“ – no ale vždyť právě při interpretaci se interpretuje zdroják, aniž by se převáděl do spustitelného programu…

„přímý přístup k HW součástem počítače;“ – to není otázka jazyka. Když budu psát aplikační program pro Windows v assembleru nebo třeba šestnáctkově ve strojáku pomocí debuggeru, nemůžu se dostat přímo k hardwaru, ale musím využít API operačního systému. Když budu naopak psát ovladač nějakého periferního zařízení, můžu ho psát v C nebo v jiném ještě vyšším jazyce, a podobně třeba kdybych chtěl naprogramovat svůj vlastní OS pro holý počítač a překládat křížem.

„vysoká náročnost pro programátora;“ – jazyk by měl být přiměřený úloze. Naprogramovat webovou aplikaci v assembleru může být pro programátora opravdu náročné, ale ještě náročnější by bylo programovat device driver ve Fortranu nebo v Prologu a v Cobolu by to asi bylo zhola nemožné.

„interpretované“ – čistě interpretované bývají tak leda shellové skripty, před 50 lety třeba Basic, ale to už dneska asi není pravda.

„interpretované – překlad ze zdrojového kódu do spustitelného kódu probíhá za běhu programu;“ – když se program interpretuje, tak se nepřekládá; a když se překládá v runtimu, tak je to JIT-kompilace, ale ne interpretace (např. C# pro .NET)

„interpretované – lze měnit datový typ proměnné;“ – to je složitější, radši bych to vynechal (proměnné se dají typovat různě a různě se dá provádět i typová kotrola)

„kompilované – rychlejší běh programu;“ – to otázka… Např. kompilovaný basic na JPR-12 byl pomalejší, než kdyby byl interpretovaný. Jinak rychlost interpretace bytecodu nebo CLR apod. bývá jen nepatrně pomalejší než kompilace do strojáku. Proslulé jsou např. kompilace z různých jazyků do javascriptu (s dokonalou přenositelností a vynikající rychlostí interpretace). Kompilace JIT taky může docela zdržovat, ale ve srovnání se zdržením, které může způsobit např. garbage-collector to nestojí za řeč. Tu poznámku by zřejmě bylo lepší vynechat.

Neprocedurální jazyky jsou především jazyky specifikační (např. OBJ2, OBJ3, SQL, RPG, UML) a ovšemže i logické. Bývají sem řazeny i jazyky funkcionální (lisp, Lua…), ale tam je postup výpočtu jednoznačně určen zápisem programu, takže opravdu nechápu, co je na tom neprocedurálního. To pak můžete za neprocedurální jazyk považovat i objektový smalltalk.

„procedurální = imperativní – strukturované; – objektově orientované (OOP);“ Jsou i nestrukturované a ne-OO jazyky (assemblery, Basic, Fortran – prostě všechny jazyky s „GOTO“). A naopak i v assembleru se dá programovat strukturovaně, když se použijí vhodná makra nebo stanoví konvence pro skoky.

„zápis programu (algoritmu):“ – pozor! Při zápisu algoritmu se neobejdete bez rekurze! Jsou algoritmy, které se nedají naprogramovat čistě strukturovaně (např. backtracking).

„program se skládá z: hlavního programu; podprogramů;“ – To třeba v Greenfootovi nebo ve Pharu fakt těžko rozlišíte… Ve Fortranu to bývala pravda, ale obecně to nedává smysl.

„Úkoly“ – Kolik je neobjektových procedurálních jazyků bez GOTO? Modula, Ada? Na další si honem nevzpomínám, musel bych hledat a zjišťovat, které mají GOTO. Kdo dá dohromady pět takových jazyků? A kdo dokáže posoudit, které odpovědi jsou správné? A co vyhazování výjimek – považujete je za strukturované? To by Vám asi Zohar Mana neuznal (viz „Matematická teorie programů“), o Tonym Hoarovi ani nemluvě. Považujete lisp za strukturovaný jazyk? Pak ale smalltalk a další objektové jazyky byste měla považovat taky za strukturované.

Celkový dojem: Jako závěrečné shrnutí tématu snad ano, jako „stručné seznámení s pojmy“ je to nepoužitelné. Očekávaný výstup nějak úplně úplně mimo, o uplatnění ICT přece v prezentaci vůbec nejde. Chybějí příklady, prezentace sama o sobě není názorná – člověk neví, co si má představit. Spíš bych dal dětem tvořit něco ve Scratchi, v Greenfootovi nebo v Pythonu (podle věku a pokročilosti) a pak jako shrnutí příp. promítnul tuto prezentaci (zkrácenou a opravenou). Je to dlouhé – tak trochu o všem a celkově o ničem.