Příspěvky

1756

Vývoj / Re:Má Python budoucnost?

« kdy: 13. 05. 2016, 18:25:29 »

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

1757

Vývoj / Re:Má Python budoucnost?

« kdy: 13. 05. 2016, 18:20:13 »

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

1758

Vývoj / Re:Má Python budoucnost?

« kdy: 13. 05. 2016, 17:46:04 »

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.

1759

Vývoj / Re:Má Python budoucnost?

« kdy: 13. 05. 2016, 17:36:18 »

V jednoduchosti (popsáno metajazykem) by to mohlo vypadat asi takto:

Kód: [Vybrat]

match 'a' -> 1
match 'b' -> 2
match 'c' -> 3
match '*' -> -1

Slovo 'match' tam samozřejmě být nemusí a tím se to pomalu začne podobat našemu oblíbenému AWK. Záleží pak už jen na tom, jaké má dotyčný engine ambice - jednoduchost či komplexnost.

V kódu:

Kód: [Vybrat]

switch(True) {
  case a > 1 && a < 10: do_foo(); break;
  case is_valid(b): do_boo(); break;
  case a <= 1: do_goo(); break;
  default: do_otherwise();
}

Sice funguje, jenže je to taková problematická věc. Protože za kontext switche/pattern matchingu považuje celej scope. Což je sice hrozně pohodlný, a rád to používám, ale taky dost nebezpečný.

Samozřejmě tam nadřazený element je. Vždycky tam musí být. V Haskellu, kde se takto přetěžují funkce, je nadřazeným elementem modul (scope modulu).

No, a říct o tom, že: "Ne tak docela. Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch)." je prostě jenom neužitečná provokace.

Evidentně jsi vůbec nepochopil, o čem jsem psal. Nevadí.

To sis vůbec nevšiml, že tam žádný "switch" nemám? Ani ve zdrojáku není. Nebavil jsem se o Haskellu, ale o metajazyku ve stylu AWK a jemu podobných. Nadřazeným elementem je samotný engine toho jazyka.

Ale všiml. A ty si prosím povšimni, že v mém případě jde jen o syntaktickou nutnost danou jazykem. Ale technicky tam být nemusí. Proto platí, že pattern matching je jen lepší switch. Principielně to totiž je fakt úplně stejný.

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

1760

Vývoj / Re:Má Python budoucnost?

« kdy: 13. 05. 2016, 16:56:25 »

Kód: [Vybrat]

match var with
| 'a' -> 1
| 'b' -> 2
| 'c' -> 3
| _ -> -1

V jednoduchosti (popsáno metajazykem) by to mohlo vypadat asi takto:

Kód: [Vybrat]

match 'a' -> 1
match 'b' -> 2
match 'c' -> 3
match '*' -> -1

Slovo 'match' tam samozřejmě být nemusí a tím se to pomalu začne podobat našemu oblíbenému AWK. Záleží pak už jen na tom, jaké má dotyčný engine ambice - jednoduchost či komplexnost.

Ach jo, s tebou je někdy práce.

V kódu:

Kód: [Vybrat]

switch(True) {
  case a > 1 && a < 10: do_foo(); break;
  case is_valid(b): do_boo(); break;
  case a <= 1: do_goo(); break;
  default: do_otherwise();
}

Sice funguje, jenže je to taková problematická věc. Protože za kontext switche/pattern matchingu považuje celej scope. Což je sice hrozně pohodlný, a rád to používám, ale taky dost nebezpečný.

Samozřejmě tam nadřazený element je. Vždycky tam musí být. V Haskellu, kde se takto přetěžují funkce, je nadřazeným elementem modul (scope modulu).

No, a říct o tom, že: "Ne tak docela. Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch)." je prostě jenom neužitečná provokace.

1761

Vývoj / Re:Má Python budoucnost?

« kdy: 13. 05. 2016, 15:46:58 »

Proc nezrusit i cely switch? Krome nekolika malo pripadu (ale fakt malo) je to jen chapa nahrada za spatne navrzenou hierarchii trid (vetsinou se da nahradit polymorfismem a v lepsich!!! jazycich pattern matchingem).

pattern matching je len vylepseny switch.

Ne tak docela. Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch).

Co to v praxi znamená?

1762

Vývoj / Re:Má Python budoucnost?

« kdy: 13. 05. 2016, 14:54:01 »

autěr chtěl říct, že haskelleři píšou return stejně jako se píše v pythonu nebo cčku

V Pythonu ani céčku by nikdo za return nenapsal tak dlouhej řádek, v tom to je - `$` prostě svádí spojovat příliš dlouhé výrazy a to tak blbě, že musím očima skočit ze začátku řádku za dolar, dočíst do konce řádku a pak znovu pokračovat od jeho začátku. Pokud je tam ještě třeba nějaká ta částečná aplikace, je to guláš, který se špatně čte. Dá se na to zvyknout, ale vrchol ergonomie to teda není, ať si kdo chce co chce říká, ať si Curry slzy utírá

Hmm, imho je to tím, že v Haskellu je všechno něco jako: "a je ve skutečnosti b".

Kód: [Vybrat]

a = 1 + 1

Takže to return nalevo dává logiku. Zatímco v Imperativních jazycích je to spíše: "nejdřív udělej a;hotovo? Tak teď b; hotovo? tak teď c; hotovo? Tak teď vrať d."

1763

Vývoj / Re:Má Python budoucnost?

« kdy: 12. 05. 2016, 20:53:56 »

Ohavnosti jako __str__() nebo ducktyping tam opravdu nenajdes.

Docela mě dráždí, jak slučuješ estetickou záležitost (__str__()) a technologickou záležitost (ducktyping versus nominální typování).

Oba pripady spadaji do souhrnne mnoziny "znouzectnost".

__str__() protoze python nema toplevel class
ducktyping() - protoze typovani neni, tak budeme typ hadat a doufat, ze nekoho jineho nenapadlo napsat podobnou tridu.

Blbost.

__str__() je metoda z (jakéhosi) rozhraní Stringable. Není to žádná hrůza, a to, že se tam dávají podtržítka je prostě konvence a estetická záležitost. To je všechno.

Volbu duck-typingu považuji za faktický problém (i když připouštím, že v praxi se nemusí projevovat).

1764

Vývoj / Re:Má Python budoucnost?

« kdy: 12. 05. 2016, 20:40:20 »

Ohavnosti jako __str__() nebo ducktyping tam opravdu nenajdes.

Docela mě dráždí, jak slučuješ estetickou záležitost (__str__()) a technologickou záležitost (ducktyping versus nominální typování).

1765

Vývoj / Re:Má Python budoucnost?

« kdy: 12. 05. 2016, 20:06:13 »

Já jen - všímáte si, že diskuze jde přesně tím směrem, co jsem popsal?

No, bacha na to. Jednou jsem se také pokoušel zeptat, proč duck-typing, a k čemu má Python typy. Ve výsledku jsem se jen dozvěděl, že jsem blbec a trollím. Tak si nestěžuj.

1766

Vývoj / Re:Má Python budoucnost?

« kdy: 12. 05. 2016, 19:28:19 »

Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.

Tak to určitě...

1767

Vývoj / Re:Má Python budoucnost?

« kdy: 12. 05. 2016, 18:10:53 »

V Haskellu základní věci dokumentovat nemusíš, protože ti to zdokumentuje Typovej systém. Ten ti taky zajistí, že to bude aktuální a korektní.

Tak to je samozřejmě pravda. S velkým důrazem na ty „základní věci“, které jsou většinou méně výraznou součástí informace, kterou od dokumentace chci. Primárně vědět „co to dělá a proč“, než „nad čím a co z toho leze“.

Haskell toho umí hodně. Ale to už nesouvisí s Pythonem.

Python i Haskell má stejný problém. Nepíše se dokumentace.

Citation needed.

Jen pro pořádek, zrovna o dokumentaci v pythonu mám rozepsaný článek*, který shrnuje mé zkušenosti z používání mnoha desítek opensource knihoven a dokumentace se píše. Dokonce celý populární ReadTheDocs, který je dneska používaný pro velkou část všemožného OSS vznikl z pythonního dokumentačního systému Sphinx.

Rád bych tedy věděl, z čeho usuzuješ, že je to podstatný problém, protože si opravdu nejsem vědom toho, že by se nepsala dokumentace. Spíš bych řekl, že naopak - pokud někdo nepíše dokumentaci, tak nemá vůbec šanci uspět se svojí knihovnou. Uznávám, že nevím, jak je na tom haskell. Různé jazyky jsou různé, ale nepouštěl bych tvrzení o pythonu jen na základě zkušenosti s haskellem.

*součást většího seriálu o pythonu v praxi, datum vydání nejdřív za pár měsíců.

Netřeba. Je to jen a pouze má zkušenost, a mé vysoké nároky které kladu na dokumentaci. A jsou to zkušenosti z používání Pythonu a Haskellu. Co se dokumentace týče, tak jsou na tom stejně. Stejně blbě. Proto mi vyhovuje, že u toho Haskellu se můžu spolehnout alespoň na něco.

1768

Vývoj / Re:Má Python budoucnost?

« kdy: 12. 05. 2016, 17:36:58 »

Není explicitní typová signatura v haskellu nepoviná?

Protože má automatické odvozování typu.

V pythonu můžete do docstringu přidat jednoduchý test.

např:

def format(a):
    """Formátuje argument a
    >>> format('hello')
    '<p>hello</p>'
    """
    return '<p>%s</p>' % a


který spustíte python -m doctest nazev_souboru.py

To je hezký (bez ironie).

Četl jsem*, argument je stále stejný. Tohle je problém který vůbec nesouvisí s pythonem, protože je stejný všude. Špatně udělanou dokumentaci prostě typový systém nijak nespasí. Nehledě na to, že když je takhle prasácky udělaná dokumentace, tak nemám žádný důvod předpokládat, že typové anotace budou dobře.

*pokud se v tom teda neztrácím.

Snažíš se narvat do otevřených dveří.

Python i Haskell má stejný problém. Nepíše se dokumentace.
Faktem je, že v Pythonu máš pouze dokumentaci. Jejíž kvalita stojí a padá na vývojáři.
V Haskellu základní věci dokumentovat nemusíš, protože ti to zdokumentuje Typovej systém. Ten ti taky zajistí, že to bude aktuální a korektní.
V Haskellu nemůžeš napsat špatné typové anotace. (Můžou neodpovídat zadání, to samozřejmě jo.)

1769

Vývoj / Re:Má Python budoucnost?

« kdy: 12. 05. 2016, 16:21:34 »

Když mám mám v Pythonu funkci:

def format(a):
   """Formátuje argument a"""
...

tak mám dělat jako co prosím?

Aha, protože tohle je fakt problém pythonu a vůbec ne demence vývojáře, která se nedá napsat v libovolném jazyce. Fakt by mě zajímalo, co se tím přesně snažíš dokázat, protože to samé můžu napsat v libovolném jazyce, třeba v Javě:

Kód: (java) [Vybrat]

// Formátuje a.
public static string format(Object a){
    ...
}

To ti ty typové anotoce fakt pomůžou, že?

A nechtěl by sis přečíst celý můj příspěvek? Tak hrozný romány to zase nejsou...

1770

Vývoj / Re:Má Python budoucnost?

« kdy: 12. 05. 2016, 16:12:10 »

Což by vyznělo mnohel líp, když by se do té dokumentace nemuselo psát to, co v silně typovaných jazycích získáš signaturou. Takhle je to taková znouzecnost.

Uznávám, psát m.__doc__ je fikaný. Sice to umí i to pitomé PHP, ale Python to má tak nějak hezčejš. Což je bohužel ono.

Python je hezký jazyk. Ale chytrý ne. Je to taková blondýna.

To vyzni dobre vzdycky, dokumentace je soucasti jazyka a nejde o to, ze lze psat m.__doc__, ale ze toho vyuzivaji ruzne nastroje, vcetne ide a ze lze z programu generovat dokumentaci.

No, nemohu si teď rychle vzpomenout na jazyk, u kterého z kódu nelze generovat dokumentaci.

Zato si třeba nedovedu představit, jak bych z kódu v Pythonu strojově generoval případy užití (z účelem obohacení dokumentace). Možná by to šlo ručním odvozování typů, ...

Ad blondyna. To jsou hloupy reci, kterymi ukazujes detinskou predpojatost, ktera disivalifikuje tve nazory, jednoduse je nelze brat vazne.

Přiznávám určitou předpojatost. Dlouho jsem si dělal naději, že budu používat Python jako můj hlavní jazyk. Těšil jsem se na komunitu, snadnost psaní, pohodlnost a znovupoužitelnost, flexibilitu.

Naučil jsem se ho. A celkem dlouho používal. Napsal jsem v něm i pár pěknejch věcí.

No, a naštval mě. Takže ano, jsem předpojatý. Nebo možná spíše zklamaný.