Python - dobré rady a praktiky

[hawran diskuse]

... Není rozdíl v tom, když vám chyby vyhodí překladač a když chyby vyhodí runtime. Chyba je chyba a je jedno v kterém kroku se na ni přijde...

?

[Reklama]

[Mirek Prýmek]

To je velmi odvážné tvrzení. Haskellovská syntaxe je úsporná, ale obliba infixových funkcí trochu připomíná jazyky typu J a transformátory monád apod. spolehlivě vylámou zuby 99% běžných programátorů.

Taky mi to přijde jako docela odvážné (a subjektivní), ale úplná hloupost to není. Připomínky k tomu, co jsi napsal:

Infixy by se měly používat právě tam, kde čitelnost zvyšují (7 `div` 3 místo (div 7 3)  ). A mj. umí zvýšit čitelnost i právě u těch monád. V Elmu:

Kód: [Vybrat]

toInt rawString `andThen` toValidMonth

- andThen je bind operator.

S monádami to je nefér argument ze dvou důvodů:
1. je to konstrukce, kterou Python nemá, takže nemůžeš říct, že má Python lepší syntaxi. Kdyby monády měl, byla by ta syntaxe +/- stejná.
2. Elm dobře ukazuje, jak se dá haskellovská syntaxe zlidštit jenom vhodnou volbou názvů (!) Nemusíš lidi trápit povídáním o skládání funktorů, aby se v tom utopili. Prostě jim řekneš, že se udělá asynchronní akce a a potom akce b. Hotovo dvacet, většině programátorů to bude stačit. Koneckonců promisy v JS jsou taky monády a neřekl bych, že by někdo měl problém napsat .done(...)

klidně věřím, že pro někoho je Haskell z nějakého důvodu pro někoho přirozenější.

Žádný jazyk není "přirozený". Vždycky je to nějaký formalismus, který se musíš naučit.

[Mirek Prýmek]

V každém "deklarativním" jazyku je chybu težší odhalit, protože odvozovací pravidla generují vlastní jazyk a vyřešit úlohu, zda generovaný jazyk, odpovídá konkrétnímu jazyku a zamýšlenému účelu, je dosti náročné

To je samozřejmě opět úplný nesmysl.

[gamer]

Není rozdíl v tom, když vám chyby vyhodí překladač a když chyby vyhodí runtime. Chyba je chyba a je jedno v kterém kroku se na ni přijde. Jedno to nebylo před 30 lety, kdy byl strojový čas drahý.

To vysvětluj zákazníkovi, že je jedno, ve kterém kroku se na chybu přidje, takže když se projeví až u něj, je to v pořádku, protože stojový čas je levný. Nebo adminovi, kterému to o půlnoci v produkci spadne, neví co s tím má dělat a je z toho na prášky, protože každá minuta nedostupnosti stojí dost peněz a když nebude dostupnost 99.9%  nebudou prémie.

[Mirek Prýmek]

Dnes by výběr byl těžší, ale není i tak logické primárně hledat mezi nejpopulárnějšími jazyky, které se nemění za pochodu jako Rust, neobsahují podivná pravidla pro porovnávání identifikátorů jako Nim nebo nerezignují na generika jenom proto, že vývojáři nevědí, jak je naimplementovat, jako Go? Není logické pokukovat po jazyce, který má hned po instalaci k dispozici spoustu knihoven a neinstaluje do systému půl gigabajtu jako jazyky běžící pod Mono? Kromě toho, co jsem už napsal, samozřejmě.

Pokud bych hledal podle těchto kritérií a chtěl bych relativně mainstreamový jazyk, šel bych nejspíš do Scaly, ta mi přijde jako docela rozumný kompromis. A hned jako první bych samozřejmě pak zvažoval Akka, ale to je moje osobní inklinace, to přiznávám bez mučení

Tvoje volání Pythonu přes sockety mě dost děsí. To to nejde jinak? Julia to třeba umí docela elegantně.

No obecně máš na výběr jenom dvě možnosti:

• ten "dceřinný" jazyk nějak k tomu mateřskému přikompiluješ
• komunikuješ s ním přes nějaké API (sockety, RPC, REST,...)

V Erlangu/Elixiru jde použít oboje, ale to první přináší riziko, že chyba v lepidlu shodí celý Erlang VM, což nechceš. Druhá možnost je pohodlnější a sockety jsou nejrychlejší. Získáš plně dekuplované (to je ale hnusné slovo) komponenty a dobře definované API. Nevidím na tom nic děsivého, naopak - pokud je to výkonově adekvátní, je to nejlepší řešení.

EDIT: no, vlastně se socketama jsem kecal, ona ta komunikace probíhá nejspíš přes normální rouru, ale principielně je to úplně jedno. Prostě http://erlang.org/doc/reference_manual/ports.html

[Reklama]

[Ivan Nový]

V každém "deklarativním" jazyku je chybu težší odhalit, protože odvozovací pravidla generují vlastní jazyk a vyřešit úlohu, zda generovaný jazyk, odpovídá konkrétnímu jazyku a zamýšlenému účelu, je dosti náročné

To je samozřejmě opět úplný nesmysl.

To říkejte uživatelům SQL :-)))

[JSH]

V každém "deklarativním" jazyku je chybu težší odhalit, protože odvozovací pravidla generují vlastní jazyk a vyřešit úlohu, zda generovaný jazyk, odpovídá konkrétnímu jazyku a zamýšlenému účelu, je dosti náročné

To je samozřejmě opět úplný nesmysl.

To říkejte uživatelům SQL :-)))

Můžu se zeptat, jak předchozí blábol souvísí se SQL? Co jsou v SQL třeba ten generovaný a konkrétní jazyk?

[Ivan Nový]

V každém "deklarativním" jazyku je chybu težší odhalit, protože odvozovací pravidla generují vlastní jazyk a vyřešit úlohu, zda generovaný jazyk, odpovídá konkrétnímu jazyku a zamýšlenému účelu, je dosti náročné

To je samozřejmě opět úplný nesmysl.

To říkejte uživatelům SQL :-)))

Můžu se zeptat, jak předchozí blábol souvísí se SQL? Co jsou v SQL třeba ten generovaný a konkrétní jazyk?

Konkrétní jazyk jsou všechny možné žádoucí výsledky SQL dotazu, tedy to, co chcete a můžete z databáze vybrat, většinou to ani přesně neznáte, ale můžete to popsat nějakou gramatikou.

Generovaný jazyk je dán pravidly v podmínkách WHERE, JOIN atp. v daném příkazu SELECT a pravidly danými kompozicemi příkazů SELECT, konkrétní příkaz SELECT byste mohl převést na gramatiku, která by generovala nějaký jazyk, a platilo by o ní, že každý výsledek tohoto konkrétního dotazu, takto zkonstruovaná gramatika přijme.

No a vaším úkolem v podstatě je, rozhodnout, zda oba jazyky jsou stejné. A to vůbec není triviální záležitost.

A tak nějak to v podstatě i děláte, při konstrukci konkrétního SELECTu si v hlavě vytváříte gramatiku omezujících pravidel (podmínek), která z dat v db vybere požadovaná data. Je-li dotaz složitější, neustále probíráte zapsané podmínky a snažíte se v mysli vygenerovat možný výsledek, abyste se dobral k tomu, jaké pravidlo do příkazu přidat,odebrat či změnit a jak. Realitu modelujete pomocí pravidel, nikoli příkazů, které by měnily a zachovávaly nějaký stav výpočtu, pracujete tedy s gramatikou, aniž byste si to třeba uvědomoval.

[JSH]

Konkrétní jazyk jsou všechny možné žádoucí výsledky SQL dotazu, tedy to, co chcete a můžete z databáze vybrat, většinou to ani přesně neznáte, ale můžete to popsat nějakou gramatikou.

Generovaný jazyk je dán pravidly v podmínkách WHERE, JOIN atp. v daném příkazu SELECT a pravidly danými kompozicemi příkazů SELECT, konkrétní příkaz SELECT byste mohl převést na gramatiku, která by generovala nějaký jazyk, a platilo by o ní, že každý výsledek tohoto konkrétního dotazu, takto zkonstruovaná gramatika přijme.

No a vaším úkolem v podstatě je, rozhodnout, zda oba jazyky jsou stejné. A to vůbec není triviální záležitost.

A tak nějak to v podstatě i děláte, při konstrukci konkrétního SELECTu si v hlavě vytváříte gramatiku omezujících pravidel (podmínek), která z dat v db vybere požadovaná data. Je-li dotaz složitější, neustále probíráte zapsané podmínky a snažíte se v mysli vygenerovat možný výsledek, abyste se dobral k tomu, jaké pravidlo do příkazu přidat,odebrat či změnit a jak. Realitu modelujete pomocí pravidel, nikoli příkazů, které by měnily a zachovávaly nějaký stav výpočtu, pracujete tedy s gramatikou, aniž byste si to třeba uvědomoval.

Tohle ale nijak nesouvisí s deklarativními jazyky. Stačí abych upravil první odstavec na

Konkrétní jazyk jsou všechny možné žádoucí výsledky programu, tedy to, co chcete a můžete vypočítat, většinou to ani přesně neznáte, ale můžete to popsat nějakou gramatikou.

Tohle jsou základy teoretické informatiky, které platí pro jakékoliv jazyky, nejen ty deklarativní. Rozhodně se to nedá použít pro jakoukoliv kritiku deklarativních jazyků v porovní s jinými paradigmaty.

Upřímně mám z vašich příspěvků větší a větší pocit, že tu na nás někdo zkouší Turingův test.

[Mirek Prýmek]

Vůbec není potřeba do toho míchat "generované jazyky". Stačí říct, že každý program (v libovolném jazyce) dává pro nějaký vstup nějaký výstup a tedy každý program je vlastně jenom (nekonečná) tabulka a je děsivácky složité vymyslet program tak, aby ta skutečná tabulka odpovídala té tabulce, kterou chci dostat.

No jistě, pro složité problémy je to složité, ale pro jednoduché problémy je to jednoduché. A implementační jazyk v tom hraje minimální roli.

[Mirek Prýmek]

Upřímně mám z vašich příspěvků větší a větší pocit, že tu na nás někdo zkouší Turingův test.

Spíš bych řekl, že se Ivan na škole naučil správná klíčová slova, ale správně je aplikovat už ho nenaučili...

[Ivan Nový]

Konkrétní jazyk jsou všechny možné žádoucí výsledky SQL dotazu, tedy to, co chcete a můžete z databáze vybrat, většinou to ani přesně neznáte, ale můžete to popsat nějakou gramatikou.

Generovaný jazyk je dán pravidly v podmínkách WHERE, JOIN atp. v daném příkazu SELECT a pravidly danými kompozicemi příkazů SELECT, konkrétní příkaz SELECT byste mohl převést na gramatiku, která by generovala nějaký jazyk, a platilo by o ní, že každý výsledek tohoto konkrétního dotazu, takto zkonstruovaná gramatika přijme.

No a vaším úkolem v podstatě je, rozhodnout, zda oba jazyky jsou stejné. A to vůbec není triviální záležitost.

A tak nějak to v podstatě i děláte, při konstrukci konkrétního SELECTu si v hlavě vytváříte gramatiku omezujících pravidel (podmínek), která z dat v db vybere požadovaná data. Je-li dotaz složitější, neustále probíráte zapsané podmínky a snažíte se v mysli vygenerovat možný výsledek, abyste se dobral k tomu, jaké pravidlo do příkazu přidat,odebrat či změnit a jak. Realitu modelujete pomocí pravidel, nikoli příkazů, které by měnily a zachovávaly nějaký stav výpočtu, pracujete tedy s gramatikou, aniž byste si to třeba uvědomoval.

Tohle ale nijak nesouvisí s deklarativními jazyky. Stačí abych upravil první odstavec na

Konkrétní jazyk jsou všechny možné žádoucí výsledky programu, tedy to, co chcete a můžete vypočítat, většinou to ani přesně neznáte, ale můžete to popsat nějakou gramatikou.

Tohle jsou základy teoretické informatiky, které platí pro jakékoliv jazyky, nejen ty deklarativní. Rozhodně se to nedá použít pro jakoukoliv kritiku deklarativních jazyků v porovní s jinými paradigmaty.

Upřímně mám z vašich příspěvků větší a větší pocit, že tu na nás někdo zkouší Turingův test.

Ale dá. Co je podstatou deklarativního programování, nevytváříte postup výpočtu, ale soubor pravidel, kterými se výpočet má řidit, takže musíte být schopen poznat pohledem na ten soubor pravidel, že výsledek po jejich aplikaci, bude odpovídat požadavkům. Přičemž nejste ani schopen predikovat, jak velké změny výsledku vyvolá malá změna pravidel. A pak stojíte před problémem, jak poznat, zda výsledek odpovídá zadání.

U imperativního stylu ten výsledek ověřujete po částech jak konstruujete výpočet. Pouze vylučujete co neodpovídá očekávaní, při přechodu z jednoho stavu do druhého, což můžete snadněji předvídat, dá se určit do kterého kroku je výsledek správně, nemůžete však zaručit, že je to zcela správně za všech okolností. Jisté je, že se časem objeví další chyby.

[Mirek Prýmek]

Ale dá. Co je podstatou deklarativního programování, nevytváříte postup výpočtu, ale soubor pravidel, kterými se výpočet má řidit, takže musíte být schopen poznat pohledem na ten soubor pravidel, že výsledek po jejich aplikaci, bude odpovídat požadavkům. Přičemž nejste ani schopen predikovat, jak velké změny výsledku vyvolá malá změna pravidel. A pak stojíte před problémem, jak poznat, zda výsledek odpovídá zadání.

U imperativního stylu ten výsledek ověřujete po částech jak konstruujete výpočet. Pouze vylučujete co neodpovídá očekávaní, při přechodu z jednoho stavu do druhého, což můžete snadněji předvídat, dá se určit do kterého kroku je výsledek správně, nemůžete však zaručit, že je to zcela správně za všech okolností. Jisté je, že se časem objeví další chyby.

Učebnicová poučka neodpovídající realitě. O kousek výš jsem použil příklad

Kód: [Vybrat]

toInt rawString `andThen` toValidMonth

což je úplně to samé jako imperativní

Kód: [Vybrat]

toValidMonth(toInt(rawString))

I v natolik "deklarativním" jazyce jako je Prolog, se reálně píše tak, že člověk rozdělí problém na kroky, kterými se má výpočet ubírat. A pokud chce, může si zkontrolovat, že po jednotlivých krocích dostává ten výsledek, který očekává.

[Ivan Nový]

Vůbec není potřeba do toho míchat "generované jazyky". Stačí říct, že každý program (v libovolném jazyce) dává pro nějaký vstup nějaký výstup a tedy každý program je vlastně jenom (nekonečná) tabulka a je děsivácky složité vymyslet program tak, aby ta skutečná tabulka odpovídala té tabulce, kterou chci dostat.

No jistě, pro složité problémy je to složité, ale pro jednoduché problémy je to jednoduché. A implementační jazyk v tom hraje minimální roli.

Ale hraje. Protože skrze jazyk vidíte realitu. Eskymáci mají tisíce výrazů pro sníh, pod každým si představí něco jiného, což my si představit nedovedeme.

[Mirek Prýmek]

Ale hraje. Protože skrze jazyk vidíte realitu. Eskymáci mají tisíce výrazů pro sníh, pod každým si představí něco jiného, což my si představit nedovedeme.

A jediná země, která nepotřebuje střední vrstvy, je Japonsko, protože jedině Japonců je dost i bez středních vrstev.