Příspěvky

3196

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 31. 03. 2016, 12:47:39 »

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.

3197

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 31. 03. 2016, 12:38:38 »

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á.

3198

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 31. 03. 2016, 12:12:44 »

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...

3199

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 31. 03. 2016, 12:08:17 »

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.

3200

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 31. 03. 2016, 08:52:53 »

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

3201

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 31. 03. 2016, 08:46:04 »

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.

3202

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 31. 03. 2016, 08:44:54 »

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.

3203

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 30. 03. 2016, 14:00:38 »

Jupyter pro dalsi jazyky porad nic moc, pro Python maji IDE JetBrains... Porad to neni Java, ale na druhou stranu, vetsina dalsich jazyku je na tom o dost hur.

Jupyter je fajn, to je jasný, ale jednak to moc nesouvisí s tématem (je to spíš na interaktivní hraní si a nějakou tu práci s daty) a navíc já radši používám RStudio, přijde mi daleko pokročilejší. Jupyter je fajn na dema a interaktivní práci, kterou chceš mít zdokumentovanou. Ale jakmile si třeba napíšeš nějaké funkce a chceš jim měnit parametry a sledovat výstup, začíná to být opruz a nic moc to pak už nepřináší. V tomhle stadiu už mám radši RStudio + Knitr (pokud chci ty reporty).

3204

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 30. 03. 2016, 13:37:22 »

Napada mne ke knihovnam jeste dve vyhody - tooling a lidi.

A tooling pro python je co a čím to překonává tooling pro jiné jazyky?

3205

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 30. 03. 2016, 13:15:16 »

V kontextu vlákna se ptám na to, v čem vidíš výhody Pythonu.

To je přesně i moje otázka. Rozumím tomu, že po jistou dobu Python moc neměl konkurenci, ale dneska když si vezmu libovolný moderní jazyk s typovou inferencí a dobrou syntaxí, tak mě moc výhod Pythonu nenapadá, jenom samé nevýhody. Kromě snad velkého množství knihoven. Ale to třeba já řeším tak, že s Pythonem komunikuju přes socket z Elixiru (pokud fakt chci nějakou pythonní knihovnu použít a není alternativa v Elixiru - naposledy jsem takhle použil třeba knihovnu pro Request Tracker on cz.nic).

3206

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 30. 03. 2016, 13:07:48 »

OpenStack?

Ok, to je dobrý příklad, beru.

3207

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 30. 03. 2016, 13:06:28 »

Jsou lidé, kteří si o to prostě říkají.

V pohodě, jestli jsem řekl něco blbě, tak si zasloužím za uši, nemám s tím problém.

Velký projekt je třeba i linuxové jádro a nikdo ho nechce psát v Pythonu.

Nerozumím tomu, kam tímhle argumentem míříš. Moje pozice je "psaní středních a velkých projektů v pythonu přináší rizika, která by člověk měl znát, než se do něčeho takového pustí". Jak s tím souvisí tvrzení "existují velké projekty, které nikdo do Pythonu přepisovat nechce"?

Rozumná diskuse má dojít k poznání, kde jsou konkrétnější hranice použitelnosti či vhodnosti.

Ony ale žádné takové hranice nejsou. Čím větší projekt, tím musí být schopnější tým, aby to ustál. A opakuju: není mi jasné, proč by to dělal, co by tím získal. U většího projektu se podle mě výhody stírají a nevýhody zůstávají.

Generální - blbý výrok, že Python není vhodný na větší projekty (pokud nebyl vyřčen obecně, tak mě klidně oprav)

Mnou doufám nebyl. Pokud ano, chtěl bych vidět citaci.

K Julii - ta se vůbec netají tím, že se tlačí na pozici Pythonu v dané doméně. Mně se docela líbí, proč ne. Dosud není ani ve verzi 1, když se začal prosazovat Python v této oblasti, tak snad ani neexistovala.

To je irelevantní. Python taky neexistoval, když v téhle oblasti fungoval Fortran...

Skoro začínám mít dojem, že se snažíš Python shazovat za každou cenu - napřed přizvukuješ trollujícím javistům a pak se divíš, proč někdo chce "mermomocí" v tomto století dát pro určitý typ vědeckých výpočtů přednost Pythonu před C nebo Fortranem...

Ne, já se tomu vůbec nedivím. Oblast (obecně) zpracování dat enormně roste a přichází do ní spousta nových lidí, kteří to dřív nedělali (já jsem jeden z nich). No a jaký jazyk s nevětší pravděpodobností umí? Python. Tak ho tam dáme, aby se nemuseli učit to divné Rko. I když se python na tu doménu hodí míň než Rko.

Pokud máš pocit, že píšu něco špatně, klidně mě oprav. Bohužel ale nemám u Tebe také zrovna pocit, že bys vždycky diskutoval férově a snažil se dojít k pravdivému výsledku padni komu padni. Viz výše.

Však to jsem udělal Snažil jsem se korigovat tvoje tvrzení, který mi přišly zavádějící.

Jestli on nebude zakopaný pes tady:

Tady se zřejmě nechápeme. Poučenou kritiku Pythonu rozhodně vítám a netvrdím, že Ty, M. Prýmek a spol. neznáte nic než Python. Snažil jsem se vypořádat s potenciální radou opustit Python a hledat jinde

Z mé strany ta rada byla "nenechat se zmást prvním dojmem, jak projekt poroste, objeví se úplně jiné problémy než na začátku". A myslím, že ani moc nejsme ve sporu, jenom se možná trochu lišíme v hodnocení závažnosti a dopadů tohodle:

To samozřejmě platí o všech jazycích, ale ty dynamické k nekázni svádějí možná o něco více.

- já mám prostě obavu, že běžní programátoři do té nekázněspadnou (míň nebo víc, v té nebo oné formě) prakticky s jistotou.

3208

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 29. 03. 2016, 21:53:05 »

Racionální důvod k použití nějaké techologie je, že zavedený tým ji ovládá. Má-li firma samé javisty, nebude inklinovat k použití Pythonu a naopak.

Možná. Anebo taky ne a racionálnější je vybrat super nástroj a nechat lidi si ho osvojit... https://medium.com/@cameronp/the-best-way-to-build-a-dev-team-go-where-the-devs-aren-t-d3f226cfe749#.boy9f5nx6
Ono totiž když máš tým pythonistů, kteří použijí python na něco, na co vůbec není vhodný, jenom protože ho znají, úspěch z toho imho moc nekouká...

Co je těžkého k pochopení toho, že jsme se původně bavili o aplikačním programování a ne o věcech typu Hadoop?

OP neřekl, o jakou oblast mu jde. A jediném, o čem je spor, je vhodnost pythonu na střední a velké projekty.

Tohle se mi ani nechce moc rozebírat. Mohli použít třeba tu Javu, ta je ještě populárnější, ne?

Nemohli, protože Java je jako glue jazyk naprosto nevhodná (kromě toho, že má tytéž zmíněný problémy jako Python). Osobně bych byl radši, kdyby se pro sci rozšířila Julia než Python. Když už teda chceme mermomoci Fortran, C a Rko něčím nahrazovat...

Ve vší úctě, nevím, kdo Tě tady udělal soudcem vlákna.

Nikdo. Nesoudím, říkám svůj názor. A proti korekcím nic nemám, jenom ničemu moc nepomůžou, když jsou ustřelené zase druhým směrem Neber si to prosím osobně.

3209

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 29. 03. 2016, 21:35:39 »

ale v Pythonu mám pocit, že prostě chtěli, aby to bylo co nejjednodušší. Žádný
BufferedReader a FileReader, dám open() a je to.

Jo, tomu rozumím. Jenom si nejsem jistý, jestli to není tak trochu mazání medu kolem úst. Jestli to není tak trochu tak, že právě v těch malých věcech si vystačíš s open(..).read(), ale pak postupně zjišťuješ, že občas potřebuješ řešit velký soubory, na který už se to nehodí a chce to nějak inteligentně chunkovat, tak šáhneš po nějaké knihovně, která to umí, ... a seš tam, kde bys byl stejně   (o tomhle nechci nějak dlouhosáhle diskutovat, je to jenom tak k zamšlení, mám takový dojem, ne vyloženě vyfutrovaný argumenty...)

Tím OOP a modelováním lze s úspěchem šetřit a to i u větších projektů (třeba zmiňovaný namedtuple je myslím často dostatečný).

To je podobný případ. Já považuju namedtuple za super na víceméně funkcionální kód. Ale rozumné OOP s tím neuděláš. Pokud do něj budeš chtít jít (což u většího projektu budeš), seš zas zpátky...

A teď k typové inferenci - to je věc, která ještě poměrně nedávno byla výsadou pár "podivných" jazyků z rodiny ML.

Plusminus asi jo. Ale teď už to tak není a tím ta výhodnost sexy stručnosti pythonu trochu mizí - jinde už ji (teď) máš taky a bez toho, abys obětoval typový systém...

Molochovitostí myslím faktickou závislostí na IDE, na těžkopádném VM, monstrech typu Maven a tak. Rust a Swift jsou podle mne (coby jazyky) docela na dobré cestě, F# prakticky neznám, tam mi nevoní Mono (to samé tudíž C# i Boo), jinak by mě mohl celkem bavit. Go mi přijde trochu šité příliš na míru dobovým potřebám Google.

Chápu. No když vyřadíš "molochy" jako NET a JVM (F#, C#, Java, Scala, Clojure,...), tak ti moc rozumných jazyků nezbude, to je celkem nasnadě

3210

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 29. 03. 2016, 21:10:54 »

Tak se našrouboval na věc, na kterou se (mimochodem) moc nehodí.

...a abych předešel dotazu na konrétní příklad: Python striktně vyžaduje evaluaci argumentů fce a nedá se to nijak obejít. A to je např. pro předávání formulí fakt problém. Stejně tak třeba selekce je omezená tím, co v pythonu jde (iloc) a kdyby byl od začátku navržený na vědecké výpočty, uměl by některé věci, které teď neumí, protože na to prostě není určený, jenom byl chytře ohnut, aby v dané oblasti mohl dělat lepidlo.