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.
