Vlákno názorů k článku Programovací jazyk Ada pro úplné začátečníky od Kolemjdoucí - Když už škola usoudí, že C++ je na...

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.