Má Python budoucnost?

[noef]

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.

Jop, napr. typovana ID pouzivam ve Scale u immutable trid k referencim: AccountRef(id: Int).

[Reklama]

[Mirek Prýmek]

- Haskell+Prolog (vcetne teorie k obema paradigmatum)

To jste teda museli vzit poradne z rychliku. Za 6h x 100min. se nedá probrat ani jeden z těch jazyků, natož teorie k němu.

[BoneFlute]

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

Sice jsem Haskellista, ale takhle pěkně zformulované bych to nedal. +1

[Wavelet]

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.

[gl]

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

Měli jsme to podobně. Haskell se probíral jako součást předmětu společně s prologem a scheme. Také jsem si z toho moc neodnesl. V té době jsem to bral spíš jako kuriozitu. Většinu úloh jsem řešil pomocí rekurze, protože jsem neznal základní funkce pro práci s listy. Zápočtovou práci jsem dělal v prologu, z toho jsem si toho odnesl asi nejvíc. V té době jsem se zajímal hlavně o počítačovou grafiku, programování her a nějaké to php. Stále si myslím, že pro řešení některých problémů je imperativní přístup vhodnější. Například inplace quicksort. Dá se taková věc naprogramovat elegantně v haskellu? Nebo některé maticové algoritmy a algoritmy dynamického programování. Ok, dá se to dělat pomocí nějakých komplikovaných konstrukcí s vnořenými foldly. Ale proč? Možná to jsou umělé školní příklady, ale zajímal by mne názor místních haskellistů.

[Reklama]

[čumil]

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

Měli jsme to podobně. Haskell se probíral jako součást předmětu společně s prologem a scheme. Také jsem si z toho moc neodnesl. V té době jsem to bral spíš jako kuriozitu. Většinu úloh jsem řešil pomocí rekurze, protože jsem neznal základní funkce pro práci s listy. Zápočtovou práci jsem dělal v prologu, z toho jsem si toho odnesl asi nejvíc. V té době jsem se zajímal hlavně o počítačovou grafiku, programování her a nějaké to php. Stále si myslím, že pro řešení některých problémů je imperativní přístup vhodnější. Například inplace quicksort. Dá se taková věc naprogramovat elegantně v haskellu? Nebo některé maticové algoritmy a algoritmy dynamického programování. Ok, dá se to dělat pomocí nějakých komplikovaných konstrukcí s vnořenými foldly. Ale proč? Možná to jsou umělé školní příklady, ale zajímal by mne názor místních haskellistů.

Haskellista se hlásí.
Samozřejmě, FP není na všechno. Není třeba na AI. Neuronová síť potřebuje pro rychlí běh rychlou implementaci matic s rychlím random přístupem. Jde to udělat s listy, ale bude to pomalí až běda. Jde to udělat i s poli, pak to bude ale díky persistenci pomalí ještě hůř. A nebo můžeme tu čistotu poslat kompletně do zadeke a použít mutable arrays ... ale proč potom používat Haskell žejo ...

[andy]

Například inplace quicksort. Dá se taková věc naprogramovat elegantně v haskellu? Nebo některé maticové algoritmy a algoritmy dynamického programování. Ok, dá se to dělat pomocí nějakých komplikovaných konstrukcí s vnořenými foldly. Ale proč? Možná to jsou umělé školní příklady, ale zajímal by mne názor místních haskellistů.

Tak logicky algoritmy optimalizované na to využít mutabilitu samozřejmě v non-mutable jazyce fungovat dobře nebudou. V mnoha případech jde použít jiný algoritmus - což někdy vede překvapivě i k přehlednějšímu řešení  (navíc s "Fusion" ten výsledek může být i slušně rychlý), ale je fakt, že občas něco opravdu jinak rozumně řešit nejde. V Haskellu je pro tyto účely tzv. ST monad, který de-fakto umožňuje provádět mutable programování v "izolaci" - tzn. ta mutabilita je uvnitř a neuteče nikam ven. Mně připadá, že ale výsledný kód má do přehlednosti dost daleko - je to takové ... imperativní ...

[Radek Miček]

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

To obecně nemusí být pravda - v některých jazycích například mohu napsat funkci typu a -> a:

Kód: [Vybrat]

normalizuj(x) = x.toLowerCase, pokud je x řetězec,
normalizuj(x) = x jinak


[zboj]

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

Mít Prolog a FP v jednom předmětu je dost blbý nápad. Jinak FP je asi jeden z mála konceptů, co by se měl učit začínaje od teorie, protože z fleku se v tom rozumně psát fakt nedá (na rozdíl třeba i od toho Prologu, jenž je taky dost daleko od mainstreamu).

[gl]

Většinu úloh jsem řešil pomocí rekurze, protože jsem neznal základní funkce pro práci s listy.

Ne že bych je vůbec neznal, ale v testech a u tabule jsem se snažil používat jen omezenou podmnožinu jazyka, abych omezil riziko chyby (testy i zkouška se psaly na papír).

[noef]

Jsem jeste pozapomnel na VHDL v par (2?) predmetech, coz teda funckionalni stale moc neni (v jednom jsme to delali na urovni hradel, v dalsim tim vyssim pristupem).

Co se tak divam, tak ten JavaScript se spise k FP neradi, prestoze ma nektere FP rysy. Dobre to shrnul treba tady na SO.

- Haskell+Prolog (vcetne teorie k obema paradigmatum)

To jste teda museli vzit poradne z rychliku. Za 6h x 100min. se nedá probrat ani jeden z těch jazyků, natož teorie k němu.

Jn, presne jak pises. Prednasky k Haskellu byly hlavne lambda kalkul a pocitani s nim (napr. reprezentace cisel, operace nad nimi atp.; coz ale primo v Haskellu jaksi nepouzijes). Pritom si treba ani moc nepamatuju, ze by prednasejici vubec resil nejake monady. Na cvikach se to do nas snazili nejak nalit, kdyz zjistili, ze to nikdo nechape, ale bylo malo casu a musely se resit predepsane prakticke priklady. Ty prekvapive s vyucovanou teorii nemeli nic moc spolecneho (asi jsme to v tom jen nevideli, nevim, protoze snad ta teorie nebyla nanic?). Treba ty monady a do notaci jsem pochopil az mnohem pozdeji samostudiem pri praci na projektu. Jak jsem byl nastvany na prednasejiciho, ze takovou "nepodstatnou" vec mi zamlcel.

Jako chapu, ze ciste FP neni moc popularni. Ale vzhledem k tomu, jak se mu uspesne dari infiltrovat popularni jazyky, tak si myslim, ze minimalne jeden predmet v bakalari by si to zaslouzilo.

Rozhodne nerazim nazor "Vsude ciste FP!". Treba prave ta Scala neni ani omylem cista (Haskellisti se na ni myslim celkem casto divaji shora) a FP se na nektere veci hodi mnohem vice, na jine naopak vice vynika imperativni pristup a OOP.

[andy]

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

To obecně nemusí být pravda - v některých jazycích například mohu napsat funkci typu a -> a:

Kód: [Vybrat]

normalizuj(x) = x.toLowerCase, pokud je x řetězec,
normalizuj(x) = x jinak


Otázka byla, proč haskellistům v zásadě stačí jako dokumentace jenom signatury funkcí (to trošku přeháním, ale faktem je, že tohle je častá výtka) - a ten důvod právě je, že v Haskellu tohle neuděláte. Signatura prostě říká, že ta funkce neví, co je "a" za typ, tak to ta funkce neví. Tohle by třeba v haskellu mělo signaturu:

Kód: [Vybrat]

Dynamic -> Dynamic
A když se na ni člověk podívá, ví, že o té funkci nemůže říct téměř nic.

[Radek Miček]

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

To obecně nemusí být pravda - v některých jazycích například mohu napsat funkci typu a -> a:

Kód: [Vybrat]

normalizuj(x) = x.toLowerCase, pokud je x řetězec,
normalizuj(x) = x jinak


Otázka byla, proč haskellistům v zásadě stačí jako dokumentace jenom signatury funkcí (to trošku přeháním, ale faktem je, že tohle je častá výtka) - a ten důvod právě je, že v Haskellu tohle neuděláte. Signatura prostě říká, že ta funkce neví, co je "a" za typ, tak to ta funkce neví. Tohle by třeba v haskellu mělo signaturu:

Kód: [Vybrat]

Dynamic -> Dynamic
A když se na ni člověk podívá, ví, že o té funkci nemůže říct téměř nic.

I tak existuje v Haskellu 3. možnost - někdy vrátit totéž a někdy se zacyklit (pomocí seq).

[Radek Miček]

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

To obecně nemusí být pravda - v některých jazycích například mohu napsat funkci typu a -> a:

Kód: [Vybrat]

normalizuj(x) = x.toLowerCase, pokud je x řetězec,
normalizuj(x) = x jinak


Otázka byla, proč haskellistům v zásadě stačí jako dokumentace jenom signatury funkcí (to trošku přeháním, ale faktem je, že tohle je častá výtka) - a ten důvod právě je, že v Haskellu tohle neuděláte. Signatura prostě říká, že ta funkce neví, co je "a" za typ, tak to ta funkce neví. Tohle by třeba v haskellu mělo signaturu:

Kód: [Vybrat]

Dynamic -> Dynamic
A když se na ni člověk podívá, ví, že o té funkci nemůže říct téměř nic.

I tak existuje v Haskellu 3. možnost - někdy vrátit totéž a někdy se zacyklit (pomocí seq).

Lepší by asi bylo říci, že ta 3. možnost je vyhodnotit do WHNF.

[andy]

I tak existuje v Haskellu 3. možnost - někdy vrátit totéž a někdy se zacyklit (pomocí seq).

Jenže ta funkce nemá žádná vstupní data do podmínky "mám se zacyklit?". Takže nemůže.