Má Python budoucnost?

[Youda]

Kazy jouda pouzivajici tvuj objekt ti jej muze rozbit. U toho singletonu zvlaste, kde kazdy automaticky zavola konstruktor, namisto ClassName.getInstance()

Upřímně, můj názor je že chránit se takto před něčím, co kdyby je, zbytečné. Každý programátor by měl psát dokumentaci a každý programátor by ji měl číst. Nedej bože by měl dodržova i standard daného jazyka. Kdo to nedělá tak není programátor a sebelepší programovací jazyk ho nezachrání. Když ho rozbije je to jeho chyba, jemu ten program nebude fungovat.

Delal jste uz na projektu, na kterem pracovalo 2 a vice lidi?
Kdyz nekteri ti lidi byli z Indie?

Tak nekoho mozna bavi resit nesmyslne bugreporty od lidi, co objekt pouzili nezamyslenym zpusobem, nekdo zase svuj objekt zkratka zabezpeci. (Treba tim inspectem outer calleru )

[Reklama]

[Youda]

Myslím že volnost je ta hlavní vlastnost, nikdo tě nenutí dodržovat OOP přesně do puntíku. Naproti tomu v Java nutí programátora do OOP a programátoři to pak prostě různě obcházejí.

Java na jedné straně nutí do OOP, na druhé straně to programátoři obchází přes gettery a settery. A ještě se tím chlubí.

Gettery/settery nejak koliduji s OOP? Ja dosud zil v domeni, ze to je jedna ze zakladnich OOP vlastnosti (zapouzdreni stavu objektu a kontrolovany pristup k atributum)
Zajimave, prosim vysvetleni.

[v]

Řetězení transformací je chytlavý nešvar FP, nedá se to dobře testovat.

To pouze odpovida nekolika prikazum za sebou. Nebo bezne snad testujete jen polovinu metody objektu, napr. jen prvni tri prikazy, ikdyz jich metoda obsahuje 20? Treba v Jave to asi mozne je, ale nevim proc to delat.

A v konečném důsledku je to podobné, jako když funkce má 12 parametrů.

Ne, neni. Stejne jako mit 12 prikazu v metode neznamena, ze je to stejne jako mit 12 parametru.

Python je navržen schválně tak, aby nic nešlo lehce řetězit.

S tim souhlasim, je zamerne navrzen tak, aby v nem neslo elegentne provozovat FP. Ostatne myslim, ze i samotny tvurce se k tomu tak vyjadril, ze FP je pro neho na druhe koleji. Cely Python je zamerne navrzen tak, aby byl ukecany, coz nemam rad - jazyk je hezky pro novacky, jakmile ale po chvili povysi na znale, tak najednou vidi vsude tu ukecanost pro zacatecniky, ktera pokrocilym uz ale nic neprinasi. Nevzniklo ostatne proto Ruby?

Dobře, když máte výraz x = a(b(c(d(e(f(g)))))), tak jak otestujete, která funkce je špatně bez přepisování kódu. Jak se dozvíte, co je výsledkem c na reálných datech?

čím je ten příklad specifický pro funkcionální programování? v pythonu by to bylo úplně stejné

[Youda]

V Javě tyhlety gettery ani settery nepoužívám, protože je k ničemu nepotřebuji. Na privátní atributy objektu mi tak nikdo hrabat nebude. Případný debuglog injektuji do konstruktoru.

Singleton je antipatternem, který má své účelné použití například u vzoru NullObject. Jinak je vcelku bezvýznamný.

Tohle prilis nechapu. Jakym zpusobem mi debuglog v konstrutoru umozni zalogovat, ze nekdo v 13:00:23 nastavil atribut "teplota" z "33" na "45"?

Ze Singleton (navrzeny a popsany Gang of Four) je antipattern je pomerne odvazne tvrzeni.
A vzhledem k tomu, ze defaultni scope Spring beanu je prave Singleton, je to tvrzeni o to odvaznejsi.
Zrejme budou lidi kolem Springu banda matlaku.

[Kit]

V Javě tyhlety gettery ani settery nepoužívám, protože je k ničemu nepotřebuji. Na privátní atributy objektu mi tak nikdo hrabat nebude. Případný debuglog injektuji do konstruktoru.

Tohle prilis nechapu. Jakym zpusobem mi debuglog v konstrutoru umozni zalogovat, ze nekdo v 13:00:23 nastavil atribut "teplota" z "33" na "45"?

Při každé změně teploty v objektu se zavolá ten debuglog. Do konstruktoru se injektuje ten debuglogger nebo zmíněný NullObject, který v té logovací metodě nebude dělat nic.

[Reklama]

[BoneFlute]

To co já považuju na Pythonu za velice dobrého je, že nutí všechny vývojáře psát stejně strukturovaný kód (pravda kopírování kódu je pak občas peklo)

To má Haskell taky.

a dále že přímo integruje dokumentaci. Součástí definice jazyka je prostě i způsob jak dokumentovat a nástoje (žlutou vlnovkou) opozorňují že dokumentace chybí. Příjde mi prostě, že python jako takový vynucuje slušné programátorské zvyklosti, to je celé. Že je ukecaný, to místy trochu je, ale alespoň není kryptický.

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.

[BoneFlute]

Ze Singleton (navrzeny a popsany Gang of Four) je antipattern je pomerne odvazne tvrzeni.
A vzhledem k tomu, ze defaultni scope Spring beanu je prave Singleton, je to tvrzeni o to odvaznejsi.
Zrejme budou lidi kolem Springu banda matlaku.

Lidi ze Spring banda matláků není. Nezaměňuj odvahu a invenci za bezchybnost a zbožňování.

Ona spousta věcí z GoF jsou špatné nápady. Ale je fajn, že jsou pojmenované, a můžem se o nich bavit. Autorů si maximálně vážím, ale to mi nebrání o jejich závěrech špekulovat.

[ROFL]

Při každé změně teploty v objektu se zavolá ten debuglog.

Tohle bych taky prosil vysvětlit. V Pythonu nedělám, takže nevím, jestli existuje třeba nějaký event pro změnu hodnot vlastností. Nicméně tohle mi připadá, že mluvíte čistě o nějaké metodě setTemperature, ve které se rovnou zavolá i log(co mi to ale jenom připomíná...), zatímco my mluvíme o přímém přiřazení a.temperature = 123.

[Youda]

V Javě tyhlety gettery ani settery nepoužívám, protože je k ničemu nepotřebuji. Na privátní atributy objektu mi tak nikdo hrabat nebude. Případný debuglog injektuji do konstruktoru.

Tohle prilis nechapu. Jakym zpusobem mi debuglog v konstrutoru umozni zalogovat, ze nekdo v 13:00:23 nastavil atribut "teplota" z "33" na "45"?

Při každé změně teploty v objektu se zavolá ten debuglog. Do konstruktoru se injektuje ten debuglogger nebo zmíněný NullObject, který v té logovací metodě nebude dělat nic.

Porad to nechapu.
Mam class Teplomer, z neho objekt tepolomer a v nem public tribut teplota.

Nekdo z venku nastavi atribut:
teplomer.teplota = 45

Jak se invokuje to zalogovani provedene zmeny atributu?


Rychly google mi ukazal toto:
http://stackoverflow.com/questions/6190468/how-to-trigger-function-on-value-change

Podle toho odkazu mam pouzit pattern Observer (taky Gang of Four) anebo gettery/settery na @property, coz je to same, co java getter/setter approach...

Takze nakonec to v Pythonu jde uplne stejne jako v Jave, akorat se tahle dira v navrhu musela dodelat dekoratorem @property... A ochrana proti primemu zapisu atributu tam stejne neni.

[Citrisin]

... zatímco my mluvíme o přímém přiřazení a.temperature = 123.

Viz několik příspěvků zpět. Přetížení přiřazení.

V Pythonu se __setattr__ používá spíš k přetěžování operátoru přiřazení. Tedy nikoli k omezení, ale k rozšíření funkcionality objektu.

[BoneFlute]

Kdyby byl Python nepouzitelny jazyk, jak tvrdis, tak ho nikdo nebude pouzivat, ale on je naopak siroce pouzivany.

To je docela hezká argumentace. Ale doufám, že si uvědumuješ že má svá úskalí. Jak napsal kdosi kdesi, "Nejlepší jídlo jídlo je výkal. Tisíce much se nemůže mýlit."

Tak todle moc čitelné není a je to v haskellu (přebráno z GitHubu):

onCreate :: JNIEnv -> JObject -> JObject -> IO ()
onCreate env activity _bundle = runJNISafe () env $ do
  msg <- liftIO $ do
    getNumProcessors >>= setNumCapabilities
    caps <- getNumCapabilities
    return $ "Hello World!\nRunning on " `append` pack (show caps) `append` " CPUs!"

Co se mě týče, přijde mi tak od pohledu, že tuším, co to dělá. Ačkoliv to runJNISafe() mi trochu smrdí, a říkám si, že jsi vyhrabal prostě nějakou prasečinu.

[Bystroushaak]

... zatímco my mluvíme o přímém přiřazení a.temperature = 123.

Viz několik příspěvků zpět. Přetížení přiřazení.

V Pythonu se __setattr__ používá spíš k přetěžování operátoru přiřazení. Tedy nikoli k omezení, ale k rozšíření funkcionality objektu.

Tohle se běžně neřeší přes __setattr__, ale setter dekorátor.

http://stackoverflow.com/questions/6618002/python-property-versus-getters-and-setters

[zboj]

proměnné typu boolean nepoužívám. Bez náhrady. Těm aplikacím to prostě nechybí.

Nechodím sem často, ale skoro vždycky tady prezentujete nějaký neotřelý koncept, o kterém by mě nenapadlo ani uvažovat. Jste génius. Sepište knihu o programování. Okamžitě si jí koupím a otevřu jí vždycky, když budu mít špatnou náladu, zaručeně pobaví.

Na to stačí Ovčáček

[Youda]

Viz několik příspěvků zpět. Přetížení přiřazení.

Tak pretezovani standardnich operatoru je v mem zebricku jazykovych/programatorskych prasecin bezkonkurecne na prvnim miste.
Kdo tohle vymyslel, ten by mel byt bicovan kazde rano a nucen poslouchat Country Radio do obeda. Slysis, Stroustrupe?

Neni vetsi poteseni, nez pretizit "+", aby delal "-".

[noef]

Dobře, když máte výraz x = a(b(c(d(e(f(g)))))), tak jak otestujete, která funkce je špatně bez přepisování kódu. Jak se dozvíte, co je výsledkem c na reálných datech?

A jak se to vztahuje k FP? To jako ze tam jsou funkce tak je to FP? To co jste uvedl (asi) nepouziva ani funkce vyssich radu, vypada to jako normalni imperativni kod. Co mi brani to takto napsat v Pythonu, nebo pripadne v jazyce, ktery zadne extra FP ficury nema?

Kdyby byl Python nepouzitelny jazyk, jak tvrdis, tak ho nikdo nebude pouzivat, ale on je naopak siroce pouzivany.

Staci se podivat na PHP. Jazyk, ktery mel byt utracen davno (hrozna "specifikace", jazyk i interpret), je to jako splacane od zacinajiciho studentika VS, presto tu dal uspesne preziva. Kvalita nema bohuzel s popularitou nic spolecneho.

Rec je o pouzitelnosti, nikoliv kvalite a popularite. Je dobre rozlisovat mezi akademickou kvalitou a praktickou pouzitelnosti a zamyslet se, proc se tem akademickym jazykum v praxi tolik nedari. Velmi pravdepodobne v posouzeni kvality jazyka bude kazdy zduraznovat jine vlastnosti, rozhodne bych to neredukoval jen na cistotu syntaxe.

Tak napr. PHP je nekvalitni v tolika aspektech (casti jazyka nespecifikovane, std knihovna nema/nedodrzuje zadne konvence pojmenovani a navratovych hodnot, parser je patlany a casto jsou tam nesmysle podminky jen kvuli jednoduchosti implementace [takovou hruzu jsem nevidel snad v zadnem jinem bezne pouzivanem jazyce], konfigurace se provadi na mnoha mistech a to i u veci ze std knihovny [compile flagy, config v ini souboru, config v aplikaci, parametry dane funkce]) a rekl bych, ze prave proto i spatne pouzitelny. Byl jen na dobrem miste v dobry cas a napsalo se pro neho spostu kodu (a rozjelo dost hostingu), ktery se lidem nechce opoustet, tak u neho zustavaji. Jak pise Kit, programovat se da i v takovem bordelu, jen clovek musi presne vedet, kam nema slapat, aby neprisel o nohu.

Ja ho naopak preferuji a uprednostnuji kde muzu a nemusim naopak Javu, ktera me osobne prijde celkove tezkopadna a neohrabana.

Python me prijde stejne neohrabany jako Java. Moc to nesleduju, ale Java 8 myslim prinasela dost FP veci, coz vede k mnohem jednodussimu kodu. Osobne me prijde Scala jako dobry kompromis mezi uplatnitelnosti (JVM) a "krasou" jazyka (velmi jednoduse zapsane slozite veci, podpora DSL, FP atd).

Neumim si predstavit, ze bych neco jako scala pouzival prakticky, tj. ze bych mel odvahu to nasadit u zakaznika v rozsahu desitek tisic radkukodu a udrzoval/rozvijel to 15+ let. Pro me je to neduveryhodny a proto _prakticky_ nepouzitelny jazyk.

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

V Pythonu me vadi velke mnozstvi boilerplatu (napr. @property, @staticmethod, lambda, nenasel jsem zpusob, jak lehce retezit volani funkci, takze pokusy o FP styl pusobi hrozne) a kod celkove pusobi roztahane.

Samozrejme na Haskell, co se tyce "krasy" a strucnosti, as nic moc nema*. A to jsem v nem "noob", pamatuji si ho pouze ze skoly. Ale uz i jen ty zaklady byly nezapomenutelne (pro ostatni studenty spise v tom spatnem slova smyslu ).
*: Resp. nic lepsiho jsem jeste nevidel. Pokud neco znate, tak sem s tim.

Dekoratory nejsou boilerplate, to je naopak reseni eliminujici boilerplate, ktere vede k prehlednosti a strucnosti, nejsou povinne a jsou velmi flexibilni, muzes si je prizpusobit svym potrebam. Na haskellu mi nic krasneho neprijde, ale nema smysl porovnavat funkcionalni jazyk s imperativnim a tomu druhemu vycitat opacny stav. Argument, ze pokusy programovat v haskellu imperativne vypada hrozne, bych osobne povazoval za fail :-).

Je to kod, navic na cely radek (alespon tak to vsude vidim), ktery se casto opakuje. Stejne tak lambda - v jinych jazycich vidime co nejkrasi zapis, jako treba ->, => nebo \, v Pythonu je to ale cele slovo? Snad hur na tom byval jen JavaScript a i ten to uz napravil.

Ale Haskell nezavadi imperativni programovani jako nejakou svou feature, castecne ho umoznuje pomoci do notace. Python naopak se vsi slavou zavedl ruzne ficury z FP sveta (zakladni funkce nebo ty ukecane lambdy), ale uz se jaksi zapomnelo na to, ze jsou skoro nepouzitelne, protoze nejdou hezky retezit .

A naopak, moznost program casto a co nejdriv spoustet je jedna z vyhod interpretovanych jazyku.

Vzhledem k tomu, ze existuji inkrementalni prekladace (tusim ze jej ma Java i Scala a urcite mnoho dalsich), tak tohle je standard, ne vyhoda. Stejne tak i kompilovana Scala ma REPL, take to neni vyhrada Pythonu nebo interpretovanych jazyku.

Neni to standard a naopak, ze se o to snazi i kompilovane jazyky jen dokazuje, ze to ma smysl a je to vyhodou pro kazdy jazyk, ktery to umi.

Snazi? Ony to uz davno umi, vzdyt jinak by vyvoj v Jave byl hrozny, kdyby se vse vzdy muselo prekladat od 0. To by nesly rozumne psat (a testovat) ty dinosauri enterprise aplikace.

REPL pokud vim je i pro Javu, jen ne zatim oficialni (jestli se nepletu, tak je to soucasti nejakeho navrhu). JavaScript ma NodeJS, nebo primo prohlizec; ruby je na tom stejne jako Python, v Haskellu staci pusti ghci, atd.

To, ze Python ma REPL, ho nad konkurenci rozhodne nevysouva.