Má Python budoucnost?

[Kit]

Pomohlo by, aby jsi uvedl kompletní příklad. Tento druhý ti nebude fungovat, páč tam neuvádíš var.

Podívej se na libovolný skript pro AWK a uvidíš kompletní příklad. Nikde žádný cyklus, nikde žádný switch. Prostě jen vzorek, akce, vzorek, akce, ...

Chápu. Problém je v tom, že v tvém příkladu tam schází "co" matchuješ. Takže díky tomuto opomenutí si nabil dojmu, jakoby "Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch)".

To je všechno, co jsem chtěl řešit. Přeji pěkný den.

Matchuješ vstupní data. Žádná proměnná, prostě standardní vstup.

Nabil sis akorát čumák. Ostatní nabyli dojmu.

[Reklama]

[BoneFlute]

Chápu. Problém je v tom, že v tvém příkladu tam schází "co" matchuješ. Takže díky tomuto opomenutí si nabil dojmu, jakoby "Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch)".

To je všechno, co jsem chtěl řešit. Přeji pěkný den.

Matchuješ vstupní data. Žádná proměnná, prostě standardní vstup.

Já to chápu. Prostě v jednom programu je možné použít vstupní proud jako argument matchování, a ty z toho děláš obecný rozdíl mezi switchem a pattern matchingem. Je mi to jasný.

Nabil sis akorát čumák. Ostatní nabyli dojmu.

Ach, samozřejmě sorry - "nabýt".

[gl]

Spousta funkcí v haskellu má nic neříkající typovou signaturu jako a -> a. Například většina matematických funkcí má signaturu Floating a => a -> a. Docstring v pythonu často obsahuje příklad použití, který mohu spustit jako test.

To je naopak signatura, která říká naprosto všechno - že jde o fci, která může pracovat s libovolným typem ze třídy Floating a vrací stejný typ, jaký mu dám. Co víc bys mohl chtít vědět?

Jak jsem psal výše. Mohl bych chtít krátký popis chování funkce v docstringu a několik příkladů použití, které mohu spustit jako test. Reagoval jsem na BoneFlute, který říkal, že typová signatura může zastoupit dokumentaci. Nezpochyňuji užitečnost statického typování, ale nedovedu si představit, jak vám může zastoupit testy a dokumentaci. Možná je to jen můj omezený pohled.

[Mirek Prýmek]

Jak jsem psal výše. Mohl bych chtít krátký popis chování funkce v docstringu a několik příkladů použití, které mohu spustit jako test. Reagoval jsem na BoneFlute, který říkal, že typová signatura může zastoupit dokumentaci. Nezpochyňuji užitečnost statického typování, ale nedovedu si představit, jak vám může zastoupit testy a dokumentaci. Možná je to jen můj omezený pohled.

Proti tomu nic nemám, ale ten tvůj argument byl chybný. Signatura a -> a není o nic horší nebo lepší než Int -> String

[BoneFlute]

Spousta funkcí v haskellu má nic neříkající typovou signaturu jako a -> a. Například většina matematických funkcí má signaturu Floating a => a -> a. Docstring v pythonu často obsahuje příklad použití, který mohu spustit jako test.

To je naopak signatura, která říká naprosto všechno - že jde o fci, která může pracovat s libovolným typem ze třídy Floating a vrací stejný typ, jaký mu dám. Co víc bys mohl chtít vědět?

Jak jsem psal výše. Mohl bych chtít krátký popis chování funkce v docstringu a několik příkladů použití, které mohu spustit jako test. Reagoval jsem na BoneFlute, který říkal, že typová signatura může zastoupit dokumentaci. Nezpochyňuji užitečnost statického typování, ale nedovedu si představit, jak vám může zastoupit testy a dokumentaci. Možná je to jen můj omezený pohled.

To je nedorozumění:
- Typová signtura je víc i míň než testy - je kvalitnější, pokrývaj větší oblast (to je to víc) a něco nedokáže podchytit (to je to míň).
- Typová signatura nenahrazuje dokumentaci. Ale může sloužit jako slušný základ dokumentace. Plus to, že je vynucená.

Takže určitě ne, že by typy mohli dokumentaci zastoupit. Rozhodně ne plně.
Hlavně jsem se točil kolem toho, že co se nevynutí, tak to nedostaneš.

[Reklama]

[gl]

Jak jsem psal výše. Mohl bych chtít krátký popis chování funkce v docstringu a několik příkladů použití, které mohu spustit jako test. Reagoval jsem na BoneFlute, který říkal, že typová signatura může zastoupit dokumentaci. Nezpochyňuji užitečnost statického typování, ale nedovedu si představit, jak vám může zastoupit testy a dokumentaci. Možná je to jen můj omezený pohled.

Proti tomu nic nemám, ale ten tvůj argument byl chybný. Signatura a -> a není o nic horší nebo lepší než Int -> String

Myslel jsem to tak, že když se ze signatury matematické funkce dovím, že má argument typu číslo a vrací číslo, tak mi to většinou moc nepomůže. Chtěl bych vědět jakou operaci s těmi čísly provádí. V některé z předchozích diskuzí někdo psal, že vyhledává haskellovské funkce podle signatury na téhle stránce https://www.haskell.org/hoogle/ . Nedovedu si představit jak to funguje v případě těchto běžných signatur.

[Wavelet]

Jak jsem psal výše. Mohl bych chtít krátký popis chování funkce v docstringu a několik příkladů použití, které mohu spustit jako test. Reagoval jsem na BoneFlute, který říkal, že typová signatura může zastoupit dokumentaci. Nezpochyňuji užitečnost statického typování, ale nedovedu si představit, jak vám může zastoupit testy a dokumentaci. Možná je to jen můj omezený pohled.

Proti tomu nic nemám, ale ten tvůj argument byl chybný. Signatura a -> a není o nic horší nebo lepší než Int -> String

Myslel jsem to tak, že když se ze signatury matematické funkce dovím, že má argument typu číslo a vrací číslo, tak mi to většinou moc nepomůže. Chtěl bych vědět jakou operaci s těmi čísly provádí. V některé z předchozích diskuzí někdo psal, že vyhledává haskellovské funkce podle signatury na téhle stránce https://www.haskell.org/hoogle/ . Nedovedu si představit jak to funguje v případě těchto běžných signatur.

Pokud má funkce rozumný název, už to hodně napoví nebo ne? Ideálně vhodným názvem metody/funkce zrcadlím problém z domény -- tak nějak, jak se to praktikuje v DDD. Když máš funkci pojmenovanou jako calculate(i) -- tak ti je to k ničemu v jakémkoliv jazyce; pokud není ve vhodně pojmenovaném modulu, třídě -- zasazená do kontextu.

[andy]

Myslel jsem to tak, že když se ze signatury matematické funkce dovím, že má argument typu číslo a vrací číslo, tak mi to většinou moc nepomůže. Chtěl bych vědět jakou operaci s těmi čísly provádí. V některé z předchozích diskuzí někdo psal, že vyhledává haskellovské funkce podle signatury na téhle stránce https://www.haskell.org/hoogle/ . Nedovedu si představit jak to funguje v případě těchto běžných signatur.

Tak řekněme, že heldám funkci, která mi třeba najde, jestli v seznamu je prvek splňující nějaké kritérium. Takže máme signaturu:

Kód: [Vybrat]

(a -> Bool) -> [a] -> Bool a vida - vypadne hned na začátku "all" a "any".
Tak třeba něco, co spočte, kolikrát je daný prvek v poli:

Kód: [Vybrat]

Eq a => a -> [a] -> Int a hned máme elemIndexJust a countElem.

Chcem třeba akci zopakovat n-krát a dostat v seznamu výsledky těch akcí:

Kód: [Vybrat]

Monad m => Int -> m a -> m [a] - replicateM

Co třeba... takový sum:

Kód: [Vybrat]

Num a => [a] -> aa máme product, sum

Tak co takhle funkce na setřídění, která třídí prvky přímo:

Kód: [Vybrat]

Ord a => [a] -> [a] a vypadnul nám "sort" a hned potom "ordNub", který odstraňuje duplikáty v n*logn.

A co třeba třídění podle custom funkce:

Kód: [Vybrat]

(a -> a -> Ordering) -> [a] -> [a]A hned máme sortBy a nubOrdBy.

A nebo máme funkci "a -> a" a chceme ji n-krát iterovat:

Kód: [Vybrat]

Int -> (a -> a) -> a -> a

[andy]

Ještě k těm typům - většina lidí si totiž neuvědomuje, že čím méně je toho v typu specifikováno, tím méně toho ta funkce může dělat. Třeba jediná smysluplná věc, kterou může funkce se signaturou "a -> a" dělat, je ten argument vrátit (nebo se zacyklit, ale to není moc rozumné). Nic víc ta funkce dělat nemůže, protože o "a" nic neví. Funkce "[a] -> Int" pravděpodobně vrátí nějakou funkci délky pole. Funkce "[a] -> [a]" provede nějakou reorganizaci/filtraci na poli, která není závislá na prvcích, ale výhradně na počtu prvků.
Funkce "Eq a => a -> a -> Bool" může být buď "==" nebo "!=", nic jiného nedává smysl. Takže ta signatura fakt funguje jako dost dobrá dokumentace, velmi často ve spojení se jménem bohatě stačí. Osobně mám akorát problém, když přijdu k nové knihovně a nevím jak začít. Ale v momentě, kdy už se nějak orientuju, tak v podstatě ty signatury stačí.

[Mirek Prýmek]

Myslel jsem to tak, že když se ze signatury matematické funkce dovím, že má argument typu číslo a vrací číslo, tak mi to většinou moc nepomůže. Chtěl bych vědět jakou operaci s těmi čísly provádí.

Já třeba v Haskellu nedělám, teď jsem akorát asi 14dní dělal intenzivně v Elmu a musím říct, že první, na co jsem se díval, byly vždycky signatury. Musíš totiž taky vzít v úvahu, že u FP jazyků se daleko víc pracuje se základními primitivními operacemi - přidat něco do listu, něco z listu vyfiltrovat, aplikovat nějakou lambdu na všechny prvky... A tam ti prostě stačí vidět map :: (a -> b) -> [a] -> [ b ] a čte se ti to líp (pohodlněji) než nějaká slovní omáčka - pokud ty základní operace znáš a poznáš je aspoň přibližně podle názvu.

[gl]

Ještě k těm typům - většina lidí si totiž neuvědomuje, že čím méně je toho v typu specifikováno, tím méně toho ta funkce může dělat. Třeba jediná smysluplná věc, kterou může funkce se signaturou "a -> a" dělat, je ten argument vrátit (nebo se zacyklit, ale to není moc rozumné). Nic víc ta funkce dělat nemůže, protože o "a" nic neví. Funkce "[a] -> Int" pravděpodobně vrátí nějakou funkci délky pole. Funkce "[a] -> [a]" provede nějakou reorganizaci/filtraci na poli, která není závislá na prvcích, ale výhradně na počtu prvků.
Funkce "Eq a => a -> a -> Bool" může být buď "==" nebo "!=", nic jiného nedává smysl. Takže ta signatura fakt funguje jako dost dobrá dokumentace, velmi často ve spojení se jménem bohatě stačí. Osobně mám akorát problém, když přijdu k nové knihovně a nevím jak začít. Ale v momentě, kdy už se nějak orientuju, tak v podstatě ty signatury stačí.

To dává smysl. Díky za vysvětlení. Nechtěl jsem nic zpochybňovat, jen jsem si nedokázal představit jak to může fungovat v praxi.

[Mirek Prýmek]

To dává smysl. Díky za vysvětlení. Nechtěl jsem nic zpochybňovat, jen jsem si nedokázal představit jak to může fungovat v praxi.

Prekvapive dobre. A dalsi prekvapeni je, ze jsou ty signatury v Haskellu podstatne lip citelny nez treba templaty v C++, coz je principielne dost podobna vec, ale z templatu by se clovek zblil

[andy]

Ještě bych možná dodal, že funkce typu "Int -> Int -> Int -> Int" jsou v Haskellu tak trošku antipattern - tak nějak nikdo nemá moc rád více než 1 parametr stejného typu. Ne vždycky se tomu člověk vyhne, ale existují různé snadno použitelné "tagované" typy, které v tom trochu dělají pořádek - takže ve výsledku pak vypadá taková funkce např.:

Kód: [Vybrat]

Email -> [Email] -> Subject -> [Part] -> Message Takhle to obvykle není v knihovnách, ale ve vlastním kódu tohle strašně pomáhá.

[Kit]

Ještě bych možná dodal, že funkce typu "Int -> Int -> Int -> Int" jsou v Haskellu tak trošku antipattern - tak nějak nikdo nemá moc rád více než 1 parametr stejného typu. Ne vždycky se tomu člověk vyhne, ale existují různé snadno použitelné "tagované" typy, které v tom trochu dělají pořádek - takže ve výsledku pak vypadá taková funkce např.:

Kód: [Vybrat]

Email -> [Email] -> Subject -> [Part] -> Message Takhle to obvykle není v knihovnách, ale ve vlastním kódu tohle strašně pomáhá.

Sémantické označení obyčejného typu String pomáhá nejen v Haskellu. Pak to teprve vypadá jako dokumentace, která nepotřebuje další komentáře.

[noef]

Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor. Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.

Ono je obecně škoda, že se v populárních jazycích moc nevidí koncepty z FP. Možná si tvůrci jazyků myslí, že na běžného vývojáře je FP moc složité/abstraktní/matoucí... Přitom takové OOP většina také dost patlá...

Je stejne zajimave, jak dlouho trvalo OOP, nez se prosadilo. Pokud si to pamatuju spravne, tak byl potreba prechod na graficka uzivatelska rozhrani, kde OOP zazarilo, a az pak se opravdu masove zacalo pouzivat. Mozna stojime na podobnem prahu - jak roste pocet jader, ale ne vykon jadra, tak FP pristup zacina byt dost zajimavy.

PS: Je opravdu dost mozne, ze je to pouze zpusobeno pristupem skol, kdy se imperativni pristup uci prvni. A teda prijde me, ze i podstatne lepe, nez treba ten funkcionalni. V imperativnim jsme rovnou zacali patlat v C, u funkcionalniho jsme nejdriv museli prezit a nepochopit (nasprtat se) teorii a az pak, pri reseni projektu, zacit chapat, o cem ze ta teorie asi ze byla.

Já jsem se s haskellem setkal ve škole asi před 10-ti lety a nevzpomínám si, že by ho někdo ze spolužáků začal ihned používat v praxi. Víc než na škole záleží na vyspělosti ekosystému okolo. Ten je dneska úplně jinde. Naopak, dynamické jazyky jako ruby, php a js se nikdy nikde neučily a rozšířily se docela rychle.

No, ja se taky "setkal", ale ve srovnani s imperativnim pristupem, ktery se do nas tlacil vlastne neustale, setkani v ramci poloviny jednoho predmetu bylo opravdu slabe.

stredni (gympl):
- Pascal (nekteri spoluzaci z prumek znali trochu C, dost lidi neznalo nic)

bc:
- C (nekolik predmetu)
- ASM
- C++/Java (na vyber jedno)
- Python (myslim take nekolikrat na psani ukolu)
- cisty stary JavaScript
- Pascal+pseudo kod

mgr:
- C/C++ (nekolik predmetu, na projekty)
- Java/nejaky neznamy jazyk na IS
- 1x jazyk podle vlastniho vyberu (pouzil jsem Scalu)
- Ada+nejaky dalsi paralelni
- Haskell+Prolog (vcetne teorie k obema paradigmatum)
- 2x C#
- Python (zase ukoly, tusim sifrovani)

Asi jsem na neco zapomnel, ale funkcionalni bych si pamatoval. Kdyz to shrneme, tak mame za cele studium 0,5 predmetu venovanemu funkcionalnimu jazyku (jeste teda JavaScript, ale tomu nebyl take venovan cely predmet a FP jako takove se tam snad ani neresilo; navic JS podle nekterych definic ani nespada do funkcionalnich jazyku). Takze ne, nedivim se, ze nikdo z mych spoluzaku nebezel a nezacal pracovat v FP jazyce.

Je mozne, ze na vasi skole jste meli destiky predmetu vyucujici a vyuzivajici FP a funckionalni jazyky. Sice jsem znacne skepticky, ale co. Pokud je tomu opravdu tak, prosim podelte se o jmeno skoly (bych si treba i precetl jake predmety jste meli a tise zavidel).