Python je neoblíbenějším programovacím jazykem pro výuku programování (diskuse)

[sigma]

Zajímavé. Co si vůbec místní jazykobijci myslí o MATLABu jako jazyku? Když odhlédneme od toho, že to je komerční věc, tak mi to přijde jako inženýrsky výborně použitelný jazyk/prostředí nejen pro hrubé výpočty, ale obecně pro prototyping hlavně v oblasti zpracování a vizualizace dat. Skvělá je hlavně interaktivní práce - to je trochu možné i v pythonu, ale přijde mi to podstatně slabší, možná kvůli absenci kvalitního IDE/GUI - a pak debugger a profiler.

Ale když si vezmu některé (nejen) místní diskuse o návrhové čistotě, kultuře a designu "standardních" jazyků, tak MALTLAB by v tom všem snad totálně propadnul.

[deda.jabko]

inženýrsky výborně použitelný jazyk/prostředí nejen pro hrubé výpočty, ale obecně pro prototyping hlavně v oblasti zpracování a vizualizace dat

Na tohle je to dobre, ale na vyuku programovani opravdu nic moc, stejne jako Java nebo C++. Vetsina lidi bude zapasit s jazykem (casto jen se syntaxi) a k samotne podstate programovani se dostane jen okrajove.

[FrostyX]

+1, proto se mi nelíbí výuka prvních kroků programování v C. Lidi mají ze začátku problém vůbec nějakým způsobem analyzovat zadání a ujasnit si, co vlastně chtějí udělat a jak to chtějí udělat. Místo aby se soustředili na tohle, což je imho důležitější, snaží se z hlavy vylovit nějakou konkrétní syntaxi něčeho. V tomhle je python skvělý. Přitom si ani nemyslím, že by oproti C učil nějakým špatným návykům (teda až na odsazování mezerama, ale to je na nekonečný flame).

[tom]

+1, proto se mi nelíbí výuka prvních kroků programování v C. Lidi mají ze začátku problém vůbec nějakým způsobem analyzovat zadání a ujasnit si, co vlastně chtějí udělat a jak to chtějí udělat. Místo aby se soustředili na tohle, což je imho důležitější, snaží se z hlavy vylovit nějakou konkrétní syntaxi něčeho. V tomhle je python skvělý. Přitom si ani nemyslím, že by oproti C učil nějakým špatným návykům (teda až na odsazování mezerama, ale to je na nekonečný flame).

Na IT vysoke skole je vyuka v C na miste. C je potreba v kurzech o operacnich systemech a hardware, takze je dobre ho studenty naucit co nejdrive.

[Michal Kubeček]

Tady se ovšem nabízí otázka, jestli by se v IT oboru na VŠ mělo počítat s tím, že studenti přijdou do prvního ročníku programováním zcela nepolíbeni.

[kavol]

to se nevylučuje s tím, že by měli mít jako předmět Cčko - kdo už ho umí dobře, může na zápočet místo docházky dostat nějakej zajímavej projekt, a ke zkoušce si přijde pro jedničku "zadarmo"; to by se jinak mohly zrušit vlastně všechny předměty s tím, že "někdo už to umí odjinud" ...

[j]

Jenze na VS by se mely ucit pokrocily techniky a ne "zaciname s C/..." jenze to by 90% gymplaku bylo na technikach vprdeli, protoze to nevideli ani z rychliku.

[Bystroushaak]

+1

[kavol]

Jenze na VS by se mely ucit pokrocily techniky a ne "zaciname s C/..."

proč, to se jako nějak vylučuje?

považuju za samozřejmost, že mně škola věc, kterou učí, naučí od základu, pokud vstup na ní není omezen nějakou prerekvizitou, která zaručuje, že ten základ již umím

jenze to by 90% gymplaku bylo na technikach vprdeli, protoze to nevideli ani z rychliku.

a negympláci? - to by bylo 99%, že?

já jsem sice proti devalvaci vzdělání, ale na druhou stranu, opravdu je nutné někoho vylučovat z řádného vzdělávacího procesu jen protože si coby děcko špatně vybral (nebo dokonce byl rodiči natlačen) střední školu?

[Bystroushaak]

a negympláci? - to by bylo 99%, že?

Ne imho tak 20%. Z mé zkušenosti z VŠ, obor Informační technologie plyne to samé - gympláci se plácají v programování, protože ho vidí poprvé v životě, nemají kontext a v podstatě je ani moc nezajímá. Celá VŠ je tomu přizpůsobena a studium bakaláře se dá v podstatě shrnout do "pět úvodů do programování a nějaký ten shit kolem". Naproti tomu třeba matematika se rovnou bere na gympl úrovni a lidi ze střední se moc nechytají.

Tzn. pokud jde někdo na VŠ a očekává, že se tam naučí programovat a po škole může rovnou nastoupit do práce jako programátor/analytik, nebo tak něco, tak s vysokou pravděpodobností tvrdě narazí, protože málokterý předmět půjde dál než za naučení syntaxe. V Liberci byl vrchol ve třeťáku Softwarové inženýrství, kde se v rychlosti proberou vývojové techniky (katedrála, vodopád atp) a šmytec. Nějaké algoritmy, to možná lehce v rámci teorie grafů a her, taky jen takové škrtnutí v rámci jednoho semestru a ani se to nijak nehrotí.

V podstatě se nelze divit firmám, že se pak zdráhají přijmout uchazeče co právě dostudoval, protože se právem dá říct, že nic neumí. Má pár úvodů do něčeho, ale pokud se silně neangažoval sám o sobě, tak je na dost podobné úrovni, jako lidé co právě vylezli z technické střední.

Netvrdím, že je to problém všude, ale u lidí, kteří očekávají že VŠ jim nějak pomůže v IT to problém dost často je, co tak mám vlastní zkušenost a možnost pozorovat známé, kteří šli stejnou cestou. Určitě byly na VŠ i velmi zajímavé předměty, otázkou však je, jestli to za ty 3 roky života stálo a kde by člověk byl, kdyby si rovnou začal nějak zařizovat život, který do té doby prakticky neměl.

proč, to se jako nějak vylučuje?

V podstatě ano, protože se to prostě nedá stihnout, když všechny pořád uvádíš do něčeho.

[Miloslav Ponkrác]

„Tzn. pokud jde někdo na VŠ a očekává, že se tam naučí programovat a po škole může rovnou nastoupit do práce jako programátor/analytik, nebo tak něco, tak s vysokou pravděpodobností tvrdě narazí, protože málokterý předmět půjde dál než za naučení syntaxe.“

Já jsem to očekával a nenarazil ani trochu, ba právě naopak.

Ale pravdou je, že jsem vystudoval vysokou školu před 20 lety, to znamená ještě poctivou vysokou školu. Ne dnešní flákárnu. (Mohu srovnávat, protože jsem vystudoval ještě druhou, kterou jsem dokončil loni. A dnes jsou požadavky na studenty tak setinové.)

[Bystroushaak]

Ale pravdou je, že jsem vystudoval vysokou školu před 20 lety, to znamená ještě poctivou vysokou školu. Ne dnešní flákárnu. (Mohu srovnávat, protože jsem vystudoval ještě druhou, kterou jsem dokončil loni. A dnes jsou požadavky na studenty tak setinové.)

Tak ono zase nejsou všechny vysoké školy stejné a pokud někdo vystuduje třeba matfyz, tak to má pořád nemalou úroveň. Minimálně Liberec a Ostrava na tom ale jsou tak, jak jsem popisoval, to mám reportované od vícero lidí.

[Miloslav Ponkrác]

Já jsem ale nevystudoval programování, ale kybernetiku. A přesto jsem dostal tak dobré základy matematiky i programování jako vedlejší předměty, že to dnešní školy nedají ani jako hlavní obor. Hned po škole už jsem programoval naplno, a úspěšně.

Ale co jsem chtěl říci, to módní nadávání na školy je chyba studentů. Jestliže chtějí něco umět, nechť si vyberou KVALITNÍ školu. Je zbytečné vinit z toho školy. Jak psal už Werich, zlobí se na zrcadlo ten, kdo má křivou hubu.

Vidím v celé této diskusi, že lidé nevědí co chtějí. Hlavně si neuvědomují, že když se chtějí něco naučit a umět, musejí pro to něco obětovat, a to je NÁMAHA.

Jestliže někdo dává rovnítko mezi programování a znalost programovacího jazyka, pak je vedle jak ta jedle.

Tu lenost tady vidím v celé diskusi. Někdo jde studovat lehkou školu, a pak se diví, že nic neumí. Ale samozřejmě, je to chyba školy, student za to nemůže.

Někdo se nechce učit programovat na dobrém učebním jazyce, hned chce být hotový programátor a používat to, co virtuózní machr. A diví se, že to nejde. Protože dostat se na vrchol umění programovat chce zase tu NÁMAHU.

Všichni tu preferují lenost, a diví se, že to nejde. Že neumějí. A pak z toho dělají závěry, že tu škola, tu ten jazyk je nenaučil programovat. Ale ve skutečnosti se nenaučil programovat ten člověk, protože je to líné tele, které chce vše dostat až pod nos, a nechce nic investovat za námahu. Ale jednodušší je obviňovat školství, nebo jazyk, než sebe a svůj špatný přístup.

Ten, kdo umí programovat, se hravě naučí další programovací jazyk za odpoledne. Protože je to jen syntaxe a to co už zná trochu jinak.

Tedy být programátorem není věc ani školy, ani konkrétního programovacího jazyka – je to věc přístupu člověka.

[Bystroushaak]

Ale co jsem chtěl říci, to módní nadávání na školy je chyba studentů. Jestliže chtějí něco umět, nechť si vyberou KVALITNÍ školu. Je zbytečné vinit z toho školy. Jak psal už Werich, zlobí se na zrcadlo ten, kdo má křivou hubu.

Jak poznáš jako student kvalitu? Osobně jsem v té době ani netušil, co za kvalitu hledat, natožpak abych dokázal zjistit, jestli jí daná škola splňuje. Věděl jsem prostě že chci vědět víc a šel jsem to vědění hledat tam, kde podle všeho mělo být.

Vidím v celé této diskusi, že lidé nevědí co chtějí. Hlavně si neuvědomují, že když se chtějí něco naučit a umět, musejí pro to něco obětovat, a to je NÁMAHA.

Tak zase nebudu tvrdit, že bych se tam nic nenaučil - naopak, setkal jsem se tam se spoustou zajímavých věcí, názorů, technologií i lidí. Ale co do programátorské praxe to bylo v podstatě bezcenné, to jsem se musel všechno naučit sám. Dodneška mě děsí myšlenka, že třeba někdo z lidí kterým jsem tam pomáhal s programováním jdou dělat někam programátora, nebo nedej bože vedoucího a na tuhle pozici se dostanou jen kvůli titulu.

[Miloslav Ponkrác]

„Jak poznáš jako student kvalitu? Osobně jsem v té době ani netušil, co za kvalitu hledat, natožpak abych dokázal zjistit, jestli jí daná škola splňuje. Věděl jsem prostě že chci vědět víc a šel jsem to vědění hledat tam, kde podle všeho mělo být.“

Pokud o to stojíš, způsoby najdeš.

---

„Ale co do programátorské praxe to bylo v podstatě bezcenné, to jsem se musel všechno naučit sám.“

To záleží, co si představuješ tou „programátorskou praxí“.

---

„Dodneška mě děsí myšlenka, že třeba někdo z lidí kterým jsem tam pomáhal s programováním jdou dělat někam programátora, nebo nedej bože vedoucího a na tuhle pozici se dostanou jen kvůli titulu.“

Za celý můj život se nikdo z lidí, pro které jsem pracoval nekoukal na můj titul.

Nicméně lidi bych nepodceňoval. To, že je někdo v nějakém čase hloupý a neznalý, neznamená, že v pozdějším čase to není machr nejvyššího stupně.

[rADOn]

Pokud o to stojíš, způsoby najdeš

To je větička kterou se v českým školství omlouvá kdejaký šlendrián. Dotaženo do důsledku, pokud si někdo umí najít ty slavný způsoby, tak se na nějaký školy může vykašlat.

[Jan R.]

Nepravda - existuju najmenej rebricky a osobne referencie. Ked sa niekto rozhodne pre skolu, lebo pri nej studenti stihaju chodit kazdy den na zabavy, do prace a bez problemov ju dokoncia, tak asi nehlada kvalitu. Ked niekomu staci titul, tak typicky tiez nehlada kvalitu.
Ked niekto studuje na predsunutej budove detasovaneho pracoviska vysokej skoly v Hornej-Dolnej, tak asi tiez nehlada kvalitu.
Podobne to je, ked sa na skole zaoberaju len nepotrebnymi predmetmi, ktore napadnu aj tak kazdeho. Kamaratka sa mi kedysi stazovala, ze predmet s nazvom tusim Architektura pocitacov na ich skole je narocny, lebo musia sami rozobrat PC a v druhom semestri dokonca diagnostikovat chybu vymenou komponent...
Kto chce, ten si lepsiu skolu najde. Len treba hladat a pytat sa.

[frr]

Trochu si přisadím. Programování mě nakonec neživí, je potřeba dělat jiné věci... ale jeden čas jsem i v práci pár menších věcí napsal.

Když si vzpomenu na školu a pozdější "čistokrevnou" praxi, tak se mi vybavuje jeden důležitý dojem: na programování něčeho většího a smysluplnějšího není ve škole ani čas, ani přiměřeně motivující zadání. Třeba "krásu nahého těla" OOP moje vepřová hlava ve škole (včetně VŠ) nějak nebrala. A v jednosemestrálních začátečnických kursech se prostě k ničemu výživnějšímu nedalo dospět. Když máte na semestrální úkol řádově několik málo dní čistého času (možná spíš pár hodin), tak z toho prostě nic zásadního vyvstat nemůže. A když si vzpomenu na shůry daná témata diplomek - ve zpětném pohledu z toho cítím beznaděj, že v akademické sféře "prostě není o čem".

Když mě pak (vzápětí po opuštění školy) pod tíhou práce v síťařině napadlo cosi trochu velkolepého, co mně a kolegům mohlo dost zjednodušit dřinu, navíc jsem se z vlastní vůle začal trochu vrtat v Cčku na Linuxovém podvozku, tak během 1-2 měsíců reálného času pár věcí zaklaplo dohromady. Myslím co do OOP, rozvláknění, základní programátorské hygieny a tak. Jenom rozsah těch programovacích prací byl takový, že by to ve škole naprosto nešlo realizovat. Oproti běžné Mgr. diplomce třeba několikanásobný - a přitom to byly dost jednoúčelové "server-side" hračky, které by asi ani ve škole nebyly prezentovatelné jako něco extra užitečného. S jedním projektem "do šuplíku" jsem si hrál ve volném čase snad tři roky. V práci jsem cosi psal třeba tři měsíce čistého času. (A to byly ještě relativní "štěky".) Přinést takovou věc do školy? 1) to by řádově přesahovalo rozsah práce, kterou stojí běžná diplomka a 2) to by se jim hodilo... aby mě pak mohli předhazovat normálním študákům, jako že "dívejte kolik práce zvládl kvůli diplomce tuten". To zrovna.

[Ondrej 'SanTiago' Zajicek]

Jak psal už Werich, zlobí se na zrcadlo ten, kdo má křivou hubu.

Werich to mozna psal taky, ale ten citat je puvodem z Revizora od Nikolaje Gogola.

[pan Klobouk]

Když už tak autorem bonmotku je Nikolaj Vasiljevič Gogol. Což je u cintátů panwericha věc vcelku obvyklá.

[wjn]

> Ten, kdo umí programovat, se hravě naučí další programovací jazyk za odpoledne. Protože je to jen syntaxe a to co už zná trochu jinak.

To ukazuje na nedostatecny rozhled.

Jazyk se sklada z nekolika veci: 1) syntaxe 2) semantiky 3) zakladnich knihoven a 4) idiomu. Ano, pokud prejdes z Javy na C#, dlouho ti to trvat nebude, pac se lisi hlavne syntaxi a knihovnami.

Jit z Javy na distribuovany system v Erlangu, nebo datove paralelni system v Haskellu, to je neco jineho, a rozhodne to neni za odpoledne. Zmenit paradigma nejde snadno.

[jehovista]

bla bla*

*realizovat se muzes zde a zde

[Bystroushaak]

Viděl jsem a četl snad do stránky 20.

[jehovista]

No a to ti nestacilo? :)

[Bystroushaak]

Tam jsem se ale nezúčastnil :)

[kavol]

a negympláci? - to by bylo 99%, že?

Ne imho tak 20%. Z mé zkušenosti z VŠ ...

můžeš to nějak rozvést?

já mám docela čerstvou zkušenost ze SŠ, a ... no, nechci být nějak neuctivý (ti lidi jsou machři zas na jiný věci), ale řekl bych, že učitel, co tam jedinej byl schopen přemýšlet nad nějakou algoritmizací, byl tak na úrovni mejch spolužáků z gymplu (myslim ten šedej průměr, co chodil na programování), tedy co asi tak mohl naučit ty žáky ...

proč, to se jako nějak vylučuje?

V podstatě ano, protože se to prostě nedá stihnout, když všechny pořád uvádíš do něčeho.

no, i tady se naše zkušenosti zásadně rozchází ...

[Bystroushaak]

já mám docela čerstvou zkušenost ze SŠ, a ... no, nechci být nějak neuctivý (ti lidi jsou machři zas na jiný věci), ale řekl bych, že učitel, co tam jedinej byl schopen přemýšlet nad nějakou algoritmizací, byl tak na úrovni mejch spolužáků z gymplu (myslim ten šedej průměr, co chodil na programování), tedy co asi tak mohl naučit ty žáky ...

To je sice možná pravda, ale na rozdíl od gymplu na vysokou potom nejde celý ročník, ale jen jeden nebo dva lidi, které to opravdu baví a kterým to často doporučí přímo učitelé. Pokud se tam náhodou vydá víc lidí, tak tam jdou jen aby si prodloužili prázdniny a mohli semestr/dva prochlastat za peníze rodičů, než je vyhodí a na přednáškách/cvičeních je moc neuvidíš.

Tohle jsou prostě moje zkušenosti, nevím jak moc se dá na jejich základě generalizovat, ale odpovídá to tomu, co slyším od ostatních.

[kavol]

hm, máš pocit, že z gymplu jde celý ročník na jednu vysokou? nebo je to spíše tak, že na tu konkrétní (kde se programuje) jdou jenom lidi, které to baví nebo kterým to někdo doporučí?

a pokud počítáš s tím, že to někoho baví natolik, že se to naučí mimo školu, pak nechápu, proč to s tou školou spojuješ (tedy takovým způsobem, jakým to děláš, jinak samozřejmě nehledal bych fandu do počítačů primárně třeba na zdravce, že ...)

já jsem reagoval z toho hlediska, jak která škola umí žáky připravit, a co se programování týče, vskutku nemám pocit, že by technické SŠ byly nějak na výši

[Bystroushaak]

hm, máš pocit, že z gymplu jde celý ročník na jednu vysokou? nebo je to spíše tak, že na tu konkrétní (kde se programuje) jdou jenom lidi, které to baví nebo kterým to někdo doporučí?

To je imho docela jedno. Více méně všichni z gymplu jdou na nějakou. Buď to a nebo prodávat párky.

a pokud počítáš s tím, že to někoho baví natolik, že se to naučí mimo školu, pak nechápu, proč to s tou školou spojuješ

Subjektivní zkušenosti.

já jsem reagoval z toho hlediska, jak která škola umí žáky připravit, a co se programování týče, vskutku nemám pocit, že by technické SŠ byly nějak na výši

Tak s tím souhlasím, ale nemám pocit, že by to na gymplech obecně bylo lepší.

[tom]

a negympláci? - to by bylo 99%, že?

Ne imho tak 20%. Z mé zkušenosti z VŠ, obor Informační technologie plyne to samé - gympláci se plácají v programování, protože ho vidí poprvé v životě, nemají kontext a v podstatě je ani moc nezajímá.

Na IT skolu nas slo z meho gymplu 5 a uvodni programovaci kurz byl pro nas o nicem. Ja jsem se naucil v C sam z knizek a ze cteni OSS kodu mezi 14. - 16. rokem a podobne na tom byli dalsi 2 a z toho jeden umel cist x86 kod primo v hexaeditoru. Zbyvajici 2 umeli programovat v pascalu.

[Bystroushaak]

Já netvrdím, že to nemůže být jinak, ani že neexistují vyjímky.

BTW: Z lidí, kteří začali vypadávat na programování, jaká byla statistika tam?

[kralyk z abclinuxu]

Jenze na VS by se mely ucit pokrocily techniky a ne "zaciname s C/..." jenze to by 90% gymplaku bylo na technikach vprdeli, protoze to nevideli ani z rychliku.

No... To nemusí platit... U nás na gymplu jsme měli Pascal někdy v prváku nebo max. v druháku, brali jsme takový věci jako spojový seznamy, sortovacá algoritmy, procházení koně šachovnicí a podobný kravinky. Bohužel o rok později to trochu zabili s Javou v BlueJ, což je tak stupidní prostředí, že by jeden plakal. (Možná, že právě vinou tohohle prostředí nemam rád Javu ). To byl asi nejslabší bod. Nicméně čtvrťák to trochu zpravil, tam jsme se zabývali aproximací řešení funkce (jednoduchá numerická analýza) a vykreslením, vzpomínám si že závěrečný úkol jsem napsal v Qt se zadáním funkce v JS, ale většina spolužáků, které to tak nebralo, sáhla po tom Pascalu nebo Javě. Samozřejmě to nebylo žádné velké programování, všechno jednoduché školní úlohy, ale myslimže snad nikdo z těch co sme to absolvovali by v případě zájmu o IT VŠ ztracen nebyl.

Jednalo se o gymnazijní program "s rožšířenou výukou matematiky, fyziky a ivt" (myslimže to byl odificální název) a vůbec to nebylo špatný. Bohužel, za dva roky tenhle program zrušili. Nevím proč, asi prostě jeden z failů školství. Takže je možné, že dnes už bys s těma 90% možná i měl pravdu...

[JS1]

To zni jako dobry gympl, ciste ze zvedavosti, jaky to byl?

[kralyk z abclinuxu]

GJKT HK.

[pavlix]

No... To nemusí platit...

Nemyslím si, že by těch (alespoň) 90% neplatilo, ale je pravda, že sám nejsem nadšený z čistě statistických argumentů, ať už jsou statistické hodnoty reálné nebo vycucané z prstu.

[Michal Kubeček]

To si nerozumíme, nechtěl jsem tím říct, že by se céčko nemělo učit, naopak. Myslel jsem to obráceně: sice souhlasím s tím, že C není jazyk vhodný k tomu, aby se na něm člověk začínal učit programovat, ale protože by IMHO na informatický obor neměl přijít někdo, kdo o programování neví vůbec nic, nebrání to tomu, aby se tam s C začínalo poměrně brzy.

[kavol]

aha, ok, pochopil jsem to jako rozporování předchozího příspěvku, nikoli doplnění

[JS1]

Tady se ovšem nabízí otázka, jestli by se v IT oboru na VŠ mělo počítat s tím, že studenti přijdou do prvního ročníku programováním zcela nepolíbeni.

No, mozna se neco za 15 let zmenilo, a deti se dnes uci programovani na stredni bezne. (Ja osobne povazuji programovani za dalsi gramotnost, a myslim, ze kazdy by se to mel naucit uz na zakladni skole.) Ale v roce 1996, kdyz jsem sel na VS (FJFI), mel jsem v rocniku spoluzaka, ktery nedokazal ani zapnout PC (nicmene matematiku znal asi nejlepe z rocniku, takze nebyl blbec).

Podle me predpokladat znalost programovani, aniz by bylo aspon z 90% soucasti vyuky na strednich skolach, je ponekud diskriminacni.

Ale jinak ja bych v prvaku ucil ten Python prave proto, ze si myslim, ze pokud uz si nekdo ma vystacit s jednim jazykem, Python je asi nejpraktictejsi volba. Takze kdyz ti lide po prvaku odejdou z VS, zbyde jim aspon tohle.

[pavlix]

ktery nedokazal ani zapnout PC

Tak ale to už je znalost hardware ;).

[pavlix]

Ale jinak ja bych v prvaku ucil ten Python prave proto, ze si myslim, ze pokud uz si nekdo ma vystacit s jednim jazykem, Python je asi nejpraktictejsi volba. Takze kdyz ti lide po prvaku odejdou z VS, zbyde jim aspon tohle.

To je velmi dobrý argument. Těch lidí, co se nepřenesou přes první ročník je hromada a děje se to z různých důvodů včetně finančních, kde by Python mohl být rychlejší pomocí než některé jiné jazyky. Na druhou stranu se mi nelíbí, že je Python relativně komplexní ve srovnání s jazyky jako je C a Pascal.

[JS1]

Komplexni? Jako ze ma komplexni cisla?

Jestli se tim mysli pomerne bohata standardni knihovna, to beru spis jako plus. (Nevim, ktery jiny jazyk mel odvahu dat si relacni databazi do standardni knihovny, a to mi prijde hodne uzitecne. Jeste ten numpy aby se tam dostal, no snad nekdy.)

[pavlix]

Komplexni? Jako ze ma komplexni cisla?

Předpokládám, že slovo komplexní znáš. Kdybych napsal složité, tak mi zas bude nadávat, že v céčku je práce složitější.

Jestli se tim mysli pomerne bohata standardni knihovna

Mám namysli věci, které se týkají samotného jazyka.

[JS1]

Ne, delal jsem si legraci, protoze jsem chtel dostat konkretni odpoved, co konkretne je slozite? Jsme o dva prispevky dal a porad na stejnem miste.

[pavlix]

Jednak se neumíš zeptat, a jednak ti tu nebudu vypisovat referenci obou jazyků a dělat kvantitativní srovnání, to už si holt budeš muset udělat sám, pokud tě to zajímá.

[JS1]

jednak ti tu nebudu vypisovat referenci obou jazyků a dělat kvantitativní srovnání

O to nestojim. Jen jsem si myslel, ze by tvoje zkusenost mohla byt zajimava, kdyz uz to ucis.

[Josef Kufner]

Otázkou je, zda tu komplexitu musí uživatel programátor zvládnout na začátku, nebo až když k ní dozraje.

[pavlix]

Učím lidi s Pythonem už delší dobou a pořád na to nemám úplně jasný názor. Ale můžu říct, že programy psané lidmi, kteří ji alespoň částečně neobsáhli, se mi moc nelíbí.

[Josef Kufner]

To jo, ale jsou schopni ten program napsat a ulehčit si tak práci nebo splnit jinak prakticky nerealizovatelný úkol. Že ten program bude neudržovatelná kopa hnoje je už podružné a u malých jednoúčelových nástrojů, které se dají za dva dny kompletně přepsat, je to úplně jedno. Blbé je, když se pak pustí do něčeho většího …

[pavlix]

A pak odejdou a někdo ty nástroje po nich musí převzít.

[Michal Kubeček]

To mi zní jako klasický projev víry ve školu. Prostě přístup, že když přečtu předepsané knihy, složím předepsané zkoušky a dostanu příslušný papír (ať už maturitní vysvědčení nebo vysokoškolský diplom), přičemž za celou dobu se nepodívám nalevo napravo a nebudu se zajímat o nic nad rámec školní výuky, tak umím všechno, co je potřeba.

IMHO je to nesmysl. Stejně jako se člověk nestane dobrým řidičem v okamžiku, kdy absolvuje autoškolu, nestane se dobrým programátorem ve chvíli, kdy vystuduje odpovídající obor na VŠ. Naše základní a střední školství (a bohužel někdy i vysoké) bohužel podporuje právě tu uniformitu a nepodporuje ve studentech snahu samostatně se vzdělávat nad rámec výuky. To je podle mne chyba a v tak rychle se vyvíjejícím oboru jako IT, chyba přímo osudná.

Můj oblíbený aforismus říká, že vzdělání je to, co člověku zůstane, když zapomene všechno, co se naučil ve škole. To je samozřejmě jen vtip, ale jeho podstata je IMHO moc důležitá: přínos dobré školy není jen v těch znalostech, které si student odnese, ale hlavně v tom, že ho naučí pracovat s informacemi a samostatně se vzdělávat.

Proto nejsem přesvědčen, že je správné koncipovat výuku na VŠ tak, aby s ní v žádném případě nemohl mít problémy student kterékoli střední školy, který ji řádně absolvoval a naučil se všechno, co se po něm chtělo, ale ani o chloupek víc.

[JS1]

V tom se neshodneme. I kdyz s tim aforismem souhlasim. Proste VS nema predpokladat, ze lide znaji neco navic oproti tomu, co se bezne uci na SS, to je podle me spatne. Mozna dobry kompromis by bylo to, co myslim delal matfyz - mel v prvaku specialni predmet, kde se dohanely nektere veci ze strednich skol. Podobne i na FJFI byl na zacatky fyziky "rychlokurz" matematicke analyzy, protoze pro fyziku to proste bylo potreba driv, nez se k tomu dobereme v matematice. Ale odmitam, aby si nad tim vysoka skola myla ruce s tim, ze ten, koho to zajima, by to mel uz vedet.

A mimochodem, to mi vadilo i na te autoskole. Byl jsem pri zkousce srovnavan s lidmi, kteri se naucili ridit ve 14ti, samozrejme nelegalne. To mi pripada podobne nefer. Stejne tak, deti by mely mit pravo ve svem volnem case delat jine veci nez co se pak rozhodnou studovat na VS.

[Michal Kubeček]

Proste VS nema predpokladat, ze lide znaji neco navic oproti tomu, co se bezne uci na SS, to je podle me spatne.

Podle mne je špatně naopak ten přístup "naučte se, co vám vyložíme, nic víc potřebovat nebudete" Podle mne by škola měla naopak vést studenty k tomu, aby se snažili učit a hledat nové věci sami. Ne "…will be sufficient to get you through your examinations, which, after all, is what school is all about".

Stejne tak, deti by mely mit pravo ve svem volnem case delat jine veci nez co se pak rozhodnou studovat na VS.

To právo jim rozhodně upírat nechci. Co jim chci upírat, je právo na to, aby ti, kdo na rozdíl od nich tu snahu vyvinou, z toho nemohli mít žádnou výhodu. Mimochodem, používání termínu "děti" pro středoškolské studenty mi připadá krajně zavádějící.

[JS1]

Co jim chci upírat, je právo na to, aby ti, kdo na rozdíl od nich tu snahu vyvinou, z toho nemohli mít žádnou výhodu.

Me prijde, ze tu vyhodu nemaji uz implicitne. Vzdycky budou mit vyhodu ti, kteri to bokem studovali proti tem, co to bokem nestudovali. A pokud by se to vyresilo zpusobem, ktery jsem naznacil - VS by na to mela nejaky dalsi kurz, ktery lze preskocit - pak je ta nevyhoda dokonce explicitni.

[pochybnik]

Spis bych to videl tak, ze skvele zvladnuti stredni skoly by samo o sobe melo cloveka vybavit vsemi znalostmi nutnymi pro to, aby se mohl zacit ucit na vysoke skole.

Kazdy kurz ma sve vstupni predpoklady, na kterych stavi a dale je rozviji a pridava k nim. Dobry kurz pri splneni vsupnich predpokladu da studujicimu vse potrebne k zavrseni kurzu (at formou znalosti, ci odkazem, kde si je doplnit) a postupuje od znameho kj neznamemu.

[Josef Kufner]

Na vysoké škole můžeš začít v podstatě hned po základce a přípravném kurzu matematiky. Co jsem si všimnul, snad žádný předmět prvního ročníku na FELu neměl nějaké podstatné prerekvizity.

[j]

Ono to je (bylo) jeste lepsi ... za me na felu bylo co si pamatuju 5 matik. A defakto bylo uplne jedno v jakym poradi je clovek absolvoval, protoze spolu naprosto dokonale nesouvisely. Velmi podobny to bylo i s ostatnima predmetama ... kde slo defakto jen o to, zapsat si dostatek kreditu ... a jestlo to spolu souvisi nebo ne ...

[j]

Nikoli ...

Podivej, skolstvi funguje tak, ze muzes absolovat cojavim ... skolu senkrubniho potapece ... a kdyz nakonec dostanes maturitu ... muzes jit na matfyz. Mel by na to brat matfyz ohled? Ja tvrdim ze nikoli.

Stejne tak pokud lezes na IT vejsku, tak by se by default melo predpokladat, ze mas zakladni znalosti z IT, a zcela me nezajima, jestli si ty znalosti ziskal ve skole nebo kdekoli jinde. A samo, tady je rec o programovani, ale minim tim i odpovidajici znalosti o HW a dalsich IT nalezitostech.

[j]

Proc? Proboha ber to tak, ze ucit by ses mel predevsim sam. Skola by ti mela jen rozsirit obzory a v tom uceni pomoct. Pokud lezes na IT VS, tak proste zcela automaticky predpokladam, ze se v IT ve svych +- 19-20ti velmi dobre orientujes, ze zvladas zakladni veci, ze umis napsat kus nejakyho kodu, mas predstavu ze existujou nejaky algoritmy ... a ja ti na ty VS mozna vysvetlim, proc je v dany situaci dobry pouzit to a ne ono, a jak si to muzes spocitat/dovodit/... ale rozhdone bych ti na VS nemel vysvetlovat, jak funguje for/while ... na coz spousta lidi cumi jak tele na novy vrata.

Ostatne ja osobne sem se takovy veci jako bublesort a qicksort ucil uz na 8mibitech ... na zakladce. A sami sme s kamosema vymesleli jak zrychlit ruzny algoritmy ... mozna prave proto, ze tenkrat na tech 8mibitech to bylo kurevsky znat. Na stredni sme pak jen tak pro zabavu vyrabeli ruzny 3D animace ... ktery sme postupne prepisovali do asm ... a bylo to zatracene hodne poznat.

[Miloslav Ponkrác]

„Pokud lezes na IT VS, tak proste zcela automaticky predpokladam, ze se v IT ve svych +- 19-20ti velmi dobre orientujes, ze zvladas zakladni veci, ze umis napsat kus nejakyho kodu, mas predstavu ze existujou nejaky algoritmy“

A to proč?

[j]

Protoze lezes na VS inteligente ... a VS neni od toho aby ses tam ucil cist a psat, coz je presne totez.

[Miloslav Ponkrác]

Rozumím, takže argumenty nemáte, střelil jste jen tak do větru a já se blbě zeptal, proč. Potřebujete prostě nemyslící kývače, jinak se rozčílíte, protože svůj názor zdůvodnit nedokážete. Už to chápu, netřeba dále vysvětlovat, je to jasné.

[j]

Obecni blb jirsak leze na VS a neumi se pritom podepsat ... mno aby to pak podle toho presne nevypadalo v tech vysledcich ... je to naprosto jasny ...

[vencour]

Proč? Aby člověk mohl něco rozvíjet a nebyl jen přenejlepším průměrem? Tedy aby člověk šel na to, na co má největší šanci dodělat a zvládnout, zpravidla na to, co ho nejvíc baví ...

[JS1]

A k cemu takova VS bude? Vzdyt muzeme proste predpokladat, ze v 25 znaji cele kurikulum, co se uci na VS, a jenom jim rozdat diplom.. Smyslem VS je lidi ten obor naucit, ne je protridit. Ale ja to chapu, jsem v Cechach, memuzu holt cekat, ze co chvili nenarazim na nejake elitarske pitomce.

[Bystroushaak]

Myslím že chtěl naznačit to co jsem popisoval výše, tedy že když jdeš na VŠ s cílem stát se dobrým programátorem, tak je to zbytečné, protože v tomhle ohledu ti škola nic nedá. Prostě v Čechách nenajdeš školu, která by generoval již funkční programátory, pokud pod tím slovem hledáš něco víc, než je jen znalost syntaxe a odevzdání 10 úkolů.

Imho to není o elitářství, ale o tom, že praxe je pak o něčem úplně jiném a to tě žádná VŠ ani zdaleka nenaučí, ani tě na to nepřipraví (i když by mohla). Zaměstnavatel do tebe pak musí nalejt půl roku času jen aby si tě dovzdělal a to může i do člověka ze střední, u kterého má aspoň trochu jistotu, že se motal kolem techniky. Škola je pak pro ně irelevantní, spíš je zajímají projekty na kterých jsi již dělal.

[JS1]

Jestli si cetl tu diskusi na Root.cz, muj nazor znas: Nevidim duvod, proc by mel stat platit z dani vzdelavani, ktere si muze platit zamestnavatel. Pokud ma nekdo pocit, ze se mu VS nevyplati, at na ni nechodi.

Proste, to co to tam stale obhajuje Prymek, jsou vlhke sny ekonomickych socialnich inzenyru, kteri by chteli, aby spolecnost fungovala "optimalne". Ale takova spolecnost neni svobodna, takze diky, nechci.

[Bystroushaak]

Pokud ma nekdo pocit, ze se mu VS nevyplati, at na ni nechodi.

Já znám osobně minimálně 3 lidi (na víc si v současnosti konkrétně nevzpomenu), kteří na konci druháku či ve třeťáku odešli, protože jim to konečně došlo a dál už jim škola neměla kromě titulu co nabídnout. Všichni jsou velmi technicky schopní, a někteří z nich se dají vidět i tady. Kdo naopak vždy zůstal jsou lidi, kterým šlo jen o titul a fungovali stylem "nauč se, udělej zkoušku, zapomeň". Hlášky jako "nasdílej prosím ten úkol, mě programování nezajímá a stejně to dělám jen kvůli titulu" jsem měl tu možnost slyšet dokonce osobně.

Nevím, nepřijde mi to, že je to tak, jak by to mělo fungovat, ale co já vím.

[j]

Protoze ten clovek bude platit dane, a tudiz zaplati to vzdelani. Kdyz z nej stat udela nepouzitelnyho idiota, tak ho jeste bude muset zivit na pracaku. Ale jo, proc ne, pokladni v marketu s cevenym diplomem taky dobry ...

Vlhky sny jsou, ze bude neco platit zamestnavatel. Ten nic platit nebude, protoze ho radove levnejs vyjde si najmout nekoho, kdo to umi. A kdyz na to prijde, zaplati si inda, kterej to udela za hrst rejze.

[Jendа]

Jestli si cetl tu diskusi na Root.cz

Sorry, skončil jsem poměrně brzo a nemá to fulltext.

Nevidim duvod, proc by mel stat platit z dani vzdelavani, ktere si muze platit zamestnavatel.

Počkej, a co si zaměstnavatel platit nemůže, tedy co se může na VŠ učit?

[JS1]

V mem pohledu ma VS slouzit k rozvoji vseobecne vzdelanosti, ma ucit predevsim veci, na ktere je casovy horizont zamestnavatele (coz pokud mas stesti je tak nejvys 5 let, existuje par vyjimek, ktere se neridi striktne trhem) prilis kratky.

A take jsem tam psal o "moskevske skole", coz je v podstate idea, ze inzenyr (ten kdo navrhuje technicka reseni) by mel mit stejne zaklady jako vedec (ten kdo zkouma prirodu), protoze ve finale neni hloupejsi. Tudiz by clovek, ktery chce navrhovat IT systemy, mel mit pravo znat computer science stejne dobre jako nekdo, kdo chce CS primo delat jako karieru. Prestoze bude delat neco jineho. (Muzeme to zkratka obratit a misto "budu tohle potrebovat?" se ptat "nemel bych mit pravo znat svuj obor do hloubky?".)

Jinak samozrejme, nabizi se otazka, kdyz absolventy pokryji VS, co ti ostatni? Pokud by cilem statnich VS (muzeme se tak dohodnout, jako spolecnost) melo byt zajistit vzdelavani zamestnancu, pak by bylo ucit jen mlade lidi ponekud diskriminacni. Realita v IT IMHO je, ze technologie se dost meni a jak pise "j", ano, clovek se to musi ucit sam (i kdyz taky neni pravda, ze by to zamestnavatele vubec nebyli ochotni platit, a s tou Indii je to take dost mimo). Jenze to neplati jen pro ty, co jdou na VS.

Ja predpokladam, ze to Bystroushaakovi casem dojde, az prozije tu zmenu. Treba prave v dobe, kdy jsem ja studoval VS (1996-), byl skutecne Pascal jeden z nejuzitecnejsich jazyku. Java trochu zacinala..

[j]

Zamestnavatel do tebe investuje cas (a tudiz penize) az v okamziku, kdy si spocita, ze se mu to vyplati. Rozhodne ti nebude platit "zaciname s programovanim", protoze mu za dverma ceka 150 dalsich, kteri tohle zvladli uz nekde na ty zakladce.

Navic je pro zamestnavatele zcela nezajimavej absolvent VS ... kterej toho umi min, nez stredoskolak s 5ti lety praxe. Pritom financni pozadavky obou budou nejspis srovnatelny.

A to sou indii neni prehnany ani trochu, mel sem tu cest s nekolika dodavateli - trebas oracle, kde defakto vse bylo reseno tak, ze tady se semnou bavi jen obchodak, ale cokoli chci nakonfigurovat, posle jako req indovi a ind to za dolar na hodinu udela. Samo, vysledek tomu casto odpovida, ale cena je takova, ze jim to nechaj klidne 3x predelat, a porad se to vyplati.

[JS1]

Moc nerozumim premise, kterou obhajujes. Pokud ma nejaky zamestnavatel pocit, ze se mu vysokoskolaci nehodi, at je nenabira! Jeho boj. Tim spis je pak otazka, proc by se VS mela prizpusobovat jeho pozadavkum.

Co se te Indie tyka, mozna mluvis o nejakych vesnicanech. Ja jsem byl v Hyderabadu, vypada to tam na nase pomery desive, nicmene zivotni naklady jsou vuci nam jen asi polovicni.

[kavol]

Navic je pro zamestnavatele zcela nezajimavej absolvent VS ... kterej toho umi min, nez stredoskolak s 5ti lety praxe. Pritom financni pozadavky obou budou nejspis srovnatelny.

no, požadavky ... řekl bych, že ten absolvent VŠ se typicky bude cejtit tak na desetkrát víc

[Miloslav Ponkrác]

Ale houby.

To, že je někdo lempl, a nedokáže využít možností, které mu škola dává, není problém školy, ale přístupu člověka.

Já přeložím Vaše věty: „Prostě v Čechách nenajdeš školu, která by generoval již funkční programátory, pokud pod tím slovem hledáš něco víc, než je jen znalost syntaxe a odevzdání 10 úkolů."

Znamená to: „Že si Bystousak nechce přiznat, že chyba je v něm. Tak je lépe to okecat a zachovat si vlastní sebeúctu a ego tím, že to svede na někoho jiného.“

---

Stejně tak to urban legend o nepoužitelnosti dobrých studentů (zdůrazňuji dobrých studentů, ne lemplů, co na to kašlou a pak obviní školu) a o investicích zaměstnavatele o délce osmdesáti dob ledových – nijak v okolí nevidím.

A to znám mnoho lidí, se kterými jsem školu dokončil, stejně jako řadu dalších. Je to přesně naopak. Lidi byli perfektně schopní okamžitě v praxi začít, včetně mě, a často se stávali oporou a hlavní silou firmy.

A nebo dnešní mládež je totální lemplovatá, a je to o jejím přístupu. A není nic snadnějšího, než říct: „Já nic já muzikant, bé bé bé, fňuk, fňuk, fňuk, to oni za to můžou! To oni mě nic nenaučili, když já jsem se na to vykašlinkal.“

[Bystroushaak]

Znamená to: „Že si Bystousak nechce přiznat, že chyba je v něm. Tak je lépe to okecat a zachovat si vlastní sebeúctu a ego tím, že to svede na někoho jiného.“

Já jsem nad tím přemýšlel, ale není to tak, protože já měl problémy jen s matematikou a ta chyba byla zcela jistě ve mě. Studium mě jinak docela dost bavilo.

Ten zbytek co jsem tu prezentoval jsou vesměs nářky, které poslouchám od známých z IRC a z mé pracovní zkušenosti, se kterou jsem díky vlastní iniciativě a opensource na githubu také problém neměl.

[j]

Hmm ... zazil sem nekolik kolegu a kolegyn (u tech to bylo obzvlast zjevne), kteri zcela bez potizi prochazeli s jednickama a dvojkama ... proste proto, ze se na zkousku nasprtali scripta zpameti a byli hodnoceni jako vynikajici studenti. Zadny z nich dneska samozrejme v oboru nedela, protoze o nem nemaji ani nejmensi paru. Jenze presne takto funguji vsechny nase VS.

Zato spousta lidi kteri tem vecem opravdu rozumeli, ale nebyli ochotni se sprtat zpameti ... jednoduse odeslo nebo bylo odejito ... castro trebas proto, ze v one zcela zasadni a v realnem zivote naprosto nepostradatelne definici neudelali "spravne" carku ...

Jinak by se to dalo popsat i tak, ze ten kdo VS absolvoval nic jineho nez nepouzitelny lempl byt nemuze.

[egg]

Jenze presne takto funguji vsechny nase VS.

To asi ne, pane.

[Michal Kubeček]

To, že člověk (jen) s tím, co ho naučili ve škole, pro praxi nevystačí, ani zdaleka neznamená, že mu ta škola nebyla k ničemu.

[Bystroushaak]

To ale ani netvrdím.

[j]

Jenze clovek ktery ze skoly vyleze by mel byt pouzitelny v praxi. To neznamena, ze si sedne ke klavesnici a bude obratem kodit stejne, jako jeho kolega co kodi 10let ... bohuzel, realita je takova, ze vystup skolstvi je v takovem stadiu nepouzitelnosti, ze opravdu muze jit tak leda ke kase v marketu.

[Jendа]

a deti se dnes uci programovani na stredni bezne

Ne.

Ja osobne povazuji programovani za dalsi gramotnost, a myslim, ze kazdy by se to mel naucit uz na zakladni skole.

Já bych spíš než programování učil skriptování, protože když vidím, jak uživatelé ručně zpracovávají sto stejných souborů/řádků/whatever pomocí sta opakování téhož klikání, když bych to dal jedním one-linerem v bashi… Ale to by vyžadovalo nějaký větší úvod do operačních systémů.

Ale v roce 1996, kdyz jsem sel na VS (FJFI), mel jsem v rocniku spoluzaka, ktery nedokazal ani zapnout PC

1996? Jako naswitchovat do feritové paměti loader, nastavit na jeho začátek IP a nahrát monitor z pásky? Ne, vážně, ale tak tehdy prostě mohl mít smůlu a k počítači se nedostal, nebyly ještě na každém rohu, že jo. (teda myslím, byly mi 3)

[JS1]

Já bych spíš než programování učil skriptování, protože když vidím, jak uživatelé ručně zpracovávají sto stejných souborů/řádků/whatever pomocí sta opakování téhož klikání, když bych to dal jedním one-linerem v bashi… Ale to by vyžadovalo nějaký větší úvod do operačních systémů.

To s tebou souhlasim. Bohuzel zatim nikdo neprisel na to, jak to uzivatelum prilis zpristupnit. Shell byl takovy zpusob nekdy v 70. letech, a pochybuji, ze ucit lepe OS je ta spravna cesta. Spis se proste lepe prodava MS Word nez Emacs.

Ono elitarstvi programatoru je castecne problem (a muze myslim za ty snahy o "falesnou" uzivatelskou privetivost, ktera prave automatizaci zcela opomiji). Ja bych rad, aby vice lidi nahlizelo na programovani prave jako na to vareni - je to neco, co muze usnadnit praci, i kdyz ten program/skript pak nebude mit zadnou architekturu.

Ted existuje jista nadeje v hudebni produkci, to by mohlo programovani priblizit vic "masam", ale uvidime.

[egg]

Ted existuje jista nadeje v hudebni produkci, to by mohlo programovani priblizit vic "masam", ale uvidime.

O co jde?

[JS1]

Toho jsem se bal, ze se nekdo zepta. Moc o tom nevim, viz treba tady.

[egg]

Ten zvuk, co se ozývá v tom youtube videu, je hudební produkce? Jsem asi z jiné planety.

[Bystroushaak]

I když běžně s některými pro běžné lidi neposlouchatelnými skladbami problém nemám, tak na tohole jsem asi taky moc malý autista.

[Jindřich Makovička]

Připomíná mi to experimentální elektroniku z padesátých let, a.k.a. Musique Concrete, která se rovněž nedala poslouchat.

[JS1]

No ja jen, ze je to zajimava subkultura. Jestli to skutecne bude mit budoucnost je tezke rict.

[JZD]

Hm, pěkná divočina. To mi připomenulo tuhle starší zprávičku http://www.abclinuxu.cz/zpravicky/neco-k-poslechu-pomoci-gcc-a-aplay kde je v komentářích spousta námětu.

[deda.jabko]

Ja bych rad, aby vice lidi nahlizelo na programovani prave jako na to vareni

Tesim se na zaplavu televiznich poradu o programovani:

1) Zdenek Pohlraich: Kurva, chlapi, v tom kodu mate ale bordel, [pip], [pip].

2) Jirka Babica: Dneska si ukazeme, jak udelat quicksort. Budeme k tomu potrebovat jedno pole hodnot. Kdo nevi, jak se dela pole, pouzije spojovy seznam.

3) Jarda Hruska: Dnes si v televiznich novinach ukazeme, jak v JavaScriptu rychle a levne otestovat prvociselnost. Kazdy vi, ze prvocisla jsou licha cisla. Staci nam tedy overit, ze cislo je delitelne dvema. Nefunguje to vzdy uplne spravne, ale hlavni je, ze je to rychle a levne naprogramovane.

4) Prostreno: Dnes si pozveme bandu psychopatu, aby neco naprogramovali a pak si ten kod pomluvili. Vysledna hadka bude priblizne stejne zabavna jako tato diskuze.

[Jindřich Makovička]

+1000

[JS1]

Hezke. I kdyz ja jsem si spis predstavoval neco jako Premka Podlahu.

Tesim se na zaplavu televiznich poradu o programovani

Mne je to jedno, ja televizi nemam. A je mi jasne, ze si z toho lide delaji legraci, protoze jim to dnes pripada absurdni, stejne jako stredovekym mnichum pripadalo nejspis absurdni, ze skoro kazdy umi cist a psat. Ale vazne si myslim, ze by to mohlo pomoct. Treba prave informace o tom, jak zpracovat velke mnozstvi fotek soucasne.

[deda.jabko]

protoze jim to dnes pripada absurdni, stejne jako stredovekym mnichum pripadalo nejspis absurdni, ze skoro kazdy umi cist a psat

Mne to absurdni zase tak neprijde. Znam nekolik lidi z vekove kategorie 50+, kteri se diky RaspberryPI pustili do programovani, mimochodem, i kvuli pouzitemu Pythonu, ktery je pro ne docela pristupny.

Aby lidi zacali programovat, musi pro to mit nejakou motivaci. Premek podlaha svuj uspech postavil na tom, ze za minuleho rezimu nebylo nic dostani a kde chtel neco extra, tak si to musel SAM ubastlit. V pripade programovani je velka vyhoda v tom, ze staci jeden clovek, co uz podobny problem resil a dal sve reseni sdilet na net. Rada beznych problemu je takto pokryta, tudiz jeste vic klesa motivace ucit se programovat...

Z pohledu pristupnosti pro neprogramatory mne paradoxne prisly asi nejlepsi Windows s jejich podporou OLE Automation (nebo jak se to jmenovalo), ktere de facto umoznovaly skriptovat aplikace z libovolneho jazyka a vytvaret zajimave celky. Ale nejak se to nechytlo...

[kralyk z abclinuxu]

+1

^{(Hergot, už musim ty fortunky opravdu aktualizovat...)}

[kralyk z abclinuxu]

^{(Fortuny aktualizovány (27 nových) )}

[pavlix]

Kazdy vi, ze prvocisla jsou licha cisla.

Vážně? Já to teda nevím.

[pavlix]

Nebo to je součástí vtipu?

[Jindřich Makovička]

Tak samozřejmě až na dvojku, ale pro Jardu Hrušku dobrý.

[Blaazen]

Je to Láďa Hruška, ne Jarda, ale to nevadí, pobavil jsi mě velice. Ještě jsi měl být genderově korektní a přidat nějakou programátorku, třeba Jiřku Bohdalovou, s prioritou růžového fontu v editoru.

[AsciiWolf]

[j]

3) Mno a protoze pocitace umej jen nulu a jednicku ... tak muzeme smele prohlasit, ze kazde cislo v pocitaci je prvocislo. ;D

[JS1]

Ne, vážně, ale tak tehdy prostě mohl mít smůlu a k počítači se nedostal, nebyly ještě na každém rohu, že jo.

No ne zcela, byl v tomhle asi jediny z rocniku. Rekl bych, ze nejaky pocitac melo tak mozna 30-40% domacnosti. Na druhou stranu, usetril spousta volneho casu, ktery mohl venovat cteni Jarnika, takze se v prvnim rocniku ponekud nudil..

[kralyk z abclinuxu]

Já bych spíš než programování učil skriptování, protože když vidím, jak uživatelé ručně zpracovávají sto stejných souborů/řádků/whatever pomocí sta opakování téhož klikání, když bych to dal jedním one-linerem v bashi… Ale to by vyžadovalo nějaký větší úvod do operačních systémů.

+1. Trochu bych to zobecnil - ono nejde ani tak konkrétně o bash nebo linux, ale spíš o určitý přístup k řešení problémů - obecnost, znovupoužitelnost, rozšiřitelnost apod. (asi v podstatě unixová filosofie).

Bohužel, řada lidí to řeší tak, že si stáhnou FooBarVendor® AwesomeFileRenamer™ (který je shareware a obsahuje toolbar do prohlížeče od Ask.com) a mají pocit, že jsou guru :-/

[j]

Script je program jako kazdej ... decka by se mela ucit jak postavit nejaky vetveni, par typu podminek, smycky ... a samo idealne na necem, co pro ne v dany okamzik ma smysl - coz nejspis bude nejaky script na prejmenovani fotek ... a podobny ptakoviny. Ve finale trebas ani nejde o to, aby kazdej umel programovat, ale spis o to, aby mel predstavu jak se podobny veci resej, a dosel za nekym s tim, jestli mu to za 10 minut napise, misto toho, aby travil 50hodin rucnim resenim.

Mimochodem, v roce 1995 sme na stredni meli 4 plne vybaveny PC ucebny, dokupy mozna neco kolem 150x PC, HW to melo nekde od 386 po pentium. A tu feritovou pamet (1kB na desce tak 400x400) sem si tak o 3 roky driv odnekud dones domu jako artefakt hodny uchovani.

[little.owl]

Je to mimoradne prasoidni ulipany jazyk jehoz podstatnou vyhodou je silna uzivatelska baze, rozumne IDE a dostupne toolboxy.

Uziti Matlabu nad ramec prototyping/verifikace napadu/akademickeho research je obecne cesta do (_!_). S lidmi kteri ulipou algoritmus v high level funkcich Matlabu a mysli si, ze tim jejich prace zkoncila, se potykam v soucasnosti temer denne. Casto je u nas situace takova, ze jejich algoritmus bezici v Matlabu na PC (extrem byl cluster sedmi PC) musi byt v okamziku portace na cilovou platformu produkcniho systemu predelan tak, ze nej vubec nic nezbude a stoji nas to neskutecne penize. Lidi, schopnych udelat prototyping v Matlabu a pak to dotahnout do podoby pouzitelneho C/C++ kodu, je zatracene malo. Pred par mesici jsem protlacil, ze od urcite urovne vyvoje se *musi* prejit na C/C++, klidne i s uzitim knihoven jako OpenCV, VTK a dalsich. Plno kvikotu, nekolik lidi i kvuli tomu odeslo (my jsme vyzkumnici, ne nejaci za***ni programatori), ale situace se celkove o dosti zlepsila.

Pokud by Matlab mel byt nastroj na vyuku programovani, riskuje se vyprodukovani nepouzitelnych retardovanych programatorskych mrzaku, ktere je lepsi do teamu vubec nepoustet. Postupem doby chapu proc univerzity v USA/UK pouzivali extremne dlouho na vyuku programovani LISP; Python v tomto ohledu neni az tak spatna volba.

[K>]

ja se teda tem co nechteji prejit na C/C++ nedivim. Pokud clovek vystuduje fyziku/matematiku, tak je Matlab mnohem pristupnejsi nez jine jazyky. Uz jenom napoveda v Matlabu je psana obvykle nekym kdo te matematice rozumi. A v tamnim helpu obsazeny kratky uvod do Matlabu je vynikajici. Taky me nebavi resit nejake ukazatele a jestli jsem nekde dealokoval pamet a nepretekl cosi nebo tamto.

[little.owl]

Problem je v tom, ze jejich prace je pro nas pak casto proste nepouzitelna.

Matlab help neni lepsi nez treba u numpy, je to casto presne naopak - u numpy jsme navic schopni i dohledat, jak je to implementovano - u Matlabu jsme v haji. Help casto opomiji veci jako numericke aspekty, od stability pro precisions a je to do znacne miry blackbox - coz je krasne videt, kdyz lide co portuji algoritmy do C/C++ se potrebuji od matlabich smoulu dozvedet co to *presne* dela.

Pokud clovek vystuduje fyziku/matematiku, tak je Matlab mnohem pristupnejsi nez jine jazyky.

Nez python ci haskell? Pokud ano, jsou uz brain damaged a je lepsi se jich vyvarovat.

[Josef Kufner]

Je velký rozdíl mezi matematikou a programováním, i když to druhé je z části podmnožinou prvního. Tyto dvě odvětví formují odlišný způsob myšlení a matematici se na stejné problémy dívají z jiného pohledu než programátoři.

Co jsem většinou potkal, tak matematici nebyli moc dobří programátoři a naopak programátoři měli potíže s matematikou. Z toho mi je celkem jasné, že každý potřebuje svůj jazyk a pokud chceš implementovat řešení matematického problému, potřebuješ alespoň dva lidi.

[little.owl]

Tak prunik nad oblasti aplikovane matematiky, u lidi ktere zamestnavame, je z obou stran pomerne velky. Obe skupiny musi najit spolecnou rec, a tou je bud velmi dobra dobra formalni dokumentace - treba na bazi SysML/UML ci nejaka referencni, byt klidne i priserne napsana, naivni C implementace. Kupka matlabiho hnoje tim stycnym bodem rozhodne neni a extenzivni uziti Matlabu mimo pocatecni fazi vede casto k takovemu odtrzeni od reality, ze nakonec zahazujeme mesice prace.

[Miloslav Ponkrác]

„Co jsem většinou potkal, tak matematici nebyli moc dobří programátoři a naopak programátoři měli potíže s matematikou.“

Znovu, co je to „programátor“?

Pokud jde o to programovat kernel nebo databáze, tam matematickům scházejí zkušenosti.

Ale pokud jde o programování praktických věcí mimo tyto oblasti, tam zase matematici si vedou dobře a programátoři velmi špatně.

---

„Z toho mi je celkem jasné, že každý potřebuje svůj jazyk a pokud chceš implementovat řešení matematického problému, potřebuješ alespoň dva lidi.“

Nebo jednoho, co umí matematiku i programování.

[marvn]

Nebo jednoho, co umí matematiku i programování.

problem s timhle ale je, ze Henryk Lahola je na svete jen jeden...

[Miloslav Ponkrác]

Takový lidí je mnoho. Sám jich znám hodně.

Jen si obvykle vybírají zajímavé projektu a koncentrují se na místech, kde se jim líbí. Třeba simulace, lékařství, rozpoznávání hlasu, atd.

[Agent]

Znovu, co je to hodně?

[Miloslav Ponkrác]

Minimálně o 5 řádů více, než jeden Henryk Lahola.

Pokud vystrčíte čumák z linuxové komunity, stejně tak jako z komunity databázové a systémové, pak zjistíte, že je zde další ohromný, neuvěřitelně rozlehlý sw svět.

Nebo se podívejte do katalogů elektroniky. Těch mikrokontrolerů, co se vyrábí! A digitální procesorů! A mnoho dalšího. A kolem nich je spousta lidí a pracovníků a zaměstnanců …

Nebo výpočety na superpočítačích stále nezvládá programovat jeden Henryk Lahola.

To, že si lidé kolem desktopu a běžných programátorů kolem sebe dělají ulitu a přehlížejí obrovské další trhy, kde se musí programovat, a často jsou potřeba i velké znalosti zdaleka nejenom programátorské.

Dále už to nechám na Vašem bádání.

[K>]

Cti co pisu, ne to co si myslis ze pisu. Netvrdim ze Matlab je nejlepsi. Ale proc teda chces, aby "od urcite urovne vyvoje se *musi* prejit na C/C++", kdyz pak obhajujes NumPy?

[Jindřich Makovička]

NumPy je v zásadě převlečený Lapack/Blas, což činí portování do C/C++ jakžtakž snesitelným.

[little.owl]

+1

[little.owl]

Cti co pisu, ne to co si myslis ze pisu.

To plati i pro vas. Muj druhy odstavec se tyka vaseho tvzeni o dokumentovanosti Matlabu, kde cela rada algoritmu ma specifikovany jen interface, ale co je uvnitr nevite.

[kavol]

Co si vůbec místní jazykobijci myslí o MATLABu jako jazyku?

no, nejsem jazykobijec, dokonce jsem se kdysi zařeknul, že programovat už nikdy nebudu, nicméně když jsem zprávičku četl, tak jsem nad umístěním matlabu silně zarazil - jestli jde o ten matlab, ve kterém jsem byl kdysi nucen spáchat nějaké úložky, tak bych řekl, že je k výuce programování vhodný asi jako Quarantine k výuce pravidel silničního provozu ...

[JS1]

No, ja jsem pouzival nedavno Octave (studoval jsem trochu strojove uceni). A dalo se to, az na ty stredniky, to jsem nepochopil. Ale fakt se to hodi asi jen na to pocitani/prototyping, a az bude mit Python operator nasobeni matic, i to asi prestane byt zajimave (z hlediska jazyka, co jsem slysel, hlavni sila MATLABu je v tech toolboxech).

Domnivam se, ze Python eventualne MATLAB uplne vytlaci. Vedecke a statisticke vypocty jsou zda se domena, kde posledni dobou hodne roste oproti ruzne konkurenci (MATLAB, R, Julia, C++..).

[little.owl]

az bude mit Python operator nasobeni matic, i to asi prestane byt zajimave

numpy

hlavni sila MATLABu je v tech toolboxech

Ano.

[JS1]

Numpy znam, mel jsem na mysli toto.

[little.owl]

To je super a je to asi schvaleno do 3.5!

[Jendа]

No já nevím… To budeme mít i operátor na inverzi a transpozici matice, na počítání částečných součtů a rozdílů pole a já nevím co všechno? A to v jazyce, který neumí i++? Sorry, asi nejsem moc dobrý filozof na programovací jazyky.

[JS1]

Asi ne. Ale ja to chapu jako jisty ustupek pro pouzivani Pythonu v matematickych domenach - je prekvapive, jak malo rozruchu ta zmena vzbudila.

Specialni operator na inverzi a transpozici tolik nepotrebujes, protoze ten neni binarni. Jde hlavne o to, ze lidem vyhovuje infixovy zapis, i kdyz je to nelogicke.

[egg]

Skvělá je hlavně interaktivní práce - to je trochu možné i v pythonu, ale přijde mi to podstatně slabší, ...

IPython Notebook znáte?

[Bystroushaak]

Ale když si vezmu některé (nejen) místní diskuse o návrhové čistotě, kultuře a designu "standardních" jazyků, tak MALTLAB by v tom všem snad totálně propadnul.

To bude tím, že nemá návrhovou čistotu ani kulturu :D

Ne, vážně - proprietární jazyk pro výpočty a simulace uzamčený na jedno (z hlediska programování tragicky špatné) vývojové prostředí s velmi dobrou podporou interaktivní práce (grafický repl s debuggerem). K tomu hnusná, ukecaná syntaxe kombinující funkcionální a procedurální kód. Imho kdyby se to neučilo na vysokých školách, tak po tom imho ani pes neštěkne.

[K>]

Problem je, ze kdyz chci vynasobit 2 blbe matice, tak v Matlabu to je napsane hned. V cem jinem to jde tak rychle? V cecku pretypovat operatory? V pythonu dotahat NumPy? To vsechno jsou zbytecne slozitosti navic pro ty co nejsou programatori.

[Bystroushaak]

To není problém, to je feature. Pokud si napíšu jazyk se speciálním operátorem pro posílání emailů, tak v něm taky pošlu email rychleji než v pythonu, to z něj však nedělá lepší jazyk.

Násobení matic je vysoce specifická věc a pokud ti nevadí zahodit možnost zahodit obecné schopnosti jazyka/platformy jen proto, že to někde jde rychleji, tak proč ne. Chudáci ovšem ti, kdo se to budou snažit rozšířit, portovat a udržovat i za 10 let.

[K>]

Nojo, ale to je tvuj pohled. Armady fyziku a matematiku resi jak rychle vynasobit matici, a ne jak dobrou to ma implementaci lambda funkci. Takze z jejich (a meho) pohledu ten jazyk proste je lepsi nez jine.

[Miloslav Ponkrác]

S principem souhlasím. Matice je velmi používaná věc. Nicméně on ten MATLAB zase tak dobře ani rychle vždy matice nenásobí.

Ve své podstatě třeba ve Fortranu/C++ vždy vynásobíte rychleji. Protože pro malé matice nemáte overhead MATLABu, a protože pro konkrétní účel si uložení prvků matice napíšete lépe. A protože si můžete pro prvky matice použít datový typ, který přesně potřebujete.

[Bystroushaak]

Nemyslím si, že by řešil rychlost ve smyslu implementace (protože díky numpy na tom python není špatně), ale ve smyslu syntaxe. Prostě že v pythonu je to delší a méně pohodlné, než v matlabu.

[Miloslav Ponkrác]

Souhlasím s tím, že v matlabu je to příjemnější.

[Jendа]

Když píšu nějakou matematiku, tak prostě na začátku automaticky udělám import numpy as np a pak prostě kdekoli np.dot(a, b) (+ asi milion dalších funkcí co numpy má).

[Josef Kufner]

Někde uprostřed toho odkazovaného textu je příklad. S infixovým operátorem je takový zápis asi poloviční a výrazně čitelnější. A zrovna u takovýchto komplikovanějších výpočtů je ta čitelnost sakra důležitá, neboť toto je oblast, kde debugger je na prd.

[g.g]

"ale obecně pro prototyping hlavně v oblasti zpracování a vizualizace dat."

Ehm...Roassal2?

[dementni.lojzik]

Co si vůbec místní jazykobijci myslí o MATLABu jako jazyku?

a co o wolfram language?

[Bystroushaak]

Wolfram language se nezdá tak moc zajímavá, jako ten cloud kolem toho a možnost interakce se všemi možnými embeded zařízeními. Taky ty streamy ověřených dat ve strukturovaném formátu působí velmi zajímavě.

[kralyk z abclinuxu]

a co o wolfram language?

Onehdá jsem na to koukal, přijde mi, že se jedná o další "God project" (analogie s God object). Čas od času se objeví nějaký takový projekt, typicky se vyznačuje tím, že se snaží vyřešit a umět úplně všechno, nebo alespoň úplně všechno v nějaké oblasti. Nedávno se objevila zprávičkao Xiki - to je další takový případ, ale existují další. Proč lidé tohle dělají?

[JS1]

Asi se jim libi idea boha.. Me se ale Xiki libi, trochu mi to pripomina pristup k UI v ACME z Plan 9 (nezkousel jsem osobne). Je IMHO dobre, ze to nekdo zkousi.

S Mathematicou jsem si hral kdysi davno, ale nakonec jsem dal prave prednost OSS.

[Michal Kubeček]

Jestli je to něco podobného, jako měla Mathematica (naposledy jsem ji viděl ve verzi 3 a 4), tak určitě ne. Těžko uvěřitelný mix všech možných stylů (snad jen Prolog se jim do toho namíchat nepodařilo) s místy poněkud záludnou syntaxí. Pro učení se programování bych to rozhodně nikomu nedoporučil.

[Bystroushaak]

Ty videa vzbudily dost rozruch před pár měsíci, viz třeba; https://www.youtube.com/watch?v=_P9HqHVPeik. Osobně se mi to taky dost líbilo, ale zatím jsem s tím nic nedělal.

[kouzer]

Kdybych si měl zpětně vybrat svůj první programovací jazyk, tak bych asi volil Ruby. Bohužel za nás se ale začínalo na Pascalu nebo Basicu...

[Bruce]

Mne pride Ruby ohladom zapisu desne neprehladne (asi ako Perl) a tazko citatelne. Python ma naproti tomu pekny cisty zapis, ovela vacsiu komunitu a nasadenie. Takze za mna rozhodne Python.

[kouzer]

Mě zase přišel Python špatně čitelný. Každému holt vyhovuje něco jiného...

[JS1]

V cem konkretne?

[kouzer]

Myslím, že není potřeba to rozebírat. Jak jsem psal... Každému vyhovuje něco jiného.

[Miloslav Ponkrác]

I mně přijde Python nečitelný.

[egg]

I mně přijde Python nečitelný.

A ani vy nebudete konkrétní?

[w4rr10r]

Je to ve hvězdách...

[Miloslav Ponkrác]

Python vnucuje určitou úpravu zdrojáku. Pokud vím, tak Brainfuck a Python jsou jediné dva jazyky, kde záleží na počtu mezer ve zdrojáku.

Python mě nutí pokud možno dát jeden příkaz na jeden řádek.

Prostě každý jazyk, který si vynucuje určitý code style, je z definice méně přehledný. V jazycích s volnou úpravou kódu můžete udělat prasečtější i přehlednější jazyk, můžete ho udělat velmi čitelný a udržovatelný.

K tomu si přidejte to, že v Pythonu jsou knihovny každý pes, jiná ves a rozhodně nedrží nějaké stejné základní principy. Co se posbíralo někde ve zbytcích kódu, z toho jsou Python knihovny.

Z hlediska přehlednosti a udržovatelnosti navíc trochu vadí, že proměnné jsou dynamické a nenapovídají ve zdrojáku na různých místech alespoň typ.

[JS1]

Docela rad bych videl konkretni priklad, kde code style Pythonu dela veci mene citelne. Dokazu si to predstavit u toho Lispu, ale u Pythonu.. nevim.

K tomu si přidejte to, že v Pythonu jsou knihovny každý pes, jiná ves a rozhodně nedrží nějaké stejné základní principy.

Jake zakladni principy by mely dodrzovat? Jedine, co si dokazu predstavit je pozadavek na vetsi objektovost. Coz muze a nemusi byt vyhoda.

Z hlediska přehlednosti a udržovatelnosti navíc trochu vadí, že proměnné jsou dynamické a nenapovídají ve zdrojáku na různých místech alespoň typ.

A tohle pise nekdo, kdo ma rad Lisp? Vazne?

[Miloslav Ponkrác]

Tohle je přesně důvod, proč se lidi nechtějí v diskusích vyjadřovat konkrétně. Protože z toho jsou pak vlákna o milionech příspěvků a wasting of time. Mně je fuk, co si o Pythonu myslí druzí, důležité je, co si o něm myslím sám a co si z toho vyvodím pro praxi. Druhé přesvědčovat nehodlám, a je mi fuk, co si zase o Pythonu myslí oni.

Je zcela jednoduché, jak OBJEKTIVNĚ zjistit udržovatelnost a přehlednost. Napište projekt o milionu řádek zdrojového kódu v několika jazycích. A pak v nich několik let opravujte chyby, dodělávejte nové věci, atd. Zapisujte si čas, od otevření zdrojáku po konečnou úpravu a pak porovnejte celkové časy po několika letech. Zcela objektivně zjistíte.

Python není nepřehledný, ale IMHO nic moc.

Nevidím příliš šťastné řešení extenzivně a prakticky povinně používat bílé znaky jako součást syntaxe. Mezery, konce řádků, atd. To k přehlednosti nikdy nepřidá. (Bavíme se o velkých projektech, ne o hello world.)

Řada jazyků maximálně používala bílé znaky jako součást syntaxe, později od toho začaly ustopat, protože to prostě není ono. Ustoupil od toho Fortran, Basic, a další.

IBM kdysi dělala rozsáhlá měření, jak optimálně psát programy. Včetně blbin jako jak dlouhý identifikátor způsobuje nejrychlejší orinetaci v programu při údržbě a další. Někde si to najděte, je to docela zajímavé čtení.

Co se týká OOP, jeho pojetí objektů se mi líbí. Dokonce jsem miloval i ten jeho self parametr v metodách. A co Python 3 odhodil staré typy tříd, tak je to lepší z tohoto pohledu.

Ale přehlednost rozhodně není vlastností, ve které by Python exceloval. Jednoduchost syntaxe je vynikající, to ano. Ale přehledný je pouze průměrně.

I v tom C/C++ se dá napsat přehlednější a udržovatelnější program, pokud někdo drží dobrou štábní kulturu.

[JS1]

Tak puvodne me zajimalo, v cem by se dala citelnost Pythonu jeste zlepsit, za predpokladu zachovani zakladnich kriterii, podle jakych byl navrzen. Kouzer psal, ze se mu libi Ruby, proto.

Python se snazi odstranit prebytecny text a znaceni, aby se zapis zkratil, ale ne za cenu "zasifrovani" zdrojaku. Take je to dynamicky typovany jazyk. Tohle jsou explicitni navrhova omezeni, a podle me, pokud je opustime, nelze hodnotit "vseobecnou citelnost". V tehle kriteriich to nikdy nebude objektivni, je to jako kdyby sochar nadaval na hlinu, ze z ni nepostavi 20 metrovou sochu. Ano, samozrejme, protoze ucel toho materialu je v necem jinem. Stejne tak ucel Pythonu je ve snadne praci nad problemem, ktery chci resit.

A moc neverim tomu, ze IBM delala studii o tom, jak spravne navrhnout programovaci jazyk a nejlepe z toho, cirou nahodou, vyslo C++.

[deda.jabko]

Pokud vím, tak Brainfuck a Python jsou jediné dva jazyky

Nevite, protoze v Brainfucku mezera neni. Bile znaky maji vyznam napriklad v Haskellu nebo v make. Pak jsem videl nejaky wtf-vyznam i v JavaScriptu, ale to asi nebyl zamer.

[Miloslav Ponkrác]

Myslel jsem jazyk Whitespace. Klidně se přiznám, že v těchto jazycích jsem ještě neměl tu čest.

Jinak díky za doplnění s dalšími jazyky.

[egg]

Prostě každý jazyk, který si vynucuje určitý code style, je z definice méně přehledný.

Můj názor je přesně opačný.

K tomu si přidejte to, že v Pythonu jsou knihovny každý pes, jiná ves a rozhodně nedrží nějaké stejné základní principy. Co se posbíralo někde ve zbytcích kódu, z toho jsou Python knihovny.

To jsou nekonkrétní řeči, které nic neznamenají.

Z hlediska přehlednosti a udržovatelnosti navíc trochu vadí, že proměnné jsou dynamické a nenapovídají ve zdrojáku na různých místech alespoň typ.

Tohle nijak nesouvisí s čitelností, to je jen o tom, že vy jste zvyklý na jiné programovací paradigma.

[Bruce]

Sem tam niekto pise o tych medzerach ako o neprekonatelnom probleme, ale je to take robenie z komara velblouda. V Pythone programujem cez 4 roky, ale nikdy som nemal pocit, ze by ma Python do niecoho nutil. Tie medzery su tam uplne prirodzene, ako by to snad kazdy pisal aj bez nich. Za cele tie roky by som IndentationError vynimky, ktore som porobil, spocital mozno aj na jednej ruke.

Python mě nutí pokud možno dát jeden příkaz na jeden řádek.

Nenuti, na jeden riadok je mozne zapisat aj viacero prikazov, ale takyto zapis povazujem za prasenie (zneprehladnuje debugging).

Prostě každý jazyk, který si vynucuje určitý code style, je z definice méně přehledný. V jazycích s volnou úpravou kódu můžete udělat prasečtější i přehlednější jazyk, můžete ho udělat velmi čitelný a udržovatelný.

Nesuhlasim. Python definuje urcity coding style, ale je to len doporucenie, prasit sa tam da nehlade na vynutene odsadenie (ktore plni funkciu bloku kodu). Dany coding style ovsem dodrzuje vacsina Python programatorov a ked pozriete na cudzi kod, lahsie sa v nom zorientujete.

K tomu si přidejte to, že v Pythonu jsou knihovny každý pes, jiná ves a rozhodně nedrží nějaké stejné základní principy. Co se posbíralo někde ve zbytcích kódu, z toho jsou Python knihovny.

Toto si dovolim tvrdit, ze je strasny nezmysel. Rovnako ako kazdy iny popularny jazyk, aj Python ma kniznice, ktorych kvalita sa pohybuje od shitu az po top uroven. V Pythone existuje kniznica snad na uplne vsetko a subjektivne hodnotim kvalitu popularnych kniznic viac nez velmi dobru.

Z hlediska přehlednosti a udržovatelnosti navíc trochu vadí, že proměnné jsou dynamické a nenapovídají ve zdrojáku na různých místech alespoň typ.

Tak toto snad o dynamicky typovom jazyku asi ani nema zmysel komentovat.

[jas]

Python mě nutí pokud možno dát jeden příkaz na jeden řádek.

To uz v pythone zrusili bodkociarku? Neviem ako python3, ale v python2 mi 'print 1;print 2' stale funguje.

Z hlediska přehlednosti a udržovatelnosti navíc trochu vadí, že proměnné jsou dynamické a nenapovídají ve zdrojáku na různých místech alespoň typ.

To uz zrusili aj 'type'? Ked uz clovek chce, tak si na typy moze hrat aj v pythone. ('if type(a) == int:' a pod.).

[rADOn]

Python vnucuje určitou úpravu zdrojáku. Pokud vím, tak Brainfuck a Python jsou jediné dva jazyky, kde záleží na počtu mezer ve zdrojáku.

Prdlajs. Jediný na čem záleží je aby byl blok odasezenej stejně, kolik mezer tam dáš je putna. Ani není problém roztáhnout něco komplikovaného na více řádek – dokud interpret nenajde konec výrazu tak odsazení ignoruje. Dokonce se s tím počítá a interpret schválně ignoruje nadbytečný koncový čárky (tam kde je to nesporný) aby se dal snadno kopírovat kód když si takhle rozpitváš třeba nějaký tučný volání funkce.

Python mě nutí pokud možno dát jeden příkaz na jeden řádek.

Taky prdlajs. Pythonisti jsou naopak nechvalně známí tím co všechno dokážou natlačit na jeden řádek. Pokud ti pajtní kód přijde moc roztahanej, tak je to spíš tím že otrocky přepisuješ céčkový myšlení.

Prostě každý jazyk, který si vynucuje určitý code style, je z definice méně přehledný.

Tuplovaný prdlajs. Céčko si vynucuje oddělený deklarace/definice. Java si vynucuje všude tlačit objekty, každej ve vlastním souboru. Pascal si vynucuje i určitý rozvržení kódu. Jestli nejsi prase tak zjistíš že si toho python vynucuje spíš méně. Navíc je to celý nesmysl, kdyby volnější styl byl přehlednější tak by nejpřehlednější jazyk na světě byl Perl.

K tomu si přidejte to, že v Pythonu jsou knihovny každý pes, jiná ves a rozhodně nedrží nějaké stejné základní principy. Co se posbíralo někde ve zbytcích kódu, z toho jsou Python knihovny.

To je naprostá pravda… pokud všechno co tě zajímá je pohled z rychlíku. Když se podíváš blíž tak uvidíš že pajtní knihovna je taky o hodně větší než má většina jiných jazyků. Pokud nataháš do C nebo Javy externí knihovny se srovnatelnou funkčností, tak mezi nimi taky bude spousta různých stylů a bude to vypadat jako bordel. BTW taky ten bordel dobře dokumentuje to hrozný vynucování coding style, že?

Z hlediska přehlednosti a udržovatelnosti navíc trochu vadí, že proměnné jsou dynamické a nenapovídají ve zdrojáku na různých místech alespoň typ.

Nikdo ti přece nebrání si je srozumitelně pojmenovat. Nic víc ani nepotřebuješ, naopak, nějak typy vynucovat v tom jazyce nedává smysl a spíš to škodí.

Prostě z tebe mluví nezvyk. V práci máme spousty přeučených céčkařů který měli stejný obavy. Nikdo s tím neměl problém – štábní kulturu musí držet i v céčku. Pokud má někdo problém s odsazováním tak je prostě prase. V jakémkoliv jazyce.

[TM]

Python? Nechápu.
Jako jazyk třeba pro psaní testovacích sekvencí řídících jednotek, připojených k simulátoru je OK. Dá se v něm rychle a snadno v případě potřeby něco naprasit atd... hraje podle mě podobnou roli jako kdysi klasický interpretet Basicu.
Ale k výuce? Vede k pocitu, jak je vše snadné a ona to není pravda. Nejsem už dostatečně free, cool a IN a tak nechápu ten odklon od objektového(i klasického) Pascalu pro tento účel(pochopitelně jen pro tento účel, pro který byl kdysi navržený - na reálné projekty už se pak moc nehodí (což "turbopascalisté" dodnes nepochopili ).

[Ilfirin]

Tak mě učili na vajšce Pascal/Delphi a nadávál jsem jak špaček. To už bych radši i ten C# (a to ho nemám rád). Za Python bych líbal ruce. Takhle jsem prolezl s odřenýma ušima.

[rADOn]

Já věděl že je otázka času kdy nějakej pascalista vyleze z díry… Já zase nechápu proč by se člověk měl učit prgat v jazyce kde půl času stráví ne programováním, ale obcházením pradávných idiosynkrazií. Pascal nebyl navržený na výuku programování jak se říká – pascal byl navržený na indoktrinaci jednoho velmi specifického způsobu programování. A ten je dnes už dávno mrtvý.

[TM]

Pascalista nejsem. Jen mě v něm kdysi učili a žádný negativní vývoj mé osobnosti to neznamenalo.
Jaký způsob programování, proboha, učí Python? Styl "nějak to zbastlím a ono to ňák bude fungovat?" No, je fakt, že se to tak teď často dělá.

[rADOn]

Já jsem potkal dost lidí kterým pascal zkurvil mozek. Možná že určitý procento lidí na to prostě nemá a jen otázka aktuální módy jestli se z nich stanou zarytí fortranisti, pascalisti, javisti nebo phpčkaři. Ale pascal z toho nejhorší, protože učí věci který je pak potřeba se zase odnaučit pokud má být z člověka programátor. Já si pod "výukovým" jazykem představuju něco trochu jiného

[egg]

Ale pascal z toho nejhorší, protože učí věci který je pak potřeba se zase odnaučit pokud má být z člověka programátor.

Konkrétně?

[rADOn]

O tom by se daly psát knihy. Vezmi si třeba pitomej nápad mít středníky jako oddělovače. V žádným jiným jazyce to člověk nemusí řešit, jenom v pascalu se každej začátečník na tom spálí. Je z něj proto lepší programátor?

Podobných krávovin by se dalo najít plno. Ja už jsem naštěstí zapoměl co se dalo, ale kdysi jsem četl pojednání tuším od Denise (nebo někdo jinej, prostě někdo z otců-zakladatelů) kde ten jazyk dost přesvědčivě rozstřílel. Navíc ze svý praxe vím že jsem se v tom jazyku nic moc nenaučil. Nějaký ty smyčky a aritmetiku jsem znal z basicu a ve vsem ostatním pascal buď stojí za hovno nebo to vůbec neumí. Třeba objektový programování v turbo pascalu, to byla čirá šaškárna. IO – cirkus. Knihovny – rekurzivní pakárna. Standarní knihovna – ubohá.

AFAIK se ten jazyk u nás rozmohl jen proto že měl na svojí dobu špičkový vývojový prostředí.

[JS1]

Zrejme mas na mysli toto. I kdyz myslim, ze Pascal ve sve dobe nemel vubec spatne knihovny a vetsinu te Kerninghanovy kritiky novejsi verze jazyka opravily (ale nemam s tim primou zkusenost).

[egg]

Jediný konkrétní argument, co z tebe vypadl, je tohle:

... nápad mít středníky jako oddělovače.

To je z dnešního pohledu skutečně divné, ale na druhou stranu v novějších verzích jazyka nic nebrání tomu naučit se dělat středníky za každým příkazem. Pascalisti to tak obvykle stejně dělají, protože si tím zjednoduší připisování kódu na konec.

... kdysi jsem četl pojednání tuším od Denise ...

Byl to Brian Kernighan, ale jeho připomínky z velké části neplatí pro současné verze Pascalu.

[rADOn]

Problém se středníky není v tom že by nešel opravit, ale v tom že "výukový" jazyk který má zapotřebí opravovat takovéhle pitomosti prostě od začátku nebyl dobře navržený. Jestli chceš další tak si vezmi třeba modula ("units") – tak jak je to navržené si to nedokáže poradit s cyklickými závislostmi bez zavedení forward deklarací (které vzhledem ke kokotskému způsobu deklarací snad ani nejde do toho jazyka narvat) nebo nějaké hrozné magie uvnitř kompileru. Deklarace jsou ostatně další věc – mít všechny proměnné globální a na jedný hromadě je nejen pitomost, ale přímo antiteze programování kterou se člověk musí naopak odnaučit pokud chce opravdu programovat.

Byl to Brian Kernighan, ale jeho připomínky z velké části neplatí pro současné verze Pascalu.

Jinými slovy, "nalakovali jsme to hovno tak tlustě že vypadá jako koláč". Z toho je právě vidět že tvrzení že pascal je navržený v k výuce je kravina – pokud se nějaká současná verze pascalu skutečně dá učit, tak je to naopak proto že s tím jak byl ten jazyk navržen už nemá mnoho společného.

[kralyk z abclinuxu]

Z toho je právě vidět že tvrzení že pascal je navržený v k výuce je kravina – pokud se nějaká současná verze pascalu skutečně dá učit, tak je to naopak proto že s tím jak byl ten jazyk navržen už nemá mnoho společného.

Tak to máš pravdu, ale zas je potřeba pamatovat, že doba se vyvíjí a jazyky s ní. Prakticky každý trochu šířeji používaný jazyk prošel podobným vývojem. Viz třeba historický vývoj jazyka C, C++, Java, Python a dalších. Originální podoba těchto jazyků je z dnešního pohledu taky naprosto nevyhovující.

[rADOn]

To se teda pleteš. V céčku se od standartizace jen pilujou hrany. Na C++ běžně používám příručky dvacet let starý. A originální podoba pythonu je natolik, ehm, "nevyhovující" že se spoustě lidí vůbec nechce přecházet na trojku. I Java víceméně drží formu, přestože je to vlastně předčasně narozený dítě. Tím nechci říci že by se ty jazyky nevyvíjely, ale nebylo nutný v nich dělat nějaký masivní změny. Zatímco stále platný jádro tý brianovy kritiky pascalu je něco jako "no escape" – ten jazyk s žádným vývojem nepočítá a opravit některý zásadní vady znamená defacto vytvořit novej jazyk.

[egg]

Zatímco stále platný jádro tý brianovy kritiky pascalu je něco jako "no escape" – ten jazyk s žádným vývojem nepočítá a opravit některý zásadní vady znamená defacto vytvořit novej jazyk.

Brian napsal: "The language is closed," a pro tebe zřejmě tehdy Pascal skončil, uvázl jsi v minulosti. Ale bez ohledu na to se jazyk někam vyvinul, ty escape mechanismy dnes existují. Nebavíme se o verzi roku 1981.

[rADOn]

Vím že dneska je to jiný jazyk, ale pokud někdo tvrdí že pascal je vhodný na výuku protože tak byl navržen, tak se ergo baví o jazyku tak jak byl navržen. A jiný argument pro pascal jsem ještě neslyšel a ani nemohl, vylepšení v "moderním" pascalu jsou buď převzaté z jinych jazyků nebo opravy neduhů kterými jiné jazyky netrpí, takže se tím radši nikdo nechlubí. Přiznej si to, jedinej pozitivní rys pascalu jsou nostalgické vzpomínky jedné generace. A protože to nejde nijak kvantifikovat tak se vytahuje na světlo mýtus o tom jak byl navrženej na učení. Nebo mi řekni jediný jiný důvod proč učit pascal a ne třeba python.

[egg]

Já si myslím, že Python je dnes vhodnější než Pascal, míním to prosazovat, a sbírám za tím účelem všechny souhlasné i nesouhlasné argumenty. Je třeba je předkládat těm učitelům Pascalu. Ale tvé řeči mi v tom pramálo pomohly. Nevšiml jsem si, že by v této diskusi někdo argumentoval nějakým původním výukovým účelem. Jde mi o to, proč dnes neučit dnešní Pascal. Jasným argumentem je, že v praxi (a patrně i na zahraničních školách) se s ním dnes člověk setká spíš výjimečně, takže prakticky nikdo u něj nemůže setrvat. Rád bych ale tento důvod podepřel i argumenty na konkrétní problémy jazyka.

[JS1]

Rád bych ale tento důvod podepřel i argumenty na konkrétní problémy jazyka.

Takovou analyzu je mozne provest, ale chtelo by to konkretni referenci Pascalu, ktery se pouziva (nejsem v tom odbornik). Protoze jinak se opravdu budeme tocit v kruhu kolem toho, co napsal ten Kerninghan. (Ale obavam se, ze ten Pascal, ktery uci ucitele nijak standardizovan neni, takze je i tezke to objektivne vyvratit.)

[Blaazen]

Já chodím na diskuzní fóra (FreePascal a Lazarus) a dnes jsou největší komunity v Brazílii a hlavně v Rusku. Jeden ruský učitel tvrdil, že na výuku seu nich Pascal používá asi ze 40%. Největší rozdíl je ale v mentalitě. Ve světě se to bere tak nějak normálně, jeden jazyk z mnoha, koneckonců Delphi je běžně prodávané RAD a Pascal má dlouhou tradici. Zato tady je hned při zmínce o Pascalu flame, prostě pivu, fotbalu, politice a programování rozumí každej.

[Bystroushaak]

Jestli to spíš není tím, že pascal bylo mnoho lidí donuceno se učit a hned zase zapomenout, protože byl k ničemu už před 10 lety, natožpak dneska.

[Michal Kubeček]

Brian napsal: "The language is closed," a pro tebe zřejmě tehdy Pascal skončil, uvázl jsi v minulosti.

Je tu ale podstatný rozdíl: zatímco v případě céčka jsou nové verze standardizované (C90, C99), u Pascalu AFAIK žádná nová norma neexistuje (poslední se zdá být ta z roku 1990 a ta to, co tvrdíte, zdaleka nesplňuje), takže ten "vývoj" jsou ve skutečnosti jen rozšíření jazyka implementovaná různými autory překladačů; v případě Borland Pascalu a Delphi už bych spíš mluvil o novém jazyce založeném na Pascalu.

[kralyk z abclinuxu]

V céčku se od standartizace jen pilujou hrany.

No jo, ale kdy ta standardizace proběhla, že? Skoro 20 let od vzniku jazyka. I C++ se dost vyvíjelo, třeba abstraktní metody, statické metody, vícenásobná dědičnost, protected, const metody byly přidané v roce 89. Templates v roce 91 a exception handling až někdy v r. 93 nebo tak nějak...

Na C++ běžně používám příručky dvacet let starý.

No to neděláš dobře, např. o exception safety nebo o smart pointerech tam asi nic moc nebude... O featurách C++11 ani nemluvě...

[egg]

Ach jo, nedokážeš si odpustit ty emoce a vulgarity, aby se to dalo číst?..

[PetrHL]

Deklarace jsou ostatně další věc – mít všechny proměnné globální a na jedný hromadě je nejen pitomost, ale přímo antiteze programování kterou se člověk musí naopak odnaučit pokud chce opravdu programovat.

Toto nechápu. Všechny proměnné globální rozhodně nejsou, proč by měly? Samozřejmě si můžete nadeklarovat globální proměnnou, záleží jen na Vás. Ale všechny?

Mluvíme o dnešní výuce. Bylo by lepší srovnávat stávající verzi ObjectPascalu a ne vzpomínat na něco, co platilo před XX lety.

[kavol]

... kde XX je více než dvacet let, bo už za mejch mladejch let rozhodně neplatilo, že by všechny proměnné byly globální

[PetrHL]

Přesně tak. Já se s Pascalem potkal porve před 17 lety. Bohužel už nevím co jsem k tomu měl za knihu, jen si pamatuju že se jednalo o pokusy se zápisem a čtením ze souboru.

[rADOn]

No tak sorry, špatne jsem to pojmenoval. Nevím jak se správně nazývá to že všechny proměnný jsou v jednom "var" bloku který musí být na začátku programu/funkce/třídy. Ale stojím si za tím že pokud se někdo chce naučit slušně psát céčko, tak se tuhle úžasnou vymoženost musí odnaučit. A podle wiki to je i v "moderním" pascalu. Dokonce ani Java tohle nemá, a to je jazyk který se IMO v syntaktický buzeraci vyžívá.

[little.owl]

Ale stojím si za tím že pokud se někdo chce naučit slušně psát céčko, tak se tuhle úžasnou vymoženost musí odnaučit.

Proc je to problem?

[rADOn]

Proc nekomu rvat do hlavy zbytecnosti? Nejsi ty nahodou profesi ucitel?

[little.owl]

Nejsi ty nahodou profesi ucitel?

Nejsem, to bych byl jiz ve vezeni za mlaceni studentu.

Nemyslim si ze nutnost mit promenne deklarovane na zacatku bloku (<=C89) byl nekdy problem, nektere coding standards to vyzaduji, s komentari, dodnes.

Pokud vam cini obtize i takovehle niance, budete mit problem pestovat i mrkev .

[j]

Deklarace na zacatku bloku je spis o prehlednosti => kouknu a vidim, nepotrebuju prohledavat cely blok kde se tam bere jakysi cosi.

A nepamatuju ze by to nekdy bylo nutny, stacilo promennou deklarovat pred prvnim pouzitim, ale to pak vedlo k tomu, ze neco dohledat bylo peklo.

A dobrym zvykem je to i proto, ze Ccko(Cckari) dost dbali rozdilu mezi deklaraci a definici, pricemz deklarace byly vyobcovany do Hcek (technicky to samo nutny nebylo, pokud nehodlal dotycny poskytovat nejaky API ven).

[JS1]

Treba kniha Coding Complete explicitne doporucuje deklarovat promenne uvnitr bloku, nikoli na zacatku funkce. Ale jinak ano, nazory jsou ruzne.

[little.owl]

A nepamatuju ze by to nekdy bylo nutny

Starsi standardy vyzadovali deklaraci lokalnich promennych na zacatku bloku (ANSI, C89, C90) a zakazovali mixovat deklaci a kod. I dnes u gcc staci pouzit -ansi -pedantic a jste v tom:

void fnc() {}

int main()
{
    fnc();
    int a;
    return 0;
}

a pak dostanete:

test.c:9:5: warning: ISO C90 forbids mixed declarations and code [-Wpedantic]
     int a;
     ^

Takze bud jste pouzival novejsi nebo tolerantnejsi kompilatory a nebo kaslal na standardy jazyka.

[rADOn]

Ani jedno.

radon@xenon ~ $ cat test.c
void fnc() {}

int main(void) {
    fnc();
    {
        int a;
        return 0;
    }
}
radon@xenon ~ $ gcc -ansi -pedantic -o test test.c
radon@xenon ~ $

To je prave ta tragedie ze "vyukovy" jazyk misto aby ti vysvetlil k cemu jsou dobry obory platnosti, tak te naucil ze to neexistuje.

[pavlix]

Kde máš tu deklaraci, co není na začátku bloku?

[little.owl]

+1

[rADOn]

To už škrábete dno Já jsem nepsal "na začátku bloku", ale na "na začátku programu/funkce/třídy". Kdyby šlo v pascalu přidat var sekci do jakýhokoliv bloku, tak bych samozřejmě neřekl ani B. Umí to nějaký ten "moderní" pascal, nebo se jen chytáte slovíček protože si nechcete přiznat že to není dobrej nápad?

[little.owl]

"na začátku programu/funkce/třídy"

A ja jsem psal na zacatku bloku v C, Pascal mi byl vzdy ukradeny a byl jste to vy, kdo z toho zacal delat tragedii a tahat do toho i C. Telo funkce je z hlediska C standardu take blok a pravidla se aplikovala i na nej. Napsal jsem pomerne dost certifikovaho kodu podle C89, jakykoliv warning od kompilatoru byl blocker a nikdy nebyla nutnost mit lokalni promenne definovane na zacatku problem, spise naopak.

[kralyk z abclinuxu]

To je prave ta tragedie ze "vyukovy" jazyk misto aby ti vysvetlil k cemu jsou dobry obory platnosti, tak te naucil ze to neexistuje.

To je pravda, nicméně Pascal se už dnes neučí. Dnes je to ještě horší. Učí se Java, ve které obory platnosti už vůbec nejsou a správa paměti se řeší tak, že se neřeší, navíc je stuedntům vtlučeno do hlavy, že OOP = objekty v Javě a že společně s GC to je nejvíc nejlepší věc v programování :-/

[Blaazen]

V Pascalu je pravidlo, že vše musí být předem deklarováno, proto ten var blok a proto někdy ty forward deklarace. V tomhle:

procedure Foo;
var i: Integer;

  procedure Subfoo;
  begin
    //code
  end;

var j: Integer;
begin
  //code
end;

může ta nested procedura používat i, ale ne j. Důvod je, že Pascal kompiluje jen na jeden průchod, proto jsou kompilery hodně rychlý. Vývojář FPC nedávno uváděl, že FPC zkompiluje sebe (je to self-hosting) 300 000 řádek za 4,2s na Core i7.

[Michal Kubeček]

Myslím, že kolega měl na mysli spíš proměnné s omezeným scope, např.

while (...) {
  const struct device *dev = a[i].dev;

  ...
}

nebo (v C99) rovnou

for (unsigned i = 0; i < N; i++) {
  ...
}

[rADOn]

Přesně to jsem měl na mysli. Zvláště druhý příklad je ilustrativní – v pascalu se cykly afaik obvykle řeší tak že se nadeklaruje i, j, k a ty se pak používají v celém bloku opakovaně, což je samo o sobě šeredný zlozvyk.

[egg]

Pravda, to je nebezpečný zvyk.

[Miloslav Ponkrác]

I já jsem se učil základy programování na Pascalu a dodnes za to děkuji bohu. Považuji to za jeden z nejlepších začátků.

Ačkoli pro praxi se Pascal nehodí, jako výukový jazyk je IHMO geniální.

Kdybych si mohl dnes vybrat, tak bych odmítl se učit programovat v Pythonu, a zejména v Javě.

Kdybych znovu začínal, považuji za nejlepší se na začátek učit nejdříve Pascal nebo ještě lépe Adu, ten pak zahodit a dále se učit souběžně C++ a LISP. Tou cestou bych dnes šel, kdybych začínal znovu.

Vycházím z toho, že „výuka programování“ by měla něco naučit, nikoli být jednoduchá, či dávat rychlé výsledky. Cílem je dát dobrý základ, nic víc, ale nic méně.

To, že se „někdo plácá v syntaxi“ je dobře, protože učení chce námahu, pokud ta námha je smysluplná. Pokud někdo má vážný problém se syntaxí tak jednoduchého jazyka jako je Pascal, pak z něho nikdy programátor nebude, protože na to nemá svými schopnostmi. Je třeba se plácat v jazyce, který Vás bude opravovat, nutit Vás abyste dodržovali typy, obraty, meze, a další. To je ten nejlepší učební jazyk.

Pascal je velmi geniální jazyk pro výuku. Pro praxi je špatný.

Za nejhorší volbu pro výuku považuji Javu, zlé návyky se pak roky napravují.

Ale jinak už nebudu do flame tématu zasahovat.

Miloslav Ponkrác

[Agent]

Co je to zlý návyk? Je zlý jen pro vás nebo obecně zlý pro každého? Já bych výuku začal obecně principy a návrhem OOP pomocí diagramů a připravených projektů. Pak bych postupně plynule přešel ke psaní kódu.

[Miloslav Ponkrác]

Jsem velmi rád, že jste mě nevyučoval. Protože s Vaší výukou bych se nejspíše nikdy dobře programovat nenaučil.

Jednak proto, že cpát začátečníkovi jako první OOP považuji za zločin vůči lidským právům. Ale na druhé straně, čím více fanatických OOP učitelů, tím méně konkurence v programátorské branži. Jednak je to dokonale demotivační pro začátečníka, druhak poměrně slušně vytvářející chaos v hlavě začátečníka a zabraňující pochopení.

Filozofické debaty jako o obecném principu zla bych nechal na jiných serverech. Ano, máte pravdu, že zlé návyky jsou do jisté míry subjektivní, například masochisticky naladění lidé si rádi ubližují, a pak je otázkou, zda takové návyky jsou pro ně zlé. A jiní, sadisticky naladění lidé jim je rádi dopřejí.

Nicméně obecně se v této debatě předpokládá, že člověk se chce stát efektivně programátorem a naučit se dobře programovat, a přitom netrpí žádnou sexuální deviací, jako je sadomasichismus, apod.

Učitelé mají vysokou odpovědnost, a začátečníci jim musí věřit a věřit jejich zkušenostem a pedagogickým schopnostem. Ale ne každý učitel je pedagogicky a/nebo odborně na výši. To je risk.

[JS1]

Mas tohle, tohle nebo tohle v Pascalu? Python je idealni jazyk pro lidi, kteri se chteji naucit jenom jeden jazyk, treba proto, ze jejich skutecny obor je neco jineho nez programovani.

[TM]

Ale s tím nejsem ve sporu. Vždyť jsem psal, že je to takový dnešní BASIC. Řeč ale snad byla o výchově programátorů(??)

[JS1]

Pokud chces vychovavat programatory, nema smysl je ucit Pascal. Programator by se mel naucit ty nejcastejsi (Java, C, C++) a pak jazyky ruznych paradigmat (Lisp, Haskell, Prolog, Erlang, Forth, assembler..). Pascal neni dost odlisny od tech bezne pouzivanych na to, aby melo smysl ho ucit jako dalsi jazyk navic.

Je to proste tak ci onak mrtva vec.

Jinak prirovnavat Python k BASICu moc nesedi. To byla prave IMHO hlavni chyba BASICu, ze se prilis orientoval na vyuku a amatery. Naopak Python se snazi byt navrzeny dobre i pro profesionaly, a diky tomu je tak uspesny (diky tomu porazi ruzne niche ad hoc jazyky, jako treba prave ten MATLAB).

[JS1]

Jo, to jsem zapomnel - programator by take mel znat neco skriptovaciho, aspon shell, nebo prave ten Perl/Python/Ruby.

[deda.jabko]

Programator by se mel naucit ty nejcastejsi (Java, C, C++)

Bylo by dobre rozlisovat dva vyznamy "ucit se programovat". (1) Ucit se programovat per se (obecne vytvaret programy). (2) Ucit se programovat v konkretnim jazyce. V pripade (1) je zadouci, aby se programovaci jazyk pletl do programovani co nejmene. Tohle dobre splnuje prave Python nebo dialekty Lispu. V pripade (2) je zadouci, aby clovek pochopil poradne jazyk, ve kterem programuje vcetne detailu. Delat obe veci soucasne sice jde, ale je to silenost. Mnohem rozumnejsi je jit od bodu (1) k (2).

Jazyky Java, C, C++ jsou naprosto nevhodne pro "ucit se programovat" ve vyznamu (1).

Java (obzvlast ve verzi 8) -- vnitrne nekonzistentni jazyk, aby clovek pochopil radu nelogicnostni, musi pochopit vyvoj tohoto jazyka, takze vedle programovani se clovek musi naucit i neco z dejepisu. Z tohoto pohledu by zajimavym resenim mohla byt Scala.

C -- pro pochopeni i tak elementarnich operaci jako je prace s retezci nebo poli, musi clovek pochopit, jak vlastne funguje procesor a pamet. Tohle muze byt bug i feature. ;-]

C++ -- takovy jeden velky programatorsky eintopf.

[JS1]

Vesmes souhlasim - psal jsem co by se mel ten absolvent naucit, ne v jakem poradi.

A s tou Scalou, sice ji neznam, ale dost me to desi - pripomina mi ten eintopf taky.

[Miloslav Ponkrác]

Tvrdě nesouhlasím.

Ad 1) Učit se programovat – za nejlepší považuji důkladné studium matematiky, algoritmizace a teoretických předmětů. A pak potřebujete programovací jazyk, který bude třeba složitější, ale naučí Vás dobře základy.

Ad 2) Učit se programovat v jazyce je jen to, že se učíte řemeslo. Pokud se budete učit s hoblíkem je to analogie v truhlářství. Pak si musíte vzít ten hoblík.

[JS1]

A co deti? Chces je ucit programovat tim, ze jim nejdrive predepises dva semestry algoritmizace? To je pekna ptakovina.

Nas ucili ve 3.tride na ZS programovat v Karlovi. Ta myslenka, ze muzu pocitac neco naucit, a on to pak bude umet - neboli koncept procedury - byla uchvatna! Mel jsem cely sesit popsany procedurami v Karlovi, ktere stavely na tech predchozich, pritom jsem neznal ani cykly a podminky. A slovo algoritmus jsem neznal nez jsem prisel na vysokou skolu. I bez dukladneho studia teorie lze pochopit zaklady.

[deda.jabko]

A co deti? Chces je ucit programovat tim, ze jim nejdrive predepises dva semestry algoritmizace?

Celkove je ta myslenka ujeta. A je jedno, jestli jsou to deti nebo dospeli, s takovym pristupem by byli demotivovani uplne vsichni. Ucit se programovat bez programovaciho jazyku je zhruba tak efektivni jako ucit se plavat na sousi a pak zkouset preplavat kanal La Manche. Vylozene mne to pripomnelo.

[JS1]

Tak vsichni zase ne, par lidi se takhle naucilo programovat. Napriklad Alan Turing.. V podstate je to pristup z 50.let, ze se vzal matematik a postavil se k tem elektronkam..

[Miloslav Ponkrác]

„A co deti? Chces je ucit programovat tim, ze jim nejdrive predepises dva semestry algoritmizace? To je pekna ptakovina.“

Co znamená přesně termín „učit programovat“? Proč by se algortimizace měla učit na ZŠ univerzitními metodami? Ono se dá vymyslet i zábavnější forma.

---

„Nas ucili ve 3.tride na ZS programovat v Karlovi. Ta myslenka, ze muzu pocitac neco naucit, a on to pak bude umet - neboli koncept procedury - byla uchvatna! Mel jsem cely sesit popsany procedurami v Karlovi, ktere stavely na tech predchozich, pritom jsem neznal ani cykly a podminky. A slovo algoritmus jsem neznal nez jsem prisel na vysokou skolu. I bez dukladneho studia teorie lze pochopit zaklady.“

Tedy Vás učili algoritmizaci. Jen jiným způsobem. Vlastně jste důkladně studoval, jen to bylo uděláno formou, která bavila, a tak to mylně nenazýváte „studiem“.

Protože 99 % lidí v této diskusi by to odsoudilo. Karel není programovací jazyk, kterým si budou vydělávat v praxi.

---

Podívejte se, co tu doporučují lidi v diskusi. Samé ptákoviny. Musí to být Python. Musí to být OOP. Atd.

Přitom programování je o něčem jiném. Programovací jazyk, či OOP či zvládnutí pár syntaktických vychytávek je jen řemeslné dotáhnutí, které se naučí i nejblbější cvičená opice, když bude chtít.

Proto se ptát, co znamená „programovat“. Já jsem třeba dnes programoval pračku. Jiní si myslí, že programují, když dělají formuláře v grafickém návrháři. Další si představují, že když napíší HTML dokument a umí do toho vsadit značku <a>, že programují v HTML. Jiní (zejména javisté) si zase představují, že programování je volání knihoven i tam, kde potřebuji jeden cykl nebo jednu podmínku.

Každé „učení programování“ má jinou potřebu na jazyk i metodu podle očekávaného cíle.

[JS1]

Tak co chces tedy ucit jinak? Nemuzu mluvit za ostatni, a jsem proti vyuce OOP hned na zacatku. Python prosazuji proto, ze se v nem dobre pise, zejmena proto, ze existuje spoustu knihoven.

Deti (nebo mladez, aby me Michal Kubecek nenapominal ) typicky chteji psat hry, nebo alespon neco grafickeho. Ano, v polovine 90. let se tohle realne dalo delat v Pascalu. Dneska jsme ale uz nekde jinde.

[Miloslav Ponkrác]

Já jsem také proti výuce OOP od začátku. Myslím, že na OOP je čas, až člověk dokonale zvládne strukturované programování a pochopí co je podprogram, parametry, cykly, proměnné, typy, struktury, výčtové typy, pole, …

V polovině 90. let byla mládeži přizpůsobena řada projektů. Přesně těmto choutkám. Protože grafiku dělal i ten pitomý basic. Kromě toho byl Karel, nebo programovací jazyk Logo.

Vlastně i v C/C++ Borland měl svou BGI knihovnu, kde se dalo v grafice velmi schopně a snadno kreslit.

Dnes se ovšem grafika dělá přes ruku. Knihovny obvykle počítají s událostmi, sizery, plus zapojí několik objektových návrhových vzorů. Je to složité jako dvoják žebř. V tom se hrát nedá.

[JS1]

Pokud mluvite o GUI, ja pouzival PyQt a byla to brnkacka. Zadne udalosti jsem resit nemusel. Trochu OOP je potreba znat, ale to bylo potreba i v tom Turbo Vision.

A dnes jsou veci jako Khan Academy, kde ten zdrojak v Javascriptu muzete interaktivne menit. Takove moznosti, co driv, existuji i dnes a daleko lepsi.

Navic, trochu ty deti podcenujete. Programovat se muze naucit skoro kazdy, fakt to neni o moc tezsi, nez vareni (jak psala Grace Hopper).

[Miloslav Ponkrác]

„Pokud mluvite o GUI, ja pouzival PyQt a byla to brnkacka. Zadne udalosti jsem resit nemusel. Trochu OOP je potreba znat, ale to bylo potreba i v tom Turbo Vision.“

Ve všem, o čem píšu, to byla větší brnkačka a objekty nebyly potřeba.

---

„Takove moznosti, co driv, existuji i dnes a daleko lepsi.“

Ano, někde na okraji existují. Zatímco dříve to byl mainstream.

Ještě jedna věc se změnila. Dříve bylo daleko více lidí, kteří věcem opravdu rozuměli, a dokázali poradit a rádi. Dnes je hledáte lucernou v poledne. A řekl bych, že tento efekt je daleko nejdůležitjěší. (Linuxová komunita jako první zavedla, že radění a dotazy obtěžují.)

---

„Navic, trochu ty deti podcenujete. Programovat se muze naucit skoro kazdy, fakt to neni o moc tezsi, nez vareni (jak psala Grace Hopper).“

Já je nepodceňuji. Opakovaně píši, že programovat se naučí i nejblbější cvičená opice. Stačí projít mé příspěvky zde.

[Agent]

Já sem třeba pochopil (aspoň si to myslím) principy OOP aniž bych uměl ještě bůhví jak programovat. Podle mě se to nevylučuje. Je to sice abstraktní, ale co není? Nevidím v tom problém, pochopit principy OOP a začít programovat hned objektově.

[j]

Ale starou belu, studiem matiky se vzivote nikdo programovat nenucil ... programovani vyzaduje kreativni mysleni, premejsleni nad problemem ... na to matiku vubec netreba. A az bude programator potrebovat nejaky sofistikovany algoritmus, tak si ho necha vysvetlit od matematika.

[Miloslav Ponkrác]

Zatímco matematika žádné kreativní myšlení nepotřebuje. Vy vtipálku!

[j]

Ne, matematika vyzaduje dril a kreativitu naopak temer totalne ubiji.

[Miloslav Ponkrác]

Nemusíte dokola opakovat, že matematice ani zbla nerozumíte. Už to všichni chápou.

[j]

Nemusis to porad dokola dokazovat ze si negramotny blb, to vsichni pochopili uz davno.

[Michal Kubeček]

Jedině za předpokladu, že slovem "matematika" myslíte předmět na základní nebo střední škole vedený nepříliš osvíceným učitelem, ne matematiku jako takovou.

[j]

Nevsim sem si, ze by se za poslednich rekneme 50let v matematice udalo neco zasadniho. Jestli ono to nebude tim, ze matematici obecne jsou skostnateli stari dedci (s par nezajimavymi vyjimkami). Podotykam, ze s matikou sem nikdy nemel zadny problem - ani na VS ne. Ale prave na te VS me bavit postupne zcela prestala. Nebot dohadovat se s onim zminenym starym dedkem na tema zda v definici ma byt carka pred ale ... na to sem opravdu silu nemel.

A to muzu vzpomenout takove udaloste, jako ze jisty kolega opsal pri zkousce pozadovanou definici ze sript, jejiz autorem byl dotycny zkousejici a presto ho zacal prcat za to, ze je to spatne... nacez mu to dotycny vpalil stim, ze je vul, kdyz to tedy spatne uci ...

[Michal Kubeček]

jisty kolega opsal pri zkousce pozadovanou definici ze sript, jejiz autorem byl dotycny zkousejici a presto ho zacal prcat za to, ze je to spatne

Vynechal jste dost podstatnou informaci: jestli ta definice byla špatně. Bez ní tu historku lze jen těžko hodnotit.

Ale ano, jistě, i na vysokých školách se může člověk setkat s tím, že matematiku vyučuje někdo, kdo by pokud možno neměl vyučovat vůbec nic. Mně se třeba stalo, že mi ve třetím ročníku na matfyzu zkoušející řekla něco ve smyslu: "No, je sice hezké, že si to dokážete odvodit, ale já bych radši, kdybyste se to naučil." Jenže na rozdíl od vás to beru jako problém té vyučující, ne vědního oboru.

[kavol]

Mně se třeba stalo, že mi ve třetím ročníku na matfyzu zkoušející řekla něco ve smyslu: "No, je sice hezké, že si to dokážete odvodit, ale já bych radši, kdybyste se to naučil." Jenže na rozdíl od vás to beru jako problém té vyučující, ne vědního oboru.

vynechal jste dost podstatnou informaci ... jestli tam ta vyučující seděla v pátek odpoledne třikrát tak dlouho než by stačilo, kdybyste se nezdržoval odvozováním - bez ní tu historku lze jen těžko hodnotit :-p

[Michal Kubeček]

Ne, to rozhodně ne. Jen jsem párkrát u nějakého zřejmého dílčího tvrzení, když si vyžádala důkaz, předvedl jiný, než ona přednášela. Pokaždé to okomentovala "Ale my jsme si to na přednášce dokazovali takhle: …" Kdyby opravdu nechtěla zbytečně ztrácet čas, mohla si odpustit to předvádění "oficiálních" důkazů.

[jas]

Toto sa skutocne dialo? Aj na matfyze? Zacinam byt celkom rad, ze som sa s niecim takym pocas mojich studii nestretol a to som dokazy zasadne odvodzoval (u zlozitejsich s tym, ze som si zapamatal zbeznu ideu) a neucil sa ich naspamat. Ta osoba by v mojich ociach zrejme po niecom podobnom klesla velmi vyrazne.

Co sa tyka povodneho pribehu od j, tak by som kludne veril tomu, ze skusajuci povedal, 'keby aspon ta ciarka pred ale bola spravne, tak vam tu druhu chybu v definicii odpustim, ale takto...', co si j transformoval na vlastnu verziu 'bolo to blbo kvoli ciarke'. Inak povedane: neverim tomu, ze by ho od skusky vyhodil ten clovek len kvoli chybajucej ciarke, ta ciarka bola pravdepodobne uz len posledny klinec do rakvy. Podobnych verzii pribehov som uz pocul pozehnane a nevybavujem si ani jeden pripad, kedy neslo o skratenu/skomolenu/nepochopenu verziu povodneho vyroku skusajuceho.

Co sa tyka druheho pribehu od j, tak tiez by som to videl na chybu v skriptach. V skriptach byva chyb neurekom, aj preto byvaju skripta casto oznacovane len za pomocne materialy (na prednaske to snad bolo odprednasane spravne). Osobne som sa niekolkokrat stretol s tym, ze ucitel vyslovene na prednaske povedal -- v pripade nezrovnalosti medzi skriptami a odprednasanym ucivom je rozhodujuce odprednasane ucivo.

[Michal Kubeček]

Toto sa skutocne dialo? Aj na matfyze?

Za celou dobu studia se mi něco takového stalo jen jednou a samozřejmě mi to vyrazilo dech. Naopak, při jiné příležitosti udělalo přednášejícímu zjevnou radost, když jsem mu předvedl jiný důkaz, než ukazoval na přednášce (ale to byla nějaká složitější věta a důkaz jsem si rozmýšlel doma, jenže jsem na té přednášce nebyl a zapomněl jsem si od někoho půjčit poznámky). A při zkoušce z míry dokonce přednášející razil zásadu, že kdo chce jeničku, musí být schopen něco sám vymyslet.

v pripade nezrovnalosti medzi skriptami a odprednasanym ucivom je rozhodujuce odprednasane ucivo

Takhle bych to asi neformuloval. I v tom odpřednášeném mohou být chyby, aniž by si jich kdokoli z přítomných všiml.

[jas]

Za celou dobu studia se mi něco takového stalo jen jednou a samozřejmě mi to vyrazilo dech. Naopak, při jiné příležitosti udělalo přednášejícímu zjevnou radost, když jsem mu předvedl jiný důkaz, než ukazoval na přednášce (ale to byla nějaká složitější věta a důkaz jsem si rozmýšlel doma, jenže jsem na té přednášce nebyl a zapomněl jsem si od někoho půjčit poznámky). A při zkoušce z míry dokonce přednášející razil zásadu, že kdo chce jeničku, musí být schopen něco sám vymyslet.

S tymto pristupom som sa uz stretaval castejsie. Aj ked, ked som teraz zavrtal v pamati, tak sa sem-tam stalo, ze nejaky doktorand (na bakalarskom stupni) nieco opravil v style 'asi mas pravdu, ale na prednaske sa to robi inak'.

Takhle bych to asi neformuloval. I v tom odpřednášeném mohou být chyby, aniž by si jich kdokoli z přítomných všiml.

To, ze obe tie verzie su az za ich formalne spravnou definiciou je ocakavane implicitne (aspon ja som to tak vzdy bral, nejaka mensia chyba (hlavne preklep) sa tam najde, vacsiu by si uz mal prednasajuci snad vsimnut). V tychto pripadoch slo skor o to, ze skripta boli zastarale, pripadne pisane inymi ludmi alebo pre inak koncipovane predmety. Vysledkom bolo, ze tam boli tie rozdiely dost vyrazne a neslo len o nejake male preklepy a pod.

btw: Tie chyby tam mozu byt aj ked si ich niekto vsimne, aspon ja som na trivialne chyby na prednaskach neupozornoval.

[kavol]

nu dobrá ... když ono některé fakt mrzí, když jim lidi na ty přednášky nechodí, nebo tam spí[*] apod.

[*] to jsem měl jednou takové období, že mi padala hlava i ve speciálních protispacích lavicích ... tak jsem si to hezky vyslechnul, jak kazím přednášku (to jsem ovšem nechrápal!), tak jsem tam radši už nechodil vůbec ... načež jsem si taky u zkoušky vyslechnul "ale vy to máte všechno špatně!" - "jak špatně?" - "to má být jeden sloupec" - "aha, ale na výsledek to sedí, ne, tak tady a tady a tady dopíšu T jako že transponovaný, a bude to dobře, ne?" - "no to ano, ale my jsme si to ukazovali takhle ..."

[egg]

Podstatou matematiky není dril a puntičkářství. Jde o způsob myšlení, vnímání pravidelnosti a struktury ve věcech kolem. Využívání matematiky k řešení reálných problémů je velice kreativní proces a je blízce příbuzný programování. Matematika je jazyk, kterému je třeba se nejdříve s určitou pílí učit, ale pokud jím člověk "plynně hovoří", je to svého druhu superschopnost.

Podívej třeba na prof. Druckmüllera z VUT Brno a jeho snímky ze zatmění Slunce. Jeho způsob zpracování fotek, který odhaluje jemné struktury ve sluneční koróně, prakticky posunul vědecké expedice za tímto jevem na novou úroveň, nikdo jiný předtím takové obrázky neuměl. Přitom astronomie nebo fyzika plazmatu vůbec není jeho oborem, jen prostě využil své matematické schopnosti a spojil je s programováním.

[little.owl]

Nevsim sem si, ze by se za poslednich rekneme 50let v matematice udalo neco zasadniho.

To snad ne ...

Kouknete se alespon za co dostali nekteri matematici Fieldsovu cenu, obdobu Nobelovi ceny, a pak si uvedomite, ze vyvoj jde dale a nezamrzl.

[Bystroushaak]

Pokud chces vychovavat programatory, nema smysl je ucit Pascal. Programator by se mel naucit ty nejcastejsi (Java, C, C++) a pak jazyky ruznych paradigmat (Lisp, Haskell, Prolog, Erlang, Forth, assembler..). Pascal neni dost odlisny od tech bezne pouzivanych na to, aby melo smysl ho ucit jako dalsi jazyk navic.

Souhlasím. Podle mě by bylo taky dobré, aby ten programátor v té které zemi našel práci, až vypadne ze školy. Zrovna v pascalu bych se bál, že bude mít silný problém a pokud už něco najde, bude to z většiny jen údržba existujícího hororového systému vzniklého v době, kdy se nepoužívalo nic z dnešních vymožeností (například git a unittesty).

[Miloslav Ponkrác]

A jaký je problém naučit se jiný programovací jazyk? Vždyť jsou všechny na jedno brdo.

POkud umíte programovat, což je schopnost nezávislá na programovacím jazyce, pak stejně neodhadnete, co bude frčet za rok, za dva, …

[Bystroushaak]

Pro mě osobně to žádný problém není a minimálně na úrovni orientace v kódu a psaní jednoduchých programů (čti; naprogramoval jsem v nich malé projekty do pár tisíc řádek) jich umím cca 8 nebo víc.

Na druhou stranu, lidé, kteří nejsou takoví nadšenci jako já to považují za opruz a naprostou demotivaci se této oblasti věnovat, i když si v ní jinak nevedou vůbec špatně. Nemůžu říct, že bych se jim divil.

[Miloslav Ponkrác]

„Na druhou stranu, lidé, kteří nejsou takoví nadšenci jako já to považují za opruz a naprostou demotivaci se této oblasti věnovat, i když si v ní jinak nevedou vůbec špatně. Nemůžu říct, že bych se jim divil.“

Rozumím. Katka ráda čte a ráda čte knihy vysázené fontem Dejavu Serif. SIce by poměrně rychle byla schopná číst knihy vysázené i fontem Times New Roman, nebo Helvetica, ale bylo by pro ni demotivující číst takové knihy. Nemůžu říci, že bych se jí divil.

Jen abych analogicky vyprášil stejnou obtížnost.

[Bystroushaak]

Analogie by spíš byly knihy v latině a angličtině.

Katku ve škole naučí latinsky a Katka je v tom docela dobrá. Pak jednoho dne složí všechny zkoušky a začne hledat na trhu práce, ale kde nic tu nic, občas se vyskytne nějaká nabídka, ale tam chtějí 6+ let praxe a to Katka prostě nemá. Do toho Katce na pracáku řeknou, že by se měla naučit anglicky, vždyť 90% nabídek je v angličtině. Ani to není moc složité, naopak je to dost podobné, jen jiná slovíčka a větné konstrukce, ale vlastně je to taky jazyk, taky se jím dá mluvit, jen se píše trochu jinak, ale funguje veskrze stejně a určitě jí to hodně rozšíří obzory.

Jsou lidi, kteří se na Katky místě s radostí pustí do práce, protože mají spoustu času a baví je se učit nové jazyky. Pak lidi, kteří začnou hledat problém ve školství, které je učí věci k ničemu a nikdo je tam na tohle nepřipravil a lidi, kteří si prostě začnou hledat práci v jiném oboru. Přitom všechny tyto skupiny mohou být tvořeny lidmi s velkým talentem, kteří jsou ovšem odrazeni tím jak to funguje.

[Miloslav Ponkrác]

Zvládl jste kdy alespoň jeden programovací jazyk? Víte o čem to je?

Je to o cca 30 klíčových slovech a několika pravidlech gramatiky. To je celý programovací jazyk. Plus mít před sebou otevřenou nápovědu s referenční příručkou ke standardní knihovně.

Nic, co by Kaťule, pokud už nějaký programovací jazyk zná a něco naprogramovala, nezvládla za den, v nejhorším za dva, když bude tupá a nenadaná.

Je třeba vymýšlet přirovnání, která nekulhají na všech osm nohou.

[deda.jabko]

Je to o cca 30 klíčových slovech a několika pravidlech gramatiky. To je celý programovací jazyk.

Wow! A kam se podela semantika a pragmatika? A to nemluvim o operacni semantice jazyka, kterou je taky dobre znat.

Je to o cca 30 klíčových slovech a několika pravidlech gramatiky. To je celý programovací jazyk. Plus mít před sebou otevřenou nápovědu s referenční příručkou ke standardní knihovně.

Super, chci videt jak s touto vybavou naucite ceckare Haskell a C#-pistu Lisp.

[Miloslav Ponkrác]

To, že se z jednoduché věci dělá složitá a vypouští se hustá mlha, to jsou jen řeči.

---

„Super, chci videt jak s touto vybavou naucite ceckare Haskell a C#-pistu Lisp.“

Dejte jim k dispozici zaměstnání s vynikajícím platem, který se neodmítá a dejte si tuto podmínku na znalosti. Uvidíte, jak snadné to bude.

[FrostyX]

Nic, co by Kaťule, pokud už nějaký programovací jazyk zná a něco naprogramovala, nezvládla za den, v nejhorším za dva, když bude tupá a nenadaná.

Měl byste uznat, že vás setřel. Nevěřím tomu že Kaťule, byť třeba geniální slečna, ostřílená v C, by byla schopná se za "den, přinejhorším za dva" naučit Haskell.

[FrostyX]

... na takové úrovni, aby mohla být zaměstnaná jako programátor v Haskellu na velmi dobře placené pozici, která byla zmíněna výše.

[Bystroushaak]

Zvládl jste kdy alespoň jeden programovací jazyk? Víte o čem to je?

Já dělám sedmým rokem v Pythonu (od února na fulltime) a taky občas v D a v C. Škrtl jsem si i o lisp, rebol, matlab, C#, javu, c++, php, javascript, pascal (na něm jsem začínal) a pár dalších (momentálně se chci zaměřit na smalltalk). Takže ano.

Je to o cca 30 klíčových slovech a několika pravidlech gramatiky. To je celý programovací jazyk. Plus mít před sebou otevřenou nápovědu s referenční příručkou ke standardní knihovně.

Ne, to je syntaxe. Naučit se myslet v tom kterém jazyce a psát idiomaticky a efektivně, to je potom úplně o něčem jiném a trvá to dlouhá léta. Pěkně to jde vidět třeba u lidí, co přejdou z javy na python, jeden takový hororový příběh jsem v nedávné době pozoroval podstatně blíž než je mi libo a ještě po něm přepisoval pár hrůz.

[Miloslav Ponkrác]

„Naučit se myslet v tom kterém jazyce a psát idiomaticky a efektivně, to je potom úplně o něčem jiném a trvá to dlouhá léta.“

Ano, proto jsem dal tu podmínky, že ten člověk umí programovat. Protože „programovat“ a „bouchat kód“ jsou dvě různé věci. Bohužel mnoho lidí si myslí, že umí programovat, ale ve skutečni patří do druhé kategorie.

Ona uklízečka je také manažerka, byť podlahových krytin, když budete chtít. A stejně tak programátor je i ten, kdo zatočí kolečkem u pračky. Nebo napíše HTML stránku („hledáme HTML programátora“).

Skutečný programátor s tímto problémy nemá. Jakmile se naučíte psát efektivně ve 2 jazycích, ideálně velmi odlišných, pak jste-li skutečný programátor, platí to, co jsem napsal.

Ale ano, bouchač kódu, co se to naučil praxí a ostantí opovrhuje („teorie“ and/or „škola“ je zbytečná, všehcno mě naučí v praxi), ten to bude mít tak, jak píšete.

Jakmile někdo klade důraz na programovací jazyk, není to programátor. Je to řemeslník alias bouchač kódu. Takoví jsou potřeba. Ale nejsou to programátoři.

---

„Pěkně to jde vidět třeba u lidí, co přejdou z javy na python, jeden takový hororový příběh jsem v nedávné době pozoroval podstatně blíž než je mi libo a ještě po něm přepisoval pár hrůz.“

Už několik let opakovaně mluvím o tom, že chcete-li neumět programovat a roky se plácat v chaosu, není lepší cesta, než začít Javou. Takže ano, javisté, pokud nepřešli na jiný jazyk, neumějí programovat obecně, protože si zvolili strategicky nejhorší cestu. DObře jim tak.

[j]

Hele ponkrac, od tebe bych si nenachal psat ani hello world ... protoze ty zjevne nechapes, ze postup, ktery v jednom jazyce muze byt zcela koser efektivni zpusob jak neceho dosahnout, muze byt v jinym jazyce naprosta tregedie. Par takovych jako ses ty uz sem potkal ... ten jejich hello world pak ma binarku 30MB velkou a potrebuje 100MB RAM. A to jen proto, ze v (trebas) Ccku aplikujou javu.

[little.owl]

No jo, on je asi vyjmecny. S obecnou algoritmizaci ma pravdu, nicmene kdyz se prejde na schopnost dobre kodovat v jazyce XY, prinejmensim u me to zavisi na tom jak moc v danem jazyce mam jiz naprogramovano; prvni kod je obvykle neohrabana osklivost a pro zlepseni musim studovat kod zkusenejsich.

[jas]

Ja by som to az tak cierne nevidel, samozrejme sa clovek nenauci programovat v jazyku perfektne za dva dni, ale ak ma za sebou dostatok teorie, tak ho v podstate ziadna konstrukcia jazyka neprekvapi a pochopi ju takmer okamzite. Vysledok je, ze sa nauci v jazyku programovat celkom schopne velmi rychlo a obvzlast moznost prispievat novy kod do existujuceho projektu pre takeho cloveka zacina takmer okamzite (rychlo odkuka aka je pozadovana uroven projektu).

[little.owl]

Tak u jazyku stejne kategorie (C-like, lisp-like) nebude problem, pokud jeden z nich znate a nemusite pouzivat jine paradigma, pak ano, ale rozhodne to neni o 30 klicovych slovech.

[TM]

Pro první seznámení s programováním ale Java, C a C++ určitě nejsou ideální(řada lidí skončí hned na začátku). Oproti tomu znám řadu příkladů, kdy byl Pascal relativně nenáročnou vstupenkou a přechod na C pak nedělal problémy. Končím. Ta debata nikam nevede.

[JS1]

Tak Pascal byl jeden z prvnich jazyku, ktery jsem se ucil (po ZX BASICu a Z80 assembleru). Ale zpetne to povazuji spis za ukrok stranou - udelal bych lepe, kdybych se ucil rovnou C.

Ja jsem vuci koncepci "jazyku pro vyuku" dost skepticky. Hodi se to pro deti, kterym je tak max. 14, ale od toho veku nevidim duvod pouzivat specialni "vyukove" jazyky.

[Miloslav Ponkrác]

Vy to bohužel ale už neposoudíte. Získal jste benefit z Pascalu, a nejste schopen zjistit jaké by to bylo, kdybyste vzal jen C.

[JS1]

Zadny benefit z Pascalu nebyl. Naopak, pristup C k polim je v jistem smysl genialni, a myslim, ze byla skoda, ze jsem ho neznal driv. (Protoze jsem, v te dobe mylne, povazoval C jen za Pascal s mene citelnou syntaxi.) Celkove byl Pascal slepa kolej - kdybych se ucil C, asi bych se i k Linuxu dostal o par let driv.

[Miloslav Ponkrác]

Benefit není o syntaxi. Benefit je v tom, že Pascal udělá ve večech v hlavě pořádek.

C se naopak tváří, že celý svět je jedna velká emulace nad pointery.

Každé řešení má něco do sebe, jak skutečné pole, tak i C řešení, které pole vůbec nemá, ale emuluje jakous takous náhradu polí pomocí pointerové aritmetiky.

Zvláštní, já se dostal k unixu v době (80. léta), kdy jsem C neuměl. Uměl jsem sice asi 8 jiných programovacích jazyků, ale C k nim tehdy nepatřilo. A nijak mi to v poznávání a chápaní unixu nevadilo. Nerozumím proto, jak Ván neznalost C zamezila přístupu k linuxu.

[Michal Kubeček]

Já si hned říkal, že to nebude tak horké…

dnes 17:15 Miloslav Ponkrác

Tato debata opravdu nikam nevede. Končím.

[JS1]

Nerozumím proto, jak Ván neznalost C zamezila přístupu k linuxu.

Presne! Prave proto, ze neznate moji osobni historii, nemuzete vynaset soudy nad tim, co mi Pascal dal ci nedal.

Do VS jsem byl s prostredim DOS/Pascal celkem spokojeny. Byl to az nastup Windows 95, ktery me donutil hledat jinou, otevrenejsi platformu (Linux). Ale jsem si temer jisty, ze kdybych umel C driv, dostal bych se i k Linuxu driv - ta moznost v mem okoli existovala.

Nevim, v cem by mel v te dobe Pascal "udelat v me hlave poradek". Uz predtim jsem znal dost slusne assembler (jak Z80 tak x86), a Pascal jsem pouzival v podstate jen proto, ze byl vysokourovnovy (a mel graficke knihovny, atd.). Stejne dobre by dnes poslouzil Python (skoda, ze jsem nic takoveho tehdy nemel!).

[Miloslav Ponkrác]

Ok. O tom, co udělal Pascal u Vás víte jen Vy sám. Přehnal jsem to, když jsem něco o tom tvrdil. Omlouvám se.

Nicméně opravdu pořád nechápu, jak Vám neznalost C bránila k přístupu k linuxu. Když jak píšete ta možnost tu existovala.

Znám spoustu lidí používající linux a o C nemají ani páru.

[JS1]

Myslel jsem, ze uz jsem to napsal - slo predevsim o "kulturni" barieru mezi DOS/Pascal a Linux/C. Pocitace tehdy pro me byly predevsim platformou pro programovani (a samozrejme hrani, ale to Linuxu nebranilo). Srovnani s dneskem opravdu kulha, protoze je opravdu trochu rozdil Linux (a PC) dnes a pred 20 lety.

[Miloslav Ponkrác]

Já tu dobu zažil a rád na ní vzpomínám. Protože před 20 lety jsem lítal mezi VAX/C, DOS/C a DOS/C++ a DOS/Simula a EC1027/Fortran plus Smalltalk (ten obsahoval vlastní os, takže se bootoval rovnou jako samotný os).

Linux před 20 lety si pamatuji. Bylo to pro mě obrovské zklamání. (Jiné unixy byly učesané, přehledné, zdokumentované.) Nic nefungovalo, každý krok znamenal měsíc studia rozsáhlých anglických manuálů (a to unix jsem dobře znal). Všechno se dělalo strašně low level. Nakonec jsem rozchodil skoro vše. Po několika měsících linuxu jsem dostal od ženy nůž na krk, buť linux nebo ona. Pochopil jsem, že linux není ještě zralý v té době na běžné použití. A přeinstaloval na Windows 95, kde vše chodilo okamžitě a dalo se pracovat.

Dnes už je linux daleko zralejší na použití bez nutnosti rozvodu.

Jinak já jsem C opustil, prestože jsem v něm programoval asi 15 let, dnes už ho považuji za zastaralý a překonaný, a nenabízející žádný benefit, který by ospravedlňoval nové projekty v něm.

[Miloslav Ponkrác]

Souhlasím.

V zásadě vidím kolem sebe, jak dopadají různé vstupní jazyky. Druhé nejlepší výsledky vidím u lidí, kteří do programování vstoupili přes Pascal.

Lidé začínající s C/C++ měli vysokou úmrtnost, protože C je neučilo, C je trestalo s příliš vysokou vstupní laťkou.

Stejně tak nevidím ani dobré výsledky u lidí s Pythonem na začátku. Ten jazyk je nic nenauší, byť je jednoduchý a zábavný.

Nejhorší výsledky vidím u lidí pokoušející se začít Javou, následky se napravují ještě řadu let poté.

Nejlepší výsledky vidím u lidí začínající na LISP či Scheme.

---

Tato debata opravdu nikam nevede. Končím.

[Agent]

Lidé začínající s C/C++ měli vysokou úmrtnost, protože C je neučilo, C je trestalo s příliš vysokou vstupní laťkou.

Jinými slovy byli líní...

[j]

Programator se nema ucit jazyk, programator se ma ucit programovat. A pro ten ucel je nejlepsi to, co mu co mozna nejmin praci ulehcuje, protoze jinak nikdy nepochopi, co vlastne dela a proc to dela. Jakmile se nekde neco deje samo ... tak to je pruser, protoze si pak dotycny mysli, ze se to samo dela vzdy a vsude.

[pta]

Uplne bych ObjectPascal na vyuku nezatracoval. Algoritmizace i principy OOP se daji na tom naucit stejne dobre a navic ma vyhodu oproti Pythonu ve staticke analyze a typove kontrole kodu prekladacem. To muze hodne pomahat zacatecnikum, bez nutnosti psat ke kazdemu programu jeste jednotkove testy, ktere navic nejsou 100% spolehlive.

Daleko podstatnejsi je naucit se snadno algoritimizovat problem a nasledne prevest do implementace. Volba jazyka je druhotna a od urcite urovne je uplne jedno v cem to pisete. V praxi je pak daleko dulezitejsi znalost knihoven a prostredi.

S ohledem na vyvoj smerem k paralelnimu a distribuovanemu zpracovani uloh bych spis uvital posun smerem k funkcionalnimu paradigmatu, pro ktere je zrovna Python nevhodny. Vim o univerzite, kde byl jako vyukovy jazyk Scheme a ve vyssich rocnicich computer science vladnul Haskell a o absolventy se tam velke firmy a banky perou. Je jen otazka casu, kdy se presune poptavka i do jinych odvetvi. Python, Ruby, Perl nebo C++ uz maji obdobi slavy zrejme za sebou.

[Bystroushaak]

Uplne bych ObjectPascal na vyuku nezatracoval. Algoritmizace i principy OOP se daji na tom naucit stejne dobre a navic ma vyhodu oproti Pythonu ve staticke analyze a typove kontrole kodu prekladacem. To muze hodne pomahat zacatecnikum, bez nutnosti psat ke kazdemu programu jeste jednotkove testy, ktere navic nejsou 100% spolehlive.

Má ale jednu nevýhodu - je k ničemu. Až potom absolvent ze školy odejde, může se celý zbytek života věnovat jeho zapomínání, protože je to asi stejné jako naučit programátora místo angličtiny latinu.

Daleko podstatnejsi je naucit se snadno algoritimizovat problem a nasledne prevest do implementace. Volba jazyka je druhotna a od urcite urovne je uplne jedno v cem to pisete. V praxi je pak daleko dulezitejsi znalost knihoven a prostredi.

Souhlas.

S ohledem na vyvoj smerem k paralelnimu a distribuovanemu zpracovani uloh bych spis uvital posun smerem k funkcionalnimu paradigmatu, pro ktere je zrovna Python nevhodny.

To je imho blbost. Python je funkcionální docela dost, ale nebere to jako náboženství.

Vim o univerzite, kde byl jako vyukovy jazyk Scheme a ve vyssich rocnicich computer science vladnul Haskell a o absolventy se tam velke firmy a banky perou. Je jen otazka casu, kdy se presune poptavka i do jinych odvetvi. Python, Ruby, Perl nebo C++ uz maji obdobi slavy zrejme za sebou.

Tak jedna z těhle univerzit je například MIT. Osobně bych určitě komukoliv kdo se chce programováním zabývat naordinoval nějaký lisp, protože to je jak kdyby se člověku otevřelo třetí oko.

[Miloslav Ponkrác]

Já bych naopak ObjectPascal zatradil až na dno pekel. Pro praxi se skřípěním zuby, pro použití na výuku je to na zastřelení profesora pro výstrahu, který ho dává studentům. Neexistuje hůře vyřešený jazyk. A neexistuje horší implementace OOP, než se podařila Borlandu v jeho ObjectPascalu.

ObjectPascal není Pascal. Je to jazyk odvozený od Pascalu, některé věci Pascalu mu chybí, mnoho jich přibývá.

S čím ale souhlasím je, že jazyk je druhotný. Výuka programování by měla probíhat na teoretické bázi, kde programovací jazyk je jen druhá část procesu výuky.

Programovat NĚJAK bez teorie se naučí v programovacím jazyce i cvičená opice, protože něco naprgat není žádné velké umění. Pak se takový člověk mylně domnívá, že je programátor, protože je schopen něco malého vytvořit v programovacím jazyce X. A pokud je hodně nesoudný, pak si dokonce myslí, že něco v programování umí.

Výuka programování není o programovacím jazyce. Je to o zvládnutí teorie a získání dobrých návyků. Kdo je skutečný programátor, se několik nových jazyků naučí velmi snadno, protože programovací jazyky jsou velmi jednoduchoučké.

Kdo má starost o to, aby se naučil jediný programovací jazyk, který bude používat v praxi – není programátor. Jeho schopnosti končí velmi nízko a nic neumí. Nicméně pokud se bude držet toho nic neprogramovat a vše slepit s knihoven, pak jako glue programátor bude mít i slušné místo. Ale nic nebude umět.

[jos]

Dá se v něm rychle a snadno v případě potřeby něco naprasit

jasně, podle sebe soudim tebe a v jinejch jazycích rozhodně prasit nejde, *facepalm*

[Anino]

Python učíme u nás na gympli. Ak by bol záujem, tak tu je knižka (po slovensky): http://www.smnd.sk/anino/moje/Python.pdf plus nejaké súbory: http://www.smnd.sk/anino/moje/PythonFiles.zip Je to písané pre Python 3, dnes by som možno viac zvažoval, či to predsa len nepísať pre 2.7

[egg]

Díky moc, taky učím Python na SŠ a jsem vděčný za materiály v cs/sk. Zvlášť pro py3 je jich málo. Btw proč by 2 měla být pro základní kurs lepší?

[frantisekz]

Taky díky za link ;)

[PetrHL]

Děkuji za odkaz, už jsem se začetl. Občas něco musím v programu, který je napsaný v Pythonu, opravit, ale jsou to jen drobnosti. Vámi napsaná kniha je super srozumitelná, zkusím s Pythonem i trochu více.

Píšu už více jak 10 let v Object Pascalu (Delphi, Lazarus, FPC) a zatím mi stačil na všechno. Doma v Linuxu používám Lazarus, v práci Delphi XE. Napsal si pro sebe X řádkových utilit a pár programů i s GUI (ten největší má kolem 70k řádků zdrojáku a 81 oken).

Trochu se sem stydím napsat, když neumím 8 jazyků ale asi jen dva ...

[Venda]

rekl bych ze vyuka cehokoliv se musi vzdy orientovat na lokalnich okolnostech a budoucich potrebach. (prumyslu, vedy).

V nasich koncinach a s nasi mentalitou je rozumne reseni se orientovat podle jakesi 'nejistoty' ve spolecnosti. Nase tisicileta historie, ktera byla po vetsinu case nejaka poroba a nesamostatnost nas naucila uhybat ranam a se vsim tak nejak vyjebat. Pozitivne vyjadreno je to urcita flexibilita jak v mysleni tak v charakterove oblasti. To je take nase velka vyhoda, dokazeme vyborne improvizovat.

V oblasti programovani tomu odpovida Perl. A proto by bylo zahodno, aby se jiz na zakladni ci nejpozdeji stredni skole zacalo s timto jazykem. Kazdy, kdo v tom jazyku programoval si dovede predstavit, ze kdyby se zadala v nejake trida jedna uloha, tak kazdy z zaku by odevzdal uplne jiny program. (a vzajemne by meli velky problem pochopit reseni souseda). Trenovat v takovem prostredi je pro nasi (stredoevropskou) budoucnost vec zasadniho vyznamu. Miliardy koderu v nejakych strukturovanych jazycich bude naizet vychodni Asie uz za par let. My musime umet improvizovat.

[Miloslav Ponkrác]

„… vyuka cehokoliv se musi vzdy orientovat na lokalnich okolnostech a budoucich potrebach. (prumyslu, vedy).“

Problém je v nedostatku těch křišťálových koulí se zjišťováním budoucích potřeb.

„V oblasti programovani tomu odpovida Perl.“

Slyšel jsem, že Chuck Norris dokáže psát přehledné a udržovatelné programy v Perlu.

[JS1]

Dad se vratil?

[Seraph]

Když za milion počítačů dáš milion opic. Jedna opice bude programovat v Javě, zbytek v perlu.

[Bedňa]

Ja by som dal ako prvý jazyk U++ Je to C++ a netreba sa jebať s pointrami Taká Java, ale 100rýchlejšia. Gambas je tiež veľmi easy, trochu upraviť parser aby to vyzeralo ako C# a je na Linuxe platforma k nezaplateniu. Konvertor audia, videa som v tom napísal za večer, neviem či by som to dokázal v niečom inom. Len syntax... proste Basic, ale zas ten kompilátor je moc krát rýchlejší ako hocičo čo som videl.

[jehovista]

Taká Java, ale 100rýchlejšia.

dal jsem necetl

[Bedňa]

Keď zoberiem otvorené implementácie Javy, tak som to ani neprehnal. Pokiaľ zoberieme tie od Oracle, to je iná, ale zas tie licenčné pasce no a naposledy sa mi aj NetBeans s nimi sypal.

[deda.jabko]

Keď zoberiem otvorené implementácie Javy, tak som to ani neprehnal. Pokiaľ zoberieme tie od Oracle, to je iná

Tohle nedava uplne smysl. Referencni implementace Javy (OpenJDK) je otevrena a Oracle Java je od oka tak z 99% postavena na OpenJDK.

[Jendа]

Konvertor audia, videa som v tom napísal za večer, neviem či by som to dokázal v niečom inom.

Takové to pythoní Qt, dobrá ukázka je brmbar3.

[Bedňa]

Takové to pythoní Qt

Python s nejakým widgets a nemusí to byť zrovna QT mi príde vysoko použiteľné, aj ako nepythonista si to dokážem upraviť. Osobne používam LinuxCNC, PyCAM a určite som na niečo zabudol. Osobne mi to príde easy, napr. oproti Jave & niečo.

[Seraph]

Python se mi osobně nelíbí. Přijde mi skutečně nepohodlný a nekonzistentní (True, False, and, or ...). Dynamické typování je zlo. Taktéž není schopen zapouzdřovat datové členy a metody v třídách (takže není plně objektový). V metodách je nutno neustále psát před členy třídy self nebo this (podle toho jak si to pojmenujeme...). Je pomalí až to bolí (což ale na výuku nemá dopad). Obsahuje GC, což je ale nástroj původně vytvořen pro čistě funkcionální jazyky. GC v OO jazyku účinně pohřbívá výhody objektového systému (management paměti bez vynaložení výkonu navíc). Z toho vyplývá že tvůrce Pythonu buď nepochopil objektový systém a nebo počítal s tím že Python budou používat ... kteří nepochopili objektový systém.

Ideální první jazyk je z mého pohledu Haskell. To, že ho plno lidí nezvládá není proto že by to byly takový idioti. Nemají pouze flexibilní mysl. Nejsou schopni se odpoutat od imperativního paradigmatu. Oblíbenost GC je důkazem oblíbenosti vysoké úrovně abstrakce. Přesně to nabízí funkcionální jazyky. Programovat imperativně vlastně není vůbec třeba, pokud teda zrovna neděláte kernel a nebo nějaký driver (či runtime pro funkcionální jazyk :)). Imperativní paradigma je co se týče abstrakce velice nízko a nepodporuje optimalizace vyšších úrovní (call by need, call by future).

Pokud by první učený jazyk byl Haskell (či jiný čistě funkcionální jazyk), odpadla by fixace na imperativní paradigma a tím pádem by nečinilo problém zvládnout funkcionální paradigma které bude v budoucnu klíčové.

[little.owl]

Pokud by první učený jazyk byl Haskell (či jiný čistě funkcionální jazyk), odpadla by fixace na imperativní paradigma a tím pádem by nečinilo problém zvládnout funkcionální paradigma které bude v budoucnu klíčové.

Roky se ucil na univerzitach Lisp a jeho derivaty, a predpokladany efekt to nemelo. O superiorite funkcionalnich jazyku se blaboli roky a kde nic tu nic. Mozna proto ze pod kapotou mame stale von Neumannovskou architekturu a na brzkou zmenu to nevypada.

[Seraph]

Architektura může za pomalost funkcionálních jazyků. Poslední dobou se to ale zlepšuje (s rostoucím počtem jader).

[little.owl]

Nezlepsuje, porad se modifikujete stav. Typickou ukazkou je Twitter, kde presli z Ruby na Scala, aby nakonec zkoncili u reimplementace parallelnich casti systemu v Jave (treba zde). Zatim jsem nevidel v praxi zadny vyrazny benefit funkcionalniho programovani a parallelismus vice jadrovych systemu lze resit i u imperativnich jazyku vhodnou architekturou.

[pta]

Sorry ale nepodarilo se mi v odkazovanem materialu najit, kde a proc nahradili Scalu Javou.

AFAIK cast frontendu je porad v Ruby. Asi stoji za pripomenuti, ze v dobe kdy opustili Ruby tak bezeli na verzi 1.8.x a od te doby prosel VM i GC zasadnima zmenama smerem ke skalovatelnosti (YARV a generacni RGenGC). Nemluve o JRuby. Kod primo ve Scale nebo Jave je ale obecne rychlejsi, o tom zadna.

[little.owl]

Je to i ve zminenem odkazu, prectete si sekci "Concerns with Scala", kde zacali nahrazovat actor based architekturu, tedy zakladni prvek Scala parallelismu (scala.actors), tradicnim Java thread modelem s explicitni udrzbou threadu. Podle jinych clanku/vyjadreni prepsali jen casti, kde byl bottleneck.

Pobavil me ten scenar, ktery jsem jiz nekolikrat videl: Ruby, super, oh, hmm, ... OK, JVM, ale Scala/Clojure/etc. ... well, hmm, OK, tak tedy, nic se neda delat, mame JVM, importujem java.util.concurrent, a tohle prepisem v Jave. A vysledkem je hybrid.

[pta]

Aha, ale oni nereimplementoval parallelni casti v Jave ale jen misto actoru jako abstrakce nad java threads je zacali pouzivat primo, ale porad v ramci Scaly.

[little.owl]

Ale prd, actor model je mnohem vice nez thread. Pointa je v tom, ze kdyz zacali mit problemy s parallelnim kodem, splachli actors, immutable objects s pure functions a celou tuhle funkcionalni nadheru, a misto toho naimportovali primo javovske thready a parallelni struktury a udelali to osklive imperativne se sdilenymi daty a locky.

[JS1]

To je zajimava perspektiva. Mne se Haskell hodne libi, ale myslim, ze to nekdo dobre popsal na HackerNews, kdyz napsal, ze se u Haskellu musi na zacatku dost premyslet, jak definovat typy v programu. Jinak si clovek dost nabehne (asi nejlepsi priklad je v samotnem Prelude - Monad neni instance Applicative).

A to je prave to, kde Python (a Lisp!) vitezi. V situacich, kdy se teprve zkouma prostor reseni. Mne by se libil funkcionalni lazy jazyk s dynamickymi typy, dokazu si to celkem predstavit. To by mohla byt zajimava vec.

Taky moc nechapu, proc ti vadi "self", kdyz v Haskellu musis v podstate psat to same?

[Seraph]

Protože self není nutné psát, může to za tebe doplnit jazyk (jako v C++). Lisp není čistě funkcionální jazyk a tím pádem nemá výhody které sebou nese čistota. Funkcionální jazyk která je dynamicky typovaný je třeba Erlang (ale není čistý a je o mnoho pomalejší než Haskell -> právě díky typové dynamičnosti).

Funkcionální jazyky se více nerozšířili protože v nich nikdo neumí dělat (díky prvně učenému imperativnímu paradigmatu).

Monády jsou vylepšené applicative. Důvod proč všechny monády nemají garantováno že jsou applicative je ten že monády byly vymyšleny dříve než applicative. Standardně ale lze předpokládat že monáda je zároveň applicative a funktor.

[little.owl]

Funkcionální jazyky se více nerozšířili protože v nich nikdo neumí dělat (díky prvně učenému imperativnímu paradigmatu).

To je blabol, lide se uci. Ve skutecnosti je to jinak - ciste funkcionalni programovani nema v soucasnosti zasadni prakticke vyhody a kecy teoretiku nechme stranou.

[pta]

To je blabol, lide se uci. Ve skutecnosti je to jinak - ciste funkcionalni programovani nema v soucasnosti zasadni prakticke vyhody a kecy teoretiku nechme stranou.

To je blabol, funkcionalni programovani ma prakticke vyhody a kecy little.owla nechme stranou. Jen to neni nastroj delniku jako Java, C# nebo C ale inteligence.

funkcionalni ≠ ciste funkcionalni, prakticke ≠ zasadni prakticke

[little.owl]

Jen to neni nastroj delniku jako Java, C# nebo C ale inteligence.

Vyborne, a ted zavedeme tridni boj i do programovacich jazyku .

Ja nemam nic proti funkcionalnim jazykum, jen si nemyslim ze je to panacea.

[pta]

jen si nemyslim ze je to panacea

V tom souhlas a snad jsem to nikde ani netvrdil.

[little.owl]

Vy ne, ale Seraph, soude podle jeho prispevku, uz k tomu nema daleko.

[Michal Kubeček]

To už je ale trochu stará finta: prohlásit něco za "jen pro inteligentní", aby se nikdo neodvážil to kritizovat ze strachu, že bude vypadat jako blbec. Ale co, používá se to u knih, u filmů, u hudby, … tak proč ne u programovacích jazyků.

[pavlix]

To už je ale trochu stará finta: prohlásit něco za "jen pro inteligentní", aby se nikdo neodvážil to kritizovat ze strachu, že bude vypadat jako blbec.

To mi připomíná jednu pohádku.

[JS1]

V Haskellu ale self psat musis (nebo prinejmensim, musis napsat typovou signaturu). Proc by ti to tedy zrovna u Pythonu melo vadit?

Dokazu si predstavit dynamicky typovany jazyk, ktery je stejne rychly jako staticky typovany. Myslim, ze vyvoj jeste nerekl posledni slovo.

Důvod proč všechny monády nemají garantováno že jsou applicative je ten že monády byly vymyšleny dříve než applicative.

Ano, a to prave dobre vystihuje problem statickych typovych systemu. Pokud se neco takoveho stane, je problem to zmenit. Jelikoz ma Haskell striktnejsi typovy system nez jine jazyky, trpi timto problemem jeste vice.

Abstrakce Haskellu jsou fajn. Je pekne, ze tomu programovani dava matematicky zaklad. Urcite to otevira cestu spouste novych optimalizaci. Ale budoucnost primo v tom nevidim. Myslim, ze to nakonec skonci pod kapotou - bude se dal programovat "imperativne" (i kdyz na vysi urovni), a kompilator si to prebere, to co zvladne zfunkcionalizovat, zfunkcionalizuje.

O tomhle mluvi treba Erik Meijer. Ma to i realne vysledky - treba LINQ v .NET jsou ve skutecnosti monady, ale nerika se tomu tak.

[pta]

kdyz napsal, ze se u Haskellu musi na zacatku dost premyslet, jak definovat typy v programu

To je mozna problem uplnych zacatecniku, kteri se snazi priohnout svuj styl mysleni nauceny z dynamickych imperativnich jazyku. Navic je neni potreba vetsinou ani deklarovat diky typove inferenci.
Barierou jsou vyssi naroky na komplexnejsi analyzu ulohy pred tim nez se zapise algoritmicky. U imperativnich jazyku usnadnuje programovani inkrementalni pristup, dekompozice na mensi casti. Coz ale muze vest k mnoha ruznym i suboptimalnim resenim.
Nesouhlasim teda s predrecnikem, ze je to jen o odpoutani od imperativniho paradigmatu. Efektivne programovat v ciste funkcionalnich jazyzich je obecne narocnejsi na IQ a nezvladne v nem psat cvicena opice i kdyz tomu venuje hodne casu.

[little.owl]

To je mozna problem uplnych zacatecniku, kteri se snazi priohnout svuj styl mysleni nauceny z dynamickych imperativnich jazyku.

Jiste, nad type classes neni treba vubec premyslet - a pritom tomu samotni haskelliste venuji cele state.

U imperativnich jazyku usnadnuje programovani inkrementalni pristup, dekompozice na mensi casti.

A funkcionalnich jazyku dekompozice a inkrementalni pristup nepomaha?

Efektivne programovat v ciste funkcionalnich jazyzich je obecne narocnejsi na IQ

Zajimave. A mate to podlozeno jak?

[JS1]

Efektivne programovat v ciste funkcionalnich jazyzich je obecne narocnejsi na IQ

Hm, v cem je tedy pak jejich vyhoda, krome masochismu?

Takhle, nic proti, ja mam rad dobry hlavolam. Ale kdyz chces resit prakticky problem? Neni to spis na prekazku, kdyz je ten jazyk narocnejsi?

[pta]

Vyhodu spatruju v tom, ze pokud prekrocis urcitou hranici pak se ti budou obtizne ulohy resit snadneji nez v imperativnim jazyku a budou robustnejsi. Je zbytecne se tady o tom rozepisovat, o Haskellu jsou na netu kvanta informaci i obecne formulace o jeho vyhodach. Podstatne je ale vlastni zkusenost a nakodit aspon par stredne velkych projektu. Ja to udelal a musel se sklonit nad genialitou typoveho systemu i kvalitou svobodne implementace GHC.

[JS1]

Bohuzel, zrovna o tomhle jsem moc informaci nenasel. Nekdo doporucoval tuhle serii, ale i tak mi prislo, ze programuje v podstate dost imperativne.

Rad bych v tom videl nejaky vetsi projekt (ktery neni ciste matematicky, neco realneho), ktery ma smysl si precist (a pouziva efektivne treba RWS monad tower nebo neco podobneho).

Ja vidim nektere vyhody, ale ten typovy system povazuji spis za prekazku. I kdyz jako matematicka teorie se mi to libi.

[pta]

Na Hackage je spousta realnych ne-ciste-matematickych projektu.

[JS1]

Nepochybne. Ale jak mam vedet, ktery stoji za precteni?

[little.owl]

Tedy jestli tohle ma byt vykladni skrin Haskellu, pak je to bida. Dve tretiny jsou zoufalosti jako tohle, a toho vyssi inteligence tedy moc nekouka.

Ach ty svinske IO ... .

[pta]

Dve tretiny jsou zoufalosti jako tohle

Psst, nemusis na sebe tolik upozornovat ze tomu vubec nerozumis
Na tu analyzu 2/3 projektu bych se ale rad podival. Das sem link ?

[little.owl]

Psst, nemusis na sebe tolik upozornovat ze tomu vubec nerozumis

Ja chapu, ze my delnici, na vas, pracujici inteligenci, proste nemame.

Na tu analyzu 2/3 projektu bych se ale rad podival. Das sem link ?

Stacilo mi nahodne samplovat cca 15 projektu - a je to stejne jako u vetsiny techto repositaru - casto spise sbirka polofunkcniho poloudrzovaneho semestralniho/diplomkoveho srotu po par lekcich, ktery se kumuloval roky. Pokud mate pocit, ze tomu tak neni, ukazte mi par [desitek] pilotnich vzorovych nematematickych projektu. Navic, pokud mozno nejakou knihu se vzorovymi Haskell design patterns a pristup k reseni fundamentalnich problemu spojenych s time/space costs u lazy FP.

[pta]

Hmm, ty tady neco nepodlozene tvrdis a kdyz te vyzvu abys to nejak dokazal tak to prevratis a dukazy mam davat ja ? To je smesne.

[little.owl]

Silna tvrzeni jste predevsim uvadel vy.

Samplovani je ve statistice regulerni cesta k analyze dat.

[pta]

Samplovani je ve statistice regulerni cesta k analyze dat

Zacinas me bavit. Jak ten vyber probehl ? Jaka byla hladina vyznamnosti ? Pocet opakovani (nula?) ? Tohle je neseriozni tvrdit nasamploval jsem 15 vzorku a vyslo mi tohle - bez relevantniho podkladu.

[:::]

Co je na tom neseriozniho?

Dejme tomu ze mnozina je dost velka abych nemusel resit 's opakovanim' vs 'bez opakovani'.

Nahodne vyberu 15 prvku z mnoziny a divam se jestli maji urcitou vlastnost.

% prvku ktere maji vlastnost | pravdepodobnost ze ani jeden nevytahnu
---------------------------------------------------------------------
                          50 | 0.5 ^ 15 = 0.003 %
                          20 | 0.8 ^ 15 = 3.5 %
                          10 | 0.9 ^ 15 = 21 %
                           5 | 0.95 ^ 15 = 46 %

Takze ze vzorku 15 muzes rict ze pravdepodobne (> 50%), 95% projektu nema danou vlastnost

[pta]

Kdyz ses toho ujal, muzes prosim doplnit kriteria podle kterych se ohodnotila shoda/podobnost vybranych vzorku podle, cituji
mpvguihs
dikes

[little.owl]

Vy jste nam tu daval lekce o vyssim IQ programatoru, o vyssi robustnosti Haskell programu a jako odkaz nam predhodil zminenou repository. Par projektu, ktere jsem otevrel a podival se do kodu mne nepresvedcilo, stejne mizerny kod jsem psal sam po precteni jedne knihy (Real Word Haskell) a vice casu tomu venovat neminim, a to jestli to byl reprezentativni vzorek ci nikoliv, je vedlejsi. Stejne jako JS1 bych ale rad videl nejaky vzorovy nematematicky projekt, kde by se clovek mohl ucit.

[pta]

Shrnme to, ze jsi tu placnul blabol vycucany z prstu. Dik za spolupraci.

Skoda ze vic nepochoplapila extremni lama. Jeho nastrel zacal vypadat hodne vyzivne. Smich pry prodluzuje zivot

[Marvin]

Prijde me celkem usmevne jak si nekteri haskelaci namlouvaji ze jsou chytrejsi nez vsichni ostatni.

Navic kdyz v diskuzi od nich nezazni jediny argument a jenom se snazi urazet ostatni... :-/

[pta]

Hackage is the Haskell community's central package archive.
Rad bych pridal do "vykladni skrine" nektere komercni projekty, ale asi bych si sel sednout do chladku neb na na nahradu skody v mil. € fakt nemam Zkus kontaktovat Galois, treba ti vyhovi

[siam]

Je mi to trapné, avšak z přečtené diskuze mi zatím vypadlo vychvalování se Haskellistou a ne source, kterým by dokázal, proč je to jeho vlastně lepší. Tímto vede little.owl a pokud se mají věci nějak měnit, tak prostě dojde na "31 - TITS or GTFO".
Vůbec - pod každým článkem s jazyky vidím vychvalování Haskellu a Erlangu, avšak nikde nevidím příklady nasazení mimo akademickou sféru (takže motivace pro další studium), ne-li dokonce ve státních institucích. Když teď konečně vylezly první prdy, tak je vidět, že co se bordelu v kódu týče, to taková změna oproti známým, široce užívaným případům (deriváty C, Ruby) zase není. Jo a nesmím zapomenout na výrazivo, které je díky snaze se odlišit "yntelygencí" pro průměrného čtenáře naprosto nepoživatelné. Ne každý, kdo maká, má čas sedět v NTK v Dejvicích, kde je až nahoře v nejvyšším patře v koutě zašito oddělení s obecnou programátorskou literaturou, kde by ta vysvětlení dohledal.

[JS1]

Haskell urcite potencial ma, pokud se pise ciste (male IO jadro a funkcionalne pure zbytek) - sice ho sam moc neumim, ale dokazu si predstavit, ze z hlediska unit testu, modularity a take expresivity je to genialni (viz).

Ja si myslim, ze dobra analogie funkci a programu v Haskellu je "vojensky tabor/zakladna". Vsechen material, co leze dovnitr a ven z funkce, musi projit "hlavni branou", kterou je jeji typova signatura . Ale dal je to na vas. Muzete klidne uvnitr te funkce poradat divokou, imperativni party s monadami. Ale vyplyva z toho, ze se o tom bude vedet (ne zcela - muzete taky pasovat pres to unsafePerformIO, ale to se nema delat). To je sila a zaroven slabina. Mne, jakozto pacifistickemu anarchistovi, to pripada jako zbytecny opruz a byrokracie. Ale dokazu si predstavit, ze u velkeho programu ten fakt, ze presne vite, co se uvnitr funkce muze stat, jenom na zaklade typove signatury, muze mit velkou vyhodu.

[little.owl]

Haskell ma sve kouzlo, zejmena typovy system, i kdyz je to jazyk pro extremisty. Limitujici mi prijde sprava zdroju, veci jako space leaks, prece jenom bych mel rad jistotu, ze se to nezhrouti treva kvuli nedostatku pameti az to dostane jina data.

[siam]

Já si docela dokážu představit, jak v praktickém světě bouchne - mašina neexistuje ve vzduchoprázdnu a program prostě musí komunikovat se svým okolím, takže to velmi uzavřené paradigma vždy shoří právě na IO, obzvlášť, když přilétne něco nečekaného.
Vezměme si třeba pitomost jako tvorba mailu. Některé věci to obsahovat musí (from), jiné ne (cc, bcc). Nebo úloha, kde je potřeba jednotlivé části zpracovávat v daném pořadí (tedy pravděpodobně nejlépe imperativně) a přitom na jiné úrovni by se paralelní zpracování uživilo.

[JS1]

Napriklad klasicky problem, ktery jsem zminoval uz na HN:

Mam dva moduly, jeden - modul A - neco pocita pro ten druhy - modul B. Muzu tedy ten A napsat ciste "ciste", a vsechno IO dat do B.

Ale ted, prijde pozadavek, ze modul A potrebuje nacist nejaky dodatecny parametr z konfigurace (ktery mohl byt predtim jako konstanta). Najednou stojim pred divokym refaktoringem nejenom A, ale i B: Musim vsechno to IO, co chci dostat do A, protahnout pres IO monadu v B.

V tomhle smeru je Haskell na muj vkus prilis explicitni - prilis vyplouvaji na povrch rozvody (kam privest IO, osetrovani chyb, atd.), ktere by v jinych jazycich (objektovych) mohly klidne zustat skryte. Proto si myslim, ze Haskell neni posledni slovo - nakonec to nejak vyresi zatim nejaky neexistujici funkcionalni jazyk, kde bude mozne rict - protahni mi tuhle IO monadu skrz modul B, at se o to nemusim starat. (Podobne problemy, ale bez matematicke teorie, se IMHO snazi resit dependency injection nebo AOP.)

[pta]

Na tohle je celkem jednoducha odpoved - obal funkci z A Reader monadou ktera implicitne preda parametry z IO kodu modulu B. Manualni refaktoring s explicitnim pridanim parametru neni treba. Taky lze samozrejme pouzit unsafePerformIO, ale to je v tomhle pripade zbytecny a silne to nedoporucuju.

[JS1]

Dik, zamyslim se nad tim. Ale takovehle veci jsou prave neco, o cem zadny rozumny tutorial neznam. Je to neco jako navrhovy vzor.

[pta]

S tutorialama to je tezky, pokud hledas od teorie k prikladum. "Learn You a Haskell for Great Good!" je sice lehce stravitelny ale konceptu se jen dotkne. "RealWorldHaskell" je v tomhle lepsi ale vyzaduje uz obecny prehled. Teoreticka baze je slusne popsana v Hudakove "Gentle Introduction To Haskell", i kdyz je pro predchozi standard Haskell98 ale vetsina plati i pro Haskell2010.
Asi nelze doporucit "nejrozumnejsi", kazdy ma zpusob uceni nastaveny trochu jinak. Kolegovi dal pry nejvic "Write Yourself a Scheme in 48 Hours in Haskell", ale ja se v tom ztracel.

[JS1]

Learn Yourself a Haskell jsem cetl. A pak "All About Monads". Real World Haskell zvazuji, i kdyz mi uplne nepripada, ze na tyhle problemy rozumne odpovida. (Pak jsem to tema trochu opustil, protoze jsem zacal cist knizku Homotopy Type Theory, ktere jsem v 2. kapitole prestal rozumet. )

Zkratka, zatim me nic nepresvedcilo, ze je Haskell, az na nektere pripady, skutecne tak moc efektivnejsi na programovani. Z Common Lispu jsem byl tedy rozhodne nadseny vic. Ale matematika je to (Haskell) pekna, o tom zadna.

U uloh, kde je jasne, jak v te domene definovat pojmy, jako treba matematickych problemu, si to dokazu i predstavit. Ale jakmile clovek musi trochu experimentovat s typy, nebo se zacne dotykat neostreho realneho sveta, jde ta efektivita dost dolu.

A ja myslim vidim zpusob, jak ten rozpor mezi statickym a dynamickym typovanim v budoucnosti vyresit - typovou detekci za behu a jejich ulozeni pro pozdejsi pouziti. To resi nevyhody obou stran - jak rapid prototyping, tak citelnost po letech. Zaroven by to nejspis skutecne realne zvysilo produktivitu programatoru. U fantazii s komplikovanymi statickymi typovymi systemy si tim fakt nejsem jisty.

[little.owl]

Take mi vice sedi z teto oblasti Lisp/Scheme/Closure.

[pta]

(Common) Lisp je taky genialni a diky multiparadigmaticnosti(.fuj.) je jednodussi v nem neco nahackovat, ale nemyslim ze je to z dlohodobejsiho hlediska vyhoda (modularita, udrzba, auditing). Navic ho trochu prizabila neexistence standardnich knihoven pokryvajicich obvykle problemy a Scheme tim trpi snad doted. Na to ze je tu s nami asi 50 let a jeho koncepty recykluji "moderni" jazyky o necem svedci

Nez teoretizovani o "idealnim" jazyku a implementaci je asi lepsi si nejdriv polozit otazku k cemu ho budu potrebovat. Pokud jde jen o konicek a rozsireni prehledu nebo jak zabit volny cas, pak je to prakticky jedno.

[little.owl]

Knihovny jsou u Lispu/Scheme tragedie, Clojure by na tom mohla byt lepe.

[pta]

Njn, bohuzel.

[deda.jabko]

Obsahuje GC, což je ale nástroj původně vytvořen pro čistě funkcionální jazyky.

A to ho nemohou pouzivat jine jazyky? GC ma treba i SmallTalk...

GC v OO jazyku účinně pohřbívá výhody objektového systému

Oblíbenost GC je důkazem oblíbenosti vysoké úrovně abstrakce.

GC je pouze nastroj a s urovni abstrakce nema nic spolecneho. Pokud chces, muzes mit GC i v C.

Imperativní paradigma je co se týče abstrakce velice nízko a nepodporuje optimalizace vyšších úrovní (call by need, call by future).

To, ze to soudobe imperativni jazyky nepodporuji, neznamena, ze to nejde v ramci celeho paradigmatu, jen proste o to neni vyraznejsi zajem.

[Seraph]

1) Až pochopíš objektové a funkcionální paradigma. Dáš mi za pravdu. 2) goto 1 3) Nejde to v rámci celého paradigmatu. Ale opět: goto 1

[deda.jabko]

Kdyz jsi mi to takto hezky vysvetlil, tak uz tomu rozumim.

[Seraph]

1) GC lze používat všude kde se vám zachce. Stejně tak rekurzivní datové struktury. Nebo pole. Ovšem, ne vždy je to dobrý nápad. Používat GC v imperativním jazyku je to samé jako používat pole ve funkcionálním jazyku, či rekurzivní datové struktury v imperativním jazyku. Lze to, ale má to dopad na rychlost nebo na čistotu paradigmatu (a na využitelnost daného "přeneseného" nástroje). Popřípadě na obojí. Imperativní nástroje patří prostě do imperativního paradigmatu. To samé s funkcionálními nástroji.

2) GC souvisí s úrovní abstrakce.

3) Implicitní call by need optimalizace je podmíněna referenční transparentností. Tu mají čistě funkcionální jazyky ale nikoli imperativní jazyky. Implicitní call by future vyžaduje taktéž referenční transparentnost. V opačném případě by z důvodu velkého množství zamykání paměti nebylo možno získat jakoukoli výhodu. Bohužel, z důvodu architektury kterou používáme není možné mít implicitní call by future optimalizaci (funkcionální programy jsou prostě moc paralelní na naše procesory). Takže je používána explicitní call by future.

[deda.jabko]

rekurzivní datové struktury v imperativním jazyku. Lze to, ale má to dopad na rychlost nebo na čistotu paradigmatu

Tomu nerozumim. V imperativnich jazycich pouzivam bezne rekurzivni datove struktury a na vykon nebo nejakou cistotu to vliv nema. Nebo se snazis rict, ze v imperativnich jazycich je prasarna pouzivat spojove seznamy, stromy, atd.?

GC souvisí s úrovní abstrakce.

Jak?

Implicitní call by need optimalizace je podmíněna referenční transparentností. Tu mají čistě funkcionální jazyky ale nikoli imperativní jazyky. Implicitní call by future vyžaduje taktéž referenční transparentnost.

To jen pouze v tom nejobecnejsim pripade. Referencni transparentnosti lze dosahnout i v imperativni jazycich.

Imperativní nástroje patří prostě do imperativního paradigmatu. To samé s funkcionálními nástroji.

Toto je hodne omezene videni sveta. Treba v takovem Lispu spojenim funcionalniho a imperativniho programovani lze dosahnout peknych vysledku, ktere by nebyly ani v jednom z techto svetu mozne.

Mimoto, vetsina main-streamovych (imperativnich/objektovych) jazyku prejima prvky z funkcionalniho sveta a take je to posun k lepsimu, zajimave...

[little.owl]

+1

[Bystroushaak]

Přijde mi skutečně nepohodlný a nekonzistentní (True, False, and, or ...).

Co jen na tom nekonzistentního?

[Seraph]

Tento výrok mi pomohl pochopit myšlenkové pochody člověka který to standardizoval. Děkuji.

[pavlix]

A odpověď?

[Bystroushaak]

Myšlenkové pochody šly imho cestou: Je to objekt, který je používán jako hodnota, tak tomu dám na začátek velké písmeno, zbytek jsou operátory, tak budou celé malé.

[little.owl]

Take mi prislo, ze si neuvedomuje ze True a False jsou objektove konstanty a pak je pristup konzistentni.

[mankind_boost]

-1

[JS1]

-1 se chova jako True, v cem je to nekonzistentni?

[Hans1024]

Jakozto UPOLak jsem "odchovany" na Scheme (ale pred vyskou jsem samozrejme zacinal na imperativnich jazycich). Je to muj nejoblibenejsi Lispovy dialekt. Mam ho tak rad, ze na nem ted stavim i svoji bakalarku. Myslim, ze na nektere problemy se Lispy, nebo obecne funkcionalni paradigma, skvele hodi.

Ale presto si myslim, ze na vetsinu problemu je lepsi zvolit neco klasickeho imperativniho a zpravidla se s tim pak da dosahnout (prave diky mensi abstrakci) mnohem lepsiho vykonu. A jak uz tady nekdo napsal, mnoho imperativnich jazyku uz prejalo ruzne funkcionalni prvky, takze tam, kde se to opravdu hodi, je mozne psat funkcionalne.

Taky si myslim ze vliv prvniho jazyka na kvalitu buduciho programatora se precenuje a za vyznamny argument pro Python tudiz povazuju jeho praktickou vyuzitelnost v pripade, ze se na skolu studentik po chvili vykasle.

[kralyk z abclinuxu]

Python jako první jazyk má výhodu v tom, že donutí uživatele pořádně odsazovat. Zejména na gymplu (ale bohužel někdy i později na VŠ) jsem viděl začátečníky, kteří na odsazování naprosto kašlali...

[little.owl]

To je predevsim vec editoru.

[Bystroushaak]

Já jsem to teda viděl i v eclipsech, netbeansech a visualstudiu.

[FrostyX]

To není. Už jsem viděl i případy, kdy člověk odenteroval, editor zvolil správné odsazení a on si tam pro jistotu přidal pár mezer navíc. Odsazování pomocí mezer celkově rád nemám, ale u začátečníků to bývá katastrofa, protože je často absolutně nezajímá, kolik tam těch mezer mají. Takže to imho není absolutně věc editoru, ale toho, jestli je člověk prase.

[Field]

No jestli je na Pythonu něco skutečně zpraseného, tak je to právě to odsazování. Jazyk sám o sobě fajn, ale určovat hloubku vnoření podle pozice prvního znaku na řádku je poněkud dementní a vede to k obtížně nalezitelým chybám, které tu asi většina lidí zná.

To už i ten MUMPS blahé paměti to měl udělané líp, kdy se hloubka vnoření označovala příslušným počtem teček na začátku řádku. Sice taky žádný zázrak, ale na první pohled bylo vidět, kde člověk je.

[Bystroushaak]

No jestli je na Pythonu něco skutečně zpraseného, tak je to právě to odsazování. Jazyk sám o sobě fajn, ale určovat hloubku vnoření podle pozice prvního znaku na řádku je poněkud dementní a vede to k obtížně nalezitelým chybám, které tu asi většina lidí zná.

Já si myslím, že kecáš voloviny. Za celých 7 let, co dělám v pythonu se mi tohle stalo v naprosto zanedbatelném počtu případů a chyba byla okamžitě nalezena. Python má svoje chyby, ale určení kódu odsazením mezi ně rozhodně nepatří. Prostě to není problém, ten v tom vidí jen lidi, co se rozhodli, že to pro ně problém bude a tak se mu radši vyhýbají.

[Field]

Brzdi, hochu. Že jsi se naučil žít a pracovat s něčím, co je trochu zprasené, to tě samozřejmě šlechtí, ale je to spíš doklad o tvé flexibilitě než o kvalitě jazyka. Navíc jsem nemluvil o tom, že by se to mělo stát tobě, ale zkus si poslepovat dohromady pár kusů kódu, na kterých spolupracovalo víc lidí.

BTW, programuju v různých systémech a jazycích skoro 30 let a troufám si říct, že o tomhle oboru něco málo vím. Pythonu se nevyhýbám, má spoustu fajn vlastností, ale některé věci Kvído prostě zkonil a není ostuda to přiznat.

[kralyk z abclinuxu]

Imho když na něčem dělá více lidí nebo se přijímají patche zvenku, chce to linty na styl. A to celkem bez ohledu na jazyk a velikost projektu...

[Bystroushaak]

Navíc jsem nemluvil o tom, že by se to mělo stát tobě, ale zkus si poslepovat dohromady pár kusů kódu, na kterých spolupracovalo víc lidí.

To dělám, dokonce je to součástí mojí práce. Nechci tě shazovat, je určitě možné, že jsi odborník na slovo vzatý, ale imho ne na python.

V pythonu se považuje za standard úprava kódu pomocí PEP8 a za sebe musím říct, že ačkoliv občas pracuji i s různými amatérskými projekty, které jsou rády že mají stránku na githubu a nestojí za nimi nikdo podstatný, tak většina lidí jí z velké většiny skutečně používá.

BTW, programuju v různých systémech a jazycích skoro 30 let a troufám si říct, že o tomhle oboru něco málo vím. Pythonu se nevyhýbám, má spoustu fajn vlastností, ale některé věci Kvído prostě zkonil a není ostuda to přiznat.

Většinu vlastností nezkonil zrovna on, probíhá to komunitním rozhodováním už několik desítek let. Jak jsem psal, python má nepěkné vlastnosti, ale syntaxe mezi ně nepatří. Například problémy s konverzemi unicode (ordinal not in range(128) horor), cyklické importy a používání dokumentace ve sphinxu, který je všechno jen ne jednoduchý a intuitivní.

[Field]

Já ale přeci netvrdím, že jsem odborník na python. Já v něm prostě jen občas potřebuju programovat, stejně jako v dalších n jazycích, a tohle mi prostě vadí. Dokonce o tom ani netvrdím, že je to největší vada jazyka, ale dokážu pochopit, že to třeba někoho při prvním setkání otráví natolik, že se na to vykašle a jde klikat to Visual Basicu.

Možná to zkusme otočit a říct, v čem jsou ty mezery výhodné. Já na to nepřišel.

[JS1]

Možná to zkusme otočit a říct, v čem jsou ty mezery výhodné. Já na to nepřišel.

Myslim, ze hlavni vyhoda je eliminace zbytecnych radku obsahujicich 'end' nebo neco podobneho. Tim se zvysuje citelnost, protoze se vejde vic kodu na stranku.

[Bystroushaak]

Jak píšeš, jednak se tím zvyšuje čitelnost, druhak odpadá nutnost celý tenhle humus používat. Kdysi jsem jako začátečník v pascalu udělal mnohokrát tuhle chybu, že jsem na nějaký end zapomněl, nebo po něm zapomněl udělat tečku, když byl poslední. Python pak na mě působil doslova geniálně, že tenhle opruz v něm odpadá, asi jako když člověk přejde z původního basicu s číslováním řádek někam jinam.

[j]

lol ... chci videt aspon jedinyho cloveka, pro kteryho se citelnozt zlepsi tim, ze chybi zahajovaci/ukoncovaci tagy segmentu ... a je uplne jedno jestli je to begin/end, zavorky ... nebo cokoli co je normalne videt. A zcela obecne, jazyky bazirujici na formatovani byly odkopnuty na okraj spolecnosti uz pred nejakymi 30+lety.

[pavlix]

lol ... chci videt aspon jedinyho cloveka, pro kteryho se citelnozt zlepsi tim, ze chybi zahajovaci/ukoncovaci tagy segmentu

Mojí fotku na netu jistě najdeš.

[Bystroushaak]

lol ... chci videt aspon jedinyho cloveka, pro kteryho se citelnozt zlepsi tim, ze chybi zahajovaci/ukoncovaci tagy segmentu ...

Mojí fotku nenajdeš, ale pokud se někdy potkáme, tak si mě můžeš důkladně prohlédnout.

BTW: Nezlepší se tím jen čitelnost, ale taky zapisovatelnost a celkově se snižuje opruz ohledně věcí, které musíš dělat a jsou přitom dokonale zbytečné.

[Bystroushaak]

Možná to zkusme otočit a říct, v čem jsou ty mezery výhodné. Já na to nepřišel.

V tom že blok je definován odsazením a ne nějakým znakem, který si můžeš napsat kamkoliv, nebo zapomenout. Když koukneš na kód, tak prostě vidíš, zatímco všude jinde musíš studovat chlupaté závorky a beginy a endy a celou tuhle vatu kolem a běda jak jí někde zapomeneš, nebo jestli je ten po kom to upravuješ prase.

[Marvin]

+1

Lidi dokazou mnohem rychleji a snadneji rozpoznat odsazeni nez spocitat zavorky.

Na druhou stranu bych uvital kdyby v pythonu byla i moznost pouzit zavorky. Jenom pomoci odsazeni je tezky udelat nektery veci. Viz napr. pythonosvska parodie na lambda funkce.

[Bystroushaak]

Viz napr. pythonosvska parodie na lambda funkce.

No, já jsem googlil proč to tak je a údajně je to prostě proto, že Guido lambda funkce nepovažuje za dobrý nápad, který by se měl cpát všude. Osobně je ale používám docela často.

[j]

V kazdym normalnim editoru je blok v kazdym normalnim jazyce oznacen a muzu ho vybrat/zvyraznit jedinym klipnutim. A pokud potrebuju kod nejak preorganizovat, nepotrebuju jak chuj vse odsazovat, jen premistim uzaviraci znacku a o zbytek se postara editor.

[egg]

Jestli jednoduše přidáš závorky a s odsazováním si neděláš starosti, opravdu bych nechtěl po tobě něco číst. A jestli přeci jen odsazuješ, aby tvůj kód nebyl write-only, tak proč se zdržovat ještě psaním závorek?..

[little.owl]

Ze tomu tak je, svedci i knihy o algoritmech pouzivajicich intuitivni pseudokod, treba Introduction to Algorithms a dalsich, treba:

PARTITION (A, p, r)
1 x = A[r]
2 i = p - 1
3 for j = p to r - 1
4     if A[j] ≤ x
5         i = i + 1
6         exchange A[i] with A[j]
7 exchange A[i + 1] with A[r]
8 return i + 1

Zvyk je zelezna kosile .

[pavel]

V tom že blok je definován odsazením a ne nějakým znakem, který si můžeš napsat kamkoliv, nebo zapomenout

V jazycich kde blok je sam o sobe objekt je ale ukoncovaci symbol prakticka nutnost. Napr. nasledujici kod:

kolekce.reduce(init) {|elem|
  ...
}.permutation(n) { ... }.transpose

by se bez pouziti ukoncovaciho symbolu nesmyslne komplikoval a muselo by se obchazet vytvarenim pomocnych promenych nebo funkci.

U odsazovani v pythonu me jeste stve, a setkavam se s tim celkem casto, ze musim hledat k jakemu predchozimu kodu se aktualni radka vztahuje, pokud je clenity a dlouhy:

def rbt_search(...):
  if podm1 or podm2:
     ...
     if podm3 and not podm4:
        ...
        if podm5:
           ...
     elif podm6:
        ...
  else:
     # predchozi else: by mohlo byt klidne omylem zde a python nebude
     # protestovat, ale program se bude chovat jinak 
     ...

Ta fukce je dlouha treba na celou obrazovku a mezi podminkama je dost kodu. Sice muzu pouzit editor ktery podporuje sloupcovy kurzor, ale ne vsude je k dispozici tak nezbyva nez pocitat a porovnavat pocet odsazeni. To uz je lepsi proletnout explicitni endy a prinejhorsim na me zarve syntax checker ze neni blok uzavreny.

[deda.jabko]

Ta fukce je dlouha treba na celou obrazovku a mezi podminkama je dost kodu.

A napadlo te, ze by mohl byt problem v tom kodu samotnem a ne v jazyce?

[pavel]

Me funkce na jednu obrazovku ~ 25 - 30 SLOC ani nekolikanasobne vnorene podminky neprijde nic problemoveho.

[FrostyX]

Už jen dle tvého předchozího příspěvku problémové jsou, jen ti to nedochází. O čitelnosti znovupoužitelnosti, testovatelnosti, etc ani nemluvě.

[JS1]

V jazycich kde blok je sam o sobe objekt je ale ukoncovaci symbol prakticka nutnost.

To je pravda. Python tohle explicitne nema, jeho primitivou jsou funkce, nikoli bloky. Tim se lisi napr. od Lispu a Ruby. Temer zcela jde o estetickou volbu, z praktickeho hlediska je to ekvivalentni.

musim hledat k jakemu predchozimu kodu se aktualni radka vztahuje, pokud je clenity a dlouhy

Mne prijde, ze tohle je problem u vsech jazyku? Jak ti presne pomaha jazyk, kde musis mit endy? Python v tomhle pomaha tim, ze takovy kod je kratsi (protoze se konce bloku nepisou na samostatny radek).

[:::]

Treba ve vimu muzu pomoci % preskakovat z jedny zavorky na druhou.

Ale myslim ze u dlouhy funkce se slozitou srukturou by bylo vhodny se zamyslet nad refaktoringem.

[JS1]

Treba ve vimu muzu pomoci % preskakovat z jedny zavorky na druhou.

Pak se nabizi otazka, proc by neco takoveho nemohl umet i u Pythonu..

[:::]

Naprogramovat tohle pro zavorky je snadny a obecne pouzitelny (nejenom pro jeden jazyk a pro bloky kodu).

Naprogramovat to pro python by bylo podstatne slozitejsi (v podstate bys tam musel mit parser pythonu) a je to pouzitelny jen pro jeden jazyk.

Navic skok z dvojtecky nekam priblizne na konec bloku je relativne jednoznacny, ale opacne, najit spravnou dvojtecku kdyz mam kurzor nekde v kodu uz tak jednoznacne byt nemusi...

[JS1]

Ano, dokazu si predstavit, ze jsou pro to technicke duvody. Pak to ale nebude fungovat ani treba v tom Pascalu.

[Bystroushaak]

Naprogramovat to pro python by bylo podstatne slozitejsi (v podstate bys tam musel mit parser pythonu) a je to pouzitelny jen pro jeden jazyk.

Python má v sobě parser pythonu (ast modul).

[Josef Kufner]

Nepotřebuješ závorky, stačí sledovat odsazení.

Viz http://vim.wikia.com/wiki/Move_to_next/previous_line_with_same_indentation (nezkoušel jsem to)

[pavel]

Temer zcela jde o estetickou volbu, z praktickeho hlediska je to ekvivalentni.

Z praktickeho hlediska se to musi obchazet a zhorsit tim srozumitelnost kodu.

Jak ti presne pomaha jazyk, kde musis mit endy?

Tim ze explicitne vyzaduje ukonceni bloku nemuze dojit k nejednoznacnosti u vyse uvedeneho prikladu. Parser na to upozorni, stejne tak na neukonceny blok. Pomaha proti zaludnycm chybam, ktere vzniknou omylem pri vetsim nebo mensim odsazeni.

[JS1]

Z praktickeho hlediska se to musi obchazet a zhorsit tim srozumitelnost kodu.

Kde se to musi obchazet? Muzes dat konkretni priklad, kde jsou funkce problematicke?

Jinak zavedenim jak funkci tak bloku se jazyk stane ponekud mene ortogonalni. Lisp to resi tak, ze defun je makro. Jazyky bez maker si tenhle luxus dovolit nemuzou.

Tim ze explicitne vyzaduje ukonceni bloku nemuze dojit k nejednoznacnosti u vyse uvedeneho prikladu.

Nevim, jestli si spravne rozumime. Pokud chces napsat jen jedno else u dvou vnorenych podminek, bude to vzdycky nejednoznacne, s endy i bez endu.

V podstate to co rikas je: S endem se musim ujistit na dvou mistech, zda jsem to napsal dobre, a tim spis to napisu dobre. Nicmene nic ti nebrani se 2x ujistit i v Pythonu. V obou pripadech ale kompilator kontroluje jen jeden zpusob - u Pythonu odsazeni, u jinych jazyku existenci endu.

Navic, Python je optimalizovany pro cteni, na zaklade predstavy, ze kod cteme mnohokrat, ale piseme jen jednou.

[pavel]

Kde se to musi obchazet?

Zkus si prepsat ten uvodni priklad do pythonu a uvidis. Pokud neznas ruby, tak bloky jsou vymezeny '{' a '}', nazvy metod jsou samovysvetlujici.

Nevim, jestli si spravne rozumime. Pokud chces napsat jen jedno else u dvou vnorenych podminek, bude to vzdycky nejednoznacne, s endy i bez endu.

Vtip je v tom, ze kazda podminka musi mit uzavreny blok a pokud ho uzavru u te vnitrni, nemuze se mi stat ze by nasledujici kod do neho vstoupil a hlavne zacatek a konec bloku jsou parove a kdyz opomenu uzavrit tak to za me parser zkontroluje a vyhodi chybu. U pythonu takova kontrola chybi a nezamyslene ukonceni bloku chybnym odsazenim projde a program se pak chova chybne.

[JS1]

Zkus si prepsat ten uvodni priklad do pythonu a uvidis.

Ja tomu prikladu rozumim, jen ho povazuji za hure citelny nez to, jak by se to napsalo v Pythonu (definovala by se vnitrni funkce).

U pythonu takova kontrola chybi a nezamyslene ukonceni bloku chybnym odsazenim projde a program se pak chova chybne.

To je uplne stejny argument jako pro statickou typovou kontrolu. Ano, interpretr to "kontroluje", ale jen za cenu, ze to tam sam napises. Python se holt rozhodl, ze to lide psat navic nemusi, a muzou cas usetreny psanim "end" venovat tomu, aby si to po sobe lepe precetli.

[pavel]

Ja tomu prikladu rozumim, jen ho povazuji za hure citelny nez to, jak by se to napsalo v Pythonu (definovala by se vnitrni funkce).

Jiste, zavede se nova promenna - funkce do ktere se ulozi obsah bloku a na tu se pak bude odkazovat. A pak jeste jedna a jeste jedna. Tak misto prirozeneho zapisu algoritmu cteneho zleva do prava budeme postupne volat krome knihovnich funkci jeste tri vlastni a odskakovat k jejich definicim, abychom vedeli co delaji. Tomu rikam lepsi citelnost. Bravo

Python se holt rozhodl, ze to lide psat navic nemusi, a muzou cas usetreny psanim "end" venovat tomu, aby si to po sobe lepe precetli.

Lepe po sobe cist ! Ze me to hned nenapadlo

[mirec]

Čo sa týka dokumentácie ... čo je lepšie než sphinx? Nejak extra mi nevyhovuje, ale pravdu povediac na druhej strane ani nič lepšie v čom sa dá podrobnejšie popísať fungovanie systému ako celku a potom rozpísať jednotlivé komponenty nepoznám.

[Bystroushaak]

Lepší než Sphinx je asi všechno, i takový javadoc :D

Pokud myslíš lepší než Sphinx v pythonu, tak jen Sphinx s napoleondoc: http://sphinxcontrib-napoleon.readthedocs.org může za to, že jsem se z toho ještě nezbláznil. Dřív jsem v osobních projektech používal Doxygen, který jsem později nahradil za epydoc, se kterým jsem byl docela spokojený.

Mě na Sphinxu irituje, že dokumentace samotného sphinxu je dost divná (na některé věci jsem musel přijít prostě tím, že jsem studoval kódy ostatních na githubu tak dlouho, až jsem našel co jsem potřeboval) a syntaxe nedává smysl, tu prostě vylosovali náhodně z klobouku. Je fakt, že jakmile to člověk umí, tak je to dost silný nástroj, který má pár schopností navíc proti ostatním Markupům. Moje rage na tohle téma trochu zklidnil Eric Holscher na tomhle talku z pyva; https://www.youtube.com/watch?v=ztdPSbIIwoo.

[egg]

Například problémy s konverzemi unicode (ordinal not in range(128) horor), ...

Odpověď zní Python 3. Ale je mi jasné, že tím začínají zase jiné problémy.

[Bystroushaak]

No, to jen do určité míry, a když jsem zkoušel přepisovat IRC bota, tak jsem tam taky narazil na pár problémů. Navíc ne vždy máš možnost volby - já si třeba v práci vybírat nemůžu.

[pavlix]

Pro mě je Python 3 odpověď na hodně věcí a v jeho světle mi Python 2 připadá jako sprasený prototyp.

[Bystroushaak]

Mě zrovna dneska python3 naštval tím vracením iterátorů ze všeho možného. Takhle mám na každém druhém řádku přetypovávání zpět na list, protože autory asi nenapadlo, že bych chtěl výstupy z map/filter/comprehensions/.keys() testovat na prázdnost, indexovat a vůbec s nimi dělat cokoliv jiného než přes ně iterovat. Vzhledem k tomu jak často to musím přetypovávat mi to přijde nehorázně otravné.

[Alfonz]

Jo tohle mně na 3 také neuvěřitelně štvě... Nechápu koho to napadlo.. často procházím keys() nebo nový vytvořený list a něco s objekty dělám. Vůbec mi nejde do hlavy koho napadlo, že teď musím každé procházení vylepšit o jeden list(obj...) navíc.

[egg]

často procházím keys() nebo nový vytvořený list a něco s objekty dělám.

Na to je snad právě iterátor určený a není potřeba kvůli tomu stavět seznam. Anebo si pod procházením představuješ něco jiného než já.

[pavlix]

Vůbec mi nejde do hlavy koho napadlo, že teď musím každé procházení vylepšit o jeden list(obj...) navíc.

Pokud při procházení zadáváš list(d.keys()), tak to zkus nahradit za d.keys() a pochopíš.

[little.owl]

Iteratory umoznuji celou radu vnitrnich optimalizaci, takze pristup chapu. Pokud musite porad pretypovavat, videl bych to spise na problem jinde.

V nejhorsim muzete pouzit tohle:

an_iterator_object.__length_hint__()

ale je to neportovatelny implementacni detail.

[Bystroushaak]

Iteratory umoznuji celou radu vnitrnich optimalizaci, takze pristup chapu.

Já to taky chápu. Co nechápu je použití dementních iterátorů, které mě o možnosti připravují, místo aby mi nějaké daly. Přitom by stačilo přidat pár magických metod, které má každé pole. Iterátory ta data stejně k dispozici mají, jen bude trvat pár let, než to někomu dojde a s velkou slávou to začlení do pythonnu 3.6, nebo tak něco.

Pokud musite porad pretypovavat, videl bych to spise na problem jinde.

Problém je ve vývojářích jazyka, kteří tohle všem nacpali do chřtánu a nedomysleli přitom, že by bylo hezké mít možnost si zvolit, jestli chci pole, nebo iterátor, jako to bylo v 2.7. Docela si dokážu představit, jak to probíhalo; "oni ty iterátory moc nepoužívají, přitom je to geniální, co jim je pro dobro věci nacpat všude a pro jistotu jim sebrat možnost zvolit si, jestli je chtějí, nebo ne? Celé to pak bude optimální & shit."

Nechci působit jako nějaký hater - iterátory a generátory jsou geniální součást jazyka, jen mě pěkně vytáčí, když je cpou všude jen proto, že by to šlo, když mi to nedá žádnou novou možnost, naopak mi to spoustu možností sebere a jediné řešení je přetypování na list, čímž výkon ztrácím, místo abych ho získával. Je to předčasná optimalizace jak prase a ještě navíc "inteligentní" ve stylu pana sponky z Windows.

[JS1]

Ja myslim, ze to domysleli. Misto:

d.iterkeys()

d.keys()

mame:

d.keys()

list(d.keys()) nebo d.keys()[:]

Mne to druhe pripada lepsi (a vidis, ze to neni o tolik kratsi). Za prve, zbavis se te metody keys(), ktera vraci seznam. Dale, tim, ze explicitne volis, co chces, napr. muzes udelat set(d.items()) a dostat tak mnozinu. Vysledek je ortogonalnejsi API - dict podporuje vsechny enumerovatelne datove struktury stejne.

Za druhe, ono to trochu souvisi s filozofii Pythonu, "Explicit is better than implicit". Existuje myslim v navrhu Pythonu jedno nevyrcene pravidlo (ktere vyplyva take trochu z "There should be one obvious way to do it"), ktere zhruba rika, ze pokud lze nejakeho efektu dosahnout trivialni kombinaci dvou, mozna tri metod, nema smysl kvuli tomu do jazyka zavadet dalsi metodu. Protoze lide si zkratka tyhle nove metody nebudou pamatovat. Tohle pravidlo dost odlisuje Python od jinych jazyku (Perl, PHP, Common Lisp), ktere bezstarostne pridavaji dalsi metody jen proto, ze "lide tohle chteji casto delat" nebo "dava to logicky smysl".

A mne osobne tohle vyhovuje, protoze po pravde, daleko casteji pouzivam iteratory nez seznamy. Dela to program mene zavislym na objemu dat, co tecou skrz. A pokud te zajima nejaka vlastnost mnoziny dat vracene pres iterator, neni treba to hned prevadet na seznam - doporucuji se podivat na modul itertools.

[JS1]

Dalsi aspekt je, ze lide samozrejme meli tendenci psat for k in d.keys() a ne for k in d.iterkeys(), cimz zbytecne ztraceli vykon (podobne jako pouzivali range tam, kde staci xrange).

[Bystroushaak]

d.keys() list(d.keys()) nebo d.keys()[:]

Až na to, že tohle imho musí projít iterátorem a vytvořit z něj nové pole. Což není ekvivalentní ani omylem.

Dale, tim, ze explicitne volis, co chces, napr. muzes udelat set(d.items()) a dostat tak mnozinu. Vysledek je ortogonalnejsi API - dict podporuje vsechny enumerovatelne datove struktury stejne.

To jsem mohl udělat předtím taky, jen bych k tomu musel zavolat jinou metodu.

Tohle pravidlo dost odlisuje Python od jinych jazyku (Perl, PHP, Common Lisp), ktere bezstarostne pridavaji dalsi metody jen proto, ze "lide tohle chteji casto delat" nebo "dava to logicky smysl".

S tím se dá skoro souhlasit, až na to, že tohle bylo v py2 dost dlouho a nic se nepřidává, ale ubírá. Dokonce to má za následek složitější portování kódu, který bude padat na tom, že najednou je z toho iterátor (true story).

[JS1]

Až na to, že tohle imho musí projít iterátorem a vytvořit z něj nové pole. Což není ekvivalentní ani omylem.

Pak nechapu, v cem je tvuj problem. Jaky je tvuj use case pro pristup k tem prvkum jako k poli?

Prijde mi, ze pokud pozadujes pristup do internich struktur dict (nebo cehokoliv jineho), rozbijis modularitu za ucelem optimalizace. Ne, ze by to bylo spatne, ale v takovem pripade asi udelas lepe, kdyz si zkonstruujes vlastni datovou strukturu, ktera se lepe hodi pro tvuj specificky problem.

S tím se dá skoro souhlasit, až na to, že tohle bylo v py2 dost dlouho a nic se nepřidává, ale ubírá.

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. -- Antoine de Saint-Exupery

[Bystroushaak]

Jaky je tvuj use case pro pristup k tem prvkum jako k poli?

Tak jednak je to testování na prázdnost, jak už jsem psal, pak zjištění počtu prvků. Když pracuješ s ordered dictem, tak se hodí mít například možnost zjistit index, který v něm daný prvek má (to jsem reálně použil například včera).

Prijde mi, ze pokud pozadujes pristup do internich struktur dict (nebo cehokoliv jineho), rozbijis modularitu za ucelem optimalizace. Ne, ze by to bylo spatne, ale v takovem pripade asi udelas lepe, kdyz si zkonstruujes vlastni datovou strukturu, ktera se lepe hodi pro tvuj specificky problem.

Proč bych to dělal? Na pythonu je pěkné, že díky dynamickým polím, slovníkům a setům se tomuhle můžu ve většině případů vyhnout, než abych trávil půlku doby vynalézáním neoptimálních zabugovaných ekvivalentů běžných datových struktur.

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. -- Antoine de Saint-Exupery

Jo, proto teď musíš přidat přetypování na list :].

[JS1]

Tak jednak je to testování na prázdnost, jak už jsem psal, pak zjištění počtu prvků.

Pokud vim, standardni dict ma funkci len(), ktera ti pomuze zjistit oboji.

Když pracuješ s ordered dictem, tak se hodí mít například možnost zjistit index, který v něm daný prvek má (to jsem reálně použil například včera).

Co se tyce usporadaneho slovniku, to jsem snad nikdy nepouzival. Ale prijde mi, ze si pak stezujes na neco jineho.

Mozna by bylo uzitecne, aby usporadany slovnik mel metodu, ktera ten index vrati (i kdyz zase, troufam si trochu zpochybnit, k cemu by to mohlo byt dobre - napis co konkretne jsi delal). Ale to pak neni problem s dict API, protoze tam ten index nema vyznam, jelikoz je to hashtabulka.

Na pythonu je pěkné, že díky dynamickým polím, slovníkům a setům se tomuhle můžu ve většině případů vyhnout, než abych trávil půlku doby vynalézáním neoptimálních zabugovaných ekvivalentů běžných datových struktur.

To si povime, az mi vysvetlis, k cemu potrebujes ten index.

[Bystroushaak]

To si povime, az mi vysvetlis, k cemu potrebujes ten index.

Ordered dict používám jako lookup tabulku. Tohle je případ, kdy potřebuji prohodit pořadí dvou prvků v té tabulce. Ordered to musí být proto, že později jí celou serializuji do textu a záleží tam na pořadí, dict proto, že v ní hledám podle klíčů. Celý ten projekt sem časem hodím do vlastního blogpostu.

Pokud vim, standardni dict ma funkci len(), ktera ti pomuze zjistit oboji.

Pravda. V té implementaci pythonu kterou jsem použil to nešlo, ale když jsem to teď testoval v cpythonu, tak ano, takže to bude bug v interpretru brythonu.

[pavlix]

Jak to tak popisuješ, tak se obávám, že to máš skutečně z hlediska datových struktur nešikovně navržené.

[pavlix]

Když pracuješ s ordered dictem, tak se hodí mít například možnost zjistit index, který v něm daný prvek má (to jsem reálně použil například včera).

Pokud vím, tak je to vcelku nová datová struktura, která tak nějak kombinuje vlastnosti seznamu a slovníku. Nejspíš nemá smysl nadávat na Python 3 jako takový, ale soustředit se na absenci obdoby .index() u OrderedDict nebo ItemsView.

Jo, proto teď musíš přidat přetypování na list :].

No to je toho. Kvůli absenci .index někde jednou necháš vylistovat slovník a pokud nepočítáš s velkými daty, jednoduše uděláš list(d).index(key) nebo list(d.values()).index(key), popřípadě dokopeš pythonisty, ať .index() vyspecifikují a přidají a kvůli zpětné kompatibilitě pak dáš do kódu něco ve smyslu...

if not hasattr(collections.OrderedDict, "index"):
    collections.OrderedDict.index = lambda self, key: list(self).index(key)

[Bystroushaak]

No to je toho. Kvůli absenci .index někde jednou necháš vylistovat slovník a pokud nepočítáš s velkými daty, jednoduše uděláš list(d).index(key) nebo list(d.values()).index(key), popřípadě dokopeš pythonisty, ať .index() vyspecifikují a přidají a kvůli zpětné kompatibilitě pak dáš do kódu něco ve smyslu...

if not hasattr(collections.OrderedDict, "index"):
    collections.OrderedDict.index = lambda self, key: list(self).index(key)

To moc nepatří k věcem, které bych chtěl do smrti držet v paměti.

[pavlix]

To moc nepatří k věcem, které bych chtěl do smrti držet v paměti.

Ty se chystáš držet zpětnou kompatibilitu až do smrti?

[Bystroushaak]

Ne. Nepatří to k věcem, které chci dělat, přesto budu muset. Je to podobné jako s daněma.

[pavlix]

To měla být odpověď na otázku? :)

[JS1]

Jinak mel jsem za to, ze Python 2 v d.keys() vzdycky vraci kopii pole tech svych internich klicu (kvuli mutabilite), takze fakt nevim, proc ti tak vadi vytvoreni noveho pole.

[Bystroushaak]

Mě vadí především to, že se s tím musím takříkajíc srát. Dost často používám filter() tam, kde chci dostat jen jeden prvek a z vráceného iterátoru mám opravdu negativní radost.

[JS1]

Zase, nerozumim tomu, co se snazis delat. Funkce filter() snad bere i iterator, ne? A vraci iterator, tak muzes napsat (tusim, pisu to bez manualu po pameti):

first,* = filter(d.keys(), op)

[Bystroushaak]

Dobrá teorie, až na to že to padne, pokud nedostanu zpět nic a ta syntaxe s hvezdičkou je něco co sis tam doplnil z jiného jazyka.

[:::]

u ty hvezdicky jenom vypadl identifikator ne?

first, *rest = 1,2,3,4,5

[Bystroushaak]

Ok, tohle jsem sice znal, ale měl jsem za to, že to má v py3 přestat fungovat (a ono je to naopak). Stále to má problém, pokud je pole prázdné, ale chápu kam směřuješ.

[pavlix]

Tak jako tak to není podle mě ta správná konstrukce.

next(filter(...))

[egg]

Dost často používám filter() tam, kde chci dostat jen jeden prvek

next(filter(...))

[pavlix]

+1

[Bystroushaak]

Dobré, to mě ani nenapadlo. Škoda, že u dictu to padá:

> a = {1:2}.keys()
> next(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'dict_keys' object is not an iterator

[JS1]

Samozrejme, protoze jsi v Pythonu 2 - musis pouzit iterkeys().

[little.owl]

Cekal bych, ze i v python3 bude potrebovat:

next(iter(a))

ale ted to nemohu otestovat ...

[egg]

Je to tak. Ale nevím, k čemu to je dobré, znamená to: "dej mi jeden klíč slovníku, lhostejno který".

[Bystroushaak]

Samozrejme, protoze jsi v Pythonu 2 - musis pouzit iterkeys().

Ne, nejsem. TypeError: 'dict_keys' object is not an iterator; v pythonu 2 to nevrací dict_keys, ale pole a to je trochu jiný error :)

<<< a = {1:2}.keys()
<<< next(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list object is not an iterator

[pavlix]

Pravda, on to není iterátor, ale view. Python 2.7 už tam má tuším všechny tři, list, iterátor a view. Možná jsem se na to i někde v komentářích chytil...

Můžeš iterovat slovník nebo view nad klíči:

next(iter(d))
next(iter(d.keys()))

[Bystroushaak]

Příloha:

• mmifof.jpg (42697 bytů)

[pavlix]

Tak až se ti hlava zase srovná, tak si uvědomíš, (1) že jde jen o ukázkový kód vhodný k pochopení, jak věci fungují a (2) že pokud chceš používat next(), potřebuješ iterátor, nikoliv pole nebo view. Pokud chceš seznam, je lepší použít list(). To všechno je podle mě v pořádku. Proč nemají ty views list API, to mi ale úplně jasné není, nechtěl bys jim poslat dotaz?

[Bystroushaak]

Proč nemají ty views list API, to mi ale úplně jasné není, nechtěl bys jim poslat dotaz?

Komu? Nemám úplně náladu vést anglické konverzace s vývojáři.

[little.owl]

Proč nemají ty views list API, to mi ale úplně jasné není, nechtěl bys jim poslat dotaz?

Duvod by mohl byt, ze oni jsou z hlediska uzivatele immutable, ale mohou se dynamicky menit pokud se zmeni odkazovany dictionary objekt, coz je jine chovani, ktere muze mit mnou ted nedomyslene dopady.

[pavlix]

Podle mě je prostě OrderedDict nedodělaný. Je to taková kombinace list a dict, takže by to mělo implementovat víceméně kompletní API obou a případě ještě prvky, které vycházejí z jejich kombinace.

[little.owl]

Implementace dictviewobject je velmi jednoducha a nedodelana, viz. TODO:

/* TODO(guido): The views objects are not complete:

 * support more set operations
 * support arbitrary mappings?
   - either these should be static or exported in dictobject.h
   - if public then they should probably be in builtins
*/

[pavlix]

Ve skutečnosti to s vestavěným slovníkem není zase tak horké. Tady je řeč o OrderedDict, což je slovník lízlý seznamem, navíc implementovaný v Pythonu a odvozený od vestavěného slovníku. Navíc co koukám, tak pořadí je implementováno spojovým seznamem, což mi přijde přinejmenším překvapivé. Asi bych to zahodil a implementoval znova, aby to mělo co nejvíc vlastností pythoního seznamu.

[JS1]

Mimochodem, next() bere volitelny parametr, ktery se vrati misto toho, pokud je iterator prazdny. Takze je to lepsi reseni nez to, co jsem psal vys.

[little.owl]

Vytvareni listu, pokud je znama delka, je rychle, pomala je jen alokace pameti. Iteratory maji malou konstantni velikost, velikost listu zavisi na poctu prvku. Pokud iterator iteruje, pouziva se stale stejny objekt v pameti, u velkych listu je nesrovnatelne pomalejsi vytvorit kopii nez iterator. Filozofie python3 je, ze tam kde to jde, bude se pouziva pouze "dynamic view" do pameti pres iteratory a nevytvari se kopie, python2 kopie v mnoha pripadech, jako tomto, zbytecne vytvarel.

[little.owl]

To bylo na usaka ...

[:::]

Souhlasim ze iteratory maji smysl, ale mohli se trochu vic snazit s jejich rozhranim.

Napr. pri pretypovani na bool by meli vracet jestli je mozne udelat next(). Zkouset next() a zachytavat vyjimku je otrava. Vyresil by se tim i test na prazdnost bez vytvareni listu.

[pavlix]

Zachytávat výjimku není nutné, `next()` při neúspěchu umí vrátit druhý parametr. Pokud bys chtěl, aby bool() vracel, zda jsme na konci, tak to už jde mimo generátorové API a vyžaduje to být o krok napřed. Je fakt, že u iterátorů nad seznamy by to smysl dávalo.

[pavel]

d.keys()[:]

Explicit is better than implicit - The Zen of Python
Trochu prasarnicka takhle zneuzivat list slicing, vhodna tak na code golf.

[JS1]

Ja to pouzivam, je to kratsi nez copy(). Nevidim na tom nic implicitniho.

[pavlix]

Několikrát jsem přemýšlel nad tím, zda není list.copy() nadbytečné, když lze použít list().

[JS1]

Urcite list() na existujici list vraci kopii? To se mi zda spatne.. Tyhle konstruktory "typove konverze" by mely byt idempotentni.

[pavlix]

Samozřejmě, že vrací kopii. Nevidím jediný důvod, proč by vytváření instance třídy s existující instancí jako parametrem mělo být idempotentní. Vždyť by to volání pak dělalo v závislosti na parametru zcela různé věci.

[JS1]

Tak chapat se to da ruzne - jako konstruktor, nebo jako typova konverze. Ale mas pravdu, asi je to vhodne, aby u mutable typu vracel kopii (treba u tuple() se vraci ten stejny tuple).

Myslim, ze jsem si na [:] idiom zvykl kdysi davno, kdy jeste nebyl list() jako builtin funkce.

[pavel]

Ja to pouzivam, je to kratsi nez copy(). Nevidim na tom nic implicitniho.

Jednak jsou pouzity implicitni pocatecni a koncovy index slice a hlavne se explicitni vytvoreni seznamu konstruktorem maskuje vytvarenim vysece ze vsech prvku.

Aby toho nebylo malo ten priklad se slice mi v Pythonu 3.4 ani nechodi: {}.keys()[:] hodi TypeError: 'dict_keys' object is not subscriptable

[JS1]

Jo, na to jsme tady uz narazili, ze keys() nevraci primo iterator. Myslel jsem, ze se chova jako iterkeys() v Pythonu 2. Podle me je to divne, zajimalo by mne, jaky k tomu je duvod.

[pavlix]

Jo, na to jsme tady uz narazili, ze keys() nevraci primo iterator.

Ani seznam, který by byl v tomto případě vyžadován.

Myslel jsem, ze se chova jako iterkeys() v Pythonu 2.

A on se přitom chová jako viewkeys() (nebo spíše viewkeys() je jeho název v pozdějších verzích dvojky). Proč to nejde indexovat ale docela chápu, vzhledem k tomu, že pořadí u slovníku nedává smysl. Proč to nejde indexovat u OrderedDict už je jiná věc. On ani není důvod, aby to byl iterátor, hlavně když je to iterable.

[JS1]

On ani není důvod, aby to byl iterátor, hlavně když je to iterable.

Spis jaky je duvod k tomu, aby to iterator nebyl? Prijde mi, ze to nemuze nicemu uskodit.

[pavlix]

Spis jaky je duvod k tomu, aby to iterator nebyl? Prijde mi, ze to nemuze nicemu uskodit.

Takto je d.keys() objekt svázaný s d, který dává API k přístupu ke klíčům slovníku. Nechová se jako seznam, protože klíče nemají dané pořadí. Chová se spíše blíže množině. Ale narozdíl od iterátoru se nevyčerpá a dá se používat opakovaně. Iterátory a iterovatelné objekty je potřeba striktně rozlišovat, až na pár výjimek, mezi které patří iterátory samotné a různé generátory na jedno použití.

>>> d = {x**2: x for x in range(10)}
>>> keys = d.keys()
>>> list(keys)
[0, 1, 4, 49, 16, 25, 64, 9, 81, 36]
>>> list(keys)
[0, 1, 4, 49, 16, 25, 64, 9, 81, 36]

Pokud by keys() a values() byly iterátory, tak by takto nefungovalo. Už takto si lidé stěžují na změněné chování oproti seznamům, ale seznam klíčů slovníku skutečně pořadí nemá.

>>> keys = iter(d.keys())
>>> list(keys)
[0, 1, 4, 49, 16, 25, 64, 9, 81, 36]
>>> list(keys)
[]

[JS1]

Ano, to mas pravdu, v tomhle by se ta semantika lisila, ale stale nechapu, proc je to problem? Ten priklad mi prijde dost umely - copak nekdo chce v realnem kodu neco takoveho delat? (Vzdyt je to hloupost - stejny seznam se zbytecne konstruuje 2x.)

[pavlix]

Tak nebudu se vypisovat s příkladem s cyklama nebo něčím takovým, to už si laskavý čtenář doplní sám ;).

[JS1]

Ja bych si to i rad doplnil, ale neznam takovy priklad. Nevim, proc neni lepsi vzdy znovu zavolat d.keys(). Musim rict, ze v tomhle me tedy Python 3 dost zklamal - vymysleli novou vec (view), ktera neni ani iterator, ani list. Bud za tim je nejaky hodne dobry duvod, nebo je to uplna hloupost.

[pavlix]

vymysleli novou vec (view), ktera neni ani iterator, ani list.

Ale to je podle mě úplně mylný pohled, view podle mě nemá vůbec znamenat konkrétní datovou strukturu ale obecné slovo, tak jak se v programování (a třeba v databázích) používá. Někdy se tomu taky říká proxy nebo proxy object.

Podle mě je to navrženo správně:

1) Nemá to být seznam ani se to chovat jako seznam, protože na pořadí klíčů nezáleží.

2) Nemá to být množina, aby nebylo nutné ji vždy konstruovat, ale má se to jako množina navenek chovat, proto i to TODO.

3) Určitě to nemá být iterátor, protože pak by se to nechovalo jako kolekce.

Seznam, množina a jiné kolekce taky nejsou iterátory. Jasně, mohlo by se prostě zadefinovat, že ty metody iterátory vracet budou, ale to mi přijde jako hrozná prasárna. Na příkladu jsem jen ukazoval, že kolekce a iterátor mají skutečně odlišné chování.

[Bystroushaak]

Já bych neměl nic proti existenci, kdyby si programátor mohl vybrat, jestli to chce nebo ne. Takhle je to ale podivný ošklivý hybrid k ničemu, ze kterého si člověk musí vyrobit použitelnou datovou strukturu přetypováním. To že to někde možná ušetří špetku výkonu je mi veskrze ukradené, protože výkon je to poslední co mě při programování zajímá a když náhodou ano, budu to řešit optimalizací algoritmů, nikoliv pseudooptimalizacema datových struktur. To jediné, co to v současnosti přináší je bordel a zmatení, nic víc.

[JS1]

Napsal jsi 5 odstavcu, ale jedina podstatna informace byla:

má se to jako množina navenek chovat

OK, dejme tomu. To ale porad neodpovida na otazku, k cemu je to dobre, a uz vubec ne, zda je to dobre rozhodnuti.

Konkretne, bude ta pseudo-mnozina mutable? Predpokladam, ze ne (v opacnem pripade to dava dalsi otazky ohledne semantiky). V takovem pripade ovsem nevidim moc vyhod oproti konstrukci mnoziny z iteratoru.

Ano, dokazu si predstavit, ze nektere algoritmy (treba prunik klicu dvou slovniku) budou mirne rychlejsi. Ale mam dost pochybnost, ze to vyvazi tu nevyhodu s tim psat vsude iter() navic. Myslim, ze by bylo uzitecnejsi dat takovy algoritmus mimo slovnik, a udelat z keys() regulerni iterator.

[pavlix]

Naopak. Napsal jsem tři body, které podle mě vysvětlují, proč .keys(), .values() a .items() nevrací seznam, množinu ani iterátor, ale dynamický read-only pohled na množinu klíčů, hodnot nebo jejich dvojic. Z tvého zápisu mi ani není jasné, se kterými body přesně nesouhlasíš a proč, ani jaké řešení je podle tebe lepší a proč.

Ale mam dost pochybnost, ze to vyvazi tu nevyhodu s tim psat vsude iter() navic.

Mám takové podezření, že jsem viděl víckrát iter() v této diskuzi než ve skutečném kódu.

[JS1]

Zadne "proc" jsi nevysvetlil! Proste jsi jen napsal, ze to tak je.

Podle me by bylo nejlepsi, kdyby proste d.keys() v Pythonu 3 vracelo primo iterator.

K cemu mi je "dynamicky pohled na mnozinu klicu" dobry? Otestovat, jestli je neco soucasti te mnoziny muzu i na samotnem slovniku. Pokud chci ty klice projit, muzu to udelat i s iteratorem. Co jeste dalsiho chybi? Fakt nevidim ten use case.

A u "dynamickeho pohledu na mnozinu hodnot ci dvojic" je to jeste horsi. To totiz uz vubec nemusi byt mnoziny, takze pripadna semantika je uz uplne mlhava.

[little.owl]

Podle me by bylo nejlepsi, kdyby proste d.keys() v Pythonu 3 vracelo primo iterator.

A ted vam vraci view, ktere reflektuje dynamicky zmeny v pameti, vcetne poradi a v pripade potreby si z nej muzete udelat iterator ci list.

Problem listu je v tom, ze jak ho jednou vytvorite nereflektuje zmeny v puvodni dictionary, list muze byt modifikovan a navic zabira i misto v pameti. Iterator je na tom o neco lepe, ale stale nemusi reflektovat zmeny v puvodnim objektu.

Idea dynamic view jako set mi prijde lepsi - muzete provadet operace prunik, sjednoceni, testovat bezpecne existenci snapshotu klicu i kdyz se puvodni objekt zmenil.

[:::]

Nejaky priklad kdy je to dobry ze reflektuje zmeny? Me to prijde celkove jako spatny napad ze si vytahnu seznam klicu, zacnu delat zmeny ve slovniku, a seznam klicu se me pri tom nenapadne meni...

Kdyz chci informce o aktualnim stavu slovniku, tak proste pouziji primo ten slovnik..

[little.owl]

Ano, to chapu, a na prvni pohled to vypada uzitecne.

I na druhy.

a seznam klicu se me pri tom nenapadne meni...

Pak si tedy vytvorte list nebo set. Vyhodu vidim treba v tomto:

if dict1.keys() == dict2.keys():
    ...

pripadne i jine operace. Nebo ciste z duvodu efektivity:

dv = dict.items()
for x, y in dv:
...

for x, y in dv:
...

for x, y in dv:
...

fs = set(dict.keys())

...

if fs == dict.keys():
   ...

Tyto operace s vyjimkou vytvoreni setu jsou asi rychle - vytvari se maly objekt a prinasi to IMHO mene problemu v asynchronnim ci multithreadovem prostredi nez iteratory se stavem ci kopie v listech.

Bohuzel je hloupe, soude podle kodu, ze plna funkcionalita set-u neni jeste dodelana.

[little.owl]

Huf, neprilis chytre dat ilustrativni promenne jmeno typu ... jeste, ze jsem hned pote zmizel domu, protoze ...

[JS1]

Idea dynamic view jako set mi prijde lepsi - muzete provadet operace prunik, sjednoceni, testovat bezpecne existenci snapshotu klicu i kdyz se puvodni objekt zmenil.

Ano, to chapu, a na prvni pohled to vypada uzitecne.

Ale proc si proste nemuzu, ve chvili, kdy chci provest tu operaci treba pruniku, pozadat o aktualni iterator nad tim slovnikem? Proc to nestaci? Proste fakt nevidim ten use case - zkus schvalne nejaky vymyslet.

Dokazal bych si predstavit, ze by bylo uzitecne, kdyby treba i ten prunik byl dynamicky view. Ale jak to chapu, tak v momente, kdy udelas treba prunik, ti stejne vznikne kopie, ktera se uz k puvodnim objektum vazat nebude. Proste porad se snazim prijit na to, k cemu je ta "dynamicnost" toho view dobra?

[pavlix]

No nic, dokud se mi od tebe nedostane nějaké relevantní kritiky a lepšího zdůvodnění než „proč ne“, nemám jaksi na co reagovat. Množina dvojic je stejně přímočará jako množina klíčů. O množině a multimnožině hodnot se dá diskutovat, ale těžko bez reálného use case.

[JS1]

Ale ja nerikam "proc ne", ja rikam "proc jo". Ten kdo prosazuje nejakou vlastnost jazyka by mel umel vysvetlit, k cemu je dobra, nikoli naopak. A specialne u Pythonu, ktery je co se tyce pridavani novych vlastnosti dost konzervativni.

[pavlix]

Celou dobu jsem měl za to, že prosazuješ, aby metoda .keys() u pythoních slovníků začala vracet iterátor. Pak bys to tedy měl podle svých vlastních slov měl umět zdůvodnit.

[JS1]

Na takovy use case jsme tady prece uz narazili.

Ale konecne, po deseti prispevcich, z tebe vypadlo neco rozumneho. Uznavam, ze porovnani dvou mnozin klicu se prilis elegantne s iteratory udelat neda. I tak se mi to rozhodnuti ale moc nelibi.

[pavlix]

Ale konecne, po deseti prispevcich, z tebe vypadlo neco rozumneho.

K čemu další zbytečná urážka?

[JS1]

K cemu? Protoze se celou dobu tvaris, jako by to byla ocividna vec. Ale pritom jsi na ten protipriklad (ktery je ale i tak diskutabilni) ani sam neprisel.

[pavlix]

Když ti to dělá dobře, tak pokračuj, aspoň udělám dobrý skutek a pomůžu duševně nestabilnímu jedinci ;).

[little.owl]

Protoze se celou dobu tvaris, jako by to byla ocividna vec.

Tak pavlix vam dal tri koncepcni duvody proc je pristup korektni.

ktery je ale i tak diskutabilni

Vyborne, proc?

Ted jsem pouzil pro test existence alespon jednoho klice:

if dictionary.keys() & {'key1', 'key2', 'key3'}:
    ...

Jak byste to udelal lepe?

Pokud potrebujete iterator nebo list se souvisejicim overheadem a limitacemi - uvazujte o dictionaries s tisici zaznami - tak si je explicitne vytvorite, jedno nebo druhe, no biggie.

Tedy proc?

[Bystroushaak]

Pokud potrebujete iterator nebo list se souvisejicim overheadem a limitacemi - uvazujte o dictionaries s tisici zaznami - tak si je explicitne vytvorite, jedno nebo druhe, no biggie.

Biggie je, že to kurví kompatibilitu a přináší teoretickou úsporu čehosi ne úplně definovaného, kterou se to snaží vecpat každému, i když o ní vůbec nemá zájem. Py2 je v tomhle funkcionálně nadřazen py3, protože má metody které vrací jak iterátor, tak pole, kdežto py3 vrací jen tuhle ošklivku a ještě se to snaží prezentovat jako výhodu.

[little.owl]

kurvi kompatibilitu a přináší teoretickou úsporu čehosi ne úplně definovaného, kterou se to snaží vecpat každému, i když o ní vůbec nemá zájem.

Python 3 je nova revize jazyka Python a zmeny nejsou kompatibilni s prechozi radou. Python 3 je IMHO celkove lepe navrzen a takovehle procisteni jazyka jednou za par let neni na skodu. U noveho kodu neni problem a pokud 2to3 migracni tool umi +/- prevest stary kod, neni v podstate co resit, zejmena kdyz obe verze jsou dlouho soubezne podporovane.

ještě se to snaží prezentovat jako výhodu.

Ona to je vyhoda. Vytvoreni velkeho pole neni levna zalezitost a s iteratorem nemuzete delat plno veci, navic se zjednodusi iterface.

Py2 je v tomhle funkcionálně nadřazen py3

Neni, jen se nektere veci delaji jinak.

Znovu, v cem je problem explicitniho vytvoreni listu nebo iteratoru, v okamziku kdy set nestaci?

dictionary.keys() <-> list(dictionary.keys())
dictionary.iterkeys() <-> iter(dictionary.keys())

[Bystroushaak]

Python 3 je IMHO celkove lepe navrzen a takovehle procisteni jazyka jednou za par let neni na skodu.

Já si tím pomalu přestávám být jistý a čím dál víc mi přijde, že tohle splitnutí komunity za to nestálo.

U noveho kodu neni problem a pokud 2to3 migracni tool umi +/- prevest stary kod, neni v podstate co resit, zejmena kdyz obe verze jsou dlouho soubezne podporovane

Jo, ale 2to3 nepřevede mozky programátorů, speciálně ne v těhle případech, kdy se něco co perfektně fungovalo zákeřně změní.

Ona to je vyhoda. Vytvoreni velkeho pole neni levna zalezitost a s iteratorem nemuzete delat plno veci, navic se zjednodusi iterface.

Čtu: Je to výhoda pro tebe, v některých pro mě okrajových případech.

Znovu, v cem je problem explicitniho vytvoreni listu nebo iteratoru, v okamziku kdy set nestaci?

Je to otrava. S tímhle přístupem by se rovnou mohlo používat C API, protože to přece bude efektivnější.

[little.owl]

splitnutí komunity za to nestálo

Splitnuti komunity? Jake? Na Python 3 se roky hledal konsensus, nasel se a bylo jasne receno, ze to je budoucnost.

Jo, ale 2to3 nepřevede mozky programátorů, speciálně ne v těhle případech, kdy se něco co perfektně fungovalo zákeřně změní.

(a) Co je na dokumentovane zmene zakerne? (b) Prechod na Python 3 probiha vice nez patym rokem - s tim by nemel mit problem zadny mozek - proboha, kolik let bude jeste potreba zmenit nektere navyky? Tech par skutecne nekompatibilnich veci je otazka studia jednoho vikendu.

Čtu: Je to výhoda pro tebe, v některých pro mě okrajových případech.

Pokud to nekde potrebujete skutecne casto, neni lepsi se zamyslet na architekturou/designem aplikace a vytvorit vlastni class/funkci, ktera problemy nejak genericky resi, i kdyby se mely pouzivat decorators/metaclasses a podobne "dirty" techniky?

[Bystroushaak]

Splitnuti komunity? Jake? Na Python 3 se roky hledal konsensus, nasel se a bylo jasne receno, ze to je budoucnost.

Viz reddit rage z poslední doby. Že někdo něco jasně řekl ještě neznamená, že se to stane/stalo.

Co je na dokumentovane zmene zakerne?

Že je to zcela nečekané, podle mě i nesmyslné a zbytečné. Něco co skvěle fungovalo a vracelo triviální interní datovou strukturu teď vrací cosi co prakticky nikam nepasuje a musí se to konvertovat, aby to bylo co k čemu. Je to složitost, která podle mě nemá své opodstatnění. Vůbec se mi nelíbí, že půlka v py2 triviálních funkcí najednou vrací vlastní a od sebe navzájem různě odlišné objekty s různým API, místo polí, tuplů a setů.

Prechod na Python 3 probiha vice nez patym rokem - s tim by nemel mit problem zadny mozek - proboha, kolik let bude jeste potreba zmenit nektere navyky?

No a přesto i po pěti letech je majorita projektů a troufám si tvrdit i programátorů pořád na 2.7. V podstatě kdybych k tomu nebyl nucený, tak mě ani nenapadne psát to v py3 a hádám, že nejsem jediný.

Pokud to nekde potrebujete skutecne casto, neni lepsi se zamyslet na architekturou/designem aplikace a vytvorit vlastni class/funkci, ktera problemy nejak genericky resi, i kdyby se mely pouzivat decorators/metaclasses a podobne "dirty" techniky?

A pak tím zaplevelovat všechny svoje projekty, specifikovat to jako externí závislost, abych opravil jednu z nejpoužívanějších interních datových struktur. Do toho se mi ani moc nechce.

[little.owl]

Viz reddit rage z poslední doby.

Jako pri kazde zmene.

Že někdo něco jasně řekl ještě neznamená, že se to stane/stalo.

Alespon vidite, ze vyvojari Python drzi sve slovo.

a musí se to konvertovat, aby to bylo co k čemu.

Pouzitelne je to v rade pripadu i bez konverze.

odlišné objekty s různým API, místo polí, tuplů a setů

Smeruje to k set-u a vnitrni implemtace je diametralne jina.

No a přesto i po pěti letech je majorita projektů a troufám si tvrdit i programátorů pořád na 2.7.

(a) to je v kontradikci s tvrzenim, ze nekdo nekoho nuti, stejne jako dlouha podpora Python2 (2020+). (b) minimalne podle poctu stazeni zacina mit Python3 navrch (tusim od 3.3) - kdyz ho uvedli mluvili o peti letech a to celkem sedlo.

kdybych k tomu nebyl nucený

Pokud je to rozhodnuti vaseho zamestnavatele, placete na spatnem hrobe.

abych opravil jednu z nejpoužívanějších interních datových struktur

Nic neni treba opravovat, je treba to dodelat. Opravit musite programovaci navyky, ale to se tyka pripadu kazde revize jazyka.

Na muj vkus byly zmeny male, odstranil byl GIL a pridal JIT, jenze Guido van Rossum a Python jsou konzervativni.

[JS1]

Myslim, ze bych napsal:

if any(( k in dictionary for k in {'key1','key2','key3'} )): ...

[little.owl]

To neni IMHO to "lepe". Potom je nutnost psat ve vymezenych pripadech iter() ci list() jen kosmeticka zmena.

[JS1]

To neni IMHO to "lepe".

Proc? Muj nazor je, ze je to s tim v podstate srovnatelne, a tudiz si ten tvuj priklad nezaslouzi mit specialni metodu v dict().

[little.owl]

Nejde jen o tento priklad. Ale tato zmena prave redukovala specialni metody, tedy plus ne?

[JS1]

Myslim, ze uz jsem svoji pozici v teto diskusi vysvetlil dostatecne. (Krome toho to kvuli zarovnani prestava byt citelne.)

Kdyz vychazel Python 3, libilo se mi to, ale tehdy se psalo o tom, ze keys() atd. se bude chovat jako iterkeys(). Od te doby ale Python zase prilis aktivne nesleduji - zabyval jsem se jinymi jazyky.

V soucasnem chovani nevidim zadny velky prinos oproti vyse uvedenemu. I ten uvedeny priklad je dost slaby duvod. Vlastne i ten priklad s tou rovnosti se da myslim udelat lepe zpusobem, jaky jsem naznacil.

Kdyz nad tim tak premyslim, mozna by bylo v praxi uzitecnejsi, kdyby mnozinove operace umely efektivne pracovat s mnozinou a iteratorem. Pak by se to alespon dalo aplikovat obecne, a ty view by nebyly vubec potreba.

[little.owl]

Myslim, ze uz jsem svoji pozici v teto diskusi vysvetlil dostatecne.

Myslite "I tak se mi to rozhodnuti ale moc nelibi."? To jsme s Pavlixem nabidli padnejsi argumenty.

Vlastne i ten priklad s tou rovnosti se da myslim udelat lepe zpusobem, jaky jsem naznacil.

Tam uz by pripadna uspora nebyla vyrazna a sla by na ukor prehlednosti. V podstate byste rikal, ze set-y a mnozinove operace jsou k nicemu a vse udelam same lepe treba pres generatory.

kdyby mnozinove operace umely efektivne pracovat s mnozinou a iteratorem.

Ale oni umi. Jak spravne poznamenal Pavlix, ekvivalentni metody setu, narozdil od operatoru, akceptuji iteratory. U operatoru v podminkach se muze zkusit spolehat na zkracene vyhodnocovani, ktere python dela, ale ktere nemusi IMHO vzdy pracovat spolehlive. U generators/comprehensions zadna rozumna optimalizace neni a je to na programatorovi.

a ty view by nebyly vubec potreba.

View je ve sve podstate koncepcne jiny typ.

[JS1]

Predevsim, nevidim duvod, proc by keys() nemohlo byt iterator nezavisle na tom, ze je to mnozina (nebo view). Prijde mi to jako zbytecne omezeni.

To jsme s Pavlixem nabidli padnejsi argumenty.

Nepovazuji ten vas zpusob pouziti za neco prilis casteho. A uz vubec to neadresuje moji namitku ohledne items() a values().

Pokud bys neco takoveho delal casto, a chtel to rychleji, muzes si napsat helper. Sam jsi videl, ze tvoje "mnozinova" implementace byla pomalejsi. To neni neobvykla situace.

Ale oni umi. Jak spravne poznamenal Pavlix, ekvivalentni metody setu, narozdil od operatoru, akceptuji iteratory.

Tim spis je to argument proti. Navic nevidim duvod, proc nemit mnozinove operatory primo nad slovniky. To by IMHO casto bylo uzitecnejsi.

View je ve sve podstate koncepcne jiny typ.

Ano, a proto jsem proti. Jsem proti tomu, aby Python obsahoval zbytecne mnoho ruznych typu, vymenou za zrychleni v marginalnim poctu pripadu. Je na to obecne tlak, ale myslim si, ze ten jazyk dela spravne, ze tomu odolava.

Proste, neni to idealni navrh. Ale myslete si co chcete, uz se o tom nechci prit.

[little.owl]

Ano, a proto jsem proti. Jsem proti tomu, aby Python obsahoval zbytecne mnoho ruznych typu, vymenou za zrychleni v marginalnim poctu pripadu.

To mi prijde jako nejpadnejsi argument proti. Ne skutecnost, ze nekdy musim pouzit iter() ci list(). Pokud ten koncept nedopracuji, nedodelaji vsechny set operace a nebude to vice nez tupa proxy do dictionary, bez moznosti vytvoreni instance, asi to nema skutecne smysl. Podle TODO v kodu a diskuzi okolo to vedi, cas ukaze, co z toho nakonec bude.

[JS1]

Hm, 3.4 a neni to dodelane? Zrejme to nikomu zase tak moc nechybi.

Jinak ja jsem zastance Pythonu 3.

[JS1]

Respektive, takhle - ne ze by to hralo nejakou zasadni roli - ale ta moje implementace bude mirne rychlejsi, protoze ja nemusim testovat vsechny 3 klice. Ty vytvaris mnozinu pruniku, a tu pak testujes na prazdnost. Zatimco ja testuji kazdy z tech klicu jeden po druhem, a jakmile narazim na takovy, co tam je, ukoncim vyhodnoceni podminky.

[little.owl]

ale ta moje implementace bude mirne rychlejsi,

To je fakt, zejmena pro velke sety, i kdyz python ma optimalizaci empty set()/list()/dict() v podminkach. Jenze tady mate i dalsi set-ove operace, ktere potom maji trivialni notaci a zacne se to zejmena projevovat az zacnete pracovat s vice dictionaries - i kdyz tyhle operace ted nejsou optimalizovane.

[pavlix]

Mimochodem, jen takový nápad...

>>> d = {'a': 'z', 's': 'x', 'd': 'c', 'f': 'v'}
>>> s = {"key1", "key2", "key3"}
>>> not d.keys().isdisjoint(s)
False

Přičemž argumentem .isdisjoint() je libovolný iterable.

[little.owl]

To je lepsi reseni.

[JS1]

Akorat, ze to zase musi testovat vsechny 3 klice.

[little.owl]

Udelal jsem si par nereprezentativnich snidanovych testu, nez se vyjadrim.

Pro par klicu je putna co pouzijete, metodu, operator nebo generator, zejmena pokud se to neopakuje. Generators/comprehensions se interne nakonec prevedou na loop, pripadne s iterator like objektem a ten overhead pro male hodnoty je potom takovy, ze to nema prinos oproti testovani vseho. Pak bych pouzil to nejprehlednejsi a tim jsou pro me operatory. Pro vyssi pocet klicu mohou byt generatory lepsi reseni a pro ultra velky set muze byt lepsi si ten loop napsat sam.

Zalezi na operaci, pro xor uz jsou uz operator a metoda rychlejsi, naivne - mozna to lze prepsat lepe:

#1
{x for x in set1 | set2 if (x not in set1) or (x not in set2)}
#2
set1.symmetric_difference(set2)
#3
set1 ^ set2

Z duvodu prehlednosti bych opet volil to posledni. Tohle presne duvod, proc si myslim, ze dictview jako set neni az takova tragedie.

[JS1]

Dobre, ale zase, k cemu? Nebylo by proste lepsi delat ty operace primo na tech slovnicich, s tim, ze se rovnou i zachovaji ty hodnoty? Proc proste nepridat par konkretnich metod primo na ten slovnik?

Mne zkratka pripada, ze pokud nekdo potrebuje pracovat s keys() jako mnozinou, tak bud to dela jednou, a pak si to klidne muze prevest, nebo to chce nejak zpetne aplikovat na ten slovnik, a v takovem pripade si tam zase bude asi chtit nejak doplnit ty hodnoty. Ale fakt nevidim use case pro to, aby to view bylo dynamicke. To mi prijde jako zbytecny pozadavek.

(Jinak zase to lze nejspis prepsat lepe - kdyz prvek nenajdes v te prvni mnozine, uz ho nemusis hledat v te druhe.. Pointa je spis v tom, ze vsechny ty mnozinove operace se daji prepsat pres operator in nad samotnym slovnikem a iteraci pres klice, takze ten view obecne neni potreba.)

[Bystroushaak]

Souhlasím a poměrně to vystihuje to, co mi na tom taky vadí. Vážně by mě zajímalo, co si mysleli když to tam přidávali a proč okolo toho nebylo víc humbuku.

[little.owl]

proč okolo toho nebylo víc humbuku.

Humbuk okolo toho nebyl a neni to dodelane, nebot to neni zasadni problem.

[little.owl]

Nebylo by proste lepsi delat ty operace primo na tech slovnicich, s tim, ze se rovnou i zachovaji ty hodnoty?

To jako ze by dictionary mela navic interface set-u? Byl bych proti.

Jinak zase to lze nejspis prepsat lepe - kdyz prvek nenajdes v te prvni mnozine, uz ho nemusis hledat v te druhe..

Huh, znova - Python pouziva zkracene vyhodnocovani, pokud se najde v prvni mnozine, v druhe se nehleda a interne provadeji dalsi kupu optimalizaci, takze to neni tak tragicke, aby se tupe iterovalo pres vse pokud to neni nutne.

[JS1]

Ah, vlastne jsem te jeste urazil malo , protoze s tim skutecnym protiprikladem prisel little.owl.

[Sajfi]

Zase když je potřeba (někde uvnitř smyčky), může to mít smysl:

$ python2 -m timeit -n 1000000 -r 3 -s 'from copy import copy; baz = range(10)' 'bar = copy(baz)'
1000000 loops, best of 3: 0.802 usec per loop
$ python2 -m timeit -n 1000000 -r 3 -s 'baz = range(10)' 'bar = list(baz)'
1000000 loops, best of 3: 0.245 usec per loop
$ python2 -m timeit -n 1000000 -r 3 -s 'baz = range(10)' 'bar = baz[:]'
1000000 loops, best of 3: 0.104 usec per loop

$ python3 -m timeit -n 1000000 -r 3 -s 'from copy import copy; baz = range(10)' 'bar = copy(baz)'
1000000 loops, best of 3: 0.558 usec per loop
$ python3 -m timeit -n 1000000 -r 3 -s 'baz = range(10)' 'bar = list(baz)'
1000000 loops, best of 3: 0.432 usec per loop
$ python3 -m timeit -n 1000000 -r 3 -s 'baz = range(10)' 'bar = baz[:]'
1000000 loops, best of 3: 0.355 usec per loop

[pavlix]

Mě zrovna dneska python3 naštval tím vracením iterátorů ze všeho možného.

Narozdíl od Pythonu 2 to dělá vcelku konzistentně, takže zpravidla víš, co máš čekat. Jak sám píšeš dál, není problém to vylistovat, když potřebuješ.

Takhle mám na každém druhém řádku přetypovávání zpět na list

To se mi děje jen v interaktivním Pythonu, kde si potřebuju výsledky vylistovat, abych na ně viděl. Ve skriptech používám vylistování jen tam, kde seznam potřebuju.

protože autory asi nenapadlo

Možná autory nenapadlo, že si vývojáři potřebujou nutně komplikovat život.

map/filter

Máš nějaký důvod používat map/filter místo comprehentions?

comprehensions

Comprehensions v hranatých závorkách vrací seznam.

>>> [a**2 for a in range(10)]
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

.keys()

U klasických slovníků vylistování vrací seznam klíčů a neprázdnost lze kontrolovat přímo.

>>> d = {a: a**2 for a in range(10)}
>>> list(d)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> bool(d)
True

Vzhledem k tomu jak často to musím přetypovávat mi to přijde nehorázně otravné.

Show me the code!

[little.owl]

>>> bool(d)
True

Hezke!

[Bystroushaak]

Máš nějaký důvod používat map/filter místo comprehentions?

Přijde mi to přirozenější a podstatně čitelnější. U comprehentions vždy do příště zapomenu, jak udělat filter.

U klasických slovníků vylistování vrací seznam klíčů a neprázdnost lze kontrolovat přímo.

Tohle mě třeba trochu děsí:

>>> a = map(lambda x: x, [])
>>> list(a)
[]
>>> bool(a)
True
>>> d = {a for a in []}
>>> list(d)
[]
>>> bool(d)
False

Chápu, že to druhé vytváří set, ale stejně mi není jasné, proč bool nad prázdným setem funguje a nad polem ne.

Show me the code!

Bude časem blogpost, až to dodělám (což by mohlo být brzo).

[JS1]

Chápu, že to druhé vytváří set, ale stejně mi není jasné, proč bool nad prázdným setem funguje a nad polem ne.

Protoze to prvni je iterator, a ne pole? A na nem se bool() chova jinak?

Prazdnost iteratoru totiz nejde zjistit nedestruktivne.

[pavlix]

+1

Funguje jak nad prázdným setem, tak nad prázdným polem, tak nad prázdným slovníkem, jen ne nad iterátorem, který při příštím kroku skončí.

[Bystroushaak]

No, celé mi to ale přijde silně matoucí pro přecházející programátory. V podstatě to znamená, že ve chvíli kdy chci přejít na python3, tak si nemůžu být jistý, že i naprosto triviální kód bude fungovat tak jak čekám, neboť všechno možné vyhazuje iterátory a pohledy a já nevím co ještě, ale spousta funkcí s tím neumí pracovat tak, jak bych očekával po zkušenostech z py2. Zde by bylo imho naprosto logické, kdyby si bool() z toho udělal list.

[JS1]

No, celé mi to ale přijde silně matoucí pro přecházející programátory.

To, ze ma Python dynamicke typy, tudiz se nezapisuji do zdrojaku, neznamena, ze nemusis vedet, co ma kde jaky typ.

Beztak, to co chces delat je patrne bool(d) a nikoli bool(d.keys()).

[Bystroushaak]

To, ze ma Python dynamicke typy, tudiz se nezapisuji do zdrojaku, neznamena, ze nemusis vedet, co ma kde jaky typ.

Tak to já samozřejmě chápu. Problém je, pokud mám v hlavě udržovat dvě verze, které se v detailech chovají jinak, ale jinak jsou prakticky totožné. Na to moc nemám ani čas, ani náladu a akorát mi to zvedá level frustrace, který byl do téhle doby v pythonu úplně nejnižší.

[pavlix]

Beztak, to co chces delat je patrne bool(d) a nikoli bool(d.keys()).

+1

Mimochodem bojí funguje a dává stejné výsledky.

[pavlix]

No, celé mi to ale přijde silně matoucí pro přecházející programátory.

Mně přišel Python 2 matoucí mnohem víc, takže tam vidím to celkové zlepšení.

Zde by bylo imho naprosto logické, kdyby si bool() z toho udělal list.

Jakože by bool() při absenci .__bool__() používal list() a zkoušel přes objekty iterovat? To se mi nezdá jako dobrý nápad. To už je snad lepší naučit programátory si to vylistovat.

[Bystroushaak]

Jakože by bool() při absenci .__bool__() používal list() a zkoušel přes objekty iterovat? To se mi nezdá jako dobrý nápad. To už je snad lepší naučit programátory si to vylistovat.

Tohle ti v podstatě brání používat jeden idiom, který říká, že nemáš používat if len(pole) > 0:, ale if pole:.

[pavlix]

Nebrání, seznamy i slovníky bool API mají, navíc generátory typicky nemají len API.

[pavel]

Generator bez dalsiho prvku ale porad vraci True:

g=(i for i in range(10))
bool(g)  # True
list(g)  # [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
list(g)  # []
next(g)  # StopIteration exception
bool(g)  # True (!?)

[pavlix]

Proč ale? Vždyť ten generátor obecně neví, zda další prvek přijde nebo ne, proto má smysl bool API dávat jen některým objektům, které se dají iterovat.

[pavel]

Pak ale nechapu souvislost bool API s idiomem na test (ne)prazdne kolekce.

Jestli to chapu dobre, tak objekty tridy generator jsou vzdycky True a nema nad nima smysl volat fci bool(). Test na prazdnou kolekci nejde teda provadet jako u seznamu, slovniku nebo n-tice, kde [], {}, () jsou vsechny False.

Podle me ten idiom podminky if generator_exhausted: pada a bud se musi z ni ten seznam stejne vytvorit nebo se musi iteracne projit.

[pavel]

Jeste dodam, ze pro tyhle pripady by se hodila metoda nazvana treba peek, ktera by nedestruktivne vratila nasledujici hodnotu.

[JS1]

Nekde jsem to videl, a muzes si na to snadno napsat generator sam. Obali jakykoli iterator, a kdyz mu neco vratis pres send(), ulozi si to a vrati ti to zpatky pri pristi iteraci. Takze muzes destruktivne ubrat treba v normalni smycce, ale zaroven vracet do toho iteratoru, pokud se ti ta hodnota zrovna nehodi.

[pavel]

Kdyz nad tim tak dumam, on to asi nebude uplne dobry napad, protoze generatory muzou pred yieldnutim hodnoty provadet prakticky cokoliv vcetne odpaleni mezikontinentalni rakety a pak by to vraceni hodnoty pres send() bylo asi k nicemu.

[JS1]

Spis peek() se obecne pro vsechny iteratory implementovat neda, vyse popsana metoda je univerzalni (pokud ti jde predevsim o ty vracene hodnoty), ale je ano, je potreba vzit v uvahu ten caveat.

[pavlix]

Co je špatného třeba na mé implementaci níže (mimo případných triviálních chyb).

[pavlix]

To lze vcelku triviálně implementovat nad běžným iterátorem.

class peekiter:
    def __init__(self, iterable):
        self.iterator = iter(iterable)
        self.queue = []

    def __iter__(self):
        return self

    def __next__(self, *args, **kwargs):
        if self.queue:
            return self.queue.pop(0)
        return next(self.iterator, *args, **kwargs)

    def peek(self):
        item = next(self.iterator)
        self.queue.append(item)
        return item

[JS1]

Nebo tak. Mel jsem za to, ze neco podobneho je ve standardni knihovne, ale nenasel jsem to.

A mimochodem - tady ti iter() taky vraci primo ten objekt, a nikoli kopii.

[pavlix]

A mimochodem - tady ti iter() taky vraci primo ten objekt, a nikoli kopii.

Souvislost?

[pavel]

Tohle reseni je dobre ale ma jen dve drobne vady:
- neni v implementaci standardniho generatoru
- trida generatoru vytvoreneho funkci pomoci yield nelze zmenit

[pavlix]

Výše uvedené řešení lze použít nad kterýmkoliv generátorem/iterátorem, tudíž nemá ani jednu z uvedených vad.

[pavel]

Asi si nerozumime. Jak donutim, aby mi nize uvedena funkce vytvorila instanci tve tridy peekiter misto standardni generator ?

def create_generator():
   while podminka:
      res = calculate()
      yield res

my_gen = create_generator()
type(my_gen)  # <class 'generator'>
# logicky nic nebude vedet o metode peek
my_gen.peek()  # AttributeError: 'generator' object has no attribute 'peek'

[little.owl]

Jak donutim, aby mi nize uvedena funkce vytvorila instanci tve tridy peekiter misto standardni generator ?

Viz. dole, decorator.

[JS1]

Lidem musi jit ze vsech tech oratoru hlava kolem. Python, jazyk pro zacatecniky? Pche!

[pavlix]

Že bys mi dával za pravdu?

[pavlix]

Nevím v čem si nerozumíme, jasně jsem psal, že lze takto napsaný peekiter() použít nad jakýmkoli iterátorem/generátorem. Než začneš kritizovat, je dobré zkusit použít hlavu.

my_gen = peekiter(create_generator())

[pavel]

Jasne jsem psal, ze me zajima jak donutit generatorovou funkci aby pomoci yield vracela ten vas generator misto vychoziho.

Stacilo mi potvrdit, ze to nejde, ze je ta trida pro yield natvrdo zadratovana v jazyce a nelze ji zmenit.

Misto jedne instance generatoru musite vytvaret dve.

[pavlix]

Jasne jsem psal, ze me zajima jak donutit generatorovou funkci aby pomoci yield vracela ten vas generator misto vychoziho.

Psal jsem, jak docílit požadované funkcionality, sračky neřeším.

Stacilo mi potvrdit, ze to nejde, ze je ta trida pro yield natvrdo zadratovana v jazyce a nelze ji zmenit.

Jednak jsem to považoval za samozřejmé, jednak to vůbec není potřeba.

[pavel]

Jednak jsem to považoval za samozřejmé, jednak to vůbec není potřeba.

Misto aby to slo udelat primo, a nevidim jediny duvod co tomu brani, tak se musi provadet dve inicializace a udrzovat dve instance misto jedne.

Asi mame kazdy jine predstavy o efektivite a co je potreba. K racionalizaci obchazeni omezeni se ale neuchyluju.

[pavlix]

a nevidim jediny duvod co tomu brani

Za to ovšem nemůžu nést zodpovědnost. Ale jsem rád, že se ode mě u každé implementace iterátoru neočekává, že budu implementovat ještě peek cache.

[JS1]

Presne jak napsal Pavlix, muzes napsat p=peekiter(iterator) a bude se to chovat jako normalni iterator, a navic to bude umet ten peek().

[JS1]

Test na prazdnou kolekci nejde teda provadet jako u seznamu, slovniku nebo n-tice, kde [], {}, () jsou vsechny False.

Kolekce samotna nemusi byt iterator. Staci, kdyz implementuje __iter__(). Aby se chovala jako zabudovane kolekce, muze naimplementovat __bool__() tak, aby vracel False, pokud je prazdna.

[pavlix]

Pak ale nechapu souvislost bool API s idiomem na test (ne)prazdne kolekce.

Idiom na test (ne)prázdné kolekce není nic jiného než konverze na bool u objektu, který to podporuje.

[pavel]

Standardni generator ale tohle zjevne nepodporuje a pozadovanou konverzi na False pri prazdne kolekci je nutne si dopsat.

[JS1]

Duh! Samozrejme, ze to standardni generator neumi, protoze neni totez co kolekce.

[pavel]

Slovickareni. Vim ze generator neni kolekce ale hodnoty ziskavane z generatoru kolekci tvori. Myslena byla v kontextu predchoziho situace, kdy generator uz nema hodnotu k vraceni.

[JS1]

Vim ze generator neni kolekce ale hodnoty ziskavane z generatoru kolekci tvori.

Nemusi nutne, vzdyt jsi to sam psal.

[pavel]

Ale to si neodporuje - sice muzou nastat postranni efekty ale pro konzumenta generator porad vraci hodnoty ktere jsou kolekci.

[pavlix]

Nesmysl. Generátor pouze vrací jednu hodnotu za druhou a žádná kolekce ve smyslu datové struktury udržující množství hodnot k tomu není potřeba.

[pavel]

ve smyslu datové struktury udržující množství hodnot

Nevkladejte mi do ust co jsem nikdy nerekl. Diky.

[pavlix]

Nicméně pokud člověk píše v nějakém kontextu a chce stejné pojmy používat v odlišném významu, měl by na to alespoň upozornit.

[pavlix]

Tady nejde o slovíčkaření, ale chápání základních pojmů. Kolekce a iterátor mají odlišné vlastnosti.

[pavlix]

Jak velký musí být člověk masochista aby namísto triviálního testu na neprázdnost kolekce nejprve vytvořil iterátor, který už takový test nepodporuje, a pak nad ním stavěl vrstvu, která mu tu podporu přidá?

[Bystroushaak]

Například běžný autor API, který to dostane parametrem.

[pavlix]

?

[pavel]

Me prijde jako masochismus, ze si musim podobnou funkcionalitu dopisovat a neni uz standardni metodou tridy generator.
Vsude kde to budu chtit pouzit si budu muset tahat vlastni tridu a v kodu se bude michat se zakladnim generatorem, ktery se pouziva vsude jinde vcetne standardnich knihoven. Vsude kde budu obecne manipulovat s instancemi generatoru budu muset zjistovat, jestli jde o instanci tridy peekiter resp. ma definovanou metodu peek.

[little.owl]

Tak abychom si to ujasnili - generator je funkce, ktera vraci generator object, ktery implementuje interface jako iterator. Problem tedy je, ze takto vytvoreny iterator nema metodu peek(), ano? Ted se mi nad tim uz nechce premyslet, ale cesta vede pres decorator funkce generatoru, ktery vytvori novy iterator s peek(), s nejakou memoizaci. Tento novy iterator je pouzitelny kdekoliv funguje standardni iterator, takze testovani by se provadelo jen tam, kde je treba volat peek(), coz mame pod kontrolou.

Osobne si myslim, ze takovyhle telocvik u rozumne navrzeneho kodu netreba.

[pavlix]

Taky si myslím, že se tu hledají problémy, kde nejsou. Iterační API je záměrně jednoduché, aby nebyl problém ho implementovat a tvoří ho metoda .__next__(). Aby byly iterátory zároveň iterovatelné, ještě definují metodu .__iter__(), která vrací ten stejný iterátor. Pokud někdo chce iterátor s pamětí, .peek() a případně i .__bool__() (a vyřešit kolize mezi nimi), je to věc na pár řádků a může ji použít kdykoliv potřebuje mít tyto metody k dispozici.

Nevidím jediný důvod vyžadovat něco takového od implementátorů iterátorů a ani nevidím důvod, aby to uměly pythoní generátory. Od toho lze v pythonu všechno používat jako objekt s určitým API, aby si člověk mohl nástroje podle potřeby pospojovat.

Přikládám naivní implementaci obalovacího iterátoru s podporou nezávisle volaných .peek() a bool(), public domain.

class peekiter:
    def __init__(self, iterable):
        self._iterator = iter(iterable)
        self._bool_queue = []
        self._peek_queue = []

    def __iter__(self):
        return self

    def __next__(self, *args, **kwargs):
        if self._bool_queue:
            return self._bool_queue.pop(0)
        if self._peek_queue:
            return self._peek_queue.pop(0)
        return next(self._iterator, *args, **kwargs)

    def __bool__(self):
        if self._bool_queue or self._peek_queue:
            return True
        try:
            self._bool_queue.append(next(self._iterator))
            return True
        except StopIteration:
            return False

    def peek(self):
        if self._bool_queue:
            item = self._bool_queue.pop(0)
        else:
            item = next(self._iterator)
        self._peek_queue.append(item)
        return item

[pavel]

On si asi clovek zvykne na vsechno vcetne dopisovani funkcionality, ktera je jinde out-of-the-box jako Enumerator z ruby.
Dalsi vec ze takove naivni implementace muzou byt radove pomalejsi nez kdyby byly soucasti standardni knihovny a napsane v C.

[pavlix]

On si asi clovek zvykne na vsechno vcetne dopisovani funkcionality, ktera je jinde out-of-the-box jako Enumerator z ruby.

>>> for i, v in enumerate('asdf'):
...     print(i, v)
... 
0 a
1 s
2 d
3 f

Dalsi vec ze takove naivni implementace muzou byt radove pomalejsi nez kdyby byly soucasti standardni knihovny a napsane v C.

Nic ti nebrání přepsat to do C.

[pavlix]

Hádám, že ten enumerator je asi k něčemu jinému než jsem psal, ale ty examples nejsou úplně zřejmé.

[pavel]

Daval jsem odkaz na dokumentaci k cele tride generatoru v ruby, kde je mj. definovana metoda #peek kterou se tu snazite implementovat v pythonu.

Ani trida enumerate z vaseho prikladu ktery je uplne mimo, obdobu teto metody nema.

[pavlix]

Daval jsem odkaz na dokumentaci k cele tride generatoru v ruby, kde je mj. definovana metoda #peek kterou se tu snazite implementovat v pythonu.

Popravdě se o nic nesnažím. Poslal jsem dvě různé implementace iterátoru s metodou .peek(), druhá navíc uměla bool(). Ty implementace se mi zdají zcela v pořádku a podle mě by se klidně něco takového mohlo stát součástí standardní knihovny a pomoct těm, kteří něco takového potřebují. Samozřejmě si to může kdokoli vylepšit či zoptimalizovat, když bude chtít.

Ani trida enumerate z vaseho prikladu ktery je uplne mimo

K tomu už jsem se vyjádřil výše. Něco z toho kódu mi připomínalo use case pro enumerate, ale jinak je ta dokumentace z mého pohledu značně nepřehledná a není z ní na první pohled jasné, k čemu ta věc je. Prakticky všechny příklady, co tam byly vypadaly jako use case pro běžný for cyklus.

[little.owl]

Ma asi na mysli tuto metodu Enumerate:

peek → object

Returns the next object in the enumerator, but doesn’t move the internal
position forward. If the position is already at the end, StopIteration
is raised.

Kod Ruby se mi zda ve srovnani s Python pekny binec, a s ohledem na i diskuzi zde - oni pouzivaji i ve vyse uvedenem souboru mezery a i taby pro formatovani, takze kdyz si nastavite ve vim set tabstop=2 cele se to rozpadne, coz situaci je ilustruje.

[pavel]

s/Enumerate/Enumerator/

a s ohledem na i diskuzi zde - oni pouzivaji i ve vyse uvedenem souboru mezery a i taby

Michate hrusky s jablkama. Rec byla o formatovani jako soucasti syntaxe jazyka, nikoli o zdrojaku ext. knihovny. Jo michaji tam taby s mezerama, ale maximalne se "rozpadne" formatovani kdyz si tab zmensite, ale na funkcnost to nema vliv a normalne se prelozi. Na rozdil od pythonu.

[little.owl]

Rec byla o formatovani jako soucasti syntaxe jazyka,

Kouknete se nahoru, resila se tu i IDE, taby a coding standards.

nikoli o zdrojaku ext. knihovny.

enumerator.c je soucasti Ruby a stejne problemy jsou i jinde.

ale na funkcnost to nema vliv a normalne se prelozi.

Ilustruje to stav kodu Ruby - chapu ze s takovym pristupem k mezeram a tabum je Python neprekonatelny problem .

V obecne rovine si nemyslim, ze Ruby nabizi neco, z ceho by se Python mohl ucit, zejmena na poli designu jazyka, ale neminim se poustet do diskuze na tema Python versus Ruby.

[pavel]

enumerator.c je soucasti Ruby a stejne problemy jsou i jinde.

Zdojak te C knihovny ale nema zadnou souvislost s tim jak se pise v ruby, ktere ji pouzije.

Ilustruje to stav kodu Ruby - chapu ze s takovym pristupem k mezeram a tabum je Python neprekonatelny problem

Ilustrace otresneho stavu kodu v Pythonu:

find Python-3.4.1 -name '*.c' -or -name "*.h"|xargs grep -lP "^\t"|xargs egrep -l "^ "|wc -l
210

Namatkou: callbacks.c _datetimemodule.c

Hruza, co ? Vyvojari pythonu si s michanim tabu a mezer moc hlavu nelamou. Ale to jste si mohl sam overit, nez sem neco napisete.

[little.owl]

Příloha:

• gvim.png (205228 bytů)

Namatkou: callbacks.c _datetimemodule.c

210? Tak to je jeste dobre, evidentne release prochazi nejakym QA, normalne je to horsi. Kouknete se na screenshot souboru o kterych jsme tady mluvili a pochopite rozdil, mne to trochu zaskocilo a hadam, ze release kod snad bude lepsi.

[pavel]

Ono je tam toho vic a na vic radcich i v pythonnich zdrojacich. Pokud bych to mel striktne posuzovat, a ja si s tim nezacal , tak rozlisuju jen mezi korektnim s jednotnim zpusobem odsazovani a nekorektnim kde to michaji. A je jedno jestli je to spatne u 5 nebo 50 radku, melo by se to tak jako tak opravit.

[little.owl]

Rozdil je v tom, jestli se jedna o opakovanou chybu nebo sporadicky zasah. Treba Nobuyoshi Nakada se s tim evidentne podle logu dlouhodobe nepare, plno jeho kodu by neslo zarovnat ani pri velikosti tabu 4 nebo 8 a pritom patri mezi nejvetsi prispevatele do Ruby. Na stranu druhou, je to Japonec, evidentne anglicky spise negramotny, takze bych mu to i odpustil, treba i za to ze tam necpe komentare v japonstine.

[pavel]

Nezkousejte obhajovat neobhajitelne.

for f in $(find Python-3.4.1 -name '*.c' -or -name "*.h"|xargs grep -lP "^\t"|xargs grep -l "^ "); do
    printf "%04d\n" $(grep -P "^\t" $f|wc -l)
done | paste -sd+ | bc
9153

9.153 radku kodu zacinajicich tabem u zdrojaku pravdepodobne pouzivajici mezery k odsazovani

Nejpocetnejsi vyskyt tabu s michanym odsazovanim je z modulu ctypes:
pocet   cesta k souboru
radku
=====================================================================
0070    Python-3.4.1/Modules/unicodedata_db.h
0073    Python-3.4.1/Modules/_ctypes/libffi/src/moxie/ffi.c
0074    Python-3.4.1/Modules/_ctypes/libffi/src/x86/ffi.c
0076    Python-3.4.1/Modules/_ctypes/libffi/src/raw_api.c
0077    Python-3.4.1/Modules/_ctypes/libffi/src/m68k/ffi.c
0081    Python-3.4.1/Modules/_ctypes/libffi/testsuite/libffi.call/cls_pointer_stack.c
0084    Python-3.4.1/Modules/_ctypes/libffi/testsuite/libffi.call/stret_medium.c
0084    Python-3.4.1/Modules/_ctypes/libffi/testsuite/libffi.call/stret_medium2.c
0086    Python-3.4.1/Modules/_ctypes/libffi/src/frv/ffi.c
0091    Python-3.4.1/Modules/_ctypes/libffi/src/alpha/ffi.c
0093    Python-3.4.1/Modules/_ctypes/libffi/src/m32r/ffi.c
0100    Python-3.4.1/Modules/_ctypes/libffi/src/java_raw_api.c
0102    Python-3.4.1/Modules/_ctypes/libffi/testsuite/libffi.call/stret_large.c
0105    Python-3.4.1/Modules/_ctypes/libffi_osx/ffi.c
0105    Python-3.4.1/Modules/_ctypes/libffi/testsuite/libffi.call/stret_large2.c
0123    Python-3.4.1/Modules/_ctypes/libffi/src/cris/ffi.c
0132    Python-3.4.1/Modules/_ctypes/libffi/src/arm/ffi.c
0168    Python-3.4.1/Modules/_ctypes/libffi/src/sh64/ffi.c
0195    Python-3.4.1/Modules/_ctypes/libffi/src/metag/ffi.c
0226    Python-3.4.1/Modules/_ctypes/libffi/src/ia64/ffi.c
0229    Python-3.4.1/Modules/_ctypes/libffi/src/pa/ffi.c
0233    Python-3.4.1/Modules/_ctypes/libffi/src/microblaze/ffi.c
0246    Python-3.4.1/Modules/_ctypes/libffi/src/sparc/ffi.c
0260    Python-3.4.1/Modules/_ctypes/libffi/src/x86/ffi64.c
0265    Python-3.4.1/Modules/_ctypes/libffi/src/s390/ffi.c
0276    Python-3.4.1/Modules/_ctypes/libffi/src/aarch64/ffi.c
0291    Python-3.4.1/Modules/_ctypes/libffi/src/mips/ffi.c
0296    Python-3.4.1/Modules/_ctypes/libffi/testsuite/libffi.call/huge_struct.c
0307    Python-3.4.1/Modules/_ctypes/libffi/src/sh/ffi.c
0503    Python-3.4.1/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c
0532    Python-3.4.1/Modules/_ctypes/libffi_osx/x86/x86-ffi64.c
0694    Python-3.4.1/Modules/_ctypes/libffi/src/powerpc/ffi.c
1211    Python-3.4.1/Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c

To je vsechno jen ne sporadicky zasah

[little.owl]

Vy jste nezmar .

To je vsechno jen ne sporadicky zasah

To je tak kdyz nekdo dela analyzu a nezamysli se nad vysledky. Modul v Python-3.4.1/Modules/_ctypes/libffi/ pochazi od treti strany, a ano, je to nekonzistentni bordel. IMHO ho pouziva i samotna Ruby, i kdyz tam to nenapadne zapadne. Soubor unicodedata_db.h je strojove generovany skryptem a podle vseho u generatoru jednoho pole static const change_record change_records_3_2_0[] udelali a do generovane kodu dali vyjmecne taby.

Ja znam kod Pythonu, a troufam si tvrdit, po nahledu do kodu Ruby, ze tam to bude mnohem mnohem horsi - fakticky je to jeden z nejhorsich projektu co jsem v posledni dobe videl.

[little.owl]

Hmm, aha, vas skrypt:

for f in $(find ruby-2.1.2 -name '*.c' -or -name "*.h"|xargs grep -lP "^\t"|xargs grep -l "^ "); do printf "%04d\n" $(grep -P "^\t" $f|wc -l); done | paste -sd+ | bc

94846

Uz toho mereni ******** nechme.

[little.owl]

Neda mi to, vcera vecer jsem si totiz cisla pro jednotlive soubory nakonec take vygeneroval, ale uz jsem nemel vubec naladu se na to podivat. Ale ted je rano a situace u snidane je diametralne jina! Chvili.

Pokud se budeme bavit o klicovych komponentach, tak nejvetsi binec z hlediska poctu radku je u Ruby (ruby-2.1.2) v parse.c (5465 z 18067, uz zmrseny yacc), compile.c (3537 z 5950), string.c (2478 z 8927), win32/win32.c (2447 z 7132), io.c (1818 z 12203), gc.c (1800 z 7564) a dalsi. Je to temer vsude vsude, rozhazene po celych souborech, dusledek mnoha commitu.

U Pythonu (Python-3.4.1) v klicovych komponentach to je Parser/parser.h (10 z 42 - tri struktury), Python/dup2.c (9 z 31 - jedna funkce), Modules/_weakref.c (9 z 158 - jedna struktura), Python/strdup.c (6 z 14 - jedna funkce), Modules/_io/_iomodule.c (6 z 770 - zarovnani parametru jedne funkce), Modules/_datetimemodule.c (6 z 5616 - zarovnani parametru nekolika funkci). Radove jina cisla, vetsinou vse soustredeno do jednoho mista, jedne funkce, struktury, pole, spise jednorazovy zasah nejakeho aktivisty.

[little.owl]

Jazyk, ktery implementuje metody, ktere potrebujete jednou za uhersky rok, si dlouhodobe koleduje o problemy. Python pouzivam jiz od verze 1.5, jazyk se postupne meni - dnes vypada v podstate jinak - a tohle me nikdy nepalilo. Pokud to bude chybet, tak to casem pridaji.

[JS1]

Prijde mi, ze se snazis predevsim presvedcit sebe, jak je Python spatny.

To co dela ten Enumerator jsem z toho popisu nepochopil, Ruby neznam. Mozna bys to mohl lepe vysvetlit.

Ale troufam si tvrdit, ze Python ma podobnou funkcionalitu, nebo si ji aspon muzes snadno dodat, jak ukazuje Pavlix - neni vubec tezke najit podobny kod na Internetu.

[pavel]

Prijde mi, ze se snazis predevsim presvedcit sebe, jak je Python spatny.

To je omyl, jen me stve nekriticky obdiv k cemukoliv. Delal jsem na vic nez desitce projektu postavenych nad pythonem 2 a narazil na limity a urcitou koncepcni roztristenost, ktere me stvaly a zchladily moje puvodni nadseni. Stavely se mezi napad a jeho implementaci a musel jsem navic vymyslet jak to obejit, udelat jinak. Ruby se mi do cesty tolik nestavi, ale zase ma jine mouchy. O pythonu 3 uz takovy prehled nemam a nebyl jsem si jisty co vsechno tam vylepsili a jak.

To co dela ten Enumerator jsem z toho popisu nepochopil, Ruby neznam. Mozna bys to mohl lepe vysvetlit.

. Trida Enumerator vytvari instanci generatoru podobnou tomu pythonnimu, s nekterymi sikovnymi featurami navic jako nahleduti nebo vlozeni nasledujici hodnoty, reset generatoru, pocet prvku, iterace s indexem a killer featuru - verzi generatoru s linym vyhodnocovanim. Na rozdil od pythonu ho umoznuje a jakoukoli jinou tridu modifikovat nebo z ni primo odvozovat vlastni.

Ale troufam si tvrdit, ze Python ma podobnou funkcionalitu, nebo si ji aspon muzes snadno dodat, jak ukazuje Pavlix - neni vubec tezke najit podobny kod na Internetu.

Muzu, vzdyt je turingove kompletni. A nekdy to jde primo a snadno, nekdy se to musi resit zbytecne komplikovane. Jde jen o to, jestli ta namaha a cas kterou tim stravim bude umerna ocekavanemuvysledku.

[pavlix]

To je omyl, jen me stve nekriticky obdiv k cemukoliv.

Zvláštní, že jsi zatím jediný člověk v diskuzi, u kterého jsem získal dojem, že takový nekritický obdiv brání.

Trida Enumerator vytvari instanci generatoru podobnou tomu pythonnimu, s nekterymi sikovnymi featurami navic jako nahleduti nebo vlozeni nasledujici hodnoty, reset generatoru, pocet prvku, iterace s indexem a killer featuru - verzi generatoru s linym vyhodnocovanim.

Hezké vysvětlení, teď se alespoň máme o čem bavit. Mám dojem, že se jedná o funkcionalitu, jejíž podmnožinu jsem zde ukazoval v Pythonu.

Na rozdil od pythonu ho umoznuje a jakoukoli jinou tridu modifikovat nebo z ni primo odvozovat vlastni.

Parse error. Bylo by dobré přesně specifikovat, co z toho v Pythonu nejde implementovat a proč. Zatím mám dojem, že je Enumerator věc plně reimplementovatelná v Pythonu a zjevně by z toho bylo v některých případech užitečné rozšíření.

[Bystroushaak]

Protoze to prvni je iterator, a ne pole? A na nem se bool() chova jinak?

Ah, pravda. Ta diskuze se tu tak rozpukla, že začínám ztrácet přehled.

[Josef Kufner]

[...], kdy se hloubka vnoření označovala příslušným počtem teček na začátku řádku. Sice taky žádný zázrak, ale na první pohled bylo vidět, kde člověk je.

Zkoušel jsi v Pythonu odsazovat tabem a v editoru si zapnout jeho zobrazování? Většinou to pak dělá právě takovou pěknou tečku

[FrostyX]

Ano, jenže dle PEP 8 by se měli používat mezery. Python miluju, ale tohle mě neskutečně štve.

[kralyk z abclinuxu]

+1 ty mezery bych nepřekousl...

[JS1]

Proc nedas na moji radu a nezapnes si v editoru mezery misto tabu? PEP 8 se nazere a funkcionalita editoru zustane cela..

[kralyk z abclinuxu]

S nastavením editoru problém není, to já si to nastavim, když po mě někdo ty mezery chce. Ale vadí mi to rozhodnutí jako takové, když už jednou máme bajt specielně vyhrazený na odsazování, tak nepoužít ho mi přijde podobné jako nepoužívat třeba písmeno A...

Bohužel, už i v Rustu doporučují čtyři mezery :-/

[JS]

To bude asi tim, ze povazuji znak TAB tak trochu za historicky omyl. Podobne jako vetsinu ostatnich ridicich znaku. Predevsim je problematicka ta graficka nerozlisitelnost od mezery.

[kralyk z abclinuxu]

Predevsim je problematicka ta graficka nerozlisitelnost od mezery.

To mi není jasný, v čem ta problematičnost spočívá - když odsazuju taby, tak vím, že tam jsou taby Případně přinejhorším to editory umí vizualizovat...

[egg]

Problematické je spíš to, že tab nemá obecně standardizovanou šířku.

[kralyk z abclinuxu]

No to mi přijde právě jako výhoda, že si můžeš v editoru nastavit šíři odszení jaká ti vyhovuje, ale obsah souboru se přitom vůbec nemusí změnit.

Když potřebuješ kus textu odsadit asolutně (třeba rozdělit na dva řádky volání funkce s dlouhým seznamem parametrů), tak se pro odsazení bloku použijí taby a pro zbytek odsazení mezery. To je imho bez problému...

[Hans1024]

To ja jsem mel nastavenou sirku tabu na 4 znaky, ale pak jsem chtel s takto nastavenym editorem cist zdrojaky s takovym tim "genialnim" odsazovanim, ktere kombinuje taby a mezery (pouziva ho napr. GNU style). Takze jsem se nakonec smiril s tim, ze tab ma proste 8 znaku a kdyz chci odsazovat ctyrmi, pouziju mezery.

[pavlix]

No to mi přijde právě jako výhoda

Osobně taky rád považuju jeden kus odsazení za jednu entitu, ideálně realizovanou jedním znakem. Asi bylo praktičtější na to zneužít zavedený TAB (ač je jeho účelem zarovnání, nikoliv odsazení) než vymýšlet znak nový. Na druhou stranu to nepovažuju za nijak důležité, u nových projektů dodržuju mezerový standard, u stávajících projektů samozřejmě standard daného projektu.

Co mi přijde mnohem horší, je že si někteří vymysleli pravidla, že se kód bude nejen odsazovat, což je nezbytné pro elementární čitelnost a u Pythonu to je navíc součástí syntaxe, ale i zarovnávat, což mi přijde fajn jen v případě, že se jedná o vedlejší efekt odsazení, jinak to považuju za věc úchylnou a škodlivou.

Paradoxně se pak k zarovnávání používají mezery (protože TABy ve své primární funkci selhávají) a na odsazování TABy. Navíc se na jednom řádku sejde i odsazení i zarovnání, čímž pádem je nutné dodržovat správný počet obou dvou typů znaků (což pravidla některých projektů nedodržují a to stejné platí i pro logiku některých editorů). V případě nedodržení správného počtu obou typů znaků dochází k rozházení kódu už při zobrazení v závislosti na konfiguraci velikosti TABu v editoru.

Já osobně jsem vyrostl převážně na open source a VCS, později jsem se dostal k patchům, takže považuju minimalizaci změn za naprosto klíčovou. Změna logiky programu nebo dat v textovém formátu by z tohoto pohledu měla vždy zasahovat do minimálního počtu řádků, kterých se změna přímo netýká. Zarovnávání kódu tomuto přímo odporuje. To stejné platí pro různé oddělovače, které se týkají víceřádkových konstrukcí.

Příklad:

int
moje_funkce(int a,
            int b,
            int c)
{
        return a + b + c;
}

Přejmenování funkce:

@@ -1,7 +1,7 @@
 int
-moje_funkce(int a,
-            int b,
-            int c)
+tvoje_funkce(int a,
+             int b,
+             int c)
 {
        return a + b + c;
 }

Skutečná změna v jediném řádku může způsobit kosmetickou změnu hned v několika řádcích.

[kralyk z abclinuxu]

protože TABy ve své primární funkci selhávají

Historická vsuvka: Tab sloužil původně k posunu na následující tab stop... I dnešní emulátory terminálu většinou podporují nastavování tab stopů, ačkoli to nikdo nepoužívá (viz sekvence \eH a spol.). Čili používání tabu na zarovnání v textových souborech není o nic menší zneužití než odsazování, naopak, spíš větší, protože spoléhá na default nastavení pocházející z DEC VT terminálů nebo buhví odkud...

Změna logiky programu nebo dat v textovém formátu by z tohoto pohledu měla vždy zasahovat do minimálního počtu řádků, kterých se změna přímo netýká. Zarovnávání kódu tomuto přímo odporuje.

Workaround: diff -w

Horší jsou jazyky, kde výčet položek (v poli, v objektu apod.) nesmí končit čárkou (búno oddělovačem), takže když přidáš nějakou novou položku/y na konec, předchozí řádek se zcela zbytečně musí změnit.

[pavlix]

Čili používání tabu na zarovnání v textových souborech není o nic menší zneužití než odsazování, naopak, spíš větší

Chápu to správně, že jenom potvrzuješ, co jsem výše napsal?

Workaround: diff -w

Nesmysl, to by vytvořilo špatný patch.

Horší jsou jazyky, kde výčet položek (v poli, v objektu apod.) nesmí končit čárkou (búno oddělovačem)

O tom jsem psal hned v další větě.

[Josef Kufner]

diff -w je na prohlížení. Vytvořit se samozřejmě musí správně i s mezerami. Ale stejně to působí zbytečné konflikty.

[pavlix]

Nástrojů na prohlížení rozdílů je samozřejmě celá řada a mnohé z nich umí zohlednit i rozdíly v rámci jinak stejného řádku, mnohé umí vyrobit hezké barvičky a mnohé dokážou interaktivně zpřístupnit kontext podle potřeby člověka. Když říkám, že chci vyrobit patch, tak se to mezi vývojáři zpravidla chápe tak, že vyrábím soubor určení k aplikaci na strom zdrojových kódů, například programem patch. Že může často druhá strana ten patch přečíst a pochopit jej i bez zbytku zdrojového kódu je jedna z příjemných vlastností kontextových patchů.

[Josef Kufner]

Jo, u samostatného patche se s tím nic moc dělat nedá. Já měl na mysli například zobrazení commitu v gitu, kde -w funguje.

[mirec]

Elastics tabstops, implementačne to nie je až tak zložité ale akosi editory podporujúce niečo také chýbajú.

[pavlix]

Tak já osobně bych je ani nepotřeboval, celé to je o tom, že mě obtěžují lidé, kteří potřebují mít kód nejen odsazený, ale i zarovnaný. Osobně si myslím, že by si měli zajistit editor, který ten kód umí zobrazit přesně podle jejich představ a neotravovat. Ale to je utopie.

[Michal Kubeček]

Když se člověk živí zkoumáním a opravováním cizího kódu, tak se na to časem začne dívat jinak. Ze začátku mi striktní coding style, který vyžaduje David Miller v síťovém subsystému linuxového jádra připadal jako přehnané puntíčkářství, ale teď už jsem za něj vděčný - a to hlavně když musím pracovat s kódem, kde tak přísná štábní kultura nepanuje.

[pavlix]

Z toho, co jsem výše psal, by mělo být zřejmé, že bych preferoval maximálně přísný coding style, ale právě kvůli zarovnávačům jsem na něj musel rezignovat. Živím se zkoumáním a opravováním cizího kódu jen dva roky, takže budu rád, když mi předpovíš můj budoucí názor.

[Jindřich Makovička]

Pokud jde o diff versus whitespace, třeba v MPlayeru dodržovali striktní politiku "v diffu pouze funkční změny, žádné kosmetické úpravy", nicméně přinejmenším můj dojem byl, že to kód postupem času hrozně prasí.

[pavlix]

Uváděl jsem příklad, kde to není vůbec věcí politiky.

[Jendа]

To mi přijde naopak jako výhoda, protože jsou lidi, kteří chtějí mít odsazení velké jako 8 znaků, a kteří chtějí jen 4 nebo 2. Když se tam naprasí mezery, tak se to musí složitě konvertovat, když tam jsou taby, tak si jenom změní renderování v editoru.

[little.owl]

Naopak, to je dobre. Tab je odvozen od tabulate a to je IMHO k cemu se to historicky pouzivalo - formatovani textovych tabulek na mechanickych psacich strojich (sirka sla nastavit), a pozdeji i na ruznych terminalech a displayich - a pak se skutecnost, ze to neni pevne dane, hodi. Netreba zapominat, ze mame i vertical tab.

Tab je tab, a mezery jsou mezery a pokud nekdo nerad taby, tak at si nastavi v editoru jejich expanzi a zbytek uhlida treba coding standard.

[Jendа]

Predevsim je problematicka ta graficka nerozlisitelnost od mezery.

To je problém i s mezerou, ta třeba není vidět, když je na konci řádku.

[Marvin]

Příloha:

• code.png (25749 bytů)

Predevsim je problematicka ta graficka nerozlisitelnost od mezery.

To zalezi dost na tom jestli mas inteligentni editor.

Ja mam treba ve vimu nastavy zobrazeni tabu jako roury ('|') a prvni mezeru za tabem mam jinou barvou. Tim jasne vidim kde me pokracuje radek. Viz obrazek v priloze. (btw. license GPL kdyby to nekdo chtel pouzit )

[Bystroushaak]

Příloha:

• taby_mezery.png (5090 bytů)

To mi teda přijde docela divoké. Mě to vyhovuje tak, jak to umí Sublime a většina ostatních editorů.

[Marvin]

Je me jasny ze je to dost o zvyku, ale myslim ze ty vertikalni cary co tam mam ja jsou prehlednejsi ze ty horizontalni co mas ty

[pavlix]

Osobně používám:

set list listchars=tab:»·,trail:·

[Josef Kufner]

Jediná rozumná věta v té kapitole je, že se to nemá míchat.

[FrostyX]

Já s tebou souhlasím a proto tu kapitolu vesele ignoruji a ve svých projektech odsazuji pomocí tabů.

[Bystroushaak]

Já jsem to dělal taky, ale vzbudilo to nemalé otázky ohledně coding style při pracovním pohovorou.

[mirec]

V editore mám nastavené kontrolovanie pomocou pylint (občas trochu ukecaný tak zvyknem niektoré drobnosti umlčať a občas si dopíšem nejaké transformácie pre astroid) a PEP 8. Z tých rôznych pravidiel je práve tabulátor ktorý porušujem, zvyšok takmer bez vhýhrady dodržiavm. Pravdu povediac nechápem nenávisť niektorých ľudí voči tabom. Na druhej strane python je voči tomu fakt tolerantný na rozdiel od takého YAML kde je vnútené používanie 2 medzier.

[FrostyX]

Jsem rád, že tu je někdo stejného názoru jako já. Když jsem se na #python nejak zmínil, že používám tab, myslel jsem že mě nechají shořet na hranici ...

[JS1]

Neni treba nikoho upalovat, spalite se jednou sami. Existuje dost editoru (tusim mi to delal treba Eclipse), ktere maji tendenci michat taby a mezery prazvlastnimi zpusoby. Ten pozadavek v tom PEP 8 neni pro srandu kralykum.

[mirec]

To je už vecou editorov že robia bordel. Jednoducho na centrálnom repozitári nechám prebehnúť pushnuté zdrojáky kontrolou a ak neprejdú tak jednoducho opraviť a git commit --amend.

[Marvin]

Existuje dost editoru (tusim mi to delal treba Eclipse), ktere maji tendenci michat taby a mezery prazvlastnimi zpusoby.

Doporucoval bych poslat bug report / prestat editor pouzivat.

[kralyk z abclinuxu]

To se takhle sešla skupina lidí, kteří chtěli vytvořit IDE, ale bohužel dostali naprosté zatmění mysli. A tak vzniklo Eclipse.

[JS1]

Nerikam, ze ne. Ale tu zkusenost s rozhozenym zdrojakem jsem udelal uz kdysi davno (bude to vic nez 10 let).

[j]

Ne vzdy mas k dizpozici editor, ktery s taby umi nejak normalne nakladat. A to je presne duvod toho, proc se spousta lidi snazi taby eliminovat. Dalsim duvodem je to, ze pokud prohlasim ze odsazeni jsou ctyri mezery, tak vsichni vedi ze to sou ctyri mezery ... kdyz necham odsazeni v tabech, tak mi nekdo odsadi o dva, protoze ma nastaveno ze tab jsou 2 znaky, jinej o jeden, protoze ma nastaveno ze tab sou 4 znaky ...

Dtto zobrazeni kodu - s mezerama ho zobrazej vsechny editory +- stejne.

[:::]

Ne vzdy mas k dizpozici editor, ktery s taby umi nejak normalne nakladat.

Nevim jestli ma smysl celorocni sebemrskactvi s mezerama jenom proto ze jednou za rok mozna budu muset neco editovat v nejakym nedodelanym editoru...

Dalsim duvodem je to, ze pokud prohlasim ze odsazeni jsou ctyri mezery, tak vsichni vedi ze to sou ctyri mezery ... kdyz necham odsazeni v tabech, tak mi nekdo odsadi o dva, protoze ma nastaveno ze tab jsou 2 znaky, jinej o jeden, protoze ma nastaveno ze tab sou 4 znaky ...

Jednoduse nadefinuju odsazeni == 1 tab a kdo to udela spatne tak si to po sobe opravi

Dtto zobrazeni kodu - s mezerama ho zobrazej vsechny editory +- stejne.

To je podle me prave nevyhoda. Napr. pro me je kod s odsazenim 2 velice spatne citelnej. Odsazeni 4 je na hrane a 8 je akroat. Nekdo treba radsi pouziva 4. Kdyz pouzivas taby tak si to kazdej muze zobrazit jak mu to vyhovuje.

[pavlix]

Pokud máš dobrý editor, mohl by zvládnout zobrazit i zdroják odsazený mezerami způsobem, který ti vyhovuje.

[FrostyX]

To mi přijde jako ... "Odsazovat pomocí tabů je moc jednoduché, co kdybychom to udělali tak, že budeme odsazovat pomocí mezer a nastavíme si prostředí tak, aby se chovalo úplně přesně, jako bychom použili taby"

[FrostyX]

Ale samozřejmě je to k nezaplacení ve chvíli, kdy se chci připojit k existujícímu projektu, používajícímu mezery.

[Bystroushaak]

Což bude v pythonu každý druhý, protože PEP8.

[kralyk z abclinuxu]

+1

[pavlix]

co kdybychom to udělali tak, že budeme odsazovat pomocí mezer a nastavíme si prostředí tak, aby se chovalo úplně přesně, jako bychom použili taby

Jen tato část platí a v současné situaci, kdy se na různé projekty používá obojí odsazení to považuju za maximálně užitečné.

[j]

Vetsina celorocne neprovozuje one man show abych si mohli moc vybirat, a rozhodne se nehodlaji dohadovat se 150+ lidma na tema rozhazenych zdrojaku. A totez samo plati v pripade, ze nekam poslu 1radkovy patch a nekdo mi zacne vycitat, ze si mam opravit taby/mezery ... tak ho poslu presne tak, kam nalezi a uz tam vzivote nic nepostnu.

Mimochodem, jestli je pro tebe odsazeni 8 "tak akorat", tak to koncis nekde u 3ti urovne vnoreni, protoze pak uz ti to vytece z monitoru.

[Marvin]

Mimochodem, jestli je pro tebe odsazeni 8 "tak akorat", tak to koncis nekde u 3ti urovne vnoreni, protoze pak uz ti to vytece z monitoru.

Ono je totiz vetsinou lepsi skoncit u 3 urovne vnoreni

Zkousel jsem grep jednoho rozdelanyho programu:

pocet radku: 3797

1 tab: 1024 (zajimavy kulaty cislo )

2 taby: 1120

3 taby: 343

4 taby: 126

5 tabu: 21

6 tabu: 2

7 a vic tabu: 0

[mirec]

Kód: 5897

1 tab: 1653
2 taby: 1856
3 taby: 752
4 taby: 178
5 tabov: 41
6 tabov: 13
7 tabov: 5
8 a viacej tabov: 0

(áno som prasa)

[Marvin]

Příloha:

• indent.png (20170 bytů)

Udelal jsem graf ktery zobrazuje kolik procent radku ma urcity odsazeni a vyslo nam to skoro stejne

[mirec]

8 je tak akurát??? Ah jaj všetci predsa vedia že správna šírka je e*šírka písmena e. Keďže väčšina editorov sa nedá rozumne dokopať k tomu aby zobrazovala šírku odsadenia takú aká má ideálne byť je tu možnosť alternatívne používať odsadenie 3 medzerami. No ehm a keďže väčšina programátorov sú idioti ktorí nevedia doceniť šírku 3 medzier musel som prejsť nútene na taby (nie že by neprotestovali pri nich, ale je to výrazne viacej v pohode než 3 medzery )

[Field]

No vidíte, a do editoru je to dobastlené právě proto, že to chybí v návrhu jazyka. Kdyby to bylo řešené nějak rozumně, tak by nebylo potřeba používat tyhle obezličky.

[JS1]

IMHO ty tecky v editoru se hodi skoro u vsech jazyku. Ale kdyz uz o tom mluvime, me zase vadi zarovnavani v Lispu, ktere je nepravidelne a zavisi na delce prvniho symbolu formy.

[FrostyX]

Jestli ho náhodou nemáš rád právě proto, že jsme v něm nikdy neřešili žádnou úlohu z reálného světa (Což je imho nereálné).

[Kaiten]

true, false, and, or vs True, False, and, or

[pavlix]

Zdůvodnění?

[pta]

Ja na Pythonu "miloval" nekonzistenci mezi zakladnimi tridami a odvozenymi:

> type(doit)
<type 'function'>
> object.reflect = doit
TypeError: can't set attributes of built-in/extension type 'object'
> class MyClass(object):
>   pass
> MyClass.reflect = doit
> MyClass.reflect
<unbound method MyClass.reflect>

nebo nepodpora uzaver (nested scoping):

> def outer():
>   x = 0
>   def inner():
>     x = x +1
>     return x
>   return inner
> clos = outer()
> clos()
UnboundLocalError: local variable 'x' referenced before assignment

Sice to jde obejit napsanim dekoratoru, referenci na prvek seznamu nebo v Pythonu 3 nove pridanym keywordem nonlocal, ale prijde mi to jako drbani se levou rukou za pravym uchem.

[pavlix]

Ja na Pythonu "miloval" nekonzistenci mezi zakladnimi tridami a odvozenymi:

Chápu, že to překvapí, ale jedná se o optimalizaci, jejímž důsledkům se člověk vyhne tím, že nebude očekávat, že může instancím libovolných vestavěných či knihovních tříd volně přidávat atributy.

nebo nepodpora uzaver (nested scoping):

Co konkrétně není podporováno? Co je účelem ukázky kódu výše?

Sice to jde obejit napsanim dekoratoru, referenci na prvek seznamu nebo v Pythonu 3 nove pridanym keywordem nonlocal, ale prijde mi to jako drbani se levou rukou za pravym uchem.

V čem se funkčně liší následující ukázka od požadovaného výsledku?

def outer():
  y = 0
  def inner():
    x = y + 1
    return x
  return inner
clos = outer()
clos()

[pavlix]

V čem se funkčně liší následující ukázka od požadovaného výsledku?

Tedy kromě výsledků opakovaného volání, ale to v příkladu není.

[pta]

Chápu, že to překvapí, ale jedná se o optimalizaci

Hmm, tak ze to je nekonzistentni. Omlouva se to optimalizaci. Zajimavy ze srovnatelne Ruby timhle omezenim netrpi.

Co konkrétně není podporováno? Co je účelem ukázky kódu výše?

Vazne je potreba tak hluboko klesat ? uzavery a PEP #3104

[pavlix]

Hmm, tak ze to je nekonzistentni.

Není, jen musí člověk chápat logiku kódu.

Omlouva se to optimalizaci.

Nepoužití slovníku u pythoních objektů je optimalizace a je k dispozici každému i u jeho vlastních tříd. Lze argumentovat zda je ta optimalizace užiteční či nikoliv, ale argument, že Ruby takovou optimalizaci nepoužívá mi přijde mimo mísu.

Vazne je potreba tak hluboko klesat?

Jen jsem se ptal, co konkrétně Python nepodporuje a ideálně bych se držel jen nejnovější verze Pythonu, pokud jde o obecné tvrzení, že Python něco neumí.

[pavlix]

nove pridanym keywordem nonlocal, ale prijde mi to jako drbani se levou rukou za pravym uchem.

Vzhledem k tomu, že Python zapisuje do lokálních proměnných, pokud programátor neřekne jinak, přijde mi nonlocal jako správná cesta. Dokonce mi to snad i přijde robustnější než aby místo zápisu odvozoval od existence nelokální proměnné.

[little.owl]

Tohle je problem u jazyku umoznujici definovat funkci ve funkci, pripadne jak zapouzdrit closure, proste u nested scope. Python to neresi spatne, lepsi nez nutnost psat let/my/var/etc.

[pavlix]

Mně osobně Pythoní řešení taky vcelku vyhovuje, alespoň od chvíle, co jsem se ho naučil správně používat.

[JS1]

Lide se tu ptali na Matlab a Mathematicu, nedavno jsem narazil na tyto dva clanky, kde autor rozebira interaktivni systemy pro programovani, treba IPython.