Má Python budoucnost?

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

Co je na tom nic neříkajícího?

Docstring v pythonu často obsahuje příklad použití, který mohu spustit jako test.

To má Haskell taky.

Prosím nezaměňujte typovou deklaraci s dokumentací. Haskell má úplně stejný problém jako Python s tím, že vývojáři flákaj dokumentaci. Výhodou Haskellu v tomto je ta, že si jazyk vynutí alespoň tu siganturu.

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

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

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

[Reklama]

[Zopper]

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

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

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

Přečíst si tělo funkce. Dokumentace je stejně skoro vždycky out of date... 

[BoneFlute]

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

[Bystroushaak]

Rozhodne neobhajujte neco, jen proto ze v tom delate. Mam podezreni, ze to je duvod, proc tu to PHP jeste porad strasi. Vyvijim v JavaScriptu a rozhodne nemam potrebu ho do nebe vychvalovat. Mam na neho spise neutralni nazor, rozhodne by me nenapadlo vsem cpat NodeJS na server, kdyz si myslim, ze se to hodi jen na mikro weby (v podstate nastejno jak ten Python nebo Ruby).

To rozhodně nemám v plánu.

Jinak dělám v py nikoliv proto, že bych musel, nebo protože by mi to bylo vnuceno někde na škole. V roce 2007 jsem zkoumal co dál, tak jsem sepsal 2 stránky pro a proti všemožných jazyků, všechny je prozkoumal, pročetl wikipedii, homepage, zkusil si je nainstalovat a napsat v nich něco triviálního, ohodnotil je subjektivními body a pak si z nich vybral python. A od té doby v něm dělám a posledních několik let mě za to i lidi platí.

Na vetsi veci se mi zda neprakticky, protoze zacnete pocitovat ty chybejici typy (musite vyvazovat dokumentaci, casem a testy navic) a nepodporou IDE (at uz refaktorovani nebo treba navigaci).

Zrovna tohle je typický argument. O pythonu už jsem tu vedl několik diskuzí, které vždycky skončí stejně: já ukážu na nějaký projekt, dodám zkušenost s práce na větším systému (desítky tisíc řádků podle cloc bez komentářů, prázdných řádků a tak) a ostatní se hádají, že to prostě nemůže fungovat, i když to funguje.

Pak se to zvrhne na hádku o typových systémech, kde javisti dokazují, že když to nefunguje jako v javě, tak to nemůže být použitelné pro cokoliv kromě trivialit, pythonisti se frustrovaně snaží vysvětlit, že to fakt funguje, což je prostě pozorování, ne teorie, pak přijde někdo s tím, že ducktyping je bullshit a že mu nerozumí, haskellisti, ocamlisti a další typoví guru se smějí na pozadí. Do toho přijdou lopaťáci, kteří začnou vykřikovat cosi o lopatách, trolové, kteří prostě jen krmí některý z táborů čímkoliv, na co budou reagovat a drama je na světě.

Ono vůbec, u pythonu narážím na to, že spousta lidí vůbec nechápe, že má svojí vlastní filosofii a nejde jen tak přijít z javy, naučit se základy syntaxe a začít v něm javit, protože pak z toho lezou výblitky, které je horor udržovat a tohle pak javisti berou jako důkaz, že python nestojí za nic.

Stejne jako u PHP, ani u Pythonu nerikam, ze to nejde (vim, ze se tak deje a firmy jsou casto nuceny pak prepisovat cele svoje zivobyti z PHP/Pythonu/Ruby kvuli vykonu/udrzovatelnosti do Javy/C#/Scaly) - jen tvrdim, ze je to nevhodny nastroj. Ostatne i TeX je turing-complete, takze nic nebrani firme, aby back-end pro web psali v TeXu. Jen se obavam, ze by brzy skoncila, pokud by tedy vubec nekdy zacala (kdo by chtel BE v TeXu? kdo by chtel psat BE v TeXu?).

Skvělá šikmá plocha. Protože lopatička není koloběžka, tak ani v javě se nedá psát komplexní projekt.

Že to nedává smysl? No, to tyhle jazykové analogie fakt nedávají, což ale nikomu nebrání je používat, že. Tady se třeba cosi snažíš dokázat na TeXu, který má s pythonem společného co? Nic.

Po pravde mam z Pythonu pocit, ze OOP podporuje jen na oko (chybejici modifikatory pristupu, __háky__, nutnost predavat metodam self a uvadet self pro pristup k poli objektu, atd.) a FP jednou omylem nekdo chtel zkusit a uz to nejak v jazyce zustalo, prestoze ty vlastnosti jsou tam celkem nanic.

Já mám zas pocit, že nemáš tušení co je to OOP, ani FP. Modifikátory přístupu například vůbec v původním OOP (smalltalk, self) nebyly a ani být nemusí. To je jen demence, když to pak roubovali na pokroucený zprasený systém C++ a Javy (Oaku, heh).

Python podporuje „privátní“ atributy pomocí __, kde ti interpreter vyhodí chybu, když k tomu zkusíš přistoupit.

Kód: [Vybrat]

>>> class Xe(object):
...  def __private(self):
...   return 1
...
>>> x = Xe()
>>> x.__private()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Xe' object has no attribute '__private'

Na druhou stranu ti v tom fakt nebude bránit, pokud víš co děláš:

Kód: [Vybrat]

>>> x._Xe__private()
1

Což je podle mě v pořádku. Když programátor fakt ví co chce, tak si může dělat co chceš a ty jako programátor knihovny mu v tom nezabráníš, i kdyby ses posral a nadefinoval si private úplně všechno. To jen lidi co přichází z Javy / C# mají urputný pocit, že když to neudělají, tak dojde ke konci světa. Nedojde. Prostě to spadne někomu, kdo dělá věci co by neměl, což není můj problém. Naopak progrmátorům, kteří ví co dělají a třeba chtějí jen mocknout nějakou hodnotu pro účely testování to může ušetřit shitload práce.

Jinak kdysi jsem na tom byl stejně, takže chápu, kde se tahle mentalita bere, můžu tě ale ujistit, že je to falešný pocit nutnosti něčeho, co fakt nutné není.

__háky__

Magické metody jsou naopak docela chytrý koncept systematizovaného metaobjektového komunikačního protokolu. Stěžovat si na ně je stejná blbost, jako stěžovat si na konvenci používání metody nazvané toString() v jiných jazycích.

nutnost predavat metodam self a uvadet self pro pristup k poli objektu

Jo, to se může jevit jako opruz. Na druhou stranu to umožňuje dekorátorům pracovat s instancemi objektu za běhu, což se používá v pokročilém metaprogramování. Má to i pár dalších výhod a dává to konzistentní smysl, ale to člověk nevidí, dokud nepřekročí základy.

Ono argumentovat popularitou je dost ošemetné. Kdybych to měl přirovnat třeba k hudbě, tak takový Justin Bieber má na YT miliardy shlédnutí a přitom objektivně jeho produkce stojí za hovno. Popularita a kvalita bohužel ne vždy jdou ruku v ruce a často se vyloženě rozcházejí. Někdy se to krásně sejde, ale jedno automaticky nevyplývá z druhého.

Hahah. Tohle mě pobavilo, hlavně proto, že pamatuju ještě ty časy, kdy tomu tak nebylo a lidi argumentovali proti pythonu tím, že je nepopulární a v čechách v něm moc lidí nedělá. Teď je populární a lidi argumentují zase opakem

[Bystroushaak]

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?

[Reklama]

[BoneFlute]

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

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

Co je na tom nic neříkajícího?

Docstring v pythonu často obsahuje příklad použití, který mohu spustit jako test.

To má Haskell taky.

Prosím nezaměňujte typovou deklaraci s dokumentací. Haskell má úplně stejný problém jako Python s tím, že vývojáři flákaj dokumentaci. Výhodou Haskellu v tomto je ta, že si jazyk vynutí alespoň tu siganturu.

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

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

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

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

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

[Bystroushaak]

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

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

[Kit]

nutnost predavat metodam self a uvadet self pro pristup k poli objektu

Jo, to se může jevit jako opruz. Na druhou stranu to umožňuje dekorátorům pracovat s instancemi objektu za běhu, což se používá v pokročilém metaprogramování. Má to i pár dalších výhod a dává to konzistentní smysl, ale to člověk nevidí, dokud nepřekročí základy.

Tohle jsem zpočátku viděl jako opruz, ale dnes to vidím jako velkou výhodu, protože je velmi snadno rozlišitelné, která proměnná je instanční a která lokální. V Javě se také musí při kolizi používat "this".

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

Co je na tom nic neříkajícího?

Docstring v pythonu často obsahuje příklad použití, který mohu spustit jako test.

To má Haskell taky.

Prosím nezaměňujte typovou deklaraci s dokumentací. Haskell má úplně stejný problém jako Python s tím, že vývojáři flákaj dokumentaci. Výhodou Haskellu v tomto je ta, že si jazyk vynutí alespoň tu siganturu.

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

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

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

Doctestová knihovna pro haskell sice existuje, ale používá jí někdo?

[BoneFlute]

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

[Bystroushaak]

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

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

[BoneFlute]

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.

[noef]

Na vetsi veci se mi zda neprakticky, protoze zacnete pocitovat ty chybejici typy (musite vyvazovat dokumentaci, casem a testy navic) a nepodporou IDE (at uz refaktorovani nebo treba navigaci).

Zrovna tohle je typický argument. O pythonu už jsem tu vedl několik diskuzí, které vždycky skončí stejně: já ukážu na nějaký projekt, dodám zkušenost s práce na větším systému (desítky tisíc řádků podle cloc bez komentářů, prázdných řádků a tak) a ostatní se hádají, že to prostě nemůže fungovat, i když to funguje.

Ehm, vzdyt na to jsem odpovel v prispevku, ktery citujete.

Stejne jako u PHP, ani u Pythonu nerikam, ze to nejde ... jen tvrdim, ze je to nevhodny nastroj.

a ten drivejsi, na ktery jsem se odkazoval:

...
Jak pise Kit, programovat se da i v takovem bordelu, jen clovek musi presne vedet, kam nema slapat, aby neprisel o nohu.
...
Prakticky se pouziva, dokonce i na dost velke veci. Naopak veci v Pythonu nebo JavaScriptu s trochu vic radky bych se bal udrzovat. Bez typu se hezky vyviji v malickem meritku s malo lidmi, ale jakmile se to rozroste a uz nemate v hlave mentalni model cele aplikace, tak mate problem. V Jave/Scale vam pomuze IDE a prekladac vam kdyztak vynada, v JavaScriptu nebo Pythonu je to mnohem horsi. Treba v JS musite spolehat na dokumentaci a IDE, ze to nejak prechroupe a zobrazi zhruba co by mohlo sedet k tomu, co potrebujete.

(V podstate to stejne pise BoneFlute - v dynamickych jazycich si musite vypomahat dobrovolnymi typy v dokumentaci, ve statickych je vynucuje prekladac.)

Pak se to zvrhne na hádku o typových systémech, kde javisti dokazují, že když to nefunguje jako v javě, tak to nemůže být použitelné pro cokoliv kromě trivialit, pythonisti se frustrovaně snaží vysvětlit, že to fakt funguje, což je prostě pozorování, ne teorie, pak přijde někdo s tím, že ducktyping je bullshit a že mu nerozumí, haskellisti, ocamlisti a další typoví guru se smějí na pozadí. Do toho přijdou lopaťáci, kteří začnou vykřikovat cosi o lopatách, trolové, kteří prostě jen krmí některý z táborů čímkoliv, na co budou reagovat a drama je na světě.

Nikdy jsem nepsal (viz citace vyse), ze to nejde bez statickych typu, jen ze je to zbytecny opruz. Opravdu nevim, jestli podle vas jsem v nejake z tech kategorii, protoze prvni kategorii nesplnuji, pythonista nejsem (ocividne), ducktyping pouzivam denne v praci a na typoveho guru se moc necitim, kdyz pomalu nedavam ani zaklady ScalaZ (celkem hardcore FP knihovna).

Ono vůbec, u pythonu narážím na to, že spousta lidí vůbec nechápe, že má svojí vlastní filosofii a nejde jen tak přijít z javy, naučit se základy syntaxe a začít v něm javit, protože pak z toho lezou výblitky, které je horor udržovat a tohle pak javisti berou jako důkaz, že python nestojí za nic.

Python jsem zkousel (spise byl nucen pouzivat) po urcitych zkusenostech s C#, Javou a Scalou. Naopak jsem srovnaval se Scalou, protoze Python mi byl popisovan jako krasny a celkem strucny jazyk, ve kterem se rychle vyviji. Jak z mych prispevku vyplvyva, ma ocekavani nesplnil. Po pravde po zkusenostech s kolekcemi ze Scaly nevim, zda vubec nejaky jazyk se ji priblizil (napr. v Pythonu* nelze ani pomalu psat funckionalne [ukecane lambdy, chybejici retezeni]; JavaScript je funkcionalni, od ES6 umi i hezky kondenzovane fat-arrow funkce, ale bez externi knihovny take hodne slaby [co se vyberu funkci tyce]).

*: Nasel jsem jakesi reseni v podobe doimplementovani pipe opratoru a preimplementovani zabudovanych funkci jako map nebo filter na curried variantu. IMO celkem hnusne reseni - narovnavak na ohybak.

Stejne jako u PHP, ani u Pythonu nerikam, ze to nejde (vim, ze se tak deje a firmy jsou casto nuceny pak prepisovat cele svoje zivobyti z PHP/Pythonu/Ruby kvuli vykonu/udrzovatelnosti do Javy/C#/Scaly) - jen tvrdim, ze je to nevhodny nastroj. Ostatne i TeX je turing-complete, takze nic nebrani firme, aby back-end pro web psali v TeXu. Jen se obavam, ze by brzy skoncila, pokud by tedy vubec nekdy zacala (kdo by chtel BE v TeXu? kdo by chtel psat BE v TeXu?).

Skvělá šikmá plocha. Protože lopatička není koloběžka, tak ani v javě se nedá psát komplexní projekt.

Že to nedává smysl? No, to tyhle jazykové analogie fakt nedávají, což ale nikomu nebrání je používat, že. Tady se třeba cosi snažíš dokázat na TeXu, který má s pythonem společného co? Nic.

Opet, nerikam ze se v TeXu neda napsat skvely back-end, jen to podle me neni vhodny nastroj (stejne jako Python - takze neco spolecneho maji) a minimalne z dlouhodobeho hlediska se to prodrazi. Sam bych nejradsi misto JavaScriptu pouzival treba TypeScript nebo ScalaJS, vetsinu chyb by odhalil prekladac a nemusel bych ani nic testovat. A to nyni v podstate vyvijim v jednom cloveku jen par mesicu, takze je to pidi projekt oproti tomu, co pisete. Mit treba projekt v Pythonu (nebo klidne i NodeJS, at nerikate, ze jsem zaujaty vuci Pythonu) o desitkach nebo stovkach tisicu radek s nekolika vyvojari stary treba 5 let? Eh, hned bych hledal zpusob, jak prejit jinam, kor kdybych prisel k hotovemu a nevedel o tom projektu zhola nic.

Po pravde mam z Pythonu pocit, ze OOP podporuje jen na oko (chybejici modifikatory pristupu, __háky__, nutnost predavat metodam self a uvadet self pro pristup k poli objektu, atd.) a FP jednou omylem nekdo chtel zkusit a uz to nejak v jazyce zustalo, prestoze ty vlastnosti jsou tam celkem nanic.

Já mám zas pocit, že nemáš tušení co je to OOP, ani FP. Modifikátory přístupu například vůbec v původním OOP (smalltalk, self) nebyly a ani být nemusí. To je jen demence, když to pak roubovali na pokroucený zprasený systém C++ a Javy (Oaku, heh).

Ano, priznavam, ze puvodni OOP neznam (aktualni prakticky pouzivane OOP ano). Ale nejak se mi nepozdava, ze treba zapouzdreni by tam chybelo, coz snad ty modifikatory pristupu zajistuji. K tomu, ze neznam FP jsi nejak nic nenapsal. Jako nutne to nevyvracim, ale zaklady FP si myslim znam celkem dobre. A pokud jazyk chce byt trosku funkcionalni, tak nutnost pouzivat hacky k dosazeni beznych operaci umoznujicich ono FP mi prijde dost mimo.

Python podporuje „privátní“ atributy pomocí __, kde ti interpreter vyhodí chybu, když k tomu zkusíš přistoupit.
...
Na druhou stranu ti v tom fakt nebude bránit, pokud víš co děláš:

Kód: [Vybrat]

>>> x._Xe__private()
1


Tohle me prijde jako prilis snadne obejiti zapouzdreni (a ano, i v JavaScriptu bych uvital modifikatory pristupu, ne jen skryvani "privatnich" promennych do closure). Ono i v Java svete nebyva problem pomoci reflexe nebo primo pres bytekod tridy zpristupnit privatni data, ale je to o uroven dal, nez jen zavolat jinak pojmenovanou metodu (programator opravdu vi, ze dela neco hodne nestandardniho a nestava se, ze novacci pouzivaji privatni veci, protoze neni tak trivialni k nim pristupovat).

Což je podle mě v pořádku. Když programátor fakt ví co chce, tak si může dělat co chceš a ty jako programátor knihovny mu v tom nezabráníš, i kdyby ses posral a nadefinoval si private úplně všechno. To jen lidi co přichází z Javy / C# mají urputný pocit, že když to neudělají, tak dojde ke konci světa. Nedojde. Prostě to spadne někomu, kdo dělá věci co by neměl, což není můj problém. Naopak progrmátorům, kteří ví co dělají a třeba chtějí jen mocknout nějakou hodnotu pro účely testování to může ušetřit shitload práce.

Jinak kdysi jsem na tom byl stejně, takže chápu, kde se tahle mentalita bere, můžu tě ale ujistit, že je to falešný pocit nutnosti něčeho, co fakt nutné není.

Osobne to preferuji, kdyz mi jazyk primo umoznuje omezovat pristup. Prijde me, ze do tymu je to mnohem lepsi pristup. Kdyz se opet podivam do JS sveta, tak tam byvaji nehezke zaludne a tezce dohledatelne bugy, kdyz se nekdo, nebo jeste lepe nejaka knihovna, rozhodne "opravit" funkci nejakeho standardniho typu (monkey patching).

__háky__

Magické metody jsou naopak docela chytrý koncept systematizovaného metaobjektového komunikačního protokolu. Stěžovat si na ně je stejná blbost, jako stěžovat si na konvenci používání metody nazvané toString() v jiných jazycích.

Zcela uprimne - prijde me to ohavne, to jsem od "krasneho" jazyka necekal. Proc radeji nezvolili jiny znak, pouze 1 znak, jako prefix, proc radeji 2x 2 podtrzitka?

Reflexe je i v jinych jazycich (jestli to chapu dobre) a vetsinou je povazovana za zverstvo, ktere se smi pouzivat pouze ve velmi specifickych pripadech typu knihovny kvuli hezci syntaxi. Podobne jako eval v JavaScriptu. Ma sice sve misto, ale v normalnim projektu typu web to misto rozhodne neni.

nutnost predavat metodam self a uvadet self pro pristup k poli objektu

Jo, to se může jevit jako opruz. Na druhou stranu to umožňuje dekorátorům pracovat s instancemi objektu za běhu, což se používá v pokročilém metaprogramování. Má to i pár dalších výhod a dává to konzistentní smysl, ale to člověk nevidí, dokud nepřekročí základy.

Troufam si rict, ze v JavaScriptu jsem davno prekrocil zaklady, a rozhodne nemam v lasce nutnost vsude ve tride uvadet "this". CoffeeScript to vyresil celkem elegantne, misto "this" prisel s jednim znakem - @. Po pravde az v Pythonu vidim, ze se musi pouzivat this/self i jako parametr metody. Nevim, ja to vse vnimam tak, ze je to do Pythonu dolepene.

Ono argumentovat popularitou je dost ošemetné. Kdybych to měl přirovnat třeba k hudbě, tak takový Justin Bieber má na YT miliardy shlédnutí a přitom objektivně jeho produkce stojí za hovno. Popularita a kvalita bohužel ne vždy jdou ruku v ruce a často se vyloženě rozcházejí. Někdy se to krásně sejde, ale jedno automaticky nevyplývá z druhého.

Hahah. Tohle mě pobavilo, hlavně proto, že pamatuju ještě ty časy, kdy tomu tak nebylo a lidi argumentovali proti pythonu tím, že je nepopulární a v čechách v něm moc lidí nedělá. Teď je populární a lidi argumentují zase opakem

To, ze je jazyk popularni jej nedela dobrym (meh, PHP nebo i starsi verze JavaScriptu nejsou nejake prevratne) a ani naopak.

Mimochodem Python je tu opravdu tak popularni? Vsude v inzeratech totiz vidim jen Javu a C# na ty velke veci. Na male naopak jen PHP .

A celkove, nemate nekdo nejake statistiky o popularite jazyku u firem v CR/SK? By me zajimal treba takovy Haskell (slysel jsem, ze i v Brne v nem kdesi delaji) nebo Scala ci Groovy.

[Kit]

Ano, priznavam, ze puvodni OOP neznam (aktualni prakticky pouzivane OOP ano). Ale nejak se mi nepozdava, ze treba zapouzdreni by tam chybelo, coz snad ty modifikatory pristupu zajistuji.

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.