OOP je sprosta, skodliva a necitliva antropomorfizace pocitacu!
Pryc s ni. #MEETOOP!
Jenom to nejhorsi :)Preco to najhorsie?
Já se teda domnívám, že OOP byl a je pěkný xindl. A to se dala Jásiru Arafatovi ještě Nobelova cena míru. 8)
Jen bych chtel zminit takovou drobnost ktera se tyka abuzu polymorfismu. A nebo obecneji, na abuzu zobecnovani - protoze polymorfizmus je zobecnovani. To by cloveka treba nenpadlo, ze neco takoveho existuje, nez dojde na velky zabordelovany projekt, kde se hojne vyuziva polymorfizmus - on totiz dokaze uplne znicit statickou analyzu kodu metodou generovani method call hierarchiii, coz je extremne dulezity nastroj pro orientaci v kodu. Tzn. ja se ridim tim, ze kdyz neni nutne abstrahovat, tak to nedelam, ikdyz to udelat jde. Drive jsem si myslel, ze musim abstrahovat automaticky, kdyz to jde. Ono neni zase tak spatne napsat toho kodu trochu vic, nez by se muselo, pokud to povede k citelnejsimu programu jako celku.
Cargo kult. Tedy aspon v nasi firme.
Implementace C interface (exportovane funkce z DLL/SO), kazda funkce vypada takto:Cargo kult. Tedy aspon v nasi firme.nejake vtipne detaily z nataceni mas?
Myslím že tuším, co má na mysli. V původním OOP (třeba Smalltalk) jsou objekty něco, co přijímá požadavky a nějak je řeší. Těm objektům se nevolají přímo metody ale posílají jim zprávy, co je třeba udělat. Myslím, že daleko lepší název by byl "service" nebo možná i "actor" něco podobného. Na rozdíl od Javovských objektů jsou ty Smalltalkovské daleko autonomnější.OOP je sprosta, skodliva a necitliva antropomorfizace pocitacu!
Pryc s ni. #MEETOOP!
to je celkem vtipny komentar, ale proc antropomorfizace???
objekt neni nijak zavisly na lidskych vlastnostech, objekt je proste jen nejaka struktura.
i mimozemstani muzou klasifikovat veci a objekty.
Polymorfizmus je celkom performance hit
OOP je nastroj, bud ho pouzijes dobre, nebo blbe.
OOP neni svaty gral.
No ty teda dobre trepes :)Polymorfizmus je celkom performance hit
Právě naopak. S masivním využitím polymorfismu se mé skripty nejen zpřehlednily, ale i zrychlily.
Prýmek je místní übertroll.Jenom to nejhorsi :)Preco to najhorsie?
Já se teda domnívám, že OOP byl a je pěkný xindl. A to se dala Jásiru Arafatovi ještě Nobelova cena míru. 8)
dobry, ale tady se diskutuje Object Oriented Programing a ne rucnikari.
Dle mého dává smysl u velkých monolitických oblud. Pokud máte microservices, už to žádné velké benefity nemá.Monolit neni antipattern :) A nejsou microservices vicemene OOP prevedene do distribuovaneho systemu service(object) a zasilani zprav? :)
Zase to tam není složité, takže lze použít i tam. Pokud tu monolitickou zrůdu rozmlátíte na kousky, taky nemusí být objektová.
Preferuju všechno rozsekané na malé kousky :) pak je mi naprosto jedno v čem to je napsané.
Preco to najhorsie?Myslel jsem to "mainstream OOP" (C++, Java apod.)
Ma oop za nasledok zhorsenie performance aplikacie? Ak teda zoberiem c# a javu do uvahy, tak o oop nemozno hovorit, len o akomsi napodobneni.
Dokazal byste nekdo nadefinovat oop? Lidi se tu ztraci v semantice.Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.
Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.Tomu se dneska (bohužel) říká spíš "agentní systém" nebo "actor model".
Proto tvrdě prosazuji návrat k tomu původnímu smyslu. Pro to byl ten název vymyšlen. Že tím dnes většina lidí myslí C++ nebo Javu je jen důkazem, že to celé vůbec nepochopili (včetně tvůrců těch jazyků). Současné mainstreamové pojetí je cargo kult jak vyšitý.Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.Tomu se dneska (bohužel) říká spíš "agentní systém" nebo "actor model".
Ono to taky vychází z toho, že si vybrali fakt blbý název. Všude kromě OOP se "objekt" říká něčemu, co rozumí akorát tak zprávě "zůstaň". Jestli by nebylo lepší se vrátit k původní myšlence s nějakým lepším jménem. :)Proto tvrdě prosazuji návrat k tomu původnímu smyslu. Pro to byl ten název vymyšlen. Že tím dnes většina lidí myslí C++ nebo Javu je jen důkazem, že to celé vůbec nepochopili (včetně tvůrců těch jazyků). Současné mainstreamové pojetí je cargo kult jak vyšitý.Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.Tomu se dneska (bohužel) říká spíš "agentní systém" nebo "actor model".
Dokazal byste nekdo nadefinovat oop? Lidi se tu ztraci v semantice.Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.
Ja pracujem na projekte kde oop je dost zastupene a tolko abstrakcie som este nikde nevidel a mam pocit, ze je to niekedy az prekomplikovane a uplne zbytocne.
Jestli by nebylo lepší se vrátit k původní myšlence s nějakým lepším jménem. :)No to je právě ten "agent" nebo "actor" :) Lepší je imho "actor". Sice to zní trochu exoticky, ale "agent" na sebe nabaluje speciální význam, který mu byl dán v podoboru "multiagentní systémy" (takže různé ty komunikační jazyky KQML, ACL, sémantiky/ontologie atd.)
Se mi líbí, jak když někdo něco nepochopí, tak tvrdí, že to "nikdo" nechápe. Čemu přesně nerozumíš?Dokazal byste nekdo nadefinovat oop? Lidi se tu ztraci v semantice.Ne. Každý si pod tím představuje trochu něco jiného. Pro mě to je to, co tím mysleli otcové-zakladatelé, tj. Alan Kay a spol.
Alan Kay ma svoji definici kterou neustale omila a nikdo ji nechape. Precet jsem o tom neapocer jeho komentaru i posledni clanky na quore a HN kam prispiva. Rad bych, aby tu jeho definici nekdo tady vysvetlil, nez se budem bavit dal.
To je dobre ze tomu nekdo jako ty rozumi.- objekt jako černá krabička, která může mít stav, přijímá a vysílá zprávy, pomocí nichž interaguje s okolím; množina zpráv na něž reaguje a způsob jak tak činí je čistě v gesci objektu (může se to v čase i měnit)
Vysvetli mi tedy
- svoji definici oop
- priklad systemu co hodne lidi zna co je oop
- na ktery pripady bys pouzil oop jestli vubec
- kterej programovaci jazyk je skutecne oop. Nebo kterej byl jestli vubec kdy byl
- použil bych ho u problémů, které se přirozeně rozpadají na autonomní podproblémy a je účelné je na tyto autonomní jednotky separovat z důvodů přehlednosti, substituovatelnosti, znovupoužitelnosti a testováníPopravdě, tohle toho moc neříká. Dělit problémy na menší a jednodušší kusy se snaží úplně všechna paradigmata. Je to akorát rozkecané "použil bych ho tam, kde se hodí". Někdo, komu OOP několikrát nebouchlo do obličeje, ví kulové, kdy je to účelné a kdy není.
To ano, ale tady jsem měl na mysli právě tu autonomii. Že sám o sobě je ten objekt "životaschopný". Pokud použiju klasickou strukturovanou dekompozici, tak toto nezbytně neplatí (dokonce to bude platit málokdy).- použil bych ho u problémů, které se přirozeně rozpadají na autonomní podproblémy a je účelné je na tyto autonomní jednotky separovat z důvodů přehlednosti, substituovatelnosti, znovupoužitelnosti a testováníPopravdě, tohle toho moc neříká. Dělit problémy na menší a jednodušší kusy se snaží úplně všechna paradigmata. Je to akorát rozkecané "použil bych ho tam, kde se hodí". Někdo, komu OOP několikrát nebouchlo do obličeje, ví kulové, kdy je to účelné a kdy není.
To je dobre ze tomu nekdo jako ty rozumi.- objekt jako černá krabička, která může mít stav, přijímá a vysílá zprávy, pomocí nichž interaguje s okolím; množina zpráv na něž reaguje a způsob jak tak činí je čistě v gesci objektu (může se to v čase i měnit)
Vysvetli mi tedy
- svoji definici oop
- priklad systemu co hodne lidi zna co je oop
- na ktery pripady bys pouzil oop jestli vubec
- kterej programovaci jazyk je skutecne oop. Nebo kterej byl jestli vubec kdy byl
- použil bych ho u problémů, které se přirozeně rozpadají na autonomní podproblémy a je účelné je na tyto autonomní jednotky separovat z důvodů přehlednosti, substituovatelnosti, znovupoužitelnosti a testování
- Smalltalk
- kterej programovaci jazyk je skutecne oop. Nebo kterej byl jestli vubec kdy bylObjective-C
Kadet,
prijde mi, ze se snazis najit obecne reseni/popis/pristup na pomerne konkretni vec. Coz ti vetsinou nevyjde. Kdyz prirovname ten objekt k cihle, tak s tim pracujes jako s cihlou (nejdriv hezky vedle sebe a pak dalsi radek) otazka zni jestli stejnej objekt pouzijes i na stavbu mrakodrapu (tam bys asi pouzil objekt pilir a stavel ho nahoru a pak okolo nej).
Tahle prednaska by se ti mohla libit: https://www.youtube.com/watch?v=OSGv2VnC0go
Nerikam, ze vystihuje presne to na co se ptas. S tema objektama, vem si ze mas objekt "session" nebo "user" a potom mas nejaky objekt "message" a "log". Na kazdy mozna pouzijes jiny navrhovy vzor. Kdyz se budes snazit implementovat jeden a ten samy na vsechny, nebo najit nejaky super obecny, asi ti to nevyjde.
Pojem oop uz strasi tenhle svet dostatecne , dlouho tak si zaslouzi nejakou definici, at se chudaci juniori maji od ceho odpichnout. Pokud se definice nenajde, protoze si pod tim kazdej predstavuje neco jinyho, tak je to taky dobrej poznatek. Muze se pak celej pojem oop zahodit a vyresi se tim spousta semantickych nedorozumeni.
Jinak ja se bavim o modelovani realnyho sveta. Napr. business problemu. V takovym problemu figuruje cas. Kazdy z techto problemu muze byt namapovan na nejaky reaktivni system. Pokud v systemu nefiguruje cas, pak se da takovy problem reprezentovat pouhou statickou funkci, ktera mapuje vstupy na vystupy. Pak zadny oop neni treba, staci napsat obyc funkci a poskladat ji z mensich funkci atd.
Pojem oop uz strasi tenhle svet dostatecne , dlouho tak si zaslouzi nejakou definici, at se chudaci juniori maji od ceho odpichnout. Pokud se definice nenajde, protoze si pod tim kazdej predstavuje neco jinyho, tak je to taky dobrej poznatek. Muze se pak celej pojem oop zahodit a vyresi se tim spousta semantickych nedorozumeni.
Jinak ja se bavim o modelovani realnyho sveta. Napr. business problemu. V takovym problemu figuruje cas. Kazdy z techto problemu muze byt namapovan na nejaky reaktivni system. Pokud v systemu nefiguruje cas, pak se da takovy problem reprezentovat pouhou statickou funkci, ktera mapuje vstupy na vystupy. Pak zadny oop neni treba, staci napsat obyc funkci a poskladat ji z mensich funkci atd.
Podivej se na ten koncept co pouziva Trailblazer (http://trailblazer.to/) a predevsim (http://trailblazer.to/gems/cells/)
Netvrdim, ze to je to nejlepsi a jediny, ale ty koncepcni casti a to jak "uchopili" problem se mi zamlouva. Jenze taky rozumim tomu, ze ne vzdycky to sedi/je mozny podle "modeloveho prikladu". Neboli jestli chces zobecnit "realnej svet" na nejakou tridu/sablonu, neuspejes. Jdu se mrknout na tu prednasku cos poslal, jsem zvedavej. Dik za link.
Kdyz vezmeme v potaz treba onen "log" ve chvili kdy ti to plive nejakej vystup do "souboru" je to asi fuk, ale ve chvili, kdy chces treba pouzit ruzny "system" do kterejch to loguje, prave treba polymorfizmus je na to jak delanej. Cili podle toho jestli je instance of "loguj do sentry" nebo "loguj do souboru" nebo "loguj do graylogu", ohnes to strasne jednoduse a nezabordeli se ti to. Protoze nekde ve tride volas jenom Log.write(message).
Shodou okolnosti ten prvni link co jsem ti poslal na tu prednasku tak tam pan velmi dobre vysvetluje, ze chces vracet iteratable misto dict a nemusis pak delat zbytecny bastleni.
Rozdíl oproti C++like jazykům vidím hlavně v eleganciRozdíl je hlavně v tom, že poslání zprávy a volání funkce je úplně něco jiného. C++ to pomíchalo a lidi to přestali rozlišovat. K jeho dobru je třeba říct, že k tomu byl docela pádnej důvod (výkon). Ale výsledek je bohužel smutnej.
Předně dynamické typování vnímám jako nezbytnost pro objektový přístup.A to je podle mě přesně ta výš zmíněná chyba. Obvykle tohle totiž řekne člověk, kterej ví, že "opravdové OOP" potřebuje něco flexibilnějšího než volání compile-time metod (např. pro respondsToSelector) a v tomhle smyslu je to celkem i pravda.
Pojem oop uz strasi tenhle svet dostatecne , dlouho tak si zaslouzi nejakou definici, at se chudaci juniori maji od ceho odpichnout. Pokud se definice nenajde, protoze si pod tim kazdej predstavuje neco jinyho, tak je to taky dobrej poznatek. Muze se pak celej pojem oop zahodit a vyresi se tim spousta semantickych nedorozumeni.
Jinak ja se bavim o modelovani realnyho sveta. Napr. business problemu. V takovym problemu figuruje cas. Kazdy z techto problemu muze byt namapovan na nejaky reaktivni system. Pokud v systemu nefiguruje cas, pak se da takovy problem reprezentovat pouhou statickou funkci, ktera mapuje vstupy na vystupy. Pak zadny oop neni treba, staci napsat obyc funkci a poskladat ji z mensich funkci atd.
Podivej se na ten koncept co pouziva Trailblazer (http://trailblazer.to/) a predevsim (http://trailblazer.to/gems/cells/)
Netvrdim, ze to je to nejlepsi a jediny, ale ty koncepcni casti a to jak "uchopili" problem se mi zamlouva. Jenze taky rozumim tomu, ze ne vzdycky to sedi/je mozny podle "modeloveho prikladu". Neboli jestli chces zobecnit "realnej svet" na nejakou tridu/sablonu, neuspejes. Jdu se mrknout na tu prednasku cos poslal, jsem zvedavej. Dik za link.
Kdyz vezmeme v potaz treba onen "log" ve chvili kdy ti to plive nejakej vystup do "souboru" je to asi fuk, ale ve chvili, kdy chces treba pouzit ruzny "system" do kterejch to loguje, prave treba polymorfizmus je na to jak delanej. Cili podle toho jestli je instance of "loguj do sentry" nebo "loguj do souboru" nebo "loguj do graylogu", ohnes to strasne jednoduse a nezabordeli se ti to. Protoze nekde ve tride volas jenom Log.write(message).
Shodou okolnosti ten prvni link co jsem ti poslal na tu prednasku tak tam pan velmi dobre vysvetluje, ze chces vracet iteratable misto dict a nemusis pak delat zbytecny bastleni.
Nejvic polymorfickej mechanismus co znam jsou unix pipes a files. Misto toho abych v pythonu nebo jave bastlil svoji reimplementaci polymorfismu na logovani, radsi udelam
Sys.stderr.write(message)
A zabalim celrj program do nejakyho shell skriptu nebo systemd unit configu, kterej mi to redirectne do graylogu, sentry, do filu, systemd journalu.
Nac tahat zbytecny zavislosti na tyhle externi sluzby do jednoduchyho python skriptu. Kdyz to chce nekdo pustit na cli a podivat se na vystup, at ten log plivne do stderr. Kdyz to chce nekdo plivnout do graylogu, klidne muze.
Sam uz vis, ze je lepsi vracet iterator nez statickej list nebo dict. Pak zjstis ze celej takovej problem muzes namapovat na streamovaci system coz je jeste obecnejsi nez iterator. Ale to uz je lekce c.2.
Pojem oop uz strasi tenhle svet dostatecne , dlouho tak si zaslouzi nejakou definici, at se chudaci juniori maji od ceho odpichnout. Pokud se definice nenajde, protoze si pod tim kazdej predstavuje neco jinyho, tak je to taky dobrej poznatek. Muze se pak celej pojem oop zahodit a vyresi se tim spousta semantickych nedorozumeni.
Jinak ja se bavim o modelovani realnyho sveta. Napr. business problemu. V takovym problemu figuruje cas. Kazdy z techto problemu muze byt namapovan na nejaky reaktivni system. Pokud v systemu nefiguruje cas, pak se da takovy problem reprezentovat pouhou statickou funkci, ktera mapuje vstupy na vystupy. Pak zadny oop neni treba, staci napsat obyc funkci a poskladat ji z mensich funkci atd.
Podivej se na ten koncept co pouziva Trailblazer (http://trailblazer.to/) a predevsim (http://trailblazer.to/gems/cells/)
Netvrdim, ze to je to nejlepsi a jediny, ale ty koncepcni casti a to jak "uchopili" problem se mi zamlouva. Jenze taky rozumim tomu, ze ne vzdycky to sedi/je mozny podle "modeloveho prikladu". Neboli jestli chces zobecnit "realnej svet" na nejakou tridu/sablonu, neuspejes. Jdu se mrknout na tu prednasku cos poslal, jsem zvedavej. Dik za link.
Kdyz vezmeme v potaz treba onen "log" ve chvili kdy ti to plive nejakej vystup do "souboru" je to asi fuk, ale ve chvili, kdy chces treba pouzit ruzny "system" do kterejch to loguje, prave treba polymorfizmus je na to jak delanej. Cili podle toho jestli je instance of "loguj do sentry" nebo "loguj do souboru" nebo "loguj do graylogu", ohnes to strasne jednoduse a nezabordeli se ti to. Protoze nekde ve tride volas jenom Log.write(message).
Shodou okolnosti ten prvni link co jsem ti poslal na tu prednasku tak tam pan velmi dobre vysvetluje, ze chces vracet iteratable misto dict a nemusis pak delat zbytecny bastleni.
Nejvic polymorfickej mechanismus co znam jsou unix pipes a files. Misto toho abych v pythonu nebo jave bastlil svoji reimplementaci polymorfismu na logovani, radsi udelam
Sys.stderr.write(message)
A zabalim celrj program do nejakyho shell skriptu nebo systemd unit configu, kterej mi to redirectne do graylogu, sentry, do filu, systemd journalu.
Nac tahat zbytecny zavislosti na tyhle externi sluzby do jednoduchyho python skriptu. Kdyz to chce nekdo pustit na cli a podivat se na vystup, at ten log plivne do stderr. Kdyz to chce nekdo plivnout do graylogu, klidne muze.
Sam uz vis, ze je lepsi vracet iterator nez statickej list nebo dict. Pak zjstis ze celej takovej problem muzes namapovat na streamovaci system coz je jeste obecnejsi nez iterator. Ale to uz je lekce c.2.
Skouknul jsem tu prednasku a od zacatku mi to prislo, ze misto tridy proste jenom nekdo chtel napsat "helper" bo jak tam rikal "my heap toolkit". Rozhodne jsou tam jsou hezky veci a dik za sharing.
Tvuj problem je, ze ty vidis "jednoduchej" python script, to cos napsal za jako modelovej priklad pak vypada, ze to vyjde. Jenze pokud se bavis o necem vetsim nez je par funkci ktery nekde neco berou a nekam to davaj uz ti to nevyjde. Mas predpoklad, ze mas k dispozici bash cili to co nevybordelis ve svym pythonu zacnes bordelit ve svym bashi, kterej treba na windowsech neni, stejne jako existence systemd je dalsi "hard dependency". To mas jako kdyz chces bejt nekdo database agnostic nebo platform agnostic, ale zaroven reknes, ze to bezi jenom na linuxu s postgresem :)
To co ti chci rict, zes sis "vytvoril konkretni problem" a nasel sis na nej "konkretni reseni", ale zaroven tu pises, ze chces "obecny principy" a "realny svet". Navzajem se to vylucuje.
Kdyz delas skript tak delas skript a pokrocily "techniky/pristupy" v tom resi nemusis, protoze je to konkretni skrtip na reseni konkretniho problemu. Pokud mas aplikaci, ktera resi treba logovani a analyzu hovoru pro call centrum, muzes to napsat jako 300 skriptu ktery budes nejak importovat jeden do druhyho, nebo to muzes napsat jako clovek, kdy sice budes mit ve finale 500 souboru a 200 trid, ale aspon se to bude dat cist, testovat a rozsirovat a ne z toho delat nejaky spagety a dalsich 20 berlickovejch bashu okolo toho.
Jestli tady jde o premerovani udu a dogmatickou demagogii kde minimalismus je doktrina a zadna promena nebude mit vic jak tri pismenka, prosim jak je libo. Klidne ti i reknu ze mas pravdu a ze to tak je nejlepsi, kdyz te to potesi ;)
Salut.
Podle mě se v tom strašně pipláte. Z praktického pohledu mě nikdy nenapadlo nad tím tak dumat. Jen vnímám rozdíly, resp. to, co mě irituje jinde. Mě vůbec připadá, že se tady strašně teoretizuje, místo aby si lidi prakticky zkusili A, pak B a pak řešili, v čem se jim dělá lépe.Rozdíl oproti C++like jazykům vidím hlavně v eleganciRozdíl je hlavně v tom, že poslání zprávy a volání funkce je úplně něco jiného. C++ to pomíchalo a lidi to přestali rozlišovat. K jeho dobru je třeba říct, že k tomu byl docela pádnej důvod (výkon). Ale výsledek je bohužel smutnej.Předně dynamické typování vnímám jako nezbytnost pro objektový přístup.A to je podle mě přesně ta výš zmíněná chyba. Obvykle tohle totiž řekne člověk, kterej ví, že "opravdové OOP" potřebuje něco flexibilnějšího než volání compile-time metod (např. pro respondsToSelector) a v tomhle smyslu je to celkem i pravda.
Ve skutečnosti ale není. Protože posílání zpráv NENÍ volání funkcí. Čili to s tím vůbec nesouvisí. Zprávy můžou být klidně typované, vnitřek actoru může být klidně typovaný, není to žádný problém. Protože zprávy se prostě zpracovávají úplně jiným mechanismem než se volají funkce.
Viz Erlang, Elixir: to jsou prakticky dva jazyky v jednom: struktura jednoho je daná strukturou komunikace (kdo komu posílá co), druhé je "běžný" funkcionální jazyk (který sice není typovaný, ale klidně by mohl být).
C++ to nepomíchalo. Objektový model C++ je +- převzatý ze Simuly.Rozdíl oproti C++like jazykům vidím hlavně v eleganciRozdíl je hlavně v tom, že poslání zprávy a volání funkce je úplně něco jiného. C++ to pomíchalo a lidi to přestali rozlišovat. K jeho dobru je třeba říct, že k tomu byl docela pádnej důvod (výkon). Ale výsledek je bohužel smutnej.
Podle mě se v tom strašně pipláte. Z praktického pohledu mě nikdy nenapadlo nad tím tak dumat. Jen vnímám rozdíly, resp. to, co mě irituje jinde. Mě vůbec připadá, že se tady strašně teoretizuje, místo aby si lidi prakticky zkusili A, pak B a pak řešili, v čem se jim dělá lépe.Ne, tohle není žádná teoretická onanie. Má to konkrétní (tragické) důsledky. Ten asi nejhorší ze všech je, že když máš posílání zpráv implementované (jednoduše) jako volání metod, tak při vícevláknovém zpracování ti vznikají race conditions. Což je přesně to, co to dnešní praseOOP dostává do kolen. A co by se nemohlo stát, kdyby se tyhle dvě věci nemíchaly.
C++ to nepomíchalo. Objektový model C++ je +- převzatý ze Simuly.V C++ se žádné zprávy do žádných inboxů neposílají. V C++ se posílání zpráv markýruje voláním (potenciálně virtuálních) metod.
Jo, pardon, špatně jsem tu větu pochopil. Ok, díky za upřesnění. Nechtěl jsem říct, že to Stoustrup vymyslel, ale že to zpopularizoval. Což byl podle mě (multi)million dollar mistake.C++ to nepomíchalo. Objektový model C++ je +- převzatý ze Simuly.V C++ se žádné zprávy do žádných inboxů neposílají. V C++ se posílání zpráv markýruje voláním (potenciálně virtuálních) metod.
Tohle mi připadá jako opačný extrém.Podle mě se v tom strašně pipláte. Z praktického pohledu mě nikdy nenapadlo nad tím tak dumat. Jen vnímám rozdíly, resp. to, co mě irituje jinde. Mě vůbec připadá, že se tady strašně teoretizuje, místo aby si lidi prakticky zkusili A, pak B a pak řešili, v čem se jim dělá lépe.Ne, tohle není žádná teoretická onanie. Má to konkrétní (tragické) důsledky. Ten asi nejhorší ze všech je, že když máš posílání zpráv implementované (jednoduše) jako volání metod, tak při vícevláknovém zpracování ti vznikají race conditions. Což je přesně to, co to dnešní praseOOP dostává do kolen. A co by se nemohlo stát, kdyby se tyhle dvě věci nemíchaly.
Je to velice praktická věc, akorát ten "teoretický" problém jako příčinu ne každý vidí, protože prostě nic jinýho neviděl, nezažil. Proto bych každýmu fakt vřele doporučoval si zkusit ten Elixir, aby mu to mohlo docvaknout. Zprávy jsou zprávy, mají se posílat do inboxu, odtud vybírat a (dle libovůle) zpracovávat. Žádný nesmysly typu vlákno Pes teď vlezlo do třídy Kočka. Pes je pes a kočka je kočka. Stačí to jenom nemíchat, tak snadné to je :)
Rozdíl je hlavně v tom, že poslání zprávy a volání funkce je úplně něco jiného. C++ to pomíchalo a lidi to přestali rozlišovat.Poslani synchronni zpravy a volani funkce je to same. Nebo preferujete asynchronni posilani zprav, kazdy obekt s vlastnim vlaknem, handlerem a obrovskym balastem navic? Prijde Vam soucasny SW prilis optimalizovany, chcete ho jeste viz zpomalit?
Poslani synchronni zpravy a volani funkce je to same.V jakém smyslu?
Nebo preferujete asynchronni posilani zprav, kazdy obekt s vlastnim vlaknem, handlerem a obrovskym balastem navic?Není potřeba vlastní vlákno. Nevím, co si mám představit pod handlerem. Jaký "obrovský balast"?
Poslani synchronni zpravy a volani funkce je to same.V jakém smyslu?Nebo preferujete asynchronni posilani zprav, kazdy obekt s vlastnim vlaknem, handlerem a obrovskym balastem navic?Není potřeba vlastní vlákno. Nevím, co si mám představit pod handlerem. Jaký "obrovský balast"?
Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.Green threading? A jsme zpet u kooperativniho multitaskingu jako ve win 3.11. A neni nejlepsi cely ten balast zahodit a rovnou zavolat metodu?
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Go má kooperativní scheduler a jak skvěle šlape...Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.Green threading? A jsme zpet u kooperativniho multitaskingu
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Go má kooperativní scheduler a jak skvěle šlape...Jiste, na dnesnich CPU bezi rychle vsechno. Ale mohlo by i rychleji.
Debilně napsaný kód bude vždy pomalejší. Vypovídací hodnota nula.Go má kooperativní scheduler a jak skvěle šlape...Jiste, na dnesnich CPU bezi rychle vsechno. Ale mohlo by i rychleji.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go-gpp.html
Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.Tak to asi bude dost záležet na definicích pojmů. Nemám potřebu se o ně přít ani je řešit. To, co je opravdu důležitý, je, že actors komunikují pouze pomocí předávání dat, tj. nesdílejí ani paměť, ani jiné zdroje, čili z principu nemůže nastat race condition jako u OOP, nemusí se používat žádné zběsilé zámky, kritické sekce a podobné srandy. Pořád existuje problém deadlocku kvůli možným kruhovým závislostem, ale to asi žádné extraelegantní řešení stejně nemá (aspoň já o něm nevím).
Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.
Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.Green threading? A jsme zpet u kooperativniho multitaskingu jako ve win 3.11. A neni nejlepsi cely ten balast zahodit a rovnou zavolat metodu?
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
To je pravda, ale jen v rámci jednoho adresního prostoru.Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totezPoslani synchronni zpravy a volani funkce je to same.V jakém smyslu?Nebo preferujete asynchronni posilani zprav, kazdy obekt s vlastnim vlaknem, handlerem a obrovskym balastem navic?Není potřeba vlastní vlákno. Nevím, co si mám představit pod handlerem. Jaký "obrovský balast"?
Tak těmto definicím vyhovuje PHP docela dobře, tedy alespoň v mých aplikacích.To není definice, jenom znínění dvou vlastností, které jsou podstatné pro ten protipříklad.
To je pravda, ale jen v rámci jednoho adresního prostoru.Znova opakuju: v jakém smyslu je to pravda (v rámci jednoho adresního prostoru)?
Kdyz usporadam jeho operace v kodu podle toho jak pujdou po sobe, dokonce.ten kod zacne vypadat jako synchronni. Ale presto muzu volat jeho jednotlivy 'metody'.Přiznám se, že vůbec nejsem schopnej dešifrovat, co se snažíš sdělit :)
Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.Tak to asi bude dost záležet na definicích pojmů. Nemám potřebu se o ně přít ani je řešit. To, co je opravdu důležitý, je, že actors komunikují pouze pomocí předávání dat, tj. nesdílejí ani paměť, ani jiné zdroje, čili z principu nemůže nastat race condition jako u OOP, nemusí se používat žádné zběsilé zámky, kritické sekce a podobné srandy. Pořád existuje problém deadlocku kvůli možným kruhovým závislostem, ale to asi žádné extraelegantní řešení stejně nemá (aspoň já o něm nevím).
Jestli dvěma goroutinám, které si posílají zprávy pomocí kanálu někdo chce nebo nechce říkat "dvě vlákna", je mi celkem jedno. Skutečné OS vlákno to může být jenom jedno a žádná tragická performance penalty tam není (btw, stejný princip se používá i v embedded), ani žádné extrabuřthandlery ani jiný "obrovský balast".
Kdyz usporadam jeho operace v kodu podle toho jak pujdou po sobe, dokonce.ten kod zacne vypadat jako synchronni. Ale presto muzu volat jeho jednotlivy 'metody'.Přiznám se, že vůbec nejsem schopnej dešifrovat, co se snažíš sdělit :)
Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat. Vysilac muze vysilat data najakou funkci napr. send(data) a prijimac obsahuje naky handler napr. ondatareceive(data).Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.
Ja jsem nikde nezminil nic o konkretni implementaci frajere.
Mohli bychom zustat v v rovine akademicke diskuse?
Mirku, ten, kdo posila tu zpravu neztraci ihned kontrolu v pripade synchronniho (blokujiciho) volani, jak jsem zminoval. Tj. Tazatel po odeslani zamrzne vyjma toho, ze je schopen prijmout odpoved na svoji odeslanou zpravu. Tazatel a odpovidatel se muzou koordinovat pomoci unikatniho klice (correlation id), ktere svazuje request a response k sobe.Já teď nevím, o čem mluvíš. Jestli o "mainstream OOP", "původním OOP", actor modelu nebo nějaké své představě. Pokud o actor modelu, tak nemáš pravdu hned v několika bodech.
Ano, kazdy agent funguje jakoby plne ve svym pocitaci, s vlastnimi zdroji, ve vlastnim vlakne. Jak moc blizko se tehle abstrakce v softwaru implementujicim agenty/actory dosahne je irelevantni. Konceptualne jsou plne izolovani.Souhlas - jak je to implementované je irelevantní, pokud jsou splněné jisté požadavky.
Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat.A v tom se právě mýlíš. V actor modelu i "původním OOP" můžeš mít objekt, který na jakoukoli zprávu odpoví "sorry, nerozumím". Opět: v pseudoOOP implementovaném pomocí volání metod to není realizovatelné.
Nemusí, přesně ten příklad s proxy je přiléhavý. Prostě vezmu zprávu, aniž bych jí sám rozuměl, a pošlu ji někam dál.Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat. Vysilac muze vysilat data najakou funkci napr. send(data) a prijimac obsahuje naky handler napr. ondatareceive(data).Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.
Prostou zamenou volani send() za ondatareceive() se zmenilo vysilani zpravy na volani metody.
To je v zásadě pravda, ale otázka je, co pak dělá to ondatareceive.Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat. Vysilac muze vysilat data najakou funkci napr. send(data) a prijimac obsahuje naky handler napr. ondatareceive(data).Volani funkce a synchronni poslani zpravy, tj. zaslani pozadavku a obdrzeni odpovedi, jsou skutecne totez, pokue je to v ramci programovaciho jazyka.Tak já zkusím jeden protipříklad: když se skutečně předává zpráva, tak se předávají data a 1. ten, kdo je předává nad nimi ztrácí jakoukoliv kontrolu, 2. příjemce jim nutně nemusí rozumět. Čili jde například udělat velmi snadno obecnou RPC proxy, která umí proxovat cokoli, i to, co v době jejího překladu ještě vůbec neexistuje. S voláním metod tohle udělat nejde.
Prostou zamenou volani send() za ondatareceive() se zmenilo vysilani zpravy na volani metody.
Volá se funkce podle nějakého ABI, konkrétní implementace závisí na jazyce, ale umí to třeba i Java.To je pravda, ale jen v rámci jednoho adresního prostoru.Znova opakuju: v jakém smyslu je to pravda (v rámci jednoho adresního prostoru)?
Volá se funkce podle nějakého ABI, konkrétní implementace závisí na jazyce, ale umí to třeba i Java.Jak v Javě napíšeš třídu, na které když zavoláš jakoukoli - tj. i v době překladu neznámou metodu, tak ti vrátí string "Sorry, I do not understand"?
To je v zásadě pravda.Ne, není to pravda. Bacsa mixuje úroveň jazyka (volání metody vs. předání dat) a jeho implementaci (konkrétní implementace předání dat vs. nějaké to vyhledávání ve virtuální tabulce, ASM CALL apod.)
Volá se funkce podle nějakého ABI, konkrétní implementace závisí na jazyce, ale umí to třeba i Java.Jak v Javě napíšeš třídu, na které když zavoláš jakoukoli - tj. i v době překladu neznámou metodu, tak ti vrátí string "Sorry, I do not understand"?
Pokud to jde (nevím), tak nějak extrémně krkolomně. Přitom tohle by měl být základ skutečného OOP.
Je to stejně “krkolomné” jako ve Smalltalku.Ve Smalltalku je to, pokud se nepletu, na dva řádky. Můžeš ukázat tu implementaci v Javě? Je taky na dva řádky?
Jen doplním - ve Smalltalku:Je to stejně “krkolomné” jako ve Smalltalku.Ve Smalltalku je to, pokud se nepletu, na dva řádky. Můžeš ukázat tu implementaci v Javě? Je taky na dva řádky?
doesNotUnderstand: aMessage
^ 'Unknown message: ', aMessage asString
V Javě to bude standardně na tři řádky kvůli uzavírací závorce. Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.Jen doplním - ve Smalltalku:Je to stejně “krkolomné” jako ve Smalltalku.Ve Smalltalku je to, pokud se nepletu, na dva řádky. Můžeš ukázat tu implementaci v Javě? Je taky na dva řádky?Kód: [Vybrat]doesNotUnderstand: aMessage
^ 'Unknown message: ', aMessage asString
int nakafunkce(...) { return ERR_NOT_SUPPORTED;}Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat.A v tom se právě mýlíš. V actor modelu i "původním OOP" můžeš mít objekt, který na jakoukoli zprávu odpoví "sorry, nerozumím". Opět: v pseudoOOP implementovaném pomocí volání metod to není realizovatelné.
To je v zásadě pravda, ale otázka je, co pak dělá to ondatareceive.Asi se podiva do vstupnich dat, nejak je parsuje a nejak na ne reaguje.
To same je, kdyz ondatareceive(...) zavola nejakyjinyondatareceive(...).Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat. Vysilac muze vysilat data najakou funkci napr. send(data) a prijimac obsahuje naky handler napr. ondatareceive(data).Nemusí, přesně ten příklad s proxy je přiléhavý. Prostě vezmu zprávu, aniž bych jí sám rozuměl, a pošlu ji někam dál.
Prostou zamenou volani send() za ondatareceive() se zmenilo vysilani zpravy na volani metody.
int nakafunkce(...) { return ERR_NOT_SUPPORTED;}Na jakoukoli zprávu, ne na zprávu "nakafunkce".
nakafunkce(...) je handler vsech zprav. Ocekaval jsem, ze si to domyslite.int nakafunkce(...) { return ERR_NOT_SUPPORTED;}Na jakoukoli zprávu, ne na zprávu "nakafunkce".
On myslí dynamický dispatch, to by v Javě byla metoda invoke (obdoba forward), z jejíchž parametrů lze vyčíst jméno původně volané metody.int nakafunkce(...) { return ERR_NOT_SUPPORTED;}Nejsem toho nazoru. Prijimaci strana musi na urcite urovni zprave rozumet, jinak by neumela data zpracovat.A v tom se právě mýlíš. V actor modelu i "původním OOP" můžeš mít objekt, který na jakoukoli zprávu odpoví "sorry, nerozumím". Opět: v pseudoOOP implementovaném pomocí volání metod to není realizovatelné.
Nepochopils.nakafunkce(...) je handler vsech zprav. Ocekaval jsem, ze si to domyslite.int nakafunkce(...) { return ERR_NOT_SUPPORTED;}Na jakoukoli zprávu, ne na zprávu "nakafunkce".
V Javě to bude standardně na tři řádky kvůli uzavírací závorce.Trochu jsem hledal příklady a zjevně to moc používaný není. Zaujalo mě tohle:
Under no circumstances should you call the method on the proxy itself since it will be intercepted again by the invocation handler and you will be faced with a StackOverflowError.https://blog.frankel.ch/the-power-of-proxies-in-java/
Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.Je určitě fajn, že to tam přidali. Každopádně škoda už je způsobena: obraty tohodle typu působí exoticky, místo aby byly chápaný jako úplně normální OO zpracování zpráv.
nakafunkce(...) je handler vsech zprav. Ocekaval jsem, ze si to domyslite.No a to je prave to michani urovne implementace a urovne jazyka. O implementaci se nebavime. Semantika predavani zprav samozrejme pomoci funkci implementovat jde. Bylo by nesmyslne tvrdit, ze actor model nejde v mainstreamových jazycích implementovat. To samozřejmě jde, jsou to jazyky turingovsky kompletní :)
Za to už Java nemůže. Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.Je určitě fajn, že to tam přidali. Každopádně škoda už je způsobena: obraty tohodle typu působí exoticky, místo aby byly chápaný jako úplně normální OO zpracování zpráv.
Nicméně ten konkrétní příklad, jak na to v Javě, tu zatím nikdo neuvedl. Pouze tu tvrdíte, že to jde.Za to už Java nemůže. Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.Je určitě fajn, že to tam přidali. Každopádně škoda už je způsobena: obraty tohodle typu působí exoticky, místo aby byly chápaný jako úplně normální OO zpracování zpráv.
Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybnýmNepamatuju si, že bych tvrdil, že to v Javě neexistuje. Pamatuju se, že jsem explicitně řekl, že nevím. Nejsem na Javu žádný odborník a děkuju za doplnění, byla to pro mě zajímavá informace.
, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.Ano, v tomhle jsem se mýlil, to uznávám. Má to nějaká omezení a je to specialita, ne obecná vlastnost všech objektů, ale uživatelsky to není tak nepříjemný, jak jsem čekal.
Trochu jsem se tu v té diskuzi ztratil, jaké bylo zadání?Nicméně ten konkrétní příklad, jak na to v Javě, tu zatím nikdo neuvedl. Pouze tu tvrdíte, že to jde.Za to už Java nemůže. Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybným, stejně jako “pokud to něco náhodou existuje, je to krkolomné”.Tohle do Javy dali lidi z Lighthousu, kteří psali v ObjC a v Sunu po akvizici je donutili psát v Javě.Je určitě fajn, že to tam přidali. Každopádně škoda už je způsobena: obraty tohodle typu působí exoticky, místo aby byly chápaný jako úplně normální OO zpracování zpráv.
Ono se to k tomu prapůvodnímu účelu - distribuovaným objektům - nepoužívá už ani ve Smalltalku nebo ObjC. Performance penalty tam určitě bude, i v ObjC je forwardInvocation řádově pomalejší (ten prapůvodní účel zahrnoval síťovou komunikaci s ještě mnohem větší latencí, tak to nevadilo). Moderní použití proxy je v ObjC například “animátor”, ale protože je ten mechanismus nesnesitelně pomalý, zrychlili to přidáním forwardingTarget. To už v Javě opravdu není, ale zrovna tohle tam asi nikomu nechybí.Nicméně tvoje uvažování “nevím o něčem, tak to neexistuje” se ukázalo být chybnýmNepamatuju si, že bych tvrdil, že to v Javě neexistuje. Pamatuju se, že jsem explicitně řekl, že nevím. Nejsem na Javu žádný odborník a děkuju za doplnění, byla to pro mě zajímavá informace.
Každopádně to nic nemění na tom, co jsem tvrdil: neexistuje to v tom smyslu, že tyhle - v původním OOP naprosto běžné a základní - obraty v "mainstream OOP" neexistují v tom smyslu, že nejsou v učebnicích, běžně se (zřejmě) nepoužívají, všechno se drtí dědičností. Původně základní skládání a manipulace se selectory se používá málo nebo vůbec.
Stačí se prostě podívat na nějakou základní učebnici SmallTalku a Javy. Jestli tam někdo nevidí zásadní rozdíl ve způsobu řešení problémů, tak je asi zbytečný ho o tom přesvědčovat., stejně jako “pokud to něco náhodou existuje, je to krkolomné”.Ano, v tomhle jsem se mýlil, to uznávám. Má to nějaká omezení a je to specialita, ne obecná vlastnost všech objektů, ale uživatelsky to není tak nepříjemný, jak jsem čekal.
Ještě je taky otázka, co se děje pod kapotou - jestli je tam nějaká performance penalty oproti normálním metodám.
Ono se to k tomu prapůvodnímu účelu - distribuovaným objektůmPrávěže to není (jediný) prapůvodní účel. Je to technika, která je prapůvodně úplně normální, žádná exotika: já tomu požadavku nerozumím, předám to někomu, kdo to zvládne zpracovat. Použitelné např. pro skládání obecných objektů, jejichž rozhraní pak nemusím znát.
To není pravda, i do původního OOP to přidali až v souvislosti s potřebou DO. RespondsToSelector je něco jiného, to tam původně bylo, ale to je jen introspekce. Nicméně hádat se nebudu, jen v podstatě “překládám” z AJ příslušnou pasáž z knihy Object oriented programming přímo od Coxe. Jinak historie “čistého” OOP včetně toho forwardingu za účelem DO je skvěle popsaná v knize Developing business applications with OpenStep, kterou jsem teď taky oprášil, abych si ověřil, co tu píšu. V té je i historický exkurs o probublání mnoha technik z OpenStepu do Javy. Čili závěr je, že buď prapůvodní účel forwardingu byly výhradně distribuované objekty, nebo Brad Cox lže.Ono se to k tomu prapůvodnímu účelu - distribuovaným objektůmPrávěže to není (jediný) prapůvodní účel. Je to technika, která je prapůvodně úplně normální, žádná exotika
Jinak další sekundární použití bylo HOM, to se přestalo používat až s příchodem bloků. DO vyšly z módy jako důsledek rozšíření HTTP, takže jediné současné použití je fakt jen ten animátor (to je něco jako doesNotRecognize light, funkčně omezenější, ale zato řádově rychlejší). Ale i to je už skoro historie.Ono se to k tomu prapůvodnímu účelu - distribuovaným objektůmPrávěže to není (jediný) prapůvodní účel. Je to technika, která je prapůvodně úplně normální, žádná exotika: já tomu požadavku nerozumím, předám to někomu, kdo to zvládne zpracovat. Použitelné např. pro skládání obecných objektů, jejichž rozhraní pak nemusím znát.
Stejně tak to respondsToSelector. Chci neznámý objekt uložit do pdf? No tak se ho prostě zeptám, jestli to umí. Fakt to musím komplikovat rozhraním ICanSaveToPDFInAWayYouWouldLike nebo ExtremelyComfortSaveableToPDFObjectFactory?
A o tom to právě je, tyhle techniky nikoho dneska ani nenapadnou. Přitom právě tohle je "to OOP", ne nějaká přiblblá dědičnost.
Nicméně hádat se nebudu, jen v podstatě “překládám” z AJ příslušnou pasáž z knihy Object oriented programming přímo od Coxe.A nebylo by lepší tu pasáž prostě odcitovat? Já tu knížku po ruce nemám, takže těžko můžu vědět, co tam píše :)
A nebylo by lepší tu pasáž prostě odcitovat?Každopádně:
OOP to me means only messaging, local retention and protection andhttp://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en (zvýraznění moje)
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them.
A nebylo by lepší tu pasáž prostě odcitovat? Já tu knížku po ruce nemám, takže těžko můžu vědět, co tam píše :)To bych se upsal. Ale jak říkám, nemám potřebu někoho přesvědčovat, zvlášť o věcech, které jsou jen historickou kuriozitou.
Begun the language wars have ::)A nebylo by lepší tu pasáž prostě odcitovat?Každopádně:CitaceOOP to me means only messaging, local retention and protection andhttp://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en (zvýraznění moje)
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them.
"Mainstreamové OOP" nesplňuje ani jedno...
To bych se upsal. Ale jak říkám, nemám potřebu někoho přesvědčovat, zvlášť o věcech, které jsou jen historickou kuriozitou.Nejde o přesvědčování, mě to zajímá a třeba i někoho jinýho. Třeba se v něčem zásadně mýlím, v tom případě bych to chtěl vědět. Ten InvactionHandler pro mě taky byla zajímavá informace.
Ja jsem na to sel empiricky. Rozdelil jsem si softy na oop/neoop a problemove(bugy, pady, leaky)/bezproblemove. Sam jsem byl prekvapeny jak silna korelace oop->problemy mi z toho vysla.
Třeba se v něčem zásadně mýlím, v tom případě bych to chtěl vědět.Myslím, že nejsme ve sporu.
To bych se upsal. Ale jak říkám, nemám potřebu někoho přesvědčovat, zvlášť o věcech, které jsou jen historickou kuriozitou.Nejde o přesvědčování, mě to zajímá a třeba i někoho jinýho. Třeba se v něčem zásadně mýlím, v tom případě bych to chtěl vědět. Ten InvactionHandler pro mě taky byla zajímavá informace.
Tohle je zase novinka pro mě, vypadá to, že __call v PHP je to samé, co forwardInvocation.Mne to například také zajímá. V PHP běžně používám magické metody, které se však mnoha vývojářům nelíbí. Přitom podle této diskuze dělají z PHP objektovější jazyk, než je třeba C++, C# nebo Java.To bych se upsal. Ale jak říkám, nemám potřebu někoho přesvědčovat, zvlášť o věcech, které jsou jen historickou kuriozitou.Nejde o přesvědčování, mě to zajímá a třeba i někoho jinýho. Třeba se v něčem zásadně mýlím, v tom případě bych to chtěl vědět. Ten InvactionHandler pro mě taky byla zajímavá informace.
dělají z PHP objektovější jazyk, než je třeba C++, C# nebo Java.Tak Java má ten forwarding taky a C# má dynamické objekty také už drahně let. Jen to C++ v tomto zaostává.
Problém těch mainstreamových "objektových" jazyků je v tom, že se vzal koňský povoz, koně byli nahrazeni traktorem a voila - máme auto. A za moderní výdobytky se považuje, že se to už neřídí opratěmi, ale vozka už má "drahně let" místo nich také volant (jehož pohyby se přenášejí do toho traktoru pomocí provazů). Nedokážu pochopit, že to stádo IT ovcí nevidí a nechce vidět, že toto opravdu není auto a žádnými vylepšními se z toho auto nikdy neudělá, protože je to prostě koncepčně od základů špatně. Vždycky to bude jen koňský povoz, třebaže bez koní. Což je ještě horší, než kdyby to byl normální koňský povoz s koňmi.Až jednou dostuduješ, tak možná různé přístupy k OOP pochopíš. Prozatím uber na agresivitě, za neznalost se stydět nemusíš.
V PHP běžně používám magické metody, které se však mnoha vývojářům nelíbí. Přitom podle této diskuze dělají z PHP objektovější jazyk, než je třeba C++, C# nebo Java.Tohle je zase novinka pro mě, vypadá to, že __call v PHP je to samé, co forwardInvocation.
$article->setTitle("Titulek");
// se dá mnohem pohodlněji a přehledněji zapsat
$article->title = "Titulek";
Zda to přímo ovlivní globální atribut nebo zda se to provede přes interní setter, je už čistě na implementaci objektu. Dají se takto snadno refaktorovat třídy s globálními atributy, včetně možnosti doplnění vhodných dekorátorů.mě to zajímáK tomu původnímu tvrzení o účelu - Smalltalk původně to doesNotUnderstand neměl, to přidali až do verze Smalltalk-80 (viz stejnojmenná kniha). Kayův důraz na zprávy plyne z toho, že v jeho pojetí měly jít posílat i mimo adresní prostor a třeba i mezi počítači v rámci jedné syntaxe. To doesNotUnderstand byl právě jen implementační detail (z toho pak postupně vzniklo doesNotRecognize, forward, forwardingTarget atd.) a čím dál víc se to zkrkolomnilo (vrcholem je požadavek ObjC implementovat za účelem odchytu zpráv methodSignatureForSelector), jak se postupně naráželo na další technické nedostatky a zádrhely. Ta prvotní verze Smalltalku tedy uměla jen něco jako virtuální metody, protože než začali implementovat Distributed Smalltalk (viz stejnojmenné články a kniha), tak nic dynamičtějšího nepotřebovali.
K tomu původnímu tvrzení o účelu [...]Díky moc za exkurs. Reálně jsem si trochu hrál s ObjectiveC, kolem Smalltalku jsem se jenom lehce šmrncl, takže vědět kdy co přidali, to je fakt daleko za mými obzory ohledně těhle jazyků. Každopádně si ale živě pamatuju, jaký překvapení pro mě bylo, když jsem si prvně o Obj-C něco četl (s nějakou znalostí C++). Ten aha moment: ajó, tak tohle je vlastně to OOP! Wow! ;)
Tímto asi pro dnešek končím, [MerryChristman wishTo: Prymek] ;)Tobě a všem ostatním taky, dík.
Tímto asi pro dnešek končím, [MerryChristman wishTo: Prymek] ;)Tobě a všem ostatním taky, dík.
Priste jak to uvidim tak to hlasim Krcmimu.Dobře děláš, protože na vatikánskou telenovelu je u nás pěkně vostrej paragraf.
OOP? v zmysle takom, jak sa šmuchtlá vätšinou programátorov v "modernej Jave" je to grc. Ale OOP v pôvodnej myšlienke môže mať výhody pre určité situácie.
OOP je dobry sluha a spatny pan. Dobre jsou jazyky, ktere ho umoznuji, ale nevynucuji, takze je mozne ho aplikovat jen na mista a situace, kde je to vyhodne.
OOP je dobry sluha a spatny pan. Dobre jsou jazyky, ktere ho umoznuji, ale nevynucuji, takze je mozne ho aplikovat jen na mista a situace, kde je to vyhodne.
Kadet tady uvedl link na video, ve kterém je prezentováno, jak zbytečné některé třídy mohou být.
https://www.youtube.com/watch?v=o9pEzgHorH0 (https://www.youtube.com/watch?v=o9pEzgHorH0)
Na devel.cz se tazatel ptal na zbytečnost testu. Odpověděl jsem mu, že je zbytečná celá třída a napsal k tomu náhradu na dva řádky. Byl jsem zavalen mínusy, hlavně kvůli tomu, že jsem odpověděl jinak, než se očekávalo. Budiž. Zároveň je z toho vidět, že když osekám třídu tak, že z ní nic nezbyde, tak se to nehodí do mantry OOP.
Mnoho tříd je napsáno tak, že mají několik atributů, ke každému jeden getter a jeden setter. Co to je? Obyčejná struktura. Jen se místo "title = xxx" píše "setTitle(xxx)". Operace s takovou instancí se provádí v další třídě, nejlépe pomocí statických metod. To má být OOP? Ne, je to jen převlečené strukturované programování.
Ani se nedivím, že se vývojáři ozývají, že tohle je fuj. Místo toho, aby napravili chybně aplikované OOP, utíkají k funkcionálnímu programování. Tam už mají své struktury, které mohli mít v objektech. Tam mají i funkce, které používají stejně, jako používali statické metody. Místo tříd mají moduly. Prakticky to používají stejně, jen s úspornějším zápisem. I tu curryfikaci si mohli napsat v OOP, kdyby to zvládli.
V každém paradigmatu se dá napsat dobrý nebo špatný program. Nejlepší výsledky však vychází, pokud je možné paradigmata kombinovat, nejlépe ve vrstvách. Spodní vrstva strukturovaně, mezivrstva funkcionálně, horní vrstva objektově. Proč ne?
...Ve skutečném světě je ale spousta jevů, kde žádné identity neexistují a vznikají všelijaké ad-hoc shluky jevů a vlastností (triviální příklad jsou třeba korály nebo shluky nějakých bakterií, kde výraz "jedinec" moc nedává smysl, tím spíš jedinec, který by měl být "věšákem na vlastnosti")...
...A neni nejlepsi cely ten balast zahodit a rovnou zavolat metodu?
Vlakno je pouze abstrakce. Muze byt tezkopadne jako unix nebo nt vlakno s velkym stackem, nebo velmi lehka abstrakce v pripade green threadingu.Green threading? A jsme zpet u kooperativniho multitaskingu jako ve win 3.11. A neni nejlepsi cely ten balast zahodit a rovnou zavolat metodu?
Ale z pohledu actor systemu bezi kazdy agent ve svem vlakne.
Jinak další sekundární použití bylo HOM, to se přestalo používat až s příchodem bloků. DO vyšly z módy jako důsledek rozšíření HTTP, takže jediné současné použití je fakt jen ten animátor (to je něco jako doesNotRecognize light, funkčně omezenější, ale zato řádově rychlejší). Ale i to je už skoro historie.Ono se to k tomu prapůvodnímu účelu - distribuovaným objektůmPrávěže to není (jediný) prapůvodní účel. Je to technika, která je prapůvodně úplně normální, žádná exotika: já tomu požadavku nerozumím, předám to někomu, kdo to zvládne zpracovat. Použitelné např. pro skládání obecných objektů, jejichž rozhraní pak nemusím znát.
Stejně tak to respondsToSelector. Chci neznámý objekt uložit do pdf? No tak se ho prostě zeptám, jestli to umí. Fakt to musím komplikovat rozhraním ICanSaveToPDFInAWayYouWouldLike nebo ExtremelyComfortSaveableToPDFObjectFactory?
A o tom to právě je, tyhle techniky nikoho dneska ani nenapadnou. Přitom právě tohle je "to OOP", ne nějaká přiblblá dědičnost.
Co je to HOM?HOM je posílání zpráv vyššího řádu (higher order messaging).
Cox ani nelže, ale spíš nerozumí. Delegace je obecně využitelný mechanismus vyplývající z podstaty objektu jako samostatné jednotky.
Co je animátor, nevím (prosím odkaz)
Na devel.cz se tazatel ptal na zbytečnost testu. Odpověděl jsem mu, že je zbytečná celá třída a napsal k tomu náhradu na dva řádky. Byl jsem zavalen mínusy, hlavně kvůli tomu, že jsem odpověděl jinak, než se očekávalo. Budiž. Zároveň je z toho vidět, že když osekám třídu tak, že z ní nic nezbyde, tak se to nehodí do mantry OOP.Tie minusy si tam dostal pre t, ze namiesto odpovede na otazku si zacal trollovat.
A hlavne nevies ci je ta treda zbytocna lebo nepoznas kontext a hlavne tvoje vedomosti z programovania su dost obmedzene na PHP a male one man show projektiky.
Na devel.cz se tazatel ptal na zbytečnost testu. Odpověděl jsem mu, že je zbytečná celá třída a napsal k tomu náhradu na dva řádky. Byl jsem zavalen mínusy, hlavně kvůli tomu, že jsem odpověděl jinak, než se očekávalo. Budiž. Zároveň je z toho vidět, že když osekám třídu tak, že z ní nic nezbyde, tak se to nehodí do mantry OOP.Tie minusy si tam dostal pre t, ze namiesto odpovede na otazku si zacal trollovat.
A hlavne nevies ci je ta treda zbytocna lebo nepoznas kontext a hlavne tvoje vedomosti z programovania su dost obmedzene na PHP a male one man show projektiky.
Takže velký projekt poznám podle toho, že používá uměle nafouklé třídy?
Tady jde asi o nedorozumění. Neřekl jsem, že to "nejde modelovat", ale že naše obvyklé "substanční" modely jsou pro spoustu jevů reálného života neadekvátní. Kdyby to ti, kdo je používají, věděli a skromně přiznávali, tak by to bylo ok. Ale když se začnou tvářit, že jejich model je tak dobrý, že to snad ani není model, ale ontologie (vystihuje samou podstatu toho, jaký svět je), je to průser....Ve skutečném světě je ale spousta jevů, kde žádné identity neexistují a vznikají všelijaké ad-hoc shluky jevů a vlastností (triviální příklad jsou třeba korály nebo shluky nějakých bakterií, kde výraz "jedinec" moc nedává smysl, tím spíš jedinec, který by měl být "věšákem na vlastnosti")...
Při všem respektu k vám je tohle jen vaším nedostatkem fantazie - cokoliv, co jde pojmenovat nebo popsat, jde i modelovat, a to i věci abstraktní.
Ne. Ale vzhledem ke sve omezene zkusenosti nepoznas, kdy je neco umele nafoukle.Takže velký projekt poznám podle toho, že používá uměle nafouklé třídy?Na devel.cz se tazatel ptal na zbytečnost testu. Odpověděl jsem mu, že je zbytečná celá třída a napsal k tomu náhradu na dva řádky. Byl jsem zavalen mínusy, hlavně kvůli tomu, že jsem odpověděl jinak, než se očekávalo. Budiž. Zároveň je z toho vidět, že když osekám třídu tak, že z ní nic nezbyde, tak se to nehodí do mantry OOP.Tie minusy si tam dostal pre t, ze namiesto odpovede na otazku si zacal trollovat.
A hlavne nevies ci je ta treda zbytocna lebo nepoznas kontext a hlavne tvoje vedomosti z programovania su dost obmedzene na PHP a male one man show projektiky.
CitaceUnder no circumstances should you call the method on the proxy itself since it will be intercepted again by the invocation handler and you will be faced with a StackOverflowError.https://blog.frankel.ch/the-power-of-proxies-in-java/
Znamená to, že ten objekt nesmí mít jinou metodu než invoke? To by bylo docela hloupý.
Cox je autorem ObjC, takže mu celkem rozumí. Nicméně řec vůbec nebyla o delegaci.
Animator je - přísně vzato - metoda některých tříd GUI vracející proxy animující změny některých vlastností: https://developer.apple.com/documentation/appkit/nsanimatablepropertycontainer/1530511-animator?language=objc
Tady jde asi o nedorozumění. Neřekl jsem, že to "nejde modelovat", ale že naše obvyklé "substanční" modely jsou pro spoustu jevů reálného života neadekvátní. Kdyby to ti, kdo je používají, věděli a skromně přiznávali, tak by to bylo ok. Ale když se začnou tvářit, že jejich model je tak dobrý, že to snad ani není model, ale ontologie (vystihuje samou podstatu toho, jaký svět je), je to průser.
Příklad:
AFAIK, v ranných fázích vývoje je lidský zárodek shluk buněk, přičemž se může stát, že část tohodle shluku se utrhne a vznikne z něj samostatný jedinec (jednovaječná dvojčata) nebo naopak se vyvíjí dva oddělené shluky, vypadá to na dvojčata, ale pak se z ničehožnic shluky spojí a je z toho ve finále jeden člověk.
Pokud tenhle děj budu chtít modelovat, nemůžu říct, že tam je jedna nebo dvě entity (na které věším vlastnosti), nemůžu určit přesný okamžik, kdy se z jedné staly dvě ani ze dvou jedna. Ani moc nevíme, jak bysme měli vlastnosti dvou splynuvších jedinců mergovat a naopak.
Laicky mám za to, že to je důsledek aristotelismu, který nám pomáhá a zároveň háže klacky pod nohy dodnes. Umíme dobře pracovat se "substancí" a "akcidenty" (i když tomu tak dneska neříkáme), ale moc neumíme konceptualizovat plynulé, těžko definovatelné změny, které mají kvalitativní/ontologickou povahu.
Ale to (v OOP) není.Cox je autorem ObjC, takže mu celkem rozumí. Nicméně řec vůbec nebyla o delegaci.
Animator je - přísně vzato - metoda některých tříd GUI vracející proxy animující změny některých vlastností: https://developer.apple.com/documentation/appkit/nsanimatablepropertycontainer/1530511-animator?language=objc
Je-li delegací jakékoliv předávání požadavku dalšímu objektu
Je to jen proxy udělaná pomocí forward, viz dokumentace.Cox je autorem ObjC, takže mu celkem rozumí. Nicméně řec vůbec nebyla o delegaci.
Animator je - přísně vzato - metoda některých tříd GUI vracející proxy animující změny některých vlastností: https://developer.apple.com/documentation/appkit/nsanimatablepropertycontainer/1530511-animator?language=objc
Animátor znamená objekt, který zajišťuje provedení nějaké zvolené posloupnosti změn jiného objektu v času? Chápu to správně? Pak se jedná spíše o adaptér.
Tady jde asi o nedorozumění. Neřekl jsem, že to "nejde modelovat", ale že naše obvyklé "substanční" modely jsou pro spoustu jevů reálného života neadekvátní. Kdyby to ti, kdo je používají, věděli a skromně přiznávali, tak by to bylo ok. Ale když se začnou tvářit, že jejich model je tak dobrý, že to snad ani není model, ale ontologie (vystihuje samou podstatu toho, jaký svět je), je to průser.
Příklad:
AFAIK, v ranných fázích vývoje je lidský zárodek shluk buněk, přičemž se může stát, že část tohodle shluku se utrhne a vznikne z něj samostatný jedinec (jednovaječná dvojčata) nebo naopak se vyvíjí dva oddělené shluky, vypadá to na dvojčata, ale pak se z ničehožnic shluky spojí a je z toho ve finále jeden člověk.
Pokud tenhle děj budu chtít modelovat, nemůžu říct, že tam je jedna nebo dvě entity (na které věším vlastnosti), nemůžu určit přesný okamžik, kdy se z jedné staly dvě ani ze dvou jedna. Ani moc nevíme, jak bysme měli vlastnosti dvou splynuvších jedinců mergovat a naopak.
Laicky mám za to, že to je důsledek aristotelismu, který nám pomáhá a zároveň háže klacky pod nohy dodnes. Umíme dobře pracovat se "substancí" a "akcidenty" (i když tomu tak dneska neříkáme), ale moc neumíme konceptualizovat plynulé, těžko definovatelné změny, které mají kvalitativní/ontologickou povahu.
Nejdříve je třeba říci, že model je zjednodušením, kdy modeluju jen to, co mi stačí (a i to můžu zprasit - běžný to jev). Vytvořím-li dokonalý model modelující vše, bude nutně zcela identický se vzorem, pak ale nemá smysl vytvářet model, použiju originál.
U vašeho modelu zárodku je třeba především rozmyslet, co chcete modelovat, máte na výběr různou granularitu od dělení genetické informace přes buňky až po celé chuchvalce, záleží, k čemu to bude.
Poslední myšlenka je hlubší než moje duševní schopnost.
Nejdříve je třeba říci, že model je zjednodušením, kdy modeluju jen to, co mi stačí (a i to můžu zprasit - běžný to jev). Vytvořím-li dokonalý model modelující vše, bude nutně zcela identický se vzorem, pak ale nemá smysl vytvářet model, použiju originál.Míjíte se s tím, co se snažím říct. Podstata sdělení je v tom příspěvku, který jste citoval, líp ji asi nevyjádřím:
U vašeho modelu zárodku je třeba především rozmyslet, co chcete modelovat, máte na výběr různou granularitu od dělení genetické informace přes buňky až po celé chuchvalce, záleží, k čemu to bude.
Ne, o výkon nejde, spíš mě štve, jakým způsobem OOP strukturuje uvažování. V době největšího OOP-hypu se OOP vydávalo ne za model reality, ale tvářilo se, že má téměř ontologickou povahu. Tj. v knížkách se podvědomě sugerovala představa, že svět JE takový (má takovou strukturu), jak ho OOP modeluje. Tedy že OOP je vlastně "přirozený". A to je strašně destruktivní iluze.
Jsou tyto vase texty mysleny jako variace na pividku Woodyho Allena: "Kdyby byli impresioniste dentisty", nebo jste ozrali?Konstruktivnější reakce (co konkrétně se ti nezdá, nebo čemu nerozumíš) by pro debatu byla cennější.
https://www.youtube.com/watch?v=8Z-YjkS2wzIJsou tyto vase texty mysleny jako variace na pividku Woodyho Allena: "Kdyby byli impresioniste dentisty", nebo jste ozrali?Konstruktivnější reakce (co konkrétně se ti nezdá, nebo čemu nerozumíš) by pro debatu byla cennější.
https://www.youtube.com/watch?v=8Z-YjkS2wzIJsou tyto vase texty mysleny jako variace na pividku Woodyho Allena: "Kdyby byli impresioniste dentisty", nebo jste ozrali?Konstruktivnější reakce (co konkrétně se ti nezdá, nebo čemu nerozumíš) by pro debatu byla cennější.
Podle me zasadni pristup v OOP, ktery dodal do tohoto modelovani tu spravnou konzistenci, je Inversion of Control. Diky IoC je totiz vlastne mozne redukovat OOP na jednoduchou plochou architekturu bez slozitych konstrukci, ktera nasledne tvori zaklad cele aplikace. Rozdeli to design na Funkce a Data. Tim se proste nikdy neda nic zkazit, je to VZDY prehledne. Nasledne sofistikovanejsi OOP konstrukce se pouzivaji, az pokud jsou vylozene k necemu prospesne. IoC umoznuje psat jednoduse a dava prostor otazce "Je tato OOP konstrukce (navrhovy vzor) pro aplikaci prospesnejsi, nez jednoduche IoC?" Pokud je, tak PAK JI TEPRVE pouziju, pokud ne (ve vetsine pripadu), pokracuje se v ploche IoC architekture. Zaroven je IoC takovy navrat ke korenum programovani, a to jsou prave ty Funkce a Data, ktere tu byly odjakziva. Dala by se na tom nakreslit (vyzivova) pyramida, kde spodni patro by nalezelo prave tomuto Funkce+Data designu.
...Doufám, že ten idiot, o kterém se tam mluví, nebude mít i novorční projev.
https://www.youtube.com/watch?v=8Z-YjkS2wzI
https://www.youtube.com/watch?v=8Z-YjkS2wzIJsou tyto vase texty mysleny jako variace na pividku Woodyho Allena: "Kdyby byli impresioniste dentisty", nebo jste ozrali?Konstruktivnější reakce (co konkrétně se ti nezdá, nebo čemu nerozumíš) by pro debatu byla cennější.
Vy jste to taky nepochopil?
...Doufám, že ten idiot, o kterém se tam mluví, nebude mít i novorční projev.
https://www.youtube.com/watch?v=8Z-YjkS2wzI
Končit starý a začínat rok nový tou samou duševní žumpou a verbalním průjmem by už bylo moc...
...Doufám, že ten idiot, o kterém se tam mluví, nebude mít i novorční projev.
https://www.youtube.com/watch?v=8Z-YjkS2wzI
Končit starý a začínat rok nový tou samou duševní žumpou a verbalním průjmem by už bylo moc...
...Uff, ještě že tak.
Nebude. Kromě toho máš možnost se na to nekoukat a neposlouchat, prostě to ignorovat. Jak jednoduché.
... debakl.:) ;) :D ;D
Ked je OOP zo Smalltalku tak super hyper uzasne pre co sa (smalltalk) nepouziva?
neco DOzadekE neni bud a nebo, ale ze je tam ku*va SKALAScala? Ta je funkcionální.
;DKed je OOP zo Smalltalku tak super hyper uzasne pre co sa (smalltalk) nepouziva?Ovšem musím varovat před tím, že se ti pak Java možná zhnusí.
neco DOzadekE neni bud a nebo, ale ze je tam ku*va SKALAScala? Ta je funkcionální.
Ked je OOP zo Smalltalku tak super hyper uzasne pre co sa (smalltalk) nepouziva?Zkus si něco nastudovat o marketingu, byl bys vyléčen z iluzí, že o úspěchu produktu rozhoduje jeho kvalita.
Ked je OOP zo Smalltalku tak super hyper uzasne pre co sa (smalltalk) nepouziva?Zkus si něco nastudovat o marketingu, byl bys vyléčen z iluzí, že o úspěchu produktu rozhoduje jeho kvalita.
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?Windows.
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?Windows.
Těch možností bylo víc: OS/2, MacOS, BeOS, NeXT, ... Jinak ne všechny UNIXy byly drahé, bylo i BSD.
Víceméně všechny alternativy byly technicky lepší než "grafická nadstavba DOSu" jménem Windows.
Dobre, to neumim posoudit, ale je tady jeste jedna kvalita, a ta se skryva v tom "tech moznosti bylo nekolik" - standardizace a to, ze kazdy ma svem PC jediny OS, a to je Windows, namisto toho, aby tech OS bylo celkem 10 ruznych, se taky ceni.Jistě, ale to byl až důsledek toho marketingového vítězství technicky horšího produktu.
Dobre, to neumim posoudit, ale je tady jeste jedna kvalita, a ta se skryva v tom "tech moznosti bylo nekolik" - standardizace a to, ze kazdy ma svem PC jediny OS, a to je Windows, namisto toho, aby tech OS bylo celkem 10 ruznych, se taky ceni.Jistě, ale to byl až důsledek toho marketingového vítězství technicky horšího produktu.
Těch možností bylo víc: OS/2, MacOS, BeOS, NeXT, ... Jinak ne všechny UNIXy byly drahé, bylo i BSD.
Víceméně všechny alternativy byly technicky lepší než "grafická nadstavba DOSu" jménem Windows.
Ten jediný za něco stál (akorát se jmenoval NeXTSTEP).Těch možností bylo víc: OS/2, MacOS, BeOS, NeXT, ... Jinak ne všechny UNIXy byly drahé, bylo i BSD.NeXT nemá smysl rozebírat vůbec.
Víceméně všechny alternativy byly technicky lepší než "grafická nadstavba DOSu" jménem Windows.
NeXT nemá smysl rozebírat vůbec.Ten jediný za něco stál (akorát se jmenoval NeXTSTEP).
Jeho přejmenovaná verze dnes běží na 100 milionech počítačů, to není tak úplně neúspěch.Z technického hlediska určitě zajímavý, to nepopírám. Ale z obchodního hlediska podle mě odsouzený k neúspěchu - vývoj šel prostě jinudy.NeXT nemá smysl rozebírat vůbec.Ten jediný za něco stál (akorát se jmenoval NeXTSTEP).
Ale Mirku... BeOS byla jednouživatelská hračka pro omezené spektrum využití, MacOS nestabilní OS se složitou správou RAM a kooperativním multitaskingemTak jistě, ale musíš srovnávat produkty vydané ve stejné době. "Masová" (tj. ne-NT) verze Windows měla preemptivní multitasking až od Windows 95 a že by ty nějak oplývaly stabilitou, to ani nemám uplně pocit :)
a byl poměrně drahýNojo, jenže o tom právě jsou ty business decisions. Kdyby si tenkrát IBM nehrálo na exkluzivní OS, ale dalo by ho za babku a ke svému železu zdarma, kdoví, jakou cestou by vývoj šel.
Tak jistě, ale musíš srovnávat produkty vydané ve stejné době. "Masová" (tj. ne-NT) verze Windows měla preemptivní multitasking až od Windows 95 a že by ty nějak oplývaly stabilitou, to ani nemám uplně pocit :)
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?
Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?
Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..
Ke kazde z tech veci v te dobe existovaly podstatne lepsi alternativy, jen byly (z toho ci onoho duvodu = marketing) mene zname.
Me by zajimal ten Hadoop (bez ironie). Rozvedl bys to?Mě taky. Dneska alternativy jsou (minimálně znám Spark a Flink), ale ty jsou IIRC pozdějšího data.
Nejen pozdejsi, ale v produkci typicky navic nad Hadoopem (resp. nad HDFS a YARNem).Me by zajimal ten Hadoop (bez ironie). Rozvedl bys to?Mě taky. Dneska alternativy jsou (minimálně znám Spark a Flink), ale ty jsou IIRC pozdějšího data.
Co lepsiho bylo k php a js? Imho to neposuzujes komplexne.Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?
Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..
Ke kazde z tech veci v te dobe existovaly podstatne lepsi alternativy, jen byly (z toho ci onoho duvodu = marketing) mene zname.
Co lepsiho bylo k php a js? Imho to neposuzujes komplexne.No tak tohle je zrovna špatný příklad. JS se používá naopak právě proto, že nic jiného v prohlížečích pro skripty není. A také to není důkaz jeho "kvality".
Co lepsiho bylo k php a js? Imho to neposuzujes komplexne.No tak tohle je zrovna špatný příklad. JS se používá naopak právě proto, že nic jiného v prohlížečích pro skripty není. A také to není důkaz jeho "kvality".
JS se používá naopak právě proto, že nic jiného v prohlížečích pro skripty není,... v prohlížečích se používa JS, protože práve není nič lepšího čo by v prohlížečích mohlo bežať.
CitaceJS se používá naopak právě proto, že nic jiného v prohlížečích pro skripty není,... v prohlížečích se používa JS, protože práve není nič lepšího čo by v prohlížečích mohlo bežať.
V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.CitaceJS se používá naopak právě proto, že nic jiného v prohlížečích pro skripty není,... v prohlížečích se používa JS, protože práve není nič lepšího čo by v prohlížečích mohlo bežať.
Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.
V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.CitaceJS se používá naopak právě proto, že nic jiného v prohlížečích pro skripty není,... v prohlížečích se používa JS, protože práve není nič lepšího čo by v prohlížečích mohlo bežať.
Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.
Tak to snad je webassembly, ne? To je i snad ten duvod, proc je takovy rozmach jazyku co se umi kompilovat do "webu". (jsem Javista, takze me napada Kotlin)
Tak to snad je webassembly, ne? To je i snad ten duvod, proc je takovy rozmach jazyku co se umi kompilovat do "webu". (jsem Javista, takze me napada Kotlin)
Pro vývoj webu bych se vyhnul všemu, co je typováno staticky.
Tak to snad je webassembly, ne? To je i snad ten duvod, proc je takovy rozmach jazyku co se umi kompilovat do "webu". (jsem Javista, takze me napada Kotlin)
Pro vývoj webu bych se vyhnul všemu, co je typováno staticky.
Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.
Tak, musime si ujasnit, co je to vyvoj webu. J si pod vyvojem webu predstavuju tvorbu webovych stranek, coz je dostatecne obecny pojem na to, abych si pod tim predstavil i webove stranky slouzici jako frontend pro informacni systemy, jako jsou napr. v bankach a telco. A pri vyvoji IS bych se ja osnobne vyhnul vsemu, co naopak neni staticky typovane.
Proč?Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.
Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.
A důvod?Tak to snad je webassembly, ne? To je i snad ten duvod, proc je takovy rozmach jazyku co se umi kompilovat do "webu". (jsem Javista, takze me napada Kotlin)
Pro vývoj webu bych se vyhnul všemu, co je typováno staticky.
Proč?Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.
Pro vývoj webu bych se vyhnul všemu, co je typováno staticky.A důvod?
Doporucuju si precist tohle od Alana Kaye. Jeho nazor na web prohlizece. Prohlizec je operacni system, nebo alespon jeho vrstva. Je to prostredi, ve kterym bezi aplikace, izolovane od sebe. Presna definice OS. Tak proc znovu vynalezat kolo.Asi před rokem jsem tady na rootu v jiné diskusi, kde se řešilo něco podobného, odcitoval tento Kayův názor, aniž bych schválně uvedl autora. Naprostá většina čitatelů hodnotila červeným palcem. "Chtěl by pohánět loď parou! Blázen."
http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=2
Úspornější? Co je pro boha úspornějšího na tom, když se po netu valí sem a tam pořád dokola ty samé tagy v podobě mnohabajtových stringů, jmen funkcí, proměnných, klíčových slov, syntaktického cukru, komentářů a jiného balastu, jehož sémantika se dá zachytit doslova pár bajty, nebo by se dal eliminovat zcela?Proč?Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.
Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?
Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?Úspornější? Co je pro boha úspornějšího na tom, když se po netu valí sem a tam pořád dokola ty samé tagy v podobě mnohabajtových stringů, jmen funkcí, proměnných, klíčových slov, syntaktického cukru, komentářů a jiného balastu, jehož sémantika se dá zachytit doslova pár bajty, nebo by se dal eliminovat zcela?
Ke kompilaci kódu by docházelo pokud možno přímo u autora kódu. Prohlížeč by obsahoval pouze VM.
Bez uvedení autora to není citace. Navíc Kay nic takového neřekl, nanejvýš apud.Doporucuju si precist tohle od Alana Kaye. Jeho nazor na web prohlizece. Prohlizec je operacni system, nebo alespon jeho vrstva. Je to prostredi, ve kterym bezi aplikace, izolovane od sebe. Presna definice OS. Tak proc znovu vynalezat kolo.Asi před rokem jsem tady na rootu v jiné diskusi, kde se řešilo něco podobného, odcitoval tento Kayův názor, aniž bych schválně uvedl autora. Naprostá většina čitatelů hodnotila červeným palcem. "Chtěl by pohánět loď parou! Blázen."
http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=2Úspornější? Co je pro boha úspornějšího na tom, když se po netu valí sem a tam pořád dokola ty samé tagy v podobě mnohabajtových stringů, jmen funkcí, proměnných, klíčových slov, syntaktického cukru, komentářů a jiného balastu, jehož sémantika se dá zachytit doslova pár bajty, nebo by se dal eliminovat zcela?Proč?Takže by se po linkách přenášel binární bajtkód? To se mi nejeví jako dobré řešení a ani nevidím úsporu při transportu.Dovedu si představit, že by v prohlížečích běhal Lisp. Byla by to paráda.V prohlížečích by mohl být nějakou VM zpracováván nějaký bytekód, do kterého by mohlo být překládáno z čehokoli. Bylo by to jednodušší, univerzálnější a nenáročnější jak na objem dat přepravovaných po síti, tak na výkon počítačů. Ale často mám u některých řešení pocit, že jsou to vítězové soutěže o nejhloupěji navržený kus SW.
Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?
Ke kompilaci kódu by docházelo pokud možno přímo u autora kódu. Prohlížeč by obsahoval pouze VM.
Koncept webu, tak jak to vymysleli v CERNu, je IMHO jeden z největších omylů IT za posledních 30 let. A další ukázka toho, jak se může i naprosto nemožná technologie masově rozšířit.
Tak jednak je potom otázkou, zda javovský či pythoní bytekód je vhodný etalon (osobně ho nepovažuji za nic ideálního a strukturu .class jsem nestudoval, abych dokázal posoudit, kolik balastu obsahuje) - avšak sám, jakožto embeďák, můžu často porovnávat binární kód pro mikrořadiče s korespondujícím zdrojákem v C či C++. A tam je to celkem jasné. Pokud poměr u relativně hutného (oproti strojovému kódu) bytekódu nevychází dobře oproti zdrojáku, asi je něco špatně. Abych jen nekritizoval, tak za zdařilý považuji bytekód jazyka Lua.Textový formát je pro přenos přece jen trochu úspornější. Kde by tedy docházelo ke kompilaci? Na serveru nebo až na klientovi?Úspornější? Co je pro boha úspornějšího na tom, když se po netu valí sem a tam pořád dokola ty samé tagy v podobě mnohabajtových stringů, jmen funkcí, proměnných, klíčových slov, syntaktického cukru, komentářů a jiného balastu, jehož sémantika se dá zachytit doslova pár bajty, nebo by se dal eliminovat zcela?
Ke kompilaci kódu by docházelo pokud možno přímo u autora kódu. Prohlížeč by obsahoval pouze VM.
Ty mnohabajtové stringy se docela dobře komprimují během přenosu. Kromě toho je velké množství skriptů a stylů minifikováno, když se dělá deploy. Jedno- či dvouznakový identifikátor zabere méně místa než celý node či odkaz na něj. Když porovnáš velikost souboru .java a .class, tak to moc velký rozdíl není, podobně jako .py vs. .pyc. Zdrojáky se však lépe komprimují.
Bez uvedení autora to není citace. Navíc Kay nic takového neřekl, nanejvýš apud.Takže většina toho, čemu říkáme citáty, zvláště ty latinské, vlastně podle tebe vůbec citáty nejsou. Prosím, držme se obecně přijímaného významu slov a nevymýšlej si pro ně své vlastní definice. Ale nešť - tak jsem přeparafrázoval Kayovy názory na to, jak by podle něj mohl vypadat web. Proč jsem schválně autora neuvedl, je snad zřejmé - většina lidí ani nemá svůj názor, jen kýve či kroutí podle toho, kdo daný názor vysloví. A to dnes bohužel platí i v politice a umění.
Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.
Tak, musime si ujasnit, co je to vyvoj webu. J si pod vyvojem webu predstavuju tvorbu webovych stranek, coz je dostatecne obecny pojem na to, abych si pod tim predstavil i webove stranky slouzici jako frontend pro informacni systemy, jako jsou napr. v bankach a telco. A pri vyvoji IS bych se ja osnobne vyhnul vsemu, co naopak neni staticky typovane.
Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.
V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě. Zatímco ve strukturovaných jazycích typu Pascal obvykle předpokládám určitý typ dat na určitém místě a situace, kdy tomu tak není, jsou spíše výjimečné, v objektovém přístupu je tomu přesně naopak. Pokud toto není aspoň v nějaké omezené formě umožněno (jako v C++ či v Javě), tak se vůbec nedá mluvit o objektovém programování.Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.
Tak já bych se s dovolením od této blbosti odpíchl, a zeptal se vás na názor.
V čem je dynamické typování, či případně netypování, užitečné? Za mě jsem dospěl k závěru, že jsou to dvě situace:
1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.
2. Někdy se hodí, zejména na prototypování, když jsou typy volitelné, a následně to při refactoringu upřesňovat. Protože ze začátku člověk třeba nemá jasno, jak to má vypadat, a tak samozřejmě dost dobře nemůže ty typy určit.
Kromě těchto dvou scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.
Co myslíte vy?
Ty mnohabajtové stringy se docela dobře komprimují během přenosu. Kromě toho je velké množství skriptů a stylů minifikováno, když se dělá deploy. Jedno- či dvouznakový identifikátor zabere méně místa než celý node či odkaz na něj. Když porovnáš velikost souboru .java a .class, tak to moc velký rozdíl není, podobně jako .py vs. .pyc. Zdrojáky se však lépe komprimují.Tak jednak je potom otázkou, zda javovský či pythoní bytekód je vhodný etalon (osobně ho nepovažuji za nic ideálního a strukturu .class jsem nestudoval, abych dokázal posoudit, kolik balastu obsahuje) - avšak sám, jakožto embeďák, můžu často porovnávat binární kód pro mikrořadiče s korespondujícím zdrojákem v C či C++. A tam je to celkem jasné. Pokud poměr u relativně hutného (oproti strojovému kódu) bytekódu nevychází dobře oproti zdrojáku, asi je něco špatně. Abych jen nekritizoval, tak za zdařilý považuji bytekód jazyka Lua.
A jednak je nevhodná celková koncepce, kdy statický web složitými kličkami dynamizuji. Komprimace je sice hezká, ale neřeší podstatu problému.
V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.Nenašel jsem situaci, kdy by pozdní vazba bránila typům. Můžeš uvést příklad?
Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.
Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.V čem je dynamické typování, či případně netypování, užitečné?
V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.Nenašel jsem situaci, kdy by pozdní vazba bránila typům. Můžeš uvést příklad?
Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.
A jestli to je Kit-compliant OOP je vec uplne druhorada, protoze bavime se o tom, co je lepsi a co horsi, o to jde predevsim 8)
O pár stránek zpět bylo propagováno oddělení funkcí od datových struktur, což je přesně proti myšlence OOP, tedy že metody jsou co nejblíž k datům, se kterými pracují.
Ajeje, uz tu zacina akademicka debata. Jeste ze to nemusim resit, asi se budu drzet Javy a jestli mi nekdo bude tvrdit, ze to neni tak vhodne na OOP, tak se budu smat, protoze kdo rikal, ze na tom zalezi, hlavne, ze se prace odvede dobre.
Ja jsem vlastne docela rad, ze jak Java, tak C# nejsou Kit-compliant OOP programovaci jazyky :D
Hosi, reknu vam to takhle a usetrim vam praci a dohadovani. Nevymyslejte bejkarny s OOP a podivejte se, jak to vypada v Jave a C# a jak se to pouziva v praxi, a toho se drzte, protoze nic lepsiho vymysleneho nebylo 8) A jestli to je Kit-compliant OOP je vec uplne druhorada, protoze bavime se o tom, co je lepsi a co horsi, o to jde predevsim 8)
Takže většina toho, čemu říkáme citáty, zvláště ty latinské, vlastně podle tebe vůbec citáty nejsou. Prosím, držme se obecně přijímaného významu slov a nevymýšlej si pro ně své vlastní definice. Ale nešť - tak jsem přeparafrázoval Kayovy názorySouhlas, tak si nevymýšlej nesmysly. Definice: “Citát je doslovné znění z díla spisovatele, anebo doslovně zopakovaný výrok. [...] Při citování se uvádí jak autor, tak i dílo v kterém se výrok objevil.” Tohle jsi měl mít na ZŠ (předpokládám, žes ji úspěšně ukončil), asi to fakt jde s naším školstvím od 5 k 0.
Ajeje, uz tu zacina akademicka debata.Begun the language wars have ;D
A jestli to je Kit-compliant OOP je vec uplne druhorada, protoze bavime se o tom, co je lepsi a co horsi, o to jde predevsim 8)
Za kvalitní objektový jazyk považuji Python a kousek za ním PHP. Java ani C# nevede programátory k OOP, ale ke strukturovanému programování. O pár stránek zpět bylo propagováno oddělení funkcí od datových struktur, což je přesně proti myšlence OOP, tedy že metody jsou co nejblíž k datům, se kterými pracují.
Dobrej priklad kde staticky typovani naprosto selhava jsou silne variabilni datovy struktury. Proste prace s json daty. To co mi posilaji nektery backend apj jsou jsony o deseti urovnich a skutecne nemam silu na to mapovat tohlr monstrum na nejakej muj class nebo haskell type.No a co pak s tím děláš? Máš strukturu struktury struktur. A to by mělo mít nějaký význam, ne? Třeba a.b.c je klíč pro nějakou konkrétní konkfiguraci (třeba). Takže to potom čekuješ ručně?
Dobrej priklad kde staticky typovani naprosto selhava jsou silne variabilni datovy struktury. Proste prace s json daty. To co mi posilaji nektery backend apj jsou jsony o deseti urovnich a skutecne nemam silu na to mapovat tohlr monstrum na nejakej muj class nebo haskell type.No a co pak s tím děláš? Máš strukturu struktury struktur. A to by mělo mít nějaký význam, ne? Třeba a.b.c je klíč pro nějakou konkrétní konkfiguraci (třeba). Takže to potom čekuješ ručně?
Můžeš prosím rozvést to "naprosto selhává"? Tak trochu v tom čuchám "nechce se mi to definovat, tak to nechám vágní, a řešit to budu potom...".
Dobrej priklad kde staticky typovani naprosto selhava jsou silne variabilni datovy struktury. Proste prace s json daty. To co mi posilaji nektery backend apj jsou jsony o deseti urovnich a skutecne nemam silu na to mapovat tohlr monstrum na nejakej muj class nebo haskell type.No a co pak s tím děláš? Máš strukturu struktury struktur. A to by mělo mít nějaký význam, ne? Třeba a.b.c je klíč pro nějakou konkrétní konkfiguraci (třeba). Takže to potom čekuješ ručně?
Můžeš prosím rozvést to "naprosto selhává"? Tak trochu v tom čuchám "nechce se mi to definovat, tak to nechám vágní, a řešit to budu potom...".
Chci z jsonu ziskat a.b.c
1. nechapu proc bych mel definovat typ nekolika urovnovyho jsonu
2. pokud to nebudu typovat ale budu s tim pracovat jako s dynamickym typem, pak mi statickej jazyk nijak nepomoh. naopak mi to zneprijemnil hloupyma hlaska a pri kompilaci
Dobrej priklad kde staticky typovani naprosto selhava jsou silne variabilni datovy struktury. Proste prace s json daty. To co mi posilaji nektery backend apj jsou jsony o deseti urovnich a skutecne nemam silu na to mapovat tohlr monstrum na nejakej muj class nebo haskell type.No a co pak s tím děláš? Máš strukturu struktury struktur. A to by mělo mít nějaký význam, ne? Třeba a.b.c je klíč pro nějakou konkrétní konkfiguraci (třeba). Takže to potom čekuješ ručně?
Můžeš prosím rozvést to "naprosto selhává"? Tak trochu v tom čuchám "nechce se mi to definovat, tak to nechám vágní, a řešit to budu potom...".
Chci z jsonu ziskat a.b.c
1. nechapu proc bych mel definovat typ nekolika urovnovyho jsonu
2. pokud to nebudu typovat ale budu s tim pracovat jako s dynamickym typem, pak mi statickej jazyk nijak nepomoh. naopak mi to zneprijemnil hloupyma hlaska a pri kompilaci
1. protože aby si dostal a.b.c a ne třeba a.b.x
2. to je tautologie. Já znám jen dvě možnosti: statickej typ= vím, že je tam a.b.c, dynamický typ: nevím nic. Tudíž, aby si to mohl zpracovat musíš tu informaci dodat dodatečně ručně. V čem ti dynamický typ pomohl?
Připomenu, já samozřejmě můžu ve statickém jazyce veškeré informace ignorovat, a pracovat jen s tuplem. (Sám si to zmiňoval "Node (string -> string|int|list|Node)"). Ale to pak znamená, jestli to chápu dobře, že jen a pouze chcetš si tu kontrolu dělat sám. To je veškerá výhoda dynamického typování? Možnost dělat si všechno ručně?
--
edit: jak si to po sobě čtu, možná by byl lepší výraz "záruka" na místo "vím". Protože já samozřejmě o té hodnotě můžu evidovat co je to za typ. Ale stroj s tím víc nepracuje.
Co bys považoval za dobrou alternativu k dynamizovanému statickému webu?Zahodit koncept webového prohlížeče a nahradit ho pouhou VM, zahodit koncept webových stránek a nahradit je kompletně jednotným standardizovaným bytekódem appletů, které ať si každý píše, v čem mu to vyhovuje/co je pro daný účel nejvýhodnější, doplnit o podepsané knihovny (dostupné transparentně z dotazovaného serveru či odjinud), vše spravované na straně klienta systémem cache. Webová stránka, jež je ze své podstaty pouhým označkovaným textem, by tak byla nahrazena plnohodnotným programem.
protoze nic lepsiho vymysleneho nebylo 8)Právě že bylo. :) Jestliže tytéž problémy vyřeším na třetině LOC a za pětinu času, tak ať mě nikdo nepřesvědčuje, že nepracuji s lepším nástrojem. Dlouhé roky jsem dělal v C++, backendy i frontendy, embedded i PC, pamatuji Turbo Vision i OWL, jásal jsem nad Qt... Něco málo (ve srovnání s objemem práce v C++) jsem dělal v Javě a v C#. Ale když to srovnám s věcmi jako Cocoa v Objective C nebo smalltalkovými frameworky, tak je to prostě parní stroj versus parní turbína - základní myšlenka je sice stejná, ale jsou tam jisté velmi podstatné rozdíly.
Už to tu zmiňoval Kit. Spíš jde o ty přívlastky statický/dynamický. Rozdíl bych viděl asi v tom, že ve statickém případě se v daném místě další (řádný) běh programu může odvíjet jedině od dat. V dynamickém od dat a/nebo jejich typu, nebo dokonce nezávisle na jejich typu. To dává větší spektrum možností, jak na ně program v daném místě může (řádně) reagovat. Ve statickém případě se musím omezit (často zbytečně defenzivně) jen na určitý typ dat, přičemž diskrepance mezi povinně deklarovaným očekávaným a reálně přijatým typem dat vede k chybovému stavu. Jsou to opačné imperativy - za všech okolností znát typ dat, s nimiž pracuji, vs. nestarat se o typ dat, dokud to nezbytně nepotřebuji k práci s nimi.V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.Nenašel jsem situaci, kdy by pozdní vazba bránila typům. Můžeš uvést příklad?
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky. O to, že v ní budou jen rohlíky, se postarám tak, že do ní prostě nic jiného nedám. Ale konat nákup za situace, že mám k dispozici jen tašky na rohlíky, přepravky na lahve, tašky na šunkové salámy, tašky na párky, tašky na chleby apod. by mohl být docela nesnadný úkol. Přitom v tom obchodě je jistě vhodné, aby zboží bylo roztříděno dle druhů, stejně tak ten, kdo z něj bude vařit, bude potřebovat odlišit máslo od chleba. Ale pro účely přenosu z obchodu domů to bude jedno, nebo spíš bude třeba odlišit, co je křehké a co ne. Křehká jsou vejce, ale taky třeba sklenice nebo žárovky či pivo ve skle. Nikoli však pivo v PETce. Pro účely uskladnění se bude rozlišovat podle toho, co půjde do ledničky (pivo bez ohledu na to, je-li ve skle či v PETce), co do mrazáku, co do špajzu. A to je právě ta mnohotvárnost - možnost klasifikovat tytéž objekty za různých situacích - pro různé potřeby různě. Ale k tomu je nezbytné, aby se s nimi technicky dalo zacházet úplně stejně - abych je pokud možno mohl všechny uchopit do ruky a tím s nimi manipulovat a pouhým pohledem, přičichnutím apod., prostě dle vlastnosti, jež mě zajímá, je klasifikovat (včetně situace "tohle mi dali místo sušenek Vanda, ty se už nevyrábějí, ale prý je to něco podobného" a "tohle vůbec netuším, co je, dali mi to pro Frantu, tak mu to prosím předej").Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.
Takže většina toho, čemu říkáme citáty, zvláště ty latinské, vlastně podle tebe vůbec citáty nejsou. Prosím, držme se obecně přijímaného významu slov a nevymýšlej si pro ně své vlastní definice. Ale nešť - tak jsem přeparafrázoval Kayovy názorySouhlas, tak si nevymýšlej nesmysly. Definice: “Citát je doslovné znění z díla spisovatele, anebo doslovně zopakovaný výrok. [...] Při citování se uvádí jak autor, tak i dílo v kterém se výrok objevil.” Tohle jsi měl mít na ZŠ (předpokládám, žes ji úspěšně ukončil), asi to fakt jde s naším školstvím od 5 k 0.
O pár stránek zpět bylo propagováno oddělení funkcí od datových struktur, což je přesně proti myšlence OOP, tedy že metody jsou co nejblíž k datům, se kterými pracují.OOP je o umístění stavu do objektu a o polymorfismu. To co popisuješ není dobrá definice. Vejdou se do toho snad všechny funkcionální jazyky. A možná i mnoho dalších neOOP.
1. "třeba"?!1. protože aby si dostal a.b.c a ne třeba a.b.x
2. to je tautologie. Já znám jen dvě možnosti: statickej typ= vím, že je tam a.b.c, dynamický typ: nevím nic. Tudíž, aby si to mohl zpracovat musíš tu informaci dodat dodatečně ručně. V čem ti dynamický typ pomohl?
Připomenu, já samozřejmě můžu ve statickém jazyce veškeré informace ignorovat, a pracovat jen s tuplem. (Sám si to zmiňoval "Node (string -> string|int|list|Node)"). Ale to pak znamená, jestli to chápu dobře, že jen a pouze chcetš si tu kontrolu dělat sám. To je veškerá výhoda dynamického typování? Možnost dělat si všechno ručně?
--
edit: jak si to po sobě čtu, možná by byl lepší výraz "záruka" na místo "vím". Protože já samozřejmě o té hodnotě můžu evidovat co je to za typ. Ale stroj s tím víc nepracuje.
1. kdyz tam chybi a.b.c, tak mi to muze vratit treba null a vubec se nebudu zlobit
2. popravde tvoji vetu nechapu. Nepotrebuju zadnou informaci dodavat. To, co se skryva pod a.b.c ma svuj dynamicky typ a to mi staci, abych a tim pracoval. Pokud a.b.c neexistuje, vrati mi to null, keyerror nebo jinou takovou hodnotu.
Nechapu kde jsi vytah, ze jsem tvrdil neco o 'veskerych vyhodach dynamickych jazyku'. Tvrdil jsem pouze, ze staticky jazyky v tomhle selhavaji a kazdej normalni clovek by pouzil 'tuple' misto definovanu tyou cely struktury. Tj. sahnul by po dynamickym typovani.
Já znám jen dvě možnosti: statickej typ= vím, že je tam a.b.c, dynamický typ: nevím nic. Tudíž, aby si to mohl zpracovat musíš tu informaci dodat dodatečně ručně. V čem ti dynamický typ pomohl?
Co bys považoval za dobrou alternativu k dynamizovanému statickému webu?Zahodit koncept webového prohlížeče a nahradit ho pouhou VM, zahodit koncept webových stránek a nahradit je kompletně jednotným standardizovaným bytekódem appletů, které ať si každý píše, v čem mu to vyhovuje/co je pro daný účel nejvýhodnější, doplnit o podepsané knihovny (dostupné transparentně z dotazovaného serveru či odjinud), vše spravované na straně klienta systémem cache. Webová stránka, jež je ze své podstaty pouhým označkovaným textem, by tak byla nahrazena plnohodnotným programem.
1. "třeba"?!1. protože aby si dostal a.b.c a ne třeba a.b.x
2. to je tautologie. Já znám jen dvě možnosti: statickej typ= vím, že je tam a.b.c, dynamický typ: nevím nic. Tudíž, aby si to mohl zpracovat musíš tu informaci dodat dodatečně ručně. V čem ti dynamický typ pomohl?
Připomenu, já samozřejmě můžu ve statickém jazyce veškeré informace ignorovat, a pracovat jen s tuplem. (Sám si to zmiňoval "Node (string -> string|int|list|Node)"). Ale to pak znamená, jestli to chápu dobře, že jen a pouze chcetš si tu kontrolu dělat sám. To je veškerá výhoda dynamického typování? Možnost dělat si všechno ručně?
--
edit: jak si to po sobě čtu, možná by byl lepší výraz "záruka" na místo "vím". Protože já samozřejmě o té hodnotě můžu evidovat co je to za typ. Ale stroj s tím víc nepracuje.
1. kdyz tam chybi a.b.c, tak mi to muze vratit treba null a vubec se nebudu zlobit
2. popravde tvoji vetu nechapu. Nepotrebuju zadnou informaci dodavat. To, co se skryva pod a.b.c ma svuj dynamicky typ a to mi staci, abych a tim pracoval. Pokud a.b.c neexistuje, vrati mi to null, keyerror nebo jinou takovou hodnotu.
Nechapu kde jsi vytah, ze jsem tvrdil neco o 'veskerych vyhodach dynamickych jazyku'. Tvrdil jsem pouze, ze staticky jazyky v tomhle selhavaji a kazdej normalni clovek by pouzil 'tuple' misto definovanu tyou cely struktury. Tj. sahnul by po dynamickym typovani.
2. Pokud pracuju s nějakou strukturou (mluvím o JSON), tak pokud s ní nějak pracuji, tak musím vědět co je zač. Tedy, potřebuji informaci. Že mám řadu klíčů a.b.c je informace. Protože třeba taky mohu dostat x.y.z. A to přeci není to samé. Otázka je, kdy tu informaci dodám. Buď předem, nebo dodatečně. Což má své důsledky.
Mé stanovisko (můžeš mě opravit) je, že dynamické jazyky se používají v situaci kdy:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování
3. neumím, nebo jazyk neumí typy
Příklad, který si uvedl, bych opravdu raději dělal v staticky typovaném jazyce. Právě proto, že by mi IMHO spoustu práce usnadnil.
Obávám se, že takto statické typování nefunguje. Všechny příklady tebou naznačného spektra možností mohu řešit. A statické typování mi bude hodně pomáhat. (A nemusím to dělat ručně.)Už to tu zmiňoval Kit. Spíš jde o ty přívlastky statický/dynamický. Rozdíl bych viděl asi v tom, že ve statickém případě se v daném místě další (řádný) běh programu může odvíjet jedině od dat. V dynamickém od dat a/nebo jejich typu, nebo dokonce nezávisle na jejich typu. To dává větší spektrum možností, jak na ně program v daném místě může (řádně) reagovat. Ve statickém případě se musím omezit (často zbytečně defenzivně) jen na určitý typ dat, přičemž diskrepance mezi povinně deklarovaným očekávaným a reálně přijatým typem dat vede k chybovému stavu. Jsou to opačné imperativy - za všech okolností znát typ dat, s nimiž pracuji, vs. nestarat se o typ dat, dokud to nezbytně nepotřebuji k práci s nimi.V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.Nenašel jsem situaci, kdy by pozdní vazba bránila typům. Můžeš uvést příklad?
To samozřejmě (u statického typování) nemusíš. Ale občas je fajn točit pivo do skleněné flašky, a bylinky sypat do papírové krabice. A zajistit, aby to nešlo naopak. Já tam neuváděl komponentu na inputy, ale komponentu na widgety.A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ?Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.
Nic ve zlym, ale je videt, ze vy lidi ze statickyho typovani jste matematici a zajima vas spis nejaka axiomaticka pravda vesmiru nez dodat vysledek zakaznikovi.Opak je pravdou.
2. Muzes si o ty strukture precist treba encyklopedii a vykouzlit nad tim nejakej katamorfismus. Ja mezitim zavolam query("a.b.c", json_objekt, else=null) a jdu domu s penezma od zakaznika.Kdepak, nejdeš. Já už jsem hotov, zatímco ty stále ještě honíš KeyError :-)
Co udělá statický typ, když mu místo a.b.c přijde a.b.x? V čem mi pomůže, když se takový program sesype, místo aby tu chybu zpracoval?Kde jsi sebral, že se ten program sesype? Staticky typované jazyky narozdíl od svých dynamických kolegů obvykle nepadaj (ne, že by vůbec, ale násobně méně).
2. Pokud pracuju s nějakou strukturou (mluvím o JSON), tak pokud s ní nějak pracuji, tak musím vědět co je zač. Tedy, potřebuji informaci. Že mám řadu klíčů a.b.c je informace. Protože třeba taky mohu dostat x.y.z. A to přeci není to samé. Otázka je, kdy tu informaci dodám. Buď předem, nebo dodatečně. Což má své důsledky.
Ne, to to skutečně neznamená.2. Pokud pracuju s nějakou strukturou (mluvím o JSON), tak pokud s ní nějak pracuji, tak musím vědět co je zač. Tedy, potřebuji informaci. Že mám řadu klíčů a.b.c je informace. Protože třeba taky mohu dostat x.y.z. A to přeci není to samé. Otázka je, kdy tu informaci dodám. Buď předem, nebo dodatečně. Což má své důsledky.
Statické typování znamená, že když chceš zpracovat JSON, tak bezpečně víš, že na první položce pole je číslo, na druhé je string a na třetí je datum: [42, "Adam", "1995-05-25"]. Běda, pokud zdroj dat přehodí pořadí - to pak vyběhne fatal error.
Při dynamickém typování bude v JSONu místo pole mapa: {id:42, name:"Adam", birthdate:"1995-05-25"}. Na rozdíl od statického přístupu jsou zde uvedeny skutečné typy, tedy id, name a birthdate. Nemusí nás trápit, pokud ten JSON má položky v jiném pořadí - podstatné je, že je zachována relace typ:hodnota.
Nic ve zlym, ale je videt, ze vy lidi ze statickyho typovani jste matematici a zajima vas spis nejaka axiomaticka pravda vesmiru nez dodat vysledek zakaznikovi.Opak je pravdou.2. Muzes si o ty strukture precist treba encyklopedii a vykouzlit nad tim nejakej katamorfismus. Ja mezitim zavolam query("a.b.c", json_objekt, else=null) a jdu domu s penezma od zakaznika.Kdepak, nejdeš. Já už jsem hotov, zatímco ty stále ještě honíš KeyError :-)
No nic, mír s tebou.
Jen tak pro informaci by mne zajímalo, který staticky typovaný jazyk standardně doporučuje mít v poli různé typy? Tím neříkám, že to v některých nejde, ale je to prostě prasárna, kdy poté musím používat reflexi. Pro tyto případy se používá mapa, což je tvůj druhý příklad. Jaký je rozdíl?2. Pokud pracuju s nějakou strukturou (mluvím o JSON), tak pokud s ní nějak pracuji, tak musím vědět co je zač. Tedy, potřebuji informaci. Že mám řadu klíčů a.b.c je informace. Protože třeba taky mohu dostat x.y.z. A to přeci není to samé. Otázka je, kdy tu informaci dodám. Buď předem, nebo dodatečně. Což má své důsledky.
Statické typování znamená, že když chceš zpracovat JSON, tak bezpečně víš, že na první položce pole je číslo, na druhé je string a na třetí je datum: [42, "Adam", "1995-05-25"]. Běda, pokud zdroj dat přehodí pořadí - to pak vyběhne fatal error.
Při dynamickém typování bude v JSONu místo pole mapa: {id:42, name:"Adam", birthdate:"1995-05-25"}. Na rozdíl od statického přístupu jsou zde uvedeny skutečné typy, tedy id, name a birthdate. Nemusí nás trápit, pokud ten JSON má položky v jiném pořadí - podstatné je, že je zachována relace typ:hodnota.
Jen tak pro informaci by mne zajímalo, který staticky typovaný jazyk standardně doporučuje mít v poli různé typy? Tím neříkám, že to v některých nejde, ale je to prostě prasárna, kdy poté musím používat reflexi. Pro tyto případy se používá mapa, což je tvůj druhý příklad. Jaký je rozdíl?
Celý ten případ s JSONem je na hlavu postavený. Pokud chci pracovat s hlubokou strukturou, prostě použiji JSONPath, stejně jako dříve uvedený příklad a mám to stejně rychle. Podle jazyka pak zpracuji chybu, pokud položka neexistuje. Žádný rozdíl.
Nejsem žádný mistr přes jazyky, ale pokud vím, všechny běžně používané staticky typované jazyky umožňují nějakým způsobem reflexi, takže není problém do nich dynamické typování "dodělat". Statické typování do dynamicky typovaných jazyků ale dodělat nelze.
Mám zkušenosti s oběma skupinami a největší rozdíl vidím v dokumentaci. Na co ve staticky typovaných jazycích stačí 3 řádky a odkaz na strukturu, je potřeba v dynamicky typovaných jazycích zpravidla 3x tolik informací. A ani potom nemám moc velkou jitotu, co tam skutečně může být.
... největší rozdíl vidím v dokumentaci.Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
... největší rozdíl vidím v dokumentaci.Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Mam dva objekty. Chci ziskat 'name'.
V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}
s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
Just x -> x
Nothing -> '')
print (Json.parse Person s)
s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError
Problem je 'presvedcit kompilator'. Napr. existuji programy, ktere dokaze clovek interpretovat, ale nelze je staticky overit. Soundness vs Completeness.
Prakticky kazdej praktickej clovek, kdo kdy delal v necem staticky typovanym a pak zkusil neco napsat v pythonu, jq nebo one line pipelinu ve shellu, chtel staticky jazyky hodit do kose. Staticky jazyky jsou dobry akorat na definovani jednoduchy funkce, kterou je treba silne zoptimalizovat.
Mam dva objekty. Chci ziskat 'name'.
V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}
Pseudokód, rozepsáno (pro laiky):Kód: [Vybrat]s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
Just x -> x
Nothing -> '')
print (Json.parse Person s)
Tak samozřejmě, že by to šlo napsat i pomocí toho query("name"), ale myslím si, že by to nikdo soudnej nedělal. Bylo by to přesně to dynamické, aniž by to přineslo nějaký užitek, a jen jeho nedostatky:Kód: [Vybrat]s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError
Problem je 'presvedcit kompilator'. Napr. existuji programy, ktere dokaze clovek interpretovat, ale nelze je staticky overit. Soundness vs Completeness.
Prakticky kazdej praktickej clovek, kdo kdy delal v necem staticky typovanym a pak zkusil neco napsat v pythonu, jq nebo one line pipelinu ve shellu, chtel staticky jazyky hodit do kose. Staticky jazyky jsou dobry akorat na definovani jednoduchy funkce, kterou je treba silne zoptimalizovat.
Ano, to jsem psal. Důvody pro dynamicky typovaný jazyk:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování
3. neumím, nebo jazyk neumí typy
Samozřejmě sám sebe označit za praktického člověka a pak všechny ty, kteří to mají jinak označit za nepraktické je hodně odvážně, ale budiž ti přáno.
Takže ještě jednou. Pokud by si byl schopen uvést nějakou výhodu dynamicky typovaných jazyků, krom těch mnou zmíněných tří bodů - sem s tím. V opačném případě to tedy můžem uzavřít.
Nemusíš. Naparsují se hodnoty, které tam jsou, které vyžaduješ. Ostatní je smetí, které se bude ignorovat.Mam dva objekty. Chci ziskat 'name'.
V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}
Pseudokód, rozepsáno (pro laiky):Kód: [Vybrat]s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
Just x -> x
Nothing -> '')
print (Json.parse Person s)
Tak samozřejmě, že by to šlo napsat i pomocí toho query("name"), ale myslím si, že by to nikdo soudnej nedělal. Bylo by to přesně to dynamické, aniž by to přineslo nějaký užitek, a jen jeho nedostatky:Kód: [Vybrat]s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError
Diky, to byl zacatek. Druhej den mi api posle json s velikosti bot. Treti den se tam objevi pole s vysi jeho platu, atd atd.
{id:42, name:"Adam"}
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam", birthdate:"1995-05-25", shoesize:43}
{id:42, name:"Adam", birthdate:"1995-05-25", salary:200000}
K moji smule musim kazdej den prepisovat typ Person i kdyz me zajima jenom jeho jmeno.
Druha vec. Je rozdil mezi chybejicim polem birthdate a kdyz je birthdate v jsonu null. Takze ten typ by vypadal spis (Maybe (Date|null)).Nevypadal.
Uzavrem to klidne. Myslim ze se shodnem na tom, ze schopnost dodat vysledek v staticky typovanym jazyce se v nekterych konkretnich prikladech realneho sveta blizi k nule. Muj verdikt o dynamickych jazycich v kontrastu tedy, muzes si to pridat jako dalsi bod, je ze jsou POUZITELNY. Jinymi slovy jsem schopen dodat vysledek. Se statickym jazykem ostatni lidi mezitim dodavaji akorat hromadu slibu.Neschodnem. Mě by zajímal konkrétní scénář, kdy je dynamický jazyk tak výrazně použitelnější, že to slovo píšeš kapitálkama. (Parsování JSON to evidentně není.) To, že to prohlašuješ mi pochopitelně nestačí.
Nemusíš. Naparsují se hodnoty, které tam jsou, které vyžaduješ. Ostatní je smetí, které se bude ignorovat.Mam dva objekty. Chci ziskat 'name'.
V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}
Pseudokód, rozepsáno (pro laiky):Kód: [Vybrat]s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
Just x -> x
Nothing -> '')
print (Json.parse Person s)
Tak samozřejmě, že by to šlo napsat i pomocí toho query("name"), ale myslím si, že by to nikdo soudnej nedělal. Bylo by to přesně to dynamické, aniž by to přineslo nějaký užitek, a jen jeho nedostatky:Kód: [Vybrat]s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError
Diky, to byl zacatek. Druhej den mi api posle json s velikosti bot. Treti den se tam objevi pole s vysi jeho platu, atd atd.
{id:42, name:"Adam"}
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam", birthdate:"1995-05-25", shoesize:43}
{id:42, name:"Adam", birthdate:"1995-05-25", salary:200000}
K moji smule musim kazdej den prepisovat typ Person i kdyz me zajima jenom jeho jmeno.Druha vec. Je rozdil mezi chybejicim polem birthdate a kdyz je birthdate v jsonu null. Takze ten typ by vypadal spis (Maybe (Date|null)).Nevypadal.Uzavrem to klidne. Myslim ze se shodnem na tom, ze schopnost dodat vysledek v staticky typovanym jazyce se v nekterych konkretnich prikladech realneho sveta blizi k nule. Muj verdikt o dynamickych jazycich v kontrastu tedy, muzes si to pridat jako dalsi bod, je ze jsou POUZITELNY. Jinymi slovy jsem schopen dodat vysledek. Se statickym jazykem ostatni lidi mezitim dodavaji akorat hromadu slibu.Neschodnem. Mě by zajímal konkrétní scénář, kdy je dynamický jazyk tak výrazně použitelnější, že to slovo píšeš kapitálkama. (Parsování JSON to evidentně není.) To, že to prohlašuješ mi pochopitelně nestačí.
Možná si budu muset počkat na někoho, kdo rozumí obému.
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?
Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..
Ke kazde z tech veci v te dobe existovaly podstatne lepsi alternativy, jen byly (z toho ci onoho duvodu = marketing) mene zname.
1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.Měl bys k tomuhle nějakej odkaz? Přijde mi divný, že by to zaznělo přesně takhle (že by tím důvodem byl právě hot code loading).
máš k dispozici algebraické typyTohle jsem moc zúžil. Nemusí to být jenom vyloženě algebraické typy, ale jakýkoliv mechanismus "nadtypů". Třeba i to klasické OOP "načtu přes síť objekt, neznám jeho kompletní typ, ale vím, že umí zpracovat zprávu saveToPdf" - to je taky "nadtyp".
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.Tady podsouváš něco, co není pravda (strawman). Že máš staticky typovaný jazyk ještě neimplikuje, že musíš nutně pracovat jenom s nějakými základními typy a všechny je zvlášť ošetřovat. Stačí ti mít nějaký mechanismus nadtypů (viz výš).
Mel bys na to nejaky odkaz? Nefunguje to u kazdeho jazyka s REPL?Statické typování se hodí pro strukturované programování, ale já raději používám OOP, ve kterém je lepší typovat dynamicky.1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.
2. Někdy se hodí, zejména na prototypování, když jsou typy volitelné, a následně to při refactoringu upřesňovat. Protože ze začátku člověk třeba nemá jasno, jak to má vypadat, a tak samozřejmě dost dobře nemůže ty typy určit.
Mel bys na to nejaky odkaz? Nefunguje to u kazdeho jazyka s REPL?S REPL to nemá nic společnýho. V Erlangu můžeš za běhu vyměnit jeden modul za jiný. Můžeš si to představit tak, jako bys v Javě vyměnil implementaci třídy String za jinou a všechen kód, včetně knihoven atd. začal pracovat s novou třídou (ta stará prostě vůbec neexistuje, vyhodíš ji). Nejsem si vůbec jistej, jestli tohle umí všechny jazyky, spíš bych řekl, že ne.
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.Tady podsouváš něco, co není pravda (strawman). Že máš staticky typovaný jazyk ještě neimplikuje, že musíš nutně pracovat jenom s nějakými základními typy a všechny je zvlášť ošetřovat. Stačí ti mít nějaký mechanismus nadtypů (viz výš).
Že některé statické jazyky nadtypy nemají, to považuju za zločin (jo, mluvím o tobě, Go!).
Čili v tom tvém příkladu: máš nadtyp "cokoli do čeho se dá vložit cokoli, co je menší než Boeing" ;)
Co máš na mysli těmi nadtypy, prosímtě?Typ je množina hodnot. Nadtyp je nadmnožina.
Co máš na mysli těmi nadtypy, prosímtě?Typ je množina hodnot. Nadtyp je nadmnožina.
Mel bys na to nejaky odkaz? Nefunguje to u kazdeho jazyka s REPL?S REPL to nemá nic společnýho. V Erlangu můžeš za běhu vyměnit jeden modul za jiný. Můžeš si to představit tak, jako bys v Javě vyměnil implementaci třídy String za jinou a všechen kód, včetně knihoven atd. začal pracovat s novou třídou (ta stará prostě vůbec neexistuje, vyhodíš ji). Nejsem si vůbec jistej, jestli tohle umí všechny jazyky, spíš bych řekl, že ne.
Tomu rozumím, ale asi tušíš, že na to jsem se neptal.Netušil jsem, jinak bych ti tak neodpovídal :)
Jde mi o tu implementaci; chápu, že třeba v Javě máš Object, narážíš konkrétně na Go, ale pokud tomu dobře rozumím, tak nízkoúrovňové jazyky obecně nic takového nemají.Nevím, co jsou "nízkoúrovňové jazyky". Bavíme se obecně o různých jazycích, takže těžko mluvit o konkrétní implementaci. Prakticky těch mechanismů může být víc, ale všechny mají stejný "filosofický" princip:
To E v REPL znamena "evaluate". Nevim jak jinde, ale v mem oblibenem clojure proste predhodim REPLu kod a on se evaluuje. To znamena, ze pokud v tom kodu prepisu funkci, nebo cely namespace tak stara verze kodu efektivne zmizi a je nahrazena tou predhozenou.No jistě, ale to je něco jinýho.
A uz sem to videl v akci i na produkci... (byl to trochu opruz kvuli sitarum a bezpecakum, ale nakonec to probehlo)
1. typ je "sjednocením" dvou typů -> algebraické typy (tj. prakticky: chci mít možnost napsat funkci, která vrací string nebo int)
2. nadtyp je definovaný tím, že má jenom některé vlastnosti podtypu -> dědičnost, interfejsy
Tedy "sum type"? Tak tam má Go asi fakt handicap.Jo. Nebo se používá i termín "composite type".
No ale interface naopak podporuje...Interfejsy sice podporuje, ale celkově je ten type systém dost omezený. Prakticky se to projevuje tak, že ve spoustě kódu uvidíš "prázdný interfejs" - tj. ekvivalent Object. Go je na tom prostě teď stejně jako Java před deseti lety. A i ty argumenty jsou stejné... (nejen) v tomhletom je Go trochu smutný příběh.
Ne že bych chtěl zrovna já obhajovat Go, jenom mě zajímalo, proč jsi po něm tak tvrdě vyjel.
Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?
Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..
Ke kazde z tech veci v te dobe existovaly podstatne lepsi alternativy, jen byly (z toho ci onoho duvodu = marketing) mene zname.
Me by zajimala ta lepsi alternativa sve doby ke vsemu z toho, co jsi uvedl.
Upřesnění:Upřesnění upřesnění: to je pak spíše protokol/rozhraní, případně trait.máš k dispozici algebraické typyTohle jsem moc zúžil. Nemusí to být jenom vyloženě algebraické typy, ale jakýkoliv mechanismus "nadtypů". Třeba i to klasické OOP "načtu přes síť objekt, neznám jeho kompletní typ, ale vím, že umí zpracovat zprávu saveToPdf" - to je taky "nadtyp".
Upřesnění upřesnění: to je pak spíše protokol/rozhraní, případně trait.No je to oboje. Chceš dosáhnout stejného cíle (vytvoření "obecnějšího typu") a jdeš na to buď přes algebraické typy nebo přes dědičnost nebo přes interfejsy.
Když by to bylo tak skvělé, tak proč se to nedělá?Svět by byl dnes jistě úplně jiný, pokud by se v něm prosazovaly zásadně jen věci, které jsou skvělé.
Obávám se, že takto statické typování nefunguje. Všechny příklady tebou naznačného spektra možností mohu řešit. A statické typování mi bude hodně pomáhat. (A nemusím to dělat ručně.)Netvrdím, že to nejde. Kdyby to nešlo, tak by většina praktických problémů byla neřešitelná staticky typovanými jazyky. Jenže to, co vnímáš jako cosi, co ti bude hodně pomáhat, já často vnímám jako klacky motající se pod nohama.
Zkusme být konkrétní. Bylo tu uvedeno parsování JSONu. Řešil bych to určitě staticky. Rozhodování zpracování podle typu dat? Staticky. Rozhodnování podle dat - to si nejsem jist, co myslíš. Jak se mohu rozhodovat podle dat? Čeho se mohu chytnout? Můžeš uvést příklad?
Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.To samozřejmě (u statického typování) nemusíš. Ale občas je fajn točit pivo do skleněné flašky, a bylinky sypat do papírové krabice. A zajistit, aby to nešlo naopak. Já tam neuváděl komponentu na inputy, ale komponentu na widgety.A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ?Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.
Taška na rohlíky je provokace. Jestli nechceš vést vážou diskusi, tak to řekni rovnou :-)
Neznám moc jazyků, které by obsahovaly "rohlík" jako jeden ze základních typů. Budu-li chtít modelovat nákupní tašku, tak jako nejjednodušší případ mě napadá nějaká kolekce, třeba seznam. Ale pořád mi tu BoneFlute nevysvětlil, seznam čeho by to optimálně měl být a jakou by to mělo výhodu oproti obecné dynamicky typované kolekci. Protože staticky typovaný jazyk mi říká "hele, tu informaci, co konkrétně se chystáš nakupovat, bezpodmínečně potřebuju znát dopředu", zatímco dynamicky typovaný jazyk nikoli. Vidím to tak, že ve statickém případě bych si musel definovat nějaký typ "zboží", který pojme veškerý sortiment plánovaného nákupu. Jenže proč bych se musel omezovat na cokoli, co třeba je menší než ten Boeing, když ze zadání problému neplyne, že bych nikdy neměl chtít koupit Boeing?A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.Tady podsouváš něco, co není pravda (strawman). Že máš staticky typovaný jazyk ještě neimplikuje, že musíš nutně pracovat jenom s nějakými základními typy a všechny je zvlášť ošetřovat. Stačí ti mít nějaký mechanismus nadtypů (viz výš).
Že některé statické jazyky nadtypy nemají, to považuju za zločin (jo, mluvím o tobě, Go!).
Čili v tom tvém příkladu: máš nadtyp "cokoli do čeho se dá vložit cokoli, co je menší než Boeing" ;)
Go má rozhraní (kterému výše říkáš “nadtyp”), což je právě ten hledaný duck typing. Viz též vnitřní implementace rozhraní v Go, dost to připomíná dynamické “typování” à la Smalltalk (navenek to je bohužel omezené syntaxí, ale jde to obejít).A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.Že některé statické jazyky nadtypy nemají, to považuju za zločin (jo, mluvím o tobě, Go!).
Určitě? Composite type je prachobyčejný record/struct/class: https://en.wikipedia.org/wiki/Composite_data_typeTedy "sum type"? Tak tam má Go asi fakt handicap.Jo. Nebo se používá i termín "composite type".
To E v REPL znamena "evaluate". Nevim jak jinde, ale v mem oblibenem clojure proste predhodim REPLu kod a on se evaluuje. To znamena, ze pokud v tom kodu prepisu funkci, nebo cely namespace tak stara verze kodu efektivne zmizi a je nahrazena tou predhozenou.No jistě, ale to je něco jinýho.
A uz sem to videl v akci i na produkci... (byl to trochu opruz kvuli sitarum a bezpecakum, ale nakonec to probehlo)
Hot reloading v Erlangu je o tom, že ti běží na serveru nějaká aplikace a ty v ní za běhu změníš část kódu. Klíčový je to, že měníš existující aplikaci, zatímco v REPLu vlastně vytváříš novou.
Protože staticky typovaný jazyk mi říká "hele, tu informaci, co konkrétně se chystáš nakupovat, bezpodmínečně potřebuju znát dopředu",A to právě není pravda. I ve statickém jazyce můžeš mít kolekci "neznámého" typu. Ten typ musí minimálně splňovat vlastnosti, které jsou pro tu danou kolekci potřeba (např. musí být hashovatelný) a maximálně to může být i konkrétní typ. K praktické implementaci pak potřebuješ parametrizovatelné typy - něco jako Array<String>.
Statické typování mě nutí, abych dopředu znal nějaké omezeníNe. Dobře udělané statické typování tě jenom nutí, aby ty vkládané objekty měly vlastnosti, které pro vložení do té které kolekce jsou nutně potřeba (např. ta hashovatelnost). A to je správně.
, nebo abych si ho uměle vytvořilNic takového se neděje.
Určitě? Composite type je prachobyčejný record/struct/class: https://en.wikipedia.org/wiki/Composite_data_typeNo dyť jo :) Struct můžeš taky zneužít jako nadtyp: pokud chceš funkci, která vrací string nebo int, tak vrátíš struct se dvěma položkami, jedna string a druhá int.
Ano na vzdalenem produkcnim serveru mi bezi existujici aplikace. Pripojim se pomoci nREPL a hot reloadnu si co chci...No vždyť já netvrdím, že to v Clojure nejde. Jenom říkám, že to neplyne z toho, že má REPL.
V navrhu erlangu to zrejme bylo klicove, zatimco v clojure to funguje spis nahodou, nez ze by to byl cil... ale funguje.
Samozrejme se na nejtere veci musi davat pozor.... Pokud sejdes z cesty a zacnes intenzivne pouzivat java interop, nebo atomy tak si muzes tu bezici aplikaci nakopnout. Ale pokud budes psat pure funkce tak je to bez problemu.
Tedy "sum type"? Tak tam má Go asi fakt handicap.Jo. Nebo se používá i termín "composite type".No ale interface naopak podporuje...Interfejsy sice podporuje, ale celkově je ten type systém dost omezený. Prakticky se to projevuje tak, že ve spoustě kódu uvidíš "prázdný interfejs" - tj. ekvivalent Object. Go je na tom prostě teď stejně jako Java před deseti lety. A i ty argumenty jsou stejné... (nejen) v tomhletom je Go trochu smutný příběh.
Ne že bych chtěl zrovna já obhajovat Go, jenom mě zajímalo, proč jsi po něm tak tvrdě vyjel.
Můžu, všechno se dá ochcat, ale už to není sum type.Určitě? Composite type je prachobyčejný record/struct/class: https://en.wikipedia.org/wiki/Composite_data_typeNo dyť jo :) Struct můžeš taky zneužít jako nadtyp: pokud chceš funkci, která vrací string nebo int, tak vrátíš struct se dvěma položkami, jedna string a druhá int.
Tak snad nemusí být hned tak zle. Mě to jen připomělo, že občas narážím na hlasy, které obhajují dynamické typování. A já bych si někdy opravdu docela rád vyslechl v čem je to užitečné. (Čímž díky @Kiwi-mu za pokus o vysvětlení, ačkoliv to zatím nestačilo :-) )
Jasně, i mně přijde návrh Go na hlavu (pragmatické výhody jsou, nepopírám). Teď řeší, jak udělat líp ošetření chyb, přičemž ale už v době původního návrhu jazyka muselo být jasné, že řešením je haskellovský Either. Jenže oni se rozhodli ten jazyk napsat takhle "blbě", protože takhle blbě se přece píše kód už desítky let a taky to jde.Jo, mám z toho úplně stejný pocit. V Go udělali několik rozhodnutí, který vůbec nechápu. V Rustu jsem na nic takovýho nenarazil (ale znám ho málo, daleko míň než Go, ve kterým jsem psal i nějaký netriviální produkční kód).
Na druhou stranu třeba Rust má prakticky všechno správně - má algebraické typy, má pattern matching, má monadické řetězení operací, všechno krásně zapadá. Na druhou stranu je ten jazyk statický až na půdu, všechny ty abstrakce se v době překladu zapečou až pomalu do železa. Může to omezovat, ale sedí mi to dohromady.
Můžu, všechno se dá ochcat, ale už to není sum type.Ne, je to product type ;)
Mě to jen připomělo, že občas narážím na hlasy, které obhajují dynamické typování. A já bych si někdy opravdu docela rád vyslechl v čem je to užitečné.Užitečná je pozdní vazba. A užitečná je i kontrola typů při překladu. Úplně nejlépe to má asi vyřešené ObjC, které má stejný dispatch zpráv jako Smalltalk, ale překladač kontroluje typy, jsou-li uvedeny (původní ObjC mělo jen “id”). Při překladu se tedy kontrolují typy vzhledem k hierarchii (dědičnost) a konformanci. Když chci, můžu použít “id” a pak se kontrola při překladu neprovádí. Většina běžného kódu tedy může být staticky otypovaná a jen v případě nouze můžu nechat kontrolu typů až na běh. Navíc v kombinaci s instancetype a auto se typy ani nemusí explicitně uvádět, překladač si je totiž odvodí (a zkontroluje) sám. V Go je pozdní vazba také (jako v ObjC) implementovaná pomocí isa, což se používá při volání metod na proměnných deklarovaných jako interface.
Ano na vzdalenem produkcnim serveru mi bezi existujici aplikace. Pripojim se pomoci nREPL a hot reloadnu si co chci...No vždyť já netvrdím, že to v Clojure nejde. Jenom říkám, že to neplyne z toho, že má REPL.
V navrhu erlangu to zrejme bylo klicove, zatimco v clojure to funguje spis nahodou, nez ze by to byl cil... ale funguje.
Samozrejme se na nejtere veci musi davat pozor.... Pokud sejdes z cesty a zacnes intenzivne pouzivat java interop, nebo atomy tak si muzes tu bezici aplikaci nakopnout. Ale pokud budes psat pure funkce tak je to bez problemu.
A ja si prave myslim, ze plyne. A koukal jsem na par prikladu jak se to dela v tom erlangu a prijde mi to velmi podobne. Neni eshell vlastne takovy REPL?Ne "vlastne takovy", eshell je REPL.
A ja si prave myslim, ze plyne. A koukal jsem na par prikladu jak se to dela v tom erlangu a prijde mi to velmi podobne. Neni eshell vlastne takovy REPL?Ne "vlastne takovy", eshell je REPL.
Akorat porad nezorumim tomu, proc tyhle dve vlastnosti spojujes, jsou uplne ortogonalni. REPL muzes udelat v jakemkoliv jazyce, k hot code (re)loadingu potrebujes nekolik predpokladu, ktere ne kazdy jazyk splnuje.
V JVM, co jsem se dočetl, hot reloading jde, ale nemůžeš měnit signatury ani odstraňovat nebo přidávat metody. Takže vlastně můžeš jenom měnit implementaci existujících věcí.
Jake jsou ty predpoklady ktere myslis, ze jsou k hot swapu potreba?No napriklad musis mit moznost nejak zabezpecit, ze kod nepoleze do kodu, ktery prave reloadujes. Nebo musis mit moznost mit zaraz v pameti dve verze tehoz. Pak musis mit vubec moznost kod za behu menit. Nesmi existovat zpusob, jak se na kod odkazovat (pointerem nebo necim podobnym), nebo musis mit moznost ty odkazy automaticky updatovat. Atd. atd. těch věcí je moře.
A btw. taky se domnivam, ze nejde udelat (plnotucny) REPL v kazdem jazyce... Treba ta java ho pokud vim nema. Co treba C?REPL není nic jiného než iteraktivní vyhodnocovač výrazů. Pokud pro nějaký jazyk není, tak spíš proto, že to u něj nedává moc smysl, např. proto, že výrazy jsou v tom jazyce podružná věc. Mám pocit, že máš nějaké mylné představy o magické podstatě REPLu :)
A btw. taky se domnivam, ze nejde udelat (plnotucny) REPL v kazdem jazyce... Treba ta java ho pokud vim nema. Co treba C?
A ja si prave myslim, ze plyne. A koukal jsem na par prikladu jak se to dela v tom erlangu a prijde mi to velmi podobne. Neni eshell vlastne takovy REPL?Ne "vlastne takovy", eshell je REPL.
Akorat porad nezorumim tomu, proc tyhle dve vlastnosti spojujes, jsou uplne ortogonalni. REPL muzes udelat v jakemkoliv jazyce, k hot code (re)loadingu potrebujes nekolik predpokladu, ktere ne kazdy jazyk splnuje.
V JVM, co jsem se dočetl, hot reloading jde, ale nemůžeš měnit signatury ani odstraňovat nebo přidávat metody. Takže vlastně můžeš jenom měnit implementaci existujících věcí.
Jake jsou ty predpoklady ktere myslis, ze jsou k hot swapu potreba?No napriklad musis mit moznost nejak zabezpecit, ze kod nepoleze do kodu, ktery prave reloadujes. Nebo musis mit moznost mit zaraz v pameti dve verze tehoz. Pak musis mit vubec moznost kod za behu menit. Nesmi existovat zpusob, jak se na kod odkazovat (pointerem nebo necim podobnym), nebo musis mit moznost ty odkazy automaticky updatovat. Atd. atd. těch věcí je moře.
Je možné, že výraz refactoring jsem nepoužil podle příručky.2. Někdy se hodí, zejména na prototypování, když jsou typy volitelné, a následně to při refactoringu upřesňovat. Protože ze začátku člověk třeba nemá jasno, jak to má vypadat, a tak samozřejmě dost dobře nemůže ty typy určit.
Tohle mi prijde zvlastni. refactoring chapu jako "cisteni" kodu v pripade, ze uz funguje spravne tzn. beze zmeny funkcionality... Abych mohl delat refactoring "bezpecne" potrebuju mit uz v ruce nejaky kontrolni mechanizmus (testy nebo typovou kontrolu), abych mohl po vycisteni prokazat, zachovani funcionality.
Takze, kdyz budu delat nejaky proof of concept tak muzu bez testu a bez typu, ale rozhodne to pak nebudu refactorovat do nejake produkcni verze, protoze bych se osypal.
function assetContactForm(form, name, age, email, content)
{
form['name'].value = name
form['age'].value = age
form['email'].value = email
form['content'].value = content
return form
}
Ze začátku to plníš takhle. Pak si ale řekneš, že by si chtěl omezit vstupy na číslo, text, etc. A nebo zjistíš, že vlastně ta funkce je celá blbě.No a ja tvrdim, ze pokud mas plnotucny REPL tak musis mit vsechny tyhle veci taky, protoze jinak bys nemohl mit ani ten. A z toho vyvozuju, ze pokud mas REPL mas i hot swap.Jake jsou ty predpoklady ktere myslis, ze jsou k hot swapu potreba?No napriklad musis mit moznost nejak zabezpecit, ze kod nepoleze do kodu, ktery prave reloadujes. Nebo musis mit moznost mit zaraz v pameti dve verze tehoz. Pak musis mit vubec moznost kod za behu menit. Nesmi existovat zpusob, jak se na kod odkazovat (pointerem nebo necim podobnym), nebo musis mit moznost ty odkazy automaticky updatovat. Atd. atd. těch věcí je moře.
A btw. taky se domnivam, ze nejde udelat (plnotucny) REPL v kazdem jazyce... Treba ta java ho pokud vim nema. Co treba C?REPL není nic jiného než iteraktivní vyhodnocovač výrazů. Pokud pro nějaký jazyk není, tak spíš proto, že to u něj nedává moc smysl, např. proto, že výrazy jsou v tom jazyce podružná věc. Mám pocit, že máš nějaké mylné představy o magické podstatě REPLu :)
Pro Javu existuje: https://www.infoq.com/articles/jshell-java-repl
Synku, Java to neni jen tak nejaka technologie s fajnovym marketingem, muzes metody pridavat, i tridy, potrebujes jen JVM opatchovat s DCEVM.Takže, tatínku, pro normální JVM od Sunu platí to, co jsem napsal :)
Např. pokud víš, že ve výrazu x / y je y s jistotou "integer", je ti to víceméně na nic, protože situace, kdy je y nula má stejné důsledky jako kdyby to byl string. Dělení nulou je stejně nedefinované jako dělení stringem. Takže kdykoli se ti v programu objeví dělení (nebo jakákoli jiná parciální funkce), stane se ti ze statického jazyka efektivně dynamický - protože prostě v době překladu nejsi schopný ověřit korektnost.S tím nemám problém. Já neobhajuji statické typování. Já hejtuju dynamické.
No a ja tvrdim, ze pokud mas plnotucny REPL tak musis mit vsechny tyhle veci taky, protoze jinak bys nemohl mit ani ten. A z toho vyvozuju, ze pokud mas REPL mas i hot swap.No tak to z chybného předpokladu vyvozuješ chybný závěr, no, co na to říct jiného? REPL máš třeba v pythonu a code reloading tam dělat nejde (AFAIK). Existující kód prostě běží dál, změny se projeví jenom v nově nataženém.
Pokud tomu tak neni tak to neni plnohodnotny REPL.Beru na vědomí tvou definici "plnohodnotného REPLu".
A btw. taky se domnivam, ze nejde udelat (plnotucny) REPL v kazdem jazyce... Treba ta java ho pokud vim nema. Co treba C?
REPL jde udělat s trochou snahy v každém jazyce: https://github.com/root-project/cling
S hot swapem to není tak jednoduché, vem si třeba inlinované funkce, jak bys je chtěl hot swapovat? Jediné rozumné řešení je všechno překompilovat, což už se dá dost těžko považovat za hot swap.
S tím nemám problém. Já neobhajuji statické typování. Já hejtuju dynamické.Však jo. Já jenom, že ty tvoje hejty platí i pro statické, jenom v menší míře.
Viz. odpoved Mirkovi. cling neznam, ale myslim, ze to nebude plnohodnotny REPL.
Bohužel. Někde jsem to četl. A klidně to může být kec, nestojí mi na tom můj světonázor :-)1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.Měl bys k tomuhle nějakej odkaz? Přijde mi divný, že by to zaznělo přesně takhle (že by tím důvodem byl právě hot code loading).
1. Několikrát opakuješ obrat "nemá typy". To je minimálně zavádějící. Dynamické jazyky mají typy. Od staticky typovaných se liší jenom tím, jestli informaci o typu znáš (pozitivně, s jistotou) při překladu, nebo až v době běhu. V principu provádíš tu stejnou kontrolu, jenom jindy. Výhoda statických jazyků je v tom, že kontrolu provedeš (ve většině případů - viz 2) jenom jednou, zatímco u dynamického ji musíš provádět pořád dokola, za běhu.Snažil jsem se bavit o statickém typování, nikoliv o staticky typovaných jazycích. A pro mě podstatný rozdíl je právě a hlavně v tom, že jsem schopen ten kód zkontrolovat při překladu. Jak píšeš. To, že při dynamickém typování ty výrazy si nesou typy, to jsem (doufám) nikde nerozporoval. Každopádně to nepovažuji za výhodu, ale za znouzecnost. Ale někteří tvrdí, že by to měla být výhoda.
2. Z bodu 1 přímo vyplývá, že statický jazyk má problém v situacích, kdy typ v době překladu z principu nemůžeš znát - to je ten příklad s načítáním JSONu, ale můžeš jich vymyslet bambilion jiných. Můžeš to řešit dvěma způsoby (možná i jinak, ale teď mě jiná možnost nenapadá):Uváděl jsem příklad jakéhosi kódu s JSONem. IMHO pro staticky typovaný jazyk to není problém. Dokonce bych se troufal tvrdit, že je na to šikovnější.
A) buď máš k dispozici algebraické typy a (v době překladu neznámý) typ prohlásíš za nějakou nadmnožinu různých typů, v extrémním případě všech myslitelných a dál pracuješ s tímhle nadtypem
B) nebo typ zjistíš za běhu (dynamické typování!) a program podle typu větvíš, takže i v době překladu víš, že do určité větve ti jde už jenom určitý typ
3. Někde jsi řekl, že do dynamických jazyků nejdou typy (při překladu) dodat. To není pravda. Stejně jako se u statického jazyka občas musíš uchýlit k dynamickému typování, můžeš u dynamického jazyka otypovat ty části programu, kde v době překladu víš, co tam bude za typ. A můžeš to i kontrolovat, úplně stejně jako u statického (viz např. u Erlangu Dializer). Dokonce by asi i šlo (ale nevím o žádném dynamickém jazyce, který by to uměl) třeba některé části programu otypovat staticky a u nich vyhodit kontroly typů za běhu.Myslím, že to jsem nebyl já.
Prostě, ty dva přístupy se vzájemně nevylučují. Je třeba si jenom uvědomit, že u některých částí programu víš předem, s jakými daty může pracovat, u jiných částí to nevíš (ani u jednoho typu jazyka). Ty části můžou být různě velké.Já vím.
Na druhou stranu s tebou docela souhlasím v tom, že udržovat tu část, kde typy znáš, co největší (a tím se vyvarovat runtime chybám) je docela dobrý přístup. Ale i kdyby ses na hlavu postavil, nemůžeš mít takových 100% programu. Někde prostě z principu věci dostaneš data, jejichž typ v době překladu neznáš.Otázka narážela na tvrzení, že dynamické typování má nějaké nesporné výhody. To, že mám blbej jazyk, který to neumí, nepovažuji za výhodu. To, že typy neumím, také nepovažuji za výhodu (i když...).
S tím nemám problém. Já neobhajuji statické typování. Já hejtuju dynamické.Však jo. Já jenom, že ty tvoje hejty platí i pro statické, jenom v menší míře.
Představ si funkci, která má argumenty a plní formulář:Kód: [Vybrat]function assetContactForm(form, name, age, email, content)
Ze začátku to plníš takhle. Pak si ale řekneš, že by si chtěl omezit vstupy na číslo, text, etc. A nebo zjistíš, že vlastně ta funkce je celá blbě.
{
form['name'].value = name
form['age'].value = age
form['email'].value = email
form['content'].value = content
return form
}
Využiješ situace, že na začátku pracuješ s ideálními podmínkami. Ale na závěr už chceš spolehlivý kód.
function assetContactForm(array $form, string $name, int $age, string $email, string $content) {
$form['name'] = $name;
$form['age'] = $age;
$form['email'] = $email;
$form['content'] = $content;
return $form;
}
Dokonce by asi i šlo (ale nevím o žádném dynamickém jazyce, který by to uměl) třeba některé části programu otypovat staticky a u nich vyhodit kontroly typů za běhu.PHP, google-closure-compiler, Flow, TypeScript.
V PHP to jde docela snadno. Prostě ty typy nacpeš do formálních parametrů a máš hotovo.Kód: [Vybrat]function assetContactForm(array $form, string $name, int $age, string $email, string $content) {
$form['name'] = $name;
$form['age'] = $age;
$form['email'] = $email;
$form['content'] = $content;
return $form;
}
Troufám si neskromě tvrdit, že celkem vím, jaký je rozdíl mezi staticky a dynamicky typováním. Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?
Zajímalo by mě pár kousků těch bambilionu jiných, kde dynamické typování je vhodnější (nikoliv jediné technicky možné).Neříkal jsem, že je vhodnější, ale že je bambilion případů, kdy musíš statické typování opustit a přejít na dynamické, protože prostě typ v době překladu neznáš. Je to jakákoliv situace, kdy data načítáš z externího zdroje. Z principu věci ti typový systém může zaručit, že je někde nějaký typ, jenom za předpokladu, že ten zdroj těch dat má pod kontrolou. Kdykoli načítáš ze sítě nebo z disku, typy nemáš.
Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?Se zkvalitněním inference výhody trochu ubývají. Ale pár bys jich našel. Například když potřebuješ někde na zkoušku nějaký typ změnit, může ti probublat do spousty kódu, takže to musíš změnit i na spoustě mít, který vůbec spouštět nechceš. Je to podobný jako s IO v Haskellu - nemůžeš si někam jenom tak narychlo dát nějaký debug výpis...
V PHP to jde docela snadno. Prostě ty typy nacpeš do formálních parametrů a máš hotovo.Kód: [Vybrat]function assetContactForm(array $form, string $name, int $age, string $email, string $content) {
$form['name'] = $name;
$form['age'] = $age;
$form['email'] = $email;
$form['content'] = $content;
return $form;
}
Aby to bylo typově korektní, tak ten $form musí být typu (Form String, Int, String, String, ...) :-P (Ale to samozřejmě nebylo pointou mého příspěvku.)
Uz je to davno co sem delal s pythonem. Ale melo by to jit.No a ja tvrdim, ze pokud mas plnotucny REPL tak musis mit vsechny tyhle veci taky, protoze jinak bys nemohl mit ani ten. A z toho vyvozuju, ze pokud mas REPL mas i hot swap.No tak to z chybného předpokladu vyvozuješ chybný závěr, no, co na to říct jiného? REPL máš třeba v pythonu a code reloading tam dělat nejde (AFAIK). Existující kód prostě běží dál, změny se projeví jenom v nově nataženém.
Pokud tomu tak neni tak to neni plnohodnotny REPL.Beru na vědomí tvou definici "plnohodnotného REPLu".
Ani ten ti ale na hot code reload nestačí.
Ale melo by to jit.Ne, nejde to, smiř se s tím, mýlíš se.
V PHP to jde docela snadno. Prostě ty typy nacpeš do formálních parametrů a máš hotovo.Kód: [Vybrat]function assetContactForm(array $form, string $name, int $age, string $email, string $content) {
$form['name'] = $name;
$form['age'] = $age;
$form['email'] = $email;
$form['content'] = $content;
return $form;
}
Aby to bylo typově korektní, tak ten $form musí být typu (Form String, Int, String, String, ...) :-P (Ale to samozřejmě nebylo pointou mého příspěvku.)
To by nefungovalo. Napsal jsem svůj kód dle tvého příkladu, který je v PHP korektní a funkční.
OK Miro. si omluven.Ale melo by to jit.Ne, nejde to, smiř se s tím, mýlíš se.
(sorry, tohle téma už mě nebaví, omlouvám se z něj)
Já nevím, tohle se mi nezdá. Když mám data z externího zdroje, stále to můžu otypovat. Typy dělají jakoby "cestičky". Prostě mám vstup od uživatele (co může být více nespolehlivé). A vím, typem určím, že buď zadá číslo, a pak ho zpracuju, nebo zadá nečíslo, a pak mu hodím chybovku. Tohle jde udělat compile-time.Zajímalo by mě pár kousků těch bambilionu jiných, kde dynamické typování je vhodnější (nikoliv jediné technicky možné).Neříkal jsem, že je vhodnější, ale že je bambilion případů, kdy musíš statické typování opustit a přejít na dynamické, protože prostě typ v době překladu neznáš. Je to jakákoliv situace, kdy data načítáš z externího zdroje. Z principu věci ti typový systém může zaručit, že je někde nějaký typ, jenom za předpokladu, že ten zdroj těch dat má pod kontrolou. Kdykoli načítáš ze sítě nebo z disku, typy nemáš.
Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?Se zkvalitněním inference výhody trochu ubývají. Ale pár bys jich našel. Například když potřebuješ někde na zkoušku nějaký typ změnit, může ti probublat do spousty kódu, takže to musíš změnit i na spoustě mít, který vůbec spouštět nechceš. Je to podobný jako s IO v Haskellu - nemůžeš si někam jenom tak narychlo dát nějaký debug výpis...
Tohle jasná výhoda je. A našel bys jich víc. Jestli převažují nevýhody, to ať si každý soudruh posoudí sám :)
Nechápu, co se pokoušíš říct?To by nefungovalo. Napsal jsem svůj kód dle tvého příkladu, který je v PHP korektní a funkční.V PHP to jde docela snadno. Prostě ty typy nacpeš do formálních parametrů a máš hotovo.Aby to bylo typově korektní, tak ten $form musí být typu (Form String, Int, String, String, ...) :-P (Ale to samozřejmě nebylo pointou mého příspěvku.)Kód: [Vybrat]function assetContactForm(array $form, string $name, int $age, string $email, string $content) {
$form['name'] = $name;
$form['age'] = $age;
$form['email'] = $email;
$form['content'] = $content;
return $form;
}
function assetContactForm(Form $form, string $name, int $age, string $email, string $content) {
$form->name = $name;
$form->age = $age;
$form->email = $email;
$form->content = $content;
return $form;
}
Vše řádně otypováno, včetně $form->name atd. Spokojen?
Je to podobný jako s IO v Haskellu - nemůžeš si někam jenom tak narychlo dát nějaký debug výpis...ale může http://hackage.haskell.org/package/base-4.12.0.0/docs/Debug-Trace.html#v:trace
Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?dynamický jazyk umožňuje napsat většinu konstrukcí jako ve statickém jazyce bez nutnosti přesvědčovat typechecker, že víte co děláte, taky se snadněji implementuje (protože nepotřebuje typechecker)
Je tu nejakej pythonak, kterej by rekl, jestli je to pouzitelne?
Existující kód prostě běží dál, změny se projeví jenom v nově nataženém.
ale může http://hackage.haskell.org/package/base-4.12.0.0/docs/Debug-Trace.html#v:traceJistě, ale to je hack.
Já nevím, tohle se mi nezdá. Když mám data z externího zdroje, stále to můžu otypovat. Typy dělají jakoby "cestičky". Prostě mám vstup od uživatele (co může být více nespolehlivé). A vím, typem určím, že buď zadá číslo, a pak ho zpracuju, nebo zadá nečíslo, a pak mu hodím chybovku. Tohle jde udělat compile-time.Zajímalo by mě pár kousků těch bambilionu jiných, kde dynamické typování je vhodnější (nikoliv jediné technicky možné).Neříkal jsem, že je vhodnější, ale že je bambilion případů, kdy musíš statické typování opustit a přejít na dynamické, protože prostě typ v době překladu neznáš. Je to jakákoliv situace, kdy data načítáš z externího zdroje. Z principu věci ti typový systém může zaručit, že je někde nějaký typ, jenom za předpokladu, že ten zdroj těch dat má pod kontrolou. Kdykoli načítáš ze sítě nebo z disku, typy nemáš.
Já nevím, tohle se mi nezdá. Když mám data z externího zdroje, stále to můžu otypovat. [...] typem určím, že buď zadá číslo, a pak ho zpracuju, nebo zadá nečíslo, a pak mu hodím chybovku. Tohle jde udělat compile-time.To rozlišení mezi číslem a (čímkoli jiným) není nic jinýho, než dynamický typování :) Vstup od uživatele není moc dobrej příklad, protože to je vždycky string. Zajímavější je třeba deserializace z disku nebo sítě.
Jde vlastně o featuru, moct ty typy vypnout. Protože třeba ten Haskell to vždycky kompiluje jako na produkci.Přesně tak. Chceš jenom něco narychlo prubnout a přitom jsi nucenej psát stejně kvalitní kód jako pro produkci. A to je opruz.
Přesně tak. Chceš jenom něco narychlo prubnout a přitom jsi nucenej psát stejně kvalitní kód jako pro produkci. A to je opruz.https://ghc.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime
Ty ne. Ty mas omluvenku ;-).Je tu nejakej pythonak, kterej by rekl, jestli je to pouzitelne?Existující kód prostě běží dál, změny se projeví jenom v nově nataženém.
Ale tak dobre... jestli moc chces muzes mi to vysvetlit. Ja budu poslouchat.https://stackoverflow.com/questions/3862871/hot-reloading-swapping-with-python
Ok. Procetl jsem. I nektere ty odkazovane veci. A nejsem si jisty, co mas na mysli.Ale tak dobre... jestli moc chces muzes mi to vysvetlit. Ja budu poslouchat.https://stackoverflow.com/questions/3862871/hot-reloading-swapping-with-python
Zajímavější je třeba deserializace z disku nebo sítě.V čem je to jiné? Taky dostanu proud dat, defakto string, defakto zase musím použít Maybe.
To, ze stare objekty (vytvorene podle predchozi verze kodu) zustanou nezmenene je snad v poradku ne?Ne. To je to, co ti porad nedochazi. Podstata je ve vymene stareho za nove ne ve vytvoreni noveho. To druhé Python umí (a umí to jakýkoliv jazyk s REPL), to první ne.
V čem je to jiné? Taky dostanu proud dat, defakto string, defakto zase musím použít Maybe.Jiné je to v tom, že serializovaná data můžou obsahovat serializované typy. Tj. dostaneš se přesně do situace dynamicky typovaného jazyka - typy znáš (pozitivně, jistě) v době běhu, ale ne v době překladu.
Uvazujes tak, ze uz vis presne, co s temi prichozimi daty chces udelat. Tj. ziskat jmeno, cislo, pripadne hodit error, kdyz se to nepovede.Supr. Tak jsme se s velkou parádou dostaly k bodu dva, o tom, že bez typů se lépe prototypuje. To je všechno?
Ale aby sis moh s temi prichozimi daty hrat a prozkoumavat je, musis je bud plne otypovat nebo pouzit dynamicky typovani. Zjistili jsme ze plne typovat ty jsony nechces, dynamicky typovat je taky nechces, tak mi z toho vyplyva opet, ze potrebujes presny zadani, jinak odmitas pracovat.
To reprezentuje tu sortu programatoru, ktery se nehnou z mista, dokud nemaji precizne zpracovany zadani. S preciznim zadanim je pak suna fuk jestli pouzijes python nebo haskell, protoze jsi dostal definici vstupu a vystupu, tak z toho akorat napises funkci.
Programivani je ale casto o prozkoumavani moznych reseni. A proto v nejistych podminkach dynamicky jazyky vzdy zvitezily.
To, ze stare objekty (vytvorene podle predchozi verze kodu) zustanou nezmenene je snad v poradku ne?Ne. To je to, co ti porad nedochazi. Podstata je ve vymene stareho za nove ne ve vytvoreni noveho. To druhé Python umí (a umí to jakýkoliv jazyk s REPL), to první ne.
Tak to ale erlang taky neumi.Jak jsi na to prisel?
Chlopé, běžte ven (mezi lidi)!Já náhodou běhám celej den.
:) ;) :D ;D
Kdyz hotswapnu nejaky modul ktery ma funkci akceptujici tuple tak mi otp samo zmigruje vsechny existujici relevantni tuply ktere do ni muzou prijit?Tak to ale erlang taky neumi.Jak jsi na to prisel?
Kdyz hotswapnu nejaky modul ktery ma funkci akceptujici tuple tak mi otp samo zmigruje vsechny existujici relevantni tuply ktere do ni muzou prijit?Úplně neumím rozšifrovat, na co se vlastně ptáš. Každopádně se nic samo nemigruje. Ale v OTP existují postupy, jak stavy zmigrovat. I způsoby, jak udělat rollback. Je to dost komplexní věc, nedá se to vysvětlit pár větama. Ale můžeš si něco o tom vygooglit, po netu je toho spousta.
A brani mi neco udelat ty migrace podobne v pythonu? Pokud vim tak erlang ma nemenitelne datove struktury. Takze migrace stavu bude znamenat zahozeni stareho a vytvoreni noveho stavu.Kdyz hotswapnu nejaky modul ktery ma funkci akceptujici tuple tak mi otp samo zmigruje vsechny existujici relevantni tuply ktere do ni muzou prijit?Úplně neumím rozšifrovat, na co se vlastně ptáš. Každopádně se nic samo nemigruje. Ale v OTP existují postupy, jak stavy zmigrovat. I způsoby, jak udělat rollback. Je to dost komplexní věc, nedá se to vysvětlit pár větama. Ale můžeš si něco o tom vygooglit, po netu je toho spousta.
A brani mi neco udelat ty migrace podobne v pythonu?Ano, několik věcí - a je to popsané v tom odkazu, co's říkal, že sis pročetl.
Pokud vim tak erlang ma nemenitelne datove struktury. Takze migrace stavu bude znamenat zahozeni stareho a vytvoreni noveho stavu.Ne. V Erlangu se stav udržuje tak, že se předává z jedné funkce do druhé. V event-loopu pak typicky ta funkce volá sebe sama:
def loop(stav) do
# do something
loop(stav)
end
(Tohle je Elixir, ale to je úplně to samý jako Erlang)Hmm. Nepresvedcil si me, ale nehodlam to dal tlacit, protoze python tolik neznam.A brani mi neco udelat ty migrace podobne v pythonu?Ano, několik věcí - a je to popsané v tom odkazu, co's říkal, že sis pročetl.
Fajn, ale stav je porad immutable. Takze ta funkce co se postara o upgrade vytvori novy stav a preda ho zpet do smycky.Pokud vim tak erlang ma nemenitelne datove struktury. Takze migrace stavu bude znamenat zahozeni stareho a vytvoreni noveho stavu.Ne. V Erlangu se stav udržuje tak, že se předává z jedné funkce do druhé. V event-loopu pak typicky ta funkce volá sebe sama:Kód: [Vybrat]def loop(stav) do
(Tohle je Elixir, ale to je úplně to samý jako Erlang)
# do something
loop(stav)
end
V OTP je pak tohle ještě zabalený do wrapperu, kterej když zjistí, že jsi kód upgradnul, tak automaticky zavolá funkci, která se o upgrade toho "stav" postará. Viz "Changing Internal State" http://erlang.org/doc/design_principles/appup_cookbook.html
Hmm. Nepresvedcil si me, ale nehodlam to dal tlacit, protoze python tolik neznam.Ale já tě přece nepřesvědčuju, jenom říkám, že to máš popsané na té odkazované SO stránce a na jiných z ní odkazovaných:
You can use reload(module) for this, but beware of nasty side effects. For example, existing code will be based on the original code, it will not magically get new attributes or baseclasses added.https://stackoverflow.com/questions/3862871/hot-reloading-swapping-with-python
Python modules’ code is recompiled and the module-level code reexecuted, defining a new set of objects which are bound to names in the module’s dictionary. The init function of extension modules is not called a second time. As with all other objects in Python the old objects are only reclaimed after their reference counts drop to zero. The names in the module namespace are updated to point to any new or changed objects. Other references to the old objects (such as names external to the module) are not rebound to refer to the new objects and must be updated in each namespace where they occur if that is desired.https://stackoverflow.com/questions/437589/how-do-i-unload-reload-a-python-module
Fajn, ale stav je porad immutable. Takze ta funkce co se postara o upgrade vytvori novy stav a preda ho zpet do smycky.Samozřejmě. V Erlangu žádná funkce nic jiného než vytvářet nová data nemůže. Erlang má naprosto striktně imutabilní data. A proč to říkáš?
Koukni na co reaguju. Tam mi tvrdis ze to tak neni.Fajn, ale stav je porad immutable. Takze ta funkce co se postara o upgrade vytvori novy stav a preda ho zpet do smycky.Samozřejmě. V Erlangu žádná funkce nic jiného než vytvářet nová data nemůže. Erlang má naprosto striktně imutabilní data. A proč to říkáš?
Koukni na co reaguju. Tam mi tvrdis ze to tak neni.Máš pravdu, že jsem to napsal blbě. Chtěl jsem říct, že to není nic zvláštního, že v tom není podstata hot code loadingu. To "vytvoření nového stavu" se dělá po každém eventu (který mění stav).
Me uz taky ne. :) Tak toho nechame.Koukni na co reaguju. Tam mi tvrdis ze to tak neni.Máš pravdu, že jsem to napsal blbě. Chtěl jsem říct, že to není nic zvláštního, že v tom není podstata hot code loadingu. To "vytvoření nového stavu" se dělá po každém eventu (který mění stav).
A pořád mi není jasný, proč se o tom vlastně bavíme :)
Je to zlocinecka organizace a Arafat je terorista. :-)
Míjíte se s tím, co se snažím říct. Podstata sdělení je v tom příspěvku, který jste citoval, líp ji asi nevyjádřím:Ne, o výkon nejde, spíš mě štve, jakým způsobem OOP strukturuje uvažování. V době největšího OOP-hypu se OOP vydávalo ne za model reality, ale tvářilo se, že má téměř ontologickou povahu. Tj. v knížkách se podvědomě sugerovala představa, že svět JE takový (má takovou strukturu), jak ho OOP modeluje. Tedy že OOP je vlastně "přirozený". A to je strašně destruktivní iluze.
;DKed je OOP zo Smalltalku tak super hyper uzasne pre co sa (smalltalk) nepouziva?Ovšem musím varovat před tím, že se ti pak Java možná zhnusí.
V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.
Ajeje, uz tu zacina akademicka debata. Jeste ze to nemusim resit, asi se budu drzet Javy a jestli mi nekdo bude tvrdit, ze to neni tak vhodne na OOP, tak se budu smat, protoze kdo rikal, ze na tom zalezi, hlavne, ze se prace odvede dobre.
Ja jsem vlastne docela rad, ze jak Java, tak C# nejsou Kit-compliant OOP programovaci jazyky :D
Hosi, reknu vam to takhle a usetrim vam praci a dohadovani. Nevymyslejte bejkarny s OOP a podivejte se, jak to vypada v Jave a C# a jak se to pouziva v praxi, a toho se drzte, protoze nic lepsiho vymysleneho nebylo 8) A jestli to je Kit-compliant OOP je vec uplne druhorada, protoze bavime se o tom, co je lepsi a co horsi, o to jde predevsim 8)
Za kvalitní objektový jazyk považuji Python...
O pár stránek zpět bylo propagováno oddělení funkcí od datových struktur, což je přesně proti myšlence OOP, tedy že metody jsou co nejblíž k datům, se kterými pracují.
OOP je o umístění stavu do objektu a o polymorfismu.
To co popisuješ není dobrá definice. Vejdou se do toho snad všechny funkcionální jazyky. A možná i mnoho dalších neOOP.
Za kvalitní objektový jazyk považuji Python...
Tak to máte docela nízké požadavky na kvalitu. Python je sice syntakticky přehledný a má dost knihoven, takže se v něm rychle dělá, ale ZCELA ZBYTEČNĚ obsahuje neobjektové konstrukce (len(řetězec), ...), na zapouzdření dlabe (přestože implementace by pravděpodobně ani nebyla složitá), definice třídních metod je řešena nekoncepčně přes jakési anotace... To mě napadá jen tak z hlavy, na co jsem stihnul zběžně narazit.
...Protoze me prijde, ze je tady jasny trend, ze od OOP, a myslim tim ted to puritanske paradigma, se ustupuje uz nekolik let jak v Jave, tak v C#. Tomu se rika stredni cesta, jestlis o tom nekdy neslysel. A dam vsadil bych se ze proto, ze se lidi sw inzenyri napric celou industry vic a vic shodli, ze to proste je takhle LEPSI. A kdyz je to takhle LEPSI, tak je to proste LEPSI.
...Protoze me prijde, ze je tady jasny trend, ze od OOP, a myslim tim ted to puritanske paradigma, se ustupuje uz nekolik let jak v Jave, tak v C#. Tomu se rika stredni cesta, jestlis o tom nekdy neslysel. A dam vsadil bych se ze proto, ze se lidi sw inzenyri napric celou industry vic a vic shodli, ze to proste je takhle LEPSI. A kdyz je to takhle LEPSI, tak je to proste LEPSI.Těžko ustupovat od (Kayova) OOP, když se vlastně nikdy ani pořádně nepoužívalo.
Tu shodu bych prosil doložit.
Co je to "industry"?
O pár stránek zpět bylo propagováno oddělení funkcí od datových struktur, což je přesně proti myšlence OOP, tedy že metody jsou co nejblíž k datům, se kterými pracují.
OOP je o umístění stavu do objektu a o polymorfismu.
To nestačí. Kit to píše dobře. Myšlenkou OOP je, že stavy bez popisu svých změn a změny bez stavů nemají smysl, neboli jsou neoddělitelné.To co popisuješ není dobrá definice. Vejdou se do toho snad všechny funkcionální jazyky. A možná i mnoho dalších neOOP.
Funkcionální jazyky neznám, ale z toho, co jsem zatím viděl, řeší výpočet přesně opačně.
type Person = Person String String Int
getName (Person x _ _) = x
getSurname (Person _ x _) = x
getAge (Person _ _ x) = x
getFullname p = getName p .. " " .. getSurname p .. " (" .. getAge p .. ")"
parsePerson :: String -> Person
parsePerson s = ......
Tak jinak - jak by podle tebe vypadala implementace polymorfismu tak, jak je chápán v objektovém paradigmatu, prostředky (nikoli jejich obcházením) staticky typovaného prostředí?V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.
Už to tu psal tuším p. Prýmek: Typ typování souvisí jen okrajově s polymorfismem - typovaný systém vede pouze na užší vyhledávání metody na straně obeslaného objektu dle typů ve zprávě, nic víc. Nepleťte si to s prasojazyky Java a C#, kdy jejich problémem není samotné typování, ale tzv. podtypový polymorfismus jako prostředek realizace časné vazby znemožňující kamarádění objektů (instancí) typově (třídně) nepříbuzných.
Neobjektové konstrukce nejsou zbytečné, python není oop jazyk, ale hybridní. Jestli mu neco vycist, tak to, ze by default krome len(list) neumi i list.len(). Zapouzdreni ma. Proc povazujete dekoratory za nekoncepcni? Python nepouziva modifikujici klicova slova, ale obecneji fungujici a uzivatelsky nastavitelne dekorarory, coz je koncept.Za kvalitní objektový jazyk považuji Python...Tak to máte docela nízké požadavky na kvalitu. Python je sice syntakticky přehledný a má dost knihoven, takže se v něm rychle dělá, ale ZCELA ZBYTEČNĚ obsahuje neobjektové konstrukce (len(řetězec), ...), na zapouzdření dlabe (přestože implementace by pravděpodobně ani nebyla složitá), definice třídních metod je řešena nekoncepčně přes jakési anotace... To mě napadá jen tak z hlavy, na co jsem stihnul zběžně narazit.
Funkcionální jazyky neznám, ale z toho, co jsem zatím viděl, řeší výpočet přesně opačně.- funkce popisují změny stavu
- bez stavu nemají smysl
- jsou neoddělitelné
Jediný rozdíl je, že ten stav je vně.
Tak jinak - jak by podle tebe vypadala implementace polymorfismu tak, jak je chápán v objektovém paradigmatu, prostředky (nikoli jejich obcházením) staticky typovaného prostředí?V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.
Už to tu psal tuším p. Prýmek: Typ typování souvisí jen okrajově s polymorfismem - typovaný systém vede pouze na užší vyhledávání metody na straně obeslaného objektu dle typů ve zprávě, nic víc. Nepleťte si to s prasojazyky Java a C#, kdy jejich problémem není samotné typování, ale tzv. podtypový polymorfismus jako prostředek realizace časné vazby znemožňující kamarádění objektů (instancí) typově (třídně) nepříbuzných.
...Blbec jsem čekal odpověď od SB, hrozně se divil, když ta odpověď nějak přestávala dávat smysl...
...Blbec jsem čekal odpověď od SB, hrozně se divil, když ta odpověď nějak přestávala dávat smysl...
Jsi hodný, ale já nepotřebuju vědět všechno....Blbec jsem čekal odpověď od SB, hrozně se divil, když ta odpověď nějak přestávala dávat smysl...
Potřebuješ, abych ti to vysvětlil nějako podrobněji? Neboj se zeptat.
Takže něco takového jako když já po milióntý prvý pouštím celou aplikaci, a píšu druhou miliardu testů, aby to pokrylo alespoň 5procent všech možnejch chyb? :-)Obávám se, že takto statické typování nefunguje. Všechny příklady tebou naznačného spektra možností mohu řešit. A statické typování mi bude hodně pomáhat. (A nemusím to dělat ručně.)Netvrdím, že to nejde. Kdyby to nešlo, tak by většina praktických problémů byla neřešitelná staticky typovanými jazyky. Jenže to, co vnímáš jako cosi, co ti bude hodně pomáhat, já často vnímám jako klacky motající se pod nohama.
Zkusme být konkrétní. Bylo tu uvedeno parsování JSONu. Řešil bych to určitě staticky. Rozhodování zpracování podle typu dat? Staticky. Rozhodnování podle dat - to si nejsem jist, co myslíš. Jak se mohu rozhodovat podle dat? Čeho se mohu chytnout? Můžeš uvést příklad?
Rozhodování podle dat, tím myslím IF size > 5 cm THEN ...Rozumím. Tak první bude nějaká funkce. Druhé bude pattern matching na typ. A třetí se řeší třídou/interfacem. Viz odpověď dále.
Rozhodování podle typu, tím myslím IF (x hasMagnitude) THEN ...
Rozhodování bez ohledu na typ, tím myslím IF x > 5 THEN ..., bez ohledu na to, co to "x" je, protože mě zajímá jen odpověď na otázku, zda "to" je větší než 5.
Konkrétní příklad bych vzal mnohem prostší - chceš realizovat jakýsi print(x), který zajistí vypsání argumentu na terminál. Jaký datový typ x-u by ta funkce měla podle tebe optimálně očekávat a proč? V čem mi jakožto vývojáři pomůže, že ta funkce očekává ten konkrétní datový typ? Uvažuješ-li o stringu, tak pokračuj v úvaze dál - jak se teda pak vypořádat s ne-stringy. Nebo třeba seznam v Pascalu...typ show (v případně Javy by to bylo něco jako Printable)
Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.Smysl statických typů je zajistit, aby se něco takového nestalo. Když zůstaneme u přirovnání, tak ty budeš muset hostinského zaškolit, a ještě nainstalovat kameru, aby si ho sledoval, zda nečepuje pivo přímo do pusy. A stejně ho neuhlídáš. Zatímco já tam budu moct dát cedulku "samoobslužná pípa".
Co je na tašce na rohlíky tak provokativního? Do datového typu rohlík dám jen rohlík a seznam rohlíků není nic jiného než taška na rohlíky. V době překladu vím, že mám datový typ, do kterého můžu naskládat jedině rohlíky. Jistě, mohu vytvořit i datový typ, do něhož jdou sázet rohlíky a housky. Ale i tuto situaci musím předvídat v době překladu.Ano, musím to předvídat v době překladu. To je jediné, v čem máš pravdu. Jinak fakt neuvažuju, tak jak popisuješ.
Neznám moc jazyků, které by obsahovaly "rohlík" jako jeden ze základních typů.Taky nás nic takového nezajímá. Doba typování ala jazyk C je naštěstí už dávno pryč.
Budu-li chtít modelovat nákupní tašku, tak jako nejjednodušší případ mě napadá nějaká kolekce, třeba seznam. Ale pořád mi tu BoneFlute nevysvětlil, seznam čeho by to optimálně měl být a jakou by to mělo výhodu oproti obecné dynamicky typované kolekci.Toho, čeho potřebuješ. To přirovnání je debilní, ale tak můžeš mít nákupní tašku na pečivo. Takže obecný typ pro pečivo. Nebo typ TuháHmota, aby si tam nečepoval to pivo. Atd.
Protože staticky typovaný jazyk mi říká "hele, tu informaci, co konkrétně se chystáš nakupovat, bezpodmínečně potřebuju znát dopředu", zatímco dynamicky typovaný jazyk nikoli.Není nutné, uvádět úplně konkréntí informaci, tam kde ji nepotřebuješ vědět. S tím si typy poraděj.
Statické typování mě nutí, abych dopředu znal nějaké omezení, nebo abych si ho uměle vytvořil, ačkoli z řešeného problému vůbec neplyne.Nenutí, nemusíš vytvářet, pokud skutečně neplyne. Ale častokrát plyne. Statické typování dělá úplně jinou věc.
Nejčastějším problémem, se kterým se vývojář ve své pracovní době potýká, není obvykle přímo problém, který má za úkol vyřešit, ale jak se vypořádat s problémy, které si nadělal sám sobě dříve nebo které mu vymysleli jeho předchůdci. Takže jakmile se zákazník zeptá, proč nejde koupit Boeing, co mu na to odpovíš? A jak se budeš tvářit, až po X mandays práce, spočívající v překopávání půlky programu kvůli Boeingu, ti zákazník nezaplatí ani halíř, protože v té původní smlouvě o dílo není nikde napsáno, že by ten program neměl umět nakupovat Boeingy?To zdaleka není specifické pro Statické typování. Ve skutečnosti je to tak, že:
... a nemusime type checkeru vysvetlovat nektere situace.Tak, že nepoužití typů je jednodužší pro autora jazyka, to je tak nějak jasné. Ale tady mi tvrdí, že to má výhody pro někoho, kdo ten jazyk bude používat.
Většina běžného kódu tedy může být staticky otypovaná a jen v případě nouze můžu nechat kontrolu typů až na běh.O jakém případě nouze mluvíš? Můžeš to rozvést? Nějaký příklad?
Tak pod pojmem řádně otypováno si představuju něco dost jiného. Dej si ještě práci, když už odvádíš téma.Aby to bylo typově korektní, tak ten $form musí být typu (Form String, Int, String, String, ...) :-P (Ale to samozřejmě nebylo pointou mého příspěvku.)
V původní ukázce jsi nic takového neuvedl, proto jsem to udělal tak jak jsem to udělal. Pokud Form bude třída, tak to bude v PHP vypadat asi takto:Kód: [Vybrat]function assetContactForm(Form $form, string $name, int $age, string $email, string $content) {
Vše řádně otypováno, včetně $form->name atd. Spokojen?
$form->name = $name;
$form->age = $age;
$form->email = $email;
$form->content = $content;
return $form;
}
Je to ošetřený a rozhodnutý v době překladu. To je to co mě zajímá.Já nevím, tohle se mi nezdá. Když mám data z externího zdroje, stále to můžu otypovat. [...] typem určím, že buď zadá číslo, a pak ho zpracuju, nebo zadá nečíslo, a pak mu hodím chybovku. Tohle jde udělat compile-time.To rozlišení mezi číslem a (čímkoli jiným) není nic jinýho, než dynamický typování :)
Smysl statických typů je zajistit, aby se něco takového nestalo.Smyslem statickych typu je vykonostni optimalizace.
Jen tak pro informaci by mne zajímalo, který staticky typovaný jazyk standardně doporučuje mít v poli různé typy? Tím neříkám, že to v některých nejde, ale je to prostě prasárna, kdy poté musím používat reflexi. Pro tyto případy se používá mapa, což je tvůj druhý příklad. Jaký je rozdíl?
Celý ten případ s JSONem je na hlavu postavený. Pokud chci pracovat s hlubokou strukturou, prostě použiji JSONPath, stejně jako dříve uvedený příklad a mám to stejně rychle. Podle jazyka pak zpracuji chybu, pokud položka neexistuje. Žádný rozdíl.
Nejsem žádný mistr přes jazyky, ale pokud vím, všechny běžně používané staticky typované jazyky umožňují nějakým způsobem reflexi, takže není problém do nich dynamické typování "dodělat". Statické typování do dynamicky typovaných jazyků ale dodělat nelze.
Mám zkušenosti s oběma skupinami a největší rozdíl vidím v dokumentaci. Na co ve staticky typovaných jazycích stačí 3 řádky a odkaz na strukturu, je potřeba v dynamicky typovaných jazycích zpravidla 3x tolik informací. A ani potom nemám moc velkou jitotu, co tam skutečně může být.
Na co v dynamicky typovaných jazycích stačí jedna metoda, ve staticky typovaných potřebuješ třeba tři přetížené. Například pokud potřebuješ sort pro integer, float nebo string.
...Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Na co v dynamicky typovaných jazycích stačí jedna metoda, ve staticky typovaných potřebuješ třeba tři přetížené. Například pokud potřebuješ sort pro integer, float nebo string.
Ale ne. Dle principu sebeodpovědnosti objektu každý objekt definuje uspořádání (např. isLessThan:), metodě sort už pak stačí je obecně a polymorfně ověřovat pro jednotlivé páry, aniž by o nich musela cokoliv vědět.
...Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Šlo o pochopitelné zjednodušení. V statickém typování mám spousta kontrol (netvrdím, že všechno). V dynamickém žádné. Nehledě na to, že v mé otázce jsem to zohlednil. Ptal jsem se, co je výhoda dynamického typování. Když to technicky nejde, tak to technicky nejde, to dá rozum. Ale to není ta výhoda....Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Jo, o tom tu bylo hovadsky dlouhé vlákno ve fóru se závěrem, že kompletnost významové kontroly programu a jednoduchost takové kontroly jdou (logicky) proti sobě, takže jsou-li vaše typy jednoduché, většina kontrol vás teprve čeká.
No LOL. Staticke typy vznikly za ucelem vykonostni optimalizace, pro jednoduchou a rychlou praci s pameti..Taky si LOLnu. Samozřejmě, tak vznikli. Ale to je historie. Existuje taky věc, jako teorie typů.
Navzdory tomu spousta jejich priznivcu je presvedcena, ze jejich smysl je zajistit bezchybnost aplikace a z nich potom padaji obdobne nesmyslne hlasky, ze kdyz program proleze kompilatorem, tak je hotovo.Ano, a taky to tak je. Sice to asi nejde dotáhnout tak, aby to bylo doslova jak píšu, ale odvedou ohromné množství práce. V porovnání s dynamickými, které nedělají žádnou práci, ...
Dovolim si tvrzeni, ze staticke typy adoruji lini programatori, kteri nechteji delat testy a ziji v naivnim presvedceni, ze kompilator testuje aplikaci za ne.Měl jsem jednou přednášku na námět teorie typů. Vzhledem k tomu, jak na mě zmateně koukali mě už nepřekvapuje, že tu tolika lidem zcela ujel vlak.
Programy v dynamickych jazycich obecne nepadaji, to je domenou jazyku, ktere nemaji vyjimky. Nevzpominam si ze bych videl nekdy padnout python.Tak když to říkáš. Na takovou blbost se nebudu optěžovat argumentovat.
...V dynamickym prostredi to deserializuju do obyc nestovanyho dict objektu, nad kterym mam dostupnych tisic generickych funkci. Konverzi do vsech moznych formatu. Vse dostupne out of the box...
U statickych typu mas kontrolu prace s pameti, kterou u dynamickych jazyku nepotrebujes. Kompilator dynamickeho jazyka ti take odhali spoustu chyb a linter spoustu dalsich. Nic z toho neznamena, ze kdyz to tim proleze, ze uz mas prakticky hotovo. A mimochodem, me linter na chyby upozornuje uz behem psani.Šlo o pochopitelné zjednodušení. V statickém typování mám spousta kontrol (netvrdím, že všechno). V dynamickém žádné. Nehledě na to, že v mé otázce jsem to zohlednil. Ptal jsem se, co je výhoda dynamického typování. Když to technicky nejde, tak to technicky nejde, to dá rozum. Ale to není ta výhoda....Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Jo, o tom tu bylo hovadsky dlouhé vlákno ve fóru se závěrem, že kompletnost významové kontroly programu a jednoduchost takové kontroly jdou (logicky) proti sobě, takže jsou-li vaše typy jednoduché, většina kontrol vás teprve čeká.
Dokud ti staci jedno usporadani...Je v tom rozdíl, zda je ten stav uvnitř objektu (OOP), či vně (FP) ? Imho ten problém je stejný. Ani jeden to nedělá výrazně líp. (Pro mě je FP hlavně Haskell.)
Nic z toho neznamena, ze kdyz to tim proleze, ze uz mas prakticky hotovo.Šlo o pochopitelné zjednodušení.
U statickych typu mas kontrolu prace s pameti,Ano. No a? Ptal jsem se na to, v čem je dynamické typování tak výrazně výhodnější jak statické. V tom, že statické umí i optimalizovat výkon?
Kompilator dynamickeho jazyka ti take odhali spoustu chyb a linter spoustu dalsich. Nic z toho neznamena, ze kdyz to tim proleze, ze uz mas prakticky hotovo. A mimochodem, me linter na chyby upozornuje uz behem psani.Proto jsem tak přeháněl. Protože vám kompilátor dynamického jazyka objeví syntax error, a linter nevhodnou konstrukci, a už jste z toho unešeni jak OHROMNĚ vám to pomáhá. Panejo!
No LOL. Staticke typy vznikly za ucelem vykonostni optimalizace, pro jednoduchou a rychlou praci s pameti.. Navzdory tomu spousta jejich priznivcu je presvedcena, ze jejich smysl je zajistit bezchybnost aplikace a z nich potom padaji obdobne nesmyslne hlasky, ze kdyz program proleze kompilatorem, tak je hotovo.
Teorie typu existuje a ne jen jedna, treba i v psychologii a je to asi stejne relevantni.No LOL. Staticke typy vznikly za ucelem vykonostni optimalizace, pro jednoduchou a rychlou praci s pameti..Taky si LOLnu. Samozřejmě, tak vznikli. Ale to je historie. Existuje taky věc, jako teorie typů.Navzdory tomu spousta jejich priznivcu je presvedcena, ze jejich smysl je zajistit bezchybnost aplikace a z nich potom padaji obdobne nesmyslne hlasky, ze kdyz program proleze kompilatorem, tak je hotovo.Ano, a taky to tak je. Sice to asi nejde dotáhnout tak, aby to bylo doslova jak píšu, ale odvedou ohromné množství práce. V porovnání s dynamickými, které nedělají žádnou práci, ...Dovolim si tvrzeni, ze staticke typy adoruji lini programatori, kteri nechteji delat testy a ziji v naivnim presvedceni, ze kompilator testuje aplikaci za ne.Měl jsem jednou přednášku na námět teorie typů. Vzhledem k tomu, jak na mě zmateně koukali mě už nepřekvapuje, že tu tolika lidem zcela ujel vlak.Programy v dynamickych jazycich obecne nepadaji, to je domenou jazyku, ktere nemaji vyjimky. Nevzpominam si ze bych videl nekdy padnout python.Tak když to říkáš. Na takovou blbost se nebudu optěžovat argumentovat.
def get_record(self, data):
Funkcionální jazyky neznám, ale z toho, co jsem zatím viděl, řeší výpočet přesně opačně.- funkce popisují změny stavu
- bez stavu nemají smysl
- jsou neoddělitelné
Jediný rozdíl je, že ten stav je vně.
- Funkce přece nepopisují změny stavu, ale transformují vstupní data na výstupní. Objekty nemusí měnit svůj stav a mnohé jsou zcela immutable.
- Funkce mají smysl i bez stavu. Co třeba sinus nebo logaritmus? Kde mají ten stav? Výstup se neukládá tam, kde dříve byl vstup, ale posílá se dál.
- V OOP jsou instance navázány na metody. U funkcí se data volně přiřazují přes parametry dle potřeby
Netvrdím, že tu není podobnost, dokonce se v OOP dá mírně inspirovat z FP, ale těch rozdílů je docela dost. Ve FP je docela kladen důraz na typování, zatímco v OOP není podstatné.
... a nemusime type checkeru vysvetlovat nektere situace.Tak, že nepoužití typů je jednodužší pro autora jazyka, to je tak nějak jasné. Ale tady mi tvrdí, že to má výhody pro někoho, kdo ten jazyk bude používat.
Smysl statických typů je zajistit, aby se něco takového nestalo.Smyslem statickych typu je vykonostni optimalizace.
V JVM, co jsem se dočetl, hot reloading jde, ale nemůžeš měnit signatury ani odstraňovat nebo přidávat metody. Takže vlastně můžeš jenom měnit implementaci existujících věcí.
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Kód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Kód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.html
Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?Se zkvalitněním inference výhody trochu ubývají. Ale pár bys jich našel. Například když potřebuješ někde na zkoušku nějaký typ změnit, může ti probublat do spousty kódu, takže to musíš změnit i na spoustě mít, který vůbec spouštět nechceš. Je to podobný jako s IO v Haskellu - nemůžeš si někam jenom tak narychlo dát nějaký debug výpis...
No tak to z chybného předpokladu vyvozuješ chybný závěr, no, co na to říct jiného? REPL máš třeba v pythonu a code reloading tam dělat nejde (AFAIK). Existující kód prostě běží dál, změny se projeví jenom v nově nataženém.Uz je to davno co sem delal s pythonem. Ale melo by to jit.
Proč by ho měla mít? Když se dobře jmenuje, tak přesně víš, co dělá. Může ho mít, ale nevím, proč bych do něj měl dávat typ?Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.htmlKód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
A proč bych je tam přidával, když tu všichni píšou, že nejsou potřeba?
Jen mě to zajímá, fakt do toho nechci rýt. Dynamické typování zřejmě žádné výhody nemá a celé tohle vlákno to akorát potvrzuje. Takže bych rád věděl, jak to funguje a jak právě dynamičtí programátoři přemýšlí a jak fungují. Třeba bych tomu přišel na chuť taky. Pokud ale nevím, co posílat za typy, tak bohužel v tom dělat neumím.
Proč by ho měla mít? Když se dobře jmenuje, tak přesně víš, co dělá. Může ho mít, ale nevím, proč bych do něj měl dávat typ?Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.htmlKód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
A proč bych je tam přidával, když tu všichni píšou, že nejsou potřeba?
Jen mě to zajímá, fakt do toho nechci rýt. Dynamické typování zřejmě žádné výhody nemá a celé tohle vlákno to akorát potvrzuje. Takže bych rád věděl, jak to funguje a jak právě dynamičtí programátoři přemýšlí a jak fungují. Třeba bych tomu přišel na chuť taky. Pokud ale nevím, co posílat za typy, tak bohužel v tom dělat neumím.
Té metodě pošleš data a vrátí record. Jak prosté, typy ani signatury k tomu nejsou potřebné.
Celé toto vlákno je o tom, že statické typování nemá žádné výhody proti dynamickému - snad jen výkonnostní. Pokud opravdu potřebuji výkon, použiji Fortan, kde ty statické typy mám.
To, ze stare objekty (vytvorene podle predchozi verze kodu) zustanou nezmenene je snad v poradku ne?Ne. To je to, co ti porad nedochazi. Podstata je ve vymene stareho za nove ne ve vytvoreni noveho. To druhé Python umí (a umí to jakýkoliv jazyk s REPL), to první ne.
Kandidát na nejdebilnější hlášku desetiletí.Staticke typy zvysuji miru slozitosti programu, tedy jeho nachylnost k chybam.No LOL. Staticke typy vznikly za ucelem vykonostni optimalizace, pro jednoduchou a rychlou praci s pameti..Taky si LOLnu. Samozřejmě, tak vznikli. Ale to je historie. Existuje taky věc, jako teorie typů.Navzdory tomu spousta jejich priznivcu je presvedcena, ze jejich smysl je zajistit bezchybnost aplikace a z nich potom padaji obdobne nesmyslne hlasky, ze kdyz program proleze kompilatorem, tak je hotovo.Ano, a taky to tak je. Sice to asi nejde dotáhnout tak, aby to bylo doslova jak píšu, ale odvedou ohromné množství práce. V porovnání s dynamickými, které nedělají žádnou práci, ...Dovolim si tvrzeni, ze staticke typy adoruji lini programatori, kteri nechteji delat testy a ziji v naivnim presvedceni, ze kompilator testuje aplikaci za ne.Měl jsem jednou přednášku na námět teorie typů. Vzhledem k tomu, jak na mě zmateně koukali mě už nepřekvapuje, že tu tolika lidem zcela ujel vlak.Programy v dynamickych jazycich obecne nepadaji, to je domenou jazyku, ktere nemaji vyjimky. Nevzpominam si ze bych videl nekdy padnout python.Tak když to říkáš. Na takovou blbost se nebudu optěžovat argumentovat.
Celé toto vlákno je o tom, že statické typování nemá žádné výhody proti dynamickému - snad jen výkonnostní. Pokud opravdu potřebuji výkon, použiji Fortan, kde ty statické typy mám.Jenom vykonost. A bezpecnost. A moznost refaktorovat s podporou nastroju. A lepsi code completion. A snazsi TDD.
Zapouzdření nemusí být fyzické. Stačí, když programátor nepřistupuje z vnějšku k atributům instance, a to ani prostřednictvím getterů či setterů.
Python je multiparadigmatickým jazykem, neobjektové konstrukce sice působí divoce, ale jsou tam. Žádný jazyk není dokonalý. Třídní (statické?) metody nepoužívám, takže příslušné anotace ani nemusím řešit.
Jako stary pythonista bys mel vedet, ze python konstanty nema. Kdyz mas dve sady cisel a nechces aby doslo k jejich zamene, staci si je otypovat. To slo delat vzdy a enum v pythonu nedela nic jineho, je to jen preddefinovana trida za timto ucelem. Staticke typy k tomu nepotrebujes a testy ti to odhali, kdyz budou dobre, take muzes pouzit typing.No LOL. Staticke typy vznikly za ucelem vykonostni optimalizace, pro jednoduchou a rychlou praci s pameti.. Navzdory tomu spousta jejich priznivcu je presvedcena, ze jejich smysl je zajistit bezchybnost aplikace a z nich potom padaji obdobne nesmyslne hlasky, ze kdyz program proleze kompilatorem, tak je hotovo.
Jako starý Pythonista musím nesouhlasit. Stačí blbá číselná konstanta (v Pythonu už je naštěstí enum), máš dvě sady číselných konstant, někdo se sekne, napíše něco podobného (našeptávání ve Vimu nebo v IDE) a chyba je na světě. To jsem bohužel viděl v praxi. A jelikož těch konstant můžeš mít desítky a jelikož to špatné číslo může nasekat paseku, která na první pohled není hned vidět, testy to pravděpodobně nevyřeší. Nehledě k tomu, že testy zcela obecně nezaručují korektnost aplikace ve všech situacích. Tady by explicitní typ a la Haskell vyřešil úplně všechno.
Dále ta Tvoje naprosto nekonstruktivní poznámka o účelu statických jazyků - jasně, u trošku inteligentnějších asemblerů (C a spol.) to není nic jiného, než přiblížení železu, jenže u moderních, dobře psaných jazyků typy pomáhají přesnému vyjadřování a kontrole korektnosti. To vidí každý, kdo zažil v akci *ML, Haskell, Rust atd. a nemá klapky na očích. Jazyky typu C mají navíc to typování úplně špatně (přetypování ukazatelů, hloupá sémantika boolovských operací). A Python, bohužel, z Céčka pár těch nesmyslů přebral (sémantika boolovských operací, před verzí 3 bylo dokonce možno porovnávat číslo a None, to byl teda nápad!)
Takže otázka nezní, co bylo původním záměrem statických jazyků, ale co přinášejí navíc a v čem samozřejmě mohou mít nevýhody. Zbytek Tvého příspěvku necituju, ale vzhledem k tomu, že explicitně zmiňuješ C, doporučuju trochu pokory a samostudia.
- Bezpečnost? To je jen iluze, která není ničím podložena.
- Možnost refaktorovat je stejná. Nevidím výhodu statického typování.
- Lepší code completion je jen dáno konkrétním použitým IDE. Ve Vimu je to jedno, tam vítězí dynamické typování.
Dynamicky typovaný jazyk se lépe čte, vlastně ke čtení ty typy ani nepotřebuji. Hodí se do hlavičky metod a funkcí - tam je dávám, protože programuji proti rozhraní, které je vyžaduje.
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Kód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Kód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
To je prece popsane v dokumentaci k te funkci. Samotna znalost typu te k pochopeni funkce a jak ji pouzivat nepriblizuje nijak vic. I kdybys vedel, ze int je cislo, porad bez dokumentace nevis jake cislo a co znamena. Ano, dynamicke jazyky se pouzivaji na vic veci, nez hrani se skriptiky.
Jako stary pythonista bys mel vedet, ze python konstanty nema. Kdyz mas dve sady cisel a nechces aby doslo k jejich zamene, staci si je otypovat. To slo delat vzdy a enum v pythonu nedela nic jineho, je to jen preddefinovana trida za timto ucelem. Staticke typy k tomu nepotrebujes a testy ti to odhali, kdyz budou dobre, take muzes pouzit typing.
Delas tu chybu, ze si pletes obecne typy a staticke typy. Typy aby plnily svou kontrolni funkci nemusi byt staticke a ani to neni zadouci, je to omezujici a dela to program slozitejsi, rozumej nachylnejsi k chybam. Jedine plus pro staticke typy je vyssi vykon, zaplaceny vyssi slozitosti. Jazyky typu C maji slabe typovani, tvrditvze to je spatne je velmi odvazne, ale je to hezky doklad toho, ze _staticke_ typovani ma jiny ucel. Doslo by ti to rychleji, kdyby ses nasnazil mavnout rukou nad tim, proc vubec staticke typy vznikly, tento duvod nepominul. Pak bys jim neprisuzoval ucel, ktery nemaji.
To beru.... a nemusime type checkeru vysvetlovat nektere situace.Tak, že nepoužití typů je jednodužší pro autora jazyka, to je tak nějak jasné. Ale tady mi tvrdí, že to má výhody pro někoho, kdo ten jazyk bude používat.
V tom co jsem psal jsem mel na mysli programatora. Napriklad nemusim type checkeru v Haskellu vysvetlovat, ze zadany retezcovy literal ma byt typu Text a nikoli typu String. (A o existenci OverloadedStrings vim, jde o obecny problem.)
Ale jo, to už tu bylo. Dokonce jsem to uváděl jako jeden ze scénářů, kdy je dynamické typování lepší HNED V OTÁZCE.Ale ať nad tím dumám jak dumám, tak mi vychází, že dynamické typování je znouzecnost. Nemá žádné benefity. Pletu se?Se zkvalitněním inference výhody trochu ubývají. Ale pár bys jich našel. Například když potřebuješ někde na zkoušku nějaký typ změnit, může ti probublat do spousty kódu, takže to musíš změnit i na spoustě mít, který vůbec spouštět nechceš. Je to podobný jako s IO v Haskellu - nemůžeš si někam jenom tak narychlo dát nějaký debug výpis...
Nebo jinak: Kotím javový kód. Mám 5 věcí rozdělaných (např. v TDD standard), ale dokud to nebudu mít alespoň formálně (tedy i typově, což samo o sobě nestačí) správně, tak to nepřeložím. Takže to nějak ojebu (doplním kraviny, pozakomentuju - krásný příklad na situaci, kdy kód funguje špatně, ale překladem prošel, takže jej někteří považují za správný!), abych mohl vyzkoušet TU JEDNU VĚC, co jsem potřeboval.
V pythonu se z dokumentacnich retezcu mj. generuje dokumentace. Tva otazka tedy je, proc by mel byt program zdokumentovany. Tato dokumentace je primou soucasti programu/knihovny.Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Kód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.html
Proč by ho měla mít? Když se dobře jmenuje, tak přesně víš, co dělá. Může ho mít, ale nevím, proč bych do něj měl dávat typ?
A proč bych je tam přidával, když tu všichni píšou, že nejsou potřeba?
Jen mě to zajímá, fakt do toho nechci rýt. Dynamické typování zřejmě žádné výhody nemá a celé tohle vlákno to akorát potvrzuje. Takže bych rád věděl, jak to funguje a jak právě dynamičtí programátoři přemýšlí a jak fungují. Třeba bych tomu přišel na chuť taky. Pokud ale nevím, co posílat za typy, tak bohužel v tom dělat neumím.
Je to marný, s Tebou se nedomluvím. Od zítřka kamarádím s Kitem.Si pomůžeš? :-P
jako obvykle si každý představuje pod pojmem "typ" něco trochu (nebo i hodně) jiného
tenhle to hezky shrnul: http://tomasp.net/blog/2015/against-types/
Je to marný, s Tebou se nedomluvím. Od zítřka kamarádím s Kitem.Si pomůžeš? :-P
neobvyklé to třeba není, ale tady půlka lidí debatuje o pascalu a druhá o teorii typů a to mi přijde takové nahovnojako obvykle si každý představuje pod pojmem "typ" něco trochu (nebo i hodně) jiného
tenhle to hezky shrnul: http://tomasp.net/blog/2015/against-types/
To ovsem neni nic tak neobvykleho, ze pojem "typ" ma v programovani jiny vyznam nez v matematice. Treba pojem "funkce" ma v programovani take jiny vyznam.
Funkcionalni programovani se prave obecne snazi obe discipliny priblizit a tedy tam se snazi oba pojmy pouzivat primarne v matematickem vyznamu (coz je uzsi a formalnejsi). Ale obecne v programovani to ten vyznam, bohuzel historicky, nema.
Dynamicke typovani vyhodu ma, je jednodussi, flexíbilnejsi a srozumitelnejsi. Staticke typovani je vlastne docela hloupe a neprirozene, je umele. Principialni rozdil mezi statickym a dynamickym typovanim je v tom, kdo nese informaci o typu, zda promenna nebo hodnota.
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Kód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.html
Proč by ho měla mít? Když se dobře jmenuje, tak přesně víš, co dělá. Může ho mít, ale nevím, proč bych do něj měl dávat typ?
A proč bych je tam přidával, když tu všichni píšou, že nejsou potřeba?
Jen mě to zajímá, fakt do toho nechci rýt. Dynamické typování zřejmě žádné výhody nemá a celé tohle vlákno to akorát potvrzuje. Takže bych rád věděl, jak to funguje a jak právě dynamičtí programátoři přemýšlí a jak fungují. Třeba bych tomu přišel na chuť taky. Pokud ale nevím, co posílat za typy, tak bohužel v tom dělat neumím.
V prvni rade to vim z dokumentace, v druhe rade k tomu opravdu nepotrebuji staticke typy.Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Kód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
To je prece popsane v dokumentaci k te funkci. Samotna znalost typu te k pochopeni funkce a jak ji pouzivat nepriblizuje nijak vic. I kdybys vedel, ze int je cislo, porad bez dokumentace nevis jake cislo a co znamena. Ano, dynamicke jazyky se pouzivaji na vic veci, nez hrani se skriptiky.
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
neobvyklé to třeba není, ale tady půlka lidí debatuje o pascalu a druhá o teorii typů a to mi přijde takové nahovnoPravdu máš soudruhu. A přitom ta moje otázka vypadala celkem jednoduše.
V prvni rade to vim z dokumentace, v druhe rade k tomu opravdu nepotrebuji staticke typy.Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Kód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
To je prece popsane v dokumentaci k te funkci. Samotna znalost typu te k pochopeni funkce a jak ji pouzivat nepriblizuje nijak vic. I kdybys vedel, ze int je cislo, porad bez dokumentace nevis jake cislo a co znamena. Ano, dynamicke jazyky se pouzivaji na vic veci, nez hrani se skriptiky.
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
Kód: [Vybrat]type Person = Person String String Int
getName (Person x _ _) = x
getSurname (Person _ x _) = x
getAge (Person _ _ x) = x
getFullname p = getName p .. " " .. getSurname p .. " (" .. getAge p .. ")"
parsePerson :: String -> Person
parsePerson s = ......
Jediný rozdíl je, že ten stav je vně.
Jo, dokumentaci by mel mit kazdy jazyk, byt ne u kazdeho je soucasti jazyka. Kazdopadne by se dokumentace nemela nahrazovat statickymi typy.Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Kód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
Tak za prvé by měla mít metoda dokumentační komentář a za druhé se dají přidat typy do signatury. https://docs.python.org/3/library/typing.html
Proč by ho měla mít? Když se dobře jmenuje, tak přesně víš, co dělá. Může ho mít, ale nevím, proč bych do něj měl dávat typ?
A proč bych je tam přidával, když tu všichni píšou, že nejsou potřeba?
Jen mě to zajímá, fakt do toho nechci rýt. Dynamické typování zřejmě žádné výhody nemá a celé tohle vlákno to akorát potvrzuje. Takže bych rád věděl, jak to funguje a jak právě dynamičtí programátoři přemýšlí a jak fungují. Třeba bych tomu přišel na chuť taky. Pokud ale nevím, co posílat za typy, tak bohužel v tom dělat neumím.
a) Dokumentaci by měla mít, aby se zní dala generovat dokumentace, to se snad dělá i v jiných jazycích ne? Jinak v Pythonu se tam slušně strká i "typ". To už před tím než se zavedli type-hints.
b) Vytváříš falešnou představu že když někdo dělá v třeba v Pythonu je to milovník dynamického typování :), to ani ne, ale kolem toho co mě baví je Python komunita, takže asi tak.
c) Ideální jazyk pro mne by byl něco jako OCaml, ale bohužel už jsou zavedený knihovny Pandas, Numpy, Scipy -- tohle se těžko nahrazuje.
Samozřejmě na Pythonu je blbý, že jako začátěčník ti dovolí všechno, blbě se refaktoruje atd.
Nebo ty funkce jsou vně? Jak potom dosáhnete konzistenci (u složitějších modelů, ne tohoto triviálního případu), když si každý kdekoliv může vyrobit funkci, která přepíše v "stavu" cokoliv zvenku?Ve FP nemůžeš přepsat stav. A v Haskellu nemůže kdokoliv vyrobit funkci - hlídaj to typy a moduly. Ale to už je jinej příběh.
P. S.: Opravdu se jednotlivé položky struktury odkazují tak neobratně a nepřehledně pozicí?!Tak, na struktury jsou spíše zkratky, já to z demostrativních důvodů rozepsal. Ale jinak ano, a je to velice šikovné a dobře se na to zvyká.
To je cira z nouze ctnost.Nepotrebujes, pomahaji. A to i pokud se bavime o ridke situaci, kdy dokumentace je 100%.V prvni rade to vim z dokumentace, v druhe rade k tomu opravdu nepotrebuji staticke typy.Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:To je prece popsane v dokumentaci k te funkci. Samotna znalost typu te k pochopeni funkce a jak ji pouzivat nepriblizuje nijak vic. I kdybys vedel, ze int je cislo, porad bez dokumentace nevis jake cislo a co znamena. Ano, dynamicke jazyky se pouzivaji na vic veci, nez hrani se skriptiky.Kód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
Dynamicke typovani vyhodu ma, je jednodussi, flexíbilnejsi a srozumitelnejsi. Staticke typovani je vlastne docela hloupe a neprirozene, je umele. Principialni rozdil mezi statickym a dynamickym typovanim je v tom, kdo nese informaci o typu, zda promenna nebo hodnota.
To neni tak docela pravda. Napriklad Haskell nema promenne, jen hodnoty; pritom je staticky typovany. Na druhou stranu, treba Java ma promenne, ale nektere hodnoty (objekty) si drzi informaci o svem typu.
Rozdil je skutecne v tom, zda se typy kontroluji pri prekladu nebo az pri behu programu. A to druhe obvykle znamena nejakou ztratu vykonu a vyssi spotrebu pameti.
dabl x = x + x
Co je to to 'x' a je datoveho typu double nebo int? Dynamicke typovani vyhodu ma, je jednodussi, flexíbilnejsi a srozumitelnejsi. Staticke typovani je vlastne docela hloupe a neprirozene, je umele. Principialni rozdil mezi statickym a dynamickym typovanim je v tom, kdo nese informaci o typu, zda promenna nebo hodnota.
To neni tak docela pravda. Napriklad Haskell nema promenne, jen hodnoty; pritom je staticky typovany. Na druhou stranu, treba Java ma promenne, ale nektere hodnoty (objekty) si drzi informaci o svem typu.
Rozdil je skutecne v tom, zda se typy kontroluji pri prekladu nebo az pri behu programu. A to druhe obvykle znamena nejakou ztratu vykonu a vyssi spotrebu pameti.
takze kdyz v haskellu napisuKód: [Vybrat]dabl x = x + x
Co je to to 'x' a je datoveho typu double nebo int?
Je otazka, zda objekt je opravdu hodnota, ale dobre, opravuji formulaci na 'kde i informace o jednoduchem datovem typu je soucasti hodnoty.
Takze kdyz v pythonu, php a pod vyuziji type hinting, a datove typy zkontroluji pri prekladu, udelal jsem z nej staticky typovany jazyk? Myslim ze ne a to prave proto, ze informace o typu je soucasti hodnoty, nikoliv promenne. To je podle me zakladni rozdil, nikoliv cas kontroly.
Muj priklad vypadal jinak. Je to priklad ze statickeho jazyka a krasne to ukazuje, ze vase tzv. vyhody statickych jazyku jsou iluzorni. Vy statickym typum prisuzujete vlastnosti, ktere neplynou ze statickeho typovani. Staticke typovani ma jedinou vyhodu a smysl, umoznuje vyrazne lepsi vykonovou optimalizaci. To vsechno ostatni jsou vedlejsi efekty, ktere nejsou platne pro vsechny staticke jazyky a nejsou podmineny existenci statickeho typovani.Dynamicke typovani vyhodu ma, je jednodussi, flexíbilnejsi a srozumitelnejsi. Staticke typovani je vlastne docela hloupe a neprirozene, je umele. Principialni rozdil mezi statickym a dynamickym typovanim je v tom, kdo nese informaci o typu, zda promenna nebo hodnota.
To neni tak docela pravda. Napriklad Haskell nema promenne, jen hodnoty; pritom je staticky typovany. Na druhou stranu, treba Java ma promenne, ale nektere hodnoty (objekty) si drzi informaci o svem typu.
Rozdil je skutecne v tom, zda se typy kontroluji pri prekladu nebo az pri behu programu. A to druhe obvykle znamena nejakou ztratu vykonu a vyssi spotrebu pameti.
takze kdyz v haskellu napisuKód: [Vybrat]dabl x = x + x
Co je to to 'x' a je datoveho typu double nebo int?
Je otazka, zda objekt je opravdu hodnota, ale dobre, opravuji formulaci na 'kde i informace o jednoduchem datovem typu je soucasti hodnoty.
Takze kdyz v pythonu, php a pod vyuziji type hinting, a datove typy zkontroluji pri prekladu, udelal jsem z nej staticky typovany jazyk? Myslim ze ne a to prave proto, ze informace o typu je soucasti hodnoty, nikoliv promenne. To je podle me zakladni rozdil, nikoliv cas kontroly.
dabl :: Num a => a -> a
(jinymi slovy x je cislo)
(a jeste update: dabl je polymorfni, ale nezamenovat to uplne s polymorfismem pozdni vazby v beznem OOP)
Muj priklad vypadal jinak. Je to priklad ze statickeho jazyka a krasne to ukazuje, ze vase tzv. vyhody statickych jazyku jsou iluzorni. Vy statickym typum prisuzujete vlastnosti, ktere neplynou ze statickeho typovani. Staticke typovani ma jedinou vyhodu a smysl, umoznuje vyrazne lepsi vykonovou optimalizaci. To vsechno ostatni jsou vedlejsi efekty, ktere nejsou platne pro vsechny staticke jazyky a nejsou podmineny existenci statickeho typovani.Dynamicke typovani vyhodu ma, je jednodussi, flexíbilnejsi a srozumitelnejsi. Staticke typovani je vlastne docela hloupe a neprirozene, je umele. Principialni rozdil mezi statickym a dynamickym typovanim je v tom, kdo nese informaci o typu, zda promenna nebo hodnota.
To neni tak docela pravda. Napriklad Haskell nema promenne, jen hodnoty; pritom je staticky typovany. Na druhou stranu, treba Java ma promenne, ale nektere hodnoty (objekty) si drzi informaci o svem typu.
Rozdil je skutecne v tom, zda se typy kontroluji pri prekladu nebo az pri behu programu. A to druhe obvykle znamena nejakou ztratu vykonu a vyssi spotrebu pameti.
takze kdyz v haskellu napisuKód: [Vybrat]dabl x = x + x
Co je to to 'x' a je datoveho typu double nebo int?
Je otazka, zda objekt je opravdu hodnota, ale dobre, opravuji formulaci na 'kde i informace o jednoduchem datovem typu je soucasti hodnoty.
Takze kdyz v pythonu, php a pod vyuziji type hinting, a datove typy zkontroluji pri prekladu, udelal jsem z nej staticky typovany jazyk? Myslim ze ne a to prave proto, ze informace o typu je soucasti hodnoty, nikoliv promenne. To je podle me zakladni rozdil, nikoliv cas kontroly.
dabl :: Num a => a -> a
(jinymi slovy x je cislo)
(a jeste update: dabl je polymorfni, ale nezamenovat to uplne s polymorfismem pozdni vazby v beznem OOP)
dabl x = x + x
ne?Je otazka, zda objekt je opravdu hodnota, ale dobre, opravuji formulaci na 'kde i informace o jednoduchem datovem typu je soucasti hodnoty.Rozdělení na hodnotové nehodnotové typy je IMHO taková bolest mutabilních jazyků. V haskellu je všechno hodnota: číslo, text, pole, funkce, ... Většina věcí tam je first-class. Takže když prohlásíme, že sturktura je objekt, tak ano, i v takovém případě by to byla hodnota.
Takze kdyz v pythonu, php a pod vyuziji type hinting, a datove typy zkontroluji pri prekladu, udelal jsem z nej staticky typovany jazyk?Skoro. Určitě to pomůže odchytit velkou fůru potenciálních chyb. Ale type-hinting bude furt slabej proti plnohodnotnému statickému systému.
class ContactForm:
def __init__(self):
self.name = none
self.age = none
def assetContactForm(ContactForm form, string name, int age):
form.name = name
form.birth = age
return form
Takze kdyz v pythonu, php a pod vyuziji type hinting, a datove typy zkontroluji pri prekladu, udelal jsem z nej staticky typovany jazyk? Myslim ze ne a to prave proto, ze informace o typu je soucasti hodnoty, nikoliv promenne. To je podle me zakladni rozdil, nikoliv cas kontroly.V Haskellu (a myslím, že to tak platí u většiny modernějších jazyků) je typ součást hodnoty:
sum :: Int -> Int -> Int
sum a b = a + b
inc a = a + 1
dump (sum (inc 4) (inc 5.5))
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).
K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
List nemá stejné metody jako set, natož jako text.Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
List nemá stejné metody jako set, natož jako text.Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
Dobrá, zde tedy polymorfismus selhává. K čemu tedy potřebuji takovou kolekci vytahovat z objektu? Nebylo by lepší ji iterovat uvnitř nebo místo kolekce předat iterovatelný objekt?
On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
Sémantický rozdíl nevidím. Seznam autorů nebo množina autorů? Pro mne je to kolekce autorů a budu s ní pracovat tak, aby když někdo vymění list za set, mi to mohlo být jedno.
~ $ cat hint_test.py
class ContactForm:
def __init__(self):
self.name = none
self.age = none
def assetContactForm(ContactForm form, string name, int age):
form.name = name
form.birth = age
return form
~ $
~ $ python hint_test.py
File "hint_test.py", line 6
def assetContactForm(ContactForm form, string name, int age):
^
SyntaxError: invalid syntax
~ $
~ $ pylint hint_test.py
Using config file /data/data/com.termux/files/home/.pylintrc
************* Module hint_test
E: 6, 0: invalid syntax (<string>, line 6) (syntax-error)
~ $
On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
Sémantický rozdíl nevidím. Seznam autorů nebo množina autorů? Pro mne je to kolekce autorů a budu s ní pracovat tak, aby když někdo vymění list za set, mi to mohlo být jedno.
hele kite - zeptam se te jenom jednou ... jestli pak vis co je to anglicky "pasy"?
Kód: [Vybrat]~ $ cat hint_test.py
class ContactForm:
def __init__(self):
self.name = none
self.age = none
def assetContactForm(ContactForm form, string name, int age):
form.name = name
form.birth = age
return form
~ $
~ $ python hint_test.py
File "hint_test.py", line 6
def assetContactForm(ContactForm form, string name, int age):
^
SyntaxError: invalid syntax
~ $
~ $ pylint hint_test.py
Using config file /data/data/com.termux/files/home/.pylintrc
************* Module hint_test
E: 6, 0: invalid syntax (<string>, line 6) (syntax-error)
~ $
Jak vidis, tak tuhle blbost ti python odchytne. Tvrzeni ze typing z pythonu udela staticky typovany jazyk je dalsi nesmysl. Az se prokouses moznostmi a schopnostmi typingu, probereme si moznosti cythonu.
Jako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Jako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
4. genericke programovaniJako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
8. interaktivitato není výsada dynamických jazyků, viz např https://www.youtube.com/watch?v=mOtKD7ml0NU
Jediné co se mi vybavilo jsou IO monády v Haskellu. Jinak mě nenapadá, kdy by měl být typový systém příliš přísný. A i u těch IO monádách je to vlastně lepší, než bez toho.Jako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
4. pripady, kdy staticky typovy system je prilis prisny a nepovoli preklad programu, ktery by dynamicky jazyk v pohode zvladnul a navic je takovy program lidsky intuitivni
4. genericke programovaniJako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita
To je tvrzeni do pranice. Je jazyk staticky, pokud struktury oznacovane za staticke vytvari dynamicky? Muzu v takovem interpretu definovat funkci, ktera bude pracovat s datovym typem, ktery zatim jeste neni definovan?8. interaktivitato není výsada dynamických jazyků, viz např https://www.youtube.com/watch?v=mOtKD7ml0NU
Jako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.4. genericke programovaniJako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita
Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?
Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.4. genericke programovaniJako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita
Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?
Takže zpátky k výhodám Pythonu - čitelnost, dobrá komunita, batteries included, v jazyku se cítím docela přirozeně. Pro prototypy je celkem super a i větší věci se v něm dají dělat, ne že ne. Dobré je, že můžeš mít kolekce s různorodými prvky, prostě se s tím hezky pracuje a zároveň se vždycky můžeš vyptat, co je ten prvek zač a podle toho s ním naložit. Prostě hezká hračka, lego, které se dá použít i na praktické věci. Mám ty výhody zobecňovat? Perl nesnáším, Ruby nemusím, Smalltalk je úplně jiný svět, PHP beru jako praktický nástroj, ale jinak mi taky nejde moc od ruky.Podepisuju se.
Co se mi líbí:
1. Neukecaná syntaxe - to ale řeší i typová inference apod.
2. Vysokoúrovňové idiomy a datové struktury - to je ale obecný trend a není to statická ani dynamická věc
3. Automatická správa paměti (ať už jde o RC, GC nebo paměťový model a la Rust)
4. Kvalitní knihovny
5. Dobré nástroje pro organizaci kódu - moduly, balíčky apod.
Python mnohé z toho splňuje, jiné jazyky taky. Dynamické typování nepovažuju za takovou výhodu. Python to dělá takhle a docela mu to jde. Jiné jazyky to umí jinak. Kdybych si mohl svobodně zvolit jazyk, šel bych spíš cestou Rustu/Scaly/Haskellu/F#. Python mě živí, umím ho nejlíp a často je to pragmaticky správná volba. Ale z dynamických vlastností nedělám fetiš, na těch to nestojí. Spousta věcí se díky nim dá spíchnout skoro "zadarmo", jenže má to samozřejmě dlouhodobé náklady. Důležitý je proces a produkt. A svět programovacích jazyků se vyvíjí k lepšímu - i Python.
S tou Javou a C# jsi si jist? ;-)Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.
U me je to podobne, Python+C(ython) je prvni vychozi volba. Otazka nezni proc Python jo, ale proc Python ne. Takze Python ne, kdyz potrebuji skriptovat webove stranky, tam je nutny JS, Python ne, kdyz jde o produkt na verejny hosting, tam je to PHP, Python ne, kdyz jde o produkt, ktery ma byt integrovan do stavajici podnikove infrastruktury nebo se jedna o jeji modifikaci, tam je to casto Java nebo C#. Ale ve vetsine pripadu Python vyhovi. Je paradni treba na automation, kde se driv pouzivalo vba, je paradni na webove aplikace, ktere jedou na vlastnim serveru a dneska uz je skoro vsechno webova aplikace, o tradicni desktopove prestal byt zajem. Drive byl duvod k odmitnuti Pythonu pozadavek na vysoky vykon, Cython to ale zmenil a dnes se pozadavky na vykon neni potreba zabyvat.Jako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
No já Ti raději povím svoji historii; když nepočítám Basic a Pascal a úkroky stranou typu FoxPro, vyšel jsem programátorsky z C a C++. V C byla perfektní široká škála funkcí, které oproti Pascalu umělo (práce s řetězci atd.) Jenže celou dobu mě trápilo dřevácké strukturování programů, explicitní alokace atd. C++ bylo podstatně hezčí, v té době ještě takové to staré s klasickými pointery atd., ale už to umělo aspoň reference a spousta věcí tam byla příčetnější než v C. Pak jsem koketoval s Javou - v době šílených nestabilních IDE typu Xelfi a microsoftí snahy ukrást celou platformu pomocí J++. Šílené obstrukce okolo načtení kousku souboru, to API bylo neskutečně hnusné.
V Linuxu byly dva jazyky, které mě zaujaly - Perl, který mi vždycky přišel trhlý a Python, který měl jenom "trhlou" syntaxi. Měl ale vizi, programy v něm psané byly celkem elegantní a čitelné a člověk se nemusel mazat s nějakým hloupým mallocem a callocem atd. Nějaká ideologie kolem mě trochu oslovila, ale to bylo spíš mladické poblouznění.
Takže zpátky k výhodám Pythonu - čitelnost, dobrá komunita, batteries included, v jazyku se cítím docela přirozeně. Pro prototypy je celkem super a i větší věci se v něm dají dělat, ne že ne. Dobré je, že můžeš mít kolekce s různorodými prvky, prostě se s tím hezky pracuje a zároveň se vždycky můžeš vyptat, co je ten prvek zač a podle toho s ním naložit. Prostě hezká hračka, lego, které se dá použít i na praktické věci. Mám ty výhody zobecňovat? Perl nesnáším, Ruby nemusím, Smalltalk je úplně jiný svět, PHP beru jako praktický nástroj, ale jinak mi taky nejde moc od ruky.
Co se mi líbí:
1. Neukecaná syntaxe - to ale řeší i typová inference apod.
2. Vysokoúrovňové idiomy a datové struktury - to je ale obecný trend a není to statická ani dynamická věc
3. Automatická správa paměti (ať už jde o RC, GC nebo paměťový model a la Rust)
4. Kvalitní knihovny
5. Dobré nástroje pro organizaci kódu - moduly, balíčky apod.
Python mnohé z toho splňuje, jiné jazyky taky. Dynamické typování nepovažuju za takovou výhodu. Python to dělá takhle a docela mu to jde. Jiné jazyky to umí jinak. Kdybych si mohl svobodně zvolit jazyk, šel bych spíš cestou Rustu/Scaly/Haskellu/F#. Python mě živí, umím ho nejlíp a často je to pragmaticky správná volba. Ale z dynamických vlastností nedělám fetiš, na těch to nestojí. Spousta věcí se díky nim dá spíchnout skoro "zadarmo", jenže má to samozřejmě dlouhodobé náklady. Důležitý je proces a produkt. A svět programovacích jazyků se vyvíjí k lepšímu - i Python.
To bych nerekl. Zabyvam se tim pragmaticky. I kdyby haskell nebyl tak tezkopadny, jako v praxi pouzivane staticke jazyky, tak je to bezvyznamna zajimavost, protoze v praxi je to nepouzitelny jazyk. Zajimaji me a posuzuji vlastnosti praktickych jazyku.Aha. Takže houby víš, ale názor se ti už udělal.Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?4. genericke programovaniJako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita
To bych nerekl. Zabyvam se tim pragmaticky. I kdyby haskell nebyl tak tezkopadny, jako v praxi pouzivane staticke jazyky, tak je to bezvyznamna zajimavost, protoze v praxi je to nepouzitelny jazyk. Zajimaji me a posuzuji vlastnosti praktickych jazyku.Aha. Takže houby víš, ale názor se ti už udělal.Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?4. genericke programovaniJako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita
Že i na takovou obludu jako je javascript se roubujou typy (Flow, google-closure, TypeScript), protože bez nich žádnou větší aplikaci prostě neudržíš.To bych nerekl. Zabyvam se tim pragmaticky. I kdyby haskell nebyl tak tezkopadny, jako v praxi pouzivane staticke jazyky, tak je to bezvyznamna zajimavost, protoze v praxi je to nepouzitelny jazyk. Zajimaji me a posuzuji vlastnosti praktickych jazyku.Aha. Takže houby víš, ale názor se ti už udělal.Nevim co povazujes za moderni. Znam ty, ktere se se pouzivaji a je potreba je znat. C, C#, Java. Na akademicke jako je Haskell neplytvam casem.Hele viděl jsi někdy nějaký moderní statický typovaný jazyk?4. genericke programovaniJako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
5. flexibilita
6. jednodussi (prehlednejsi) kod
7. introspekce
8. interaktivita
A že půlka těch věcí neplatí ani u Javy třebas o F# nebo Scale nemluvě...
první otázce nerozumím, na druhou je odpověď kladná (typeclasses, parametricity a tak)To je tvrzeni do pranice. Je jazyk staticky, pokud struktury oznacovane za staticke vytvari dynamicky? Muzu v takovem interpretu definovat funkci, ktera bude pracovat s datovym typem, ktery zatim jeste neni definovan?8. interaktivitato není výsada dynamických jazyků, viz např https://www.youtube.com/watch?v=mOtKD7ml0NU
Python mnohé z toho splňuje, jiné jazyky taky. Dynamické typování nepovažuju za takovou výhodu. Python to dělá takhle a docela mu to jde. Jiné jazyky to umí jinak. Kdybych si mohl svobodně zvolit jazyk, šel bych spíš cestou Rustu/Scaly/Haskellu/F#. Python mě živí, umím ho nejlíp a často je to pragmaticky správná volba. Ale z dynamických vlastností nedělám fetiš, na těch to nestojí. Spousta věcí se díky nim dá spíchnout skoro "zadarmo", jenže má to samozřejmě dlouhodobé náklady. Důležitý je proces a produkt. A svět programovacích jazyků se vyvíjí k lepšímu - i Python.Podepisuju se.
Ja to vidim podobne jako Inkvizitor - taky jsem Python zacal pouzival okolo roku 2001, a v te dobe to bylo prijemne jednodussi nez vsechno ostatni okolo. Pozdeji jsem si oblibil Common Lisp a Haskell, ale Python mi porad jde nejlepe.Takže když si to shrnu, dynamické typování nemá žádné principielní výhody. Jen je to zkrátka a dobře jednodužší na implementaci a naučení. Můžeme se bavit o tom, že je tu jakýsi historický balast, který si vývojáři nesou (například představa ukecanosti, představa pouze základních typů, nepochopení důsledků typové kontroly, etc) vytvářející mýtus výhod, ale jinak asi nic výraznějšího tam nebude. Souhlas?
Ale zacinat znovu, tak rovnou u Haskellu... jak uz jsem ti psal, s dobrou typovou inferenci se vyhoda dynamickeho typovani znacne snizuje. Takze pocitam, ze soucasny trend je (velmi pomaly) postupny navrat ke statickemu typovani diky rozsireni typove inference.
...Takze pocitam, ze soucasny trend je (velmi pomaly) postupny navrat ke statickemu typovani diky rozsireni typove inference.A když to už někdo opravdu potřebuje dynamicky, tak třeba c# mu vychází vstříc datový typem dynamic (třeba jako parametry metod).
+1Ja to vidim podobne jako Inkvizitor - taky jsem Python zacal pouzival okolo roku 2001, a v te dobe to bylo prijemne jednodussi nez vsechno ostatni okolo. Pozdeji jsem si oblibil Common Lisp a Haskell, ale Python mi porad jde nejlepe.Takže když si to shrnu, dynamické typování nemá žádné principielní výhody. Jen je to zkrátka a dobře jednodužší na implementaci a naučení. Můžeme se bavit o tom, že je tu jakýsi historický balast, který si vývojáři nesou (například představa ukecanosti, představa pouze základních typů, nepochopení důsledků typové kontroly, etc) vytvářející mýtus výhod, ale jinak asi nic výraznějšího tam nebude. Souhlas?
Ale zacinat znovu, tak rovnou u Haskellu... jak uz jsem ti psal, s dobrou typovou inferenci se vyhoda dynamickeho typovani znacne snizuje. Takze pocitam, ze soucasny trend je (velmi pomaly) postupny navrat ke statickemu typovani diky rozsireni typove inference.
+1Ja to vidim podobne jako Inkvizitor - taky jsem Python zacal pouzival okolo roku 2001, a v te dobe to bylo prijemne jednodussi nez vsechno ostatni okolo. Pozdeji jsem si oblibil Common Lisp a Haskell, ale Python mi porad jde nejlepe.Takže když si to shrnu, dynamické typování nemá žádné principielní výhody. Jen je to zkrátka a dobře jednodužší na implementaci a naučení. Můžeme se bavit o tom, že je tu jakýsi historický balast, který si vývojáři nesou (například představa ukecanosti, představa pouze základních typů, nepochopení důsledků typové kontroly, etc) vytvářející mýtus výhod, ale jinak asi nic výraznějšího tam nebude. Souhlas?
Ale zacinat znovu, tak rovnou u Haskellu... jak uz jsem ti psal, s dobrou typovou inferenci se vyhoda dynamickeho typovani znacne snizuje. Takze pocitam, ze soucasny trend je (velmi pomaly) postupny navrat ke statickemu typovani diky rozsireni typove inference.
+1Ja to vidim podobne jako Inkvizitor - taky jsem Python zacal pouzival okolo roku 2001, a v te dobe to bylo prijemne jednodussi nez vsechno ostatni okolo. Pozdeji jsem si oblibil Common Lisp a Haskell, ale Python mi porad jde nejlepe.Takže když si to shrnu, dynamické typování nemá žádné principielní výhody. Jen je to zkrátka a dobře jednodužší na implementaci a naučení. Můžeme se bavit o tom, že je tu jakýsi historický balast, který si vývojáři nesou (například představa ukecanosti, představa pouze základních typů, nepochopení důsledků typové kontroly, etc) vytvářející mýtus výhod, ale jinak asi nic výraznějšího tam nebude. Souhlas?
Ale zacinat znovu, tak rovnou u Haskellu... jak uz jsem ti psal, s dobrou typovou inferenci se vyhoda dynamickeho typovani znacne snizuje. Takze pocitam, ze soucasny trend je (velmi pomaly) postupny navrat ke statickemu typovani diky rozsireni typove inference.
Kdyz se nam tu tedy formuje nejaky konsenzus... Tak se zeptam.
Z toho co tu ctu to vypada, ze staticke typovani (a la haskell) ma jistou evolucni vyhodu pred dynamickym.
Z dlouhodobeho hlediska muzeme tedy predokladat vymizeni dynamicky typovanych jazyku?
(at uz tim, ze se prestanou pouzivat, nebo tim, ze do nich typy proniknou)
Nejake odhady kdy to bude?
Takže když si to shrnu, dynamické typování nemá žádné principielní výhody. Jen je to zkrátka a dobře jednodužší na implementaci a naučení. Můžeme se bavit o tom, že je tu jakýsi historický balast, který si vývojáři nesou (například představa ukecanosti, představa pouze základních typů, nepochopení důsledků typové kontroly, etc) vytvářející mýtus výhod, ale jinak asi nic výraznějšího tam nebude. Souhlas?
Z dlouhodobeho hlediska muzeme tedy predokladat vymizeni dynamicky typovanych jazyku?
(at uz tim, ze se prestanou pouzivat, nebo tim, ze do nich typy proniknou)
Nejake odhady kdy to bude?
Tohle už některé jazyky mají.Z dlouhodobeho hlediska muzeme tedy predokladat vymizeni dynamicky typovanych jazyku?kompilator bude typy urcovat uplne sam (pripadne s nejakymi lehkymi hinty).
(at uz tim, ze se prestanou pouzivat, nebo tim, ze do nich typy proniknou)
Nejake odhady kdy to bude?
Dynamicky typovaný jazyky si serou do huby, viz PHP. Snažíme se v něm dělat jakoby byl staticky typovanej, přitom ale nemáme featury jako přetížení, generiku a navíc dynamický typy proměnnejch a type hinty ještě k tomu snižujou výkon.
Jediné co se mi vybavilo jsou IO monády v Haskellu. Jinak mě nenapadá, kdy by měl být typový systém příliš přísný. A i u těch IO monádách je to vlastně lepší, než bez toho.Jako starý Pythonista...Mohu tě požádat o odpověď na mou otázku?
Důvody pro použití dynamických typů:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování (takové to, když potřebuješ jen něco zkusit, a upřesňovat to budeš pozdějc)
3. neumím, nebo jazyk neumí typy
Doplníš další? (Kromě těchto scénářů nevím o ničem, kdy by netypování (př. dynamické typování) bylo užitečné.)
4. pripady, kdy staticky typovy system je prilis prisny a nepovoli preklad programu, ktery by dynamicky jazyk v pohode zvladnul a navic je takovy program lidsky intuitivni
Přijde mi to jako kombinace 2ky a neznalosti.
Chlape, ty si nejdřív něco nastuduj o typových systémech, než budeš rozdávat pravdy.
Existujou validní programy, který statickej jazyk neuzná. Žádnej statickej typovej systém nebude nikdy dostatečně silnej na to, aby uznal všechny validní programy - viz Godelovy věty o nekompletnosti.
http://logan.tw/posts/2014/11/12/soundness-and-completeness-of-the-type-system/
Existujou validní programy, který statickej jazyk neuzná. Žádnej statickej typovej systém nebude nikdy dostatečně silnej na to, aby uznal všechny validní programy - viz Godelovy věty o nekompletnosti.
http://logan.tw/posts/2014/11/12/soundness-and-completeness-of-the-type-system/
Tohle už některé jazyky mají.Z dlouhodobeho hlediska muzeme tedy predokladat vymizeni dynamicky typovanych jazyku?kompilator bude typy urcovat uplne sam (pripadne s nejakymi lehkymi hinty).
(at uz tim, ze se prestanou pouzivat, nebo tim, ze do nich typy proniknou)
Nejake odhady kdy to bude?
Kdyz se nam tu tedy formuje nejaky konsenzus... Tak se zeptam.
Jaká miliarda testů? Používám jak jazyky staticky typované, tak dynamicky a nepozoruji, že by programy v těch druhých padaly nějak častěji.Takže něco takového jako když já po milióntý prvý pouštím celou aplikaci, a píšu druhou miliardu testů, aby to pokrylo alespoň 5procent všech možnejch chyb? :-)Obávám se, že takto statické typování nefunguje. Všechny příklady tebou naznačného spektra možností mohu řešit. A statické typování mi bude hodně pomáhat. (A nemusím to dělat ručně.)Netvrdím, že to nejde. Kdyby to nešlo, tak by většina praktických problémů byla neřešitelná staticky typovanými jazyky. Jenže to, co vnímáš jako cosi, co ti bude hodně pomáhat, já často vnímám jako klacky motající se pod nohama.
Zkusme být konkrétní. Bylo tu uvedeno parsování JSONu. Řešil bych to určitě staticky. Rozhodování zpracování podle typu dat? Staticky. Rozhodnování podle dat - to si nejsem jist, co myslíš. Jak se mohu rozhodovat podle dat? Čeho se mohu chytnout? Můžeš uvést příklad?
Toto asi už bude o pocitech, takže to nerozebírejme. Zajímají mě tedy asi spíše nějaké racionálnější argumenty.
A v dynamicky typovaném Smalltalku se to vše vyřeší jedním a tím samým mechanismem.Rozhodování podle dat, tím myslím IF size > 5 cm THEN ...Rozumím. Tak první bude nějaká funkce. Druhé bude pattern matching na typ. A třetí se řeší třídou/interfacem. Viz odpověď dále.
Rozhodování podle typu, tím myslím IF (x hasMagnitude) THEN ...
Rozhodování bez ohledu na typ, tím myslím IF x > 5 THEN ..., bez ohledu na to, co to "x" je, protože mě zajímá jen odpověď na otázku, zda "to" je větší než 5.
Ale to je často zbytečně defenzivní přístup. Velké komplikace kvůli něčemu, čemu se dá předejít i jinak - prakticky tak, že pípu obsluhuje jedině personál k tomu kompetentní. Podobně je jednodušší namalovat na silnici plnou čáru než všude stavět svodidla.Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.Smysl statických typů je zajistit, aby se něco takového nestalo. Když zůstaneme u přirovnání, tak ty budeš muset hostinského zaškolit, a ještě nainstalovat kameru, aby si ho sledoval, zda nečepuje pivo přímo do pusy. A stejně ho neuhlídáš. Zatímco já tam budu moct dát cedulku "samoobslužná pípa".
Každopádně ve statickém jazyce zajistím, že ta pípa se odjistí jen v případě, kdy je do čeho načepovat. Džbánek ano, papírová krabice ne.
V případě dynamických typů ten problém máš samozřejmě taky. Ale buď ho neřešíš, a doufáš, že všechno dobře dopadne. Nebo testuješ jak blbej, a pak doufáš, že všechno dobře dopadne.
Akorát jsi přidal nicneříkající přívlastek ke slovu "omezení", abys ho nějak ospravedlnil. Která to jsou a proč? Opět - pro mě často zbytečně restriktivní způsob myšlení.Co je na tašce na rohlíky tak provokativního? Do datového typu rohlík dám jen rohlík a seznam rohlíků není nic jiného než taška na rohlíky. V době překladu vím, že mám datový typ, do kterého můžu naskládat jedině rohlíky. Jistě, mohu vytvořit i datový typ, do něhož jdou sázet rohlíky a housky. Ale i tuto situaci musím předvídat v době překladu.Ano, musím to předvídat v době překladu. To je jediné, v čem máš pravdu. Jinak fakt neuvažuju, tak jak popisuješ.
Kontainer na rohlíky bych dělal v případě, kdy chci jen rohlíky. Takže to bude třeba recept na jednohubky. Protože ten dělám zásadně z rohlíků.
Ale když budu brát do krámu nějakou tašku, tak bych byl idiot se omezovat takhle, ne. Budu definovat jiná omezení. Ta, která budou užitečná.
A jaká je tedy dnes doba?Neznám moc jazyků, které by obsahovaly "rohlík" jako jeden ze základních typů.Taky nás nic takového nezajímá. Doba typování ala jazyk C je naštěstí už dávno pryč.
A proč? Když tu kolekci využívá nějaký modul, který už má na jiném místě zajištěno, že tam přijde jen patřičný typ objektů, tak není důvod to opět někde specifikovat a kontrolovat. Dokonce to bude komplikace, když se změní protokol na vyšší úrovni. Zatímco u nespecifikovaného typu by nebylo nutné zasahovat do daného modulu vůbec, v tomto případě se tím vše úplně zbytečně rozbije.Budu-li chtít modelovat nákupní tašku, tak jako nejjednodušší případ mě napadá nějaká kolekce, třeba seznam. Ale pořád mi tu BoneFlute nevysvětlil, seznam čeho by to optimálně měl být a jakou by to mělo výhodu oproti obecné dynamicky typované kolekci.Toho, čeho potřebuješ. To přirovnání je debilní, ale tak můžeš mít nákupní tašku na pečivo. Takže obecný typ pro pečivo. Nebo typ TuháHmota, aby si tam nečepoval to pivo. Atd.
Pak samozřejmě můžeš dojít k závěru, že nevíš, a že tam chceš dát cokoliv. Tak dáš typ *, a budeš tam moct uložit opravdu cokoliv.
Trošku bych to přeformuloval:Naprosto v pořádku. Úplně stejně argumentují známí, kteří sympatizují s levicovými stranami. A nedokážou pochopit, když jim říkám, že nechci, aby mě stát vodil za ručičku, protože se umím vodit sám. Ale chtěl bych zdůraznit, že jsem prvotně reagoval na odpověď na Kitův komentář, v němž výslovně zmiňoval objektové jazyky. Nikdo tam po překladači nechce, aby něco takového hlídal, protože to je plně v kompetenci objektu.
Statickej jazyk: "hele, čím víc mi řekneš podrobností předem, tím líp ti pomůžu".
Dynamickej jazyk: "hele, mě to nezajímá, cpi si tam co chceš, stejně si to budeš hlídat ty, já ti nepomůžu, ani mě nenapadne".
- V dynamickém typování ti aplikace furt padá (ideálně na produkci), protože jsi nevychytal všechny chyby (nic ti nepomáhá).Podobné předsudky jsem taky míval, dokud jsem v tom nezačal dělat. A, světe div se, žádné neustálé padání se nekoná. Přiznám se, že mě to samotného překvapilo, ale v dynamicky typovaných jazycích se vyvíjí trošku jinak - musíš u toho trochu změnit způsob uvažování. Ze začátku má člověk nutkání dopisovat typovou kontrolu ručně, ale to je ve skutečnosti antipattern. To platí třeba i v Pythonu (viz Idiomatic Python), ale třeba v takovém objektovém Smalltalku je to přímo do očí bijící. Prostě typová kontrola je také kompetence objektů. A ono to funguje, a velmi dobře!
V dynamickém typování ti aplikace furt padá (ideálně na produkci), protože jsi nevychytal všechny chyby (nic ti nepomáhá).
A v dynamicky typovaném Smalltalku se to vše vyřeší jedním a tím samým mechanismem.Rozhodování podle dat, tím myslím IF size > 5 cm THEN ...Rozumím. Tak první bude nějaká funkce. Druhé bude pattern matching na typ. A třetí se řeší třídou/interfacem. Viz odpověď dále.
Rozhodování podle typu, tím myslím IF (x hasMagnitude) THEN ...
Rozhodování bez ohledu na typ, tím myslím IF x > 5 THEN ..., bez ohledu na to, co to "x" je, protože mě zajímá jen odpověď na otázku, zda "to" je větší než 5.
Trošku bych to přeformuloval:Naprosto v pořádku. Úplně stejně argumentují známí, kteří sympatizují s levicovými stranami. A nedokážou pochopit, když jim říkám, že nechci, aby mě stát vodil za ručičku, protože se umím vodit sám. Ale chtěl bych zdůraznit, že jsem prvotně reagoval na odpověď na Kitův komentář, v němž výslovně zmiňoval objektové jazyky. Nikdo tam po překladači nechce, aby něco takového hlídal, protože to je plně v kompetenci objektu.
Statickej jazyk: "hele, čím víc mi řekneš podrobností předem, tím líp ti pomůžu".
Dynamickej jazyk: "hele, mě to nezajímá, cpi si tam co chceš, stejně si to budeš hlídat ty, já ti nepomůžu, ani mě nenapadne".
- V dynamickém typování ti aplikace furt padá (ideálně na produkci), protože jsi nevychytal všechny chyby (nic ti nepomáhá).Podobné předsudky jsem taky míval, dokud jsem v tom nezačal dělat. A, světe div se, žádné neustálé padání se nekoná. Přiznám se, že mě to samotného překvapilo, ale v dynamicky typovaných jazycích se vyvíjí trošku jinak - musíš u toho trochu změnit způsob uvažování. Ze začátku má člověk nutkání dopisovat typovou kontrolu ručně, ale to je ve skutečnosti antipattern. To platí třeba i v Pythonu (viz Idiomatic Python), ale třeba v takovém objektovém Smalltalku je to přímo do očí bijící. Prostě typová kontrola je také kompetence objektů. A ono to funguje, a velmi dobře!
Ve staticky typovanym jazyku se provede kontrola vstupnich dat nejen pred vstupem do funkce/objektu ale kdyz se dostatecne chytre oseka prostor typu vstupnich dat, da se matematicky dokazat validnost dat retezove. Tj. kdyz mi sedi vstupni data do moji funkce a vystup z my funkce sedi do nasledujici funkce v poradi, tak se transzitivne dokaze ze sedi celej program.Numpy? To myslíš tu Python knihovnu napsanou v C? ???
Problem je ze se musi provest mozkova lobotomie a intuitivni programy pro obycejnyho cloveka se musi nejak nacpat do toho osekanyho typovyho systemu. Obzvlast to boli u generik. Dynamickej jazyk mapuje lidskou intuici skoro presne do reseni problemu, u statickyho musi clovek provadet mentalni gymnastiku, nez svoji intuici nejak vmestna do ty omezeny svedsky bedny jmenem statickej typovej system.
Cim lepsi typovej system, tim min to boli samozrejme. Obzvlast kdyz novy typovy systemy jako Idris umoznujou typovy diry. Tj. dokud nevis co tam bude za typ, tak to preskocis a program prelozis i bez toho.
Problem je v tom ze skutecne pouzitelnej typovej system je zatim dost daleko v budoucnosti, proto vsichni radsi pouzivaji dynamicky jazyky. Nebo soucasny staticky jazyky pro skutecne jednoduchy programy, ktery jenom tahaji nejaky jasne specifikovany data sem a tam, zejmena pokud potrebujou vykon.
Vykon je lepsi u soucasnych mainstream statickych jazyku, protoze se daji prelozit do C ekvivalentu, tj. zhruba representace jak funguje CPU. Existujou i dynamicky jazyky ktery fungujou na vykonnostni urovni C. Dokonce ho i prekonavaji v dnesni dobe, kde se silne uvazuje s paralelnim vypoctem. Viz vektorovy jasyky APL family, obzvlast kdb, numpy, apod.
Ve staticky typovanym jazyku se provede kontrola vstupnich dat nejen pred vstupem do funkce/objektu ale kdyz se dostatecne chytre oseka prostor typu vstupnich dat, da se matematicky dokazat validnost dat retezove. Tj. kdyz mi sedi vstupni data do moji funkce a vystup z my funkce sedi do nasledujici funkce v poradi, tak se transzitivne dokaze ze sedi celej program.Numpy? To myslíš tu Python knihovnu napsanou v C? ???
Problem je ze se musi provest mozkova lobotomie a intuitivni programy pro obycejnyho cloveka se musi nejak nacpat do toho osekanyho typovyho systemu. Obzvlast to boli u generik. Dynamickej jazyk mapuje lidskou intuici skoro presne do reseni problemu, u statickyho musi clovek provadet mentalni gymnastiku, nez svoji intuici nejak vmestna do ty omezeny svedsky bedny jmenem statickej typovej system.
Cim lepsi typovej system, tim min to boli samozrejme. Obzvlast kdyz novy typovy systemy jako Idris umoznujou typovy diry. Tj. dokud nevis co tam bude za typ, tak to preskocis a program prelozis i bez toho.
Problem je v tom ze skutecne pouzitelnej typovej system je zatim dost daleko v budoucnosti, proto vsichni radsi pouzivaji dynamicky jazyky. Nebo soucasny staticky jazyky pro skutecne jednoduchy programy, ktery jenom tahaji nejaky jasne specifikovany data sem a tam, zejmena pokud potrebujou vykon.
Vykon je lepsi u soucasnych mainstream statickych jazyku, protoze se daji prelozit do C ekvivalentu, tj. zhruba representace jak funguje CPU. Existujou i dynamicky jazyky ktery fungujou na vykonnostni urovni C. Dokonce ho i prekonavaji v dnesni dobe, kde se silne uvazuje s paralelnim vypoctem. Viz vektorovy jasyky APL family, obzvlast kdb, numpy, apod.
Pokud ti není jasný rozdíl mezi sémantikou listu a setu, tak je asi problém na tvém přijímači.Sémantický rozdíl nevidím. Seznam autorů nebo množina autorů? Pro mne je to kolekce autorů a budu s ní pracovat tak, aby když někdo vymění list za set, mi to mohlo být jedno.On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
(Btw zrovna tady máš ještě o problém navíc, protože se rozlišuje první autor, korespondující autor...)
#!/usr/bin/env python
# -*- coding: utf-8 -*-
def vypis(kolekce):
print(type(kolekce))
for i in kolekce:
print(i)
print()
seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)
Pokud ti není jasný rozdíl mezi sémantikou listu a setu, tak je asi problém na tvém přijímači.Sémantický rozdíl nevidím. Seznam autorů nebo množina autorů? Pro mne je to kolekce autorů a budu s ní pracovat tak, aby když někdo vymění list za set, mi to mohlo být jedno.On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
(Btw zrovna tady máš ještě o problém navíc, protože se rozlišuje první autor, korespondující autor...)Kód: [Vybrat]#!/usr/bin/env python
# -*- coding: utf-8 -*-
def vypis(kolekce):
print(type(kolekce))
for i in kolekce:
print(i)
print()
seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.Jasne. Existuji situace, kdy je to jedno (a v nich ti nic nebrani pouzit neco jak Iterable). A (drz se!) jsou situace, kdy to jedno neni. Pokud je chces resit jako prase... tak je res jako prase.
vypis(list(seznam))
vypis(list(mnozina))
# nebo uvnitř vypis()
seznam = list(kolekce)
Kód: [Vybrat]#!/usr/bin/env python
# -*- coding: utf-8 -*-
def vypis(kolekce):
print(type(kolekce))
for i in kolekce:
print(i)
print()
seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.
V Javě bych v deklaraci formálního parametru použil Iterable<Object>. Takže vlastně stejně, jen o pár zbytečných znaků navíc.
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print().Toto není problém dynamicky typovaných jazyků, ale pouze tohoto příkladu. Navíc je to napsané spíš strukturovaně, než s OOP.
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print(). Když nebudou splněny obě tyto podmínky, funkce havaruje. Pravděpodobně vyhodí nějakou výjimku, kterou buď očekávám a musím na ni nějak zareagovat, nebo výjimka shodí celý program. Kdybych se chtěl výjimce vyhnout, musel bych v kódu nějak ošetřit chování funkce pro všechny typy, které nejsou "iterable<printable>". Ovšem ze zadání může plynout, že nemá smysl volat vypis() na takové typy. Ve staticky typovaném jazyce bych jednoduše přidal parametru kolekce typ iterable<printable> a mohl bych se spolehnout, že případné chyby odhalí kompilátor při překladu. V dynamicky typovaném jazyce můžu tento požadavek tak akorát napsat do dokumentace a případně doufat, že na každé použití této funkce někdo napíše test, že se v tom kokrétním místě vždy volá se správným typem.
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print(). Když nebudou splněny obě tyto podmínky, funkce havaruje. Pravděpodobně vyhodí nějakou výjimku, kterou buď očekávám a musím na ni nějak zareagovat, nebo výjimka shodí celý program. Kdybych se chtěl výjimce vyhnout, musel bych v kódu nějak ošetřit chování funkce pro všechny typy, které nejsou "iterable<printable>". Ovšem ze zadání může plynout, že nemá smysl volat vypis() na takové typy. Ve staticky typovaném jazyce bych jednoduše přidal parametru kolekce typ iterable<printable> a mohl bych se spolehnout, že případné chyby odhalí kompilátor při překladu. V dynamicky typovaném jazyce můžu tento požadavek tak akorát napsat do dokumentace a případně doufat, že na každé použití této funkce někdo napíše test, že se v tom kokrétním místě vždy volá se správným typem.
Jistě, uvedený příklad nemá ošetřen vstup, protože pro demonstrační účely je nepotřebuje. V reálu jsou před výkonnou částí procedury nejen typové kontroly, ale i další validace s případným vyhozením výjimky. Záleží na specifikaci požadavku, zda a v jaké míře je taková validace účelná. Pokud se připouští, že na vstupu bude třeba int nebo string, procedura s tím musí počítat. U staticky typovaných jazyků by přibyly další dvě přetížené metody. Pak do té metody někdo bude chtít strčit float...
Statické typy nepřipouští, že bych tu proceduru mohl chtít volat s hodnotou jiného typu, než jaký je uveden ve formálním parametru. Považuji to za chybu. V dynamicky typovaném jazyce mohu předat i hodnotu, která není iterable a procedura si s tím poradí. Je to její starost.
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.Jasne. Existuji situace, kdy je to jedno (a v nich ti nic nebrani pouzit neco jak Iterable). A (drz se!) jsou situace, kdy to jedno neni. Pokud je chces resit jako prase... tak je res jako prase.
Správně jsi poznal, že seznam i množina jsou Iterable, což je přesně to, o co mi šlo. Ukázal jsem příklad, kde je výhodné použití polymorfismu. Velmi dobře vím, že jsou situace, kdy to jedno není, ale o tom ten příklad není. Místo striktně defenzivního přístupu použiji takový, který je v daném případě výhodnější. Uvedeným postupem docílím mnohem volnějších závislostí mezi objekty, což je silně žádoucí. Mohu je tak poměrně jednoduše zaměňovat. Jestli je to styl na prase, tak programuji jako prase - ale objektově.
V Javě bych v deklaraci formálního parametru použil Iterable<Object>. Takže vlastně stejně, jen o pár zbytečných znaků navíc.
Pokud by byl problém s množinou, mohu ji klidně přetypovat na seznam při volání procedury nebo až uvnitř.Kód: [Vybrat]vypis(list(seznam))
vypis(list(mnozina))
# nebo uvnitř vypis()
seznam = list(kolekce)
Kód: [Vybrat]#!/usr/bin/env python
# -*- coding: utf-8 -*-
def vypis(kolekce):
print(type(kolekce))
for i in kolekce:
print(i)
print()
seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print(). Když nebudou splněny obě tyto podmínky, funkce havaruje. Pravděpodobně vyhodí nějakou výjimku, kterou buď očekávám a musím na ni nějak zareagovat, nebo výjimka shodí celý program. Kdybych se chtěl výjimce vyhnout, musel bych v kódu nějak ošetřit chování funkce pro všechny typy, které nejsou "iterable<printable>". Ovšem ze zadání může plynout, že nemá smysl volat vypis() na takové typy. Ve staticky typovaném jazyce bych jednoduše přidal parametru kolekce typ iterable<printable> a mohl bych se spolehnout, že případné chyby odhalí kompilátor při překladu. V dynamicky typovaném jazyce můžu tento požadavek tak akorát napsat do dokumentace a případně doufat, že na každé použití této funkce někdo napíše test, že se v tom kokrétním místě vždy volá se správným typem.
Toto není problém dynamicky typovaných jazyků, ale pouze tohoto příkladu.
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print().Toto není problém dynamicky typovaných jazyků, ale pouze tohoto příkladu. Navíc je to napsané spíš strukturovaně, než s OOP.
V OOP by pro výpis sloužila samostatná třída (nějaký Printer), s pomocí návrhového vzoru Visitor by si implementovala sama tu metodu print(), nebo by ji delegovala na ty prvky, u kterých to potřebuji. Navíc ve skutečnosti vůbec nemusí záležet na tom, zda chci vypsat kolekci, prvek, a nebo třeba rekurzivně nějaký Composite
Toto není problém dynamicky typovaných jazyků, ale pouze tohoto příkladu.
Toto je problém dynamicky typovaných jazyků. Ve staticky typovaném jazyce můžeš napsat vypis jako generickou funkci a dostaneš naprosto stejnou funkcionalitu jaku v pythonu. Když tu funkci píšeš, nemusíš znát konkrétní typ. Jako bonus navíc máš typovou kontrolu během překladu, funce vypis nepujde zavolat s nečím, co není iterable a printable a v runtime to bude rychlejší než dynamicky typovaný jazyk, protože v runtime se už žádné typové kontroly dělat nemusí.
Generika jsou pouze berličkou, aby se ve staticky typovaných jazycích dalo dělat totéž co v dynamicky typovaných. Stále však budu chtít zavolat tu proceduru třeba se stringem.
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print().Toto není problém dynamicky typovaných jazyků, ale pouze tohoto příkladu. Navíc je to napsané spíš strukturovaně, než s OOP.
V OOP by pro výpis sloužila samostatná třída (nějaký Printer), s pomocí návrhového vzoru Visitor by si implementovala sama tu metodu print(), nebo by ji delegovala na ty prvky, u kterých to potřebuji. Navíc ve skutečnosti vůbec nemusí záležet na tom, zda chci vypsat kolekci, prvek, a nebo třeba rekurzivně nějaký Composite
Dynamické typování v tomto případě nemá žádnou výhodu. Bude to pomalejší a na chyby v programu se přijde až v runtime, kdy to celé spadne.
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Dynamické typování v tomto případě nemá žádnou výhodu. Bude to pomalejší a na chyby v programu se přijde až v runtime, kdy to celé spadne.
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Jde-li jen o (úsporný) zápis, tak v C++ to jde stejně jednoduše (bez explicitních typů):Pokud ti není jasný rozdíl mezi sémantikou listu a setu, tak je asi problém na tvém přijímači.Sémantický rozdíl nevidím. Seznam autorů nebo množina autorů? Pro mne je to kolekce autorů a budu s ní pracovat tak, aby když někdo vymění list za set, mi to mohlo být jedno.On je tam trochu sémantický rozdíl, víme? A z toho typu vysloveně svítí.Teoreticky. Prakticky treba kdyz mas getXs(), tak podle typu vis, zda mohou byt xka duplicitni (list vs. set).K čemu potřebuješ rozlišovat list vs. text? Dostaneš kolekci a budeš s ní tak i pracovat.
(Btw zrovna tady máš ještě o problém navíc, protože se rozlišuje první autor, korespondující autor...)Kód: [Vybrat]#!/usr/bin/env python
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.
# -*- coding: utf-8 -*-
def vypis(kolekce):
print(type(kolekce))
for i in kolekce:
print(i)
print()
seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)
auto printElements(auto coll) {
for (auto el : coll) {
std::cout << el << std::endl;
}
}
int main() {
std::vector<int> v{1, 2, 3};
printElements(v);
std::set<int> s{4, 5, 6};
printElements(s);
printElements("abc"s);
}
Ještě nějaký jiný problém s typy?
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.
Generika jsou pouze berličkou, aby se ve staticky typovaných jazycích dalo dělat totéž co v dynamicky typovaných.
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.
Tohle je tady mylně považováno za výhodu statických jazyků, ale ten program nepůjde přeložit vůbec úplně celý.
Přitom v dynamickém jazyce mi ta hotová část programu může už dávno běžet...
Dynamické typování v tomto případě nemá žádnou výhodu. Bude to pomalejší a na chyby v programu se přijde až v runtime, kdy to celé spadne.
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print().Toto není problém dynamicky typovaných jazyků, ale pouze tohoto příkladu. Navíc je to napsané spíš strukturovaně, než s OOP.
V OOP by pro výpis sloužila samostatná třída (nějaký Printer), s pomocí návrhového vzoru Visitor by si implementovala sama tu metodu print(), nebo by ji delegovala na ty prvky, u kterých to potřebuji. Navíc ve skutečnosti vůbec nemusí záležet na tom, zda chci vypsat kolekci, prvek, a nebo třeba rekurzivně nějaký Composite
Zrovna print() není úplně dobrý příklad, protože "nějak smysluplně vypsat" se dají vypsat hodnoty libovolného typu. Ale třeba get_peer_address() má jistě smysl pro třídu network_socket. Hůř se ale bude hledat význam takové funkce pro string nebo int a s tím mi nepomůže, když tu funkci přesunu do samostatné třídy address_extractor.
... Ale třeba get_peer_address() má jistě smysl pro třídu network_socket. Hůř se ale bude hledat význam takové funkce pro string nebo int a s tím mi nepomůže, když tu funkci přesunu do samostatné třídy address_extractor. Jde mi o to, že některé operace nemají pro nějaké typy smysl, buď obecně nebo v kontextu konkrétního řešeného problému. Jakákoliv runtime reakce na volání takové operace s nevhodným typem argumentu je špatně, protože v prvé řadě nemělo dojít k tomu zavolání. Tedy jedná se o chybu v programu, kterou je nutno řešit úpravou kódu. Statické typování mi takovou chybu odhalí včas a bez toho, abych musel kvůli diagnostice psát víc, než jméno typu.
Je tu stále stejná skupina diskutujících. A tak jsem si dovolil představit si ten dokonalý statický typový systém, který nepotřebuje unit testy, a který se píše od začátku do konce na čisto, kdy až na konci se povede celý zkompilovat, což znamená, že je správně, a rovnou se posílá na produkci... ;D ;D (jen trocha ironie)Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.
Tohle je tady mylně považováno za výhodu statických jazyků, ale ten program nepůjde přeložit vůbec úplně celý.
Přitom v dynamickém jazyce mi ta hotová část programu může už dávno běžet...
A na to jsi přišel jak?
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.
Tohle je tady mylně považováno za výhodu statických jazyků, ale ten program nepůjde přeložit vůbec úplně celý.
Přitom v dynamickém jazyce mi ta hotová část programu může už dávno běžet...
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.
... Ale třeba get_peer_address() má jistě smysl pro třídu network_socket. Hůř se ale bude hledat význam takové funkce pro string nebo int a s tím mi nepomůže, když tu funkci přesunu do samostatné třídy address_extractor. Jde mi o to, že některé operace nemají pro nějaké typy smysl, buď obecně nebo v kontextu konkrétního řešeného problému. Jakákoliv runtime reakce na volání takové operace s nevhodným typem argumentu je špatně, protože v prvé řadě nemělo dojít k tomu zavolání. Tedy jedná se o chybu v programu, kterou je nutno řešit úpravou kódu. Statické typování mi takovou chybu odhalí včas a bez toho, abych musel kvůli diagnostice psát víc, než jméno typu.
get_peer_address() má jako parametr int32, string nebo je to jedno? Návratová hodnota je big endian nebo little endian? Pro diagnostiku musíš psát i testy. Co když dostaneš 0.0.0.0 nebo 255.255.255.255? Bude to v pořádku?
To je zcela zásadní výhoda statických jazyků. O tom, že to není omyl, svědčí i všechny ty snahy naroubovat statickou typovou kontrolu na původně dynamicky typované jazyky. A zatímco opravuji kód, aby prošla typová kontrola, hotová část programu, tedy předchozí zkompilovatelná, odladěná, otestovaná a v mém oblíbeném VCS uložená verze, už dávno běží v produkčním nasazení. A já se přitom nemusím bát, že se z nějakého podivného důvodu do nějaké pomocné funkce, která normálně dostává řetězce a volá na ně clear(), dostane jako parametr handle k databázi :)Tohle je tady mylně považováno za výhodu statických jazyků, ale ten program nepůjde přeložit vůbec úplně celý.Při chybě v programu to spadne už v testech - stejně jako při statickém typování.Při statickém typování to nepůjde vůbec přeložit, chybu zjistíš ještě dřív, než napíšeš jedinou řádku testů.
Přitom v dynamickém jazyce mi ta hotová část programu může už dávno běžet...
Tohle je tady mylně považováno za výhodu statických jazyků, ale ten program nepůjde přeložit vůbec úplně celý.
Přitom v dynamickém jazyce mi ta hotová část programu může už dávno běžet...
To je zcela zásadní výhoda statických jazyků. O tom, že to není omyl, svědčí i všechny ty snahy naroubovat statickou typovou kontrolu na původně dynamicky typované jazyky. A zatímco opravuji kód, aby prošla typová kontrola, hotová část programu, tedy předchozí zkompilovatelná, odladěná, otestovaná a v mém oblíbeném VCS uložená verze, už dávno běží v produkčním nasazení. A já se přitom nemusím bát, že se z nějakého podivného důvodu do nějaké pomocné funkce, která normálně dostává řetězce a volá na ně clear(), dostane jako parametr handle k databázi :)
Dynamické typování v tomto případě nemá žádnou výhodu. Bude to pomalejší a na chyby v programu se přijde až v runtime, kdy to celé spadne.
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Pokud máš plné pokrytí. Za předpokladu jedné unity.
Pokud píšeš libku nebo nedejte bozi framework, tak se ti tohle ještě dál komplikuje...
Co jsou to "pomocné funkce"? Když mají vedlejší efekt, tak to jsou procedury, ne?
... Ale třeba get_peer_address() má jistě smysl pro třídu network_socket. Hůř se ale bude hledat význam takové funkce pro string nebo int a s tím mi nepomůže, když tu funkci přesunu do samostatné třídy address_extractor. Jde mi o to, že některé operace nemají pro nějaké typy smysl, buď obecně nebo v kontextu konkrétního řešeného problému. Jakákoliv runtime reakce na volání takové operace s nevhodným typem argumentu je špatně, protože v prvé řadě nemělo dojít k tomu zavolání. Tedy jedná se o chybu v programu, kterou je nutno řešit úpravou kódu. Statické typování mi takovou chybu odhalí včas a bez toho, abych musel kvůli diagnostice psát víc, než jméno typu.
get_peer_address() má jako parametr int32, string nebo je to jedno? Návratová hodnota je big endian nebo little endian? Pro diagnostiku musíš psát i testy. Co když dostaneš 0.0.0.0 nebo 255.255.255.255? Bude to v pořádku?
Funkce get_peer_address() je buď metoda třídy network_socket bez parametrů, nebo je to samostatná funkce (nebo klidně metoda třídy address_extractor) s jedním parametrem typu network_socket. Návratová hodnota je typu socket_address, což je polymorfní typ zahrnující IPv4, IPv6 i řetězce (používané jako jména UNIX domain socketů). Všechny tyhle informace jsou explicitně napsané ve zdrojáku, z něj se automaticky přenesou do dokumentace (např. v C++ pomocí Doxygenu), a to všechno bez nutnosti napsat jediné slovo komentáře a jediný test zjišťující, zda se předávají nebo vrací hodnoty správných typů. Testy už píšu jen na ověření chování této funkce se smysluplnými typy parametrů.
NeDá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?Dynamické typování v tomto případě nemá žádnou výhodu. Bude to pomalejší a na chyby v programu se přijde až v runtime, kdy to celé spadne.
Při chybě v programu to spadne už v testech - stejně jako při statickém typování.
Pokud máš plné pokrytí. Za předpokladu jedné unity.
Pokud píšeš libku nebo nedejte bozi framework, tak se ti tohle ještě dál komplikuje...
Kód: [Vybrat]#!/usr/bin/env python
# -*- coding: utf-8 -*-
def vypis(kolekce):
print(type(kolekce))
for i in kolekce:
print(i)
print()
seznam = ["Alfa", 42, 42, ("Beta", "Gamma")]
mnozina = {"Alfa", 42, 42, ("Beta", "Gamma")}
vypis(seznam)
vypis(mnozina)
Jak vidíš, tak proceduře vypis() je v daném případě jedno, zda jí předhodíš seznam nebo množinu. Vypíše obojí. Pokud je budu potřebovat rozlišit, stále ještě mohu použít reflexi.
Tento příklad krásně ilustruje problém dynamicky typovaných jazyků. Procedura vypis() implicitně předpokládá, že parametr kolekce se dá iterovat a že iterací dostanu objekty, pro které má smysl volat print(). Když nebudou splněny obě tyto podmínky, funkce havaruje. Pravděpodobně vyhodí nějakou výjimku, kterou buď očekávám a musím na ni nějak zareagovat, nebo výjimka shodí celý program. Kdybych se chtěl výjimce vyhnout, musel bych v kódu nějak ošetřit chování funkce pro všechny typy, které nejsou "iterable<printable>". Ovšem ze zadání může plynout, že nemá smysl volat vypis() na takové typy. Ve staticky typovaném jazyce bych jednoduše přidal parametru kolekce typ iterable<printable> a mohl bych se spolehnout, že případné chyby odhalí kompilátor při překladu. V dynamicky typovaném jazyce můžu tento požadavek tak akorát napsat do dokumentace a případně doufat, že na každé použití této funkce někdo napíše test, že se v tom kokrétním místě vždy volá se správným typem.
Co jsou to "pomocné funkce"? Když mají vedlejší efekt, tak to jsou procedury, ne?Používám terminologii mého oblíbeného C++.
A já se přitom nemusím bát, že se z nějakého podivného důvodu do nějaké pomocné funkce, která normálně dostává řetězce a volá na ně clear(), dostane jako parametr handle k databázi :)
Jestli potřebuješ staticky typovaný jazyk, aby sis byl jistý, že tvůj kód omylem nepromázne databázi, tak bys měl změnit obor. Nebo si alespoň pořídit hodně kvalitní pojistku na blbost.
K tomu mě napadá akademická otázka: Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?+1
Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?Ne
Statické typování má tu výhodu, že taková situace jednoduše neexistuje. Pokud popletu vstupy, tak to na mě zařve kompilátor. Hned! Nemusím testovat, jestli ta funkce vyhodila nějakou chybu, protože jsem se překlpl. Spustu věcí nemusím dělat. Kód je kratší a přímočařejší.
float sin(float phi) {
return 0.0;
}
+1
A já se přitom nemusím bát, že se z nějakého podivného důvodu do nějaké pomocné funkce, která normálně dostává řetězce a volá na ně clear(), dostane jako parametr handle k databázi :)
Jestli potřebuješ staticky typovaný jazyk, aby sis byl jistý, že tvůj kód omylem nepromázne databázi, tak bys měl změnit obor. Nebo si alespoň pořídit hodně kvalitní pojistku na blbost.
Já už jsem ve svém programátorském životě viděl příliš mnoho chyb, které jsem buď sám udělal, nebo jsem je musel opravit, o nichž jsem byl přesvědčený, že nemohou nastat... :)
S trochou nadsázky - programátoři se dělí do několika podmnožin:
- Ti, kteří dělají chyby, a nevědí, co s tím.
- Ti, kteří dělají chyby, ale snaží se z nich poučit a snaží se používat nástroje, které jim pomohou chyby lépe odhalovat a odstraňovat.
- Ti, kteří nedělají chyby.
Programátoři z první podmnožiny potřebují nabrat zkušenosti nebo, když toho nejsou schopni, najít si jiný obor. Programátoři z druhé podmnožiny dávají přednost staticky typovaným jazykům, protože jim pomáhají diagnostikovat chyby. Pro programátory ze třetí podmnožiny jsou lepší dynamicky typované jazyky, protože je nebrzdí v tvůrčím rozletu. Drobný problém je, že třetí podmnožina je prázdná.
Navíc z ní vůbec není patrné, zda je parametr ve stupních, radiánech nebo v jiných jednotkách. Takže i ten typ "float" je de facto špatně, protože neobsahuje sémantiku. Když tam hodíš údaj v metrech, tak to typová kontrola nepozná.
sin :: Deg Float -> Float
S trochou nadsázky - programátoři se dělí do několika podmnožin:
- Ti, kteří dělají chyby, a nevědí, co s tím.
- Ti, kteří dělají chyby, ale snaží se z nich poučit a snaží se používat nástroje, které jim pomohou chyby lépe odhalovat a odstraňovat.
- Ti, kteří nedělají chyby.
Programátoři z první podmnožiny potřebují nabrat zkušenosti nebo, když toho nejsou schopni, najít si jiný obor. Programátoři z druhé podmnožiny dávají přednost staticky typovaným jazykům, protože jim pomáhají diagnostikovat chyby. Pro programátory ze třetí podmnožiny jsou lepší dynamicky typované jazyky, protože je nebrzdí v tvůrčím rozletu. Drobný problém je, že třetí podmnožina je prázdná.
Navíc z ní vůbec není patrné, zda je parametr ve stupních, radiánech nebo v jiných jednotkách. Takže i ten typ "float" je de facto špatně, protože neobsahuje sémantiku. Když tam hodíš údaj v metrech, tak to typová kontrola nepozná.Kód: [Vybrat]sin :: Deg Float -> Float
Jako doplňek k statickým typů jsou samozřejmě testy výborným nástrojem.S trochou nadsázky - programátoři se dělí do několika podmnožin:
- Ti, kteří dělají chyby, a nevědí, co s tím.
- Ti, kteří dělají chyby, ale snaží se z nich poučit a snaží se používat nástroje, které jim pomohou chyby lépe odhalovat a odstraňovat.
- Ti, kteří nedělají chyby.
Programátoři z první podmnožiny potřebují nabrat zkušenosti nebo, když toho nejsou schopni, najít si jiný obor. Programátoři z druhé podmnožiny dávají přednost staticky typovaným jazykům, protože jim pomáhají diagnostikovat chyby. Pro programátory ze třetí podmnožiny jsou lepší dynamicky typované jazyky, protože je nebrzdí v tvůrčím rozletu. Drobný problém je, že třetí podmnožina je prázdná.
Popis druhé podmnožiny je neúplný. Patří do ní i programátoři, kteří píší testy.
Nevím, zda si rozumíte:Taky nevím, jestli si rozumíme, ale to, co já chápu pod "hot code (re)loading" je každopádně to první, ne to druhé. Myslím, že jsem to několikrát celkem jasně napsal.
Jestliže ve Smalltalku přepíšu za běhu (Smalltalk má běh pořád) metodu, všechny instance dané třídy, přestože se nijak nezměnily, budou používat novou metodu, protože nositelem metod objektu je zde třída (způsob implementace metod). Když v Javascriptu změním kód, který generuje objekty včetně metod (bez "prototypování", ad-hoc), pak samozřejmě nové chování budou mít až ty nové objekty.
Je to ošetřený a rozhodnutý v době překladu. To je to co mě zajímá.Nevím, jestli jsme si tady rozuměli. V době překladu víš jenom to, že
Intuitivně bych to taky tak tipoval. Ale nemám dostatek erudice, abych to mohl tvrdit s jistotou :)V JVM, co jsem se dočetl, hot reloading jde, ale nemůžeš měnit signatury ani odstraňovat nebo přidávat metody. Takže vlastně můžeš jenom měnit implementaci existujících věcí.A to je právě jedním z důsledků toho, že Java nemá zasílání zpráv, ale volání funkcí.
Podstatné je, že já sice chci integer, ale stroj ví, že to nemusí být jen integer. A tak mě přinutí, compile-time, ošetřit obě možnosti.Je to ošetřený a rozhodnutý v době překladu. To je to co mě zajímá.Nevím, jestli jsme si tady rozuměli. V době překladu víš jenom to, že
1. z externího zdroje dostaneš posloupnost bajtů (vstup uživatele nebo síťový packet)
2. víš, že bys chtěl, aby ta posloupnost bajtů byl nějaký typ (např. integer zakódovaný jako string)
Jestli se tvoje "compile time přání" v run time splní nebo ne - to není nic jiného než dynamické typování.
Existujou validní programy, který statickej jazyk neuzná. Žádnej statickej typovej systém nebude nikdy dostatečně silnej na to, aby uznal všechny validní programy - viz Godelovy věty o nekompletnosti.
Podstatné je, že já sice chci integer, ale stroj ví, že to nemusí být jen integer. A tak mě přinutí, compile-time, ošetřit obě možnosti.No, skoro bych řekl, že to je univerzální pravda. Protože ten jazyk prostě musí nějak ošetřit tu druhou možnost.
(Jsem si vědom, že to není univerzální pravda, a že ne každý staticky typovaný jazyk se bude takto chovat. Ale je to má motivace, proč ano, a proč ne dynamické.)
Mě by zas enormně zajímalo, jak bys chtěl vágní pojmy typu "jakkoliv zakamuflovaná statická typová kontrola" přeformulovat do formální podoby :)Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?Ne
Já si to myslím taky, ale na akademickou otázku by mě zajímala akademická odpověď, tedy přeformulování otázky do formální podoby a matematický důkaz...
To je jak kdyby jeden frajer peclive frezoval ocelove obrobky do komplexniho pristroje, zatimco opodal by se mu smal nejaky plantala z kvetinarstvi, ze naco to frezuje do oceli a dela to tak presne a namahave, kdyz na to prece muze pouzit stejne dobre nuzky a lepenku, jako to dela on.
Panové, fakt vám přijde, že tahle pseudotrefná, emotivní, na všech deset noh kulhající přirovnání, jsou k něčemu dobrá?To je jak kdyby jeden frajer peclive frezoval ocelove obrobky do komplexniho pristroje, zatimco opodal by se mu smal nejaky plantala z kvetinarstvi, ze naco to frezuje do oceli a dela to tak presne a namahave, kdyz na to prece muze pouzit stejne dobre nuzky a lepenku, jako to dela on.
Proč bych měl lisovat podložky pod matičky z plechu, když je mohu soustružit z kulatiny a prověřovat kalibrem, že?
Nehádám se s tebou, přijde mi taky lepší mít explicitně dvě větve, když tam věcně nutně jsou, ale nevidím mězi těmi dvěma možnostmi, jak k tomu přistupovat, tak světodějný rozdíl jako ty ;)
Tak třeba typová kontrola umí zajistit, že funkce vrací sudé číslo. Testem to nejde, nejsou-li ty výsledky shora omezené.Já si to myslím taky, ale na akademickou otázku by mě zajímala akademická odpověďDá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?Ne
Pouštíš se na tenkej led :-) Bohatě stačí, že typová kontrola umí zajistit, že funkce vrátí celé číslo. Už v takovém případě test nebude stačit.Tak třeba typová kontrola umí zajistit, že funkce vrací sudé číslo. Testem to nejde, nejsou-li ty výsledky shora omezené.Já si to myslím taky, ale na akademickou otázku by mě zajímala akademická odpověďDá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?Ne
To je tím, že to je hloupě napsané. V takovém systému jde mít typ obsahující (a kontrolující) fyzikální rozměr i jednotku a činitele, takže prostě řeknu, že rozměr vstupu je 1 a výpočet upravím podle vlastností vstupu. Pak tam nepůjdou hodit metry, protože clashne rozměr. Fyzici tohle mají ve výpočtech ošetřené běžně, jen ty typy bývají divočejší, například vektorové pole.Statické typování má tu výhodu, že taková situace jednoduše neexistuje. Pokud popletu vstupy, tak to na mě zařve kompilátor. Hned! Nemusím testovat, jestli ta funkce vyhodila nějakou chybu, protože jsem se překlpl. Spustu věcí nemusím dělat. Kód je kratší a přímočařejší.Kód: [Vybrat]float sin(float phi) {
return 0.0;
}
Navíc z ní vůbec není patrné, zda je parametr ve stupních, radiánech nebo v jiných jednotkách. Takže i ten typ "float" je de facto špatně, protože neobsahuje sémantiku. Když tam hodíš údaj v metrech, tak to typová kontrola nepozná.
To je tím, že to je hloupě napsané. V takovém systému jde mít typ obsahující (a kontrolující) fyzikální rozměr i jednotku a činitele, takže prostě řeknu, že rozměr vstupu je 1 a výpočet upravím podle vlastností vstupu. Pak tam nepůjdou hodit metry, protože clashne rozměr. Fyzici tohle mají ve výpočtech ošetřené běžně, jen ty typy bývají divočejší, například vektorové pole.Statické typování má tu výhodu, že taková situace jednoduše neexistuje. Pokud popletu vstupy, tak to na mě zařve kompilátor. Hned! Nemusím testovat, jestli ta funkce vyhodila nějakou chybu, protože jsem se překlpl. Spustu věcí nemusím dělat. Kód je kratší a přímočařejší.Kód: [Vybrat]float sin(float phi) {
return 0.0;
}
Navíc z ní vůbec není patrné, zda je parametr ve stupních, radiánech nebo v jiných jednotkách. Takže i ten typ "float" je de facto špatně, protože neobsahuje sémantiku. Když tam hodíš údaj v metrech, tak to typová kontrola nepozná.
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...To je triviální, prostě rozhraním.
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...To je triviální, prostě rozhraním.
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...To je triviální, prostě rozhraním.
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...To je triviální, prostě rozhraním.
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.
Ano, to se blížíme tomu, co jsem chtěl naznačit. Přetíženou metodou to totiž nepůjde, protože typ výsledku známe až za běhu...Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...To je triviální, prostě rozhraním.
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Např. v Javě rozhodně nemůžu mít dvě stejné metody, pokud mají různé typy výsledku...
racionální implikuje reálný, sám sis odpověděl, co je rozhranímAno, to se blížíme tomu, co jsem chtěl naznačit. Přetíženou metodou to totiž nepůjde, protože typ výsledku známe až za běhu...Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...To je triviální, prostě rozhraním.
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Např. v Javě rozhodně nemůžu mít dvě stejné metody, pokud mají různé typy výsledku...
Pokud se liší typem parametru, tak ano. Ovšem sin(π/6) má reálný parametr, ale racionální výsledek. Také jsem zvědav, jak to staticky natypují.
Pokud se liší typem parametru, tak ano. Ovšem sin(π/6) má reálný parametr, ale racionální výsledek. Také jsem zvědav, jak to staticky natypují.racionální implikuje reálný, sám sis odpověděl, co je rozhraním
On nechtěl racionální čísla, ale zlomky, to sis tam přimyslel. pi/6 je zlomek.Pokud se liší typem parametru, tak ano. Ovšem sin(π/6) má reálný parametr, ale racionální výsledek. Také jsem zvědav, jak to staticky natypují.racionální implikuje reálný, sám sis odpověděl, co je rozhraním
V uvedeném případě je to naopak - z reálného čísla se stává racionální.
Kite, Kite. Ty kdyby si tomu aspoň rozuměl, co?Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...To je triviální, prostě rozhraním.
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.
type RatioNum = RatioNum Num
| RatioNumFract Num Num
deriving show
sin :: RatioNum -> RatioNum
sin RatioNum num = ...
sin RatioNumFract num denom = ...
print $ sin (RatioNum 5)
print $ sin (RatioNumFract 5 2)
Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Kite, Kite. Ty kdyby si tomu aspoň rozuměl, co?Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...To je triviální, prostě rozhraním.
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.Kód: [Vybrat]type RatioNum = RatioNum Num
| RatioNumFract Num Num
deriving show
sin :: RatioNum -> RatioNum
sin RatioNum num = ...
sin RatioNumFract num denom = ...
print $ sin (RatioNum 5)
print $ sin (RatioNumFract 5 2)
Kite, Kite. Ty kdyby si tomu aspoň rozuměl, co?Díky, člověk rychle zapomene, že je něco takového ve statických jazycích potřeba...Na tom příkladu se sinusem bych chtěl vidět jednu věc: chci, aby parametrem mohl být i zlomek, nejen float...To je triviální, prostě rozhraním.
A výsledek chci mít možnost obojí, podle toho, jak to vyjde, abych neztratil přesnost výpočtu. Ha?
Ve statických jazycích je nutné ho i implementovat nějakou přetíženou metodou.Kód: [Vybrat]type RatioNum = RatioNum Num
| RatioNumFract Num Num
deriving show
sin :: RatioNum -> RatioNum
sin RatioNum num = ...
sin RatioNumFract num denom = ...
print $ sin (RatioNum 5)
print $ sin (RatioNumFract 5 2)
Bavíme se o objektových jazycích. Patří mezi ně i Haskell?
A já se přitom nemusím bát, že se z nějakého podivného důvodu do nějaké pomocné funkce, která normálně dostává řetězce a volá na ně clear(), dostane jako parametr handle k databázi :)
Jestli potřebuješ staticky typovaný jazyk, aby sis byl jistý, že tvůj kód omylem nepromázne databázi, tak bys měl změnit obor. Nebo si alespoň pořídit hodně kvalitní pojistku na blbost.
Já už jsem ve svém programátorském životě viděl příliš mnoho chyb, které jsem buď sám udělal, nebo jsem je musel opravit, o nichž jsem byl přesvědčený, že nemohou nastat... :)
S trochou nadsázky - programátoři se dělí do několika podmnožin:
- Ti, kteří dělají chyby, a nevědí, co s tím.
- Ti, kteří dělají chyby, ale snaží se z nich poučit a snaží se používat nástroje, které jim pomohou chyby lépe odhalovat a odstraňovat.
- Ti, kteří nedělají chyby.
Programátoři z první podmnožiny potřebují nabrat zkušenosti nebo, když toho nejsou schopni, najít si jiný obor. Programátoři z druhé podmnožiny dávají přednost staticky typovaným jazykům, protože jim pomáhají diagnostikovat chyby. Pro programátory ze třetí podmnožiny jsou lepší dynamicky typované jazyky, protože je nebrzdí v tvůrčím rozletu. Drobný problém je, že třetí podmnožina je prázdná.
Je to ošetřený a rozhodnutý v době překladu. To je to co mě zajímá.Nevím, jestli jsme si tady rozuměli. V době překladu víš jenom to, že
1. z externího zdroje dostaneš posloupnost bajtů (vstup uživatele nebo síťový packet)
2. víš, že bys chtěl, aby ta posloupnost bajtů byl nějaký typ (např. integer zakódovaný jako string)
Jestli se tvoje "compile time přání" v run time splní nebo ne - to není nic jiného než dynamické typování.
func read_int(s: stream) -> Result<int, str> {
buf = stream.read();
if len(buf) == 8
Ok(buf.to_integer())
else
Err("Invalid size, cannot convert to integer")
}
func print_int(i: int) {
print("Valid integer {}", i)
}
func main() {
s = open_stream();
match read_int(s) {
case Ok(i) print_int(i)
case Err(s) print("Error on input: {}", s)
}
}
Tam nikde žádný dynamický typ neníA proč to žere jenom osmibajtové vstupy?!
Tam nikde žádný dynamický typ neníA proč to žere jenom osmibajtové vstupy?!
Ale nežere. Zná dva druhy vstupu, int a noise. Co nemá 8 bajtů, je noise. Způsob ošetření lze samozřejmě zvolit libovolně.Tam nikde žádný dynamický typ neníA proč to žere jenom osmibajtové vstupy?!
Zná dva druhy vstupu, int a noise. Co nemá 8 bajtů, je noise.No a dynamicky (až za běhu) rozhoduje o typu => je to dynamické typování.
součtové typy => dynamické typování?Zná dva druhy vstupu, int a noise. Co nemá 8 bajtů, je noise.No a dynamicky (až za běhu) rozhoduje o typu => je to dynamické typování.
součtové typy => dynamické typování?rozhodování o typu za běhu => dynamické typování
co je "rozhodování o typu"?součtové typy => dynamické typování?rozhodování o typu za běhu => dynamické typování
co je "rozhodování o typu"?Nemam potrebu se tady tahat za nohu ani hadat o pitomosti :)
tak tak, tyhle mlhavé vágní úvahy...co je "rozhodování o typu"?Nemam potrebu se tady tahat za nohu ani hadat o pitomosti :)
co je "rozhodování o typu"?součtové typy => dynamické typování?rozhodování o typu za běhu => dynamické typování
tak tak, tyhle mlhavé vágní úvahy...Nevím, co je na tom vágního. Jestliže máš nějaký vstup a podle toho, co tam přijde, se rozhoduje, jestli je to typ X nebo typ Y, tak tomu já říkám "dynamické typování". Pokud někdo ten pojem používá jinak, rád si to poslechnu. Ale nehodlám si tady hrát na kočku s myší.
co je "rozhodování o typu"?Nemam potrebu se tady tahat za nohu ani hadat o pitomosti :)
tak tak, tyhle mlhavé vágní úvahy...Nevím, co je na tom vágního. Jestliže máš nějaký vstup a podle toho, co tam přijde, se rozhoduje, jestli je to typ X nebo typ Y, tak tomu já říkám "dynamické typování". Pokud někdo ten pojem používá jinak, rád si to poslechnu. Ale nehodlám si tady hrát na kočku s myší.
v Inkvizitorově příkladu se transformuje hodnota staticky daného typu na jinou (opět staticky známého typu), žádné "rozhodování o typu" se tam neděje, stejně jako když třeba porovnáváte celá, v době překladu neznámá, číslatak tak, tyhle mlhavé vágní úvahy...Nevím, co je na tom vágního. Jestliže máš nějaký vstup a podle toho, co tam přijde, se rozhoduje, jestli je to typ X nebo typ Y, tak tomu já říkám "dynamické typování". Pokud někdo ten pojem používá jinak, rád si to poslechnu. Ale nehodlám si tady hrát na kočku s myší.
Tak dobře, třeba jsem konkrétně já nepochopil, co jsi chtěl říci původním příspěvkem. Pokud jsi chtěl ukázat, že i statický jazyk dokáže zpracovat dynamický vstup, nemám problém.Myslel jsem, že jsem to napsal celkem jasně. Možná ne. Chtěl jsem říct, že otypovat program v době překladu jde jenom tam, kde mám pod kontrolou vstupní typy (lapidárně: "vím, co mi leze dovnitř"). Pokud nevím, co mi leze dovnitř, a ukáže se to až v době běhu, pak jsem v situaci dynamického typování (aka "rozhování o typech až za běhu").
Součtový typ dokáže z různých typů udělat různé hodnoty téhož typu. Pokud si množinu možných vstupních hodnot namodeluješ součtovým typem, je Tvoje tvrzení poměrně sporné.Mno... Součtový typ je způsob, jak dva (nebo více) typů "schovat pod jeden" - je to čistě proto, že potřebuješ, aby ti z funkce lezl jenom jeden typ. Je to technikálie, nic jiného. Nic to nemění na sémantice toho programu: dovnitř ti leze něco, o čem v době překladu nic nevíš a dozvíš se to až v době běhu - a podle toho, jestli tam bude X nebo Y, půjde program větví A nebo B.
v Inkvizitorově příkladu se transformuje hodnota staticky daného typu na jinou (opět staticky známého typu), žádné "rozhodování o typu" se tam neděje, stejně jako když třeba porovnáváte celá, v době překladu neznámá, číslaJak jsem psal někde výš: "Znát typ" není nc jiného než "mít nějakou znalost o datech v tomhle místě programu". "Statické jazyky" se snaží v době překladu ze struktury programu vydedukovat co nejvíc znalostí. "Dynamické jazyky" na to rezignují a znalosti získávají až v době běhu. V tom je ten zásaní rozdíl.
co je "rozhodování o typu"?součtové typy => dynamické typování?rozhodování o typu za běhu => dynamické typování
To znamená, není předem jasně dáno, že na vstupu je osmibajtový int a nic jiného. Jakmile připustím nějaký "noise", už dynamicky rozhoduji, jaký typ dat na tom vstupu je. Když chci přečíst 512 bajtů (sektor) z disku jako zařízení (ne přes FS), tak staticky říkám, že chci načíst přesně 512 bajtů a v bufferu očekávám 512 platných bajtů. Z FS může přijít i kratší záznam s uvedenou délkou, ale to už je dynamický typ.
v Inkvizitorově příkladu se transformuje hodnota staticky daného typu na jinou (opět staticky známého typu), žádné "rozhodování o typu" se tam neděje, stejně jako když třeba porovnáváte celá, v době překladu neznámá, číslaJak jsem psal někde výš: "Znát typ" není nc jiného než "mít nějakou znalost o datech v tomhle místě programu". "Statické jazyky" se snaží v době překladu ze struktury programu vydedukovat co nejvíc znalostí. "Dynamické jazyky" na to rezignují a znalosti získávají až v době běhu. V tom je ten zásaní rozdíl.
Když použiju součtový typ "StringVal String | IntVal Int", tak tím jenom dávám překladači najevo, že vím, že v tomhle místě programu se za běhu objeví buď integer nebo string. Dynamický jazyk vlastně říká totéž: v tomhle (každém) místě programu nevím, co za běhu bude: int, string, list, ...
to je dost zúžený výklad, typ můžou mít i "věci", které nemají žádnou hodnotu/nepředstavují datav Inkvizitorově příkladu se transformuje hodnota staticky daného typu na jinou (opět staticky známého typu), žádné "rozhodování o typu" se tam neděje, stejně jako když třeba porovnáváte celá, v době překladu neznámá, číslaJak jsem psal někde výš: "Znát typ" není nc jiného než "mít nějakou znalost o datech v tomhle místě programu".
Když použiju součtový typ "StringVal String | IntVal Int", tak tím jenom dávám překladači najevo, že vím, že v tomhle místě programu se za běhu objeví buď integer nebo string. Dynamický jazyk vlastně říká totéž: v tomhle (každém) místě programu nevím, co za běhu bude: int, string, list, ...no ano, stacký jazyk - jeden algebraický typ, dynamický - cokoliv
no ano, stacký jazyk - jeden algebraický typ, dynamický - cokoliv
mohl by sis vytvořit součtový typ, který by obsáhl všechny typy. Nazvěme takový typ Super. Všechny funkce nechť potom mají typ Super -> Super. Byl by takový jazyk/program podle tebe "statický" nebo "dynamický"?čili, pokud bysme chtěli slovíčkařit: statický jazyk: jeden algebraický typ. Dynamický jazyk: jeden algebraický typ (pod kterým jsou "schované" všechny možné).
to je dost zúžený výklad, typ můžou mít i "věci", které nemají žádnou hodnotu/nepředstavují dataNeplodné slovíčkaření.
překrucujete tono ano, stacký jazyk - jeden algebraický typ, dynamický - cokolivmohl by sis vytvořit součtový typ, který by obsáhl všechny typy. Nazvěme takový typ Super. Všechny funkce nechť potom mají typ Super -> Super. Byl by takový jazyk/program podle tebe "statický" nebo "dynamický"?čili, pokud bysme chtěli slovíčkařit: statický jazyk: jeden algebraický typ. Dynamický jazyk: jeden algebraický typ (pod kterým jsou "schované" všechny možné).
viz např. "phantom types"to je dost zúžený výklad, typ můžou mít i "věci", které nemají žádnou hodnotu/nepředstavují dataNeplodné slovíčkaření.
překrucujete toNic nepřekrucuju. Celou dobu říkám jenom to, že nějaké "světodějné" rozlišování mezi statickými a dynamickými jazyky je iluze (falešné dilema). Jedná se totiž jenom o množství informací, které o datech mám - a to je na kontinuu, není to binární "statický ví vždycky všechno v compile time" vs. "dynamický neví v compile time nikdy nic". Statické jazyky občas něco neví (a tím se v té části programu přiblíží k dynamickému) a dynamické občas mají možnost použít třeba anotaci (a tím se v té části programu přiblíží ke statickému).
dá se říct, že dynamický jazyk má jeden součtový typ pro všechny hodnoty (Robert Harper, "unityped"), statický umí rozlišit více typů u různých částí programu (třeba funkcí)
viz např. "phantom types"Neplodné slovíčkaření.
jenom se snažím vyhnout mlhavým vágním pojmům
Statické jazyky občas něco nevíNo jo, ale uvádíš blbej příklad.
Zatímco příklad parsováním vstupu je naopak situace, kdy ten jazyk ví všechno.Neví, jestli výpočet půjde cestou A nebo B, to se rozhodne až za běhu.
Tak dobře, třeba jsem konkrétně já nepochopil, co jsi chtěl říci původním příspěvkem. Pokud jsi chtěl ukázat, že i statický jazyk dokáže zpracovat dynamický vstup, nemám problém.Myslel jsem, že jsem to napsal celkem jasně. Možná ne. Chtěl jsem říct, že otypovat program v době překladu jde jenom tam, kde mám pod kontrolou vstupní typy (lapidárně: "vím, co mi leze dovnitř"). Pokud nevím, co mi leze dovnitř, a ukáže se to až v době běhu, pak jsem v situaci dynamického typování (aka "rozhování o typech až za běhu").Součtový typ dokáže z různých typů udělat různé hodnoty téhož typu. Pokud si množinu možných vstupních hodnot namodeluješ součtovým typem, je Tvoje tvrzení poměrně sporné.Mno... Součtový typ je způsob, jak dva (nebo více) typů "schovat pod jeden" - je to čistě proto, že potřebuješ, aby ti z funkce lezl jenom jeden typ. Je to technikálie, nic jiného. Nic to nemění na sémantice toho programu: dovnitř ti leze něco, o čem v době překladu nic nevíš a dozvíš se to až v době běhu - a podle toho, jestli tam bude X nebo Y, půjde program větví A nebo B.
Dalo by se argumentovat i jinak: mohl by sis vytvořit součtový typ, který by obsáhl všechny typy. Nazvěme takový typ Super. Všechny funkce nechť potom mají typ Super -> Super. Byl by takový jazyk/program podle tebe "statický" nebo "dynamický"?
Ano. Což ale pro naše potřeby není vůbec důležitá informace. Ví všechno potřebné (, když tedy slovíčkaříš).Zatímco příklad parsováním vstupu je naopak situace, kdy ten jazyk ví všechno.Neví, jestli výpočet půjde cestou A nebo B, to se rozhodne až za běhu.
dávám překladači najevo, že vím, že v tomhle místě programu se za běhu objeví buď integer nebo string. Dynamický jazyk vlastně říká totéž: v tomhle (každém) místě programu nevím, co za běhu bude: int, string, list, ...
Pokud porovnáváš tuto nerozhodnost, s tupostí dynamických jazyků, tak ti udělám radost, a nebudu už v diskusi pokračovat :-PNe. Jenom říkám, že je to "kontinuum tuposti", přičemž není pravda, že "statické jazyky" jsou vždycky a ve všech situacích úplně vlevo a dynamické vždycky úplně v pravo. Různé jazyky se v různých situacích na tom kontinuu objevují na různých místech.
nemá ani dědičnost (tedy žádné Super)Jestli tímhle reaguješ na to mnou zmíněné Super, tak jsi vůbec nepochopil, co jsem se snažil říct (netvrdím, že je to tvoje chyba).
Je docela rozdíl mezi "vím, že tady je string nebo int" a "vím, že tady je nějaká hodnota libovolného typu".Ano. Ale rozdíl mezi tím, kdy nevím, jestli je to jeden ze dvou typů nebo jeden za čtyř nebo jeden z dvaceti sedmi (kolik jich je v Pythonu?), je kvantitaivní, ne kvalitativní.
Kecy. Sebedokonalejší typový systém za tebe kvalitní kód nevyrobí, prasit se dá v čemkoli. Mnohem více záleží na znalostech, zkušenosti a disciplíně(!) programátora. Sám jsem sice ve své víc než dvacetileté profesní praxi vždy pracoval převážně se staticky typovanými jazyky, ale nevidím ve statickém typování nijak velký přínos, co se týká bezpečnosti a vůbec kvality kódu. Způsob typování představuje jen jeden střípek ve škále vlastností jazyka a v praxi je to nakonec stejně hlavně o člověku, jeho schopnostech a přístupu, ne o nástroji. Nástroj je jen tak dobrý, jak dobrý je jeho uživatel. Kromě toho je zjevné, že dynamické a dynamicky typované jazyky si našly svou niku, ve které se prosadily, a je známkou arogance (nebo hlouposti či nezkušenosti) je jen tak spatra shazovat jako jazyky pro fušery. Ale když černobílé uvažování je tak pohodlné, že?
mě snad jebne!!!Ultimátní argument ke zkvalitnění diskuse.
Ano. Ale rozdíl mezi tím, kdy nevím, jestli je to jeden ze dvou typů nebo jeden za čtyř nebo jeden z dvaceti sedmi (kolik jich je v Pythonu?), je kvantitaivní, ne kvalitativní.
Kecy. Sebedokonalejší typový systém za tebe kvalitní kód nevyrobí, prasit se dá v čemkoli. Mnohem více záleží na znalostech, zkušenosti a disciplíně(!) programátora. Sám jsem sice ve své víc než dvacetileté profesní praxi vždy pracoval převážně se staticky typovanými jazyky, ale nevidím ve statickém typování nijak velký přínos, co se týká bezpečnosti a vůbec kvality kódu. Způsob typování představuje jen jeden střípek ve škále vlastností jazyka a v praxi je to nakonec stejně hlavně o člověku, jeho schopnostech a přístupu, ne o nástroji. Nástroj je jen tak dobrý, jak dobrý je jeho uživatel. Kromě toho je zjevné, že dynamické a dynamicky typované jazyky si našly svou niku, ve které se prosadily, a je známkou arogance (nebo hlouposti či nezkušenosti) je jen tak spatra shazovat jako jazyky pro fušery. Ale když černobílé uvažování je tak pohodlné, že?
Počuli ste slovo Božie... Všetci čo tu vediete tie jalové debaty o typoch si toto vytlačte a zarámujte. V deň v ktorý tento text pochopíte, sa aj vy stanete programátormi. Dovtedy ste lopaty s plnou hubou rádoby odborných kecov.
Ale už když se přidají struktury (v C), třídy (v C++ nebo Javě), nebo se jako struktura použije hash (v Perlu) nebo dictionary (v Pythonu), tak těch typů je nekonečně (spočetně).C, C++ ani Java nejsou dynamické jazyky. A zcela záměrně jsem řekl Python. Python nemá parametrizovaný typ dictionary<K,V>, má jeden typ dictionary. Perl (zcela vědomě a záměrně) vůbec neznám.
Jestli to je kvantitativní nebo kvalitativní rozdíl je námět na dlouhou neplodnou filozofickou diskusi.Souhlas.
Ale už když se přidají struktury (v C), třídy (v C++ nebo Javě), nebo se jako struktura použije hash (v Perlu) nebo dictionary (v Pythonu), tak těch typů je nekonečně (spočetně).C, C++ ani Java nejsou dynamické jazyky. A zcela záměrně jsem řekl Python. Python nemá parametrizovaný typ dictionary<K,V>, má jeden typ dictionary. Perl (zcela vědomě a záměrně) vůbec neznám.
Skoro bych tipoval, že většina dynamických jazyků bude mít spíš konečný počet typů, protože tam pro parametrizaci není tak silný důvod jako u statických jazyků.
Takových typů je nekonečno.Ano, takových typů je nekonečně mnoho, ale dynamické jazyky takové typy nemají, protože je nepotřebují. Statické jazyky je mají, protože potřebují nějak označit, co "z pole vyleze". Proto pokud potřebuju v dynamickém jazyce nějak reagovat na "všechny typy", není jich zas tak moc.
Myslel jsem to tak, že často používaný typ je "record", tedy množina pojmenovaných položek, kde počet, jména a typy položek jsou součástí definice typu. V C to je struct, v C++ nebo v Javě to je class. V jazycích, které mají asociativní pole (dictionary v Pythonu, hash v Perlu) se typ record implementuje pomocí asociativního pole, které má konstatní množinu klíčů (ať už lze prostředky jazyka tuto konstantnost vynutit, nebo ne). Takových typů je nekonečno. Statická typová kontrola mi umožňuje definovat, že v konkrétním místě programu se smí vyskytovat pouze konkrétní (konečná nebo nekonečná) podmnožina všech možných typů. Při dynamickém typování se musím být schopen v každém místě umět vypořádat s kterýmkoliv z celé nekonečné množiny všech možných typů.
Takových typů je nekonečno.Ano, takových typů je nekonečně mnoho, ale dynamické jazyky takové typy nemají, protože je nepotřebují. Statické jazyky je mají, protože potřebují nějak označit, co "z pole vyleze". Proto pokud potřebuju v dynamickém jazyce nějak reagovat na "všechny typy", není jich zas tak moc.
Taková reprezentace dat je v dynamických jazycích potřeba úplně stejně.Není.
Python má historicky dva různé způsoby vytváření "recordu" - dictionary (pohodlnější) a class (těžkopádnější, ale systémovější). V poslední době přišly dvě novinky - named tuple a dataclass, protože prostě ani dictionary (nejdynamičtější řešení z dynamických) ani "normální" třída nejsou zase tak moc super.To všechno je ale pod kapotou netypovaný dict. viz x.__dict__
To je, spolu s dalšími změnami včetně anotací typů odpověď vývojářů jazyka na otázku, zda by se příklon ke statickým programovacím jazykům přece jenom občas nehodil.Příklon ke statičnosti se hodí vždycky, to může popírat jenom někdo s hodně velkýma klapkama na očích.
To všechno je ale pod kapotou netypovaný dict. viz x.__dict__On možná lepší příklad než Python by byl JS nebo Lua...
Proto pokud potřebuju v dynamickém jazyce nějak reagovat na "všechny typy", není jich zas tak moc.To je sice možné, ale když si mám vybrat mezi: kontrolovat, zda přišel správný typ, a pokud ne, tak chcípnout; a mezi tím, že vždy přijde správný typ...
To je sice možné, ale když si mám vybrat mezi: kontrolovat, zda přišel správný typ, a pokud ne, tak chcípnout; a mezi tím, že vždy přijde správný typ...Souhlasím, ale to jsi skočil do jiného tématu. My jsme pořád ještě u toho, že dynamické typování je vlastně jenom takový "trochu širší" součtový typ :)
To je, spolu s dalšími změnami včetně anotací typů odpověď vývojářů jazyka na otázku, zda by se příklon ke statickým programovacím jazykům přece jenom občas nehodil.Příklon ke statičnosti se hodí vždycky, to může popírat jenom někdo s hodně velkýma klapkama na očích.
Proto pokud potřebuju v dynamickém jazyce nějak reagovat na "všechny typy", není jich zas tak moc.To je sice možné, ale když si mám vybrat mezi: kontrolovat, zda přišel správný typ, a pokud ne, tak chcípnout; a mezi tím, že vždy přijde správný typ...
Pardon :-)To je sice možné, ale když si mám vybrat mezi: kontrolovat, zda přišel správný typ, a pokud ne, tak chcípnout; a mezi tím, že vždy přijde správný typ...Souhlasím, ale to jsi skočil do jiného tématu. My jsme pořád ještě u toho, že dynamické typování je vlastně jenom takový "trochu širší" součtový typ :)
Já si myslím, že není. Protože dynamické typování je úplně jiná (samozřejmě špatná) filozofie programování. Ale nerad bych se opakoval. :-)To se nevylučuje. Používat v celém programu takhle široký součtový typ je úplně jiná (podle někoho samozřejmě špatná) filosofie programování ;)
Já si myslím, že není. Protože dynamické typování je úplně jiná (samozřejmě špatná) filozofie programování. Ale nerad bych se opakoval. :-)To se nevylučuje. Používat v celém programu takhle široký součtový typ je úplně jiná (podle někoho samozřejmě špatná) filosofie programování ;)
type Person = {name: String, surname: String, age: Int}
parsePerson(s: String) : Maybe Person = ...
str.concat (a: String, b: String) = ...
readIO(io) =
case (parsePerson(io.read())):
Just x -> console.log str.concat("person: ", x)
Nothing -> console.error "Je třeba definice Person."
Dá se to zapsat v statickém i dynamickém jazyce. V obou použiju stejný druh typu. Dokonce stejnou konstrukci (ač u dynamických jazyků jsou obvyklejší výjimky). Jenže dynamický jazyk tu chybu pustí.Jenže dynamický jazyk tu chybu pustí.
Asi se už dost opakujeme, ale tak co už :) Ve všem souhlas, jenom tomuhle nerozumím:Jenže dynamický jazyk tu chybu pustí.
V dynamickém jazyce bude výsledkem parsePerson buď hodnota typu Person nebo výjimka, ve statickém buď Just Person nebo Nothing. Nevidím tam žádný zásadní "světodějný" rozdíl. Jediný rozdíl, který tam vidím (a souhlasím, že je docela podstatný), je, že statický jazyk tě donutí obě varianty explicitně ošetřit, zatímco dynamický tě klidně nechá výjimku nechat probublat až do main a nechat program spadnout v produkci :)
V tom řádku s Just je právě schválně chyba. Kde statický jazyk si "všimne" při překladu, že x není string. To považuju za dost "světodějný".Ajo, promiň, toho jsem si nevšiml. Ale co tím demonstruješ? Jenom to, že statické jazyky umí některé chyby odhalit už v době překladu. To ale přece všichni víme, ne?!
def some_func_anywhere():
return 1 + "x"
- Python ti tohle ochotně pustí do produkce i když by to krásně mohl odhalit. No, je to tak, dělá míň práce, než by mohl :)
Asi se už dost opakujeme, ale tak co už :) Ve všem souhlas, jenom tomuhle nerozumím:Jenže dynamický jazyk tu chybu pustí.V dynamickém jazyce bude výsledkem parsePerson buď hodnota typu Person nebo výjimka, ve statickém buď Just Person nebo Nothing. Nevidím tam žádný zásadní "světodějný" rozdíl. Jediný rozdíl, který tam vidím (a souhlasím, že je docela podstatný), je, že statický jazyk tě donutí obě varianty explicitně ošetřit, zatímco dynamický tě klidně nechá výjimku nechat probublat až do main a nechat program spadnout v produkci :)
Nevidím důvod, proč by v dynamicky typovaném jazyce měla aplikace padat v produkci. Ovšem pokud někdo píše testy jen podle metrik...Mohl úplně jednoduše na otestování nějakého edge casu zapomenout. Probublal mu None někam, kde správně neměl být povolený, uložilo se to na disk, nikdo na ty data deset let nešáhl a nikdo už dneska neví, že tam kdysi None být mohl.
A proč to demonstrovat tak krkolomně? Stačilo úplně:Kód: [Vybrat]def some_func_anywhere():
- Python ti tohle ochotně pustí do produkce i když by to krásně mohl odhalit. No, je to tak, dělá míň práce, než by mohl :)
return 1 + "x"
File "list.py", line 11, in some_func_anywhere
return 1 + "x"
TypeError: unsupported operand type(s) for +: 'int' and 'str'
Nepustí:No dobře, tak ten string bude trochu víc zakuklenej no. Třeba do atributu.
Ajo, promiň, toho jsem si nevšiml. Ale co tím demonstruješ? Jenom to, že statické jazyky umí některé chyby odhalit už v době překladu. To ale přece všichni víme, ne?!
Pokoušel jsem se na ladit ne ten váš problém, co řešíte. Evidentně se mi to nepovedlo :-)Ne, nepovedlo :) Pointa je v tom, že v obou systémech se program větví na základě typu a v obou k tomu dojde až za běhu.
Ne, nepovedlo :) Pointa je v tom, že v obou systémech se program větví na základě typu a v obou k tomu dojde až za běhu.Ale jen u toho dynamického dojde za běhu k tomu "vymejšlení". (Což je ale také věc, kde záleží na tom, jak se to vezme.)
pustí i bez kuklyNepustí:No dobře, tak ten string bude trochu víc zakuklenej no. Třeba do atributu.
>>> def some_func_anywhere():
... return 1 + "x"
...
>>> some_func_anywhere()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in some_func_anywhere
TypeError: unsupported operand type(s) for +: 'int' and 'str'
>>>
Tak jinak - jak by podle tebe vypadala implementace polymorfismu tak, jak je chápán v objektovém paradigmatu, prostředky (nikoli jejich obcházením) staticky typovaného prostředí?V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.
Už to tu psal tuším p. Prýmek: Typ typování souvisí jen okrajově s polymorfismem - typovaný systém vede pouze na užší vyhledávání metody na straně obeslaného objektu dle typů ve zprávě, nic víc. Nepleťte si to s prasojazyky Java a C#, kdy jejich problémem není samotné typování, ale tzv. podtypový polymorfismus jako prostředek realizace časné vazby znemožňující kamarádění objektů (instancí) typově (třídně) nepříbuzných.
(dle pravidla Liskovové).A ještě lepší by bylo tam podtypový polymorfismus vůbec nemít, ušetřili bysme si spoustu bolehlavů ;)
Tak to máte docela nízké požadavky na kvalitu. Python je sice syntakticky přehledný a má dost knihoven, takže se v něm rychle dělá, ale ZCELA ZBYTEČNĚ obsahuje neobjektové konstrukce (len(řetězec), ...), na zapouzdření dlabe (přestože implementace by pravděpodobně ani nebyla složitá), definice třídních metod je řešena nekoncepčně přes jakési anotace... To mě napadá jen tak z hlavy, na co jsem stihnul zběžně narazit.Neobjektové konstrukce nejsou zbytečné, python není oop jazyk, ale hybridní. Jestli mu neco vycist, tak to, ze by default krome len(list) neumi i list.len(). Zapouzdreni ma. Proc povazujete dekoratory za nekoncepcni? Python nepouziva modifikujici klicova slova, ale obecneji fungujici a uzivatelsky nastavitelne dekorarory, coz je koncept.
To všechno je ale pod kapotou netypovaný dict. viz x.__dict__Ne že by to v diskusi bylo podstatné, ale ne vše je zakuklený dict, viz __slots__ (ono pro malé třídy je dict dost overkill).
Ne že by to v diskusi bylo podstatné, ale ne vše je zakuklený dict, viz __slots__ (ono pro malé třídy je dict dost overkill).To je ale jenom optimalizace, která pro to, o čem se bavíme, nejenom že není podstatná, ale nemá to vůbec žádný vliv.
Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.Smysl statických typů je zajistit, aby se něco takového nestalo. Když zůstaneme u přirovnání, tak ty budeš muset hostinského zaškolit, a ještě nainstalovat kameru, aby si ho sledoval, zda nečepuje pivo přímo do pusy. A stejně ho neuhlídáš. Zatímco já tam budu moct dát cedulku "samoobslužná pípa".
Pak samozřejmě můžeš dojít k závěru, že nevíš, a že tam chceš dát cokoliv. Tak dáš typ *, a budeš tam moct uložit opravdu cokoliv.
Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???Proč je tam to "ne nutně"? Pokud chci zjistit, jestli se mi tam vlezou, pak musí na ty zprávu odpovídat nutně, jinak nemůžu rozhodnout, jestli se mi tam vlezou.
Ale ne. Dle principu sebeodpovědnosti objektu každý objekt definuje uspořádání (např. isLessThan:), metodě sort už pak stačí je obecně a polymorfně ověřovat pro jednotlivé páry, aniž by o nich musela cokoliv vědět.
Dokud ti staci jedno usporadani...
Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.Smysl statických typů je zajistit, aby se něco takového nestalo. Když zůstaneme u přirovnání, tak ty budeš muset hostinského zaškolit, a ještě nainstalovat kameru, aby si ho sledoval, zda nečepuje pivo přímo do pusy. A stejně ho neuhlídáš. Zatímco já tam budu moct dát cedulku "samoobslužná pípa".
Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.
Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???
jedna z obecnějších možností:Kód: [Vybrat]{-# LANGUAGE ExistentialQuantification, ConstraintKinds, GADTs #-}
data Ex c = forall x. c x => Ex x
instance x ~ Show => Show (Ex x) where
show (Ex x) = show x
xxx :: [Ex Show]
xxx = [Ex (), Ex 2, Ex "3"]
main = print xxx
Pak samozřejmě můžeš dojít k závěru, že nevíš, a že tam chceš dát cokoliv. Tak dáš typ *, a budeš tam moct uložit opravdu cokoliv.
Vizte můj příspěvek dříve: Není problémem vytvořit seznam s prvky typu objekt a najebat do něj cokoliv, problémem je potom nad tímto seznamem spustit sumu na vlastnost "cena" nebo "objem". Jak se to udělá v statickém jazyku?
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Kód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
...Ale type-hinting bude furt slabej proti plnohodnotnému statickému systému.
Tak to máte docela nízké požadavky na kvalitu. Python je sice syntakticky přehledný a má dost knihoven, takže se v něm rychle dělá, ale ZCELA ZBYTEČNĚ obsahuje neobjektové konstrukce (len(řetězec), ...), na zapouzdření dlabe (přestože implementace by pravděpodobně ani nebyla složitá), definice třídních metod je řešena nekoncepčně přes jakési anotace... To mě napadá jen tak z hlavy, na co jsem stihnul zběžně narazit.Neobjektové konstrukce nejsou zbytečné, python není oop jazyk, ale hybridní. Jestli mu neco vycist, tak to, ze by default krome len(list) neumi i list.len(). Zapouzdreni ma. Proc povazujete dekoratory za nekoncepcni? Python nepouziva modifikujici klicova slova, ale obecneji fungujici a uzivatelsky nastavitelne dekorarory, coz je koncept.
A jaký má smysl zavádět imperativní konstrukce s objekty, jestliže je to bez přínosu a komplikuje to jazyk i jeho implementaci?
Opravdu se tu nehodlám dohadovat s někým, co je to zapouzdření a zda jej má Python, OPRAVDU NE!
Proč tedy není i u instanční metody anotace "@instancemethod"?
Funkce get_peer_address() je buď metoda třídy network_socket bez parametrů, nebo je to samostatná funkce (nebo klidně metoda třídy address_extractor) s jedním parametrem typu network_socket.
Návratová hodnota je typu socket_address, což je polymorfní typ zahrnující IPv4, IPv6 i řetězce (používané jako jména UNIX domain socketů).
Testy už píšu jen na ověření chování této funkce se smysluplnými typy parametrů.
K tomu mě napadá akademická otázka: Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?
Fakt nechápu, co tu řešíte. Když vemu ten úžasný Python, tak pokud mám methodu:Kód: [Vybrat]def get_record(self, data):
Tak co ta metoda vrací? A co jí mám poslat? Fakt někdo chce takový jazyk používat na víc než na hraní a skriptíky?
Tak především jste v uvedeném případě udělal jednu z nejzákladnějších a nejhorších chyb v psaní kódu (standard většiny "vývojářů"), to je, že jste špatně pojmenoval jak metodu, tak její druhý parametr nicneříkajícím označením. A jestli si myslíte, že typovaně
Propocet get_record(Object self, Integer data)
to bude lepší, tak se mýlíte.
K tomu mě napadá akademická otázka: Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?
Přeloženo: Dá se mechanismus statické kontroly nahradit jiným mechanismem statické kontroly, aniž by byl tomu prvnímu podobný? (Jestli jsem to správně pochopil, předpokládá se formální kontrola zdrojáku, ne běhová.)
Jaký má daná snaha smysl?
(dle pravidla Liskovové).A ještě lepší by bylo tam podtypový polymorfismus vůbec nemít, ušetřili bysme si spoustu bolehlavů ;)
Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???Proč je tam to "ne nutně"? Pokud chci zjistit, jestli se mi tam vlezou, pak musí na ty zprávu odpovídat nutně, jinak nemůžu rozhodnout, jestli se mi tam vlezou.
Pak taky není pravda to "netypový" a "nezajímá mě, co to je". "Netypový" by znamenalo, že o těch objektech nemám vůbec žádnou informaci. Já ale nějakou mám: odpovídají na zprávu "hmotnost" a "velikost". To je typ. (Odbočka: ) Přesvědčení, že to typ není, vychází imho z internalizace zparchantělého OOP založeného jenom na dědičnosti.
Jak by se to vyřešilo? Snadno. Už víme, že ty objekty mají nějaký typ. Stačí ho pojmenovat (např. HasWeightAndDimension) a pak už snadno můžu říct, že pracuju s polem HasWeightAndDimension[].
Jak to přesně technicky udělat, na to asi bude víc způsobů. Jeden konkrétní je třeba ten, který ma Go: struktury implementují rozhraní implicitně - tj. jakmile jsou pro strukturu definované všechny potřebné metody, je interface implementovaný, není potřeba to explicitně prohlašovat.
Funkce get_peer_address() je buď metoda třídy network_socket bez parametrů, nebo je to samostatná funkce (nebo klidně metoda třídy address_extractor) s jedním parametrem typu network_socket.
Jak dostane ta "samostatná funkce", nebo třída address_extractor z toho socketu tu adresu???
Návratová hodnota je typu socket_address, což je polymorfní typ zahrnující IPv4, IPv6 i řetězce (používané jako jména UNIX domain socketů).
Co je to "polymorfní typ"?
Testy už píšu jen na ověření chování této funkce se smysluplnými typy parametrů.
Jasně, když je to jen pro smysluplné typy parametrů, tak to vlastně testy ani nejsou.
K tomu mě napadá akademická otázka: Dá se pro libovolný program napsat testovací sada, která nalezne všechny chyby, jež by nalezla statická typová kontrola, a přitom nebude zahrnovat (jakkoliv zakamuflovanou) statickou typovou kontrolu?
Přeloženo: Dá se mechanismus statické kontroly nahradit jiným mechanismem statické kontroly, aniž by byl tomu prvnímu podobný? (Jestli jsem to správně pochopil, předpokládá se formální kontrola zdrojáku, ne běhová.)
Jaký má daná snaha smysl?
@ není anotace, ale dekorátor. Takovou classmethod si můžete zjednodušeně představit...
Ty "neobjektové" funkce si představte jako implementaci určitého protokolu. Díky duck typingu nemusí mít objekt miliardy metod pro všechny možné situace. Proto také můžou existovat věci jako len(), iter(), next(), ... které ho využívají. Pokud vím, že něco je kolekce, len() na to bude fungovat a určitým postupem zjistí, kolik je v ní prvků. Taky můžu udělat např. max(map(len, iterable)). max(map(lambda i: i.len(), iterable)) by bylo krkolomnější. Rubysta by namítl, že iterable.collect(&:len) je lepší, ale každý jazyk má své vlastnosti :)
Statická typová kontrola zabrání určité třídě chyb v programu, protože nepovolí použití neočekávaných typů. Pokud mají být testy plnohodnotnou náhradou, měly by všechny tyto chyby odchytit taky (nepřu se o to, že testy mohou zachytit i spoustu jiných chyb, na které naopak nestačí typová kontrola). Je mi celkem jedno, jak budou testy vypadat, ale aby odpověď nebyla triviální, neměly by zahrnovat nic, co je jen převlečená statická typová kontrola přesunutá z kompilátoru do testovacího prostředí (tedy žádná statická analýza zdrojáků s použitím typových anotací).
Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.Viděl jsi často, že by hostinský točil pivo do papírové krabice, přestože mu v tom nic nebrání? Jistě by šlo zařídit, aby se pípa odjistila jen v případě, že pod sebou detekuje konkrétně určený značkový půllitr. Mě by popadl rapl a ta pípa by letěla na smetiště hned v okamžiku, kdy by mi odmítala pustit pivo do džbánku.Smysl statických typů je zajistit, aby se něco takového nestalo. Když zůstaneme u přirovnání, tak ty budeš muset hostinského zaškolit, a ještě nainstalovat kameru, aby si ho sledoval, zda nečepuje pivo přímo do pusy. A stejně ho neuhlídáš. Zatímco já tam budu moct dát cedulku "samoobslužná pípa".
Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.
Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???
Smysl je ve flexibilite. Zadne paradigma neni objektivne lepsi nez jine a pro ruzne situace muze byt jednou vhodnejsi to a podruhe ono, v Pythonu si je lze podle potřeby vybrat a kombinovat je, zlepsuje to vyjadrovaci prostredky jazyka. To je bez pochyby prinosne a obliba Pythonu prokazuje, ze to za pripadne komplikace stoji.A jaký má smysl zavádět imperativní konstrukce s objekty, jestliže je to bez přínosu a komplikuje to jazyk i jeho implementaci?Tak to máte docela nízké požadavky na kvalitu. Python je sice syntakticky přehledný a má dost knihoven, takže se v něm rychle dělá, ale ZCELA ZBYTEČNĚ obsahuje neobjektové konstrukce (len(řetězec), ...), na zapouzdření dlabe (přestože implementace by pravděpodobně ani nebyla složitá), definice třídních metod je řešena nekoncepčně přes jakési anotace... To mě napadá jen tak z hlavy, na co jsem stihnul zběžně narazit.Neobjektové konstrukce nejsou zbytečné, python není oop jazyk, ale hybridní. Jestli mu neco vycist, tak to, ze by default krome len(list) neumi i list.len(). Zapouzdreni ma. Proc povazujete dekoratory za nekoncepcni? Python nepouziva modifikujici klicova slova, ale obecneji fungujici a uzivatelsky nastavitelne dekorarory, coz je koncept.
Opravdu se tu nehodlám dohadovat s někým, co je to zapouzdření a zda jej má Python, OPRAVDU NE!
Proč tedy není i u instanční metody anotace "@instancemethod"?
Statická typová kontrola zabrání určité třídě chyb v programu, protože nepovolí použití neočekávaných typů. Pokud mají být testy plnohodnotnou náhradou, měly by všechny tyto chyby odchytit taky (nepřu se o to, že testy mohou zachytit i spoustu jiných chyb, na které naopak nestačí typová kontrola). Je mi celkem jedno, jak budou testy vypadat, ale aby odpověď nebyla triviální, neměly by zahrnovat nic, co je jen převlečená statická typová kontrola přesunutá z kompilátoru do testovacího prostředí (tedy žádná statická analýza zdrojáků s použitím typových anotací).
Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.
Naproti tomu se mi typové anotace nelíbí, to už raději v hlavičce metody ten typ použiji. Problém však nastane, pokud jsou přípustné paranetry různých typů. U statického typování se to řeší přetěžováním, což může pro různé kombinace typů parametrů znamenat značné množství metod. U dynamického se to může vyřešit v jedné metodě.
Proč budu "určitým postupem" zjišťovat, kolik je v kolekci prvků, když se jí můžu rovnou zeptat? Oč jsou uvedené funkce jednodušší, koncepčnější a přehlednější než seznam.len(), seznam.forEach(), seznam.max(), ... Tohle se mi jeví jako zbytečný bastl za účelem lezení do zadku uživatelům zvyklým na imperativní jazyky.
Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.
Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???
To není pravda, takové metody používají buď generika, nebo rozhraní. V C++ můžu říct, že parametr je “auto”, a překladač si s tím poradí. Chyby se řeší koncepčně (Concepts TS).Statická typová kontrola zabrání určité třídě chyb v programu, protože nepovolí použití neočekávaných typů. Pokud mají být testy plnohodnotnou náhradou, měly by všechny tyto chyby odchytit taky (nepřu se o to, že testy mohou zachytit i spoustu jiných chyb, na které naopak nestačí typová kontrola). Je mi celkem jedno, jak budou testy vypadat, ale aby odpověď nebyla triviální, neměly by zahrnovat nic, co je jen převlečená statická typová kontrola přesunutá z kompilátoru do testovacího prostředí (tedy žádná statická analýza zdrojáků s použitím typových anotací).
Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.
Naproti tomu se mi typové anotace nelíbí, to už raději v hlavičce metody ten typ použiji. Problém však nastane, pokud jsou přípustné paranetry různých typů. U statického typování se to řeší přetěžováním, což může pro různé kombinace typů parametrů znamenat značné množství metod. U dynamického se to může vyřešit v jedné metodě.
Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.
Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???
Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?
Typove anotace jsou dobra pomucka, svuj smysl maji treba u verejneho rozhrani. Vyhodou u nich je, ze nejsou povinne, takze je programator je nemusi otrocky pouzivat tam, kde nemaji smysl nebo dokonce program zbytecne komplikuji.
Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.
Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???
Tak v tom případě nemáš vůbec žádný problém, napiš si to třeba v Go, je to poučné.Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.
Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???
Mám je na seznamu věcí, které chci do toho batohu dát. Předměty, které to rozhraní nesplní, však do toho batohu dávat nebudu. Pokud ten seznam obsahuje takové nesmysly, tak to ještě nemusí znamenat, že ten seznam zahodím a prohlásím, že nikam nejedu.
Mám je na seznamu věcí, které chci do toho batohu dát. Předměty, které to rozhraní nesplní, však do toho batohu dávat nebudu. Pokud ten seznam obsahuje takové nesmysly, tak to ještě nemusí znamenat, že ten seznam zahodím a prohlásím, že nikam nejedu.Tak v tom případě nemáš vůbec žádný problém, napiš si to třeba v Go, je to poučné.
@ není anotace, ale dekorátor. Takovou classmethod si můžete zjednodušeně představit...
Je mi buřt, jak se to jmenuje (dekorátor je pro mě návrhový vzor), vnitřní implementace je nepodstatná. Představoval bych si, že vedle klíčového slova def tu bude např. classdef, aby bylo jasné, co je definováno na třídní a co na instanční straně. Tyto anotace/dekorátory na mě dělají dojem dobastlovaného jazyku.Ty "neobjektové" funkce si představte jako implementaci určitého protokolu. Díky duck typingu nemusí mít objekt miliardy metod pro všechny možné situace. Proto také můžou existovat věci jako len(), iter(), next(), ... které ho využívají. Pokud vím, že něco je kolekce, len() na to bude fungovat a určitým postupem zjistí, kolik je v ní prvků. Taky můžu udělat např. max(map(len, iterable)). max(map(lambda i: i.len(), iterable)) by bylo krkolomnější. Rubysta by namítl, že iterable.collect(&:len) je lepší, ale každý jazyk má své vlastnosti :)
Nechápu. Proč budu "určitým postupem" zjišťovat, kolik je v kolekci prvků, když se jí můžu rovnou zeptat? Oč jsou uvedené funkce jednodušší, koncepčnější a přehlednější než seznam.len(), seznam.forEach(), seznam.max(), ... Tohle se mi jeví jako zbytečný bastl za účelem lezení do zadku uživatelům zvyklým na imperativní jazyky.
Pak samozřejmě můžeš dojít k závěru, že nevíš, a že tam chceš dát cokoliv. Tak dáš typ *, a budeš tam moct uložit opravdu cokoliv.
Vizte můj příspěvek dříve: Není problémem vytvořit seznam s prvky typu objekt a najebat do něj cokoliv, problémem je potom nad tímto seznamem spustit sumu na vlastnost "cena" nebo "objem". Jak se to udělá v statickém jazyku?
Bez typové kontroly. V C++, Go, ObjC nebo Swiftu to máš stejně flexibilní a s kontrolou.Mám je na seznamu věcí, které chci do toho batohu dát. Předměty, které to rozhraní nesplní, však do toho batohu dávat nebudu. Pokud ten seznam obsahuje takové nesmysly, tak to ještě nemusí znamenat, že ten seznam zahodím a prohlásím, že nikam nejedu.Tak v tom případě nemáš vůbec žádný problém, napiš si to třeba v Go, je to poučné.
Totéž si mohu napsat i v PHP, Pythonu nebo některém z mnoha dalších dynamicky typovaných jazyků.
V tom řádku s Just je právě schválně chyba. Kde statický jazyk si "všimne" při překladu, že x není string. To považuju za dost "světodějný".Ajo, promiň, toho jsem si nevšiml. Ale co tím demonstruješ? Jenom to, že statické jazyky umí některé chyby odhalit už v době překladu. To ale přece všichni víme, ne?!
A proč to demonstrovat tak krkolomně? Stačilo úplně:Kód: [Vybrat]def some_func_anywhere():
- Python ti tohle ochotně pustí do produkce i když by to krásně mohl odhalit. No, je to tak, dělá míň práce, než by mohl :)
return 1 + "x"
~ $ cat tt.py
def some_func_anywhere():
"""
Function raise TypeError exception.
>>> some_func_anywhere()
Traceback (most recent call last):
...
TypeError: unsupported operand type(s) for +: 'int' and 'str'
"""
return 1 + "x"
if __name__ == '__main__':
import doctest
print(doctest.testmod())
~ $ python tt.py
TestResults(failed=0, attempted=1)
Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.
To je samozřejmě hloupost a realita je přesně opačná, bez testů se neobejdeme, bez _statických_ typů ano. Statické typy mají jediné opodstatnění, výkon. Ve všem ostatním jsou nahraditelné.Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.
Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat.
mne by treba zajimalo proc se dynamicke jazyky zatim neprosadily u life saving real time mission criticial systems, ktere se nejspis vyvijeji jen v silne typovych jazycich, napr. v Ade resp. v jazycich ktere jsou jeji podmnozinouDoporucuji neplest si silne a staticke typovani.
https://en.wikipedia.org/wiki/Ada_(programming_language (https://en.wikipedia.org/wiki/Ada_(programming_language))
https://en.wikipedia.org/wiki/SPARK_(programming_language (https://en.wikipedia.org/wiki/SPARK_(programming_language))
https://en.wikipedia.org/wiki/Ravenscar_profile (https://en.wikipedia.org/wiki/Ravenscar_profile)
nebo je to jinak ?
Python má historicky dva různé způsoby vytváření "recordu" - dictionary (pohodlnější) a class (těžkopádnější, ale systémovější). V poslední době přišly dvě novinky - named tuple a dataclass, protože prostě ani dictionary (nejdynamičtější řešení z dynamických) ani "normální" třída nejsou zase tak moc super.To všechno je ale pod kapotou netypovaný dict. viz x.__dict__
mne by treba zajimalo proc se dynamicke jazyky zatim neprosadily u life saving real time mission criticial systems, ktere se nejspis vyvijeji jen v silne typovych jazycich, napr. v Ade resp. v jazycich ktere jsou jeji podmnozinouJá tuším, že to bude tím, že implementace těch jazyků, které se pro to nepoužívají, mají nedeterministický GC. Pokud navíc běží VM pouze v jednom vlákně, tak to je problém. Ale není to proto, že jde o dynamické jazyky...
https://en.wikipedia.org/wiki/Ada_(programming_language (https://en.wikipedia.org/wiki/Ada_(programming_language))
https://en.wikipedia.org/wiki/SPARK_(programming_language (https://en.wikipedia.org/wiki/SPARK_(programming_language))
https://en.wikipedia.org/wiki/Ravenscar_profile (https://en.wikipedia.org/wiki/Ravenscar_profile)
nebo je to jinak ?
~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys
def undo(name):
undo.data[name].pop(-1)
return undo.data[name][-1]
undo.data = {}
def history(frame, event, arg):
for name,val in frame.f_locals.items():
if name not in undo.data:
undo.data[name] = []
else:
if undo.data[name][-1] is val:
continue
undo.data[name].append(val)
return history
def main():
for i in range(5):
var1 = i
var2 = str(i)
print "var1:", var1
var1 = undo('var1')
var1 = undo('var1')
print "var1 after undo:", var1, type(var1)
print "var2:", var2
var2 = undo('var2')
var2 = undo('var2')
print "var2 after undo:", var2, type(var2)
if __name__ == '__main__':
sys.settrace(history)
main()
sys.settrace(None)
Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?Kód: [Vybrat]~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys
def undo(name):
undo.data[name].pop(-1)
return undo.data[name][-1]
undo.data = {}
def history(frame, event, arg):
for name,val in frame.f_locals.items():
if name not in undo.data:
undo.data[name] = []
else:
if undo.data[name][-1] is val:
continue
undo.data[name].append(val)
return history
def main():
for i in range(5):
var1 = i
var2 = str(i)
print "var1:", var1
var1 = undo('var1')
var1 = undo('var1')
print "var1 after undo:", var1, type(var1)
print "var2:", var2
var2 = undo('var2')
var2 = undo('var2')
print "var2 after undo:", var2, type(var2)
if __name__ == '__main__':
sys.settrace(history)
main()
sys.settrace(None)
Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat. To z mnoha důvodů většinou nejde. Proto se snažíme dokázat (rozhodnout na základě statické analýzy zdrojových textů, pro všechny možné vstupy a bez nutnosti program spouštět) aspoň něco. Statická typová analýza je jedním z nástrojů, jak dokázat aspoň některé vlastnosti programu. Jestliže nějaké tvrzení o programu dokážeme (v matematickém slova smyslu), tak si můžeme být jistí, že platí.
Na druhou stranu testy většinou žádné obecné tvrzení o programu nedokazují, protože je není možné napsat tak, aby pokryly úplně celý stavový prostor programu. Takže se spoléháme na to, že otestujeme některé speciální situace, v lepším případě zvolené "chytře", např. na základě znalosti kódu, v horším případě vybrané náhodně, v nejhorším případě vybrané systematicky špatně. Když testy neohlásí chybu, tak věříme, že je program dobře. Ale ve skutečnosti jsme jen ověřili, že nenastane chyba pro určitou (většinou malou) podmnožinu vstupů. A to ještě za předpokladu, že nějaká chyba v testu nezamaskuje přítomnost chyby v kódu.
Když mám k dispozici dva kontrolní mechanismy, které jsou do značné míry komplementární, tak se mi nezdá vhodné jeden z nich zahodit (a ještě ten s principiálně silnější vypovídací schopností) a tvářit se, že jsem zachoval stejnou úroveň kontroly.
Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?Kód: [Vybrat]~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys
def undo(name):
undo.data[name].pop(-1)
return undo.data[name][-1]
undo.data = {}
def history(frame, event, arg):
for name,val in frame.f_locals.items():
if name not in undo.data:
undo.data[name] = []
else:
if undo.data[name][-1] is val:
continue
undo.data[name].append(val)
return history
def main():
for i in range(5):
var1 = i
var2 = str(i)
print "var1:", var1
var1 = undo('var1')
var1 = undo('var1')
print "var1 after undo:", var1, type(var1)
print "var2:", var2
var2 = undo('var2')
var2 = undo('var2')
print "var2 after undo:", var2, type(var2)
if __name__ == '__main__':
sys.settrace(history)
main()
sys.settrace(None)
Ty vole co to je za hack, to doufam ze Java ani takovouto cestou neumi, fuj :D
Ano, mas pravdu, uvedl jsi kraaasnyy pripad flexibilnosti dynamicky typovaneho jazyka.
Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?Kód: [Vybrat]~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys
def undo(name):
undo.data[name].pop(-1)
return undo.data[name][-1]
undo.data = {}
def history(frame, event, arg):
for name,val in frame.f_locals.items():
if name not in undo.data:
undo.data[name] = []
else:
if undo.data[name][-1] is val:
continue
undo.data[name].append(val)
return history
def main():
for i in range(5):
var1 = i
var2 = str(i)
print "var1:", var1
var1 = undo('var1')
var1 = undo('var1')
print "var1 after undo:", var1, type(var1)
print "var2:", var2
var2 = undo('var2')
var2 = undo('var2')
print "var2 after undo:", var2, type(var2)
if __name__ == '__main__':
sys.settrace(history)
main()
sys.settrace(None)
Ty vole co to je za hack, to doufam ze Java ani takovouto cestou neumi, fuj :D
Ano, mas pravdu, uvedl jsi kraaasnyy pripad flexibilnosti dynamicky typovaneho jazyka.
To neni zadny hack, ale priklad vyuziti velmi uzitecna veci, introspekce. Mohu skrz ni kontrolovat chod programu, aniz bych zasahoval do jeho kodu a reagovat libovolne na ruzne specificke podminky. Introspekce neni nutne vlastnost jen dynamickeho jazyka, ale v dynamickem jazyku se lehce vyrovnam s tim, ze prichazum do styku s hodnotami libovolnych datovych typu.
Pamatovat si historii muze byt dobre treba k implementaci transakci a bud rollbacku nebo provest navrat do nejakeho casu. Nebo potrebujes mit triger ne na hodnotu, ale rychlost zmeny. Fantazii se meze nekladou. Logovat muzes svuj kod ale to znamenak ze ho musis upravit a bude ho to zpomalovat. Predstav si, ze chces docasne logovat nejaky kus kodu, treba nejakou funkci nebo metodu nejake tridy z nejake knihovny, do ktere ale nechces nebo nemuzes zasahovat.Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?Kód: [Vybrat]~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys
def undo(name):
undo.data[name].pop(-1)
return undo.data[name][-1]
undo.data = {}
def history(frame, event, arg):
for name,val in frame.f_locals.items():
if name not in undo.data:
undo.data[name] = []
else:
if undo.data[name][-1] is val:
continue
undo.data[name].append(val)
return history
def main():
for i in range(5):
var1 = i
var2 = str(i)
print "var1:", var1
var1 = undo('var1')
var1 = undo('var1')
print "var1 after undo:", var1, type(var1)
print "var2:", var2
var2 = undo('var2')
var2 = undo('var2')
print "var2 after undo:", var2, type(var2)
if __name__ == '__main__':
sys.settrace(history)
main()
sys.settrace(None)
Ty vole co to je za hack, to doufam ze Java ani takovouto cestou neumi, fuj :D
Ano, mas pravdu, uvedl jsi kraaasnyy pripad flexibilnosti dynamicky typovaneho jazyka.
To neni zadny hack, ale priklad vyuziti velmi uzitecna veci, introspekce. Mohu skrz ni kontrolovat chod programu, aniz bych zasahoval do jeho kodu a reagovat libovolne na ruzne specificke podminky. Introspekce neni nutne vlastnost jen dynamickeho jazyka, ale v dynamickem jazyku se lehce vyrovnam s tim, ze prichazum do styku s hodnotami libovolnych datovych typu.
A jaky je zrovna usecase pro to historii setovani tech parametru? To se da prece logovat - pokud pises spravne objektove a ne jako prase, mas tam getry a setry. Nenapada me k cemu by to bylo dobre.
Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?Kód: [Vybrat]~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys
def undo(name):
undo.data[name].pop(-1)
return undo.data[name][-1]
undo.data = {}
def history(frame, event, arg):
for name,val in frame.f_locals.items():
if name not in undo.data:
undo.data[name] = []
else:
if undo.data[name][-1] is val:
continue
undo.data[name].append(val)
return history
def main():
for i in range(5):
var1 = i
var2 = str(i)
print "var1:", var1
var1 = undo('var1')
var1 = undo('var1')
print "var1 after undo:", var1, type(var1)
print "var2:", var2
var2 = undo('var2')
var2 = undo('var2')
print "var2 after undo:", var2, type(var2)
if __name__ == '__main__':
sys.settrace(history)
main()
sys.settrace(None)
O tom co se mi hodi a co ne vis uplne prdlajs a jinak jsi na urovni trumbery, ktery na demonstracni hello world reaguje poznamkou, ze vypisovani slov hello world je uplne na nic. :-)Já mám takovou krásnou ukázku flexibility dynamického jazyka. Implementace funkce undo pro libovolné proměnné libovolného typu. Jak složité bude tohle implementovat ve statickém jazyce, který se používá v produkční sféře, tedy C, C++, Java, C#?Kód: [Vybrat]~ $ python2 history.py
var1: 4
var1 after undo: 2 <type 'int'>
var2: 4
var2 after undo: 2 <type 'str'>
~ $ cat history.py
import sys
def undo(name):
undo.data[name].pop(-1)
return undo.data[name][-1]
undo.data = {}
def history(frame, event, arg):
for name,val in frame.f_locals.items():
if name not in undo.data:
undo.data[name] = []
else:
if undo.data[name][-1] is val:
continue
undo.data[name].append(val)
return history
def main():
for i in range(5):
var1 = i
var2 = str(i)
print "var1:", var1
var1 = undo('var1')
var1 = undo('var1')
print "var1 after undo:", var1, type(var1)
print "var2:", var2
var2 = undo('var2')
var2 = undo('var2')
print "var2 after undo:", var2, type(var2)
if __name__ == '__main__':
sys.settrace(history)
main()
sys.settrace(None)
Až na to, že jelikož objekty v Pythonu obecně nejsou immutabilní, je Ti zcela obecně ta Tvoje LIFO kolekce hodnot úplně nanic.
O tom co se mi hodi a co ne vis uplne prdlajs a jinak jsi na urovni trumbery, ktery na demonstracni hello world reaguje poznamkou, ze vypisovani slov hello world je uplne na nic. :-)
Neprsim se kodem, prsim se moznostmi, ktere demonstruuji na jednoduche ukazce. Tvoje chyba je, ze na to reagujes s nepochopenim jako osel. Psal jsem, ze to funguje pro vsechny promenne libovolneho typu, coz plati.O tom co se mi hodi a co ne vis uplne prdlajs a jinak jsi na urovni trumbery, ktery na demonstracni hello world reaguje poznamkou, ze vypisovani slov hello world je uplne na nic. :-)
Aha, takže Ty se prsíš kódem, který je ubohý a nepoužitelný a je to moje chyba? Sám jsi psal, že to funguje s hodnotami libovolného typu, tak se nevykrucuj, když jsem Tě nachytal.
To neni zadny hack, ale priklad vyuziti velmi uzitecna veci, introspekce. Mohu skrz ni kontrolovat chod programu, aniz bych zasahoval do jeho kodu a reagovat libovolne na ruzne specificke podminky. Introspekce neni nutne vlastnost jen dynamickeho jazyka, ale v dynamickem jazyku se lehce vyrovnam s tim, ze prichazum do styku s hodnotami libovolnych datovych typu.
Neprsim se kodem, prsim se moznostmi, ktere demonstruuji na jednoduche ukazce. Tvoje chyba je, ze na to reagujes s nepochopenim jako osel. Psal jsem, ze to funguje pro vsechny promenne libovolneho typu, coz plati.
To je samozřejmě hloupost a realita je přesně opačná, bez testů se neobejdeme, bez _statických_ typů ano. Statické typy mají jediné opodstatnění, výkon. Ve všem ostatním jsou nahraditelné.Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.
Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat.
Já mám takovou krásnou ukázku flexibility dynamického jazyka.Spíš je to krásná ukázka toho, že "krása" je veskrze subjektivní pojem.
Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat. To z mnoha důvodů většinou nejde. Proto se snažíme dokázat (rozhodnout na základě statické analýzy zdrojových textů, pro všechny možné vstupy a bez nutnosti program spouštět) aspoň něco. Statická typová analýza je jedním z nástrojů, jak dokázat aspoň některé vlastnosti programu. Jestliže nějaké tvrzení o programu dokážeme (v matematickém slova smyslu), tak si můžeme být jistí, že platí.
Také by mohlo být ideální obejít se bez statických typů. Bude to znamenat pouze určitou ztrátu výkonu, což v dnešní době není považováno za podstatné. Statická analýza může být (a také bývá) součástí testů.
Na druhou stranu testy většinou žádné obecné tvrzení o programu nedokazují, protože je není možné napsat tak, aby pokryly úplně celý stavový prostor programu. Takže se spoléháme na to, že otestujeme některé speciální situace, v lepším případě zvolené "chytře", např. na základě znalosti kódu, v horším případě vybrané náhodně, v nejhorším případě vybrané systematicky špatně. Když testy neohlásí chybu, tak věříme, že je program dobře. Ale ve skutečnosti jsme jen ověřili, že nenastane chyba pro určitou (většinou malou) podmnožinu vstupů. A to ještě za předpokladu, že nějaká chyba v testu nezamaskuje přítomnost chyby v kódu.
Zpravidla testujeme pouze okrajové podmínky, kdy program má fungovat a kdy naopak musí vyhodit výjimku. Na znalost kódu se spoléhat nemůžeme, protože ho v době psaní testů ještě nemáme. Když testy neohlásí chybu, tak zpřesníme testy, to je základ. Nevěř testům, které projdou.
Když mám k dispozici dva kontrolní mechanismy, které jsou do značné míry komplementární, tak se mi nezdá vhodné jeden z nich zahodit (a ještě ten s principiálně silnější vypovídací schopností) a tvářit se, že jsem zachoval stejnou úroveň kontroly.
Proto se tyto kontrolní mechanismy kombinují. Smalltalk šel cestou testování a možná proto se tolik nerozšířil. Haskell se vydal cestou statického typování, ale bez testů se také neobejde. Nejlépe jsou dnes na tom jazyky, které oba přístupy volně kombinují. Proto byly do PHP či Pythonu přidány volitelné statické typy a proto se staticky typované programy nejen dokazují, ale i testují.
Já mám takovou krásnou ukázku flexibility dynamického jazyka.Spíš je to krásná ukázka toho, že "krása" je veskrze subjektivní pojem.
Ono by nejen této diskusi prospělo, kdyby každý diskutující rozlišoval věcné argumenty a subjektivní názory...Ano, velmi. Ale je to obtížné. Pro někoho přílíš obtížné.
Muze to byt tak i tak, je neco podobneho ale v komplexnejsi forme mam ve vlastni knihovne, kterou pouzivam jak pri testech tak nekdy i v samotnem kodu.To neni zadny hack, ale priklad vyuziti velmi uzitecna veci, introspekce. Mohu skrz ni kontrolovat chod programu, aniz bych zasahoval do jeho kodu a reagovat libovolne na ruzne specificke podminky. Introspekce neni nutne vlastnost jen dynamickeho jazyka, ale v dynamickem jazyku se lehce vyrovnam s tim, ze prichazum do styku s hodnotami libovolnych datovych typu.
Vidím tam jednu vadu na kráse: Funkce history() a undo() jsou zbytečně součástí aplikace. Uvítal bych, kdyby byly spíš součástí toho testu dole. Nebo je to celé samostatným testem?
Nemas pravdu ani v jednom pripade. Nevymyslel jsem to ja, implementace funguje a demonstruuji tu vyhody dynamickych jazyku, ktere tu mnozi popiraji. Analogii ve statickem jazyku tu nikdo nepredvedl, asi to vubec nejde a rekl bych, ze odtud prameni tvoje nasranost :-).Neprsim se kodem, prsim se moznostmi, ktere demonstruuji na jednoduche ukazce. Tvoje chyba je, ze na to reagujes s nepochopenim jako osel. Psal jsem, ze to funguje pro vsechny promenne libovolneho typu, coz plati.
Hele, chybu udělá každý, ale takhle zatloukat, to je trapné. Vymyslel sis featuru, která je nanic, udělal implementaci, která nefunguje, abys demonstroval, co tu nikdo nepopírá. Tím s Tebou fakt končím, už se budu akorát tiše uchechtávat.
Nemas pravdu ani v jednom pripade. Nevymyslel jsem to ja, implementace funguje a demonstruuji tu vyhody dynamickych jazyku, ktere tu mnozi popiraji. Analogii ve statickem jazyku tu nikdo nepredvedl, asi to vubec nejde a rekl bych, ze odtud prameni tvoje nasranost :-).
Potreba vykonu je jen v nekterych prápadech. Proto se arduino bude programt v C asi vzdy a webove stranky asi nikdy. Dnes je vykonu tolik, ze mnohem vyznamnejsi je produktivita, ktera je vyssi u flexibilnejsich dynamickych jazyku. Staticke analyza u testu ma vyhodu v tom, ze ji lze pouzit jen tam kde je vhodna a potrebna. Idealni univerzalni jazyk budoucnosti by tedy mel mit moznost statickych typu, ale nepovinne. K necemu takovemu ma nakroceno cython, ktery kombinuje vyhody dynamickych a statickych jazyku.Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat. To z mnoha důvodů většinou nejde. Proto se snažíme dokázat (rozhodnout na základě statické analýzy zdrojových textů, pro všechny možné vstupy a bez nutnosti program spouštět) aspoň něco. Statická typová analýza je jedním z nástrojů, jak dokázat aspoň některé vlastnosti programu. Jestliže nějaké tvrzení o programu dokážeme (v matematickém slova smyslu), tak si můžeme být jistí, že platí.
Také by mohlo být ideální obejít se bez statických typů. Bude to znamenat pouze určitou ztrátu výkonu, což v dnešní době není považováno za podstatné. Statická analýza může být (a také bývá) součástí testů.
Kupodivu i v dnešní době na výkonu často záleží. Jaký je rozdíl, když je statická analýza (nejspíš včetně typové analýzy, pokud k ní kód poskytuje dostatek informací) součástí testů a ne kompilátoru? Kromě toho, že je pak potřeba statickou analýzu v testech vůbec řešit a kompilátor tyto informace nemůže použít pro optimalizaci?
Mne prijde, ze je tu malo programatoru z praxe, programatoru, kteri vytvari skutecny produkcni kod, ktery neco poradneho dela, vydelava penize a za to jsou ti programatori placeni. Vypada to, ze je to tu samy teoreticky programator, ktery ma nastudovanu teorii typu, ale nikdy zadny realny produkt nevytvoril. Testovat se musi nejen ze program funguje a dela to co ma, ale i to, ze selze a nedela to co nema. Vetsinou se od programu nechce aby fungoval za kazdou cenu, ale hlavne aby nenadelal skody. Pokud zakaznik predem doda testy, je to to nejlepsi co muze programatora potkat, protoze programator zpravidla nerozumi byznysu a procesum zakaznika a aplikaci z funkcniho hlediska otestovat neumi. Programator vi, ze nemuze scitat int se stringem, ale to ani zdaleka nestaci. Ono se treba take musi otestovat, ze zkratovaci souprava muze byt osazena jen na jedno miste a na jednom miste muze byt jen jedna zkratovaci souorava s vyjimkou nekolika mist, ze musi byt osazena na prikaz b a nejde ji sundat, dokud plati, ale muze zustat osazena i po jeho ukonceni, ze muze byt osazena na vice prikazu b, ze jeden prikaz muze byt prilohou jineho prikazu b, kdy se pozadavky prenasi, ze jsou prikazy b ciste na odjisteni, kdy se nezajistuje, ze existuje moznost docasneho odjisteni na prikaz b a rada dalsich pravidel, ktere zakaznik upresnuje zpravidla az kdyz je aplikace hotova a poukazuje na chyby v aplikaci a divi se, ze to programatori nevi a udelali spatne, protoze je to prece vsechno jasne a logicke. Teda s tim, ze na ruznych lokalitach bezi procesy trochu odlisne, coz je potreba take zohlednit, coz ani zakaznik sam netusil, protoze pozadavek zadava nejaky manager, kterynti sam do detailý nezna. Ale rozhodne to nesmi byt spatne, protoze kdyz to bude fungovat spatne, pujde elektrikarum o zivot. No a to se bavime o velmi jednoduche evidencni knize, ktera se da naprogramovat za par dnu, ale otestovat ji dukladne a pustit do provozu je zalezitost na nekolik mesicu. Kazda uprava a zasah do kodu vyzaduje provest testy na vsechny vazby a podminky znovu, aby se overilo, ze se nic nenarusilo. Kod testu je rozsahlejsi nez sama aplikace. A staticke typy v tom hraji zcela marginalni ulohu. Aplikace musi byt v C#, protoze takove je zakaznikovo prostredi a rozumne nic jineho nepripusti, aby to byl schopen rozumne udrzovat. Takova je realna praxe, panove. A pak tady jsou s prominutim imbecilove, kteri zcela vazne tvrdi, ze kdyz aplikace projde kompilatorem, tak je v podstate hotovo.Testy není nutné psát dřív než kód. U některých je to dost nevhodné. Kdybych bral poslední dvě věty doslova, tak nevím, jak poznám, že je program připraven pro produkční nasazení.Na druhou stranu testy většinou žádné obecné tvrzení o programu nedokazují, protože je není možné napsat tak, aby pokryly úplně celý stavový prostor programu. Takže se spoléháme na to, že otestujeme některé speciální situace, v lepším případě zvolené "chytře", např. na základě znalosti kódu, v horším případě vybrané náhodně, v nejhorším případě vybrané systematicky špatně. Když testy neohlásí chybu, tak věříme, že je program dobře. Ale ve skutečnosti jsme jen ověřili, že nenastane chyba pro určitou (většinou malou) podmnožinu vstupů. A to ještě za předpokladu, že nějaká chyba v testu nezamaskuje přítomnost chyby v kódu.
Zpravidla testujeme pouze okrajové podmínky, kdy program má fungovat a kdy naopak musí vyhodit výjimku. Na znalost kódu se spoléhat nemůžeme, protože ho v době psaní testů ještě nemáme. Když testy neohlásí chybu, tak zpřesníme testy, to je základ. Nevěř testům, které projdou.
Staticke typy mohou pomoci pri overovani spravnosti kodu, ale jsou zbytne, nezbytne jsou testy. Staticke typy v tomto smeru hraji druhe housle.Když mám k dispozici dva kontrolní mechanismy, které jsou do značné míry komplementární, tak se mi nezdá vhodné jeden z nich zahodit (a ještě ten s principiálně silnější vypovídací schopností) a tvářit se, že jsem zachoval stejnou úroveň kontroly.
Proto se tyto kontrolní mechanismy kombinují. Smalltalk šel cestou testování a možná proto se tolik nerozšířil. Haskell se vydal cestou statického typování, ale bez testů se také neobejde. Nejlépe jsou dnes na tom jazyky, které oba přístupy volně kombinují. Proto byly do PHP či Pythonu přidány volitelné statické typy a proto se staticky typované programy nejen dokazují, ale i testují.
Právě že se programy nedokazují, a proto se musí testovat. I staticky typované jazyky kombinují oba přístupy. Já jsem nebyl ten, kdo prosazoval, že nejsou potřeba statické typy, protože testy. A netvrdím ani to, že statická typová analýza je náhradou testů.
A presne za timto ucelem to pouzivam, k testovani aplikaci. Je to vyborna vec pro realtime aplikace, ktere bezi nonstop a potrebujes jejich chod monitorovat. Program se pozaduje a dodava vzdy na definovane platforme a v definovanem prostredi. Operacnim systemem pocinaje, verzi knihoven konce. Takze to co vnimas jako problem je v praxi nepodstatne a bez problemu toho vyuzivam dele, nez vubec existovaly nektere technologie microsoftu jako treba Silverlight nebo zustali kompatibilni, jako treba access a jeho runtime.Nemas pravdu ani v jednom pripade. Nevymyslel jsem to ja, implementace funguje a demonstruuji tu vyhody dynamickych jazyku, ktere tu mnozi popiraji. Analogii ve statickem jazyku tu nikdo nepredvedl, asi to vubec nejde a rekl bych, ze odtud prameni tvoje nasranost :-).
My nejsme nasraní, my se podivujeme nad tvojí nezkušeností a zaslepeností. Použít implementation dependent debugger k implementaci historie, to je opravdu majstrštyk hodný uveřejnění na hovnokódu. Mimochodem kdyby sis přečetl dokumentaci k settrace, tak by ses tam dozvěděl mimo mnoho dalších zajímavých věcí i tohle:
CPython implementation detail: The settrace() function is intended only for implementing debuggers, profilers, coverage tools and the like. Its behavior is part of the implementation platform, rather than part of the language definition, and thus may not be available in all Python implementations.
Pouzil jsem presne tolik argumentu, jako jich bylo pouzito u tvrzeni, na ktere jsem reagoval. Vecne argumenty jsou zrejme, alespon jsem predpokladal, ze je to vsem zrejme. Na tom ze se bez testu neda obejit se shodneme, a nenajde se jediny programator, ktery by kdy poskytl funkcni produkcni kod, aniz by ho otestoval. Ze se lze obejit bez statickych typu pro testovani programu dokazuje rada siroce pouzivanych jazyku, v kterych je napsano nespocet programu, ktere staticke typy nepouzivaji.Když v takovéto diskusi věta začíná: "To je samozřejmě", je to silná indikace, že následuje nepravda. Aspoň jeden věcný argument by nebyl?To je samozřejmě hloupost a realita je přesně opačná, bez testů se neobejdeme, bez _statických_ typů ano. Statické typy mají jediné opodstatnění, výkon. Ve všem ostatním jsou nahraditelné.Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat.
Ano, bez testů se neobejdeme, protože neumíme správnost programu dokázat. Ano, bez statických typů se obejdeme, když se smířime se ztrátou výhod, které poskytují. Ne, jejich význam nespočívá jen ve zlepšení výkonu. Také nás zbavují nutnosti psát některé druhy testů a zároveň poskytují lepší záruku správnosti programu.
A presne za timto ucelem to pouzivam, k testovani aplikaci. Je to vyborna vec pro realtime aplikace, ktere bezi nonstop a potrebujes jejich chod monitorovat. Program se pozaduje a dodava vzdy na definovane platforme a v definovanem prostredi. Operacnim systemem pocinaje, verzi knihoven konce. Takze to co vnimas jako problem je v praxi nepodstatne a bez problemu toho vyuzivam dele, nez vubec existovaly nektere technologie microsoftu jako treba Silverlight nebo zustali kompatibilni, jako treba access a jeho runtime.Nemas pravdu ani v jednom pripade. Nevymyslel jsem to ja, implementace funguje a demonstruuji tu vyhody dynamickych jazyku, ktere tu mnozi popiraji. Analogii ve statickem jazyku tu nikdo nepredvedl, asi to vubec nejde a rekl bych, ze odtud prameni tvoje nasranost :-).
My nejsme nasraní, my se podivujeme nad tvojí nezkušeností a zaslepeností. Použít implementation dependent debugger k implementaci historie, to je opravdu majstrštyk hodný uveřejnění na hovnokódu. Mimochodem kdyby sis přečetl dokumentaci k settrace, tak by ses tam dozvěděl mimo mnoho dalších zajímavých věcí i tohle:
CPython implementation detail: The settrace() function is intended only for implementing debuggers, profilers, coverage tools and the like. Its behavior is part of the implementation platform, rather than part of the language definition, and thus may not be available in all Python implementations.
Ne me to pusobi opacnym dojmem. Naslo se neco, na co jsou bezne jazyky se statickym typovanim kratke a nez to priznat, tak radsi sami sebe presvedcime, ze je to na nic. Obavam se, ze kdyby debugger byl domenou jen dynamickych jazyku jako introspekce, tak byste tu houfne tvrdili, ze debugger je na nic, vsak zjistit obsah promenne lze take pomoci logu. Introspekce je velmi uzitecna vlastnost jazyka, ale proc by se mel nekdo zamyslet nad jejimim moznostmi a vyuzitim, kdyzi ji nema k dispozici, ze. Je to neco neznameho, ciziho, fuj, prasacky hack a kdesi cosi - nazval bych to programatorskou xenofobii :-).A presne za timto ucelem to pouzivam, k testovani aplikaci. Je to vyborna vec pro realtime aplikace, ktere bezi nonstop a potrebujes jejich chod monitorovat. Program se pozaduje a dodava vzdy na definovane platforme a v definovanem prostredi. Operacnim systemem pocinaje, verzi knihoven konce. Takze to co vnimas jako problem je v praxi nepodstatne a bez problemu toho vyuzivam dele, nez vubec existovaly nektere technologie microsoftu jako treba Silverlight nebo zustali kompatibilni, jako treba access a jeho runtime.Nemas pravdu ani v jednom pripade. Nevymyslel jsem to ja, implementace funguje a demonstruuji tu vyhody dynamickych jazyku, ktere tu mnozi popiraji. Analogii ve statickem jazyku tu nikdo nepredvedl, asi to vubec nejde a rekl bych, ze odtud prameni tvoje nasranost :-).
My nejsme nasraní, my se podivujeme nad tvojí nezkušeností a zaslepeností. Použít implementation dependent debugger k implementaci historie, to je opravdu majstrštyk hodný uveřejnění na hovnokódu. Mimochodem kdyby sis přečetl dokumentaci k settrace, tak by ses tam dozvěděl mimo mnoho dalších zajímavých věcí i tohle:
CPython implementation detail: The settrace() function is intended only for implementing debuggers, profilers, coverage tools and the like. Its behavior is part of the implementation platform, rather than part of the language definition, and thus may not be available in all Python implementations.
Aneb zastanci dynamicky typovanych jazyku byli nachytani v nedbalkach :D
Nedokazu si predstavit, k cemu by tahle funkce byla. Co potrebujes logovat, to si zalogujes, volani metod muzes obcas logovat pomoci AOP.
Mozna to je uzitecne pro nejake super jednoduche aplikace. V podstate ale neverim, ze pokud to pouzivas, ma tvoje aplikace dobry design. Mam podezreni, ze to delas na koleni. To je uplne typicke pro skriptovaci bastlire. Tahle diskuze je jeden o voze, druhy o koze.
Ne me to pusobi opacnym dojmem. Naslo se neco, na co jsou bezne jazyky se statickym typovanim kratke a nez to priznat, tak radsi sami sebe presvedcime, ze je to na nic.Hele, předvedl jsi způsob, jak implementovat nějakou featuru (undo). A implementoval jsi ji prasáckým způsobem, který ve statických jazycích nemá moc ekvivalent. To ale neznamená, že stejná funkcionalita ve statických jazycích nejde implementovat jinak - a daleko čistěji.
Obavam se, ze kdyby debugger byl domenou jen dynamickych jazyku jako introspekce, tak byste tu houfne tvrdili, ze debugger je na nic, vsak zjistit obsah promenne lze take pomoci logu. Introspekce je velmi uzitecna vlastnost jazyka, ale proc by se mel nekdo zamyslet nad jejimim moznostmi a vyuzitim, kdyzi ji nema k dispozici, ze. Je to neco neznameho, ciziho, fuj, prasacky hack a kdesi cosi - nazval bych to programatorskou xenofobii :-).Tvoje obava je zcela lichá.
Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.
Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???
Ne me to pusobi opacnym dojmem. Naslo se neco, na co jsou bezne jazyky se statickym typovanim kratke a nez to priznat, tak radsi sami sebe presvedcime, ze je to na nic.Hele, předvedl jsi způsob, jak implementovat nějakou featuru (undo). A implementoval jsi ji prasáckým způsobem, který ve statických jazycích nemá moc ekvivalent. To ale neznamená, že stejná funkcionalita ve statických jazycích nejde implementovat jinak - a daleko čistěji.
Pokud bys chtěl undo implementovat čistě, použiješ explicitní stav a nějaký state store. Podívej se, jak to má udělané třeba Vue.js. JS sice není statický jazyk, ale ani tak tam nepoužili žádnou takovou prasárnu jako ty :)Obavam se, ze kdyby debugger byl domenou jen dynamickych jazyku jako introspekce, tak byste tu houfne tvrdili, ze debugger je na nic, vsak zjistit obsah promenne lze take pomoci logu. Introspekce je velmi uzitecna vlastnost jazyka, ale proc by se mel nekdo zamyslet nad jejimim moznostmi a vyuzitim, kdyzi ji nema k dispozici, ze. Je to neco neznameho, ciziho, fuj, prasacky hack a kdesi cosi - nazval bych to programatorskou xenofobii :-).Tvoje obava je zcela lichá.
Smysl je ve flexibilite. Zadne paradigma neni objektivne lepsi nez jine a pro ruzne situace muze byt jednou vhodnejsi to a podruhe ono, v Pythonu si je lze podle potřeby vybrat a kombinovat je, zlepsuje to vyjadrovaci prostredky jazyka. To je bez pochyby prinosne a obliba Pythonu prokazuje, ze to za pripadne komplikace stoji.
Nedohadujte se, Python zapouzdreni ma, at se vam to libi nebo ne. Zapouzdreni je abstrakce, ktera progranatorum umoznuje urcity pristup k programovani a Python tento pristup umoznuje.
@instancemethod neni anotace, ale dekorator a tento tam neni, protoze je to vychozi chovani. Stejne byste se mohl ptat, proc se v matematice nepise + pred kladnymi cisly, kdyz u zapornych se pise -.
Mate problem uvest ekvivalent primitivni demonstracni ukazky, jejiz podstata vam unika a chytate se marginalii. Po vas se chce, abysye odpovedeli stejne jednoduchou principialni (princip introspekce) ukazkou jak tehoz dosahnout v bezne pouzivanem jazyce se statickymi typy. Popripade pripustili, ze to jednoduse udelat nejde a pochopili s tim, kde jsou vyhody dynamickych jazyku.Dobyvas se do otevrenych dveri. Nikdo tady netvrdi, ze ve statickych jazycich existuji ekvivalenty ke vsem konstrukcim dynamickych jazyku.
x = pickle.load(...)
Vývojář by se především měl zeptat sám sebe, zda ten počet prvků potřebuje k dosažení cíle. Například zmíněné metody seznam.forEach(), seznam.max() tuto potřebu zpravidla eliminují.
Naimplementujte tohle, volové!http://hackage.haskell.org/package/python-pickle-0.2.3/docs/Language-Python-Pickle.html ?Kód: [Vybrat]x = pickle.load(...)
To ve statickém jazyce nejde. Minimálně ne tak snadno. A nikdo to nerozporuje.
Jasně, že ne. Dělá se to jako protokoly třeba v ObjC. Když už někdo potřebuje takto heterogenní seznam, musí pak použít ve Smalltalk-like jazycích conformsTo: a jinde třeba typové aserce, implementace bývá zcela stejná.Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.
Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???
Znamená to, že mám-li různé seznamy různých prvků, nad kterými potřebuju spouštět pokaždé jiné metody, musejí mít ony prvky rozhraní vždy s danou kombinací spouštěných metod, nebo rovnou pro každou metodu jedno rozhraní?
Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.
Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?
http://hackage.haskell.org/package/python-pickle-0.2.3/docs/Language-Python-Pickle.html ?Tak jistě, můžeš si klidně implementovat celý Python v Haskellu, že :)
To je pak chyba v návrhu. Ve smalltalkoidním jazyce by nešlo použít conformsTo:, muselo by se sáhnout po respondsTo:, což je méně efektivní nejspíš ve všech jazycích, protože introspekce. Tohle je zřejmě důvod, proč je v Go konformance automatická. Nicméně pokud někdo udělá takovou botu třeba v Javě, tak musí sáhnout po reflexi jako ve Smalltalku, to není nic objevného.Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.
Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?
Kit to možná chtěl napsat opačně: Co když položky metodu implementovanou mají, ale není v rozhraní.
Tohle je zřejmě důvod, proč je v Go konformance automatická.Co tím myslíš? Můžeš to rozvést nebo ilustrovat kódem?
To přece sám znáš, v Go se neuvádí u struktur implementovaná rozhraní, překladač si je odvodí sám podle implementovaných metod. Příklad: Když nedefinuju pro nějakou svou struct metodu String(), automaticky ji překladač považuje za Stringer, což je rozhraní ze standardní knihovny. To řeší tu zmiňovanou chybu kodéra, co zapomene uvést rozhraní jako podporované.Tohle je zřejmě důvod, proč je v Go konformance automatická.Co tím myslíš? Můžeš to rozvést nebo ilustrovat kódem?
Pickle pro me neni stezejni. Kdyz slysim dynamicky jazyk, je to pro me v prvni rade flexibilita a jednoduchost psani prehledneho kodu ktery jde primeji k podstate veci a v druhe rade moznost 'magickeho' zasahovani do chodu programu. Moznost menit hriste, na kterem se hraje. To nezajimavejsi na pythonu pro me se popisuje v runtime services: https://docs.python.org/3/library/python.html Obavam se, ze kritici dynamickych jazyku nevi co to vlastne obnasi, nikdy se nepodivali za zrcadlo. Neumi vyuzit dynamickeho prostredi, boji se ho, jeho moznostina svobody a preferuji totalitu statickeho prostredi, prijde jim bezpecnejsilMate problem uvest ekvivalent primitivni demonstracni ukazky, jejiz podstata vam unika a chytate se marginalii. Po vas se chce, abysye odpovedeli stejne jednoduchou principialni (princip introspekce) ukazkou jak tehoz dosahnout v bezne pouzivanem jazyce se statickymi typy. Popripade pripustili, ze to jednoduse udelat nejde a pochopili s tim, kde jsou vyhody dynamickych jazyku.Dobyvas se do otevrenych dveri. Nikdo tady netvrdi, ze ve statickych jazycich existuji ekvivalenty ke vsem konstrukcim dynamickych jazyku.
Mohl bys pouzit daleko jednodussi argument:
Naimplementujte tohle, volové!Kód: [Vybrat]x = pickle.load(...)
To ve statickém jazyce nejde. Minimálně ne tak snadno. A nikdo to nerozporuje.
Jinak, celá tahle žabomyší válka je fakt tragikomicky dětinská.
To přece sám znáš, v Go se neuvádí u struktur implementovaná rozhraní, překladač si je odvodí sám podle implementovaných metod. Příklad: Když nedefinuju pro nějakou svou struct metodu String(), automaticky ji překladač považuje za Stringer, což je rozhraní ze standardní knihovny. To řeší tu zmiňovanou chybu kodéra, co zapomene uvést rozhraní jako podporované.Jasny, ja jsem jenom blbe pochopil kontext. Ok, dik.
BTW tohle by měly mít všechny jazyky, je to praktické.To přece sám znáš, v Go se neuvádí u struktur implementovaná rozhraní, překladač si je odvodí sám podle implementovaných metod. Příklad: Když nedefinuju pro nějakou svou struct metodu String(), automaticky ji překladač považuje za Stringer, což je rozhraní ze standardní knihovny. To řeší tu zmiňovanou chybu kodéra, co zapomene uvést rozhraní jako podporované.Jasny, ja jsem jenom blbe pochopil kontext. Ok, dik.
Pepa vyrobí .size(), Franta vyrobí .length(), Honza vyrobí .len() ... a pak se v tom vyznej (to už se mi stalo).
Generické věci využívající generické protokoly nemusí bordelit třídní namespace a zbytečně komplikovat dědičnost. Například len() se podívá, jestli si třída implementuje __len__ a pokud ne, tak si ji projde a spočítá počet prvků, takže funguje s čímkoliv, co je iterable. Ditto ostatní takové věci. Ale Control-Space Enter, já vím.
Navíc python do jisté míry podporuje funkcionální styl programování, kde se přesně takové věci dělají. A když už mám jazyk, co takové programování podporuje, tak proč bych to nevyužil? Šetří to psaní, lépe se píšou výrazy ve funkcionálním stylu.
...Když si někde vytvořím _my_private, tak by v code review mělo být nad slunce jasné, že když někdo napíše neco._my_private, že je něco asi špatně.
Není to problém. Prostě nad tím pustím tu funkci sum() která vynucuje vlastnost "cena" či "objem". A ono se to transitivně propíše i do toho seznamu. Takže někdy v tom okamžiku mi kompilátor začne řvát, že tam má něco nedomyšleného, ať to laskavě domyslím.
Testy není nutné psát dřív než kód. U některých je to dost nevhodné. Kdybych bral poslední dvě věty doslova, tak nevím, jak poznám, že je program připraven pro produkční nasazení.
Staticke typy mohou pomoci pri overovani spravnosti kodu, ale jsou zbytne, nezbytne jsou testy. Staticke typy v tomto smeru hraji druhe housle.
Znamená to, že mám-li různé seznamy různých prvků, nad kterými potřebuju spouštět pokaždé jiné metody, musejí mít ony prvky rozhraní vždy s danou kombinací spouštěných metod, nebo rovnou pro každou metodu jedno rozhraní?Jasně, že ne. Dělá se to jako protokoly třeba v ObjC. Když už někdo potřebuje takto heterogenní seznam, musí pak použít ve Smalltalk-like jazycích conformsTo: a jinde třeba typové aserce, implementace bývá zcela stejná.
ObjC třeba. Nebo Smalltalk :)Co to je "Smalltalk-like jazycích"???Znamená to, že mám-li různé seznamy různých prvků, nad kterými potřebuju spouštět pokaždé jiné metody, musejí mít ony prvky rozhraní vždy s danou kombinací spouštěných metod, nebo rovnou pro každou metodu jedno rozhraní?Jasně, že ne. Dělá se to jako protokoly třeba v ObjC. Když už někdo potřebuje takto heterogenní seznam, musí pak použít ve Smalltalk-like jazycích conformsTo: a jinde třeba typové aserce, implementace bývá zcela stejná.
Kit to možná chtěl napsat opačně: Co když položky metodu implementovanou mají, ale není v rozhraní.To je pak chyba v návrhu. Ve smalltalkoidním jazyce by nešlo použít conformsTo:, muselo by se sáhnout po respondsTo:, což je méně efektivní nejspíš ve všech jazycích, protože introspekce. Tohle je zřejmě důvod, proč je v Go konformance automatická. Nicméně pokud někdo udělá takovou botu třeba v Javě, tak musí sáhnout po reflexi jako ve Smalltalku, to není nic objevného.
Tak sem dej kód pro ten batoh, my ti tu pak vysvětlíme, kde děláš ve svém uvažování chybu.A v kterém rozhraní má tedy být uvedena metoda např. pro hmotnost?Kit to možná chtěl napsat opačně: Co když položky metodu implementovanou mají, ale není v rozhraní.To je pak chyba v návrhu. Ve smalltalkoidním jazyce by nešlo použít conformsTo:, muselo by se sáhnout po respondsTo:, což je méně efektivní nejspíš ve všech jazycích, protože introspekce. Tohle je zřejmě důvod, proč je v Go konformance automatická. Nicméně pokud někdo udělá takovou botu třeba v Javě, tak musí sáhnout po reflexi jako ve Smalltalku, to není nic objevného.
Smalltalk SERE na rozhraní či třídy, Smalltalk posílá zprávy, objekt vrací hodnotu, nebo chybu. To je celé!
Staticke typy mohou pomoci pri overovani spravnosti kodu, ale jsou zbytne, nezbytne jsou testy. Staticke typy v tomto smeru hraji druhe housle.
Taky si to myslím. Typový systém nahradit testy jde. Testy typovým systémem taky, ale zatím jen teoreticky, prakticky to ještě nikdo nepředvedl. Otázkou tedy (stále) zůstává, zda mi to sraní s typy víc přinese než vezme. To si musí každý soudruh pořešit sám.
Testy není nutné psát dřív než kód. U některých je to dost nevhodné. Kdybych bral poslední dvě věty doslova, tak nevím, jak poznám, že je program připraven pro produkční nasazení.No hlavně se vám to ani nepovede, protože ve statickém jazyku bez existence testovaného ani nepřeložíte test.
Ano, tohle by mohl interpret zachytit a poskytnout varovani. V praxi to zachyti lint....Když si někde vytvořím _my_private, tak by v code review mělo být nad slunce jasné, že když někdo napíše neco._my_private, že je něco asi špatně.Bude to v code review stačit? Co interpret, ví o tom?
~ $ cat xx.py
class Cls(object):
def __init__(self):
self.__var = 1
if __name__ == '__main__':
INS = Cls()
print INS._Cls__var
~ $ pylint xx.py
Using config file /data/data/com.termux/files/home/.pylintrc
************* Module xx
R: 1, 0: Too few public methods (0/2) (too-few-public-methods)
E: 7,10: Instance of 'Cls' has no '_Cls__var' member (no-member)
W: 7,10: Access to a protected member _Cls__var of a client class (protected-access)
--------------------------------------------------------------------
Your code has been rated at -1.67/10 (previous run: -1.67/10, +0.00)
~ $ python2 xx.py
1
BTW tohle by měly mít všechny jazyky, je to praktické.Souhlas, tohle je rozhodne jedna z tech svetlejsich stranek Gocka :)
Testy typovym systemem nahradit nelze, protoze neexistuje zadne obecne spravne chovani platne pro vsechny pripady. Jeden a ten samy kod muze byt jednou spatne a po druhe dobre. Funkce, ktera ma na vstupu 1 a na vystupu 0 muze fungovat pro jeden pripad dobre a pro druhy spatne. Jestli funguje podle ocekavani se da zkontrolovat jedine testem, v kterem nase ocekavani bude zahrnuto.
Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:
inc (x: Int) = x + 1
A proto tu mame rozsirene jazyky bez statickych typu a vsechy programy psane v programech se statickymi typy je nutno dukladne testovat. To jsou mi pekne druhe housle. :-)Testy typovym systemem nahradit nelze, protoze neexistuje zadne obecne spravne chovani platne pro vsechny pripady. Jeden a ten samy kod muze byt jednou spatne a po druhe dobre. Funkce, ktera ma na vstupu 1 a na vystupu 0 muze fungovat pro jeden pripad dobre a pro druhy spatne. Jestli funguje podle ocekavani se da zkontrolovat jedine testem, v kterem nase ocekavani bude zahrnuto.
To je samozřejmě pravda. Problém je v tom, že naopak je to ještě horší. Pár scénářů, které typy nezvládnou, zatímco většina scénářů, které pro změnu nezvládnou testy.
Takže druhé housle hrají testy.
Autoři by museli lépe argumentovatAnebo by placali uplne stejne neplodne, neposlouchali se, vedli svuj monolog, akorat na desetkrat vetsi plose :)
BTW tohle by měly mít všechny jazyky, je to praktické.Souhlas, tohle je rozhodne jedna z tech svetlejsich stranek Gocka :)
IMHO by bylo užitečnější místo této diskuze vést polemiku ve formě série článků s různými autory. Autoři by museli lépe argumentovat a uvést konkrétní příklady, na které by se pak lépe reagovalo. Portál by měl přísun zajímavých článků a paradoxně by si možná všichni ušetřili čas promrhaný v diskuzi... :-DA s kterými? :D Kdyby tu polemiku vedli lidé jako A. Kay, D. Knuth nebo N. Wirth, tak bych si ji i rád přečetl. Ale na myšlenkové průjmy jakýchsi bezvýznamných českých Brouků Pytlíků bych fakt zvědavý nebyl. Takže když se tu nějaký anonymní niemand vysmívá dynamicky typovaným jazykům a lidem, kteří je používají, tak má pro mě mnohem větší váhu názor nositele Turingovy ceny:
I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.
I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.
Asi nějaká lopata, která si myslí, že statické typy jsou jen na zlepšení výkonu ;D
"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages"IMHO by bylo užitečnější místo této diskuze vést polemiku ve formě série článků s různými autory. Autoři by museli lépe argumentovat a uvést konkrétní příklady, na které by se pak lépe reagovalo. Portál by měl přísun zajímavých článků a paradoxně by si možná všichni ušetřili čas promrhaný v diskuzi... :-DA s kterými? :D Kdyby tu polemiku vedli lidé jako A. Kay, D. Knuth nebo N. Wirth, tak bych si ji i rád přečetl. Ale na myšlenkové průjmy jakýchsi bezvýznamných českých Brouků Pytlíků bych fakt zvědavý nebyl. Takže když se tu nějaký anonymní niemand vysmívá dynamicky typovaným jazykům a lidem, kteří je používají, tak má pro mě mnohem větší váhu názor nositele Turingovy ceny:
I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.
Nevyuzivaji se jen na zlepseni vykonu, ale kvuli tomu vznikly a v tom jedinem jsou nenahraditelne.I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.Asi nějaká lopata, která si myslí, že statické typy jsou jen na zlepšení výkonu ;D
I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.
Asi nějaká lopata, která si myslí, že statické typy jsou jen na zlepšení výkonu ;D
Ne, je to jinak. Protoze Alan Kay v roce 2003 prohlasil, ze vsechny typove systemy ktere zna, jsou moc velky opruz, je to vecna a nezpochybnitelna pravda platna i pro vsechny jazyky budoucnosti a diskuse je zbytecna.
"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages"A?
- nositel turingovy ceny
"When people who can’t think logically design large systems, those systems become incomprehensible. And we start thinking of them as biological systems. And since biological systems are too complex to understand, it seems perfectly natural that computer programs should be too complex to understand.
We should not accept this."
-jiný nositel turingovy ceny
Ne, je to jinak. Protoze Alan Kay v roce 2003 prohlasil, ze vsechny typove systemy ktere zna, jsou moc velky opruz, je to vecna a nezpochybnitelna pravda platna i pro vsechny jazyky budoucnosti a diskuse je zbytecna.
Haskell v té době už existoval a ničím typově sofistikovanějším tu neargumentujete. Ostatně můžete shrnout své dojmy a zeptat se ho, co si o tom myslí dnes. Je to člověk, který by vám i odpověděl, když by viděl, že to má hlavu a patu, narozdíl od většiny českých profesůrků a inžynýrků z všelijakých sorbonn v Horní Dolní, kteří mají dojem, že je pod jejich úroveň na takové dotazy od prostého lidu reagovat.
Podle mě to jsou ale debaty na úrovni andělů na špičce jehly. Navíc působíte dojmem "dílcovou metodou odhadneme rychlost nepřátelského tanku". Sorry jako.
A v kterém rozhraní má tedy být uvedena metoda např. pro hmotnost?Tak sem dej kód pro ten batoh, my ti tu pak vysvětlíme, kde děláš ve svém uvažování chybu.
Smalltalk SERE na rozhraní či třídy, Smalltalk posílá zprávy, objekt vrací hodnotu, nebo chybu. To je celé!
batoh := Bag new.
batoh add: (Kámen ofSize: 10 andWeight: 20).
batoh add: (Sekyrka ofMaterial: #ocel andWeight: 20).
batoh add: (Hovno ofColour: #tmavěHnědá andWeight: 120).
batoh sum: [ :x | x weight ].
"se zohledněním nevhodného prvku"
batoh sum: [ :x | [ x weight ] ifError: [ 0 ] ].
Chapu, ze pristup Go ma svoje vyhody a muze byt prijemny, na druhou stranu zase nevidim zadnou zvlastni komplikaci v tom, ze implementaci interface/traitu musi autor explicitne deklarovat. Typovy system to pozna, prekladac to validuje, prace s tim prakticky zadna neniNo kdyz muze prekladac najit definici traitu kdekoli ve zdrojacich, tak uplne stejne muze najit i ten konflikt, takze to mi uplne jako argument neprijde.
mi nějak nedochází jak to funguje, např. mám strukturu x = (y, z), tak pro (f x) se provede (f y) a (f z) a hodnota (f x) se určí jak?Chapu, ze pristup Go ma svoje vyhody a muze byt prijemny, na druhou stranu zase nevidim zadnou zvlastni komplikaci v tom, ze implementaci interface/traitu musi autor explicitne deklarovat. Typovy system to pozna, prekladac to validuje, prace s tim prakticky zadna neniNo kdyz muze prekladac najit definici traitu kdekoli ve zdrojacich, tak uplne stejne muze najit i ten konflikt, takze to mi uplne jako argument neprijde.
Ale pripomnel jsi mi, ze jednu fakt blbou vlastnost to ma: kdyz interfejs implementuju explicitne, muze mi prekladac ohlasit, ze mi neco chybi, primo na tom miste, kde to chybi. Kdyz je to implicitni, tak mi (v lepsim pripade) oznami na uplne jinem miste, ze pro tuhle strukturu interfejs definovany neni (clovek se drbe na hlave jakto, kdyz pred chvili byl - a pricinu musi hledat uplne jinde nez kde je chyba, prekladac mu s tim nepomuze). Anebo (v horsim pripade) mu to prestane fungovat az v testech (nedej matko prirodo na produkci), protoze se mu ve switchi nenamatchoval interface, pac ho kvuli nejake trivialni chybe najednou neimplementuje :)
Jednou se mi tohle stalo a pekne jsem si trhal vlasy, takze nakonec mas vlastne asi pravdu, zas tak dobra featura to neni. Ten spatnej zazitek muj mozek asi sebezachovne vytesnil ;)
Podle mě to jsou ale debaty na úrovni andělů na špičce jehly.Tak to ani náhodou. Debata o andělech byla daleko smysluplnější. To jenom dneska si ve své samolibé pýše myslime, že když je někde slovo "anděl", musí to být už z principu zhovadilost, i když o tom vůbec nic nevíme :)
a ještě Robin Milner dostal turingovu cenu"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages"A?
- nositel turingovy ceny
"When people who can’t think logically design large systems, those systems become incomprehensible. And we start thinking of them as biological systems. And since biological systems are too complex to understand, it seems perfectly natural that computer programs should be too complex to understand.
We should not accept this."
-jiný nositel turingovy ceny
mi nějak nedochází jak to funguje, např. mám strukturu x = (y, z), tak pro (f x) se provede (f y) a (f z) a hodnota (f x) se určí jak?https://tour.golang.org/methods/10
No hlavně se vám to ani nepovede, protože ve statickém jazyku bez existence testovaného ani nepřeložíte test.
To je právě účelem prvotního spuštění testu. Nesmí projít. Pokud by náhodou prošel, může to být chybou nebo také příznakem, že jsme hotovi.
děkuji, ale asi jsem se zeptal blběmi nějak nedochází jak to funguje, např. mám strukturu x = (y, z), tak pro (f x) se provede (f y) a (f z) a hodnota (f x) se určí jak?https://tour.golang.org/methods/10
děkuji, ale asi jsem se zeptal blběNebo jsem blbec já, to je v poho, zkus to třeba jinak :)
No super, takže v Go se to řeší za běhu úplně stejně pomocí typové aserce, kde je teda problém? Mimochodem moderní Smalltalk má protokoly taky, protože bez nich vzniká prasokód.A v kterém rozhraní má tedy být uvedena metoda např. pro hmotnost?Tak sem dej kód pro ten batoh
Smalltalk SERE na rozhraní či třídy, Smalltalk posílá zprávy, objekt vrací hodnotu, nebo chybu. To je celé!Kód: [Vybrat]batoh := Bag new.
batoh add: (Kámen ofSize: 10 andWeight: 20).
batoh add: (Sekyrka ofMaterial: #ocel andWeight: 20).
batoh add: (Hovno ofColour: #tmavěHnědá andWeight: 120).
batoh sum: [ :x | x weight ].
"se zohledněním nevhodného prvku"
batoh sum: [ :x | [ x weight ] ifError: [ 0 ] ].
zkusil jsem to obvyklým způsobem - nainstaloval go, vyzkoušel si to a zřejmě jsem to chápal blbě, představoval jsem si něco jako conditional conformance ze swiftuděkuji, ale asi jsem se zeptal blběNebo jsem blbec já, to je v poho, zkus to třeba jinak :)
představoval jsem si něco jako conditional conformance ze swiftuTa ale k životu potřebuje generika, ne?
zkusil jsem to obvyklým způsobem - nainstaloval go, vyzkoušel si to a zřejmě jsem to chápal blbě, představoval jsem si něco jako conditional conformance ze swiftuRule of thumb: neočekávat od Go nic, co by mohlo budit dojem pokročilosti ;)
Chapu, ze pristup Go ma svoje vyhody a muze byt prijemny, na druhou stranu zase nevidim zadnou zvlastni komplikaci v tom, ze implementaci interface/traitu musi autor explicitne deklarovat. Typovy system to pozna, prekladac to validuje, prace s tim prakticky zadna neniNo kdyz muze prekladac najit definici traitu kdekoli ve zdrojacich, tak uplne stejne muze najit i ten konflikt, takze to mi uplne jako argument neprijde.
přijde Karel a bezelstně začne ten interface s tím typem používat, jenže ono to dělá trochu něco jinéhoK tomu ale může dojít i bez interfejsů. Pokud si jenom podle názvu metody myslím, že něco dělá, tak se můžu splést :)
Čekal jsem, kdy na to přijdete. Zen of Python: Explicit is better than implicit.přijde Karel a bezelstně začne ten interface s tím typem používat, jenže ono to dělá trochu něco jinéhoK tomu ale může dojít i bez interfejsů. Pokud si jenom podle názvu metody myslím, že něco dělá, tak se můžu splést :)
Celkem ale souhlasím, asi to docela nebezpečné je.
(Takže ve finále jsem došel k tomu, že vlastně ty implicitní interfejsy vůbec nejsou dobrej nápad :)) )
Zen of Python: Explicit is better than implicit.Třeba explicit types?
Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
třebaTesty se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
inc :: Nat n -> Nat (S n)
Většina tvých tvrzení je všeobecná.Zen of Python: Explicit is better than implicit.Třeba explicit types?
Zen of the World: všechna všeobecná tvrzení jsou nepravdivá.
to ano, ten můj chybný dojem byl, že když všechny prvky struktury (nebo pole) jsou typu který implementuje rozhraní, tak struktura implementuje rozhranípředstavoval jsem si něco jako conditional conformance ze swiftuTa ale k životu potřebuje generika, ne?
třebaTesty se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.Kód: [Vybrat]inc :: Nat n -> Nat (S n)
Co je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?třebaTesty se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.Kód: [Vybrat]inc :: Nat n -> Nat (S n)
inc je funkce.Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
inc je funkce.
Otázka nezní zda lze typem zcela nahradit testy, ale vaše opačné tvrzení, že typy lze nahradit testy.
jasně, tady je kód, přeju příjemnou zábavutřebaTesty se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.Kód: [Vybrat]inc :: Nat n -> Nat (S n)
To vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?
{-# LANGUAGE GADTs, TypeInType #-}
import Data.Kind
data Nat :: Type where
Z :: Nat
S :: !Nat -> Nat
data Nat' :: Nat -> Type where
Z' :: Nat' Z
S' :: !(Nat' n) -> Nat' (S n)
inc :: Nat' n -> Nat' (S n)
inc = S'
haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typCo je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?třebaTesty se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.Kód: [Vybrat]inc :: Nat n -> Nat (S n)
Nečetl jsem poctivě celou diskusi, ale předpokládám, že takové tvrzení tu nezaznělo. Diskuse běží na téma potřebnosti statických typů k ověření bezchybnosti programu, nikoliv nahrazení typů.inc je funkce.Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Otázka nezní zda lze typem zcela nahradit testy, ale vaše opačné tvrzení, že typy lze nahradit testy.
Nečetl jsem poctivě celou diskusi, ale předpokládám, že takové tvrzení tu nezaznělo. Diskuse běží na téma potřebnosti statických typů k ověření bezchybnosti programu, nikoliv nahrazení typů.inc je funkce.Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Otázka nezní zda lze typem zcela nahradit testy, ale vaše opačné tvrzení, že typy lze nahradit testy.
Takze to je tohle? Tedy neco jako preddefinovany test?haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typCo je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?třebaTesty se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.Kód: [Vybrat]inc :: Nat n -> Nat (S n)
Aha, tak to je nesmysl, i testy se opiraji o typovy system.Nečetl jsem poctivě celou diskusi, ale předpokládám, že takové tvrzení tu nezaznělo. Diskuse běží na téma potřebnosti statických typů k ověření bezchybnosti programu, nikoliv nahrazení typů.inc je funkce.Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.
Otázka nezní zda lze typem zcela nahradit testy, ale vaše opačné tvrzení, že typy lze nahradit testy.
Co je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typ
Aha, tak to je nesmysl, i testy se opiraji o typovy system.
využití expresivního typového systému (GADT, zobecněné algebraické typy)Takze to je tohle? Tedy neco jako preddefinovany test?haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typCo je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?třebaTesty se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.Kód: [Vybrat]inc :: Nat n -> Nat (S n)
nijak mě to nelákáCo je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typ
Co takhle použít nějaký objektovější jazyk, třeba Scalu?
nijak mě to nelákáCo takhle použít nějaký objektovější jazyk, třeba Scalu?Co je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typ
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.
Furt lepší než PHP.nijak mě to nelákáCo takhle použít nějaký objektovější jazyk, třeba Scalu?Co je to za jazyk, není to srozumitelné? Dokáže to zajistit to, že hodnota tohoto typu v jedné funkci může být zvýšena právě o jedna, v jiné právě o dva a v třetí může být změněna v závislosti na jiné hodnotě jiného typu a tim zkontrolovat funkčnost funkce? Co v případě, že funkce vrací jiný typ, než je parametr. Je kontrola správnosti funkce součástí vstupního nebo výstupního typu?haskell, viz výše, je to typ funkce, která inkrementuje přirozené číslo, pokud by měla dělat něco jiného, měla by jiný typ
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?
Máš něco proti kruhovým definicím?To vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?třebaTesty se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.Kód: [Vybrat]inc :: Nat n -> Nat (S n)
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.jestli je dynamické typování tak zásadní pro OOP jak tu mnozí tvrdí, pak je ukázka možností statického typování zcela relevantní
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.jestli je dynamické typování tak zásadní pro OOP jak tu mnozí tvrdí, pak je ukázka možností statického typování zcela relevantní
Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
...
def inc(x):
if not isinstance(x, Int):
raise Exception()
...
třebaKód: [Vybrat]inc :: Nat n -> Nat (S n)
To vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.jestli je dynamické typování tak zásadní pro OOP jak tu mnozí tvrdí, pak je ukázka možností statického typování zcela relevantní
Statické typování je pro OOP irelevantní.
A jak souvisí Java/C# s OOP?Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.jestli je dynamické typování tak zásadní pro OOP jak tu mnozí tvrdí, pak je ukázka možností statického typování zcela relevantní
Statické typování je pro OOP irelevantní.
Co se dovzdelat a zkusit se doucit trebas tu Scalu/F# nebo alespon Javu/C#?
To skutecne neodhali, ale to neodhali ani zadny test na inc.. Testem na funkce tezko otestujes, ze jsi pri volani te funkce zadal spravne parametry.třebaTo vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?Kód: [Vybrat]inc :: Nat n -> Nat (S n)
inc5 :: Nat n -> Nat (S n)
inc5 (x: Int) = x + 7
Pozor na to tykání!!!
Když nad tím přemýšlím, tak musím uznat, že TYPOVÉ testy prováděné PŘI PŘEKLADU nahradit nejdou (běhové pochopitelně ano, vizte výše).
Jestliže i naopak prakticky nejdou nahradit výpočetní testy typovými
pak už zůstává jen otázka, zda a kdy se vyplatí použít typový systém a kdy netypový. Osobně upřednostňuju ten volnější, netypový, ale to je na každém.
Aha, tak to je nesmysl, i testy se opiraji o typovy system.Nečetl jsem poctivě celou diskusi, ale předpokládám, že takové tvrzení tu nezaznělo. Diskuse běží na téma potřebnosti statických typů k ověření bezchybnosti programu, nikoliv nahrazení typů.
GenČtverce = func(x) {
return {
_strana: x,
strana: func() {return _strana},
plocha: func() {return _strana^2}
}
testČtverce = func() {
assert (GenČtverce(5).plocha == 25) # test identity
}
(S n) není o 5To skutecne neodhali, ale to neodhali ani zadny test na inc.. Testem na funkce tezko otestujes, ze jsi pri volani te funkce zadal spravne parametry.třebaTo vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?Kód: [Vybrat]inc :: Nat n -> Nat (S n)
Měl jsem na mysli tohle:Kód: [Vybrat]inc5 :: Nat n -> Nat (S n)
inc5 (x: Int) = x + 7
Jak to odhalí chybu? Chtěl jsem zvýšit o 5, ale místo toho se mi hodnota zvýší o 7.
Měl jsem na mysli tohle:Kód: [Vybrat]inc5 :: Nat n -> Nat (S n)
inc5 (x: Int) = x + 7
Jak to odhalí chybu? Chtěl jsem zvýšit o 5, ale místo toho se mi hodnota zvýší o 7.
inc5 :: Nat n -> Nat (S (S (S (S (S n)))))
inc5 (x: Int) = x + 7
A jak souvisí Java/C# s OOP?Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.jestli je dynamické typování tak zásadní pro OOP jak tu mnozí tvrdí, pak je ukázka možností statického typování zcela relevantní
Statické typování je pro OOP irelevantní.
Co se dovzdelat a zkusit se doucit trebas tu Scalu/F# nebo alespon Javu/C#?
Tak nám aspoň přestaň vnucovat Haskell, který s OOP nesouvisí.
Proč? Mě to zajímá.
Citacepak už zůstává jen otázka, zda a kdy se vyplatí použít typový systém a kdy netypový. Osobně upřednostňuju ten volnější, netypový, ale to je na každém.
Samozrejme odpoved je ten typovy, ten umoznuje oboji. Netypovy jen to druhe.
(S n) není o 5To skutecne neodhali, ale to neodhali ani zadny test na inc.. Testem na funkce tezko otestujes, ze jsi pri volani te funkce zadal spravne parametry.třebaTo vypadá jako kruhová definice. Skutečně to odhalí chybu, když místo čísla 5 tam dám omylem číslo 7?Kód: [Vybrat]inc :: Nat n -> Nat (S n)
Měl jsem na mysli tohle:Kód: [Vybrat]inc5 :: Nat n -> Nat (S n)
inc5 (x: Int) = x + 7
Jak to odhalí chybu? Chtěl jsem zvýšit o 5, ale místo toho se mi hodnota zvýší o 7.
To neni metrika, proste si to nemam kde zkusit a z toho plyne muj osobni nezajem.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Nahradit jdou a to typingem.Taky si to myslím. Typový systém nahradit testy jde.Nahraď mi prosím typy za testy u tohoto příkladu:Kód: [Vybrat]inc (x: Int) = x + 1
...
Pozor na to tykání!!!
V Pytónu:Kód: [Vybrat]def inc(x):
if not isinstance(x, Int):
raise Exception()
...
Když nad tím přemýšlím, tak musím uznat, že TYPOVÉ testy prováděné PŘI PŘEKLADU nahradit nejdou (běhové pochopitelně ano, vizte výše). Jestliže i naopak prakticky nejdou nahradit výpočetní testy typovými, pak už zůstává jen otázka, zda a kdy se vyplatí použít typový systém a kdy netypový. Osobně upřednostňuju ten volnější, netypový, ale to je na každém.
To neni metrika, proste si to nemam kde zkusit a z toho plyne muj osobni nezajem.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Srovnej. Implicitni pretypovani v jazyce C se take opira o staticke typy a prameni z toho nestabilita a chybovost programu napsanych v C. Je tedy nestabilitu a chybovost programu mozno oznacit za nevyhodu statickych typu? Nebo je to vlastnost jazyka, nikoliv statickych typu?
Zadny kam bych mohl instalovat cizi software. Online mohu zkusit.Ty nemas pocitac? :-OTo neni metrika, proste si to nemam kde zkusit a z toho plyne muj osobni nezajem.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Kazdopadne jsou i REPLy online. A cele IDE online byvalo taky.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Srovnej. Implicitni pretypovani v jazyce C se take opira o staticke typy a prameni z toho nestabilita a chybovost programu napsanych v C. Je tedy nestabilitu a chybovost programu mozno oznacit za nevyhodu statickych typu? Nebo je to vlastnost jazyka, nikoliv statickych typu?Timhle muzes ukazat na Hindenburg a odstrelit tim myslenku na letani...
Dulezite je, ze reseni existuje a neco prinasi. A bez statickeho typovani ti fungovat nebude.
Dukaz pro toto tvrzeni?Timhle muzes ukazat na Hindenburg a odstrelit tim myslenku na letani...Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Srovnej. Implicitni pretypovani v jazyce C se take opira o staticke typy a prameni z toho nestabilita a chybovost programu napsanych v C. Je tedy nestabilitu a chybovost programu mozno oznacit za nevyhodu statickych typu? Nebo je to vlastnost jazyka, nikoliv statickych typu?
Dulezite je, ze reseni existuje a neco prinasi. A bez statickeho typovani ti fungovat nebude.
Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
return x+1
if __name__ == '__main__':
print(inc(3))
print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.Normální? Oba jsou to multiparadigmatické jazyky.Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Zadny kam bych mohl instalovat cizi software. Online mohu zkusit.Ty nemas pocitac? :-OTo neni metrika, proste si to nemam kde zkusit a z toho plyne muj osobni nezajem.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Kazdopadne jsou i REPLy online. A cele IDE online byvalo taky.
Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.Normální? Oba jsou to multiparadigmatické jazyky.Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.No vida, už jsi prozřel.Kód: [Vybrat]~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
return x+1
if __name__ == '__main__':
print(inc(3))
print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
Měl jsem na mysli tohle:Kód: [Vybrat]inc5 :: Nat n -> Nat (S n)
inc5 (x: Int) = x + 7
Jak to odhalí chybu? Chtěl jsem zvýšit o 5, ale místo toho se mi hodnota zvýší o 7.
Tohle odhali chybu hned - nezkompiluje se to. Protoze v typu stale rikas, ze chces zvysovat o 1. Neco jineho by bylo neco jako:Kód: [Vybrat]inc5 :: Nat n -> Nat (S (S (S (S (S n)))))
inc5 (x: Int) = x + 7
Uz jsme to tady pred casem rozebirali. Jisty si muzes byt jen tak, ze to napises dvakrat a porovnas. Testy a dostatecne silny typovy system jsou jen dve ruzne moznosti, jak se priblizit tomu "napsat to dvakrat". Oba na to jdou z jine strany, takze v tom priblizeni maji vyhody a nevyhody. Ale ciste teoreticky (v tom limitnim pripade) lze jedno zcela nahradit druhym, je to vec vkusu.
Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.Kód: [Vybrat]~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
return x+1
if __name__ == '__main__':
print(inc(3))
print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
def inc(x):
return 1 + x
if __name__ == "__main__":
print(inc(3))
print(inc('4'))
4
Traceback (most recent call last):
File "inc.py", line 9, in <module>
print(inc('4'))
File "inc.py", line 5, in inc
return 1 + x
TypeError: unsupported operand type(s) for +: 'int' and 'str'
To nemyslíš vážně s tím impulzem pro vynalézáním lepšího létání, že ne? Ta tragédie se stala v roce 1937. V té době už takové impulsy nebyly potřeba. Vzducholodě byly a kupodivu stále jsou (nyní zažívají určitou renesanci) poměrně okrajovou a velice speciální záležitostí, určenou pro specifické účely.Timhle muzes ukazat na Hindenburg a odstrelit tim myslenku na letani...Dukaz pro toto tvrzeni?
Dulezite je, ze reseni existuje a neco prinasi. A bez statickeho typovani ti fungovat nebude.
Co se tyce Hindenburgu, nemas pravdu, ze to odstreli myslenku na letani. Stejne jako staticke typy neodstrali myslenku na programovani. Naopak to byl impulz pro vynalezani lepsiho letani, stroju tezsi nez vzduch.
Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
Takže o čom to tu vlastne točíte? O tomto, že staticky typované jazyky sú lepšie? Iste, väčšinou sa s nimi bude robiť o niečo lepšie. Ale že dynamicky typované sú zlé, resp. úplne nefunkčné? Ani náhodou.
nebo se přidá pár type families a napíše se třebaAha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.
Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)
hnus, ale taky úplně umělý příklad
nebo se přidá pár type families a napíše se třebaAha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.
Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.Kód: [Vybrat]Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)
hnus, ale taky úplně umělý příklad
jestli potřebujete funkci inc1234567 tak dobře vám taknebo se přidá pár type families a napíše se třebaAha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.
Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.Kód: [Vybrat]Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)
hnus, ale taky úplně umělý příklad
A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
Takže o čom to tu vlastne točíte? O tomto, že staticky typované jazyky sú lepšie? Iste, väčšinou sa s nimi bude robiť o niečo lepšie. Ale že dynamicky typované sú zlé, resp. úplne nefunkčné? Ani náhodou.
Myslim, ze slo o tu prvni otazku, a nikoli o tu druhou. Skoro nikdo tu netvrdil to druhe.
Už před nehodou Hindenburgu došlo k řadě nehod vzducholodí, většinou způsobených špatným počasím. Žádná vážnější nehoda se však netýkala Zeppelinů, ty držely pozoruhodný rekord v bezpečnosti letecké dopravy; např. Graf Zeppelin bezpečně nalétal více než 1,6 miliónu kilometrů, mj. i první úplný oblet zeměkoule a dopravila 12000 pasažérů. Firma Zeppelin hrdě zdůrazňovala, že na jejích vzducholodích se nikdy nezranil jediný pasažér.To nemyslíš vážně s tím impulzem pro vynalézáním lepšího létání, že ne? Ta tragédie se stala v roce 1937. V té době už takové impulsy nebyly potřeba. Vzducholodě byly a kupodivu stále jsou (nyní zažívají určitou renesanci) poměrně okrajovou a velice speciální záležitostí, určenou pro specifické účely.Timhle muzes ukazat na Hindenburg a odstrelit tim myslenku na letani...Dukaz pro toto tvrzeni?
Dulezite je, ze reseni existuje a neco prinasi. A bez statickeho typovani ti fungovat nebude.
Co se tyce Hindenburgu, nemas pravdu, ze to odstreli myslenku na letani. Stejne jako staticke typy neodstrali myslenku na programovani. Naopak to byl impulz pro vynalezani lepsiho letani, stroju tezsi nez vzduch.
Na vyvoj mam pocitac, ale vzhledem k citlivosti nekterych zakazek s ohledem na kybernetickou bezpecnost si tam nemohu stahovat a instalovat kdejaky brak z netu. Na hrani si mi plne staci tablet....nebo si třeba koupit počítač? Pro programátora je to celkem užitečné vybavení.Zadny kam bych mohl instalovat cizi software. Online mohu zkusit.Ty nemas pocitac? :-OTo neni metrika, proste si to nemam kde zkusit a z toho plyne muj osobni nezajem.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Kazdopadne jsou i REPLy online. A cele IDE online byvalo taky.
:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.Tak to jsou normální.Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.Normální? Oba jsou to multiparadigmatické jazyky.Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Tim ze jsem vyvratil vase tvrzeni, ze typova kontrola pred spustenim programu je domenou statickych typu? :-)Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.No vida, už jsi prozřel.Kód: [Vybrat]~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
return x+1
if __name__ == '__main__':
print(inc(3))
print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
To co ukazujes ty je dynamicka kontrola za chodu programu, to co ukazuji ja je kontrola pred spustenim. Program mypy je type checker. Nainstaluj si ho prikazem 'python -m pip install -U mypy'Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.Kód: [Vybrat]~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
return x+1
if __name__ == '__main__':
print(inc(3))
print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
Ono to funguje i bez explicitní deklarace typů:Kód: [Vybrat]def inc(x):
return 1 + x
if __name__ == "__main__":
print(inc(3))
print(inc('4'))Kód: [Vybrat]4
Traceback (most recent call last):
File "inc.py", line 9, in <module>
print(inc('4'))
File "inc.py", line 5, in inc
return 1 + x
TypeError: unsupported operand type(s) for +: 'int' and 'str'
def inc(x:int)->int:
return x+1
if __name__ == '__main__':
print(inc(3))
if False:
print(inc('4'))
To co ukazujes ty je dynamicka kontrola za chodu programu, to co ukazuji ja je kontrola pred spustenim. Program mypy je type checker. Nainstaluj si ho prikazem 'python -m pip install -U mypy'
Rozdil poznas, kdyz kod upravis naKód: [Vybrat]def inc(x:int)->int:
return x+1
if __name__ == '__main__':
print(inc(3))
if False:
print(inc('4'))
def inc(x:int)->int:
return x+1
if False:
print(inc(3))
print(inc('4'))
Tim ze jsem vyvratil vase tvrzeni, ze typova kontrola pred spustenim programu je domenou statickych typu? :-)Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.No vida, už jsi prozřel.Kód: [Vybrat]~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
return x+1
if __name__ == '__main__':
print(inc(3))
print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
Jedna se o naprosto primitivni funkci. Predstav si implementaci neceho slozitejsiho, treba md5(). Jak si typem overis vsechny pripady? Nebo jak si overis vsechny pripady u formatmonth() z calendar?Aha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?
V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.
Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.
Nicmene zatimco to prvni to donuti typechecker overit pro vsechny pripady, to druhe overi jen nektere situace. Nevyhodou prvniho pristupu ovsem je, ze nekdy to ten typechecker taky dokazat nemusi umet.
>>> import calendar
>>> print(calendar.LocaleTextCalendar().formatmonth(2019, 2))
February 2019
Mo Tu We Th Fr Sa Su
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28
A to jsme jeste porad u jednoduchych veci. Ted si predstav, ze mas overovat spravnost sloziteho vystupu typu webova stranka, video nebo hudebni skladba.
Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).jestli potřebujete funkci inc1234567 tak dobře vám taknebo se přidá pár type families a napíše se třebaAha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.
Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.Kód: [Vybrat]Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)
hnus, ale taky úplně umělý příklad
A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
Jiste, protoze vyrazy se porad vyhodnocuji az za chodu programu a typy jsou svazane s hodnotami. Nebo si myslis, ze python je staticky jazyk? Interpret pythonu zustava naprosto stejny a type hinty ignoruje, jsou vyhrazeny pro externi nastroje. Uz se blizite k pochopeni toho, co jsou ve skutecnosti staticke typy a ze jim prisuzujete vlastnosti, ktere jim nejsou vlastni a lze jich dosahnout alternativne.Tim ze jsem vyvratil vase tvrzeni, ze typova kontrola pred spustenim programu je domenou statickych typu? :-)Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.No vida, už jsi prozřel.Kód: [Vybrat]~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
return x+1
if __name__ == '__main__':
print(inc(3))
print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
Myslis, ze muzes porad mluvit to dynamickem jazyku kdyz pouzijes staticky type checker?
Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).jestli potřebujete funkci inc1234567 tak dobře vám taknebo se přidá pár type families a napíše se třebaAha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.
Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.Kód: [Vybrat]Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)
hnus, ale taky úplně umělý příklad
A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
haskell není jazyk s nejpokročilejším typovým systémem, ale je hodně rozšířený a ma jiné výhodyTohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).jestli potřebujete funkci inc1234567 tak dobře vám taknebo se přidá pár type families a napíše se třebaAha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.
Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.Kód: [Vybrat]Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)
hnus, ale taky úplně umělý příklad
A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?
inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
přírůstek můžete přepsat podle potřeby, pokud se liší v typu a těle, neprojde typecheckerem
pro srovnání idris:Pripomnel jsi mi, ze jsem se chtel - az budu mit nekdy trochu vic casu na ptakoviny* - na nejaky jazyk s dependent types podivat. Idris je horky kandidat. Pouzival jsi ho nekdy trochu vic? Doporucil bys ho na hrani nebo radsi neco jinyho?Kód: [Vybrat]inc : (n : Nat) -> (m : Nat ** m = n + 1)
přírůstek můžete přepsat podle potřeby, pokud se liší v typu a těle, neprojde typecheckerem
inc n = (n + 1 ** Refl)
znám jenom letmo idris a agdu jsem viděl z vlaku... ale doporučil, příbuznost s haskellem je IMHO velká výhoda, jinak ten-jehož-jméno-je-nestálé o tom asi ví vícpro srovnání idris:Pripomnel jsi mi, ze jsem se chtel - az budu mit nekdy trochu vic casu na ptakoviny* - na nejaky jazyk s dependent types podivat. Idris je horky kandidat. Pouzival jsi ho nekdy trochu vic? Doporucil bys ho na hrani nebo radsi neco jinyho?Kód: [Vybrat]inc : (n : Nat) -> (m : Nat ** m = n + 1)
přírůstek můžete přepsat podle potřeby, pokud se liší v typu a těle, neprojde typecheckerem
inc n = (n + 1 ** Refl)
* takze nejspis nejdriv tak v duchodu
Hic svnt dracones ???pro srovnání idris:Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).jestli potřebujete funkci inc1234567 tak dobře vám taknebo se přidá pár type families a napíše se třebaAha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.
Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.Kód: [Vybrat]Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)
hnus, ale taky úplně umělý příklad
A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?Kód: [Vybrat]inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
Jako první bych ho nedoporučil, má implicitní argumenty, při učení člověk jen zírá, kde se ztrácí proměnné.pro srovnání idris:Pripomnel jsi mi, ze jsem se chtel - az budu mit nekdy trochu vic casu na ptakoviny* - na nejaky jazyk s dependent types podivat. Idris je horky kandidat. Pouzival jsi ho nekdy trochu vic? Doporucil bys ho na hrani nebo radsi neco jinyho?Kód: [Vybrat]inc : (n : Nat) -> (m : Nat ** m = n + 1)
přírůstek můžete přepsat podle potřeby, pokud se liší v typu a těle, neprojde typecheckerem
inc n = (n + 1 ** Refl)
* takze nejspis nejdriv tak v duchodu
Jako první bych ho nedoporučil, má implicitní argumenty, při učení člověk jen zírá, kde se ztrácí proměnné.Takze radsi Agdu? Nebo jeste neco jinyho?
Tak to už je šílené :D :D :D tolik vnořených komentářůHic svnt dracones ???pro srovnání idris:Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).jestli potřebujete funkci inc1234567 tak dobře vám taknebo se přidá pár type families a napíše se třebaAha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.
Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.Kód: [Vybrat]Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)
hnus, ale taky úplně umělý příklad
A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?Kód: [Vybrat]inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
Tak to už nezhoršujte ;)Tak to už je šílené :D :D :D tolik vnořených komentářůHic svnt dracones ???pro srovnání idris:Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).jestli potřebujete funkci inc1234567 tak dobře vám taknebo se přidá pár type families a napíše se třebaAha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.
Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.Kód: [Vybrat]Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)
hnus, ale taky úplně umělý příklad
A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?Kód: [Vybrat]inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
Coze?Tak to už nezhoršujte ;)Tak to už je šílené :D :D :D tolik vnořených komentářůHic svnt dracones ???pro srovnání idris:Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).jestli potřebujete funkci inc1234567 tak dobře vám taknebo se přidá pár type families a napíše se třebaAha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.
Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.Kód: [Vybrat]Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)
hnus, ale taky úplně umělý příklad
A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?Kód: [Vybrat]inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
Na naučení asi (nebo spíše rozhodně) ne. Na první lekce Pie (z knihy The little typer), nemá implicitní parametry, takže jsou všechna odvození (důkazy) názorně vidět.Jako první bych ho nedoporučil, má implicitní argumenty, při učení člověk jen zírá, kde se ztrácí proměnné.Takze radsi Agdu? Nebo jeste neco jinyho?
::)Coze?Tak to už nezhoršujte ;)Tak to už je šílené :D :D :D tolik vnořených komentářůHic svnt dracones ???pro srovnání idris:Tohle uz ma jiny principialni problem. Ten typ je radove slozitejsi nez sama funkce, takze je tu otazka, kdo bude kontrolovat spravnost zapisu typu :-).jestli potřebujete funkci inc1234567 tak dobře vám taknebo se přidá pár type families a napíše se třebaAha, takže úplně stejně to udělám, když budu chtít napsat funkci inc4096, která zvýší hodnotu o 4096?V podstate jo, akorat pouzijes silnejsi typovy system, kde se to "funkce zvysuje o 4096" zapise v typech rovnou s konstantou 4096.
Neni to pak (co do psani) odlisne od toho, mit test, ktery overi, jestli je vystup skutecne o 4096 vyssi nez vstup.Kód: [Vybrat]Nat' n -> Nat' (Plus (Exp (S (S Z)) (S (S (S (S (S (S (S (S (S (S (S (S Z))))))))))))) n)
hnus, ale taky úplně umělý příklad
A co třeba kdybych chtěl funkci inc1234567, která bude přidávat 1234567? To budu zase vymýšlet podobnou bejkárnu?Kód: [Vybrat]inc : (n : Nat) -> (m : Nat ** m = n + 1)
inc n = (n + 1 ** Refl)
Na naučení asi (nebo spíše rozhodně) ne. Na první lekce Pie (z knihy The little typer), nemá implicitní parametry, takže jsou všechna odvození (důkazy) názorně vidět.Dik!
Je to na githubu.Na naučení asi (nebo spíše rozhodně) ne. Na první lekce Pie (z knihy The little typer), nemá implicitní parametry, takže jsou všechna odvození (důkazy) názorně vidět.Dik!
Je to na githubu.Jo, videl jsem.
:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.Tak to jsou normální.Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.Normální? Oba jsou to multiparadigmatické jazyky.Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.Tak to jsou normální.Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.Normální? Oba jsou to multiparadigmatické jazyky.Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.Tak to jsou normální.Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.Normální? Oba jsou to multiparadigmatické jazyky.Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Nejen sve. Jak uz jsem tu uvedl, pragmaticky me zajima jen to, co ma pro me prinos, ted a nebo v budoucnu.Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.Tak to jsou normální.Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.Normální? Oba jsou to multiparadigmatické jazyky.Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Nejen sve. Jak uz jsem tu uvedl, pragmaticky me zajima jen to, co ma pro me prinos, ted a nebo v budoucnu.Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.Tak to jsou normální.Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.Normální? Oba jsou to multiparadigmatické jazyky.Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Prave naopak.To asi zůstaneš hodně omezenej.Nejen sve. Jak uz jsem tu uvedl, pragmaticky me zajima jen to, co ma pro me prinos, ted a nebo v budoucnu.Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.Tak to jsou normální.Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.Normální? Oba jsou to multiparadigmatické jazyky.Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Tak jak jinak chceš fachidiocii říkat?Prave naopak.To asi zůstaneš hodně omezenej.Nejen sve. Jak uz jsem tu uvedl, pragmaticky me zajima jen to, co ma pro me prinos, ted a nebo v budoucnu.Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.Tak to jsou normální.Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.Normální? Oba jsou to multiparadigmatické jazyky.Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Urážkami na tom nic nezměníš.Tak jak jinak chceš fachidiocii říkat?Prave naopak.To asi zůstaneš hodně omezenej.Nejen sve. Jak uz jsem tu uvedl, pragmaticky me zajima jen to, co ma pro me prinos, ted a nebo v budoucnu.Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.Tak to jsou normální.Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.Normální? Oba jsou to multiparadigmatické jazyky.Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Urážkami na tom nic nezměníš.
Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky (a i to je dnes moc, aby sis u všech udržoval expertní znalosti, včetně souvisejícího ekosystému), než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. Rozdíl mezi mnou a tebou je jako rozdíl mezi praktickým hudebníkem a hudebním kritikem. Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit. A chceš-li to nazývat idiocií, prosím. Co ale říct o vás, co žijete v přesvědčení, že když se program podaří zkompilovat, tak je v podstatě hotovo. Vůbec netušíte, co obnáší praktická tvorba software, který není jen na hraní. To pochopíte, až se ze školy dostanete do praxe.
Urážkami na tom nic nezměníš.Tak jak jinak chceš fachidiocii říkat?Prave naopak.To asi zůstaneš hodně omezenej.Nejen sve. Jak uz jsem tu uvedl, pragmaticky me zajima jen to, co ma pro me prinos, ted a nebo v budoucnu.Jinymi slovy - generalizujes sve zkusenosti s patlanim v jedne oblasti na cely obor.Pro mě jsou zajímavé zakázky. Nikdo z našich klientů (podniková sféra) takové obskurnosti nepoptává.:-)) Ohledne moznosti zneuznaneho a neuspesneho haskellu mi muzes veset buliky na nos, ohledne bezne pouzivanych jazyku v komercni sfere nikoliv.Tak to jsou normální.Normalni, to jest ty, ktere se bezne pouzivaji v komercni praxi.Normální? Oba jsou to multiparadigmatické jazyky.Zatim to spis vypada na vlastnost funkcionalnich jazyku, porad cekam na nejaky normalni. :-)Ale houby, umi to s drobnymi rozdily kopec jazyku (o Scale a F# tu uz rec sla), ten Haskell se proste bere jako "zlaty standard", co ho navic pomalu kazdy zna.Neni to demonstrace vyhod statickych typu, pokud je haskell jediny jazyk, ktery to umi. V takovem pripade je to demonstrace vyhoda haskellu. Na tom zalozene tvrzeni o statickych typech je argumentacni klam, predcasna generalizace.Tak jsem chtel overit tu haskell ukazku a zjistil, ze haskell je tak okrajovy jazyk, ze neni k dispozici v termuxu. Hledal jsem balicek s nazvem haskell nebo ghc. Seznam balicku: https://pastebin.com/kdfgUFRt To jen upevnuje me presvedceni, ze nema smysl ztracet cas okrajovymi nepodporovanymi jazyky. Je schopen to nekdo predvest v jinem jazyku ktery je mezi balicky? (je tam kde co, rust, vala, erlang, java, ocaml, golang, clang, racket, ...) Nebo se jedna ciste o schopnost haskellu, ktera je tu mylne prisuzovana jazykum se statickymi typy?To je tak pitomá metrika (přítomnost v termuxu) a tak pitomý argument (když je to v Haskellu a opírá se to o statické typy, tak to nutně je demonstrace výhod statických typů)...
To je takovy problem se podivat do inzeratu? Scala neni zdaleka takova masovka jako trebas Java, ale misto se najde bez problemu. Pokud zuzis sve pozadavky na "zajimava prace", tak se ten pomer navic dost zlepsi...
Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky (a i to je dnes moc, aby sis u všech udržoval expertní znalosti, včetně souvisejícího ekosystému), než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. Rozdíl mezi mnou a tebou je jako rozdíl mezi praktickým hudebníkem a hudebním kritikem. Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit. A chceš-li to nazývat idiocií, prosím. Co ale říct o vás, co žijete v přesvědčení, že když se program podaří zkompilovat, tak je v podstatě hotovo. Vůbec netušíte, co obnáší praktická tvorba software, který není jen na hraní. To pochopíte, až se ze školy dostanete do praxe.
Co ale říct o vás, co žijete v přesvědčení, že když se program podaří zkompilovat, tak je v podstatě hotovo.
Vůbec netušíte, co obnáší praktická tvorba software, který není jen na hraní. To pochopíte, až se ze školy dostanete do praxe.
Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky [...] než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. [...] Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit.Mě taky zajímá praktická stránka věci. A v praxi jsem zjistil, že je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata. Protože znalost nového paradigmatu ti úplně změní perspektivu, pohled na věc. Zkušenost s jinými paradigmaty tě může výrazně inspirovat k lepším řešením nebo se vyvarovat chyb, které jsou způsobené tím, že máš klapky na očích (známé "když mám v ruce kladivo, všechno je hřebík").
Ja pracujem na projekte kde oop je dost zastupene a tolko abstrakcie som este nikde nevidel a mam pocit, ze je to niekedy az prekomplikovane a uplne zbytocne.
typedef int delkaStrany_t;
typedef int obvod_t;
obvod_t obvodObdelniku( delkaStrany_t stranaA, delkaStrany_t stranaB) {
return 2 * (obvod_t) soucetDelek( stranaA, stranaB );
}
...
delkaStrany_t SoucetDelek( delkaStrany_t stranaA, delkaStrany_t stranaB) {
return (delkaStrany_t) soucetIntu( (int) stranaA, (int) stranaB );
}
...
int soucetIntu( int a, int b ) {
return a + b;
}
Mě taky zajímá praktická stránka věci. A v praxi jsem zjistil, že je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata. Protože znalost nového paradigmatu ti úplně změní perspektivu, pohled na věc. Zkušenost s jinými paradigmaty tě může výrazně inspirovat k lepším řešením nebo se vyvarovat chyb, které jsou způsobené tím, že máš klapky na očích (známé "když mám v ruce kladivo, všechno je hřebík").
Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky [...] než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. [...] Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit.Mě taky zajímá praktická stránka věci. A v praxi jsem zjistil, že je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata. Protože znalost nového paradigmatu ti úplně změní perspektivu, pohled na věc. Zkušenost s jinými paradigmaty tě může výrazně inspirovat k lepším řešením nebo se vyvarovat chyb, které jsou způsobené tím, že máš klapky na očích (známé "když mám v ruce kladivo, všechno je hřebík").
Např. alespoň letmá znalost funkcionálního programování je afaik výborná proto, že se naučíš explicitně přemýšlet nad stavem - co s ním děláš, kam ho posíláš, kde se mění, kde se nemění atd. I v nefunkcionálním jazyce to může výrazně pomoct vyhnout se race conditions, zbytečným zámkům apod.
A právě proto je dobré třeba ten Haskell (nebo Elixir, Prolog, ...) alespoň párkrát zkusit, něco málo si v tom napsat. Pohrdat jím stylem "já jsem ten fachman, vy blbečcí akademičtí, mě vaše hračky nezajímají, protože vás musím živit" je hodně stupidní a omezený. Podobně stupidní jako "vy lopaty PHPkový si vykládejte co chcete, my jsme zasvěcenci páté úrovně haskellové gnóze!" Ne nadarmo byla po tisíciletí pýcha chápaná jako největší hřích...
Takže na začátku parsování/verifikace dat na jednom místě, následná logika pak ví, že data jsou validní a jak jsou zabalený. A pokud jsou zabalený jinak, kompilátor to zatepla nabonzuje...tohle je asi ústřední filosofie silně typového funkcionálního programování "make invalid state unrepresentable"
tohle je asi ústřední filosofie silně typového funkcionálního programování "make invalid state unrepresentable"
int fn( int a, str b) {
assert(a > 0);
}
nebo fn(a, b) {
assert(isInt(a));
assert(isString(b));
assert(a > 0);
}
, Mě taky zajímá praktická stránka věci. A v praxi jsem zjistil, že je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata. Protože znalost nového paradigmatu ti úplně změní perspektivu, pohled na věc. Zkušenost s jinými paradigmaty tě může výrazně inspirovat k lepším řešením nebo se vyvarovat chyb, které jsou způsobené tím, že máš klapky na očích (známé "když mám v ruce kladivo, všechno je hřebík").
Tak ono furt platí, že
1) Jak dostanu z vnějšku nějakou hodnot, musím ji validovat -> validátor / parser tam stejně bude
2) Chybu mám zachytit a ošetřit co nejdřív.
3) Věci by měly být řešeny na jednom místě (SRP)
8) Za sebe, pokud si mám vybrat meziKód: [Vybrat]nebo
int fn( int a, str b) {
assert(a > 0);
}Kód: [Vybrat]fn(a, b) {
,
assert(isInt(a));
assert(isString(b));
assert(a > 0);
}
volím první možnost - nejenom že je s tím míň práce, ale 2/3 testů tam zůstanou a po vypnutí asserce v release.
int fn( int a, str b) {
assert(a > 0);
}
assert(isInt(a));
assert(isString(b));
fn(a, b);
Treba se naucite rozumet internim procesum jazyka, vyuzivat je a nebudete z toho vydeseny jako inkvizitor :-).Urážkami na tom nic nezměníš.
Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky (a i to je dnes moc, aby sis u všech udržoval expertní znalosti, včetně souvisejícího ekosystému), než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. Rozdíl mezi mnou a tebou je jako rozdíl mezi praktickým hudebníkem a hudebním kritikem. Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit. A chceš-li to nazývat idiocií, prosím. Co ale říct o vás, co žijete v přesvědčení, že když se program podaří zkompilovat, tak je v podstatě hotovo. Vůbec netušíte, co obnáší praktická tvorba software, který není jen na hraní. To pochopíte, až se ze školy dostanete do praxe.
Treba se naucite psat undo jako ja, operator. Sice to dela memory leaky a moc to nefunguje, ale zato mi to trvalo jenom pul dne.
8) Za sebe, pokud si mám vybrat meziKód: [Vybrat]nebo
int fn( int a, str b) {
assert(a > 0);
}Kód: [Vybrat]fn(a, b) {
,
assert(isInt(a));
assert(isString(b));
assert(a > 0);
}
volím první možnost - nejenom že je s tím míň práce, ale 2/3 testů tam zůstanou a po vypnutí asserce v release.
Ve skutečnosti však ta tvá první možnost vypadá takhle:Kód: [Vybrat]int fn( int a, str b) {
assert(a > 0);
}
assert(isInt(a));
assert(isString(b));
fn(a, b);
takže jsi nic neušetřil, ale úlohu sis zesložitil. Odebral jsi funkci odpovědnost za validaci vstupu, ale zaměstnal jsi vstupní parser. Pokud budeš chtít změnit int na float, budeš muset měnit funkci i parser. Když změníš parser, budeš muset upravit i ostatní funkce, které jsou na datech z toho parseru závislé a v tuto chvíli akceptují stále jen ten int.
Ty první dva body jsou poněkud v rozporu s bodem třetím...
Ve skutečnosti však ta tvá první možnost vypadá takhle..Houbeles, nechápeš princip. U dynamickýho typování víš maximálně ty, co ti přijde za data. Většinou ani ty ne. A kompilátor/interpret se musí rozhodovat za běhu - mít připravený všechny varianty a kontrolní mechanismus na všechno. Takže mám menší a rychlejší kód.
To je pravda, ale jen castecne. Za prve v praxi potrebujes znat vice jazyku, protoze zadny univerzalni neexistuje. Ale cim mene jich je, tim lepe jim muzes rozumet. Za druhe ruzne paradigmata jsou uzitecna, ale nepotrebujes si kvuli tomu povrchne hrat s hromadou prakticky nevyuzitelnych jazyku. V tom je prave dobry python, protoze ti umoznuje jednotliva paradigmata podle potreby prirozene kombinovat. Viz pocatek diskuse a narky nad tim, ze je to spatne a jazyk to komplikuje. Za treti netyka se to jen paradigmat, ale i metodik vyvoje, a plati to i na tady odsuzovane dynamicke rysy jazyku, kterych se tu nekteri desi. I programovani v dynamickem jazyce potrebuje jiny pohled na vec. Mozna vic jiny, nez funkcionalni programovani. Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.Pokud chceš něco dobrého a hodnotného tvořit, je lepší umět dva, tři praktické jazyky do hloubky [...] než se povrchně zabývat kdejakou obskurností, která má v praxi minimální využití. [...] Mě zajímá praktická stránka věci, to co mi pomůže reálně a dobře tvořit.Mě taky zajímá praktická stránka věci. A v praxi jsem zjistil, že je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmata. Protože znalost nového paradigmatu ti úplně změní perspektivu, pohled na věc. Zkušenost s jinými paradigmaty tě může výrazně inspirovat k lepším řešením nebo se vyvarovat chyb, které jsou způsobené tím, že máš klapky na očích (známé "když mám v ruce kladivo, všechno je hřebík").
Např. alespoň letmá znalost funkcionálního programování je afaik výborná proto, že se naučíš explicitně přemýšlet nad stavem - co s ním děláš, kam ho posíláš, kde se mění, kde se nemění atd. I v nefunkcionálním jazyce to může výrazně pomoct vyhnout se race conditions, zbytečným zámkům apod.
A právě proto je dobré třeba ten Haskell (nebo Elixir, Prolog, ...) alespoň párkrát zkusit, něco málo si v tom napsat. Pohrdat jím stylem "já jsem ten fachman, vy blbečcí akademičtí, mě vaše hračky nezajímají, protože vás musím živit" je hodně stupidní a omezený. Podobně stupidní jako "vy lopaty PHPkový si vykládejte co chcete, my jsme zasvěcenci páté úrovně haskellové gnóze!" Ne nadarmo byla po tisíciletí pýcha chápaná jako největší hřích...
To je pravda, ale jen castecne. Za prve v praxi potrebujes znat vice jazyku, protoze zadny univerzalni neexistuje. Ale cim mene jich je, tim lepe jim muzes rozumet. Za druhe ruzne paradigmata jsou uzitecna, ale nepotrebujes si kvuli tomu povrchne hrat s hromadou prakticky nevyuzitelnych jazyku. V tom je prave dobry python, protoze ti umoznuje jednotliva paradigmata podle potreby prirozene kombinovat. Viz pocatek diskuse a narky nad tim, ze je to spatne a jazyk to komplikuje. Za treti netyka se to jen paradigmat, ale i metodik vyvoje, a plati to i na tady odsuzovane dynamicke rysy jazyku, kterych se tu nekteri desi. I programovani v dynamickem jazyce potrebuje jiny pohled na vec. Mozna vic jiny, nez funkcionalni programovani. Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.
Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.Jenže svět, který se snažíme v IT modelovat/automatizovat má spíše charakter statických typů....Nikdo se nejmenuje 123456 nebo 10.60 a na výplatu dostanu vždy nějakou částku a ne stokorunčeských...takže oprávněný požadavek dynamických typů zpravidla zaznívá jen tehdy, když někdo něco generalizoval-sloučil. Navíc zákazník zpravidla požaduje ukládat data to staticky typovaných databází...v tomto případě nedává moc smysl zavádět do systému nějakou dynamickou složku.
P.S. Kadete, k těm typům. Je lepší hodinu bojovat se statickými typy, než týden hledat, proč se to číslo chová divně. Schválně, mám SessionID 231479973001 a používám to jako číslo ve formátu UINT64. Co dostanu, pokud ho první knihovna interně konvertuje do UINT32 (protože na ni od dob 32b nikdo nesáhl), druhá do INT64 (protože signed považuje za nativní formát) a pak zpátky do UINT64? Jaký budeš mít SessionID na konci toho procesu? A uspokojí tě to? Ale co, hlavní je, že ani ty tři warningy při buildu nedostaneš... A to se počítá.
Takže na začátku parsování/verifikace dat na jednom místě, následná logika pak ví, že data jsou validní a jak jsou zabalený. A pokud jsou zabalený jinak, kompilátor to zatepla nabonzuje...
Bez urazky, ale kdyz jsi prase a pouzivas praseci knihovny ktery ti hloupy session id prezvejka do tolika formatu, tak se nedivim, ze potrebujes statickou kontrolu...
Krok | | Typ | | Dekadicky | | Hexadecimálně | | Podrobnosti |
0 | | uint64 | | 231479973001 | | 0x0000000035E5481489 | | hodnota má 40b |
1 | | uint32 | | 3846706313 | | 0xE5481489 | | přišli jsme o horních 8b hodnoty |
2 | | int64 | | -448260983 | | 0xFFFFFFFFE5481489 | | bit 31 = 1 -> záporné číslo |
3 | | uint64 | | 18446744072813029651 | | 0xFFFFFFFFE5481489 | | Interpretováno jako UINT64 |
Bez urazky, ale kdyz jsi prase a pouzivas praseci knihovny ktery ti hloupy session id prezvejka do tolika formatu, tak se nedivim, ze potrebujes statickou kontrolu...
Já preferuju vlastní kód, ale nikdo ti nezaplatí vývoj vlastních knihoven. Vždycky používáš kód třetí strany a inspekce od kompilátoru se vždycky hodí (resp. je zadarmo). "Model světa" totiž musíš přechrchlat na byty, aby jim stroj rozuměl a to jsou najednou chyby jak víno. Zaokrouhlování u floatů, přetečení nebo podtečení hodnot,... Prostě je fajn si říct, že to bude tak a ještě lepší si to restriktivně vynutit.
Btw, nemusí to být jenom staticky linkovaný knihovny, může to být kombinace několika jazyků, jedna z těch věcí může běžet na jiným fyzickým stroji,... A o to je to zákařnější - není nad to, když server má 64b hodnoty, klient 32b hodnoty a vývojář se diví. A pokud nezná typy (a s tím i tyhle pasti), tak si pěkně namlátí hubu.
Můj příklad je jenom malinká ukázka, jak to dopadá, když prasata ignorujou typy:
Krok | Typ | Dekadicky | Hexadecimálně | Podrobnosti 0 | uint64 | 231479973001 | 0x0000000035E5481489 | hodnota má 40b 1 | uint32 | 3846706313 | 0xE5481489 | přišli jsme o horních 8b hodnoty 2 | int64 | -448260983 | 0xFFFFFFFFE5481489 | bit 31 = 1 -> záporné číslo 3 | uint64 | 18446744072813029651 | 0xFFFFFFFFE5481489 | Interpretováno jako UINT64
Další past je třeba float - currency. Jak to má sakra kompilátor/interpreter poznat jenom podle toho, že jsou v parsovaným stringu číslice a mezi nima čárka? To jako podle toho, že je před tím "price="? A každej typ se přitom chová jinak...
Zkrátka, volnost typu = volnost kompilátoru = volnost chování výsledné aplikace. Typ je totiž nedílná součást popisu dat. Když kompilátor neví, co použít a jenom tak tam něco práskne, tak je něco blbě v principu.
...Kdyz to dotahnu do konce a klient je spokojenej muzu zacit konecne optimalizovat....Tohle mě zaujalo.
Ano. A je to velmi špatně.Tak ono furt platí, že
1) Jak dostanu z vnějšku nějakou hodnot, musím ji validovat -> validátor / parser tam stejně bude
2) Chybu mám zachytit a ošetřit co nejdřív.
3) Věci by měly být řešeny na jednom místě (SRP)
Ty první dva body jsou poněkud v rozporu s bodem třetím. Data z vnějšku klidně nechám probublat až do objektu, který je v zvaliduje až ve chvíli, kdy s těmi daty potřebuje pracovat. Tedy naopak je validuji co nejpozději. Pokud ta data proudí z více zdrojů, tak jsou validována právě v tom jednom objektu, který se stará právě jen o tento typ dat. O data jiného typu se stará jiný objekt, i když jsou součástí toho jednoho požadavku.
Tento přístup mi umožňují dělat poměrně jednoduché kontrolery, které se o validaci nestarají, ale pouze se rozhodují, které komponenty modelu použijí a jak je zkombinují.
Ja si mezitim dovolim predvest moznost typove kontroly u dynamickeho jazyka.Kód: [Vybrat]~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
~ $ cat typehint.py
def inc(x:int)->int:
return x+1
if __name__ == '__main__':
print(inc(3))
print(inc('4'))
~ $ mypy typehint.py
typehint.py:6: error: Argument 1 to "inc" has incompatible type "str"; expected "int"
...Kdyz to dotahnu do konce a klient je spokojenej muzu zacit konecne optimalizovat....Tohle mě zaujalo.
Kdo ti tu optimalizaci zaplatí, pokud je klient už spokojený s právě hotovou verzí aplikace?
Realita te taková, že jakmile má projekťák od zákazníka akceptaci (za co nejméň nákladů = první verze se kterou je zákazník spokojený), předá to k fakturaci a ty dostaneš jinou práci.
Nejlepší jsou silně typované jazyky s pozdní vazbou ;Dto by mělo v ghc jít
Tak to se podle mě velice tragicky mýlíš. Pokud chceš nějakému paradigmatu porozumět, musíš si ho vyzkoušet pokud možno v čisté podobě. Protože jenom ta tě donutí opravdu použít daný přístup a neuhýbat jinam. Tj. pokud funkcionální, tak Haskell, ne Scalu. Na Haskellu pochopíš, o co jde, a pak v praxi už můžeš vzít tu Scalu, protože to může být ze spousty důvodů praktičtější.je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmataV tom je prave dobry python, protoze ti umoznuje jednotliva paradigmata podle potreby prirozene kombinovat.
Za druhe ruzne paradigmata jsou uzitecna, ale nepotrebujes si kvuli tomu povrchne hrat s hromadou prakticky nevyuzitelnych jazyku.Potřebuješ, protože žádný jiný způsob, jak jim porozumět, neexistuje.
Tak to se podle mě velice tragicky mýlíš. Pokud chceš nějakému paradigmatu porozumět, musíš si ho vyzkoušet pokud možno v čisté podobě. Protože jenom ta tě donutí opravdu použít daný přístup a neuhýbat jinam. Tj. pokud funkcionální, tak Haskell, ne Scalu. Na Haskellu pochopíš, o co jde, a pak v praxi už můžeš vzít tu Scalu, protože to může být ze spousty důvodů praktičtější.je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmataV tom je prave dobry python, protoze ti umoznuje jednotliva paradigmata podle potreby prirozene kombinovat.
Ne, Python opravdu není "multiparadigmatický", to je marketingový blábol. Ono v principu vůbec nic takového jako "multiparadigmatický" neexistuje, protože ta paradigmata jsou právě o tom, co ti jazyk nedovolí udělat, ne o tom, co ti dovolí. Když něco z principu nejde -> máš jistotu, že k tomu nedošlo -> máš zaručenou informaci.Za druhe ruzne paradigmata jsou uzitecna, ale nepotrebujes si kvuli tomu povrchne hrat s hromadou prakticky nevyuzitelnych jazyku.Potřebuješ, protože žádný jiný způsob, jak jim porozumět, neexistuje.
Ale nikdy jsem se od něj nic užitečného neodnesl.Myslím, že největší zkušenost, jakou může Python dát, je potvrzení lidové moudrosti, že i s malým kašpárkem se dá hrát velké divadlo ;)
Nejlepší jsou silně typované jazyky s pozdní vazbou ;DTřeba ObjC kombinující dvě výhody, extrémní rychlost Smalltalku a úžasnou paměťovou bezpečnost céčka :)
2.Kód: [Vybrat]fn(a, b) {
assert(isInt(a));
assert(isString(b));
assert(a > 0);
}
Celkem pěkný příklad, který by navozoval dojem, že je vhodnější používat variantu 2. No, je to ale dáno tím, že se předpokládá, že s údaji bude po business stránce pracovat pouze ta JEDNA funkce. Jenže tak to ve skutečnosti nebude. Business logika je často komplexní a je rozprostřena do více method/objektů/funkcí....potom při variantě 2 je nutné nějakým způsobem harmonizovat tu validaci...V tomto případě už přináší řešení 1 nesporné výhody.
Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.Jenže svět, který se snažíme v IT modelovat/automatizovat má spíše charakter statických typů....Nikdo se nejmenuje 123456 nebo 10.60 a na výplatu dostanu vždy nějakou částku a ne stokorunčeských...takže oprávněný požadavek dynamických typů zpravidla zaznívá jen tehdy, když někdo něco generalizoval-sloučil. Navíc zákazník zpravidla požaduje ukládat data to staticky typovaných databází...v tomto případě nedává moc smysl zavádět do systému nějakou dynamickou složku.
Btw, nemusí to být jenom staticky linkovaný knihovny, může to být kombinace několika jazyků, jedna z těch věcí může běžet na jiným fyzickým stroji,... A o to je to zákařnější - není nad to, když server má 64b hodnoty, klient 32b hodnoty a vývojář se diví. A pokud nezná typy (a s tím i tyhle pasti), tak si pěkně namlátí hubu.
Můj příklad je jenom malinká ukázka, jak to dopadá, když prasata ignorujou typy:Kód: [Vybrat]Krok | Typ | Dekadicky | Hexadecimálně | Podrobnosti
0 | uint64 | 231479973001 | 0x0000000035E5481489 | hodnota má 40b
1 | uint32 | 3846706313 | 0xE5481489 | přišli jsme o horních 8b hodnoty
2 | int64 | -448260983 | 0xFFFFFFFFE5481489 | bit 31 = 1 -> záporné číslo
3 | uint64 | 18446744072813029651 | 0xFFFFFFFFE5481489 | Interpretováno jako UINT64
Krok | Typ | Dekadicky | Hexadecimálně | Podrobnosti
0 | string | 231479973001 | 0x0000000035E5481489 | hodnota má 12 B
1 | string | 231479973001 | 0x0000000035E5481489 | hodnota má 12 B
2 | string | 231479973001 | 0x0000000035E5481489 | hodnota má 12 B
3 | string | 231479973001 | 0x0000000035E5481489 | hodnota má 12 B
Jinými slovy se nedělají konverze tam, kde to nikdo nepotřebuje.
Další past je třeba float - currency. Jak to má sakra kompilátor/interpreter poznat jenom podle toho, že jsou v parsovaným stringu číslice a mezi nima čárka? To jako podle toho, že je před tím "price="? A každej typ se přitom chová jinak...
Zkrátka, volnost typu = volnost kompilátoru = volnost chování výsledné aplikace. Typ je totiž nedílná součást popisu dat. Když kompilátor neví, co použít a jenom tak tam něco práskne, tak je něco blbě v principu.
Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.
jednotky má moc hezky udělaný F# https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/units-of-measureDale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.
Tohle je docela důležitá poznámka. Pokud typy umožní zadat -100 kg, -200 cm nebo -300 °C, tak je takový typ zcela k ničemu. To už je lepší takové hodnoty (neotypované) předat do objektu, který s nimi pracuje a který zajistí nejen otypování, ale i validaci hodnot. Objekt může být za taková data zcela odpovědný a vadným vstupům se ubrání výjimkami. Je zcela v jeho kompetenci, zda nevalidní vstupy odmítne nebo sanuje. Běžný parser tohle nezvládne.
Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
jednotky má moc hezky udělaný F# https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/units-of-measure
a parsování jednotek problém není
Context-sensitive grammar? To asi dost těžko, v čem by se takový parser psal?Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
Context-sensitive grammar? To asi dost těžko, v čem by se takový parser psal?Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
Taková gramatika je ale formálně bezkontextová.Context-sensitive grammar? To asi dost těžko, v čem by se takový parser psal?Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
To je prosté. Podle prvního slova vybereš konstruktor a druhé slovo použiješ jako parametr. Vytvořená instance si ho už zpracuje podle svých potřeb. Pokud vyžaduje text, ale dostane číslo, zpracuje ho jako text. Pokud vyžaduje int, ale dostane text, vyhodí výjimku. Například REST funguje na tomto principu, ale variant je spousta.
Taková gramatika je ale formálně bezkontextová.To je prosté. Podle prvního slova vybereš konstruktor a druhé slovo použiješ jako parametr. Vytvořená instance si ho už zpracuje podle svých potřeb. Pokud vyžaduje text, ale dostane číslo, zpracuje ho jako text. Pokud vyžaduje int, ale dostane text, vyhodí výjimku. Například REST funguje na tomto principu, ale variant je spousta.Context-sensitive grammar? To asi dost těžko, v čem by se takový parser psal?Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
Ten “konstruktor” a parametr jsou součástí jednoho pravidla.Taková gramatika je ale formálně bezkontextová.To je prosté. Podle prvního slova vybereš konstruktor a druhé slovo použiješ jako parametr. Vytvořená instance si ho už zpracuje podle svých potřeb. Pokud vyžaduje text, ale dostane číslo, zpracuje ho jako text. Pokud vyžaduje int, ale dostane text, vyhodí výjimku. Například REST funguje na tomto principu, ale variant je spousta.Context-sensitive grammar? To asi dost těžko, v čem by se takový parser psal?Dale, Typ v beznych prog. jazycich je dost omezena pomucka. Pomuze ti oddelit string od cisla, ale nepomuze ti oddelit zaporny cislo od kladnyho cisla. Taky se ti jednoho krasnyho dne muze stat ze ti nekdo zacne posilat negativni hmotnosti tvych zakazniku a typovej system bude drzet hubu.Datové vstupy se běžně zpracovávají kontextovou gramatikou, kterou obecné parsery nezvládají.
Jak tedy pozná, že třeba 138 není číslo, ale tříznakový string?
To je sice hezké, ale nijak mi to nezabrání uživatelsky zadat záporné kilogramy nebo teplotu roztaveného železa 5000 °C. Pokud by objekt nedělal následnou validaci, zpracoval by i nesmysly. V tomhle mi bezkontextový parser skutečně nepomůže.Jedna šťouravá :) - co je nesmyslného na teplotě roztaveného železa 5000°C?
Váha a hmotnost jsou dvě různé veličiny s různými jednotkami. Na Marsu se ti například změní váha, ale ne hmotnost. Za nás se tohle bralo na ZŠ, ale svět se asi změnil, dnes by si maturanti stěžovali na obtížnost, kdyby měli vysvětlit rozdíl ???To je sice hezké, ale nijak mi to nezabrání uživatelsky zadat záporné kilogramy nebo teplotu roztaveného železa 5000 °C. Pokud by objekt nedělal následnou validaci, zpracoval by i nesmysly. V tomhle mi bezkontextový parser skutečně nepomůže.I záporné kilogramy můžou mít v určitém kontextu smysl - např relativní váha člověka ve vodě
Jedna šťouravá :) - co je nesmyslného na teplotě roztaveného železa 5000°C?
Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.Jenže svět, který se snažíme v IT modelovat/automatizovat má spíše charakter statických typů....Nikdo se nejmenuje 123456 nebo 10.60 a na výplatu dostanu vždy nějakou částku a ne stokorunčeských...takže oprávněný požadavek dynamických typů zpravidla zaznívá jen tehdy, když někdo něco generalizoval-sloučil. Navíc zákazník zpravidla požaduje ukládat data to staticky typovaných databází...v tomto případě nedává moc smysl zavádět do systému nějakou dynamickou složku.
Zrovna částku 10.60 je nejlepší předat do databáze jako string. Jakákoli konverze na nějaký int či float mimo databázi je zcela zbytečná a ve svém důsledku může aplikaci dost ublížit. Není žádný důvod pro hlídání takových typů v aplikaci.
V životě se člověku přihodí ledacos. Kdysi v databázi jeden takový samouk zavedl IP adresu jako string. On byl opravdu trochu omezenější, protože pořád nedokázal pochopit, že to je ve skutečnosti jen jedno číslo, nedokázal pochopit, jak může číslo obsahovat tři tečky. Jenže pak přišlo IPv6 a díky jeho stringu databáze bez problémů nové adresy zchroustala. Nakonec udělat si konverzi string->číslo (nebo whatever...) jde vždycky, ale kdyby byl databázi udělal nad uint32, celá věc by se bývala dost zkomplikovala.Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.Jenže svět, který se snažíme v IT modelovat/automatizovat má spíše charakter statických typů....Nikdo se nejmenuje 123456 nebo 10.60 a na výplatu dostanu vždy nějakou částku a ne stokorunčeských...takže oprávněný požadavek dynamických typů zpravidla zaznívá jen tehdy, když někdo něco generalizoval-sloučil. Navíc zákazník zpravidla požaduje ukládat data to staticky typovaných databází...v tomto případě nedává moc smysl zavádět do systému nějakou dynamickou složku.
Zrovna částku 10.60 je nejlepší předat do databáze jako string. Jakákoli konverze na nějaký int či float mimo databázi je zcela zbytečná a ve svém důsledku může aplikaci dost ublížit. Není žádný důvod pro hlídání takových typů v aplikaci.
A já myslel, že Kit tu žraloka přeskočil už dávno. A on se to pořád snaží trumfnout...
ale určité ponaučení si z toho pro praxi odnést lze.Jaké?
V životě se člověku přihodí ledacos. Kdysi v databázi jeden takový samouk zavedl IP adresu jako string. On byl opravdu trochu omezenější, protože pořád nedokázal pochopit, že to je ve skutečnosti jen jedno číslo, nedokázal pochopit, jak může číslo obsahovat tři tečky. Jenže pak přišlo IPv6 a díky jeho stringu databáze bez problémů nové adresy zchroustala. Nakonec udělat si konverzi string->číslo (nebo whatever...) jde vždycky, ale kdyby byl databázi udělal nad uint32, celá věc by se bývala dost zkomplikovala.
Je to sice jako v těch pohádkách, kde hloupému Honzovi nakonec pomohlo štěstí, ale určité ponaučení si z toho pro praxi odnést lze.
V životě se člověku přihodí ledacos. Kdysi v databázi jeden takový samouk zavedl IP adresu jako string. On byl opravdu trochu omezenější, protože pořád nedokázal pochopit, že to je ve skutečnosti jen jedno číslo, nedokázal pochopit, jak může číslo obsahovat tři tečky. Jenže pak přišlo IPv6 a díky jeho stringu databáze bez problémů nové adresy zchroustala. Nakonec udělat si konverzi string->číslo (nebo whatever...) jde vždycky, ale kdyby byl databázi udělal nad uint32, celá věc by se bývala dost zkomplikovala.
Je to sice jako v těch pohádkách, kde hloupému Honzovi nakonec pomohlo štěstí, ale určité ponaučení si z toho pro praxi odnést lze.
Něco podobného se mi skutečně stalo, když mi někdo vnucoval, že telefonní číslo mám ukládat jako uint32, ale já ho přesto udělal jako string, protože telefonní číslo není číslo.
Ty jsi, Kite, predbehl dobu. Dnes je v mode genderova flexibilita a jak by se hodilo mit moznost volnou formou zadat v kolonce pohlavi "kyberpes" namisto trapneho vyberu mezi M a F.
Ty jsi, Kite, predbehl dobu. Dnes je v mode genderova flexibilita a jak by se hodilo mit moznost volnou formou zadat v kolonce pohlavi "kyberpes" namisto trapneho vyberu mezi M a F.
Zažil jsem i dobu, kdy se pohlaví zadávalo true/false.
V životě se člověku přihodí ledacos. Kdysi v databázi jeden takový samouk zavedl IP adresu jako string. On byl opravdu trochu omezenější, protože pořád nedokázal pochopit, že to je ve skutečnosti jen jedno číslo, nedokázal pochopit, jak může číslo obsahovat tři tečky. Jenže pak přišlo IPv6 a díky jeho stringu databáze bez problémů nové adresy zchroustala. Nakonec udělat si konverzi string->číslo (nebo whatever...) jde vždycky, ale kdyby byl databázi udělal nad uint32, celá věc by se bývala dost zkomplikovala.
Je to sice jako v těch pohádkách, kde hloupému Honzovi nakonec pomohlo štěstí, ale určité ponaučení si z toho pro praxi odnést lze.
Něco podobného se mi skutečně stalo, když mi někdo vnucoval, že telefonní číslo mám ukládat jako uint32, ale já ho přesto udělal jako string, protože telefonní číslo není číslo.
Ty jsi, Kite, predbehl dobu. Dnes je v mode genderova flexibilita a jak by se hodilo mit moznost volnou formou zadat v kolonce pohlavi "kyberpes" namisto trapneho vyberu mezi M a F.
Akorát pohlaví (u lidí) jsou dvě. Tzv. "gender" je něco jiného. To jen taková technická :)Ještě přesněji, pojem "pohlaví" postupně ztrácí svůj někdejší čistě vnějškový biologický význam (má pindíka/nemá pindíka).
Akorát pohlaví (u lidí) jsou dvě. Tzv. "gender" je něco jiného. To jen taková technická :)Ještě přesněji, pojem "pohlaví" postupně ztrácí svůj někdejší čistě vnějškový biologický význam (má pindíka/nemá pindíka).
Ne, ideologicky není přesněji.O žádnou ideologii nejde. Jde o to, jak je to slovo reálně používáno reálnými lidmi. To moje tvrzení je deskriptivní, ne preskriptivní.
O žádnou ideologii nejde. Jde o to, jak je to slovo reálně používáno reálnými lidmi. To moje tvrzení je deskriptivní, ne preskriptivní.
Teprve v poslední době se prostě ve veřejném prostoru běžně objevují otevřené informace o tom, že existují lidi, kteří mají pindíka a přesto mají potřebu se označovat za ženy (a naopak). To způsobilo zvýšené povědomí o tom, že ten pojem není tak bezproblémový, za jaký byl dříve pokládán.
Žádná ideologie v tom nehraje žádnou roli, to je typický red herring, hodný Václava Klause ml.
Vy chcete překonat stávající rekord počtu příspěvků?Akorát pohlaví (u lidí) jsou dvě. Tzv. "gender" je něco jiného. To jen taková technická :)Ještě přesněji, pojem "pohlaví" postupně ztrácí svůj někdejší čistě vnějškový biologický význam (má pindíka/nemá pindíka).
...
Nebo možná to poučení z té anekdoty s IP ve stringu je v tom, že bysme do labelu takové položky neměli psát "pohlaví", ale "co máte v občance v položce >pohlaví<?", nevím.
Vy chcete překonat stávající rekord počtu příspěvků?
Nicméně k tématu: "gender" se lépe než "pohlaví" přeloží jako "rod". I když ani to není úplně ono... ale už to naznačuje na co se zaměřit u datového modelování.
K čemu vlastně potřebuji "pohlaví" nebo "rod" ve formuláři? Opravdu danou aplikaci zajímá jaký má dotyčný primární pohlavní orgán? Nebo jaké má chromozómy? Někdy ano. Ale troufám si říci že ve většině případů je zajímavý mluvnický rod pro skloňování (zvlášť v češtině, kde existuje vokativ). V takovém případě je lepší místo "pohlaví" mít kolonku "oslovení" s výběrem (pan, paní, slečna, doktor, etc) který mluvnický rod i správně implikuje. Dokážu si ale představit i aplikaci kde se používají "přezdívky" a pak je zcela na místě mít všechny tři rody které v českém jazyce existují.
Ještě bych se ale vrátil k tomu telefonu, který zde byl zmíněn. Doufám že nikoho snad opravdu nenapadne telefon ukládat jako integer nebo float!! A i když je k dispozici datový typ s neomezenou přesností (v dekadické soustavě), tak typicky nepodporuje významné nuly na začátku! A počet číslic také není úplně jasný, u mezinárodních čísel... A to všechno má stejně smysl zase podle aplikace: někdy je telefon použitý pro vytáčení, pak se samozřejmě číslo musí validovat. Ale pokud jsou to jenom kontaktní údaje někde zobrazené pro lidi, pak je lepší nechat telefon jako volný řetězec. Umožní to lidem zapsat speciality jako "klapka", rozsah čísel, nebo třeba "jen 9-12h". Samozřejmě, je to kompromis hodně směrem k uživatelům a nevhodný pro stroje :-)
1) Ne, pohlaví je terminus technicus.Dobře. Takže mám před sebou nějakého člověka. Jakým testem s naprostou jistotou zjistím jeho pohlaví?
1) Ne, pohlaví je terminus technicus.Dobře. Takže mám před sebou nějakého člověka. Jakým testem s naprostou jistotou zjistím jeho pohlaví?
Moje připomínka ke genderu byla zamýšlena jako popíchnutí Kita. Co tam má smysl nebo nemá, je závislé opět na kontextu. Bývaly doby, kdy pohlaví mělo jasnou souvislost s rozmnožováním a "rod" to respektoval (kupodivu slovo opět ukazuje k rození, což je jasně biologická, v našem druhu binární záležitost). V současném západním kontextu, kde jsou lidé věčnými dětmi a celý svět se točí kolem jejich ega, samozřejmě návrh software toto musí rovněž respektovat-
V drtivé většině pouhým zrakem, jinak podle chromozomů. Každopádně to lze určit.To je velice vágní, je to potřeba upřesnit:
V drtivé většině pouhým zrakem, jinak podle chromozomů. Každopádně to lze určit.To je velice vágní, je to potřeba upřesnit:
1. "pouhým zrakem" znamená co? Podívám se, jestli má pindíka?
2. "podle chromozomů" znamená co?
3. co když metody 1 a 2 dávají odlišné výsledky?
Ne, není to vágní a asi jsi nedával ve škole pozor.No nebudu ti oplácet stejnou mincí (tj. nebudu se uchylovat k ad hominem) a omezím se na konstatování, že:
mi třeba ve škole na otázku kde se bere to 3.14.. odpověděli, že to 22/7 :) a s chromozomama je to podobněV drtivé většině pouhým zrakem, jinak podle chromozomů. Každopádně to lze určit.To je velice vágní, je to potřeba upřesnit:
1. "pouhým zrakem" znamená co? Podívám se, jestli má pindíka?
2. "podle chromozomů" znamená co?
3. co když metody 1 a 2 dávají odlišné výsledky?
Ne, není to vágní a asi jsi nedával ve škole pozor.
Všechno ostatní jsou genetické mutace.Ano, jsou to genetické mutace, které způsobují, že u daného jedince nelze bezproblémově říct, jestli se jedná o samce nebo samici. Nic jiného tu nikdo netvrdí. Žádného "demagogického vytváření alternativních pohlaví" jsem si tady nevšiml, ty jo?
Ne, není to vágní a asi jsi nedával ve škole pozor.No nebudu ti oplácet stejnou mincí (tj. nebudu se uchylovat k ad hominem) a omezím se na konstatování, že:
1. existují všelijaké varianty stavby těla, včetně "zmixovaných", kde např. člověk má obojí pohlavní orgány
2. existují všelijaké genetické poruchy, kde platí totéž
Čili tvůj dojem, že "pohlaví" je neproblematický pojem, je mylné. U drtivé většiny lidí je možné říct, že se jedná o muže nebo ženu, ale existují lidé, u kterých to jasné není, jsou prostě biologicky "někde mezi".
Ne, není mylné. Jistě, existují lidé, co se narodí s jednou ledvinou, ale člověk má dvě. Člověk má nos, jistě jsou lidé, kteří se narodí bez něj.U některých jedinců prostě je problém určit pohlaví. Proto není pojem "pohlaví" bezproblémový (tím ti odpovídám na položenou otázku).
Ne, není mylné. Jistě, existují lidé, co se narodí s jednou ledvinou, ale člověk má dvě. Člověk má nos, jistě jsou lidé, kteří se narodí bez něj.U některých jedinců prostě je problém určit pohlaví. Proto není pojem "pohlaví" bezproblémový (tím ti odpovídám na položenou otázku).
Ne, není mylné. Jistě, existují lidé, co se narodí s jednou ledvinou, ale člověk má dvě. Člověk má nos, jistě jsou lidé, kteří se narodí bez něj.U některých jedinců prostě je problém určit pohlaví. Proto není pojem "pohlaví" bezproblémový (tím ti odpovídám na položenou otázku).
Termín pohlaví je jasný.Pokud bude v modelu položka "pohlaví" s enumem "muž" a "žena", tak u některých jedinců nebude problém, co by tam mělo být.
Termín pohlaví je jasný.Pokud bude v modelu položka "pohlaví" s enumem "muž" a "žena", tak u některých jedinců nebude problém, co by tam mělo být.
Jestli ti to přijde jako že "Termín pohlaví je jasný.", tak přijde no. Mně ne.
Mimochodem, celosvětově se intersexuálové pohybují kolem setin procent přinejlepším (mluvíme-li o případech, které nelze rozhodnout). Chápu, že to zkoušíš, ale už to fakt zavání nihilismem.
Doporučím vám některou přednášku u nás na přírodovědě.Kterou a proč?
Pohlavní dimorfismus vám něco říká?Něco jo.
A s OOP ty vaše komentáře souvisí jak?Souvisí to s modelováním. Dobrý příklad má o příspěvek výš Kit.
Mimochodem, celosvětově se intersexuálové pohybují kolem setin procent přinejlepším (mluvíme-li o případech, které nelze rozhodnout). Chápu, že to zkoušíš, ale už to fakt zavání nihilismem.
I při tak nízkém zastoupení je docela pravděpodobné, že v databázi s několika tisíci lidmi na někoho takového narazíme a musíme se s tím vypořádat. Dokonce mohou být rozdílné vstupy pro registraci v obchodě s oblečením a pro registraci ke sportovnímu utkání.
Doporučím vám některou přednášku u nás na přírodovědě.Kterou a proč?Pohlavní dimorfismus vám něco říká?Něco jo.A s OOP ty vaše komentáře souvisí jak?Souvisí to s modelováním. Dobrý příklad má o příspěvek výš Kit.
Který dobrý příklad měl Kit?Příklad na to, že pokud máme v modelu položku "pohlaví", může dávat smysl mít pro jednoho člověka v různých kontextech v téhle položce různé hodnoty.
Přednáška: https://www.youtube.com/watch?v=mDl2Xrdpeow&t=5035sA co bych tam měl hledat?
Ano, ale pohlaví != určení pohlaví.Mimochodem, celosvětově se intersexuálové pohybují kolem setin procent přinejlepším (mluvíme-li o případech, které nelze rozhodnout). Chápu, že to zkoušíš, ale už to fakt zavání nihilismem.I při tak nízkém zastoupení je docela pravděpodobné, že v databázi s několika tisíci lidmi na někoho takového narazíme a musíme se s tím vypořádat. Dokonce mohou být rozdílné vstupy pro registraci v obchodě s oblečením a pro registraci ke sportovnímu utkání.
Ano, ale pohlaví != určení pohlaví.Mimochodem, celosvětově se intersexuálové pohybují kolem setin procent přinejlepším (mluvíme-li o případech, které nelze rozhodnout). Chápu, že to zkoušíš, ale už to fakt zavání nihilismem.I při tak nízkém zastoupení je docela pravděpodobné, že v databázi s několika tisíci lidmi na někoho takového narazíme a musíme se s tím vypořádat. Dokonce mohou být rozdílné vstupy pro registraci v obchodě s oblečením a pro registraci ke sportovnímu utkání.
Jistě, ve sportu se určuje geneticky, tam je to jasné. Při nákupu oblečení nejen podle morfologie postavy, ale hlavně podle toho, co zákazník chce koupit. Například transvestita může být v civilu zcela jasným mužem, ale v daném obchodě chce vybírat dámské oblečení pro svá vystoupení. Co má zadat do formuláře?
Jistě, ve sportu se určuje geneticky, tam je to jasné.
pohlaví je vědecký termínPokud máš ve webovém formuláři položku "pohlaví", tak tě typicky nezajímá "vědecký" význam, ale jiné významy: právní, administrativní, sebeidentifikační apod.
Jistě, ve sportu se určuje geneticky, tam je to jasné. Při nákupu oblečení nejen podle morfologie postavy, ale hlavně podle toho, co zákazník chce koupit. Například transvestita může být v civilu zcela jasným mužem, ale v daném obchodě chce vybírat dámské oblečení pro svá vystoupení. Co má zadat do formuláře?V databázi jako zákazník je muž (pokud to tak zadal), ale preference na doporučení oblečení chce mít ženské. Ten systém bych namodeloval s touto možností. Dře to protože se to snažíž ohnout na jiný scénář než to je namodelované.
Ano, jak to namodeluji tak to mám. Ale spíš se mi zdá že jste to pomotal s pojmem gender a teď se z toho snažíte nějak vymotat a to způsoběm, že to celé označíte za jakýsi "problém". Cikáda to píše dobře. Jinak ta přednáška by vám kromě jiného mohla ukázat že zjistit pohledem pohlaví je naprosto normální metoda. U lidí dost spolehlivá narozdíl třeba od papoušků.pohlaví je vědecký termínPokud máš ve webovém formuláři položku "pohlaví", tak tě typicky nezajímá "vědecký" význam, ale jiné významy: právní, administrativní, sebeidentifikační apod.
Slovo "pohlaví" prostě není jednoznačné a jeho vědecký význam je jenom jeden z mnoha.
tak jaký je teda typ kolonky "biologické pohlaví"? mi vyšlo tohle:Ano, jak to namodeluji tak to mám. Ale spíš se mi zdá že jste to pomotal s pojmem gender a teď se z toho snažíte nějak vymotat a to způsoběm, že to celé označíte za jakýsi "problém". Cikáda to píše dobře. Jinak ta přednáška by vám kromě jiného mohla ukázat že zjistit pohledem pohlaví je naprosto normální metoda. U lidí dost spolehlivá narozdíl třeba od papoušků.pohlaví je vědecký termínPokud máš ve webovém formuláři položku "pohlaví", tak tě typicky nezajímá "vědecký" význam, ale jiné významy: právní, administrativní, sebeidentifikační apod.
Slovo "pohlaví" prostě není jednoznačné a jeho vědecký význam je jenom jeden z mnoha.
data Sex = Male | Female | Intersex
asi v informačním systému pro doktory, ve filtru eshopudata Sex = Male | Female | Unisex
pohlaví je vědecký termínPokud máš ve webovém formuláři položku "pohlaví", tak tě typicky nezajímá "vědecký" význam, ale jiné významy: právní, administrativní, sebeidentifikační apod.
Slovo "pohlaví" prostě není jednoznačné a jeho vědecký význam je jenom jeden z mnoha.
tak jaký je teda typ kolonky "biologické pohlaví"? mi vyšlo tohle:Ano, jak to namodeluji tak to mám. Ale spíš se mi zdá že jste to pomotal s pojmem gender a teď se z toho snažíte nějak vymotat a to způsoběm, že to celé označíte za jakýsi "problém". Cikáda to píše dobře. Jinak ta přednáška by vám kromě jiného mohla ukázat že zjistit pohledem pohlaví je naprosto normální metoda. U lidí dost spolehlivá narozdíl třeba od papoušků.pohlaví je vědecký termínPokud máš ve webovém formuláři položku "pohlaví", tak tě typicky nezajímá "vědecký" význam, ale jiné významy: právní, administrativní, sebeidentifikační apod.
Slovo "pohlaví" prostě není jednoznačné a jeho vědecký význam je jenom jeden z mnoha.Kód: [Vybrat]data Sex = Male | Female | Intersex
asi v informačním systému pro doktory, ve filtru eshopuKód: [Vybrat]data Sex = Male | Female | Unisex
Citace: KitJistě, ve sportu se určuje geneticky, tam je to jasné. Při nákupu oblečení nejen podle morfologie postavy, ale hlavně podle toho, co zákazník chce koupit. Například transvestita může být v civilu zcela jasným mužem, ale v daném obchodě chce vybírat dámské oblečení pro svá vystoupení. Co má zadat do formuláře?V databázi jako zákazník je muž (pokud to tak zadal), ale preference na doporučení oblečení chce mít ženské. Ten systém bych namodeloval s touto možností. Dře to protože se to snažíž ohnout na jiný scénář než to je namodelované.
Jinak ta přednáška by vám kromě jiného mohla ukázat že zjistit pohledem pohlaví je naprosto normální metoda. U lidí dost spolehlivá narozdíl třeba od papoušků.
tak řekněme, že typ Sex je výsledek funkce stanovující pohlaví, argumentem můžou být všelijaké biologické ukazatele respektive tvar osoby pro kterou nakupujeme :)tak jaký je teda typ kolonky "biologické pohlaví"? mi vyšlo tohle:Ano, jak to namodeluji tak to mám. Ale spíš se mi zdá že jste to pomotal s pojmem gender a teď se z toho snažíte nějak vymotat a to způsoběm, že to celé označíte za jakýsi "problém". Cikáda to píše dobře. Jinak ta přednáška by vám kromě jiného mohla ukázat že zjistit pohledem pohlaví je naprosto normální metoda. U lidí dost spolehlivá narozdíl třeba od papoušků.pohlaví je vědecký termínPokud máš ve webovém formuláři položku "pohlaví", tak tě typicky nezajímá "vědecký" význam, ale jiné významy: právní, administrativní, sebeidentifikační apod.
Slovo "pohlaví" prostě není jednoznačné a jeho vědecký význam je jenom jeden z mnoha.Kód: [Vybrat]data Sex = Male | Female | Intersex
asi v informačním systému pro doktory, ve filtru eshopuKód: [Vybrat]data Sex = Male | Female | Unisex
Není "biologické pohlaví", je pohlaví. Intersexuálové netvoří další pohlaví.
Ale spíš se mi zdá že jste to pomotal s pojmem gender a teď se z toho snažíte nějak vymotat a to způsoběm, že to celé označíte za jakýsi "problém".Vy jste si vybrali jednu definici, tu považujete za "správnou" a neberete v úvahu, že to slovo se může používat i v jiných významech, které třeba tak jednoznačné nejsou. To je samozřejmě v jistém smyslu řešení některých problémů, které nejednoznačnost toho slova přináší. Každý ale s vámi nemusí sdílet názor, že je to řešení nejlepší. A už vůbec s vámi nemusí souhlasit, že jenom toto a nic jiného je přesně význam toho slova.
Jinak ta přednáška by vám kromě jiného mohla ukázat že zjistit pohledem pohlaví je naprosto normální metoda.Tak to se na ni asi dívat nemusím, protože to je samozřejmé. Obzvlášť pokud člověk mluví česky a nutně musí použít nějaký rod při komunikaci s lidma, jimž nemá možnost udělat genetický test.
Citace: KitJistě, ve sportu se určuje geneticky, tam je to jasné. Při nákupu oblečení nejen podle morfologie postavy, ale hlavně podle toho, co zákazník chce koupit. Například transvestita může být v civilu zcela jasným mužem, ale v daném obchodě chce vybírat dámské oblečení pro svá vystoupení. Co má zadat do formuláře?V databázi jako zákazník je muž (pokud to tak zadal), ale preference na doporučení oblečení chce mít ženské. Ten systém bych namodeloval s touto možností. Dře to protože se to snažíž ohnout na jiný scénář než to je namodelované.
Co na tomhle chcete modelovat? V obchodu s oblečením jsou běžně různá oddělení a když půjdu koupit podprsenku, nikoho nezajímá, jestli to je pro manželku nebo pro matku nebo pro ujetého souseda Pepu, zrovna tak v dětském oddělení Vás nechají koupit bryndák bez ohledu na to, jestli máte potvrzení o tom, že máte děti.
Proto se to musí nějak odlišit, ale to neznamená že problém je v pohlaví, ale v tom, že ten systém musím modelovat jiným způsobem a dodat kontext "zajímám se především o...".Problém je ve slovu "pohlaví", protože ne vždy a ne každý ho musí chápat úzce biologicky a to ještě v nějakém konkrétním technickém významu ("gen X na místě Y", "chromozomy XY", atd).
Vy jste si vybrali jednu definici, tu považujete za "správnou" a neberete v úvahu, že to slovo se může používat i v jiných významech, které třeba tak jednoznačné nejsou. To je samozřejmě v jistém smyslu řešení některých problémů, které nejednoznačnost toho slova přináší. Každý ale s vámi nemusí sdílet názor, že je to řešení nejlepší. A už vůbec s vámi nemusí souhlasit, že jenom toto a nic jiného je přesně význam toho slova.Ano, vybral jsem definic (vlastně jste ji vybral vy)i, která zapadá do kontextu o které tady mluvíte a tu jste vysvětloval zcestně.
Tak to se na ni asi dívat nemusím, protože to je samozřejmé. Obzvlášť pokud člověk mluví česky a nutně musí použít nějaký rod při komunikaci s lidma, jimž nemá možnost udělat genetický test.
Když je to tak samozřejmé, proč jste to popíral?Můžete ocitovat příspěvek, ve kterém jsem to udělal?
Jasně! `Moje filozofie je vymyslet novou filozofii, když jí potřebuju.`Proto se to musí nějak odlišit, ale to neznamená že problém je v pohlaví, ale v tom, že ten systém musím modelovat jiným způsobem a dodat kontext "zajímám se především o...".Problém je ve slovu "pohlaví", protože ne vždy a ne každý ho musí chápat úzce biologicky a to ještě v nějakém konkrétním technickém významu ("gen X na místě Y", "chromozomy XY", atd).
Jasně! `Moje filozofie je vymyslet novou filozofii, když jí potřebuju.`Ne.
str. 61Když je to tak samozřejmé, proč jste to popíral?Můžete ocitovat příspěvek, ve kterém jsem to udělal?
Aha, takže jsem to nepopíral.str. 61Když je to tak samozřejmé, proč jste to popíral?Můžete ocitovat příspěvek, ve kterém jsem to udělal?
A: Dobře. Takže mám před sebou nějakého člověka. Jakým testem s naprostou jistotou zjistím jeho pohlaví?
B: V drtivé většině pouhým zrakem, jinak podle chromozomů. Každopádně to lze určit.
A: To je velice vágní, je to potřeba upřesnit:
1. "pouhým zrakem" znamená co? Podívám se, jestli má pindíka?
...
Snažit se někoho přesvědčit, že tahle metoda není 100% je na hranici paranoi -- pokud nejsi papoušek.nebo transgendered
Ne, Python opravdu není "multiparadigmatický", to je marketingový blábol. Ono v principu vůbec nic takového jako "multiparadigmatický" neexistuje, protože ta paradigmata jsou právě o tom, co ti jazyk nedovolí udělat, ne o tom, co ti dovolí. Když něco z principu nejde -> máš jistotu, že k tomu nedošlo -> máš zaručenou informaci.
Z tohoto pohledu Python není OOP, protože u něj neplatí, že "z principu nejde" měnit vnitřní stav objektu zvenku. Troufnete si to vysvětlovat místním mistrům?Určitě nemá "ukázkové", "vzorové", "čisté" OOP. Má OOP (a všechno ostatní) "pragmatické" nebo "good enough". Což je v praxi často přesně to, co lidi chtějí (viz https://en.wikipedia.org/wiki/Worse_is_better)
Ne, Python opravdu není "multiparadigmatický", to je marketingový blábol. Ono v principu vůbec nic takového jako "multiparadigmatický" neexistuje, protože ta paradigmata jsou právě o tom, co ti jazyk nedovolí udělat, ne o tom, co ti dovolí. Když něco z principu nejde -> máš jistotu, že k tomu nedošlo -> máš zaručenou informaci.
Z tohoto pohledu Python není OOP, protože u něj neplatí, že "z principu nejde" měnit vnitřní stav objektu zvenku. Troufnete si to vysvětlovat místním mistrům?
Ne, Python opravdu není "multiparadigmatický", to je marketingový blábol. Ono v principu vůbec nic takového jako "multiparadigmatický" neexistuje, protože ta paradigmata jsou právě o tom, co ti jazyk nedovolí udělat, ne o tom, co ti dovolí. Když něco z principu nejde -> máš jistotu, že k tomu nedošlo -> máš zaručenou informaci.Z tohoto pohledu Python není OOP, protože u něj neplatí, že "z principu nejde" měnit vnitřní stav objektu zvenku. Troufnete si to vysvětlovat místním mistrům?
Když někdo zvenku zavolá setter, tak také mění stav objektu zvenku. Používání setterů je tedy v rozporu s principy OOP.
co znamená měnit stav z venku? Přiřazení v Pythonu zavolá metodu __setattr__. Tyhle diskuze vždy skončí dohadováním o slovíčkách.
Setter je jako každá metoda uvnitř objektu, takže se nejedná o změnu zvenku. Stav je bez existujícího prostředníka zvenku nedostupný.Mně teda přijde, že to je spíš otázka designová/koncepční. Buď k objektu přistupuju jako ke structu/dementovi, kterého polopaticky řídím, nebo k němu přistupuju jako k dospělému, kterého o něco žádám a sděluju mu, jaké parametry odpovědi by se mi líbily. Nepřijde mi, že by tam byla ostrá hranice.
Používání setterů je tedy v rozporu s principy OOP.https://en.wikipedia.org/wiki/Setter ?
Ve statickem jazyku jsi nucen svet modelovat staticky, ale on ve skutecnosti staticky neni, kdyz nic jineho, vyviji se v case a je to prave zakaznik, kdo potrebuje aplikaci prizpusobovat.Odpor vuci dynamickym jazykum zazniva od tech, kteri se v nich pokousi programovat staticky, protoze to jinak neumi.Jenže svět, který se snažíme v IT modelovat/automatizovat má spíše charakter statických typů....Nikdo se nejmenuje 123456 nebo 10.60 a na výplatu dostanu vždy nějakou částku a ne stokorunčeských...takže oprávněný požadavek dynamických typů zpravidla zaznívá jen tehdy, když někdo něco generalizoval-sloučil. Navíc zákazník zpravidla požaduje ukládat data to staticky typovaných databází...v tomto případě nedává moc smysl zavádět do systému nějakou dynamickou složku.
P.S. Kadete, k těm typům. Je lepší hodinu bojovat se statickými typy, než týden hledat, proč se to číslo chová divně. Schválně, mám SessionID 231479973001 a používám to jako číslo ve formátu UINT64. Co dostanu, pokud ho první knihovna interně konvertuje do UINT32 (protože na ni od dob 32b nikdo nesáhl), druhá do INT64 (protože signed považuje za nativní formát) a pak zpátky do UINT64? Jaký budeš mít SessionID na konci toho procesu? A uspokojí tě to? Ale co, hlavní je, že ani ty tři warningy při buildu nedostaneš... A to se počítá.
Takže na začátku parsování/verifikace dat na jednom místě, následná logika pak ví, že data jsou validní a jak jsou zabalený. A pokud jsou zabalený jinak, kompilátor to zatepla nabonzuje...
Bez urazky, ale kdyz jsi prase a pouzivas praseci knihovny ktery ti hloupy session id prezvejka do tolika formatu, tak se nedivim, ze potrebujes statickou kontrolu. Ja bych taky odmitnul pracovat na prasecim Python projektu, kdybych tam videl praseciny podobnyho typu. Taky bych byl radsi kdyby to bylo staticky otypovany.
Jenze ja bych vzal ten prasecak, pokusil se najit co se to snazi delat, tj. najit vstupy a vystupy a jak to komunikuje s okolnim svetem, a vyhazet 90% toho chliva ven.
Presne to taky delam ve svy praxi. V tvym pripade bych vyhazel vsechny th black box knihovnh co mi znasilnujou session id, session id bych nahradil pouhym stringem, protoze nepotrebuju delat aritmetiku ani pocitatncialni rovnice se session id.
Kod bych zredukoval na desetinu mozna min ve zlomku casu. To co ostatnim trva mesice, ja dodavam do tydne. Protoze dokazu rychle najit co je v programu potreba a co je balast.
Kdyz to dotahnu do konce a klient je spokojenej muzu zacit konecne optimalizovat. Takze vezmu kritickou sekci a prepisu ji v Cythonu, v C nebo necim podobnym. Nebo napisu kritickou sekci jako cistej C, java program a pospojuju to unix pipelinou. Je mi to prakticky jedno. A vis co. Dneska jsou komoy tak rychly, ze klient radsi zaplati za dve dalsi masiny misto prepisu do rychlejsiho jazyka.
Svet musis digitalizovat, ale nemusis mit staticka data. V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji. Korunujes to v zaveru tvrzenim, ze typ je soucasti dat. Vitej ve svete dynamickych jazyku, tam to opravdu plati.Bez urazky, ale kdyz jsi prase a pouzivas praseci knihovny ktery ti hloupy session id prezvejka do tolika formatu, tak se nedivim, ze potrebujes statickou kontrolu...
Já preferuju vlastní kód, ale nikdo ti nezaplatí vývoj vlastních knihoven. Vždycky používáš kód třetí strany a inspekce od kompilátoru se vždycky hodí (resp. je zadarmo). "Model světa" totiž musíš přechrchlat na byty, aby jim stroj rozuměl a to jsou najednou chyby jak víno. Zaokrouhlování u floatů, přetečení nebo podtečení hodnot,... Prostě je fajn si říct, že to bude tak a ještě lepší si to restriktivně vynutit.
Btw, nemusí to být jenom staticky linkovaný knihovny, může to být kombinace několika jazyků, jedna z těch věcí může běžet na jiným fyzickým stroji,... A o to je to zákařnější - není nad to, když server má 64b hodnoty, klient 32b hodnoty a vývojář se diví. A pokud nezná typy (a s tím i tyhle pasti), tak si pěkně namlátí hubu.
Můj příklad je jenom malinká ukázka, jak to dopadá, když prasata ignorujou typy:
Krok | Typ | Dekadicky | Hexadecimálně | Podrobnosti 0 | uint64 | 231479973001 | 0x0000000035E5481489 | hodnota má 40b 1 | uint32 | 3846706313 | 0xE5481489 | přišli jsme o horních 8b hodnoty 2 | int64 | -448260983 | 0xFFFFFFFFE5481489 | bit 31 = 1 -> záporné číslo 3 | uint64 | 18446744072813029651 | 0xFFFFFFFFE5481489 | Interpretováno jako UINT64
Další past je třeba float - currency. Jak to má sakra kompilátor/interpreter poznat jenom podle toho, že jsou v parsovaným stringu číslice a mezi nima čárka? To jako podle toho, že je před tím "price="? A každej typ se přitom chová jinak...
Zkrátka, volnost typu = volnost kompilátoru = volnost chování výsledné aplikace. Typ je totiž nedílná součást popisu dat. Když kompilátor neví, co použít a jenom tak tam něco práskne, tak je něco blbě v principu.
Když někdo zvenku zavolá setter, tak také mění stav objektu zvenku. Používání setterů je tedy v rozporu s principy OOP.
Setter je jako každá metoda uvnitř objektu, takže se nejedná o změnu zvenku. Stav je bez existujícího prostředníka zvenku nedostupný.
Porozumění záleží na inteligenci. Kdyby si to každý musel zkoušet, nikdo to nevymyslí. Zrovna tak je to věc sebeovládání. Ovládat se můžeš sám a nebo potřebuješ, aby někdo ovlédal tebe, ať člověk nebo jazyk nebo statické typy. Někdo radši svobodu a zodpovědnost, někdo radši totalitu a přenesení zodpovědnosti na systém. Python je multiparadigmatický. Paradigma spočívá v přístupu k věci, ne v omezení. Python ti umožňuje různé přístupy. Čisté paradigma je extremismus. Ideální je možnost výběru a flexibilního přizpůsobení se aktuálním potřebám.Tak to se podle mě velice tragicky mýlíš. Pokud chceš nějakému paradigmatu porozumět, musíš si ho vyzkoušet pokud možno v čisté podobě. Protože jenom ta tě donutí opravdu použít daný přístup a neuhýbat jinam. Tj. pokud funkcionální, tak Haskell, ne Scalu. Na Haskellu pochopíš, o co jde, a pak v praxi už můžeš vzít tu Scalu, protože to může být ze spousty důvodů praktičtější.je dobré znát ne dva až tři jazyky, ale především dvě až tři paradigmataV tom je prave dobry python, protoze ti umoznuje jednotliva paradigmata podle potreby prirozene kombinovat.
Ne, Python opravdu není "multiparadigmatický", to je marketingový blábol. Ono v principu vůbec nic takového jako "multiparadigmatický" neexistuje, protože ta paradigmata jsou právě o tom, co ti jazyk nedovolí udělat, ne o tom, co ti dovolí. Když něco z principu nejde -> máš jistotu, že k tomu nedošlo -> máš zaručenou informaci.Za druhe ruzne paradigmata jsou uzitecna, ale nepotrebujes si kvuli tomu povrchne hrat s hromadou prakticky nevyuzitelnych jazyku.Potřebuješ, protože žádný jiný způsob, jak jim porozumět, neexistuje.
Python ti umožňuje různé přístupy. Čisté paradigma je extremismus. Ideální je možnost výběru a flexibilního přizpůsobení se aktuálním potřebám.Jasný. A i JavaScript je multiparadigmatický. A vlastně každý v současnosti existující jazyk. Protože tenhle blábol lidi naučil si myslet, že když má jazyk funkce jako first class citizens, tak je funkcionální. Až na to, že ono je to ve skutečnosti o dost zajímavější. Jenže to nezjistíš, protože sis "funkcionálně" zaprogramoval v pythonu a nic jinýho nikdy nezkusíš. (tím nemyslím tebe osobně, ale lidi, kteří na tenhle blábol naskočili)
Javascript mám docela rád, na menší věci, dobře se mi v něm píše. Také pragmatický jazyk, byť s pochybným původem. Co je to funkcionální si každý zkusil ve škole na lispu. Funkcionální programování není žádná novinka. A třeba C za multiparadigmatický jazyk nepovažuji, tomu objektové paradigma občas citelně chybí, nebo alespoň jmenné prostory. Viz třeba gtk napsané v C. V pythonu se s ním pracuje mnohem příjeměji a klidně tu může někdo operovat s myšlenkou, že python, kde je všechno objekt, včetně objektů frame a code, není objektový.Python ti umožňuje různé přístupy. Čisté paradigma je extremismus. Ideální je možnost výběru a flexibilního přizpůsobení se aktuálním potřebám.Jasný. A i JavaScript je multiparadigmatický. A vlastně každý v současnosti existující jazyk. Protože tenhle blábol lidi naučil si myslet, že když má jazyk funkce jako first class citizens, tak je funkcionální. Až na to, že ono je to ve skutečnosti o dost zajímavější. Jenže to nezjistíš, protože sis "funkcionálně" zaprogramoval v pythonu a nic jinýho nikdy nezkusíš. (tím nemyslím tebe osobně, ale lidi, kteří na tenhle blábol naskočili)
Co je to funkcionální si každý zkusil ve škole na lispu.Takže tě přece jenom někdo donutil si ty "nesmyslné" jazyky vyzkoušet. To je dobře :)
Netvrdil jsem, že jsou nesmyslné, ale v praxi nepraktické a že se pragmaticky radši zabývám věcmi praktickými.Co je to funkcionální si každý zkusil ve škole na lispu.Takže tě přece jenom někdo donutil si ty "nesmyslné" jazyky vyzkoušet. To je dobře :)
Netvrdil jsem, že jsou nesmyslné, ale v praxi nepraktické a že se pragmaticky radši zabývám věcmi praktickými.Co je to funkcionální si každý zkusil ve škole na lispu.Takže tě přece jenom někdo donutil si ty "nesmyslné" jazyky vyzkoušet. To je dobře :)
Proto davam prednost pythonu se silnymi typy, dnes i moznosti typehintingu.V praxi je nepraktická i přílišná volnost.Netvrdil jsem, že jsou nesmyslné, ale v praxi nepraktické a že se pragmaticky radši zabývám věcmi praktickými.Co je to funkcionální si každý zkusil ve škole na lispu.Takže tě přece jenom někdo donutil si ty "nesmyslné" jazyky vyzkoušet. To je dobře :)
V praxi je nepraktická i přílišná volnost.Mně vůbec celá praxe přijde taková nepraktická.
(https://cdn-images-1.medium.com/max/1600/0*ZglaEb3qQK6xCBC6.png)V praxi je nepraktická i přílišná volnost.Mně vůbec celá praxe přijde taková nepraktická.
Proto davam prednost pythonu se silnymi typy, dnes i moznosti typehintingu.
Setter je jako každá metoda uvnitř objektu, takže se nejedná o změnu zvenku. Stav je bez existujícího prostředníka zvenku nedostupný.Mně teda přijde, že to je spíš otázka designová/koncepční. Buď k objektu přistupuju jako ke structu/dementovi, kterého polopaticky řídím, nebo k němu přistupuju jako k dospělému, kterého o něco žádám a sděluju mu, jaké parametry odpovědi by se mi líbily. Nepřijde mi, že by tam byla ostrá hranice.
Setter je jako každá metoda uvnitř objektu, takže se nejedná o změnu zvenku. Stav je bez existujícího prostředníka zvenku nedostupný.
Proto by settery měly být privátní.
...A třeba C za multiparadigmatický jazyk nepovažuji, tomu objektové paradigma občas citelně chybí...
Sice nevím, co tím myslíte, ale existuje jednodušší řešení - zapomeňte na settery, je to nadbytečný "koncept".Setter je jako každá metoda uvnitř objektu, takže se nejedná o změnu zvenku. Stav je bez existujícího prostředníka zvenku nedostupný.Proto by settery měly být privátní.
Svet musis digitalizovat, ale nemusis mit staticka data.
V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji.
...A třeba C za multiparadigmatický jazyk nepovažuji, tomu objektové paradigma občas citelně chybí...
Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.Svet musis digitalizovat, ale nemusis mit staticka data.
Pokud svět musím digitalizovat, jsou tam dvě kvantizace - hodnota (např. ADC s rozlišením 12 bitů) a čas (vzorkování po např. 120ns). Příchod dalšího vzorku = změna stavu objektu.
V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji.
Kontrolní otázky:
- Jak Python interně ukládá ten INT?
- Pokud uložím INT do binárního souboru a načtu ho do programu v C++, budu kompatibilní?
- Budu kompatibilní, pokud ten Python spustím na 32-bit RPi a soubor otevřu v nativní aplikaci na AMD64 psané dejme tomu v C#?
- Jakou velikost bude mít ten soubor, když v něm bude pole 100 000 000 intů?
a) Nemohl, protoze ne vsem jazykum chybi....A třeba C za multiparadigmatický jazyk nepovažuji, tomu objektové paradigma občas citelně chybí...
Jak může C chybět OOP, když není konstruované pro daný typ úloh, pro danou úroveň abstrakce? To byste mohl pak říci o každém jazyku, že mu chybí OOP.
Ano, data musim zjednodusit, ale z toho nevyplyva, ze datovy model musi byt staticky a nemuze se prubezne menit.Svet musis digitalizovat, ale nemusis mit staticka data.
Pokud svět musím digitalizovat, jsou tam dvě kvantizace - hodnota (např. ADC s rozlišením 12 bitů) a čas (vzorkování po např. 120ns). Příchod dalšího vzorku = změna stavu objektu.V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji.
Kontrolní otázky:
- Jak Python interně ukládá ten INT?
- Pokud uložím INT do binárního souboru a načtu ho do programu v C++, budu kompatibilní?
- Budu kompatibilní, pokud ten Python spustím na 32-bit RPi a soubor otevřu v nativní aplikaci na AMD64 psané dejme tomu v C#?
- Jakou velikost bude mít ten soubor, když v něm bude pole 100 000 000 intů?
Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.
Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.
Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.
List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.
Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?
Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.
V tom případě je tam objekt "fronta dat", který změní svůj stav (už neí prázdný, přetekl, nebo došel do stavu, kdy vynutí zpracování s vyšší prioritou,...).
Pointa je taková, že hodnoty i čas jsou v digitálním modelu světa nespojitý. A je potřeba s tím počítat.Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.
Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.
List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.
Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?
Aha. Takže dynamický pole bytů, hmm. Tak to je super. Takže 100 se uloží do 1B, 200 do dvou (počítám signed) a když někde budu mít 100k, bude to ve třech... A k tomu ještě nějaký info, jak sou ty data velký. A rozbitej alignment... No jedno lepší jak druhý:
- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
- Pokud chceš I/O operaci, musíš to přechroustat na to tvoje pěkný bytový pole. zase pěkně v cyklu, místo jedné instrukce pro data šířky sběrnice. Ve finále stejně musíš deklarovat, jak to do toho bitovýho streamu budeš sypat. No není to super?
- A pokud to hážeš na interní stringy, tak máš navíc pro čtení INT64 z RAMky 18*(RD + MUL10 + ADD). Zapsat číslo je ještě o trochu horší, 18*(MOD10 + DIV10 + WR). MUL, MOD a DIV jsou nejdražší operace a bez násobičky, která současně vyplivne dělení i zbytek, jsi v pr...
Python znamená Krajta. Největší škrtiči na světě. Už mám jasno, proč zvolili tohle slovo - takovýho škrtiče výkonu aby člověk pohledal. Nedivím se, že je program v Pythonu obvykle pomalejší než Ťokovo budování dálnic... ;D
Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.
V tom případě je tam objekt "fronta dat", který změní svůj stav (už neí prázdný, přetekl, nebo došel do stavu, kdy vynutí zpracování s vyšší prioritou,...).
Pointa je taková, že hodnoty i čas jsou v digitálním modelu světa nespojitý. A je potřeba s tím počítat.Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.
Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.
List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.
Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?
Aha. Takže dynamický pole bytů, hmm. Tak to je super. Takže 100 se uloží do 1B, 200 do dvou (počítám signed) a když někde budu mít 100k, bude to ve třech... A k tomu ještě nějaký info, jak sou ty data velký. A rozbitej alignment... No jedno lepší jak druhý:
- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
- Pokud chceš I/O operaci, musíš to přechroustat na to tvoje pěkný bytový pole. zase pěkně v cyklu, místo jedné instrukce pro data šířky sběrnice. Ve finále stejně musíš deklarovat, jak to do toho bitovýho streamu budeš sypat. No není to super?
- A pokud to hážeš na interní stringy, tak máš navíc pro čtení INT64 z RAMky 18*(RD + MUL10 + ADD). Zapsat číslo je ještě o trochu horší, 18*(MOD10 + DIV10 + WR). MUL, MOD a DIV jsou nejdražší operace a bez násobičky, která současně vyplivne dělení i zbytek, jsi v pr...
Python znamená Krajta. Největší škrtiči na světě. Už mám jasno, proč zvolili tohle slovo - takovýho škrtiče výkonu aby člověk pohledal. Nedivím se, že je program v Pythonu obvykle pomalejší než Ťokovo budování dálnic... ;D
Koukam zes to odpovedel za me.Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.Svet musis digitalizovat, ale nemusis mit staticka data.
Pokud svět musím digitalizovat, jsou tam dvě kvantizace - hodnota (např. ADC s rozlišením 12 bitů) a čas (vzorkování po např. 120ns). Příchod dalšího vzorku = změna stavu objektu.V dalsi casti popiras sam sebe. V pythonu bys na to mel jeden univerzalni int a tvuj problem by vubec nenastal. Takze staticke typi te pred timto problemem nechřani,míny ho zpusobuji.
Kontrolní otázky:
- Jak Python interně ukládá ten INT?
- Pokud uložím INT do binárního souboru a načtu ho do programu v C++, budu kompatibilní?
- Budu kompatibilní, pokud ten Python spustím na 32-bit RPi a soubor otevřu v nativní aplikaci na AMD64 psané dejme tomu v C#?
- Jakou velikost bude mít ten soubor, když v něm bude pole 100 000 000 intů?
Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.
Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.
List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.
Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?
Ale to nikdo nerozporuje, jen jde o to, ze struktura ulozeni dat muze byt samopopisna a dynamicka, nemusi byt staticka a nemenna.Pokud '=' znamena ekvivalence, pak velky omyl. Prichod dalsiho vzorku muzu modelovat tak, ze ho prilepim na konec seznamu vsech vzorku a nic pri to menit nemusim.
V tom případě je tam objekt "fronta dat", který změní svůj stav (už neí prázdný, přetekl, nebo došel do stavu, kdy vynutí zpracování s vyšší prioritou,...).
Pointa je taková, že hodnoty i čas jsou v digitálním modelu světa nespojitý. A je potřeba s tím počítat.
Je jedno jak Python uklada inty. Treba je ma ulozeny v cloudu a taha je pres sit. Je to abstrakce za kterou muze byt cokoliv. Ale pravdepodobne to bude ulozeny jako bytearray s variabilni velikosti.
Do binarniho souboru budes ukladat serializovanou reprezentaci. Zadnej dump internich struktur a srani se s endianem jako to delaji prasata v c++.
List bude mit umernou hodnotu velikosti ulozenych dat. 100m intu, log n bitu na kazdy integer. Ty jsi ho asi chtel nachytat na tom, ze int je fixed size datatype.
Polozil bych tu otazku jinak. Jakou velikost bude mit soubor kdyz v nem bude pole 100 000 000 stringu?
Aha. Takže dynamický pole bytů, hmm. Tak to je super. Takže 100 se uloží do 1B, 200 do dvou (počítám signed) a když někde budu mít 100k, bude to ve třech... A k tomu ještě nějaký info, jak sou ty data velký. A rozbitej alignment... No jedno lepší jak druhý:
- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
- Pokud chceš I/O operaci, musíš to přechroustat na to tvoje pěkný bytový pole. zase pěkně v cyklu, místo jedné instrukce pro data šířky sběrnice. Ve finále stejně musíš deklarovat, jak to do toho bitovýho streamu budeš sypat. No není to super?
- A pokud to hážeš na interní stringy, tak máš navíc pro čtení INT64 z RAMky 18*(RD + MUL10 + ADD). Zapsat číslo je ještě o trochu horší, 18*(MOD10 + DIV10 + WR). MUL, MOD a DIV jsou nejdražší operace a bez násobičky, která současně vyplivne dělení i zbytek, jsi v pr...
Python znamená Krajta. Největší škrtiči na světě. Už mám jasno, proč zvolili tohle slovo - takovýho škrtiče výkonu aby člověk pohledal. Nedivím se, že je program v Pythonu obvykle pomalejší než Ťokovo budování dálnic... ;D
- pokud chce nějak ty čísla násobit/dělit, musíš to přechroupat do jinýho standardu. Takže za běhu vybrat, že INT16 * INT64 chce konverzi INT16 na INT64 s taháním po bytech (protože alignment), pak že požiješ INT64*INT64 a podle výsledku alokuješ pole (klidně 10B), do kterýho to nasypeš. Takže tam, kde by stačila jedna verze natvrdo, máš cyklus na čtení, rozhodování o operaci za běhu, několik aletrnativ matematické funkce, ukládání v cyklu.
Ono to krasne dokazuje omezenost mysleni 'statickych' programatoruMno... Zaznelo tady "muzes pouzit numpy.array". Neni to nahodou implementovano staticky v cythonu nebo rovnou v C? :)
Ono to krasne dokazuje omezenost mysleni 'statickych' programatoruMno... Zaznelo tady "muzes pouzit numpy.array". Neni to nahodou implementovano staticky v cythonu nebo rovnou v C? :)
Ani ne. Typová informace je součástí toho objektu. Typová kontrola probíhá za běhu.Nemluvil jsem o tom, kde je typová kontrola, ale o tom, v čem je to implementováno.
Ani ne. Typová informace je součástí toho objektu. Typová kontrola probíhá za běhu.Nemluvil jsem o tom, kde je typová kontrola, ale o tom, v čem je to implementováno.
je to implementováno stejně jako všechny vestavěné typy cpythonu.Ani mi to moc nepřijde: https://github.com/numpy/numpy/blob/master/numpy/core/src/common/array_assign.c
je to implementováno stejně jako všechny vestavěné typy cpythonu.Ani mi to moc nepřijde: https://github.com/numpy/numpy/blob/master/numpy/core/src/common/array_assign.c
Celý Python je implementován v C a ten zase generuje strojový kód. A co má být? Ze sportovních důvodů existuje C compiler implementovaný v Pythonu, viz https://github.com/ShivamSarodia/ShivyCOno to krasne dokazuje omezenost mysleni 'statickych' programatoruMno... Zaznelo tady "muzes pouzit numpy.array". Neni to nahodou implementovano staticky v cythonu nebo rovnou v C? :)
ndarray je implementováno tadyVůbec nerozumím, co se snažíš říct.
https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/arrayobject.c
všechny vestavěné typy jsou implementovány v C, není rozdíl mezi rozšiřujícím typem a vestavěným typem.
https://docs.python.org/3/extending/newtypes_tutorial.html
ndarray je implementováno tadyVůbec nerozumím, co se snažíš říct.
https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/arrayobject.c
všechny vestavěné typy jsou implementovány v C, není rozdíl mezi rozšiřujícím typem a vestavěným typem.
https://docs.python.org/3/extending/newtypes_tutorial.html
co jsi chtěl říct ty tím odkazem?No já jsem reagoval na to, na co jsem reagoval: https://forum.root.cz/index.php?topic=20380.msg304009#msg304009
Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.
Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.
Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.OOP je dobre treba na datove objekty, na vytvareni novych datovych typu. Zvlaste kdyz je jich hodne a maji hierarchickou strukturu. Typicky a vsude uvadeny pripad je GUI. A nebo ja jsem ted hodne ponoren do midi a midi eventů, u nich objektovy pristup take sedi jak zadek na hrnec. A s temito objekty pak muze byt dal klidne nakladano strukturovane nebo funkcionalne, jak je v dane situaci nejlepsi. Takze oop by mel byt dobry sluha aplikovany kam patri, ale ne spatny pan vnucovany nam z duvodu cistoty/uniformity jednoho paradigma i na miste, kde se nehodi.
Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.
Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.OOP je dobre treba na datove objekty, na vytvareni novych datovych typu. Zvlaste kdyz je jich hodne a maji hierarchickou strukturu. Typicky a vsude uvadeny pripad je GUI. A nebo ja jsem ted hodne ponoren do midi a midi eventů, u nich objektovy pristup take sedi jak zadek na hrnec. A s temito objekty pak muze byt dal klidne nakladano strukturovane nebo funkcionalne, jak je v dane situaci nejlepsi. Takze oop by mel byt dobry sluha aplikovany kam patri, ale ne spatny pan vnucovany nam z duvodu cistoty/uniformity jednoho paradigma i na miste, kde se nehodi.
Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.
Blahopřeju k (zatím) nejdebilnějšímu příspěvku tohoto vlákna.Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.OOP je dobre treba na datove objekty, na vytvareni novych datovych typu. Zvlaste kdyz je jich hodne a maji hierarchickou strukturu. Typicky a vsude uvadeny pripad je GUI. A nebo ja jsem ted hodne ponoren do midi a midi eventů, u nich objektovy pristup take sedi jak zadek na hrnec. A s temito objekty pak muze byt dal klidne nakladano strukturovane nebo funkcionalne, jak je v dane situaci nejlepsi. Takze oop by mel byt dobry sluha aplikovany kam patri, ale ne spatny pan vnucovany nam z duvodu cistoty/uniformity jednoho paradigma i na miste, kde se nehodi.
Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.
Presne GUI a implementace vnitrnosti programovaciho prostredi (hierarchie cisel), nektery datovy struktury, jsou presne pripady, kde je fajn mit nastroje, co dokazou dispatchovat funkci hierarchicky.
Nemyslim si ale ze je k tomu potreba OOP jazyk, mela by stacit featura, ktera mi diapatchne spravnou funkci.
Napr. u hierarchie cisel. Mam pripady kdy scitam int a float:
1 + 1 (int_int_plus)
1.0 + 1 (float_int_plus)
1 + 1.0 (int_float_plus, nebo flip + float_int_plus)
1.0 + 1.0 (float_float_plus)
na zaklade typu potrebuju dispatchnout spravnou funkci nebo instrukci.
OOP s posilanim zprav nebo volanim metod je na to kratky, protoze dispatchuju pres dva argumenty. Muzu to ohackovat pres double dispatch. Nejakej haskell fanda mi muze tvrdit, ze bez dispatche na zaklade statickych typu to nepujde, ale kazdy vidi, ze je v tomhle pripade jedno jestli dispatchuju pri prekladu nebo az tesne pred volanim funkce.
Kazdopadne jakmile mam spravnou funkci, tak nepotrebuju dalsi featury OOP jazyka. Staci mi skladat funkce jednu za druhou. Algebra funkci je jednodussi nez algebra objektu, pokud beru objekt pouze jako mnozinu 1+ funkci.
Blahopřeju k (zatím) nejdebilnějšímu příspěvku tohoto vlákna.Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.OOP je dobre treba na datove objekty, na vytvareni novych datovych typu. Zvlaste kdyz je jich hodne a maji hierarchickou strukturu. Typicky a vsude uvadeny pripad je GUI. A nebo ja jsem ted hodne ponoren do midi a midi eventů, u nich objektovy pristup take sedi jak zadek na hrnec. A s temito objekty pak muze byt dal klidne nakladano strukturovane nebo funkcionalne, jak je v dane situaci nejlepsi. Takze oop by mel byt dobry sluha aplikovany kam patri, ale ne spatny pan vnucovany nam z duvodu cistoty/uniformity jednoho paradigma i na miste, kde se nehodi.
Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.
Presne GUI a implementace vnitrnosti programovaciho prostredi (hierarchie cisel), nektery datovy struktury, jsou presne pripady, kde je fajn mit nastroje, co dokazou dispatchovat funkci hierarchicky.
Nemyslim si ale ze je k tomu potreba OOP jazyk, mela by stacit featura, ktera mi diapatchne spravnou funkci.
Napr. u hierarchie cisel. Mam pripady kdy scitam int a float:
1 + 1 (int_int_plus)
1.0 + 1 (float_int_plus)
1 + 1.0 (int_float_plus, nebo flip + float_int_plus)
1.0 + 1.0 (float_float_plus)
na zaklade typu potrebuju dispatchnout spravnou funkci nebo instrukci.
OOP s posilanim zprav nebo volanim metod je na to kratky, protoze dispatchuju pres dva argumenty. Muzu to ohackovat pres double dispatch. Nejakej haskell fanda mi muze tvrdit, ze bez dispatche na zaklade statickych typu to nepujde, ale kazdy vidi, ze je v tomhle pripade jedno jestli dispatchuju pri prekladu nebo az tesne pred volanim funkce.
Kazdopadne jakmile mam spravnou funkci, tak nepotrebuju dalsi featury OOP jazyka. Staci mi skladat funkce jednu za druhou. Algebra funkci je jednodussi nez algebra objektu, pokud beru objekt pouze jako mnozinu 1+ funkci.
De facto oop nepotrebujes vubec, viz gtk v c, jde se bez toho obejit a nasimulovat to, ale je to krajne nepohodlne. Takze pokud mi vlastnosti oop zjednodusi nebo alespon zprehledni praci, jsem za to rad, a soucasne jsem rad za to, ze je to jen moznost a nikoliv nutnost. Pro me je nejdulezitejsi moci s lehkosti, strucne a prehledne vyjadrit. A proto mam rad komplexni python s jeho multiparadigmatickym pristupem, dekoratory, generatory, comprehension a dalsimi featurami, protoze programovat v nem je poteseni a radost. Zvlast kdyz jsem nucen z profesnich duvodu programovat v necem tezkopadnem, a klopotnem jako je Java, tak ho potom o to vic umim ocenit. A ano, za to pohodli se plati vykonem.Ohledně OPP si myslím, že je vhodné pro něco, co si drží nějaké stavy. Např. desktopová aplikace. A hlavně si myslím, že z těch, kteří tvrdí, že umějí OOP, pak 80% porgramátorů přinejmenším zneužívá dědičnost pro sdílení kódu a hrubě pourušují SRP. Tolik k OOP.OOP je dobre treba na datove objekty, na vytvareni novych datovych typu. Zvlaste kdyz je jich hodne a maji hierarchickou strukturu. Typicky a vsude uvadeny pripad je GUI. A nebo ja jsem ted hodne ponoren do midi a midi eventů, u nich objektovy pristup take sedi jak zadek na hrnec. A s temito objekty pak muze byt dal klidne nakladano strukturovane nebo funkcionalne, jak je v dane situaci nejlepsi. Takze oop by mel byt dobry sluha aplikovany kam patri, ale ne spatny pan vnucovany nam z duvodu cistoty/uniformity jednoho paradigma i na miste, kde se nehodi.
Jinak mi přijde, že když už to tu není úplné OT o pohlavích, tak stejně si tu namísto debaty o OPP hodně lidí obhajuje nějaký svůj jazyk a debata se stáčí na dynamické typování, enumy a věci, které imho s OOP tolik nesouvisí.
Presne GUI a implementace vnitrnosti programovaciho prostredi (hierarchie cisel), nektery datovy struktury, jsou presne pripady, kde je fajn mit nastroje, co dokazou dispatchovat funkci hierarchicky.
Nemyslim si ale ze je k tomu potreba OOP jazyk, mela by stacit featura, ktera mi diapatchne spravnou funkci.
Napr. u hierarchie cisel. Mam pripady kdy scitam int a float:
1 + 1 (int_int_plus)
1.0 + 1 (float_int_plus)
1 + 1.0 (int_float_plus, nebo flip + float_int_plus)
1.0 + 1.0 (float_float_plus)
na zaklade typu potrebuju dispatchnout spravnou funkci nebo instrukci.
OOP s posilanim zprav nebo volanim metod je na to kratky, protoze dispatchuju pres dva argumenty. Muzu to ohackovat pres double dispatch. Nejakej haskell fanda mi muze tvrdit, ze bez dispatche na zaklade statickych typu to nepujde, ale kazdy vidi, ze je v tomhle pripade jedno jestli dispatchuju pri prekladu nebo az tesne pred volanim funkce.
Kazdopadne jakmile mam spravnou funkci, tak nepotrebuju dalsi featury OOP jazyka. Staci mi skladat funkce jednu za druhou. Algebra funkci je jednodussi nez algebra objektu, pokud beru objekt pouze jako mnozinu 1+ funkci.
A proto mam rad komplexni python s jeho multiparadigmatickym pristupem, dekoratory, generatory, comprehension a dalsimi featurami, protoze programovat v nem je poteseni a radost.A to jsi ještě nezmínil konkurentnost. Programovat něco konkurentního v Pythonu, to není potěšení a radost, to už je přímo orgastická extáze. Obzvlášť ve dvojce.
Se svym statickm stylem mysleni nedokazi vyuzivat jejich vyhodnych vlastnosti
OOP je dobre treba na datove objekty, na vytvareni novych datovych typu. Zvlaste kdyz je jich hodne a maji hierarchickou strukturu.Kdy potřebuješ hiearchickou strukturu? Čuchá čuchám zneužití dědičnosti na reusable kódu.
A proto mam rad komplexni python s jeho multiparadigmatickym pristupem, dekoratory, generatory, comprehension a dalsimi featurami, protoze programovat v nem je poteseni a radost.A to jsi ještě nezmínil konkurentnost. Programovat něco konkurentního v Pythonu, to není potěšení a radost, to už je přímo orgastická extáze. Obzvlášť ve dvojce.
ve dvojce jsem používal gevent a radost to byla.Radost je slabý slovo. Když si člověk vzpomene na ten debugging! Saturnálie!
A proc bych to mel jeste vic rozvadet? Rozvedeno je to vic nez dost. Pro ty, kterym je shury dano programovat v dynamickem prostredi to rozvadet nepotrebuji a pro ty ostatni je to zbytecne. Staticky jazyk, to je neco jako vezeni. Tvrda omezeni, pevny rad, vse mas nalajnovano, zadna svoboda/flexibilita. Je to efektivni a prinasi to pocit bezpeci, protoze je o tebe postarano a neses minimalni zodpovednost. Kdyz jsi v tom moc dlouho, tak se pak na svobode citis ztraceny a chtel bys zpet do toho vytyceneho radu, kde se o tebe postaraji. Vysvetluj nekomu takovemu hodnotu svobody. Ja ti pochopeni neprinesu a uz vubec nevnutim, to je tvuj boj, me to nevycitej a na me to neprenasej.Se svym statickm stylem mysleni nedokazi vyuzivat jejich vyhodnych vlastnostiMěl jsi možnost tyto výhodné vlastnosti rozvést. Proč jsi to neudělal?
Zadny tvuj sarkasmus nic nezmeni na faktu, ze programovat v Pythonu mi z uvedenych duvodu prinasi nejvetsi poteseni. A vzhledem k jeho oblibe a rozsireni, navzdory tomu, ze za nim nestoji zadny ekonomicky gigant, nebudu evidentne jediny. A zvazuji, co za tim asi je, ze tebe to tak zere :-).ve dvojce jsem používal gevent a radost to byla.Radost je slabý slovo. Když si člověk vzpomene na ten debugging! Saturnálie!
A zvazuji, co za tim asi je, ze tebe to tak zere :-).Mě to vůbec nežere, já v Pythonu dělám taky. Je to fajn jazyk, některé momenty má slabší a nesmí se to s ním moc přehánět, ale dělá se mi v něm dobře.
A proc bych to mel jeste vic rozvadet? Rozvedeno je to vic nez dost. Pro ty, kterym je shury dano programovat v dynamickem prostredi to rozvadet nepotrebuji a pro ty ostatni je to zbytecne. Staticky jazyk, to je neco jako vezeni. Tvrda omezeni, pevny rad, vse mas nalajnovano, zadna svoboda/flexibilita. Je to efektivni a prinasi to pocit bezpeci, protoze je o tebe postarano a neses minimalni zodpovednost. Kdyz jsi v tom moc dlouho, tak se pak na svobode citis ztraceny a chtel bys zpet do toho vytyceneho radu, kde se o tebe postaraji. Vysvetluj nekomu takovemu hodnotu svobody. Ja ti pochopeni neprinesu a uz vubec nevnutim, to je tvuj boj, me to nevycitej a na me to neprenasej.Se svym statickm stylem mysleni nedokazi vyuzivat jejich vyhodnych vlastnostiMěl jsi možnost tyto výhodné vlastnosti rozvést. Proč jsi to neudělal?
Pro ty, kterym je shury dano programovat v dynamickem prostredi to rozvadet nepotrebuji a pro ty ostatni je to zbytecne.
Staticky jazyk, to je neco jako vezeni. Tvrda omezeni, pevny rad, vse mas nalajnovano, zadna svoboda/flexibilita. Je to efektivni a prinasi to pocit bezpeci, protoze je o tebe postarano a neses minimalni zodpovednost. Kdyz jsi v tom moc dlouho, tak se pak na svobode citis ztraceny a chtel bys zpet do toho vytyceneho radu, kde se o tebe postaraji. Vysvetluj nekomu takovemu hodnotu svobody. Ja ti pochopeni neprinesu a uz vubec nevnutim, to je tvuj boj, me to nevycitej a na me to neprenasej.
Se svym statickm stylem mysleni nedokazi vyuzivat jejich vyhodnych vlastnosti
.....
Nekdo tomu rika event sourcing, nekdo funkcionalni programovani, nekdo programovani s explicitnim casem.
Blahopřeju k (zatím) nejdebilnějšímu příspěvku tohoto vlákna.
A zvazuji, co za tim asi je, ze tebe to tak zere :-).Mě to vůbec nežere, já v Pythonu dělám taky. Je to fajn jazyk, některé momenty má slabší a nesmí se to s ním moc přehánět, ale dělá se mi v něm dobře.
Ne, kontinuace je neco hodne jinyho.Nekdo tomu rika event sourcing, nekdo funkcionalni programovani, nekdo programovani s explicitnim casem.
Nejmenuje se to continuation? https://en.wikipedia.org/wiki/Continuation (https://en.wikipedia.org/wiki/Continuation)
Ja s typy nemam sebemensi problem. Ktera cast mozku chybi tobe, ze se nesrovna s dynamickymi typy?Pro ty, kterym je shury dano programovat v dynamickem prostredi to rozvadet nepotrebuji a pro ty ostatni je to zbytecne.Co mi to jenom připomíná? Aha, https://www.joelonsoftware.com/2005/12/29/the-perils-of-javaschools-2/ Kterou část mozku nemáš, že nepojme i informaci o typu?
Tvuj mozek mozna pojme informaci o typech, ale uz ne to, ze se deli na staticke/dynamicke a vedle toho na slabe/silne. Python ma silne typy, takze ti nikdy cislo implicitne nevyhodnoti jako string a naopak.Staticky jazyk, to je neco jako vezeni. Tvrda omezeni, pevny rad, vse mas nalajnovano, zadna svoboda/flexibilita. Je to efektivni a prinasi to pocit bezpeci, protoze je o tebe postarano a neses minimalni zodpovednost. Kdyz jsi v tom moc dlouho, tak se pak na svobode citis ztraceny a chtel bys zpet do toho vytyceneho radu, kde se o tebe postaraji. Vysvetluj nekomu takovemu hodnotu svobody. Ja ti pochopeni neprinesu a uz vubec nevnutim, to je tvuj boj, me to nevycitej a na me to neprenasej.
Někdy je to dobře. Říká se tomu "defenzivní programování". Víš, že 123+456 = 579 a nemusíš počítat s tím, že to bude 123456, pokud to interpreter vyhodnotí jako string.
Tady se ale prece nevede debata jestli typy ano nebo ne, ale v jake podobe. Na to jake mas silne reci o mozku ti unika i zakladni podstata diskuse. Dynamicky jazyk neznamena beztypovy jazyk.
Ostatně i v Basicu byly typy "číslo" (např "a") a "string" (např. "a$") právě z tohoto důvodu. Když jsem přecházel z Basicu na Pascal, tak jsem se typům taky divil, ale zjistil jsem, že to má logiku a řada dřívějších chyb záhadně vymizela.
Ne, nic takoveho jsem a) nedokazal protoze rozdil mezi statickymi a dynamickymi typy lezi jinde a b) neresim to stejne. Zakladni rozdil č v tom, ze vykonovou optimalizaci resim jen tam, kde je nutna a jinde se tim nemusim a naopak mam vyhodu flexibility dynamickych typu a to v naproste vetsine kodu, vetsinou celem. Python mi treba umoznuje zpracovavat vzajemnou realtime midi komunikaci nekolika nastroju pres na raspbery pi zero s velkou vykonovou rezervou, cpu je zatizeno asi na cca 10 %, nepozorovatelnou latenci a to bez jakychkoliv optimalizaci. Me ten vykon proste nezajima. Pohodli pri ladeni je hodne relativni. A) nemusim ladit spoustu problemu, ktere u me jednoduse vubec nevznikaji, b) mam jednodussi a prehlednejsi kod a tedy mensi mnozstvi chyb c) mam introspekci a snazsi odhalovani chyb, d) mam radu vybornych nastroju na testovani.
A rozhodování o typu? Sám říkáš "no tak inkluduju knihnovnu, která to řeší". Není rozhodnutí "inkluduju knihovnu, která tohle pole vezme jako float" právě volba typu? Zatímco jinde napíšu prostě float x[500], tam musím něco inkludvat, něco vytvořit, nějak tam ty data přechroupat dovnitř, musím vědět něco o rozhraní toho něčeho,...Se svym statickm stylem mysleni nedokazi vyuzivat jejich vyhodnych vlastnosti
Například?
Zatím jsi jenom dokázal, že se problém odsouvá z deklarace proměnné na deklaraci knihovny, která to zpracuje, ale řešíš to stejně. A navíc tam máš režie s rozhodováním o aktuálním typu za běhu a kontrolou validity kdekoliv, což u typovanýho systému můžeš udělat na vstupu a víš, že pak se ti typ dat bez tvýho vědomí nezmění. A že máš víc pohodlí při psaní, míň pohodlí při ladění.
Na vedomi to beru, ale velmi casto to jsou falesne predstavy a myty o statickych/dynamickych typech, o tom, co jde nebo nejde, co je nutne nebo nezbytne.Tohle je presne duvod, proc se v teto diskusi s uzivatelem operator vubec nema smysl bavit. Jak uz bylo zrejme z prvnich jeho prispevku, vubec nebere na vedomi, co sem ostatni lide napsali (konkretne Inkvizitor, BoneFlute a ja).A zvazuji, co za tim asi je, ze tebe to tak zere :-).Mě to vůbec nežere, já v Pythonu dělám taky. Je to fajn jazyk, některé momenty má slabší a nesmí se to s ním moc přehánět, ale dělá se mi v něm dobře.
Tve vyjadrovani pusobi jinym dojmem.A zvazuji, co za tim asi je, ze tebe to tak zere :-).Mě to vůbec nežere, já v Pythonu dělám taky. Je to fajn jazyk, některé momenty má slabší a nesmí se to s ním moc přehánět, ale dělá se mi v něm dobře.
Jo, kontinuace je monáda :DNe, kontinuace je neco hodne jinyho.Nekdo tomu rika event sourcing, nekdo funkcionalni programovani, nekdo programovani s explicitnim casem.
Nejmenuje se to continuation? https://en.wikipedia.org/wiki/Continuation (https://en.wikipedia.org/wiki/Continuation)
Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.A proc bych to mel jeste vic rozvadet? Rozvedeno je to vic nez dost. Pro ty, kterym je shury dano programovat v dynamickem prostredi to rozvadet nepotrebuji a pro ty ostatni je to zbytecne. Staticky jazyk, to je neco jako vezeni. Tvrda omezeni, pevny rad, vse mas nalajnovano, zadna svoboda/flexibilita. Je to efektivni a prinasi to pocit bezpeci, protoze je o tebe postarano a neses minimalni zodpovednost. Kdyz jsi v tom moc dlouho, tak se pak na svobode citis ztraceny a chtel bys zpet do toho vytyceneho radu, kde se o tebe postaraji. Vysvetluj nekomu takovemu hodnotu svobody. Ja ti pochopeni neprinesu a uz vubec nevnutim, to je tvuj boj, me to nevycitej a na me to neprenasej.Se svym statickm stylem mysleni nedokazi vyuzivat jejich vyhodnych vlastnostiMěl jsi možnost tyto výhodné vlastnosti rozvést. Proč jsi to neudělal?
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.
nemá smysl si stěžovat, že výpočetní model OOP je jiný než funkcionální, a tvrdit, že jeden je lepší než druhý.To ne.
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
dá se třeba zabezpečit funkce headPřipomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
Pokud si to dobre vybavuju, tak v Pascalu byl akorat tak fixni limit na delku (klasicky string do 255 znaku, ANSI string mel max. delku omezenou maximalni hodnotou integeru). Fixni delka patri spis k poli (pripade n-tici) a ne seznamu, tam pro to nevidim moc smysl.
head :: Vec (1 + more) a -> a
Vec je seznam s počtem prvků v typu, ale záleží co přesně znamená "fixní"
dá se třeba zabezpečit funkce headPřipomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
Pokud si to dobre vybavuju, tak v Pascalu byl akorat tak fixni limit na delku (klasicky string do 255 znaku, ANSI string mel max. delku omezenou maximalni hodnotou integeru). Fixni delka patri spis k poli (pripade n-tici) a ne seznamu, tam pro to nevidim moc smysl.Kód: [Vybrat]head :: Vec (1 + more) a -> a
Vec je seznam s počtem prvků v typu, ale záleží co přesně znamená "fixní"
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
K čemu může být užitečná fixní délka typu v seznamu? Seznam by tuto vlastnost nijak nevyužil.
Pro typovou kontrolu operací pracujících s délkou, třeba append. Je to prostě silnější typová kontrola při překladu.Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
K čemu může být užitečná fixní délka typu v seznamu? Seznam by tuto vlastnost nijak nevyužil.
"fixní" jsem spíš interpretoval jako "počet prvků seznamu je pevně daný typem, ale ne neměnný"dá se třeba zabezpečit funkce headPřipomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
Pokud si to dobre vybavuju, tak v Pascalu byl akorat tak fixni limit na delku (klasicky string do 255 znaku, ANSI string mel max. delku omezenou maximalni hodnotou integeru). Fixni delka patri spis k poli (pripade n-tici) a ne seznamu, tam pro to nevidim moc smysl.Kód: [Vybrat]head :: Vec (1 + more) a -> a
Vec je seznam s počtem prvků v typu, ale záleží co přesně znamená "fixní"
Pokud ma byt hlavicka fixni, rozhodne bych to nedelal pres vektor, ale pres strukturu/record/tuple.
Pro typovou kontrolu operací pracujících s délkou, třeba append. Je to prostě silnější typová kontrola při překladu.K čemu může být užitečná fixní délka typu v seznamu? Seznam by tuto vlastnost nijak nevyužil.Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
Pak to chce typovou třídu. Nijak to ale nesouvisí se zahrnutím velikosti kolekce přímo do typu.Pro typovou kontrolu operací pracujících s délkou, třeba append. Je to prostě silnější typová kontrola při překladu.K čemu může být užitečná fixní délka typu v seznamu? Seznam by tuto vlastnost nijak nevyužil.Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
Co když potřebuji mít v seznamu položky různého typu a s rozdílnou délkou?
Pak to chce typovou třídu. Nijak to ale nesouvisí se zahrnutím velikosti kolekce přímo do typu.Co když potřebuji mít v seznamu položky různého typu a s rozdílnou délkou?Pro typovou kontrolu operací pracujících s délkou, třeba append. Je to prostě silnější typová kontrola při překladu.K čemu může být užitečná fixní délka typu v seznamu? Seznam by tuto vlastnost nijak nevyužil.Připomněl jsi mi peklo fixní délky stringů v Pascalu. S tím se fakt nedalo rozumně pracovat. Staticky typovaného jazyka jsem si užil až až.Fixní délka v typu může být užitečná. I když asi spíše u seznamu než řetězce.
Jo, kontinuace je monáda :DTo sice jo, ale asi to nikomu úplně neobjasní, co to kontinuace je, páč monáda je beztak při troše vůle skoro všechno ;)
[...] je suffix takovyho logu skutecne kontinuace. [...] je kontinuace rovna tomu zasobniku.Sorry, ale obraty "log je kontinuace" a "kontinuace je rovna zásobníku" jsou mi teda úplně nesrozumitelný :)
Pak to chce typovou třídu. Nijak to ale nesouvisí se zahrnutím velikosti kolekce přímo do typu.
K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.
Ano::) Typova trida je v podstate rozhrani, akorat o neco lepsi.Pak to chce typovou třídu. Nijak to ale nesouvisí se zahrnutím velikosti kolekce přímo do typu.K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.
Jinak BaldSlatterovi - premyslel jsem nad tim a uznavam, ze mas pravdu o tom simply-typed lambda kalkulu. Asi to brzo vyzkousim v praxi, protoze se chystam napsat si prekladac totalniho funkcionalniho jazyka, ktery bude mit STLC jako typovy system.Tak to jsem rád. Ne kvůli tomu, kdo měl/má pravdu, ale že někdo projevil zájem a iniciativu a snad se něco zajímavé naučil. S překladačem držím palce.
Pokud to zrovna není diáda...kontinuace je monádamonáda je beztak při troše vůle skoro všechno
::) Typova trida je v podstate rozhrani, akorat o neco lepsi.Pak to chce typovou třídu. Nijak to ale nesouvisí se zahrnutím velikosti kolekce přímo do typu.K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.
[...] je suffix takovyho logu skutecne kontinuace. [...] je kontinuace rovna tomu zasobniku.Sorry, ale obraty "log je kontinuace" a "kontinuace je rovna zásobníku" jsou mi teda úplně nesrozumitelný :)
(Ne že bys to musel vysvětlovat ausgerechnet mně, ale docela pochybuju, žes tím příspěvkem někomu něco srozumitelnýho sdělil :) To jenom tak zpětná vazba pro tebe )
Dik za zpetnou vazbu. Event log je termin pouzivanej v event sourcingu. Event log = posloupnost zprav reprezentujicich zmenu nejakyho stavu.Ja vim, co je log. Kafka, Vue.js jsou muj denni chleba. Zrovna nedavno jsem dopsal stream processing engine (Kafka/Go) :)
Tech stejnych zprav jako 'volani metody' ve smalltalku, jen jsou ty zpravy nekam logovany a ne zapomenuty.
Dik za zpetnou vazbu. Event log je termin pouzivanej v event sourcingu. Event log = posloupnost zprav reprezentujicich zmenu nejakyho stavu.Ja vim, co je log. Kafka, Vue.js jsou muj denni chleba. Zrovna nedavno jsem dopsal stream processing engine (Kafka/Go) :)
Tech stejnych zprav jako 'volani metody' ve smalltalku, jen jsou ty zpravy nekam logovany a ne zapomenuty.
Spis jde o to, ze log je log a kontinuace je kontinuace. I kdyz to spolu souvisi, je to neco jinyho.
Je to jako bys rekl, ze seznam je funkce :) Jo, funkce se da popsat seznamem a naopak, ale i tak je to neco jinyho :)
K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.UserName = String[1..255]
K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.UserName = String[1..255]
Naprosto běžný a obvyklý use case, který se v praxi řeší (zatím) blbě pomocí assertů.
Ne, je to typ UserName, který obsahuje string v rozsahu 1 až 255. Omezení délky textu.K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.UserName = String[1..255]
Naprosto běžný a obvyklý use case, který se v praxi řeší (zatím) blbě pomocí assertů.
To jako pole pro 255 stringů? K čemu mi to bude, když potřebuji seznam stringů a dopředu nevím, zda jich bude 20 nebo 20000?
Ne, je to typ UserName, který obsahuje string v rozsahu 1 až 255. Omezení délky textu.To jako pole pro 255 stringů? K čemu mi to bude, když potřebuji seznam stringů a dopředu nevím, zda jich bude 20 nebo 20000?K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.UserName = String[1..255]
Naprosto běžný a obvyklý use case, který se v praxi řeší (zatím) blbě pomocí assertů.
Tak nezněla otázka.Ne, je to typ UserName, který obsahuje string v rozsahu 1 až 255. Omezení délky textu.To jako pole pro 255 stringů? K čemu mi to bude, když potřebuji seznam stringů a dopředu nevím, zda jich bude 20 nebo 20000?K čemu by mi byla typová třída, když mi plně vyhovuje rozhraní? A tu kolekci chci mít nafukovací, takže její fixní velikost by mi byla také k ničemu.UserName = String[1..255]
Naprosto běžný a obvyklý use case, který se v praxi řeší (zatím) blbě pomocí assertů.
Který objektový jazyk tohle používá?
Kontinuaci můžeš implementovat pomocí logu (a naopak), ale jsou to jiné koncepty.BTW, dobře je to vidět na tom tvrzení "kontinuace je monáda". To je pravda (za nějakých podmínek).
seznam = funkce a naopak. Jestli to je pravda, tak je to isomorfismus, jinak receno prejmenovani.1. obecně není už proto, že funkčních hodnot může být nespočetně mnoho, zatímco položek listu je vždycky jenom spočetně.
Kontinuace je 'zbytek vypoctu'.Je to přesně naopak, kontinuace je funkce reprezentující nějaký výpočet, které se předá “zbytek výpočtu” ve formě funkce. Z Wikipedie bys mohl pochopit aspoň převod konstanty na příslušnou kontinuaci.
Kontinuace je 'zbytek vypoctu'.Je to přesně naopak, kontinuace je funkce reprezentující nějaký výpočet, které se předá “zbytek výpočtu” ve formě funkce. Z Wikipedie bys mohl pochopit aspoň převod konstanty na příslušnou kontinuaci.
Vůbec nevíš, která bije. Jestli s tím “pracuješ” v bakalářce, tak ji neobhájíš ani ne VŠE.Kontinuace je 'zbytek vypoctu'.Je to přesně naopak, kontinuace je funkce reprezentující nějaký výpočet, které se předá “zbytek výpočtu” ve formě funkce. Z Wikipedie bys mohl pochopit aspoň převod konstanty na příslušnou kontinuaci.
Synku, ja s timhle pracuju, tak snad vim, o cem mluvim.
Ty zrejme mluvis o funkci callcc, neboli call-with-current-continuation, ktera dostane parametr K, coz je kontinuace, neboli zbytek vypoctu.
Vůbec nevíš, která bije. Jestli s tím “pracuješ” v bakalářce, tak ji neobhájíš ani ne VŠE.Kontinuace je 'zbytek vypoctu'.Je to přesně naopak, kontinuace je funkce reprezentující nějaký výpočet, které se předá “zbytek výpočtu” ve formě funkce. Z Wikipedie bys mohl pochopit aspoň převod konstanty na příslušnou kontinuaci.
Synku, ja s timhle pracuju, tak snad vim, o cem mluvim.
Ty zrejme mluvis o funkci callcc, neboli call-with-current-continuation, ktera dostane parametr K, coz je kontinuace, neboli zbytek vypoctu.
P.S. Call/cc je něco zcela jiného.
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?
Vůbec nevíš, která bije. Jestli s tím “pracuješ” v bakalářce, tak ji neobhájíš ani ne VŠE.Kontinuace je 'zbytek vypoctu'.Je to přesně naopak, kontinuace je funkce reprezentující nějaký výpočet, které se předá “zbytek výpočtu” ve formě funkce. Z Wikipedie bys mohl pochopit aspoň převod konstanty na příslušnou kontinuaci.
Synku, ja s timhle pracuju, tak snad vim, o cem mluvim.
Ty zrejme mluvis o funkci callcc, neboli call-with-current-continuation, ktera dostane parametr K, coz je kontinuace, neboli zbytek vypoctu.
P.S. Call/cc je něco zcela jiného.
Mas neco cim bys prispel do diskuse nebo tady chces jen dal trollovat?
Jestli chces pokracovat tak predstav svuj argument k vyvraceni a neschovavej se za nejaky hadanky.
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?
V dynamických jazycích jako python a ruby nejsou makra moc potřeba.V Ruby se makra (a DSLka) používají až tak extenzivně, že to dělá kód totálně nečitelný. Proto Ruby nemám rád - většina Ruby kódu, co jsem viděl, na mě působila jako že hlavní účel kódu je co největší onanie a ne srozumitelnost a čitelnost.
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?Já bych řekl, že principielně jsou to ortogonální koncepty. Makra slouží k automatickému generování kódu z dat - tj. jsou někde na úrovni "textu programu" (v případě hloupých C maker doslovně, v případě plnotučných na úrovni AST). OOP je o tom, jak modelovat problém, jak program strukturovat. Takže je to spíš o nějakou tu úroveň výš.
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?Čistě prakticky je ale pravda, že v dobrém OOP jazyce makra moc nevyužiješ, protože máš prostě jiné prostředky pro dosažení podobných cílů. IMHO makra nejvíc využiješ ve statickém, kompilovaném jazyce, který se hodně motá kolem funkcí.
Makro je funkce mapujici na AST.To je jenom jeden význam slova "makro". Makrům v C taky říkáme "makra" a s AST nepracují.
Cim bliz je reprezentace v textu podobna reprezentaci v ast, tim vypada makro citelneji.To není nutně pravda. Např. v Elixiru je AST poměrně komplikované, ale moc to nevadí, protože napřímo s ním skoro nikdy nepracuješ. Používáš totiž quote (čili normální, bežný kód) a jenom tam občas třeba vpašuješ nějaký parametr nebo tak něco.
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?Čistě prakticky je ale pravda, že v dobrém OOP jazyce makra moc nevyužiješ, protože máš prostě jiné prostředky pro dosažení podobných cílů. IMHO makra nejvíc využiješ ve statickém, kompilovaném jazyce, který se hodně motá kolem funkcí.
ale zároveň se mi zkontroluje při překladu, že tam mám parametrů přesný počet, že implementují potřebný trait atd. Jelikož pozdní vazba je tak super, šlo by v OOP minimálně počítat ty parametry, počet by měl sedět i přes existenci pozdní vazby.Ani na jedno z toho nepotřebuješ makra.
No makro umožňuje psát věci jinak, řekl bych líp. Třeba v Rustu println! a spol., nic lepšího jsem zatím pro formátování řetězců neviděl. Ten formát napíšu hezky čitelně a úsporně, ale zároveň se mi zkontroluje při překladu, že tam mám parametrů přesný počet, že implementují potřebný trait atd. Jelikož pozdní vazba je tak super, šlo by v OOP minimálně počítat ty parametry, počet by měl sedět i přes existenci pozdní vazby.
Chlapi (a roby), mám zcela nový podnět do diskuse. Když odmyslím Lisp s jeho objektovou nadstavbou, existuje v (skutečném) OOP světě něco jako makra? Pokud ano, jak moc se používají a pokud ne, tak proč ne?
Osobně se domnívám, že největší motivace jsou takové ty short-circuit operátory, nebo podobné serepetičky. Páč jinak mě nenapadá na co by nutně muselo být makro potřeba. Všechno se dá zapsat funkcí :-)
V C je makro preprocessoru mapovani z prvni textovy na druhou textovou reprezentaci. Kompiler pak prevede vysledek na ast a ten pak hodi do vyslednyho binarniho kodu.Makro je funkce mapujici na AST.To je jenom jeden význam slova "makro". Makrům v C taky říkáme "makra" a s AST nepracují.
Cim bliz je reprezentace v textu podobna reprezentaci v ast, tim vypada makro citelneji.To není nutně pravda. Např. v Elixiru je AST poměrně komplikované, ale moc to nevadí, protože napřímo s ním skoro nikdy nepracuješ. Používáš totiž quote (čili normální, bežný kód) a jenom tam občas třeba vpašuješ nějaký parametr nebo tak něco.
Jinymi slovy, nejaka funkce, ktera transformuje reprezentaci programu predtim nez se prevese na AST nebo na target. Zkratka nejaky predchroupani at uz jakyhokoliv typu.No ono to právě není jedno, jakýho typu. Buď pracuju s textem, aniž bych znal jeho význam, nebo pracuju s AST. To je úplně něco jinýho a má to výrazně jiné možnosti.
Elixir ma myslim prave jednoduchou a homoikonickou reprezentaci AST.No asi je to otázka, čemu chceš říkat "jednoduchá". Každopádně kdybys měl napsat AST tak, aby ti vygenerovalo nějaký kód, tak bys z toho moc nadšenej nebyl, je to trochu opruz. Jak jsem ale řekl, v drtivé většině případů to nepotřebuješ dělat.
Vsemozny konstrukce jako classy jsou implementovany prave pres manipulaci AST, pokud si vzpominam.Elixir žádné classy nemá a makra se nepoužívají zas tak často (autor jazyka správně tvrdí, že zlaté pravidlo je "dokud to jde udělat funkcí, udělejte to funkcí"). Takže to si spíš asi s něčím pleteš.
Pokud do quotace muzes vlozit parametr, pak se podle me jedna o tzv. quasiquotaci.Tohle vůbec nechápu. S interpolací to, o čem jsem mluvil, nemá nic společnýho.
abcd - text
"abcd" - quotovany text, neboli string
f"abcd {n}" - quasiquotovany string, neboli string interpolation
$ iex
Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]
Interactive Elixir (1.6.6) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> quote do if f(1) do 1 else 2 end end
{:if, [context: Elixir, import: Kernel], [{:f, [], [1]}, [do: 1, else: 2]]}
iex(2)> f(1)
** (CompileError) iex:2: undefined function f/1
Osobně se domnívám, že největší motivace jsou takové ty short-circuit operátory, nebo podobné serepetičky. Páč jinak mě nenapadá na co by nutně muselo být makro potřeba. Všechno se dá zapsat funkcí :-)Občas se s tím dají udělat docela dobrý kravinky pro optimalizaci.
No makro umožňuje psát věci jinak, řekl bych líp. Třeba v Rustu println! a spol., nic lepšího jsem zatím pro formátování řetězců neviděl. Ten formát napíšu hezky čitelně a úsporně, ale zároveň se mi zkontroluje při překladu, že tam mám parametrů přesný počet, že implementují potřebný trait atd. Jelikož pozdní vazba je tak super, šlo by v OOP minimálně počítat ty parametry, počet by měl sedět i přes existenci pozdní vazby.
Nahlédl jsem do manuálu Rustu a zjistil jsem, že zmíněný println! funguje stejně jako print v Pythonu. Ani PHP nezůstává nijak pozadu a také na to nepotřebuje makra. Něco mi snad uniklo?
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.
V dynamických jazycích jako python a ruby nejsou makra moc potřeba.V Ruby se makra (a DSLka) používají až tak extenzivně, že to dělá kód totálně nečitelný. Proto Ruby nemám rád - většina Ruby kódu, co jsem viděl, na mě působila jako že hlavní účel kódu je co největší onanie a ne srozumitelnost a čitelnost.
Jinymi slovy, nejaka funkce, ktera transformuje reprezentaci programu predtim nez se prevese na AST nebo na target. Zkratka nejaky predchroupani at uz jakyhokoliv typu.No ono to právě není jedno, jakýho typu. Buď pracuju s textem, aniž bych znal jeho význam, nebo pracuju s AST. To je úplně něco jinýho a má to výrazně jiné možnosti.Elixir ma myslim prave jednoduchou a homoikonickou reprezentaci AST.No asi je to otázka, čemu chceš říkat "jednoduchá". Každopádně kdybys měl napsat AST tak, aby ti vygenerovalo nějaký kód, tak bys z toho moc nadšenej nebyl, je to trochu opruz. Jak jsem ale řekl, v drtivé většině případů to nepotřebuješ dělat.Vsemozny konstrukce jako classy jsou implementovany prave pres manipulaci AST, pokud si vzpominam.Elixir žádné classy nemá a makra se nepoužívají zas tak často (autor jazyka správně tvrdí, že zlaté pravidlo je "dokud to jde udělat funkcí, udělejte to funkcí"). Takže to si spíš asi s něčím pleteš.Pokud do quotace muzes vlozit parametr, pak se podle me jedna o tzv. quasiquotaci.Tohle vůbec nechápu. S interpolací to, o čem jsem mluvil, nemá nic společnýho.
abcd - text
"abcd" - quotovany text, neboli string
f"abcd {n}" - quasiquotovany string, neboli string interpolation
quote je taková trochu speciální funkce, která:
1. se spouští při překladu
2. vložíš do ní normální blok kódu a ona ti vrátí příslušný AST
3. tj. když do toho kódu vpašuješ parametr, quote ti ho vpašuje do toho AST, aniž bys AST musel "ručně" upravovat (provádět operace přímo nad daty AST)Kód: [Vybrat]$ iex
Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]
Interactive Elixir (1.6.6) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> quote do if f(1) do 1 else 2 end end
{:if, [context: Elixir, import: Kernel], [{:f, [], [1]}, [do: 1, else: 2]]}
iex(2)> f(1)
** (CompileError) iex:2: undefined function f/1
- na tomhle vidíš:
1. quote skutečně "cituje" svůj parametr (převádí ho na AST) - používám tam fci f/1, která není definovaná a ničemu to nevadí, protože se v tuhle chvíli nevolá
2. to elixirovské AST je fakt celkem komplikované (a tohle je ještě jednoduchý příklad, mohl bych ukázat složitější), není to jako v Lispu
Ty jseš dokonalý příklad Dunning-Krugera, jako vystřižený z jedné glosy o flatearthers “Retarded monkeys lecturing Nobel laureates”. No nic, každé fórum musí mít svého šaška, jde ti to lépe jež javamanovi ;)Jinymi slovy, nejaka funkce, ktera transformuje reprezentaci programu predtim nez se prevese na AST nebo na target. Zkratka nejaky predchroupani at uz jakyhokoliv typu.No ono to právě není jedno, jakýho typu. Buď pracuju s textem, aniž bych znal jeho význam, nebo pracuju s AST. To je úplně něco jinýho a má to výrazně jiné možnosti.Elixir ma myslim prave jednoduchou a homoikonickou reprezentaci AST.No asi je to otázka, čemu chceš říkat "jednoduchá". Každopádně kdybys měl napsat AST tak, aby ti vygenerovalo nějaký kód, tak bys z toho moc nadšenej nebyl, je to trochu opruz. Jak jsem ale řekl, v drtivé většině případů to nepotřebuješ dělat.Vsemozny konstrukce jako classy jsou implementovany prave pres manipulaci AST, pokud si vzpominam.Elixir žádné classy nemá a makra se nepoužívají zas tak často (autor jazyka správně tvrdí, že zlaté pravidlo je "dokud to jde udělat funkcí, udělejte to funkcí"). Takže to si spíš asi s něčím pleteš.Pokud do quotace muzes vlozit parametr, pak se podle me jedna o tzv. quasiquotaci.Tohle vůbec nechápu. S interpolací to, o čem jsem mluvil, nemá nic společnýho.
abcd - text
"abcd" - quotovany text, neboli string
f"abcd {n}" - quasiquotovany string, neboli string interpolation
quote je taková trochu speciální funkce, která:
1. se spouští při překladu
2. vložíš do ní normální blok kódu a ona ti vrátí příslušný AST
3. tj. když do toho kódu vpašuješ parametr, quote ti ho vpašuje do toho AST, aniž bys AST musel "ručně" upravovat (provádět operace přímo nad daty AST)Kód: [Vybrat]$ iex
Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]
Interactive Elixir (1.6.6) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> quote do if f(1) do 1 else 2 end end
{:if, [context: Elixir, import: Kernel], [{:f, [], [1]}, [do: 1, else: 2]]}
iex(2)> f(1)
** (CompileError) iex:2: undefined function f/1
- na tomhle vidíš:
1. quote skutečně "cituje" svůj parametr (převádí ho na AST) - používám tam fci f/1, která není definovaná a ničemu to nevadí, protože se v tuhle chvíli nevolá
2. to elixirovské AST je fakt celkem komplikované (a tohle je ještě jednoduchý příklad, mohl bych ukázat složitější), není to jako v Lispu
V elixiru to jsou protocoly a jiny struktury, ne classy, ale nic to nemeni na to, ze jsou implementovany az v elixiru pomoci maker.
Pomoci quote a unquote delas v elixiru quasiquotaci. Klasicka quotace neni dostatecna. Priklad byl na quotaci stringu, kterou jsi nepochopil. V tomhle pripade nequotuju AST, ale pouze string. Doslova quotuju protoze pouzivam uvozovky.
Elixir AST je vlastne lisp, az na druhy parametr coz je nejaky context. Elixir je syntakticky cukr nad timhle jednoduchym AST.
https://hackernoon.com/understanding-elixir-macros-3464e141434c
Ty jseš dokonalý příklad Dunning-Krugera, jako vystřižený z jedné glosy o flatearthers “Retarded monkeys lecturing Nobel laureates”. No nic, každé fórum musí mít svého šaška, jde ti to lépe jež javamanovi ;)
V těch kecech o logách, kontinuacích, ASTu...Ty jseš dokonalý příklad Dunning-Krugera, jako vystřižený z jedné glosy o flatearthers “Retarded monkeys lecturing Nobel laureates”. No nic, každé fórum musí mít svého šaška, jde ti to lépe jež javamanovi ;)v čem nemá pravdu?
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.
parametry format může v pythonu kontrolovat linter
https://pypi.org/project/flake8-string-format/
Python 3.6, má format stringy, kontrola názvů proměnných uvnitř format stringu funguje normálně.
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.No makro umožňuje psát věci jinak, řekl bych líp. Třeba v Rustu println! a spol., nic lepšího jsem zatím pro formátování řetězců neviděl. Ten formát napíšu hezky čitelně a úsporně, ale zároveň se mi zkontroluje při překladu, že tam mám parametrů přesný počet, že implementují potřebný trait atd. Jelikož pozdní vazba je tak super, šlo by v OOP minimálně počítat ty parametry, počet by měl sedět i přes existenci pozdní vazby.Nahlédl jsem do manuálu Rustu a zjistil jsem, že zmíněný println! funguje stejně jako print v Pythonu. Ani PHP nezůstává nijak pozadu a také na to nepotřebuje makra. Něco mi snad uniklo?
to nejsou makra. V Ruby jsou možná makra jen pomocí third party knihoven, ale nikdo je nepoužívá. Matsumoto se vyjádřil jasně, že makra v jazyku typu Ruby nejsou potřeba.Ok, je to možný, že to nejsou makra v tom smyslu, jak jsou implementovaný v Lispu nebo Elixiru. Ruby neznám tolik, abych to uměl pořádně posoudit. Každopádně se tomu makra říká [1] a používá se to k zavádění nové syntaxe, DSLek apod., což je typickej use case pro makra. A ten bordel, co tím Rubyisti vytvořili, je taky typickej pro nevhodný použití maker.
v čem nemá pravdu?Všechno jsou to takový víc nebo míň zavádějící polopravdy, u kterých (alespoň mně) vlastně není vůbec jasný, co chtěl Kadet sdělit, kromě toho, že použil správný klíčový slova. Moc nemá smysl to kdovíjak rozebírat, protože zas jenom skončíme u nekonečnýho hádání se o slova a význam vět, což mě nebaví.
V elixiru to jsou protocoly a jiny struktury, ne classy, ale nic to nemeni na to, ze jsou implementovany az v elixiru pomoci maker.Nevím, o čem přesně mluvíš. No třeba "defprotocol" je makro, no. A co z toho má plynout? Nevím, kam míříš.
Pomoci quote a unquote delas v elixiru quasiquotaci. Klasicka quotace neni dostatecna.Pojem "quasiquotace" slyším poprvé. Jestli rozdíl mezi quotací a quasi-quotací má být v tom, že do toho druhýho můžeš dávat parametry, tak samozřejmě. Makra bez parametrů by byla dost naprd, to je jasný. A proč to říkáš?
Priklad byl na quotaci stringu, kterou jsi nepochopil.Pochopil, ale nepřijde mi to jako dobrej příklad. Je srozumitelnej jenom tomu, kdo už ví, co makra jsou, a najde si to v tom.
Elixir AST je vlastne lisp, az na druhy parametr coz je nejaky context.To právě imho není vždycky pravda. AFAIK, v Lispu je vždycky jasný, jak AST pro nějaký výraz bude vypadat. V Elixiru je to trochu komplikovanější - různé struktury se převádí na různá AST data, z prstu si to nevycucáš, musíš si to buď zkusit, nebo si to najít v dokumentaci. Např.:
iex(2)> quote do [1,2,3] end
[1, 2, 3]
iex(3)> quote do [1,2|3] end
[1, {:|, [], [2, 3]}]
iex(4)> quote do [1,2|_] end
[1, {:|, [], [2, {:_, [], Elixir}]}]
- tady prostě musíš vědět, že "|" se do AST převede zrovna takhle. AST by klidně mohlo vypadat klidně jinak. Úplně 100%ně intuitivní to není.Elixir je syntakticky cukr nad timhle jednoduchym AST.Jako celý Elixir? To rozhodně není pravda. Některé věci jsou v Elixiru samozřejmě implementované pomocí maker. Proč ne, když tam ta makra jsou a dává to smysl?
https://hackernoon.com/understanding-elixir-macros-3464e141434cProč mi tenhle link dáváš? Já vím, k čemu se makra v Elixiru používají, pracuju s nima často.
V tomhle pripade nequotuju ASTAST se nequotuje. AST je výsledkem quotace. Quotuje se (platný) výraz (jazyka).
V elixiru to jsou protocoly a jiny struktury, ne classy, ale nic to nemeni na to, ze jsou implementovany az v elixiru pomoci maker.Nevím, o čem přesně mluvíš. No třeba "defprotocol" je makro, no. A co z toho má plynout? Nevím, kam míříš.Pomoci quote a unquote delas v elixiru quasiquotaci. Klasicka quotace neni dostatecna.Pojem "quasiquotace" slyším poprvé. Jestli rozdíl mezi quotací a quasi-quotací má být v tom, že do toho druhýho můžeš dávat parametry, tak samozřejmě. Makra bez parametrů by byla dost naprd, to je jasný. A proč to říkáš?Priklad byl na quotaci stringu, kterou jsi nepochopil.Pochopil, ale nepřijde mi to jako dobrej příklad. Je srozumitelnej jenom tomu, kdo už ví, co makra jsou, a najde si to v tom.Elixir AST je vlastne lisp, az na druhy parametr coz je nejaky context.To právě imho není vždycky pravda. AFAIK, v Lispu je vždycky jasný, jak AST pro nějaký výraz bude vypadat. V Elixiru je to trochu komplikovanější - různé struktury se převádí na různá AST data, z prstu si to nevycucáš, musíš si to buď zkusit, nebo si to najít v dokumentaci. Např.:Kód: [Vybrat]iex(2)> quote do [1,2,3] end
- tady prostě musíš vědět, že "|" se do AST převede zrovna takhle. AST by klidně mohlo vypadat klidně jinak. Úplně 100%ně intuitivní to není.
[1, 2, 3]
iex(3)> quote do [1,2|3] end
[1, {:|, [], [2, 3]}]
iex(4)> quote do [1,2|_] end
[1, {:|, [], [2, {:_, [], Elixir}]}]Elixir je syntakticky cukr nad timhle jednoduchym AST.Jako celý Elixir? To rozhodně není pravda. Některé věci jsou v Elixiru samozřejmě implementované pomocí maker. Proč ne, když tam ta makra jsou a dává to smysl?https://hackernoon.com/understanding-elixir-macros-3464e141434cProč mi tenhle link dáváš? Já vím, k čemu se makra v Elixiru používají, pracuju s nima často.
----
Vůbec celkově nechápu, co se vlastně snažíš říct - jestli jenom upřesňuješ něco z toho, co jsem řekl, nebo něco vyvracíš, nebo jenom tak plkáme. Zkus být trochu explicitnější, jestli chceš o něčem diskutovat - pokud možno zkus prosím použít věty jako "v tomhle nemáš pravdu", "tohle bych upřesnil" apod. :)
Ty jseš dokonalý příklad Dunning-Krugera, jako vystřižený z jedné glosy o flatearthers “Retarded monkeys lecturing Nobel laureates”. No nic, každé fórum musí mít svého šaška, jde ti to lépe jež javamanovi ;)
Ty jseš dokonalý příklad Dunning-Krugera, jako vystřižený z jedné glosy o flatearthers “Retarded monkeys lecturing Nobel laureates”. No nic, každé fórum musí mít svého šaška, jde ti to lépe jež javamanovi ;)
Quasiquotace nebo quotace je detail. Quasi je obecnejsi. Ale kdyz lidi rikaji quotace, pravdepodobne mysli quasi. Jen pro upresneni.Ok, tohle upřesnění může mít smysl.
Elixir je syntakticky cukr nad ast [...] Dalo by se rict, ze je to instance Greenspunova desateho pravidla.S tímhle nemůžu souhlasit, hlavně ze dvou důvodů:
https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule
Ta transformace z elixiru do de facto lispu je komplikovana kvuli vsemoznym infix operatorum, ktery se akorat prevedou na prefiz operatory. Je to krasne videt na prikladu co jsi postnul.Právě na tom příkladu je vidět, že to není tak, jak píšeš. Proč se tam to "[1,2|_]" nepřevede třeba na
{:|, [], [
[1,2],
{:_, [], Elixir}
]}
? No, protože se tak autoři jazyka z nějakých důvodů rozhodli. A klidně se mohli rozhodnout jinak. Dokud se s tím jejich rozhodnutím neseznámíš, nevíš.Nekdy to delam tak ze poukazu na nejasny pouziti vyrazu. Nekdy to pomuze, jindy to urazi. Neminim to jako utok.V pohodě, za to jsem vždycky vděčný. Akorát, upřímně řečeno, u tebe to na mě často nepůsobí jako upřesnění, ale spíš jako zamlžení.
Predtim jsem upresnoval definici co to je makro.No, to je přesně ten případ. Nepřijde mi, že bys to nějak upřesnil. Kdybys to chtěl upřesnit, mohl's napsat něco jako "maker máme X typů, jsou to [...] a rozdíl mezi nimi je v [...] přičemž jazyk Z má makra typu [...]" apod.
2. Elixir má spoustu featur a některé jsou dost unikátní. Např. posílání zpráv, procesy, atd. Jestli ti v něčem přijde jako "zakuklený lisp", tak jenom na nejnižší úrovni - a na té je to (v nějakém, příliš obecném smyslu) prakticky každý jazyk. Mohl bys klidně říct, že "všechno je zakuklený lambda kalkul". Takové tvrzení není k ničemu dobré.Kdybys napsal, že Elixir je syntaktický cukr nad Erlangem, tak by to bylao jiný kafe. Tohle tvrzení se objevuje relativně často a je prokazatelně nepravdivé. Viz např. https://joearms.github.io/published/2013-05-31-a-week-with-elixir.html (přímo od Armstronga, takže celkem autoritativní ;) ). Jediný příklad za všechny:
In Erlang FORMS are not EXPRESSIONS.
(disclaimer: ten článek je dost starý a některé věci už pro aktuální Elixir nemusí platit)
Quasiquotace nebo quotace je detail. Quasi je obecnejsi. Ale kdyz lidi rikaji quotace, pravdepodobne mysli quasi. Jen pro upresneni.Ok, tohle upřesnění může mít smysl.Elixir je syntakticky cukr nad ast [...] Dalo by se rict, ze je to instance Greenspunova desateho pravidla.S tímhle nemůžu souhlasit, hlavně ze dvou důvodů:
https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule
1. je to tak strašně obecné tvrzení, že těžko říct, co tím myslíš. Je to jako když někdo řekne "Češi jsou [...]". Nevím, jestli myslíš "většinu aspektů", "všechny aspekty" nebo "některé aspekty" jazyka...
2. Elixir má spoustu featur a některé jsou dost unikátní. Např. posílání zpráv, procesy, atd. Jestli ti v něčem přijde jako "zakuklený lisp", tak jenom na nejnižší úrovni - a na té je to (v nějakém, příliš obecném smyslu) prakticky každý jazyk. Mohl bys klidně říct, že "všechno je zakuklený lambda kalkul". Takové tvrzení není k ničemu dobré.Ta transformace z elixiru do de facto lispu je komplikovana kvuli vsemoznym infix operatorum, ktery se akorat prevedou na prefiz operatory. Je to krasne videt na prikladu co jsi postnul.Právě na tom příkladu je vidět, že to není tak, jak píšeš. Proč se tam to "[1,2|_]" nepřevede třeba naKód: [Vybrat]{:|, [], [
? No, protože se tak autoři jazyka z nějakých důvodů rozhodli. A klidně se mohli rozhodnout jinak. Dokud se s tím jejich rozhodnutím neseznámíš, nevíš.
[1,2],
{:_, [], Elixir}
]}Nekdy to delam tak ze poukazu na nejasny pouziti vyrazu. Nekdy to pomuze, jindy to urazi. Neminim to jako utok.V pohodě, za to jsem vždycky vděčný. Akorát, upřímně řečeno, u tebe to na mě často nepůsobí jako upřesnění, ale spíš jako zamlžení.Predtim jsem upresnoval definici co to je makro.No, to je přesně ten případ. Nepřijde mi, že bys to nějak upřesnil. Kdybys to chtěl upřesnit, mohl's napsat něco jako "maker máme X typů, jsou to [...] a rozdíl mezi nimi je v [...] přičemž jazyk Z má makra typu [...]" apod.
Ok, Syntakticka cast elixiru je syntakticky cukr nad skoro lispem.Já ti pořád snáším argumenty, proč to není pravda (resp. je to zavádějící) a ty to pořád opakuješ :) Buď si ten "skoro lisp" nadefinuješ tak, že "syntaktický cukr nad skoro lispem" bude všechno, nebo to nebude Elixir. Tak jako tak není to tvoje tvrzení k ničemu dobré, protože víc zamlžuje než objasňuje.
Skoro lispem protoze stale micha infix a prefix syntax. Infix v pripade toho seznamu. Mohl by ho reprezentovat jako (, 1 2 3) misto infixovyho [1,2,3]. Tvuj priklad kodu mi pripada, ze nedela totez co tvuj prechodi priklad. Autori se rozhodli ze nekdy je lepsi citelnost nebo vykonnost nad jednoduchosti a proto zamichali infix a prefix zapis v elixir ast.Abych to (naposledy) shrnul: Nejde o infix a prefix. Neukazoval jsem kód, ale AST. A není to totéž AST, protože jsem ukazoval dvě představitelné varianty, jak by se dal do AST zakódovat jeden elixirovský výraz. A rozhodnutí, který z těch dvou bude skutečně použit, je arbitrární. Tím argumentuju pro to, že narozdíl od Lispu, v Elixiru není intuitivně jasné, jak bude AST vypadat, což je podstatný rozdíl. Proto považuju tvoje tvrzení "je to vlastně Lisp" za zavádějící.
Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.
Však to v Pythonu odchytí testy, ne?
...
Podobne v clojure, coz je lisp family ale mota tam infix notaci kvuli citelnosti. Clojure vypada vic jako cisty lisp. U elixiru musi clovek vic zamhourit oci aby to videl.
....
Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.Však to v Pythonu odchytí testy, ne?
...
Podobne v clojure, coz je lisp family ale mota tam infix notaci kvuli citelnosti. Clojure vypada vic jako cisty lisp. U elixiru musi clovek vic zamhourit oci aby to videl.
....
Muzes ukazat priklad infix notace v clojure?
Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.Však to v Pythonu odchytí testy, ne?
Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?
...
Podobne v clojure, coz je lisp family ale mota tam infix notaci kvuli citelnosti. Clojure vypada vic jako cisty lisp. U elixiru musi clovek vic zamhourit oci aby to videl.
....
Muzes ukazat priklad infix notace v clojure?
(hash-map :key1 1, :key1 2)
Ta carka je infix syntakticky cukr.
{:key1 1, :key1 2}
Dalsi syntakticky cukr je pouziti jinych zavorek.
https://clojuredocs.org/clojure.core/hash-map
Typický inkvizitorský bullshit. V pythonu bys dnes měl v první řadě používat fstringy a v tu ránu ti zmíněný problém nehrozí. Mimo to, že ti nesedí počet argumentů, ti ošetří lint realtime už při psaní, viz obrázek. Když od někud taháš data, musíš si je validovat v každém jazyce. Statické C ti bez toho s makry i bez nich padá jako zralá hruška. Výjimky jsou tu od toho, abys je ošetřoval a ne proto, abys je ignoroval a nechal na nich spadnout program. A když jsi takový neumětel, že si neošetřuješ IO operace, nic jiného si ani nezasloužíš a to v libovolnám jazyce.Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.Však to v Pythonu odchytí testy, ne?
Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?
Asi nerozumíš více věcem, ale to je normální.
Asi nerozumíš více věcem, ale to je normální.Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.Však to v Pythonu odchytí testy, ne?
Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?
Asi nerozumíš více věcem, ale to je normální.Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.Však to v Pythonu odchytí testy, ne?
Mohl bys mi prosím odpovědět na položenou otázku?CitaceProč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?
Pokud neznáš odpověď, tak samozřejmě nemusíš a ani se nemusíš zbytečně vykrucovat.
Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!
Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!Třeba proto, že než programátor dostane mail, aktualizuje aplikaci apod., request už dávno vyexpiroval a provozovatel přišel o kšeft. Ale asi žijeme každý v jiném světě a Ty s Kitem si pozastavíte realitu, opravíte aplikaci a ona pojede dál, kde skončila a to zcela bez následku.
Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!
Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!Protože pád aplikace je furt ještě lepší výsledek než poškození dat. Chyba programátora může být prkotina (argument navíc), ale také může být zásadní. A to nejde rozhodnout.
Proto je obecně lepší všechny tyhle scénáře nechat vychytat už dlouho před tím, než se kód vůbec dostane na produkci (dost na tom, že i tak nejdou udělat všechny).
Jde to rozhodnout. Už v zadání bylo řečeno, že jde o nedůležitou funkci. Takže příslušnou operace můžeš nechat v klidu selhat, selhání zaznamenat a program může pokračovat dál.Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!
Protože pád aplikace je furt ještě lepší výsledek než poškození dat. Chyba programátora může být prkotina (argument navíc), ale také může být zásadní. A to nejde rozhodnout.
Proto je obecně lepší všechny tyhle scénáře nechat vychytat už dlouho před tím, než se kód vůbec dostane na produkci (dost na tom, že i tak nejdou udělat všechny).
selhání nedůležié funkce je pro mě třeba selhání zobrazení notifikace na desktopu (tj. IO operace mimo kontrolu programátora), volání funkce s nesprávným počtem argumentů je docela hrozivá logická chybaJde to rozhodnout. Už v zadání bylo řečeno, že jde o nedůležitou funkci. Takže příslušnou operace můžeš nechat v klidu selhat, selhání zaznamenat a program může pokračovat dál.Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!
Protože pád aplikace je furt ještě lepší výsledek než poškození dat. Chyba programátora může být prkotina (argument navíc), ale také může být zásadní. A to nejde rozhodnout.
Proto je obecně lepší všechny tyhle scénáře nechat vychytat už dlouho před tím, než se kód vůbec dostane na produkci (dost na tom, že i tak nejdou udělat všechny).
Aha, takže když uživatel místo int vloží text, tak necháš aplikaci slítnout? Hmm, to asi bude hodně stabilní.
Linter může kotrolovat jenom to, čemu rozumí. Makro si můžu napsat vlastní a mám to i s tou kontrolou, nejde jenom o standardní knihovnu. Mimochodem právě na Pylintu je vidět, jak se vyplatí psát všechno "hloupě" jako ve statických jazycích, jinak přestane chápat, co se kam může posílat a kde se bere jaká hodnota a už nám s kontrolou nepomůže.
Linter může kotrolovat jenom to, čemu rozumí. Makro si můžu napsat vlastní a mám to i s tou kontrolou, nejde jenom o standardní knihovnu. Mimochodem právě na Pylintu je vidět, jak se vyplatí psát všechno "hloupě" jako ve statických jazycích, jinak přestane chápat, co se kam může posílat a kde se bere jaká hodnota a už nám s kontrolou nepomůže.
kolik jsi takových maker validujících mikrojazyk napsal? Podle mě to není častý problém a lépe ho vyřeší plugin do linteru.
Aha, takže když uživatel místo int vloží text, tak necháš aplikaci slítnout? Hmm, to asi bude hodně stabilní.Kite, Kite. Bavime se o chybach, ktere zpusobil programator, v tomto pripade dokonce o chybe, ktera by se dala odchytit pri prekladu, kdyby dany jazyk rozumne podporoval makra. Pokud nekdo nema validaci vstupu a necha probublat z formulare nenumericky vstup tam, kde je pozadovano cislo, ma mnohem vetsi problem, nez ze mu to shodilo aplikaci.
A ano, mas pravdu, ze v dnesnich interaktivnich systemech fakt runtime chyba obycejne nevede k ukonceni cele aplikace. Jenze problem, o kterem jsem puvodne psal, je v tom, ze (zase se opakuju) dnesni jazyky uz umeji nektere tridy chyb proste eliminovat. Ty ostatni se budto prizpusobi nebo budou v nekterych oblastech po pravu vytlaceny.
Jak víš, že tu chybu způsobil programátor, když se objektové aplikace sestavují až za běhu? Úplně stejná situace nastane, pokud uživatel otevře třeba XML s jinou strukturou. To při překladu neodchytíš. Validaci vstupu dělám až v objektu, který ten vstup má za úkol zpracovat, protože každý objekt si musí umět uhlídat vstupy. Jak bys chtěl při překladu odchytit chybu, když omylem při volání metody přehodíš dva parametry stejného typu?
...logicke chyby typovy system resit neumi.je to docela dobrý nástroj k jejich prevenci, už prostý newtype (typedef struct v Cčku :D) dost pomůže nebo takové "units of measure" v F#
Plugin do linteru ten problem samozrejme nevyresi lepe, je to reseni ad hoc a je to reseni z principu mene spolehlive, nez first-class podpora ve standardnich nastrojich jazyka.
Plugin do linteru ten problem samozrejme nevyresi lepe, je to reseni ad hoc a je to reseni z principu mene spolehlive, nez first-class podpora ve standardnich nastrojich jazyka.
Je to univerzálnější. Statická kontrola v případech s konstantním formátovacím řetězcem funguje stejně jako v Rustu. Narozdíl od Rustu funguje i kontrola v čase běhu.
Jak víš, že tu chybu způsobil programátor, když se objektové aplikace sestavují až za běhu? Úplně stejná situace nastane, pokud uživatel otevře třeba XML s jinou strukturou. To při překladu neodchytíš. Validaci vstupu dělám až v objektu, který ten vstup má za úkol zpracovat, protože každý objekt si musí umět uhlídat vstupy. Jak bys chtěl při překladu odchytit chybu, když omylem při volání metody přehodíš dva parametry stejného typu?Tezko bych hledal lepsi argument proti pouzivani OOP, dekuju. Co se tyce dvou parametru stejneho typu, krome specifickych pripadu (treba min a max) je mozne prohozeni dvou parametru vyresit prave tim, ze se bude pracovat s presnejsimi typy (enum namisto ciselnych konstant atd.). A jasne, logicke chyby typovy system resit neumi.
Na rozdil od Pythonu Rust zadnou podobnou kontrolu v case behu nepotrebuje. A asi rozumime slovu "univerzalni" kazdy jinak, kdyz musis pro kazdou podobnou vec psat novy plugin do linteru.
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Objektový přístup spočívá v tom, že data kontroluješ co možná nejpozději.
Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou. Viz C, ktere lehce umozni prekladat padajic programy a naopak jsou ty typy zdrojem mnohych chyb. Pak tu jsou jazyky s pokrocilejsim typovym systemem. Pokrocilejsi = slozitejsi. Tyto sice umozni eliminovat nektere chyby typické pro C, ale a) ty se v dynamickem jazyce nevyskytuji b) je tu kardinalni otazka, kdo odladi chyby v pouziti typoveho systemu? A na to mame univerzalni odpoved, testy. Staticke typy vec zbytecne komplikuji a ve vysledku nic neresi. S vyjimkou vykonu.Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou. Viz C, ktere lehce umozni prekladat padajic programy a naopak jsou ty typy zdrojem mnohych chyb. Pak tu jsou jazyky s pokrocilejsim typovym systemem. Pokrocilejsi = slozitejsi. Tyto sice umozni eliminovat nektere chyby typické pro C, ale a) ty se v dynamickem jazyce nevyskytuji b) je tu kardinalni otazka, kdo odladi chyby v pouziti typoveho systemu? A na to mame univerzalni odpoved, testy. Staticke typy vec zbytecne komplikuji a ve vysledku nic neresi. S vyjimkou vykonu.Tak to určitě.
Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
To je spis dynamicky pristup a nerekl bych co nejpozdeji, ale na nejvhodnsim miste. Je to vice flexibilni, ale prave toho se nejvíc boji ti, co s tim neumi pracovat.Objektový přístup spočívá v tom, že data kontroluješ co možná nejpozději.Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
A proc je to blbost na entou? Protoze je to straw man.
To neni straw man, to je reakce na tvrzeni, kdyz se to podari zkompilovat, je to v podstate hotovo.A proc je to blbost na entou? Protoze je to straw man.Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
To neni straw man, to je reakce na tvrzeni, kdyz se to podari zkompilovat, je to v podstate hotovo.A proc je to blbost na entou? Protoze je to straw man.Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
To neni blbost, je to jazyk se statickymi typy. Kdyz je rec obecne o statickych typech a jejich vlastnostech, musis vzit v potaz i tento jazyk. Mozna ze potom i pochopis, ze vlastnosti, ktere prisuzujes statickym typum, nejsou ve skutecnosti vlastnosti statickych typu.A proc je to blbost na entou? Protoze je to straw man.Blbost na ntou je predevsim porad dokola operovat Ceckem. S Operatorem nema smysl diskutovat, vykasli se na to.
Ano, souvislost je evidentní, protože to bylo tvrzení ke statickým typům. A žádný z obhájců statických typů to ani nezpochybnil, takže se dá předpokládat, že to je názor přijímaný většinou.Což je souvislost vysloveně evidentní. A výraz "v podstatě" jsi taky úmyslně vynechal.To neni straw man, to je reakce na tvrzeni, kdyz se to podari zkompilovat, je to v podstate hotovo.A proc je to blbost na entou? Protoze je to straw man.Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Vskutku, tvé příspěvky nejsou v ničem přínosné.
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)Ano, souvislost je evidentní, protože to bylo tvrzení ke statickým typům. A žádný z obhájců statických typů to ani nezpochybnil, takže se dá předpokládat, že to je názor přijímaný většinou.Což je souvislost vysloveně evidentní. A výraz "v podstatě" jsi taky úmyslně vynechal.To neni straw man, to je reakce na tvrzeni, kdyz se to podari zkompilovat, je to v podstate hotovo.A proc je to blbost na entou? Protoze je to straw man.Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Vskutku, tvé příspěvky nejsou v ničem přínosné.
Je to pouzitelne. Pouzivam to bezne pri vyvoji webu. Main aplikace porovnava cas py a pyc souboru a kdyz je py novejsi, tak modul, typicky nejaky handler requestu, automaticky reloadne. Nemusim kvuli tomu restartovat celou aplikaci.OK Miro. si omluven.Ale melo by to jit.Ne, nejde to, smiř se s tím, mýlíš se.
(sorry, tohle téma už mě nebaví, omlouvám se z něj)
Pro ostatni: https://docs.python.org/3/library/importlib.html#importlib.reload (https://docs.python.org/3/library/importlib.html#importlib.reload)
Je tu nejakej pythonak, kterej by rekl, jestli je to pouzitelne?
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)Tak tak. Těšil jsem se na debaty o polymorfismu a zapouzdřování, které by mohly vyústit v debaty o OO návrhu. Tešil jsem se jak tady budou lítat pojmy jako factory design pattern, dependency injection. Těšil jsem se na poučky o SRP a vůbec o celém SOLID. A místo toho se tu řeší datové typy. :(
No a to je prave ten problem. Staticky typ je staticky typ v kazdem z techto jazyku. A pokud to neni upresneno, nelze ignorovat mainstramove jazyky se statickymi typy, tedy C, C++, Java a C#. Pokud tvrzeni neplati pro tyto jazyky, neni to tvrzeni platne pro staticke typy jako takove. A pokud to nekdo upresni, ze to plati pro statickevtypy v haskellu, tak fajn, ale je tonpak vlastnost haskellu a jeho typoveho systemu, nikoliv statickych typu. Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)Ano, souvislost je evidentní, protože to bylo tvrzení ke statickým typům. A žádný z obhájců statických typů to ani nezpochybnil, takže se dá předpokládat, že to je názor přijímaný většinou.Což je souvislost vysloveně evidentní. A výraz "v podstatě" jsi taky úmyslně vynechal.To neni straw man, to je reakce na tvrzeni, kdyz se to podari zkompilovat, je to v podstate hotovo.A proc je to blbost na entou? Protoze je to straw man.Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.
Vskutku, tvé příspěvky nejsou v ničem přínosné.
v tématu, které začíná slovy "Je potreba to (OOP) vsade pretlacat?"?již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)Tak tak. Těšil jsem se na debaty o polymorfismu a zapouzdřování, které by mohly vyústit v debaty o OO návrhu. Tešil jsem se jak tady budou lítat pojmy jako factory design pattern, dependency injection. Těšil jsem se na poučky o SRP a vůbec o celém SOLID.
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)No a to je prave ten problem. Staticky typ je staticky typ v kazdem z techto jazyku. A pokud to neni upresneno, nelze ignorovat mainstramove jazyky se statickymi typy, tedy C, C++, Java a C#.
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)Tak tak. Těšil jsem se na debaty o polymorfismu a zapouzdřování, které by mohly vyústit v debaty o OO návrhu. Tešil jsem se jak tady budou lítat pojmy jako factory design pattern, dependency injection. Těšil jsem se na poučky o SRP a vůbec o celém SOLID. A místo toho se tu řeší datové typy. :(
Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.
... největší rozdíl vidím v dokumentaci.Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Ne. Problém je v tom, že C a Pascal z pohledu typů dneska už nikoho nezajímají. Takže snaha používat to jako argument je buď snaha o matení, nebo neznalost. Vyber si.již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)No a to je prave ten problem. Staticky typ je staticky typ v kazdem z techto jazyku. A pokud to neni upresneno, nelze ignorovat mainstramove jazyky se statickymi typy, tedy C, C++, Java a C#.
Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.IMHO ne
již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)Tak tak. Těšil jsem se na debaty o polymorfismu a zapouzdřování, které by mohly vyústit v debaty o OO návrhu. Tešil jsem se jak tady budou lítat pojmy jako factory design pattern, dependency injection. Těšil jsem se na poučky o SRP a vůbec o celém SOLID. A místo toho se tu řeší datové typy. :(
Celé tohle vlákno mi připomnělo vyprávění mého učitele angličtiny (rodilý mluvčí s pedagogickým vzděláním), jak se s ním jeden jeho žák (taky programátor) hádal o gramatice. Učitel vůbec nechápal a řečnicky se mě tázal, kde ten člověk bere to sebevědomí. Tak jsem jen pokrčil rameny a řekl: "programmer" :D Obor, kdy si člověk tak 5x až 20x za kariéru řekne: "Před tím jsem nevěděl nic, ale teď už jsem konečně programátor."v tématu, které začíná slovy "Je potreba to (OOP) vsade pretlacat?"?již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)Tak tak. Těšil jsem se na debaty o polymorfismu a zapouzdřování, které by mohly vyústit v debaty o OO návrhu. Tešil jsem se jak tady budou lítat pojmy jako factory design pattern, dependency injection. Těšil jsem se na poučky o SRP a vůbec o celém SOLID.
Pascal uz asi nikoho nezajima, proto ho ani neuvadim. Jazyk C je ale siroce pouzivany, nenahraditelny a nenahrazeny. Programatori, kteri ho pouzivaji, se o jeho statickemu typovemu systemu nevyhnou. Neni to ani mateni, ani neznalost, ne z me strany.již před válkou jsem poukazoval na to, že část lidí tu debatuje o pascalu (nebo i C ...) a část o teorii typů (haskell apod.)No a to je prave ten problem. Staticky typ je staticky typ v kazdem z techto jazyku. A pokud to neni upresneno, nelze ignorovat mainstramove jazyky se statickymi typy, tedy C, C++, Java a C#.
Ne. Problém je v tom, že C a Pascal z pohledu typů dneska už nikoho nezajímají. Takže snaha používat to jako argument je buď snaha o matení, nebo neznalost. Vyber si.
Imho jo, vcetne typove kontroly pred spustenim.Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.IMHO ne
typová kontrola před spuštěním je statická typová kontrolaImho jo, vcetne typove kontroly pred spustenim.Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.IMHO ne
Tak se toho drz.Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.Myslím si, že pokud člověk tématu nerozumí, měl by k příspěvkům přistupovat velmi, velmi opatrně.
Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.... největší rozdíl vidím v dokumentaci.Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
To nerozporuji, ale nepotrebuji k ni staticke typy.typová kontrola před spuštěním je statická typová kontrolaImho jo, vcetne typove kontroly pred spustenim.Myslim ze jsem tu presvedcive dokazal, ze vetsinu veci, prisuzovanych statickym typum, lze dosahnout i jinak, bez statatickych typu.IMHO ne
řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.... největší rozdíl vidím v dokumentaci.Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.
Dependency injection znamena 'posli mi objekt jako parametr, at si ho nemusim vytvaret sam'.
to mi vůbec nedává smysl, asi radší půjdu programovattypová kontrola před spuštěním je statická typová kontrolaTo nerozporuji, ale nepotrebuji k ni staticke typy.
A hlavne, i kdyz pada, tak jen na semanticke chyby, a ty BoneFlute obecne nepocita :-).Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.... největší rozdíl vidím v dokumentaci.Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.
BoneFlute nám zatím nevysvětlil, co mu v dynamicky typovaných jazycích neustále padá. Zřejmě dělá dobře, že se drží staticky typovaných jazyků.
Popravde benefit pouzivani principu SOLID jsem nikdy moc nepochopi, treba mi to nekdo vysvetli na prikladu. Stejne tak jsem nikdy neprisel na to, proc navrhovat aplikace timto komplexnim zpusobem co pouziva milion hierarchii a rozhrani. Podle me je takovych systemu poskrovnu, napr. operacni system nebo GUI.
Jak se říká, Easy to Learn, Hard to Master. Začátky s pythonem a js jsou snazší, ale plné porozumění, zvláště u poměrně komplexního pythonu, je rozhodně náročné.řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.... největší rozdíl vidím v dokumentaci.Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?
řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?Záleží náročnější na co.
Statickou typovou kontrolu lze provest i nad dynamickymi typy. Python umoznuje provest takovou kontrolu a presto je to porad dynamicky jazyk. A priklad jsem zde uvedl.to mi vůbec nedává smysl, asi radší půjdu programovattypová kontrola před spuštěním je statická typová kontrolaTo nerozporuji, ale nepotrebuji k ni staticke typy.
Napr. zapouzdreni je vlastnost modulovyho systemu. Ktery si lidi casto pletou s objektovym. Nebo je to treba taky totez.Imho znepřístupňovat vlastnosti a funkcionalitu má smysl na úrovni modulů i na úrovni tříd. Jsem zvyklý při zapouzdřování myslet hlavně na to znepřístupňování na úrovni tříd, ale musí se s tím velmi opatrně. Špatně se to pak jednotkově testuje (což se dá většinou obejít), ale hlavně to často není potřeba, pokud se dodržuje SRP.
Polymorfismus je zalezitost typovyho systemu. V dynamickym jazyku me tohle netrapi, ve statickym musim mit po ruce interfacy nebo abstraktni tridy.V dynamickém jazyku mě právě trápí, že ten interface kolegové často použít nemusí a tím se zhoršuje orientace v kódu.
OO navrh je staticky pohled na relace mezi objekty. Taky znamo jako ER diagram.Dostal jsi mě. Ale víš co jsem myslel.
Design patterny tohohle typu jsou take znamy jako 'chybejici vlastnost jazyka'. Tj. napr. namisto factory patternu muzu pouzit proste obycejnou funkci.Asi úplně nerozumím argumentu. Místo factory patternu můžu použít i obyčejnou funkci. Můžu i nalinkovat funkčnost zkompilovanou z assembleru. Jsem programátor. Můžu cokoliv. :)
Viz http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures
Dependency injection znamena 'posli mi objekt jako parametr, at si ho nemusim vytvaret sam'.Tak hlavně by mělo platit, že ho nemůžu vytvářet sám. Protože v různých situacích chci různé implementace toho samého rozhraní. Tam kde ten objekt potřebuji, tak tam se nechci starat o to, jaká ta implementace to bude. Např. mock při jednotkovém testování. Nebo implementace pro konkrétní databázi, jako je to např v PDO v PHP.
Popravde benefit pouzivani principu SOLID jsem nikdy moc nepochopi, treba mi to nekdo vysvetli na prikladu. Stejne tak jsem nikdy neprisel na to, proc navrhovat aplikace timto komplexnim zpusobem co pouziva milion hierarchii a rozhrani. Podle me je takovych systemu poskrovnu, napr. operacni system nebo GUI.SOLID je celá sada doporučení a težko se udělá příklad do jednoho komentáře. Ale benefity jsou např: Snadná znovupoužitelnost již naprogramovaného. Dobře testovatelné jednotkovými testy. Minimalizace stavů, kdy opravou jedné funkcionality rozbiji jinou.
vybavuju si jenom příklad s typovýma anotacemaStatickou typovou kontrolu lze provest i nad dynamickymi typy. Python umoznuje provest takovou kontrolu a presto je to porad dynamicky jazyk. A priklad jsem zde uvedl.to mi vůbec nedává smysl, asi radší půjdu programovattypová kontrola před spuštěním je statická typová kontrolaTo nerozporuji, ale nepotrebuji k ni staticke typy.
Však to je ono.vybavuju si jenom příklad s typovýma anotacemaStatickou typovou kontrolu lze provest i nad dynamickymi typy. Python umoznuje provest takovou kontrolu a presto je to porad dynamicky jazyk. A priklad jsem zde uvedl.to mi vůbec nedává smysl, asi radší půjdu programovattypová kontrola před spuštěním je statická typová kontrolaTo nerozporuji, ale nepotrebuji k ni staticke typy.
řekl byste tedy, že programování v dynamických jazycích (python, js) je náročnější než ve statických (haskell, pascal)?Záleží náročnější na co.
Dynamické jazyky mají snadnej rozjezd. Nic tě nebrzdí. Nemusíš nic umět. Píšeš rychle, a aplikace utěšeně narůstá. IMHO s velikostí aplikace se to má tendenci bortit. Protože ti taky nic moc nepomáhá.
Co se týče statických jazyků, tak Pascal bych sem netahal. U Haskellu je to tak, že tě furt ten kompilátor komanduje. Což může být flustrující. Je těžší rozjezd, protože člověk se musí naučit pár těch záležitostí kolem typů. Ale když už ten kompilátor ukecáš, tak to většinou dost drží. Někdo porovnával na nějaké aplikaci Clojure a Haskell. A říkal, že je to cca stejný. Akorád v tom Haskellu je to pak tak nějak jakože do betonu zalité.
Dobré ohlasy má Rust, který by měl být poněkud netradičnější, ale se silnými typy. Žel zatím jsem neměl tak velkou možnost se mu věnovat.
Je zajímavé, že u většiny dynamických jazyků se dříve či později objeví tendence přidat tomu statickou typovou kontrolu (Javascript, Python). Proč asi.
A hlavne, i kdyz pada, tak jen na semanticke chyby
Ze to vyplazne semanticky spatnej vysledek mam asi podobnlu duveru jako kdyz to napisu v pythonu.Nikdy jsem netvrdil opak.
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resitVětšinou jsem se bez cyklické struktury obešel.
data Node = Node {pk: Int, val: String, links: [Node]}
(Node 42 "text") == (Node 42 "text")
protože na pointery se nehraje.
tak to je rozpor - anotace / "nepotrebuji k ni staticke typy"Však to je ono.vybavuju si jenom příklad s typovýma anotacemaStatickou typovou kontrolu lze provest i nad dynamickymi typy. Python umoznuje provest takovou kontrolu a presto je to porad dynamicky jazyk. A priklad jsem zde uvedl.to mi vůbec nedává smysl, asi radší půjdu programovattypová kontrola před spuštěním je statická typová kontrolaTo nerozporuji, ale nepotrebuji k ni staticke typy.
Logicke chyby povazuji za podmnozinu semantickych, a jak to pada po prelozeni se syntaktickymi, to bych chtel videt.A hlavne, i kdyz pada, tak jen na semanticke chybyNikoliv. Padá to na syntaktické či logické chyby. Jako třeba na to, že do metody očekávající dict {street: "", city:""} pošlu: {name: "", surname:"", address: {street: "", city:""}}.
Tak to považuješ chybně.Logicke chyby povazuji za podmnozinu semantickychA hlavne, i kdyz pada, tak jen na semanticke chybyNikoliv. Padá to na syntaktické či logické chyby. Jako třeba na to, že do metody očekávající dict {street: "", city:""} pošlu: {name: "", surname:"", address: {street: "", city:""}}.
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
A hlavne, i kdyz pada, tak jen na semanticke chyby, a ty BoneFlute obecne nepocita :-).Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.... největší rozdíl vidím v dokumentaci.Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.
BoneFlute nám zatím nevysvětlil, co mu v dynamicky typovaných jazycích neustále padá. Zřejmě dělá dobře, že se drží staticky typovaných jazyků.
Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.
Mohl by si sem hodit nějaký scénář, kdy se cyklická datová struktura hodí? Pro představu.V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.To je pořád dokola tvůj strawman.
Mohl by si sem hodit nějaký scénář, kdy se cyklická datová struktura hodí? Pro představu.V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.To je pořád dokola tvůj strawman.
Takže pokud aplikaci se statickými typy přeložíš, dáš ho s klidným svědomím bez vyzkoušení ihned na produkci?
já se s nima potkávám u AST (tam právě zkouším alga a jinde zase "závislostní vektor" - k vynucení konzistence) a interpretrech (knot tying, vážně velká sranda, vemu seznam instrukcí a složím je do jedné IO akce, v místě skoku na jiné místo programu uvážu uzlík)Mohl by si sem hodit nějaký scénář, kdy se cyklická datová struktura hodí? Pro představu.V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
Paráda. Tákže:Napr. zapouzdreni je vlastnost modulovyho systemu. Ktery si lidi casto pletou s objektovym. Nebo je to treba taky totez.Imho znepřístupňovat vlastnosti a funkcionalitu má smysl na úrovni modulů i na úrovni tříd. Jsem zvyklý při zapouzdřování myslet hlavně na to znepřístupňování na úrovni tříd, ale musí se s tím velmi opatrně. Špatně se to pak jednotkově testuje (což se dá většinou obejít), ale hlavně to často není potřeba, pokud se dodržuje SRP.Polymorfismus je zalezitost typovyho systemu. V dynamickym jazyku me tohle netrapi, ve statickym musim mit po ruce interfacy nebo abstraktni tridy.V dynamickém jazyku mě právě trápí, že ten interface kolegové často použít nemusí a tím se zhoršuje orientace v kódu.OO navrh je staticky pohled na relace mezi objekty. Taky znamo jako ER diagram.Dostal jsi mě. Ale víš co jsem myslel.Design patterny tohohle typu jsou take znamy jako 'chybejici vlastnost jazyka'. Tj. napr. namisto factory patternu muzu pouzit proste obycejnou funkci.Asi úplně nerozumím argumentu. Místo factory patternu můžu použít i obyčejnou funkci. Můžu i nalinkovat funkčnost zkompilovanou z assembleru. Jsem programátor. Můžu cokoliv. :)
Viz http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeaturesDependency injection znamena 'posli mi objekt jako parametr, at si ho nemusim vytvaret sam'.Tak hlavně by mělo platit, že ho nemůžu vytvářet sám. Protože v různých situacích chci různé implementace toho samého rozhraní. Tam kde ten objekt potřebuji, tak tam se nechci starat o to, jaká ta implementace to bude. Např. mock při jednotkovém testování. Nebo implementace pro konkrétní databázi, jako je to např v PDO v PHP.Popravde benefit pouzivani principu SOLID jsem nikdy moc nepochopi, treba mi to nekdo vysvetli na prikladu. Stejne tak jsem nikdy neprisel na to, proc navrhovat aplikace timto komplexnim zpusobem co pouziva milion hierarchii a rozhrani. Podle me je takovych systemu poskrovnu, napr. operacni system nebo GUI.SOLID je celá sada doporučení a težko se udělá příklad do jednoho komentáře. Ale benefity jsou např: Snadná znovupoužitelnost již naprogramovaného. Dobře testovatelné jednotkovými testy. Minimalizace stavů, kdy opravou jedné funkcionality rozbiji jinou.
Ale samozřejmě OOP může být dobrý sluha ale velmi zlý pán.
V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
já se s nima potkávám u AST (tam právě zkouším alga a jinde zase "závislostní vektor" - k vynucení konzistence) a interpretrech (knot tying, vážně velká sranda, vemu seznam instrukcí a složím je do jedné IO akce, v místě skoku na jiné místo programu uvážu uzlík)
a jo vlastně, to T v AST znamená strom :Djá se s nima potkávám u AST (tam právě zkouším alga a jinde zase "závislostní vektor" - k vynucení konzistence) a interpretrech (knot tying, vážně velká sranda, vemu seznam instrukcí a složím je do jedné IO akce, v místě skoku na jiné místo programu uvážu uzlík)
Mohl by si se více rozepsat. Shodou okolností jsem zrovna nějaké to ASTčko nedávno dělal. A na žádný cyklický graf jsem nenarazil. Vždy jsem si vystačil se stromem. Buď jsem tak šikovnej (nepravděpodobné), nebo jsem se jen náhodou vyhnul nějakému scénáři... Předem dík.
paper není nezbytný k využití knihovny, tak jsem ho radši nečet, ale ten základní trik je vidět z deklarace typu:V rustu je peklo napsat jakoukoliv cyklickou datovou strukturu. Graf, strom s pointrem na rodice, apod. V haskellu se mi to ani nildy nepovedlo, protoze je z principu imutabilni. Urcite existuje nejaly magicky trik jak tyhle problemy v haskellu resit, ale nemam na ne cas, protoze chci resit problemy a ne hadanky jak to udelat.tohle je zajímavé téma! znám asi tři přístupy, reference v IO/ST atd, knot tying (velká sranda!) a u grafů to zajímavě řeší algebraické grafy (http://hackage.haskell.org/package/algebraic-graphs)
Diky za odkaz. Vic podobnych linku by sem mohli lidi hodit.
Projel jsem slidy toho jak funguje tahle algebraicka reprezentace grafu. Musel bych ale videt metodu jak reprezentovat libovolny netrivialni graf timhle zpusobem. Pak bych potreboval videt jak se nad tim delaji klasicky algoritmy, alespon pruchody grafem. Napada me z toho vygenerovat klasickou adjacency matici a pak s tim pracovat zase klasicky.
data Graph a = Empty
| Vertex a
| Overlay (Graph a) (Graph a)
| Connect (Graph a) (Graph a)
Je to pouzitelne. Pouzivam to bezne pri vyvoji webu. Main aplikace porovnava cas py a pyc souboru a kdyz je py novejsi, tak modul, typicky nejaky handler requestu, automaticky reloadne. Nemusim kvuli tomu restartovat celou aplikaci.No jistě, funguje ti to proto, že handler requestu je "fire and forget". Pokud by to byl modul, který pořád běží (někdo někde, nikdo neví kde všude ho přímo nebo nepřímo používá), tak by ti to nefungovalo.
Nejsem si jist, ale doufal jsem, ze to reknes. Vyplyva z toho, ze zijes v domeni, ze kompiler ti diky statickym typum odchyti logicke chyby. Protoze jak jsi uvedl, po uspesne kompilaci je obecne vse hotovo, zbyvaji jen semanticke chyby.Tak to považuješ chybně.Logicke chyby povazuji za podmnozinu semantickychA hlavne, i kdyz pada, tak jen na semanticke chybyNikoliv. Padá to na syntaktické či logické chyby. Jako třeba na to, že do metody očekávající dict {street: "", city:""} pošlu: {name: "", surname:"", address: {street: "", city:""}}.
Neni, je to reakce na tvrzeni, ktere tu zaznelo.To je pořád dokola tvůj strawman.A hlavne, i kdyz pada, tak jen na semanticke chyby, a ty BoneFlute obecne nepocita :-).Ja vedel ze to najdu, zajimalo me, kdo s touto vtipnou tezi prisel. A citoval jsem spatne, nebylo to v podstate, ale obecne.... největší rozdíl vidím v dokumentaci.Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.
Tam patřilo spíš "Zatímco u dynamického jazyka mi furt něco padá." Už jsem psal, že dynamické typování není pro každého. Je nutné si nejen držet určitou kázeň, ale i pokrýt jednotku testy.
BoneFlute nám zatím nevysvětlil, co mu v dynamicky typovaných jazycích neustále padá. Zřejmě dělá dobře, že se drží staticky typovaných jazyků.
Tudiz tvrdim, ze je tu sorta lidi verici ve staticke typy a to, ze kdyz se jim podari prelozit kod se statickymi typy, maji obecne hotovo.
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladechModul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
zvláště u poměrně komplexního pythonuCo je na Pythonu komplexního?
Moduly a objekty mi pripadaji jako totez.Jako totéž to může připadat právě kvůli tomu zparchantělému OOP, co se rozšířilo jako mor a které považuje za normální lézt do jednoho objektu z víc vláken, takže pojem objektu jako entity, která něco dělá, začíná ztrácet smysl.
Alespon v erlangu je objekt nejaka isolovana vypocetni jednotka (actor, agent, proces, vlakno, apod.) a ne pouze obycejny dict v prestrojeni.Právě proto, že v Erlangu[1] je to přesně naopak, než píšeš, je Erlang původní myšlence OOP paradoxně blíž než ty slavné "OOP jazyky".
Právě proto, že v Erlangu[1] je to přesně naopak, než píšešJo, teď mi došlo, že tady už jsi možná nemluvil o modulech, z kontextu to není poznat. Pokud ne, tak sry, pak to citovaný beru zpět :)
Jako totéž to může připadat právě kvůli tomu zparchantělému OOP, co se rozšířilo jako mor a které považuje za normální lézt do jednoho objektu z víc vláken, takže pojem objektu jako entity, která něco dělá, začíná ztrácet smysl.Ten objekt se s tim musi nejak popasovat. Kdyz kuchar vari pizzu a zadas mu jeste varit omacku, tak bud na to ma kapacity a dela 2 veci soucasne (na dnesnich PC proc ne), nebo muze vratit nejake ERROR_BUSY pripadne 2. zadost zaradi do fronty a vyzvedne ji az po vyrizeni 1. zadosti.
Pro zjednodušení si stačí představit, že každý objekt má vlastní vlákno. Když objektu Kuchař pošlu zprávu [vař: pizzu], tak vaří pizzu a těžko může zároveň vařit omáčku. ...
Ten objekt se s tim musi nejak popasovat. Kdyz kuchar vari pizzu a zadas mu jeste varit omacku, tak bud na to ma kapacity a dela 2 veci soucasne (na dnesnich PC proc ne), nebo muze vratit nejake ERROR_BUSY pripadne 2. zadost zaradi do fronty a vyzvedne ji az po vyrizeni 1. zadosti.Přesně tak! Ale má to fungovat tak, že já kuchaře o něco požádám a on to buď umí, nebo neumí atd. A ne že se já (vlákno) stanu kuchařem a uvařím si to sám, přičemž kuchařská kniha je napsaná tak, aby dva lidi (vlákna) mohli vařit zaráz, i když o sobě navzájem vůbec nic neví (sdílí jenom zámek).
To, ze o sobe nevedi, je problem kuchare. Kdyz je to schopny nejak zaridit, ze vsechno funguje, nevidim problem. Mame jen omezeny pocet jader (CPU), tak se jadra prevlekaji, chvili hraji cisnika, chvili kuchare.Ten objekt se s tim musi nejak popasovat. Kdyz kuchar vari pizzu a zadas mu jeste varit omacku, tak bud na to ma kapacity a dela 2 veci soucasne (na dnesnich PC proc ne), nebo muze vratit nejake ERROR_BUSY pripadne 2. zadost zaradi do fronty a vyzvedne ji az po vyrizeni 1. zadosti.Přesně tak! Ale má to fungovat tak, že já kuchaře o něco požádám a on to buď umí, nebo neumí atd. A ne že se já (vlákno) stanu kuchařem a uvařím si to sám, přičemž kuchařská kniha je napsaná tak, aby dva lidi (vlákna) mohli vařit zaráz, i když o sobě navzájem vůbec nic neví (sdílí jenom zámek).
Chápej, rozdíl je právě v tom, jestli je objekt "jednotka kódu" nebo "jadnotka výpočtu" (neboli "TA entita, která vyvíjí nějakou činnost"). Ve zparchantělém OOP je "objekt" ve skutečnosti spíš modul (a proto někteří lidi moc nechápou, jakej - a vůbec proč - by měl být mezi modulem a objektem rozdíl).
To, ze o sobe nevedi, je problem kuchare. Kdyz je to schopny nejak zaridit, ze vsechno funguje, nevidim problem.Jenže ve zparchantělém OOP žádný Kuchař (jako entita která něco dělá, tj. aktor[1]), není. Je jenom KuchařskáKniha, což je takový (nepopírám) docela fikaný protokol, postavený na tom, že kolem Knihy chodí lidi (to jsou tam ti aktoři!) a přesně podle návodu cosi do knihy píšou. Každej z těch různých lidí je občas kuchařem, někdy i víc z nich zaráz atd.
Mame jen omezeny pocet jader (CPU), tak se jadra prevlekaji, chvili hraji cisnika, chvili kuchare.No tak to každopádně. Určitě budeme mít víc aktorů než jader. V tom není problém. Problém je v tom, že to probublává do programu. Pokud by se to dělo způsobem, o kterém programátor vůbec neví a neřeší to, bylo by to naprosto OK (proto jsou taky goroutiny v tomhle smyslu naprosto OK)
Pro me je objekt vlastne jen datova struktura + nejake picarny kolem. A ted do me :-)Tak jasně no, to nejsi sám. Však když ti to vyhovuje, není problém, užij si to! :) Akorát to prostě vůbec neodpovídá ani základním myšlenkám původního OOP. Je to prostě takové nové zparchantělé OOP© ;)
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladechModul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Právě proto, že v Erlangu[1] je to přesně naopak, než píšešJo, teď mi došlo, že tady už jsi možná nemluvil o modulech, z kontextu to není poznat. Pokud ne, tak sry, pak to citovaný beru zpět :)
Dik, pochopils.Zkus pls psát trochu explicitněji a přesněji. Viz "V Erlangu je objekt [...]" - v Erlangu žádný objekt není, takže těžko odhadovat, o čem mluvíš...
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladechModul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.
Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.
[dict1, dict2, dict3]
ekvivalentni
class C: pass
class B(C): pass
class A(B): pass
kde A odpovida dict1, B dict2, C dict3
Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.
Dik, pochopils.Zkus pls psát trochu explicitněji a přesněji. Viz "V Erlangu je objekt [...]" - v Erlangu žádný objekt není, takže těžko odhadovat, o čem mluvíš...
Mas pravdu, v Erlangu neni objekt. Vazu na to diskusi Co je to OOP. V Erlangu beru proces jako actor nebo taky jako 'aktivni' objekt. Neco co je bliz OOP myslence od Kaye nez objekt jako modul v tom cemu ty rikas zparchantele oop.Ok, tak to bylo nedorozumění, v tom případě to chápeš naprosto správně. Omlouvám se.
zvláště u poměrně komplexního pythonuCo je na Pythonu komplexního?
Dobré přednášky o pokročilejších vlastnostech má David Beazley.No, když tyhle "pokročilejší" věci porovnám třeba s C++, tak bych je rozhodně nenazval "komplexní" ;)
Tim ale neimplementujes dedicnost v dictu, a dedicnost pomoci seznamu dictu a kodu, ktery to osetri, pricemz seznam je zase jen nadstavba nad dictem. Jestli tim chces rict, ze dokazes pomoci dictu emulovat chovani trid, tak asi ano, ale budes k tomu potrebovat slozity kod, c3 linearizaci a bude to tezkopadne na pouzivani. A v tom spociva smysl trid, modulu atd. Je to abstrakce, ktera ti zjednodusi a zprehledni programovy kod. Pokud to nepotrebujes, muzes zkusit programovat primo ve strojovem kodu. Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladechModul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.
Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.
[dict1, dict2, dict3]
ekvivalentni
class C: pass
class B(C): pass
class A(B): pass
kde A odpovida dict1, B dict2, C dict3
Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.
Dobré přednášky o pokročilejších vlastnostech má David Beazley.No, když tyhle "pokročilejší" věci porovnám třeba s C++, tak bych je rozhodně nenazval "komplexní" ;)
(to není kritika, to je dobře)
a) pisu pomerne, kde jsi vytrhl z kontextu, že ho pomeruji k JSzvláště u poměrně komplexního pythonuCo je na Pythonu komplexního?
Tim ale neimplementujes dedicnost v dictu, a dedicnost pomoci seznamu dictu a kodu, ktery to osetri, pricemz seznam je zase jen nadstavba nad dictem. Jestli tim chces rict, ze dokazes pomoci dictu emulovat chovani trid, tak asi ano, ale budes k tomu potrebovat slozity kod, c3 linearizaci a bude to tezkopadne na pouzivani. A v tom spociva smysl trid, modulu atd. Je to abstrakce, ktera ti zjednodusi a zprehledni programovy kod. Pokud to nepotrebujes, muzes zkusit programovat primo ve strojovem kodu. Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladechModul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.
Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.
[dict1, dict2, dict3]
ekvivalentni
class C: pass
class B(C): pass
class A(B): pass
kde A odpovida dict1, B dict2, C dict3
Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.
Dict se v pythonu pouziva na implementaci objektu, a protoze vsechno je v pythonu objekt, muzeme rict, ze dict je soucasti vseho, je to zakladni datova struktura Pythonu, proto taky na vsechno funguje dir(). Ale neznamena, ze kdyz to pouziva dict, tak muzeme rikat, ze je to dict a nic jineho nepotrebujeme. Protoze s takovou muzeme jit hloub a prohlasit, ze vsechno je jen cislo, resp. organizovany seznam jednicek a nul, cimz jsme zpatky u strojoveho kodu.
Protirecis si, marketing je uspokojovani potreb zakaznika. Cim komplexnejsi veci se v JS programuji, tim vice takove abstrakce jsou potreba. Proto byly pozadovany a proto byly implementovany.Tim ale neimplementujes dedicnost v dictu, a dedicnost pomoci seznamu dictu a kodu, ktery to osetri, pricemz seznam je zase jen nadstavba nad dictem. Jestli tim chces rict, ze dokazes pomoci dictu emulovat chovani trid, tak asi ano, ale budes k tomu potrebovat slozity kod, c3 linearizaci a bude to tezkopadne na pouzivani. A v tom spociva smysl trid, modulu atd. Je to abstrakce, ktera ti zjednodusi a zprehledni programovy kod. Pokud to nepotrebujes, muzes zkusit programovat primo ve strojovem kodu. Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladechModul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.
Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.
[dict1, dict2, dict3]
ekvivalentni
class C: pass
class B(C): pass
class A(B): pass
kde A odpovida dict1, B dict2, C dict3
Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.
Dict se v pythonu pouziva na implementaci objektu, a protoze vsechno je v pythonu objekt, muzeme rict, ze dict je soucasti vseho, je to zakladni datova struktura Pythonu, proto taky na vsechno funguje dir(). Ale neznamena, ze kdyz to pouziva dict, tak muzeme rikat, ze je to dict a nic jineho nepotrebujeme. Protoze s takovou muzeme jit hloub a prohlasit, ze vsechno je jen cislo, resp. organizovany seznam jednicek a nul, cimz jsme zpatky u strojoveho kodu.
javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.
Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.Aby nedoslo k nedorozumeni. Programem tady minim programovy kod. Vzhledem k tomu, ze to zjednodusi programovani, to umoznuje ve vysledku vznik komplexnejsich programu ve smyslu aplikaci.
Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.Aby nedoslo k nedorozumeni. Programem tady minim programovy kod. Vzhledem k tomu, ze to zjednodusi programovani, to umoznuje ve vysledku vznik komplexnejsich programu ve smyslu aplikaci.
Asi bych nemluvil o urovni, ale jinak ano, presne to je cil, zjednoduseni programoveho kodu. Krome toho se take zvysi efetivita tvorby programu.Jinak řečeno pro každou úroveň abstrakce použiješ jiný syntaktický cukr. Čitelnost a přehlednost programu se tím zvýší a sníží se riziko chyb.Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.Aby nedoslo k nedorozumeni. Programem tady minim programovy kod. Vzhledem k tomu, ze to zjednodusi programovani, to umoznuje ve vysledku vznik komplexnejsich programu ve smyslu aplikaci.
Asi bych nemluvil o urovni, ale jinak ano, presne to je cil, zjednoduseni programoveho kodu. Krome toho se take zvysi efetivita tvorby programu.
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladechTohle už je na mě příliš konkrétní. Chtěl jsem se jen svěřit se zkušeností, že hodně malé "izolované výpočetní jednotky" pak mají často skoro všechno veřejné, protože jsou tak malé, že už v nich není co schovávat.
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Alespon v erlangu je objekt nejaka isolovana vypocetni jednotka (actor, agent, proces, vlakno, apod.) a ne pouze obycejny dict v prestrojeni.
Pokud je problem ze kolegove nemuzou byt svazani sveraci kazajkou jazyka, jako v pripade chybejicich rozhrani v dynamickych jazycich, pak je to organizacni problem. V dynamickym jazyce bouchne driv nez ve statickym. Co je lepsi, tezko rict. Pro me je lepsi kdyz ten bolak praskne driv nez pozdeji a zacne se resit skutecny problem - spatna organizace lidi.Tohle mi přijde tak trochu jako argument: nedávejte na školní schodiště zábradlí, ať se dříve ukáže, že máte nevychované žáky. Jako jasně že se místo interface dá napsat lepší komentář. Ale když tam musí být interface, je o problém méně.
Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.
Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.
zkuste častěji ukazovat příklady dobře napsaných OO programůTen clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.
Funkcionální programování propagují zejména programátoři, kteří nepochopili principy OOP. Vždycky mi ukážou blbě napsaný objektový program a začnou mi tvrdit, že takhle programovat nechtějí. Já také ne. Nad každým objektem je třeba se zamyslet tak, aby nebyl kuchařskou knihou nebo spíží, ale kuchařem.
Funkcionální programování však nepovažuji za špatné - je jen jiné. Dá se skvěle kombinovat s objektovým - zejména v jazycích, které podporují obojí.
zkuste častěji ukazovat příklady dobře napsaných OO programůTen clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.
Funkcionální programování propagují zejména programátoři, kteří nepochopili principy OOP. Vždycky mi ukážou blbě napsaný objektový program a začnou mi tvrdit, že takhle programovat nechtějí. Já také ne. Nad každým objektem je třeba se zamyslet tak, aby nebyl kuchařskou knihou nebo spíží, ale kuchařem.
Funkcionální programování však nepovažuji za špatné - je jen jiné. Dá se skvěle kombinovat s objektovým - zejména v jazycích, které podporují obojí.
Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.
Funkcionální programování propagují zejména programátoři, kteří nepochopili principy OOP. Vždycky mi ukážou blbě napsaný objektový program a začnou mi tvrdit, že takhle programovat nechtějí. Já také ne. Nad každým objektem je třeba se zamyslet tak, aby nebyl kuchařskou knihou nebo spíží, ale kuchařem.
Funkcionální programování však nepovažuji za špatné - je jen jiné. Dá se skvěle kombinovat s objektovým - zejména v jazycích, které podporují obojí.
Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladechTohle už je na mě příliš konkrétní. Chtěl jsem se jen svěřit se zkušeností, že hodně malé "izolované výpočetní jednotky" pak mají často skoro všechno veřejné, protože jsou tak malé, že už v nich není co schovávat.
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Alespon v erlangu je objekt nejaka isolovana vypocetni jednotka (actor, agent, proces, vlakno, apod.) a ne pouze obycejny dict v prestrojeni.Pokud je problem ze kolegove nemuzou byt svazani sveraci kazajkou jazyka, jako v pripade chybejicich rozhrani v dynamickych jazycich, pak je to organizacni problem. V dynamickym jazyce bouchne driv nez ve statickym. Co je lepsi, tezko rict. Pro me je lepsi kdyz ten bolak praskne driv nez pozdeji a zacne se resit skutecny problem - spatna organizace lidi.Tohle mi přijde tak trochu jako argument: nedávejte na školní schodiště zábradlí, ať se dříve ukáže, že máte nevychované žáky. Jako jasně že se místo interface dá napsat lepší komentář. Ale když tam musí být interface, je o problém méně.Ten clanek o design patternech obsahuje priklady. Vetsina oop patternj jsou proste ochcavka kolem toho, ze jazyk nedokaze napr. posilat funkce. Ted uz je ma i java, tak proc by nekdo vubec tyhle zastarale navrhove vzory pouzival.Tohle je takovéto: Ve funkcionálních jazycích můžeme podobná očekávání splnit jinak a napíšeme u toho méně znaků. OK. Proč ne. Ale nepřijde mi, že by funkcionální jazyky byly nějaká novinka, co se chystá spasit svět a OOP zastaralé paradigma.
Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.Modifikátory přístupu (public, protected, private) považuji za takový lepší komentář, který je mi připomínán i překladačem.
Zabradli a zaci. Pokud bychom zili v systemu, kde jsou zaci lehce nahraditelni, pak by to bylo skutecne dobre reseni. V nasem svete ale zaci nejsou lehce nahraditelni. V nasem svete ale jsou programy lehce nahraditelne. Alespon v nekterych organizacich. Zacal bych se divat na zdroj problemu zde.Zas až takový darvinista nejsem. Nahraditelnost softwaru je docela dobře vyjádřena jeho cenou.
funkcionalni vs objektove jazyky. Zmin jsem to v prispevku pred. OO jako simulace, objekty posilajici si zpravy, je vypocetni model, ne zpusob programovani. OO jako modularni programovani (java,C++) tj. vsemozne zapouzdrovani, zavislosti mezi moduly (dedicnost), mi prijde jako prekomplikovane imperativni a funkcionalni programovani v jednom. Napr. Trida neni nic jineho nez mnozina nekolika funkci.Jádro našeho "sporu" je možná právě v tom, že ty počítáš každý konstrukt, který nemusíš napsat a já naopak počítám každý konstrukt, který napsat můžu. Samozřejmě že si můžu pamatovat, že tyhle 3 funkce jsou na sobě závislé a že má smysl volat jen tu jednu, protože ty zbylé dvě té první jen pomáhají a pro nic jiného nejsou použitelné. Nebo to můžu napsat do komentáře. Nebo můžu použít prefixy v názvu. Nebo to můžu zavřít do třídy a pomocí public označit tu metodu, kterou má smysl volat. A pak k tomu může přijít i Ind, který neumí slovo anglicky a na první pokus se trefí. No a nebo můžu hrdě tvrdit, že žádnýho pologramotnýho Inda do svého masterpiece kódu nepustím a hledat na pracovním trhu jenom samé guru s 200k platem.
To s tím Javascriptem je docela dobrá paralela. Protože díky tomu, že Javascript neměl žádný zvláštní cukr na vytváření objektů, vzniklo pár zajímavejch článků na toto téma. Díky tomu (a taky proto, že jsem si to zkusil :-) ) je mi jasné, že v tom Pythonu je objekt opravdu jen převlečený slovník. S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".Tim ale neimplementujes dedicnost v dictu, a dedicnost pomoci seznamu dictu a kodu, ktery to osetri, pricemz seznam je zase jen nadstavba nad dictem. Jestli tim chces rict, ze dokazes pomoci dictu emulovat chovani trid, tak asi ano, ale budes k tomu potrebovat slozity kod, c3 linearizaci a bude to tezkopadne na pouzivani. A v tom spociva smysl trid, modulu atd. Je to abstrakce, ktera ti zjednodusi a zprehledni programovy kod. Pokud to nepotrebujes, muzes zkusit programovat primo ve strojovem kodu. Pak imho prehodnotis nazor a zjistis, ze abstraktni prvky/pojmy komplexitu programu snizuji, nikoliv zvysuji.Moduly a objekty mi pripadaji jako totez. Tj. nejaka skupina funkci (plus pripadne nejaky stav). Ze je to totez je videt na prikladechModul je reprezentace souboru. Objekt je v pythonu vsechno. Mozna mas na mysli tridy. Ty maji dedicnost, funguji jako uzivatelske datove typy a podobne vychytavky. Jak bys to implementoval jen pomoci slovniku?
1. zapouzdreni se resi u obou a stejnymi zpusoby
2. v pythonu je modul vlastne objekt. A objekt je vlastne dict. Nac tedy pouzivat moduly nebo objekty a ztracet se v komplexite kdyz muzu pouzit obycejny dict
Jo, ale misto toho, abych zavadel zbytecne koncepty trida, objekt a modul, muzu pouzit proste jen dict.
Dedicnost muzes v dictu naimplementovat jednoduse. Prolinkujes par dictu dohromady a kdyz hledas konkretni metodu/odpoved na prichazejici zpravu projedes ten seznam dictu dokud nenajdes tu funkci.
[dict1, dict2, dict3]
ekvivalentni
class C: pass
class B(C): pass
class A(B): pass
kde A odpovida dict1, B dict2, C dict3
Kdybys implementoval novej jazyk tak udelas nejpravdepodobneji prave tohle.
Dict se v pythonu pouziva na implementaci objektu, a protoze vsechno je v pythonu objekt, muzeme rict, ze dict je soucasti vseho, je to zakladni datova struktura Pythonu, proto taky na vsechno funguje dir(). Ale neznamena, ze kdyz to pouziva dict, tak muzeme rikat, ze je to dict a nic jineho nepotrebujeme. Protoze s takovou muzeme jit hloub a prohlasit, ze vsechno je jen cislo, resp. organizovany seznam jednicek a nul, cimz jsme zpatky u strojoveho kodu.
javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.
javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.
javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.
javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.
Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.Modifikátory přístupu (public, protected, private) považuji za takový lepší komentář, který je mi připomínán i překladačem.Zabradli a zaci. Pokud bychom zili v systemu, kde jsou zaci lehce nahraditelni, pak by to bylo skutecne dobre reseni. V nasem svete ale zaci nejsou lehce nahraditelni. V nasem svete ale jsou programy lehce nahraditelne. Alespon v nekterych organizacich. Zacal bych se divat na zdroj problemu zde.Zas až takový darvinista nejsem. Nahraditelnost softwaru je docela dobře vyjádřena jeho cenou.funkcionalni vs objektove jazyky. Zmin jsem to v prispevku pred. OO jako simulace, objekty posilajici si zpravy, je vypocetni model, ne zpusob programovani. OO jako modularni programovani (java,C++) tj. vsemozne zapouzdrovani, zavislosti mezi moduly (dedicnost), mi prijde jako prekomplikovane imperativni a funkcionalni programovani v jednom. Napr. Trida neni nic jineho nez mnozina nekolika funkci.Jádro našeho "sporu" je možná právě v tom, že ty počítáš každý konstrukt, který nemusíš napsat a já naopak počítám každý konstrukt, který napsat můžu. Samozřejmě že si můžu pamatovat, že tyhle 3 funkce jsou na sobě závislé a že má smysl volat jen tu jednu, protože ty zbylé dvě té první jen pomáhají a pro nic jiného nejsou použitelné. Nebo to můžu napsat do komentáře. Nebo můžu použít prefixy v názvu. Nebo to můžu zavřít do třídy a pomocí public označit tu metodu, kterou má smysl volat. A pak k tomu může přijít i Ind, který neumí slovo anglicky a na první pokus se trefí. No a nebo můžu hrdě tvrdit, že žádnýho pologramotnýho Inda do svého masterpiece kódu nepustím a hledat na pracovním trhu jenom samé guru s 200k platem.
Nejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.
Tridy = moduly. Inda nepustim do svyho kodu tak, ze mu hodim nektery funkce private v modulu kam nema sahat. Nepotrebuju k tomu N konceptu, kazdej pripominajici modul a umoznujici skryvani atributu.
To s tím Javascriptem je docela dobrá paralela. Protože díky tomu, že Javascript neměl žádný zvláštní cukr na vytváření objektů, vzniklo pár zajímavejch článků na toto téma. Díky tomu (a taky proto, že jsem si to zkusil :-) ) je mi jasné, že v tom Pythonu je objekt opravdu jen převlečený slovník.
S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".
Citace: KadetNejak nechapu tu neustalou potrebu v OO neco schovavat. Resit co bude schovane a co verejne. Ja radsi resim zadani problemu.Citace: KadetTridy = moduly. Inda nepustim do svyho kodu tak, ze mu hodim nektery funkce private v modulu kam nema sahat. Nepotrebuju k tomu N konceptu, kazdej pripominajici modul a umoznujici skryvani atributu.
Takže ta potřeba "schovávat" asi není zase tak nepochopitelná.
Jinak asi nikdo nepotřebuje N konceptů. Každému stačí ten jeden, který zrovna on používá.
Jestli skrývat kromě metod i atributy nebo nechávat atributy veřejné, do toho už se pouštět nechci. To strašně záleží na případu použití i na tom, jak to má jaký jazyk zrovna řešeno a návrh to imho nijak zvlášť neovlivňuje. Ale já to mám rád, když můžu některé atributy označit jako private, kvůli lepší čitelnosti kódu. Samozřejmě když má třída/modul desítky privátních atributů, tak v tom návrhu nejspíše něco smrdí.
Stejně nechápu, proč většina jazyků má v návrhu slovo "private". Privátní by mělo být defaultně všechno. Jen ty komponenty, které chci mít veřejné, označím "public" nebo "protected".
Mezi object a dict bývá jeden významný rozdíl: Object se předává odkazem, ale dict hodnotou. Platí to například v PHP.
Stejně nechápu, proč většina jazyků má v návrhu slovo "private". Privátní by mělo být defaultně všechno. Jen ty komponenty, které chci mít veřejné, označím "public" nebo "protected".
Mezi object a dict bývá jeden významný rozdíl: Object se předává odkazem, ale dict hodnotou. Platí to například v PHP.
Jestli nechat defaultne private nebo public je otazka jestli pracuju v prototypovacim nebo produkcnim modu.
Je vlastnosti 'zpusob predani' nejaka vnitrni vlastnost objektu nebo dictu? Jinymi slovy, dict nelze predat jako odkaz a objekt nelze predat hodnotou?
Ty jo, zaváhal jsem, ale:S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".
to v Pythonu nejde. To si asi pleteš s Javascriptem.
class A:
pass
class B (A):
def boo(self):
return 'B'
def goo(self):
return 'C'
b = B()
print(dir(b))
A.goo = goo
print(dir(b))
print b.goo
print b.goo()
Proc by to nemelo jit, objekty lze dynamicky modifikovat. Jde nejen pridat, ale i z(a)menit. Podívej se také na bound a unbound methods.To s tím Javascriptem je docela dobrá paralela. Protože díky tomu, že Javascript neměl žádný zvláštní cukr na vytváření objektů, vzniklo pár zajímavejch článků na toto téma. Díky tomu (a taky proto, že jsem si to zkusil :-) ) je mi jasné, že v tom Pythonu je objekt opravdu jen převlečený slovník.
slovník je defaultní reprezentace, ale existují __slots__, namedtuple, recordclasses, atd. Kde můžu používám knihovnu attrs, se slots=True.S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".
to v Pythonu nejde. To si asi pleteš s Javascriptem.
Ta omacka navic je zadana, takze evidentne neco zjednodusuje. Minimalne pochopeni jazyka pro nektere programatory. Imho je to vyhodne i pro jednodussi a prehlednejsi objektovy navrh programu. Prototypova dedicnost je dobra pro DOM, tedy kdyz chces pracovat s rozsahlou a bohatou kolekci uz existujicich kolekci. Ale neni dobra, kdyz podobnou strukturu nechces jen pouzivat, ale chces ji navrhnout sam.Asi bych nemluvil o urovni, ale jinak ano, presne to je cil, zjednoduseni programoveho kodu. Krome toho se take zvysi efetivita tvorby programu.Class v Javascriptu nic nezjednodušuje. Kód nezkracuje. Je to jen omáčka navíc.
javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.
Nevim jak vypada implementace require. Ale prislo mi, ze je to jen funkce. A javascript uz koncept funkce ma, takze nic nemuzel pridavat. Kdyby museli upravit jazyk kvuli necemu, co jde implementovat pouhou funkci, pak ano, bylo by to pridani nadbytecneho cukru.
Marketingove dduvody, aby to pouzivalo vic lidi, jsou dost presne vyjadreni situace. Javascript mel prototypy vychazejici ze Selfu. To je presne co tady popisuju. Prolinkovany dicty. Nic vic. Nekdo ted pridal cukr na classy. Proc? Za me je odpoved marketing.
Ja chapu potrebu schovavat. Akorat debaty o OO navrhu zacinaji tim, co schovat, zapouzdrit a zdedit, nez tim, co je vysledkem vyreseni problemu.
Kdyz jsi sam, kdo pouziva program, tak je fajn, ze si muzes vybrat tridu nebo modul nebo package nebo cokoliv k tomu ucelu. Jenze kdyz pracujes s indem, tak on si vybere jedno a ty druhy. Ja bych na to mel radsi jen jeden koncept.
V Selfu zjistili, ze je lepsi povazovat atribut stejne jako metodu. Jinak jestli se nekdo rozhoduje, jestli schovat nebo ne podle toho, co mu umoznuje jazyk, pak je otazka, jestli nema prilis svazujici jazyk.
Problem je mozna v tom, ze OOP neni programovaci paradigma, ale vypocetni model. Podobny Petriho sitim. System, kde si mnozina objektu posila zpravy, muzu naimplementovat v cemkoliv. Muzu k tomu pouzit dokonce i C++ nebo Javu, tedy jazyky s dvoji koncepci modulu, tj. modul a trida.
The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.
http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
To s tím Javascriptem je docela dobrá paralela. Protože díky tomu, že Javascript neměl žádný zvláštní cukr na vytváření objektů, vzniklo pár zajímavejch článků na toto téma. Díky tomu (a taky proto, že jsem si to zkusil :-) ) je mi jasné, že v tom Pythonu je objekt opravdu jen převlečený slovník. S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".
1 class X():
2 counter = 5
3
4 def __init__(self, x=0):
5 if self.__class__.counter < 0:
6 raise RuntimeError('Overflow maximum allowed instances.')
7 self.__id = self.__class__.counter
8 self.__class__.counter -= 1
9 self.__x = x
10
11 @property
-- 12 def x(self):
13 return self.__x
14
15 @property
-- 16 def id(self):
17 return self.__id
18
19 def __iadd__(self, val):
20 self.__x += val
21 return self
22
23 def __add__(self, val):
24 if isinstance(val, type(self)):
25 return self.__class__(val.x + self.__x)
26 raise TypeError(f"unsupported operand type(s) for +: " + \
27 f"'{type(self).__name__}' and '{type(a).__name__}'")
28
29 def __repr__(self):
30 return f'{self.__x} of type: {type(self).__name__} and id: {self.__id}'
31
-- 32 class A(X):
33 pass
34
-- 35 class B(X):
36 pass
37
38 # vytvoreni objektu 'a', 'b' a 'c' a operace s nimi
-- 39 a = A()
-- 40 b = B(7)
41
42 print(a.x) # 0
43 print(a.id) # 5
44 print(a) # 0 of type: A and id: 5
45 print(b) # 7 of type: B and id: 5
46
47 a += 10
-- 48 c = a + a
49 print(c) # 20 of type: A and id: 4
50 print(a + c) # 30 of type: A and id: 3
51
>> 52 a.id = 1 # AttributeError, zakaz zapisu do atributu
-- 53 a + b # Type error, secist lze jen objekty stejneho typu
54 a += a # Type error, pridat jde jen int hodnota
-- 55
Problem je mozna v tom, ze OOP neni programovaci paradigma, ale vypocetni model. Podobny Petriho sitim. System, kde si mnozina objektu posila zpravy, muzu naimplementovat v cemkoliv. Muzu k tomu pouzit dokonce i C++ nebo Javu, tedy jazyky s dvoji koncepci modulu, tj. modul a trida.OOP je programovaci paradigma. Je to abstrakce, ktera ti umoznuje se na program divat/uvazovat jinym zpusobem. To jestli jde nebo nejde simulovat jinymi prostredky je nepodstatne. Pokud reknes, me abstrakce nezajima, pak se muzes vratit ke strojovemu kodu, protoze vsechno ostatni je vice ci mene pokrocila abstrakce nad nim a v nem jde pouzit/udelat vsechno, akorat to bude dost neprehledne.
The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.
http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
Ty jo, zaváhal jsem, ale:S jednou výjimkou. Ta výjimka souvisí s dědičností a s dynamičností Pythonu - že můžeš už vytvořenému objektu přidat metodu tak, že přidáš metodu do jeho předka. A vzhledem k tomu, že něco takového opravdu, ale opravdu nechci, tak se mi to scvrkne na "objekt = dict".
to v Pythonu nejde. To si asi pleteš s Javascriptem.Kód: [Vybrat]
class A:
pass
class B (A):
def boo(self):
return 'B'
def goo(self):
return 'C'
b = B()
print(dir(b))
A.goo = goo
print(dir(b))
print b.goo
print b.goo()
v mém scénáři začnu se strukturovaným AST (podmínky + cykly, fakt strom) a přeložím ho na seznam příkazů se skokama (tohle jsem měl původně na mysli, když jsem psal AST) a tady už jsou cykly kdy se příkaz skoku odkazuje na jiný příkaz ve stejném seznamu
javascript donedávna neměl ani třídy ani moduly a nechyběly. Byly přidány hlavně z marketingových důvodů. Vše bylo objekt/slovník. Stále je, nová syntax je jen nadbytečný cukr.Platí tedy i věta, že require, který načítá modul, byl přidán z marketingových důvodů a je to jen nadbytečný syntax sugar? A ty "marketingové důvody" znamenají, "Chceme aby to používalo více lidí, kteří nevědí, co je pro ně dobré."? Já jen aby to zaznělo pěkně naplno.
Nevim jak vypada implementace require. Ale prislo mi, ze je to jen funkce. A javascript uz koncept funkce ma, takze nic nemuzel pridavat. Kdyby museli upravit jazyk kvuli necemu, co jde implementovat pouhou funkci, pak ano, bylo by to pridani nadbytecneho cukru.
Marketingove dduvody, aby to pouzivalo vic lidi, jsou dost presne vyjadreni situace. Javascript mel prototypy vychazejici ze Selfu. To je presne co tady popisuju. Prolinkovany dicty. Nic vic. Nekdo ted pridal cukr na classy. Proc? Za me je odpoved marketing.
Pouzivas pojem marketing jako sproste slovo, ale marketing je o uspokojovani potreb. Protoze marketing == protoze to je velmi zadana vlastnost.
Syntakticky cukr neni nadbytecny. Syntakticky cukr zjednodusuje pouzivani jazyka, umoznuje psat kratsi, jednodusi, pochopitelnejsi a prehlednejsi kod. Take to muze umoznit rychlejsi beh programu.
Ja chapu potrebu schovavat. Akorat debaty o OO navrhu zacinaji tim, co schovat, zapouzdrit a zdedit, nez tim, co je vysledkem vyreseni problemu.
Kdyz jsi sam, kdo pouziva program, tak je fajn, ze si muzes vybrat tridu nebo modul nebo package nebo cokoliv k tomu ucelu. Jenze kdyz pracujes s indem, tak on si vybere jedno a ty druhy. Ja bych na to mel radsi jen jeden koncept.
V Selfu zjistili, ze je lepsi povazovat atribut stejne jako metodu. Jinak jestli se nekdo rozhoduje, jestli schovat nebo ne podle toho, co mu umoznuje jazyk, pak je otazka, jestli nema prilis svazujici jazyk.
Uvedomujes si, ze si protirecis?
Vadi ti syntakticky cukr a zaroven ti vadi, ze ind si vybere modul nebo tridu. Kdyz budes mit jazyk, kde si budes muset objekty implementovat sam z dictu, tak ten ind je bude zarucene implementovat jinak nez ty a tech moznych implementaci nebude jen trida nebo modul, bude jich prakticky nekonecne mnoho. Modul nebo trida,vto jsou ruzne abstrakce a ma smysl je mit. Ale mit nekonecne mnoho implementaci te same abstrakce, to smysl nedava. To je jeden z duvod, proc v pythonu pouzivas standardizovanou abstrakci class a ne vlastni reseni postavene nad dicty i kdyz muzes. Aby ses jednoduseji domluvil. Vsechno co ti zjednodusuje pouziti jazyka je uzitecne, nikoliv nadbytecne.
Problem je mozna v tom, ze OOP neni programovaci paradigma, ale vypocetni model. Podobny Petriho sitim. System, kde si mnozina objektu posila zpravy, muzu naimplementovat v cemkoliv. Muzu k tomu pouzit dokonce i C++ nebo Javu, tedy jazyky s dvoji koncepci modulu, tj. modul a trida.
The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.
http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
Jakkoliv nesouhlasim s nekterymi Tvymi zavery, libi se mi, ze jsi od sebe rozseknul veci, ktere se obycejne spojuji. Moduly+interfacy poskutuji elegantni reseni vetsiny veci, ktere slibuje resit OOP, jak se obycejne chape. Actor je neco (uz to tady nakousnul Mirek), co mi dava smysl jako "oklestene" vnimani objektoveho modelu. Co je opravdu z principu samostatne, necht je objekt. Zalozit celou aplikaci na "posilani zprav" mezi "objekty", to se moc neuchytilo a IMO jsou k tomu dobre duvody.
Problem je mozna v tom, ze OOP neni programovaci paradigma, ale vypocetni model. Podobny Petriho sitim. System, kde si mnozina objektu posila zpravy, muzu naimplementovat v cemkoliv. Muzu k tomu pouzit dokonce i C++ nebo Javu, tedy jazyky s dvoji koncepci modulu, tj. modul a trida.OOP je programovaci paradigma. Je to abstrakce, ktera ti umoznuje se na program divat/uvazovat jinym zpusobem. To jestli jde nebo nejde simulovat jinymi prostredky je nepodstatne. Pokud reknes, me abstrakce nezajima, pak se muzes vratit ke strojovemu kodu, protoze vsechno ostatni je vice ci mene pokrocila abstrakce nad nim a v nem jde pouzit/udelat vsechno, akorat to bude dost neprehledne.
The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation.
http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
Sproste slovo.. to zalezi na pohledu pozorovatele. Ja hovorim neutralne pokud mozno.Marketing je pozitivni, jeho smyslem je efektivne investovat zdroje. V pripade jazyka by tedy mel vest k vyvoji smerem, po kterem je nejvetsi poptavka, ktery ten jazyk nejlepe zhodnoti. Pokud je to jinak, neni to kvuli marketingu, ale jeho absenci. V lepsim pripade jsou zdroje promarneny, v horsim to jazyk pokazi a bude opusten.
Syntakticky cukr je tady jako kafe nebo jako droga. Kafe ti umozni zustat vzhuru dele dneska, ale na ukor spanku zitra. Cukr ti umozni pochopit jazyk driv dneska ale na ukor toho, ze kdyz budes chtit udelat neco slozitejsiho, tak to nepujde, protoze jazykove bozstvo rozhodlo, ze se budou pouzivat classy a ne nic jinyho.
Moje zavery nejsou zavery ale pouze tvrzeni ktera jsou pokud mozno vyvratitelna (falsifiability). Jinak receno jdu s kuzi na trh a usnadnuju vam ostatnim mi moje tvrzeni lehceji vyvratit.
Rad bych aby mi moje tvrzeni lidi zacali rozebirat na padrt a konstruktivne vyvracet. Casto moje 'zavery' zde ale ocividne lidi urazi.
Aplikace postavena na posilani zprav. To je pohled na vec, ne vec implementace. Kdyz mam distribuovany system z vic pocitacu, tak mi nezbyde nez mezi nimi skutecne poslat pres sit nejakou zpravu. Kdyz se podivam dovnitr jedny masiny nebo dovnitr konkretniho programu, muzu rict, ze zavolani metody je taky poslani zpravy.
Ja jsem nekde rek, ze me nezajima abstrakce?Doslova, ne, ale neprimo jo. Tebou neustale odmitany syntakticky cukr neni nic jineho, nez implementace vyssi abstrakce do jazyka. Zajima te to?
Kdyz jsme u strojoveho kodu. Kod 'nizke urovne abstrakce' a strojovy kod moderniho cpu pripominaji uz spis python nebo neco vysokourovnovyho.
import sys
print(sys.argv[::2])
A u toho Haskelluv tu bezela teze, ze jeho striktni funkcionalita a nic jineho je pro tve blaho, protoze te to donuti ji pouzivat a pochopit. S cimz se osobne neztotoznuji, ja jsem zastance flexibility a co mozna nejsirsich prostredku k vyjadreni.zvláštní, podle mě má haskell striktně bohatší vyjadřovací schopnosti než python :))
Sproste slovo.. to zalezi na pohledu pozorovatele. Ja hovorim neutralne pokud mozno.Marketing je pozitivni, jeho smyslem je efektivne investovat zdroje. V pripade jazyka by tedy mel vest k vyvoji smerem, po kterem je nejvetsi poptavka, ktery ten jazyk nejlepe zhodnoti. Pokud je to jinak, neni to kvuli marketingu, ale jeho absenci. V lepsim pripade jsou zdroje promarneny, v horsim to jazyk pokazi a bude opusten.
Syntakticky cukr je tady jako kafe nebo jako droga. Kafe ti umozni zustat vzhuru dele dneska, ale na ukor spanku zitra. Cukr ti umozni pochopit jazyk driv dneska ale na ukor toho, ze kdyz budes chtit udelat neco slozitejsiho, tak to nepujde, protoze jazykove bozstvo rozhodlo, ze se budou pouzivat classy a ne nic jinyho.
Syntakticky cukr neni ani jako kafe ani jako cukr. Ani jedno neni zavedeni zjednodusujici abstrakce, ani jedno z toho nesnizuje slozitost systemu. Python neni Haskell, tam ti zadne bozstvo neprikazalo pouzivat classy a nic jineho. A u toho Haskelluv tu bezela teze, ze jeho striktni funkcionalita a nic jineho je pro tve blaho, protoze te to donuti ji pouzivat a pochopit. S cimz se osobne neztotoznuji, ja jsem zastance flexibility a co mozna nejsirsich prostredku k vyjadreni.
Moje zavery nejsou zavery ale pouze tvrzeni ktera jsou pokud mozno vyvratitelna (falsifiability). Jinak receno jdu s kuzi na trh a usnadnuju vam ostatnim mi moje tvrzeni lehceji vyvratit.
Rad bych aby mi moje tvrzeni lidi zacali rozebirat na padrt a konstruktivne vyvracet. Casto moje 'zavery' zde ale ocividne lidi urazi.
Aplikace postavena na posilani zprav. To je pohled na vec, ne vec implementace. Kdyz mam distribuovany system z vic pocitacu, tak mi nezbyde nez mezi nimi skutecne poslat pres sit nejakou zpravu. Kdyz se podivam dovnitr jedny masiny nebo dovnitr konkretniho programu, muzu rict, ze zavolani metody je taky poslani zpravy.
No jak mam polemizovat s tim, ze objekt je dict a trida zbytecny syntakticky cukr? Jako zjednoduseni to nejaky smysl dava, prehlednou syntaxi mam vysoko v osobnich prioritach, proc se o to hadat v situaci, kdy je Tvuj nazor dost minoritni a vyvoj jde jinudy (podobne v kauze prototypy, kde Self a spol. evolucne prohravaji).
Zpravu ja si predstavuju ve smyslu pozdni vazby - mam nejaky dohodnuty protokol a pres obecny komunikacni kanal poslu zpravu a doufam, ze ji prijemce porozumi. Volani funkce v situaci, kdy mi to validuje kompilator nebo linter, je trosku neco jineho. Nemam potrebu se na to divat jako na komunikaci autonomnich objektu, protoze funkcim vidim pod prsty. Predstavovat si to muzeme ruzne, o tom zadna.
Protirecis si ve svych pozadavcich a jejich dusledcich. Odmitas vyssi abstrakci v jazyce, prijde ti zbytecna, kdyz tehoz muzes dosahnout existujicimi prostredky, byt sloziteji. A zaroven si stezujes na slozitost, ktera ti stezuje spolupraci s indem. Kdyz ti vadi vyssi pocet abstrakci zavedenych do jazyku, mel by ti idealne vyhovovat lisp, ale myslim ze ve skutecnosti i s nim bys mel problemy.Ja chapu potrebu schovavat. Akorat debaty o OO navrhu zacinaji tim, co schovat, zapouzdrit a zdedit, nez tim, co je vysledkem vyreseni problemu.
Kdyz jsi sam, kdo pouziva program, tak je fajn, ze si muzes vybrat tridu nebo modul nebo package nebo cokoliv k tomu ucelu. Jenze kdyz pracujes s indem, tak on si vybere jedno a ty druhy. Ja bych na to mel radsi jen jeden koncept.
V Selfu zjistili, ze je lepsi povazovat atribut stejne jako metodu. Jinak jestli se nekdo rozhoduje, jestli schovat nebo ne podle toho, co mu umoznuje jazyk, pak je otazka, jestli nema prilis svazujici jazyk.
Uvedomujes si, ze si protirecis?
Vadi ti syntakticky cukr a zaroven ti vadi, ze ind si vybere modul nebo tridu. Kdyz budes mit jazyk, kde si budes muset objekty implementovat sam z dictu, tak ten ind je bude zarucene implementovat jinak nez ty a tech moznych implementaci nebude jen trida nebo modul, bude jich prakticky nekonecne mnoho. Modul nebo trida,vto jsou ruzne abstrakce a ma smysl je mit. Ale mit nekonecne mnoho implementaci te same abstrakce, to smysl nedava. To je jeden z duvod, proc v pythonu pouzivas standardizovanou abstrakci class a ne vlastni reseni postavene nad dicty i kdyz muzes. Aby ses jednoduseji domluvil. Vsechno co ti zjednodusuje pouziti jazyka je uzitecne, nikoliv nadbytecne.
Mohl bys mi ukazat konkretni dve teze ve kterych si protirecim?
Ta spoluprace s indem je organizacni problem. Pokud ho nedokazu vyresit na urovni lidi tak me zadna trida nebo modul nespasi jinak pozdrav panbu. Vratim se k moji starsi tezi. Praseci kod a vic lidi co na nem pracuje? Vyres nejdriv problem praseciho kodu nez budes hledat nastroj co omezi ostatni cleny tymu tak aby neudelaly radsi zadnou chyby a taky zadny pokrok.
Ja v pythonu classy ani pokud mozno nepouzivam btw. Pro me je python jen host language pro vytvoreni lepsiho jazyka (embedded dsl), napr. proto ze python ma dobrej ekosystem knihoven.
Mozna jo, ja ho neznam. Ale ziskal jsem dojem, ze v nem nejde psat jinak nez funkcionalne a ze se v nem proto nejde vyjadrovat objektove nebo proceduralne.A u toho Haskelluv tu bezela teze, ze jeho striktni funkcionalita a nic jineho je pro tve blaho, protoze te to donuti ji pouzivat a pochopit. S cimz se osobne neztotoznuji, ja jsem zastance flexibility a co mozna nejsirsich prostredku k vyjadreni.zvláštní, podle mě má haskell striktně bohatší vyjadřovací schopnosti než python :))
je to čistě funkcionální jazyk, ale neřekl bych, že to brání objektovému (YMMV...) nebo procedurálnímu (tomu určitě ne) programováníMozna jo, ja ho neznam. Ale ziskal jsem dojem, ze v nem nejde psat jinak nez funkcionalne a ze se v nem proto nejde vyjadrovat objektove nebo proceduralne.A u toho Haskelluv tu bezela teze, ze jeho striktni funkcionalita a nic jineho je pro tve blaho, protoze te to donuti ji pouzivat a pochopit. S cimz se osobne neztotoznuji, ja jsem zastance flexibility a co mozna nejsirsich prostredku k vyjadreni.zvláštní, podle mě má haskell striktně bohatší vyjadřovací schopnosti než python :))
proto chapu, ze nekteri Haskell opevuji, kdyz maji pracovat treba s Indy.
Minoritni nazor. Tohle by bylo dobry tema. Mas pravdu ze muj nazor je minoritni. Ja se majoritnich nazoru stitim. Majoritni nazor je jako lemmings nebo ovce. Takova ovce nasleduje druhou ovci az se nasleduje cely stado a nakonec poskacou vsichni se srazu. Bud doslova nebo v nejaky financni krizi spadnou na hubu v akciich, nemovitostech, apod.
Kratkodobe vyhrava tenhle majoritni ovci nazor ale kdyz se vlastne sam zabije tim ze poskace ze skaly, dlouhodobe to zas takova konkurence neni.
Ano, nekdy se pohled na system jako mnozinu komunikujicich objektu hodi, jindy ne. Za me je to pouze pohled na vec. Pohled jak probiha vypocet. Muzu vzit jakykoliv system, i ten kde nikdo s zadnym posilanim zprav nepocital, a videt v nem posilani zprav.
Jak? Funkcionalitu tridy muzes implementovat skrz prototypy. Prototypy muzes implementovat skrz dicty. Ergo dict je obecnejsi abstrakce nez trida.Tahle logika kulhá na všechny čtyři. Kdyby záleželo na tom, co jde v čem implementovat, tak je instrukce mov ta úplně nejobecnější možná abstrakce (je výpočetně úplná, takže jde pomocí nich implementovat úplně všechno).
Zalozit celou aplikaci na "posilani zprav" mezi "objekty", to se moc neuchytilo a IMO jsou k tomu dobre duvody.Já bych to takhle příkře nestavěl. Skoro bych řekl, že naopak tenhle způsob dívání se na systémy se poslední dobou docela rozšiřuje, akorát ne na té "druhé nejnižší úrovní" (samotný programovací jazyk). Na vyšších urovních se mi ale zdá, že docela kvete.
Stejně goroutiny/channely v Go, REST, microservices, ...Jo, málem bych zapomněl na výpočetní clustery - tam to funguje už hodně dlouho - MPI, Hadoop, Spark, ... To je všechno o předávání zpráv mezi dost autonomními, "svéprávnými" jednotkami.
muzu rict, ze zavolani metody je taky poslani zpravy.Říct to samozřejmě můžeš, ale naděláš tím víc škody než užitku, protože jsou to dva zásadně odlišné koncepty. Už jsme o tom tady mluvili: pokud volám metodu, tak tím bezprostředně spouštím nějaký (víc nebo míň) statický, předem daný kód. Pokud posílám zprávu, tak jenom sděluju nějakou informaci. Jak s tím příjemce informace naloží, jestli v návaznosti na to vyvine nějakou činnost nebo ne, je už na něm.
Zalozit celou aplikaci na "posilani zprav" mezi "objekty", to se moc neuchytilo a IMO jsou k tomu dobre duvody.
Já bych to takhle příkře nestavěl. Skoro bych řekl, že naopak tenhle způsob dívání se na systémy se poslední dobou docela rozšiřuje, akorát ne na té "druhé nejnižší úrovní" (samotný programovací jazyk). Na vyšších urovních se mi ale zdá, že docela kvete.
Haskell je prilis striktni, neodpovida lidske intuiciZ mýho pohledu hlavně většinové programátorské intuici neodpovídá líné vyhodnocování. Většina z nás začínala a nejvíc času strávila přemýšlením v intencích "algoritmus je posloupnost kroků [...]".
Ja se majoritnich nazoru stitim. Majoritni nazor je jako lemmings nebo ovce.Majoritní názor taky je, že je Země kulatá. Minoritní názor je, že je placka.
Kdyby záleželo na tom, co jde v čem implementovat, tak je instrukce mov ta úplně nejobecnější možná abstrakce (je výpočetně úplná, takže jde pomocí nich implementovat úplně všechno).Ještě lepší je logický NOR, s ním si dospělej chlap vystačí ;)
Nedovedl jsem si predstavit, ze se zrovna Ty na tohle nechytnes. ;-)Tak jasně, pro mě je to prostě srdcovka. S multiagentními systémy jsem si pohrával ještě když jsem tahal kačera po škole :)
muzu rict, ze zavolani metody je taky poslani zpravy.Říct to samozřejmě můžeš, ale naděláš tím víc škody než užitku, protože jsou to dva zásadně odlišné koncepty. Už jsme o tom tady mluvili: pokud volám metodu, tak tím bezprostředně spouštím nějaký (víc nebo míň) statický, předem daný kód. Pokud posílám zprávu, tak jenom sděluju nějakou informaci. Jak s tím příjemce informace naloží, jestli v návaznosti na to vyvine nějakou činnost nebo ne, je už na něm.
V nejčistší podobě je rozdíl vidět na multiagentních systémech, kde si skutečně inteligentní agenti jenom sdělují informace, upravují svoje lokální knowledge bases a podle jejich obsahu pak vyvijejí nějakou činnost.
Haskell je prilis striktni, neodpovida lidske intuiciZ mýho pohledu hlavně většinové programátorské intuici neodpovídá líné vyhodnocování. Většina z nás začínala a nejvíc času strávila přemýšlením v intencích "algoritmus je posloupnost kroků [...]".Ja se majoritnich nazoru stitim. Majoritni nazor je jako lemmings nebo ovce.Majoritní názor taky je, že je Země kulatá. Minoritní názor je, že je placka.Kdyby záleželo na tom, co jde v čem implementovat, tak je instrukce mov ta úplně nejobecnější možná abstrakce (je výpočetně úplná, takže jde pomocí nich implementovat úplně všechno).Ještě lepší je logický NOR, s ním si dospělej chlap vystačí ;)Nedovedl jsem si predstavit, ze se zrovna Ty na tohle nechytnes. ;-)Tak jasně, pro mě je to prostě srdcovka. S multiagentními systémy jsem si pohrával ještě když jsem tahal kačera po škole :)
Jak? Funkcionalitu tridy muzes implementovat skrz prototypy. Prototypy muzes implementovat skrz dicty. Ergo dict je obecnejsi abstrakce nez trida.Tahle logika kulhá na všechny čtyři. Kdyby záleželo na tom, co jde v čem implementovat, tak je instrukce mov ta úplně nejobecnější možná abstrakce (je výpočetně úplná, takže jde pomocí nich implementovat úplně všechno).
Bud mam asynchronni poslani zpravy. Fire and forget.To s tím, co píšu, přímo nesouvisí.
Nebo mam synchronni volani zpravy, totez co volani funkce nebo metody. A to jsou celkem dve zpravy. Jedna odesilajici pozadavek, druha prijimajici vysledek.
Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Bud mam asynchronni poslani zpravy. Fire and forget.To s tím, co píšu, přímo nesouvisí.
Nebo mam synchronni volani zpravy, totez co volani funkce nebo metody. A to jsou celkem dve zpravy. Jedna odesilajici pozadavek, druha prijimajici vysledek.
Rozdíl je v tom, jestli se adresát zprávy autonomně rozhoduje, co udělá. Pokud volám metodu, tak se o ničem nerozhoduje, prostě se provede kód metody. To má potom různé důsledky, třeba právě v tom, jestli (jak snadno) jde udělat obecná proxy.
A kdyz zavolam metodu, co se sama interne rozhodne co udela?Tak se na tom, co jsem napsal, nemění ani čárka.
K cemu je dobre posilat do objektu zpravu, se kterou objekt neumi pracovat? Aby mi vratil InvalidArgumentException?Jak kdy a jak k čemu. Je "k něčemu dobré", že můžeš http serveru poslat nevalidní request? Je "k něčemu dobré", že po něm můžeš chtít resource, který nemá, a on ti odpoví "404 not found"?
Neni nahodou lepsi mit metodu se staticky typovanymi parametry, aby vubec nebylo mozne nesmyslnou zpravu objeku zaslat?
Majoritní názor taky je, že je Země kulatá. Minoritní názor je, že je placka.
Bud mam asynchronni poslani zpravy. Fire and forget.
Nebo mam synchronni volani zpravy, totez co volani funkce nebo metody. A to jsou celkem dve zpravy. Jedna odesilajici pozadavek, druha prijimajici vysledek.
Jak kdy a jak k čemu. Je "k něčemu dobré", že můžeš http serveru poslat nevalidní request? Je "k něčemu dobré", že po něm můžeš chtít resource, který nemá, a on ti odpoví "404 not found"?
K cemu je dobre posilat do objektu zpravu, se kterou objekt neumi pracovat? Aby mi vratil InvalidArgumentException?Jak kdy a jak k čemu. Je "k něčemu dobré", že můžeš http serveru poslat nevalidní request? Je "k něčemu dobré", že po něm můžeš chtít resource, který nemá, a on ti odpoví "404 not found"?
Neni nahodou lepsi mit metodu se staticky typovanymi parametry, aby vubec nebylo mozne nesmyslnou zpravu objeku zaslat?
Nevím, nerozumím moc smyslu té otázky.
Kdyz poslu Tomcatu nevalidni Http request ve smyslu, ze to vybec neni Http request, Tomcat (catalina) to odpalkuje hned a k memu Servletu se to vubec nedostane.
A ja nevidim zadnou vyhodu v tom, aby se mi do ServletDispatcheru sypal neidentifikovatelny bordel a dej se vule bozi.Já taky ne. A proč to říkáš?
Smysl one otazky spociva v tom, jaky ze je rozdil mezi synchronni zpravou a zavolanim metody.No já myslím, že jsem to už řekl dostatečně jasně:
pokud volám metodu, tak tím bezprostředně spouštím nějaký (víc nebo míň) statický, předem daný kód. Pokud posílám zprávu, tak jenom sděluju nějakou informaci. Jak s tím příjemce informace naloží, jestli v návaznosti na to vyvine nějakou činnost nebo ne, je už na něm.
Nebo mam synchronni volani zpravy, totez co volani funkce nebo metody. A to jsou celkem dve zpravy. Jedna odesilajici pozadavek, druha prijimajici vysledek.Plus započítej implementaci, která se prostě nepovedla. A díky tomu máme objektově orientované programování (místo objektového programování) :-)
Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Metoda se staticky typovanym atributen tedy NEMUZE dostat nekorektni data ve smyslu, ze to neni objekt HttpRequest.
Python neni pripad, ze se nedomluvis na nicem. U pythonu mas domluvenu jednu zasadni vec, ze vsechno je objekt, tj. vsechno ma nejaky zakladni protokol pomoci ktereho umi kazdy komunikovat s kazdym, treba se ho zeptat na identitu a dalsi veci a kazdy na to umi odpovedet.Metoda se staticky typovanym atributen tedy NEMUZE dostat nekorektni data ve smyslu, ze to neni objekt HttpRequest.Je rozdíl mezi tím, když se s dotyčným objektem domluvíš na určitých podmínkách, a mezi tím, když se domluvíš na všech (Haskell) a na ničem (Python).
Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
P.S. pokud je to potřeba vyloženě polopaticky:
Mezi voláním metody a předáním zprávy je podobný rozdíl jako mezi voláním metody a HTTP requestem. Pokud někdo bude tvrdit, že volání metody a HTTP request je totéž, tak podle mě jenom zbytečně mate pojmy. Vyvrátit se mu to ale nedá, protože ten člověk prostě jenom zbytečně označuje dvě meritorně rozdílné věci (neobvykle) stejným slovem. Jeho věc.
To je dobry postreh, ktery by nekomu mohl pomoci pochopit vyhody dynamickeho programovani.Jak kdy a jak k čemu. Je "k něčemu dobré", že můžeš http serveru poslat nevalidní request? Je "k něčemu dobré", že po něm můžeš chtít resource, který nemá, a on ti odpoví "404 not found"?
V důsledku by to znamenalo, že by každý klient musel přesně vědět, na co se smí kterého serveru zeptat. Ostatní požadavky by musel ten klient stornovat ještě před jeho odesláním. Tohle může splňovat tzv. tlustý klient.
Vlastně to můžeme zobecnit, že u statického typování je klient tlustý, ale server tenký. U dynamického typování je tomu naopak.
To same lze doporucit i tobe, akorat s dicty :-). Implementovat tu mou ukazku jen pomoci dictu se asi nikdo ani nepokusi, co? Beru to jako dukaz toho, ze vyssi abstrakce ma smysl a neni nadbytecna.Super, tak na tom postav intuitivni programovaci jazyk a budes mit perfektni system.Jak? Funkcionalitu tridy muzes implementovat skrz prototypy. Prototypy muzes implementovat skrz dicty. Ergo dict je obecnejsi abstrakce nez trida.Tahle logika kulhá na všechny čtyři. Kdyby záleželo na tom, co jde v čem implementovat, tak je instrukce mov ta úplně nejobecnější možná abstrakce (je výpočetně úplná, takže jde pomocí nich implementovat úplně všechno).
V marketingu te kvalita produktu zajima, ale nema absolutni prioritu. Zvazuji se i dalsi aspekty. Ve vysledku se v idealnim pripade na kvalitu klade takovy duraz, jaky na nej kladou zakaznici. Ano, vyhrava lepsi produkt, ale to nutne neznamena ten nejkvalitnejsi.Neshodnem se na vyznamu slova marketing. Ja pod marketingem chapu sales operaci s sirokym zaberem, tj. ne obvolavani jednotlivych klientu, ale neco co ma dosah k tisicum az milionum. V marketingu te nezajima kvalita produktu. Jediny cil je prodat. At uz je to smejd nebo super produkt, ktery se pak ale vetsinou prodava sam. Trh kratkodobe reaguje na marketing, ale dlouhodobe vyhrava lepsi produkt.Sproste slovo.. to zalezi na pohledu pozorovatele. Ja hovorim neutralne pokud mozno.Marketing je pozitivni, jeho smyslem je efektivne investovat zdroje. V pripade jazyka by tedy mel vest k vyvoji smerem, po kterem je nejvetsi poptavka, ktery ten jazyk nejlepe zhodnoti. Pokud je to jinak, neni to kvuli marketingu, ale jeho absenci. V lepsim pripade jsou zdroje promarneny, v horsim to jazyk pokazi a bude opusten.
Syntakticky cukr je tady jako kafe nebo jako droga. Kafe ti umozni zustat vzhuru dele dneska, ale na ukor spanku zitra. Cukr ti umozni pochopit jazyk driv dneska ale na ukor toho, ze kdyz budes chtit udelat neco slozitejsiho, tak to nepujde, protoze jazykove bozstvo rozhodlo, ze se budou pouzivat classy a ne nic jinyho.
Syntakticky cukr neni ani jako kafe ani jako cukr. Ani jedno neni zavedeni zjednodusujici abstrakce, ani jedno z toho nesnizuje slozitost systemu. Python neni Haskell, tam ti zadne bozstvo neprikazalo pouzivat classy a nic jineho. A u toho Haskelluv tu bezela teze, ze jeho striktni funkcionalita a nic jineho je pro tve blaho, protoze te to donuti ji pouzivat a pochopit. S cimz se osobne neztotoznuji, ja jsem zastance flexibility a co mozna nejsirsich prostredku k vyjadreni.
Analogie s kafem a drogou byla ve smyslu Chci neco ted hned ale rozesere me to pozdeji.
cukr, kafe, droga, dluh, vyber si
Python, Haskell, Javascript. V kazdem bozstvo rozhodlo jaky bude syntax. Rozhodli se ho udelat citelnejsi pro blbecky za cenu flexibility pro pokrocilejsi uzivatele. Podle me spravne rozhodnuti z pohledu adopce uzivateli ale schazi na trhu nastroje pro power usery.
Souhlasim, ze Haskell je prilis striktni, neodpovida lidske intuici, pusobi jako sveraci kazajka. Na druhou stranu clovek v sveraci kazajce nenadela prilis skody okolo, proto chapu, ze nekteri Haskell opevuji, kdyz maji pracovat treba s Indy.
Minoritni nazor. Tohle by bylo dobry tema. Mas pravdu ze muj nazor je minoritni. Ja se majoritnich nazoru stitim. Majoritni nazor je jako lemmings nebo ovce. Takova ovce nasleduje druhou ovci az se nasleduje cely stado a nakonec poskacou vsichni se srazu. Bud doslova nebo v nejaky financni krizi spadnou na hubu v akciich, nemovitostech, apod.Jestli mohu doporucit, utvor si a zastavej vlastni nazory a neres, jestli jsou majoritni nebo minoritni, protoze oboji muze byt chybne i spravne.
Rozdil je technicky, u posilani zprav muzu komunikovat skrze ruzna rozhrani, treba i socket a mit tak distribuovany system, za tuto flexibilitu se, jako vzdy, plati vykonemTo je pravda.
a navic je to komplikovanejsi na spravu.Ne vždycky, záleží na okolnostech.
Jaky je v tom rozdil ale pro navrh programu? Imho zadny, protoze z pohledu abstrakce je to to same. Tedy v pripade, ze se bude jednat o objekty v ramci jednoho programu. U distribuovaneho systemu me to bude nutit delat co nejvetsi objekty s co nejdelsi zivotnosti.I v rámci jednoho programu je rozdíl zásadní - buď píšu autonomní objekty, které se samy rozhodují, nebo píšu tupé recepty "když X, tak Y".
A tohle je právě jeden z technických důsledků toho zásadního rozdílu - předání informace se velice snadno zakóduje jakkoli (request může putovat klidně třeba mailem a A vůbec nepozná rozdíl), zatímco volání metody typicky využívá přímo instrukce procesoru, takže pokud chci udělat RPC, musím tam vrazit nějakou proxy, která to nafejkuje.Ale tohle je jen technicky problem, nijak to nemeni abstrakci objektoveho programovani. Volani metod nebo posilani zprav jsou jen ruzne formy komunikace. Je to podobne jako staticke/dynamicke typy. Bud chci vykon nebo flexibilitu, ale ani jednim nenarusim paradigma proceduralniho/oop/funkcionalniho programovani. Posilani zprav je flexibilni, ale ani volanim metod nenarusim oop. Jestli je objekt autonomni nebo ne zalezi na jeho implementaci a ne na zpusobu, jakym komunikuje.
Bud chci vykon nebo flexibilitu, ale ani jednim nenarusim paradigma proceduralniho/oop/funkcionalniho programovani. Posilani zprav je flexibilni, ale ani volanim metod nenarusim oop. Jestli je objekt autonomni nebo ne zalezi na jeho implementaci a ne na zpusobu, jakym komunikuje.Ale jistě, pokud chceš, můžeš všechno. Ale pokud máš nějaké prostředky, tak jim design přizpůsobuješ. Pokud máš jako hlavní prostředek volání metod, tak se ti prostě nebude chtít jít třeba do té distribuovanosti (a je to racionální). Navíc tě to bude motivovat udělat rozhraní objektu určitým způsobem.
Vzhledem k tomu, ze to neni zadarmo, tak tu distribuovatelnost chci jen v pripade, ze ji potrebuji a ne pro strycka prihodu co kdyby. Protoze zpomalit si signifikantne system jen pro strycka prihodu nedava smysl. Kdyz dospeju k tomu, ze distribuovatelnost potrebuji, stejne ji z toho duvodu zaridim jen mezi objekty, ktere ji potrebuji a ne mezi vsemi. Jo, neni to tak flexibilni, ale za to je to pouzitelne. Protoze kdyz scitam objekt 1 + objekt 1, tak to typicky nechci zatezovat pomalou komunikaci.Bud chci vykon nebo flexibilitu, ale ani jednim nenarusim paradigma proceduralniho/oop/funkcionalniho programovani. Posilani zprav je flexibilni, ale ani volanim metod nenarusim oop. Jestli je objekt autonomni nebo ne zalezi na jeho implementaci a ne na zpusobu, jakym komunikuje.Ale jistě, pokud chceš, můžeš všechno. Ale pokud máš nějaké prostředky, tak jim design přizpůsobuješ. Pokud máš jako hlavní prostředek volání metod, tak se ti prostě nebude chtít jít třeba do té distribuovanosti (a je to racionální). Navíc tě to bude motivovat udělat rozhraní objektu určitým způsobem.
Jinými slovy: pokud sis zvolil menší flexibilitu, nebudeš dělat designová rozhodnutí, která by se dobře implementovala jedině v systému s větší flexibilitou. Ne že by to nešlo, ale "nazapadá to do sebe", nemělo by to logiku.
...no a protože mainstream staví jednoznačně na volání metod, tak se v sw inženýrství prosadily metody, které tomu odpovídají. A teprve teď, později, se učíme, jak se vlastně ty víc flexibilní systémy designují a implementují (to jsou právě třeba ty microservices, které jenom málo kdo dokáže navrhnout dobře, aniž by to udělal úplně tupě).
...no a protože mainstream staví jednoznačně na volání metod, tak se v sw inženýrství prosadily metody, které tomu odpovídají. A teprve teď, později, se učíme, jak se vlastně ty víc flexibilní systémy designují a implementují (to jsou právě třeba ty microservices, které jenom málo kdo dokáže navrhnout dobře, aniž by to udělal úplně tupě).To je proste proces. Az to bude v praxi pouzitelne a prinosne, tak se s tim lide nauci pracovat. Ne vsichni, nekteri zustanou zamrzli na oop realizovanem pomoci metod, stejne jako nekteri zustali zamrzli na statickych jazycich. Tak to proste je.
Protoze kdyz scitam objekt 1 + objekt 1, tak to typicky nechci zatezovat pomalou komunikaci.To ani není nutně potřeba. Zase příklad z Elixiru: komunikace pomocí zpráv se dělá jenom mezi procesy. V rámci jednoho procesu se dělá (víceméně) standardní volání funkcí.
Protoze kdyz scitam objekt 1 + objekt 1, tak to typicky nechci zatezovat pomalou komunikaci.To ani není nutně potřeba. Zase příklad z Elixiru: komunikace pomocí zpráv se dělá jenom mezi procesy. V rámci jednoho procesu se dělá (víceméně) standardní volání funkcí.
Jinak ale celkem souhlas se vším, co píšeš.
Nutne neni potreba ani to posilani zprav. Resp. je potreba v minimu pripadu, kdy se vyplati ho implementovat rucne a proto je lepsi ho nemit by default. Ale rozlisoval bych mezi interni implementaci a abstrakci. V Pythonu treba cisla interne take ve skutecnosti nejsou objekty, to by byl o dost pomalejsi, ale vuci programatorovi se tak tvari a to je to, co se pocita, to je podle me podstatne, protoze to umoznuje programatorovi k programu pristupovat nejakym a jednotnym pristupem. Podle me je Python vyborne navrzen, vsechno je v nem objekt a definice tridy je zaroven definici datoveho typu. Pricemz k tomuto sjednoceni doslo az ve verzi 2.2, a po zbytek druhe generace v nem byly objekty dvojiho typu. Cesta k jeho dobremu navrhu je lemovana chybami a odvahou prinaset nekompatibilni zmeny. Az nastane cas na posilani zprav mezi objekty, python prijde s flexibilnim funkcnim resenim. Ted je na poradu dne spise asynchronni komunikace, kterou python pred casem adoptoval a ted se ladi.Protoze kdyz scitam objekt 1 + objekt 1, tak to typicky nechci zatezovat pomalou komunikaci.To ani není nutně potřeba. Zase příklad z Elixiru: komunikace pomocí zpráv se dělá jenom mezi procesy. V rámci jednoho procesu se dělá (víceméně) standardní volání funkcí.
Jinak ale celkem souhlas se vším, co píšeš.
Ted je na poradu dne spise asynchronni komunikace, kterou python pred casem adoptoval a ted se ladi.jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go
Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.
Pozadu je, ale dotahuje se, s kazdou verzi se to vylepšuje. Asyncio je modelova knihovna. Soucasti jazyka se staly prikazy async a await a pracuje se na jejich hlubsi integraci do systemu. Python jde evolucni cestou vyvoje, takze se nejprve vyzkousi koncept, pak se to implementuje jako modul, pak se to zavede do jazyka, a nakonec se to v nem usazuje a prorusta do systemu. Stejne tak to probihalo u dalsich abstrakci, u novych trid, iteratoru, generatoru, type hintingu. Je to jen otazka casu.Ted je na poradu dne spise asynchronni komunikace, kterou python pred casem adoptoval a ted se ladi.jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi go
Az nastane cas na posilani zprav mezi objekty, python prijde s flexibilnim funkcnim resenim. Ted je na poradu dne spise asynchronni komunikace, kterou python pred casem adoptoval a ted se ladi.S tím se asi nedá nesouhlasit. Stejně jako s tím asyncio, kdy Python teď ladí něco, co jinde už deset let funguje :) Zasílání zpráv je už teď (Pykka), akorát je to neúplná omezená implementace Akka, což je neúplná omezená implementace toho, co má Erlang víc než dvacet let :)
jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi goCo Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let! ;)
já jsem hlavně narážel na nutnost psát explicitně všelijaké ty async/await, když erlang má lightweight vlákna přes 30 letjestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi goCo Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let! ;)
Nerozumim pojmu derava abstrakce?Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Az vyresis tuhle kontradikci, naleznes nirvanu.
Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.
Mozna ma a nic mu to nebylo platny. :-) Python ma greenlety uz taky nejaky rok, o tom to preci neni.já jsem hlavně narážel na nutnost psát explicitně všelijaké ty async/await, když erlang má lightweight vlákna přes 30 letjestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi goCo Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let! ;)
greenlet jsem neznal, nicméně to nevypadá jako skutečné lightweight vlákno, chybí mi ta abstrakce vláknaMozna ma a nic mu to nebylo platny. :-) Python ma greenlety uz taky nejaky rok, o tom to preci neni.já jsem hlavně narážel na nutnost psát explicitně všelijaké ty async/await, když erlang má lightweight vlákna přes 30 letjestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi goCo Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let! ;)
Node.js neni univerzalni, je orientovan na web. V tomto smeru nabizi Python treba Tornado a Twisted. Ale to je take jednoucelove reseni. Reseni na urovni jazyka je samozrejme lepsi.jestli je tím myšleno asyncio, tak tady je IMO python hodně pozadu, srovnejte s erlangem, haskellem a asi goCo Erlang a Haskell... Node.js už tady máme 9 (slovy: devět) let! ;)
chybí mi ta abstrakce vlákna
Nerozumim pojmu derava abstrakce?Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Az vyresis tuhle kontradikci, naleznes nirvanu.
Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.
Jak vis co bude zitra?
Nad objekty jako abstrakce imho stoji komponenty. Ale neni nutne aby nad kazdou abstrakci byla jeste vyssi, resp. aby kazda abstrakce byla soucasti ci stavebnim kamenem vyssi abstrakce.
Metatrida je spise implementacni detail, druh tridy za nejakym ucelem, podobne jako je treba abstraktni trida, nez nova vyssi abstrakce. Python manipulaci s metatridami umoznuje, ale myslim ze jsem toho nikdy nevyuzil, takze se nedivim, ze v jinych jazycich nejsou k dispozici. Pokud by to byl problem, je dusledkem nedostatecne implementace, nikoliv chybne abstrakce.
V cem je objekt derava abstrakce?
Trida je derava abstrakce ale smalltalk trida derava neni? Zase si protirecis.
jako normální vláknochybí mi ta abstrakce vlákna
to by mělo vypadat jak?
forkIO $ forever $ do
writeChan tx "hello"
response <- readChan rx
print response
a není poznat, že to není plnotučné vlákno a místo kanálů může být třeba socket nebo stdin
Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.
Ja jsem tvrdil ze cukr je derava abstrakce, tridy vem cert.
Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Node.js neni univerzalni, je orientovan na web.Webem to možná začalo, dneska už je to stejně univerzální platforma jako Python.
Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.
Ja jsem tvrdil ze cukr je derava abstrakce, tridy vem cert.
Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Proč by měly mít třídy možnost dědit od více rodičů? Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
Tridy jako abstrakce vicenasobnou dedicnost umoznuji. Ze to nektere jazyky neimplementuji neni chyba abstrakce.Nerozumim pojmu derava abstrakce?Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Az vyresis tuhle kontradikci, naleznes nirvanu.
Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.
Jak vis co bude zitra?
Nad objekty jako abstrakce imho stoji komponenty. Ale neni nutne aby nad kazdou abstrakci byla jeste vyssi, resp. aby kazda abstrakce byla soucasti ci stavebnim kamenem vyssi abstrakce.
Metatrida je spise implementacni detail, druh tridy za nejakym ucelem, podobne jako je treba abstraktni trida, nez nova vyssi abstrakce. Python manipulaci s metatridami umoznuje, ale myslim ze jsem toho nikdy nevyuzil, takze se nedivim, ze v jinych jazycich nejsou k dispozici. Pokud by to byl problem, je dusledkem nedostatecne implementace, nikoliv chybne abstrakce.
V cem je objekt derava abstrakce?
Trida je derava abstrakce ale smalltalk trida derava neni? Zase si protirecis.
Me tridy nezajimaji, ja je nepouzivam a nejsem na ne expert. Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.
Ja jsem tvrdil ze cukr je derava abstrakce, tridy vem cert.
Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
To se hodi, protoze takovy potomek muze nahradit vic ruznych predku soucasne.Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.Proč by měly mít třídy možnost dědit od více rodičů? Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
Ja jsem tvrdil ze cukr je derava abstrakce, tridy vem cert.
Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Ok, podivam se na dostupne knihovny, treba podporu midi komunikace.Node.js neni univerzalni, je orientovan na web.Webem to možná začalo, dneska už je to stejně univerzální platforma jako Python.
A i kdyby: devět let, to je v IT celá věčnost.
Ano muzes tady pouzit kompozici misto dedicnosti. Tim se vracime k tomu, ze muzes pouzit proste dict, protoze to vyjde nastejno.Tohle tvrzeni jsi neprokazal. Implementuj ukazku, co jsem ti predlozil, pomoci dictu a uvidime, jestli to vyjde na stejno. Ja tvrdim ze ne. Ale treba mi neco unika a dokazes to.
Trida neco neumoznuje (derava abstrakce), ale potrebuju toho stejne dosahnout. Musim to ochcat pres kompozici a najednou mam dva zpusoby jak neco resit. Proc nevyhodit ten deravej zpusob a nenechat jen kompozici.
Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.
Ja jsem tvrdil ze cukr je derava abstrakce, tridy vem cert.
Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Proč by měly mít třídy možnost dědit od více rodičů? Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
Muzes mit nekolik Mixin trid a chces je ppuzit vsechny napriklad.
Ano muzes tady pouzit kompozici misto dedicnosti. Tim se vracime k tomu, ze muzes pouzit proste dict, protoze to vyjde nastejno.
Trida neco neumoznuje (derava abstrakce), ale potrebuju toho stejne dosahnout. Musim to ochcat pres kompozici a najednou mam dva zpusoby jak neco resit. Proc nevyhodit ten deravej zpusob a nenechat jen kompozici.
To se hodi, protoze takovy potomek muze nahradit vic ruznych predku soucasne.Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.Proč by měly mít třídy možnost dědit od více rodičů? Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
Ja jsem tvrdil ze cukr je derava abstrakce, tridy vem cert.
Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Mas tridu Plavidlo a Vozidlo a potrebujes vytvorit tridu Obojzivelnik(Vozidlo, Plavidlo).Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.
Ja jsem tvrdil ze cukr je derava abstrakce, tridy vem cert.
Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Proč by měly mít třídy možnost dědit od více rodičů? Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
Muzes mit nekolik Mixin trid a chces je ppuzit vsechny napriklad.
Ano muzes tady pouzit kompozici misto dedicnosti. Tim se vracime k tomu, ze muzes pouzit proste dict, protoze to vyjde nastejno.
Trida neco neumoznuje (derava abstrakce), ale potrebuju toho stejne dosahnout. Musim to ochcat pres kompozici a najednou mam dva zpusoby jak neco resit. Proc nevyhodit ten deravej zpusob a nenechat jen kompozici.
Vývojář by se měl především zamyslet nad tím, zda takové mixiny nejsou logickým nesmyslem. Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?
Takze neco na hrani ma, ale asi to nebude pouzitelny kvuli latenci: https://stackoverflow.com/questions/44741879/node-midi-i-o-module-has-a-slight-latency Ze by prave kvuli async io? Jde to vypnout?Ok, podivam se na dostupne knihovny, treba podporu midi komunikace.Node.js neni univerzalni, je orientovan na web.Webem to možná začalo, dneska už je to stejně univerzální platforma jako Python.
A i kdyby: devět let, to je v IT celá věčnost.
Vývojář by se měl především zamyslet nad tím, zda takové mixiny nejsou logickým nesmyslem. Mohl bys uvést nějaký příklad, kde by to mohlo být k něčemu dobré?Mas tridu Plavidlo a Vozidlo a potrebujes vytvorit tridu Obojzivelnik(Vozidlo, Plavidlo).
Tridy jako abstrakce vicenasobnou dedicnost umoznuji. Ze to nektere jazyky neimplementuji neni chyba abstrakce.Nerozumim pojmu derava abstrakce?Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Az vyresis tuhle kontradikci, naleznes nirvanu.
Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.
Jak vis co bude zitra?
Nad objekty jako abstrakce imho stoji komponenty. Ale neni nutne aby nad kazdou abstrakci byla jeste vyssi, resp. aby kazda abstrakce byla soucasti ci stavebnim kamenem vyssi abstrakce.
Metatrida je spise implementacni detail, druh tridy za nejakym ucelem, podobne jako je treba abstraktni trida, nez nova vyssi abstrakce. Python manipulaci s metatridami umoznuje, ale myslim ze jsem toho nikdy nevyuzil, takze se nedivim, ze v jinych jazycich nejsou k dispozici. Pokud by to byl problem, je dusledkem nedostatecne implementace, nikoliv chybne abstrakce.
V cem je objekt derava abstrakce?
Trida je derava abstrakce ale smalltalk trida derava neni? Zase si protirecis.
Me tridy nezajimaji, ja je nepouzivam a nejsem na ne expert. Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.
Ja jsem tvrdil ze cukr je derava abstrakce, tridy vem cert.
Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Tvrdil jsi, ze tridy a objekty jsou derava abstrakce. Cukr a kafe abstrakce neni.
Ok, derava abstrakce je takova, ktera neslouzi jako zaklad vyssi abstrakce. V tom pripade na nich neni nic spatneho.
Abstrakce tvori kazdy programator, ktery pouziva tridy. Takze nevim jestli ty jo, kdyz je nepouzivas, ja ale ano.
Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))
O tridach a objektech tvrdim ze existuje jednodussi mechanismus na kterym zalozit bazi jazyka - napr. prototypy. Clovek pak v implementaci nemusi resit rozdil mezi objektem a tridou, pouze mezi built-in a derivovanym objektem.
Pro vetsinu aplikaci to jsou sourozenci se spolecnym predkem.Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))
projektový manažer:Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))
Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))
vývojář:vývojář 2: Vůbec nerozumíš OOP návrhu! Dog má samozřejmě dědit z HairyAnimal, implementovat rozhraní FourLeggedThing a skládat PetYouCanHoldWithAtLeastTwoHands!
"a je to tu! na tohle jsi tak dlouho trénoval!
class Dog implements Animal
... "
To tu ještě nebylo. Tak to bude delší debata než obvykle! (Tipuju tak dvacet stránek)A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))Pro vetsinu aplikaci to jsou sourozenci se spolecnym predkem.
Pak je 'deravy' jazyk (coz nicemu nemusi vadit), ale nikoliv abstrakce oop jako paradigma. Bavis se o konkretnim jazyku nebo obecne o oop?Pokud mas teda jazyk postavenej na neuplny implementaci tridy pak je ten jazyk deravej v abstrakcich. Zapomen na to jestli jsem neco tvrdil o deravych tridach protoze jsme se nikdy neshodli na tom jestli se bavime o implementaci nebo koncepci. Tridu jako abstrakci muzu implementovat pouhym dictem metod a seznamem jak jsem zminil. Tvrdim akorat ze cukr je deravy a tvrdim ze vzdy.Tridy jako abstrakce vicenasobnou dedicnost umoznuji. Ze to nektere jazyky neimplementuji neni chyba abstrakce.Nerozumim pojmu derava abstrakce?Presne na tohle je dobra vyssi abstrakce, kterou nazyvas nadbytecny syntakticky cukr. Porad to vnimam tak, ze si protirecis.Jakmile vidis, ze to na co lidi pouzivaji tisice az miliony radku kodu jde pouzit par set nebo mozna nizkych tisic, a udelat to zaroven jednodussi, rychlejsi, citelnejsi, tak prehodnotis.Dneska je programovani zhruba na urovni pred Kopernikem, takze se od tech majoritnich cirkevnich nazoru distancuju.Jak myslíš, no. Já bych si spíš vsadil, že to ještě v průběhu života přehodnotíš, ale třeba bych prohrál :)
Jestli v programovani existuje silver bullet, pak bych bych vsadil hodne na to, ze to bude jednoduchost (simplicity).
Az vyresis tuhle kontradikci, naleznes nirvanu.
Syntakticky cukr je derava abstrakce. Dostanes jednu abstrakci dnes, ale uz z ni zitra nevytvoris jeste vyssi abstrakci. Pro nederavy abstrakce potrebujes vysoce kompozitabilni stavebni bloky, napr. nekdo zminil nor nebo mov nebo funkce. Ty slozis do vyssich abstraktnich bloku, ty jeste do vyssich, atd.
Tridy a objekty jsou derava abstrakce. Je to videt kdyz zjistis ze najednou potrebujes metatridy a tvuj jazyk je nema. Smalltalk tridy mozna deravy nejsou, ale ve vetsine jazyku je to abstraktni dira.
Jak vis co bude zitra?
Nad objekty jako abstrakce imho stoji komponenty. Ale neni nutne aby nad kazdou abstrakci byla jeste vyssi, resp. aby kazda abstrakce byla soucasti ci stavebnim kamenem vyssi abstrakce.
Metatrida je spise implementacni detail, druh tridy za nejakym ucelem, podobne jako je treba abstraktni trida, nez nova vyssi abstrakce. Python manipulaci s metatridami umoznuje, ale myslim ze jsem toho nikdy nevyuzil, takze se nedivim, ze v jinych jazycich nejsou k dispozici. Pokud by to byl problem, je dusledkem nedostatecne implementace, nikoliv chybne abstrakce.
V cem je objekt derava abstrakce?
Trida je derava abstrakce ale smalltalk trida derava neni? Zase si protirecis.
Me tridy nezajimaji, ja je nepouzivam a nejsem na ne expert. Deravy jsou protoze treba nezvladnou dedit z vic rodicu. Nektery jo, protoze maji lrpsi implementaci coz je sada hacku a uz se to nabaluje.
Ja jsem tvrdil ze cukr je derava abstrakce, tridy vem cert.
Derava abstrakce je takova ze ktery neposkladas jeste vyssi abstrakci. Ne vsechny pripady, protoze tam je dira. Treba te to nezajima protoze matlas kod a pouzivas k tomu abstrakce od jinych lidi. Lidi co ale tvori abstrakce hodne zajima jestli k tomu maji dostatecny nastroje.
Tvrdil jsi, ze tridy a objekty jsou derava abstrakce. Cukr a kafe abstrakce neni.
Ok, derava abstrakce je takova, ktera neslouzi jako zaklad vyssi abstrakce. V tom pripade na nich neni nic spatneho.
Abstrakce tvori kazdy programator, ktery pouziva tridy. Takze nevim jestli ty jo, kdyz je nepouzivas, ja ale ano.
O tridach a objektech tvrdim ze existuje jednodussi mechanismus na kterym zalozit bazi jazyka - napr. prototypy. Clovek pak v implementaci nemusi resit rozdil mezi objektem a tridou, pouze mezi built-in a derivovanym objektem.
Máme tady třídu Obojživelník, Vozidlo a Plavidlo. Ze které z nich bude dědit třída Letadlo?To je úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.
Máme tady třídu Obojživelník, Vozidlo a Plavidlo. Ze které z nich bude dědit třída Letadlo?To je úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.
Diamant je vyreseny c3 linearizaci. Letadlo je sourozenec Vozidla a Plavidla a jeste si k tomu pridej Ponorku. Podzemni vozidla asi nemame a Vesmirna budeme ignorovat.Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))
Ani jedno :)
Tématem je, co si myslíme o OOP. Jak tady někdo začne s diamanty, tak je jasné, že něco navrhuje blbě. Dědičnost je užitečná, ale její nadužívání je škodlivé. Máme tady třídu Obojživelník, Vozidlo a Plavidlo. Ze které z nich bude dědit třída Letadlo?
Snad budeš souhlasit i s tím, že Letadlo za určitých okolností může dědit z třídy DopravníProstředek, stejně jako ostatní zmíněné třídy.Jasně že bych souhlasil. Je to jenom speciální případ obecného tvrzení:
Obojživelník, Vozidlo i Plavidlo jsou DopravníProstředky.A jsme na standardní vlně "OOP debaty" :))) Dávám tomu tak dvě stránky, než začnete řešit, jestli má čtverec dědit z obdélníka nebo naopak :)))
Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.Máme tady třídu Obojživelník, Vozidlo a Plavidlo. Ze které z nich bude dědit třída Letadlo?To je úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.
Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:
Ještě je třeba myslet na další pravidlo :Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:
(T2) zadaní se vždycky změní, nejpozději do půl roku
a třetím:
(T3) jakmile se zadání změní, je potřeba okamžitě udělat ad hoc změny, které původně geniální objektovou analýzu změní v nepřehledný bordel totálních zhovadilostí
čímž se dostáváme k větě "obecné tvrzení o oop" (OTOOOP lemma):
(OTOOOP) Cokoliv může [v čase analýzy] dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.
:)
Zalezi co se snazis modelovat a zda ma byt system flexibilni a rozsiritelny a na jake urovni. I tomu musis prizpusobit navrh. Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:
(T2) zadaní se vždycky změní, nejpozději do půl roku
a třetím:
(T3) jakmile se zadání změní, je potřeba okamžitě udělat ad hoc změny, které původně geniální objektovou analýzu změní v nepřehledný bordel totálních zhovadilostí
čímž se dostáváme k větě "obecné tvrzení o oop" (OTOOOP lemma):
(OTOOOP) Cokoliv může [v čase analýzy] dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.
:)
Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.A proto je to nejčastější způsob! ;)
Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.A úplně ideálně ani třídy ne :)
Třída je typ.Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.A proto je to nejčastější způsob! ;)Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.A úplně ideálně ani třídy ne :)
V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)Třída je typ.Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.A proto je to nejčastější způsob! ;)Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.A úplně ideálně ani třídy ne :)
Mě teda přijde, ale možná z toho ještě vyrostu, že na něco takového je dobrej kompromis funkcionální programování. Napsat funkci umí každej. Nejde to moc zvrtat. Kruhový závislosti jsem tam taky nějak moc neviděl. A když vznikne nějaký patvar, nebo se posune zadání, tak se prostě staré funkce nechají vyhnít. Zatím my přišlo, že se to dá snáz ukočírovat.Ještě je třeba myslet na další pravidlo :Nevznikne, kdyz si dobre analyzujes potreby a tomu navrhnes vhodnou abstrakci. Protoze je potreba mit na mysli, ze tato abstrakce je zjednoduseny model za nejakym konkretnim ucelem, ktery je potreba sledovat a neexistuje zadne univerzalne platne rozdeleni.Ano, to je pravda. Toto tvrzení (T1) pak zkombinujeme s druhým:
(T2) zadaní se vždycky změní, nejpozději do půl roku
a třetím:
(T3) jakmile se zadání změní, je potřeba okamžitě udělat ad hoc změny, které původně geniální objektovou analýzu změní v nepřehledný bordel totálních zhovadilostí
čímž se dostáváme k větě "obecné tvrzení o oop" (OTOOOP lemma):
(OTOOOP) Cokoliv může [v čase analýzy] dědit z čehokoliv, je to úplně jedno, protože ať tak nebo tak, stejně ve finále vznikne nepřehledný bordel totálních zhovadilostí.
:)
(T4) Změna zadání rozbordelí jakýkoliv návrh provedený podle jakéhokoliv paradigmatu.
Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit. Když to bude nepřehledé už od začátku, tak už to žádná změna nemůže zhoršit. 8)
Pokud mas teda jazyk postavenej na neuplny implementaci tridy pak je ten jazyk deravej v abstrakcich. Zapomen na to jestli jsem neco tvrdil o deravych tridach protoze jsme se nikdy neshodli na tom jestli se bavime o implementaci nebo koncepci. Tridu jako abstrakci muzu implementovat pouhym dictem metod a seznamem jak jsem zminil. Tvrdim akorat ze cukr je deravy a tvrdim ze vzdy.
O tridach a objektech tvrdim ze existuje jednodussi mechanismus na kterym zalozit bazi jazyka - napr. prototypy. Clovek pak v implementaci nemusi resit rozdil mezi objektem a tridou, pouze mezi built-in a derivovanym objektem.
Úplně něco jiného jsou pak vlastnosti jazyka, které schválně omezují vývojáře. Protože takové omezení může být z různých důvodů přidaná hodnota.
Úplně něco jiného jsou pak vlastnosti jazyka, které schválně omezují vývojáře. Protože takové omezení může být z různých důvodů přidaná hodnota.
Dodnes jsem přesvědčen, že gettery a settery nejsou v Javě součástí syntaxe právě proto, aby se nepoužívaly.
Jak jsi na to prisel? Vytvareni uzivatelskych typu pomoci trid je zaklad.V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)Třída je typ.Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.A proto je to nejčastější způsob! ;)Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.A úplně ideálně ani třídy ne :)
Je na tom postavena zakladni typova kontrola, pouziva to chtej nechtej kazdy:Jak jsi na to prisel? Vytvareni uzivatelskych typu pomoci trid je zaklad.V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)Třída je typ.Jediné řešení je vykašlat se na jakoukoliv analýzu a prostě to naprasit.A proto je to nejčastější způsob! ;)Tady uz zacinaji vyhody flexibility dynamickych jazyku, ktere nemusi resit typ ale jen protokol a casto ani to ne.A úplně ideálně ani třídy ne :)
>>> class A():
... pass
...
>>> a = A()
>>> type(a)
<class '__main__.A'>
>>> type(a).__name__
'A'
>>> 1 + a
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'A'
Mě mučí tyhle slovokolotoče: v Pythonu se objekt vytváří pomocí slova class, a na jeho jméno se tážeme slovem type. Uff.V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)Jak jsi na to prisel? Vytvareni uzivatelskych typu pomoci trid je zaklad.
pouziva to chtej nechtej kazdy:Zas nepřeháněj. Možná někdo někdy.
To je dost zavadejici tvrzeni. Pomoci class se definuje trida, coz je sice take objekt, jako vsechno v pythonu, ale neni to jedina a ani hlavní cesta jak vytvaret objekty. Objekt, ktery jsi mel pravdepodobne na mysli, se vytvari volanim te tridy, nikoliv pomoci slova class. A neni to zadny slovokolotoc, datovym typem tridy je typ type. Volanim type() se pak neptas na jmeno objektu, ale jeho datovy typ. Mas v tom desny chaos.Mě mučí tyhle slovokolotoče: v Pythonu se objekt vytváří pomocí slova class, a na jeho jméno se tážeme slovem type. Uff.V Pythonu?! (Ano, formálně samozřejmě ano, ale reálně na tom nikdo nic nestaví.)Jak jsi na to prisel? Vytvareni uzivatelskych typu pomoci trid je zaklad.
Neprehanim. Protoze je na tom postavena silna typova kontrola, chtej nechtej to pouziva kazdy, te se nevyhnes. I ten, kdo nepouziva v Pythonu tridy a nevytvari si vlastni uzivatelske typy. Python je flexibilni a nenuti te definovat si vlastni tridy, tedy vlastni uzivatelske typy, ale bez toho ho vyuzivas jen tak na pul. Pro male skripty fajn, tam vystacis s generickymi typy, ale pro vetsi aplikace a/nebo komplexnejsi datove struktury je to vyborna pomucka a jen trouba ji nevyuzije.pouziva to chtej nechtej kazdy:Zas nepřeháněj. Možná někdo někdy.
Mě mučí tyhle slovokolotoče: v Pythonu se objekt vytváří pomocí slova class, a na jeho jméno se tážeme slovem type. Uff.
Mě mučí tyhle slovokolotoče: v Pythonu se objekt vytváří pomocí slova class, a na jeho jméno se tážeme slovem type. Uff.
Na jmeno tridy se ptame pres x.__class__.__name__. Jestli je objekt instanci (pod)tridy se ptame pomoci isinstance(). type() se pro tyto ucely pouzivat nedoporucuje, rozhodne ne v Pythonu 3, kde se semantika te funkce dost zmenila.
Upresnim. Funkce type(obj) vraci datovy typ promenne. Funkce isinstance(obj, cls) vraci bool a vyhodnocuje, zda obj je instanci tridy nebo jejiho potomka, cili na test typove kompatibility je to vhodnejsi funkce. V Pythonu 3 je type(obj) ekvivalentni s obj.__class__, protoze v pythonu jsou sjednoceny typy a tridy. V Pythonu 2 to tak nebylo, byly tam tridy dvojiho druhu, puvodni a tzv, new class, ktere se v Pythonu 3 staly standardnimi a univerzalni pristup k typum byl pres type() a je stale nutny u Python programu, ktere maji byt funkcni pod obema verzemi Pythonu.Mě mučí tyhle slovokolotoče: v Pythonu se objekt vytváří pomocí slova class, a na jeho jméno se tážeme slovem type. Uff.
Na jmeno tridy se ptame pres x.__class__.__name__. Jestli je objekt instanci (pod)tridy se ptame pomoci isinstance(). type() se pro tyto ucely pouzivat nedoporucuje, rozhodne ne v Pythonu 3, kde se semantika te funkce dost zmenila.
Pokrocilou zajimavosti je, ze type() jde vyuzit i k definici datoveho typu bez pouziti trid. Tudiz kdyby Kadet chtel, mohl by implementovat onen priklad objektu s dicty bez class, jen by to nebylo tak prehledne.
A = type('A', (), {})
# je stejne
class A:
pass
Pravda, v Pythonun 3 uz i cislo ma datovy typ tridu int.Pokrocilou zajimavosti je, ze type() jde vyuzit i k definici datoveho typu bez pouziti trid. Tudiz kdyby Kadet chtel, mohl by implementovat onen priklad objektu s dicty bez class, jen by to nebylo tak prehledne.
Přesněji, type vytvoří třídu bez klíčového slova class. Slovem třída bývají označovány i datové typy obecně. Datové typy jsou objekty typu type.Kód: [Vybrat]A = type('A', (), {})
# je stejne
class A:
pass
~ $ python
Python 3.7.2 (default, Dec 28 2018, 01:00:42)
[Clang 7.0.2 (https://android.googlesource.com/toolchain/clang 003100370607242d on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> type(0)
<class 'int'>
>>>
~ $ python2
Python 2.7.15 (default, Sep 23 2018, 14:53:40)
[GCC 4.2.1 Compatible Android (4751641 based on r328903) Clang 7.0.2 (https://a on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> type(0)
<type 'int'>
>>>