Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: nm 03. 05. 2016, 12:40:21
-
Začal jsem se učit Python. Ale vývoj jde dopředu tak rychle, že neustále vznikají další a další programovací jazyky a technologie. A tak jsem si položil otázku, jestli má Python budoucnost.
Takže se ptám: Má PYTHON budoucnost?
-
Podle mě se ti znalost Pythonu neztratí. Ale taky asi záleží na oboru.. Osobně bych s nim extendil třeba C, ale pro C++ bych spíš použil AngelScript. Na samostatný scripty se určitě taky hodí, i když na Linuxu spíš použiješ Bash. Na webu se používá, ale mě se tam nelíbí, na menší stránky bych použil PHP/Nette, na něco většího asi Go, kterej už má celkem fajn knihovny, líbí se mi framework Beego.
Toto jsou mé názory, nikomu je nevnucuji, případné protiargumenty uvítám.
-
Já se začal učit python tento rok a jedeme v něm backend pro naše appky a musím říct, že skvělý.
Django je skvělý a python má spoustu frameworků.
To, co jsme jinde dělali týden, jsme díky pythonu a jeho frameworkům udělali za den.
Samozřejmě sám nevím, jak to bude s Pythonem do budoucna, ale myslím, že se jnetak neztratí. To už spíš PHP.
-
Nejsou jen weby, ale taky systémové věci, vědecké výpočty,…
-
Python používám tam, kde Bash už nestačí. Výkonem, datovými typy a strukturami, objektovostí, knihovnami, ... Python je také skvělým jazykem na prototypování. Jeho schopnosti bývají často podceňovány, ale umí toho opravdu hodně.
Python MÁ budoucnost.
-
budoucnost je perl 6
-
Budoucnost patří aluminiu.
-
Osobne bych se na python vykaslal.
Na male skriptiky pouzivam BASH.
Na slozitejsi skriptiky Perl.
Na veci ktere musi bezet trochu slusne rychle commandline Javu.
Na male intranetove veci Javu/JSF2+Primefaces na Jettyne, Hibernate mapping (nativni, nemam rad JQL) + obcas Spring. Nebo misto Hibernatu nasadit Elasticsearch/Apache Lucene.
Na vetsi spolupracujici veci Javu + Karaf OSGi container, ve kterem mam Apache Camel, Apache CXF a Apache ActiveMQ.
Na opravdove weby se chci naucit AngularJS (frontend) v kooperaci se Spring MVC. Kamosi maji dobre zkusenosti s Twitter Bootstrap.
Plnotucne GUI aplikace nedelam, asi bych ale pouzil Javu FX.
Dnesni programovani je hlavne o frameworkach - a zdaleka nejvyssi nabidku mas v Jave. Vsecko pouzivane navic vystavene primo na MavenCentral. Staci slusne definovat pom.xml, devops prostredi se sestavi samo. Vcetne napr embedded jettyn na Unit testy a mockovani.
Parkrat jsem se dival na vselisjake ty Pythony a Ruby a opravdu jsem nenasel duvod, proc to pouzivat. Leda snad to Ruby se nyni casto pouziva jako script language uvnitr JVM (JRuby knihovna).
Jak ma vypadat elegantni jazyk vymysleli panove Kerninghan a Ritchie, vse co za neco stoji, jsou variace na ne.
Navic Pythoni napad formatovat kod newlines mi prijde podobne pritroubly, jako VisualBasic.
Python mi prijde jako vyhasle hype, ktery castecne nahradil zabordeleny Perl (kde do CPANu muze prispivat svymi vyplody kazdy, kdo na do zadeke diru a pak to tak vypada).
Dnes se hypuje funkcionalni programovani, aneb jak resit problemy, kdyz nechapu OOP, Java 8 lambda je mi malo, nevim co je Spring IoC a o OSGi jsem neslysel.
-
Podla mojho nazoru je otazka polozena uplne zle..
Kazdy lepsi systemak s algoritmickym myslenim by mal byt schopny operativne pouzivat akykolvek jazyk po osvojeni si syntaxe..
Cize urcite sa zide ovladat zaklady pythonu, vediet syntax a princip na akom funguje..Aj ked to nebudes pouzivat niekolko rokov tak v hlave to stale budes mat a ked to budes potrebovat tak sa do neho dostanes velmi rychlo...
Ja som naprilkad nikdy nerobil v C# ale potreboval som napisat jednu vec v tom jazyku a za 2 dni som si metodou pokus omyl vyskladal funkcny "program".. Takisto php a jquery..Nikdy som v tom nerobil ale mal som za ulohu urobit web ktory bude robit toto a toto a za 2 dni bol hotovy..
-
Jsou dva pohledy jak se na to dívat (osobně používám Python přes 10 let).
Python je snadno naučitelný jazyk, se spoustou knihoven, a pokud v něm člověk píše rozumně, tak i relativně snadno čitelný a spravovatelný.
Nevýhody Pythonu plynou z jeho výhod - častý přístup je "včera jsem si otevřel tutorial, dneska jsem udělal super appku na evidenci žížal a zítra v tom uděláme celokorporátní aplikaci pro tisíce zákazníků". V kombinaci s přístupem "zkusíme to takhle, když to nebude fungovat tak to předěláme" je Python recept na neštěstí. Díky tomu, že neexistuje vynutitelnost rozhraní, neexistence private/internal a spousta lidí má potřebu dělat prasárny typu "přes inspect.getouterframes zjistíme kdo funkci volá a podle toho se budeme chovat", dneska se už snažím Pythonu vyhnout (a to jsem ho jeden čas dost vehementně propagoval).
Jinými slovy - na prototyp je skvělý, na jednorázové admin skripty taky. Na kritické aplikace, kde je riziko že se bude používat i za rok, dva, tak rozhodně ne.
-
Jsou dva pohledy jak se na to dívat (osobně používám Python přes 10 let).
Python je snadno naučitelný jazyk, se spoustou knihoven, a pokud v něm člověk píše rozumně, tak i relativně snadno čitelný a spravovatelný.
Nevýhody Pythonu plynou z jeho výhod - častý přístup je "včera jsem si otevřel tutorial, dneska jsem udělal super appku na evidenci žížal a zítra v tom uděláme celokorporátní aplikaci pro tisíce zákazníků". V kombinaci s přístupem "zkusíme to takhle, když to nebude fungovat tak to předěláme" je Python recept na neštěstí. Díky tomu, že neexistuje vynutitelnost rozhraní, neexistence private/internal a spousta lidí má potřebu dělat prasárny typu "přes inspect.getouterframes zjistíme kdo funkci volá a podle toho se budeme chovat", dneska se už snažím Pythonu vyhnout (a to jsem ho jeden čas dost vehementně propagoval).
Jinými slovy - na prototyp je skvělý, na jednorázové admin skripty taky. Na kritické aplikace, kde je riziko že se bude používat i za rok, dva, tak rozhodně ne.
Prasit se dá v jakémkoliv jazyce, to co ty popisuješ je problém jakéhokoliv jazyka. Jinak souhlas.
-
Prasit se sice dá v jakémkoliv jazyce, ale jazyky se silnou typovou kontrolou, const, private/internal a interfacy celkem hodně omezují místa kde je možné něco zkazit. Pokud napíšu framework třeba v C# nebo v Javě, tak ostatní vývojáři sice mohou prasit, ale dokud implementují předem dané interfacy tak mě to ani tolik trápit nemusí, a na zbytek problémů se přijde při integračních testech (nebo aspoň na většinu z nich).
Díky monkey-patchingu je sice možné velmi rychle něco dobastlit, ale pak se i z dobře navrženého projektu postupným přidáváním podobných hacků stává neudržovatelný moloch.
Další problém je s výkonem - už jen z návrhu Pythonu plyne že jakákoliv operace (klidně i plus, minus) může mít vedlejší efekty a tím pádem to co dělá jinde kompilátor (např. common subexpression elimination) se musí dělat v Pythonu ručně. Jsou lidé co se ptají (pomalé) databáze na totéž číslo v několikrát vnořeném cyklu, a pak se diví že na výsledek čekají desítky minut nebo i několik hodin.
Python je celkem hezký jazyk s poměrně dost nedostatky, a pokud by nebylo Django, NumPy, pandas a IPython/Jupyter, byl by už dávno mrtvý (můj názor).
Prasit se dá v jakémkoliv jazyce, to co ty popisuješ je problém jakéhokoliv jazyka. Jinak souhlas.
-
Prasit se sice dá v jakémkoliv jazyce, ale jazyky se silnou typovou kontrolou, const, private/internal a interfacy celkem hodně omezují místa kde je možné něco zkazit...
Python má silnou typovou kontrolu.
Pokud máš dobře napsané testy pro skripty v Pythonu nebo i v PHP, tak typovou kontrolu kompilátoru nepotřebuješ.
-
Budoucnost patří aluminiu.
jj, to mě taky napadlo :-)
-
Prasit se sice dá v jakémkoliv jazyce, ale jazyky se silnou typovou kontrolou, const, private/internal a interfacy celkem hodně omezují místa kde je možné něco zkazit. Pokud napíšu framework třeba v C# nebo v Javě, tak ostatní vývojáři sice mohou prasit, ale dokud implementují předem dané interfacy tak mě to ani tolik trápit nemusí, a na zbytek problémů se přijde při integračních testech (nebo aspoň na většinu z nich).
Díky monkey-patchingu je sice možné velmi rychle něco dobastlit, ale pak se i z dobře navrženého projektu postupným přidáváním podobných hacků stává neudržovatelný moloch.
Další problém je s výkonem - už jen z návrhu Pythonu plyne že jakákoliv operace (klidně i plus, minus) může mít vedlejší efekty a tím pádem to co dělá jinde kompilátor (např. common subexpression elimination) se musí dělat v Pythonu ručně. Jsou lidé co se ptají (pomalé) databáze na totéž číslo v několikrát vnořeném cyklu, a pak se diví že na výsledek čekají desítky minut nebo i několik hodin.
Python je celkem hezký jazyk s poměrně dost nedostatky, a pokud by nebylo Django, NumPy, pandas a IPython/Jupyter, byl by už dávno mrtvý (můj názor).
Prasit se dá v jakémkoliv jazyce, to co ty popisuješ je problém jakéhokoliv jazyka. Jinak souhlas.
Jak zmiňuje Kit, testy. Které ale na druhou stranu nejsou povinné, čili o krok blíž k prasení a možnosti chyb, když testy nejsou. Nicméně i to není vlastně tolik pravda, ve firmách které to s Pythonem myslí vážně se bez testů neobejdeš.
Pokud je někde problém s výkonem, i python se dá optimalizovat, je toho plnej google a i fajn blogy na dropboxu...
Co se týče budoucnosti... Tu těžko odhadnout, ale vzhledem k tomu, že je v něm napsáno mraky ultilit, je před instalován prakticky na všech distribucích a má v základu plnohodnotné knihovny, s kterejma uděláš dost věcí bez nutnosti vymejšlet kolo, či něco stahovat... Zas tak černě bych to neviděl a nemyslím si že ho nad vodou drží jen Django, NumPy, pandas a IPython/Jupyter :-)
-
"přes inspect.getouterframes zjistíme kdo funkci volá a podle toho se budeme chovat"
Co navrhujete? Zakázat to? Co všechno byste zakázal? Když se Vám nějaká funkcionalita nelíbí, tak jí nepoužívejte.
Zrovna tahle funkce má praktická použití.
-
Jak zmiňuje Kit, testy. Které ale na druhou stranu nejsou povinné, čili o krok blíž k prasení a možnosti chyb, když testy nejsou. Nicméně i to není vlastně tolik pravda, ve firmách které to s Pythonem myslí vážně se bez testů neobejdeš.
Pokud je někde problém s výkonem, i python se dá optimalizovat, je toho plnej google a i fajn blogy na dropboxu...
Pak je samozřejmě taky možnost že testy jsou (dokonce jich je hodně), ale jsou k ničemu. Pokud se budeme bavit o korporacích tak nesmíme zapomenout na code reviews, že... které jsou k ničemu pokud kód schvalují lidé kteří neví co provádí a berou code review jenom jako něco co jim brání commitovat.
Ano, Python jde optimalizovat a docela dobře, jediné co jsem tvrdil je že Python sám o sobě optimalizace neprovádí (ve smyslu kompilovaných jazyků).
Co navrhujete? Zakázat to? Co všechno byste zakázal? Když se Vám nějaká funkcionalita nelíbí, tak jí nepoužívejte.
Zrovna tahle funkce má praktická použití.
Prakticky se to dá použít možná pro ladění, ale výstup funkce má být dán jejími vstupy, ne kontextem ve kterém je volána. Já tuhle funkcionalitu nepoužívám, ale najde se dost lidí kteří ano (v produkčním kódu) a jakýkoliv refaktoring je pak hrozně složitý.
-
Jak zmiňuje Kit, testy. Které ale na druhou stranu nejsou povinné, čili o krok blíž k prasení a možnosti chyb, když testy nejsou. Nicméně i to není vlastně tolik pravda, ve firmách které to s Pythonem myslí vážně se bez testů neobejdeš.
Pokud je někde problém s výkonem, i python se dá optimalizovat, je toho plnej google a i fajn blogy na dropboxu...
Pak je samozřejmě taky možnost že testy jsou (dokonce jich je hodně), ale jsou k ničemu. Pokud se budeme bavit o korporacích tak nesmíme zapomenout na code reviews, že... které jsou k ničemu pokud kód schvalují lidé kteří neví co provádí a berou code review jenom jako něco co jim brání commitovat.
Ano, Python jde optimalizovat a docela dobře, jediné co jsem tvrdil je že Python sám o sobě optimalizace neprovádí (ve smyslu kompilovaných jazyků).
Co navrhujete? Zakázat to? Co všechno byste zakázal? Když se Vám nějaká funkcionalita nelíbí, tak jí nepoužívejte.
Zrovna tahle funkce má praktická použití.
Prakticky se to dá použít možná pro ladění, ale výstup funkce má být dán jejími vstupy, ne kontextem ve kterém je volána. Já tuhle funkcionalitu nepoužívám, ale najde se dost lidí kteří ano (v produkčním kódu) a jakýkoliv refaktoring je pak hrozně složitý.
Viděl jsem použití pro implementaci dynamického scopování. Něco jako local v perlu.
-
budoucnost je perl 6
Tam je jedina otazka ci perl 6 bude nekdy soucasnost nebo ne :)
-
Takže se ptám: Má PYTHON budoucnost?
Urcite ano - ma buducnost.
Python je super jazyk - battery included, ak potrebujes rychlo vyriesit nejaky problem: napr. reporty z databazy, spracovanie textu, generovanie kodu na zaklade dat ... atd.
Ja som s nim zacal pred vyse 10 rokmi a napisal som v nom aj nejake utility, ktore u nas vo firme pouzivaju vyvojari doteraz, pretoze nikto nenasiel silu urobit nieco lepsie v Jave :-)
Z mojej strany jedina nevyhoda je povinne odsadzovania riadkov.
Na prvy pohlad to sice zvysuje citatelnost, ale treba si dat pozor aby sa nepomiesali medzery s tabulatormi. Mne sa to stalo ked som skripty robil aj v praci aj doma, pretoze v praci som mal inac nastaveny editor (vim) ako doma. Zistil som to az po rokoch, ked som sice fungujuce zdrojaky otvoril v inom editore a bolo to zle odsadene raz tabulatory a raz medzery. Fungovalo to sice, ale pre vlastne uspokojenie som napisal script ktory formatovanie opravil.
Kazdopadne sa nauc nejaky main stream skriptovaci jazyk: perl, python, ruby. Rozsiri ti to obzor a zvysi produktivitu. Uvidis, ze to ma oproti Jave vyhodu hlavne v rychlosti vyvoja a nepotrebujes k tomu ani ziadne vyvojove prostredie, staci dobry editor (ako vim). V praxi je to tak, ze kym javista este len bude kreslit UML diagramy, tak pythonista (alebo perlista) ma uz ulohu davno hotovu ...
To ze tu niekto pise ze nejde refaktoring je totalna blbost. Skriptovacie jazyky su urcene na mensie veci a ak napises program dobre modularne nepotrebujes ho spravidla nikdy refaktorovat. Niektori Javisti su prilis zviazani s vyvojovym prostredim a preto pre mna neupotrebitelni. Poznam ludi ktori nie su ochotni robit v eclipse, ale iba v IntelliJ IDEA. Taketo typky fakt nemam rad.
Na druhej strane skriptovacie jazyky sa nepouzivaju na enterprise aplikacie, napr. u nas vo firme pouzivame iba Javu a COBOL.
Zaver:
Dobry programator nema problem naucit sa rychlo nejaky iny jazyk. Okrem enterprise jazyka sa nauc pouzivat aj skriptovacie utility ako bash, awk, perl, python, ruby ... vyznamne ti to zlahci zivot.
-
... bych spíš použil AngelScript ...
Toto mi pripada ako vyplody bujnej fantazie. O tom jazyku som nikdy nepocul a podla mna nemoze mat zdaleka take kniznice ako Python, t.j. ani uplatnenie.
-
Python je celkem hezký jazyk s poměrně dost nedostatky, a pokud by nebylo Django, NumPy, pandas a IPython/Jupyter, byl by už dávno mrtvý (můj názor).
To je totalna akademicka blbost, NumPy patri tak na (vysoke) skoly.
Tie moduly som nikdy nepouzil, ale pouzil som napriklad moduly na pristupy do databazy, parsovanie XML, generovanie PDF, ... atd.
-
Dnesni programovani je hlavne o frameworkach - a zdaleka nejvyssi nabidku mas v Jave.
Zalozit aplikacie na open source frameworkoch je kamen urazu. Potom ked budes potrebovat update na aktualny framework uvidis kolko ta to bude stat.
Kedysi vsetci nadavali na stare monoliticke COBOL aplikacie. Ukazuje sa ale, ze tie boli uplne idealne, neboli zavisle na nicom, na ziadnych frameworkoch. Raz sa to naprogramovalo a potom to bezalo s malymi upravami dalsich 20 rokov ...
... Unit testy a mockovani ...
To je tiez ako kedy. Ak mas kvalifikovanych programatorov a testerov, ktori sa vyznaju v problematike tak to spravidla nepotrebujes. V tom pripade je to iba strata casu.
Casto sa za tymi poziadavkami skryvaju len paraziti, ktori sa tym zivia - napriklad rozni test a release manageri.
Ale samozrejme ale outsourcujes a programuju ti to niekde v Indii tak to nutne potrebujes.
Dnes se hypuje funkcionalni programovani
Myslim, ze toto sa snazi ujat uz niekolko dekad, ale je to pre beznych programatorov dost nezrozumitelne, takze sa to neujme.
-
To je tiez ako kedy. Ak mas kvalifikovanych programatorov a testerov, ktori sa vyznaju v problematike tak to spravidla nepotrebujes. V tom pripade je to iba strata casu.
Ztrátou času je, když ten, kdo píše testy je někdo jiný než ten, kdo píše produkční kód. Ten test pak nemáš šanci spustit třeba 20× za hodinu. Když obojí píšeš sám, tak to zvládneš naprosto v pohodě i častěji.
-
To je tiez ako kedy. Ak mas kvalifikovanych programatorov a testerov, ktori sa vyznaju v problematike tak to spravidla nepotrebujes. V tom pripade je to iba strata casu.
Ztrátou času je, když ten, kdo píše testy je někdo jiný než ten, kdo píše produkční kód. Ten test pak nemáš šanci spustit třeba 20× za hodinu. Když obojí píšeš sám, tak to zvládneš naprosto v pohodě i častěji.
Problemom je, zu programator sa uolne nevyzna v odbornej (produkcnej) problkematike a ani sa tym nechce hlbsie zaoberat, pretoze ho to nebavi.
-
Prasit se sice dá v jakémkoliv jazyce, ale jazyky se silnou typovou kontrolou, const, private/internal a interfacy celkem hodně omezují místa kde je možné něco zkazit...
Python má silnou typovou kontrolu.
Teoreticky ano, prakticky je k ničemu.
Pokud máš dobře napsané testy pro skripty v Pythonu nebo i v PHP, tak typovou kontrolu kompilátoru nepotřebuješ.
Ano, tedy zbytečná práce navíc.
-
Dnesni programovani je hlavne o frameworkach - a zdaleka nejvyssi nabidku mas v Jave.
Zalozit aplikacie na open source frameworkoch je kamen urazu. Potom ked budes potrebovat update na aktualny framework uvidis kolko ta to bude stat.
Kedysi vsetci nadavali na stare monoliticke COBOL aplikacie. Ukazuje sa ale, ze tie boli uplne idealne, neboli zavisle na nicom, na ziadnych frameworkoch. Raz sa to naprogramovalo a potom to bezalo s malymi upravami dalsich 20 rokov ...
Máš tam logickou chybu: Co dělali vývojáři COBOL aplikace, když potřebovali updatovat? Co brání dnešní aplikaci, aby si zmrazila verzi FW kterou používá?
-
Pokud máš dobře napsané testy pro skripty v Pythonu nebo i v PHP, tak typovou kontrolu kompilátoru nepotřebuješ.
Ano, tedy zbytečná práce navíc.
Skutečně si spousta programátorů dodnes myslí, že psaní testů je jen zbytečná práce navíc. Bohužel.
-
Pokud máš dobře napsané testy pro skripty v Pythonu nebo i v PHP, tak typovou kontrolu kompilátoru nepotřebuješ.
Ano, tedy zbytečná práce navíc.
Skutečně si spousta programátorů dodnes myslí, že psaní testů je jen zbytečná práce navíc. Bohužel.
A někteří programátoři si myslí, že když ty testy napíšou ručně, bude to efektivnější, než když jim ty testy vygeneruje kompilátor, že?
-
Uvidis, ze to ma oproti Jave vyhodu hlavne v rychlosti vyvoja a nepotrebujes k tomu ani ziadne vyvojove prostredie, staci dobry editor (ako vim). V praxi je to tak, ze kym javista este len bude kreslit UML diagramy, tak pythonista (alebo perlista) ma uz ulohu davno hotovu ...
Takze "profik" pythonista/perlista neco rychle splaca, nezdokumentuje nic a pokud se nedejboze zjisti, ze se zmenily pozadavky, tak se to musi zahodit a napsat znovu.
To ze tu niekto pise ze nejde refaktoring je totalna blbost. Skriptovacie jazyky su urcene na mensie veci a ak napises program dobre modularne nepotrebujes ho spravidla nikdy refaktorovat.
No, refaktoring je velky problem. Sam jsi to nevyvratil, jen jsi napsal, ze "dobry" programator nikdy nerefaktoruje. A nikdy se mu nezmeni zadani. A nikdy nebudou pribyvat nove vlastnosti. :D Takova utopie...
Niektori Javisti su prilis zviazani s vyvojovym prostredim a preto pre mna neupotrebitelni.
To, ze tobe se nehodi, asi nikoho moc nezajima.
Poznam ludi ktori nie su ochotni robit v eclipse, ale iba v IntelliJ IDEA. Taketo typky fakt nemam rad.
No, to bys me asi nemel rad, ja ostatne tebe asi taky ne. Kdyz clovek dela v jednom prostredi roky a zna vsechny potrebne zkratky a chovani, tak je hloupost prechazet na jine, v tomto pripade i objektivne mnohem horsi, prostredi. (A to ani nedelam v Jave.)
Doufam, ze zase nekdo nezacne tvrdit, jak Vim je skvele IDE pro Javu a pak pri prvni ukazce refaktorovani z opravdovem IDE sklapne a radsi se uz ani neozve.
Na druhej strane skriptovacie jazyky sa nepouzivaju na enterprise aplikacie, napr. u nas vo firme pouzivame iba Javu a COBOL.
Mozna si spatne vykladam slovo enterprise, ale napr. takovy Google nebo Quora maji (meli?) casti v Pythonu.
Zaver:
Dobry programator nema problem naucit sa rychlo nejaky iny jazyk. Okrem enterprise jazyka sa nauc pouzivat aj skriptovacie utility ako bash, awk, perl, python, ruby ... vyznamne ti to zlahci zivot.
Celkem souhlas. Naucit/zkusit si alespon zakladny popsanych je urcite dobre. Alespon pak clovek vi, az bude potrebovat neco automatizovat, jaky nastroj by se na to asi mohl hodit.
-
Pokud máš dobře napsané testy pro skripty v Pythonu nebo i v PHP, tak typovou kontrolu kompilátoru nepotřebuješ.
Ano, tedy zbytečná práce navíc.
Skutečně si spousta programátorů dodnes myslí, že psaní testů je jen zbytečná práce navíc. Bohužel.
A někteří programátoři si myslí, že když ty testy napíšou ručně, bude to efektivnější, než když jim ty testy vygeneruje kompilátor, že?
:D ;D ;D
Osobne bych cokoliv v dynamicky typovanem jazyce, co ma vice nez par desitek az stovek radku kodu, nepsal. Delam ted v JavaScriptu, jsem na par tisicich (navic celkem pouziva FP pristup a to s ES6 je hodne usporne), testy mi nedovolili a muzu rict, ze refaktoring pomalu cehokoliv je vzdy opravdu zazitek. Vzdy nasleduje smrst bug reportu. No, dal bych prednost automatickemu testovani, ale co nadelam :/.
-
Dobrý programátor by měl být schopný vývoje app i v nano, vi etc.... ;-)
IDE je jen práci ulehčující nadstavba :-)
-
Dobrý programátor by měl být schopný vývoje app i v nano, vi etc.... ;-)
IDE je jen práci ulehčující nadstavba :-)
Schopny mozna, ale proc by v tom mel chtit delat?
Navic ta efektivita by byla uboha - bez navigace (orientace ve stovkach trid musi byt fakt terno), refaktorovani (i hloupe prejmenovani jedne metody na desitkach mist muze trvat hodiny [nejlepe pokud se stejne jmenuji i metody z jinych trid], zatimco v poradnem IDE je to na par vetrin), debugovani, ... Pokud firma nekoho nuti psat v Jave ve Vimu/Nano, tak jsou teda solidne padli na hlavu.
-
Dobrý programátor by měl být schopný vývoje app i v nano, vi etc.... ;-)
IDE je jen práci ulehčující nadstavba :-)
Schopny mozna, ale proc by v tom mel chtit delat?
Navic ta efektivita by byla uboha - bez navigace (orientace ve stovkach trid musi byt fakt terno), refaktorovani (i hloupe prejmenovani jedne metody na desitkach mist muze trvat hodiny [nejlepe pokud se stejne jmenuji i metody z jinych trid], zatimco v poradnem IDE je to na par vetrin), debugovani, ... Pokud firma nekoho nuti psat v Jave ve Vimu/Nano, tak jsou teda solidne padli na hlavu.
Vsak jsi to napsal sam :-)
Napovidani, ulehcovani, psani kusu kodu za Tebe :-) K tomu je IDE dobre ano :-)
Proto taky kazdy "programator" musi jedine delat v IDE :-)
-
Dobrý programátor by měl být schopný vývoje app i v nano, vi etc.... ;-)
IDE je jen práci ulehčující nadstavba :-)
Schopny mozna, ale proc by v tom mel chtit delat?
Navic ta efektivita by byla uboha - bez navigace (orientace ve stovkach trid musi byt fakt terno), refaktorovani (i hloupe prejmenovani jedne metody na desitkach mist muze trvat hodiny [nejlepe pokud se stejne jmenuji i metody z jinych trid], zatimco v poradnem IDE je to na par vetrin), debugovani, ... Pokud firma nekoho nuti psat v Jave ve Vimu/Nano, tak jsou teda solidne padli na hlavu.
Vsak jsi to napsal sam :-)
Napovidani, ulehcovani, psani kusu kodu za Tebe :-) K tomu je IDE dobre ano :-)
Proto taky kazdy "programator" musi jedine delat v IDE :-)
Ano, kazdy profesionalni programator v Jave (a minimalne v jakemkoliv statickem jazyce) musi jedine delat v IDE. V opacnem pripade budto "okrada" zamestnavatele nebo sebe, v kazdem pripade to ukazuje na jeho (o vyhazov rikajici si) neschopnost zvolit spravny nastroj ;).
-
ftp://
Skutečně si spousta programátorů dodnes myslí, že psaní testů je jen zbytečná práce navíc. Bohužel.
A někteří programátoři si myslí, že když ty testy napíšou ručně, bude to efektivnější, než když jim ty testy vygeneruje kompilátor, že?
Žádný kompilátor nedokáže vygenerovat všechny potřebné testy.
-
No spíš každý "opravdový programátor" dělá ve vimu :-)
-
ftp://Skutečně si spousta programátorů dodnes myslí, že psaní testů je jen zbytečná práce navíc. Bohužel.
A někteří programátoři si myslí, že když ty testy napíšou ručně, bude to efektivnější, než když jim ty testy vygeneruje kompilátor, že?
Žádný kompilátor nedokáže vygenerovat všechny potřebné testy.
Ale dokáže vygenerovat nepotřebné testy, proto taky vznikly a vznikají dynamické jazyky :-)
-
Dobrý programátor by měl být schopný vývoje app i v nano, vi etc.... ;-)
IDE je jen práci ulehčující nadstavba :-)
Schopny mozna, ale proc by v tom mel chtit delat?
Navic ta efektivita by byla uboha - bez navigace (orientace ve stovkach trid musi byt fakt terno), refaktorovani (i hloupe prejmenovani jedne metody na desitkach mist muze trvat hodiny [nejlepe pokud se stejne jmenuji i metody z jinych trid], zatimco v poradnem IDE je to na par vetrin), debugovani, ... Pokud firma nekoho nuti psat v Jave ve Vimu/Nano, tak jsou teda solidne padli na hlavu.
Pokud si někdo pod pojmem "refaktorování" představuje jen přejmenování metody na "desítkách míst", tak to bude pěkná tragédie. Nehledě k tomu, že programátoři, kteří pracují na těch "desítkách míst" ti jistě poděkují.
-
Pokud si někdo pod pojmem "refaktorování" představuje jen přejmenování metody na "desítkách míst", tak to bude pěkná tragédie.
Snad nejtrapnejsi forma refaktorovani, velmi casta. Pokud tohle, u staticky typovaneho jazyka, neni editor schopny provest, tak to neni IDE. Tragedie je, kdyz si nekdo mysli, ze to nikdy nebude potreba. Pak nazvy metod, poli nebo celych trid neodpovidaji opravdove funkcnosti nebo dokonce ani typu a to je tragedie.
Videl jsem takto bastlena reseni, kde byl refaktoring sproste slovo. Vzdy to skonci tak, ze se to musi zahodit, protoze se v tom nikdo nevyzna, ani tvurci tech skvostu.
Nehledě k tomu, že programátoři, kteří pracují na těch "desítkách míst" ti jistě poděkují.
No, tak pokud se neumim domluvit s ostatnimi, tak mi nic nepomuze. Je jedno jestli jde o prejmenovani jedne metody, nebo zmenu funkcnosti metody vedouci k rozbiti kodu ostatnim.
Svete div se, realita je, ze se bezne metody, promenne, tridy i pole prejmenovavaji. Pokud si opravdu stale myslite, ze ani prejmenovani metody nikdy nepouzijete, tak musite delat na smesne malych projektech. Tohle by mozna fungovalo pri skvele specifikaci, skvelemu navrhu a konstatni specifikaci. Bohuzel ani jedno se bezne nevidi (nepochopeni druhe strany, zaplaceni za dalsi vlastnosti => zmena specifikace, setreni na analyze a navrhu atp.).
-
...
Svete div se, realita je, ze se bezne metody, promenne, tridy i pole prejmenovavaji. Pokud si opravdu stale myslite, ze ani prejmenovani metody nikdy nepouzijete, tak musite delat na smesne malych projektech. Tohle by mozna fungovalo pri skvele specifikaci, skvelemu navrhu a konstatni specifikaci.
Ja myslim, ze tohle je nejcastejsi duvod, proc pulka "programatoru" nechape potrebu refaktorovani. Pak se tady objevuji reci ve stylu: "refaktorovat potrebujou jenom luzri...", "IDE neni potreba...", "vim bohate staci na vse...", atd.
-
Pokud si někdo pod pojmem "refaktorování" představuje jen přejmenování metody na "desítkách míst", tak to bude pěkná tragédie.
Snad nejtrapnejsi forma refaktorovani, velmi casta. Pokud tohle, u staticky typovaneho jazyka, neni editor schopny provest, tak to neni IDE. Tragedie je, kdyz si nekdo mysli, ze to nikdy nebude potreba. Pak nazvy metod, poli nebo celych trid neodpovidaji opravdove funkcnosti nebo dokonce ani typu a to je tragedie.
Velmi častá? Vždyť změny názvu metod se nedělají každý den, ale jen výjimečně, s označením původní metody za deprecated a jejím přesměrováním do metody s novým názvem.
-
Vždyť změny názvu metod se nedělají každý den, ale jen výjimečně, s označením původní metody za deprecated a jejím přesměrováním do metody s novým názvem.
Pokud metody a názvy tříd měníš podle konzultací s koncovým uživatelem a o dané doméně toho moc nevíš, můžou se měnit docela často.
-
Vždyť změny názvu metod se nedělají každý den, ale jen výjimečně, s označením původní metody za deprecated a jejím přesměrováním do metody s novým názvem.
Pokud metody a názvy tříd měníš podle konzultací s koncovým uživatelem a o dané doméně toho moc nevíš, můžou se měnit docela často.
No jo, ale myslí někdo na ostatní projekty, které tu třídu používají? Ty se z toho musí zhroutit.
-
No jo, ale myslí někdo na ostatní projekty, které tu třídu používají? Ty se z toho musí zhroutit.
Název třídy a metod musí odpovídat doméně -- tedy já jsem na to přistoupil a můj život je jednodušší -- dřív jsem byl takový "kreativní" v pojmenovávání .) Pokud se to API ustálí, chápu tvoji poznámku, ale že bych nemusel přejmenovávat metody a třídy v rané fázi vývoje se mi osobně nestává. A že Python na tom není v tomhle ohledu dobře je pravda.
-
No jo, ale myslí někdo na ostatní projekty, které tu třídu používají? Ty se z toho musí zhroutit.
Název třídy a metod musí odpovídat doméně -- tedy já jsem na to přistoupil a můj život je jednodušší -- dřív jsem byl takový "kreativní" v pojmenovávání .) Pokud se to API ustálí, chápu tvoji poznámku, ale že bych nemusel přejmenovávat metody a třídy v rané fázi vývoje se mi osobně nestává. A že Python na tom není v tomhle ohledu dobře je pravda.
Je fakt, že někdy mám trochu problém, zda novozu metodu pojmenovat add() vs. insert(), resp. delete() vs. remove(), ale většinou to rychle vyřeším a dále ten název už nemám důvod měnit.
Veřejné metody často pojmenovávám podle rozhraní a tam už vůbec není důvod diskutovat o názvu metody. To se samozřejme Pythonu příliš netýká.
-
vědecké výpočty,…
no to je úplně jiný sektor.. icc, ifortran..
-
Překvapivě, Python budoucnost má, stejně tak i Ruby (podle některých umírající).
-
vědecké výpočty,…
no to je úplně jiný sektor.. icc, ifortran..
Ale není: https://www.scipy.org/
-
ftp://Skutečně si spousta programátorů dodnes myslí, že psaní testů je jen zbytečná práce navíc. Bohužel.
A někteří programátoři si myslí, že když ty testy napíšou ručně, bude to efektivnější, než když jim ty testy vygeneruje kompilátor, že?
Žádný kompilátor nedokáže vygenerovat všechny potřebné testy.
To je fakt. Než jen většinu, to raději žádný.
-
Ale dokáže vygenerovat nepotřebné testy, ...
Docela by mě zajímal příklad takového nepotřebného testu. Jen abych si udělal představu, co máte na mysli.
-
A někteří programátoři si myslí, že když ty testy napíšou ručně, bude to efektivnější, než když jim ty testy vygeneruje kompilátor, že?
Žádný kompilátor nedokáže vygenerovat všechny potřebné testy.
To je fakt. Než jen většinu, to raději žádný.
[/quote]
Žádný test nelze vygenerovat zcela automaticky. Do každého je minimálně nutné dosadit parametry, které žádný kompilátor sám nedosadí. A stejně se pak ty testy musí ručně opravovat.
-
Dnesni programovani je hlavne o frameworkach - a zdaleka nejvyssi nabidku mas v Jave.
Zalozit aplikacie na open source frameworkoch je kamen urazu. Potom ked budes potrebovat update na aktualny framework uvidis kolko ta to bude stat.
Kedysi vsetci nadavali na stare monoliticke COBOL aplikacie. Ukazuje sa ale, ze tie boli uplne idealne, neboli zavisle na nicom, na ziadnych frameworkoch. Raz sa to naprogramovalo a potom to bezalo s malymi upravami dalsich 20 rokov ...
To je hloupost.
Zatimco monoliticky COBOL plny bugu a bezpecnostnich der se bud necha deravy, nebo prepise zgruntu, v pripade FW se updatuje podle readme (casto automaticky), nebo se to necha derave na starem FW stejne jako ten COBOL. Tedy situace je MNOHEM lepsi.
Jinak ohledne budoucnosti Opensource FW, konkretne Apache Foundation verim mnohem vic, nez treba Oraclu, ktery se vykalel na Javu FX a dal ji do sveta, at se toho nekdo opensource chytne (a kdyz se nikdo nechytne, tak to zdechne), nebo treba MS, ktery zrusil Silverlight bez nahrady.
... Unit testy a mockovani ...
To je tiez ako kedy. Ak mas kvalifikovanych programatorov a testerov, ktori sa vyznaju v problematike tak to spravidla nepotrebujes. V tom pripade je to iba strata casu.
Casto sa za tymi poziadavkami skryvaju len paraziti, ktori sa tym zivia - napriklad rozni test a release manageri.
Ale samozrejme ale outsourcujes a programuju ti to niekde v Indii tak to nutne potrebujes.
Nesmysl, automaticke testy slouzi k tomu, aby se peridicky re-testoval kod pred kazdym commitem, tedy aby byli testeri usetreni opici prace a mohli se soustredit na dulezitejsi vec. Maven ma test phase primo ve svem build lifecyclu.
Co jsem videl vyvoj v realnych firmach, kde nejsou uplni matlaci, tak vesmes plati:
- Kod je v GITu a kazdy si hraje na svem forku
- lokalni buildy ridi Maven, ktery spousit Unit testy, Mock integracni testy (napr. Mockito), pripadne SeleniumHQ na E2E testy. Maven zaroven automaticky hlida unit test coverage, kazdy koder musi plne pokryt svuj kod testy, pripadne zduvodnit, proc to nejde.
- kdyz to lokalne proslo, muze koder mergovat do hlavniho branche GITu
- nad hlavnim branchem GITu se v Bamboo spousti nightbuildy (opet s hromadou testu), kdyz to spadne, Bamboo praskne, kdo to zku*rvil.
- jednou za cas se udela release, main branch se vystavi na lokalnim Nexusu jako maven artefact, vichni si updatujou pom.xml na tento novy artefarct a jede se dal.
Rozumny vyvoj bez automatickeho testovani je naprosty nesmysl.
-
Žádný test nelze vygenerovat zcela automaticky. Do každého je minimálně nutné dosadit parametry, které žádný kompilátor sám nedosadí. A stejně se pak ty testy musí ručně opravovat.
A co QuickCheck?
-
Žádný test nelze vygenerovat zcela automaticky. Do každého je minimálně nutné dosadit parametry, které žádný kompilátor sám nedosadí. A stejně se pak ty testy musí ručně opravovat.
A co QuickCheck?
To jsem zvědav, jak automaticky sám vygeneruje testy, když ještě nemáš ani jeden řádek cílového programu. Minimálně mu musíš vyjmenovat, co ten program (třída, modul, ...) musí umět. A to je také ruční práce.
-
Jasný, test bez kódu je nejlepší :D Můžeš je pouštět po večerech a třeba jednou dopsat i ten kód... obvykle to totiž funguje naopak, ale to nesmíš používat bastly jako Python nebo PHP.
-
Žádný kompilátor nedokáže vygenerovat všechny potřebné testy.
To je fakt. Než jen většinu, to raději žádný.
Žádný test nelze vygenerovat zcela automaticky. Do každého je minimálně nutné dosadit parametry, které žádný kompilátor sám nedosadí. A stejně se pak ty testy musí ručně opravovat.
I kdyby to byla pravda (jakože není) - no a?
-
Jasný, test bez kódu je nejlepší :D Můžeš je pouštět po večerech a třeba jednou dopsat i ten kód... obvykle to totiž funguje naopak, ale to nesmíš používat bastly jako Python nebo PHP.
No tak nejprve si v editoru nejprve napíši vedle sebe několik slov (obvykle 3-5) a nechám si z nich vygenerovat kostru třídy včetně lokálních atributů a testů. A to v PHP i Pythonu. Samozřejmě musím následně dopsat i parametry a očekávané výsledky testů, ale nevidím nic, co by mi nějaké IDE mohlo zefektivnit.
-
Žádný test nelze vygenerovat zcela automaticky. Do každého je minimálně nutné dosadit parametry, které žádný kompilátor sám nedosadí. A stejně se pak ty testy musí ručně opravovat.
A co QuickCheck?
To generuje pouze náhodná vstupní data. Testy musíte psát ručně. Nevím jak moc je to užitečné. Neprovádí to zbytečně moc nadbytečných testů? Většinou stačí otestovat okrajové případy a nějaká malá data.
-
Dobrý programátor by měl být schopný vývoje app i v nano, vi etc.... ;-)
IDE je jen práci ulehčující nadstavba :-)
Schopny mozna, ale proc by v tom mel chtit delat?
Navic ta efektivita by byla uboha - bez navigace (orientace ve stovkach trid musi byt fakt terno), refaktorovani (i hloupe prejmenovani jedne metody na desitkach mist muze trvat hodiny [nejlepe pokud se stejne jmenuji i metody z jinych trid], zatimco v poradnem IDE je to na par vetrin), debugovani, ... Pokud firma nekoho nuti psat v Jave ve Vimu/Nano, tak jsou teda solidne padli na hlavu.
Vsak jsi to napsal sam :-)
Napovidani, ulehcovani, psani kusu kodu za Tebe :-) K tomu je IDE dobre ano :-)
Proto taky kazdy "programator" musi jedine delat v IDE :-)
Ano, kazdy profesionalni programator v Jave (a minimalne v jakemkoliv statickem jazyce) musi jedine delat v IDE. V opacnem pripade budto "okrada" zamestnavatele nebo sebe, v kazdem pripade to ukazuje na jeho (o vyhazov rikajici si) neschopnost zvolit spravny nastroj ;).
Ono je to mozna spis opacne. Ted mam na mysli tu zavorku o staticky typovanem jazyce. Jelikoz napriklad v PHP, ve kterem v praci programujem, je IDE mnohem dulezitejsi nez jinde. To co nam PhpStorm umoznuje je opravdu k nezaplaceni. Z netypovaneho jazyka nam to umoznuje pracovat jako s typovanym a vetsina chyb je objevena mimo runtime. U kompilovanych (prekladanych to znamena pocitam jsem i javu atd) je vyhodou to ze spousta chyb je objevena behem prekladu, takze spousta chyb je odchycena jiz behem vyvoje i bez IDE. Ale u jazyku jako je PHP, Ruby ci Python je to horsi. Tam je dobre IDE opravdu prinosem.
Jinak jsem zastancem nazoru ze kvalitni IDE je dulezite. Osobne pouzivam VIM nekolik let, a sam jsem driv tvrdil ze IDE neni treba a VIM staci. Ale praxe ukazala ze kvalitni vyvojove prostredi ma sve vyhody :)
-
To ze tu niekto pise ze nejde refaktoring je totalna blbost. Skriptovacie jazyky su urcene na mensie veci a ak napises program dobre modularne nepotrebujes ho spravidla nikdy refaktorovat.
No, refaktoring je velky problem. Sam jsi to nevyvratil, jen jsi napsal, ze "dobry" programator nikdy nerefaktoruje. A nikdy se mu nezmeni zadani. A nikdy nebudou pribyvat nove vlastnosti. :D Takova utopie...
Ked sa ti zmeni zadanie tak slusne napisany skript rozsiris aj vo vime a nepotrebujes na to nejake skvele IDE na refaktorovanie.
Poznam ludi ktori nie su ochotni robit v eclipse, ale iba v IntelliJ IDEA. Taketo typky fakt nemam rad.
No, to bys me asi nemel rad, ja ostatne tebe asi taky ne. Kdyz clovek dela v jednom prostredi roky a zna vsechny potrebne zkratky a chovani, tak je hloupost prechazet na jine, v tomto pripade i objektivne mnohem horsi, prostredi. (A to ani nedelam v Jave.)
Doufam, ze zase nekdo nezacne tvrdit, jak Vim je skvele IDE pro Javu a pak pri prvni ukazce refaktorovani z opravdovem IDE sklapne a radsi se uz ani neozve.
To si ma asi zle pochopil. Ak raz v tyme pouzivame STS (https://spring.io/tools/sts), tak si snad nemyslis ze pre teba by sme extra kupovali licenciu IntelliJ IDEA, pretoze eclipse nevies alebo nechces pouzivat a pocuval by som zbytocne diskusie na temu eclipse vs IDEA. Clovek ktory sa nevie prisposobit ani takej malickosti ako je IDE je neprisposobivy a skor alebo neskor s nim budu aj dalsie problemy. S takymi typkami nebudeme stracat cas.
Zaver:
Dobry programator nema problem naucit sa rychlo nejaky iny jazyk. Okrem enterprise jazyka sa nauc pouzivat aj skriptovacie utility ako bash, awk, perl, python, ruby ... vyznamne ti to zlahci zivot.
Celkem souhlas. Naucit/zkusit si alespon zakladny popsanych je urcite dobre. Alespon pak clovek vi, az bude potrebovat neco automatizovat, jaky nastroj by se na to asi mohl hodit.
A tak som to aj myslel. Nechcel som porovnavat Java, C# vs. skriptovacie jazyky. Chcel som len povedat ze skriptovaci jazyk je vyborny doplnok a stoji za to sa ho naucit.
-
Videl jsem takto bastlena reseni, kde byl refaktoring sproste slovo. Vzdy to skonci tak, ze se to musi zahodit, protoze se v tom nikdo nevyzna, ani tvurci tech skvostu.
Tak si rozsir trochu obzor. Prihlas za COBOL juniora a uvidis programy, ktore refaktoring nepoznali a bezia aj 20 rokov.
Ja mam prave skusenost s tym, ze novy Javista sa chcel ukazat a zrefaktoroval tak aplikaciu ze ostatni nadavali, ze to mu nerozumeju.
-
Clovek ktory sa nevie prisposobit ani takej malickosti ako je IDE je neprisposobivy a skor alebo neskor s nim budu aj dalsie problemy. S takymi typkami nebudeme stracat cas.
Eclipse je sračka pro začátečníky. Ale je dobře, že vím, že někde hledají rovnou lopaty za 60 místo opravdu kvalitních lidí, kteří přesně vědí, co potřebují k práci. Pokud by mu vadil pomalý počítač a malý monitor, tak ho taky rovnou odmítnete, ne? By vám kazil lemplpartu :D
-
Tak si rozsir trochu obzor. Prihlas za COBOL juniora a uvidis programy, ktore refaktoring nepoznali a bezia aj 20 rokov.
Ja mam prave skusenost s tym, ze novy Javista sa chcel ukazat a zrefaktoroval tak aplikaciu ze ostatni nadavali, ze to mu nerozumeju.
Nebude to tym, ze to je spagetovy kod na ktory nikto nechce sahat a nikto do toho poriadne nevidi, iba tam vzdy dohackuje co treba? Btw 20 rokov to je 1996, to je dost cerstvy software :). Myslim ze to bude viac.
-
http://www.tiobe.com/tiobe_index
-
Clovek ktory sa nevie prisposobit ani takej malickosti ako je IDE je neprisposobivy a skor alebo neskor s nim budu aj dalsie problemy. S takymi typkami nebudeme stracat cas.
Eclipse je sračka pro začátečníky. Ale je dobře, že vím, že někde hledají rovnou lopaty za 60 místo opravdu kvalitních lidí, kteří přesně vědí, co potřebují k práci. Pokud by mu vadil pomalý počítač a malý monitor, tak ho taky rovnou odmítnete, ne? By vám kazil lemplpartu :D
Asi tak. Prijde me, ze mikrom pise o tech povestnych "lopatach". Ja osobne bych nemel problem odejit z firmy, pokud by me nutili pouzivat jine IDE, nez me vyhovuje. Delam v male firmicce a i tam me nabidli, ze to zacaluji. Nevim jak ve Springu, ale celkove je IntelliJ IDEA o hodne ficur napred pred Eclipsem. Pokud firma ma problem s tim poridit licenci za par tisic, tak to s ni jde z kopce a v takove IT firme bych teda ani nechtel delat.
Jiste, i u dynamicky typovanych jazyku je dobre IDE plus. Sam IntelliJ IDEA pouzivam na JavaScript a je to podstatne lepsi nez nejaky Sublime nebo Atom (naseptavani, odhady typu podle pouziti a JSDocu apod.). Ale refaktoring i toho hloupeho jmena vlastnosti je/muze byt problem, protoze je to proste dynamicky jazyk a IDE casto jen tipuje, ktere fieldy jsou opravdu stejne (dedene) a ktere se stejne jen jmenuji. V te vete me slo o to, ze kdyz ani u staticky typovanych jazyku editor nezvlada prejmenovani, tak to neni IDE. To bohuzel u dynamickych nemuze asi nikdy platit, pouze za urcitych podminek (nejake spravne anotace ci pouziti nepovinnych typu atp.).
-
...
Žádný kompilátor nedokáže vygenerovat všechny potřebné testy.
To je fakt. Než jen většinu, to raději žádný.
;D ;D ;D
-
...
Žádný kompilátor nedokáže vygenerovat všechny potřebné testy.
To je fakt. Než jen většinu, to raději žádný.
Jsem z tech odpovedi zmateny. Mel jsem pocit, ze BoneFlute psal o statickych vs dynamickych jazycich a pak to tvrzeni plati. U statickych snad kompilator kontroluje typy a tim padem neni potreba psat jakekoliv testy typu. Coz u dynamickych jazyku neplati a musi se hezky poctive psat kontroly typu a v podstate simulovat tak to, co dela prekladac u statickych jazyku.
-
...
Žádný kompilátor nedokáže vygenerovat všechny potřebné testy.
To je fakt. Než jen většinu, to raději žádný.
Jsem z tech odpovedi zmateny. Mel jsem pocit, ze BoneFlute psal o statickych vs dynamickych jazycich a pak to tvrzeni plati. U statickych snad kompilator kontroluje typy a tim padem neni potreba psat jakekoliv testy typu. Coz u dynamickych jazyku neplati a musi se hezky poctive psat kontroly typu a v podstate simulovat tak to, co dela prekladac u statickych jazyku.
Chápeš to tak jak jsem to myslel.
-
... Ja osobne bych nemel problem odejit z firmy, pokud by me nutili pouzivat jine IDE, nez me vyhovuje. Delam v male firmicce a i tam me nabidli, ze to zacaluji...
Jsem nastupoval do jedné firmy, a oni, že všichni použíají NetBeans. Ptal jsem se, zda je to povinné. Řekli ne, a tak jsem nastoupil a všichni jsme byli spokojení.
V jiné firmě měli tabulku, kde psali kdo všechno používá co za nástroje. Pro inspiraci. To se mi líbilo.
-
... Ja osobne bych nemel problem odejit z firmy, pokud by me nutili pouzivat jine IDE, nez me vyhovuje. Delam v male firmicce a i tam me nabidli, ze to zacaluji...
Jsem nastupoval do jedné firmy, a oni, že všichni použíají NetBeans. Ptal jsem se, zda je to povinné. Řekli ne, a tak jsem nastoupil a všichni jsme byli spokojení.
A keby povedali, ze musis tiez pouzivat NetBeans tak by si nenastupil ? :)
-
Osobně bych to bral jako hodně obrovský mínus, který by musel vyvážit dostatečný počet plusů. Mám totiž jenom jedny nervy.
-
... Jsem nastupoval do jedné firmy, a oni, že všichni použíají NetBeans. Ptal jsem se, zda je to povinné. Řekli ne, a tak jsem nastoupil a všichni jsme byli spokojení.
A keby povedali, ze musis tiez pouzivat NetBeans tak by si nenastupil ? :)
Pokud jde o me, tak ja bych asi opravdu nenastoupil. Vzhledem k tomu, ze namam rodinu, hypo, ani nic podobneho, tak radeji dam prednost pohodovejsi praci, ktera mne plne vyhovuje, ikdyby to bylo na ukor financi. Ve vetsim meste opravdu neni takovy problem najit hodne nabidek, tak proc si nevybrat poradne.
Osobně bych to bral jako hodně obrovský mínus, který by musel vyvážit dostatečný počet plusů. Mám totiž jenom jedny nervy.
+1
-
...
Žádný kompilátor nedokáže vygenerovat všechny potřebné testy.
To je fakt. Než jen většinu, to raději žádný.
Jsem z tech odpovedi zmateny. Mel jsem pocit, ze BoneFlute psal o statickych vs dynamickych jazycich a pak to tvrzeni plati. U statickych snad kompilator kontroluje typy a tim padem neni potreba psat jakekoliv testy typu. Coz u dynamickych jazyku neplati a musi se hezky poctive psat kontroly typu a v podstate simulovat tak to, co dela prekladac u statickych jazyku.
Kontrola typů je jen prkotina proti potřebnému množství dalších testů, které kompilátor neudělá a stejně se musí udělat ručně. A stejně kompilátor ani nezkontroluje všechny potřebné typy.
-
Trosku odbocim od temy. Vsetci tu basnite o testoch, ale aka je realita v pripade OS projektov? To iba ja narazim vzdy na nejaky, ktory testy nema vobec? Potom stiahnem C++ alebo Java projekt a tisicky testov. Chapem, ze to nie je chyba pythonu alebo perlu, ale treba byt realista a zvazit pri vybere jazyka, ci som fanusik test driven alebo nie (alebo napr ci existuju tooly, ktore mi vygeneruju kostru testov ked uz nemam cas pisat to rucne..).
-
Trosku odbocim od temy. Vsetci tu basnite o testoch, ale aka je realita v pripade OS projektov? To iba ja narazim vzdy na nejaky, ktory testy nema vobec? Potom stiahnem C++ alebo Java projekt a tisicky testov. Chapem, ze to nie je chyba pythonu alebo perlu, ale treba byt realista a zvazit pri vybere jazyka, ci som fanusik test driven alebo nie (alebo napr ci existuju tooly, ktore mi vygeneruju kostru testov ked uz nemam cas pisat to rucne..).
Asi si vybíráš špatné projekty, od špatných programátorů, neříkám že všecny testy maj, ale co sem potřeboval tak valná většina ano.
-
Pokud máš dobře napsané testy pro skripty v Pythonu nebo i v PHP, tak typovou kontrolu kompilátoru nepotřebuješ.
Ano, tedy zbytečná práce navíc.
Skutečně si spousta programátorů dodnes myslí, že psaní testů je jen zbytečná práce navíc. Bohužel.
A někteří programátoři si myslí, že když ty testy napíšou ručně, bude to efektivnější, než když jim ty testy vygeneruje kompilátor, že?
:D ;D ;D
Osobne bych cokoliv v dynamicky typovanem jazyce, co ma vice nez par desitek az stovek radku kodu, nepsal. Delam ted v JavaScriptu, jsem na par tisicich (navic celkem pouziva FP pristup a to s ES6 je hodne usporne), testy mi nedovolili a muzu rict, ze refaktoring pomalu cehokoliv je vzdy opravdu zazitek. Vzdy nasleduje smrst bug reportu. No, dal bych prednost automatickemu testovani, ale co nadelam :/.
Například takové Objective-C má dynamický runtime a přitom v něm vznikají projekty mající desítky tisíc řádek, takže jen o dynamickém typování to není.
-
Ono je to taky hodně o stylu psaní, o schopném linteru/type checkeru a v neposlední řadě o použitém IDE.
-
... Ja osobne bych nemel problem odejit z firmy, pokud by me nutili pouzivat jine IDE, nez me vyhovuje. Delam v male firmicce a i tam me nabidli, ze to zacaluji...
Jsem nastupoval do jedné firmy, a oni, že všichni použíají NetBeans. Ptal jsem se, zda je to povinné. Řekli ne, a tak jsem nastoupil a všichni jsme byli spokojení.
A keby povedali, ze musis tiez pouzivat NetBeans tak by si nenastupil ? :)
Obávám se, že nenastoupil. Pokud trvaj na takovéhle věci, tak to smrdí.
-
...
Žádný kompilátor nedokáže vygenerovat všechny potřebné testy.
To je fakt. Než jen většinu, to raději žádný.
Jsem z tech odpovedi zmateny. Mel jsem pocit, ze BoneFlute psal o statickych vs dynamickych jazycich a pak to tvrzeni plati. U statickych snad kompilator kontroluje typy a tim padem neni potreba psat jakekoliv testy typu. Coz u dynamickych jazyku neplati a musi se hezky poctive psat kontroly typu a v podstate simulovat tak to, co dela prekladac u statickych jazyku.
Kontrola typů je jen prkotina proti potřebnému množství dalších testů, které kompilátor neudělá a stejně se musí udělat ručně. A stejně kompilátor ani nezkontroluje všechny potřebné typy.
Záleží v jak blbém jazyce píšeš. Existují jazyky, který maj tak vymakanej systém typů, že se těžko vymejšlí, co ještě otestovat.
Největší fór je, že kdyby si opustil svůj dogmatickej svět, kde se testy píšou protože se píšou, tak by si objevil situace, kde testy jsou skutečně lepší než promakanej systém typů (za určitejch podmínek). Jenže to ti nechám jen jako hádanku. Zatím soudím, podle tvého vyjadřování, že netušíš :-P
-
A keby povedali, ze musis tiez pouzivat NetBeans tak by si nenastupil ? :)
Pokud jde o me, tak ja bych asi opravdu nenastoupil.
Obávám se, že nenastoupil. Pokud trvaj na takovéhle věci, tak to smrdí.
O starsich programatoroch sa zvyklo hovorit, ze su neprisposobivi a neschopni naucit sa nove veci, i ked ja som to nikdy nezazil. Mam kolegov ktori mozno za par rokov odidu do dochodku, ale nikto nikdy nepolemizoval o pouzitom IDE. O Vas predpokladam, ze mate este daleko do dochodku, tak preco taka neflexibilita, zavislost na jednom posratom IDE a neochota k troche namahy a prisposobeniu sa.
Ved v prvom rade je jak je projekt zaujimavy, jak ma posunie dalej a kolko prachov mi to hodi. Pouzite nastroje su podla mna asi tak na predposlednom mieste.
Ked mi takto povies, ze dokazes pouzivat iba jeden druh IDE tak predpokladam, ze ked budes mat zbuildovat nieco na command line , alebo napisat na to skript tak to nedas. Skratka vyzera to tak, ze si tvrdohlavy a budu s tebou skor alebo neskor nejake problemy.
IMHO, takymto pristupom si iba zatvaras dvere k praci v slusnej firme a k lukrativnemu jobu.
Ale neprekvapilo ma to, ocakaval som, ze to asi nejako takto dopadne. Toto spochybnovanie a filozovanie je typicka vlastnost nas Slovakov a Cechov. Kazdy sa tu nadrapuje ako majster sveta a najvacsi odbornik a vsecko ostane spochybnuje.
Toto napriklad v nemeckej firme nezazijes. Tam ked sa povie, ze toto je standard tak nikto o tom nediskutuje - a cuduj sa, ze sa tam zaraba 2x viac ako tu.
Takze asi sa mam na co tesit, ked moji starsi kolegovia sa rozhodnu odist do dochodku, s naborom mladsich rozmaznanych programatorov to bude asi o dost zlozitejsie ...
Alebo aby som konecne presiel na Intellij IDEA? Popravde robil som v tom nejake webservisy, ale pripada mi to oproti eclipse zbytocne zlozite a tazkopadne. Naposledy som mal verziu tusim 12 a kym nastartovala, mohol som si uvarit kavu. Ma to kopu funkcionality, ktoru nevyzivam a nepotrebujem a pokladam za zbytocne za to platit, ked eclipse je de facto standard a pouzivaju ho i nasi zahranicni partneri s ktorymi spolupracujeme. My v nasej firme pracujeme podla standardov, takze nepotrebujeme stale refaktorovat, ako vy ostatni kutili a freelanceri.
:)
Ale vsetko toto o com sa tu bavime je vlaste OT v tomto threade.
Pointa je v tom, ze ak vies iba Javu a nejake tvoje IDE, tak si ako zaba v studni. Myslis si ze to je cely svet. Preto sa nauc minimalne aj Python, alebo iny jazyk ... aby si trochu pochopil aj svet, ktory je okolo tvojej studne. Inac zostanes vzdy iba tou zabou v studni.
-
zavislost na jednom posratom IDE a neochota k troche namahy a prisposobeniu sa
Podle mě tady nejde až tak o závislost na jednom konkrétním IDE, ale čistě o to, že NetBeans je fakt ukrutná sračka. S jiným editorem bys nejspíš sklidil větší úspěchy.
-
A keby povedali, ze musis tiez pouzivat NetBeans tak by si nenastupil ? :)
Pokud jde o me, tak ja bych asi opravdu nenastoupil.
Obávám se, že nenastoupil. Pokud trvaj na takovéhle věci, tak to smrdí.
O starsich programatoroch sa zvyklo hovorit, ze su neprisposobivi a neschopni naucit sa nove veci, i ked ja som to nikdy nezazil. Mam kolegov ktori mozno za par rokov odidu do dochodku, ale nikto nikdy nepolemizoval o pouzitom IDE. O Vas predpokladam, ze mate este daleko do dochodku, tak preco taka neflexibilita, zavislost na jednom posratom IDE a neochota k troche namahy a prisposobeniu sa.
Ved v prvom rade je jak je projekt zaujimavy, jak ma posunie dalej a kolko prachov mi to hodi. Pouzite nastroje su podla mna asi tak na predposlednom mieste.
Ked mi takto povies, ze dokazes pouzivat iba jeden druh IDE tak predpokladam, ze ked budes mat zbuildovat nieco na command line , alebo napisat na to skript tak to nedas. Skratka vyzera to tak, ze si tvrdohlavy a budu s tebou skor alebo neskor nejake problemy.
IMHO, takymto pristupom si iba zatvaras dvere k praci v slusnej firme a k lukrativnemu jobu.
Ale neprekvapilo ma to, ocakaval som, ze to asi nejako takto dopadne. Toto spochybnovanie a filozovanie je typicka vlastnost nas Slovakov a Cechov. Kazdy sa tu nadrapuje ako majster sveta a najvacsi odbornik a vsecko ostane spochybnuje.
Toto napriklad v nemeckej firme nezazijes. Tam ked sa povie, ze toto je standard tak nikto o tom nediskutuje - a cuduj sa, ze sa tam zaraba 2x viac ako tu.
Takze asi sa mam na co tesit, ked moji starsi kolegovia sa rozhodnu odist do dochodku, s naborom mladsich rozmaznanych programatorov to bude asi o dost zlozitejsie ...
Alebo aby som konecne presiel na Intellij IDEA? Popravde robil som v tom nejake webservisy, ale pripada mi to oproti eclipse zbytocne zlozite a tazkopadne. Naposledy som mal verziu tusim 12 a kym nastartovala, mohol som si uvarit kavu. Ma to kopu funkcionality, ktoru nevyzivam a nepotrebujem a pokladam za zbytocne za to platit, ked eclipse je de facto standard a pouzivaju ho i nasi zahranicni partneri s ktorymi spolupracujeme. My v nasej firme pracujeme podla standardov, takze nepotrebujeme stale refaktorovat, ako vy ostatni kutili a freelanceri.
:)
Ale vsetko toto o com sa tu bavime je vlaste OT v tomto threade.
Pointa je v tom, ze ak vies iba Javu a nejake tvoje IDE, tak si ako zaba v studni. Myslis si ze to je cely svet. Preto sa nauc minimalne aj Python, alebo iny jazyk ... aby si trochu pochopil aj svet, ktory je okolo tvojej studne. Inac zostanes vzdy iba tou zabou v studni.
Rád bych tě upozornil na tvou tendenci vyvozovat závěry z naprosto nedostatečných údajů :-P
-
zavislost na jednom posratom IDE a neochota k troche namahy a prisposobeniu sa
Podle mě tady nejde až tak o závislost na jednom konkrétním IDE, ale čistě o to, že NetBeans je fakt ukrutná sračka. S jiným editorem bys nejspíš sklidil větší úspěchy.
Sračka nebo ne, ať si programátor vyvíjí v čem chce. Třeba ať fouká do motýlů.
Pro mě je důležitější že mu nemusím vysvětlovat základní věci, kód je dobrej a za rozumnej čas... člověk, kterej se za rok práce z gitem diví, že po `git stash pop` mu ten stash zmizí ze seznamu mě bude dráždit víc.
A firma která chce od vývojáře výsledky a přitom mu byrokraticky háže klacky pod nohy si zaslouží zemřít. Zatím jsem zažil, že mi dávali na výběr i systém, linux/win/os. Natož editor. Jste upadli, ne?!
-
...
Žádný kompilátor nedokáže vygenerovat všechny potřebné testy.
To je fakt. Než jen většinu, to raději žádný.
Jsem z tech odpovedi zmateny. Mel jsem pocit, ze BoneFlute psal o statickych vs dynamickych jazycich a pak to tvrzeni plati. U statickych snad kompilator kontroluje typy a tim padem neni potreba psat jakekoliv testy typu. Coz u dynamickych jazyku neplati a musi se hezky poctive psat kontroly typu a v podstate simulovat tak to, co dela prekladac u statickych jazyku.
Kontrola typů je jen prkotina proti potřebnému množství dalších testů, které kompilátor neudělá a stejně se musí udělat ručně. A stejně kompilátor ani nezkontroluje všechny potřebné typy.
Záleží v jak blbém jazyce píšeš. Existují jazyky, který maj tak vymakanej systém typů, že se těžko vymejšlí, co ještě otestovat.
Největší fór je, že kdyby si opustil svůj dogmatickej svět, kde se testy píšou protože se píšou, tak by si objevil situace, kde testy jsou skutečně lepší než promakanej systém typů (za určitejch podmínek). Jenže to ti nechám jen jako hádanku. Zatím soudím, podle tvého vyjadřování, že netušíš :-P
V kterých situacích je lepší testovat?
-
A keby povedali, ze musis tiez pouzivat NetBeans tak by si nenastupil ? :)
Pokud jde o me, tak ja bych asi opravdu nenastoupil.
Obávám se, že nenastoupil. Pokud trvaj na takovéhle věci, tak to smrdí.
O starsich programatoroch sa zvyklo hovorit, ze su neprisposobivi a neschopni naucit sa nove veci, i ked ja som to nikdy nezazil. Mam kolegov ktori mozno za par rokov odidu do dochodku, ale nikto nikdy nepolemizoval o pouzitom IDE.
Zrovna se starsimi programatory jsem cetl, ze se vyskytuje "agismus", ktery neni ani vedecky podlozeny. Sice jim prace tvra vetsinou dele, ale byva taky podstatne kvalitnejsi. A neni to tim, ze jsi v zamestnani obklopen lidmi, kterym je jedno, ze budou delat v IDE/OS/cemkoliv co je prudi, ale potrebuji penize/zvykli si trpet/jsou lini hledat jine misto?
O Vas predpokladam, ze mate este daleko do dochodku, tak preco taka neflexibilita, zavislost na jednom posratom IDE a neochota k troche namahy a prisposobeniu sa.
A neni to naopak? Proc zamestnavatel neopodstatnene vynucuje jedno IDE nebo jeden OS? Dokud to neni opravdu nutne, napr. ze aplikace jede pouze v Winech, tak nevidim duvod, proc nutit vsem zamestnancum Winy. To stejne s IDE. Pokud to proste cpe vsem, tak to smrdi a naopak pusobi neflexibilne ta firma.
Ved v prvom rade je jak je projekt zaujimavy, jak ma posunie dalej a kolko prachov mi to hodi. Pouzite nastroje su podla mna asi tak na predposlednom mieste.
Jak jsem psal, penize jsou treba pro me na seznamu priorit dost nizko. Zajimavost projektu je pro me primo spojena s pouzitymi nastroji, napr. sebezajimavejsi zadani projektu pokud budu nucet to psat v Notepadu a v C# bych odmitl (spatny nastroj a jazyk, u ktereho nechci firmu, ktera za nim stroji, podporovat).
Ked mi takto povies, ze dokazes pouzivat iba jeden druh IDE tak predpokladam, ze ked budes mat zbuildovat nieco na command line , alebo napisat na to skript tak to nedas. Skratka vyzera to tak, ze si tvrdohlavy a budu s tebou skor alebo neskor nejake problemy.
To sis vycucal z prstu. Neni to o tom, ze bych nedokazal pouzivat jine IDE (na VS jsem byl nucet zkusit i Eclipse i NetBeans), jen nevidim duvod, proc bych mel pouzivat (minimalne pro me) horsi IDE, kde budu mit nizsi produktivitu i komfort. Mam zkusenosti s Bashem (i pod Widlema ho pouzivam na jednodussi ukoly), delal jsem i neco malo v Pythonu, PHP, hodne v JS a konzoli pouzivam primo zabudovanou v IntelliJ IDEA. Napr. nas build proces je konzolovy (Gulp). Nedovedu si predstavit, ze by neci nebyl a spolehali by vsichni na IDE. Jak to budou automaticky testovat na vzdalenem servru? Automaticky nasazovat? Eh, nechci to ani vedet, jak by to muselo byt ubastlene.
Laskave nevyvozuj zavery o jinych lidech z faktu, ktere sis vymyslel. Ocividne to nefunguje. ;)
IMHO, takymto pristupom si iba zatvaras dvere k praci v slusnej firme a k lukrativnemu jobu.
K penezum mozna, ale slusna firma podle me nevynucuje neoduvodnene IDE (ani OS), takze tam si dvere nezaviram. Ze se me zavrali dvere nekam, kde nechci pracovat, me zase tak moc nemrzi :).
Ale neprekvapilo ma to, ocakaval som, ze to asi nejako takto dopadne. Toto spochybnovanie a filozovanie je typicka vlastnost nas Slovakov a Cechov. Kazdy sa tu nadrapuje ako majster sveta a najvacsi odbornik a vsecko ostane spochybnuje.
Toto napriklad v nemeckej firme nezazijes. Tam ked sa povie, ze toto je standard tak nikto o tom nediskutuje - a cuduj sa, ze sa tam zaraba 2x viac ako tu.
Opet, penize me moc nezajimaji. Dokud je to dost, abych vyzil a obcas si neco poridil, tak je neresim. Pokud jsem do firmy nastupoval s tim, ze budu vyvijet v Linuxu a v IntelliJ IDEA a oni za pul roku dojdou, ze mam Winy a Eclipse, tak z fleku odchazim. To by musela byt prace snu (nepocitaje IDE a OS) s platem nejmene v radu statisicu, aby to vyvazilo ty nevyhody. Neni to, ze vydelavaji 2x vic, dano spis ekonomickym stavem statu, nez te firmy? Co jsem cetl, tak jsou i myslim ochotni pracovat mnohem dele (neplacene prescasy?) a prostredi ve firmach byva podstatne horsi, nez u nas. Ja radsi o neco mene, ale nemit kazdy pohyb pod drobnohledem a byt neustale ve stresu, jestli me za neco hloupeho nevyhodi.
Takze asi sa mam na co tesit, ked moji starsi kolegovia sa rozhodnu odist do dochodku, s naborom mladsich rozmaznanych programatorov to bude asi o dost zlozitejsie ...
To bych cekal, ze si budou "stari" programatori rikat vzdy a vsude. Je to stejne, jako kdyz kazda "duchna" na ulici nadava, jak jsou ty dnesni decka rozmazleny a zkazeny, ze za nich to bylo vsecko jinak a uctivy a vsecko vlastne lepsi.
Alebo aby som konecne presiel na Intellij IDEA? Popravde robil som v tom nejake webservisy, ale pripada mi to oproti eclipse zbytocne zlozite a tazkopadne. Naposledy som mal verziu tusim 12 a kym nastartovala, mohol som si uvarit kavu. Ma to kopu funkcionality, ktoru nevyzivam a nepotrebujem a pokladam za zbytocne za to platit, ked eclipse je de facto standard a pouzivaju ho i nasi zahranicni partneri s ktorymi spolupracujeme.
Ma to mesic zkusebni dobu (ta placena verze), takze si myslim by nemel byt velky problem to zkusit. A proc vubec musite vsichni pouzivat stejne IDE? To pouzivate nejake IDE-specific veci (fuj), nebo jaky je duvod? Pokud to trva tak dlouho, nez nabehne, tak doporucuji upgrade PC. Nerikam, ze je to rychlik, ale stroj vyvojare by mohl mit alespon SSD, i5 a kotel pameti. Trosku me zarazi, ze zrovna Eclipse ma byt rychlejsi :o. Nevim, je to dlouho, mozna se to opravdu posunulo. Pokud to tak je, tak nemam problem pockat jednou denne o par vetrin dele, abych dostal po zbytek dne pristup k vyspelejsimu IDE.
My v nasej firme pracujeme podla standardov, takze nepotrebujeme stale refaktorovat, ako vy ostatni kutili a freelanceri.
:)
O tom silne pochybuju (nevernejne fieldy nikdy nerefaktorujete? nepresouvate funkcionalitu mezi patry v hierarchii dedicnosti?), ale budiz. IntelliJ IDEA si me poprve ziskala naseptavanim - v dobe, kdy jsem to zkousel, tak jsem musel do skoly delat v NetBeans a nejake naseptavani podle casti retezce neexistovalo. Pritom mi to prislo jako neco uplne zakladniho. Dalsi veci je chytre "type-aware" naseptavani, v JavaScriptu ne az tak pouzitelne, ale prave v Jave nebo Scale uzasne - v naseptavani uprednostnuje polozky podle typu, ktery se hodi do aktualniho vyrazu (napr. do parametru volani metody). Extremne casto pouzivam treba "search everywhere" (3x shift), kde to automaticky vyhledava v naposledy otevrenych souborech, ve tridach a symbolech. A takovych vychatavek je tam kotel, jen si je treba napoprve projit a zjistit, co to umi, aby clovek vedel, kdy to muze pouzit a ulehcit si zivot (treba takovy multicursor jsem podezrival, jestli je k necemu, a hle, kdyz znam zkratku, tak to najednou pouzivam a nemusim psat slozite [spise casove narocnejsi] regexpy na nahrazovani).
(BTW vyvojem se zivim a nejsem freelancer.)
Ale vsetko toto o com sa tu bavime je vlaste OT v tomto threade.
Pointa je v tom, ze ak vies iba Javu a nejake tvoje IDE, tak si ako zaba v studni.
Pointa je, ze pokud znas Javu a nejake pouzivane IDE, tak nebudes mit problem najit si dobre misto, kde budes psat v Jave a tvem IDE. Nechapu, proc bych mel kvuli par korunam jit do firmy, kde me bude prace prudit, protoze sefove setri na vybaveni (pomala PC, spatne/malo monitoru atd.) a neoduvodnene me limituji (vyber OS, IDE).
Myslis si ze to je cely svet. Preto sa nauc minimalne aj Python, alebo iny jazyk ... aby si trochu pochopil aj svet, ktory je okolo tvojej studne. Inac zostanes vzdy iba tou zabou v studni.
Tohle se bezne deje na IT VS (nebo alespon na VUT FITu). Donuti te udelat ten tymovy projekt v Haskellu, Prologu, C++. Proste musis napsat ten prekladac a interpret (zjednoduseneho) Pascalu a musis pochopit alespon zaklady "magie" (spise pekla) Bashe, jinak neprojdes. Ale vyzkousis si i zajimave veci jako neuronove site, evolucni algoritmy, programovani HW (neprilis popularni), reseni beznych algoritmu ve vysoce paralelnim prostredi, jak funguje sifrovani a jak se to lame atd.
-
Python má stále budoucnost v systémové administraci. Například často se používá u Raspberry Pi nebo i nepoměrně častěji v mnoha projektech pro administrátory jako Ansible, Openstack apod...
Python je ideální na místa, kde bash je příliš primitivní nástroj a naopak java zase příliš komplexní. Například nedávno jsem potřeboval přes snmp načíst měřené hodnoty a ukládat je do databáze, Python byl volba číslo jedna. Python je poměrně dost přehledný, knihovny se přes pip instalují velmi jednoduše a narozdíl od bash už má člověk pocit, že programuje (OOP, vyjímky atd...).
Navíc se dá naučit poměrně snadno. Řekl bych, že bash používám tak do 30 řádků, Python tak do 1.000 řádků kódu a na víc bych už asi použil Javu.
Jde tedy především o použití. Co se týká kariéry, tak Python asi nebrat. V kariéře teď aktuálně s přehledem vede Java.
-
Jde tedy především o použití. Co se týká kariéry, tak Python asi nebrat. V kariéře teď aktuálně s přehledem vede Java.
To je fakt. Hledal jsem něco s Pythonem a nemohl nic moc najít. Takže jsem šel ze senior Python na Javu a i když jsem neměl praxi, tak jsem měl lepší peníze než bych měl u senior Python. Divné, ale dnes to tak je :D
-
Záleží v jak blbém jazyce píšeš. Existují jazyky, který maj tak vymakanej systém typů, že se těžko vymejšlí, co ještě otestovat.
Největší fór je, že kdyby si opustil svůj dogmatickej svět, kde se testy píšou protože se píšou, tak by si objevil situace, kde testy jsou skutečně lepší než promakanej systém typů (za určitejch podmínek). Jenže to ti nechám jen jako hádanku. Zatím soudím, podle tvého vyjadřování, že netušíš :-P
V kterých situacích je lepší testovat?
Mi to celé kazíš. Jsem se těšil jak si Kit zase naběhne...
Zásadní výhoda testů je jejich separátnost. Tudíž můžeš dělat věci, které s typama jdou hůř1. Jedním z pravidel TDD je, že se píše kód nebo testy; nikdy dohromady. Což vede k tomu, že se dá podchytit kdy ti implementace odjíždí od kontraktu.
1 S typama to jde taky, třeba Elm má dost zajímavou featuru (https://github.com/elm-lang/elm-package/blob/master/README.md#publishing-updates). Jen nevím, nakolik je to prototyp a nakolik production ready.
-
Záleží v jak blbém jazyce píšeš. Existují jazyky, který maj tak vymakanej systém typů, že se těžko vymejšlí, co ještě otestovat.
Největší fór je, že kdyby si opustil svůj dogmatickej svět, kde se testy píšou protože se píšou, tak by si objevil situace, kde testy jsou skutečně lepší než promakanej systém typů (za určitejch podmínek). Jenže to ti nechám jen jako hádanku. Zatím soudím, podle tvého vyjadřování, že netušíš :-P
V kterých situacích je lepší testovat?
Mi to celé kazíš. Jsem se těšil jak si Kit zase naběhne...
To by ses načekal. Původně jsem ti chtěl napsat, ať si to strčíš do /dev/null, ale byl by to zbytečný příspěvek.
Zásadní výhoda testů je jejich separátnost. Tudíž můžeš dělat věci, které s typama jdou hůř1. Jedním z pravidel TDD je, že se píše kód nebo testy; nikdy dohromady. Což vede k tomu, že se dá podchytit kdy ti implementace odjíždí od kontraktu.
Jako obvykle ses nevytasil s ničím světoborným. Tohle přece víme.
Četl jsem, že kdysi Enšpígl poradil krejčím, aby po navléknutí nitě do jehly nezapomněli udělat na jením konci uzlík.
-
Panove, uvedomte si, ze nemyli-li se astronomove, Zeme ma pred sebou pouhych nekolik miliard let, nez bude sezehnuta rozpinajicim se Sluncem a nejspise uz dlouho pred tim bude neobyvatelna. Na konci z ni zbyde sezehnuta planeta bez vody a prakticky bez atmosfery. Logicky budoucnost Pythonu nemuze byt delsi. ;-)
-
Mi to celé kazíš. Jsem se těšil jak si Kit zase naběhne...
To by ses načekal. Původně jsem ti chtěl napsat, ať si to strčíš do /dev/null, ale byl by to zbytečný příspěvek.
Zásadní výhoda testů je jejich separátnost. Tudíž můžeš dělat věci, které s typama jdou hůř1. Jedním z pravidel TDD je, že se píše kód nebo testy; nikdy dohromady. Což vede k tomu, že se dá podchytit kdy ti implementace odjíždí od kontraktu.
Jako obvykle ses nevytasil s ničím světoborným. Tohle přece víme.
Četl jsem, že kdysi Enšpígl poradil krejčím, aby po navléknutí nitě do jehly nezapomněli udělat na jením konci uzlík.
Jsem rád, žes mě nesklamal :-)
-
Záleží v jak blbém jazyce píšeš. Existují jazyky, který maj tak vymakanej systém typů, že se těžko vymejšlí, co ještě otestovat.
Největší fór je, že kdyby si opustil svůj dogmatickej svět, kde se testy píšou protože se píšou, tak by si objevil situace, kde testy jsou skutečně lepší než promakanej systém typů (za určitejch podmínek). Jenže to ti nechám jen jako hádanku. Zatím soudím, podle tvého vyjadřování, že netušíš :-P
V kterých situacích je lepší testovat?
Mi to celé kazíš. Jsem se těšil jak si Kit zase naběhne...
Zásadní výhoda testů je jejich separátnost. Tudíž můžeš dělat věci, které s typama jdou hůř1. Jedním z pravidel TDD je, že se píše kód nebo testy; nikdy dohromady. Což vede k tomu, že se dá podchytit kdy ti implementace odjíždí od kontraktu.
1 S typama to jde taky, třeba Elm má dost zajímavou featuru (https://github.com/elm-lang/elm-package/blob/master/README.md#publishing-updates). Jen nevím, nakolik je to prototyp a nakolik production ready.
Implementace může odjíždět od kontraktu vždy. Výše jsi psal, že testování je lepší jen v některých situacích. V kterých situacích dokáže promakaný typový systém zabránit všem logickým chybám?
Ta featura na kterou vede odkaz se týká automatického určování čísla verze (snad jsem to pochopil správně). Jak to souvisí s testováním?
-
A proc vubec musite vsichni pouzivat stejne IDE? To pouzivate nejake IDE-specific veci (fuj), nebo jaky je duvod?
Hovori sa tomu firemne standardy a stabna kultura. To sa vo vacsich firmach pozaduje vies ?
My sa dohodne, ake nastroje budeme pouzivat a potom to aj zdokumentujeme. To znamena, ze mame interne manualy na vsetko, napriklad pre pripad, ze niekto dostane novy PC, tak otvori iba manual a tam ma step-by-step ake pluginy v STS (https://spring.io/tools) si treba naisntalovat, jak si nastavi SourceTree (https://www.sourcetreeapp.com/), .. atd, aby na danom projekte mohol co najrychlejsie zacat pracovat. Plus mnoho dalsich navodov, napr. jak sa pouziva GitFlow (http://nvie.com/posts/a-successful-git-branching-model/), jak sa builduje SNAPSHOT, jak sa builduje release, ... atd. Je to pre pripad zastupitelnosti clenov teamu, aby si to skuseny kolega nemusel vsetko drzat v hlave alebo novy kolega nieco nedojebal.
Keby sme pripustili situaciu, ze Franta Noef bude pouzivat nestandardny nastroj, a potom nam zahlasi, ze nieco mu v nom nefunguje, tak mu ziadny iny kolega ktory pouziva standard nebude vediet s tym pomoct. A Franta Noef, namiesto toho, aby robil nieco uzitocneho zabije den tym, ze bude skumat jak si to svoje IDE nastavi, aby mu vsecko fungovalo jak ma.
A potom snad Frantu chyti depresia, ze to tu nezvlada, alebo ze ho nejako tyranizujeme a da nam vypoved, ked sme uz s nim pocitali a investovali tisice EUR do jeho vzdelavania. To by bol pruser. :)
Snad to teraz uz lepsie chapes - tych nastrojov je hodne a su zlozite a obcas su s nimi problemy - dal som ti tam i nejake linky.
Nejde vobec o to, ktore IDE je sracka, ale vyzaduju sa standardy a zastupitelnost.
V projektoch je vela prachov a manageri vyzaduju, ze vsecko musi byt standardizovane a zdokumentovane. Security s oblubou pouziva, ze je to pre pripad, keby cely team sedel v jednom lietadle. :)
-
Implementace může odjíždět od kontraktu vždy.
No tak to je snad jasné. Ale u testů si toho snáz všimneš, protože ti spadnou.
Výše jsi psal, že testování je lepší jen v některých situacích. V kterých situacích dokáže promakaný typový systém zabránit všem logickým chybám?
Ta otázka je divně položená.
Promakaný typový systém dokáže zabránit všem logickým chybám, které dokáže podchytit.
Testování (ruční) dokáže zabránit všem logickým chybám, které kontroluješ.
Statický typový systém je podmnožina testování.
(Ale to jsem měl za to, že chápem.)
Ta featura na kterou vede odkaz se týká automatického určování čísla verze (snad jsem to pochopil správně). Jak to souvisí s testováním?
Testování stejně jako statické typování slouží (mimo jiné) k definování kontraktu. Podle rozdílu kontraktu se dá určit, který číslo v semver změnit. O tom byl ten odkaz.
-
A proc vubec musite vsichni pouzivat stejne IDE? To pouzivate nejake IDE-specific veci (fuj), nebo jaky je duvod?
Hovori sa tomu firemne standardy a stabna kultura. To sa vo vacsich firmach pozaduje vies ?
My sa dohodne, ake nastroje budeme pouzivat a potom to aj zdokumentujeme. To znamena, ze mame interne manualy na vsetko, napriklad pre pripad, ze niekto dostane novy PC, tak otvori iba manual a tam ma step-by-step ake pluginy v STS (https://spring.io/tools) si treba naisntalovat, jak si nastavi SourceTree (https://www.sourcetreeapp.com/), .. atd, aby na danom projekte mohol co najrychlejsie zacat pracovat. Plus mnoho dalsich navodov, napr. jak sa pouziva GitFlow (http://nvie.com/posts/a-successful-git-branching-model/), jak sa builduje SNAPSHOT, jak sa builduje release, ... atd. Je to pre pripad zastupitelnosti clenov teamu, aby si to skuseny kolega nemusel vsetko drzat v hlave alebo novy kolega nieco nedojebal.
Keby sme pripustili situaciu, ze Franta Noef bude pouzivat nestandardny nastroj, a potom nam zahlasi, ze nieco mu v nom nefunguje, tak mu ziadny iny kolega ktory pouziva standard nebude vediet s tym pomoct. A Franta Noef, namiesto toho, aby robil nieco uzitocneho zabije den tym, ze bude skumat jak si to svoje IDE nastavi, aby mu vsecko fungovalo jak ma.
A potom snad Frantu chyti depresia, ze to tu nezvlada, alebo ze ho nejako tyranizujeme a da nam vypoved, ked sme uz s nim pocitali a investovali tisice EUR do jeho vzdelavania. To by bol pruser. :)
Snad to teraz uz lepsie chapes - tych nastrojov je hodne a su zlozite a obcas su s nimi problemy - dal som ti tam i nejake linky.
Nejde vobec o to, ktore IDE je sracka, ale vyzaduju sa standardy a zastupitelnost.
V projektoch je vela prachov a manageri vyzaduju, ze vsecko musi byt standardizovane a zdokumentovane. Security s oblubou pouziva, ze je to pre pripad, keby cely team sedel v jednom lietadle. :)
Jsem příznivcem přesného opaku. Díky tomu, že Franta Noef (a nejenom on) používá své nástroje, tak je jednak kladen tlak na to, aby se do firemní dokumentace uvádělo co se robí, a nikoliv jak se to robí. Druhak se v praxi ukazuje, že heterogenní struktura pomáhá objevování vícero bugů, což znamená kvalitnější produkt tak nějak samo od sebe.
Standardy (více), a štábní kultura (méně) jsou rozhodně užitečná věc. Ale zrovna v případech které popisuješ je to jen projev lennosti, bez žádných objektivních výhod. IMHO.
No ale pointa je v tom, že pokud vám to tak funguje, a vyhovuje, ať je vám přáno. Ale já bych si u vás pracovat nepřál.
-
Jsem příznivcem přesného opaku. Díky tomu, že Franta Noef (a nejenom on) používá své nástroje, tak je jednak kladen tlak na to, aby se do firemní dokumentace uvádělo co se robí, a nikoliv jak se to robí. Druhak se v praxi ukazuje, že heterogenní struktura pomáhá objevování vícero bugů, což znamená kvalitnější produkt tak nějak samo od sebe.
Ale ked napises do DOK iba co a nenapises jak, tak mozno niekto nebude vediet to jak. Mame vyvojarov, ktori su dobri v business problematike, ale nechcu moc riesit technicke veci. Ked nieco nevedia, pozru do manualu ...
Sme samozrejme otvoreni aj novym myslienkam, a keby sa Franta Noef ukazal napr. po roku ze je totalny guru a ze jeho standard je lepsi a vyhodnejsi, pretoze nam podstane zvysuje produktivitu, tak by sme ho iste prijali a boli mu za to vdacni. Len by to musel aj zdokumentovat.
Standardy (více), a štábní kultura (méně) jsou rozhodně užitečná věc. Ale zrovna v případech které popisuješ je to jen projev lennosti, bez žádných objektivních výhod. IMHO.
Nemyslel by som, ze to je lenivost. Tieto vsetky administrativne veci, ako mat vsetko zdokumnetovane vyzaduje dost effortu - samozrejme popri tom co este programujes. Ja si myslim, ze je to tym, ze firma chce radsej istotu, ako nejaky pokrok.
Vyhodou je napr. zastupitelnost, nahraditelnost - nepotrebujes ziadnych guru, vies vymenit vyvojarov jako baterky.
Ale já bych si u vás pracovat nepřál.
Chapem ta, kto je zvyknuty na iny pristup nemusi mat na toto zaludok ...
Ja napriklad neznasam kravatu, pretoze mam pocit, ze ma skrti :)
-
Sme samozrejme otvoreni aj novym myslienkam, ...
To by snad ani nebyla mladá progresivní firma s neformální kulturou, kdyby tam tuhlenctu hlášku nedala :-)
-
@Mikrom:
pravdepodobne precujete pre ten typ firmy ktory zamestnava tzv 'lopaty', pretoze potrebujete bud:
1. programatorov s praxou, ale bez vlastnych nazorov, skusenosti a zvykov
2. junior programatorov ktorych zaucite tak, ze su v podstate neuplatnitelni mimo vasej firmy pokial sa nevzdelavaju v sukromnom case.
pracoval som hned po skole v podobnej 'velkej firme', dost dlho mi trvalo kym som si uvedomil ze tam stracam cas, dakujem neprosim
-
Hm, ale Franta Noef by v prve rade nenastoupil do vasi firmy, pokud se vynucuje neco, s cim nesouhlasi. Jak tedy dosahujete toho pokroku, kdyz nabirate jen lidi, co s tim musi souhlasit, naucit se to pouzivat a mozna za rok muzou zkusit neco maleho zmenit? To by museli mit firmu hodne radi, aby pretrpeli rok a pak mozna neco zmenili. Ale protoze pises, ze je potreba mit moznost vymenovat vyvojare jak baterky, tak to opravdu pusobi, ze chcete jen lopaty. Ale lopatam de tak maximalne o penize a teple misto, rozhodne nebudou posouvat firmu dal a stejne jako firma je vidi jako lehce nahraditelne, oni budou taky firmu videt jako lehce nahraditelnou - precejen pokud jim staci
patlani vyvoj v jekomkoliv jazyce a IDE s jakymikoliv nastroji, tak nebudou mit zadny problem vas nahradit.
@Mikrom:
pravdepodobne precujete pre ten typ firmy ktory zamestnava tzv 'lopaty', pretoze potrebujete bud:
1. programatorov s praxou, ale bez vlastnych nazorov, skusenosti a zvykov
2. junior programatorov ktorych zaucite tak, ze su v podstate neuplatnitelni mimo vasej firmy pokial sa nevzdelavaju v sukromnom case.
pracoval som hned po skole v podobnej 'velkej firme', dost dlho mi trvalo kym som si uvedomil ze tam stracam cas, dakujem neprosim
+1
-
Zase lopaty dostanou svejch 60 tisíc a připadaj si jako vývojáři, protože Franta od pásu má 16 :D Fakt cena hraje u lopat velkou cenu a dnes je moderní vzít radši více lopat než méně vývojářů.
-
@manag: Podle toho, co pises, tak musis byt totalne spickovym machrem vyvojarem aspon za pul melounu.
-
Tolik neberou ani v Silicon Valley.
-
Manag neni Silicon valley, urcite je lepsi.
-
Panove, uvedomte si, ze nemyli-li se astronomove, Zeme ma pred sebou pouhych nekolik miliard let, nez bude sezehnuta rozpinajicim se Sluncem a nejspise uz dlouho pred tim bude neobyvatelna. Na konci z ni zbyde sezehnuta planeta bez vody a prakticky bez atmosfery. Logicky budoucnost Pythonu nemuze byt delsi. ;-)
Samozřejmě, že budoucnost Pythonu může být delší, když opustí sluneční soustavu :-))) Některé sekvence RNA, nebo DNA už trvají více než 3 miliardy let.
-
Panove, uvedomte si, ze nemyli-li se astronomove, Zeme ma pred sebou pouhych nekolik miliard let, nez bude sezehnuta rozpinajicim se Sluncem a nejspise uz dlouho pred tim bude neobyvatelna. Na konci z ni zbyde sezehnuta planeta bez vody a prakticky bez atmosfery. Logicky budoucnost Pythonu nemuze byt delsi. ;-)
Samozřejmě, že budoucnost Pythonu může být delší, když opustí sluneční soustavu :-))) Některé sekvence RNA, nebo DNA už trvají více než 3 miliardy let.
Zde ovšem vyvstává metafyzická otázka, čím a k čemu Python bude bez svých uživatelů. Skoro bych řekl, že k h....
-
Panove, uvedomte si, ze nemyli-li se astronomove, Zeme ma pred sebou pouhych nekolik miliard let, nez bude sezehnuta rozpinajicim se Sluncem a nejspise uz dlouho pred tim bude neobyvatelna. Na konci z ni zbyde sezehnuta planeta bez vody a prakticky bez atmosfery. Logicky budoucnost Pythonu nemuze byt delsi. ;-)
Samozřejmě, že budoucnost Pythonu může být delší, když opustí sluneční soustavu :-))) Některé sekvence RNA, nebo DNA už trvají více než 3 miliardy let.
Zde ovšem vyvstává metafyzická otázka, čím a k čemu Python bude bez svých uživatelů. Skoro bych řekl, že k h....
Bude užívat sám sebe. Jak to dnes dělají lidé sami se sebou :-)))
-
Panove, uvedomte si, ze nemyli-li se astronomove, Zeme ma pred sebou pouhych nekolik miliard let, nez bude sezehnuta rozpinajicim se Sluncem a nejspise uz dlouho pred tim bude neobyvatelna. Na konci z ni zbyde sezehnuta planeta bez vody a prakticky bez atmosfery. Logicky budoucnost Pythonu nemuze byt delsi. ;-)
Samozřejmě, že budoucnost Pythonu může být delší, když opustí sluneční soustavu :-))) Některé sekvence RNA, nebo DNA už trvají více než 3 miliardy let.
Zde ovšem vyvstává metafyzická otázka, čím a k čemu Python bude bez svých uživatelů. Skoro bych řekl, že k h....
Bude užívat sám sebe. Jak to dnes dělají lidé sami se sebou :-)))
A aby si usnadnili život, tak vytvoří uživatele. Samozřejmě uživatele budou dělit do určitých kategorií, a budou díky tomu vznikat více či méně intuitivní a správně odsazené spory.
-
@manag: Podle toho, co pises, tak musis byt totalne spickovym machrem vyvojarem aspon za pul melounu.
Přesně tak, jen ne všude mi to dají :D Lopata ví, že má cenu tak jako dva Frantové, tak na 60 kouká jako na výhru ve Sportce. Obecně za 60 seženeš jen lemply.
-
@Mikrom:
pravdepodobne precujete pre ten typ firmy ktory zamestnava tzv 'lopaty', pretoze potrebujete bud:
1. programatorov s praxou, ale bez vlastnych nazorov, skusenosti a zvykov
2. junior programatorov ktorych zaucite tak, ze su v podstate neuplatnitelni mimo vasej firmy pokial sa nevzdelavaju v sukromnom case.
Ano treba inteligentnych ludi, ktori precizne vykonaju danu pracu. Neviem preco ich nazyvas lopaty ... to ty sa asi sam citis ako nejaky nadclovek :)
Nazory sa takisto beru, ale nie OT. Svoje zvyky si tak akurat mozes nechat na zachod, to do prace nepatri.
Mozno by si bol prekvapeny, ale nepamatam si dlhsi cas, ze by niekto dobrovolne odisiel.
-
Ale měl pravdu. Pokud hledáš jen lopaty, tak ty neodcházejí. Těm nacpeš polofunkční Netbeans, ukážeš manuál, jak instalujete SW, který se jinde instaluje sám, a lopaty budou šťastné a nikam nepůjdou. Kam by také šly, když nic neumí?
-
@Mikrom:
pravdepodobne precujete pre ten typ firmy ktory zamestnava tzv 'lopaty', pretoze potrebujete bud:
1. programatorov s praxou, ale bez vlastnych nazorov, skusenosti a zvykov
2. junior programatorov ktorych zaucite tak, ze su v podstate neuplatnitelni mimo vasej firmy pokial sa nevzdelavaju v sukromnom case.
Ano treba inteligentnych ludi, ktori precizne vykonaju danu pracu. Neviem preco ich nazyvas lopaty ... to ty sa asi sam citis ako nejaky nadclovek :)
Nazory sa takisto beru, ale nie OT. Svoje zvyky si tak akurat mozes nechat na zachod, to do prace nepatri.
Mozno by si bol prekvapeny, ale nepamatam si dlhsi cas, ze by niekto dobrovolne odisiel.
Vzdyt jsem to psal, pokud dobrovolne prisel, tak musel akceptovat vase omezeni, tudiz asi kvuli nim neodejde. Navic by asi ani nebyl prijat, kdyby prvni den zkusebky rekl, ze chce svoje IDE a zkostnatelci by rekli, ze to nejde.
To je jako rict, ze cervene jablko je jablko, ktere je cervene ;D. Je to pravda, ale nics tim vlastne nerekl.
Od lopat ale prave nemuzes cekat nejake zapaleni do projektu, loajalitu nebo ze budou prichazet s inovacemi. Lidi, ktere nabirate, jsou presny opak.
Svoje zvyky si tak akurat mozes nechat na zachod, to do prace nepatri.
Do tvoji prace mozna, v me praci pouzivam IDE na ktere jsem zvykly a nastroje se kterymi jsem zvykly pracovat. Pouzivam OS na ktery jsem zvykly. Pracuji tak, jak jsem zvykly.
Jiste, obcas se nejaky kompromis musi udelat. Ale pouziti/pouzite technologie se v tymu diskutuje a veci, ktere neni treba vynucovat se opravdu nevynucuji. Neni treba rok, aby kdokoliv mohl neco navrhnout a potencionalne uspet. Ale taky tu nejsou vyvojari jako baterky - zahodit starou a nacpat novou. Ja jsem s timto stavem spokojen.
-
Do tvoji prace mozna, v me praci pouzivam IDE na ktere jsem zvykly a nastroje se kterymi jsem zvykly pracovat. Pouzivam OS na ktery jsem zvykly. Pracuji tak, jak jsem zvykly.
Jiste, obcas se nejaky kompromis musi udelat. Ale pouziti/pouzite technologie se v tymu diskutuje a veci, ktere neni treba vynucovat se opravdu nevynucuji. Neni treba rok, aby kdokoliv mohl neco navrhnout a potencionalne uspet. Ale taky tu nejsou vyvojari jako baterky - zahodit starou a nacpat novou. Ja jsem s timto stavem spokojen.
Pointa není v tom, že jsi na něco zvyklí, ale v tom, že navzdory tomu, co tvrdí @mikrom takové rigidní omezování nepřináší vůbec žádný benefit.
-
Velkou, alespoň ve finančnictví a big-data. Python je dobré umět, pokud chceš mít strašně prachů a práci od devíti do pěti.
-
Na male skriptiky pouzivam BASH.
Na slozitejsi skriptiky Perl.
Na veci ktere musi bezet trochu slusne rychle commandline Javu.
Na male intranetove veci Javu/JSF2+Primefaces na Jettyne, Hibernate mapping (nativni, nemam rad JQL) + obcas Spring. Nebo misto Hibernatu nasadit Elasticsearch/Apache Lucene.
Na vetsi spolupracujici veci Javu + Karaf OSGi container, ve kterem mam Apache Camel, Apache CXF a Apache ActiveMQ.
Na opravdove weby se chci naucit AngularJS (frontend) v kooperaci se Spring MVC. Kamosi maji dobre zkusenosti s Twitter Bootstrap.
Na male skriptiky pouzivam Python.
Na slozitejsi skriptiky Python.
Na veci ktere musi bezet trochu slusne rychle commandline Python.
Na male intranetove veci Python.
Na vetsi spolupracujici veci Python.
Na opravdove weby Python.
.. víc než 15 let.
-
Na veci ktere musi bezet trochu slusne rychle commandline Python.
Slusne rychle a Python? Kdyz predrecnik uvadel Javu, kterou casto lidi kritizuji za pomalost? Napr. podle https://benchmarksgame.alioth.debian.org/u64q/python.html je Java vetsinou o jeden az dva rady rychlejsi ;D.
Na opravdove weby Python.
Na opravdove obrovske a narocne weby bych zase vzal (minimalne) Javu nebo jiny jazyk nad JVM (ani C# pry neni spatny, ale ten bych si nevybral). Kazdopadne bych sahnul po necem silne typovanem, rozhodne zadny NodeJS nebo Python, protoze po vlne nadseni z jednoduche implementace by prislo zdeseni s narocnou udrzbou.
Mimochodem, nebyl v Pythonu nejaky problem s globalnim zamkem, nebo uz to konecne vyresili? Se divam (http://www.cdotson.com/2014/12/node-js-vs-python-vs-pypy-a-simple-performance-comparison-updated/), ze i ten hloupy Node je mnohem rychlejsi nez Python, to jsem nevedel :o.
-
kdybych mel vestit z kristalove koule...
tak komercni budoucnost maji jazyky, ktere jsou navazany na firmu s podporou.
Oracle = Java
Facebook = PHP
Vyhledove vidim problem u:
Microsoft = C# - problem je restrukturalizace vs. zmena obchodniho modelu.
Google = GoLang - prumerna zivotnost vedlejsich Google projektu je nahodne nepredvidatelna.
vsechno ostatni je tajtrlikovani snad az na systemove zalezitosti za kteryma stoji nadace a konsorcia typu C a C++ setrvacnosti dokud budou existovat vyvojarske workstation.
-
Python je celkem hezký jazyk s poměrně dost nedostatky, a pokud by nebylo Django, NumPy, pandas a IPython/Jupyter, byl by už dávno mrtvý (můj názor).
To je totalna akademicka blbost, NumPy patri tak na (vysoke) skoly.
Tie moduly som nikdy nepouzil, ale pouzil som napriklad moduly na pristupy do databazy, parsovanie XML, generovanie PDF, ... atd.
zrovna python a xml a je docela vysmech. pokud je potreba pracovat se vsim vsudy, tak ma python naprosto nedostatecne rozhranni k xml, ale zato jich ma opravdu hodne a kazde jinym zpusobem nedostatecne.
-
Na veci ktere musi bezet trochu slusne rychle commandline Python.
Slusne rychle a Python? Kdyz predrecnik uvadel Javu, kterou casto lidi kritizuji za pomalost? Napr. podle https://benchmarksgame.alioth.debian.org/u64q/python.html je Java vetsinou o jeden az dva rady rychlejsi ;D.
Na opravdove weby Python.
Na opravdove obrovske a narocne weby bych zase vzal (minimalne) Javu nebo jiny jazyk nad JVM (ani C# pry neni spatny, ale ten bych si nevybral). Kazdopadne bych sahnul po necem silne typovanem, rozhodne zadny NodeJS nebo Python, protoze po vlne nadseni z jednoduche implementace by prislo zdeseni s narocnou udrzbou.
Mimochodem, nebyl v Pythonu nejaky problem s globalnim zamkem, nebo uz to konecne vyresili? Se divam (http://www.cdotson.com/2014/12/node-js-vs-python-vs-pypy-a-simple-performance-comparison-updated/), ze i ten hloupy Node je mnohem rychlejsi nez Python, to jsem nevedel :o.
Zkus si vyvíjet například v Djangu, naprostá paráda... Nevím v čem by byla lepší/výhodnější Java... Beztak je to jedno v jakém jazyce, vem si FB a jeho php...
-
Slusne rychle a Python? Kdyz predrecnik uvadel Javu, kterou casto lidi kritizuji za pomalost? Napr. podle https://benchmarksgame.alioth.debian.org/u64q/python.html je Java vetsinou o jeden az dva rady rychlejsi ;D.
Existují malé lži, velké lži a benchmarky...
-
Slusne rychle a Python? Kdyz predrecnik uvadel Javu, kterou casto lidi kritizuji za pomalost? Napr. podle https://benchmarksgame.alioth.debian.org/u64q/python.html je Java vetsinou o jeden az dva rady rychlejsi ;D.
Existují malé lži, velké lži a benchmarky...
Ale rozdil o rady? Navic to neni mikrobenchamark, zadna trivialni operace, je to nekolik algoritmu a je to provadeno v radu desitek az stovek sekund, vypada to solidne. Takze bych te pomalosti Pythonu veril. Ostatne dost velkych firem prechazelo z Pythonu ci Ruby prave k JVM nebo i NodeJS kvuli vykonu.
-
Slusne rychle a Python? Kdyz predrecnik uvadel Javu, kterou casto lidi kritizuji za pomalost? Napr. podle https://benchmarksgame.alioth.debian.org/u64q/python.html je Java vetsinou o jeden az dva rady rychlejsi ;D.
Existují malé lži, velké lži a benchmarky...
Ale rozdil o rady? Navic to neni mikrobenchamark, zadna trivialni operace, je to nekolik algoritmu a je to provadeno v radu desitek az stovek sekund, vypada to solidne. Takze bych te pomalosti Pythonu veril. Ostatne dost velkych firem prechazelo z Pythonu ci Ruby prave k JVM nebo i NodeJS kvuli vykonu.
a? Když budeš někde bržděnej a už nepůjde kód z optimalizovat, (na uvedené příklady sem se nedíval...) můžeš danou výpočet přepsat do cečka a máš problém s rychlostí vyřešenej. Nebo použiješ pypy, když chceš bejt u pythonu...
-
Na veci ktere musi bezet trochu slusne rychle commandline Python.
Slusne rychle a Python? Kdyz predrecnik uvadel Javu, kterou casto lidi kritizuji za pomalost? Napr. podle https://benchmarksgame.alioth.debian.org/u64q/python.html je Java vetsinou o jeden az dva rady rychlejsi ;D.
Na opravdove weby Python.
Na opravdove obrovske a narocne weby bych zase vzal (minimalne) Javu nebo jiny jazyk nad JVM (ani C# pry neni spatny, ale ten bych si nevybral). Kazdopadne bych sahnul po necem silne typovanem, rozhodne zadny NodeJS nebo Python, protoze po vlne nadseni z jednoduche implementace by prislo zdeseni s narocnou udrzbou.
Mimochodem, nebyl v Pythonu nejaky problem s globalnim zamkem, nebo uz to konecne vyresili? Se divam (http://www.cdotson.com/2014/12/node-js-vs-python-vs-pypy-a-simple-performance-comparison-updated/), ze i ten hloupy Node je mnohem rychlejsi nez Python, to jsem nevedel :o.
Zkus si vyvíjet například v Djangu, naprostá paráda... Nevím v čem by byla lepší/výhodnější Java... Beztak je to jedno v jakém jazyce, vem si FB a jeho php...
A znas vubec neco jineho?
Zkus se mrknout na primefaces.org do polozky demo, co to umi a kolik radku kodu je pro to potreba.
Treba tady, tu mas priklad CRUD tabulky s kontextovym menu:
http://www.primefaces.org/showcase/ui/data/datatable/contextMenu.xhtml
-
A znas vubec neco jineho?
Zkus se mrknout na primefaces.org do polozky demo, co to umi a kolik radku kodu je pro to potreba.
Treba tady, tu mas priklad CRUD tabulky s kontextovym menu:
http://www.primefaces.org/showcase/ui/data/datatable/contextMenu.xhtml
Este k tomu prikladu vyse. V jave ti tenhle priklad rozjedu na notebooku tak, ze napisu do mavenu jednoduchy pom.xml vyuzivajici pouze Maven Central, kde pridam v eclipsu dependency na posledni Primefaces, plugin na embedded jetynu, , pak do src vlozim ty tri example soubory, pak spustim maven target "mvn jetty:run" a hotovo.
Vse potrebne se automaticky postahuje z Maven Central, zkompiluje se WARko, spusti se embedded jettyna, deployuje se WARko a cely vehement se rozjede.
Vse co bylo potreba, je Eclipsa, jeden pom.xml a vedet co do nej napsat.
-
Slusne rychle a Python? Kdyz predrecnik uvadel Javu, kterou casto lidi kritizuji za pomalost? Napr. podle https://benchmarksgame.alioth.debian.org/u64q/python.html je Java vetsinou o jeden az dva rady rychlejsi ;D.
Existují malé lži, velké lži a benchmarky...
Ale rozdil o rady? Navic to neni mikrobenchamark, zadna trivialni operace, je to nekolik algoritmu a je to provadeno v radu desitek az stovek sekund, vypada to solidne. Takze bych te pomalosti Pythonu veril. Ostatne dost velkych firem prechazelo z Pythonu ci Ruby prave k JVM nebo i NodeJS kvuli vykonu.
Tak nejak.
Navic Java ma nevyhodu nutnosti pomaleho spusteni a zahrati JVM. POkud by ty testy byly koncipovany jako o rad delsi, dopadlo by to pro Python este hur. Treba ten prvni test pidigits trval na jave 3 sekundy, z toho cca 1 sec trval start JVM...
Na serveru bezi JVM kontinualne.
Jinak samozrejme, Java je nepouzitelna pro mnoho jednorazovych spusteni, napr. skript na zpracovani SNMP trapu v Net-SNMP. Tam jedine perl nebo C, rezie startu JVM je prilis velka.
-
Co se divam na nejake benchmarky, tak ani s PyPy se to neblizi Jave. Porad to byva 2x a vic pomalejsi.
Co ziskat Javou? No, ne ze bych ji ja zvolil, radeji bych si vzal Scalu, kdybych mel na vyber. Ale v kazdem pripade staticke typy (=lepe udrzovatelne, odpada nutnost psani casti testu oproti dynamickym jazykum) a snad nejstabilnejsi platformu (coz se pro opravdove weby hodi) s velmi vyspelymi knihovnami, dotazenym systemem zavislosti a nasazovani. Dale urcite nepreberne mnozstvi studijnich materialu, vysoke prumerne platy, obrovske mnozstvi pracovnich mist. No, urcite jsem na neco zapomnel, ale jako zacatek to myslim staci.
Nyni bych sel spise do frontendu ala SPA (Angular nebo React) a backend by se staral "jen" o pristup k DB a pocty.
V pripade maleho webu, bych si rad casem zkusil ScalaJS - mit staticky typovany jazyk v prohlizeci me dost laka. Navic moznost sdileni kodu mezi fronendem a backendem (modely) zni take vyborne, ale opravdu nevim, jestli je to uz pripravene na ostre nasazeni.
...
Jinak samozrejme, Java je nepouzitelna pro mnoho jednorazovych spusteni, napr. skript na zpracovani SNMP trapu v Net-SNMP. Tam jedine perl nebo C, rezie startu JVM je prilis velka.
Myslim ze existavalo nejake reseni, nailgun nebo nejak tak. Pustene JVM bylo porad a pri spusteni "skriptu" se JVM jen pridelilo a po dokonceni zustalo bezet, takze nemuselo vzdy startovat znovu.
-
Co se divam na nejake benchmarky, tak ani s PyPy se to neblizi Jave. Porad to byva 2x a vic pomalejsi.
Co ziskat Javou? No, ne ze bych ji ja zvolil, radeji bych si vzal Scalu, kdybych mel na vyber. Ale v kazdem pripade staticke typy (=lepe udrzovatelne, odpada nutnost psani casti testu oproti dynamickym jazykum) a snad nejstabilnejsi platformu (coz se pro opravdove weby hodi) s velmi vyspelymi knihovnami, dotazenym systemem zavislosti a nasazovani. Dale urcite nepreberne mnozstvi studijnich materialu, vysoke prumerne platy, obrovske mnozstvi pracovnich mist. No, urcite jsem na neco zapomnel, ale jako zacatek to myslim staci.
Nyni bych sel spise do frontendu ala SPA (Angular nebo React) a backend by se staral "jen" o pristup k DB a pocty.
V pripade maleho webu, bych si rad casem zkusil ScalaJS - mit staticky typovany jazyk v prohlizeci me dost laka. Navic moznost sdileni kodu mezi fronendem a backendem (modely) zni take vyborne, ale opravdu nevim, jestli je to uz pripravene na ostre nasazeni.
Souhlas. Osobne bych dneska bych na plnotucny web nasadil Angular frontend a Spring MVC backend, ktery bude vyrabet REST services na krmeni Angularu.
Jinak pro Angular2 je doporuceno pouzivat TypeScript, coz je nadstavba Javascriptu s podporou silneho typovani. Tim pada jedna z nevyhod Angularu. Sam jsem ale nezkousel.
-
Jinak samozrejme, Java je nepouzitelna pro mnoho jednorazovych spusteni, napr. skript na zpracovani SNMP trapu v Net-SNMP. Tam jedine perl nebo C, rezie startu JVM je prilis velka.
Když jsem si dělal plugin do Vimu v Javě, tak mi také vadila jeho dlouhá doba spouštění. Proto jsem si ten plugin zkompiloval do nativního kódu. Výsledná odezva spouštění kolem 0,3 s je už přijatelná pro interaktivní práci.
-
...
Svete div se, realita je, ze se bezne metody, promenne, tridy i pole prejmenovavaji. Pokud si opravdu stale myslite, ze ani prejmenovani metody nikdy nepouzijete, tak musite delat na smesne malych projektech. Tohle by mozna fungovalo pri skvele specifikaci, skvelemu navrhu a konstatni specifikaci.
Ja myslim, ze tohle je nejcastejsi duvod, proc pulka "programatoru" nechape potrebu refaktorovani. Pak se tady objevuji reci ve stylu: "refaktorovat potrebujou jenom luzri...", "IDE neni potreba...", "vim bohate staci na vse...", atd.
ja refaktorujem furt a iterativne, vzdy sa da ten kod vylepsit, aj ked si niekto mysli ze uz na tom netreba nic menit, tak si to fakt len mysli, ide ale o to sa s tym vediet v rozumny cas rozlucit a nechat to tak a dat tomu softveru zivot nech sa pouziva ... a potom obcas zrefaktorovat ked tam nieco nesedi, hlavne to vydavat casto von
-
asi polovicu casu stravim testovanim toho co som naprogramoval, unit testy, performance testy, zvysujem code coverage skrz jacoco ... jasne ze to "trva", ale ked by som toto vsetko nerobil tak si neviem predstavit ako by som tomu kodu veril ze to robi to co to robit ma ... vyvoj bez testov to je ako programovat naslepo, ved neviete co to poriadne robi ...
-
asi polovicu casu stravim testovanim toho co som naprogramoval, unit testy, performance testy, zvysujem code coverage skrz jacoco ... jasne ze to "trva", ale ked by som toto vsetko nerobil tak si neviem predstavit ako by som tomu kodu veril ze to robi to co to robit ma ... vyvoj bez testov to je ako programovat naslepo, ved neviete co to poriadne robi ...
Každej programátor testuje. Jen někteří lépe, jiní ručně.
-
...
Svete div se, realita je, ze se bezne metody, promenne, tridy i pole prejmenovavaji. Pokud si opravdu stale myslite, ze ani prejmenovani metody nikdy nepouzijete, tak musite delat na smesne malych projektech. Tohle by mozna fungovalo pri skvele specifikaci, skvelemu navrhu a konstatni specifikaci.
Přejmenovávání metod, objektů a tříd je při refaktorování jen okrajovou záležitostí. Názvy privátních metod si mohu měnit dle potřeby, ale u veřejných si to jen tak dovolit nemohu, protože bych tím měnil rozhraní třídy. To by mohlo mít fatální dopad na další projekty, ve kterých je tato třída použita.
-
ja sa v praxi velmi casto stretavam s tym, ze sa na automatizovane testy hladi presne z toho pohladu ze to brzi cas a vysvetlovat to managementu stale dokola je strasne frustrujuce. ja nemienim robit nejake kompromisy a kym to nie je poriadne testnute tak to nejde proste von. tou polovicou casu stravenim testovanim som viac menej myslel "vyvoj testov toho co som naprogramoval" a tomu ver ze to je automatizovane jak vino.
lenze management si to nedokaze dat dokopy a nevidi, ze ked sa to spravi poriadne tak to v dlhodobom horizonte prave ten cas brutalne setri.
-
Uz sme dosli medzicasom na to, ci ma python buducnost?
Inak k tomu facebooku a php - to ich php ma spolocny iba jazyk a kniznicu. Po prve na php spravili kompiler, potom vm a podruhe uz maju nejaky vlastny typovy jazyk. Oni do toho museli uz vrazit take prachy, ze si mohli vyvijat ten web rovno v C++ (alebo assembleri :D).
tralala bud rad, ze si nezazil: -ja si musim pisat testy -co vy neviete programovat? ehm..
-
tralala bud rad, ze si nezazil: -ja si musim pisat testy -co vy neviete programovat? ehm..
Tak až poletíte někam na služebku, tak se můžeš (přesně ve chvíli, kdy jste na vzletové dráze a nabíráte rychlost) jen tak mezi řečí zmínit:
"a to jste taky četl, že se zrovna u tohoto typu letadla předevčírem updatoval celý systém, a ani nezbyl čas na testování? ale copak, jste pane manažere nějak bledý... " :-)
-
Uz sme dosli medzicasom na to, ci ma python buducnost?
Inak k tomu facebooku a php - to ich php ma spolocny iba jazyk a kniznicu. Po prve na php spravili kompiler, potom vm a podruhe uz maju nejaky vlastny typovy jazyk. Oni do toho museli uz vrazit take prachy, ze si mohli vyvijat ten web rovno v C++ (alebo assembleri :D).
tralala bud rad, ze si nezazil: -ja si musim pisat testy -co vy neviete programovat? ehm..
Tak ale Facebook si to může dovolit. Na druhou stranu to je hezký příklad toho, jak relativně malý projekt (Facebook na úplném začátku) začne s PHP a poté, co se rozroste, se hledají cesty, jak ze špatného rozhodnutí ven. Facebook je hodně extrémní případ, ale názorný, překladač z PHP do C++ se nevyplatí psát jen tak někomu.
-
Uz sme dosli medzicasom na to, ci ma python buducnost?
Inak k tomu facebooku a php - to ich php ma spolocny iba jazyk a kniznicu. Po prve na php spravili kompiler, potom vm a podruhe uz maju nejaky vlastny typovy jazyk. Oni do toho museli uz vrazit take prachy, ze si mohli vyvijat ten web rovno v C++ (alebo assembleri :D).
tralala bud rad, ze si nezazil: -ja si musim pisat testy -co vy neviete programovat? ehm..
Tak ale Facebook si to může dovolit. Na druhou stranu to je hezký příklad toho, jak relativně malý projekt (Facebook na úplném začátku) začne s PHP a poté, co se rozroste, se hledají cesty, jak ze špatného rozhodnutí ven. Facebook je hodně extrémní případ, ale názorný, překladač z PHP do C++ se nevyplatí psát jen tak někomu.
No tak ono přepsat Facebook a napsat překladač to vyjde tak nastejno. Za tím spíše bude příchylnost k PHP. Chtěli, aby to zůstalo v PHP.
-
No, ale kischtoknizka nepouziva PHP, maji ten svuj vlastni jazyk Hack (http://hacklang.org/). Co se tak z rychliku divam, tak to pridava spoustu veci ze staticky typovanych jazyku - typove anotace, generiky, nullable typy.
PHP nemam vubec rad. Je to cele placane za behu clovekem bez CS znalosti - neschopny parser*, otresne pojmenovani a obcas i funkcnost standardni knihovny, obcasne nestandarni chovani operatoru, ktere v zajmu zachovani zpetne rozbitosti zustalo v jazyce, ikdyz sam autor uznal chybu.
(https://i.imgur.com/1zgFd.jpg)
Pokud neverite tak: http://www.phpsadness.com/ https://www.reddit.com/r/lolphp https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
*: Jsem na jeho bugy narazil i v projektiku o nejakych 100 radcich jednoducheho kodu - napr. zavolat metodu na nove vytvorene instanci nelze s libovolnym poctem zavorek, instance se prece musi se ulozit do promenne a az pak volat metoda, to da rozum. Takove esotericke chovani prece PHP nebude podporovat ;D.
-
No, ale kischtoknizka nepouziva PHP, maji ten svuj vlastni jazyk Hack (http://hacklang.org/). Co se tak z rychliku divam, tak to pridava spoustu veci ze staticky typovanych jazyku - typove anotace, generiky, nullable typy.
PHP nemam vubec rad. Je to cele placane za behu clovekem bez CS znalosti - neschopny parser*, otresne pojmenovani a obcas i funkcnost standardni knihovny, obcasne nestandarni chovani operatoru, ktere v zajmu zachovani zpetne rozbitosti zustalo v jazyce, ikdyz sam autor uznal chybu.
(https://i.imgur.com/1zgFd.jpg)
Pokud neverite tak: http://www.phpsadness.com/ https://www.reddit.com/r/lolphp https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
*: Jsem na jeho bugy narazil i v projektiku o nejakych 100 radcich jednoducheho kodu - napr. zavolat metodu na nove vytvorene instanci nelze s libovolnym poctem zavorek, instance se prece musi se ulozit do promenne a az pak volat metoda, to da rozum. Takove esotericke chovani prece PHP nebude podporovat ;D.
PHP se řídí jen jediným zákonem, jazyk musí být praktický. Proto nasává vše praktické z aktuálně modních jazyků. Tu z C, tu z Perlu, tu z Javy, tu z Pythonu, ... a na vás záleží, jak konzistentní jazykovou směs z toho vytvoříte, každý jazykový projev je totiž obrazem vaší vnitřní disciplíny, ne jen gramatiky jazyka :-) A to už tak u jazyků bývá, i česky můžete mluvit jako afroameričan :-)))
Osobně ale dávám přednost Pythonu, představuje pro mě výzvu, dělat věci pythonicky, to je jako česky psát v hexametrech :-)))
-
Problem je, ze pythonovych (resp javovych) zakaziek tolko nenajdete. Mala firmicka si radsej nahodi na web wordpress a zaplati par eur nejakemu studentovi ktory im to nastavi. Java pre mna znamena sediet v nejakej moloch institucii a v poslednej dobe ma to prestalo bavit. Mam pocit, ze tam dreveniem..
-
Pythoh samozrejme budoucnost ma. Je to vyborny a prakticky jazyk, ktery se hodi na radu ruznych ukolu. Od pokrocilejsich shellovych skriptu, pres webove a gui aplikace az po skriptovani aplikaci jako je gimp nebo office.
-
*: Jsem na jeho bugy narazil i v projektiku o nejakych 100 radcich jednoducheho kodu - napr. zavolat metodu na nove vytvorene instanci nelze s libovolnym poctem zavorek, instance se prece musi se ulozit do promenne a az pak volat metoda, to da rozum. Takove esotericke chovani prece PHP nebude podporovat ;D.
Proto se píší testy, aby takové špeky vývojář odhalil co nejdříve. Také jsem už několikrát narazil na nezvyklé priority v ternárním operátoru, ale testy to včas odhalily a závorky spravily.
-
Python je podle mě dobrej na různý skriptování, pokud začínáš, klidně do něj jdi. Co se týče webů, několik let dělam v PHP. Python považuju za líp navrženej jazyk než PHP, ale na druhou stranu má (minimálně u nás) horší ekosystém - menší poptávka, hůř seženu parťáka, malá komunita a podpora ze strany hostingů. A Python pro mě nemá zas nějakou velkou featuru, abych měl důvod přecházet. S PHP+frameworkem se dá celkem dobře žít. Spíš typuju, že rozsáhlý projekty mě beztak dovedou ke staticky typovanýmu jazyku (C#/java) ať už budu dělat v Pythonu nebo v PHP.
-
Spíš typuju, že rozsáhlý projekty mě beztak dovedou ke staticky typovanýmu jazyku (C#/java) ať už budu dělat v Pythonu nebo v PHP.
Statické typování se do PHP vkrádá již nějakou dobu, takže ho nebudeš muset opouštět ani v rozsáhlých projektech.
To statické typování však nemá zase tak velký přínos, jak se o něm mluví. Občas i zbytečně hází klacky pod nohy.
-
To statické typování však nemá zase tak velký přínos, jak se o něm mluví. Občas i zbytečně hází klacky pod nohy.
Blbost.
-
To statické typování však nemá zase tak velký přínos, jak se o něm mluví. Občas i zbytečně hází klacky pod nohy.
Blbost.
Blbost to sice je, ale přinejmenším je korektní poznamenat, že existují i špatné implementace statického typování.
-
python se dobre cte
kod je kratky - vysoka produktivita prace
dobra podpora napric platformama
tuna zajimavych uzitecnych knihoven
jak muze nekdo pochybovat o jeho budoucnosti?
-
python se dobre cte
kod je kratky - vysoka produktivita prace
dobra podpora napric platformama
tuna zajimavych uzitecnych knihoven
jak muze nekdo pochybovat o jeho budoucnosti?
Přesně tak. Sice jsem v něm nějakou dobu hledal interface, ale pak jsem zjistil, že i ten ducktyping má své kouzlo.
-
Jak se teda programuje bez interface? Podle mě pak jsou z toho jen takové malé skriptíky bez architektury.
Rychlý vývoj je také nesmysl, protože vývoj je jen z malé části o psaní kódu.
-
kod je kratky - vysoka produktivita prace
Na skole jsme meli nejaky projekt v Pythonu a zazil jsem pravy opak. Byl jsem zvykly na Scalu a Python byl hrozne ukecany, funkcionalne se v nem skoro nedalo ani psat. Uznavam, ze s nim mam malo zkusenosti (a po tomto zazitku se k nemu urcite nevratim), ale nasel jsem pomerne dost kritiky i od zkusenejsich, napr. http://stackoverflow.com/questions/1017621/why-isnt-python-very-good-for-functional-programming. Uz jen ten zapis lambdy byl na odstrel.
dobra podpora napric platformama
tuna zajimavych uzitecnych knihoven
No, to ale v Jave, PHP i NodeJS mate taky. A rekl bych, ze Jave se knihovnami nemuze rovnat snad nic.
jak muze nekdo pochybovat o jeho budoucnosti?
Na poli skriptovacich jazyku jeho misto chapu. Jinde, napr. u tech opravdovych webu, moc ne. Ale tam ostatne nechapu ani ten NodeJS nebo PHP - udrzovat to musi byt opravdu zazitek.
*: Jsem na jeho bugy narazil i v projektiku o nejakych 100 radcich jednoducheho kodu - napr. zavolat metodu na nove vytvorene instanci nelze s libovolnym poctem zavorek, instance se prece musi se ulozit do promenne a az pak volat metoda, to da rozum. Takove esotericke chovani prece PHP nebude podporovat ;D.
Proto se píší testy, aby takové špeky vývojář odhalil co nejdříve. Také jsem už několikrát narazil na nezvyklé priority v ternárním operátoru, ale testy to včas odhalily a závorky spravily.
Tak ono lze programovat i v nejakem tom Brainfucku, ale proc si volit spatny jazyk a pak to vyvazovat testy/casem/nervy, kdyz jsou lepsi alternativy? Prislo me absurdni, ze jsem narazil na bug parseru, kdyz jsem poprve lepil dohromady par trid a ten projektik byl tak smesne maly.
Par vychytavek PHP (vycuc z /r/lolphp):
Catchable fatal error: Argument 1 passed to a() must be an instance of int, int given
- preklep v RNG, hlavne ze puvodni kod u sebe mel referencni vysledky, aby se predeslo podobnym botam - https://www.reddit.com/r/lolphp/comments/467ykt/oops_theres_a_typo_in_the_mersenne_twister_rng/
- null is apparently smaller than any number you can imagine. Except zero. - https://3v4l.org/MVDH0
- (http://i.imgur.com/Htg0feG.png)
- (https://i.imgur.com/uYUs0Ap.png)
Uprimne nechapu, jak nekdo muze obhajovat takto neprofesionalne vyvijeny jazyk. Co me zarazi, ze mel tolik casu napravit chyby, ale oni radeji pridavaji dalsi. Napr. takovy JavaScript jde opracnou cestou - postupne se jazyk zlepsuje.
-
Jak se teda programuje bez interface? Podle mě pak jsou z toho jen takové malé skriptíky bez architektury.
Rychlý vývoj je také nesmysl, protože vývoj je jen z malé části o psaní kódu.
Je to o zvyku a sebekázni. Bez toho to nejde ani ve staticky typovaných jazycích.
Vývoj je z velké části o čtení již napsaného kódu. Kratší kód se rychleji čte. Pomohou kratší komentáře, kratší názvy tříd, objektů i metod.
-
Par vychytavek PHP (vycuc z /r/lolphp):
...
Uprimne nechapu, jak nekdo muze obhajovat takto neprofesionalne vyvijeny jazyk. Co me zarazi, ze mel tolik casu napravit chyby, ale oni radeji pridavaji dalsi. Napr. takovy JavaScript jde opracnou cestou - postupne se jazyk zlepsuje.
Z mého pohledu to jsou zvěrstva, které v běžné aplikaci nemají co pohledávat. Když někdo použije takový hnus, tak se nemůže divit, že se to chová podivně. Podivně se v PHP chová například typ boolean. Už léta ho nepoužívám, protože mi připadá v dnešní době zbytečný. Kdo ho používá, tak se občas diví.
PHP má za sebou živelný vývoj - je to jeho významné mínus. Bývá však k dispozici prakticky na každém webovém serveru a při dodržování jakési kultury programování se na uvedené problémy ani nenarazí. Zbytek odchytí testy. V PHP se mi programuje mnohem pohodlněji, než například v Javě.
-
Jak se teda programuje bez interface? Podle mě pak jsou z toho jen takové malé skriptíky bez architektury.
Rychlý vývoj je také nesmysl, protože vývoj je jen z malé části o psaní kódu.
Je to o zvyku a sebekázni. Bez toho to nejde ani ve staticky typovaných jazycích.
Vývoj je z velké části o čtení již napsaného kódu. Kratší kód se rychleji čte. Pomohou kratší komentáře, kratší názvy tříd, objektů i metod.
O jakém zvyku? Co tam teda dám, když mám rozhraní a několik implementací? Nebo to nahradím dědičností, která se normálně skoro nepoužívá?
Kratší kód, který nikdo neví, co dělá? Aha, to musí být zážitek. Právě kvůli čtení kódu je to nepoužitelný jazyk. Jako pustit si kód, abych věděl, co vlastně dělá, to je dost ujetý na nějaký reálný vývoj.
-
Jak se teda programuje bez interface? Podle mě pak jsou z toho jen takové malé skriptíky bez architektury.
Rychlý vývoj je také nesmysl, protože vývoj je jen z malé části o psaní kódu.
Je to o zvyku a sebekázni. Bez toho to nejde ani ve staticky typovaných jazycích.
Vývoj je z velké části o čtení již napsaného kódu. Kratší kód se rychleji čte. Pomohou kratší komentáře, kratší názvy tříd, objektů i metod.
O jakém zvyku? Co tam teda dám, když mám rozhraní a několik implementací? Nebo to nahradím dědičností, která se normálně skoro nepoužívá?
Kratší kód, který nikdo neví, co dělá? Aha, to musí být zážitek. Právě kvůli čtení kódu je to nepoužitelný jazyk. Jako pustit si kód, abych věděl, co vlastně dělá, to je dost ujetý na nějaký reálný vývoj.
Dědičnost se normálně používá, podmínkou je zachování LSP.
V Pythonu prostě interface nepoužiješ. Použití ducktypingu je jednodušší, než použití interface.
Čtení kódu v Pythonu je pohodové, protože Python donutí programátora dodržovat grafickou úpravu. Pokud jsi zvyklý třeba na Javu a uvidíš program v Pythonu, je to pro tebe cizí jazyk. Platí to však i obráceně. Pythonista se na Javu dívá jako na jazyk plný šílených obstrukcí, složených závorek a věčným soubojem s kompilátorem.
-
Jak se teda programuje bez interface?
Blbě.
V Pythonu prostě interface nepoužiješ. Použití ducktypingu je jednodušší, než použití interface.
Tak jasně. Nic je vždycky jednodužší než něco.
Čtení kódu v Pythonu je pohodové, protože Python donutí programátora dodržovat grafickou úpravu. Pokud jsi zvyklý třeba na Javu a uvidíš program v Pythonu, je to pro tebe cizí jazyk. Platí to však i obráceně. Pythonista se na Javu dívá jako na jazyk plný šílených obstrukcí, složených závorek a věčným soubojem s kompilátorem.
No a pak se na to kouká haskellista a vrtí hlavou, že vás to baví. Jeden píše romány, protože Java je ukecaná, druhej píše romány, protože Python prakticky nic neumí.
-
Jak se teda programuje bez interface?
Blbě.
V Pythonu prostě interface nepoužiješ. Použití ducktypingu je jednodušší, než použití interface.
Tak jasně. Nic je vždycky jednodužší než něco.
Čtení kódu v Pythonu je pohodové, protože Python donutí programátora dodržovat grafickou úpravu. Pokud jsi zvyklý třeba na Javu a uvidíš program v Pythonu, je to pro tebe cizí jazyk. Platí to však i obráceně. Pythonista se na Javu dívá jako na jazyk plný šílených obstrukcí, složených závorek a věčným soubojem s kompilátorem.
No a pak se na to kouká haskellista a vrtí hlavou, že vás to baví. Jeden píše romány, protože Java je ukecaná, druhej píše romány, protože Python prakticky nic neumí.
Stokrát nic...
-
Jak se teda programuje bez interface? Podle mě pak jsou z toho jen takové malé skriptíky bez architektury.
Rychlý vývoj je také nesmysl, protože vývoj je jen z malé části o psaní kódu.
Programuje se v nem velmi dobre. Ty moje skriptiky maji bezne desitky tisic radku per projekt, nejstarsi udrzuju uz pres 15 let. Je vazne zajimave, bez jakych berlicek si rada lidi neumi predstavit zivot. Neni to ani tak o schopnostech jazyka, ale o schopnostech programatora. Python je dostatecne robustni i pro psani vetsich veci, ale nekteri lide s omezenym rozhledem se domnivaji, ze bez statickych typu nebo interface se neda programovat.
Python se nehodi na vsechno, ale to asi zadny jazyk a ve spouste pripadu je velmi dobre pouzitelny a prakticky. Jeho hlavni omezeni je nizsi vykon, presto se pomoci nej daji generovat komplexni webove stranky do 50 ms, kde polovinu casu z toho zaberou pristupy do databaze, jako nejuzsi hrdlo. Ostatne, velka cast webu jede na obdobne pomalem php. U gui aplikaci ani nepoznate, ze nejsou nativne kompilovane a ze je pohani python - na rozdil treba od javy. Rada linuxovych systemovych gui utilit je napsana prave v pythonu.
-
Jak se teda programuje bez interface? Podle mě pak jsou z toho jen takové malé skriptíky bez architektury.
Rychlý vývoj je také nesmysl, protože vývoj je jen z malé části o psaní kódu.
Programuje se v nem velmi dobre. Ty moje skriptiky maji desitky tisic radku per projekt, nejstarsi udrzuju uz pres 15 let. Je vazne zajimave, bez jakych berlicek si rada lidi neumi predstavit zivot. Neni to ani tak o schopnostech jazyka, ale o schopnostech programatora. Python je dostatecne robustni i pro psani vetsich veci, ale nekteri lide s omezenym rozhledem se domnivaji, ze bez statickych typu nebo interface se neda programovat.
Python se nehodi na vsechno, ale to asi zadny jazyk a ve spouste pripadu je velmi dobre pouzitelny a prakticky. Jeho zasadni omezeni je nizsi vykon, presto se pomoci nej daji generovat komplexni webove stranky do 50 ms, kde polovinu casu z toho zaberou pristupy do databaze, jako nejuzsi hrdlo.
-
O jakém zvyku? Co tam teda dám, když mám rozhraní a několik implementací? Nebo to nahradím dědičností, která se normálně skoro nepoužívá?
Kratší kód, který nikdo neví, co dělá? Aha, to musí být zážitek. Právě kvůli čtení kódu je to nepoužitelný jazyk. Jako pustit si kód, abych věděl, co vlastně dělá, to je dost ujetý na nějaký reálný vývoj.
Jak jsi prisel na to, ze dedicnost se nepouziva? :-)
Jak jsi prisel na to, ze u kratsiho kodu nikdo, vcetne jeho programatora, nevi co dela? Trpis predsudky a neargumentujes racionalne. Kdyby byl Python nepouzitelny jazyk, jak tvrdis, tak ho nikdo nebude pouzivat, ale on je naopak siroce pouzivany. Ja ho naopak preferuji a uprednostnuji kde muzu a nemusim naopak Javu, ktera me osobne prijde celkove tezkopadna a neohrabana. Ale, to jsou moje osobni preference a chapu, ze jinym programatorum vyhovuje.
A naopak, moznost program casto a co nejdriv spoustet je jedna z vyhod interpretovanych jazyku.
-
Par vychytavek PHP (vycuc z /r/lolphp):
...
Uprimne nechapu, jak nekdo muze obhajovat takto neprofesionalne vyvijeny jazyk. Co me zarazi, ze mel tolik casu napravit chyby, ale oni radeji pridavaji dalsi. Napr. takovy JavaScript jde opracnou cestou - postupne se jazyk zlepsuje.
Z mého pohledu to jsou zvěrstva, které v běžné aplikaci nemají co pohledávat. Když někdo použije takový hnus, tak se nemůže divit, že se to chová podivně. Podivně se v PHP chová například typ boolean. Už léta ho nepoužívám, protože mi připadá v dnešní době zbytečný. Kdo ho používá, tak se občas diví.
PHP má za sebou živelný vývoj - je to jeho významné mínus. Bývá však k dispozici prakticky na každém webovém serveru a při dodržování jakési kultury programování se na uvedené problémy ani nenarazí. Zbytek odchytí testy. V PHP se mi programuje mnohem pohodlněji, než například v Javě.
To co popisujes ale znaci spatnou kvalitu jazyka :).
Namatkou par dalsich perel:
- ve standardni knihovne obsahuje funkce, ktere maji zamerne neopravene bezpecnosti chyby (zpetna kompatibilita FTW)
- jeden typ je podle autora PHP optimalizovany na pouziti jako pole, vektor, hashmapa, slovnik, kolekce, zasobnik i fronta :D
- automaticke pretypovani (https://3v4l.org/NcZ0n) je proste genialni (https://eval.in/108854)
- std knihovna je hrozna, bohuzel ne jen jmena jsou problem - napr. "sleep() returns 0 on success, FALSE on error, or when interrupted by a signal returns number of remaining seconds except on Windows where it returns 192" ;D
Kdyby byl Python nepouzitelny jazyk, jak tvrdis, tak ho nikdo nebude pouzivat, ale on je naopak siroce pouzivany.
Staci se podivat na PHP. Jazyk, ktery mel byt utracen davno (hrozna "specifikace", jazyk i interpret), je to jako splacane od zacinajiciho studentika VS, presto tu dal uspesne preziva. Kvalita nema bohuzel s popularitou nic spolecneho.
Python na me povetsinou pusobi naopak kvalitne (no, veci okolo objektu me moc nesedi, napr. ty __háky__, ale asi spis vec zvyku), akorat je na muj vkus prilis ukecany.
Ja ho naopak preferuji a uprednostnuji kde muzu a nemusim naopak Javu, ktera me osobne prijde celkove tezkopadna a neohrabana.
Python me prijde stejne neohrabany jako Java. Moc to nesleduju, ale Java 8 myslim prinasela dost FP veci, coz vede k mnohem jednodussimu kodu. Osobne me prijde Scala jako dobry kompromis mezi uplatnitelnosti (JVM) a "krasou" jazyka (velmi jednoduse zapsane slozite veci, podpora DSL, FP atd).
V Pythonu me vadi velke mnozstvi boilerplatu (napr. @property, @staticmethod, lambda, nenasel jsem zpusob, jak lehce retezit volani funkci, takze pokusy o FP styl pusobi hrozne) a kod celkove pusobi roztahane.
Samozrejme na Haskell, co se tyce "krasy" a strucnosti, as nic moc nema*. A to jsem v nem "noob", pamatuji si ho pouze ze skoly. Ale uz i jen ty zaklady byly nezapomenutelne (pro ostatni studenty spise v tom spatnem slova smyslu :D).
*: Resp. nic lepsiho jsem jeste nevidel. Pokud neco znate, tak sem s tim.
A naopak, moznost program casto a co nejdriv spoustet je jedna z vyhod interpretovanych jazyku.
Vzhledem k tomu, ze existuji inkrementalni prekladace (tusim ze jej ma Java i Scala a urcite mnoho dalsich), tak tohle je standard, ne vyhoda. Stejne tak i kompilovana Scala ma REPL, take to neni vyhrada Pythonu nebo interpretovanych jazyku.
-
Par vychytavek PHP (vycuc z /r/lolphp):
...
Uprimne nechapu, jak nekdo muze obhajovat takto neprofesionalne vyvijeny jazyk. Co me zarazi, ze mel tolik casu napravit chyby, ale oni radeji pridavaji dalsi. Napr. takovy JavaScript jde opracnou cestou - postupne se jazyk zlepsuje.
Z mého pohledu to jsou zvěrstva, které v běžné aplikaci nemají co pohledávat. Když někdo použije takový hnus, tak se nemůže divit, že se to chová podivně. Podivně se v PHP chová například typ boolean. Už léta ho nepoužívám, protože mi připadá v dnešní době zbytečný. Kdo ho používá, tak se občas diví.
PHP má za sebou živelný vývoj - je to jeho významné mínus. Bývá však k dispozici prakticky na každém webovém serveru a při dodržování jakési kultury programování se na uvedené problémy ani nenarazí. Zbytek odchytí testy. V PHP se mi programuje mnohem pohodlněji, než například v Javě.
To co popisujes ale znaci spatnou kvalitu jazyka :).
Namatkou par dalsich perel:
- ve standardni knihovne obsahuje funkce, ktere maji zamerne neopravene bezpecnosti chyby (zpetna kompatibilita FTW)
- jeden typ je podle autora PHP optimalizovany na pouziti jako pole, vektor, hashmapa, slovnik, kolekce, zasobnik i fronta :D
- automaticke pretypovani (https://3v4l.org/NcZ0n) je proste genialni (https://eval.in/108854)
- std knihovna je hrozna, bohuzel ne jen jmena jsou problem - napr. "sleep() returns 0 on success, FALSE on error, or when interrupted by a signal returns number of remaining seconds except on Windows where it returns 192" ;D
Kdyby byl Python nepouzitelny jazyk, jak tvrdis, tak ho nikdo nebude pouzivat, ale on je naopak siroce pouzivany.
Staci se podivat na PHP. Jazyk, ktery mel byt utracen davno (hrozna "specifikace", jazyk i interpret), je to jako splacane od zacinajiciho studentika VS, presto tu dal uspesne preziva. Kvalita nema bohuzel s popularitou nic spolecneho.
Python na me povetsinou pusobi naopak kvalitne (no, veci okolo objektu me moc nesedi, napr. ty __háky__, ale asi spis vec zvyku), akorat je na muj vkus prilis ukecany.
Ja ho naopak preferuji a uprednostnuji kde muzu a nemusim naopak Javu, ktera me osobne prijde celkove tezkopadna a neohrabana.
Python me prijde stejne neohrabany jako Java. Moc to nesleduju, ale Java 8 myslim prinasela dost FP veci, coz vede k mnohem jednodussimu kodu. Osobne me prijde Scala jako dobry kompromis mezi uplatnitelnosti (JVM) a "krasou" jazyka (velmi jednoduse zapsane slozite veci, podpora DSL, FP atd).
V Pythonu me vadi velke mnozstvi boilerplatu (napr. @property, @staticmethod, lambda, nenasel jsem zpusob, jak lehce retezit volani funkci, takze pokusy o FP styl pusobi hrozne) a kod celkove pusobi roztahane.
Samozrejme na Haskell, co se tyce "krasy" a strucnosti, as nic moc nema*. A to jsem v nem "noob", pamatuji si ho pouze ze skoly. Ale uz i jen ty zaklady byly nezapomenutelne (pro ostatni studenty spise v tom spatnem slova smyslu :D).
*: Resp. nic lepsiho jsem jeste nevidel. Pokud neco znate, tak sem s tim.
A naopak, moznost program casto a co nejdriv spoustet je jedna z vyhod interpretovanych jazyku.
Vzhledem k tomu, ze existuji inkrementalni prekladace (tusim ze jej ma Java i Scala a urcite mnoho dalsich), tak tohle je standard, ne vyhoda. Stejne tak i kompilovana Scala ma REPL, take to neni vyhrada Pythonu nebo interpretovanych jazyku.
Tak todle moc čitelné není a je to v haskellu (přebráno z GitHubu):
onCreate :: JNIEnv -> JObject -> JObject -> IO ()
onCreate env activity _bundle = runJNISafe () env $ do
msg <- liftIO $ do
getNumProcessors >>= setNumCapabilities
caps <- getNumCapabilities
return $ "Hello World!\nRunning on " `append` pack (show caps) `append` " CPUs!"
-
Tak todle moc čitelné není a je to v haskellu (přebráno z GitHubu):
onCreate :: JNIEnv -> JObject -> JObject -> IO ()
onCreate env activity _bundle = runJNISafe () env $ do
msg <- liftIO $ do
getNumProcessors >>= setNumCapabilities
caps <- getNumCapabilities
return $ "Hello World!\nRunning on " `append` pack (show caps) `append` " CPUs!"
Mýlíš se. V očích haskellistů je to luxusní a přehledný kód, na který Python prostě nemá :)
-
Tak todle moc čitelné není a je to v haskellu (přebráno z GitHubu):
onCreate :: JNIEnv -> JObject -> JObject -> IO ()
onCreate env activity _bundle = runJNISafe () env $ do
msg <- liftIO $ do
getNumProcessors >>= setNumCapabilities
caps <- getNumCapabilities
return $ "Hello World!\nRunning on " `append` pack (show caps) `append` " CPUs!"
Programovaci jazyk nema nutne byt citelny pro ty, kteri jej neznaji (a uz vubec ne, pokud neznaji ani dane paradigma). Nedokazu pousoudit, zda je to nejhezci mozny zapis v Haskellu, ale citelne a krasne me to prijde (no, mozna az na ten append).
Zkuste si v cistem Pythonu hezky funkcionalne retezit par transformaci (napr. nekolik map, filter a pouzijte v nich inline funkce) a pak srovnejte se Scalou nebo Haskellem. To teprv uvidite tu krasu ;).
-
Z mého pohledu to jsou zvěrstva, které v běžné aplikaci nemají co pohledávat. Když někdo použije takový hnus, tak se nemůže divit, že se to chová podivně. Podivně se v PHP chová například typ boolean. Už léta ho nepoužívám, protože mi připadá v dnešní době zbytečný. Kdo ho používá, tak se občas diví.
OMG, co je teda spravny typ pro bool hodnotu? Integer nula/nenula?
A z jineho soudku:
http://stackoverflow.com/questions/70528/why-are-pythons-private-methods-not-actually-private
Je tam genialni implementace privatni metody pres inspect outer caller:
import re
import inspect
class MyClass :
def __init__(self) :
pass
def private_function ( self ) :
try :
function_call = inspect.stack()[1][4][0].strip()
# See if the function_call has "self." in the begining
matched = re.match( '^self\.', function_call )
if not matched :
print 'This is Private Function, Go Away'
return
except :
print 'This is Private Function, Go Away'
return
# This is the real Function, only accessible inside class #
print 'Hey, Welcome in to function'
def public_function ( self ) :
# i can call private function from inside the class
self.private_function()
Celkem 180 upvotes a tisice dekovnych dopisu.
Tomuhle se uz neda ani smat, to je jedno velke WTF.
-
Z mého pohledu to jsou zvěrstva, které v běžné aplikaci nemají co pohledávat. Když někdo použije takový hnus, tak se nemůže divit, že se to chová podivně. Podivně se v PHP chová například typ boolean. Už léta ho nepoužívám, protože mi připadá v dnešní době zbytečný. Kdo ho používá, tak se občas diví.
OMG, co je teda spravny typ pro bool hodnotu? Integer nula/nenula?
Nic. Prostě v PHP proměnné typu boolean nepoužívám. Bez náhrady. Těm aplikacím to prostě nechybí. Pokud je výsledkem nějaké funkce typ boolean, tak ho použiji k větvení, řízení cyklu nebo do ternárního operátoru, ale nikde ho neukládám, protože vím, že už jeho hodnotu potřebovat nebudu.
-
Tak todle moc čitelné není a je to v haskellu (přebráno z GitHubu):
onCreate :: JNIEnv -> JObject -> JObject -> IO ()
onCreate env activity _bundle = runJNISafe () env $ do
msg <- liftIO $ do
getNumProcessors >>= setNumCapabilities
caps <- getNumCapabilities
return $ "Hello World!\nRunning on " `append` pack (show caps) `append` " CPUs!"
Programovaci jazyk nema nutne byt citelny pro ty, kteri jej neznaji (a uz vubec ne, pokud neznaji ani dane paradigma). Nedokazu pousoudit, zda je to nejhezci mozny zapis v Haskellu, ale citelne a krasne me to prijde (no, mozna az na ten append).
Zkuste si v cistem Pythonu hezky funkcionalne retezit par transformaci (napr. nekolik map, filter a pouzijte v nich inline funkce) a pak srovnejte se Scalou nebo Haskellem. To teprv uvidite tu krasu ;).
Řetězení transformací je chytlavý nešvar FP, nedá se to dobře testovat. A v konečném důsledku je to podobné, jako když funkce má 12 parametrů.
Python je navržen schválně tak, aby nic nešlo lehce řetězit.
-
Řetězení transformací je chytlavý nešvar FP, nedá se to dobře testovat.
To pouze odpovida nekolika prikazum za sebou. Nebo bezne snad testujete jen polovinu metody objektu, napr. jen prvni tri prikazy, ikdyz jich metoda obsahuje 20? Treba v Jave to asi mozne je, ale nevim proc to delat.
A v konečném důsledku je to podobné, jako když funkce má 12 parametrů.
Ne, neni. Stejne jako mit 12 prikazu v metode neznamena, ze je to stejne jako mit 12 parametru.
Python je navržen schválně tak, aby nic nešlo lehce řetězit.
S tim souhlasim, je zamerne navrzen tak, aby v nem neslo elegentne provozovat FP. Ostatne myslim, ze i samotny tvurce se k tomu tak vyjadril, ze FP je pro neho na druhe koleji. Cely Python je zamerne navrzen tak, aby byl ukecany, coz nemam rad - jazyk je hezky pro novacky, jakmile ale po chvili povysi na znale, tak najednou vidi vsude tu ukecanost pro zacatecniky, ktera pokrocilym uz ale nic neprinasi. Nevzniklo ostatne proto Ruby?
-
Z mého pohledu to jsou zvěrstva, které v běžné aplikaci nemají co pohledávat. Když někdo použije takový hnus, tak se nemůže divit, že se to chová podivně. Podivně se v PHP chová například typ boolean. Už léta ho nepoužívám, protože mi připadá v dnešní době zbytečný. Kdo ho používá, tak se občas diví.
OMG, co je teda spravny typ pro bool hodnotu? Integer nula/nenula?
A z jineho soudku:
http://stackoverflow.com/questions/70528/why-are-pythons-private-methods-not-actually-private
Je tam genialni implementace privatni metody pres inspect outer caller:
import re
import inspect
class MyClass :
def __init__(self) :
pass
def private_function ( self ) :
try :
function_call = inspect.stack()[1][4][0].strip()
# See if the function_call has "self." in the begining
matched = re.match( '^self\.', function_call )
if not matched :
print 'This is Private Function, Go Away'
return
except :
print 'This is Private Function, Go Away'
return
# This is the real Function, only accessible inside class #
print 'Hey, Welcome in to function'
def public_function ( self ) :
# i can call private function from inside the class
self.private_function()
Celkem 180 upvotes a tisice dekovnych dopisu.
Tomuhle se uz neda ani smat, to je jedno velke WTF.
Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...
Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...
S tim souhlasim, je zamerne navrzen tak, aby v nem neslo elegentne provozovat FP. Ostatne myslim, ze i samotny tvurce se k tomu tak vyjadril, ze FP je pro neho na druhe koleji. Cely Python je zamerne navrzen tak, aby byl ukecany, coz nemam rad - jazyk je hezky pro novacky, jakmile ale po chvili povysi na znale, tak najednou vidi vsude tu ukecanost pro zacatecniky, ktera pokrocilym uz ale nic neprinasi. Nevzniklo ostatne proto Ruby?
Si asi jeden z mála lidí co považuje Python za ukecanej jazyk.
-
proměnné typu boolean nepoužívám. Bez náhrady. Těm aplikacím to prostě nechybí.
Nechodím sem často, ale skoro vždycky tady prezentujete nějaký neotřelý koncept, o kterém by mě nenapadlo ani uvažovat. Jste génius. Sepište knihu o programování. Okamžitě si jí koupím a otevřu jí vždycky, když budu mít špatnou náladu, zaručeně pobaví.
-
Řetězení transformací je chytlavý nešvar FP, nedá se to dobře testovat.
To pouze odpovida nekolika prikazum za sebou. Nebo bezne snad testujete jen polovinu metody objektu, napr. jen prvni tri prikazy, ikdyz jich metoda obsahuje 20? Treba v Jave to asi mozne je, ale nevim proc to delat.
A v konečném důsledku je to podobné, jako když funkce má 12 parametrů.
Ne, neni. Stejne jako mit 12 prikazu v metode neznamena, ze je to stejne jako mit 12 parametru.
Python je navržen schválně tak, aby nic nešlo lehce řetězit.
S tim souhlasim, je zamerne navrzen tak, aby v nem neslo elegentne provozovat FP. Ostatne myslim, ze i samotny tvurce se k tomu tak vyjadril, ze FP je pro neho na druhe koleji. Cely Python je zamerne navrzen tak, aby byl ukecany, coz nemam rad - jazyk je hezky pro novacky, jakmile ale po chvili povysi na znale, tak najednou vidi vsude tu ukecanost pro zacatecniky, ktera pokrocilym uz ale nic neprinasi. Nevzniklo ostatne proto Ruby?
Dobře, když máte výraz x = a(b(c(d(e(f(g)))))), tak jak otestujete, která funkce je špatně bez přepisování kódu. Jak se dozvíte, co je výsledkem c na reálných datech?
-
Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...
Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...
Přesně tak, WTF. Rád bych poznamenal, Python není Java a neměla by se z něho Java dělat. To že Python nemá nic jako privátní typ se mě osobně náhodou velice líbí. Ale pokud byste v Pythonu skutečně něco programovali tak existují standardy na kterých se jednotlivý vývojáři domluvili a metody formátu __*__ jsou považovány za privátní a nikdo je z vnějšku nevolá. Pokud je zavoláte tak se nic nestane, ale vývojář je může odstranit či změnit a váš kód může bez ohlášení přestat fungovat.
To co já považuju na Pythonu za velice dobrého je, že nutí všechny vývojáře psát stejně strukturovaný kód (pravda kopírování kódu je pak občas peklo) a dále že přímo integruje dokumentaci. Součástí definice jazyka je prostě i způsob jak dokumentovat a nástoje (žlutou vlnovkou) opozorňují že dokumentace chybí. Příjde mi prostě, že python jako takový vynucuje slušné programátorské zvyklosti, to je celé. Že je ukecaný, to místy trochu je, ale alespoň není kryptický.
K tomu, co tu párkrát okrajově zaznělo, že Python díky tomu, že se nekompiluje neprovádí žádnou kontrolu (typovou či jakoukoli jinou), ano neprovádí, je to převážně skriptovací jazyk. Ale s nástroji pylint a pep8 se většina chyb objeví již v editoru.
Finálem k diskuzi o IDE. Rád bych poznamenal, že refaktroring je možné udělat i mimo IDE, stejně tak našeptávání a sémantické prohledávání a to možná ještě efektivnějí než v případě IDE, které mají mnohdy na velkých projektech problémy. V tomto případě hovořím především o C/C++, pro Javu bych s IDE neváhal. Jinak k výběru IDE, mnohdy nemáte na výběr už jen kvůli tomu co se na projektu používalo dodneška. Pro některé existuje svět i mimo web a PC a v tomto světě většinou skončíte na IDE které má podporu právě pro vaši platformu a změna je prakticky nemožná. Z tohoto pohledu mi přijdou takové dohady zbytečné a programátor prostě musí dělat v tom v čem musí a zrovna podpora více IDE není většinou to co se ve vývoji chce podporovat, protože to není to co zákazník uvidí, práce na více platformách má už větší smysl.
-
Kdyby byl Python nepouzitelny jazyk, jak tvrdis, tak ho nikdo nebude pouzivat, ale on je naopak siroce pouzivany.
Staci se podivat na PHP. Jazyk, ktery mel byt utracen davno (hrozna "specifikace", jazyk i interpret), je to jako splacane od zacinajiciho studentika VS, presto tu dal uspesne preziva. Kvalita nema bohuzel s popularitou nic spolecneho.
Rec je o pouzitelnosti, nikoliv kvalite a popularite. Je dobre rozlisovat mezi akademickou kvalitou a praktickou pouzitelnosti a zamyslet se, proc se tem akademickym jazykum v praxi tolik nedari. Velmi pravdepodobne v posouzeni kvality jazyka bude kazdy zduraznovat jine vlastnosti, rozhodne bych to neredukoval jen na cistotu syntaxe.
Ja ho naopak preferuji a uprednostnuji kde muzu a nemusim naopak Javu, ktera me osobne prijde celkove tezkopadna a neohrabana.
Python me prijde stejne neohrabany jako Java. Moc to nesleduju, ale Java 8 myslim prinasela dost FP veci, coz vede k mnohem jednodussimu kodu. Osobne me prijde Scala jako dobry kompromis mezi uplatnitelnosti (JVM) a "krasou" jazyka (velmi jednoduse zapsane slozite veci, podpora DSL, FP atd).
Neumim si predstavit, ze bych neco jako scala pouzival prakticky, tj. ze bych mel odvahu to nasadit u zakaznika v rozsahu desitek tisic radkukodu a udrzoval/rozvijel to 15+ let. Pro me je to neduveryhodny a proto _prakticky_ nepouzitelny jazyk.
V Pythonu me vadi velke mnozstvi boilerplatu (napr. @property, @staticmethod, lambda, nenasel jsem zpusob, jak lehce retezit volani funkci, takze pokusy o FP styl pusobi hrozne) a kod celkove pusobi roztahane.
Samozrejme na Haskell, co se tyce "krasy" a strucnosti, as nic moc nema*. A to jsem v nem "noob", pamatuji si ho pouze ze skoly. Ale uz i jen ty zaklady byly nezapomenutelne (pro ostatni studenty spise v tom spatnem slova smyslu :D).
*: Resp. nic lepsiho jsem jeste nevidel. Pokud neco znate, tak sem s tim.
Dekoratory nejsou boilerplate, to je naopak reseni eliminujici boilerplate, ktere vede k prehlednosti a strucnosti, nejsou povinne a jsou velmi flexibilni, muzes si je prizpusobit svym potrebam. Na haskellu mi nic krasneho neprijde, ale nema smysl porovnavat funkcionalni jazyk s imperativnim a tomu druhemu vycitat opacny stav. Argument, ze pokusy programovat v haskellu imperativne vypada hrozne, bych osobne povazoval za fail :-).
A naopak, moznost program casto a co nejdriv spoustet je jedna z vyhod interpretovanych jazyku.
Vzhledem k tomu, ze existuji inkrementalni prekladace (tusim ze jej ma Java i Scala a urcite mnoho dalsich), tak tohle je standard, ne vyhoda. Stejne tak i kompilovana Scala ma REPL, take to neni vyhrada Pythonu nebo interpretovanych jazyku.
Neni to standard a naopak, ze se o to snazi i kompilovane jazyky jen dokazuje, ze to ma smysl a je to vyhodou pro kazdy jazyk, ktery to umi.
-
Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...
Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...
V Javě se to stejně obchází přes gettery a settery, takže to vyjde nastejno. V C# na to dokonce vymysleli syntaktický cukr. Python si na privátní atributy prostě nehraje, takže ty gettery ani settery nepotřebuje.
-
Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...
Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...
V Javě se to stejně obchází přes gettery a settery, takže to vyjde nastejno. V C# na to dokonce vymysleli syntaktický cukr. Python si na privátní atributy prostě nehraje, takže ty gettery ani settery nepotřebuje.
No ne že by je nepotřeboval, jako na zpracování dat před uložením se hodí (například pro kontrolu). Jinak by python nepodporoval magickou metodu __setattr__. Ale obecně si myslím, že python se svou volnější představou o OOP je na tom líp než taková Java nebo C++. Ale to je jen můj názor.
-
Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...
Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...
V Javě se to stejně obchází přes gettery a settery, takže to vyjde nastejno. V C# na to dokonce vymysleli syntaktický cukr. Python si na privátní atributy prostě nehraje, takže ty gettery ani settery nepotřebuje.
No a kdyz v Jave _NECHCI_, aby mi nekdo hrabal do privatniho atributu, no tak zkratka pro nej getter/setter nevygeneruju.
Gettery a settery jsou v Jave nepovinne, pouzivaji se hlavne proto, ze je pak mozno na akci cteni/zapisu atributu nahookovat nejakou akci, treba debuglog.
Pokud v Jave budu treba potrebovat pri setovani atributu provest sideefect akci (napr. odeslat SNMP trap), puvodni tridu si zdedim, prepisu setter kde krome volani super() este poslu ten SNMP trap.
A protoze classes IoC injektuju Springem, injektnu zkratka moji zdedenou tridu, interface se nezmenil a okolni svet nemusi delat nic.
Pokud budes po pythonovsku setovat atribut naprimo, ceka te pri mnou popisovane uprave preveliky oser a to i pro svet okolo.
Nehlede na to, ze bez opravdu privatnich atributu a metod nejde bezpecne udelat prakticky zadny coding pattern, ani primitivni singleton ne.
Kazy jouda pouzivajici tvuj objekt ti jej muze rozbit. U toho singletonu zvlaste, kde kazdy automaticky zavola konstruktor, namisto ClassName.getInstance()
-
Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...
Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...
V Javě se to stejně obchází přes gettery a settery, takže to vyjde nastejno. V C# na to dokonce vymysleli syntaktický cukr. Python si na privátní atributy prostě nehraje, takže ty gettery ani settery nepotřebuje.
No ne že by je nepotřeboval, jako na zpracování dat před uložením se hodí (například pro kontrolu). Jinak by python nepodporoval magickou metodu __setattr__. Ale obecně si myslím, že python se svou volnější představou o OOP je na tom líp než taková Java nebo C++. Ale to je jen můj názor.
V Pythonu se __setattr__ používá spíš k přetěžování operátoru přiřazení. Tedy nikoli k omezení, ale k rozšíření funkcionality objektu.
-
V Javě se to stejně obchází přes gettery a settery, takže to vyjde nastejno.
Tady nejde o nějaké obcházení. Díky getterům a setterům má právě programátor věci plně pod kontrolou. Jde o úmyslné poskytnutí částečného a kontrolovaného(to je celkem důležité slovo) přístupu k určitým datům. Smyslem zapouzdření není neměnitelný objekt, do kterého se akorát všechno na začátku nasype konstruktorem. Osobně s volností Pythonu problém nemám, ale argument, že "to vyjde nastejno", je zase mimo.
-
Nic jako privátní meto v Pythonu není.
K _ prostě přistupovat můžeš, ale pak se nediv...
Nicméně to že někdo takhle privátní metodu zprasí a spousta lidí mu ještě děkuje je nepochopitelné, prostě WTF...
V Javě se to stejně obchází přes gettery a settery, takže to vyjde nastejno. V C# na to dokonce vymysleli syntaktický cukr. Python si na privátní atributy prostě nehraje, takže ty gettery ani settery nepotřebuje.
No a kdyz v Jave _NECHCI_, aby mi nekdo hrabal do privatniho atributu, no tak zkratka pro nej getter/setter nevygeneruju.
Gettery a settery jsou v Jave nepovinne, pouzivaji se hlavne proto, ze je pak mozno na akci cteni/zapisu atributu nahookovat nejakou akci, treba debuglog.
Pokud v Jave budu treba potrebovat pri setovani atributu provest sideefect akci (napr. odeslat SNMP trap), puvodni tridu si zdedim, prepisu setter kde krome volani super() este poslu ten SNMP trap.
A protoze classes IoC injektuju Springem, injektnu zkratka moji zdedenou tridu, interface se nezmenil a okolni svet nemusi delat nic.
Pokud budes po pythonovsku setovat atribut naprimo, ceka te pri mnou popisovane uprave preveliky oser a to i pro svet okolo.
Nehlede na to, ze bez opravdu privatnich atributu a metod nejde bezpecne udelat prakticky zadny coding pattern, ani primitivni singleton ne.
Kazy jouda pouzivajici tvuj objekt ti jej muze rozbit. U toho singletonu zvlaste, kde kazdy automaticky zavola konstruktor, namisto ClassName.getInstance()
V Javě tyhlety gettery ani settery nepoužívám, protože je k ničemu nepotřebuji. Na privátní atributy objektu mi tak nikdo hrabat nebude. Případný debuglog injektuji do konstruktoru.
Singleton je antipatternem, který má své účelné použití například u vzoru NullObject. Jinak je vcelku bezvýznamný.
-
V Pythonu se __setattr__ používá spíš k přetěžování operátoru přiřazení. Tedy nikoli k omezení, ale k rozšíření funkcionality objektu.
Ano to je pravda, viz. Django. Špatně jsem se vyjádřil.
Kazy jouda pouzivajici tvuj objekt ti jej muze rozbit. U toho singletonu zvlaste, kde kazdy automaticky zavola konstruktor, namisto ClassName.getInstance()
Upřímně, můj názor je že chránit se takto před něčím, co kdyby je, zbytečné. Každý programátor by měl psát dokumentaci a každý programátor by ji měl číst. Nedej bože by měl dodržova i standard daného jazyka. Kdo to nedělá tak není programátor a sebelepší programovací jazyk ho nezachrání. Když ho rozbije je to jeho chyba, jemu ten program nebude fungovat. A upřímě není zase až tak těžké pochopit, že to co se jmenuje __*__ na to se z vnějšku nesaha. Pak není těžké vytvořit ani Java-like getry a setry., nikdo ti v tom nebrání. Nevim na co, ale tady je ukázka.
class foo:
def __init__(self):
self.__fo__ = true
def set_fo(self, val):
self.__fo__ = val
def get_fo(self,val):
return self.__fo__Myslím že volnost je ta hlavní vlastnost, nikdo tě nenutí dodržovat OOP přesně do puntíku. Naproti tomu v Java nutí programátora do OOP a programátoři to pak prostě různě obcházejí. Python tě to prostě nechá udělat. V Pythonu můžeš napsat kód který nemá jedinou classu a bude fungovat, tady to máš Javo.
-
Myslím že volnost je ta hlavní vlastnost, nikdo tě nenutí dodržovat OOP přesně do puntíku. Naproti tomu v Java nutí programátora do OOP a programátoři to pak prostě různě obcházejí.
Java na jedné straně nutí do OOP, na druhé straně to programátoři obchází přes gettery a settery. A ještě se tím chlubí.
-
Kazy jouda pouzivajici tvuj objekt ti jej muze rozbit. U toho singletonu zvlaste, kde kazdy automaticky zavola konstruktor, namisto ClassName.getInstance()
Upřímně, můj názor je že chránit se takto před něčím, co kdyby je, zbytečné. Každý programátor by měl psát dokumentaci a každý programátor by ji měl číst. Nedej bože by měl dodržova i standard daného jazyka. Kdo to nedělá tak není programátor a sebelepší programovací jazyk ho nezachrání. Když ho rozbije je to jeho chyba, jemu ten program nebude fungovat.
Delal jste uz na projektu, na kterem pracovalo 2 a vice lidi?
Kdyz nekteri ti lidi byli z Indie?
Tak nekoho mozna bavi resit nesmyslne bugreporty od lidi, co objekt pouzili nezamyslenym zpusobem, nekdo zase svuj objekt zkratka zabezpeci. (Treba tim inspectem outer calleru :)) )
-
Myslím že volnost je ta hlavní vlastnost, nikdo tě nenutí dodržovat OOP přesně do puntíku. Naproti tomu v Java nutí programátora do OOP a programátoři to pak prostě různě obcházejí.
Java na jedné straně nutí do OOP, na druhé straně to programátoři obchází přes gettery a settery. A ještě se tím chlubí.
Gettery/settery nejak koliduji s OOP? Ja dosud zil v domeni, ze to je jedna ze zakladnich OOP vlastnosti (zapouzdreni stavu objektu a kontrolovany pristup k atributum)
Zajimave, prosim vysvetleni.
-
Řetězení transformací je chytlavý nešvar FP, nedá se to dobře testovat.
To pouze odpovida nekolika prikazum za sebou. Nebo bezne snad testujete jen polovinu metody objektu, napr. jen prvni tri prikazy, ikdyz jich metoda obsahuje 20? Treba v Jave to asi mozne je, ale nevim proc to delat.
A v konečném důsledku je to podobné, jako když funkce má 12 parametrů.
Ne, neni. Stejne jako mit 12 prikazu v metode neznamena, ze je to stejne jako mit 12 parametru.
Python je navržen schválně tak, aby nic nešlo lehce řetězit.
S tim souhlasim, je zamerne navrzen tak, aby v nem neslo elegentne provozovat FP. Ostatne myslim, ze i samotny tvurce se k tomu tak vyjadril, ze FP je pro neho na druhe koleji. Cely Python je zamerne navrzen tak, aby byl ukecany, coz nemam rad - jazyk je hezky pro novacky, jakmile ale po chvili povysi na znale, tak najednou vidi vsude tu ukecanost pro zacatecniky, ktera pokrocilym uz ale nic neprinasi. Nevzniklo ostatne proto Ruby?
Dobře, když máte výraz x = a(b(c(d(e(f(g)))))), tak jak otestujete, která funkce je špatně bez přepisování kódu. Jak se dozvíte, co je výsledkem c na reálných datech?
čím je ten příklad specifický pro funkcionální programování? v pythonu by to bylo úplně stejné
-
V Javě tyhlety gettery ani settery nepoužívám, protože je k ničemu nepotřebuji. Na privátní atributy objektu mi tak nikdo hrabat nebude. Případný debuglog injektuji do konstruktoru.
Singleton je antipatternem, který má své účelné použití například u vzoru NullObject. Jinak je vcelku bezvýznamný.
Tohle prilis nechapu. Jakym zpusobem mi debuglog v konstrutoru umozni zalogovat, ze nekdo v 13:00:23 nastavil atribut "teplota" z "33" na "45"?
Ze Singleton (navrzeny a popsany Gang of Four) je antipattern je pomerne odvazne tvrzeni.
A vzhledem k tomu, ze defaultni scope Spring beanu je prave Singleton, je to tvrzeni o to odvaznejsi.
Zrejme budou lidi kolem Springu banda matlaku.
-
V Javě tyhlety gettery ani settery nepoužívám, protože je k ničemu nepotřebuji. Na privátní atributy objektu mi tak nikdo hrabat nebude. Případný debuglog injektuji do konstruktoru.
Tohle prilis nechapu. Jakym zpusobem mi debuglog v konstrutoru umozni zalogovat, ze nekdo v 13:00:23 nastavil atribut "teplota" z "33" na "45"?
Při každé změně teploty v objektu se zavolá ten debuglog. Do konstruktoru se injektuje ten debuglogger nebo zmíněný NullObject, který v té logovací metodě nebude dělat nic.
-
To co já považuju na Pythonu za velice dobrého je, že nutí všechny vývojáře psát stejně strukturovaný kód (pravda kopírování kódu je pak občas peklo)
To má Haskell taky.
a dále že přímo integruje dokumentaci. Součástí definice jazyka je prostě i způsob jak dokumentovat a nástoje (žlutou vlnovkou) opozorňují že dokumentace chybí. Příjde mi prostě, že python jako takový vynucuje slušné programátorské zvyklosti, to je celé. Že je ukecaný, to místy trochu je, ale alespoň není kryptický.
Což by vyznělo mnohel líp, když by se do té dokumentace nemuselo psát to, co v silně typovaných jazycích získáš signaturou. Takhle je to taková znouzecnost.
Uznávám, psát m.__doc__ je fikaný. Sice to umí i to pitomé PHP, ale Python to má tak nějak hezčejš. Což je bohužel ono.
Python je hezký jazyk. Ale chytrý ne. Je to taková blondýna.
-
Ze Singleton (navrzeny a popsany Gang of Four) je antipattern je pomerne odvazne tvrzeni.
A vzhledem k tomu, ze defaultni scope Spring beanu je prave Singleton, je to tvrzeni o to odvaznejsi.
Zrejme budou lidi kolem Springu banda matlaku.
Lidi ze Spring banda matláků není. Nezaměňuj odvahu a invenci za bezchybnost a zbožňování.
Ona spousta věcí z GoF jsou špatné nápady. Ale je fajn, že jsou pojmenované, a můžem se o nich bavit. Autorů si maximálně vážím, ale to mi nebrání o jejich závěrech špekulovat.
-
Při každé změně teploty v objektu se zavolá ten debuglog.
Tohle bych taky prosil vysvětlit. V Pythonu nedělám, takže nevím, jestli existuje třeba nějaký event pro změnu hodnot vlastností. Nicméně tohle mi připadá, že mluvíte čistě o nějaké metodě setTemperature, ve které se rovnou zavolá i log(co mi to ale jenom připomíná...), zatímco my mluvíme o přímém přiřazení a.temperature = 123.
-
V Javě tyhlety gettery ani settery nepoužívám, protože je k ničemu nepotřebuji. Na privátní atributy objektu mi tak nikdo hrabat nebude. Případný debuglog injektuji do konstruktoru.
Tohle prilis nechapu. Jakym zpusobem mi debuglog v konstrutoru umozni zalogovat, ze nekdo v 13:00:23 nastavil atribut "teplota" z "33" na "45"?
Při každé změně teploty v objektu se zavolá ten debuglog. Do konstruktoru se injektuje ten debuglogger nebo zmíněný NullObject, který v té logovací metodě nebude dělat nic.
Porad to nechapu.
Mam class Teplomer, z neho objekt tepolomer a v nem public tribut teplota.
Nekdo z venku nastavi atribut:
teplomer.teplota = 45
Jak se invokuje to zalogovani provedene zmeny atributu?
Rychly google mi ukazal toto:
http://stackoverflow.com/questions/6190468/how-to-trigger-function-on-value-change
Podle toho odkazu mam pouzit pattern Observer (taky Gang of Four) anebo gettery/settery na @property, coz je to same, co java getter/setter approach...
Takze nakonec to v Pythonu jde uplne stejne jako v Jave, akorat se tahle dira v navrhu musela dodelat dekoratorem @property... A ochrana proti primemu zapisu atributu tam stejne neni.
-
... zatímco my mluvíme o přímém přiřazení a.temperature = 123.
Viz několik příspěvků zpět. Přetížení přiřazení.
V Pythonu se __setattr__ používá spíš k přetěžování operátoru přiřazení. Tedy nikoli k omezení, ale k rozšíření funkcionality objektu.
-
Kdyby byl Python nepouzitelny jazyk, jak tvrdis, tak ho nikdo nebude pouzivat, ale on je naopak siroce pouzivany.
To je docela hezká argumentace. Ale doufám, že si uvědumuješ že má svá úskalí. Jak napsal kdosi kdesi, "Nejlepší jídlo jídlo je výkal. Tisíce much se nemůže mýlit."
Tak todle moc čitelné není a je to v haskellu (přebráno z GitHubu):
onCreate :: JNIEnv -> JObject -> JObject -> IO ()
onCreate env activity _bundle = runJNISafe () env $ do
msg <- liftIO $ do
getNumProcessors >>= setNumCapabilities
caps <- getNumCapabilities
return $ "Hello World!\nRunning on " `append` pack (show caps) `append` " CPUs!"
Co se mě týče, přijde mi tak od pohledu, že tuším, co to dělá. Ačkoliv to runJNISafe() mi trochu smrdí, a říkám si, že jsi vyhrabal prostě nějakou prasečinu.
-
... zatímco my mluvíme o přímém přiřazení a.temperature = 123.
Viz několik příspěvků zpět. Přetížení přiřazení.
V Pythonu se __setattr__ používá spíš k přetěžování operátoru přiřazení. Tedy nikoli k omezení, ale k rozšíření funkcionality objektu.
Tohle se běžně neřeší přes __setattr__, ale setter dekorátor.
http://stackoverflow.com/questions/6618002/python-property-versus-getters-and-setters
-
proměnné typu boolean nepoužívám. Bez náhrady. Těm aplikacím to prostě nechybí.
Nechodím sem často, ale skoro vždycky tady prezentujete nějaký neotřelý koncept, o kterém by mě nenapadlo ani uvažovat. Jste génius. Sepište knihu o programování. Okamžitě si jí koupím a otevřu jí vždycky, když budu mít špatnou náladu, zaručeně pobaví.
Na to stačí Ovčáček ;)
-
Viz několik příspěvků zpět. Přetížení přiřazení.
Tak pretezovani standardnich operatoru je v mem zebricku jazykovych/programatorskych prasecin bezkonkurecne na prvnim miste.
Kdo tohle vymyslel, ten by mel byt bicovan kazde rano a nucen poslouchat Country Radio do obeda. Slysis, Stroustrupe?
Neni vetsi poteseni, nez pretizit "+", aby delal "-".
-
Dobře, když máte výraz x = a(b(c(d(e(f(g)))))), tak jak otestujete, která funkce je špatně bez přepisování kódu. Jak se dozvíte, co je výsledkem c na reálných datech?
A jak se to vztahuje k FP? To jako ze tam jsou funkce tak je to FP? To co jste uvedl (asi) nepouziva ani funkce vyssich radu, vypada to jako normalni imperativni kod. Co mi brani to takto napsat v Pythonu, nebo pripadne v jazyce, ktery zadne extra FP ficury nema?
Kdyby byl Python nepouzitelny jazyk, jak tvrdis, tak ho nikdo nebude pouzivat, ale on je naopak siroce pouzivany.
Staci se podivat na PHP. Jazyk, ktery mel byt utracen davno (hrozna "specifikace", jazyk i interpret), je to jako splacane od zacinajiciho studentika VS, presto tu dal uspesne preziva. Kvalita nema bohuzel s popularitou nic spolecneho.
Rec je o pouzitelnosti, nikoliv kvalite a popularite. Je dobre rozlisovat mezi akademickou kvalitou a praktickou pouzitelnosti a zamyslet se, proc se tem akademickym jazykum v praxi tolik nedari. Velmi pravdepodobne v posouzeni kvality jazyka bude kazdy zduraznovat jine vlastnosti, rozhodne bych to neredukoval jen na cistotu syntaxe.
Tak napr. PHP je nekvalitni v tolika aspektech (casti jazyka nespecifikovane, std knihovna nema/nedodrzuje zadne konvence pojmenovani a navratovych hodnot, parser je patlany a casto jsou tam nesmysle podminky jen kvuli jednoduchosti implementace [takovou hruzu jsem nevidel snad v zadnem jinem bezne pouzivanem jazyce], konfigurace se provadi na mnoha mistech a to i u veci ze std knihovny [compile flagy, config v ini souboru, config v aplikaci, parametry dane funkce]) a rekl bych, ze prave proto i spatne pouzitelny. Byl jen na dobrem miste v dobry cas a napsalo se pro neho spostu kodu (a rozjelo dost hostingu), ktery se lidem nechce opoustet, tak u neho zustavaji. Jak pise Kit, programovat se da i v takovem bordelu, jen clovek musi presne vedet, kam nema slapat, aby neprisel o nohu.
Ja ho naopak preferuji a uprednostnuji kde muzu a nemusim naopak Javu, ktera me osobne prijde celkove tezkopadna a neohrabana.
Python me prijde stejne neohrabany jako Java. Moc to nesleduju, ale Java 8 myslim prinasela dost FP veci, coz vede k mnohem jednodussimu kodu. Osobne me prijde Scala jako dobry kompromis mezi uplatnitelnosti (JVM) a "krasou" jazyka (velmi jednoduse zapsane slozite veci, podpora DSL, FP atd).
Neumim si predstavit, ze bych neco jako scala pouzival prakticky, tj. ze bych mel odvahu to nasadit u zakaznika v rozsahu desitek tisic radkukodu a udrzoval/rozvijel to 15+ let. Pro me je to neduveryhodny a proto _prakticky_ nepouzitelny jazyk.
Prakticky se pouziva, dokonce i na dost velke veci (https://www.quora.com/What-enterprise-level-companies-are-using-the-programming-language-Scala-and-Clojure/answer/Kevin-Wright?srid=PSiE). Naopak veci v Pythonu nebo JavaScriptu s trochu vic radky bych se bal udrzovat. Bez typu se hezky vyviji v malickem meritku s malo lidmi, ale jakmile se to rozroste a uz nemate v hlave mentalni model cele aplikace, tak mate problem. V Jave/Scale vam pomuze IDE a prekladac vam kdyztak vynada, v JavaScriptu nebo Pythonu je to mnohem horsi. Treba v JS musite spolehat na dokumentaci a IDE, ze to nejak prechroupe a zobrazi zhruba co by mohlo sedet k tomu, co potrebujete.
(V podstate to stejne pise BoneFlute - v dynamickych jazycich si musite vypomahat dobrovolnymi typy v dokumentaci, ve statickych je vynucuje prekladac.)
V Pythonu me vadi velke mnozstvi boilerplatu (napr. @property, @staticmethod, lambda, nenasel jsem zpusob, jak lehce retezit volani funkci, takze pokusy o FP styl pusobi hrozne) a kod celkove pusobi roztahane.
Samozrejme na Haskell, co se tyce "krasy" a strucnosti, as nic moc nema*. A to jsem v nem "noob", pamatuji si ho pouze ze skoly. Ale uz i jen ty zaklady byly nezapomenutelne (pro ostatni studenty spise v tom spatnem slova smyslu :D).
*: Resp. nic lepsiho jsem jeste nevidel. Pokud neco znate, tak sem s tim.
Dekoratory nejsou boilerplate, to je naopak reseni eliminujici boilerplate, ktere vede k prehlednosti a strucnosti, nejsou povinne a jsou velmi flexibilni, muzes si je prizpusobit svym potrebam. Na haskellu mi nic krasneho neprijde, ale nema smysl porovnavat funkcionalni jazyk s imperativnim a tomu druhemu vycitat opacny stav. Argument, ze pokusy programovat v haskellu imperativne vypada hrozne, bych osobne povazoval za fail :-).
Je to kod, navic na cely radek (alespon tak to vsude vidim), ktery se casto opakuje. Stejne tak lambda - v jinych jazycich vidime co nejkrasi zapis, jako treba ->, => nebo \, v Pythonu je to ale cele slovo? Snad hur na tom byval jen JavaScript a i ten to uz napravil.
Ale Haskell nezavadi imperativni programovani jako nejakou svou feature, castecne ho umoznuje pomoci do notace. Python naopak se vsi slavou zavedl ruzne ficury z FP sveta (zakladni funkce nebo ty ukecane lambdy), ale uz se jaksi zapomnelo na to, ze jsou skoro nepouzitelne, protoze nejdou hezky retezit :D.
A naopak, moznost program casto a co nejdriv spoustet je jedna z vyhod interpretovanych jazyku.
Vzhledem k tomu, ze existuji inkrementalni prekladace (tusim ze jej ma Java i Scala a urcite mnoho dalsich), tak tohle je standard, ne vyhoda. Stejne tak i kompilovana Scala ma REPL, take to neni vyhrada Pythonu nebo interpretovanych jazyku.
Neni to standard a naopak, ze se o to snazi i kompilovane jazyky jen dokazuje, ze to ma smysl a je to vyhodou pro kazdy jazyk, ktery to umi.
Snazi? Ony to uz davno umi, vzdyt jinak by vyvoj v Jave byl hrozny, kdyby se vse vzdy muselo prekladat od 0. To by nesly rozumne psat (a testovat) ty dinosauri enterprise aplikace.
REPL pokud vim je i pro Javu, jen ne zatim oficialni (jestli se nepletu, tak je to soucasti nejakeho navrhu). JavaScript ma NodeJS, nebo primo prohlizec; ruby je na tom stejne jako Python, v Haskellu staci pusti ghci, atd.
To, ze Python ma REPL, ho nad konkurenci rozhodne nevysouva.
-
Viz několik příspěvků zpět. Přetížení přiřazení.
Tak pretezovani standardnich operatoru je v mem zebricku jazykovych/programatorskych prasecin bezkonkurecne na prvnim miste.
Kdo tohle vymyslel, ten by mel byt bicovan kazde rano a nucen poslouchat Country Radio do obeda. Slysis, Stroustrupe?
Neni vetsi poteseni, nez pretizit "+", aby delal "-".
Máš trauma z nějakého zpraseného kódu?
-
Myslím že volnost je ta hlavní vlastnost, nikdo tě nenutí dodržovat OOP přesně do puntíku. Naproti tomu v Java nutí programátora do OOP a programátoři to pak prostě různě obcházejí.
Java na jedné straně nutí do OOP, na druhé straně to programátoři obchází přes gettery a settery. A ještě se tím chlubí.
Gettery/settery nejak koliduji s OOP? Ja dosud zil v domeni, ze to je jedna ze zakladnich OOP vlastnosti (zapouzdreni stavu objektu a kontrolovany pristup k atributum)
Zajimave, prosim vysvetleni.
Jistěže nekolidují, je to prostě chabá náhrada za properties.
-
Viz několik příspěvků zpět. Přetížení přiřazení.
Tak pretezovani standardnich operatoru je v mem zebricku jazykovych/programatorskych prasecin bezkonkurecne na prvnim miste.
Kdo tohle vymyslel, ten by mel byt bicovan kazde rano a nucen poslouchat Country Radio do obeda. Slysis, Stroustrupe?
Neni vetsi poteseni, nez pretizit "+", aby delal "-".
Přetěžování operátorů je třeba i v C++ a k uvedenému se nezneužívá. Vždycky je nutné přetěžovat s rozvahou s dodržováním sémantiky. Napříkad
"+-" * 10v Pythonu je příkladem vhodně užitého přetížení. Je to čitelné a už od pohledu je patrné, co to dělá.
-
Mám dílema:
Obhajovat Python, protože v něm konec konců dělám, je to relativně dobrý jazyk a je pro mě dobré, když v něm bude dělat víc lidí, kteří vytvoří víc knihoven, a vůbec udělá víc příležitostí pro mě.
nebo
Nechat místní trolly a omezené javisty na python plivat, což třeba odradí některé nováčky, ze kterých by v budoucnosti mohla být konkurence. Nestojí to žádnou práci a konec konců mi může být v zadeki, co kde kdo vykládá.
Co byste vybrali vy?
-
Vydávej se za sebenenávistného Javistu, co programuje v Pythonu.
-
Mám dílema:
Obhajovat Python, protože v něm konec konců dělám, je to relativně dobrý jazyk a je pro mě dobré, když v něm bude dělat víc lidí, kteří vytvoří víc knihoven, a vůbec udělá víc příležitostí pro mě.
nebo
Nechat místní trolly a omezené javisty na python plivat, což třeba odradí některé nováčky, ze kterých by v budoucnosti mohla být konkurence. Nestojí to žádnou práci a konec konců mi může být v zadeki, co kde kdo vykládá.
Co byste vybrali vy?
Vidím to stejně, ale cokoliv zde probírat je ztráta času a jestli se někdo bude rozhodovat na základě zdejších plků? Nemyslím si...
-
Gettery/settery nejak koliduji s OOP? Ja dosud zil v domeni, ze to je jedna ze zakladnich OOP vlastnosti (zapouzdreni stavu objektu a kontrolovany pristup k atributum)
Zajimave, prosim vysvetleni.
Jistěže nekolidují, je to prostě chabá náhrada za properties.
Netusim, co je na mechanismu bena/getter/setter chabeho.
Ony to JSOU atributy.
Ve Springu v application.xml pak pracuju s beanem s atributem kozel, ktery se implementuje jako getKozel(), setKozel(), isKozel(). Prefixy jsou standardizovane a funguje to bez potizi.
Primefaces atributy mapovane na MBean dtto.
V Eclipse atributy beanu oznacim, klepnu na Generate Getters/Setters - samo se to vygeneruje a uklidi nekam dospodu class, at to neprekazi.
To je prave obrovska vyhoda a elegance javy, ze se nepokousi zbytecne kdejakou hovadinu strkat primo do jazyka.
Operatory +-*/ delaji vzdy to same. Pokud potrebuju nejaky divny soucet, no tak si zkratka udelam metodu obj.weirdAdd() a kazdy na prvni pohled vidi, ze budu delat nejaky weird add.
Java zustava z pohledu reserved words velice jednoduchy jazyk, od dohadovani uzusu je tady JSR proces.
Takovy JMX je definovan jako JSR3 (https://www.jcp.org/en/jsr/detail?id=3) a opravdu neni potreba hrabat do jazyka.
Jazyk ma zustat co nejjednodussi, jednoduse citelny a predikovatelny, problemy resit pokud mozno pouze jednim moznym zpusobem. Ne ze v perlu mam 3 zpusoby, jak zjistit delku pole, vsechny vypadaji hrozne.
Rozsirovani funkcionality je mozne prave pomoci JSR a frameworku, ktere je implementuji.
-
Netusim, co je na mechanismu bena/getter/setter chabeho.
Mám takový mlhavý pocit, že to ze strany Zboje byla ironie.
-
Porad to nechapu.
Mam class Teplomer, z neho objekt tepolomer a v nem public tribut teplota.
Nekdo z venku nastavi atribut:
teplomer.teplota = 45
Jak se na teploměru nastavuje teplota? Zahřátím v dlani?
-
Což by vyznělo mnohel líp, když by se do té dokumentace nemuselo psát to, co v silně typovaných jazycích získáš signaturou. Takhle je to taková znouzecnost.
Uznávám, psát m.__doc__ je fikaný. Sice to umí i to pitomé PHP, ale Python to má tak nějak hezčejš. Což je bohužel ono.
Python je hezký jazyk. Ale chytrý ne. Je to taková blondýna.
To vyzni dobre vzdycky, dokumentace je soucasti jazyka a nejde o to, ze lze psat m.__doc__, ale ze toho vyuzivaji ruzne nastroje, vcetne ide a ze lze z programu generovat dokumentaci.
Ad blondyna. To jsou hloupy reci, kterymi ukazujes detinskou predpojatost, ktera disivalifikuje tve nazory, jednoduse je nelze brat vazne.
Python je chytry jazyk, zakterym stoji chytri lide. Diky tomu je tak uspesny a rozsireny, prestoze za nim nestoni zadna megakorporacd. Prosadil se v rade oblasti, dnes lze povazovag za standard v oblasti univerzalnich skriptovacich jazyku a jeho popularita stale roste. Napriklad vytlacil javu z pozice nejrozsirenejsiho jazyka pro vyuku. A tusim, ze odtud prameni i iracionalni vyhrady zastancu jinych jazyku.
-
Mám dílema:
Obhajovat Python, protože v něm konec konců dělám, je to relativně dobrý jazyk a je pro mě dobré, když v něm bude dělat víc lidí, kteří vytvoří víc knihoven, a vůbec udělá víc příležitostí pro mě.
Rozhodne neobhajujte neco, jen proto ze v tom delate. Mam podezreni, ze to je duvod, proc tu to PHP jeste porad strasi. Vyvijim v JavaScriptu a rozhodne nemam potrebu ho do nebe vychvalovat. Mam na neho spise neutralni nazor, rozhodne by me nenapadlo vsem cpat NodeJS na server, kdyz si myslim, ze se to hodi jen na mikro weby (v podstate nastejno jak ten Python nebo Ruby).
nebo
Nechat místní trolly a omezené javisty na python plivat, což třeba odradí některé nováčky, ze kterých by v budoucnosti mohla být konkurence. Nestojí to žádnou práci a konec konců mi může být v zadeki, co kde kdo vykládá.
Javista nejsem (i kdyz zaklady znam), tak asi jsem troll. Tak si dovoluji oznacit i vas za trolla, at vam to oplatim ;). Python, si myslim, je pro novacky dobry, ale jak jsem psal, jen pro vyuku a male skriptiky. Na vetsi veci se mi zda neprakticky, protoze zacnete pocitovat ty chybejici typy (musite vyvazovat dokumentaci, casem a testy navic) a nepodporou IDE (at uz refaktorovani nebo treba navigaci).
Stejne jako u PHP, ani u Pythonu nerikam, ze to nejde (vim, ze se tak deje a firmy jsou casto nuceny pak prepisovat cele svoje zivobyti z PHP/Pythonu/Ruby kvuli vykonu/udrzovatelnosti do Javy/C#/Scaly) - jen tvrdim, ze je to nevhodny nastroj. Ostatne i TeX je turing-complete, takze nic nebrani firme, aby back-end pro web psali v TeXu. Jen se obavam, ze by brzy skoncila, pokud by tedy vubec nekdy zacala (kdo by chtel BE v TeXu? kdo by chtel psat BE v TeXu?).
Po pravde mam z Pythonu pocit, ze OOP podporuje jen na oko (chybejici modifikatory pristupu, __háky__, nutnost predavat metodam self a uvadet self pro pristup k poli objektu, atd.) a FP jednou omylem nekdo chtel zkusit a uz to nejak v jazyce zustalo, prestoze ty vlastnosti jsou tam celkem nanic.
Chapu, ze ukecanost je subjektivni, a jsou lidi, kterym Java vyhovuje (ukecanost se postupne trochu snizuje, treba ta podpora lambd nebo * v typovych parametrech). Ja mezi ne nepatrim a naopak ocenuji strucny zapis ala Scala*, LiveScript nebo Haskell.
*: Casto zavidim Haskellistum nadupanou typovou inferenci, ale jak jsem psal vyse, Scala je IMO dobry kompromis mezi krasou a prakticnosti. JVM je snad nejrychlejsi VM a mam pristup ke vsem knihovnam a nastrojum z Java sveta.
-
je tak uspesny a rozsireny
Ono argumentovat popularitou je dost ošemetné. Kdybych to měl přirovnat třeba k hudbě, tak takový Justin Bieber má na YT miliardy shlédnutí a přitom objektivně jeho produkce stojí za hovno. Popularita a kvalita bohužel ne vždy jdou ruku v ruce a často se vyloženě rozcházejí. Někdy se to krásně sejde, ale jedno automaticky nevyplývá z druhého.
-
Napriklad vytlacil javu z pozice nejrozsirenejsiho jazyka pro vyuku. A tusim, ze odtud prameni i iracionalni vyhrady zastancu jinych jazyku.
Podle teto logiky bych mel byt vzteky bez sebe, kdyz se na mistni ZS pouziva k vyuce Baltik misto Javy? To jako myslite vazne? ;D
Pokud jsou nejake me vyhrady iracionalni, tak je prosim racionalne vyvratte. Jinak povazuji vasi poznamku o iracionalnich vyhradach za iracionalni.
-
To co já považuju na Pythonu za velice dobrého je, že nutí všechny vývojáře psát stejně strukturovaný kód (pravda kopírování kódu je pak občas peklo)
To má Haskell taky.
a dále že přímo integruje dokumentaci. Součástí definice jazyka je prostě i způsob jak dokumentovat a nástoje (žlutou vlnovkou) opozorňují že dokumentace chybí. Příjde mi prostě, že python jako takový vynucuje slušné programátorské zvyklosti, to je celé. Že je ukecaný, to místy trochu je, ale alespoň není kryptický.
Což by vyznělo mnohel líp, když by se do té dokumentace nemuselo psát to, co v silně typovaných jazycích získáš signaturou. Takhle je to taková znouzecnost.
Uznávám, psát m.__doc__ je fikaný. Sice to umí i to pitomé PHP, ale Python to má tak nějak hezčejš. Což je bohužel ono.
Python je hezký jazyk. Ale chytrý ne. Je to taková blondýna.
Spousta funkcí v haskellu má nic neříkající typovou signaturu jako a -> a. Například většina matematických funkcí má signaturu Floating a => a -> a. Docstring v pythonu často obsahuje příklad použití, který mohu spustit jako test.
-
Mám dílema:
Obhajovat Python, protože v něm konec konců dělám, je to relativně dobrý jazyk a je pro mě dobré, když v něm bude dělat víc lidí, kteří vytvoří víc knihoven, a vůbec udělá víc příležitostí pro mě.
nebo
Nechat místní trolly a omezené javisty na python plivat, což třeba odradí některé nováčky, ze kterých by v budoucnosti mohla být konkurence. Nestojí to žádnou práci a konec konců mi může být v zadeki, co kde kdo vykládá.
Co byste vybrali vy?
Dobrý jazyk se "obhájí" sám ;)
-
Spousta funkcí v haskellu má nic neříkající typovou signaturu jako a -> a. Například většina matematických funkcí má signaturu Floating a => a -> a.
Co je na tom nic neříkajícího?
Docstring v pythonu často obsahuje příklad použití, který mohu spustit jako test.
To má Haskell taky.
Prosím nezaměňujte typovou deklaraci s dokumentací. Haskell má úplně stejný problém jako Python s tím, že vývojáři flákaj dokumentaci. Výhodou Haskellu v tomto je ta, že si jazyk vynutí alespoň tu siganturu.
Když mám mám v Pythonu funkci:
def format(a):
"""Formátuje argument a"""
...
tak mám dělat jako co prosím?
-
Když mám mám v Pythonu funkci:
def format(a):
"""Formátuje argument a"""
...
tak mám dělat jako co prosím?
Přečíst si tělo funkce. Dokumentace je stejně skoro vždycky out of date... :D
-
Což by vyznělo mnohel líp, když by se do té dokumentace nemuselo psát to, co v silně typovaných jazycích získáš signaturou. Takhle je to taková znouzecnost.
Uznávám, psát m.__doc__ je fikaný. Sice to umí i to pitomé PHP, ale Python to má tak nějak hezčejš. Což je bohužel ono.
Python je hezký jazyk. Ale chytrý ne. Je to taková blondýna.
To vyzni dobre vzdycky, dokumentace je soucasti jazyka a nejde o to, ze lze psat m.__doc__, ale ze toho vyuzivaji ruzne nastroje, vcetne ide a ze lze z programu generovat dokumentaci.
No, nemohu si teď rychle vzpomenout na jazyk, u kterého z kódu nelze generovat dokumentaci.
Zato si třeba nedovedu představit, jak bych z kódu v Pythonu strojově generoval případy užití (z účelem obohacení dokumentace). Možná by to šlo ručním odvozování typů, ...
Ad blondyna. To jsou hloupy reci, kterymi ukazujes detinskou predpojatost, ktera disivalifikuje tve nazory, jednoduse je nelze brat vazne.
Přiznávám určitou předpojatost. Dlouho jsem si dělal naději, že budu používat Python jako můj hlavní jazyk. Těšil jsem se na komunitu, snadnost psaní, pohodlnost a znovupoužitelnost, flexibilitu.
Naučil jsem se ho. A celkem dlouho používal. Napsal jsem v něm i pár pěknejch věcí.
No, a naštval mě. Takže ano, jsem předpojatý. Nebo možná spíše zklamaný.
-
Rozhodne neobhajujte neco, jen proto ze v tom delate. Mam podezreni, ze to je duvod, proc tu to PHP jeste porad strasi. Vyvijim v JavaScriptu a rozhodne nemam potrebu ho do nebe vychvalovat. Mam na neho spise neutralni nazor, rozhodne by me nenapadlo vsem cpat NodeJS na server, kdyz si myslim, ze se to hodi jen na mikro weby (v podstate nastejno jak ten Python nebo Ruby).
To rozhodně nemám v plánu.
Jinak dělám v py nikoliv proto, že bych musel, nebo protože by mi to bylo vnuceno někde na škole. V roce 2007 jsem zkoumal co dál, tak jsem sepsal 2 stránky pro a proti všemožných jazyků, všechny je prozkoumal, pročetl wikipedii, homepage, zkusil si je nainstalovat a napsat v nich něco triviálního, ohodnotil je subjektivními body a pak si z nich vybral python. A od té doby v něm dělám a posledních několik let mě za to i lidi platí.
Na vetsi veci se mi zda neprakticky, protoze zacnete pocitovat ty chybejici typy (musite vyvazovat dokumentaci, casem a testy navic) a nepodporou IDE (at uz refaktorovani nebo treba navigaci).
Zrovna tohle je typický argument. O pythonu už jsem tu vedl několik diskuzí, které vždycky skončí stejně: já ukážu na nějaký projekt, dodám zkušenost s práce na větším systému (desítky tisíc řádků podle cloc bez komentářů, prázdných řádků a tak) a ostatní se hádají, že to prostě nemůže fungovat, i když to funguje.
Pak se to zvrhne na hádku o typových systémech, kde javisti dokazují, že když to nefunguje jako v javě, tak to nemůže být použitelné pro cokoliv kromě trivialit, pythonisti se frustrovaně snaží vysvětlit, že to fakt funguje, což je prostě pozorování, ne teorie, pak přijde někdo s tím, že ducktyping je bullshit a že mu nerozumí, haskellisti, ocamlisti a další typoví guru se smějí na pozadí. Do toho přijdou lopaťáci, kteří začnou vykřikovat cosi o lopatách, trolové, kteří prostě jen krmí některý z táborů čímkoliv, na co budou reagovat a drama je na světě.
Ono vůbec, u pythonu narážím na to, že spousta lidí vůbec nechápe, že má svojí vlastní filosofii a nejde jen tak přijít z javy, naučit se základy syntaxe a začít v něm javit, protože pak z toho lezou výblitky, které je horor udržovat a tohle pak javisti berou jako důkaz, že python nestojí za nic.
Stejne jako u PHP, ani u Pythonu nerikam, ze to nejde (vim, ze se tak deje a firmy jsou casto nuceny pak prepisovat cele svoje zivobyti z PHP/Pythonu/Ruby kvuli vykonu/udrzovatelnosti do Javy/C#/Scaly) - jen tvrdim, ze je to nevhodny nastroj. Ostatne i TeX je turing-complete, takze nic nebrani firme, aby back-end pro web psali v TeXu. Jen se obavam, ze by brzy skoncila, pokud by tedy vubec nekdy zacala (kdo by chtel BE v TeXu? kdo by chtel psat BE v TeXu?).
Skvělá šikmá plocha. Protože lopatička není koloběžka, tak ani v javě se nedá psát komplexní projekt.
Že to nedává smysl? No, to tyhle jazykové analogie fakt nedávají, což ale nikomu nebrání je používat, že. Tady se třeba cosi snažíš dokázat na TeXu, který má s pythonem společného co? Nic.
Po pravde mam z Pythonu pocit, ze OOP podporuje jen na oko (chybejici modifikatory pristupu, __háky__, nutnost predavat metodam self a uvadet self pro pristup k poli objektu, atd.) a FP jednou omylem nekdo chtel zkusit a uz to nejak v jazyce zustalo, prestoze ty vlastnosti jsou tam celkem nanic.
Já mám zas pocit, že nemáš tušení co je to OOP, ani FP. Modifikátory přístupu například vůbec v původním OOP (smalltalk, self) nebyly a ani být nemusí. To je jen demence, když to pak roubovali na pokroucený zprasený systém C++ a Javy (Oaku, heh).
Python podporuje „privátní“ atributy pomocí __, kde ti interpreter vyhodí chybu, když k tomu zkusíš přistoupit.
>>> class Xe(object):
... def __private(self):
... return 1
...
>>> x = Xe()
>>> x.__private()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'Xe' object has no attribute '__private'
Na druhou stranu ti v tom fakt nebude bránit, pokud víš co děláš:
>>> x._Xe__private()
1
Což je podle mě v pořádku. Když programátor fakt ví co chce, tak si může dělat co chceš a ty jako programátor knihovny mu v tom nezabráníš, i kdyby ses posral a nadefinoval si private úplně všechno. To jen lidi co přichází z Javy / C# mají urputný pocit, že když to neudělají, tak dojde ke konci světa. Nedojde. Prostě to spadne někomu, kdo dělá věci co by neměl, což není můj problém. Naopak progrmátorům, kteří ví co dělají a třeba chtějí jen mocknout nějakou hodnotu pro účely testování to může ušetřit shitload práce.
Jinak kdysi jsem na tom byl stejně, takže chápu, kde se tahle mentalita bere, můžu tě ale ujistit, že je to falešný pocit nutnosti něčeho, co fakt nutné není.
__háky__
Magické metody jsou naopak docela chytrý koncept systematizovaného metaobjektového (https://en.wikipedia.org/wiki/Metaobject) komunikačního protokolu. Stěžovat si na ně je stejná blbost, jako stěžovat si na konvenci používání metody nazvané toString() v jiných jazycích.
nutnost predavat metodam self a uvadet self pro pristup k poli objektu
Jo, to se může jevit jako opruz. Na druhou stranu to umožňuje dekorátorům pracovat s instancemi objektu za běhu, což se používá v pokročilém metaprogramování. Má to i pár dalších výhod a dává to konzistentní smysl, ale to člověk nevidí, dokud nepřekročí základy.
Ono argumentovat popularitou je dost ošemetné. Kdybych to měl přirovnat třeba k hudbě, tak takový Justin Bieber má na YT miliardy shlédnutí a přitom objektivně jeho produkce stojí za hovno. Popularita a kvalita bohužel ne vždy jdou ruku v ruce a často se vyloženě rozcházejí. Někdy se to krásně sejde, ale jedno automaticky nevyplývá z druhého.
Hahah. Tohle mě pobavilo, hlavně proto, že pamatuju ještě ty časy, kdy tomu tak nebylo a lidi argumentovali proti pythonu tím, že je nepopulární a v čechách v něm moc lidí nedělá. Teď je populární a lidi argumentují zase opakem :D
-
Když mám mám v Pythonu funkci:
def format(a):
"""Formátuje argument a"""
...
tak mám dělat jako co prosím?
Aha, protože tohle je fakt problém pythonu a vůbec ne demence vývojáře, která se nedá napsat v libovolném jazyce. Fakt by mě zajímalo, co se tím přesně snažíš dokázat, protože to samé můžu napsat v libovolném jazyce, třeba v Javě:
// Formátuje a.
public static string format(Object a){
...
}
To ti ty typové anotoce fakt pomůžou, že?
-
Když mám mám v Pythonu funkci:
def format(a):
"""Formátuje argument a"""
...
tak mám dělat jako co prosím?
Aha, protože tohle je fakt problém pythonu a vůbec ne demence vývojáře, která se nedá napsat v libovolném jazyce. Fakt by mě zajímalo, co se tím přesně snažíš dokázat, protože to samé můžu napsat v libovolném jazyce, třeba v Javě:
// Formátuje a.
public static string format(Object a){
...
}
To ti ty typové anotoce fakt pomůžou, že?
A nechtěl by sis přečíst celý můj příspěvek? Tak hrozný romány to zase nejsou...
-
Spousta funkcí v haskellu má nic neříkající typovou signaturu jako a -> a. Například většina matematických funkcí má signaturu Floating a => a -> a.
Co je na tom nic neříkajícího?
Docstring v pythonu často obsahuje příklad použití, který mohu spustit jako test.
To má Haskell taky.
Prosím nezaměňujte typovou deklaraci s dokumentací. Haskell má úplně stejný problém jako Python s tím, že vývojáři flákaj dokumentaci. Výhodou Haskellu v tomto je ta, že si jazyk vynutí alespoň tu siganturu.
Když mám mám v Pythonu funkci:
def format(a):
"""Formátuje argument a"""
...
tak mám dělat jako co prosím?
Není explicitní typová signatura v haskellu nepoviná?
V pythonu můžete do docstringu přidat jednoduchý test.
např:
def format(a):
"""Formátuje argument a
>>> format('hello')
'<p>hello</p>'
"""
return '<p>%s</p>' % a
který spustíte python -m doctest nazev_souboru.py
-
A nechtěl by sis přečíst celý můj příspěvek? Tak hrozný romány to zase nejsou...
Četl jsem*, argument je stále stejný. Tohle je problém který vůbec nesouvisí s pythonem, protože je stejný všude. Špatně udělanou dokumentaci prostě typový systém nijak nespasí. Nehledě na to, že když je takhle prasácky udělaná dokumentace, tak nemám žádný důvod předpokládat, že typové anotace budou dobře.
*pokud se v tom teda neztrácím.
-
nutnost predavat metodam self a uvadet self pro pristup k poli objektu
Jo, to se může jevit jako opruz. Na druhou stranu to umožňuje dekorátorům pracovat s instancemi objektu za běhu, což se používá v pokročilém metaprogramování. Má to i pár dalších výhod a dává to konzistentní smysl, ale to člověk nevidí, dokud nepřekročí základy.
Tohle jsem zpočátku viděl jako opruz, ale dnes to vidím jako velkou výhodu, protože je velmi snadno rozlišitelné, která proměnná je instanční a která lokální. V Javě se také musí při kolizi používat "this".
-
Spousta funkcí v haskellu má nic neříkající typovou signaturu jako a -> a. Například většina matematických funkcí má signaturu Floating a => a -> a.
Co je na tom nic neříkajícího?
Docstring v pythonu často obsahuje příklad použití, který mohu spustit jako test.
To má Haskell taky.
Prosím nezaměňujte typovou deklaraci s dokumentací. Haskell má úplně stejný problém jako Python s tím, že vývojáři flákaj dokumentaci. Výhodou Haskellu v tomto je ta, že si jazyk vynutí alespoň tu siganturu.
Když mám mám v Pythonu funkci:
def format(a):
"""Formátuje argument a"""
...
tak mám dělat jako co prosím?
Doctestová knihovna pro haskell sice existuje, ale používá jí někdo?
-
Není explicitní typová signatura v haskellu nepoviná?
Protože má automatické odvozování typu.
V pythonu můžete do docstringu přidat jednoduchý test.
např:
def format(a):
"""Formátuje argument a
>>> format('hello')
'<p>hello</p>'
"""
return '<p>%s</p>' % a
který spustíte python -m doctest nazev_souboru.py
To je hezký (bez ironie).
Četl jsem*, argument je stále stejný. Tohle je problém který vůbec nesouvisí s pythonem, protože je stejný všude. Špatně udělanou dokumentaci prostě typový systém nijak nespasí. Nehledě na to, že když je takhle prasácky udělaná dokumentace, tak nemám žádný důvod předpokládat, že typové anotace budou dobře.
*pokud se v tom teda neztrácím.
Snažíš se narvat do otevřených dveří.
Python i Haskell má stejný problém. Nepíše se dokumentace.
Faktem je, že v Pythonu máš pouze dokumentaci. Jejíž kvalita stojí a padá na vývojáři.
V Haskellu základní věci dokumentovat nemusíš, protože ti to zdokumentuje Typovej systém. Ten ti taky zajistí, že to bude aktuální a korektní.
V Haskellu nemůžeš napsat špatné typové anotace. (Můžou neodpovídat zadání, to samozřejmě jo.)
-
V Haskellu základní věci dokumentovat nemusíš, protože ti to zdokumentuje Typovej systém. Ten ti taky zajistí, že to bude aktuální a korektní.
Tak to je samozřejmě pravda. S velkým důrazem na ty „základní věci“, které jsou většinou méně výraznou součástí informace, kterou od dokumentace chci. Primárně vědět „co to dělá a proč“, než „nad čím a co z toho leze“.
Python i Haskell má stejný problém. Nepíše se dokumentace.
Citation needed.
Jen pro pořádek, zrovna o dokumentaci v pythonu mám rozepsaný článek*, který shrnuje mé zkušenosti z používání mnoha desítek opensource knihoven a dokumentace se píše. Dokonce celý populární ReadTheDocs, který je dneska používaný pro velkou část všemožného OSS vznikl z pythonního dokumentačního systému Sphinx.
Rád bych tedy věděl, z čeho usuzuješ, že je to podstatný problém, protože si opravdu nejsem vědom toho, že by se nepsala dokumentace. Spíš bych řekl, že naopak - pokud někdo nepíše dokumentaci, tak nemá vůbec šanci uspět se svojí knihovnou. Uznávám, že nevím, jak je na tom haskell. Různé jazyky jsou různé, ale nepouštěl bych tvrzení o pythonu jen na základě zkušenosti s haskellem.
*součást většího seriálu o pythonu v praxi, datum vydání nejdřív za pár měsíců.
-
V Haskellu základní věci dokumentovat nemusíš, protože ti to zdokumentuje Typovej systém. Ten ti taky zajistí, že to bude aktuální a korektní.
Tak to je samozřejmě pravda. S velkým důrazem na ty „základní věci“, které jsou většinou méně výraznou součástí informace, kterou od dokumentace chci. Primárně vědět „co to dělá a proč“, než „nad čím a co z toho leze“.
Haskell toho umí hodně. Ale to už nesouvisí s Pythonem.
Python i Haskell má stejný problém. Nepíše se dokumentace.
Citation needed.
Jen pro pořádek, zrovna o dokumentaci v pythonu mám rozepsaný článek*, který shrnuje mé zkušenosti z používání mnoha desítek opensource knihoven a dokumentace se píše. Dokonce celý populární ReadTheDocs, který je dneska používaný pro velkou část všemožného OSS vznikl z pythonního dokumentačního systému Sphinx.
Rád bych tedy věděl, z čeho usuzuješ, že je to podstatný problém, protože si opravdu nejsem vědom toho, že by se nepsala dokumentace. Spíš bych řekl, že naopak - pokud někdo nepíše dokumentaci, tak nemá vůbec šanci uspět se svojí knihovnou. Uznávám, že nevím, jak je na tom haskell. Různé jazyky jsou různé, ale nepouštěl bych tvrzení o pythonu jen na základě zkušenosti s haskellem.
*součást většího seriálu o pythonu v praxi, datum vydání nejdřív za pár měsíců.
Netřeba. Je to jen a pouze má zkušenost, a mé vysoké nároky které kladu na dokumentaci. A jsou to zkušenosti z používání Pythonu a Haskellu. Co se dokumentace týče, tak jsou na tom stejně. Stejně blbě. Proto mi vyhovuje, že u toho Haskellu se můžu spolehnout alespoň na něco.
-
Na vetsi veci se mi zda neprakticky, protoze zacnete pocitovat ty chybejici typy (musite vyvazovat dokumentaci, casem a testy navic) a nepodporou IDE (at uz refaktorovani nebo treba navigaci).
Zrovna tohle je typický argument. O pythonu už jsem tu vedl několik diskuzí, které vždycky skončí stejně: já ukážu na nějaký projekt, dodám zkušenost s práce na větším systému (desítky tisíc řádků podle cloc bez komentářů, prázdných řádků a tak) a ostatní se hádají, že to prostě nemůže fungovat, i když to funguje.
Ehm, vzdyt na to jsem odpovel v prispevku, ktery citujete.
Stejne jako u PHP, ani u Pythonu nerikam, ze to nejde ... jen tvrdim, ze je to nevhodny nastroj.
a ten drivejsi, na ktery jsem se odkazoval:
...
Jak pise Kit, programovat se da i v takovem bordelu, jen clovek musi presne vedet, kam nema slapat, aby neprisel o nohu.
...
Prakticky se pouziva, dokonce i na dost velke veci (https://www.quora.com/What-enterprise-level-companies-are-using-the-programming-language-Scala-and-Clojure/answer/Kevin-Wright?srid=PSiE). Naopak veci v Pythonu nebo JavaScriptu s trochu vic radky bych se bal udrzovat. Bez typu se hezky vyviji v malickem meritku s malo lidmi, ale jakmile se to rozroste a uz nemate v hlave mentalni model cele aplikace, tak mate problem. V Jave/Scale vam pomuze IDE a prekladac vam kdyztak vynada, v JavaScriptu nebo Pythonu je to mnohem horsi. Treba v JS musite spolehat na dokumentaci a IDE, ze to nejak prechroupe a zobrazi zhruba co by mohlo sedet k tomu, co potrebujete.
(V podstate to stejne pise BoneFlute - v dynamickych jazycich si musite vypomahat dobrovolnymi typy v dokumentaci, ve statickych je vynucuje prekladac.)
Pak se to zvrhne na hádku o typových systémech, kde javisti dokazují, že když to nefunguje jako v javě, tak to nemůže být použitelné pro cokoliv kromě trivialit, pythonisti se frustrovaně snaží vysvětlit, že to fakt funguje, což je prostě pozorování, ne teorie, pak přijde někdo s tím, že ducktyping je bullshit a že mu nerozumí, haskellisti, ocamlisti a další typoví guru se smějí na pozadí. Do toho přijdou lopaťáci, kteří začnou vykřikovat cosi o lopatách, trolové, kteří prostě jen krmí některý z táborů čímkoliv, na co budou reagovat a drama je na světě.
Nikdy jsem nepsal (viz citace vyse), ze to nejde bez statickych typu, jen ze je to zbytecny opruz. Opravdu nevim, jestli podle vas jsem v nejake z tech kategorii, protoze prvni kategorii nesplnuji, pythonista nejsem (ocividne), ducktyping pouzivam denne v praci a na typoveho guru se moc necitim, kdyz pomalu nedavam ani zaklady ScalaZ (celkem hardcore FP knihovna).
Ono vůbec, u pythonu narážím na to, že spousta lidí vůbec nechápe, že má svojí vlastní filosofii a nejde jen tak přijít z javy, naučit se základy syntaxe a začít v něm javit, protože pak z toho lezou výblitky, které je horor udržovat a tohle pak javisti berou jako důkaz, že python nestojí za nic.
Python jsem zkousel (spise byl nucen pouzivat) po urcitych zkusenostech s C#, Javou a Scalou. Naopak jsem srovnaval se Scalou, protoze Python mi byl popisovan jako krasny a celkem strucny jazyk, ve kterem se rychle vyviji. Jak z mych prispevku vyplvyva, ma ocekavani nesplnil. Po pravde po zkusenostech s kolekcemi ze Scaly nevim, zda vubec nejaky jazyk se ji priblizil (napr. v Pythonu* nelze ani pomalu psat funckionalne [ukecane lambdy, chybejici retezeni]; JavaScript je funkcionalni, od ES6 umi i hezky kondenzovane fat-arrow funkce, ale bez externi knihovny take hodne slaby [co se vyberu funkci tyce]).
*: Nasel jsem jakesi reseni v podobe doimplementovani pipe opratoru a preimplementovani zabudovanych funkci jako map nebo filter na curried variantu. IMO celkem hnusne reseni - narovnavak na ohybak.
Stejne jako u PHP, ani u Pythonu nerikam, ze to nejde (vim, ze se tak deje a firmy jsou casto nuceny pak prepisovat cele svoje zivobyti z PHP/Pythonu/Ruby kvuli vykonu/udrzovatelnosti do Javy/C#/Scaly) - jen tvrdim, ze je to nevhodny nastroj. Ostatne i TeX je turing-complete, takze nic nebrani firme, aby back-end pro web psali v TeXu. Jen se obavam, ze by brzy skoncila, pokud by tedy vubec nekdy zacala (kdo by chtel BE v TeXu? kdo by chtel psat BE v TeXu?).
Skvělá šikmá plocha. Protože lopatička není koloběžka, tak ani v javě se nedá psát komplexní projekt.
Že to nedává smysl? No, to tyhle jazykové analogie fakt nedávají, což ale nikomu nebrání je používat, že. Tady se třeba cosi snažíš dokázat na TeXu, který má s pythonem společného co? Nic.
Opet, nerikam ze se v TeXu neda napsat skvely back-end, jen to podle me neni vhodny nastroj (stejne jako Python - takze neco spolecneho maji) a minimalne z dlouhodobeho hlediska se to prodrazi. Sam bych nejradsi misto JavaScriptu pouzival treba TypeScript nebo ScalaJS, vetsinu chyb by odhalil prekladac a nemusel bych ani nic testovat. A to nyni v podstate vyvijim v jednom cloveku jen par mesicu, takze je to pidi projekt oproti tomu, co pisete. Mit treba projekt v Pythonu (nebo klidne i NodeJS, at nerikate, ze jsem zaujaty vuci Pythonu) o desitkach nebo stovkach tisicu radek s nekolika vyvojari stary treba 5 let? Eh, hned bych hledal zpusob, jak prejit jinam, kor kdybych prisel k hotovemu a nevedel o tom projektu zhola nic.
Po pravde mam z Pythonu pocit, ze OOP podporuje jen na oko (chybejici modifikatory pristupu, __háky__, nutnost predavat metodam self a uvadet self pro pristup k poli objektu, atd.) a FP jednou omylem nekdo chtel zkusit a uz to nejak v jazyce zustalo, prestoze ty vlastnosti jsou tam celkem nanic.
Já mám zas pocit, že nemáš tušení co je to OOP, ani FP. Modifikátory přístupu například vůbec v původním OOP (smalltalk, self) nebyly a ani být nemusí. To je jen demence, když to pak roubovali na pokroucený zprasený systém C++ a Javy (Oaku, heh).
Ano, priznavam, ze puvodni OOP neznam (aktualni prakticky pouzivane OOP ano). Ale nejak se mi nepozdava, ze treba zapouzdreni by tam chybelo, coz snad ty modifikatory pristupu zajistuji. K tomu, ze neznam FP jsi nejak nic nenapsal. Jako nutne to nevyvracim, ale zaklady FP si myslim znam celkem dobre. A pokud jazyk chce byt trosku funkcionalni, tak nutnost pouzivat hacky k dosazeni beznych operaci umoznujicich ono FP mi prijde dost mimo.
Python podporuje „privátní“ atributy pomocí __, kde ti interpreter vyhodí chybu, když k tomu zkusíš přistoupit.
...
Na druhou stranu ti v tom fakt nebude bránit, pokud víš co děláš:
>>> x._Xe__private()
1
Tohle me prijde jako prilis snadne obejiti zapouzdreni (a ano, i v JavaScriptu bych uvital modifikatory pristupu, ne jen skryvani "privatnich" promennych do closure). Ono i v Java svete nebyva problem pomoci reflexe nebo primo pres bytekod tridy zpristupnit privatni data, ale je to o uroven dal, nez jen zavolat jinak pojmenovanou metodu (programator opravdu vi, ze dela neco hodne nestandardniho a nestava se, ze novacci pouzivaji privatni veci, protoze neni tak trivialni k nim pristupovat).
Což je podle mě v pořádku. Když programátor fakt ví co chce, tak si může dělat co chceš a ty jako programátor knihovny mu v tom nezabráníš, i kdyby ses posral a nadefinoval si private úplně všechno. To jen lidi co přichází z Javy / C# mají urputný pocit, že když to neudělají, tak dojde ke konci světa. Nedojde. Prostě to spadne někomu, kdo dělá věci co by neměl, což není můj problém. Naopak progrmátorům, kteří ví co dělají a třeba chtějí jen mocknout nějakou hodnotu pro účely testování to může ušetřit shitload práce.
Jinak kdysi jsem na tom byl stejně, takže chápu, kde se tahle mentalita bere, můžu tě ale ujistit, že je to falešný pocit nutnosti něčeho, co fakt nutné není.
Osobne to preferuji, kdyz mi jazyk primo umoznuje omezovat pristup. Prijde me, ze do tymu je to mnohem lepsi pristup. Kdyz se opet podivam do JS sveta, tak tam byvaji nehezke zaludne a tezce dohledatelne bugy, kdyz se nekdo, nebo jeste lepe nejaka knihovna, rozhodne "opravit" funkci nejakeho standardniho typu (monkey patching).
__háky__
Magické metody jsou naopak docela chytrý koncept systematizovaného metaobjektového (https://en.wikipedia.org/wiki/Metaobject) komunikačního protokolu. Stěžovat si na ně je stejná blbost, jako stěžovat si na konvenci používání metody nazvané toString() v jiných jazycích.
Zcela uprimne - prijde me to ohavne, to jsem od "krasneho" jazyka necekal. Proc radeji nezvolili jiny znak, pouze 1 znak, jako prefix, proc radeji 2x 2 podtrzitka?
Reflexe je i v jinych jazycich (jestli to chapu dobre) a vetsinou je povazovana za zverstvo, ktere se smi pouzivat pouze ve velmi specifickych pripadech typu knihovny kvuli hezci syntaxi. Podobne jako eval v JavaScriptu. Ma sice sve misto, ale v normalnim projektu typu web to misto rozhodne neni.
nutnost predavat metodam self a uvadet self pro pristup k poli objektu
Jo, to se může jevit jako opruz. Na druhou stranu to umožňuje dekorátorům pracovat s instancemi objektu za běhu, což se používá v pokročilém metaprogramování. Má to i pár dalších výhod a dává to konzistentní smysl, ale to člověk nevidí, dokud nepřekročí základy.
Troufam si rict, ze v JavaScriptu jsem davno prekrocil zaklady, a rozhodne nemam v lasce nutnost vsude ve tride uvadet "this". CoffeeScript to vyresil celkem elegantne, misto "this" prisel s jednim znakem - @. Po pravde az v Pythonu vidim, ze se musi pouzivat this/self i jako parametr metody. Nevim, ja to vse vnimam tak, ze je to do Pythonu dolepene.
Ono argumentovat popularitou je dost ošemetné. Kdybych to měl přirovnat třeba k hudbě, tak takový Justin Bieber má na YT miliardy shlédnutí a přitom objektivně jeho produkce stojí za hovno. Popularita a kvalita bohužel ne vždy jdou ruku v ruce a často se vyloženě rozcházejí. Někdy se to krásně sejde, ale jedno automaticky nevyplývá z druhého.
Hahah. Tohle mě pobavilo, hlavně proto, že pamatuju ještě ty časy, kdy tomu tak nebylo a lidi argumentovali proti pythonu tím, že je nepopulární a v čechách v něm moc lidí nedělá. Teď je populární a lidi argumentují zase opakem :D
To, ze je jazyk popularni jej nedela dobrym (meh, PHP nebo i starsi verze JavaScriptu nejsou nejake prevratne) a ani naopak.
Mimochodem Python je tu opravdu tak popularni? Vsude v inzeratech totiz vidim jen Javu a C# na ty velke veci. Na male naopak jen PHP :-X.
A celkove, nemate nekdo nejake statistiky o popularite jazyku u firem v CR/SK? By me zajimal treba takovy Haskell (slysel jsem, ze i v Brne v nem kdesi delaji) nebo Scala ci Groovy.
-
Ano, priznavam, ze puvodni OOP neznam (aktualni prakticky pouzivane OOP ano). Ale nejak se mi nepozdava, ze treba zapouzdreni by tam chybelo, coz snad ty modifikatory pristupu zajistuji.
Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.
-
Mimochodem Python je tu opravdu tak popularni? Vsude v inzeratech totiz vidim jen Javu a C# na ty velke veci. Na male naopak jen PHP :-X.
Samozřejmě není. Na malé projekty klidně. Často startupy, ale ty nemají peníze. Pokud chceš normální peníze, tak na Python zapomeň, ten je tak za půlku. Asi to není náhoda...
-
Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.
No a nekdy to tak není a přístup k atributu přes getter či setter dává perfektní smysl. Co je na tom tak těžkého k pochopení? Navíc to perfektní zapouzdření je blbost, kdyby se vnitřní stav nějak neprojevil na chování objektu, nemusí tam ty atributy být vůbec že :-) Takže zapouzdření samozřejmě ano, ale pokud někdo cítí potřebu získat přístup například ke klasickému hodnotovému objektu a jeho atributům, nevidím v tom problém, i když třeba FP přístup má jiné prostředky (imho lepší, ale to je spíše na jinou debatu)
-
__háky__
Magické metody jsou naopak docela chytrý koncept systematizovaného metaobjektového (https://en.wikipedia.org/wiki/Metaobject) komunikačního protokolu. Stěžovat si na ně je stejná blbost, jako stěžovat si na konvenci používání metody nazvané toString() v jiných jazycích.
Zcela uprimne - prijde me to ohavne, to jsem od "krasneho" jazyka necekal. Proc radeji nezvolili jiny znak, pouze 1 znak, jako prefix, proc radeji 2x 2 podtrzitka?
Reflexe je i v jinych jazycich (jestli to chapu dobre) a vetsinou je povazovana za zverstvo, ktere se smi pouzivat pouze ve velmi specifickych pripadech typu knihovny kvuli hezci syntaxi. Podobne jako eval v JavaScriptu. Ma sice sve misto, ale v normalnim projektu typu web to misto rozhodne neni.
Nechápete to dobre. Já bych magické metody popsal jako rozhraní, které je společné všem objektům. S reflexí to nemá mnoho společného.
nutnost predavat metodam self a uvadet self pro pristup k poli objektu
Jo, to se může jevit jako opruz. Na druhou stranu to umožňuje dekorátorům pracovat s instancemi objektu za běhu, což se používá v pokročilém metaprogramování. Má to i pár dalších výhod a dává to konzistentní smysl, ale to člověk nevidí, dokud nepřekročí základy.
Troufam si rict, ze v JavaScriptu jsem davno prekrocil zaklady, a rozhodne nemam v lasce nutnost vsude ve tride uvadet "this". CoffeeScript to vyresil celkem elegantne, misto "this" prisel s jednim znakem - @. Po pravde az v Pythonu vidim, ze se musi pouzivat this/self i jako parametr metody. Nevim, ja to vse vnimam tak, ze je to do Pythonu dolepene.
Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.
-
Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.
Dik za vysvetleni.
Tak ale v tom pripade je Python jeste mene "OOP" nez Java, pokud v podstate nema zapouzdreni, nebo ne?
Jinak to oddeleni dat od funkci zni jako FP, uz jen chybi se zbavit tech setteru :).
-
Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.
Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat! :D
-
Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.
Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat! :D
Jak píše Kit výše. Psaní self zlepšuje čitelnost. Oproti Javě toho pořád dokola jako retard moc nepíšu. Dekorátory v Javě opravdu nefungují. Dekorátor v pythonu je něco jiného než návrhový vzor dekorátor.
-
__háky__
Magické metody jsou naopak docela chytrý koncept systematizovaného metaobjektového (https://en.wikipedia.org/wiki/Metaobject) komunikačního protokolu. Stěžovat si na ně je stejná blbost, jako stěžovat si na konvenci používání metody nazvané toString() v jiných jazycích.
Zcela uprimne - prijde me to ohavne, to jsem od "krasneho" jazyka necekal. Proc radeji nezvolili jiny znak, pouze 1 znak, jako prefix, proc radeji 2x 2 podtrzitka?
Reflexe je i v jinych jazycich (jestli to chapu dobre) a vetsinou je povazovana za zverstvo, ktere se smi pouzivat pouze ve velmi specifickych pripadech typu knihovny kvuli hezci syntaxi. Podobne jako eval v JavaScriptu. Ma sice sve misto, ale v normalnim projektu typu web to misto rozhodne neni.
Nechápete to dobre. Já bych magické metody popsal jako rozhraní, které je společné všem objektům. S reflexí to nemá mnoho společného.
Jsem vychazel z wiki:
Metaobjects are examples of the computer science concept of reflection, where a system has access (usually at run time) to its internal structure.
...
A metaobject protocol (MOP) provides the vocabulary to access and manipulate the structure and behavior of objects.
To tedy dost pusobi jako reflexe ci prace s bytekodem, pokud to mam vztahnout k Java svetu. Ale je to asi jedno, me neslo o ty metaobjekty ani metaobjektovy protokol, ale o to inovativni jmeno: __*__, ktere bych nikdy neoznacil za hezke - coz uznavam je asi subjektivni a pravdepodobne o zvyku.
nutnost predavat metodam self a uvadet self pro pristup k poli objektu
Jo, to se může jevit jako opruz. Na druhou stranu to umožňuje dekorátorům pracovat s instancemi objektu za běhu, což se používá v pokročilém metaprogramování. Má to i pár dalších výhod a dává to konzistentní smysl, ale to člověk nevidí, dokud nepřekročí základy.
Troufam si rict, ze v JavaScriptu jsem davno prekrocil zaklady, a rozhodne nemam v lasce nutnost vsude ve tride uvadet "this". CoffeeScript to vyresil celkem elegantne, misto "this" prisel s jednim znakem - @. Po pravde az v Pythonu vidim, ze se musi pouzivat this/self i jako parametr metody. Nevim, ja to vse vnimam tak, ze je to do Pythonu dolepene.
Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.
A opravdu tuto "vyhodu" vyuzivate tak casto, ze si to ospravedlnuje pridani jednoho parametru do kazde metody instance? To uz me prijde lepsi zpusob jak to ma Java nebo JavaScript - this je implicitni a pouze pokud opravdu chceme, tak muzeme podstrcit jine (v JS Function.apply/call, v Jave tusim reflexe), ale nemusime ho vsude uvadet.
PS: Jsem moc pomalej, javaman me predbeh :-\.
-
Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.
Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat! :D
Jak píše Kit výše. Psaní self zlepšuje čitelnost. Oproti Javě toho pořád dokola jako retard moc nepíšu. Dekorátory v Javě opravdu nefungují. Dekorátor v pythonu je něco jiného než návrhový vzor dekorátor.
Jak to může zvyšovat čitelnost? Oproti Javě tam pořád píšeš self jak retard. Anotace v Javě nejsou?
-
Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.
No a nekdy to tak není a přístup k atributu přes getter či setter dává perfektní smysl. Co je na tom tak těžkého k pochopení? Navíc to perfektní zapouzdření je blbost, kdyby se vnitřní stav nějak neprojevil na chování objektu, nemusí tam ty atributy být vůbec že :-) Takže zapouzdření samozřejmě ano, ale pokud někdo cítí potřebu získat přístup například ke klasickému hodnotovému objektu a jeho atributům, nevidím v tom problém, i když třeba FP přístup má jiné prostředky (imho lepší, ale to je spíše na jinou debatu)
Úkolem objektu není prezentace atributů, ale sebe sama. Je tedy v pořádku metoda toString(), která ten objekt prezentuje jako celek. Podobně by mohla fungovat i metoda toJson() nebo toMap(), které by prezentovaly stav objektu v jiných formátech. Dělat to posloupností volání getterů a teprve venku z toho slepovat nějakou datovou strukturu je blbost. To se dá pohodlně udělat uvnitř.
Podobně je tomu i s modifikací. Základem je kvalitní konstruktor, který vyrobí validní objekt se všemi nadefinovanými atributy. Modifikace se pak děje prostřednictvím zpráv, které obsahují informace vhodné k uložení - nebo také k ignorování. Modifikační metoda by neměla být pouhým setterem, protože ten obvykle mění jen jeden atribut. Je to způsob předání zprávy. Objekt si sám určí, jak s touto zprávou naloží a které atributy bude modifikovat. Opět je zcela zbytečné, aby vně objektu byla data parsována, validována a předávána objektu po jednom atributu. Prostě se data pošlou objektu jako celek a příslušná metoda uvnitř si je zpracuje. Ve své podstatě je to také setter, ale nenastavuje jen jeden atribut, jako je tomu zvykem u běžných setterů. Proto by ani nebylo příliš vhodné ho jako setter nazývat.
-
Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.
Tak to určitě...
-
Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.
Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat! :D
Jak píše Kit výše. Psaní self zlepšuje čitelnost. Oproti Javě toho pořád dokola jako retard moc nepíšu. Dekorátory v Javě opravdu nefungují. Dekorátor v pythonu je něco jiného než návrhový vzor dekorátor.
Jak to může zvyšovat čitelnost? Oproti Javě tam pořád píšeš self jak retard. Anotace v Javě nejsou?
Anotace dělají něco jiného.
-
Jestli to nebude tím, že jsou daleko schopnější než ty v Pythonu. Takže mi chceš říct, že jednoduché věci jako dekorátor v Pythonu neumí?
-
Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.
Dik za vysvetleni.
Tak ale v tom pripade je Python jeste mene "OOP" nez Java, pokud v podstate nema zapouzdreni, nebo ne?
Jinak to oddeleni dat od funkci zni jako FP, uz jen chybi se zbavit tech setteru :).
Je to zapouzřeno. Data i metody pro práci s nimi jsou uvnitř jednoho objektu. Každý aplikovaný přístup zvenčí do atributu, ať již přímo či nepřímo prostřednictvím getteru/setteru je porušením tohoto zapouzdření. Java se proti tomuto porušení zapoudření umí bránit, Python ne. Je to součást jejich designu. Zapouzřeno však je obojí. Tedy za předpokladu, že to programátor zapouzdřit chce a umí.
V Javě ani Pythonu by se k atributům objektu z vnějšku přistupovat nemělo. A to ani prostřednictvím getterů/setterů. Mělo by se pracovat přímo s objektem, tedy volat jeho metody, které data uvnitř objektu zpracovávají jak pro vstup, tak i pro výstup.
-
Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.
Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat! :D
V Javě se zase "this" schizofrenně někdy píše a někdy ne. Přitom se to chová stejně. To ti přijde normální?
-
Ano, priznavam, ze puvodni OOP neznam (aktualni prakticky pouzivane OOP ano). Ale nejak se mi nepozdava, ze treba zapouzdreni by tam chybelo, coz snad ty modifikatory pristupu zajistuji.
Původní OOP spočívalo v tom, že data i algoritmy jsou zapouzdřeny v objektu. Metody měly bezproblémový přístup k instančním proměnným, které zvenku přístupné nebyly. Perfektně zapouzdřeno. Postupně se to však zdeformovalo do podoby, kdy data jsou zvlášť a servisní služby také zvlášť v samostatných třídách. Často statických. Aby bylo možné se k těm datům dostat zvenčí, tak se na to naroubovaly gettery a settery. Prostě z toho vznikl paskvil.
Je pekne, ze sis vsiml existence design patternu ModelViewController (opet Gang of Four), lec tento OOP pattern opravdu na OOP pranic neboura ani nedeformuje.
MVC je uroven abstrakce nad OOP.
Pokud servisni class primo potrebuje nejake svoje atributy, napr URL na WebService nebo JDBC konexi, no tak je ma hezky u sebe.
Data modelu jsou v jinych objektech, obvykle nejaka collection/shluk Beanu. Beany uz ze sve definice nejsou nic jineho nez datova stuktura, tam opravdu jine metody nez gettery a settery nenajdes.
MVC design pattern oddeluje business logiku aplikace (controller) od statove/datove prezentace (model) a prezentace uzivateli (view)
Zkracene view zobrazuje userovi aktualni stav modelu, user klepe na buttonky, cimz controller meni model a ten se zase zobrazuje uzivateli.
Na MVC patternu ostatne funguje Django.
-
Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.
Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat! :D
V Javě se zase "this" schizofrenně někdy píše a někdy ne. Přitom se to chová stejně. To ti přijde normální?
Jak někdy? Jakože máš metody, kde je parametr občas this? :D To jsem fakt neviděl. A nevím, co to má společného s bludy. Kite, vem si léky!
-
Jestli to nebude tím, že jsou daleko schopnější než ty v Pythonu. Takže mi chceš říct, že jednoduché věci jako dekorátor v Pythonu neumí?
Možná že to jde pomocí nějakého aop frameworku, ale určitě je to tak komplikované, že se to běžně nepoužívá. Javu moc dobře neznám. Možná se mýlím.
-
Já jen - všímáte si, že diskuze jde přesně tím směrem, co jsem popsal? Dokonce už je tu i javaman, který nám udělal kázání o lopatách co pracují za polovinu.
Už si skoro říkám, jestli by to nestálo za napsání článku, který by se pak vždycky jen odkazoval, protože teď se to bude vše znova opakovat. Pokolikáté už za poslední půlrok? Potřetí?
http://forum.root.cz/index.php?topic=12988.0
Jsem vychazel z wiki:
Metaobjects are examples of the computer science concept of reflection, where a system has access (usually at run time) to its internal structure.
...
A metaobject protocol (MOP) provides the vocabulary to access and manipulate the structure and behavior of objects.
To tedy dost pusobi jako reflexe ci prace s bytekodem, pokud to mam vztahnout k Java svetu. Ale je to asi jedno, me neslo o ty metaobjekty ani metaobjektovy protokol, ale o to inovativni jmeno: __*__, ktere bych nikdy neoznacil za hezke - coz uznavam je asi subjektivni a pravdepodobne o zvyku.
Reflexe nepracuje s bytekódem, ale přímo s objekty, které můžou zkoumat svojí vlastní strukturu, třídy, chain dědičnosti a různě jí upravovat. Někdy to může ušetřit kód pomocí pokročilé magie, jindy tě to může střelit do nohy.
Sice jsem odkazoval jen slovo „metaobjektového“ (protože to spousta lidí nezná), ale důležitý je celý zbytek té věty, hlavně to „protokolu“. V pythonu magické metody vytvářejí standardizovaný protokol pro komunikaci s objekty definující často používané akce. Dalo by se říct, že je to takové rozhraní pro standardní funkcionalitu, které podporuje sám jazyk. Třeba __str__() se zavolá při konverzi na string a __repr__() při „zobrazení“ objektu v konzoli atd..
Jestli to nebude tím, že jsou daleko schopnější než ty v Pythonu. Takže mi chceš říct, že jednoduché věci jako dekorátor v Pythonu neumí?
Proč vůbec diskutuješ o věcech, kterým od pohledu nechápeš?
V Javě ani Pythonu by se k atributům objektu z vnějšku přistupovat nemělo. A to ani prostřednictvím getterů/setterů. Mělo by se pracovat přímo s objektem, tedy volat jeho metody, které data uvnitř objektu zpracovávají jak pro vstup, tak i pro výstup.
V pythonu je to imho jedno, protože podporuje properties. Ve chvíli, kdy potřebuješ přístup omezit či nějak transformovat, můžeš tak učinit přes property, či přes deskriptory.
Osobně mi snaha omezovat přístup a myslet si, že tím zlepšuji bezpečnost (nebo co vlastně?) jako nesmysl. Je stejně absurdní, jako snaha některých výrobců omezovat co můžu dělat s mobilem který si koupím a co už ne. Když prostě budu chtít znásilnit nějaký objekt a vlézt si do něj, tak to udělám ať už v javě, nebo kdekoliv jinde, i kdybych to měl dělat scannováním a živou úpravou /dev/mem.
V Javě se zase "this" schizofrenně někdy píše a někdy ne. Přitom se to chová stejně. To ti přijde normální?
To proto, že java nemá žádnou vnitřní logiku, ani krásu. Celé to tak je, prostě proto že to tak někdo chtěl (navíc někde v C++, nebo ještě hlouběji v historii), nikoliv proto, že by to dávalo vnitřní smysl. Neroste to z žádného silnějšího vnitřního konceptu, jako některé jiné jazyky (smalltalk, lisp, do jisté míry i python, který vše staví na dictech).
-
Jestli to nebude tím, že jsou daleko schopnější než ty v Pythonu. Takže mi chceš říct, že jednoduché věci jako dekorátor v Pythonu neumí?
Možná že to jde pomocí nějakého aop frameworku, ale určitě je to tak komplikované, že se to běžně nepoužívá. Javu moc dobře neznám. Možná se mýlím.
Tak záleží na tom, co chceš. Normálně dekorátor není moc potřeba. Ale když bys ho chtěl se stejnou prací jako v Pythonu, tak samozřejmě uděláš anotace a normální aspekt. Nic jednoduššího nevymyslíš. Když chceš ale něco složitějšího, tak ti Java nabízí další možnosti.
Já jen - všímáte si, že diskuze jde přesně tím směrem, co jsem popsal? Dokonce už je tu i javaman, který nám udělal kázání o lopatách co pracují za polovinu.
Jestli to nebude tím, že jsou daleko schopnější než ty v Pythonu. Takže mi chceš říct, že jednoduché věci jako dekorátor v Pythonu neumí?
Proč vůbec diskutuješ o věcech, kterým od pohledu nechápeš?
Tak když se tu pokaždé vyrojí pár matláků, kteří neumí ani Python a začnou se navážet do Javy, která je úrovní úplně jinde. Co mám dělat? Právě jedině to, že berete tak půlku, je reálný fakt, který mě hřeje!
Asi máš špatný pohled.
-
Obdivuju vaše zapálení do takovýhle diskuze :D Zkuste nějak zobecnit Python×ostatní programovací jazyky, zajímalo by mě to.
-
Já jen - všímáte si, že diskuze jde přesně tím směrem, co jsem popsal?
No, bacha na to. Jednou jsem se také pokoušel zeptat, proč duck-typing, a k čemu má Python typy. Ve výsledku jsem se jen dozvěděl, že jsem blbec a trollím. Tak si nestěžuj.
-
MVC design pattern oddeluje business logiku aplikace (controller) od statove/datove prezentace (model) a prezentace uzivateli (view)
Zkracene view zobrazuje userovi aktualni stav modelu, user klepe na buttonky, cimz controller meni model a ten se zase zobrazuje uzivateli.
Nepleteš si to náhodou s MVP? Jsou to přece jen trochu odlišné architektury.
MVC není design patternem, ale architekturou, která se v OOP používá na mnoha úrovních. A to jak na úrovni namespaces, tak i na úrovni každého jednotlivého objektu, kde modelem jsou datové struktury, controllerem metody modifikující stav (včetně setterů) a viewem metody prezentující stav (včetně getterů).
-
Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.
Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat! :D
V Javě se zase "this" schizofrenně někdy píše a někdy ne. Přitom se to chová stejně. To ti přijde normální?
Jak někdy? Jakože máš metody, kde je parametr občas this? :D To jsem fakt neviděl. A nevím, co to má společného s bludy. Kite, vem si léky!
Jo tak tobě vadí self jako formální parametr metody? Vždyť je to jen jedno slovo, které ti tam lepší editor automaticky sám napíše. Aspoň je explicitně vidět, s jakými daty ta metoda pracuje.
"this." se v Javě píše jako prefix názvu atributu objektu. Tedy někdy se píše, jindy ne. "self." je v Pythonu povinné.
-
Obdivuju vaše zapálení do takovýhle diskuze :D Zkuste nějak zobecnit Python×ostatní programovací jazyky, zajímalo by mě to.
Na malý skriptíky je Python fajn. Ale jak to naroste, je to na vyhození.
Používání self jako prvního parametru má mnoho výhod. Metody se díky tomu neliší od jiných funkcí. Jak píše Bystroushaak, umožňuje to například dekorátorům přistupovat k předávané instanci. Další výhoda je, že mohu metodu volat způsobem Trida.metoda(instance_jine_tridy, dalsi parametry). V jiných jazycích to jde také, ale ne tak přímočaře.
Takže psaní self jako retard pořád dokola ti přijde normální? Dekorátory v Javě teda vlastně nefungují, ne? A ta poslední konstrukce je luxusní, tu chci používat! :D
V Javě se zase "this" schizofrenně někdy píše a někdy ne. Přitom se to chová stejně. To ti přijde normální?
Jak někdy? Jakože máš metody, kde je parametr občas this? :D To jsem fakt neviděl. A nevím, co to má společného s bludy. Kite, vem si léky!
Jo tak tobě vadí self jako formální parametr metody? Vždyť je to jen jedno slovo, které ti tam lepší editor automaticky sám napíše. Aspoň je explicitně vidět, s jakými daty ta metoda pracuje.
"this." se v Javě píše jako prefix názvu atributu objektu. Tedy někdy se píše, jindy ne. "self." je v Pythonu povinné.
Samozřejmě :D Je to hnus. Proč bych ho tam dával, když je to jasné?
Když ho potřebuješ, tak ho napíšeš, ale nikdo tě nenutí.
-
Reflexe nepracuje s bytekódem, ale přímo s objekty, které můžou zkoumat svojí vlastní strukturu, třídy, chain dědičnosti a různě jí upravovat. Někdy to může ušetřit kód pomocí pokročilé magie, jindy tě to může střelit do nohy.
"Pokrocila magie" na usetreni kodu je synonymum pro termin "Neskutecna prasecina, ktere nerozumi ani autor pul roku po napsani".
Kdyz uz je potreba "pokrocile carovat", tak jedine a pouze ve forme standardizovane a dokumentovenho frameworku. Napr. Spring IoC je presne tento pripad, Spring pres reflection API sestavuje aplikaci ze Spring Beanu behem inicializace kontejneru.
Pokusy vyrabet si vlastni IoC primym matlanim na reflection API je na ranu bejkovcem.
Sice jsem odkazoval jen slovo „metaobjektového“ (protože to spousta lidí nezná), ale důležitý je celý zbytek té věty, hlavně to „protokolu“. V pythonu magické metody vytvářejí standardizovaný protokol pro komunikaci s objekty definující často používané akce. Dalo by se říct, že je to takové rozhraní pro standardní funkcionalitu, které podporuje sám jazyk. Třeba __str__() se zavolá při konverzi na string a __repr__() při „zobrazení“ objektu v konzoli atd..
Takove "rozhrani pro standardni funkcionalitu" pristupne jsou prosim V Jave metody poskytovane toplevel tridou Object, napr toString(). A neni potreba vytvaret ohavnosti typu __str__().
Kdykoliv jsem nekdy nekde v nejakem jazyce videl prefix "_", vzdycky to bylo zoufale reseni jak nekam strcit magicky keyword tak, aby nekolidoval s normalnimi nazvy promennych a funkci.
Osobně mi snaha omezovat přístup a myslet si, že tím zlepšuji bezpečnost (nebo co vlastně?) jako nesmysl. Je stejně absurdní, jako snaha některých výrobců omezovat co můžu dělat s mobilem který si koupím a co už ne. Když prostě budu chtít znásilnit nějaký objekt a vlézt si do něj, tak to udělám ať už v javě, nebo kdekoliv jinde, i kdybych to měl dělat scannováním a živou úpravou /dev/mem.
Samozrejme, zvysuje to bezpecnost proti nechtene zmene neceho, co z vnejsku meneno byt nema. Kdyz mam v objektu atribut drzici hash seed, no tak bych byl velice nerad, at to nekdo, trebas omylem zmeni. Privatni metody dtto, kdyz potrebuju aby interface metoda drzela sekvenci prikazu, jinak vybuchnou Dukovany, tak muzu bud:
- udelat interface metodu jako clovek, ktera bude obsahovat hromadu malych snadno udrzovatelnych privatnich metod
- nebo napsat spagetovou hruzu
To proto, že java nemá žádnou vnitřní logiku, ani krásu. Celé to tak je, prostě proto že to tak někdo chtěl (navíc někde v C++, nebo ještě hlouběji v historii), nikoliv proto, že by to dávalo vnitřní smysl. Neroste to z žádného silnějšího vnitřního konceptu, jako některé jiné jazyky (smalltalk, lisp, do jisté míry i python, který vše staví na dictech).
Java ma vnitrni logiku velice jednoduchou a velice elegantni. Dokonce az moc jednoduchou, slozitejsi veci se resi na na urovni design patternu, JSR, Frameworku typu Spring a kontejneru typu OSGi.
Ohavnosti jako __str__() nebo ducktyping tam opravdu nenajdes.
Je velice malo vyjimek z objektoveho paradigmatu, (napr. primitivni typy) zapricinene technologickymi omezenimi (int[] je zkratka rychlejsi nez LinkedList<Integer>). Nebo napriklad problemy s finally bloky, nebo s resources typu otevreny file descriptor, o ktery se garbage collector nepostara.
-
Tak záleží na tom, co chceš. Normálně dekorátor není moc potřeba. Ale když bys ho chtěl se stejnou prací jako v Pythonu, tak samozřejmě uděláš anotace a normální aspekt. Nic jednoduššího nevymyslíš. Když chceš ale něco složitějšího, tak ti Java nabízí další možnosti.
Mluvíš o tomhle? http://www.learnpython.org/en/Decorators (http://www.learnpython.org/en/Decorators)
-
MVC design pattern oddeluje business logiku aplikace (controller) od statove/datove prezentace (model) a prezentace uzivateli (view)
Zkracene view zobrazuje userovi aktualni stav modelu, user klepe na buttonky, cimz controller meni model a ten se zase zobrazuje uzivateli.
Nepleteš si to náhodou s MVP? Jsou to přece jen trochu odlišné architektury.
MVC není design patternem, ale architekturou, která se v OOP používá na mnoha úrovních. A to jak na úrovni namespaces, tak i na úrovni každého jednotlivého objektu, kde modelem jsou datové struktury, controllerem metody modifikující stav (včetně setterů) a viewem metody prezentující stav (včetně getterů).
https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Cituji: Model–view–controller (MVC) is a software architectural pattern for implementing user interfaces on computers.
https://en.wikipedia.org/wiki/Architectural_pattern
Cituji: Architectural patterns are similar to software design pattern but have a broader scope. The architectural patterns address various issues in software engineering, such as computer hardware performance limitations, high availability and minimization of a business risk. Some architectural patterns have been implemented within software frameworks.
Tedy MVC je obecne architecture pattern (protze se muze tykat treba i hardwaru). Design pattern je podmnozinou Architecture patternu.
K puvodnimu tematu. Ze nekto udela SW architekturu podle MVC, tak to neznamena, ze je to z pohledu OOP spatne. MVC je u jednu uroven abstrakce vyse.
-
Ohavnosti jako __str__() nebo ducktyping tam opravdu nenajdes.
Docela mě dráždí, jak slučuješ estetickou záležitost (__str__()) a technologickou záležitost (ducktyping versus nominální typování).
-
Tak záleží na tom, co chceš. Normálně dekorátor není moc potřeba. Ale když bys ho chtěl se stejnou prací jako v Pythonu, tak samozřejmě uděláš anotace a normální aspekt. Nic jednoduššího nevymyslíš. Když chceš ale něco složitějšího, tak ti Java nabízí další možnosti.
Mluvíš o tomhle? http://www.learnpython.org/en/Decorators (http://www.learnpython.org/en/Decorators)
Jistě, normální Python dekorátor.
-
Ohavnosti jako __str__() nebo ducktyping tam opravdu nenajdes.
Docela mě dráždí, jak slučuješ estetickou záležitost (__str__()) a technologickou záležitost (ducktyping versus nominální typování).
Oba pripady spadaji do souhrnne mnoziny "znouzectnost".
__str__() protoze python nema toplevel class
ducktyping() - protoze typovani neni, tak budeme typ hadat a doufat, ze nekoho jineho nenapadlo napsat podobnou tridu.
-
https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Cituji: Model–view–controller (MVC) is a software architectural pattern for implementing user interfaces on computers.
Však to souhlasí. Controllerem je klávesnice, jako View obrazovka a jako Model je ten počítač, ke kterému jsou tyto komponenty připojeny.
Tlačítka zobrazovaná na monitoru už do tohoto schématu nepasují, proto byl navržen alternativní systém MVP, který už řeší interaktivitu těchto tlačítek. Do aplikace se pak předávají až jejich události.
-
Ohavnosti jako __str__() nebo ducktyping tam opravdu nenajdes.
Docela mě dráždí, jak slučuješ estetickou záležitost (__str__()) a technologickou záležitost (ducktyping versus nominální typování).
Oba pripady spadaji do souhrnne mnoziny "znouzectnost".
__str__() protoze python nema toplevel class
ducktyping() - protoze typovani neni, tak budeme typ hadat a doufat, ze nekoho jineho nenapadlo napsat podobnou tridu.
Blbost.
__str__() je metoda z (jakéhosi) rozhraní Stringable. Není to žádná hrůza, a to, že se tam dávají podtržítka je prostě konvence a estetická záležitost. To je všechno.
Volbu duck-typingu považuji za faktický problém (i když připouštím, že v praxi se nemusí projevovat).
-
Je hezke, ze Python nabizi take metaprogramovani. Osobne jsem si nad JVM pri modovani Mincraftu hral s reflexi a i upravou bytekodu za behu (bohuzel to ani jinak neslo, rozhodne neslo o mou prvni volbu ;D). Ale jak jsem psal vyse, pri vyvoji normalnich aplikaci to clovek nepouzije (nebo mozna spise bych mel napsat "by nemel pouzivat"). Je to velmi podobne jako makra pro prekladac ve Scale - velice pokrocile, velmi efektni, ale casto tak komplexni, ze to akorat bude delat problemy pri udrzbe. "Pokrocila magie" je vystizne, jak psal nekdo prede mnou, tak i podle me, by ji mely pouzivat pouze knihovny, ktere maji vse velmi detailne zdokumentovane.
-
"this." se v Javě píše jako prefix názvu atributu objektu. Tedy někdy se píše, jindy ne. "self." je v Pythonu povinné.
Tak to není úplně přesné, může se psát i u metody s naprosto stejným významem. Ale nikdy se nepíše v seznamu parametrů metody, tam je to totiž zřejmé z její hlavičky, kdy se self použije a kdy ne (statické metody).
-
Oba pripady spadaji do souhrnne mnoziny "znouzectnost".
__str__() protoze python nema toplevel class
ducktyping() - protoze typovani neni, tak budeme typ hadat a doufat, ze nekoho jineho nenapadlo napsat podobnou tridu.
C# také nemá toplevel class. Řekl bych, že to nikomu nevadí. Jinak je úplně jedno, zda se ta metoda jmenuje __str__() nebo toString(). Píši to pokaždé stejně a nechávám na korektuře pravopisu, aby mi napsala správné záhlaví metody.
Nějaká podobná třída by vadila? Běžně ve třídách používám stále stejné názvy metod a dokonce i třídy mají (i v rámci jednoho projektu) často stejná jména. Ničemu to nevadí a nemusím si pamatovat tolik názvů.
-
"this." se v Javě píše jako prefix názvu atributu objektu. Tedy někdy se píše, jindy ne. "self." je v Pythonu povinné.
Tak to není úplně přesné, může se psát i u metody s naprosto stejným významem. Ale nikdy se nepíše v seznamu parametrů metody, tam je to totiž zřejmé z její hlavičky, kdy se self použije a kdy ne (statické metody).
Statickým metodám se úmyslně vyhýbám, proto mi tento detail unikl.
-
"this." se v Javě píše jako prefix názvu atributu objektu. Tedy někdy se píše, jindy ne. "self." je v Pythonu povinné.
Tak to není úplně přesné, může se psát i u metody s naprosto stejným významem. Ale nikdy se nepíše v seznamu parametrů metody, tam je to totiž zřejmé z její hlavičky, kdy se self použije a kdy ne (statické metody).
Statickým metodám se úmyslně vyhýbám, proto mi tento detail unikl.
To je dobře, ono je to většinou dobře se jim vyhnout, jejich použití mnohdy naznačuje, že v kódu něco smrdí (pokud se člověk nesnaží i FP, ale to by bylo patrné i z dalších technik, většinou to tak není).
-
JavaScript je funkcionalni, od ES6 umi i hezky kondenzovane fat-arrow funkce, ale bez externi knihovny take hodne slaby [co se vyberu funkci tyce]).
*: Nasel jsem jakesi reseni v podobe doimplementovani pipe opratoru a preimplementovani zabudovanych funkci jako map nebo filter na curried variantu. IMO celkem hnusne reseni - narovnavak na ohybak.
Myslis toto?
https://www.npmjs.com/package/babel-plugin-operator-overload
Tiez som na to nedavno pozeral s otvorenymi ustami :D takze JS uz ma aj currying :D ale stale si nemyslim ze je to plnohodnotny funkcionalny jazyk. Je to imperativny jazyk ktory umoznuje pisat aj funkcionalny kod. Ale ta podpora FP je tam zhruba na urovni C#.
-
je tak uspesny a rozsireny
Ono argumentovat popularitou je dost ošemetné. Kdybych to měl přirovnat třeba k hudbě, tak takový Justin Bieber má na YT miliardy shlédnutí a přitom objektivně jeho produkce stojí za hovno. Popularita a kvalita bohužel ne vždy jdou ruku v ruce a často se vyloženě rozcházejí. Někdy se to krásně sejde, ale jedno automaticky nevyplývá z druhého.
A) neustale ta same hloupe nerozlisovani mezi pouzitelnosti, popularitou a kvalitou
B) navic si tu nekdo plete subjektivni s objektivnim. Objektivni je meritelne a objektivne ma produkce Justina vysokou hodnotu, jak ukazuji jeho prijmy, coz je primarnim cilem komercni hudebni produkce. Python je oproti tomu jazyk nekomercni, meritkem jeho uspechu je rozsirenost a nezbyva nez konstatovatk ze je jazykem nadmiru uspesnym a ze nabizi vlastnosti, ktere uspokojuji velkou skupinu uzivatelu. V jeho pripade je jeho rozsirenost ukazatelem jeho pouzitelnosti.
-
objektivne ma produkce Justina vysokou hodnotu, jak ukazuji jeho prijmy
Ty to opravdu nechápeš? Vždyť je to tak jednoduché. Finanční hodnotu to má možná proto, že to dokáže rozvřískat stadion nadržených patnáctek s mickey mousem na triku. O hudební kvalite to ale neříká vůbec nic. Jestli si tady někdo něco plete, pak jsou to slova hodnota a kvalita. Já celou dobu mluvím o tom druhém.
-
Statickým metodám se úmyslně vyhýbám, proto mi tento detail unikl.
Tak to už máme boolean hodnoty, gettery/settery a statické metody v jediném vlákně. Které všechny konstrukce ještě považujete za naprosto zbytečné? Upřímně mě to zajímá.
Mně to teda připadá, jako když se někdo rozhodne, že bude psát bez interpunkce, diakritiky, nebude text dělit do odstavců a nebude ani rozlišovat velká a malá písmena. Jsou to jednak úplné zbytečnosti a hlavně v tom pak neudělá chybu. Sice potom působí jako negramot a ostatním se to po něm špatně čte, ale ke sdělení informace opravdu žádnou z těch zbytečností nepotřeboval.
Ono stačí si někdy poslechnout běžný rozhovor na ulici, s jak omezeným slovníkem si někteří vystačí. To ale přece neznamená, že je to vole takhle upa v cajku vole a vůbec kdo má vole na tydlencty panský vymyšlenosti náladu vole, nasrat.
-
objektivne ma produkce Justina vysokou hodnotu, jak ukazuji jeho prijmy
Ty to opravdu nechápeš? Vždyť je to tak jednoduché. Finanční hodnotu to má možná proto, že to dokáže rozvřískat stadion nadržených patnáctek s mickey mousem na triku. O hudební kvalite to ale neříká vůbec nic. Jestli si tady někdo něco plete, pak jsou to slova hodnota a kvalita. Já celou dobu mluvím o tom druhém.
Ty seš úplně mimo člověče, vždyť ty vůbec netušíš o čem je řeč :-). Prečti si počátek debaty, ať alespoň tušíš, že spor je o použitelnosti, nikoliv kvalitě.
Justinovo vystoupení má vysokou hodnotu, protože vydělává a protože je to vystoupení komerční a jeho cílem je vydělávat, je úspěšné. Kvalita s tím nemá vůbec co do činění a je to fail argument, na to poukazují akorát závistivci.
Stejně tak to platí o pythonu, kde jakýsi závistivec tvrdil, že python je nepoužitelný a já jsem argumentoval tím, že je to zjevný nesmysl, když je to jeden z nejpoužívanějších jazyků a etabloval se v řadě oblastí. Kvalita s tím nemá nic do činění.
Navíc opírat se o kvalitu je čistě subjektivní záležitost, byť se tu někdo snaží tvrdit přesný opak. Objektivní měřítko kvality jazyka neexistuje, protože hodnotící měřítka jsou čistě subjektivní. Platí to i o hudbě. Pokud jsem hudebním producentem, který chce vydělat, tak si jako základní měřítkem kvality pro výběr hudebníka vezmu jeho potenciál vydělat a přinést mi zisk. Nikoliv nějaké pochybné hudební kvality, které nikdo nedovede objektivně definovat a měřit. Justin mi vyjde jako kvalitní zpěvák a dám mu přednost před jiným, který tu schopnost a potenciál nemá, byť mi ho budeš podsouvat, jako údajně kvalitnějšího. A to samé platí o programování a programovacích jazycích. Kvalita je odpověď na otázku jaký a tato otázka může být libovolná. Hodnocení kvality je subjektivní záležitost, je to věc úhlu pohledu daná např. vkusem, osobními preferencemi nebo účelem využití.
Jestliže je pro mě důležitá praktická použitelnost jazyka, mohu si položit otázku, jaký jazyk je nejpoužitelnější, např. na vývoj středně velkého webu běžícím na webhostingu. A vyjde mi zatracované PHP a nikoliv nepraktický haskell, který tu furt někdo nesmyslně prosazuje. A s tímto měřítkem kvality mohu dokonce tvrdit, že PHP je kvalitnější jazyk než haskell, protože hodnocení kvality je subjektivní.
Dovolím si tvrdit, že měřítko použitelnosti je pro programátory v praxi daleko důležitější, než jakési akademické tajemně nedefinované měřítko, podle kterého tu někdo subjektivně lépe hodnotí haskell. Měřítko použitelnosti rozhoduje o úspěchu a rozšíření jazyka. Takže konec konců i tu popularitu mohu oprávněně brát za kvalitativní parametr a ne že ne.
-
Řetězení transformací je chytlavý nešvar FP, nedá se to dobře testovat. A v konečném důsledku je to podobné, jako když funkce má 12 parametrů.
Python je navržen schválně tak, aby nic nešlo lehce řetězit.
To je samozřejmě opět nesmysl. Řetězení není nic jiného než nepojmenovávání proměnných, které pojmenovávat nepotřebuju.
d = a |> f |> g |> h
je úplně to samé jako
b = f(a)
c = g(b)
d = h(c)
a je to úplně stejně testovatelné. Funkce s 12 parametry to fakt není.
-
Neumim si predstavit, ze bych neco jako scala pouzival prakticky, tj. ze bych mel odvahu to nasadit u zakaznika v rozsahu desitek tisic radkukodu a udrzoval/rozvijel to 15+ let. Pro me je to neduveryhodny a proto _prakticky_ nepouzitelny jazyk.
A přesně proto je ve Scale napsaný Spark, pomocí kterého se v produkci zpracovávají největší množství dat a postupně válcuje Hadoop :)
-
Spousta funkcí v haskellu má nic neříkající typovou signaturu jako a -> a. Například většina matematických funkcí má signaturu Floating a => a -> a. Docstring v pythonu často obsahuje příklad použití, který mohu spustit jako test.
To je naopak signatura, která říká naprosto všechno - že jde o fci, která může pracovat s libovolným typem ze třídy Floating a vrací stejný typ, jaký mu dám. Co víc bys mohl chtít vědět?
-
onCreate :: JNIEnv -> JObject -> JObject -> IO ()
onCreate env activity _bundle = runJNISafe () env $ do
msg <- liftIO $ do
getNumProcessors >>= setNumCapabilities
caps <- getNumCapabilities
return $ "Hello World!\nRunning on " `append` pack (show caps) `append` " CPUs!"
No jo, jenže ta nečitelnost pro lidi, kteří Haskell neznají, je daná jeho odlišnými vlastnostmi od jazyků, které jsou obecně známé.
Jinak osobně taky moc nemusím třeba používání $, protože mě to nutí skákat očima několikrát zleva do prava. Za čitelnější považuju |> kde můžu číst zleva doprava (nebo shora dolů) a nemusím se vracet. Ale haskelleři to prostě mají ve zvyku a pro nás ostatní je to jenom nezvyk.
-
Haskell je prakticky asi jak pro koho - osobne si myslim, ze je to pouze o zpusobu vzdelavani, kde se na zacatek silne preferuji imperativni jazyky (Java, Python, Pascal). Napr. na FITu jsme si funkcionalni pristup osahali az v magisterskem, ktere bylo povazovano nekterymi prednasejicimi za nadstandard a do praxe muze student v pohode i jen s bakalarem.
Osobne si nemyslim, ze kvalita jakkoliv souvisi s popularitou. Kvalitni jazyk se totiz podle me nesnazi pretrhnout kvuli zacatecnikum a znehodnotit tak sve dalsi casti nebo cely svuj pristup. A kdyz jsme u toho, tak pokud chcete objektivne merit kvalitu/pouzitelnost a vztahnete ji i k popularite, jak presne objektivne merite popularitu? :D Podle radek kodu v produkci? Celkoveho vydelku vyvojaru pouzivaci ten jazyk? Nejake nahodne zvolene kriterium jako pocet commitu GitHubu a pocet dotazu na StackOverflow?
Prakticka pouzitelnost jazyka zase nema s popularitou IMO nic spolecneho. I uplny odpad, jako PHP, ktery je obtizne pouzitelny (poskytl jsem dost prikladu, nekolik jich dodal i Kit a ten v tom dokonce i vyviji trochu vice) a stejne se stal popularnim. Stejne tak to nerika nic o pouzitelnosti a kvalite jeho knihoven a celkove ekosystemu. (Ktery ho v pripade PHP drzi nad vodou.) To stejne mohu vztahnout na NodeJS - to ze je JavaScript nejpopularnejsi jazyk na planete (http://redmonk.com/sogrady/2016/02/19/language-rankings-1-16/) z neho nedela nejlepsi jazyk a ani nejpouzitelnejsi, rozhodne ne nejak univerzalne. S chladnou jistotou bych vzdy doporucil Javu, Scalu nebo klidne i ten Haskell na back-end pro jakykoliv projekt, ktery neni "fire-and-forget" - tj. ze se ocekava dlouha doba udrzby. Proste dynamicke jazyky, stejne jako treba ty "pokrocile magie", tam podle me nepatri. Dynamicke jazyky typu Ruby se skvele hodi pro stratup, to nepopiram, projektiky jsou obecne mensi, potrebuji to mit rychle udelane a pokud to uspejeje a budou problemy (u tech uspesnych casto ctu, ze jsou), tak to proste prepisou do neceho vice se hodiciho na dany ukol (vetsinou ta Java ci C#, videl jsem uz ale i treba NodeJS, k cemuz jsem byl trosku skepticky).
S tou pajpou jsem myslel Python. V JavaScriptu je vyhoda, ze je prave ten kratky zapis closure, takze staci pribrat treba ten Lodash a muzete vesele retezit. Bohuzel v Pythonu je lambda silene dlouha na zapis, jako kdyby autor nechtel, aby se to moc pouzivalo. Coz ostatne sedi k jeho postoji o FP. To jsme ale trochu odbocili, protoze ani o JS jsem nepsal, ze je nejake skvele na FP, rozhodne ne out-of-the-box (chybi mi spousta funkci pro manipulaci s poli). Puvodne jsem to srovnaval se Scalou a tam jsou i veci, ktere umoznuji opravdu jednoduchy kod (ktery me prijde hezky, ale to je opravdu silne subjektivni), treba placeholder _.
(1 to 10).filter(_ % 2 == 0).map(_ * 10)
-
Bohuzel v Pythonu je lambda silene dlouha na zapis, jako kdyby autor nechtel, aby se to moc pouzivalo.
Co, dlouhá na zápis, to by se ještě dalo přežít. Ona ale hlavně nedělá to, co má dělat (anonymní fce). V Pythonu je to speciální konstrukce se speciálními omezeními. Čili stejná hloupost jako print. Jak mám Python docela rád, tak tyhle spešl konstrukce jsou velká vada na kráse. Aspoň ten print v 3ce už umravnili. Jak je to s lambdou nevím.
-
onCreate :: JNIEnv -> JObject -> JObject -> IO ()
onCreate env activity _bundle = runJNISafe () env $ do
msg <- liftIO $ do
getNumProcessors >>= setNumCapabilities
caps <- getNumCapabilities
return $ "Hello World!\nRunning on " `append` pack (show caps) `append` " CPUs!"
No jo, jenže ta nečitelnost pro lidi, kteří Haskell neznají, je daná jeho odlišnými vlastnostmi od jazyků, které jsou obecně známé.
Jinak osobně taky moc nemusím třeba používání $, protože mě to nutí skákat očima několikrát zleva do prava. Za čitelnější považuju |> kde můžu číst zleva doprava (nebo shora dolů) a nemusím se vracet. Ale haskelleři to prostě mají ve zvyku a pro nás ostatní je to jenom nezvyk.
oceňuju pokus o analýzu, ale máte to trochu blbě
($) je víceméně náhrada závorek, takže return $ 1+1 je jako return (1+1), můžete si vytvořit ten váš pipe (|>) = flip ($) a pak psát 1 |> return místo return 1, ale to teda zrovna zvyklé není (snad v žádném jazyce)
-
oceňuju pokus o analýzu, ale máte to trochu blbě
($) je víceméně náhrada závorek, takže return $ 1+1 je jako return (1+1), můžete si vytvořit ten váš pipe (|>) = flip ($) a pak psát 1 |> return místo return 1, ale to teda zrovna zvyklé není (snad v žádném jazyce)
Nevidím, co bych tam měl mít blbě. Místo
return $ "Hello World!\nRunning on " `append` pack (show caps) `append` " CPUs!"
je mi prostě subjektivně příjemnější
"Hello World!\nRunning on "
`append` pack (show caps)
`append` " CPUs!"
|> return
-
a) Osobne si nemyslim, ze kvalita jakkoliv souvisi s popularitou.
b) A kdyz jsme u toho, tak pokud chcete objektivne merit kvalitu/pouzitelnost a vztahnete ji i k popularite, jak presne objektivne merite popularitu? :D
c) Prakticka pouzitelnost jazyka zase nema s popularitou IMO nic spolecneho. I uplny odpad, jako PHP, ktery je obtizne pouzitelny
d) Proste dynamicke jazyky, stejne jako treba ty "pokrocile magie", tam podle me nepatri.
a) Osobně si to myslet můžeš, to je přesně to o čem píšu, je to subjektivní záležitost,kterou nelze vydávat za objektivní, jakse tu někteří snaží.
b) Stále ve stejné vyjeté koleji chybného uvažovaní. Kvalita se objektivně neměří, kvalita se subjektivně posuzuje. Měřené vlastnosti nejsou kvalitativní, ale kvantitativní.
c) Naopak, kvalitní PHP je ve své oblasti velmi dobře použitelné, což jednoznačně dokazuje jeho vysoká míra používání navzdory nedostatkům v jeho návrhu. Z toho je vidět, že ač si z čistoty návrhu někdo dělá modlu, tak v praxi to není důležité. Žádný z úspěšných jazyků nemá čistý a bezchybný návrh. Čím to asi bude?
d) Už jsme opět v oblasti subjektivních dojmů a předsudků. Dynamická povaha jazyka sama o sobě není diskvalifikující, je to vlastnost, nikoliv chyba. A že se pár lidem tato vlastnost nelíbí, co na tom. Jiným zase naopak vyhovuje. Jen mi není jasné, proč v diskusi pod dotazem, zda má Python budoucnost, se někdo snaží propagovat svůj oblíbený jazyk. Je to offtopic.
Python je výborný, kvalitní a široce uplatnitelný jazyk, jeho obliba roste, je velmi zajímavý i komerčně a myslím že neexistuje jediný důvod, proč by se někdo měl domnívat, nebo dokonce s jistotou tvrdit, že nemá budoucnost, byť někdo může mít jiné preference.
-
Nevidím, co bych tam měl mít blbě.
No jo, jenže ta nečitelnost pro lidi, kteří Haskell neznají, je daná jeho odlišnými vlastnostmi od jazyků, které jsou obecně známé.
Jinak osobně taky moc nemusím třeba používání $ ... Ale haskelleři to prostě mají ve zvyku a pro nás ostatní je to jenom nezvyk.
obecně známý python: return 1
obecně známé c a c++: return 1;
-
Žádný z úspěšných jazyků nemá čistý a bezchybný návrh. Čím to asi bude?
Jde taky o to, jak moc dojebaný ten návrh je, jestli je to ještě aspoň "good enough". Třeba v případě toho PHP už je to tak moc za hranou, že nám "fajnovkám" se z toho prostě zvedá kufr a nebudeme v tom ochotní dělat, ani kdyby to mělo dvakrát takovou popularitu jako teď.
-
obecně známý python: return 1
obecně známé c a c++: return 1;
To ale byly dvě různé věci napsané ve dvou různých odstavcích:
1. Ta nečitelnost toho ukázkového kódu je daná tím, že se tam musí operovat s monádami, což je důsledek toho, že je Haskell lazy. Kdyby nebyl (jako třeba Elixir), tak by se prostě psaly příkazy pod sebe jako v céčku a žádné složité šipky jednoduché dvojité doleva doprava by se nekonaly. Takže těžko srovnávat čitelnost zápisu, který dělá daleko víc ("programovatelný středník") s kódem, který dělá míň ("neprogramovatelný středník" v ne-lazy jazycích).
2. Mně osobně navíc není sympatické $
-
důsledek toho, že je Haskell lazy
Teda respektive ne jenom lazy, ale taky referenčně transparentní, když už jsme u toho chytání za slovíčka :)
-
Žádný z úspěšných jazyků nemá čistý a bezchybný návrh. Čím to asi bude?
Jde taky o to, jak moc dojebaný ten návrh je, jestli je to ještě aspoň "good enough". Třeba v případě toho PHP už je to tak moc za hranou, že nám "fajnovkám" se z toho prostě zvedá kufr a nebudeme v tom ochotní dělat, ani kdyby to mělo dvakrát takovou popularitu jako teď.
O tom, jestli je něco dostatečně dobré, efektivně a poměrně objektivně rozhoduje "trh" a ten v případě PHP pravil, že ano. A komu se to nelíbí, ať si ...
-
...
obecně známý python: return 1
obecně známé c a c++: return 1;
To je snad jen o tom, že v (nejen) c je středník (povinný) oddělovač příkazů; nebo ne?
-
O tom, jestli je něco dostatečně dobré, efektivně a poměrně objektivně rozhoduje "trh" a ten v případě PHP pravil, že ano. A komu se to nelíbí, ať si ...
Voliči pravili, že Zeman je vhodným kandidátem na prezidenta. Diváci Šlágr TV rozhodli, že dechovky hrané na synťáky z tržnice jsou ta nejlepší hudba pod sluncem. Diváci pravidelně rozhodují, že Ordinace v růžové ulici je to nejlepší, co můžete vidět na obrazovce. Váš svět je sice strašně jednoduchý, nemusíte se namáhat s přemýšlením, ale zároveň je to svět dost omezený.
-
To je snad jen o tom, že v (nejen) c je středník (povinný) oddělovač příkazů; nebo ne?
Nejen. V Haskellu máš ještě curryfikaci, která to komplikuje. V jiných jazycích musíš explicitně použít lambdu, takže je jasné, že to je jeden parametr a ne dva. V Haskellu to nepoznáš, takže musíš závorkovat. A protože závorkování je opruz, zavedl se $ jako "definitivní závorka" ;)
-
To je snad jen o tom, že v (nejen) c je středník (povinný) oddělovač příkazů; nebo ne?
Nejen. V Haskellu máš ještě curryfikaci, která to komplikuje. V jiných jazycích musíš explicitně použít lambdu, takže je jasné, že to je jeden parametr a ne dva. V Haskellu to nepoznáš, takže musíš závorkovat. A protože závorkování je opruz, zavedl se $ jako "definitivní závorka" ;)
Tebou popisované věci znám jen z rychlíku a o proto o tom ani nepolemizuju, v tom nejsme vepři.
Já jen nějak nepochytil, co tím (těma returnama) chtěl autor říci.
-
To je snad jen o tom, že v (nejen) c je středník (povinný) oddělovač příkazů; nebo ne?
Nejen. V Haskellu máš ještě curryfikaci, která to komplikuje. V jiných jazycích musíš explicitně použít lambdu, takže je jasné, že to je jeden parametr a ne dva. V Haskellu to nepoznáš, takže musíš závorkovat. A protože závorkování je opruz, zavedl se $ jako "definitivní závorka" ;)
Tebou popisované věci znám jen z rychlíku a o proto o tom ani nepolemizuju, v tom nejsme vepři.
Já jen nějak nepochytil, co tím (těma returnama) chtěl autor říci.
autěr chtěl říct, že haskelleři píšou return stejně jako se píše v pythonu nebo cčku
-
O tom, jestli je něco dostatečně dobré, efektivně a poměrně objektivně rozhoduje "trh" a ten v případě PHP pravil, že ano. A komu se to nelíbí, ať si ...
Voliči pravili, že Zeman je vhodným kandidátem na prezidenta. Diváci Šlágr TV rozhodli, že dechovky hrané na synťáky z tržnice jsou ta nejlepší hudba pod sluncem. Diváci pravidelně rozhodují, že Ordinace v růžové ulici je to nejlepší, co můžete vidět na obrazovce. Váš svět je sice strašně jednoduchý, nemusíte se namáhat s přemýšlením, ale zároveň je to svět dost omezený.
Nikoliv, vhodnost kandidáta na prezidenta se neurčuje volbou nýbrž zákonem, který definuje kdo a za jakých okolností může kandidovat. Voliči pravili, že Zeman je z kandidátů ten nejlepší. Přemýšlením se nemusí namáhat nikdo. O mém světě nevíš zhola nic a domnívám se, že svět si zjednodušuje a přemýšlení se vyhýbá spíš ten, kdo nechce brát na vědomí realitu a dává přednost zjednodušeným ideiím, plete si pojmy a nerozlišuje jejich význam.
-
Žádný z úspěšných jazyků nemá čistý a bezchybný návrh. Čím to asi bude?
Jde taky o to, jak moc dojebaný ten návrh je, jestli je to ještě aspoň "good enough". Třeba v případě toho PHP už je to tak moc za hranou, že nám "fajnovkám" se z toho prostě zvedá kufr a nebudeme v tom ochotní dělat, ani kdyby to mělo dvakrát takovou popularitu jako teď.
+1
Jine jazyky chyby napravuji, viz JavaScript nebo Python. PHP si udrzuje svoji "kvalitu", spise nekvalitu, a pridava dalsi ficury, ktere jej nedale "zkvalitnuji".
...
O tom, jestli je něco dostatečně dobré, efektivně a poměrně objektivně rozhoduje "trh" a ten v případě PHP pravil, že ano. A komu se to nelíbí, ať si ...
Ok, at je po vasem (me penize ani popularita jazyka, ve kterem pisi, nejak extra nemotivuje; mysleno obecne), podivejme se na trh. Platy PHP vyvojaru nejsou ve srovnani s ostanimi nejak vysoke: http://www.sitepoint.com/best-programming-language-learn-2015-job-demand-salaries/. Mozna, ze nadanejsi programatori ani nechteji zacinat pracovat v PHP, nebo radeji od nej odchazeji za lepsim? Podle te statistiky bych tipoval, ze PHP lidi budou zdrhat treba k tomu Pythonu, ktery ma lehce podobne rysy, je o nej celkem zajem a plati se za nej stejne jak za Javu.
vycuc te statistiky:
1 Java — featured in 18% of adverts with an average salary of $100,000 USD
2 JavaScript — 17%, $90,000
3 C# — 16%, $85,000
4 C — 9%, $90,000
5 C++ — 9%, $95,000
6 PHP — 7%, $75,000
7 Python — 5.5%, $100,000
8 R — 3%, $95,000
9 Scheme — 3%, $65,000
10 Perl — 3%, $100,000
Dost me prekvapilo, ze Python je tak vysoko. U nas jsem o nem moc neslysel ani necetl. Proto jsem se ptal, jestli nekdo nema nejaka data o CR/SK (ta uvedena statistika je nejaka mezinarodni firma).
-
objektivne ma produkce Justina vysokou hodnotu, jak ukazuji jeho prijmy
Ty to opravdu nechápeš? Vždyť je to tak jednoduché. Finanční hodnotu to má možná proto, že to dokáže rozvřískat stadion nadržených patnáctek s mickey mousem na triku. O hudební kvalite to ale neříká vůbec nic. Jestli si tady někdo něco plete, pak jsou to slova hodnota a kvalita. Já celou dobu mluvím o tom druhém.
kvalita hudby je nemeratelna, nemame ziadnu jednotku kvality hudby. Co ale "odmerat" dokazeme je pocet fanusikov alebo prijmy umelca na zaklade ktorých dokazeme povedat pre ake mnozstvo fanusikov je justinova hudba subjektivne kvalitna.
-
Ok, at je po vasem (me penize ani popularita jazyka, ve kterem pisi, nejak extra nemotivuje; mysleno obecne), podivejme se na trh. Platy PHP vyvojaru nejsou ve srovnani s ostanimi nejak vysoke: http://www.sitepoint.com/best-programming-language-learn-2015-job-demand-salaries/. Mozna, ze nadanejsi programatori ani nechteji zacinat pracovat v PHP, nebo radeji od nej odchazeji za lepsim? Podle te statistiky bych tipoval, ze PHP lidi budou zdrhat treba k tomu Pythonu, ktery ma lehce podobne rysy, je o nej celkem zajem a plati se za nej stejne jak za Javu.
Doporucuji precist si ten clanek az do konce a neprehlednout kapitolu "Salaries are Averages" kde se venuji a vysvetluji prave to, nad cim tu spekulujes.
-
kvalita hudby je nemeratelna, nemame ziadnu jednotku kvality hudby. Co ale "odmerat" dokazeme je pocet fanusikov alebo prijmy umelca na zaklade ktorých dokazeme povedat pre ake mnozstvo fanusikov je justinova hudba subjektivne kvalitna.
Jakou váhu má názor prepubertálních dívčin, které zatím nic lepšího, než Lady Gaga nebo Justina Biebera(nebo co to do nich mainstream láduje), nepoznaly? Moc velkou ne. Zeptej se radši nějakého muzikanta, co ti na takové "Bejby, bejby, bejby, ou bejby"(velice hluboký text, to se zase musí nechat) řekne. Nahodíme tři akordy, primitivní rytmus, kolovrátkovou melodii, originální text o tom, jak se všichni vzájemně milujeme a je to tam. Nerad bych ale takovou blbost řešil celý den, takže se loučím.
-
kvalita hudby je nemeratelna, nemame ziadnu jednotku kvality hudby. Co ale "odmerat" dokazeme je pocet fanusikov alebo prijmy umelca na zaklade ktorých dokazeme povedat pre ake mnozstvo fanusikov je justinova hudba subjektivne kvalitna.
Jakou váhu má názor prepubertálních dívčin, které zatím nic lepšího, než Lady Gaga nebo Justina Biebera(nebo co to do nich mainstream láduje), nepoznaly? Moc velkou ne. Zeptej se radši nějakého muzikanta, co ti na takové "Bejby, bejby, bejby, ou bejby"(velice hluboký text, to se zase musí nechat) řekne. Nahodíme tři akordy, primitivní rytmus, kolovrátkovou melodii, originální text o tom, jak se všichni vzájemně milujeme a je to tam. Nerad bych ale takovou blbost řešil celý den, takže se loučím.
Minimalne ekonomicky ma vahu vysokou. A jinak v pozadi tusim jednak mezigeneracni spor, viz drivejsi 'rockovy kraval' jsou dnes klasiky a koho dnes oslovuje kdysi ocenovany Glenn Miller? A co je teda kvalitnejsi? A druhak tusim nadrazovani se mensiny nad vetsinou. Co je na jednoduchosti spatneho? Veskera popularni produkce je dnes jednoducha, Bedrich Smetana by se smal. Kde v dnesni moderni hudbe uslysis treba fugu? Je tedy veskera moderni popularni hudba z duvodu sve jednoduchosti nekvalitni? A to pomijim obsahovou redukci na pouhe dve toniny, durovou a molovou nebo zjednoduseni ve forme temperovaneho (roz)ladeni. A kde beres informaci, ze ty holky krome Justina neposlouchaji i neco jineho, treba ne az tolik oklestenou a jeste stale aspon trochu barvitou world nebo ethnic music? Zas jen predsudky a ocernovani. Stale stejne schema diskuse, at jde o jazyk nebo o hudbu.
-
Statickým metodám se úmyslně vyhýbám, proto mi tento detail unikl.
Tak to už máme boolean hodnoty, gettery/settery a statické metody v jediném vlákně. Které všechny konstrukce ještě považujete za naprosto zbytečné? Upřímně mě to zajímá.
Nikoli boolean hodnoty, ale boolean proměnné, které dnes už nedávají smysl.
Statické metody nás vrací do dob strukturovaného programování, stejně jako gettery a settery. Jistě, existuje pár případů, kdy statické metody smysl mají. Například matematické funkce nebo třeba vzor Simple Factory. V ostatních případech si většinou vynucují porušování zapouzdření jiných objektů, případně vytváří obtížně testovatelné skryté závislosti. Injektování třídy se statickou metodou v mnohých jazycích ani nejde. Jsou to samé klacky pod nohy a málo výhod.
-
Statickým metodám se úmyslně vyhýbám, proto mi tento detail unikl.
Tak to už máme boolean hodnoty, gettery/settery a statické metody v jediném vlákně. Které všechny konstrukce ještě považujete za naprosto zbytečné? Upřímně mě to zajímá.
Abych nezapomněl, tak jsem vyloučil konstrukce "else" a "elseif". Také jsem zrušil používání "break" uvitř konstrukce "switch". Aplikace to docela významně zkrátí, zjednoduší a zpřehlední.
Některé jazyky mají "else" jako součást ternárního operátoru. Tam ho samozřejmě používám.
-
Viz několik příspěvků zpět. Přetížení přiřazení.
Tak pretezovani standardnich operatoru je v mem zebricku jazykovych/programatorskych prasecin bezkonkurecne na prvnim miste.
Kdo tohle vymyslel, ten by mel byt bicovan kazde rano a nucen poslouchat Country Radio do obeda. Slysis, Stroustrupe?
Neni vetsi poteseni, nez pretizit "+", aby delal "-".
Tak dementovi do ruky taky nedas knipl, zejo... Dovolis mu maximalne kolobezku. Pro lopaty takove veci nejsou dobre. Profik je umi vyuzit.
Java ma jednu vyhodu, z jedne strany sice ten jazyk nic neumi, z druhe strany s nim muzou pracovat jak lopaty, tak profici. Ne ze by se v nem nedalo prasit, ale neda se prasit tak hrozne. Jak te tak posloucham, tak ty Youdo, by ses mel drzet neceho jednoducheho, co se neda moc posrat...
-
Myslím že volnost je ta hlavní vlastnost, nikdo tě nenutí dodržovat OOP přesně do puntíku. Naproti tomu v Java nutí programátora do OOP a programátoři to pak prostě různě obcházejí.
Java na jedné straně nutí do OOP, na druhé straně to programátoři obchází přes gettery a settery. A ještě se tím chlubí.
Gettery/settery nejak koliduji s OOP? Ja dosud zil v domeni, ze to je jedna ze zakladnich OOP vlastnosti (zapouzdreni stavu objektu a kontrolovany pristup k atributum)
Zajimave, prosim vysvetleni.
Jistěže nekolidují, je to prostě chabá náhrada za properties.
Ja treba nechapu, proc, kdyz uz properties mel naky object pascal od borlandu pred 20 lety, se nic takoveho nedokazalo dostat do javy. Ne ze bych si to nak extra pamatoval, ale zda se mne, ze to fungovalo docela dobre.
-
Statickým metodám se úmyslně vyhýbám, proto mi tento detail unikl.
Tak to už máme boolean hodnoty, gettery/settery a statické metody v jediném vlákně. Které všechny konstrukce ještě považujete za naprosto zbytečné? Upřímně mě to zajímá.
Abych nezapomněl, tak jsem vyloučil konstrukce "else" a "elseif". Také jsem zrušil používání "break" uvitř konstrukce "switch". Aplikace to docela významně zkrátí, zjednoduší a zpřehlední.
Některé jazyky mají "else" jako součást ternárního operátoru. Tam ho samozřejmě používám.
Proc nezrusit i cely switch? Krome nekolika malo pripadu (ale fakt malo) je to jen chapa nahrada za spatne navrzenou hierarchii trid (vetsinou se da nahradit polymorfismem a v lepsich!!! jazycich pattern matchingem).
-
Myslím že volnost je ta hlavní vlastnost, nikdo tě nenutí dodržovat OOP přesně do puntíku. Naproti tomu v Java nutí programátora do OOP a programátoři to pak prostě různě obcházejí.
Java na jedné straně nutí do OOP, na druhé straně to programátoři obchází přes gettery a settery. A ještě se tím chlubí.
Gettery/settery nejak koliduji s OOP? Ja dosud zil v domeni, ze to je jedna ze zakladnich OOP vlastnosti (zapouzdreni stavu objektu a kontrolovany pristup k atributum)
Zajimave, prosim vysvetleni.
Jistěže nekolidují, je to prostě chabá náhrada za properties.
Ja treba nechapu, proc, kdyz uz properties mel naky object pascal od borlandu pred 20 lety, se nic takoveho nedokazalo dostat do javy. Ne ze bych si to nak extra pamatoval, ale zda se mne, ze to fungovalo docela dobre.
Java je prostě omezená.
-
Co se týče té budoucnosti Pythonu... ;)
takové "Bejby, bejby, bejby, ou bejby"(velice hluboký text, to se zase musí nechat) [...] Bedrich Smetana by se smal.
A viděls někdy Hubičku? Běž na to a ještě budeš rád za Bejby, ou bejby :)
Lukáš (překvapen, ale mírně): Má rozmilá, jak žes to myslila?
Vendulka: Že k hubičkám teď věru času není.
Lukáš: Však Vendulko, já chtěl to políbení!
Vendulka: Já nechtěla!
Lukáš: Vždyť přece smím ho chtít - Ty mi ho dáš! (Blíží se jí.)
Vendulka (couvne, vážně): Ne, pravím! Nech mě být!
To je drama! :)
Kde v dnesni moderni hudbe uslysis treba fugu?
A proč bys měl slyšet v moderní hudbě fugu? Fuga je historická hudební forma, proč by ji měl někdo dneska napodobovat?
(Že ty s těma hudebníma pojmama jenom tak šermuješ jakože "Jó, hoši, tadlencta fuga, to vám je něco!"? ;) )
-
Abych nezapomněl, tak jsem vyloučil konstrukce "else" a "elseif". Také jsem zrušil používání "break" uvitř konstrukce "switch". Aplikace to docela významně zkrátí, zjednoduší a zpřehlední.
Některé jazyky mají "else" jako součást ternárního operátoru. Tam ho samozřejmě používám.
Proc nezrusit i cely switch? Krome nekolika malo pripadu (ale fakt malo) je to jen chapa nahrada za spatne navrzenou hierarchii trid (vetsinou se da nahradit polymorfismem a v lepsich!!! jazycich pattern matchingem).
Ano, ve spoustě případů se mi switch podařilo nahradit polymorfismem. Aplikaci to skutečně významně prospělo, protože pro přidání nové vlastnosti stačilo jen přidat další třídu a do zbytku aplikace nebylo potřeba nijak zasahovat.
Pattern matching používám také, např. v XSLT. Tím v mnoha případech odpadl nejen switch, ale i if.
-
autěr chtěl říct, že haskelleři píšou return stejně jako se píše v pythonu nebo cčku
V Pythonu ani céčku by nikdo za return nenapsal tak dlouhej řádek, v tom to je - `$` prostě svádí spojovat příliš dlouhé výrazy a to tak blbě, že musím očima skočit ze začátku řádku za dolar, dočíst do konce řádku a pak znovu pokračovat od jeho začátku. Pokud je tam ještě třeba nějaká ta částečná aplikace, je to guláš, který se špatně čte. Dá se na to zvyknout, ale vrchol ergonomie to teda není, ať si kdo chce co chce říká, ať si Curry slzy utírá ;)
-
Statickým metodám se úmyslně vyhýbám, proto mi tento detail unikl.
Tak to už máme boolean hodnoty, gettery/settery a statické metody v jediném vlákně. Které všechny konstrukce ještě považujete za naprosto zbytečné? Upřímně mě to zajímá.
Abych nezapomněl, tak jsem vyloučil konstrukce "else" a "elseif". Také jsem zrušil používání "break" uvitř konstrukce "switch". Aplikace to docela významně zkrátí, zjednoduší a zpřehlední.
Některé jazyky mají "else" jako součást ternárního operátoru. Tam ho samozřejmě používám.
Proc nezrusit i cely switch? Krome nekolika malo pripadu (ale fakt malo) je to jen chapa nahrada za spatne navrzenou hierarchii trid (vetsinou se da nahradit polymorfismem a v lepsich!!! jazycich pattern matchingem).
Pokud někdo použije Swift místo polymorfismu, tak je ňouma a měl by se nejdřív naučit programovat. Nicméně pattern matching je v podstatě jen zakamuflovaný switch, a k tomu s režií navíc, viz Swift.
-
Pokud někdo použije Swift místo polymorfismu, tak je ňouma a měl by se nejdřív naučit programovat. Nicméně pattern matching je v podstatě jen zakamuflovaný switch, a k tomu s režií navíc, viz Swift.
S prvnim souhlas (po s/Swift/switch :), s druhym uplne az tak ne. Protoze switch napriklad v C/Jave je strasne umezenej na primitivni hodnoty + retezce + vycty, kdezto pattern matching ma spoustu veci navic, od pascalovskeho 'a'..'z' az po rekneme regexpy. Tedy neco jako switch v TCL.
-
Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor (http://danielwestheide.com/blog/2012/11/21/the-neophytes-guide-to-scala-part-1-extractors.html). Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.
-
A proč bys měl slyšet v moderní hudbě fugu? Fuga je historická hudební forma, proč by ji měl někdo dneska napodobovat?
(Že ty s těma hudebníma pojmama jenom tak šermuješ jakože "Jó, hoši, tadlencta fuga, to vám je něco!"? ;) )
Jaká historická forma? Je to živá forma a to nejen pro interprety, ale i pro mladé skladatele. https://www.megaknihy.cz/hudba/215979-preludium-a-fuga-pro-klavir.html To bys takhle mohl odsoudit kde co, treba cihly :-).
Nejde o fugu, jako takovou, ale priklad hudebni slozitosti, vedle ktere je moderni popularni hudba detsky jednoducha. A nezodpovezena otazka zni, je proto nekvalitni? Poukazuji tim na zcestnost odsuzovani neceho jen proto, ze je to jednoduche.
Jak se rika, podle sebe soudim tebe, takze mi zkus neprisuzovat sve zpusoby chovani a zkus se vyjadrit k veci.
-
Pokud někdo použije Swift místo polymorfismu, tak je ňouma a měl by se nejdřív naučit programovat. Nicméně pattern matching je v podstatě jen zakamuflovaný switch, a k tomu s režií navíc, viz Swift.
S prvnim souhlas (po s/Swift/switch :), s druhym uplne az tak ne. Protoze switch napriklad v C/Jave je strasne umezenej na primitivni hodnoty + retezce + vycty, kdezto pattern matching ma spoustu veci navic, od pascalovskeho 'a'..'z' az po rekneme regexpy. Tedy neco jako switch v TCL.
Jasně, mea culpa (proč sakra nemůžu editovat příspěvek??!!). S tím druhým taky v podstatě souhlasím, protože to, že pattern matching se ve Swiftu uvozuje slovem switch, o ničem moc nevypovídá.
-
Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor (http://danielwestheide.com/blog/2012/11/21/the-neophytes-guide-to-scala-part-1-extractors.html). Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.
Ono je obecně škoda, že se v populárních jazycích moc nevidí koncepty z FP. Možná si tvůrci jazyků myslí, že na běžného vývojáře je FP moc složité/abstraktní/matoucí... Přitom takové OOP většina také dost patlá...
-
A proč bys měl slyšet v moderní hudbě fugu? Fuga je historická hudební forma, proč by ji měl někdo dneska napodobovat?
(Že ty s těma hudebníma pojmama jenom tak šermuješ jakože "Jó, hoši, tadlencta fuga, to vám je něco!"? ;) )
Jaká historická forma? Je to živá forma a to nejen pro interprety, ale i pro mladé skladatele. https://www.megaknihy.cz/hudba/215979-preludium-a-fuga-pro-klavir.html To bys takhle mohl odsoudit kde co, treba cihly :-).
Nejde o fugu, jako takovou, ale priklad hudebni slozitosti, vedle ktere je moderni popularni hudba detsky jednoducha. A nezodpovezena otazka zni, je proto nekvalitni? Poukazuji tim na zcestnost odsuzovani neceho jen proto, ze je to jednoduche.
Jak se rika, podle sebe soudim tebe, takze mi zkus neprisuzovat sve zpusoby chovani a zkus se vyjadrit k veci.
tak populární hudba za Bacha asi taky nebyla moc složitá
-
Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor (http://danielwestheide.com/blog/2012/11/21/the-neophytes-guide-to-scala-part-1-extractors.html). Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.
Ono je obecně škoda, že se v populárních jazycích moc nevidí koncepty z FP. Možná si tvůrci jazyků myslí, že na běžného vývojáře je FP moc složité/abstraktní/matoucí... Přitom takové OOP většina také dost patlá...
Je stejne zajimave, jak dlouho trvalo OOP, nez se prosadilo. Pokud si to pamatuju spravne, tak byl potreba prechod na graficka uzivatelska rozhrani, kde OOP zazarilo, a az pak se opravdu masove zacalo pouzivat. Mozna stojime na podobnem prahu - jak roste pocet jader, ale ne vykon jadra, tak FP pristup zacina byt dost zajimavy.
PS: Je opravdu dost mozne, ze je to pouze zpusobeno pristupem skol, kdy se imperativni pristup uci prvni. A teda prijde me, ze i podstatne lepe, nez treba ten funkcionalni. V imperativnim jsme rovnou zacali patlat v C, u funkcionalniho jsme nejdriv museli prezit a nepochopit (nasprtat se) teorii a az pak, pri reseni projektu, zacit chapat, o cem ze ta teorie asi ze byla.
-
je mi prostě subjektivně příjemnější
"Hello World!\nRunning on "
`append` pack (show caps)
`append` " CPUs!"
|> return
Tak v principu můžeš použít:
"Hello World!\nRunning on " <> pack (show caps) <> " CPUs!" & return
Ale je to takové nehaskelloidní :)
-
autěr chtěl říct, že haskelleři píšou return stejně jako se píše v pythonu nebo cčku
V Pythonu ani céčku by nikdo za return nenapsal tak dlouhej řádek, v tom to je - `$` prostě svádí spojovat příliš dlouhé výrazy a to tak blbě, že musím očima skočit ze začátku řádku za dolar, dočíst do konce řádku a pak znovu pokračovat od jeho začátku. Pokud je tam ještě třeba nějaká ta částečná aplikace, je to guláš, který se špatně čte. Dá se na to zvyknout, ale vrchol ergonomie to teda není, ať si kdo chce co chce říká, ať si Curry slzy utírá ;)
Hmm, imho je to tím, že v Haskellu je všechno něco jako: "a je ve skutečnosti b".
a = 1 + 1
Takže to return nalevo dává logiku. Zatímco v Imperativních jazycích je to spíše: "nejdřív udělej a;hotovo? Tak teď b; hotovo? tak teď c; hotovo? Tak teď vrať d."
-
Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor (http://danielwestheide.com/blog/2012/11/21/the-neophytes-guide-to-scala-part-1-extractors.html). Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.
Ono je obecně škoda, že se v populárních jazycích moc nevidí koncepty z FP. Možná si tvůrci jazyků myslí, že na běžného vývojáře je FP moc složité/abstraktní/matoucí... Přitom takové OOP většina také dost patlá...
Je stejne zajimave, jak dlouho trvalo OOP, nez se prosadilo. Pokud si to pamatuju spravne, tak byl potreba prechod na graficka uzivatelska rozhrani, kde OOP zazarilo, a az pak se opravdu masove zacalo pouzivat. Mozna stojime na podobnem prahu - jak roste pocet jader, ale ne vykon jadra, tak FP pristup zacina byt dost zajimavy.
PS: Je opravdu dost mozne, ze je to pouze zpusobeno pristupem skol, kdy se imperativni pristup uci prvni. A teda prijde me, ze i podstatne lepe, nez treba ten funkcionalni. V imperativnim jsme rovnou zacali patlat v C, u funkcionalniho jsme nejdriv museli prezit a nepochopit (nasprtat se) teorii a az pak, pri reseni projektu, zacit chapat, o cem ze ta teorie asi ze byla.
1) To bude asi tím, že GUI je jeden z mála reálných případů, kdy má smysl dědičnost (která jinak v OOP spíše škodí).
2) To je chybným stylem výuky, lepší by bylo postupovat - podle Komenského - od konkrétního k abstraktnímu, neb teorie je sice důležitá, ale lépe a rychleji ji člověk pochopí, když už má určité kousky znalostí (z praktických příkladů a menších projektů) a teprve poté si je začne dávat do širšího kontextu a objevovat souvislosti mezi nimi. Super příklad (byť trochu extrémní) jsou ony nechvalně známé monády, ale k ilustraci problému bohatě postačí třeba i teorie typů, jakmile se dostaneme k pojmu ko(ntra)variantní.
-
V Pythonu ani céčku by nikdo za return nenapsal tak dlouhej řádek, v tom to je - `$` prostě svádí spojovat příliš dlouhé výrazy a to tak blbě, že musím očima skočit ze začátku řádku za dolar, dočíst do konce řádku a pak znovu pokračovat od jeho začátku. Pokud je tam ještě třeba nějaká ta částečná aplikace, je to guláš, který se špatně čte. Dá se na to zvyknout, ale vrchol ergonomie to teda není, ať si kdo chce co chce říká, ať si Curry slzy utírá ;)
On return v haskellu není return :) Já osobně to tak různě mixuju, ale je fakt že s tím & operátorem to někdy vypadá líp:
result = input & map (+1)
& filter (<100)
& sum
Nejde o fugu, jako takovou, ale priklad hudebni slozitosti, vedle ktere je moderni popularni hudba detsky jednoducha. A nezodpovezena otazka zni, je proto nekvalitni? Poukazuji tim na zcestnost odsuzovani neceho jen proto, ze je to jednoduche.
No můj osobní názor teda je, že víceméně je. A to můžeš porovnat třeba s takovým Arvo Partem, jehož hudba je taky často jednoduchá a zároveň geniální. Výjimky se najdou, ale tak trošku potvrzují pravidlo.
-
Statickým metodám se úmyslně vyhýbám, proto mi tento detail unikl.
Tak to už máme boolean hodnoty, gettery/settery a statické metody v jediném vlákně. Které všechny konstrukce ještě považujete za naprosto zbytečné? Upřímně mě to zajímá.
Abych nezapomněl, tak jsem vyloučil konstrukce "else" a "elseif". Také jsem zrušil používání "break" uvitř konstrukce "switch". Aplikace to docela významně zkrátí, zjednoduší a zpřehlední.
Některé jazyky mají "else" jako součást ternárního operátoru. Tam ho samozřejmě používám.
Proc nezrusit i cely switch? Krome nekolika malo pripadu (ale fakt malo) je to jen chapa nahrada za spatne navrzenou hierarchii trid (vetsinou se da nahradit polymorfismem a v lepsich!!! jazycich pattern matchingem).
pattern matching je len vylepseny switch.
-
Proc nezrusit i cely switch? Krome nekolika malo pripadu (ale fakt malo) je to jen chapa nahrada za spatne navrzenou hierarchii trid (vetsinou se da nahradit polymorfismem a v lepsich!!! jazycich pattern matchingem).
pattern matching je len vylepseny switch.
Ne tak docela. Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch).
-
[quote author=andy link=topic=13173.msg165937#msg165937 date=1463144144]
result = input & map (+1)
& filter (<100)
& sum
[/quote]
vypadá to hrozně
-
Proc nezrusit i cely switch? Krome nekolika malo pripadu (ale fakt malo) je to jen chapa nahrada za spatne navrzenou hierarchii trid (vetsinou se da nahradit polymorfismem a v lepsich!!! jazycich pattern matchingem).
pattern matching je len vylepseny switch.
Ne tak docela. Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch).
Co to v praxi znamená?
-
Proc nezrusit i cely switch? Krome nekolika malo pripadu (ale fakt malo) je to jen chapa nahrada za spatne navrzenou hierarchii trid (vetsinou se da nahradit polymorfismem a v lepsich!!! jazycich pattern matchingem).
pattern matching je len vylepseny switch.
Ne tak docela. Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch).
Ako to myslite? mozte uviest nejaky priklad?
Lebo mne pride zapis:
switch (var)
{
case 'a': return 1;
case 'b': return 2;
case 'c': return 3;
default: return -1;
}
je ekvivalentny zapisu:
match var with
| 'a' -> 1
| 'b' -> 2
| 'c' -> 3
| _ -> -1
Akurat pri matchu mam este dalsie moznosti - napriklad mozem matchovat polozky listu:
match list with
| [] -> []
| ((head1 :: head2) as lst) :: tail -> lst
| head :: tail -> [head]
alebo pouzivat active patterns.
-
Proc nezrusit i cely switch? Krome nekolika malo pripadu (ale fakt malo) je to jen chapa nahrada za spatne navrzenou hierarchii trid (vetsinou se da nahradit polymorfismem a v lepsich!!! jazycich pattern matchingem).
pattern matching je len vylepseny switch.
Ne tak docela. Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch).
Co to v praxi znamená?
Chová se to tak, jako kdyby ten pattern byl názvem funkce. Něco jako stráže v Haskellu, ale o level výš - přímo v kořeni aplikace. Každý pattern může (nemusí) být v samostatném souboru, přidání dalšího patternu tedy nemusí znamenat žádný zásah do již hotové části aplikace.
-
match var with
| 'a' -> 1
| 'b' -> 2
| 'c' -> 3
| _ -> -1
V jednoduchosti (popsáno metajazykem) by to mohlo vypadat asi takto:
match 'a' -> 1
match 'b' -> 2
match 'c' -> 3
match '*' -> -1
Slovo 'match' tam samozřejmě být nemusí a tím se to pomalu začne podobat našemu oblíbenému AWK. Záleží pak už jen na tom, jaké má dotyčný engine ambice - jednoduchost či komplexnost.
-
Jaká historická forma? Je to živá forma a to nejen pro interprety, ale i pro mladé skladatele. https://www.megaknihy.cz/hudba/215979-preludium-a-fuga-pro-klavir.html To bys takhle mohl odsoudit kde co, treba cihly :-).
A co jako? Je to prostě barokní forma, což nevylučuje, aby někdo podle jejích pravidel skládal později. Třeba jako cvičení, z lásky k baroku nebo ze srandy. Pseudogotické stavby se taky staví dodnes a nikdo nebude argumentovat, že moderní stavby jsou špatné, protože neobsahují lomený oblouk :)
Nejde o fugu, jako takovou, ale priklad hudebni slozitosti, vedle ktere je moderni popularni hudba detsky jednoducha. A nezodpovezena otazka zni, je proto nekvalitni? Poukazuji tim na zcestnost odsuzovani neceho jen proto, ze je to jednoduche.
Jak se rika, podle sebe soudim tebe, takze mi zkus neprisuzovat sve zpusoby chovani a zkus se vyjadrit k veci.
Vyjadřuju se k věci celou dobu. Souhlasím, že složitost není měřítkem ničeho, protože v umění není nic měřítkem ničeho. Umění je čistě konsensuální koncept. Co jím prohlásíme, to jím bude. A co prohlásíme za kvalitní, to budou lidi jako kvalitní vnímat. Mj. proto, že se tím potvrzuje společenský status.
Mj. taky hudba působí na mnoha vrstvách a různými způsoby. Já třeba docela respektuju freetekno a hladám v něm úplně jiné věci než třeba v tom Smetanovi - a nikdy by mě nenapadlo je srovnávat. Při Smetanovi nezažiju to, co na freeteknu a naopak.
...z čehož plyne, že Python má budoucnost i když je úplně jiný než Haskell! ;)
-
Ale je to takové nehaskelloidní :)
No právě - proto jsem to říkal - že v Haskellu je prostě zvykem psát tím způsobem, který vyžaduje očima těkat. Jakoby sám o sobě ten jazyk nebyl dost komplikovanej, ještě se do toho přidá tohle :) Zlatej Elm! ;)
-
S ničím se to nemá přehánět. Ani s jednoduchostí. Ono to pak totiž může působit ne jednoduše, ale vyloženě primitivně, až si skoro můžete připadat, jestli si z vás dotyčný "umělec" nedělá srandu.
Hudební producenti se snaží dělat hudbu schválně co nejpřístupnější širokým masám, chrlí tu nejpřímočařejší, nejstravitelnější hudbu, jaká se dá vůbec vyprodukovat, aby na ní vydělali co nejvíc. S takovou hudbou nebude mít problém ani vaše prababička, zato jsou to hitovky typu jedním uchem dovnitř, druhým ven. Prostě žádný hudební orgasmus se nekoná.
Naštěstí jsou tady pořád opravdoví umělci, kterým jde v první řadě o hudbu samotnou. Ty nikdy v rádiu neuslyšíte a miliardy fanoušků taky mít nebudou, ale jim je to celkem jedno, není to totiž jejich primárním cílem.
Koho ta sterilní rádiová produkce baví, ten ať si to užije. Přeju příjemný poslech.
-
match var with
| 'a' -> 1
| 'b' -> 2
| 'c' -> 3
| _ -> -1
V jednoduchosti (popsáno metajazykem) by to mohlo vypadat asi takto:
match 'a' -> 1
match 'b' -> 2
match 'c' -> 3
match '*' -> -1
Slovo 'match' tam samozřejmě být nemusí a tím se to pomalu začne podobat našemu oblíbenému AWK. Záleží pak už jen na tom, jaké má dotyčný engine ambice - jednoduchost či komplexnost.
Ach jo, s tebou je někdy práce.
V kódu:
switch(True) {
case a > 1 && a < 10: do_foo(); break;
case is_valid(b): do_boo(); break;
case a <= 1: do_goo(); break;
default: do_otherwise();
}
Sice funguje, jenže je to taková problematická věc. Protože za kontext switche/pattern matchingu považuje celej scope. Což je sice hrozně pohodlný, a rád to používám, ale taky dost nebezpečný.
Samozřejmě tam nadřazený element je. Vždycky tam musí být. V Haskellu, kde se takto přetěžují funkce, je nadřazeným elementem modul (scope modulu).
No, a říct o tom, že: "Ne tak docela. Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch)." je prostě jenom neužitečná provokace.
-
Haskell je prakticky asi jak pro koho - osobne si myslim, ze je to pouze o zpusobu vzdelavani, kde se na zacatek silne preferuji imperativni jazyky (Java, Python, Pascal). Napr. na FITu jsme si funkcionalni pristup osahali az v magisterskem, ktere bylo povazovano nekterymi prednasejicimi za nadstandard a do praxe muze student v pohode i jen s bakalarem.
Osobne si nemyslim, ze kvalita jakkoliv souvisi s popularitou. Kvalitni jazyk se totiz podle me nesnazi pretrhnout kvuli zacatecnikum a znehodnotit tak sve dalsi casti nebo cely svuj pristup. A kdyz jsme u toho, tak pokud chcete objektivne merit kvalitu/pouzitelnost a vztahnete ji i k popularite, jak presne objektivne merite popularitu? :D Podle radek kodu v produkci? Celkoveho vydelku vyvojaru pouzivaci ten jazyk? Nejake nahodne zvolene kriterium jako pocet commitu GitHubu a pocet dotazu na StackOverflow?
Prakticka pouzitelnost jazyka zase nema s popularitou IMO nic spolecneho. I uplny odpad, jako PHP, ktery je obtizne pouzitelny (poskytl jsem dost prikladu, nekolik jich dodal i Kit a ten v tom dokonce i vyviji trochu vice) a stejne se stal popularnim. Stejne tak to nerika nic o pouzitelnosti a kvalite jeho knihoven a celkove ekosystemu. (Ktery ho v pripade PHP drzi nad vodou.) To stejne mohu vztahnout na NodeJS - to ze je JavaScript nejpopularnejsi jazyk na planete (http://redmonk.com/sogrady/2016/02/19/language-rankings-1-16/) z neho nedela nejlepsi jazyk a ani nejpouzitelnejsi, rozhodne ne nejak univerzalne. S chladnou jistotou bych vzdy doporucil Javu, Scalu nebo klidne i ten Haskell na back-end pro jakykoliv projekt, ktery neni "fire-and-forget" - tj. ze se ocekava dlouha doba udrzby. Proste dynamicke jazyky, stejne jako treba ty "pokrocile magie", tam podle me nepatri. Dynamicke jazyky typu Ruby se skvele hodi pro stratup, to nepopiram, projektiky jsou obecne mensi, potrebuji to mit rychle udelane a pokud to uspejeje a budou problemy (u tech uspesnych casto ctu, ze jsou), tak to proste prepisou do neceho vice se hodiciho na dany ukol (vetsinou ta Java ci C#, videl jsem uz ale i treba NodeJS, k cemuz jsem byl trosku skepticky).
S tou pajpou jsem myslel Python. V JavaScriptu je vyhoda, ze je prave ten kratky zapis closure, takze staci pribrat treba ten Lodash a muzete vesele retezit. Bohuzel v Pythonu je lambda silene dlouha na zapis, jako kdyby autor nechtel, aby se to moc pouzivalo. Coz ostatne sedi k jeho postoji o FP. To jsme ale trochu odbocili, protoze ani o JS jsem nepsal, ze je nejake skvele na FP, rozhodne ne out-of-the-box (chybi mi spousta funkci pro manipulaci s poli). Puvodne jsem to srovnaval se Scalou a tam jsou i veci, ktere umoznuji opravdu jednoduchy kod (ktery me prijde hezky, ale to je opravdu silne subjektivni), treba placeholder _.
(1 to 10).filter(_ % 2 == 0).map(_ * 10)
Slovo lambda se používá například i ve scheme. V délce zápisu není největší problém. Neexistenci vícepříkazových anonymních funkcí je třeba brát jako vlastnost pythonu a naučit se s tím žít. Ten váš příklad bych v pythonu přepsal jako [i*10 for i in range(1,10) if i % 2 == 0]. Python není FP jazyk a nesnaží se jím být. Kdo chce programovat za každou cenu funkcionálně, ať používá něco jiného. Ano, python je jednoduchý a snaží se přetrhnout kvůli začátečníkům. Díky tomu má velkou komunitu a velké množství knihoven. Proč řešit jednoduché problémy složitým nástrojem?
-
Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor (http://danielwestheide.com/blog/2012/11/21/the-neophytes-guide-to-scala-part-1-extractors.html). Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.
Ono je obecně škoda, že se v populárních jazycích moc nevidí koncepty z FP. Možná si tvůrci jazyků myslí, že na běžného vývojáře je FP moc složité/abstraktní/matoucí... Přitom takové OOP většina také dost patlá...
Je stejne zajimave, jak dlouho trvalo OOP, nez se prosadilo. Pokud si to pamatuju spravne, tak byl potreba prechod na graficka uzivatelska rozhrani, kde OOP zazarilo, a az pak se opravdu masove zacalo pouzivat. Mozna stojime na podobnem prahu - jak roste pocet jader, ale ne vykon jadra, tak FP pristup zacina byt dost zajimavy.
PS: Je opravdu dost mozne, ze je to pouze zpusobeno pristupem skol, kdy se imperativni pristup uci prvni. A teda prijde me, ze i podstatne lepe, nez treba ten funkcionalni. V imperativnim jsme rovnou zacali patlat v C, u funkcionalniho jsme nejdriv museli prezit a nepochopit (nasprtat se) teorii a az pak, pri reseni projektu, zacit chapat, o cem ze ta teorie asi ze byla.
Já jsem se s haskellem setkal ve škole asi před 10-ti lety a nevzpomínám si, že by ho někdo ze spolužáků začal ihned používat v praxi. Víc než na škole záleží na vyspělosti ekosystému okolo. Ten je dneska úplně jinde. Naopak, dynamické jazyky jako ruby, php a js se nikdy nikde neučily a rozšířily se docela rychle.
-
V jednoduchosti (popsáno metajazykem) by to mohlo vypadat asi takto:
match 'a' -> 1
match 'b' -> 2
match 'c' -> 3
match '*' -> -1
Slovo 'match' tam samozřejmě být nemusí a tím se to pomalu začne podobat našemu oblíbenému AWK. Záleží pak už jen na tom, jaké má dotyčný engine ambice - jednoduchost či komplexnost.
V kódu:
switch(True) {
case a > 1 && a < 10: do_foo(); break;
case is_valid(b): do_boo(); break;
case a <= 1: do_goo(); break;
default: do_otherwise();
}
Sice funguje, jenže je to taková problematická věc. Protože za kontext switche/pattern matchingu považuje celej scope. Což je sice hrozně pohodlný, a rád to používám, ale taky dost nebezpečný.
Samozřejmě tam nadřazený element je. Vždycky tam musí být. V Haskellu, kde se takto přetěžují funkce, je nadřazeným elementem modul (scope modulu).
No, a říct o tom, že: "Ne tak docela. Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch)." je prostě jenom neužitečná provokace.
Evidentně jsi vůbec nepochopil, o čem jsem psal. Nevadí.
To sis vůbec nevšiml, že tam žádný "switch" nemám? Ani ve zdrojáku není. Nebavil jsem se o Haskellu, ale o metajazyku ve stylu AWK a jemu podobných. Nadřazeným elementem je samotný engine toho jazyka.
-
V jednoduchosti (popsáno metajazykem) by to mohlo vypadat asi takto:
match 'a' -> 1
match 'b' -> 2
match 'c' -> 3
match '*' -> -1
Slovo 'match' tam samozřejmě být nemusí a tím se to pomalu začne podobat našemu oblíbenému AWK. Záleží pak už jen na tom, jaké má dotyčný engine ambice - jednoduchost či komplexnost.
V kódu:
switch(True) {
case a > 1 && a < 10: do_foo(); break;
case is_valid(b): do_boo(); break;
case a <= 1: do_goo(); break;
default: do_otherwise();
}
Sice funguje, jenže je to taková problematická věc. Protože za kontext switche/pattern matchingu považuje celej scope. Což je sice hrozně pohodlný, a rád to používám, ale taky dost nebezpečný.
Samozřejmě tam nadřazený element je. Vždycky tam musí být. V Haskellu, kde se takto přetěžují funkce, je nadřazeným elementem modul (scope modulu).
No, a říct o tom, že: "Ne tak docela. Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch)." je prostě jenom neužitečná provokace.
Evidentně jsi vůbec nepochopil, o čem jsem psal. Nevadí.
To sis vůbec nevšiml, že tam žádný "switch" nemám? Ani ve zdrojáku není. Nebavil jsem se o Haskellu, ale o metajazyku ve stylu AWK a jemu podobných. Nadřazeným elementem je samotný engine toho jazyka.
Ale všiml. A ty si prosím povšimni, že v mém případě jde jen o syntaktickou nutnost danou jazykem. Ale technicky tam být nemusí. Proto platí, že pattern matching je jen lepší switch. Principielně to totiž je fakt úplně stejný.
Pomohlo by, aby jsi uvedl kompletní příklad. Tento druhý ti nebude fungovat, páč tam neuvádíš var.
-
Pomohlo by, aby jsi uvedl kompletní příklad. Tento druhý ti nebude fungovat, páč tam neuvádíš var.
Podívej se na libovolný skript pro AWK a uvidíš kompletní příklad. Nikde žádný cyklus, nikde žádný switch. Prostě jen vzorek, akce, vzorek, akce, ...
-
Pomohlo by, aby jsi uvedl kompletní příklad. Tento druhý ti nebude fungovat, páč tam neuvádíš var.
Podívej se na libovolný skript pro AWK a uvidíš kompletní příklad. Nikde žádný cyklus, nikde žádný switch. Prostě jen vzorek, akce, vzorek, akce, ...
Chápu. Problém je v tom, že v tvém příkladu tam schází "co" matchuješ. Takže díky tomuto opomenutí si nabil dojmu, jakoby "Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch)".
To je všechno, co jsem chtěl řešit. Přeji pěkný den.
-
Pomohlo by, aby jsi uvedl kompletní příklad. Tento druhý ti nebude fungovat, páč tam neuvádíš var.
Podívej se na libovolný skript pro AWK a uvidíš kompletní příklad. Nikde žádný cyklus, nikde žádný switch. Prostě jen vzorek, akce, vzorek, akce, ...
Chápu. Problém je v tom, že v tvém příkladu tam schází "co" matchuješ. Takže díky tomuto opomenutí si nabil dojmu, jakoby "Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch)".
To je všechno, co jsem chtěl řešit. Přeji pěkný den.
Matchuješ vstupní data. Žádná proměnná, prostě standardní vstup.
Nabil sis akorát čumák. Ostatní nabyli dojmu.
-
Chápu. Problém je v tom, že v tvém příkladu tam schází "co" matchuješ. Takže díky tomuto opomenutí si nabil dojmu, jakoby "Ten pattern totiž nemusí být součástí nějakého nadřazeného elementu (konstrukce if nebo switch)".
To je všechno, co jsem chtěl řešit. Přeji pěkný den.
Matchuješ vstupní data. Žádná proměnná, prostě standardní vstup.
Já to chápu. Prostě v jednom programu je možné použít vstupní proud jako argument matchování, a ty z toho děláš obecný rozdíl mezi switchem a pattern matchingem. Je mi to jasný.
Nabil sis akorát čumák. Ostatní nabyli dojmu.
Ach, samozřejmě sorry - "nabýt".
-
Spousta funkcí v haskellu má nic neříkající typovou signaturu jako a -> a. Například většina matematických funkcí má signaturu Floating a => a -> a. Docstring v pythonu často obsahuje příklad použití, který mohu spustit jako test.
To je naopak signatura, která říká naprosto všechno - že jde o fci, která může pracovat s libovolným typem ze třídy Floating a vrací stejný typ, jaký mu dám. Co víc bys mohl chtít vědět?
Jak jsem psal výše. Mohl bych chtít krátký popis chování funkce v docstringu a několik příkladů použití, které mohu spustit jako test. Reagoval jsem na BoneFlute, který říkal, že typová signatura může zastoupit dokumentaci. Nezpochyňuji užitečnost statického typování, ale nedovedu si představit, jak vám může zastoupit testy a dokumentaci. Možná je to jen můj omezený pohled.
-
Jak jsem psal výše. Mohl bych chtít krátký popis chování funkce v docstringu a několik příkladů použití, které mohu spustit jako test. Reagoval jsem na BoneFlute, který říkal, že typová signatura může zastoupit dokumentaci. Nezpochyňuji užitečnost statického typování, ale nedovedu si představit, jak vám může zastoupit testy a dokumentaci. Možná je to jen můj omezený pohled.
Proti tomu nic nemám, ale ten tvůj argument byl chybný. Signatura a -> a není o nic horší nebo lepší než Int -> String
-
Spousta funkcí v haskellu má nic neříkající typovou signaturu jako a -> a. Například většina matematických funkcí má signaturu Floating a => a -> a. Docstring v pythonu často obsahuje příklad použití, který mohu spustit jako test.
To je naopak signatura, která říká naprosto všechno - že jde o fci, která může pracovat s libovolným typem ze třídy Floating a vrací stejný typ, jaký mu dám. Co víc bys mohl chtít vědět?
Jak jsem psal výše. Mohl bych chtít krátký popis chování funkce v docstringu a několik příkladů použití, které mohu spustit jako test. Reagoval jsem na BoneFlute, který říkal, že typová signatura může zastoupit dokumentaci. Nezpochyňuji užitečnost statického typování, ale nedovedu si představit, jak vám může zastoupit testy a dokumentaci. Možná je to jen můj omezený pohled.
To je nedorozumění:
- Typová signtura je víc i míň než testy - je kvalitnější, pokrývaj větší oblast (to je to víc) a něco nedokáže podchytit (to je to míň).
- Typová signatura nenahrazuje dokumentaci. Ale může sloužit jako slušný základ dokumentace. Plus to, že je vynucená.
Takže určitě ne, že by typy mohli dokumentaci zastoupit. Rozhodně ne plně.
Hlavně jsem se točil kolem toho, že co se nevynutí, tak to nedostaneš.
-
Jak jsem psal výše. Mohl bych chtít krátký popis chování funkce v docstringu a několik příkladů použití, které mohu spustit jako test. Reagoval jsem na BoneFlute, který říkal, že typová signatura může zastoupit dokumentaci. Nezpochyňuji užitečnost statického typování, ale nedovedu si představit, jak vám může zastoupit testy a dokumentaci. Možná je to jen můj omezený pohled.
Proti tomu nic nemám, ale ten tvůj argument byl chybný. Signatura a -> a není o nic horší nebo lepší než Int -> String
Myslel jsem to tak, že když se ze signatury matematické funkce dovím, že má argument typu číslo a vrací číslo, tak mi to většinou moc nepomůže. Chtěl bych vědět jakou operaci s těmi čísly provádí. V některé z předchozích diskuzí někdo psal, že vyhledává haskellovské funkce podle signatury na téhle stránce https://www.haskell.org/hoogle/ . Nedovedu si představit jak to funguje v případě těchto běžných signatur.
-
Jak jsem psal výše. Mohl bych chtít krátký popis chování funkce v docstringu a několik příkladů použití, které mohu spustit jako test. Reagoval jsem na BoneFlute, který říkal, že typová signatura může zastoupit dokumentaci. Nezpochyňuji užitečnost statického typování, ale nedovedu si představit, jak vám může zastoupit testy a dokumentaci. Možná je to jen můj omezený pohled.
Proti tomu nic nemám, ale ten tvůj argument byl chybný. Signatura a -> a není o nic horší nebo lepší než Int -> String
Myslel jsem to tak, že když se ze signatury matematické funkce dovím, že má argument typu číslo a vrací číslo, tak mi to většinou moc nepomůže. Chtěl bych vědět jakou operaci s těmi čísly provádí. V některé z předchozích diskuzí někdo psal, že vyhledává haskellovské funkce podle signatury na téhle stránce https://www.haskell.org/hoogle/ . Nedovedu si představit jak to funguje v případě těchto běžných signatur.
Pokud má funkce rozumný název, už to hodně napoví nebo ne? Ideálně vhodným názvem metody/funkce zrcadlím problém z domény -- tak nějak, jak se to praktikuje v DDD. Když máš funkci pojmenovanou jako calculate(i) -- tak ti je to k ničemu v jakémkoliv jazyce; pokud není ve vhodně pojmenovaném modulu, třídě -- zasazená do kontextu.
-
Myslel jsem to tak, že když se ze signatury matematické funkce dovím, že má argument typu číslo a vrací číslo, tak mi to většinou moc nepomůže. Chtěl bych vědět jakou operaci s těmi čísly provádí. V některé z předchozích diskuzí někdo psal, že vyhledává haskellovské funkce podle signatury na téhle stránce https://www.haskell.org/hoogle/ . Nedovedu si představit jak to funguje v případě těchto běžných signatur.
Tak řekněme, že heldám funkci, která mi třeba najde, jestli v seznamu je prvek splňující nějaké kritérium. Takže máme signaturu:
(a -> Bool) -> [a] -> Bool a vida - vypadne hned na začátku "all" a "any".
Tak třeba něco, co spočte, kolikrát je daný prvek v poli:
Eq a => a -> [a] -> Int a hned máme elemIndexJust a countElem.
Chcem třeba akci zopakovat n-krát a dostat v seznamu výsledky těch akcí:
Monad m => Int -> m a -> m [a] - replicateM
Co třeba... takový sum:
Num a => [a] -> aa máme product, sum
Tak co takhle funkce na setřídění, která třídí prvky přímo:
Ord a => [a] -> [a] a vypadnul nám "sort" a hned potom "ordNub", který odstraňuje duplikáty v n*logn.
A co třeba třídění podle custom funkce:
(a -> a -> Ordering) -> [a] -> [a]A hned máme sortBy a nubOrdBy.
A nebo máme funkci "a -> a" a chceme ji n-krát iterovat:
Int -> (a -> a) -> a -> a
-
Ještě k těm typům - většina lidí si totiž neuvědomuje, že čím méně je toho v typu specifikováno, tím méně toho ta funkce může dělat. Třeba jediná smysluplná věc, kterou může funkce se signaturou "a -> a" dělat, je ten argument vrátit (nebo se zacyklit, ale to není moc rozumné). Nic víc ta funkce dělat nemůže, protože o "a" nic neví. Funkce "[a] -> Int" pravděpodobně vrátí nějakou funkci délky pole. Funkce "[a] -> [a]" provede nějakou reorganizaci/filtraci na poli, která není závislá na prvcích, ale výhradně na počtu prvků.
Funkce "Eq a => a -> a -> Bool" může být buď "==" nebo "!=", nic jiného nedává smysl. Takže ta signatura fakt funguje jako dost dobrá dokumentace, velmi často ve spojení se jménem bohatě stačí. Osobně mám akorát problém, když přijdu k nové knihovně a nevím jak začít. Ale v momentě, kdy už se nějak orientuju, tak v podstatě ty signatury stačí.
-
Myslel jsem to tak, že když se ze signatury matematické funkce dovím, že má argument typu číslo a vrací číslo, tak mi to většinou moc nepomůže. Chtěl bych vědět jakou operaci s těmi čísly provádí.
Já třeba v Haskellu nedělám, teď jsem akorát asi 14dní dělal intenzivně v Elmu a musím říct, že první, na co jsem se díval, byly vždycky signatury. Musíš totiž taky vzít v úvahu, že u FP jazyků se daleko víc pracuje se základními primitivními operacemi - přidat něco do listu, něco z listu vyfiltrovat, aplikovat nějakou lambdu na všechny prvky... A tam ti prostě stačí vidět map :: (a -> b) -> [a] -> [ b ] a čte se ti to líp (pohodlněji) než nějaká slovní omáčka - pokud ty základní operace znáš a poznáš je aspoň přibližně podle názvu.
-
Ještě k těm typům - většina lidí si totiž neuvědomuje, že čím méně je toho v typu specifikováno, tím méně toho ta funkce může dělat. Třeba jediná smysluplná věc, kterou může funkce se signaturou "a -> a" dělat, je ten argument vrátit (nebo se zacyklit, ale to není moc rozumné). Nic víc ta funkce dělat nemůže, protože o "a" nic neví. Funkce "[a] -> Int" pravděpodobně vrátí nějakou funkci délky pole. Funkce "[a] -> [a]" provede nějakou reorganizaci/filtraci na poli, která není závislá na prvcích, ale výhradně na počtu prvků.
Funkce "Eq a => a -> a -> Bool" může být buď "==" nebo "!=", nic jiného nedává smysl. Takže ta signatura fakt funguje jako dost dobrá dokumentace, velmi často ve spojení se jménem bohatě stačí. Osobně mám akorát problém, když přijdu k nové knihovně a nevím jak začít. Ale v momentě, kdy už se nějak orientuju, tak v podstatě ty signatury stačí.
To dává smysl. Díky za vysvětlení. Nechtěl jsem nic zpochybňovat, jen jsem si nedokázal představit jak to může fungovat v praxi.
-
To dává smysl. Díky za vysvětlení. Nechtěl jsem nic zpochybňovat, jen jsem si nedokázal představit jak to může fungovat v praxi.
Prekvapive dobre. A dalsi prekvapeni je, ze jsou ty signatury v Haskellu podstatne lip citelny nez treba templaty v C++, coz je principielne dost podobna vec, ale z templatu by se clovek zblil :)
-
Ještě bych možná dodal, že funkce typu "Int -> Int -> Int -> Int" jsou v Haskellu tak trošku antipattern - tak nějak nikdo nemá moc rád více než 1 parametr stejného typu. Ne vždycky se tomu člověk vyhne, ale existují různé snadno použitelné "tagované" typy, které v tom trochu dělají pořádek - takže ve výsledku pak vypadá taková funkce např.:
Email -> [Email] -> Subject -> [Part] -> Message Takhle to obvykle není v knihovnách, ale ve vlastním kódu tohle strašně pomáhá.
-
Ještě bych možná dodal, že funkce typu "Int -> Int -> Int -> Int" jsou v Haskellu tak trošku antipattern - tak nějak nikdo nemá moc rád více než 1 parametr stejného typu. Ne vždycky se tomu člověk vyhne, ale existují různé snadno použitelné "tagované" typy, které v tom trochu dělají pořádek - takže ve výsledku pak vypadá taková funkce např.: Email -> [Email] -> Subject -> [Part] -> Message Takhle to obvykle není v knihovnách, ale ve vlastním kódu tohle strašně pomáhá.
Sémantické označení obyčejného typu String pomáhá nejen v Haskellu. Pak to teprve vypadá jako dokumentace, která nepotřebuje další komentáře.
-
Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor (http://danielwestheide.com/blog/2012/11/21/the-neophytes-guide-to-scala-part-1-extractors.html). Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.
Ono je obecně škoda, že se v populárních jazycích moc nevidí koncepty z FP. Možná si tvůrci jazyků myslí, že na běžného vývojáře je FP moc složité/abstraktní/matoucí... Přitom takové OOP většina také dost patlá...
Je stejne zajimave, jak dlouho trvalo OOP, nez se prosadilo. Pokud si to pamatuju spravne, tak byl potreba prechod na graficka uzivatelska rozhrani, kde OOP zazarilo, a az pak se opravdu masove zacalo pouzivat. Mozna stojime na podobnem prahu - jak roste pocet jader, ale ne vykon jadra, tak FP pristup zacina byt dost zajimavy.
PS: Je opravdu dost mozne, ze je to pouze zpusobeno pristupem skol, kdy se imperativni pristup uci prvni. A teda prijde me, ze i podstatne lepe, nez treba ten funkcionalni. V imperativnim jsme rovnou zacali patlat v C, u funkcionalniho jsme nejdriv museli prezit a nepochopit (nasprtat se) teorii a az pak, pri reseni projektu, zacit chapat, o cem ze ta teorie asi ze byla.
Já jsem se s haskellem setkal ve škole asi před 10-ti lety a nevzpomínám si, že by ho někdo ze spolužáků začal ihned používat v praxi. Víc než na škole záleží na vyspělosti ekosystému okolo. Ten je dneska úplně jinde. Naopak, dynamické jazyky jako ruby, php a js se nikdy nikde neučily a rozšířily se docela rychle.
No, ja se taky "setkal", ale ve srovnani s imperativnim pristupem, ktery se do nas tlacil vlastne neustale, setkani v ramci poloviny jednoho predmetu bylo opravdu slabe.
stredni (gympl):
- Pascal (nekteri spoluzaci z prumek znali trochu C, dost lidi neznalo nic)
bc:
- C (nekolik predmetu)
- ASM
- C++/Java (na vyber jedno)
- Python (myslim take nekolikrat na psani ukolu)
- cisty stary JavaScript
- Pascal+pseudo kod
mgr:
- C/C++ (nekolik predmetu, na projekty)
- Java/nejaky neznamy jazyk na IS
- 1x jazyk podle vlastniho vyberu (pouzil jsem Scalu)
- Ada+nejaky dalsi paralelni
- Haskell+Prolog (vcetne teorie k obema paradigmatum)
- 2x C#
- Python (zase ukoly, tusim sifrovani)
Asi jsem na neco zapomnel, ale funkcionalni bych si pamatoval. Kdyz to shrneme, tak mame za cele studium 0,5 predmetu venovanemu funkcionalnimu jazyku (jeste teda JavaScript, ale tomu nebyl take venovan cely predmet a FP jako takove se tam snad ani neresilo; navic JS podle nekterych definic ani nespada do funkcionalnich jazyku). Takze ne, nedivim se, ze nikdo z mych spoluzaku nebezel a nezacal pracovat v FP jazyce.
Je mozne, ze na vasi skole jste meli destiky predmetu vyucujici a vyuzivajici FP a funckionalni jazyky. Sice jsem znacne skepticky, ale co. Pokud je tomu opravdu tak, prosim podelte se o jmeno skoly (bych si treba i precetl jake predmety jste meli a tise zavidel).
-
Ještě bych možná dodal, že funkce typu "Int -> Int -> Int -> Int" jsou v Haskellu tak trošku antipattern - tak nějak nikdo nemá moc rád více než 1 parametr stejného typu. Ne vždycky se tomu člověk vyhne, ale existují různé snadno použitelné "tagované" typy, které v tom trochu dělají pořádek - takže ve výsledku pak vypadá taková funkce např.: Email -> [Email] -> Subject -> [Part] -> Message Takhle to obvykle není v knihovnách, ale ve vlastním kódu tohle strašně pomáhá.
Sémantické označení obyčejného typu String pomáhá nejen v Haskellu. Pak to teprve vypadá jako dokumentace, která nepotřebuje další komentáře.
Jop, napr. typovana ID pouzivam ve Scale u immutable trid k referencim: AccountRef(id: Int).
-
- Haskell+Prolog (vcetne teorie k obema paradigmatum)
To jste teda museli vzit poradne z rychliku. Za 6h x 100min. se nedá probrat ani jeden z těch jazyků, natož teorie k němu.
-
Ještě k těm typům - většina lidí si totiž neuvědomuje, že čím méně je toho v typu specifikováno, tím méně toho ta funkce může dělat. Třeba jediná smysluplná věc, kterou může funkce se signaturou "a -> a" dělat, je ten argument vrátit (nebo se zacyklit, ale to není moc rozumné). Nic víc ta funkce dělat nemůže, protože o "a" nic neví. Funkce "[a] -> Int" pravděpodobně vrátí nějakou funkci délky pole. Funkce "[a] -> [a]" provede nějakou reorganizaci/filtraci na poli, která není závislá na prvcích, ale výhradně na počtu prvků.
Funkce "Eq a => a -> a -> Bool" může být buď "==" nebo "!=", nic jiného nedává smysl. Takže ta signatura fakt funguje jako dost dobrá dokumentace, velmi často ve spojení se jménem bohatě stačí. Osobně mám akorát problém, když přijdu k nové knihovně a nevím jak začít. Ale v momentě, kdy už se nějak orientuju, tak v podstatě ty signatury stačí.
Sice jsem Haskellista, ale takhle pěkně zformulované bych to nedal. +1
-
Sémantické označení obyčejného typu String pomáhá nejen v Haskellu. Pak to teprve vypadá jako dokumentace, která nepotřebuje další komentáře.
;)
-
Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor (http://danielwestheide.com/blog/2012/11/21/the-neophytes-guide-to-scala-part-1-extractors.html). Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.
Ono je obecně škoda, že se v populárních jazycích moc nevidí koncepty z FP. Možná si tvůrci jazyků myslí, že na běžného vývojáře je FP moc složité/abstraktní/matoucí... Přitom takové OOP většina také dost patlá...
Je stejne zajimave, jak dlouho trvalo OOP, nez se prosadilo. Pokud si to pamatuju spravne, tak byl potreba prechod na graficka uzivatelska rozhrani, kde OOP zazarilo, a az pak se opravdu masove zacalo pouzivat. Mozna stojime na podobnem prahu - jak roste pocet jader, ale ne vykon jadra, tak FP pristup zacina byt dost zajimavy.
PS: Je opravdu dost mozne, ze je to pouze zpusobeno pristupem skol, kdy se imperativni pristup uci prvni. A teda prijde me, ze i podstatne lepe, nez treba ten funkcionalni. V imperativnim jsme rovnou zacali patlat v C, u funkcionalniho jsme nejdriv museli prezit a nepochopit (nasprtat se) teorii a az pak, pri reseni projektu, zacit chapat, o cem ze ta teorie asi ze byla.
Já jsem se s haskellem setkal ve škole asi před 10-ti lety a nevzpomínám si, že by ho někdo ze spolužáků začal ihned používat v praxi. Víc než na škole záleží na vyspělosti ekosystému okolo. Ten je dneska úplně jinde. Naopak, dynamické jazyky jako ruby, php a js se nikdy nikde neučily a rozšířily se docela rychle.
No, ja se taky "setkal", ale ve srovnani s imperativnim pristupem, ktery se do nas tlacil vlastne neustale, setkani v ramci poloviny jednoho predmetu bylo opravdu slabe.
stredni (gympl):
- Pascal (nekteri spoluzaci z prumek znali trochu C, dost lidi neznalo nic)
bc:
- C (nekolik predmetu)
- ASM
- C++/Java (na vyber jedno)
- Python (myslim take nekolikrat na psani ukolu)
- cisty stary JavaScript
- Pascal+pseudo kod
mgr:
- C/C++ (nekolik predmetu, na projekty)
- Java/nejaky neznamy jazyk na IS
- 1x jazyk podle vlastniho vyberu (pouzil jsem Scalu)
- Ada+nejaky dalsi paralelni
- Haskell+Prolog (vcetne teorie k obema paradigmatum)
- 2x C#
- Python (zase ukoly, tusim sifrovani)
Asi jsem na neco zapomnel, ale funkcionalni bych si pamatoval. Kdyz to shrneme, tak mame za cele studium 0,5 predmetu venovanemu funkcionalnimu jazyku (jeste teda JavaScript, ale tomu nebyl take venovan cely predmet a FP jako takove se tam snad ani neresilo; navic JS podle nekterych definic ani nespada do funkcionalnich jazyku). Takze ne, nedivim se, ze nikdo z mych spoluzaku nebezel a nezacal pracovat v FP jazyce.
Je mozne, ze na vasi skole jste meli destiky predmetu vyucujici a vyuzivajici FP a funckionalni jazyky. Sice jsem znacne skepticky, ale co. Pokud je tomu opravdu tak, prosim podelte se o jmeno skoly (bych si treba i precetl jake predmety jste meli a tise zavidel).
Měli jsme to podobně. Haskell se probíral jako součást předmětu společně s prologem a scheme. Také jsem si z toho moc neodnesl. V té době jsem to bral spíš jako kuriozitu. Většinu úloh jsem řešil pomocí rekurze, protože jsem neznal základní funkce pro práci s listy. Zápočtovou práci jsem dělal v prologu, z toho jsem si toho odnesl asi nejvíc. V té době jsem se zajímal hlavně o počítačovou grafiku, programování her a nějaké to php. Stále si myslím, že pro řešení některých problémů je imperativní přístup vhodnější. Například inplace quicksort. Dá se taková věc naprogramovat elegantně v haskellu? Nebo některé maticové algoritmy a algoritmy dynamického programování. Ok, dá se to dělat pomocí nějakých komplikovaných konstrukcí s vnořenými foldly. Ale proč? Možná to jsou umělé školní příklady, ale zajímal by mne názor místních haskellistů.
-
Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor (http://danielwestheide.com/blog/2012/11/21/the-neophytes-guide-to-scala-part-1-extractors.html). Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.
Ono je obecně škoda, že se v populárních jazycích moc nevidí koncepty z FP. Možná si tvůrci jazyků myslí, že na běžného vývojáře je FP moc složité/abstraktní/matoucí... Přitom takové OOP většina také dost patlá...
Je stejne zajimave, jak dlouho trvalo OOP, nez se prosadilo. Pokud si to pamatuju spravne, tak byl potreba prechod na graficka uzivatelska rozhrani, kde OOP zazarilo, a az pak se opravdu masove zacalo pouzivat. Mozna stojime na podobnem prahu - jak roste pocet jader, ale ne vykon jadra, tak FP pristup zacina byt dost zajimavy.
PS: Je opravdu dost mozne, ze je to pouze zpusobeno pristupem skol, kdy se imperativni pristup uci prvni. A teda prijde me, ze i podstatne lepe, nez treba ten funkcionalni. V imperativnim jsme rovnou zacali patlat v C, u funkcionalniho jsme nejdriv museli prezit a nepochopit (nasprtat se) teorii a az pak, pri reseni projektu, zacit chapat, o cem ze ta teorie asi ze byla.
Já jsem se s haskellem setkal ve škole asi před 10-ti lety a nevzpomínám si, že by ho někdo ze spolužáků začal ihned používat v praxi. Víc než na škole záleží na vyspělosti ekosystému okolo. Ten je dneska úplně jinde. Naopak, dynamické jazyky jako ruby, php a js se nikdy nikde neučily a rozšířily se docela rychle.
No, ja se taky "setkal", ale ve srovnani s imperativnim pristupem, ktery se do nas tlacil vlastne neustale, setkani v ramci poloviny jednoho predmetu bylo opravdu slabe.
stredni (gympl):
- Pascal (nekteri spoluzaci z prumek znali trochu C, dost lidi neznalo nic)
bc:
- C (nekolik predmetu)
- ASM
- C++/Java (na vyber jedno)
- Python (myslim take nekolikrat na psani ukolu)
- cisty stary JavaScript
- Pascal+pseudo kod
mgr:
- C/C++ (nekolik predmetu, na projekty)
- Java/nejaky neznamy jazyk na IS
- 1x jazyk podle vlastniho vyberu (pouzil jsem Scalu)
- Ada+nejaky dalsi paralelni
- Haskell+Prolog (vcetne teorie k obema paradigmatum)
- 2x C#
- Python (zase ukoly, tusim sifrovani)
Asi jsem na neco zapomnel, ale funkcionalni bych si pamatoval. Kdyz to shrneme, tak mame za cele studium 0,5 predmetu venovanemu funkcionalnimu jazyku (jeste teda JavaScript, ale tomu nebyl take venovan cely predmet a FP jako takove se tam snad ani neresilo; navic JS podle nekterych definic ani nespada do funkcionalnich jazyku). Takze ne, nedivim se, ze nikdo z mych spoluzaku nebezel a nezacal pracovat v FP jazyce.
Je mozne, ze na vasi skole jste meli destiky predmetu vyucujici a vyuzivajici FP a funckionalni jazyky. Sice jsem znacne skepticky, ale co. Pokud je tomu opravdu tak, prosim podelte se o jmeno skoly (bych si treba i precetl jake predmety jste meli a tise zavidel).
Měli jsme to podobně. Haskell se probíral jako součást předmětu společně s prologem a scheme. Také jsem si z toho moc neodnesl. V té době jsem to bral spíš jako kuriozitu. Většinu úloh jsem řešil pomocí rekurze, protože jsem neznal základní funkce pro práci s listy. Zápočtovou práci jsem dělal v prologu, z toho jsem si toho odnesl asi nejvíc. V té době jsem se zajímal hlavně o počítačovou grafiku, programování her a nějaké to php. Stále si myslím, že pro řešení některých problémů je imperativní přístup vhodnější. Například inplace quicksort. Dá se taková věc naprogramovat elegantně v haskellu? Nebo některé maticové algoritmy a algoritmy dynamického programování. Ok, dá se to dělat pomocí nějakých komplikovaných konstrukcí s vnořenými foldly. Ale proč? Možná to jsou umělé školní příklady, ale zajímal by mne názor místních haskellistů.
Haskellista se hlásí.
Samozřejmě, FP není na všechno. Není třeba na AI. Neuronová síť potřebuje pro rychlí běh rychlou implementaci matic s rychlím random přístupem. Jde to udělat s listy, ale bude to pomalí až běda. Jde to udělat i s poli, pak to bude ale díky persistenci pomalí ještě hůř. A nebo můžeme tu čistotu poslat kompletně do zadeke a použít mutable arrays ... ale proč potom používat Haskell žejo ...
-
Například inplace quicksort. Dá se taková věc naprogramovat elegantně v haskellu? Nebo některé maticové algoritmy a algoritmy dynamického programování. Ok, dá se to dělat pomocí nějakých komplikovaných konstrukcí s vnořenými foldly. Ale proč? Možná to jsou umělé školní příklady, ale zajímal by mne názor místních haskellistů.
Tak logicky algoritmy optimalizované na to využít mutabilitu samozřejmě v non-mutable jazyce fungovat dobře nebudou. V mnoha případech jde použít jiný algoritmus - což někdy vede překvapivě i k přehlednějšímu řešení (navíc s "Fusion" ten výsledek může být i slušně rychlý), ale je fakt, že občas něco opravdu jinak rozumně řešit nejde. V Haskellu je pro tyto účely tzv. ST monad, který de-fakto umožňuje provádět mutable programování v "izolaci" - tzn. ta mutabilita je uvnitř a neuteče nikam ven. Mně připadá, že ale výsledný kód má do přehlednosti dost daleko - je to takové ... imperativní ...
-
Třeba jediná smysluplná věc, kterou může funkce se signaturou "a -> a" dělat, je ten argument vrátit (nebo se zacyklit, ale to není moc rozumné). Nic víc ta funkce dělat nemůže, protože o "a" nic neví.
To obecně nemusí být pravda - v některých jazycích například mohu napsat funkci typu a -> a:
normalizuj(x) = x.toLowerCase, pokud je x řetězec,
normalizuj(x) = x jinak
-
Pattern matching treba ve Scale je hodne silny, defaultne umi i regexpy, ale lze si dodefinovat libovolny extractor (http://danielwestheide.com/blog/2012/11/21/the-neophytes-guide-to-scala-part-1-extractors.html). Celkem skoda, ze se podobne veci v popularnich jazycich prilis nevidi.
Ono je obecně škoda, že se v populárních jazycích moc nevidí koncepty z FP. Možná si tvůrci jazyků myslí, že na běžného vývojáře je FP moc složité/abstraktní/matoucí... Přitom takové OOP většina také dost patlá...
Je stejne zajimave, jak dlouho trvalo OOP, nez se prosadilo. Pokud si to pamatuju spravne, tak byl potreba prechod na graficka uzivatelska rozhrani, kde OOP zazarilo, a az pak se opravdu masove zacalo pouzivat. Mozna stojime na podobnem prahu - jak roste pocet jader, ale ne vykon jadra, tak FP pristup zacina byt dost zajimavy.
PS: Je opravdu dost mozne, ze je to pouze zpusobeno pristupem skol, kdy se imperativni pristup uci prvni. A teda prijde me, ze i podstatne lepe, nez treba ten funkcionalni. V imperativnim jsme rovnou zacali patlat v C, u funkcionalniho jsme nejdriv museli prezit a nepochopit (nasprtat se) teorii a az pak, pri reseni projektu, zacit chapat, o cem ze ta teorie asi ze byla.
Já jsem se s haskellem setkal ve škole asi před 10-ti lety a nevzpomínám si, že by ho někdo ze spolužáků začal ihned používat v praxi. Víc než na škole záleží na vyspělosti ekosystému okolo. Ten je dneska úplně jinde. Naopak, dynamické jazyky jako ruby, php a js se nikdy nikde neučily a rozšířily se docela rychle.
No, ja se taky "setkal", ale ve srovnani s imperativnim pristupem, ktery se do nas tlacil vlastne neustale, setkani v ramci poloviny jednoho predmetu bylo opravdu slabe.
stredni (gympl):
- Pascal (nekteri spoluzaci z prumek znali trochu C, dost lidi neznalo nic)
bc:
- C (nekolik predmetu)
- ASM
- C++/Java (na vyber jedno)
- Python (myslim take nekolikrat na psani ukolu)
- cisty stary JavaScript
- Pascal+pseudo kod
mgr:
- C/C++ (nekolik predmetu, na projekty)
- Java/nejaky neznamy jazyk na IS
- 1x jazyk podle vlastniho vyberu (pouzil jsem Scalu)
- Ada+nejaky dalsi paralelni
- Haskell+Prolog (vcetne teorie k obema paradigmatum)
- 2x C#
- Python (zase ukoly, tusim sifrovani)
Asi jsem na neco zapomnel, ale funkcionalni bych si pamatoval. Kdyz to shrneme, tak mame za cele studium 0,5 predmetu venovanemu funkcionalnimu jazyku (jeste teda JavaScript, ale tomu nebyl take venovan cely predmet a FP jako takove se tam snad ani neresilo; navic JS podle nekterych definic ani nespada do funkcionalnich jazyku). Takze ne, nedivim se, ze nikdo z mych spoluzaku nebezel a nezacal pracovat v FP jazyce.
Je mozne, ze na vasi skole jste meli destiky predmetu vyucujici a vyuzivajici FP a funckionalni jazyky. Sice jsem znacne skepticky, ale co. Pokud je tomu opravdu tak, prosim podelte se o jmeno skoly (bych si treba i precetl jake predmety jste meli a tise zavidel).
Mít Prolog a FP v jednom předmětu je dost blbý nápad. Jinak FP je asi jeden z mála konceptů, co by se měl učit začínaje od teorie, protože z fleku se v tom rozumně psát fakt nedá (na rozdíl třeba i od toho Prologu, jenž je taky dost daleko od mainstreamu).
-
Většinu úloh jsem řešil pomocí rekurze, protože jsem neznal základní funkce pro práci s listy.
Ne že bych je vůbec neznal, ale v testech a u tabule jsem se snažil používat jen omezenou podmnožinu jazyka, abych omezil riziko chyby (testy i zkouška se psaly na papír).
-
Jsem jeste pozapomnel na VHDL v par (2?) predmetech, coz teda funckionalni stale moc neni (v jednom jsme to delali na urovni hradel, v dalsim tim vyssim pristupem).
Co se tak divam, tak ten JavaScript se spise k FP neradi, prestoze ma nektere FP rysy. Dobre to shrnul treba tady (http://stackoverflow.com/a/3962690/1017211) na SO.
- Haskell+Prolog (vcetne teorie k obema paradigmatum)
To jste teda museli vzit poradne z rychliku. Za 6h x 100min. se nedá probrat ani jeden z těch jazyků, natož teorie k němu.
Jn, presne jak pises. Prednasky k Haskellu byly hlavne lambda kalkul a pocitani s nim (napr. reprezentace cisel, operace nad nimi atp.; coz ale primo v Haskellu jaksi nepouzijes). Pritom si treba ani moc nepamatuju, ze by prednasejici vubec resil nejake monady. Na cvikach se to do nas snazili nejak nalit, kdyz zjistili, ze to nikdo nechape, ale bylo malo casu a musely se resit predepsane prakticke priklady. Ty prekvapive s vyucovanou teorii nemeli nic moc spolecneho (asi jsme to v tom jen nevideli, nevim, protoze snad ta teorie nebyla nanic?). Treba ty monady a do notaci jsem pochopil az mnohem pozdeji samostudiem pri praci na projektu. Jak jsem byl nastvany na prednasejiciho, ze takovou "nepodstatnou" vec mi zamlcel.
Jako chapu, ze ciste FP neni moc popularni. Ale vzhledem k tomu, jak se mu uspesne dari infiltrovat popularni jazyky, tak si myslim, ze minimalne jeden predmet v bakalari by si to zaslouzilo.
Rozhodne nerazim nazor "Vsude ciste FP!". Treba prave ta Scala neni ani omylem cista (Haskellisti se na ni myslim celkem casto divaji shora) a FP se na nektere veci hodi mnohem vice, na jine naopak vice vynika imperativni pristup a OOP.
-
Třeba jediná smysluplná věc, kterou může funkce se signaturou "a -> a" dělat, je ten argument vrátit (nebo se zacyklit, ale to není moc rozumné). Nic víc ta funkce dělat nemůže, protože o "a" nic neví.
To obecně nemusí být pravda - v některých jazycích například mohu napsat funkci typu a -> a:
normalizuj(x) = x.toLowerCase, pokud je x řetězec,
normalizuj(x) = x jinak
Otázka byla, proč haskellistům v zásadě stačí jako dokumentace jenom signatury funkcí (to trošku přeháním, ale faktem je, že tohle je častá výtka) - a ten důvod právě je, že v Haskellu tohle neuděláte. Signatura prostě říká, že ta funkce neví, co je "a" za typ, tak to ta funkce neví. Tohle by třeba v haskellu mělo signaturu:
Dynamic -> Dynamic
A když se na ni člověk podívá, ví, že o té funkci nemůže říct téměř nic.
-
Třeba jediná smysluplná věc, kterou může funkce se signaturou "a -> a" dělat, je ten argument vrátit (nebo se zacyklit, ale to není moc rozumné). Nic víc ta funkce dělat nemůže, protože o "a" nic neví.
To obecně nemusí být pravda - v některých jazycích například mohu napsat funkci typu a -> a:
normalizuj(x) = x.toLowerCase, pokud je x řetězec,
normalizuj(x) = x jinak
Otázka byla, proč haskellistům v zásadě stačí jako dokumentace jenom signatury funkcí (to trošku přeháním, ale faktem je, že tohle je častá výtka) - a ten důvod právě je, že v Haskellu tohle neuděláte. Signatura prostě říká, že ta funkce neví, co je "a" za typ, tak to ta funkce neví. Tohle by třeba v haskellu mělo signaturu:
Dynamic -> Dynamic
A když se na ni člověk podívá, ví, že o té funkci nemůže říct téměř nic.
I tak existuje v Haskellu 3. možnost - někdy vrátit totéž a někdy se zacyklit (pomocí seq).
-
Třeba jediná smysluplná věc, kterou může funkce se signaturou "a -> a" dělat, je ten argument vrátit (nebo se zacyklit, ale to není moc rozumné). Nic víc ta funkce dělat nemůže, protože o "a" nic neví.
To obecně nemusí být pravda - v některých jazycích například mohu napsat funkci typu a -> a:
normalizuj(x) = x.toLowerCase, pokud je x řetězec,
normalizuj(x) = x jinak
Otázka byla, proč haskellistům v zásadě stačí jako dokumentace jenom signatury funkcí (to trošku přeháním, ale faktem je, že tohle je častá výtka) - a ten důvod právě je, že v Haskellu tohle neuděláte. Signatura prostě říká, že ta funkce neví, co je "a" za typ, tak to ta funkce neví. Tohle by třeba v haskellu mělo signaturu:
Dynamic -> Dynamic
A když se na ni člověk podívá, ví, že o té funkci nemůže říct téměř nic.
I tak existuje v Haskellu 3. možnost - někdy vrátit totéž a někdy se zacyklit (pomocí seq).
Lepší by asi bylo říci, že ta 3. možnost je vyhodnotit do WHNF.
-
I tak existuje v Haskellu 3. možnost - někdy vrátit totéž a někdy se zacyklit (pomocí seq).
Jenže ta funkce nemá žádná vstupní data do podmínky "mám se zacyklit?". Takže nemůže.
-
Lepší by asi bylo říci, že ta 3. možnost je vyhodnotit do WHNF.
Dobře, tak seq je úlitba k tomu, aby se ten líný jazyk dal nějak efektivně používat :)
-
I tak existuje v Haskellu 3. možnost - někdy vrátit totéž a někdy se zacyklit (pomocí seq).
Jenže ta funkce nemá žádná vstupní data do podmínky "mám se zacyklit?". Takže nemůže.
Máte pravdu, v případě identity to seq nepokazí - moje chyba (pokazil by to třeba deepseq, jenže to už by v typové signatuře bylo NFData). U složitějších funkcí - například u funkce filter to již pokazit jde. Bez seq by typ filter : (a -> Bool) -> [a] -> [a] implikoval vlastnost
filter p (map f list) = map f (filter (p . f) list)
pro každé p, f, list a klasicky definovaný map. Tato vlastnost by platila bez ohledu na to, jak je filter definovaný (stačilo by, že má daný typ). Se seq již tato vlastnost nemusí platit.
-
Tak fajn, kdyz si tu konecne prestali honit triko haskellisti a jim podobna havet, lze snad konecne odpovedet na polozeny dotaz.
Python ma budoucnost, je to jazyk jednoduchy, snadno pochopitelny, prakticky a pragmaticky, ktery ma sirokou oblast vhodneho uplatneni od psani pokrocilejsich skriptu, pres psani prototypu a webovych aplikaci az po vyvoj gui aplikaci. Jeho obliba roste, coz se projevuje mimo jine tim, ze nahradil Javu jako prvni vyukovy jazyk, ktera kdysi nahradila Pascal. Take se da vyuzit ke skriptovani ruznych aplikaci, treba textovych editoru jako je vim nebo gedit, grafickych editoru jako je gimp, inkscape nebo blender nebo ruzne kancelarske baliky.
-
kdyz si tu konecne prestali honit triko haskellisti a jim podobna havet, lze snad konecne odpovedet na polozeny dotaz.
+1
-
Python ma budoucnost, je to jazyk jednoduchy, snadno pochopitelny, prakticky a pragmaticky, ktery ma sirokou oblast vhodneho uplatneni od psani pokrocilejsich skriptu, pres psani prototypu a webovych aplikaci az po vyvoj gui aplikaci. Jeho obliba roste, coz se projevuje mimo jine tim, ze nahradil Javu jako prvni vyukovy jazyk, ktera kdysi nahradila Pascal. Take se da vyuzit ke skriptovani ruznych aplikaci, treba textovych editoru jako je vim nebo gedit, grafickych editoru jako je gimp, inkscape nebo blender nebo ruzne kancelarske baliky.
Mohu-li si vybrat (což obvykle nemohu) tak dávám přednost jazyku Lua. Umí prakticky to samé co Python, je menší, rychlejší, snáze se zakomponovává do C aplikací. S výsledným kódem se dá imho mnohem lépe pracovat. A subjektivně mi přijde i taková jakože čistěji navržená.
-
Python ma budoucnost, je to jazyk jednoduchy, snadno pochopitelny, prakticky a pragmaticky, ktery ma sirokou oblast vhodneho uplatneni od psani pokrocilejsich skriptu, pres psani prototypu a webovych aplikaci az po vyvoj gui aplikaci. Jeho obliba roste, coz se projevuje mimo jine tim, ze nahradil Javu jako prvni vyukovy jazyk, ktera kdysi nahradila Pascal. Take se da vyuzit ke skriptovani ruznych aplikaci, treba textovych editoru jako je vim nebo gedit, grafickych editoru jako je gimp, inkscape nebo blender nebo ruzne kancelarske baliky.
Mohu-li si vybrat (což obvykle nemohu) tak dávám přednost jazyku Lua. Umí prakticky to samé co Python, je menší, rychlejší, snáze se zakomponovává do C aplikací. S výsledným kódem se dá imho mnohem lépe pracovat. A subjektivně mi přijde i taková jakože čistěji navržená.
Račte prosím laskavě navnímat že svět je mnohem barvitější, než si představujete. A že programuje spousta NEprogramátorů (klasicky většina vědců, kteří nějak umí programovat a k tomu umí svůj obor) a Python nachází řadu uplatnění právě v této branži - třeba distribuce Annaconda. Že se někdo u nich z této sorty lidí bude učit Javu a nebo Lua nedává žádný smysl.
-
Račte prosím laskavě navnímat že svět je mnohem barvitější, než si představujete. A že programuje spousta NEprogramátorů (klasicky většina vědců, kteří nějak umí programovat a k tomu umí svůj obor) a Python nachází řadu uplatnění právě v této branži - třeba distribuce Annaconda. Že se někdo u nich z této sorty lidí bude učit Javu a nebo Lua nedává žádný smysl.
Dříve vědci ke svým výpočtům používali zejména jazyk Fortran. Ostatně mnozí ho používají dodnes, neboť stále je z dostupných jazyků nejvýkonnější. Modernějšími jazyky pro vědce jsou například Matlab, Rko nebo právě Python.
-
Dříve vědci ke svým výpočtům používali zejména jazyk Fortran. Ostatně mnozí ho používají dodnes, neboť stále je z dostupných jazyků nejvýkonnější. Modernějšími jazyky pro vědce jsou například Matlab, Rko nebo právě Python.
U vědců python dost válcuje všechno ostatní, je to univerzální jazyk první volby. V kombinaci se SciPy moc nemá konkurenci: https://talkpython.fm/episodes/show/29/python-at-the-large-hadron-collider-and-cern
-
Dříve vědci ke svým výpočtům používali zejména jazyk Fortran. Ostatně mnozí ho používají dodnes, neboť stále je z dostupných jazyků nejvýkonnější. Modernějšími jazyky pro vědce jsou například Matlab, Rko nebo právě Python.
U vědců python dost válcuje všechno ostatní, je to univerzální jazyk první volby. V kombinaci se SciPy moc nemá konkurenci: https://talkpython.fm/episodes/show/29/python-at-the-large-hadron-collider-and-cern
Mam dojem, ze ma konkurenci mohutnou a to je Rko. (Ze je mezi temi jazyky propastny rozdil v kvalite asi nema potrebu zduraznovat. Ale bez ohledu na to, jak je Rko zprasene, tak se pouziva hojne.)
-
Mam dojem, ze ma konkurenci mohutnou a to je Rko. (Ze je mezi temi jazyky propastny rozdil v kvalite asi nema potrebu zduraznovat. Ale bez ohledu na to, jak je Rko zprasene, tak se pouziva hojne.)
Rko se používá hlavně kvůli množství specializovaných knihoven, kterýmu se Python ani se SciPy ani neblíží. Že Python "nemá konkurenci" je spíš zbožné přání než realita. Navíc vědecké použití Pythonu není moc ke cti Pythonu, protože ten tam slouží jenom jako tenoučká obálka. Počítat v něm samém by se nedalo vůbec. Používá se, protože se snadno učí a je dostatečně flexibilní, aby se na ty výpočty dal jakžtakž ohnout (žádná velká sláva, ale jde to).
Ještě taky uvidíme, jestli se chytne Julia, ta by mohla se situací dost zatočit.
-
Nesmysl, automaticke testy slouzi k tomu, aby se peridicky re-testoval kod pred kazdym commitem, tedy aby byli testeri usetreni opici prace a mohli se soustredit na dulezitejsi vec. Maven ma test phase primo ve svem build lifecyclu.
Co jsem videl vyvoj v realnych firmach, kde nejsou uplni matlaci, tak vesmes plati:
- Kod je v GITu a kazdy si hraje na svem forku
- lokalni buildy ridi Maven, ktery spousit Unit testy, Mock integracni testy (napr. Mockito), pripadne SeleniumHQ na E2E testy. Maven zaroven automaticky hlida unit test coverage, kazdy koder musi plne pokryt svuj kod testy, pripadne zduvodnit, proc to nejde.
- kdyz to lokalne proslo, muze koder mergovat do hlavniho branche GITu
- nad hlavnim branchem GITu se v Bamboo spousti nightbuildy (opet s hromadou testu), kdyz to spadne, Bamboo praskne, kdo to zku*rvil.
- jednou za cas se udela release, main branch se vystavi na lokalnim Nexusu jako maven artefact, vichni si updatujou pom.xml na tento novy artefarct a jede se dal.
Rozumny vyvoj bez automatickeho testovani je naprosty nesmysl.
Do kamene tesat.
-
Mohu-li si vybrat (což obvykle nemohu) tak dávám přednost jazyku Lua. Umí prakticky to samé co Python, je menší, rychlejší, snáze se zakomponovává do C aplikací. S výsledným kódem se dá imho mnohem lépe pracovat. A subjektivně mi přijde i taková jakože čistěji navržená.
Račte prosím laskavě navnímat že svět je mnohem barvitější, než si představujete. A že programuje spousta NEprogramátorů (klasicky většina vědců, kteří nějak umí programovat a k tomu umí svůj obor) a Python nachází řadu uplatnění právě v této branži - třeba distribuce Annaconda. Že se někdo u nich z této sorty lidí bude učit Javu a nebo Lua nedává žádný smysl.
Nápodobně.
Co byste mi chtěl vytknout? Že jsem dal přednost něčemu jinému před Pythonem? Že jsem napsal svou zkušenost?
Python se používá protože efekt sněhové koule.
Já jsem začal Luu používat protože si myslím, že tím koncákům neprogramátorům usnadním život. Jestli se naučí Luu nebo Python je pro ně vcelku jedno. Zato je pro ně důležité, zda ten jazyk mohou používat pro práci s požadovanou funkcionalitou. A tvrdím, že napojovat existující C knihovny je v Lue výrazně snazší než v Pythonu.
-
Ještě taky uvidíme, jestli se chytne Julia, ta by mohla se situací dost zatočit.
Nemyslim ze z toho nieco bude, pozeral som na to pred par rokmi ked som o tom prvykrat cital.
Furt je to vo verzii 0.x.y. Zda sa ze je to experimentalny jazyk pouzivany akurat na universite kde vznikol.
-
Furt je to vo verzii 0.x.y. Zda sa ze je to experimentalny jazyk pouzivany akurat na universite kde vznikol.
To byly na začátku skoro všechny jazyky :)
-
Mohu-li si vybrat (což obvykle nemohu) tak dávám přednost jazyku Lua. Umí prakticky to samé co Python, je menší, rychlejší, snáze se zakomponovává do C aplikací. S výsledným kódem se dá imho mnohem lépe pracovat. A subjektivně mi přijde i taková jakože čistěji navržená.
Račte prosím laskavě navnímat že svět je mnohem barvitější, než si představujete. A že programuje spousta NEprogramátorů (klasicky většina vědců, kteří nějak umí programovat a k tomu umí svůj obor) a Python nachází řadu uplatnění právě v této branži - třeba distribuce Annaconda. Že se někdo u nich z této sorty lidí bude učit Javu a nebo Lua nedává žádný smysl.
Nápodobně.
Co byste mi chtěl vytknout? Že jsem dal přednost něčemu jinému před Pythonem? Že jsem napsal svou zkušenost?
Python se používá protože efekt sněhové koule.
Já jsem začal Luu používat protože si myslím, že tím koncákům neprogramátorům usnadním život. Jestli se naučí Luu nebo Python je pro ně vcelku jedno. Zato je pro ně důležité, zda ten jazyk mohou používat pro práci s požadovanou funkcionalitou. A tvrdím, že napojovat existující C knihovny je v Lue výrazně snazší než v Pythonu.
Já Vám nic nevytýkám, pouze (na Vašem příkladě, nic osobního - mohl jsem si vybrat samozřejmě někoho jiného...) konstatuji, jak je tato diskuse šíleně omezená svým rozhledem (obecných programátorů).
A jestli Lua a nebo Python není jedno ani omylem, protože zaměstnavatel, zvyky v daném oboru, práce v týmu, zastupitelnost lidí, atd. Pokud se všeobecně v oboru na půlce planety široce používá třeba Python, tak nemá smysl se učit cokoliv dalšího, protože je to ztráta času a programovací jazyk je prostředek, nikoliv cíl. V tom čase se dá dělat X užitečnějších neprogramátorských věcí.
-
A jestli Lua a nebo Python není jedno ani omylem, protože zaměstnavatel, zvyky v daném oboru, práce v týmu, zastupitelnost lidí, atd. Pokud se všeobecně v oboru na půlce planety široce používá třeba Python, tak nemá smysl se učit cokoliv dalšího, protože je to ztráta času a programovací jazyk je prostředek, nikoliv cíl. V tom čase se dá dělat X užitečnějších neprogramátorských věcí.
To jsem ve svém příspěvku zohlednil. Takže?
Tím, že je to jedno jsem myslel scénář, kdy si nějaký uživatel mého programu potřebuje nascriptovat nějakou funkci. Tam to, dle mého opravdu je jedno. Protože rozdíl mezi Luou a Pythonem je v tomto marginální.
-
A jestli Lua a nebo Python není jedno ani omylem, protože zaměstnavatel, zvyky v daném oboru, práce v týmu, zastupitelnost lidí, atd. Pokud se všeobecně v oboru na půlce planety široce používá třeba Python, tak nemá smysl se učit cokoliv dalšího, protože je to ztráta času a programovací jazyk je prostředek, nikoliv cíl. V tom čase se dá dělat X užitečnějších neprogramátorských věcí.
To jsem ve svém příspěvku zohlednil. Takže?
Takže nic, moje technická poznámka právě skončila. ;)
-
A jestli Lua a nebo Python není jedno ani omylem, protože zaměstnavatel, zvyky v daném oboru, práce v týmu, zastupitelnost lidí, atd. Pokud se všeobecně v oboru na půlce planety široce používá třeba Python, tak nemá smysl se učit cokoliv dalšího, protože je to ztráta času a programovací jazyk je prostředek, nikoliv cíl. V tom čase se dá dělat X užitečnějších neprogramátorských věcí.
Pokud by takhle uvažovali všichni, dodneska programujeme ve Fortranu a Cobolu.
-
A jestli Lua a nebo Python není jedno ani omylem, protože zaměstnavatel, zvyky v daném oboru, práce v týmu, zastupitelnost lidí, atd. Pokud se všeobecně v oboru na půlce planety široce používá třeba Python, tak nemá smysl se učit cokoliv dalšího, protože je to ztráta času a programovací jazyk je prostředek, nikoliv cíl. V tom čase se dá dělat X užitečnějších neprogramátorských věcí.
Pokud by takhle uvažovali všichni, dodneska programujeme ve Fortranu a Cobolu.
Pro Vaši ctěnou představu, poslední program ve Fortranu jsem napsal asi před 25 lety.
-
Pro Vaši ctěnou představu, poslední program ve Fortranu jsem napsal asi před 25 lety.
Hmm, dobře. Dík za informaci.
-
Co byste mi chtěl vytknout? Že jsem dal přednost něčemu jinému před Pythonem? Že jsem napsal svou zkušenost?
Ja bych vam vytknul offtopic. Jak dotaz, zda ma python budoucnost, souvisi s vylevem, cemu davate prednost kdyz muzete, coz vetsinou stejne nemuzete.
-
Jak je vlastně na tom na Python na trhu? Co jsem viděl, pár firem dělá velký projekty na Pythonu, ale mnohem větší poptávka je po Java/.NET/PHP (koukněte např. na jobs.cz a startupjobs.cz). Python mi přijde, že se používá spíš pro nějaký systémový programování, nebo pro bastlení pro zábavu, ale mainstreamovej jazyk to u firem neni.
-
Jak je vlastně na tom na Python na trhu? Co jsem viděl, pár firem dělá velký projekty na Pythonu, ale mnohem větší poptávka je po Java/.NET/PHP (koukněte např. na jobs.cz a startupjobs.cz). Python mi přijde, že se používá spíš pro nějaký systémový programování, nebo pro bastlení pro zábavu, ale mainstreamovej jazyk to u firem neni.
Python je na trhu velmi dobře. Python developerů je málo a poptávka po nich je značná, zejména u firem ve finančním sektoru.
Umíš python? Firmy ti utrhnou ruce.
-
ROFL. Trhání rukou u Pythonu :D Finanční sektor :D Jasný, tak asi žijeme v jiném světě. Python je fajn na malé skriptíky a jednoduché menší aplikace. V bankách fakt moc Python nefrčí a když jo, tak na jednoúčelový malý aplikace. Finančně je to samozřejmě dost jinde než u Javy, ale to je jasné, že skriptování a vývoj je náročností jinde.
-
a poptávka po nich je značná
Jakými kanály? Veřejně asi ne, protože inzerátů je málo.
-
a poptávka po nich je značná
Jakými kanály? Veřejně asi ne, protože inzerátů je málo.
Linkedin, často přímo na e-mail (kde sakra vzali tu adresu?). Týdně 1-2 nabídky na Python developera do USA/UK/Irsko/Německo/Polsko a k tomu 1-2x měsíčně do tuzemska. Polovina z toho je Django, zbytek financial, cloud apod.
-
Za kolik do ČR? Za kolik třeba do Londýna? Protože psát nesmysly jak je Python cool, když ti píšou HR dementi, není úplně ono. Kolik pohovorů jsi s ním měl a dostal nabídku?
Django je na menší věci, ale věřim tomu, že ho sem tam někdo chce. To je i v ČR.
Pokud bys chtěl vidět trhání rukou, tak si dej někam inzerát jako Java developer.
-
Za kolik do ČR? Za kolik třeba do Londýna? Protože psát nesmysly jak je Python cool, když ti píšou HR dementi, není úplně ono. Kolik pohovorů jsi s ním měl a dostal nabídku?
Django je na menší věci, ale věřim tomu, že ho sem tam někdo chce. To je i v ČR.
Pokud bys chtěl vidět trhání rukou, tak si dej někam inzerát jako Java developer.
Django je na malé věci heh, proč se k tomu vůbec vyjadřuješ když o tom očividně ho*no víš?!
-
Možná z hlediska Pythonu je to větší. Jinak je to menší framework, který sedí hezky ke skriptování, ale nenabízí moc flexibilitu a celkově to není na velké věci.
-
Možná z hlediska Pythonu je to větší. Jinak je to menší framework, který sedí hezky ke skriptování, ale nenabízí moc flexibilitu a celkově to není na velké věci.
Psal jsi v něm někdy něco, že tohle tvrdíš?
Koukni se schválně jaké velké weby využívají Django, možná se budeš divit.
Stran nabídek u nás, spoustu jich je například od seznamu, to asi samo o sobě říká stran toho jestli má python budoucnost (v tuzemsku) a jak moc velké projkety jsou v něm napsané. Weby se daj psát v čemkoliv a ve výsledku jako uživatel rozdíl nepoznáš i stran rychlosti...
-
Dyť je to malinký. Samozřejmě jsem v něm chvíli dělal. Pokud se podíváš na EE, tak rovnou v základu máš takových věcí, že nějaké hraní s Pythonem pro tebe bude úplně zbytečné. A pak máš i další knihovny.
Jak spousta? Když jsem něco hledal, tak 80 tisíc na HPP bylo jako bych chtěl firemní Mercedes a asistenktu na kouření. S Javou tohle dostaneš ani nikdo nemrkne okem. V Seznamu jsou lemplové za pár korun, takže tam asi budou mít nedostatek lidí obecně :D
-
Dyť je to malinký. Samozřejmě jsem v něm chvíli dělal. Pokud se podíváš na EE, tak rovnou v základu máš takových věcí, že nějaké hraní s Pythonem pro tebe bude úplně zbytečné. A pak máš i další knihovny.
Jak spousta? Když jsem něco hledal, tak 80 tisíc na HPP bylo jako bych chtěl firemní Mercedes a asistenktu na kouření. S Javou tohle dostaneš ani nikdo nemrkne okem. V Seznamu jsou lemplové za pár korun, takže tam asi budou mít nedostatek lidí obecně :D
Které věci má EE navíc?
-
podporu vice vlaken ?
-
podporu vice vlaken ?
K čemu ji ve webových aplikacích používáte?
-
podporu vice vlaken ?
Podporou více vláken bych se moc neoháněl, to je otázka architektury aplikace. Není problém spouštět více vláken aplikace v Pythonu nebo node.js, v hrubém součtu to pak bývá často rychlejší než ta Java a rozhodně lépe škálovatelné. A když už se z výkonostních důvodů migruje z Ruby/Pythonu/node.js na něco jiného, Java to rozhodně není. Zpravidla je to Go.
-
K čemu ji ve webových aplikacích používáte?
Webová aplikace je přece nejtypičtější příklad vícevláknové aplikace. Pokud se teda situace neřeší obezličkou s poolem oddělených interpreterů, což není žádná ctnost, ale nemotorný způsob, jak obejít neschopnost jazyka, a vede to ke zbytečným komplikacím.
-
v hrubém součtu to pak bývá často rychlejší
A málem bych zapomněl na tohle, to taky stojí za komentář: NE, python NENÍ rychlý. Je to naopak jeden z nejpomalejších jazyků. Pokud někde dosahuje rychlosti, tak jenom díky tomu, že se z Pythonu skočí do céčka. Což by AFAIK v Javě šlo taky, ale nejspíš (?) se to tolik nepoužívá, protože to není zas takový rozdíl jako u Pythonu, který je sám o sobě pomalý jako prase.
-
v hrubém součtu to pak bývá často rychlejší
A málem bych zapomněl na tohle, to taky stojí za komentář: NE, python NENÍ rychlý. Je to naopak jeden z nejpomalejších jazyků. Pokud někde dosahuje rychlosti, tak jenom díky tomu, že se z Pythonu skočí do céčka. Což by AFAIK v Javě šlo taky, ale nejspíš (?) se to tolik nepoužívá, protože to není zas takový rozdíl jako u Pythonu, který je sám o sobě pomalý jako prase.
Mě jednou v lese honil divočák a moc pomalé mi to prase nepřišlo. Ale chápu, co chceš říct ;)
-
Ach jo, zase jsem klikl na "změnit" místo na citovat :(
Podporou více vláken bych se moc neoháněl, to je otázka architektury aplikace.
Ještě před tím je to ale otázka toho, jestli daný jazyk vůbec poskytuje potřebná primitiva.
Není problém spouštět více vláken aplikace v Pythonu nebo node.js, v hrubém součtu to pak bývá často rychlejší než ta Java a rozhodně lépe škálovatelné.
No tak to teda je problém, protože v Pythonu více vláken pouštět *nejde*. Prostě NEJDE, snad všichni víme, co je to GIL, ne?! To, že se udělá nějaké API, které vypadá jakobych měl víc vláken, neznamená, že víc vláken skutečně mám a že jsou dobře využita.
Škálovatelné?! Python není škálovatelný VŮBEC. Spuštění několika oddělených interpreterů není škálování!
-
K čemu ji ve webových aplikacích používáte?
Webová aplikace je přece nejtypičtější příklad vícevláknové aplikace. Pokud se teda situace neřeší obezličkou s poolem oddělených interpreterů, což není žádná ctnost, ale nemotorný způsob, jak obejít neschopnost jazyka, a vede to ke zbytečným komplikacím.
To je pravda, ale pro obyčejné CRUD aplikace to bohatě stačí. Tam stačí i PHP. Asi jsem lopata, ale vlákna jsem nikdy nepotřeboval.
-
v hrubém součtu to pak bývá často rychlejší
A málem bych zapomněl na tohle, to taky stojí za komentář: NE, python NENÍ rychlý. Je to naopak jeden z nejpomalejších jazyků. Pokud někde dosahuje rychlosti, tak jenom díky tomu, že se z Pythonu skočí do céčka. Což by AFAIK v Javě šlo taky, ale nejspíš (?) se to tolik nepoužívá, protože to není zas takový rozdíl jako u Pythonu, který je sám o sobě pomalý jako prase.
Mě jednou v lese honil divočák a moc pomalé mi to prase nepřišlo. Ale chápu, co chceš říct ;)
Nám jednou uteklo domácí prase. Je také docela rychlé.
-
To je pravda, ale pro obyčejné CRUD aplikace to bohatě stačí. Tam stačí i PHP. Asi jsem lopata, ale vlákna jsem nikdy nepotřeboval.
No jistě, pokud mám aplikaci, která nedělá nic jiného než že na dotaz do šablony vkládá údaje z databáze, tak to "stačí". Sice se kvůli tomu musí vymýšlet narovnáváky na ohýbáky jako třeba FCGI, ale jinak je to "úplně v pohodě". Jo akorát tedy ty narovnáváky něco občas rozbijí. Ajo a taky se vlastně na ně musí spešl myslet, když se tam dává proxyna. Ale jinak v pohodě. Jo a taky vlastně takhle vůbec nejdou dělat moderní aplikace. Ale to nevadí. My si vystačíme s tím, že PHP do nějakého HTML vyprdne něco z MySQL.
Však když někdo nezná nic jinýho než kladivo, taky jím "úplně v pohodě" i spraví televizi :)
-
To je pravda, ale pro obyčejné CRUD aplikace to bohatě stačí. Tam stačí i PHP. Asi jsem lopata, ale vlákna jsem nikdy nepotřeboval.
No jistě, pokud mám aplikaci, která nedělá nic jiného než že na dotaz do šablony vkládá údaje z databáze, tak to "stačí". Sice se kvůli tomu musí vymýšlet narovnáváky na ohýbáky jako třeba FCGI, ale jinak je to "úplně v pohodě". Jo akorát tedy ty narovnáváky něco občas rozbijí. Ajo a taky se vlastně na ně musí spešl myslet, když se tam dává proxyna. Ale jinak v pohodě. Jo a taky vlastně takhle vůbec nejdou dělat moderní aplikace. Ale to nevadí. My si vystačíme s tím, že PHP do nějakého HTML vyprdne něco z MySQL.
Však když někdo nezná nic jinýho než kladivo, taky jím "úplně v pohodě" i spraví televizi :)
Těmi moderními aplikacemi myslíte websockety? K tomu používám celery a nodejs. Nodejs udržuje spojení a z djanga nebo celery mu posílám data, která chci poslat klientovi. Uznávám, že je to zbytečně komplikované, ale websockety používá jen malá část aplikace.
-
Těmi moderními aplikacemi myslíte websockety? K tomu používám celery a nodejs. Nodejs udržuje spojení a z djanga nebo celery mu posílám data, která chci poslat klientovi. Uznávám, že je to zbytečně komplikované, ale websockety používá jen malá část aplikace.
To nejsou jenom websockety, ale ten celkový koncept, kdy aplikace tahá jenom ta data, která nutně potřebuje, a překresluje jenom to, co je překreslit potřeba. Takhle bude nejspíš web v budoucnosti vypadat, nikdo nebude na každé kliknutí tahat (a generovat) celou stránku znovu.
Uznávám, že je to zbytečně komplikované, ale websockety používá jen malá část aplikace.
No jak která aplikace, že :) Nejenom, že je to zbytečně komplikované (další narovnávák na vohýbák), ale především je to zoufale pomalé a náročné na zdroje na serveru. Pomocí naplňování šablon prostě nejde (u aplikace složitější než hello world) dosáhnout latence řádově stejné jako je latence pingu. U aplikace založené na websocketech to možné je.
Šablony prostě imho patří minulosti. Odehrály svoji úlohu, ale jde se dál. A to ono "dál" bude pro python tvrdý oříšek. Možná se s ním popere, možná ne, to uvidíme. Ale hurónsky rozhlašovat, jak je python jedinečná technologie na web, je podle mě poněkud úsměvné, pionýři už jsou jiní a jinde.
-
Těmi moderními aplikacemi myslíte websockety? K tomu používám celery a nodejs. Nodejs udržuje spojení a z djanga nebo celery mu posílám data, která chci poslat klientovi. Uznávám, že je to zbytečně komplikované, ale websockety používá jen malá část aplikace.
To nejsou jenom websockety, ale ten celkový koncept, kdy aplikace tahá jenom ta data, která nutně potřebuje, a překresluje jenom to, co je překreslit potřeba. Takhle bude nejspíš web v budoucnosti vypadat, nikdo nebude na každé kliknutí tahat (a generovat) celou stránku znovu.
Uznávám, že je to zbytečně komplikované, ale websockety používá jen malá část aplikace.
No jak která aplikace, že :) Nejenom, že je to zbytečně komplikované (další narovnávák na vohýbák), ale především je to zoufale pomalé a náročné na zdroje na serveru. Pomocí naplňování šablon prostě nejde (u aplikace složitější než hello world) dosáhnout latence řádově stejné jako je latence pingu. U aplikace založené na websocketech to možné je.
Šablony prostě imho patří minulosti. Odehrály svoji úlohu, ale jde se dál. A to ono "dál" bude pro python tvrdý oříšek. Možná se s ním popere, možná ne, to uvidíme. Ale hurónsky rozhlašovat, jak je python jedinečná technologie na web, je podle mě poněkud úsměvné, pionýři už jsou jiní a jinde.
Já jsem o šablonách nic nepsal. CRUD aplikace může komunikovat čistě pomocí JSONu a html můžu obsluhovat jako statické soubory. MVC frameworky se rozšířily právě proto, že se v nich snadno dělají ajaxové aplikace.
-
Já jsem o šablonách nic nepsal. CRUD aplikace může komunikovat čistě pomocí JSONu a html můžu obsluhovat jako statické soubory. MVC frameworky se rozšířily právě proto, že se v nich snadno dělají ajaxové aplikace.
No a pak je tam to Django úplně zbytečné :)
-
MVC frameworky se rozšířily právě proto, že se v nich snadno dělají ajaxové aplikace.
fyi mvc v jave tu bolo 2001. struts kralovali v java svete ked ajax este spal v mozgu microsoftu
mvc akurat dobre generuje json miesto html
-
Já jsem o šablonách nic nepsal. CRUD aplikace může komunikovat čistě pomocí JSONu a html můžu obsluhovat jako statické soubory. MVC frameworky se rozšířily právě proto, že se v nich snadno dělají ajaxové aplikace.
No a pak je tam to Django úplně zbytečné :)
S tím souhlasím. I když třeba Django REST Framework se občas použít dá.
-
MVC frameworky se rozšířily právě proto, že se v nich snadno dělají ajaxové aplikace.
fyi mvc v jave tu bolo 2001. struts kralovali v java svete ked ajax este spal v mozgu microsoftu
mvc akurat dobre generuje json miesto html
Ten koncept je starý, ale dokud neexistoval ajax, tak se webové aplikace daly psát celkem pohodlně i bez toho.
-
Já jsem o šablonách nic nepsal. CRUD aplikace může komunikovat čistě pomocí JSONu a html můžu obsluhovat jako statické soubory. MVC frameworky se rozšířily právě proto, že se v nich snadno dělají ajaxové aplikace.
No a pak je tam to Django úplně zbytečné :)
S tím souhlasím. I když třeba Django REST Framework se občas použít dá.
Ještě se doplním. Nejsem velký fanoušek Djanga. Když mohu, používám Flask a SqlAlchemy. Django se snaží umět moc věcí najednou. Není ale pravda, že většina funkčnosti Djanga se nedá použít v ajaxových aplikacích. Jediné, co příliš nevyužijete jsou šablony. Všechno ostatní včetně formulářů se běžně používá i v čistě ajaxových aplikacích. Za každou cenu se vyhýbat generování html na serveru je dle mého názoru best practices fašismus.
-
Těmi moderními aplikacemi myslíte websockety? K tomu používám celery a nodejs. Nodejs udržuje spojení a z djanga nebo celery mu posílám data, která chci poslat klientovi. Uznávám, že je to zbytečně komplikované, ale websockety používá jen malá část aplikace.
To nejsou jenom websockety, ale ten celkový koncept, kdy aplikace tahá jenom ta data, která nutně potřebuje, a překresluje jenom to, co je překreslit potřeba. Takhle bude nejspíš web v budoucnosti vypadat, nikdo nebude na každé kliknutí tahat (a generovat) celou stránku znovu.
Uznávám, že je to zbytečně komplikované, ale websockety používá jen malá část aplikace.
No jak která aplikace, že :) Nejenom, že je to zbytečně komplikované (další narovnávák na vohýbák), ale především je to zoufale pomalé a náročné na zdroje na serveru. Pomocí naplňování šablon prostě nejde (u aplikace složitější než hello world) dosáhnout latence řádově stejné jako je latence pingu. U aplikace založené na websocketech to možné je.
Šablony prostě imho patří minulosti. Odehrály svoji úlohu, ale jde se dál. A to ono "dál" bude pro python tvrdý oříšek. Možná se s ním popere, možná ne, to uvidíme. Ale hurónsky rozhlašovat, jak je python jedinečná technologie na web, je podle mě poněkud úsměvné, pionýři už jsou jiní a jinde.
Celkovej koncept je to fajn, ale nemyslím si že je na něj každej momentálně připraven a že všude má smysl. Viděl bych to spíš jako budoucnost. Šablony pomalé jsou, ale proto se na druhou stranu kešují. Kde pak je ve výsledným jedno jak pomalej jazyk je pod kapotou, protože spousta věcí bude stejně nakešovanejch, ano pochopitelně záleží o jakej web jde, respektive jestli web, nebo webovou aplikaci.
Celkem tohle vlákno sleduji a nemyslím si že tu někdo tvrdí že je Python (na web) jedinečnej, to tak maximálně Javisti (nejen) tady tvrdí jak je ta jejich Java na všechno nejlepší.
Já jsem o šablonách nic nepsal. CRUD aplikace může komunikovat čistě pomocí JSONu a html můžu obsluhovat jako statické soubory. MVC frameworky se rozšířily právě proto, že se v nich snadno dělají ajaxové aplikace.
No a pak je tam to Django úplně zbytečné :)
Ale MVC frameworky nejsou jen o tom, že generují data do HTML šablon, můžou generovat data například právě do JSONu, třeba ve spojistosti u djanga s Django REST frameworkem.
Já jsem o šablonách nic nepsal. CRUD aplikace může komunikovat čistě pomocí JSONu a html můžu obsluhovat jako statické soubory. MVC frameworky se rozšířily právě proto, že se v nich snadno dělají ajaxové aplikace.
No a pak je tam to Django úplně zbytečné :)
S tím souhlasím. I když třeba Django REST Framework se občas použít dá.
Ještě se doplním. Nejsem velký fanoušek Djanga. Když mohu, používám Flask a SqlAlchemy. Django se snaží umět moc věcí najednou. Není ale pravda, že většina funkčnosti Djanga se nedá použít v ajaxových aplikacích. Jediné, co příliš nevyužijete jsou šablony. Všechno ostatní včetně formulářů se běžně používá i v čistě ajaxových aplikacích. Za každou cenu se vyhýbat generování html na serveru je dle mého názoru best practices fašismus.
Toho bych rád využil a zeptal se proč používat Flask.
Já kdysi k Djangu přišel proto že v něm byl napsanej web kterej sem měl udržovat a zalíbilo se mě, tak sem ho používal nadále. Mám to nastavené tak, že když je web složitější, šáhnu po Djangu, v opačném případě po Bottle.
Na Djangu se mě právě líbí, že umí spoustu věcí a neřekl bych že špatně a hlavně že má super dokumentaci. Když sem tedy uvažoval o Flasku, ve výsledným bych si z toho ve směs poskládal Django, proč ho tedy nepoužít rovnou, kde mám zaručenou celkovou funkčnost? O tom že se mě víc líbí přístup urls.py, kde mám mapování adres na jednom místě, ani nemluvě, to je spíš příjemnej bonus.
-
Šablony pomalé jsou, ale proto se na druhou stranu kešují.
Nejde ani zdaleka jenom o jejich generování, ale o celej ten cyklus - načtu data, naplním do šablony, pošlu přes net, parsuju, vykresluju. A tohle všechno dělám pro všechna data na stránce, i ta, na která se v tom kliku vůbec nešáhlo. Neefektivní nesmysl.
-
Šablony pomalé jsou, ale proto se na druhou stranu kešují.
Nejde ani zdaleka jenom o jejich generování, ale o celej ten cyklus - načtu data, naplním do šablony, pošlu přes net, parsuju, vykresluju. A tohle všechno dělám pro všechna data na stránce, i ta, na která se v tom kliku vůbec nešáhlo. Neefektivní nesmysl.
Jop, proto tu mame vsechny ty nenavidene Reacty a Angulary :).
-
Jop, proto tu mame vsechny ty nenavidene Reacty a Angulary :).
Právě - a těm (AFAIK) nemá Python moc co nabídnout...
-
Toho bych rád využil a zeptal se proč používat Flask.
Já kdysi k Djangu přišel proto že v něm byl napsanej web kterej sem měl udržovat a zalíbilo se mě, tak sem ho používal nadále. Mám to nastavené tak, že když je web složitější, šáhnu po Djangu, v opačném případě po Bottle.
Na Djangu se mě právě líbí, že umí spoustu věcí a neřekl bych že špatně a hlavně že má super dokumentaci. Když sem tedy uvažoval o Flasku, ve výsledným bych si z toho ve směs poskládal Django, proč ho tedy nepoužít rovnou, kde mám zaručenou celkovou funkčnost? O tom že se mě víc líbí přístup urls.py, kde mám mapování adres na jednom místě, ani nemluvě, to je spíš příjemnej bonus.
To bude asi subjektivní. Hlavní důvod je SQLAlchemy. Pracuji s legacy databázemi a tam Django ORM moc nevyniká. SQLAlchemy funguje po vygenerování modelů out of box. Spoustu funkčností Djanga bych nevyužil, protože nemohu vytvářet libovolné nové tabulky.
Oddělené urls.py se mi moc nelíbí. Musím zbytečně přepínat mezi soubory. To je subjektivní.
Koncept oddělených appek v Djangu je sice pěkný, ale lidé to přeceňují a uměle rozdělují kód, který spolu souvisí. Je to má zkušenost s kolegy Djangisty, kteří IMHO zbytečně moc řeší architekturu na úkor funkčnosti.
Na druhou stranu, na aplikace začínající od nuly s vlastní databází je Django asi vhodnější. Spoustu věcí tam máte bezpracně hned od začátku.
Jop, proto tu mame vsechny ty nenavidene Reacty a Angulary :).
Právě - a těm (AFAIK) nemá Python moc co nabídnout...
Od někud brát data musí.
-
Jop, proto tu mame vsechny ty nenavidene Reacty a Angulary :).
Právě - a těm (AFAIK) nemá Python moc co nabídnout...
V Pythonu backendy nepíšu, ale tohle bych si nedovolil tvrdit. Nevidím žádný rozdíl, jestli napíšu backend v Ruby/node.js/Python/Go/Java/... Pokud jsem si v tom jazyce jistý, tak je mnohem efektivnější napsat ho v tom co znám. Nevím co by mi Java nabídla navíc. Dnešní frameworky jsou si tak podobné (Javovské neznám), že jsou mezi nimi mikroskopické rozdíly. Kdybych si chtěl rýpnout, tak bych jen dodal, že v javě bude zdroják sice 3x delší, ale za to bude vývoj trvat 3x tak dlouho. :D
Navíc se předpokládám bavíme o českém písečku, pokud vím společnosti jako Twitter nebo Dropbox byly z výkonostních důvodů nuceny migrovat poději na něco rychlejšího, ale kdo tady má tyto problémy?
-
Toho bych rád využil a zeptal se proč používat Flask.
Já kdysi k Djangu přišel proto že v něm byl napsanej web kterej sem měl udržovat a zalíbilo se mě, tak sem ho používal nadále. Mám to nastavené tak, že když je web složitější, šáhnu po Djangu, v opačném případě po Bottle.
Na Djangu se mě právě líbí, že umí spoustu věcí a neřekl bych že špatně a hlavně že má super dokumentaci. Když sem tedy uvažoval o Flasku, ve výsledným bych si z toho ve směs poskládal Django, proč ho tedy nepoužít rovnou, kde mám zaručenou celkovou funkčnost? O tom že se mě víc líbí přístup urls.py, kde mám mapování adres na jednom místě, ani nemluvě, to je spíš příjemnej bonus.
To bude asi subjektivní. Hlavní důvod je SQLAlchemy. Pracuji s legacy databázemi a tam Django ORM moc nevyniká. SQLAlchemy funguje po vygenerování modelů out of box. Spoustu funkčností Djanga bych nevyužil, protože nemohu vytvářet libovolné nové tabulky.
Oddělené urls.py se mi moc nelíbí. Musím zbytečně přepínat mezi soubory. To je subjektivní.
Koncept oddělených appek v Djangu je sice pěkný, ale lidé to přeceňují a uměle rozdělují kód, který spolu souvisí. Je to má zkušenost s kolegy Djangisty, kteří IMHO zbytečně moc řeší architekturu na úkor funkčnosti.
Na druhou stranu, na aplikace začínající od nuly s vlastní databází je Django asi vhodnější. Spoustu věcí tam máte bezpracně hned od začátku.
Jop, proto tu mame vsechny ty nenavidene Reacty a Angulary :).
Právě - a těm (AFAIK) nemá Python moc co nabídnout...
Od někud brát data musí.
Jo SQLAlchemy je fajn :)
Oddělené appky jsou fajn, ale musí se to oddělovat s rozumem, to souhlasím.
Dík za reakci :-)
-
Toho bych rád využil a zeptal se proč používat Flask.
Já kdysi k Djangu přišel proto že v něm byl napsanej web kterej sem měl udržovat a zalíbilo se mě, tak sem ho používal nadále. Mám to nastavené tak, že když je web složitější, šáhnu po Djangu, v opačném případě po Bottle.
Na Djangu se mě právě líbí, že umí spoustu věcí a neřekl bych že špatně a hlavně že má super dokumentaci. Když sem tedy uvažoval o Flasku, ve výsledným bych si z toho ve směs poskládal Django, proč ho tedy nepoužít rovnou, kde mám zaručenou celkovou funkčnost? O tom že se mě víc líbí přístup urls.py, kde mám mapování adres na jednom místě, ani nemluvě, to je spíš příjemnej bonus.
Tak než React je lepší Dart a Polymer.
To bude asi subjektivní. Hlavní důvod je SQLAlchemy. Pracuji s legacy databázemi a tam Django ORM moc nevyniká. SQLAlchemy funguje po vygenerování modelů out of box. Spoustu funkčností Djanga bych nevyužil, protože nemohu vytvářet libovolné nové tabulky.
Oddělené urls.py se mi moc nelíbí. Musím zbytečně přepínat mezi soubory. To je subjektivní.
Koncept oddělených appek v Djangu je sice pěkný, ale lidé to přeceňují a uměle rozdělují kód, který spolu souvisí. Je to má zkušenost s kolegy Djangisty, kteří IMHO zbytečně moc řeší architekturu na úkor funkčnosti.
Na druhou stranu, na aplikace začínající od nuly s vlastní databází je Django asi vhodnější. Spoustu věcí tam máte bezpracně hned od začátku.
Jop, proto tu mame vsechny ty nenavidene Reacty a Angulary :).
Právě - a těm (AFAIK) nemá Python moc co nabídnout...
Od někud brát data musí.
-
V Pythonu backendy nepíšu, ale tohle bych si nedovolil tvrdit. Nevidím žádný rozdíl, jestli napíšu backend v Ruby/node.js/Python/Go/Java/... Pokud jsem si v tom jazyce jistý, tak je mnohem efektivnější napsat ho v tom co znám. Nevím co by mi Java nabídla navíc. Dnešní frameworky jsou si tak podobné (Javovské neznám), že jsou mezi nimi mikroskopické rozdíly. Kdybych si chtěl rýpnout, tak bych jen dodal, že v javě bude zdroják sice 3x delší, ale za to bude vývoj trvat 3x tak dlouho. :D
Tak to je fajn, že nejdřív řekneš, že tomu vůbec nerozumíš, ale dál to pak rozvíjíš :D Javu bys vybral přesně kvůli brutálnímu výkonu. Jasný, mikroskopické rozdíly... hmmm. Vývoj bude trvat třikrát déle, což je ta výhoda. Napatlat něco ve skriptovacím Pythonu a pak jít patlat něco jiného, je u důležitých systémů k ničemu. Důležitá je spolehlivost a udržovatelnost. To se u skriptíků moc nenosí, chápu.
-
Jo SQLAlchemy je fajn :)
Oddělené appky jsou fajn, ale musí se to oddělovat s rozumem, to souhlasím.
Dík za reakci :-)
Všechno co jsem zmiňoval má i své výhody a jsou to jen nepodstatné věci. Rozhodně to neberte jako mou kritiku Djanga. Na velký problém jsem při práci s ním nenarazil.
-
Nevím co by mi Java nabídla navíc.
podporu vice vlaken ?
-
Nevím co by mi Java nabídla navíc.
podporu vice vlaken ?
Jaká je výhoda používání skutečných vláken ve skriptovacím jazyce oproti eventloopu? Ok, skript poběží čtyřikrát rychleji na čtyřech jádrech, ale pořád používám jazyk, který je padesátkrát pomalejší než třeba ta Java.
-
Jaká je výhoda používání skutečných vláken ve skriptovacím jazyce oproti eventloopu? Ok, skript poběží čtyřikrát rychleji na čtyřech jádrech, ale pořád používám jazyk, který je padesátkrát pomalejší než třeba ta Java.
Čtyřikrát je pořád lepší než jednou ;) A nezapomeň, že dneska má 4 jádra spíš tak možná mobil.
Ale nejde jenom o rychlost. V jazyce, který umí pořádný multithreading, ideálně green threads/processes, můžu například pro každou session od začátku až do konce nechat běžet jeden green thread a držet v něm stav té session, aniž bych ho nutně musel pořád ukládat a načítat a blokoval uživatele navzájem. Pokud tě to zajímá, můžeš se podívat, jak to dělá Phoenix v Elixiru: http://www.phoenixframework.org/docs/channels
-
V Pythonu backendy nepíšu, ale tohle bych si nedovolil tvrdit. Nevidím žádný rozdíl, jestli napíšu backend v Ruby/node.js/Python/Go/Java/... Pokud jsem si v tom jazyce jistý, tak je mnohem efektivnější napsat ho v tom co znám. Nevím co by mi Java nabídla navíc. Dnešní frameworky jsou si tak podobné (Javovské neznám), že jsou mezi nimi mikroskopické rozdíly. Kdybych si chtěl rýpnout, tak bych jen dodal, že v javě bude zdroják sice 3x delší, ale za to bude vývoj trvat 3x tak dlouho. :D
Tak to je fajn, že nejdřív řekneš, že tomu vůbec nerozumíš, ale dál to pak rozvíjíš :D Javu bys vybral přesně kvůli brutálnímu výkonu. Jasný, mikroskopické rozdíly... hmmm. Vývoj bude trvat třikrát déle, což je ta výhoda. Napatlat něco ve skriptovacím Pythonu a pak jít patlat něco jiného, je u důležitých systémů k ničemu. Důležitá je spolehlivost a udržovatelnost. To se u skriptíků moc nenosí, chápu.
A, brouk Pytlík se zastavil... ;)
Brutální výkon, java, ... nemá smysl dále pokračovat.
-
A, brouk Pytlík se zastavil... ;)
Brutální výkon, java, ... nemá smysl dále pokračovat.
Jako ja nevim, ale normalni Python je malokdy rychlejsi, nez Java, vetsinou i o rady pomalejsi - https://benchmarksgame.alioth.debian.org/u64q/python.html.
-
Brutální výkon, java, ... nemá smysl dále pokračovat.
ako bolo vyssie, gil brzdi python. threads neprichadzaju do uvahy
z druhej strany je tu integracia s c
java a .net maju velmi rychle virtualmachines. to sa s pythonom / ruby / php ani neda porovnat
-
Jo SQLAlchemy je fajn :)
Oddělené appky jsou fajn, ale musí se to oddělovat s rozumem, to souhlasím.
Dík za reakci :-)
Všechno co jsem zmiňoval má i své výhody a jsou to jen nepodstatné věci. Rozhodně to neberte jako mou kritiku Djanga. Na velký problém jsem při práci s ním nenarazil.
Neberu, udělal jsem si závěr protože SQLAlchemy (což je fajn ORM) a ostatní subjektivní názor...
Brutální výkon, java, ... nemá smysl dále pokračovat.
ako bolo vyssie, gil brzdi python. threads neprichadzaju do uvahy
z druhej strany je tu integracia s c
java a .net maju velmi rychle virtualmachines. to sa s pythonom / ruby / php ani neda porovnat
To ano, Python má PyPy, což někde určitě pomůže...
-
Python si svou stručnou syntaxí natlouk, nejde v něm udělat například volání řetězcově metody na více řádků, bez toho aniž bych to musel obalit závorkou, nebo lomítkovat řádky. A to se mi nelíbí.
Tohle bych nečekal http://benchmarksgame.alioth.debian.org/u64q/php.html
Někdo tu narážel na Python v Seznamu. Nevíte k čemu používaj Javu?
-
Python si svou stručnou syntaxí natlouk, nejde v něm udělat například volání řetězcově metody na více řádků, bez toho aniž bych to musel obalit závorkou, nebo lomítkovat řádky. A to se mi nelíbí.
Tohle bych nečekal http://benchmarksgame.alioth.debian.org/u64q/php.html
Někdo tu narážel na Python v Seznamu. Nevíte k čemu používaj Javu?
proč by nešlo, zkuste toto
print("""aaaa
aaaaa
aaaaa
aaaaa
aaaa
aaaaaa
aaaa""".upper())
-
proč by nešlo, zkuste toto
print("""aaaa
aaaaa
aaaaa
aaaaa
aaaa
aaaaaa
aaaa""".upper())
result = session.query(Entity)
.filter(..)
.all()
-
Tohle bych nečekal http://benchmarksgame.alioth.debian.org/u64q/php.html
Pokud někdo používá PHP či Python stejným způsobem jako Javu, tak mu v benchmarcích vždycky budou vycházet nesmysly.
-
Tohle bych nečekal http://benchmarksgame.alioth.debian.org/u64q/php.html
Pokud někdo používá PHP či Python stejným způsobem jako Javu, tak mu v benchmarcích vždycky budou vycházet nesmysly.
Pokud vim, tak zrovna benchmarksgame pisou dost zkuseni lidi v danem jazyku, neni to zadny blog, kde autor zna jeden jazyk a srovnava s dvaceti, o kterych cetl 10 minut.
-
Tohle bych nečekal http://benchmarksgame.alioth.debian.org/u64q/php.html
Pokud někdo používá PHP či Python stejným způsobem jako Javu, tak mu v benchmarcích vždycky budou vycházet nesmysly.
Pokud vim, tak zrovna benchmarksgame pisou dost zkuseni lidi v danem jazyku, neni to zadny blog, kde autor zna jeden jazyk a srovnava s dvaceti, o kterych cetl 10 minut.
Tak se pořádně podívej na ty nesmyslné příklady a na zdrojáky. To je na porovnávání imperativních a nikoli objektových jazyků. To je tak na C/C++ vs. Fortran apod.
-
Tak se pořádně podívej na ty nesmyslné příklady a na zdrojáky. To je na porovnávání imperativních a nikoli objektových jazyků. To je tak na C/C++ vs. Fortran apod.
Však to je taky porovnání hrubého výkonu, nic víc, nic míň. Třeba můj oblíbený Erlang tam dopadá dost špatně a vůbec mi to žíly netrhá :)
-
Nevím co by mi Java nabídla navíc.
podporu vice vlaken ?
Jaká je výhoda používání skutečných vláken ve skriptovacím jazyce oproti eventloopu? Ok, skript poběží čtyřikrát rychleji na čtyřech jádrech, ale pořád používám jazyk, který je padesátkrát pomalejší než třeba ta Java.
V ideálním případě žádný, protože vlákna by měla transparentně používat jen standardní knihovna, a ta bude stejně z větší části napsaná nativně. Nicméně svět ideání není a lidi eventloopy používat moc neumí...
-
V ideálním případě žádný, protože vlákna by měla transparentně používat jen standardní knihovna, a ta bude stejně z větší části napsaná nativně. Nicméně svět ideání není a lidi eventloopy používat moc neumí...
Jak jsi tohle myslel? Eventloop mi přece sám o sobě nijak neumožňuje využít víc jader. Pokud mám v jazyce de facto jeden velký stav, který neumím rozdělit na víc nezávislých stavů, tak ty eventy stejně musím zpracovávat sekvenčně a opět využiju jenom jedno jádro. Eventloop by mohl pomoct jenom v případě, že bych uměl eventy zpracovávat paralelně, což stejně v těch zmiňovaných jazycích obvykle nejde (nebo jde za cenu hnusných hacků).
Nebo jak jsi to myslel?
-
V ideálním případě žádný, protože vlákna by měla transparentně používat jen standardní knihovna, a ta bude stejně z větší části napsaná nativně. Nicméně svět ideání není a lidi eventloopy používat moc neumí...
Jak jsi tohle myslel? Eventloop mi přece sám o sobě nijak neumožňuje využít víc jader. Pokud mám v jazyce de facto jeden velký stav, který neumím rozdělit na víc nezávislých stavů, tak ty eventy stejně musím zpracovávat sekvenčně a opět využiju jenom jedno jádro. Eventloop by mohl pomoct jenom v případě, že bych uměl eventy zpracovávat paralelně, což stejně v těch zmiňovaných jazycích obvykle nejde (nebo jde za cenu hnusných hacků).
Nebo jak jsi to myslel?
No samotný event je stav, není zaručeno pořadí událostí, takže rozdělit to lze, maximálně nějaká událost počká na dokončení nutných předchozích kroků, což principielně nebrání rozdělení výpočtu na několik jader.
-
Jaká je výhoda používání skutečných vláken ve skriptovacím jazyce oproti eventloopu? Ok, skript poběží čtyřikrát rychleji na čtyřech jádrech, ale pořád používám jazyk, který je padesátkrát pomalejší než třeba ta Java.
Čtyřikrát je pořád lepší než jednou ;) A nezapomeň, že dneska má 4 jádra spíš tak možná mobil.
Ale nejde jenom o rychlost. V jazyce, který umí pořádný multithreading, ideálně green threads/processes, můžu například pro každou session od začátku až do konce nechat běžet jeden green thread a držet v něm stav té session, aniž bych ho nutně musel pořád ukládat a načítat a blokoval uživatele navzájem. Pokud tě to zajímá, můžeš se podívat, jak to dělá Phoenix v Elixiru: http://www.phoenixframework.org/docs/channels
Stav si může držet i couroutina. Koukal jsem na ten Phoenix framework. Je to pěkné, ale nevidím tam nic, k čemu by byla nutná vlákna. Ještě se na to podívám později.
-
V ideálním případě žádný, protože vlákna by měla transparentně používat jen standardní knihovna, a ta bude stejně z větší části napsaná nativně. Nicméně svět ideání není a lidi eventloopy používat moc neumí...
Jak jsi tohle myslel? Eventloop mi přece sám o sobě nijak neumožňuje využít víc jader. Pokud mám v jazyce de facto jeden velký stav, který neumím rozdělit na víc nezávislých stavů, tak ty eventy stejně musím zpracovávat sekvenčně a opět využiju jenom jedno jádro. Eventloop by mohl pomoct jenom v případě, že bych uměl eventy zpracovávat paralelně, což stejně v těch zmiňovaných jazycích obvykle nejde (nebo jde za cenu hnusných hacků).
Nebo jak jsi to myslel?
Sám o sobě ne. Nicméně o stavu jsem nic neříkal. Představuju si eventloop (kód pak je nějaká šílenost s vnořenými callbacky), přičemž volání knihovny se rozprostřou na více jader. High-level kód pak může být sekvenční a ostatní jádra využije jen kód knihovny. Záleží samozřejmě na tom, co píšu. Alternativně by šlo mít jen funkcionální datové struktury a tam, kde to nejde, na těch pár místech použít zámky. Pak by ani ten high-level kód nemusel být sekvenční.
-
Stav si může držet i couroutina. Koukal jsem na ten Phoenix framework. Je to pěkné, ale nevidím tam nic, k čemu by byla nutná vlákna. Ještě se na to podívám později.
Jde především o 1. jednoduchost řešení 2. o paralelizovatelnost "zadarmo" (bez toho, aby se o ni musel programátor nějak explicitně starat).
Načtu stránku - dojde k autentizaci a inicializaci stavu (načtení nebo vytvoření session). Každá událost na webu se pak odešle na backend (tomu procesu) a ten modifukuje stav. Zavření stránky = ztráta spojení = zrušení procesu, příp. uložení stavu.
Pokud mám green threads, můžu to celé psát tak, jako bych měl jednovláknovou aplikaci, která obsluhuje právě jednoho klienta a nic jiného ji nezajímá. Narozdíl od té výš zmíněné obezličky s N interpretery (kde jich navíc typicky nemůžu mít tolik, kolik mám klientů) ale navíc můžu snadno posílat události mezi takovými procesy. Tady v tom Phoenixu je to pubsub - klienta zajímají např. zprávy v chatové místnosti, tak každou novou zprávu odešlu na daný kanál a pubsub ji automaticky doručí všem procesům a ty procesy pak informují svého klienta. Protože těch procesů mám typicky víc než jader, škáluje mi to prakticky lineárně a přitom vůbec neřeším nějaké korutiny odskoky sem a tam, zamražení stavu a jeho zpětné načtení až na něj přijde řada, nemusím přepínat kontext jenom v pevně daných okamžicích, ale prakticky (z pohledu programátora) kdykoli atd. atd. atd.
Dost těžko se to vysvětluje, je potřeba si s tím tak půl roku hrát, aby si člověk uvědomil, v čem všem se to vyplatí a jakými všemi způsoby to usnadňuje práci. Nedělám si sebemenší naději, že bych to uměl nějak nevyvratitelně dokázat. Zkus a uvidíš, třeba se mýlím.
Nicméně o stavu jsem nic neříkal. Představuju si eventloop (kód pak je nějaká šílenost s vnořenými callbacky), přičemž volání knihovny se rozprostřou na více jader. High-level kód pak může být sekvenční a ostatní jádra využije jen kód knihovny. Záleží samozřejmě na tom, co píšu. Alternativně by šlo mít jen funkcionální datové struktury a tam, kde to nejde, na těch pár místech použít zámky. Pak by ani ten high-level kód nemusel být sekvenční.
No jo, ale takhle by to právě mohlo fungovat (jestli jsem tě pochopil správně) jenom pokud by 1. ty operace byly vůbec principielně paralelizovatelné 2. pokud by ten "podvozek" (runtime jazyka nebo knihovna) uměl poznat, že to může paralelizovat.
Jasně, pokud ten event bude "k tomuhle poli tisíce hodnot připočti jedničku", tak to paralelizovat jde. Ale to není úplně typická operace na webovém backendu, notabene napsaném v OOP jazyce, navíc tak nevyzpytatelném/flexibilním [nehodící se škrtni ;) ] jako je Python...
-
Nicméně o stavu jsem nic neříkal. Představuju si eventloop (kód pak je nějaká šílenost s vnořenými callbacky), přičemž volání knihovny se rozprostřou na více jader. High-level kód pak může být sekvenční a ostatní jádra využije jen kód knihovny. Záleží samozřejmě na tom, co píšu. Alternativně by šlo mít jen funkcionální datové struktury a tam, kde to nejde, na těch pár místech použít zámky. Pak by ani ten high-level kód nemusel být sekvenční.
No jo, ale takhle by to právě mohlo fungovat (jestli jsem tě pochopil správně) jenom pokud by 1. ty operace byly vůbec principielně paralelizovatelné 2. pokud by ten "podvozek" (runtime jazyka nebo knihovna) uměl poznat, že to může paralelizovat.
Jasně, pokud ten event bude "k tomuhle poli tisíce hodnot připočti jedničku", tak to paralelizovat jde. Ale to není úplně typická operace na webovém backendu, notabene napsaném v OOP jazyce, navíc tak nevyzpytatelném/flexibilním [nehodící se škrtni ;) ] jako je Python...
1. Pochopitelně.
2. Chtěl jsem to nechat na programátorovi :)
Neměl jsem na mysli nic konkrétního, nicméně u webového backendu si představuju, že paralelní přístup k datům za mě ošetří databáze, takže kromě správy sessions apod. klidně můžu jednotlivé požadavky zpracovávat souběžně (ne každý na jednom vlákně, ale třeba pomocí Grand Central Dispatch). Obecně jsem pro defaultní paralelní běh s mutexy, kde jsou třeba, než sekvenční divnokód s občasnou paralelizací.
-
nicméně u webového backendu si představuju, že paralelní přístup k datům za mě ošetří databáze
No to vlastně neříkáš nic jiného, než že ten samotný obslužný kód je bezstavový - což je právě to, co platilo dřív - ten CRUD model a dneska už to nestačí/neplatí. Resp. můžeš to tak dělat, ale nebude to pohodlné a výsledky nebudou dobré (můj názor, každý nemusí souhlasit).
-
nicméně u webového backendu si představuju, že paralelní přístup k datům za mě ošetří databáze
No to vlastně neříkáš nic jiného, než že ten samotný obslužný kód je bezstavový - což je právě to, co platilo dřív - ten CRUD model a dneska už to nestačí/neplatí. Resp. můžeš to tak dělat, ale nebude to pohodlné a výsledky nebudou dobré (můj názor, každý nemusí souhlasit).
Možná místo než databáze jsem měl říct "vrstva pro práci s daty". Chápu ale, co myslíš, a nemyslím, že si nějak oponujeme.
-
Možná místo než databáze jsem měl říct "vrstva pro práci s daty". Chápu ale, co myslíš, a nemyslím, že si nějak oponujeme.
Jasne, vsak si jenom tak povidame, nesporime se ;)
Mne se na tech green threads libi prave to, ze pokud nechces, zadnou "vrstvu pro práci s daty" tam mit nemusis - stav si proste drzis uvnitr toho vlakna, nic neresis, mas ho pro sebe a nikdo ti na nej nemuze sahat. Pohodicka, klidek ;)
-
Možná místo než databáze jsem měl říct "vrstva pro práci s daty". Chápu ale, co myslíš, a nemyslím, že si nějak oponujeme.
Jasne, vsak si jenom tak povidame, nesporime se ;)
Mne se na tech green threads libi prave to, ze pokud nechces, zadnou "vrstvu pro práci s daty" tam mit nemusis - stav si proste drzis uvnitr toho vlakna, nic neresis, mas ho pro sebe a nikdo ti na nej nemuze sahat. Pohodicka, klidek ;)
Tímhle stylem píšu taky, ale zase nedělám webové backendy, v AI si můžu hrát v blackboxu a jen vyplivnout výsledek.
-
Jde především o 1. jednoduchost řešení 2. o paralelizovatelnost "zadarmo" (bez toho, aby se o ni musel programátor nějak explicitně starat).
Načtu stránku - dojde k autentizaci a inicializaci stavu (načtení nebo vytvoření session). Každá událost na webu se pak odešle na backend (tomu procesu) a ten modifukuje stav. Zavření stránky = ztráta spojení = zrušení procesu, příp. uložení stavu.
Pokud mám green threads, můžu to celé psát tak, jako bych měl jednovláknovou aplikaci, která obsluhuje právě jednoho klienta a nic jiného ji nezajímá. Narozdíl od té výš zmíněné obezličky s N interpretery (kde jich navíc typicky nemůžu mít tolik, kolik mám klientů) ale navíc můžu snadno posílat události mezi takovými procesy. Tady v tom Phoenixu je to pubsub - klienta zajímají např. zprávy v chatové místnosti, tak každou novou zprávu odešlu na daný kanál a pubsub ji automaticky doručí všem procesům a ty procesy pak informují svého klienta. Protože těch procesů mám typicky víc než jader, škáluje mi to prakticky lineárně a přitom vůbec neřeším nějaké korutiny odskoky sem a tam, zamražení stavu a jeho zpětné načtení až na něj přijde řada, nemusím přepínat kontext jenom v pevně daných okamžicích, ale prakticky (z pohledu programátora) kdykoli atd. atd. atd.
Dost těžko se to vysvětluje, je potřeba si s tím tak půl roku hrát, aby si člověk uvědomil, v čem všem se to vyplatí a jakými všemi způsoby to usnadňuje práci. Nedělám si sebemenší naději, že bych to uměl nějak nevyvratitelně dokázat. Zkus a uvidíš, třeba se mýlím.
Rozdílný asynchronní a synchronní kód se mi také nelíbí. Asynchronní kód moc často nepíšu. To, že se kontext přepíná v pevně daných okamžicích jsem vždy považoval za výhodu. Takový kód se snadno debuguje. Asi to je tím, že mám zkušenosti s vlákny jen v c/c++.
Ten koncept channelů mi přijde podobný jako v Clojure. V Clojurescriptu to funguje bez vláken.
Pro moje účely většinou stačí blokující framework. Zde http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/ jsou nějaké grafy ukazující, že při použití rychlé databáze je neblokující framework zbytečný. Websockety používám jen pro posílání notifikací ze serveru na klient. Kdybych dělal nějakou real time aplikaci typu chat, asi bych Elixir zkusil použít jako náhradu za Nodejs.
-
Jako ja nevim, ale normalni Python je malokdy rychlejsi, nez Java, vetsinou i o rady pomalejsi - https://benchmarksgame.alioth.debian.org/u64q/python.html.
Tohle bych nečekal http://benchmarksgame.alioth.debian.org/u64q/php.html
Njn, když ono je to s těmi testy takové ošidné. Když bych měl parafrázovat: Nevěřím žádnému benchmarku, který jsem si sám nezfalšoval...
Kupříkladu:
C
#include <stdio.h>
int main ()
{
long a;
long sum = 0;
for( a = 0; a < 200000000; a++ )
{
sum += a;
}
printf("sum: %ld\n", sum);
return 0;
}
$ gcc -o bench0 bench.c && time ./bench0
sum: 19999999900000000
real 0m0.529s
user 0m0.524s
sys 0m0.000s
Půl sekundy... Hm rychlovka!
Java
class Bench {
public static void main (String [] args)
{
long i, sum = 0;
for(i=0; i<200000000; i++) {
sum+=i;
}
System.out.println(sum);
}
}
$ javac bench.java && time java Bench
19999999900000000
real 0m0.188s
user 0m0.184s
sys 0m0.016s
Tý jo! Java skoro 3x rychlejší než C?! (viz. dále)
PHP
<?php
$sum = 0;
for($i=0; $i<200000000; $i++) {
$sum += $i;
}
echo($sum."\n");
?>
$ time php -f bench.php
19999999900000000
real 0m8.860s
user 0m8.836s
sys 0m0.012s
No to se dalo čekat.
Python
sum = 0
for i in range(200000000):
sum+=i
print(sum)
$ time python bench3.py
19999999900000000
real 0m25.327s
user 0m21.612s
sys 0m3.616s
No to teda vypadá vážně blbě!
Python 3
$ time python3 bench3.py
19999999900000000
real 0m21.746s
user 0m21.676s
sys 0m0.012s
Taky propadak! ...???
No jo, jenže...
Python 2
sum = 0
for i in xrange(200000000):
sum+=i
print(sum)
(range vs xrange)
$ time python bench.py
19999999900000000
real 0m15.998s
user 0m15.972s
sys 0m0.000s
No vida, jedno písmenko a co to udělá, že? ;-)
A co na to JIT, když Java má, chci ho taky!
PyPy
$ time pypy bench3.py
19999999900000000
real 0m1.175s
user 0m1.152s
sys 0m0.016s
To je už hodně zajímavé, jen dvojnásobek času, který na to potřebuje C.
$ time pypy bench.py
19999999900000000
real 0m1.165s
user 0m1.156s
sys 0m0.004s
A tady jakbysmet.
Ale ruku na srdce, ono v Pythonu se to stejně má dělat jinak, že...
Python 3
print(sum(range(200000000)))
$ time python3 bench-sum-range.py
19999999900000000
real 0m3.209s
user 0m3.200s
sys 0m0.000s
To už je 7x rychlejší než původní kód...
Python 2
$ cat bench-sum-xrange.py
print sum(xrange(200000000))
$ time python bench-sum-xrange.py
19999999900000000
real 0m1.335s
user 0m1.324s
sys 0m0.000s
Tohle je dokonce 19x rychlejší než původní kód a zase se přibližujeme rychlosti Céčka.
A Python má vlastně hromady specializovaných knihoven, že...
Python 3
import numpy
print numpy.sum(numpy.arange(200000000))
$ time python3 bench-numpy.py
19999999900000000
real 0m1.745s
user 0m0.792s
sys 0m0.876s
Hm, 2x rychlejší než kód bez specializované knihovny.
Python 2
$ time python bench-numpy.py
19999999900000000
real 0m1.599s
user 0m0.684s
sys 0m0.900s
Mno a tady jsme si kupodivu nepomohli.
A pro pořádek, v Céčku bychom to asi těžko kompilovali s -O0, že?
C
$ gcc -O1 -o bench1 bench.c && time ./bench1
sum: 19999999900000000
real 0m0.085s
user 0m0.080s
sys 0m0.000s
Kde jsi Javo? :)
$ gcc -O2 -o bench2 bench.c && time ./bench2
sum: 19999999900000000
real 0m0.003s
user 0m0.000s
sys 0m0.000s
Java? Cože? Kde? :D
Pointa je myslím jasná...
- když budu chtít, může Java vypadat lepší než C a PHP bude vypadat velmi zajímavě
- když budu patlal, tak v Pythonu budu daleko za všemi ostatními.
- ale pak si pustíme desktopový program v Javě a budeme se divit, co se stalo s tou pověstnou o řády rychlejší Javou
- když budu chtít, bude se Python blížit Céčku
- když použiji možnosti konkrétní implementace daného jazyka (specializované knihovny, JIT ap.), bude to vypadat zase úplně jinak
- s Céčkem stejně všem nakopu zadnice, protože takhle úloha se s optimalizacemi přeloží na pár strojových instrukcí a pak je spouštění takového programu dražší než vlastní běh, ale dělat v tom backend pro webové appky bych fakt nechtěl (naposled si vzpomínám hromadu let zpátky nějaké CGI "skripy", ale to byla úplně jiná doba).
Mimochodem zkuste si ten rozsah pro jednotlivé testy zvětšit desetinásobně. Příklady s range v Python 2 vám na paměť utlučou stroj s 16 GiB RAM (protože to vytváří list o daném počtu položek), kdežto xrange či Python 3 spotřebu paměti elegatně řeší, protože to hodnoty pro výpočet generuje až když jsou třeba.
Osobně si myslím, že tvrzení, že Python je pomalý není moc moudré. Když se budeme bavit o konkrétní implementaci jazyka, to už pravda být může (CPython pro konkrétní zpatlaný algoritmus), ale nemusí (PyPy) či vhodně zvolený algoritmus a možnosti dané implementace (xrange, numpy, sum+xrange).
Docela by mohlo být zajímavé, jak by se to měnilo s výpočty ve floating point (a tady by si obdobné zadání ve FP říkalo o prohnání např. přes OpenCL ap. a pak už je jazyk irelevantní, vše to bude jen lepidlo pro HW akcelerovaný běh).
-
Jako ja nevim, ale normalni Python je malokdy rychlejsi, nez Java, vetsinou i o rady pomalejsi - https://benchmarksgame.alioth.debian.org/u64q/python.html.
Tohle bych nečekal http://benchmarksgame.alioth.debian.org/u64q/php.html
Njn, když ono je to s těmi testy takové ošidné. Když bych měl parafrázovat: Nevěřím žádnému benchmarku, který jsem si sám nezfalšoval...
Kupříkladu:
....
Konecne hezky priklad pro vsechny benchmark fany. Nerikam ze je Java vyslovene spatna, taky mne z velke casti zivi, ale pokud potrebuje clovek opravdu vykon, tak se to neda s C/C++ srovnavat. A pokud ano, tak je s optimalizacema nasobne vice prace a mnohem neprehlednejsi kod, nez v C++.
-
Pokud vim, tak postovane benchmarky nepodvadi outsourcovanim provadeni opraci do asm/c/c++ knihoven, jako tvuj kod ;).
PS: Java snad nema specializovane matematicke knihovny? ;D
-
Njn, když ono je to s těmi testy takové ošidné. Když bych měl parafrázovat: Nevěřím žádnému benchmarku, který jsem si sám nezfalšoval...
Kupříkladu:
C
#include <stdio.h>
int main ()
{
long a;
long sum = 0;
for( a = 0; a < 200000000; a++ )
{
sum += a;
}
printf("sum: %ld\n", sum);
return 0;
}
Tak tenhle benchmark sis zfalšoval opravdu hezky. Viděl jsi assembler, který gcc vygeneruje?
.cfi_startproc
subq $8, %rsp
.cfi_def_cfa_offset 16
movabsq $19999999900000000, %rsi
movl $.LC0, %edi
xorl %eax, %eax
call printf
Ten cyklus se vyhodnotí během kompilace a nic se nepočítá. Takový syntetický příklad je ale úplně k ničemu. Zkus si místo konstanty načíst horní mez cyklu ze vstupu a bude to vypadat úplně jinak.
-
Pokud vim, tak postovane benchmarky nepodvadi outsourcovanim provadeni opraci do asm/c/c++ knihoven, jako tvuj kod ;).
PS: Java snad nema specializovane matematicke knihovny? ;D
1. Téma této diskuse se týká Pythonu, ne Javy
2. Pointa příspěvku nebyla ohledně toho co má který jazyk, ale ohledně toho, jak to je s benchmarky
-
Pokud vim, tak postovane benchmarky nepodvadi outsourcovanim provadeni opraci do asm/c/c++ knihoven, jako tvuj kod ;).
PS: Java snad nema specializovane matematicke knihovny? ;D
1. Téma této diskuse se týká Pythonu, ne Javy
2. Pointa příspěvku nebyla ohledně toho co má který jazyk, ale ohledně toho, jak to je s benchmarky
Nasel jsi snad nejaky podobne zavadny kod, jako jsi napsal, v te benchmarksgame? V opacnem pripade tvuj prispevek nema zadnou pointu, protoze asi vsichni vi, ze podvadet se da :).
-
Njn, když ono je to s těmi testy takové ošidné. Když bych měl parafrázovat: Nevěřím žádnému benchmarku, který jsem si sám nezfalšoval...
Kupříkladu:
C
#include <stdio.h>
int main ()
{
long a;
long sum = 0;
for( a = 0; a < 200000000; a++ )
{
sum += a;
}
printf("sum: %ld\n", sum);
return 0;
}
Tak tenhle benchmark sis zfalšoval opravdu hezky. Viděl jsi assembler, který gcc vygeneruje?
.cfi_startproc
subq $8, %rsp
.cfi_def_cfa_offset 16
movabsq $19999999900000000, %rsi
movl $.LC0, %edi
xorl %eax, %eax
call printf
Ten cyklus se vyhodnotí během kompilace a nic se nepočítá. Takový syntetický příklad je ale úplně k ničemu. Zkus si místo konstanty načíst horní mez cyklu ze vstupu a bude to vypadat úplně jinak.
Ano, přesně to jsem napsal, včetně toho, že to je o několika strojových instrukcích, že? A o tom je pointa mého příspěvku. Jak je to často s těmi benchmarky. Že jsou v podstatě nicneříkající nebo udělané tak, jak se komu hodí do krámu, takže ohánět se jimi je úplně k ničemu. Ke každé části v mém příspěvku se dá namítat. Protože je téma diskuze ohledně Pythonu, jsou námitky převážně rozvinuty v příspěvku na něm.
Neříkejte, že vám přece jen uchází pointa, že to není o language war, ale upozornění na to, jak je to s benchmarky.
-
Ta benchmarks game se snazi implementovat realne algoritmy a kod, ktery tam je, je od profiku v danych jazycich.
Moje pointa je, ze pokud neco naimplementujete naivne v Jave a pustite to na defaultnim JVM, tak to pojede mnohem rychleji (klidne o rady), nez kdyz udelate to stejne naivne v Pythonu a pustite defaultnim interpreterem.
A to si myslim i odrazi dost tech "zpackanych" benchmarku valejicich se na blozich, proste pokud chcete vykon v Pythonu stejny, jako dostanete bez prace v Jave, musite vynalozit specialni usili - napr. prepsat cast aplikace aby pouzivala externi knihovnu, prekladat to necim specialnim atp.
Co jsem cetl, tak pomalost Javy oproti C++ je pouze v pripade malych projektu - kdyz JIT jede dlouho nad velkymi enterprise vecmi, tak pry bezne dosahuje lepsiho vykonu, nez C++, protoze dynamicky provadi mnohem vice pokrocilych optimalizaci podle hotspotu v dobe behu, ne jen pri kompilaci nebo provadeni jedne ulohy (na to je C++ rozhodne lepsi). To je duvod, proc se to pouziva na ty obrovske veci - (relativne) jednoduchy velmi rozsireny jazyk + solidni vykon.
-
Pokud vim, tak postovane benchmarky nepodvadi outsourcovanim provadeni opraci do asm/c/c++ knihoven, jako tvuj kod ;).
PS: Java snad nema specializovane matematicke knihovny? ;D
1. Téma této diskuse se týká Pythonu, ne Javy
2. Pointa příspěvku nebyla ohledně toho co má který jazyk, ale ohledně toho, jak to je s benchmarky
Nasel jsi snad nejaky podobne zavadny kod, jako jsi napsal, v te benchmarksgame? V opacnem pripade tvuj prispevek nema zadnou pointu, protoze asi vsichni vi, ze podvadet se da :).
A vy jste si prošel ty kódy, udělal testy a nic jste v nich nenašel? Jestli jste to neudělal, jakou pointu má váš příspěvek?
Já si se svým příspěvkem práci dal a pointa z něj vyplývá doufám dobře. A podle reakcí ji zdá se ji vidí i jiní...
-
Ta benchmarks game se snazi implementovat realne algoritmy a kod, ktery tam je, je od profiku v danych jazycich.
Moje pointa je, ze pokud neco naimplementujete naivne v Jave a pustite to na defaultnim JVM, tak to pojede mnohem rychleji (klidne o rady), nez kdyz udelate to stejne naivne v Pythonu a pustite defaultnim interpreterem.
A to si myslim i odrazi dost tech "zpackanych" benchmarku valejicich se na blozich, proste pokud chcete vykon v Pythonu stejny, jako dostanete bez prace v Jave, musite vynalozit specialni usili - napr. prepsat cast aplikace aby pouzivala externi knihovnu, prekladat to necim specialnim atp.
Co jsem cetl, tak pomalost Javy oproti C++ je pouze v pripade malych projektu - kdyz JIT jede dlouho nad velkymi enterprise vecmi, tak pry bezne dosahuje lepsiho vykonu, nez C++, protoze dynamicky provadi mnohem vice pokrocilych optimalizaci podle hotspotu v dobe behu, ne jen pri kompilaci nebo provadeni jedne ulohy (na to je C++ rozhodne lepsi). To je duvod, proc se to pouziva na ty obrovske veci - (relativne) jednoduchy velmi rozsireny jazyk + solidni vykon.
Opět bych mohl reagovat mým příspěvkem. Stále uchází pointa... S části se s tím co píšete souhlasit dá, v zásadě nejsem proti, ale říkáte to způsobem, kterým to tlačíte jednostranně směrem, který se vám hodí a tím to kroutíte a ohýbáte. Celkový obraz je jiný.
Python vs implementace Pythonu (jsou i implementace běžící nad JVM)
Rychlost Javy (JVM) vs GUI apky v Javě
atd. viz. můj příspěvek... Už to bylo řečeno.
PS: Osobně nemám nic proti Javě, Pythonu ani C ;-). Ohledně PHP už by to bylo složitější, a to jsem v tom napsal takovou hromadu věcí, až to hezké není :)
-
A vy jste si prošel ty kódy, udělal testy a nic jste v nich nenašel? Jestli jste to neudělal, jakou pointu má váš příspěvek?
Já si se svým příspěvkem práci dal a pointa z něj vyplývá doufám dobře. A podle reakcí ji zdá se ji vidí i jiní...
Ta pointa uvedených benchmarků je naprosto skvělá.
Navíc příklady v běžných benchmarcích jsou silně umělé. Nikdo přece nebude chtít sečítat čísla 1..N nebo implementovat nějaký sort v Pythonu, že?
-
Neříkejte, že vám přece jen uchází pointa, že to není o language war, ale upozornění na to, jak je to s benchmarky.
Bohužel pointa uchází tobě, tvrdíš, že jsou benchmarky k ničemu a sám vyrobíš benchmark, který je naprosto úplně mimo a vyvozuješ z něho závěry o kosmické rychlosti C oproti jiným jazykům.
-
Neříkejte, že vám přece jen uchází pointa, že to není o language war, ale upozornění na to, jak je to s benchmarky.
Bohužel pointa uchází tobě, tvrdíš, že jsou benchmarky k ničemu a sám vyrobíš benchmark, který je naprosto úplně mimo a vyvozuješ z něho závěry o kosmické rychlosti C oproti jiným jazykům.
Tak tyhle závěry jste si vyvodil sám. Já vůbec ne. Já upozorňoval na to, jak je to s benchmarky. Nedělal jsem z toho závěry. Můj příspěvek je o tom, jak se dají věci ohýbat v benchmarcích. Nehodnotil jsem ani jednotlivé jazyky ani ohledně nich nedělal závěr. Jen jsem je použil na demonstraci toho, jak je to se syntetickými benchmarky tak, aby to bylo zřetelně vidět. Pokud to stále nechápete, tak už nevím jak vám to mám vysvětlit...
-
Tak tyhle závěry jste si vyvodil sám. Já vůbec ne. Já upozorňoval na to, jak je to s benchmarky. Nedělal jsem z toho závěry. Můj příspěvek je o tom, jak se dají věci ohýbat v benchmarcích. Nehodnotil jsem ani jednotlivé jazyky ani ohledně nich nedělal závěr. Jen jsem je použil na demonstraci toho, jak je to se syntetickými benchmarky tak, aby to bylo zřetelně vidět. Pokud to stále nechápete, tak už nevím jak vám to mám vysvětlit...
Takže tvrdíš, že benchmarky na benchmarksgame jsou podobně vadné, jako ten tvůj benchmark? Po pravdě nevím, co se snažíš říct. Že se dá bechmark udělat úplně blbě a je naprosto nevypovídající? To všichni víme. Jsou takové i benchmarky na benchmarksgame? Nemyslím si.
-
Neříkejte, že vám přece jen uchází pointa, že to není o language war, ale upozornění na to, jak je to s benchmarky.
Bohužel pointa uchází tobě, tvrdíš, že jsou benchmarky k ničemu a sám vyrobíš benchmark, který je naprosto úplně mimo a vyvozuješ z něho závěry o kosmické rychlosti C oproti jiným jazykům.
Tak tyhle závěry jste si vyvodil sám. Já vůbec ne. Já upozorňoval na to, jak je to s benchmarky. Nedělal jsem z toho závěry. Můj příspěvek je o tom, jak se dají věci ohýbat v benchmarcích. Nehodnotil jsem ani jednotlivé jazyky ani ohledně nich nedělal závěr. Jen jsem je použil na demonstraci toho, jak je to se syntetickými benchmarky tak, aby to bylo zřetelně vidět. Pokud to stále nechápete, tak už nevím jak vám to mám vysvětlit...
Uz to pisu ponekolikate, benchmarksgame se prave snazi nemit umele ukoly navrzene pro vyhru jednoho jazyka/prekladace/interpretu - ty algoritmy pocitaji vetsinou i neco smysluplneho a ne uplne trivialniho, takze je tam prostor pro optimalizace na strane prekladace/VM. Rozhodne se tam nedeje, ze prekladac vse vypocita v dobe prekladu a vysledny program provadi jen vypis vysledku :D.
PS: Ja Python, prestoze se mi jako jazyk moc nelibi a mnohem radeji mam Ruby, respektuji. Na skriptovani jeho misto chapu. Ale stejne jako si myslim, ze JavaScript/Ruby/Bash/PowerShell neni vhodny na psani weboveho backendu (a obecne jakehokoliv projektu s LOC v tisicich), tak si to stejne myslim o Pythonu. Vim, ze dost lidi nesouhlasi, ale ja preferuji automatickou typovou kontrolu od prekladace a ne manualni smoleni testu vyvazujici chybejici typovou kontrolu.
-
Tak tyhle závěry jste si vyvodil sám. Já vůbec ne. Já upozorňoval na to, jak je to s benchmarky. Nedělal jsem z toho závěry. Můj příspěvek je o tom, jak se dají věci ohýbat v benchmarcích. Nehodnotil jsem ani jednotlivé jazyky ani ohledně nich nedělal závěr. Jen jsem je použil na demonstraci toho, jak je to se syntetickými benchmarky tak, aby to bylo zřetelně vidět. Pokud to stále nechápete, tak už nevím jak vám to mám vysvětlit...
Takže tvrdíš, že benchmarky na benchmarksgame jsou podobně vadné, jako ten tvůj benchmark? Po pravdě nevím, co se snažíš říct. Že se dá bechmark udělat úplně blbě a je naprosto nevypovídající? To všichni víme. Jsou takové i benchmarky na benchmarksgame? Nemyslím si.
Hele ty nerudný človíčku, buď té lásky a běž si vkládat slova do úst někomu jinému. Tenhle způsob diskuze mě nebere. Díky.
-
Hele ty nerudný človíčku, buď té lásky a běž si vkládat slova do úst někomu jinému. Tenhle způsob diskuze mě nebere. Díky.
Jen se snažím dobrat smyslu toho tvého "benchmarku", ale asi se mi to nepodaří...
-
Hele ty nerudný človíčku, buď té lásky a běž si vkládat slova do úst někomu jinému. Tenhle způsob diskuze mě nebere. Díky.
Jen se snažím dobrat smyslu toho tvého "benchmarku", ale asi se mi to nepodaří...
Potřetí a naposled: Smysl mého PŘÍSPĚVKU je o tom, že se snažím upozornit, že benchmarky mají často špatnou vypovídací hodnotu, že se s výsledky dá velmi snadno ohýbat, že je to často porovnávání hrušek s jablky, že teoreticky je teorie a praxe to samé, ale prakticky to tak není atd. atp.
Napadá vás všechno možné, jen ne to, o čem můj příspěvek je.
-
Všem milovníkům benchmarků doporučuji prostudovat následující stránky:
https://www.techempower.com/benchmarks/
Jen aby se vám z toho ale nezamotala hlava. :) Ten tolikrát vychvalovaný Spring v o několik řádů rychlejší Javě je v něm totiž například pomalejší než flask s Pythonem. A to se bavíme o reálných problémech webového backendu, žádné syntetické přičítání jedničky. Jsou tam i zdrojové kódy, tak můžete začít hledat, kde soudruzi udělali chybu a přidat vlastní verzi, která tomu Pythonu natře zadek.. :D
Tak se ukažte, jestli máte svaly i někde jinde než pod jazykem.
P.S.: Tahle diskuse mi připomíná souboje děcek v mateřské školce. Slovní spojení jako brutálně rychlá java, o několik řádů rychlejší, atd jsou zpravidla v praxi naprosto nesmyslné. Pokud si pro svůj problém náhodou nevyberete opravdu nevhodný nástroj, jsou rozdíly mezi jednotlivými jazyky zpravidla do jednoho řádu, často ještě mnohem menší a v nemálo případech o nich rozhoduje především kvalita knihoven. Tiše se tak pomíjí skutečnost, že nevhodné zpracování problému programátorem (které je v praxi naprosto běžné) klidně způsobí 100 násobné zpomalení výsledného programu, takže zvolený jazyk/framework je téměř irelevatní.
-
Všem milovníkům benchmarků doporučuji prostudovat následující stránky:
https://www.techempower.com/benchmarks/
Jen aby se vám z toho ale nezamotala hlava. :) Ten tolikrát vychvalovaný Spring v o několik řádů rychlejší Javě je v něm totiž například pomalejší než flask s Pythonem. A to se bavíme o reálných problémech webového backendu, žádné syntetické přičítání jedničky. Jsou tam i zdrojové kódy, tak můžete začít hledat, kde soudruzi udělali chybu a přidat vlastní verzi, která tomu Pythonu natře zadek.. :D
Tak se ukažte, jestli máte svaly i někde jinde než pod jazykem.
P.S.: Tahle diskuse mi připomíná souboje děcek v mateřské školce. Slovní spojení jako brutálně rychlá java, o několik řádů rychlejší, atd jsou zpravidla v praxi naprosto nesmyslné. Pokud si pro svůj problém náhodou nevyberete opravdu nevhodný nástroj, jsou rozdíly mezi jednotlivými jazyky zpravidla do jednoho řádu, často ještě mnohem menší a v nemálo případech o nich rozhoduje především kvalita knihoven. Tiše se tak pomíjí skutečnost, že nevhodné zpracování problému programátorem (které je v praxi naprosto běžné) klidně způsobí 100 násobné zpomalení výsledného programu, takže zvolený jazyk/framework je téměř irelevatní.
Souhlas. Ve webových aplikacích je bottleneck většinou databáze. Backendový jazyk je jen lepidlo, které v jednom requestu nikdy nezpracovává víc dat než se zobrazí na stránku. Rychlost jazyka většinou nemá cenu řešit. Naopak, u skriptovacích jazyků je příjemná nízká paměťová náročnost a rychlý start. O rychlost běhu tolik nejde.
-
A srovnavate srovnatelne? Neznam ani jedno, ale opravdu umi Flask to stejne, co Spring?
Ale to jsem psal vyse, pokud mate stejne neschopne programatory pouzivajici stejne defaultni prostredi a doprasi to stejne, tak v Jave to vetsinou pobezi rychlej (asi kvuli JITu), nez v Pythonu. Take pokud prasite, tak v Jave jste alespon svazani typy, v Pythonu (stejne jako v JavaScriptu), pokud si vzpominam spravne, nic takoveho neni a mate o dalsi problem navic (typy), co musite pro kazdy kus kodu testovat.
Souhlasim, ze na male veci je to opravdu skvele, protoze se v tom rychle vyviji (Python, Ruby, JavaScript). Dokud mate v hlave cely mentalni model aplikace, tak je to zuzo. Ale jak tu nekdo jiny psal (Javaman?), tak na ty opravdu velke veci je to IMO nevhodne, protoze musite cim dal vic resit absenci formalnich kontraktu, ktere ve staticky typovanych jazycich kontroluje automaticky prekladac a proste kdyz to API porusite, tak se to neprelozi a pres to vlak nejede. V Pythonu/Ruby/JS se to vesele spusti a pokud nepisete opravdu dusledne unit testy, tak na tyto zaludnosti budete narazet cim dal casteji, jak se projekt refaktoruje, jak se meni pozadavky (ano, realnemu projektu se meni pozadavky neustale), jak se opravuji chyby a zanasejici se tak dalsi chyby, atd. Pokud nevenujete cas tem unit a dalsim testum, tak za chvili z toho mate minove pole, kde se kazdy z tymu boji cokoliv refaktorovat, aby nerozbil desitky souvisejicich veci, nove feature se placaji do stavajiciho kodu tak, aby se co nejmene upravoval stavajici a vznika z toho neudrzovatelny propletenec.
PS: K tomu PHP, to take nemusim. Jazyk "vyvijeny" clovekem, ktery nezna zaklady CS. Nekonzistentni pojmenovani a chovani funkci v std lib, vecne zbugovany parser (to mozna uz konecne zvladli v 7 opravit, nevim, moc optimisticky nejsem), nastaveni rozeste na nekolika mistech, nelogicky podmineny vyraz a mnoho dalsich vychytavek. A nez nekdo napise, ze se v tom bezne vyviji, tak to asi nemuze byt tak spatne - ano, ale musite dodrzovat seznam zakazanych vlastnosti jazyka, ktery je oproti jinym jazykum dost objemny. Kdyby se enterprise veci programovaly v BrainFucku, tak taky nebudu trvrdit, ze asi nemuze byt tak spatny, kdyz se v tom delaji mega veci.
-
A srovnavate srovnatelne? Neznam ani jedno, ale opravdu umi Flask to stejne, co Spring?
Neumí a je to dobře.
Ale to jsem psal vyse, pokud mate stejne neschopne programatory pouzivajici stejne defaultni prostredi a doprasi to stejne, tak v Jave to vetsinou pobezi rychlej (asi kvuli JITu), nez v Pythonu.
Jak jsem psal výše, webové aplikace toho většinou moc nedělají. Maximálně na něco čekají. V tom případě pomůže použít neblokující framework. Například Paypal přešel od Javy k NodeJS https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/. Použití rychlejšího jazyka většinou nepomůže. Ten benchmark dává smysl jen pokud používáte nějaké opravdu rychlé uložiště jako Redis.
-
Souhlas. Ve webových aplikacích je bottleneck většinou databáze. Backendový jazyk je jen lepidlo, které v jednom requestu nikdy nezpracovává víc dat než se zobrazí na stránku. Rychlost jazyka většinou nemá cenu řešit. Naopak, u skriptovacích jazyků je příjemná nízká paměťová náročnost a rychlý start. O rychlost běhu tolik nejde.
Aha, vy stale mluvite pouze o CRUD? Na to ale snad neni ani potreba specialni BE a staci nejake hotove reseni typu "Backend as a Service". Treba projekt, na kterem nyni pracuji, ma webovy rypak a rozhodne to neni jen a pouze CRUD - podle nejakeho algoritmu se ruzne updatuji tabulky a synchronizuje se to s dalsi sluzbou podle toho, jake uzivatel udela zmeny.
Pametova nenarocnost po startu IMO neni zadna vyhoda v pripade enterprise veci, kde za cenu dne prace vyvojare muzu poridit dalsi pakl pameti do servru. A i kdyby JVM potrebovalo 1GB pro start, coz realne nepotrebuje, tak to v prepoctu ta pamet vyjde na par stovek, to se asi bavime o nejakych pidi projekticich, kdyz se resi kazdy megabajt pameti zabirany VM, ktery se navic nezvetsuje s pametovymi pozadavky aplikace... Rychly start to stejne (v benchmarksgame to merili a bylo to tusim spise par stovek milisekund) - co je par (i kdyby desitek) sekund proti uptimu servru a aplikace? Pokud je navic start kriticky, tak se proste prihodi SSD nebo se udela nejaka magie s hotswapovanim trid. Jedina situace, kde to je opravdu vyhoda, jsou shell skripty*, ale tady se bavime o backendu webove aplikace a od te se neocekava, ze se bude spoustet vicekrat nez (strelim od pasu, realne asi jeste mene casto) jednou za tyden.
*: I to ale lze resit, existuje napr. NailGun, ktery udrzuje "zhave" JVM a spoustenou aplikaci mu jen prideli, takze start aplikace je instantni (po skonceni behu aplikace se JVM recykluje).
Nevim, ja osobne, pokud bych vybiral jazyk pro projekt, ktery bude mit odhadovanych par tisic LOC, zivotnost delsi nez par mesicu a potencionalne ho budou vyuzivat treba tisice lidi, tak radeji zvolim Javu (nebo neco nad JVM, v horsim pripade .NET + C#), nez to pak zpetne cele prepisovat z Pythonu a v podstate to tak implementovat nadvakrat.
-
Take pokud prasite, tak v Jave jste alespon svazani typy,...
..., protoze musite cim dal vic resit absenci formalnich kontraktu, ktere ve staticky typovanych jazycich kontroluje automaticky prekladac...
... jak se projekt refaktoruje, jak se meni pozadavky...
PS: K tomu PHP,... A nez nekdo napise, ze se v tom bezne vyviji, tak to asi nemuze byt tak spatne - ano, ale musite dodrzovat seznam zakazanych vlastnosti jazyka, ktery je oproti jinym jazykum dost objemny.
V PHP je také možné (nikoli nutné) vytvářet formální kontrakty a typové vazby.
Těch zakázaných vlastností jazyka PHP není mnoho. Žádné z běžně uváděných jsem nikdy neměl potřebu použít. Stačí programovat normálně. Jazyky C/C++ jsou jako minová pole mnohem záludnější.
Je zvláštní, jak mnoho lidí vkládá pojmy refaktorování a redesign do jedné věty, i když jsou to odlišné záležitosti, které se řeší samostatně.
-
Aha, vy stale mluvite pouze o CRUD? Na to ale snad neni ani potreba specialni BE a staci nejake hotove reseni typu "Backend as a Service". Treba projekt, na kterem nyni pracuji, ma webovy rypak a rozhodne to neni jen a pouze CRUD - podle nejakeho algoritmu se ruzne updatuji tabulky a synchronizuje se to s dalsi sluzbou podle toho, jake uzivatel udela zmeny.
Podle popisu je ten projekt stále jen CRUD.
-
Aha, vy stale mluvite pouze o CRUD? Na to ale snad neni ani potreba specialni BE a staci nejake hotove reseni typu "Backend as a Service". Treba projekt, na kterem nyni pracuji, ma webovy rypak a rozhodne to neni jen a pouze CRUD - podle nejakeho algoritmu se ruzne updatuji tabulky a synchronizuje se to s dalsi sluzbou podle toho, jake uzivatel udela zmeny.
Existuje nějaký Backend as a Service, který zpřístupňuje plnohodnotné SQL? Podle mne to z hlediska bezpečnosti není možné.
-
Pametova nenarocnost po startu IMO neni zadna vyhoda v pripade enterprise veci, kde za cenu dne prace vyvojare muzu poridit dalsi pakl pameti do servru. A i kdyby JVM potrebovalo 1GB pro start, coz realne nepotrebuje, tak to v prepoctu ta pamet vyjde na par stovek, to se asi bavime o nejakych pidi projekticich, kdyz se resi kazdy megabajt pameti zabirany VM, ktery se navic nezvetsuje s pametovymi pozadavky aplikace... Rychly start to stejne (v benchmarksgame to merili a bylo to tusim spise par stovek milisekund) - co je par (i kdyby desitek) sekund proti uptimu servru a aplikace? Pokud je navic start kriticky, tak se proste prihodi SSD nebo se udela nejaka magie s hotswapovanim trid. Jedina situace, kde to je opravdu vyhoda, jsou shell skripty*, ale tady se bavime o backendu webove aplikace a od te se neocekava, ze se bude spoustet vicekrat nez (strelim od pasu, realne asi jeste mene casto) jednou za tyden.
*: I to ale lze resit, existuje napr. NailGun, ktery udrzuje "zhave" JVM a spoustenou aplikaci mu jen prideli, takze start aplikace je instantni (po skonceni behu aplikace se JVM recykluje).
Rozhodně je příjemnější když tyhle problémy řešit nemusíte.
-
1. prgate rest v pythone / ruby / php.
2. tesite sa lebo zerete malo ram
3. pride 50k userov
4. server hori
5. skalujete = prepisujete do jvm / .net
-
1. prgate rest v pythone / ruby / php.
2. tesite sa lebo zerete malo ram
3. pride 50k userov
4. server hori
5. skalujete = prepisujete do jvm / .net
Pokud mi aplikace přitáhne 50k uživatelů, tak mě nebude škálování vůbec trápit, prostě ho udělám. Samozřejmě ho nebudu dělat vertikálně přepisem do JVM/.NET, ale horizontálně přidáním dalšího nodu.
-
1. prgate rest v pythone / ruby / php.
2. tesite sa lebo zerete malo ram
3. pride 50k userov
4. server hori
5. skalujete = prepisujete do jvm / .net
Nevim, ja osobne, pokud bych vybiral jazyk pro projekt, ktery bude mit odhadovanych par tisic LOC, zivotnost delsi nez par mesicu a potencionalne ho budou vyuzivat treba tisice lidi, tak radeji zvolim Javu (nebo neco nad JVM, v horsim pripade .NET + C#), nez to pak zpetne cele prepisovat z Pythonu a v podstate to tak implementovat nadvakrat.
No vidíte, a přitom existují obří firmy s tisíci vývojáři, kteří opouštějí .NET/Javu a přechází třeba na node.js nebo Go.
Tady je zrovna aktuální článek:
https://blog.risingstack.com/node-js-examples-how-enterprises-use-node-in-2016/
To není nic proti .NET/Jave, jen chci ukázat, že existují firmy které se (určitě po zvážení všech hledisek) rozhodnou opustit .NET nebo Javu a vydat se směrem k nové platformě. A pokud tady v diskusi od některých zaznělo, že cokoliv skriptovacího je tak akorát na 200 řádkový skript, tak tyto firmy ukazují, že ony si to nemyslí. Taky se tady někteří chvástali 300kLOC programy. Nic proti, i takové jsou potřeba, jen si nemyslím, že počet řádků kódu je měřítkem čehokoliv. Možná jen managor má dobrý pocit, že za ty vyplacené peníze má něco, co může vykázat. Ale nabízí se otázka: nežije architekt této aplikace někde v roce 1995? Kdo bude tuto aplikaci udržovat, jak se bude reagovat na měnící se podmínky. Dnes se aplikace píší jinak, vytváří se malé týmy a každý pracuje nad samostatným problémem.
Osobně si myslím, že statické typování má velký význam, ale na druhou stranu si nemyslím, že je to spása na všechny problémy. Pokud tady někteří propagují, že se statickým typováním nemusí psát unit testy, tak to je naprosté nepochopení funkce unit testů.
-
No vidíte, a přitom existují obří firmy s tisíci vývojáři, kteří opouštějí .NET/Javu a přechází třeba na node.js nebo Go.
to je pravda
node.js tiez neriesi ramku :-)
-
1. prgate rest v pythone / ruby / php.
2. tesite sa lebo zerete malo ram
3. pride 50k userov
4. server hori
5. skalujete = prepisujete do jvm / .net
Tak prvně nebudu blbec a nebudu mít web od kterého něco čekám jen na jednom stroji, ale budu ho mít nejlépe navržen tak, aby mohl běžet v clusteru, kde na větší zátěž zareaguju tak, že přidám další node. Nebo se mě to nebude chtít řešit a šáhnu po nějakém hotovém řešení, nebo na to celé budu kašlat nechám to na jednom stroji a budu si pak nadávat že sem osel. Zvolenej jazyk mě tenhle problém možná oddálí, že chudák jeden server utáhne víc lidí, ale rozhodně nevyřeší.
-
Například Paypal přešel od Javy k NodeJS https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/. Použití rychlejšího jazyka většinou nepomůže. Ten benchmark dává smysl jen pokud používáte nějaké opravdu rychlé uložiště jako Redis.
Zrovna nedavno jsem nekde cetl, ze NodeJS je neuveritelny hype a ze v JVM svete vsechny veci, co umi, davno existuji (nemam zkusenosti, ale neni treba Spring Reactor v podstate ten stejny princip?).
IMO takova Scala + Akka je mnohem lepsi pristup - out-of-box se to da skalovat jak do vice vlaken (podobne jako cluster s NodeJS, akorat bez nutnosti zpetne resit IPC, protoze aktori z principu pouzivaji zpravy) tak na vice stroju (to uz netusim, jestli v NodeJS nejak lehce jde).
Pametova nenarocnost po startu IMO neni zadna vyhoda v pripade enterprise veci, kde za cenu dne prace vyvojare muzu poridit dalsi pakl pameti do servru. A i kdyby JVM potrebovalo 1GB pro start, coz realne nepotrebuje, tak to v prepoctu ta pamet vyjde na par stovek, to se asi bavime o nejakych pidi projekticich, kdyz se resi kazdy megabajt pameti zabirany VM, ktery se navic nezvetsuje s pametovymi pozadavky aplikace... Rychly start to stejne (v benchmarksgame to merili a bylo to tusim spise par stovek milisekund) - co je par (i kdyby desitek) sekund proti uptimu servru a aplikace? Pokud je navic start kriticky, tak se proste prihodi SSD nebo se udela nejaka magie s hotswapovanim trid. Jedina situace, kde to je opravdu vyhoda, jsou shell skripty*, ale tady se bavime o backendu webove aplikace a od te se neocekava, ze se bude spoustet vicekrat nez (strelim od pasu, realne asi jeste mene casto) jednou za tyden.
*: I to ale lze resit, existuje napr. NailGun, ktery udrzuje "zhave" JVM a spoustenou aplikaci mu jen prideli, takze start aplikace je instantni (po skonceni behu aplikace se JVM recykluje).
Rozhodně je příjemnější když tyhle problémy řešit nemusíte.
Toz zmeril jsem to a hello world vychazi takto:
OpenJDK 1.8 - 17MB
Python 2.7.5 - 4MB
VPS se snad bezne ani po par mega pameti stelovat neda, takze tu nevidim zadne problemy k reseni - proste placnu minimalnich 1GB a ono to svete div se staci i pro Javu.
Aha, vy stale mluvite pouze o CRUD? Na to ale snad neni ani potreba specialni BE a staci nejake hotove reseni typu "Backend as a Service". Treba projekt, na kterem nyni pracuji, ma webovy rypak a rozhodne to neni jen a pouze CRUD - podle nejakeho algoritmu se ruzne updatuji tabulky a synchronizuje se to s dalsi sluzbou podle toho, jake uzivatel udela zmeny.
Podle popisu je ten projekt stále jen CRUD.
Hmm, takze desitky minut pocitani pomoci nejakeho proprietarniho algoritmu je podle vas CRUD jak vysity? Tak to asi vlastne nemame jine ulohy nez CRUD, kdyz kazdy ukol musi data cist a plivat => CRUD, ze? :D Ne, databaze to opravdu nepocita...
No vidíte, a přitom existují obří firmy s tisíci vývojáři, kteří opouštějí .NET/Javu a přechází třeba na node.js nebo Go.
Tady je zrovna aktuální článek:
https://blog.risingstack.com/node-js-examples-how-enterprises-use-node-in-2016/
A taky existuji firmy jako Twitter, kteri presli z duvodu vykonu k JVM. Ja nerikam, ze to nejde delat v NodeJS, jen ze si myslim, ze je to spatny nastroj, pro vyvoj "ve velkem".
Osobně si myslím, že statické typování má velký význam, ale na druhou stranu si nemyslím, že je to spása na všechny problémy. Pokud tady někteří propagují, že se statickým typováním nemusí psát unit testy, tak to je naprosté nepochopení funkce unit testů.
Jestli to "nekteri" je na mne, tak ja nepsal, ze staticke typovani plne nahrazuje unit testy. Ja psal, ze bez statickeho typovani musite psat testu mnohem vice, testu, ktere by se psat manualne nemuseli, kdyby se pouzil staticky jazyk.
-
Taky se tady někteří chvástali 300kLOC programy. Nic proti, i takové jsou potřeba, jen si nemyslím, že počet řádků kódu je měřítkem čehokoliv.
Většinu takových aplikací, které se mi dostanou pod ruku, zkracuji na cca třetinu pouhým refaktorováním. To by člověk nevěřil, kolik zbytečností a duplicit se v nich obvykle nachází.
Osobně si myslím, že statické typování má velký význam, ale na druhou stranu si nemyslím, že je to spása na všechny problémy. Pokud tady někteří propagují, že se statickým typováním nemusí psát unit testy, tak to je naprosté nepochopení funkce unit testů.
Statické typování má velký význam, pokud se neomezuje na číselné a řetězcové typy, což bývá bohužel velmi časté.
Hezky je to vidět na Haskellu. Pokud někdo napíše typovou deklaraci
funkce :: Int -> Int -> Int -> Inttak to neříká prakticky nic o tom, co ta funkce dělá a co je jejími parametry. Autor místo toho, aby nahradil "Int" tím správným typem, to popíše do zbytečných komentářů.
-
Aha, vy stale mluvite pouze o CRUD? Na to ale snad neni ani potreba specialni BE a staci nejake hotove reseni typu "Backend as a Service". Treba projekt, na kterem nyni pracuji, ma webovy rypak a rozhodne to neni jen a pouze CRUD - podle nejakeho algoritmu se ruzne updatuji tabulky a synchronizuje se to s dalsi sluzbou podle toho, jake uzivatel udela zmeny.
Podle popisu je ten projekt stále jen CRUD.
Hmm, takze desitky minut pocitani pomoci nejakeho proprietarniho algoritmu je podle vas CRUD jak vysity? Tak to asi vlastne nemame jine ulohy nez CRUD, kdyz kazdy ukol musi data cist a plivat => CRUD, ze? :D Ne, databaze to opravdu nepocita...
Stále nevidím náznak toho, že by to nebyl jen CRUD. Mezi akcí uživatele a akcí na databázi či dalších službách je jen sada transformačních funkcí.
-
Zrovna nedavno jsem nekde cetl, ze NodeJS je neuveritelny hype a ze v JVM svete vsechny veci, co umi, davno existuji (nemam zkusenosti, ale neni treba Spring Reactor v podstate ten stejny princip?).
IMO takova Scala + Akka je mnohem lepsi pristup - out-of-box se to da skalovat jak do vice vlaken (podobne jako cluster s NodeJS, akorat bez nutnosti zpetne resit IPC, protoze aktori z principu pouzivaji zpravy) tak na vice stroju (to uz netusim, jestli v NodeJS nejak lehce jde).
Hlavní výhoda Node.js je v tom, že v javascriptu jsou všechny knihovny od začátku neblokující a nemusíte se nijak omezovat v tom, co použijete. Třeba v Pythonu při použití něčeho jako Twisted/Tornado/asyncio musíte používat jen knihovny kompatibilní s daným event loopem. Předpokládám, že v tom Spring Reactoru to bude podobné. Akka používá vlákna. Jak jsem psal výše, s takovým přístupem zkušenosti nemám. Asi to bude v něčem lepší a v něčem jiném horší.
-
Akka používá vlákna. Jak jsem psal výše, s takovým přístupem zkušenosti nemám. Asi to bude v něčem lepší a v něčem jiném horší.
Pouziva, ale pokud se nepletu, tak v jednom vlakne bezne bezi mnoho actoru - pouziva take neblokujici pristup. Narozdil od NodeJS ale actori nesdili jeden globalni mega-stav, kazdy ma svuj malicky, a zpravy jsou serializovatelne, takze je velmi jednoduche pridat vice vlaken nebo servru.
-
Akka používá vlákna. Jak jsem psal výše, s takovým přístupem zkušenosti nemám. Asi to bude v něčem lepší a v něčem jiném horší.
Pouziva, ale pokud se nepletu, tak v jednom vlakne bezne bezi mnoho actoru - pouziva take neblokujici pristup. Narozdil od NodeJS ale actori nesdili jeden globalni mega-stav, kazdy ma svuj malicky, a zpravy jsou serializovatelne, takze je velmi jednoduche pridat vice vlaken nebo servru.
Myslel jsem, že Akka používá zelená vlákna o kterých mluvil Mirek Prýmek. Ale není to tak. Máte pravdu, pokud jsem to správně pochopil, blokující kód se v Akka musí obalit Future, aby nezablokoval hlavní vlákno.
-
Akka používá vlákna. Jak jsem psal výše, s takovým přístupem zkušenosti nemám. Asi to bude v něčem lepší a v něčem jiném horší.
Pouziva, ale pokud se nepletu, tak v jednom vlakne bezne bezi mnoho actoru - pouziva take neblokujici pristup. Narozdil od NodeJS ale actori nesdili jeden globalni mega-stav, kazdy ma svuj malicky, a zpravy jsou serializovatelne, takze je velmi jednoduche pridat vice vlaken nebo servru.
Myslel jsem, že Akka používá zelená vlákna o kterých mluvil Mirek Prýmek. Ale není to tak. Máte pravdu, pokud jsem to správně pochopil, blokující kód se v Akka musí obalit Future, aby nezablokoval hlavní vlákno.
Ja myslim, ze hlavni vlakno neblokuje, ale sada aktoru sdili jedno vlakno - muze tedy blokovat jine aktory. Future, co jsem alespon cetl, se moc nedoporucuje a lepsi je pouzivat docasne actory (pripadne v jinem thread poolu blokujici aktory).
Nejvetsi rozdil oproti ostatnim pristupu jeto rozdeleni dat mezi aktory - zadny (nebo minimalni) globalni stav.
-
Jen aby se vám z toho ale nezamotala hlava. :) Ten tolikrát vychvalovaný Spring v o několik řádů rychlejší Javě je v něm totiž například pomalejší než flask s Pythonem. A to se bavíme o reálných problémech webového backendu
Já tam teda vidím Javu na druhém a 5.-8. místě, přičemž se jí tam vetřel jenom Ur (asi málo kdo používá) a C++. První výskyt Pythonu vidím až někde na místě, do kterého se mi nechce počítat. Cca čtyřicátém?
Ty tam vidíš něco jinýho?
-
Jen aby se vám z toho ale nezamotala hlava. :) Ten tolikrát vychvalovaný Spring v o několik řádů rychlejší Javě je v něm totiž například pomalejší než flask s Pythonem. A to se bavíme o reálných problémech webového backendu
Já tam teda vidím Javu na druhém a 5.-8. místě, přičemž se jí tam vetřel jenom Ur (asi málo kdo používá) a C++. První výskyt Pythonu vidím až někde na místě, do kterého se mi nechce počítat. Cca čtyřicátém?
Ty tam vidíš něco jinýho?
Já vidím v původním příspěvku, že je řeč o Spring (na Javě) vs Flash (na Pythonu). Ty tam vidíš něco jiného?
-
Ja myslim, ze hlavni vlakno neblokuje, ale sada aktoru sdili jedno vlakno - muze tedy blokovat jine aktory. Future, co jsem alespon cetl, se moc nedoporucuje a lepsi je pouzivat docasne actory (pripadne v jinem thread poolu blokujici aktory).
Nejvetsi rozdil oproti ostatnim pristupu jeto rozdeleni dat mezi aktory - zadny (nebo minimalni) globalni stav.
Řekl bych, že v téhle oblasti se ty pojmy dost melou a těžko se dá říct něco, co by bylo úplně zjevná ověřitelná pravda :)
Ideální stav je samozřejmě takový, jaký má Erlang, jak jinak ;) - každý actor může mít bez problému vlastní (zelené) vlákno a zároveň jich nemůže mít víc. I tak se ale nedá vyhnout tomu, že actor, který čeká na nějakou externí událost (EDIT: nemusí být ani externí, stačí nekonečný výpočet nebo cyklus vzájemných čekání), může blokovat další actory. Čistě proto, že čekají na zprávu od něj. Pokud čekají synchronně (blokovaně) a bez timeoutu, je z toho deadlock. Pokud s timeoutem, je potřeba nějak ošetřit chybový stav. Pokud čekají asynchronně, je to relativně ok, ale vyžaduje to neúměrné množství logiky kolem zjišťování, na co všechno vlastně ještě čekám, jak dlouho na to mám čekat, co mám udělat, až se to stane atd., takže tohle se uvnitř actoru prakticky vůbec nepoužívá, pokud ta funkcionalita není ze své podstaty asynchronní (není svázaná s žádným stavem, proto si k ní nemusím nic pamatovat, jenom ji odpálím a až přijde odpověď, tak na ni reaguju pořád stejně).
Takže shrnuto podtrženo, ani v (reálně dosažitelném) ideálním stavu nemůžu mít žádné silné garance o tom, že nedojde ke stavu, který si moc nepřeju (deadlock nebo chyba). Čili pokud actory poháním nějakým poolem threadů, může to (imho) fungovat docela dobře, pokud je to dobře navržené a dobře dimenzované.
Typicky i v té první "ideální" situaci chci mít věci, které můžou blokovat, uzavřené do samostatného actoru, takže pokud je tohle řešení doporučované[1] v Akka, není to žádná velká ostuda ;)
[1] http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html#Blocking_Needs_Careful_Management
-
Já vidím v původním příspěvku, že je řeč o Spring (na Javě) vs Flash (na Pythonu). Ty tam vidíš něco jiného?
Kromě toho tam vidím neplatné zobecnění "co platí pro Spring, platí pro Javu". Proto jsem ho korigoval.
-
Já vidím v původním příspěvku, že je řeč o Spring (na Javě) vs Flash (na Pythonu). Ty tam vidíš něco jiného?
Kromě toho tam vidím neplatné zobecnění "co platí pro Spring, platí pro Javu". Proto jsem ho korigoval.
Aha, já to tam nevidím :-)
-
Aha, já to tam nevidím :-)
To se stává, že člověk sem tam něco nevidí.
-
Aha, já to tam nevidím :-)
To se stává, že člověk sem tam něco nevidí.
V téhle diskuzi je to spíš naopak. Že tady často vidí něco co není ;-)
-
Nevíte proč v tom benchmarku zkončil Luminus tak bídně? Zejména v latenci.
-
*skončil
-
Aha, já to tam nevidím :-)
To se stává, že člověk sem tam něco nevidí.
Je komické, že nerozpoznáš parodii na benchmarky...
-
Python má budoucnost. Je tady už dlouho, osvědčil se, je stabilní a spolehlivý, je rozšířený a hodně používaný, neexistuje jediný důvod proč mít obavu o jeho budoucnost s vyhledem na desitky let.
-
Python má budoucnost. Je tady už dlouho, osvědčil se, je stabilní a spolehlivý, je rozšířený a hodně používaný, neexistuje jediný důvod proč mít obavu o jeho budoucnost s vyhledem na desitky let.
To same byl Perl a kde je dnes? Ani pes po nem nestekne.
-
Vlákna by se měla automaticky zamykat, po několika měsících bez nových příspěvků. Vsadil bych se, že to oživování dělá pokaždé stejný člověk pod různými nicky.
-
Python má budoucnost. Je tady už dlouho, osvědčil se, je stabilní a spolehlivý, je rozšířený a hodně používaný, neexistuje jediný důvod proč mít obavu o jeho budoucnost s vyhledem na desitky let.
To same byl Perl a kde je dnes? Ani pes po nem nestekne.
Perl měl hloupou syntaxi.
-
Python má budoucnost. Je tady už dlouho, osvědčil se, je stabilní a spolehlivý, je rozšířený a hodně používaný, neexistuje jediný důvod proč mít obavu o jeho budoucnost s vyhledem na desitky let.
To same byl Perl a kde je dnes? Ani pes po nem nestekne.
Perl měl hloupou syntaxi.
Už ji má chytrou?
-
Python má budoucnost. Je tady už dlouho, osvědčil se, je stabilní a spolehlivý, je rozšířený a hodně používaný, neexistuje jediný důvod proč mít obavu o jeho budoucnost s vyhledem na desitky let.
Dyť to nic neumí, to je tak pro začátečníky. Proto je to tak populární u neprogramátorů. Už to má rozhraní a použitelné IDE?
-
použitelné IDE?
PyCharm je fajn.
-
použitelné IDE?
PyCharm je fajn.
Vyslovujem ako py-šarm. Anglofónna vyslovnosť u kolegov vyvoláva úsmev.
-
použitelné IDE?
PyCharm je fajn.
i kdyz na vim nemam, tak musim uznat ze pycharm je fajn
-
Python zažíva momentálne neskutočný boom. Primárne kvôli machine learning. Etabloval sa tiež ako jazyk
bezpečnostných expertov a pen testerov. Python je vynikajúci aj pre web vývoj (Django, Flask); aj keď nie je tak populárny.
Okrem PyCharmu je skvelým nástrojom aj Visual Studio Code.
-
Python má budoucnost. Je tady už dlouho, osvědčil se, je stabilní a spolehlivý, je rozšířený a hodně používaný, neexistuje jediný důvod proč mít obavu o jeho budoucnost s vyhledem na desitky let.
To same byl Perl a kde je dnes? Ani pes po nem nestekne.
Perl se mi nikdy nelíbil, v něm jsem nic nedělal, imho jeho využití nebylo ani zdaleka tak flexibilní, jako je u pythonu. Python byl už tehdy imho lepší jazyk, proto perl vytlačil i z jeho domény - zpracování textů.
-
Python má budoucnost. Je tady už dlouho, osvědčil se, je stabilní a spolehlivý, je rozšířený a hodně používaný, neexistuje jediný důvod proč mít obavu o jeho budoucnost s vyhledem na desitky let.
Dyť to nic neumí, to je tak pro začátečníky. Proto je to tak populární u neprogramátorů. Už to má rozhraní a použitelné IDE?
Umí toho hodně, je jednoduchý na pochopení, proto je oblíbený u začátečníků a neprogramátorů, ale nejen u nich. Avimho je čím dál použitelnější. Díky cythonu už ani výkon není problém, což podstatně rozšiřuje možnosti jeho využití. Rozhraní to má a IDE nepoužívám, mám radši vim.
-
Python zažíva momentálne neskutočný boom. Primárne kvôli machine learning. Etabloval sa tiež ako jazyk
bezpečnostných expertov a pen testerov. Python je vynikajúci aj pre web vývoj (Django, Flask); aj keď nie je tak populárny.
Okrem PyCharmu je skvelým nástrojom aj Visual Studio Code.
Etabloval se i ve vědě a na akademické půdě, je dobrý na skriptování, psaní drobných aplikací, automatizívání, na drobný web, na vytváření prototypů, na zpracování dat, mám ho nejen na pc, ale i na tabletech, raspberry, disk stationu od synology a kromě pythonu už mi stačí jen vim, který také běží všude. Je to mimořádně flexibilní nástroj. U aplikací do 20 k řádků už nepoužívám nic jiného.
-
Python zažíva momentálne neskutočný boom. Primárne kvôli machine learning. Etabloval sa tiež ako jazyk
bezpečnostných expertov a pen testerov. Python je vynikajúci aj pre web vývoj (Django, Flask); aj keď nie je tak populárny.
Okrem PyCharmu je skvelým nástrojom aj Visual Studio Code.
Etabloval se i ve vědě a na akademické půdě, je dobrý na skriptování, psaní drobných aplikací, automatizívání, na drobný web, na vytváření prototypů, na zpracování dat, mám ho nejen na pc, ale i na tabletech, raspberry, disk stationu od synology a kromě pythonu už mi stačí jen vim, který také běží všude. Je to mimořádně flexibilní nástroj. U aplikací do 20 k řádků už nepoužívám nic jiného.
Hold Pythonpest
-
Python zažíva momentálne neskutočný boom. Primárne kvôli machine learning.
No jo, ale používá se jen pro glue code.
-
Python zažíva momentálne neskutočný boom. Primárne kvôli machine learning.
No jo, ale používá se jen pro glue code.
Glue code je nejdůležitější, knihovna se udělá jen jednou a pak ji všichni používají, množství potřebné práce na knihovnách je jen zlomek celého objemu. Nové věci se dělají a objevují pomocí lepení knihoven. Napsat knihovnu v C, na základě nějakého objevu je opruz a jen rutina.
-
Python zažíva momentálne neskutočný boom. Primárne kvôli machine learning.
No jo, ale používá se jen pro glue code.
Nové věci se dělají a objevují pomocí lepení knihoven.
To se mi nějak nezdá.