Názory k článku Programovací jazyk Ada pro úplné začátečníky

http://www.theregister.co.uk/2015/05/01/787_software_bug_can_shut_down_planes_generators/

Je to sice pruser ale jedna se jen o generatory u motoru - kazdy motor ma 2.
"If the four
main GCUs (associated with the engine mounted generators) were powered up at the same time, after 248 days of continuous power..."
Na leteckem prumyslu je krasne to ze se spoleha na redundanci na vsech urovnich vcetne te lidske,
I kdyby selhaly vsechny ctyri GCU, tak neni problem nahodit APU a vytapet s ni jeste bazen...:)
Na prechod nahleho vypadku staci baterie(ano ty dymajici;) nastesti se to netyka startovacich na APU a pripadu vybijeni;) 787 ma jednak po novu elektricke hydra pumpy na palube, ale take ma tradicni hydra pumpy pres mechanicky nahon v motorech. Takze se jich vypadek generator control unit nedotkne.

Na druhou stranu pokud bude cist pilot dva kilometry dlouhy checklist a odtukavat failed systemy tak ani tech 10 minut v baterkach nemusi stacit... Nekdy se za svuj obor dost stydim. Piloti nas musi mit dost za nezodpovedne <zdrobnelina od slova hlupak> a maji pravdu.

2x225kVa bohate staci. Asi se poleti v low power rezimu, takze vytapeni bazenu a sauna nebude k dispozici a kafe studeny...

Tak je jen otazka casu, kdy piloti z kokpitu zmizi. Ti v Boeingu pilotuji prumerne 7 minut za let, zatimco v Airbusu jen polovinu casu. Jsou drahy a litaj s letadlama do skal kdyz maj depresi :)

K veci - jak muze takova chyba vubec vzniknout? Nepouzivaji se formalni metody jako napr. abstraktni interpretace?

K veci - jak muze takova chyba vubec vzniknout? Nepouzivaji se formalni metody jako napr. abstraktni interpretace?

Formálně ověřit nějakou vlastnost může být docela náročné. Pokud tedy nástroj pro analýzu programu řekne, že něco neumí ověřit, tak se to IMO většinou nechá na lidech.

Navíc může být chyba v HW, chyba v kompilátoru jazyka, chyba v nástroji, co ověřuje vlastnosti programů - málokdy má kompilátor nebo pomocný SW formální důkaz správnosti.

Vše je navíc komplikováno faktem, že jazyky nemají formální specifikace.

No, ano, v dostatecne vysokourovnovych skriptovacich jazycich je mozne napsat
"aplikator" (at uz to bude makro, nebo funkce, nebo objekt).

Jen se mi ho nechce pro kazdy jazyk psat znovu a vymyslet, jak to udelat obecne, kdyz se mi tam budou michat (globalni) funkce a metody toho objektu, tak aby to zustalo citelne.

To jak o dane veci premyslis nemusi znamenat ze tak budou premyslet ostatni lide v tymu. Citelnost daneho kodu tak muze byt znacne subjektivni zalezitost.
To ze o dane veci nejak premyslis neznamena ze to bude dostatecne prehledne napsano tak, aby se kolem nesesel hloucek lidi "co tim chtel basnik rici".

Souhlas. Čitelnost a tedy dlouhodobá udržitelnost kódu je IMO daleko důležitější, než dokonalost z pohledu teorie programování.

Pokud bude ta vec "bez zahusteni" napsana na jednu, nebo dve radky misto na deset, tak to vyrazne zvetsuje rozhled (kontext) ctenare programu.

Jako ilustraci, kde je to videt asi nejlepe je pythonovske:

[ foo(x) for x in bar if foobar(x) ]

misto extremniho pseudokodu (je fakt, ze podobne hrozny byl snad jen bash):

ret = array()
for (int i=0; i<bar.length(); i++) {
if (foobar(bar[i])) {
ret[ret.length()] = bar[i]
}
}

Oboji je napsano blbe. Kod dole vratim vyvojari k prepsani.
Kod nahore v pythonu opatrim komentarem ze by to mel rozdelit aspon v te podmince protoze clobrda co to po nem bude zkoumat v te hromade kodu tohle prehledne. Mezitim mne predbehne asi nekdo kdo dela review a "usmerni" juniora z matfyzu. A to nemam kdovijake naroky na citelnost a kvalitu ( v pythonu by to byl asi stejne normalni neuzitecny webovy odpad ) jako vyvojari avioniky kde se diskutuje o kazdym znaku.

Jde o to ze kdyz do toho bude nekdo cucet, tak pythonovskeho radku si nevsimne podminky a druhy radek je tak priserny ze to zas prepise aby to bylo citelnejsi.

Ten řádek v Pythonu je čitelný dostatečně. Samozřejmě za předpokladu, že identifikátory nebudou foo, bar, baz...

Neni citelnej ve velky zmeti kodu. Rozdelat for a if na vic radek. Citelnost na prvnim miste. Uspora na druhem. Ale jo nektery projekty maji guidelines natolik volny ze to dovoli.

To by ses divil, ale my máme guidelines dost striktní. Např. před takový řádek píšeme komentář. A vyhýbáme se velké změti kódu. Chápu ale, že tohle je dost subjektivní.

Jen jsem zastáncem toho názoru, že začátečníci by měli dostat do ruky něco prakticky použitelného a ne nepraktické krámy vhodné jen pro výuku.

Studenti informatiky na VŠ by měli dostat do ruky něco, co je dobře navrženo - nejspíše se tím totiž budou sami inspirovat.

Bohužel mainstreamové programovací jazyky jsou navrženy dost podivně - už takové základní věci jako proměnné nebo "rovnost" tam jsou špatně. Nemluvě o tom, že tam neplatí ani základní zákony aritmetiky jako asociativita sčítání.

Myslím, že Clojure tam nepatří, Smalltalk nevím.

Scheme - v podstatě souhlasím.

Nelíbí se mi, jak z Clojure prosakuje JVM - to je možná výhodné pro praktické použití, ale jazyk to komplikuje.

Příkladem jsou protokoly, které tam jsou AFAIK proto, že jsou efektivnější než multimetody. Nebo absence TCO - místo toho je třeba použít trampolínu. A nakonec celé Java Interop.

dozví se o transakcích (a to možná pochopitelnějším způsobem než později při probírání DB) a ten jazyk je navíc praktický.

S tím souhlasím, podpora pro konkurentní programování je v Clojure velmi dobrá a navíc je to jednoduché (na rozdíl od Haskellu).

Smalltalk je mimořádně vhodný pro objektové paradigma, možná nejlepší, problémem je, že v případě pozdního seznámení s tímto čistým konceptem hrozí šok, který dotyčný obvykle nerozchodí.

Student by si neměl plést programování s matematikou. Pokud je více low level zaměřený tak by hlavně mel zhruba vědět co Compiler asi vyrábí za instrukce pro danou arch a jak psát kód aby ho mohli číst I jiní z týmu. Obvykle je I přehlednost více zadaná nes nějaký Brutus algoritmus v pěti radkach který nikdo nedesifruje.

„Studenti informatiky na VŠ by měli dostat do ruky něco, co je dobře navrženo - nejspíše se tím totiž budou sami inspirovat.“

Podstata programování se dá vysvětlit pouze na čistých konceptech bez balastu (má pár jazyků) a pak studenta konfrontovat s praktickými implementacemi těchto konceptů v používaných jazycích, aby bylo zřejmé, jak to kdekterý samozvaný vořežprut zkurvil. To, si myslím, je nejlepší školou.

Musím oponovat, ale základy latiny byly jedním z nejužitečnějších předmětů, který mi na střední škole vtloukli do hlavy. Nejen kvuli dalsim jazykům (nejsem humanitní typ), ale především kvůli přírodním vědám. Je úplně jiné kafe skutečně rozumět odborné terminologii než s ní zacházet jako s magickými formulemi.

Takže se ten Pascal mají učit později???

Jo, to si pamatuju dodneška z přednášek - plusplusáků z průmek byla narvaná aula, všechny ostatní jazyky odmítali se slovy, že přece „takové pičoviny se učit nebudou“.
Osobně považuju C++ za jednu z největších sraček, co kdy vznikla, a pro výuku programování vyloženě za škodlivý.

http://en.wikipedia.org/wiki/Design_by_committee

Vypada to ze na tech vysokych skolach stale porad neco vynechavaji... a tim nemyslim v tomto pripade ty technicke.

Jazyk k jehoz studiu potrebuji bichli tlustsi nez Stary a Novy zakon, uz ze sve podstaty musi byt tak perfektni jako pitoreskni umelecka montaz z velkeho mnozstvi ruznorodeho komunalniho odpadu.

C++ jeste neni tak hrozne. Da se to ucit postupne behem pouzivani. Je to sice slepenec, ale alespon se trochu snazi o to, aby kdyz se clovek nauci nejakou jazykovou konstrukci, tak mu fungoval vicemene vsude. Narozdil treba od PHP, to je slepenec, ktery se snazi cloveka odnaucit nove konstrukce, protoze vetsinou funguji jen v zakladnim pripade a kombinace dvou pokrocilych konstrukci vyhodi chybu kompilace. (No dnes uz je to mozna o trosku lepsi, tenhle pocit mam z doby PHP 5.2)

C bylo pro výuku nevhodné vždycky, ale báječně se v tom pracuje. C++14 je nevhodné pro výuku i pro práci, příšerná hydra. :)

Namátkou není deklarace proměnných, typová kontrola, předávání parametrů odkazem, case, výčtový typ, overloading, interface, funkční multithreading.
Samozřejmě na všechno můžete říct že se to naučí cestou :-)

Mluvím obecně, napřed žáky naučit že při volání funkce se neřeší datové typy parametrů a poté jim vysvětlit že v praxi v C++/C#/Java to funguje zcela jinak, je jako u blbečků na dvorečku. Takových věcí je tam víc, nebudu to rozvádět.

Zrovna matematika a fyzika se v současné době učí dost blbě. Jestliže máte dojem že zmíněná záležitost v Pythonu není průšvih, pouze je "jiná", pak nemá smysl pokračovat.

Ze se pri tom typy neresi neni pravda, typovani v Pythonu je silne.

To je takový ten pohled ze základky, řečeno vašimi slovy. Ve skutečnosti tam nejsou žádné typy (alternativně můžeme říci, že tam je jeden typ a vše má tento typ).

Jiné typování než statické neexistuje:

• Does “untyped” also mean “dynamically typed” in the academic CS world?,
• Dynamic Languages are Static Languages
• nebo kniha Types and Programming Languages od Benjamina Pierce.

A kdo mel v rukach par zacateciku vi, ze ze zacatku jsou radi za kazdy cyklus, co zvladnou, a to, ze za par let mozna potkaji jazyky, ktere se na veci divaji hodne jinak, je jedno - maji problem prezit pristich par tydnu

S tím souhlasím, také nenavrhuji Coq nebo něco podobného, ale navrhuji Racket a Standard ML, což jsou decentní jazyky.

Bud jak bud to nic nemeni na tom, ze Python to udelal vzhledem k ucelu a dobe vzniku vicemene dobre.

Jak jsem zmínil výše, vadí mi i takové drobnosti jako (něco z toho platí i pro Python):

• vestavěná "rovnost" není ekvivalence a v jazycích s podtypovým polymorfismem není úpně snadné rovnost implementovat tak, aby se chovala jako ekvivalence (viz triky jako canEqual),
• standardem je referenční rovnost (místo strukturální) a vedlejší efekty (i vytvoření objektu je vedlejší efekt),
• do proměnných jde přiřazovat (nechovají se jako matematické proměnné),
• aritmetika s čísly v plovoucí řádové čárce je složitá (např. aby člověk správně implementoval funkci počítající průměr, musí vědět něco o numerické stabilitě),
• chování kódu nejde zjistit bez použití hex editoru nebo spuštění (např. Java, stačí vzít vhodný Unicode identifikátor a jednou ho normalizovat do NFD, podruhé do NFC a máte dva různé identifikátory, co vypadají úplně stejně).

Dříve jsem si myslel, že Python je dobrý jazyk (ale moc jsem se o něj nikdy nezajímal), pak mi dal JS1 následující odkazy a už si to nemyslím:

• Revenge of the Types
• a diskuze.

Jazyk Standard ML vznikl (1990, revize 1997) dříve než Python a přesto mi přijde mnohem lépe navržený. Viz například formální specifikace The Definition of Standard ML, Revised a seznam chyb Defects in the Revised Definition of Standard ML.

Mj. z výše zmíněných nedostatků řeší Standard ML vše kromě "aritmetika s čísly v plovoucí řádové čárce je složitá".

Tak urcite. Ted se muzeme zacit trumfovat delkou brad akademickych autoru, kteri tvrdi ruzne veci. ja si mohu vytahnout trebas Erika Meijera.

Tohle je o tom, že po roce 1990 vznikl standardní způsob, jak specifikovat programovací jazyky (přesněji jejich core kalkuly) a jejich typové systémy, který dnes drtivá většina lidí z oboru používá. Osobně nevidím žádný důvod, proč vytvářet definice, které jdou buď proti tomuto standardnímu způsobu (dynamické typování), nebo nemají žádný přesný význam (např. silné typování).

Vytáhněte Erika Meijera.

Mohl bych poprosit o vysvětlení předposledního odstavce?

Jak chápu silné vs statické typování já, jde o to, že:

1. Objekt má nebo nemá konkrétní typ. Pokud má (Python), je možné se na něj zeptat a dá se očekávat, že se bude chovat nějakým způsobem. Pokud nemá (Perl, JavaScript, ale třeba i C s přetypováváním ukazatelům a prací přímo nad pamětí nebo Java s přetypováváním na Object a zpět), v závislosti na kontextu je to pro nás jeden typ nebo jiný typ. První případ nazýváme silným typováním, druhý slabým.

2. Chlívek/štítek striktně obsahuje (odkazuje na) hodnotu určitého typu daného obyčejně deklarací. To je statické typování. Pokud je ten chlívek nebo štítek typově agnostický, je to dynamické typování.

Co je na takovém dělení špatné nebo proč Ti to připadá neužitečné?

Obvykle má zpracování programu dvě fáze - statickou a dynamickou. Statická fáze je to, co se děje před spuštěním (parsování, typová kontrola), a dynamická fáze je vykonání programů, které úspěšně prošly typovou kontrolou.

Programy, jenž neprošly úspešně typovou kontrolou, se obvykle nevykonávají - ani se jim nepřiřazuje význam.

Typový systém je sada pravidel, jak přiřadit typy částem programu - například výrazům. Tj. typy nejsou přiřazovány jen hodnotám jako například číslu 5 nebo řetězci "ahoj", ale i celým výrazům například cos x + i*sin x.

Existují různé typové systémy (sady pravidel) - v některých mohou typy obsahovat kvantifikátory, příkladem je typ prázdného seznamu ∀x.[x]. Často pak můžeme za vázanou typovou proměnnou dosadit (např. za x) a dostat tak jiný typ (takto například můžeme odvodit, že prázdný seznam má nekonečně mnoho typů). Typové systémy s podtypovým polymorfismem obsahují pravidlo subsumce, které říká, že má-li výraz e typ s a je-li s podtyp t, pak má výraz e typ t. Výraz tedy může mít neomezeně mnoho typů.

Typový systém rozděluje výrazy programu do skupin a říká, jaké výrazy jde použít v jakých situacích.

Programům, jenž prošly typovou kontrolou, je přiřazen význam - sémantika. Například operační sémantika určí, jak se mají výrazy vyhodnocovat. Zde už se typy nepoužívají. Výraz se vyhodnocuje tak dlouho, dokud to jde. Vyhodnocení tedy nemusí skončit. Když už nejde výraz dále vyhodnocovat (neexistuje žádné pravidlo operační sémantiky, které by šlo na výraz použít) máme buď hodnotu nebo chybu (angl. stuck). Například operační sémantika neříká, co dělat s výrazem 1 + Pes(), tudíž máme chybu.

Smyslem typového systému je, aby se předešlo chybám. Typový systém, který to dokáže se nazývá korektní. Obvykle se dokáže, že 1) postupné vyhodnocování nemění typ (preservation) a 2) má-li výraz pevný typ, tak je to buď hodnota nebo jde vyhodnotit (progress).

Pozn.: U některých jazyků se typ výrazu mění při vyhodnocování, tudíž se to musí dokázat trochu jinak.

Typ tedy předpovídá nebo odhaduje chování výrazu při vyhodnocování, korektnost typového systému neboli typová bezpečnost zajišťuje, že tyto předpovědi jsou správné.

Například jazyk C není typově bezpečný neboť tam můžete přetypovat cokoliv na cokoliv jiného.

Například Python definuje sémantiku pro všechny výrazy, co se podařilo naparsovat - tedy neprobíhá žádné rozdělování výrazů do skupin s tím, že na určitých místech jde použít jen některé výrazy - například vyhodnocení výrazu 1 + Pes() může vyhodit výjimku (sémantika výrazu je definována). Můžeme to chápat tak, že v Pythonu existuje pouze jedna skupina výrazů, pouze jeden typ.

Hodnoty v Pythonu mají tzv. tagy - nesou si nějaký štítek, z něhož lze zjistit například název třídy. Podobně mají i některé hodnoty v Javě štítek a také tam lze zjistit název třídy, ale tento název třídy není typ - například můžeme vytvořit instanci třídy Pes a uložit ji do proměnné typu Zvíře - pak je typ proměnné Zvíře, ale hodnota má štítek Pes.

Na rozdíl od typů štítky (neboli tagy) existují za běhu programu a jsou pouze na hodnotách, nikoliv na výrazech. Na hodnotě obvykle bývá nejvýše jeden štítek, ale hodnota může mít nekonečně mnoho typů.

Díky za odpověď. Nemůžu říct, že by to nedávalo smysl, ale podle mě je to prostě jiné pojetí ontologie. Když je v Pythonu (nebo jiném OO jazyku, třeba Smalltalku) nějaký objekt instancí třídy Pes, prostě je to pes a chová se jako pes. Tam, kde se typy deklarují (inferují) staticky, tam je samozřejmě úplně jedno, že jde o psa, jednou se rozhodl chovat jako Zvíře a už z toho nemůže vyskočit (no, v Javě a dalších jazycích může, ale to je spíš smutné).

Proti teorii typů vystupovat nechci, užitečná je, ale v praxi mi přijde zbytečné argumentovat tím, že daná hodnota má štítek, protože pes prostě JE pes. Je instancí třídy Pes a v Pythonu na to existuje funkce type(), která vrací typ objektu. Jelikož tvrdíš, že v Pythonu existuje (ze statického pohledu) pouze jeden typ, nevidím smysl to dále zkoumat touto optikou a musíme použít jinou. Zásadně nesouhlasím s používáním pojmu "typový štítek", protože to není pojem ontologický, nýbrž implementační. Pokud to mělo být pouze k dovysvětlení, OK, tam mi to nevadí. Pak se vracíme k dilematu typ výrazu a typ hodnoty. V čase běhu programu má každý objekt v Pythonu jednoznačný typ (je instancí třídy), tj. hodnota má typ. Jestli je daný štítkem nebo čím jiným je přece jedno, programátora to nezajímá a z hlediska ontologie to nic neřeší.

Pro programátora to má význam v tom, že se může spolehnout na informaci dostupnou v době běhu programu (prostřednictvím type() například). Dokonce ale, s určitou mírou jistoty, lze typy dovozovat i statickou analýzou, pokud do hry nevstupuje eval vstupu od uživatele apod. Pak, přestože Python nebyl navržen s přihlédnutím k teorii typů, lze dosáhnout podobného výsledku jako u jazyků typu ML. Problém vidím spíš v tom, že Python nemá algebraické datové typy a věci okolo. Tam mi ty typy začínají teprve dávat pořádný smysl, protože už neslouží pouze ke kontrole správnosti, ale umožňují jasnější vyjadřování myšlenky programem.

BTW docela dobrá skriptíčka o typových systémech jsou z kurzu Type systems, jenž pořádají francouzské univerzity.

Za odkaz děkuju, podobné věci mě zajímají.

OK (uvažuju hlavně Python):

není deklarace proměnných - to je koncept poplatný určité skupině jazyků, každý pochopí hned, když se mu řekne, že než nějakou proměnnou začne používat, musí to v jazyce BŽ napřed nahlásit

typová kontrola - typová kontrola při kompilaci? v jazyce BŽ není možné všechno strkat kamkoliv, když nadeklarujete typ, musíte ho držet (jasné hned). Navíc v jazyce DŽ není možné stejnému jménu přiřadit jinou hodnotu nikdy!

předávání parametrů odkazem - u nás jsme všichni odkaz

case - no to záleží jaké case máme na mysli - v jazyce BŽ je to syntaktický cukr pro if/else, v jazyce DŽ se bavíme o variantách hodnot jedné proměnné, v jazyce FŽ jde o pattern matching, ne, fakt nejde o regexpy

overloading - nevedeme (dost specifická záležitost, něco jako multimetody v jiných jazycích)

interface - nepotřebujeme, máme násobnou dědičnost, na rozdíl od jiných...

funkční multithreading - z hlediska teorie máme, v praxi záleží na okolnostech, umíme ale navíc multiprocessing, asyncio a jiné finty

Nemá smysl to takto dál pitvat, každopádně i myslím, že je lepší se naučit používat základní datové struktury a koncepty a pak si ukázat, jak to řešit v C (spojový seznam, dynamicky alokované pole, pointerová aritmetika) než se trápit s hello worldem a přemýšlet, proč má main návratovou hodnotu int nebo void, jestli je parametr *arg[] nebo **argv, kde použít printf() a kde puts() atd.

Nehledě na to, že moderní programovací jazyky přicházejí často s konstrukcemi ve světě C/Pascalu/Ady apod. nevídanými. A mainstream (C#, Java, C++) to nějakým způsobem reflektuje.

Prostě je to zprasené a nedodělané, ale z principu to budeš obhajovat to roztrhání těla :-) Zrovna multithreading je průser jak mraky.

Já nic neobhajuju. Programuj si klidně v C++, pokud Ti přijde nezprasené nebo v jakém jazyce se Ti dělá nejlíp a nejvíc vyděláš, to je fuk. Jenom tvrdím, že k výuce základů programování podle mě nejsou C++, Java, Ada ani Pascal vhodné a svoje argumenty jsem uvedl.

Ten zbytek je na jinou debatu a na tu nemám náladu tady ani jinde, sorry. Já se snažím k problematice přistupovat profesionálně a když po mně zákazník bude chtít, abych naprogramoval neco v APL nebo Cobolu, udělám to. Z jazyků mě momentálně nejvíc zajímají Haskell a Rust a Python mě živí. Jeho slabiny znám velice dobře, ale snažím se je vidět v souvislostech, protože žádný superjazyk se samými výhodami a bez nevýhod neexistuje, jinak by nikdo nic jiného už na nic nepoužil.

Výborně a který jazyk je vhodný k výuce, jestliže nelze studenta posadit k C++/C#/Java ? Python to totiž není taktéž.

Mně by ten Python nepřišel úplně špatný. Když to vezmu obecně, řekl bych, že:

1. By to měl být jazyk, u kterého Hello world nepotřebuje 10 řádků kódu, aby šel vůbec spustit.

2. Jazyk nepotřebuje šílené IDE, pokud bude mít REPL, o to lépe.

3. Asi bych preferoval syntaxi ala Algol před Lispovou.

4. Měl by mít k dispozici ideálně nějaké vyšší abstrakce, ne jenom větvení a cykly a komplexnější datové struktury (množiny, hashe apod.). Jestli by byl dynamický nebo statický je mi vcelku jedno. Obojí má výhody a nevýhody.

Souhlasím. Ještě dodám:

Člověk (např. učitel) by měl být schopen se naučit celý jazyk. Když dostane nějaký výraz v daném jazyce, měl by ho být schopen vyhodnotit (resp. dělat kroky, které k vyhodnocení vedou). V ideálním případě by měl být schopen i o nějakém řetězci rozhodnout, zda je to vůbec výraz v daném jazyce.

Indikátorem je délka formální specifikace (pokud tedy jazyk vůbec nějakou má). Například ne více než 100 stran.

To jako syntaxi? Tak to má Smalltalk tak na půl.

Myslím, že nejen syntaxi, ale i třeba metatabulky.

A pomocí metatabulek lze naimplementovat objektový model. Za výhodu považuji to, že takový objektový model není přímou součástí jazyka, takže si můžeš přečíst a pochopit jeho zdrojáky a případně je i někde zmodifikovat.

Myslim ze mluvite o vecech ktere nejsou podstatne. To jestli je nejaky jazyk "modni zalezitost", nebo "cool" je absolutne irelevantni vec. Jak vubec nekdo, kdo zjevne uci programovani muze vubec neco takoveho napsat!?! To je neco co bych cekal od "HR specialisty" nebo jineho "nezasvecence".

Kdo s programovanim zacina, se hlavne musi CHTIT ucit programovat. A to dokazete prave jenom tim, ze uz v prvni hodine dokaze dotycny clovek vytvorit programek ktery neco (idealne vizualne zajimaveho) dela. Pokud dokaze napsat programek ktery zobrazi pohybujici se krouzek, bude nadseny a bude se tesit na dalsi hodinu a s nejvetsi pravdepodobnosti si stahne prislusne IDE/SDK doma a bude to zkouset sam a vymyslet co udela dalsiho a jak by to udelal atd.

Pokud ho prvni hodinu budete polovinu casu nudit definicemi na tabuli a pak na konci hodiny je nechate napsat hello world, tak jste pravdepodobne ztratil 90% vsech potencialnich programatoru ve tride.

A jeste dulezitejsi je, aby za 2 mesice, kdyz par lidi ve tride (je jasne ze vsechny to bavit nebude) dosahne vyrazne vyssi urovne, aby treba mohli zkusit z hybajicich krouzku udelat jednoduchou hru, nebo simulaci gravitacnich sil ve slunecni soustave a prulety sond.. to vsechno ale vyzaduje, aby ten jazyk, ktery se naucil byl dostatecne "mocny" na to, aby v nem byl schopen vyjadrit i komplexnejsi logiku stale stejne jednoduchym zpusobem. A to je bod, ve kterem vetsina "historicko-pragmatickych" jazyku (pascal, C++, ada, Java) totalne selze, a "primitivni" jazyky jako jsou rizne dialekty lispu (vcetne clojure), python, ruby, javascript a dalsi vyhravaji na cele care.

Kdyz rikate "OOP v každém jazyku jiné, událostní programování, datové struktury" zni to jako Vera Pohlova ("..ty vsechny higher-order functions vsechny jenom otravuji, ja bych vsechny ty vyssi jazyky zakazala!"). V celem tom odstavecku mi chybi nejaky obecnejsi rozhled. To ze je to v ruznych jazycich ruzne je jasne, ale v nekterych jazycich nektere veci VUBEC NEJSOU - jako treba podpora syntaxe pro asociativni pole, funkce jako first class object apod. To je podstatne. Nejde o to jak krypticky se zapisuje "object/class/wha­tever" ale o to jaky koncept to podporuje. A podle toho, jestli to podporuje koncept dostatecne jednoduse, pochopitelne a konzistentne se uz da jazyk vybrat snadno (hint: neni to ada ani c++)

Zkuste si na 2h (!!!) precist tutorial k pythonu a neco v nem napsat! Jde to primo samo, a brzy zjistite jak SNADNE a POHODLNE je psat neco v podobnem jazyku. A jake utrpeni je se snazit pak vratit k byrokraticke zrudnosti jako je Ada.

Ta byrokratická zrůdnost má své důvody, které jsou všeobecně známy. Sice nedělám v Adě, ale zato dělám ve VHDL.

Trochu mi to pripada, jako ze propagujete Python jako jazyk pro zacinajici programatory s poruchou pozornosti. Uceni musi byt alespon trochu "vopruz" a znacna cast lidi se programatory nestanou jednoduse proto, ze na to nemaji bunky.

Na uceni je potreba, aby to od zacatku v lidech alespon vyvolavalo dojem ze tomu rozumi a ze to maji pod kontrolou. A zaroven by to ale nemelo umoznovat odvatet pozornost uplne pryc.

Přesně tak. Víte, co je zajímavé? Že dodnes nejlepší návyky lze vypozorovat u těch, co začínali na Pascalu. Čím si to vysvětlit?

Podle "WTFs per minute"? :-D

Výborná měrná jednotka, hned jsem pochopil, co vyjadřuje. :)
Jak je to definováno v SI?

Naprostý souhlas. :D

"Vždy pište kód tak, jako by ho měl po Vás udržovat namakaný psychopat se sklony k násilí a znalostí vašeho aktuálního místa pobytu."
-- Martin Golding (ne uplně doslovný překlad, ale snad mi grammar nazi prominou :) )

To je snad zart?

Minecraft je i pro děti na prvním stupni žhavé téma. S oblibou tiskneme postavičky na 3D tiskárně.

Pokud by bylo možné k tomu bukkit/spigot a RaspberryJuice napsat něco víc, ideálně článek, jak to rozběhat a příklady ovládání, byl bych za to rád.

Ještě, kdyby to šlo bez placeného účtu to by bylo fajn.

Jasně, je to pro první stupeň, to jsou do MC nejvíc zažrané. Do školy se to ale nehodí, protože je neudržíš, aby nezačali spolu hrát a neztratili tak pozornost. Společný MC svět je pro ně mocné lákadlo.

Placený účet - používá se standardní MC klient, který se musí autorizovat vůči serverům mojangu. Kreknuté by možná taky šly, ale to jsem nikdy neřešil a řešit nebudu. Pro domácí "skupinovou výuku" není to pětikilo žádný problém. Samozřejmě ve třídě je to o něčem jiném...

Je to jednoduché - spigot má detailní popis instalace (jen se spustí instalační jar, sám si natáhne a zkompiluje vše potřebné, otestováno ve win i linuxu). Vyleze z toho jar, ten se spustí (opět jen java -jar spigot.jar), java si rozbalí strukturu a už server běží. Pak se do jeho adresáře plugins nakopíruje jar raspberryjuice stažený z netu

Rozšířená pythonní knihovna mcpi se stáhne z toho githubu RJuice a vloží do pythonního adresáře. Návodů na tyhle pythoní prográmky je na webu celá řada, fakt žádná věda, i já to dal na první dobrou :-)

Jen to chce v MC klientovi vypnout opuštění hry při ztrátě fokusu, aby se šlo přepnout do IDE a pořád vidět, co se v MC děje. Triviální změna jednoho parametru v konfigu http://gaming.stackexchange.com/questions/15664/can-i-alt-tab-out-of-minecraft-without-the-game-auto-pausing

Všechny komponenty jsou zcela multiplatformní. Server máme na linuxu (doma ani žádné win nemám), kluci jedou na obojím. Ve win je to pro mě opruz, protože je pořádně neznám a chybí mi v ních základní nástroje. Ale to už je jiná diskuse...

MC docela žere CPU (a samožejmě grafiku), na starém čtyřjádru ale jede kombinace spigot/MC jednoho z kluků úplně v pohodě. Samozřejmě když si naprogramují kostku TNT se stranou 1000, tak spigot dle povelu umisťující kostičky TNT do skonání věku vypínám a přemazávám jeho adresář čistou zálohou...

Díky za tipy.

Oni by rádi hráli i jiné multiplayerovky než Minecraft, ale ono toho moc není, kde by se mohli pohybovat ve virtuálním světě a ten přetvářet a budovat. Zacílit takovou multiplyerovku na vzdělávací obsah, tak by to byl šlágr.