[Radovan]

Tohle nepřetrumfneš: http://www.fffilm.name/2017/07/jak-na-programovani.html

[Bystroushaak]

No jo, taky bych doma možná ještě našel podobný sešítek na pascal.

[JS1]

Tohle nepretrumfne.

Jinak v odkazu na knihu Dokonaly Kod je chyba.

[Bystroushaak]

Tohle nepretrumfne.

To mám nějakou dobu uložené. Problém je, že tyhle texty jsem psal pro reálné začátečníky, co mi píšou na mail a oni prostě anglicky moc neumí.

[JS1]

Pokud ne, tak řekne, že jde o největší sračku, kterou kdy viděl a měli by jste to celé zahodit a předělat a že kdyby to napsal on, tak se jde zabít. [..] Bývalý kolega v minulé práci rozbrečel svojí kritikou jiného kolegu tak, že se z toho zhroutil a utekl z práce a už nechtěl nikdy přijít. Šéf ho pak musel přesvědčovat až do půlnoci, aby výpověď nedával a že kritika kódu není kritikou jeho samotného.

Sam nerad lidi kritizuji, ale tohle je katastrofalni pristup a melo by se to rict. Lide, kteri se takhle chovaji, si zaslouzi vynadat.

Osobne zastavam nazor (ktery muze byt chybny), ze v pripade "katastrofalniho" review je nejlepsi soustredit se na zmenu te nejhorsi veci/zlozvyku, a ostatni neresit. Sesypat na nekoho, kdo proste neni na dostatecne urovni, nekonecny seznam jeho chyb je spis kontraproduktivni.

Jinak muj sef mi radil 3P pri kritice:

Private - kritizuj v soukromi, ne pred ostatnimi.

Positive - zacni necim pozitivnim, treba tim, co ten dotycny dela dobre.

Personal - dej osobni priklad, treba neco jako "dopoustel jsem se driv podobne chyby".

[Bystroushaak]

Jo, s tím souhlasím, jenže to má jedno ale: typicky přitom chceš po tom člověku ten kód přepsat, protože nebudeš pouštět do produkce něco, co má masivní nedostatky všude možně. Takže stejně musíš nakonec řešit všechno, nebo to po něm přepsat.

[JS1]

typicky přitom chceš po tom člověku ten kód přepsat, protože nebudeš pouštět do produkce něco, co má masivní nedostatky všude možně

Ja mam na tohle jiny nazor. Pokud to ma tak zasadni nedostatky, ze je potreba to po review od zakladu prepsat, pak slo bud o nevhodne zadani (neodpovidajici dovednostem daneho programatora), nebo o nevhodneho cloveka.

Idealni by bylo, vratit hlavni nedostatek, udelat nove review, opravit dalsi nedostatek atd. Ale to neni uplne realne jak z duvodu casovych, tak z duvodu lidskych (ne kazdy se uci tak rychle a nekdo by si takovy pristup take mohl vykladat spatne).

Takze pokud to nema zasadni nedostatky, tak bych to proste akceptoval. V temer kazdem tymu budou nejaci lide, kteri se neco uci a delaji to poprve. A obcas napisi kod, ktery neni uplne idealni. Vetsinou to neni velky problem.

[Bystroushaak]

Takze pokud to nema zasadni nedostatky, tak bych to proste akceptoval. V temer kazdem tymu budou nejaci lide, kteri se neco uci a delaji to poprve. A obcas napisi kod, ktery neni uplne idealni. Vetsinou to neni velky problem.

Já to jako problém vnímám, protože ten kód pak musí taky někdo udržovat a bude tam strašit klidně desítky let. Oproti tomu se prostě vyplatí donutit to člověka udělat čistě na první pokus.

V pythonu jsme měli tenhle případ třeba u člověka, který v něm psal javu. Místo aby použil prostředky, které mu nabízí, tak prostě programoval tak, že si udělal deset tříd a začal mezi nima dělat patterny a bůh ví co. Kdo to pak má po něm číst a udržovat? Místo toho jsme ho prostě tlačili naučit se „zen pythonu“ a psát jednoduchý a čitelný kód, který využívá možnosti, které python nabízí. Třídy se vyhodily a celý problem se přepsal na asi třista řádků čitelného kódu, který se nesnažil dělat mosty a slonovinové věže abstrakce.

Úplně typickým příkladem je to, na čem zrovna momentálně dělám. Jedná se o systém redistribuce obsahu mezi servery, které mají obsah ukládat. Systém musí počítat s výpadky disků, sledovat chyby, zatížení a zaplnění serverů, přidávání a ubírání disků a serverů a tak podobně. V roce 2013 to napsal někdo, kdo byl celý ujetý do patternů a callbacků. Výsledek je, že se v tom hrabu třetí týden a snažím se v tom opravit bug, ale díky vrstvám nesmyslné abstrakce, která řeší neexistující problémy, se v tom skoro nedá vyznat. Například jen kód, který počítá statistiky volání metod se inicializuje skrz pět souborů a asi šest tříd a nakonec jsem zjistil, že už se roky nepoužívá a reportuje výsledky do prázdna.

Kdybych byl u code review, tak mu to omlátím o hlavu na třináct způsobů. Nikdo z kolegů, kteří tu dělají roky se k tomu nechce ani přiblížit a to jsou lidi, co ten systém znají a aspoň ví jak to má fungovat. Tohle končí tak, že se z toho stává svatý relikt, kolem kterého se jen opatrně našlapuje, který nikdo nechápe, ale všichni se modlí, aby se nerozbil.

V tomhle mi přijde krásný ten citát Kena Thompsona:

One of my most productive days was throwing away 1,000 lines of code.

[JS1]

Oproti tomu se prostě vyplatí donutit to člověka udělat čistě na první pokus.

Nevyplati. Vyplati se udelat to decentne na prvni pokus, ale ciste.. vetsinou zbytecna prace.

Programatori jsou produktivnejsi nez pred 30 lety. Bohuzel temer vsechna ta produktivita (a mozna i vic nez ona) se ztratila v jakemsi preludu "dokonaleho kodu" a neustaleho refaktorovani.

Mne se taky libi cisty kod, jako kazdemu. Ale je IMHO dobre si priznat, ze treba zmena "business objectives" (obchodnich cilu?) a dalsi vnejsi faktory (treba fluktuace lidi) je mnohem vetsi zdroj vzrustajici entropie kodu nez programatori. (A krome toho - ciste osobni nazor, kterym se pripojuji k deda.jabko - jenom prechodem od Pythonu k Haskellu by sis v cistote dost pomohl. Uz jenom treba QuickCheck..)

[misch]

Z mého pohledu je akceptace jakž-takž použitelného kódu (navíc z důvodu "aby se autor necítil špatně") pomalá ale jistá cesta do pekel. Autor takového kódu bude mít sice dobrej pocit z toho že jeho výtvor nikdo nekritizuje, ale následně pak dotyčný vytvoří 20 dalších variant podobných skoro-ale-ne-zcela-prasáren, načež opět jeho dílo nikdo nezkritizuje ("minule jsme to nechali být, on by se cítil divně kdybychom mu teď to samé vrátili k přepracování"), a postupně si tak každý vytvoří svůj vlastní rybníček s vlastními nestandardními postupy a mini-chybami, a projekt jako celek je v pr....

Můj názor je: pokud programátor není schopný pochopit, že _objektivní_ kritika jeho kódu není kritikou jeho samotného, a že _objektivní_ důvody k přepracování kódu neznamenají že "šéf se po mě vozí", tak je lepší s takovým ani nezačít spolupracovat.

[JS1]

Autor takového kódu bude mít sice dobrej pocit z toho že jeho výtvor nikdo nekritizuje

Rekl bych, ze nic takoveho jsem nepsal, dal je to non-sequitur.

[smazáno]

nejak hosi zapominate, ze code review muze byt katastrofalni kvuli tomu kdo ho psal :)

[Agent]

Jen 80%, jak někdo může dát mínus? Velice pěkně popsáno, jestli se někdy budu chtít stát ajťákem, programátorem, vezmu si z toho příklad. Děkuji za rady. A ať se daří.

[Jendа]

Příloha:

• Jak_se_stat_programatorem.html.patch (12656 bytů)

No, výjimečně jsem to nepřečetl tak hladce jako tvoje ostatní texty. Patch v příloze, ale ještě by to chtělo nějak vyhladit co do navazování souvětí na sebe.

Osobně teď nejvíc bojuju s architekturou. Ve škole mě nějak naučili algoritmy a tak, ale jak něco udělat, aby z toho nebyl šílený nerozšiřitelný bordel, nad tím furt tápu.

Pokud něco nevíte, prostě se zeptejte, jestli má čas („máš na mě chvilku?“) a ptejte se a nechte si to vysvětlit.

Tohle mě vytáčí (a hlavně to poškozuje tazatele). Příklad: nejsem u počítače a někdo něco potřebuje. Napíše na Jabber:

• Varianta 1: zeptá se mě, jestli mám chvilku. Až za hodinu přijdu, odpovím, že ano, a on je už mezitím pryč. Má smůlu.
• Varianta 2: rovnou napíše, co potřebuje. Až za hodinu přijdu, rovnou problém vyřeším/odpovím mu k věci.

[Bystroushaak]

No, výjimečně jsem to nepřečetl tak hladce jako tvoje ostatní texty. Patch v příloze, ale ještě by to chtělo nějak vyhladit co do navazování souvětí na sebe.

Jo, to je tím, že jsem si to po sobě nepřečetl. Běžně ty blogy po sobě většinou ještě minimálně jednou přepíšu, včera se mi už ale fakt nechtělo.

Osobně teď nejvíc bojuju s architekturou. Ve škole mě nějak naučili algoritmy a tak, ale jak něco udělat, aby z toho nebyl šílený nerozšiřitelný bordel, nad tím furt tápu.

Tohle bude tak nějak boj až do konce života. Můžeš se naučit různé patterny a standardní způsoby řešení, to ti ale jen trochu usnadní práci. Asi jediné řešení je prostě sbírat zkušenosti, diskutovat o architektuře s ostatními a číst různé názory, ze kterých si pak vybereš co ti přijde smysluplné.

Tohle mě vytáčí (a hlavně to poškozuje tazatele). Příklad: nejsem u počítače a někdo něco potřebuje. Napíše na Jabber:

To ale znamená, že tu chvilku nemáš. Když se takhle ptám já, tak tím předpokládám interaktivní chvilku.

[kralyk z abclinuxu]

Varianta 1: zeptá se mě, jestli mám chvilku. Až za hodinu přijdu, odpovím, že ano, a on je už mezitím pryč. Má smůlu.

Pokud jde o IRC/IM, tohle s kolegy běžně řešíme asi takhle:

Q: Čau, máš chvilku?
[...timeout...]
Q: nvm, viz email
následně odpovím po mailu...

[Bystroushaak]

Tak já to většinou praktikuji IRL, že se prostě otočím a zeptám se verbálně.

[kralyk z abclinuxu]

Tak to je samozřejmě nejlepší, kontext vlákna je ale IM/IRC...

[DW]

Jenže to hrozně vytrhává ze soustředění, když se tě pořád někdo na něco ptá. Sotva se zabereš do práce, tak je tu nějaký kolega a něco chce. To se opakuje Xkrát za den, mezi tím sem tam nějaká porada, oběd... a produktivita jde do háje, protože nemáš dlouhý souvislý čas, ve kterém bys mohl v klidu pracovat. Asi by to chtělo vyčlenit nějaká časová okna, ve kterých se diskutuje (ideálně v zasedačkách, aby to nerušilo ostatní).

BTW: máte klidné pracovní prostředí? Nebo tam pořád někdo mluví a chodí?

[Bystroushaak]

BTW: máte klidné pracovní prostředí? Nebo tam pořád někdo mluví a chodí?

Máme kancelář o čtyřech lidech.

[pavlix]

Mně dělá klidné pracovní prostředí problém, bez ruchu se nemůžu soustředit. Když není nikdo doma a kočky chrápou, tak si pouštím televizi.

[Heron]

Jednou jsem tohle schválně změřil a průmerná souvislá doba bez přerušení (z různých zdrojů) byla asi tak 6minut. Je to peklo.

[trekker.dk]

Tohle se dá regulovat - když četnost vyrušení přeroste rozumnou míru, stačí bejt protivnej. To vyrušitele motivuje, aby si příště buď poradili sami, nebo šli za někým jiným.

[deda.jabko]

Mne se nechce delat patch, ale autor by si mel uvedomit, ze carka pred "nebo" meni vyznam (OR vs. XOR) a pak jeste udelat %s/by jste/byste/g, %s/by jsme/bychom/g.

[Bystroushaak]

Mne se nechce delat patch

Z toho důvodu jsou ty blogy od určité doby na githubu: https://github.com/Bystroushaak/clanky/blob/master/2017.07.16_Jak_se_stat_programatorem/Jak_se_stat_programatorem.html. Tam můžeš použít přímo zabudovaný online editor. Hlavní chyby jsem opravil, díky za podněty.

[Max]

Pěkně. Bohužel u nás je to naprostý opak.
Před hafec lety jsem je donutil, aby používali svn, ani jeden programátor to nechtěl používat a nadávali, jak je to zdržuje při praci. To, že si věčně přepisovali kód je asi trápilo míň, ale jen do chvíle, než jeden z nich opět přišel o den práce.
Programy nemají u sebe ani README, ani nic dalšího. Nikdo neví, co to dělá, co to potřebuje k životu, když se něco řeší, musí se všichni dívat do kódu, co to vlastně dělá.
Jeden týpek, co byl přibrán, psal aplikace pro net.framework 4.5, když to měl, zjistil, že na cílovce, tenkrát windows server 2003r2, net.framework 4.5 nerozjede, tak mu to běželo na jeho workstation.
Aktuálně máme týpka, který dělá Oracle, nic víc. Oracle je pro něj vším a nic dalšího nevidí. Má rád tedy Oracle,PLSQL, Apex. Tento týpek plodí selecty o 5000 řádcích, protože je to výkonnější, než kdyby to rozdělil na části. Pokud někdy odejde, tak jsem zvědavý, kdo a jak to po něm vůbec převezme.
Mno, unit testy a další věci je v tomto kontextu už jen opravdu vtip. aktuálně se nasazuje na úrovni fs (aktualizace jednotlivých souborů), žádná konzistence, žádné tagování v svn, nic, prostě jen trunk a jede se.
Já programátor nejsem, nemám to na starosti, ale když to vidím, chce se mi brečet.
Zdar Max

[Bystroushaak]

Jo, to je fakt špatné. Připomíná mi to situaci z knihy The Phoenix Project, což je v podstatě taková naučná story o tom jak manažer převezme oddělení, kde se to vede tímhle způsobem, i když se to víc věnuje adminům, než programátorům.

Před hafec lety jsem je donutil, aby používali svn, ani jeden programátor to nechtěl používat a nadávali, jak je to zdržuje při praci. To, že si věčně přepisovali kód je asi trápilo míň, ale jen do chvíle, než jeden z nich opět přišel o den práce.

Už jsem na pohovorech párkrát slyšel něco podobného. Většinou jsem se jen usmál, přestal se snažit a už se jim nikdy neozval. Naposledy to byl Nordic telecom, kde když mi popsali stav, v jakém mají jejich codebase a že už se jim podařilo přidat některé části do SVN, tak jsem utekl, až se mi za patama prášilo, přestože nabízeli 60 tisíc za práci tři dny v týdnu a později slušnou šanci podílet se na vývoji nového systému.

Aktuálně máme týpka, který dělá Oracle, nic víc. Oracle je pro něj vším a nic dalšího nevidí. Má rád tedy Oracle,PLSQL, Apex. Tento týpek plodí selecty o 5000 řádcích, protože je to výkonnější, než kdyby to rozdělil na části. Pokud někdy odejde, tak jsem zvědavý, kdo a jak to po něm vůbec převezme.

Imho nepřevezme. To se prostě zahodí a někdo to bude znovu vynalézat, pokud tedy nenajdete fakt masochistu.

Tohle mi právě přijde asi jako největší rozdíl, mezi amaterismem a profesionální prací. Každý amatér zvládne vyplodit výblitek na 5000 řádek, pár týdnů si s tím hrát a ono to nakonec nějak funguje. Profesionál by to měl zvládat udělat i čistě, přehledně a hlavně udržovatelně a navíc to zdokumentovat, protože už tak nějak chápe, že firma není jen o odvedení práce, ale také o nějaké kontinuitě. Prostě počítat s tím, že ho jednoho dne vyhodí, nebo povýší a někdo to po něm bude muset převzít.

Bohužel občas se lze setkat právě s tímhle, že se lidi (možná záměrně?) udělají nenahraditelnými.

[rastos]

Neplač. Keby som napísal, ako to funguje "u nás", tak ťa ešte tromfnem Ale nechcem ohovárať svojho chlebodarcu.

[Max]

Vím, kde děláš, takže díky za info :).
Zdar Max

[Heron]

Ještě jsem nepotkal začátečníka, který by uměl správně dokumentovat kód.

Je velmi málo lidí, kteří píšou dokumentaci a je ještě méně lidí, kteří píšou dobrou dokumentaci. Tohle považuji za největší bolest. Spousta lidí si hraje na to, že "dokumentace až po projektu". Největší chyba, tohle vždy skončí bez dokumentace. Pro mě je psaní dokumentace integrální součástí práce. Dokumentace roste tak, jak roste projekt.

Dříve nebo později se vám to určitě stane - někdo se podívá na váš kód a celý ho zkritizuje. Pokud budete mít štěstí, řekne jen, že se jedná o špatný kód.

Nevím, jak to chodí u programátorů, ale pokud se stane, že někdo zkritizuje celou něčí práci (tj něco, na čem pracoval déle než řekněme pár hodin), tak je něco špatně. Pokud tým pracuje správně, tak by ostatní měli vědět, co dělají jejich kolegové, takže mají šanci včas zastavit kolegu, který dělá něco špatně. Vzájemná kontrola by měla být automatická.

Další věc, kterou začátečníci moc neovládají jsou verzovací systémy.

Je celkem fajn ukázat, že verzovací systém není něco navíc (co přidává práci a co otravuje), ale že verzovací systém je pracovní nástroj který práci ulehčuje. Potom je přijetí většinou snazší.

Potíž je s workflow, které vzniklo ještě na "emailech" (posíláme si různé verze dokumentů emailem), potom se toto převedlo do SVN, ale nic se na tom nezměnilo ("geniální" nápad je svn commit jednou denně na konci prac doby) a potom to někdo zkusí namlátit do gitu (kdy potom všichni na konci prac. doby řeší merge konflikty). To potom není divu, že je pro ně git naprostým zlem.

[Bystroushaak]

Nevím, jak to chodí u programátorů, ale pokud se stane, že někdo zkritizuje celou něčí práci (tj něco, na čem pracoval déle než řekněme pár hodin), tak je něco špatně. Pokud tým pracuje správně, tak by ostatní měli vědět, co dělají jejich kolegové, takže mají šanci včas zastavit kolegu, který dělá něco špatně. Vzájemná kontrola by měla být automatická.

Vzájemná kontrola většinou přichází před začleněním do devel branche. Zase imho nemá smysl neustále stát člověku za zády a hlídat každý jeho krok.

Je celkem fajn ukázat, že verzovací systém není něco navíc (co přidává práci a co otravuje), ale že verzovací systém je pracovní nástroj který práci ulehčuje. Potom je přijetí většinou snazší.

Tak dneska mi přijde GIT jako naprosto integrální součást práce, stejně samozřejmá, jako třeba používání pokročilého editoru a ne notepadu.

[Heron]

Zase imho nemá smysl neustále stát člověku za zády a hlídat každý jeho krok.

Tak u nás na techu nestojíme každému za zády, ale většinou vzájemně víme, co kdo z nás dělá. S kolegou navíc máme vypěstovaný takový pracovní vztah, že většinu náročných věcí děláme ve dvojici (a je prakticky jedno, jaký úkol si kdo z nás vezme, jsme 100% zastupitelní) a při práci se informujeme a více méně si potvrzujeme, že tento krok by udělal i kolega. Je to nesmírně efektivní (tj v podstatě jak pracovat s vlastním klonem ) a minimalizuje se riziko chyb (už se nám párkrát stalo, že to co chtěl někdo z nás udělat nebyl zrovna dobrý nápad a ten druhý ho zarazil).

Chápu, že u prog to bude jinak, protože tam ještě přijdou na řadu revize kódu, kontroly, qa apod., takže kontrola na počátku není až tak kritická.

[Kate]

On hlavně až na výjimku ve formě párového programování většinou není čas na to, aby všichni věděli všechno. Vím na kterých projektech kolegové právě pracují, ale kdybych měla sledovat celý proces který vede k výsledku u všech, nic neudělám.

Tady je hlavně důležité nebýt „lone wolf“ a vědět kdy ostatním svou práci v počátcích ukázat a dát k posouzení.

[Bystroushaak]

Tak u nás na techu nestojíme každému za zády, ale většinou vzájemně víme, co kdo z nás dělá. S kolegou navíc máme vypěstovaný takový pracovní vztah, že většinu náročných věcí děláme ve dvojici (a je prakticky jedno, jaký úkol si kdo z nás vezme, jsme 100% zastupitelní) a při práci se informujeme a více méně si potvrzujeme, že tento krok by udělal i kolega. Je to nesmírně efektivní (tj v podstatě jak pracovat s vlastním klonem ) a minimalizuje se riziko chyb (už se nám párkrát stalo, že to co chtěl někdo z nás udělat nebyl zrovna dobrý nápad a ten druhý ho zarazil).

Chápu, že u prog to bude jinak, protože tam ještě přijdou na řadu revize kódu, kontroly, qa apod., takže kontrola na počátku není až tak kritická.

U programátorů se tomuhle říká párové programování. Někdy to může být fajn, ale ne vždy.

Osobně mi v tomhle pomáhá spíš diskutovat. Než něco vymyslím, tak si o tom prostě promluvím s kolegou / kolegy takovou tou věděckou metodou, že to nadnesu jako hypotézu, jak by šel problém vyřešit a očekávám, že budou hledat důvody, proč to není dobrý nápad. Když se žádné nenajdou, nebo jsou to řešitelné věci, tak se pustím do implementace, průběžně to testuji (integračně), píšu unittesty, pak to okomentuji a zdokumentuji a pošlu jako změnu ke schválení, na kterou někdo musí udělat review. Osobně jsem za připomínky na review rád, protože mi to prostě pomáhá se zlepšovat, stejně jako jsem rád třeba za diskuzi pod blogy, i když je kritická (pokud je to tedy konstruktivní kritika). Nové pohledy a způsoby jak přemýšlet o věcech jsou pro mě hodnotné.

[Kate]

Jojo. Ono to že typický programátor je asociál je taková hezká pověra, ale ve výsledku je umět mluvit s ostatními často dost důležité.

A reviews jsou super. Občas se člověk dozví něco nového, občas se něco nového dozví i protistrana :)

[Heron]

U programátorů se tomuhle říká párové programování. Někdy to může být fajn, ale ne vždy.

Ne, tohle je něco jiného. My oba pracujeme na svých úkolech (třeba různé služby na stejném připravovaném serveru), oba děláme to svoje ale průběžně se informujeme a v případě kritických míst se raději ptáme. Takže skoro 2x tak efektivní, jako kdyby to dělal jeden člověk, ale navíc včetně kontroly.

Osobně mi v tomhle pomáhá spíš diskutovat.

To by mě taky pomáhalo, kdyby bylo s kým...

[podlesh]

Tohle je jeden z hlavních účelů standupů, které se zavádějí se scrummem - aby se všichni takhle průběžně informovali alespoň jednou za den. Plus: pokud někdo za celý den s problémem nehne, tak o tom ostatní ví a mohou se podívat, co je tam tak kritického.

Samozřejmě, vyžaduje to alespoň minimální motivaci vůbec spolupracovat - pokud není, tak se to zašvejkuje, každý si prostě pět minut povypráví o tom svém a jinak vypne příjem. A až do všechno skončí tak jde někam na fórum kde si postěžuje jak se zavádějí nesmysly které ho zdržují od práce.

[Bystroushaak]

Standupy jsou dobré, ale nesmí se to zvrhnout v řešení detailů. Lidi mají tendence začít diskutovat o svých problémech a to by imho na standupu neměli, protože většinu to nezajímá.

Já se snažím na standupu během minuty / dvou vysvětlit co dělám a na čem jsem se případne zasekl, ale další diskuze a plánování mám tendence nechat po standupu na specifické kolegy, se kterými jsem se o tom třeba už bavil, nebo kteří mi jsou schopní pomoct.

Bohužel, ne všichni to tak dělaj a pak to končí jako dvacetiminutový standup v pěti lidech, kde jeden člověk patnáct minut vypráví každý den co má za problémy. Tam pak chápu, že to spoustu lidí otravuje.

[JS1]

Standupy jsou k nicemu, a tenhle ucel naprosto plnit nemohou.

[podlesh]

Proč? Jelikož je empiricky potvrzeno, že tento účel plnit mohou, tak bych rád viděl ty důvody proč nemohou.

[JS1]

Ja to tedy empiricky potvrzene nemam, spis naopak. Duvod uz napsala Kate.

Kdyz jsem zacinal u nas, meli jsme cca. hodinovou schuzi jednou za tyden, kde jsme prave mohli resit dulezite technicke detaily. Bylo to uzitecnejsi nez standup, protoze a) mohli jsme jit vic do detailu b) nemuseli jsme zminovat problemy, ktere se mezitim (treba nasledujici den) podarilo vyresit.

Standup je totalni idiocie - chces vyssi frekvenci informaci ale das na to min casu. Ale pokud ti to funguje - tak fajn.

[Kate]

Nebo prostě standup bereš úplně špatně. Standup nemá být výklad technických detailů. Má to prostě být krátká synchronizace teamu a toho kdo na čem pracuje, případně naplánování věcí na den typu „potřebuju s tím a tím pomoct, kdo bude mít čas?“, případně „budu nasazovat do produkce to a to, máte k tomu ještě někdo něco?“, nebo „dneska mě neotravujte s ničím, budu debugovat tuhle komponentu co všichni nenávidíme“

Na technické detaily si klidně můžeš svolávat týdenní hodinové schůze. U nás nám většinou stačí plánování sprintu jednou za dva týdny a na složitější věci další plánovací timebox (člen teamu zjistí aktuální stav a na standupu se dohodne kdy si nad tím všichni sednou, člen teamu ukáže k čemu došel a navrhne řešení, které s ostatními probere)

[JS1]

Má to prostě být krátká synchronizace teamu

Az bude implementovan standup mezi vlakny Linuxoveho jadra, prijmu, ze je to dobry napad. Do te doby budu povazovat asynchronni ad-hoc synchronizaci za lepsi napad.

[Kate]

Jasně, ad-hoc v rámci dne je potřeba, ale ten ranni standup přece jen pomůže udělat si na začátku dne trochu představu o tom, jak bude den probíhat i pro ostatní v teamu a rozvrhnout si čas. Navíc to z mé zkušenosti přispěje k tomu, že se na nic nezapomene.

[JS1]

Potvrzujes muj dojem, ze standupy proste nemaji naprosto zadny vliv, ani pozitivni, ani negativni. Solidni empiricka data nemame (kdyz jsme tak u toho, mam v oblibe tohohle chlapika), a ciste anekdoticky, je dost mozne, ze na spousta lidi to pusobi jako placebo (ty) a na spousta lidi jako nocebo (ja).

[xkucf03]

IMHO to za těch 10-15 minut stojí (to už víc času strávíš vařením kafe/čaje a chozením po chodbách… a kuřáci ještě mnohem víc).

Funguje to jako základní psychologická motivace („musím něco udělat, abych zítra mohl říct, že jsem to udělal, ideálně dokončil“) a řekneš si nejdůležitější úkoly pro dnešek (to je dobré poslat i e-mailem).

Řeknou se tam věci, na které by tě třeba nenapadlo se ptát nebo by ostatní nenapadlo zajít zrovna za tebou a říct ti je (řekli to osobně někomu jinému). Díky tomu víš, na čem ostatní pracují a co se na projektu zrovna děje (vzniká nová větev, zítra vydáváme verzi, nasazuje se na produkci, objevila se nějaká zásadní chyba, čekáme na dodavatele/zákazníka atd.)

Samozřejmě záleží, jak se k tomu kdo postaví – pokud tam lidi přečtou jen čísla úkolů, na kterých pracují, a pak už neposlouchají, tak to smysl nemá – ale to je vada těch lidí nikoli systému.

Šlo by to nahradit e-mailovou nebo jinou komunikací (u distribuovaných týmů to jinak nejde), ale pokud lidé pracují ve stejné kanceláři, tak mi dává smysl se sejít osobně.

[Kate]

Pokud v tom standupu začneš zabíhat do detailů, tak ti právě začnou vypínat. Ideální mi přijde říct na čem jsem zaseklá a zeptat se přítomných, jestli na to bude někdo mít čas přes den mrknout se mnou. Detaily se dají řešit tam, už bez lidí které to nezajímá a potřebují pracovat :)

[podlesh]

Ano, tak to má být. Bohužel ten fígl se "stand up" nefunguje, někteří lidé nemají ploché nohy

[Jendа]

Osobně mi v tomhle pomáhá spíš diskutovat.

Ano.

Třeba gsm stack jsme napsali skoro celý ve dvou a bylo to velmi poučné (s programováním jsem tehdy totálně začínal), taky protože to nebylo ani tak o implementaci, jako spíš o tom fungování sítě a kryptografii za tím. Ale od té doby mi taky pomáhá spíš diskutovat, pak nějakou dobu programovat sám a pak zase probrat, na co jsem narazil.

[Bystroushaak]

Ještě existuje jedna fáze, a to je ležet v hamace a přemýšlet a kreslit si, viz Hammock Driven Development - Rich Hickey :)

[Josef Kufner]

+1

[VSi]

Nerad kradu nesouvisející diskusi, ale když už to tu je - a nevím kde jinde se nejlépe zeptat - tak proč se pro tyhle GSM hackingy používají těžko sehnatelné staré telefony a OsmocomBB, když velmi zajímavá SDR (třeba postavená na AD9364 s 56MHz bw, plus nějaké FPGA) už jsou cenově celkem dostupná? Jde o lepší radiovou část s HW filtry? Nebo se používají originální kusy baseband firmwaru? Zvlášť pokud jde jen o poslouchání, kde to není o nějakých realtime rx-tx reakcích na úrovní rádia, tak by mi SDR přišlo ideální.

[Jendа]

Protože v roce 2011 neexistovala cenově dostupná SDR.

Kdybych to psal dneska, tak samozřejmě SDR, a ostatní projekty jsou samozřejmě SDR.

Zvlášť pokud jde jen o poslouchání, kde to není o nějakých realtime rx-tx reakcích na úrovní rádia

Mimochodem není to tak triviální jako že naladíš SDR někam a přečteš si samply, uplink je o 40 nebo 80 MHz níž, + je tam frequency hopping, takže když to nepokryješ celé, musíš nějak řešit neustálé přelaďování.

[dementni.lojzik]

Vzájemná kontrola většinou přichází před začleněním do devel branche. Zase imho nemá smysl neustále stát člověku za zády a hlídat každý jeho krok.

pri zaclenovani do devel vetve uz je IMHO pozde, tam hrozi, ze clovek sel od zacatku spatnym smerem a vyhodi praci za mnoho dni. Souhlasim uplne s Heronem. U nas na triviality staci Jira s kratkym popisem, vetsi veci se diskutuji na mailing listu a na fakt velke veci (ktere pisou velci kluci, co uz, treba na rozdil ode me, fakt umi programovat) dany vyvojar udela desing doc, na ktery se vetsina lidi podiva a na mailing listu opet prodiskutuje pripadny nejasnosti. Obvykle pak po 2-3 tydnech prace dobrovolne posila pull request jako s rozdelanou praci preview, aby se pripadne odstranila nejaka fatalni prehlednuti (nepamatuju se, ze by se kdy stalo, aby to predelavali uplne, ale urcite je to dobry zvyk).

[Bystroushaak]

pri zaclenovani do devel vetve uz je IMHO pozde, tam hrozi, ze clovek sel od zacatku spatnym smerem a vyhodi praci za mnoho dni.

Tak úplně špatný směr by měl odhalit jeho šéf, který mu práci zadává a který se ho různě průběžně ptá, jak a jestli postupuje.

[dementni.lojzik]

co kdyz sef dane oblasti nerozumi (a nebo nerozumi dostatecne hluboku, aby pripadnou chybu odhalil)?

[JS1]

Tak by mel asi odejit.

Nemam nic proti sefum, co necemu nerozumi, ale tak ci onak je to manazerske selhani.

[Kate]

To jako že šéf má dopodrobna rozumět kompletně celému projektu a všem jeho komponentám? Jako, u piškvorek možná, ale u něčeho velkého je to asi celkem bez šance, i když je sám programátor.

[Bystroushaak]

Šéf by měl být spíš schopný poznat, jestli je ten člověk zaseknutý, nebo jestli má s něčím problémy, čistě na lidské úrovni, formou dialogu a rozhovoru. Pak může alokovat třeba jiného programátora, ať s tím pomůže.

[podlesh]

Nemusí to být nutně šéf, může to být decentralizováno. Stejně jako rozdělování a plánování práce. Není to vždy možné, není to ani jednoduché, ale skutečně to je možné. Důležité je, že někde někdo tu znalost má a funguje komunikace s ostatníma.

[dementni.lojzik]

ale v tomhle vlakne se bavime o situaci, kdy dany programator na nicem zaseknuty neni, dokonce treba skace blahem, ze se mu podaril rozseknout velmi zapeklity problem a az dodela implementaci, tak pri review nekdo zjisti, ze to vlastne az tak genialni reseni neni a musi se to udelat cele jinak

[podlesh]

V okamžiku kdy je někdo nadšený že mu to podařilo rozseknout, tak je dobré se hned (aktivně) podívat jak to rozsekl. Právě z tohoto důvodu.

[Kate]

Ale to mu těžko pomůže rozeznat že jde špatným směrem. Člověk může být spokojený nad tím jak mu práce odsýpá, dokonce i na standupech může jeho postup znít rozumně, ale na pozadí vznikne něco co je krok vedle. Proto je fajn na začátku hlavně komunikovat, pokud jde o novou vlastnost seznámit kolegy s draftem, hodit na review kostru řešení „jak by to mohlo vypadat“ a tak.

[Bystroushaak]

Ale tak to určitě. Jen ne každý to tak dělá. Já osobně se to tak snažím dělat hlavně z toho důvodu, že prakticky vždycky touhle metodou dojdu k lepšímu řešení, už jen proto, že neznám celý systém tak dobře, jako ostatní, kdo jsou tu déle.

[JS1]

Co napsal Bystrousak je spravne, ale navic, sef ma samozrejme vedet, co je kdo zac a hlidat si je na zaklade toho. Takze novacka muze klidne kontrolovat kazdy den (nebo pres zastupce), ale nekoho, kdo je senior, muze nechat treba mesic bez dozoru.

Uz proto je standup totalni pitomost, protoze strka lidi do stejne skatulky.

[Kate]

Možná by to opravdu chtělo odprostit se od toho že je standup kontrola teamu. Jestli to u tebe takhle funguje, je to chyba implementace, ne procesu :)

[pavlix]

Tak základní vlastnost standupu je mluvit k ostatním ne kdy cítíš potřebu, ale kdy je to naplánováno. Navíc ani to rychlé tempo nemusí vyhovovat. Pro mě třeba rychlé tempo standupu znamená, že lidi před sebou vůbec neposlouchám a jen se zoufale snažím udržet v hlavě znění myšlenky, kterou chci na ostatní vysypat, a pokud možno tak, aby se nikdo na nic neptal, jinak se zakecáme a to tempo porušíme.

[prqek]

Díky. Je dobré vědět, že v tom nejsem sám :)

[Josef Kufner]

Na schůzky se svým školitelem nosím třístránkové PDF. První stránka je co jsem od minule udělal, druhá o tom co budu dělat a třetí je na poznámky ze schůzky. Obvykle to je jen pár stručných vět, několik málo bodů. Shledal jsem to velmi užitečným nástrojem. Jednak mám přehled o tom, co jsem dělal a jak mi to trvalo. A pak také si udělám pořádek v tom, čím chci pokračovat.

Proč si na ten standup nepřipravíš těch pár bodů předem? Vždyť stačí chvíli předem kouknout do bugzilly a hodit kus textu do mobilu …

[pavlix]

Tak je pravda, že bych si mohl každý den těch pět větiček místo zapamatování před meetingem napsat, pokud bych k tomu cítil dostatečnou motivaci... Ovšem pak mi nedělá problémy to napsat rovnou do nějakého sdíleného zdroje, kde si to v klidu přečtou ti, které to zajímá a kterých se to týká. Souvislost se schůzkou se školitelem nevidím. Do detailů stejně zacházet nebudu.

[JS1]

Mel jsem spis na mysli neco jako toto. Ackoli ano, interpretace, kterou zminujes, je bohuzel bezna, a ja si dokonce myslim, ze je duvodem popularity Scrumu. Takova uz je holt lidska psychika, ze jazykem se komunikuji i veci, ktere se jim primo nerikaji. Ja v podstate souhlasim s timto clankem, ktery shrnuje radu i mych vlastnich kritik. Jenom bych k tomu pridal jeste jednu, a to ze vymysleni nove terminologie povazuji za necestny zamer, jehoz cilem je prerusit kontinuitu mlade generace s tou starsi, ktera ma zkusenosti (napriklad s rizenim projektu). Zkratka snake oil jak vysity.

[JS1]

Ale abych nebyl jen za skeptika - velmi se mi libi Kanban (narozdil od Scrumu je to postavene na necem, co ma realny zaklad a tudiz se da celkem prijmout, ze to bude fungovat i u SW). Jediny problem je, ze nijak nedava odpoved na tu vecnou zakladni otazku, totiz, kdy to bude hotove.

[Kate]

Ono je fajn, že jsi v oboru kde docela můžeš vybrat a tedy jít někam, kde je model co ti vyhovuje :) Pro mě má třeba scrum reálný význam a standupy reálný přínos k organizaci dne, takže nazývat to výše placebem jenom kvůli tomu že to nevyhovuje tobě je docela zvláštní.

Na otázku „kdy to bude hotové“ se ve vývoji něčeho trošku většího asi odpovědět pořádně nedá nikdy. Ve své předchozí práci jsem musela předběžně nacenit a dát čas na každý požadavek klienta a nakonec se toho čísla i držet a prostě to nejde. Jednou se z primitivně vypadajícího řešení vyklube problém na týden, jindy se z náročně vypadající věci stane trivialita. K takovým extrémům sice zas až tak často nedocházelo, ale ani člověk co tam dělal 20 let se prostě v mnoha případech trefit nezvládl.

Správně aplikovaný scrum dovede čas aspoň slušně aproximovat potřebný počet sprintů v průběhu a reagovat na nově objevené skutečnosti / změny požadavků, ale u dlouhodobějších projektů se prostě vědět dopředu nedá :)

[pavlix]

Ono je fajn, že jsi v oboru kde docela můžeš vybrat a tedy jít někam, kde je model co ti vyhovuje :) Pro mě má třeba scrum reálný význam a standupy reálný přínos k organizaci dne, takže nazývat to výše placebem jenom kvůli tomu že to nevyhovuje tobě je docela zvláštní.

Mně to zvláštní nepříjde. Placebo má v životě lidí rovněž reálný význam a reálný přínos. V tom mají obrovskou výhodu individuální metody, které může člověk praktikovat na sobě nebo společně s lidmi, kterým též vyhovují, narozdíl od těchto vnucovaných kolektivních metod. Je to jako rozdíl mezi svobodou a totalitou, individualismem a kolektivismem.

Správně aplikovaný scrum dovede čas aspoň slušně aproximovat potřebný počet sprintů v průběhu a reagovat na nově objevené skutečnosti / změny požadavků, ale u dlouhodobějších projektů se prostě vědět dopředu nedá :)

Tady v podstatě říkáš, že scrum dokáže to, co jsme dělali bez něj.

[Kate]

Jenže pokud něco skutečně řeší reálné problémy, není to placebo. Samozřejmě jsou jiné způsoby jak k podobným organizačním záležitostem dojít a někomu mohou vyhovovat víc. Mně vyhovuje tenhle styl práce. Placebo by bylo, kdybych ze SU odcházela spokojená že se něco vyřešilo a zatím se nevyřešilo nic. Tak tomu není.

Ne, tam jsem řekla že žádná metoda nedokáže dát přesný odhad kdy bude věc hotova, protože to není reálné. Scrum může lépe reagovat na změny, ale to je tak všechno.

[JS1]

nazývat to výše placebem jenom kvůli tomu že to nevyhovuje tobě je docela zvláštní

Me to nevyhovuje, ani spouste jinych lidi, a na zaklade toho na to mam svuj nazor, odlisny od tveho. Na tom neni nic zvlastniho, mit odlisny nazor na neco, co je jen spatne empiricky podlozene.

Na otázku „kdy to bude hotové“ se ve vývoji něčeho trošku většího asi odpovědět pořádně nedá nikdy.

Vesmes neda, ale nejakych 70 let a vic, co existuje projektove rizeni, je zkusenost (jejiz soucasti jsou i metody odhadu), kterou je dost pochybne zahodit kvuli necemu, co si nekdo vymyslel za par dni od stolu (tedy Scrum). A dal tomu pro jistotu jinou terminologii, aby zamaskoval fakt, ze uz tu ta zkusenost je a nekdo by mohl zacit premyslet a zjistit, ze to v lepsim pripade neni nic noveho a v horsim to primo skodi.

Scrum je vubec takova mala oslava amaterismu, napriklad i v tom, ze "kdyz se vam to nelibi, tak si to muzete zmenit na zaklade retrospektivy". Ano, na prvni pohled to vypada jako empiricky, vedecky pristup. Jenze veda nezavedla ve 20. stoleti statistiku a dvojite slepy experiment a dalsi veci jen tak z pleziru, ale na ochranu pred prave, jak pise Bystrousak, predpojatostmi v mysleni samotnych pozorovatelu.

[pavlix]

Navíc je dnes scrum taková modla, že většina lidí nepřizná, že jim to nevyhovuje. Já bych si třeba ještě cca před půl rokem nedovolil ho veřejně kritizovat, vzhledem k tomu, že jsem vážně uvažoval o novém zaměstnání. A jako sorry, já jsem sice hodně upřímný člověk, ale živím rodinu a nevěděl jsem, jestli si můžu dovolit zavřít tolik dveří. Nakonec jsem se dal jinou cestou, která mi umožňuje být upřímnější a čestnější. :)

Svou roli v tom sehrál i jeden pohovor, kde jsem měl na drátě asi tři manažery, z nichž se dva alespoň nějak zajímali o to, co dělám, ale jedna manažerka se mnou za celou dobu nepromluvila kromě pozdravu a dotazu, jaký mám názor na scrum, a zrovna náhodou to byla manažerka týmu, který by pro mě byl v podstatě v roli zákazníka. Při pohovoru jsem neměl čas si rozmyslet reakci, tak jsem bečel cosi o tom, že je scrum super, ale že zřejmě nebyl v mém týmu dobře implementován.

Nope. To, že dotyčná manažerka nechala zcela na ostatních zjistit, jestli jsem k něčemu, a projevila zájem pouze o scrum, který se mnou pečlivě a ráda prodiskutovala, pro mě byl natolik rizikový faktor, že to pro mě byl jeden ze tří argumentů, abych se nesnažil tuto pozici obsadit.

[xkucf03]

Me to nevyhovuje, ani spouste jinych lidi, a na zaklade toho na to mam svuj nazor, odlisny od tveho. Na tom neni nic zvlastniho, mit odlisny nazor na neco, co je jen spatne empiricky podlozene.

Já jsem viděl více týmů, kde se jelo podle SCRUMu a někde ten vývoj fungoval perfektně a dělal se software na úrovni a jinde to bylo o dost horší. Tak jak na základě takové zkušenosti mám hodnotit danou metodiku? Asi nijak – bude to záležet víc na lidech než na použité metodice. A kromě těch lidí (aktuálního týmu), tam máš i spoustu dalších faktorů, které můžeš těžko ovlivnit – technologický dluh, který ti zanechaly předchozí generace programátorů, obchodníci (tzn. jak jsou postavené smlouvy a obecně vztahy se zákazníky, na jaké zákazníky se cílí), situace na trhu, historická zkušenost tvých zákazníků s tvými předchůdci (od toho se odvíjí, jak moc ti jako dodavateli věří, zda jsou ochotni jít do rizika a chovat se víc jako partner než jen jako zákazník). Někdy se i tým dobrých lidí může dostat do situace, ze které se jen tak nevyhrabe.

[little-drunk-jesus]

Scrum je vubec takova mala oslava amaterismu, napriklad i v tom, ze "kdyz se vam to nelibi, tak si to muzete zmenit na zaklade retrospektivy". Ano, na prvni pohled to vypada jako empiricky, vedecky pristup. Jenze veda nezavedla ve 20. stoleti statistiku a dvojite slepy experiment a dalsi veci jen tak z pleziru, ale na ochranu pred prave, jak pise Bystrousak, predpojatostmi v mysleni samotnych pozorovatelu.

Ono to neni tak horke, veci se ve SCRUMU nemeni na retrospektive ihned, protoze se to prave nekomu nelibi, ale dochazi k analyze toho proc nejaka cast procesu selhava a jak je mozne to zlepsit. I v takovem pripade se to nerusi v ramci jedne retrospektivy ale obecne dochazi nejprve k monitorovani a pochopeni, proc nejaky proces nefunguje a teprve pote k jeho uprave.

SCRUM neni svatej gral, ale pokud si jeho implementaci dokumentujete a venujete se mu, muze docela snadno fungovat. Proste clovek se k tomu musi chovat jako k produktu, kde zakaznikem je cely team. Ale chapu, ze pokud je ve firme problem pokryt testy/slusnou dokumentaci nejaky druh SW, ktery je pro ni kriticky a zivi ji, bude velmi velky problem i kvalitne zacit s nejakymi procesy/metodikou, ktera samozrejme tu implementaci take potrebuje dokumentovat/testovat a udrzovat.

[JS1]

I v takovem pripade se to nerusi v ramci jedne retrospektivy ale obecne dochazi nejprve k monitorovani a pochopeni, proc nejaky proces nefunguje a teprve pote k jeho uprave.

Ten amaterismus spociva v tom, ze si to dela kazdy tym sam. Mohli bychom to delat taky napric tymy a svete div se, to uz minimalne 100 let existuje a rika se tomu projektove rizeni.

SCRUM neni svatej gral, ale pokud si jeho implementaci dokumentujete a venujete se mu, muze docela snadno fungovat.

A nebo se stane to, co se stalo u nas. Retrospektivy zmenily po trech letech proces tak, ze uz to nebyl SCRUM(tm). A prisel nejaky idiot shora se svatou knihou, a prohlasil (naznacil), ze to nedelame podle knihy a tudiz to delame spatne. Takze jsme 3 roky zkusenosti zahodili a zacali prichazet na stejna zlepseni znovu.

[xkucf03]

A nezpůsobuje náhodou tahle otázka¹ víc problémů než užitku? :-)

_{[1] a zejména pak víra v odpovědi}

[JS1]

To se budes muset zeptat nekoho, kdo tu otazku klade, ja to nejsem.

[KS]

Jestli to u tebe takhle funguje, je to chyba implementace, ne procesu :)

To je jako argument, že komunismus není špatný, jen byl špatně implementován.

Pokud mají lidé vůli problémy řešit, komunikují mezi sebou neustále dle potřeby. Nepotřebují synchronizovaný komunikační kanál zvaný "standup".

[Kate]

Nechceš rovnou standupy srovnat s Hilterem? To je argument jako brno :)

Z mé zkušenosti to prostě pomáhá utřídit si čas předem a po zbytek dne toho pak musím řešit míň a na míň věcí se zapomene. A vzhledem k tomu že to celému teamu vyhovuje víc než předešlý systém, kdy probíhala jen desynchronizovaná komunikace, asi je to pro nás správné řešení. Pokud bychom to dělali tak jak bylo naznačeno, tak nám je to ovšem skutečně k ničemu. Proto tvrdím že je to špatná implementace.

[pavlix]

Nechceš rovnou standupy srovnat s Hilterem? To je argument jako brno :)

On nesrovnává standup s Hitlerem. Ani se Stalinem. Ani s komunismem. Jen celkem elegantně zpochybňuje tvůj argument, že je problém pouze v implementaci a nikoli v ideologii. Komunismus je perfektní příměr, protože tam skutečně nedokážeme dobře rozlišit, které jeho problémy byly dané implementací a které samotným nápadem. A pokud se s tímto zpochybněním nedokážeš vyrovnat klidně a racionálně a na místo toho argumentuješ Hitlerem (že je to metaargument na věci nic nemění), podle mě vyvolává jen další pochybnosti.

[Kate]

To co popisoval je špatná implementace daného komunikačního prostředku. Pokud řeknu že metoda a) nefunguje, protože to dělám metodou b), těžko tím mohu prokázat, že je metoda a) objektivně špatně. Dokazuju tím jen, že se to v mém případě špatně dělalo. Mimochodem, tak jak to vyprávěl on bych opravdu standup raději bojkotovala.

A znovu opakuji, nijak nezpochybňuji že to někomu nesedne. Ty jsi příkladem, on je příkladem. Možná by se nám dělalo špatně spolu, protože jsme zvyklí na jin styl práce. Zkusila jsem jich víc a tohle je styl který mi sedne. Tobě asi ne. Což nevypovídá o kvalitě daného systému vůbec nic.

[pavlix]

Proto je potřeba k tomu říct víc než jenom že se jedná o špatnou implementaci, pokud má mít diskuze vůbec nějaký smysl. Problém dnešního scrumu vidím právě v tom, že pokud chce člověk být dobře hodnocen v práci, musí ho zbožňovat nebo jeho zbožňování alespoň předstírat. A to konkrétně tu implementaci scrumu, která se v daném kolektivu provozuje a prosazuje. A není k tomu nucen někým konkrétním, ale celou smečkou. Jakmile jsem se dostal do scrumového týmu, okamžitě jsem pochopil, že musím přistoupit na to, že je ta věc naprosto super a potlačit v sobě jakoukoli antagonii.

[xkucf03]

Problém dnešního scrumu vidím právě v tom, že pokud chce člověk být dobře hodnocen v práci, musí ho zbožňovat nebo jeho zbožňování alespoň předstírat.

Tohle neplatí zdaleka všude a i kdybys byl v týmu, kde je to nadšení pro SCRUM vyšší, tak většinou stačí to tiše tolerovat a myslet si své :-). Ono potížisty a rýpaly sice nemá nikdo rád, ale že by se někde vynucovalo nadšení, to jsem si nevšiml – pokud děláš dobře svoji práci, tak je ostatním jedno, jestli věříš ve SCRUM nebo ne. Nebo ty jsi dělal v týmu, kde to byl náboženský fanatismus a soudili tě podle tvojí víry?

Pokud je to jen ta zkušenost z pohovoru s manažerkou, tak to bych nebral vůbec vážně – prostě třeba jen nevěděla, o čem jiném by se s tebou bavila a na nějakém vývojářském serveru viděla nadšený článek o SCRUMu, tak to považovala za dobré téma.

[pavlix]

Asi nemám sílu komentovat komentář, který z části jen rekapituluje, co jsem napsal, a z části idealizuje, tak vezmu jenom ten konec.

Pokud je to jen ta zkušenost z pohovoru s manažerkou, tak to bych nebral vůbec vážně – prostě třeba jen nevěděla, o čem jiném by se s tebou bavila a na nějakém vývojářském serveru viděla nadšený článek o SCRUMu, tak to považovala za dobré téma.

Je úplně jedno, jak k tomu došla, každopádně mě při pohovoru ničím nepřesvědčila, že bych pro ni chtěl dlouhodobě pracovat, což je podle mě jeden z hlavních smyslů pracovního pohovoru.

[Kate]

Jinak samozřejmě nijak nerozporuji, že to nemusí vyhovovat každému. Jenže o tom to snad je. Pokud člověk pracuje v teamu, je ideální volit nástroje, které teamu vyhovují a pomáhají řešit problémy efektivně i s ohledem na jejich styl práce. Pro někoho je ideál kanban, někomu nevyhovuje nic „agile“ a raději má věci naškatulkované a naplánované předem. Někdo je totální lone wolf a jakákoliv práce v teamu pro něj ani nepřipadá v úvahu.

[xkucf03]

To je jako argument, že komunismus není špatný, jen byl špatně implementován.

On je špatný (resp. hloupý/chybný) a současně byl špatně implementován (resp. na implementaci vlastně ani nedošlo, alespoň tady v ČSSR).

[Heron]

Spíš neškáluje na tak velká společenství, jak si někdo představoval. Tohle funguje (a zcela přirozeně), pro velmi malé skupiny (uvádí se do 150 členů. to se mi zdá trochu moc), kde se jednotliví členové jsou ještě schopni znát a sociálně vázat.

Některé jiné systémy jsou zase na takto malé skupiny nepoužitelné.

[Bystroushaak]

Ono by to možná šlo, kdyby se na to tenkrát uplatnila kybernetika. Jenže se z ní udělala buržoázní pavěda a nic z toho nebylo.

[xkucf03]

Jako, že by o centrálním plánování rozhodoval počítač? Ne, nešlo.

[Bystroushaak]

Jako, že by o centrálním plánování rozhodoval počítač? Ne, nešlo.

Proč? Jaké jsou objektivní důvody to zatratit?

[xkucf03]

Nejde až tak o výpočetní výkon (i když i to je utopie), ale hlavně o to, že počítač nezná individuální preference všech jednotlivých lidí. Aneb počítač neví, jakou subjektivní hodnotu pro tebe má jaká věc nebo činnost (které si chceš pořídit nebo dělat) a co jsi ochoten kvůli nim obětovat. Např.

• Nepůjdu třikrát na oběd (připravím si svačinu doma) a za ušetřené peníze půjdu na večeři.
• Budu dělat přesčasy a v létě pojedu na (dražší) dovolenou.
• Půjdu na vysokou a budu několik let bez příjmů, které bych měl, kdybych šel rovnou pracovat.
• Přestanu pracovat pro jinou firmu a začnu podnikat a vymyslím něco vlastního (přínosného pro ostatní), co dosud nikdo nevymyslel (tudíž neznáme hodnotu té věci).
• Koupím si lepší klávesnici nebo radši lepší monitor?
• AMD nebo Intel?
• ARM nebo x86_64?
• Mám si koupit lístky na Spartu nebo Slávii?
• Koupím si oblečení vyrobené v které zemi?
• Mám vyhodit všechny plastové výrobky a mít v bytě jen dřevěné a kovové?
• Mám jít plavat nebo radši lézt? / Má se postavit bazén nebo horolezecká stěna?
• Mám dojíždět do práce delší dobu nebo radši vzít horší práci blíže domova?
• … + nekonečno podobných a ještě složitějších otázek

Centrálně to nenaplánuješ. Oproti tomu cenový mechanismus funguje.

[Fluttershy, yay!]

počítač nezná individuální preference všech jednotlivých lidí

Ale může znát preference populace nebo skupin lidí (hint: sociologie).

Ostatně, firmy si také dělají průzkum trhu, tak by ho prostě dělala jiná entita.

[xkucf03]

Byl bys jistě náramně nadšený, kdyby tě počítač zařadil na základě „sociologie“ do nějaké skupiny a předpokládal, že se budeš chovat a mít stejné preference jako průměr této skupiny a to i proti tvé vůli.

[Fluttershy, yay!]

kdyby tě počítač zařadil na základě „sociologie“ do nějaké skupiny a předpokládal, že se budeš chovat a mít stejné preference jako průměr této skupiny a to i proti tvé vůli

To se děje právě teď.

[trekker.dk]

Pro jistotu se vracíte k náznakům a jinotajům, abyste nemusel napsat nějakou skutečnou myšlenku?

[Fluttershy, yay!]

Voda je mokrá.

[Bystroushaak]

Nejde až tak o výpočetní výkon (i když i to je utopie), ale hlavně o to, že počítač nezná individuální preference všech jednotlivých lidí. Aneb počítač neví, jakou subjektivní hodnotu pro tebe má jaká věc nebo činnost (které si chceš pořídit nebo dělat) a co jsi ochoten kvůli nim obětovat. Např.

Jasně, já to chápu. Ale trh není složený jen z samostatně nakupujících lidí, spoustu potřeb mají firmy více/méně pravidelně. Jinak v podstatě každá firma tohle teď dělá, jen interně, ne externě v nějakém ERP systému. Ono ani ta původní Sovětská idea nebyla taková, že to bude řídit jeden počítač, měla to být síť počítačů v podnicích. Viz The Soviet web: the tale of how the USSR almost invented the internet. Osobně si nemyslím, že by to dávalo smysl pro 100% trhu, ale myslím, že vysoké desítky procent by se asi pokrýt daly (distribuce energie a pohonných hmot třeba) a ten zbytek by se dal vyrovnat kapitalismem.

Tím samozřejmě nechci tvrdit, že bych chtěl komunismus, jen že by mě to zajímalo z čisté zvědavosti, jako zajímavý model.

[xkucf03]

Ty obchodní vztahy lze do jisté míry automatizovat a ve velkých firmách se to používá už dnes, viz dodavatelsko-odběratelský řetězec a automatické objednávání zboží, o kterém systém usoudí, že je zrovna potřeba.

Ale tomu bych jednak neříkal „centrální plánování“ – to by tam musela být nějaká centrální autorita, která by koordinovala objednávky M:N mezi více firmami a na základě nějakého algoritmu rozhodovala, kdo od koho co a za kolik nakoupí. To by asi možné bylo, ale je otázka co dělat ve chvíli, kdy se někomu výsledky výpočtu nebudou líbit a nebude je považovat za optimální. Má se jim podřídit proti své vůli? Nebo bude mít možnost vystoupit z nějaké aliance a obchodovat si „ručně“ po svém?

A jednak za zásadní považuji, aby to bylo na dobrovolné bázi – zatímco pojem „centrální plánování“ je spjatý s komunismem a s tou nedobrovolností. Dovedu si to představit na dobrovolné bázi, kdy by se nějaká skupina firem dohodla, že objednávky mezi nimi nebudou zadávat nákupčí, ale programy + tam bude nějaký společný koordinační prvek (algoritmus), který si společně odsouhlasí tak, aby z dlouhodobého hlediska vyhovoval všem a byl v průměru nestranný (že to jednou vyjde výhodnější pro jednoho a jindy pro jiného budou považovat za náhodu a budou ochotní se tomu dobrovolně podřídit).

Na úrovni spotřebitelů by šlo v omezené míře dělat něco podobného, ale opět: musí to být na dobrovolné bázi. A pak je to zcela v intencích volného trhu a s komunismem/socialismem to nemá nic společného.

Občas něco v tomhle smyslu funguje už dnes – viz crouwdfunding. To je vlastně algoritmus, který říká: zkusíme vybrat peníze a pokud se jich vybere dost, tak to znamená, že je po dané věci poptávka a daná věc se začne vyrábět, a pokud se všechny potřebné peníze vybrat nepodaří, tak se ty vybrané vrátí a nic se vyrábět nebude. Je to vlastně způsob optimalizace a automatizace obchodních vztahů, který odstraňuje část rizika a nutnost vyrábět/vyvíjet na sklad něco, o čem ještě není jisté, že o to bude zájem. Kdežto klasicky bez této automatizace by se podnikatel musel spolehnout jen na průzkumy trhu a svoji intuici.

[JS1]

počítač nezná individuální preference všech jednotlivých lidí

V tom problem neni, muzes se jich i zeptat, nebo jim dat utratit nejake pseudo-penize.

Komunismus selhal protoze se kradlo. Ne vazne, ja si myslim, ze selhal proto, ze centralni planovani se proste snazi optimalizovat az prilis, a to pak vede k tomu, ze system je velice krehky a snadno se v nem siri poruchy. (Ja to pekne vidim ve velke firme - spousta veci se dela s velkou slavou centralne, aby to "bylo efektivni", a pak to tise ztroskota.) Kapitalismus je dost neefektivni (je v nem znacna redundance), a diky tomu robustni vuci nahlym porucham (treba zivelnym katastrofam).

Potiz je, ze ideologove jako ty nejsou ochotni pripustit takovou nuanci reality, ze treba existuje kompromis mezi efektivitou a robustnosti, a ze zadne "optimum" proste neni.

[Randy_Sh]

Komunismus selhal protoze se kradlo.

Kradení byl jen vedlejší produkt toho, že všechno bylo státní (tj. všech a nikoho) a tím pádem nebyla motivace hlídat majetek. Dnes si kapitalista sakra pohlídá, aby mu zaměstnanci firmu nerozkradli, protože to jsou jeho peníze.

Ne vazne, ja si myslim, ze selhal proto, ze centralni planovani se proste snazi optimalizovat az prilis, a to pak vede k tomu, ze system je velice krehky a snadno se v nem siri poruchy.

Centrální plánování je nepružné a nemůže podchytit všechno. Neviditelná ruka trhu je pružnější. Když dnes budou na trhu chybět třeba hřebíky, nepochybně se najde někdo, kdo je vyrobí nebo doveze. Protože má silnou motivaci vydělat peníze. Tohle stačí, není potřeba nic plánovat. Za socialismu by soudruzi prohlásili, že na to budou v příští pětiletce pamatovat.

[smazáno]

Tohle je presne to co do nas jeli na zakladce jako brainwashing zly zly komunismus :).

[Randy_Sh]

Zkuste trochu podrobněji rozebrat, kde se podle vás pletu.

[smazáno]

Pokud bych mel tehdy na zakladce zrovna provokativni naladu tak se ozvu "a proc by kdokoliv stavel tovarnu na hrebiky, kdyz jinde vydela vic?" ... a mam z toho pruser .

[Randy_Sh]

Pokud bych mel tehdy na zakladce zrovna provokativni naladu tak se ozvu "a proc by kdokoliv stavel tovarnu na hrebiky, kdyz jinde vydela vic?" ... a mam z toho pruser .

Protože když bude hřebíků nedostatek, tak poroste jejich cena a tím pádem na nich bude možné opravdu hodně vydělat.

[smazáno]

Myslel jsem to ciste pro pobaveni.

Spis jako ukazku, ze ani jeden z tech argumentu nema nic spolecneho s realitou.

[Randy_Sh]

Spis jako ukazku, ze ani jeden z tech argumentu nema nic spolecneho s realitou.

Jak nemá společného s realitou? Realita je taková, že výrobci hřebíků dnes nikdo neurčuje, kolik jich má vyrobit nebo že má vůbec vyrábět hřebíky a ne něco jiného. Prostě ty hřebíky vyrábí, protože mu to vydělává. Kdyby zavřel továrnu, najde se někdo jiný, kdo ho nahradí, protože vidí výdělek. Četl jsem, že ještě v 60. letech tohle soudruhům v SSSR nedocházelo a mysleli si, že v USA mají nějaké tajné plánovací centrum, které řídí americkou ekonomiku a je lepší než sovětské.

[trekker.dk]

A kde máte tu jistotu, že jinde vydělá víc? A že všichni, koho napadne "mohl bych vyrobit nebo dovézt hřebíky" jinde vydělají víc? To za situace, kdy je hřebíků málo a lidi potřebují hřebíky.

[melkors]

Dnes si kapitalista sakra pohlídá, aby mu zaměstnanci firmu nerozkradli, protože to jsou jeho peníze.

Optimisto. Tohle muze platit ve firme, kde je jeden majitel a zna vsechny (a to jeste s vyjimkami - vim o nekolika pripadech vyhazovu na hodinu s tim, ze majitel radeji ani nechtel vedet, kolik penez se vlastne ztratilo). V korporatu je to v podstate stejne jako za socialismu ...

[Randy_Sh]

Optimisto. Tohle muze platit ve firme, kde je jeden majitel a zna vsechny (a to jeste s vyjimkami - vim o nekolika pripadech vyhazovu na hodinu s tim, ze majitel radeji ani nechtel vedet, kolik penez se vlastne ztratilo). V korporatu je to v podstate stejne jako za socialismu ...

Netvrdím, že se dnes takové věci nedějí, ale ta míra kradení byla tenkrát zcela jiná.

[kralyk z abclinuxu]

Netvrdím, že se dnes takové věci nedějí, ale ta míra kradení byla tenkrát zcela jiná.

Skutečně? Můžeš to něčím podložit?

Nechápej mě špatně, nechci minulý režim obhajovat a těžce mi vadí dnešní procento voličů volících KSČM (nebo estébáka Babiše). Jde mi spíš o to, že míra rozkrádání nebyla IMHO ten hlavní problém, ten hlavní problém vidím zejména v nedemokratičnosti, nesvobodě, v policejním státu, v tom, že země byla kolonií SSSR, a tak dále. Ale rozkrádání? Ano, rozkrádalo se a to ve velkém. Nelíbí se mi to. Nicméně dnes se snad ve velkém nerozkrádá? Mně přijde že ano, a to zcela bez ohledu na ideologii.

[Randy_Sh]

Skutečně? Můžeš to něčím podložit?

Nemůžu. Ale dobře si ty časy pamatuji. Ovšem je pravda, že jeden manažer dokáže škrtem pera ukrást víc než deset dělníků za celý rok.

Jde mi spíš o to, že míra rozkrádání nebyla IMHO ten hlavní problém, ten hlavní problém vidím zejména v nedemokratičnosti, nesvobodě, v policejním státu, v tom, že země byla kolonií SSSR, a tak dále.

Hlavní problém byla celková neefektivita systému.

Nicméně dnes se snad ve velkém nerozkrádá? Mně přijde že ano, a to zcela bez ohledu na ideologii.

Ano, ale dnes se rozkrádají především veřejné prostředky a podle toho také ty veřejné služby vypadají.

[kralyk z abclinuxu]

Ovšem je pravda, že jeden manažer dokáže škrtem pera ukrást víc než deset dělníků za celý rok.

No právě.

Hlavní problém byla celková neefektivita systému.

Strašidelný názor.

Ano, ale dnes se rozkrádají především veřejné prostředky a podle toho také ty veřejné služby vypadají.

To je IMHO částečně bias způsobený tím, že člověk to rozkrádání veřejných prostředků vidí / cítí, narodzíl od nějakého soukromého někde kdovíkde, a částečně to je dáno tím, že veřejný rozpočet je AFAIK stále řádově jinde než rozpočet i těch největších firem u nás.

[kralyk z abclinuxu]

Jinak ještě bych se chtěl zeptat k té neefektivitě / centrálnímu plánování:

Proč centrální plánování na úrovni státu vadí a je to zlo, zatímco ve firmách to je dobrá věc?

[ehm]

Když zkrachuje firma, zastoupí ji jiná. Když zkrachuje stát...

Nemluvě o tom, že ta komplexita je drasticky odlišná.

[JS1]

Nemluvě o tom, že ta komplexita je drasticky odlišná.

Ano, kdyz srovname treba kubanskou ekonomiku v 50. letech a logisticky system Walmartu, tak je to skutecne ve slozitosti nekde jinde.

Slozitost nebyla problem ani tehdy, a tim mene je to problem dnes. Potiz byla casto v tom, ze planovac rekl treba "jen tato tovarna bude vyrabet nejako soucastku". Pak se to z toho ci onoho duvodu zdrzelo a tim se zdrzelo vsechno. Kdyz zkrachuje firma v kapitalismu, ano, zastoupi ji jina, pokud existuje, ma know-how atd. Tudiz musi existovat a vyrabet paralelne, redundantne.

[ehm]

Díváš se na to špatně. Pokud Walmart nebude schopný dodávat konkrétní typ produktu, přijde o část tržeb, ale fungovat bude nadále. Pokud v celé zemi s centrálně plánovaným hospodářstvím nebude produkt, po kterém existuje poptávka, k sehnání, klesne lidem životní úroveň.

[kralyk z abclinuxu]

To ale pouze řešíš závažnost důsledků (ne)fungování toho systému. To je ale zaprvé vedlejší a zadruhé to platí pro jakýkoli systém - pokud bude selhávat na úrovni státu, budou důsledky vždy závažnější.

[ehm]

Hm. Možná to bude tím, že mě nezajímá systém jako takový, ale jeho konkrétní použití – zde centrálně plánováné hospodářství na úrovni celého státu. V opačném případě za chvíli skončíme u diskuze, jestli je lepší centralizovaný nebo decentralizovaný VCS.

[kralyk z abclinuxu]

Když zkrachuje firma, zastoupí ji jiná. Když zkrachuje stát...

Ano, ale i úspěšné dlouhodobě nekrachující firmy mají centrální plánování.

PS. Nejsem proponent centrálního plánování.

[ehm]

A jiné firmy krachují. Přirozený výběr.

[xkucf03]

Firma někomu patří, ten ji řídí a nese rizika (že přijde o svůj majetek).

Majitel firmy (a následně ta hierarchie pod ním) může vydávat rozkazy svým podřízeným a ti je musí plnit. Pokud se jim to nelíbí, tak mohou dát výpověď. Předpokládám, že bys ale nechtěl žít v totalitním státě a poslouchat rozkazy shora, ne?

[kralyk z abclinuxu]

Firma někomu patří, ten ji řídí a nese rizika (že přijde o svůj majetek).

To, že ten, kdo řídí, vlastní firmu, platí typicky pouze u malých firem.

Předpokládám, že bys ale nechtěl žít v totalitním státě a poslouchat rozkazy shora, ne?

Tohle je ta otázka svobody/nesvobody, kterou já jsem zmiňoval jako hlavní problém minulého režimu. Randy a ty (myslimže?) jste si stěžovali hlavně na tu neefektivitu. Tudíž jsem se ptal, proč je státní centrální plánování neefektivní, zatímco centrální firemní plánování efektivní.

[xkucf03]

To, že ten, kdo řídí, vlastní firmu, platí typicky pouze u malých firem.

Majitel může řízení delegovat – a to je taky rozhodnutí a taky za něj nese odpovědnost (riziko, že to ti manažeři povedou neefektivně nebo to dokonce rozkradou).

Sice bys mohl říct, že občané mohou delegovat rozhodování na politiky a ti budou řídit všechny firmy v zemi. Jenže jaká bude motivace to dělat dobře? Mezi firmami je jednak konkurence, což je tlačí dopředu, a jednak je lze mezi sebou porovnávat. Pokud např. celý obor roste o 10 % a tvoje firma roste jen o 2 %, tak buď jsi něčím hodně specifický nebo to vedeš špatně a měl bys na efektivitě zapracovat. Pokud na tom naopak budeš líp než zbytek tvého oboru, tak víš, že nemusíš tolik šetřit, můžeš třeba zvýšit platy nebo rozjet nějaký interní vývojový projekt.

Když ale budou všechny firmy státní, tak s čím to porovnáš? Jak budeš vědět, jestli to děláš dobře nebo ne? Jestli ti pověření manažeři vedou firmy dobře nebo bys je měl vyměnit?

(kromě toho tu jsou jiné problémy, psal jsem to už jinde, třeba že neznáš preference lidí, nevíš, jakou má co pro koho subjektivní hodnotu, nedokážeš to měřit…)

Tohle je ta otázka svobody/nesvobody, kterou já jsem zmiňoval jako hlavní problém minulého režimu.

Ona ta ekonomická a osobní svoboda se prolínají. Obecně tu svobodu ani nemá moc smysl dělit na dvě.

Představ si, že máš nápad na nějakou inovaci a chceš začít podnikat. V tržním hospodářství prostě začneš podnikat, buď zbohatneš nebo zkrachuješ (riziko neseš jen ty sám, takže se nemusíš nikoho doprošovat, jestli smíš, případně nese riziko ten, kdo ti na podnikání půjčil). Co bys ale dělal v centrálně plánovaném hospodářství? Zapsal bys svoji inovaci do nějaké databáze a pak čekal, až ji počítač vyhodnotí jako vhodnou či nevhodnou k realizaci? Co když ji zamítne, ale ty a další lidé přesto věříte, že to má smysl a mělo by se to zkusit?

A zásadní otázka: kdo bude programovat ten centrální plánovací systém? Lidi jsou dneska sotva schopní kontrolovat zákony – a to jsou psané česky – přesto se tam politikům často podaří udělat nějakou skulinu, kterou následně zneužijí. Jak by asi občané kontrolovali zdrojový kód programu, který řídí hospodářství? To by pro ně byla úplně černá skříňka. Asi by kolem toho vzniklo nějaké novodobé náboženství… A lidé, kteří by ten systém programovali a spravovali by měli neomezenou totalitní moc nad všemi ostatními.

[Käyttäjä 11133]

Mezi firmami je jednak konkurence, což je tlačí dopředu, a jednak je lze mezi sebou porovnávat

Zatím co v mezi městy, kraji a zeměmi konkurence není a srovnávat se nedají... Migrace taky vlastně neexistuje...

[kralyk z abclinuxu]

Majitel může řízení delegovat – a to je taky rozhodnutí a taky za něj nese odpovědnost (riziko, že to ti manažeři povedou neefektivně nebo to dokonce rozkradou).

Takže v podstatě stát jako firmu už máme

Zbytek komentáře moc nechápu, nepřije mi, že by se týkal mé otázky...

[Randy_Sh]

Proč centrální plánování na úrovni státu vadí a je to zlo, zatímco ve firmách to je dobrá věc?

Odpovím otázkou - proč by měl stát nařizovat Škodovce, kolik mají příští rok vyrobit oktávek? Vidíte v tom nějaký přínos? Myslíte, že úředník v plánovací komisi vyhodnotí situaci lépe než příslušní lidé v automobilce?

[Fluttershy, yay!]

Rozdíl může být např. v tom, kdo je podílníkem podniku, totiž v jednom případě – pokud se nejedná o autoritářský režim – občané. Pak je složitější, aby podnik jednal v přímém rozporu s veřejným zájmem.

[Fluttershy, yay!]

Odtud např. internalizace externalit.

[kralyk z abclinuxu]

Taky odpovím otázkou - proč by měl nějaký manažer vysoko v hierarchii nařizovat našemu týmu, jestli můžem nebo nemůžem nabrat nového zaměstnance? Myslíš, že nějaký manažer na nějakém boardu vyhodnotí situaci líp než my v týmu, kdy přesně víme, kolik dá práce splnit očekávání? Vžyť ani pořádně neví, co děláme...

Jinak s těmi automobilkami mi to nepřijde jako úplně dobrý příklad - AFAIK nadprodukce aut je problém, krom toho je to druh zboží s hodně velkou ekologickou zátěží a negativa čistě tržního pojetí se zrovna v téhle kategorii hodně projevují.

[Randy_Sh]

Taky odpovím otázkou - proč by měl nějaký manažer vysoko v hierarchii nařizovat našemu týmu, jestli můžem nebo nemůžem nabrat nového zaměstnance? Myslíš, že nějaký manažer na nějakém boardu vyhodnotí situaci líp než my v týmu, kdy přesně víme, kolik dá práce splnit očekávání? Vžyť ani pořádně neví, co děláme...

Rozdíl je v tom, že vy něco chcete (nového zaměstnance, vyšší platy), ale platí to firma. Nějaká kontrola nákladů musí být. Jen pořád nevím, jestli by to nějaký centrální plánovač zvládnul naplánovat lépe. Zatím stát není schopen ani zajistit dostatek míst ve školkách, ačkoliv to je krásně předvídatelný jev (letos se narodilo hodně dětí, které za tři roky budou potřebovat školku).

Jinak s těmi automobilkami mi to nepřijde jako úplně dobrý příklad - AFAIK nadprodukce aut je problém,

Jaká nadprodukce? V současnosti se na nové auto musí čekat.

krom toho je to druh zboží s hodně velkou ekologickou zátěží a negativa čistě tržního pojetí se zrovna v téhle kategorii hodně projevují.

Automobilka byl jen ilustrační příklad. Stejně tak mohlo jít o firmu vyrábějící tkaničky do bot.

[kralyk z abclinuxu]

Rozdíl je v tom, že vy něco chcete (nového zaměstnance, vyšší platy), ale platí to firma. Nějaká kontrola nákladů musí být. Jen pořád nevím, jestli by to nějaký centrální plánovač zvládnul naplánovat lépe. Zatím stát není schopen ani zajistit dostatek míst ve školkách, ačkoliv to je krásně předvídatelný jev (letos se narodilo hodně dětí, které za tři roky budou potřebovat školku).

Nechci rozebírat interní záležitosti firmy, kde pracuju, ale věcí, které jsou krásně předvítalné, ale přitom byly podělány, tam je taky dost.

Jinak problém se školkami by měla elegantně vyřešit neviditelná hnáta, ne?

Hlavně jsem se tou otázkou ale zajímal, proč centrálně plánovaný stát krachuje, zatímco centrálně plánovaná firma prosperuje. (Možná jsem to měl lépe formulovat.)

[Jendа]

Jinak problém se školkami by měla elegantně vyřešit neviditelná hnáta, ne?

Tak v soukromých školkách místa jsou, ne? Akorát ta cena…

[pavlix]

Ta cena je pro většinu našeho obyvatelstva likvidační. To si můžu dovolit já, ale i tak je to náklad srovnatelný s náklady na bydlení. A ve skutečnosti se ani v soukromé to místo v danou chvíli najít nemusí, navíc tam dáváš do péče člena rodiny a to zrovna trh moc neřeší a regulace nejsou nutně na škodu.

[ehm]

O děti má pečovat matka.

[vencour]

A chcete na tohle téma diskutovat?
Mimochodem pečovat nebo vychovávat?

[pavlix]

Nesouhlasím.

[ehm]

Šak já len dúfám, že pokrachuješ aj ty a nebudeš mať ani na Internet, abys tam nemohol písať somariny!

[Randy_Sh]

Jinak problém se školkami by měla elegantně vyřešit neviditelná hnáta, ne?

Jak už tady někdo napsal, soukromé školky tuto mezeru zaplňují, ale nechají si za to pěkně zaplatit. Stát by měl především zajišťovat základní věci, kde trh moc nefunguje (bezpečnost, zdravotnictví, vzdělání). Přitom toho není moc schopen, je hrozně "překvapen", když děti přeplní školky. Stejně tak jsou úřady "překvapeny", že v nemocnicích chybí doktoři i sestry. Oni dlouhé roky odcházejí za lepšími platy na Západ a nikoho zodpovědného nenapadne, že to časem bude problém. Opravdu myslíte, že když stát není schopen efektivně zajistit takové základní věci, tak by nějakým zázrakem dokázal řídit celou ekonomiku?

Hlavně jsem se tou otázkou ale zajímal, proč centrálně plánovaný stát krachuje, zatímco centrálně plánovaná firma prosperuje.

Jde o princip subsidiarity. Rozhodování má probíhat na nejnižší možné úrovni. Továrna si rozhodne, co má vyrábět, podstatně lépe než nějaký úředník v plánovací komisi. Nakonec i ve firmách vidíme, že s růstem firmy nastupuje byrokracie a vytrácí se pružnost a inovace.

[pavlix]

To je jednoduché. Lidé dělají překvapené, pokud za toto překvapení nemůžou být nijak potrestáni.

[kralyk z abclinuxu]

Opravdu myslíte, že když stát není schopen efektivně zajistit takové základní věci, tak by nějakým zázrakem dokázal řídit celou ekonomiku?

No to by nejspíše nedokázal.

Jde o princip subsidiarity. Rozhodování má probíhat na nejnižší možné úrovni.

Ok, tohle beru.

Ovšem nevim, jestli úplně věřim tomu, že volný trh tohle řeší, vzhledem k tomu, že pozorováním vidím, že typicky vede postupem času ke konsolidaci rozhodování do vyšších a vyšších míst (tím, že firmy rostou a slučují se).

[xkucf03]

proč by měl nějaký manažer vysoko v hierarchii nařizovat našemu týmu, jestli můžem nebo nemůžem nabrat nového zaměstnance? Myslíš, že nějaký manažer na nějakém boardu vyhodnotí situaci líp než my v týmu, kdy přesně víme, kolik dá práce splnit očekávání? Vžyť ani pořádně neví, co děláme...

On to ale dělat nemusí. Nijak to nesouvisí s kapitalismem a ten který podnik si může nastavit interní pravidla jak chce. Rozumná firma v tomhle nechá dostatečnou volnost a nechá tyhle věci rozhodovat na úrovni, kde k tomu jsou kompetentní lidi. Když si ta firma nastaví špatná interní pravidla, tak bude v důsledku nekompetentních rozhodnutí nabírat nevhodné lidi a to ji oslabí oproti konkurenci.

[kralyk z abclinuxu]

Hm, opět mam trochu problém interpretovat, jak tohle souvisí s mou otázkou. Chápu to tedy správně tak, že považuješ za špatné / neefektivní i centrální plánování ve firmách?

[xkucf03]

Psal jsi konkrétně o nabírání nových lidí do týmu – to fakt asi nemá smysl dělat centrálně. Maximálně nejvyšší vedení nastaví nějaká obecná kritéria, ale o konkrétních uchazečích bude rozhodovat už hlavně ten, kdo pak bude jejich nadřízený.

Totéž různé vývojové projekty nebo inovace – nejvyšší vedení nemusí všemu rozumět a může nechat určitou volnost a počítat s tím, že část projektů nedopadne, ale část bude úspěšná a v součtu se to vyplatí. Kdyby se pokoušeli z centra řídit všechno, tak by třeba nedopadlo nic, protože by projekt dokončili pozdě a konkurence by je na trhu předběhla.

Nejde tedy obecně říct, jestli je centrální plánování ve firmě dobré nebo ne – některé věci je dobré držet jednotné, ale ne všechno, protože to se uřídit ani nedá.

[xkucf03]

ten hlavní problém vidím zejména v nedemokratičnosti, nesvobodě, v policejním státu, v tom, že země byla kolonií SSSR

Morálně to špatné samozřejmě je, ale většina lidí na tyto problémy moc nenarážela¹ a žila si celkem v pohodě, většinu času řešili běžné věci jako dnes, ne nějaké komunisty, co je ale trápilo byly ty materiální nedostatky. Pokud by byl komunismus ekonomicky úspěšný, možná bychom vyvěšovali rudé vlajky dodnes. Podívej se třeba na Čínu – běžného Číňana fakt netrápí, že tam vládne komunistická strana, možná je na to i hrdý, ale zajímá ho, jak dobře se má.

Tím rozhodně nechci obhajovat nesvobodné režimy, ale chci tím říct, že komunismus/socialismus má kromě těch morálních vad i zásadní a neřešitelné ekonomické nedostatky a nedokáže efektivně uspokojit materiální potřeby lidí.

_{[1] musel jsi něčím provokovat, upozorňovat na sebe… nebo v tom pak byly osobní zájmy, kdy někdo zneužil svoji funkci, aby ti ublížil}

[kralyk z abclinuxu]

Morálně to špatné samozřejmě je, ale většina lidí na tyto problémy moc nenarážela1 a žila si celkem v pohodě, většinu času řešili běžné věci jako dnes, ne nějaké komunisty, co je ale trápilo byly ty materiální nedostatky.

IMHO ty materiální nedostatky byly způsobený zejména obchodním embargem na půlku světa naordinovaným SSSR spíše než neefektivitou vnitrostátního systému.

Tím nechci vyjádřit názor, že by reálný socialismus byl efektivní ekonomický systém, to si nemyslim, jen si nemyslim, že by kapitalismus fungoval (o tolik) lépe. Ryzí (neoliberální) kapitalismus by při pokusu o reálné nasazení IMHO fungoval podobně špatně jako minulý režim (jsem si celkem jistý, že i na to porušování lidských práv by došlo - 'neviditelná ruka trhu' by si o to řekla). Kapitalismus říznutý nějakými prvky socialismu a se silnou participací státu tak jak ho máme dnes, příp. jak ho mají jiné vyspělé státy světa, funguje lépe, respektive, řekněme, méně špatně...

[xkucf03]

IMHO ty materiální nedostatky byly způsobený zejména obchodním embargem na půlku světa naordinovaným SSSR spíše než neefektivitou vnitrostátního systému.

I kdyby, tak půlka světa (východní blok) je stále dost velký trh, aby na něm mohlo fungovat dobře hospodářství – ono ale nefungovalo.

[kralyk z abclinuxu]

Ano, zatímco kapitalismus tam funguje výborně a ve zbytku světa taky funguje výborně, že...

Mně přijde, že část lidí prostě potřebuje udělat tu zkušenost s pořádným průserem, aby naznali, že idealistické* ideologie jako komunismus nebo čistý kapitalismus nejsou to pravé.

*) ie. založené na ideálech spíše než pragmatismu, tj. místo přístupu typu "pojďme se podívat, co funguje a proč to funguje a odpíchnout se od toho" se použije přístup typu "myšlenka X je dobrá → je potřeba ji implementovat a to, co jí neodpovídá, vymítit".

[Bystroushaak]

Ano, zatímco kapitalismus tam funguje výborně a ve zbytku světa taky funguje výborně, že...

Co funguje líp?

[kralyk z abclinuxu]

Co funguje líp?

Politický systém, který funguje dobře, IMHO neexistuje. Lépe než reálný socialismus a neolibreální kapitalismus fungují, zdá se, systémy, které mají nejvyspělejší státy světa, tj. typicky jakýsi hybrid prvků kapitalismu a socialismu. (Je samozřejmě otázka, jak moc je systém vyspělých zemí závislý na exploitaci třetího světa.)

[ehm]

Lépe než reálný socialismus a neolibreální kapitalismus fungují, zdá se, systémy, které mají nejvyspělejší státy světa, tj. typicky jakýsi hybrid prvků kapitalismu a socialismu.

Trochu odbočím.

Největší bolestí ekonomiky jsou omezené přírodní zdroje. A je to i největší problém kapitalismu a nejspíš i nejčastější zdroj kritiky. Ten rozdíl mezi chybnou implementací a principielní chybou není vždy tak snadno rozlišitelný. Bohužel to není (tak) snadno řešitelné.

Z hlediska „sociální spravedlnosti“ není úplně fér, že jeden člověk zdědil rozsáhlé pozemky, polnosti, lesy a uhelné doly a druhý člověk nic. Přitom i on je rovnocenným občanem státu a možná se i jeho předci podíleli na obraně země – tedy i těch přírodních zdrojů, které teď ale kontroluje omezená skupina lidí.

Občas si pohrávám s myšlenkou, jestli by veškeré přírodní zdroje neměly připadat celé společnosti – ideálně tak, aby opravdu každý měl určitá majetková práva. Otázka je, jak by to mělo vypadat prakticky, pokud to aplikujeme více/méně doslovně. Úvahy tímto směrem asi nechci rozvádět, protože to k ničemu smysluplnému nevede.

Čili ta praktičtější úvaha by asi byla taková, že třeba uhelný důl bude vlastnit stát, a pouze jej bude pronajímat těžební společnosti. Ta bude státu za pronájem platit – cena může být odvozena třeba z předpokládaného objemu těžby a tržní ceny uhlí tak, aby bylo možné pokrýt náklady a vygenerovat třeba nějaký přiměřený zisk. (Pokud dokáže těžit efektivněji, náklady jim klesnou a zisk stoupne; dobře pro ně). To vytváří pro státní rozpočet příjem, který opravdu může být dobrou součástí nepodmíněného ZP každého občana.

Bohužel to není tak jednoduché a ta úvaha pokračuje dál – k pozemkům. Kdybychom teď kolonizovali novou planetu, je nakrásně možné si pozemky spravedlivě rozdělit. Udělá se nějaký územní plán, rozdělí se parcely (každý dostane stejně velkou) a je to.

O generaci později nastane situace, kdy se pozemky začnou dále dělit v důsledku dědění. Lidé s menším počtem sourozenců budou disponovat většími pozemky než lidé s větším počtem sourozenců. V praxi je to o to složitější, že na pozemcích už budou stát hotové budovy. Jak to pak řešit? Zboří velký barák veprostřed pozemku, pozemek rozdělí (třeba) na dva menší a každý si postaví svůj menší domek?

O několik generací dál jsme možná v situaci, kdy stavět individuální domky už ani není možné a je třeba začít stavět výškové budovy. Opět – jak?

Problém je možné odložit tím, že se počáteční velké území nerozdělí hned celé, nýbrž se vezme jen jeho část. Každému dalšímu občanovi se pak prostě přidělí nový pozemek stejné velikosti z dosud nerozděleného území. Ale jak jsem říkal – tím se problém jen oddálí.

Dost možná by taky bylo nutné zbavit majitele práva pozemek prodat, protože jinak by to nevyhnutelně – dříve či později – vedlo k současnému stavu.

Záměrně zanedbávám takové případy, jako že majitel pozemku A s majitelkou pozemku B založí rodinu a pravděpodobně budou chtít bydlet na jednom místě, ne na dvou nesousedících pozemcích. Ideálně by tedy chtěli dostat jeden pozemek o stejné celkové velikosti jako jejich dva menší pozemky, jenže takový pozemek nemusí být vůbec k dispozici.

Že jsou potřeba ještě nějaké průmyslové pozemky, dopravní infrastruktura, obchody apod. raději zanedbávám, protože tím by se to zkomplikovalo ještě víc.

Vlastně se tím dostáváme zpátky k tomu centrálnímu plánování. Jak tohle systematicky vyřešit? Jen ta samotná představa mi přijde fakt úchylná i přesto, že jsem to maximálně idealizoval a zjednodušil a vyhnul se nejtěžším otázkám, které do toho nevyhnutelně vstupují.

Na to někdo může říct, že lidé nemovitosti nemají vlastnit vůbec a o bydlení se bude starat stát. Ten by optimálně a efektivně přiděloval (půjčovat) byty a domky. Ale zase – kde se vezmou peníze na výstavbu? To bude formou nějakého jednorázového poplatku, který když zaplatí, tak budou mít do konce života nárok na bydlení v bytu/domku o dané ploše a dispozicích? A když se dva takoví, co už si „předplatili“ garsonku, vezmou, tak zase dostanou větší byt o stejné rozloze? A pokud se rozvedou, tak se to zase rozdělí na dva menší byty? A nebo se nic platit nebude a prostě každý bude mít právo na bydlení? A až si najde práci na druhém konci města a bude trávit půl dne dojížděním, tak si znovu podá žádost a stát zařídí přesun? Etc.

A samozřejmě ta údržba/výstavba něco stojí (minimálně za práci) a stát by nesl veškerou odpovědnost. A tak dál.

No, fakt nevidím jakoukoliv snadnou cestu ven. Možná by davkol mohl místo nahodilých jednovětných útržků vyklopit nějakou komplexní teorii, jak si představuje, že by ekonomika mohla fungovat.

[JS1]

Rekl bych, ze popisujes georgismus. Dokonce si o tom muzes precist i skoro 140 let starou knihu.

[ehm]

Dobrá reference. Díky.

[xkucf03]

Tržní hospodářství / volný trh je výchozí přirozený stav – jakýkoli jiný systém je změna oproti tomuto výchozímu stavu a pokud ji navrhuješ, tak bys ji měl nějak obhájit.

BTW: společnost k tomuto přirozenému stavu konverguje, i navzdory aktuálnímu politickému systému – když např. před rokem 1989 byl uměle stanovený měnový kurz, za který ale nešlo sehnat potřebné množství zahraniční měny (a ta tudíž musela být na příděl), tak lidé mezi sebou obchodovali za tržní ceny.

[kralyk z abclinuxu]

Tržní hospodářství / volný trh je výchozí přirozený stav

Ne, to tedy není.

"Přirozený stav" je něco, co už dávno neexistuje, přestalo to existovat postupně někdy od zemědělské revoluce (15 tisíc let zpátky jestli si to dobře pamatuju?). Od té doby už se člověk nikdy k přirozenému stavu nevrátil, naopak, funguje čím dál tím více nepřirozeně. Dnešní společnost už je tak daleko, že žádný "přirozený default" nemá.

[Randy_Sh]

IMHO ty materiální nedostatky byly způsobený zejména obchodním embargem na půlku světa naordinovaným SSSR spíše než neefektivitou vnitrostátního systému.

I kdyby, tak půlka světa (východní blok) je stále dost velký trh, aby na něm mohlo fungovat dobře hospodářství – ono ale nefungovalo.

Nejsem si úplně jistý, o jakém embargu je přesně řeč a kdo ho na koho uvalil. Ale nemělo by to embargo poškodit obě strany stejně? Pokud vedlo ke zhroucení pouze jedné strany, nebylo s jejím systémem něco špatně?

[kralyk z abclinuxu]

Pokud vedlo ke zhroucení pouze jedné strany, nebylo s jejím systémem něco špatně?

Samozřejmě, že ano. Tam toho byly špatně spousty a spousty.

[kralyk z abclinuxu]

Dnes si kapitalista sakra pohlídá, aby mu zaměstnanci firmu nerozkradli, protože to jsou jeho peníze.

Pobavilo.

Neviditelná ruka trhu je pružnější.

Tak vzhledem k tomu, že neviditelná ruka trhu je z nějakých 80% imaginární konstrukt, tak má pružnost v podstatě neomezenou.

[xkucf03]

V tom problem neni, muzes se jich i zeptat, nebo jim dat utratit nejake pseudo-penize.

Takže bychom vlastně simulovali cenový mechanismus a na základě výsledků té simulace nějak rozhodli? Proč nenechat rozhodovat přímo cenový mechanismus? Kdo bude ta autorita, která bude moci říct, že se to nakonec udělá jinak, než k čemu došla simulace?

Co když s tím část lidí nebude souhlasit a budou si chtít mezi sebou obchodovat přímo bez zásahů nějaké autority? Přijde mi, že vymýšlíš akorát složitější a zároveň nemorální systém.

Komunismus selhal protoze se kradlo.

To souvisí s osobní zainteresovaností a motivací. V tržním hospodářství jsou lidé mj. motivovaní ziskem. V komunismu/socialismu budou lidi spíš krást, plýtvat materiálem, chovat se nešetrně k pracovním nástrojům atd. protože na tom nemají osobní zájem – a ten, kdo by je měl hlídat na tom opět nemá osobní zájem.

Ne vazne, ja si myslim, ze selhal proto, ze centralni planovani se proste snazi optimalizovat az prilis, a to pak vede k tomu, ze system je velice krehky a snadno se v nem siri poruchy.

Centrální plánovač může počítat s riziky a může zvolit určitou míru redundance. Nikdo komunisty nenutil, aby optimalizovali až na dřeň – klidně nějakou redundanci nastavit mohli. Je to jako když použiješ RAID – taky počítáš s rizikem, že ti občas nějaký disk odejde.

Kapitalismus je dost neefektivni (je v nem znacna redundance), a diky tomu robustni vuci nahlym porucham (treba zivelnym katastrofam).

Takže je ve výsledku vlastně dost efektivní :-) Protože pokud zanedbáš rizika a uměle odstraníš redundanci za účelem vyšší efektivity, tak jsi vlastně z dlouhodobého hlediska vyšší efektivity nedosáhl, protože se ti to jednou vymstí – bude docházet ke skokovým změnám a velkým propadům, místo aby to harmonicky plynulo a výkyvy se vyrovnávaly průběžně.

ze treba existuje kompromis mezi efektivitou a robustnosti, a ze zadne "optimum" proste neni.

K tomu kompromisu/optimu se dojde právě na trhu. Pokud bude někde příliš velká redundance, tak budou firmy fúzovat, a pokud se naopak nějaká firma bude chovat jako komunistický moloch, tak vedle ní vyroste nová efektivnější konkurence. Kdo tomu naopak brání je typicky stát – např. skrze patenty nebo další regulace.

[JS1]

Centrální plánovač může počítat s riziky a může zvolit určitou míru redundance.

Muze s tim pocitat, ale lidska pycha zpusobuje, ze s tim nepocita.

[xkucf03]

To pak snahy socialistů dopadnou jako Černobyl.

[Josef Kufner]

Komunismus nefunguje ze dvou hlavních důvodů:

1. Fyzické věci nejde snadno kopírovat. Pokud jeden něco vyrobí, nemůže to dát všem. A pokud dá, tak každý dostane zanedbatelně malou část. Pokud bysme měli replikátory ze Star Treku, bylo by to o něčem jiném. Zatím tohle funguje jen u open source software (neboť malé příspěvky jednotlivců je snadné rozkopírovat pro celou populaci).
2. Jednotlivci nejsou nijak motivovaní se snažit. Pokud je životní úroveň jednotlivce průměrem výsledků snažení všech, tak flákači se flákají, neboť i tak dostanou, co potřebují, a pracovití na to kašlou, neboť si nijak nepomůžou.

Ten zbytek už jsou jen důsledky těchto dvou důvodů a/nebo snah o jejich řešení.

[Fluttershy, yay!]

Jednotlivci nejsou nijak motivovaní se snažit.

Což takhle vnitřní motivace nebo výsledek vztahů v komunitě. Koneckonců to tak fungovalo po tisíciletí.

Ta mrkev na špagátku lidem nějak vlezla do hlavy.

[Bystroushaak]

Což takhle vnitřní motivace nebo výsledek vztahů v komunitě. Koneckonců to tak fungovalo po tisíciletí.

To nefunguje pro větší skupiny. Například já ani nevím co má být moje komunita, nebo jaký je stav vztahů v ní, natož abych je chtěl zlepšovat. Dokážu si to představit možná tak někde na úrovni rozvětvené rodiny, ale tak někde od 40+ lidí už bych to asi nedokázal sledovat.

[Fluttershy, yay!]

(a) Různé lidi zajímají různé věci, tak se angažují.

(b) Lokalita. Bylo a stále je časté, že člověk interaguje s lidmi ze stejného bloku/ulice/vesnice/čtvrti. Tak ostatně funguje komunální politika, pokud není prolezlá korupcí (např. do obecního zastupitelstva kandiduje, kdo potřebuje prodat pozemky).

[Josef Kufner]

Vnitřní motiivace má jen omezený rozsah a neřeší práci, kterou se nikomu zrovna nechce dělat jen tak nebo ve větším rozsahu.

Vztahy v komunitě dost často vedou na závist a následnou likvidaci pracovitého jedince (např. hony na čarodějnice). V malých komunitách jde hlavně o dobrovolné sdílení prostředků, neboť jednou pomůže on jemu a podruhé zas naopak, což neškáluje nad pár desítek lidí. Před pár tisíci lety (ale i docela nedávno) se obdobné problémy řešily otroctvím, což mi taky nepřijde moc dobré.

[Fluttershy, yay!]

neřeší práci, kterou se nikomu zrovna nechce dělat jen tak nebo ve větším rozsahu

Představ si, že lidé mají různé priority a pro někoho je to třeba loajalita, harmonie nebo čertvíco, takže dělá to, co je třeba jinak nepopulární, ale jinak prospěšné.

Vztahy v komunitě dost často vedou na závist a následnou likvidaci pracovitého jedince

Jablka a hrušky. Nikoliv pracovitého jedince (pomalu jak Ivánek Nový, *vzdych*). Prostě se ustálí v rovnovážném stavu, co se týče [mocenské] rovnosti.

V malých komunitách jde hlavně o dobrovolné sdílení prostředků, neboť jednou pomůže on jemu a podruhé zas naopak, což neškáluje nad pár desítek lidí.

Především jde o zcela jiný hodnotový systém a např. v kmenových společenstvích prakticky neexistuje odpor k práci (resp. v nich ani neexistuje „práce“).

[trekker.dk]

Především jde o zcela jiný hodnotový systém a např. v kmenových společenstvích prakticky neexistuje odpor k práci

Což je v diskuzi o fungování světa, ve kterém kmenová společenství prakticky neexistují, velmi relevantní.

[Randy_Sh]

Představ si, že lidé mají různé priority a pro někoho je to třeba loajalita, harmonie nebo čertvíco, takže dělá to, co je třeba jinak nepopulární, ale jinak prospěšné.

Otázkou je, jakou část populace takoví lidé tvoří a jestli by zvládli dělat všechny ty nepopulární práce, na které by se ostatní vykašlali.

[xkucf03]

Což takhle vnitřní motivace nebo výsledek vztahů v komunitě.

Tou komunitou může být klidně skupina flákačů, která se navzájem utvrzuje v tom, jak je bezva parazitovat na ostatních. A ta vnitřní motivace může být dobrý pocit z toho, že se mi podařilo obelstít systém. Jasně, zní to úchylně, ale i takoví lidé jsou součástí společnosti a návrh systému s jejich existencí musí počítat.

[Heron]

Ano, současný systém s nimi počítá geniálně, ta parta flákačů je většinou na vyšších (relativně) místech, ideálně kde nejsou moc vidět. Pokud si na ně někdo posvítí, tak občas začnou i škodit.

[xkucf03]

Pokud mají lidé vůli problémy řešit, komunikují mezi sebou neustále dle potřeby. Nepotřebují synchronizovaný komunikační kanál zvaný "standup".

Ona ta komunikace „dle potřeby“ má svoje úskalí – např. se na něco nezeptáš, protože ani nevíš, že to existuje a nebo ti to někdo neřekne, protože neví, že by se tě to taky mohlo týkat. Tudíž je dobré některé věci komunikovat všem, i za cenu toho, že se někdo dozví i to, co nutně vědět nemusel a bude ho to „zatěžovat“.

Jakou formou tuto komunikaci vést je pak druhá věc. Dá se to dělat různými způsoby – i čistě elektronicky a asynchronně (e-mail), ale pokud členové týmu pracují v jedné kanceláři, tak mi cca desetiminutová ranní schůzka přijde jako celkem rozumná forma.

[Heron]

Pokud mají lidé vůli problémy řešit, komunikují mezi sebou neustále dle potřeby. Nepotřebují synchronizovaný komunikační kanál zvaný "standup".

Pokud lidé mají vůli, tak nejsou potřeba žádné metody řízení. Problém je, že takových lidí je dost málo. Znám člověka, který je schopen se divit, že jeho kolegové o jeho práci nic nevědí a to za situace, kdy on sám je neinformuje. Prostě on to ví, takže to (logicky) přece musí vědět všichni. Standup možná pomáhá toto řešit, tedy každý (více méně povinně) řekne to své a třeba to někdo i poslouchá (i když, nevim, asi ne).

Jinak jsem celkem skeptickej k jakékoliv nucené formě řízení. Pokud si ti lidi nesednou, nerozumí si a nemluví spolu, tak s tím nic nepohne. Povinné schůzky mohou přinést jen další problémy. Pokud navíc ten, kdo tu schůzi řídí (nebo je teda pověřen), není schopen takové situace řešit, je to marné.

[Bystroushaak]

Prostě on to ví, takže to (logicky) přece musí vědět všichni. Standup možná pomáhá toto řešit, tedy každý (více méně povinně) řekne to své a třeba to někdo i poslouchá (i když, nevim, asi ne).

To má jméno btw: Illusion of transparency

[kedlub]

Vzájemná kontrola většinou přichází před začleněním do devel branche. Zase imho nemá smysl neustále stát člověku za zády a hlídat každý jeho krok.

Dělal jsem ve firmě, kde jeden senior chodil hodně brzo do práce a než se vzbudil a vypil kafe, tak zběžně prolítnul commity ze včera (tým asi 10 lidí) a hned psal připomínky. Přišlo mi to mrtě efektivní, často narazil na to, že něco implementujeme vícekrát, zbytečně nebo vyloženě špatně. V poslední době jsem zkusil tuhle metodu aplikovat v jiné firmě a je to neuvěřitelné kolik věcí člověk chytne hned na začátku. Přitom tomu rozhodně nevěnuju víc jak půl hoďky za den. Lidi navíc většinou reagujou na tyhle neoficiální připomínky pozitivně, protože to píšu neveřejně rovnou jim a mají pocit, že se o jejich práci někdo zajímá. Hlavně je to potřeba psát slušně ať je to sebevětší prasárna (zrovna tohle je u spousty programátorů problém). Taky ty chyby jdou často mnohem snáz opravit právě díky tomu, že to ten programátor má zrovna v hlavě a ne že na tom někdy před časem dělal a uzná to až potom co mu ukážeš blame.

[Gulašnikov]

ať je to sebevětší prasárna

tohle napr. v Perlu nefunguje - kdo definuje co je prasárna?

[Bystroushaak]

tohle napr. v Perlu nefunguje - kdo definuje co je prasárna?

Většinou komunita na základě (možná nepsaných) zkušeností. I v tom perlu poměrně rychle zjistíš, že některé věci, které jsou validní program vážně nechceš udržovat do budoucna.

[Kate]

Pro hlídání dokumentace je docela fajn dělat v teamu, kde si jednotliví členové dobře uvědomují že to po dotyčném budou muset někdy upravovat. U nás by mi špatně dokumentovaný kód neprošel přes review.

To se zkritizováním celé (desetidenní) práce se mi stalo, byla to docela poučná chyba. Prostě jsem šla na úkol od začátku špatně, i když to bylo z mého pohledu dobře a prorazila tak slepou uličku. Kolegové často nemůžou vědět že by bylo fajn mrknout programátorovi pod ruce, takže je fajn využít třeba code review nebo jiného teamem používaného nástroje a posílat ostatním úseky práce současně s tím jak se rozvíjí.

[Gulašnikov]

Selhání Pokud selžete, neberte si to osobně.

pockal jsem na tech 50 komentaru a chtel jsem videt, kolik lidi si toho vsimne a omlati to autorovi o hlavu.

Nic.

To uz jste vsichni tak uplne zdegenerovali, ze to vubec nevnimate? Boj o pracovni misto u klavesnice a obrazovky. S vitezi a porazenymi. Porazenymi, kteri patrne neodkladali sve vyplody na github. A tim selhali.

V diskuzi se nekdo divi, jak to, ze jen 80% hodnoceni, jak muze dat nekdo minus. Ja sice chapu, proc se v dnesni zdegenerovane spolecnosti hodnoti podobne blaboly positivne, spise se divim, kde se vzalo tech 20%, ale zoufaly jsem z toho presto. Zoufaly z omezenosti autora a jemu podobnych, kteri se snazi vylepsit sve pracovni dovednosti, aby mohli pristimu zamestnavateli generovat jeste vetsi nadhodnotu.

Ale i po te ciste technicke strance je ta semiprofesionalita autora ubijejici. Kde je napr. zminka o unittestech unittetstu . Kdo kritizuje kritiky a kdo kontroluje spravnou funkci verzovaciho systemu. Neni ani zminena ta zasadni podminka uspesneho projektu, totiz , ze nejlepsi je delat vsechno nejlepe a idealni tym je treba sestavit idealne. Dale autor zapomnel upozornit, ze pri komunikaci je treba se divat do oci partnera. Opomenuta jsou dnes absolutne rozhodujici temata jako napr: jak vybrat Scrum Mastera aneb proc i zkuseni Scrum Masteri selhavaji v Agilni transformaci.

Modlim se za nas za vsechny, aby i nadale trvala stavajici ekonomicka situace, ktera zarucuje, ze se miliony 'pracujicich' mohou vydovadet s blbinamia a jeste za to berou slusne penize. Nedovedu si predstavit, co se stane, kdyby mela prijit krize.

[Kalašnikov]

Nic

ale prd, my autora známe a tolerujeme se tu. Já to třeba ani nedočet, protože si myslím, že už jsem někde jinde a takové blbosti jako dokumentace mně nezajímají :P.

[Bystroushaak]

ale prd, my autora známe a tolerujeme se tu. Já to třeba ani nedočet, protože si myslím, že už jsem někde jinde a takové blbosti jako dokumentace mně nezajímají :P.

Tak ono tenhle text byl určený středne pokročilým začátečníkům, jak jsem tam (a v linkovaném článku z perexu) zmiňoval asi třikrát. Pokud nejsi začátečník, tak ti to očividně moc nedá.

Nenapsal jsem to proto, že by se mi jen tak chtělo, napsal jsem to proto, že mi začátečníci píšou na email, protože jsem se angažoval několika předchozími články, kam jsem dal adresu. Teď se mě ptají, jak na to, proto jsem sepsal celou sérii, kde tohle je (zatím) poslední část.

[Kalašnikov]

Pro začátečníky? Já myslel spíš pro pokročilé, ty si to dokážou už nějak protřídit. Začátečník musí být podle mne naprosto unesen a pak zcela ztracen.

[Bystroushaak]

Psal jsem že článek je určený pro středně pokročilé, pro začátečníky je pak určený zbytek té odkazované série.

[JS1]

Tak ono tenhle text byl určený středne pokročilým začátečníkům

Uprimne receno, to mi na tom tvem textu prijde nejhorsi - ze nevis, komu jsi to vlastne chtel napsat. Na jednu stranu nektere rady jsou spis pro zacatecniky, na druhou stranu, radis lidem, jak najit praci (a navic mam trochu podezreni, ze spatne, ale to je jina vec - s tim portfoliem na Githubu je to ponekud diskutabilni). A pak to zabijes tim, ze od tech lidi cekas dokonale vysledky.

[Bystroushaak]

Na jednu stranu nektere rady jsou spis pro zacatecniky, na druhou stranu, radis lidem, jak najit praci

Snažil jsem se to koncipovat na lidi, kteří si poprvé v životě hledají práci. Protože ti mi píšou.

s tim portfoliem na Githubu je to ponekud diskutabilni

No tak diskutuj :)

A pak to zabijes tim, ze od tech lidi cekas dokonale vysledky.

Dokonalé výsledky? Kde od nich čekám dokonalé výsledky?

[JS1]

No tak diskutuj

Nemam s pohovory osobne tolik zkusenosti (za dekadu svoji pracovni "kariery" jsem byl jen na nekolika), takze nevim, jestli se mi chce na toto tema diskutovat a tvarit se u toho, jak tomu rozumim.

Ale cetl jsem u vic lidi, ze s tim portfoliem je to diskutabilni. Nektere firmy na to daji, jine ne. Stejne tak programatori, nekteri ho maji, jini ne. A nezda se, ze by to moc korelovalo s kvalitou cloveka nebo firmy.

Ono vubec s tim prijimanim je to tezke, na HN jsem kdysi cetl zajimavou studii, ktera v podstate ukazovala, ze a) mezi zpusoby prijimani programatoru je mezi firmami obrovska variabilita a b) neni zadna prokazatelne dobra metoda, jak poznat dobre kandidaty. Z toho pro me plyne zaver, ze je to spis o nahode, a to co se firmy v tom smeru snazi delat odpovida vesmes poveram. Bohuzel ji uz nemohu najit, ale bylo to neco podobneho jako toto.

Takze to je z moji strany asi tak vsechno, co k tomu muzu rict.

Kde od nich čekám dokonalé výsledky?

Tady pises, ze by se to melo vracet, dokud to neni dokonale. Takze asi dokonaly vysledek cekas.

[Heron]

Já jsem vedl několik pohovorů, svoje zkušenosti jsem o tom kdysi sepsal. To bylo tehdy po 8 pohovorech, od té doby je jich zase pár dalších.

Zatímco kolegové řešili otázky, vymýšleli testy, já jsem na to šel metodou prostě si pokecat. Kolega mě dokonce po jednom pohovoru upozornil, že to není seznamka, ale hledání technika (jako kdyby to nešlo spojit, že ).

Proč. Protože většina testů je na konkrétní technologii. Umíš / neumíš. Tečka. Zažil jsem. Kravina na entou. Mě je celkem jedno, že borec nezná svn nebo git, ale pokud si s ním 20minut povídám o tom, co zažil při nasazování mercurialu, stačí mi to (přestože to tady nemáme) a je to lepší, než když mi odpapouškuje man svnadmin.

Taky během pohovoru dokážu poznat, zda je někdo jen nabiflovanej na test, nebo o tom fakt něco ví. Což jsou dvě různé věci.

Co se týče portfolia, mě vždy zajímalo, zda má dotyčnej vlastní web. Protože u techniků hlásících se do firmy vyrábějící webové aplikace bych tak nějak automaticky čekal, že si někde budou bastlit vlastní web. Z toho se dá taky lecos poznat. Jenže takových lidí překvapivě taky moc není.

Jestli je to správná metodika nevím, já si vždy vybírám člověka, se kterým si sednu po stránce lidské. Ano, možná jsme tím přišli o pár géniů, ale samostatný genius není vše. Kolikrát je lepší pohoda v týmu, vzájemná pomoc a zastupitelnost.

[Bystroushaak]

Zatímco kolegové řešili otázky, vymýšleli testy, já jsem na to šel metodou prostě si pokecat. Kolega mě dokonce po jednom pohovoru upozornil, že to není seznamka, ale hledání technika (jako kdyby to nešlo spojit, že ).

V tomhle je právě fajn, když má třeba github, nebo něco, protože pak to můžeš otevřít a pokecat si přímo o konkrétním zdrojáku, ptát se proč takhle a ne jinak a jestli zkoušel X a proč se rozhodl pro Y a hned vidíš. Když si chceš pokecat jen tak obecně, tak hrozí, že to bude jen člověk, který umí dobře okecávat věci, ale reálně nic neumí.

[Heron]

V tomhle je právě fajn, když má třeba github, nebo něco, protože pak to můžeš otevřít a pokecat si přímo o konkrétním zdrojáku

Jo, souhlas. Proto taky chci vidět nějaký web, ideálně s dokumentací apod. (U nás fakt zdrojáky požadovat nemůžu. Max tak skripty na ansible apod.)

Když si chceš pokecat jen tak obecně, tak hrozí, že to bude jen člověk, který umí dobře okecávat věci, ale reálně nic neumí.

To si troufnu říct, že docela poznám. Člověk, který jen okecává a reálně to nikdy pořádně nedělal, nezná nějaké konkrétní detaily, na které by nutně musel narazit. To se pozná.

[xkucf03]

Proč. Protože většina testů je na konkrétní technologii. Umíš / neumíš. Tečka. Zažil jsem. Kravina na entou.

V tomhle mi přijde rozumné dát na výběr víc otázek/témat, ať si vybere to, s čím dělal nebo co umí nejlíp, a v tom se předvede – ať už psaním testu nebo naprogramováním zadaného úkolu nebo důkladným pohovorem. Pokud např. dělal s Debianem a ty máš ve firmě Centos, tak ho nechat dělat úkol radši na Debianu, než aby tápal v Centosu, protože tím moc svoje schopnosti nepředvede (mohl by sice použít internet a doučit se to za chodu, ale na to není moc prostor). A k tomu náhodné otázky z jiných oblastí, ve kterých by měl prokázat alespoň průměrné/dostatečné znalosti. To abys mj. odfiltroval lidi, kteří vědí, jak děláš pohovory, a připravili si důkladně jedno téma, ačkoli s ním v praxi nemají zkušenost.

Nicméně tyhle rady platí v situaci, kdy si můžeš dovolit to místo neobsadit a hledání nového člověka je spíš dlouhodobý cíl než akutní potřeba. Pokud to místo obsadit musíš nebo téměř musíš (můžeš to zrušit jen pokud by chodili pouze úplní lemplové a nikdo použitelný nebyl) a uchazečů je málo, tak otázka není „ano/ne?“ ale „koho?“ a jde o jen relativní porovnání uchazečů a výběr toho nejpoužitelnějšího (a v krajním případě zrušení/odložení projektu, protože prostě nejsou lidi).

[pavlix]

Zatímco kolegové řešili otázky, vymýšleli testy, já jsem na to šel metodou prostě si pokecat. Kolega mě dokonce po jednom pohovoru upozornil, že to není seznamka, ale hledání technika (jako kdyby to nešlo spojit, že ).

Tak v tom případě jsem včerejší večer a dnešní dopoledne strávil úplně špatně a firma, kde jsem byl, by se měla jít zahrabat. Sice se ke mě chovali tak, že jsem jim okamžitě dohodil potenciálního stálého člověka a teď přemýšlím, koho bych ještě s nimi mohl spojit, zatímco se volně bavíme o možnostech spolupráce se mnou jako freelancerem. Kolega asi bude trošku mimoň. :)

Ano, možná jsme tím přišli o pár géniů, ale samostatný genius není vše.

Svatá pravda.

[Bystroushaak]

Ale cetl jsem u vic lidi, ze s tim portfoliem je to diskutabilni. Nektere firmy na to daji, jine ne. Stejne tak programatori, nekteri ho maji, jini ne. A nezda se, ze by to moc korelovalo s kvalitou cloveka nebo firmy.

Portfolio je tvoje prezentace, která ti pomáhá se prosadit. Pokud ho nemáš, tak to samozřejmě neznamená, že se neprosadíš, jen že to musíš udělat jinak. Například máš za sebou kopu zkušeností, nebo jsi známý v oboru, nebo můžeš ukázat na nějaký konkrétní projekt, který je známý. Určitě. Ale zrovna začátečníci nic z tohohle nemají, takže zaměstnavatel bude většinou chtít, aby se ukázali třeba psaním otravných testů na papír, nebo vypracováním nějakého testovacího zadání.

Tady pises, ze by se to melo vracet, dokud to neni dokonale. Takze asi dokonaly vysledek cekas.

Nepíšu dokonale, píšu čistě. To jsou různé věci. Já třeba zrovna teď mentoruju člověka, který tenhle týden nastupoval a dělá u nás přes léto, protože jinak studuje. Ani ve snu by mě nenapadlo po něm chtít dokonalý kód, ale určitě po něm budu chtít čisté řešení. A když ho nenabídne, tak to prostě bude muset přepsat. To není nesmyslná buzerace, mám prostě nějaký standard co chtít v codebase a zároveň mu tím zvedám úroveň, protože mu pomůžu pochopit jak psát čistěji. Mě konkrétně ani nezajímá, co přesně programuje, ale že to po něm budu muset udržovat až odejde, to je docela podstatné. Tak prostě od začátku trvám na tom, aby to bylo čistě, přehledně a udržovatelně. Jinak neříkám, že to musí vymýšlet sám, ostatně co je a není čistý kód je předmětem diskuze.

[ehm]

To je obsahově prázdné sdělení. Dozvěděli jsme se, že všechno je špatně, ale dál už nic.

Ostatně, existují i jiné práce než nahypované supermoderní startupy nebo korporace. Vždycky se můžeš přidat k nějaké neziskovce a začít pečovat o nemocné za minimální mzdu.

Jakože – chápu, co se snažíš říct, a neznám nikoho, koho by to nesralo, ale to je prostě život.

[JS1]

To je obsahově prázdné sdělení.

Musis umet cist mezi radky.

Jakože – chápu, co se snažíš říct

Protirecis si s tim, co jsi napsal v prvni vete. A pokud ne, protirecis si jeste jinak.

Lidska spolecenstvi maji tu zvlastni vlastnost, ze se mohou ocitnout v situaci, kde vsichni clenove praktikuji neco, s cim fakticky nikdo nesouhlasi. Jedina moznost, jak to prestat delat, je, ze nekdo najde odvahu se vyjadrit a rict to verejne (ze kral je nahy). Sam zde uznavas, ze toto je ta situace, a tudiz, nejde o prazdne sdeleni, stejne jako slavne "kral je nahy" z te pohadky neni prazdne sdeleni, akorat se sdeluje neco ponekud jineho.

a neznám nikoho, koho by to nesralo, ale to je prostě život

To je tedy pekna hloupost. Pokud to vsem vadi, a vite, ze to vsem vadi (protoze to nekdo nahlas rekl, ze to vsem vadi), proc to nezmenite?

[ehm]

Protirecis si s tim, co jsi napsal v prvni vete.

Že (asi) chápu, co se snaží říct, neznamená, že to řekl.

To je tedy pekna hloupost. Pokud to vsem vadi, a vite, ze to vsem vadi (protoze to nekdo nahlas rekl, ze to vsem vadi), proc to nezmenite?

Nevím, jestli všechny, jen nikoho takového neznám.

Jestli jde udělat nějaké změny ku větší všeobecné spokojenosti si nejsem jistý.

Každý člověk má jiné cíle a motivace a při jakékoliv mezilidské interakci to vyjde najevo a projeví se to menší či větší frustrací nebo nespokojeností na jedné nebo obou stranách. Zatímco je relativně snadné dosáhnout ucházející spokojenosti v soužití dvou kompatibilních lidí, u tří už je to těžší. A protože v komereční sféře do styku přichází i lidi, co kompatibilní nejsou (přinejmenším nepřímo), je ještě těžší to sladit.

Vem si jen zdejší diskuze, kde se schází netriviální množství lidí s většinou víceméně podobnými zájmy a stylem uvažování. Přesto je těžké dosáhnout shody v čemkoliv; Heron bude nespokojený, když mu budeš předhazovat konfiguráky v XML, luv bude nespokojený, když ho budeš nutit pracovat s Javou, a pan Sekanina bude nespokojený, když kdokoliv z nás bude spokojený, protože by to považoval jen za další důkaz neoliberálních tendencí.

Ve firmách situace není naprosto nijak odlišná. Pro spoustu lidí jsou významné různé sociální role a možnost chovat se určitým způsobem. Introvertní programátor si bude bručet štěstím, když bude moct nerušeně v klidu programovat, zatímco extrovertní manažer bude trpět, když nebude mít možnost dávat se na odiv při hlasitém telefoním rozhovoru, pochodujíc po chodbě, tváříc se důležitě, nebo pobíhat mezi kancelářemi, předstírat trvalý spěch a promlouvat na lidi. Tohle všechno jsou motivace, které do toho vstupují, a ty s tím nic neuděláš a nic nezměníš, protože ti lidi se většinou vzájemně potřebují (i když se třeba nemůžou vystát).

A všechny věci, o kterých byla řeč, jsou tím v důsledku taky dotčeny.

[JS1]

Jestli jde udělat nějaké změny ku větší všeobecné spokojenosti si nejsem jistý.

Premyslim, co za timhle fatalistickym tvrzenim je. Neznalost historie? Neznalost jinych kultur? Vira ve spravedlivy svet? Vira v nezvratny pokrok?

Ve firmách situace není naprosto nijak odlišná. Pro spoustu lidí jsou významné různé sociální role a možnost chovat se určitým způsobem.

Prijde mi, ze jsi zrovna touhle vetou potvrdil to, co napsal uz Gulasnikov:

Modlim se za nas za vsechny, aby i nadale trvala stavajici ekonomicka situace, ktera zarucuje, ze se miliony 'pracujicich' mohou vydovadet s blbinamia a jeste za to berou slusne penize.

Diky rustu produktivity prace je prace stale mene o produktivite, a stale vice o tom, davat najevo uzitecnost. Kdyby byla o produktivite, tak se konstruktivne pracuje a neresi se blbosti, protoze na tom zavisi preziti celeho spolecenstvi.

[Bystroushaak]

Diky rustu produktivity prace je prace stale mene o produktivite, a stale vice o tom, davat najevo uzitecnost. Kdyby byla o produktivite, tak se konstruktivne pracuje a neresi se blbosti, protoze na tom zavisi preziti celeho spolecenstvi.

To smrdí subjektivitou a kognitivníma biasama, kde jeden člověk má pocit, že dělá hovno to vztahuje i na ostatní a vyčítá jim, že je jejich práce je k ničemu.

Lidi jako Gulašnikov jsou na internetu vidět poslední dobou často. Z každé jejich řádky je cítit, jak strašně moc mají pocit, že nezapadají do současné společnosti a celé se to stáčí směrem v hejt na všechno. Není to ani žádný nový fenomen, pocit že dřív bylo líp, tráva zelenější a práce smysluplnější je starý jako lidstvo samo. K tomu ten pocit nutného příchodu zkázy, která nás ztrestá za naší pýchu, taky nic nového. Jen internet tomu dává křídla a podporuje vytváření circlejerců, kde se tyhle pocity zesilují. Kdybych měl říct, kolikrát za život jsem slyšel, že už už přijde konec světa, civilizace padne, že takhle to dál nejde a bla bla, tak se ani nedopočítám, protože to slyším celý život ze všech možných stran. Stačí se podívat do levných knih, které jsou plné předpovědí konce na všechna možná data.

Problém dnešního světa je, že je složitý a je těžké se v něm vyznat. Například práce v korporaci má docela dlouhý feedback loop a v případě že management nedává zpětnou vazbu, tak lidi mají pocit, že užiteční prostě nejsou a jejich práce je k ničemu. Přitom to že vůbec práci mají je důkazem, že jejich práce nějaký smysl dává, protože kromě státu na ně nikdo prachy jen tak pro radost vyhazovat nebude.

Řešením imho není vymýšlet co je špatně s civilizací, ale prostě je občas poplácat po rameni a říct jim, že něco udělali dobře. Jinak mají tendenci spadnout do tohohle hejtu, protože možnost ukázat na ostatní a říct „podívej jak jsou úplně k ničemu“ je tak nějak poslední věc, která jim dává pocit alespoň nějaké sebe-hodnoty. A to mi přijde nezdravé.

[pavlix]

Kdybych měl říct, kolikrát za život jsem slyšel, že už už přijde konec světa, civilizace padne, že takhle to dál nejde a bla bla, tak se ani nedopočítám, protože to slyším celý život ze všech možných stran. Stačí se podívat do levných knih, které jsou plné předpovědí konce na všechna možná data.

A kolikrát bys chtěl, aby ten konec světa/civilizace za tvůj život nastal? To je věc, která nemůže vyjít pokaždé, když to někdo předpoví, to uvidíš maximálně jednou. :D

[pavlix]

Přitom to že vůbec práci mají je důkazem, že jejich práce nějaký smysl dává, protože kromě státu na ně nikdo prachy jen tak pro radost vyhazovat nebude.

Tak tohle je podle mě docela solidní klam. Lidé dávají peníze zbůhdarma na kde co, a tím spíše když ty peníze nejsou ani jejich.

[Bystroushaak]

Tak tohle je podle mě docela solidní klam. Lidé dávají peníze zbůhdarma na kde co, a tím spíše když ty peníze nejsou ani jejich.

Fakt zbůhdarma? Kde? Já chci taky.

[Jendа]

Já spíš vídám, že se dělají IT věci, u nichž nevidím žádnou praktickou užitečnost. Například jak funguje penetrační testování: místo toho, aby se udělala analýza zranitelností zevnitř, si najmou někoho, kdo se to snaží prostřelit zvenku a demonstrovat, že to opravdu jde, což stojí mnohem víc práce a výsledek typicky porývá jen několik cest průniku.

[Bystroushaak]

Význam může být manažerský, tedy dokázat, že to jde a že by bylo dobré se tomu věnovat víc tím, že manažera vystrašíš.

[Jendа]

Což mi přijde právě ta nesmyslná práce.

Tímhle způsobem se dá vysvětlit smysl asi tak všeho.

[Bystroushaak]

Což mi přijde právě ta nesmyslná práce.

To je jako říct, že lidská psychologie nedává smysl. Můžeme se bavit o efektivitě takového postupu, ale smysl lze jen těžko upřít.

[pavlix]

Tím pádem lze smysl definovat kontextem a životní realitou a máte tedy ve svém úhlu pohledu pravdu oba. Pokud jde o IT, tak stejně v 99 % řeší problémy, které IT způsobilo.

[xkucf03]

Zrovna u testování (nejen penetračního) se hodí, když to dělá někdo jiný, než kdo ten systém tvořil – je to jako když napíšeš článek a dáš ho někomu ke korektuře, nebo ať nechodíme tak daleko: jako když napíšeš kód a dáš ho na revizi kolegovi, který si spíš těch chyb všimne, nebo si všimne jiných chyb, než ty, který jsi do toho kódu koukal celý den/dny a už ti to přijde normální. Kromě toho se odfiltrují různé osobní zájmy a zaujatost. Další věc je, že je poměrně těžké být dobrý programátor a zároveň znát všechny aktuální trendy v oblasti bezpečnosti a dívat se na věc očima útočníka. Většina lidí je ráda, když budou zvládat jedno z toho. A většina firem si nemůže dovolit trvale zaměstnávat ty nejlepší.

Na druhou stranu nezpochybňuji, že se často vyhazují peníze za zbytečné služby externích konzultantů – aneb „odborník je ten, kdo přijel z jiného města (firmy)“. :-)

[Jendа]

Zrovna u testování (nejen penetračního) se hodí, když to dělá někdo jiný, než kdo ten systém tvořil

Netvrdil jsem opak. Ta analýza zevnitř znamená, že se nedělá blackbox pentest, ale že se pentesterovi dají všechny zdrojáky a dokumentace.

[xkucf03]

To jsem myslel, že se dělá i u testů externí firmou – nejdřív se pokusit systém napadnout bez znalosti (blackbox) a následně se znalostí (whitebox). Jinak by to ani moc nedávalo smysl, vzhledem k tomu, kolik útoků mají na svědomí lidi zevnitř (např. bývalí zaměstnanci nebo i současní nebo lidi od dodavatele atd.).

[Jendа]

Bohužel zrovna mám zakázku, kde klient má tímto způsobem postižená přání. A co jsem slyšel od kamarádů, tak to rozhodně není výjimka.

Jinak by to ani moc nedávalo smysl, vzhledem k tomu, kolik útoků mají na svědomí lidi zevnitř (např. bývalí zaměstnanci nebo i současní nebo lidi od dodavatele atd.).

Nešlo mi dokonce ani o to, odkud ten člověk je, ale prostě o to, že se znalostí systému dokážeš identifikovat víc děr v kratším čase, případně i upozornit na místa, kde to budoucím problémem teprve hrozí.

[JS1]

To smrdí subjektivitou a kognitivníma biasama

To zni jako nejaka nova forma Godwinova zakona, akorat misto Hitlera je "kognitivni bias".

Jinak mi prijde, ze to zbytecne komplikujes. Ja ti nabizim IMHO daleko primocarejsi pohled:

Například práce v korporaci má docela dlouhý feedback loop a v případě že management nedává zpětnou vazbu, tak lidi mají pocit, že užiteční prostě nejsou a jejich práce je k ničemu.

Dejme tomu, nikdo nevi, k cemu ta prace je. Ty tvrdis, ze tam musi byt nejaky skryty duvod, ktery proste my nedokazeme nasimi smysly ani rozumem odhalit, neco jako "cesty bozi jsou nevyzpytatelne". Ja tvrdim, ze tam zadny vyssi duvod neni a proste ta prace zbytecna je.

Řešením imho není vymýšlet co je špatně s civilizací, ale prostě je občas poplácat po rameni a říct jim, že něco udělali dobře.

Tobe vyhovuje poplacani se po rameni, nekomu treba ne. Nekdo by treba rad vyresil problemy, ktere vidi, a proto na ne upozornuje; a tam kde nejsou je spokojeny. A je pak (treba pro tebe) za morouse, ktery jen mluvi o problemech, protoze nejsi schopen pochopit, ze mas selekcni bias.

[Bystroushaak]

To zni jako nejaka nova forma Godwinova zakona, akorat misto Hitlera je "kognitivni bias".

Rozdíl je v tom, že o kognitivním biasu se dá diskutovat a dá se zhodnotit, jestli jo, nebo ne a člověk ho může třeba přestat používat. Hitler je prostě hitler. Já (většinou) nemám za zlé, když mě na bias někdo upozorní, protože mi vadí, když biasy používám a nevím o tom.

Dejme tomu, nikdo nevi, k cemu ta prace je. Ty tvrdis, ze tam musi byt nejaky skryty duvod, ktery proste my nedokazeme nasimi smysly ani rozumem odhalit, neco jako "cesty bozi jsou nevyzpytatelne". Ja tvrdim, ze tam zadny vyssi duvod neni a proste ta prace zbytecna je.

Ne, já nesouhlasím se základním axiomem téhle teorie, tedy že „nikdo neví, k čemu ta práce je“. To prostě popírá moje zkušenosti. Stává se, že to neví ten člověk, ale většinou jen proto, že se dost nesnaží zasadit se do kontextu. Málokdo zvládne přijít za šéfem a zeptat se „hele, mám pocit, že tahle práce moc nemá smysl, můžeš mi ukázat jaký je kontext?“ Asi ze strachu, že by mohli být vyhozeni, nebo co.

Tobe vyhovuje poplacani se po rameni, nekomu treba ne. Nekdo by treba rad vyresil problemy, ktere vidi, a proto na ne upozornuje; a tam kde nejsou je spokojeny. A je pak (treba pro tebe) za morouse, ktery jen mluvi o problemech, protoze nejsi schopen pochopit, ze mas selekcni bias.

Ne, já se dokážu poplácat sám. Praxí jsem ale zjistil, že musím plácat i ostatní, protože nikdo jiný to neudělá a oni pak sklouzávají k depresím a vidí problémy i tam, kde nejsou.

Tohle je mimochodem vysvětlení, proč lidi dělají práce jako je třeba uklízečka, nebo operátor servicedesku a nevadí jim to. Je to prostě proto, že za sebou vidíš nějaký výsledek (čisté hajzly), nebo ti zákazníci říkají, že jsi jim pomohl, máš tedy pocit užitečnosti. V pozicích, kde ten výsledek jasně nevidíš pak narůstá deprese a pocit neužitečnosti. Většinou to ale znamená, že se jen neumíš podívat, protože tvoje práce zapadá do složitého kontextu, který prostě není vidět na první pohled.

Stejně tak může mít depresi člověk, co celý den razí na stroji jen kusy těsnění. Kus plastu do mašiny, zmáčknout tlačítko, buch. Je to tam. Vyndat výlisek, dát nový. K čemu to je? Nudná a monotónní práce, zas znova každý den. Dát, buch, vyndat, dát, buch, vyndat. Život na hovno. Stejně mě nahradí číňani a robot by to mohl dělat rychleji. Tak se na to jednoho dne rozhodne vykašlat a najednou má problém celá fabrika na výrobu raketových motorů.

Samozřejmě, je možné, že má problém celá civilizace, že všichni vymýšlí práce k ničemu a platí lidi, aby je dělali, protože proto. Možná to dokonce sponzorují ilumináti, nebo stát. A třeba se to tak fakt občas děje. Jsem poslední, kdo se bude hádat o tom, že vznikají kapsy neefektivity. Určitě ano, sám jsem je viděl. Jenže mnohem větší šance je, že prostě nevidíš kontext a věci co ti přijdou k ničemu přeci jen nějaký užitek mají, speciálně pokud jde o celé třídy pracovních pozic.

Víš jak poznáš většinu biasů? Člověk z nich má nějakým způsobem uspokojivý pocit. Jako například pocit, když na někoho ukážeš prstem a řekneš „tihle X, ti jsou k ničemu, zato já, já mám svojí hodnotu“, nebo „jen počkejte, až přijde konec (krize, oteplení, ochalzení, meteorit, ..), to vám to pán bůh konečně spočítá a bude spravedlnost, haha“.

[Fluttershy, yay!]

Většinou to ale znamená, že se jen neumíš podívat, protože tvoje práce zapadá do složitého kontextu, který prostě není vidět na první pohled.

Ale prosím tebe, složitý kontexte. Cílem [v komerční sféře] je makat na kapitalistu, aby byl co nejbohatší.

[Bystroushaak]

Jo, a nakonec všichni umřeme.

[Fluttershy, yay!]

Kapitalista není nikdo, bez koho by se realita neobešla. Zatímco smrt je prostě skončení bouřlivých chemických reakcí v organismu.

[Jendа]

Ale prosím tebe. Cílem [v komerční sféře] je makat na sebe, abys byl co nejbohatší.

[Bystroushaak]

No já nevím, většina lidí co znám to rozhodně nedělá kvůli tomu, aby byli co nejbohatší. Například nedělají dvě práce najednou, i když by mohli.

[xkucf03]

Ono se sice říká, že peníze v práci nejsou všechno, ale ve skutečnosti jedna z nejdůležitějších věcí jsou, protože se dají celkem snadno a spolehlivě¹ konvertovat na volný čas, ve kterém si můžeš dělat, co chceš. Jedna práce ve srovnání s jinou ti může vydělat na období, kdy nemusíš pracovat pro nikoho cizího a můžeš využít volno zcela podle svého.

_{[1] pokud zrovna nedojde na měnovou reformu, hyperinflaci nebo něco, co ti znehodnotí úspory – ale to se dá poměrně řešit diverzifikací}

[Bystroushaak]

Ono se sice říká, že peníze v práci nejsou všechno, ale ve skutečnosti jedna z nejdůležitějších věcí jsou, protože se dají celkem snadno a spolehlivě1 konvertovat na volný čas, ve kterém si můžeš dělat, co chceš. Jedna práce ve srovnání s jinou ti může vydělat na období, kdy nemusíš pracovat pro nikoho cizího a můžeš využít volno zcela podle svého.

Já teď vyměňuju možnost vydělat si víc peněz za jeden volný den v týdnu.

[xkucf03]

Tím vlastně pracuješ za vyšší denní sazbu (tzn. pořád jde o peníze). Jestli si to volno rozdělíš po dnech do jednotlivých týdnů, nebo budeš střídat delší období zaměstnání a volna, to je jen otázka osobních preferencí – princip je stejný.

[Bystroushaak]

Asi to takhle říct jde, ale to se pak dá vztáhnout na všechno a přijde mi to takové zbytečné. Například máš vyšší hodinovou sazbu, protože pracuješ jen 8 hodin denně místo 20 a taky víkendy tě nutí mít vyšší hodinovou sazbu a taky ..

[Fluttershy, yay!]

Kumuluješ kapitál?

[Jendа]

Samozřejmě. Přece nebudu žít z ruky do huby a v případě nemoci/vyhození/... nepůjdu hned pod most.

[Fluttershy, yay!]

Je na pováženou, zda je potřeba generovat zisk, aby byly zajištěny základní potřeby – a odkud se ten zisk bere.

[Bystroushaak]

A co takhle sepsat celou ekonomickou teorii, než trousit moudra po jedné větě v diskuzích?

[Fluttershy, yay!]

A co takhle sepsat celou ekonomickou teorii

Proč? Protože syndrom NIH?

[Bystroushaak]

Protože trousit to po jedné větě v diskuzích je docela k ničemu.

[Fluttershy, yay!]

Však laskavý čtenář může z diskuze přejít na jiné weby nebo do knihovny, kde jsou o tom celé svazky, pokud ho to zajímá.

To bych mohl konstatovat, že libovolný komentář v diskuzi je k ničemu, protože neobsahuje úplné pozadí ke svému obsahu, nýbrž – je-li netriviální – odkazuje se na další/primární zdroje.

[Bystroushaak]

No, ale ty se neodkazuješ. Prostě jen o něčem mluvíš a ani neřekneš pořádně o čem.

[ehm]

Přece, že kapitalismus je špatně, a že potřebujeme zavést ZP.

[Fluttershy, yay!]

kapitalismus je špatně, a že potřebujeme zavést ZP

Pokud ZP je nepodmíněný příjem, tak podle některých jde o mechanismus pro zachování kapitalismu.

[Bystroushaak]

Přece, že kapitalismus je špatně, a že potřebujeme zavést ZP.

Já bych byl asi klidně pro.

[ehm]

Pro zavedení ZP?

[Bystroushaak]

Jo. Kdysi jsem si to počítal a vycházelo mi to hodně nízko, pokud by zůstaly stejné daně. Pak mi došlo, že jsem zapomněl započítat danění korporací a pak už to vycházelo líp. Pokud by se ZP podařilo nějak vybalancovat, tak by se na tom dalo i ušetřit a všichni by si mohli dělat co chtěli. Nedávno jsem rozepsal úvahu o důchodovém systému a budoucnosti a těžkosti vyvázání se z ekonomického běhu světa, ale jednak jsem to nedopsal a taky nechci psát politické blogy. Každopádně mi u toho ale došlo, že ZP je jedním z mála způsobů, jak z toho poměrně elegantně ven, než důchodový systém buď všechny naprosto zotročí, zkrachuje, nebo sem napustí migranty.

[Käyttäjä 11133]

Pokud by nás bylo přesně 10 000 000 a na ZP by padly veškeré plánované příjmy státního rozpočtu na rok 2017, tak si můžeme dovoli ZP ve výši 10 408,33 Kč měsíčně.

[Bystroushaak]

Pokud by nás bylo přesně 10 000 000 a na ZP by padly veškeré plánované příjmy státního rozpočtu na rok 2017, tak si můžeme dovoli ZP ve výši 10 408,33 Kč měsíčně.

To imho nebere v úvahu kolik by se ušetřilo zrušením všemožných institucí zodpovědných za přerozdělování.

[Käyttäjä 11133]

veškeré plánované příjmy státního rozpočtu, takže smůla, ale bere...

[Bystroushaak]

veškeré plánované příjmy státního rozpočtu, takže smůla, ale bere...

Chtěl jsem tím poskočit v diskuzi o dva kroky dál, kde někdo řekne, že je to málo, další že by to bylo s výdaji podstatně míň a pak přijde někdo, kdo řekne, že by se zrušilo přerozdělování a tedy by to zas tak málo nebylo. Ale vidím, že davkol už se tam dostal.

[xkucf03]

Kromě toho by takový zásah zpětně ovlivnil systém, tudíž stará čísla by už neplatila. Např. těch deset tisíc by nemělo hodnotu dnešních deseti tisíc… Spousta lidí by přestala pracovat nebo by dělali maximálně melouchy, v důsledku toho by stát vybral méně na daních a zároveň by byl nedostatek pracujících, takže firmy by buď ukončily činnost nebo by musely nabídnout vyšší mzdy – což na jednu stranu vypadá pozitivně, ale na druhou stranu by se to promítlo do zvýšení cen (tudíž by sis za těch deset tisíc nekoupil totéž, co dneska). Ve výsledku by na tom akorát pracující byli hůř, protože by museli živit flákače. Aneb neexistuje žádné perpetuum mobile nebo oběd zdarma a když někdo přestane být přínosem pro společnost, ale spotřebu neomezí, tak se to musí někde projevit.

Teoreticky by se ušetřila nějaká režie přerozdělování (výdaje státu na rozhodování, komu dát a komu ne), ale to by nebylo tak podstatná částka, aby to stálo za to, a jednak to jde řešit i jinak – zefektivněním státní správy, zjednodušením systému a snížením míry přerozdělování jako takové.

[Fluttershy, yay!]

Spousta lidí by přestala pracovat nebo by dělali maximálně melouchy

Kdo je ta spousta lidí?

Vidím primárně dvě skupiny lidí: jednak ty, kteří ve své práci nevidí žádný smysl (tj. pročistil by se systém), a jednak de facto námezdní otroky, kteří mají minimální ekonomickou svobodu (jsme chudí) a jsou mj. kvůli automatizaci nebo outsourcingu stejně riziková skupina, co se týče nezaměstnanosti…

v důsledku toho by stát vybral méně na daních

Pokud rozpočet závisí na zdanění té druhé skupiny, tj. jedněch z nejchudších, kteří jsou stejně riziková skupina, co se týče zaměstnanosti, někde je chyba.

zároveň by byl nedostatek pracujících

Na opodstatněně nepopulárních pozicích.

ale na druhou stranu by se to promítlo do zvýšení cen (tudíž by sis za těch deset tisíc nekoupil totéž, co dneska)

Pokud je řeč o těch, kteří už teď žijí na deseti tisících (což je hluboko pod living wage u nás), kdyby měli jistotu příjmu, zřejmě by se chovali racionálněji. Tzn. mj. by se nezvyšovalo jejich zadlužení (což je skutečný problém).

Ve výsledku by na tom akorát pracující byli hůř, protože by museli živit flákače.

Práce není ctnost.

Teoreticky by se ušetřila nějaká režie přerozdělování (výdaje státu na rozhodování, komu dát a komu ne), ale to by nebylo tak podstatná částka, aby to stálo za to, a jednak to jde řešit i jinak

Nebo by lidé měli více času na výchovu potomstva a vzdělávání se (= potenciálně lepší kvalifikace), díky práci pod menším tlakem zdravější (= menší náklady na zdravotnictví) – nebo třeba angažovanější…

zefektivněním státní správy, zjednodušením systému a snížením míry přerozdělování jako takové

…a toho chceš dosáhnout bez angažovaných občanů, kteří se nestarají primárně o přežití, jak?

[Randy_Sh]

zároveň by byl nedostatek pracujících

Na opodstatněně nepopulárních pozicích.

A co by z toho vyplynulo? Že by neměl kdo zametat ulice, takže bychom museli brát gastarbeitery? A ti by časem také získali nárok na ZP, takže bychom museli shánět další gastarbeitery pořád dokola?

Pokud je řeč o těch, kteří už teď žijí na deseti tisících (což je hluboko pod living wage u nás), kdyby měli jistotu příjmu, zřejmě by se chovali racionálněji. Tzn. mj. by se nezvyšovalo jejich zadlužení (což je skutečný problém).

Například mi není jasné, jak by se lidé pracující na minimální mzdu zachovali, kdyby dostali ZP v přibližně stejné výši. Jestli by požadovali vyšší mzdu (za 10 kKč pracovat nebudu, protože stejné peníze dostanu jako ZP za nic), nebo by se třeba spokojili i s menší mzdou (mám 10 kKč ZP a tak mi stačí 5 kKč mzda, protože to celkem dělá 15 kKč).

Nebo by lidé měli více času na výchovu potomstva a vzdělávání se (= potenciálně lepší kvalifikace), díky práci pod menším tlakem zdravější (= menší náklady na zdravotnictví) – nebo třeba angažovanější…

Tak tohle už máme vyzkoušené. Jistá "diskriminovaná" skupina obyvatel ČR již ZP v podstatě má. Stačí jim občas zajít na úřad a vyfasují tučné dávky. Nicméně to vzdělávání, výchova potomstva a zdravý životní styl se tam jaksi nekoná, protože peníze zahučí do alkoholu, drog, cigaret a hazardu.

[Fluttershy, yay!]

Protože na zametání ulic stojí ekonomika. /s

Zrovna to je činnost, kterou lidé nezřídka dělají dobrovolně, pokud na to mají čas, protože jim záleží na prostředí, kde se pohybují.

Ale i kdyby šlo o fabriku, (1) zaměstnání jde zatraktivnit finančně, pracovní dobou nebo benefity (tj. pak jde o funkční trh a ne vykořisťování), (2) je nutné (ba dokonce správné), aby Česko byla montovna závislá na sotva kvalifikované pracovní síle? Montoven se automatizace dotkne (a už začíná dotýkat) nejvíce. Základní otázka totiž zní, co s částí populace, která vždycky dělala málo kvalifikovanou práci, a zda pro tyto pozice existuje náhrada 1:1 – jeví se, že nikoliv.

Jistá "diskriminovaná" skupina obyvatel ČR již ZP v podstatě má.

Má podmíněný příjem a chová se podle toho.

[Randy_Sh]

Protože na zametání ulic stojí ekonomika.

Neříkám, že na úklidu ulic stojí ekonomika. Ale je to práce, která se musí udělat, jinak budou ulice plné odpadků. To samé platí i pro další nepříliš kvalifikované a placené profese, jako jsou uklízečky, prodavačky v supermarketech atd.

Ale i kdyby šlo o fabriku, (1) zaměstnání jde zatraktivnit finančně, pracovní dobou nebo benefity (tj. pak jde o funkční trh a ne vykořisťování),

A dnes je trh nefunkční? Kdyby se nenašel nikdo, kdo by chtěl zametat ulice za minimální mzdu, tak by zaměstnavatel musel připlatit. Což se dnes děje např. u prodavaček. A potom je otázka, co to udělá s inflací - když zvýším mzdy zaměstnancům, tak logicky zvýším cenu produktu a výsledkem je inflace.

Má podmíněný příjem a chová se podle toho.

To je otázka. Když pracují načerno, tak jde vlastně o ZP. A hlavně pořád nevidím ty údajné investice do vzdělání a výchovy dětí. Co jim brání investovat peníze sem místo do alkoholu? Kdyby dostávali ZP místo současných dávek, změnili by své chování?

[xkucf03]

jako jsou uklízečky, prodavačky v supermarketech atd.

Úklid a zejména prodej na pokladnách lze dost automatizovat a lidí tam bude potřeba méně. Díky tomu může být víc žen (nebo i mužů) v domácnostech a vychovávat děti. Někomu to možná bude znít šovinisticky/anti-feministicky, ale spousta žen by byla radši v domácnosti než aby chodily do nějaké mizerné práce.

Pak je otázka, kdo by jí měl platit ušlý příjem ze zaměstnání, které nevykonává, když je doma. Má to být manžel nebo stát (tzn. všichni ostatní pracující)? Totéž v případě, kdy se na ni manžel vykašle nebo není schopen zabezpečit rodinu.

Na jednu stranu se na to můžeš dívat tak, že měla smůlu a ostatní by jí měli pomoc. Na druhou stranu je to zásah státu do přirozeného stavu věcí a ten se někde musí projevit. Pokud bude mít žena jistotu, že jí stát (resp. všichni pracující) zaplatí náklady na dítě a domácnost, které si pořídila s nějakým zmrdem/flákačem, který se o ně nepostará, tak to oslabuje přirozenou motivaci vybrat si jako otce svých dětí někoho schopného a slušného. Což z dlouhodobého hlediska povede k tomu, že ve společnosti poroste počet zmrdů/flákačů (jednak geneticky, jednak výchovou). Je to vlastně taková eugenika naruby, kde umělý zásah nevede k lepším výsledkům ale naopak horším.

Nepodmíněný ZP bude mít tyhle následky. (a netýká se jen žen a dětí) Naopak podmíněné příspěvky cílené na konkrétní jednotlivce mohou pomoci někomu, kdo měl smůlu, a naopak nepomáhat těm, kdo by chtěli jen parazitovat na ostatních.

[Fluttershy, yay!]

Pokud bude mít žena jistotu, že jí stát (resp. všichni pracující) zaplatí náklady na dítě a domácnost, které si pořídila s nějakým zmrdem/flákačem, který se o ně nepostará, tak to oslabuje přirozenou motivaci vybrat si jako otce svých dětí někoho schopného a slušného. Což z dlouhodobého hlediska povede k tomu, že ve společnosti poroste počet zmrdů/flákačů (jednak geneticky, jednak výchovou).

Nebo klesne počet zlatokopek.

Každopádně: kde na tyhle choré úvahy chodíš?

[xkucf03]

Zlatokopka se chce mít nadprůměrně dobře (spíš výrazně nadprůměrně). K tomu ji ZP těžko pomůže.

[pavlix]

Neříkám, že na úklidu ulic stojí ekonomika. Ale je to práce, která se musí udělat, jinak budou ulice plné odpadků.

Já vůbec nechápu, proč řešíte tento přihlouplý argument úklidem. Uklízet umí kdekdo a pokud to bude znamenat, že se bude mít o kousek líp, kdekdo to bude dělat i se základním příjmem. Klasický úklid ulic není nijak zvlášť nepříjemná činnost a když se těm lidem nabídne slušný příjem a nebudou společensky shazování, což jde ruku v ruce, budou to dělat a ještě rádi. Že nejsou lidi, kteří by za nějakou tu výhodu uklidili, je hloupá pověra, Jenom se ted taková práce v podstatě nevyplatí, zvlášť pokud znamená ztrátu bezpracného příjmu na dávkách.

Když pracují načerno, tak jde vlastně o ZP. A hlavně pořád nevidím ty údajné investice do vzdělání a výchovy dětí.

Když musejí pracovat načerno, aby se to vyplatilo, jaká je motivace investovat ty peníze do výchovy a vzdělání, to přece nedává smysl.

[Randy_Sh]

Uklízet umí kdekdo a pokud to bude znamenat, že se bude mít o kousek líp, kdekdo to bude dělat i se základním příjmem.

Dnes jde o nepříliš prestižní a špatně placenou práci. Proč by se to po zavedení ZP mělo změnit?

Když musejí pracovat načerno, aby se to vyplatilo, jaká je motivace investovat ty peníze do výchovy a vzdělání, to přece nedává smysl.

Právě proto by měli investovat peníze do vzdělání a výchovy, aby nemuseli žít na dávkách a pracovat načerno. Ale podívejme se na to globálně. Před časem jsem četl komentář, který říkal asi toto: za uplynulých 25 let jsme do integrace Romů investovali stovky miliard Kč, ať už na dávkách nebo v různých integračních a vzdělávacích projektech. A výsledek? Zlepšila se nezaměstnanost a kriminality mezi Romy? Přestala vznikat romská ghetta? Ne, situace se zhoršuje. Proto je jasné, že rozdávání peněz nic neřeší a problém naopak narůstá.

[Heron]

Dnes jde o nepříliš prestižní a špatně placenou práci. Proč by se to po zavedení ZP mělo změnit?

Docela dobré první přiblížení k tomu, co je skutečně důležitá práce, je zamyslet se nad tím, co by se stalo, kdyby se o to na týden, rok, sto let přišlo. Kdyby někdo přestal na měsíc odvážet odpadky, tak ...

Ano, ocenění práce je někdy v naprostém rozporu s její důležitostí.

za uplynulých 25 let jsme do integrace Romů investovali stovky miliard Kč

Ty stovky miliard bych chtěl vidět.

Říká ti něco pojem obchod s chudobou? Tohle je problém, který ve skutečnosti málokdo chce řešit, protože se na tom dá slušně vydělat. Úřady nic neřeší, protože "to jsou přece Romové, že", politici (ti slušnější) to neřeší, protože si našli lepšího a neokoukaného nepřítele, o těch méně slušných se snad nemusíme bavit, a mezitím bují pronájem zcela nevhodných prostor za astronomické částky a tohle všechno jde do kapsy majitelům ubytoven. Prostě výhodné pro všechny. Teda, skoro.

[Käyttäjä 11133]

Docela dobré první přiblížení k tomu, co je skutečně důležitá práce, je zamyslet se nad tím, co by se stalo, kdyby se o to na týden, rok, sto let přišlo. Kdyby někdo přestal na měsíc odvážet odpadky, tak ...

+1

[xkucf03]

Ano, ocenění práce je někdy v naprostém rozporu s její důležitostí.

Cena je výsledkem nabídky a poptávky. Ta důležitost/užitečnost stanovuje horní mez a náklady dodavatele zase tu dolní. Cena se pak ustálí někde mezi tím. Nemůže se řídit jen tou horní hranicí. Nebo jak by se ti líbilo, kdyby ti někdo na poušti chtěl prodat trochu vody a chtěl za to všechen tvůj majetek? Nebo kdyby ti na opuštěné silnici chtěl prodat trochu benzínu do tvého prázdného auta za všechny peníze, co máš s sebou?

Říká ti něco pojem obchod s chudobou? Tohle je problém, který ve skutečnosti málokdo chce řešit, protože se na tom dá slušně vydělat.

A nedopadlo by to se základním příjmem náhodou stejně? Že by ti lidé ty bezpracně získané peníze nacpali nějakým podvodníkům a pak by zase neměli nic?

[Heron]

Že by ti lidé ty bezpracně získané peníze nacpali nějakým podvodníkům a pak by zase neměli nic?

Nebylo by lepší se těch podvodníků zbavit?

[xkucf03]

Bylo. Ale oni se jaksi vždy objeví, když se naskytne někdo, kdo snadno nabyl…

[Heron]

V tom případě nemusíme vyplácet ani výplatu. Však on mu to stejně někdo ukradne ...

[xkucf03]

U té výplaty to není „snadno nabyl“ – tam si spíš dokáže představit, jakou ty peníze mají hodnotu, kolik úsilí ho to stálo.

[Käyttäjä 11133]

Tak si kup nějaký pěkný, třeba nový bytový dům a za tržní cenu jej poskytni těmhle nepřízpůsobivým... uvidíme za kolik ho normáním lidem budeš moct poskytovat za 10 let, jestli ještě vůbec bude stát... Ti lidi, kteří ty nemovistosti těmhle vyloučeným skupinám obyvatel pronajímají musí taky počítat s tím, že po nějaké době budou muset tu nemovitost zbourat a postavit na tom místě novou.

[Heron]

těmhle nepřízpůsobivým

Netuším, kdo jsou tihle nepřizpůsobiví. Lze to nějak specifikovat?

vyloučeným skupinám

Kdo je vyloučil?

[Käyttäjä 11133]

Netuším, kdo jsou tihle nepřizpůsobiví. Lze to nějak specifikovat?

Lidé, kteří zpravidla nemají zaměstnání či podnik, ale žijí dlouhodobě ze sociálních dávek.

Kdo je vyloučil?

Sami se vyloučili ze společnosti svým sociálně nepřízpůsobivým chováním.

[Heron]

Lidé, kteří zpravidla nemají zaměstnání či podnik, ale žijí dlouhodobě ze sociálních dávek.

Chápu, třeba můj kamarád na vozíku.

Sami se vyloučili ze společnosti svým sociálně nepřízpůsobivým chováním.

jj, ještě nikdy nevstal při hymně.

Je tohle fakt nutné?

[Käyttäjä 11133]

Chápu, třeba můj kamarád na vozíku.

Zpravidla neznamená vždy...

Je tohle fakt nutné?

Kde vidíš problém, možná v tom že nemáš ten barák, ale kdyby si ho měl, tak by si jim ho určitě poskytnul za zcela tržní nájemné bez rizikového upliftu (rizikové marže) a plácal se po zádech tím, že nejsi obchodník s chudobou...

[Heron]

Mno.

Jsem členem představenstva sdružení o 96 bytech a místopředsedou druhého SVJ o 74 bytech. Sice nemám barák (jen dva byty), ale už 5+3 roky docela vím, o co go.

Takže s těmi, jejichž jméno se ti nechce vyslovit, je docela přesně nula problémů. Jsou to velmi milí lidé. Na obou lokalitách.

Největší problém je s majiteli bytů, pronajímateli, kteří tam nebydlí. Pro ty se jedná pouze a jen o generátor peněz. Na shromáždění (což je ze zákona) nejezdí, shromáždění jsou neusnášení schopná. Na lecos (ze zákona) je nutný 100% souhlas vlastníků. Protože ... jsou to přece vlastníci, že a s jejich majetkem nikdo nemůže bez jejich souhlasu nakládat, že.

Takže se dělají věci, při kterých jsem jednou nohou v kriminále. Buď se to "schválí", nebo ten barák časem spadne.

Takže tak.

[Käyttäjä 11133]

Na shromáždění (což je ze zákona) nejezdí, shromáždění jsou neusnášení schopná.

Což je chyba zákona, že sice stanovuje nesmyslné podmínky pro usnášeníschopnost, ale už nestanovuje povinnost ať již osobně, nebo v zastoupení se shromáždění účastnit. Já mám například ve v dohodě společníků to, že pokud se nezůčastníš řádně svolané valné hromady (a způsobíš tím neusnášenlivost valné hromady tzn. účast bude nižší než 75% hlasů) tak tvůj podíl na společnosti propadá ve prospěch společníků, kteří se valné hromady účastní v poměrné výši dle existujících podínů na společnosti.

[ehm]

Já mám například ve v dohodě společníků to, že pokud se nezůčastníš řádně svolané valné hromady (a způsobíš tím neusnášenlivost valné hromady tzn. účast bude nižší než 75% hlasů) tak tvůj podíl na společnosti propadá ve prospěch společníků, kteří se valné hromady účastní v poměrné výši dle existujících podínů na společnosti.

WTF? To zákon umožňuje? V jaké jurisdikci je ta společnost registrovaná?

Pokud to tedy nebyla chyba a nemyslel jsi propadnutí hlasovacího práva (v tom daném případě, resp. pro daná hlasování), nikoliv úplné propadnutí majetkového podílu na společnosti jako takového.

[Käyttäjä 11133]

WTF? To zákon umožňuje? V jaké jurisdikci je ta společnost registrovaná?

Dohoda společníků umožňuje spoustu věcí, které společenská smlouva neumožňuje. Jedná se o společnost registrovanou v ČR.

[Heron]

Což je chyba zákona

No s tím ale nic nenaděláme.

Já mám například ve v dohodě společníků

Nevím, co je to dohoda společníků, ale obecně nelze žádnou smlouvou nebo v našem případě stanovami zrušit ustanovení zákona. Takže i kdybychom si do stanov nakrásně dali rozhodování jen většinou výboru, tak je to stejně neplatné.

[JS1]

Ano, ocenění práce je někdy v naprostém rozporu s její důležitostí.

Cena je výsledkem nabídky a poptávky.

Mas pravdu. A proto, pokud ma nekdo vnitrni motivaci neco delat, napriklad proto, ze to povazuje sam za dulezite, neni potreba (podle zakona poptavky a nabidky) mu platit tolik, jako nekomu, kdo takovou motivaci nema.

Obecneji, stale me fascinuje, jak jsou lide schopni vnimat poptavku a nabidku (naprosto symetricky princip) jako nejakeho strazce jimi vybrane moralky (z principu asymetricke).

[ehm]

Ano, ocenění práce je někdy v naprostém rozporu s její důležitostí.

Ona „důležitost práce“ je především velmi obtížně stanovitelná, protože na té práci často závisí práce jiná. Společenský status to také nereflektuje.

Na základní škole po nás často chtěli sestavovat žebříčky povolání, kterých si „nejvíc vážíme“. Lékaři, záchranáři, požárníci a dokonce i učitelé se – nepříliš překvapivě – umisťovali na prvních příčkách. Nevzpomínam si, že by kdy kdo zmínil vědce. Netřeba snad říkat, že lékař stěží může (na stejné úrovni) léčit lidi, když nebude mít k dispozici veškeré technické vybavení, které bylo dodáno velmi dlouhým řetězcem; začínajícím někde u propoceného horníka dýchajícího prach v dole.

[Randy_Sh]

Docela dobré první přiblížení k tomu, co je skutečně důležitá práce, je zamyslet se nad tím, co by se stalo, kdyby se o to na týden, rok, sto let přišlo. Kdyby někdo přestal na měsíc odvážet odpadky, tak ... Ano, ocenění práce je někdy v naprostém rozporu s její důležitostí.

To je všechno pravda, ale nic to nemění na mé původní otázce. Tj. jak by se po zavedení ZP změnila prestiž povolání, která dnes příliš prestižní nejsou?

Ty stovky miliard bych chtěl vidět.

Tak třeba 250 miliard za 25 let je 10 GKč ročně. Romů je v ČR kolem 300 tisíc, na jednoho to činí 33 kKč ročně, tj. necelé 3 kKč měsíčně. To není úplně nerealistické číslo. Ano, někteří z nich pracují a v 90. letech byla jiná cenová hladina než dnes, ale celkem vzato to číslo sedí.

Říká ti něco pojem obchod s chudobou? Tohle je problém, který ve skutečnosti málokdo chce řešit, protože se na tom dá slušně vydělat. Úřady nic neřeší, protože "to jsou přece Romové, že", politici (ti slušnější) to neřeší, protože si našli lepšího a neokoukaného nepřítele, o těch méně slušných se snad nemusíme bavit, a mezitím bují pronájem zcela nevhodných prostor za astronomické částky a tohle všechno jde do kapsy majitelům ubytoven. Prostě výhodné pro všechny. Teda, skoro.

Vždyť o tom mluvím. Současný systém je špatný a musí se změnit. Není možné donekonečna házet peníze do černé díry bez jakéhokoliv výsledku.

[Bystroushaak]

Před časem jsem četl komentář, který říkal asi toto: za uplynulých 25 let jsme do integrace Romů investovali stovky miliard Kč, ať už na dávkách nebo v různých integračních a vzdělávacích projektech. A výsledek?

Já jsem fascinovaný arogancí, s jakou se k tomu snaží naše kultura přistupovat. Zkusil se jich někdo vůbec zeptat, jestli vlastně chtějí být integrovaní a rozpuštění v naší kultuře? Když si to představím naopak, kde bych byl součástí české menšiny o velikosti desítek tisíc lidí ve státě, který se skládá z desítky milionu romů, tak bych asi taky nechtěl být integrovaný, vzdát se všeho co tvoří mojí kulturu a přijmout všechny jejich hodnoty. A na tom přece není nic špatného. Stejně tak třeba Židi u nás se nikdy úplně neintegrovali, nebo třeba indiáni v Americe. Přijde mi absurdní a arogantní se o to snažit silou.

[Randy_Sh]

Já jsem fascinovaný arogancí, s jakou se k tomu snaží naše kultura přistupovat. Zkusil se jich někdo vůbec zeptat, jestli vlastně chtějí být integrovaní a rozpuštění v naší kultuře? Když si to představím naopak, kde bych byl součástí české menšiny o velikosti desítek tisíc lidí ve státě, který se skládá z desítky milionu romů, tak bych asi taky nechtěl být integrovaný, vzdát se všeho co tvoří mojí kulturu a přijmout všechny jejich hodnoty. A na tom přece není nic špatného. Stejně tak třeba Židi u nás se nikdy úplně neintegrovali, nebo třeba indiáni v Americe. Přijde mi absurdní a arogantní se o to snažit silou.

Současná situace je taková, že Romové ve srovnání s Čechy mají v průměru výrazně vyšší nezaměstnanost a kriminalitu, podstatně víc jich žije v chudobě a ve vyloučených lokalitách, mají nižší vzdělání, horší zdravotní stav, nikdo je nechce mít za sousedy atd. Nemělo by se to nějak řešit? A kdo by to měl řešit - my nebo oni? Ať si každý soukromě vyznává hodnoty, jaké chce, ale zákony tohoto státu jsou nadřazené těmto soukromým hodnotám.

[deda.jabko]

A kdo by to měl řešit - my nebo oni?

Se mi vybavil dil Ano, sefe, kde se Pohlreich vratil za lidmi z ucnaku a zjistoval, kde se jednotlivi zaci nakonec uchytili. Ciganka, vyucena kucharka, skoncila v Amazonu u prace, kde nepotrebuje nejak extra kvalifikaci, protoze v pohostinstvi ji automaticky odmitali s tim, ze je ciganka. Tady se tedy nabizi otazka: A kdo by to měl řešit - my nebo oni?

[Randy_Sh]

Se mi vybavil dil Ano, sefe, kde se Pohlreich vratil za lidmi z ucnaku a zjistoval, kde se jednotlivi zaci nakonec uchytili. Ciganka, vyucena kucharka, skoncila v Amazonu u prace, kde nepotrebuje nejak extra kvalifikaci, protoze v pohostinstvi ji automaticky odmitali s tim, ze je ciganka.

Proti tomu nebude problém najít případy, když někdo zaměstnal Roma a potom trpce litoval. Zkuste si vy sám upřímně odpovědět, jestli byste Roma zaměstnal, pronajal mu byt, koupil si nemovitost v sousedství romské rodiny atd.

Tady se tedy nabizi otazka: A kdo by to měl řešit - my nebo oni?

Je jasné, že obě strany budou muset změnit přístup nebo problém eskaluje natolik, že pokojné řešení už nebude možné.

[deda.jabko]

Zkuste si vy sám upřímně odpovědět, jestli byste Roma zaměstnal, pronajal mu byt, koupil si nemovitost v sousedství romské rodiny atd.

Takze problem evidentne nebude jen v nich, ...

Ale pritom v predchozim prispevku pozadujes, aby to byli prave, oni kdo to bude resit.

[pavlix]

Takze problem evidentne nebude jen v nich, ...

Tak ono to není rozdělení na my a oni. Ale je to určitá lehce poznatelná skupina obyvatel, jejíž velká část svým jednáním vytváří předsudky, kterými pak trpí i ti ostatní. To je velmi nepříjemná situace, kdy je extrémně těžké jim pomoct. Ale rozhodně budu mít radši ty z nich, kteří se snaží sami o sobě situaci dobrým způsobem řešit, ať už řeší jen tu svoji nebo celé význačné skupiny.

A otázka, jestli se chtějí nebo nechtějí integrovat, opravdu není na místě. Člověk, který dokáže být v dané společnosti soběstačný a nedělá jí problémy, si jistě zaslouží maximální svobodu v rozhodování, co s ním bude. Stejné chování vůči celé skupině včetně těch, kteří problémy dělají, k úspěšnému soužití nepovede a naopak to uškodí těm, kteří se snaží se sebou něco dělat.

[Fluttershy, yay!]

Relevantní: 'Nechceme Roma.' Inspekce odhalila nejvíc diskriminačních nabídek zaměstnání za čtyři roky

[pavlix]

Dnes jde o nepříliš prestižní a špatně placenou práci. Proč by se to po zavedení ZP mělo změnit?

Změní se to ve chvíli, kdy lidem začne vadit bordel a začnou být ochotni platit za to, aby bordel nebyl. Já nejsem narozdíl od některých diskutujících volnotrhovec, ale tak triviální věc jako je nedostatek uklízeček vyřeší trh hravě.

Právě proto by měli investovat peníze do vzdělání a výchovy, aby nemuseli žít na dávkách a pracovat načerno.

A tak to právě nefunguje, jak už jsem naznačil výše. Člověk, kterému se nejlépe daří načerno, nemá potřebu investovat do vzdělání a výchovy, a není na tom vůbec nic divného.

[Randy_Sh]

Změní se to ve chvíli, kdy lidem začne vadit bordel a začnou být ochotni platit za to, aby bordel nebyl. Já nejsem narozdíl od některých diskutujících volnotrhovec, ale tak triviální věc jako je nedostatek uklízeček vyřeší trh hravě.

Tomu rozumím, ale to přece funguje i dnes. Když bude nedostatek uklizeček, bude nutné jim nabídnout vyšší platy. Moje otázka zní, jak tohle změní zavedení ZP. Podle mě nijak, pořád půjde o nekvalifikovanou, nepříliš prestižní a nepříliš dobře placenou práci.

[Fluttershy, yay!]

Rozdíl je v mobilitě.

[pavlix]

Tomu rozumím, ale to přece funguje i dnes.

Pak nechápu celý ten argument podřadnými pracemi, který se tak často používá, který byl i zde v diskuzi a na který jsem já reagoval.

Moje otázka zní, jak tohle změní zavedení ZP.

Na odpověď na tuto otázku tu celou dobu napjatě čekám. :)

Podle mě nijak, pořád půjde o nekvalifikovanou, nepříliš prestižní a nepříliš dobře placenou práci.

Podle mě nelze zároveň tvrdit, že to bude špatně placená práce, že to bude po zavedení ZP vzácná práce, kterou nikdo nebude chtít dělat, a že trh vyřeší, aby taková vzácná práce stoupla v ceně, tedy že to bude dobře placená práce.

[Randy_Sh]

Podle mě nelze zároveň tvrdit, že to bude špatně placená práce, že to bude po zavedení ZP vzácná práce, kterou nikdo nebude chtít dělat, a že trh vyřeší, aby taková vzácná práce stoupla v ceně, tedy že to bude dobře placená práce.

Jak už jsem psal, tohle jsou otázky, na které se těžko hledá teoretická odpověď a nejspíš se to ukáže až v praxi. Dovedu si představit, že po zavedení ZP ve výši minimální mzdy poklesne zájem o špatně placené práce. Proč bych pracoval, když nyní dostanu ZP ve stejné výši. Počkám si na lepší nabídku. Ale stejně tak je možné, že lidé budou ochotni pracovat za nižší mzdu, protože v součtu se ZP se jejich příjem zvýší. Pak tady jsou další faktory - vyšší mzdy vyvolají inflaci, reálný ZP tím poklesne, bude se muset zvyšovat a tím se roztočí inflační spirála. Nebo povedou vyšší mzdy k tomu, že se vyplatí nahradit lidi roboty, ale potom nevím, kdo bude platit daně, aby stát měl na ZP. Nebo se budou importovat gastabeitři, kteří na ZP nebudou mít nárok, ale časem vzniknou tlaky, aby ho také dostali. Takže se těším, až to někde zavedou, abychom se z jejich úspěchu či neúspěchu mohli poučit.

[trekker.dk]

Proč bych pracoval, když nyní dostanu ZP ve stejné výši.

Nemá náhodou ZP být bezpodmínečný - bez ohledu na to, jestli příjemce pracuje nebo ne?

[Randy_Sh]

Nemá náhodou ZP být bezpodmínečný - bez ohledu na to, jestli příjemce pracuje nebo ne?

Jistě, jen mi není jasné chování po zavedení ZP. Dřív jsem dělal za 10 kKč, teď dostanu 10 kKč ZP. Zůstanu doma s tím, že mám nyní stejný příjem jako předtím? Půjdu s radostí do práce, protože můj příjem se tím zdvojnásobí? Budu naopak ochoten pracovat za poloviční mzdu, protože v součtu se ZP se můj příjem přesto zvýší o 50%?

[trekker.dk]

Můj odhad - skoková inflace vyvolaná zavedením ZP vás dokope k tomu pracovat dál.

[pavlix]

To jsou samé kecy. Já jsem reagoval jen a pouze na stokrát opakované tvrzení, že by ZP způsobil, že nikdo nebude uklízet. To si nemyslím a položil jsem zde to, co si myslím, že jsou pádné důvody tomu nevěřit. Nemyslím si, že je k tomu potřeba taková hromada vokecávek.

[xkucf03]

zaměstnání jde zatraktivnit finančně, pracovní dobou nebo benefity

Zvýšení platu nebo přidání benefitů vyjde úplně nastejno – znamená to vyšší náklady a ty se promítnou do ceny. Takže dělník sice dostane nominálně vyšší plat, ale bude nakupovat za vyšší ceny, tudíž si reálně moc nepomůže.

Je nutné (ba dokonce správné), aby Česko byla montovna závislá na sotva kvalifikované pracovní síle?

Tohle je problém naší příliš jednostranné orientace na Německo a automobilový průmysl. Obojí je špatně a do budoucna velký problém. Ale když na to někdo upozorní, tak ho obvykle napadnou rusofobové nebo je označen za agenta Číny, takže je docela těžké vést nějakou rozumnou diskusi.

Základní otázka totiž zní, co s částí populace, která vždycky dělala málo kvalifikovanou práci, a zda pro tyto pozice existuje náhrada 1:1 – jeví se, že nikoliv.

Co třeba (jak překvapivé) získat nějakou kvalifikaci?

[Fluttershy, yay!]

Zvýšení platu nebo přidání benefitů vyjde úplně nastejno – znamená to vyšší náklady a ty se promítnou do ceny. Takže dělník sice dostane nominálně vyšší plat, ale bude nakupovat za vyšší ceny, tudíž si reálně moc nepomůže.

A bude mít více na útratu.

Základní otázka totiž zní, co s částí populace, která vždycky dělala málo kvalifikovanou práci, a zda pro tyto pozice existuje náhrada 1:1 – jeví se, že nikoliv.

Co třeba (jak překvapivé) získat nějakou kvalifikaci?

To už jsem někde slyšel.

Nic proti tomu. Ale pokud se trh posune jinam, např. od výroby ke službám, titíž lidé mohou mít podstatně menší předpoklady (např. fyzické dispozice versus „emoční inteligence“).

Za předpokladu, že vůbec vznikne dostatek nových pracovních míst. (A vůbec, proč by to nutně musela být pracovní místa?)

[Randy_Sh]

A bude mít více na útratu.

Asi nechápete, jak funguje inflace. Vezměme člověka, který bere 10 kKč a chleba stojí 10 Kč. Potom nastane vlna zvyšování platů (a tím pádem i cen), takže po nějaké době člověk bere 20 kKč a chleba stojí 20 Kč. Jeho situace se nezměnila a za svou výplatu si koupí stejně jako předtím. Zvyšování mezd bez růstu produktivity nic moc neřeší.

[Fluttershy, yay!]

K inflaci dojde, pokud se vytiskne víc peněz. Což není nutné. Ale co, o vztahu k inflaci už bylo napsáno mnoho bajtů textu.

(Mimochodem v Česku je minimální mzda jedna z nejnižších v Evropě. Proč? To jsme „zvláštní trh“ stejně jako když jde o mobilní operátory?)

[Randy_Sh]

K inflaci dojde, pokud se vytiskne víc peněz

Takže kdyby v parlamentu odhlasovali zákon, že se platy zvyšují na dvojnásobek, tak to nepřineslo inflaci?

(Mimochodem v Česku je minimální mzda jedna z nejnižších v Evropě. Proč?

Všimněte si, že zároveň máme i nejnižší nezaměstnanost v EU. V Francii mají mzdy i nezaměstnanost podstatně vyšší. Nevidíte nějakou souvislost?

[Fluttershy, yay!]

Korelace != kauzalita.

Ostatně, které státy mají podobnou minimální mzdu? Maďarsko, Slovensko.

[JS1]

Takže kdyby v parlamentu odhlasovali zákon, že se platy zvyšují na dvojnásobek, tak to nepřineslo inflaci?

NE! S Kucerou tady uz diskutujete asi 10 let, ale vase neochota pochopit zakladni ekonomicke mechanismy je zarazejici.

Strucne, existuje zakladni menova rovnice: MV=PY. V je "velocity", tedy zhruba receno kolikrat se dana koruna obrati v ekonomice za dany cas. Tudiz, pokud se zmeni V, muze se klidne zmenit Y (prijmy) aniz by se zmenilo P (ceny). Takze obecne, to co rikas, neplati.

Stejne tak je to i se zakladnim prijmem. Muzes si to predstavit treba tak, ze pokud do systemu pridame "umele" prerozdeleni, bude potreba jeste dalsi prerozdeleni, aby se penize dostaly od zakazniku k firmam na zaklade jejich pozadavku. Tudiz se v situaci zakladniho prijmu zvysi V, a inflace nutne nemusi nastat, ci dokonce naopak.

Jinak receno, v situaci se ZP musi nakonec vsechny ty penize navic dostat ti, co pracuji, protoze jak jinak by ti co ziji jen ze ZP realizovali svoji spotrebu? Tudiz se zvysi V, zvysi Y, a jestli se zmeni P a jak je ve hvezdach (ja si spis myslim, ze se nepohne, neni k tomu duvod, ale muze tam byt nejaky sekundarni efekt).

[xkucf03]

Tak znovu. ZP sníží motivaci lidí pracovat. Někdo nebude pracovat vůbec a vystačí si jen se ZP a jiní budou pracovat menší počet dní v týdnu (tzn. vytvoří toho méně za jinak stejných okolností) a budou mít stejný příjem (a budou čekat, že si za to koupí totéž, jako před zavedením ZP, jen získají volné dny navíc). Někdo bude pracovat třeba pořád stejně, ale zvýší se mu příjem – tzn. vytvoří stejný produkt jako před zavedením ZP, ale utrácet/spotřebovávat bude chtít víc.

Jak si představuješ, že tento „ekonomický zázrak“ bude fungovat? Kde se vezme ta hodnota navíc? Kdo udělá tu práci, kterou neudělali ti, kteří mají zrovna dneska volno (placené základním příjmem) nebo kteří přestali pracovat úplně? A není to jen o flákačích – i já bych si udělal nějaký ten volný den navíc, kdyby mi někdo dával peníze jen tak za nic – a to si myslím, že jsem jinak relativně pracovitý člověk.

Inflace je už pak jen prostý důsledek – buď se a) vyrobí méně zboží a dodá méně služeb, tudíž vzroste jejich vzácnost, nepokryje to současnou spotřebu a vzroste cena; nebo b) firmy by chtěly zachovat současnou produkci a aby motivovaly lidi k práci, musely by nabídnout větší platy – což by snížilo zisk a zvýšilo cenu zboží a služeb.

[Fluttershy, yay!]

ZP sníží motivaci lidí chodit do zaměstnání.

FTFY

To neznamená, že nemůže snížit bariéry pro podnikání nebo vykonávání různých společensky prospěšných činností mimo zaměstnání.

[xkucf03]

Takže to celé stojí na tom, že lidi jsou natolik obětaví, že dobrovolně a bez nároku na další odměnu vykonají práci odpovídající tomu ZP, který dostali zadarmo?

[Fluttershy, yay!]

Jako péči o rodinu, dobrovolné činnosti aj.?

[Bystroushaak]

Jak si představuješ, že tento „ekonomický zázrak“ bude fungovat? Kde se vezme ta hodnota navíc? Kdo udělá tu práci, kterou neudělali ti, kteří mají zrovna dneska volno (placené základním příjmem) nebo kteří přestali pracovat úplně? A není to jen o flákačích – i já bych si udělal nějaký ten volný den navíc, kdyby mi někdo dával peníze jen tak za nic – a to si myslím, že jsem jinak relativně pracovitý člověk.

Tak celá pointa ZP je, že tu práci udělají z velké míry roboti, dokonce natolik, že jim lidi nebudou schopní konkurovat, i kdyby chtěli. Například sektor dopravy dostane na prdel v příštích 10 - 20 letech jak žádný jiný, protože prostě všude budou samořídící se X (kde za X si dosaď auta, vlaky, kamiony, ..). A řídící jednotka v X nespí, nemrká, vždycky dává 100% pozor a navíc vidí svět ne jenom v optickém spektru a 120°, ale s 360° pokrytím včetně radaru, vždycky 100% dodržuje předpisy a jezdí optimálně. To samé továrny a práce ve stylu „stojím u pásu“, tam to je taky jen otázkou jak rychle to přijde. Pokud skočím do budoucnosti, dostáváme se do stavu, že velkou část práce, kde se skutečně generují hodnoty (= něco fyzického z toho leze) budou zastávat stroje. Lidé se budou angažovat ve službách a přidané hodnotě.

Já nejsem ekonom, proto se u toho začínám ztrácet, protože ta ekonomie prostě nemá s naší společné základní axiomy. Skoro by mě to děsilo, jenže ekonomie je lidský vynález, který nám má sloužit a když sloužit nebude, tak jí prostě lidi znásilní tak, aby sloužila, protože se negeneruje jen tak sama z prázdnoty, ale je to výslednice lidské potřeby a ta potřeba nikam nezmizí, i když se hodně změní její podstata.

Osobně si dokážu představit například zcela masivní zdanění korporací v takové ekonomii, jenže ne finanční, ale například se řekne, že půlka výroby půjde občanům. Lidi ve skutečnosti nechtějí peníze, těch se nikdo nenažere. Chtějí věci a služby, které se dají za peníze směnit.

[Bystroushaak]

Já vím, že je to nejspíš naivní a každý ekonom se tomu vysměje, ale poslední dobou se nemůžu při přemýšlení nad budoucností vyhnout srovnání s mraveništěm. Mraveniště taky funguje bez centrálního plánování a bez použití kapitalismu, samostatní mravenci mají svoje potřeby. Lidi nejsou zas tak rozdílní, liší se jen vysokou dimenzí těch potřeb. V ekonomii, kde odpadá lidská práce k výrobě věcí a určité části služeb se tím modelem blížíme k něčemu, jako mraveniště.

[xkucf03]

Představy o plné automatizaci měl už Marx a dosud se to nenaplnilo.

Totéž se děje i v našem oboru, cyklicky se to vrací, to se třeba mluvilo o tom, jak díky BPMN nebude potřeba nic programovat a někteří se snad i báli o práci. A stalo se to? Nestalo. Navzdory vší automatizaci, vysokoúrovňovým jazykům, frameworkům, novým paradigmatům… které měly zvýšit efektivitu, je pořád práce dost resp. na trhu je dnes nedostatek programátorů.

Osobně si dokážu představit například zcela masivní zdanění korporací

Proč by měl být někdo trestán za to, že vynalezl nástroj, který zvyšuje produktivitu práce?

[Fluttershy, yay!]

Korporace nejsou lidi.

[xkucf03]

Ale patří lidem.

[Käyttäjä 11133]

Patří zpravidla fondům a ty fondy vlastní další korporace, celkem hezky cyklicky...

[Bystroushaak]

Představy o plné automatizaci měl už Marx a dosud se to nenaplnilo.

To není tak úplně pravda. Například automobilky se hodně blíží. Nová tesla gigafactory na výrobu baterek bude plně automatická a tohle uvidíme čím dál víc. Není to binární skok. Budoucnost je tady, jen není rovnoměrně rozložená a s čím dál lepším machine learningem a levnější automatizací se to bude zrychlovat a rovnoměrněji distribuovat.

Totéž se děje i v našem oboru, cyklicky se to vrací, to se třeba mluvilo o tom, jak díky BPMN nebude potřeba nic programovat a někteří se snad i báli o práci. A stalo se to? Nestalo. Navzdory vší automatizaci, vysokoúrovňovým jazykům, frameworkům, novým paradigmatům… které měly zvýšit efektivitu, je pořád práce dost resp. na trhu je dnes nedostatek programátorů.

To není argument, to je jen kuriozita plynoucí ze špatného pochopení problému.

Proč by měl být někdo trestán za to, že vynalezl nástroj, který zvyšuje produktivitu práce?

Protože výroba pro výrobu samotnou nedává smysl. Pokud většina lidí nebude mít peníze, protože budou nahrazeni strojem, nebudou mít ani peníze na nákup.

Navíc to souvisí s axiomy kapitalismu a přírodními zdroji. Proč by měla mít korporace právo nakládat s prostředky? V současnosti je to tak, že jí ho prodává stát, nebo majitel, který je potomkem nebo kupujícím od toho, kdo tam byl první. To ale není samozřejmost, jen součást společenské dohody.

[xkucf03]

Stručně: pokud bychom zavedli ZP příliš brzy, tak odtud vyštveme podnikatele, kteří by něco dobrého vytvořili, a tím se jako stát a národ odsoudíme k neúspěchu. Pokud to neuděláme a budeme tu mít dostatečně svobodné podnikatelské prostředí, tak Češi budou úspěšní podnikatele a časem třeba budeme tak bohatí, že nebude problém dávat nějaké peníze paušálně všem. Nemá cenu se tedy o tom teď moc hádat.

Za daleko důležitější věc považuji pravidlo, že majitelem nemovitosti může být pouze občan daného státu.

A další zásadní otázka je, komu dovolíme být naším občanem – protože pokud sem pustíme nekvalifikované (nebo dokonce nepřizpůsobivé a nepřátelské) lidi z Afriky a podobných končin, tak tu budeme mít plno lidí, kteří by chtěli ZP nebo obecně bohatství zdarma, ale nikoho, kdo by na to vydělal.

[Käyttäjä 11133]

Za daleko důležitější věc považuji pravidlo, že majitelem nemovitosti může být pouze občan daného státu.

Které se už od svého zavedení obchází 2 způsoby...

[xkucf03]

Nová tesla gigafactory na výrobu baterek bude plně automatická a tohle uvidíme čím dál víc. Není to binární skok. Budoucnost je tady, jen není rovnoměrně rozložená a s čím dál lepším machine learningem a levnější automatizací se to bude zrychlovat a rovnoměrněji distribuovat.

A jak k tomu přijdou firmy, které vyrábí klasickým způsobem a zaměstnávají (relativně) hodně lidí? Ty budou taky muset platit vysoké daně (nutné pro financování ZP) nebo budou mít nějaké výjimky?

Pokud budou daně pro všechny stejné, tak to řadu firem (nebo i oborů) zlikviduje a zůstanou jen ty, které mají přístup k nejnovějším technologiím (což by nebyl až takový problém, pokud by vše byl svobodný software a svobodný hardware – pak by k tomu měli přístup reálně všichni).

Pokud budou nějaké úlevy pro „tradiční“ způsoby výroby a služeb, tak to zase může vést k tomu, že firmy nebudou do nových technologií tolik investovat, vývoj se zpomalí a nevznikne něco, co by jinak mohlo pomoci celému lidstvu.

[Bystroushaak]

A jak k tomu přijdou firmy, které vyrábí klasickým způsobem a zaměstnávají (relativně) hodně lidí? Ty budou taky muset platit vysoké daně (nutné pro financování ZP) nebo budou mít nějaké výjimky?

Pokud budou daně pro všechny stejné, tak to řadu firem (nebo i oborů) zlikviduje a zůstanou jen ty, které mají přístup k nejnovějším technologiím (což by nebyl až takový problém, pokud by vše byl svobodný software a svobodný hardware – pak by k tomu měli přístup reálně všichni).

Nejsem věštec. Kam směřuje technologie se dá předpovědět, když se podíváš na současný stav a snažíš se představit kam asi bude pokračovat, ale i tak to často předpovíš blbě. Kam bude směřovat politika .. na to jsem žádnou metodiku zatím nenašel. Pravděpodobně to povede k vyššímu zdanění korporací používajících masivní automatizaci. Možná to umožní něco jako ten ZP. Nevím. Je ale dobré nad tím začít přemýšlet. Pěkne to shrnul CGP Grey v Humans Need Not Apply.

Rád bych podotkl, že se nesnažím tvrdit, že to bude vysloveně dobře, nebo špatně, protože to je prostě moc velké zjednodušení celé věci.

Pokud budou nějaké úlevy pro „tradiční“ způsoby výroby a služeb, tak to zase může vést k tomu, že firmy nebudou do nových technologií tolik investovat, vývoj se zpomalí a nevznikne něco, co by jinak mohlo pomoci celému lidstvu.

To by ty úlevy musely fungovat globálně a to imho prostě nebudou.

[pavlix]

To by ty úlevy musely fungovat globálně a to imho prostě nebudou.

Ono je dost možné, že naopak přestane fungovat globální obchod. V minulosti už byl mnohokrát omezen a ani teď není univerzálně volný.

[xkucf03]

Což připomíná spíš studenou válku nebo rozdělení do více bloků, které spolu nekamarádí, než svět ve kterém bych chtěl žít.

[pavlix]

Tak on se zrovna tebe asi nikdo ptát nebude, v jakém světě že bys to chtěl žít.

[xkucf03]

Tahle diskuse je z velké míry v duchu: „jak by se mi líbilo, aby to bylo“ (přestože to nikdo z diskutujících moc neovlivní).

[pavlix]

Nebudeme se dohadovat, o čem je tato diskuze, že ne? Jsem si naprosto jistý, že je pro každého trochu o něčem jiném.

[Heron]

Totéž se děje i v našem oboru, cyklicky se to vrací, to se třeba mluvilo o tom, jak díky BPMN nebude potřeba nic programovat a někteří se snad i báli o práci. A stalo se to? Nestalo. Navzdory vší automatizaci, vysokoúrovňovým jazykům, frameworkům, novým paradigmatům… které měly zvýšit efektivitu, je pořád práce dost resp. na trhu je dnes nedostatek programátorů.

No spíš se pořád dokola vyrábí různě šišaté kolo. Funkční programy na dnešní agendu existovaly možná před 40lety. Od té doby se to tisíckrát přepsalo, popadalo to, přišlo se o data a bůh ví co a výsledek je, že to funguje stejně jako před 40 lety akorát to vyžaduje milionkrát takový výkon a je 200x tolik úředníků.

Stačí si vzít jen web. Po té, co OS vyřešily všechno co bylo potřeba k řešení a nativní aplikace měly skvělé, bezpečné stabilní prostředí, tak se řeklo ne, půjde to na web. Od té doby se řeší to, co bylo vyřešeno před 20 lety. Jak zařídit to, aby jeden tab nemohl čumět na data druhého tabu a tak dále.

Každý rok přijde nějaký nový hyper cool webový framework, tak se to celé zase přepíše. Prostě proto.

IT je obor, který si práci generuje sám pro sebe. A ostatní mu to furt žerou. Nebo se s tím svezou.

[xkucf03]

No spíš se pořád dokola vyrábí různě šišaté kolo. Funkční programy na dnešní agendu existovaly možná před 40lety.

Ano, taky někdy žasnu nad tím, jak někdo použije nejmodernější technologie, obrovský diskový prostor a výpočetní výkon… a nakonec se slavnostně dopočítá toho, že v pátek lidé odjíždějí z města na víkend chatu :-)

Stačí si vzít jen web.

To mi povídej :-/ Většina webů dělá v zásadě to samé, co kdysi. Akorát tehdy ti stačilo trochu HTML, triviální PHP na serveru a triviální SQL. Dneska je „webový frontend“ šílená změť technologií, potřebuješ desítky knihoven, frameworků, nástrojů, abys dosáhl téhož jako před těmi patnácti nebo více lety. (nebo to můžeš dělat postaru, ale webaři tě budou mít za nekompetentního zpátečníka). Na webovém serveru je situace o něco málo jednodušší. Snad jen ty databáze jsou taková klasika. Ale i tam občas někoho napadne nacpat data do nerelační bezschémové databáze, aby to nebylo tak jednoduché a „nudné“ a nedalo se v tom na první pohled orientovat.

IT je obor, který si práci generuje sám pro sebe.

Smutná pravda, ale týká se to primárně toho webu. Nebo třeba sítí, kde se vymýšlí různé nesmyslné restrikce, následně se všechny protokoly zabalí do HTTP, protože HTTP přes firewally prochází a pak se zase vymýšlejí transparentní proxy a systémy, které se do toho HTTP(S) budou dívat a zjišťovat, jestli je to web nebo něco jiného. Hezky se to zacyklilo. Ale to jsme zase u toho webu. Jinde mi přijde, že je IT poměrně konzervativní obor nebo se tam dělají aspoň zajímavé a reálně inovativní věci.

[Käyttäjä 11133]

Jinde mi přijde, že je IT poměrně konzervativní obor nebo se tam dělají aspoň zajímavé a reálně inovativní věci.

Protimluv...

[xkucf03]

…nebo…

[Heron]

To samé továrny a práce ve stylu „stojím u pásu“, tam to je taky jen otázkou jak rychle to přijde.

Upřímně řečeno se divím, že to ještě stále existuje. Když jsem ještě v minulém století v 15. letech nastupoval na brigádu (a vydržel jsem tam asi tak týden) do čokoládoven, tak jsem si celých těch pět dnů říkal, že to přece nemůže nikdo myslet vážně. Člověk má 8h v kuse cosi strkat do pytlíků? Vždyť na to existují stroje. Tohle přece nemá dělat člověk. No a ono je to tady pořád. Trestuhodné.

[Bystroushaak]

Protože se to stále ještě nevyplatí. Automatizace je drahá a výpadek při přestavování linky je ještě dražší. Ve chvíli, kdy cena padne pod určitou hranici, či přinese takovou optimalizaci, aby se to vyplatilo, tak to přijde samo. Jinak nějaká forma automatizace je všude, i ten samotný pás je automatizace. Jde jen o to to dotáhnout na další stupeň, což se zatím prostě nevyplatilo, protože lidská práce prostě byla levnější.

[Heron]

To byla řečnická otázka.

Nehledě na to, že tehdy tam linka na pytlíky byla. Jedna linka automatická, druhá osazená živými roboty.

[Kalašnikov]

Já se picnu! Ty si těch linek a robotů musel už postavit, že to podáváš s takovou suverenitou. Ostatně jako všechno.

[ehm]

Nemusí stavět linky a roboty, aby mohl předvídat jejich větší rozšíření. Pokud znáš nějaké konkrétní důvody, proč by k tomu rozšíření, tak jak ho popisuje, nemělo dojít, tak sem s nimi.

[Bystroushaak]

Já se picnu! Ty si těch linek a robotů musel už postavit, že to podáváš s takovou suverenitou. Ostatně jako všechno.

Automatizace byla součást mého studia od střední školy a částečně na škole vysoké. To že jsem v tom oboru potom dál nepracoval neznamená, že si neudržuji přehled.

[Bystroushaak]

že to podáváš s takovou suverenitou. Ostatně jako všechno.

Zdá se mi, že jsi asi stále ještě nepřišel na princip fungování diskuze. Specificky, že když se chceš zapojit, tak použiješ argumenty, ne že napadneš osobu řečníka. Koukal jsem na všechny tvoje příspěvky pod tímhle blogem a vždycky jedna věta a jen kecy na toho, kdo to napsal. Co si od toho sleduješ? Jakože reálně, když si představíš stav světa ve chvíli, kdy ten příspěvek píšeš a stav světa potom, co ho odešleš, tak co čekáš za změnu?

[Kalašnikov]

Co si od toho sleduješ?

Pozorný a přemýšlivý čtenář pochopí? ;).

[Bystroushaak]

To je ta iluze transparentnosti. Lidi ti ve skutečnosti do hlavy nevidí a když jen sem tam vykřikneš nějakou větu, tak mi věř, že většina lidí si tě zařadí do úplně jiné kategorie, než do jaké si asi myslíš, že se tím dostáváš. Všimni si, že (minimálně v téhle diskuzi) na tebe nikdo nereagoval tak, že by si namodeloval celou tvojí osobu, namapoval na to co jsi psal a odvodil si z toho hodnotu tvých zápisků. Můžeš se považovat za nedoceněného génia, ale faktem prostě je, že brutálně selháváš ve schopnosti komunikovat svojí myšlenku ostatním a to je tak nějak to jediné, co se v diskuzi na internetu počítá.

Já jen tak, protože mi přišlo, že ti to nedochází, ale pokud je to tvoje strategie, tak ok.

[Kalašnikov]

Myslím, že mi křivdíte :(. Až na tento jediný komentářík jsem vždy stručně a věcně odpověděl na položenou otázku - podle svého nejlepšího vědomí i svědomí. Jednou jsem vyjádřil svůj názor začínající zkratkou IMHO. Jednou jsem si dobíral slečnu (nebo paní co já vím), aby zde neztrácela s náma moc času a nepodlehla nějaké nezdravé újmě. A zde jste mne šokoval svým širokým záběrem i názorem. Nějaké ne zrovna malé zkušenosti s tím také mám, proto ten šok. -- V případě mírného sarkasmu jsem používal smajlík, aby se to poznalo. Se sarkasmem by se to nemělo přehánět, ale někdy je to na místě a diskusi to oživí. Vždy, až na jeden případ, jsem dostal nějakou odpověď, kterou jsem si přečetl a vzal na vědomí. Na diskutování nemám zatím čas ani chuť, snad jindy, takže tak. Děkuji, že akceptujete moji "strategii" a zatím se mějte.

[ehm]

Ty si těch linek a robotů musel už postavit, že to podáváš s takovou suverenitou.

Myslím, že mi křivdíte :(.

[Kalašnikov]

Však jsem psal, že jsem byl zaskočen. Dneska už snad ta hranice mezi tykáním a vykáním není tak ostrá. Klidně si můžeme tykat nebo někdy tykat a jindy vykat, co na tom sejde ;).

[ehm]

Poukazoval jsem na možnost, že ty příspěvky psali dva různí lidé.

[Kalašnikov]

Zbytečně matete čtenáře. Co je na tom špatného, že to v rámci své "strategie" :) raději napíšu pod nikem.

[ehm]

+1. K něčemu podobnému jsem mířil svým komentářem.

[Bystroushaak]

Já jsem se teď trochu zamýšlel, jestli o tom nezkusit napsat blog. Ale asi se mi nechce, hlavně proto, že se v ekonomii fakt nevyznám. Jen ta představa vzdálené budoucnosti, kde máš univerzální rekonfigurovatelnou továrnu, která se během měsíce dokáže rekonfigurovat na základě popisu na úplně cokoliv a do toho lidi, kteří nejsou schopní konkurovat skoro žádné manuální práci..

Přemýšlím třeba, jak na tom budou peníze, protože mi z toho všeho tak nějak plynou hrozné skoky hodnot u všeho možného zboží. X stojí Z, dokud někdo nerekonfiguruje továrnu, pak stojí skoro skokově 0.01 Z. Možná by dávalo smysl odvodit peníze například z energie a založit je na kW mechanické práce..

Taky jaký smysl dává říct, že X bude stát Y jednotek Z, když skoro nic nepasuje na současné ceny. Například jídlo může být v té době skoro zdarma, protože prostě roboty provozovaný vertikální skleník, který má 600% výnosy plodin na m^2 (to vůbec není nereálné už dneska). To že vím, že ZP bude 10000 Schmeckles na měsíc, tak co to vypovídá o tom co si za to koupím? Chleba může stát 0.0001 Schmeckles, mobil 100 Schmeckles a masáž zad 200 Schmeckles, protože to dělá člověk.

[xkucf03]

Jen ta představa vzdálené budoucnosti, kde máš univerzální rekonfigurovatelnou továrnu, která se během měsíce dokáže rekonfigurovat na základě popisu na úplně cokoliv

A kdo napíše ten popis – specifikaci? #350

[Bystroushaak]

Ten kdo to bude umět a komu se to vyplatí?

[sigma]

univerzální rekonfigurovatelnou továrnu

Sice píšeš, že ve vzdálené budoucnosti, ale současné technologie využívané v průmyslové automatizaci jsou na zcela jiném levelu, ze kterého nelze podle mě usuzovat, že něco takového bude v budoucnu smysluplně existovat.

Jsou sice výroby, kde je (téměř) 100% automatizace, ale to jsou buď celkem triviální (byť třeba large-scale) věci, kde je taková úroveň běžná už mnoho (někde nižších desítek) let (třeba chemický / potravinářský / papírenský průmysl), nebo i dost složité věci, ale s obrovskou mírou hromadnosti a unifikace výroby (automotive).

V tom prvním případě ale zůstává dost velké potřeba lidské práce pro udržení té automatizované technologie v provozu. Automatizace některých údržbových činností je představitelná, ale jednak je tam menší až žádná hromadnost a jednak by to vyžadovalo totální redesign prostorového uspořádání těch technologií, které se často vyvíjí po desítky let a staví s obdobným investičním cyklem.

Druhý případ v současnosti spočívá v designu produktu tak aby byl vyrobitelný plně automatizovaně, což je ještě OK, a následně ve stavbě v zásadě jednoúčelové továrny pro tento produkt. To dokud někdo nerekonfiguruje továrnu v současnosti obvykle znamená mnoho člověkoroků inženýrské činnosti a nízké jednotky let na implementaci. To se vyplatí jen u té silně hromadné výroby. Při použití nejlepších technologií a projektového řízení v současnosti nemáme lepší způsob, jak takovou v podstatě jednoúčelovou továrnu postavit. Představa, že napsat na to specifikaci tak dokonalou, že se to pak "postaví samo", bude méně náročné než stávající přístup, nemusí vyjít. Podobně jako ty SW roboty, co nahradí programátory a budou místo nich psát kód podle specifikace, jak už tu někdo linkoval.

Omezení v rekonfigurovatelnosti nejsou ve značné části v deficitu potřebného SW resp. AI, ale v řadě mechanických resp. fyzikálních problémů. Můžeme předvídat úplnou změnu paradigmatu, např. nějakou převratnou metodu 3D tisku z kovových materiálů schopnou z významné části nahradit konvenční metalurgii, tváření a obrábění, ale současný vývoj tomu žádné náznaky nedává. Jinak je příkladů těchto problémů spousta - třeba o fundamentálních omezeních flexibility v oblasti designu robotických manipulátorů a jejich aplikací by se dalo napsat několik článků. Představa, že tyto věci, ke kterým často není vybudován ani solidní teoretický základ, dokážeme vtělit do AI... proč by to mělo být v nějak dohledné době možné?

A k tomu ještě jeden link: https://en.wikipedia.org/wiki/Moravec%27s_paradox -- problém není v softwaru a AI, počítač je schopen drtit rovnice rychleji než člověk, byl k tomu nakonec navržen. I když často třeba pro některá výhodná kinematická uspořádání manipulátorů prostě neexistuje matematická metoda řešení pohybových rovnic v real-time predikovatelném čase, a je to no-go. Vyrobit použitelné aktuátory, které se jen vzdáleně blíží sensomotorickým vlastnostem lidských svalů je pořád sci-fi, natož umístit jich do jednoho stroje stovky.

[Bystroushaak]

Sice píšeš, že ve vzdálené budoucnosti, ale současné technologie využívané v průmyslové automatizaci jsou na zcela jiném levelu, ze kterého nelze podle mě usuzovat, že něco takového bude v budoucnu smysluplně existovat.

Záleží, co je pro tebe budoucnost. Samozřejmě, že to jsou všechno jen odhady, ale když se podíváš 50 let do budoucnosti, tak je možné skoro všechno.

Jsou sice výroby, kde je (téměř) 100% automatizace, ale to jsou buď celkem triviální (byť třeba large-scale) věci, kde je taková úroveň běžná už mnoho (někde nižších desítek) let (třeba chemický / potravinářský / papírenský průmysl), nebo i dost složité věci, ale s obrovskou mírou hromadnosti a unifikace výroby (automotive).

To je právě pointa dnešní doby a toho o čem jsem psal, že začíná být možné automatizovat věci, které dříve nebyly, protože machine learning / AI (ehm ehm) se pomalu prodírá i tam, kde to dřív fungovalo v podstatě úplně triviálně. Zatímco dřív prostě průmyslový robot jel přesně ze souřadnice na souřadnici a veškeré jeho reakce byly úplně primitivní, tak pomalu přichází doba, kdy dokáže reagovat na svoje okolí, rozpoznávat obraz a přizpůsobovat se stavu věcí. Jinými slovy, stává se univerzálním.

Už když jsem studoval někdy v 2010, tak jsme měli hodiny, kde jsme se učili používat průmyslové toolkity na rozpoznávání obrazu a reagovat právě třeba na věci, které jely na pásu a různě je sbírat a kategorizovat a přesunovat. Dobře je to vidět třeba na robotických řeznících, kteří umí zpracovat různě tvarovaná zvířata a okrájet z nich maso efektivním způsobem, jako třeba tenhle robot co dokáže okrájet šunku od kosti. To se zdá jako blbosti, ale ve skutečnosti je to úplně jiná třída zařízení, než předchozí generace. Málokdo si uvědomuje, co znamená generický robot, kterého je možné naučit dělat v podstatě libovolnou mechanickou práci, v rámci které je schopný variabilně reagovat na prostředí.

A i programování se zjednodušuje. Tam kde předchozí generace dokázala kopírovat pohyb operátora, takže mohl robota naučit opakovat zadaný pohyb prostě tím, že mu ho ukázal, dokáže současná generace pomalu, ale jistě chápat záměr operátora. Už neukazuje pohyb, ukazuje co chce vybrat za součástky a robot se to učí přes machine learning a vytváří si vlastní model, který není třeba programovat. Ukážeš mu 10x jak zvednout dveře a nalakovat je a on si vytvoří model, který mu umožní zvednout dveře a nalakovat je. Jenže na rozdíl od předchozí generace bude umět zvednout libovolné dveře libovolného tvaru.

Viz třeba https://www.youtube.com/watch?v=SdI6lrQUa8s

Takže to máme jednu osu trendu - univerzalita automatizace se zvyšuje. Druhá osa je programování, které se zjednodušuje. Nekoukej se kde jsou dneska, koukej se, kam směřují.

Druhý případ v současnosti spočívá v designu produktu tak aby byl vyrobitelný plně automatizovaně, což je ještě OK, a následně ve stavbě v zásadě jednoúčelové továrny pro tento produkt. To dokud někdo nerekonfiguruje továrnu v současnosti obvykle znamená mnoho člověkoroků inženýrské činnosti a nízké jednotky let na implementaci. To se vyplatí jen u té silně hromadné výroby. Při použití nejlepších technologií a projektového řízení v současnosti nemáme lepší způsob, jak takovou v podstatě jednoúčelovou továrnu postavit. Představa, že napsat na to specifikaci tak dokonalou, že se to pak "postaví samo", bude méně náročné než stávající přístup, nemusí vyjít. Podobně jako ty SW roboty, co nahradí programátory a budou místo nich psát kód podle specifikace, jak už tu někdo linkoval.

Určitě, souhlasím. Měl jsem na pokoji dva spolubydlící strojaře, vím jaká byla práce s rekonfigurací výrobní linky. Ale i tam se neustále zvyšuje univerzálnost a jednoduchost. Třeba spousta dnešních malých strojírenských fabrik vypadá prostě tak, že máš pár pásů a podavačů kolem jednoho brutálně drahého, ale výkonného a univerzálního CNC, které dokáže samo vyfrézovat a vyvrtat a obrobit z kusu kovu skoro cokoliv. Co chybí jsou roboti, kteří by dokázali poskládat z několika kusů kus nový, to zatím většinou dělají lidé.

Omezení v rekonfigurovatelnosti nejsou ve značné části v deficitu potřebného SW resp. AI, ale v řadě mechanických resp. fyzikálních problémů. Můžeme předvídat úplnou změnu paradigmatu, např. nějakou převratnou metodu 3D tisku z kovových materiálů schopnou z významné části nahradit konvenční metalurgii, tváření a obrábění, ale současný vývoj tomu žádné náznaky nedává.

Tak zrovna ta metalurgie, tváření a obrábění je brutálně automatizovaná už teď. Občas mě baví na youtube prostě jen tak koukat na videa z továren na obrábění různých věcí. Třeba https://www.youtube.com/watch?v=4XkrNBUvpGs Pointa není, že tam lidi nebudou vůbec, ale že jich tam bude jen málo. Když se na ty videa dívám, tak lidi tam plní z velké míry jen úlohu obsluhy strojů a to jen proto, že automatizace obsluhy strojů je zatím drahá a obtížná, že se to vyplatí třeba jen v těch automobilkách.

Jinak je příkladů těchto problémů spousta - třeba o fundamentálních omezeních flexibility v oblasti designu robotických manipulátorů a jejich aplikací by se dalo napsat několik článků. Představa, že tyto věci, ke kterým často není vybudován ani solidní teoretický základ, dokážeme vtělit do AI... proč by to mělo být v nějak dohledné době možné?

Proč by nebylo? Ale ok, odpovím první - existuje brutální ekonomický tlak to udělat.

A k tomu ještě jeden link: https://en.wikipedia.org/wiki/Moravec%27s_paradox -- problém není v softwaru a AI, počítač je schopen drtit rovnice rychleji než člověk, byl k tomu nakonec navržen. I když často třeba pro některá výhodná kinematická uspořádání manipulátorů prostě neexistuje matematická metoda řešení pohybových rovnic v real-time predikovatelném čase, a je to no-go. Vyrobit použitelné aktuátory, které se jen vzdáleně blíží sensomotorickým vlastnostem lidských svalů je pořád sci-fi, natož umístit jich do jednoho stroje stovky.

Jo, znám. Tohle mi trochu připomíná, jak kdysi lidi říkali, že člověk vždycky nad počítačem vyhraje v šachách. A pak vyhrál počítač. Potom lidi říkali, že nikdy nevyhrajou v Go, protože velký prostor k prohledání. A pak vyhrál počítač v Go. Inovace nestojí a utěšovat se tím, že nyní něco není možné, nebo vyřešené ti nic neříká o stavu světa za deset, nebo dvacet let.

Co se moc nezměnilo je hardware automatizace, ten je podobný už tak 40 let. V poslední době se ale brutálně změnil software, protože už prostě je výpočetní výkon na dělání věcí, které před lety možné nebyly. Samozřejmě, spousta věcí o kterých mluvím je současná hranice, špička technologie, mnohdy omezená a nepraktická na ostatní věci. Ale takové jsou růžky, které budoucnost vystrkuje vždycky. Když se podíváš na první auta, tak jsou taky něco úplně jiného, než to co tu máme o sto let později.

Když mluvím o rekonfigurovatelných továrnách, nepředstavuji si to jako něco, co se rekonfiguruje za den, ale třeba za měsíc, nebo tři. Rozdíl vidím především v tom, že to bude celý balík, který bude od začátku navrhovaný a vymýšlený tak, aby byl rekonfigurovatelný, místo aby se stavěl kolem konkrétního výrobku. To samozřejmě nedává smysl všude, například v chemickém provozu, ale v místech kde chceš něco montovat a obrábět docela jo.

[ehm]

+1×^{1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010}

[Bystroushaak]

Pointa není, že tam lidi nebudou vůbec, ale že jich tam bude jen málo.

K tomuhle bych rád citoval wikipedii a případ se zemědělstvím:

In 1870, almost 50 percent of the US population was employed in agriculture. As of 2008, less than 2 percent of the population is directly employed in agriculture.

Během jednoho století se podíl lidí zaměstnaných v zemědělství změnil z 50% populace na 2%, díky mechanizaci práce. Něco podobného se teď postupně stane i v ostatních odvětvích.

[xkucf03]

Ono to s tou umělou inteligencí nebude zase tak horké…

Právě jsem zjistil, že jedna velká americká firma nezaměstnává na technické podpoře už ani Pakistánce, ani Indy, ale nasadili tam umělou inteligenci. Měl jsem tohle podezření už delší dobu ale poslední odpověď je usvědčila. To by člověk nenapsal, ani debil.

Hodím to do blogu …snad brzy.

[Bystroushaak]

To se dělá už docela dlouho. Někde jsem o tom četl před pár lety článek na /r/programming, kde zkoumali, jestli to je fakt AI, nebo jen ind co sedí u systému s pár stovkami tlačítek pro každou odpověď a mačká je podle toho na co se zeptáš.

Jinak viz třeba: https://www.nuance.com/omni-channel-customer-engagement/voice-and-ivr/conversational-ivr.html

[xkucf03]

Tohle ani nebylo po telefonu, ale psaná komunikace¹. U toho telefonu aspoň víš, že na tebe mluví plechová huba. U té psané komunikace je těžší poznat, jestli je na druhé straně AI nebo jen někdo intelektuálně nepříliš obdařený, kdo vychází z předepsané šablony² a doprostřed vloží nějakou tu větu, kterou sám vymyslel.

_{[1] něco jako e-mail, ale přes jejich interní systém, na e-mail mi chodí jen kopie
[2] pozdrav, poděkování za zprávu, že je rád, že mi může dnes pomáhat, jak moc je pro něj můj problém důležitý, jak moc si váží toho, že jsem jejich zákazník, …, jak pevně věří, že mi jeho rada pomohla, uctivý pozdrav}

[Bystroushaak]

U toho telefonu aspoň víš, že na tebe mluví plechová huba

To bývávalo v minulé generaci a všechny to univerzálně sralo. Dneska je snaha, abys o tom nevěděl a z toho co jsem tak viděl ukázky, tak jsem byl kolikrát na pochybách, jestli to je IVR, nebo ne.

U té psané komunikace je těžší poznat, jestli je na druhé straně AI nebo jen někdo intelektuálně nepříliš obdařený, kdo vychází z předepsané šablony2 a doprostřed vloží nějakou tu větu, kterou sám vymyslel.

Imho šablona.

[xkucf03]

Imho šablona.

Šablona tam samozřejmě je, všechny ty kecy okolo. Ale pak je tam nějaké jádro zprávy a to mi v tomhle případě přijde, že by to člověk nevymyslel – chytlo se to jednoho klíčového slova a k němu vyhrabalo nějakou odpověď, ale absolutně to nedává smysl.

[Bystroushaak]

Představ si, že tam dělá někdo, kdo skoro neumí anglicky, pak začne dávat smysl spousta věcí. Ti prostě vykopíroval nějakou blbost z interní wiki. Ale nevím, je možné, že tam maj nějakého chatbota, nebo tak něco.

[ehm]

A teď si představ, že by to AI začalo šířit nějaké confidential informace. :)

[JS1]

Treba jako tahle AI?

[Bystroushaak]

Náhodou, chatboti mají v tomhle potenciál.

[Käyttäjä 11133]

tzn. vytvoří stejný produkt jako před zavedením ZP, ale utrácet/spotřebovávat bude chtít víc.

I kdybych vydělal 2x víc než vydělávám teď tak neutratím ani o korunu víc...

[xkucf03]

To nehraje roli – tak je utratíš později, nebo je vložíš do banky nebo někomu půjčíš (typicky skrze nějaký finanční produkt) a ten je bude utrácet. Většina lidí si bude buď užívat volna (vytvoří toho méně) nebo pracovat stejně a spotřebovávat víc nebo pracovat stejně a investovat (takže ty peníze navíc utratí dnes někdo jiný a bude jim dlužit).

[JS1]

Jak si představuješ, že tento „ekonomický zázrak“ bude fungovat? Kde se vezme ta hodnota navíc?

Zmeni se struktura spotreby, nebo dokonce spotreba mirne vzroste. Konkretne treba, nebudou se stavet zbytecne neprodejne luxusni byty, ktere pak jen slouzi jako uloziste majetku, a budou se treba vyrabet skutecne veci, ktere lide potrebuji (napr. ty drogy a alkohol, jak napsal uz Randy).

Dokonce si dokazu predstavit, ze v dusledku zavedeni ZP dojde k deflaci, protoze se snizi objem penez v ekonomice v dusledku prave posunu smerem k vetsi spotrebe, ktera neni tazena dluhem.

Ale jelikoz ty se dopoustis stale stejne chyby - nechapes, ze na makroekonomicke urovni se penize nechovaji jako zdroj, jak je tomu na mikroekonomicke urovni - nema smysl s tebou vest na toto tema diskusi.

[xkucf03]

A ještě jedna důležitá věc: jak si představuješ, že by hospodařil stát, který by zavedl ZP? Měl by vyrovnaný rozpočet nebo schodkový? Nebo snad přebytkový? (já vím, zbytečná otázka)

Pokud vyrovnaný, tak před zavedením ZP prosím, abys nejprve prokázal, že jsi schopný hospodařit s vyrovnaným rozpočtem – měl bys ho mít několik let ještě před zavedením ZP. Protože jinak ti (resp. těm politikům) nevěřím, že toho jsi vůbec schopen a obávám se, že lžeš (resp. oni lžou).

Pokud schodkový, tak jak se to pak liší od situace, kdy by si každý občan sám půjčil každý měsíc třeba těch deset tisíc s dlouhodobě odloženým splácením? Až jednou by mu banka zabavila dům, byt, auto, rodinný majetek…¹ a jeho děti by nedostaly žádné dědictví. Proč by to v případě státního dluhu mělo být jiné? Jistě, stát si může vyjednat lepší úrok,² ale jistinu by měl splatit i on. Nebo myslíš, že stát svoje dluhy platit nemusí? Přijde ti normální okrádat věřitele? Lhát jim, že jim půjčené peníze vrátíš i s úrokem, když hraješ na to, že jednou přijde doba, kdy jim jim ukážeš vztyčený prostředníček a dluhy „smažeš“?

_{[1] případně, pokud věřitel usoudí, že ten člověk nikdy během svého života nenashromáždí takový majetek, aby z toho šlo dluh splatit, tak ho asi budou muset odchytit a prodat do otroctví nebo rozřezat a prodat jeho orgány
[2] nebo si může dohromady půjčit víc peněz, třeba těch 10000*10000000, zatímco některým lidem individuálně by nikdo 10000 měsíčně nepůjčil – aneb všichni by byli ručitelé všech}

[Randy_Sh]

NE! S Kucerou tady uz diskutujete asi 10 let, ale vase neochota pochopit zakladni ekonomicke mechanismy je zarazejici.

Tak si to představte. Když zvýším platy bez růstu produktivity, tak budu muset zvýšit ceny. A zvýšení cenové hladiny je inflace.

Stejne tak je to i se zakladnim prijmem. Muzes si to predstavit treba tak, ze pokud do systemu pridame "umele" prerozdeleni, bude potreba jeste dalsi prerozdeleni, aby se penize dostaly od zakazniku k firmam na zaklade jejich pozadavku. Tudiz se v situaci zakladniho prijmu zvysi V, a inflace nutne nemusi nastat, ci dokonce naopak.

Až to uvidím, tak tomu uvěřím. Už se nemůžu dočkat, až to někde zrealizují.

[Käyttäjä 11133]

Tak si to představte. Když zvýším platy bez růstu produktivity, tak budu muset zvýšit ceny. A zvýšení cenové hladiny je inflace.

Nebo si taky třeba můžu snížit marži, takže se to do ceny výsledného produktu vůbec nemusí promítnout...

[Randy_Sh]

Tak si to představte. Když zvýším platy bez růstu produktivity, tak budu muset zvýšit ceny. A zvýšení cenové hladiny je inflace.

Nebo si taky třeba můžu snížit marži, takže se to do ceny výsledného produktu vůbec nemusí promítnout...

To je velmi teoretická možnost. Marže může být tak nízká, že další snížení není možné. I kdyby nebyla, vlastníkům se nebude líbit snížení zisku. A především - zákazníci vyšší cenu klidně zaplatí, protože se jim zvyšují platy.

[melkors]

Až to uvidím, tak tomu uvěřím. Už se nemůžu dočkat, až to někde zrealizují.

Pokud mne skleroza nemyli, tak ve Finsku uz to zkouseji - pravda, na nejakem malem vzorku populace.

Podrobnosti si laskavy ctenar dohleda sam, mne to az tak neinteresuje ...

[Randy_Sh]

Pokud mne skleroza nemyli, tak ve Finsku uz to zkouseji - pravda, na nejakem malem vzorku populace.

Já vím, zkoušejí to na více místech. Ale na malém vzorku je možné skoro všechno. Opravdová zábava by nastala, kdyby to zavedli do praxe pro všechny.

[trekker.dk]

Strucne, existuje zakladni menova rovnice: MV=PY. V je "velocity", tedy zhruba receno kolikrat se dana koruna obrati v ekonomice za dany cas. Tudiz, pokud se zmeni V, muze se klidne zmenit Y (prijmy) aniz by se zmenilo P (ceny). Takze obecne, to co rikas, neplati.

Stejne tak je to i se zakladnim prijmem. Muzes si to predstavit treba tak, ze pokud do systemu pridame "umele" prerozdeleni, bude potreba jeste dalsi prerozdeleni, aby se penize dostaly od zakazniku k firmam na zaklade jejich pozadavku. Tudiz se v situaci zakladniho prijmu zvysi V, a inflace nutne nemusi nastat, ci dokonce naopak.

To je teorie dobrá tak pro případ, že člověk je dokonale sférický objekt ve vakuu.

Základním příjmem - a kde na něj chcete vzít, ještě nikdo nezodpověděl - do ekonomiky nalejete spoustu peněz, ale ne to, čemu se říká hodnoty. Věci jako stavební pozemky, byty, pole, pekárny - těch zůstane pořád stejně. V podstatě jste do ní nalil akorát tak spoustu čísel.

No a reálný člověk - možná až na altruisty, zejména ty, co rádi rozdávají z cizího - se stejně jako ten zlý korporát snaží maximalizovat svůj zisk. Takže když bude třeba někdo pronajímat byt, tak přednost budou mít ti, co nabídnou nejvyšší číslo. Kdo bude stavět bydlení, prodá ho vyšší částku. Lidi bydlící v nájmu budou mít dražší nájemné. Lidi kupující bydlení za něj budou platit pořád stejně - všechny peníze, co se dají vydělat za život, mínus výdaje na jídlo, dovolené, děti apod. Bude to vyšší částka, efekt bude stejný, kdo dneska nemá na vlastní bydlení, nebude na něj mít dál. Nakonec se situace ustálí prakticky ve stejném stavu, v jakém je teď.

Samozřejmě až na lidi, kteří jsou dneska jen tak tak nad cílovou skupinou ZP, protože ti si kvůli zvýšení přerozdělování pohorší, což je určitě skvělá motivace.

Pokud chcete, aby lidi měli zajištěné, že budou mít co jíst a kde bydlet - což je proklamvoaný cíl ZP - tak padejte stavět byty a vyrábět jídlo.

[JS1]

To je teorie dobrá tak pro případ, že člověk je dokonale sférický objekt ve vakuu.

Ugh. Zase, nastuduj si to. Menova rovnice neni fenomenologicka, neni to model. Je to ucetni rovnost, jinymi slovy, v podstate definice toho V.

Pokud chcete, aby lidi měli zajištěné, že budou mít co jíst a kde bydlet - což je proklamvoaný cíl ZP - tak padejte stavět byty a vyrábět jídlo.

O to presne jde. Lidem, kteri bydleni a jidlo nemaji, se daji penize (ZP). Ti ty penize utrati, vytvori tak poptavku, ktera bude uspokojena prostrednictvim trhu (a tudiz se bude vyrabet vic levnych bytu a jidla). Tohle misto toho, aby treba bohati lide nesmyslne sporili (napr. investici do nemovitosti, kterou si pak nikdo nemuze koupit, protoze jsou predrazene, jelikoz se pouzivaji jako collateral).

Staci jen malo, ziskat trochu rozhled v ekonomii a dozvedet se, ze neexistuje jen "ekonomie strany nabidky", jsou i jine, empiricky ne totalne vyvracene teorie.

[xkucf03]

Obávám se, že ZP nebude fungovat, jak si to maluješ ve svých představách.

Vydělat na vlastní bydlení (pokud to nemá být chatrč někde v pohraničí) je dost obtížné, i když máš hodně nadprůměrné příjmy. Tudíž základní příjem, který bude hluboko pod průměrným příjmem, šanci na vlastní bydlení nijak nezvýší.

Co se týče bydlení, pomohly by tři věci:

• Vlastníkem nemovitosti může být pouze občan našeho státu.
• Změna myšlení: ne všichni se musí stěhovat do Prahy. Život – včetně pracovních příležitostí, kultury, sportu atd. – by měl být rovnoměrněji rozložen po celé republice. Poměr rozlohy a počtu obyvatel nemáme zase tak špatný, na jednoho občana připadá celkem dost místa. Ale pokud se většina lidí bude chtít nastěhovat do jednoho či dvou měst, tak to prostě fungovat nebude. Život v Praze tím přelidněním a přetížením dost trpí (a v centru navíc už v podstatě nikdo nežije). S tím se těžko dá něco dělat, pokud lidé nebudou sami chtít – nicméně stát by tomu mohl pomoci investicemi do infrastruktury – pak bys mohl v první fázi (než se to víc decentralizuje) pořád pracovat třeba v té Praze, ale dostal by ses tam rychle vlakem (což sice v některých případech dneska lze, ale mohlo by těch míst/spojů být víc). Privatizace ČD měla vypadat tak, že České dráhy budou skutečně ty dráhy tzn. koleje a nádraží a na nich budou jezdit vlaky různých firem. Stát k tomu udělá jen informační systém, ve kterém budou jízdní řády a nákup jízdenek, aby to pro cestující bylo stejně pohodlné, jako kdyby to celé patřilo jedné firmě. Když už přerozdělovat, tak by stát mohl zadotovat některé spoje, aby podpořil decentralizaci a rovnoměrnější distribuci obyvatel po republice – rozhodně by to bylo lepší přerozdělování, než ZP, který vyšumí do ztracena nebo v horším případě způsobí škody.
• Povolit stavět na mnohem víc pozemcích. Dneska si můžeš koupit pole, ale jestli na něm budeš moci stavět a kdy, to je primárně otázka kontaktů, úplatků a zákulisních informací. Mělo by jít stavět na mnohem víc pozemcích než dnes a mělo by to být transparentní. Nevidím žádnou tragédii v tom, že by se spousta polí zastavěla. Obilí se může pěstovat v těch oblastech, kde chce bydlet méně lidí. Rozhodně by to bylo příjemnější než současný stav, kdy je snaha zastavět každý metr ve městech, vesnicích, satelitech… což má za následek, že jsou malé zahrady, mizí parky, volná prostranství… Stavební pozemek je jen jedna věc – na něm je potřeba postavit dům a to je spousta materiálu a práce – a to rozhýbe ekonomiku a dá lidem smysluplnou užitečnou práci.

ZP je oproti těmto třem bodům úplně irelevantní a nemá na výsledek žádný pozitivní vliv.

[Fluttershy, yay!]

Nevidím žádnou tragédii v tom, že by se spousta polí zastavěla.

To mě nepřekvapuje, že nevidíš problém v destrukci krajiny.

[JS1]

Obávám se, že ZP nebude fungovat

Vis, pokrok neprichazi s lidmi s obavami. Klidne se obavej dal.

Vydělat na vlastní bydlení je dost obtížné, i když máš hodně nadprůměrné příjmy.

Jo vono je to obtizne! Zajimave je, ze i za socialismu (coz byl dost mizerny system) si vetsina lidi mohla dovolit vlastni bydleni. Ale nenech si svoji ideologii kazit fakty.

Vlastníkem nemovitosti může být pouze občan našeho státu.

To je napad. Protoze obcany naseho statu nezajima zisk z renty, jsou to altruiste. Rozdaji nove byty bezdomovcum (pokud budou taky Cesi, samozrejme).

Změna myšlení: ne všichni se musí stěhovat do Prahy.

Zmena mysleni koho? Zamestnavatelu, kteri vytvori pracovni mista mimo Prahu?

Je to k placi, k jakym myslenkovym konstrukcim se uchylujes, aby sis potvrdil svoji ideologii.

Ja nevim jak ZP bude fungovat. Myslim, ze bude, a prijde mi to ocividne. Kazdopadne, melo by se to zkusit. Ja osobne si chci jednou napsat socialni simulaci, ktera mi to trochu ukaze.

[xkucf03]

Obávám se, že ZP nebude fungovat

Vis, pokrok neprichazi s lidmi s obavami. Klidne se obavej dal.

To byl eufemismus pro: „navrhuješ úplné kokotiny“.

Jinak socialismus/kolektivismus tady už byl – člověk se může obávat, že se zase vrátí, ale nenazýval bych to pokrokem.

Zajimave je, ze i za socialismu (coz byl dost mizerny system) si vetsina lidi mohla dovolit vlastni bydleni. Ale nenech si svoji ideologii kazit fakty.

A kolik nemovitostí tehdy skupovali cizinci jako investici?

To je napad. Protoze obcany naseho statu nezajima zisk z renty, jsou to altruiste. Rozdaji nove byty bezdomovcum (pokud budou taky Cesi, samozrejme).

Čechů, natolik bohatých, aby skupovali nemovitosti a „zabírali“ tím prostor ostatním zase tolik není.

Nepočítám lidi, kteří mají dvě garsonky a z toho jednu pronajímají (i těch je celkem málo). I takový člověk je v podstatě chudák, který bydlí na malém prostoru a s rentou + běžným platem nějak vyžije. Musel bys mít desítky milionů, aby to nějak ovlivnilo situaci kolem tebe – např. za deset pořídíš vlastní bydlení a za zbylé desítky nakoupíš pozemky a domy. To už nějaký vliv na ostatní mít může. Ale znovu opakuji: kolik takových Čechů je.

Ovšem v celosvětové populaci takových lidí je velmi mnoho, a že tady skoupí nemovitosti a výrazně zhorší šance českých občanů na vlastní bydlení, je reálné riziko (nebo spíš už současná realita).

Zmena mysleni koho? Zamestnavatelu, kteri vytvori pracovni mista mimo Prahu?

Tohle je problém slepice-vejce. Když se budou kvalifikovaní lidé stěhovat do velkých měst (resp. primárně do Prahy), tak nemá smysl jinde zakládat firmu, protože tam neseženeš lidi. Z toho může pomoci ven ta investice do infrastruktury. To je svým způsobem taky přerozdělování, ale alespoň cílené, aby mělo nějaký efekt – ne jako ZP, který se rozpustí mezi všemi a ve výsledku se nic nezmění (leda k horšímu).

Kazdopadne, melo by se to zkusit.

Kdo rozhodne, že „by se mělo“? Pokud chceš rozdat peníze formou ZP, tak je nejprve musíš někomu vzít – měl by ses tedy zeptat těch, kterým ty peníze bereš, zda s takovou formou přerozdělování souhlasí. Nebo plánuješ provést něco jako znárodnění/zestátnění?

Zatím jsi stále neodpověděl na zásadní otázku: #321 – kde na to chceš vzít? Bude to zase na dluh?

Pokud bychom např. měli zásoby uranu na sto let dopředu, zásobovali elektřinou okolní státy a vydělávali na tom dost peněz, tak si dovedu představit, že by stát tyto peníze rozděloval mezi občany, klidně rovnoměrně formou ZP. Ale to zjevně není náš případ, žádný takový zdroj bezpracného bohatství nemáme.

Jestli tyhle úvahy myslíš vážně, tak si schválně zkus navrhnout vyrovnaný státní rozpočet se ZP. Zamysli se nad tím, jak vysoké by musely být daně a kolik by byl ZP. A zkus odhadnout, jaké by to mělo dopady třeba v příštích deseti letech.

[JS1]

Ja uz jsem k tomu vsechno napsal ve svem prvnim prispevku. Misto abys zacal tam, snazis se me tu grafomanicky presvededcit o nesmyslech; bez empirickych dokladu to nepujde. Zakladni prijem uz se parkrat zkousel a zadne velke problemy to neprineslo.

A kolik nemovitostí tehdy skupovali cizinci jako investici?

Treba tady, ukaz jak je to relevantni na realnych datech. Navic sam veris na trh, takze bys mel chapat, ze podle trzni teorie to nepredstavuje zadny problem.

Ale to zjevně není náš případ, žádný takový zdroj bezpracného bohatství nemáme.

Porad dokolecka - nepochopeni toho, co jsou to penize. Hint: neni to bohatstvi.

Muzes se zacit vzdelavat treba tady.

[Randy_Sh]

Zakladni prijem uz se parkrat zkousel a zadne velke problemy to neprineslo.

Tak proč už to dávno někde nezavedli, když je to taková super věc?

[JS1]

Protoze lide jsou hloupi a veri vic sve vlastni intuici nez empirii.. jako treba ted ty.

[Randy_Sh]

Protoze lide jsou hloupi a veri vic sve vlastni intuici nez empirii.. jako treba ted ty.

Politici chtějí vyhrát volby. A cesta k vítězství vede přes sliby. Před volbami se politici předhánějí, co lidem naslibují, komu navýší platy atd. Proč nikdo nejde do voleb s tím, že všichni dostanou 10 kKč měsíčně za nic? To je přece záruka vítězství.

veri vic sve vlastni intuici nez empirii

A tu empirii máte kde? Zatím proběhlo jen pár pokusů s malým počtem lidí. Uvědomte si, že v malém množství jde skoro všechno. Není problém dát ZP pár tisícům pokusných lidí. Problém nastává v okamžiku, kdy to zavedete pro všechny. Je to jako s technikou - vyrobit v prototypu jde skoro cokoliv. Dostat výrobek do sériové výroby je něco úplně jiného.

[JS1]

O tom ZP neni. Kdybys o tom neco vedel, mohlo by ti to byt jasne.

Ano, zkouselo se to, nebe se nezhroutilo. Nakonec se pravdepodobne ukaze, ze je to velmi rozumne, stejne jako se to ukazalo u demokracie. Ale tu take lide nejak zvlast nechteli. Nekteri lide (jako treba ty) jsou proste konzervativni a brani se zmenam k lepsimu. Zpatecnictvim ale jen tezko presvedcis nekoho v diskusi, takze se radsi uz nesnaz.

[Randy_Sh]

O tom ZP neni. Kdybys o tom neco vedel, mohlo by ti to byt jasne.

O čem není ZP? Já se ptám, proč takovou super věc ještě nikdo nezavedl, když by mu to vyhrálo volby.

Ano, zkouselo se to, nebe se nezhroutilo.

Jak říkám, dát tisícovce lidí ZP ve výši 10 kKč měsíčně, to není problém. To dělá 120 MKč ročně, což je pro státní rozpočet prkotina. Problémy nastanou, když ten projekt rozšíříme na všechny.

[trekker.dk]

A která že empirie to je? Základní příjem na úrovni celého státu se nikde nezkoušel, takže těžko můžete tvrdit něco o reálných zkušenostech.

[Randy_Sh]

Zajimave je, ze i za socialismu (coz byl dost mizerny system) si vetsina lidi mohla dovolit vlastni bydleni. Ale nenech si svoji ideologii kazit fakty.

Co přesně si představujete pod výrazem, že si většina lidí mohla dovolit vlastní bydlení? Třeba že člověk dva roky nechodil do hospody a nejel na zahraniční dovolenou a potom si za uspořené peníze pořídil byt v Praze? Zažil jste vůbec tu dobu? Doporučuji shlédnout některé časosběrné dokumenty z té doby, např. Soukromý vesmír od Heleny Třeštíkové. Mladá rodina s dětmi bydlela u rodičů, což byl problém. Aby získali vlastní bydlení, tak udělali něco z dnešního pohledu těžko pochopitelného - odstěhovali se do pronajaté ruiny, kterou na vlastní náklady zrekonstruovali nebo tak něco. Už si detaily bohužel nepamatuji, ale vím, že mi to přišlo opravdu mimo.

[JS1]

No ona byla ruzna obdobi, nekdy byl vetsi nedostatek bytu, nekdy jen mensi. Ale rezim i ve sve neefektivite dokazal vyprodukovat dost na bydleni (relativne slusne - panelakove) pro kazdeho. Dnesni system vyprodukuje potencialne vic, ale lide, kteri to potrebuji, si to nemohou dovolit - protoze zde existuje vrstva lidi, kteri na najmech a hypotekach bezpracne profituji. To tehdy neexistovalo.

Je to trochu podobne jako debata o duchodovych systemech. Zastanci prubezneho reseni (kam se radim i ja) chapou, ze existuje neco jako socialni kontrakt.

Ale kdo to nechce videt (nebo chce videt jen cernobile), nevidi.

[Randy_Sh]

No ona byla ruzna obdobi, nekdy byl vetsi nedostatek bytu, nekdy jen mensi.

V kterých letech byl ten nedostatek menší a co přesně ten "menší" nedostatek znamenal? Čekal bych odpověď typu: v roce X si kdokoliv požádal o byt v Praze a za Y měsíců se stěhoval.

Je to trochu podobne jako debata o duchodovych systemech. Zastanci prubezneho reseni (kam se radim i ja) chapou, ze existuje neco jako socialni kontrakt.

Když nebudou peníze, a to vzhledem k demografickému vývoji nebudou, tak vám je nějaký kontrakt k ničemu.

[JS1]

Pokud vim, tak v 70. letech byl nedostatek, ale to se zacalo resit pomoci panelaku. Pak se to trochu zlepsilo. Konkretni cisla nejsou podstatna, za prve mi slo o neco jineho, a nedelam studii o tom, jak spatne se zilo za socialismu, na to studie neni potreba.

Zase, stejny problem porad dokolecka - penize se daji vytisknout, demograficky vyvoj nijak dramaticky neni (populace v Cesku mirne roste), takze v cem je tvuj problem? V idiocii - nepochopeni toho, co jsou penize, a nacionalismu.

[Randy_Sh]

Konkretni cisla nejsou podstatna

Konkrétní čísla jsou naprosto nejdůležitější. Ono totiž výraz "pak se to trochu zlepšilo" může klidně znamenat, že nejdřív se na byt čekalo 15 let a potom se to zlepšilo na 12.

penize se daji vytisknout,

Ano, už to párkrát v historii zkoušeli (Německo 1923, Zimbabwe, Venezuela).

demograficky vyvoj nijak dramaticky neni

Jen se poněkud zhoršuje poměr mezi lidmi v důchodovém a produktivním věku.

[JS1]

Fakt nerozumim tomu, proc misto opakovani stale stejnych odpovedi, s kterymi jsem jiz obeznamen, si radeji detailne nenastudujes muj uhel pohledu a nezamyslis se nad tim?

Stale nechapes zakladni ekonomicke zakonitosti. Zde konkretne - jak vznikaji penize (vsechny se tisknou), ze podstatny pro vyvoj ekonomiky je HDP a nikoli pomer produktivnich lidi.

[Randy_Sh]

Stale nechapes zakladni ekonomicke zakonitosti. Zde konkretne - jak vznikaji penize (vsechny se tisknou),

Ano, peníze se tisknou. Dokonce se dnes ani tisknout nemusí, centrální banka je vytvoří elektronicky. Problém je, jak si pomůžeme, když budeme tisknout/generovat peníze z ničeho. Výsledkem nebude blahobyt, ale inflace.

ze podstatny pro vyvoj ekonomiky je HDP

To je pravda, teď je jen nutné zařídit takovou "maličkost" - růst HDP. V Řecku jim to moc nejde. I když teď jsme na vrcholu ekonomického cyklu a dokonce i jižní státy EU se trochu zvedají.

[JS1]

No jak pisu, nechapes to. Penize vzdycky vznikaji z niceho, v podstate jde o dluh, ktery lze prodat treti strane. Je jen otazka, kdo to dela - dnes to dela z mensi casti centralni banka a z vetsi casti komercni banky.

Otazka vyrovnaneho statniho rozpoctu je pak jen otazkou kontraktu mezi statem a veriteli. Dost podivneho kontraktu.. zvlast kdyz jsou to casto prave ti veritele, kdo tiskne penize "z niceho".

Rust HDP v Recku by se dal zaridit pomerne snadno. Stacilo by treba zavest ZP. Ale zase, ekonomicka ortodoxie (a ekonomicke zajmy) to povazuji za spatne. Je tak tezke pochopit, ze proste ne vsichni ekonomicti akteri chteji rust HDP?

Skoda, ze nad tim stale nepremyslis. Uz me to moc nebavi, diskutovat s nekym, kdo nema zajem se nad tim, co rika, trochu zamyslet.

[trekker.dk]

Penize vzdycky vznikaji z niceho, v podstate jde o dluh, ktery lze prodat treti strane.

To je pěkná teorie, ale opomíjí praxi, ve které člověka nezajímá, jak vznikly, ale kolik jich má a co si za ně koupí. A když jich necháte vzniknout moc, lidi jich prostě za věci budou chtít víc. To se jmenuje inflace a většinou to krátkodobě prospívá jenom tomu, kdo ty peníze vyrábí.

[JS1]

To je pěkná teorie, ale opomíjí praxi, ve které člověka nezajímá, jak vznikly, ale kolik jich má a co si za ně koupí.

A co tu asi porad dokola pisu? Ze na mikro urovni se penize chovaji jinak nez na makro urovni, a nelze je srovnavat.

A když jich necháte vzniknout moc

O tom kolik vznikne penez dnes vetsina statu fakticky nerozhoduje, protoze velka cast tvorby penez je v rukou komercnich bank.

Kazdopadne, cele tohle je strawman. Prave diky inflaci jich nemuze "vzniknout moc". Ale to nic nerika o tom, co se stane pri zavedeni ZP, protoze ten meni strukturu poptavky a to je to klicove!

[xkucf03]

Ale to nic nerika o tom, co se stane pri zavedeni ZP, protoze ten meni strukturu poptavky a to je to klicove!

Aby to (skrz inflaci) nevyšumělo do ztracena (lidé by dostávali bezcenné papírky, za které si nic nekoupí), tak bys musel někomu ty peníze sebrat, místo abys je natiskl. To znamená obyčejné přerozdělování resp. pořádně vysoké zdanění (což ale zase vyžene řadu podnikatelů do svobodnějších a férovějších zemí a tvoji ekonomiku to ve výsledku poškodí).

[Fluttershy, yay!]

Za to dobu, co tady opakuješ furt to samé, sis mohl najít a přečíst pár článků, které se UBI a inflací zabývají, protože o tom už byly napsány stohy.

[Randy_Sh]

Rust HDP v Recku by se dal zaridit pomerne snadno. Stacilo by treba zavest ZP. Ale zase, ekonomicka ortodoxie (a ekonomicke zajmy) to povazuji za spatne.

V roce 2015 vyhrála v Řecku volby krajně levicová Syriza. Jejím programem byly odvážné sliby o ukončení škrtů atd. Proč Syriza nezavedla ZP? Proč nevyhlásili bankrot? Proč pokračují v nastoleném kurzu úspor? Že by byl Tsipras ve skutečnosti agentem velkokapitálu? Není to spíš tak, že v opozici můžete slibovat cokoliv, ale když jste ve vládě, tak stojíte tváří v tvář tvrdé realitě?

[JS1]

Proč Syriza nezavedla ZP? Proč nevyhlásili bankrot? Proč pokračují v nastoleném kurzu úspor?

Protoze by museli opustit Eurozonu a to by byl ekonomicky masakr. Proste si ze dvou spatnych moznosti vybrali tu mene spatnou, ale zase, stavis falesne dilema, to neznamena, ze neexistuji lepsi moznosti, jak se s tou situaci vyporadat.

[Randy_Sh]

A co Venezuela? Kde přesně udělali soudruzi chybu? Tam žádnou eurozónu nemají, peníze mohou tisknout podle libosti a jako bonus sedí na obřích zásobách ropy.

[JS1]

Nevim, jak souvisi Venezuela se ZP. Kdybychom o tom chteli diskutovat, musel bych si o ni neco precist (nemam vsechno v hlave), ale to muzes udelat i sam. Ja v tom nevidim moc prinos. Existuje spousta zpusobu, jak muze stat selhat.

[Randy_Sh]

Nevim, jak souvisi Venezuela se ZP.

Třeba takto - co brání Venezuele zavést ZP? A pomohlo by jim to?

[JS1]

Pochybuji, ze by jim to pomohlo.

Je to asi jako ptat se bezdomovce, jestli by mu nepomohlo udelat si doktorat.

[xkucf03]

Stacilo by treba zavest ZP. Ale zase, ekonomicka ortodoxie (a ekonomicke zajmy) to povazuji za spatne. Je tak tezke pochopit, ze proste ne vsichni ekonomicti akteri chteji rust HDP?

A jak by sis to představoval? Že si Řecko natiskne Eura, rozdá je Řekům a ti si za ně nakoupí zboží z Německa a dalších zemí a budou tak žít v blahobytu a poroste jim HDP? Jak k tomu přijdou ty ostatní státy?

Proč bych si Eura nemohl natisknout já a rozdat je své rodině a kamarádům? Taky bychom tím přece přispěli k růstu HDP a bylo by to bezva, ne?

[xkucf03]

ze podstatny pro vyvoj ekonomiky je HDP

Je otázka, co myslíš tou ekonomikou. Pokud má stát zastupovat zájmy svých občanů, tak je daleko důležitější HNP. Jinak se ti totiž může stát, že ti krásně roste HDP, jenže zisky odcházejí do zahraničí a ve firmách pracují cizinci, takže občané daného státu z toho nic nemají nebo jsou dokonce v mínusu – přestože to slavné HDP hezky roste.

[xkucf03]

chapou, ze existuje neco jako socialni kontrakt.

A to, že socialista dneska zadluží budoucí generace je taky kontrakt? Ptal se někdo těch budoucích generací, jestli s tímto „kontraktem“ souhlasí?

[JS1]

Uz ti to rikam asi podesate - je rozdil mezi makro- a mikro- ekonomii. Stat se zadluzit nemuze, ale lide ano. Protoze stat jako celek nemuze (z fyzikalnich duvodu) spotrebovavat neco, co jeste nebylo vyrobeno, tedy zit na dluh.

Tahle debata nema smysl, kdyz ti nejsou jasne zakladni veci. A pritom jste to meli ve skole.

[Randy_Sh]

Uz ti to rikam asi podesate - je rozdil mezi makro- a mikro- ekonomii. Stat se zadluzit nemuze, ale lide ano.

Tak to vysvětlete v Řecku, že vlastně nejsou zadlužení.

[JS1]

Recko ma externi dluh vuci EU, ktery by EU docela klidne mohla monetizovat, kdyby chtela. Ale protoze ji vedou idioti (nebo spis vychytralci), tak to nechce udelat.

Poukazuje na to spousta lidi. Staci se trochu zamyslet, proc asi.

[xkucf03]

ktery by EU docela klidne mohla monetizovat, kdyby chtela

Tím myslíš natisknout Eura a řecký dluh „vymazat“? Jak by k tomu přišli ti, kteří drží nějaká Eura (tzn. víceméně všichni kolem)? Ve skutečnosti by ten řecký dluh zaplatili oni – tím, že bys jim znehodnotil jejich úspory.

Akorát bys ten dluh rozpustil mezi větší množství lidí, ale to není obecné řešení problému – „funguje“ to jen ve velmi specifických případech, kdy máš poměrně malý problém a poměrně dost lidí, mezi které ho lze rozpustit. Je to něco jako pyramidová hra – pokud jsi na začátku pyramidy, tak na tom můžeš vydělat, ale jak se pyramida začne rozrůstat tak za chvíli už není kde brát – dojdou ti lidi, kteří by to platili.

[Fluttershy, yay!]

Jeden by řekl, že to patří mezi stěžejní motivace pro unifikaci, tady opak „fuck you, got mine“.

[JS1]

Ted to ctu podruhe - v podstate jde o to, ze Recko neni tak uplne suverenni/nezavisly stat. Takze ano, jeden region muze spotrebovavat vic nez vyrobi. Ale jako celek nemohou. Samozrejme, vetsina statu tyhle rozdily vyrovnava, protoze neni duvod drzet region odpovedny za fakt, ze je ekonomicky vice nebo mene produktivni. Stejne tak i EU (Eurozona) by mela chapat, ze Recko je jeji soucasti a tedy to neni dobre, kdyz tam lide ekonomicky zivori.

[ehm]

Mně spíš prijde, že základní věci nejsou jasné tobě.

Ekonomie je v jádru dost jednoduchá. Fakt, že v praxi do toho vstupují různé zvláštní zásahy, centrální banky apod., je prostě jen zkurvenost systému. Ty tyhle věci do diskuze zatahuješ s tím, že očekáváš, že to nějak zázračně vyřeší a odůvodní otázky okolo ZP. To se ale nestane, pokud nepřijdeš s nějakým mechanismem, jak zvýšit bohatství našeho státu.

Zkus si tu situaci zjednodušit. Několik tisíc lidí žije někde na ostrově – třeba potomci nějakých trosečníků. Peníze nemají – používají jen barterové směny. Ekonomika je tam taková jednodušší; rozvinutý primární a sekundární sektor, částečně se rozvíjející terciární. Jsou tam lovci a rybáři, dřevorubci, stavitelé, kuchaři, lékař, možná nějací umělci.

Může tam fungovat základní příjem? Jak bys musel tu výchozí podmínku upravit, aby tam fungovat mohl?

[JS1]

To se ale nestane, pokud nepřijdeš s nějakým mechanismem, jak zvýšit bohatství našeho státu.

Ten zazracny mechanismus tu mame a rika se mu kapitalismus. Akorat to vsechno zacina od poptavky.

Může tam fungovat základní příjem? Jak bys musel tu výchozí podmínku upravit, aby tam fungovat mohl?

Samozrejme, ze by tam fungovat mohl. Kazda profese by dala cast sveho produktu do fondu, ktery by se rozdelil rovnym dilem mezi vsechny. Dokonce bych i odhadoval, ze nektere (technologicky primitivnejsi) spolecnosti tak i fungovaly.

Nicmene, v takove spolecnosti neni moc duvod ZP mit. Ten realny prinos je ve spolecnosti, kde je vysoka produktivita a je kapitalisticka. Ta tvoje spolecnost nevypada moc kapitalisticky (nejak tam nevidim tu akumulaci kapitalu), takze tam asi nema vyznam ZP zavadet.

[ehm]

Definice kapitalismu na Wikipedii:

Kapitalismus je ekonomický systém, v němž jsou výrobní prostředky v soukromém vlastnictví a jsou provozovány v prostředí tržní ekonomiky za účelem dosažení zisku. Akumulací (části) zisku vzniká kapitál, který je znovu investován do výroby za účelem navýšení zisku.

Není to závislé na akumulaci majetku v monetární formě. Rybář může vlastnit loď a prut (výrobní prostředky). Jejich používáním produkuje zisk – ulovené ryby. Ty pak může směnit za brambory či práci a um jiných lidí.

Tedy ta společnost je v té mnou myšlené podobě tržní a kapitalistická.

Kazda profese by dala cast sveho produktu do fondu, ktery by se rozdelil rovnym dilem mezi vsechny.

Je to socialismus v té nejméně smysluplné formě. Zvyšuješ přerozdělování (které vždy přidává neefektivitu) a snižuješ intelektuální motivaci.

Představ si, že na tom ostrově je rybář, co každý den uloví 1000 ryb, protože si dokázal vyvinout lepší nástroje a umí je lépe ovládat. Ale stále je to závislé na jeho práci.

1000 ryb za den nikdy nesní – lovit takový objem ryb dává smysl jen v případě, že je dokáže směnit za produkty práce jiných lidí, a zvýšit tak svůj životní komfort. Zatímco na lodi chytá ryby, možná mu muži staví dům a ženy válí na stehnech doutníky.

Když zavedeš základní příjem, začne se tahle vysoká vyprodukovaná hodnota – 1000 ryb denně – rozdělovat ostatním bez ohledu na to, jestli pracují, nebo ne. Možná pracovat přestanou, nebo budou méně ochotní pracovat. Tedy produktivní rybář nejen, že je zdaněn, ale ještě doplácí na nárůst cen. A jsou teď dvě možnosti: Buď si chce svůj životní komfort udržet a svou produktivitu musí ještě výrazně zvýšit (a pokud už to nemůže dál automatizovat a je to závislé na jeho práci, tak musí déle pracovat), nebo ho to přestane bavit, protože jeho kupní síla při stejném množství vykonané práce prudce poklesne.

Sníží-li skutečně objem vykonané práce, sníží se základní příjem všech ostatních. Krátké období „koláčů bez práce“ končí a je na čase opět začít pracovat. A komu by se chtělo začít se snažit až moc, když mu to pak ostatní, kterým se do práce nechce, seberou? Povede to k chudobě. Samozřejmě, že se to někdy zlomí, a produktivita asi zase začne trochu stoupat. Ale nejspíš to bude pomalu a dlouho a na úkor těch snaživějších – ti méně snaživí se do práce už možná nikdy nevrátí. A pořád se to bude točit v cyklech – někdo si řekne, že už se mu prostě nechce chodit pracovat, protože hlady stejně neumře. Chvíli se bude poflakovat, zatímco ostatní dřou. A pak zase bude pracovat on a ostatní se budou flákat.

Něco podobného pro ekonomiku není zdravé. Trh bude destabilizovaný a celková produktivita bude nižší. V reálném světě – který je přecejen o mnoho složitější než podobné velmi zjednodušené a idealizované úvahy – takové výkyvy nahrávají spekulantům.

Rozumný socialismus je to, že když dřevorubce při práci v lese zavalí strom a on ochrne, společnost se o něj přiměřeně postará – nenechají ho zemřít hlady s tím, že je to jeho problém a ať se víc snaží.

Nesmyslný socialismus je to, že sponzoruješ lidi, kteří jsou líní nebo neschopní vlastním přičiněním. A úplně nejhorší socialismus je takový, který v tom lidi přímo podporuje a vybízí je k tomu.

Každý, kdo není sociopat, má nějakou schopnost empatie a cítění s druhými. Proto, a právě proto, by v popsaném společenství určité socialistické prvky velmi pravděpodobně fungovaly i na dobrovolné bázi.

Můžeme se bavit o tom, že tam by to fungovalo proto, že se jedná o dostatečně malé společenství. Na úrovni státu s mnohamilionovou populací to není až tak dobře proveditelné, pokud bohatství není rovnoměrně rozložené po celém území a všude v sousedství nepanují přátelské vztahy a otevřenost. Tedy dává smysl to do nějaké míry centralizovat – a v tomto ohledu jsem v rozporu s většinou libertariánů a anarchokapitalistů.

Jde o to, že z konkrétní podoby toho sociálního systému bys měl mít dobrý pocit (v důsledku té empatie). Rozhodně bys neměl mít pocit, že se dřeš na nějaké lemply, ze kterých se ti na ulici dělá na blití. Musí tam být ta rozumná hranice – pak se ty negativní dopady na ekonomiku minimalizují a ještě docíliš příjemnějšího mezilidského soužití.

Najít tu rozumnou hranici není jednoduché. Jsou případy, kdy je to jednodušší a shodne se na nich většina lidí, ale jsou případy, kdy je to mnohem složitější. Pohrával jsem si s myšlenkou povinných příspěvků ve stanoveném objemu. Tedy – do sociálního systému musíš odvést minimálně určitou částku, ale máš možnost upřesnit, kdo ji má dostat. Můžou tam být limity – tak, aby se nestalo, že bezruký kytarista nasbírá 10 milionů, protože lidi zaujme, zatímco cikánská dívka, která byla obětí žhářského útoku, nedostane ani korunu. A teoreticky tam můžou být i minima – peníze se z rozpočtu nejprve rozdělí tak, aby všude byla pokrytá ta minima. Zbylou částku rozdělí lidi.

Proč stát stále neprovozuje jeden posraný portál, kde bys měl přístup ke všemu a mohl jednotně komunikovat s celou státní správou? A tam přesně můžou tyhle věcí být jednoduše zakomponované. Uvidíš tam, kolik po tobě stát chce zaplatit, a přehled všech plateb. No a taky bys měl možnost se podílet na přerozdělování těch peněz v rámci sociálního systému. Protože aby opravdu mohla být řeč o sociálním systému, musí v tom občané participovat i jinak než odevzdáváním části výplaty!

Kdo by přerozdělovat nic nechtěl, tak by to nedělal. Rozprsklo by se to automaticky. Kdo by chtěl přispět víc, měl by tu možnost.

Částečně by to mohlo suplovat potřebu kvůli každé sbírce na nemocné dítě a kdesi cosi zakládat nový web, peníze nechávat téct přes neziskovky apod.

Podobný princip by teoreticky mohl jít aplikovat i na další části státního rozpočtu. Nejsem příznivcem demokracie, ale pokud už někdo udělá racionálnější rozhodnutí, tak snad ve chvíli, kdy rozděluje svoje vlastní peníze – ne když rozhoduje o pěnezích jiných.

Přihoď k tomu zrušení různých dotací, předražených státních zakázek, byrokracie, zbytečných úřadů, úředníků a zákazů, a začneš se blížit mojí představě ideálního státu...

Chce to dívat se víc konkrétně a prakticky. Dostat stát do stavu, který považuji za ideální, by byla záležitost na mnoho desetiletí. Musí se to dělat postupnými, strategickými změnami. Participování na přerozdělování peněz by byla jedna z nich. Je to technicky realizovatelné, málo riskantní, postupně adaptovatelné.

[JS1]

No, napsal jsi toho hodne, coz bylo zbytecne, protoze ja tomu argumentu rozumim. Hlavni problem ovsem je - kdo si tech 1000 ryb koupi? Skryte predpokladas, ze tam automaticky bude odbyt (takovemu predpokladu se rika Sayuv zakon a je to nesmysl), ale tak prave moderni spolecnosti nevypadaji (ani ty hodne socialisticke) a tudiz je prostor pro rust spotreby a tedy produkce.

Ono by to nejlepe bylo videt na simulaci. No kdybych netravil tolik casu diskutovanim na Internetu, mozna bych i takovou napsal.

[ehm]

No, napsal jsi toho hodne, coz bylo zbytecne, protoze ja tomu argumentu rozumim.

Volně jsem přešel k jinému tématu.

Hlavni problem ovsem je - kdo si tech 1000 ryb koupi? Skryte predpokladas, ze tam automaticky bude odbyt

Nepředpokládám, že by dál rybařil, kdyby ten odbyt neměl.

tak prave moderni spolecnosti nevypadaji (ani ty hodne socialisticke) a tudiz je prostor pro rust spotreby a tedy produkce

Může začít klesat cena, ale jiný prostor pro růst spotřeby tam nevidím.

[JS1]

Může začít klesat cena, ale jiný prostor pro růst spotřeby tam nevidím.

Jakto? Vzdyt jsi to zrovna napsal:

Nepředpokládám, že by dál rybařil, kdyby ten odbyt neměl.

Jinak receno, mohl by urybarit i vic, tedy zvysit produkci, tedy muze narust i spotreba.

[Bystroushaak]

Může tam fungovat základní příjem? Jak bys musel tu výchozí podmínku upravit, aby tam fungovat mohl?

Že se o některé věci začne starat automatika. Například automatická loď na lov ryb a automatická past na lov prasat. Tím se z toho stanou v podstatě obecní zdroje, jako je třeba studna, o které se všichni můžou dělit a tím mít jejich „základní příjem“.

Pokud začnou používat nějakou vzácnou a netriviálně padělatelnou jednotku jako peníze (kly divočáků třeba), můžou ten základní příjem ryb začít vyměňovat za kly a od toho už je jen krok dál, aby rovnou dostávali kly a tu výměnu provedl ten automat (státní korporace) co ryby dodává.

Celé to ale stojí na tom, že se něco objevuje v podstatě bez práce a „„„zdarma“““ (což není, někdo musí tu automatiku vyrobit a udržovat) a tím se z toho může stát obecní zdroj. Taky musí být odbyt pro to co automatika vyrábí, například restaurace, která potřebuje víc ryb. Když nebude, tak prostě občani dostanou místo klů samotný produkt.

V dnešní době sice stále ještě nejsme na téhle úrovni automatizace, aby se dalo třeba úplně automaticky pěstovat jídlo, ale blížíme se a třeba v dvacetiletém horizontu si to umím představit. Náklady pak padají v podstatě jen na výstavbu a údržbu, za předpokladu, že to bude provozovat stát jako službu pro občany, na které nechce profit. Jenže tyhle státní služby většinou končí tak že výdělek se utopí někde v rámci státu a lidi z toho přímo dostanou tak leda hovno.

[ehm]

Souhlasím. Něco podobného jsem tu naznačoval nedávno (už ani nevím kde, mám v těch diskuzích bordel).

[Randy_Sh]

V dnešní době sice stále ještě nejsme na téhle úrovni automatizace, aby se dalo třeba úplně automaticky pěstovat jídlo, ale blížíme se a třeba v dvacetiletém horizontu si to umím představit.

Já bych řekl, že už se to v podstatě stalo. V roce 1870 pracovala v USA v zemědělství polovina populace, nyní jsou to necelá 2%. Potraviny jsou jistě levnější, ale jinak se toho zase moc nezměnilo.

Náklady pak padají v podstatě jen na výstavbu a údržbu

Chlap s kombajnem (nebo třeba bagrem) sice udělá práci, kterou dříve dělaly desítky lidí, takže na platech se výrazně ušetří. Ale kombajn stojí miliony korun a to se do nákladů musí promítnout.

[Bystroushaak]

Já bych řekl, že už se to v podstatě stalo. V roce 1870 pracovala v USA v zemědělství polovina populace, nyní jsou to necelá 2%. Potraviny jsou jistě levnější, ale jinak se toho zase moc nezměnilo.

#414

Moc nezměnilo? Reálně v ČR v podstatě nikdo netrpí hladem. Naopak se začíná řešit přežírání velké části populace jako zdravotní problém.

Chlap s kombajnem (nebo třeba bagrem) sice udělá práci, kterou dříve dělaly desítky lidí, takže na platech se výrazně ušetří. Ale kombajn stojí miliony korun a to se do nákladů musí promítnout.

Co se týče té ceny kombajnu, to je otázka, kdy se svět dočká nějakého „Muska“, který srazí cenu těsně nad výrobní náklady + vývoj, prostě protože věří v to že by kombajny měly být levné a opravitelné. Momentálně to jde přesně opačným směrem, kde jsou čím dál míň opravitelný, každý výrobce používá custom součástky atd.. Kdyby to někdo chrlil v masové sérii formou vyměnitelných bloků, tak zadupe konkurenci do země během pár let.

[Käyttäjä 11133]

Co se týče té ceny kombajnu, to je otázka, kdy se svět dočká nějakého „Muska“, který srazí cenu těsně nad výrobní náklady + vývoj, prostě protože věří v to že by kombajny měly být levné a opravitelné.

A něco takového dělá která z Muskových firem?

[Randy_Sh]

A něco takového dělá která z Muskových firem?

SpaceX?

[Bystroushaak]

A něco takového dělá která z Muskových firem?

Tesla.

[Käyttäjä 11133]

Whether or not they will manage to is still up for debate, but an analyst today came out with a note predicting that they will be able to achieve a ~25% gross margin – comparable with the Model S’ margin.

[Bystroushaak]

Podívej se jaké mají zisky celkově. Momentálně jsou co jsem tak četl v dluzích, protože úplně všechno narvali do vývoje a produkce. Mimo jiné taky uvolnili patenty, místo aby je použili k trollingu.

SpaceX je taky docela hezký příklad, kde se jim podařilo srazit cenu jak nízko to jen šlo a to ještě pořád neskončili.

[Käyttäjä 11133]

Takže Tesla má jako automobilka jednu z nejvyšších hrubých marží a ty ji uvádíš jako příklad samaritánství? Samozřejmě že jsou v dluzích, automobilový průmysl není nejlevnější na vstup, stavba továren něco stojí a to že mají vysokou hrubou marži je jediný důvod proč Tesla vůbec ještě existuje, protože bez emise nových akcií by už dávno skončila v bankrotu, představa že jakmile začnou vyrábět sériovější auta bude ta marže nižší je taky mimo, vzhledem k tomu, že analytici předpovídají zhruba stejné hrubé marže i u high-volume Model 3.

Ke SpaceX se vyjadřovat nebudu, protože není k dispozici dostatek informací k analýze, ale hádám že vzhledem k tomu, že dosáhla nedávno valuace 21 mld. USD tak to asi taky nebude charita, a až jim bude jejich klíčová myšlenka o návratnosti prvního stupně raket fungovat bezchybně, tak to bude taky hezká dojná kráva.

[Käyttäjä 11133]

Jen pro doplnění...

Gross margin is on average 24% over the last four years. Not bad, especially when compared to the competition such as General Motors with a meager 11%.

[Bystroushaak]

Takže Tesla má jako automobilka jednu z nejvyšších hrubých marží a ty ji uvádíš jako příklad samaritánství? Samozřejmě že jsou v dluzích, automobilový průmysl není nejlevnější na vstup, stavba továren něco stojí a to že mají vysokou hrubou marži je jediný důvod proč Tesla vůbec ještě existuje, protože bez emise nových akcií by už dávno skončila v bankrotu, představa že jakmile začnou vyrábět sériovější auta bude ta marže nižší je taky mimo, vzhledem k tomu, že analytici předpovídají zhruba stejné hrubé marže i u high-volume Model 3.

Uvidíme.

Ke SpaceX se vyjadřovat nebudu, protože není k dispozici dostatek informací k analýze, ale hádám že vzhledem k tomu, že dosáhla nedávno valuace 21 mld. USD tak to asi taky nebude charita, a až jim bude jejich klíčová myšlenka o návratnosti prvního stupně raket fungovat bezchybně, tak to bude taky hezká dojná kráva.

V tomhle doporučuji si nastudovat, za kolik lítá konkurence a o kolik byla tesla levnější před znovupoužitelností (kterou reálně používá jen tenhle rok).

[Bystroushaak]

*tesla/spacex.

[Randy_Sh]

#414

Dobrá shoda

Moc nezměnilo? Reálně v ČR v podstatě nikdo netrpí hladem. Naopak se začíná řešit přežírání velké části populace jako zdravotní problém.

Jak říkám, na jednu stranu jsou potraviny výrazně levnější a dostupnější, ale na druhé straně jsme pořád dost daleko od toho, aby je stát rozdával zadarmo každému.

Kdyby to někdo chrlil v masové sérii formou vyměnitelných bloků, tak zadupe konkurenci do země během pár let.

Když nové auto stojí řádově stovky tisíc Kč, tak mi přijde logické, že kombajn bude stát desetkrát tolik, protože je větší a zdaleka se nevyrábí v takovém množství. A dost pochybuji, že by automobilky dokázaly srazit ceny, to už udělaly.

[Bystroushaak]

Když nové auto stojí řádově stovky tisíc Kč, tak mi přijde logické, že kombajn bude stát desetkrát tolik, protože je větší a zdaleka se nevyrábí v takovém množství. A dost pochybuji, že by automobilky dokázaly srazit ceny, to už udělaly.

U kombajnů je podstatně delší životnost. Znám lidi, co dodneška provozují 40+ let staré kombajny. Sice to nic nemění na pořizovací ceně, ale mění to cenu v přepočtu na den.

Další věc je ta opravitelnost, kde dnešní „moderní“ technika naprosto žalostně selhává za sovětskou, která se dala opravit kladivem a svářečkou. Přitom to není tak, že by se to nedalo vyrobit, jen to jde přímo proti zájmům „plánovaného zastarávání“ výrobce, který má z autorizovaných oprav prachy. A třeba zrovna ta kauza John Deere, který se soudí s lidmi, kteří si techniku doma opravují a vylepšují, je docela známá: A right to repair: why Nebraska farmers are taking on John Deere and Apple.

[xkucf03]

Reálně v ČR v podstatě nikdo netrpí hladem. Naopak se začíná řešit přežírání velké části populace jako zdravotní problém.

Trochu mimo téma, ale: pokud by lidé měli jíst kvalitní jídlo (aby třeba ve vyšším věku netrpěli zdravotními problémy), tak nebudou mít na to, aby se přežírali.

Momentálně to jde přesně opačným směrem, kde jsou čím dál míň opravitelný, každý výrobce používá custom součástky atd.. Kdyby to někdo chrlil v masové sérii formou vyměnitelných bloků, tak zadupe konkurenci do země během pár let.

Proto je obrovsky důležitý svobodný software a hardware. Jakákoli proprietární technologie je brzda pokroku a nelze ji považovat za vývoj. Pokud používáš cizí proprietární technologii, nemáš znalost, nedisponuješ danou technologií, nelze to považovat za pokrok – jsi pouze otrok, který obsluhuje nástroj, který mu někdo jiný propůjčil. Proto je takové zlo, když Microsoft nebo podobné firmy (s podporou státu) šíří svoje technologie do zemí třetího světa (nebo i k nám) a tváří se, jak jim pomáhají s rozvojem a poskytují jim technologii.

Matematik není ten, kdo umí obsluhovat kalkulačku, ale ten, kdo umí počítat sám s tužkou a papírem. Nemusí mít všechno v hlavě, klidně může sáhnout do knihovny pro knihu, kde najde řešení, ale jde o otevřenou veřejně přístupnou znalost. Pouze v takovém případě lze říct, že daná společnost disponuje danou technologií.

[Bystroushaak]

Trochu mimo téma, ale: pokud by lidé měli jíst kvalitní jídlo (aby třeba ve vyšším věku netrpěli zdravotními problémy), tak nebudou mít na to, aby se přežírali.

To je jedna věc. Druhá je, že se většinou ani tak moc přežírat nechceš. Nekvalitní jídlo má v sobě například kopec soli, což prostě pouští biologický reflex „žer dokud ti nebude blbě“. To samé s cukry a dnešním oblíbeným „glukózo-fruktózovým sirupem“, který je prakticky ve všem, protože ho lidi nemůžou přestat žrát, když už začnou. Trochu mi to připomíná Transmetropolitana, kde přidávali do novinového papíru kokain, aby se čtenáři stali závislými na čtení novin.

Proto je obrovsky důležitý svobodný software a hardware. Jakákoli proprietární technologie je brzda pokroku a nelze ji považovat za vývoj. Pokud používáš cizí proprietární technologii, nemáš znalost, nedisponuješ danou technologií, nelze to považovat za pokrok – jsi pouze otrok, který obsluhuje nástroj, který mu někdo jiný propůjčil. Proto je takové zlo, když Microsoft nebo podobné firmy (s podporou státu) šíří svoje technologie do zemí třetího světa (nebo i k nám) a tváří se, jak jim pomáhají s rozvojem a poskytují jim technologii.

Souhlasím plně.

[xkucf03]

Chlap s kombajnem (nebo třeba bagrem) sice udělá práci, kterou dříve dělaly desítky lidí, takže na platech se výrazně ušetří. Ale kombajn stojí miliony korun a to se do nákladů musí promítnout.

Místo toho, aby ten chlap dřel na poli, tak někde v továrně montuje kombajny. V součtu na té automatizaci celá společnost vydělá a i on se má líp.

Spíš než blouznění o základním příjmu by se lidi měli zamyslet, jestli má smysl pořád chodit do práce na osm hodin (někteří i víc) denně. Podle mého to smysl nemá (vzhledem k technologickému pokroku) a lidé by si měli vyjednat lepší podmínky, které jim dají dostatečný příjem při kratší pracovní době.

Tenhle přístup má to dvě zásadní výhody:

• místo, abys dostal (výhledově bezcenné) natištěné papírky, tak získáš volný čas, ve kterém můžeš tvořit něco pro sebe, pro ostatní nebo třeba jen odpočívat
• není k tomu potřeba žádný zásah státu, není potřeba nikoho okrádat, konfiskovat jeho bohatství nebo páchat podvody (znehodnotit lidem úspory, nezaplatit věřitelům)… stačí k tomu obyčejná dohoda na trhu (dohodnout se dá i kolektivně – můžeš si založit odbory, což je adekvátní protějšek k velkým korporacím)

Ve výsledku taky dojde ke změně v bohatství a příjmech (po čem zřejmě touží JS1), ovšem nejedná se o nějaké umělé násilné přerozdělení či podvod, ale o přirozený a férový vývoj.

[JS1]

Nezlob se, ale uz s tebou na tohle tema nebudu diskutovat. Podle meho nazoru zijes asi na nejake jine planete, nehlede k tomu, ze se opakujes.

Lide, co pracuji 12ky za minimalni mzdu si vyjednaji lepsi podminky, jako prirozeny vyvoj? A nikdo na tom pak nebude hur?

[xkucf03]

Kde píšu, že nikdo na tom nebude hůř? Píšu tam o změně rozložení bohatství a příjmů. Hůř na tom budou jejich zaměstnavatelé a jejich zákazníci, ale je to přirozený a legitimní¹ vývoj, zákon nabídky a poptávky. Pokud např. neseženeš dělníky, tak jim musíš dát víc a snížit si zisk nebo zvýšit cenu (nebo kombinaci obojího).

_{[1] na rozdíl od případu, kdy by jim ten majetek/příjem zkonfiskoval stát}

[JS1]

Ja ti nerozumim. Myslim, ze tem zamestnavatelum je jedno, jestli to zhorseni jejich situace zpusobi stat nebo trh. To jestli je to prirozene nebo ne je zbytecna filozoficka otazka, nad kterou mozna masturbuji v liberalnim institutu, ale pro normalni lidi nema prakticky vyznam.

[JS1]

Automatika je fajn, ale ZP resi spis jeji dusledek, coz je nerovnost mezi kapitalem a praci. Takova situace muze nastat (a taky v minulosti nastala) nezavisle na technologicke urovni. ZP ma smysl zavadet jako prostredek prave lepsiho vyuziti kapitalu v populaci.

[Bystroushaak]

ZP ma smysl zavadet jako prostredek prave lepsiho vyuziti kapitalu v populaci.

A je to lepší využití? Co definuje lepší a horší využití?

[JS1]

Lepsi vyuziti je ze treba lide nehladovi, zatimco se vedou nesmyslne valky. Definuje to nejaka spolecenska dohoda.

To same plati i u automatizace. Je jenom na spolecnosti, jestli se rozhodne, ze z vyhod automatizace bude tezit uzka skupina nebo cela spolecnost.

Pointa je, ze automatizace je jen specialni pripad obecneho problemu "socialni nerovnosti".

[Bystroushaak]

Lepsi vyuziti je ze treba lide nehladovi, zatimco se vedou nesmyslne valky. Definuje to nejaka spolecenska dohoda.

Ale je to fakt lepší využití? Určitě je lepší pro ty konkrétní lidi, ale je to lepší i z hlediska lidstva a civilizace?

[JS1]

Nerozumim tvoji otazce. Co je "hledisko lidstva"? Demokraticke hlasovani?

[Bystroushaak]

Vem si třeba takové války. Zcela určitě se jednalo o gigantické tragédie. Jenže na druhou stranu se jednalo o období technického pokroku, kterému v podstatě není rovno. Jsou tedy světové války špatně? Určitě jsou špatné z hlediska lidí, ale jsou špatné i z hlediska lidstva?

Pokud bys každému zajistil základní příjem bez jakékoliv snahy z jeho strany, jsi si fakt jistý, že by to mělo pozitivní vliv na civilizaci, nebo by to skončilo masivní celospolečenskou degenerací?

[JS1]

Ja valky nepovazuji za zdroj pokroku, a uz vubec ne za jediny mozny zdroj.

Japonsko po valce prodelalo ohromny technologicky rozvoj a valky k tomu nebyly potreba.

Samozrejme, to je jen muj nazor. Tim spis, zadne objektivni kriterium "jmenem civilizace" myslim neexistuje.

[Rezervní polská kotace]

Válka samozřejmě není zdrojem pokroku, ale může vyburcovat lidi a být motivaci k tomu technologickému pokroku. Oproti tomu základní příjem může mít přesně opačný efekt.

[JS1]

Oproti tomu základní příjem může mít přesně opačný efekt.

To nejak nevidim proc by to tak mohlo byt. Povede k mensimu pokroku, pokud lide daji penize treba do projektu na Kickstarteru, nez kdyz je vlada da do Manhattan projektu?

Ono je vlastne vubec i otazka, jestli lze treba vynalez atomove bomby povazovat za civilizacni pokrok.

[Bystroushaak]

To nejak nevidim proc by to tak mohlo byt. Povede k mensimu pokroku, pokud lide daji penize treba do projektu na Kickstarteru, nez kdyz je vlada da do Manhattan projektu?

Skoro určitě ano. Dřív bych si to asi nemyslel, ale poslední dobou mi přijde, že pokud do něčeho masivně zainvestuje vláda, tak to má lepší výsledky, než když do něčeho decentralizovaně investují lidé, mimo jiné taky proto, že vláda může změnit pravidla hry, která lidé musí obcházet.

Dobrý příklad je třeba investice do technologií po prvním sputniku, ze které časem vznikl nejenom internet, ale i interaktivní počítače. Rozvoj v té době byl naprosto bezprecedentní, nikoliv jen proto že se objevily nové technologie, ale především proto, že americká vláda zcela systematicky a cílevědomě nalila gigantické prachy do výzkumu a vzdělávání. To imho crowdsourcing emulovat nemůže.

Ono je vlastne vubec i otazka, jestli lze treba vynalez atomove bomby povazovat za civilizacni pokrok.

Vzhledem k tomu, že od to jednu světovou válku ukončilo a další odvrátilo, tak by se asi dalo opatrně konstatovat, že ano. To vynechám, že výzkum nebyl užit jen na výrobu atomové bomby, ale taky reaktorů, které se používaly k výrobě plutonia, což zase rozvinulo celé odvětví reaktorů na výrobu elektřiny, z čehož tak nějak všichni těžíme dodnes, ať si to připouštíme, nebo ne.

[JS1]

poslední dobou mi přijde, že pokud do něčeho masivně zainvestuje vláda, tak to má lepší výsledky, než když do něčeho decentralizovaně investují lidé, mimo jiné taky proto, že vláda může změnit pravidla hry, která lidé musí obcházet

Coz o to, tohle tvrzeni se jeste jakztakz da brat. Ale pokud to ta vlada utrati za zbrojeni?

výzkum nebyl užit jen na výrobu atomové bomby, ale taky reaktorů, které se používaly k výrobě plutonia, což zase rozvinulo celé odvětví reaktorů na výrobu elektřiny

Podle me by reaktory vznikly tak jako tak. Ostatne, stepnou reakci tusim popsal Leo Szilard (dokonce si podle Wikipedie nechal reaktor patentovat v roce 1933), ktery ani nebyl clenem Manhattan projektu, protoze ho podezirali, ze je Zid a komunista.

[xkucf03]

Ale pokud to ta vlada utrati za zbrojeni?

Takže ve státě se ZP se nebude zbrojit. Je hezké, jak spojuješ věci dohromady, přitom to spolu vůbec nesouvisí – pak se snadno stane, že zaměníš příčiny nějakých pozitivních efektů a přisoudíš je něčemu jinému.

Co třeba stát, který (tolik[protože úplně přestat investovat do obrany nejde, takový stát by moc dlouho neexistoval]) nezbrojí a zároveň nemá ZP? Soukromému sektoru tam zůstane víc peněz a můžou je investovat sami.

Proč si myslíš, že někdo, kdo dostal peníze za nic (ZP) by měl být více kompetentní k investování než ten, kdo ty peníze sám vydělal?

[JS1]

Takže ve státě se ZP se nebude zbrojit.

Nic takoveho jsem nenapsal. Jenom se treba nebudou vest zbytecne valky, vyrabet jaderne zbrane, atp.

Proč si myslíš, že někdo, kdo dostal peníze za nic (ZP) by měl být více kompetentní k investování než ten, kdo ty peníze sám vydělal?

Tutez otazku si muzes klast uz dnes - jak je nekdo, kdo si treba kupuje auto, kompetentni rozhodovat, jaka auta mame vyrabet? Odpoved je, ze neni - od toho si plati inzenyry, kteri ta auta navrhuji, a rozhoduji o tom, jak budou jeho penize dal investovat.

Ale jinak je to stejna otazka, jakou nekteri kladou v demokracii - proc by meli byt lide v demokracii vsichni stejne kompetentni o necem rozhodovat? Odpoved je, ze to neni o kompetenci, ale o zastoupeni zajmu. V demokracii slouzi rovny hlas tomu, aby lide byli stejne zastoupeni politicky - lidmi kompetentnimi. Stejne tak, v systemu se ZP slouzi ZP k tomu, aby lide byli (do urcite miry) stejne zastoupeni ekonomicky, zase s tim, ze konkretni beh ekonomiky se preda lidem kompetentnim.

[ehm]

poslední dobou mi přijde, že pokud do něčeho masivně zainvestuje vláda, tak to má lepší výsledky, než když do něčeho decentralizovaně investují lidé

OpenCard, Blanka, Centrální registr vozidel, Tojecool.cz, ...

[Käyttäjä 11133]

OpenCard, Blanka, Centrální registr vozidel, Tojecool.cz, ...

Neřekl Česká vláda

[Bystroushaak]

OpenCard, Blanka, Centrální registr vozidel, Tojecool.cz, ...

Budu pokračovat v #892 dole, protože už mě nebaví být takhle nalepený doprava, což se skoro nedá číst ani s tím custom CSS stylem, který ty příspěvky rozšiřuje.

[ehm]

Asi by to chtělo horizontální scrollbar.

[ehm]

BTW: Největší peklo je číst tyhle diskuze na mobilu.

[Bystroushaak]

Spíš by to chtělo, aby to tyhle vnořená vlákna samo do určité míry narovnávalo. Například po 20 zanoření je prostě odhodit jako samostatné vlákno. Já mám doma 27" monitor, takže tam se to čte v pohodě, ale v práci na 24" už to narazilo na meze čtení i s tím custom CSS, které nastavuje minimální šířku.

[Käyttäjä 11133]

O něčem takovém by se dalo uvažovat za Argonitu, nový vlastník ABCLinuxu má k portálu poměrně laxní přístup...

[ehm]

Mně se to zatím čte docela dobře i na 22,5".

[xkucf03]

Příloha:

• Screenshot_20170806_164544.png (272525 bytů)

Ono je to víc o poměru stran resp. šířce v bodech než o palcích. Nedávno jsem si pořídil širokoúhlý monitor a tam se to čte v pohodě. Ale na mobilu se to nedá, tam je na každém řádku jedno slovo – komentář ještě přečíst jde, ale už z toho nevidíš, kdo na koho reaguje.

[Bystroushaak]

Japonsko po valce prodelalo ohromny technologicky rozvoj a valky k tomu nebyly potreba.

Válka imho mohla za Japonský pokrok (resp. snahu se pozvednout) a naprostou a brutální změnu mentality a přístupu k technologiím.

[Fluttershy, yay!]

Japonsko v prvé řadě prodělalo enormní posun od feudalismu a industrializaci po ukončení izolacionismu.

[JS1]

Pokud to beres takhle, tak pak valka mohla za ledacos.

Me spis jde o to, ze Japonsko je prikladem, ze lze mit technologicky pokrok i bez valky. Samozrejme, vzdycky se najdou alfa-idioti, kterym to vadi. Chces byt taky jeden z nich?

[Bystroushaak]

Samozrejme, vzdycky se najdou alfa-idioti, kterym to vadi. Chces byt taky jeden z nich?

Lol, hezká sloučená otázka. A už jsi přestal bít svojí ženu?!

Me spis jde o to, ze Japonsko je prikladem, ze lze mit technologicky pokrok i bez valky.

Já nechtěl tvrdit, že technologický pokrok potřebuje válku, jen že válka takový pokrok masivně urychlí.

[JS1]

Lol, hezká sloučená otázka.

Nic s nicim neslucuji. Jen chci, aby sis dobre rozmyslel, jestli chces patrit mezi lidi (a ze jich je pekna radka), kteri se historicky ztrapnili tvrzenimi jako ze treba valky jsou nevyhnutelne. Jestli to tak citis nebo ne (tedy odpoved na tu otazku) je mi ukradene - pokud to tak necitis, tak sis to uz rozmyslel a ja budu spokojeny.

Vubec mi tak pripada, ze jsi trochu vztahovacny. Viz nase diskuse jinde v tomto foru.

jen že válka takový pokrok masivně urychlí

Ano, s tim prave nesouhlasim. Urychli to mozna v pripade, kdy te spolecnosti vladnou alfa-blbci, kteri tu valku chteji, a v podstate je to vsechno, co je tak zajima. Ale vlada alfa-blbcu neni nevyhnutelna, jen az zbytecne casta.

[JS1]

Urychli to mozna v pripade

A i to je diskutabilni. Paradoxne, ten nejvetsi alfa-blbec ze vsech, Hitler, nebyl schopen jadernou zbran vyvinout.. A jeho blizky konkurent, Stalin, ji zase musel ukrast, protoze rusti fyzici se v praci na ni zrovna nepretrhli.

[Bystroushaak]

A i to je diskutabilni. Paradoxne, ten nejvetsi alfa-blbec ze vsech, Hitler, nebyl schopen jadernou zbran vyvinout.

To čistě jen proto, že to nestihl. Na začátku v tom měl paradoxně náskok, proto taky Einstein psal Rooseveltovi, aby začal vývoj, na základě čehož začal projekt Manhattan. Na tom se podílely stovky vědců z celého světa. Hitler si oproti tomu musel vystačit s podstatně menší skupinou a imho tomu nikdy nedal takovou prioritu, kterou dali ze strachu Američani.

BTW: Dost dobrý seriál na téma kde Hitler vyhraje právě použitím atomových zbraní je The Man in the High Castle, kdyby ses nudil, tak můžu doporučit.

[JS1]

To čistě jen proto, že to nestihl.

On to hlavne stihnout ani nechtel - jak pises, nedal tomu velkou prioritu. Byl to proste, nastesti, idiot.

[Bystroushaak]

On to hlavne stihnout ani nechtel - jak pises, nedal tomu velkou prioritu. Byl to proste, nastesti, idiot.

Nepřijde mi, že by byl idiot. Je dobré to vnímat v kontextu doby, kdy vedl válku na dvou frontách a Německo v tu dobu mělo jiné problémy, než aby si mohlo dovolit dát podstatnou část svého HDP na jeden super tajný projekt, o kterém parta vědců tvrdí, že možná bude revoluce.

[Bystroushaak]

Nic s nicim neslucuji. Jen chci, aby sis dobre rozmyslel, jestli chces patrit mezi lidi (a ze jich je pekna radka), kteri se historicky ztrapnili tvrzenimi jako ze treba valky jsou nevyhnutelne.

Počkat, jak se tím mohli historicky ztrapnit, když nikdo empiricky nedokázal opak? Naopak od začátku psané historie lidstva asi ani neexistoval rok, kdy by se někde neválčilo.

Ano, s tim prave nesouhlasim. Urychli to mozna v pripade, kdy te spolecnosti vladnou alfa-blbci, kteri tu valku chteji, a v podstate je to vsechno, co je tak zajima.

Společnosti imho skoro nikdy nevládnou alfa-blbci. Nebo možná spíš jen špatně chápu definici toho termínu. Alfa blbci jsou podle mě spíš v armádě a po válce volají, ale společnosti vládnou jen málokdy.

Principu urychlení imho vychází z něčeho úplně jiného, specificky z červené královny, která tě prostě nutí vyvíjet se, protože jinak prohraješ. Tenhle princi platí i obecně, běžně však na rozdíl od války není doslova evolučním tlakem, kde ten kdo ustrne skutečně fyzicky umře.

[JS1]

Počkat, jak se tím mohli historicky ztrapnit, když nikdo empiricky nedokázal opak?

Jeden empiricky dukaz mas v tom videu.. Jinak posledni dobou se nevalci dost, a mnoha lidem to, mozna te to prekvapi, ani nechybi. Alfa-blbcum ale asi jo.

Principu urychlení imho vychází z něčeho úplně jiného, specificky z červené královny, která tě prostě nutí vyvíjet se, protože jinak prohraješ.

Ale kecy, Americany nic nenutilo snazit se "uzbrojit" Rusy, to byla jen propaganda vojensko-prumysloveho komplexu, samozrejme zivena strachem z "komunismu" (jako by o nej nekdo stal).

[Bystroushaak]

Jinak posledni dobou se nevalci dost, a mnoha lidem to, mozna te to prekvapi, ani nechybi. Alfa-blbcum ale asi jo.

Však probíhají minimálně dvě války.

Ale kecy, Americany nic nenutilo snazit se "uzbrojit" Rusy, to byla jen propaganda vojensko-prumysloveho komplexu, samozrejme zivena strachem z "komunismu" (jako by o nej nekdo stal).

Tím jsem nenarážel na studenou válku, ale na války obecně. Když se ve válce zastavíš, tak končíš.

[Bystroushaak]

Jeden empiricky dukaz mas v tom videu..

Myslíš v tom videu o tlupě opic? To mi přijde docela nedostatečné jako argument o sedmi miliardách lidí s pokročilou ekonomikou a politikou, resp. je to takové zjednodušení, že to nedokazuje o vůbec nic.

[xkucf03]

Že se o některé věci začne starat automatika. Například automatická loď na lov ryb a automatická past na lov prasat. Tím se z toho stanou v podstatě obecní zdroje, jako je třeba studna, o které se všichni můžou dělit a tím mít jejich „základní příjem“.

Tahle úvaha ignoruje vývoj, minulost a budoucnost. Tu loď, past nebo studnu musel někdo vymyslet, vyrobit a musí ji udržovat. Časem se situace změní, třeba ti dojdou prasata/ryby, na které tvůj automatický aparát funguje a bude potřeba vyvinout něco nového. Tzn. ten „bezpracný zdroj“ nepřišel odnikud, nespadl z nebe a nebude fungovat věčně.

Ono to vypadá lákavě vzít hodnoty, které vznikly v kapitalismu, ty prohlásit za „obecní zdroj“ a rozdat je… jenže to má jednu vadu: bude to fungovat jen jednu iteraci.

[xkucf03]

Ty jsi vážně komik. Možná bys s tím mohl někde vystupovat a lidi by se tomu smáli.

Uz ti to rikam asi podesate - je rozdil mezi makro- a mikro- ekonomii. Stat se zadluzit nemuze, ale lide ano.

Stát se samozřejmě zadlužit může a běžně se tak (bohužel) děje.

Protoze stat jako celek nemuze (z fyzikalnich duvodu) spotrebovavat neco, co jeste nebylo vyrobeno, tedy zit na dluh.

Stát si může půjčit v zahraničí a pak skutečně spotřebuje víc, než kolik v daném období vyrobil – tzn. žije si na dluh, nad poměry. Navíc majitel dluhopisu se může v čase měnit.

I kdyby všichni věřitelé byli jen z daného státu a žádný dluh vůči zahraničí neexistoval, tak to pořád neznamená, že je to v pohodě.

Znamená to, že stát¹ spotřeboval či přerozdělil víc, než kolik získal na daních. A snadno se může dostat do situace, kdy bude dlužit tolik, že to nebude schopný splácet – a před tím se ještě dostane do fáze, kdy ho dluh paralyzuje a stát nebude pořádně a efektivně plnit svoji funkci, protože příliš velkou část peněz bude muset vydat na splátky dluhu.

Při méně formálním pohledu se na to můžeme dívat tak, že část lidí ve státě si žila nad poměry a část lidí jim na to půjčila – a samozřejmě budou chtít svoje peníze zpět.

Tahle situace nemá žádné dobré řešení. Můžou nastat jen různé špatné konce:

• bude to dlouhodobě drhnout, stát bude splácet, ale bude neefektivní – nakonec to dopadne jednou z variant níže, ale k tomu je ještě potřeba připočíst ztráty, které se nasčítaly během tohoto období paralýzy státu
• stát si natiskne peníze a rozpustí dluh v inflaci – znehodnotí všem úspory a poškodí věřitele
• stát udělá měnovou reformu, úspory do určitého limitu převede na novou měnu, ale kdo bude mít nad limit, ten dostane nevýhodný kurz nebo vůbec nic – spousta lidí bude okradena
• stát prodá svůj majetek
• stát bude obsazen zahraničními věřiteli s podporou některých mezinárodních organizací – stát přijde o suverenitu, majetek, moc nad daným územím… bude dosazena loutková vláda nebo vznikne nějaký protektorát
• dojde k převratu či revoluci a nová vláda odmítne platit dluhy minulého režimu, věřitelé přijdou o svoje investice

Samozřejmě se na to můžeš dívat i tak, že věřitelé jsou hlupáci, když na tuhle pyramidovou hru naletěli, a je v pořádku, když přijdou o peníze. Svým způsobem je to správný pohled. Ale to můžu říct, já, jako člověk, který si nepůjčuje a ani nekupuje státní dluhopisy. Ale jak to vysvětlí socialistický politik (nebo třeba ty), který je na půjčkách závislý? Když si totiž tuhle pravdu veřejně přiznáme, tak nikdo státu nebude chtít půjčovat – resp. bude půjčovat maximálně² do doby, dokud jsou ty dluhy splatitelné, což už ale nejsou a spousta států se z té dluhové pasti nemá šanci dostat – tedy leda jednou z těch variant výše, což ale poškodí věřitele, tudíž nedává smysl státu peníze půjčovat.

Věřitel může taky hrát na to, že až to praskne, dostane se k moci nebo si ukousne část ze státního majetku. Takhle to klidně může být – ale o to horší je, že politici takhle hazardují s naší suverenitou a společným majetkem. Hrají na to, že se zadarmo nažerou a pak udělají hyperinflaci a věřitele pošlou do háje? Jenže ono to tak vůbec vyjít nemusí a může nastat některý z těch horších konců. Nebo to jsou přímo zrádci, kteří mají připravit půdu pro převzetí moci a majetku někým jiným? Tak jako tak je to hazard a krajně nemorální jednání. Buď chceš poškodit občany nebo věřitele – jak jsem psal: dobrý konec tohle nemá.

_{[1] ve smyslu „státní aparát“
[2] to se může cyklicky opakovat – může fungovat ten keynesiánský model, kdy si v horších časech půjčíš a v lepších to splatíš – i když to nepovažuji za dobrý nápad, tak by to teoreticky dlouhodobě udržitelné bylo – ovšem politici ty dluhy nesplácejí, nedochází k vyrovnání a dluh se pouze zvyšuje}

[JS1]

Na tohle vsechno uz jsem v diskusich s tebou odpovidal. Takze skocim rovnou na konec - ja nechci, aby nekdo nekomu pujcoval na spotrebu. Pokud tedy veritele nebudou chtit statu pujcit z obavy, ze to utrati na spotrebu, bude to z meho pohledu naprosto legitimni situace. Staci?

[xkucf03]

Tvrdil jsi, že dluh údajně není problém a že nejde žít nad poměry. Když jsem ti dokázal, že to není pravda, tak odbíháš od tématu.

Pokud tedy veritele nebudou chtit statu pujcit z obavy, ze to utrati na spotrebu, bude to z meho pohledu naprosto legitimni situace. Staci?

A jak má věřitel poznat, jestli to bude na spotřebu nebo investice? Když stát ty peníze rozdá jako ZP, tak je to co? Část lidí ty peníze určitě prožere. Část je možná investuje.

Stále jsi nevysvětlil, z čeho chceš ten ZP financovat – v zásadě máš jen dvě možnosti:

• zadlužit se
• zvýšit daně

Nebo tě napadá jiná možnost? Když si budeš půjčovat, tak je to ten hazard a nemorální jednání, o kterém píšu výše. Případně ti nikdo nepůjčí, protože ví, že bys to akorát prožral. Když zvýšíš daně, tak ti podnikatelé utečou do zahraničí, kde takhle hloupé nápady nemají, nebo ukončí činnost a budou žít ze ZP nebo ti poroste černá a šedá ekonomika (tzn. stát vybere méně daní a ještě bude mít vyšší výdaje na boj se zločinem + negativní dopady existence mafiánů na běžné občany – něco jako veksláci a s nimi související kriminalita za minulého režimu).

Někteří v téhle diskusi jsou alespoň trochu konstruktivní a odvolávají se na jakýsi skokový nárůst automatizace a technologickou revoluci. I když i to mi přijde celkem jako utopie… Ale u tebe žádně nevím, z čeho bys ten ZP chtěl alespoň teoreticky financovat.

[JS1]

Tvrdil jsi, že dluh údajně není problém a že nejde žít nad poměry. Když jsem ti dokázal, že to není pravda, tak odbíháš od tématu.

Neodbiham, jen si myslim, ze pokud chapes, co pisu, tak je ti i jasne, jak to myslim - totiz ze ekonomika jako celek nemuze "zit nad pomery". Samozrejme, muze si pujcit ze zahranici, ale to neni to, co jsem mel na mysli, protoze pak uz to neni ekonomika jako celek. (Taky si muze zit nad pomery tak, ze treba pali uhli, ale zase, je jasne, ze to jsem na mysli zrovna nemel.)

Jinak receno, kdyz Necas a spol. v roce 2012 poukazovali na to, ze si zijeme nad pomery, meli take ukazat, ktery blbec nam na to ze zahranici pujcil. Ale to jaksi neslo, protoze zadne "ziti si nad pomery" se nekonalo.

A jak má věřitel poznat, jestli to bude na spotřebu nebo investice?

Nikde neni psane, ze to poznat musi, a ze musi pujcit. Kdyz nepozna tak nepujci, holt.

Uz to opakuji asi podesate - nevidim velky ekonomicky problem v nedostatku penez (pokud si ho nezpusobis umele, treba zavedenim zlateho standardu). Ekonomicky problem vidim bud v nedostatku poptavky (lepe receno nemoznosti tu poptavku vyjadrit diky nedostatecnym prijmum) nebo nizke produktivite (ze na neco chybi know-how).

Když zvýšíš daně, tak ti podnikatelé utečou do zahraničí

At utecou. Ja si myslim, ze se to nestane, duvody uz jsem naznacil driv (ze vyse dani podnikatele objektivne netrapi) a ani empiricky se to tak nejevi. Ono se najde dost tech, kteri treba zacnou diky ZP take podnikat.

Samozrejme, idealni by bylo, kdyby vsichni meli prijmy vyssi nez ZP. Pak by prerozdeleni bylo nulove.

[Bystroushaak]

Jsem zrovna nedávno koukal, jak je to s hypotékami a docela mě zarazilo, že si ani nemůžu dovolit si hypotéku vzít, přestože moje měsíční příjmy jsou 50k+ a mám něco naspořeno. Čím víc se nad tím zamýšlím, tak asi jediným řešením bude vypadnout z Prahy, protože tady se z toho stává hrozný krysí závod a ty ceny a podmínky lezou do stropu nechutnou rychlostí.

[pavlix]

Tak jestli máš příjmy 50k na živnost a výdaje uvádíš paušálem 60 %, tak jsi formálně vzato hluboko pod průměrnou mzdou a nemůžeš si u bank moc vyskakovat.

[Bystroushaak]

Tak jestli máš příjmy 50k na živnost a výdaje uvádíš paušálem 60 %, tak jsi formálně vzato hluboko pod průměrnou mzdou a nemůžeš si u bank moc vyskakovat.

To byl čistý zisk.

[pavlix]

Tak to už bys měl na hypotéku dosáhnout, pokud máš odpovídající hotovost na zaplacení části ceny. Na čem to ztroskotává?

[Bystroushaak]

Na tý hotovosti, to se docela posrali s tím kolik toho chtěj.

[Käyttäjä 11133]

Na tý hotovosti, to se docela posrali s tím kolik toho chtěj.

Problém je v tom že na realitním trhu je taková menší bublina a proto banky nabízejí LTV 80%, protože až ta bublina splaskne tak hodnoty nemovitostí klidně můžou i o těch 20% klesnout a banka by tak v případě zesplatnění hypotéky skončila ve ztrátě... Prostě počkej až ta bublina splaskne a pak nakupuj nemovitosti... Do té doby můžeš budovat vlastní kapitál, aby si měl za co nakupovat.

[Bystroushaak]

Jo, k tomu jsem taky dospěl. Osobně mě to netlačí, takže je mi to v podstatě jedno, ale dokážu si představit, že spoustě lidí to může dost kazit život. Osobně to asi nakonec vyřeším prostě tím, že z prahy vypadnu a budu pracovat z domova, protože se mi fakt nechce účastnit se tohohle krysího závodu o co nejdražší byt. Ale ještě uvidím, jak se to vyvine s přítelkyní a tak.

[JS1]

Prostě počkej až ta bublina splaskne a pak nakupuj nemovitosti...

To je hezka rada, ovsem jak pravi znamy citat: "Housing bubbles can remain longer than you can remain fertile."

[Käyttäjä 11133]

See #957 for alternative aproach...

Což je ještě navíc posíleno tím, že ČNB tu bublinu ještě natahuje svými obranými opatřeními.

[Käyttäjä 11133]

Jinak to co ti chybí můžeš vykrýt překlenovacím úvěrem u stavební spořitelny... Založíš si stavebko s cílovou částkou 1M CZK, 500k vložíš z toho co máš naspořeno, 500k CZK si půjčíš a najednou máš 20% (1M) na byt za 5M CZK.

[xkucf03]

Opravdu to takhle jednoduše funguje? Banka přece pozná, že dlužíš jinde, ne? Navíc ty splátky budou asi stavěné tak, abys je zvládal splácet samotné – ale platit dvě takové splátky najednou už může být moc. Tzn. obejitím pravidel se můžeš dostat do dost „nepohodlné“ situace.

[JS1]

Rasismus v tehle diskusi jeste chybel, dik.

[Jendа]

Já v tom discrimination and prejudice towards people based on their race or ethnicity nevidím. Naopak, Randy explicitně použil ekonomický indikátor. Rasismu se dopouští ten, kdo v tom automaticky vidí nějakou rasu.

[Fluttershy, yay!]

Je zřejmé, které etnikum tím myslel.

Mimochodem je pozoruhodné, kolik uživatelů tady přispívá pouze svou politickou agendou (namátkou Randy, JiK, M-train).

[Jendа]

Je zřejmé, které etnikum tím myslel.

Mně není zřejmé, že tím myslel vůbec nějaké etnikum. Ještě jednou: psal pouze o ekonomických ukazatelích.

[Fluttershy, yay!]

Vážně?

Jistá "diskriminovaná" skupina obyvatel ČR

Nebo tím myslel, co já vím, důchodce nebo ženy? Asi ne.

[pavlix]

Vidím primárně dvě skupiny lidí: jednak ty, kteří ve své práci nevidí žádný smysl (tj. pročistil by se systém), a jednak de facto námezdní otroky, kteří mají minimální ekonomickou svobodu (jsme chudí) a jsou mj. kvůli automatizaci nebo outsourcingu stejně riziková skupina, co se týče nezaměstnanosti…

Právě jsi shrnul většinu obyvatelstva, ze které dohromady teče do rozpočtu docela dost peněz.

[Fluttershy, yay!]

Jedna otázka zní, nakolik práce lidí, kteří v ní smysl nevidí, skutečně přináší něco nového do systému. (hint: např. státní úředník)

Ta druhá je, zda by měl rozpočet záviset na zdanění otroků – a pokud tito přicházejí o práci, zda by se nemělo restrukturalizovat zdanění.

[xkucf03]

Jedna otázka zní, nakolik práce lidí, kteří v ní smysl nevidí, skutečně přináší něco nového do systému.

Jestli v tom vidí smysl konkrétní pracovník je z hlediska přínosu pro společnost poměrně jedno – představ si, že někdo třeba montuje dohromady nějaké součástky nebo nosí něco odněkud někam, nebo dělá něco na počítači… smysl v tom nevidí a dělá to jen, aby dostal plat – ale ve skutečnosti je ta jeho práce přínosná a je součástí nějakého většího celku, který dělá něco úžasného pro ostatní lidi.

(hint: např. státní úředník)

Zajímavé. Státní úředníci pracují na základě zákonů, vyhlášek a příkazů od svých šéfů. A tyhle věci mají na svědomí většinou socialisti/levičáci spíš než příznivci minimálního státu (ti by zrušili podstatnou část regulací, zákonů, vyhlášek a zjednodušili by systém).

[xkucf03]

Vidím primárně dvě skupiny lidí: jednak ty, kteří ve své práci nevidí žádný smysl

Jak píšu jinde: to, že konkrétní zaměstnanec nevidí ve své práci smysl a dělá ji jen pro peníze, rozhodně neznamená, že ta práce nemá smysl pro ostatní a není přínosná.

Na opodstatněně nepopulárních pozicích.

Tady hrozí, že se to někdo pokusí „řešit“ dovozem migrantů. Což následně způsobí ještě horší problémy. Původní obyvatel by nepracoval a žil ze ZP, migrant by se dočasně spokojil s almužnou, ale za chvíli by taky požadoval ZP nebo zvýšení platu, což by vedlo k dovozu nových migranů a počet nepracujících by pořád rostl – s tím by klesala efektivita systému a rostla nespravedlnost spočívající v tom, že pracující dotují ty, kteří pracovat nechtějí.

Pokud je řeč o těch, kteří už teď žijí na deseti tisících (což je hluboko pod living wage u nás), kdyby měli jistotu příjmu, zřejmě by se chovali racionálněji. Tzn. mj. by se nezvyšovalo jejich zadlužení (což je skutečný problém).

To je hodně naivní představa. Spousta dlužníků to má v hlavě tak, že kdybys jim dal peníze (nebo splatil jejich dluhy), za chvíli se zadluží znovu a jsou opět ve stejné situaci. Když to budeš dělat každý měsíc, tak ničemu nepomůžeš, těch deset tisíc budou brát jako příjemný bonus, ale nijak je to nemotivuje se dále nezadlužovat.

Je to podobné, jako když si někdo pořídí kreditku a každý měsíc jde do mínusu. Ve skutečnosti je na tom pořád stejně (blbě), akorát k tomu navíc platí ještě úroky. Jediné, co tím získal je ten jeden měsíc na začátku, kdy měl celkem pohodu a mohl utratit peníze, které nemá, ale v dalších měsících už to nemá žádný vliv, protože ta prvotní finanční injekce se už neopakuje (a naopak musí platit navíc ty úroky).

Práce není ctnost.

Není. Po nikom nechci, aby do ní chodil a nepohoršují mne lidi, kteří nepracují (když na to mají). Ale taky nechci, aby mě stát nutil pracovat na někoho jiného a dávat mu svoje peníze. Můžu přispívat lidem, kteří měli smůlu a pracovat nemohou, a brát to jako pojištění (mohlo by se to stát i mně), ale není důvod proč bych měl přispívat obecně komukoli.

Nicméně obecně k otázce ZP – jak jsi asi pochopil, nejsem této myšlence příliš nakloněn, ale i kdybych někdy v budoucnu změnil názor, nechci rozjímání nad ZP věnovat příliš mnoho času, protože v současné době je tato otázka bezpředmětná. Důvod je ten, že současní politici nejsou schopni udržet vyrovnaný státní rozpočet a trvale nás zadlužují a tudíž ZP by byl opět na dluh. Pokud budou veřejné finance dostatečně zdravé a bude řadu let po sobě vyrovnaný rozpočet, tak můžeme otázku ZP opět otevřít. Jinak je to nemorální zlo, protože politici buď a) okrádají budoucí generace tím, že je zadlužují, nebo b) páchají úvěrový podvod a okrádají věřitele, protože ty dluhy se nikdy nesplatí.

[Fluttershy, yay!]

Jak píšu jinde: to, že konkrétní zaměstnanec nevidí ve své práci smysl a dělá ji jen pro peníze, rozhodně neznamená, že ta práce nemá smysl pro ostatní a není přínosná.

Což implikuje selhání [zaměstnavatele] v poskytování informací.

Neměly by být subjekty na fungujícím trhu co nejlépe informované, aby se co nejlépe rozhodovaly?

Na opodstatněně nepopulárních pozicích.

Tady hrozí, že se to někdo pokusí „řešit“ dovozem migrantů.

„Hrozí.“ Když jdu kolem stavby, česky se tam nemluví – nebo mluví, ale s přízvukem. Jinde totéž.

To je hodně naivní představa. [kecy]

Ano, já vím, že máš představu, že chudí lidé jsou hloupí, za všechno si můžou sami a vůbec. Jenom mi není jasné, jak potom chceš, aby se tedy rekvalifikovali.

Co třeba (jak překvapivé) získat nějakou kvalifikaci?

[xkucf03]

Což implikuje selhání [zaměstnavatele] v poskytování informací.

Proč by mělo jít o selhání? Ten člověk má dostatek informací k tomu, aby vykonával dobře zadané úkoly a byl pro zaměstnavatele užitečný. A má i dostatek informací k tomu, aby se dokázal sám rozhodovat, zda tu práci vzít nebo ne – ví, kolik tam bude trávit času, jak pracné/náročné to pro něj bude a kolik dostane peněz.

Že mu uchází celkový smysl něčeho většího, v zásadě ničemu nevadí. Jistě, bylo by fajn, kdyby věděl, jaké to má celé smysl, ale není to nezbytné – pokud na to nemá kapacitu nebo to nechce vědět, bude to fungovat i tak. (neplatí to u každé práce, ale tam, kde záleží na znalosti celkového kontextu, se o to zaměstnavatel ve vlastním zájmu postará)

„Hrozí.“ Když jdu kolem stavby, česky se tam nemluví – nebo mluví, ale s přízvukem. Jinde totéž.

To je dané jednak tím, že zaměstnance z těchto pozic odčerpal přebujelý státní aparát a ti lidé teď sedí na úřadech, místo aby dělali něco užitečnějšího, a na druhé straně jiné lidi demotivuje sociální systém, aby šli pracovat. K tomu si připočti lidi, které stát svými buzeracemi demotivuje podnikat a jsme tam, kde jsme.

Např. teď zrovna potřebuji opravit nějakou věc a budu čekat tak nejméně měsíc, protože jediný člověk široko daleko, co to dělá, má plno. Ostatní dělají nějaké zbytečné práce nebo jsou na podpoře, místo aby dělali něco užitečného.

Kdyby ty lidi někdo vykopal ze sociálek, úřadů a zbytečných firem přisátých na stát, tak by se ve vlastním zájmu rekvalifikovali a šli dělat něco, co ostatní reálně potřebují.

[Fluttershy, yay!]

Že mu uchází celkový smysl něčeho většího, v zásadě ničemu nevadí. Jistě, bylo by fajn, kdyby věděl, jaké to má celé smysl, ale není to nezbytné – pokud na to nemá kapacitu nebo to nechce vědět, bude to fungovat i tak.

Kdyby ty lidi někdo vykopal ze sociálek, úřadů a zbytečných firem přisátých na stát, tak by se ve vlastním zájmu rekvalifikovali a šli dělat něco, co ostatní reálně potřebují.

To je spor.

[xkucf03]

Proboha proč?

Pokud dělník chodí do práce na osm hodin, má spoustu volného času a vydělá si dost peněz na živobytí, tak proč by měl pátrat po tom, jaký má jeho práce širší smysl? Mě by to třeba zajímalo, ale někoho vůbec, odpracuje si to svoje, dostane peníze a je spokojený. Nevidím v tom problém.

Totéž u těch úředníků a nezaměstnaných – oni taky nemusí pátrat v tom, jaký to má smysl, nebo jestli je to správné – svoje peníze dostanou a jsou spokojení. Důvod k nespokojenosti má leda ten, kdo jim to platí – a ten klidně celkový smysl znát může a vědět, jak to funguje, ale není mu to nic platné, protože stát ho většinou donutí ty peníze vydat.

Naopak, když někdo nebude mít práci, tak bude ve vlastním zájmu pátrat, co by mohl dělat jiného, co by se mohl naučit, aby to mělo smysl, resp. aby to bylo užitečné pro ostatní.

[Fluttershy, yay!]

Protože je to pro řadu lidí důležité. Je to jedna z komponent motivace.

[xkucf03]

Ale vždyť jim nikdo nebrání pochopit, jaký to má smysl, a proč jim někdo za jejich práci platí. Jen říkám, že to často není nezbytně nutné a pokud někdo tu potřebu nemá, nevidím v tom problém.

[Fluttershy, yay!]

V dalším odstavci jsi vyjmenoval pozice, na kterých ta práce [podle tebe] smysl nemá.

[xkucf03]

No a? Nemá smysl, ale to jim nebrání být spokojený a takovou práci (nebo ne-práci) vykonávat. Pro ně to není problém – problém je, že jim někdo tu práci zadává a někdo to musí platit.

[Heron]

Naopak, když někdo nebude mít práci, tak bude ve vlastním zájmu pátrat, co by mohl dělat jiného, co by se mohl naučit, aby to mělo smysl, resp. aby to bylo užitečné pro ostatní.

Jak psal Králík, tohle je naivní myšlenka. Jak to dopadá vidíme i dnes. Někteří lidé* pracují jen pro peníze a vezmou i práci, která někomu škodí. Nepřemýšlí nad tím, protože jsou 5 tis. Kč před exekucí. Možná nad tím přemýšlí a štve je to, ale nemůžou s tím nic udělat. Roste frustrace apod.

Po zavedení ZP by tito lidé mohli z té nenáviděné práce odejít (a už tím být přínosem pro společnost) a mohli by mít čas najít něco, co by je bavilo a čím by byli skutečně prospěšní.

*) Jako upřímně řečeno, nám se to z 90. percentilu dobře kecá, ale jsou lidé, kteří jsou jednou nohou pod mostem a druhou v kriminále. V naší rozvojové zemi s kultem práce a s odměnami typu za stejnou práci jako na západě akorát za 1/3 mzdu, je hromada lidí skutečně v situaci, kdy si reálně nemohou nic vybírat a prostě přijmou cokoliv. A na tyto lidi čekají podvodníci, kteří je oškubou na kost a zneužijí k dalších činnostem, které pro společnost nic nepřináší.

[Randy_Sh]

Jak psal Králík, tohle je naivní myšlenka. Jak to dopadá vidíme i dnes. Někteří lidé* pracují jen pro peníze a vezmou i práci, která někomu škodí. Nepřemýšlí nad tím, protože jsou 5 tis. Kč před exekucí. Možná nad tím přemýšlí a štve je to, ale nemůžou s tím nic udělat. Roste frustrace apod.

Po zavedení ZP by tito lidé mohli z té nenáviděné práce odejít (a už tím být přínosem pro společnost) a mohli by mít čas najít něco, co by je bavilo a čím by byli skutečně prospěšní.

Znám několik lidí, u nichž nepochybuji, že kdyby nějaký dobrodinec zaplatil všechny jejich dluhy a ještě jim dal ZP ve výši 30 kKč měsíčně, tak by časem skončili ve stejném srabu, jako jsou teď.

[kralyk z abclinuxu]

Znám několik lidí, u nichž nepochybuji, že kdyby nějaký dobrodinec zaplatil všechny jejich dluhy a ještě jim dal ZP ve výši 30 kKč měsíčně, tak by časem skončili ve stejném srabu, jako jsou teď.

S tím souhlasím, bohužel to tak je.

Obávám se, že jsem v diskusi ten nihilista, který nevidí řešení ani jedním směrem. Řešit takovéhle lidi je obecně strašně těžké.

[Käyttäjä 11133]

že kdyby nějaký dobrodinec zaplatil všechny jejich dluhy

Stačí chvilku počkat a pak se nechat oddlužit v insolvenčním řízení

[xkucf03]

Není to tak jednoduché, jak si možná představuješ ;-)

[Käyttäjä 11133]

Vím velice dobře jak jednoduché to je, protože jsem jedné příbuzné s oddlužením pomáhal a čekat je potřeba jenom proto, protože v současné době stále musíš za 5 let zaplatit alespoň 30% dluhů.

[xkucf03]

Ono už jen pět let řešit ty dluhy mi přijde dost otravné. Ale osobní zkušenost s tím nemám, asi o tom víš víc, nechci se hádat.

[Käyttäjä 11133]

No tak já jakožto inteligentní člověk bych nejdříve restrukturoval aktiva (odvedl do zahraničí) a až pak bych se nechal oddlužit od svých pasiv, že...

[xkucf03]

To trochu zavání úvěrovým podvodem…

[Käyttäjä 11133]

To docela dost záleží na tom jak to člověk udělá, ale já bych to dělal chytře, takže se není čeho bát, nehledě na to, že ochota Policie ČR vyšetřovat úvěrové podvody je mizivá (to říkám jako člověk, který byl na straně poškozeného nejméně ve 3 případech).

[kralyk z abclinuxu]

Kdyby ty lidi někdo vykopal ze sociálek, úřadů a zbytečných firem přisátých na stát, tak by se ve vlastním zájmu rekvalifikovali a šli dělat něco, co ostatní reálně potřebují.

To je opět ta neuvěřitelná naivita a idealismus. Vůbec nevim, odkud jsi vzal myšlenku, že takový člověk půjde dělat něco užitečného, něco takového vůbec není zaručeno. Naopak se dá celkem předpokládat, že pokud to je nepoctivý člověk ochcávající systém, nejspíše půjde do nějakého pofidérního byznysu, různé firmy na hraně zákona, etc. O několika takových případech dokonce i vím z okolí.

[xkucf03]

Takže mu radši dáme peníze jen tak nebo ho zaměstnáme na úřadě, aby nešel dělat nějaký pofidérní byznys?

[kralyk z abclinuxu]

A: Máme problém X.
B: Mám nápad: Vyřešíme to pomocí Y.
C: To nebude mít dobré výsledky, protože [důvody].
B: Takže ty bys radši udělal nesmyslný krok Z?

Supr diskuse, good job.

[Fluttershy, yay!]

Což není zcela relevantní, protože to nebere v potaz možné změny struktury zdanění a efektivitu výběru (sarkastická poznámka: něco něco EET).

[ehm]

Asi se do téhle diskuze nechci pouštět. Jen pár myšlenek:

(I.) S pokrokem automatizace nezbyde než přijít s lepším ekonomickým uspořádáním. Těžko odhadovat, jak by vypadala společnost, kde stroje budou schopny obstarat veškerý proces získávání potravy, lékařskou péči a v neposlední řadě i opravu sebe sama a případnou těžbu potřebných surovin.

Za takových podmínek bych možná neměl výtky ani vůči tomu, aby takovou techniku vlastnil stát a (např.) potravu přerozděloval.

Potíž je, že s největší pravděpodobností to nebude tak ideální, že by všeho byl dostatek a o každého bylo postaráno. Dost možná bude zoufalý nedostatek i pitné vody, v duchu čehož ostatní problémy ustupují do pozadí.

Dost pravděpodobně by nás čekala řízená/regulovaná reprodukce, aby se velikost populace udržela v mezích, kdy ještě bude možné ji uživit.

Jednotlivci se stejně budou snažit si svou životní úroveň zvýšit a nějaký trh existovat asi bude (resp. nemá žádný užitek snažit se tomu bránit).

(II.) Za současných podmínek mi to přijde dost nebezpečné.

(a) Nevím, jestli by si to státní rozpočet mohl dovolit; ušetří se sice na důchodech a sociálních dávkách, ale kde vezmeš ten zbytek?

(b) Pokud kvůli ZP část lidí přestane pracovat, zvýší se ceny lidské práce a tím i ceny zboží/produktů. V důsledku tedy kupní síla ZP devalvuje. V neposlední řadě budou státu chybět příjmy z daní, které ti dříve pracující lidé odváděli.

(c) Pokud budeme chtít předejít (b), ZP musí být stanovetn dostatečně nízký (tj. tak, že se z něj nedá vyžít). To v důsledku znamená, že pracující lidé to prakticky nijak nepocítí (resp. to ucítí podobně jako třeba snížení daní), zatímco nepracujícím lidem to uškodí, protože budou dostávat mnohem míň než se sociálních dávek.

---

Závěr: ZP mi přijde nereálné teď zavádět. Jedna z možností to může být ve chvíli, kdy bude automatizovaná takřka celá ekonomika a uplatnění lidské práce by bylo minimální až žádné.

Pozn.: Vyspělé ekonomiky se vyznačují silným sektorem služeb. Aplikováno na automatizaci, bohatí majitelé firem pravděpodobně vytvoří pracovní místa nepřimo. Lze předpokládat, že raději zajdou do restaurace s lidskou obsluhou, třebaže je mnohem dražší, rádi si pořídí ručně opracovaný dřevený nábytek, poslechnou lidské hudebníky apod. Do jisté míry tento trend lze pozorovat již dnes. Otázkou je, zda to bude stačit, popř. zda to nepovede k modernímu otroctví, a jak bude ten přerod vypadat. V takovém případě možná viz bod I.

(Reagovat možná budu na příspěvky, které jsou striktně k věci, nepokládají otázku, která už byla zodpovězena, a jejichž autor projevil dostatečnou míru inteligence a schopnost porozumět psanému textu. Grunt se ani nemusí snažit. Děkuji.)

[Bystroushaak]

Potíž je, že s největší pravděpodobností to nebude tak ideální, že by všeho byl dostatek a o každého bylo postaráno. Dost možná bude zoufalý nedostatek i pitné vody, v duchu čehož ostatní problémy ustupují do pozadí.

To se zrovna dá řešit technologií docela dobře, pokud by fakt byla vůle. Jenže zatím jsou prostě priority jinde.

Dost pravděpodobně by nás čekala řízená/regulovaná reprodukce, aby se velikost populace udržela v mezích, kdy ještě bude možné ji uživit.

Momentálně máme opačný problém - populace v podstatě ve všech vyspělých zemích se snižuje a to tak, že to hrozí rozbít důchodové systémy, které na snižování nejsou stavěné.

[pavlix]

To není opačný problém. Vysoká reprodukce nevzdělaných chudých lidí produkující masy nekvalifikovaných lidí toužících po lepším životě ve spojení s nízkou reprodukcí lidí vzdělaných a kvalifikovaných, považuju za jeden univerzální problém z velké části způsobený i nevyváženou změnou životní úrovně (lepší zdravotní péče, ale ne lepší vzdělání a uplatnění) v zemích třetího světa. A k tomu jsou tu náboženské skupiny posedlé sexualitou toužící po ovládnutí životního prostoru rozmnožováním (například katolická církev), které právě působí i v tom třetím světě.

[pavlix]

Abych to ještě upřesnil... současný trend vede v našem prostoru (dejme tomu EU) nejen k vyššímu zastoupení starých a tím pádem neproduktivních lidí, ale vlivem přirozené migrace se zvyšuje i zastoupení mladých neproduktivních lidí, což sociální systém ještě více zatěžuje. Jedno z řešení je samozřejmě nechat věci plynout přirozenou cestou, Evropany nechat až na bláznivé výjimky vesele vymírat a umírat třeba i hladem (což je dnes věc zde nevídaná) a uvolnit tady prostor pro lidi na nižším stupni civilizace, aby si tu s obživou nějak poradili. :)

[Bystroushaak]

Jo, a do velké míry nás k tomu všemu imho nutí právě konstrukce důchodového systému. Jenže co s tím?

[pavlix]

Nevím o tom, že by nás konstrukce důchodového systému v tuto chvíli k něčemu nutila.

[Bystroushaak]

Důchodový systém nutí majoritu populace zůstat v ekonomickém běhu. Pokud se velikost té populace bude snižovat, tak buď všechny neúměrně zatíží, nebo, a to můžeme vidět v okolních zemích, vznikne tlak na příjem migrantů.

[Rezervní polská kotace]

A k tomu jsou tu náboženské skupiny posedlé sexualitou toužící po ovládnutí životního prostoru rozmnožováním (například katolická církev), které právě působí i v tom třetím světě.

To není zdaleka jen katolická církev. Stejně se k tomu staví i židé a (co je ted největší problém) muslimové - snaží se přemožit a ovládnout další území.

[pavlix]

Já jsem nepsal, že je to jen katolická církev, ale v našich končinách je to asi nejlepší příklad.

[ehm]

Je na pováženou, zda je potřeba štípat dříví, lovit zvířata a pěstovat plodiny, aby byly zajištěny základní potřeby.

[Jendа]

Je na pováženou, zda je potřeba generovat zisk, aby byly zajištěny základní potřeby

A jak by sis to představoval ty? Robotickou post-scarcity-economy tady ještě nemáme, takže IMHO moc jiných způsobů než pracovat nezbývá.

[Fluttershy, yay!]

V Česku máme např. více méně univerzální zdravotní péči.

[Jendа]

Vyjadřuješ se v náznacích a jinotajích.

[Bystroushaak]

+1

[Fluttershy, yay!]

Komentář byl myšlen jako protipříklad, a sice v systému s univerzální [sociální a zdravotní] péčí bys neměl osobně potřebovat kapitál k přežití.

Ale samozřejmě jsou země, kde tomu tak je a lidé skutečně hojně bankrotují, jdou na ulici nebo umírají, protože tam záchytná síť chybí nebo funguje hůře. Ale nemyslím, že je dobrý nápad je napodobovat.

[xkucf03]

Jedna věc je holé přežití a druhá věc je udržet si životní úroveň. Proč bych měl třeba prodávat majetek, stěhovat se, rušit předplatné služeb, jíst horší jídlo, přestat chodit sportovat a za kulturou atd. ve chvíli, kdy nějaká firma (shodou okolností můj zaměstnavatel nebo třeba klíčový zákazník) zkrachuje?

Je víc než rozumné si držet nějaké peníze bokem pro vykrytí horších období, kdy přijde nějaký průšvih nebo je třeba jen méně zakázek.

Nebo si snad představuješ, že stát dokáže zaručit konstantní životní úroveň i relativně bohatým lidem? Kde by na to vzal? V tom případě by akorát ty rezervy musel držet stát (místo těch lidí nebo třeba soukromé pojišťovny), ale to by nic dobrého nepřineslo (uvědom si, že současní politici nejsou schopní držet rezervy vůbec žádné a místo toho nás trvale zadlužují).

[Fluttershy, yay!]

Non sequitur.

nepůjdu hned pod most

aby byly zajištěny základní potřeby

[Kate]

To bych sem asi nenastoupila :D

[JS1]

Já (většinou) nemám za zlé, když mě na bias někdo upozorní, protože mi vadí, když biasy používám a nevím o tom.

Vidis, a ted se te snazim upozornit, ale zda se, neposlouchas.

Ne, já nesouhlasím se základním axiomem téhle teorie, tedy že „nikdo neví, k čemu ta práce je“. To prostě popírá moje zkušenosti.

No ano - pokud delas ve firme o 4 lidech, tam samozrejme ten kontext neni problem zjistit. Ale predstav si, ze tu zbytecnou praci vymyslelo treba jine oddeleni. Bude ten sef stejne osviceny, aby se zeptal sveho sefa, ten taky jeste sveho sefa, ten sveho kolegy C*O, a ten vsech tech svych ovecek pod nim, aby se zjistilo, ze to vlastne potreba neni?

Kazdopadne, tady nelze nez doporucit slavny Graeberuv esej o "bullshit jobs".

Praxí jsem ale zjistil, že musím plácat i ostatní, protože nikdo jiný to neudělá a oni pak sklouzávají k depresím a vidí problémy i tam, kde nejsou.

A nebo je naopak ta situace trapi vic nez tebe, a proto si na to stezuji vic, zatimco ty jsi v klidu, a zijes ve svem biasu, ze je vsechno v pohode a problem neexistuje. A mas samozrejme pravdu, kdyby problem existoval, uz by bylo po nas, a k tomu zatim nedoslo. Co na tom, ze fakticky diky stiznostem lidi, na ktere si stezujes, se te katastrofe podarilo predejit?

(A to jsem si nevymyslel. Znam inteligentni lidi, kteri si skutecne mysli, ze treba kysele deste nebo ozonova dira nebyly realne ekologicke problemy, kterym lidstvo muselo v minulosti celit.)

[Bystroushaak]

Vidis, a ted se te snazim upozornit, ale zda se, neposlouchas.

Nebo ti není dostatečně dobře rozumět.

No ano - pokud delas ve firme o 4 lidech, tam samozrejme ten kontext neni problem zjistit. Ale predstav si, ze tu zbytecnou praci vymyslelo treba jine oddeleni. Bude ten sef stejne osviceny, aby se zeptal sveho sefa, ten taky jeste sveho sefa, ten sveho kolegy C*O, a ten vsech tech svych ovecek pod nim, aby se zjistilo, ze to vlastne potreba neni?

Kazdopadne, tady nelze nez doporucit slavny Graeberuv esej o "bullshit jobs".

Viděl jsem, not impressed. Related: Growing Up and Being Useful is The New Counterculture

A nebo je naopak ta situace trapi vic nez tebe, a proto si na to stezuji vic, zatimco ty jsi v klidu, a zijes ve svem biasu, ze je vsechno v pohode a problem neexistuje. A mas samozrejme pravdu, kdyby problem existoval, uz by bylo po nas, a k tomu zatim nedoslo. Co na tom, ze fakticky diky stiznostem lidi, na ktere si stezujes, se te katastrofe podarilo predejit?

Aha. No, tak ono záleží na definici slova „problém“. Například já a většina mojí rodiny nemám existencionální problém, naopak všichni koho znám se mají líp, než jak se měli třeba 10, 15 let zpět.

[JS1]

Nemusis byt tak defenzivni, ja bych jenom rad, kdyby ses nad tim zamyslel. Protoze "za pohled mas 80 bodu".

Related: Growing Up and Being Useful is The New Counterculture

Nevim, co se tim videem snazis rict a jak je to relevantni.

Například já a většina mojí rodiny nemám existencionální problém, naopak všichni koho znám se mají líp, než jak se měli třeba 10, 15 let zpět.

Pripada mi, ze se me zase snazis presvedcit o svem biasu, ktery sam nevidis. Tohle je presne veta, kterou rekne nekdo, kdo se chova tak, jak jsem popsal v predchozim prispevku.

[Bystroushaak]

Ok, to vypadá, že máme problém v pochopení. Můžeš ještě jednou detailně rozebrat ten můj předpokládaný bias? Jakože úplně jasně a polopatě tak jak si myslíš, že to je? Já se neurazím.

[JS1]

Tvuj bias je v tom, ze vnimas lidi, co si stezuji jako zahorkle, a pritom jsou dost mozna vice zainteresovani v tom, aby se veci zlepsily, nez ty. A proto si na to stezuji, zatimco ty ne.

Nicmene, koukal jsem na par videi toho pana Petersona, a mezi nim a Graeberem je zasadni, jemny rozdil - zatimco Graeber vychazi z toho, co pocituji samotni lide (tedy svuj esej stavi na tom, ze spousta lidi vidi svou vlastni praci jako zbytecnou), Peterson predpoklada, ze vi lepe, nez ostatni lide, jak by se ti ostatni lide meli chovat.

Mne pripada pozice, ze zbytecna prace v soucasne spolecnosti neexistuje (nebo ze ji nepribyva), jako dost obtizne udrzitelna. Dva priklady jenom clanku z posledniho tydne, co jsem nahodou cetl, kde nekdo popisuje zbytecnou praci: 1, 2.

[Bystroushaak]

Tvuj bias je v tom, ze vnimas lidi, co si stezuji jako zahorkle, a pritom jsou dost mozna vice zainteresovani v tom, aby se veci zlepsily, nez ty. A proto si na to stezuji, zatimco ty ne.

Osobní zkušenost. Většina z nich je zahořklá a zrovna z OPovo postu to bylo cítit docela hodně.

Mne pripada pozice, ze zbytecna prace v soucasne spolecnosti neexistuje (nebo ze ji nepribyva), jako dost obtizne udrzitelna. Dva priklady jenom clanku z posledniho tydne, co jsem nahodou cetl, kde nekdo popisuje zbytecnou praci: 1, 2.

To ale nechci tvrdit a pokud to tak vypadá, tak jsem to napsal špatně. Chci tvrdit, že to není civilizační risk a že se to neděje v takovém měřítku, v jakém je to předřečníkem prezentováno. Ten to mimochodem popsal tak, že mezi zbytečné práce šmahem hodil všechny programátory a vůbec lidi pracující s počítačem, viz „Boj o pracovni misto u klavesnice a obrazovky“ a „miliony 'pracujicich' mohou vydovadet s blbinamia a jeste za to berou slusne penize“.

Chová se, jako kdyby byl on, kdo rozhoduje o tom, která práce je zbytečná a která není podle nějakého svého interního klíče a pak se lze těžko divit, že mu toho tolik přijde zbytečného. Přitom o tom rozhoduje právě a jen společnost, která různé práce různě v čase odměňuje podle poptávky po nich.

[JS1]

Osobní zkušenost.

..je jenom jiny nazev pro bias. A pokud ti na necem opravdu zalezi, budes casem taky zahorkly, neboj.

Chci tvrdit, že to není civilizační risk a že se to neděje v takovém měřítku, v jakém je to předřečníkem prezentováno.

Civilizacni risk to asi neni, pravda, ale deje se to v meritku znacnem. Staci se treba jen podivat, jak se vsichni zblbli na prepisovani desktopovych na webove aplikace.. IT skutecne zda se generuje daleko vic vlastnich problemu nez resi.

No treba se nad temi absurditami taky casem zacnes pousmivat, jako ja.

Přitom o tom rozhoduje právě a jen společnost, která různé práce různě v čase odměňuje podle poptávky po nich.

Aha. Takze to je jadro tvoji polemiky s Graeberem. Zase, mel bys pochopit, ze tento predpoklad neni zadny objektivni fakt, ale jen jisty normativni uhel pohledu, ktery je prinejmensim stejne validni jako ten Graeberuv (totiz ze uzitecnost prace urcuje to, zda lide citi, ze je uzitecna). Ostatne, lze nejspis pomerne snadno ukazat, ze v situaci dokonaleho trhu (kde maji vsichni dostatecny pristup k informacim) jsou oba pohledy ekvivalentni.

[Bystroushaak]

Civilizacni risk to asi neni, pravda, ale deje se to v meritku znacnem. Staci se treba jen podivat, jak se vsichni zblbli na prepisovani desktopovych na webove aplikace.. IT skutecne zda se generuje daleko vic vlastnich problemu nez resi.

Kolik procent IT jsou webové aplikace, aby se na základě toho argumentu dalo hodit celé IT do pytle s nápisem „generuje víc problémů, než řešení“?

Jinak tohle je taky dobrá ukázka zahořklosti. Znám lidi, kteří se začali angažovat jako programátoři až minulý rok. Pro ně jsou webové aplikace něčím naprosto přirozeným a naopak nemají vůbec žádný důvod používat žádné jiné. A nemůžu říct, že by neměli dobré argumenty - webová aplikace jede všude, na tabletu, na telefonu, na televizi, na hodinkách, na čtečce, na počítači i na notebooku. Navíc se nemusí instalovat, dá se okamžitě updatovat všem klientům a může poskytovat luxusní API, které je co do jednoduchosti a standardizovanosti o generaci dál, než co většinou nabízejí desktopové aplikace.

Teď se asi hodí říct, že já s nimi nesouhlasím, dokonce mám rozepsanou kritiku webových aplikací, začínající slovy ‚Ach jo, jak jen mě serou „moderní“ webové aplikace.‘ . Ne proto, že bych měl rád desktopové aplikace, ale protože se řadím k ještě hlubší a mnohem starší skupině oldfagů, kteří si myslí, že všechno šlo do prdele už v roce 1979, když přijel Steve Jobs do Xeroxu na návštěvu a zapoměl ukrást Smalltalk. Ostatně proto taky po nocích hackuju Self, protože to je ještě větší mimozemšťan než Smalltalk a taky z Xeroxu.

No treba se nad temi absurditami taky casem zacnes pousmivat, jako ja.

Já vím co se tím myslí a chápu úplně přesně, na co naráží. Jen prostě nesouhlasím se závěrem. Nedávno jsem dočetl esej „As we may think“, od Vannevara Bushe, sepsanou v roce 1945, kde mimo jiné představil i něco jako osobní počítač. Hádej co? Spousta dnešních problémů IT existovala dokonce i před tím, než IT vzniklo, protože to ve skutečnosti vůbec nejsou problémy IT, ale problémy organizace informací a struktury rozhodování.

Lidi v téhle pozici usmívajícího se starce IT kmenu (mimochodem, doporučuji osmnácti-dílnou sérii „Vzpomínky na servis počítačů před 30 lety“ z pera mistra Ogilviho na zpovedce (ochutnávka), nebo knihu Očima estébáka, aneb, Jak jsem škodil lidu (odkaz na stažení se dá vygooglit)) zapomínají, že problémy nejsou v technologiích, problémy jsou v lidech. A dokud budou lidi lidmi, problémy tohohle druhu nikam nezmizí.

Aha. Takze to je jadro tvoji polemiky s Graeberem. Zase, mel bys pochopit, ze tento predpoklad neni zadny objektivni fakt, ale jen jisty normativni uhel pohledu, ktery je prinejmensim stejne validni jako ten Graeberuv (totiz ze uzitecnost prace urcuje to, zda lide citi, ze je uzitecna). Ostatne, lze nejspis pomerne snadno ukazat, ze v situaci dokonaleho trhu (kde maji vsichni dostatecny pristup k informacim) jsou oba pohledy ekvivalentni.

Ok, můžu to uznat jako teoretickou poznámku, ale těžko to může soupeřit s okamžitou realitou kolem nás, kde to (s výjimkou státní správy) funguje z velké většiny tak, jak jsem napsal.

[xkucf03]

Kolik procent IT jsou webové aplikace, aby se na základě toho argumentu dalo hodit celé IT do pytle s nápisem „generuje víc problémů, než řešení“?

Tenhle dojem bude souviset s tím, že fungující IT není příliš vidět a spousta lidí ani neví, že tam nějaké IT je (ale ono je dneska v podstatě všude).

[xkucf03]

a může poskytovat luxusní API, které je co do jednoduchosti a standardizovanosti o generaci dál, než co většinou nabízejí desktopové aplikace.

To API se samo nenapíše. A pokud bylo navrženo jen jako interní komunikační prostředek v rámci dané aplikace (propojit klienta a server), tak je prakticky nepoužitelné pro kohokoli jiného – typicky chybí dokumentace a není žádná záruka stability tohoto rozhraní. A pokud si dal někdo práci s tvorbou stabilního veřejného API, tak totéž mohl udělat u desktopové nebo jakékoli jiné aplikace, pracnost by byla stejná.

[Bystroushaak]

A pokud si dal někdo práci s tvorbou stabilního veřejného API, tak totéž mohl udělat u desktopové nebo jakékoli jiné aplikace, pracnost by byla stejná.

Nejsem si úplně jistý s premisou, že pracnost by byla stejná (například desktopové aplikace se často píšou single thread, kdežto webové vždycky musí obsloužit víc uživatelů), ale imho je hlavní důvod tlak na provozovatele, speciálně když se to kombinuje s popularitou (mobilních, tabletových) „appek“. API je často taky používáno na integraci služby do dalších a provozovateli přidává přidanou hodnotu a další zákazníky. To mi přijde, že u desktopových aplikací chybí.

[xkucf03]

Nejsem si úplně jistý s premisou, že pracnost by byla stejná (například desktopové aplikace se často píšou single thread

Možná tak u řádkových (CLI) aplikací – a tam API vlastně máš (parametry příkazové řádky). U desktopové (GUI) aplikace prakticky nikdy jednovláknově psát nemůžeš, protože déletrvající akce běžící na pozadí by ti blokovaly GUI (ano, takové aplikace existují – ale zablokované GUI je chyba).

tlak na provozovatele, speciálně když se to kombinuje s popularitou (mobilních, tabletových) „appek“

Interní API mobilních a tabletových „appek“ je většinou proprietární a nepoužitelné jako veřejné API pro někoho cizího (chybí dokumentace a záruka stability API).

API je často taky používáno na integraci služby do dalších a provozovateli přidává přidanou hodnotu a další zákazníky.

To už je veřejné API. Ale jak říkám, to můžeš udělat i na desktopu a naopak ho nemusíš udělat na webu.

To mi přijde, že u desktopových aplikací chybí.

To záleží na záměru a zájmu/ochotě autora, ne na tom jestli je to desktop nebo web.

Na desktopu máme taky API. Máme parametry příkazové řádky, kterými můžeš poslat příkaz stávající aplikaci místo abys spouštěl novou instanci. Máme D-Bus, kterým uděláš totéž. Máme unixové sokety, kterými můžeš komunikovat s běžícími aplikacemi. Máme POSIX MQ. Atd.

[Bystroushaak]

Interní API mobilních a tabletových „appek“ je většinou proprietární a nepoužitelné jako veřejné API pro někoho cizího (chybí dokumentace a záruka stability API).

Myslel jsem API aplikací, které využívají nějaký web. Třeba Github je dobrý příklad, ale i Slack, Facebook a další.

To už je veřejné API. Ale jak říkám, to můžeš udělat i na desktopu a naopak ho nemusíš udělat na webu.

Tak samozřejmě, myslel jsem, že se ale bavíme o tom, co se běžně dělá, ne co se dá dělat.

Na desktopu máme taky API. Máme parametry příkazové řádky, kterými můžeš poslat příkaz stávající aplikaci místo abys spouštěl novou instanci. Máme D-Bus, kterým uděláš totéž. Máme unixové sokety, kterými můžeš komunikovat s běžícími aplikacemi. Máme POSIX MQ. Atd.

Jo, jsem si vědom, protože ho používám. Pokud bych měl na výběr REST, tak si ho vyberu úplně pokaždé. Všimni si, že snad kromě D-Busu nic z toho nemá ani jasně danou strukturu přenášených informací, což může být výhoda, ale v praxi, když s tím chceš komunikovat je to jen nevýhoda (každý program si to řeší po svém). Asi úplně nejhorší jsou ty parametry příkazové řádky, protože to fakt co program, to něco úplně jiného.

Osobně si myslím, že nejdál je v tomhle Smalltalk, kde prostě API jsou jednotlivé objekty v paměti. Se všemi můžeš jednotným způsobem interagovat, můžeš na nich provádět introspekci, číst nápovědu atd.. K tomu (resp. k Selfu) jsem dospěl od vydání Proč používám Unix/Linux.

[xkucf03]

nic z toho nemá ani jasně danou strukturu přenášených informací, což může být výhoda, ale v praxi, když s tím chceš komunikovat je to jen nevýhoda (každý program si to řeší po svém)

Přesně tohle řeším ve svém zápisku vedle :-)

Asi úplně nejhorší jsou ty parametry příkazové řádky, protože to fakt co program, to něco úplně jiného.

Tak jistá snaha o jednotnost tu je, např. krátké volby s jednou pomlčkou -v a dlouhé se dvěma --version. Ale někteří i na tohle kašlou nebo to nemůžou změnit – největší problém je tu zpětná kompatibilita, kvůli které spoustu věcí pro nepředěláš (musel bys vytvořit nový příkaz/program, případně nějaký přepínač --api-v2 nebo proměnná prostředí…).

Osobně si myslím, že nejdál je v tomhle Smalltalk, kde prostě API jsou jednotlivé objekty v paměti.

A jak řekneš, co je veřejné API a co je privátní? Veřejné API by mělo být stabilní, ale zdaleka ne všechno chceš takhle zafixovat. Uvnitř programu chceš mít volnost, možnost refaktorovat atd. Např. Java k tomuhle má JMX – tam zpřístupníš vybrané objekty a uživatel (nebo spíš nějaký program na správu aplikací) na nich může volat metody, číst a nastavovat vlastnosti a může odebírat události.

[Bystroushaak]

Tak jistá snaha o jednotnost tu je, např. krátké volby s jednou pomlčkou -v a dlouhé se dvěma --version. Ale někteří i na tohle kašlou nebo to nemůžou změnit – největší problém je tu zpětná kompatibilita, kvůli které spoustu věcí pro nepředěláš (musel bys vytvořit nový příkaz/program, případně nějaký přepínač --api-v2 nebo proměnná prostředí…).

Tak ona je to zkurvnost i z toho důvodu, že neexistuje introspekce. --help je sice hezký (když funguje, lol, někde je jen -h a někde nic), na platformě závislé (sranda je portovat věci z linuxu do jiného unixu), ale kolikrát z toho ani pořádně nezjistíš, jaké jsou sety parametrů (co s čím jde kombinovat), aniž bys to musel vyzkoušet. To ani nemluvím o tom, že je to strojově neparsovatelné. Pak jsou tu věci, jako že je to úplně debilní na volání z jiných programů (chybové kódy má taky každý jinak), pletou se do toho tty a buffery proudů (nemluvím o tom že musíš flushovat, ale o stdbuf) a co já vím co všechno ještě, i když vynechám escapování shellu. A vracení dat zpět, to je zkurvenost sama pro sebe.

Zrovna v práci debuguju systém, který má podstatné části napsané jako volání ostatních programů, předávání parametrů, parsování chybových kódů, zpravávání stdout a stderr. To je tak zkurveně křehké, že z toho mám chůť se zabít asi tak třikrát za den. Většinou lidi, co mají pocit, že jsou tyhle věci jednoduché nikdy nic podobného nezkoušeli. Například snaha přes stdout tahat strukturovanou informaci celá stojí na tom, že se nic z početných podknihoven někde cestou „neubleje“ nějakým perverzním způsobem (a že jsem viděl věci, z kterých se mi dodnes krabatí chlupy na prdeli).

A jak řekneš, co je veřejné API a co je privátní?

Prostě to dáš do kategorie „veřejné API“? Osobně se mi nejvíc líbí přístup pythonu, kde prostě „privátní“ věci začínají na __ a „protected“ na _. Oboje dvoje znamená „sice můžeš šahat do vnitřností, ale když ti to zláme prsty, tak se nediv“. A světe div se, funguje to skvěle.

[ehm]

Prostě to dáš do kategorie „veřejné API“? Osobně se mi nejvíc líbí přístup pythonu, kde prostě „privátní“ věci začínají na __ a „protected“ na _. Oboje dvoje znamená „sice můžeš šahat do vnitřností, ale když ti to zláme prsty, tak se nediv“.

Ó, jak by se člověku zjednodušil život, kdyby modifikátory viditelnosti v Javě měly jen dokumentační efekt a bylo možné to (třeba nějakým syntaktickým cukříkem) overridnout.

Jak můžeš použít třeba modifikátory private nebo protected, když tu metodu potřebuješ otestovat? Řeším to prostě tak, že metodu nechám jen package-protected, abych to z testu, který je v jiném source-rootu, ale ve stejném packagi, mohl zavolat.

Mnohem víc by se mi líbílo, kdyby zůstal více/méně plně současný stav, ale s tím, že to jde ochcat i jinak než použitím reflexe nebo invokedynamic. Může to být něco ve stylu:

object.@fuckingPrivateMethod();

Popř. tam vůbec žádná zvláštní syntax být nemusí – tak to má např. Groovy. Mně přijde, že by to nějak odlišené být mělo, ale to už je detail.

IDE by při našeptávání mělo veřejné a skryté metody taky třeba nějak barevně odlišit a veřejné metody řadit na začátek.

Usnadnilo by to tolik věcí... Debugování, testování, a především práci se špatně napsaným kódem. Setkal jsem s tím zrovna nedávno; v kódu jsou nadefinované konstanty, o kterých se autoři domnívali, že by měly před zraky uživatele zůstat skryté. Já mám naopak velmi dobrý důvod ty konstanty použít, ale hrábnout na ně nijak normálně nemůžu, takže to musím překopírovat. Úžašně smysluplné...

[xkucf03]

Jak můžeš použít třeba modifikátory private nebo protected, když tu metodu potřebuješ otestovat?

Říká se, že jednotkové testy by tě měly vést i k lepšímu návrhu tříd. Ten test by měl danou jednotku testovat zvenku a pokud je jednotkou třída, tak by měl testovat její veřejné metody.

Otestovat tu privátní metodu skrze ty veřejné, které ji volají, může být někdy pracnější a může tě to štvát… ale pak je otázka, jestli v tom případě neporušuješ některá návrhová doporučení (např. toho ta třída dělá víc, než by měla a smíchal si v ní víc věcí dohromady).

Setkal jsem s tím zrovna nedávno; v kódu jsou nadefinované konstanty, o kterých se autoři domnívali, že by měly před zraky uživatele zůstat skryté. Já mám naopak velmi dobrý důvod ty konstanty použít, ale hrábnout na ně nijak normálně nemůžu, takže to musím překopírovat. Úžašně smysluplné...

Můžeš uvést konkrétní příklad, co v těch konstantách je?

Buď je to chyba autora, že udělal privátní něco, co měla být součást veřejného API, nebo to používáš špatně. Ale rozhodně bych to neprasil tím, že se budu snažit používat cizí privátní konstanty. To si můžeš dovolit tak leda u těch testů svého kódu. Ty cizí privátní konstanty se ti můžou v příští verzi klidně změnit nebo zmizet – nemáš žádnou záruku stability, není to veřejné API. Je to jako kdybys v tom Pythonu přistupoval k cizím _ a __ a pak se divil, že ti něco přestalo fungovat.

[kralyk z abclinuxu]

Můžeš uvést konkrétní příklad, co v těch konstantách je?

Do přesně stejné debaty jsem se onehdá dostal někde na SO nebo tak něco.

Uváděl jsem tam příklad se sortovací funkcí.

Klasicky se na řazení používá quicksort nebo podoobný rychlý algoritmus, nicméně pro krátké sekvence (něco jako 10 elementů, nevim přesně) je trochu nečekaně rychlejší bubblesort. Takže AFAIK bývají ty funkce implementovány tak, že pole kratší než $magická_konstanta řadí bubblesortem místo quicksortem. Ta konstanta nemá IMHO vůbec co dělat v API, je to implementační detail. Nicméně pro testování je důležité ji znát, protože jinak hrozí, že otestuješ implementaci jen jednoho z obou použitých algoritmů.

Další takový příklad (na což jsem právě i nedávno narazil) jsou různé datové struktury, kde existuje nějaký práh. Například SmallVector. Nebo struktury jako hashmapy nebo podobné, které interně obsahují nějaké buckety fixní velikosti. Opět z podobných důvodů je dobré znát ty prahy, velikosti bucketů, apod.

Blackbox testing je samozřejmě dobrá věc, nicméně je potřeba mít na paměti, že API / interface není nikdy zcela do důsledku oproštěň od implementačních detailů.

[kralyk z abclinuxu]

Respektive u toho SmallVectoru typicky ten práh je součástí API, nicméně tím se problém pouze přesune na strukturu/funkci, která ho používá a kterou jistě bude taky potřeba otestovat...

[xkucf03]

Nicméně pro testování je důležité ji znát, protože jinak hrozí, že otestuješ implementaci jen jednoho z obou použitých algoritmů.

Proto se měří pokrytí testy.

Uváděl jsem tam příklad se sortovací funkcí. Klasicky se na řazení používá quicksort nebo podoobný rychlý algoritmus, nicméně pro krátké sekvence (něco jako 10 elementů, nevim přesně) je trochu nečekaně rychlejší bubblesort. Takže AFAIK bývají ty funkce implementovány tak, že pole kratší než $magická_konstanta řadí bubblesortem místo quicksortem. Ta konstanta nemá IMHO vůbec co dělat v API, je to implementační detail.

Tohle je přesně případ špatného návrhu, kde by tě jednotkový test měl donutit se zamyslet a navrhnout to lépe. Ty dva algoritmy nemají být spojené dohromady do jednoho nedělitelného celku.

Jedna jednotka je quicksort. Druhá jednotka je bubblesort. Obě implementují společné rozhraní (pokud to ten jazyk umožňuje). Třetí jednotka obsahuje jen tu rozhodovací logiku (který algoritmus použít). Bude opět implementovat totéž rozhraní (podporuje-li to jazyk) a ty první dvě jednotky do ní injektuješ jako parametry (můžou to být jak instance nějaké třídy, tak funkce, záleží na paradigmatu jazyka) a stejně tak jako parametr nastavíš tu hranici, od které se používá který algoritmus. (jestli je to parametr nebo konstanta je z hlediska výkonu celkem jedno – a pokud to bude final parametr, tak je to úplně jedno)

Všechny tři jednotky otestuješ samostatně pomocí jednotkových testů. A pak k tomu napíšeš „integrační“ test, který ověří, že to funguje celé dohromady (nebo už budeš testovat nějaký větší celek, celý systém).

Další jednotka může být (resp. měla by být) funkce/třída, která porovnává (větší/menší/rovno) objekty – to by se nemělo míchat s těmi algoritmy – opět se to do nich jen injektuje jako parametr. Když to bude generické, tak můžeš jeden algoritmus použít na řazení různých datových typů.

Celé tohle „soustrojí“ si můžeš buď sestavit na míru aktuálním potřebám nebo si nějakou typickou konfiguraci instanciuješ předem a uložíš si ji (resp. udělá to autor knihovny) do globální proměnné (pokud jsou ty instance vícevláknově bezpečné, tak to není problém) nebo si na to uděláš továrnu nebo nějakou fasádu. Takže základní použití je pak jen o tom napsat něco jako x.y.sort(…) nebo spíš sort(…) podle toho, co si naimportuješ.

[kralyk z abclinuxu]

Ty dva algoritmy nemají být spojené dohromady do jednoho nedělitelného celku.

Ale mají, protože v podstatě tvoří jeden algoritmus adaptivní. V tomto příkladu nemám vůbec zájem na tom poskytovat nějaké širší API než jednu funkci. To, že to vevnitř používá dva nebo čtyři nebo jeden dílčí algoritmus je implementační detail, který se klidně může změnit.

Je dobrý nápad testovat ty dílčí algoritmy, na to stejně musí vevnitř existovat nějaké funkce, ale měly by to být privátní testy nebo testy s přístupem do privátních dat. Na testování toho veřejnýho API jsou pak také unit testy a integrační testy.

Publikovat jen kvůli testům 4× větší API než bylo záměrem, navíc obsahující implementační detaily, mi přijde jako nesmysl.

No a kromě toho tahle rada nefunguje na ty datový struktury. Ta řadící funkce byl jen příklad, to, co jsem řešil ve skutečnosti byl paralelní lock-free kontejner trochu podobný FIFO frontě, operující nad bucketama konstantní velikosti. A ne, ta velikost nemá být součástí API. API vůbec neví, že vevnitř jsou nějaké buckety. Teď např. přemýšlím, že ten vnitřek předělám ještě na trochu jinou strukturu, API ale zůstane v každém případě stejné.

Celé tohle „soustrojí“ si můžeš buď sestavit na míru aktuálním potřebám nebo si nějakou typickou konfiguraci instanciuješ předem a uložíš si ji (resp. udělá to autor knihovny) do globální proměnné (pokud jsou ty instance vícevláknově bezpečné, tak to není problém) nebo si na to uděláš továrnu nebo nějakou fasádu.

Klasická Javovská masturbace. Tam, kde normální člověk udělá jednu dvě funkce, javista vytvoří 15 tříd, 4 fasády, 2 tvorány, 3 singletony a 1 kontrafibulátor.

Statická proměnná tam nemá vůbec nic co dělat (wtf?). Když už tak default parametry generických argumentů nebo type alias.

[xkucf03]

No a kromě toho tahle rada nefunguje na ty datový struktury. Ta řadící funkce byl jen příklad, to, co jsem řešil ve skutečnosti byl paralelní lock-free kontejner trochu podobný FIFO frontě, operující nad bucketama konstantní velikosti. A ne, ta velikost nemá být součástí API. API vůbec neví, že vevnitř jsou nějaké buckety. Teď např. přemýšlím, že ten vnitřek předělám ještě na trochu jinou strukturu, API ale zůstane v každém případě stejné.

Od toho jsou přece rozhraní. A tím spíš, když píšeš takovouhle knihovnu. Tu tvoji třídu by neměl nikdo používat a pokud možno ani vidět (např. v OSGi modulu bys ji neexportoval) a měl by pracovat jen s tím rozhraním. Ve třídě pak klidně můžeš mít metody, jaké chceš.

Klasická Javovská masturbace. Tam, kde normální člověk udělá jednu dvě funkce, javista vytvoří 15 tříd, 4 fasády, 2 tvorány, 3 singletony a 1 kontrafibulátor.

Normální člověk si nebude psát tyhle věci sám a bude řešit byznys logiku. A pokud píšeš knihovnu, kterou mají používat ostatní, tak má smysl to udělat pořádně, dát tomu rozhraní a nezmatlat pět věcí do jedné třídy.

Statická proměnná tam nemá vůbec nic co dělat (wtf?).

static final proměnnou máš třeba v Collections.EMPTY_MAP. Nebo máš Objects.isNull(), což je sice metoda (kterou ve filtru zavoláš jako funkci přes Objects::isNull), ale klidně by to mohla být instance funkce (funkčního rozhraní), kterou máš připravenou v nějaké konstantě.

Nebo to může být singleton, který se instanciuje při prvním použití. Pak je to nefinální statická proměnná.

[kralyk z abclinuxu]

Od toho jsou přece rozhraní. A tím spíš, když píšeš takovouhle knihovnu. Tu tvoji třídu by neměl nikdo používat a pokud možno ani vidět

Cože? Proč ne? Je to prostě kontejner jako každej jinej, ačkoli na určitý specielní účel. Důvod pro rozhraní nevidím, rozhraní je užitečný pro polymorfismus, a to v tomto případě nemám důvod dělat.

A pokud píšeš knihovnu, kterou mají používat ostatní, tak má smysl to udělat pořádně, dát tomu rozhraní a nezmatlat pět věcí do jedné třídy.

Nikde žádných 5 věcí do jedné třídy zmatláno není.

static final proměnnou máš třeba v Collections.EMPTY_MAP

Ano, což je netypovaná berlička z doby před generiky v Javě...

[ehm]

Overengineering.

Máš takový kompromisní přístup ve stylu:

public class SortUtil {
    static final BUBBLE_THRESHOLD = 10;

    public static <T> void sort(T[] elements, Comparator<T> comparator) {
        if (elements.length <= BUBBLE_THRESHOLD) {
            bubbleSort(elements, comparator);
        } else {
            quickSort(elements, comparator);
        }
    }

    static <T> void bubbleSort(T[] elements, Comparator<T> comparator) {
        // ...
    }

    static <T> void quickSort(T[] elements, Comparator<T> comparator) {
        // ...
    }
}

V testu si pak samostatně otestuješ jak dílčí metody bubbleSort a quickSort, tak metodu sort. Ty test-casy můžou být víceméně společné, jen u testu pro sort je třeba dát pozor, že to půjde každou větví (podle konstanty BUBBLE_THRESHOLD).

Pak je druhý přístup, který může být třeba ve stylu:

    public interface Sorter {
        void <T> sort(T[] elements, Comparator<T> comparator);
    }

    public class BubbleSortSorter implements Sorter {
        public void <T> sort(T[] elements, Comparator<T> comparator) {
            // ...
        }
    }

    public class QuickSortSorter implements Sorter {
        public void <T> sort(T[] elements, Comparator<T> comparator) {
            // ...
        }
    }

    public class SmartSorter implements Sorter {
        private Sorter sorterForSmall;
        private Sorter sorterForLarge;

        public SmartSorter(Sorter sorterForSmall, Sorter sorterForLarge, int threshold) {
            this.sorterForSmall = sorterForSmall;
            this.sorterForLarge = sorterForLarge;
            this.threshold = threshold;
        }

        public void <T> sort(T[] elements, Comparator<T> comparator) {
            Sorter sorter = getAppropriateSorter(elements.length);
            sorter.sort(elements, comparator);
        }

        private Sorter getAppropriateSorter(int length) {
            return length <= threshold ? sorterForSmall : sorterForLarge;
        }
    }

Pak si samostatně otestuješ třídy BubbleSortSorter a QuickSortSorter. Pří testování třídy SmartSorter využiješ třeba Mockito a nainstancuješ ji s namockovanými implementacemi. Pak jednoduše otestuješ, že se to chová, jak má. Např.:

import static org.mockito.Mockito.*;

public class SmartSorterTest {
    private Sorter sorterForSmall;
    private Sorter sorterForLarge;
    private Comparator<Object> comparator;

    @Before
    public void before() {
        this.sorterForSmall = mock(Sorter.class);
        this.sorterForLarge = mock(Sorter.class);
        this.comparator = mock(Comparator.class);
    }

    @Test
    public void testUsesSmallSorter1() {
        doTestUsesCorrectSorter(3, 5, sorterForSmall);
    }

    @Test
    public void testUsesSmallSorter2() {
        doTestUsesCorrectSorter(5, 5, sorterForSmall);
    }

    @Test
    public void testUsesLargeSorter1() {
        doTestUsesCorrectSorter(6, 5, sorterForLarge);
    }

    private void doTestUsesCorrectSorter(int actualLength, int threshold, Sorter expectedSorter) {
        Object[] elements = new Object[actualLength];

        Sorter smartSorter = new SmartSorter(sorterForSmall, sorterForLarge, threshold);
        smartSorter.sort(elements, comparator);

        verify(expectedSorter).sort(elements, comparator);
        verifyNoMoreInteractions();
    }
}

Bonusová otázka: Jak vytvořit třídu SortUtil se statickou metodou sort? Jak oveříš, že to instanci SmartSorter nainstancovalo se správnými argumenty, tj. že se skutečně používá bubble sort, resp. quick sort, a že to předalo správný threshold? Ten problém – otestovat, že nějaká statická utilitka použije ten či onen algoritmus – zůstal úplně stejný. Ono totiž jakýkoliv statický kód se testuje dost blbě; v tomto případě by nezbylo než něco jako:

public class SortUtil {
    static Sorter sorter = new SmartSorter(new BubbleSortSorter(), new QuickSortSorter(), 10);

    public static <T> void sort(T[] elements, Comparator<T> comparator) {
        sorter.sort(elements, comparator);
   }
}

public class SortUtilTest {
    private static Sorter originalSorterInstance;

    @Before
    public void before() {
        this.originalSorterInstance = SortUtil.sorter;
    }

    @After
    public void after() {
        SortUtil.sorter = originalSorterInstance;
    }

    @Test
    public void testUsesCorrectInstance() {
        Sorter sorter = mock(Sorter.class);
        SortUtil.sorter = sorter;

        Object[] elemetns = new Object[0];
        Comparator<Object> comparator = mock(Comparator.class);

        SortUtil.sort(elements, comparator);

        verify(sorter).sort(elements, comparator);
        verifyNoMoreInteractions();
    }

    @Test
    public void testSorterCorrectlyInstantiated() {
        Sorter sorter = SortUtil.sorter;

        // ... a s použitím mnou navrhované syntaxe, protože, ouha, nemáme přístup k těm chráněným fieldům
        assertTrue(sorter.@sorterForSmall instanceof BubbleSortSorter);
        assertTrue(sorter.@sorterForLarge instanceof QuickSortSorter);
        assertEquals(10, sorter.@threshold);
    }
}

Kdybych to chtěl ještě trochu zkomplikovat, tak si v SortUtil udělám továrnu, která vyrobí Sorter. Pak si samostatně otestuji tu továrnu, že vrací správný Sorter, a ještě si otestuji, že ten kód používá správnou továrnu. Ale... To jsme si tedy moc nepomohli.

Co říct závěrem – všimni si, že ten problém s modifikátory, na který jsem úplně původně poukazoval, tam prostě zůstal. Ten field sorter ve třídě SortUtil by měl být private, ne package-protected.

Jak přijde na testy a debugování, nebo práci se špatně napsaným kódem (viz ten Asm), řada jinak užitečných nebo tolerovatelných vlastností Javy je ryze kontraproduktivní.

Pokud jde o mně – volil bych první příklad, tj. jednu třídu s pár metodami a ty si otestoval odděleně. Vůči většině chyb je to odolné (bubble sort řadí, quick sort řadí, ta složená metoda taky řadí, stěrače stírají), a pokud má smysl nějaký další test, tak je to test výkonnostní – testovat, jestli se použije ten či onen algoritmus není zdaleka tak významné jako jestli to splňuje požadovaná kritéria. Všechno ostatní je ztráta času.

[xkucf03]

Tak vytvořit třídu SortUtil se statickou metodou sort? Jak oveříš, že to instanci SmartSorter nainstancovalo se správnými argumenty, tj. že se skutečně používá bubble sort, resp. quick sort, a že to předalo správný threshold?

Vtip je v tom, že díky vhodnému návrhu dokážeš drtivou většinu kódu (a všechen netriviální kód) otestovat.

A tu statickou metodu sice neotestuješ úplně neprůstřelně, ale je natolik jednoduchá, aby se s tím dalo žít. Ty složité věci jsme izolovali do tříd, které se testovat dají. Tu statickou metodu otestuješ s pár reprezentativními hodnotami a kdyby náhodou došlo ke změně konstanty a nějaká větev se zde přestala testovat, tak se ti to projeví na statistice pokrytí kódu. Na to tě může upozornit CI, že se zhoršilo pokrytí někde, kde dřív bylo 100%.

[ehm]

On ten návrh taky musí reflektovat celkové požadavky a předpoklady. Ten druhý přístup je jako vyšitý z učebnice OOP a může mít svoje opodstatnění, ale zrovna implementace jednoduchého třídícího algoritmu to skoro určitě není.

Kontrakt té metody sort je seřadit dané pole. Měla by změna používaných algoritmů vést k selhání testů? Jaký to má smysl?

Pokud je požadavkem, že to má řadit, tak testy mají otestovat, že to řadí. Pokud je požadavkem, aby to bylo rychlé, tak testy mají otestovat, že je to dostatečně rychlé.

Aby ti ten test prolezl všechny větve, asi budeš potřebovat znát tu konstantu – ta diskuze se původně odpíchla od toho, že když ta konstanta bude privátní, tak se k ní nedostaneš.

Je tam riziko, že někdo přijde, přímo do kódu napíše nějaký magic number (aniž by použil tu nadefinovanou konstantu) a rázem to všechny vetvě procházet nebude. Ale tam by asi opravdu lepším řešením bylo sledovat test coverage, jak jsi zmiňoval, než kvůli tomu vymýšlet takovéhle maškarády.

[kralyk z abclinuxu]

On ten návrh taky musí reflektovat celkové požadavky a předpoklady. Ten druhý přístup je jako vyšitý z učebnice OOP a může mít svoje opodstatnění, ale zrovna implementace jednoduchého třídícího algoritmu to skoro určitě není.

Přesně tak. +100. Nevím, proč to jsou právě javovští programátoři, kteří mají takhle fanatický přístup. Asi špatná výuka, která klade příliš velký důraz na návrh. Ten problém je hlavně v tom, že se vezme učebnicová poučka nebo nějaké velmi teoretické pravidlo pro design a aplikují se hlava nehlava na úplně všechno. Přitom je často dobré se zamyslet čistě selským rozumem, jestli to vůbec dává smysl.

Všiml si vůbec někdo, že v tom druhém kódu došlo ke změně od jednoho statického volání statické metody na dvě virtuální volání member funkcí (když chci seřadit pole)? Ví někdo z přítomných javistů, jak moc je/není java kompilátor schopen tohle odoptimalizovat? Pokud ne, je dost možné, že overhead toho rasově čistého API pohřbí ty původní benefity používání bubblesortu pro krátká pole.

[deda.jabko]

Ví někdo z přítomných javistů, jak moc je/není java kompilátor schopen tohle odoptimalizovat?

A proto buh stvoril vyssi programovaci jazyky, aby programatori nemuseli resit, jak je co prelozeno do strojoveho kodu. Sorry jako, ale jestli chces resit takove detaily, tak se vykasli na Javu a dalsi vyssi programovaci jazyky, protoze ty maji trosku jiny ucel nez davat programatorovi pocit, ze vi, jak bude z pracovana kazda operace. (A vlastne dnes i u prekladacu C je hodne tezke odhadnout, co z prekladace vyleze.)

[pavlix]

Java je zase natolik náročná, že je javovské programy často nutné extrémně optimalizovat, aby vůbec běžely na současném hardware. A odrazovat lidi od vyšších programovacích jazyků jen proto, že někdy řeší optimalizaci, je docela nesmysl. Programovací jazyky jsou jenom nástroje. Chápu, že java patří mezi nástroje, kolem kterých se vytváří carco cult, ale to je problém těch kterých lidí.

[deda.jabko]

Java je zase natolik náročná, že je javovské programy často nutné extrémně optimalizovat, aby vůbec běžely na současném hardware

Jsou dve moznosti. Bud lzes (nebo nevis, co mluvis) nebo zijes v minulem stoleti.

Jen pro zajimavost. Nedavno jsem implementoval jeden algoritmus pro analyzu dat, nejdriv jako prototyp v Jave (zadne velke optimalizace) a pak jsem to prepsal do C a tesil se jak to bude 10x rychlejsi. Bez zapojeni JIT prekladu byl javovsky kod cca 2x pomalejsi. Kdyz dostal cas, aby se projevil JIT prekladac, tak uz se to 100% zpomaleni stahlo na jednotky procent.

A odrazovat lidi od vyšších programovacích jazyků jen proto, že někdy řeší optimalizaci

Ja neodrazuji lidi od vyssich programovacich jazyku, ale od uvah, ze kdyz udelam tohle a tohle, prekladac udela tohle a tohle. Ma to nekolik duvodu. Jednak vyssi jazyky jsou tu forma abstrakce, ktera ma z principu odstinit programatora od technickych a implementacnich detailu. Za druhe, i kdyz programator tusi, jaky z toho vyleze kod, je tato informace zavadejici, protoze jsou dalsi faktory, ktere zasadnim zpusobem ovlivnuji beh programu, ktere programator neovlivni, ooo provadeni instrukci, vyuziti cache, atd.

[xkucf03]

+1

Ono poměrně dost softwaru, kde záleží na výkonu a zpracovávají se velká data, se dneska píše právě v Javě – viz třeba Hadoop nebo Apache Kafka.

[smazáno]

tak minimalne hadoop je pripad throw more hardware at it!

[xkucf03]

V těch objemech, na které se to používáš, jiná možnost ani není, než to rozložit na spoustu serverů.

[smazáno]

samozrejme ... myslel jsem to tak ze hadoop je, kdyz uz, argument pro skalovatelnost, ne performance

[smazáno]

On i ten android ART je hrozne pomaly a to se snazi z javy vytlacit vic nez maximum .. do znacne miry je to dano tim ze v java kodu mas nad sebou 100 abstrakcnich vrstev .. a premyslis jakou abstrakci tam pridat. Staci si i na nejnovejsim mobilu s androidem otevrit nejakou aplikaci (klidne core, napr. kontakty, sms) kdyz neni nactena v ramce - a trva to klidne *sekundu* nez se pusti, ze.

Android davam schvalne jako pripad jako superoptimalizovane javy.

[deda.jabko]

do znacne miry je to dano tim ze v java kodu mas nad sebou 100 abstrakcnich vrstev

Ale to neni problem Javy ani jako jazyka, ani jako platformy, ale jejiho konkretniho pouziti, v tvem pripade implmentaci Android SDK.

[JS1]

Java je zase natolik náročná, že je javovské programy často nutné extrémně optimalizovat, aby vůbec běžely na současném hardware

Jsou dve moznosti. Bud lzes (nebo nevis, co mluvis) nebo zijes v minulem stoleti.

Nejsem Javista, ale osobne si myslim, ze ta "pomalost Javy" existuje (jde o realny fenomen), ale je temer vyhradne dana pametovym modelem. Spousta malych objektu rozhazenych ruzne po pameti (absence hodnotoveho typu), 64-bit neprime pointery, asynchronni GC.. Proste jako kdyby to bylo vybrane z prirucky "Jak si zabit CPU cache". Takze to na mnoha ucebnicovych prikladech nepoznas.

[kralyk z abclinuxu]

Spousta malych objektu rozhazenych ruzne po pameti (absence hodnotoveho typu)

+1, imho to je hlavní problém, pak z toho plyne absence POD typů a nemožnost ukládat primitivní a POD typy do kolekcí. Dále nepodpora přímé kompozice objektů, pouze přes referenci (která navíc musí být nullovatelná, i když to v daném případě použití třeba nedává smysl / není validní stav).

[deda.jabko]

Ano, je tam spousta takovych neprijemnosti, ale neni tam potreba nic extremne optimalizovat. Hromada tech historek o pomalosti prameni ze zkusenosti s javovskymi desktopovymi aplikacemi, ktere jsou napsane ve Swingu, ktere opravdu rychlosti moc neoslinovaly, protoze cely toolkit byl taky napsany v Jave a desktopove aplikace nedaly moc prilezitosti JIT prekladaci ukazat, co umi. Co se tyce rychlosti obcas jsem mile prekvapeny, co na ciste algoritmickych ulohach Java dokaze.

[kralyk z abclinuxu]

Sorry jako, ale jestli chces resit takove detaily, tak se vykasli na Javu a dalsi vyssi programovaci jazyky

Však taky můj kód není v Javě. Jenže problém diskusí o návrhu programů se skalními javisty je, že ať už se mluví o jakémkoli jazyku nebo programování obecně, diskuse je stejně ve skutečnosti o Javě.

[deda.jabko]

Jenže problém diskusí o návrhu programů se skalními javisty je, že ať už se mluví o jakémkoli jazyku nebo programování obecně, diskuse je stejně ve skutečnosti o Javě.

Problem je, ze jeden mluvite o koze a druhy o voze. Lidi, co programuji v Jave maji casto nastavene jinak priority. Udrzovatelnost, rozsiritelnost, srozumitelnost, raketoplanovitost predevsim. Ceckari se zase vyzivaji v rychlosti a setreni kazdeho bitu. Kazde ma svoje opodstatneni. Ale je pruser kdyz se jeden snazi svuj mindset nacpat druhemu. Jako tady prave predvadite v teto diskuzi.

[Bystroushaak]

raketoplanovitost

Co je to raketoplanovitost?

[deda.jabko]

Sam uplne nevim, jestli je to vic hyperbola ci metafora.

[melkors]

Spadne to jednou za X let a pak to pohrbi vsechny primo zucastnene

[Bystroushaak]

Já myslel že je to byla narážka na překomplikovanost a složitost, kde raketoplány měly něco kolem 2.5 milionů pohyblivých částí. Java s tendencí budovat abstrakci nad abstrakcí abstrakce často končí podobně, jen s tím rozdílem, že se nikdo nevyzná co to vlastně dělá pod kapotou a lidi jsou na to pyšní.

[ehm]

Příklad? Thx.

[Bystroushaak]

Příklad máš přímo tady v diskuzi o kus výš v tomhle threadu, kde se začnou výmýšlet továrny a fasády na vcelku primitivní problém. Dál v diskuzi se lidi dokonce aktivně zděsí, že bych třeba chtěl vědět, jak moc optimálně se to zkompiluje a co z toho vyleze.

[ehm]

Příklad máš přímo tady v diskuzi o kus výš v tomhle threadu, kde se začnou výmýšlet továrny a fasády na vcelku primitivní problém.

Továrna tam nebyla žádná. Rozdíl je především v tom, že v tom druhém řešení je to rozdělené do více tříd.

Dál v diskuzi se lidi dokonce aktivně zděsí, že bych třeba chtěl vědět, jak moc optimálně se to zkompiluje a co z toho vyleze.

Což se děsí naprosto oprávněně, protože měnit návrhové vzory tak, aby se ušetřilo jedno volání metody, je naprosto nesmyslná mikrooptimalizace.

Ale samozřejmě je to opět specifické čistě pro Javu, protože dalších high-level jazyků se případný overengineering netýká a všichni tam píší naprosto ukázkově a soudně.

[Bystroushaak]

Továrna tam nebyla žádná.

Reagoval jsem spíš na část komentáře:

Celé tohle „soustrojí“ si můžeš buď sestavit na míru aktuálním potřebám nebo si nějakou typickou konfiguraci instanciuješ předem a uložíš si ji (resp. udělá to autor knihovny) do globální proměnné (pokud jsou ty instance vícevláknově bezpečné, tak to není problém) nebo si na to uděláš továrnu nebo nějakou fasádu. Takže základní použití je pak jen o tom napsat něco jako x.y.sort(…) nebo spíš sort(…) podle toho, co si naimportuješ.

než na kód.

Což se děsí naprosto oprávněně, protože měnit návrhové vzory tak, aby se ušetřilo jedno volání metody, je naprosto nesmyslná mikrooptimalizace.

V běžném kódu by to skutečně byla nesmyslná optimalizace na úkor přehlednosti, ale zrovna v případě performance critical kódu na sortování.. Tam víš, že bude bottleneck ať chceš, nebo ne, protože prostě vždycky je.

Ale samozřejmě je to opět specifické čistě pro Javu, protože dalších high-level jazyků se případný overengineering netýká a všichni tam píší naprosto ukázkově a soudně.

Hehe. V pythonu se běžně říká, že [někdo] javí do kódu, že je v kódu najaveno, nebo že ten kód je zakuklená java. Proč asi ;)

Asi bych tu mohl napsat něco o té parodii na objektové programování, které java převzala a o kterém si lidi často myslí, že je to vrchol abstrakce, přitom je to zkryplený, špatně pochopený smalltalk bez bloků a většiny dynamičnosti, kterému někdo ustřelil koule a jednu nohu a pak ho tloukl kladivem tak dlouho, až se trochu podobal C++, ale asi se mi nechce rozpoutávat flame tímhle směrem. Už jsem takový párkrát vedl a nikam to nevedlo.

[ehm]

Reagoval jsem spíš na část komentáře: [...]

S xkucf03 v téhle diskuzi nesouhlasím.

V běžném kódu by to skutečně byla nesmyslná optimalizace na úkor přehlednosti, ale zrovna v případě performance critical kódu na sortování.. Tam víš, že bude bottleneck ať chceš, nebo ne, protože prostě vždycky je.

Muselo by se to změřit. Pokud se to volá hodně často, tak má smysl to optimalizovat.

Mám v Javě napsaný třeba load balancer (+ tam je nějaká dodatečná logika), který běží na 2 strojích (1 jádro, 1 GB RAM) a obsluhuje tisíce requestů za minutu. Podobné optimalizace tam vůbec neřeším. Tak jako tak to poběží na dvou strojích, aby to bylo kryté proti výpadku. Mnohem víc jsem se bál, že to bude zdržovat čekání na Redis (po síti), ale taky se to neděje.

V pythonu se běžně říká, že [někdo] javí do kódu, že je v kódu najaveno, nebo že ten kód je zakuklená java. Proč asi ;)

Každý jazyk nabízí jiné prostředky a existuje tam jiný konsenzus, jak má vypadat správně napsaný kód. „You can write FORTRAN in any language.“ Opět to není specifické pro Javu.

[Bystroushaak]

S xkucf03 v téhle diskuzi nesouhlasím.

¯\_(ツ)_/¯

Já to taky nepsal tobě, ale obecně.

Muselo by se to změřit. Pokud se to volá hodně často, tak má smysl to optimalizovat.

Určitě. Jako já sám jsem proti předčasným optimalizacím, ale zrovna v případě sortu? Jako .. co na tom bude za překvapení, že to chceš napsat co nejoptimálněji?

Každý jazyk nabízí jiné prostředky a existuje tam jiný konsenzus, jak má vypadat správně napsaný kód. „You can write FORTRAN in any language.“ Opět to není specifické pro Javu.

To není o jazyku, je to o (sub)kultuře.

[xkucf03]

Jako já sám jsem proti předčasným optimalizacím, ale zrovna v případě sortu? Jako .. co na tom bude za překvapení, že to chceš napsat co nejoptimálněji?

I kdybych rezignoval na návrhové vzory a OOP, tak bych udělal prostě knihovnu (sadu) funkcí, kde by byly funkce pro různé algoritmy a kdokoli by si mohl kterýkoli vybrat a použít (byly by veřejné) a k tomu by byla jedna „chytrá“ funkce, která by vybírala vhodný algoritmus sama. Otestuješ to úplně v pohodě a kromě jednotkových testů to můžeš použít i pro výkonnostní testy a hezky si porovnat, jak je který algoritmus rychlý pro který počet prvků. Skrývat dva algoritmy před ostatními a zpřístupnit jen nějakou zastřešující fasádu je podle mého návrhová chyba v jakémkoli paradigmatu (ať už objektovém, funkcionálním nebo jiném).

[kralyk z abclinuxu]

Což se děsí naprosto oprávněně, protože měnit návrhové vzory tak, aby se ušetřilo jedno volání metody, je naprosto nesmyslná mikrooptimalizace.

Mikrooptimalizace byla nejspíše po napasování na kontext Javy už ta původní premisa s bubblesortem, takže jsem se na to ptal s tím, že porovnáváme dvě mikrooptimalizace a víceméně jen ze zvědavosti.

Jinak si ale mysím, že všeobecně má smysl na tohle poukazovat. Tohle byla samozřejmě jedna bezvýznamná funkce, nicméně pokud běžný Java programátor napíše každou takovouhle blbost tak, že spotřebuje zbytečně kdovíkolikrát více paměti a zbytečných dynamic dispatchů, pak se nelze divit, že Javový software tolik žere hardware prostředky.

(Naproti tomu třeba v C/C++ je pravděpodobně záhodno motivovat obráceným směrem )

[xkucf03]

běžný Java programátor napíše každou takovouhle blbost tak, že spotřebuje zbytečně kdovíkolikrát více paměti a zbytečných dynamic dispatchů, pak se nelze divit, že Javový software tolik žere hardware prostředky

Píšu v Javě už pěkných pár let (telekomunikace, bankovnictví) a můžu říct, že tohle opravdu není problém. Reálné problémy reálných týmů jsou někde úplně jinde… Primárně je to chybovost a odlišnost oproti zadání. V širším smyslu jsou to i problémy s analýzou, zadáním a spoluprací mezi lidmi a dalšími týmy (to už se týká obecně vývoje softwaru, ne Javy). A i když jde o výkon, tak bývá úzké hrdlo někde jinde než v Javě – i kdybys místo pěti metod jich volal dvacet a měl tam dvakrát tolik tříd/rozhraní, tak to nebude mít zásadní vliv a stejně tak na druhou stranu: mikro-optimalizacemi javovského kódu to nespasíš, nedosáhneš požadovaných časů. Optimalizace většinou spočívá ve změně logiky/zadání a lepší práci s daty (opět na úrovni logiky/zadání, ne na nějaké mikro-úrovni proměnných a metod). A nejčastěji (když je tam databáze) tak jde o optimalizaci dotazů + indexy + případně změnu datového modelu.

Jedna z důležitých věcí, co by se měl vývojář naučit (typicky na VŠ), je, kolik co řádově trvá. Pak víš, že i kdybys určitou oblast optimalizoval až na dřeň, ušetříš maximálně X. A pokud potřebuješ ušetřit 10X, tak ti bude jasné, že tuhle oblast ani nemusíš řešit a zaměříš se rovnou na něco jiného, kde těch požadovaných výsledků dosáhnout můžeš. Tzn. vždy hledat úzké hrdlo a neztrácet čas nesmysly.

[kralyk z abclinuxu]

Píšu v Javě už pěkných pár let (telekomunikace, bankovnictví) a můžu říct, že tohle opravdu není problém. Reálné problémy reálných týmů jsou někde úplně jinde…

Jo jo, kdybych dostal desetikačku pokaždé, když jsem od někoho slyšel něco jako "Přešli jsme na Javu, docela to jde, akorát jsme museli dokoupit RAM..." tak už jsem si mohl něco hezkého koupit

Optimalizace většinou spočívá ve změně logiky/zadání a lepší práci s daty (opět na úrovni logiky/zadání, ne na nějaké mikro-úrovni proměnných a metod). A nejčastěji (když je tam databáze) tak jde o optimalizaci dotazů + indexy + případně změnu datového modelu.

Řešili jsme jednu blbou sortovací funkci. Cos čekal jiného než mikrooptimalizace? Kde mam podle tebe na tak primitivním příkladu najít bottleneck, který nebude totální mikrooptimalizace?

Jedna z důležitých věcí, co by se měl vývojář naučit (typicky na VŠ), je, kolik co řádově trvá. Pak víš, že i kdybys určitou oblast optimalizoval až na dřeň, ušetříš maximálně X. A pokud potřebuješ ušetřit 10X, tak ti bude jasné, že tuhle oblast ani nemusíš řešit a zaměříš se rovnou na něco jiného, kde těch požadovaných výsledků dosáhnout můžeš. Tzn. vždy hledat úzké hrdlo a neztrácet čas nesmysly.

Koukám, že tou otázkou na ten dynamic dispatch jsem si dovolil opravdu moc a už mi to nebude odpuštěno Přitom jsem se v podstatě jen zajímal o vlastnosti javac.

[ehm]

+1

[ehm]

Obojí je otázka požadavků a měření. Pokud se to řazení dělá fakt hodně často, nebo je to součást specializované knihovny, tak může dávat smysl si nějaké to volání ušetřit.

[xkucf03]

Standardní knihovna Javy je celkem hezké čtení, není to těžké na pochopení.¹ Schválně se do nějakých těch tříd v IDE proklikej a uvidíš.

Ta abstrakce tam dává dobrý smysl. Opravdu nestojím o to, abych např. s každou implementací mapy nebo seznamu musel pracovat jiným nekompatibilním způsobem.

_{[1] něco jiného bude céčkový a assemblerový kód JVM, ale to nebude jednoduché u žádného podobně mocného jazyka}

[Bystroushaak]

To nebyla narážka na to že by to bylo napsáno špatně, ale že to staví na tolika vrstvách zapouzdřené abstrakce, že lidi často vůbec nemají tušení, co se vlastně děje pod nimi. Stdlib jsem kdysi částečně četl.

[ehm]

Pořád čekám na ten příklad. Co je nějaká taková hodně zrádná abstrakce (nejlépe přímo ve standardní knihovně), u které lidi často nemají tušení, co to dělá, a je to spíš vinou návrhu než jejich nekompetencí?

[Bystroushaak]

Čekáš na něco, co nedostaneš, protože jsi mě špatně pochopil. Nepsal jsem o konkrétním případě, psal jsem o mentalitě, kde abstrakce a zapouzdření se berou jako killer feature. Například se zde vedla diskuze o final atributu, což je typická ukázka - javisti jsou naprosto posedlí specifikováním přístupových modifikátorů. Taky typické pro javu je začít stavět vzdušné zámky z patternů, aby se nějak obešel typový systém, takže vznikne ne jedna, ale většinou hned několik vrstev abstrakce i nad zcela primitivním problémem, které by v jiných jazycích nemusely být vůbec nutné, protože jsou prostě expresivnější (pozor, tím neříkám lepší, mají zase svoje mínusy). A lidi co pak chtějí používat tenhle kód vybudují další vrstvy abstrakce a většinou nemají ani tušení, jak to pod tím funguje. A když tohle vzneseš jako námitku, javisti ti řeknou, že to je přece princip zapouzdření a že už jen se zajímat o to jak co funguje v detailech je filosoficky špatně.

Samozřejmě, nechci hovořit dogmaticky, že každý javista je stejný, ale je to jasně viditelný pattern, se kterým se tak nějak setká každý, kdo stojí mimo skupinu. Sám jsem v javě dělal a jako jeden z mála lidí, co už v ní nedělají jsem jí nikdy moc nehejtoval, ten hejt jsem pochytil spíš až od ostatních a s časem :)

[ehm]

Tu diskuzi o modifikátorech jsem odstartoval já – považuju je za přešlap (v dané podobě). Ale zase – C++ používá hodně podobné modifikátory a bohatě užívané jsem je v různých kódech viděl taky. Z C++ je kromě Javy (a z té zase C#) převzalo také např. PHP. A kvůli tomu, jak moc se rozšířil JavaScript navzdory naprosto zoufalému návrhu, vznikl TypeScript, který, světe div se, opět závádí stejné modifikátory (a ještě před ním lze zmínit Dart, ale ten byl Javou docela silně inspirovaný celkově).

Sám jsem v javě dělal a jako jeden z mála lidí, co už v ní nedělají jsem jí nikdy moc nehejtoval, ten hejt jsem pochytil spíš až od ostatních a s časem :)

Whatever. Největší zločin Javy je, že není cool a wow.

[Bystroushaak]

Whatever. Největší zločin Javy je, že není cool a wow.

Ahah. Když jsem se začal učit programovat, tak jí všichni prezentovali jako cool a wow. Což teda fakt není no :D

[kralyk z abclinuxu]

Pořád čekám na ten příklad. Co je nějaká taková hodně zrádná abstrakce (nejlépe přímo ve standardní knihovně), u které lidi často nemají tušení, co to dělá, a je to spíš vinou návrhu než jejich nekompetencí?

Zkus třeba moji patičku

Btw. měl bych ji rozšířit o další jazyky, třeba C++...

[ehm]

Vedli jsme podobnou diskuzi vcelku nedávno. Proto jsem to i upřesnil na nejlépe standardní knihovnu. Těžko se bavit nad jednou třídou v monstrózním frameworku, který je často nepopulární i mezi (jinak spokojenými) javisty.

[kralyk z abclinuxu]

Chtěl jsi praktický příklad, máš praktický příklad.

Pokud opravdu trváš na standardní knihovně, klasický případ je java.util.Date + Calendar + časová pásma. Takový prasopes se jen tak nevidí.

Jinak mi přijde standardní knihovna ok, alespoň co si vybavuju.

[ehm]

Tohle mě shodou náhod napadlo taky. Ale zrovna tohle API se v Javě 8 dost měnilo (resp. přidalo se nové).

[kralyk z abclinuxu]

Ta abstrakce tam dává dobrý smysl. Opravdu nestojím o to, abych např. s každou implementací mapy nebo seznamu musel pracovat jiným nekompatibilním způsobem.

Tak zrovna v tomhle ohledu není IMHO Java žádnou výjimkou mezi jazyky.

[kralyk z abclinuxu]

Problem je, ze jeden mluvite o koze a druhy o voze. Lidi, co programuji v Jave maji casto nastavene jinak priority. Udrzovatelnost, rozsiritelnost, srozumitelnost, raketoplanovitost predevsim. Ceckari se zase vyzivaji v rychlosti a setreni kazdeho bitu.

Ta optimalizace byla ale v tom příkladu naprosto vedlejší, to byl jen příklad, šlo tam o to, jak nejlépe napsat testy tak, aby bylo pokrytí co největší. Já doufám, že se alespoň shodneme na tom, že řada věcí - algoritmy, kontejnery atd. - mají nějaké svoje vnitřní implementační detaily, které můžou způsobovat i celkem rozsáhlé větvení.

Otázkou bylo, jestli povolit testu používat implementační detaily. Franta (stejně jako spousta dalších lidí, se kterými už jsem se na to téma dohadoval) si zřejmě někde v učebnici o rasově čistém návrhu přečetli, že blackbox testing = klaďas - chválit a prosazovat, zatímco whitebox testing = záporák - odstranit, zničit, exterminovat. Přitom ale v případě těhle struktur celkem nevidim důvod, proč nedoplnit blackbox testy i nějakými whitebox testy za účelem spolehlivého dosažení code coverage. Přijde mi, že když to člověk neudělá, tak buď musí nechat implementační detaily vyhřeznout do API (jako v příkladu výše), nebo se snažit v unit testech za pomocí code coverage reportingu hádat vstupní data tak, aby testovala co možná všechno, což mi ale přijde úplně stejné jako mít přístup k interním věcem, akorát ty informace prosáknou oklikou přes code coverage reporty :)

Na tu cenu toho dynamic dispatche jsem se ptal víceméně jen ze zvědavosti.

[deda.jabko]

Mne prijde, ze se tu snazis za kazdou cenu vytvorit falesne dilema.

Blackbox testing se ti hodi, pokud chces testovat ciste proti nejake specifikaci. Pokud ale zaroven chces testovat na pokryti kodu, musis mit ten kod k dispozici, takze posun k white box testing neni nic divneho.

buď musí nechat implementační detaily vyhřeznout do API (jako v příkladu výše)

To si myslim, ze je spatne. Interni veci by mely zustat interni, protoze temer vzdy se najde blbec, ktery to k necemu pouzije a pak to nadela paseku.

nebo se snažit v unit testech za pomocí code coverage reportingu hádat vstupní data tak

Proc hadat, pokud delas code coverage a mas kod, vidis, kde se to lame.

což mi ale přijde úplně stejné jako mít přístup k interním věcem, akorát ty informace prosáknou oklikou přes code coverage reporty :)

Ne, neni, protoze tu konstantu budes pouzivat jen v testech a nemuze se stat, ze nejaky dalsi kod na tom bude zavisly.

[kralyk z abclinuxu]

Mne prijde, ze se tu snazis za kazdou cenu vytvorit falesne dilema.

Mezi čím? Já reagoval na názor, se kterým jsem se poslední dobou setkal už poněkolikáté (v této diskusi Franta v #501, že whitebox testy jsou špatné a měly by se používat pouze blackbox testy. Ta sortovací funkce měla být příklad, kdy je dobré mít whitebox testy.

Proc hadat, pokud delas code coverage a mas kod, vidis, kde se to lame.

Když se zarytě držíš přesvědčení, že whitebox testy jsou špatné, tak pro dosažení code coverage musíš v blackbox testech hádat.

Ie. přijde mi, že s tebou nejsem ve sporu. Jsem ve sporu s tím názorem, že private věci se nesmějí testovat, a když to je potřeba, tak je špatně design.

[deda.jabko]

Mezi čím?

Blackbox vs. whitebox.

tak pro dosažení code coverage musíš v blackbox testech hádat.

Tohle mi prijde z principu nonsense. Kdyz te zajima coverage musis mit i zdrojove kody, ktere chces testovat.

Ie. přijde mi, že s tebou nejsem ve sporu. Jsem ve sporu s tím názorem, že private věci se nesmějí testovat, a když to je potřeba, tak je špatně design.

Ja si taky myslim, ze explicitne testovat privatni veci by se nemelo. Svazuje to ruce pri zmene implementace. Ale nevidim nic spatneho na tom, kdyz se pri psani testu podivam, jak vypada implementace a pak podle toho upravit testy, aby pokryti bylo co nejuplnejsi. Kdyz se zmeni implementace, neni problem dopsat dalsi testy, ktere budou pokrytovat nove varianty behu.

[kralyk z abclinuxu]

Ja si taky myslim, ze explicitne testovat privatni veci by se nemelo. Svazuje to ruce pri zmene implementace.

Mohl bys rozvést, v čem je to problematické?

To, že nějaký unit test, jehož účelem je testovat implementační detaily, např. nepůjde zkompilovat po změně implementace, mi přijde spíš jako výhoda. Vývojáře to přiměje aktualizovat také testy.

[deda.jabko]

Klicove je testovat, jestli dane verejne rozhrani (chces-li kontrakt) splnuje pozadovane podminky, co se deje pod kapotou, te nemusi zajimat, protoze ve stejnem duchu ani ostatni casti programu nezajima, co se deje uvnitr, protoze zapouzdreni.

např. nepůjde zkompilovat po změně implementace, mi přijde spíš jako výhoda.

Dejme tomu, ze chces udelat nejaky refactoring. V takovem pripade musis refactorovat i testy. Coz predstavuje praci navic, a navic to predstavuje moznost zanest do upravenych testu chybu. Jinymi slovy, pridana hodnota nulova, prace navic a jeste s potencialnimi problemy.

Vývojáře to přiměje aktualizovat také testy.

Pro me je mnohem pohodlnejsi mit stale jednu sadu testu a tu pripadne rozsirovat, pokud pri zmene implementace nemam dostatecne pokryti kodu.

[kralyk z abclinuxu]

Dejme tomu, ze chces udelat nejaky refactoring. V takovem pripade musis refactorovat i testy. Coz predstavuje praci navic, a navic to predstavuje moznost zanest do upravenych testu chybu. Jinymi slovy, pridana hodnota nulova, prace navic a jeste s potencialnimi problemy.

Přidaná hodnota je lokalita těch těstů - typicky to bude jedna dvě malé unit test funkce na pár krátkých řádků. Důvod, proř je píšu, je, že prostě chci vědět, jestli kód, který jsem právě napsal, funguje. Pokud zjistím, že ne, nejspíše se to bude snáz debugovat, protože se tesetuje jen ta nejmenší možná část.

Nepřijde mi to náročnější než muset pokaždé pouštět testy vnějšího API a u toho diffovat někde code coverage oproti předchozímu stavu. To je něco, co chci udělat až nakonec, kdy jsem víceméně hotov s nějakou jednotkou.

Pokud by přítomnost takovejch testů někomu opravdu nějak vadila, klidně se můžou i vyhodit po dokončení té jednotky, pokud tim neklesne code coverage...

[deda.jabko]

Důvod, proř je píšu, je, že prostě chci vědět, jestli kód, který jsem právě napsal, funguje.

Ok, pis si je, kdyz ti to pomaha. Mne zase prijde otravne, kdyz menim vnitrni implementaci, treba menim pocet parametru, nazvy, atp., ze to musim opravovat nejen v kodu, ale i v testech. IMHO testy by tu mely byt, aby usetrily praci, ne ji pridavaly.

Nepřijde mi to náročnější než muset pokaždé pouštět testy vnějšího API a u toho diffovat někde code coverage oproti předchozímu stavu.

Jak diffovat code coverage? Spustim testy s code coverage a IDE mi ukaze, ktere radky jsou pokryte, vizualni kontrola na pul sekundy. Pokud novy kod neni pokryty, dopisu test.

Pokud by přítomnost takovejch testů někomu opravdu nějak vadila, klidně se můžou i vyhodit po dokončení té jednotky, pokud tim neklesne code coverage...

Nevim, jak ty, ja se chci testama zabyvat co nejmin. Tj. jednou je napsat a dal je nechat overovat, jestli je program OK, nechci je resit, vic nez je potreba.

[kralyk z abclinuxu]

Mne zase prijde otravne, kdyz menim vnitrni implementaci, treba menim pocet parametru, nazvy, atp., ze to musim opravovat nejen v kodu, ale i v testech.

V příkladech výše to byly spíše jednotlivosti / střípky, které importuju z privátního API, rozhodně ne celé private API. Kromě toho, pokud tě při refaktoringu opravdu otravuje nějaký test a nechceš ho aktualizovat, tak ho prostě vyhodíš, je slušná šance, že code coverage neklesne, pokud jsou dostatečné blackbox testy.

Jak diffovat code coverage? Spustim testy s code coverage a IDE mi ukaze, ktere radky jsou pokryte, vizualni kontrola na pul sekundy.

To funguje dobře v případě, že code coverage byl před refactoringem 100%.

Nevim, jak ty, ja se chci testama zabyvat co nejmin. Tj. jednou je napsat a dal je nechat overovat, jestli je program OK, nechci je resit, vic nez je potreba.

Nevim jak ty, mě zajímá především, jestli kód, který jsem napsal, funguje. Když to pohodlně zjistí existující testy, OK. Když je potřeba napsat nové, napíšu nové, klidně kraťoučkou funkci, která používá private konstantu. Klidně se později může přetvořit v nějaký více big-picture test, který tu privátní konstantu nepoužívá. Anebo se big-picture test vytvoří zvlášť. Přijde mi to jedno. Hlavní je, abych si ověřil, že nepíšu blbost.

Vyčetl jsi mi, že vytvářím falešné dilema mezi těmi druhy testů. Přijde mi, že ho vytváříš ty.

[deda.jabko]

pokud tě při refaktoringu opravdu otravuje nějaký test a nechceš ho aktualizovat, tak ho prostě vyhodíš

Tudis vyhodis predchozi praci.

To funguje dobře v případě, že code coverage byl před refactoringem 100%.

To je blbost, funguje to obecne. V C i Jave.

Nevim jak ty, mě zajímá především, jestli kód, který jsem napsal, funguje.

Vsak to se nevylucuje.

Když je potřeba napsat nové, napíšu nové

S tim nemam problem, to je samozrejmy pristup. Problem mam s tim, ze tam pridavas jeste dalsi dve varianty, co je potreba delat pri zmene implementace -- odstraneni testu a nutna zmena testu, aby odpovidala novemu kodu. To je ta zbytecna prace navic, ktera mi vadi, kdyz se testuji interni zalezitosti.

Vyčetl jsi mi, že vytvářím falešné dilema mezi těmi druhy testů. Přijde mi, že ho vytváříš ty.

Nevytvarim. Ty porad rozlisujes nejake whitebox/blacbox + code coverage.

[kralyk z abclinuxu]

Tudis vyhodis predchozi praci.

Nebavíme se náhodou o refaktoringu???

Jinak obecně mi nepřijde škoda ani když ověřím funkcionalitu kódu, který jsem právě napsal, čistě throwaway kódem, je-li to potřeba...

To je blbost, funguje to obecne. V C i Jave.

Dejme tomu, že zasahuješ do nějakých vnitřností a pak si pustíš testy. V testech vidíš, že nějaká funkce někde kus vedle není pokryta. Pokud pokrytí nebylo před změnami 100%, jak odlišíš, jestli ta funkce nebyla pokrytá už předtím, nebo jestli byla a tvoje změny můžou za to, že teď není?

Nevytvarim. Ty porad rozlisujes nejake whitebox/blacbox + code coverage.

Já mám naopak tendenci to nerozlišovat, rozlišují to lidé, kteří prosazují názor, že se nemají v testech používat private položky (konstanty, funkce).

[deda.jabko]

Nebavíme se náhodou o refaktoringu???

Ano, ale i tak mi prijde zbytecne vyhazovat kod, kdyz ten test sel udelat uz od zacatku poradne a mohl dal dobre slouzit

Pokud pokrytí nebylo před změnami 100%, jak odlišíš, jestli ta funkce nebyla pokrytá už předtím, nebo jestli byla a tvoje změny můžou za to, že teď není?

Vytvaris tu problem, ktery neexistuje. Proste vidis nepokryte radky, tak dopises testy tak, aby byly pokryte vsechny. Jestli nebyly pokryte pred tim nebo potom v tom nehraje roli.

Já mám naopak tendenci to nerozlišovat,

V tom pripade to nerozlisuj, coz si myslim, ze je spravne. Ale zaroven si nemyslim, ze je spravne jakkoliv zpristupnovat soukrome polozky, protoze se vzdycky najde blbec, ktery nejak pouzije a udela ti z toho de facto verejne polozky, jak uz jsem rikal vyse.

[kralyk z abclinuxu]

Ano, ale i tak mi prijde zbytecne vyhazovat kod, kdyz ten test sel udelat uz od zacatku poradne a mohl dal dobre slouzit

To mi přijde jako řešení prkotiny (zejména pokud "pořádné" testy stejně tak jako tak existují), ale ok, je to věc názoru.

Vytvaris tu problem, ktery neexistuje. Proste vidis nepokryte radky, tak dopises testy tak, aby byly pokryte vsechny.

Ok, poopravím tedy předchozí tvrzení: To funguje dobře v případě, že code coverage je po refactoringu 100%.

Jakmile tohle neplatí, nemáš jistotu, že jsi nezhoršil coverage, pokud neporovnáš. Což by ale IDE technicky vzato mohlo taky automatizovat, celkem nevidim důvod, proč ne. Nevim ale, jestli to v praxi tak funguje... V každém případě to bude umět CI, ale tím se postupně oddaluje odhalení problému a zhoršuje lokalita.

Ale zaroven si nemyslim, ze je spravne jakkoliv zpristupnovat soukrome polozky, protoze se vzdycky najde blbec, ktery nejak pouzije a udela ti z toho de facto verejne polozky, jak uz jsem rikal vyse.

V mém případě jsou ty soukromé položky zpřístupněné jen unit testům, nejsou přístupné uživateli knihovny.

[deda.jabko]

Jakmile tohle neplatí, nemáš jistotu, že jsi nezhoršil coverage, pokud neporovnáš

To jsi mohl rict rovnou, ze se v tom chces hnipat z teoretickeho uhlu pohledu. Realne, co se tu snazis popsat, opravdu neni problem.

[kralyk z abclinuxu]

Mně zas přijde jako teoretické hnípání zakazovat unit testům přístup k private konstantám apod.

Ale hlavně řešíme každý trochu jinou situaci - ty řešíš relativně drobný refactoring déle existující codebase, já (v tomto případě) spíš řeším psaní nové netriviální části/modulu nebo i zcela nové knihovny, kde testy třeba vůbec nejsou nebo jsou napůl a kde si třeba chci vyzkoušet různé přístupy a počítám s tím, že část kódu vyhodim (ať už vlastní kód nebo testy).

[xkucf03]

Mně zas přijde jako teoretické hnípání zakazovat unit testům přístup k private konstantám apod.

Nad JVM běží spousta jazyků – klidně si testy můžeš psát v něčem jiném, jestli chceš. Ale nevidím důvod proč kvůli velmi specifické potřebě pár lidí kazit Javu všem ostatním a zbavovat jazyk silné podpory zapouzdření a bezpečnosti.

[kralyk z abclinuxu]

???

1. Můj kód není v Javě
2. V Javě by ale klidně být mohl a nebylo by potřeba na Javě nic měnit, prostě bych na pár drobností použil package-protected místo private stejně jako to dělá kolega "ehm". Kazí tím Javu?
3. Nikdo tady nikomu Javu nekazí. (Napadá mě sarkastická otázka, co by se ještě dalo na Javě zkazit. Odebrat generika coby pokus přetáhnout Gophery zpět k Javě?)
4. Bezpečnost je v Javě velmi základní, jak ví kdokoli se zkušeností s vymakanějším type systémem. Pokud ti ale připadá, že nějak kazim bezpečnost v Javě nebo něco takového, bylo by fajn poskytnout odpovědi s konkretními a praktickými důvody, proč je něco špatně. Pouhé zopakování učebnicové poučky ve stylu Drugs are bad, mmmkay mi přijde úplně k ničemu.

[xkucf03]

Můj komentář se týkal toho, jak se tu někteří navážejí do private nebo final a nejradši by tahle, podle nich asi zbytečná, omezení z jazyka odstranili, aby tam šlo prasit jako v nejmenovaném dynamickém jazyce.

[Bystroushaak]

jak se tu někteří navážejí do private nebo final a nejradši by tahle, podle nich asi zbytečná, omezení z jazyka odstranili, aby tam šlo prasit jako v nejmenovaném dynamickém jazyce.

Díky za precizní ukázku přesně toho, na co jsem narážel.

[xkucf03]

Sorry, ale pokud překračuješ private nebo protected modifikátory, které nastavil (byť třeba formou jmenné konvence) autor kódu, tak to nic jiného než prasení není. Stejně tak když ta běhu přepisuješ konstantu (final), od které ostatní očekávají, že bude neměnná – to mívá dost nepěkné a nepředvídatelné následky, které se špatně ladí.

[ehm]

V produkčním kódu je to prasení, ale občas se tomu vyhnout nelze. V testech bych to za prasení nepovažoval, pokud tu neveřejnou část chceš z nějakého důvodu otestovat (což může a nemusí dávat smysl).

[Bystroushaak]

Sorry, ale pokud překračuješ private nebo protected modifikátory, které nastavil (byť třeba formou jmenné konvence) autor kódu, tak to nic jiného než prasení není.

No, a tomu se říká dogma, které navíc předpokládá, že původní autor napsal dokonalý kód. Pokud se podíváš dovnitř do implementace a budeš chtít informovaně upravit .. eh, co to vlastně dělám, hádat se s javistou. Nope.

[pavlix]

+1

Hádáš se s dogmatikem a to fakt nemá smysl.

[ehm]

Přistupovat k neveřejným částem knihoven, třeba i informovaně, je pořád prasení (pořád; i v případech, kdy zdánlivě není jiná možnost), protože se to může změnit a ty na nekompatibilitu ani nemusíš být upozorněn. Měl by se na to alespoň doplnit test.

[Bystroushaak]

Přistupovat k neveřejným částem knihoven, třeba i informovaně, je pořád prasení (pořád; i v případech, kdy zdánlivě není jiná možnost), protože se to může změnit a ty na nekompatibilitu ani nemusíš být upozorněn. Měl by se na to alespoň doplnit test.

No, tak to spadne. Pak se budu muset sebrat a udělat to samé co při každé změně - (u/o)pravit to.

[ehm]

Rozdíl je v tom, že slušně psané knihovny se snaží držet nějakou kompatibilitu a rozhraní měnit jen mezi major verzemi. Pak se ti může stát, že narazíš na nějaký bug (v horším případě už to bude produkční verze), ale nebudeš schopný upgradovat na další setinkovou verzi, aniž bys začal tahle „informovaná rozhodnutí“ refactorovat. A vzhledem k tomu, že jsi ten hack nejspíš použil proto, že jiné řešení tam nebylo, tak teď to budeš muset vyřešit znovu nějak – ovšem s tím rozdílem, že můžeš být v mnohem větší časové tísni a najít i nějaký hack může být o dost těžší než předtím. Proto, a právě proto, je to prasení. V daný okamžik je to rychlejší cesta, která se ale v dlouhodobém horizontu může těžce nevyplatit.

[Bystroushaak]

Přijde mi to celé takové hodně teoretické a plné obav z toho, že by se něco náhodou mohlo změnit, když reálně se mění celý život úplně všechno a čekat, že to bude navždy vytesané v mramoru prostě nefunguje.

[ehm]

To jsou zkušenosti.

[Bystroushaak]

A v čem děláš, když v javě to nejde?

[ehm]

Java má reflexi a instrumentaci. Package-protected modifikátory lze na úrovni zdrojových kódů obejít přidáním vlastní třídy do daného package.

Taky jsem dělal docela dost různých upgradů nad větší codebase a dobře vím, kolik práce přidělá každá konstrukce, která spoléhá na nějaké nedokumentované chování. Zdaleka se to nemusí týkat jen přístupů k neveřejným metodám. I plánované upgrady na vyšší nekompatibilní major verze jsou kolikrát úporné a nechci se dobrovolně stavět do situace, kdy potenciálně nekompatibilní bude každý drobný upgrade. A podobné věci už jsem řešil.

[xkucf03]

No, a tomu se říká dogma, které navíc předpokládá, že původní autor napsal dokonalý kód.

Čisté řešení je dohodnout se s autorem knihovny a v mezičase používat vlastní upravenou verzi knihovny.

Prasení vede k nespolehlivosti a nepředvídatelným výsledkům. Narušuje to základní principy a předpoklady, na které se lidi běžně spoléhají.

Takové věci se do kódu většinou zanesou s omluvou: „teď nestíháme, ale až bude čas, tak to uděláme pořádně“ – jenže čas nebude nikdy, naopak se ti v týmu postupně vymění lidi a nová generace vývojářů zdědí sračku s ošklivým technologickým dluhem.

eh, co to vlastně dělám, hádat se s javistou. Nope.

Tohle není o Javě, ale o tom, jestli chceš vyvíjet software nebo stavět domeček z karet, který se ti může kdykoli rozsypat.

[kralyk z abclinuxu]

Sorry, ale pokud překračuješ private nebo protected modifikátory, které nastavil (byť třeba formou jmenné konvence) autor kódu, tak to nic jiného než prasení není. Stejně tak když ta běhu přepisuješ konstantu (final), od které ostatní očekávají, že bude neměnná – to mívá dost nepěkné a nepředvídatelné následky, které se špatně ladí.

Tohle je IMHO záležitost kultury / zvyklostí / naučených postupů, ne engineeringu.

Ty ze zhrozíš nad Pythonem, že se nebabrá až tolik s rozlišením public/private. Ok. Úplně stejně se ale zhrozí třeba dogmatický Haskellista nad Javou kvůli non-pure funkcím a nebude chápat, jak můžeš v noci v klidu spát s vědomím, že jakákoli funkce může mít jakýkoli side effect. Tvůj kód bude považovat za totálně nebezpečný.

Podobné příklady by se daly najít i mezi dalšími jazyky.

Doporučil bych vyzkoušet si nějaký jiný třeba něčím zajímavý jazyk včetně té kultury, nejlépe u toho zcela zapomenout na veškerou Javu (v jednom ze zápisků jsem viděl nějaký tvůj C++ kód a byla to do značné míry Java v C++.)

[xkucf03]

v jednom ze zápisků jsem viděl nějaký tvůj C++ kód a byla to do značné míry Java v C++

Tam šlo tuším o ty vnořené jmenné prostory, nad kterými se někteří zhrozili a na základě toho to odsoudili jako „Java v C++“. Ale tohle je dost povrchní pohled. Mně se prostě líbí, když mám globálně jedinečný název třídy. Ale na jmenné prostory se můžeme klidně vykašlat – důležitější byl obsah těch tříd – a k tomu žádné užitečné rady moc nebyly. Třeba jsem se tam trochu mořil s mapami, seznamy, chytrými ukazateli… a přišlo mi to strašně nepohodlné a ukecané oproti Javě. Bohužel mi tam nikdo neporadil, jak psát bezpečně a stručně/elegantně, aby se třeba s tou pitomou mapou pracovalo stejně pohodlně jako v Javě.

[kralyk z abclinuxu]

Tam šlo tuším o ty vnořené jmenné prostory, nad kterými se někteří zhrozili a na základě toho to odsoudili jako „Java v C++“. Ale tohle je dost povrchní pohled.

Ano, namespaces + adresářová struktura. Je to kravina, to souhlasim, ale nemůžeš se úplně divit, že se nad tim někdo pozastaví, protože to na první pohled každého praští do očí... Navíc v C++ to ani nemá takové opodstatnění jako v Javě (v C++ nemáš, bohužel, moduly/pacakges).

Ale na jmenné prostory se můžeme klidně vykašlat – důležitější byl obsah těch tříd – a k tomu žádné užitečné rady moc nebyly. Třeba jsem se tam trochu mořil s mapami, seznamy, chytrými ukazateli… a přišlo mi to strašně nepohodlné a ukecané oproti Javě. Bohužel mi tam nikdo neporadil, jak psát bezpečně a stručně/elegantně, aby se třeba s tou pitomou mapou pracovalo stejně pohodlně jako v Javě.

Moderní C++ je relativně ukecané co se memory managementu týče, zejména když se použijí move semantics atd. (V Javě memory management neřešíš, že.)

Co jsi měl za problém s mapama? Já jsem se po napsání ten Rust verze s C++ už nedělal mj. taky proto, že s tím Rustem by to bylo dost 1:1. Ale pro někoho, kdy tyhle jazyky až tak nezná to mapování nejspíše nebude zřejmé. Můžu se na to zkusit ještě podívat. Odpověděl bych asi kdyžtak zpátky do toho blogu, tady už jsme dost zanořený.

[xkucf03]

Odpověděl jsem v původní diskusi: #46.

[kralyk z abclinuxu]

Můj komentář se týkal toho, jak se tu někteří navážejí do private nebo final a nejradši by tahle, podle nich asi zbytečná, omezení z jazyka odstranili

Nemyslim si, že by s accessem v Javě bylo něco špatně. Na druhou stranu nemusí být špatné se podívat, jak to dělají jinde.

Třeba v Haskellu to je dané konvencí, pokud se vzpomínám, dávají interní věci do Foo.Internal, odkud si je sice můžeš technicky vzato importovat, ale je jasné, že to není public API. Ale Haskell znám opravdu jen velmi velmi zběžně, takže to ber s rezervou. Třeba někdo poopraví.

Přemýšlím, jak to mají další jazyky. Go má jednoduchý systém private a public na úrovni souborů, ale (asi aby ušetřili keywordy?) rozlišuje se to ne pomocí keywordů ale malého/velkého počátečního písmena identifikátoru. (Což mi popravdě přijde trochu úchylné.)

V Rustu je nejmenší granularita visibility modul, věci můžou být module-private, module-public, nebo (relativně nově) package-private, příp. můžeš explicitně jmenovat modul, pro který má být identifikátor viditelný (to se ale v praxi používá jen výjimečně). Krom toho funguje reexportování. Tj. je to hodně flexibilní systém, kde si to můžeš poskládat v podstatě jak chceš, vzhledem k tomu, že modul může být celý adresář (kde soubory jsou sub-moduly), jednotlivý soubor, nebo i pár řádek v jednom souboru. Nevýhoda je, že pro lidi zvyklé na tradiční model z C++/Java je tohle na začátku náročnější na strávení.

Další příklady netradičních řešení vítány, pokud si někdo na něco vzpomene.

[Bystroushaak]

Další příklady netradičních řešení vítány, pokud si někdo na něco vzpomene.

Python, který to řeší pomocí _ a __. První znamená „nesahej na to prosím, mělo by to být protected“, druhé znamená „nesahej na to prosím vážně moc, mělo by to být private“. Druhý příklad interpret optimalizuje tak, že interně přeloží názvy těch metod na _JmenoTridy__jmenoMetody:

>>> class A:
...  def _a(self):
...   pass
...  def __b(self):
...   pass
... 
>>> a = A()
>>> dir(a)
['_A__b', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
'__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_a']

Kde je možné vidět, že metoda __b() byla přeložena na _A__b(), takže k ní nemůžeš přistupovat přes původní název, ale pokud víš co děláš, tak k ní můžeš přistoupit zavoláním a._A__b(), což se dá chápat jako že říkáš „ano, fakt vím co dělám“.

Proč se mi líbí zrovna tenhle přístup? Není to proto, že bych považoval python za dokonalý jazyk, ani proto že jsem se ho učil jako první (ve skutečnosti to byl asi můj pátý jazyk). Je to proto, že nepředpokládá, že původní autor byl dokonalý a dovoluje ti na vlastní zopodvědnost dělat si co chceš, což prostě občas, sice relativně zřídka, chceš. Je to něco jako mít možnost root účtu na linuxové distribuci, kde prostě když chceš, tak můžeš klidně smazat celý systém a nic ti nestojí v cestě.

Oproti tomu mentalita javy předpokládá, že uživatel je nekompetentní idiot a že je součástí práce autora knihovny / whatever se postarat, že nedostane možnost se střelit do nohy, i kdyby se dobrovolně rozhodl spáchat sebevraždu a fakt si nutně potřeboval ustřelit nohu. Což je docela paradox, protože uživatel ten kód spouští u sebe, ne u autora a to nejhorší co se může stát je, že program prostě padne uživatelovo vinou.

[deda.jabko]

Proč se mi líbí zrovna tenhle přístup?

Prijde mi, ze nevis, co chces. Na jedne strane pozadujes i po zacatecnikovi, aby tvoril elegantni kod a na druhe strane se rozplyvas nad hackem, ktery je udelany v Pythonu a nad tim, ze umoznuje prasit.

a dovoluje ti na vlastní zopodvědnost dělat si co chceš,

Ze zkusenosi, toto je nejhorsi typ chyb, na ktere clovek muze narazit. Az budes v programech narazet na ruzne hacky, ktere udelal nekdo na svou zodpovednost (protoze prece vedel, co dela), a ktere po deseti letech prestaly fungovat, protoze se neco zmenilo (verze knihovny, operacni system, architektura procesoru), mozna zmenis nazor. Takove chyby se hodne blbe hledaji a jeste hur opravuji.

Oproti tomu mentalita javy předpokládá, že uživatel je nekompetentní idiot a že je součástí práce autora knihovny / whatever se postarat, že nedostane možnost se střelit do nohy

Evidentne jsi stale nepochopil zakladni pouziti Javy. Kod v Jave by mel byt jednoduchy a snadno kazdemu srozumitelny, a proto ma omezene vyjadrovaci schopnosti a relativne striktne dana pravidla, co je mozne a co ne. Neco jako technicke kresleni. Rozcilovat se, ze v tom nejdou delat ruzne hacky, je asi jako rozcilovat se nad tim, ze pomoci technickeho kresleni nejde namalovat Slovanska epopej.

[smazáno]

Prijde mi, ze nevis, co chces. Na jedne strane pozadujes i po zacatecnikovi, aby tvoril elegantni kod a na druhe strane se rozplyvas nad hackem, ktery je udelany v Pythonu a nad tim, ze umoznuje prasit.

To je prave ten pragmatismus. Jednou je nejlepsi pristup takovy, jindy uplne jiny.

Ze zkusenosi, toto je nejhorsi typ chyb, na ktere clovek muze narazit. Az budes v programech narazet na ruzne hacky, ktere udelal nekdo na svou zodpovednost (protoze prece vedel, co dela), a ktere po deseti letech prestaly fungovat, protoze se neco zmenilo (verze knihovny, operacni system, architektura procesoru), mozna zmenis nazor. Takove chyby se hodne blbe hledaji a jeste hur opravuji.

Myslis ze mi ty zkusenosti s resenim bugu v desitky let stare nezname codebase nemame? Proc myslis, ze na tu javu nadavame .

Evidentne jsi stale nepochopil zakladni pouziti Javy. Kod v Jave by mel byt jednoduchy a snadno kazdemu srozumitelny, a proto ma omezene vyjadrovaci schopnosti a relativne striktne dana pravidla, co je mozne a co ne. Neco jako technicke kresleni. Rozcilovat se, ze v tom nejdou delat ruzne hacky, je asi jako rozcilovat se nad tim, ze pomoci technickeho kresleni nejde namalovat Slovanska epopej.

Spis nad tim ze te pak vsichni nuti tu Slovanskou epopej v jave kreslit ...

[deda.jabko]

Ty taky nevis, co chces. Najednu stranu chces cisty elegantni kod, ve kterem se da prasit.

Chces pragmaticky prasit, a pak nadavas, ze jini to pred tebou delali taky.

Kdo jsou ti vsichni, co te nuti malovat tu Slovanskou epopej? Vsimni si, ze to ale neni problem Javy, ale tebe nebo nich, kteri chcou tu epopej v Javy.

[smazáno]

Problem Javy neni, ze existuje, ale ze se pouziva.

[xkucf03]

Spis nad tim ze te pak vsichni nuti tu Slovanskou epopej v jave kreslit ...

Zadavatel ti neříká, jak máš psát kód – zadavatel definuje byznys požadavky – jak se má program chovat navenek. Uvnitř máš jako programátor hodně volnou ruku, můžeš si dělat v podstatě, co chceš, pokud se to navenek bude chovat podle zadání. Nikdo (kromě tvých kolegů) tomu kódu nerozumí a není schopen tě kontrolovat. (nepočítám externí audity/revize kódu, to je poměrně málo časté)

A ty byznys požadavky nebývají takové, že by to nešlo napsat v Javě. Rozhodně ti nikdo nedá zadání, které by vynucovalo překračování private/protected/final modifikátorů.

[smazáno]

Ja v jave opravdu neprogramuju. Myslel jsem to obecne.

"I fear, as far as I can tell, that most undergraduate degrees in computer science these days are basically Java vocational training."

[kralyk z abclinuxu]

Kod v Jave by mel byt jednoduchy a snadno kazdemu srozumitelny,

Hm, zajímavé je, že na nesrozumitelné, překomplikované konstrukty narážím v Javě celkem běžně. Prostě se akorát ty omezené vyjadřovací schopnosti nahradily návrhovými vzory, výsledek stejný. Tím nechci říct, že v ostatních jazycích by to bylo s překomplikovaností lepší (lol C++, lol Rust).

Mimochodem, podobnou mantrou se v dnešní době zaklínají fanoušci Go, podle kterých i Java je moc překomplikovaná, protože má např. generika nebo klasické OOP. IMHO jsou podobně mimo, prostě jen nahradili jednu komplexitu za jinou (lol interface{}).

Rozcilovat se, ze v tom nejdou delat ruzne hacky

Ale vždyť v ní jdou dělat úplně stejné hacky.

Java IMHO reálně v zásadě ani nijak moc nechrání proti střílení se do nohy. Maximálně tak proti memory access bugům, ale to každý jazyk nad úrovní C/C++. Jinak standardní paleta chyb je v Javě přítomna. NullPointerException - check. Race conditions - check. Deadlocks - check. Nechtěnné side-efekty - check. Tak jakápak bezpečnost.

[deda.jabko]

překomplikované konstrukty narážím v Javě celkem běžně

Doporucuji nastudovat vyznam slov "by mel".

Java IMHO reálně v zásadě ani nijak moc nechrání proti střílení se do nohy. Maximálně tak proti memory access bugům, ale to každý jazyk nad úrovní C/C++. Jinak standardní paleta chyb je v Javě přítomna. NullPointerException - check. Race conditions - check. Deadlocks - check. Nechtěnné side-efekty - check. Tak jakápak bezpečnost.

Z diskuzi na urovni detskeho piskoviste o tom, ktery jazyk je nejlepsi uz jsem vyrostl. Takto otazka totiz vubec nestoji.

[kralyk z abclinuxu]

Doporucuji nastudovat vyznam slov "by mel".

Tak jestli "by měl" ale není, tak ten význam je dosti nulový...

Z diskuzi na urovni detskeho piskoviste o tom, ktery jazyk je nejlepsi uz jsem vyrostl. Takto otazka totiz vubec nestoji.

Wat? Tam nepadlo nic o nejlepším jazyku. (A ani kdybych chtěl, tak ze sebe nevymáčknu, který jazyk je nejlepší.)

Jen jsem tím reagoval na tu bezpečnost, kterou má údajně poskytovat zapouzdření. (Reálně to spíš je jeden velmi specifický druh bezpečnosti s tím, že jiné otázky bezpečnosti se zdaleka tak neřeší.)

[Bystroushaak]

Ze zkusenosi, toto je nejhorsi typ chyb, na ktere clovek muze narazit. Az budes v programech narazet na ruzne hacky, ktere udelal nekdo na svou zodpovednost (protoze prece vedel, co dela), a ktere po deseti letech prestaly fungovat, protoze se neco zmenilo (verze knihovny, operacni system, architektura procesoru), mozna zmenis nazor. Takove chyby se hodne blbe hledaji a jeste hur opravuji.

Ok. Takže v javě potřebuješ přistoupit k privátní metodě, protože autor knihovny třeba něco nepředpokládal. Co budeš dělat? Upravíš zdrojáky (pokud je máš), nebo celou tu metodu přepíšeš a pak se jí tam přes dědičnost pokusíš naroubovat? Nebo jaké je řešení?

[deda.jabko]

Takže v javě potřebuješ přistoupit k privátní metodě, protože autor knihovny třeba něco nepředpokládal.

Ta premisa je z principu spatna, protoze to, co je private pro me neexistuje. Co kdyz autor knihovny (treba i v setinkove verzi) zmeni chovani te metody nebo ji zrusi, co pak? Nebudes upgradovat knihovnu, budes pri kazdem upgradu hackovat pristup k te funkci. Budes se modlit aby zustala zachovana semantika? Co je nejlepsi reseni?

A co treba kdyz mas program v C a proceduru oznacenou jako static, taky se budes dozadovat pristupu k ni. A co kdyz ji prekladac vubec nazahrne do binarky? Jake je reseni?

[kralyk z abclinuxu]

Co kdyz autor knihovny (treba i v setinkove verzi) zmeni chovani te metody nebo ji zrusi, co pak?

Skončí svět? Nastane zatmění a hlubiny země vydají předpotopní netvory, kteří nemilosrdně pozřou vše živé a i neživé?

Ne.

Něco mnohem, mnohem horšího.

Softwre nebude fungovat dle specifikace a bude nutno vytvořit bugreport.

[smazáno]

Spis to nepujde zkompilovat/odchyti to testy.

Ale java neresi ani tohle (to reseni je pouze teoritecke). V praxi se bezne stava, ze vyvojar odstrani verejne metody, obcas na celou knihovnu klidne zapomene ...

[deda.jabko]

Skončí svět?

Na jednu stranu tu autor pise traktaty o tom, jak se ma hezky programovat, jak se ma udrzovat stabni kultura, jak ma byt kod elegantni a jak je dulezite code review. (S tim se da souhlasit.) A pak tady zacne vychvalovat prasarnu nejhrubsiho zrna, ktera vygeneruje absolutne krehky kod.

Softwre nebude fungovat dle specifikace a bude nutno vytvořit bugreport.

Takhle muzes bagatelizovat cokoliv.

[Bystroushaak]

A pak tady zacne vychvalovat prasarnu nejhrubsiho zrna, ktera vygeneruje absolutne krehky kod.

Tak to pozor, autor tu prasárnu nevychvaluje jako praktiku, ale jako možnost. Mimochodem, já vím, že javistům to nedochází, ale ne všechno programování jsou business grade aplikace. Často píšu věci jen pro sebe, kde je podstatný hlavně čas jak dlouho mi to bude trvat, a často taky pracuji s interaktivním režimem, kde chci mít možnosti dělat cokoliv, stejně jako chci jako root na příkazové řádce mít možnost interaktivně dělat cokoliv, i když tím můžu smazat půlku systému, když si nedám pozor.

[ehm]

[...] často taky pracuji s interaktivním režimem, kde chci mít možnosti dělat cokoliv [...]

$ groovysh
Groovy Shell (2.4.8, JVM: 1.8.0_131)
Type ':help' or ':h' for help.
-------------------------------------------------------------------------------
groovy:000> ++new ArrayList().size
===> 1

ArrayList.java#118

Dříve taktéž BeanShell:

$ bsh
BeanShell 2.0b4 - by Pat Niemeyer (pat@pat.net)
bsh % setAccessibility(true);
bsh % print(++new java.util.ArrayList().size);
1

Ten BeanShell je z roku '99, takže opravdu nic nového. Ale holt to javistům prostě nedochází.

[xkucf03]

K tomu používám debugger – pomocí něj vidím do všeho, můžu to měnit, volat metody…

[xkucf03]

A nenapadlo tě, že třeba používáš špatnou knihovnu?

Buď špatnou v tom smyslu, že je nekvalitně napsaná (pokud narážíš na takto viditelné chyby, tak tam jistě budou i jiné, které jsi zatím neobjevil, a dost možná tě to nepěkně vypeče někdy v produkci – a tam neseš celou odpovědnost ty – zákazníka nezajímá, že je chyba v externí knihovně).

Nebo špatnou v tom smyslu, že je určená k jinému účelu a na ten tvůj nebude nikdy dobře pasovat. Protože pokud ji používáš k tomu, k čemu je určená a zároveň autor není neschopný, tak bude mít nějaké řešení – třeba se to jen píše jinak, než ty předpokládáš, nebo tu chybu opraví.

[Fluttershy, yay!]

To je roztomilé, ale pokud je Java nový Cobol (ostatně, s Javou 1.5 se pořád jde snadno potkat), často není na výběr.

Tuhle jsem se potýkal s vědeckou knihovnou, kterou někdo napsal v 90. letech a od té doby na to nesáhl (už je možná taky nějaký ten pátek pod drnem), co teď s tím?

[xkucf03]

A vážně chceš stavět na mrtvém projektu, který nikdo neudržuje?

Doporučoval bych buď vybrat jinou knihovnu nebo sám převzít vývoj této – a čím dřív to uděláš, tím líp. Den, kdy se na tebe začnou valit produkční chyby, rozhodně není vhodný k tomu, aby ses začal seznamovat s cizím kódem a zjišťovat, jak se to vlastně kompiluje a jestli máš kompletní zdrojáky…

[Fluttershy, yay!]

reality check: alternativa neexistuje a vývoj samotný nikdo nezaplatí, navíc uživatelé jsou vesměs mizerní vývojáři (jsou to experti ve zcela jiné doméně).

[ehm]

V tomto případě je pravděpodobnost, že by se kód změnil, zanedbatelná. Tady je přístup do vnitřností IMO akceptovatelný. Alternativně můžeš tu knihovnu forknout alespoň neveřejně, udělat v ní nutné úpravy a dál pracovat se zkompilovaným JARem. Druhé řešení mi přijde lepší, protože v legacy codebase těch problémů dost možná bude víc.

Pokud tu knihovnu budeš mít odděleně jako samostatný projekt (což je asi lepší), tak ten zkompilovaný JAR můžeš publikovat do lokálního Maven repozítáře (tuším, že to bylo nějak mvn install a samozřejmě nastavit groupID a artifactID, ale nepamatuju si to přesně) a ve druhém projektu to přidat do závislostí. Použije se to z toho lokálního repozitáře...

[Fluttershy, yay!]

Franta reagoval na #631, uvádím reálný příklad toho, co spadá pod situaci z #631 (edit: klarifikace; ať nehnojím diskuzi opravami). Ano, libovolný způsob, jak v takové situaci pracovat s danou knihovnou, je praktičtější než konstatování, že „mám špatnou knihovnu". No, lepší nemám.

[deda.jabko]

Ano, libovolný způsob, jak v takové situaci pracovat s danou knihovnou, je praktičtější než konstatování, že „mám špatnou knihovnu".

Uz jsem se parkrat dostal do situace, kdy bylo lepsi napsat si knihovnu od zacatku a nakonec se ukazalo, ze to nebylo tak hrozne, jak se puvodne zdalo.

[Fluttershy, yay!]

Proto jsem příznivcem aspoň univerzálního základního příjmu: abych mohl biologům přepisovat jejich software. ^_^

[deda.jabko]

To by bylo hezke. Ale chce se na to divat optimisticky. Kdyz jsem pred N lety zacal delat nahradu za GNU lightning, netusil jsem, ze mi nekdo bude casem za nove funkce i platit. Mozna i biologove casem vyskrabou nejake penize. ;-]

[ehm]

Co si najít nějakého sponzora? Hint: crowdfunding.

[ehm]

Pokud si fakt nutně potřebuješ ustřelit nohu, můžeš použít tu reflexi. Ten syntactic sugar mi chybí mj. proto, že by ten zápis byl stručnější a vyhodnocoval by se staticky, ne dynamicky – tj. pokud by se změnil prototyp té metody, nešel by tvůj kód zkompilovat. To je alespoň nějaká ochrana; nepokryje to nejobtížněji odhalitelné případy (vnitřní změna chování), ale zachytí to jiný případ, kdy program už fungovat jednoznačně nemůže. V neposlední řadě jsou tam nějaké výkonostní rozdíly.

[ehm]

Reflexi můžeš použít vždy (tedy s výjimkou případů, kdy to zakazuje SecurityManager), čili nějak nevidím, jak by přidání syntaktického cukru pro umožnění přímého přístup k těm neveřejným metodám/fieldům ubíralo na zapouzdření a bezpečnosti. Se SecurityManagerem lze při návrhu počítat a zachovat ho, modifikátory jako takové taky zůstanou; s tím rozdílem, že jejich špatná volba nenapáchá takové škody.

Jen upřesním, že mluvím pouze o modifikátorech viditelnosti (zejména metod a fieldů). Nemluvím o final fieldech a už vůbec ne o final metodách nebo dokonce třídách. První zmiňované je úplná blbost a to druhé bych si musel rozmyslet; především to už ale není drobná úprava, protože dědění z final tříd zakazuje i přímo JVM (tj. není to už jen syntaktická drobnost). Z neděditelných tříd mě jako první napadá třeba java.lang.String – jsou tam nějaké mezní případy, kdy by dědění z něj vedlo k nějakým zvlášť závažným zločinům proti Javě? Nejsem si jistý...

[xkucf03]

Reflexi můžeš použít vždy (tedy s výjimkou případů, kdy to zakazuje SecurityManager), čili nějak nevidím, jak by přidání syntaktického cukru pro umožnění přímého přístup k těm neveřejným metodám/fieldům ubíralo na zapouzdření a bezpečnosti.

Ta určitá pracnost použití reflexe funguje jako celkem účinná bariéra, aby to lidi běžně nepoužívali nebo spíš nezneužívali. Když už budeš psát kód s reflexí, tak tě to spíš trkne, že děláš třeba něco špatně… a nezkušený programátor se do toho asi vůbec nepustí.

Syntaktický cukr by tuhle bariéru snížil. Což je dobře i špatně zároveň. Kdybys musel připsat nějaký speciální symbol a IDE by ti takové věci nenabízelo nebo zobrazovalo varování, tak by sis snad taky všiml, že se nacházíš v nějaké nestandardní situaci a že se máš zamyslet, jestli opravdu víš, co děláš. Svým způsobem by bylo fajn to v Javě mít. Ale na druhou stranu by to zvýšilo složitost jazyka – a já jsem rád, že Java není tak složitá jako třeba C++ nebo Perl. IMHO tedy negativa převažují – těch případů, kde by to mělo smysluplné využití je minimum.

[ehm]

Vždyť jsi mi dával odkaz na nějakou knihovnu, která to usnadňuje, a ještě jsi argumentoval, že ani když si to píšeš sám, tak to není tak hrozné. Řeč tedy sice byla o testech, kde se nějaké neošetřené výjimky apod. ztratí snáž než v produkčním kódu, ale zas takový rozdíl to taky není.

Ta striktnost mi tady fakt přijde spíš na škodu. Nějaký drobný nárůst prasení pak asi očekávat lze, ale to se nedá nic dělat.

[xkucf03]

Nevim, jak ty, ja se chci testama zabyvat co nejmin. Tj. jednou je napsat a dal je nechat overovat, jestli je program OK, nechci je resit, vic nez je potreba.

+1, to je ostatně pointa automatických testů – čím častěji je potřeba je přepisovat, tím víc ztrácejí smysl.

[xkucf03]

Mezi čím? Já reagoval na názor, se kterým jsem se poslední dobou setkal už poněkolikáté (v této diskusi Franta v #501, že whitebox testy jsou špatné a měly by se používat pouze blackbox testy.

A teď si představ, že bys dělal TDD – to bys psal nejdřív test a žádnou implementaci bys k dispozici v tu chvíli ještě neměl. ;-)

že whitebox testy jsou špatné a měly by se používat pouze blackbox testy

Nejsou špatné a běžně při psaní testu do kódu koukat můžeš. TDD je spíš výjimka, alespoň podle mé zkušenosti.

Jsem ve sporu s tím názorem, že private věci se nesmějí testovat, a když to je potřeba, tak je špatně design.

To ale není žádná jednoznačná implikace – já jsem psal o tom, že když ti nejdou napsat jednotkové testy, měl by ses zamyslet nad návrhem a dost možná dojdeš k tomu, že by šel udělat líp. Pokud si i po tom zamyšlení budeš za tím návrhem stát, tak je to v pořádku a je na místě nějak ohnout testy resp. udělat kompromis v nich.

Testování totiž není cíl – cílem je mít kvalitní software (odpovídající požadavkům). To, že tě jednotkové testy donutí se zamyslet a případně i přepracovat návrh, je jen jejich pozitivní vedlejší efekt.

Ta sortovací funkce měla být příklad, kdy je dobré mít whitebox testy.

Nemyslím si. Správná cesta je podle mého ta kompozice (odlišené algoritmy v samostatných třídách + výhybka ve třetí třídě). Nejdřív bych to tedy napsal takhle, a až pokud by režie volání metody jiného objektu byla problém, tak bych přemýšlel, jak to přepsat – jinak je to totiž předčasná optimalizace, kořen všeho zla. Rozdíl v té režii bude pravděpodobně minimální/neměřitelný, takže by to zůstalo takhle.

I kdyby ses ale rozhodl to nacpat všechno do jedné třídy, tak se to pořád ještě dá testovat. Ta třída by implementovala nějaké rozhraní a ty metody by mohly být normálně vidět. Případně ty metody můžou být protected a z testu se na ně dostaneš. A mj. to umožňuje vytvořit potomka té třídy, který bude mít jinou rozhodovací logiku, který algoritmus kdy použije, ale jejich implementaci podědí. (opět můžeme dojít k tomu, že kompozice bude čistější návrh, ale teď předpokládám, že trváš na tom, aby obě metody byly v jedné třídě).

A na závěr musím dodat, že v podstatě žádný test netestuje všechny případy, které mohou nastat – typicky se testují jen reprezentativní vzorky, což dává dostatečnou míru jistoty, že je implementace správná. Můžeš tedy otestovat řazení seznamu o např. 0,1,2,3,4,5,10,50,100,1000 a 10000 prvcích a pokud to ve všech případech projde, tak prohlásíš test za úspěšný. Pak můžeš s tou hranicí hýbat celkem dle libosti a ničemu nevadí, že je to privátní konstanta neviditelná z testu. Pokud by někdo změnil konstantu nad 10000 a zároveň zanesl chybu do implementace, tak prostě smůla – žádný test není dokonalý. Tohle by měla zachytit zase revize kódu (její běžnou součástí je kouknout mj. na pokrytí testy a ověření, zda testují, co mají – což v tomto případě netestují, protože ten testovaný vzorek není dostatečně reprezentativní a pokrytí není plné).

P.S. I kdybys chtěl testovat nad tou hranicí a pod ní na základě té konstanty, tak máš pořád dvě možnosti: a) udělat tu konstantu veřejnou nebo spíš napsat getter (do komentáře uvedeš, že je jen pro testy, třeba ho dáš jako @Deprecated) nebo b) uvnitř testu použiješ reflexi. Oboje je lepší, než útočit na jazyk jako takový a snažit se ho zbavit užitečné vlastnosti (zapouzdření nebo jinde třeba ten final).

[kralyk z abclinuxu]

A teď si představ, že bys dělal TDD – to bys psal nejdřív test a žádnou implementaci bys k dispozici v tu chvíli ještě neměl.

No musel bych pak třeba ten test změnit, abych měl coverage...

Nemyslím si. Správná cesta je podle mého ta kompozice (odlišené algoritmy v samostatných třídách + výhybka ve třetí třídě). Nejdřív bych to tedy napsal takhle, a až pokud by režie volání metody jiného objektu byla problém, tak bych přemýšlel, jak to přepsat – jinak je to totiž předčasná optimalizace, kořen všeho zla. Rozdíl v té režii bude pravděpodobně minimální/neměřitelný, takže by to zůstalo takhle.

Ja s tímhle designem nemám vůbec problém z hlediska rychlosti, ale protože to je totální overengineering, zejména ve chvíli, kdy do toho začneš míchat ještě fasády a singletony a kdovíco. To je IMHO prostě šílenost. Už to, že někoho napadne to takhle řešit, mi přijde na pováženou, dále je na tom hlavně to, že tím strašně zvětšuješ public API, o které bude potřeba se starat, nehledě k tomu, že ho bezvýznamně zesložiťuješ. Když někdo přijde k dokumentaci a uvidí tam 4 sortovací funkce s nějakým magickým parametrem, bude mnohem zmatenější, než když tam prostě bude jedna funkce na sortování a basta, která vevnitř bude mít navenek blíže nespecifikovanou implementaci. Klidně se můžu v další verzi rozhodnout, že vyhodim bubblesort a quicksort a nahradim to timsorte a API by to nemělo nijak ovlivnit.

Zkus se možná zamyslet na důvody, proč bys volil to komplikované řešení. Jsou pro to nějaké praktické důvody, nebo to je prostě protože máš pocit, že to je "správný design"? To, že za "správným designem" existují nějaké praktické důvody, samozřejmě vím. Otázka ale je, jestli v tomhle případě stále ještě zůstaly ty praktické důvody, nebo je to už jen rutinní opakování naučených pravidel zcela bez ohledu na praktické zdůvodnění.

I kdyby ses ale rozhodl to nacpat všechno do jedné třídy, tak se to pořád ještě dá testovat.

Ta funkce vůbec v žádné třídě být neměla, měla to být samostatná funkce podobně jako třeba tahle. Po přenesení do Javy bohužel v nějaké třídě bude muset být, ačkoli to vůbec nedává smysl, protože Java retardovaně nepodopruje samostatné funkce.

[xkucf03]

Zkus se možná zamyslet na důvody, proč bys volil to komplikované řešení. Jsou pro to nějaké praktické důvody, nebo to je prostě protože máš pocit, že to je "správný design"?

Já se nad tím zamýšlím v podstatě každý den :-).

Jestli danou úlohu řešit jednoduše ale nepružně nebo naopak spíš pružně, univerzálněji, s větším výhledem do budoucna a trochu složitěji – to záleží na okolnostech – neexistuje obecná rada, dělat to vždy tak nebo tak. (BTW: tohle je možná falešné dilema – ale já s tím nezačal)

Pokud je daný kód jen interní, spravovaný jedním týmem (nebo dokonce člověkem), definovaný a používaný v jednom repozitáři/projektu, tak velice rád použiji jednodušší řešení, protože vím, že to v případě potřeby můžu kdykoli přepsat – refaktorovat v rámci jednoho repozitáře se v IDE dá snadno a taky vím, že nikomu dalšímu nerozbiji jeho kód, že ho nebude muset přepisovat. Ale když tvořím víc veřejné API a jeho uživatelé jsou vzdálenější, pracují na jiných projektech, v jiných repozitářích, sedí někde jinde nebo je dokonce ani neznám, tak pak je na místě se zamyslet nad obecnějším a pružnějším (byť trochu složitějším) návrhem, protože to, co v takové situaci jednou zveřejníš/vydáš, už nemůžeš tak snadno měnit, protože na tobě závisí další lidi a další kód, který nemůžeš sám měnit nebo dokonce ani nevíš, jaký všechen takový kód existuje.

Po přenesení do Javy bohužel v nějaké třídě bude muset být, ačkoli to vůbec nedává smysl, protože Java retardovaně nepodopruje samostatné funkce.

Knihovní třída (návrhový vzor) je vlastně jen jmenný prostor (na rozdíl od běžných tříd). Je otázka, jestli nemít speciální jazykový konstrukt pro tyto funkce. Ale stejně by byly v nějakém souboru a musel bys je nějak adresovat a nemyslím si, že by to mělo nějaké praktické výhody – možná bys jen v poslední části jmenného prostoru nemusel psát velké písmeno, ale třeba bys zase musel psát něco jiného, abys to odlišil od tříd. Podle mého zbytečnost, která by jen zesložitila jazyk a znepřehlednila kód.

[kralyk z abclinuxu]

Ale když tvořím víc veřejné API a jeho uživatelé jsou vzdálenější, pracují na jiných projektech, v jiných repozitářích, sedí někde jinde nebo je dokonce ani neznám, tak pak je na místě se zamyslet nad obecnějším a pružnějším (byť trochu složitějším) návrhem, protože to, co v takové situaci jednou zveřejníš/vydáš, už nemůžeš tak snadno měnit, protože na tobě závisí další lidi a další kód, který nemůžeš sám měnit nebo dokonce ani nevíš, jaký všechen takový kód existuje.

Přesně z tohohle důvodu jsem chtěl dát jako veřejné API jen tu jednu funkci místo několika tříd, interfaců atd. Rozšířit jednoduché/minimální rozraní ve chvíli, kdy to je potřeba, mi přijde z hlediska zpětné kompatibility snažší než se snažit nějak měnit existující rozsáhlejší API.

Samozřejmě záleží na zadání. A vzhldem k tomu, že zadání nemáme a jen ho hádáme, nemá asi moc smysl řešit, který přístup to líp splňuje...

Podle mého zbytečnost, která by jen zesložitila jazyk a znepřehlednila kód.

No ono by to v případě Javy šlo špatně vzhledem k tomu jak funguje import.

[ehm]

Knihovní třída (návrhový vzor) je vlastně jen jmenný prostor (na rozdíl od běžných tříd). Je otázka, jestli nemít speciální jazykový konstrukt pro tyto funkce.

Nevidím v tom jinou přidanou hodnotu než ušetření jednoho odsazení. Z hlediska použití v tom také není rozdíl, protože existují statické importy (příliš často se to nepoužívá a sám nevím, jak se to k tomu stavět).

Pokud něco, líbíl by se mi modifikátor pro neinstanciovatelnou třídu. Takto musíš psát privátní konstruktor a třídu označit jako final.

[kralyk z abclinuxu]

Pokud něco, líbíl by se mi modifikátor pro neinstanciovatelnou třídu. Takto musíš psát privátní konstruktor a třídu označit jako final.

namespace ?

[ehm]

Zmatečné. Alternativou k namespacům (jak známo z C++, PHP, C#) jsou v Javě packages.

[xkucf03]

Když už rozšiřovat jazyk v tomhle směru, tak by se mi líbilo, kdyby šlo třídu/metodu při importu lokálně přejmenovat a tím se vyhnout kolizím (stejné názvy v různých balíčcích/třídách). Příklad:

import com.example.db.Connection as DatabaseConnection;
import org.example.ssh.Connection as SshConnection;

[ehm]

To je dobrý postřeh. Dokonce přesně na to byly nejméně dva požadavky (1, 2). Oba jsou zavřené jako duplicitní, takže to musel reportovat někdo už dřív.

Související otázka: Setkal jsi se někdy s tím, že by (mimo tebou spravovanou codebase) kolidovaly fully-qualified jména tříd? Já naštěstí ne a vzhledem ke jmenným konvencím packagů je i nepravděpodobné, že by se to stalo, ale pokud by k tomu došlo, tak nevím, jestli to jde resolvnout jinak než patchem, nebo instrumentací (tj. přejmenovat ty třídy před načtením class loaderem a pak si je vyžádat pomocí Class.forName – to dává smysl jen v případě, že s nimi můžeš pracovat skrz nějaký implementovaný interface). Řekl bych, že je to hodně teoretický případ, a v praxi se to neděje, ale zajímá mě tvoje zkušenost.

Ale abych ještě nějak uzavřel to rozšiřování jazyka: Nic z toho nepovažuji za zásadní. Typicky se bavíme o specifických situacích a lze to většinou řešit jinak, třebaže ne tolik elegantně. Ale vidím v tom nějaký prostor pro zlepšování.

U toho overridování modifikátorů si pohrávám s myšlenkou submitnout JEP. Trochu jsem si to ale nechal projít hlavou a napsat kompletní specifikaci není úplně triviální (je tam dost případů, které je nutné ošetřit), takže si to ještě rozmyslím. V neposlední řadě si myslím, že šance na schválení jsou mizivé, a vytvářet superset Javy (po vzoru Oderskyho Generic Javy – dnes již samozřejmě neaktuální) bych asi taky neviděl jako zvlášť smysluplné.

Jinak tohle je bohužel další diskuze, kde lidi Javu kritizují převážně pocitem, ne racionálně a ze zkušenosti. Schválně jsem včera zkusil přeměřit ten rozdíl mezi voláním virtuální a statické metody a bylo to neměřitelné. Ta virtuální metoda vycházela o něco pomaleji, ale ten rozdíl byl velmi malý až žádný. Navíc ty hodnoty mezi jednotlivými spuštěními skákaly tolik, že jakýkoliv závěr je pod přesnost toho měření (zvlášť stane-li se, že ta virtuální metoda občas vyjde i nepatrně rychleji než statická). K tomu, že je to zbytečná mikrooptimalizace, jsem se přikláněl já, ty i deda.jabko. Ale rozjede se o tom diskuze, kde se samozřejmě řeší zlá abstrakce a nikdo neví, co to dělá pod povrchem a jak se to přeloží. Fakt nevím, jak vypadá machine code, co vybleje JIT, a znát to ani nepotřebuju. Relevantní: Benchmarky srovnávající různá JVM (vč. ExcelsiorJET, tj. AOT kompilátor) a nativní kód v C. Je to 9 let stará záležitost, na výkonu JVM se od té doby ještě dál výrazně zapracovalo (přinejmenším v oblasti GC).

Nic nevědět (možná kromě matných vzpomínek, jak se psala semestrálka v Javě, nebo bouchat nějaký side-project v práci v editoru bez IDE – viz starší diskuze s kralykem), ale hlavně mít názor.

[kralyk z abclinuxu]

Když už rozšiřovat jazyk v tomhle směru, tak by se mi líbilo, kdyby šlo třídu/metodu při importu lokálně přejmenovat a tím se vyhnout kolizím (stejné názvy v různých balíčcích/třídách). Příklad:

import com.example.db.Connection as DatabaseConnection;
import org.example.ssh.Connection as SshConnection;

Kotlin tohle podporuje. Dokonce je ta syntaxe přesně taková, jak jsi ji napsal

[ehm]

Groovy taky.

[Bystroushaak]

Sorry jako, ale jestli chces resit takove detaily, tak se vykasli na Javu a dalsi vyssi programovaci jazyky, protoze ty maji trosku jiny ucel nez davat programatorovi pocit, ze vi, jak bude z pracovana kazda operace.

Chápu ten argument, ale u výpočetně náročných numerických operací, jako je sort, to asi docela chceš mít optimální, ne?

[deda.jabko]

Chápu ten argument, ale u výpočetně náročných numerických operací, jako je sort, to asi docela chceš mít optimální, ne?

Zmena primeho volani na neprime ma v tomto pripade minimalni rezii. Nedavno jsem si s tim hral v C++ a prinos byl na realnych algoritmech nemeritelny. Jinak schvalne srovnej treba s Pythonem, kde volani metod ma rezii ve srovnani s C++/Javu nesoumeritelnou a nikoho to netankuje.

[Bystroushaak]

Zmena primeho volani na neprime ma v tomto pripade minimalni rezii. Nedavno jsem si s tim hral v C++ a prinos byl na realnych algoritmech nemeritelny. Jinak schvalne srovnej treba s Pythonem, kde volani metod ma rezii ve srovnani s C++/Javu nesoumeritelnou a nikoho to netankuje.

V pythonu to tankuje docela hodně lidí, proto se taky sorty píšou v C.

[deda.jabko]

proto se taky sorty píšou v C

Ale az v momente, kdyz to zacne drit. Pri programovani snad neuvazujes nad tim, jestli se pro volani sort pouzije call 0xdeadbeaf nebo call [eax + 0xcafebabe].

[ehm]

Ví někdo z přítomných javistů, jak moc je/není java kompilátor schopen tohle odoptimalizovat?

javac tohle nijak neoptimalizuje. Jak s tím naloží JIT nevím, ale nemyslím si, že by tam byl nějaký zajímavý výkonnostní rozdíl. Samozřejmě záleží, o kolik by ten bubble sort byl rychlejší – ale divil bych se, kdyby ty dvě volání ten rozdíl setřely (a pokud ano, tak možná nestojí za to ty algoritmy vůbec střídat).

[kralyk z abclinuxu]

Ok, to zní rozumně.

[ehm]

Ten test by měl danou jednotku testovat zvenku a pokud je jednotkou třída, tak by měl testovat její veřejné metody.

Čím složitější/komplexnější funkčnost test testuje, tím obtížnější bude pochopit, kde došlo k chybě, až ten test začne padat. Proto se hodí mít otestované i ty neveřejné metody, pokud obsahují netriviální logiku. Přesouvat každou takovou metodu do jiné třídy, pokud není použitelná i jinde, nepovažuji za dobrý nápad.

S tím, že bys v ideálním případě měl mít z vnějšku otestované všechny veřejné metody a všechny jejich větve, souhlasím.

V praxi mám ale na psaní testů omezený čas, a přiznám se, že je často ani nepovažuji za natolik významné, takže to řeším nějakým hybridem.

Psal jsem třeba nějaké připojováky na různé externí služby. Typicky pak mám oddělený jednotkový test a integrační test. V jednotkovém testu si otestuji logiku. V integračním testu otestuji pár základních případů, které se dají nějak rozumně vyvolat. Některé případy se rozumně nasimulovat nedají, resp. to nestojí za vynaložené úsilí.

Není to pak pokryté úplně dokonale, protože kdyby třeba někdo přišel, a v kódu přestal volat metodu, která byla pokrytá tím jednotkovým testem, a místo toho to nahradil zjednodušeným kusem kódu, díky kterému projdou ty nekompletní integrační testy, ale ve skutečnosti to nebude řešit některé složitější případy (které pokrýval ten jednotkový test na tu neveřejnou metodu), tak se to rozbije. Ale to je prostě o tom, kolik prostředků si můžeš do psaní těch testů dovolit investovat a jak moc je ta která část důležitá.

Ale jak jsem psal úplně na začátku – i kdybys testoval veřejné metody v plném rozsahu, tak to neznamená, že se nemůžou hodit doplňkové testy na ty vnitřní metody. (V některých případech – zas se to taky nesmí přehánět, abys pak kvůli jedné drobné změně ve specifikaci neupravoval neúměrně mnoho testů.)

Můžeš uvést konkrétní příklad, co v těch konstantách je?

Ano, můžu. Bylo to v knihovně Asm a zmiňované konstanty reprezentují typy položek v constant poolu. Hodnoty jsou dané specifikací JVM. Protože Asm constant pool při načtení třídy neparsuje (pouze si spočítá indexy jednotlivých položek a ty potom čte; prostě spoléhají na to, že to bude v očekávaném typu), tak si to parsování musím zajistit sám. K tomu potřebuji ty konstanty. Viz blok konstant začínající konstantou CLASS v tomto souboru (nedá se tam udělat kotva na konkrétní řádek, sorry).

Upřímně je celý Asm napsaný velmi podivně – hodně volně řečeno. Class formát je docela jednoduchý, takže jsem přemýšlel, že to celé přepíšu, ale možná se na to vykašlu. S bajtkódem už si moc nehraju a tu věc, co teď potřebuju, asi jen nějak ohackuju.

[xkucf03]

V praxi mám ale na psaní testů omezený čas, a přiznám se, že je často ani nepovažuji za natolik významné, takže to řeším nějakým hybridem.

V tom případě bych to pořešil tou reflexí a moc se tím netrápil. Přinejhorším ti spadne test (a tím aspoň poznáš, že se něco změnilo). Jsou na to i knihovny, které to usnadní, ale ani ruční použití reflexe není takový problém.

A mimochodem, ta reflexe není až tak pomalá.

[ehm]

V tom případě bych to pořešil tou reflexí a moc se tím netrápil.

Ne, díky. To je fakt jednodušší používat jen public a package-protected a na ten zbytek se vykašlat. final taky dost často použít nemůžu kvůli omezením jazyka (příklad).

[xkucf03]

Na to už jsem taky narazil, ale nenapadá mne, jak to řešit líp. Jazyk/kompilátor by musel mít jiná pravidla pro tutéž metodu, podle toho, zda je volaná z konstruktoru nebo ne. A taky by musel složitě zkoumat, jestli už danou proměnnou nějaká metoda nastavila a ostatní k ní můžou přistupovat.

Typicky se to řeší tak, že si hodnotu spočítáš v metodě, ale do final proměnné ji přiřadíš v konstruktoru.

[ehm]

No, zkrátka je lepší se final obloukem vyhnout, jakmile něco začne smrdět. Tohle může a nemusí být ten případ, záleží na okolnostech.

Další perlička je tohle. Tam je to podobné. Metoda by mohla napáchat nějaké ukrutné zlo než dojde k inicializaci předka (nedejbůh si šáhnout na final field), tak je potřeba to zakázat. Nepřijde mi, že by bylo zas tak těžké rozšířit specifikaci a podobné věci umožnit.

Považuju to za historické defekty, ale neočekávám, že by to v dohledné budoucnosti začaly měnit.

Jinak ono je v Javě různých chytáků docela dost. Ty nejzákeřnější (na které jsem skutečně narazil v práci) si pečlivě hýčkám v poznámkách, kdybych třeba někdy potřeboval připravit otázky na pohovor pro někoho, kdo o sobě tvrdí, že je v Javě senior.

[deda.jabko]

Tam je to podobné. Metoda by mohla napáchat nějaké ukrutné zlo než dojde k inicializaci předka

Ze je zakazane volat metodu neinicializovaneho objektu je vcelku pochopitelna restrikce, obzvlast, dela-li si jazyk narok na to, ze chce byt bezpecny.

Nepřijde mi, že by bylo zas tak těžké rozšířit specifikaci a podobné věci umožnit.

Tezke to neni, pokud umis vyresit problem zastaveni.

[ehm]

Tezke to neni, pokud umis vyresit problem zastaveni.

To není potřeba. Pokud se může (v jakékoliv větvi) zavolat třeba metoda předka, která pak bude číst dosud neinicializované fieldy, tak se to má chovat stejně. Jinak to může povolit. A přijde mi, že s dnešním výpočetním výkonem by to nemusel být zas takový problém zanalyzovat/rozhodnout.

[kralyk z abclinuxu]

final taky dost často použít nemůžu kvůli omezením jazyka (příklad).

Na tohle má Kotlin lateinit, dokonce to mají i ukázáno právě na testu...

[Josef Kufner]

Kromě Javy jsou snad všechny GUI aplikace implicitně jednovláknové. Všechno v Qt, Gtk+, Xlib a mnoha jiných je jednovláknové, dokud tam explicitně nezačneš vlákna vyrábět. Říká se tomu event-driven programming (prostě main loop, select() (či něco takového) na socketech a file descriptorech, neblokující čtení i zápis do všeho).

[xkucf03]

Přesto se řada aplikací zasekává… tak to asi úplně neblokující nebude.

Ale to je jedno. Pokud jim to funguje pro jiné věci, tak by to mělo fungovat i pro to API – skrze API budou přicházet nějaké zprávy/události a aplikace je bude vyřizovat (odesílat do fronty odpovědi).

[Josef Kufner]

Něco si o tom neblokujícím IO přečti. Je to zajímavé čtení

[xkucf03]

Já vím, jak to funguje¹, jen jsou zřejmě ty aplikace blbě napsané. Zrovna před chvílí se mi zasekl Firefox, protože disk byl uspaný a než se roztočil, tak ve FF nešlo nic dělat. A stává se to i jinde – čeká se buď na disk nebo na síť. V KDE třeba dlouho trvá přihlášení, když je vytažený síťový kabel.

_{[1] BTW: zkouším si i něco psát nad libevent v C++}

[Josef Kufner]

Ono u krátkých operací se neřeší, že GUI bude chvíli zaseklé. Otevírání souboru, které typicky zabere pár milisekund, snad ani neblokující variantu nemá. Ale zaseknout se to může třeba i na swapování nebo podobných činnostech. Řešit všechno pomocí neblokujících operací nebo pomocí vláken by bylo zbytečně složité. Takže si to prostě občas trošku škytne a teprve když je něco na delší dobu, tak se udělá progress bar či točicí cosi.

[Fluttershy, yay!]

Zkus si porovnat dva větší adresáře v Meldu.

[xkucf03]

A nebo použiješ dvě vlákna + blokující IO a ještě to máš jednodušší na psaní. U desktopové aplikace tě to vlákno navíc fakt nevytrhne (neříkám u www serveru jako Apache nebo Nginx, který má servírovat nějaký veřejný web a obsloužit spousty klientů – tam je to něco jiného).

[Josef Kufner]

Ale pak je zas potřeba se patlat se synchronizací vláken. To mnohdy nadělá víc škody než užitku. Navíc knihovny jako Qt mají v sobě nástroje pro velmi snadno použitelné čekání na data ze souboru (chodí pak události "buffer naplněn, tady máš kus souboru").

[pavlix]

Tak to má snad už POSIX a hodně to vylepšují linuxová rozšíření.

[xkucf03]

Ale pak je zas potřeba se patlat se synchronizací vláken. To mnohdy nadělá víc škody než užitku.

Vzpomínám, kdy jsem měl naposledy problémy s vlákny… to už bude hodně dávno.

V Javě je to asi jednodušší tím, že standardní třídy se nedělají jako vícevláknově bezpečné, tak je v tom celkem jasno. A když chceš k nějakému objektu přistupovat z více vláken, tak si ověříš, jestli náhodou není uvnitř synchronizovaný (to bys měl bez práce) a pokud není, tak si ho synchronizuješ sám nebo ho obalíš třeba synchronizovanáMapa = Collections.synchronizedMap(původníNesynchronizovaná) což je mj. fajn v tom, že uvnitř je tvoje vlastní implementace mapy nebo něčeho jiného a nemíchají se tyhle dvě věci dohromady (implementace kolekce / způsob synchronizace).

Navíc knihovny jako Qt mají v sobě nástroje pro velmi snadno použitelné čekání na data ze souboru

Tohle má dneska většina jazyků. V Javě to máš ve standardní knihovně + nad tím můžeš mít třeba ještě Netty.

Někdy mi přijde, že je to až hysterické tažení proti vláknům a módní vlna dělat všechno asynchronně. Mám na tohle prostě trochu střízlivější pohled – jsou případy, kdy asynchronní IO hodně pomůže, a pak jsou případy, je to prakticky jedno nebo jsou vlákna a synchronní IO jednodušší.

[kralyk z abclinuxu]

Někdy mi přijde, že je to až hysterické tažení proti vláknům a módní vlna dělat všechno asynchronně.

To není proti vláknům obecně ale proti snahám škálovat pomocí vláken, ie. třeba vytváření vlákna per klient, protože to je neefektivní. Vlákna se ale jinak typicky používají i spolu s asynchronním I/O, akorát jich je konstatní počet - vytvoříš thread pool a v něm pak vyřízuješ věci asynchronně.

[xkucf03]

V případě škálování to dává smysl. Ale právě mi přijde, že si někteří přečetli o tom, jak největší webové servery nezvládají škálovat pomocí vláken a bylo potřeba je přepsat asynchronně… a na to zareagovali zcela hystericky a povrchně tím, že zavrhli vlákna obecně (i v jakkoli malých aplikacích) a snaží se do všeho nacpat asynchronní IO.

[Josef Kufner]

Někteří zas vlákna párkrát použili a vědí, jak těžko se tam hledají chyby.

[pavlix]

+1

A takový člověk vlákna zavrhuje mimo případy, kdy je pro ně dostatečné opodstatnění, a i v těch případech ještě zváží multiprocessing.

[Bystroushaak]

Někteří zas vlákna párkrát použili a vědí, jak těžko se tam hledají chyby.

Že by v tom teda asynchronní kód byl nějak lepší, to mi zrovna nepřijde.

[xkucf03]

+1

[pavlix]

Tak to mně teda docela prijde a docela dost. Jestli ti přijde debugging asynchronního a vláknového kódu na stejné úrovni, docela rád bych se na tvoje metody přijel podívat.

[Bystroushaak]

No, já mám třeba konkrétní příklad a to je použití asyncia v pythonu 3.5. Celé to nakonec skončilo přepsáním na multiprocessing, protože z asyncia se kolega málem posral. Sice tam nemusíš řešit běžné problémy paralelizace, ale zas musíš řešit problémy frameworku, který je všechno jen ne jednoduchý a snadno pochopitelný. Teď v práci jsem několikrát řešil twisted a že by se mi to nějak extra líbilo se taky říct nedá. Těch způsobů, jak se tam střelit do nohy je nemálo.

[pavlix]

Debugování v Pythonu je hodně špatné, to uznávám, ale to platí obecně a asyncio tomu může dopomoct tím, že to schovává hodně věcí. Ale to není úplně problém používání event loopu s asynchronními zdroji. Chápu, že pokud svoji zkušenost odvozuješ z asyncio nebo twisted, že bude asi hodně jiná než moje. :) Ale stejně bych se někdy sešel na drobnou výměnu zkušeností, pokud budeš mít čas a náladu.

[kralyk z abclinuxu]

Někteří zas vlákna párkrát použili a vědí, jak těžko se tam hledají chyby.

Že by v tom teda asynchronní kód byl nějak lepší, to mi zrovna nepřijde.

+1

[pavlix]

Pokud použiješ dvě vlákna a v obou pouze blokující IO, jak budou komunikovat mezi sebou, aby se neblokovaly?

[xkucf03]

Typicky jedno vlákno jen kreslí GUI, takže ho nic neblokuje. A druhé vlákno dělá něco na pozadí a do GUI pošle až výsledek. Kdyby na pozadí běželo víc vláken, tak na sebe buď počkají (když to čekání má nějaký reálný smysl) nebo odešlou svoje výsledky do GUI samostatně.

K blokování pak dochází maximálně po dobu, než naplníš např. textové pole GUI nějakou hodnotou – ale to by mělo být okamžité (na rozdíl od práce s disky, sítí nebo nějakých výpočtů).

[pavlix]

Pokud nemáš zájem odpovědět na otázku, proč se namáháš s psaním desítek slov okecávek?

[xkucf03]

Jak budou komunikovat mezi sebou? Pokud už to bude tedy potřeba, tak třeba přes synchronizovanou resp. vícevláknově bezpečnou frontu

[pavlix]

A k té frontě se bude přistupovat blokujícím nebo neblokujícím přístupem?

[kralyk z abclinuxu]

Neblokujícím? Přijde mi, že tohle podvlákno je diskuse typu "X/Y problem". Nejlépe kdybys lépe vysvětlil tu situaci, na kterou ses ptal, protože zjevně lidé nechápou, co to bylo.

[pavlix]

Pokud neblokujícím, tak jsi právě zabil celou diskuzi, která se zabývala tím, jestli použít neblokující přístup nebo vlákna. Nakonec skončíš u toho, že použiješ vždy na klíčovou komunikaci neblokující přístup a pouze se rozhoduješ zda ho doplnit o vlákna či nikoliv.

[kralyk z abclinuxu]

What? Nerozumim řeči tvého kmene. Neblokující přístup je u datových struktur default, pokud bys chtěl blokovat na nějaký frontě, tak bude ta fronta muset být vybavena nějakou condition variable nebo něčím takovým, kde si v podstatě explicitně žádáš, aby bylo vlákno uspáno. Naopak u I/O je default ten blokující přístup a potřebuješ něco navíc, aby to neblokovalo (oznámení o readiness nebo completion).

[ehm]

„Jak byste vymalovali pokoj červenou zelenou?“ – „Vymaloval bych jen červenou, nebo zelenou.“ – „OMG STFU NOOB! Odpověz mi na mou otázku!“

Just pavlix. Full retard mode. All the fucking time.

[pavlix]

Nope.

[kralyk z abclinuxu]

Pokud nemáš zájem odpovědět na otázku, proč se namáháš s psaním desítek slov okecávek?

Možná lépe vysvětlit tu otázku? Mně přijde dost kryptická...

[pavlix]

Mně přijde tak krystalicky jasná i když si ji teď opakovaně přečtu, že zatím nevidím prostor pro jakékoli vysvětlování.

[pavlix]

Pokud se zasekává GUI, je to už špatně. Pokud se nezasekává díky neblokujícímu IO, ideál, pokud se to neumí, tak asi další vlákno zpracování. Teď neříkám, že to musí být vytvořením vlákna v rámci jednoho procesu, samostatný proces je možná v těchto případech lepší řešení.

[JS1]

Jinak tohle je taky dobrá ukázka zahořklosti.

Navrhuji odlozit nasi diskusi o zahorklosti o 10 let, az uvidis, a trochu te unavi, ze lide delaji porad tytez chyby. Vis, kdo je (podle me) taky zahorkly? Alan Kay.

Co tim chci rict - oznacovat nekoho za zahorkleho, jak to tak rad delas, je proste chucpe. Casem na to snad prijdes.

Ano, web aplikace mi vadi, protoze uz to bylo udelano driv a (v nekterych smerech dost) lepe.

Spousta dnešních problémů IT existovala dokonce i před tím, než IT vzniklo, protože to ve skutečnosti vůbec nejsou problémy IT, ale problémy organizace informací a struktury rozhodování.

Ano, vzdyt to pisu.

těžko to může soupeřit s okamžitou realitou kolem nás, kde to (s výjimkou státní správy) funguje z velké většiny tak, jak jsem napsal

Kdyz myslis.. Ja dochazim posledni dobou spis k tomu, ze lide o meritokracii vlastne moc nestoji. Ono to neni zadne terno. A proto ve velkych a statnich podnicich ta meritokracie nijak zvlast nekvete, a je tam spousta lidi, co radeji delaji a vymysleji nesmyslnou praci.

[Bystroushaak]

Vis, kdo je (podle me) taky zahorkly? Alan Kay.

Jop, s tím souhlasím. Taky Ted Nelson a pár dalších lidí. Na Kayovi musím ale nechat, že on svojí zahořklost spaluje konstruktivně a snaží se přesvědčit mladé lidi přednáškami, kde se jim snaží ukázat, že to kde jsme není nějaký vysněný stav a vrchol technologie, ale jen mezikrok k něčemu mnohem silnějšímu a vznešenějšímu. Prostě jim dodat nějaký filosofický ideál, ke kterému směřovat.

Co tim chci rict - oznacovat nekoho za zahorkleho, jak to tak rad delas, je proste chucpe. Casem na to snad prijdes.

Tak já to nemyslím jako urážku (může to být vůbec urážka?), spíš popis stavu, jak mi to přijde.

Ano, web aplikace mi vadi, protoze uz to bylo udelano driv a (v nekterych smerech dost) lepe.

A mělo to featury, o kterých jsem psal? Protože co já vím, tak ani zdaleka nemělo.

Kdyz myslis.. Ja dochazim posledni dobou spis k tomu, ze lide o meritokracii vlastne moc nestoji. Ono to neni zadne terno. A proto ve velkych a statnich podnicich ta meritokracie nijak zvlast nekvete, a je tam spousta lidi, co radeji delaji a vymysleji nesmyslnou praci.

Já myslím, že to souvisí s nárůstem komplexity organizace práce. To je jedna věc. Druhá je, že velké instituce si to prostě můžou dovolit a nepoloží je to (hned).

Osobně bych řekl, že v takových podnicích to funguje podobně jako takové ty grafy závislosti počtu lišek na počtu zajíců, kde se zajíci množí a lišky je požírají a taky se množí a musí se to balancovat, protože jinak se přemnoží lišky a chcípnou hladem, nebo se přemnoží králící, sežerou všechnu trávu a chcípnou hladem. To co vidíme my jsou ty balancovací cykly mezi tím, kde se ve firmě množí zmrdi a zmrdobijci a různě to osciluje a jednou za čas si nějaký (klidně externě najatý) analytik všimne, že lidi jsou tam vlastně k ničemu, tak je vyrazí a pak se tam zas dostanou netáhla a doporučí i svoje kamarády a firmu zevnitř infikují a takhle se to prostě různě opakuje a je to věčný koloběh života. Firmy co mají dostatečně dobré mechanismy to nepoloží, firmy které je nemají to položit může. Problém je to hlavně u státu, kde místo položení prostě zvednou daně všem ostatním.

[JS1]

Nez ti (pozdeji) odpovim vic k veci, zrovna ctu Proc socialismus? a libi se mi tam odstavec:

I have now reached the point where I may indicate briefly what to me constitutes the essence of the crisis of our time. It concerns the relationship of the individual to society. The individual has become more conscious than ever of his dependence upon society. But he does not experience this dependence as a positive asset, as an organic tie, as a protective force, but rather as a threat to his natural rights, or even to his economic existence. Moreover, his position in society is such that the egotistical drives of his make-up are constantly being accentuated, while his social drives, which are by nature weaker, progressively deteriorate. All human beings, whatever their position in society, are suffering from this process of deterioration. Unknowingly prisoners of their own egotism, they feel insecure, lonely, and deprived of the naive, simple, and unsophisticated enjoyment of life. Man can find meaning in life, short and perilous as it is, only through devoting himself to society.

[ehm]

Premyslim, co za timhle fatalistickym tvrzenim je. Neznalost historie? Neznalost jinych kultur? Vira ve spravedlivy svet? Vira v nezvratny pokrok?

Zkušenost, znalost historie, znalost jiných kultur, absence víry ve spravedlivý svět, absence víry v nezvratný pokrok.

Prijde mi, ze jsi zrovna touhle vetou potvrdil to, co napsal uz Gulasnikov

Já to rozporoval? Ptal jsi se, proč se nesnažím/e něco změnit. Tak jsem to rozvedl.

[JS1]

Pokud znas historii a/nebo jine kultury, tak asi vidis, ze veci mohou byt i (o dost) horsi... tak proc zastavas nazor, ze nemohou byt lepsi?

[ehm]

Ta otázka nezněla, jestli mohou být lepší, ale jestli to jde změnit k lepšímu.

[JS1]

V tom nevidim rozdil.

[Bystroushaak]

pockal jsem na tech 50 komentaru a chtel jsem videt, kolik lidi si toho vsimne a omlati to autorovi o hlavu.

Nic.

To uz jste vsichni tak uplne zdegenerovali, ze to vubec nevnimate? Boj o pracovni misto u klavesnice a obrazovky. S vitezi a porazenymi. Porazenymi, kteri patrne neodkladali sve vyplody na github. A tim selhali.

Butthurt? O poražených a vítězích píšeš ty, já tam nic takového nezmiňuji. Pokud se ucházíš o práci, tak je logicky přijetí úspěchem a nepřijetí neúspěchem. To tak nějak plyne z definice slova „ucházet se“. Fakt by mě zajímalo, co máš zrovna s tímhle za problém.

patrne neodkladali sve vyplody na github. A tim selhali.

Nejde o github, ale o portfolio. Github je jen dobrá platforma, ale samozřejmě je možné to praktikovat i jinak, příklad viz zde v diskuzi Jenda Hrach, který si provozuje vlastní server, kde má projekty na ukázku. Samozřejmě je možné se ucházet o práci i bez toho, ale z mé osobní zkušenosti plyne, že se tím stavíš do složitější pozice. Pokud ti to však vyhovuje, tak proč ne.

V diskuzi se nekdo divi, jak to, ze jen 80% hodnoceni, jak muze dat nekdo minus. Ja sice chapu, proc se v dnesni zdegenerovane spolecnosti hodnoti podobne blaboly positivne, spise se divim, kde se vzalo tech 20%, ale zoufaly jsem z toho presto. Zoufaly z omezenosti autora a jemu podobnych, kteri se snazi vylepsit sve pracovni dovednosti, aby mohli pristimu zamestnavateli generovat jeste vetsi nadhodnotu.

Osobně se snažím vylepšit své pracovní dovednosti především proto, že mě to zajímá a baví. Rád si poslechnu důvody, proč by mi mělo vadit, že zaměstnavateli (zadavateli práce v mém případě) generuji nadhodnotu.

Ale i po te ciste technicke strance je ta semiprofesionalita autora ubijejici. Kde je napr. zminka o unittestech unittetstu . Kdo kritizuje kritiky a kdo kontroluje spravnou funkci verzovaciho systemu. Neni ani zminena ta zasadni podminka uspesneho projektu, totiz , ze nejlepsi je delat vsechno nejlepe a idealni tym je treba sestavit idealne. Dale autor zapomnel upozornit, ze pri komunikaci je treba se divat do oci partnera. Opomenuta jsou dnes absolutne rozhodujici temata jako napr: jak vybrat Scrum Mastera aneb proc i zkuseni Scrum Masteri selhavaji v Agilni transformaci.

Opravdu ti to přijde jako vhodný materiál do blogu pro začátečníky?

Kde je napr. zminka o unittestech unittetstu .

Pokud bych to někdy potřeboval, tak se vydám radši cestou formální verifikace.

Kdo kritizuje kritiky

Ostatní kritici.

kdo kontroluje spravnou funkci verzovaciho systemu.

Uživatelé.

Neni ani zminena ta zasadni podminka uspesneho projektu, totiz , ze nejlepsi je delat vsechno nejlepe a idealni tym je treba sestavit idealne. Dale autor zapomnel upozornit, ze pri komunikaci je treba se divat do oci partnera. Opomenuta jsou dnes absolutne rozhodujici temata jako napr: jak vybrat Scrum Mastera aneb proc i zkuseni Scrum Masteri selhavaji v Agilni transformaci.

Hele, zas to s tím sarkasmem nepřeháněj, nebo úplně zanikne přenášená informace.

Modlim se za nas za vsechny, aby i nadale trvala stavajici ekonomicka situace, ktera zarucuje, ze se miliony 'pracujicich' mohou vydovadet s blbinamia a jeste za to berou slusne penize. Nedovedu si predstavit, co se stane, kdyby mela prijit krize.

V čem selháváš je adaptace na současnou situaci, kde prostě je poptávka po konkrétní prací. Až bude krize, tak budu řešit krizi, momentálně tu ale žádná není. Uznávám, že je třeba dobré se předem připravit, ale zrovna odmítat kvůli tomu práci není příprava.

Nedovedu si predstavit, co se stane, kdyby mela prijit krize.

Krize už přišla a stalo se co? Hovno. Ale jen pro pořádek - kdyby se tentokrát stalo něco vážnějšího, tak prostě půjdu a budu pěstovat brambory na jihu Čech, mám tam jako nejstarší syn statek a dědičných 12 hektarů polí i se zemědělskou technikou, děkuji za optání.

[xkucf03]

Začátečníci a neprofesionálové typicky hodně zanedbávají unittesty a o integračních testech většinou ani neslyšeli. Minimálně unittesty by měl mít každý projekt

Já bych doporučoval opačné pořadí a upřednostnil integrační testy, protože ty jsou z hlediska kvality výsledného produktu důležitější. Jednotkové testy jsou spíš taková pomůcka pro vývojáře – ano, užitečná pomůcka (a tím spíš by lidi měli dojít k tomu, že je budou psát dobrovolně), ale s kvalitou (ve smyslu shody implementace se zadáním) až tak moc nesouvisí.

A mám dojem, že řada jednotlivců/týmů vyplýtvá svoji chuť/kapacitu pro psaní automatizovaných testů na těch jednotkových – a na ty integrační jim pak nezbude prostor.

[Fluttershy, yay!]

TDD?

[deda.jabko]

Vzhledem k tomu, ze autor se domniva, ze je dobre delat velke projekty v Pythonu, unittesty jsou v jeho pripade nutnost, protoze supluji roli typoveho systemu a kontroly prekladace .

[Bystroushaak]

Mě vždycky baví, jak lidi onanují nad typovým systémem, když reálně zrovna to suplování typového systému a kontroly překladače je to, co mě na unittestech zajímá asi úplně nejmíň a patří to chybám, se kterými se nesetkávám skoro vůbec. Prostě jak je rok dlouhý, tak jestli to dělá třeba 5% chyb, tak přeháním. Přitom v úplně každé diskuzi o pythonu se zákonitě objeví někdo, kdo přijde a začne tvrdit, jak je python k ničemu, když nemá statické typování (což má, jen to používají hlavně lidi, co v něm stejně píšou javu).

Unittesty považuji za důležité, protože dodávají podrobnější specifikaci. Pointa není v hřejivém pocitu, že teď je to jako všechno super a dobře, když jsem si k tomu napsal testy, ale naopak v tom, že můžu s klidem dělat refactoring a být si přiměřeně jistý, že jsem nic nerozbil. K tomu je například typový systém úplně k ničemu, a to úplně vynechávám, že ho většina lidí nakonec znásilní design patternama tak, že překladač stejně nic neodchytí.

[ehm]

Tak PEP 484 "Type Hints" fakt není statické typování.

[Bystroushaak]

To na jejich základě přidává mypy.

[ehm]

Jasně, ale funguje to jen na argumenty a návratové hodnoty. Je to sice asi nejužitečnější případ (slouží to i jako dokumentace), ale za plnohodnotné statické typování bych to zrovna neoznačil.

Fun fact: Nechce se mi pouštět do dalšího language flamewaru poté, co jsem musel předefinovat univerzálně použitelnou konstantu, kterou se autor rozhodl udělat package-protected a já nebyl ve stejném packagi. Je to debilita autora, ale člověk si v tu chvíli steskne po Pythonu, Groovym nebo jakémkoliv jazyce, kde se s podobnými modifikátory šetří. (Tu knihovnu už přepisuju, protože je to neskutečný bastl odshora dolů.)

[Bystroushaak]

Jasně, ale funguje to jen na argumenty a návratové hodnoty. Je to sice asi nejužitečnější případ (slouží to i jako dokumentace), ale za plnohodnotné statické typování bych to zrovna neoznačil.

Python je k tomu ještě silně typovaný, což je dohromady prakticky to samé. Jediná výjimka už jsou pak asi jen proměnné.

[ehm]

Vím, že je silně typovaný – jinak bych se s ním vůbec nezaobíral.

Jinak, někdo tu před časem dával odkaz na autocomplete pro Python, nebo tak něco, ne? Před časem jsem používal PyDev a ten fungoval docela slušně, ale mělo to svoje nedostatky.

[smazáno]

jedi

pydev je fuj :)

[smazáno]

vzdyt to od dedy byla ocividna provokace :)

[smazáno]

Ale kdyz uz flame, tak proc ne .... Ale nesrovnavej s javou (to je hodne nefer srovnavat nejlepsi typing optional jazyk s nejhorsim static typing jazykem :)) ... vzdy me bavi na Jave pobavi, kdyz kvuli striktni kontrole typu misto jednoho radku kodu musis nadefinovat 10 ruznych trid ... a jak ty typy pomahaji citelnosti a pomahaji nachazet chybi :)

[Bystroushaak]

Já ho nechci srovnávat s javou, ale je fakt, že často potkávám lidi, co python nepochopí a pak v něm píšou javu a zrovna oni typicky nadávají na to, že nemá statické typování. Zrovna nedávno jsem se zase málem zeblil z kódu, který byl plný ITříd, protože si tam prostě někdo chtěl definovat všude interface, i když to vůbec nedávalo smysl a kdyby náhodou ano, tak je tu pořád abc.

[ehm]

Definovat úplně zbytečné třídy/interfacy je na přesdržku i v té Javě. Když někdo neví, co dělá, tak je to pak těžké. Ale zrovna prefixování jmen interfaců s „I“ je rozšířenější spíš v C++, C# a možná PHP, v Javě to standardní jmenná konvence není. Když jsme u toho, tak je to naprosto zhovadilá jmenná konvence, podobně jako maďarská notace v C. Pokud se jméno interfacu nedá smysluplně zvolit bez prefixu (a následných kolizí), poukazuje to na to, že takový interface nedává vůbec smysl.

[Bystroushaak]

Javě to standardní jmenná konvence není.

Není, ale používá se to v py. Zavedlo to tuším Zope a javista, který pak hodí do google výraz "python interface" narazí právě na tuhle konvenci.

[kralyk z abclinuxu]

Mě vždycky baví, jak lidi onanují nad typovým systémem

Souhlasím, že mezi lidmi je dost v kurzu onanie nad typovými systémy, ale onanie nad unit testy nebo Something Driven Developement mi nepřijde o nic lepší. (Btw. Hammock Driven Developement? Srsly? Doufám, že to je vtip / parodie. Jestli ne, tak by se to mělo urychleně postnout na r/programmingcirclejerk.)

Jak z diskuse tak blogu mám dojem, že pohled, který nabízíš, je takový dost zjednodušený.

Unit testy a integrační testy jsou hezká věc, ale jsou drahé. Kdybych měl pustit veškeré testy na celém našem produktu, trvalo by to nevim jak dlouho, ale klidně třeba dva dny, možná víc, zejména pokud bych chtěl testovat na více platformách, architekturách nebo obě varianty buildu (debug / nondebug). Takže před začleněním pouštím testy jen vždy na těch částech, které jsou postiženy změnami, a i tak to je celkem časově náročný. Integrační nástroje se snaží odhadovat, které části jsou změnou zasaženy a vývojáře na to upozorňují, ale ultimátně je to zodpovědnost jeho a těch, co mu dělají review.

IMHO je fajn mít co nejvíce věcí podchyceno už v buildu, statická analýza je oproti testům problémy zachycuje časněji, blíže ke zdroji a poskytuje lepší informace k hledání původu problému. Udržet v pořádku codebase je z tohohle pohledu se staticky typovaným jazykem prostě snažší. Ano, člověk může dělat všelijakou statickou analýzu i na Pythonu (a je pravda, že v oblasti statické analýzy Pythonu bychom mohli build systém určitě vylepšit), ale nikdy to nebude na takové úrovni jako v C/C++/Javě/atd. Type Hints jsou dost chabá náhrada.

[Bystroushaak]

Btw. Hammock Driven Developement? Srsly? Doufám, že to je vtip / parodie. Jestli ne, tak by se to mělo urychleně postnout na r/programmingcirclejerk.

Co se na to třeba podívat, než se předem rozčilovat podle titulku? Je to docela dobrý talk, kde autor clojure mluví o tom, že je lepší prvně přemýšlet, než programovat.

Jak z diskuse tak blogu mám dojem, že pohled, který nabízíš, je takový dost zjednodušený.

Tak to určitě. Tohle neměl být argument do pranice o výhodách EP a TDD, ale praktický návod pro začátečníky orientovaný na to, co se budou muset naučit. Což prostě imho ve většině firem budou muset.

Unit testy a integrační testy jsou hezká věc, ale jsou drahé. Kdybych měl pustit veškeré testy na celém našem produktu, trvalo by to nevim jak dlouho, ale klidně třeba dva dny, možná víc, zejména pokud bych chtěl testovat na více platformách, architekturách nebo obě varianty buildu (debug / nondebug). Takže před začleněním pouštím testy jen vždy na těch částech, které jsou postiženy změnami, a i tak to je celkem časově náročný. Integrační nástroje se snaží odhadovat, které části jsou změnou zasaženy a vývojáře na to upozorňují, ale ultimátně je to zodpovědnost jeho a těch, co mu dělají review.

Drahé jsou většinou integrační, ne unittesty.

IMHO je fajn mít co nejvíce věcí podchyceno už v buildu, statická analýza je oproti testům problémy zachycuje časněji, blíže ke zdroji a poskytuje lepší informace k hledání původu problému. Udržet v pořádku codebase je z tohohle pohledu se staticky typovaným jazykem prostě snažší. Ano, člověk může dělat všelijakou statickou analýzu i na Pythonu (a je pravda, že v oblasti statické analýzy Pythonu bychom mohli build systém určitě vylepšit), ale nikdy to nebude na takové úrovni jako v C/C++/Javě/atd. Type Hints jsou dost chabá náhrada.

Eh, co pořád všichni máte se statickou analýzou. Já jí teda provádím taky pomocí externích nástrojů (tři různé lintery), ale nepřijde mi to jako nějaká spása. Dělal jsem i ve staticky typovaných jazycích a to procento chyb, které to vyřešilo mi vždycky přišlo jako úplně nezajímavé. Ani si nevzpomínám, kdy naposledy jsem řešil problém typů, zato každý den řeším problémy v logice (asynchronní programování, kde se ti vynořuje emergentní chování je v tomhle zábava), nebo změny specifikace.

Největší výhodu unittestů vidím v strojově definované specifikaci chování. Pak se nemusím bát dělat extenzivní refactoring, protože prostě vím, že to bude (nebo nebude, a pak vím hned co a jak) odpovídat specifikaci i bez toho, abych to pak hodinu testoval.

[xkucf03]

Drahé jsou většinou integrační, ne unittesty.

„Drahé“ ve smyslu porovnání nákladů a přínosů by nemělo být ani jedno a z dlouhodobého hlediska by se to mělo vyplácet. (to, že se často zabředne do technologického dluhu a upřednostní se krátkodobé cíle – např. vydat verzi v předem stanoveném termínu – je věc jiná)

Jinak ale dobře napsané jednotkové testy jsou hodně drahá záležitost – často zaberou stejně nebo i více času než psaní implementace.

Dělal jsem i na projektu, kde jsme měli požadavek na 100% pokrytí kódu (větví, ne jen řádků), což se týkalo nového kódu – testy pro ten starý se dopisovaly postupně, tam to bylo někde kolem 95 %. Kromě toho tam byl tým testerů (i když schopnostmi spíš na úrovni programátorů v běžných firmách), kteří psali automatizované integrační/systémové testy. K tomu lidi, co se starali o vydávání verzí, kvalitář… A bylo to fajn, měl jsem z té práce mnohem lepší pocit než jinde (kde se většinou vyvíjí a nasazuje ve větší nejistotě). Nicméně to je poměrně drahý způsob vývoje. Pokud bych si jako manažer nemohl takový luxus dovolit a musel něco seškrtat, tak by to byly jednotkové testy (nemusí být 100 %), nikoli integrační (těch naopak 100 % být musí nebo se zbytek musí dotestovat ručně).

[Josef Kufner]

Záleží, jaké škody může neotestovaný kód napáchat. Pokud možné škody jsou menší než cena vytvoření a údržby testů, tak se důkladné testy prostě nevyplatí. Pro udržení rychlosti vývoje a možnosti refactoringu je dobré alespoň nějaké základní testy mít, ale hodně záleží na tom, co se vlastně dělá. Dobře udělané unit testy se dají použít pro samotný vývoj knihoven, i když aplikace ještě vůbec není. Na druhou stranu, příliš důkladné testy je potřeba průběžně udržovat, jak se kód mění a testy se rozbíjejí.

[xkucf03]

S tím souhlasím. Mluvil jsem o komerčním/seriózním vývoji. Ale pak je spousta vývoje, kde jsou ty potenciální škody, jak píšeš, malé a kvalita daná samotnými schopnostmi programátora a tím, že dělá málo chyb, je dostačující. Tam se nevyplatí maximalizovat pokrytí testy a je lepší ten čas věnovat implementaci nových funkcí.

[Josef Kufner]

Mluvil jsem o komerčním/seriózním vývoji.

Však jo. Je spousta komerčních a seriózních aplikací, kde jsou nároky na robustnost velmi nízké a nijak moc nevadí, když se v produkci používá vývojová verze. Na jednu stranu to může znít naprosto šíleně, obzvlášť pro někoho zvyklého na provoz nějakých kritických systémů, ale na druhou stranu takových věcí, kde menší problémy nevadí a může se počkat na opravu, je docela hodně. Typicky jde o nástroje používané někde v pozadí a v lepším případě i stranou od zákazníků.

[kralyk z abclinuxu]

Co se na to třeba podívat, než se předem rozčilovat podle titulku? Je to docela dobrý talk, kde autor clojure mluví o tom, že je lepší prvně přemýšlet, než programovat.

Ale jo, ono to nejspíš bude dobrý, jen se mi prostě trochu nelíbí ten přístup, kdy má potřebu to zabalit do buzzwordu, navíc ještě takhle přiblblého (s hamakou nemá téma vůbec nic společného). Proč? Tím své přednášce akorát škodí...

Je ale pravda, že tehdy ještě takový hype okol X Driven Developement nebyl...

nebo změny specifikace

Změny specifikace se typicky do type systému promítají.

Největší výhodu unittestů vidím v strojově definované specifikaci chování. Pak se nemusím bát dělat extenzivní refactoring, protože prostě vím, že to bude (nebo nebude, a pak vím hned co a jak) odpovídat specifikaci i bez toho, abych to pak hodinu testoval.

Tak zrovna u refactoringu nebo psaní nové funkcionality mi type system přijde jako přínos, už jenom proto, že odhaluje chyby v kódu, který jsem právě napsal, pro který zatím vůbec žádné unit testy nejsou. "Extenzivní refactoring" mi přije jako něco, kde se spousta unit testů vyhází a budou potřeba nové.

Krom toho, ano, unit testy jsou výrazně levnější než integrační, ale zadarmo nejsou a inkrementální kompilace je stále výrazně rychlejší / pohodlnější. Poznají tvé unit testy, kterou část kódu jsi právě změnil a je potřeba ji verifikovat?

Jinak nevykládej si to prosím tak, že krtizuju unit testy, to uričtě ne, jsou fajn. Jenom prostě zároveň i přes unit testy vidím celkem velký přínos type systému.

[xkucf03]

"Extenzivní refactoring" mi přije jako něco, kde se spousta unit testů vyhází a budou potřeba nové.

+1

Ono záleží, co je pro tebe ta jednotka. Typicky je to jedna třída a ta má jen pár metod. Takže pak můžeš refaktorovat/optimalizovat leda kód uvnitř metody, ale jakékoli větší změny ti rozbijí testy a musíš je přepsat (což je jednak pracné a jednak to znamená, že v tu chvíli můžeš udělat stejnou chybu v implementaci i v testu – např. si budeš myslet, že nějaký předpoklad o vnějším okolí jednotky platí a on přitom neplatí, takže napíšeš blbě jak kód, tak test a vyjde ti, že je to celé OK).

Pokud za jednotku prohlásíš něco většího, tak se posouváš spíš k těm integračním/systémovým testům.

Při refaktoringu nebo optimalizaci chci mít hlavně jistotu, že se pro moje okolí chování té komponenty nezmění. Pokud tím okolím myslím ostatní třídy, tak se dá vystačit s jednotkovými testy. Jenže když je refaktoring/optimalizace rozsáhlejší, tak tím okolím nejsou nějaké třídy a ostatní kolegové z týmu, ale je tím okolím uživatel nebo nějaký jiný systém, který s tím mým systémem komunikuje třeba po síti nebo formou nějakých souborů – a tady mi jsou jednotkové testy celkem na nic a potřebuji ty integrační/systémové.

[Bystroushaak]

Ale jo, ono to nejspíš bude dobrý, jen se mi prostě trochu nelíbí ten přístup, kdy má potřebu to zabalit do buzzwordu, navíc ještě takhle přiblblého (s hamakou nemá téma vůbec nic společného). Proč? Tím své přednášce akorát škodí...

Eh? Autor si právě dělá srandu ze všech možných buzzwordů a s hamakou to má společného spoustu. Popisuje tam svoje zkušenosti z vymýšlení clojure, kde celé dny ležel s v hamace a kreslil si do poznámkového bloku a argumentuje, proč mu to přijde lepší než sedět u počítače a tak podobně. Fakt se mi to nechce celé převyprávět.

Jinak nevykládej si to prosím tak, že krtizuju unit testy, to uričtě ne, jsou fajn. Jenom prostě zároveň i přes unit testy vidím celkem velký přínos type systému.

Ok.

[Bystroushaak]

"Extenzivní refactoring" mi přije jako něco, kde se spousta unit testů vyhází a budou potřeba nové.

Jinak jo, to je do velké míry pravda. Ale když to člověk bere jako určitou formu lešení, které se staví okolo budovy před tím, než se na ní udělají změny, tak to přestane působit tak tragicky. Lidi co dělají bez testů mají samozřejmě pravdu, že je jednodušší se slaňovat z vrcholu střechy na lanech, já mám ovšem radši jistotu lešení :)

[deda.jabko]

Mě vždycky baví, jak lidi onanují nad typovým systémem,

Kdybych chtel provozovat masturbaci nad typovymi systemy asi bych nepouzival lispove jazyky. ;-]

když reálně zrovna to suplování typového systému a kontroly překladače je to, co mě na unittestech zajímá asi úplně nejmíň a patří to chybám, se kterými se nesetkávám skoro vůbec.

K dokonalosti uz chybi jenom to, aby sem prisel Ondrej Novak a vysvetlil nam, ze on v C++ nema vubec zadny problem s pointery.

Unittesty považuji za důležité, protože dodávají podrobnější specifikaci.

A typovy system dela co?

[dementni.lojzik]

IMHO zalezi na cem delas. Kdyz delas na necem slozitejsim/rozsahlejsim, tak nahodit cely stack a pak hledat, co je kde spatne, muze byt o dost slozitejsi, nez napsat jednotkovy test, kde bude chyba videt na prvni pohled. IMHO je idealni delat neco mezi (napr. v pripade JEE napsat test s arquillianem nebo mit treba neco podobneho vyvinuteho pro dany dany projekt jako test harness ... tohle ja osobne porad povazuju za unit test) a pak teprv psat integracni testy

[Bystroushaak]

Já bych doporučoval opačné pořadí a upřednostnil integrační testy, protože ty jsou z hlediska kvality výsledného produktu důležitější.

Může být. Pro spoustu projektů ale nedávají moc smysl (například interaktivní aplikace), nejsou dostatečně komplexní (unittesty jdou víc do hloubky), nebo jsou mimo dosah začátečníků. Unittesty pak stejně bude každý dřív nebo později potřebovat, až se pustí do refactoringu.

Jinak u důležitějších projektů se asi vyplatí mít přímo testera, který bude na základě specifikace (integrační) testy vytvářet.

[Josef Kufner]

Hlavní je mít alespoň nějaké testy. Jestli jsou integrační nebo jednotkové je úplně putna. A většinou je nejlepší je mít od každého něco a trochu to namíchat. Často dokonce stačí to tak nějak spustit a zkontrolovat, že to nespadlo.

[multi-kulti]

Jestli jsou integrační nebo jednotkové je úplně putna

neřekl bych. Integrační testy mají absolutní prioritu. V Německu je chtějí zavádět pro ty migranty.

[pavlix]

Jasně, stačí mít jenom nějaký ten testíček, aby se neřeklo. Jdu blejt.

[smazáno]

Podle me to JK myslel prave obracene - hlavni je mit takove testy co jsou opravdu potreba a ne masturbovat ze mame tolik a tolik integracnich a tolik a tolik unit testu ...

[Kalašnikov]

IMHO, k tomuhle ten tučňák nepatří. Zdar!

[Max]

Já to do digestu nedal, ale kdyby to tam nebylo, tak bych to tam dal. Takže s tebou nesouhlasím :).
Zdar Max

[miriam je těhotná s kotyzem]

Maxi, ještě pořád seš panic?

[V.]

Tučňák neni jen o linuxu ale i o vyšší dívčí v IT. Co Vy na to?

[Bystroushaak]

Tučňák tady slouží jako indikátor zápisků „to si asi chcete přečíst“, doslova je dává do kategorie „výběr (linuxové)“. Kolikrát je i u věcí, které s linuxem nemají vůbec nic společného, jen jsou prostě dobře napsané.

Rád bych zároveň dodal, že jsem nikdy svému vlastnímu blogu nedal tučňáka, u všech to udělali jiní lidé.

[vencour]

Co tam asi stojí ...

Výběr zápisků, které se týkají Linuxu, Open Source či IT. Žádná politika.

[Bystroushaak]

Ehm, kdo mluvil o politice?

[vencour]

Proč že je tam zdůrazněné to IT?
Citoval jsem z tutoho odkazu, vpravo skoro nahoře.

[Bystroushaak]

Aha, sorry, toho jsem si nevšiml, nedošlo mi, že je to přesná citace.

[BFU]

Proc by melo byt pro BFU tezke naprogramovat NP-uplny algoritmus ? To v tom uvodu prilis nedava smysl.

[DW]

BTW: máte někdo tipy/doporučení, jak komunikovat s (věkově) staršími, ale jinak juniornějšími kolegy? Ono jedna věc je vyškolit (v dobrém) nějakého čerstvého absolventa a předávat mu svoje rady. Ale když máte totéž dělat s člověkem třeba o deset let starším než jste vy, tak je to složitější. Jasně, když má člověk lepší znalosti a pravdu, tak si to vyargumentuje a osobně mám zkušenost, že ty připomínky i starší kolegové celkem berou, ale stejně z toho nemám úplně dobrý pocit a nad některými menšími chybami při revizi radši mávnu rukou. I když v případě juniora bych to řešil a snažil se s ním na tom pracovat.

[Kate]

Tak nevím jestli se počítám jako o tolik starší, ale na programování jakožto zaměstnání jsem se vrhla až v 30, do té doby jsem byla adminka a ač jsem programovala od základky, vždycky jen drobnůstky pro sebe. případně nějaké ty skripty na serverech. Takže i teď v 31 potkávám o pět let mladší kolegy, kteří jsou v lecčem o dost zkušenější. Ale i kdyby zkušenější nebyli. Člověk který chce být v něčem dobrý nesmí trpět představou o své vlastní dokonalosti. U programování stejně jako v mnoha jiných podobných oborech platí, že se člověk musí učit pořád. Takže stejně jako jsem neměla jako junior problém zajít za o 15 let starším senior kolegou a říct mu, že to co napsal je zbytečně komplexní a dá se to řešit elegantněji, stejně tak mi nevadí, když mi někdo ukáže že dělám někde blbosti já.

Prostě, nebála bych se říct mu. Pokud to není trotl co si myslí že s věkem přichází automatická všeznalost a nadřazenost nad mladším plebsem (s čímž se bohužel taky občas potkám), vyslechne si kritiku rád. A jestli ne, aspoň budeš vědět, na čem jsi :) Pochopitelně, dost udělá i styl jakým mu to řekneš.

Osobně jsem ráda že nic takového v teamu nemáme.

[Fluttershy, yay!]

i teď v 31

Hotová vykopávka.

Mám podezření, že předřečník myslel lidi řádově dvakrát tak staré.

[Kate]

Jasně, nejsem nijak stará, proto zmiňuji i podstatně starší kolegy. Každopádně, pokud ke mě s něčím přijde někdo komu je 20, ten věkový rozdíl znát je :)

Hlavní pointa byla, že předávání znalostí a zkušeností by mělo probíhat nezávisle na věku. I když ke mě přijde někdo kdo má míň praxe a zároveň je mladší než já, neznamená to že nemá pravdu a já se nemůžu něčemu přiučit.

[Fluttershy, yay!]

Tak jistě, byl tam ten příklad s deseti lety a rozdíl mezi skoro-určitě-absolventem a už-ne-absolventem rozhodně je, ale mně to přijde zajímavější v případě, že jsou strany generačně, hodnotově,… někde jinde (což teda vede i na další diskuze, např. nakolik v tomhle odvětví figuruje věková diskriminace).

[Kate]

Když si to tak vezmu, tak jsem se sekla, můj nejstarší kolega se kterým jsme se chytli nad kódem byl vlastně skoro 2x starší než já. A opravdu nebyl problém pokecat si nad kódem a dojít k tomu, že část přepsal. Taky jsem mohla v průběhu přijít na to, že má pravdu a za jeho postupem je určitý záměr. Dobrý výsledek je to v obou případech :)

Osobně si nemyslím že by byl problém s generačními rozdíly, alespoň jsem na něj nenarazila. Spíš je občas problém s elitářstvím a je jedno jestli je to elitářství založené na „za našich mladých let se to programovalo takhle, což ty jako děcko fakt nepochopíš“, nebo na „je mi stejně jako tobě a přispívám do 20 OSS projektů, tak mlč a drž krok“, případně „mám doktorát, tak to asi budu vědět dobře“. Ani s jedním toho moc nenaděláš.

[Radovan]

„za našich mladých let se to programovalo takhle, což ty jako děcko fakt nepochopíš“

http://www.misantrop.info/noveho-psa-starym-trikum-nenaucis/

[Bystroushaak]

Tak nevím jestli se počítám jako o tolik starší, ale na programování jakožto zaměstnání jsem se vrhla až v 30, do té doby jsem byla adminka a ač jsem programovala od základky, vždycky jen drobnůstky pro sebe. případně nějaké ty skripty na serverech. Takže i teď v 31 potkávám o pět let mladší kolegy, kteří jsou v lecčem o dost zkušenější.

Zajímavé. Co bys řekla k obsahu blogu? Máš k němu nějaké výhrady?

[Kate]

Tak pro mě byla asi největší bariéra přesvědčit se za 10 let, že na to mám :D Docela mi pomohlo zjištění, že ta profi sféra není plná naprostých guruů, kteří jsou o světelné kroky přede mnou. Možná bych opravdu přidala radu „nebát se toho a jít do toho“ :)

Jinak se vším souhlas. Hlavně ten důraz na schopnost učit se je dost důležitý. Nejen že to doslova vyhrává pohovory, ale bez toho se v oboru nedá přežít :)

[Bystroushaak]

Možná bych opravdu přidala radu „nebát se toho a jít do toho“ :)

To jsem několikrát psal v té sérii článků odkazované z perexu.

[ehm]

Pochopitelně, dost udělá i styl jakým mu to řekneš.

„Hěj, dědku, tak tos fakt posral!“

[pavlix]

To jsem ani nevěděl, že jsi můj ročník. :) Akorát teda pravda, že já jsem se vrhnul aktivně na programování cca o půl desetiletí dříve.

[Kate]

Já začala první program v 10, jen jsem prostě měla od prvního pracovního poměru strach něco programovat profi. „nemám na to, musím se ještě zlepšit“, klasika. Nakonec člověk dospěje k tomu, že se toho nejvíc naučí a zlepší se právě v práci :)

[pavlix]

Já jsem do nástupu k červeným kloboukům programoval jen relativně malé projekty, na nic víc jsem neuměl dosáhnout obchodně a do zaměstnání jsem nechtěl. Red Hat byl zatím první a prozatím i poslední firma, která mě přesvědčila ke vstupu do zaměstnaneckého poměru.

[Kate]

RH by mě myslím dokázal snadno přesvědčit také, jen je škoda že je tak daleko :) Ale Seznam je rozhodně také dobrá zkušenost.

[pavlix]

Nastupoval jsem tam na home office pod podmínkou, že u nich strávím první tři měsíce, kdy jsem byl navíc ještě part time. Podařilo se mi tam výhodně pronajmout na léto byt než se pronajme novým studentům, tak jsem zůstal i čtvrtý měsíc. Ale je fakt, že je to zase jiná zkušenost a mně tak nějak baví být všude doma. V poslední době zjišťuju, že jsem digitální nomád s usedlou rodinou, takže nomádím povětšinou na velmi krátkou dobu na vzdálenost max stovek kilometrů.

[pavlix]

Vlastně 90 % času nomádím v řádu desítek kilometrů a teď to možná ještě zkrátím.

[Kate]

Dlouhodobější práce z domova občasné nomádění by mě bavilo, jenže to chce (alespoň pro mě) menší změnu bytových dispozic, kterou výhledově chystáme :) Prostě, potřebuju mít nějaký dedikovaný koutek který je pracovna a mimo práci ho můžu zamknout. Jinak bych si za chvíli doma připadala pořád jako v práci :)

Což bych asi radila zkusit všem… Po minulé zkušenosti mi stačil měsíc a půl a zvládlo mi to dost narušit pohodu domova.

[pavlix]

Bez dedikovaného koutku jsem se musel obejít, i když teď bych takový maličký po přestěhování teoreticky mohl mít, navíc se mi pravděpodobně rychle podaří odlifrovat přes den zbytek rodiny mimo domov. Pracovní dobu dodržovat neumím, začínal jsem tak, že jsem se časově trefoval s amíkama a dost mi to vyhovovalo. Když jsem se začal přizpůsobovat evropskému režimu, trochu jsem trpěl.

[xkucf03]

Mít to fyzicky oddělené (samostatnou místnost) mi přijde dost velký luxus. Co třeba soukromé projekty nebo soukromé používání počítače? Na to budeš mít jinou místnost? IMHO bohatě stačí mít vyhrazenou VM/notebook/uživatele, které člověk po skončení práce na daném projektu zavře a má klid.

[Bystroushaak]

Mít to fyzicky oddělené (samostatnou místnost) mi přijde dost velký luxus. Co třeba soukromé projekty nebo soukromé používání počítače? Na to budeš mít jinou místnost? IMHO bohatě stačí mít vyhrazenou VM/notebook/uživatele, které člověk po skončení práce na daném projektu zavře a má klid.

Po vlastních zkušenostech jsem dospěl k názoru, že to není luxus, ale nutnost. Přeci jen, když třeba měsíc v kuse pracuješ a spíš a trávíš část volného času ve stejné místnosti, tak to přestane být psychicky zdravé.

Neříkám teda hned celou místnost věnovanou jen práci, spíš zvlášť stůl, nebo třeba chodit různě po coworkingových centrech a tak. Mít na to oddělené prostředí je dobré i z toho důvodu, že pak nemáš tendence to všechno míchat.

[Rezza]

Napis mi, trebas neco vymyslime :).

PS: muzu jen otravovat lidi nez neco primo nabidnout...

[Kate]

Ale co, doháním to docela obstojně :D

[Kalašnikov]

Tak tu nekrafaj a jdou se učit, nebo z nich nic nebude!

[projekťák]

můj osobní nazor a zkušenosti z firmy 30 lidí (Rakousko). Také jsme měli několik kolegů 50+ a s komunikací byly problémy. Poznámky ohledně kódu byly brány vesměs osobně a argumentace staršího kolegy končila větou, že jeho zkušenosti mu říkají, že námi navrhované řešeni povede za pár let k problémům. Agilní metody, týmový práce, to vše bylo pro ty pány další novodobý nesmysl, kterých už zažili haldu. Nakonec vedení rozhodlo, že bude nejlepši ty kolegy z firmy 'odejít'.

U většiny se to podařilo vcelku rychle - přidělí se nepříjemná práce, veřejná kritika i maličkostí a normální člověk brzy pochopí, že je třeba se poohlédnout jinde. Jen jeden bývalý kolega se držel toho pracovního místa zuby nehty. Naooko se dokonce snažil se přizbůsobit, poníženě akceptoval jakekoliv výtky a trochu omezil i predchozí nekonstruktivní přístup. Přesto ale takového člověka nikdo nepředělá, atmosféra celá napjatá a vedení se bálo, že hrozí tučné odstupné. Nakonec se naštěstí zjistilo, že má nemocnou manželku o kterou musí denně pečovat. Tak mu vedení začalo přidělovat služebky i do zahraničí i třeba na týden. Přesto to trvalo 2 měsíce než to vzdal.

Celé to stálo dost energie, ale pod čarou se to vyplatí (někdy možná i za cenu menšiho odstupného), než se leta plahočit s kolegy, s kterými z důvodu věkového rozdílu komunikace prostě není možná.

[Kate]

Ono je to asi o firmě a o lidech. Pokud firma jede neustále ve starých kolejích a má bandu starších programátorů co už 30 let programují pořád stejně a to samé, narazíš na bariéru už jen kvůli tomu, že tu propast mezi nimi a mladými už prostě nemají šanci překonat. U firmy která se technologicky neustále rozvíjí to bude vypadat jinak.

[Princ Druhý]

Vypadá to, že máš spoustu zkušeností... Na ty starší je tohle asi dobrý postup. Jenže co s mladými a neschopnými? Ti se o nikoho starat nemusí a někteří v práci vydrží běžně vysedávat třeba i do devíti večer. Na služebku je poslat nemůžeme, protože by tam dělali ostudu. Po večerech někdy vygenerují tolik kódu, že to úplně zahnojí Git a co je horší, zablokuje to druhý den seniorního vývojáře, který tomu pak musí dělat revizi a musí s mlamojem diskutovat. Asi budeme muset zavést pull requesty, abychom eliminovali aspoň největší škody (na takhle rozvrtaném projektu nemůžou pracovat ostatní).

[Kate]

Uf. Sice můžeme do gitu přispívat kdykoliv kdokoliv, ale myslím že někdo kdo by zkoušel obcházet code review a rovnou hnojil master / devel branche gitu by moc dlouho nepřežil :) Tohle si opravdu říká o změnu procesů.

[Heron]

Nakonec se naštěstí zjistilo, že má nemocnou manželku o kterou musí denně pečovat. Tak mu vedení začalo přidělovat služebky i do zahraničí i třeba na týden. Přesto to trvalo 2 měsíce než to vzdal.

Není nad férový a lidský přístup. Lze zveřejnit jméno té firmy, aby se tomu ostatní mohli vyhnout?

[pavlix]

Je otázka, jestli to není trestný čin, takže se do zveřejňování jména firmy asi jen tak hrnout nebude.

[xvasek]

BTW: máte někdo tipy/doporučení, jak komunikovat s (věkově) staršími, ale jinak juniornějšími kolegy?

Tip mám, je úplně jednoduchý. Vlastně nemusíš dělat vůbec nic, toto je problém, který se vyřeší úplně sám. Prostě jenom zestárni.

[DW]

Jako že mi to pak bude jedno?

[xvasek]

Ne, je to celé horší. Postupně se z tebe stane ten, kdo bude trvat na starých pořádcích, nepůjde se s ním domluvit a kterého se budou snažit školit mladí zobáci. Dobrá zpráva je, že z tvého pohledu to je PNJ.

[pavlix]

Obávám se, že tohle asi fungovat nebude. Alespoň ne u mně, kde ten problém v komunikaci není věkem. Naopak u mně zafungovalo přestat si holit tvář, to starším rýpalům do velké míry zavřelo hubu. :)

[JS1]

To mi nejak tedy neni zcela jasne, jak jste to tam vlastne u vas komunikovali.

[pavlix]

To nebylo u nás.

[moloko]

byl to dobrý programátor ... řekl lidojed.

[xvasek]

Článek se lživě snaží vyvolat dojem, že ještě existují vývojáři, kteří ví, co je to git nebo unittest. A pokud by takoví teoreticky existovali, že se nějakou netriviální dobu nachází na trhu práce a nevezmou je v první firmě, kam pošlou CV. Ha ha, moc vtipné.

[Bystroushaak]

Článek se lživě snaží vyvolat dojem, že ještě existují vývojáři, kteří ví, co je to git nebo unittest. A pokud by takoví teoreticky existovali, že se nějakou netriviální dobu nachází na trhu práce a nevezmou je v první firmě, kam pošlou CV. Ha ha, moc vtipné.

Článek se snaží vysvětlit lidem, kteří tu práci ještě nikdy nedělali, co se budou muset všechno naučit. Pokud to z něj není dost jasně vidět, tak jsem to asi špatně napsal.

[xvasek]

Ne, článek máš pěkný, to měla být ironie. Co popisuješ - tzn. nějaké odmítnutí zaměstnance, protože se přihlásilo X a je potřeba jenom Y - probíhalo podle mého někdy tak dva tři roky zpět. Dnes, pokud člověk umí něco aspoň přibližně podobného tomu ve vypsané pracovní pozici, nemá šanci neuspět. (Tím "umí" myslím "umí", ne že to má napsané v CV.)

[Bystroushaak]

Jo takhle. S tím souhlasím, ale nepřijde mi, že to platí u lidí, kteří jdou do první práce. Tam imho přeci jenom pořád je šance, že bude odmítnut.

[pavlix]

Dost záleží na tom, kolik si řekne plat.

[Kate]

Jojo… Šéf i teď od pohovorů vyhazuje, ale je pravda že nevím co tam chodí… Občas to mohou být docela exoti, třeba v minulé práci se nám na pozici programátora hlásil bývalý dlaždič jehož vrchol IT vědomostí bylo vytvoření profilu na Facebooku :/

Začátečníkovi by teoreticky mohlo stačit i vyplnit si profil na LinkedIn a chvíli počkat :D

[pavlix]

Shánět si job přes LinkedIn mi připadá jako jedna z nejhorších možností vůbec. :D

[xvasek]

Tak vyhazovat se vyhazuje samozřejmě, protože drzost lidí nezná mezí a na prográmatora se hlásí jak píšeš... Ale stačí opravdu elementární znalost jakéhokoli jazyka - napíšeš 100 print "Prga!" a máš to. Bohužel na druhou stranu je nutno přiznat si smutný fakt, že takto hlubokou znalost programování nemá velmi často ani absolvent střední školy se zaměřením na informatiku půl roku po absolvování a musel by to najít na Google.

[kralyk z abclinuxu]

Mam trochu rozporuplné pocity z tohohle zápisku...

Zaprvé: Jsi si jistý, že máš zkušnosti a znalosti na takhle obecné programátorské FAQ? To není nic proti tobě, vím třeba, že já bych neměl. Ty máš (asi zřejmě) větší zkušenosti / praxi, ale nevim jestli až zas o tolik a přijde mi, že to FAQ je relevantní zejména pro job podobný tvému na podobné úrovni. S těmi postřehy / radami jako takovými souhlasím.

Zdaruhé, a to hlavně: Přijde mi to spíše jako druhý díl článku, kde první díl by měl pojednávat trochu více o "big picture". Co si pod tím představuju? Zejména jak dobře porovnávat a vybírat směry v rámci programování (programování obecně je velmi široký pojem). Jak vyhodnotit, co mě bude bavit a na co budu mít. Jak odhadnout do kterých technologií a do kterých projektů / ekosystémů v rámci FOSS investovat svůj čas. Jak vybírat a porovnávat firmy / nabídky práce. Jak odhadnout tým. Na co se ptát při pohovoru - tady mám na mysli otázky uchazeče na nabízejícího - mnoho lidí se soustředí zejména na dobré odpovědi, ale přitom otázky jsou neméně důležité.

Je mi jasný, že to nejsou jednoduché otázky (a vyžadují ještě více zkušeností / větší přehled), nicméně IMHO lidi, kteří se vrhnou rovnou na krok 2, se vystavují riziku, že je za nějakou chvíli dožene vyhoření nebo takněco...

[Bystroushaak]

Zaprvé: Jsi si jistý, že máš zkušnosti a znalosti na takhle obecné programátorské FAQ? To není nic proti tobě, vím třeba, že já bych neměl. Ty máš (asi zřejmě) větší zkušenosti / praxi, ale nevim jestli až zas o tolik a přijde mi, že to FAQ je relevantní zejména pro job podobný tvému na podobné úrovni. S těmi postřehy / radami jako takovými souhlasím.

Tohle má dvě úrovně pohledu. Jedna je čistě edukační a tam souhlasím, že potřebné zkušenosti nemám a je prostor se zlepšovat, asi tak příštích 50 let. Určitě je to taky biased a hodně zaměřené na mojí zkušenost.

Druhá úroveň je praktická. Lidi mi píšou a chtěj rady. Většinou jim odpovídám a nebaví mě se opakovat. Tak jsem to prostě sepsal a je to na světě. Samozřejmě nemám nic proti tomu, když někdo sepíše něco lepšího. Nedělám to proto, že se chci stavit do pozice autority, ale proto, že prostě potřebuju podobný materiál, abych to nemusel v emailech vysvětlovat zas a znova.

Přijde mi to spíše jako druhý díl článku, kde první díl by měl pojednávat trochu více o "big picture". Co si pod tím představuju? Zejména jak dobře porovnávat a vybírat směry v rámci programování (programování obecně je velmi široký pojem). Jak vyhodnotit, co mě bude bavit a na co budu mít. Jak odhadnout do kterých technologií a do kterých projektů / ekosystémů v rámci FOSS investovat svůj čas. Jak vybírat a porovnávat firmy / nabídky práce. Jak odhadnout tým. Na co se ptát při pohovoru - tady mám na mysli otázky uchazeče na nabízejícího - mnoho lidí se soustředí zejména na dobré odpovědi, ale přitom otázky jsou neméně důležité.

Ve skutečnosti je to pátý přídavek ke článku, který jsem linkoval v perexu. Iniciativě meze nekladu, pokud něco takového sepíšeš, tak na to budu rád linkovat a odkazovat lidi :)

[kralyk z abclinuxu]

Druhá úroveň je praktická. Lidi mi píšou a chtěj rady. Většinou jim odpovídám a nebaví mě se opakovat. Tak jsem to prostě sepsal a je to na světě. Samozřejmě nemám nic proti tomu, když někdo sepíše něco lepšího. Nedělám to proto, že se chci stavit do pozice autority, ale proto, že prostě potřebuju podobný materiál, abych to nemusel v emailech vysvětlovat zas a znova.

Jj, to dává smysl.

Ve skutečnosti je to pátý přídavek ke článku, který jsem linkoval v perexu. Iniciativě meze nekladu, pokud něco takového sepíšeš, tak na to budu rád linkovat a odkazovat lidi :)

To asi není úplně to, co jsem měl na mysli. Nicméně já asi aktuálně moc na to téma nenapíšu, protože to je něco, co hodně řeším a asi ještě řešit nějakou dobu budu... Tak možná potom

[John_Pitralon]

Každopádně všechny dynamické jazyky jako Python nebo Javascript by měly být zakázány zákonem, stejně jako tvrdé drogy. Dost by to pomohlo. Pro osobní potřebu možná, ale rozhodně to veřejně nešířit a nevyvíjet v tom v týmu, proboha. Protože práce některých dynamických umělců, to je pak jen hack na hack.

[pavlix]

Proč omezovat zákaz jen na ty dynamické?

[Bystroushaak]

Já bych rovnou zakázal všechny ty internety.

[John_Pitralon]

Jen ať si ti kouzelníci svoje prasokódy kompilují na nějakém normálním překladači. Ale to ne, každý musí mít Python, PHP, javascript...

[ehm]

V C se taky dá narazit na pořádné prasokódy...

[smazáno]

dokonce bych rekl ze v C je praseni na celkem vysoke urovni :)

[pavlix]

Někdy dokonce i na nízké úrovni. :)

[John_Pitralon]

To jo, prasit se dá ve všem, jenže tyhle jazyky k tomu přímo navádějí. Deklarovat si staticky typ proměnné? K čemu, to tadyhle vůbec nevedeme, zapomeň.

[ehm]

O tom se tu už diskutovalo několikrát celkem nedávno a asi k tomu není moc co nového dodat.

[Fluttershy, yay!]

*zív*

To je podobně nudný trolling jako s tím (ne)přistáním na Měsíci.

[ehm]

Trollil jsem trollil, ale málo, kolečko se mi v hlavě polámalo.

[John_Pitralon]

Proč trolling? To je realita. Ale kouzelníci v magických jazycích si poradí i bez překladače.

[ehm]

#!/usr/bin/env python3
javisti_to_proste_nechapou()

def javisti_to_proste_nechapou():
    pass

Traceback (most recent call last):
  File "./lol.py", line 2, in <module>
    javisti_to_proste_nechapou()
NameError: name 'javisti_to_proste_nechapou' is not defined

#!/usr/bin/env python3
class JavistiUzToMoznaChapou:
    def __init__(self):
        self.javisti_to_proste_nechapou()        

    def javisti_to_proste_nechapou(self):
        print("nechapou")

JavistiUzToMoznaChapou()

nechapou

[ehm]

#!/usr/bin/env python3
javisti_to_proste_nechapou = lambda x:
    x + 1

  File "./lol.py", line 2
    javisti_to_proste_nechapou = lambda x:
                                         ^
SyntaxError: invalid syntax

[ehm]

#!/usr/bin/env python3
import sys

def fib(n):
    if n == 0:
        return 0
    elif n == 1:
        return 1
    else:
        return fib(n - 1) + fib(n - 2)

print(fib(int(sys.argv[1])))

$ time ./javisti_to_proste_nechapou.py 40
102334155

real	0m37.583s
user	0m37.314s
sys	0m0.016s

public class JavistiToProsteNechapou {
    public static void main(String[] args) {
        System.out.println(fib(Integer.valueOf(args[0])));
    }
    
    static int fib(int n) {
        if (n == 0) {
            return 0;
        } else if (n == 1) {
            return 1;
        } else {
            return fib(n - 1) + fib(n - 2);
        }
    }
}

$ time java JavistiToProsteNechapou 40
102334155

real	0m0.549s
user	0m0.541s
sys	0m0.012s

Sice je Python jen 68x pomalejší, ale stejně budem radší držkovat na takový ty divný lidi, co píšou v tom divnym jazyce, kde přes všechny ty abstrakce ani neví, co se děje pod povrchem! Aspoň je to cool a dynamický, neasi. Tam rupnu lambdu, bo haj ordr fankšn (tož jedinej pojem z funkcionálního programování co znám, krom funkce teda, ale to je i v matice a ta taky neni zas tak kůl pyčo), a nemusim mít péči. Se to všecko vyoptimalizuje a bude to rychlý jak čyp, nepíšu přece v Javabolu, kde aby měl jeden strach zavolat si virtuální metodu, pyčo! Neumym vočima přelouskat ani 12 let starej článek od soudruhů z IBM, tak můžu dál bastlit a vědět hovno, protože emoce jsou víc jak benchmark.

[pavlix]

Netroufal bych si z toho tvrdit, že je pomalejší zrovna 68-krát, ale to, že Pythoní kód vyšel pomalejší než Javovský kód je snad vcelku očekávatelný výsledek, ne? Nějak nemůžu přijít na to, co je na vašem zjištění tak objevného a překvapivého.

[xkucf03]

že Pythoní kód vyšel pomalejší než Javovský kód je snad vcelku očekávatelný výsledek, ne?

Tak proč pořád tolik lidí nadává na údajnou pomalost Javy a vyzdvihuje Python?

Java má pomalejší start, protože se při něm načítá spousta věcí… – to je trochu hendikep při psaní CLI aplikací, kde pokaždé spouštíš nový proces a očekáváš okamžitou odezvu¹. Python vypíše rychleji Hello World, ale pak je asi ve všem ostatním pomalejší.

Jasně, můžeš říct, že některé části napíšeš v C a z Pythonu je zavoláš, ale to už pak nepíšeš aplikaci v Pythonu² – programátor musí umět C a přichází o výhody vyššího programovacího jazyka. Totéž bys mohl dělat v té Javě – přes JNA nebo JNI volat kód psaný v C/C++.

_{[1] na mém počítači to dělá nějakých 115 ms, což je celkem použitelné i pro ty CLI aplikace
[2] trochu mi to připomíná situaci, kdy se někdo tváří, že dělá webovou aplikaci, ale ve skutečnosti ten web jen odkazuje na ActiveX nebo Flash komponentu}

[pavlix]

Tak proč pořád tolik lidí nadává na údajnou pomalost Javy a vyzdvihuje Python?

Odpověď na první otázku je, protože se známé a oblíbené programy v Javě projevují jako pomalé a těžkopádné. Odpověď na druhou otázku je, že je Python oblíbený jazyk a docela dobře se v něm píše.

Python vypíše rychleji Hello World, ale pak je asi ve všem ostatním pomalejší.

Ve skutečnosti nikoho nezajímá, který jazyk je rychlejší nebo pomalejší. Ve skutečnosti lidi zajímá, jestli můžou aplikaci plynule používat a jesti a jak moc budou na výsledky svých akcí čekat.

Jasně, můžeš říct, že některé části napíšeš v C a z Pythonu je zavoláš, ale to už pak nepíšeš aplikaci v Pythonu2 – programátor musí umět C a přichází o výhody vyššího programovacího jazyka.

Nemusí a nepřichází.

Totéž bys mohl dělat v té Javě – přes JNA nebo JNI volat kód psaný v C/C++.

Jenže to nechceš a nemůžeš. Přátelé javisté by tě považovali za blázna a vytěsnili by tě ze své prominentní komunity. :D

[JS1]

Tak proč pořád tolik lidí nadává na údajnou pomalost Javy a vyzdvihuje Python?

Proc? Protoze kdyz si porovname tri kriteria:

- Rychlost vysledneho kodu

- Slozitost zapisu programu

- Schopnost interoperability s jinymi jazyky (treba C/C++)

Tak z toho, pro velkou vetsinu projektu, vychazi Python podstatne lip.

Java je proste jeden z nejhur navrzenych popularnich jazyku. Neni to tak strasne jako PHP nebo Javascript, ale porad dost. Hlavni problem (navrhu) Javy je ideologicky, ale posledni dobou se to nastesti snazi spravit.

[xkucf03]

Rychlost vysledneho kodu

Java je na tom často líp, než si lidé myslí. Viz různé výkonnostní testy nebo viz aplikace pro práci s velkými daty nebo třeba fronty zpráv, které se v Javě píší.

Za problém s rychlostí dnes považuji snad jen těch cca 100 ms. připadajících na start JVM – což se týká vlastně jen CLI aplikací a i u nich je to často v pohodě (např. ls nebo cat bych v Javě implementované mít nechtěl, ale je spousta CLI programů, kde tohle zdržení nevadí). Většina aplikací běží delší dobu a tam je tohle zdržení při startu nepodstatné.

Slozitost zapisu programu

Složitost zápisu je do jisté míry subjektivní.

Neméně důležitá je i složitost porozumění cizímu kódu. Resp. je to ještě důležitější, protože kód napíšeš jednou, ale čteš ho mnohokrát – je potřeba se k němu opakovaně vracet, hledat a opravovat v něm chyby, přidávat do něj nové vlastnosti… Takže složitější jazyk umožňující napsat totéž s menším počtem řádků/znaků než Java, nemusí být nutně výhra.

Schopnost interoperability s jinymi jazyky (treba C/C++)

Viz JNA. Jen si napíšeš javovské rozhraní s hlavičkami metod, které odpovídají těm céčkovým funkcím, a jedním řádkem si načteš danou dynamickou knihovnu. Nebo tě napadá, jak by to šlo udělat jednodušeji (a zároveň typově bezpečně)?

[JS1]

viz aplikace pro práci s velkými daty nebo třeba fronty zpráv, které se v Javě píší

Ano, bohuzel se v tom pisi. Tak jsem pak napise, ze je to "scalable", coz je cim dal tim vic zkratka pro "je to neskutecne pomale, tak jsme to aspon udelali tak, aby to mohlo bezet na vice strojich, jinak by to totiz uz vubec nemelo smysl pouzit". Treba neznam databazi v Jave, kterou by Postgres nestrcil do kapsy.

Jinak o vsem co jsi napsal lide vedi, a presto si vyberou Python. Tak se s tim smir.

[pavlix]

Jinak o vsem co jsi napsal lide vedi, a presto si vyberou Python. Tak se s tim smir.

+1

Velmi často to není neinformovaný výběr.

[Agent]

Jinak o vsem co jsi napsal lide vedi, a presto si vyberou Python. Tak se s tim smir.

Jejich boj Já bych tam přidal ještě (ne)kompatibilitu.

Jinak proč se třeba ty bankovní věci nepíší v Pythonu? Konec konců, je snad i starší než Java, tak by měl mít náskok a když jej mají programátoři radši...

[Bystroushaak]

Jinak proč se třeba ty bankovní věci nepíší v Pythonu? Konec konců, je snad i starší než Java, tak by měl mít náskok a když jej mají programátoři radši...

Konzervatismus jak zmrd.

Zajímavější otázka spíš je, proč se dřív psaly ve Smalltalku a nikomu to nevadilo, když Smalltalk je na tom co do vlastností hodně podobný pythonu.

[xkucf03]

Asi se neosvědčil? Kdyby ano a navíc to prostředí bylo tak konzervativní, jak píšeš, tak proč by přecházeli na jiný jazyk?

[Bystroushaak]

Asi se neosvědčil? Kdyby ano a navíc to prostředí bylo tak konzervativní, jak píšeš, tak proč by přecházeli na jiný jazyk?

Afaik proto že byl nedostatek programátorů. Smalltalk si to hodně posral licencováním, které v podstatě znemožňovalo sehnat licenci, která by nestála stovky, nebo tisíce dolarů. Ve chvíli kdy se objevily použitelné opensource verze už se všude učila Java a Smalltalk tuhle bitvu prohrál.

Jinak částečně se ve Smalltalku v bankovnictví pořád dělá. Před pár lety jsem přemýšlel že tam nastoupím, dokonce jsem prvním kolem pohovorů, ale pak jsem dostal lepší nabídku na python.

[pavlix]

On se v tom bankovnictví uplatňuje i ten Python, čistě mezi námi. :)

[JS1]

Jak pise Bystroushak, komercni licencovani Smalltalk (a taky Lisp, ale to je jina story) zabilo. Firmy chteji neco, co ma podporu od velkych firem, ale nechteji za to moc platit. Proto se ujalo C++ (AT&T), Java (Sun). Smalltalk sice trochu podporovala IBM, ale Java byla "kompatibilni" s C a navic zadarmo. Python vitezi spis temto faktorum navzdory.

On je tam IMHO jeste jeden faktor, a to je, ze prilis abstraktni jazyky (Lisp, Smalltalk, Forth, APL, Haskell..) proste spousta programatoru nechce pouzivat. Zkratka je lepsi moznosti tvorby abstrakci nezajimaji. Nehodnotim to, ale cim vic empiricky pozoruji.

[Bystroushaak]

proste spousta programatoru nechce pouzivat. Zkratka je lepsi moznosti tvorby abstrakci nezajimaji.

Já bych ani neřekl, že nezajímají. Spíš to stojí námahu a taky se tam zapojuje ten efekt, že když jsi fakt dobrý v imperativním jazyce, který tě naučili ve škole a do kterého jsi dal třeba desetiletí námahy a tvrdé práce, aby jsi ho fakt plně ovládl včetně nějaké architektury, tak je fakt těžké najednou přejít na něco, kde jsi úplná lama a nic neumíš. Sám to na sebe pozoruji taky, že čím jsem starší a lepší v klasických jazycích, tím víc mě stojí námahy se učit něco úplně jiného.

Ale to se projevuje tak nějak všude. Například jsem relativně dobrý v češtině a mám určitou vládu nad slovy, takže z nich můžu tkát myšlenky a ovlivňovat jimi nejenom názory, ale i pocity ostatních. A když zkusím psát v angličtině, tak najednou brutálně narazím a mám asi tak 5% vyjadřovacích schopností. Angličtina mě skoro bolí, i když jí „ovládám“ na úrovni vedení konverzace. Protože ale každou chvíli narazím na to, že vlastně ani nevím, jak bych vyjádřil myšlenku, vzal nějaké přísloví a vytvořil abstrakci, tak v ní spíš moc nepíšu.

S programovacími jazyky je to stejné. Začínat v něčem na novo je spousta frustrace, kde každou chvíli narazíš na něco, co bys hned uměl implementovat ve svém „starém“ jazyce, ale v novém vůbec netušíš a když už náhodou ano, tak je to skoro vždycky blbě a „správně“ se to dělá 100x efektivněji a elegantněji, protože jiné paradigma.

Když si k tomu navíc přidáš, že ti to vydělává peníze / zajišťuje živobytí, tak se vůbec nedivím, že většina lidí po různých ne-mainstreamových jazycích nesáhne.

[JS1]

Vsechno, co pises, jsem si driv taky myslel, protoze jsem uvazoval stejne jako ty, a hledal v tom hlubsi, racionalni vysvetleni (na zaklade ocividne pravdy, ze protoze to delam ja, je to racionalni). Ale zadny z tech duvodu neodpovida moji empiricke zkusenosti. Ted si myslim, ze lepsi abstrakce proste spoustu lidi nezajima. To zajima lidi, kteri maji sklony k matematice, a to z nich jen jeste urcitou (ale velkou) cast. Ale spousta lidi je proste zadratovana jinak.

Je to trochu neco jako technologicka adopce. Jsou lide, kteri musi mit nejnovejsi a nejzarivejsi technologie, a neustale vyhlizeji, co noveho je ceka, a jsou lide, kterym je to jedno, az to prijde do mainstreamu, tak si to pak koupi. To nedela to rozhodnuti te druhe skupiny nejak horsi (jak se to snazis zduvodnit, treba tou frustraci z noveho), naopak, mozna jsou prave chytrejsi.

[xkucf03]

lepsi abstrakce proste spoustu lidi nezajima

Co je konkrétně lepší abstrakce? Byl by nějaký, pokud možno ne úplně triviální, příklad?

[JS1]

No proste schopnost tvorby novych abstrakci v jazyce, jako ma Lisp, Smalltalk, Haskell, Forth, ..

Priklad jsou treba makra. Nebo funkce vyssiho radu. Nebo pokrocile typove systemy. Atd. Proste vsechen "general abstract nonsense" u ktereho neni na prvni pohled jasne, k cemu to je.

O tom to prave je, ze smysluplnost tehle veci tem lidem (mezi ktere patris asi i ty) nejde vysvetlit prikladem. Zadny priklad te sam o sobe nemuze presvedcit o uzitecnosti obecneho mechanismu.

Dejme tomu, ze ti dam priklad z libovolne kapitoly knizky On Lisp, dejme tomu te, kde se pres makra definuji kontinuace. Ty muzes hned namitnout, pokud jsou kontinuace uzitecne, tak je muze autor jazyka definovat primo v jazyce. Budes mit pravdu, ale presto totalne nepochopis pointu.

[xkucf03]

S těmi makry souhlasím – a narážím na situace, kdy by bylo užitečné je mít.¹ Ale má to i druhou stranu mince: vyšší složitost a potenciálně horší čitelnost kódu, následně vyšší náklady na údržbu. Takže to není tak jednoznačné („čím víc toho jazyk umí/dovoluje, tím líp“ – to neplatí).

Nevidím to černobíle. Jen vím, že to má svoji stinnou stránku, svoji cenu a ta mi přijde někdy moc vysoká.

Je to dobrý sluha, ale může se to taky ošklivě vymknout kontrole. Musel bys mít zkušený tým a nastavená striktní pravidla, aby se používání takových jazykových konstrukcí nezvrhlo. Např. by makra nebo podobné věci mohl zavádět pouze senior/architekt. To by se ještě dalo uhlídat. Ale pak máš třeba různé knihovny – každou psal jiný senior/architekt a každý se na věc díval trochu jinak → komplexita se násobí. Taky je běžné, že se lidi v týmech mění – to, co zavedl tvůj předchůdce ti nemusí vyhovovat a nemusíš to moc dobře chápat – a čím „bohatší“ jazyk, tím hůř. I nový člověk, který to má „jen“ používat se do toho bude hůř dostávat. U jednoduššího jazyka celkem snadno seženeš člověka, který ho 100% ovládá. U „bohatšího“ jazyka je to těžší a spíš budeš mít tým, kde každý umí určitou podmnožinu těch funkcí.

Spousta skvělých jazykových vlastností/konstrukcí je skvělých jen v případě sólových projektů nebo stabilních týmů, ve kterých máš dvacet let ty samé lidi… Pak jsou ale jiné projekty s jinými prioritami – a ty si vyberou jiný nástroj. Není to o tom, že by jeden nástroj byl obecně lepší a druhý horší – jde o to, že se každý víc hodí na jiný typ úloh.

_{[1] a když někdy přemýšlím o ideálním jazyce, tak bych tam makra v nějaké bezpečné formě mít chtěl – ale mělo by to být stejně průhledné a použitelné jako obyčejné metody – u nich se v IDE snadno prokliknu na jejich zdroják a dokumentaci – u makra nebo teřeba přetíženého operátoru by mělo jít totéž, jinak to zavání obfuskací}

[JS1]

Nezlob se, ale tohle vsechno jsou jen racionalizace toho, proc ty abstrakce odmitat. Nejjasneji je to videt kde pises:

aby se používání takových jazykových konstrukcí nezvrhlo

Jinak receno - primo jsi to napsal - nechces nove abstrakce. Cele je to jen obava z toho, ze nekdo prijde s vhodnou abstrakci, ktera program zasadne zkrati, ale pro tebe bude tezko uchopitelna. Je to proste ve finale jen strach z neznameho.

Pritom neexistuje zadny empiricky ani teoreticky duvod si myslet, ze jazyky s vyssimi moznostmi tvorby abstrakce jsou vic nachylnejsi ke spatne napsanym programum.

[kralyk z abclinuxu]

Pritom neexistuje zadny empiricky ani teoreticky duvod si myslet, ze jazyky s vyssimi moznostmi tvorby abstrakce jsou vic nachylnejsi ke spatne napsanym programum.

O to tam ale přece vůbec nejde.

Tohle je klasický postoj lispisty: Přístup "Čím víc abstrakcí, tím lépe" a také naprostá ignorance overheadu abstrakcí (ať už výkonnostního nebo jiného).

Nejdříve k "Čím víc abstrakcí, tím lépe". Jde celkem jasně poznat případy, kdy abstrakce chybějí. Java je je klasickým příkladem, ačkoli v poslední době se vylepšuj a její původní místo IMHO obsadilo Go. Nicméně doplnit základní běžné abstrakce není až tak těžké a benefit každé vyšší přidané abstrakce se stále snižuje. Otázka, k čemu jsou dobré vysoké abstrakce, je pak zcela na místě. Tvůj postoj, kdy se snažíš posunout "důkazní břemeno" na toho druhého s tím, že to nechápe a není na dostatečně vysoké úrovni uvědomění, považuju za argumentační faul trochu připomínající narcisistické výblitky Paula Grahama (myslím, že on jim říká eseje). Pokud tvrdíš, že jazyk s vysokými možnostmi abstrakcí (např. lisp nebo haskell) je nějakým způsobem 'lepší', ale nejsi schopen to nijak dále vysvětlit na příkladech nebo statistikách nebo něčem podobném, je to tvoje selhání v diskusi.

K té ceně abstrakcí. Lispeři se často bijou v prsa, že veškeré prostředky, které široce používané jazyky nabízejí, měl Lisp už někdy v roce 1492. To tvrzení je často (i když ne 100% vždy) technicky vzato správné, ale komplet ignoruje to, že Lisp málokdy dokázal dodat abstrakce za použitelnou cenu a/nebo v přijatelné formě. Ten problém ceny spočíval např. ve slabém výkonu (zejména dříve, kdy ještě nebyly stroje tak výkonné, což IMHO byl důvod např. selhání Lisp machines). Další problém je cena za ergonomii - tlak na homoikonicitu a setrvání u s-exprs (m-exprs nebyly realizovány) dovedl Lisp k příšerné syntaxi. Lispeři tohle typicky s argoancí sobě vlastní odbudou s tím, že lidi jsou zvyklí na C-like syntaxi a cokoli jiného se jim nelíbí. To je ovšem dosti bullshit, s-exprs pro účely programování prostě docela sajou. Haskell má problém s ergonomií zase daný tím, že je hodně složitý a obsahuje obrovské množství operátorů apod. a nepomáhá ani to, že k monádám existuje 1500000 tutoriálů, z nichž použitelné jsou asi tak 3. Další cenou je fragmentace ekosystému. Lisp v tomhle jde přesně do opačného extrému naž Java. V té jsou všichni tlačení do vyznávání jednoho božího zákona a dogmaticky následovat stanovená pravidla. Naproti tomu v Lispu si každý může dělat úplně co chce a vynalézat vlastní jazyky v rámci Lispu, což vede k anarchii a následně zmatku. Tohle dobře ilustruje úspěch Clojure, které oba extrémy přivádí k sobě a vytváří mezi nimi celkem hezký průměr.

Nchci tímhle komentářem vyjádřit nějaký anti-intelektualismus. Lisp jsem si vyzkoušel a IMHO je to celkem fajn jazyk. Není to takový zázrak, jako z něj jeho skalní fanoušci dělají, ale není španý (když člověk použije editor, který trochu uleví s tou syntaxí). Nemám pro něj praktické využití, ale celkově je IMHO fajn si vyzkoušet co nejvíce jazyků.

Co si myslím, že není správné, je prosazování abstrakcí samoúčelně. Abstrakce jako takové by neměly být cíl, ale prostředek (načež je fajn vysvětlit k čemu, pokud někomu cpu abstrakce). Další věc je, že je důležité nebýt jako Paul Graham. Lisp, Haskell a další jazyky vysoké úrovně se určitě dají "prodávat" mnohem lépe.

[ehm]

měl Lisp už někdy v roce 1492

Fííha, tož to ja!

1415: Upálení mistra Jana Husa. („Ian, sfakt zašel za granici.“)

1492: Nalezení svazku psaného mistrem Janem Husem se specifikací LISPu.

1774: Po více než čtvrtině tisíciletí Marie v Terezíně konečně zavádí povinnou školní docházku, kde se děti učí počítat závorky. Jan Žizka z Trucu dříve si nechal při počítání závorek vyschnout oko.

[JS1]

On tim jenom narazel na to, ze ty "neabstraktni" jazyky casto takrikajic "objevuji Ameriku".

[JS1]

Pokud tvrdíš, že jazyk s vysokými možnostmi abstrakcí (např. lisp nebo haskell) je nějakým způsobem 'lepší', ale nejsi schopen to nijak dále vysvětlit na příkladech nebo statistikách nebo něčem podobném, je to tvoje selhání v diskusi.

Ale ony jsou lepsi; vzdycky mas moznost ty abstrakce nepouzit. Rozumis, ja ani tak neobhajuji (v teto diskusi, za jinych okolnosti mozna ano) pouziti tech nastroju (na tvorbu abstrakci), jako jejich existenci. A muj postoj je, ze proste spousta lidi nevidi, k cemu je to dobre, asi stejne jako nevedi, k cemu je dobra treba teorie kategorii. To neni nutne odsudek tech lidi, jen konstatuji, ze je to myslim hlavni duvod, proc se ty jazyky neujimaji (a jine duvody, ktere ti lide uvadi, treba syntakticke, jsou jen racionalizace).

Jinak receno, ja mam treba rad princip DRY. Ale spouste lidi se ten princip proste tak docela nelibi. Jen bych rad, aby byli k sobe uprimni, a uvedomili si to, misto vymysleni falesnych racionalizaci o tom, jak vyssi abstrakce prinasi nevyhody.

Haskell má problém s ergonomií zase daný tím, že je hodně složitý a obsahuje obrovské množství operátorů

No, ve skutecnosti neni. Haskell je ve skutecnosti radove jednodussi nez Java. To, ze ma obrovske mnozstvi operatoru je dane spis tim, ze v nem lze snadno abstrahovat veci, ktere by v Jave abstrahovat bylo slozite. V Jave si to radeji kazdy napise znova, kdezto v Haskellu se z toho udela operator a vrazi do knihovny.

Další cenou je fragmentace ekosystému.

Ale to se prece deje ve vsech jazycich, bez ohledu na nastroje k tvorbe abstrakci. Ja vidim fragmentaci v mainframe assembleru (kde si kazdy muze vymyslet treba volaci konvenci jakou chce) - a to rozhodne neni jazyk, ktery by umoznoval snadnou tvorbu abstrakci (i kdyz fakt je, ze to ma makra). Fragmentace je i v Jave a v Javascriptu - tuny frameworku pro totez, a staci k tomu jen malo - moznost vytvareni funkci nebo trid. Proste je nefer vydavat to za nevyhodu abstrakci, kdyz to s tim vubec nesouvisi.

Abstrakce jako takové by neměly být cíl, ale prostředek

IMHO jsou prostredek (k extremnimu) DRY. A DRY je prostredek treba k neopakovani chyb (protoze je to prostredek k neopakovani se obecne).

[kralyk z abclinuxu]

Jinak receno, ja mam treba rad princip DRY. Ale spouste lidi se ten princip proste tak docela nelibi. Jen bych rad, aby byli k sobe uprimni, a uvedomili si to, misto vymysleni falesnych racionalizaci o tom, jak vyssi abstrakce prinasi nevyhody.

Částečně bych souhlasil, nicméně ty racionalizace nemusí být nutně falešné, IMHO pro to mohou být platné racionální důvody.

No, ve skutecnosti neni. Haskell je ve skutecnosti radove jednodussi nez Java.

Tohle je zase taková právničtina :-/ Ano, samozřejmě, že technicky vzato je Haskell jednodušší co do počtu elementárních prvků, řekněme, ale z praktického hlediska je složitý, člověk se musí seznámit s velkým množstvím pojmů a mechanismů, které jsou navíc třeba specifické pro nějakou oblast / knihovnu...

Fragmentace je i v Jave a v Javascriptu - tuny frameworku pro totez, a staci k tomu jen malo - moznost vytvareni funkci nebo trid.

Fragmentaci v Javě až tak nevidim. Fragmentaci v JS určitě ano, ale tam to je spíše jednak problém granularity (příliš malé knihovny) a jednak problém prohlížečů, které neposkytují dostatečné prostředky, takže lidé se to snaží různými cestami řešit, což celkem nevyhnutelně vede k fragmentaci.

Proste je nefer vydavat to za nevyhodu abstrakci, kdyz to s tim vubec nesouvisi.

Souvisí to a IMHO to je legitimní námitka proti prostředkům pro vytváření abstrakcí.

Představ si, že bys pracoval v ekosystému, kde každá další knihovna by měla úplně jiné paradigma a úplně jiné vyjadřovací prostředky. V podstatě ta míra vytváření abstrakcí by šla tak daleko, že každá komponenta programu by byla napsaná úplně jinými způsobem šitým na míru právě té komponentě, takže čtení kódu každé komponenty by se víceméně rovnalo seznamování se s novým jazykem... Já doufám, že se shodneme, že existuje něco jako 'příliš mnoho abstrakcí' nebo 'příliš abstraktně napsaný program'. Pokud ano, v důsledku se také shodneme na tom, že může existovat jazyk, který poskytuje příliš velkou sílu / příliš velké prostředky pro psaní abstrakcí, tj. takový, kde pokud by někdo ty prostředky skutečně využil, vedlo by to k 'příliš abstraktně napsanému programu'.

Pozice lispu, Haskellu apod. v důsledku není zdaleka tak jednoduchá, jak to obvykle jejich fanoušci postaví, nelze prostě říct, že čím víc proužků, tím víc adidas, ale bylo by potřeba ukázat, že ta míra abstrakcí v lispu, Haskellu apod. je právě ta správná a jsou to právě ty správné prostředky, což je mnohem těžší. IMHO jinak pouze ta myšlenka "více abstrakcí = lepší" je podobně bezmyšlenkovité prázdné dogma jako třeba v Javě "více OOP enkapsulace = lepší" anebo třeba v C++ "více optimalizované pro hardware = lepší".

[xkucf03]

Ale ony jsou lepsi; vzdycky mas moznost ty abstrakce nepouzit.

Když je to sólový projekt, kde jsi jediný vývojář, tak ano. Pokud je to ale týmová práce nebo to přebíráš po někom jiném, tak to nejsi ty, kdo by rozhodoval o použití či nepoužití dané abstrakce – ona v tom kódu prostě je a ty se s tím musíš nějak vypořádat.

Fragmentace je i v Jave a v Javascriptu - tuny frameworku pro totez, a staci k tomu jen malo - moznost vytvareni funkci nebo trid.

Za JavaScript mluvit nechci. Ale v Javě jsi spoustu programů schopný napsat jen se standardní knihovnou. Na větší aplikaci použiješ buď Javu EE nebo Spring. To jsou dvě základní volby – je to fragmentace? Pak tu máš knihovny pro nějakou doménu (třeba grafika, nebo podpora nějakého specifického formátu, protokolu atd.) to bys měl ale specifické tak jako tak. V lepším případě to implementuje nějaký javovský standard (to funguje u obecnějších věcí jako JCache, JDBC, věci kolem XML, JPA, JCA…). Tak jako tak se ale nemusíš učit nějaký nový jazyk (abstrakci) a jen používáš nějaké třídy/rozhraní a voláš jejich metody.

IMHO jsou prostredek (k extremnimu) DRY. A DRY je prostredek treba k neopakovani chyb (protoze je to prostredek k neopakovani se obecne).

A proč by abstrakce rozšiřující samotný jazyk a vytvářející jakousi novou abecedu měla být výrazně lepší¹ než abstrakce ve formě tříd a rozhraní, případně anotací?

_{[1] v nějakém smyslu asi lepší bude, ale pokud se bavíme o efektivitě a o tom, kolik času je potřeba celkem vložit, abys získal stejně užitečný a stejně kvalitní program – tak tam si právě nejsem jistý, zda je tento přístup lepší – nebo bude lepší jen v nějakých specifických případech, ale ne obecně}

[JS1]

Když je to sólový projekt, kde jsi jediný vývojář, tak ano.

Jo, to se tvrdi (na obhajobu Javy a spol.), ale jeste jsem nevidel zadny empiricky dukaz, proc by jazyky vyhodne pro jednotlivce mely byt nevyhodne pro skupiny. Je to trochu jako tvrdit, ze existuji prirozene jazyky, ktere jsou vhodne pro komunikaci dvou lidi, ale tri lide uz maji problem.

Pokud je to ale týmová práce nebo to přebíráš po někom jiném, tak to nejsi ty, kdo by rozhodoval o použití či nepoužití dané abstrakce – ona v tom kódu prostě je a ty se s tím musíš nějak vypořádat.

Ano, v takovem pripade nerozhodujes ani o jinych vecech, ktere se ti nemusi libit. Treba o tom, jake se pouzivaji tridy a funkce. Stale se musi naucit uz existujici jazyk - uzivatelsky definovane funkce a tridy, ktere prichazi s tim kodem.

Jakmile lidem dovolis definovat si vlastni funkce (nebo procedury), dal jsi jim moznost vytvaret nove abstrakce. Uz v tomhle pripade zacinas resit tento problem. Je to argument vuci abstrakcim obecne, nikoli vuci lepsim nastrojum na tvorbu abstrakci nez jake poskytuje treba Java.

Ale v Javě jsi spoustu programů schopný napsat jen se standardní knihovnou. Na větší aplikaci použiješ buď Javu EE nebo Spring. To jsou dvě základní volby – je to fragmentace?

Jsem si jisty, ze bychom pri pohledu do minulosti nasli vetsi fragmentaci. U webovych frameworku, treba.

Tak jako tak se ale nemusíš učit nějaký nový jazyk (abstrakci) a jen používáš nějaké třídy/rozhraní a voláš jejich metody.

Naucit se nazvy a smysl novych trid a funkci je jako naucit se nova slova a jejich semantiku, ucis se fakticky novy jazyk. Vytvaris delitko nekde, kde neni.

A proč by abstrakce rozšiřující samotný jazyk a vytvářející jakousi novou abecedu měla být výrazně lepší1 než abstrakce ve formě tříd a rozhraní, případně anotací?

Uz ti to napsal trochu Bystroushaak, ale zhruba receno jde o to, ze zapises snaz neco, co by jsi v existujicim jazyce napsal jen slozite. Klasicky priklad jsou funkce vyssiho radu (funkce co pracuji s funkcemi), na ktere se musela pred Javou 8 vytvaret specialni trida. Je to casto dane tim, ze ty tzv. abstraktnejsi jazyky ve skutecnosti dost procisti/zjednodusi koncepty, s kterymi se pracuje, a tim se zbavis mnoha specialnich pripadu, ktere jsou v podstate v tom mene abstraktnim jazyce resene arbitrarne.

Napriklad Haskell nema vyjimky - resi se to tak, ze se vrati specialni typ. To umoznuje zjednodusit nektere funkce, ktere by v Jave musely mit specialni podobu pro pripad vyjimek a pripad normalnich hodnot, na jedinou sadu funkci.

[ehm]

Je to trochu jako tvrdit, ze existuji prirozene jazyky, ktere jsou vhodne pro komunikaci dvou lidi, ale tri lide uz maji problem.

Nikoliv. Je to jako tvrdit, že když si pro sebe kreslíš nějaké schéma nebo diagram, můžeš používat jaké značky a symboliku chceš, zatímco když vyhotovuješ kompletní stavební dokumentaci, kterou budou číst desítky lidí, tak není úplně žádoucí nadefinovat si na nějakém dobře ukrytém místě vlastní značku a spoléhat na to, že každý si dohledá a zapamatuje její definici.

[xkucf03]

Na zbytek teď nemám sílu reagovat, tak jen tohle, abych to nezapomněl:

Napriklad Haskell nema vyjimky - resi se to tak, ze se vrati specialni typ.

A dokáže to plně nahradit výjimky? Jak se tam řeší „probublání“ výjimky do vyšších úrovní? (ne vždy chci každou výjimku řešit hned tam, kde vznikla – určitý typ výjimek chci nechat vyletět až do nějaké vyšší vrstvy a ošetřit až tam, na jednom místě)

[JS1]

A dokáže to plně nahradit výjimky? Jak se tam řeší „probublání“ výjimky do vyšších úrovní?

Bud pres pattern matching nebo Either monadu. Neni to moc odlisne od checked exceptions v Jave. Ale hezke na tom je, ze treba muzes snadno funkci, ktera s vyjimkami nepocita, osperkovat tak, aby s nimi pocitala - rika se tomu "lifting".

[xkucf03]

U výjimek to funguje tak, že když neudělám nic (záměrně neošetřím/neodchytnu nebo na to zapomenu), tak vyletí výš. Kontrolované výjimky musím deklarovat v rozhraní (takže mi případné chyby odchytí kompilátor) a ty nekontrolované vyletí nahoru i bez toho. Jak je tam tohle řešené a podporované jazykem? Nebo to tam není a výjimka „vyletí nahoru“ jen když explicitně řeknu, že se tak má stát?

[kralyk z abclinuxu]

V jazycích s tímhle error handling stylem jsou návratové hodnoty založené na sumárních typech. Tj v případě že funkce vrací Either nebo podobný typ, tak ta návratová hodnota obsahuje buď vrácený výsledek, nebo chybu. K tomu máš k dispozici třeba funkci, která "rozbaluje" výsledek z toho návratového typu a která nějakým způsobem nedovolí pokračovat, pokud nastala chyba (v závislosti na jazyku - v Haskellu to bude řešeno asi více funkcionálně (asi se typicky prostě půjde do chybové větve funkce), v Rustu spíše více imperativně - zpanikuje se thread).

Samozřejmě můžeš i explicitně nějakým způsobem ten chybový stav ignorovat / spolknout, ale to můžeš v Javě taky.

Taky máš typicky k dispozici funkce/makra/mechanismy jak propagovat tyhle typy nahoru, s tím, že můžeš funkcionálně mapovat jeden typ na jiný (můžeš mapovat typ hodnoty nebo typ chyby nebo oboje, pokud potřebuješ - tj. tam kde v Javě catchneš jednu chybu jen proto, abys vyhodil vejš chybu jinýho typu, tak v těhle jazycích akorát necháš prohnat tu návrotovou hodnotu lambdou, která mapuje tu chybu na jinou).

Kontrolované výjimky mi přijdou skoro blíž sumárním návratovým typům než běžným unchecked výjimkám, protože stejně jako návratový typ jsou součástí signatury funkce a stejně jako ten druhý (chybový) typ v Either specifikují chybovou návratovou hodnotu funkce. Akorát trochu jinak integrují se zbytkem jazyka a nedají se transformovat funkcionálním stylem.

[JS1]

Presne tak, nevim, co bych k tomu dodal.

Snad jen to, ze z hlediska typove korektnosti (a na tom si treba Haskell dost zaklada) jsou unchecked vyjimky dost o drzku.

[xkucf03]

BTW: a co říkáš na to, že hodně lidí propaguje běhové/nekontrolované výjimky a používá obalující knihovny (např. Spring JDBC Template), které převádějí kontrolované výjimky na nekontrolované?

[JS1]

O tom nevim, a neni mi uplne jasne, jakou by to melo prinest vyhodu.

[deda.jabko]

Je to trochu jako tvrdit, ze existuji prirozene jazyky, ktere jsou vhodne pro komunikaci dvou lidi, ale tri lide uz maji problem.

Vsimni si, ze matematici, pravnici, lekari maji sve "domenove specificke prirozene jazyky", ktere omezuji existujici prirozene jazyky na "bezpecnou podmnozinu" tak, aby si mezi sebou byli schopni navzajem rozumet.

Neco podobneho popisuje treba Feynman, ze mel na skole vlastni system matematickych znacek, ktery ale byl neslucitelny s existujici notaci, coz pak delalo problemy pri vysvetlovani uciva jinym. Podobne to muze nastat u jazyku s vysokou mirou abstrakce, kdy si zavades svuj system, na nem vybudujes dalsi aparat, atp. A ostatni tomu maji problem rozumet.

Jakmile lidem dovolis definovat si vlastni funkce (nebo procedury), dal jsi jim moznost vytvaret nove abstrakce.

Mne se zda, ze tu resis falesne dilema, jestli abstrakce, ano, nebo ne. Ono je to otazky miry, kdy uz se veci zacinaji komplikovat a kdy ne. Pro me treba pri praci na necem vetsim je Java obrovske usnadneni prace, protoze kod je sice ukecany ale pruhledny, na mensi a osobni veci neni problem pouzit Scheme nebo Clojure nebo Python, ale uz je to horsi pro porozumeni ostatnim.

Klasicky priklad jsou funkce vyssiho radu (funkce co pracuji s funkcemi), na ktere se musela pred Javou 8 vytvaret specialni trida

Tak to byla a je spis ideologicka vec, protoze to Javovske reseni vylozene tezi z principu: mame objektovy jazyk, ustredni entitou je objekt, budeme pracovat ciste s objekty, proc bychom to komplikovali jeste funkcemi. Pred dvaceti lety asi malokdo tusil, ze FP bude takova velka vec. Spis si dokazu predstavit, ze by prisli puristi a kritizovali Javu, za to, ze je malo OOP.

[JS1]

Podobne to muze nastat u jazyku s vysokou mirou abstrakce, kdy si zavades svuj system, na nem vybudujes dalsi aparat, atp. A ostatni tomu maji problem rozumet.

Nevim, porad nevidim rozdil oproti jakemukoli vlastnimu frameworku nebo knihovne, ktera proste zavadi tvoje vlastni funkce, ktere musi jini pochopit.

Ono je to otazky miry, kdy uz se veci zacinaji komplikovat a kdy ne.

Mozna je to otazka miry, ale mam o tom sve pochybnosti. Kdyz vidim, s cim Javisti musi zit! Kolikrat vidim nejaky Javovsky konstrukt (pattern), ktery vypada silene, ale kdyz se to prelozi do funkci, tak je to najednou vlastne primitivni.

Rad napul vtipkuji, ze nejsem dost chytry, abych pouzival Javu, ze proto mi vyhovuje Haskell, ktery je jednodussi. Takze pro mne to neni tak, ze bych povazoval Javisty za nejak hloupejsi. Naopak, co me na tom frustruje je prave jejich tendence delat veci mnohem vic pres ruku nez by museli (casto z ideologickych duvodu), a nedaji si rict, ze to jde snaz!

kod je sice ukecany ale pruhledny

Tenhle argument jsem slysel, ale ja mam za to, ze mezi ukecanosti a pruhlednosti neni zadny vztah. Dokazu si predstavit ten samy kod napsany vsemi ctyrmi variantami (ne)ukecanosti a (ne)pruhlednosti.

Tak to byla a je spis ideologicka vec, protoze to Javovske reseni vylozene tezi z principu: mame objektovy jazyk, ustredni entitou je objekt, budeme pracovat ciste s objekty, proc bychom to komplikovali jeste funkcemi.

No ano, ale tim se vracime k jadru moji kritiky Javy - ideologie. Jak pises jinde o te rychlosti, zase, ten napad napsat vnitrne Swing v Jave byl zase dany ideologii, ze Java bude jeden jazyk na vsechno. Pythonisty by tohle nenapadlo..

[kralyk z abclinuxu]

Rad napul vtipkuji, ze nejsem dost chytry, abych pouzival Javu, ze proto mi vyhovuje Haskell, ktery je jednodussi.

Já bych si Haskell klidně i vyzkoušel, ale nemám pro něj úplně využití. Tíhnu spíše k nízkoúrovňovému nasazení, což je oblast, kterou jazyky vysokých abstrakcí jako Lisp/Haskell dost ignorujou, skoro bych spíš řekl z vysoka na ni serou. (Ale to Java taky.)

No ano, ale tim se vracime k jadru moji kritiky Javy - ideologie. Jak pises jinde o te rychlosti, zase, ten napad napsat vnitrne Swing v Jave byl zase dany ideologii, ze Java bude jeden jazyk na vsechno.

Není tohle i ideologie Lispu nebo SmallTalku?

[deda.jabko]

nevidim rozdil oproti jakemukoli vlastnimu frameworku nebo knihovne, ktera proste zavadi tvoje vlastni funkce, ktere musi jini pochopit.

To souvisi s principem nejmensiho prekvapeni. Kdyz kod ctes, vis, ze se jedna o volani metody nebo aplikaci funkce. V pripade maker, uz tuto jistotu ztracis. Osobne mam makra moc rad (nejen LISPova) a obcas su hrdy na to, co se mi treba v CPP podarilo vytvorit za hezky DSL, ktery kod zprehledni, ale chapu, proc si javiste mysli, ze makra jsou spatne. Obcas narazim na veci, ktere jsem delal 2+ roky zpatky a dostat se do takoveho programu s makry je obcas orisek, obzvlast, kdyz chci menit nejake makro.

Z podobneho duvodu si myslim, ze i imperativni programovani neni dobry napad. V momente, kdyz muzes explicitne menit stav, prestavas mit jistotu nad tim, co se s programem deje.

Kolikrat vidim nejaky Javovsky konstrukt (pattern), ktery vypada silene, ale kdyz se to prelozi do funkci, tak je to najednou vlastne primitivni.

Muzes byt konkretnejsi?

Naopak, co me na tom frustruje je prave jejich tendence delat veci mnohem vic pres ruku nez by museli (casto z ideologickych duvodu), a nedaji si rict, ze to jde snaz!

Ja bych to tak cerne nevidel. Uz jsem tu pouzival paralelu s technickym kreslenim, ktere je taky neefektivni s omezenymi vyjadrovacimi schopnostmi, skoro bez abstrakci, ale pouziva se, protoze je srozumitelne pro kazdeho.

Ono jeste hodne zalezi na tom s jakymi javovskymi projekty ses setkal. Treba Java EE do verze 5 bylo vylozene utrpeni, kde mi prislo, ze vsechno navrhovali sadisti a masochisti. JEE 7 (pod tlakem Springu) vypada uz jako sympaticky framework, kde se da docela hezky a rychle programovat bez toho, ze by i jednoducha vec byla PITA.

tim se vracime k jadru moji kritiky Javy - ideologie

Tady zneuzivame dvoji vyznam slova ideologie. Na jedne strane mas ideologii uzivatelu, kteri s jazykem pracuji, a je mozne, ze jim ta ideologie vyhovuje. Osobne si myslim, ze zalezi na resenem problemu a neni jedno dobre reseni(tm). Podobne je to i v beznem zivote.

Druhy vyznam je filozofie samotneho jazyka. Kritizovat Javu za to, ze se primarne snazi pracovat s objekty misto toho, aby zavedla funkce, je stejne tak hloupe jako treba kritizovat Haskell, ze se vedlejsi efekty snazi resit pres monady a nezavede normalni prikaz prirazeni.

[xkucf03]

ale chapu, proc si javiste mysli, ze makra jsou spatne

Já si nemyslím, že jsou úplně špatná, naopak mě celkem lákají. Jenže si nemyslím, že by byla vhodná do projektů, které se dnes běžně píší v Javě – a tohle je přesně ten důvod:

Obcas narazim na veci, ktere jsem delal 2+ roky zpatky a dostat se do takoveho programu s makry je obcas orisek, obzvlast, kdyz chci menit nejake makro.

Naopak si dovedu představit týmy/projekty, u kterých jazyk s makry dává dobrý smysl.

A teď je otázka, jestli nemít jeden jazyk s makry a jen si u některých projektů říct, že zde je nebudeme používat. Dá se taková disciplína udržet?

Např. u reflexe se to držet daří – v aplikačním kódu ji prakticky nevidíš a pokud ano, tak se to obvykle považuje za chybu. Reflexe se používá leda ve frameworcích a knihovnách. U maker by asi to nutkání je použít bylo mnohem větší a častěji by se zneužívala (u reflexe to navíc reguluje její ne až tak příjemné používání). Projektový manažer většinou neví, co makra jsou, nedokáže zhodnotit jejich pozitiva a negativa a ani není schopen kontrolovat, zda v kódu jsou nebo ne. Takže je to vlastně jen na programátorech, jak se k tomu postaví. A jak jsem psal, lidi se v týmech mění – a ty nejsi schopen ovlivnit, tvoji předchůdci makra použili nebo ne. Pokud zdědíš kód prolezlý nějakými šílenými makry, tak si to můžeš jít hodit. Těžko se ti budou dělat odhady, těžko přebereš odpovědnost za existující kód…

Myslím, že situace celkem přirozeně dokonvergovala k současnému stavu, kdy se na určité typy projektů používá Java, na jiné typy projektů C++ nebo C a na jiné třeba Haskell nebo Lisp. Kdyby se Java v principu změnila, tak by se postupně na daný typ projektů přestala používat a její místo by zaujal jiný jazyk (podobný dnešní Javě).

[JS1]

Jenže si nemyslím, že by byla vhodná do projektů, které se dnes běžně píší v Javě

A projekt Lombok vhodny je? Vzdyt to jsou (ponekud bizarni) makra!

Pokud takove konstrukty do jazyka nedaji jeho autori, pak si lide pomahaji podobnymi (a dost desnymi, IMHO) obezlickami.

Dá se taková disciplína udržet?

Proc by se nedala udrzet? Staci k tomu - disciplina. Je to stejne jako s reflexi.

Projektový manažer většinou neví, co makra jsou, nedokáže zhodnotit jejich pozitiva a negativa a ani není schopen kontrolovat, zda v kódu jsou nebo ne.

Projektovy manazer nema co mluvit do toho, jakym zpusobem se pise kod. To je na inzenyrech.

Ale ono to mozna souvisi s tim, ze tvorba software se mnohde nebere jako skutecne inzenyrstvi, ale jen jako nejake "lepeni".

[ehm]

A projekt Lombok vhodny je? Vzdyt to jsou (ponekud bizarni) makra!

Dle mého názoru není. Třeba v IntelliJ je potřeba doinstalovat plugin, aby to přestalo hlásit chybu na volání generovaných metod. Zkompilovat a spustit to sice jde i bez pluginu, ale analýza kódu je bez něj rozbitá. (Pravděpodobně to půjde kromě pluginu řešit i nějakým upravením konfigurace, ale nestudoval jsem to.)

To už by mi asi přišlo lepší použít klasické generování kódu.

Pokud takove konstrukty do jazyka nedaji jeho autori, pak si lide pomahaji podobnymi (a dost desnymi, IMHO) obezlickami.

Je to tak. Bylo by fajn, aby na JavaBeans byla nějaká lepší podpora přímo v jazyku. Může to fungovat třeba na podobném principu jako ten Lombok.

Proc by se nedala udrzet? Staci k tomu - disciplina.

To souvisí s argumentem, co jsem tu už někde víckrát psal. Naposledy #753. Musel bych to citovat skoro celé, tak si to raději přečti tam (a kdyžtak i odpověz tam).

[xkucf03]

Je to tak. Bylo by fajn, aby na JavaBeans byla nějaká lepší podpora přímo v jazyku. Může to fungovat třeba na podobném principu jako ten Lombok.

+1, chtěl bych to mít ve standardu. Takhle je to jen nedokonalé řešení, u kterého jsem si akorát vyhodnotil, že výhody převažují nad nevýhodami a riziky.

[xkucf03]

A projekt Lombok vhodny je? Vzdyt to jsou (ponekud bizarni) makra!

V zásadě to makra jsou. Ale asi se mylně domníváš, že já jsem nějak zásadně proti makrům. V ideálním jazyce, který bych chtěl pro sebe, bych makra mít chtěl. Prostě se jen děsím toho, že bych měl spravovat kód, který někdo zaneřádil nějakými šílenými makry. A nejde jen o makra, týká se to i dalších věcí, které umožňuje třeba C++, Python, Perl… Oproti tomu Java je taková sázka na jistotu, kde se dají dělat relativně dobré odhady a člověk se nemusí až tak bát převzít kód po někom jiném.

To mi spíš vadí všechno ostatní vedle maker – proč ty jazyky musí mít natolik jinou syntaxi a používat jiné symboly? Čemu tím prospěješ? Ta základní C-syntaxe mi prostě přijde docela dobrá – kulaté, složené a hranaté závorky, klíčová slova, přiřazení, zápis metod a parametrů, základní operátory…

Pokud bych někdy konstruoval ideální jazyk, tak by to z téhle syntaxe vycházelo, akorát by k tomu byly přidané nějaké věci navíc. Nevidím přínos v tom, dělat to za každou cenu nějak jinak.

Staci k tomu - disciplina. :-) Je to stejne jako s reflexi.

Jak jsem psal, u té reflexe to reguluje a ne zcela snadné použití programátorská kultura, která na reflexi hledí jako na něco nestandardního a trochu podezřelého, co by se mělo používat jen v opravdu nutných případech. V jazyce, který podporuje makra a další podobné věci jako běžnou součást, tak tahle „brzda“ existovat nebude a spousta programátorů tyhle věci bude používat i tam, kde to nadělá víc škody než užitku.

To je na inzenyrech.

No právě (a spíš bych řekl „na programátorech“ – protože ne všichni jsou inženýři). A jsme zase u toho – pokud máš stabilní tým, kde jsou zkušení lidé, jsou vytrénovaní danou štábní kulturou a po letech sehraní a zvykí na nějaký jednotný styl, tak s „jazykem neomezených možností“ nebudeš mít problém, protože všichni budete používat nějakou rozumnou podmnožinu. Ale pokud děláš na projektech, kde se lidi mění¹ nebo přebíráš práci po někom jiném, tak mi fakt použití takového jazyka nepřijde jako dobrý nápad.

Ale ono to mozna souvisi s tim, ze tvorba software se mnohde nebere jako skutecne inzenyrstvi, ale jen jako nejake "lepeni".

Cílem vývoje softwaru je dodat produkt, který bude přinášet užitek. Nikoli meditovat nad dokonalostí – za to tě nikdo platit nebude. Je to jako když stavíš most nebo přehradu – v první řadě by ta stavba měla plnit svůj účel, neměla by lidem padat na hlavu nebo zatopit město, neměla by plýtvat zdroji a neměla by lidi obtěžovat ošklivostí, měla by být estetická… ale jestli obsahuje geniální návrh a myšlenky a představuje maximum dokonalosti, které je lidstvo schopné… to není až tak důležité. Je to sice hezké, ale na tom to nestojí. Ostatně staré stavby taky nepředstavují maximum toho, čeho jsme dnes schopní, a přesto jsme rádi, že je máme.

O kousek vedle je vlákno o tom, jak moc myslet na budoucí požadavky při psaní kódu. V podstatě každý extrém je špatný – jak maximalizace ohledů na potenciální požadavky, tak overengineering, tam předčasná optimalizace na výkon, tak ta i tvoje extrémní snaha o „dokonalost“.

_{[1] což může být dané tím, že někdy je práce hodně a jindy se jen udržuje a opravují se chyby, takže nedává smysl tam držet celou dobu plný počet lidí}

[JS1]

Pokud bych někdy konstruoval ideální jazyk, tak by to z téhle syntaxe vycházelo, akorát by k tomu byly přidané nějaké věci navíc. Nevidím přínos v tom, dělat to za každou cenu nějak jinak.

Takovy jazyk uz existuje - Julia.

a spousta programátorů tyhle věci bude používat i tam, kde to nadělá víc škody než užitku

Vis, v tom je rozdil mezi nami. Ja se staram o to, jak pisu ja. Ty se staras o to, jak pise nekdo jiny. Nechci tvrdit, ze to prvni je produktivnejsi pristup, ackoli si to asi myslim.

Ostatne i v OSS - veci, co napises pro sebe jsou casto uspesnejsi nez veci, co napises pro nekoho jineho. Protoze ty sam moc dobre vis, co te trapi; nepotrebujes navic nejakeho "produktoveho manazera", ktery to sam nepouziva a nejspis jen spatne pochopi.

tak mi fakt použití takového jazyka nepřijde jako dobrý nápad

Tak trochu strawman, co rikas.. Treba ja bych pouzil Python a Haskell na dost odlisne projekty. A realne je situace, kterou popisujes, spis dusledek idiocie managementu, nez cehokoliv jineho.

tak ta i tvoje extrémní snaha o „dokonalost“

Ja nemam extremni snahu o "dokonalost". Jen mi vadi, kdyz mi nejaky namysleny idiot (= ty, v tomto pripade) vnucuje omezeny nastroj. Predpokladas, ze to udelam spatne, pritom ja si chci jen vybrat, protoze ja tu praci delam. S tim jdi do haje.

[ehm]

Takovy jazyk uz existuje - Julia.

Na první pohled to vypadá mnohem víc jako Pascal než jako C.

Vis, v tom je rozdil mezi nami. Ja se staram o to, jak pisu ja. Ty se staras o to, jak pise nekdo jiny.

Protože s tím kódem někoho jiného budeš pracovat. Je to podobně důležité jako jmenné konvence, jednotné odsazování apod.

A v té Javě tohle fakt funguje. Mrknout do cizího zdrojáku většinou není naprosté utrpení. Existují adepti, co se o to snaží (třeba Apache Commons), ale nakonec se v těch prasokódech stejně vyznáš. Proměnná b? To je deskriptivní název, že bych si z toho vyškrábal oči a donutil autora toho kódu se na mě u toho dívat. Ale zmáčknu F2 a vidím, že je to třeba byte[].

To se tedy týkalo typování, o kterém teď řeč úplně nebyla. Jenže podobně to funguje i u dalších věcí. Ta syntaxe je strašně jednoduchá. Mozek se s tím naučí rychle pracovat.

Jen mi vadi, kdyz mi nejaky namysleny idiot (= ty, v tomto pripade) vnucuje omezeny nastroj.

Vadilo by ti, kdyby ti v práci někdo nutil coding-style (tj. omezené množství možností jak tvůj zápis naformátovat)?

[JS1]

Protože s tím kódem někoho jiného budeš pracovat.

A ja to asi nevim?

Ve skutecnosti v praci spravuji kod, od ktereho by mozna 50% Javistu utekla, protoze je pro ne prilis neprehledny. Jenze nekdo to delat musi, tak to udelam. Protoze, kdyz je nejakou praci potreba udelat, tak ji udelam, nechci mit reci, ze by se to melo prepsat, protoze to nedodrzuje konvenci, ktera neexistuje.

Jsou to dve strany mince. Muzes me kritizovat za prilisnou toleranci vuci ostatnim, jenze v praxi je to potreba, protoze nejaky kod uz existuje a nekdo ho spravovat musi.

Ale o co mi slo spis je, ze autori (a obhajci) Javy ta omezeni lidem vnucuji jeste driv, nez vidi jejich kod, a nedelaji to na zaklade hodnoceni sebe sama. Je to proste moralizujici bullshit.

A v té Javě tohle fakt funguje. Mrknout do cizího zdrojáku většinou není naprosté utrpení.

Moje zkusenost, tedy spis z C#, je jina. Pracoval jsem s jazyky s ruznou mirou abstrakce (od assembleru pres C az po Haskell) a schoponost porozumet zdrojaku je nezavisla. Je to trade off - jazyky s nizkou abstrakci jsou tezkopadne, jazyky s vysokou abstrakci jsou obcas prilis strohe. Takze se to tak nejak vykompenzuje, osobne bych rekl, ze strohost je dlouhodobe spis plus (protoze jakmile si zazijes nejaky koncept, veci se dost zrychli, u tezkopadnych jazyku nebo zdrojaku neni co se naucit).

Vlastne, co je tezkeho na tom tak pochopit? Java se cte lepe nez C++, ne? Tak co je tak tezkeho na tom prijmout, ze existuje jazyk, ktery se cte jeste lepe nez Java? To je ten problem, ty jsi prisel do jisteho bodu, a deklaroval, ze tohle je vrchol. Neni.

Vadilo by ti, kdyby ti v práci někdo nutil coding-style

Absolutne ne, mne nevadi ani daleko horsi veci. Jenze coding style je konvence, je to jedna volba z mnoha. Neni to technicke omezeni.

[ehm]

Ale o co mi slo spis je, ze autori (a obhajci) Javy ta omezeni lidem vnucuji jeste driv, nez vidi jejich kod, a nedelaji to na zaklade hodnoceni sebe sama.

Kdy jindy to chceš dělat? Až tým sto lidí, kteří se pravidelně obměňují, vyprodukuje kód, ve kterém každý používá úplně jiný přístup a nikdo se v tom nevyzná? Pak teda řekneš, že bude lepší to zahodit a přepsat do Javy?

Moje zkusenost, tedy spis z C#, je jina. Pracoval jsem s jazyky s ruznou mirou abstrakce (od assembleru pres C az po Haskell) a schoponost porozumet zdrojaku je nezavisla.

To není záležitost abstrakce, ale syntaxe.

Tak co je tak tezkeho na tom prijmout, ze existuje jazyk, ktery se cte jeste lepe nez Java? To je ten problem, ty jsi prisel do jisteho bodu, a deklaroval, ze tohle je vrchol. Neni.

To je pro mě nová informace.

Jenze coding style je konvence, je to jedna volba z mnoha. Neni to technicke omezeni.

A tak na každém projektu budeš opakovat tytéž volby? Psát coding-style, pak guidelines, kdy jak co zapsat, resp. jakou konstrukci použít, a ve výsledku budeš používat jen striktní subset toho jazyka.

A nebo taková omezení zavádět nebudeš a v naprosté většině případů to dopadne blbě.

[xkucf03]

ve výsledku budeš používat jen striktní subset toho jazyka

U těch podmnožin (a to se týká i třeba C++ nebo Perlu) to dopadá tak, že většina lidí pak bude umět nějakou podmnožinu, ale neovládá kompletní jazyk. A to je problém jednak proto, že přímo¹ pracuješ s nástrojem, který pořádně neovládáš. A jednak proto, že se hůř domluvíš s ostatními – např. ty i kolega řeknete, že máte praxi pět let v jazyce XY, ale když budete mít za úkol spolupracovat na jednom projektu, tak se ukáže, že to nejde, protože každý znáte a používáte jinou podmnožinu z toho jazyka.

_{[1] a je to jiný problém než abstrakce, kdy programuješ ve vyšším jazyce a nevíš, co se děje v assembleru – spíš se to dá přirovnat k situaci, kdy používáš stroj, který máš padesát páček a tlačítek, ale ty znáš význam jen pěti z nich}

[ehm]

Jo, přesně. Človek si prostě klade otázku, jak je možné, že na jedné straně existují stavební normy, ale na straně druhé je plně legální vyvíjet komerční software v C++, Perlu, nebo PHP. Pak to končí bezpečnostními chybami, které prostě přímo vyplývají ze složitosti těch jazyků! Čili buď zrušit i ty stavební normy, nebo prostě tyhle zmetkovité jazyky nechat úplně zakázat. Když budeš potřebovat napsat třeba nějaký low-level kód v C, tak si podáš žádost na Softwarový úřad, a oni posoudí, jestli to povolení dostaneš. Jinak všechno v Javě.

[kralyk z abclinuxu]

Bohajeho. Ty jsi fakt softwarový fašista, viď? Jako kdyby Java byla kdovíjak bezpečný jazyk. Např. tu nucenou mutabilitu jsme probírali, že. Další věc je nucená nullovatelnost všech referencí. A tak dále. Java si s runtime errory opravdu hlavu nedělá. Nařídit všem Javu by nebyl ekvivalent stavebních norem, to by spíš byl ekvivalent nařízení, že všichni musí stavět baráky ze stejného materiálu a víceméně stejným způspbem. To je prostě naprosto absurdní. (Jestli jsi ten komentář myslel ze srandy nebo jako trolling, tak dej vědět.)

Já na jednu stranu s tebou a Frantou souhlasim v tom, že jsou na projektech potřeba nějaké standardizace a nějaká štábní kultura. Nejsem fanoušek toho, aby na společném projektu každý člen týmu psal jiný kód, vlastní abstrakce, atd. a z toho důvodu nejsem fanouškem syntakticky minimálních jazyků jako Scheme apod (a asi i Lisp obecně).

Na druhou stranu to, co tady předvádíte, je IMHO už za touto hranicí, je to už prostě akorát fóbie z neznámého. Tak trochu to na mě dělá dojem, že tě děsí cokoli, co by sis nemohl otevřít jako projekt ve svém oblíbeném IDE a kde by se nedalo zmáčknout to staré známé F2.

Doporučil bych vám oběma coby ozdravnou kúru nahlédnout do komunity Golangu. Tam se v podsatě úplně přesně stejnými argumenty ohánějí skoro neustále také, akorát s jedním drobným rozdílem - ten správný jednoduchý jazyk je podle nich Go a Java patří k těm ostatním zaostalým překomplikovaným jazykům. Třeby by mohl někoho pohled na tu stejnou argumentaci (demagogii?) akorát aplikovanou na jiný, ještě méně abstraktní jazyk, ke kterému nemá emocionální vazbu, trochu vyléčit.

[smazáno]

Doporučil bych vám oběma coby ozdravnou kúru nahlédnout do komunity Golangu.

Pripadne pro javisty rovnou gulag.

[Bystroushaak]

Ve chvíli, kdy někdo vyjádří vážně extrémní názor, který nedává smysl a není úplně konzistentní s předchozími názory, by možná stálo za to se zamyslet, jestli to nebyl sarkasmus, ironie, nebo záměrný trolling.

[ehm]

Softwarové inženýrství je jedna z mnoha technických disciplín a nevidím důvod, proč v něm tolerovat lidi, jejichž rozhodnutí se více řídí pocitem než rozumem. Tedy všichni odpůrci Javy a XML. Java funguje. XML funguje. Dynamické jazyky oproti tomu připomínají čarování, akorát z klobouku netaháš králíky, ale různé datové typy. Prostě jen tak.

[pavlix]

Tedy všichni odpůrci Javy a XML.

Zjevně se jim daří dobře, takže o čem se tu bavíme?

[Bystroushaak]

Mě je jasné, že je to jen trolling, ale čistě pro pořádek:

Zákazníkovi je většinou úplně v píči, kolik patternů, javy a xml jsi použil, zajímá ho jestli to funguje a splňuje specifikaci, nebo ne. A to může ve všech možných jazycích.

[ehm]

Přesně tak. Zajímá ho, jestli to bude fungovat. A teď jakou technologii zvolit, že...

[Bystroushaak]

Takovou, kterou ovládáš a máš jistotu, že to v ní zvládneš dotáhnout do konce.

[kralyk z abclinuxu]

FTR, taky si myslim, že trolluje. Ale co už.

Softwarové inženýrství je jedna z mnoha technických disciplín a nevidím důvod, proč v něm tolerovat lidi, jejichž rozhodnutí se více řídí pocitem než rozumem. Tedy všichni odpůrci Javy a XML. Java funguje. XML funguje. Dynamické jazyky oproti tomu připomínají čarování, akorát z klobouku netaháš králíky, ale různé datové typy. Prostě jen tak.

Osobně nejsem příznivcem menší statické kontroly než má Java, ale naopak větší. Tobě připadá nebezpečné žonglovat s dynamickými datovými typy. Ok, fair enough. Mně ale nepřijde jazyk, kde všechno je nullovatelná reference a kde takřka jakýkoli přístup k jakémukoli objektu může zhučet na NullPointerException o moc lepší.

[ehm]

Další věc je nucená nullovatelnost všech referencí.

To je další věc, kde je C# dál. Pokud referenci neuvedeš jako nullable (místo Type napíšeš Type?), tak to nikdy nemůže být null. Java se to částečně snaží řešit pomocí Optional, ale fakt to není ono a v komunitě se spíš spekuluje, jestli to vůbec dává smysl používat. Kotlin to řeší syntakticky stejně jako ten C#.

A zatímco všechny trochu rozumnější jazyky řeší Hoareovu „billion dollare mistake“, tak lidi začnou používat JavaScript, který vedle null zavádí ještě undefined a NaN. To dává smysl!

Tak trochu to na mě dělá dojem, že tě děsí cokoli, co by sis nemohl otevřít jako projekt ve svém oblíbeném IDE a kde by se nedalo zmáčknout to staré známé F2.

Tak zvyknul bych si na jiné IDE, ale to musí nějaké existovat. V Pythonu používám jen textový editor, REPL a občas ještě online dokumentaci. Ten komfort je úplně někde jinde. Žít se s tím dá, ale proč? Dřív jsem používal PyDev v Eclipse, ale nebylo to úplně ono (kvůli té dynamické podstatě Pythonu), takže se mi přestalo chtít kvůli těm malým projektům šachovat s IDE, vytvářet v něm projekty apod.

Psát bez IDE je krok o 30+ let zpátky. První Turbo Pascal vyšel 1983. Od té doby se objevil autocomplete, integrace s VCS a další a význam IDE se ještě zesílil.

IntelliJ a Eclipse pro Scalu podporují worksheets, což je normálně zdroják, který ale jde vyhodnocovat přímo v IDE. Na jedné straně vidíš výrazy, na druhé straně jejich výsledky. Na rozdíl od REPLu lze ten kód plnohodnotně editovat – není nutné zápasit se šipkou nahoru v případě překlepu a znovu zadávat celou definici funkce apod. A máš tam ten autocomplete, syntax highlighting i zobrazování dokumentace.

Teď se s různými editory roztrhl pytel, protože se masivněji začaly používat dynamické jazyky (zejména asi ten JavaScript), kde IDE z principu nemůže mít takový význam. Takže máme Sublime, Atom, Visual Studio Code a určitě nějaké další. Ale to je jen další důkaz, že IT dělá krok dozadu místo dopředu.

[Bystroushaak]

Psát bez IDE je krok o 30+ let zpátky. První Turbo Pascal vyšel 1983. Od té doby se objevil autocomplete, integrace s VCS a další a význam IDE se ještě zesílil.

To bude tím, že to neumíš. Já mám třeba v Sublime jak lintery, tak autocomplete, GIT i refactoring a používám to každý den. Netvrdím, že to bylo lehké nastavit, ale funguje to přesně jak chci. Kolega používá VIM a kupodivu tam má úplně to samé, co mám v Sublime. Už dávno to nefunguje tak, že bys měl jen tupý editor, dneska je všechno modulární a můžeš si z toho postavit IDE přesně na míru.

Jinak existuje Pycharm, což je plnohodnotné IDE od jetbrainsu. Používá to hodně lidí (brácha třeba, u nás v práci tak polovina). Mě to sralo protože ten editor v tom dosahuje tak 10% schopností Sublime.

[ehm]

Však to asi je IDE. Sám to i píšeš:

dneska je všechno modulární a můžeš si z toho postavit IDE přesně na míru

Jak se ten tvůj toolchain v praxi liší třeba od toho Pycharmu neumím posoudit. Na druhou stranu to nic nemění na tom, že spoustu lidí (a tipoval bych, že většina), to pořádně nastavené nemá, protože je to PITA a duplikování práce, co dělají třeba vývojáři v právě JetBrains.

Mimochodem, na jaké úrovni je statická analýza v Pythonu? Když volám funkci, která vždycky vrací objekt nějakého typu, tak by to mohlo umět našeptávat metody toho objektu. Jak se to chová v případě, že ta funkce může vracet objekt jednoho typu, nebo druhého typu? Našeptá to průnik metod z obou typů? A jak je to rychlé? Zpracovává to jen změněné soubory a ty si to cachuje, takže při volání té funkce to nemusí znovu parsovat zdroják, ale jen to koukne na předzpracované informace?

[Bystroushaak]

Příloha:

• autocomplete.png (35563 bytů)

Mimochodem, na jaké úrovni je statická analýza v Pythonu? Když volám funkci, která vždycky vrací objekt nějakého typu, tak by to mohlo umět našeptávat metody toho objektu. Jak se to chová v případě, že ta funkce může vracet objekt jednoho typu, nebo druhého typu? Našeptá to průnik metod z obou typů? A jak je to rychlé? Zpracovává to jen změněné soubory a ty si to cachuje, takže při volání té funkce to nemusí znovu parsovat zdroják, ale jen to koukne na předzpracované informace?

V Sublime je popravdě na docela nízké úrovni. V pycharmu z toho co jsem slyšel podstatně lepší. Rychlé mi to přijde dostatečně na to, abych se nemusel starat jak je to rychlé.

Když volám funkci, která vždycky vrací objekt nějakého typu, tak by to mohlo umět našeptávat metody toho objektu. Jak se to chová v případě, že ta funkce může vracet objekt jednoho typu, nebo druhého typu? Našeptá to průnik metod z obou typů?

Jo, to funguje co jsem tak teď rychle zkoušel, viz příloha (Sublime).

[ehm]

Pěkná ukázka. V tom prvním případě to ovšem není průnik, ale sjednocení – vrací to obě metody, i když reálně vždy půjde volat jen jedna. Průnik by zde byl prázdný, tedy bez znalosti toho, jaký typ metoda doopravdy vrací (jaký bude výsledek té podmínky) bys neměl volat nic. Asi by bylo fajn, aby to ty našeptané metody nějak barevně odlišovalo podle toho, jestli tam jsou přítomné vždy, nebo podmíněně.

U těch zbylých dvou případů se mi líbí, že pokud je ten výraz vždy pravdivý, našeptává to rovnou jen podle toho, co je skutečně dosažitelné.

Našeptávání typů argumentů to taky umí?

---

BTW. Když jsem hledal náhradu za Eclipse, přemýšlel jsem mj. nad podobným přístupem, tj. poskládat si IDE okolo nějakého editoru. Hlavní motivací tady bylo to, že bych měl jediný univerzální editor na všechno, a s trochou štěstí by to bylo i víc light-weight než full-blown Java IDE, takže bych se vyhnul upgradu HW. Jenže pak jsem si uvědomil, že bych musel řešit:

• integraci s build systémem a importování projektů
• spouštění aplikace/testů, debuggování
• navigace v kódu/projektu
• autocomplete, zobrazování deklarací/Javadocu
• refactoringy, klávesové zkratky pro generování kódu

Tohle jsou ty úplně nejnutnější věci, ale snad každá z těch položek se ukázala jako netriviální. V zásadě by to asi nějak šlo, nebo s dostatečně customizovatelným editorem bych si to tam třeba nějak dolepil sám, ale ve výsledku mi prostě přišlo, že to fakt nestojí za to.

Dokonce jsem kdysi někde zaznamenal projekt, který to řešil tak, že nastartoval headless Eclipse, se kterým pak socketem komunikoval a v podstatě všechny tyhle věci řešil přes něj. Tuším, že to byl nějaký plugin do Vimu, Emacsu, nebo něčeho podobného.

Když člověk přechází z IDE, kde je to fakt integrované a sladěné všechno dohromady, tak rychle narazí na nedostatky. Ono jsem z toho výčtu spoustu věcí vynechal. Třeba budu chtít zjistit, jaké mám pokrytí testem. V IDE se s tím počítá hned, zatímco tady bych se asi zase musel shánět po tom, jak to do svého toolchainu zadrátovat tak, aby mi editor podbarvil pokryté/nepokryté řádky. Nebo budu chtít nastavit podmíněný breakpoint – jak to z toho editoru udělám? IntelliJ umí při zadávání conditional breakpointu i ten autocomplete. Totéž platí v případě, že něco debugguji a zastavil jesm na breakpointu – můžu zadávat výrazy nebo i bloky kódu do okna, které se nijak neliší od normálního editoru. Tedy to opět našeptává i zobrazuje dokumentaci. A tak dál.

V podstatě je to tak, že jak rostu jako vývojář, tak odhaluji stále více a více způsobů, jak mi to IDE může usnadnit práci. Když to nepotřebuji, tak mi ty funkce nepřekáží, a když je potřebovat začnu, tak tam jsou. Kdybych si to skládal sám, každou věc, kterou bych začal potřebovat (nebo prostě jen začal být schopný využít), bych si tam musel přidávat sám.

A poslední věc je, že ty pluginy, co jsem většinou takhle někde objevil, byly dost často nějaký menší open-source, kterému se nedá dlouhodobě moc věřit. Té stability bych se dost obával. Je fakt, že kdyby teď JetBrains zkrachoval, tak přijdu o celý nástroj – ne jednu jeho část. Jednak jsem ale před přechodem na IntelliJ trochu ověřoval jejich hospodářské výsledky (:D), druhak bych bez upgradů asi pár let přežil – pokud to bude podporovat poslední verzi jazyka a nebudou tam bugy. Pokud by to náhodou neuvolnili jako open-source, mohl bych mezitím přejít na jiné IDE, nebo si to tedy zkusit poskládat sám okolo toho editoru.

[xkucf03]

Nebo budu chtít nastavit podmíněný breakpoint – jak to z toho editoru udělám? IntelliJ umí při zadávání conditional breakpointu i ten autocomplete. Totéž platí v případě, že něco debugguji a zastavil jesm na breakpointu – můžu zadávat výrazy nebo i bloky kódu do okna, které se nijak neliší od normálního editoru. Tedy to opět našeptává i zobrazuje dokumentaci. A tak dál.

BTW: totéž dělají Netbeans.

A hodně dobrá je integrace s verzovacím systémem – máš podbarvené řádky, které jsi změnil, můžeš jednotlivé změny vracet nebo si zobrazit původní verzi, je tam integrovaný blame/annotate, prohlížeč historie, diff, vše se zvýrazněním syntaxe. K tomu ještě lokální historie (IDE průběžně ukládá a dá se vrátit k předchozím verzím).

[ehm]

A hodně dobrá je integrace s verzovacím systémem

Abych řekl pravdu, tak zrovna ta integrace s VCS je přesně to poslední, co používám. Což má prapůvod v tom, že jsem se s Gitem původně začal „učit“ přes klikátko v Eclipse a smazal si celodenní práci. Raději jsem se tedy s Gitem naučil pracovat z terminálu. Teprve pak jsem začal zpátky začleňovat i to IDE na úlohy, kde mi to přijde rychlejší/vhodnější než dělat to ručně. Příkladem je třeba prohlížení historie souboru.

Stagování dělám v git-cola. Důvod tady je spíš iracionální – dívám se na ten kód v jiném prostředí a víc mi to pomáhá si to po sobě překontrolovat.

Mám v podstatě takové workflow, že kód napíšu v IDE a staguji to v git-cola. Když při čtení diffu narazím na něco, co bych ještě chtěl opravit, tak skočím do IDE a napíšu si k tomu řádku FIXME. Většinou to ale napřed stagnu, takže to samotné FIXME už uvidím v nestagnutých změnách. Takhle projdu všechny soubory (pokud nenarazím na něco hodně zásadního).

Pak se vrátím do IDE a vyřeším všechny FIXME. Ty soubory si nechávám otevřené, takže prostě jen jdu soubor po souboru a čistím to. Pak se znovu přepnu do git-cola a dívám se, že v diffu zmizelo FIXME a přibyla oprava. Zase to nastaguji a pak většinou dělám commit.

Zrovna v tomhle workflow je IMO dost prostoru pro zlepšení, protože třeba než FIXME můžou být lepší záložky, a tak. V neposlední řadě je potřeba říct, že mám to štěstí, že nemusím moc řešit mergování, čímž se mi práce s VCS dost zjednodušuje.

K tomu ještě lokální historie (IDE průběžně ukládá a dá se vrátit k předchozím verzím).

Jop, IntelliJ to má taky. Jestli to umí Eclipse nevím, ale každopádně jsem o tom nevěděl, když jsem přišel o tu celodenní práci (viz výše). :) Ale nebyla to taková tragédie a už je to dávno.

[kralyk z abclinuxu]

Java se to částečně snaží řešit pomocí Optional, ale fakt to není ono a v komunitě se spíš spekuluje, jestli to vůbec dává smysl používat.

No IMHO moc ne, v podstatě si tím jen přidáš další nulovatelný stav navíc, takže Optional<Foo> může být buď null nebo empty nebo Foo. Optional dává smysl, když potřebuješ přidat nulovatelnost někde, kde není. Což není případ Javy.

A zatímco všechny trochu rozumnější jazyky řeší Hoareovu „billion dollare mistake“, tak lidi začnou používat JavaScript, který vedle null zavádí ještě undefined a NaN. To dává smysl!

Njn tak to je JabbaScript, co bys chtěl Alespoň ale existuje TypeScript, který má možnost strictNullChecks (nebo taknějak), s kterou se to chová podobně jako C# / Kotlin. Jenže samozřejmě je pak na lidech, jestli to použijí (a jestli vůbec použijí TS místo holého JS).

Teď se s různými editory roztrhl pytel, protože se masivněji začaly používat dynamické jazyky (zejména asi ten JavaScript), kde IDE z principu nemůže mít takový význam. Takže máme Sublime, Atom, Visual Studio Code a určitě nějaké další. Ale to je jen další důkaz, že IT dělá krok dozadu místo dopředu.

IMHO je to hlavně otázka zvyku a toho, jaký komfort vyžaduješ. Dřív jsem pracoval výhradně s IDE, dnes používám radši editor + případně nějaké pluginy na napovídání nebo hledání symbolů nebo jinou statickou analýzu, ale moc je neřešim. Používám hodně příkazovou řádku na všechno možné (třeba git atd.), dokumentaci atd. Mysim si, že to mam někde zhruba na půl cestě mezi holým editorem a IDE. Používání full-blown IDE se všemi těmi vymoženostmi by mi možná zvýšilo efektivitu v nějakých případech, ale moc nevěřim, že by to mělo velký efekt v globálu. Každá další fíčura IDE mi zvyšuje produktivitu méně a méně. A když pak natrefim na kolegu, který používá víceméně jen základní vim se syntax highlightingem, a přesto je o dost produktivnější než já, tak už vůbec nemám motivaci se zabývat nějakým IDE...

[ehm]

No IMHO moc ne, v podstatě si tím jen přidáš další nulovatelný stav navíc, takže Optional<Foo> může být buď null nebo empty nebo Foo.

Tak nastavit Optional na null už by byla ultra prasárna. Ale jasně, stát se to může a jazyk tomu nedokáže zabránit.

Ono si mimochodem pohrávám s myšlenkou, že bych ten nullable do Javy nějak doplnil (formou anotačního procesoru – tj. dodatečné analýzy AST v čase kompilace). Ale zatím mě nenapadá, jak to udělat pěkně.

Alespoň ale existuje TypeScript

O TypeScriptu jsem se mj. zmiňoval v #601 jako o dalším zbytečném jazyku.

který má možnost strictNullChecks (nebo taknějak), s kterou se to chová podobně jako C# / Kotlin

Tak aspoň něco.

A když pak natrefim na kolegu, který používá víceméně jen základní vim se syntax highlightingem, a přesto je o dost produktivnější než já, tak už vůbec nemám motivaci se zabývat nějakým IDE...

Možná by byl s IDE ještě efektivnější (po nějakém čase). Asi budou existovat výjimky, kdy někdo v „holém“ textovém editoru dokáže být mnohem výkonnější než v IDE, ale budou to spíš výjimky (a je otázka, do jaké míry by v tom hrál roli třeba psychický blok). Tedy alespoň co se high-level programování týká.

Nemyslím si, že někdo z Linux kernel developerů používá IDE. Spíš tam naprostá většina lidí pojede vim, Emacs, nebo něco podobného. Možná pár pluginů k tomu. Jenže tam to bude do značné míry tím, že pořádné IDE asi ani není k dispozici, debuggování se nekoná apod. Tuším, že dokonce byly nějaké pokusy jít touhle cestou a usnadnit vstup novým developerům, ale Linus to utnul s tím, že tímhle přístupem se to vyvíjet nedá (+ nějaké jeho obvyklé držkování).

[smazáno]

Možná by byl s IDE ještě efektivnější (po nějakém čase).

Predpokladam, ze neprogramuje v jave, takze IDE nepotrebuje, aby se v tom bordelu vyznal :D.

[ehm]

Tak se možná pletu. Viz třeba LinK+.

[kralyk z abclinuxu]

Nemyslím si, že někdo z Linux kernel developerů používá IDE. Spíš tam naprostá většina lidí pojede vim, Emacs, nebo něco podobného.

Ano, to je ta kategorie, o které mluvím. Resp. kernel jen někteří většinou userspace, ale i tak low-level unix záležitosti. Debugování se pochopitelně koná, akorát v CLI. Ono je pochopitelné, že v takové situaci potřebuješ používat spíše příkazovou řádku než IDE, protože to má mnohem větší flexibilitu. Potřebuješ si k práci třeba nějak specializovaně nastavovat systém/stroj a/nebo pracuješ na vzdáleném stroji a/nebo více strojích najednou, takže ssh, tmux atd... IDE se do tohohle nehodí.

[ehm]

Hm. Jak se vlastně debuguje kernel? Vím, že tam mají printk, ale dál? Představoval bych si to tak, že to spustím virtualizovaně třeba pod VMWare a píchnu se tam debuggerem. To by měla být jen otázka nastavení/nakonfigurování.

A pokud tohle funguje, tak by to mohlo být i v IDE. Nastartoval by se z něj emulátor, kód by šel krokovat, číst si hodnoty proměnných (pokud tam jsou debuggovací symboly), registrů apod.

Co se může debuggovat dost blbě jsou věci, kde dojde v případě zastavení k timeoutu. I když ani to by nemuselo být nutné, pokud by to stopnulo fakt celý virtuální stroj, tedy včetně hodin.

Ale řekl bych, že vývojáři kernelu to budou většinou dělat spíš jinak. Jak to dělá Linus nechápu už vůbec – co jsem slyšel/četl, tak se k patchům často vyjadřuje jen po mailu a jinak to prostě merguje. Že by to nějak testoval, natož ladil, jsem neslyšel. Jestli to fakt všechno dělá z hlavy, tak je to trochu WTF.

[kralyk z abclinuxu]

Začnu od toho, co vím...

V Linux kernelu je hodně ve zvyku používat printk. Ale je možné se debugerem píchnout do kernelu skrz QEMU nebo KVM (o VMWare nevim, to asi ne) anebo skrz JTAG (což vyžaduje HW podporu).

Další možnost je, že když ti systém padne na hubu a máš nakonfigurovaný kdump, tak ti to vyprodukuje crashdump, kterej můžeš analyzovat pomocí gdb.

Mam taky jistou zkušenost s nástrojem mdb na systémech illumos/Solaris a ten umí debugovat bežící kernel "svého" systému a je celkově nad gdb dost napřed co se týče low-level. Umí některé velmi pěkné věci jako procházet kernelové struktury na živém systému user-friendly způsobem a podobně. Je velká škoda, že Linux nemá plnohodnotný ekvivalent mdb. Na druhou stranu zase gdb má např. lepší source-level debugging.

BSD tuším taky používá na tohle gdb podobně jako Linux, ale nevim přesně. Mac OS X a Windows vůbec nevim.

Co se může debuggovat dost blbě jsou věci, kde dojde v případě zastavení k timeoutu. I když ani to by nemuselo být nutné, pokud by to stopnulo fakt celý virtuální stroj, tedy včetně hodin.

Na takovéhle věci můžeš na Linuxu použít kprobe, na BSD/Masox/illumos/Solaris je k dispozici DTrace (další excelentní ladící nástroj ze Sunu). Windows vůbec nevim.

Ale řekl bych, že vývojáři kernelu to budou většinou dělat spíš jinak. Jak to dělá Linus nechápu už vůbec – co jsem slyšel/četl, tak se k patchům často vyjadřuje jen po mailu a jinak to prostě merguje. Že by to nějak testoval, natož ladil, jsem neslyšel. Jestli to fakt všechno dělá z hlavy, tak je to trochu WTF.

On tohle AFAIK hodně deleguje na maintainery subsystémů.

[ehm]

Ale je možné se debugerem píchnout do kernelu skrz QEMU nebo KVM (o VMWare nevim, to asi ne) anebo skrz JTAG (což vyžaduje HW podporu).

To zní dobře. VMWare jsem zmínil jen proto, že vím, že tam podobné věci jdou dělat. Pokud to jde i s jiným hypervizorem, tak tím líp.

JTAG vypadá zajímavě, to jsem neznal.

Mam taky jistou zkušenost s nástrojem mdb na systémech illumos/Solaris a ten umí debugovat bežící kernel "svého" systému a je celkově nad gdb dost napřed co se týče low-level. Umí některé velmi pěkné věci jako procházet kernelové struktury na živém systému user-friendly způsobem a podobně.

To zní hodně krutopřísně.

On tohle AFAIK hodně deleguje na maintainery subsystémů.

Asi jo, ale občas jim taky dělá review. A nakonec je to on, kdo to zamerguje. Sice větší merge nedělá a vrací to zpátky autorům těch commitů, ale že by všechny zbylé merge byly triviální a bez rizika chybování?

Bylo by docela zajímavé kernel vyvíjet tak, jak je zvykem psát high-level aplikace – tedy s plnohodnotným debuggerem (a samozřejmě možností to celé snadno spouštět), testy apod. Nejsem si jistý, že je to úplně dobře proveditelné a nutně lepší, ale docela by mě zajímalo, do jaké míry se to dá udělat. Nějaké automatické 3rd party testování existuje – nezkoumal jsem detailně, ale vypadá to spíš jako integrační testy.

Na druhou stranu, na takto low-level úrovni je tolik věcí, co se můžou rozbít, a tolik způsobů, jak se mohou zdánlivě nezávislé věci ovlivňovat, že integrační testy jsou nakonec asi mnohem smysluplnější než unit testy.

[kralyk z abclinuxu]

Ještě k tomuhle:

A pokud tohle funguje, tak by to mohlo být i v IDE.

Technicky vzato asi ano. Prakticky se s tím ale asi nikdo dělat nebude, protože ty nástroje jsou typicky zaměřeny na CLI. gdb i mdb mají svou vlastní poměrně komplexní příkazovou řádku. gdb má taky integrovaný python a poskytuje do něj API. DTrace má vlastní skriptovací jazyk. IMHO většina vývojářů používajících tyhle nástroje by nepovažovala IDE za přínos, naopak spíš za jistou ztrátu flexibility, kterou shell a CLI má. Další věc je, jak už jsem zmiňoval, vzdálený přístup. Když se na nějakým vzdáleným stroji něco špatnýho děje v kernelu nebo třeba v nějakým démonu nebo tak něco, tak máš nejjednoduší se tam připojit přes ssh a podívat se co se děje CLI nástrojema.

[deda.jabko]

Ono si mimochodem pohrávám s myšlenkou, že bych ten nullable do Javy nějak doplnil

Na to uz nekolik linteru existuje. Googli si anotace @Nullable a @NotNull.

[ehm]

Hej, to je vlastně pravda. Ono je to integrované i do IntelliJ, ale zatím jsem to pořádně nevyužil. Dávám si do TODO.

[JS1]

Kdy jindy to chceš dělat?

Az budeme vedet, jaky problem chceme resit? Pokud nekdo navrhuje "univerzalni jazyk" (coz uz samo o sobe je trochu chucpe), tak nevi, jaky problem se bude resit, a tudiz by to ani nemel omezovat.

V libovolne fazi muzes prijit a rict: Tohle by se dobre vyresilo makry, takto. A muzes mit pravdu nebo ne.. Proc predbihat udalostem?

To není záležitost abstrakce, ale syntaxe.

Ne. Assembler neni jen "sloziteji zapsana Java". Napriklad v nem nejsou podminene prikazy nebo funkce, coz jsou dnes bezne pouzivane abstrakce.

A tak na každém projektu budeš opakovat tytéž volby? Psát coding-style, pak guidelines, kdy jak co zapsat, resp. jakou konstrukci použít, a ve výsledku budeš používat jen striktní subset toho jazyka.

Ne, tyhle veci se normalne predavaji z generace na generaci. To co rikas neni pravda. Podivej se treba na Python. Lide nepouzivaji jen striktni subset, prestoze maji coding guidelines a podobne veci. Jazyk ale programatory a priori prilis neomezuje.

A nebo taková omezení zavádět nebudeš a v naprosté většině případů to dopadne blbě.

Tenhle argument celkem spolehlive vyvraci existence Lispu.

[ehm]

Pokud nekdo navrhuje "univerzalni jazyk" (coz uz samo o sobe je trochu chucpe), tak nevi, jaky problem se bude resit, a tudiz by to ani nemel omezovat.

Java je univerzální a mimořádně dobře použitelná v širokém spektru rozdílných úloh.

Ne. Assembler neni jen "sloziteji zapsana Java". Napriklad v nem nejsou podminene prikazy nebo funkce, coz jsou dnes bezne pouzivane abstrakce.

Ta schopnost parsovat zdroják bulvama je záležitost syntaxe.

Když jsme u toho, tak Assembler je syntakticky nejjednodušší jazyk v existenci.

Lide nepouzivaji jen striktni subset, prestoze maji coding guidelines a podobne veci.

Pak to podle toho dopadá. Totální bordel ve standardní knihovně, a tak.

Tenhle argument celkem spolehlive vyvraci existence Lispu.

LISP neexistuje. Je to fikce, podobně jako přistání Američanů na měsíci.

[kralyk z abclinuxu]

Java je univerzální a mimořádně dobře použitelná v širokém spektru rozdílných úloh.

lol

[ehm]

V Javě se píšou enterprise aplikace, počítačové hry, operační systémy, aplikace pro Android, dříve J2ME. V Javě je napsaná implementace Gitu, celá IDE, celé databáze, window manager. To vše jako kvalitní, objektový, staticky typovaný kód dodržující jednotné standardy. S něčím jsi na mém výroku nesouhlasil?

[Bystroushaak]

Úplně to samé se dá říct o všech možných jazycích, včetně Smalltalku který používá minimum lidí, nebo C, které jak se asi všichni shodneme, moc vhodné z hlediska bezpečnosti a udržitelnosti není. Dokonce asi v pythonu bych našel příklad na všechno co jsi napsal, včetně operačního systému.

To tvrzení je bezobsažné. Když se snažíš udělat kategorii z něčeho, co pasuje na všechny možné jazyky, tak je to kategorie k ničemu.

[ehm]

Ale jenom v té Javě to lze napsat jako kvalitní, objektový, staticky typovaný kód. V diskuzi výše jsme se všichni shodli, že ničím jiným než statickým typováním se nemá smysl zaobírat, takže třeba příklad s Pythonem je nepodstatný už z principu.

[Fluttershy, yay!]

Pche, Java.

Se divím, že tu dosud nikdo nevytáhl Adu.

[smazáno]

Nedelas ty ve statni sprave?

[ehm]

Ano. Připravuji podklady pro ten zákon zakazující užívání dynamických jazyků pod záminkou kybernetické bezpečnosti.

(Se mi líbí, jak si nikdo nevšiml té nenápadné změny titulku.)

[Bystroushaak]

(Se mi líbí, jak si nikdo nevšiml té nenápadné změny titulku.)

On tu někdo čte titulky? Jsem si nevšiml že tu jsou.

[ehm]

xkucf03 je občas mění, aby to odpovídalo tématu. Ale taky si toho všimnu většinou jen náhodou, tak mi přišlo příhodné to prubnout.

[Fluttershy, yay!]

(Se mi líbí, jak si nikdo nevšiml té nenápadné změny titulku.)

Všiml, nenapsal.

[kralyk z abclinuxu]

Beru enterprise a Android, zbytek je lol.

[kralyk z abclinuxu]

Vis, v tom je rozdil mezi nami. Ja se staram o to, jak pisu ja. Ty se staras o to, jak pise nekdo jiny. Nechci tvrdit, ze to prvni je produktivnejsi pristup, ackoli si to asi myslim.

Viz Programming Prodigy

Jinak osobně si myslím, že ani jeden extrémní přístup není dobrý - tj. na jedné straně myslet jen na to, jak píšu kód já, na straně druhé zase dávat příliš velký důraz na unifikaci. IMHO to chce nějaký zdravý balanc.

[JS1]

Ano, ale me slo o neco jineho. Nerikat druhym lidem - jsi neopatrny hlupak a proto nemuzes pouzivat makra. Zvlast pokud to rika nekdo, kdo je nezna (ono vetsinou ti, co nejakou konstrukci znaji, chapou jeji zpusob pouziti, a tudiz maji k radikalnim krokum jako zakaz vetsinou daleko).

[xkucf03]

Je zajímavé, jak to vždy vztahuješ k těm makrům – přitom jsem ti tu psal, že makra mi na těch jazycích vadí relativně málo a někdy bych je sám použil a považoval za užitečná.

[JS1]

Ono bavit se muzeme i o jinych vlastnostech, ale jen malo z nich lze do Javy pridat, aniz by se porusila (pripadne aniz by bylo zadouci porusit) zpetna kompatibilita.

[xkucf03]

Vis, v tom je rozdil mezi nami. Ja se staram o to, jak pisu ja. Ty se staras o to, jak pise nekdo jiny. Nechci tvrdit, ze to prvni je produktivnejsi pristup, ackoli si to asi myslim.

To je pořád dokola. Různí lidé mají různou zkušenost. A různé projekty zaslouží různý přístup. Už jsem to tu psal několikrát – pokud máš přebírat práci po někom jiném nebo dělat v týmu, kde nejsou lidi celý život, ale občas se mění, tak tě prostě musí zajímat i to, jak píší ostatní, ne jen to, jak píšeš ty (nebo tvoji stálí kolegové, se kterými jsi po dlouhé době sehraný). Pokud děláš na jiných projektech, tak ti může perfektně fungovat ten tvůj přístup – to jsem nikdy nerozporoval.

A realne je situace, kterou popisujes, spis dusledek idiocie managementu, nez cehokoliv jineho.

Jistě, za každý problém může hloupý manažer. Že by za to mohly vnější okolnosti tě nenapadlo? Software se vyvíjí proto, aby podporoval nějaké byznys procesy, aby poskytoval užitek. Pokud software dosáhne nějakého stupně dokonalosti a splní dostatečné množství požadavků, tak (alespoň nějakou dobu) přestává dávat smysl ho dál rozvíjet (další investice do rozvoje by nepřinesla odpovídající užitek) a jsi ve fázi, kdy software prostě požíváš tak, jak je, a máš přínos z dřívějších investic. Maximálně se opravují chyby nebo přidávají nějaké drobnosti, na což stačí pár lidí (kteří se tomu ani nemusí věnovat naplno a můžou současně udržovat nebo vyvíjet jiné projekty).

Když jde vývoj nějakého produktu do útlumu, tak to rozhodně nemusí znamenat chybu – může to být dost dobře tím, že program dosáhl dostatečného stupně dokonalosti a už není potřeba ho moc vylepšovat.

Jen mi vadi, kdyz mi nejaky namysleny idiot (= ty, v tomto pripade) vnucuje omezeny nastroj. Predpokladas, ze to udelam spatne, pritom ja si chci jen vybrat, protoze ja tu praci delam. S tim jdi do haje.

Ty si programuj, v čem chceš, pokud ti to vyhovuje a já to po tobě nebudu muset číst. Když ale mám dělat na projektu s ostatními lidmi, které si nemůžu tolik vybírat¹ nebo kteří na tom projektu dělali před deseti lety, což už vůbec neovlivním, tak jsem rád za tu Javu.

_{[1] což je dneska objektivní fakt – kvalifikovaných lidí je málo a musíš pracovat s tím, co je}

[kralyk z abclinuxu]

A projekt Lombok vhodny je? Vzdyt to jsou (ponekud bizarni) makra!

S makry vidím jeden problém. Lisp je hodně dynamický jazyk, který si moc nepotrpí na nějakou statickou analýzu. Makra v Lispu fungují jistě velmi dobře, ale jakmile bys je chtěl přenést do staticky typovaného jazyka, zejména pokud tam probíhá hodně statické analýzy, tak narazíš na to, že nebude jasné, ve které fázi překladu by měly s kódem interagovat. Moderní staticky typované jazyky kolikrát procházejí v kompilátoru několika fázemi analýzy a transformace.

Příklad: Typová inference. Měly by makra fungovat před, nebo po typové inferenci? IMHO se to nedá úplně určit, protože některá makra mohou potřebovat ke své funkci výsledky type inference, jiné zase mohou naopak chtít type inferenci ovlivňovat apod.

Ve výsledku zjistíš, že si potřebuješ s kompilátorem povídat v různých fázích a že ani tak nepotřebuješ Lisp-style makra, ale spíše API ke kompilátoru a možnost s ním interagovat během překladu. (K tomuhle, vypadá to, konvergují Julia nebo Rust.)

Tohle by nabízelo asi úplně největší sílu, ale je to IMHO velmi těžké dobře realizovat, mj. protože to vyžaduje, aby API kompilátoru bylo stabilní.

[JS1]

Ano, interakce maker a typu je znamy otevreny problem. Ono to trochu souvisi s tim, jakou vlastne tem typum pripisujes roli v programovani, ja vidim asi 4.

Trochu mi to, co rikas, pripomina architekturu GHC, kde se typove kontroluje i behem prekladu. A hacky do kompilatoru muzes taky poskytnout.

Co ovsem vidim predevsim problematicke na nekterych zastancich Javy, ze treba makra (i s temi problemy, o kterych mluvis) odmitaji a horsi alternativu, totiz generovani kodu, akceptuji. Je to odmitnuti poucit se z historie, z ideologickych duvodu. Nastesti ta ideologicnost s casem upada, jak se ukazuje, ze jine pristupy prinaseji nejaky uzitek (treba ten Lombok).

[ehm]

Generování kódu je lepší a zjednodušuje jazyk i kompilátor.

[xkucf03]

Z čeho ten kód budeš generovat? Z jiného jazyka/formátu? To omezuje možnosti bezešvé integrace se zbytkem kódu. Pokud k tomu použiješ ty anotace a anotační preprocesor, tak je to ta interakce s kompilátorem, ne generování kódu. Nebo bys na základě anotací mohl generovat kód (jiné třídy, než ty, ve kterých jsou dané anotace), ale to je dost nepraktické a omezující.

A všechny tyhle přístupy mají potenciálně negativní dopad na možnosti ladění – jak dohledat řádek (původního nikoli vygenerovaného) kódu k právě prováděné instrukci při krokování? Tohle je potřeba vždy zvážit, zda to stojí za to, a jestli si pod sebou člověk nepodřízne větev (třeba tím, že neexistují vhodné nástroje pro ladění nebo refaktorování nebo ani nikdy existovat nemůžou).

[ehm]

Právě proto je generování kódu nejlepší. Každý pochopí, že je lepší se na to vysrat. Ve výsledku je jednodušší jazyk, jednodušší kompilátor a programátoři si stejně poradí nějak jinak.

[JS1]

Generování kódu je lepší a zjednodušuje jazyk i kompilátor.

Jak uz jsme se drive shodli, tady se neshodneme, protoze generovany kod neni DRY. A ja jsem zastance DRY.

[xkucf03]

Proč by nebyl? Z tohoto pohledu je jedno, jestli je to makro nebo generátor kódu. V obou případech zapíšeš totéž nějak jednodušeji (a třeba deklarativněji) než v samotném jazyce bez maker/generátoru.

(samozřejmě se nebavím o generátorech, které se používají tak, že výsledný kód uložíš do verzovacího systému a udržuješ ručně a děláš v něm změny, takže ho nelze přegenerovat – to je zvěrstvo – na tom se snad shodneme všichni)

[smazáno]

Generovani kodu muze byt fajn ve specifickych pripadech. Libilo by se mi kdyby SQLAlchemy dokazalo generovat python moduly podobne jak to dela google protobuf, fungovala by pak totiz staticka analyza kodu (jedi) i v pripade kdy se pouzije SQLAlchemy automap.

Ano, slo by to resit i chytrejsimi dynamickymi type hints v jazyku jako mnohem cistejsi a univerzalnejsi reseni, ale to si jeste hodne pockame nez tohle bude v pythonu.

[JS1]

V pripade maker, uz tuto jistotu ztracis.

Na tom neco je, a proto jsem si posledni dobou oblibil Haskell - naprosta vetsina situaci, ktera by se v Lispu resila makry (ne reader makry) se da resit primo funkcemi. A v podstate jsem zmenil nazor "ze dne na den" kdyz jsem videl, jak se pres free monady da fakticky reinterpretovat kod (to co v Lispu resi homoikonicita).

Ale i v Pythonu musis treba vedet, jakou funkce vrati hodnotu, a to muze byt netrivialni zjistit. Ono to muze byt netrivialni zjistit i v jazyce se statickymi typy (treba vraci objekt a ty nevis, v jakem je stavu).

Ale to je skoro to, co pises dal:

V momente, kdyz muzes explicitne menit stav, prestavas mit jistotu nad tim, co se s programem deje.

Muzes byt konkretnejsi?

Takhle z hlavy.. (to jsem si nabeh ) No treba kdyz uvazim, co nekdy delaji kolem Dependency Injection. Pritom by casto stacil dalsi parametr, nekde, pripadne castecne vyhodnoceni. To same Builder pattern.

Skoro kazdy "design pattern" lze nahradit popisem "funkce ktera bla bla bla" (a skutecne staci jen tri slova)

Nebo delegaty. V podstate nic jineho, nez funkce s implicitnim parametrem (instanci). Ale chce to hned nove slovo.

Ja vidim velky problem v tehle "inflaci terminologie". Vysledek je, ze si lide nevsimnou, ze vlastne delaji tytez veci jen jinak, protoze tomu rikaji uplne jinak. A tak si zbytecne komplikuji situaci a znovuvynalezaji kola. A pak se dohaduji, co je lepsi, jestli abstraktni trida nebo interface, jestli vyjimka nebo navratova hodnota (viz diskuse vys), jestli konstruktor nebo tovarna, jestli private nebo protected.. Pritom se ty veci konceptualne temer nelisi.

JEE 7 (pod tlakem Springu) vypada uz jako sympaticky framework

Tak to rad slysim, protoze i kdyz se Jave zatim celkem uspesne vyhybam (coz je asi z moji strany zbytecne prehnane), tak pocitam, ze to nepujde delat donekonecna.

Druhy vyznam je filozofie samotneho jazyka. Kritizovat Javu za to, ze se primarne snazi pracovat s objekty misto toho, aby zavedla funkce, je stejne tak hloupe jako treba kritizovat Haskell, ze se vedlejsi efekty snazi resit pres monady a nezavede normalni prikaz prirazeni.

Uznavam, ze neco na tom, co rikas, je. (Vlastne je sranda, ze Haskell byl puvodne ideologicky jako line vyhodnocovany jazyk, a cistota byla jen dusledek, akorat dnes ty benefity vnimame opacne.) Ale troufam si tvrdit, ze matematici maji vetsinou lepsi cit pro tu "ideologickou" volbu (tak nejak ve smyslu "vse by melo byt tak jednoduche, jak je to mozne, ale ne jednodussi").

Mozna je to opravdu trochu nefer vuci autorum Javy. Ja OOP povazuji do budoucna za prekonane - byl to jisty napad, jak se vyporadat se stavem (rozdelit ho na male kusy a skryt ho do objektu, ktere se predavaji a navenek ukazuji jen rozhrani), a FP prislo s necim radikalne jinym a IMHO lepsim (stav si drzet globalne a vubec nikam ho nepredavat, naopak jen predavat opacnym smerem funkce - recepty, jak s nim nakladat - je to tak trochu dualni pristup). Ale autori Javy nemohli tak uplne za to, ze to lepsi neznali, to se zacalo ukazovat az po roce 2000.

Co jim asi vytykam vic je takove to elitarstvi typu "tohle bezny Franta vyvojar v jazyce nepotrebuje", treba co se tyka vyctovych typu, lambda funkci, hodnotovych typu, pretezovani operatoru, atd.

[ehm]

Ja vidim velky problem v tehle "inflaci terminologie". Vysledek je, ze si lide nevsimnou, ze vlastne delaji tytez veci jen jinak, protoze tomu rikaji uplne jinak.

To mi taky vadí. Víc záleží na principu. Ale dost jsi to zabil těmi příklady:

A pak se dohaduji, co je lepsi, jestli abstraktni trida nebo interface

Pokud bychom se bavili konkrétně v doméně Javy, je tam jeden významný rozdíl – třída může implementovat libovolné množství rozhraní, ale dědí vždy právě jednu třídu.

Mimochodem, když trochu odbočím, tak docela mě zaráží, že nikdo z lidí, co si chtějí kopnout do Javy, ještě nevytáhl defaultní metody u rozhraní v Javě 8. Zavádí to vícenásobnou dědičnost a stírá to rozdíly mezi třídou a rozhraním.

jestli vyjimka nebo navratova hodnota

Tyhle diskuze se často vedly v duchu „co chybělo v C“. Pokud se o to musíš starat úplně sám (buď mít rezervovanou hodnotu pro chybový stav, nebo vracet strukturu, nebo nastavovat globální stav), tak je to opravdu nepříjemné.

Pokud pro to jazyk má nějakou podporu (vracení dvou hodnot atp.), tak už tolik nezáleží na tom, jak tomu budeš říkat. Ony ty výjimky ve skutečnosti taky jsou návratovou hodnotou (to je taky argumentace za checked výjimkami v Javě – ale ty zrovna moc rád nemám).

jestli konstruktor nebo tovarna

V příkladu, který jsem uvedl, fakt v žádném vesmíru nejde hledat souvislost mezi konstruktorem a továrnou. U tovární metody/funkce budiž, ale to nebyl tenhle případ.

jestli private nebo protected

Jsou to modifikátory s různým významem. Je to nepodstatné z hlediska algoritmu? Ano, je. Je to nepodstatné z hlediska rozhraní? Ne, není.

[kralyk z abclinuxu]

Pokud bychom se bavili konkrétně v doméně Javy, je tam jeden významný rozdíl – třída může implementovat libovolné množství rozhraní, ale dědí vždy právě jednu třídu.

Wow. Až tak drastický rozdíl mezi nimi je. Hustý.

Mimochodem, když trochu odbočím, tak docela mě zaráží, že nikdo z lidí, co si chtějí kopnout do Javy, ještě nevytáhl defaultní metody u rozhraní v Javě 8. Zavádí to vícenásobnou dědičnost a stírá to rozdíly mezi třídou a rozhraním.

To mě vůbec nepřekvapuje, vzhledem k tomu, že lidi z ostatních jazyků často ten rozdíl ignorovali už dříve. Coby člověka zvyklého mj. na C++ jsem vždy považoval za hlavní rozdíl mezi class a interface to, že se použije jiný keyword, asi jako v C++ rozdíl mezi class a struct. Java 8 tomuhle dost dává zapravdu.

V příkladu, který jsem uvedl, fakt v žádném vesmíru nejde hledat souvislost mezi konstruktorem a továrnou.

• K rozdílu mezi tovární třídou a tovární funkcí: Když budeš mít (hypoteticky) lambda funkci, která bude capturovat nějaká data a vracet instance nějakých objektů, bude to továrna, nebo tovární funkce?
• K rozílu mezi konstruktorem a funkcí: Jaký je rozdíl mezi konstruktorem a statickou funkcí vracející novou instanci?

Osobně mi v obou bodech ty rozdíly přijdou spíše sémantické než principielní.

[ehm]

Továrna bude objekt, který můžeš předávat dál třeba pomocí DI. Jestli ten objekt vznikl z normální třídy, anonymní třídy, lambdy nebo method reference, je irelevantní.

[kralyk z abclinuxu]

Továrna bude objekt, který můžeš předávat dál třeba pomocí DI.

No tos tomu moc nepomohl, vzhledem k tomu, že neschopnost předávat funkce je čistě technická limitace Javy...

Co se týče DI a IoC, přiznám se, že je vůbec nechápu. A teď tím nemyslím ty techniky jako takové, ty chápu, používám a považuju za užitečné. Co mi uniká je proč tyhle pojmy existují / k čemu jsou dobré. Poprvé jsem se s DI setkal někdy na škole, kdy po odevzdání nějakého úkolu učitel poznamenal "Hezké použití Dependency Injection". Neměl jsem šajn, co tím myslí, dohledal jsem si to později a řekl na to něco jako "Aha". Tím to taknějak skončilo.

[deda.jabko]

Co mi uniká je proč tyhle pojmy existují / k čemu jsou dobré.

Ja jsem si to myslel jiz delsi dobu. Tobe v podstate navadi navrhove vzory, ale to, ze nektere postupy, jak navrhnout program maji sve pojmenovani.

[kralyk z abclinuxu]

Ja jsem si to myslel jiz delsi dobu. Tobe v podstate navadi navrhove vzory, ale to, ze nektere postupy, jak navrhnout program maji sve pojmenovani.

V zásadě ano. Respektive ani mi až tak nevadí čistě to, že ty postupy mají pojmenování, ale spíš to, jakým způsobem se s těmi pojmenováními pracuje, že se jim věnuje příliš velká pozornost (což pak způsobuje to zmíněné posouvání pozornosti z obsahu na formu) a že je kolem nich takový kult, který pak vede k tomu, že lidé je používají, aniž by se zamysleli nad podstatou toho problému.

Nejsem úplně 100% proti existenci návrhových vzorů (tj. těch pojmů), protože to může např. usnadňovat komunikaci (můžu použít kratší výraz "továrna" místo "funkce která vytváří instance bla bla...").

Ale tím by to IMHO mělo končit. IMO by návrhové vzory neměly být vnímány jako nějaká řešení pro nějaké problémy. Když budu například pracovat na nějakém codereview, absolutně mě nezajímá, jestli onen člověk použil "továrnu" nebo ne, protože bych musel nejdříve zvážit, jestli použití továrny je na místě v tom daném kontextu a následně se podívat, jestli byla naimplementována správně a vhodně pro dané použití. Místo toho můžu pojem "továrna" zcela ignorovat a prostě se podívat, jestli daný kód správně a vhodně řeší daný problém.

Návrhové vzory totiž neřeší žádné problémy. Vhodně vybraný a vhodně naimplementovaný návrhový vzor může být řešením nějakého problému, ale jde o to, že aby člověk návrhový vzor dobře vybral a dobře naimplementoval, musí (měl by) se zamyslet nad podstatou problému v podstatě úplně stejně, jako kdyby žádný návrhový vzory neznal.

[ehm]

cpt. obvious

[xkucf03]

Mimochodem: cpt. obvious, strawman, šikmá plocha, ad hominem, falšené dilema, No true Scotsman, ďáblův advokát a další jsou vlastně „návrhové vzory“ označující určité konstrukce v diskusích.

[Bystroushaak]

Mimochodem: cpt. obvious, strawman, šikmá plocha, ad hominem, falšené dilema, No true Scotsman, ďáblův advokát a další jsou vlastně „návrhové vzory“ označující určité konstrukce v diskusích.

Jsou to kognitivní biasy lidského myšlení. Poměrně fascinující věci, když o tom člověk začne číst, mimo jiné proto, že se nevztahují jen na diskuze, ale celkově na přemýšlení. Pokud si představíš lidské vědomí jako čočku (ve smyslu optické čočky), která se dívá na svět, tak kognitivní biasy jsou praskliny a způsoby, jakými ta čočka zkresluje obraz na který se dívá. Jejich znalost a schopnost je vidět ti může umožnit ty optické vady korigovat, i když je to docela těžké aplikovat sám na sebe a většina lidí (včetně mě) to na sebe aplikovat nezvládne (jako prasklá čočka co se dívá do zrcadla na sebe a vidí v něm prasklou čočku dívající se do zrcadla na prasklou čočku a prasklin je víc a víc a navíc je průhledná a uaá). Je to jeden z důvodů, proč píšu blogy a spoustu věcí konzultuji v diskuzích na abclinuxu, nebo IRC, protože ostatní lidi mi na ten bias většinou poukážou.

[xkucf03]

Jsou to kognitivní biasy lidského myšlení.

Myslel jsem to tak, že jsou to zažitá pojmenování pro nějaké opakující se scénáře/modely. Díky tomu můžeš říct „vytváříš falešné dilema“ a nemusíš to nějak víc rozpitvávat – ostatní vědí, o čem mluvíš. Stejně tak můžeš říct: „implementuj to jako továrnu“ nebo „místo továrny bych to řešil jako…“.

[pavlix]

To nejsou návrhové vzory, ale standardní knihovna funkcí. :D

[deda.jabko]

kult, který pak vede k tomu, že lidé je používají, aniž by se zamysleli nad podstatou toho problému.

Toto jsem v realnem svete jeste nevidel.

Ale tím by to IMHO mělo končit. IMO by návrhové vzory neměly být vnímány jako nějaká řešení pro nějaké problémy.

Navrhove vzory predstavuji urcitou meta-uroven pro popis programu. S navrhovymi vzory v programovacich jazycich to je podobne jako s vetnou stavbou v prirozenych jazycich. Taky mas postupy, ktere jsou zauzivane, protoze umoznuji nejlepe vyjadrit myslenku. (Vyresit nejaky typ problemu.)

Vezmi si treba vetu: Java, indonesky ostrov, dala pojmenovani kave a programovacimu jazyku. V teto vete dvojice indonesky ostrov predstavuje pristavek. Abys takovou vetu rekl/napsal, nepotrebujes znat, co je to pristavek, reknes to prirozene. Podobne jako prirozene pouzijes navrhovy vzor Factory nebo Singleton. Podobne, pokud budes delat review, nezajima te prilis, jestli se jedna o pristavek, ale kontrolujes faktickou spravnost.

Ale jsou situace, kdy je dobre se podivat i na tu meta-uroven. Dejme tomu, ze nekdo v tvem textu uvidi: Java, coz je indonesky ostrov, dala pojmenovani kave a programovacimu jazyku. a rekne ti ta vedlejsi veta to zbytecne natahuje, pouzi pristavek. Obema bude jasne, co mas udelat. Vsimni si, ze tady v tomto pripade resils problem, jak rozvinout informaci o podmetu. Jedno reseni byla vedlejsi veta, druhe pristavek.

Jake z toho plyne ponauceni. Pro tvorbu programu stejne jako bezneho textu neni potreba se prenaset na tu meta-uroven, na coz jsi evidentne prisel i sam, ale v pripade diskuze nad tim programem to muze byt uzitecne.

[ehm]

+1

[Bystroushaak]

Podobne jako prirozene pouzijes navrhovy vzor Factory nebo Singleton. Podobne, pokud budes delat review, nezajima te prilis, jestli se jedna o pristavek, ale kontrolujes faktickou spravnost.

Osobně mi to třeba nepřijde špatně, dokud to člověk netahá do jazyků, kde to není zapotřebí. Když už jsme u těch analogií, tak se pak podobá zombie, která není schopná přemýšlet a všude cpe patterny jeden za druhým bez toho, aby k tomu měl dobrý důvod.

Já vím, že mi napíšeš, že jsi nic takového neviděl, ale já ano. Zrovna včera jsem se z jednoho takového kódu málem zeblil a domluvil se s kolegou, že až bude příležitost, tak tyhle hovna zrefactorujeme a vyhodíme. Je to zrovna kód, kde jsou tři různé továrny (doslova DlServiceFactory, BrokerServiceFactory, BrokerRPCServerServiceFactory), vrstvy abstrakce a píčovin a z celého toho kódu smrdí java na sto metrů. Nejlepší na tom je, že když jsem to celé nastudoval a pochopil, tak jsem zjistil že mi to dokonce aktivně brání v tom co jsem chtěl udělat (přidat periodicky pouštěný callback z twisted na konkrétní metodu), protože je to tak zapouzdřené v zapouzdření zapouzdření (pro jistotu to ještě startuje další proces), že se k tomu vůbec nedostanu.

A já vím, že tohle je hejt na konkrétní kód, ale není to poprvé, co jsem se setkal s tím, kdy nějaký relativně jednoduše a elegantně řešitelný problém byl ukryt pod horami naprosto nesmyslné abstrakce design patternů v jazyce, který design patterny používající třídy a dědičnost z velké míry vůbec nepotřebuje, protože jsou tam jsou jiné naprosto nativní (viz pojem idiomatický python).

Když se zamýšlím, kde se to tak asi v těch lidech bere, tak nelze dospět k ničemu jinému, než že tenhle styl programování prostě deformuje způsob jakým člověk přemýšlí o problémech a z nástroje, který může být na konkrétním místě v konkrétním jazyce užitečný se stává dogma (je to přece základní abeceda *bleje duhu*). Protože tohle fakt není poprvé, kdy jsem něco takového viděl a stejně jako poznám lidi, co píšou C v pythonu, tak lidi co píšou javu jsou taky vidět na první pohled.

Tím samozřejmě nechci urážet každého, kdo takhle programuje, tak si to nevztahujte na sebe, klidně uznávám možnost, že jste výjimky. Je to jen pozorování stavu, kdy se takhle hodně lidí projevuje a zapleveluje aktivně codebase tisíci řádkami kódu, který by tam vůbec být nemusel, kdyby nestavěl abstrakci na vzorech, ale na konstruktech, které mu jazyk nabízí.

[deda.jabko]

Já vím, že mi napíšeš, že jsi nic takového neviděl, ale já ano

Uz jsem videl i par relativne standardnich javovsky veci udelane jako totalni overengineering, ale nehazel bych to na hlavu jazyku ci navrhovym vzorum. Ale nekdy ta slozitost muze prinaset sve plody, na ktere prijdes az casem, treba kdyz porebujes delat testy.

vrstvy abstrakce a píčovin a z celého toho kódu smrdí java na sto metrů.

kdy nějaký relativně jednoduše a elegantně řešitelný problém byl ukryt pod horami naprosto nesmyslné abstrakce

A tohle ma byt domena ciste Javy? Podivej se treba na GLIBC, tam je to jeste vyzivnejsi diky makrum.

[Bystroushaak]

Uz jsem videl i par relativne standardnich javovsky veci udelane jako totalni overengineering, ale nehazel bych to na hlavu jazyku ci navrhovym vzorum.

Já bych to asi házel na hlavu vysokým školám, protože tam nám to v javě cpali do hlavy taky. A pak takovému tomu cargo cultu, kde javista co nezná 20 patternů ani nedostane práci.

Ale nekdy ta slozitost muze prinaset sve plody, na ktere prijdes az casem, treba kdyz porebujes delat testy.

Já zrovna naprosto běžně a samozřejmě dělám testy skoro na všechno (kolikrát delší než samotný kód), o tom se tu už taky diskutovalo a ačkoliv je to možná neoptimální filosofie, tak v kombinaci s pythonem se mi to tak prostě osvědčilo. Ta složitost mi bude házet klacky pod nohy úplně vždycky, protože dynamičnost pythonu mi umožňuje si injectovat v testech více/méně co chci kam chci, takže jí vůbec nepotřebuju. Je to obecně jen YAGNI návrh modularity a abstrakcí.

A tohle ma byt domena ciste Javy? Podivej se treba na GLIBC, tam je to jeste vyzivnejsi diky makrum.

Mluvím za sebe z pohledu python programátora, kde vždycky když se potkám s tímhle, tak je to (bývalý) javista, nebo C# programátor. Tím nechci tvrdit, že je to doména jen jednoho jazyka, jak jsem psal, zrovna céčkaři mají taky jasný styl programování v pythonu, kde je od prvního pohledu vidět, že to psal člověk zvyklý na C. Běžně to nevadí, ale například u API je to vždycky k zeblití.

[xkucf03]

Já bych to asi házel na hlavu vysokým školám, protože tam nám to v javě cpali do hlavy taky.

Potíž s výukou je v tom, že v rámci ní nemáš prostor na to, udělat velký projekt – a přesto chceš studentům předat postupy, nástroje, metodiky, vzory…, které se běžně (a správně) na těch velkých projektech používají. V důsledku toho školní příklady z principu jsou overengineering a jinak to ani nejde, protože kdybys u školního příkladu zvolil minimalistický přístup pro splnění zadání, tak se na tom nic nenaučíš – a na skutečně velký projekt nemáš kapacitu.

Totéž máš i tady: Parametry příkazu, roury, Java a jiné jazyky – tam mi někteří psali, že to jde jednodušeji, ale nepochopili pointu – nešlo o to, vytvořit program, který vypíše parametry, ale o srovnání, jak se v různých jazycích píší modulární programy… a naučit se něco, co by se hodilo ve větších projektech.

Další věc je psychologie – je přirozené a lidské, používat něco, co jsi právě získal – a je jedno, jestli je to nějaká znalost, dovednost nebo nástroj typu profesionální multimetr, elektrikářské štípačky, momentový klíč, osciloskop atd. – budeš to s radostí používat, přestože by na daný úkol stačily mnohem primitivnější nástroje/postupy.

[kralyk z abclinuxu]

Potíž s výukou je v tom, že v rámci ní nemáš prostor na to, udělat velký projekt – a přesto chceš studentům předat postupy, nástroje, metodiky, vzory…, které se běžně (a správně) na těch velkých projektech používají.

Mně přijde ne úplně šťastné už se snažit nalít do studentů nějaké metodiky / vzory, zejémna pokud by to měl být jen v rámci jednoho jazyka / jedné ideologie (ať už Java nebo něco jiného). Resp. nechat to na později, někdy na vyšší ročník, kdy už máš větší šanci, že ten člověk je schopen si to nějak srovnat.

Ideální je, když má člověk možnost poznat co nejvíce jazyků a paradigmat. Ale tam narážíme zase na to, že, jak říkáš, na to není čas / prostor.

Přijde mi, že zejména na začátku je úplně nejdůležitější, aby si člověk hrál a zkoušel si věci nějak živelně / kreativně, a to klidně i špatným způsobem z návrhového / ideologického hlediska. Přijde mi, že nejvíc jsem se naučil na programech, který jsem totálně zprasil. Opět to je ale něco, co asi není úplně snadné nacpat nějak koherentně do nějakého studijního programu.

[xkucf03]

Mně přijde ne úplně šťastné už se snažit nalít do studentů nějaké metodiky / vzory

Viz komentář níže – je potřeba oboje, jak teoretické znalosti, tak praktické dovednosti.

Přijde mi, že zejména na začátku je úplně nejdůležitější, aby si člověk hrál a zkoušel si věci nějak živelně / kreativně, a to klidně i špatným způsobem z návrhového / ideologického hlediska.

Tohle si můžou dělat na střední (a někteří nadšenci s tím začínají jistě už na ZŠ). Ale na vysoké už by to mělo mít nějaký řád a úroveň.

Kolik myslíš, že dobrých programátorů začne s programováním až v osmnácti těsně před vysokou, aby si neodbyli to „období prasení“ v dřívějším věku a nemuseli jím procházet na VŠ? IMHO to k počítačům táhne člověka buď od malička a začíná už na ZŠ/SŠ nebo pak jsou lidi, kteří změní obor třeba ve třiceti.

A i u těch programátorských začátků je otázka, jestli je dobré jít úplně živelnou cestou. Na jednu stranu vlastní zkušenost je k nezaplacení, ale na druhou stranu postrčení správným směrem od nějakého mentora může být ještě lepší, přinejmenším urychlí rozvoj a časem si člověk tak jako tak ověří, že to byly dobré rady (třeba až uvidí chyby ostatních).

[kralyk z abclinuxu]

Tohle si můžou dělat na střední (a někteří nadšenci s tím začínají jistě už na ZŠ). Ale na vysoké už by to mělo mít nějaký řád a úroveň.

No, já právě nejsem úplně přesvědčen o tom, že ten 'řád a úroveň' opravdu ve výsledku přináší lepší výsledky. V některých případech ano, jindy ne. Třeba u výuky algoritmů a datových struktur je to celkem "jednoduchý"*. Podobně výuka základů programovacích jazyků. Ale třeba výuka návrhu, tam to už tak nevidim, protože 1) správnost je tam do jisté míry záležitost názoru, 2) různá zaměření mají i třeba radikálně různé požadavky na návrh a 3) schopnost dobře navrhovat je, myslím si, dost špatně předatelná. Co se třeba návrhových vzorů týče, aktuálně by IMHO bylo skoro lepší to přestat učit úplně a radši nedělat nic, dokud někdo nevymyslí lepší způsob.

*) Ačkoli i to se dá zrakvit - v jednom semestru jsme měli algoritmizační předmět, kde na přednáškách se jela jedna linie, na cvikách úplně jiná, a v dú/zápočťácích ještě jiná. Výsledek byl chaos.

a časem si člověk tak jako tak ověří, že to byly dobré rady (třeba až uvidí chyby ostatních).

Mám to taknějak smíšeně. Něco na škole vyidím zpětně jako dobré tady, něco jako ztrátu času nebo i špatné rady.

[Bystroushaak]

Potíž s výukou je v tom, že v rámci ní nemáš prostor na to, udělat velký projekt – a přesto chceš studentům předat postupy, nástroje, metodiky, vzory…, které se běžně (a správně) na těch velkých projektech používají. V důsledku toho školní příklady z principu jsou overengineering a jinak to ani nejde, protože kdybys u školního příkladu zvolil minimalistický přístup pro splnění zadání, tak se na tom nic nenaučíš – a na skutečně velký projekt nemáš kapacitu.

Potíž s výukou je, když se změní z výuky na tréning budoucích coding monkeys. Místo aby tě naučili myslet, učit se a dál na sobě pracovat, abys mohl vést filosofickou rozpravu se světem, tak do tebe nalejou základy čtyř jazyků (kdo neměl na VŠ pascal, lol?) a pár dogmat o tom jak se to podle nich má a nemá dělat a nazdar.

Další věc je psychologie – je přirozené a lidské, používat něco, co jsi právě získal – a je jedno, jestli je to nějaká znalost, dovednost nebo nástroj typu profesionální multimetr, elektrikářské štípačky, momentový klíč, osciloskop atd. – budeš to s radostí používat, přestože by na daný úkol stačily mnohem primitivnější nástroje/postupy.

No, to je právě ta smutná část. Protože škola kde by tě jen naučili používat osciloskop a multimetr a nedali ti k tomu žádnou teorii a praxi by byla škola úplně na hovno. Například moje střední začala ročním předmětem základy elektroniky, kde se jelo po elektronech ve valenčních sférách atomů a končilo někde u televizních vysílačů. Sice jsme nejeli Maxwellovy rovnice, ale všichni jsme tak nějak měli představu jak to vlastně funguje, což nám umožnilo přemýšlet o věcech, ne jen je tupě následovat.

Co je například úplně zarážející, že na většině škol se neprobírá ani historický kontext, ani původní ideály a většina lidí vyleze se základy nějakého programovacího jazyka, ale nemá vůbec tušení co to vlastně používají a proč to vypadá jak to vypadá, kde se to vzalo a co za tím bylo za myšlenky. Maximum co potkají je ještě tak Turingův stroj a to jen když jsou na fakt dobré škole (v Liberci třeba nebyl).

[xkucf03]

Potíž s výukou je, když se změní z výuky na tréning budoucích coding monkeys.

VŠ není učňák, ale na druhou stranu předávat jen teoretické znalosti a učit kritickému myšlení taky nestačí. Takoví lidé by byli v praxi nepoužitelní a kvůli tomu by se většina z nich nedostala k projektům, ve kterých by mohli uplatnit ty teoretické znalosti a myšlení. Ve výsledku by byli akorát znechucení a na obor by zanevřeli, protože by je nikdo k žádné práci nepustil. První zaměstnavatel by je toho musel doučit příliš moc, tudíž by se na to většina vykašlala a vzala někoho méně schopného, ale s praxí. Většina firem prostě nemá na to, aby s těmi lidmi pracovala v tak dlouhodobém horizontu a ještě platila tolik, aby jim ten člověk po zaškolení neutekl jinam. Přijde mi lepší, když se ty teoretické a praktické věci budou učit na VŠ společně a nějak systematicky. K tomu ideálně nějaká praxe jinde na částečný úvazek.

Protože škola kde by tě jen naučili používat osciloskop a multimetr

Nikde nepíšu „jen“ – a hlavně tahle část komentáře neměla nic společného se školou. Myslel jsem to tak, že když si něco koupíš nebo se něco naučíš, tak to pak prostě používáš i tam, kde to není úplně nutné, jen pro tu čistou radost, z toho, že máš nějakou novou věc nebo znalost. IMHO to je přirozené. Nebo ty to tak nemáš? A není to úplně iracionální přístup – jde i o to, aby si člověk zkalibroval odhad a ujasnil si, k čemu se daná věc/znalost hodí a získal nějaký cvik.

Co je například úplně zarážející, že na většině škol se neprobírá ani historický kontext, ani původní ideály

S tím souhlasím, tohle na VŠ určitě patří (a je smutné, kolik lidí nechodí na přednášky a uchází jim kontext). Ale to neznamená, že by tam neměla být i ta praxe. Ostatně od toho jsou přednášky + cvičení.

[Bystroushaak]

Ve výsledku by byli akorát znechucení a na obor by zanevřeli, protože by je nikdo k žádné práci nepustil.

Když vezmu, kolik projektů jsem celou VŠ dělal doma jen tak pro radost a abych si něco vyzkoušel, tak se to asi nedá vůbec srovnat s žádným jiným obdobím mého života.

První zaměstnavatel by je toho musel doučit příliš moc, tudíž by se na to většina vykašlala a vzala někoho méně schopného, ale s praxí.

:D

Úplně přesně tak to funguje. Nikoliv proto, že by studenti měli tak skvělou teoretickou přípravu (většina vůbec nemá ani základy toho co jsem popsal v blogu), ale protože velká část toho co se naučí je outdated ve chvíli, kdy konečně vylezou. Například já jsem se na školu vykašlal po 3 letech, když jsem viděl že bych musel přidat další rok. Nemám titul a přesto mě berou na pozice kde chtějí VŠ čistě proto, že mám praxi. Dokonce to jde tak daleko, že na VŠ se mě u pohovorů nikdy nikdo nezeptal (přestože v HR blábolech je VŠ podmínkou), kromě státní správy a tam jsem jim řekl, že si jí možná někdy dodělám a to je všechno. Dělal jsem tam dva a půl roku, dodneška mi občas volaj jestli nemám zájem, ale už si mě prostě nemůžou dovolit (32k hrubýho, lol).

Když do firmy někoho nabíráme, tak jak jsem psal už v blogu stejně nepředpokládáme, že by něco moc uměl, protože co leze z vysokých škol je stejně úplně k ničemu. Podstatné je, jak rychle se zvládne naučit nové věci. Například dneska jsme měli mít pohovor s klukem co teď skončil střední, který se sám naučil python. Nakonec teda ani nepřišel, ale dobře to ilustruje zoufalost pracovního trhu, kde už i ta praxe přestává firmy zajímat.

Ale to neznamená, že by tam neměla být i ta praxe. Ostatně od toho jsou přednášky + cvičení.

Zamýšlím se nad tím a přijde mi, že je špatně celá koncepce „programátorských“ vysokých škol, které počítají s tím, že na ně půjdou lidi z gymplu, kteří neumí programovat. Přitom na ně chodí i lidi ze střední, kde se předpokládá, že už umí pokročilejší matematiku (začíná se limitama a derivacema). Podle mě by měl být systém výuky navazující a už na gymplu učit programovací jazyk ve smyslu syntaxe a programování a VŠ by měla člověku ukázat jak to spolu teoreticky souvisí, kde se programovací jazyky navazují na matematiku, jak vznikly, jaké existují paradigmata a tak podobně. Vylézt by neměl člověk co umí napsat v javě jednoduchou aplikaci, ale člověk, který je schopný si napsat vlastní jazyk, nebo třeba databázi.

Škola by tě měla naučit přemýšlet nad principy, například ten turingův stroj (schválně kdo ho na VŠ měl), lambda calculus, taky třeba ty Gödelovo věty o neurčitosti, abys chápal co jde a kde budeš omezený. Měla by tě učit o kognitivních biasech a o tom jak přemýšlet o světě. Jak se nezastavit, až se školou skončíš a jak se sebevzdělávat. Například kdo měl předmět o tom, jak si dělat poznámky a jak se vlastně učit? Přitom to je celá podstata školy. Všude co jsem tak viděl, se nějak předpokládá, že to člověk pochytil, přitom existuje nespočet metod jak na to ^{(1, 2, 3)} a neustále vznikají nové.

Je mi jasné, že by se to asi úplně nelíbilo zaměstnavatelům, jenže proto jsou školy placené státem. Jejich cílem by nemělo být produkovat roboty pro práci v daném odvětví (k tomu jsou učnáky a střední), ale lidi, kteří to odvětví pozvednou dál, nebo založí úplně nová odvětví. Poslední dobou čtu třeba o historii matematiky a prostě začínám plně chápat Kaye, kde se bere jeho nasranost. Kde jsme sakra v historii špatně odbočili, že se z antické snahy o pozvednutí člověka na úroveň bohů stal tréning robo-otroků? Zcela seriózně přemýšlím, že až se budu k smrti nudit, tak založím kult technoklášterů ve stylu Anatému, kde bude cílem mnichů se nadále učit bez rušivých vlivů konzumního života, plně Stallman style.

</rant>

[Bystroushaak]

Jinak jako jeden z epických failů IT na VŠ mi přijde, že se ani neučí vědecká metoda. Samotný základ vědy, věc, na které stojí celá naše civilizace a žádné odvětví se bez ní neobejde. V podstatě ultimátní univerzálně použitelná debugovací metoda. A na IT oborech nic, většina lidí o ní ani neslyšela. Jako by nikdo ani neměl ambice udělat z IT / CS oboru něco víc než jen hraní si.

[pavlix]

Věda se moc na IT neučí, trocha matematiky ano, ale věda vůbec a vztah matematiky k vědě už vůbec ne. Ale ta matematika je někde super, to není jenom hraní si. Software má k matematice o dost blíž než k vědě.

[Agent]

Mě třeba zas fascinuje, jak se opomíjí výuka logiky, přitom už na střední by se mohla vyučovat, alespoň v nějaké lehčí obecné formě, ne hned nějaké rovnice. Já třeba dnes zjišťuju, že mi to asi dost chybí.

[ehm]

Na střední mají spoustu jiné práce, třeba s výukou „porozumění psanému textu“. Člověk by čekal, že se to lidi naučí už na základce, ale asi ne...

[deda.jabko]

Rad mluvis o biasech, ale sam se v nich topis az po usi.

Cos proboha studoval za skolu?

například ten turingův stroj (schválně kdo ho na VŠ měl), lambda calculus, taky třeba ty Gödelovo věty o neurčitosti, abys chápal co jde a kde budeš omezený.

Vsechno to jsem na VS mel s vyjimkou lambda kalkulu (ten byl az ve ctvrtaku) uz v bakalarske etape. AFAIK vsechny rozumne skoly v nejake forme TS uci, minimalne automaty maji i ty pofiderni.

Podle mě by měl být systém výuky navazující a už na gymplu učit programovací jazyk ve smyslu syntaxe a programování

A kdo to zaplati? Nastupni plat ucitele je nejakych 20 tis. hrubeho, lidi schopni dobre takove veci ucit se do skolstvi nepohrnou. (Ale s tim by slo neco delat, mozna kdyby nekteri byli ochotni platit dane.)

VŠ by měla člověku ukázat jak to spolu teoreticky souvisí, kde se programovací jazyky navazují na matematiku, jak vznikly, jaké existují paradigmata a tak podobně

V realnem svete jsou nejhorsi na vyuku programovani lide, kteri maji nejake zkusenosti, preucit je, aby veci delali spravne a ne podle toho, jak se naucili prod XY lety v nejakem obskurnim jazyce da hodne prace.

Například kdo měl předmět o tom, jak si dělat poznámky a jak se vlastně učit?

Jeste zapomnels na kurz, jak se stat uspesnym a kurz kaucovani. To jsou taky uzitecne veci.

[Bystroushaak]

Rad mluvis o biasech, ale sam se v nich topis az po usi.

Stejně jako každý koho jsem kdy viděl. Úplně stejně bych se mohl projít po tvém příspěvku a na všechny poukázat, ale meh, stejně by z toho byl jen flame o ničem.

Jeste zapomnels na kurz, jak se stat uspesnym a kurz kaucovani. To jsou taky uzitecne veci.

Ah, to pohrdání. Takže schopnosti učit se nepřikládáš důležitost, nebo ti přijde dostatečně dobrá? Nebo máš pocit, že jí nelze naučit a všichni kdo se o to snaží jsou šarlatáni s nejistými výsledky? V tomhle mi ta tvoje reakce není dost jasná.

[deda.jabko]

Nebo máš pocit, že jí nelze naučit a všichni kdo se o to snaží jsou šarlatáni s nejistými výsledky?

V podstate ano. Co jsem zatim videl, tak to byla snaha z osobnich zkusenosti delat univerzalni zavery, pricemz se nebral ohled na to, ze kazdy ma sve preference a kazdy obor vyzaduje uplne jiny pristup. Podobne, jak se to dela v (z nejakeho duvodu) popularnich knihach a seminarich na vyse zminena temata.

[Bystroushaak]

V podstate ano. Co jsem zatim videl, tak to byla snaha z osobnich zkusenosti delat univerzalni zavery, pricemz se nebral ohled na to, ze kazdy ma sve preference a kazdy obor vyzaduje uplne jiny pristup. Podobne, jak se to dela v (z nejakeho duvodu) popularnich knihach a seminarich na vyse zminena temata.

No, ale tak spousta věcí je docela univerzálních. Například je tak nějak jasné, že psaní poznámek ti pomáhá si věci lépe zapamatovat. Na to jsou výzkumy, kde se to zkouší. Pak se dá řešit struktura poznámek, zajímavá mi přišla třeba Cornell method, kde si v podstatě vytváříš různě detailní poznámky k jednomu subjektu a k nim jakési indexy. Nebo myšlenkové mapy - ty se do nás kdysi zkusila natlačit češtinářka, ale věnovala tomu jednu hodinu a to bylo málo. Ale stejně je dodneška používám v jakési kombinaci UML grafů a často mi to pomůže. Spousta lidí dneska prokrastinuje, tak máš pomodoro techniky a další podobné přístupy.

Podle mě by samozřejmě nemělo smysl tlačit jednu věc univerzálně všem, ale dávalo by smysl tomu věnovat třeba semestr a projít se studentama několik technik, aby si je mohli vyzkoušet a každý si mohl vybrat co chce. Přijde mi to jako potenciálně vysoce zisková snaha, kde když se snažíš lidi něco naučit, tak by bylo dobré je naučit prvně jak se učit.

[Fluttershy, yay!]

Toho je mnohem víc, včetně schopnosti napsat souvislý text nebo prezentovat… Ostatně, člověk může učit, aniž by s něčím takovým byl kdy konfrontován – a pak z toho plynou např. totálně wtf cvičení.

[xkucf03]

Ale s tim by slo neco delat, mozna kdyby nekteri byli ochotni platit dane.

Věřím, že pokud by ty peníze šly do vzdělávání, že by ochota platit daně byla vyšší. Když se ale většina peněz rozkrade nebo prožere, tak se nelze divit…

[ehm]

Přijde ti v pořádku, aby každý daňový poplatník musel povinně přispívat na vzdělávání jiných lidí? On sám se třeba dokáže vzdělávat sám a nepotřebuje k tomu žádné školy. Proč by si tedy z daní měl financovat konkurenci sobě samému?

[xkucf03]

Úplně přesně tak to funguje. Nikoliv proto, že by studenti měli tak skvělou teoretickou přípravu (většina vůbec nemá ani základy toho co jsem popsal v blogu), ale protože velká část toho co se naučí je outdated ve chvíli, kdy konečně vylezou. … nepředpokládáme, že by něco moc uměl, protože co leze z vysokých škol je stejně úplně k ničemu. Podstatné je, jak rychle se zvládne naučit nové věci.

Zrovna teď mám na projektu juniora, který dělal dřív testera a základy programování má ze školy. Během dvou dnů se zorientoval a ví, kde co hledat (a teď nemyslím záchody a kávovar), pouští si testy, debugguje, chápe, co ten kód dělá a kudy ten tok dat jde… už dělá i nějaké jednodušší úpravy. Samozřejmě, že se toho bude muset hodně doučit (ostatně to se člověk učí celý život), ale pokud by znal jen teorii a jen tam seděl a přemýšlel nad filosofickými otázkami a neznal ty základy (v tomhle případě Javu a SQL) a musel bych ho to učit já, tak by to nedávalo smysl s stál by mnohem víc, než kolik by přinesl užitku (i ve střednědobém horizontu). Proto mi přijde dobré, když se na VŠ učí kromě teorie i ty praktické základy, protože tam se to v rámci skupinových přednášek a cvičení, tzn. mnohem efektivněji než 1:1 – to je příliš velký luxus, který si většinou nemůžeš dovolit (jeden žák na jednoho učitele). Když se k tou přidají občasné individuální konzultace a samostudium, tak to funguje.

Podle mě by měl být systém výuky navazující a už na gymplu učit programovací jazyk ve smyslu syntaxe a programování a VŠ by měla člověku ukázat jak to spolu teoreticky souvisí, kde se programovací jazyky navazují na matematiku, jak vznikly, jaké existují paradigmata a tak podobně.

S tím souhlasím. Na SŠ a ZŠ by se toho mělo změnit dost. Dneska, když děti začínají s mobily a tablety už v předškolním věku, tak je potřeba jim předat co nejdřív tvůrčí pohled na svět a nečekat s tím na vysokou, protože jinak z nich vyrostou akorát konzumenti, kteří umí jenom matlat po displeji a zadat číslo svojí kreditky do formuláře (k tomu se nechají zaměstnat jako skladník v Amazonu nebo Kauflandu a čeká je skvělá budoucnost).

Takže ano, nějaké základy programování by měly být už na střední¹ – a na základce by se mělo učit pokročilé používání počítače a už tam by děti měly vědět, že existuje např. asymetrická kryptografie a k čemu je dobrá (samozřejmě po nich nikdo v tomhle věku nechce, aby věděli, jak to funguje uvnitř).

Jejich cílem by nemělo být produkovat roboty pro práci v daném odvětví (k tomu jsou učnáky a střední), ale lidi, kteří to odvětví pozvednou dál, nebo založí úplně nová odvětví.

Jasně, že by z vysokoškoláků neměli být roboti/dělníci. Ale taky si nedovedu představit, že bys čerstvého absolventa poslal řídit projekt, zakládat pobočku v cizí zemi, svěřil mu rozvoj strategie firmy… To taky končí špatně – a i kdyby ten člověk byl úplně zázračný a měl na to, tak nebude mít autoritu u ostatních, protože zatím nic nedokázal a neodvedl dosud žádnou reálnou práci. Teoreticky by mohl, kdyby měl titul z elitní školy a napsal diplomku relevantní k tomu, co se chystá dělat. Ale takových případů bude minimum. Ve většině případů bude lepší, když se vypracuje postupně, začne třeba jako ten tester, pak programátor a pak může dostávat větší úkoly. Jak dlouhá ta cesta bude je individuální, ale vynechávat by se IMHO neměla. A k tomu právě potřebuje i ty praktické základy (už ze školy, ne se je učit až v praxi).

Vylézt by neměl člověk co umí napsat v javě jednoduchou aplikaci, ale člověk, který je schopný si napsat vlastní jazyk, nebo třeba databázi.

To je hezké, ale tolik nových jazyků nebo databází není potřeba. To bys výrazně omezil počet absolventů? Nebo by se lidi učili něco, co nebudou nikdy potřebovat? Jde o to, aby se ti lidé nezahrabali na příliš nízkoúrovňových věcech – budou sice schopní vytvořit svůj jazyk, psát v assembleru, vědět, co dělá která instrukce procesoru, nebo budou umět napsat jednoduchý SŘBD, ale v praxi budou řešit úplně jiné úkoly, např. jak navrhnout vysokoúrovňovou architekturu a poskládat existující komponenty, jak řídit vztahy mezi dodavateli a zákazníky, rozhodnout, co vyvíjet externě a co vlastními silami, mít představu, jak roste riziko a režie, když se do projektu zapojuje víc lidí a firem². Tohle je někdy problém absolventů technických škol – příliš se věnují detailům a uchází jim větší celek.

…tak založím kult technoklášterů ve stylu Anatému, kde bude cílem mnichů se nadále učit bez rušivých vlivů konzumního života, plně Stallman style.

Nad tím jsem taky přemýšlel… Otázka je, jak to ufinancovat a jak by se to mělo lišit od nějaké lepší firmy. Na jednu stranu, v našem oboru ti stačí „tužka a papír“ (resp. počítač a síť), takže přímé náklady jsou minimální. Ale když započítáš i náklady ušlé příležitosti³ tak to přijde hodně draho. Osobně mi z toho vychází, že je nejlepší střídat období, kdy jednou děláš vývoj pro zákazníky a jindy se věnuješ plně svým věcem⁴ a máš absolutní volnost. V tom klášteře bys mohl (resp. spíš musel) dělat to samé – takže by to byla vlastně firma, která by nějakou podstatnou část zisku investovala do vlastního vývoje a interních projektů.

_{[1] a tím myslím pro všechny – ostatně matematiku, fyziku, chemii, dějepis, zeměpis… se taky učí všichni
[2] mimochodem, toto je daleko větší problém vývoje softwaru a hraje to společně s tou vysokoúrovňovou architekturou mnohem zásadnější roli, než třeba to, jak „dokonalý“ programovací jazyk používáš a jestli ti umožní napsat totéž na 400 nebo 500 řádcích nebo jestli podporuje makra a „plnohodnotné“ funkce
[3] ten člověk mohl pracovat na nějakém komerčním projektu pro zákazníka a vydělávat spoustu peněz
[4] které mají buď nějaký obecný přínos nebo můžou vést i k zisku, ale v dlouhodobějším horizontu, takže se jimi dá těžko živit teď hned}

[ehm]

To je nedostatek toho daného programátora, co ten kód napsal. Je úplně klidně možné, že mu ty design patterny natloukli do hlavy ve škole, nebo podlehl dojmu, že čím víc design patternů, tím víc Adidas, a teď to všude cpe bezdůvodně/nevhodně. A tedy se jedná o chybné použití.

Taky bych se vůbec nedivil, kdyby v Javě byl podíl špatných programátorů vyšší než v jiných jazycích. Zcela jistě jich bude vyšší absolutní počet, když Java je nejpoužívanější (nebo jeden z nejpoužívanějších) jazyků současnosti. Ale myslím, že i ten podíl může být vyšší – a bude to tím, že Java je široce vyučována na školách. Třeba na ZČU se, alespoň pokud vím, jede prakticky jenom Java a další jazyky jsou víceméně okrajové. A vzhledem k tomu, jak velká je po programátorech poptávka, není divu, že i ty chabé znalosti získané pouze ze školní výuky lze uplatnit na trhu práce, což může končit právě podobným prasokódem.

Ale opět – není to chyba design patternů a není to chyba Javy.

Obdobná situace panovala před lety u PHP. Tam je to trochu jiné tím, že PHP samo o sobě je totální zprasenina (tys ten „parser“ ostatně taky viděl, takže ti to nemusím vysvětlovat). Ale i tak lze v PHP napsat vcelku rozumný kód – jazyk jako takový tě rozhodně nenutí a snad ani nevybízí psát věci jako include "pages/".$_GET['page'].".php";. Byl to fakt, že PHP bylo – ve své době – velmi žádané a dostal jsi „za málo peněz hodně muziky“. Tím narážím na to, že ta vstupní bariéra asi nebyla o tolik nižší než v jiném high-level jazyce, ale rozhodně bylo snažší začít produkovat nějaké hmatatelné výsledky – v tomto případě weby.

Výsledkem bylo, že PHPčkaři byli považování za bastlíře a jako programátoři byli vnímání jako méněcenní. A do jisté míry to byla pravda – protože většina jich taková opravdu byla. Ale vina PHP je to jen velmi malá, pokud nějaká; PHP je příšerná technologie, ale i kdyby příšerná nebyla, ti stejní lidé by v ní stejně produkovali neskutečný hovnokód.

[kralyk z abclinuxu]

Uz jsem videl i par relativne standardnich javovsky veci udelane jako totalni overengineering, ale nehazel bych to na hlavu jazyku ci navrhovym vzorum.

To je nedostatek toho daného programátora, co ten kód napsal. Je úplně klidně možné, že mu ty design patterny natloukli do hlavy ve škole, nebo podlehl dojmu, že čím víc design patternů, tím víc Adidas, a teď to všude cpe bezdůvodně/nevhodně. A tedy se jedná o chybné použití.

Ježišmarja. Technicky vzato máš pravdu, ale stejně je na místě hodit design patternový cargo cult na Javu. Úplně stejně je na místě C/C++ hodit na hlavu přetejkání bufferů a předčasné optimalizace. Rustu zase obsesi se zero-cost abstrakcemi a návrhy na přepsání úplně všeho do Rustu. Haskellu zase masturbaci nad Zygohistomorphic prepromorphisms.

A tak dále. Zkrátka, jazyky nežijí ve vakuu, to, k jakému použití vedou a jaká je kolem nich kultura je důležité.

[ehm]

Reagoval jsem na Bystroushaaka, ne na deda.jabko, takže nevím, co tam dělá ta první citace.

Technicky vzato máš pravdu, ale stejně je na místě hodit design patternový cargo cult na Javu.

Ne, není. Chybné používání design patternů je chybné programování, které je zcela mimo dosah autorů jazyka. Neexistuje jazyk, ve kterém nebyl napsán chybně strukturovaný kód. Z majoritní části je v tomto i standardní API rozumně navrženo a over-engineering v něm nepozoruji, tedy ani nejde říct, že v tom jdou špatným příkladem.

[Bystroushaak]

To je nedostatek toho daného programátora, co ten kód napsal. Je úplně klidně možné, že mu ty design patterny natloukli do hlavy ve škole, nebo podlehl dojmu, že čím víc design patternů, tím víc Adidas, a teď to všude cpe bezdůvodně/nevhodně. A tedy se jedná o chybné použití.

Taky bych se vůbec nedivil, kdyby v Javě byl podíl špatných programátorů vyšší než v jiných jazycích. Zcela jistě jich bude vyšší absolutní počet, když Java je nejpoužívanější (nebo jeden z nejpoužívanějších) jazyků současnosti. Ale myslím, že i ten podíl může být vyšší – a bude to tím, že Java je široce vyučována na školách. Třeba na ZČU se, alespoň pokud vím, jede prakticky jenom Java a další jazyky jsou víceméně okrajové. A vzhledem k tomu, jak velká je po programátorech poptávka, není divu, že i ty chabé znalosti získané pouze ze školní výuky lze uplatnit na trhu práce, což může končit právě podobným prasokódem.

Ale opět – není to chyba design patternů a není to chyba Javy.

Tak já určitě nechci tvrdit, že je to chyba javy. Svůj pohled na chyby javy jsem napsal už v ostatních threadech a tohle k nim nepatřilo. V důvodech mi přijde, že jsi to trefil na hlavičku.

To že u toho mluvím o javě je něco, jako si dám pozor na cikána, čistě proto že mám špatnou zkušenost, ne proto že je to cikán. Ostatně sám jsem trochu pomáhal vychovávat dvě cikáňata, které měla matka v pěstounské péči a to mě naučilo. Například vysvětlovat, že fakt není dobré krást sirky a zapalovat ohýnky v posteli. Nebo topit koťata. Nebo kreslit pastelkama na zdi (opakovaně). A ač bych fakt rád zůstal bez předsudků, tak potom co se máma snažila pomoct jejich rodině a zajistila jim byt a prachy z neziskovky a cikánka se sedmi dětma to prochlastala a byt zkruvila během čtvrt roku, tak prostě předsudky mám.

Můj padawan v minulé práci byl javista (4 roky praxe) a zrovna o tomhle jsem s ním vedl nesčetné diskuze. Fajn kluk, ale zrovna přesně tohle s těma design patternama dělal a teď to vidím i v téhle práci, v kódu někoho kdo je už roky pryč a viděl jsem to několikrát i předtím v opensource knihovnách na githubu. Tak prostě na javisty si taky dávám pozor, když lezou do py.

Obdobná situace panovala před lety u PHP. Tam je to trochu jiné tím, že PHP samo o sobě je totální zprasenina (tys ten „parser“ ostatně taky viděl, takže ti to nemusím vysvětlovat). Ale i tak lze v PHP napsat vcelku rozumný kód – jazyk jako takový tě rozhodně nenutí a snad ani nevybízí psát věci jako include "pages/".$_GET['page'].".php";. Byl to fakt, že PHP bylo – ve své době – velmi žádané a dostal jsi „za málo peněz hodně muziky“. Tím narážím na to, že ta vstupní bariéra asi nebyla o tolik nižší než v jiném high-level jazyce, ale rozhodně bylo snažší začít produkovat nějaké hmatatelné výsledky – v tomto případě weby.

Výsledkem bylo, že PHPčkaři byli považování za bastlíře a jako programátoři byli vnímání jako méněcenní. A do jisté míry to byla pravda – protože většina jich taková opravdu byla. Ale vina PHP je to jen velmi malá, pokud nějaká; PHP je příšerná technologie, ale i kdyby příšerná nebyla, ti stejní lidé by v ní stejně produkovali neskutečný hovnokód.

Jo, souhlas. Zrovna dneska jsem reportoval bug v interním sw, kde někdo použil == místo === a software přestal fungovat :D Proč teda není == deprecated fakt nechápu.

[smazáno]

cpt. obvious

[xkucf03]

Když se zamýšlím, kde se to tak asi v těch lidech bere, tak nelze dospět k ničemu jinému, než že tenhle styl programování prostě deformuje způsob jakým člověk přemýšlí o problémech a z nástroje, který může být na konkrétním místě v konkrétním jazyce užitečný se stává dogma

Tohle rozhodně nemusí být tím, že člověk v jednom jazyce píše jiný jazyk. Stejný typ neshod se objevuje i mezi lidmi, kteří píší ve stejném jazyce, akorát mají odlišné priority. Jeden může psát stylem „chci to mít co nejdřív hotové, napsat co nejméně kódu“ a druhý „napíšu to trochu líp/složitěji, než je teď nezbytně nutné a v budoucnu si tím ušetřím více práce“. Oba přístupy lze přehnat a nadělat jimi dost škody a stejně tak oba můžou být legitimní postoj odpovídající dané situaci¹.

Jde o to mít dostatek informací² a najít nějakou rozumnou míru.

Nevím, jestli existuje nějaká inženýrská/exaktní metoda/postup, jak tohle rozhodnout, spíš mi přijde, že je to dost o zkušenosti a citu. Např. když ze zkušenosti víš, že na většině projektů dříve či později přijde požadavek na podporu více jazykových mutací, tak tam tuhle podporu dáš už od začátku, přestože ji nikdo explicitně nepožadoval. Já se řídím dost i podle toho, jak moc je daný kód vidět navenek – pokud je zapouzdřený, tak klidně³ zvolím jednodušší/omezenější řešení, protože vím, že si to můžu v případě potřeby kdykoli refaktorovat a vylepšit, aniž by to mělo negativní dopady na ostatní. Naopak pokud má ten kód povahou blíž k veřejnému API a budou na něm záviset ostatní lidé a ostatní kód, tak volím spíš obecnější řešení, které bere víc v úvahu potenciální požadavky.

Tohle všechno by šlo vyjádřit jednoduchou rovnicí, ale výsledku se jen tak nedopočítáme, protože je tam příliš mnoho proměnných, jejichž hodnoty neznáme. Příklady: Jaká je pravděpodobnost, že v budoucnu přijde daný požadavek? (nebudeme to dělat zbytečně?) O kolik je to lepší řešení pracnější? (často to nejde spolehlivě odhadnout, dokud se nepustíme do implementace) Jaké budou dopady na výkon, čitelnost nebo budoucí údržbu? Vyplatí se to vzhledem k daným pravděpodobnostem psát dvakrát (nejdřív jednoduše a pak to předělat) nebo raději napoprvé pořádně?

Teoreticky by nám v tom pomohla statistika a při dostatečném počtu opakování by se dostavily výsledky. Ale tyhle věci se těžko měří a většinou si takovou evidenci nikdo nevede (vést si statistiku by byly zase další náklady⁴), takže je to zase o té zkušenosti a citu.

A ty zkušenosti se budou u různých lidí lišit. Když to vezmu do extrému, tak ten, kdo dělal převážně weby, které je potřeba rychle dodat a vyfakturovat a hurá na další projekt (a za rok, za dva už ten web pozbude smyslu a nahradí se novým) bude mít diametrálně odlišný pohled (zkušenost) než ten, kdo psal kritické aplikace pro velké firmy a běžně udržoval v provozu systémy obsahující kód starý i deset a více let. Zralý vývojář se pozná mj. podle toho, že mezi těmito pozicemi dokáže přepínat podle povahy aktuálního projektu.

_{[1] projekt, délka životního cyklu produktu, předvídatelnost budoucích požadavků…
[2] Co to vlastně děláme? Co budeme dělat za týden, měsíc, rok?
[3] záleží na pracnosti – pokud to „lepší“ řešení zvládnu napsat v +/- stejném čase a i v ostatních ohledech (srozumitelnost, údržba, výkon…) je to srovnatelné, tak není důvod to dělat horší (byť stále vyhovující zadání)
[4] A vyplatí se je vynaložit? Jak to vypočítáme?}

[ehm]

Řeč byla asi spíš o situacích, kdy je nějaký design pattern použitý úplně nevhodně/zbytečně a nejde to brát ani jako přípravu na budoucí rozšiřování.

Osobně se od určité doby snažím řídit spíš tím, že nepíšu kód, který není potřeba. Budoucí rozšiřitelnost mám na paměti a snažím se dělat rozhodnutí, která té rozšiřitelnosti nebudou bránit, ale nezačnu už ten kód rovnou připravovat. Z části je to dané tím, že spravuji zcela neveřejnou codebase, tj. kompatibilitu na úrovni zdrojových kódů nemusím nikde zachovávat.

Jinak +1.

[Bystroushaak]

Osobně se od určité doby snažím řídit spíš tím, že nepíšu kód, který není potřeba. Budoucí rozšiřitelnost mám na paměti a snažím se dělat rozhodnutí, která té rozšiřitelnosti nebudou bránit, ale nezačnu už ten kód rovnou připravovat. Z části je to dané tím, že spravuji zcela neveřejnou codebase, tj. kompatibilitu na úrovni zdrojových kódů nemusím nikde zachovávat.

Tohle byla jedna z těch věcí, které do mě vtloukly až různé programátorské knížky (Programátor pragmatik třeba). Ten pocit, že se projekt bude rozšiřovat je většinou fakt neodbytný, reálně se to ale tak jak jsi předpokládal děje fakt málo a i tehdy většinou není problém udělat refactoring. Neříkám je to úplně špatná praktika, ale kdybych měl udělat nějakou statistiku, kdy jsem si myslel, že se kód bude rozšiřovat a kdy se fakt rozšiřoval, tak by to bylo asi tak 8:2. V ostatních případech to byla zbytečně vynaložená práce. Ono vůbec, plánování architektury a narážení na reálné požadavky, to je kapitola sama pro sebe.

[xkucf03]

Myslím, že nejsme ve sporu. Píšu tam, že je to o porovnání pracnosti (jednoduché řešení + předělávka vs. rovnou složitější řešení), dopadů na výkon a čitelnost, o pravděpodobnostech změn a budoucích požadavků… Nakonec je to zase jen o té zkušenosti. Neznamená to volit vždy jeden nebo druhý extrém.

Potkal jsem třeba programátory, kteří byli schopní do kódu zadrátovat na spoustě míst podporu jen češtiny (a všechno ostatní vyhazovalo chybu), protože si v analýze přečetli, že podporována je jen čeština (což tam ovšem bylo primárně jako ochrana pro nás, aby druhá strana neprudila, kdyby nám někde chyběly překlady). Podporovat více jazyků by dokonce bylo jednodušší než je nepodporovat (dělat ty kontroly a vyhazovat výjimky). Takže rozhodně neplatí, že vyvinout jen to nutné minimum, co je v zadání, je méně pracné, než udělat něco navíc, udělat produkt lepší a více připravený na budoucí požadavky.

Chce to prostě znát rozumnou míru. Kdybych měl nad lepším řešením strávit dvakrát tolik času, zatížit kód stovkami dalších řádků, tak se na to taky vykašlu. Ale často jsou ty dvě varianty +/- nastejno, podobně pracné, podobně dlouhé, stačí se nad tím jen trošku zamyslet nebo vyjít ze zkušeností. Pak není důvod nezvolit lepší řešení (převyšující aktuální požadavky).

Chápu, že i ten minimalistický přístup má svoje opodstatnění a logiku. Ale, co mi vadí, je, že to někteří lidé berou jako omluvu, proč píší mizerný kód. Řeknou, že to (explicitní) požadavky splňuje a líp to dělat prostě nebudou, protože MVP. To ale není minimalismus, nýbrž lamerský přístup. K minimalismu je potřeba se propracovat přes ty znalosti a zkušenosti, ne jím omlouvat to, že člověk není ničeho lepšího schopný.

Je to podobné jako u (de)normalizace v datovém modelování. Denormalizovaný model by člověk měl navrhnout po zralé úvaze a zvážení všech pro a proti – nikoli v důsledku toho, že není schopen navrhnout normalizovaný model nebo ani neví, co to je.

Když budu v C/C++ psát primitivní kód, tak to taky nebudu nazývat minimalismem, ale přiznám si, že nic lepšího teď prostě neumím.

[ehm]

+1

[Bystroushaak]

Ok, s tím asi souhlasím.

[pavlix]

nikoli v důsledku toho, že není schopen navrhnout normalizovaný model nebo ani neví, co to je.

Tohle bych chtěl jednou pochopit. Mě neučili normalizaci návrhu databáze nebo přesněji řečeno mě ho učili v době, kdy už jsem několik let běžně databáze navrhoval. Tehdy jsem ani nechápal k čemu to je, všechny moje návrhy byly plně normalizované. Viděl jsem nějaký minitutoriál na databáze nebo něčí kód, to už si nepamatuju, a v tom příkladu se vázalo přes primary key a dělal se nad tím select a join, tak jsem to přirozeně dělal stejně a se vším. Dodnes nechápu, co lidi vede to bezdůvodně dělat jinak.

[xkucf03]

Mně to taky přišlo přirozené a v předmětu datové modelování jsem si z velké míry potvrdil to, co jsem si myslel dřív, a urovnal jsem si myšlenky a dal tomu nějaký systém. Ale řekl bych, že bude spousta lidí, kteří mají deformované myšlení nástroji typu MS Excel nebo papírovými formuláři a tabulkami – a ty je potřeba to přeučit od základů.

A i u lidí jako já nebo ty, kteří měli už před absolvováním kurzu kompatibilní pohled na věc, ta teorie neuškodí, protože některé body tam jsou nad rámec toho, co si přečteš v nějakém tutoriálu nebo s čím se běžně setkáš (a až to jednou přijde, tak je dobré na to být připraven).

[Bystroushaak]

A ty zkušenosti se budou u různých lidí lišit. Když to vezmu do extrému, tak ten, kdo dělal převážně weby, které je potřeba rychle dodat a vyfakturovat a hurá na další projekt (a za rok, za dva už ten web pozbude smyslu a nahradí se novým) bude mít diametrálně odlišný pohled (zkušenost) než ten, kdo psal kritické aplikace pro velké firmy a běžně udržoval v provozu systémy obsahující kód starý i deset a více let. Zralý vývojář se pozná mj. podle toho, že mezi těmito pozicemi dokáže přepínat podle povahy aktuálního projektu.

Jen čistě pro pořádek - weby nedělám, dělám backendy v pythonu čítající vyšší desítky tisíc řádek, které se udržují relativně dlouho (současný projekt oslavil 10 let před dvěma měsíci). Přesto si 99% času vystačím bez patternů tak, jak se chápou v javě (spoléhání na dědičnost a vytváření hierarchií tříd). Neříkám, že patterny nepoužívám vůbec, to asi nejde, ale spíš ne tak očividně a nekladu na ně důraz.

[smazáno]

Samozrejme.

Vzdyt ten mytus ze se software musi psat nesrozumitelne a pak najednou az z nej bude ten velky projekt tak diky te nesrozumitelnosti bude srozumitelny je ... typicka java.

[xkucf03]

To nebylo o tobě, neber si to osobně.

[ehm]

No tos tomu moc nepomohl, vzhledem k tomu, že neschopnost předávat funkce je čistě technická limitace Javy...

Chci, aby ten objekt mohl mít svůj vnitřní stav. Pokud to jinde dokážeš udělat s funkcí, prosím.

Co mi uniká je proč tyhle pojmy existují / k čemu jsou dobré.

To je tvůj problém.

[deda.jabko]

Když budeš mít (hypoteticky) lambda funkci, která bude capturovat nějaká data a vracet instance nějakých objektů, bude to továrna, nebo tovární funkce?

Toto je hnipani v nepodstatnych detailech, protoze v pripade Javy ta lambda funkce je objekt implementujici funkcionalni rozhrani, tvarici se jako funkce. Rikej si tomu, jak chces, neni to dulezite.

Jaký je rozdíl mezi konstruktorem a statickou funkcí vracející novou instanci?

Uz jsem to tu psal driv. Konstruktor se stara o explicitni alokaci objektu. V managed jazyku nemas jinou moznost, jak alokovat novy objekt nez pomoci konstruktoru! Statickou funkci (uplne) novou instanci nevratis.

[kralyk z abclinuxu]

Uz jsem to tu psal driv. Konstruktor se stara o explicitni alokaci objektu. V managed jazyku nemas jinou moznost, jak alokovat novy objekt nez pomoci konstruktoru!

Konstruktor v Javě rozhodně nic nealokuje. Konstruktor inicializuje objekt. Tovární funkce inicializuje objekt.

[deda.jabko]

OK, chces-li volani konstruktoru alokuje a inicializuje objekt. Volani funkce nemuze alokovat novy objekt!

Tovární funkce inicializuje objekt.

Na to prisels jak?

Tovarni funkce muze slouzit k vytvoreni objektu. (alternativne muze treba vybirat objekt z nejakeho poolu)

Analogicky. K cemu slouzi tovarny? K tvorbe novych objektu, ne? Nebo snad chodis do tovarny, aby ti tam tvuj objekt nastavili?

[kralyk z abclinuxu]

OK, chces-li volani konstruktoru alokuje a inicializuje objekt.

Uniká mi, jak konstruktor alokuje nový objekt. Konstruktor operuje na již alokovaném objektu, dokonce v případě Javy i na již rudimentárně inicializovaném objektu.

Tovarni funkce muze slouzit k vytvoreni objektu. (alternativne muze treba vybirat objekt z nejakeho poolu)

Jestli ta funkce objekt vytvoří nový nebo ho vytáhne z poolu mi přijde jako technikalita. Ale beru, že je rozdíl oproti konstruktoru, že má tu možnost, zatímco konstruktor dostává objekt k inicializaci befelem od alokátoru.

[deda.jabko]

Tak jeste jednou, aby tomu rozumeli i uzivatele C++.

Uniká mi, jak konstruktor alokuje nový objekt.

V Jave (jazyce) nemuzes oddelit alokaci objektu od volani konstruktoru. Takze kdykoliv pouzijes new, alokuje se novy objekt a vola konstruktor (byt by byl implicitni). Staci? Jinou moznost, jak alokovat objekt nemas. Na druhou stranu, jindy konstruktor volat nemuzes. Proto jsem myslel, ze je zjevne, ze pokud volam konstruktor, vznika vzdy novy objekt, jindy ne. Tak nevim, co porad resis s nejakou funkci.

Jestli ta funkce objekt vytvoří nový nebo ho vytáhne z poolu mi přijde jako technikalita.

To neni technikalie, to je hodne vyznamny rozdil.

zatímco konstruktor dostává objekt k inicializaci befelem od alokátoru.

Hele, chces-li se hnipat v technickych detailech, tak konstruktor od alokatoru nic befelem nedostava. Nejdriv se zavola instrukce new pro alokaci objektu a pote invokevirtual pro dany konstruktor.

[kralyk z abclinuxu]

V Jave (jazyce) nemuzes ...

I see what you did there O Unsafe API se IIRC spekuluje, že by se možná mohlo standardizovat. Nevím, v jakém stavu to teď je. On je to tak trochu de-facto standard.

Hele, chces-li se hnipat v technickych detailech, tak konstruktor od alokatoru nic befelem nedostava.

Měl jsem na mysli parametr this.

Nejdriv se zavola instrukce new pro alokaci objektu a pote invokevirtual pro dany konstruktor.

invoke* instrukce jsou na volání funkcí. Ale mně ani tak nešlo o tu low-level technickou podstatu jako spíš o použití. Např.:

Foo foo = new Foo();              // "Běžný" konstruktor
Bar bar = Bar.getInstance();      // Globální Singleton
Baz baz = Baz.getInstance();      // TLS Singleton 
Connection connection = Connection.getConnection();    // Pooling

Všechny čtyři příklady výše vidím jako v zásadě stejnou věc, stejný "pattern", chceš-li. Samozřejmě v detailech se každá liší, což může být podstatné pro danou situaci, ale to se mohou navzájem lišit i samotné běžné konstruktory nebo "továrny" mezi sebou.

To, jestli ten nový objekt se alokuje někde v magii operátoru new nebo někde v útrobách té které funkce, mi nepřijde jako koncepčně podstatné, prostě stále to, co mě zajímá, je, že všechny čytři jsou "ta věc, kterou zavoláš, když potřebuješ instanci té třídy". Je mi srdečně jedno, bude-li se tomu říkat "továrna" nebo nějak jinak, jde mi o to, co ta věc dělá - tj. odněkud to shcrastí objekt a nějak ho pro mě připraví, takže ho následně můžu používat.

[deda.jabko]

Unsafe API

je pro tuto diskuzi bezpredmetne.

To, jestli ten nový objekt se alokuje někde v magii operátoru new nebo někde v útrobách té které funkce, mi nepřijde jako koncepčně podstatné, prostě stále to, co mě zajímá, je, že všechny čytři jsou "ta věc, kterou zavoláš, když potřebuješ instanci té třídy".

Tak potreti a naposledy. To, ze pouzijes operator new znamena, ze se ti vzdy alokuje novy objekt a zavola prislusny konstruktor. Pokud budes chtit zmenit zpusob vytvareni novych objektu (treba pouzit poolovani), pridat parametr, mas proste smulu, musis kazde misto, kde jsi pouzil new+konstruktor rucne upravit.

Pokud pouzijes nejakou tovarnu, staci ti provest zmenu na jednom miste (v te tovarne) a mas vystarane. Co je na tom k nepochopeni?

Viz ten priklad s new Integer, nekde v teto diskuzi.

[kralyk z abclinuxu]

Unsafe API

je pro tuto diskuzi bezpredmetne.

Děkuji arbitrovi, že vytyčil vhodné mantinely, aby se do diskuse nedostaly podvratné živly...

Tak potreti a naposledy. To, ze pouzijes operator new znamena, ze se ti vzdy alokuje novy objekt a zavola prislusny konstruktor. Pokud budes chtit zmenit zpusob vytvareni novych objektu (treba pouzit poolovani), pridat parametr, mas proste smulu, musis kazde misto, kde jsi pouzil new+konstruktor rucne upravit.

Pokud pouzijes nejakou tovarnu, staci ti provest zmenu na jednom miste (v te tovarne) a mas vystarane. Co je na tom k nepochopeni?

Když budeš chtít přidat parametr předávaný zvenku, tj. do signatury té "továrny", taky to musíš změnit všade. Ale jinak ano, ta tovární funkce má - konkrétně v Javě - větší flexibilitu. Mj. také z tohohle důvodu nemají jazyky jako Go a Rust konstruktory v tom tradičním smyslu vůbec a používá se jen to, čemu by se v Javě řeklo tovární funkce. Ono koneckonců to samé by šlo udělat i v Javě. O funkcionálních jazycích jako Haskell nemluvě, tam to je takhle odpradávna. V C++ sice tradiční konstruktory jsou, ale každý ví, že to je funkce jako každá jiná, pro nějakou případnou flexibilitu se dá se přetěžovat new, případně používat placement new, případně též statickou member funkci a kdoví jaké ještě další více či méně šílené postupy.

Viz ten priklad s new Integer, nekde v teto diskuzi.

No a co s ním? Že ty dva způsoby vytvoření dělají trochu něco jiného (jedna obsahuje optimalizaci) jsem zaznamenal. Nepřijde mi to pro diskusi nějak zajímavé.

Myslím, že se míjíme, nechal bych toho...

[deda.jabko]

Že ty dva způsoby vytvoření dělají trochu něco jiného (jedna obsahuje optimalizaci) jsem zaznamenal.

Tak jeste jednou a poooooomaaaaaaluuuuuuu.

Kdyz budes v kodu pouzivat factory method, muzes v budoucnu ovlivnit, jak ten objekt vznikne. Nejdriv to naprogramujes implicitne treba tak, ze getInstance() vola return new(...). A pokud zjistis, ze bys potreboval optimalizaci nebo brat objekty z poolu nebo kdo vi kama, jenom zmenis tu metodu getInstance(). Prinos pro jeden konkretni kod je nulovy, prinos pro rozsiritelnost a odolnost na zmeny vyrazny! To je jeden z duvodu, proc se to pouziva.

do signatury té "továrny", taky to musíš změnit všade.

Pokud mas tovarnu v pravem slova smyslu, staci ti zmenit jenom misto, kde tovarnu vytvaris.

FooFactory fooFactory = new FooFactory();
// ...
Foo foo = fooFactory.newInstance();

// muzes jednoduse zmenit

FooFactory fooFactory = new FooFactory(a, b, c);
// ...
Foo foo = fooFactory.newInstance();

Pokud mas jen tovarni metodu, moc si v tomto pripade nepomuzes, ale porad to pomuze s predchozim pripadem.

Nepřijde mi to pro diskusi nějak zajímavé.

To je skoda. Je to naprosto bezny postup, ktery se pouziva i v jinych jazycich. Jen se tomu nerika tovarna.

[kralyk z abclinuxu]

Kdyz budes v kodu pouzivat factory method, muzes v budoucnu ovlivnit, jak ten objekt vznikne. Nejdriv to naprogramujes implicitne treba tak, ze getInstance() vola return new(...). A pokud zjistis, ze bys potreboval optimalizaci nebo brat objekty z poolu nebo kdo vi kama, jenom zmenis tu metodu getInstance(). Prinos pro jeden konkretni kod je nulovy, prinos pro rozsiritelnost a odolnost na zmeny vyrazny! To je jeden z duvodu, proc se to pouziva.

Vím o tom, spíš mi nebylo jasné, co s touto informací mám jako udělat nebo čím je zajímavá. Chceš veškeré tradiční konstruktory teď převést na statické member funkce? Popravdě, divím se, že javisti už tohle dávno neudělali vzhledem k té obsesi se skrýváním implementace a rozšiřitelností dobudoucna úplně všeho včetně babiččiných papučí.

Pokud mas tovarnu v pravem slova smyslu, staci ti zmenit jenom misto, kde tovarnu vytvaris.

Ano, anebo můžeš udělat asi tak milion různných dalších věcí, pokud potřebuješ, aby se vytváření nějakého objektu nedotklo zbytku kódu...

To je skoda. Je to naprosto bezny postup, ktery se pouziva i v jinych jazycich. Jen se tomu nerika tovarna.

Ano, místo toho se tomu říká například konstruktor (v případě té funkce), že, mimo jiné...

[ehm]

Ty jsi prostě debil...

[deda.jabko]

Chceš veškeré tradiční konstruktory teď převést na statické member funkce?

Potreboval bych si to ujasnit. Ma to byt vic strawman nebo slipery slope?

Ano, anebo můžeš udělat asi tak milion různných dalších věcí, pokud potřebuješ, aby se vytváření nějakého objektu nedotklo zbytku kódu...

No, a proste toto je bezny (osvedceny, do jiste miry idiomaticky) postup v Jave, treba stejne jako v LISPu mas let-over-lambda. Se stim smir!

[kralyk z abclinuxu]

Potreboval bych si to ujasnit. Ma to byt vic strawman nebo slipery slope?

Ani jedno. Vyznělo to ironičtěji, než jsem to myslel. Spíše to má být myšlenkový experiment, tj. co by se stalo, kdyby opravdu člověk naspal třídu bez konstruktorů (resp. jen s tím výchozím, označeným třeba private) a místo konstruktorů poskytl statické metody. Pochopitelně neočekávám, že by skutečně někdo něco takového udělal v praxi. Chovám bláhovou naději, že by třeba tento myšlenkový experiment mohl v myslích javistů ilustrovat, proč mi nepřijde to rozlišení mezi konstruktorem a factory metodou tak ostré / významné...

No, a proste toto je bezny (osvedceny, do jiste miry idiomaticky) postup v Jave, treba stejne jako v LISPu mas let-over-lambda. Se stim smir!

Kdyby se mi to býval někdo ve škole pokoušel vtloukat do hlavy podobně agresivně a nesmyslně jako design patterny, asi bych k tomu měl podobný odpor (zkušenosti s design patterny mám velmi podobné tomu, jak to popisuje Bystroušák).

[Bystroushaak]

Ani jedno. Vyznělo to ironičtěji, než jsem to myslel. Spíše to má být myšlenkový experiment, tj. co by se stalo, kdyby opravdu člověk naspal třídu bez konstruktorů (resp. jen s tím výchozím, označeným třeba private) a místo konstruktorů poskytl statické metody. Pochopitelně neočekávám, že by skutečně někdo něco takového udělal v praxi. Chovám bláhovou naději, že by třeba tento myšlenkový experiment mohl v myslích javistů ilustrovat, proč mi nepřijde to rozlišení mezi konstruktorem a factory metodou tak ostré / významné...

Tohle jsem udělal a nejednou. Typicky pro classy, které se loadují z nějaké serializace a slouží jen jako struktury.

[xkucf03]

Typicky pro classy, které se loadují z nějaké serializace a slouží jen jako struktury.

A jak je ten deserializátor instanciuje, když nemůže zavolat konstruktor? Resp. v čem je lepší, když deseralizátor volá statickou metodu místo konstruktoru?

[ehm]

Nevím, jak v Pythonu (kde to asi použil Bystroushaak), ale třeba v Javě to může být něco jako:

class DataBean {
    // fieldy

    private DataBean(/* muze a nemusi mit argumenty */) {
        //
    }

    public static DataBean loadFrom(InputStream stream) {
        // deserializace
    }
}

V tomto případě je rozdíl mezi konstruktorem a metodou minimální. Přijde mi jako dobrá praxe v konstruktoru nechávat jednodušší logiku (nastavení fieldů apod.) a případnou dodatečnou logiku (deserializaci) přesunout do té metody.

[xkucf03]

Toho jsem se právě obával… (viz komentář níže).

[Bystroushaak]

A jak je ten deserializátor instanciuje, když nemůže zavolat konstruktor? Resp. v čem je lepší, když deseralizátor volá statickou metodu místo konstruktoru?

Osobně jsem to použil v případech, kdy vracím zpět třeba pole těch struktur, nebo právě v případě, jak píše indy dole, kdy se mi nechtělo zaplevelit konstruktor (python nemá přetěžování metod, pokud teda vynechám multiple dispatch dekorátor) logikou na načítání a parsování dat ze stringu.

[xkucf03]

logikou na načítání a parsování dat ze stringu

To je právě otázka, jestli by tenhle kód měl být v té samé třídě, kterou tím načítáš, a která má nějakou vlastní logiku. Já si myslím, že většinou neměl. Jedna věc je rozhraní poskytované směrem ven, druhá věc je logika uvnitř, a třetí věc je serializace a deserializace vnitřního stavu.

Když to sloučíš do jednoho, tak na jednu stranu něco málo ušetříš, na druhou stranu si ale omezíš možnosti – mít víc implementací se stejným rozhraním nebo načítat stav z různých zdrojů. A taky bude kód složitější na pochopení, méně přehledný, protože na jednom místě řešíš nesouvisející věci (když upravuji vnitřní logiku, tak nestojím o to, aby mi v té samé třídě strašil kód na serializaci a deserializaci, který mne v tu cvhíli vůbec nezajímá).

Někdy to dává smysl sloučit do jednoho, ale dělal bych to jen v případech, které jsou neveřejné a můžu si je kdykoli přepsat, aniž by to mělo dopad na někoho dalšího. Navíc to předpokládá jazyk a nástroje, které podporují refaktoring a typovou kontrolu, aby provedení změny nebylo příliš pracné.

[ehm]

Tyhle metody jsou často jen shorthand. Skutečná logika je jinde, ale tenhle zápis je srozumitelnější. A pak to taky dává smysl v případě, že ta serializace/deserializace není plně automatizovaná (přes reflexi), ale deláš to částečně ručně. Neviděl bych moc velký význam v oddělení téhle logiky do samostatné třídy.

[JS1]

jestli by tenhle kód měl být v té samé třídě

Rekl bych, ze resis typicky Javovsky pseudoproblem.

[ehm]

Žádný programátor v žádném jiném jazyce nikdy neřešil, jak zdrojáky organizovat do souborů. Poor lady Java.

[JS1]

Poor lady Java si v tomhle nabehla, protoze si vymyslela naprosto nesmyslna a zbytecna omezeni. Napriklad to, ze nejde pridat metodu nebo rozhrani do existujici tridy.

[ehm]

Jakto, že nejde? Prostě si otevřeš ten zdroják a do té třídy přidáš metodu, jakou potřebuješ. Nebo ti nerozumím?

[JS1]

Nerozumis. To tvoje reseni je mozne jen nekdy, treba pokud to zrovna neni uzavrena knihovna od treti strany. A takove byvaji shodou okolnosti zrovna ty, kde to chces delat nejcasteji (protoze to co pises sam si navrhnes jak potrebujes).

[ehm]

Jak se to liší od případu, kdy tu knihovnu patchneš a rekompiluješ? Funguje to v době, kdy píšeš kód, naprosto spolehlivě. Jazyk to 100% podporuje.

[JS1]

Jazyk mozna ano (Javu je pomerne snadne dekompilovat), ale vyrobce te knihovny casto ne.

Ale predevsim - kolikrat chces pridat neco, co do te puvodni tridy ani nemusi logicky patrit. Napriklad moznost pustit nad ni nejaky algoritmus.

[ehm]

Proč bys do té třídy přidával něco, co tam logicky nepatří, a ještě na to vyžadoval podporu jazyka?

[JS1]

Protoze jde o neco, co chci provadet nad tim typem - a trida je predevsim typ.

[ehm]

Ale proč bys tam přidával něco, co tam logicky nepatří?

[kralyk z abclinuxu]

Hádám, že tím "tam nepatří" měl JS1 na mysli, že to nepatří do zdrojáků té 3rd party knihovny, ale v rámci tvého programu to tam patřit může.

Zkusim praktický příklad (sorry, bude to v Rustu): Dejme tomu, že nějaká knihovna poskytuje typ A a já si ho importuju, dále si nadefinuju typ B a následně budu chtít konvertovat intance A na instance B. Jak to udělám? Pro typ A naimplementuju Into<B> , takže pak můžu na jakékoli instanci A zavolat .into() a získám z něj insatnci B.

BTW zároveň s tím mi v B automaticky přibude konstruktor from(A), což je asi přesně způsob, jak by se tohle nejspíše řešilo v klasickém OOP. Nicméně ten způsob s Into má větší flexibilitu, např. v případě, že máš pak někde nějakou funkci, která je generická a akceptuje cokoli, co má implementováno Into<B>, tak se pak vůbec nemusíš starat o konverzi jednoho objektu na jinej, ale prostě tam pošleš instanci A (nebo cokoli jiného, co také implementuje Into<B>), aniž bys musel explicitně volat nějaký konkrétní konstruktor.

(Doufám, že tenhle příklad není úplně na hlavu, vymýšlím to v rychlosti a už trochu spim...)

[ehm]

Tak tu logiku prostě oddělíš do samostatné třídy. Třeba:

import java.io.Serializable;
import java.util.Objects;

public class Test {
    public static void main(String[] args) {
        A2BConversionFactory a2BConversionFactory = A2BConversionFactory.getInstance();
        Conversion<A, B> a2bConversion = a2BConversionFactory.newInstance();

        A a = new A(5);
        B b = a2bConversion.getResult(a);

        System.out.println(b);
    }
}

class A implements Serializable, Cloneable {
    private static final int serialVersionUID = 1;

    private int value;

    public A(int value) {
        this.value = value;
    }

    public void setValue(int value) {
        this.value = value;
    }

    public int getValue() {
        return value;
    }

    @Override
    public String toString() {
        return String.valueOf(value);
    }

    @Override
    public int hashCode() {
        return Objects.hashCode(value);
    }

    @Override
    public boolean equals(Object obj) {
        if (obj instanceof A) {
            A o = (A) obj;
            return value == o.value;
        } else {
            return false;
        }
    }

    @Override
    public Object clone() throws CloneNotSupportedException {
        return super.clone();
    }
}

class B implements Serializable, Cloneable {
    private static final int serialVersionUID = 1;

    private String value;

    public B(String value) {
        this.value = value;
    }

    public void setValue(String value) {
        this.value = value;
    }

    public String getValue() {
        return value;
    }

    @Override
    public String toString() {
        return value;
    }

    @Override
    public int hashCode() {
        return Objects.hashCode(value);
    }

    @Override
    public boolean equals(Object obj) {
        if (obj instanceof B) {
            B o = (B) obj;
            return value == o.value;
        } else {
            return false;
        }
    }

    @Override
    public Object clone() throws CloneNotSupportedException {
        return super.clone();
    }
}

interface Conversion<T, U> {
    U getResult(T obj);
}

interface AbstractSingleParameterFactory<T, P> {
    T newInstance(P p);
}

class BFactory implements AbstractSingleParameterFactory<B, String> {
    @Override
    public B newInstance(String str) {
        return new B(str);
    }
}

class A2BConversion implements Conversion<A, B> {
    private AbstractSingleParameterFactory<B, String> bFactory;

    public A2BConversion(AbstractSingleParameterFactory<B, String> bFactory) {
        this.bFactory = bFactory;
    }

    @Override
    public B getResult(A obj) {
        return bFactory.newInstance(String.valueOf(obj.getValue()));
    }
}

class A2BConversionFactory {
    private static ThreadLocal<A2BConversionFactory> instance = new ThreadLocal<>();

    private BFactory bFactory;

    public A2BConversionFactory() {
        this.bFactory = new BFactory();
    }

    Conversion<A, B> newInstance() {
        return new A2BConversion(bFactory);
    }

    public static A2BConversionFactory getInstance() {
        if (instance.get() == null) {
            instance.set(new A2BConversionFactory());
        }

        return instance.get();
    }
}

Přehledné, elegantní a do budoucna snadno rozšiřitelné řešení.

[JS1]

Ugh, to je jeste porad trolling, nebo uz je to vazna odpoved?

Jak uz jsem psal v druhem odstavci.

V Haskellu proste napisu funkci nad nejakym typem, a jsem doma.

[kralyk z abclinuxu]

Tak tu logiku prostě oddělíš do samostatné třídy. Třeba:

Tak jako trolling dobrý no.

Nicméně doporučuju věnovat pozornost řádce 90. Buď nejsi až takový Java guru, jak tady píšeš, nebo to je jenom prosté přehlédnutí způsobené copy&paste (hádám, že to spíš), ale i tak z toho plyne to ponaučení, že rozhodnutí Javy chovat se k primitivním typům jinak a/nebo nepodporovat přetěžování operátorů není zrovna šťastné, vzhledem k tomu, že se tohle stává i zkušenějším. Případně také že není špatné věci psát genericky / snažit se o DRY.

[ehm]

+rep. Zkoušel jsem, jestli si toho někdo všimne. :) Ještě je tam něco.

[ehm]

BTW:

rozhodnutí Javy chovat se k primitivním typům jinak a/nebo nepodporovat přetěžování operátorů není zrovna šťastné

Primitivní typy – a vše, co s nimi souvisí – v Javě celkově nejsou zrovna šťastné. Je to jedna z nejhnusnějších věcí na tom jazyce. C# to má AFAIK vyřešené líp.

[JS1]

C# ma spousta veci vyresenych lip - je to IMHO hlavne diky tomu, ze MS research ma hodne lidi, co se jazyky fakt zabyvaji. Treba Simon Peyton Jones (jeden z autoru Haskellu) dlouha leta pracuje u MS.

[ehm]

Tak především to udělaly tak, jak se to má dělat – převzaly z Javy to dobré a vyřešily (nebo se pokusily vyřešit) existující problémy.

Ale teď je otázka, jak to bude s podporou na jiných platformách, IDE a celkovým ekosystémem. Je škoda, že se to nedá rozběhat nad JVM – pak by to v podstatě byla otázka jen pluginu do IDE.

Z kosmetických věcí mi dost vadí CamelCase konvence pojmenovávání metod, ale co už. Když jsem v C# před časem krátce dělal, tak mi to v některých ohledech (tohle byl jeden z nich) přišlo, že se Microsoft nutně potřeboval co nejvíc odlišit od Javy, aby je neobvinily z plagiátorství, ale zároveň tam chtěly zachovat ty dobré vlastnosti, takže občas pozměnily někde něco jiného. Ale taky je možné, že neznám přesně ten historický vývoj a může to být prostě tím, že některé věci vznikaly nezávisle na sobě.

[JS1]

Z kosmetických věcí mi dost vadí CamelCase konvence pojmenovávání metod, ale co už.

Zajimave, podle me je to jen otazka zvyku. Me se naopak MS CamelCase libi - v tom Javovskem pripade trochu mi vadi, ze kdyz mam coolFrobulator, a chci z nej udelat advancedCoolFrobulator, tak musim tomu C zmenit case. A nejhorsi je to ve slovech, ktere zacinaji zkratkami.

[ehm]

Tak jasně, že je to otázka zvyku. Krátce jsem v C# pracoval a docela jsem si zvykl.

S těmi zkratkami souhlasím – když můžu, snažím se zkratkám na začátku názvu metody vyhnout. Změnit velikost písmena při přejmenování mi nevadí, to už je drobnost. Naopak se mi líbí, že pohledem snadno rozlišíš typ od metody. Pak se mi taky moc nelíbí něco jako obj.DoSomething(); (protože u proměnných se používají ty malá písmena na začátku, pokud si správně vzpomínám).

Ale tak to už jsou takové kraviny, že se na tom nedá ani rozumně zatrollit.

[xkucf03]

Někdy se to může hodit, ale nepřijde mi to až tak zásadní. Nebo v čem je o tolik lepší napsat b = a.into(); místo b = toB(a); ? A to toB() si staticky naimportovat?

máš pak někde nějakou funkci, která je generická a akceptuje cokoli, co má implementováno Into<B>, tak se pak vůbec nemusíš starat o konverzi jednoho objektu na jinej, ale prostě tam pošleš instanci A (nebo cokoli jiného, co také implementuje Into<B>)

V jaké fázi se ty typy vyhodnocují? (Kdy se řeší, zda instance implementuje Into<B>?) Psal jsi, že se traity importují do konkrétního zdrojáku (a tím jde rozlišit, když bude víc stejného typu, viz #1301). Co když proměnná bude obecnějšího typu a instance bude konkrétnějšího (trait) a metody budou existovat pro oba typy – vybere se metoda na základě typu proměnné nebo instance?

[kralyk z abclinuxu]

Někdy se to může hodit, ale nepřijde mi to až tak zásadní. Nebo v čem je o tolik lepší napsat b = a.into(); místo b = toB(a); ?

V tom, že ti může být jedno, jakého typu je a , může to být tvůj typ, cizí typ, je to jedno. Naproti tomu to toB() bude nejspíše fungovat jen pro typ A. Můžeš si vytvořit interface, který poskytne toB(), ale ten bohužel nenaimplementuješ pro cizí typ a i pro své typy na to musíš myslet 'dopředu' a už s tím tu třídu tak vytvořit. Ten trait ti umožňuje přistupovat ke všem stejně, což se hodí třeba v generických funkcích a typech.

V jaké fázi se ty typy vyhodnocují? (Kdy se řeší, zda instance implementuje Into<B>?) Psal jsi, že se traity importují do konkrétního zdrojáku (a tím jde rozlišit, když bude víc stejného typu, viz #1301). Co když proměnná bude obecnějšího typu a instance bude konkrétnějšího (trait) a metody budou existovat pro oba typy – vybere se metoda na základě typu proměnné nebo instance?

Tady asi nerozumim otázce. Zaprvé s importem to asi nemá moc společného, protože Into je jedna z celkem fundamentálních traitů a je importovaná automaticky. Když budeš mít generickou funkci jako třeba fn foobar<T: Into<B>>(what: T) , tak to je static dispatch (compile time). Můžeš tomu předat cokoli a použije se vždy jen ta metoda z toho Into<B> celkem bez ohledu na to, kolik dalších traitů ten typ ještě má naimplementováno a jestli mají / nemají shodné metody. (Krom toho mezi Into<B> a Into<C> nenastane konflikt takjakotak, protože ty funkce mají jinou signaturu - jiná návratová hodnota).

Dynamic dispatch je možný taky, používá se na to mechanismus "Trait object" a je to podobné interfacům v Javě. Ta funkce by byla zapsaná například fn foobar(what: &Into<B>), tj. to je reference, případně se dá použít nějaký pointer (Box, Arc, ...) (hodnotou předat pochopitelně nemůžeš). To funguje celkem stejně jako když v Javě má funkce typ parametru interface.

Typicky je lepší použít static dispatch, dynamic dispatch jen když to nejde staticky z nějakého důvodu.

[xkucf03]

Tím myslíš standardními prostředky v době běhu? Pak by těžko fungovala typová kontrola, která je jedním ze základních principů Javy.

[JS1]

Ne v dobe behu, v dobe, kdy pisu kod.. Typova kontrola neni problem, treba Haskell to umi.

[xkucf03]

A bude mi to napovídat v IDE a podtrhávat chyby při psaní?

[ehm]

Je to píčovina, ale asi by to šlo udělat. V podstatě by se definice té třídy jen poskládala z víc zdrojů, jiný rozdíl by v tom nebyl. V případě dynamických modifikací by to samozřejmě nešlo.

Zajímavější by byla otázka, jak to vlastně spouštět. ClassLoader by nemohl načíst jen konkrétní *.class soubor, ale musel by i všechny dodatečné (re)definice, smíchat je dohromady a teprve ten výsledek načíst.

[xkucf03]

Teď jsem se neptal na Javu ale na Haskell.

[ehm]

WTF?

[JS1]

Jasne, to neni problem - ghc-mod.

[Bystroushaak]

V tomhle je vážně zajímavý Smalltalk. Teď nemluvím o tom, že používá image a neorganizuje třídy do souborů, ale spíš o tom, že způsob organizace metod je jaksi „obrácený od javy“ (ve skutečnosti je obrácená java a další jazyky včetně pythonu, ale všem už to přijde normální). Kdysi mi to přišlo hodně zvláštní, že je běžné a možné vkládat metody do již existujících tříd. Například přidáš do vlastního programu nějakou funkci, třeba deserializaci z jsonu a kam jí přidáš? Nikoliv do vlastní classy, ale do stringu.

Prvně jsem z toho byl docela zmatený, ale pak mi to začlo do velké míry dávat smysl a došlo mi, že je to jen rozdílná konvence.

[xkucf03]

Například přidáš do vlastního programu nějakou funkci, třeba deserializaci z jsonu a kam jí přidáš? Nikoliv do vlastní classy, ale do stringu.

Co když víc autorů (třeba nějakých knihoven) přidá do stejné třídy stejně pojmenovanou metodu?

[Bystroushaak]

Co když víc autorů (třeba nějakých knihoven) přidá do stejné třídy stejně pojmenovanou metodu?

Popravdě fakt nevím. Ono to možná vypadá, že dělám ve Smalltalku, ale já ho spíš externě studuju a posledních pár let se věnuji Selfu, který má sice některé podobné rysy, ale jinak funguje dost jinak.

[ehm]

S hrůzou v očích pochopí svůj hrozný omyl a přejdou na Javu.

[kralyk z abclinuxu]

Co když víc autorů (třeba nějakých knihoven) přidá do stejné třídy stejně pojmenovanou metodu?

Tohle funguje v Rustu, můžeš si nadefinovat trait a implementovat ji pro jakýkoli typ. Pokud si nadefinueješ dvě traity se sejnou funkcí a implementuješ obě pro jeden typ, musíš pak při použití do toho scope importovat buď jen jednu z nich, anebo, když potřebuješ importovat obě, musíš při volání použít plné jméno (UFCS) té member funkce (tj. to jméno obsahuje název té traity).

V praxi tyhle konflikty nastávají jen velmi zřídka.

[JS1]

Ano, stejne to dela i Haskell. Jako uz vickrat - nektere veci jsou proste v Jave navrzeny ad hoc a jak se pozdeji ukazalo, suboptimalne. To neni konec sveta, ma to kazdy jazyk (i Haskell), ale je dobre to vedet.

[pavlix]

Resp. v čem je lepší, když deseralizátor volá statickou metodu místo konstruktoru?

Ta metoda třídy je jenom jiný druh konstruktoru, nic víc. Teda já bych tomu neříkal konstruktor, protože ta metoda včetně pythnovského .__init__(self), C++ konstrukturu a dalších vůbec nic nevytváří, nealokuje, pouze inicializuje, takže inicializátor mi přijde jako přesnější termín pro metodu, kde konfiguruješ instanci.

[kralyk z abclinuxu]

Hele tak s tímhle bacha. Podobnou kacířskou myšlenku jsem se taky snažil vyjádřit (někde okolo #1084 a níže) a se zlou jsem se potázal

Teda já bych tomu neříkal konstruktor, protože ta metoda včetně pythnovského .__init__(self), C++ konstrukturu a dalších vůbec nic nevytváří, nealokuje, pouze inicializuje, takže inicializátor mi přijde jako přesnější termín pro metodu, kde konfiguruješ instanci.

+1, navíc kvůli, že třeba v Java, částečně C++ a obecně imperativní OOP jazyky nepodporují nebo nedoporučují vytvářet objekty/struktury napřímo i s daty, tak kolikrát konstruktor neobsahuje vůbec žádnou logiku a jen hází lopatou data. Tj. v podstatě to je identitní funkce.

[deda.jabko]

Pochopitelně neočekávám, že by skutečně někdo něco takového udělal v praxi.

A ted si predstav, ze treba takova knihovna Google Guava je navrzena tak, ze konstruktory opravdu nejsou jako public, maximalne jako protected kvuli podedeni a nove objekty se vytvari pres factory method. Ale asi to bude tim, ze na takove zakladni knihovne pracuji jelita, ktere slepe aplikuji jeden navrhovy vzor za druhym.

Kdyby se mi to býval někdo ve škole pokoušel vtloukat do hlavy podobně agresivně a nesmyslně jako design patterny, asi bych k tomu měl podobný odpor (zkušenosti s design patterny mám velmi podobné tomu, jak to popisuje Bystroušák).

Tos mohl rict rovnou, ze tve problemy s navrhovymi vzory jsou psychickeho charakteru a ne technickeho. Mohlo to usetrit dobrych 200 prispevku.

[ehm]

Tos mohl rict rovnou, ze tve problemy s navrhovymi vzory jsou psychickeho charakteru a ne technickeho.

+1. :D

[kralyk z abclinuxu]

A ted si predstav, ze treba takova knihovna Google Guava je navrzena tak, ze konstruktory opravdu nejsou jako public, maximalne jako protected kvuli podedeni a nove objekty se vytvari pres factory method.

Hmm. A ani to netrkne nikoho, že existuje mezi nimi jistá drobná podobnost?

Tos mohl rict rovnou, ze tve problemy s navrhovymi vzory jsou psychickeho charakteru a ne technickeho. Mohlo to usetrit dobrych 200 prispevku.

Už někdy zkraje jsem napsal, že ten problém je především kulturní.

Že to do nás hustili na škole mě sice štve, ale v zásadě už mi to v téhle chvíli může být srdečně jedno. Tím problémem jsou aktuálně zasaženi noví studenti a následně tím budou zasženi jejich kolegové.

[ehm]

Nejdriv se zavola instrukce new pro alokaci objektu a pote invokevirtual pro dany konstruktor.

Jen drobná technická – zavolá se invokespecial. Na volání s invokevirtual by JVM umřelo:

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.VerifyError: Illegal call to internal method
Exception Details:
  Location:
    Test.<init>()V @1: invokevirtual
  Reason:
    Error exists in the bytecode
  Bytecode:
    0x0000000: 2ab6 0001 2a10 7bb5 0002 b1            

	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
	at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
	at java.lang.Class.getMethod0(Class.java:3018)
	at java.lang.Class.getMethod(Class.java:1784)
	at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)

[deda.jabko]

Mas recht, nechtelo se mi to overovat. I tak jsem stravil s touto diskuzi vic casu nez je zdravo.

[ehm]

Však v pohodě, to je jen vcelku nepodstatný detail. Mezi těmi instrukcemi stejně není žádný funkční rozdíl – JVM zařve jen na bezpečnostním checku. Když pro volání konstruktoru použiješ invokevirtual a JVM spustíš s -noverify, tak to bude normálně fungovat.

Viz:

$ javap -p -v Test
Classfile /home/ehm/Test.class
  Last modified Aug 9, 2017; size 438 bytes
  MD5 checksum f53df22204d109c297348f3503243f30
  Compiled from "Test.java"
public class Test
  minor version: 0
  major version: 52
  flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
   #1 = Methodref          #7.#18         // java/lang/Object."<init>":()V
   #2 = Fieldref           #3.#19         // Test.a:I
   #3 = Class              #20            // Test
   #4 = Methodref          #3.#18         // Test."<init>":()V
   #5 = Fieldref           #21.#22        // java/lang/System.out:Ljava/io/PrintStream;
   #6 = Methodref          #23.#24        // java/io/PrintStream.println:(I)V
   #7 = Class              #25            // java/lang/Object
   #8 = Utf8               a
   #9 = Utf8               I
  #10 = Utf8               <init>
  #11 = Utf8               ()V
  #12 = Utf8               Code
  #13 = Utf8               LineNumberTable
  #14 = Utf8               main
  #15 = Utf8               ([Ljava/lang/String;)V
  #16 = Utf8               SourceFile
  #17 = Utf8               Test.java
  #18 = NameAndType        #10:#11        // "<init>":()V
  #19 = NameAndType        #8:#9          // a:I
  #20 = Utf8               Test
  #21 = Class              #26            // java/lang/System
  #22 = NameAndType        #27:#28        // out:Ljava/io/PrintStream;
  #23 = Class              #29            // java/io/PrintStream
  #24 = NameAndType        #30:#31        // println:(I)V
  #25 = Utf8               java/lang/Object
  #26 = Utf8               java/lang/System
  #27 = Utf8               out
  #28 = Utf8               Ljava/io/PrintStream;
  #29 = Utf8               java/io/PrintStream
  #30 = Utf8               println
  #31 = Utf8               (I)V
{
  private int a;
    descriptor: I
    flags: ACC_PRIVATE

  Test();
    descriptor: ()V
    flags:
    Code:
      stack=2, locals=1, args_size=1
         0: aload_0
         1: invokevirtual #1                  // Method java/lang/Object."<init>":()V
         4: aload_0
         5: bipush        123
         7: putfield      #2                  // Field a:I
        10: return
      LineNumberTable:
        line 4: 0
        line 5: 4
        line 6: 10

  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=2, args_size=1
         0: new           #3                  // class Test
         3: dup
         4: invokevirtual #4                  // Method "<init>":()V
         7: astore_1
         8: getstatic     #5                  // Field java/lang/System.out:Ljava/io/PrintStream;
        11: aload_1
        12: getfield      #2                  // Field a:I
        15: invokevirtual #6                  // Method java/io/PrintStream.println:(I)V
        18: return
      LineNumberTable:
        line 9: 0
        line 10: 8
        line 11: 18
}
SourceFile: "Test.java"

A pak:

$ java -noverify Test
123

Kdyby sis to chtěl vyzkoušet, tak stačí normálně v hexaeditoru nahradit ten opkód 0xb7 za 0xb6.

[ehm]

Uniká mi, jak konstruktor alokuje nový objekt.

Psal volání konstruktoru. Je možné zavolat konstruktor aniž by výsledkem byla alokace objektu (vyjma volání konstruktoru předka)?

Ono to tedy nad JVM možné je, ale ne v rámci jazyka Java. Nejde to udělat ani pomocí standardní reflexe. Je potřeba vytasit těžší kalibr.

[xkucf03]

Java 8 tomuhle dost dává zapravdu.

Ne, nedává. Důvod k zavedení výchozích metod byl jiný. Nejde o to, aby si lidi implementovali X rozhraní a tím si do třídy podědili všechny jejich výchozí metody. Důvodem jsou lambdy a to, abys mohl jednoduše zapsat nějakou funkci, ve které implementuješ specifické chování, ale ten, komu tu funkci předáváš, ji nebude volat přímo, ale zavolá si tu výchozí metodu, která to typicky obalí a přidá k tomu nějaké společné (výchozí) chování. Vícenásobná dědičnost je jen vedlejší efekt.

K rozílu mezi konstruktorem a funkcí: Jaký je rozdíl mezi konstruktorem a statickou funkcí vracející novou instanci?

V případě konstruktoru tě kompilátor donutí (upozorní na chybu) v případě, že nenastavíš final proměnné.

[ehm]

Nebylo by lepší umožnit lambou implementovat i abstraktní třídu s právě jednou abstraktní metodou? Já vím, že FunctionalInterface a tak, ale marně hledám důvod, proč by to nemohlo jít aplikovat i na tu abstraktní třídu.

Zatáhnout do jazyka vícenásobnou dědičnost mi přijde jako docela dost podstatný vedlejší efekt.

[deda.jabko]

pro vysvetleni

[ehm]

Dobrá reference, díky.

[kralyk z abclinuxu]

Ne, nedává. Důvod k zavedení výchozích metod byl jiný. Nejde o to, aby si lidi implementovali X rozhraní a tím si do třídy podědili všechny jejich výchozí metody.

Moc nechápu, jak tohle souvisí s mým komentářem - ten efekt té vícenásobné dědičnosti mi nepřijde ani podstatný ani žádoucí. Obojí z toho důvodu, že i v jazycích, kde vícenásobná dědičnost je už dávno (C++) je snaha se jí pokud možno vyhnout / používat jen ve specifických případech, jestli vůbec.

V případě konstruktoru tě kompilátor donutí (upozorní na chybu) v případě, že nenastavíš final proměnné.

Tak ta funkce musí v důsledku taky nějaký konstruktor používat...

[deda.jabko]

Moc nechápu, jak tohle souvisí s mým komentářem - ten efekt té vícenásobné dědičnosti mi nepřijde ani podstatný ani žádoucí. Obojí z toho důvodu, že i v jazycích, kde vícenásobná dědičnost je už dávno (C++) je snaha se jí pokud možno vyhnout / používat jen ve specifických případech, jestli vůbec.

Cast diskuze se tu nadava, ze ma Java omezene vyjadrovaci schopnosti, a kdyz se ty schopnosti rozsi, tak se opet najde nekdo komu to vadi. Pricemz ty defaultni metody jsou sice koncepcne (ideologicky) kontroverzni, ale co se tyce praktickeho pouziti vcelku rozumne navrzene a pouzitelne.

[kralyk z abclinuxu]

Ale mně to nevadí. To, že Java 8 přidala ty defaultní metody, považuji za krok správným směrem. Vícenásobná dědičnost je toho vedlejším efektem, který sice není úplně vítaný, ale zároveň mi nepřijde moc podstatný, protože nečekám, že by to někdo reálně nějak moc využíval.

[JS1]

Nezabil jsem to temi priklady, jde mi o princip. V Jave je spousta neortogonalnich konceptu, ktere by, kdybychom zvolili jinou "bazi" konceptu, mohly byt i ortogonalni.

Kanonicky priklad je trida. To micha dohromady tri koncepty, ktere je lepsi mit oddelene - datovy typ, rozhrani a modul (viditelnost symbolu).

A protoze micha tri koncepty, je to vecny zdroj rozporu. Datove typy je obtizne vicenasobne dedit, ale u rozhrani je to naopak velmi uzitecne. Datove typy se obcas hodi predat hodnotou, ale tridy se predavaji odkazem. Tridy obsahuji kod, ale obcas je uzitecne definovat samostatnou funkci. Atd.

Takze nakonec se dojde k tomu, ze tam stejne musi pridat i ty koncepty samostatne, jako je to treba v pripade rozhrani, nebo v pripade balicku (pro viditelnost), nebo v pripade statickych metod a lambd, nebo v pripade primitivnich typu.

Vysledek je plichta - spory o to, co je lepsi pouzit.

Co by bylo spravne reseni - vyhodit pomyleny koncept tridy, ktery se snazi byt vsim, a misto toho tam dat moznost definice datovych typu, rozhrani a funkci (a modulu) tak, aby se z toho (v pripade potreby) dala trida snadno slozit.

Jenze pak uz by to nebyla Java, ale (skoro - dost zjednodusuji) Haskell.

Stejnym zpusobem bych mohl rozebrat i zbyle priklady, ale myslim, ze to neni nutne. (A ano, mel jsem cukani tam napsat i tovarni metoda, ale treba v Haskellu myslim opravdu vsechny tri role zastanou celkem pohodlne funkce.)

[ehm]

Budiž. Nevím, jak moc dobře si to umím představit, ale dejme tomu.

[kralyk z abclinuxu]

Skoro kazdy "design pattern" lze nahradit popisem "funkce ktera bla bla bla" (a skutecne staci jen tri slova)

Nebo delegaty. V podstate nic jineho, nez funkce s implicitnim parametrem (instanci). Ale chce to hned nove slovo.

Ja vidim velky problem v tehle "inflaci terminologie". Vysledek je, ze si lide nevsimnou, ze vlastne delaji tytez veci jen jinak, protoze tomu rikaji uplne jinak. A tak si zbytecne komplikuji situaci a znovuvynalezaji kola. A pak se dohaduji, co je lepsi, jestli abstraktni trida nebo interface, jestli vyjimka nebo navratova hodnota (viz diskuse vys), jestli konstruktor nebo tovarna, jestli private nebo protected.. Pritom se ty veci konceptualne temer nelisi.

+million

Tohle je velmi podobné tomu, co jsem se snažil říct někde výš. Design patterny vedou lidi k řešení formy nad obsahem. Často řeší kraviny, pouhou sémantickou změnu která nemá na fungování programu ve výsledku reálný vliv, nebo dokonce má vliv negativní, ale onen člověk si to neuvědomí, protože vzdělání v design patternech ho vede k neřešení podstaty.

Mozna je to opravdu trochu nefer vuci autorum Javy. Ja OOP povazuji do budoucna za prekonane - byl to jisty napad, jak se vyporadat se stavem (rozdelit ho na male kusy a skryt ho do objektu, ktere se predavaji a navenek ukazuji jen rozhrani), a FP prislo s necim radikalne jinym a IMHO lepsim

Já bych to neviděl tak jednoznačně. IMHO čisté FP se široce neujalo a neujme, stejně jako se v konečném důsledku nikdy neujalo skutečné čisté OOP. Je dost těžké vynášet nějaká proroctví, ale IMHO se dlouhodobě osvědčuje jakýsi hybridní přístup, kdy si člověk vezme něco z OOP, něco z FP a k tomu ještě třeba něco jiného...

[deda.jabko]

Na tom neco je, a proto jsem si posledni dobou oblibil Haskell - naprosta vetsina situaci, ktera by se v Lispu resila makry (ne reader makry) se da resit primo funkcemi.

Mne se treba velice libi myslenka vlastnich embedded DSL, coz je misto, kde v LISPu nastupuji makra a v Haskellu line vyhodnocovani. V Jave to jde resit (uznavam, ze ne az tak uplne elegantne) pomoci "fluent interface".

Ale i v Pythonu musis treba vedet, jakou funkce vrati hodnotu, a to muze byt netrivialni zjistit.

Python jsem tu uz kritizoval ;-] a je to presne ten duvod, proc ho pouzivam jen na male veci a prototypovani.

(treba vraci objekt a ty nevis, v jakem je stavu)

Pokud ti programem cestuje objekt, ktery neni ve spravnem stavu, bude chyba nekde jinde.

A pak se dohaduji, co je lepsi, jestli abstraktni trida nebo interface, jestli vyjimka nebo navratova hodnota (viz diskuse vys), jestli konstruktor nebo tovarna, jestli private nebo protected..

Podobne zdanlive nesmyslne diskuze jsou ale i v FP komunite. Tam se zase s oblibou masturbuje nad tim, jak udelat dany vyraz co nejelegantnejsi, co nejkratsi a podobne. Oblibena kratochvile Scalistu a Haskelistu je diskutovat o tom, jak udelat dany datovy typ co nejpresnejsi nebo co nejobecnejsi. Beznym programatorum to prijde ale zbytecne, tak je povazuji za tiche blazny a neposmivaji se jim za to. ;-]

[xkucf03]

Vysledek je, ze si lide nevsimnou, ze vlastne delaji tytez veci jen jinak, protoze tomu rikaji uplne jinak. A tak si zbytecne komplikuji situaci a znovuvynalezaji kola.

Přesně naopak – společná terminologie je základ – pokud věci nedokážeš ani pojmenovat, tak těžko nad nimi můžeš spolupracovat s ostatními, protože si nebudete rozumět. Pojmenované návrhové vzory ber mj. i jako příležitost k tomu, abys mohl říct třeba: vzor X se v jazyce Y řeší pomocí…. Pokud tomu neumíš dát název, tak to musíš ukazovat buď na příkladech nebo ti ostatní nebudou rozumět.

[xkucf03]

treba vraci objekt a ty nevis, v jakem je stavu

Na tohle už jsem taky narazil. Má nějaký jazyk typovou kontrolu, která zohledňuje stavy? Tzn. aby objekt měnil svůj (pod)typ v závislosti na stavu (nějaký společný nadtyp by implementoval pořád), ale přitom data zůstávala pořád na jednom místě v paměti a nemusela se přesouvat z jedné instance do jiné.

Když jsem nad tím uvažoval v Javě, tak tam by to šlo realizovat pomocí mapy a lehké proxy, která by poskytovala různé pohledy na tatáž data (implementovala různá rozhraní).

Pritom by casto stacil dalsi parametr

Další parametr ti zahnojí API a navíc bys ho musel předávat při každém volání (a všude tam, odkud voláš, bys musel mít tu hodnotu). Oproti tomu ten DI přístup, kdy objekt jednou naparametrizuješ a pak ho opakovaně voláš (a parametry už neřešíš), je praktičtější a jednodušší.

[kralyk z abclinuxu]

Na tohle už jsem taky narazil. Má nějaký jazyk typovou kontrolu, která zohledňuje stavy? Tzn. aby objekt měnil svůj (pod)typ v závislosti na stavu

Tomuhle se říká Dependent type a pokud by to jazyk měl skutečně podporovat v rámci statického typování (tj. bez nutnosti runtime checků), tak se z něj v podstatě do značné míry stává theorem prover. Coq nebo Idris tohle samozřejmě podporují. V běžných jazycích se to IMHO nestane.

[xkucf03]

Je zajímavé, že co ti jinde nevadí – tzn. jazyk staví na nějakých myšlenkách a drží se jich:

Nebo chape, ze jde o vedlejsi efekt jinych vlastnosti, ktere davaji dobry smysl. Napr. zde konkretne - funkce jsou hodnoty jako vsechno ostatni, jmena se na hodnoty vazou a je mozne stejna jmena vazat na jine hodnoty (prirazenim); z toho plyne, ze lze funkce za behu "modifikovat".

a zlehčuješ negativní vedlejší efekty. To považuješ za problém u Javy – tam ti asi vadí, že se drží myšlenky OOP a snaží se vše modelovat jako objekty.

Java sice dělá nějaké ústupky¹, ale jinak se snaží držet tu čistotu původní myšlenky „vše je objekt“. Dokonce i když si nad tím někdo postaví vlastní abstrakci, ať už v podobě nějakých tříd, rozhraní nebo anotací, stále platí, že vše je objekt (nebo třída či metoda, ale to jsou taky objekty).

Kdyby bylo možné vytvářet abstrakce jiného typu a rozšiřovat tím samotný jazyk, tak by tohle už neplatilo – měl bys tam nějaké nové jazykové konstrukty, operátory, klíčová slova atd. a už by s tím nešlo pracovat jednotným způsobem, jako s tou dnešní javovskou abstrakcí.

Dokonce i ty lambdy v Javě 8 jsou implementované přesně v duchu těchto principů – i když je to funkce, tak je to jen jinak napsaná anonymní vnitřní třída a pracuje se s ní stejně jako s jinými třídami/objekty. IMHO je dobře, že se Java těchto principů drží, a doufám, že i abstrakce, které se v budoucnu objeví, budou ve stejném duchu.

_{[1] primitivní typy nejsou objekty – ale to je jen pár číselných typů a boolean – a kdyby to byly objekty, tak ji zas lidi budou kritizovat kvůli výkonu nebo paměťové náročnosti}

[JS1]

Java sice dělá nějaké ústupky1, ale jinak se snaží držet tu čistotu původní myšlenky „vše je objekt“.

Bohuzel nikoli. Funkce nejsou objekty, typy nejsou objekty, tridy nejsou objekty, balicky nejsou objekty, pole nejsou objekty..

Kdyby bylo možné vytvářet abstrakce jiného typu a rozšiřovat tím samotný jazyk, tak by tohle už neplatilo

Vidis a to se pletes. Kdybys znal Haskell, videl bys to (mozna).

Dokonce i ty lambdy v Javě 8 jsou implementované přesně v duchu těchto principů – i když je to funkce, tak je to jen jinak napsaná anonymní vnitřní třída a pracuje se s ní stejně jako s jinými třídami/objekty.

Coz je treba zrovna priklad te hruzy. Koncept tridy micha prilis mnoho veci dohromady. Autori ale zjistili, ze samotne lambdy nejsou tak spatny napad, a ted maji v jazyce jak tridy, tak lambdy. (To same by se dalo rict i o rozhranich.) Realita je donutila pridat tam neortogonalni koncept, ktery jazyk jen zkomplikoval (protoze nemohou uz nikdy ubrat prekomplikovany koncept trid).

Asi bych ti mohl odpovedet podrobneji, ale mam pocit, ze uz budu opakovat to, co jsem napsal vys.

[Bystroushaak]

Ten problém ceny spočíval např. ve slabém výkonu (zejména dříve, kdy ještě nebyly stroje tak výkonné, což IMHO byl důvod např. selhání Lisp machines).

Afaik clisp je kompilovaný do strojového kódu a výkonnostně na tom není vůbec špatně už asi tak 30 let. Alespoň to tvrdil lispista kterého znám.

Další problém je cena za ergonomii - tlak na homoikonicitu a setrvání u s-exprs (m-exprs nebyly realizovány) dovedl Lisp k příšerné syntaxi. Lispeři tohle typicky s argoancí sobě vlastní odbudou s tím, že lidi jsou zvyklí na C-like syntaxi a cokoli jiného se jim nelíbí. To je ovšem dosti bullshit, s-exprs pro účely programování prostě docela sajou.

Jak si pak vysvětluješ popularitu clojure?

Naproti tomu v Lispu si každý může dělat úplně co chce a vynalézat vlastní jazyky v rámci Lispu, což vede k anarchii a následně zmatku. Tohle dobře ilustruje úspěch Clojure, které oba extrémy přivádí k sobě a vytváří mezi nimi celkem hezký průměr.

Bingo, tohle je imho největší problém lispu a důvod, proč ho reálně používá tak málo lidi. Prostě bordel.

[JS1]

Afaik clisp je kompilovaný do strojového kódu a výkonnostně na tom není vůbec špatně už asi tak 30 let.

Jestli myslis tenhle CLisp, tak ten je interpretovany, ale to co pises plati treba pro SBCL Lisp.

Bingo, tohle je imho největší problém lispu a důvod, proč ho reálně používá tak málo lidi. Prostě bordel.

A Smalltalk tim netrpi?

[Bystroushaak]

A Smalltalk tim netrpi?

Jestli jo, tak jsem si nevšiml, alespoň ne v rámci Phara. Asi by se to dalo najít mezi jednotlivými implementacemi, ale dneska už asi nic než pharo / squeak nedává pro běžného člověka smysl.

U lispu mi přijde, že je problém hlavně s tím, že je hodně lehké si implementovat vlastní abstrakce. Něco jako ty známé classy v čistém javascriptu, kde to nakonec každý dělá po svém a výsledkem je jen bordel a nekompatibilita. Smalltalk je v tomhle o hodně víc unifikovaný a definovaný ve standardní knihovně, v rámci konkrétního projektu.

[ehm]

Jak si pak vysvětluješ popularitu clojure?

Popularitu? Vždyť podle TIOBE je to na 42. příčce (pro srovnání – Haskell je 47., Erlang 31.) a PYPL ho vůbec nesleduje.

[Bystroushaak]

Popularitu? Vždyť podle TIOBE je to na 42. příčce (pro srovnání – Haskell je 47., Erlang 31.) a PYPL ho vůbec nesleduje.

Tak to je samozřejmě jedna věc. Když jsem ale hledal práci, tak na mě vyskakovalo hned několik inzerátů na Clojure. Je teda fakt, že když koukám teď, tak nevidím nikde nic.

[ehm]

Nedivil bych se, kdyby i v ČR bylo pár startupů, co Clojure používají. Taky o Clojure dělal přednášku Pavel Tišnovský a zmiňoval, že v tom mají něco napsáno v práci (dělá myslím v Red Hatu). Ale za popularitu bych to ještě úplně neoznačil.

[Bystroushaak]

Myslel jsem to spíš popularitu vzhledem k tomu, že je to lisp. Protože lisp prostě běžně nevidíš nikde.

[ehm]

Tak to pak asi jo. Ono tomu bude napomáhat i to, že když to běží nad JVM, nemusíš přímo v Clojure psát úplně všechno. To se ostatně týká asi i dalších bytecode-based technologií.

[JS1]

Clojure je celkem fajn, ale CL na tom neni o mnoho hur. Sam jsem chvili byl fanousek Clojure, nez jsem prisel na to, ze co dokazu v Lispu se da udelat i v Haskellu a typove bezpecne.

Driv jsem mel nejradsi Python, ale dnes ten prilis imperativni styl mohu vystat jen s obtizemi (i kdyz ho pouzivam, stale je to neco, v cem jsem na prakticke ulohy nejrychlejsi). Pak me zaujal Common Lisp a pozdeji Clojure, a eventualne Haskell.

[ehm]

Používáš Haskell jen pro osobní projekty, nebo i pracovně?

[JS1]

Jen osobni, a jeste ne prilis.. Bylo by ale fajn, kdybych v nem mohl pracovat.

[kralyk z abclinuxu]

Vzhledem k tvé přezdívce by tě možná mohl zajímat Elm nebo PureScript ...

[JS1]

Na oboje jsem koukal, ale weby a JS me nijak zvlast nelakaji. Elm vypada celkem dobre, akorat me odrazuje absence typovych trid.

To spis me do budoucna zajima smer jako Idris a Coq.

[xkucf03]

Pokud tvrdíš, že jazyk s vysokými možnostmi abstrakcí (např. lisp nebo haskell) je nějakým způsobem 'lepší', ale nejsi schopen to nijak dále vysvětlit na příkladech nebo statistikách nebo něčem podobném, je to tvoje selhání v diskusi.

Přesně tak. Např. bych uvítal příklad kódu s abstrakcí, kde mým úkolem bude najít a opravit chybu. Nejprve budu muset identifikovat, o jakou abstrakci jde, pak najít její dokumentaci/definici a nastudovat si, jak funguje. A až pak můžu opravit chybu v kódu. Zajímá mne celkový čas, který tím strávím – tzn. efektivita vývoje resp. údržby v tomto případě.

S vyšším počtem opakování použití té samé abstrakce už náklady na studium nebudou tak vysoké a naopak můžou převládnout pozitivní efekty této abstrakce. Otázka ale je, kdy tento „bod zlomu“ nastane.

[xkucf03]

nekdo prijde s vhodnou abstrakci, ktera program zasadne zkrati, ale pro tebe bude tezko uchopitelna

Nejen pro mě. Ne všichni jsou geniální programátoři a ne všichni se danému programu chtějí (nebo mají tu možnost) věnovat naplno a naučit se všechny abstrakce v něm použité. Pokud je daný jazyk/abstrakce těžko uchopitelný lidmi, kteří s tím mají pracovat, tak je to prostě nevhodný nástroj. Programovací jazyk je jen dorozumívací prostředek mezi člověkem a počítačem – není to cíl (resp. pro někoho je cíl onanovat nad teoretickou dokonalostí daného jazyka, ale pro praktický vývoj je to irelevantní nebo spíš škodlivé).

Někdo to tu přirovnával k počtu písmen v abecedě – to je celkem výstižné. Pokud bychom měli 10× tolik písmen + měli možnost vytvářet nová písmena podle potřeby třeba na začátku věty nebo rozhovoru, mohli bychom výrazně zvýšit informační hustotu, sdělit totéž menším počtem znaků/hlásek. Ale bylo by to užitečné? Někdy se vytvoření vlastní abstrakce¹ vyplatí a jindy je spíš na škodu. Někdy to studium dané abstrakce (což je nutný předpoklad už jen k tomu, abys mohl ten kód číst) natolik nákladné, že to převažuje nad přínosy. Dva řádky psané „primitivním“ jazykem tam budou efektivnější než jeden řádek, ke kterému si ale musíš nastudovat² odstavec abstrakce.

Jsou týmy/projekty, na kterých je potřeba udržovat kód čítající stovky tisíc řádků, přes deset let vývoje, desítky lidí, které prošly týmem a přispívali do kódu… ty jsi třeba ve třetí nebo čtvrté generaci programátorů, která se o ten software stará. Tam je výhodou jednodušší jazyk a srozumitelnější abstrakce. Taky ten software může být ve stavu, kdy se už moc nerozvíjí a jen je potřeba občas opravit nějakou chybu nebo přidat nějakou drobnost. V tu chvíli na tom přestávají lidi pracovat na plný úvazek a jsou alokováni na jiné projekty – dělají třeba na pěti takových softwarech nebo se věnují primárně jiné aplikaci a na tomhle dělají jen když je to občas potřeba. Pak je obrovsky neefektivní, aby ti lidé museli držet v hlavě všechny abstrakce použité ve všech těch softwarech – nebo spíš aby si je museli vždy znovu a znovu nastudovat a zase být schopný vyvíjet.

U Javy se do podobných problémů můžeš dostat taky – ale tam se to stává, když nedodržíš doporučené postupy a návrhové vzory. Např. třívrstvá architektura (v Javě EE nebo Springu) je dobrá – ale když pod to nacpeš další tři nebo čtyři vrstvy PL/SQL kódu, tak to ztrácí smysl a jako celek je to špatně použitelné (čti: vývoj a údržba jsou drahé). Oproti tomu u těch tebou vyzdvihovaných jazyků se do problémů dostaneš právě při dodržování těch doporučení (vytvářet si vlastní abstrakce, psát velmi zhuštěný kód) v kombinaci s tím stylem vývoje, o kterém píšu výše. Efektivní by to naopak mohlo být u projektů, které jsou spíš menší, dělá na nich méně lidí, všichni jsou velmi dobří programátoři (což ale znamená i velmi drazí) a hlavně: tým je dlouhodobě stabilní, dělají na tom pořád ti samí lidé. Jde tedy o to, jaký projekt to je a jak je vývoj veden.

A netýká se to jen komerčního vývoje, jak by se mohlo zdát. I u svobodného softwaru vyvíjeného komunitně jsou složité abstrakce problém – čím víc si toho musíš nastudovat předem, tím vyšší vstupní bariéra – kterou se často kvůli opravě nějaké chyby nebo přidání nové funkce nevyplatí překonávat. Pokud se budeš muset naučit padesát nových písmen nebo celou novou abecedu, tak se na nějaké přispívání nejspíš vykašleš.

Ve výsledku to akorát nahrává tomu, aby se o program staral jeden nebo několik málo lidí a ostatní k tomu nepouštěli. Tohle má i své světlé stránky, ale ne vždy je možné nebo žádoucí takhle vést vývoj. Ta nenahraditelnost lidí (resp. horší nahraditelnost) je problém jak pro zadavatele, tak pro samotné vývojáře – nemůžeš jen tak odejít a dělat něco jiného, protože budeš mít pocit, že se bez tebe původní projekt zhroutí nebo se vývoj zastaví, takže jsi vlastně méně svobodný, než kdybys používal abecedu o menším počtu znaků.

_{[1] a ta může mít různé podoby – v některých jazycích to může být třeba sada tříd/rozhraní místo přetížených operátorů nebo nějaké formy DSL či rozšíření samotného jazyka
[2] a v některých jazycích budeš mít dokonce problém zjistit, co si vůbec máš nastudovat, protože z místa použití dané abstrakce nevede jednoduchá cesta (např. proklik v IDE) na místo její definice a dokumentaci}

[Bystroushaak]

Nejen pro mě. Ne všichni jsou geniální programátoři a ne všichni se danému programu chtějí (nebo mají tu možnost) věnovat naplno a naučit se všechny abstrakce v něm použité. Pokud je daný jazyk/abstrakce těžko uchopitelný lidmi, kteří s tím mají pracovat, tak je to prostě nevhodný nástroj. Programovací jazyk je jen dorozumívací prostředek mezi člověkem a počítačem – není to cíl (resp. pro někoho je cíl onanovat nad teoretickou dokonalostí daného jazyka, ale pro praktický vývoj je to irelevantní nebo spíš škodlivé).

Na tomhle mě nejvíc baví, že před pár lety jsem znal pár programátorů v C a PHP, kteří měli stejné argumenty k OOP. Jeden z nich dodneška dělá PHP a objekty pořád nepochopil, naposledy jsem se ho na to ptal v pátek a pořád to neumí. Přitom už od roku 2012, kdy jsem mu je zkoušel vysvětlit uběhlo fakt hodně času. Když jsem začínal na internetu v roce 2003 a chodil jsem na pcsvet, tak tam bylo často možné potkat v diskuzích lidi, kteří uměli jen assembler a úplně stejně si stěžovali na C, že je to k ničemu a pomalé a že si for smyčky můžou napsat sami a efektivněji..

Strach z abstrakcí není strachem z nějakých nepochopitelných geniálních věcí, je to strach z něčeho nového mimo zónu komfortu, něčeho co tě nutí se sebrat a zapracovat na pochopení nové věci. Zpětně se pak ale většinou divíš, jak jsi bez tak jasné a očividné věci mohl žít.

Někdo to tu přirovnával k počtu písmen v abecedě – to je celkem výstižné. Pokud bychom měli 10× tolik písmen + měli možnost vytvářet nová písmena podle potřeby třeba na začátku věty nebo rozhovoru, mohli bychom výrazně zvýšit informační hustotu, sdělit totéž menším počtem znaků/hlásek. Ale bylo by to užitečné? Někdy se vytvoření vlastní abstrakce1 vyplatí a jindy je spíš na škodu. Někdy to studium dané abstrakce (což je nutný předpoklad už jen k tomu, abys mohl ten kód číst) natolik nákladné, že to převažuje nad přínosy. Dva řádky psané „primitivním“ jazykem tam budou efektivnější než jeden řádek, ke kterému si ale musíš nastudovat2 odstavec abstrakce.

To není úplně dobré přirovnání, reálně je to víc podobné spíš novým slovům a jejich definicím. Je lepší mít omezený slovník a nová slova vždycky definovat vlastními slovy předtím, než je použiješ? Všimni si, že každý specializovaný člověk dřív nebo později přebere terminologii svého oboru, protože je to užitečné a jasně definované a když se tím dva lidi baví, tak ví přesně co se tím myslí.

Jsou týmy/projekty, na kterých je potřeba udržovat kód čítající stovky tisíc řádků, přes deset let vývoje, desítky lidí, které prošly týmem a přispívali do kódu… ty jsi třeba ve třetí nebo čtvrté generaci programátorů, která se o ten software stará. Tam je výhodou jednodušší jazyk a srozumitelnější abstrakce. Taky ten software může být ve stavu, kdy se už moc nerozvíjí a jen je potřeba občas opravit nějakou chybu nebo přidat nějakou drobnost. V tu chvíli na tom přestávají lidi pracovat na plný úvazek a jsou alokováni na jiné projekty – dělají třeba na pěti takových softwarech nebo se věnují primárně jiné aplikaci a na tomhle dělají jen když je to občas potřeba. Pak je obrovsky neefektivní, aby ti lidé museli držet v hlavě všechny abstrakce použité ve všech těch softwarech – nebo spíš aby si je museli vždy znovu a znovu nastudovat a zase být schopný vyvíjet.

Jenže to předpokládá, že se tam nevyskytne potřeba abstrakcí. Reálně se tam ovšem vyskytne úplně stejně, protože tu potřebu neudávají programátoři, ale podstata problému. Programátoři v jazycích nižší úrovně pak tu abstrakci vybudují například návrhovými vzory a továrnami továren, takže jí musíš nastudovat a pochopit úplně stejně, jen něčím desetkrát víc ukecaným. Je to ekvivalent toho, jako kdyby si nadefinovali vlastní slovo vlastním popisem, které přitom odpovídá něčemu, co už je dobře definované a obecně uznávané.

Ostatně - kde si myslíš, že se ty abstrakce v jazycích berou? Že si někdo jen tak sedne a řekne si, že jí vymyslí? Jde o často opakované vzory, které se vyplatí mít časem jako součást stdlib a pokud se opakují fakt hodně často, tak dokonce jazyka. Třeba taková list (dict / set) comprehension a generator expression je něco, co člověku úžasně šetří práci a prostor a naprosto dává smysl to v jazyku mít, protože ten pattern se neustále opakuje. A takhle je to i s vysokoúrovňovými jazyky jako lisp, jen prostě odsud zezdola to většinou není vidět. Já jsem si třeba v pythonu několikrát přál, aby tam byly lispovská makra. Většinou jsem končil psaním generátoru kódu, což mělo mnoho nevýhod.

[ehm]

Už mě to s těmi továrnami začíná srát.

Klasický příklad na použití továren uvedl třeba Alexandrescu v Modern C++ design. Píšeš hru, kde máš jednotlivé entity a jejich chování popsané v třídách. Ty entity potřebuješ dynamicky spawnovat. Jejich konkrétní konfigurace ale může záviset třeba na zvolené obtížnosti. Pak lze místo hard-wiringu na každém místě v kódu, kde chceš tu entitu naspawnovat, volat jen tu továrnu.

Co na to poskytuje geniálního a tak strašně odlišného Python? Zkus to napsat bez použití továren a jejich obdob a s největší pravděpodobností to bude totální prasárna, ze které si všichni budou rvát vlasy a jediné zbylé argumenty v rukávu budou, že na takové „abstrakce‟ není dotyčný zvyklý. Jasně, můžeš si nadefinovat entitu jako model a pak mít jednu sadu operátorů na práci s ní pro každou úroveň zvlášť, a někde přepínat, která sada operátorů se použije. Protože „funkcionální‟, pyčo. A fakt hodně se to liší od předávání struktury funkcím v C.

Na závěr si samozřejmě řekneme, že Java je špatná. O kousek výše jsme si řekli, že Java je špatná, protože je tam těch abstrakcí moc a „programátoři přes všechny ty abstrakce neví, co se dejě pod povrchem‟ (#589). Teď je naopak Java špatná, protože těch abstrakcí má málo.

[Bystroushaak]

Co na to poskytuje geniálního a tak strašně odlišného Python?

Slovník, do kterého si poukládáš ty classy a pak je dynamicky instancuješ, případně s aplikací functools.partial? Možná bych to vyhodil o úroveň výš do odekorované funkce, kde ten dekorátor pracuje s konfigurací. Asi tak něco.

Na závěr si samozřejmě řekneme, že Java je špatná. O kousek výše jsme si řekli, že Java je špatná, protože je tam těch abstrakcí moc a „programátoři přes všechny ty abstrakce neví, co se dejě pod povrchem‟

Hele, ale všimni si, že ten argument jsem neudělal já, ale deda.jablko (#546) s jeho „raketoplánovitostí“, ke které jsem jen nabídl svojí interpretaci významu podle toho, co se o javě běžně říká.

Podle mého osobního názoru je java jako platforma skutečně velmi složitá a programátor naprosto nemá kontrolu ani tušení, co se děje pod pokličkou. Ale to platí pro každý JITovaný interpreter.

Jako jazyk je naopak silně triviální, nebál bych se možná říct, že je jednodušší na kompletní pochopení než C (určitě je čistější než C).

[Bystroushaak]

Jako jazyk je naopak silně triviální, nebál bych se možná říct, že je jednodušší na kompletní pochopení než C (určitě je čistější než C).

Ono teda ještě k tomu se hodí říct, že právě ta jednoduchost tě nutí tlačit abstrakci do aplikačního kódu nad tím a tím zvyšuje složitost toho, co se musí na všech úrovních (levelech, vrstvách, myšleny knihovny používající knihovny) vybudovat.

[ehm]

Slovník, do kterého si poukládáš ty classy a pak je dynamicky instancuješ, případně s aplikací functools.partial?

To neřeší předávání argumentů.

Možná bych to vyhodil o úroveň výš do odekorované funkce, kde ten dekorátor pracuje s konfigurací. Asi tak něco.

Což je továrna. Jen to není objekt, ale funkce.

Podle mého osobního názoru je java jako platforma skutečně velmi složitá a programátor naprosto nemá kontrolu ani tušení, co se děje pod pokličkou. Ale to platí pro každý JITovaný interpreter.

To už je záležitost JVM. Vzhledem k tomu, že v praxi se AOT téměř nepoužívá (a i použití AOT nejspíš bude trpět neduhy jako je nedeterministický GC apod.), tak dejme tomu.

Jako jazyk je naopak silně triviální, nebál bych se možná říct, že je jednodušší na kompletní pochopení než C (určitě je čistější než C).

To si nemyslím, ale může to být tím, že žádný standard C neznám úplně detailně.

Ono teda ještě k tomu se hodí říct, že právě ta jednoduchost tě nutí tlačit abstrakci do aplikačního kódu nad tím a tím zvyšuje složitost toho, co se musí na všech úrovních (levelech, vrstvách, myšleny knihovny používající knihovny) vybudovat.

To se mi právě moc nezdá. Třeba jsi zmiňoval comprehensions. Abych je suploval, potřebuji další abstrakci? Ne, jen to musím rozepsat se smyčkou. Nebo Java nemá yield, takže musíš vytvářet a vracet Iterable (místo toho, aby to jazyk odstínil a umožnil elegantnější zápis). Absence přetěžování operátorů nový kód taky nepřidá. Absence properties (resp. možnosti se nahookovat na přímý přístup do fieldu a přidat tam nějakou logiku) produkuje boiler-plate kód, ale nevzniká kvůli tomu nová abstrakce. O hashCode a equals platí totéž.

[xkucf03]

Absence properties (resp. možnosti se nahookovat na přímý přístup do fieldu a přidat tam nějakou logiku) produkuje boiler-plate kód, ale nevzniká kvůli tomu nová abstrakce. O hashCode a equals platí totéž.

Tohle celkem elegantně řeší Lombok. Jen škoda, že je to trochu hack. Ale vzhledem k tomu, že ke kompilaci stejně prakticky všichni používají buď OpenJDK (či Oracle JDK) nebo Eclipse, tak to je použitelné.

Hezčí by bylo, kdyby anotační procesor mohl měnit třídu, na které jsou ty anotace. Pak by to bylo úplně čisté.

A za povšimnutí stojí i to, že aby Lombok fungoval a byl jím vygenerovaný kód vidět už při editaci v IDE, není potřeba žádná speciální podpora ze strany IDE (viz Netbeans).

[kralyk z abclinuxu]

Tohle celkem elegantně řeší Lombok. Jen škoda, že je to trochu hack. Ale vzhledem k tomu, že ke kompilaci stejně prakticky všichni používají buď OpenJDK (či Oracle JDK) nebo Eclipse, tak to je použitelné.

Jaký je Lombok v porovnání s Kotlinem?

[ehm]

O Lomboku vím, ale nevěděl jsem, jak to funguje. Teď už to vím. Není to „trochu“ hack – je to dost velký hack. Chtělo by to buď submitnout JEP na veřejné API pro modifikování AST, nebo jít cestou code generation. Přimlouval bych se za první variantu.

[JS1]

Tohle celkem elegantně řeší Lombok.

Ech, tohle je na facepalm.

Tedy, nejsem si jisty, jestli jsem to spravne pochopil, ale to mam skoro nejradsi - Javista odmitne (Lispovska) makra, protoze jsou pry prilis slozita, a pak mi ukaze preferovane reseni - generator kodu specificky pro sve IDE.

I kdyz dost tomu konkuruje to vice proflakle - odmitne Lispovskou syntaxi jako prilis mnoho zavorek, aby mi pak ukazal, jak si muze polovinu aplikace nadeklarovat v XML.

[ehm]

Nepochopil jsi to správně. Lombok není specifický pro žádné IDE.

[JS1]

Ano, to Franta tvrdil, ale ja se jen nahodou podival do dokumentace a ctu:

WARNING: This feature does not currently work in NetBeans.

A druha vec je, bude to fungovat i v Emacsu, nebo podporuji jen 3-4 bezna IDE? Jestli to druhe, pak je to trochu jako s tou nezavislosti Javy na platforme - teoreticky ano, prakticky tam, kde bezi JVM, coz je radove mene platforem, nez podporuje treba GCC.

A to jsem se ani nedostal k tomu, ze generovani kodu je dost oskliva alternativa k makrum. Ale tady si nejsem jisty, jestli to Lombok dela, jestli uklada ten zdrojak vygenerovany nebo ne.

[ehm]

Začíná mi docházet trpělivost.

Řeč byla o generování getterů/setterů, hashCode/equals. Do kódu se doplní anotace a Lombok pomocí anotačního procesoru nad kódem udělá transformaci, kterou tam ty metody vygeneruje. Hack je to z toho důvodu, že k operacím nad AST používají interní API – anotační procesor nic takového veřejně neposkytuje. Je to ušité na míru pro javac z OpenJDK a ecj z Eclipse.

Bude to fungovat v každém IDE za předpokladu, že se IDE spokojí s uspokojením závislosti na těch setterech/getterech na binární úrovni, tj. při volání z jiné třídy ověří, že patřičný *.class soubor obsahuje metodu s danou signaturou, nikoliv, že se takové metody vyskytují přímo ve zdrojáku. Totéž platí pro všechny tooly na statickou analýzu.

Zavedení keywordu val už je rozšíření syntaxe jazyka a není divu, že s tím IDE může mít problém.

[JS1]

Začíná mi docházet trpělivost.

Ta by mela dojit hlavne autorum Lomboku, aby to tam dopsali, jak to vlastne funguje.

Ale dik, aspon vim, o cem to je. V podstate jsou to makra.

Uznavam, ze je to lepsi nez generovat kod do zdrojaku. Ale zase, je to specificke reseni problemu, ktery ma pomerne elegantni abstraktni reseni. Je to takovy dost opatrny krok spravnym smerem, jako skoro vsechno, co nekdo pridava do Javy.

(Daleko vic se mi libi Haskellovske reseni - deriving - ackoli si nejsem jisty, jestli pokryva vsechno, co dela Lombok.)

[ehm]

Pro úplnost: ty settery/gettery ještě přežiju, ale equals/hashCode mě serou fakt kurevsky moc a bylo by fajn, kdyby to nějak řešil přímo jazyk. Delegovat to na externí knihovnu a to ještě takovýmhle hackem není zrovna šťastné řešení.

Tohle je třeba jedna z věcí, kde je v Javě určitě prostor pro zlepšení. Když už ne na úrovni jazyka, tak alespoň na úrovni API. Už je tam Objects.hash(Object... values), ale je tam zbytečně varargs – chtělo by to tu metodu aspoň přetížit zvlášť pro každý počet argumentů (do nějakého rozumného čísla, pak to nechat na varargs). Pro equals je to složitější, protože se to obecně nedá napsat bez reflexe.

[kralyk z abclinuxu]

Pro úplnost: ty settery/gettery ještě přežiju, ale equals/hashCode mě serou fakt kurevsky moc a bylo by fajn, kdyby to nějak řešil přímo jazyk. Delegovat to na externí knihovnu a to ještě takovýmhle hackem není zrovna šťastné řešení.

Asi už s tím tady asi vysírám, ale Kotlin to řeší přímo v jazyku.

[xkucf03]

Zrovna ten val je v principu jiný než zbytek Lomboku a IMHO tam úplně nepatří.

Ale tady si nejsem jisty, jestli to Lombok dela, jestli uklada ten zdrojak vygenerovany nebo ne.

Ne, viz můj předchozí komentář – vstupuje do procesu kompilace a ovlivňuje výsledný bajtkód.

Jako generátor kódu (zdrojáku) jde použít taky, ale to se běžně nedělá (to je jen pojistka pro případ, že bys chtěl od Lomboku odejít).

[xkucf03]

P.S. Pointa lomboku je v tom, že ti na základě anotací vygeneruje do bajtkódu nějaké metody nebo proměnné/konstanty, které pak nemusíš psát do zdrojáku.

[xkucf03]

generator kodu specificky pro sve IDE.

Ne, to jsi pochopil špatně. Lombok je specifický pro kompilátor (podporuje OpenJDK/Oracle a Eclipse), nikoli pro IDE, protože ten kompilátor musí „hacknout“ (bohužel k tomu neexistuje podpora ve specifikaci Javy). Zkompilovaný bajtkód je ale úplně standardní a může s ním pracovat kdokoli, jakýkoli nástroj nebo běhové prostředí. A vzhledem k tomu, že IDE kompilují online a pracují s výsledným bajtkódem, tak to funguje (např. ti IDE bude napovídat metody, které se vygenerovaly do bajtkódu, ale nejsou ve zdrojáku).

a pak mi ukaze preferovane reseni

Tohle taky není pravda. Nepovažuji to za ideální řešení (chtěl bych podporu ve specifikaci). A sám jsem řešil dilema, jestli na aktuálním projektu Lombok zavést nebo ne. Není to černobílé, ale nakonec jsem se pro něj rozhodl – důležitou roli hrálo to, že existuje snadná cesta, jak se ho zbavit a převést ten kód na standardní Javu bez Lomboku. Bez toho bych do něj nešel, protože by mi vadila závislost na něčem nestandardním. Takhle ale není problém se v případě nějakých problémů Lomboku zbavit.

aby mi pak ukazal, jak si muze polovinu aplikace nadeklarovat v XML

To nevím, s jakými javisty se bavíš. XML konfiguraci u EJB 2 lidi přímo nesnášeli (a naopak ocenili anotace v EJB 3), totéž ve Springu, který prošel stejným vývojem. XML se pro „programování“ občas používá, ale jednak máš dobrou podporu v IDE a hlavně se používá jen pro specifické případy. Něco podobného je třeba Apache Camel – ten IMHO dává smysl hlavně v případě, kdy část lidí píše komponenty v Javě (často žádné nepíšeš a použiješ ty hotové) a jiná část lidí (sedící třeba v jiné kanceláři, firmě, státu…) ty komponenty používá a „slepuje“ pomocí XML. Na tenhle způsob práce je to celkem dobré, protože je to vlastně takový konfigurák/skript, který nemusíš kompilovat a jen ho hodíš třeba do deploy adresáře Karafu a on se nasadí, nebo ho vložíš do konfigurace Active MQ, kde to pak dělá nějaké operace s JMS zprávami. Ale i ten Camel podporuje kromě XML i zápis v Javě, takže si můžeš vybrat.

[ehm]

To nevím, s jakými javisty se bavíš

+1. Tohle je takové klišé, co (nejen) v téhle diskuzi zaznívá furt dokola. Přitom co tak znám z vlastní praxe i vidím názory online, tak mi přijde, že nějaké monstrózní XML konfiguráky pro Spring apod. lidi bytostně nesnáší a třeba ten Spring právě v reakci na to zaváděl i alternativní možnosti. A dodnes s tím stigma bojují – přímo mezi limdi, co Javu používají.

[JS1]

Tohle je takové klišé, co (nejen) v téhle diskuzi zaznívá furt dokola.

Mozna to klise je, bohuzel odmitani lepsich reseni z jinych jazyku (jenom proto, ze jsou abstraktnejsi) uz takove klise neni.

[xkucf03]

Možná ti to bude připadat moc přízemní a pragmatické, ale…

1) Za cíl programování považuji vytvoření nějakého užitečného programu. Že je to i intelektuální cvičení a zábava považuji za pozitivní vedlejší efekt. Mít to jako cíl lze jen občas, jinak by to bylo samoúčelné a zbytečné.

2) V minulosti vznikla (a v budoucnu ještě vznikne) spousta užitečných programů, které dělají něco úžasného, a napsat je nebylo tak těžké (výnosy jsou mnohem vyšší než náklady). Přestože se ty programy psaly v jazycích, které (zřejmě) považuješ za špatné, hloupé a k dokonalosti mají daleko (to si myslím i já).

Co by lidstvu přineslo, kdyby všichni psali třeba v tom Haskellu (nebo něčem jiném, co zrovna považuješ za vrchol dokonalosti)? Trval by vývoj programu poloviční dobu? Obsahovaly by programy jen polovinu chyb? Běžely by dvakrát rychleji? Mohly by řešit výrazně složitější úkoly? Kde jsou ty praktické přínosy? Nebo je to zase jen nějaké mentální cvičení?

[Fluttershy, yay!]

Něco o dějinách instalatérství.

Ve které historické fázi je vývoj software?

[Bystroushaak]

To si nemyslím, ale může to být tím, že žádný standard C neznám úplně detailně.

V tom je natažený hrozný historický balast plný hoven.

Abych je suploval, potřebuji další abstrakci? Ne, jen to musím rozepsat se smyčkou.

Jo. Jenže to je zrovna pattern, který si abstrakci zaslouží. Poměrně často potřebuješ vytvořit sekvenci, která je jen transformací jiné sekvence. Přijde mi fajn pro to mít syntaktickou podporu. Dá se to řešit přes filter / map, ale tohle je silnější (protože to funguje přímo na setech / listech / dictech a nemusíš dělat konverze).

Jinak k tomu potřebuješ smyčku a další (v podstatě dočasné) proměnné, jenže to třeba neřeší generator expressions (to samé co comprehensions, jen se to vyhodocuje lazy přes generátory), které do sebe můžeš různě zanořovat naprosto bez práce na pár řádcích čitelného kódu. Pokud tohle chceš dělat v jazyce, který je nemá, tak prostě musíš napsat desítky, možná stovky řádků kódu, který se bude často opakovat. Proto to většinou ani neděláš, nebo to používáš jako knihovnu, jenže pak jsi na tom úplně stejně - máš nějakou abstrakci, kterou se musíš naučit používat a poznávat a všichni ostatní, kdo to budou číst taky.

Jinak já zas nechci vychvalovat python, protože ten je oproti ostatním jazykům taky hodně omezený a nezřídka narážím na problémy, které by se daly řešit líp, kdyby tam šly věci jako třeba double-return který funguje v Selfovských blocích a tak podobně.

[ehm]

V tom je natažený hrozný historický balast plný hoven.

V Javě místy taky.

Jo. Jenže to je zrovna pattern, který si abstrakci zaslouží.

Já právě zpochybňuju, jestli to za abstrakci vůbec považovat. Svým způsobem ano (ve smyslu míň toho přečteš, víc si toho domyslíš => je to abstraktnější), ale není to abstrakce v architektonickém smyslu. Tedy absence takové featury nerozbíjí kód na vyšších úrovních, není potřeba to tam nějak suplovat. Je to záležitost třeba podpůrné metody v Javě apod.

[xkucf03]

Slovník, do kterého si poukládáš ty classy a pak je dynamicky instancuješ

Já to pochopil tak, že to bude všechno jedna třída nebo několik málo tříd, ale budou různě naparametrizované. Jasně, mohl bys do té mapy naskládat vzorové instance a pak je klonovat. Ale ne vždy to bude jen prosté okopírování šablony – ta továrna toho může dělat víc.

Továrna je vlastně funkce, akorát ve formě abstrakce, třídy. Kdyby to byla funkce na úrovni jazyka, tak můžeš do té mapy nastrkat ty funkce. Ale co tím získáš? Budeš to moci definovat na jednom místě, v jednom souboru. Ale je to taková výhoda? Mně přijde, že spíš ne. Kód je stejně lepší rozdělit do víc souborů a nemít příliš dlouhé metody/třídy/soubory.

Nicméně tu mapu můžeš použít i v Javě. Můžeš tam mít metodu na hluboké kopírování[s použitím reflexe může být i univerzální – pro libovolné třídy; případně si můžeš zavést anotaci pro označení polí, která se nemají kopírovat nebo která se mají naplnit nějak jinak] ze šablony (vzorové instance). A v Javě 8 tam můžeš mít i ty funkce na úrovni jazyka a vše napsat do jednoho souboru (v předchozích verzích by to šlo taky, akorát bys to musel napsat jako anonymní vnitřní třídy).

[ehm]

Můžeš tam mít metodu na hluboké kopírování[s použitím reflexe může být i univerzální – pro libovolné třídy; případně si můžeš zavést anotaci pro označení polí, která se nemají kopírovat nebo která se mají naplnit nějak jinak] ze šablony (vzorové instance).

Možná by stačilo zneužít transient.

[JS1]

Ve skutecne funkcionalnim jazyce se misto tovaren da pouzit castecne vyhodnocovani. Nicmene je na to i funkce v Pythonu.

Neni to komplikovanejsi nez tovarna, jde o podobny princip. Rozdil je v tom, ze "castecne vyhodnocovani" je systematictejsi a obecnejsi koncept nez tovarna.

O kousek výše jsme si řekli, že Java je špatná, protože je tam těch abstrakcí moc a „programátoři přes všechny ty abstrakce neví, co se děje pod povrchem‟ (#589). Teď je naopak Java špatná, protože těch abstrakcí má málo.

To jsou dva ruzne problemy, prvni se tyka stylu programovani nekterych lidi v Jave, druhy navrhu Javy jako jazyka. To prvni je stejny problem, jako ten, na ktery si stezuji nekteri Javiste, ze by nastal u jazyka s lepsi moznosti abstrakce. Ale jak vidno, naduzivani abstrakci (v tomhle pripade trid a vzoru) lze provadet v kazdem jazyce.

Ten druhy problem spociva v tom, ze Java nektere vyssi abstrakce nedovoluje konstruovat, a tim by se kod znacne zjednodusil.

[kralyk z abclinuxu]

Klasický příklad na použití továren uvedl třeba Alexandrescu v Modern C++ design. Píšeš hru, kde máš jednotlivé entity a jejich chování popsané v třídách. Ty entity potřebuješ dynamicky spawnovat. Jejich konkrétní konfigurace ale může záviset třeba na zvolené obtížnosti. Pak lze místo hard-wiringu na každém místě v kódu, kde chceš tu entitu naspawnovat, volat jen tu továrnu.

Proč tohle neřeší konstruktor? Jaký je vůbec rozdíl mezi továrnou a konstruktorem? Přijde mi, že žádný.

[ehm]

WTF?! Nějak nevím, co na to říct.

[smazáno]

Z toho prikladu to neni uplne zrejme, ale, predpokladam, ze se jedna se o skupinu objektu, ktere musi byt "nakonfigurovane" zaroven - proto je tam potreba ta funkce, ktera ty objekty vytvori a vrati na ne nejaky ukazatel.

[smazáno]

Pro pochopeni primo toho "Factory Method" vzoru je potreba si uvedomit, ze GoF design patterns popisuji jak se psal software v 80-tych letech (vyslo '94).

[ehm]

Zároveň ne. Prostě to mají být nějaké instance s určitými vlastnostmi. Jestli je to jedna třída a v konstruktoru ji předáš třeba zvolenou obtížnost, nebo se jedná o úplně jiné třídy, je jedno – továrna má za úkol tohle izolovat a jen vrátit instanci nějakého typu. Je to pak soustředěné na jediné místo v kódu.

[kralyk z abclinuxu]

továrna má za úkol tohle izolovat a jen vrátit instanci nějakého typu

Jestli je to instance jednoho konkrétního typu, tak mi to přijde jako zakuklený konstruktor.

Jestli je to interface, tak pak se můžeme bavit o nějakém návrhu případně, ale na to by bylo potřeba znát konkrétní situaci. Nicméně definice "továrna = funkce, která něco udělá a vrátí nějaký objekt" mi přijde poměrně hodně vágní a v téhle podobně dost neužitečná.

[smazáno]

vsak jo

[ehm]

Zvláštní. V tom citovaném výroku mluvím jen o továrně. V textu se ti najednou nějak objevilo továrna = funkce.

[deda.jabko]

Jaký je vůbec rozdíl mezi továrnou a konstruktorem? Přijde mi, že žádný.

Konstruktor se ti postara ciste o explicitni vytvoreni objektu jedne konkretni tridy, tj. alokaci pameti a jeji inicializaci. Factory method muze delat vic veci, podle aktualni potreby.

Napriklad muze vytvaret instance ruznych trid implementujici stejne rozhrani, napr. podle dodanych parametru.

Dalsi caste pouziti je treba k eliminaci zbytecnych alokaci. Pokud zavolas new Integer(42), vzdy se ti alokuje novy objekt, pokud zavolas Integer.valueOf(42), muzes v dane metode rozhodnout, zda se bude alokovat novy objekt, nebo se vrati nejaka predchystana instance.

[xkucf03]

Zásadní rozdíl je v tom, že konstruktor musí napsat autor dané třídy, kdežto továrnu může napsat kdokoli jiný nezávisle na něm (třeba v rámci jiného projektu, knihovny, modulu…).

Další důležitý rozdíl je v tom, že můžeš mít jednu třídu a k ní více továren vytvářejících různě naparametrizované instance téže třídy; a ty továrny mají stejné rozhraní. To s konstruktorem neuděláš, protože konstruktorů můžeš mít sice víc, ale musíš je odlišit typem/počtem parametrů.

A taky můžeš mít továrnu, která vrací instance různých tříd, podle toho, co je zrovna potřeba, ale všechny implementují stejné rozhraní – to s konstruktorem taky neuděláš.

Továrna je vlastně funkce a odkaz na továrnu si můžeš předávat do jiných částí programu – můžeš tam předávat různé továrny implementující stejné rozhraní. To s konstruktorem neuděláš (v Javě 8 se na něj dá odkázat přes ::, ale musí se ti ty konstruktory lišit v parametrech – a navíc, jak jsem psal na začátku, konstruktor může napsat jen autor třídy).

BTW: je zajímavé, jak se příznivci funkcionálního programování často navážejí do návrhového vzoru továrna – přitom je to jen způsob zápisu funkce. Asi v tom vidí konkurenci :-)

[ehm]

Jde i o závislosti. Je čistější, aby LevelGenerator závisel na EntityFactory než na Configuration s konfigurací celé aplikace, z té si přečetl hodnotu difficulty a s tou pak pracoval (posílal jí jako argument konstruktoru, větvil se podle ní atp.).

Ta továrna prostě může být objekt, který ví, jakou instanci zkonstruovat a s jakými argumenty. Tenhle objekt lze vytvořit někde na vyšší úrovni aplikace a pak ho jen předat na patřičné místo. Krásně se to kombinuje třeba s DI.

Je to lepší zapouzdření než někde předávat hodnotu, se kterou se jinak vůbec nepracuje a jen se to někde předává do konstruktoru. Významně přispěje čitelnosti kódu se té hodnoty zbavit.

[kralyk z abclinuxu]

Jde i o závislosti. Je čistější, aby LevelGenerator závisel na EntityFactory než na Configuration s konfigurací celé aplikace, z té si přečetl hodnotu difficulty a s tou pak pracoval (posílal jí jako argument konstruktoru, větvil se podle ní atp.).

Pokud LevelGenerator nemá mít závislost na celé konfiguraci, pak by konfigurace neměla být celá v jednom konfiguračním God objektu a měl by existovat nějaký objekt držící podmnožinu konfigurace relevantní pro LevelGenerator ... což by ve výsledku byl nejspíše v podstatě ekvivalent toho EntityFactory, akorát s jasnějším, méně gof-kargo-kultovním názvem...

Je to lepší zapouzdření než někde předávat hodnotu

Proč mají javisti neustále fobii z toho, že by něco někde mohlo nebýt za minimálně třemi šlupkami zapouzdření? Pomohl by Lexaurin?

[xkucf03]

Pokud LevelGenerator nemá mít závislost na celé konfiguraci, pak by konfigurace neměla být celá v jednom konfiguračním God objektu a měl by existovat nějaký objekt držící podmnožinu konfigurace relevantní pro LevelGenerator

A co ti pořád vadí na tom továrním/funkcionálním/DI přístupu, kde předáš funkci/továrnu, místo abys předal jen data (konfiguraci, část konfigurace)?

Proč mají javisti neustále fobii z toho, že by něco někde mohlo nebýt za minimálně třemi šlupkami zapouzdření?

Není to fóbie, jde o lepší a pružnější návrh, který ti umožňuje, aby každá komponenta dělala pokud možno jednu věc, nebo několik málo věcí, patřících k sobě, a zbytek delegovala na ostatní. V tomhle případě je jedna třída (nebo množina tříd se společným rozhraním) zodpovědná za vytváření nějakých instancí na základě konfigurace a jiná třída je zodpovědná za to, kdy k tomu vytváření dojde a co se s vytvořeným objektem bude dít dál. A jiná třída je zodpovědná za načtení konfigurace ze souboru (nebo třeba její vygenerování na základě nějakého algoritmu – od toho ostatní abstrahují a je jim jedno, jak ta konfigurace vznikla) a další třída/komponenta je zodpovědná za to, aby to pospojovala a předala třeba tu továrnu té třídě, která potřebuje vytvářet instance.

Klíčová slova: DI, IoC

[kralyk z abclinuxu]

A co ti pořád vadí na tom továrním/funkcionálním/DI přístupu, kde předáš funkci/továrnu, místo abys předal jen data (konfiguraci, část konfigurace)?

Ale ono ve výsledku to je v podstatě to samé. Jestliže pro vytáření instancí entit potřebuješ data z konfigurace, tak stejně ve výsledku se tam budou muset nějak dostat. Jestliže EntityFactory bude obsahovat nějaká data z konfigurace, která potřebuje k vytváření entit, co jiného to je, než třída držící subset konfigurace? A jestli potom nechám tu třídu generovat nějaké instance nebo ji předám do nějaké funkce nebo konstruktoru - to mi přijde jako dost nepodstatný detail.

Jinými slovy, co mi vadí na "továrnách" a dalších design patternech je to, že přesunují pozornost z obsahu na formu. Než mi zas někdo vytkne, že mi nezáleží na formě: Ano, samozřejmě, nějká štábní kultura je potřeba, ale přijde mi, že disgn-patternový vývoj je příliš extrémně zaměřen na formu na úkor obsahu.

Je dost možné, že bych to třeba ve výsledku technicky vzato naprogramoval stejně, jen bych použil jiné názvy (nevím, to by záleželo na konkrétní situaci). Ale už to mi přijde podstatné. Dávat věcem do názvu věci jako "Factory" nebo "Singleton" mi přijde podobně švihlé, jako kdybych každý proměnný do názvu přidal suffix "Variable" a šel celému patru hrdě oznámit, že používám design patterny - variables.

Není to fóbie, jde o lepší a pružnější návrh, který ti umožňuje, aby každá komponenta (...)

Ano, to je standardní poučka o zapouzdření. Zapouzdření samozřejmě je užitečné a používám ho každou chvíli. Opět ale jde o rozumnou míru a o to, že není nutné prosazovat dogmaticky jednu poučku 100% všude. Občas prostě je na místě předat holý data. Kdyby Java tak fanaticky neprosazovala zapouzdření, mohla třeba mít POD typy a kontejnery pro primitivní a POD typy.

[ehm]

Je dost možné, že bych to třeba ve výsledku technicky vzato naprogramoval stejně, jen bych použil jiné názvy (nevím, to by záleželo na konkrétní situaci). Ale už to mi přijde podstatné. Dávat věcem do názvu věci jako "Factory" nebo "Singleton" mi přijde podobně švihlé, jako kdybych každý proměnný do názvu přidal suffix "Variable" a šel celému patru hrdě oznámit, že používám design patterny - variables.

OMG. Z čeho zase dedukuješ, že o použití design patternu se jedná jen a právě tehdy, kdy jméno patternu zakóduješ do identifikátoru? Samotný design pattern a jmenné konvence jsou dvě úplně nezávislé věci. Pro mě za mě si to můžeš místo EntityFactory pojmenovat klidně EntityInstanceCreator, nebo nějakým jiným názvem, který co nejsrozumitelněji popisuje, co daný interface/třída dělá.

[xkucf03]

Ale ono ve výsledku to je v podstatě to samé. Jestliže pro vytáření instancí entit potřebuješ data z konfigurace, tak stejně ve výsledku se tam budou muset nějak dostat. Jestliže EntityFactory bude obsahovat nějaká data z konfigurace, která potřebuje k vytváření entit, co jiného to je, než třída držící subset konfigurace?

Rozdíl je v tom, že třída volající továrnu nemusí vůbec vědět, že nějaká konfigurace existuje. Tahle třída závisí na rozhraní továrny a navenek poskytuje rozhraní pro injektování továrny. Znamená to pružnější kód, univerzálnější komponenty, které lze používat různými způsoby, aniž bys je musel uvnitř měnit. Jedním z těch způsobů je i testování.

Je to stejný důvod, jako proč používáš třeba souborový systém, místo abys pracoval přímo s blokovým zařízením. Nebo proč třeba příkaz (v rouře) čte data ze standardního vstupu a zapisuje na standardní výstup, místo aby pracoval se soubory v napevno zadrátovaných cestách. Takhle může být vstupem a výstupem soubor, ale třeba i síť (např. přes socat) nebo obecně jiný proces, nebo terminál uživatele.

[kralyk z abclinuxu]

Rozdíl je v tom, že třída volající továrnu nemusí vůbec vědět, že nějaká konfigurace existuje. Tahle třída závisí na rozhraní továrny a navenek poskytuje rozhraní pro injektování továrny. Znamená to pružnější kód, univerzálnější komponenty

Může to znamenat pružnější kód. Problém s tímhle příkladem je, že nevíme kontext. Pokud to má být třeba nějaký herní framework a tyhle věci jsou součástí API, pak ano, může mít smysl ten tlak na komposabilitu a univerzálnost. Pokud jsou to njěaké útroby, které reálně nikdo nijak drasticky odlišným způsobem nebude nikdy používat, pak mi to přijde jako nesmyslná obfuskace a zamlžování toho, co se tam ve skutečnosti děje.

Prostě předčasná abstrakce (nebo jak to nazvat) je podobně negativní jako předčasná optimalizace. Nejednou jsem viděl / zažil na projektu, že ačkoli bylo něco navrženo takhle abstrahovaně a decouplovaně, tak se tam vlivem pouze jednoho způsobu použití stejně časem dostaly nějaký předpoklady a později už to stejně nešlo použít obecně. Anebo se tam sice žádné konkrétní předpoklady nevloudily, ale stejně se to později muselo předělat, protože prostě to obecně použití bylo ještě o něco jiné, nez původní autor předpokládal.

Jedním z těch způsobů je i testování.

Zrovna v tomhle případu mi to odůvodnění testováním nepřijde smysluplné. Konfigurace je snad jedna z vůbec nejsnazších věcí na mockování. Další věc je, že používání těch věcí v testech by mělo být pokudmožno co nejpodobnější reálnému použití.

Je to stejný důvod, jako proč používáš třeba souborový systém, místo abys pracoval přímo s blokovým zařízením. Nebo proč třeba příkaz (v rouře) čte data ze standardního vstupu a zapisuje na standardní výstup, místo aby pracoval se soubory v napevno zadrátovaných cestách.

To jsou všechno extrémně veřejná a obecná rozhraní.

[ehm]

Kontext víme. Vysvětloval jsem ti ho několikrát.

[kralyk z abclinuxu]

Jó, jasný, pro tebe všechno

[ehm]

A nevysvětloval snad? Situace byla jasně popsaná. Fakt, že ty to kvůli psychickému traumatu z dob studií nejsi schopen vidět, je záležitost spíše pro psychologickou poradnu, nikoliv technickou diskuzi.

[kralyk z abclinuxu]

A nevysvětloval snad? Situace byla jasně popsaná.

O té situaci nevim skoro nic, např. nevim, jak moc jsou ty popsané třídy/interfacy veřejné/privátní, jak moc bude potřeba s tím šibovat dobudoucna, co je zač ta konfigurace, co vlastně je/není potřeba pro vytváření těch entit atd. Jen tak jsi napsal, že LevelGenerator nesmí záviset na Configuration bez jakéhokoli vysvětlení - tím nechci říct, že to nutně není pravda, ale bez dalšího to nemůžu posoudit. Taky nebylo vysvětleno, proč je konfigurace celé aplikace v jednom objektu - to mi zní jako návrhová chyba a následná potřeba vytvoření factory toho může být jen důsledek. Anebo taky ne - to opět nemůžu bez dalšího posoudit. Stejně tak jsi později jentak mimochodem zmínil, že v testech není možný EntityFactory vytvářet stejně jako ve vlastním programu, takže to bude muset být interface, zase zcela bez vysvětlení. Přitom třeba vytvoření konfigurace v testech by určitě mělo být možné.

TL;DR bez nějakého big picture byla následující diskuse řešení kravin a vaření z vody. Další věc je, že jsi ten příklad citoval z Alexandresca, čili C++, tam ten design nebude to samé co v Javě.

[ehm]

To zase překrucuješ. Já nenapsal, že LevelGenerator nesmí záviset na konfiguraci, ale že by neměl, pokud ji k ničemu jinému nepotřebuje. Jak s tím souvisí, jestli konfigurace je nebo není v jednom objektu, taky nechápu a řeč o tom nikde nebyla.

Je úplně jedno, jestli tam budu předávat celou konfiguraci jako jediný objekt, nebo z ní vyzobu pár hodnot a ty budu předávat dál. Pokud LevelGenerator má na starosti třeba jen samotnou logiku generování herního světa a rozmisťování entit po mapě, tak je mu úplně ukradené, jakou má hráč zvolenou obtížnost. Tedy dává větší smysl předat mu továrnu, která ty instance vyrobí – a její logika je zcela zapouzdřená a oddělená – než mu předat jednu hodnotu, která se někde uloží do fieldu a pak si tam psát nějakou metodu, která se podle toho fieldu rozhodne, jakou instanci vytvořit. Taková logika tam totiž vůbec nepatří, komplikuje to testování apod.

Zcela mylně předpokládáš, že kdyby bylo možné tu konfiguraci namockovat v testech, tak by to nebyl problém. Naprosto ti uniká skutečnost, že tohle není ten problém – problém je, že mi do testu bude vstupovat dodatečná komplexita, kterou se tam vůbec nechci zaobírat (tj. která konkrétní instance je vyrobena chci testovat někde úplně jinde), a že tu skutečnou logiku, kterou chci testovat, možná ani nebudu mít jak otestovat, nebo to bude těžší. Třeba místo toho, abych testu podvrhl speciální továrnu, která bude vracet mocky (a nad těmi si ověřil, že je třeba prováděno umístění na správnou pozici apod.), tak budu vytvořené entity lovit z nějaké vnitřní datové struktury, která ty entity obsahuje. Ta struktura na operaci „vrať mi všechny naspawnované entity v tom pořadí, v jakém byly naspawnovány“ vůbec nemusí být optimalizována (a to zachování pořadí nemusí podporovat vůbec).

A na kontextu to záleží mnohem míň než si myšlíš – daleko víc to poukazuje tvojí nezkušenost. Jinak bys totiž takové případy viděl a z toho popisu a dodatečných indícií, co jsem hodil v diskuzi, se okamžitě rozhodl pro továrnu, protože objem napsaného kódu bude úplně stejný a zcela jistě to přispěje lepšímu rozdělení do logických celků a testovatelnosti. Použití továrny je tady úplně samozřejmé, bez ohledu na to, jestli to okamžitá situace nutně vyžaduje, nebo ne.

Domnívat se, že se situace s tímto konkrétním design patternem nějak dramaticky liší mezi Javou a C++, je jen další ukázkou tvojí neznalosti a neschopnosti.

[xkucf03]

Tedy dává větší smysl předat mu továrnu, která ty instance vyrobí – a její logika je zcela zapouzdřená a oddělená – než mu předat jednu hodnotu, která se někde uloží do fieldu

Nevím, jestli to tu už padlo, ale: ta hodnota se může měnit. A v případě funkce/továrny můžeš tu změnu lépe řídit. A pokud bude potřeba něco na chvíli zamknout kvůli atomicitě a vícevláknovému přístupu, tak to bude jednodušší/proveditelnější, než když budeš mít po celém programu rozstrkané reference na (v horším případě kopie) datové struktury.

[kralyk z abclinuxu]

A pokud bude potřeba něco na chvíli zamknout kvůli atomicitě a vícevláknovému přístupu, tak to bude jednodušší/proveditelnější, než když budeš mít po celém programu rozstrkané reference na (v horším případě kopie) datové struktury.

K tomu zamýkání si neodpustim poznámku: Tohle je tak trochu "výchozí přístup" - Chci vícevláknovost? Použiju zámky! Přitom málokdo si uvědomí, že zámek jde vlastně proti vícevláknovému přístupu. Použití zámků může do značné míry zredukovat nebo úplně zazdít benefit vláken.

V Javě mi MT programování přijde jako dost mizérie. Jazyk jako takový pro vícevláknové programování neposkytuje snad vůbec nic, naopak jde spíše proti vláknové bezpečnosti, např. tím, že tě nutí předávat všade mutabilní reference a nemůžeš jinak, nemůžeš předat hodnotu nebo immutabilní referenci. Když chceš immutable object, tak musíš tu třídu tak napsat.

Tyhle problémy jsou v Javě kompenzované ve standardní knihovně, která IIRC poskytuje nějaké pěkné mechanismy, ale tam to zas naráží na to, že lidé si často neuvědomují, že zámky jsou kolikrát spíše berlička, někdy i škodlivá, a třeba vůbec neví nebo neřeší, že mezi např. SynchronizedHashMap a ConcurrentHashMap je významný rozdíl.

Nicméně ten default se zámky určitě není specifikum Javy, v ostatních jazycích to je dost podobné, akorát v některých je to lepší v tom, že podporují immutabilitu.

[kralyk z abclinuxu]

s/SynchronizedHashMap/synchronizedMap/

[ehm]

Předávání immutable objektů se typicky řeší nějakou proxy (viz třeba Collections.unmodifiableMap). V podstatě to odpovídá tomu, co říkáš: musíš tu třídu (nebo nějaký wrapper nad ní) tak napsat.

Na druhou stranu moc nevím, jak by to mělo fungovat jinak. Zakázat jazykem volat nad immutable objektem metody se side-effectem? Tj. pokud předáš objekt jako immutable, jazyk do hloubky zkontroluje, že volání té které metody nikdy nevyústí ve změnu nějakého fieldu apod.?

Z hlediska výkonu by to dávalo smysl – nebylo by potřeba vytvářet proxy. Z hlediska statické analýzy by to taky bylo výhodnější, protože třeba ta unmodifiableMap prostě vyhazuje výjimku za běhu – nekontroluje se to v čase kompilace.

Na druhou stranu nevím, jak užitečné by to bylo, a jestli to vlastně dává smysl. V praxi totiž řada volání side-effect má, nebo mít může, a jen programátor dokáže posoudit, zda je to v pořádku (to mluvím o případě, kdy ten side-effect je mimo ten daný objekt). Omezit to jen na změny uvnitř objektu mi nepřijde smysluplné, protože to řeší jen minimum případů (tj. stejně tu třídu musíš tak napsat; co naplat, že ti jiný thread nemůže uvnitř objektu změnit fieldy, když může zavolat metodu, která volá nějaký callback, kterému předává this, a v důsledku to změnu do toho objektu stejně propíše, jen nepřímo?).

Jak by sis to představoval?

[kralyk z abclinuxu]

Na druhou stranu moc nevím, jak by to mělo fungovat jinak. Zakázat jazykem volat nad immutable objektem metody se side-effectem? Tj. pokud předáš objekt jako immutable, jazyk do hloubky zkontroluje, že volání té které metody nikdy nevyústí ve změnu nějakého fieldu apod.?

Ano, takhle to funguje s const referencemi v C++, Rustu, D (?) a podobných jazycích. Funguje to tak, že když máš const referenci (nebo poitner) a zalováš metodu, ta metoda dostane parametr this jakožto const. Metody jsou dvojího typu: const a mutable (což je default). Pochopitelně mutabilní reference automaticky konvertuje na const referenci, ale obráceně to nejde (resp. ne bez násilného přetypování nějakým způsobem - třeba const_cast v C++). Takže z const metod můžeš volat zase jenom const metody a k this (tj. i ke všem fieldům) máš jen const přístup.

Bohužel ovšem konkrétně v C++ (narozdíl od D, Rustu,...) tohle nefunguje dokonale - constness není transitivní pro pointery. Takže u member pointeru s const přístupem je to bohužel podobně jako s javovskou final referncí a smart pointery ve standardní knihovně to IIRC bohužel mají takhle taky, akočli se dá vytvořit i smart pointer, který respektuje constness transitivně.

mezit to jen na změny uvnitř objektu mi nepřijde smysluplné, protože to řeší jen minimum případů (tj. stejně tu třídu musíš tak napsat; co naplat, že ti jiný thread nemůže uvnitř objektu změnit fieldy, když může zavolat metodu, která volá nějaký callback, kterému předává this, a v důsledku to změnu do toho objektu stejně propíše, jen nepřímo?).

Pokud má ten thread pouze const referenci, tak member metodám nebo komukoli dalšímu může předat zase jenom const referenci. (Samozřejmě pokud nepoužije nějaký ten const_cast nebo něco podobného.)

Rust jde v tomhle ještě dále a například pokud na nějaký data nebo objekt vytvoříš mutabilní referenci, tak ti nedovolí vytvořit referenci další (ať už mutabilní nebo const), dokud ta první "žije". Const referencí si můžeš vytvořit kolik chceš, ale opět pak zase nemůžeš vytvořit mutabilní referenci, dokavaď veškeré ostatní referce "žijou". Tímhle způsobem zaručuje Rust thread safety staticky při compile-time.

[ehm]

Ano, takhle to funguje s const referencemi v C++, Rustu, D (?) a podobných jazycích.

To je pravda vlastně. Zapomněl jsem, že C++ to tak má.

[xkucf03]

Chci vícevláknovost? Použiju zámky! Přitom málokdo si uvědomí, že zámek jde vlastně proti vícevláknovému přístupu. Použití zámků může do značné míry zredukovat nebo úplně zazdít benefit vláken.

Souhlasím, že by bylo fajn mít (spolehlivou) podporu pro neměnné objekty v jazyce. Nicméně to řeší jen poměrně malé množství případů – pak máš spoustu případů, kdy objekty z principu neměnné nejsou, občas se jejich stav mění a ty potřebuješ nějak koordinovat vlákna, aby k objektům nepřistupovala v nevhodnou dobu, aby změny byly atomické nebo respektovaly nějaká pravidla, která sis stanovil… a tam se bez nějaké formy zámků neobejdeš. Ty zámky můžou být schované za nějakou abstrakcí, ale pořád tam kdesi uvnitř jsou – aby pozastavily nějakou činnost, dokud neskončí jiná, protože obě najednou z podstaty zadání probíhat nemohou.

Dobře použitý zámek vstupuje do hry jen na minimální nutnou dobu – všude jindy pracuje více vláken vesele současně, takže to nic proti vícevláknovému programování není (naopak ho to umožňuje).

[kralyk z abclinuxu]

pak máš spoustu případů, kdy objekty z principu neměnné nejsou, občas se jejich stav mění a ty potřebuješ nějak koordinovat vlákna, aby k objektům nepřistupovala v nevhodnou dobu, aby změny byly atomické nebo respektovaly nějaká pravidla, která sis stanovil… a tam se bez nějaké formy zámků neobejdeš.

To není tak úplně pravda. Viz lock-free datové struktury - existují například různé fronty, stacky i hashmapy, které jsou vláknově bezpečné, ale přitom nepoužívají žádný zámek, jsou založené pouze na atomických operacích nad číselnými typy (vč. pointerů) a nad nimi dělají všelijaké chytré věci, aby zajistili thread-safety. Např. Michael-Scott Queue a další.

IMHO ve většině případů by ses teoreticky vzato obešel bez zámku i v případě mutability dat, ale obvykle naimplementovat to tím lock-free přístupem je mnohem náročnější, navíc kolikrát by ten benefit byl malý nebo žádný, takže často se prostě použijou zámky. Což je v pořádku. Ale jindy je zase lepší se zamyslet nad lock-free řešením. (Nedávno jsem např. řešil kontejner, do kterého se dávají objekty a on je drží pod unikátním číselným ID, pomocí kterýho se k nim dá později přistupovat, trochu jako hashmapa, ale zároveň trochu jako fronta, protože každý ten objekt je po nějaký chvíli odebrán. Při přechodu na lock-free implementaci, tj. vložení, přístup a vyjmutí bez zámku, se zvýšil výkon programu o desítky procent.)

[kralyk z abclinuxu]

Je úplně jedno, jestli tam budu předávat celou konfiguraci jako jediný objekt, nebo z ní vyzobu pár hodnot a ty budu předávat dál. Pokud LevelGenerator má na starosti třeba jen samotnou logiku generování herního světa a rozmisťování entit po mapě, tak je mu úplně ukradené, jakou má hráč zvolenou obtížnost.

Souhlasím, že pokud LevelGenerator nepotřebuje konfiguraci, nevidím důvod pro to tlačit do něj konfiguraci. Naproti tomu pokud generování entit je součástí výlučně generování levelů a je k tomu potřeba konfigurace, pak by ale mohlo mít smysl nechat LevelGenerator mít přístup ke konfiguraci a předávat jí (nebo subset) třeba někam hloub - na tom mi nepřijde nic špatného, zejména pokud by to mělo být tak, že generování entit je nějaká vnitřní privátní záležitost LevelGeneratoru, do které nemá okolní svět co kecat. Na druhou stranu pokud generování entit je obecnější / mělo by být odděleno od LevelGeneratoru (který už jen entity rozmisťuje), pak dává větší smysl návrh, jaký jsi podal ty (nebo podobný).

Můžeš na mě řvát jak chceš, že jsem debil a že tohle není důležité, mně to ale důležité připadá. Vždy chci znát big picture. Klidně to ber pro mě za mě jako negativum.

než mu předat jednu hodnotu, která se někde uloží do fieldu a pak si tam psát nějakou metodu, která se podle toho fieldu rozhodne, jakou instanci vytvořit

S tím souhlasím, ale něco takového jsem ani nenavrhoval a krom toho, to ani nemá nic moc společného s nějakými patterny, to je prostě jen smysluplné rozdělení kódu do různých tříd / celků, resp. necpaní veškerého kódu na jedno místo.

Zcela mylně předpokládáš, že kdyby bylo možné tu konfiguraci namockovat v testech, tak by to nebyl problém. (...)

Tady vůbec nevidím, jak tenhle odstavec souvisí s tím, co jsem napsal, myslím, že jsme se minuli / mluvíme o něčem jiném.

A na kontextu to záleží mnohem míň než si myšlíš – daleko víc to poukazuje tvojí nezkušenost. Jinak bys totiž takové případy viděl a z toho popisu a dodatečných indícií, co jsem hodil v diskuzi, se okamžitě rozhodl pro továrnu

Njn a jsme u toho návrhového fašismu - buď se tady rozhodneš pro tovránu, nebo jsi blb. Good job. Absolutní absence nějakého nadhledu - ostatně jako ve většině tvých komentářů.

Domnívat se, že se situace s tímto konkrétním design patternem nějak dramaticky liší mezi Javou a C++, je jen další ukázkou tvojí neznalosti a neschopnosti.

Hele nemohl by ses vrátit k tomu "seš prostě debil"? Pro mě to je mnohem snažší v textu rozeznat a odfiltrovat.

[ehm]

Naproti tomu pokud generování entit je součástí výlučně generování levelů a je k tomu potřeba konfigurace, pak by ale mohlo mít smysl nechat LevelGenerator mít přístup ke konfiguraci a předávat jí (nebo subset) třeba někam hloub - na tom mi nepřijde nic špatného, zejména pokud by to mělo být tak, že generování entit je nějaká vnitřní privátní záležitost LevelGeneratoru, do které nemá okolní svět co kecat.

Tak jistě, že není těžké ten příklad přiohnout tak, aby najednou továrna přestala dávat smysl.

Všimni si, že celý tenhle subthread vznikl v reakci na údajně nesmyslné abstrakce příkladem, kde dává smysl ty továrny použít. Tu situaci jsem IMO popsal dostatečně přesně – neočekávej, že začnu doopravdy vyvíjet nějakou hru jen proto, abych tam demonstroval korektní užití továren v celém „big picture“.

S tím souhlasím, ale něco takového jsem ani nenavrhoval a krom toho, to ani nemá nic moc společného s nějakými patterny, to je prostě jen smysluplné rozdělení kódu do různých tříd / celků, resp. necpaní veškerého kódu na jedno místo.

Tak společného to má, protože pokud je za vytvářením objektů nějaká logika, tak továrna to zapouzdřuje a odděluje. Myslím, že jsem to tu už taky někde zmiňoval.

Tady vůbec nevidím, jak tenhle odstavec souvisí s tím, co jsem napsal, myslím, že jsme se minuli / mluvíme o něčem jiném.

Takto:

Přitom třeba vytvoření konfigurace v testech by určitě mělo být možné.

V komentářích výše jsi měl podobné námitky (konfigurace jako jeden God objekt, nemožnost ji namockovat v testech apod.).

Njn a jsme u toho návrhového fašismu - buď se tady rozhodneš pro tovránu, nebo jsi blb. Good job. Absolutní absence nějakého nadhledu - ostatně jako ve většině tvých komentářů.

Pokud chceš nedodržování best practices považovat za věc názoru, tak prosím. Design patterny nejsou nic jiného než standardní a osvědčená řešení určitých problémů. Nevidím pointu v tom do toho hnípat stylem: „No, jo, ale když tohle a tamto, tak se to nehodí.“.

To uvažování je totiž přesně opačné. U design patternů neřešíš, kdy je nepoužít, ale kdy je použít. A ten můj příklad jsem nakonec zkonkretizoval fakt tak přesně, že ta továrna je tam úplně samozřejmá (viz testovatelnost – zmiňoval jsem už třeba v #1056 a následně ještě doplnil).

Můžeme se bavit, při jaké nejmenší změně výchozích podmínek by už použití továrny nedávalo smysl, ale má taková diskuze nějaký smysl? Smysl a výhody továrny jsou tak nějak patrné z těch situací, kdy to dává smysl. Pokud použití továrny žádné výhody nepřidává, no tak to asi smysl nedává. To je celé.

Hele nemohl by ses vrátit k tomu "seš prostě debil"?

Zkus hádat, proč jsem ti to v #1128 napsal. Malá nápověda:

Chceš veškeré tradiční konstruktory teď převést na statické member funkce? Popravdě, divím se, že javisti už tohle dávno neudělali vzhledem k té obsesi se skrýváním implementace a rozšiřitelností dobudoucna úplně všeho včetně babiččiných papučí.

[kralyk z abclinuxu]

Tak jistě, že není těžké ten příklad přiohnout tak, aby najednou továrna přestala dávat smysl.

Všimni si, že celý tenhle subthread vznikl v reakci na údajně nesmyslné abstrakce příkladem, kde dává smysl ty továrny použít. Tu situaci jsem IMO popsal dostatečně přesně – neočekávej, že začnu doopravdy vyvíjet nějakou hru jen proto, abych tam demonstroval korektní užití továren v celém „big picture“.

Tak to samozřejmě ne, já jsem se v podstatě jen snažil přemýšlet, jak můžu interpretovat to zadání, protože mi to moc jednoznačné nepřišlo, pokud ti to přišlo jak překrucování, tak to je možné, ale nebylo to schválně.

[ehm]

OK.

Ještě chci opravit jednu věc, kterou jsem tam uvedl chybně. Napsal jsem, že design patterny jsou standardní a osvědčená řešení určitých problémů. Tu druhou část beru zpět.

Třeba singleton je totiž úplně validní design pattern a dokonce bych řekl, že nejznámější design pattern vůbec, ale přitom je v naprosté většině případů (resp. mnohem častěji než si většina jeho uživatelů uvědomuje) současně považován za návrhovou chybu – anti-pattern, chcete-li.

[xkucf03]

Prostě předčasná abstrakce (nebo jak to nazvat) je podobně negativní jako předčasná optimalizace.

Viz můj předchozí komentář:

Já se řídím dost i podle toho, jak moc je daný kód vidět navenek – pokud je zapouzdřený, tak klidně zvolím jednodušší/omezenější řešení, protože vím, že si to můžu v případě potřeby kdykoli refaktorovat a vylepšit, aniž by to mělo negativní dopady na ostatní.

[kralyk z abclinuxu]

Jj, to mi připadá dobré.

[ehm]

Pokud LevelGenerator nemá mít závislost na celé konfiguraci, pak by konfigurace neměla být celá v jednom konfiguračním God objektu a měl by existovat nějaký objekt držící podmnožinu konfigurace relevantní pro LevelGenerator ... což by ve výsledku byl nejspíše v podstatě ekvivalent toho EntityFactory, akorát s jasnějším, méně gof-kargo-kultovním názvem...

Stále jsi to nepochopil. Já nechci LevelGeneratoru předávat konfiguraci, kterou tam jinak nepotřebuji, jen proto, abych to následně předával do konstruktoru (nebo se podle toho větvil). Pokud najednou spawnování entit začne záviset na další konfigurační hodnotě, tak začnu do celého toho řetězce přidávat další hodnotu? A nebo to udělám jen na vyšší úrovni té aplikace, kde si vytvářím tu továrnu?

Psaní testů je další věc. V jednom případě můžu LevelGeneratoru podstrčit namockovanou továrnu a jednoduše si ověřit, že za určitých podmínek dojde k naspawnování entity, zatímco ve druhém případě si můžu leda tak utřít prdel, protože najednou stojím v situaci, že někde v útrobách aplikace má vznikat objekt, a já fakt nemám jak to čistě ověřit.

Ale tak můžete si dál bastlit nějaká svoje hovna, mně je to fakt už jedno. Vůbec nechápu, proč takovéhle věci musím vysvětlovat profesionálnímu programátorovi.

Proč mají javisti neustále fobii z toho, že by něco někde mohlo nebýt za minimálně třemi šlupkami zapouzdření?

Naser si.

[kralyk z abclinuxu]

Stále jsi to nepochopil. Já nechci LevelGeneratoru předávat konfiguraci, kterou tam jinak nepotřebuji, jen proto, abych to následně předával do konstruktoru (nebo se podle toho větvil). Pokud najednou spawnování entit začne záviset na další konfigurační hodnotě, tak začnu do celého toho řetězce přidávat další hodnotu? A nebo to udělám jen na vyšší úrovni té aplikace, kde si vytvářím tu továrnu?

Určitě nejsem pro větvit někde v tom LevelGeneratoru a tím tam přidávat kód, který patří jinam. Co se týče předávání konfigurace podotýkám - stejně jako Frantovi - že tím, že LevelGenerator vlastní tu EntityFactory, v podstatě stejně vlastní kus konfigurace a každý to ví. Nejsem proti zabalit ten kus konfigurace do samostatného objektu, z kterého nebo pomocí kteréhu si budu generovat nějaký další objekty, jenom mi to nepřijde jako tak zásadní rozdíl. IMHO klidně můžeš na začátku jeden konfigurační parametr předávat přímo a následně, když zjistíš, že jich potřebuješ víc, to refaktorovat do toho samostatného objetku (ať už to bude továrna, nebo ne), vzhledem k tomu, že se to týká jen dvou tříd použitých vedle sebe v interních útrobách (není to zřejmě žádné veřejné API).

Tohle je přesně stejný jako ta premature optimization u C++ programátorů, akorát javisti mají místo toho premature design a decouplují a zapozdřují úplně všechno, i když to nemá praktický výsledek. Javovské zdrojáky pak jsou plné getterů a setterů, které už 20 let nemají žádné chování a dalších 20 let taky nebudou mít, jen nastavují/vrací hodnotu přímo, ale musí tam být, protože autor by se jinak v noci budil hrůzou co by se stalo, kdyby někdy někdo ve vzdálené hypotetické budoucnosti náhodou chtěl přidat nějaké chování.

[ehm]

A používání továren za každou cenu to zas prosazuje kdo? Bystroushaak si tu ublinknul, že:

Programátoři v jazycích nižší úrovně pak tu abstrakci vybudují například návrhovými vzory a továrnami továren, takže jí musíš nastudovat a pochopit úplně stejně, jen něčím desetkrát víc ukecaným.

Já na to reagoval s tím, kde a proč se továrny používají. To je zas nějaká tvoje projekce, že tu prosazujeme používání továren při sebemenší příležitosti.

Pak píšeš, že:

Co se týče předávání konfigurace podotýkám - stejně jako Frantovi - že tím, že LevelGenerator vlastní tu EntityFactory, v podstatě stejně vlastní kus konfigurace a každý to ví.

Což není pravda a vysvětloval jsem ti to výše v souvislosti s testováním.

[Bystroushaak]

A používání továren za každou cenu to zas prosazuje kdo? Bystroushaak si tu ublinknul, že:

Já jsem náhodou spokojen.

[ehm]

Já vim.

[JS1]

To by bylo, abychom neprekonali cirkevni restituce!

[kralyk z abclinuxu]

Já na to reagoval s tím, kde a proč se továrny používají.

Ok, beru.

To je zas nějaká tvoje projekce, že tu prosazujeme používání továren při sebemenší příležitosti.

Ne tak úplně, s bezhlavým aplikováním dizajn patternů jsem se bohužel dříve hodně setkával, zejména při pracích při studiu. A téhle diskusi už k tomu taky došlo - Franta navrhoval továrny v tom příkladu s tou sortovací funkcí. Ale beru, že zrovna u tebe to nejspíše tak nebude.

Což není pravda a vysvětloval jsem ti to výše v souvislosti s testováním.

Nerozumím, pokud to správně chápu, ta EntityFactory potřebuje obsahovat nějaká data na základě kterých se rozhoduje, kterou instanci a s jakými parametry vytvořit. Měl jsem za to, že to jsou data z konfigurace.

[ehm]

Ne tak úplně, s bezhlavým aplikováním dizajn patternů jsem se bohužel dříve hodně setkával, zejména při pracích při studiu.

Já se s tím samozřejmě setkal taky, ale to neznamená, že je špatný ten pattern. Špatné je to použití.

Nerozumím, pokud to správně chápu, ta EntityFactory potřebuje obsahovat nějaká data na základě kterých se rozhoduje, kterou instanci a s jakými parametry vytvořit. Měl jsem za to, že to jsou data z konfigurace.

EntityFactory by v takovém případě bylo jen rozhraní. Implementace v produkčním kódu by se řídila konfigurací, zatímco mock v testu na konfiguraci záviset vůbec nemusí.

[kralyk z abclinuxu]

EntityFactory by v takovém případě bylo jen rozhraní. Implementace v produkčním kódu by se řídila konfigurací, zatímco mock v testu na konfiguraci záviset vůbec nemusí.

Ok, to beru, nicméně doufám, že tohle je vymyšlený příklad a nedělal bys to takhle složitě, pokud by skutečně nebylo z nějakéhu důvodu striktně potřeba testovat EntityFactory bez konfiguračního objektu. Možná ti přijde paranoidní, že se takhle ptám, ale jsou lidi, kteří by to klidně takhle nadesignovali čistě pro to, že někdy v hypotetické budoucnosti by to teoreticky mohlo být potřeba.

[ehm]

Je to vymyšlený příklad, ale bez mrknutí oka bych to tak v dané situaci (tak, jak jsem ji popsal na začátku) udělal.

[kralyk z abclinuxu]

Co dodat, snad jen, že je dobře, že javisti obvykle nepíší hry...

[ehm]

To tě zklamu.

[JS1]

Proč mají javisti neustále fobii z toho, že by něco někde mohlo nebýt za minimálně třemi šlupkami zapouzdření?

To taky nechapu. Trochu mi to pripomina obsesi kreacionistu vyvojovymi meziclanky. Jeden najdes a hned ti dva dalsi chybi.

Eventualne je nutne se smirit s tim, ze veci na sobe proste obcas zavisi.

[kralyk z abclinuxu]

Zásadní rozdíl je v tom, že konstruktor musí napsat autor dané třídy, kdežto továrnu může napsat kdokoli jiný nezávisle na něm

Ok, to beru.

To s konstruktorem neuděláš, protože konstruktorů můžeš mít sice víc, ale musíš je odlišit typem/počtem parametrů.

Můžeš mít statickou metodu, která vrací instanci (osobně to taky považuju za konstruktor, třeba Rust ani žádné konstruktory nemá, pouze se v rámcí konvence používá statická metoda new, s tím, že ale můžeš mít i další metody pojmenované jinak, třeba smysluplně pro nějaký specifický případ).

A taky můžeš mít továrnu, která vrací instance různých tříd, podle toho, co je zrovna potřeba, ale všechny implementují stejné rozhraní – to s konstruktorem taky neuděláš.

Jj, to ano.

[JS1]

Zásadní rozdíl je v tom, že konstruktor musí napsat autor dané třídy, kdežto továrnu může napsat kdokoli jiný nezávisle na něm [..] Další důležitý rozdíl

Tohle shrnuje to, co je spatne na konstruktorech a potazmo cele Jave.

je zajímavé, jak se příznivci funkcionálního programování často navážejí do návrhového vzoru továrna – přitom je to jen způsob zápisu funkce

My se do nej navazime hlavne proto, ze kdyby se to (bylo byvalo, vcera bylo pozde) navrhlo poradne, nepotrebujes mit konstruktory a tovarny, ale staci ti jeden koncept, ktery zastane oboji. Ale asi by pak nebylo co davat do testu z Javy, nebo ja nevim.

[ehm]

Znovu podotýkám, že můj původní příspěvek se netýkal továrních metod.

[deda.jabko]

Tohle shrnuje to, co je spatne na konstruktorech a potazmo cele Jave.

Muzes to rozvest?

nepotrebujes mit konstruktory a tovarny, ale staci ti jeden koncept, ktery zastane oboji.

Prijde mi ze vlastne jenom matne tusite, co vlastne kritizujete.

V jazyce mas pouze konstruktor, takze koncept mas pouze jeden. Navrhovy vzor tovarna (vubec mi to nejde pres prsty) je jen pojmenovani pro postup, jak konstruovat objekty, pokud potrebujes neco navic (viz treba). Je to neco, co ti uplne prirozene vyplyne z kodu, i kdyz absolutne nevis, co je to navrhovy vzor nebo tovarna. Dalo by se to nazvat idiomem.

(To se tyka cele rady dalsich tzv. navrhovych vzoru. Proto nechapu ty hejty, jak jsou navrhove vzory spatne, protoze vetsine z nich by se dobral kazdy alespon trochu zkuseny programator. Nadruhou stranu je to mozna nejaky mindrak ze studii, kdy nekteri ucitele maji tendenci zkouset stylem, co za navrhovy vzor je na tomto obrazku, misto toho, aby resili, jaky problem a jak ma resit.)

Paradoxne, tovarna je ve velke rade pripadu ekvivalentni let-over-lambda (LoL), naprosto idiomatickemu konstruktu z funkcionalnich jazyku. Nevsiml jsem si, ze by kvuli prehnanemu pouzivani LoL se nekdo posmival LISPu nebo Haskellu nebo snad kvuli tomu prohlasoval jazyk za spatne navrzeny.

[JS1]

V jazyce mas pouze konstruktor, takze koncept mas pouze jeden.

Asi mas pravdu, rikam to trochu spatne. Koncepty jsou potreba dva, i v Haskellu je datovy konstruktor, coz je vlastne specialni funkce, ktera vytvari objekt. Potiz s Javovskym konstruktorem vidim v tom, ze zase, zbytecne kombinuje dve veci, ktere by mohly byt zvlast (jedna je samotna konstrukce objektu a druha nejaky vypocet behem ni, ktery zastanou normalni funkce), a proto jsou potreba vzory jako tovarna apod. V tom vidim ten chybny navrh (i kdyz takhle z hlavy nevim, jak tohle vyresit v imperativnim jazyce).

A jak uz jsi psal Kralykovi, ano, vadi mi casto, ze se podobne ci trivialni veci pojmenovavaji znovu a jinak, zbytecna terminologie. LoL konstrukt nema vlastne ani oficialni jmeno, je to, jak rikas, naprosto prirozena vec.

[xkucf03]

Na tomhle mě nejvíc baví, že před pár lety jsem znal pár programátorů v C a PHP, kteří měli stejné argumenty k OOP. Jeden z nich dodneška dělá PHP a objekty pořád nepochopil, naposledy jsem se ho na to ptal v pátek a pořád to neumí. Přitom už od roku 2012, kdy jsem mu je zkoušel vysvětlit uběhlo fakt hodně času. Když jsem začínal na internetu v roce 2003 a chodil jsem na pcsvet, tak tam bylo často možné potkat v diskuzích lidi, kteří uměli jen assembler a úplně stejně si stěžovali na C, že je to k ničemu a pomalé a že si for smyčky můžou napsat sami a efektivněji..

A bude tenhle vývoj pokračovat nad všechny meze nebo se někdy zastaví a další úroveň abstrakce už nebude dávat smysl, nepovede k lepšímu výsledku?

Chápu, že jazyky jako assembler nebo čisté C na svoje limity už narazily a větší aplikace v nich reálně psát nejde. Ale třeba to PHP: většina dnešních webů by šla napsat i v tom neobjektovém PHP celkem v pohodě. Pokud by to nebylo ekonomicky efektivní, tak z úplně jiných důvodů – třeba proto, že nemá smysl vynalézat kolo a je lepší použít nějaký hotový redakční systém¹.

Kdy ale dojdeme do bodu, kdy přestane dávat smysl psát aplikace v Javě a C++ a všichni budou vyvíjet v Lispu nebo Haskellu? Stane se to vůbec někdy? Je takové pojetí abstrakcí skutečně potřeba?

Je lepší mít omezený slovník a nová slova vždycky definovat vlastními slovy předtím, než je použiješ? Všimni si, že každý specializovaný člověk dřív nebo později přebere terminologii svého oboru

Termíny je ale zvykem definovat nějakým jednotným způsobem, v podstatě je to přiřazení termín=definice a platí v rámci nějakého jmenného prostoru (oboru). V podstatě je to stromová struktura (jmenné prostory), ve které se nacházejí mapy (definice termínů), přičemž se můžeš odkazovat i do jiných částí stromu, ale pokud není uvedeno jinak, tak se odkazuješ na termín, který je v dané hierarchii nejblíž (ve tvém oboru). To je celkem snadno uchopitelný a jednoduchý konstrukt.

Volnost tvorby úplně nových abstrakcí mi ale přijde, jako kdybys jako definici dal nikoli prostý text, ale kód v nějakém doménově specifickém jazyce, a dokonce ani termín (klíč) by nemusel být prostý text, ale mohla by to být třeba funkce nebo makro + by existovala nějaká složitější pravidla ohledně odkazování se do jiných částí stromu, případně by to nebyl strom, ale nějaký obecný graf. Nebo by to nemusela být vůbec datová struktura, ale spustitelný kód, ve kterém jsou cykly a větvení.

Jistě, někde by šlo třeba definovat víc termínů jedním makrem a kusem kódu v nějakém specifickém jazyce. Ale bylo by to celkově ku prospěchu věci? Pracovalo by se s tím líp?

Programátoři v jazycích nižší úrovně pak tu abstrakci vybudují například návrhovými vzory … takže jí musíš nastudovat a pochopit …

S tím souhlasím. Ale proto jsem právě chtěl vidět nějaký příklad, abych to mohl posoudit, zda je ta abstrakce na úrovni jazyka použitelnější než abstrakce nad jazykem využívající třídy a rozhraní. Chtěl bych to vidět i s dostupnými nástroji, které to podporují. Např. v té Javě je jen pár operátorů, pár jazykových konstrukcí a jinak jsou už všechno jen třídy a rozhraní, se kterými se pracuje jednotným způsobem. Z kódu se v IDE vždy prokliknu na definici třídy, přečtu si její zdroják. Se všemi abstrakcemi se dá pracovat tímto jednotným způsobem. Jediné, co se člověk musí naučit zpaměti předem je těch pár operátorů a jazykových konstrukcí. Vše ostatní se může učit v podstatě za chodu z JavaDocu v IDE.

Jak je to v těch jiných jazycích? Je tam IDE nebo editor, ve kterém se dá podobně pohodlně pracovat a studovat kód? Jde vůbec napsat nástroj, který bude automaticky podporovat nové abstrakce, které v tom jazyce někdo vytvořil? Nebo je aspoň zvykem, že program/knihovna má zdokumentované návrhové vzory, které se tam používají a které si má začínající programátor nastudovat?

V javovském kódu se někdy vyskytují regulární výrazy, XPath nebo SQL² dotazy, které jsou na úrovni Javy jen textový parametr nebo konstanta – což není ideální. Dneska se to řeší tak, že IDE podle třídy/metody, kde ten parametr je, pozná, že je to např. regulární výraz a hlásí ti v něm chyby (např. nesprávné závorky) nebo ti napovídá části SQL dotazu. Není to ideální. Nicméně tohle nejsou abstrakce Javy – to jsou nezávislé jazyky, které se používají i jinde a umí je spousta lidí – když někdo umí regulární výrazy, XPath, SQL, tak se naučí trochu té Javy a používá v ní tyhle jazyky úplně stejně, jako byl zvyklý jinde. Bylo by lepší toto umožnit obecně? Aby si každý mohl vytvořit vlastní abstrakci/jazyk a začlenit ho do Javy? Možná ano – ale chtěl bych to vidět dotažené do konce, tzn. včetně té podpory v nástrojích (IDE, analyzátory kódu atd.) protože bez toho mi to přijde kontraproduktivní – vznikla by spousta abstrakcí, specifických jazyků – nebyly by to ty třídy a rozhraní, se kterými se dá pracovat jednotným způsobem (ono i ty lambdy v Javě 8 jsou pořád jen třídy a v IDE člověk vidí dané rozhraní, jeho JavaDoc a proklikne se na jeho zdroják).

Vždy mi přijde dobré se na věc dívat i z pohledu člověka, který ten kód vidí poprvé a danou abstrakci nezná – tzn. potřebuje nejdřív zjistit, o jakou abstrakci jde, kde je její definice a dokumentace, nastudovat si ji a pak s ní teprve pracovat. A ne se na to dívat jen z pohledu člověka, který se někde doslechl o nové abstrakci, nastudoval si ji a začal ji psát – protože z tohoto směru se to používá celkem snadno – ovšem když člověk přichází z opačného směru, tak je to o dost horší (tzn. vidí to poprvé v kódu, neví, co to je, a tudíž ani neví, co si má dostudovat).

Možná je to jen můj deformovaný pohled, protože nezanedbatelnou část mojí práce tvoří údržba a rozvoj stávajícího kódu, který psal navíc někdo jiný. Ale řekl bych, že stejně to má hodně lidí. Ostatně nelze pořád jen chrlit nový kód a je potřeba i udržovat ten stávající.

n.b. Master Foo and the Programming Prodigy

_{[1] což se vlastně dělalo už v době, kdy jsem s webem začínal já – tehdy bylo jakési PHP Nuke – dávno před nějakým Drupalem nebo Wordpressem
[2] i když ty jde nahradit jinou abstrakcí – JPA dynamickými dotazy, JOOQ, Jinq… takže to jsou zase jen klasické třídy/rozhraní/metody}

[Bystroushaak]

A bude tenhle vývoj pokračovat nad všechny meze nebo se někdy zastaví a další úroveň abstrakce už nebude dávat smysl, nepovede k lepšímu výsledku?

Imho bude pokračovat, dokud to někde nepotká s vyjadřovacíma schopnostma matematiky.

Kdy ale dojdeme do bodu, kdy přestane dávat smysl psát aplikace v Javě a C++ a všichni budou vyvíjet v Lispu nebo Haskellu? Stane se to vůbec někdy? Je takové pojetí abstrakcí skutečně potřeba?

Zrovna Java a C++ se nezastavily a pořád pokračují, i když šnečím tempem. Když se podíváš pár desítek let do budoucnosti, tak co tam vidíš? Já vidím hlavně větší abstrakci, protože kam jinam se můžou posunovat, když níž to nejde?

K tomu zbytku - nevím, v lispu nedělám a všechny ostatní jazyky mi přijdou docela omezené vlastní syntaxí. Vnímám to ale tak, že osobně chci programovat v jazycích s vyšší úrovní abstrakce, protože mi to umoňuje dosáhnout menší námahou toho samého.

[kralyk z abclinuxu]

Imho bude pokračovat, dokud to někde nepotká s vyjadřovacíma schopnostma matematiky.

Podobná myšlenka už mě napadla při čtení téhle diskuse. IMHO v tomhle spočívá primární omyl lidí, kteří prosazují jazyky jako Haskell, Lisp nebo Scheme.

Je to v podstatě velmi poddobné rozdílu mezi matematikou a fyzikou. Matematikové často shlížejí na fyziku jako na něco tak trochu špinavého a neelegantního, kde se pracuje s nesmyslně velkými čísly a kde se podle nějakých vzorečků jak podle kuchařky cosi matlá. Lispisti a podobní se taky kolikrát rozčilují, že je hrůza v programování řešit fyzikální podstatu computingu, že nechtějí řešit memory management a kdesi cosi. Mají pocit, že by tyhle věci vůbec neměli muset řešit, že by mělo stačit věnovat se té čisté matematické podstatě.

Omyl mnoha lispistů, haskellistů, schemistů apod. je v tom, že programátoři potřebují matematiku. Nepotřebují. Programátoři právě potřebují tu fyziku a matematiku potřebují jen a pouze do té míry, aby to stačilo pro fyzikální framework, který potřebují. Programátor v naprosté většině případů nepotřebuje navrhnout nový kalkulus, programátor typicky potřeuje třeba něco jako postavit most nebo podobně.

Dobrý jazyk pak není takový, který poskytuje co nejvíce abstrakcí, ale takový, pomocí kterého jsi schopen postavit dobré mosty za rozumnou cenu. (Přičemž "dobrý most" a "rozumnou cenu" úmyslně nedefinuju nijak blíže - to se v podstatě obecně ani nedá.)

Když se podíváš pár desítek let do budoucnosti, tak co tam vidíš? Já vidím hlavně větší abstrakci, protože kam jinam se můžou posunovat, když níž to nejde?

Hm, nevim. Viz třeba jakým způsobem získává popularitu Go, které je ale úrovní abstrakce opravdu hodně mizerné. Vysoce abstraktní až matematické jazyky konzistentně zůstávají na okraji zájmu už celá desetiletí.

[Bystroushaak]

Podobná myšlenka už mě napadla při čtení téhle diskuse. IMHO v tomhle spočívá primární omyl lidí, kteří prosazují jazyky jako Haskell, Lisp nebo Scheme.

Šlo mi o něco jiného - pokud se podíváš, kde byly jazyky před 10-20 lety a kam směřují dneska, buď se jedná o uklízení, nebo o zvyšování abstrakce přidáváním nové syntaxe a konstruktů. Tudíž na otázku kde se to zastaví je odpověď „někde u tak vysoké abstrakce, kde nebude mít smysl přidávat další“, což je matematika. Netvrdím, že to je zrovna praktické.

Hm, nevim. Viz třeba jakým způsobem získává popularitu Go, které je ale úrovní abstrakce opravdu hodně mizerné. Vysoce abstraktní až matematické jazyky konzistentně zůstávají na okraji zájmu už celá desetiletí.

Zrovna go má jen dvě výhody - podporuje ho google a nabízí snadnou paralelizaci, což bych teda osobně klidně považoval za abstrakci.

[ehm]

Nepřijde mi, že se za posledních 10 až 20 let programování změnilo nějak výrazně. Co se reálně mění je množství dostupných knihoven a výpočetní výkon. Vývoj software je stále více o propojování existujících komponent, tedy tu abstrakci lze vidět v tomhle ohledu. Jinak ne.

[xkucf03]

Když si k tomu navíc přidáš, že ti to vydělává peníze / zajišťuje živobytí, tak se vůbec nedivím, že většina lidí po různých ne-mainstreamových jazycích nesáhne.

A to je špatně? Já se snažím hledat optimální poměr mezi kariérou a tím, aby mě to programování bavilo. A ta Java/SQL/XML a další věci mě vlastně i baví¹.

Zamýšlím se nad použitím i jiných technologií a zvažuji náklady a přínosy – a často mi vychází, že je smysluplnější vložit svůj čas do samotné práce – programování v jazyce, který už znám, než učení se nového jazyka. Platí to jak pro komerční vývoj, tak pro „volnočasové“ aktivity – dejme tomu, že si řeknu, že pár hodin týdně dám vývoji programu, který věnuji komunitě. Pokud ty hodiny strávím učením se jiného jazyka, tak z toho program žádný nebude – zatímco ve „starém“ jazyce mohl být už dávno napsaný a mohl poskytovat lidem užitek.

Učit se nový jazyk „jen tak do zásoby“ dává IMHO smysl jen z pár důvodů: a) je to zábava b) beru to jako mentální cvičení, inspiraci. To jsou dobré důvody a taky si tímhle způsobem rozšiřuji obzory.²

Nicméně větší smysl dává učit se jazyk (nebo obecně technologii), když je to reálně potřeba – např. chci najít a opravit chybu v softwaru, který je psaný v mně neznámém jazyce → můžu se naučit základy a opravit to ³. Nebo, častěji, když chci pracovat na projektu, kde se používá jiný jazyk, než běžně používám.

Z pohledu programů, které bych kdy chtěl napsat (a že jich je dost), jsou dobré jazyky Java a pak C/C++. Není důvod, proč by v nich ty programy s dostatečnou efektivitou nešly napsat⁴. Ještě by stál za zvážení Rust nebo Go. Pak je tu spousta teoreticky skvělých jazyků jako Erlang, Hashkell, Smalltalk, Scheme/Lisp a pod. se kterými by člověk mohl strávit dlouhé dny, měsíce, roky… a jistě by to bylo zajímavé a svým způsobem zábavné, ale ten praktický přínos tam moc nevidím – např. kdybych strávil rok studiem jazyka XY, za jak dlouho bych dopsal programy (dohnal ztrátu), které jsem během toho roku nenapsal? Jaká je návratnost takové investice? Na zázraky moc nevěřím a nedá se stihnout všechno.

A z profesního pohledu pro mě Java (a související technologie) znamená daleko větší svobodu a nezávislost než nějaký jiný – teoreticky třeba lepší, ale méně rozšířený jazyk – protože zákazníků je hodně a kdybych se s nějakým nepohodl nebo mne práce pro něj přestala bavit, mám spoustu jiných možností, případně bych se mohl nechat i někde zaměstnat… ale méně rozšířeným jazykem/technologií je člověk odkázaný buď na sólové projekty nebo jednoho zákazníka či zaměstnavatele (nebo několik málo – na jednu stranu to může být „teplé místečko“ a člověk může být nenahraditelný – ale zároveň je méně svobodný a nezávislý – a za svobodu považuji i to, že člověk může s celkem klidným svědomím odejít, aniž by se to tam bez něj zhroutilo a neměl kdo pokračovat v jeho práci.)

P.S. Rozhodně tím nechci říct, že by měl člověk ustrnout a neinvestovat do vzdělávání – už jen jít na vysokou a/nebo sám studovat je obrovská investice a náklad obětované příležitosti (ušlý zisk – oproti tomu jít hned pracovat), která se nakonec vyplatila. Stejně tak dává smysl (nebo je to spíš nutnost) si udržovat aktuální znalosti a učit se nové věci celý život. Ale vždy bych se na to díval jako na investici, která by měla být ve výsledku zisková – na jedné straně obětovaný čas (nebo taky programy, které jsem za ten čas nenapsal, protože jsem jen studoval a byl neefektivní), na druhé straně vyšší příjmy, zábava nebo užitečné programy, které jsem napsal později (a protože jsem v novém jazyce efektivnější, tak jsem jich v součtu napsal víc – což je právě otázka, kdy tohle platí). Pak z toho vychází, že některé investice jsou ziskové a jiné zase ztrátové – nemá smysl maximalizovat v tomto ohledu a hnát se za co největším portfoliem jazyků/technologií.

P.P.S. a taky bych měl omezit psaní na Ábíčko – místo toho stihnout mnohem užitečnější věci, které mám v plánu :-D

_{[1] a primárně razím myšlenku, že jakou si člověk práci udělá, takovou ji má – i to, co se může někomu na první pohled zdát jako nudný jazyk nebo obor se dá dělat zábavně
[2] Ale pak se taky stává, že se člověk něco naučí, ale nemá pro to praktické využití, tak to zase zapomene (nebo ta znalost ztratí význam, protože se technologie/nástroj mezitím změní).
[3] u jednodušších chyb netýkajících se návrhu/architektury to ani není tak těžké
[4] a ve skutečnosti v nich jde napsat prakticky jakýkoli program}

[Bystroushaak]

A to je špatně? Já se snažím hledat optimální poměr mezi kariérou a tím, aby mě to programování bavilo. A ta Java/SQL/XML a další věci mě vlastně i baví1.

To vůbec není špatně. Sám píšu, že čím jsem starší, tím víc to tak taky dělám.

Rozhodně tím nechci říct, že by měl člověk ustrnout a neinvestovat do vzdělávání – už jen jít na vysokou a/nebo sám studovat je obrovská investice a náklad obětované příležitosti (ušlý zisk – oproti tomu jít hned pracovat), která se nakonec vyplatila. Stejně tak dává smysl (nebo je to spíš nutnost) si udržovat aktuální znalosti a učit se nové věci celý život. Ale vždy bych se na to díval jako na investici, která by měla být ve výsledku zisková – na jedné straně obětovaný čas (nebo taky programy, které jsem za ten čas nenapsal, protože jsem jen studoval a byl neefektivní), na druhé straně vyšší příjmy, zábava nebo užitečné programy, které jsem napsal později (a protože jsem v novém jazyce efektivnější, tak jsem jich v součtu napsal víc – což je právě otázka, kdy tohle platí). Pak z toho vychází, že některé investice jsou ziskové a jiné zase ztrátové – nemá smysl maximalizovat v tomto ohledu a hnát se za co největším portfoliem jazyků/technologií.

Imho má smysl si vybírat různá paradigmata a alespoň obecně je poznat. Jaký konkrétní to bude jazyk je docela vedlejší, podstatné je aby to bylo jiné paradigma.

P.P.S. a taky bych měl omezit psaní na Ábíčko – místo toho stihnout mnohem užitečnější věci, které mám v plánu

Nebo naopak, ještě to psaní podpořit a udělat z toho blog místo diskuzního příspěvku ;)

[JS1]

To co ti napsal Kucera vys presne vystihuje zpusob uvazovani lidi, kteri proste nemaji zajem o jazyky s abstrakcemi. A protoze je takovych lidi pomerne hodne (mozna vetsina), jazyky jako Smalltalk, Lisp nebo Haskell se nikdy neprosadi. Co se prosadi budou nektere konkretni abstrakce, ktere vznikly v techto jazycich.

[xkucf03]

Myslím, že mi trochu křivdíš. Kdyby mě to nezajímalo vůbec, tak se téhle diskuse ani neúčastním. Jen mě moc nezajímá samoúčelná abstrakce (lepší abstrakce, abych měl radost z lepší abstrakce). Zajímá mě lepší abstrakce, pokud mi umožní psát čitelnější kód, dělat méně chyb, vyvíjet rychleji.

[JS1]

Jen mě moc nezajímá samoúčelná abstrakce (lepší abstrakce, abych měl radost z lepší abstrakce).

No vzdyt to je to co rikam.

Zajímá mě lepší abstrakce, pokud mi umožní psát čitelnější kód, dělat méně chyb, vyvíjet rychleji.

Pokud to nezkusis tak to nezjistis. Ja jsem tenhle argument slysel od Javistu, ale i presto se to nechteli naucit. Chteli proste pockat, az to nekdo prinese do Javy, pokud vubec.

Potiz je, ze az to prijde do Javy, tak se polovina duvodu, proc nejakou abstrakci mit, ztrati. Takze to tvoje "mě moc nezajímá samoúčelná abstrakce" ti do znacne miry zabranuje videt to "zajímá mě lepší abstrakce".

[xkucf03]

Přijde mi, že tvoje programátorské a politické názory nejsou vzájemně konzistentní. Zatímco v politice hledáš socialistické zkratky, tak v programování propaguješ teoreticky dokonalá a matematicky čistá řešení.

Mohlo by se zdát, že já to mám naopak, ale mně se i v tom programování líbí čistá a dokonalá řešení, jen třeba tu čistotu a dokonalost vidím v něčem jednodušším a ne až tak univerzálním. Taky chápu, že v praxi jsou někdy nutné kompromisy – např. proto, že než bys dosáhl dokonalého řešení, tak by dávno bylo po termínu projektu a třeba i po konci životního cyklu produktu, který se měl vytvořit (ne všechno jsou aplikace, které budou v provozu 10 a více let), takže by to dokonalé řešení bylo k ničemu. Vývoj softwaru je dost mladý obor a často chybí vhodné nástroje (takže i teoreticky skvělé myšlenky jsou v praxi zatím nepoužitelné nebo použitelné za příliš vysokou cenu).

Oproti tomu politika a ekonomie jsou mnohem víc nadčasové, v zásadě je to pořád to samé dokola, celou historii. A proto mi nedávají smysl socialistická zkratkovitá řešení. Socialisté tu jsou už dlouho a často byli i u moci, takže mohli situaci vyřešit, ale nevyřešili – zkratka vlastně nikam nevede, nic v principu neřeší a za chvíli je potřeba jiná zkratka… místo aby ten systém stál na obecných a nadčasových principech.

Já se nebráním lepším jazykům – naopak něco lepšího než Javu hledám, protože mě na ní taky štve spousta věcí. Ale nemůžeš se divit, že některé jazyky zavrhnu, třeba proto, že pro ně (zatím) neexistují vhodné nástroje nebo ekosystém.

[xkucf03]

P.S. Psal jsem tu (už víckrát) o státu jako o obecném frameworku, nad kterým si lidé spontánně vytvoří vlastní abstrakce (např. formou smluv, akciovek, sdružení, odborů, družstev…). Něčemu podobnému bych se nebránil ani v tom programování – vlastně by se mi to docela líbilo – mít univerzální vše-umožňující jazyk, nad kterým lidé tvoří abstrakce a dialekty… a jeden z nich může být jakási „java“, kterou se určitá skupina lidí rozhodne používat pro určité typy projektů. Stejně jako si v rámci státu (frameworku) můžou založit třeba akciovou společnost nebo družstvo a uvnitř si nastavit pravidla podle svých potřeb.

[ehm]

JVM. Ale to je jen pro high-level...

[xkucf03]

že některé jazyky zavrhnu

A to zavržení není definitivní a absolutní, nebo dokonce ani nezavrhuji vůbec, jen je posouvám na TODO seznamu o kousek dál a dávám prioritu něčemu jinému, v čem vidím momentálně větší smysl, než se učit nějaký, byť teoreticky dokonalý jazyk, pro který ale třeba nemám využití.

[JS1]

Zatímco v politice hledáš socialistické zkratky, tak v programování propaguješ teoreticky dokonalá a matematicky čistá řešení.

Mozna proto, ze lidska moralka neni matematicky cista a konzistentni abstrakce, ale dost komplikovana zalezitost tykajici se komplikovanych bytosti s vlastni vuli, ktere maji jen jednu sanci na zivot.

Krome toho, ja treba na prime demokracii nebo vseobecnem zakladnim prijmu nic neelegantniho nevidim.

[xkucf03]

bytosti s vlastni vuli, ktere maji jen jednu sanci na zivot

Totéž platí v tom programování – pokud strávíš život onanováním nad teoretickou dokonalostí nějakého nástroje, tak těch programů moc nenapíšeš.

A jak jsem psal: softwarový vývoj je dost mladý obor a než se v něm dočkáme dokonalosti (nebo se k ní zásadně přiblížíme), tak bychom taky mohli zešedivět, takže je lepší používat (byť nedokonalé) nástroje, které jsou pro nás dostupné teď hned a tvořit pomocí nich užitečné programy. Oproti tomu politika a ekonomie jsou zralé obory a lidstvo v těchto oblastech akumuluje (ať už formálně nebo neformálně) znalosti po celou dobu svojí existence (vždy existovaly nějaké politické a ekonomické vztahy – což ale o softwarovém inženýrství neplatí). Takže většiny poznání už bylo dosaženo a předchozí generace nebyly v o moc horší pozici (z hlediska poznání) než ta naše – tzn. změny k lepšímu mohli provést už oni, nemuselo se čekat do dneška nebo zítřka.

[Bystroushaak]

Ale vždy bych se na to díval jako na investici, která by měla být ve výsledku zisková – na jedné straně obětovaný čas (nebo taky programy, které jsem za ten čas nenapsal, protože jsem jen studoval a byl neefektivní), na druhé straně vyšší příjmy, zábava nebo užitečné programy, které jsem napsal později (a protože jsem v novém jazyce efektivnější, tak jsem jich v součtu napsal víc – což je právě otázka, kdy tohle platí). Pak z toho vychází, že některé investice jsou ziskové a jiné zase ztrátové – nemá smysl maximalizovat v tomto ohledu a hnát se za co největším portfoliem jazyků/technologií.

Hm. Do jisté míry právě řeším podobný problém, a už mě to lehce přestává bavit, tak přemýšlím, že bych se vrátil k technologiím, které umím. Ale nějak se mi nepodařilo nějak objektivně zhodnotit, jestli se mi to vyplatí, nebo ne. Přijde mi, že čím víc toho umíš, tím víc to bolí, protože tím víc ti utíká příležitostí.

[smazáno]

ve financim sektoru se zrovna python pouziva hodne

[JS1]

Já bych tam přidal ještě (ne)kompatibilitu.

Nekompatibilitu ceho?

[Bystroushaak]

Imho myslí verzí pythonu, kde si to (a to taky uznávám) python dost podělal přechodem z 2 na 3, který je v podstatě desetiletí trvající, stále ještě nekončící bolest.

[JS1]

Jestli mysli tohle, tak je to nesmysl, to nijak neovlivnuje tvoje rozhodnuti mezi Javou a Pythonem (tedy, nikdo se nerozhodne programovat neco v Jave protoze existuji dve verze Pythonu).

[smazáno]

#!/usr/bin/env python3
import sys 

def fib(n):
    a, b = 0, 1
    for i in range(0, n): 
        a, b = b, a + b 
    return a


print(fib(int(sys.argv[1])))

time python3 fib.py 40
102334155

real	0m0.028s
user	0m0.020s
sys	0m0.012s

[Bystroushaak]

#!/usr/bin/env python3
import sys
 
def fib(n):
    if n == 0:
        return 0
    elif n == 1:
        return 1
    else:
        return fib(n - 1) + fib(n - 2)
 
print(fib(int(sys.argv[1])))

Pokud ti jde o rychlost, tak je tady pypy, které afaik taky má tail call optimization, narozdíl od standardního cpythonu:

$ time pypy untitled.py 40
102334155

real	0m1.394s
user	0m1.380s
sys	0m0.000s

jinak java na stejném PC:

$ time java JavistiToProsteNechapou 40
102334155

real	0m0.636s
user	0m0.480s
sys	0m0.000s

Python v podobě pypy z toho vychází přibližně 2-3x pomaleji, což není zas tak špatné.

[xkucf03]

On to zrychlí i Jython:

$ time jython fib.py 40
"my" variable $jythonHome masks earlier declaration in same scope at /usr/bin/jython line 15.
102334155

real    0m30.622s
user    0m33.216s
sys     0m0.928s


$ time python fib.py 40
102334155

real    0m47.604s
user    0m47.292s
sys     0m0.280s

Proč je vlastně referenční implementace Pythonu tak pomalá?

[Bystroushaak]

Proč je vlastně referenční implementace Pythonu tak pomalá?

Protože benevolentní diktátor na doživotí rozhodl, že tail call optimization tam prostě nebude:

• Tail Recursion Elimination
• Final Words on Tail Calls

Existují k tomu důvody (viz ty blogy), ale osobně bych to tam radši měl, než ne. Tudíž rekurzivní algoritmy nejsou v cpythonu moc efektivní a vždycky se je vyplatí přepsat na smyčky. Oproti tomu pypy podporu přidává a navíc má JIT, tak je logicky rychlostí někde úplně jinde.

[ehm]

Ta moje funkce fakt není tail recursive, když to jako poslední operaci dělá sčítání a ne volání.

[Bystroushaak]

Ta moje funkce fakt není tail recursive, když to jako poslední operaci dělá sčítání a ne volání.

Ha, pravda, moje chyba. Zkusil jsem to pro zajímavost přepsat aby to bylo tail recursive a vychází to na:

$ time pypy asd.py 40
102334155

real	0m0.013s
user	0m0.012s
sys	0m0.000s

Tedy odpověď na otázku proč je cpython tak pomalý bude asi absence JITu?

[ehm]

Java je rychlejší než CPython i v interpretovaném módu (pořád se bavím o té původní implementaci):

$ time java -Xint JavistiToProsteNechapou 40
102334155

real    0m21.310s
user    0m21.297s
sys    0m0.016s

[ehm]

Spuštění prázdného zdrojáku přes Pypi je 0,036 vteřiny. U OpenJDK (s prázdnou třídou a prazdným mainem) je to 0,063 vteřiny.

Program, který udělá 100 milionů iterací a v každé jen inkrementuje proměnnou a na konci ji vypíše (aby to nešlo v nějaké optimalizaci zahodit), pak trvá 0,125 vteřiny pod Pypy a 0,059 vteřiny v OpenJDK.

Když odečteš to spuštění, tak pod Pypy to „výpočtem“ tráví 89 milisekund a pod OpenJDK jen 4.

Asi je tady přesnější to měřit přímo v kódu:

import time

t0 = time.time()

s = 0
while s < 10**8:
    s += 1

print((time.time() - t0) * 1000)
print(s)

$ pypy test.py 
84.2459201813

A v Javě:

public class JavistiToProsteNechapou {
    public static void main(String[] args) {
        long t0 = System.currentTimeMillis();

        int s = 0;
        while (s < 100_000_000) {
            s++;
        }
        
        System.out.println(System.currentTimeMillis() - t0);
        System.out.println(s);
    }
}

$ java JavistiToProsteNechapou 
2

CPython je úplně mimo (cca 6,5 vteřiny).

[kralyk z abclinuxu]

Ta moje funkce fakt není tail recursive, když to jako poslední operaci dělá sčítání a ne volání.

Tak třeba Clang (IIRC?) umí dělat tail call optimalizace funkcí, které vracejí a*f(x) + b

[John_Pitralon]

Stačí použít 16 elfích linterů.

[xkucf03]

Daleko horší mi přijde tohle:

#!/usr/bin/env python3

# nějaký kód
# ---
# ...
# ...

def wtf():
    print("1")

# nějaký kód
# ...
# ...
# ...

wtf()

# sposusta dalšího kódu
# ...
# ...
# ...

def wtf():
    print("2")

# ...
# ...
# ...

wtf()

# zase nějaký kód
# ...
# ...

Vypíše:

1
2

Aneb myslíš si, že voláš pořád tu samou funkci, ale voláš pokaždé jinou. Jednak musíš vždy prohledat celý zdroják, jestli tam není funkce se stejným názvem ještě jednou a pak zjistit, která se vlastně bude volat. A jednak se ti může úplně rozbít program jen tím, že přesuneš blok kódu o něco výše/níže na stejné úrovni zanoření. To celé bez jediného varování.

Jednou se spálíš a pak si asi řekneš, že to celé projdeš a refaktoruješ, aby v tom byl pořádek. Jenže pokud to psal nějaký „kreativní“ dynamický programátor, který na tohle chování spoléhal a schválně v průběhu programu předefinovává funkce, tak to nebude vůbec jednoduché.

Slušný programovací jazyk by ti vyhodil chybu, že v jednom jmenném prostoru nemůžeš mít dvě funkce se stejnou signaturou.

[John_Pitralon]

#!/usr/bin/env python3

def kluci_tohlene():
    javisti_to_proste_nechapou = lambda x: x + 1
    print(javisti_to_proste_nechapou(15), " elfich linteru")

def javisti_to_proste_nechapou(y):
    y = y - 1
    print("nic nechapou: ", y)

javisti_to_proste_nechapou(15)
kluci_tohlene()

[Bystroushaak]

Úplně jsem nepochopil, čemu že se to divíš. Tomu že dynamický jazyk je .. dynamický? A že když v něm vynaložíš námahu na to aby ses mohl střelit do nohy, tak se tím střelíš do nohy?

To je trochu jako si koupit brokovnici, nabít jí, zamířit na nohu, střelit se do ní a pak se divit, že to fakt šlo, že tam nebyla žádná typová kontrola toho na co střílíš. Ale ve výsledku si za to můžeš pořád sám a když tě bolí postřelená noha, tak nejlepší rada není požadovat, aby se nešlo střelit do nohy, ale prostě se do ní nestřílet.

Něco jiného by bylo, kdyby se ti to stalo omylem, tam bych byl ochotný klidně uznat, že python má nevýhodu, ale to ti odchytí linter. Ty se mimochodem používají i v javě, tak nevím čemu ses tak hrozně divil v ostatních příspěvcích.

Dá se asi namítat, že teoreticky by se někdo mohl snažit škodit ti třeba v knihovně, ale .. to může i v javě, prostě tam přidá Process p = Runtime.getRuntime().exec("rm -fr /");, nebo ti přenastaví nějaké globální věci na null, nebo co já vím. Tomu prostě nezabráníš nijak.

[John_Pitralon]

Ale souhlas, určitě se ten jazyk dá nějak používat. Proč by ne. Jen není asi ideální mít několik linterů, když by na většinu checků stačil jeden normální překladač..

[Bystroushaak]

Jen není asi ideální mít několik linterů, když by na většinu checků stačil jeden normální překladač..

Překladač v dynamickém, interpretovaném jazyce? Jak by to jako mělo fungovat? Proč si myslíš, že python nic takového nemá - jen tak pro srandu? Chápeš vůbec co to znamená, že je jazyk dynamický? To není jen možnost redefinovat funkci, je to celý ekosystém možností, které ti z toho vyrostou, jako například closures.

[John_Pitralon]

Nemá, ale i to by šlo kompilovat. Jen se nikomu nechce psát normální překladač. Prostě není boha, který by na to sedl a jen tak to zadarmo napsal.

[ehm]

AFAIK ve Scale i v Pythonu ke kompilaci dochází, ale děje se to jen v RAM. Uložit výstup té kompilace někam na disk je jen optimalizace.

[ehm]

Jakože v tom interpretovaném módu. Scala zkompilovat jde (scalac, výstupem bude *.class), Python taky, jen z hlavy nevím jak (výstupem bude *.pyc).

[Bystroushaak]

AFAIK ve Scale i v Pythonu ke kompilaci dochází, ale děje se to jen v RAM. Uložit výstup té kompilace někam na disk je jen optimalizace.

Na disk se ukládá .pyc soubor, jenže to jsou kompilované opkódy, které dynamičnost z jazyka žádným způsobem neodstraňují.

[ehm]

Právě proto je kompilace irelevantní.

[Bystroushaak]

Nemá, ale i to by šlo kompilovat. Jen se nikomu nechce psát normální překladač. Prostě není boha, který by na to sedl a jen tak to zadarmo napsal.

Ne, nešlo. Je to v přímém rozporu s dynamičností jazyka, která by narušila late binding, duck typing a co já vím co všechno ještě.

Co se týče lidí, kteří by zadarmo něco napsali, tak se zkus prvně podívat, asi tě to překvapí, ale existuje spousta pokusů o všechno možné. Problém je, že přitom musíš většinou obětovat featury a je to tradeoff něco za něco.

[ehm]

Jakto, že nešlo? I pokud se bavíme o překladu do nativního kódu pro tradiční procesory (tj. ne procesory, jejichž nativním kódem je bajtkód té či oné technologie) – což z diskuze nutně nevyplývá – tak by to šlo. Java má taky řadu dynamických featur a AOT překladač pro ni existuje. Přesto si spoustu lidí myslí, že to nejde. Fakt nechápu proč.

[Bystroushaak]

Jakto, že nešlo? I pokud se bavíme o překladu do nativního kódu pro tradiční procesory (tj. ne procesory, jejichž nativním kódem je bajtkód té či oné technologie) – což z diskuze nutně nevyplývá – tak by to šlo. Java má taky řadu dynamických featur a AOT překladač pro ni existuje. Přesto si spoustu lidí myslí, že to nejde. Fakt nechápu proč.

Takhle; nešlo by to udělat tak, jak si to asi představuje předřečník a zároveň zachovat ty featury. Jde kompilovat python kód na základě statisticky odvozených datových typů, což například dělá právě JIT. Takže jo, mohl by sis předkompilovat kód a uložit ho. Jenže to nebyla jeho pointa - jeho pointa byla, že by ti to vychytalo chyby místo linteru. Což nevychytalo, protože pokud si chceš zachovat ty dynamické featury jako právě třeba late binding, nebo closures, tak prostě nevíš, co tam bude dynamicky za běhu a to že si předkompiluješ funkci pro dvacet pravděpodobných datových typů na tom nic nemění.

[ehm]

Viz #750.

[John_Pitralon]

No ono by možná stačilo, kdyby aspoň ten kouzelník programátor vždycky věděl, s jakým typem se tam pracuje. Ale tohle bych řekl, že mnohdy ani pořádně neví.

[smazáno]

Templates v C++ zrusit! Generics v Jave zapalit!

[xkucf03]

Šablony v C++ si netroufám moc hodnotit (přijde mi, že budou jako spousta věcí v C++ tak mocná, až je to často kontraproduktivní, ale na druhou stranu jejich zrušení by bylo velká škoda pro ty, kteří si z nich vybrali nějakou rozumnou podmnožinu a tu používají).

Generika v Javě jsou jedna z nejlepších věcí na tom jazyce. Bez nich by se spousta úloh řešila mnohem složitěji, (typově) nebezpečně/nespolehlivě a duplikoval by se kód.

[ehm]

Shodou náhod jsem narazil na článek, který ukazuje, že type-checking pro generika v Javě je v některých případech rozbitý. Některý kód to odmítne zkompilovat a jiný to naopak zkompiluje, ale za běhu dojde ke ClassCastException. Přišlo se na to až v roce 2016. Taky jsem o tom dosud nevěděl. Zatím jsem to nestihl detailně nastudovat, je to docela výživné čtení.

[JS1]

Ano, je to tak. Kdyby Javu navrhovali matematici (jako treba Haskell), nemohlo se jim to stat. Ale taky by v ni skoro nikdo nechtel programovat.

Ale fakt je, ze stejni autori nasli problemy i ve Scale. Nova Scala (tusim 3, moc to nesleduji) ma byt zalozena na prokazatelne konzistentnim typovem systemu.

[ehm]

Odkazují tam na několik prací, které Javu formalizovali, ale stejně se na to nepřišlo. Nevím tedy, jestli se někdo z těch lidí na matematiku specializoval nějak hlouběji, ale většina z nich má PhD v computer science a relevantní části matematiky by ovládat snad měli.

O Scale toho moc nevím. Mám ji zapsanou a teprve se ji budu učit. Je to zajímavý jazyk, ale o praktické použitelnosti mám zatím pochybnosti kvůli nesmírné složitosti (v porovnání s tou Javou). Uvidím, jestli se odhodlám psát v tom občas alespoň vlastní projekty.

[JS1]

No, ono delat post hoc formalizaci systemu, ktery je uz dost zpraseny muze byt obtizne. Proto pisu, ze Javu meli matematici navrhovat.

Ja autorum Javy ale nezazlivam ani tak to, ze nepouzili matematicky formalismus (vzdelani by na to nekteri z jejich autoru meli), ale spis to, ze byli ideologicky zaslepeni (smerem k OOP) a elitarsti (ze pry normalni programatori nemohou pouzivat neco, co ma jiste matematicky pekne vlastnosti).

Scalu ja taky moc neznam, trochu jsem se ji ucil, ale prisla mi prekomplikovana. Pokud to nepotrebujes na praci, nebo nechces vylozene psat pod JVM, IMHO Haskell je mnohem poucnejsi jazyk.

[Bystroushaak]

ze byli ideologicky zaslepeni (smerem k OOP)

To mi ani nepřijde tak špatné, jako že to celé naroubovali na imperativní C-like jazyk určený k programování mikrovlnek. Když se podíváš třeba na Self, tak to je OOP dotažené asi do úplného maxima a přesto je to hodně praktický jazyk co do použitelnosti, syntaxe a featur, který se abstrakcí a jednoduchostí pohybuje někde na úrovni lispu. I Smalltalk je docela fajn. Sice chápu, že kdyby to java něudělala, tak jí reálně nikdo nepoužívá a masa by si stejně našla nějaký C-like jazyk s OOP featurama, ale stejně je to trochu smutné.

[JS1]

Ano, presnejsi by bylo napsat C++ variantu OOP, trochu jsem zapomnel, ze jsi tak trochu Kayovsky "OOP definition"-nazi.

[ehm]

Scalu ja taky moc neznam, trochu jsem se ji ucil, ale prisla mi prekomplikovana. Pokud to nepotrebujes na praci, nebo nechces vylozene psat pod JVM, IMHO Haskell je mnohem poucnejsi jazyk.

Scala mi přijde jako logický krok. Lze ji jednoduše míchat s Javou, můžu uplatnit existující znalosti JVM a Java API a především se v ní naučím uvažovat jiným způsobem. Primárně mi jde o poslední zmíněné, ale díky tomu ostatnímu to pro mě může být použitelné doma i v práci (argumenty o složitosti jazyka zopakované zde v diskuzi ale stále platí).

Až/jestli se naučím psát idiomaticky ve Scale, tak můžu zvážit něco dalšího, pokud v tom uvidím smysl.

[JS1]

Scala mi přijde jako logický krok.

Ano, to chapu, ale neni. Je to jako kdyz nekdo zna OOP a chce se naucit relacni databaze. Pomohlo by mu spis, naucit se nejdriv relacni teorii a SQL, nez zacit s ORM. I kdyz to druhe vypada schudnejsi, tak neni.

Budes nechapave koukat, proc se veci ve Scale delaji, jak se delaji. Lepsi je IMHO porozumet zakladum FP paradigmatu v jazyce, ktery je prinesl.

Ale je to tvuj boj..

[ehm]

Ale je to tvuj boj..

Přesně tak.

Mimochodem: S FP jsem seznámen na úrovni porozumění principům. Kdysi jsem se díval na LISP i Haskell. Neprogramoval jsem v tom, ale není to pro mě úplně nová oblast. Taky běžně píšu v Pythonu a nemám problém v něm přejít na úplně jiný způsob uvažování než jsem zvyklý z imperativních jazyků – alespoň nakolik to umím posoudit.

[Bystroushaak]

Mimochodem: S FP jsem seznámen na úrovni porozumění principům. Kdysi jsem se díval na LISP i Haskell. Neprogramoval jsem v tom, ale není to pro mě úplně nová oblast.

Imho to jen z popisu člověk nepochopí. Co jsem tak měl možnost vidět, tak to trvá pár let, než si člověk fakt zvykne na úplně jiné paradigma a má z toho to skutečné osvícení, ale především to chce praxi. Přeci jen jde o úplně jiný styl myšlení. Já jsem si třeba udělal vlastní lisp, přečetl knihu o programování v lispu, projel si pár tutoriálů, zkoušel jsem dělat v lisp-like jazycích a pořád si troufám tvrdit, že z toho chápu jen velmi hrubé obrysy. Jen z jsem nahlédl na tu stezku skrz ostatní lidi. Kdybych v tom dělal, tak budu hrozné prase. Spousta z těch věcí ani není záležitost jazyka, to jde skoro do filosofie.

Sám si tak říkám, že si někdy dám jen rok nebo dva lispu. Koukal jsem, že na clojure nabírají docela dost i juniory, tak to možná někdy vezmu jen abych se naučil pořádně něco nového.

[ehm]

Jen z popisu to fakt asi nepochopíš, ale zas tak dramatické mi to taky nepřijde. Zvlášť když jsem se přihlásil na kurz, který je přesně na tohle zaměřený. To byl ostatně ten důvod, proč jsem zvolil tuhle cestu – na naučení syntaxe by mi stačila dokumentace. K tomu uvažování bych se pak ale musel dopracovat víc organicky.

Ale jinak se v tomhle ohledu spíš držím vác při zemi. Zas tak nadšený z různých paradigmat a způsobů vyjádření programu nejsem. Asi nemám ambici hledat (popř. vytvářet) dokonalý způsob, jak počítače programovat.

Zásadní nedostatky vidím v úplně jiných oblastech. Tam bych nejraději všechno překopal a změnil. Něco z toho se z části překrývá s tvými postoji; obecně bych to shrnul pod (I.) reprezentaci informací, (II.) běžnou uživatelskou interakci s počítačem.

[Bystroushaak]

na naučení syntaxe by mi stačila dokumentace. K tomu uvažování bych se pak ale musel dopracovat víc organicky.

Hah. Na naučení syntaxe by ti stačil jeden den. Na to abys fakt skutečně pochopil makra stačí taky pár dní a pár ukázek. Na to abys pochopil co všechno je v clispu, pak už stačí jen asi tři životy. Tím nechci vychvalovat clisp, protože prakticky ho moc lidí nepoužívá, ale ta míra kódu, co je v něm napsaná .. Zatím pokaždé, když jsem viděl nějaký fakt cool koncept, tak jsem zjistil, že v clispu je asi tak 20-30 let už dávno implementovaný. A pak ta filosofie - začít psát ve skutečně jiném paradigmatu, to chce z mé zkušenosti roky práce. Já to třeba u FP naprosto nedávám, i když vím, co a jak, tak stejně pořád jedu v zajetých myšlenkových kolejích přemýšlení nad problémy.

[ehm]

Hah. Na naučení syntaxe by ti stačil jeden den.

Měl jsem na mysli tu Scalu. Naučit si tam veškerou syntaxi za jeden den si nedokážu moc představit.

A pak ta filosofie - začít psát ve skutečně jiném paradigmatu, to chce z mé zkušenosti roky práce. Já to třeba u FP naprosto nedávám, i když vím, co a jak, tak stejně pořád jedu v zajetých myšlenkových kolejích přemýšlení nad problémy.

To je dost možné. Mým cílem ale není FP dokonale ovládnout a přijmout ho jako své hlavní paradigma. Tohle je jen takový další průzkumný vrt do nové oblasti. Jak s tím konkrétně naložím zatím přesně nevím – to záleží, co tam najdu. Co především očekávám jsou věci, které bych si odnesl i do imperativního programování nebo že mě to přivede na obecnější věci z computer science.

Jak říkám, nejsem ohledně těch paradigmat zas tak enthusiastický. FP mi ani nepřijde jako intuitivní a praktický způsob, jak nad vývojem SW uvažovat.

Třeba autoři Xmonadu, který je napsaný v Haskellu, AFAIK používají různé formální metody, dokazování apod. Díky tomu je to údajně nesmírně stabilní a bez chyb. Pro takový styl vývoje FP určitě může být správná volba – ale kdyby se obdobný přístup používal u imperativního programování, změny se do kódu zanášely velmi šetrně a důkladně se nad vším uvažovalo a diskutovalo, tak by výsledky byly podobné. Co je časově efektivnější si netroufám porovnávat.

[smazáno]

Osobne jsem si z hrani se scalou odnesl velice dulezitou zkusenost a to ze muze existovat jazyk pro prakticke pouziti horsi nez java (ktery se o to umyslne nesnazi). A v celku to sedi s tim jak javisti scalu neznaji a adoruji.

[Bystroushaak]

No ono by možná stačilo, kdyby aspoň ten kouzelník programátor vždycky věděl, s jakým typem se tam pracuje. Ale tohle bych řekl, že mnohdy ani pořádně neví.

To je právě ta java v pythonu. Programátorovi by mělo být úplně jedno s jakým typem pracuje, podstatné by pro něj měla být kategorie interface toho datového typu.

Co je mu po tom, jestli zrovna pracuje s tuplem, polem, nebo generátorem? Podstatné pro něj je, že se přes to dá iterovat, nebo to třeba sečíst, nebo ..

Zábavné je, že to je tak nějak podstata polymorfismu, jen Java si z ní (ve zcela tradičním zkrypleném duchu) bere jen pár procent toho, co vlastně nabízí.

Nejlepší je, že postupně se ty featury do javy dostávají, jenže to bude trvat asi tak příštích padesát let a tím jak to budou roubovat na jádro něčeho, co na to nebylo koncipované, tak z toho bude pořád horší a horší zkroucenina se spoustou přílepků.

Nedávno jsem se za břicho popadal, když jsem zkoumal ty lambdy v javě, což je skoro všude naprosto přirozená věc, kterou je radost používat a java z toho udělala takovou těžkopádnou vymyšleninu, která je funkcionalitou skoro hybrid s generátory.

[ehm]

Nedávno jsem se za břicho popadal, když jsem zkoumal ty lambdy v javě, což je skoro všude naprosto přirozená věc, kterou je radost používat a java z toho udělala takovou těžkopádnou vymyšleninu, která je funkcionalitou skoro hybrid s generátory.

Wut? Určitě ses díval na lambdy?

[Bystroushaak]

Si zkus lambdu uložit do proměnný.

[ehm]

Z hlavy a na mobilu:

Function<Integer, Integer> wut = n -> n + 1;
System.out.println(wut.apply(2));

V čem je problém?

[Bystroushaak]

To ti fakt nepřipomíná generátory?

[ehm]

Ne.

[John_Pitralon]

No ty interfacy by pro code checker možná postačovaly. A jsou statické. Přece nikdo nebude za běhu dynamicky předefinovávat interfacy. I když nějaký kouzelník asi ano.

[Bystroushaak]

Za běhu pravděpodobně nikdo interface předefinovávat nebude, ale nevíš co za objekty se tam dostane, resp. to musíš vyhodnotit až ve chvíli, kdy se to stane, jinak se připravíš o featury. Tudíž jsi na tom úplně stejně, jako kdybys to vůbec nekontroloval a prostě to nechal vyhodit výjimku ve chvíli, kdy ten kód zkusí přistoupit k atributu, který tam není.

[ehm]

Moc nevidím, jak se to vylučuje se statickým typováním. I v té Javě se považuje za dobrou praxi dávat tam nejabstraktnější možný typ.

Pokud metoda pouze konzumuje stream hodnot, měla by vyžadovat Iterable. Je jedno, jestli konkrétní objekt je typu List, Set, nebo úplně jiného.

V Pythonu odpadá formální statická definice rozhraní. Místo toho se lze spolehnout na to, že funkce volá metodu foo, a pokud tedy tebou předaný objekt obsahuje metodu foo (akceptující požadovaný počet argumentů a splňující daný kontrakt), bude to fungovat.

Jediný praktický rozdíl je v tom, že když máš v Javě metodu akceptující Iterable a pracuješ s objektem, který Iterable neimplementuje a nemůžeš to změnit (třeba proto, že to pochází z nějaké 3rd party knihovny), tak to musíš buď zkonvertovat, nebo použít proxy.

Pak je tam ještě drobný rozdíl v tom, že když nad tím objektem nějakou metodu voláš podmíněně a ty víš, že ta podmínka nebude vyhodnocena pozitivně, tak tu metodu nemusíš vůbec deklarovat. V Javě se to někdy obchází abstraktní třídou s prázdnými těly metod, takže přetížíš jen to, co fakt chceš implementovat.

Moc v tom nevidím praktický rozdíl. Taky by mě zajímalo, co si představuješ pod:

Nejlepší je, že postupně se ty featury do javy dostávají, jenže to bude trvat asi tak příštích padesát let a tím jak to budou roubovat na jádro něčeho, co na to nebylo koncipované, tak z toho bude pořád horší a horší zkroucenina se spoustou přílepků.

Protože cca od Javy 5 (což je tak zhruba poslední verze, o které něco vím) si nic takového nevybavuji.

[Bystroushaak]

Jediný praktický rozdíl je v tom, že když máš v Javě metodu akceptující Iterable a pracuješ s objektem, který Iterable neimplementuje a nemůžeš to změnit (třeba proto, že to pochází z nějaké 3rd party knihovny), tak to musíš buď zkonvertovat, nebo použít proxy.

To ale není malý rozdíl. V Javě, když něco interface Iterable nepodporuje, ale přesto se to jinak chová úplně stejně, tak jí do toho musíš nějak naroubovat, což může vést k signifikantním přepisům.

Protože cca od Javy 5 (což je tak zhruba poslední verze, o které něco vím) si nic takového nevybavuji.

Tak zrovna ta lambda je hezká ukázka. Generika jsou další. Nakonec se dostane i na ten late binding (myšleno v ne tolik zprasené podobě, v jaké se o něj snaží skrz znásilnění objektů a typového systému).

[ehm]

To ale není malý rozdíl. V Javě, když něco interface Iterable nepodporuje, ale přesto se to jinak chová úplně stejně, tak jí do toho musíš nějak naroubovat, což může vést k signifikantním přepisům.

Je to malý rozdíl a k přepisům to vést vůbec nemusí. Prostě uděláš něco jako:

static <T> Iterable<T> convert(SameAsIterable<T> obj) {
    return new Iterable<T>() {
        @Override
        public Iterato<T> iterator() {
            return new Iterator<T>() {
                @Override
                public boolean hasNext() {
                    return obj.hasNext();
                }

                @Override
                public T next() {
                    return obj.next();
                }
            };
        }
    };
}

Nebo:

class SameAsIterableToIterableProxy<T> implements Iterable<T> {
    public final SameAsIterable<T> instance;
    private final Iterable<T> iterable;

    public SameAsIterableToIterableProxy(SameAsIterable<T> instance) {
        this.instance = instance;
        this.iterable = convert(instance);
    }

    @Override
    public Iterator<T> iterator() {
        return iterable.iterator();
    }

    private static <T> Iterable<T> convert(SameAsIterable<T> obj) {
        // stejný kód jako výše
    }
}

Dlužno podotknout, že tohle je krajní případ a v praxi se s něčím podobným setkávám naprosto minimálně. Mimojiné proto, že je dobrou praxí ve své codebase pracovat se stejnými typy, a pokud třeba nějaká 3rd party knihovna zavádí jiné typy, tak to rovnou konvertovat na vhodné typy na té nejnižší možné úrovni. Pak nemáš svůj kód podobnými nekompatibilními instancemi vůbec prolezlý a konverze řešit nemusíš.

Tohle prostě není problém a není to solidní argument. Obdobně bych mohl tvrdit, že pokud mám v Pythonu objekt, který má metodu foo, ale nějaká funkce vyžaduje metodu se stejným kontraktem nazvanou bar, tak to nebude fungovat, aniž bych objekt buď zkonvertoval, nebo do něj přiřadil alias bar = foo – ale co když jméno bar bude zase potřeba jinde, nebo už bude zabrané?

Absence interfaců a statického typování nic užitečného nepřináší – pouze to umožňuje psát trochu stručnější kód, který pak ale musíš (měl bys) kompenzovat dokumentací. Je lepší popsat to ve strojově zpracovatelném formátu, nebo v deklaraci funkce napsat, že akceptuješ libovolný objekt a v dokumentaci vysvětlovat, že v tom objektu očekáváš takové a makové metody, properties apod.?

Výhodu to představuje výhradně při rapid prototypingu, jiné situace si neumím představit. A i u toho prototypingu to víc pomůže nezkušeným programátorům, kteří nedokážou myslet na pár kroků dopředu a nadeklarovat si ty rozhraní ihned.

Tak zrovna ta lambda je hezká ukázka.

Lambda je mírně nepřesně řečeno jen elegantnější zápis anonymní třídy. Mírně nepřesně proto, že jsou tam tuším nějaké rozdíly ohledně scopů, a taky se to myslím jinak zkompiluje. Ale to není podstatné.

Jak to souvisí s duck-typingem?

Generika jsou další.

S volným (neomezeným) typovým parametrem T můžeš pracovat pouze jako s instancí typu Object. Jediný rozdíl je v tom, že za tebe jazyk řeší přetypování a kontroluje, co leze dovnitř a ven.

Nebyl to krok k dynamičnosti a duck-typingu, ale naopak ke striktnějšímu typovému systému. Dřív jsi musel při každém čtení z Listu dělat přetypování, protože to vracelo prostě jen ten Object.

Nakonec se dostane i na ten late binding (myšleno v ne tolik zprasené podobě, v jaké se o něj snaží skrz znásilnění objektů a typového systému).

Mi přijde, že sem prostě jen tak házíš termíny a ani pořádně nevíš, co znamenají. Mrkni sem.

Pokud myslíš něco ve smyslu přiřazování metod do objektu za běhu, tak fakt silně pochybuju, že by to v Javě někdy bylo, protože to tam nedává naprosto žádný smysl.

[ehm]

Solch dynamisch. Viel wow.

DEMO.

[Bystroushaak]

Výhodu to představuje výhradně při rapid prototypingu, jiné situace si neumím představit. A i u toho prototypingu to víc pomůže nezkušeným programátorům, kteří nedokážou myslet na pár kroků dopředu a nadeklarovat si ty rozhraní ihned.

Meh, vrátil jsem se unavený z posilovny a seznal jsem, že na tohle téma už se mi nechce diskutovat, protože bych do toho musel dát moc námahy.

Lambda je mírně nepřesně řečeno jen elegantnější zápis anonymní třídy. Mírně nepřesně proto, že jsou tam tuším nějaké rozdíly ohledně scopů, a taky se to myslím jinak zkompiluje. Ale to není podstatné.

Jak to souvisí s duck-typingem?

S duck typingem asi nijak, psal jsem že je to jeden z kroků, kdy se do javy přidávají featury z ostatních /dynamičtějších/ jazyků a to dost kostrbatě. Například zrovna s lambdou bývá jinde radost pracovat, což se o imho o téhle obludce vytvářející anonymní třídy zrovna moc říct nedá.

Nebyl to krok k dynamičnosti a duck-typingu, ale naopak ke striktnějšímu typovému systému. Dřív jsi musel při každém čtení z Listu dělat přetypování, protože to vracelo prostě jen ten Object.

Imho se tím typový systém nijak striktnější nestal, jen vzrostl komfort programátora.

Mi přijde, že sem prostě jen tak házíš termíny a ani pořádně nevíš, co znamenají. Mrkni sem.

Hah. Na to jsem přesně koukal, jen abych si byl jistý, že java late binding tak jak se běžně chápe fakt nemá a to taky nemá. Schválně si přečti i třeba tu lispovou podkapitolu, což je prostě něco úplně jiného.

[ehm]

Meh, vrátil jsem se unavený z posilovny a seznal jsem, že na tohle téma už se mi nechce diskutovat, protože bych do toho musel dát moc námahy.

Chápu. Došly argumenty.

S duck typingem asi nijak, psal jsem že je to jeden z kroků, kdy se do javy přidávají featury z ostatních /dynamičtějších/ jazyků a to dost kostrbatě. Například zrovna s lambdou bývá jinde radost pracovat, což se o imho o téhle obludce vytvářející anonymní třídy zrovna moc říct nedá.

S dynamičností to nemá společného vůbec nic. To je opět naprosto zmatené užití termínu.

Imho se tím typový systém nijak striktnější nestal, jen vzrostl komfort programátora.

Je rozdíl, jestli metoda deklaruje, že vrací seznam objektů (a programátor si musí zjistit jejich typ a přetypovávat je), nebo seznam objektů daného typu.

Hah. Na to jsem přesně koukal, jen abych si byl jistý, že java late binding tak jak se běžně chápe fakt nemá a to taky nemá. Schválně si přečti i třeba tu lispovou podkapitolu, což je prostě něco úplně jiného.

Ono je v tom článku taky třeba napsáno (v souvislosti s virtuálními metodami):

Usually, the "late binding" term is used in favor of "dynamic dispatch".

Tedy to neoznačují za chybné užití.

Ale ono je to jedno – late binding v tom významu, v jakém jsi to myslel, se v Javě v dohledné době neplánuje a napříč komunitou je to asi poslední věc, kterou by někdo požadoval. Pokud po tom někdo fakt hrozně touží, tak už dnes asi nepoužívá Javu, ale Groovy, který to podporuje. Tedy tvoje domněnka není pravdivá.

Jinak mám za to, že třeba hrabání do cizího prototypu je za prasečinu docela považováno i v JS komunitě a naopak třeba immutable (a knihovna immutable.js) je tam strašný buzzword. Pokud si správně vzpomínám, tak třeba Haskell na neměnných hodnotách staví docela dost (JS1 možná upřesní) a celkově tedy ta proklamovaná dynamičnost a možnost cokoliv přepisovat a předefinovávat runtime nemá nutně takový význam ani v jazyce, který silněji adoptuje funkcionální paradigma. Je to podobná prasárna jako dříve globální proměnné.

Softwarové inženýrství zná metriky jako životnost proměnných apod., ale to opět sklouzáváme k tomu, jestli se výběr a hodnocení jazyka řídí víc emocemi, nebo racionalitou. Co to asi bude, když, cituji:

což se o imho o téhle obludce vytvářející anonymní třídy zrovna moc říct nedá

Výše jsme si ukázali, že s tou pomalostí Javy (OpenJDK) to asi tak horké nebude. V kódu je zápis stručný a žádné anonymní třídy tam nevidíš – jediný rozdíl je uvedení typu. Ale prostě je to obludka.

[Bystroushaak]

Chápu. Došly argumenty.

Do velké míry skutečně ano. Co jsem chtěl napsat jsem napsal. Mohl bych to ještě dál rozvést a zdůraznit konkrétní části, ale nevidím, že by se to vyplatilo ve smyslu zisk / námaha.

S dynamičností to nemá společného vůbec nic. To je opět naprosto zmatené užití termínu.

Ehm, to jsem ani nepsal. Psal jsem, že to má společnou inspiraci dynamickými jazyky a jejich featurami.

Je rozdíl, jestli metoda deklaruje, že vrací seznam objektů (a programátor si musí zjistit jejich typ a přetypovávat je), nebo seznam objektů daného typu.

Vskutku tak jest.

Výše jsme si ukázali, že s tou pomalostí Javy (OpenJDK) to asi tak horké nebude. V kódu je zápis stručný a žádné anonymní třídy tam nevidíš – jediný rozdíl je uvedení typu.

O pomalosti javy jsem taky vůbec nic nepsal, dokonce naopak, už někdy v roce 2008 jsme afaik vedli diskuzi, že java je asi 100x rychlejší, než python (Nevygenerovaná čísla, jestli si pamatuješ). V téhle diskuzi jsem psal, že python není tak pomalý, když se použije pypy, což jak ukazují benchmarky nahoře vskutku není.

celkově tedy ta proklamovaná dynamičnost a možnost cokoliv přepisovat a předefinovávat runtime nemá nutně takový význam ani v jazyce, který silněji adoptuje funkcionální paradigma.

Ta proklamovaná dynamičnost imho nikdy nebyla proklamovaná s výhodou možnost přepisovat a předefinovávat runtime, ale kvůli ostatním vlastnostem. Minimálně v téhle diskuzi byly naopak tyhle věci zcela konzistentně označovány jako prasečiny.

V kódu je zápis stručný a žádné anonymní třídy tam nevidíš – jediný rozdíl je uvedení typu. Ale prostě je to obludka.

Ano, to podle mého subjektivního názoru vskutku je. Osobně mi nedá, než to srovnávat třeba s D, kde implementaci považuji za podstatně elegantnější z hlediska programátora.

[ehm]

Psal jsem, že to má společnou inspiraci dynamickými jazyky a jejich featurami.

Nějak to tam nevidím. Přijde mi to divné přirovnání. Třeba PHP dynamické je, ale lambdy (resp. anonymní funkce) zavedlo snad až v 5.3 (pokud tedy PHP lze vůbec považovat za jazyk). C dynamické vůbec není a GCC anonymní funkce stejně podporuje. Ještě to umí nested functions.

Je to samostatně stojící věc, která s dynamičností nemá IMO společného vůbec nic – snad kromě historických souvislostí, kdy se podobné konstrukce objevovaly výhradně nebo převážně v dynamických jazycích. Ale není to věc, která ten jazyk dělá dynamickým, tak bych to z toho prostě vyjmul.

O pomalosti javy jsem taky vůbec nic nepsal, dokonce naopak, už někdy v roce 2008 jsme afaik vedli diskuzi, že java je asi 100x rychlejší, než python (Nevygenerovaná čísla, jestli si pamatuješ).

Něco mi ta nevygenerovaná čísla říkají, ale už si to nepamatuju. Hlavně jsem ale v roce 2008 v Javě vůbec neprogramoval a skoro nic o ní nevěděl – používal jsem C++, Python a PHP a k Javě jsem měl silnou iracionální pubertální averzi. Řekl bych, že jsme tu diskuzi vedli až o pár let později, ale téma ani svůj postoj si už nepamatuju.

Pomalost jsem zmiňoval proto, že jsem spekuloval nad významem toho slova oblůdka.

Ta proklamovaná dynamičnost imho nikdy nebyla proklamovaná s výhodou možnost přepisovat a předefinovávat runtime, ale kvůli ostatním vlastnostem.

To je ale IMO jedna z klíčových vlastností dynamických jazyků. A volně jsem tím navazoval na můj rozbor, proč duck typing výhody nepřináší. Ale je možné, že v téhle části diskuze jsem se už zamotal; začínám mít problém to držet v paměti.

Ano, to podle mého subjektivního názoru vskutku je. Osobně mi nedá, než to srovnávat třeba s D, kde implementaci považuji za podstatně elegantnější z hlediska programátora.

Nevidím tam rozdíl. S D jsem se před časem seznámil jen velmi letmo, tak jsem se teď díval do specifikace. Mají tam tenhle příklad:

auto twice  = function (int x) => x * 2;
// ...
writeln(twice(i));

Je tam deklarace proměnné twice odvozeného datového typu (type-inference). Pak následuje samotná deklarace funkce. Následné volání se nijak neliší od ostatních funkcí (tj. kulaté závorky hned za identifikátorem atp.).

V Javě bys měl něco jako:

Function<Integer, Integer> twice = n -> n * 2;
// ...
System.out.println(twice.apply(i));

Všimni si, že D sice podporuje type-inference pro proměnnou, ale aby bylo schopno ten typ korektně odvodit, je potřeba typ deklarovat přímo u argumentu. V Javě musíš nadeklarovat typ proměnné, ale není nutné to už opisovat u argumentů – type-inference se použije tam.

Skutečný rozdíl je tedy pouze ve volání – v D to zavoláš stejně jako jakoukoliv jinou funkci, v Javě s funkcí pracuješ jako s objektem.

Smysl to začne dávat ve chvíli, kdy vezmeš v úvahu, že Java je stále silně objektově orientovaná a pomocí lambdy lze implementovat libovolné rozhraní s právě jednou metodou. Tedy například:

interface Listener {
    void onWhatever();
}

// ...
Listener l = () -> {
    // whatever
};

// použití:
l.onWhatever();

Snad by bylo možné rozšířit jazyk tak, že při práci s typem, který má právě jednu metodu, lze tuto metodu zavolat bez psaní jejího názvu pouhým uvedením kulatých závorek. Nevidím v tom ale zas tak velký smysl a za zesložitění jazyka to asi nestojí (i.e. getFunction()()).

[Bystroushaak]

Nějak to tam nevidím. Přijde mi to divné přirovnání. Třeba PHP dynamické je, ale lambdy (resp. anonymní funkce) zavedlo snad až v 5.3 (pokud tedy PHP lze vůbec považovat za jazyk). C dynamické vůbec není a GCC anonymní funkce stejně podporuje. Ještě to umí nested functions.

Je to samostatně stojící věc, která s dynamičností nemá IMO společného vůbec nic – snad kromě historických souvislostí, kdy se podobné konstrukce objevovaly výhradně nebo převážně v dynamických jazycích. Ale není to věc, která ten jazyk dělá dynamickým, tak bych to z toho prostě vyjmul.

Protože nečteš co píšu. Inspirace dynamickými jazyky neznamená, že se z toho stává dynamický jazyk, jen že to získává dynamickými jazyky inspirované featury.

To je ale IMO jedna z klíčových vlastností dynamických jazyků. A volně jsem tím navazoval na můj rozbor, proč duck typing výhody nepřináší. Ale je možné, že v téhle části diskuze jsem se už zamotal; začínám mít problém to držet v paměti.

Python, či lisp je postavený nad určitým setem axiomů (PHP mimochodem není), ze kterých potom odvozováním vyrůstají všechny možné vlastnosti. Mezi ty vlastnosti patří i možnost dynamicky měnit například classy, to ale neznamená, že je to důvod, proč dynamické jazyky existují, naopak, to je více/méně vedlejší efekt (v tomhle případě že classy i funkce jsou first class citizen).

[ehm]

Protože nečteš co píšu. Inspirace dynamickými jazyky neznamená, že se z toho stává dynamický jazyk, jen že to získává dynamickými jazyky inspirované featury.

Ale čtu. Na tohle jsem přesně reagoval. Přijde mi divné tvrdit, že je to vlastnost inspirovaná dynamickými jazyky – není to společná vlastnost všech dynamických jazyků a možná je tam leda nějaká historická souvislost, kdy (třeba) lambdy zaváděly zejména jazyky, které byly dynamické. Což je ale nepodstatná souvislost.

Nedává to smysl ani z hlediska kontextu. Vedla se diskuze o statických vs. dynamických jazycích. Ty jsi pak prohlásil, že do Javy se dostávají některé konstrukce inspirované dynamickými jazyky a za příklad jsi uvedl tu lambdu. Kdyby Java zavedla try/catch/else/final po vzoru try/except/else/finally, jak moc by bylo na místě říct, že Java adaptuje vlastnost jednoho dynamického jazyka...? Není to vysloveně nepravdivý výrok, ale je to zavádějící.

Smysluplnější by bylo říct, že lambda v Javě (a související API) je inspirovaná funkcionálními jazyky.

[xkucf03]

Podstatné pro něj je, že se přes to dá iterovat, nebo to třeba sečíst, nebo ..

Od toho jsou rozhraní a předci.

Když se metoda jen stejně jmenuje a používá stejné typy, tak to zdaleka ještě neznamená, že má i stejný význam. Můžeš mít třeba getVěk() a jednou to bude vracet stáří osoby v letech a jindy to bude vracet konstantu označující novověk, starověk, středověk… Oboje můžeš třeba sečíst a spočítat průměr, ale smysl to dává jen u toho prvního typu objektů. Význam těch hodnot je totiž jiný.

V zásadě můžou nastat případy:

• třídy implementují stejné rozhraní a lze s nimi pracovat typově bezpečně společným způsobem
• metody jsou stejně pojmenované a mají stejnou návratovou hodnotu a typy a hlavně stejný logický význam, ale neimplementují společné rozhraní
• metody jsou stejně pojmenované a mají stejnou návratovou hodnotu a typy, ale rozdílný logický význam
• metody se jmenují jinak a možná mají i trochu jiné typy nebo pořadí parametrů, ale z logického pohledu dělají totéž

Ten duck-typing lze použít jen ve druhém případě. To bude ale dost málo časté – víceméně náhoda. Daleko pravděpodobnější jsou ty ostatní případy – buď dojde k chybě, protože používáš jako kachnu něco, co se nechová jako kachna, nebo si budeš muset stejně udělat nějaký adaptér/proxy, protože se metoda jmenuje jinak nebo má trochu jiné parametry.

Je to otázka priorit, ale podle mého těch užitečných případů je moc málo na to, aby to vyvážilo ta rizika a škody (chybovost, složitost, nespolehlivost).

Pokud kód pochází od různých autorů (např. z různých knihoven), odkud by se měla vzít ta jednotnost? (že na sebe budou pasovat názvy a typy parametrů) Pokud se jsou autoři schopni dohodnout na jednotném názvu a parametrech, můžou se rovnou dohodnout na tom, že implementují společné rozhraní. Pokud se dohodnout neodkáží nebo ani k pokusu o dohodu nedošlo, tak je naopak pravděpodobné, že se netrefí ani do stejného názvu metody a typu/pořadí parametrů.

[smazáno]

Ano, presne na techto myslenkach je java postavena ... a prave kvuli dogmatickemu lpeni na teto jedine pravde je java takova !@#$ ... vzdyt to vidim dnes a denne u java programatoru jak s tim bojuji a jak jim tento tvrdohlavy pristup haze klacky pod nohy fakt temer na kazdem kroku. Opravdu me prekvapuje, ze i zkuseny programtor, ktery o vecech rad premysli, to proste nevidi :(.

[Bystroushaak]

Když se metoda jen stejně jmenuje a používá stejné typy, tak to zdaleka ještě neznamená, že má i stejný význam. Můžeš mít třeba getVěk() a jednou to bude vracet stáří osoby v letech a jindy to bude vracet konstantu označující novověk, starověk, středověk… Oboje můžeš třeba sečíst a spočítat průměr, ale smysl to dává jen u toho prvního typu objektů. Význam těch hodnot je totiž jiný.

Ano. Proto je na programátorovi, aby ten význam pochopil a použil ho tak jak fakt chce. Nepřijde mi, že by tě Java a statické typování nějak zbavilo nutnosti myslet, interpretovat věci, se kterými chceš pracovat a přiřazovat jim význam.

Pokud kód pochází od různých autorů (např. z různých knihoven), odkud by se měla vzít ta jednotnost? (že na sebe budou pasovat názvy a typy parametrů)

Z konvencí. Samozřejmě, že lidi můžou implementovat __add__() jako odečítání, ale tím jdou jen sami proti sobě, proto to nedělají.

[xkucf03]

Nepřijde mi, že by tě Java a statické typování nějak zbavilo nutnosti myslet, interpretovat věci, se kterými chceš pracovat a přiřazovat jim význam.

Rozhraní definuje nějaký kontrakt, na který se běžně spoléháš. Taky neřešíš, jestli ten který souborový systém dělá svoji práci, a jen zavoláš společnou (abstraktní) funkci operačního systému pro přístup k souboru. Pokud by tam byla chyba, tak se opraví v tom souborovém systému – ale ty svůj program upravovat nemusíš.

Můžou sice nastat případy, kdy někdo jiný ten kontrakt porušuje a na opravu chyby se bude čekat delší dobu, takže to musíš nějak ohackovat u sebe, ale to je nestandardní situace, kterou stačí vyřešit v rámci testování. Není důvod, aby tě to brzdilo při programování a musel jsi při volání každé metody zkoumat, jestli daný kontrakt splňuje nebo ne (což bude často dost netriviální úkol).

[kralyk z abclinuxu]

Ne, nešlo. Je to v přímém rozporu s dynamičností jazyka, která by narušila late binding, duck typing a co já vím co všechno ještě.

IMHO to není v rozporu nebo ne úplně. Třeba Go má duck typing interfaces. (Ale Go je zas dojebané tím, že je staticky typované, ale nemá generika.)

[Bystroushaak]

Jenže pokud to psal nějaký „kreativní“ dynamický programátor, který na tohle chování spoléhal a schválně v průběhu programu předefinovává funkce, tak to nebude vůbec jednoduché.

Jinak řečeno - pokud by chtěl někdo škodit, tak v pythonu může a v Javě jako ne?

[xkucf03]

Je otázka, jestli o to chápe jako škodění. Třeba z toho má radost a užívá si to jako výhodu, kterou mu dává dynamický jazyka a třeba kvůli tomu ušetřil pár řádků kódu.

[Bystroushaak]

Znova - a v javě by tohle škodění psaním prasáren*, které považuje za dobrý kód jako udělat nemohl? Nebo co je to za argument?

*Vím že by nemohl udělat tuhle, ale neříkej mi, že nemůže udělat žádnou.

[John_Pitralon]

On ten Pythonista asi škodit nikomu nechce, ale škodí už jen tím, že programuje. Napíše si tam samozřejmě parametry metod hezky bez typů. Pak jednoho dne přijde někdo, kdo na ten prasokód musí navázat.

[Bystroushaak]

1/10. Dej do toho trochu snahy, s takhle průhlednými pokusy o trolling ten blog do top 10 nejkomentovanějších nedostanem.

[Käyttäjä 11133]

Long way to go do top 10... :)

[Bystroushaak]

Nah, jen nějakých 210 komentářů. To by se dalo, kdyby se mi fakt chtělo.

[Käyttäjä 11133]

Ale na tvůj nejkomentovanější příspěvek už tento docela dotahuje...

[John_Pitralon]

To je přece realita. Nebo už jsem asi úplně mimo, nevím ani, co všechno je prachsprostý trolling.

[Bystroushaak]

To je přece realita. Nebo už jsem asi úplně mimo, nevím ani, co všechno je prachsprostý trolling.

Realita. Co je vlastně realita v kontextu diskuze? Jsou tvoje názory reálnější, než moje? Je realita subjektivní, nebo objektivně pozorovatelná?

Tahle diskuze se neodehrává na internetu, odehrává se v našich myslích, internet je jen nosné médium. Jsou naše mysli reálné? Jak moc reálnější, či nereálnější bude tahle diskuze jen pro někoho kdo to čte, speciálně, když se třeba ani nevyzná v programování? A co třeba za 10 let? Kdo uvěří, že se to skutečně stalo a nejsou to jen tahy štětcem na prázdné stránce navržené tak, abych se dostal do „top 10“ blogů na abclinuxu co do počtu komentářů?

Všechno co z tebe lidi vidí je jen pozlátko, maska, kterou si může vzít kdokoliv, řetězec 13 ASCII znaků. Jsi skutečný, nebo je za tou maskou tucet trolů? Kdo o tom může rozhodnout? Jak nám to můžeš dokázat? Kým vlastně jsi?

[John_Pitralon]

Popsal jsem realitu generování prasokódu. Lidé nagenerují miliardy řádek chaosu, a až pak následně jdou a pracně vymýšlejí různé hybridy jako TypeScript.

[kralyk z abclinuxu]

To je přece realita. Nebo už jsem asi úplně mimo

B) je správně.

[smazáno]

tam jeste nejsme? :)

[Bystroushaak]

První místo drží kupodivu Dag s jeho blogem Zmije za dveřmi, což je vzhledem ke krátkosti i překvapivě hodně čtený blog (30k přečtení, průměr je tady tak 1-2k). Poslední v „top 10“ je Amnestie s 930 komentáři. Tenhle blog má momentálně 740, takže ještě máme co dohánět ;) Už jsem měl i víc, třeba Strach z konkurence má 863.

Nejde mi ani tak o attention whoring, spíš:

When minds interact, new ideas emerge.

[ehm]

Můžu zařídit klidně první místo, zdrojáky ChronicPaina furt někde mám.

[ehm]

(To ani nemyslím tak, že bych to tu tolik zaspamoval, ale že třeba Kapica na to prve reagoval jako by to psal člověk. Čili to prošlo Turingovo testem a pokud sem naženeš dostatek slabomyslných jedinců, tak je vystaráno.)

[Bystroushaak]

Nah, taky mám asi pořád někde Slovenskou učitelku. Jde mi hlavně o konstruktivnější diskuzi, zaspamovat si to abych se dostal na první místo bych zvládl taky.

[trevor12]

jak si zobrazim ty nejvice ctene (s nejvice prispevky ..) ?

[Fluttershy, yay!]

/nej

[ehm]

Třikrát za úplňku měsíce a krákání havrana zakroužíš rukou nad křišťálovou koulí a ta ti zjeví nejvíce komentované diskuze.

[ehm]

Vedla se tu před časem diskuze, kde jsem argumentoval komplexností jazyka (syntaktickou). oryctolagus to tehdy přirovnal k abecedě. Nerad bych se opakoval, ale stručně to shrnu.

Zbytečný kód můžeš napsat v jakémkoliv jazyce bez ohledu na velikost abecedy. Vždy jsi schopen generovat nekonečné množství unikátních programů a dokonce i nekonečné množství unikátních programů, které plní zadání. Tedy nemá smysl zaobírat se návrhovými vzory apod., protože tam mezi jazyky nejsou rozdíly.

Rozdíl je v tom, že v Javě díky té menší abecedě existuje menší množství řešení, které splňují zadání, a nejsou na první pohled špatně. Alternativně by asi šlo říct, že existuje méně platných programů vyhovujících zadání o maximální délce N (neunikátních) symbolů.

Příklad byl tady.

A argument byl ten, že v užším jazyce je snažší se dohodnout na jednotném způsobu zápisu v rámci většího týmu. Nebude tam tak velká variabilita napříč autory.

U Javy si dokážu představit větší tým pracující nad jednou codebase než u Pythonu, kde by asi bylo lepší to od začátku udělat víc modulární (což pak má nevýhodu, že lidi nejde tak snadno přehazovat mezi týmy a projekty, zaškolení může trvat delší dobu apod.).

A nebo si nějaký senior sedne a naspecifikuje, kdy a jak zapsat jaké řešení, co se použít smí, co ne, co půjde vyhodnotit automaticky, tak přenést do nastavení různých linterů apod., a tím tak nějak duplikovat část práce, co jinde dělají tvůrci jazyků. Jen tím získáš trochu větší flexibilitu.

Profesionální (a zejména týmový) vývoj je do značné míry o tom, že si programátor nemá k napsanému kódu vytvářet citovou vazbu. Jazyk, který je z principu strohý, to přímo podporuje. Oproti tomu jazyky, které víc dbají na estetickou stránku a elegantnost, jsou s tím v rozporu, protože každý považuje za elegantní něco jiného.

Ono stačí, když narazím na StackOverflow. U Javy je většina kódů zapsaná dost podobně. Narazíš na prasárny, neefektivní konstrukce apod., ale způsob uvažování je většinou dost podobný. U Pythonu je těch řešení často víc a není snadné poznat, které je nejvhodnější – a lidi tam pak řeší, co tedy je ten nejvíc idiomatický způsob. (Sám sis stěžoval na lidi, co v Pythonu píšou jako v Javě. Za příklad jsi dával spíš navrhové chyby, ale předpokládám, že se to netýkalo jen toho.)

Mimochodem, tu odkazovanou diskuzi odstartovalo mé tvrzení, že:

Java je především o jednotném způsobu uvažování, řešení a zápisu. Lze toho docílit i v jiných jazycích, ale pak to klade větší nároky na celý tým, protože všichni musí dodržovat totožná pravidla. To se spoustě lidí nebude líbit, protože kód vnímají jako nástroj, jak prezentovat svoji domnělou genialitu, a snaží se toho docílit psaním co nejkratších a nejúdernějších konstrukcí. To je v profesionálním vývoji katastrofa. [...] Není tam tolik prostoru ukázat svojí znalost jazyka a zamachrovat si na zbytečně složitých konstrukcích, protože k tomu jazyk jednoduše nemá prostředky. To je vzácně nevýhoda, častěji výhoda.

Neznamená to, že syntakticky omezenější jazyk je nutně lepší, ale je to jeden způsob, jak se na to dívat.

[xkucf03]

+1

[JS1]

Rozdíl je v tom, že v Javě díky té menší abecedě existuje menší množství řešení, které splňují zadání, a nejsou na první pohled špatně.

Vidim dva problemy v tomhle tvrzeni.

Za prve, Java nema mensi abecedu nez Haskell, ale naopak. Java opravdu neni jednodussi jazyk.

Za druhe, tebou deklarovany cil "menší množství řešení, které splňují zadání, a nejsou na první pohled špatně" je v podstate odmitnuti principu DRY. Na tom neni samo o sobe nic spatneho, akorat ja osobne jsem proti.

A nebo si nějaký senior sedne a naspecifikuje

V jazycich s lepsimi moznostmi abstrakce se tohle resi knihovnami, ktere ti tyhle veci davaji uz predpripravene.

Napriklad, to co dela ten Lombok by bylo v Lispu jako knihovna maker a ta by se proste pouzila. (Ono to tak realne je, treba v Common Lispu je velka cast OOP typicky implementovana jako makra.)

[JS1]

A abych nezapomnel - Java neni jednodussi nez Haskell ani syntakticky, ani semanticky. To same urcite plati i pro Scheme, u Common Lispu jakztakz taky pokud beres standardni makra jen jako knihovnu a ne jako soucast jazyka (treba LOOP je trochu zverstvo).

[xkucf03]

Java neni jednodussi nez Haskell ani syntakticky, ani semanticky.

To myslíš vážně nebo to platí jen v nějakém tvém zvráceném paralelním vesmíru? Mluvím o složitosti ve smyslu kolik úsilí je potřeba vynaložit na praktické ovládnutí toho jazyka (nikoli o nějaké teoretické složitosti po odečtení „syntaktického cukru“). Protože zatím se mi to moc nezdá – věřím, že je jednodušší, než kompletní(!) C++, ale o tom tvém srovnání s Javou pochybuji.

Pokud vážně, tak: za jak dlouho bych se měl naučit Haskell, abych v něm dokázal psát srovnatelně složité programy (a srovnatelně efektivně) jako člověk, který zná třeba Javu SE a používá základní knihovnu? Jaké bys doporučil zdroje, literaturu a nástroje?

BTW: Když to srovnám třeba s C++ vs. Javou – mám dvě podobně tlusté knihy, jednu o Javě, jednu o C++ a to, co se v nich naučíš a jak složité/užitečné programy jsi pak schopný psát, je diametrálně odlišné (ve prospěch Javy).

[JS1]

To myslíš vážně nebo to platí jen v nějakém tvém zvráceném paralelním vesmíru?

100% vazne, mluvim o delce specifikace.

Mluvím o složitosti ve smyslu kolik úsilí je potřeba vynaložit na praktické ovládnutí toho jazyka

To je dost nejasne kriterium, ale v tvem pripade asi u Haskellu vic nez v Jave.

Pokud vážně, tak: za jak dlouho bych se měl naučit Haskell, abych v něm dokázal psát srovnatelně složité programy (a srovnatelně efektivně) jako člověk, který zná třeba Javu SE a používá základní knihovnu? Jaké bys doporučil zdroje, literaturu a nástroje?

Doporucil bych jednoznacne Haskell book (a pokud mas hluboko do kapsy, tak Learn you a Haskell, ale ta neni zdaleka tak dobra), pozdeji k tomu Co bych si pral vedet, Vse o monadach a Typeclassopedii. Z nastroju Stack.

Ale varovani - pokud k tomu nepristoupis s uplne cistou hlavou, tak nemas sanci se to naucit.

[xkucf03]

Díky, zkusím se na to někdy podívat. Jakkoli jsme v diskusi ve sporu, tak si tím nechci nechat ten Haskell znechutit :-) O tom jazyku vím dlouho a přijde mi celkem zajímavý, jen prostě dosud nebyla dostatečně silná motivace (investovaný čas vs. užitek).

[ehm]

Za prve, Java nema mensi abecedu nez Haskell, ale naopak.

Haskell bohužel neumím, takže to nedokážu posoudit.

Za druhe, tebou deklarovany cil "menší množství řešení, které splňují zadání, a nejsou na první pohled špatně" je v podstate odmitnuti principu DRY.

Tomu nerozumím.

V jazycich s lepsimi moznostmi abstrakce se tohle resi knihovnami, ktere ti tyhle veci davaji uz predpripravene.

Mně šlo spíš o to vymezit, jak co zapsat. Budeš se snažit psát spíš funkcionálně? Nebo spíš imperativně? Za jakých podmínek je dobrý nápad přetížit nějaký operátor? Resp. bude deskriptivnější název tvořen slovy, nebo speciálními znaky? Atd.

Ten rozhodovací strom musí být co nejjednodušší. Něco řešíš a měl bys být schopný velmi rychle vidět tu správnou možnost. Čím více toho je na výběr a čím menší rozdíly v tom jsou, tím je ta volba těžší.

[JS1]

Haskell bohužel neumím, takže to nedokážu posoudit.

Uz jsem to trochu naznacil nahore.

Kdyz jsem s Haskellem zacinal, dost me to matlo. Pripadalo mi, ze je slozity. Ale ve skutecnosti je to kombinace dvou veci:

- Pomerne dost "syntaktickeho cukru" nad temi zakladnimi koncepty. Ale to je jen zapis.

- Spousta funkci a operatoru, ktere jsou dulezite ale jsou definovane v knihovnach. Zase, je to jen o zvyku, zapamatovat si zakladni jmena.

Jazyk samotny je neuveritelne primitivni, ale velmi abstraktni.

Tomu nerozumím.

Chces omezit mnozstvi reseni, ktera nejsou zjevne spatne, to nutne musi omezit i takova kratka reseni, u kterych to patrne neni, a nemaji kratky ekvivalent, u ktereho to patrne je. Tedy omezujes nektera kratka reseni - popiras DRY.

Budeš se snažit psát spíš funkcionálně?

Nejde-li o rychlost, funkcionalne.

Za jakých podmínek je dobrý nápad přetížit nějaký operátor? Resp. bude deskriptivnější název tvořen slovy, nebo speciálními znaky?

To je uplne stejna otazka, jaky nazev zvolit. Pokud to jde, zvolis tradicni nazev, stejne tak se symboly, pokud to jde, zvolis tradicni symbol. Zadne hruzy jako metody add() misto operatoru +. Na papir taky nepises add(). (Na druhou stranu, definovat funkci na integrovani pomoci Unicode symbolu pro integral by asi taky bylo zvrhle, kdo to ma hledat na klavesnici?)

Čím více toho je na výběr a čím menší rozdíly v tom jsou, tím je ta volba těžší.

S tim souhlasim, ackoli tezko rict, jestli je to az tak ovlivnene samotnym jazykem. I v Haskellu (kde se nemusi resit nektera dilemata, co popisuji vys v te kritice konceptu "tridy") existuje pomerne dost skol, jak psat kod. Ono to myslim do znacne miry nejde eliminovat.

[ehm]

Pomerne dost "syntaktickeho cukru" nad temi zakladnimi koncepty. Ale to je jen zapis.

Ten syntaktický cukr může zvyšovat množství zdánlivě nebo i efektivně stejných řešení, ne?

Tedy omezujes nektera kratka reseni - popiras DRY.

Aha, chápu. To pak ano.

Nejde-li o rychlost, funkcionalne.

To byla řečnická otázka. Každý programátor si bude klást podobné otázky. Čím častěji se stane, že si programátoři na stejnou otázku odpoví jinak (a naprogramují to podle toho), tím spíš v tom kódu bude bordel.

Zadne hruzy jako metody add() misto operatoru +.

Jasně. Ale zrovna tak se někomu může líbit použít operátor ^ na získání průniku dvou kolekcí apod. Zápis bude o pár znaků stručnější, ale pokud význam toho operátoru nebudeš znát, bez dokumentace se neobejdeš. Oproti tomu rozumně zvolený název pochopíš i bez dokumentace.

Větší smysl by to snad dávalo, kdyby se více začaly používat ty Unicode znaky s matematickými symboly apod. Ale tam tu nevýhodu zmiňuješ sám...

Ono to myslim do znacne miry nejde eliminovat.

Ano, jde to samozřejmě jen do nějaké míry.

[JS1]

Ten syntaktický cukr může zvyšovat množství zdánlivě nebo i efektivně stejných řešení, ne?

Ne. Dukaz v matematice je stale ten stejny dukaz, at ho zapises anglicky nebo francouzsky nebo cesky. Obdobne je to i v pocitacich (protoze programy jsou fakticky dukazy).

Jasně. Ale zrovna tak se někomu může líbit použít operátor ^ na získání průniku dvou kolekcí apod. Zápis bude o pár znaků stručnější, ale pokud význam toho operátoru nebudeš znát, bez dokumentace se neobejdeš. Oproti tomu rozumně zvolený název pochopíš i bez dokumentace.

Haskell umoznuje libovolnou funkci pouzit jako operator, a naopak, libovolny operator pouzit jako funkci. To znamena, pokud chces pouzit infixovy operator oznaceny slovem, neni to problem.

Stejne tak neni velky problem si libovolny operator predefinovat, pokud po tom touzis.

[ehm]

Ne. Dukaz v matematice je stale ten stejny dukaz, at ho zapises anglicky nebo francouzsky nebo cesky.

Bingo. A ty jako matematik nechceš muset umět anglicky a francouzsky, ale chceš, aby to bylo zapsáno nějakou univerzální symbolickou notací – pokud možno přiměřeně jednoduchou.

To znamena, pokud chces pouzit infixovy operator oznaceny slovem, neni to problem.

Jasně. Ale problém je, když někdo nebude chtít použít slovo, protože mu třeba přijde víc cool udělat to jen symbolicky, i když to kódu ubere na přehlednosti.

[Bystroushaak]

Bingo. A ty jako matematik nechceš muset umět anglicky a francouzsky, ale chceš, aby to bylo zapsáno nějakou univerzální symbolickou notací – pokud možno přiměřeně jednoduchou.

Zrovna matematická notace je všechno, jen ne přiměřeně jednoduchá. Mi přijde, že každý field si vymýšlí úplně vlastní způsoby zápisu.

[kralyk z abclinuxu]

+1, viz už jen třeba skalární součin...

[ehm]

Bingo. A ty jako matematik nechceš muset umět anglicky a francouzsky, ale chceš, aby to bylo zapsáno nějakou univerzální symbolickou notací – pokud možno přiměřeně jednoduchou.

Bingo. A ty jako matematik nechceš muset umět anglicky a francouzsky, ale chceš, aby to bylo zapsáno nějakou univerzální symbolickou notací – pokud možno přiměřeně jednoduchou.

ale chceš

ale chceš

ale chceš

[Bystroushaak]

No, ale jestli chceš, ale nic pro to neděláš, tak vážně chceš?

[ehm]

A ty jako matematik

A ty jako matematik

A ty jako matematik

A ty jako matematik

A ty jako matematik

[JS1]

ale chceš, aby to bylo zapsáno nějakou univerzální symbolickou notací – pokud možno přiměřeně jednoduchou

Chci, a zrovna Haskell k ni ma hodne blizko, pokud jde o programy. Jedine, kde dela vyznamnejsi kompromis, je prave trocha syntaktickeho cukru, aby se v nem dal lepe realizovat "trochu matematicky" zapis.

Narozdil od Javy, ktera hodne syntaxe (a slovniku) prejima z C++, Haskell nedela syntakticky kompromis s beznymi programovacimi jazyky.

Snazis se dobre, ale obavam se, ze tvoje neznalost Haskellu ti neumoznuje presvedcive argumentovat v teto diskusi.

když někdo nebude chtít použít slovo, protože mu třeba přijde víc cool udělat to jen symbolicky

Ma tu moznost. Ale neni to jine, nez ze nekomu muze prijit "vic cool" pojmenovat funkci zavadejicim zpusobem. Pak to taky kodu ubere na prehlednosti.

Zase - problem jsou lide, nikoli moznosti programovacich jazyku.

Ono v tom Haskellu je to tak trochu stret dvou kultur - matematicke a programatorske (a ne nahodou, to je cela pointa FP). Matematicka se symboly problemy spise nema, programatorska nekdy ano. Ja znam obe, takze mi to nepripada jako problem, a prijde mi, ze to pripada jako problem jen tem lidem, kteri tu matematickou kulturu tolik neznaji.

[ehm]

Snazis se dobre, ale obavam se, ze tvoje neznalost Haskellu ti neumoznuje presvedcive argumentovat v teto diskusi.

Je to úplně klidně možné. Původně jsem srovnával především Javu a Python. Oba jazyky umím a píšu v nich. Pravda tedy, že v každém něco jiného, ale nějaké srovnání mám.

V případě Haskellu můžu reagovat výhradně na to, co píšeš, ale celkový kontext si jen domýšlím, nebo si do toho projektuji zkušenosti odjinud. Což není úplně fér, a proto jsem hned v první reakci výše řekl, že Haskell neumím.

Ale abych tedy ještě reagoval na ten zbytek:

Ma tu moznost. Ale neni to jine, nez ze nekomu muze prijit "vic cool" pojmenovat funkci zavadejicim zpusobem. Pak to taky kodu ubere na prehlednosti.

Tak samozřejmě se to může stát. Celé je to o tom, že když vyžaduješ alfanumerický idenfifikátor, tak to IMO častěji (ve větším množství případů) vyprodukuje srozumitelnější výsledek než když umožníš přetěžovat/definovat operátory.

IMO zejména mladší/méně zkušení lidé často mají tendenci používat něco jen proto, že se to naučili/chtějí si zamachrovat/whatever. V diskuzi výše se to třeba řeší u design patternů. Tady to řešíme třeba u těch operátorů. Ano, i tady by to byla chyba jednotlivce, ale v tomto případě tomu lze předejít (i za cenu, že tím znemožníš i korektní použití). Při práci s kódem někoho jiného za to budeš rád.

[kralyk z abclinuxu]

Co by se podle tebe mělo stát, aby byl Haskell popoulárnější? Ideálně něco, co nevyžaduje velkou změnu v lidech, protože IMHO se nedá očekávat, že se lidi nějak zásadně změní.

Mam zkušenost s Elmem, vím, že je oproti Haskellu hodně zjednodušený, ale dost se mi líbil, a teď jsem ještě navíc té diskusi s javisty, takže bych si i vyzkoušel něco zajímavého, akorát mě odrazuje na Haskellu ta ne moc velká využitelnost v praxi...

[JS1]

Co by se podle tebe mělo stát, aby byl Haskell popoulárnější?

Nevim, co by se melo stat - jak uz jsem napsal vys, mam za to, ze proste prilis abstraktni jazyky jsou pro hodne lidi neprekonatelny problem (nebo spise problem, ktery prekonat nechteji). A proto se neujal zadny z nich.

akorát mě odrazuje na Haskellu ta ne moc velká využitelnost v praxi

Co jsem slysel (a trochu chapu ty duvody), tak je to fakt skvele treba na psani kompilatoru. Takze az/jestli budes mit takovy projekt, muzes to zkusit. Zkus se inspirovat tady.

[xkucf03]

Zkus se inspirovat tady.

Já tam tedy vidím:

• Data science: Immature
• Numerical programming: Immature
• Front-end web programming: Immature
• Distributed programming: Immature
• Standalone GUI applications: Immature
• Machine learning: Immature
• Game programming: Immature
• Systems / embedded programming: Bad / Immature
• Mobile apps: Immature? / Bad? (Uncertain)
• ARM processor support: Immature
• Computer Vision: Immature
• Education: Immature
• Databases and data stores: Immature
• Debugging: Immature
• Cross-platform support: Immature
• IDE support: Immature

což mi přijde dost omezující. (tím nezpochybňuji ty silné stránky – ty ale samy o sobě na dobrý jazyk/platformu/ekosystém nestačí)

[JS1]

Hele, mne to nepis - ja uz vymluv, proc se neco nenaucit, mam dost od jinych lidi.

[kralyk z abclinuxu]

Ok, díky.

[deda.jabko]

Puvodne jsem se uz nechtel zapojovat do teto diskuze, ale snad par poslednich poznamek.

ale chceš, aby to bylo zapsáno nějakou univerzální symbolickou notací

To je podle me nerealizovatelne. Jednotna notace se da maximalne udrzet v ramci nejake komunity, nikdy vsak nebude univerzalni, protoze kazdy ma jine zvyklosti a jine potreby. Muzes se snazit, ale bude to mit uspech jak esperanto.

muze pojmenovat funkci zavadejicim zpusobem. Pak to taky kodu ubere na prehlednosti.

To je hodne zavadejici argument. Pokud pouzijes slovni pojmenovani, jiz to si sebou prirozene nese nejakou informaci, ze ktere je (melo by byt, chces-li) zjevne, k cemu ta promenna/funkce/makro ma byt. Pokud pouzijes symbol (ktery prirozene nenese zadnou informaci), musis jeho vyznam znat nebo hledat v dokumentaci. Hodne neprakticke.

Proto je dobrym zvykem ve slusnem kodu (a treba i v matematickem zapisu) velke vyrazy rozepisovat a prirazovat k "promennym", ktere te donuti najit pojmenovani pro to, co dana cast vyrazu znamena, aby ten, co ten kod (text) po tobe cte, mohl sledovat myslenkove postupy.

Matematicka se symboly problemy spise nema, programatorska nekdy ano.

Nebude to tim, ze ta matematicka resi relativne uzce definovane problemy, kdy si vystaci s omezenym mnozstvim symbolu, pricemz programatorska resi mnohem rozsahlejsi ulohy. Srovnej matematicky clanek v zurnalu, vs. informacni system.

Zase - problem jsou lide, nikoli moznosti programovacich jazyku.

To je totalni IoC. ;-] Programovaci jazyky tu jsou pro lidi, ne naopak!

[pavlix]

Hlavně má matematika se symboli dost velké problémy a většinou se to obchází tak, že se slovně popíše kontext.

[JS1]

Nebude to tim, ze ta matematicka resi relativne uzce definovane problemy, kdy si vystaci s omezenym mnozstvim symbolu, pricemz programatorska resi mnohem rozsahlejsi ulohy. Srovnej matematicky clanek v zurnalu, vs. informacni system.

To bych nerekl. Ja myslim, ze informacnimu systemu by casto nejaka notace prospela, napr. kdybychom meli opravdu dobrou notaci transformace dat (relacni algebru?), tak by to kod hodne zkratilo a zprehlednilo. To, co se pouziva dnes (SQL) je takove "ADD 5 TO X GIVING Y."

Bohuzel, IS jsou s nami jen par let, takze se to zatim nevyvinulo, zatimco pouzivani symbolu v matematice se vyvijelo po staleti. Druhy aspekt asi je (a zase, myslim, ze IS by z toho profitovaly), ze symboly jsou v matematice uzitecne proto, ze mame "algebru" - tedy nejake formalni operace, ktere muzeme aplikovat bez premysleni.

Ale programovani v Haskellu timhle smerem k algebram trochu jde.. Ja si napriklad dovedu predstavit (aniz bych ji mel) algebru pro reportovani nebo kresleni (Excelovskych) grafu. Pokusy timhle smerem uz existuji, treba grammar of graphics. A pokud mas algebru, je to dobry kandidat pro zavedeni symbolicke notace.

Programovaci jazyky tu jsou pro lidi, ne naopak!

S tim souhlasim, a proto si myslim, ze je hloupost programatory zbytecne omezovat v moznostech toho, co mohou s jazykem delat. To se ovsem nijak nevylucuje s tim, dat jim k necemu standardni prostredek.

[xkucf03]

Ja myslim, ze informacnimu systemu by casto nejaka notace prospela

Už existuje: BPMN/BPEL, nebo různé rozhodovací tabulky a deklarativní programování. Mnohdy ten proces nebo tok dat jde zapsat líp než zadrátováním do kódu. Nicméně není to zadarmo – jsi o úroveň abstrakce výš, někdy to není dostatečně pružné, nebo rychlé (to se dá řešit kompilací do nativního kódu), nebo proto neexistují dostatečně vyspělé nástroje.

[xkucf03]

Ne. Dukaz v matematice je stale ten stejny dukaz, at ho zapises anglicky nebo francouzsky nebo cesky. Obdobne je to i v pocitacich (protoze programy jsou fakticky dukazy).

Matematické důkazy jsou maximálně úsporné, není v nich nic navíc. A formulovat je vyžaduje celkem dost úsilí.

Programy se tímhle stylem rozhodně nepíší a prakticky vždy obsahují nějakou redundanci nebo ne úplně nezbytné věci. Osekat každý kus programu na minimum by stálo víc nákladů než by to přineslo užitku. To si může dovolit vědec, který jednou za dlouho formuluje důkaz, který pak budou všichni opisovat. Ale programátor, který se živí vývojem softwaru, si těžko může dovolit vynakládat takové úsilí, aby program vytesal k dokonalosti (ve smyslu, že v něm není absolutně nic zbytečného).

[JS1]

Mas tak trochu pravdu, ale na moji pointe to nic nemeni.

[JS1]

Třeba z toho má radost a užívá si to jako výhodu

Nebo chape, ze jde o vedlejsi efekt jinych vlastnosti, ktere davaji dobry smysl. Napr. zde konkretne - funkce jsou hodnoty jako vsechno ostatni, jmena se na hodnoty vazou a je mozne stejna jmena vazat na jine hodnoty (prirazenim); z toho plyne, ze lze funkce za behu "modifikovat".

Ale kdyz vidim, jaky chaos v Jave delaji classloadery.. nevim, jestli je to jednodussi. IMHO takova vlastnost je obcas potreba.

[xkucf03]

Napr. zde konkretne - funkce jsou hodnoty jako vsechno ostatni, jmena se na hodnoty vazou a je mozne stejna jmena vazat na jine hodnoty (prirazenim); z toho plyne, ze lze funkce za behu "modifikovat".

Uznávám, že z tohoto pohledu je to asi konzistentní. Ale…

Nebo chape, ze jde o vedlejsi efekt jinych vlastnosti, ktere davaji dobry smysl.

…je právě otázka, jaký smysl to dává – podle mého to, že prvním přiřazením do proměnné ji zároveň deklaruji, má víc nevýhod než výhod. I když nebudeme řešit explicitní typy (mohlo to být klidně var/auto), tak výhodou je to, že jsme nemuseli napsat cca tři znaky. Naopak nevýhodou je možná chybovost a nespolehlivost programu, špatně předvídatelné chování. Opravdu to stojí za to?

[smazáno]

A proto je optional typing tak super - tam kde mi deklarace typu pomuze ji vyuziji a tam kde mi ublizuje pouziji vlastne takova "implicitni generika" ... sam pises ze generika jsou jedna z nejlepsi casti javy, tak proc je nemit s hezkou syntaxi? :)

[xkucf03]

tam kde mi ublizuje pouziji vlastne takova "implicitni generika"

Generika ti např. zaručí, že na výstupu budeš mít tentýž datový typ jako na vstupu nebo že mezi parametry bude nějaký vztah – např. jeden je Map<String,Long> a druhý je List<Long> – ale nemůžu tam nacpat Map<String,String> a List<Long>. Generika fungují i jako strojově čitelná dokumentace. Tím, že se jich člověk zabaví, nic nezíská.

Dynamické jazyky jsou něco jako „syntaktický cukr“ pro psaní stylem, kde všude používám jen typ Object a všude přetypuji na to, co se mi zrovna hodí. Problém tohoto stylu „programování“ ovšem není v tom, že musím napsat spoustu kódu navíc (to přetypování, což řeší ten „syntaktický cukr“), ale v tom, že je to nespolehlivé a špatně předvídatelné, napomáhá to vzniku chyb a hůř se s tím pracuje, protože část dokumentace chybí (nebo není strojově čitelná, tudíž nemůže být podporována nástroji a musí to člověk louskat ručně).

[Bystroushaak]

a hůř se s tím pracuje

[smazáno]

Jestli pouziva na python treba eclipse pydev tak se jeho pristupu fakt nedivim.

[xkucf03]

Pokud musím pustit debugger, abych zjistil, kde jsou jaké atributy/metody, místo abych otevřel dokumentaci resp. to viděl hned z typového systému, tak bych opravdu řekl, že se s tím hůř pracuje. Ale třeba je to jen subjektivní pocit :-)

[smazáno]

Tak z dokumentace to vyctes, pripadne si to muzes zkusit behem sekund treba z ipythonu, ale urcite souhlasim, ze tohle je vyhoda striktniho typoveho systemu. Resp. poradny standardizovany type hints v pythonu chybi (ale dela se na tom). Za ty proprietarni pycharm type hints by mel jit nekdo sedet.

[Bystroushaak]

Pokud musím pustit debugger, abych zjistil, kde jsou jaké atributy/metody, místo abych otevřel dokumentaci resp. to viděl hned z typového systému, tak bych opravdu řekl, že se s tím hůř pracuje.

Proč bys to neměl vidět v dokumentaci?

[xkucf03]

Jde o to, jestli budu vědět, kde tu dokumentaci otevřít. Pokud např. metoda nedeklaruje, jaký typ vrací nebo jakého typu jsou její parametry, tak nebudu vědět, ke kterým typům si mám nalistovat dokumentaci.

[Bystroushaak]

Jde o to, jestli budu vědět, kde tu dokumentaci otevřít. Pokud např. metoda nedeklaruje, jaký typ vrací nebo jakého typu jsou její parametry, tak nebudu vědět, ke kterým typům si mám nalistovat dokumentaci.

A pokud bude v javě definovat, že vrací object, tak jsi taky v háji. To neznamená, že je špatně jazyk, jen že někdo neudělal dokumentaci.

[smazáno]

Proto je potreba mit moznost pouzit oba pristupy. Pak muzes pouzit ten pristup, ktery na danou situaci padne lip.

Jako javistu te potesi ze optional typing je nejlepsi, alespon co jsem zatim videl, v groovy :).

[smazáno]

Uz jen kvuli tomu ze opravdovy chyby jako java.lang.OutOfMemoryError: PermGen space ti ten typovy system stejne nechytne.

[ehm]

Překvapivě...

[smazáno]

Ted tu chybu zrovna vyhazovalo abclinuxu, tak me to pobavilo ... a zvlast problem s PermGen space, coz je jeden z typickych umelych problemu, ktere si java vymyslela.

[ehm]

OpenJDK 8 už to nemá.

[ehm]

BTW - keywordy val a var se připravují pro Javu 10 (projekt Valhalla). Java 9 tu bude za cca dva měsíce, release Javy 10 se bude asi odvíjet zejména od množství potřebných bugfixů. Doufejme, že Jigsaw JDK nedestabilizoval, bugfixů bude málo a Java 10 tu bude coby dup spolu s rozšířením generik na primitivní typy, generickými enumy – jo, fakt to tam připravují, docela mindfuk – a – držte klobouky – odstraněním type-erasure. To by docela podstatně umazalo náskok C#, ale uvidíme, jak dlouho to bude trvat.

[Bystroushaak]

Nevedli jsme náhodou o kus výš diskuzi, že do javy jsou postupně doportovávány věci inspirované dynamickými jazyky, kde jsi tvrdil, že ne?

[ehm]

Type-inference. Pořád je to staticky typované, ale místo abys napsal:

List<Integer> list = new ArrayList<Integer>();

v Javě 6, nebo:

List<Integer> list = new ArrayList<>();

v Javě 7 (která zavádí tzv. diamond operator), tak napíšeš:

var list = new ArrayList<Integer>();

v Javě 10, nebo:

val list = new ArrayList<Integer>();

pokud to chceš final.

A hned se nabízí otázka, jestli to bude počítat s přetypováním. Tj. pokud budu trvat na tom, že chci vytvořit proměnnou typu X, ale instancuji Y, které X implementuje, tak můžu zapsat třeba:

val list = (List<Integer>) new ArrayList<Integer>();

nebo ještě lépe:

val list = (List<>) new ArrayList<Integer>();

Související otázka je, jestli takové podtypování vůbec dává smysl, protože mě při vytvoření nevadí, že je proměnná konkrétnějšího typu – a při předání někam, kde je vyžadováno jen konkrétní implementované rozhraní, se to přetypuje implicitně.

Čili o dynamičnosti zde hovořit nelze.

Pozn.: Ani jedna z těchto změn AFAIK ještě není schválena. Ale prozkoumává se to a možná existují nějaké první prototypy.

[smazáno]

A pritom je java interpretovany jazyk a slo by to tak jednoduse :).

[ehm]

*mně

[JS1]

podle mého to, že prvním přiřazením do proměnné ji zároveň deklaruji, má víc nevýhod než výhod

Akorat ze v Pythonu neprirazujes do promenne, ale vytvaris vazbu mezi jmenem a hodnotou. Nic jako "deklarace promenne" v Pythonu neni.

V Jave maji typ promenne (a tedy jmena s nimi spojena). V Pythonu maji typ hodnoty (nezavisle na jmenech).

[Bystroushaak]

Pokračování #890

poslední dobou mi přijde, že pokud do něčeho masivně zainvestuje vláda, tak to má lepší výsledky, než když do něčeho decentralizovaně investují lidé

OpenCard, Blanka, Centrální registr vozidel, Tojecool.cz, ...

Masivními investicemi jsem měl na mysli třeba 2% HDP, tohle všechno jsou takové vcelku nevýznamné projektíky.

[ehm]

Statistiky se neaktualizuji real-time. Aktuálně to hlásí Amnestie: 930, Jak se stát programátorem: 929. Skutečný počet příspěvků je ale 936 (resp. 937 i s tímto).

Čili po nejbližší aktualizaci jsme tam.

[smazáno]

holt je to napsany v jave

[smazáno]

... tak je to takovy pomalejsi

[Bystroushaak]

holt je to napsany v jave

Pouští se to někdy po půlnoci, přibližně v té době, co vypadne databáze.

[Bystroushaak]

Čili po nejbližší aktualizaci jsme tam.

Nice :)

[JS1]

Gratuluji ti, jsi prvni prispevek v tom Top 10, ktery se aspon trochu tyka tematu portalu..

A zda se, ze jsem mel pravdu.

[Agent]

Škoda, že sem už nechodí M. Ponkrác. Až na občasné výstřelky byl celkem fajn a to nemyslím nijak ironicky.

[Bystroushaak]

No. Já ho měl taky docela rád. Dokonce mám pořád v TODO:

☐ tracker ponkráce

[ehm]

Jsi si jistý, že reaguješ na správný příspěvek?

Ponkrác je určitě zajímavý člověk, ale ne nutně jen v pozitivním smyslu. K technickým věcem má co říct a ani ve zbylých ohledech mu nejde upřít schopnost myslet nekonvenčně, ale občas mi to přišlo fakt mimo.

Nejpozoruhodnější je na něm ta všudypřítomnost. On trackuje snad celý český Internet. V jednu dobu jsem na něj narážel fakt úplně všude. Jak vůbec stíhá něco jiného? Nebo je to no-lifer a nic jiného kromě astrologie už stíhat nepotřebuje? Těžko říct.

Nevybavuji si teď, kdy jsem tu od něj naposled viděl komentář, ale zas tak dlouho to nebude. On po tom ohlášení, že sem už chodit nebude, začal používat jiné nicky, ale lidi ho stejně poznali, tak možná začal obfuskovat i styl vyjadřování...

[Bystroushaak]

Nejpozoruhodnější je na něm ta všudypřítomnost. On trackuje snad celý český Internet. V jednu dobu jsem na něj narážel fakt úplně všude. Jak vůbec stíhá něco jiného? Nebo je to no-lifer a nic jiného kromě astrologie už stíhat nepotřebuje? Těžko říct.

Nebo k tomu má software. Ono už i RSS čtečka v tom hodně pomáhá, i když člověk nepřejde na další level.

[ehm]

Není to úplně nezbytné, pokud v tom máš systém. Třeba si někde eviduješ odkazy na navštívené diskuze a zaslané příspěvky...

[Agent]

Jsi si jistý, že reaguješ na správný příspěvek?

Ne, nikdy. Proč? Šlo mi o to, že pokud by se tu vyskyt, tak by jednak mohla být debata ještě zajímavá, druhak by se tento zápisek s diskusí posunul zase o nějakou pčíčku vejš, dost možná by i atakoval první trojici.

Nejpozoruhodnější je na něm ta všudypřítomnost. On trackuje snad celý český Internet. V jednu dobu jsem na něj narážel fakt úplně všude. Jak vůbec stíhá něco jiného?

To samé by ale mohl říct i on o tobě

[ehm]

To samé by ale mohl říct i on o tobě

Diskuze čtu jen zcela výjimečně a nejeví se jako úplně pravděpodobné, že ve všech případech, kdy Ponkrác něco komentuje, do té diskuze taky nahlédnu a trefím se přímo na jeho příspěvek.

[smazáno]

Haha, to uz nezakecas ze si ponkrac :).

[Bystroushaak]

Částečně jako odpověď na #1183:

Tahle diskuze o javě pythonu a typovém systému a patternech ukazuje jeden pěkný kognitivní bias, na který mě upozornily až videa Petersona (bohužel nenajdu) a to že lidi mají tendence považovat vlastní názory za správné a když se potkají s někým, kdo zastává jiný názor, mají pocit, že musí být špatně. Proto se ho snaží vyvrátit a čím méně se to daří, tím víc si myslí, že protistrana tomu naschvál vzdoruje.

Zde v diskuzi je možné vidět dvě různé školy návrhu software, kde jedna strana do jisté míry nechápe tu druhou a má o ní své pochybnosti. Osobně jsem za tu diskuzi fakt rád, protože byla velmi poučná, konstruktivní a inspirativní a musím říct, že jsem si z ní mnoho odnesl. Musím vychválit zdejší komunitu, protože takhle .. kvalitní diskuze se na netu posledních 10 let moc nevidí.

Oběma stranám bych asi doporučil (bez pejorativního významu, jen mi to fakt přijde zajímavé) zamyslet se nad tím, že může jít o dvě stejně validní rozdílné filosofické školy přístupu k tvorbě software. Přijde mi zajímavé co z toho plyne a jestli by se to třeba nedalo skloubit dohromady.

[ehm]

Já bych na vašem místě řešil spíš válku mezi KLDR a USA.

[Bystroushaak]

A myslíš, že by taková válka byla dobře, nebo špatně? Resp. podporoval bys jí, nebo ne?

[ehm]

To má víc částí.

Vojenský konflikt mezi KLDR a USA může odstartovat dost hnusnou řetězovou reakci. Do jisté míry to záleží na pořadí. Pokud KLDR zaútočí jako první, Čína ji s trochou štěstí nebude při následné odvetné reakci bránit. V opačném případě, kdy by USA tlak nevydrželi jako první, by se do toho Čína pravděpodobně zapojila. To by přestala legrace. Už teď jsou na bodu mrazu diplomatické vztahy mezi USA a Ruskem – konflikt s další světovou mocností vytvoří větší než zdravé napětí. Pro USA by to byla nezáviděníhodná situace, protože by čelilo dvěma částečně zpřáteleným mocnostem současně. Je to o to horší, že ve hře jsou atomové zbraně.

Druhá strana mince je ta, že v KLDR panuje diktatura, přičemž jsem dalek toho se domnívat, že Kim Čong-Un je osvícený, liberálně smýšlející diktátor. Kdyby tomu tak bylo, stěží by mohli zavírat lidi do pracovních táborů, kde jsou fakticky týráni, a pronásledovat a popravovat ideologické protivníky.

Tedy případná změna politického režimu v KLDR by mohla být vítaným efektem. To ale pravděpodobně nedopustí Číňané, a i pokud ano, je otázka, jestli by po vojenském konfliktu nezůstali v zemi tak obrovské škody (nebo v případě opravdového tvrdého atomového útoku i radiace), že by vlastně nebylo koho a co před totalitou zachraňovat.

Ta situace jako taková se mi nelíbí a v tuto chvíli nejsem schopen předpovědět, jestli se bude jednat spíš o studenou válku než skutečné povolání mužů do zbraně. Spíš si myslím, že se ze strany KLDR jedná o vyjednávací taktiku, ale jestli to napětí nepřeroste, to nevím.

[Bystroushaak]

Vojenský konflikt mezi KLDR a USA může odstartovat dost hnusnou řetězovou reakci. Do jisté míry to záleží na pořadí. Pokud KLDR zaútočí jako první, Čína ji s trochou štěstí nebude při následné odvetné reakci bránit. V opačném případě, kdy by USA tlak nevydrželi jako první, by se do toho Čína pravděpodobně zapojila

Z toho co jsem tak měl možnost číst, tak Čína z Koreii momentálně vůbec nadšená není a že mají atomovky a vyvíjejí pro ně balistické nosiče se jim taky vůbec nelíbí.

Tedy případná změna politického režimu v KLDR by mohla být vítaným efektem. To ale pravděpodobně nedopustí Číňané, a i pokud ano, je otázka, jestli by po vojenském konfliktu nezůstali v zemi tak obrovské škody (nebo v případě opravdového tvrdého atomového útoku i radiace), že by vlastně nebylo koho a co před totalitou zachraňovat.

Atomovky jsou hrozně přeceňované. Ano, škody které působí výbuchem jsou hrozné, speciálně ve městech, ale reálná škoda na životním prostředí zas tak hrozná není (při testech jich bylo atmosfericky odpáleno přes 2000). Je dobře, že z toho lidi mají strach, ale taková ta úroveň typu „konec světa“ byla počítána na stav, kdy jich USA i SSSR měly dohromady vysoké desítky tisíc a některé z nich hodně špinavé.

Osobně si myslím, že největší problém a jeden z důvodů proč k válce hned tak nedojde je Soul, který je jen 30km od hranic se Severní Koreou a v dostřelu dělostřeleckých hlavic, takže ani nepořebují žádné fancy balistické nosiče a atomovky a můžou to město prostě rozstřílet na sračky konvenčními zbraněmi.

Ta situace jako taková se mi nelíbí a v tuto chvíli nejsem schopen předpovědět, jestli se bude jednat spíš o studenou válku než skutečné povolání mužů do zbraně. Spíš si myslím, že se ze strany KLDR jedná o vyjednávací taktiku, ale jestli to napětí nepřeroste, to nevím.

Imho pokud dojde k válce, tak bude blesková.

[ehm]

Z toho co jsem tak měl možnost číst, tak Čína z Koreii momentálně vůbec nadšená není a že mají atomovky a vyvíjejí pro ně balistické nosiče se jim taky vůbec nelíbí.

Jo. Ale kdyby USA zaútočili jako první, Čína by je asi i přesto bránila. Nejspíš by tedy záleželo na konkrétní podobě toho útoku; nějaký menší vojenský manévr by jim možná prošel. Ale to už opravdu spekuluji.

Je dobře, že z toho lidi mají strach, ale taková ta úroveň typu „konec světa“ byla počítána na stav, kdy jich USA i SSSR měly dohromady vysoké desítky tisíc a některé z nich hodně špinavé.

Obavy z toho, že by případný výbuch pár menších atomovek v USA nebo KLDR vedl ke konci světa, nemám. Ale obavy, že se situace ve světě dál zkomplikuje a vyostří a může to vést k větším průserům v budoucnosti, jsou podle mého oprávněné.

Osobně si myslím, že největší problém a jeden z důvodů proč k válce hned tak nedojde je Soul, který je jen 30km od hranic se Severní Koreou a v dostřelu dělostřeleckých hlavic, takže ani nepořebují žádné fancy balistické nosiče a atomovky a můžou to město prostě rozstřílet na sračky konvenčními zbraněmi.

Ano, ale to se týká útoku na Jižní Koreu. To je spojenec USA a tedy jeden z možných cílů útoku. Ale spekuluje se o možném jaderném útoku přímo na území USA, což by byla zcela odlišná varianta. KLDR by tím fakticky spáchala sebevraždu, ale stát se to může.

Imho pokud dojde k válce, tak bude blesková.

Válka pouze mezi USA a KLDR by blesková asi byla (Američani by jim to tam srovnali se zemí). Ale to je za předpokladu, že se do toho nepřimíchají další strany (především ta Čína).

[xkucf03]

Válka pouze mezi USA a KLDR by blesková asi byla (Američani by jim to tam srovnali se zemí).

Vždyť Američani už tam jednou byli – a dopadlo to tak, že půlka země je dodnes komunistická. Ono jedna věc je totiž zničit cizí zdroje (to jde Američanům dobře) a zcela jiná věc je obsadit dané území a zavést tam nějaké konstruktivní změny k lepšímu. Pokud by tam Američani chtěli vojensky vstoupit, tak rozhodně nebudou vnímáni jako nějací osvoboditelé – naopak by se jen potvrdilo, co Kimové svým lidem vtloukali do hlav, tzn. že Američané jsou zlí a chtějí je napadnout.

[ehm]

Bleskový by byl jaderný útok. Obsadit území a bojovat konvenčními zbraněmi by bylo mnohem náročnější a nevím, proč by to vlastně dělali.

[Bystroushaak]

Bleskový může být i konvenční útok například tomahawky.

[ehm]

Počkej. Indiáni se chystají zaútočit na ty bílé přistěhovalce, aby se jim konečně pomstili za křivdy na předcích? Škoda, že to nestihli ještě za Obamy, ten už byl stejně skoro plešatej, takže by ho třeba neskalpovali.

[Fluttershy, yay!]

Indiáni

Jak příhodné.

[Fluttershy, yay!]

Tedy případná změna politického režimu v KLDR by mohla být vítaným efektem.

Až na tu humanitární krizi. KLDR má 25 mil. obyvatel, co s nimi? Ani sjednocení Německa nebylo žádné lážo plážo, a to byly rozdíly mezi zeměmi podstatně menší.

[ehm]

To nevím. Hodně by záleželo na situaci, která by tam po válce panovala. Jednoduché by to určitě nebylo, ale to změna politického režimu není nikdy...

[Bystroushaak]

Tak ona je tam humanitární krize už teď.

[Fluttershy, yay!]

Jistě. Ale region je stabilní.

Jižní Korea má 50M obyvatel, KLDR 25M. Je to především Jih, kdo se nechce jen tak sjednotit a raději velmi pozvolna buduje průmysl v DMZ, protože takový jednorázový příliv nekvalifikované pracovní síly by pro ně byl ekonomická a v důsledku humanitární katastrofa.

[Agent]

KLDR má 25 mil. obyvatel, co s nimi?

To je otázka. Že by levná pracovní síla? IMHO ti lidé tam budou na práci asi použitelnější než kdejaký afričan z buše.

[ehm]

Máš recht. Pro lidi, co pracují 14 hodin denně sedm dnů v týdnu v uranových dolech, budou dvanáctky u montážní linky ve fabrice taková menší dovolená.

[Fluttershy, yay!]

afričan z buše

non sequitur

[Agent]

Chtěl jsem napsat z pralesa. Někdy se mi to plete. Pralesy snad v Africe ještě nějaký maj, nebo ne?

[Fluttershy, yay!]

Pokud KLDR zaútočí jako první

Myslíš, že Kima a jeho papaláše přestalo bavit žít si jako králové? Protože pokud eskalují konflikt, pak už si takhle nebudou… nebudou.

To bych se spíš bál toho senilního dědka v Bílém domě, protože ten absolutně nechápe souvislosti (4D šachy, ha-ha), ale potřebuje si honit ego, zvlášť když se mu nic nedaří.

[ehm]

Ne, nemyslím. Právě proto bych tipoval, že je to z jejich strany spíš vyjednávací taktika. Ale taky můžou situaci špatně odhadnout, nebo jim prostě může rupnout v bedně.

[xkucf03]

Tedy případná změna politického režimu v KLDR by mohla být vítaným efektem. To ale pravděpodobně nedopustí Číňané

Pokud ten pád režimu bude způsoben zvenku, tak co pak bude následovat? Zřejmě instalace nějaké loutkové proamerické vlády. A tady se nelze Číňanům divit, že tohle vedle sebe mít nechtějí.

[Bystroushaak]

Já bych na vašem místě řešil spíš válku mezi KLDR a USA.

Eskaluje to rychle (za posledních 24 hodin):

• Korejská krize: Japonci rozmístili rakety. Zbraně máme připravené, ohlásil Trump
• Trump a Si Ťin-pching mluvili o Severní Koreji. Oba chtějí jaderné odzbrojení země
• Trump telefonicky hovořil s čínským prezidentem. Chtějí jaderné odzbrojení KLDR
• Spojené státy už mají nabito a zacíleno na Severní Koreu, varuje Trump

[ehm]

Příloha:

• priority.jpg (52655 bytů)

Viz příloha.

[xkucf03]

Proč sem taháš další nesouvisející téma? Chceš ještě delší diskusi?

[Bystroushaak]

Proč sem taháš další nesouvisející téma? Chceš ještě delší diskusi?

Co je špatného na dlouhé diskuzi?

[xkucf03]

Stránka se dlouho načítá a pokud někoho zajímá politika, bude muset přeskakovat příspěvky o programování, a naopak.

Trochu tě podezřívám, že jsi sem to další téma zatáhl sám, abys trhnul rekord. Za chvíli překonáme Krokodýlí řeku a co pak? Bude Zmije za dveřmi?

[Bystroushaak]

Já jsem se chtěl dostat jen do top10 a to už se dostalo dávno. Obávám se ale, že se toho nápadu chytili ostatní. Osobně je mi docela jedno kde budu o čem diskutovat, pokud je to zajímavé téma k diskuzi. Zrovna u té Koreii ale někdo blog určitě vytvoří, ostatně stejně jako u každé politické situace z posledních pár let, ale já to nebudu, protože jsem se zařekl, že nebudu blogovat o politice.

[xkucf03]

BTW: co se to stalo? Jako by se tahle diskuse zničeho nic zastavila. Poslední příspěvek (před tímto): 14.8.2017 21:16.

Všiml jsem si toho víckrát, přijde mi, že aktivita v diskusi často skončí skokově, ne plynule, že by se zpomalovala. Nebo je to jen můj dojem? Možná zajímavé téma na nějaké statistické cvičení :-)

[ehm]

Přesně! A to jsem vážně doufal, že někdo odpoví na #1360.

No, ale pak je tu ještě jedno znepokojivé možné vysvětlení: někdo vypnul bota.

[kralyk z abclinuxu]

Já byl línej na to psát odpověď, protože to je hodně OS-specific, ale tak já teda něco napíšu

[kralyk z abclinuxu]

Došlo k vyčerpání benzínu, flamewar není čím živit

[Bystroushaak]

Já teď třeba nemám čas ani náladu dál diskuzovat a zas tak moc nás tady nebylo. Jinak běžně diskuze padají, když se objeví nová.

[ehm]

Experiment, no. Zajímá mě, jak dlouho jedna diskuze dokáže přitahovat traffic. Protože to není tak, že by v té diskuzi už bylo vše řečeno, a proto ji lidé opustili. Spíš je to asi tak, že na začátku je ta diskuze hodně na očích (je pod čerstvým blogem), takže i přitahuje nové návštěvníky. Mezitím se objeví nové blogy, takže sem už lidi chodí jen ze setrvačnosti – něco sem psali a čekají na odpověď, nebo si všimnou aktivity (v přehledu navštívených diskuzí). Když odstartuješ off-topic téma, které by se zrovna tak mohlo řešit v jiné diskuzi (na tom samém portále), budou tam chodit dál? IMO teď už je pozdě, protože už delší dobu sem přispívá jen pár stejných lidí. Ale udělat něco podobného úplně na začátku a vtáhnout do téhle diskuze politické diskutéry, tak je teď tahle diskuze možná nejkomentovanější. A nebo taky ne, protože na to není úplně ideální počasí. Dát to někdy na podzim, tak možná.

BTW: Jen čisté HTML s touhle diskuzí má 3,14 MB. Není divu, že se to dlouho načítá, když je to kruh!

[Bystroushaak]

BTW: Jen čisté HTML s touhle diskuzí má 3,14 MB. Není divu, že se to dlouho načítá, když je to kruh!

Ono hlavně to HTML je naprostá, špatně napsaná sračka, která zabírá víc než samotné texty.

[ehm]

Což platí o HTML obecně.

[Agent]

Já bych na vašem místě řešil spíš válku mezi KLDR a USA.

Mě by spíš zajímalo, jak ste řešili výše vztah mezi válkou a pokrokem. Možná by bylo zajímavé porovnat fungování firem za války a v době míru. Všichni asi máme povědomí o tom, jak to chodí v korporacích v době míru. Spousta zbytečných lidí vymýšlejících zbytečnou práci otravující ty, kteří něco skutečně hodnotného tvoří a táhnou firmu kupředu. Řada lidí na postech, kde nemají co pohledávat. IMHO za války, pokud opravdu teče do bot, neni čas na kraviny jako genderová rovnost, kvóty a jiné hovadiny. Kdo nemá výsledky, jde od válu, tečka. Ten kdo výsledky má, dostane maximální podporu.

Co se týče ZP, že by lidi tak nějak stagnovali a neměli motivaci něco dělat, IMHO tvůrčí člověk bude tvořit, protože ho to baví, je to smyslem jeho života. Tvůrčí lidé často pracují i v důchodu i když by už nemuseli hrábnout, protože mají příjem zajištěn od státu a přesto pracují. Ať už jsou to umělci, architekti, nebo i ti vědci. Prostě tvůrčí člověk se umlčet nedá. Nebo si vzpomeňte na sebe v dětství. Já měl nějaké zájmy, kterým jsem se věnoval a nedělal jsem to kvůli penězům, ale prostě mě to bavilo si s něčim hrát, přičemž pod pojmem hrát nemám na mysli tahat kačera, ale třeba si zbastlit něco z Merkuru, modelařina, později i ta elektronika mě trošku zasáhla, nebo mě bavilo pomáhat s různými pracemi když se třeba předělával barák.

A dnes? Většinu energie vyplácám na zaměstnání kam chodím jen proto, že potřebuju ty pitomý prachy. A pak když přijdu domu vycuclej jak moucha v pavučině, nemám náladu ani na to si doma natřít olupující se okapy, natož si s něčim hrát.

[Bystroushaak]

Řada lidí na postech, kde nemají co pohledávat. IMHO za války, pokud opravdu teče do bot, neni čas na kraviny jako genderová rovnost, kvóty a jiné hovadiny. Kdo nemá výsledky, jde od válu, tečka. Ten kdo výsledky má, dostane maximální podporu.

Druhá světová válka genderovou rovnost podpořila asi jako málo co jiného, protože ženy musely jít makat do továren. V tu chvíli přestala být možnost luxusu dovolit si mít genderovou nerovnost a ženy doma u plotny.

Co se týče ZP, že by lidi tak nějak stagnovali a neměli motivaci něco dělat

..

A dnes? Většinu energie vyplácám na zaměstnání kam chodím jen proto, že potřebuju ty pitomý prachy. A pak když přijdu domu vycuclej jak moucha v pavučině, nemám náladu ani na to si doma natřít olupující se okapy, natož si s něčim hrát.

Ono je dobré si uvědomit, že práce ani peníze nejsou smyslem života, i když je to tak často v naší společnosti prezentováno. Pokud by byl skutečně možný ZP tak, aby to ekonomicky dávalo smysl a dovolilo lidem nepracovat, imho by měli čas prostě .. žít, ať už si pod tím každý představí co chce. Pro někoho by to klidně mohla být práce, pro jiného umění, pro dalšího chlastání do bezvědomí.

Představ si sám sebe na smrtelné posteli, kdybys zítra zjistil, že máš rakovinu a do měsíce umřeš. Co bys ten měsíc dělal? Chodil do práce? Snažil se vydělat víc peněz? Teď si představ svůj poslední den, jak ležíš na té posteli a lituješ všeho, co jsi za život nestihl. Čeho myslíš, že bys litoval? Že jsi nebyl déle v práci? Že sis nevydělal dost na lepší auto? Nebo že jsi nestrávil víc času s rodinou, necestoval po světě a neužíval si života jak se jen dá, i kdybys neměl ani korunu a chodil jako žebrák?

Ve skutečnosti dokonce už máš něco jako rakovinu - umřeš na smrt do maximálně pár desítek let, odhadem tak 30-60. Jsi si jistý, že neplýtváš život kravinama? Fakt potřebuješ ty prachy, nebo máš jen pocit, že je potřebuješ? Nešlo by se třeba uskromnit, nebo žít úplně jinak?

[Agent]

Myslíš, že se za války děly i takovéto věci? - http://www.abclinuxu.cz/zpravicky/james-damore-propusten-z-google

Pokud se bude společnost ke schopným lidem chovat takto dementně macešsky, tak se nedivme, že ten vývoj jde kupředu pomaleji, než třeba za války. Jinak ano, za 2SV nahnali ženy do fabrik, dělaly práci kterou zvládly. Rozhodně nenahnaly půlku bab na vedoucí a manažerské posty a druhou půlku do výzkumu a vývoje a to jen proto, aby to bylo fifty fifty.

Co se týče peněz, bez nich to nejde, je to nutné zlo.

...kdybys zítra zjistil, že máš rakovinu a do měsíce umřeš. Co bys ten měsíc dělal?

Tak když to vezmem takto do extrému, tak bych si vzal třeba 10 mega pujčku a letěl si užívat na nějaký opuštěný ostrov. Problém by ale nastal, kdyby se lékaři mýlili a já přežil dalších pár let a najednou bych musel tu pujčku splácet.... To bych si to asi hodil....

[Fluttershy, yay!]

Víš, že dluhy jsou součástí dědictví? Tedy za předpokladu, že máš vůbec někoho, kdo by po tobě dědil.

[ehm]

Dědici se můžou (celého) dědictví vzdát. Jak by to bylo v případě, že by všechen majetek převedl darem ještě během života, aby v dědictví zůstaly jen ty dluhy, nevím.

[Fluttershy, yay!]

Ano, celého. Ale pokud se ho nevzdají, týkají se jich i ty dluhy, o kterých třeba nevěděli.

[ehm]

To zní trochu nefér. Neměli by napřed dostat informaci o tom, co je předmětem dědictví (vč. těch dluhů)?

[Fluttershy, yay!]

To reálně moc nejde, není žádný centrální registr pohledávek a podívej se na promlčecí lhůty.

Typicky je to problém u společného jmění manželů, když se manželé třeba nestýkají furt, jeden v nepřítomnosti naseká dluhy a nikomu o tom neřekne.

[Fluttershy, yay!]

Respektive, registr dlužníků existuje a je dobré ho kontrolovat, ale to neznamená, že tam bude všechno.

[xkucf03]

Měli. Ale podobných zvráceností je v současném zákoníku plno.

Podle mého by dluhy měly fungovat úplně jinak než dnes – když už by měl nějaký dluh vzniknout, tak by mělo být předem jasné (a zdokumentované), čím se za něj bude ručit. Pokud by nic k ručení nebylo, tak by do toho věřitel musel jít s tím, že je to víceméně jen na dobré slovo a svoje peníze možná nikdy neuvidí, dluh bude nevymahatelný. A pokud ti např. půjčí na základě toho, že máš dostatečně vysoké příjmy, tak pak můžeš mít exekuci na příjem, ale na nic jiného. Pokud to věřiteli nestačí, tak si měl vzít něco do zástavy.

[ehm]

Takže jako člověk s vysokým příjmem, který už má něco našetřeno, si před plánovaným odchodem do důchodu (který může být mnohem dříve než věřitel očekává) napůjčuješ, co to půjde, a protože si budeš v klidu žít z úspor a z těch půjčených peněz, tak tě následná exekuce na příjem moc nerozhodí, když žádný příjem nemáš? Cool.

[xkucf03]

Tak když někdo půjčí starému člověku (u kterého je celkem pravděpodobné, že buď umře nebo přestane pracovat a bude v důchodu), aniž by se s ním dohodl na nějaké zástavě nebo ručením konkrétním majetkem, tak je to jeho blbost.

[ehm]

Takže jako člověk s vysokým příjmem, který už má něco našetřeno, si před plánovaným odchodem do důchodu (který může být mnohem dříve než věřitel očekává) napůjčuješ, co to půjde, a protože si budeš v klidu žít z úspor a z těch půjčených peněz, tak tě následná exekuce na příjem moc nerozhodí, když žádný příjem nemáš? Cool.

Hint: Nemám na mysli státní důchod.

[pavlix]

Exekuce na příjem tě nerozhodí. Rozhodí tě exekuce na majetek.

Náš administrátor shledal tento komentář závadným.

trolling

Zobrazit komentář

[ehm]

To jako vážně? Napsat někomu, že je negramotný, když očividně vůbec netuší, o čem je řeč (a mohl by si to přečíst jen o pár příspěvků výš), je „trolling“?

Trolling je půlka příspěvků v téhle diskuzi. Tohle by byla navýše vulgarismů prostá urážka, ale naprosto relevantní.

[Fluttershy, yay!]

Komentář je nerozlišitelný od „Pavlixovy zlé ženy“ apod.

[pavlix]

Především mi příjde dost trapné, když někdo, kdo se po celou diskuzi projevuje jako primitiv a naštěstí pro něj alespoň ne pod vlastním jménem, vůbec komentuje ostatní po osobní stránce.

[ehm]

A to můžeš nějak vysvětlit, nebo ti ten komentář mám reportnout a nechat přesunout do samostatného vlákna s odůvodněním „trolling“?

[Randy_Sh]

Podle mého by dluhy měly fungovat úplně jinak než dnes – když už by měl nějaký dluh vzniknout, tak by mělo být předem jasné (a zdokumentované), čím se za něj bude ručit. Pokud by nic k ručení nebylo, tak by do toho věřitel musel jít s tím, že je to víceméně jen na dobré slovo a svoje peníze možná nikdy neuvidí, dluh bude nevymahatelný. A pokud ti např. půjčí na základě toho, že máš dostatečně vysoké příjmy, tak pak můžeš mít exekuci na příjem, ale na nic jiného. Pokud to věřiteli nestačí, tak si měl vzít něco do zástavy.

Je dobré si uvědomit, že dluhy nevznikají pouze z půjčování peněz, ale i dalšími způsoby. Např. člověk neuhradí daň či zdravotní a sociální pojištění. Nebo nezaplatí za poskytnutou službu. Případně někomu způsobí škodu, ale neuhradí ji. Co v takových případech?

[JS1]

Podle mého by dluhy měly fungovat úplně jinak než dnes – když už by měl nějaký dluh vzniknout, tak by mělo být předem jasné (a zdokumentované), čím se za něj bude ručit.

Problem je, ze velke mnozstvi veritelu o tohle moc nestoji - oni chteji fakticky dluhove otroctvi (nebo to co se mu legalne nejvic priblizuje). Clovek, ktery je otrokem svych dluhu, neutraci penize za blbosti (jako treba spotrebu nebo investice), ale za uroky.

[Randy_Sh]

Ano, celého. Ale pokud se ho nevzdají, týkají se jich i ty dluhy, o kterých třeba nevěděli.

To neplatí, když dědic uplatní tzv. výhradu soupisu pozůstalosti. Potom zaplatí dluhy max. do výše hodnoty dědictví.

[ehm]

Cool. Tak aspoň něco.

[Fluttershy, yay!]

Ona to není kdovíjaká výhra a v podstatě se to vyplatí jenom tehdy, pokud se větší zadlužení očekává, detailněji je to třeba tady, pokud nechceš číst přímo zákon.

[xkucf03]

Co se týče peněz, bez nich to nejde, je to nutné zlo.

Peníze nejsou zlo. Je to jen prostředek pro materiální interakci s jinými lidmi. Pokud od ostatních něco chceš (např. aby tě někam dovezli, aby ses tam mohl kochat přírodou), tak musíš udělat zase něco ty pro ostatní. Což je dané tím, že energie, materiál a lidská práce jsou omezené zdroje a nikdo ti je nedá jen tak za nic (to leda v omezené míře, ale je to spíš výjimka, nemůžou to tak dělat všichni a vždy). A peníze jsou jen nástroj, který umožní, aby ti lidé, od kterých něco chceš, nemuseli být ti samí lidé, pro které něco uděláš.

[ehm]

Jinak řečeno – peníze jsou platidlo. Nad čím je zajímavé se zamyslet je otázka, jak existence jednoho univerzálního platidla ovlivňuje lidskou psychiku. Do jisté míry si myslím, že společnost, ve které je zvykem používat pouze barterovou směnu, by nikdy nebyla tolik konzumní.

Částečně lze říct, že fungujeme nepřirozeně v tom smyslu, že napřed vyděláváme peníze a až pak je uplatňujeme. Snadněji se pak stane, že si koupíš něco, co by sis jinak nekoupil (a ani tě nenapadlo, že to chceš/potřebuješ), jen proto, že jsi na to měl peníze.

Ty peníze jsou totiž do jisté míry anonymizované. Do práce chodíš tak jako tak – a z nějakého důvodu je „normální“ pracovat 8 hodin denně. A pak ty vydělané peníze utrácíš.

Vem si, že by to bylo obráceně. Měl bys danou hodinovou sazbu. Na začátku měsíce by sis sestavil seznam výdajů a pak pracoval přesně tolik hodin, aby to pokrylo ty výdaje. Koupíš si nějakou kravinu „za pár korun“, nebo raději budeš mít o půl hodiny víc volného času?

Kdybys to dělal takhle, žil bys od ruky k hubě. Vydělávat víc než kolik potřebuješ spotřebovat dává smysl, když si chceš vytvořit zásoby. Ale IMO je to těžší právě tím, že jak ty peníze už máš, ztratíš kontakt s tím, jakou mají hodnotu, a snáz je utratíš.

Jen nabízím alternativní pohled.

[xkucf03]

Do jisté míry si myslím, že společnost, ve které je zvykem používat pouze barterovou směnu, by nikdy nebyla tolik konzumní.

Spíš by to bylo o dost méně pohodlné a IMHO zbytečně – akorát bys musel řešit, co za co vyměníš a s kým. Peníze (resp. nějaké platidlo jako třeba zlato nebo kryptoměna) jsou univerzálnější.

Do práce chodíš tak jako tak – a z nějakého důvodu je „normální“ pracovat 8 hodin denně. A pak ty vydělané peníze utrácíš. Vem si, že by to bylo obráceně. Měl bys danou hodinovou sazbu. Na začátku měsíce by sis sestavil seznam výdajů a pak pracoval přesně tolik hodin, aby to pokrylo ty výdaje.

Ono to tak v zásadě funguje i s penězi, akorát to není na měsíční bázi, ale spíš si po několika letech můžeš říct, že už máš dost a přehodnotit svůj pracovní život – buď nepracovat vůbec nebo začít dělat na částečný úvazek nebo třeba změnit obor. Že to někdo nedokáže je buď dané jeho možnostmi (do práce prostě musí chodit pořád, aby se uživil) nebo má zafixované, že do práce se chodí každý den na osm hodin bez ohledu na to, kolik potřebuje – ale to je spíš problém v jeho hlavě než problém peněz.

To, co navrhuješ – rozhodovat se každý měsíc a měnit pracovní rytmus – je dost nepraktické kvůli spolupráci s ostatními lidmi – těžko se dá plánovat práce více lidí a projekty, když nevíš, kolik lidí ti přijde do práce a jestli tam ten měsíc budou 25 dní (protože se jim zrovna něco rozbilo a mají vysoké výdaje) nebo tam budou jen 5 dní (protože jim zrovna nic nechybí). Je dost málo profesí, kde bys to takhle mohl měnit z měsíce na měsíc.

Je to tedy výhoda peněz (jsou i uchovatel hodnoty), že ti stačí vydělávat nějakou průměrnou částku a mít nějaké rezervy a vyjdeš s tím (i když máš každý měsíc jiné výdaje).

Ale IMO je to těžší právě tím, že jak ty peníze už máš, ztratíš kontakt s tím, jakou mají hodnotu, a snáz je utratíš.

To je asi dost subjektivní, ale já si třeba celkem často říkám: „Kolik dní jsem na tuhle věc musel pracovat?“

[ehm]

Spíš by to bylo o dost méně pohodlné a IMHO zbytečně – akorát bys musel řešit, co za co vyměníš a s kým. Peníze (resp. nějaké platidlo jako třeba zlato nebo kryptoměna) jsou univerzálnější.

Jistě. To je jeden z důvodů, proč by ta společnost byla méně konzumní.

Že to někdo nedokáže je buď dané jeho možnostmi (do práce prostě musí chodit pořád, aby se uživil) nebo má zafixované, že do práce se chodí každý den na osm hodin bez ohledu na to, kolik potřebuje – ale to je spíš problém v jeho hlavě než problém peněz.

Z hlediska organizace a řízení je jednodušší mít zaměstnanců míň. Tedy zaměstnavatel ti mnohdy neumožní pracovat na „zkrácený“ úvazek – není to jen otázka toho, jestli by ses z poměrné části příjmu uživil.

To, co navrhuješ – rozhodovat se každý měsíc a měnit pracovní rytmus – je dost nepraktické

Já to nenavrhuju. To byla úvaha.

To je asi dost subjektivní, ale já si třeba celkem často říkám: „Kolik dní jsem na tuhle věc musel pracovat?“

Já taky, ale přesto občas utrácím víc než bych utratil, kdybych operoval podle uvedeného modelu.

Není úplně jednoduché se úplně odpoutat od toho, kolik peněz máš k dispozici (pokud máš něco našetřeno). Osobně si myslím, že to ani nedává smysl. A buch – tady máš ten konzum.

[JS1]

IMHO za války, pokud opravdu teče do bot, neni čas na kraviny jako genderová rovnost, kvóty a jiné hovadiny.

Ha ha ha. Mozna by sis o te valce mohl precist nejakou literaturu.. (zazit ti to nemuzu s klidnym svedomim doporucit) Jak treba kvete smelina.

Ciste bokem, ale pocitacove hry jsou v tomhle dost nerealisticke. Mne by se libila pocitacova hra, neco jako Civilizace, ale kde ti tvoji podrizeni ministri a generalove (a jejich podrizeni atd. az dolu) vesele ignoruji tvoje rozkazy a misto toho intrikuji a kradou.

[Fluttershy, yay!]

Mne by se libila pocitacova hra, neco jako Civilizace, ale kde ti tvoji podrizeni ministri a generalove (a jejich podrizeni atd. az dolu) vesele ignoruji tvoje rozkazy a misto toho intrikuji a kradou.

4X ani budovatelské strategie sice nehraju, ale co jsem slyšel, některé verze/klony Tropica jsou přesně o tom, a jsem si celkem jistý, že třeba Europa Universalis s tím taky počítá (ale tam je to jenom jedna z mnoha metrik).

[pavlix]

How I Won the War (Patrick Ryan)

Vřele doporučuju.

[ehm]

Pojďme si dát takovou soutěž. Když skočíte úplně na začátek stránky s touhle diskuzí a úplně nejvíc maximálně roztočíte kolečko od myši, kolik % stránky odscrollujete? Já to projedu úplně celé a kolečko se točí ještě dál, ale to je proto, že Logitech G502 má speciální čudlík, kterým jde vypnout takové to cvakátko, takže se to kolečko úplně brutálně roztočí a jak je tam minimum tření, tak se to točí úplně hrozně moc dlouho. Je to o to lepší, že když má člověk neúrozu, tak si nemusí kupovat fidget spinner, ale má to přímo v ceně myši.

[Agent]

Pojďme si poměřovat pindíky, nebo dáme bukkake kdo má silnější střik...

[ehm]

Děkuji, ale opravdu nemíním kandidovat do politiky.

[Bystroushaak]

Mám lepší návrh. Napiš do diskuze pod Co je vlastně SAP Hybris? krátkou povídku na téma "Co je vlastně SAP Hybris?", která musí obsahovat výraz "SAP Hybris". Já už jsem začal.

[ehm]

Hele, já nedávno napsal recenzi na recenzi a taky spoustu komentářů o tom, který programovací jazyk je nejlepší a proč je to zrovna Java. SUCK Hybris mě nechává chladným.

Ještě jsem ani neodpověděl oryctolagusovi na to debugování kernelu, protože jsem měl spoustu práce s refactorováním nějaké legacy codebase a snižováním seběvedomí polským, ruským a tureckým dětem v CS:GO.