Space : Najděte 10 rozdílů

31.5.2020 00:46 | Přečteno: 3601× | plky | poslední úprava: 31.5.2020 12:10

Máme zde další historický milník. Kdo najde 10 rozdílů? :)

I když pro někoho sobota 30.5.2020 nebyla nijak výjimečná, tak pro spoustu lidí byla a je to další milník ve světové historii, byť třeba né tak velký jako např. přistání na měsíci.

Ovládání:

Sezení:

Raketoplán Endeavour

Byla by škoda nehodit sem obrázek i Raketoplánu Endeavour, poslední, který se proletěl (2011).

Zajímavé linky

Start americké rakety - Falcon 9 a pilotovaný Crew Dragon DM2 (odklad)
Start americké rakety - Falcon 9 a pilotovaný Crew Dragon DM-2
Horizons mission - Soyuz: launch to orbit
SpaceX Simulator
heavens-above.com
stellarium-web.org
kosmonautix.cz
Why does the SpaceX droneship camera cut out?

Závěr

Na obrázcích je Sojuz MS-09 (rodina) a Dragon 2 (Crew Dragon).
Spousta lidí toto bere jako USA vs Rusko. Nebo to spousta lidí vnímá tak, že Musk je Bůh a další část lidí, která mu přeje neúspěch. Já to tak nevnímám, zajímají mně jen technologie a jejich pokrok.

Zdar Max

PS: Tak co, kdo sledoval start a průběh letu? A co na to říkáte?

       

Anketa

Komentáře

[Gréta]

si myslim že rozdílů je víc než 10 :D :D ;D

[Ruža Becelin]

Nevidim rozdil - manici mackajici se v nesmyslu pohanenem extra vybusnym svinstvem.

Smutny, ze jsme se za padesat let nikam poradne neposunuli.

Ale hlavne, ze mame svetelny vlacky. Pokud si budu chtit prohlidnout hvezdy, muzu si postavit vlastni raketu a podivat se z vesmiru, pac kvuli zavirovane obloze od SpaceSex uvidim velky H.

[Max]

Posunuli jsme se od joysticku k do značné míry automatické raketě. Optimalizace na motorech také proběhla. Vylepšený systém recyklace částí rakety a věcí okolo. A optimalizace nákladů je hodně slušná. Celkově to má slušný přínos a urychlí to posun kupředu.
Je samozřejmě jasné, že to nemůže mít rychlý vývoj jako třeba věci v IT, kde každý rok se něco objeví.
Zatím asi nebudou mít v dopravě velkou konkurenci, ale nepřijde mi, že by toto byl primární Muskův cíl. Jinými slovy, asi nehrozí, že ten vývoj usne podobně jako u Sojuzů.
Vypadá to, že Čína je s vývojem také pozadu, takže SpaceX se asi dnešním dnem dostalo do čela. Uvidíme, co bude.
Zdar Max

[Radovan]

Optimalizace? Akorát že nemá tolik mrtvých jako Nedělin: https://www.novinky.cz/zahranicni/amerika/clanek/prototyp-nove-rakety-spacex-vybuchl-na-testovaci-rampe-40325948 :-/

Sojuz je sice popelnice stará přes půl století, ale funguje spolehlivě. I když létání do Vesmíru bych si také představoval jinak, ale to může být tím že jsem kdysi přečetl hodně sci-fi.

A s tím "vývojem" v IT to nepřeháněj, kolik z těch nových věcí co se každý rok objeví přežije aspoň jednu lidskou generaci? Většina toho co se dnes používá pochází ze sedmdesátých a osmdesátých let, akorát to žere milionkrát víc výkonu a paměti!

[kvr]

Sojuz je sice popelnice stará přes půl století, ale funguje spolehlivě. I když létání do Vesmíru bych si také představoval jinak, ale to může být tím že jsem kdysi přečetl hodně sci-fi.

To bude asi tím. Zákon zachování energie a rovnice kolem máme pořád stejné a na přímém spálení ropného produktu s kyslíkem moc co optimalizovat není (na rozdíl třeba od auta, kde je pořád nějaká mechnika, dobré promíchání paliva apod, proti tomu je raketa jednoduchá brute force). Takže hlavní posun je v tom, že dokážeme lépe automatizovat a případně to monstrum navigovat, aby si v přesném pravém úhlu sedlo zpátky na zem. Teoreticky bychom měli mít díky výrobním procesům taky vyšší spolehlivost, což tedy možná občas nevypadá, ale to je spíš dáno tím, že se o to víc tlačí na pilu...

Dopravit dané množství paliva na Mars bude asi největší oříšek pro to, abychom tam dokázali dopravit člověka. Tedy s tím, že by se ještě vrátil, což jako požadavek třeba ještě zrelaxujou... Ideální by bylo tam dotáhnout minimum a postavit životaschopnou základu, ale to je na několik generací nebo mnohem vyzrálejší robotiku. Jak navíc zjistili Čínani minulý rok, rostliny ve vesmíru velmi rychle chcípnou a táhnout s sebou pár pytlů brambor na celý rok či víc nebude úplně efektivní... Pomíjím zcela předpoklady jako diskutabilní podmínky k životu apod.

PS: Teď jsme s dětma začali číst staré ABC komixy (Galaxie, Vzpoura mozků) a jo, je docela úsměvné se vrátit k tomu, jaké pohledy tehdejší sci-fi literatura měla (třeba - tak si tu soustavu obletíme ještě jednou a při tom téměř online rozhovor ).

[billgates]

Raketove palivo sa bude dat bez problemov vyrobit priamo na Marse, postaci na to energia, lokalne zdroje uhlika a nejaky cas. Podla mna uplne najhorsie na dopravenie bude zradlo pre marsonautov. Ak sa tam nahodou objavia naozaj pouzitelne a dostupne zdroje vody, tak by to vsetko vyrazne ulahcilo, kedze voda je pomerne tazka, neda sa stlacit, takze stale zabera velky objem, meni skupenstvo a pri tom dokaze znicit nadrze. Da sa recyklovat, ale stale jej treba dopravit obrovske mnozstvo.

[Odin1918]

Jaky ma smysl clovek na mesici ci marsu? Kdyz uz se tam coat, neni lepsi poslat jen robotickou sondu? Co zvladne clovek a robot ne?

[billgates]

Ked uz sa bavime o zmysle a vynechame fatalisticky pohlad, kedy vlastne nic nema zmysel, tak trvale osidlenie na viac ako 1 planete ma pre ludstvo vyznam prezitia.

To, ze tam pride zopar ludi, pohraju sa v piesocku a poletia domov samozrejme nema samo o sebe vyznam. Ale je to dalsi krok ku trvalemu osidleniu. Zem skor ci neskor caka katastrofa (asteroid, supervulkan, covid-88) a preto je treba redundanciu.

Taktiez niektori ludia maju radost z elegantnych inzinierskych rieseni roznych problemov, ktore s takou cestou suvisia.

[PepaSFI]

co zvládne člověk a robot ne? No tak nějak všechno.

[Max]

Člověk zvládne základní věci 1000x rychleji a trochu složitější věci zvládne jen člověk (třeba když se něco rozbije, člověk to opraví, ale sonda se sama neopraví). Se podívej, jak dlouho trvá jen komunikace ze Země s nějakými sondami. Navíc dlouhodobý pobyt lidí ve vesmíru v ochranném pásmu Země (na ISS) už známe a Měsíc je další level.
Zdar Max

[Branislaw]

ale sak na Mesiaci sme uz vraj boli pred 50 rokmi...

[Max]

Jak to souvisí s dlouhodobým pobytem a labem?
Zdar Max

[Radovan]

Dokáže dnešní technika dovézt lidi na Měsíc a zpátky, udržet je při životě a zásobovat během několikaměsíčního pobytu? Vypadá to že ještě hůř než před půl stoletím, jestli vůbec. Asimov o něčem podobném psal v Nadaci.

[billgates]

Odpoved na tvoju otazku zalezi aj od toho, ake velke riziko si ochotny podstupit. Kedysi sa s tym ludia nesrali a hlavne rusi zabijali kozmonautov ako na beziacom pase. Aj amici vedeli fajne ludi usmazit, ked bolo treba. Dnes uz ludia nemaju zaludok na smrt, takze to cele ide trochu debilnou cestou, ale stale to aspon trochu postupuje dopredu.

[Radovan]

SSSR: 4

USA: 14

Pukud započítáš i pozemní "události, tak tam ten Nikulin bezpečně vede, ale bez něj mají Američani i na zemi všechno největší

[kol-ouch]

Ono se vůbec těžko srovnává roskosmos a nasa - od doby co skončil závod o měsíc a smetli ze stolu N1, tak roskosmos v podstatě jen taxikaří na orbitu - nic jako raketoplán nemají a neměli (ok, BYL tady jednou bez posádky letící bezmotorový buran...)

Odečti z těch čísel ztráty z Columbie a Challengeru (protože cccp/Rusko nemělo, nemá a bůh ví jestli někdy bude mít nic podobnýho) a ta čísla ti vyjdou trochu jinak...

[Fluttershy, yay!]

[reakce na vlákno]

Tak například u toho delšího pobytu byť jen na oběžné dráze víme, jaké to má dopady na lidský organismus. Už jenom adaptace těla na odlišnou gravitaci. V tomhle kontextu se vážně bavit o nějakém cestování na Mars, natož zpět – šílenství.

[vencour]

Dobývání Nového světa za Kolumba se jevilo tehdy také jako šílené.

[Fluttershy, yay!]

Genocida skutečně šílená je.

[JS1]

Mozna slo o zoufaly pokus Evropanu zbavit se nabozenskych fanatiku.

[JiK]

Genocida skutečně šílená je.

Ty predkolumbovske civilizace sice hromadne vyvrazdovaly sve zajatce a sousedy, ale delali to kvuli sve vire, to vy slunickari snad podporujete, tak bud trochu tolerantni, ne?

[kralyk z abclinuxu]

Nóóó... Tak na to, aby si člověk všiml toho prudkýho poklesu množství původní populace v Americe IMO není potřeba bejt sluníčkář. Vzhledem k tomu, že hlavní příčinou byly Evropany dovezený nemoci, je možné sáhodlouze filosoficky debatovat, jak moc se za to dá Evropanům dát odpovědnost. Nicméně vzhledem k tomu, že se rudokožcům zjevně po příjezdu Evropanů úplně dobře nedařilo a že s nimi Evropani neměli zrovna dvakrát slitování, tak to davkolovo zhodnocení v zásadě moc nadhodnocený asi nebude...

[Fluttershy, yay!]

Nemoci bych do toho nepletl. Evropané se jali dělat cílené etnické čistky, otrokářství,…

JiKovo tvrzení, že „oni to dělali taky“, není omluva, nýbrž výmluva, a to na mentální úrovni mateřské školky.

[Marian]

Nicméně vzhledem k tomu, že se rudokožcům zjevně po příjezdu Evropanů úplně dobře nedařilo a že s nimi Evropani neměli zrovna dvakrát slitování

Rozumný člověk se dokáže z historie poučit. Možná byli mezi indiány sluníčkáři, kteří podporovali přijímání migrantů (v tomto případě bělochů) a hlásali toleranci - bohužel přicházející migranti k nim tolerantní nebyli, možná byli indiáni příliš slabí, aby té invazi dokázali čelit. Tak jako tak dopadli špatně.

Snažme se, abychom my jednou nedopadli jako ti indiáni. Protože přicházející invazivní druhy k nám nebudou tolerantní, nebudou s námi mít slitování.

My máme sice proti indiánům výhodu, že jsme výrazně vyspělejší civilizace, ale to neznamená, že bychom byli mimo nebezpečí. Zvlášť pokud tu máme aktivní pátou kolonu.

Nemá smysl dávat rovná práva někomu, kdo rovnost neuznává a kdo se nad nás chce povyšovat. Tohle je zhoubný sebevražedný přístup. Je jedno, jestli je to černoch, muslim, Rus nebo Číňan. Oni nepřicházejí proto, aby se stali Čechy, Němci nebo Američany atd. Oni přicházejí proto, aby obsadili nové území, podrobili si původní obyvatelstvo a žili stále tak, jak jsou zvyklí (jen materiálně lépe), a naopak svůj pohled na svět vnutili ostatním. Kdyby chtěli žít jako my, tak budou číst české knihy, vařit česká jídla a zavedou si ve své zemi politický a ekonomický systém podobný tomu českému. To ale nedělají, protože to není jejich cílem. Naši toleranci a vstřícnost nevnímají jako naši ctnost, ale jako naši slabost a příležitost, jak nás porazit, obsadit naše území a přisvojit si naše bohatství.

[Fluttershy, yay!]

Nemá smysl dávat rovná práva někomu, kdo rovnost neuznává a kdo se nad nás chce povyšovat.

To vidím, že nějakou rovnost neuznáváš, když píšeš „přicházející invazivní druhy“.

Takže, proč by měl – podle vlastní úvahy – mít rovná práva tady „Marian“?

[Radovan]

Přijde americký prezident za nejstarším a nejmoudřejším indiánským náčelníkem do rezervace na poradu: "Řekni mi, moudrý náčelníku, jakým otázkám bych měl věnovat největší pozornost?"

"Na tvém místě imigrační politice, my jsme to svého času značně podcenili!"

https://www.novinky.cz/domaci/clanek/brusel-znovu-chysta-povinne-kvoty-bezencu-cesko-proti-40326946

[Dalibor Smolík]

Byli astronauti, kteří si nechali posílat video ze Země, jak dopadá tužka na stůl, aby si připomněli gravitaci.

[_]

to "vraj" je napresdrzku, pokud je to provokace, nebo na umisteni do ustavu pro debily :)

tak si tu prez drzku daj a umiestni sa do ustavu pre ludi bez kritickeho myslenia... na Mesiaci sme sa vraj pred 50 rokmi prehanali na autach teraz ledva doletime na ISS a este je z toho obrovsky hype... Sojuzy lietaju na ISS rutinovane...

[Radovan]

Možná to bude tím, že ten Sojuz byl padesát let rutinovaně řízený stále stejným analogovým počítačem a vačkovým sekvencérem. Když to funguje, nesahej na to

[Max]

No tak Sojuz doznal také značného vývoje, zas tak moc bych mu nekřivdil .
Zdar Max

[Radovan]

Ale jo, i ten číslicový počítač už nejméně dva roky má. A Buchanku také dost vylepšili

[Max]

"...ledva doletime na ISS..."

Otestovat si modernější technologie na kratších trasách nepovažuji za ubohost nebo neschopnost doletět dál. Měsíc nebyl donedávna moc v hledáčku, protože se vše zaměřovalo na výstavbu vesmírných stanic jako ISS.
Měsíc je v plánu až nyní. A né, není ten plán tak krátkozraký, jak by si kdo myslel, ale bude více druhů lodí, které budou přepravovat astronauty a jiné věci v určitých trasách. Jinými slovy, bude jiná loď na cestu na orbitu a jiná, co bude dopravovat astronauty a náklad z orbity na Měsíc. Tato vesmírná loď pak nepotřebuje tepelné štíty, bude dotankovávána na orbitě atd.

Oproti stavu před 50 lety jde tedy o nasazení moderních technologií, automatizace, eliminace lidské chyby, co největší snížení nákladů atd.
Dřív to bylo o tom, dostat se tam za každou cenu nehledě na peníze.
Zdar Max

[Radovan]

Ono to s těmi penězi zase nebylo tak hrozné, celý projekt Apollo prý stál méně než v USA utratili za rok na kosmetiku. A ty vynálezy a technologie se potom mnohokrát zaplatily.

[_]

To může říct jenom chlap. Asi by Američané řvali, kdyby každé roidině vzali půl platu na kosmický výzkum.

[Radovan]

Spíš Američanky

Ale kdyby se to rozložilo do celé jedné dekády, tak by to nebylo zase tak strašné.

On ten vesmírný výzkum vlastně ani není nějak moc drahý, pár let zpátky byl celý roční rozpočet NASA stejně velký, jako náklady na každý jeden den války v Iráku. Ale to je holt otázka priorit.

[rastos]

Raketove palivo sa bude dat bez problemov vyrobit priamo na Marse, postaci na to energia, lokalne zdroje uhlika ...

Tie zdroje uhlíka budú vo forme čierneho uhlia alebo ropy?

[Josef Kufner]

Jako CO₂ do metanu.

[billgates]

WAT? Co tak atmosfera?

[Max]

To se celkem pleteš. Vývoj a optimalizací raketových motorů je celá řada a stále jde vývoj dopředu.
Trochu by ti mohlo něco nastínit toto video : Je Raptor kráľom raketových motorov?
Zdar Max

[Radovan]

Každý kohout chválí svůj ocas.

S hodnocením bych počkal aspoň deset let. Až přejde hype.

[Max]

Nepochopils. Chtěl jsem tím odkazem jen říci, že vývoj a posun v raketových motorech je a je stále co zlepšovat, nic víc. Tzn. reagoval jsem jen na "...na přímém spálení ropného produktu s kyslíkem moc co optimalizovat není...".
Zdar Max

[Radovan]

Já reagoval přímo na ten odkaz. Třeba u automobilových motorů se to spalování optimalizuje už sto let, a pořád to ještě není to pravé.

[Nie som robot]

chcelo by to na kvapku benzinu prejst 100 km...

[Radovan]

Buď budeš mít nízké emise nebo nízkou spotřebu. Oboje najednou nejde.

[Max]

Chyba lávky je už jen to, že toto tvrdíš. Možná to nejde nyní, ale za 15 let to platit nemusí. Vývoj predikovat moc nejde .
Zdar Max

[Radovan]

Jako že by vznikla nějaká nová chemie nebo se změnilo složení zemské atmosféry? :-P

Euro6 doháníš spalováním močoviny, zkus si dát frťana. Blížící se Euro7 mě dost děsí.

[Max]

Ty se asi považuješ za vševědoucího, co zná všechny možnosti v tomto odvětví. Já takovou slepou vírou nedisponuji.
V HydePark civilizace se nositel Nobelovky (myslím, že to byl Gérard Mourou, ale možná se pletu) vyjádřil v tom smyslu, že vědci nepřicházejí na převratné objevy tak, že by empiricky a matematicky došly k výsledku, ale zjednodušeně řečeno stylem pokus omyl. Prostě si řeknou, že to zkusí takto, jak se to asi bude chovat a 1000x nic a na 1001 najednou něco objeví.
Zdar Max

[Radovan]

Vševědoucí? Ale to zdaleka ne, vím toho dost na to, abych si dokázal uvědomit jak málo toho vím. takže také vím jak to s těmi vynálezy je, třeba že žárovka vznikla 70 roků před Edisonovým patentem.

Jenom doufám, že co se pohonů aut týče, tak těch nic za sebou máme už aspoň 500 :-/

[-]

Za 15 let nebudou ropná auta existovat.

[Blaazen]

To tu budou jen elektromobily nabíjené z uhelných elektráren a zámořské lodě na mazut.

[_]

Uhelky tu budou jen pokud technozpatecnici jako ty budou blokovat jadernou energetiku.

[Blaazen]

Což o to, já jádro podporuju. Jen aby to ještě někdo uměl za rozumnou cenu postavit. Odkaz.

[Blaazen]

Sorry, on má ten podcast hoďku a třičtvrtě. Prostě je o tom, že firmy jako Westinghouse nebo francouzská Areva jsou v úpadku a všechny stavby v Evropě se prodražují a o léta protahují. A obecně se staví málo.

[Bystroushaak]

Což o to, já jádro podporuju. Jen aby to ještě někdo uměl za rozumnou cenu postavit. Odkaz.

Když už jsme u těch offtopiců, tak nevím jestli jste zachytili že poslední dobou najednou existují "vysokoteplotní" (resp. ne tak nízkoteplotní) nízkonákladové supravodiče (HTS). Například REBCO páska. Což mělo mimo jiné za následek vznik hned několika startupů na fůzní energii, protože s tímhle jediním vynálezem je najednou možné dělat silnejší magnety než má ITER na podstatně menší ploše a za zlomek ceny (Iter je v toroidních cívkách nějakých 12 Tesla, některé startupy co jsem tak koukal dávají kolem 20 Tesla). Konkrétně třeba Tokamak Energy (například tady).

Pak se poslední dobou hodně mluvilo o aneutronické (aneutroní?) fůzi: Radical hydrogen-boron reactor leapfrogs current nuclear fusion tech, to mi přijde naprosto fascinující, protože to jako jeden z mála zdrojů energie nepotřebuje elektromagnetické generátory na konverzi energie (a k tomu přidružené parní stroje jako třeba u jádra), ale rovnou z toho leze elektřina.

[Radovan]

Střídavá? Protože se stejnosměrnou se to hodí jen na malý lokální zdroj.

[xxxs]

"Protože se stejnosměrnou se to hodí jen na malý lokální zdroj."

mozes to vysvetlit?

[billgates]

Prenosove sustavy jednosmerneho prudu vo svete na dlhsie vzdialenosti

[Max]

Na základě čeho tak usuzuješ? Osobně si myslím, že reál může být až tak někdy kolem 2050. Tzn., za 30 let.
A to platí jen pro vyspělé země.
Zdar Max

[-]

Už teď je to nesmyslný anachronismus. Snad brzy přijde zákaz.

[Fluttershy, yay!]

Průměrné stáří aut v Česku je nějakých 15 let. Vzhledem k úrovni příjmů a způsobu organizace společnosti nejde počítat s tím, že by si lidé jen tak pořídili elektromobil – nebo autem přestali jezdit úplně. Přechod aspoň na plyn je ale na místě. Firemní flotily mezitím na elektro přejdou a dost možná se rozšíří i komunitní sdílení.

Na druhé straně, takoví Kubánci pod americkými sankcemi spravují mnohem starší auta (u kterých to ale ještě jde) a fungují; je to jedna z nejúspěšnějších společností co do udržitelnosti.

Taky může přijít urychlení jako ropné krize ze 70. let, které automobilový trh výrazně proměnily. A to včetně těch zákazů – jako např. výrazné omezení maximální rychlosti v USA.

[Bystroushaak]

a na přímém spálení ropného produktu s kyslíkem moc co optimalizovat není (na rozdíl třeba od auta, kde je pořád nějaká mechnika, dobré promíchání paliva apod, proti tomu je raketa jednoduchá brute force).

SpaceX zrovna dělá těch optimalizací docela hodně a taky mají jeden z nejlepších poměrů váha/tah.

Dopravit dané množství paliva na Mars bude asi největší oříšek pro to, abychom tam dokázali dopravit člověka.

Proto má Starship / Raptor létat na metan, který se dá vyrobit na místě vytažením oxidu uhličitého z atmosféry.

[PepaSFI]

asi největší pokrok je v tom že ty motory jdou opakovaně spolehlivě spouštet a jde jim regulovat tah ve velkém rozsahu, až asi na 50%. Což se sice může zdát jako banalita ale ono to je docela problém. Raketový motor je hned po jádru nejšílenější zdroj síly, vlastně je to takový částečně kontrolovaný výbuch, který se nedá nějak moc tahat za nohu. Funguje to v celkem úzkém rozmezí a když se to rozladí, buď to scípne nebo bouchne.

[Max]

IT se za posledních x let hodně transformovalo. Rozvoj internetu, AI, schopnosti software (modely, hry, animace, přechod na ssd, masivní multicore, ohebné displeje, masivní přechody na čím dál tím lepší LCD like technologie atd.), přechody na mobilní platformy. Posun ve výkonu je obrovský a každý rok, dva pěkně roste a spotřeba se snižuje. To pak např. umožnilo rozvoj AI v automobilové, letecké aj. dopravě.

To, že se "počítač" stále jmenuje "počítač" a "procesor" se stále jmenuje "procesor" neznamená, že tam ten vývoj není velký. To jen ty jsi si stanovil taková kritéria, aby byla co nejvíce obecná a nebylo v tom vidět nic konkrétního. Podle tvé mentality bychom pak mohli říci, že lidstvo se za posledních 20000 let vůbec nikam nepohnulo, protože stále dýcháme kyslík.
Zdar Max

[Radovan]

Jo, tranformovalo. Sítě byly mezi opravdovými počítači, ne dětskými hračkami jako Altair a ZX Spectrum, zcela běžné od začátku osmdesátých let, masivní multicore řídil Buran, ohebné displeje sice jdou ohnout, ale už ne narovnat. Zbytek je pouze rozvoj starých technologií, a hlavně zlevnění dané masovou výrobou. AI je stejně blbá jako před třiceti lety, jenom pracuje s miliardkrát většími objemy dat. Jak dobře funguje v letecké dopravě ukázal Boeing 737 MAX. Mezi lidi by to pustil jen Mengele. Snížila se spotřeba, dnešní top PC žerou už jenom pětkrát víc než ta z půlky osmdesátých let, zvýšil se jejich výkon, ale kancelářské programy běží pomaleji než na 286kách. A z Internetu, sloužícího k šíření vědomostí, se stal uřvaný lunapark blikající všudypřítomnými reklamami, který můžeš nosit v kapse. Viz Neználek na Měsíci, kapitola Ostrov hlupáků. Můžeš tomu říkat transformace, ale není to evoluce. Spíš naopak.

Nechci hodnotit jak daleko jsme se posunuli za posledních 20000 let, protože vědecké teorie vytvořené na základě kusých archeologických nálezů jsou z větší části něco mezi fantasy a pohádkami pro děti, a každých pár let se mění stejně tak jako obsah učebnic Občanské výchovy, ale kam jsme se posunuli za poslední 2000 let, které jsou podstatně lépe zdokumentované, je zřejmé: https://www.youtube.com/watch?v=fM4etrRq_AE

Holt jsem v tomhle skeptik. Ale možná je to právě tou sci-fi, kterou jsem tenkrát hltal, prostě si pod slovem pokrok představuji něco jiného. Znáš tohle? http://a.da.mek.sweb.cz/novotny.f/lomzv.htm

[Max]

Nikdo neříká, že nové technologie přinášejí jen samá pozitiva. Ty argumentuješ jen zobecňováním a zápory a nedokážeš si připustit jediný klad. Nemyslím si, že je to úplně zdravý pohled.
Zdar Max

[Radovan]

Je to pohled brýlemi zkušeností. Z optimizmu jsem prostě vyrostl. A ani mě se to moc nelíbí.

Ano, snažím se zobecňovat, abych se neupínal k zářícím neonům. Za nimi je toho totiž k vidění mnohem víc, třeba skládka odpadků. A starých vysvícených neonů.

A přečti si tu povídku, je tak dobrá, že tenkrát nesměla vyjít knižně :)

[Max]

To nejsou zkušenosti, ale silný pesimismus, ve kterém se utápíš.
Zdar Max

[Radovan]

Realizmus, ten je ještě horší.

Pesimista se totiž obává že to špatně dopadne, zatímco realista už bezpečně ví, že je to velé úplně v (_!_)

[Max]

Pokud jsi schopen vidět jen to nejhorší, jsi pesimista a vsugerovávat si něco jiného ti nepomůže .
Zdar Max

[Radovan]

Ale kdepak, já naopak i na tom nejhorším dokáži najít něco dobrého. Třeba Hitler docela hezky maloval

[Fluttershy, yay!]

Třeba Hitler docela hezky maloval

Moc ne.

Ale Hitler je ten chlapík, který zabil Hitlera. 👍

[Bherzet]

To není ani pesimismus. Říká se, že optimista je člověk s nedostatkem informací, ale Radovan ty informace právě taky nemá. Jednoduché mentální cvičení: jak dlouho by vám v 70. letech trvalo postavit e-shop nebo službu pro streamování videa? A to po vás nebudu chtít budovat celosvětovou informační sít, jen připojit pár paneláků a ukázat, jak jste se ve srovnání s dnešními standardy poprali s kryptografií, fulltextovým vyhledáváním, škálovatelností v případě expanze nebo spotřebou elektřiny.

Doporučuji každému si to (alespoň mentálně) vyzkoušet. Možná si pak najednou začnete cenit těch graduálních bezvýznamně-inženýrských vylepšení, když zjistíte, že ten moderní hardware je na tom se spotřebou a výkonem jaksi jinde, že se ten výkon dá ještě ušetřit použitím lepších datových struktur nebo algoritmů (úplně namátkou mě napadá HAMT – Bagwell, 2000), že není nutné uživatelská rozhraní skládat úplně od začátku, ale lze se opřít o samozřejmosti jako je IBM Common User Access, 1987, že to není nutné programovat v prapůvodní děsivé implementaci C a kód ručně optimalizovat, že se lze opřít o teorii ohledně distribuovaných systémů (např. OCC – Kung & Robinson, 1981) a tak dále.

[Radovan]

Jedna informace mi opravdu schází: kolik lidí v sedmdesátých letech potřebovalo e-shop nebo službu pro streamování videa?

Tenkrát byl vrchol informační technologie tištěný katalog Quelle s nulovou spotřebou energie.

A jinak tam jmenuješ věci z osmdesátých let

[Bherzet]

Jedna informace mi opravdu schází: kolik lidí v sedmdesátých letech potřebovalo e-shop nebo službu pro streamování videa?

Kolik lidí v 15. století potřebovalo jezdit na kole?

Tenkrát byl vrchol informační technologie tištěný katalog Quelle s nulovou spotřebou energie.

Nebyl bych si tak jistý, že na tisk a distribuci tištěného katalogu se spotřebuje méně energie než by se spotřebovalo distribucí a konzumací elektronickou cestou. Tady třeba neberou v potaz servery a síťovou infrastrukturu, kde se to blbě počítá, ale ten rozdíl ve prospěch elektroniky jim vyšel tak velký, že je nepravděpodobné, že by to celková energie spotřebovaná na distribuci po vydělení počtem distribuovaných stránek převážila na opačnou stranu.

A jinak tam jmenuješ věci z osmdesátých let

Ano, některé. To znamená věci, které v těch 70. letech vynalezeny ještě nebyly. Obdobně by bylo možné hledat příklady z libovolné jiné následující dekády.

[Radovan]

Spotřebuješ na výrobu toho katalogu víc energie a surovin než na výrobu notebooku?

Podle toho, kolik reklamních letáků tu máme skoro každý den ve schránkách, určitě ne

[Bherzet]

~23,8 kJ na zobrazení stránky (při 4,340 GJ na výrobu, pěti letech a 100 stránkách denně). Po přičtení k 5,4 kJ spotřebovaných při tříminutovém čtení té stránky, se kterým tam kalkulují, to je pořád míň než těch 150 kJ u papíru.

[Radovan]

V tom případě by ty letáky mělo urychleně řešit ministerstvo životního prostředí. A velmi brutálně reagovat

[kralyk z abclinuxu]

To by bylo fajn no, dost mě vysírá, jak toho mam furt plnou poštovní schránku.

No jinak docela tě Bherzet setřel mam dojem

[Radovan]

Pouhý dojem. Zkus si to přepočítat a přidat tam pár opominutých údajů. Například recyklaci.

[kralyk z abclinuxu]

Nebo distribuci těch letáků...

[Radovan]

A na distribuci elektrické energie, kterou ten leták vůbec nepotřebuje :-P

No, vypadá to že asi shodneme na jediné věci, že ty letáky by se měly zakázat.

[deda.jabko]

Tebou zvolene priklady jsou fascinujici.

masivní multicore řídil Buran

Masivni multicore pocitace se na zapadnim trhu pouzivaly (komoditne) uz v sedmdesatych letech.

Viz Neználek na Měsíci, kapitola Ostrov hlupáků

Zkontroluj kalendar! Mame rok 2020 a argumentovat detskou, tezce propagandistickou knizkou z padesatych let pusobi prinejmensim hodne komicky.

Zbytek je pouze rozvoj starých technologií, a hlavně zlevnění dané masovou výrobou.

Ono to uz tak byva, ze se veci postupne vyviji.

AI je stejně blbá jako před třiceti lety, jenom pracuje s miliardkrát většími objemy dat.

Ac termin AI nemam rad, chtel bych podotknout, ze to, co dela AI dostatecne chytrou, jsou prave ty miliardkrat vetsi objemy dat, jejichz zpracovani by nebylo mozne bez zasadniho vyvoje v dalsich oblastech. Takze rict "jenom" je nemistna bagatelizace. Schvalne si vezmi bezny pocitac z roku 1990 a zkus na nem trenovat neuronovou sit, ... ale ne, nebudeme to komplikovat bude stacit, kdyz na tom pocitaci budes schopen prehrat mp3 soubor.

[Radovan]

Ona je to komunistická agitka jenom na povrchu, musíš hlouběji. Původní podoba Neználka nebyla určená dětem, to je jenom kamufláž, chránící autora před jistým gulagem. Sám nejlépe věděl co píše...

Ano, pamatuješ jak se v padesátých/šedesátých letech překračoval plán a kvalita nahrazovala kvantitou? Mohl sis třeba koupit oblek s nepřišitým rukávem, ale bylo to na 105%. Budovalo se a rozvíjelo. Tak se dnes neuronové sítě dostaly na úroveň čerstvě vylíhnutého chrousta.

A kdo umí, ten umí: https://www.youtube.com/watch?v=eM3yp7U59e0

[deda.jabko]

Ona je to komunistická agitka jenom na povrchu, musíš hlouběji.

Snazis se pekne... ale na povrchu je to knizka pro deti, pod povrchem je tezka komunisticka propaganda a pod tim je jeste neco, co pochopi jen ti nejosvicenejsi...

Ano, pamatuješ jak se v padesátých/šedesátých letech překračoval plán a kvalita nahrazovala kvantitou?

Nepamatuju, nejsem duchodce.

Tak se dnes neuronové sítě dostaly na úroveň čerstvě vylíhnutého chrousta.

Sice pochopils tajemstvi ukryte v Neznalkovi, ale to, co jsem psal, jsi v lepsim pripade nepochopil, v horsim ani neprecetl.

kvalita nahrazovala kvantitou

V pripade strojoveho uceni nefunguje dichotomie mezi kvalitou a kvantitou, ale kvantita je faktor urcujici kvalitu.

[Aleš Kapica]

Neználek na měsíci, ze z té série dost vymyká.

[marbu]

Řekl bych, že třeba vývoj v hardware a miniaturizace je pro nasazení ve vesmíru docela zásadní: ty řídící počítače jsou mnohem menší, lehčí a mají menší spotřebu. Takže i když např. již to zmiňované plně automatizované dokování Sojuzu s Mirem nebo plně automatický let Buranu bylo možné vyvynout pro hardware 80. let, dnes tu samou funkcionalitu jde nacpat do mnohem menších, a tím pádem výrazně levnějších věcí.

[j]

Az na to, ze presne tahle to nefunguje ...

Kdybys o tom neco vedel, tak ve vesmiru je vyrazne vetsi zareni nez na zemi, a to jaksi zpusobuje, ze prave ta miniaturizovana elektronika tam nefunguje (nebo nespolehlive).

Kupodivu se presne z tohodle duvodu pokud vim jeste stale vyrabi i386. Protoze ty chipy nemaji jeste tak velky problem a vykonostne naprosto bohate staci (najdi si, s cim letelo apolo, kazdy hodinky jsou vykonejsi).

Pricemz cena v tomhle ohledu je zcela marginalni, nikoho nezajima. Jediny co kazdyho zajima je hmotnost. Protoze cena dopravenyho kg je presne to, co se prakticky vubec nijak nemeni.

---

Dete s tim guuglem dopice!

[Max]

Těžko říci, jak velký reál to dnes je. Přecijen, na ISS dlouhou dobu měli a možná ještě mají Thinkpady.
Zdar Max

[trekker.dk]

To jo, jenže na práci, kde nevadí, když se to kousne. Pochybuju, že by tím řídili kritické systémy.

[deda.jabko]

Kupodivu se presne z tohodle duvodu pokud vim jeste stale vyrabi i386. Protoze ty chipy nemaji jeste tak velky problem a vykonostne naprosto bohate staci

No, mozna pred deseti lety.

Protoze cena dopravenyho kg je presne to, co se prakticky vubec nijak nemeni.

Doporucuji nastudovat treba: The Recent Large Reduction in Space Launch Cost

Commercial launch has reduced the cost to LEO by a factor of 20.

Fakt nemeni...

[marbu]

Kdybys o tom neco vedel, tak ve vesmiru je vyrazne vetsi zareni nez na zemi, a to jaksi zpusobuje, ze prave ta miniaturizovana elektronika tam nefunguje (nebo nespolehlive).

Jo, pro použití ve vesmíru je třeba řešit odolnost proti kosmickému záření, a tak se často musí extra navrhnout a vyrobit stejný čip odolný proti radiaci. Stejně tak je pravda, že na spoustu řídících funkcí není nějaký extra výkon vůbec třeba.

To že se často používá starší hardware je ale také dáno jak tím, že délka vývoje družice/lodě/rakety je většinou poměrně dlouhá, tak tím že náročnost vývoje a testování hardware se zvýšenou odolností proti radiaci jej prodražuje, a tak se nevyplatí hned vyvíjet novou generaci.

Kupodivu se presne z tohodle duvodu pokud vim jeste stale vyrabi i386. Protoze ty chipy nemaji jeste tak velky problem a vykonostne naprosto bohate staci (najdi si, s cim letelo apolo, kazdy hodinky jsou vykonejsi).

Speciální "space grade" i386 mají v řídícím počítači na ISS, ale neznám novější věc, co by takové 386 používala. Curiosity rover z roku 2011 má v sobě BAE RAD750, který je na trhu od roku 2001.

Pricemz cena v tomhle ohledu je zcela marginalni, nikoho nezajima.

V momentě kdy navrhnete hardware družice a pak zjistíte, že by šlo něco málo ušetřit na hardware to smysl fakt nemá. Ale když vezmete v potaz současné možnosti, může vám z toho vyjít nový typ použití, který by dříve nešlo kvůli příliš težkému počítači realizovat. Ať už je to přistání 1. stupně rakety Falkon 9, různé kubesaty, komerční družice pro snímání Země nebo třeba ty velké soustavy družic pro poskytování internetu z nízké oběžné dráhy.

[MadCatX]

Kolega "j" zase chytrý jak rádio. Třeba Falcon 9 žádné speciální zodolněné elektronické součástky nemá. Počítače autopilota mají nějaké tuctové x86 dvoujádro, kontroléry řídících komponent používají PPC. Na každém ze třech pilotujících počítačů se vykoná každý řídící povel paralelně a porovná se výsledek. Totéž udělají kontroléry servomotorů trysek a dalších zařízení, které AP ovládá. Tím se zaručí dostatečná redundance a korekce chyb, aniž by se musel použít drahý specializovaný hardware. Právě využití jednoduše dostupných a běžných dílů je jeden z důvodů, proč je celý SpaceX program ekonomicky efektivní.

[j]

Takze o vom vis lautr hovno, coz ti nebrani o tom zvanit, ze? Mas k tomu neco nebo tu jen tak blejes?

---

Dete s tim guuglem dopice!

[Bherzet]

S těmi silnými výrazy bych byl opatrný.

SpaceX uses multiple redundant flight computers in a fault-tolerant design. Each Merlin rocket engine is controlled by three voting computers, each of which has two physical processors that constantly check each other. The software runs on Linux and is written in C++.[66] For flexibility, commercial off-the-shelf parts and system-wide radiation-tolerant design are used instead of rad-hardened parts.[66] Each stage has stage-level flight computers, in addition to the Merlin-specific engine controllers, of the same fault-tolerant triad design to handle stage control functions. Each engine microcontroller CPU runs on a PowerPC architecture.[67]

   – https://en.wikipedia.org/wiki/Falcon_9

SpaceX uses an Actor-Judge system to provide triple redundancy to its rockets and spacecraft. The Falcon 9 has 3 dual core x86 processors running an instance of linux on each core. The flight software is written in C/C++ and runs in the x86 environment. For each calculation/decision, the "flight string" compares the results from both cores. If there is a inconsistency, the string is bad and doesn't send any commands. If both cores return the same response, the string sends the command to the various microcontrollers on the rocket that control things like the engines and grid fins.

The microcontrollers, running on PowerPC processors, received three commands from the three flight strings. They act as a judge to choose the correct course of actions. If all three strings are in agreement the microcontroller executes the command, but if 1 of the 3 is bad, it will go with the strings that have previously been correct. The Falcon 9 can successfully complete its mission with a single flight string.

   – https://space.stackexchange.com/questions/9243/what-computer-and-software-is-used-by-the-falcon-9

[MadCatX]

Začni třeba tady a zbytek si vygoogli.

[marbu]

Posunuli jsme se od joysticku k do značné míry automatické raketě.

Tady bych jen dodal, že dokování malé lodě/kapsule s velkou stacionární stanicí bylo plně automatizované vždycky. Poprvé to řešili Sověti, kteří v 80. letech vyvynuli systém KURS pro dokování Sojuzu se stanici Mir, kdy už předchozí metodu, která počítala s pomocným natočením samotné stanice, nešlo kvůli velikosti stanice použít. Manuální systém řízení TORU byl zamýšlen jen jako záloha pro případ selhání automatického systému.

Když se rozpadl SSSR a ukázalo se, že KURS je plně ve vlastnictví Ukrajiny, Rusové zkusili otestovat jak by fungovalo manuální dokování s použitím TORU při běžném provozu, aby nemuseli Ukrajině plalit za licenci než by si vyvinuli náhradu. Což skončilo kolizí a málem to vedlo k evakuaci stanice, takže příště se již zase používal automatický systém.

[j]

Ehm ... ani ne.

Plne automaticky lital uz Gagarin. Ve skutecnosti tam vsechny ty ovladaci prvky davali jen proto, aby cvicene opicky (posadka) byly spokojene.

A co se provedeni tyce, tak mechanicky tlacitko je o par radu spolehlivejsi vehement, nez patlaci obazovka. Chtel bych videt, co by se asi tak s tou obrazovkou delo pri nejakych 10+G.

Jo a ty sojuzy ze za tech 50 let taky pomerne dost zmenily, a ve skutecnosti, co myslis, kde ze musk bere motory?

---

Dete s tim guuglem dopice!

[deda.jabko]

Chtel bych videt, co by se asi tak s tou obrazovkou delo pri nejakych 10+G.

Asi nic zasadniho a vlastne ta otazka je irelevantni, protoze nebude nikdo schopen ji ovladat.

co myslis, kde ze musk bere motory?

Ze by si je sam vyvijel a vyrabel? Pletes si to s ULA.

[ehmmm]

Ze vam vstupuju do diskuze.

Netusite, kolik G mel Armostrong na Gemini 8?

A co se tzka automatikz, tak myslim, ze napr. od Tereskovove se vyzadovala alespon nejaka minimalni spoluprace, aby mohla pristat?

[Blaazen]

Nevím, ale viděl jsem rozhovor s pilotem Gripenu. Říkal, že mu anti-G oblek pomůže tak o 1,5G a zbytek je trénink. Zde (asi prvních osm minut je o přetížení a dýchání).

[PepaSFI]

teď nevím jestli Těreškovová musela něco ovládat, například spustit nějakou přistávací sekvenci ve správnou chvíli ale ono se to kosmidlo nějak moc nedalo řídit. To přistání bylo vlastně takové " když se trefíme na kontinent bude to dobrý". Ostatně i dnes je to docela drsná jízda na pekelným tobogánu.

Každopádně zrovna Těreškovová je dobrý příklad, ona na svou nekázeň málem doplatila, moc nechybělo a urazila by si hlavu. Tenkrát ještě neuměli kabinu ubrzdit na přijatelnou rychlost a proto kosmonaut přistával samostatně na svém padáku. A protože katapultáž není žádná sranda, musí se přesně dodržet postup, zaujmout přesně určenou polohu v křesle. A protože tkadlena Těreškovová neměla zkušenosti a kázeň bojového pilota, při katapultáži něco udělala blbě a dostala ránu do helmy, takže ji pak fotili jen z jedné strany aby nebyla vidět modřina přes půl ksichtu. že si pak po přistání posvačila s vesničany, čímž znehodnotila lékařské a biologické údaje, to už je jen drobná chybička.

[GeoRW]

Tak, ked v tom chcu vozit turistov, tak to musi nejako vypadat

[bsdbest]

tri modre obrazovky zrejme naznacuju, ze pocitaju hlavne s mladsimi generaciami

[Odin1918]

Fandim jim, ale na druhou stranu nechapu vubec snazeni cloveka letat do vesmiru a udrzovat tam stanici. Clovek tim prekracuje urcitou hranici. Neni nic dobreho snazit se koukat panu bohu do oken. Na jednu stranu chteji vlady lidem zakazovat auta, na stranu druhou maji snahu letat k iss a na mesic a cert vi kam. Kdyby se radeji zamerili na vedecky vyzkum na zemi. Nebo kdyby vlady radeji nedelali nic, tim by udelali nejlepe.

[pavele]

Proč vznikl linux - nějaká vláda snad pomáhala a platila vývoj?

Proč byl dobyt severní pól? Vždyť tam nic není.

Kolik lidí umřelo, než se zjistilo, které houby jsou jedlé?

Kolik lidí umřelo na otravu rostlinami, než zjistili, k čemu se dají použít na léčení?

Proč se dobrovolně nechal někdo infikovat borelií z komárů, chtěl snad umřít na žlutou horečku?

Proč se snažili dosáhnout dna Mariánského příkopu? Jediné, co za to mohli získat, byla smrt.

Proč se horolezci snaží vylézt na horu K3? Vždyť je tam nic nečeká.

Snažíš se říct, že bychom měli sedět za pecí, poslouchat nadřízené a do úmoru pracovat? Znáš betrizaci od Stanislawa Lema?

Proč? Protože tam ta hora je, protože ten měsíc tam je, nebýt výše uvedeného, dodnes bychom jedli kořínky, léčili se vyháněním zlých duchů.

Co na tom nechápeš? O všem rozhodují peníze. S výjimkou nadšenců, kteří táhnou ten pokrok vpřed.

Vždyť i dnes seženeš peníze na kdejakou pytlovinu na crowdfundingovém portálu, ale "důležité" projekty (třeba bezpečnostní knihovny pro šifrování) skomírají na peníze...

[PepaSFI]

jsou jen dvě věci, co posouvají pokrok kupředu. Jedna je bláznovství nadšených pošuků a druhá je šílenství zločinných pomatenců. Prostě to buď vymyslí a po spoustě útrap a neúspěchů postaví magor co si nedá říct že to nejde, že nikdo rozumný by přece neryl do země aby tam zapích rostlinku a čekal půl roku než vyroste, když je lepší sedět na haluzi a žvejkat bobule a doufat že přes zimu nechcípnu. Nebo to postaví někdo protože musí, za vynaložení obrovských nákladů a snažení, protože musíme udělat větší klacek než mají ti za kopcem protože nám sem chtějí vlézt a když je nepraštíme po hlavě tak nám všecko sežerou.

[Radovan]

jsou jen dvě věci, co posouvají pokrok kupředu. Jedna je bláznovství nadšených pošuků a druhá je šílenství zločinných pomatenců.

Tak tohle ukládám do archivu, protože jsi to vystihl dokonale.

[Gréta]

si jako myslim že člověk má vodjakživa právo vobsazovat ve vesmíru novej lebensraum pro svuj volkerschaft ;D ;D

[dqqw]

Vsechno dotekove. Je problem to mackat v aute za normalni jizdy.

Pri reentry, za 10g, otresech a rotaci to musi byt sranda to obsluhovat. Ale urcite tam maji par her, ktere si mohou zahrat po pristani )

[billgates]

1. Preto je to vsetko automatizovane a myslienka je, ze obsluha by do toho nemala vobec zasahovat
2. Najdolezitejsie komponenty maju aj fyzicke ovladanie

Dolezite je aj to, aby nemali okolo seba tisic roznych zobrazovacov vsetkeho mozneho, ale mali vsetko vzdy vo svojom zornom poli a "taby" si vedia prepnut aj tlacidlami na sedadle.

[Aleš Kapica]

V podstatě nic nového. Upřímně řečeno, v přítomnosti lidského elementu na orbitě nevidím žádný smysl. A blouznění o expanzi na jiné planety, jen vyvolává planou naději, že se skupina vyvolených bude mít kam přesunout, až ti nejrůznější inženýři lidských duší učiní zemi definitivně neobyvatelnou.

[_]

Jsi prostě už stará senilní konzerva, bez fantazie a relevance pro budoucnost.

[Aleš Kapica]

Rád ti tuhle budoucnost přenechám. Nech se laskavě vystřelit co nejdřív.

[_]

Však nám ji již brzo přenecháš, o tom není pochyb.

[Radovan]

Ty se už nech co zahrabat vrstvou hlíny, už na to tobě nezáleží.

[Radovan]

???

[Radovan]

!!!

Svět patří mladým.

[Nie som robot]

svet patri zlym!

[Max]

Já ten smysl vidím velký, urychluje to vývoj. Zatím nemáme stroje a AI na takové úrovni, aby dokázaly nahradit člověka. Jedna malá závada a je konec, přitom člověk by to dokázal opravit relativně rychle. Takže člověk na orbitě, na Měsíci a i jinde je zatím stále důležitý a dlouhou dobu ještě bude. A nedělám si iluze, že schopná autonomní AI tu bude do 500 let. Ještě zbývá hodně pokroku, aby se vylepšil hw (výkon, napájení, ochrany před zářením, sensory apod.) a i sw.
Stačí se podívat na automobilový průmysl, kdy asi nastane doba plného AI a bezvolantových aut? Ano, něco už je, ale je to stále v režimu test a jezdí na stále stejným místě (jedno město).
Zdar Max

[Aleš Kapica]

Nevím, ale řekl bych, že náklady na vystřelení boxu se sadou nových družic budou řádově mnohem nižší, než na vystřelení cca 2x 100 kg živé váhy + nezbytné příslušenství.

[Max]

Samozřejmě, ale člověk za rok zvládne to, co robot za dvacet. A pak jde s tím i ruku v ruce vývoj cestování pro lidi.
Zdar Max

[Aleš Kapica]

JO. Neškodilo by, kdyby někteří jedinci přispívající do zdejších diskuzí odcestovali co nejdřív. (viz výše)

[j]

Myslis jako zapichnout vlajku a sebrat par sutru? Na Mesici byl JEDINY vedec. Vsechno ostatni byli vojaci, ktery tam leteli jen a prave kvuli zapichnuti ty vlajky a porizeni fotek.

Ve skutecnosti je libovolnej automat radove uzitecnejsi a radove levnejsi.

Cestovani lidi je hovadina i v podobe cest do prace. Specielne v situaci, kdy nejmin 50% z nich stejne sedi nekde v kanclu. Meziplanetarni cestovani je pak velehovadina. Minimalne dokud nebudem schopny na ten Mars doletet v radu jednotek dnu max.

Ostatne, zajimavy, ze se prave v souvislisti s timhle startem nejak pozapomelo, ze prave amici davaji od ISS ruce pryc a nechteji dal platit dalsi provoz. Pritom bez provozu staly stanice mnohem vetsich rozmeru se jaksi ani na Mesic neda nic moc dopravit.

Dokonce je to tak, ze pokud by na mesici mel byt nejaky trvaly provoz, tak je treba velka stanice i u nej.

---

Dete s tim guuglem dopice!

[Max]

Bagatelizace a zesměšňování pro mně nejsou žádné argumenty ani cesta k nějaké rozumné diskusi.
Zdar Max

[drnest]

Jéčko, to je jak rádio Jerevan

"amici davaji od ISS ruce pryc a nechteji dal platit dalsi provoz"

Ano je to pravda jen s drobnými rozdíly. Nejsou to amíci, ale rusové a nejedná se o ISS, ale o budoucí stanici Gateway u Měsíce.

NASA nastínila blízkou i vzdálenější budoucnost ISS

[Nie som robot]

ad 1

[Nie som robot]

https://www.rouming.cz/upload/fejk_and_gej.jpg

[Max]

Why does the SpaceX droneship camera cut out?
Zdar Max

[marbu]

Docela mě překvapilo, že rozhraní pro ruční řízení, které včera a dneska testovali, nejen vypadá (to jsem čekal, navíc to tam mají přímo napsané) ale se i ovládá úplně stejně jako na jejich webové hře simulující dokování s ISS, tj. pomocí stejných gui tlačítek zobrazených na tom dotykovém displeji. Skoro jsem čekal, že tam někde mají nějakou sadu joisticků nebo tlačítek.

[Max]

Ano, je to simulátor, takže to vypadá stejně. Tlačítka tam mají pro nějaké kritické věci, ale nevím, pro co všechno.
Zdar Max

[marbu]

Jako jo, akorát jsem si do včerejška představoval, že mezi ty kritické věci patří nějaký emergency joystick (který je někde schovaný, případně sada tlačítek) pro manuální řízení lodi. Ale ono to v reálu vypadá uplně stejně jako když si spustíš ten simulátor na tabletu.

Dobře je to vidět např. na obrázcích z článku NASA astronauts successfully pilot SpaceX’s Crew Dragon spacecraft manually for the first time.

[Josef Kufner]

Ono mají nouzová tlačítka – jsou to ty řádky pod displeji. Prý to je jen pro případ, že by se porouchaly ty displeje. Asi ve vesmíru není problém mít ruce na dotykovém displeji a při startu a přistání je to jedno. Také bych očekával nějaký joystick na křesle, ale ten simulátor jsem si na velkém dotykovém displeji zkoušel a je to docela v pohodě.

[billgates]

Aj na ruckach sedadiel su tlacidla, ktorymi sa daju vykonavat niektore zakladne operacie, hlavne bezpecnostneho charakteru + vysielanie a prijimanie audia atd. Skusam to googlit, lebo pred casom som o tom cital skvely clanok, ale teraz google vyhadzuje akurat hromadu komercneho hype bordelu, takze to neviem najst.

[Bherzet]

Skoro se až nechce věřit, že vzlétly z téhle země. Tohle by mohlo přerůst v občanskou válku, v kombinaci s COVIDem americkou ekonomiku totálně zdecimovat a stáhnout do recese zbytek světa…

RIP Floyd.

[Bherzet]

Sorry, viděl jsem nějaké další záznamy a změnil jsem názor. Tohle je občanská válka. Demonstrace je příliš mírné označení na to, co se tam děje.

[Radovan]

Jestli na tu Národní gardu a vojenskou policii začnou střílet, tak možná bude. Ale zatím je to jenom bordel jako v osmašedesátém: https://politikus.ru/uploads/posts/2020-05/1590918306_2020-05-31-11.44.29.jpg

[Aleš Kapica]

Tak to je vážně úlet. Pri nic za nic asi toho "něžného obra" nezakleknul. Podle toho co jsem četl spolu kdysi pracovali v nějaké bezpečnostní agentuře, takže ho nejspíš dost dobře znal na to, aby mu z toho krku neslezl. Ten černoch nebyl žádné neviňátko. Kdyby se skutečně snažil sekat po návratu z basy dobrotu, tak by nedopadl jak dopadl.

Celá ta záležitost dokazuje pouze to, kam to dotáhla přehnaná hyperkorektnost v USA. A výsledkem bude pouze to, že to nažene další voliče do Trumpovy náruče. Bílé i černé.

[Ruža Becelin]

Zkus někoho požádat, ať ti deset minut klečí na krku - pokud to přežiješ, o čemž silně pochybuji, můžeš napsat blog o adekvátních donucovacích prostředcích.

A to píši jako člověk, co by při pohledu na rabující plebs sáhl minimálně po gumových projektilech. Minimálně.

[luky]

Preliminary results from the official autopsy found no indication that Floyd died of strangulation or traumatic asphyxia, but that the combined effects of being restrained, underlying health conditions, including coronary artery disease and hypertensive heart disease, and potential intoxicants in his system likely contributed to his death

[Ruža Becelin]

Takže kdyby přijeli, rychle ho sebrali, nedělali divadlo na mobily, tak to přežil a nemuseli mít plebs na ulici, že jo

[luky]

Tak oni ho chteli rychle sebrat, ale nejdriv meli problem ho z jeho auta vytahnout a pak zas do dalsiho auta nacpat. To je i duvod, proc skoncil na zemi vedle auta - nechtel do nej nastoupit.

[Aleš Kapica]

Nemyslím, že by někoho žádal o to aby mu klečel na krku. Myslím si, že tomu mohl předejít tím, že by mu na ten krk nikdo zakleknout nemusel.

Nevím jak se celá ta záležitost sběhla. Ani to nehodlám zjišťovat. Ale je to už minimálně podruhé, co se stal záminkou k tomu aby černoušci začali dělat bordel smrtelný úraz černého darebáka, ke kterému přišel při výkonu svého povolání.

[Aleš Kapica]

A než se tady začnou ozývat zdejší magoři podotýkám, že mám mezi černoušky řadu přátel a ti mají na věc podobný náhled jako já.

[_]

Loool, nejsem rasista, mám za kámoše černochy. Nejsem sexista, mám i kamarádky. Nejsem xeonofob, nakupuji u větrošů ve večerce.

To ti už dneska nikdo nežere, to fungovalo možná tak dekádu z5. Najdi si jinou výmluvu.

[Aleš Kapica]

Největší hovada která jsem v životě potkal nebyla ani mezi cikánama, ani mezi černochama, ani mezi asiaty, s nimiž jsem strávil docela dost času. Ale mezi čechy, co se přesně tak jako ty tupě usoudili, že ten, kdo má na hlavě číro, nebo je vyholený, nebo se jinak vymyká jejich chápání světa, musí být nutně rasista. Zákeřné zbabělé brněnské svině, které neváhaly ze zálohy zaútočit na nic netušícího kámoše z kolejí jen proto, že na něj ukázal prstem zamindrákovaný majitel, když jsem byl zrovna na hajzlu.

[deda.jabko]

Největší hovada která jsem v životě potkal nebyla ani mezi cikánama, ani mezi černochama, ani mezi asiaty, s nimiž jsem strávil docela dost času.

Ja vim, nejsi rasista, ale ... presto o lidech uvazujes na zaklade jejich vnejsich vlasnosti.

Dosad si misto toho jiné vlasnosti a (mozna) uvidis, co za hloupost pronesls.

Největší hovada která jsem v životě potkal nebyla ani mezi modrookýma, ani mezi černovlasýma, ani mezi zrzkama, s nimiž jsem strávil docela dost času.

Nebo

Zákeřné zbabělé brněnské svině, které neváhaly ze zálohy zaútočit

vs.

Zákeřné zbabělé židovské svině, které neváhaly ze zálohy zaútočit

[luky]

Ja vim, nejsi rasista, ale ... presto o lidech uvazujes na zaklade jejich vnejsich vlasnosti.

Tak spousta vlastnosti je alespon castecne ovlivnena genetickou vybavou. Dobre je to videt u psu, kde mezi jednotlivymi plemeny jsou znacne rozdily v charakteru.

[Radovan]

Pokud tohle tvrdíš o lidech, jsi rasista

[Bherzet]

Lidi se cíleně nešlechtí. Což neznamená, že rozdíly neexistují, ale pro jejich dostatečně přesný opis je potřeba významně složitější model než je většina lidí schopna pochopit, neřku-li sestrojit a z paměti spočítat, takže je vesměs lepší jim říct, ať se o to ani nepokoušejí a s těmi pojmy raději vůbec nepracují, protože závěry, které jinak produkují, je pak bolestivé poslouchat.

[-]

Brva kůže je vlastnost jako každá jiná. Tedy obdobné rozdíly lze očekávat u mnoha na první pohled neviditelných vlastností. To je biologická realita.

Zbytek je politika.

[podlesh]

Brva kůže je vlastnost jako každá jiná. Tedy obdobné rozdíly lze očekávat u mnoha na první pohled neviditelných vlastností. To je biologická realita.

Ne, není. Různé vlastnosti se chovají různě a hodně dlouho trvalo než dokázali biologové najít alespoň nějaká pravidla (Mendel natrefil na obzvláště jednoduchý případ).

Zbytek je politika.

Ano. Jakmile někdo použije termín "biologická realita", můžeme si být na 99.9% jisti že se jedná o čistou politiku.

[Aleš Kapica]

Zajímalo by mě, kde se ve vás bere to přesvědčení, že černoušci a jiné, pro nás exotické skupiny nehovoří o nás zrovna tak. A pokud to neuráží mne, nechápu proč by to mělo urážet je.

Mimochodem, na rozdíl od vašeho příkladu jsem použil konkrétní označení dle lokace a chování, nikoliv dle etnické příslušnosti a schématu založeného na nějakém obecně zažitém stereotypu, jako jste ve svých příkladech uvedl vy. V tom je ten zásadní rozdíl.

Rasismus je sám o sobě neutrální. Nebezpeční jsou ti, co si ho berou do ruky jako klacek aby mohli páchat násilí na jiných. A je úplně jedno, jakou mají barvu pleti. V USA možná šikanujou černochy, ale v JAR je situace zcela opačná a tady o tom neštěkne ani pes, aby snad náhodou na něj někdo neukázal prstem.

[trekker.dk]

Myslím, že to označení platí nejvíce na vás... schvalovat zabití člověka s předpokladem, že to byl kriminálník, i když sám přiznáváte, že nevíte, jak se celá událost seběhla, to normální člověk neudělá.

[Aleš Kapica]

Vy jste nepoučitelný. Opět si vymýšlíte a překrucujete co jsem napsal, protože jsem o žádném schvalování ani nepípl. Jenom jsem poukázal na to, že ten člověk nebyl bezúhonný, a k tomu aby se ocitnul v té situaci svým dílem přispěl. A taky jsem podotknul že to není poprvé co černoušci zneužívají úmrtní černocha, který šel svému štěstíčku naproti, k tomu aby mohli dát průchod vlastní nenávisti.

Zajímavé je, že u jiné skupiny, jako např. hispánci, v případě že policie sejme podobného typa z jejich řad, takovým způsobem nedemonstrují.

[trekker.dk]

takže ho nejspíš dost dobře znal na to, aby mu z toho krku neslezl. Ten černoch nebyl žádné neviňátko. Kdyby se skutečně snažil sekat po návratu z basy dobrotu, tak by nedopadl jak dopadl.

Takže zároveň obhajujete ten postup (znal ho dobře, aby z něj neslezl), ale zároveň to neschvalujete. To je trochu rozpor, ne?

černocha, který šel svému štěstíčku naproti

Což je vám jasné na základě toho, že nevíte, jak se celá událost seběhla.

hispánci, v případě že policie sejme podobného typa z jejich řad, takovým způsobem nedemonstrují.

To je docela chyba, protože policie nikde není od toho, aby někoho "sejmula"

[Ruža Becelin]

No jo no, kdyby se všichni chovali jak mají, na co by byla policie. Kdyby byly v pr* ryby... prostě ten zásah podělali a na konci je mrtvý člověk a plebs v ulicích.

Mimochodem plebs dělá problémy bez ohledu na barvy pleti - v USA, v Evropě, všude... Tak proč jim dávat záminku.

[Max]

Podle mně klečením na krku dotyčného nedusil. Aby ho dusil, musel by mu klečet na krku zepředu, nebo by musel klečet z druhé strany, kde má tepnu (to by ho ale nedusil, ale rychle uspal).
Pokud se tedy černoch dusil, tak jen kvůli tomu, že někdo seděl na něm a měl přimáčklý hrudník. To pak člověk může s velkou snahou mluvit, ale je to vysilující a postupně už nebude moci roztáhnout plíce a udusí se.

Jak moc je přimáčknutí hrudníku vážné bylo ověřeno několikrát. Stačí být ve výkopu a být zavalen po prsa hlínou a než vás vyhrabou, udusíte se.
Zdar Max

[kol-ouch]

Prdel je, že nemusíš být ani moc hluboko zasazený - když tě to blbě a rychle chytí, tak ti zvýšený krevní tlak (ze zmáčklých cév) škubne něco v hlavě, nebo v srdci a je vymalováno. Viděl jsem dokumentaci k případu, kdy byl borec zavalený do pasu a nedal to

[Ruža Becelin]

Dobrá poznámka - podle některých údajů na něm klečeli 3 nebo 4.

[Seržant]

Podle mně klečením na krku dotyčného nedusil. Aby ho dusil, musel by mu klečet na krku zepředu, nebo by musel klečet z druhé strany, kde má tepnu (to by ho ale nedusil, ale rychle uspal). Pokud se tedy černoch dusil, tak jen kvůli tomu, že někdo seděl na něm a měl přimáčklý hrudník.

Takže by asi moc nepomohlo, kdyby ten policajt neměl koleno na jeho krku? Přitom tohle bylo asi nejvíc kritizované. Otázka je, jak pachatele zneškodnit, aniž by se mu něco stalo. Obávám se, že nějaké riziko nehody tady bude vždycky. Zvlášť když je pachatel velký a agresivní, případně i nadrogovaný. Jestli nesedíte jen u počítačů a jestli jste se někdy s někým poprali, tak musíte vědět, že odhadnout správnou míru použité síly je těžké. V podstatě vždycky se tu člověk pohybuje na tenkém ledě - na rozhodování má minimum času, pracují emoce, nemáte kompletní informace a stejně se musíte nějak rozhodnout, např. neznáte zdravotní stav toho druhého, zároveň nevíte, jestli nemá v kapse nůž nebo jinou zbraň, jestli vás nebude chtít pokousat nebo poškrábat, jestli vás tak nenakazí nějakou nemocí atd. Jasně, nejlepší je se tomu fyzickému střetu vyhnout, ale když jste policajt, tak ty fyzické střety jsou nedílná součást vaší práce. Měla by být snaha to množství nehod minimalizovat, ale stejně tu zbude nějaké nenulové riziko. A kdo ho má nést? Podle mého spíš ten, kdo se rozhodl páchat trestnou činnost a pak navíc dělat problémy při zatýkání. Byla to jeho volba. Nemyslím si, že by riziko měl nést daňový poplatník, oběť trestného činu nebo policista, který má za nevalný plat zajišťovat naši bezpečnost a vymahatelnost zákonů.

[Aleš Kapica]

Podle mě se zdejší mudrlanti co toho policajta odsuzují naposledy prali někdy ve školce, jestli vůbec. Takže o té situaci nemají reálnou představu.

[Bystroushaak]

Podle mě se zdejší mudrlanti co toho policajta odsuzují naposledy prali někdy ve školce, jestli vůbec. Takže o té situaci nemají reálnou představu.

Jakou reálnou představu? Vždyť jsou tam na něj tři, zavražděný černoch leží na zemi s rukama spoutanýma za zády a prosí policajta ať mu sleze z krku, že nemůže dýchat („PLEASE, PLEASE, I can't breathe“), předtím než volá svojí mámu a následně je udušen k smrti. Tam žádné „praní“ neprobíhá, a předtím s nimi spolupracoval. Policajt co ho zabil tam přijel až po jeho zatčení, až když je dávno po všem a jediné o co šlo je ho naložit do auta. A z těch videí je docela jasně vidět, že nekladl žádný odpor, ale zakopl (podruhé, poprvé asi deset minut předtím), když ho vedli do auta z obrubníku do silnice.

Jako kdyby se to stalo třeba při zatýkání, nebo kladení odporu, tak prosím, asi by tam byl nějaký prostor pro spekulace. Tohle je natočené z asi pěti různých uhlů několika lidmi a minimálně dvěma bezpečnostními kamerami, když vynechám policejní kamery co nosí na rameni. Každý kdo má deset minut času se může sám podívat jak to bylo a že policii tou dobou nehrozilo naprosto žádné nebezpečí a doslova tam klečí na neozbrojeném, odpor nekladoucím občanovi, zatímco ignorují slušné prosby ať ho nedusí, a zároveň zděšené varování okolostojících, že ho očividně dusí k smrti.

Tady je to vidět jasně: https://www.youtube.com/watch?v=fGVjnhm51Rg&bpctr=1591221007

A tady máš deset dalších uhlů a videí: Udělejte si obrázek sami: Takhle probíhal policejní zákrok na černocha Floyda.

[Aleš Kapica]

K tragédii se v Minneapolisu začalo schylovat v pondělí 25. května minutu po 20. hodině místního času během telefonátu prodavače z večerky na tísňovou linku 911. Náctiletý mladík za kasou policisty informoval o tom, že Floyd mínil zaplatit cigarety dvacetidolarovou bankovkou, která je zřejmě padělaná, a zboží odmítá vrátit. Hlásil také to, že muž je opilý.

Z přepisu záznamu telefonátu na policii, který na svém webu zveřejnila mimo jiné místní televize Fox 9, vyplývá, že mladík policisty dále informoval, že „po muži chtěl cigarety zpátky, ten to ale odmítl, zdá se být hrozně opilý, mimo sebe a nechová se slušně“.

Děkuji. Obrázek jsem si udělal.

Vy naprosto opomíjíte fakt, že chybí záznam, na kterém by bylo vidět za jakých okolností se dostal mimo to auto a co se při tom sběhlo.

[prqek]

Ty zase máš jasno v tom, co se dělo, že jo? To, že policie někoho usmrtí, by v civilizovaná společnosti měla být vyjímečná záležitost. Z tvých argumentů mám pocit, že by ti nevadilo, kdyby to bylo při kdejakém zatýkání. Nebo se pletu?

[kralyk z abclinuxu]

Z tvých argumentů mám pocit, že by ti nevadilo, kdyby to bylo při kdejakém zatýkání. Nebo se pletu?

Těžko říct, ještě před nějakou dobou se p. Kapica rozčiloval nad šikanou ze strany PČR, jak se chová strašně brutálně že nutí nosit lidi roušky v lese.

[Aleš Kapica]

Vůbec mě nepřekvapuje, že vy ten diametrální rozdíl nevnímáte.

Člověk bez roušky na volném prostranství žádný zákon neporušuje – porušuje pouze nelogické a nesmyslné vládní nařízení.

I kdyby se při tom na hlavu stavěl, je to každému jedno a nepředstavuje žádné ohrožení. Pouze vaše chorá mysl, vybičovaná nesmysly které se na ni valí ze všech stran, v něm vidí zdroj nákazy – bez ohledu na fakt, že je ten člověk zcela zdráv.

A vy takového člověka dáváte do stejné roviny s osobou, která se pod vlivem neznámé látky chovala nevypočitatelně, odmítla nejenom zaplatit jinou bankovkou, ale i vrátit zboží. Zcela evidentně odmítla následovat pokyny policistů a evidentně byla i agresivní – i z těch záběrů, které k dispozici jsou je zřejmé že rozhodně nebyl jklidný jak habešánek, když skončil na zemi zakleknutý třemi policajty.

Styďte se! Ale hlavně si na to vzpomeňte, až podobná existence jednou bude někde na ulici ohrožovat vás!

[trekker.dk]

Člověk bez roušky na volném prostranství žádný zákon neporušuje

To sotva. Jestli existuje zákon, který vládě umožňuje takové nařízení vydat, téměř určitě v něm bude stanovena povinnost se tím nařízením řídit.

porušuje pouze nelogické a nesmyslné vládní nařízení.

To je pouze váš nesmyslný názor.

bez ohledu na fakt, že je ten člověk zcela zdráv

Ano, vy máte křišťálovou kouli a přesvědčení. My ostatní do budoucnosti nevidíme, takže to, že je ten člověk teď, když se s ním potkávají jiní, zcela zdráv, holt můžeme poznat až za několik dní poté.

Ale hlavně si na to vzpomeňte, až podobná existence jednou bude někde na ulici ohrožovat vás

Možná vám to z nějakého důvodu nedochází, ale mezi "nedělat nic" a "pomalu a brutálně zabít člověka" je docela velký počet akceptovatelných možností. Například použití donucovacích prostředků v přiměřené míře, dokud podezřelý klade odpor.

[kralyk z abclinuxu]

bez ohledu na fakt, že je ten člověk zcela zdráv

Jo jo, takových už bylo, co byli "zcela zdrávi", u kterých se pak po tejdnu ukázalo, že už 14 dní v sobě nosí virus... Ale to tobě zřejmě nemá smysl vysvětlovat, ten koncept inkubační doby jsi zřejmě nepochopil ani napoprvé, ani po n-té...

A vy takového člověka dáváte do stejné roviny s osobou, která se pod vlivem neznámé látky chovala nevypočitatelně, odmítla nejenom zaplatit jinou bankovkou, ale i vrátit zboží.

Nic takového můj komentář neobsahuje.

Já jen považuju za morbidně zábavný tvůj přístup, kdy když se jedná o tebe v naší zemi, tak i žádost policie nosit roušku považuješ za šikanu, zatímco když se jedná o nějakého černocha na jiným kontinentě, tak mu můžou klidně šlápnout na krk.

Ale hlavně si na to vzpomeňte, až podobná existence jednou bude někde na ulici ohrožovat vás!

Podobný existence mě už ohrožovaly. Samozřejmě chci, aby v takovým případě policie zakročila, ale rozhodně nechci, aby tomu člověku na místě klekli na krk a zabili ho. Nejsem psychopat. Stydět by ses měl především ty, jestliže takovej postup schvaluješ.

[Darth Phantom]

Zdar. Jsem se chtěl zeptat, zdali jsi již dočista nezpičovatěl pilnou četbou a2alarmu a dalších komunistických kolibáčovin. Když se tak jen mimochodem dívam na tu patičku

[kralyk z abclinuxu]

Koukám, že své oblibené činosti "vymyslim si, co krályk čte, a pak mu to zkritizuju" ses stále nevzdal. Nejdřív čtu Respekt, pak čtu Reflex, teď čtu A2larm... Zajímalo by mě, co budu číst příště, asi Annu proletářku

Asi sis toho nevšim, ale patička neodkazuje A2larm, nýbrž wikipedii.

Kdybych jednoho krásnýho dne měl takovýho volnýho času, že bych mohl číst aspoň polovinu toho, co podle tebe čtu, to by byla paráda...

[Bherzet]

Ten článek v patičce je tendenční. Napřed tvrdí:

Líčí, jak jeho předci vypalovali husté křoviny v okolí každé farmy, aby tak vytvořili pás území, který případné plameny zastaví.

A vzápětí za husté křoviny patrně považuje vzrostlé stromy:

V současné době je takové vypalování křovin nemyslitelné. Deník The Sydney Morning Herald informoval o případu 71letého důchodce Johna Davida Chia, který nechal ze svého území odstranit 74­ vzrostlých stromů. Ekologičtí aktivisté se zděsili a celá věc putovala k soudu. Ten sice uznal Chiův argument, že měl obavy z požáru, a proto chtěl území vyčistit, přesto mu uložil vysoký peněžitý trest. V rozsudku konstatoval, že došlo k velké újmě na životním prostředí.

Prostě prémiové informace.

[Radovan]

Jak to znělo v originálu? Nešlo náhodou o "thick bush"?

[kralyk z abclinuxu]

Ono je to úplně jedno, protože problém je už v tom, že to tvrzení, že se málo pálilo (ať už thick bush nebo něco jinýho), je vycucaný z prstu. Pálilo se minimálně stejně jako v minulosti, případně víc. Ale prostě někdo to zřejmě potřeboval na někoho hodit a 'ekoteroristi' byli po ruce.

[Blaazen]

Mně to z těch videí úplně jasné nepřijde. Navíc práce policisty je relativně riziková. Spíš mě zajímají ty dvě pitvy s opačným výsledkem. Někdo lže...

[Radovan]

A co když lžou obě? Jediný jistý fakt je, že policie v USA někoho zavraždí každou chvíli, a stává se že když polda zastaví auto a uvidí za okénkem "černou hubu", tak začne střílet rovnou. Nedávno proběhla kampaň se samolepkami na auta, kde řidiči prosili policisty aby je nezabíjeli.

Ano, práce policisty je riziková. Ale když ve statistikách uvidím za rok jednoho policajta zabitého zločincem, a tisíc policajty postřílených civilů, z nichž většina nespáchala žádný zločin a polovina šla prostě okolo, zrovna když si tihle psychopati hráli na kovboje, tak mě napadne že tam je něco sakra špatně!

Takže napětí, způsobené policejní brutalitou a beztrestností jejích pachatelů, rostoucí celé dlouhé roky, teď prostě překročilo mez a explodovalo. V tuhle chvíli už počet zraněných policistů a dalších "pomahačů režimu" jde do stovek, z toho postřelených jsou minimálně desítky. Občanská válka to není, ale pouliční určitě.

Mezitím v bohatých čtvrtích vznikají silně vyzbrojené domobrany, a jestli se zapojí i ty, už by se to za občanskou válku do jisté míry považovat dalo. Zatím je to jenom mírná forma povstání spodiny. Plus rabování obchodů - symbolu bohatství vyšších vrstev a napadání kanceláří CNN - symbolu provládních lží.

[xxx]

CNN - symbolu provládních lží

Videl si vubec behem posledniho tydne alespon jednou titulku CNN?

[Fluttershy, yay!]

Plete si Faux News (natož OAN) a CNN. To druhé je „pouze“ korporátní establishment.

[xxx]

Neplets si nahodou zatykani s BDSM? Tam safeword skutecne je.

Myslet si, ze se policajti vzdaj prevahy nad 120kg chlapem jen proto, ze se zatykany konecne zklidnil, je fakt naivni. Tezko poznaj jestli si dal pauzu, neb uz to mysli vazne. Stejne tak myslet si, ze je dojme "I can't breath". To zrejme tvrdi kazdej zakleknutej. Ostatne zakleknuti je bezny postup i u nas. Docela mne prekvapilo, ze vcetne chokehold, ktery nekde v USA uz nesmi pouzivat (jen narizeni, ne zakon), je u nas legalni. Co se tyka zaznamu, tak fakt nevim jestli se branil, nebo jestli ho chlapci jen nebyli schopni vyndat/nandat z/do auta. Zarazejici je, ze je ani nerozhodi pritomnost tech okolostojicich. Skoro bych rekl, ze jedou podle nejakych guidelines.

No holt se tam budu s 1000 mrtvymy v dusledku zatykani nad tim trochu zamyslet. Proces jeste bude zajimavy. Z 3rd degree murder udelali 2nd degree murder. Tedy z neceho co odpovidalo spis nedbalostnimu TC udelali umyslny TC. Tak bude zajimavy jak mu umysl dokazou. Uz ted jsou stiznosti, ze casto to k odsouzeni ani nedojde.

Holt maji v USA asi ponekdu tvrdsi pristup. Jsem sice rad, ze ho tady nemame. Na druhou stranu to ale znemena, ze kdyz ti udelaj ve vesnici technoparty, tak si muzes tak akorat uzivat duneni, protoze proti technarum uz dneska nikdo silou nezasahne. Nakonec mozna v USA dosahnou te vytouzene spravedlnosti, ze afroamericana nikdo nesebere. BTW od demokratu z NYC uz zaznelo, ze chteji aby bezduvodne volani 911 kvuli afroamericanum byl hatecrime.

[JiK]

tak soudruzi v minneapolisu uz se rozhodli zrusit celou policii

Dal jsem popkorn do mikrovlnky a tesim na pozorovani dalsiho levelu budovani "lepsich zirku uz dnes" z rukou socialistickeho starosty a guvernera.

[Fluttershy, yay!]

Yeah, good. Okay.

[kralyk z abclinuxu]

tak soudruzi v minneapolisu uz se rozhodli zrusit celou policii

Dal jsem popkorn do mikrovlnky a tesim na pozorovani dalsiho levelu budovani "lepsich zirku uz dnes" z rukou socialistickeho starosty a guvernera.

To já taky. Jsem zvědav, jak to tam dopadne. Může to být dobrý i špatný. Ale moc nadějí tomu nedávám, přecijen, řeč je o USA, kde (aspoň mi to tak přiadá) jsou švihlí skoro všichni nalevo, napravo, všude...

[Fluttershy, yay!]

Klídek. Nebylo by od věci poslechnout/přečíst si, co říká např. ten Alex Vitale. To je vcelku selský rozum (při pohledu z Evropy).

Když jediné, co máš, je kladivo, všechno vypadá jako hřebík.

Místo zdravotnického, sociálního,… personálu dostaneš pendrek a lidi postižené závislostí, bezdomovectvím,… prostě vytlučeš dopryč. (To je ještě ten mírnější případ, pak šílenosti typu „killology“).

Takže co třeba to dělat jináč…?

[bigBRAMBOR]

Pri nic za nic asi toho "něžného obra" nezakleknul. Podle toho co jsem četl spolu kdysi pracovali v nějaké bezpečnostní agentuře, takže ho nejspíš dost dobře znal na to, aby mu z toho krku neslezl. Ten černoch nebyl žádné neviňátko

tak zatim co majitelka te agentury si neni jista jestli se nekdy v agenture potkali, ty vis ze ho nejspis znal dost dobre na to aby mu z krku neslezl, zajímavé.

Kdyby se skutečně snažil sekat po návratu z basy dobrotu, tak by nedopadl jak dopadl.

Aneb, to je bratr toho zavraždeného, to bude asi taky pěknej lump

[Aleš Kapica]

Co tady meleš o bratrovi?! Nějakým způsobem se na tom místě ocitnul. A pro nic za nic na něj ti policajti asi taky neskočili.

[bigBRAMBOR]

o bratrovi? skoda, neznas ceske narodni poklady, ale to se neda nic delat. Kecas blboste, kdo se octnul na nejakem mi ste se tam neoctnul nahodou a proto se nemuze divit co se mu stalo. To jsou kecy, fakt jsem prekvapenej tohle slyset od dospeleho cloveka. Ta holka si taky za znasilneni muze sama, podivejte se jak se obleka

[Aleš Kapica]

Jestli někdo kecá blbosti, tak seš to ty. Zamysli se laskavě nad příkladem co jsi uvedl.

Srovnávat oběť znásilnění s polapeným pachatelem trestného činu může jen úchyl, který ztratil pojem o tom za jakých okolností se ztrácí nárok na slušné zacházení. - Ne. Není to na základě barvy kůže, jak se černoušci snaží podsunout. Je to za předpokladu, že uděláš něco protizákonného. V tom je ten rozdíl mezi situací v níž se ocitá oběť znásilnění, a situaci v níž se ocitá přistižený pachatel trestného činu!

[prqek]

Ten rozdíl je zhruba srovnatelný s rozdílem mezi přiměřeným spacifikováním toho pachatele a jeho zabitím.

[Aleš Kapica]

To snad nemyslíš vážně?! Ty srovnáváš úmyslný trestný čin s nešťastnou náhodou?!

Podle dostupných informací ten zesnulý Floyd nebyl ve stavu kdy byl zcela nevypočitatelný! Zrovna v pondělí jsem jel z Karláku metrem na Zličín a v něm seděl podobný týpek. Nevím jestli byl opilý, pod vlivem drog, nebo magor, ale každý se raději klidil z cesty. Seděl jsem, vyhýbal se přímému očnímu kontaktu, protože to bývá u podobných jedinců nejčastěji příčinou výbuchu agresivity a celou cestu byl ve střehu. Dotyčný si něco mumlal, semtam se pokoušel navazovat hovor s těmi co si ho při nástupu nevšimli a nestihli prchnout. A občas si "jen tak" bouchnul, tak že bylo ihned jasné, že by to s jeho pacifikací nebylo tak snadné. Vše se obešlo bez incidentu a na Zličíně ho zřejmě vybrali – nezajímal jsem se o jeho další osud. Spěchal jsem na bus. Ale přísahám, že pokud by se o něco pokusil, tak by nejspíš dopadnul jak ten Floyd.

[prqek]

Asi jsem nešikovně vyjádřil. Tvrdím, že podobně jako je blbost tvrdit, že žena může za to, že byla znásilněna, protože byla vyzývavě oblečená, je velmi podobná blbost tvrdit, že ten člověk může za to, že byl zabit, protože je podezřelý ze spáchání trestného činu (tedy ne obecně, u některých činů by blbost nebyla, ale někdo tu zmínil, že šlo o falešné bankovky, tam to blbost je). Nesrovnávám činy jako takové, ale nesmyslnost těch zdůvodnění. Ta je zhruba srovnatelná.

[Aleš Kapica]

To moje zdůvodnění rozhodně nesmyslné není.

Pokud dělám věci, které jsou v rozporu se zákonem, musím počítat s následky, které mohou být i tragické. To platilo vždy!

Nemohu v žádném případě souhlasit s honem na toho policistu, jelikož je rozdíl mezi útokem sprostého vraha kterého k útoku na oběť nikdo nenutí a útokem policisty, který je nucen do konfliktu jít ať chce nebo nechce, protože je to jeho povinnost.

Stalo se, ale mohl si za to sám Floyd. Bohužel. Jenže o to v současné době jak se zdá vůbec nejde. Tahle nešťastná událost byla jen dlouho očekávanou záminkou pro další vlnu násilí ze strany frustrované černošské menšiny na které se hodlají svézt do Bílého domu demokraté, co nebyli schopni Trumpa porazit ve volbách.

[prqek]

Když se žena oblékne vyzývavě, tak musí počítat s tím, že vzbudí pozornost mužů. Ovšem znásilnění je zcela nepřiměřená a nepatřičná pozornost. Když někdo páchá trestnou činnost, musí počítat s následky. O tom není sporu. Ovšem zabití jako následek placení falešnými bankovkami (pokud to tak bylo), je také zcela nepatřičné a napřiměřené. Pokud mu na tom krku klečel několik minut a měl kolem sebe několik dalších kolegů, tak to těžko lze považovat za nehodu.

To, že současná situace je důsledkem dlouhodbého napětí, je zřejmé. Ovšem přístup typu, že si za to může sám, protože je to krimináník, to napětí moc nesníží.

[Bherzet]

+1

[trekker.dk]

s polapeným pachatelem trestného činu

Pachatelem trestného činu je člověk, který byl za ten trestný čin pravomocně odsouzen. Do té doby je to podezřelý.

[Aleš Kapica]

Pachatel je ten kdo něco páchá (přítomný čas). Ten kdo něco spáchal (čas minulý) a byl za to odsouzen (také čas minulý), je odsouzený. Podezřelý (přítomný čas) je ten, kdo vypadá že nic nespáchal (čas minulý) či nepáše (čas přítomný), ale existují určité indicie že spáchat mohl, nebo by mohl.

Takže Floyd sice byl podezřelý, který by mohl po uvolnění ze zakleknutí policisty napadnout, ale zároveň byl i pachatelem, který spáchal přestupek a zcela evidentně se choval nestandartně, takže ho policisté museli zakleknout.

Podle toho co zachytila kamera předtím, tak to vůbec nevypadalo, že se situace později vyhrotí. Zcela chybí situace jak se Floyd dostal do toho policejního vozu, ze kterého se pak pokoušel uniknout. A pak následoval asi 5 minutový interval, během kterého nikdo žádné video, které by situaci objasnilo, netočil. Ale tipnul bych, že se Floyd opět pokusil utéct, takže jim nezbylo nic jiného než aby ho zaklekli. Podle všeho byl sjetý a v důsledku toho taky zkolaboval. Což ostatně potrdila i pitva.

Floyd asi nebyl zrovna vzorný otec, a docela by mě zajímalo, kdo objednal a zaplatil tu soukromou pitvu když měl zesnulý potřebu platit za cigára falešnou dvacetidolarovkou a informací. Jeho bývalá žena s dětmi které horaného dětství neviděly to asi nebyla. A ta současná na to taky nevypadá. Takže to vypadá na zcela účelový kalkul s cílem získat do ruky papír, kterým půjde ještě více rozvášnit davy.

[trekker.dk]

Pachatel je ten kdo něco páchá (přítomný čas)

Ale pachatel trestného činu, což jste napsal, je pouze člověk odsouzený za trestný čin, protože o tom, jestli je nějaký čin trestným činem, rozhoduje soud. Ne policajt.

Ale tipnul bych, že se Floyd opět pokusil utéct, takže jim nezbylo nic jiného než aby ho zaklekli.

Ano, policie má právo použít donucovacích prostředků, ale pouze v míře nezbytně nutné, to nejspíš platí tady i tam. A u takového úmrtí určitě věci neproběhly tak, že člověk se vzpíral a najednou byl mrtvej. O co, že tam byla fáze, kdy přestal komunikovat a ztratil vědomí, což je okamžik, ve kterém použití donucovacích prostředků nutné není. A pak se ukáže, jestli se jedná o profesionální policisty, nebo o násilnické darebáky, kteří by bez uniformy pravděpodobně skončili dřív či později za mřížemi sami.

Pokračovat v používání donucovacích prostředků za situace, kdy podezřelý ztratil vědomí, je jednoznačně pochybení na straně zasahujících policistů a měly by z toho být vyvozeny důsledky. A protože pravidelně nejsou (tam i tady), tak tam situace opakovaně přeroste v protesty a násilnosti.

Což samozřejmě vy nejste schopen pochopit, protože dokud něco takového nepostihne vás, tak je to v pořádku. Zcela v souladu s definicí psychopata.

[Aleš Kapica]

Pochybuji, že policajt, který je ve stresu zvládá kontrolovat životní funkce přišlápnutého typa, který se mu pokoušel pláchnout.

Jak už jsem vám několikrát opakoval – jsem realista, a proto mne něco podobného s největší pravděpodobností nepostihne.

A to že zrovna vy sympatizujete s darebáky mě taky nepřekvapuje.

[trekker.dk]

jsem realista, a proto mne něco podobného s největší pravděpodobností nepostihne.

Tak jistě, životní postoje rozhodně mají vliv na to, jestli se někdy dostanete do konfliktu s policií. Třeba až budete svým typickým pseudologicky-hulvátským způsobem nějakému vysvětlovat, že nemusíte nosit roušku.

A to že zrovna vy sympatizujete s darebáky mě taky nepřekvapuje

U vás není překvapením, že se argumentaci snažíte strhnout do roviny "sympatizování s darebáky". A to pořád platí, že o případu víte prd a nemůžete vědět ani to, jestli dotyčný byl darebákem (a platil falešnou bankovkou úmyslně) nebo obětí (a platil falešnou bankovkou, kterou předtím dal někdo jemu.)

Nicméně ne, nejde o sympatizování s darebáky, jde jenom o to, že v případě, že bych se buď někdy do nějakého konfliktu s policií dostal, nebo potřeboval jejich pomoc - a ono prostě někdy stačí být na špatném místě ve špatnou dobu, což je něco, co vy si zásadně nepřipouštíte - tak chci, aby v té uniformě byl profesionál a ne nějaká vypatlaná sadistická mlátička.

[Aleš Kapica]

O mne si nemusíte dělat starost. Do konfliktu s policií jsem se nikdy nedostal a z jiných konfliktů vybruslil aniž bych skončil s monoklem na oku, či zlomenými žebry. Takže ten můj přístup bude nejspíš jiný, než vám generuje vaše chorá hlava na základě selektivního čtení.

O případu máme dost informací na to, abych si troufnul prohlásit, že si mohl dotyčný sám za to, že skončil jak skončil. A rozhodně nebyl čistý jak lilium, poněvadž kdyby byl, tak by touhle dobou žil a na tomhle serveru by po něm neštěkl pes.

[Radovan]

Jak do toho zapadá střelba policistů na reportéry?

[trekker.dk]

O mne si nemusíte dělat starost. Do konfliktu s policií jsem se nikdy nedostal a z jiných konfliktů vybruslil aniž bych skončil s monoklem na oku, či zlomenými žebry.

A z toho má vyplývat, že tomu tak bude i dál?

O případu máme dost informací na to, abych si troufnul prohlásit, že si mohl dotyčný sám za to, že skončil jak skončil.

Jo, třeba to, že člověk, který ho zabil, je teď bývalý policista. Ale chápu, že postup toho člověka, který někomu pro jistotu klečel na krku ještě přes půl minuty po tom, co ho zabil, vám vyhovuje. Povahou si pravděpodobně budete dost podobní.

rozhodně nebyl čistý jak lilium, poněvadž kdyby byl, tak by touhle dobou žil

A hele, argumentace kruhem, tuhle formu logického klamu jste tu už dlouho nepředvedl.

[⧠ A = 0]

Podezřelý

Tohle slovo je důkazem, že právníci/policajti neumějí česky, a že lecjaká blbost se uchytí, když ji budete opakovat dost dlouho. (Správně by mělo být podezřený.)

[Bherzet]

Ovdovělý, osiřelý, …?

Spíš bych pocitově řekl, že být podezřený je vlastnost podezřelého.

[Bherzet]

Ah, už asi chápu co myslíš. Asi by mohla být lehká nuance mezi podezřele se chovající osobou a osobou podezřenou z trestného činu (která podezřelá být vůbec nemusí).

[podlesh]

No, kameny bych moc neházel. V IT máme podobné "blbosti", například v programovacích jazycích se používá termín "ukazatel" místo správného "ukazovatel"!

[Bherzet]

Ukazatel je normální slovo, se kterým se můžeš setkat i fyzicky (turistický ukazatel).

[podlesh]

Jo, i ten by měl být ukazovatel, protože ukazuje pořád, nedokonavě.

[xkucf03]

A skutečně ukazuje pořád? Co takový nullptr, co NullPointerException nebo dangling pointer?

[kralyk z abclinuxu]

To záleží na tom, jestli se jedná o jazyk s miliardovou chybou, nebo o slušně navržený jazyk

_^</bait>

[xkucf03]

Mluvit o „miliardové chybě“ je sice populární, ale z vlastní zkušenosti můžu říct, že tyhle chyby představují jen naprostý zlomek problémů, které se při vývoji softwaru řeší. Dokonce ani junioři s tím nemívají moc problémy a čas tráví úplně jinými chybami než debugováním NullPointerů nebo podobnými věcmi.

Možná je to trochu zkreslené tím, že dělám v Javě, která sice NullPointerException má, ale jinak je to poměrně bezpečný jazyk. Nicméně mi nepřijde, že by to v Céčku nebo C++ bylo výrazně horší.

[kralyk z abclinuxu]

Možná je to trochu zkreslené tím, že dělám v Javě, která sice NullPointerException má, ale jinak je to poměrně bezpečný jazyk.

Nejsem natolik javista, abych mohl říct, jak moc to je/není problém v rámci ekosystému. Určitě jsem se s tim nejednou setkal. Minimálně mi to ale přijde jako naprosto zbytečná komplikace. Mít by-default nullovatelné reference má pouze nevýhody a žádné výhody. Když chce někdo někde mít možnost stavu "absence hodnoty", tak od toho jsou přece optional typy. V C/C++ nullable pointers ještě víceméně dávají smysl, protože to jsou nízkoúrovňový jazyky (minimálně v některých kontextech a pokud člověk nechce dělat to co Rust, tak moc nezbude nic jinýho), ale co to dělá ve vysokoúrovňovém staticky a silně typovaném jazyce, jako je Java, to nechápu. A přitom není nutný to řešit rovnou třeba borrow checkerem, jako má Rust, IMO by celkem stačil přístup jako má třeba Kotlin nebo TypeScript, kde prostě by default ta reference null být nemůže, protože to je to, co člověk ve většině případů chce...

Nicméně mi nepřijde, že by to v Céčku nebo C++ bylo výrazně horší.

V C/C++ je to IMO problém zcela jednoznačně, a to jak z osobní zkušenosti, tak se dá vykoukat i něco třeba ze statistik CVE apod... Koneckonců vzpomeň na segfault, co jsi před časem řešil, to byla taky dangling reference...

[Bherzet]

Mně se líbí, jak to má C#. Foo nullovatelné není, Foo? ano. U nullable typů tě kompilátor nutí ten null ošetřit.

Ještě elegantnější by možná bylo nemít null vůbec a místo něj definovat pro každý typ prázdnou instanci. Ale ono to vypadá hezky u kolekcí, kde to jde zrovna přirozeně, ale už ne tak u čehokoliv jiného, kde by to v praxi skončilo vyhazováním UnsupportedOperationException a padáním za běhu stejně jako v případě NPE.

[kralyk z abclinuxu]

Mně se líbí, jak to má C#. Foo nullovatelné není, Foo? ano. U nullable typů tě kompilátor nutí ten null ošetřit.

Takhle to mají Kotlin a TypeScript (ačkoli ten má trochu divnou syntaxi).

U toho C# tomu úplně nerozumim, tam se to asi nějak měnilo s novými verzemi? Na wikipedii píšou:

Most object access is done through safe object references, which always either point to a "live" object or have the well-defined null value

A mimichodem, mají tam i ten boxing, jak jsme se o tom dohadovali v minulý diskusi

Boxing is the operation of converting a value-type object into a value of a corresponding reference type.

[Bherzet]

Já C# moc neumím, dělal jsem v něm naposledy před několika lety a jen krátce. Ale co jsem teď vydestiloval z rychlého googlení, tak:

• ve starších verzích C# (před verzí 8) platilo to, co jsem psal, pouze u hodnotových typů (např. int), ostatní reference jsou nulovatelné defaultně (a tedy nedává smysl psát T?, protože už T je nulovatelný, pokud to není hodnotový typ)
• od 8. verze jsou reference defaultně nenulovatelné a to, co jsem psal, platí obecně

Viz demo. Ideone používá Mono (gmcs 5.20.1), ale nějak se mi nedaří vygooglit, jakou verzi jazyka tahle verze podporuje. Každopádně to ještě nebude C# 8, protože Test? tam nefunguje a píše to:

prog.cs(25,3): error CS0453: The type `Test' must be a non-nullable value type in order to use it as type parameter `T' in the generic type or method `System.Nullable<T>'
Compilation failed: 1 error(s), 0 warnings

Co znamená ten citovaný výrok z Wikipedie netuším.

[Bherzet]

Boxing is the operation of converting a value-type object into a value of a corresponding reference type.

Co znamená ten citovaný výrok z Wikipedie netuším.

Heh, při zpětném pohledu nějak nevím, co mi na tom tvrzení nebylo jasné. Přesně takhle je to i v té Javě: hodnotový typ (např. int) se boxuje do referenčního typu (např. Integer).

Čtu teď předchozí diskuzi a asi už chápu, kde vzniklo nedorozumění. Pokud Rust má jiné hodnotové typy, které nutně nejsou primitivy, ale stejně to nejsou referenční typy (např. struktura složená z primitiv, která může mít libovolnou velikost), tak je nutné buď to boxovat, aby to šlo napasovat do univerzálně zkompilovaného nativního kódu, a nebo to kompilovat pro každou kombinaci typů znovu. A nebo to možná vyřešit ještě nějak jinak.

Mně zmátlo, že když jsi psal:

Generika v Rustu nefungují jako v Javě, ten overhead boxingu generických věcí by byl nepřijatelný.

Tak jsem to pochopil tak, že v Javě mají generika nějakou zásadní spojitost s boxováním. Mají jen u primitivních typů. Všechny ostatní typy jsou referenční, takže se boxování řešit nemusí. Pokud v Rustu ty referenční typy nejsou tak časté, nebo whatever, a muselo by se boxovat častěji, tak ten overhead by mohl být nepřijatelný. Chápu a souhlasím.

[Bherzet]

*mě

[kralyk z abclinuxu]

Yup, a v C++ je to taky tak...

[prqek]

Ještě elegantnější by možná bylo nemít null vůbec a místo něj definovat pro každý typ prázdnou instanci.

Tak by potom místo NullPointerException byla EmptyInstanceException. Když data nejsou k dispozici ve chvíli, kdy jsou potřeba, tak je to spíš problém algoritmu a ne jazyka. Nebo mi něco uniká a moje představivost je příliš omezená tím, že píšu hlavně v C? Koneckonců v tom C nevidím ani tak problém v tom, že ten pointer může být null (to se celkem dobře detekuje), ale že může mít jakoukoli hodnotu, to pak začíná legrace.

[Josef Kufner]

Nebo mi něco uniká a moje představivost je příliš omezená tím, že píšu hlavně v C?

Ano. Pokud máš funkci f(Foo x), tak x nikdy nebude ani prázdné, ani null, protože při volání funkce překladač vynutí, aby tam bylo Foo. Prostě nepůjde napsat f() ani f(null).

Pokud budeš mít funkci g(Foo? x), tak půjde napsat g(new F()), nebo g(null), ale nepůjde g(). Pokud budeš mít g(Foo? x = null), tak projde i g().

Pak je ještě takový hezký případ g(Foo x = null), kdy neprojde g(null), ale projde g(). Tedy pokud parametr je uveden, tak nemůže být null, v těle funkce se to chová stejně jako g(Foo? x = null).

Konkrétní možnosti, syntaxe a detaily se mezi různými jazyky mírně liší, ale co jsem poslední dobou potkal, tak to všude funguje dosti podobně.

[xkucf03]

Tak by potom místo NullPointerException byla EmptyInstanceException. Když data nejsou k dispozici ve chvíli, kdy jsou potřeba, tak je to spíš problém algoritmu a ne jazyka.

Měl by existovat kontrakt, který říká, jaké jsou vstupní předpoklady, co se čeká od výstupu a jak by to mělo fungovat uvnitř. Část toho kontraktu se vyjádří pomocí signatury metod – a zbytek je potřeba napsat do komentářů nebo specifikace. Součást toho kontraktu je i to, které parametry (nebo na druhé straně části výstupu) jsou povinné a které nepovinné. A je hezké mít na úrovni jazyka prostředky pro vyjádření, co je povinné a co ne. (např. v relačních databázích máme NOT NULL, cizí klíče a další integritní omezení)

Ty chyby jsou pak souhrou dvou okolností – v jazyce ty prostředky chybí, takže není možná strojová kontrola, a zároveň programátor nedodržel kontrakt. Tzn. považoval za povinné něco, co dle zadání může chybět, nebo naopak nenaplnil něco, co dle zadání mělo být přítomno vždy a ostatní s tím počítali.

[prqek]

Chápu, že to donutí programátora psát hezčí kód. Ten přístup C# nebo sql se mi celkem líbí. Java to taky má clekem pěkně - když ten pointer není null, tak se dá spoléhat na to, že ukazuje na něco platného. V C to neplatí, ale beru to jako daň za jeho nízkoúrovňovost. U C++ mi to přijde takové překombinované (ale to víceméně celý jazyk).

Šlo mi o to

... nemít null vůbec a místo něj definovat pro každý typ prázdnou instanci.

Přijde mi, že tohle nic nevyřeší, jen přejmenuje. Když data nejsou k dispozici, a přitom jsou potřeba sebelepší jazyk nebo pojmenování to nezachrání.

[Bherzet]

U těch kolekcí to smysl dává a dokonce přesně z tohoto důvodu v Javě existují věci jako Collections.emptyList() a podobné. Existují operace, které jsou zcela legitimní i nad prázdnou kolekcí (součet prvků, …). Existují operace, které nikoliv: například (občas odůvodněné) prasárničky ve stylu map.get(MAGIC_KEY).call(). Ale i v tomto případě ta garance validní, seč prázdné, mapy ušetří pečlivému programátorovi jednu podmínku (nemusí ověřovat, že mapa není nulová a obsahuje MAGIC_KEY, nýbrž právě a jen, že obsahuje MAGIC_KEY).

Já bych s Frantou úplně nesouhlasil, že ten null (resp. typový systém, který ho nebere v potaz) nepředstavuje vcelku podstatný problém. Ono ani tak nejde o ty chyby jako spíš o to, že to zdržuje, vede na zbytečné duplicitní kontroly atd. A pokud se člověk rozhodne odstranit zbytečnou komplexitu a psát minimalistický kód, ve kterém je opravdu jen to nezbytné, tak si kope lvovou jámu, do které dříve nebo později on nebo někdo jiný spadne (až si zapomene přečíst dokumentaci a ten null někam omylem pošle).

[prqek]

Tohle chápu, teda aspoň myslím, že chápu :) Jen mi přijde, že zavedení EmptyInstance to neřeší, protože podobně jako nějaké operace nelze provést nad null, tak budou určitě operace, které nelze provéšt nad EmptyInstance. Null je jen jedna z nevalidních hodnot, které se dají někam omylem poslat. Nicméně je pravda, že když jazyk umožňuje nějak omezit použití null, tak to může mnoha problémům zabránit.

[Bherzet]

No, jak jsem psal v předchozím komentáři:

Ale ono to vypadá hezky u kolekcí, kde to jde zrovna přirozeně, ale už ne tak u čehokoliv jiného, kde by to v praxi skončilo vyhazováním UnsupportedOperationException a padáním za běhu stejně jako v případě NPE.

Přes ty kolekce se velmi často nějak iteruje a nevadí, pokud jsou prázdné. Co by teda mohlo vadit je, že v Javě se ve standardní knihovně nerozlišují mutable a immutable typy těch kolekcí. Pokud do metody, která do té kolekce něco přidává, pošleš Collections.emptyList(), spadne to za běhu. Musel by existovat ImmutableList, který by byl subsetem Listu, a který by používal všude, kde se pouze čte. V prvním případě by se jako výchozí typ mohla recyklovat pořád stejná neměnná prázdná instance, ve druhém případě by se vytvořila pokaždé nová.

Ale určitě to neřeší všechny případy, jak jsem psal už výše.

[JS1]

co to dělá ve vysokoúrovňovém staticky a silně typovaném jazyce, jako je Java, to nechápu

Ja to chapu, Java je proste stary jazyk. Coz by nevadilo, ani by mi nevadilo, ze v ni momentalne musim psat, co mi vadi asi nejvic je to, ze se kolem me ruzni lide tvari, jako ze to je vrchol pokroku.

[xkucf03]

Nevím jestli myslíš mne, neberu si to nijak osobně, ale odpovím. Nikdy jsem tu nepsal, že by Java byla dokonalá. Ostatně ani dokonalý jazyk neexistuje. Ale celkem často tu píšu, že Java je pro určité použití nejlepší volba. A za tím si stojím. Ono totiž nezáleží jen na samotných vlastnostech jazyka, nejde jen o kód – do té pomyslné rovnice, na základě které se rozhoduje, vstupuje mnohem víc proměnných.

Nejlepší volba != dokonalost nebo vrchol pokroku.

A taky jak jsem psal nedávno v blogu:

Řada problémů a selhání v IT nemá technické nýbrž společenské příčiny

Přijde mi, že řada lidí optimalizuje na nesprávném místě. Ono je sice celkem přirozené, že se programátoři hádají o programovacích jazycích, knihovnách, frameworcích… ale často by více pomohlo ten čas trávit jinak a optimalizovat jiné části vývojového procesu, komunikaci mezi lidmi nebo vztahy se zákazníkem. Pozoroval jsem i lidi, kteří byli frustrovaní z toho, že se jim vývoj nedaří, že jsou jako tým neefektivní… pak se upnuli k nějaké nové technologii, slibovali si od ní, že vyřešení jejich problémy… a nestalo se vůbec nic, akorát vyplýtvali hodně času na zavádění změny, ale vývoj byl pořád neefektivní, protože příčina byla někde jinde.

[Fluttershy, yay!]

Ono je sice celkem přirozené, že se programátoři hádají o programovacích jazycích, knihovnách, frameworcích… ale často by více pomohlo ten čas trávit jinak a optimalizovat jiné části vývojového procesu, komunikaci mezi lidmi nebo vztahy se zákazníkem. Pozoroval jsem i lidi, kteří byli frustrovaní z toho, že se jim vývoj nedaří, že jsou jako tým neefektivní… pak se upnuli k nějaké nové technologii, slibovali si od ní, že vyřešení jejich problémy… a nestalo se vůbec nic, akorát vyplýtvali hodně času na zavádění změny, ale vývoj byl pořád neefektivní, protože příčina byla někde jinde.

Zrovna tuším JS dřív psal o pojetí organizace společnosti jako technologie (bylo to v nějakém dávné „diskuzi“ tuším o alternativách ke kapitalismu).

Třeba agile je v tomhle smyslu „technologie“… a je kolem ní taky vcelku cargo kult.

[xkucf03]

V C/C++ je to IMO problém zcela jednoznačně … V C/C++ nullable pointers ještě víceméně dávají smysl, protože to jsou nízkoúrovňový jazyky …

Tak problém to bude větší, než v Javě, to ano, ale jednak nemyslím, že by byl až tak fatální, že bych to musel takhle prožívat a dělat kolem toho nějaká skandální prohlášení typu „billion dollar mistake“ – a jednak, jak sám píšeš, jsou to nízkoúrovňové jazyky a tam se pracuje přímo s pamětí, takže ukazatel tam dává smysl (a přirozeně pak může ukazovat i na adresu nula nebo na adresu, kde je něco jiného, než programátor očekával, protože udělal chybu).

Koneckonců vzpomeň na segfault, co jsi před časem řešil, to byla taky dangling reference...

Jestli myslíš ten regulární výraz, tak to považuji v první řadě za nedostatek dokumentace (nebo jsem špatně četl, ale spíš bych řekl, že to tam není dost dobře popsané). Tam se totiž nepracovalo se surovým ukazatelem, ale s objektem, u kterého jsi mohl mít pocit, že ho máš normálně ve své lokální proměnné a sám si řídíš jeho životní cyklus… a on přitom kdesi uvnitř obsahoval ukazatele na jiný objekt, což nebylo na první pohled zřejmé ani intuitivní, a tenhle objekt měl jiný životní cyklus (mohl skončit dřív). Tzn. je to spíš otázka návrhu – byla tam závislost mezi objekty, která nebyla na první pohled zřejmá a asi ani moc zdokumentovaná. Když jsem nad tím zpětně přemýšlel, tak to celkem dává smysl implementované tak, jak to je – akorát tohle člověk většinou rozklíčuje až zpětně, na první pohled to moc zřejmé není. Alespoň ne pro javistu :-)

ale co to dělá ve vysokoúrovňovém staticky a silně typovaném jazyce, jako je Java, to nechápu

Jak jsem psal, v praxi to není nějak velký problém. Každý máme nějakou tu humornou historku, jak jsme ladili záhadný NullPointerException, ale z celkového času stráveného vývojem je to nepodstatný zlomek. On už jen GC eliminuje velkou část problémů (které mohou nastat třeba v tom C++, pokud se tam používají surové ukazatele a ne ty chytré).

Co se týče čistoty návrhu jazyka, to je věc jiná. Tady souhlasím, že striktně nenulové reference (a následně řešení na úrovni nějakých Optional objektů) by byly možná lepší… ale vezmi v úvahu rok vzniku Javy a zpětnou kompatibilitu. Schůdnější je řešení na úrovni volitelných anotací a kontroly nějakým frameworkem nebo IDE. Viz třeba Avoid Check for Null Statement in Java nebo @Nullable and @NotNull.

Zajímavé je dát si tuhle otázku do kontextu diskuse dynamické vs. statické jazyky. U těch dynamických nemáš vůbec jisté, jaký typ v proměnné budeš mít, a běžně programy v době běhu padají na tom, že metoda nebo proměnná neexistuje. Tzn. ne že by v proměnné chyběla hodnota (null), ale on tam chybí úplně ten „slot“ (proměnná či metoda), ve kterém by něco mělo/mohlo být.

[Josef Kufner]

To není o tom, zda je jazyk dynamický nebo statický, ale o tom, jak schopný je jeho typový systém. Například typový systém Typescriptu podchytí věci, o kterých si C++ může nechat jen zdát.

[kralyk z abclinuxu]

Tak problém to bude větší, než v Javě, to ano, ale jednak nemyslím, že by byl až tak fatální, že bych to musel takhle prožívat a dělat kolem toho nějaká skandální prohlášení typu „billion dollar mistake“

Hm, nedělal jsem ani jsem nehledal vyloženě nějakou statistiku / odhad a je pravda, že "billion" (ie. miliarda) je vysoký číslo, ale třeba ty částky, co se nabízejí v různých Pwn2Own soutěžních a podobně jsou taky dost slušně vysoký. Samozřejmě tam nejde zdaleka jen o memory management, nicméně ten je toho poměrně podstatnou součástí.

Jestli myslíš ten regulární výraz, tak to považuji v první řadě za nedostatek dokumentace (nebo jsem špatně četl, ale spíš bych řekl, že to tam není dost dobře popsané). Tam se totiž nepracovalo se surovým ukazatelem, ale s objektem, u kterého jsi mohl mít pocit, že ho máš normálně ve své lokální proměnné a sám si řídíš jeho životní cyklus… a on přitom kdesi uvnitř obsahoval ukazatele na jiný objekt, což nebylo na první pohled zřejmé ani intuitivní, a tenhle objekt měl jiný životní cyklus (mohl skončit dřív).

To je IMO stále stejný problém - programátor chce, aby na nějakém místě v kódu byl vždy validní pointer/reference (v tomhle případě v tom match objektu) a když tohle nemůže vyjádřit typovým systémem, tak to musí dát do dokumentace, na což může zapomenout nebo to nepopsat dost jasně (jako se stalo v tvým případě).

V podstatě jsou aktuálně dvě možnosti, jak se to dá řešit: Buď Použít GC + nejlépe non-nullable referenci (protože match objekt nad nullovou referencí nejspíš moc nemá smysl), anebo v případě, že GC nechceš nebo nemůžeš použít, tak zbývá jen jíst cestou Rustu, tj. přidat k té referenci typovou informaci. Viz Match<'t> - ten generickej parametr 't reprezentuje lifetime toho původního stringu, na kterým je ta věc závislá, je to přesně to chybějící vyjádření té závislosti, o které mluvíš. Vevnitř je ten objekt to samé jako v tom C++, navíc tam je jen ta typová informace, kde ten parametr 't se propaguje k té referenci na ten původní string.

Zajímavé je dát si tuhle otázku do kontextu diskuse dynamické vs. statické jazyky.

Jo, to mě taky napadlo, chtěl jsem i něco takového původně připsat - v zásadě ty implicitně nullovatelné reference mi přijdou jako fíčura dynamicky typovaných jazyků (proto mi to nepřijde na místě ve staticky typovaným jazyce).

[Bherzet]

v zásadě ty implicitně nullovatelné reference mi přijdou jako fíčura dynamicky typovaných jazyků (proto mi to nepřijde na místě ve staticky typovaným jazyce)

BTW: Párkrát jsem si dělal srandu, že zatímco celý softwarový průmysl řeší, jak odstranit null a sám vynálezce tohoto konceptu si sype popel na hlavu a označuje ho za tu „billion dollar mistake“, tak se široké adopce dočká jazyk, který nemá jeden, ale tři typy reprezentující nic (null, undefined a NaN, který v JavaScriptu může vypadnout i z operací nad nečíselnými typy).

[podlesh]

ale co to dělá ve vysokoúrovňovém staticky a silně typovaném jazyce, jako je Java, to nechápu.

Protože Java není vysokoúrovňový jazyk! Je to nízkoúrovňový jazyk srovnatelný s C.

Ta klasifikace je výrazně zkreslena tím, že Java je nízkoúrovňový jazyk pro platformu JVM, která nemá fyzickou (hardware) reprezentaci (i když plány byly, nicméně Sun a jeho plány...). Pokud se podíváme na JVM bytekód, tak je na první pohled patrné jak je samotný jazyk triviální.

Pravda, v posledních několika verzích se i Java významně posunula nahoru, ale pořád to není ono.

A co se týče silné typovosti, tak je to celkem slabota

[deda.jabko]

Protože Java není vysokoúrovňový jazyk! Je to nízkoúrovňový jazyk srovnatelný s C.

A valka je mir.

Ta klasifikace je výrazně zkreslena tím, že Java je nízkoúrovňový jazyk pro platformu JVM

A kdyz Javu prelozim pomoci gcj nebo graalu do nativniho kodu, bude to uz vysokourovnovy jazyk?

Pravda, v posledních několika verzích se i Java významně posunula nahoru, ale pořád to není ono.

Z pohledu urovne abstrakce, kterou jazyk nabizi, a to je to, co dela onu vysku jazyka, byl posledni posun u verze 5 z roku 2004, kdy se zavedly generika a anotace (coz je zatim relativne nedocenena vlasnost). Pak by jeste slo uvazovat o verzi 8 (rok 2014), kdy pribyly lambda-vyrazy, ale ty nenabizi nic jineho nez to, co uz s jazykem slo delat pred tim. Jen se to da pouzivat pohodlneji. Ostatni upravy z posledni doby jsou drobnosti pro pohodlnejsi programovani, ale jazyk na vyssi uroven (z pohledu abstrakce) neposunuji.

[Bystroushaak]

Z pohledu urovne abstrakce, kterou jazyk nabizi, a to je to, co dela onu vysku jazyka, byl posledni posun u verze 5 z roku 2004, kdy se zavedly generika a anotace (coz je zatim relativne nedocenena vlasnost). Pak by jeste slo uvazovat o verzi 8 (rok 2014), kdy pribyly lambda-vyrazy, ale ty nenabizi nic jineho nez to, co uz s jazykem slo delat pred tim. Jen se to da pouzivat pohodlneji. Ostatni upravy z posledni doby jsou drobnosti pro pohodlnejsi programovani, ale jazyk na vyssi uroven (z pohledu abstrakce) neposunuji.

Proč prvně reaguješ sarkasticky na podleshe a pak tvrdíš v podstatě to samé co on?

[deda.jabko]

Proč prvně reaguješ sarkasticky na podleshe a pak tvrdíš v podstatě to samé co on?

Protoze to netvrdim. Za prve je absurdni, aby se uroven jazyka posuzovala podle toho, co ten jazyk bude provadet.

Za druhe je to otazka miry, jak moc je jazyk nizko nebo vysoko urovnovy.

Podlesh manipulativne predefinovava pojmy, "aby mu to vyslo", ale Java je spise vysokourovnovy jazyk, vzhledem k tomu, jak ma reseny objekty, vyjimky, reflexi a dalsi veci. Na co jsem v tom odstavci primarne reagoval je veta: "Pravda, v posledních několika verzích se i Java významně posunula nahoru,". Coz neni pravda, protoze v poslednich verzich vazne nedoslo k pridani dalsich vyssich urovni abstrakce, ale to z Javy nedela nizkourovnovy jazyk.

[Bystroushaak]

Protoze to netvrdim. Za prve je absurdni, aby se uroven jazyka posuzovala podle toho, co ten jazyk bude provadet.

„Úroveň jazyka“ budiž, „úroveň abstrakce“ mi absurdní teda nepřijde. Pokud můžeš vzít dva jazyky, dát je vedle sebe (například jsi v obou programoval) a jasně vyhodnotit který z nich ti přijde „vysokoúrovňovější v použité abstrakci“, tak s tím nevidím žádný problém. Jestliže se takhle dokáže shodnout víc lidí, tak není důvod proč to nepoužívat v běžném mluveném jazyce jako „vysokoúrovňovější“.

Podlesh manipulativne predefinovava pojmy, "aby mu to vyslo", ale Java je spise vysokourovnovy jazyk, vzhledem k tomu, jak ma reseny objekty, vyjimky, reflexi a dalsi veci. Na co jsem v tom odstavci primarne reagoval je veta: "Pravda, v posledních několika verzích se i Java významně posunula nahoru,". Coz neni pravda, protoze v poslednich verzich vazne nedoslo k pridani dalsich vyssich urovni abstrakce, ale to z Javy nedela nizkourovnovy jazyk.

Pokud si dám na jednu stranu python, common lisp, nebo třeba smalltalk a na druhou javu, tak sorry jako, java je z hlediska abstrakce, použitých konstrukcí a programátorské pohodlnosti nízkoúrovňový jazyk. Což není hejt na javu, ale konstatování faktu, ke kterému jsi se dostal taky. Ostatně kdyby to tak nebylo, tak se nikdo ani nenamáhá s tím že by ty ostatní jazyky používal, když jsou zároveň typicky pomalejší než java.

Na Javě je „vysokoúrovňové“ asi tak to, že má GC a objekty. To (nebo alternativu) má ale dneska kde co. Čímž nechci popírat vyspělost java platformy, jen poukázat na to, že pokud ti jde o abstrakci, tak java nějak zazáří asi jen ve srovnání s C/C++.

[Fluttershy, yay!]

To bude tím, že si „úroveň“ vykládá každý jinak.

Jestli je Java nízkoúrovňová, co jsou pak jazyky symbolických adres? Bezúrovňové?

[Bystroushaak]

Jestli je Java nízkoúrovňová, co jsou pak jazyky symbolických adres? Bezúrovňové?

Ještě víc nízkoúrovňové, stejně jako je třeba C víc „nízkoúrovňovější“ než java? To že java má nějakou úroveň nedělá assemblery bez úrovně, ostatně pořád tam máš ty symbolické adresy (goto návěští), ke kterým se počítají jmp skoky automaticky a na pozadí se děje překlad, který často podporuje například makra a tak.

To bude tím, že si „úroveň“ vykládá každý jinak.

Já tvrdím že existuje všeobecně vnímaná jednodimenzionální úroveň hierarchie „programátorské abstrakce*“, která není na koncích uzavřená**. Na téhle hierarchii můžeš subjektivně umisťovat jazyky a pak je porovnávat. Přijde mi, což samozřejmě taky může být čistě subjektivní, že mezi programátory panuje docela shoda ohledně porovnání jazyků***. Například prakticky každý se shodne na tom, že java je „výšeúrovňovější“ než C. C je „výšeúrovňovější“ než assembler. Mno a z druhé strany, „python“ je „výšeúrovňovější“ než Java, „common lisp“ je „výšeúrovňovější“ než python a tak podobně. Nějaké fuzzy otázky jsou tak leda jestli je třeba Java „výšeúrovňovější“ nebo „nízkoúrovňovější“ než C#. Nebo Python vs Ruby.

* O tom byla původní diskuze a podle mě je to v praxi naprosto jednoduše rozhodnutelné z hlediska toho jak moc je to pro programátora abstraktní, efektivní a produktivní. Java například nemá ani operátor na porovnání stringu (a vůbec operator overloading), což abstraktní není.

** Stejně tak i čistý machine code typicky expanduje na nějaký mikrokód v procesoru, a i ten mikrokód expanduje na hardware. A hardware taky používá abstrakce. I jazyky jako VHDL používají abstrakce.

*** Například když se bavím u nás ve firmě s ostatními lidmi z týmu u nás ve firmě, tak o té hierarchii vědí, aniž bych o tom s nimi mluvil. Například i ženská, co přešla na programátorku z ekonomického oddělení, kde předtím plánovala budget o téhle hierarchii ví, přestože jinak nemá formální vzdělání v programátorském oboru, jen si prostě vyzkoušela různé věci.

[Bystroushaak]

Já tvrdím že existuje všeobecně vnímaná jednodimenzionální úroveň hierarchie „programátorské abstrakce*“, která není na koncích uzavřená**. Na téhle hierarchii můžeš subjektivně umisťovat jazyky a pak je porovnávat. Přijde mi, což samozřejmě taky může být čistě subjektivní, že mezi programátory panuje docela shoda ohledně porovnání jazyků***. Například prakticky každý se shodne na tom, že java je „výšeúrovňovější“ než C. C je „výšeúrovňovější“ než assembler. Mno a z druhé strany, „python“ je „výšeúrovňovější“ než Java, „common lisp“ je „výšeúrovňovější“ než python a tak podobně. Nějaké fuzzy otázky jsou tak leda jestli je třeba Java „výšeúrovňovější“ nebo „nízkoúrovňovější“ než C#. Nebo Python vs Ruby.

Nějak jsem nedokončil tu myšlenku;

Pokud tohle uznáváš, tak pak záleží, kde se relativně na té ose pohybuješ. Pokud se pohybuješ někde u C, tak jasně, java ti bude připadat vysokoúrovňová. Pokud se pohybuješ u lispu, tak asi jen těžko.

[Radovan]

A céčkaři se s lispaři shodnou na tom, že Java je sračka

[kralyk z abclinuxu]

Já tvrdím že existuje všeobecně vnímaná jednodimenzionální úroveň hierarchie „programátorské abstrakce*“, která není na koncích uzavřená**.

Hmm, s tim bych tak úplně nesouhlasil.

Pokud jde o ten dolní konec, tak to je celkem dobře definovaný: Začíná to Céčkem a pokračuje přes assembly apod. Vlastnosti jsou celkem jasný: absence abstrakcí, manuální správa paměti, řešení OS- nebo HW-specific věcí, možnost dosažení brutálního výkonu apod.

Pokud jde o ten horní konec, tak ten je IMO naprosto totálně mlhavě definovanej a reálně není jednodimenzionální, ale větví se do spousty různých rovin. Vezměme si jako příklad třeba už jen ten blbej memory-management: Je vysokoúrovňovější GC, nebo ownership-borrowing á la Rust? Z "bežného" pohledu by se asi řeklo, že GC, protože umožňuje pohodlné použití, člověk nemusí nic řešit, pointery/reference prostě vždy ukazují na validní data. Což v Rustu sice taky, ale člověk musí skákat krz obruče, aby si objekty pokládal do správných hierarchií a správně všechno propojil, aby ho kompilátor neposlal do řiti. Navíc Rust je, řekněme, ideologicky zaměřený na nižší úroveň. Takže bychom řekli, že je nízkoúrovňovější (a tak se většinou zařazuje). Ovšem z jinýho pohledu to může být jinak: GC je v konceptuálně v podstatě dost primitivní věc. Je to víceméně brute-force řešení, který začlo bejt slušně použitelný až po desetiletích, kdy bylo na problém potřeba házet jak lopatou stále vyšší výpočení výkon a optimalizace. Oproti tomu ownership-borrowing je založený ma poměrně vymakaném formálním modelu, který mimo jiné jako vedlejší efekt přinesl možnost provably-correct concurrent přístupu ke sdíleným datům, což neumí ani jazyky považované tradičně za velmi vysokoúrovňové (nebo pouze v omezené míře). Takže otázka, který z těch přístupů je vysokúrovňovější, IMO není jednozančná a záleží, jak se na to člověk dívá a jaký preferuje tradeoffs.

Podobný příklad může být třeba to, že Java a C# se považují za vysokoúrovňovější než C++, ale např. nemají imutabilní reference, což je v silně typovaným jazyku celkem užitečná vlastnost. Taky mělo C++ dříve lambda funkce než Java (i když je pravda, že v Javě bylo asi trochu snažší to workaroundovat).

Podobnej je taky třeba obecně rozpor mezi dynamicky a staticky typovanými jazyky. Je vysokoúrovňovější Haskell, nebo Lisp? Touhle otázkou by mohl odstartovat brutální flamewar, který by se nejspíš ničeho nedobral

[Bystroushaak]

Z větší části s tebou souhlasím. Hodně jsem to zjednodušil vzhledem k tomu konkrétnímu tématu. Samozřejmě, že k té ose abstrakce je možné přidávat spoustu dalších dimenzí odpovídajících na otázku „z hlediska čeho?“, ala abstrakce syntaxe, abstrakce patternů, abstrakce správy paměti, abstrakce ..

[Bherzet]

Pleteš dohromady míru pohodlnosti v podobě syntaktických cukrů a úroveň abstrakce, což není nutně totéž.

Nemyslím si, že je zápis a == b implicitně abstraktnější než a.equals(b) nebo equals(a, b) nebo == a b. Pokud tě ten jazyk odstíní, odabstrahuje od nějakého detailu – např. ti umožní napsat a == b bez starosti o to, zda má proměnná a hodnotu null – pak v tom ohledu abstraktnější je. A pakliže v Javě programátoři v některých případech záměrně píší Yoda-style ("abc".equals(s)) právě a jen proto, aby jim to nespadlo na výše diskutované NPE, pythonní porovnávání stringů vyjde z tohoto srovnání abstraktněji.

Obdobně tak dědičnost nebo generické programování odstíní programátora od starosti o to, s jakým konkrétním typem pracuje, a umožní mu svoje řešení zobecnit. Python umožňuje dosáhnout stejné úrovně abstrakce, ale tím, že neposkytuje žádné garance, ve výsledku tu abstrakci spíš ubírá. Duck-typing je vadný koncept: reálně se mi v Pythonu stává, že nevím, jaký typ mám někam poslat, ani jaké má mít vlastnosti, a musím se tím zaobírat mnohem víc než v Javě.

Pro zcela konkrétní příklad: jaký typ očekává metoda set_color(self, color) z matplotlib? Z dokumentace ani signatury metody není patrné, že očekává HTML-like string ve tvaru "#rrggbb". Absentující dokumentace je sice vinou projektu, ale jazyk mi zde neposkytuje žádný dodatečný komfort pro rozřešení této nejasnosti. Čisté, automatické a bezmyšlenkovité řešení v Javě by spočívalo v definování třídy Color s několika přetíženými konstruktory, kde by patrně i bez dodatečného popisu bylo možné několika rychlými experimenty pochopit, jaké hodnoty jsou očekávány na vstupu. To by současně odstranilo potřebu onen string parsovat na straně jedné a generovat na straně druhé. Proto absenci statického typování reálně považuji za ztrátu abstrakce asi podobně jako kdyby jazyk nerozlišoval jména parametrů.

Je to ale pření se o milimetry, zatímco před námi jsou kilometry neprobádaného prostoru. Ve všech současných jazycích se reálně programuje skoro stejně a zkratky, které poskytují ty „vyšší“ jazyky, jsou pořád jen trochu lepší lopaty, které se o něco méně lámou. Jak abstraktní je přemýšlet nad tím, v kolika vláknech můj program poběží a řešit z toho vyplývající problémy? Jak abstraktní je řešit serializaci a deserializaci dat?

Nedosahujeme zatím ani zdaleka úrovně abstrakce lidského jazyka, potažmo schopností lidské mysli. Přít se o to, jestli je jeden z mnoha těch tuctových jazyků, co jsou na trhu, abstraktnější než druhý, je až na absolutní nesmysly typu „Java je nízkoúrovňový jazyk srovnatelný s C“, vlastně směšné. Ostatně, ani náš způsob používání spotřební elektroniky příliš abstraktní není. Přizpůsobili jsme se strojům, protože lepší zatím postavit neumíme.

[Bystroushaak]

Pleteš dohromady míru pohodlnosti v podobě syntaktických cukrů a úroveň abstrakce, což není nutně totéž.

Nutně ne, ale dost často ano. Programovací jazyk je uživatelský interface, a uživatelský interface který mi neumožňuje dělat pokročilé věci je z mého pohledu méně efektivní a abstraktní.

Nemyslím si, že je zápis a == b implicitně abstraktnější než a.equals(b) nebo equals(a, b) nebo == a b. Pokud tě ten jazyk odstíní, odabstrahuje od nějakého detailu – např. ti umožní napsat a == b bez starosti o to, zda má proměnná a hodnotu null – pak v tom ohledu abstraktnější je. A pakliže v Javě programátoři v některých případech záměrně píší Yoda-style ("abc".equals(s)) právě a jen proto, aby jim to nespadlo na výše diskutované NPE, pythonní porovnávání stringů vyjde z tohoto srovnání abstraktněji.

Tak samozřejmě, že samotný operátor == více abstraktní zas tak o moc není, ale já jsem zmiňoval celý operator overloading, tedy že můžeš využívat operátory pro svoje potřeby. To už abstraktní je. Například se tím dají dělat věci jako path, což je podle mého názoru hodně abstraktní věc.

Obdobně tak dědičnost nebo generické programování odstíní programátora od starosti o to, s jakým konkrétním typem pracuje, a umožní mu svoje řešení zobecnit. Python umožňuje dosáhnout stejné úrovně abstrakce, ale tím, že neposkytuje žádné garance, ve výsledku tu abstrakci spíš ubírá. Duck-typing je vadný koncept: reálně se mi v Pythonu stává, že nevím, jaký typ mám někam poslat, ani jaké má mít vlastnosti, a musím se tím zaobírat mnohem víc než v Javě.

Tak tam to typování prostě cpi, ne? Já poslední dobou mypy trochu používám na osobních projektech, třeba teď jsem to použil v generátoru mého blogu. A už to má support přímo v pythonu.

Pro zcela konkrétní příklad: jaký typ očekává metoda set_color(self, color) z matplotlib? Z dokumentace ani signatury metody není patrné, že očekává HTML-like string ve tvaru "#rrggbb". Absentující dokumentace je sice vinou projektu, ale jazyk mi zde neposkytuje žádný dodatečný komfort pro rozřešení této nejasnosti. Čisté, automatické a bezmyšlenkovité řešení v Javě by spočívalo v definování třídy Color s několika přetíženými konstruktory, kde by patrně i bez dodatečného popisu bylo možné několika rychlými experimenty pochopit, jaké hodnoty jsou očekávány na vstupu. To by současně odstranilo potřebu onen string parsovat na straně jedné a generovat na straně druhé. Proto absenci statického typování reálně považuji za ztrátu abstrakce asi podobně jako kdyby jazyk nerozlišoval jména parametrů.

Jako tohle beru, ale jednak je blbě pojmenovaná signatura té metody, kdy se parametr nemá jmenovat color, ale něco jako rgb_hexstring, pak taky to má mít docstring. Hlavně ten argument ale úplně opomíjí, že i v javě můžeš mít hovnokód, že tam tu color budeš hledat půl dne, což jsem si zažil nejednou když někdo neumí OOP a pak lepí patterny úplně blbě. Takže typový systém tě před hovnokódem sám od sebe neubrání.

Je to ale pření se o milimetry, zatímco před námi jsou kilometry neprobádaného prostoru. Ve všech současných jazycích se reálně programuje skoro stejně a zkratky, které poskytují ty „vyšší“ jazyky, jsou pořád jen trochu lepší lopaty, které se o něco méně lámou. Jak abstraktní je přemýšlet nad tím, v kolika vláknech můj program poběží a řešit z toho vyplývající problémy? Jak abstraktní je řešit serializaci a deserializaci dat?

Si zkus něco čistě funkcionálního.

Nedosahujeme zatím ani zdaleka úrovně abstrakce lidského jazyka

Což je imho dobře, ne špatně, i když to tak na první pohled nemusí třeba vypadat.

potažmo schopností lidské mysli

Tohle je takové dost nicneříkající. Například lispy jsou populární právě tím, že si je různí pologéniové přiohnout ke svému obrazu a pak jsou v nich absurdně efektivní, až na to že ten kód už nikdy nikdo nepochopí a je nekompatibilní s úplně celým zbytkem světa. Forth to samé.

Přít se o to, jestli je jeden z mnoha těch tuctových jazyků, co jsou na trhu, abstraktnější než druhý, je až na absolutní nesmysly typu „Java je nízkoúrovňový jazyk srovnatelný s C“, vlastně směšné.

Eh, ani moc ne. Například to přímo souvisí s efektivitou.

[Bherzet]

Například se tím dají dělat věci jako path, což je podle mého názoru hodně abstraktní věc.

Nope. Zápis Path("bar") / "foo.txt" fakt nepovažuji za abstraktnější než os.path.join("bar", "foo.txt"). Je to úplně totéž. Musíš vědět, že pracuješ s typem Path, že je pro něj přetížený operátor /… Jak se to liší od situace, kdy musíš vědět, že existuje funkce join, která dělá totéž a akceptuje stejné argumenty (operandy)? Z hlediska uvažování programátora je to úplně totéž, s jedním podstatným rozdílem: přetěžování operátorů tímto způsobem je neskutečná prasárna a do projektu bych si to nikdy nepustil. Přejmenovat funkci na dopředné lomítko, protože „cesty přece obsahují dopředná lomítka!“ (na některých platformách, that is… zdravím do Microsoftu), bez ohledu na to, že všude jinde se infixově zapsaným lomítkem provádí dělení, pouze ubírá na čitelnosti. Takový kód produkují akorát lidi, co si zrovna přečetli tutoriál, jak se ten krutopřísný operator overloading používá a mají potřebu všem ukázat, že to jako umí. S abstrakcí to nemá společného vůbec nic. Je to syntaktický cukr, a to extrémně neužitečný a dementní syntaktický cukr. Možnost volat obecně kterékoliv metody infixově by mohla být, dejme tomu, užitečná, ale zase komplikuje čtení kódu (jednou a.b(c), podruhé a b c) a jak říkám, určitě nepřidává žádnou další abstrakci.

Tak tam to typování prostě cpi, ne? Já poslední dobou mypy trochu používám na osobních projektech, třeba teď jsem to použil v generátoru mého blogu.

S typováním nemám problém primárně ve svém kódu, ale v cizím kódu. Jak sám píšu, chybějící dokumentace je vinou projektu, ale jazyk neposkytuje žádné vodítko a reálně vyžaduje větší pátrání a přemýšlení na mé straně. Viz argument s názvy… argumentů. Efektivně za důkaz abstrakce, potažmo její absence, považuji to, jak moc nad něčím musím přemýšlet místo toho, aby to bylo magicky vyřešeno za mě, nebo to šlo snadno odhadnout. Kdybych měl někde pointer na pár bajtů v paměti a nevěděl, jak je mám interpretovat, ale místo toho jsem na to musel přijít z nějakých externích zdrojů a pak to zkusit spustit a doufat, že už to teda bude fungovat, bude to srovnatelně hloupé jako programovat v jazyce s volitelným typováním, které komunita považuje převážně za zbytečné a které pokud náhodou někdo používá, může si do něj psát v podstatě cokoliv v závislosti na tom, jestli používá nebo nepoužívá statický analyzér, který ho vypíčuje. a: str = 5 je v Pythonu validní kód a pokud někdo podobnou stupiditu udělá v argumentu a nesjede si to tím volitelným checkerem, bude ten checker pak hlásit chybu v mém kódu.

Což je imho dobře, ne špatně, i když to tak na první pohled nemusí třeba vypadat.

Abstrakce znamená, že nad něčím – co v danou chvíli považuješ za detaily – nepřemýšlíš. Někde si takový luxus samozřejmě dovolit nemůžeš, nebo to musíš nějak dořešit později (např. testováním).

Například lispy jsou populární právě tím, že si je různí pologéniové přiohnout ke svému obrazu a pak jsou v nich absurdně efektivní, až na to že ten kód už nikdy nikdo nepochopí a je nekompatibilní s úplně celým zbytkem světa.

Tak ono pracovat s kódem, jedním konkrétním, bajt po bajtu, taky není moc abstraktní, že.

Například to přímo souvisí s efektivitou.

Takže pokud vytvořím dialekt existujícího jazyka, který bude někde na úrovni Ostrajava nebo překladů C do češtiny hromadou #define, a svoláváním „focus groups“ cíleně vyšlechtím takovou syntaxi, která bude nejefektivnější z hlediska rychlosti zápisu, tak je možné, že bude abstraktnější než ten původní jazyk?

Je těsnopis abstraktnější než normální písmo?

[Bherzet]

Nebo jednou b(a, c), podruhé a b c, ale to je detail.

[kralyk z abclinuxu]

Například se tím dají dělat věci jako path, což je podle mého názoru hodně abstraktní věc.

Nope. Zápis Path("bar") / "foo.txt" fakt nepovažuji za abstraktnější než os.path.join("bar", "foo.txt"). Je to úplně totéž. Musíš vědět, že pracuješ s typem Path, že je pro něj přetížený operátor /… Jak se to liší od situace, kdy musíš vědět, že existuje funkce join, která dělá totéž a akceptuje stejné argumenty (operandy)?

IMO to úplně totéž není. Ta syntaxe s infix operátorem líp podporuje řetězení, tj. a / b / c. Obecně ty 'lepší' syntaxe pak třeba umožňují method chaining nebo (ještě abstraktněji) tacit programming ...

[Bherzet]

os.path.join("a", "b", "c", "d"), příp. v cyklu místo path /= filename by bylo path = os.path.join(path, filename). Stejně abstraktní.

[JS1]

Podle me se s Bystroushaakem mijite v diskusi, protoze to spatne vysvetluje. Syntakticky cukr opravdu neni abstrakce, ten tu abstrakci jen umoznuje vyjadrit podobnym jazykem.

Tou skutecnou abstrakci v tomto konkretnim pripade je definice cesty jako samostatneho typu. Takze misto "cesta/k/memu/souboru", coz je retezec (a neni zcela zrejme, ze jde o cestu a jake jsou jeji slozky), muzeme psat Path("cesta") / "k" / "memu" / "souboru", coz prave vyuziva te abstrakce, ze cesta je typ. Takze to skutecne neni abstraktnejsi nez os.path.join("cesta","k","memu","souboru"), ale je to (IMHO) citelnejsi, protoze ta abstrakce nam umoznuje zapsat to jazykem, ktery uz zname (tradicni zapis cesty). A zaroven ten jazyk zna i interpret Pythonu (narozdil od te puvodni cesty, o ktere vi jen to, ze je retezcem), coz je prave pointou vytvoreni te abstrakce.

[Bherzet]

Já si nemyslím, že je to v tomto případě čitelnější, ale souhlasím s tebou v tom, že zápis s typem je abstraktnější (i čitelnější) než zápis, kde si ho musíš domýšlet. Je to trochu paradox a zdůrazňuji slovo musíš, protože kdybychom typ znát nepotřebovali a jazyk nás naopak nutil s ním pracovat, bylo by to projevem absence abstrakce.

[xkucf03]

Tou skutecnou abstrakci v tomto konkretnim pripade je definice cesty jako samostatneho typu. Takze misto "cesta/k/memu/souboru", coz je retezec (a neni zcela zrejme, ze jde o cestu a jake jsou jeji slozky)

Souhlasím, že místo obecných typů (řetězce, čísla) je lepší používat skutečné typy, které vystihují tu podstatu (např. jméno souboru je něco jiného než jméno osoby) a ne jen implementační detail (někde uvnitř je to oboje textový řetězec¹). Ale tohle dělá třeba i Java nebo C++.

Ten typ pak může mít specifické metody, které s ním souvisejí (a které by u univerzálního textového řetězce nedávaly smysl). Ale jestli to jsou metody nebo přetížené operátory, to už není zásadní rozdíl.

muzeme psat Path("cesta") / "k" / "memu" / "souboru" … citelnejsi, protoze ta abstrakce nam umoznuje zapsat to jazykem, ktery uz zname (tradicni zapis cesty)

Když např. v shellu zadám ls "/etc" / "passwd", tak to udělá něco úplně jiného, než ls /etc/passwd, takže to není moc funkční analogie a takové věci mohou být i dost matoucí.

Nevím, jestli je to čitelnější. Tady bych si sice správně tipnul, že to spojuje cesty, ale jinde jsou přetížené operátory svým způsobem obfuskace.

Přetížený operátor ušetří psaní pár znaků těm, kteří ten konkrétní operátor mají nastudovaný, ale všem ostatním, ztíží porozumění kódu.

Když jsem se naučil přetěžovat operátory v C++, tak jsem nadšeně předělal pár metod ve svém kódu na operátory… a pak jsem se nad tím zamyslel a předělal to zase zpět, protože to nebylo prokazatelně lepší. Bylo to jen „chytřejší“ a „pokročilejší“ a dělalo mi to radost z toho, co jsem se zrovna naučil. Ale to jsou vlastnosti, které ostatní programátory nezajímají a mají pro ně nulovou nebo spíš zápornou hodnotu. Oproti tomu v Javě je snadnější udržet tyhle pudy a kreativitu na uzdě a psát „nudný“ kód, který „jen“ dobře slouží.

V některých případech přetěžování operátorů využití má a může to vést na elegantní kód – ale s mírou, s rozmyslem a někdy je méně více.

Co se týče studia nového/neznámého kódu, tak většina IDE umí proklik na definici metody. Ale kolik jich umí proklik na definici operátoru. Ještě těžší je to při vyhledávání na internetu: zkus si do vyhledávače zadat název jazyka či knihovny a názvu metody – máš velkou šanci, že najdeš, co potřebuješ. Ale zkus si do vyhledávače zadat název jazyka či knihovny a lomítko, závorku, plus nebo hvězdičku…

_{[1] i když cesty k souborům jsou spíš pole bajtů, ale to teď nechme stranou}

[kralyk z abclinuxu]

os.path.join("a", "b", "c", "d"), příp. v cyklu místo path /= filename by bylo path = os.path.join(path, filename). Stejně abstraktní.

Furt nesouhlasim

Zaprvý, tiše jsi přidal požadavek na variadický funkce, což je taky abstrakce (je to abstraktnější než non-variadická funkce) a ne všechny jazyky ji podporují. Třeba v C++ nebo Rustu uděláš jen tu variantu s infix operátorama (resp. v C++ jde využít C-čkovou podporu pro variadický funkce, ale je to z pohledu C++ hnusný / považuje se za antipattern).

Zadruhý, ta varianta s operátorem je IMO abstraktnější proto, že ten typ path obsahuje informaci, že podporuje operaci / , čehož může využívat abstrahovaný kód (např. skrz duck typing v dynamickejch jazycích a skrz vtables a/nebo generika ve staticky typovanejch). Je pravda, že zrovna u path to asi nemá úplně význam, ale obecně ano. Samozřejmě implementace operátoru je pouze syntax sugar pro member funkci, takže to je stejně abstraktní, ovšem standalone funkce je méně abstraktní, protože neumožňuje polymorfismus (resp. minimálně v pythonu a dalších běžných jazycich ne, v jiných jazycích to může být jinak).

[Bherzet]

No, já jsem nepřidal požadavek na nic. Ono je těžké bavit se o výšce abstrakce jednoho konkrétního jazykového konstruktu, když osamoceně jaksi nedává smysl bez toho jazyka okolo. Ale tady jsme primárně srovnávali Javu a Python, jak tomu ostatně bývá v diskuzích v tomto osazenstvu naším dobrým zvykem, a ty volitelný počet argumentů podporují oba.

Ano, informaci o typem podporovaných operacích asi lze považovat za abstrakci (ačkoliv tu informaci jde získat i odjinud a pak by to fungovalo i pro uživatelem definované operace, ne jen ty definované knihovnou, a navíc u toho nehrozí kolize [tak moc jako u jednoho sdíleného jmenného prostoru], takže…). Je to nicméně nezávislé na tom, jak se ta operace jmenuje (jestli je dopředné lomítko validní název, nebo nikoliv) a zda ji lze volat infixově.

S polymorfismem souhlasím, ale to je opět řešitelné samotným typem a nezávislé na přetěžování operátorů.

[Bystroushaak]

Nope. Zápis Path("bar") / "foo.txt" fakt nepovažuji za abstraktnější než os.path.join("bar", "foo.txt"). Je to úplně totéž.

Tak doslova to není úplně totéž, že. A pointa byla v tom že abstraktní feature je oprátor overloading jako takový. Knihovna path může vést na abstraktnější kód, není to ale nutně vždy, v tom máš pravdu.

Z hlediska uvažování programátora je to úplně totéž, s jedním podstatným rozdílem: přetěžování operátorů tímto způsobem je neskutečná prasárna a do projektu bych si to nikdy nepustil. Přejmenovat funkci na dopředné lomítko, protože „cesty přece obsahují dopředná lomítka!“ (na některých platformách, that is… zdravím do Microsoftu), bez ohledu na to, že všude jinde se infixově zapsaným lomítkem provádí dělení, pouze ubírá na čitelnosti. Takový kód produkují akorát lidi, co si zrovna přečetli tutoriál, jak se ten krutopřísný operator overloading používá a mají potřebu všem ukázat, že to jako umí. S abstrakcí to nemá společného vůbec nic. Je to syntaktický cukr, a to extrémně neužitečný a dementní syntaktický cukr. Možnost volat obecně kterékoliv metody infixově by mohla být, dejme tomu, užitečná, ale zase komplikuje čtení kódu (jednou a.b(c), podruhé a b c) a jak říkám, určitě nepřidává žádnou další abstrakci.

To mi přijde jako poněkud vyhraněné tvrzení, ale vesměs jsem líný ti to rozporovat. Jinak já dost často přetěžuji například operátor sčítání (resp. magic method __add__()), pro sčítání nějakých komplexnějších věcí. Například jsem to použil na funkci, co agreguje nějaká data z databáze a výsledný kód byl mnohem, mnohem přehlednější než to co tam bylo předtím.

Jak sám píšu, chybějící dokumentace je vinou projektu, ale jazyk neposkytuje žádné vodítko a reálně vyžaduje větší pátrání a přemýšlení na mé straně.

Jo. A jak jsem psal, já s tebou vesměs souhlasím. V poslední době jsem na tohle částečně změnil pohled, ale v podstatě jsem nějaké optional typování používal vždy, jen to bylo v dosctringu (to mi hlídá IDE/editor odedávna).

Ono to možná bude znít hrozně, ale osobně jsem se naučil prostě kliknout na metodu a přesměrovat se na její zdroják (pycharm to umí dobře i na stdlib a tak dál), takže se prostě v těhle případech kouknu přímo na implementaci.

Efektivně za důkaz abstrakce, potažmo její absence, považuji to, jak moc nad něčím musím přemýšlet místo toho, aby to bylo magicky vyřešeno za mě, nebo to šlo snadno odhadnout.

To částečně souvisí s abstrakcí, ale hlavně s predikovatelností chování. Což záleží na tvém .. backgroundu (pozadí? sumě zážitků a očekávání).

Kdybych měl někde pointer na pár bajtů v paměti a nevěděl, jak je mám interpretovat, ale místo toho jsem na to musel přijít z nějakých externích zdrojů a pak to zkusit spustit a doufat, že už to teda bude fungovat, bude to srovnatelně hloupé jako programovat v jazyce s volitelným typováním, které komunita považuje převážně za zbytečné a které pokud náhodou někdo používá, může si do něj psát v podstatě cokoliv v závislosti na tom, jestli používá nebo nepoužívá statický analyzér, který ho vypíčuje. a: str = 5 je v Pythonu validní kód a pokud někdo podobnou stupiditu udělá v argumentu a nesjede si to tím volitelným checkerem, bude ten checker pak hlásit chybu v mém kódu.

Mno, tak v něm nedělej, ne? Jako když ti něco očividně nevyhovuje, tak proč se tím trápit?

Takže pokud vytvořím dialekt existujícího jazyka, který bude někde na úrovni Ostrajava nebo překladů C do češtiny hromadou #define, a svoláváním „focus groups“ cíleně vyšlechtím takovou syntaxi, která bude nejefektivnější z hlediska rychlosti zápisu, tak je možné, že bude abstraktnější než ten původní jazyk?

Ne. Neplatí to tak, že co je efektivní, je zároveň i abstraktní. Jen že co je abstraktní bývá často efektivní.

Je těsnopis abstraktnější než normální písmo?

Například jazyk je abstraktní, protože skoro všechno v něm má několik významů, sarkasmů, ironií a kde čeho a běžně se k nim neuvádějí jejich definice. Ty se předpokládají že má člověk v hlavě, nebo je pochytí z kontextu. Díky tomu se můžou lidi domlouvat krátkými modulovanými skřeky a stavět na tom civilizaci.

Těsnopis může být abstraktnější než normální písmo, pokud to není jen tupá substitce, ale například začneš abstrahovat celé věty, které pak zapíšeš jedním klikyhákem a jen do toho doplníš proměnné, nebo si v něm například začneš definovat slova, která ani neexistují v jazyce, který zapisuješ.

[Bherzet]

Mno, tak v něm nedělej, ne? Jako když ti něco očividně nevyhovuje, tak proč se tím trápit?

V Pythonu jsem pro některé úlohy výrazně efektivnější než např. v té Javě, ale to nemá nic společného s úrovní abstrakce.

Například jazyk je abstraktní, protože skoro všechno v něm má několik významů, sarkasmů, ironií a kde čeho a běžně se k nim neuvádějí jejich definice.

V tom ale abstrakce nespočívá. Abstrakce spočívá ve zjednodušení nebo zobecnění. Můžu říct, že jsem někam jel a soustředit se na podstatu sdělení, např. na skutečnost, že jsem viděl krávu. Je jedno odkud kam jsem jel, jaký dopravní prostředek jsem k tomu použil a jestli jsem krávu spatřil levým nebo pravým okem nebo oběma současně. Nemusím nad tím vůbec přemýšlet, a přesto se o tom můžu bavit.

Pokud při programování potřebuji provést konkrétní operaci nad konkrétními proměnnými konkrétního typu, je z hlediska abstrakce opravdu úplně, ale úplně irelevantní, jestli metodu ztělesňující danou operaci zavolám nebo nezavolám infixově a jestli může nebo nemůže obsahovat takové nebo makové znaky. To je přece úplně absurdní. 2.*(3) ve Scale není méně abstraktní než infixový zápis 2 * 3.

Co je opakem něčeho abstraktního? Něco konkrétního. Volání metod / a join je stejně konkrétní a zvolená notace na tom opravdu nic nezmění.

[Bystroushaak]

V Pythonu jsem pro některé úlohy výrazně efektivnější než např. v té Javě, ale to nemá nic společného s úrovní abstrakce.

Ale? A s čím tedy?

V tom ale abstrakce nespočívá. Abstrakce spočívá ve zjednodušení nebo zobecnění. Můžu říct, že jsem někam jel a soustředit se na podstatu sdělení, např. na skutečnost, že jsem viděl krávu. Je jedno odkud kam jsem jel, jaký dopravní prostředek jsem k tomu použil a jestli jsem krávu spatřil levým nebo pravým okem nebo oběma současně. Nemusím nad tím vůbec přemýšlet, a přesto se o tom můžu bavit.

Eh. Myslím že jsme se nepochopili, ale nezajímá mě to dost na to abych se do téhle diskuze pouštěl.

[xkucf03]

Ale? A s čím tedy?

Co třeba dostupnost knihoven nebo návodů na webu? Jsou určité domény, kde je Python velice módní a ty knihovny a návody tam existují – zatímco třeba v Javě nebo Lispu by sis je musel programovat sám. O úrovni abstrakce jednotlivých jazyků to ale nevypovídá vůbec nic.

[Bherzet]

Jo, knihovny taky.

[Bherzet]

Ale? A s čím tedy?

Prostě efektivita zápisu. Kdo umí dobře používat sed nebo awk, taky v něm jistě bude efektivnější než kdyby své filtry a příkazy zapisoval v jiném jazyce, který sice má třeba stejné možnosti, ale ukecanější syntaxi. To neznamená, že třeba Perl je nejabstraktnější jazyk.

[xkucf03]

Tak doslova to není úplně totéž, že. A pointa byla v tom že abstraktní feature je oprátor overloading jako takový. Knihovna path může vést na abstraktnější kód, není to ale nutně vždy, v tom máš pravdu.

Nepopírám, že přetěžování operátorů je (někdy) užitečné. Ale stále moc nechápu, proč máš potřebu to spojovat s úrovní abstrakce. Jestliže můžu zavolat jednu metodu, stejně jako můžu zavolat ten operátor, tak mi to přijde jako pořád ta samá úroveň abstrakce. Nebo můžu s přetíženým operátorem udělat něco, co bych s metodou/funkcí nemohl?

Dovedu si představit nízkoúrovňovou knihovnu, kde se to jen hemží přetíženými operátory, ale pracuje se tam s nízkoúrovňovými typy a implementační detaily ti tam prosakují na povrch. A dovedu si představit vysokoúrovňovou knihovnu, kde jsi od těch implementačních detailů hezky odstíněný a můžeš se souviset na svoji obchodní logiku (tzn. vyšší úroveň abstrakce), přestože se tam používají „jen“ metody.

Ono to možná bude znít hrozně, ale osobně jsem se naučil prostě kliknout na metodu a přesměrovat se na její zdroják (pycharm to umí dobře i na stdlib a tak dál), takže se prostě v těhle případech kouknu přímo na implementaci.

Pokud musíš zkoumat implementaci, abys mohl použít nějakou knihovnu, tak je něco špatně. V jazyku, nástrojích, chybějící dokumentaci…

Vyvíjet tímhle způsobem je špatné resp. neefektivní. Mezi programátory jednotlivých částí by mělo ležet rozhraní (kontrakt), za které se nemusejí dívat. A na své straně od té pomyslné zdi, si každý může dělat, co chce, a má svobodu měnit svoje implementační detaily. Pokud se musíš dívat na kód toho druhého a vyvíjíš podle něj, tak si buď zaděláváš na problémy (tvůj kód přestane v budoucnu fungovat) nebo jemu bereš svobodu měnit implementační detaily (on se bude snažit zachovat zpětnou kompatibilitu i za cenu, že to nebude efektivní nebo mu to přidělá práci).

Související pojem: clueless.

[kralyk z abclinuxu]

Nepopírám, že přetěžování operátorů je (někdy) užitečné. Ale stále moc nechápu, proč máš potřebu to spojovat s úrovní abstrakce. Jestliže můžu zavolat jednu metodu, stejně jako můžu zavolat ten operátor, tak mi to přijde jako pořád ta samá úroveň abstrakce.

No, vysvětlení, který mě napadá, je, že jazyky, který nemaj přetěžování operátorů (Java, Go,...) typicky operátory mají, ale ty operátory jsou hardcodovaný jen pro nějakou množinu jazykem definovaných typů.

Tzn. definice těch operátorů není abstraktní, ale "magická", tj. např. integer prostě má magicky vlastnost, že u něj funguje infix +.

Oproti tomu jazyky s možností definovat operátory obsahují abstraktní koncept definice operátorů, tj. sémantika opetároů je v nich zobecněná na víc než jen úzkou množinu "vyvolených" typů. Jak moc, to je otázka konkrétního jazyka. (V Haskellu to je abstrahováno ještě o třídu výš než třeba v Pythonu, C++, Rustu...)

[Bherzet]

Z hlediska programátora je ti jedno, jestli sečtení dvou čísel volá nějakou metodu, nebo je to jen pravidlo nějak uměle našroubované zvenku.

Z hlediska návrhu jazyka je čistější a elegantnější to zobecnit, to máš pravdu.

[xkucf03]

Tak samozřejmě, že samotný operátor == více abstraktní zas tak o moc není, ale já jsem zmiňoval celý operator overloading, tedy že můžeš využívat operátory pro svoje potřeby. To už abstraktní je. Například se tím dají dělat věci jako path, což je podle mého názoru hodně abstraktní věc.

V čem je to abstraktnější než volání vhodně pojmenovaných metod? Přijde mi to jen jako syntaktický cukr. Ano, může být někdy příjemný, ale že by to byla vyšší úroveň abstrakce? Tam přece záleží víc na obsahu (co člověk řeší) než na formě.

Co se týče přetěžování operátorů, nemám na to úplně vyhraněný názor. Když se použije správně, tak to může být elegantní, ale na druhé straně to zvyšuje složitost jazyka a kódu a klade vyšší nároky na programátora. Ale tak je to v podstatě se vším (anotace, generika, lambda funkce atd.).

Tohle je takové dost nicneříkající. Například lispy jsou populární právě tím, že si je různí pologéniové přiohnout ke svému obrazu a pak jsou v nich absurdně efektivní, až na to že ten kód už nikdy nikdo nepochopí a je nekompatibilní s úplně celým zbytkem světa.

+1

Podobně na tom může být C++, když to někdo přežene se šablonami, přetěžováním operátorů atd. Oproti tomu omezenější jazyky jako Java ti nedávají tolik prostoru ke „kreativitě“ a nutí tě psát standardní kód, kterému budou ostatní rozumět. Chápu, že ne každému to vyhovuje a přijde mu to třeba moc omezující, ale pro týmovou spolupráci a podnikový software je to správná volba.

[Fluttershy, yay!]

Oproti tomu omezenější jazyky jako Java ti nedávají tolik prostoru ke „kreativitě“ a nutí tě psát standardní kód, kterému budou ostatní rozumět. Chápu, že ne každému to vyhovuje a přijde mu to třeba moc omezující, ale pro týmovou spolupráci a podnikový software je to správná volba.

Where Did Software Go Wrong?

[xkucf03]

Kolibáčobot náhodně sypající odkazy… Jestli k tomu sám nemáš co říct, tak raději neříkej nic.

[Fluttershy, yay!]

Tak náhodně, že se náhodou trefil k tématu. Co je pravděpodobnější?

[kralyk z abclinuxu]

No jo, ok, ale je dobrý - určitě vzhledem k tomu, že ten text je celkem dlouhej - zmínit (klidně krátce), čím je to k diskusi relevantní...

[Bherzet]

+1

[Fluttershy, yay!]

Ale už ve třetím odstavci se píše

It is impossible to separate software from the human and historical context that it is situated in. Code is always addressed to someone. As Structure and Interpretation of Computer Programs puts it, “programs must be written for people to read, and only incidentally for machines to execute” (Abelson et al. 1996). We do not write code for our computers, but rather we write it for humans to read and use. And even the purest, most theoretical and impractical computer science research has as its aim to provoke new patterns of thought in human readers and scholars—and these are formulated using the human-constructed tools of mathematics, language, and code.

Zbytek to rozvíjí. Ono to hlavně vyžaduje víc se zamyslet.

Pokud bych z toho měl extrahovat nějaký úryvek, pak

Here we see the way in which voices mediate our action—how does Go mediate the way in which we write and think about code? Jussi Pakkanen, creator of the Meson build system, called the mediating aspect of voices shepherding: “It’s not what programming languages do, it’s what they shepherd you to.” Shepherding, or mediational means, are “an invisible property of a programming language and its ecosystem that drives people into solving problems in ways that are natural for the programming language itself rather than ways that are considered ‘better’ in some sense” (Pakkanen 2020). We internalize the voices of our social relations, and these voices mediate or shepherd our action. Every time we dive into a codebase, speak with a mentor, take a course, or watch a conference talk, we are deliberately adding new voices to the little bag of voices in our mind. This is not purely a process of consumption: in internalizing voices, we form counter-words, mentally argue with them, and ventriloquize them through our own work—in a word, we engage in a dialogue.

[kralyk z abclinuxu]

Oproti tomu omezenější jazyky jako Java ti nedávají tolik prostoru ke „kreativitě“ a nutí tě psát standardní kód, kterému budou ostatní rozumět.

Hm, tohle je takovej věčnej argument Javistů a nově taky Gočkařů (z nichž část odsuzuje z tohohle důvodu dokonce i generika), ale přijde mi, že v praxi to nefunguje. Specielně v tý Javě se vývojáři sice nemůžou vyřádit (tolik) s třeba šablonama, operator overloadingem nebo podobně, ale o to víc se rádi vyřádí s šílenými OOP hiearchiemi, přeabstrahovanými interfacy a návrhovými vzory. Z toho pak vznikaj hromady abstraktních továren, singletonů, visitorů, bridgů, proxy objektů, fasád a dalších šíleností. A specielně podnikový software mi přijde se v tomhle celkem vyžívá. Je to všechno jen ne jednoduché. Tím nechci říct, že návrhový vzory by se vůbec neměly používat, jde mi o to, že to chce nějakou rozumnou míru, kterou v Javě často vývojáři absolutně nedodržujou a návrhovzorujou do bezvědomí.

No takže suma sumárum můj dojem je, že s kreativitou programátorů se na úrovni jazyka nic moc nedá dělat...

[JS1]

Tím nechci říct, že návrhový vzory by se vůbec neměly používat, jde mi o to, že to chce nějakou rozumnou míru

Souhlasim s tebou. Ale podle me by se nemely pouzivat vubec. Podle me zakladni vada myslenky "navrhovych vzoru" je v tom, ze - narozdil od jinych abstrakci - se proste neobtezujeme pocitaci vysvetlit, jak ten navrhovy vzor vypada.

Definovat funkci (nebo proceduru) znamena pocitac neco naucit (coz je neco, co me fascinovalo ve 3.tride, kdy jsem se zacal ucit Karel jako jeden z prvnich programovacich jazyku, a definoval funkci "vlevo vbok" jako posloupnost 3x "vpravo vbok"). Zavolat funkci je pak vlastne jako pocitaci vysvetlit "vzpomen si, jak jsem te naucil f(x), a udelej to". Funkce jsou v programovani hlavni mechanismus, ktery mame pro vytvareni abstrakci (a matematicky se pak da ukazat, ze staci jako jediny - viz lambda kalkulus).

Navrhove vzory tuhle vlastnost nemaji. Mozna to jsou abstrakce, ale ty zustavaji v mozku programatora. Pocitaci nevysvetlime, co je tou abstrakci, ktera se skryva za prislusnym navrhovym vzorem. A protoze pro nas jako pro programatora ten pocitac neni partnerem, vysledny kod se vzory je mene citelny. Takze napriklad ja bych mohl mit navrhovy vzor v jazyce Karel, pokud chces udelat to same zrcadlove, napis vsude 3x vpravo vbok, kde je 1x vpravo vbok. To je sice uzitecna pomucka, ale prakticky dost necitelna. Kdyz uvidim blok kodu s timto navrhovym vzorem, budu si muset vybavit, ze nekdo pouzil tento vzor, a snazi se provest symetrickou operaci. Zatimco pokud si definuji funkci "vlevo vbok" a vzorem pak bude, zavolej "vlevo vbok" misto "vpravo vbok", pak bude mnohem jasnejsi, co jsem chtel rict. (Muzeme to pak jeste zobecnit a definovat funkci vyssiho radu "zrcadleni", ktera to nahrazeni provede sama od sebe, a tim se vzor zcela zaobali do funkcni abstrakce.)

Pointa je, ze ty funkce, ktere definuji tu abstrakci, jsou neco, cemu pocitac rozumi. Muzeme si napriklad nechat zjistit, v jakem kontextu se dana funkce (abstrakce) pouziva, coz jde u vzoru velmi tezko. (Navrhovy vzor je asi jako dvojsmysl v mezilidske komunikaci - nerikame primo, co si myslime, a doufame, ze to druha strana - programator co to po nas bude cist - pochopi tak, jak jsme zamysleli.)

Shrnuto, pokud maji byt navrhove vzory uzitecnym jazykem, v kterem komunikujeme jako programatori, musi pocitac tomu jazyku porozumet. A to se stane jen tak, ze je zahrneme do nejake abstrakce, ale v ten moment se z nich (typicky) stanou "jen" knihovni funkce, prestanou byt "vzorem".

[Bherzet]

O tom návrhové vzory nejsou. Podělím se o konkrétní příklad, kde jsem použil továrnu.

Byla jednou jedna třída a v té si žila jedna malá, ale důležitá metoda, která něco dělala. A dělala moc složité věci, milí programátoři! Tak složité, že by bylo tuze nepraktické dělat je v té metodě přímo. :o A tak si na pomoc zvala úplně novou instanci jiného objektu, kterou si k tomuto účelu sama vytvářela.

A pak přišel čas na jednotkové testování. A najednou byl problémeček! Vůbec nebylo zjevňoučké, jak otestovat jen přidanou hodnotu této metůdky, a ne znovu testovat i vše, co dělá ten druhý objekt. :o

A pak přišel pan továrník a postavil továrnu, která ten objekt pro metůdku vyráběla, a v testu postavil druhou továrnu, která tam posílala nějaké namockované objekty, a všichni byli tuze spokojení. A jestli se neutovárnovali, tak tam továrnují dodnes!

(Ve světě funkcí: funkce f dostává funkci g jako argument místo aby ji volala přímo. Stejný problém, principielně stejné řešení. V Javě to znamenalo prostě přidat továrnu jako field, inicializovat lambdou/anonymní třídou na return new RealObject(…), v oné metodě místo new RealObject(…) volat factory.newInstance(…) a v testu si tam poslat jinou vlastní továrnu, která vytváří jiný objekt. Cca 5 řádků kódu navíc.)

[JS1]

Vubec nechapu pointu tvoji polemiky. Zrovna tovarna je dobry priklad zbytecneho navrhoveho vzoru. Pridat si argument do funkce prece neni tezke.

[Bherzet]

Pointa byla, že přidat si argument do funkce je použití toho návrhového vzoru. Tady jediný rozdíl byl v tom, že jsem to nechtěl mít v argumentu přímo té funkce (metody), ale funkce, která ji produkuje (třída, ve které se nachází), abych ty argumenty nemusel předávat pokaždé znovu.

[JS1]

Mozna jsem se spatne vyjadril. Kdyz jsem napsal "navrhove vzory by se nemely pouzivat vubec", tak jsem myslel obecne v programovani. Je samozrejme mozne, ze tvuj konkretni jazyk (Java) nema dostatecne vyrazove prostredky, jak se nekterym vzorum vyhnout, a pak je to zel nevyhnutelne (asi jako v tom assembleru), lec neprehledne.

Myslim, ze to bezdecne vystihl Bystroushaak, kdyz ti napsal, zkus si to v nejakem ciste funkcionalnim jazyce. (Mimochodem, tesi me, ze dal na moji radu a jal se funkcionalni programovani vice studovat.)

Jde o to, ze alternativy z funkcionalnich jazyku vrhaji dost pochybnosti na tovarnu jako uzitecny navrhovy vzor. Bud jsou ty uziti trivialni, nebo dusledkem spatneho navrhu, nebo absenci schopnosti Javy zachazet s funkcemi.

Pokud ma byt smyslem vzoru lepsi komunikace, pak neni vubec jasne, co je v tvem pripade komunikovano a proc. Ze se nechces predavat s argumentem? Ve funkcionalnich jazycich, co znaji currying, je to jasne hned, nepotrebujes ten vzor.

Ale to je asi moje druha vytka v rade vetsine navrhovych vzoru, ze je to terminologie navic, ktera casto vice zamlzuje nez osvetluje. Myslim, ze by jsi byl schopen slovy popsat, co delas, i bez pouziti slova tovarna, a vyslo by to kratsi a citelnejsi. Asi jako ten operator "/" na cestach, o kterem jsme se bavili vys.

[Bherzet]

Je samozrejme mozne, ze tvuj konkretni jazyk (Java) nema dostatecne vyrazove prostredky, jak se nekterym vzorum vyhnout, a pak je to zel nevyhnutelne (asi jako v tom assembleru), lec neprehledne.

Prostě jednou potřebuju vytvářet takové objekty, jindy makové, tak je vytvářím nepřímo nějakou funkcí, kterou si vytáhnu někam do argumentů. Dtto kdybych potřeboval volat různé funkce (a ne vytvářet objekty). Jak bys to dělal jinak?

Myslim, ze to bezdecne vystihl Bystroushaak, kdyz ti napsal, zkus si to v nejakem ciste funkcionalnim jazyce.

V průběhu let jsem okrajově koketoval s LISPem, Haskellem, Scalou a nejčerstvěji Erlangem. Myslím si, že jsem s principy funkcionálního programování dobře obeznámen, byť věci jako monády a teorie typů jsou pro mě velkou neznámou a mám v úmyslu se k tomu vrátit.

Bud jsou ty uziti trivialni, nebo dusledkem spatneho navrhu, nebo absenci schopnosti Javy zachazet s funkcemi.

Pokud jsou triviální, tak už se jim nesmí říkat návrhové vzory?

Jinak Java de facto má high-order funkce a i před jejich zavedením v roce 2014 šlo programovat podobně, jen ten kód byl hnusnější a delší.

Ze se nechces predavat s argumentem?

Ale já ho předávám. Považuji za podružný detail, že ho předávám o scope výše. Klidně bych to mohl posílat té metodě přímo a pořád bych mluvil o továrně.

Myslim, ze by jsi byl schopen slovy popsat, co delas, i bez pouziti slova tovarna, a vyslo by to kratsi a citelnejsi.

Praktické zkušenosti z práce, kde návrhové vzory mimochodem nebyly nijak populární a používaly se extrémně střídmě (čti: správně), svědčí o opaku.

[kralyk z abclinuxu]

Ale to je asi moje druha vytka v rade vetsine navrhovych vzoru, ze je to terminologie navic, ktera casto vice zamlzuje nez osvetluje. Myslim, ze by jsi byl schopen slovy popsat, co delas, i bez pouziti slova tovarna, a vyslo by to kratsi a citelnejsi. Asi jako ten operator "/" na cestach, o kterem jsme se bavili vys.

+1

Tvůj původní komentář + tohle je velmi dobrá suma důvodů, proč návrhové vzory jsou z většiny šum.

Bherzet zřejmě není dostatečně kovaný javista, kdyby byl, tak by v tom příkladu výše popsal nejenom že používá TOvárNU, ale taky DepeNDenCY INjeCTion / INverSIoN oF COntrOL a možná ještě nějakou další vatu...

[Bherzet]

Dependency injection samozřejmě používám a než jsem napsal pár hovnokódů a s tím patternem se seznámil, fakt mi to nepřišlo zjevné. Těmi zkušenostmi bych si musel projít stejně, samotná znalost patternu samospásná není, ale je dobré ten problém umět pojmenovat, domluvit se na nějaké štábní kultuře atp. Říct, že závislosti předáváme přes settery, je určitě úspornější než to obšírně vysvětlovat.

Mně přijde, že tu lidi jsou buď strašně otrávení, což chápu, protože – na rovinu – po celém dni programování v práci si člověk prostě chce spíš hrát s něčím pěkným a mít z toho kódu radost a ne řešit „korporátní hovna“, a nebo měli smůlu na totální idioty, kterým návrhové vzory nacpali do hlavy na VŠ, ale protože neměli žádné zkušenosti, cpali to všude úplně nesmyslně hlava nehlava. Což se bohužel děje, ale to není vina těch patternů.

[kralyk z abclinuxu]

a nebo měli smůlu na totální idioty, kterým návrhové vzory nacpali do hlavy na VŠ, ale protože neměli žádné zkušenosti, cpali to všude úplně nesmyslně hlava nehlava. Což se bohužel děje, ale to není vina těch patternů.

Z mýho pohledu, oboje. Vina patternů jako takových to určitě není.

IMO vina je především v kultuře okolo Javy. Ale říct nějak konkrétně, přesně, formálně, v čem přesně je ten problém, to mi nejde. Ono totiž ostatní jazyky, i když jsou třeba těžce abstraktní, taky mají něco jako patterny. Z Javy si člověk může dělat srandu kvůli AbstractFactoryVisitorSingletonům, z Haskellu zase kvůli Zygohistomorfickým prepromorfismům že Ale jinak třeba currying nebo monády jsou taky v zásadě patterny...

IMO ty problémy, které nejsou sice speficiký pro Java kulturu, ale jsou v ní silný, jsou:

• Označení patternů je vymyšlený tak, aby se líbilo manažerům a/nebo lidem, co programování znaj jen částečně. Říct "zrefaktoroval jsem to tak, že tu věc instancuje objekt poslaný zvenku" prostě zdaleka není tak cool, jako říct "přešel jsem na řešení využívající továrnu, která je dependency-injektována pomocí setteru". Při tom druhém každý manažer zvlhne a pochválí se s ostatními, jak jsou jejich vývojáři produktivní a znalí.
• Nízký obsah informace. Továrna nebo setter/getter jsou celkem triviální koncepty, rozhodně v porovnání třeba s curryingem nebo monádami.
• Design patterns občas slouží jako attire, prostě kdo je zná a umí, ten patří do klubu těch správných programátorů. Pokud si myslíš, že přehánim, tak ne, fakt jsou lidi, kteří jsou schopni posuzovat programátoský schopnosti někoho podle toho, jestli má nabiflovaný patterny.

[Bherzet]

Nevím. Pro mě je to prostě o znalosti, jak řešit určité problémy, a o terminologii pro usnadnění komunikace, abych se nevyjadřoval jako tatar. Např. dependency injection se často používá v kombinaci s nějakým frameworkem, které jsou sice taky jakože fuj, ale reálně to dokáže ušetřit kód a že holt občas to někdo přežene a pak tráví půlku pracovní doby debugováním svých obřích XML konfiguráků je asi tak relevantní jako si v diskuzi o tom, jestli cikání můžou být normální, stěžovat, že někomu ukradli kolo, a je dobré mít výrazový prostředek pro to, že framework předává závislost metodě (injektuje do setteru). Ony se ty slova jinak dost opakují a tohle to občas dost usnadní. Vysloveně stěžejní to není, zkušenosti to nenahradí a pro poměřování pindíků to není úplně nejrelevantnější metrika, protože každý, kdo umí programovat, kterýkoliv běžný pattern pochopí za 3,5 vteřiny, ale svůj smysl to má.

Jsou to v podstatě best-practices a i zkušený programátor může objevit nový pattern, který mu umožní dát jeho kódu lepší štábní kulturu. Osobně jsem třeba rád, že listenery se v Javě jmenují prostě listenery a až na vesměs odůvodnělé výjimky si lidi nevytváří vlastní názvosloví, byť chápu, že ty endorfiny a radost ze sexy elegantního kreativního kódu už tam pak prostě nejsou.

[kralyk z abclinuxu]

a je dobré mít výrazový prostředek pro to, že framework předává závislost metodě (injektuje do setteru)

No, mě právě zatím nikdo moc nepřesvědčil, že to fakt dobré je (resp. vidim to tak, že asi z 20% max)...

protože každý, kdo umí programovat, kterýkoliv běžný pattern pochopí za 3,5 vteřiny, ale svůj smysl to má

Jestli dokážeš libovolnému javistovi (apod., ono třeba u c/c++ to nebude o moc jinak) vysvětlit monádu (i s implikacemi) tak, aby to pochopil za 3.5 sekundy, tak bys měl dostat nějakou cenu za pedagogiku

Osobně jsem třeba rád, že listenery se v Javě jmenují prostě listenery a až na vesměs odůvodnělé výjimky si lidi nevytváří vlastní názvosloví

Meeeeeh. Asi by mě nemohlo zajímat míň, jestli se tomu říká "listener" nebo "handler" nebo nějak jinak. Beztak je to stejně nejspíš zas jen glorifikovaná lambda...

[Bherzet]

No, mě právě zatím nikdo moc nepřesvědčil, že to fakt dobré je (resp. vidim to tak, že asi z 20% max)...

Whatever. Každopádně k tomu jsou ty patterny určené a přesně tak je používám.

Jestli dokážeš libovolnému javistovi (apod., ono třeba u c/c++ to nebude o moc jinak) vysvětlit monádu (i s implikacemi) tak, aby to pochopil za 3.5 sekundy, tak bys měl dostat nějakou cenu za pedagogiku

Nedokážu, ale monáda úplně nepatří mezi patterny, které jsem měl na mysli. OK, špatně jsem ten výčet zúžil.

Asi by mě nemohlo zajímat míň, jestli se tomu říká "listener" nebo "handler" nebo nějak jinak.

Handler není úplně špatný název, ale přesto je lepší mít ty názvy jednotně. Já ten kód taky budu číst, možná budu používat našeptávání v IDE nebo něco grepovat. Je ustálené tomu v určitých kontextech říkat listener a klást na ostatní (a později i sebe samého) pasti v podobě náhodně pozměněného názvosloví se těžce racionálně obhajuje, zvlášť je-li daný adept s tím názvoslovím seznámen. Podobné záchvaty kreativity jsou jednou z nejzákeřnějších věcí, jaké lze na projektu provádět.

Beztak je to stejně nejspíš zas jen glorifikovaná lambda...

Začalo se to používat v době, kdy si Java o lambdách mohla nechat zdát. Lambdou je možné implementovat jen listenery s právě jednou metodou.

[xkucf03]

IMO vina je především v kultuře okolo Javy.

Nejvtipnější je, že tohle nejvíc prožívají lidi, kteří v Javě neprogramují a nemuseli by se nějakou javovskou kulturou vůbec trápit :-)

[Bherzet]

Já to na druhou stranu chápu. Já taky nedělám v JavaScriptu a když vidím, co páchají za zvěrstva na nevinných počítačích, dělá se mi nevolno.

Jinak JS1 i oryctolagus v Javě AFAIK občas dělají.

[kralyk z abclinuxu]

No, tak to je spíš důsledek... Jinak bez zkušenosti s Javou nejsem, dělal jsem dřív i nějakou Javu v rámci zaměstnání (byť teda ne moc).

Jinak zkoušels už Kotlin?

[xkucf03]

Označení patternů je vymyšlený tak, aby se líbilo manažerům a/nebo lidem, co programování znaj jen částečně. Říct "zrefaktoroval jsem to tak, že tu věc instancuje objekt poslaný zvenku" prostě zdaleka není tak cool, jako říct "přešel jsem na řešení využívající továrnu, která je dependency-injektována pomocí setteru". Při tom druhém každý manažer zvlhne a pochválí se s ostatními, jak jsou jejich vývojáři produktivní a znalí.

Potkal jsem v různých firmách už hodně manažerů, ale co jsou to návrhové vzory, věděl asi tak jeden¹ nebo dva. Projektové² manažery tyhle implementační detaily nezajímají, snad neřeknu nic moc důvěrného, ale oni nevnímají konkrétní slova a konkrétní problémy, i když se to před nimi probírá na poradě, je to pro ně jen šum, ale vnímají (více či méně) dobře různé neverbální a podprahové signály a dokáží vycítit, jestli je dotyčný na dobré cestě (tzn. bude to hotové včas nebo s akceptovatelným zpožděním) nebo zda je dotyčný v koncích a neví kudy kam (dodání je v nedohlednu a manažer to bude muset vysvětlovat zákazníkovi). Jestli budeš používat odborné termity nebo tomu budeš říkat familiárně a s humorem třeba šelmostroj, je celkem jedno.

Nízký obsah informace. Továrna nebo setter/getter jsou celkem triviální koncepty

Těch návrhových vzorů je mnohem víc, továrna patří k těm jednodušším. Ale nikdo netvrdil, že návrhové vzory jsou nějaká raketová věda. To snad ale ty koncepty nediskvalifikuje natolik, aby nemohly mít vlastní název.

prostě kdo je zná a umí, ten patří do klubu těch správných programátorů. Pokud si myslíš, že přehánim, tak ne, fakt jsou lidi, kteří jsou schopni posuzovat programátoský schopnosti někoho podle toho, jestli má nabiflovaný patterny

S tímhle se dá asi celkem souhlasit. Tohle taky nemám rád. Ale to je obecně o lidském přístupu – jestli jednáš s ostatními přátelsky a konstruktivně nebo se chceš na ně vytahovat a shazovat je. Taky jsem zažil některé dost nesnesitelné programátory.

(předpokládám, že mluvíš o osobním kontaktu – při tom vzdáleném a textovém může působit jako namyšlený kretén každý druhý, to si člověk nesmí tak brát :-)

_{[1] bývalý programátor resp. dělal projekťáka a zároveň s tím pořád programoval
[2] ty vyšší to nezajímá už vůbec}

[kralyk z abclinuxu]

Taky jsem zažil některé dost nesnesitelné programátory.

předpokládám, že mluvíš o osobním kontaktu

Jo. Je možný, že jsem měl prostě jen smůlu... To asi nemůžu úplně vyloučit.

[xkucf03]

ale taky DepeNDenCY INjeCTion / INverSIoN oF COntrOL a možná ještě nějakou další vatu...

Kéž by se tuhle „vatu“ naučilo používat víc programátorů. Stromy závislostí by pak nemusely být tak pekelné.

[kralyk z abclinuxu]

Kéž by se tuhle „vatu“ naučilo používat víc programátorů.

Tou "vatou" myslim něco jinýho, než ten princip, který je pod tim (a který může opravdu bejt užitečnej).

Stromy závislostí by pak nemusely být tak pekelné.

Tomu moc nerozumim - ty řešení, co tam popisuješ, ten strom naopak zvětšují (přibývaj tam různý adaptéry atd.), ne? A specielně třeba relační roury jsou, relativně k vlastnímu kódu, který něco dělá, jeden z nejsložitěji strukturovaných projektů, co znám...

[JS1]

ty řešení, co tam popisuješ, ten strom naopak zvětšují (přibývaj tam různý adaptéry atd.), ne?

Tohle mi vadi taky, to pridavani veci, aby se to pry zjednodusilo a zprehlednilo. Jde to proti Occamove britve. A ty navrhove vzory casto slouzi k obhajobe takoveho pristupu.

Ja chapu, ze se lide pokousi psat snadno udrzovatelny kod. Ale fundamentalne prave myslim, ze porusenim Occamovy britvy k tomu nepovede, naopak.

Mam proste rad DRY KISS.

[xkucf03]

Chápu, že je to dlouhé¹, ale když budeš mít někdy čas, tak si to zkus přečíst celé. Těmto otázkám se tam věnuji, i tomu, že přidání kódu (navýšení komplexity) na jednom místě může vést k většímu snížení komplexity někde jinde a tím pádem celku.

_{[1] i když knihy jsou řádově delší a lidi je taky čtou}

[JS1]

Asi by bylo lepsi vzit si konkretni priklad. Driv jsem si taky myslel, ze to uplne vzdycky nejde, snizit jak slozitost i mnozstvi kodu, ale od doby co jsem se naucil trochu funkcionalne v Haskellu si to nedovedu predstavit. A stal jsem se obhajcem DRY.

Samozrejme, neco jineho je napsat veci mene abstraktne proste proto, aby to bylo jednodussi na cteni. To je ale jina situace nez kterou resi patterny; muzeme se pak bavit o tom, kolika radkum kodu odpovida jedna indirekce, za ucelem citelnosti.

[xkucf03]

Bohužel ani nevím, na co reaguješ. Zkus citovat z toho článku, s čím polemizuješ.

[JS1]

Rikam, ze by to chtelo ukazat na konkretnim priklade, proc podle tebe ma smysl, aby velikost kodu narostla za ucelem zjednoduseni cele veci.

Treba ted mi tady kolega udelal jednu vec (podobnou jak pise Bherzet) kvuli testovani - vyrobil tridu, ktera vola vsechno to, co uz implementuje jina trida, akorat ma interface, takze se da mockovat. Takze novy kod - spousta funkci, ktere jen volaji tu samou funkci nekde jinde, proste indirekce. A pak pouzil DI s tou novou tridou, a tak dale.

Vsechno kvuli tomu, ze v Jave nemohu priradit interface existujici tride. V Haskellu by se tohle vyresilo snaz - proste bych udelal typovou tridu a definoval bych tu existujici tridu jako jeji instanci. (A vlastne by se to ani delat nemuselo, protoze cela ta zalezitost pro kterou jsme to delali tady by se dala v Haskellu vyresit jeste mnohem jednoduseji.)

Tim chci ukazat, ze treba takova uzitecna blbost, kterou Java neumi - priradit novy interface existujici tride - zpusobuje, ze se lidi mnohem vic nadrou (a potrebuji DI). Pritom neni hned zrejme, ze by bylo uzitecne, aby to jazyk umel, a ze to neprinasi zadnou nevyhodu.

(A proto je tak dulezite ty "vzory" formalne matematicky zkoumat, protoze v tom formalnim zkoumani se odpovi na podobne otazky.)

[xkucf03]

Jak jsem psal výše, chce si to přečíst ten článek. Jsou tam i konkrétní příklady.

[xkucf03]

P.S. S Javou to nemá nic společného, ty příklady jsou v Céčku – schválně, aby bylo jasně vidět, že k tomu žádný zvláštní jazyk nepotřebuješ. Tohle je otázka návrhu/architektury, ne konkrétního jazyka a implementačních detailů.

[kralyk z abclinuxu]

Tohle je otázka návrhu/architektury, ne konkrétního jazyka a implementačních detailů.

Jenže vlastnosti jazyka celkem hodně ovlivňujou architekturu.

[kralyk z abclinuxu]

V Javě máš nějakou architekturu. V C++ bude o něco jiná (ačkoli Java architektura se tam dá trochu emulovat, viděl jsem takové pokusy v raných relpipes). V Rustu by byla jiná podobným způsobem jako v C++, ale ještě o něco dál a směrem k ML. V Haskellu by byla masivně jiná.

IMO tvoje znalosti ohledně architektury jsou Javou ovlivněné o dost víc, než si uvědomuješ...

[xkucf03]

Opravdu doporučuji se podívat na ty příklady z praxe, ať máš představu, o čem mluvím.

Jde o úplně obecné principy, které lze implementovat v libovolném jazyce (zrovna ty příklady jsou všechny v C), s Javou to nemá nic společného.

[kralyk z abclinuxu]

Opravdu doporučuji se podívat na ty příklady z praxe, ať máš představu, o čem mluvím.

Uhh... Já to četl. Myslel jsem si, že se v podvlákně bavíme o DI/IoC (jako sub-počátek beru #543). DI/IoC je IMO o architektuře kódu. To, co tam popisuješ ohledně toho Postfixu et al. je prostě modulární/plugin architektura software. Nevim, jestli došlo ve vlákně k nedorozumění, nebo jestli plugin architektuře říkáš DI/IoC. Pokud to druhé, tak samozřejmě ti to nemůžu a nebudu brát, ale z mého pohledu to je přesně instance kontrafibulace.

Co se týče modulární architektury, odpověděl bych na tuhle otázku:

Někteří lidé jsou až posedlí čísly 80 a 20 a snaží se je napasovat na všechno. Já nebudu tvrdit, že 80 % uživatelů používá 20 % funkcí softwaru (a každý jiných 20 %). Ta čísla se budou případ od případu lišit, nicméně pravda je taková, že ne všichni uživatelé používají všechny funkce. Proč by tedy měli být zatěžováni (nebo dokonce ohrožováni v případě bezpečnostních chyb) komplexitou částí, které nepoužívají?

Odpověď je: Protože to je jednodušší pro uživatele i programátora a nemusí to vůbec ničemu vadit. Tvoje námitky proti monolitické architektuře jsou z mého pohledu vesměs slabé. Co se týče té bezpečnosti, očekávám, že software jako Postfix bude napsaný tak, že části, který nejsou nakonfigurovaný, se nebudou spouštět. A i kdyby autoři vyhodnotili, že je to rizikové, můžou tu modularizaci provést interně (tj. nemuset stabilizovat a exponovat plugin API). Tím nechci říct, že by Postfix měl být monolitický. Ta jejich architektura mi celkem dává smysl a souhlasim, že to je celkem pěkný. Ale nepovažuju to (zřejmě narozdíl od tebe) za Jedinou Správnou Cestu. Takováhle architektura má nezanedbatelnou režii pro programátora, pro maintainery balíčků i pro uživatele. IMO není možný tohle prezentovat jako univerzální řešení vhodné pro software obecně. Může to dávat smysl a nemusí. Osobně by mi nejspíš nijak nevadilo, kdyby ta věc byla monolitická nebo o něco monolitičtější.

Přijde mi, že prosazuješ modularizaci do úplného bezvědomí i tam, kde to nepřináší prakticky žádný výhody (nebo jen teoreticky).

[xkucf03]

Tvoje námitky proti monolitické architektuře jsou z mého pohledu vesměs slabé. Co se týče té bezpečnosti, očekávám, že software jako Postfix bude napsaný tak, že části, který nejsou nakonfigurovaný, se nebudou spouštět.

To jen doufáš. Jistotu ale nemáš a navíc se to může kdykoli změnit, aniž by sis toho všiml. Stačí chyba (nebo záměr) na jediném řádku a najednou se to začne chovat úplně jinak. Na druhé straně tu máš koncepty jako formální verifikace¹ (často adorované právě přívrženci funkcionální víry). To je trochu extrém, ke kterému se většina softwaru nikdy nedopracuje (ani to není potřeba), ale to, co říkám já – tzn. nepřibalovat k softwaru nepotřebné nesmysly, které nepoužíváš – to je takový dobrý základ, kterým se dá začít. A myslím si, že by to měla být běžná praxe i pro takový ten řádový „konzumní“ software. Jestli to pak posuneš dál a budeš to nějak matematicky/formálně ověřovat, to už je na tobě – ale osekat ty nepoužívané části je víceméně podmínka nutná. Jinak bys taky mohl verifikovat až do skonání světa a nikdy by ses nedobral konce.

_{[1] BTW: co říkáš na seL4?}

[kralyk z abclinuxu]

To jen doufáš. Jistotu ale nemáš a navíc se to může kdykoli změnit, aniž by sis toho všiml. Stačí chyba (nebo záměr) na jediném řádku a najednou se to začne chovat úplně jinak.

Ano, chyba (nebo zlý záměr) se samozřejmě může kdykoli objevit. To se stává.

[xkucf03]

Ani moc ne – z toho pohledu, o kterém mluvím (na úrovni modulů nebo spolupracujících systémů) na programovacím jazyce nezáleží, je to víceméně nepodstatný implementační detail.

Asi s JS1 mluvíte o jiném DI resp. o jiné úrovni a utápíte se v detailech na úrovni nějakých interních tříd + do toho promítáte nějaké osobní křivdy (kdy vás někdo šikanoval s tím, že máte mít v nějaké interní třídě setter místo přímého volání konstruktoru atd.). Neříkám, že na tomhle úplně nezáleží, i tohle se dá dělat lépe nebo hůře, ale z pohledu toho seriálu o komplexitě a toho DI/IoC, o kterém tu mluvím, je tohle nedůležité.

Možná narážíte i na tenhle problém:

Dalším důvodem, proč dochází k navýšení komplexity je paradoxně snaha ušetřit si práci. A nemluvím tu o nějaké lenosti, kdy vývojář vynechá nějaké kroky nebo něco zanedbá. Mluvím o situaci, kdy vývojář naopak něco přidává – s dobrým úmyslem, že to ušetří práci.

Tohle je citace z druhého dílu, který jste ale asi nečetli.

Ano, jsou různé detaily, kdy vývojáři s dobrým úmyslem něco přidávají ale navenek to nemá žádný efekt a akorát to zvyšuje komplexitu toho kódu uvnitř. Taky tam píšu, že se má rozlišovat interní rozhraní a externí API:

Z hlediska komplexity je tedy dobré u interních rozhraní psát kódu co nejméně a nepouštět se do žádných velkých akcí – to může jít i proti různým doporučením ohledně správného objektového návrhu. Např. místo pěti tříd můžeme napsat dvě metody, které se dohromady vejdou na jednu obrazovku. Mnoho abstrakcí zde můžeme vynechat, můžeme chodit zkratkami…

U veřejných rozhraní bychom si naopak na správném návrhu měli dát záležet – a to i za cenu toho, že kódu bude víc. Veřejná rozhraní zasluhují nejvíce úsilí a pečlivosti…

Nicméně tenhle seriál jsem psal mj. proto, abych nemusel vést pořád dokola ty samé diskuse – v zásadě všechny odpovědi na tyhle otázky tam jsou. Pokud máš k něčemu připomínky, tak ocituj příslušnou část a rád ti odpovím.

[JS1]

Asi s JS1 mluvíte o jiném DI resp. o jiné úrovni a utápíte se v detailech na úrovni nějakých interních tříd

Nevim, na jake jine urovni bychom o tom meli mluvit, kdyz ty (puvodni) patterny jsou definovane na urovni trid. To, co rozebiras v tech svych clancich je trochu jina diskuse, o zavislostech mezi knihovnami a moduly. Tady by se Java IMHO taky dala vylepsit, treba v Haskellu lze u kazdeho modulu explicitne rict, ktere funkce a datove typy z nej chceme externalizovat (a jsou tedy soucasti rozhrani). V Jave se to v ramci package dela dost nesikovne.

do toho promítáte nějaké osobní křivdy

Ah, to je klasicky argument typu "jsi ateista, tedy mas spatnou zkusenost s Jezisem". Nejde o to, jestli me nekdo takto sikanoval, nebo ne, ale o to, jestli to ma smysl delat nebo ne. Ja proste nechci delat veci, protoze mi to nekdo rekl, ale chci rozumet tomu, proc je ma smysl delat. A plati to i naopak - to ze me nekdo k necemu nekdy nutil jeste neznamena, ze ta vec je spatna.

[xkucf03]

Nevim, na jake jine urovni bychom o tom meli mluvit, kdyz ty (puvodni) patterny jsou definovane na urovni trid. To, co rozebiras v tech svych clancich je trochu jina diskuse, o zavislostech mezi knihovnami a moduly.

Třídy jsou pouze prostředek, jak dosáhnout nějakého řešení/návrhu. Smyslem je ale to, abys mohl mít např. databázový ovladač nezávislý na aplikaci a mohl spojení do konkrétní DB do aplikace injektovat (nebo ho v ní vyhledat nějakým tím Service locatorem). Nebo abys mohl mít několik implementací šifrovacích knihoven, a pak si konfigurací jednu vybrat. Stejně tak lze ten princip využít na úrovni byznys logiky. Obecně jde o nějaké injektování nebo vyhledávání právě závislostí. Zda je to implementované formou tříd a rozhraní nebo třeba formou ukazatelů na céčkovské funkce předaných v nějaké struktuře, to je celkem nepodstatný implementační detail.

Zda tyhle principy má smysl aplikovat i v útrobách programu, v neveřejných zákoutích jeho kódu, to je otázka. Má to svoje pro a proti. V článku se tomu věnuji v kapitole Rozlišování veřejného API a interních rozhraní.

Tady by se Java IMHO taky dala vylepsit, … V Jave se to v ramci package dela dost nesikovne.

V Javě máš např. OSGi, kde krásně rozlišíš, které části mají být exportované jako veřejné API, a které tvoří neveřejnou implementaci. Možná ti vadí, že to není přímo součástí Javy a je to „jen“ nějaký framework třetí strany. Já ale považuji naopak za důkaz flexibility Javy to, že nad ní lze takový framework vytvořit, aniž by se musel měnit samotný jazyk. Nicméně od Javy 9 je přímo její součástí systém modulů a i samotná Java platforma se víc modularizuje (konečně).

Ale v zásadě se lze obejít i bez takových nadstaveb a modulárních systémů. Běžné je např. to, že uděláš dva JARy, v jednom máš jen rozhraní a v druhém jen implementaci. Ty závislosti pak vypadají takto:

[aplikace] ---> [API] <--- [implementace]

Jako uživatel toho API tedy dostaneš malý JAR obsahující pár rozhraní či tříd, typicky bez nějakého spustitelného kódu (abstraktní rozhraní), a na něj se napojíš. Jako implementátor toho rozhraní dostaneš taky toto abstraktní rozhraní a implementuješ ho.

Pokud jako programátor dostaneš za úkol implementovat modul do nějakého velkého systému, nemusíš se potýkat s jeho komplexitou a na svůj počítač si stáhneš jen to malé abstraktní API. Stejně tak, když budeš mít za úkol zavolat službu nějakého velkého systému. Od té komplexity jsi odstíněný rozhraním a místo toho velkého systému si můžeš napsat simulátor nebo vlastní implementaci, která bude výrazně jednodušší a bude řešit jen tu malou část, která tě zajímá. S komplexitou toho původního velkého systému přijde do styku jen ten, kdo se rozhodl ho provozovat a tuhle práci ti zadal – ten si pak na svém prostředí pouští integrační testy a provozuje to v produkci.

Ah, to je klasicky argument typu "jsi ateista, tedy mas spatnou zkusenost s Jezisem". Nejde o to, jestli me nekdo takto sikanoval, nebo ne, ale o to, jestli to ma smysl delat nebo ne.

Vycházím jen z toho, co tu ty a Králík píšete – historky o kontrafibulátorech nebo kolegovi, který přidává „nesmyslná“ rozhraní.

Jestli něco takového má nebo nemá smysl si netroufám hodnotit – musel bych vidět konkrétní kód a znát kontext. Obecně můžu jen připomenout tu kapitolu Rozlišování veřejného API a interních rozhraní odkázanou výše.

Co se týče jednotkových testů, tak tam záleží, jak si ten program strukturujete a jak si organizujete práci. Obecně říkám, že testy ověřují shodu implementace se zadáním. Pokud na nějaké úrovni detailu zadání definované není, tak je otázka, zda a jak to vůbec má smysl testovat. Pokud ten test toho detailu chceš mermomocí napsat, tak tě to nutí to zadání definovat, což může být dobré (nebo taky zbytečné). Stejně tak tě ten jednotkový test může donutit upravit návrh tříd, což opět může být dobré (nebo zbytečné).

[kralyk z abclinuxu]

Podivej, ty v podstatě prosazuješ Javu, v tom je jádro problému (*). Resp. javovskou architekturu, idiomy, terminologii. Argumentuješ tím, že přece to není Java, že stejné principy platí i jinde - ne neplatí a ano je to furt Java. Respektive samozřejmě můžeš psát "Javu" v jiným jazyce, což je trochu případ relational pipes. Teď jsem na to koukal a je to takový mix Javy a C++ (což je taky daný tím, že Java a C++ jsou relativně blízko, nicméně tu Javu v tom fakt vidim na některých místech dost jednoznačně, i když musim uznat, že se to od začátku zlepšilo).

Jinde platí jiné principy, jiná terminologie, jiné idiomy. Myslim si, že masivně podceňuješ, jak moc jiné to může být. Kdybys raději místo psaní blogů sáhodlouze velebících DI/IoC ten čas vrazil do naučení se nějakýho úplně jinýho jazyka, a to včetně terminologie, idiomů a principů k tomu patřících, tj. nejen jak do toho narvat Javu, tak už bychom se dávno v těch diskusích někam posunuli. Netočili bychom se stále jenom na "Tohle je propagace Javy" - "Ne není, jen říkám, že <javovský idiom XY> je zcela obecný a měl by ho používat všechen software".

(*) a taky částečně Debian-based linux.

[xkucf03]

Tak tobě musel nějaký javista fakt hodně ublížit, přebrat holku nebo tak něco :-) Jestli tyhle myšlenky odmítáš přijmout „od javisty“ tak v tom článku najdeš i citace lidí, kteří nemají s Javou vůbec nic společného, ale říkají to samé. Já k tomu pak dodávám:

Když mluvíme o abstraktních rozhraních, IoC nebo DI, může to někomu znít jako zavádění jakýchsi novot a snaha dělat věci jinak… ve skutečnosti je to ale návrat k dávným tradicím a dodržování postupů, které byly správné odjakživa.

Kromě těch klasických unixových praotců, máš pak dole v příloze i článek od Niklause Wirtha, autora Oberonu – a i ten ti k tomu řekne:

Indeed, the most demanding aspect of system design is its decomposition into modules. Each module is a part with a precisely defined interface that specifies imports and exports.

[kralyk z abclinuxu]

Tak tobě musel nějaký javista fakt hodně ublížit, přebrat holku nebo tak něco Jestli tyhle myšlenky odmítáš přijmout „od javisty“ tak v tom článku najdeš i citace lidí, kteří nemají s Javou vůbec nic společného, ale říkají to samé.

Já ale s tou myšlenkou absolutně nemám problém. Určitě existuje spousta velmi pěkného SW navrženého s touhle architekturou. Například tuším že Qt Creator je taky hodně modularizovaný (ačkoli asi jen interně, není to exponováno).

Problém mam s tím, když se tohle prosazuje za jedinou správnou cestu a všechno ostatní se prohlásí za horší. To je prostě akorát fundamentalismus.

Tohle:

ve skutečnosti je to ale návrat k dávným tradicím a dodržování postupů, které byly správné odjakživa.

je jak z nějaký náboženský příručky.

Já jsem tu myšlenku samozřejmě dávno přijal (modulární architektura opravdu není žádná novinka), ale pouze jako jednu z více různých možností jak strukturovat software, která má nějaké výhody a nevýhody. Nevim, proč bych měl mít problém s dobře napsaným monolitickým SW jenom proto, že někde někde řekl, že modules are good, mmkay.

To samý to tvoje pojetí komplexity, to taky není něco, s čím by se dalo souhlasit na obecné rovině (existuje mnoho různých druhů/pojetí komplexity). Není to o tom, že bych nesouhlasil s tvojí myšlenkou komplexity jako takovou a měl ji za nepřijatelnou. Je to validní myšlenka, validní metrika, která je pro svůj účel velmi dobře použitelná. Nepřijatelné je pro mě prohlášení tvého pojetí komplexity za univerzálně pravdivé a relevantní pro všechen software pod sluncem.

Kromě těch klasických unixových praotců, máš pak dole v příloze i článek od Niklause Wirtha, autora Oberonu

Meh. Unixová filosofie je velmi vágně definovaná a v podstatě každý její fanoušek si z toho vytáhne to, co se mu líbí a interpretuje nějakým svým způsobem. A opět platí, že to je jen jeden pohled na problém. Jsou tu taky praktické záežitosti. Všimni si, kde skončil Linux a kde Hurd.

[xkucf03]

Problém mam s tím, když se tohle prosazuje za jedinou správnou cestu a všechno ostatní se prohlásí za horší. To je prostě akorát fundamentalismus.

To jsi nepochopil nebo nečetl ten článek. Viz kapitola Kdy použít kterou variantu.

Není to o tom, že bych nesouhlasil s tvojí myšlenkou komplexity jako takovou a měl ji za nepřijatelnou. Je to validní myšlenka, validní metrika, která je pro svůj účel velmi dobře použitelná. Nepřijatelné je pro mě prohlášení tvého pojetí komplexity za univerzálně pravdivé a relevantní pro všechen software pod sluncem.

Kterou metriku myslíš? Viz kapitola Co je to komplexita? Je tam zmíněno mnohem víc aspektů než jen počítání řádků. Trochu z toho mám pocit, že se chytáš jen klíčových slov, ale ve skutečnosti nečteš.

[kralyk z abclinuxu]

To jsi nepochopil nebo nečetl ten článek. Viz kapitola Kdy použít kterou variantu.

...

Čím více času a úsilí jsme do vývoje programu investovali a čím hodnotnější software jsme vytvořili, tím víc bychom se ho měli snažit odstínit od jeho okolí.

...

U hodnotnějšího softwaru bychom měli směřovat k variantě č. 4 (alternativně č. 6):

Aha. Takže jiný možnosti je možný použít, akorát to pak není hodnotný software. Got it.

Kterou metriku myslíš? Viz kapitola Co je to komplexita? Je tam zmíněno mnohem víc aspektů než jen počítání řádků. Trochu z toho mám pocit, že se chytáš jen klíčových slov, ale ve skutečnosti nečteš.

Myslim si, že čtu relativně dobře, v podstatě tam operuješ pouze s objemem kódu (v několika obměnách).

[xkucf03]

Aha. Takže jiný možnosti je možný použít, akorát to pak není hodnotný software. Got it.

Viz #686

Myslim si, že čtu relativně dobře, v podstatě tam operuješ pouze s objemem kódu (v několika obměnách).

Máš to v tom textu i vyznačené tučně. Kromě počtu řádků tam je cyklomatická složitost, závislosti, struktura/architektura, pestrost a různorodost technologií…

[Fluttershy, yay!]

To je ten shepherding.

[Bherzet]

Resp. javovskou architekturu, idiomy, terminologii. Argumentuješ tím, že přece to není Java, že stejné principy platí i jinde - ne neplatí a ano je to furt Java.

Aha, proto se s těmi idiomy setkáváme přinejmenším ještě v PHP [1], C# [2], C++ [3, 4], D [5], JavaScriptu [6, 7], tvém milovaném Rustu [8], Go [9, 10], těžce funkcionálním antikontrafibulačním Haskellu [11] a zkrátka obecně kdekoliv v softwarovém inženýrství. Nebo, inženýrství… Stěží bychom hledali lepší ukázku toho, proč to inženýrská disciplína ve skutečnosti není, než tuto diskuzi, která je plná ignoranství a absolutní neschopnosti odprostit se od své osobní zaujatosti vůči jedné technologii.

František má občas poměrně radikální názory na to, které postupy jsou správné, a s jeho hodnocením sanity/insanity ne zcela souhlasím, nicméně aspoň se snaží k tomu přistupovat objektivně.

Já nikomu nezazlívám, že už prostě po celém dni programování v práci na tohle nemá náladu a potřebuje taky trošku zapojit tu kreativnější hemisféru, znám to sám. Ale chce si to pak vyjasnit, o čem se teda bavíme.

[kralyk z abclinuxu]

Aha, proto se s těmi idiomy setkáváme přinejmenším ještě v PHP [1], C# [2], C++ [3, 4], D [5], JavaScriptu [6, 7], tvém milovaném Rustu [8], Go [9, 10], těžce funkcionálním antikontrafibulačním Haskellu [11] a zkrátka obecně kdekoliv v softwarovém inženýrství.

To je slušnej seznam, ale přesto nejsem impressed. To, že existuje nějaká knihovna pro jazyk XY celkem nic moc neznamená. Stejnětak existují knihovny zaměřené na funkcionální programování třeba pro JavaScript, pro Javu atd. Jaká je ale pravděpodobnost že se setkáš s pojem DI/IoC v Java ekosystému oproti jiným jazykům? Pravděpoobně bude v mnoha případech o dost jiná.

Beru to v případě třeba PHP nebo C#, tam se s tim člověk asi taky dost setká. Případně do nějaký míry taky C++.

Haskell bohužel není tak úplně antikontrafibulační, jen je kontrafibulační zase trochu jiným způsobem, viz

František má občas poměrně radikální názory na to, které postupy jsou správné, a s jeho hodnocením sanity/insanity ne zcela souhlasím, nicméně aspoň se snaží k tomu přistupovat objektivně.

Máš tam typo: s/objektivně/objektově/ ...

Ne, takhle, objektivní přistup si představuju o dost jinak, objektivní by bylo popsat různé přístupy a srovnat jejich pro a proti, ne kázat o správném přístupu, navíc poměrně dost 'opinionated' formou.

než tuto diskuzi, která je plná ignoranství a absolutní neschopnosti odprostit se od své osobní zaujatosti vůči jedné technologii.

Ne vůči technologii. Vůči kultuře, a tam skutečně mám ten názor, že je s ní něco špatně. Snažim se vysvětlit co, ale zřejmě špatně / marně.

Jeden z těch problémů je něco jako zakonzervování pohledu na abstrakce. Tys jinde v diskusi nakousl exceptions. To je celkem dobrý příklad:

Kdysi v C/C++ jsem prasil error handling všlijak hlava nehlava. Pak mi různí lidé (mj. i tady na abc) a různé tutoriály objasnily výhody výjimek, koncept exception safety apod. Nějakou dobu jsem byl spokojen a pilně vytvářel hierarchie exception tříd, zajišťoval exception safety, házel a chytal výjimky atd. O dost později jsem se trochu seznámil s prvky FP v ML jazycích a zjistil jsem, že ADTs mi pro error handling vyhovují o dost líp. Výjimky teď považuju za mechanismus se sporným přínosem. Co z toho plyne? Že ADTs jsou nejvíc nejlepší? Aktuálně je preferuju, ale mají taky nějaké svoje problémy a hlavně už mam tu zkušenost toho omylu s výjimkami, a tedy vím, že úplně stejně se můžu mýlit i v případě ADTs. Tzn. je to pouze nějaký aktuální stav poznání, který se může v budoucnu změnit, můžu zjistit, že existuje nějaký jiný mechanismus X lepší než cokoli, co jsem doposud znal. Taky se asi může stát, že třeba v nějakým jazyku narazim na výjimky (třeba nějak jinak integrovaný do jazyka) a bude mi to připadat jako dobrý řešení.

No a tohle platí taknějak o všem: Všelijaké další abstrakce v jazycích, OOP, FP, další paradigmata, architektura softwaru, sdílené knihovny, správci balíčků a repozitáře, operační systémy atd. (Bystroushaak má v tomhle ohledně OS pravdu, byť osobně nejsem nadšenec do třeba Selfu et al.)

No a u Javy, resp. Java kultury mi přijde, že jde proti tomuhle: Místo objevování nových abstrakcí má víceméně stále ty stejné, které konzervuje, standardizuje, s výjimkou sem tam nějaké nové verze, která přinese čerstvý vzduch, ale to se až tak často nestává. A to samé se týká i architektury software. Samozřejmě ono to má svůj dobrý důvod, není možný software neustále přepisovat a tam, kde se používá Java, je určitý konzervatismus typicky potřeba. Bohužel to ale má ten vedlejší efekt na tu kulturu. Je to jak říkáš - nějaké objevování nových horizontů se pak děje v lepším případě až po práci, v horším (a to mi přije, že je bohužel časté) ani to ne.

Což mi připomíná, že bych asi taky někdy v dohledný době si zas měl vyzkoušet něco jinýho (než aktuální Rust). Kdybyste někdo měl typ na zajímavý jazyk, dejte vědět. (Před časem jsem např. koukal na LunaLang, ale bohužel to úplně nenaplnilo očekávání.)

[_]

Což mi připomíná, že bych asi taky někdy v dohledný době si zas měl vyzkoušet něco jinýho (než aktuální Rust). Kdybyste někdo měl typ na zajímavý jazyk, dejte vědět. (Před časem jsem např. koukal na LunaLang, ale bohužel to úplně nenaplnilo očekávání.)

White space (doporučuji postahovat kompilátory a dokumentaci, než to smažou)

[deda.jabko]

Puvodne jsem se nechtel do teto diskuze uz zapojovat, obzvlast, kdyz uz v minulosti jsme to resili. A ten zaver byl priblizne ten, ze ti nevadi ani tak ty navrhove vzory, ale to, ze to ma nejake pojmenovani.

Ne vůči technologii. Vůči kultuře, a tam skutečně mám ten názor, že je s ní něco špatně. Snažim se vysvětlit co, ale zřejmě špatně / marně.

A ted se to ukazuje v plne krase, kdy brojis proti nejake kulture, coz je pojem, ktery nezavedls a ani zavest nejde, ale je to dokonaly slamenny panak, do ktereho se da sit hlava nehlava. Takze je jasne, ze diskuze na toto tema s tebou opravdu nemuze mit rozumne rozuzleni.

Jaká je ale pravděpodobnost že se setkáš s pojem DI/IoC v Java ekosystému oproti jiným jazykům?

Dost vysoka, ale ve FP se tomu bude rikat funkce vyssiho radu. Sakra, a neni funkce vyssiho radu taky kontrafibulace?

No a u Javy, resp. Java kultury mi přijde, že jde proti tomuhle: Místo objevování nových abstrakcí má víceméně stále ty stejné, které konzervuje, standardizuje, s výjimkou sem tam nějaké nové verze, která přinese čerstvý vzduch, ale to se až tak často nestává.

Feature, not a bug. Stejne jako technicke kresleni pouziva +/- desitky let zavedene postupy s minimem novych prvku, v muzeu moderniho umeni najdes kresby mnohem kompaktnejsi s bohatsimi vyrazovymi prostredky. Rozdil je v tom, ze v prvnim pripade tomu bude rozumet temer kazdy, v druhem pouze par zasvecenych.

A jeste poznamka k navrhovym vzorum.

Nekolikrat tu odkazovals na pouzivani idiomu a nejspis je povazujes za standardni (nijak spatnou) zalezitost. Avsak navrhove vzory v OOP nejsou nic jineho nez idiomy, ktere se pouzivaji pro reseni standardnich problemu, neni proto duvod se na ne divat pres prsty. Vsimni si, ze idiomy mohou trpet stejnymi problemy, jake s JS1 shledavate u navrhovych vzoru. Muze se z nich stat cargo cult, tj. jsou pouzivany, i kdyz to v dane situaci neni treba, jsou dusledkem omezene abstrakce jazyka, tzn. pokud by jazyk byl dostatecne abstraktni, idiom by byl nahrazen necim jinym a jiz by nebyl idiomem.

[kralyk z abclinuxu]

A ted se to ukazuje v plne krase, kdy brojis proti nejake kulture, coz je pojem, ktery nezavedls a ani zavest nejde, ale je to dokonaly slamenny panak, do ktereho se da sit hlava nehlava.

No dobře, ale jak to chceš udělat jinak? Měla by kultura okolo třeba programovacího jazyka dostat poslaneckou imunitu a kritika bude zapovězená, protože ji nemůžeme exaktně definovat? Viz taky ten odkaz na shepherding co posílal davkol...

Dost vysoka, ale ve FP se tomu bude rikat funkce vyssiho radu. Sakra, a neni funkce vyssiho radu taky kontrafibulace?

Nevim, jestli zrovna "funkce vyššího řádu", ale jako jo, může to tak být, v diskusi už jsem linkoval zygohistomorfické prepromorfismy, což je kontrafibulace jak prase. (V komentáři jsem ten odkaz měl taky, za tim "viz", ale nějak to vypadlo.)

Stejne jako technicke kresleni pouziva +/- desitky let zavedene postupy s minimem novych prvku, v muzeu moderniho umeni najdes kresby mnohem kompaktnejsi s bohatsimi vyrazovymi prostredky. Rozdil je v tom, ze v prvnim pripade tomu bude rozumet temer kazdy, v druhem pouze par zasvecenych.

No, ale fór je v tom, že poslední vývoj v jazycích ukazuje, že ty koncepty do mainstreamu probublávají. Jednu chvíli tomu rozumí tomu pouze pár zasvěcených, pak to někdo naimplementuje do Javy nebo C++, a za chvíli o tom masy píšou nadšené blogy

[deda.jabko]

No dobře, ale jak to chceš udělat jinak?

Tak predne by bylo vhodne nazyvat veci spravnymi jmeny. Tim, ze kritizujes navrhove vzory, architekturu, atd. by jeden nabral dojmu, ze se jedna o technickou diskuzi, kde se da dobrat toho, ze neco je dobre, spatne na zaklade argumentu. Ale ve skutecnosti kritizujes jen tu kulturu, coz jednak znamena, ze neni jasne, co presne to je a vuci cemu se vymezujes, a za druhe to nema obecnou platnost.

Nevim, jestli zrovna "funkce vyššího řádu", ale jako jo, může to tak být

V tom pripade je cela diskuze absurdni, protoze tobe asi opravdu vadi, ze lidi davaji vecem nazvy (aby se mezi sebou domluvili). Kdyz se oprostime od programovacich jazyku, treba pojem "sarkasmus" je to taky kontrafibulace.

[kralyk z abclinuxu]

V tom pripade je cela diskuze absurdni, protoze tobe asi opravdu vadi, ze lidi davaji vecem nazvy

Ano, v podstatě to tak je, resp. slyšel jsem tomu říkat "too much terminology". Myslim si - a je pravda, že to je pouze osobní názor - že to přispívá ke vzniku cargo cultů.

Samozřejmě ta úroveň, co je ještě ok a co už je moc terminologie je taky subjektivní. V kontextku mimo Javu mi například trochu vadí termit 'RAII', který působí jako celkem náhodný shluk písmem. Někteří lidi se to snaižli vyřešit zkratkou CADRe, což ale je skoro to samé. Nevim ale, co s tim, takže to zatim používám...

[Bherzet]

Odpor ke lpění na zbytečných, dílčích detailech chápu. Je důležitější chápat problém než z rukávu tupě vysypat stovky slovíček, ale neumět si dát jedna a jedna dohromady. Z člověka může vyrůst špičkový programátor, aniž by kdy přišel do styku s cizím kódem vyjma standardní knihovny a manuálu k tomu kterému jazyku. Tak jako šachy můžeš hrát sám proti sobě, můžeš se poučovat z chyb, které jsi natropil ve vlastních programech – a po nějaké době si začít všímat určitých vzorců.

Souhlasil bych s tebou, kdybys řekl, že zkušenosti jsou důležitější a nedají se zcela nahradit znalostí design patternů.

Souhlasil bych i v tom, že vtloukání návrhových vzorů do hlav začínajících programátorů (např. na školách), je spíše kontraproduktivní, protože ti lidé neznají a nemohou znát problémy, k jejichž řešení jsou ty věci určeny. Pak produkují kód, ve kterém se snaží těm problémům předcházet, aniž by uměli posoudit, jestli ty problémy skutečně hrozí a jestli naopak nevytváří problémy jiné.

Ale pak je tu komunikace a pokud se nebavím s někým, kdo 10 let programoval svou offline LISP machine ve sklepní kóji, odkud neviděl ani denní světlo, ani jiný zdrojový kód, natož jiné programátory, tak předpokládám, že nějaké základní pojmy pochytil. Ostatně ty sám ty zde zmiňované továrny nebo dependency injection velmi dobře chápeš a kdybych tak na tebe promluvil v práci, bez problémů bychom si rozuměli. A ano, domluvili bychom se i bez toho – po pár dnech/týdnech obšírného skládání slůvek bychom dokonvergovali k nějaké nové, projektově-specifické terminologii, která by účel plnila stejně tak dobře.

To, že se prostě určitá terminologie uchytila v širším společenství než je jedna firma, podle mě není samo o sobě nijak na škodu. A ano, nepříliš překvapivě tam budou nějaké odchylky a lidé okolo jednoho jazyka budou uvažovat v terminologii, která se k tomu jejich jazyku lépe hodí. Na té nejbanálnější úrovni se to projevuje zařazováním klíčových slov z programovacího jazyka do toho lidského: viz např. final (Java) vs. const (C++).

To ale neznamená, že jedna jazykově-preferovaná terminologie hned postrádá jakoukoliv relevanci v jazyce jiném. Jednak, jak jsme si ukázali, se např. s tou dependency injection setkáváme opravdu všude možně, jednak ten problém je opravdu natolik obecný, že v nějakých obdobách bude existovat v každém jazyce a maximálně se mu bude říkat nějak jinak. Nepředpokládám, že bych se s pojmem dependency injection setkával při přechodu na standardní LISP, ale jsem si naprosto jistý, že problém, k jehož řešení je ta dependency injection určena, bych řešil pořád a to pravděpodobně velmi, velmi podobným způsobem.

Co vypadá jako velký rozdíl při celodenním čumění do zdrojáku a uvažování v konstruktech programovacího jazyka je malý a zanedbatelný rozdíl z pohledu mírně abstraktnějšího. Pořád budu řešit problém: „Modul X závisí na modulu Y. Při testování modulu X nechci testovat modul Y.“ A ať si to zaonačím jakkoliv, pořád to skončí tak, že modulu X budu podstrkovat jiný modul než Y.

[kralyk z abclinuxu]

To, že se prostě určitá terminologie uchytila v širším společenství než je jedna firma, podle mě není samo o sobě nijak na škodu. A ano, nepříliš překvapivě tam budou nějaké odchylky a lidé okolo jednoho jazyka budou uvažovat v terminologii, která se k tomu jejich jazyku lépe hodí. Na té nejbanálnější úrovni se to projevuje zařazováním klíčových slov z programovacího jazyka do toho lidského: viz např. final (Java) vs. const (C++).

To je velmi dobrý příklad problému, o kterým se tu bavíme.

final v Javě a const v C++ není to samý, ani trochu. Ten rozdíl mezi nimi je "jednoduchý": const se aplikuje rekurzivně, final ne. Tenhle zdnánlivě banální rozdíl má ale obrovské důsledky. Vede na koncept const-correctness v C++, což ovlivňuje celá veřejná API knihoven, o vnitřním uspořádání nemluvě. A když přejdeme od C++ k Rustu, tak zjistíme, že tenhle "banální" rozdíl může mít ještě mnohem větší implikace - je to nutná podmínka pro Rustovskou paměťovou bezpečnost a eliminaci race conditions, což je něco, bez čeho by ten jazyk vlastně vůbec neměl smysl.

Tenhle "drobný" rozdíl tedy významně ovlivňuje architekturu software a mimo jiné i celé invarianty, které nějaký program má (tj. třeba že je race free).

Z mého pohledu je asi nejdůležitější to, že tyhle rozdíly ovlivňují způsob, jakým člověk o architektuře přemýšlí.

Prohlásit final jen za trochu jinou terminiologii pro const je právě ta ignorance některých Java programátorů, která mě štve. To je podobný jako s tím že "funkce je objekt", v podstatě to je cílený vyignorování rozdílů a hlavně jejich implikací, které ale můžou být opravdu dalekosáhlé.

IMO to, jak tu s Frantou dáváte jazyky "do latě" je jen trochu zvláštní způsob, jak říct, že jsou turingovsky úplné. Což je pravda a je pravda, že tím pádem může člověk v Javě udělat principielně to samé jako v Haskellu a naopak. Ale problém je, že tahle argumentace nikam nevede, protože to bychom pak všichni nepoužívali ani Javu ani C++ ani Haskell, nýbrž nějaký Turing tarpit. Což ale zřejmě naprostá většina programátorů nechce, tudíž zjevně ty rozdíly nějakým způsobem podstatné jsou.

[xkucf03]

final v Javě a const v C++ není to samý, ani trochu

Přijde mi, že jsi tu do diskuse zatáhl zase nějaká „traumata z dětství“. Tvrdil tu snad někdo, že final a const jsou to samé? Podobný nešvar se v téhle diskusi vyskytuje na více místech – podsouváš ostatním něco, co neřekli, a pak proti tomu argumentuješ, případně argumentuješ proti nějaké své představě „javovské kultury“.

IMO to, jak tu s Frantou dáváte jazyky "do latě" je jen trochu zvláštní způsob

Já už nevím, jak ti to jinak říct (viz #633, #651, #656). Zkus se o tedy o softwarové architektuře pobavit s nějakým architektem ve svém okolí a zjistit, jak moc ho zajímají implementační detaily tvého jazyka a jak moc ho zajímají vztahy mezi nějakými většími celky. Chápu, že tyhle pojmy nejsou úplně přesně definované, nicméně architekturou se obvykle myslí pohled na informační systémy z větší dálky, s větším nadhledem – zatímco to, o čem mluvíš ty je spíš návrh (vnitřku) nějaké jedné komponenty.

[kralyk z abclinuxu]

nicméně architekturou se obvykle myslí pohled na informační systémy z větší dálky, s větším nadhledem

To samozřejmě chápu.

zatímco to, o čem mluvíš ty je spíš návrh (vnitřku) nějaké jedné komponenty

Ano, ale to jsou spojené nádoby. To se snažím říct už asi desítky komentářů - a uvedl jsem i konkrétní příklady - že ty úrovně abstrakce jsou navázjem propojené. Neexistuje non-leaky abstrakce. Implementační detaily jazyka ovlivňují i tu archiketuru z dálky. Samozřejmě programátoři mají snahu ty implementační detaily skrýt, abstrahovat, atd., ale to je snaha, která v podstatě nikdy tak úplně nefunguje, vždy je to jen z nějaký části.

Ty zřejmě tohle odmítáš / nebereš na vědomí / nechápeš / nevim, v čem je problém.

Zkus se o tedy o softwarové architektuře pobavit s nějakým architektem ve svém okolí a zjistit, jak moc ho zajímají implementační detaily tvého jazyka a jak moc ho zajímají vztahy mezi nějakými většími celky.

To se děje celkem běžně. Zrovna nedávno jsem spolupracoval s člověkem v roli architekta na portování jednoho celkem propracovanýho Python systému do Rustu. Implementační detaily v tom hrály poměrně podstatnou roli a ano, mají vliv na high-level architekturu výslednýho frameworku.

[Bystroushaak]

případně argumentuješ proti nějaké své představě „javovské kultury“

Ten zbytek stranou; co jiného asi tak může dělat? Javovská kultura existuje. To myslím víme asi všichni. Tak jako každý kultura, i tahle je pro každého o něčem trochu jiném, protože má trochu jinou osobní zkušenost. Pokud člověk není zrovna nějaký student té kultury, který by systematicky šel a snažil se zmapovat v čem přesně spočívá, tak nikdy z principu nemůže kritizovat něco jiného, než tu svojí představu té kultury. Kterou hádám jakožto její člen vnímáš podstatně jinak, než jak to vnímají ostatní, pro které to není každodenní chleba.

Já jsem například dělal v javě celou vysokou školu, tři roky jsem psal i malé utility, na které se mnohem víc hodí něco jiného, jen v javě. Když jsem přecházel (zpět) na python, tak jsem naprosto nechápal, jak v něm někdo může programovat. Vždyť to nemá ani kontrolu typů! Měl jsem tendenci si s sebou tahat styl návrhu a očekávání z javy a trvalo mi roky se to odnaučit.

Myslím, že bych mohl namalovat nějaký abstraktní obraz, něco jako Platónova kočka od Veroniky Vřešťálové;

Obraz by nesl spousty nápisů v CammelCase, se spoustou buzzwordů a jmen patternů různé v cloudu po stranách. Spolu s javovským java -jar, okořeněným frustrací z instalace různých JDE JDK SE a JMC třípísmenných zkratek někde na oracle.com, když jen chceš aby ten program v javě co sis stáhl běžel. A uprostřed by bylo tělo člověka, viděné v obrysu IDE obsahujícím patnáct souborů needitovatelných v normálním editoru, sto padesát protected a final deklarací, které tě nenechají na pochybách, že je to industry grade javaman, žádná lopata. Každý jeho smysl by z něj koukal obalený vygenerovanýmy settery a gettery. Každá končetina připojena přes patřičné rozhraní, plně zaměnitelná za jakoukoliv jinou přes správné patterny. Z jeho vnešené SUNní tváře na tebe hledí zlé oči s logem Oracle. Postava stojí na zemi, která je z bližšího pohledu tvořená XML konfigurací.

A asi bych mohl pokračovat. Přitom ani nejsem hater, naopak se chci k javě vrátit kvůli graalvm.

[xkucf03]

případně argumentuješ proti nějaké své představě „javovské kultury“

Ten zbytek stranou; co jiného asi tak může dělat?

Třeba napsat vlastní zápisek do blogu na téma: „Moje názory na javovskou kulturu a tak vůbec“. Ale proč to cpát do všech diskusí, kde se vyskytl alespoň jeden člověk programující v Javě?

[xkucf03]

Kterou hádám jakožto její člen vnímáš podstatně jinak, než jak to vnímají ostatní, pro které to není každodenní chleba.

Sice znám Javu víc zevnitř (než třeba Pythonista nebo Haskellista dívající se na Javisty skrz prsty) a je to můj „každodenní chleba“, ale přesto se nepovažuji za nějakého příslušníka kmene javistů. Java je sice jazyk, který často používám a mám o něm docela dobré mínění, ale sám sebe považuji za softwarového inženýra. Ono vlastně i to, za co mi zákazníci platí a co u nich velkou část dne dělám, je něco jiného, než psaní kódu v Javě. I když se budeme bavit jen o programování, tak velkou část práce jsem udělal v SQL, což je zase úplně jiné paradigma. Ale velkou část dne ani žádný kód nepíšu a je to spíš o návrhu rozhraní, architektuře, analýze. Dělal jsem třeba implementaci ISO 8583 (protokol pro platební karty – komunikaci s bankomaty a obchodníky) nebo napojení na ČNB. Tam ani nevíš, v jakém jazyce jsou ty systémy naprogramované a píšeš to podle specifikace. U těch karet jsem si musel napsat i vlastní simulátor, protože jsme dlouho neměli ani přístup na testovací prostředí, ale už bylo potřeba vyvíjet. Pak jsem třeba dělal jeden projekt, kde se programovalo v Pascalu… jakkoli to zní hrozně, byla to zajímavá práce a zkušenost. Ale ten programovací jazyk na tom byl to nejméně podstatné. Ty velké informační systémy jsou složené z mnoha částí, psaných v různém čase různými lidmi/firmami v různých jazycích, často ani nevíš v jakých… přesto to musí fungovat dohromady a mít nějaký řád, nějakou strukturu.

Takže proto se asi na věc dívám trochu jinak, mám ty priority/zaměření někde jinde a abstrahuji od některých věcí, které někdo jiný bude považovat za naprosto kruciální :-)

[JS1]

Takže proto se asi na věc dívám trochu jinak

My uz asi s Kralykem nevime, jak ti to vysvetlit, abychom se neopakovali - ty se na veci nedivas jinak, protoze ti chybi rozhled. To my se na ne divame jinak.

[xkucf03]

Tohle už hraničí s náboženským fanatismem. Já tu psal z legrace o „příslušnících funkcionální víry“, ale ono to asi vážně tak bude.

[Bystroushaak]

Meh. Z mé zkušenosti:

Když ti N lidí tvrdí něco, co se ti zdá jako blbost, tak je samozřejmě možné, že ty máš ten jediný správný názor, ale pravděpodobnější je, že máš prostě špatný uhel pohledu. Zákeřné na tom je, že ti to ani nedochází (we don't know what we don't know).

Možná bys tomu měl zkusit dát šanci.

[Josef Kufner]

Zrovna software je obor, kde se ty blbosti vyskytují docela často. Není to tak dávno, kdy Singleton byl opěvovaný návrhový vzor a funkcionální programování bylo považováno za teoretickou hračku.

Chybějící rozhled je celkem častý nedostatek, ale zas na druhou stranu se stává, že něco nejde a pak přijde někdo, kdo neví, že to nejde a udělá to.

[Bherzet]

Pochopit ve zdejší diskuzi, co kdo vlastně tvrdí, vyžaduje netriviální množství výpočetního výkonu. IMHO „Návrhové vzory a terminologie okolo nich svůj smysl mají, byť nadužívání samozřejmě škodí, a ne vždy ukazují na nedostatek jazyka a ne vždy s jazykem vůbec souvisí“ a dál asi nemám sílu.

[kralyk z abclinuxu]

Dělal jsem třeba implementaci ISO 8583 (protokol pro platební karty – komunikaci s bankomaty a obchodníky) nebo napojení na ČNB. Tam ani nevíš, v jakém jazyce jsou ty systémy na programované a píšeš to podle specifikace.

Týhle brandži nerozumim, takže se můžu mýlit, ale není tohle daný prostě tim, že ty věci jsou od sebe hodně oddělený, např. protože komunikujou po síti / nějakým spojení?

[Bystroushaak]

Ono vlastně i to, za co mi zákazníci platí a co u nich velkou část dne dělám, je něco jiného, než psaní kódu v Javě. I když se budeme bavit jen o programování, tak velkou část práce jsem udělal v SQL, což je zase úplně jiné paradigma. Ale velkou část dne ani žádný kód nepíšu a je to spíš o návrhu rozhraní, architektuře, analýze. Dělal jsem třeba implementaci ISO 8583 (protokol pro platební karty – komunikaci s bankomaty a obchodníky) nebo napojení na ČNB. Tam ani nevíš, v jakém jazyce jsou ty systémy na programované a píšeš to podle specifikace. U těch karet jsem si musel napsat i vlastní simulátor, protože jsme dlouho neměli ani přístup na testovací prostředí, ale už bylo potřeba vyvíjet. Pak jsem třeba dělal jeden projekt, kde se programovalo v Pascalu… jakkoli to zní hrozně, byla to zajímavá práce a zkušenost. Ale ten programovací jazyk na tom byl to nejméně podstatné. Ty velké informační systémy jsou složené z mnoha částí, psaných v různém čase různými lidmi/firmami v různých jazycích, často ani nevíš v jakých… přesto to musí fungovat dohromady a mít nějaký řád, nějakou strukturu.

Jo, no a? Já jsem dělal taky spoustu implementací backendů a různých napojování, většinou v pythonu (ano, už jsem taky napojoval cobolové api). Zákazníky skutečně většinou nezajímá v čem to bude, to zajímá mě. Tvoje pointa je, že tebe to nezajímá a přijde ti to nepodstatné a obecně nezajímavé, ale tak to podle reakcí v téhle diskuzi vážně není. Můžeš si myslet, že je to nevyspělost ostatních, kteří neprogramovali nějaké úžasné enterprise bankovní api, ale faktem je, že tohle je většinou denním chlebem i spousty dalších lidí.

[Bherzet]

Ten zbytek stranou; co jiného asi tak může dělat?

Např. držet se k tématu. Uznávám, že je to složité, protože už delší dobu sám netuším, jaké téma zdejší diskuze vlastně je. Ale měl jsem za to, že o tom, jestli návrhové vzory můžou nebo nemůžou mít své opodstatnění, a intenzivní klikání na tlačítko Výše mě dostalo k #476: „Ale podle me by se nemely (návrhové vzory, pozn. redakce) pouzivat vubec“.

[JS1]

Ale měl jsem za to, že o tom, jestli návrhové vzory můžou nebo nemůžou mít své opodstatnění

A pochopil jsi aspon co jsem navrhoval za alternativu? Aby ty jim odpovidajici abstrakce byly implementovany primo v jazyce (nebo jeho knihovnach).

[Bherzet]

Samozřejmě, že pochopil. Ale nemyslím si, že je to vždy lepší, pokud je to vůbec možné. Viz třeba #670 a #673.

[Bherzet]

Ne, není to dobrý příklad problému, o kterém se bavíme, protože:

1. Nikdo netvrdil, že final a const jsou zaměnitelné;

2. Ten příklad jsem zvolil jen jako ukázku původně klíčových slov, které můžou probublat do běžné mluvy.

Pomocí final i const je možné deklarovat konstantu. Tam, kde se liší, to chování srovnávat logicky nemůžeš (v C++ se pomocí const nedá udělat neměnitelná třída, k tomu od C++11 slouží rovněž final, a naopak v Javě pomocí final nemůžeš vyznačit metodu nemodifikující vnitřní stav objektu, ani vytvořit immutable referenci).

[kralyk z abclinuxu]

Puvodne jsem se nechtel do teto diskuze uz zapojovat, obzvlast, kdyz uz v minulosti jsme to resili. A ten zaver byl priblizne ten, ze ti nevadi ani tak ty navrhove vzory, ale to, ze to ma nejake pojmenovani.

Můj takeaway je, že prostě nejsem schopen to srozumitelně vykomunikovat :-/

[JS1]

Avsak navrhove vzory v OOP nejsou nic jineho nez idiomy, ktere se pouzivaji pro reseni standardnich problemu, neni proto duvod se na ne divat pres prsty.

Muzeme tem vzorum rikat idiomy, ostatne tak se tomu v zasade rikalo predtim, nez si nekdo vzpomnel na Christophera Alexandera. Ale to co mi na tom vadi, a s cim Kralyk souhlasi, je to, ze bychom se meli snazit se tech idiomu zbavit, abstrahovat je (samozrejme, ucelem neni code golf - pokud je to idiom na jeden radek, tak se tech par znaku snese; coz je ostatne i filozofie treba Pythonu, pokud lze neco docilit kombinaci 2-3 funkci, nema smysl, aby pro to byla samostatna funkce v knihovne), a pokud mozno tedy naucit pocitac, aby jim porozumel. A myslim oba argumentujeme, ze to zvysi citelnost a srozumitelnost.

[xkucf03]

Viz #545

[Bherzet]

To, že existuje nějaká knihovna pro jazyk XY celkem nic moc neznamená.

Tak je to docela slušný ukazatel toho, že to opravdu jsou obecné koncepty.

Ne, takhle, objektivní přistup si představuju o dost jinak, objektivní by bylo popsat různé přístupy a srovnat jejich pro a proti, ne kázat o správném přístupu, navíc poměrně dost 'opinionated' formou.

V těch článcích, co tu linkoval, jsem zahlédl nějaké srovnání grafů závislostí dvou projektů a tak. Mně přijde, že optika programovacích paradigmatů, kterou se na to díváš, je relevantní jen při uvažování nad algoritmy. Ty architektonické problémy to nijak výrazně neovlivní. Jestli si v Javě někam injektuju objekt, nebo v Haskellu funkci vyššího řádu, jak poznamenává deda.jabko, je v principu úplně totéž.

Jediné, co mě napadá jako problém „vygenerovaný“ Javou je, že třeba když si uděláš Parser jako stavovou třídu, tak pak v kódu musíš dělat parserFactory.newInstance(source).parse(); a řešit tam továrnu místo prostého parser.apply(source); a předání rovnou toho parseru (jako funkce). A přesně tak by se to – naprosto přirozeně – vyřešilo ve funkcionálním jazyce. Funkce vezme funkci, aplikuje ji, „obohatí“ výsledek (resp. jej dále zpracuje) a ten vrátí.

Jenže to není tak jednoduché. Stačí, aby se z té „ošklivé stavové třídy“ používala víc než jedna metoda, a rázem se situace obrátí: zatímco při tom objektovém přístupu mám pořád jednu továrnu, která vyrábí jeden objekt – a ten už má všechny metody zabalené v sobě, tak při tom funkcionálním bych musel každou volanou funkci „indirektovat“ (nejspíš přesouvat do parametrů, nebo prostě jinak umožnit modifikovat ten scope tak, aby na ty skutečné funkce neviděly), ručně. A to i v případě, že ty které funkce nepotřebuji mockovat, resp. se spokojím s „prázdným“ chováním takového mocku. To je typický příklad věcí se side-effecty (I/O), které mohou například vygenerovat chybu: chci podstrčit nevinný objekt, nad kterým lze volat metody jako deleteAllLocalFiles() bez rizika újmy na duševním zdraví. Při funkcionálním přístupu bych místo jednoho takového objektu předával 10 různých funkcí, nebo…

Nebo by ten jazyk musel mít podporu meta-programování. Pak bych v testu řekl: „Vytvoř mi derivát této funkce, ve kterém všechny volání jiných funkcí budou nahrazena za volání prázdných funkcí, a tuto zderivovanou funkci zavolej“. Všimněme si jedné důležité věci: meta-programování potřebu továrny, alespoň tedy pro diskutovaný příklad, neodstraňuje jen za předpokladu funkcionálního paradigmatu, ale i toho objektového. Jen bych místo volání funkcí nahrazoval vytváření instance. Dnes na to musím myslet dopředu a do kódu si vkládat „zadní vrátka“.

Takže když si to shrneme.

* Kdybychom měli Konečně Ten Správný Jazyk (tm), obešli bychom se – alespoň teoreticky – bez továren? Zřejmě ano.

* V jazyce, který takové meta-programování nepodporuje, na to musíme myslet dopředu a do kódu vkládat buď továrny, nebo parametry, kterými umožníme průběh programu později ovlivnit.

Co říct závěrem. Java takové – a i daleko šílenejší – meta-programování podporuje již od své šesté verze. Nějak se to pro tyto účely neujalo a nejspíš je k tomu dobrý důvod. A nebo nás tato budoucnost teprve čeká…

[kralyk z abclinuxu]

Tak je to docela slušný ukazatel toho, že to opravdu jsou obecné koncepty.

Když to nikdo nepoužívá? Ale pomůžu ti: V Rustu se celkem hodně používá Builder pattern, dokonce (!) to kdysi i bylo v dokumentaci (ty informace tam už nejsou dnes úplně aktuální). Takže v zásadě ano, mohl bys říct, že tohle se týká i ostatních jazyků a že to je obecný princip atd.

Jenže. Jednak to tak úplně obecné není, např. motivace pro použití tohohle v Rustu často je ownership, což je něco, co třeba v Javě vůbec nenastane. Možná řekneš, že to je detail, což je do jistá míry pravda, nicméně to je něco, co celkem dost ovlivňuje architekturu např. API. No a jednak IMO je tam kulturní rozdíl; lidi to míň protežují, víc je to štve (protože se to musí psát většinou ručně), víc si uvědomují, že se v podstatě jedná o hack, který je způsobený tím, že Rust moc nepodporuje parciální inicializaci (nebo nešikovně), nemá currying apod. Resp. takový je můj dojem. Možná jsem jen naivní, možná z toho bude za chvíli stejný cargo cult jako v OOP jazycích...

Jenže to není tak jednoduché. Stačí, aby se z té „ošklivé stavové třídy“ používala víc než jedna metoda, a rázem se situace obrátí: zatímco při tom objektovém přístupu mám pořád jednu továrnu, která vyrábí jeden objekt – a ten už má všechny metody zabalené v sobě, tak při tom funkcionálním bych musel každou volanou funkci „indirektovat“ (nejspíš přesouvat do parametrů, nebo prostě jinak umožnit modifikovat ten scope tak, aby na ty skutečné funkce neviděly), ručně.

Tady moc nerozumim, co chceš říct, ale třeba v tom haskellu můžou na indirekci (více) funkcí sloužit typeclasses...

[Bherzet]

Java takové – a i daleko šílenejší – meta-programování podporuje již od své šesté verze.

A aby se neřeklo, tak jsem vykouzlil demo.

Produkční kód, ve kterém předstíráme, že APIAdapter dělá nějaké hrozné věci a nedá se na něj v testu spoléhat:

public class App {
    public static String getAPIStatusDesc(String url) {
        return new APIAdapter(url).isRunning() ? "available" : "unavailable";
    }

    public static class APIAdapter {
        public APIAdapter(String url) {
            //
        }

        public boolean isRunning() {
            return false;
        }
    }
}

Test:

public class AppTest {
    private static final String TEST_URL = "https://api.example.com/ping";

    @Test
    public void testGetAPIStatusDesc() throws Exception {
        assertEquals("available", Meta.derivative(App::getAPIStatusDesc)
            .replaceInstantiation(APIAdapter.class, /*new APIAdapter(null) {
                    @Override
                    public boolean isRunning() {
                        return false;
                    }
                }.getClass()*/ MockHandler.class)
            .build()
            .invoke(TEST_URL));
    }

    public static class MockHandler extends APIAdapter {
        public MockHandler(String url) {
            super(url);
        }

        @Override
        public boolean isRunning() {
            return true;
        }
    }
}

Třídu Meta postovat radši ani nebudu, protože je to jen narychlo splácaný proof-of-concept a ta instrumentace je děsivá. Nicméně, pár poznámek:

* Za běhu vytvářím novou třídu, do které nakopíruji zdrojovou metodu; nad touto metodou se pak provádí transformace; volání se provádí klasicky reflexí.

* Přeložit referenci na metodu na [třídu; jméno metody] se ukázalo jako velmi obtížné; ačkoliv dekompilátor si s tím poradí hravě a ta informace je někde v bajtkódu ukrytá, mně se s tím nechtělo srát a hardwirenul jsem to do toho kódu natvrdo (takže ten parametr App::getAPIStatusDesc je ve skutečnosti pro okrasu a obecně mi to nefunguje; možná by se v praxi muselo zadávat App.class, "getAPIStatusDesc").

* Anonymní třídou nelze nahrazovat proto, že nově vytvořená třída (do které jsem modifikovanou metodu vložil) k ní neměla přístup. Mělo by to jít vyřešit naklonováním té anonymní třídy nebo úpravou jejích modifikátorů, ale opět to není něco, co se mi chtělo v tuto chvíli řešit.

* Pokud by si s tím někdo dal práci a vyřešil všechna úskalí, která jsou s takto agresivní instrumentací spojená, metaprogramování v Javě by mohlo působit vcelku přirozeně. Přesto si myslím, že ty továrny jsou ve výsledku tak nějak jednodušší.

[kralyk z abclinuxu]

V těch článcích, co tu linkoval, jsem zahlédl nějaké srovnání grafů závislostí dvou projektů a tak. Mně přijde, že optika programovacích paradigmatů, kterou se na to díváš, je relevantní jen při uvažování nad algoritmy. Ty architektonické problémy to nijak výrazně neovlivní. Jestli si v Javě někam injektuju objekt, nebo v Haskellu funkci vyššího řádu, jak poznamenává deda.jabko, je v principu úplně totéž.

Ach jo. Tohle tady prosazuje Franta taky furt :-/ TL;DR není to totéž a ano, ovlivňuje to výrazně architekturu. Program v Javě, v Pythonu, v Rustu, v C++, v Haskellu, ve Smalltalku prostě bude architektovaný jinak. Celý. Se s tim smiř

Jasně, může hledat analogie a šroubovat více či méně krkolomná přirovnání. Můžeš říct, že DI je vlastně "to samý" co funkce vyššího řádu. Můžeš říct, že checked exceptions jsou vlastně "to samý" jako probublávání ADTs nahoru callstackem pomocí try opetátoru. Můžeš říct, že hodnoty + k nim asociované funkce jsou vlastně "to samý" jako objekty. Ale jsou to taková hodně povrchní přirovnání, která IMO nemají žádný smysl v praxi, protože v praxi prostě bude ten software architektovaný jinak. Je to jako říct, že vlak, raketoplán a ponorka jsou vlastně to samé, protože maj nějaký motory a nějak se říděj a přesunujou někoho z místa A do B apod. Ano, jsou tam společné rysy, ale inženýring tý věci bude pokaždý o dost jiný, bude zohledňovat jiný kritéria atd.

Já tenhle argument zcela upřímně nechápu. Proč je pro javisty tak nepřijatelná myšlenka, že v jiným jazyce se věci prostě strukturují jinak, a to třeba i na úrovni celýho SW?

[deda.jabko]

Proč je pro javisty tak nepřijatelná myšlenka, že v jiným jazyce se věci prostě strukturují jinak, a to třeba i na úrovni celýho SW?

A to je vec, ktera me toci. Tato generalizace absolutne neni na miste a prijde mi to trochu jako takovy programatorsky rasismus, kdy na zaklade anekdotickych zkusenostech vyvozujes obecne zavery. Nebo se tim, ze clovek programuje v Jave, z nej stava nejake zruda, ktera neni schopna myslet nikdy jinak?

[kralyk z abclinuxu]

A to je vec, ktera me toci. Tato generalizace absolutne neni na miste a prijde mi to trochu jako takovy programatorsky rasismus, kdy na zaklade anekdotickych zkusenostech vyvozujes obecne zavery. Nebo se tim, ze clovek programuje v Jave, z nej stava nejake zruda, ktera neni schopna myslet nikdy jinak?

No, takhle: Bherzet s Frantou tady v podstatě píšou, že rozdíly mezi jazyky jsou jen nějaké implementační detaily někde v algoritmech, že architektura je stejná a v podstatě existuje Jedna Správná Architektura™. To není nějaké moje osočení nebo nesnášenlivost, Franta doslova píše, že U hodnotnějšího softwaru bychom měli směřovat k variantě č. 4 (alternativně č. 6).

Je opravdu tak divné, když s timhle mam problém a myslim si, že hodnotný software může mít všelijaké různé architektury a není na místě ho shazovat jen pro to, že nepoužívá nějaký GoF pattern? Mně to přijde absurdní!

Co se týče zobecnění tohohle na 'java kulturu', tak tam máš možná pravdu - přiznávám, že nemam např. tvrdou statistiku o tom, že by tohle javisti dělali obecně hodně. A ano, striktně vzato to mam na základě anecdotal evidence. Přijde mi, že těch případů jsem zažil celkem hodně a nejsem jediný, kdo má tu zkušenost, ale samozřejmě nemůžu vyloučit že jsem měl smůlu a/nebo to je observation bias a/nebo nějaký mem. Omlouvám se případným javistům, kteří tohle nedělají.

[xkucf03]

bychom měli směřovat

Přečti si ta slova ještě jednou, raději nahlas. Slyšíš to? Směřovat někam, neznamená, že to tak musí být hned. A bychom měli neznamená, že to tak musí být za všech okolností.

V podstatě všichni si stěžují na nedostatek programátorů. Firmy je (nás) musí přeplácet. U komunitních/neziskových projektů zase narůstají seznamy chyb/požadavků, na které nikdo nemá čas. A na druhé straně ale neustále vzniká obrovské množství kódu, píše se znova a znova ten samý software. Duplikuje se práce, i když ty rozdíly jsou minimální nebo žádné.¹

Částečně je to přirozené a žádoucí. Z toho chaosu, kmitání a náhodných změn může evolucí vzniknout něco lepšího. Zároveň lidi se chtějí nějak kreativně realizovat. Ale je otázka, jestli toho chaosu a živelného vývoje není příliš. Já si myslím, že trochu ano.

Je evidentní, že IT nějaký problém má a že by se to dalo dělat líp. Příčiny zmíním dvě: 1) nízká granularita 2) malá obecnost. Příliš mnoho funkcionality v jednom nedělitelném balíku má jednak negativní dopady na bezpečnost a výkon atd. (viz Proč komplexita představuje problém?) a jednak vede k tomu, že ostatní si raději napíší nový software, který má jen určitou podmnožinu funkcí, místo toho, aby použili ten stávající. Malá obecnost má stejný důsledek – místo toho, aby lidí použili stávající software, tak vytvoří nový podobný, který dělá něco málo uvnitř jinak, ale z velké části duplikuje původní program.² A protože lidi plýtvají čas na téhle duplicitní práci, nezbývá jim pak kapacita na užitečnější věci.

Ano, nemá smysl hnát věci do extrému. Stejně jako může nastat paralýza analýzou, tak může nastat i paralýza příliš velkou obecností nebo příliš velkou granularitou.³ Nicméně troufám si tvrdit, že většina IT oboru nebo jeho průměr je daleko pod tím bodem, kdy granularita nebo obecnost začíná představovat problém.

Proto se snažím ostatní inspirovat k tomu, aby svůj software (a potažmo celý obor) posouvali postupně po malých krůčcích tímhle směrem. Od toho si slibuji, že bude postupně narůstat počet případů, kdy si řekneš, že tentokrát žádný nový software psát nemusíš a použiješ⁴ již existující. To ti uvolní ruce, abys mohl např. zvyšovat kvalitu a spolehlivost softwaru nebo abys mohl tvořit něco nového užitečného, na co jsi dosud neměl čas, co nemělo prioritu.

_{[1] Najdeš i případy, kdy deset, dvacet, třicet… let starý software funguje líp než ten dnešní – jen bohužel není kompatibilní s aktuálními verzemi knihoven nebo OS (místo portování a údržby raději někdo napsal novou, horší a méně zralou verzi téhož).
[2] na úrovni kódu by se to dalo přirovnat k absenci generického programování a situaci, kdy někdo napíše pět podobných tříd pro pět různých typů zpracovávaných objektů; Ale jak už tu poněkolikáté opakuji, v téhle diskusi se nebavím primárně o úrovni kódu a nějakých tříd či funkcí, ale o vyšší systémové úrovni, o větších celcích, aplikacích, komponentách, systémech…
[3] viz Volba vhodných závislostí a odstavec začínající: „Na druhé straně ale nelze říct, že čím menší knihovny, tím lépe.“
[4] protože ten existující má jednak dostatečně malou granularitu, abys mohl použít jen tu malou část, kterou potřebuješ a nebyl zatěžován nadbytečnou komplexitou (což by tě jinak tlačilo k tomu, napsat si radši vlastní software), a jednak je dostatečně obecný, aby vyhovoval tvým potřebám (tzn. jde ho parametrizovat konfigurací nebo do něj jde např. injektovat nějaká malá na míru napsaná část softwaru, která upraví jeho chování pro tvůj specifický případ)}

[Bherzet]

rozdíly mezi jazyky jsou jen nějaké implementační detaily někde v algoritmech, že architektura je stejná

Ne mezi jazyky – mluvil jsem o paradigmatech. Viz #670, lépe už to vysvětlit asi nedokážu.

Např. memory management skladbu programu samozřejmě ovlivní značně. Ale ovlivní ji z relativně přízemního pohledu, který nemá mnoho společného s abstraktními patterny, které zde diskutujeme. Dependency injection můžu uplatnit klidně i v assembleru. Pro účely testování si napíšu preprocessor, který v kódu nahradí call foo za call bar.

a v podstatě existuje Jedna Správná Architektura™

To jsem nikde neřekl. Existují postupy, o kterých lze bez příliš dlouhých úvah a diskuzí říct, že jsou prostě špatné, nebo alespoň horší než jiné, ale existují i postupy, které jsou srovnatelně dobré a není jasné, který z nich je lepší, resp. podle jaké metriky to rozhodnout.

To není nějaké moje osočení nebo nesnášenlivost, Franta doslova píše, že U hodnotnějšího softwaru bychom měli směřovat k variantě č. 4 (alternativně č. 6).

Uvedený článek jsem nečetl a tedy jsem ho nemohl ani hodnotit. Co jsem četl a (i zde) otevřeně kritizoval bylo Sane software manifesto. Myslím si, že Franta má rozsáhlé zkušenosti (alespoň tak na mě jeho příspěvky a texty působí) a ví co dělá, a že podstatná část toho, co říká, má smysl a opodstatnění, ale protože nejsem přesvědčen o tom, že bez konformity s manifestem je každý software automaticky insane, s manifestem se neztotožňuji. Frantovi jsem vytýkal, že manifest by podle mě neměl být výčet norem, ale emotivnější pojednání, které strhne čtenáře na svou stranu, ozřejmí nějaké elementární myšlenky a koncepty, ale spíše povzbuzuje vlastní kritické uvažování na straně čtenáře (a zákonitě tedy i odchylky) než diktuje podmínky, které je z velké části nutné bezvýhradně splnit.

Nicméně ve spoustě věcí jsou mi jeho názory a postoje velmi blízké.

hodnotný software může mít všelijaké různé architektury a není na místě ho shazovat jen pro to, že nepoužívá nějaký GoF pattern

To je trochu slaměný panák. Jednak to tu AFAIK nikdo netvrdil, jednak alespoň ve své argumentaci jsem se soustředil primárně na skutečnost, že určité problémy vedou na určitá řešení a těm řešením se dávají nějaké názvy.

Pokud bychom se bavili konkrétně třeba o tom, že místo dependency injection taky můžu používat singletony, ve kterých si podmínkou zjistím, jestli jsem v testu, a když ano, tak se budou chovat jinak, tak ano, považuji to za hovnokód. Všichni hovnokód občas píšeme a máme k tomu různé důvody, ale je dobré aspoň vědět, v čem jsou úskalí takového přístupu, za jakých podmínek to začne neúměrně komplikovat život apod.

java kulturu

Mně přijde, že to v podstatě vůči ničemu, o čem jsme se bavili, není relevantní. Spin-off diskuzí z výroku JS1, že design patterny by se neměly vůbec používat, jsme si ukázali, jaký je smysl např. továren a kde mají své opodstatnění a za jakých podmínek by bylo možné se bez nich obejít – přičemž obě alternativní řešení, která jsem zmiňoval, budou mít své vlastní výhody a nevýhody.

To, že někdo může design patterny používat špatně, zbytečně atd. je „hezké“ a bezesporu se to děje v míře větší než malé, ale moc nevím, k čemu by byl poznatek, kdo to páchá nejvíc a nejčastěji, s ohledem na to, že AFAIK to tu nikdo neobhajuje.

[kralyk z abclinuxu]

Např. memory management skladbu programu samozřejmě ovlivní značně. Ale ovlivní ji z relativně přízemního pohledu, který nemá mnoho společného s abstraktními patterny, které zde diskutujeme.

A já ti říkám, že má. Jako příklad jsem uvedl Builder pattern v Rustu, který je ovlivněn memory managementem / neexistencí automaticky nullovatelných typů / nepodporou parciální inicializace struktur. Nebejt toho, tak se nejspíš nepoužívá, resp. zdaleka ne tolik.

Pokud ti to pořád přijde jako příliš detaily úroveň zaostření, tak můžeš vzít v úvahu třeba generika v C++ a Rustu, jejichž vlastnosti přímo ovlivňují např. práci s dependencemi (header-only knihovny v C++, generický kód serizalizovaný do metadat v knihovnách v Rustu a z toho plynoucí implikace pro třeba stabilitu ABI apod.)

Přijde mi, že tohle je klasický omyl javistů (omlouvám se dědovi.jabkovi - některých javistů), totiž že existuje non-leaky abstrakce. Reálně žádná non-leaky abstrakce neexistuje.

Pro účely testování si napíšu preprocessor, který v kódu nahradí call foo za call bar.

DI/IoC se v assembleru dělá pomocí call %rax Akorát teda na tebe lidi píší v assembly budou asi koukat maličko divně, když tomu tak řekneš...

[kralyk z abclinuxu]

A já ti říkám, že má.

Možná ještě lepší příklad: Vem si například ten Frantovo pattern č. 4 ("Díky IoC (inversion of control) se zbavíme přímé závislosti programu na knihovně/adaptéru. Program závisí jen na rozhraní – o napojení konkrétní implementaci se nestará, protože to za něj řeší běhové prostředí.").

Jak tohle udělám v C++ nebo Rustu s knihovnou, která exportuje pouze nebo primárně generický kód? Odpověď je, že nijak. Resp. ne bez shifting the goalpost, tzn. např. bys musel zavést předpoklad, že ten program se při změně implementace závislosti překompiluje nebo bys musel generický kód vydělit do vlastního modulu, což efektivně znamená přestat používat tu závislost jako generickou.

Oproti tomu v Javě, alespoň co já vim, tohle nebude problém, protože má type-erasure generika.

Takže najednou implementační detail generik ti způsobuje změny v tom, jak přistupuješ k závivlostem a třeba efektivně i v tom, jak ten software zabalíčkuješ.

A přitom bys taky klidně mohl říct, že generika v Javě, v C++ a v Rustu jsou "vlastně to samý". Což jsou. Až na případy, kdy nejsou

[xkucf03]

V C/C++ se podobným způsobem často používají surové ukazatele – void* – typicky někam (knihovně) předáš callback nebo ukazatel na libovolnou strukturu, který pak zase někde jinde dostaneš, přetypuješ si ho zpátky a zavoláš si ho jako funkci nebo s ním pracuješ jako s tou svojí strukturou. Je to ideální příklad na použití generik, ale jak vidíš, tenhle návrhový vzor se po desetiletí používá i v jazycích, které generika nemají nebo ve kterých jsou šablony, které zrovna v některých situacích nejdou použít. V Javě za tebe tu typovou kontrolu řeší kompilátor, v Céčku si na to musíš dát pozor sám, takže s tím máš trochu víc práce, může to zvyšovat chybovost, ale v principu ten program může fungovat stejně (a taky tak běžně programy fungují).

Aby ti ty surové ukazatele nestrašily v kódu aplikace, tak bys v tom hlavičkovém souboru definujícím rozhraní musel mít i trochu logiky – dělal bys tam nějaká ta přetypování a typovou kontrolu. Pak tam budeš mít jedno rozhraní (s generiky/šablonami) vystavené směrem k aplikaci a druhé, které budou implementovat jednotlivé knihovny resp. jejich adaptéry.

Když se zamyslíme nad smyslem a použitím generik: Proč by někdo (knihovna) měl dostávat data/objekty, jejichž typ nezná? (dost možná knihovna vznikla nezávisle a dříve než daný typ, který pak přes generika bude dostávat) Odpovědi jsou v zásadě dvě: a) knihovnu nezajímá, co je uvnitř těch objektů, nijak s nimi nepracuje, jen je skladuje nebo pak posílá někam dál nebo nám je jinudy vrací zpět… a my chceme mít typovou kontrolu; b) knihovna kromě toho s objekty i nějak pracuje – a pak tu máme nějak definovanou množinu vlastností, které ten objekt má splňovat (např. mít nějaké metody), což vede k tomu, že tu máme nějaké předem definované rozhraní nebo předka, které ty objekty implementují/dědí.

[kralyk z abclinuxu]

Je to ideální příklad na použití generik

Wat? Co má void pointer společnýho s generiky? Ten mnou zmiňovaný příklad to vůbec nijak neřeší. Možná by sis to měl přečíst ještě jednou?

[kralyk z abclinuxu]

Aha, já už asi zhruba chápu, co myslíš. To, že v některých specifických situacích jde generika nahradit hnusným způsobem void pointery. Ale to neřeší případ, který mam na mysli, nemůžeš tímhle způsbem realizovat static dispatch (z definice).

Pak tam budeš mít jedno rozhraní (s generiky/šablonami) vystavené směrem k aplikaci a druhé, které budou implementovat jednotlivé knihovny resp. jejich adaptéry.

Prosím pokračuj a přibliž, jak tohle bude fungovat v C++. Dejme tomu, že závislost, kterou používám v programu, poskytuje následující funkci:

float average<T>(const std::vector<T> input);

která předpokládá, že typ T má metodu .compute_float(). Pro každou položku vektoru si zavolá právě jednou .compute_float() a vrátí průměr. Mohly by existovat různé implementace, např. naivní versus paralelní. (Nechme teď prosím stranou, že to je takový hrozně zjednodušený příklad, nechci tady psát nějaký matice nebo něco.)

Jak by se tady měla aplikovat tebou popsaná technika?

[kralyk z abclinuxu]

float average<T>(const std::vector<T> input);

lol, zmatlal jsem C++ a Rust a zapomněl na referenci. Správně to mělo být samozřejmě takhle:

template <class T> float average(const std::vector<T>& input);

[xkucf03]

A co dostanu, když ti to naprogramuji?¹ :-) Mám v hlavě rozmyšlený postup, ale nechce se mi to teď psát. Asi až zítra…

_{[1] mohl by sis třeba přejmenovat větev v gitu na java_je_boží nebo tak něco}

[kralyk z abclinuxu]

A co dostanu, když ti to naprogramuji?

Osvícení. Ale jen když nebudeš švindlovat, tj. např. nahrazovat const std::vector<T>& input něčim jako const std::vector<T*>& input nebo podobně... API se nesmí změnit (je to dependence, takže ho ani změnit nemůžu).

[xkucf03]

Ty sis sám vybral variantu č. 4, ve které máš jednak spolupracujícího autora knihovny (píše adaptér v [A+K]) a rozhraní [R] si píšeš buď ty jako autor programu nebo někdo jiný s vědomím, že to rozhraní bude stát v samostatném balíčku a někdo ho bude nezávisle implementovat a někdo používat. A nakonec ty píšeš program [P], který můžeš upravovat. Co zachovám, je tedy interní rozhraní knihovny uvnitř [A+K], ale i to by se dalo měnit, protože [A+K] je jeden balíček psaný jedním autorem. Více zítra, jestli se k tomu dostanu…

[kralyk z abclinuxu]

Můžeš si to vyzkoušet pro všechny ty varianty a porovnat si to, je mi to celkem jedno. Možná jsem neměl napsat osvícení, ale spíš opak, protože minimálně v některých případech to bude hnusné. Anebo se případně podívat na nějakou reálnou např. maticovou/lingebra knihovnu, kde je žádoucí těsná vazba, to bude asi lepší než jakýkoli příklad, který tu vymyslim...

[Bherzet]

IMHO mluvil o něčem jiném. Když budeš mít v C++ rozhraní (R):

template <typename T>
void min(T a, T b);

a ve svém kódu (P) definovaný vlastní typ s přetíženými operátory < a >, tak není možné poskytnout implementaci (A+K), aniž by tato byla zkompilována přímo proti tvému kódu (P).

[kralyk z abclinuxu]

Přesně tak. Resp. ono by to teoreticky šlo nějak ohackovat, u toho average() by sis mohl spočítat rozdíly umístění v tom vektoru a vytáhnout z toho pointer na tu funkci a podobně, ale bylo by to těžký napsat skutečně korektně, bylo by to dost hnusný a stejně by byla fůra logiky v tom headeru. To samý tvůj případ, teoreticky bys mohl napsat specielní implementace pro primitivní typy a čuchat nějaké member function pointery z ostatních (které by mohly být fat v závislosti na polymofismu T), ale byla by to dost šílenost. Nehledě k tomu, že tyhle triky se dají udělat pro jednu funkci, ale moc neškálují na celé API.

[Bherzet]

To nesouvisí s type-erasure.

Type-erasure znamená, že když si někde vytvoříš generický objekt, tak za běhu nebudeš schopen zjistit jeho typové parametry. Možná v tom listu je Láďa Hruška a možná Děda Jabko, ale z hlediska bajtkódu je to prostě jen List.

Šablona v C++ se vždycky kompiluje pro každou kombinaci dosazených typů. Jinak to udělat ani nejde. Ty předané hodnoty můžou být různě velké a můžou být různého typu. Bez znalosti konkrétního typu s nimi kompilátor nemůže udělat vůbec nic. Ani by něvěděl, kolik místa zaberou na zásobníku, takže by nebylo možné takovou generickou funkci zavolat.

Kdyby v Javě nebylo type-erasure, reference by pořád měly stejnou velikost. A pořád by o nich bylo možné předpokládat, že ukazují na typ, který je přinejmenším potomkem typu Object. Tzn. generický kód, ani z hlediska bajtkódu, by se nijak nezměnil. Akorát na úrovni bajtkódu by o té lokální proměnné typu List šlo prohlásit, jaké hodnoty obsahuje.

To, na co narážíš ty, není type-erasure, ale právě skutečnost, že generický kód v Javě vždycky smysluplně pracovat s nějakými instancemi typu Object (pokud typové parametry nejsou pomocí extends nebo super vymezeny jinak). Např. si alokovat pole typu Object[] a ukládat do něj hodnoty. V C++ se neobejdeš bez sizeof.

Jinak ano, samozřejmě, že v tomhle jsou rozdíly. No a… ?

[kralyk z abclinuxu]

To nesouvisí s type-erasure.

Mam pocit, že nastává nějaké zmatení pojmů, tak abych tomu předešel: Mám tim na myslim tohle. Půjčim si z toho článku jeden z příkladů a trošku poupravim (aby tam byla ta metoda toho interface):

public static <E extends Comparable<E>> void printArray(E[] array, E value) {
    for (E element : array) {
        if (element.compareTo(value) == 0) {
            ...
        }
    }
}

Tuhle funkce když použjieš pro se svým typem Foo, dostaneš z hlediska sémantiky tohle:

public static void printArray(Foo[] array, Foo value) {
    for (Foo element : array) {
        if (element.compareTo(value) == 0) {
            ...
        }
    }
}

Ovšem kompilátor z toho reálně udělá něco jako:

public static void printArray(Comparable[] array, Comparable value) {
    for (Comparable element : array) {
        if (element.compareTo(value) == 0) {
            ...
        }
    }
}

tzn. vymaže ten tvůj typ Foo (odtud type-erasue-based generics) a nahradí něčím obecným, kde té implementaci té funkce je konkrétní typ úplně šumák a když potřebuje volat metody, tak jen vyhledá někde v datech toho objektu tu správnou vtable a v ní tu správnou metodu a tý předhodí this pointer a nazdar (samozřejmě implementace to nějak optimalizují a třeba on-demand monomorfizují, ale to nechme stranou, obecně to musí fungovat i pro neznámý typ).

Jinak ano, samozřejmě, že v tomhle jsou rozdíly. No a… ?

Pointa je v tom, že právě díky té type-erasure je možný v Javě aplikovat ty DI/IoC patterny i pro generický kód, zatímco v C++ a Rustu to nejde (prakticky vzato, ne bez rekompilace nebo ztráty nějakých vlastností generik). Franta v tom blogu kritizuje statické linkování ("V určitých speciálních případech má statické linkovaní svoje uplatnění – jde o různá omezená či rozbitá prostředí a dočasné instalace."), nicméně co se týče generických dependencí v C++ nebo Rustu, tak v podstatě jiná možnost není a statické linkování (respektive v C++ header-only dependence) jsou validní volba.

Tj. má to být příklad, kdy ty implementační detaily, o kterých tady někteří tvrdí, že jsou pro architekturu zcela nepostatné, mají vliv na ... architekturu.

[Bherzet]

Tak ještě jinak. Do Java bajtkódu přidáme přímou podporu pro generika. Tak jako ve zdrojovém kódu, i v tomto vylepšeném bajtkódu si ta zkompilovaná třída zachová své typové parametry. S konkrétními typy se popere až JVMko v době běhu. Nic se nemaže, zcela určitě to tedy není type-erasure.

Navzdory tomu by uvedený příklad fungoval (ten v tom grafu výše, ten tvůj by podle mě nefungoval bez nechutných hacků vůbec, protože tu metodu máš statickou).

S tím pak souvisí otázka, jak by se kód, který provádí nějaké operace nad typem T měl v prostředí, kde o každém typu lze prohlásit, že je potomkem přinejmenším typu Object, a programátor při psaní generického kódu žádný konkrétnější typ rovněž nepředpokládá, vlastně zkompilovat a jestli by třeba bylo vůbec smysluplné kompilovat každý speciální případ zvlášť, když to ani není nutné.

Ten diskutovaný příklad prostě s type-erasure nijak nesouvisí. Je to v podstatě implementační detail jazyka, který tě jako uživatele nezajímá. V C# type-erasure není a přesto bys mohl napsat generický kód, zkompilovat ho a poslat ho někomu, kdo do té doby programoval proti abstraktnímu rozhraní. A fungovalo by to.

Tady je výborný příklad konkrétní implikace type-erasure v Javě.

[kralyk z abclinuxu]

Přijdemi, že tohle je úplně stejný problém jako v diskusi o boxingu: Vnímáš nějaký obecný pojem (boxing, type-erasure) pouze optikou nějaké jeho konkrétní interpretace v Javě.

Pojem type erasure (a boxing taky, for that matter) ale skutečně má obecnější význam, viz třeba HHVM:

Generics are currently implemented in HHVM through erasure

Ten diskutovaný příklad prostě s type-erasure nijak nesouvisí. Je to v podstatě implementační detail jazyka, který tě jako uživatele nezajímá. V C# type-erasure není

V podstatě je. Respektive v C# je ta situace trochu komplikovanější, protože přistupuje ke generikům různě podle toho, jaký druh typu dosazuješ: Hodnotové typy runtime dosadí a dynamicky vykompiluje (monomorfizuje) instanciaci během runtime. To je mimochodem celkem cool fíčura. K referenčním (boxovaným) typům přistupuje podobně jako Java, resp. tam mají mechanismus reified generics, což jsou type erasure generics obohacené o nějaký reflection-like mechanismus, díky kterýmu může ten kód volat konstruktory a kdesicosi. Ale v podstatě se stále jedná z pohledu téhle diskuse o type erasue. Podstatný jsou tyhle citace:

In the reference case, you actually have different classes. (...) List<Elephant> is different from List<Orangutan>, but they actually share all the same method code. (...) Yes. As an implementation detail, they actually share the same native code.

C# se liší (od třeba C++, Rustu) tím, že tam můžeš udělat runtime DI/IoC i pro generický kód s hodnotovými typy (nejen s referenčními), protože .NET runtime ten kód dynamicky překompiluje. Moje pointa ale tím pádem stále zůstátá stejná: Generický kód buď používá type erasure (nebo tu vylepšenou reified variantu), nebo musíš ten kód překompilovat, tj. v C++ ručně a C# to udělá automaticky.

Pokud se ti pojem type-erasure nelíbí, tak ok, nemusíme ho nutně používat, ale pak se dohodněme, jak tomu druhu generik teda budem říkat. Polymorfická generika? To by taky dávalo smysl, možná i větší. Nicméně ono je jedno, jak tomu řeknem, ta pointa je stále stejná: Ty implementační detaily mají konsekvence pro architekturu.

[Bherzet]

Ono to type-erasure v Hacku má úplně stejné implikace jako v Javě.

Mně fakt přijde divné označovat za type-erasure stav, kdy se při kompilaci generického kódu dosadí nejkonkrétnější možné typy. Pod type-erasure jsem si vždycky představoval to, že když mám někde v kódu new ArrayList<Integer>(), tak ve skutečnosti se při kompilaci ten typový parametr prostě ztratí a nejde to získat ani reflexí (nepočítám-li nestandardní metadata, kterými to u eclipsáckého kompilátoru snad nějak šlo…). V tom C# se tenhle typový parametr neztratí. Díky tomu to jsou schopni kompilovat do konkrétních tříd až za běhu.

Uznávám, že je to můj výklad, který pořádně nemám o co opřít. Dokonce ani v rámci té Javy, protože i samotný Oracle tvrdí něco jiného.

[xkucf03]

Jako příklad jsem uvedl Builder pattern v Rustu

Ten ošklivý návrhový vzor (!), který se používá i v Javě?

[kralyk z abclinuxu]

Ano, bohužel.

[Bherzet]

A já ti říkám, že má. Jako příklad jsem uvedl Builder pattern v Rustu, který je ovlivněn memory managementem [...]

Mně to nepřijde jako dobrý příklad. Builder moc abstraktní vzor není, je to jen hack na zpřehlednění kódu v jazyce, který neumožňuje docílit toho lépe (např. „jmenným“, nikoliv jen „pozičním“, dosazováním argumentů, defaultními hodnotami argumentů atd.).

Ale já už upřímně delší dobu vůbec nechápu, o čem tahle diskuze vlastně je. Napřed jste tu s JS1 brojili proti design patternům, že vlastně jsou to akorát nějaké zbytečné buzzwordy a ve správném jazyce vůbec nejsou potřeba, teď se ohrazuješ proti mému výroku, že „tyhle jazykové věci tu architekturu ovlivní z nízkého hlediska a s patterny to vlastně nesouvisí“ a jako příklad uvádíš pattern, kterým se řeší přesně ten nedostatek jazyka (a to dokonce ne Javy, ale Rustu)…

Osobně jsem zmaten.

DI/IoC se v assembleru dělá pomocí call %rax

Já dělám assembler jen pro zábavu, abych si právě vyčistil hlavu, takže tam by takovéhle zaneřádění produkčního kódu nějakým zbytečným předáváním závislosti neprošlo.

[xkucf03]

Tak znovu. Podívej se na ty příklady¹ v článku. Pak si zkus spustit debtree² resp. jeho obdobu ve své distribuci nad různými balíčky/programy, které používáš. Zkus se zamyslet nad počtem těch krabiček, počtem a směrem těch vazeb mezi nimi… Dává ti to smysl? Dokážeš vysvětlit, proč tam ta která vazba je? Jak velkou část těch závislostí reálně potřebuješ? Kolik procent softwaru, který máš v systému instalovaný, reálně používáš?

Spousta závislostí by mohla být volitelná, mohla by se dynamicky načítat v době běhu, injektovat do programu nebo objevit a nabídnout nějakým tím service locatorem. (a jestliže tohle zvládnou programátoři v céčku a dělalo se to tak už před vznikem Javy, tak je zřejmé, že to není nic specifického pro Javu)

Nebo se zkus zamyslet nad tím, co bys řekl kolegovi ve chvíli, kdy by ti do projektu začal zatahovat další a další knihovny, ze kterých vždy použije jen zlomek funkcionality.

_{[1] ani jeden není v Javě, mj. jsem doufal, že se tím vyhnu podobnému trollení, ale nepomohlo to
[2] v příloze článku máš i skript generate-dependency-graphs.sh, který generuje stejné výstupy, které jsem v článku používal}

[kralyk z abclinuxu]

Tak znovu. Podívej se na ty příklady v článku. Pak si zkus spustit debtree resp. jeho obdobu ve své distribuci nad různými balíčky/programy, které používáš. Zkus se zamyslet nad počtem těch krabiček, počtem a směrem těch vazeb mezi nimi… Dává ti to smysl? Dokážeš vysvětlit, proč tam ta která vazba je? Jak velkou část těch závislostí reálně potřebuješ? Kolik procent softwaru, který máš v systému instalovaný, reálně používáš?

Nevidim vůbec důvod, proč bych něco takovýho dělal. Ty otázky, které pokládáš, mě z větší části vůbec nezajímají. Ten blog jsem četl a důvody, proč by tohle člověk měl řešit, které uvádíš, mi přijdou z větší části jako handwaving. Asi si mě budeš muset zařadit mezi ignoranty, kteří nechtějí následovat ten manifest a nebudují světlé zítřky softwarového světa...

[xkucf03]

Programoval jsi někdy třeba nějakou mikroslužbu, filtr používaný v unixových rourách? Propojoval jsi nějaké systémy pomocí jejich API? Předpokládám, že ano. Každou z těch částí můžeš napsat v jiném jazyce, je to úplně jedno, a dohromady to tvoří jeden systém. Ta softwarová architektura je víc o vztazích mezi těmi částmi, než o tom, co se děje uvnitř nich.

[Bherzet]

Bude strukturovaný jinak, ale budou se tam řešit velmi podobné problémy, z nichž některé jsou natolik obecné, že s jazykem prostě už nesouvisí.

[xkucf03]

A přesně tak by se to – naprosto přirozeně – vyřešilo ve funkcionálním jazyce. Funkce vezme funkci, aplikuje ji, „obohatí“ výsledek (resp. jej dále zpracuje) a ten vrátí.

Tady je vtipné, jak se nad továrnami nejvíc rozčilují právě příznivci funkcionálního programování. Přitom továrna je v principu totéž, co funkce. Zřejmě mají pocit, že jim někdo leze do zelí a zpochybňuje jejich postavení (není potřeba funkcionální jazyk, aby šlo dělat stejné věci – stačí „mrzký“ objektový jazyk, navíc tak „podřadný“ objektový jazyk, jako je Java :-).

[JS1]

Mozna, ze ti zacina dochazet nase pointa. Pokud je to jen funkce, proc tomu nerikat proste funkce?

Ale jak pise Kralyk - diskuse fakt nema smysl, pokud si (treba o Haskellu) vic nezjistis. Nerad to rikam, ale proste neuvedomujes si miru svoji ignorance.

[xkucf03]

Třeba proto, že ne každá funkce je továrna…

[JS1]

No a? Tocime se v kruhu.

Dej mi formalni definici, jakymi vlastnostmi se ta funkce lisi od normalni funkce, a pak se muzeme bavit o tom, jestli ma smysl nova terminologie a jaka. Ale delat to naopak je prave spatne.

[kralyk z abclinuxu]

Třeba proto, že ne každá funkce je továrna…

Japatožene. Každá funkce vrací nějakou hodnotu. Každá hodnota je objekt, protože už jsme si přece vysvětlili, že všechno je objekt. Pokud funkce nic nevrací, tak taky vrací objekt - void je bezstavový objekt. Pokud funkce pouze vrací stejný objekt jako na vstupu, akorát třeba s nějakou změnou, tak to je jako kdyby ten vstupní objekt zahodila a vytvořila nový, úplně stejný (koneckonců na velmi podobném principu fungují některé FP jazyky). Ergo každá funkce je továrna své výstupní hodnoty. Funkcionální programování je ve skutečnosti Tovární programování. A protože každý objekt je vlastně taky funkce (volání různých metod objektu by se dalo brát jako volání jedné metody s různými argumenty), tak OOP je taky Tovární programování. Všechno je Tovární programování.

[Bystroushaak]

Funkcionální programování je ve skutečnosti Tovární programování. A protože každý objekt je vlastně taky funkce (volání různých metod objektu by se dalo brát jako volání jedné metody s různými argumenty), tak OOP je taky Tovární programování. Všechno je Tovární programování.

Já se nějak nemůžu zbavit dojmu, že funkcionální programování o funkcích moc není. Trochu mi přijde, že tu někteří předpokládají, že funkcionální programování je o používání funkcí, stejně jako je objektové programování o používání objektů. Reálně je ale funkcionální programování o používání immutable dat, closures, úprav AST, reflexi a tak podobně.

[kralyk z abclinuxu]

Určitě máš pravdu s těma datama - o těch to je primárně. Jinak záleží. V Haskellu to je míň o ASTu a víc o těch funkcích, jejich kompozice a transformace (všlijakej currying, mapování, lifting,...) ... Ty data jsou asi společný pro vštšinu fp jazyků...

[Fluttershy, yay!]

Určitě máš pravdu s těma datama - o těch to je primárně.

Ne asi, když pointa toho paradigmatu je výpočet postupnou aplikací funkcí (kdepak se vzaly?).

Akorát v praxi to často naráží na naprostou rezistenci vůči takovým abstraktním konceptům (což tedy stále často platí i pro naprosté základy OOP).

Ty data jsou asi společný pro vštšinu fp jazyků...

V závislosti na tom, nakolik jsou čistě funkcionální.

[xkucf03]

Určitě máš pravdu s těma datama - o těch to je primárně.

Ne asi, když pointa toho paradigmatu je výpočet postupnou aplikací funkcí (kdepak se vzaly?).

To jsi napsal moc hezky. Ono čím víc má program podobu matematického výpočtu nebo postupného zpracování dat, tím lépe to jde implementovat pomocí funkcionálního programování.

Ale pak tady máš spoustu aplikací, které fungují na jiném principu a uživatelé od nich mají jiná očekávání. Libovolný program se sice dá namodelovat jako funkce, která vrací návratový kód. Ale jestliže lidé ten program používají právě kvůli těm vedlejším efektům a ne kvůli tomu, aby po ukončení programu měli $? == 0, tak je otázka, jestli jsou funkce tím nejlepším paradigmatem nebo metaforou pro řešení dané úlohy.

P.S. U tvých příspěvků často není zřejmá pointa a smysl, takže nevím, jestli patříš k těm, kteří by rádi viděli FP všude. Pokud ne, tak tenhle komentář klidně ignoruj.

[Fluttershy, yay!]

Ale pak tady máš spoustu aplikací, které fungují na jiném principu a uživatelé od nich mají jiná očekávání.

To zní jako The Machine That Goes "Bing!"

Libovolný program se sice dá namodelovat jako funkce, která vrací návratový kód. Ale jestliže lidé ten program používají právě kvůli těm vedlejším efektům a ne kvůli tomu, aby po ukončení programu měli $? == 0, tak je otázka, jestli jsou funkce tím nejlepším paradigmatem nebo metaforou pro řešení dané úlohy.

Návratový kód, cože?

Nebyla taky ještě kousek vedle řeč o architektuře celých systémů?

[JS1]

Ale jestliže lidé ten program používají právě kvůli těm vedlejším efektům a ne kvůli tomu, aby po ukončení programu měli $? == 0, tak je otázka, jestli jsou funkce tím nejlepším paradigmatem nebo metaforou pro řešení dané úlohy.

Tohle byla otazka nekdy na konci 80. let, kdyz Philip Wadler prisel se slavnou odpovedi. Coz je prave treba neco, co by ti dalo studium Haskellu.

A ze to ma smysl prave kvuli zachovani te referencni transparence. Protoze pokud se na ni muzes spolehnout, lze provadet lokalni transformace programu bez starosti o globalni stav, coz vyznamne rozsiruje moznosti kompilatoru (a jinych transformaci programu). A jak moc by to mohlo mit vyznam treba pro business aplikace, o tom bych mohl napsat cely blogpost.

[xkucf03]

Viz #745

[JS1]

Tak pokud chces to, ze nekdo povazuje referencni transparentnost za uzitecnou vlastnost, kterou bychom se meli snazit zachovat, oznacit za fanatismus, pro me za me. Z moji zkusenosti to je uzitecna vlastnost a nema to v zasade zadne vyrazne nevyhody. Ale chapu, ze lidem, co s tim zkusenost nemaji, se to nezda, protoze prece obed neni nikdy zadarmo.

[JS1]

A jak moc by to mohlo mit vyznam treba pro business aplikace, o tom bych mohl napsat cely blogpost.

Treba za dobre povazuji blogposty od Johna A De Goese na toto tema: 1, 2. V podstate jde o strukturovani aplikaci jako vrstev interpretru, ktere prevadi mezi ruznymi DSL; na vrcholu je jazyk domeny, kterou chceme resit, a nekde dole je jazyk operaci v operacnim systemu.

A k tematu bychom mohli jeste prihodit.

[kralyk z abclinuxu]

Ale jestliže lidé ten program používají právě kvůli těm vedlejším efektům a ne kvůli tomu, aby po ukončení programu měli $? == 0, tak je otázka, jestli jsou funkce tím nejlepším paradigmatem nebo metaforou pro řešení dané úlohy.

To je moc zajímavá otázka Podle tónu, jakým jsi ji položil, usuzuju že máš celkem jasno v tom, že OOP je na tohle vhodné řešení zatímco FP spíš ne.

Otázka je, proč si to myslíš. Myslíš si to na základě toho, že máš zkušenost s OOP i FP a porovnáním těch dvou přístupů jsi došel k tomu, že OOP je na tohle lepší? Nebo prostě si jenom neumíš moc představit, jak by se daly dělat side-effecty pomocí pure funkcí? (Což bych ti neměl za zlé, ono to bez znalosti toho řešení zní trochu jako protimluv.) Taky je otázka, proč by OOP mělo být automaticky považováno za to správné řešení. V OOP jazycích jako Java, JavaScript, Python, Go atd. člověk může dělat skoro jakékoli side-effecty kdekoli se mu zachce, ale ty jazyky už moc neřeší korektnost těch side-effectů, to si musí vyřešit programátor prakticky zcela sám.

Z mýho pohledu ta otázka je dost otevřená, což mě přivádí k:

U tvých příspěvků často není zřejmá pointa a smysl, takže nevím, jestli patříš k těm, kteří by rádi viděli FP všude. Pokud ne, tak tenhle komentář klidně ignoruj.

Nevim, jestli je tohle narážka na mě, ale v každém případě, i když to tak mohlo z předchozí diskuse vypadat, nechci FP všude. To, co chci, je, aby se OOP necpalo všude, což mi přijde, že se děje (ačkoliv poslední dobou se situace zlepšila). Důvod, proč se mi líbí Rust a proč ho tady furt skloňuju v diskusi (což je asi otravný - omlouvám se) je, že spojuje několik zajímavých vlastností z různých paradigmat: Má trochu OOP (ale jen trochu, nemá dědičnost), má nějaké prvky FP (ADTs, pattern matching,... ale nikoli pure funkce) a kromě toho má Affine type system (respektive určitou variaci/rozvinutí téhle myšlenky, viz též tady), který je velmi relevantní pro právě side-effecty a je dost mimo běžné kategorie jako OOP nebo FP. Skoro žádný jazyky tohle neimplementujou - z těch známých jen částečně C++, kde ta implementace dost saje, a pak třeba podpora RAII v Javě a Pythonu, ale to je jen takovej střípek).

Rozhodně si ale nemyslim, že by Rust byl vhodný všude, naopak, je vhodný v relativně úzkém niché. A taky určitě neřekl poslední slovo k afinním typům.

Jinými slovy, nelíbí se mi OOP monokultura (umělý smrkový les), ale neznamená to, že bych ji chtěl nahradit jinou monokulturou (umělý borový les), rád vidim kombinace těch přístupů (normální les) a z toho plynoucí objevování nových řešení.

[kralyk z abclinuxu]

Oprava: Go má OOP taky jen trochu.

[xkucf03]

Otázka je, proč si to myslíš. Myslíš si to na základě toho, že máš zkušenost s OOP i FP a porovnáním těch dvou přístupů jsi došel k tomu, že OOP je na tohle lepší? Nebo prostě si jenom neumíš moc představit, jak by se daly dělat side-effecty pomocí pure funkcí?

Já ale nepochybuji o tom, že funkce můžou mít vedlejší efekty a vím, že to jde řešit pomocí monád. Já pouze pochybuji, že funkcionální přístup je jediná správná cesta.

Měl jsem tu připravených pár příkladů/poznámek, ale raději sem nic psát nebudu, protože byste to akorát des-interpretovali jako: „Franta chce nacpat objekty všude a navíc Java smrdí.“ (i když by ten příklad s Javou nijak nesouvisel a i když by neříkal, že OOP je jediná správná cesta) Tohle nemám zapotřebí.

Taky je otázka, proč by OOP mělo být automaticky považováno za to správné řešení.

To nikdo neřekl. I v tom článku píšu:

… Z pohledu OOP se jedná o chybu nebo minimálně sub-optimální návrh, nicméně je otázka, jestli nutně musíme programovat objektově. Existuje např. mnoho úspěšných aplikací nebo celých informačních systémů založených na relačních databázích, kde žádné objekty nejsou a máme zde jen záznamy a procedury (či funkce). OOP by nemělo být nějakým náboženstvím (touhle fází si prošlo někdy na přelomu 80. a 90. let), ale nástrojem, který použijeme, když je nám to k užitku.

Připadá mi, alespoň podle této diskuse, že fází náboženského fanatismu a dogmatismu si v těchto letech prochází funkcionální programování.

Tahle diskuse začala celkem nevinně mimo téma pod nesouvisejícím blogem, ale zvrhlo se v a) útoky na Javu a b) fanatickou propagaci funkcionálna.

V OOP jazycích jako Java

Java není jen objektový jazyk, Java je multi-paradigmatický jazyk, stejně jako C++, Rust nebo D a další.

i když to tak mohlo z předchozí diskuse vypadat, nechci FP všude

Tak to jsem rád. (podle řady příspěvků v téhle diskusi to tak ovšem nevypadalo, ale možná mi to trochu splývá i s tím, co tu píše JS1)

To, co chci, je, aby se OOP necpalo všude

Viz citace z mého blogu výše.

[kralyk z abclinuxu]

Připadá mi, alespoň podle této diskuse, že fází náboženského fanatismu a dogmatismu si v těchto letech prochází funkcionální programování.

Přijde mi poněkud absurdní, že tohle napíše člověk, který je ochoten se zcela vážně hádat o tom, že funkce je vlastně jen specielní případ objektu*. Ale dělej jak myslíš.

Ono to může působit tím dojmem cpaní FP všude, protože historicky OOP bylo nacpaný "všude" (ne úplně ale hodně) a příznivec FP se prostě snaží tenhle status quo rozporovat, a tím pádem jakoby cpát FP "všude", ale cílem není nastolit nějakou hegemonii FP (jakou má/mělo OOP).

Například jsem si v munilosti myslel, že OOP je velmi vhodný na GUI, resp. widget knihovny a stromy widgetů, myslimže jsem tuhle myšlenku před nějakým časem i tady propagoval a hádal se o tom s JS nebo s někým Dnes mi přijde škoda, že třeba s Qt nebo GTK se moc nedá dělat GUI funkcionálně (jasně, nějaký knihovny a tak existujou, ale...). V zásadě má člověk mnohem větší šanci něčeho takovýho dosáhnout s tim smradlavým Electronem než s Qt, GTK apod.

Java není jen objektový jazyk, Java je multi-paradigmatický jazyk

No dnes už ano, protože se lidem podařilo do ní nějaký to FP vecpat Resp. samozřejmě nejenom FP, taky jiný koncepty...

*) Když už by člověk chtěl nutně dělat takovou analogii, tak by třeba v tom Haskellu OOP objektu odpovídal datový typ + typeclasses spíš než funkce (ale i tak je to hrozně redukcionistická / násilně šroubovaná analogie)...

[Bherzet]

No dnes už ano

Java je imperativní a objektově orientovaný jazyk. Pak je ještě taky (docela) silně typovaná atp., i když to už se za programovací paradigmata většinou moc nebere.

Ne každý imperativní jazyk je objektový a ne každý objektově orientovaný jazyk musí být imperativní.

[JS1]

Ja to vidim s tim FP trochu jinak. Podle me se ukaze referencni transparence jako velmi uzitecny nastroj (coz se uz deje) a tudiz ji budeme povazovat stale vice za zadouci vlastnost SW systemu.

FP jako paradigma podle me OOP nevytlaci ani neodmitne, spis jen zacleni. Je to videt treba na tech typovych tridach, v podstate proti OOP tridam nemaji zadnou nevyhodu (prijmeme-li nemennost) a jsou konceptualne jednodussi.

To ostatne plati pro spoustu veci v FP, umoznuje nam pojmenovat jiz zname koncepty jednoduseji. Napriklad tebou zminene vyjimky jsou jen specialni datovy typ. Neni tedy treba mit samostatnou podporu pro vyjimky (jako ma treba Java checked exceptions) nez pro jine navratove hodnoty v jazyce.

Takze k tomu viteznemu tazeni FP myslim dojde, protoze stavi mnoho veci na mnohem jednodussi a formalne presnejsi konceptualni zakladnu. Myslim, ze FP jako paradigma nakonec fakticky zanikne, protoze se proste stane naprosto prirozenym pristupem, podobne jako se to stalo u strukturovaneho programovani (to bylo take kdysi davno paradigma).

Takze je mylne chapat to jako nejakou nabozenskou valku. Bude to asi podobne, jako kdyz presna definice realnych cisel zmenila matematickou analyzu, ale pritom nevyvratila treba existujici Eulerovy vysledky. A z navrhovych vzoru v OOP (tech co zbydou jako uzitecne, coz si nejsem jisty, kolik jich bude) se stanou funkce nebo typy ve standardni knihovne (pokud uz tam nejsou).

Jinak k tomu GUI - ja souhlasim, ze to je stale jeste jedno z nejvhodnejsich mist pro pouziti OOP. V FP zatim neni zcela jasne, jak to delat, existuji ruzne pokusy (treba FRP) ale zadny se zatim nevynoril jako jasny vitez. A toho Qt nebo GTK je skoda, ale je to dobry priklad, jak rikas, kde prave zvolene paradigma ovlivnuje architekturu.

[kralyk z abclinuxu]

FP jako paradigma podle me OOP nevytlaci ani neodmitne, spis jen zacleni. Je to videt treba na tech typovych tridach, v podstate proti OOP tridam nemaji zadnou nevyhodu (prijmeme-li nemennost) a jsou konceptualne jednodussi.

Hm, na tom něco je, podobný případ jsou IMO třeba konstruktory. Zajímavý je, že tam se ironicky děje opačný postup - to, co mělo podporu v jazyce (C++, Java) přecházení jen do idiomu (mnohem volněji definovaného). IMO je to daný tím, že konstruktory jsou hrozný feature creep - kromě čisté konstrukce objektu z dílčích dat se používají pro netriviální inicializaci, získání default/triviální hodnoty, kopírování, konverzi, v C++ na move,... prostě taková holka pro všechno z toho je. Přitom většinu těch věci mnohem líp zastanou typeclasses (V Rustu traits, což jsou víceméně typeclasses s o dost omezenější higher-kindedness) - tj. Default, konverze atd. a move lépe řeší afinní typesystem.

To, že můžu pro cizí typ vytvořit "konstruktor" konvertující z mého typu je boží (spolu s implikacemi pro generickej kód). Ovšem kdo neviděl, neuvěří.

V FP zatim neni zcela jasne, jak to delat, existuji ruzne pokusy (treba FRP) ale zadny se zatim nevynoril jako jasny vitez.

To je to, co dělá např. Elm? Mně se ten přístup líbí, ale nemam s tim dostatek praktický zkušenosti, abych usoudil, jestli to je/není opravdu dobrý a v jakých případech...

[JS1]

S konstruktory souhlasim. O Elmu moc nevim (snazim se webovemu programovani vyhybat), ale jak to chapu, to je jen reaktivni programovani. Pak je jeste funkcionalne-reaktivni programovani, coz pouziva spojity cas misto diskretnich udalosti. Zkousi se ruzne veci. Ale asi mas pravdu, zda se, ze posledni dobou je v GUI hitem nejaka forma Flux patternu (treba prave jako ma ten Elm).

[Bherzet]

„Franta chce nacpat objekty všude a navíc Java smrdí.“

A navíc jsi reprezentant té javovské kultury, ergo smrdíš taky :D

[kralyk z abclinuxu]

Franta zcela určitě nesmrdí, je to pravděpodobně (aspoň podle toho málo, co vím) dobrý vývojář, akorát se při čtení jeho textů / manifestů / názorů nemůžu zbavit dojmu, že se mi v tom snaží vnutit nějaké řešení nebo pohled, u kterého si neuvědomuje, že není tak obecný / obecně vhodný, jak si myslí...

[Bherzet]

Budu se opakovat z nějaké starší diskuze, ale alternativou k FP je imperativní programování, OOP je na to podle mě ortogonální. Odersky (autor Scaly) si to myslí taky.

[JS1]

Já se nějak nemůžu zbavit dojmu, že funkcionální programování o funkcích moc není.

Moje dost hruba definice funkcionalniho programovani je ta, ze je programovani s funkcemi, jak jsou definovane v matematice, tzn. pro kazdy vstup vraceji jen jeden a vzdy tentyz vystup (referencni transparence). Protoze treba random() se bezne oznacuje jako funkce, ale funkce v matematickem smyslu to neni.

A pokud se bavime specificky o funkcionalnim programovani v rodine ML jazyku (postavenych na Hindley-Milner typovym systemem nebo nejakem pribuznem typovanem lambda kalkulu), pak tam je vsechno (vicemene) bud funkce (ackoli jsou definovane jako primitiva, nikoli pomoci treba teorie mnozin), nebo typ.

Napriklad primitivni hodnoty (jako 3, "ahoj") lze interpretovat jako konstantni funkce. Algebraicke datove typy (a v podstate vsechny slozitejsi typy) jsou take formalne definovany pomoci funkci - treba produkt je definovan pomoci funkce konstruktoru (z nekolika hodnot urcitych typu vytvori souctovy typ) a projekci (ze souctoveho typu nam vrati prislusny prvek). Takze vsechno je nakonec funkce a cely program se slozi jako jedna velka funkce.

Immutable data jsou pak jen dusledek, v matematice nic jako "mutable data" nebo "promenna" neexistuje, jenom funkce, ktere operuji s nemennymi objekty.

To co popisujes ty, veci jako Lisp nebo Clojure, to nejsou striktne vzato funkcionalni jazyky (nezarucuji referencni transparenci), ten zpusob programovani (immutable data) bych nazval spis funkcionalnim stylem.

[Bherzet]

No, je a není. Je o nich z toho hlediska, že funkce je tam důležité primitivum, důležitá „stavební jednotka“, ale spíš jsou důležité ty principy okolo. Občas jsem nestačil zírat, co někdo považuje za „funkcionální programování“ jen proto, že se mu to v JavaScriptu hemží „function() {“.

Ale současně si myslím, že i to „opravdové“ funkcionální programování se dost přeceňuje. Některé myšlenky FP jsou velmi dobré a mají svoje opodstatnění, a je pravda, že někdy vyžadují i podporu jazyka a okolních knihoven, aby je šlo uplatňovat naplno, ale že bych viděl v „čistě funkcionálních jazycích“ nějaký hlubší přínos, tak to prostě zatím nevidím.

[xkucf03]

P.S. Na ten Haskell jsem se díval už před lety (propaguješ ho tu už dlouho), jindy jsem si koupil třeba knížku o Lispu, pak tu mám nespočet různých PDF… Je to v kategorii zajímavých věcí, kterým se možná někdy budu víc věnovat, ale nemá to až takovou prioritu, protože v tom nevidím takový přínos pro praxi.¹ Asi je to dost dané i tím, že jsem s výsledky svého programování celkem² spokojený a nemám moc potřebu to vylepšovat změnou jazyka. Ta Java slouží dobře, není to dokonalý jazyk, ale rozhodně to není nějaká brzda, kvůli které by selhávaly projekty. A když se podívám na to, s čím mají problémy junioři v týmu, tak to prakticky nikdy není Java³ – mívají spíš problémy 1) se složitostí IT obecně, příliš mnoho technologií, formátů, standardů, heterogenní prostředí… 2) s nepochopením zadání, s komunikací s analytiky, s neznalostí doménové oblasti… A tohle jsou věci, které opravdu nezmizí s tím, že aplikaci samotnou budeme psát v Haskellu místo v Javě.

Ano, můžeš říct, že kdyby celý svět přešel na Haskell nebo Lisp a psalo se v něm úplně všechno, tak zmizí část těch problémů z kategorie 1). Částečně možná ano⁴, ale je to utopie, která nikdy nenastane.

Optimalizovat se dá na mnoha místech, ale rozumné je začít tam, kde to má největší efekt. Takže možnost zlepšení vidím spíš v tom, že se software rozdělí na menší části, které budou mít jasně definované závislosti, a to, co není nezbytné, bude volitelné a bude na uživateli, zda si danou část (a její závislosti) nainstaluje. Dokud se lidi nenaučí software rozumě strukturovat a nenutit uživatelům zbytné závislosti, tak nemá smysl se bavit o tom, že by to měli přepsat do Haskellu. Jinak z toho bude jen takový virtue signalling – v programu bude kus Haskellu, aby to vypadalo báječně, ale pod tím budou nesmyslné závislosti čítající miliony řádků v céčku. Totéž se dá říct o Lispu, Scheme, Pythonu – pokud je to jen vysokoúrovňový obal nad původními céčkovými knihovnami. To už je zajímavější takové D nebo Rust, kde je přeci jen asi větší tendence psát si i ty nízkoúrovňové věci ve svém jazyce (viz třeba Redox, kde píší úplně celý OS v Rustu odzdola až po GUI).

_{[1] jak např. píšu v tom článku, užitečnější mi přijdou multi-paradigmatické jazyky, kde můžeš programovat i funkcionálně, ale není to jediná správná cesta
[2] jasně, taky dělám chyby, každý je dělá, a byl jsem i u věcí, které se nepovedly, tím se člověk učí, ale funkcionální jazyk by to nezachránil snad asi nikdy, není to všelék a ty nepovedené projekty mají většinou jinou příčinu
[3] tu znají ze školy, navíc je to celkem jednoduchý jazyk; když dělají chyby na úrovni kódu, tak je to jednou za čas, přijde se na to hned při revizi nebo párovém programování a příště už tu chybu neudělají
[4] i když je otázka, jak moc by to bylo dané přechodem na funkcionálno a jak moc přechodem na vyšší programovací jazyk obecně a zbavení se nízkoúrovňového céčka; Ono kdyby se všechen software přepsal do takového D nebo Rustu, tak by to taky dost pomohlo v tomhle směru.}

[kralyk z abclinuxu]

To už je zajímavější takové D nebo Rust

Tak zrovna ten Rust sdílí hodně konceptů s Haskellem, respektive se všemi ML jazyky (Rust byl původně napsán v OCamlu). S nadsázkou se dá říct, že Rust = C++ + Haskell + Cyclone. (Samozřejmě z těch jazyků si bere jen některý věci + přidává svoje.)

[kralyk z abclinuxu]

Zapomněl jsem připsat pointu Pointa je, že jazykům jako Haskell nebo OCamlu nebo F# se můžem smát, že jsou nepraktické a že to používá jen pár vědců ve svých slonovinových věžích, ale faktem je, že bez nich by třeba ten Rust nebyl nebo by byl mnohem podobnější C++ (i s těmi problémy, které to přínáší; koneckoncků tohle je problém Dčka - je celkem fajn, ale není dostatečně jiné, dostatečně inovativní na to, aby ho lidi používali místo C++).

[Bystroushaak]

koneckoncků tohle je problém Dčka - je celkem fajn, ale není dostatečně jiné, dostatečně inovativní na to, aby ho lidi používali místo C++

Problém Dčka je, že totálně prosrali svojí dobu přechodem z D1 na D2, což byl naprosto gigantický pain, srovnatelný například s přechodem z pythonu2 na python3. Akorát D mělo podstatně menší komunitu než python, tak na to dojelo podstatně hůř.

[kralyk z abclinuxu]

Jo, to máš asi pravdu. Já se k D dostal až dávno potom v době D2. Je pravda, že v době, kdy bylo nový, asi mělo dost co nabídnout oproti tehdejšímu C++ ...

[JS1]

Asi je to dost dané i tím, že jsem s výsledky svého programování celkem2 spokojený a nemám moc potřebu to vylepšovat změnou jazyka. Ta Java slouží dobře, není to dokonalý jazyk, ale rozhodně to není nějaká brzda, kvůli které by selhávaly projekty.

No ja ten pocit nemam. Kdybys v tom nevidel problem, nepsal bys dlouhe blogposty na tohle tema.

Tady nejde o to, abys ten Haskell pouzival. Jde o to, ze je oknem do sveta, kde veci funguji jinak. Nejakych 50 let pred tim, nez vznikly navrhove vzory, matematici se zabyvali studiem jejich vzoru, v teorii kategorii. A delali to mnohem rigorozneji. A Haskell je takovy most do toho sveta. (Na druhou stranu, moje zkusenost s Haskellem je, ze pokud to clovek opravdu nezkusi pouzivat, tak ty hlavni myslenky proste nepochopi. Proste je potreba ten most parkrat prejit, aby si clovek uvedomil jeho uzitecnost.)

Mam kamarada jako ty, taky Javista, ale kdyz mu reknu, ze by si mel nastudovat to ci ono, tak ne, staci mu Java. Pritom mi rika, chtel by videt jazyk, ktery resi dobre a efektivne paralelismus. Tak jsem mu rikal Rust, a porad nic.

Ja chapu, je to svym zpusobem pohodlne a prijemne zkusit si tyhle veci objevit sam. Obcas je to fajn, ale jak se rika, mesic v laboratori ti usetri odpoledne v knihovne. Jde o to, ze problemy, ktere se snazis resit, uz byly studovany (treba prave u tech funkcionalnich systemu, jako Nix), casto mnohem rigorozneji, jenom je to napsane v jinem jazyce (ted nemyslim programovaci jazyk, myslim skutecne "lidsky" jazyk, v tomhle pripade treba teorie typu nebo lambda kalkulus).

Stezujes si, ze je problem, kdyz je prilis jazyku a pristupu. Ale to co sam delas presne na tohle vede. Lide si nenastuduji, co existuje, uz existujici metody a formalismy, a snazi se tentyz problem vyresit znovu, sami, a bez dostatecneho vzdelani. Vysledek je casto plny chyb, kterym by se dalo predejit, a asi nejhur, nova vlastni terminologie.

[xkucf03]

Asi je to dost dané i tím, že jsem s výsledky svého programování celkem2 spokojený a nemám moc potřebu to vylepšovat změnou jazyka. Ta Java slouží dobře, není to dokonalý jazyk, ale rozhodně to není nějaká brzda, kvůli které by selhávaly projekty.

No ja ten pocit nemam. Kdybys v tom nevidel problem, nepsal bys dlouhe blogposty na tohle tema.

Zrovna ty problémy, o kterých tu mluvím, se týkají spíš softwaru, kde jsem v roli uživatele, než softwaru, kde jsem v roli vývojáře. Vadí mi, že spousta programů, které jinak používám rád a jsou užitečné, má příliš mnoho zbytečných závislostí, příliš vysokou vlastní komplexitu nebo jsou špatně strukturované. Proto o tom píšu.

Co se týče softwaru, který vyvíjím: u zákazníků narážím na různé problémy, to by bylo na dlouhé povídání. Velké problémy bývají např. s tím, když někdo oslabí typovou kontrolu – třeba tím, že narve data do nějaké HashMapy na jednom konci programu a na jiném nebo v jiném systému je z ní čte, hledá pomocí textových klíčů, které nejsou nikde pořádně definované, jsou rozeseté na mnoha místech v kódu… tím degraduje Javu na úroveň dynamických/skriptovacích jazyků, kde program sice půjde spustit, ale pak za běhu bude padat na tom, že metoda nebo pole neexistuje. Obecně: špatně definovaná rozhraní. Pak jsou často problémy s tím, že se v kódu nechá nějaké provizorní řešení, programátor to třeba myslí dobře, chtěl se k tomu vrátit a udělat to líp, ale už na to nedostal čas a byl převelen na jiné úkoly (to jsou spíš ty společenské problémy než technické). Obecně: narůstající technologický dluh a organizace a procesy nastavené tak, že ho neřeší a obecně se zanedbává údržba. Často ta firma má nějakou špatnou zkušenost, pustila se do interního vývojového projektu, který ale nedopadl a akorát se v něm propálily peníze, vývojáři slibovali něco, co nakonec nedodali, nebo byl projekt předčasně ukončen – pak je v takové firmě nechuť investovat do nějakého rozvoje a je tam nedůvěra mezi vedením a vývojáři, vedení si myslí, že když dá vývojářům volnost a nechá je vylepšovat software a snižovat technologický dluh (mimochodem pro hodně lidí se z toho právě stalo sprosté slovo, kterým není radno je dráždit), tak se budou akorát flákat a ani to nejde moc poznat (stejně jako když dostanou čas na studium). Na druhé straně jsou vývojáři znechucení, že se neinvestuje, zanedbává se údržba, nedělá se žádný vlastní vývoj a programuje se jen to, za co bezprostředně zákazník zaplatil – a programuje se to způsobem, aby to bylo co nejlevnější, bez nějakých velkých ohledů na kvalitu. To vede k dalšímu pokřivování systému a prohlubování technologického dluhu. Pak tu máš třeba problém nejasné definice produktu a vize: není definované, jak moc obecné a znovupoužitelné by to mělo být – takže vývojáři nějakou úroveň obecnosti nastřelí od boku – a často se netrefí. Buď je to moc nepružné, psané na míru jednomu zákazníkovi, jsou v tom zadrátované natvrdo různé závislosti a konkrétní pravidla a nejde to použít jinde. A nebo se snaží vyvíjet něco moc obecného, programují vlastní frameworky, napíší hromadu kódu, od kterého si slibují, že se použije na deseti dalších projektech… a pak třeba další zákazníci nejsou nebo se nějaký objeví, ale obchodníci mu slíbili vývoj na míru místo spíše krabicového řešení, kterému by se měl (aspoň trochu) přizpůsobit – a zákazník si teď diktuje podmínky, které s tím dosavadním frameworkem nejsou kompatibilní (a nechce z nich ustoupit, protože má pocit, že zaplatil za vývoj na míru).

Mohl bych pokračovat dál, ale pro ilustraci to asi stačí. Tyhle problémy prostě nejsou řešitelné přechodem na Haskell, ani tím, že se programátoři naučí Haskell a pak budou programovat líp v Javě. Podle mého víc pomohou jiné věci a ten čas se dá investovat líp. Kdo ještě nečetl, tak by si měl přečíst knížky Effective Java, Practical API design, Dokonalý kód a Čistý kód. Jsou to celkem základy, ale řada lidí se tím neřídí, a pak to podle toho vypadá. Ostatně, někteří se míjejí i se základy, které se učí v prváku na VŠ. Mnohde ve firmách projde a dostane se do produkce i software, který by ti neuznali ani jako semestrálku na VŠE. Ale jak už se to jednou prodá a nasadí k zákazníkům, tak se musí držet zpětná kompatibilita a těžko se s tím něco dělá.

Mimochodem, ty jsi tu tuším psal, že teď taky programuješ v Javě. Chystáte přechod na Haskell? Navrhoval jsi to u vás? Co na to kolegové a šéfové říkali? Učí se ostatní Haskell aspoň ve volném čase, aby jim šla líp Java?

Ja chapu, je to svym zpusobem pohodlne a prijemne zkusit si tyhle veci objevit sam.

Já tu ale nevymýšlím žádné nové a revoluční teorie. Modulární architektura není nic nového, reprodukovatelná sestavení (#656) jakbysmet. To, že bys měl měl stavět na dobře definovaných rozhraních, to se ví už dlouho a říkali to už mnozí přede mnou. Zvlášť Králík vypadá, že je mu nepříjemné slyšet tyhle věci „od Javisty“ – tak ať si to přečte od někoho jiného, ale na obsahu to nic nemění. Spousta lidí se rozčiluje nad bloatwarem, máš tu třeba lidi, kteří používají KDE a nesnášejí GTK a nějaký program odmítnou používat, jen proto, že si nechtějí systém „zasírat“ GTK knihovnami. Totéž z druhé strany: někdo používá Gnome a nechce mít v systému Qt knihovny, což mu brání používat Qt/KDE programy, které by mu jinak byly užitečné. Podívej se na komplexitu závislostí třeba u balíčku qemu – to je naprosto brutální strom a zdaleka ne všechno z toho potřebuješ, zvlášť pokud by sis chtěl postavit minimalistický hypervizor a vše ostatní pouštět až uvnitř virtuálek. Nebo se podívej na vnitřní komplexitu a závislosti WWW prohlížečů (Firefox, Chromium), v průběhu let to dosáhlo naprosto obludných rozměrů – přitom je to software, na kterém jsou závislí víceméně všichni a potřebuješ ho dneska i pro triviální úlohy (např. zadat objednávku, přečíst si článek nebo jízdní řád, vyřídit poštu…). Pak tu máš extrémisty typu Suckless, kteří nesnášejí pomalu všechny technologie a nemůžou používat skoro nic… do takové krajnosti to hnát nechci, mám představu softwaru, který je z uživatelského hlediska podobný tomu dnešnímu, ale bude lépe strukturovaný, spolehlivější a bezpečnější – říkám: pojďme dělat software trochu víc modulárně, ať ten, kdo ho používá, si instaluje a spouští jen ty části, které potřebuje. A říkám: pojďme ty části propojovat pomocí dobře definovaných rozhraní.

Vývoj takového softwaru je náročnější/dražší. Ale na druhé straně tu jsou rezervy, ze kterých lze brát, viz #686 (poslední odstavec).

[JS1]

A říkám: pojďme ty části propojovat pomocí dobře definovaných rozhraní.

Fajn, chces se bavit o API? Na to se prejit ten most (smerem k teorii kategorii a matematice vubec) taky bajecne hodi. Ono totiz to co Java programatori povazuji za API (interface) je asi tak ta nejmene zajimava cast, podstatne jsou ruzne algebraicke vlastnosti toho API. Tim volne parafrazuji Erika Meijera, ktery to hodne zduraznuje, protoze mu to pomohlo pri navrhu Rx - Observable je dual k Iterable. Jenze kolik Java programatoru tusi, co je dualita?

(A to opravdu neni nejaky dis na Java programatory, spis na Javu jako takovou, zejmena syntakticky. Vyjadrovat funkce vyssiho radu je v Jave velice syntakticky obtizne a tudiz to blokuje ten zpusob uvazovani. Je to asi jako ucit se nasobit s rimskymi cislicemi. Ja si naopak myslim, ze programovat v Jave je tezsi nez programovat v Haskellu - a vyzaduje tudiz vyssi inteligenci, aby se veci delaly spravne. A kdyz vidim to casto zcela zbytecne usili Javistu vynalozene na to pochopit veci, ktere jsou konceptualne jednoduche, jen v Jave zbytecne slozite zapsane, tak mi to prijde dost skoda.)

Hodne tech algebraickych vlastnosti lze reprezentovat pomoci typu (a proto je dobre studovat typove teorie). Napriklad jak jsem ted odkazoval ten post o linearnich typech, tam je hezky priklad rozhrani/protokolu, kde muzeme pomoci linearnich typu zajistit nejake jeho vlastnosti. Ale pro nekoho, kdo neni zvykly na ML syntaxi, je to tezke cteni.

[Bherzet]

FYI: Pracoval jsem na projektu, kde z matematiky měli všichni kromě mě doktorát a byla to z hlediska architektury prostě úplně normální javovská codebase. Úplně bych to nepřeceňoval.

[JS1]

Coz samozrejme neni validni argument. Navic, ja studoval pred 20 lety (aplikovanou) matematiku (a programuji taky od zakladni skoly), a presto mi trvalo nejakych 15 let pote, nez jsem si uvedomil uzitecnost veci jako teorie kategorii, teorie typu a lambda kalkulus pro programovani. A nebylo to proto, ze bych se nesnazil, uz na skole jsem koukal na Coq, ale byla to pro me tehdy spanelska vesnice, ktere jsem nebyl schopen porozumet.

Ten most je proste pomerne novy, a i kdyz znas tradicni logiku a matematiku, tak je zde stale hluboka jazykova bariera. Nastesti v poslednich 20 letech se alespon v ramci CS Haskell bezne uci, takze se lide s tou syntaxi (a trochou tech kategorii) setkaji.

[JS1]

enže to není tak jednoduché. Stačí, aby se z té „ošklivé stavové třídy“ používala víc než jedna metoda, a rázem se situace obrátí: zatímco při tom objektovém přístupu mám pořád jednu továrnu, která vyrábí jeden objekt – a ten už má všechny metody zabalené v sobě, tak při tom funkcionálním bych musel každou volanou funkci „indirektovat“ (nejspíš přesouvat do parametrů, nebo prostě jinak umožnit modifikovat ten scope tak, aby na ty skutečné funkce neviděly), ručně.

Ne. Spravne sis vsiml, ze v FP muzes predavat funkce opacnym smerem, nez v OOP objekty, a vyjde to nastejno. Ale v FP (treba Haskellu) je mozne zabalit vic funkci do jednoho typu, ktery lze pak predat a aplikovat, takze to v praxi nepredstavuje problem.

Dalsim zpusobem, jak to resit, jsou prave monady. V Haskellu by se proste "mockovalo" tak, ze by se prislusna funkce (kterou chceme testovat) zapsala jako polymorfni pro nejakou monadickou typovou tridu. A pak by se jen volala s prislusnym konkretnim typem monady (v testu s jinym nez v realu), ktera vlastne nainjektuje interpretaci toho, co ta funkce chce delat. (Viz ten clanek co jsem tu postoval o free monadach.)

Jinak i Haskell podporuje vselijake formy metaprogramovani, a rozhodne to neni tak silene jak jsi to napsal niz.

[Bherzet]

Ale v FP (treba Haskellu) je mozne zabalit vic funkci do jednoho typu, ktery lze pak predat a aplikovat, takze to v praxi nepredstavuje problem.

Aha, koukám, že Haskell má něco jako interface a asi se tam dá nějak řešit i dědičnost. Takže to tam půjde poskládat jinak, taky dobře a elegantně, a akorát se ve výsledku dospěje zas k trochu jinému patternu :)

[JS1]

Eh, zda se, ze jsi to porad nepochopil. Zalezi jak ty vzory chapes. Jak je chapu ja, jako urcite konstelace trid nebo obecne objektu, ktere vidi programator, ale pocitac je nezna. To si prave myslim, ze neni potreba, protoze muzeme ty konstelace vzdycky (v dostatecne expresivnim jazyce) zaobalit do nejake vhodne funkce nebo typu.

Samozrejme, muzes tu funkci nebo typ (nebo algebru) dal nazyvat vzorem, ale ja myslim, ze to vzor v puvodnim vyznamu uz neni. (Je treba monoid vzor?) Protoze jakmile se z toho stane konkretni funkce/typ/algebra s dobre definovanou strukturou a semantikou, lze pouziti toho vzoru komunikovat explicitne, primo pouzitim te funkce v programu, a uz nebude jen na cloveku, aby ten vzor rozpoznal jako konstelaci.

Proste, u veci, co oznacujeme za vzory, tu strukturu a semantiku dobre nezname, nebo neumime vyjadrit. Treba funkce map, ktera pracuje s prvky nejake kolekce, neni vzor, jelikoz ma jasne definovanou semantiku. Mohl to byt ale vzor (idiom) v jazyce, ktery neumi predat funkci.

[JS1]

Jo, ale co je taky mozny mit, v typovanem jazyce, urcitou sadu funkci (urcitych typu), ktere se samy dohromady slozi (takova self-assembly) v urcitou konstelaci. Pak to podle me taky neni vzor, protoze programator nemusi resit, jak to slozit, to jak je pripustne to slozit je dane typem tech funkci. Takze nemusi vedet, ze urcity vzor existuje, proste pokud to uspesne slozi, tak ten vzor vlastne pouzije. Ten vzor je pak proste presne dany typy tech funkci, neni treba jej komunikovat nejak navic.

[Bherzet]

Nah, pochopil. Šlo mi o to, že si uděláš „interface“, který si pro účely produkčního/testovacího kódu naimplementuješ jinou sadou funkcí. Ty funkce taky můžou vracet nějaká data, která nemusí být vždycky primitivní, takže by se ti hodila dědičnost nebo jiný mechanismus, kterým docílíš toho, že v kódu můžeš pracovat s atributem . x bez ohledu na to, jestli to děláš nad typem, který vypadl z „produkční“ nebo „testovací“ funkce. A tohle bych ve výsledku považoval za pattern, přestože tam není nic, co by se dalo odebrat, aniž by to ten kód o něco ochudilo (samozřejmě vycházím z předpokladu, že to takhle strukturovat potřebuješ kvůli testům, dělat to zbůhdarma všude je nesmysl).

[JS1]

No, jestli jenom pouziti rozhrani s dvema implementacemi povazujes za navrhovy vzor, to jsi ten pojem hodne ztrivializoval.

Navic jak uz jsem zminil, v Haskellu casto k testovatelnosti neni nutne delat ani to. Casto staci ten program napsat dostatecne elegantne a zaroven obecne.

[Bherzet]

Tak to, co jsem popsal, je v podstatě zase ta dependency injection, že… A nemyslím si, že jsem ten pojem ztrivializoval. Určitě by to i v Haskellu šlo naprasit nějak jinak a fungovalo by to stejně (vč. testovatelnosti), ale už by to nebylo právě tak elegantní. A o tom návrhové vzory podle mě jsou. Nemyslím si, že se všechny návrhové vzory dají nacpat do jazyka nebo knihoven.

[Bystroushaak]

Nemyslím si, že se všechny návrhové vzory dají nacpat do jazyka nebo knihoven.

Proč?

[Bherzet]

Ty bys ten příklad zobecnil jak, aby to šlo nacpat do jazyka/knihoven?

[JS1]

Tak porad sero, zda se. V Haskellu ani vlastne neexistuje moznost to resit pomoci DI (jak ja chapu DI), protoze Haskell nema nic jako tridu, kam by bylo mozne ten odkaz na injektovanou tridu umistit - predava jej implicitne v kazde "metode" zvlast. To za prve.

Ano, muzes se snazit pochopit co se deje v Haskellu v terminech Javy, ale to vyzaduje, jak uz jsem psal, hodne hodne gumovou definici toho ktereho navrhoveho vzoru. K bodu, kdy ty navrhove vzory prestanou davat smysl jako neco rozlisitelneho.

A za druhe, vsechno, co si dokazu predstavit, ze potrebuje v Haskellu nejakou specialni peci kvuli mockovani, se mi zda byt dusledek spatneho (nedostatecne obecneho) navrhu. Treba nedodrzeni principu "funkcionalni jadro, imperativni slupka".

Ja bych se rad bavil vic konkretne, ale zda se, ze Haskell neznas, takze se to opravdu tezko vysvetluje.

[kralyk z abclinuxu]

Ano, muzes se snazit pochopit co se deje v Haskellu v terminech Javy, ale to vyzaduje, jak uz jsem psal, hodne hodne gumovou definici toho ktereho navrhoveho vzoru.

Já tomu na druhou stranu rozumim, člověk se snažít pochopit neznámé v termínech toho, co už zná.

Já třeba do Rustu šel se znalostí C++, takže jsem neměl problém s borrow-checkerem (protože v C++ se řeší stejné problémy), ale musel jsem vstřebat ADTs, traits atd. a vlastně třeba Haskellovské typeclasses stále chápu spíš jen v intencích Rust traits, což asi není dobře, protože typeclasses jsou mocnější.

Když se člověk posune z jazyka X do Y, kde Y bude mít jiný paradigma, tak celkem nevyhnutelně v té prvotní fázi "prasí" do Y postupy z X, ale nevadí to, protože pomocí X poznává Y (samozřejmě pokud se v té fázi nezasekne)...

Ja bych se rad bavil vic konkretne, ale zda se, ze Haskell neznas, takze se to opravdu tezko vysvetluje.

Mě napadá jeden příklad, který budou znát i javisti: push parser vs pull parser. Pro push parser je potřbea někde subclassovat nějakej event handler a injektovat ho do parseru. S pull parserem nic takovýho dělat nemusíš, prostě z toho taháš data a transformuješ je...

[Filip]

push parser vs pull parser. Pro push parser je potřbea někde subclassovat nějakej event handler a injektovat ho do parseru. S pull parserem nic takovýho dělat nemusíš, prostě z toho taháš data a transformuješ je...

Pull parser je tedy podle tebe lepší?

[JS1]

Neni lepsi, jen pro jeho pouziti nepotrebujes IoC (coz je nejspis jen Javovsky nazev pro dualitu, co jsem zminil). V Haskellu se vlastne vsechny vedlejsi efekty realizuji pres IoC, takze neni potreba to IoC delat "dvakrat".

[Filip]

Viz co jsem psal @kralyk z abclinuxu níže. Zajímalo by mě, jak se tohle řeší v haskellu. Rád si rozšířím obzory. Nějaký praktický příklad kódu? A co myslíš tím "dvakrát" IoC?

[JS1]

No, v Haskellu to funguje tak, ze pokud chce funkce f (program) treba zapisovat vystup na zaklade vstupu a, tak bude mit typ neco jako f :: a -> IO (). Formalne to totiz probiha tak, ze ta funkce f nic s vystupem nedela, ale jen vraci "recept" (to je ten typ IO ()), jak zapsat hodnotu typu a na vystup. Hlavni funkce v programu (odpovidajici main) se pak sklada volanim mnoha funkci a vlastne jen vraci kompletni recept, typ IO ().

V momente, kdy se pusti Haskellovsky program, se jakoby paralelne zacne tento recept jak konstruovat (to je vyhodnoceni te hlavni funkce, tedy beh toho Haskellovskeho programu), tak i interpretovat (tim se provadi vsechny ty operace, ktere prisly s tim receptem).

Co muzes udelat je definovat nejakou funkci obecneji, napriklad misto toho, aby vracela typ IO (), muzeme ji nechat vratit typovou tridu (coz je neco jako interface v Jave) vhodnych receptu (nad kterymi jsou definovany funkce, co ta funkce f chce volat).

Dejme tomu, ze chci treba zapisovat na obrazovku. Muzu definovat f, ze f :: Console m => a -> m (), tedy f ma typ, ktery bere argument typu a, a vraci recept z typove tridy Console. Uvnitr f pak pouziji funkce z te typove tridy Console misto funkci, ktere vraci typ IO ().

Dale mohu vysvetlit, ze typ IO patri do typove tridy Console. Stejne tak si muzu definovat jiny typ receptu, dejme tomu ConsoleMock, o kterem taky prohlasim, ze patri do typove tridy Console, ale dela neco jineho, treba mi jen vrati seznam operaci, ktere se mely provest (nebo je proste bude ignorovat). Ty typy tech receptu popisuji ruzne interpretry toho, jak se ma s temi efekty nalozit.

No a pak kdyz chci otestovat f, tak ji necham vratit (v Haskellu se funkce da dispatchovat i podle navratoveho typu) typ ConsoleMock, zatimco kdyz ji chci proste provest, necham ji vratit typ IO. To dispatchovani f se provede na zaklade konkretniho typu m, ktery se tam vlastne pokoutne dostane diky tomu zapisu Console m =>, lze si to predstavit tak, ze ta funkce f je definovana genericky v tom typu m.

Takze vidis, ze jsme implementaci f vubec nemuseli resit, nemuseli jsme do ni nic vkladat. Ta IoC je tam uz od zacatku, tim, ze f vraci recept, ktery se pak interpretuje. Jedine, co musime udelat, je zobecnit typ te funkce tak, aby vracela obecnejsi recept (coz neni vzdy nutne delat, zavisi to pripad od pripadu), a my mohli podstrcit jiny interpretr toho receptu. (Bohuzel by asi pro tyto ucely bylo byvalo praktictejsi, kdyby IO () v Haskellu byla typova trida, ale i to ma svoje uskali a ja to nechci ted resit, to jsou temata na dizertace.)

Co jsem nerozebiral, ze to Console by asi v praxi bylo odvozene od Monad, a jak je skladat dohromady. Na to jsou v Haskellu tradicni mechanismy, ktere to zprehlednuji. Ale v zasade pod kapotou vzdycky bezi urcite IoC.

Kdybys mel vic funkci, postup by byl podobny, vsechny bychom definovali nad typem z typove tridy Console, pro ucely testovani podstrcili stale ten nas typ ConsoleMock, a pro ucely behu bychom proste jen podstrcili typ IO (coz se pravdepodobne stane implicitne diky Haskellovske typove inferenci, vesmes nebude nutne to nikde explicitne psat).

Nicmene jen malokdy je tohle potreba, protoze ve slusne napsanem kodu vetsina funkci, co dela zajimave veci (ktere stoji za to testovat), je definovana bud jako ciste funkce, nebo jsou definovane nad nejakou vhodnou typovou tridou (ve stylu te Console), a tudiz je lze velmi snadno bud primo testovat nebo mockovat bez komplikaci. Coz je vlastne i lepsi, protoze je to obecnejsi a zlepsuje to znovupouzitelnost.

[Filip]

Uff, to je docela komplikované... V případě, že budu data číst ze vstupu a vzápětí posílat na výstup, takže vlastně jen transformovat nějaký stream, tak si to tedy dokážu nějak představit.

Ale jak to bude vypadat v případě, že chci nějaká data (třeba konfiguraci) naparsovat jen jednou, pak si je držet v paměti a opakovaně používat (a pak třeba zase někdy znova načíst a mít čerstvou konfiguraci)? Na kterém místě v tom kódu se rozhodne, která data uchovat v paměti a která naparsovat pokaždé znova? A jak se rozhodne o tom, že nějaká data už nebudou potřeba a může se ta paměť dealokovat?

[JS1]

No to bych muse vysvetlit monady (to jsou matematicky formalizovane ty recepty), a to se mi uplne nechce (na Internetu je spousta tutorialu lepsich nez ja spichnu na kolene za pul hodiny). Cteni funguje taky tak, ze se vytvori recept. A opakovane cteni a zapis je jen recept, ktery kombinuje recept cteni a recept zapisu a pak rekurzivne odkazuje (vola) sam sebe. Pokud je neco potreba pritom drzet v pameti, proste se to predava mezi temi recepty.

V zasade to funguje jako treba ve skolni algebre, cely vypocet je jen postupne zjednodusovani nejakeho vyrazu neustalym dosazovanim za parametry do funkci. V momente, kdy je jasne, ze nejaky podvyraz uz neni potreba, tak se zapomene. A v momente, kdy je jasne, ze vysledkem vyrazu je "nacti data z disku a pak vypocitej X", tak se nactou data z disku a pokracuje se vypoctem X.

Programatori maji casto s Haskellem problemy, protoze ano, vyzaduje to zahodit co vedi o programovani, co pochazi z imperativniho sveta. Je to jako ucit se programovani znovu.

V imperativnim svete posilame postupne data (objekty) metodam, ktere pak s nimi neco provedou. V ryze funkcionalnim svete to jde naopak - obdrzime recepty jak neco udelat a ty slozime; vysledkem neni pozmeneny objekt nebo stav, ale novy recept.

Celkove to neni slozitejsi (naopak explicitni popis toho receptu ma celou radu vyhod), a da se to pak zase zaobalit do imperativni syntaxe (coz je svym zpusobem druha IoC, ktera neguje tu prvni). To co jsem popsal (i kdyz to tak z toho popisu nevypada) vede na celkove jednodussi kod - nepotrebujes DI.

[kralyk z abclinuxu]

Ale jak to bude vypadat v případě, že chci nějaká data (třeba konfiguraci) naparsovat jen jednou, pak si je držet v paměti a opakovaně používat (a pak třeba zase někdy znova načíst a mít čerstvou konfiguraci)?

TL;DR monáda nemusí držet (jen) I/O instrukce, můžou držet (taky) nějakej stav. Stav se pak předává z funkce do funkce, kde ty funkce ho můžou nějak transformovat.

A jak se rozhodne o tom, že nějaká data už nebudou potřeba a může se ta paměť dealokovat?

No nějaká funkce už prostě ty data nepošle dál (vyjme z předávanýho stavu).

[kralyk z abclinuxu]

Pull parser je tedy podle tebe lepší?

No, preferuju to, minimálně mi přijde obecnější (IMO push parser je v podstatě složenej z pull parseru + smyčky, která volá event handler).

Ale zas úplně nechci vynášet nějaký univerzální rady jak věci architektovat, od toho tu jsou jiní Je klidně možný, že pro nějaký použítí je vhodnější push parser, to nemůžu vyloučit...

[Filip]

Jestli ti to vyhovuje, přijde jednodušší atd. a nenarážíš např. na problémy s výkonem, tak je to validní přístup.

Když se podívám na ty dvě základní varianty push a pull parserů, tak rozdíl je v tom, že u push parseru je ta řídící smyčka vystrčená mimo tvoji aplikaci. To má dva následky 1) část kódu je na jednom místě (v knihovně) a neduplikuje se ve všech aplikacích 2) na straně té knihovny nemusíš používat jen synchronní blokující IO operace - můžeš použít třeba select/epoll a multiplexovat přes více vstupů - máš jen jedno vlákno nebo proces, máš otevřeno víc soketů nebo souborů a jakmile se na některém z nich objeví data, tak je přepošleš příslušnému handleru.

S tím pull parserem bys tohle neudělal nebo bys musel používat fibres nebo tak něco. Tam pak píšeš víceméně naivní intuitivní synchronní a jakoby blokující kód, který ve skutečnosti blokující není, ale to z kódu není na první pohled vidět a ty to nemusíš řešit. Ale nevím, jestli používáš tenhle přístup. Dá se říct, že to sem směřuje. Na druhou stranu ve většině jazyků a technologií používaných v praxi tohle není k dispozici, takže se často preferují spíš ty push parsery. Navíc ta výhoda, že se část kódu přesune na jedno místo a je to víc DRY tam zůstává tak jako tak.

[kralyk z abclinuxu]

na straně té knihovny nemusíš používat jen synchronní blokující IO operace - můžeš použít třeba select/epoll a multiplexovat přes více vstupů - máš jen jedno vlákno nebo proces, máš otevřeno víc soketů nebo souborů a jakmile se na některém z nich objeví data, tak je přepošleš příslušnému handleru.

S pull parserem asynchronní přístup možný je - přechodem z completion-based asynchronicity, kde parser volá handler ve chvíli, kdy vyparsoval nějaká data třeba ze socketu, na readiness-based, tzn. parser pouze někde indikuje (třeba callbackem do runtimu), že je ready, tj. že uživatel API si může potenciálně říct o další data. Aktuální thread pak pouze v nějakém event loopu čeká na "ready" příznaky a podle toho spouští jednotlivé logické "tasky", u kterých vždy ví, že ten task se nezablokuje, protože ví, který jsou "ready" a který ne. Rust tohle abstrahuje pomocí async/await funkcí, tzn. těmi funkcemi probublává async context runtimu, na kterém ten parser může říkat "jsem ready!". V praxi by tedy ten parser měl async metodu pojmenovanou třeba next() nebo podobně, ze které by neblokujícím způsobem lezly data.

Zní to možná složitě, ale výhoda oproti push parseru je, že máš větší svobodu si ten handling uspořádat jak potřebuješ. IMO se tím způsobem lépe pracuje se stavem, nenastává callback hell atd.

Fibers jsou hezká věc (jsou to IIRC viceméně korutiny z Erlangu nebo Go), ale ten tradeoff, že každej fiber potřebuje mít svůj stack a potřebuje v runtime dynamicky upravovat velikost toho stacku. Typicky začínají s nějakým velmi malým stackem, který se pak on-demand zvětšuje. Což má výkonnostní dopad.

Ten rozdíl je tedy v tom, že fibre potřebuje stack i ve chvíli, kdy není ready, kdy třeba čeká na data ze sítě. Oproti tomu ten readiness-based task potřebuje stack je ve chvíli, kdy skutečně potřebuje aktivně něco dělat (když je ready).

Takže ne, s výkonem nemam problém, umožňuje to velmi vysoký výkon

[Bherzet]

To už je debata o ničem. Uvedl jsem spoustu konkrétních příkladů, o kterých si myslím, že v principu používají nějaký pattern. Taky jsem se vyjádřil, že právě ten princip považuji za to podstatné, a že jasně, v jiných jazycích se může používat trochu jiná terminologie, ale hodně těch pojmů asi nebude až tak velký javismus, jak se třeba kralyk obával. Co se týká Haskellu, linkoval jsem knihovnu hs-di (a jinak Google na "haskell dependency injection" vrací 394 tisíc výsledků). Možná to je ve skutečnosti strašně neidiomatický způsob, který by správný haskellista nikdy nepoužil, to nevím, ale ten počet zmínek/použití nějakých patternů mimo Javu je tak velký, že není možné předstírat, že to jinde neexistuje. Takže to asi opravdu je obecnější terminologie, a asi to nutně není vázané na jeden jazyk nebo způsob programování.

Víc k tomu nemám co dodat.

[JS1]

Ano, hs-di je neidiomaticky zpusob, je to asi jako ta modifikace bajtkodu, takova spooky-action-at-a-distance. Nevim, proc to chtit, kdyz lze proste ten kod v prvni rade napsat elegantne natolik, aby se dal snadno testovat. Proste v Jave je pouziti DI tradeoff, v Haskellu ne.

V Cecku muzes taky napsat smycku while pomoci goto, tj. pouzit assemblersky idiom smycky, jak jsme to rozebirali vys. Ten vzor se tam nejak nalamat da. Ale proc bys to delal, kdyz while je prehlednejsi? O to mi jde. Vzory jsou proste docasna zaplata, a proto bychom se meli snazit jejich pouziti vyhnout, je-li to mozne.

Jeste taky existuje neco, cemu se rika Reader monada. To se da taky pouzit v nekterych situacich, ktere bys v Jave resil pomoci DI (predavani konfiguracnich parametru).

[JS1]

Podivej, mne spousta z toho nemusis vysvetlovat. Ja si myslim, ze ti chybi prave ten rozhled ve funkcionalnim programovani, abys pochopil, odkud s Kralykem prichazime. Ja rozumim tomu, proc se snazis zapasit s tou slozitosti, to se snazime vsichni, ale ver mi, ze pokud tomu trochu porozumis, bude ten zapas jednodussi.

[xkucf03]

Přijde mi, že pořád nechápeš, o jaké úrovni tady mluvím. Pokusím se to ještě jednou, asi už naposledy, vysvětlit.

Každá úloha má nějakou inherentní složitost. Tou úlohou může být třeba načtení JPEGu, zašifrování souboru, zpracování bankovní transakce, výpočet leasingových splátek atd. K této inherentní složitosti se při vývoji softwaru nabaluje dodatečná složitost. Na této úrovni (jednotlivých úloh) můžeme diskutovat o tom, zda se ke snížení komplexity¹ hodí víc objektové programování, funkcionální, generické, deklarativní atd.

Ale na systémové úrovni, kdy se díváme na větší celky a na vztahy mezi nimi, jsou programovací jazyky a jejich paradigmata irelevantní. Tady se řeší jiné otázky. Klidně můžeš mít jednu část systému v Rustu, jednu v Javě a třetí v Haskellu. Je to úplně jedno. I do Linuxu můžeš psát moduly v Rustu. A když budeš mít dobrý kompilátor, můžeš je psát v libovolném jiném jazyce. Stejně tak i ty moduly do Postfixu, SQLite nebo JACKu/LV2 můžeš psát v různých jazycích. Nebo když budeš mít aplikaci postavenou na mikroslužbách, opět může být jedna napsaná ve funkcionálním jazyce, druhá v objektovém a třetí být třeba jen nějaký skript volající databázovou proceduru. Stejně tak když v unixovém systému spojuješ menší části rourami nebo síťovými či unixovými sokety, opět může být každá část psaná v jiném jazyce. Na téhle úrovni nemá smysl se hádat, zda jsou lepší funkcionální nebo objektové jazyky – to je implementační detail. Na téhle úrovni jsou relevantní otázky: jaké části v systému budeme mít, jak budou tyto části uspořádané, jaké mezi nimi budou závislosti, které části spolu budou komunikovat přímo, které přes nějakého prostředníka, kdo bude komunikaci řídit/iniciovat, kde se budou uchovávat data, co bude bezestavové, které části jsou povinné, které lze vynechat, na kterých místech do toho může vstoupit třetí strana a zapojit do systému nějakou svoji část atd.

Funkcionální jazyky (nebo funkcionální prvky v multi-paradigmatických jazycích) mají co nabídnout na té první úrovni, tam můžou něčím přispět. Ale na té systémové úrovni je to úplně mimoběžná otázka. Už jen proto, že ty části typicky neběží v jednom procesu – chceš je mít např. pod různými uživateli, nebo na různých strojích (ať už kvůli rozložení výkonu nebo proto, že uživatelé nebo data jsou na různých místech). Z toho pak vyplývá, že se komunikuje přes různá rozhraní, ať už sdílenou paměť, POSIX MQ, nějaké sokety a protokoly nebo přes soubory a souborové formáty atd. V principu jde vždy o synchronní (volání procedur/metod/funkcí) či asynchronní (posílání zpráv) komunikaci. Přičemž to synchronní volání je vlastně jen specifický případ posílání zpráv, kde si vždy počkáš na odpověď a pak teprve pokračuješ. A zprávy si lze posílat v libovolném jazyce.

Když tu kapitolu Snížení komplexity závislostí zkrátím na úplné minimum, tak jde o to, že jednak nepoužívané části můžeme vynechat a jednak ty příliš komplexní nahradit jinou jednodušší implementací.

Na závěr jeden ještě příklad: když se budeš zabývat sazbou dokumentů nebo generováním podkladů k tisku, můžeš použít např. LaTeX, nějaký jiný *TeX, LibreOffice, Apache FOP, Firefox či Chromium nebo nějaký jiný software. Všechno to jsou poměrně komplexní balíky. Nakonec si něco z toho vybereš a s největší pravděpodobností půjde o kompromis a budeš si vědom nevýhod, ale nic jiného ti nezbývá. Když tam ale závislost na tomto softwaru nezadrátuješ natvrdo a vytvoříš si tam rozhraní + adaptér, tak dáváš uživatelům možnost, to tvoje kompromisní rozhodnutí změnit a zvolit si vlastní. Když se někomu nelíbí komplexita nebo kvalita LibreOffice, tak může s relativně malým úsilím použít LaTeX (napsat si adaptér pro něj). Pokud se někomu nelíbí ani LaTeX, tak si může napsat vlastní generátor PDF – ty si ho napíšeš třeba v Haskellu a Králík v Rustu a všichni budou spokojení.

_{[1] resp. k jejímu nezvýšení oproti té inherentní}

[kralyk z abclinuxu]

Ale na systémové úrovni, kdy se díváme na větší celky a na vztahy mezi nimi, jsou programovací jazyky a jejich paradigmata irelevantní.

Ne, nejsou.

Funkcionální jazyky (nebo funkcionální prvky v multi-paradigmatických jazycích) mají co nabídnout na té první úrovni, tam můžou něčím přispět. Ale na té systémové úrovni je to úplně mimoběžná otázka.

*Sigh*. NixOs. Nix. Nic?

Nix is a cross-platform package manager that utilizes a purely functional deployment model

Ne? Ok, tak ne no

Na závěr jeden ještě příklad: když se budeš zabývat sazbou dokumentů nebo generováním podkladů k tisku, můžeš použít např. LaTeX, nějaký jiný *TeX, LibreOffice, Apache FOP, Firefox či Chromium nebo nějaký jiný software. Všechno to jsou poměrně komplexní balíky. Nakonec si něco z toho vybereš a s největší pravděpodobností půjde o kompromis a budeš si vědom nevýhod, ale nic jiného ti nezbývá. Když tam ale závislost na tomto softwaru nezadrátuješ natvrdo a vytvoříš si tam rozhraní + adaptér, tak dáváš uživatelům možnost, to tvoje kompromisní rozhodnutí změnit a zvolit si vlastní. Když se někomu nelíbí komplexita nebo kvalita LibreOffice, tak může s relativně malým úsilím použít LaTeX (napsat si adaptér pro něj). Pokud se někomu nelíbí ani LaTeX, tak si může napsat vlastní generátor PDF – ty si ho napíšeš třeba v Haskellu a Králík v Rustu a všichni budou spokojení.

Zrovna nedávno jsem tohle řešil. Nakonec jsem použil LaTeX, resp. šablonu, že které se LaTeX generuje. Je možný libovolně editovat šablonu a vybrat si libovolný dostatečně kompatibilní Latex engine. A kromě toho to podporuje spouštění libovolnýho externího programu nad serializovanými daty. Ale nic víc. Je to celý nalinkovaný staticky, žádný semver interfacy. Dokonce jsem se i zabýval myšlenkou do toho nalinkovat default latex engine. Dřív jsem v tom měl integrován (staticky) Lua interpreter + Ciaro než jsem se na to vykašlal a použil LaTeX. Takže podle tvých teorií úplně špatně. V praxi to pravděpodobně ale bude fungovat celkem dobře, každopádně zatim to tak vypadá

[xkucf03]

Ne, nejsou.

Nix is a cross-platform package manager that utilizes a purely functional deployment model

Ne? Ok, tak ne no

Tohle je vtipné. Ty mi vyčítáš/podsouváš, že tahám na tu systémovou úroveň „myšlenky z Javy“. A když dělá někdo totéž s funkcionálním jazykem, tak to nevidíš nebo ti to nepřijde divné.

Tohle je v lepším případě metafora. To, že si v NixOsu vynalezli vlastní funkcionální programovací jazyk (v Guixu použili aspoň standardní Scheme), nic neznamená. Na té systémové úrovni můžeš tu funkcionální metaforu realizovat třeba objektovým jazykem (nebo klidně v céčku) a nebo realizovat objektovou metaforu pomocí funkcionálního jazyka nebo zase toho céčka nebo čehokoli jiného. Stejně tak bys mohl použít metaforu databázových transakcí. Nebo nějakou metaforu z AFK světa.

Na přelomu 80. a 90. let zase muselo být všechno objektové. I to, co ve skutečnosti objektové vůbec nebylo nebo to nedávalo velký smysl. Lidi se prostě chytají klíčových slov a módních trendů.

Mimochodem, z hlediska návrhu jsou funkce jen speciální případ objektů.¹

Nicméně GNU Guix a NixOS jsou hezkým příkladem modulárních systémů, líbí se mi na nich, že posouvají tradiční (.deb, .rpm) balíčkovací systémy zase o kus dál. Reprodukovatelná sestavení jsou hodně důležitá (tam mimochodem navazují na práci lidí z Cygnusu z počátku 90. let). Jejich balíčky mají jasně definované závislosti, jsou verzované. A jak jsi tu narážel na nějaké moje vazby na debianí systémy – sice Debian/Ubuntu používám, ale udělat balíčky pro GNU Guix nebo NixOS rozhodně nebude těžší než udělat .deb či .rpm, spíš to bude dlouhodobě jednodušší, protože tam lze mít souběžně instalovaných více verzí téhož modulu (knihovny).

Zrovna nedávno jsem tohle řešil. Nakonec jsem použil LaTeX, resp. šablonu, že které se LaTeX generuje. Je možný libovolně editovat šablonu a vybrat si libovolný dostatečně kompatibilní Latex engine. A kromě toho to podporuje spouštění libovolnýho externího programu nad serializovanými daty. Ale nic víc. Je to celý nalinkovaný staticky, žádný semver interfacy. Dokonce jsem se i zabýval myšlenkou do toho nalinkovat default latex engine. Dřív jsem v tom měl integrován (staticky) Lua interpreter + Ciaro než jsem se na to vykašlal a použil LaTeX. Takže podle tvých teorií úplně špatně. V praxi to pravděpodobně ale bude fungovat celkem dobře, každopádně zatim to tak vypadá

To vypadá na variantu č. 2, ne? Nebo pořád č.1? Jestli je to dobře nebo špatně nelze bez znalosti souvislostí (co je to za projekt, kdo ho platí, jaká má požadavky, jaká jsou očekávání do budoucna atd.) říct. Obecně viz Kdy použít kterou variantu.

Jinak ještě k té systémové² úrovni: tady opravdu dává smysl se bavit obecně o tom posílání zpráv nebo volání, o uspořádání těch prvků, jejich závislostech atd. To jsou úplně obecné principy a vlastnosti nezávislé jednak na tom, v jakém jazyce něco uvnitř implementuješ, a jednak na tom, jakou metaforu či marketingové označení chceš používat. Kdybys ten systém navrhoval před třiceti lety, tak budeš zákazníkům tvrdit, jak je úžasně objektový. Dneska jim budeš tvrdit, jak je úžasně funkcionální, navíc s prvky blockchainu a taky trochu toho AI. Za deset let se ta slova zase trochu obmění. :-)

_{[1] jen doufám, že tahle šokující informace nezpůsobí zdravotní problémy nějakému praktikujícímu příslušníkovi funkcionální víry :-)
[2] jen pro pořádek: tím tady nemyslím operační systém, ale systém obecně, nějakou větší aplikaci, více spolupracujících komponent/aplikací/systémů, informační systém atd.}

[kralyk z abclinuxu]

Tohle je vtipné. Ty mi vyčítáš/podsouváš, že tahám na tu systémovou úroveň „myšlenky z Javy“. A když dělá někdo totéž s funkcionálním jazykem, tak to nevidíš nebo ti to nepřijde divné.

Takhle to vymsleli autoři toho systému, já za to nemůžu. Kdyby to byl OOP systém v Javě, tak klidně tam může být veškerá Java terminologie a bude to v pořádku. Oproti tomu třeba Linux není javovský systém a stejně tak není funkcionální, proto v něm nepoužíváme funkcionální hantýrku ani javovskou hantýrku. Nepřijde mi na tom nic moc divnýho.

Mimochodem, z hlediska návrhu jsou funkce jen speciální případ objektů.

Jak tohle můžeš vyhodnotit bez zkušenosti s FP? To bys taky třeba mohl říct, že Haskell je vlastně OOP, protože má třídy

Kdybys ten systém navrhoval před třiceti lety, tak budeš zákazníkům tvrdit, jak je úžasně objektový. Dneska jim budeš tvrdit, jak je úžasně funkcionální, navíc s prvky blockchainu taky trochu toho AI.

Žádnou takovou blbost jim samozeřjmě tvrdit nebudu. Pokud budu znát OOP i FP, tak se pokusim co nejlépe sdělit výhody a nevýhody obojího. Krom toho, jak OOP tak i FP jsou širokej pojem, existuje strašně moc variant jednoho i druhýho... A krom toho jsou i další paradigmata.

To vypadá na variantu č. 2, ne? Nebo pořád č.1?

Je to nehodnotný ona-man-show plebejský software používající mrzkou variantu č. 1. Jo a taky je insane. Prostě všechno špatně

jen doufám, že tahle šokující informace nezpůsobí zdravotní problémy nějakému praktikujícímu příslušníkovi funkcionální víry

Meh, funkcionální programátoři tuhle blbost slýchají každou chvíli... Jinak o FP tady v zásadě nejde, FP vem čert, je to jen příklad jiného paradigmatu, příklad, jak jiné věci můžou být.

[xkucf03]

Na zcela obecné úrovni: objekt v sobě spojuje stav a chování. Mít stav není povinné – objekt může být i bezstavový. Toho chování (metod/funkcí) tam může být libovolné množství tzn. může tam být i právě jedna metoda/funkce. Z toho logicky vyplývá, že funkce je specifickým případem objektu.

Nebo máš snad něco, co můžeš dělat s funkcí a nemůžeš dělat s objektem?

[kralyk z abclinuxu]

No jistě. Všechny jazyky jsou vlastně jen specielní případ Javy. Máš zcela pravdu a já to zcela vzdávám...

[Bherzet]

+1

[ivan]

on asi úplně nepoznamenaný funkcemi nebude, když třeba v těch relpipes má možnost scheme (GUILE) transformací...

Přijde mi, že se tu tahle diskuse zvrhla akorát v poměřování, kdo ho má většího. Ale asi pořád lepší se hádat na internetu než mít vyrabované obchody a nepokoje v ulicích jako v americe.

[xkucf03]

Díky. Měl jsem za to, že o tom ostatní vědí, tak jsem to tu ani nezmiňoval. Jindy tu zase často píšu o XSLT nebo o XQuery, což je funkcionální jazyk, ale taky se to tu moc nesetkává s odezvou, takže mi spíš přijde, že někteří mají potřebu negovat za každou cenu bez ohledu na obsah sdělení.

[JS1]

No, tim bych se tedy nechlubil. Je to asi vec vkusu, ale od nekoho, komu se libi XSLT, bych asi neocekaval, ze neco navrhne jednoduse.

Nicmene to zase miji pointu. Za funkcionalni se oznacuje spousta jazyku. Jejich pouzivani jeste neznamena, ze prejdes ten most co popisuji.

A Haskell ma konecne linearni typy, yay!

[kralyk z abclinuxu]

A Haskell ma konecne linearni typy, yay!

Hustý.

[Fluttershy, yay!]

Funkcionální jazyky (nebo funkcionální prvky v multi-paradigmatických jazycích) mají co nabídnout na té první úrovni, tam můžou něčím přispět. Ale na té systémové úrovni je to úplně mimoběžná otázka.

*Sigh*. NixOs. Nix. Nic?

Nebo různá paradigmata databázových systémů, pajplajny s MapReduce…

Jak tu padla ta unixová filosofie…

Meh. Unixová filosofie je velmi vágně definovaná a v podstatě každý její fanoušek si z toho vytáhne to, co se mu líbí a interpretuje nějakým svým způsobem. A opět platí, že to je jen jeden pohled na problém. Jsou tu taky praktické záežitosti. Všimni si, kde skončil Linux a kde Hurd.

Copak Hurd, ale plan9.

[xkucf03]

Přičemž to synchronní volání je vlastně jen specifický případ posílání zpráv, kde si vždy počkáš na odpověď a pak teprve pokračuješ.

Resp. ty koncepty jsou vzájemně převoditelné. Odeslání zprávy může být implementované jako volání metody/procedury/funkce, která vrátí prázdný výsledek, jakmile druhá strana zprávu dostane (a až potom se zpráva zpracuje asynchronně na pozadí). Příjem zpráv je pak totéž, jen druhá strana volá nás.

[Bherzet]

Mockovat se dají i přímo konkrétní třídy, pokud nejsou final. Není nutné mockovat jen proti interfacu nebo abstraktní třídě.

[JS1]

No, jestli to myslis tak, ze se da podedit, tak to je zrovna v tomhle pripade dost plechovka plna cervu. Zase, mozna kdyby to byl Haskell, dalo by se to vyresit jednoduseji.

Jak rikam na zacatku, Java je proste stary jazyk a ma spousta problemu. Spousta veci v ni se da zapsat jen velmi pres ruku. Ty problemy sahaji k samotne definici OOP, coz byl pokus zkombinovat funkce a hodnoty do jedne abstrakce. Ale ja si myslim, ze to je fundamentalne chybny pristup.

Vztah funkci a hodnot je v programovani dost podobny tomu Escherovu obrazku Drawing Hands (a jak koukam na Wikipedii, nejsem prvni, kdo si toho vsiml). Ale ten obrazek se proste neda nakreslit jen jako jedna vec, jak se o to snazi OOP.

[JS1]

Ale ten obrazek se proste neda nakreslit jen jako jedna vec, jak se o to snazi OOP.

Vlastne to asi mozne je, v netypovem lambda kalkulu se to spoji dohromady (a ty ruce pak odpovidaji aplikaci a lambda abstrakci), ale co neumime je, jak tam pak zavest typy.

[kralyk z abclinuxu]

Ale ten obrazek se proste neda nakreslit jen jako jedna vec, jak se o to snazi OOP.

Vlastne to asi mozne je, v netypovem lambda kalkulu se to spoji dohromady (a ty ruce pak odpovidaji aplikaci a lambda abstrakci), ale co neumime je, jak tam pak zavest typy.

Tohle je formálně vyjádřený důvod, proč se mi intuitivně nikdy nelíbilo to prosazování lispu jako etalonu abstrakce. (Ano, samozřejmě lisp je velmi abstraktní, ale určitým konrétním způsobem.)

Přijde mi, že v celém tom boji Lisp versus "Blub languages" (a OOP) se na ML jazyky taknějak zapomnělo a celkově to je taková trochu opomíjená kategorie. Přitom jsou neméně zajímavé, neméně abstraktní a na moderní jazyky (typované) mají větší vliv, než většina lidí tuší...

[JS1]

Ja naprosto souhlasim. Ja jsem byl velkym priznivcem Lispu (a Pythonu, coz je tak trochu prakticky Lisp), ale ze dne na den jsem na Haskell zmenil nazor, kdyz mi doslo, ze to vlastne neni mene abstraktni (hodne pomohl clanek o free monadach, ktery ukazal, jak delat co jsem znal jen z Lispu a Forthu v Haskellu a navic typove bezpecne).

Navic se k tomu v prakticke rovine pridala typova inference, coz pro me byla jedna z vyhod Pythonu oproti tradicnim staticky typovanym jazykum. (Treba jen takova blbost, ze nemusim definovat novy typ, kdyz chci jen vratit dve veci z funkce.)

Spousta Lisparu si to nedovede u tech ML jazyku predstavit, ze by mohla vetsi sila jazyka byt vysledkem urcite restrikce (v tomto pripade zavedeni vhodneho typoveho systemu). Do jiste miry je to pochopitelne, ale jak to tak byva, radikalni inovace vzdy prijdou z necekane strany, a zmeni nase predpoklady o tom, co je spravne.

[xkucf03]

Ono v Javě můžeš dělat i různá kouzla nad bajtkódem, AOP a další věci.¹ Je to podobně silné jako hygienická makra nebo homoikonicita. Ano, používají se tam trochu jiné nástroje a ten přechod mezi běžným programování a meta-programováním tam není tak plynulý, jako v tvých oblíbených jazycích. Ano, dá se říct, že je to svým způsobem nevýhoda Javy, ale nemyslím si, že nějak zásadní. Pokud se totiž bavíme o tvorbě frameworků, přípravků a různých nástrojů, je to úplně jiná činnost, než běžné programování, ve kterém by ses měl soustředit na doménovou oblast. Nebudeš dělat oboje najednou a dost možná to budou řešit i různí lidé – někdo bude připravovat framework a někdo² ho bude používat a řešit obchodní logiku aplikace.

I když tedy můžeš argumentovat, že tvoje oblíbené jazyky tohle umí líp a jsou čistější, budeš mít třeba i pravdu, ale přesto v Javě vzniklo dost frameworků, které umožní velmi efektivně pracovat a odbourat většinu dodatečné komplexity³ – jako programátor aplikace se pak soustředíš tu byznys logiku a ty implementační detaily vyřešíš třeba pár anotacemi nad třídami nebo metodami.

Ty problemy sahaji k samotne definici OOP, coz byl pokus zkombinovat funkce a hodnoty do jedne abstrakce. Ale ja si myslim, ze to je fundamentalne chybny pristup.

Už jsem tu psal, že volba jazyka nezávisí jen na vlastnostech jazyka samotného, ale i na spoustě věcí kolem – v neposlední řadě na způsobu myšlení lidí. A tím nemyslím programátory – myslím tím analytiky nebo lidi od zákazníka/uživatele, kteří definují zadání.

Na procesoru se vykonává strojový kód, procesoru je jedno, jestli byl program původně psaný v objektovém, funkcionálním nebo jiném jazyce – procesor si jede po svých instrukcích a nějaké programovací jazyky neřeší. Zákazníka/uživatele taky nezajímá tvůj zdrojový kód – on chce vidět spustitelný program, který odpovídá zadání, které ti dal. Zjednodušeně řečeno, programátor je tu tedy od toho, aby to zadání psané lidskou řečí přetavil ve strojový kód. A k tomu si bere na pomoc programovací jazyky, kompilátory a další nástroje. Nicméně ty nejsou samy o sobě cílem. Cílem je vytvořit ten spustitelný program, který pracuje dle zadání.

Až bude zadání od analytiků chodit psané funkcionálním stylem a až bude v tomto stylu uvažovat a definovat svoje požadavky i zákazník, tak to bude relevantní argument pro použití funkcionálních jazyků. Co ale běžně potkávám v praxi, tak to zadání a myšlení lidí je převážně imperativní, program chápou třeba jako kuchařský recept obsahující posloupnost kroků a sem tam nějakou výjimku či větvení. A většinou operují i s tím, že nějaká část systému má jak chování, tak stav. To se pak celkem přirozeně mapuje na objektové nebo procedurální programování. Neříkám, že je to 1:1 nebo že by to nešlo přepsat ve funkcionálním stylu, šlo, ale ta přirozená tendence k objektům či procedurám tam je.

Tohle je i částečně příčina všech těchto neshod mezi programátory: pokud někdo nepracuje v týmu a zadání si vymýšlí sám a sám si to pak programuje, tak se s tímhle jevem vůbec nepotká a nebude chápat, že ostatní to vidí jinak. Podobné neshody jsou s lidmi, kteří sice píší kód v nějakém jazyce a dokonce pracují v týmu, ale nejsou placeni za vývoj softwaru – oni nedostali za úkol napsat software a software není věc, kterou by odevzdávali svému šéfovi jako hotovou práci – je to jen vedlejší produkt, který vytvořili během své skutečné práce (kterou je typicky pořízení nebo zpracování nějakých dat), a tento vedlejší produkt si většinou strčí do šuplíku nebo někam pohodí ostatním kolegům, ale není to nic, za co by museli dávat ruku do ohně a za čím by si měli stát (jejich úkolem bylo něco jiného než vyvinout software). Tím neříkám, že je na tom něco špatného, ti lidi dělají dobře svoji práci, kterou ovšem není vývoj softwaru. Píšu to ale kvůli tomu, že se tím dá vysvětlit docela velká část plamenných internetových diskusí a neshod.

_{[1] případně můžeš část programu napsat v jiném jazyce, který se do bajtkódu kompiluje
[2] pokud si dobře pamatuji, tak o tomto rozdělení rolí jsi tu někdy psal zrovna ty, ne?
[3] že si jí tam někdo přidá někudy jinudy, to už je jeho problém, nutné to není}

[JS1]

Tohle je i částečně příčina všech těchto neshod mezi programátory: pokud někdo nepracuje v týmu a zadání si vymýšlí sám a sám si to pak programuje, tak se s tímhle jevem vůbec nepotká a nebude chápat, že ostatní to vidí jinak.

Jo, to mi ti Javiste (deda.jabko promine, ale je vic prikladu nez jen ty, klidne si tam ale muze dosadit jen tebe) obcas tvrdi taky, ze programuji v mizernem jazyce ne kvuli sobe. ale kvuli "tymu". Pritom z moji zkusenosti, nejcitelnejsi (a nejsnaze upravovatelny) kod, co jsem kdy napsal, jsem napsal prave v Haskellu, protoze te rigorozne nuti oddelovat vedlejsi efekty a definovat vsechno jako funkce (o vychytavkach jako ADT nemluve).

[xkucf03]

Viz #579.

Tou "vatou" myslim něco jinýho, než ten princip, který je pod tim (a který může opravdu bejt užitečnej).

Asi myslíš různé frameworky a běhová prostředí (Java EE, Spring, OSGi…). Ono na DI/IoC stačí nějaký ten setter nebo parametr konstruktoru. V zásadě na to nic jiného nepotřebuješ. Už v tom druhém díle píšu:

Důležité ale je nezapomínat, proč to děláme a na jakém předpokladu naše rozhodnutí (přidat tu či onu závislost) stálo. Tento předpoklad bychom měli průběžně testovat – a pokud zjistíme, že platit přestal, tak z toho vyvodit patřičné závěry. Neměli bychom zapomínat na to, že samotný vyšší programovací jazyk (např. Java nebo PHP) spolu se svojí standardní knihovnou jsou samy o sobě frameworkem, stejně jako je frameworkem UNIX (resp. dnes převážně GNU/Linux) a že poskytují víc než dostatečnou úroveň abstrakce pro vývoj mnoha aplikací. Přidání jakékoli vrstvy nad ně bychom neměli vnímat jako samozřejmost a měli bychom toto rozhodnutí mít vždy dobře zdůvodněné a podložené.

Takže pokud dojdeš k tomu, že si náhradu toho DI/IoC kontejneru napíšeš sám na „pár řádcích“, tak já nemám nic proti tomu a naopak tomu fandím. Je potřeba prostě zvážit pro a proti různých variant a podle toho se rozhodnout. Když dojdu k tomu, že si radši ten setter zavolám ručně a konfiguraci si dám do nějakého vlastního souboru, a tím tam nemusím dávat (komplexní) framework, tak v pohodě. Jde jen o to, aby to bylo nějaké kvalifikované racionální rozhodnutí. A ne nějaké emotivní povrchní rozhodnutí typu „četl jsem, že Java je fuj, tak ji nepoužiji“ nebo naopak „četl jsem, že framework XY je moderní, tak ho musíme použít“.

Tomu moc nerozumim - ty řešení, co tam popisuješ, ten strom naopak zvětšují (přibývaj tam různý adaptéry atd.), ne?

Ne. Opravdu bych rád, kdyby sis to přečetl, jestli chceš pokračovat v diskusi. Tady jde o to, že ta rozhraní ti umožňují zbavit se celých velkých částí toho stromu závislostí. Díky těm rozhraním a modulární architektuře ten strom můžeš (jako uživatel, který si instaluje balíčky) prořezat a nechat v něm jen to, co skutečně potřebuješ.

A specielně třeba relační roury jsou, relativně k vlastnímu kódu, který něco dělá, jeden z nejsložitěji strukturovaných projektů, co znám...

Ty relační roury mají minimum závislostí. Většina modulů závisí jen na standardní knihovně. k sestavení je potřeba CMake (jedna z otevřených otázek je, zda se ho nezbavit a nepoužívat ručně psané Makefile, ale zatím ten CMake slouží). Pak je samozřejmě nesmysl psát si vlastní XML parser nebo vlastní implementaci AWKu či relační databáze, takže některé moduly mají tyhle závislosti. Ale díky tomu modulárnímu návrhu si je instaluje jen ten, kdo je chce používat. Tím se komplexita snižuje na tu nezbytně nutnou.

Ve verzi v0.16 modul relpipe-tr-sql přešel na abstraktní databázovou vrstvu, takže pokud se ti nelíbí SQLite, můžeš pro SQL filtrování použít libovolnou jinou databázi.

Pokud ti jde o „strukturování“ a nechceš přemýšlet nad tím, které moduly potřebuješ a které ne (i za cenu toho, že si do systému zatáhneš zbytečné závislosti), tak v produkční verzi bude existovat nějaký meta-balíček jako relpipe-all, který bude záviset na všech modulech. Takže pak budeš moci dát třeba apt install relpipe-all a nic neřešit. A koho ta komplexita zajímá a nechce si instalovat software, který nepoužívá, tak ten si nainstaluje jen vybrané moduly.

[Bherzet]

Takže pokud dojdeš k tomu, že si náhradu toho DI/IoC kontejneru napíšeš sám na „pár řádcích“, tak já nemám nic proti tomu a naopak tomu fandím.

Pracoval jsem na projektu, kde se používal vlastní kontejner.

Výhody:

• z programátorského hlediska pěkný, minimalistický kousek kódu (cca 1k LoC)
• jasné, srozumitelné, predikovatelné chování
• absolutní kontrola nad kódem, tj. chování definujeme my, ne třetí strana

Nevýhody:

• tu a tam se naráželo na omezené možnosti a muselo se to různě obcházet
• noví členi tymu se musí učit pracovat se novým frameworkem, při problémech nemohou konzultovat Google
• trávíme čas vývojem vlastního frameworku místo práce na projektu jako takovém (sice minimální, ale stejně… NIH)

Zvažoval jsem, zda nepřejít na jiný existující framework, ale upřímně jsem moc nevěděl jaký vybrat a bál se, abych se zbytečně nestřelil do paty. Migrace z minimalistického frameworku na komplexnější je triviální, opačným směrem už by to platit nemuselo.

Taky jsem přemýšlel, zda ten náš framework prostě neoupnsourcnout. Ono je na jednu stranu super, že by nám třeba lidé mohli reportovat bugy nebo posílat patche, ale je otázka, jestli bychom pak vlastně netrávili čas zdokonalováním frameworku způsobem, který sami ani nevyužijeme.

Nakonec jsem to tam nechal, dokud se neobjeví nějaký zásadnější důvod proč přejít (a bude kam). Tupě si natahat do projektu tunu závislostí jako to dělají frontenďáci je cesta do pekel. Čas, který ti to ušetří při psaní kódu, vzápětí vyplýtváš na řešení různých kolizí, nekompatibilit, aktualizování verzí, reportování bugů (které můžeš přímo fixnout leda forkem) atp.

Ohledně strukturování relpipes máš, minimálně z tohoto abstraktního popisu (detailně jsem zdrojáky nezkoumal a je to už dlouho, co jsem zkoušel čistě uživatelsky nějakou tu dřívější verzi), mou plnou podporu.

[kralyk z abclinuxu]

Tou "vatou" myslim něco jinýho, než ten princip, který je pod tim (a který může opravdu bejt užitečnej).

Asi myslíš různé frameworky a běhová prostředí (Java EE, Spring, OSGi…).

Ne, myslim tim jen terminologii, respektive nadúživání terminologie, viz ten komentář o kontrafibulaci.

Pokud ti jde o „strukturování“ a nechceš přemýšlet nad tím, které moduly potřebuješ a které ne (i za cenu toho, že si do systému zatáhneš zbytečné závislosti), tak v produkční verzi bude existovat nějaký meta-balíček jako relpipe-all, který bude záviset na všech modulech. Takže pak budeš moci dát třeba apt install relpipe-all a nic neřešit. A koho ta komplexita zajímá a nechce si instalovat software, který nepoužívá, tak ten si nainstaluje jen vybrané moduly.

Reality check: Nic z toho neudělám, protože mam Arch. Můžeš namítnout, že to je v pohodě, že budou balíčky pro všechny hlavní distribuce. Nastíním ti, co bys musel řešit, kdybys chtěl balíčky do Archu. Nemáš tam AFAIK nikde ty závislosti vypsaný, takže je čuchám z toho instalčního skriptu (kterej vypadá jako dost prasárna btw.). V Archu jsou balíčky pojmenovaný jinak a ne u všeho je mi zřejmý, co je ekvivalent. Některý ty závislosti (třeba libxerces) ani nemá Arch v oficiálních repo, pouze v AURu, kde se o to starají (nebo taky nestarají) dobrovolníci, a je potřeba si kompilovat balíček u sebe ze zdrojáků. A to jsi zatim pouze na úrovni balíčků, teď ještě budeš muset zjistit, jestli nějak sedí verze a jestli tam není nějaká jiná nekompatibilita (třeba v build flags).

A to je jedno distro, jak to bude vypadat třeba pro Fedoru, CentOS, ...? Tak typicky bude víc balíčků v oficiálních repos, ale zase u konzervativní distribuce budou starší verze, ve kterých nemusí být tebou používané fíčury...

IMO ten setup je maisvní předčasná modularizace. Osobně je mi zcela šumák, jestli mam na systému o 1MB nějaký guile nebo xml knihovny víc nebo míň. Jediný, co by mi dávalo smysl z toho vymodularizovat, je ten GUI výstup a možná python (ale spíš ne, stejně má python reálně nainstalovaný skoro každý...).

[Bherzet]

To jsou ale problémy nezávislé na tom, jestli to má nebo nemá rozdělené do více menších balíčků, ne? Pořád bude řešit stejné externí závislosti.

[kralyk z abclinuxu]

To jsou ale problémy nezávislé na tom, jestli to má nebo nemá rozdělené do více menších balíčků, ne? Pořád bude řešit stejné externí závislosti.

Ano, v zásadě máš pravdu, teda snad s tím drobným rozdílem, že jeden balíček se dostane do distra snáz než celá letka balíčků a třeba z toho AURu se mnohem snáz sestavuje jeden balíček než skupina vzájemně propojených. Ale jinak máš recht.

Z mý strany to byl spíš takovej obecnej hejt na distribuování software pro (různé) linuxové balíčkové repozitáře. IMO ta myšlenka, že struktura projektu mapuje 1:1 na balíčky reálně nefunguje, zejmena protože závislosti nemapují na balíčky v distrech (jednoznačně a spolehlivě).

IMO u těch relational pipes by bylo mnohem jednodušší minimálně v té ne-ostré vývojové verzi prostě mít jeden balíček celý ty věci, klidně s nějakejma obskurnějšíma knihovnama staticky. Špatného by se nestalo vůbec nic, jedinej rozdíl by byl, že vyzkoušet si ten projekt by bylo mnohem jednodušší...

[JS1]

Souhlasim. Ja myslim, ze balicky "druheho radu" (tedy co obsahuji podporu balicku A pro balicek B, a nejsou od treti strany) by se vubec nemely davat samostatne do distribuci, ale byt soucasti instalace balicku A. Dneska ma kazdy plno mista, a balicku je proste moc na to, aby tim clovek travil mladi. Jedina smysluplna vyjimka snad je, kdyz jsou radove stejne velke nebo vetsi nez samotne A.

[xkucf03]

Ty Relační roury jsou primárně formát dat. Cílem je, aby data v tomto formátu mohly vytvářet i jiné programy. Aby např. vedle lidsky čitelného výstupu na terminál nabídly i strojově čitelný formát dat, který se pak dá dále zpracovat, převést na jiné formáty, zobrazit v GUI atd. Proto jsou to samostatné knihovny. Celé je to ještě ve vývoji včetně dokumentace/specifikace, tak možná některé ty myšlenky a motivace za tím nejsou vidět…

Obecně: myslím si, že je dobré v balíčkovacím systému mít metadata, která řeknou, zda daný balíček představuje veřejné API a ostatní (třetí strany) se na něj mohou vázat, nebo ne. Bez toho se člověk musí řídit jen komentáři, dokumentací atd. Jinak ty interní balíčky ale ničemu nevadí a nějaký přínos mají. Ono to nemusí být jen sdílené knihovny – můžou to být třeba ikony, zvuky, šablony nebo nějaké jiné artefakty. Na disku a v (mezi)paměti pak můžou být jen jednou. To bys musel stanovit nějaký limit, do kterého se má raději duplikovat a přibalit to přímo k programu – a nad který už to může být samostatný balíček.

[Bystroushaak]

Myslim, ze to bezdecne vystihl Bystroushaak, kdyz ti napsal, zkus si to v nejakem ciste funkcionalnim jazyce. (Mimochodem, tesi me, ze dal na moji radu a jal se funkcionalni programovani vice studovat.)

Lehce paradoxně jsem poslední dobou začal číst původní Design patterns knihu od gang of four + pár dalších specifických ke smalltalku. Funkcionální programování je určitě fajn a snažím se ho aplikovat kde to jde, ale zatím v něm moc kovaný nejsem.

[xkucf03]

Myslím, že jsi návrhové vzory stále nepochopil a máš k nim jakýsi iracionální odpor (asi proto, že si je dáváš do souvislosti s Javou, která ti taky nějak leží v žaludku).

Jde o to, ze alternativy z funkcionalnich jazyku vrhaji dost pochybnosti na tovarnu jako uzitecny navrhovy vzor.

Továrna = funkce. Zrovna nedávno jsem o tom psal v blogu:

Mimochodem, takový návrhový vzor továrna (factory) je vlastně prvkem funkcionálního programování, ačkoli je implementovaný formou objektu. Stejně jako funkci můžeme objekt továrny vytvořit (parametrizovat) na jednom místě a předat jinam, kde se bude volat a vracet nějaké další objekty (nebo klidně další továrny tzn. další funkce).

Nicméně ne každá funkce je továrna. Takže i když tvůj jazyk má funkce, nebudeš tam tento návrhový vzor implementovat formou tříd/objektů (které v tom jazyce třeba ani nemáš), ale předáš tam prostě jen funkci. Stále to ale je návrhový vzor továrna.

Nebo když tvůj jazyk/platforma bude mít podporu singletonů (např. @Singleton anotace v Javě EE), tak nemusíš tenhle návrhový vzor implementovat ručně. Stále to je ale singleton. Stejně tak tvůj jazyk/platforma/knihovna může podporovat proxy, adaptéry, mosty atd., takže je nemusíš psát ručně – stále o tom ale má smysl mluvit jako o proxy, adaptéru, mostu atd., protože to označuje tu podstatu, co ta daná věc dělá.

Software bude mít vždycky nějaký přesah, nějakou část, které rozumí lidi, ale které „nerozumí“ počítač. I v tom funkcionálním kódu najdeš nějaké opakující se části – vzory – které stojí za to si nějak pojmenovat (návrhové vzory tu jsou pro lidi, aby si mezi sebou rozuměli, ne pro počítač), ale ze kterých nelze udělat (nebo to nedává smysl) znovupoužitelné funkce nebo je zadrátovat do jazyka jako konstrukt.

V unixových systémech máš zase třeba návrhový vzor filtr – program, který čte ze standardního vstupu a zapisuje na standardní výstup. Přesto je to běžná ELF binárka, jako kterákoli jiná. Ano, můžeš říct, že je to zbytečný termín, ale ostatním lidem to zbytečné nepřijde a usnadňuje jim to komunikaci.

[kralyk z abclinuxu]

Myslím, že jsi návrhové vzory stále nepochopil a máš k nim jakýsi iracionální odpor (asi proto, že si je dáváš do souvislosti s Javou, která ti taky nějak leží v žaludku).

A mně přijde, že tys stále nepochopil to jádro té kritiky

Pokusim se o příklad.

Představ si, že já a skupinka mých kamarádů ve VelkéFirmě, která píše PopulárníJazyk přijdeme s tím, že funkci/objektu, která nějakým způsobem prohazuje data na dvou místech např. přes referenci, pointer, index nebo podobně budem říkat Contrafibulator a té operaci 'kontrafibulace'. A narveme to do standardní knihovny (interface AbstractContrafibulator), do kódu, do dokumentace, do přednášek, do agilních workšopů, do meetingů, do učebnic, prostě pokudmožno úplně všude.

Jednoho dne k tomu přijdeš ty a řekneš, "Počkat, pánové, proč proboha 'kontrafibulace'? Vždyt to je prostě jen prohození hodnot, proč nenapíšete do dokumentace prostě že ta funkce prohazuje hodnoty? To je přece zbytečný pojem, proč z toho děláte tak důležitou věc?"

A my ti na to řeknem "Hele jako nech nás jo. My jsme si všimli, že pattern výměny dat ve dvou lokacích je poměrně často používaný v našem software a máme pro to tento název, protože nám to usnadňuje komunikaci. Navíc to unstadňuje testování. A taky se často stává, že nováček napíše kód, který není úplně dobře napsaný a mohl by být mnohem lepší, kdyby používal kontrafibulaci. A tak nováčkům vysvětlujeme, kdy je a není dobré používat kontrafibulaci, jak definovat správný kontrafibulační objekt, jako ho správně testovat atd. Je přece dobré, aby lidi věděli, co to je kontrafibulace a kdy se má nebo nemá použít, nesnad? Ano, je pravda, že někteří lidé používají kontrafibulátory i tam, kde nepatří, ale to přece není problém kontrafibulace!"

Zhruba takovýhle pocit mam z mnoha patternů běžně používaných v Javě.

[Bherzet]

Nemyslím si, že abstraktní kontrafibulátor bude mít nějaký funkční význam a že se ten pattern jako takový osvědčí. Což je rozdíl oproti patternům a best practices, ke kterým programátoři většinou magicky dospějí po nasbírání dostatku zkušeností. A akorát to někdo respektovaný zobecní (nebo naopak zkonkretizuje) a dá tomu nejlepší jméno, ke kterému doiteroval.

[kralyk z abclinuxu]

Nemyslím si, že abstraktní kontrafibulátor bude mít nějaký funkční význam a že se ten pattern jako takový osvědčí.

How dare you! Jak bych to jinak udělal, až budu chtít umožnit uživateli mého API injektovat jeho vlastní implementaci? Třeba bude chtít použít optimalizovanou kontrafibulaci. Anebo případně v některých použití může dávat smysl zároveň s kontrafibulací aktualizovat data, třeba i někdě jinde, klidně i na vzdáleném stroji, a pak ten kontrafibulátor potřebuje taky nějakou konfiguraci. Taky ho budu pravděpodobně chtít mockovat v testech atd., takže abstraktní kontrafibulátor samozřejmě je extrémně užitečný koncept.

[Bherzet]

Mhm.

[Bystroushaak]

+1 :)

Ale patterny nejsou blbost, jen se kolem toho zhlukuje divný cargo cult.

[Josef Kufner]

Zmiňuješ jednu podstatnou myšlenku, která zaslouží zdůraznit: Návrhový vzor je něco, čemu počítač nerozumí a v programu to explicitně není vyjádřeno. Je to jen způsob uspořádání komponent, který odpovídá mentálnímu modelu v hlavě programátora. Sice se to promítne do kódu programu, ale vzor samotný v kódu není (tedy až na nějaké názvy, což pro počítač je prostě jen identifikátor bez významu).

Důsledek tohoto faktu je, že pokud bychom uměli popsat návrhový vzor tak, aby mu počítač rozuměl, tak bychom počítač naučili programovat.

[Bherzet]

+1

[Bystroushaak]

Důsledek tohoto faktu je, že pokud bychom uměli popsat návrhový vzor tak, aby mu počítač rozuměl, tak bychom počítač naučili programovat.

Tohle je absurdní závěr. Počítač nerozumí naprosto ničemu, protože nemá rozum. Můžeme se bavit o tom, že interpretr / kompilátor nemá tušení o co vlastně jde, ale důsledek tohohle je, že ty vzory časem probublávají do jazyků jako různé konstrukce. Například by nebylo problém si ty vzory různě tagovat a vyhradit jim speciální syntaxi. Pak bys mohl dělat například analýzu těch vzorů a jejich kompilaci pro co největší efektivitu (myšleno že ty vzory zplacatíš, ne že je přeložíš na lowlevel instrukce).

Jinak konkrétně python obsahuje prvky jazyka, které spoustu patternů implementují tak nějak mimochodem na pozadí (například with a tak dál). Pěkný talk na tohle téma je, pokud mi paměť a grep slouží, https://www.youtube.com/watch?v=Er5K_nR5lDQ. Samozřejmě, že v tomhle ohledu je pořád kam postupovat.

[Josef Kufner]

ale důsledek tohohle je, že ty vzory časem probublávají do jazyků jako různé konstrukce.

O to právě jde. Jakmile takovou konstrukci v jazyce máš, tak se s ní dá pracovat a nějak o ní uvažovat, něco z toho odvozovat. Když to je jen nějaké uspořádání, které dává smysl jen v programátorově hlavě, tak s tím počítač nic neudělá a žádné nástroje nad tím nepostavíš.

Příkladem na trochu nižší úrovni jsou generika. Bez generik programátor napíše kontejner pro jeden typ, pak velmi podobný kontejner pro druhý typ, pak pro třetí. Pro překladač to není nic jiného než tři třídy bez jakéhokoliv vztahu. Když se použijí generika, tak programátor může říci, že tu máme takovýto kontejner a jak se odvodí konkrétní implementace pro daný typ. V ten okamžik už to pro překladač nejsou tři nezávislé třídy, ale může s tím nějak pracovat, sdílet optimalizace a odvozovat další implementace, případně kontrolovat, zda daný typ je v takovém kontejneru použitelný.

[xkucf03]

Například by nebylo problém si ty vzory různě tagovat a vyhradit jim speciální syntaxi. Pak bys mohl dělat například analýzu těch vzorů a jejich kompilaci pro co největší efektivitu (myšleno že ty vzory zplacatíš, ne že je přeložíš na lowlevel instrukce).

To by bylo hezké… až na to, že bys pak ty vzory musel sémanticky verzovat a udržovat u nich zpětnou kompatibilitu, jako kdyby to byla knihovna¹.

Tohle je problém u jakéhokoli znovupoužitelného kódu. Pokud ho chceš měnit², tak musíš držet zpětnou kompatibilitu a pokud ji porušuješ, tak to musíš správně komunikovat k uživatelům toho sdíleného kódu (tzn. používat sémantické verzování a zvýšit major verzi). Tohle má svoji režii a je potřeba zvážit, jestli se vyplatí nebo ne.

Je otázka, jestli z těch návrhových vzorů nadělat knihovny (či dokonce konstrukty jazyka). Samozřejmě se to děje, ale fakt, že se nějaký návrhový vzor zhmotní do nějaké konkrétní knihovny (nebo se dokonce stane součástí jazyka či standardní knihovny), ještě neznamená, že by přestal existovat jakožto myšlenkový koncept – ten existuje stále, bez ohledu na to, kolik konkrétních implementací vzniklo nebo nevzniklo.

Ten myšlenkový koncept je „měkký“ – je to lidskou řečí popsaná struktura a chování. Nemáš tu problémy, které jsou u „tvrdých“ definic (strojově čitelný popis API), kde musíš mít přesně správně pojmenované metody a atributy, jinak to na sebe nebude pasovat a kde musíš řešit různé implementační detaily a kompatibilitu. Stinnou stránkou té „měkké“ definice je to, že ta myšlenka je vlastně „rozkopírovaná“ do více instancí (podobný kód v rámci jednotlivých programů). Nicméně kdybys tuhle myšlenku nechtěl „rozkopírovat“ a usiloval bys o 100% znovupoužitelnost, tak tam máš tu režii, o které píšu výše.

Dá se říct, že návrhové vzory se nacházejí na rozhraní světa analytiků a byznys zadání (kde „papír snese všechno“) a světa počítačů (kde „to musí sedět na bit přesně, jinak to nebude fungovat“).

_{[1] resp. ona by to byla knihovna nebo modul jazyka/platformy
[2] a málokdy se ti podaří nastřelit geniální řešení hned napoprvé, které pak vydrží navěky a nemusí se na něj už nikdy sáhnout}

[JS1]

Je otázka, jestli z těch návrhových vzorů nadělat knihovny (či dokonce konstrukty jazyka).

Ja myslim, ze ano. I kdyby nakrasne ten koncept mel ruzne potencialni implementace, stale je jednodussi na porozumeni (a vic DRY) mit prinejmensim urcitou implementaci v ramci jednoho programu, ktera osvetluje, ktera bije.

Jinak receno, mam za to, ze programovani je jako matematika, a mit nedostatecne presne definovane abstrakce nepomaha tomu tvorit dobre programy. Moje zkusenost je, ze cim je neco mekci koncept, tim mene mu rozumim a tim mene jej chci mit v programu.

[xkucf03]

Ja myslim, ze ano. I kdyby nakrasne ten koncept mel ruzne potencialni implementace, stale je jednodussi na porozumeni (a vic DRY) mit prinejmensim urcitou implementaci v ramci jednoho programu, ktera osvetluje, ktera bije.

V rámci jednoho programu klidně, tam bys nemusel řešit kompatibilitu, protože jediným uživatelem bys byl ty. Ale v rámci jednoho programu se to buď dělá už teď (napíšeš si např. generickou třídu implementující určitý vzor a použiješ ji na víc místech, nebo předka, kterého na více místech podědíš, nebo použiješ kompozici, nebo to dáš do anotací atd.). Ostatně o tomhle taky píšu v tom článku, který jsem tu odkazoval.

A pak máš spoustu situací, kdy se daný návrhový vzor v rámci daného programu vyskytuje jen jednou – pak tam prostor pro znovupoužitelnost není resp. musel bys vytvářet komponentu znovupoužitelnou napříč různými programy – a tam už pak musíš řešit tu kompatibilitu a další věci, jak jsem psal.

Jinak receno, mam za to, ze programovani je jako matematika, a mit nedostatecne presne definovane abstrakce nepomaha tomu tvorit dobre programy.

Tohle zavání trochu hledáním nějaké vnitřní krásy, uměním, zabýváním se sám sebou (programuješ, abys programoval a kocháš se tím, jak je to dokonalé). Pokud to má být zábava nebo koníček, tak nic proti. Ale na softwarové inženýrství se dívám jako na službu ostatním oborům – od nich přichází nějaké zadání, potřeby, požadavky a naším cílem pak je, na základě těchto požadavků vytvořit software – a vytvořit ho efektivně, s minimálním TCO (tzn. náklady na vytvoření i následnou údržbu a rozvoj). Jestli ten výsledek přijde někomu „matematicky dokonalý“ nebo naopak „ošklivý“, to je irelevantní.

Moje zkusenost je, ze cim je neco mekci koncept, tim mene mu rozumim a tim mene jej chci mit v programu.

V programu máš třídy, funkce atd. Návrhové vzory máš v komunikaci mezi lidmi. Už jsem to psal v tom komentáři výše:

Dá se říct, že návrhové vzory se nacházejí na rozhraní světa analytiků a byznys zadání (kde „papír snese všechno“) a světa počítačů (kde „to musí sedět na bit přesně, jinak to nebude fungovat“).

V podstatě celý ten vývojový proces je skládá z kroků, ve kterých se postupně zpřesňuje zadání – na jednom konci toho řetězce jsou nějaké obecné vize a na druhém je konkrétní kód spustitelný na procesoru. Mezi tím je spousta lidí, kteří mluví každý trochu jiným jazykem, žijí v trochu jiném světě a postupně si mezi sebou předávají tu představu, co by ten software měl dělat.

[Fluttershy, yay!]

Jinak receno, mam za to, ze programovani je jako matematika, a mit nedostatecne presne definovane abstrakce nepomaha tomu tvorit dobre programy.

Tohle zavání trochu hledáním nějaké vnitřní krásy, uměním, zabýváním se sám sebou (programuješ, abys programoval a kocháš se tím, jak je to dokonalé).

Nebo je to věc zajištění korektnosti.

[Bystroushaak]

V čem je to abstraktnější než volání vhodně pojmenovaných metod? Přijde mi to jen jako syntaktický cukr.

Dobře, ale tohle můžeš říct teda úplně o všem co je v jazyce, protože všechno je jen syntaktický cukr. A ve výsledku nemusíš mít v jazyce vůbec nic víc, než volání metod (třeba Self to tak má, spolu s blokama). Dokonce ani to ne, můžeš používat lambda calculus, kde ti stačí jen volání funkce, která je schopná přijmout parametr a například cykly řešit Y combinatorem. Dokonce se dá používat jen NOR na úplně všechno.

Takže očividně na syntaktickém cukru záleží (proč se tu všichni vyjadřují jako že ne?), jelikož je to právě to co ti přináší abstrakci; abstrahuje tím, že zjednodušuje, automatizuje a generalizuje některé nudné a nepodstatné části.

Například provede expanzi for smyčky na kopec jmp a cmp, nebo třeba implementuje, kontroluje a volá iterátorový protokol, aby bylo možné procházet iterátory a generátory. Takže pak místo psaní sto řádek napíšeš jeden foreach nebo for nebo whatever. To přece je abstrakce. To že můžeš použít běžné jedno/dvouznakové matematické operátory, například operátor sčítání, kterým každý rozumí, protože má kontext naší civilizace a představu co budou dělat, je abstrakce.

na druhé straně to zvyšuje složitost jazyka a kódu a klade vyšší nároky na programátora

Složitost implementace jazyka mě moc nezajímá, dokud nemusím zkoumat interpreter/kompilátor a vyšší nároky jsou imho vesměs iluzorní. Ještě jsem nepotkal nikoho, kdo by si stěžoval že implementovat operátor po něm chce nějaké vysoké nároky.

[Bherzet]

Bingo. Začínáme se dostávat k tomu, proč současné programovací jazyky vlastně tak moc úžasně abstraktní nejsou. Zapsat for cyklus je bezesporu efektivnější než rozepisovat ty instrukce ručně, ale abstraktnější je to jen velmi nepatrně: ušetří ti to starost o nějakých pár návěstí a přeskakování mezi nimi.

[JS1]

Zapsat for cyklus je bezesporu efektivnější než rozepisovat ty instrukce ručně, ale abstraktnější je to jen velmi nepatrně: ušetří ti to starost o nějakých pár návěstí a přeskakování mezi nimi.

Ja jsem videl dost produkcniho kodu v assembleru, abych si tohle opravdu nemyslel. Co treba takove dva prekryvajici se cykly, kde se skace na zacatek toho ktereho podle situace? Je to zabava se v tom vyznat.

Nam to prijde prirozene, ale veta o strukturovanem programovani byla ohromny pokrok.

Stejne tak treba promenne jsou velmi uzitecnou abstrakci nad registry - kdyz pisu v assembleru, tak alokace registru sebere velkou cast premysleni nad kodem.

Takze ja myslim, ze dost podcenujes, jak moc jsou - kdysi se to nazyvalo vyssi programovaci jazyky - abstraktnejsi nez assembler (to byl ten nizsi jazyk), a jak moc to pomaha.

[Bherzet]

U dvou vnořených cyklů vyřešíš zvlášť vnější cyklus a zvlášť vnitřní cyklus. break na outer cyklus je jen skok na jeho konec/začátek (podle toho kde máš inkrement a podmínky), ale to neumí ani Python (nebo aspoň dřív to tak bylo, mám pocit, že to tam snad chtěli přidat taky).

Je to určitě míň přehledné a podstatně pracnější než třeba v C, zvlášť když to člověk dělá zřídka a nemá najeté ty patterny (stejně jako např. calling conventions), ale nějakou zásadní abstrakci v tom opravdu nespatřuji. Reálně tě ty chlupaté závorky odstíní od čeho? Od přemýšlení nad tím, jak máš pojmenovat návěstí a uspořádání těch skoků. Stejně jako tě ty proměnné odstíní od přemýšlení nad alokací registrů (a ano, to je opravdu peklo).

[JS1]

Ctes spatne, neslo o vnorene cykly. Jenze v tech mnoha jumpech clovek nepozna, ktery jump je soucast cyklu a ktereho, a uz vubec neni jasne, jestli jsou to cykly. A o tom to je.

V assembleru existuje "navrhovy vzor" cyklus, coz je v zasade podmineny skok na zacatek posloupnosti instrukci, za ucelem opakovani te posloupnosti. Ale presne jak pisu, vyzaduje to extra usili detekovat, ze nekdo tento navrhovy vzor v kodu pouzil. Ne kazdy podmineny skok zpet je cyklem (muze jit treba o reseni vnorene podminky). A proto jsme presli ke strukturovanemu programovani, abychom se zbavili tohoto vzoru, a tudiz kdyz napisu while, je zcela zrejme, ze chci cyklus.

[Bherzet]

Přečetl jsem správně překrývající se cykly, ale protože to je konstrukce, která by vypadala naprosto šíleně i v těch vyšších jazycích, domníval jsem se, že myslíš jen vnořené cykly.

Ale aby bylo jasno: já jsem nerozporoval, že for je abstraktnější než hromada jumpů, jen že mi to prostě jako nijak úžasně vysoká abstrakce nepřijde. Je to nesrovnatelně efektivnější pro programátora, je to více odabstrahované od hardwaru (nemusíš přemýšlet, jaké konkrétní podmíněné skoky použít, například), ale z hlediska uvažování nad řešeným problémem to za nějakou úžasně vysokou abstrakci prostě nepovažuji.

Nicméně ta diskuze je trochu nešťastná, protože oproti assembleru má každé drobné zlepšení, zjednodušení a odabstrahování od technických detailů cenu zlata. Bavíme se vlastně o tom, jak abstraktní by bylo programovat v Céčku bez cyklů a podmínek (muselo by existovat nějaké podmíněné goto).

[JS1]

jen že mi to prostě jako nijak úžasně vysoká abstrakce nepřijde

Ovsemze neprijde, protoze jsi mlady clovek a ucil ses to ve skole. Ale velice inteligentnim lidem trvalo 20 let, nez na to prisli. Tak abstraktni to je.

Stejne tak za 50 let se budou lidi divit, proc existovaly tovarny, kdyz proste stacilo castecne aplikovat funkci. A zaroven nebudou chapat castecnou aplikaci nebo tovarnu jako neco zatracene abstraktniho (budou se divit, proc pro to mit extra nazev).

Je urcity mytus, ze technologicky pokrok probiha od jednodussiho ke slozitejsimu. Ale je to naopak. Pokrok je v tom, ze se ucime resit veci jednoduseji. Je to velmi obtizne, protoze ta jednoducha reseni je casto extremne tezke najit, jdou casto naprosto proti lidske intuici a zvyklostem. Ale pokud jsi se je naucil ve skole, zdaji se byt samozrejma.

[Bherzet]

Písmo taky nepovažuji za o mnoho abstraktnější než jazyk a přesto bychom na něj mohli uplatnit podobný argument. Genialita for-loopu nespočívá v jeho abstraktnosti (byť, znovu, netvrdím, že tam žádná není), ale jeho praktické užitečnosti. Je to opravdu moc šikovné kladivo, kterým se dají velmi dobře mlátit často řešené problémy, ne úplně zbrusu nový pohled na tvorbu programů. Spíš si myslím, že dnes to lidé mohou vnímat jako abstrakci proto, že to kladivo se stalo nedílnou součástí jejich uvažování.

PS: Jsem zatvrzelý samouk a assembler jsem se začal učit těsně po Pascalu někdy v 11.

[Radovan]

Jen jestli za padesát let, při dnešních vzdělávacích trendech, tu funkci bude někdo umět aplikovat. A nechtěl bych maturovat za První republiky

Ty překrývající se cykly jsem používal kdysi na Didaktiku, ještě v BASICu, a dalo mi potom dost práce se to odnaučit. Ony některé věci docela dost zjednodušují

[podlesh]

jen že mi to prostě jako nijak úžasně vysoká abstrakce nepřijde

Ovsemze neprijde, protoze jsi mlady clovek a ucil ses to ve skole. Ale velice inteligentnim lidem trvalo 20 let, nez na to prisli. Tak abstraktni to je.

Stejne tak za 50 let se budou lidi divit, proc existovaly tovarny, kdyz proste stacilo castecne aplikovat funkci. A zaroven nebudou chapat castecnou aplikaci nebo tovarnu jako neco zatracene abstraktniho (budou se divit, proc pro to mit extra nazev).

99% souhlas. To jedno procento je za optimismus

[kralyk z abclinuxu]

Bingo. Začínáme se dostávat k tomu, proč současné programovací jazyky vlastně tak moc úžasně abstraktní nejsou. Zapsat for cyklus je bezesporu efektivnější než rozepisovat ty instrukce ručně, ale abstraktnější je to jen velmi nepatrně: ušetří ti to starost o nějakých pár návěstí a přeskakování mezi nimi.

Tohle už je úplně mimo. Jen "nepatrně abstraktnější" je for loop v C, už je v C++ a Javě je abstraktnější, případně v Pythonu či Rustu je výrazně abstraktnější, jak napsal Bystroushaak, umí pracovat s iterátorovým protokolem, generátory... Ve výsledku se to může zredukovat na pár řádků v assembly, ale taky nemusí, může to invokovat arbitrárně komplexní chování těch iterátorů, generátorů, který může bejt i třeba dynamický v runtime...

for loop tak, jak je definovaný v Pythonu a Rustu (nebo ekvivalteně), je výrazně abstraktnější než v C a assembly, protože umí pracovat obecně s arbitrárně komplexním abstraktním iterovatelným typem.

PS. for loop v C++ a Javě je IMO o trochu méně abstraktní oproti Pythonu a Rustu, protože rozlišuje (z historických důvodů) jednoduchou C-like numerikou vs abstraktní iteraci.

[Bherzet]

Napsat tu iteraci přes iterátor ručně fakt zas takové inferno není. Je trochu abstraktnější to nemuset dělat, ale fakt ne o moc.

Mně přijdou abstraktní třeba výjimky, protože tím signalizuji chybu úplně samostatnou cestou. Nehrozí mi kolize (významu) hodnot v jednom návratovém typu, nebo těch hodnot explicitně vracet víc. Kterákoliv metoda může vyhodit výjimku. Navíc si ta výjimka nese nějaký typ, ze kterých se dají stavět i celé hierarchie a lze odchytávat celé kategorie chyb. To je abstrakce. Celý try/catch/finally blok je abstrakce.

Ale smyčka? Kterou při programování nebo debugování běžně expanduješ v hlavě atd.?

[kralyk z abclinuxu]

Napsat tu iteraci přes iterátor ručně fakt zas takové inferno není.

Kdybych měl do C přepsat některé věci, co se dělají s iterátorama třeba v tom Rustu, tak to je na stovky řádek. Samozřejmě to nezahrnuje jenom for-smyčku jako takovou, ale i další koncepty jako traity, closures apod, ale jde o to, že ten for loop do toho velmi dobře zapadá, je napojen na ty ostatní abstrakce. Tj. v Pythonu na OOP/dispatch metod, generátory atd., v Rustu na traity, ownership atd.

Mně přijdou abstraktní třeba výjimky, protože tím signalizuji chybu úplně samostatnou cestou.

Ano, je to abstrakce, ale poměrně kontroverzní. Vlastnost, že jakákoli funkce může víceméně náhodně vybouchnout a úplně jinou cestou odejít úplně někam jinam do kódu není kdovíjak super. Osobně jsem opravdu rád, že Rust výjimky nemá a používá místo toho funkcionální styl práce s chybama. (Resp. technicky vzato ten mechanismus taky má, ale používá se pouze pro fatální chyby, asserty apod.) Having said that, můj dlouhodobý názor je, že opravdu dobrý a příjemný mechanismus řešení chyb neexistuje a jsou jen více či méně špatné (a různým způsobem).

Jinak o try/catch/finally bys taky mohl říct, že to je reálně jen nějaký šachování se stackem, který není ve skutečnosti zas tak infernálně složitý a mohl bys v Céčku něco podobnýho nachackovat pomocí longjmp a podobně...

Nebo si vem třeba RAII, to taky není implementačně nijak složitý, ale přitom to je velmi užitečná abstrakce.

Koneckonců, tady narážíme na to, co jsem popsal ve #419, totiž že zatímco ten dolní konec abstrakce (absence abstrakce) je celkem dobře definovanej / shodnem se na něm, ten horní je totálně v mlhách a lidi se neshodnou, co je/není abstraktnější a co je/není dobrá abstrakce.

[Bherzet]

Podle mě se na ten výrok díváte moc tou optikou, že assembler je nejnižší možná abstrakce a současné jazyky ta nejvyšší. Já se na to dívám tou optikou, že současné programování samo o sobě prostě nijak úžasně abstraktní není a ta skutečná abstrakce leží někde daleko před námi. Tím se ta osa roztáhne, resp. prodlouží, a dvě tečky, které do té doby ležely na opačných stranách, se smrsknou na jeden bod, které se až při hodně velkém zazoomování rozdělí na dva. Proto jsem i v nějakém předchozím komentáři psal, že to je pření se o milimetry zatímco před námi leží kilometry neprobádaného prostoru.

A taky jsem psal třeba:

Jak abstraktní je přemýšlet nad tím, v kolika vláknech můj program poběží a řešit z toho vyplývající problémy? Jak abstraktní je řešit serializaci a deserializaci dat?

Docela se divím, že se té druhé věty nechytl Bystroushaak, protože to je přesně v souladu s těmi jeho objektovými databázemi apod. Jazyk, potažmo celý softwarový stack, který by to reálně vyřešil tak, že by opravdu nebylo nutné se srát s nějakými databázemi a přehazováním souborů apod. a bylo to udělané tak dobře, že by to nepřinášelo víc problémů než užitku, by byl abstrakcí úplně někde jinde než co máme teď.

Totéž první příklad. To není o relativně tupé expanzi nějakých for-loopů, která je prostě strašně pracná spíš než kdovíjak složitá, ale o úplně novém přístupu. Dnes si pomáháme těmi návrhovými vzory, které tobě a JS1 leží v žaludku, a kterými – ovšem stále za poměrně značného přemýšlení a prostoru pro chybovost – místy vyjadřujeme tu chybějící abstrakci. To by byla úplná revoluce, úplně nový přístup.

ad výjimky: ano, vím, že se to někde řeší i jinak a z hlediska abstrakce to je cca stejné. O pokusech našroubovat výjimky-like mechanismy do C vím, ale dře to. Úplně programátora odstínit od uvažování nad tím, co se děje dole kromě toho, že musí pamatovat na hierarchii volání, na kterou musí myslet stejně i kvůli návratovým hodnotám, za abstrakci považuji. Při debugování for-loopu běžně musíš přemýšlet krok po kroku co se dělá a v jakém pořadí a dost často to přímo vyžaduje znalost implementačních detailů všech těch iterátorů apod. To je prostě srovnatelné se čtením kódu v assembleru. Ale že u funkcí nemusím řešit, jakože fakt vůbec řešit, calling conventions, že u výjimek nemusím vůbec přemýšlet nad tím, jak to probublá nahoru, dokud to někdo neodchytí, mi přijde z hlediska abstrakce významnější rozdíl než jestli budu iterovat přes kolekci jednořádkovým forem, nebo si vyrobím iterátor, jeden label, přečtu další prvek (pokud ho má, jinak goto KONEC), něco s ním provedu a goto ten label. A za tím už akorát ten label KONEC.

[Bystroushaak]

Docela se divím, že se té druhé věty nechytl Bystroushaak, protože to je přesně v souladu s těmi jeho objektovými databázemi apod. Jazyk, potažmo celý softwarový stack, který by to reálně vyřešil tak, že by opravdu nebylo nutné se srát s nějakými databázemi a přehazováním souborů apod. a bylo to udělané tak dobře, že by to nepřinášelo víc problémů než užitku, by byl abstrakcí úplně někde jinde než co máme teď.

Mno, ale tohle řeší Smalltalk posledních padesát let, a všem je to vesměs ukradené.

To by byla úplná revoluce, úplně nový přístup.

Osobně mám v hlavě a částečně ve wiki blog na téma paralely blenderu s programovacími IDE, respektive nedestruktivního modelování v blenderu s funkcionálním programováním. Snad z toho někdy neco bude.

[xkucf03]

Mno, ale tohle řeší Smalltalk posledních padesát let, a všem je to vesměs ukradené.

Tohle řeší kde kdo – jen musíš zůstat uzavřený v jeho světě, stejně jako u toho Smalltalku. Jakmile chceš komunikovat s okolím, tak se musíš těmi serializacemi a spol. zabývat (jde to různě automatizovat nebo posunout na jinou vrstvu, abys to nemusel řešit přímo v aplikaci, ale zbavit se toho nejde).

[Bystroushaak]

Proto jsem tu (a na blogu v angličtině) napsal ten rant, že by to měl řešit přímo operační systém, že.

[Fluttershy, yay!]

Podle mě se na ten výrok díváte moc tou optikou, že assembler je nejnižší možná abstrakce a současné jazyky ta nejvyšší. Já se na to dívám tou optikou, že současné programování samo o sobě prostě nijak úžasně abstraktní není a ta skutečná abstrakce leží někde daleko před námi.

…

Docela se divím, že se té druhé věty nechytl Bystroushaak, protože to je přesně v souladu s těmi jeho objektovými databázemi apod. Jazyk, potažmo celý softwarový stack, který by to reálně vyřešil tak, že by opravdu nebylo nutné se srát s nějakými databázemi a přehazováním souborů apod. a bylo to udělané tak dobře, že by to nepřinášelo víc problémů než užitku, by byl abstrakcí úplně někde jinde než co máme teď.

Však nejde jenom o programování ve smyslu psaní kódu, nýbrž návrh systémů – kde je dnes úrovní abstrakce fpysk, nikdo se v tom celém úplně nevyzná a hledat chyby je problém.

Vnímám určitý zájem uvažovat software jako biologický systém a mít možnost analogicky s ním manipulovat na všech úrovních včetně té nejnižší (což je spor např. s „velkými zlými optimalizujícími překladači“).

Narazil jsem na rozhovor, který to velmi pěkně shrnoval v nějakých 15 minutách, ale už několikrát se mi nepodařilo znovu najít. Mám utkvělou představu, že to bylo v podcastu a16z, leč možná mylnou.

Vlastně není od věci se na to podívat z druhé strany: jak se dělají skládačky v biotechu („lego“).

[xkucf03]

Jazyk, potažmo celý softwarový stack, který by to reálně vyřešil tak, že by opravdu nebylo nutné se srát s nějakými databázemi a přehazováním souborů apod.

Takový malý háček je v tom, že tohle funguje jen dokud se pohybuješ v rámci toho svého jazyka či platformy. Ale jakmile chceš komunikovat se svým okolím, které může používat jiné jazyky/platformy, tak už musíš řešit nějak tu serializaci a dohodnout si nějaké rozhraní, kterým budeš komunikovat. Kdyby všichni psali v Javě, tak by všechno byly javovské objekty a nemusel bys nic řešit. Ale protože někteří chtějí psát v Pythonu, někteří v Rustu, C++, D, Go atd. tak se musíme zabývat takovými věcmi, jako jsou serializace objektů, síťové protokoly, formáty souborů atd. A protože někde jsou velcí indiáni a někde malí indiáni a někde mají UTF-8 a někde UTF-16 atd. tak ani v rámci jednoho jazyka nemůžeš jen tak vyplivnout obsah paměti na disk nebo do síťového soketu.

Ty konverze se ale dají automatizovat. Např. v Javě máš JAXB, JPA a další nástroje, takže to mapování nemusíš řešit pomocí imperativního kódu, ale jen deklaruješ určité vztahy či vlastnosti.

Taky by se dal vymyslet nějaký společný objektový model¹, ale stále tam budeš mít nějaké konverze a serializace. Spíš jde jen o to, jestli tu serializaci/mapování dokážeš automatizovat a na jaké úrovni ji budeš dělat. Asi se shodneme, že do aplikační logiky to nepatří, ta by od takových věcí měla abstrahovat. Ale zbavit se toho nejde – dokud budou procesory pracovat s bity a bajty a dokud bity a bajty budou téct po síťových linkách. Případně můžeš dostat víc jazyků na společnou platformu a do jednoho procesu (GraalVM).

_{[1] ostatně viz CORBA, D-Bus, webové služby a další + ASN.1 a nespočet různých dalších serializačních formátů}

[Bherzet]

Mně přijde, že to nefunguje ve velkém rozsahu (zatím) nikde. Vždycky jsou s tím problémy. Ať už z hlediska efektivity, spolehlivosti, nebo prostě obecně použitelnosti. Samozřejmě se to zkoušelo, takové projekty existují a v omezené míře můžou fungovat, protože se soustředí na vytvoření abstrakce nad ten který scénář, ale nefunguje to prostě totálně univerzálně a bezstarostně.

Vem si třeba jak abstraktní by bylo, kdybys jen v jazyce říkal, že chceš z objektů splňující nějaká kritéria určité hodnoty a on se prostě super vyoptimalizovanými dotazy postaral o to, abys je dostal. Musel by dělat nad tím kódem analýzu, dělat predikce podle statistik (protože ne všude to jde staticky, že), popř. přeložit část kódu do SQL (např. zjistit, že se v kódu pracuje s fieldem A a pokud má nějakou hodnotu, tak i s fieldem B, a pak načíst všechny fieldy A a u řádků, kde má tu danou hodnotu, ještě field B) atd. V současnosti se to omezuje vesměs na to, že si někde načteš objekt (buď celý, nebo musíš explicitně vyjmenovat, s čím se bude pracovat, nad čímž musíš přemýšlet) a ten si v aplikaci posíláš sem a tam.

V podstatě stejně abstraktně bys mohl programovat už dnes, akorát je to v praxi totálně nepoužitelné, protože budeš mít řádově víc dotazů.

[xkucf03]

Vem si třeba jak abstraktní by bylo, kdybys jen v jazyce říkal, že chceš z objektů splňující nějaká kritéria určité hodnoty a on se prostě super vyoptimalizovanými dotazy postaral o to, abys je dostal. Musel by dělat nad tím kódem analýzu, dělat predikce podle statistik (protože ne všude to jde staticky, že), popř. přeložit část kódu do SQL (např. zjistit, že se v kódu pracuje s fieldem A a pokud má nějakou hodnotu, tak i s fieldem B, a pak načíst všechny fieldy A a u řádků, kde má tu danou hodnotu, ještě field B) atd.

Tohle částečně dělá nebo k tomu směřuje GraalVM. Na přednáškách se např. ukazovalo, jak si namapovat velký heap dump na objekty. A tím nemyslím to, že by se načetl a nakopíroval do objektů, ale fungovalo to spíš jako proxy a ten velký soubor se procházel a parsoval postupně, podle toho, ke kterým objektům/atributům jsi přistupoval a jaké jsi na nich volal metody. A teď si místo toho heap dumpu představ třeba relační databázi…

Případně máš (už delší dobu) nástroje jako Jinq, které stírají hranici mezi objekty a databázemi (víc než ORM).

V podstatě stejně abstraktně bys mohl programovat už dnes, akorát je to v praxi totálně nepoužitelné, protože budeš mít řádově víc dotazů.

Jak kde. Třeba takové ORM je pro většinu použití celkem dobře použitelné už dnes. A těch pár věcí si optimalizuješ ručně. Na druhou stranu přidává to určitou komplexitu a nepřímost (přidává vrstvu indirekce, hrozné slovo)… takže nemám problém ani s tím, když někdo programuje „nízkoúrovňově“ klidně s JDBC a píše SQL ručně… Je potřeba zvážit výhody a nevýhody obou přístupů pro konkrétní projekt.

Ale časem se to asi posune do roviny, ve které je dneska assembler nebo pomalu i céčko – psát takto nízkoúrovňový kód je neefektivní a stroje to dokáží (téměř vždy) lépe než člověk.

Zajímavější otázka je spíš: proč? Jaké úlohy budeme v budoucnu pomocí softwaru řešit a jaké budeme mít priority, k čemu tu vyšší abstrakci využijeme? Bude to jen kvantitativní posun (vývoj bude ještě rychlejší a levnější¹ než teď)? Nebo kvalitativní (budeme dělat něco výrazně jiného)? A jak do toho zapadá umělá inteligence? Bude za nás AI vyvíjet software a budeme jí předhazovat zadání podobné tomu, jaké dnes dostávají týmy programátorů? Pak by nějaká úroveň abstrakce programovacího jazyka byla úplně irelevantní, protože člověk by s tím jazykem už ani nepřišel do styku.

_{[1] i když ono i s dnešní efektivitou vývoje se dají dělat velmi výnosné projekty – a naopak když to selže, tak často není problém v tom, že by vývoj trval moc dlouho a selhalo by to asi i kdyby stál desetinu, protože ta příčina byla většinou už v zadání}

[Bystroushaak]

Takový malý háček je v tom, že tohle funguje jen dokud se pohybuješ v rámci toho svého jazyka či platformy. Ale jakmile chceš komunikovat se svým okolím, které může používat jiné jazyky/platformy, tak už musíš řešit nějak tu serializaci a dohodnout si nějaké rozhraní, kterým budeš komunikovat. Kdyby všichni psali v Javě, tak by všechno byly javovské objekty a nemusel bys nic řešit. Ale protože někteří chtějí psát v Pythonu, někteří v Rustu, C++, D, Go atd. tak se musíme zabývat takovými věcmi, jako jsou serializace objektů, síťové protokoly, formáty souborů atd. A protože někde jsou velcí indiáni a někde malí indiáni a někde mají UTF-8 a někde UTF-16 atd. tak ani v rámci jednoho jazyka nemůžeš jen tak vyplivnout obsah paměti na disk nebo do síťového soketu.

Tohle docela elegantně řeší GraalVM.

[Bherzet]

Tak ono mě šlo spíš o optimalizaci těch dotazů jako takovou. Komunikace s okolním světem už není otázka abstrakce na úrovni jazyka/frameworku.

[kralyk z abclinuxu]

Podle mě se na ten výrok díváte moc tou optikou, že assembler je nejnižší možná abstrakce a současné jazyky ta nejvyšší.

Zajímavý, já měl přesně tenhle pocit z tvojí argumentace.

u výjimek nemusím vůbec přemýšlet nad tím, jak to probublá nahoru, dokud to někdo neodchytí

Ale musíš, musíš řešit, jestli někde po cestě nezůstal nevalidní stav, leaknutej otevřenej soubor, leaknutej zamčenej mutex atd., všechno to ošetřit, aby to bylo exception-safe...

Mně přijde, že ty zaměňuješ složitost implementace té abstrakce s úrovni abstrakce. Přitom spousta abstrakcí jsou implementačně relativně jednoduchý, přesto vedou k poměrně vysoce abstraktnímu kódu.

[Bherzet]

Ale musíš, musíš řešit, jestli někde po cestě nezůstal nevalidní stav, leaknutej otevřenej soubor, leaknutej zamčenej mutex atd., všechno to ošetřit, aby to bylo exception-safe...

Což bych musel stejně i bez nich.

Mně přijde, že ty zaměňuješ složitost implementace té abstrakce s úrovni abstrakce.

Ne. Za abstrakci považuji odstínění od některých věcí, abych nad nimi nemusel přemýšlet. Shodou okolností pak mezi úrovní abstrakce a složitostí její implementace bude většinou korelace.

[kralyk z abclinuxu]

Což bych musel stejně i bez nich.

V kódu:

lock(mutex);
foo();
unlock(mutex);

Je hodně velký rozdíl v tom, jestli foo() může nebo nemůže vyhodit výjimku, tj. jestli (ne)existuje ta paralelní návratová cesta.

[Bherzet]

Nj, proto finally.

[kralyk z abclinuxu]

... které C++ nemá, a přesto se tam dá tohle řešit ... hmmm ...

[xkucf03]

std::mutex + RAII? (dokonce tam máš přesně tohle jako modelový příklad)

[kralyk z abclinuxu]

Ano, to jsem měl na mysli

[Bherzet]

Kontext: Kdybych chyby řešil Gottem (sic!), vyplývaly by z toho stejné problémy, ale neměl bych to finally.

[Josef Kufner]

Smyčka samotná až tak moc velká abstrakce není, ale tělo smyčky už ano. Bez toho byly jen podmíněné skoky, kdežto bloky kódu vnáší do programu strukturu.

Co se výjimek týče, docela zajímavé alternativní řešení používá Rust. V typovém systému je zadefinován typ pro vyjádření chyb a ten pak lze zpracovat běžnými jazykovými konstrukcemi, avšak je přidán syntaktický cukřík, který to učiní podobně pohodlné jako jsou výjimky.

[kralyk z abclinuxu]

Co se výjimek týče, docela zajímavé alternativní řešení používá Rust.

Jen bych k tomu dodal, že to nevynalezl Rust, ale je to víceméně okopírovaný z Ocamlu, potažmo celý ML family, je to monáda. (I když je pravda, že OCaml, pokud čtu dobře, používá exception pro error handling.) Rust možná vynalezl ten ? operátor? To je takové trochu propojení těch monadických error typů s imperativním jazykem...

[deda.jabko]

Mam takovy pocit, ze vzdycky ctes jen tu prvni cast vety.

Dulezita je i ta cast posuzovala podle toho, co ten jazyk bude provadet. Pokud budes mit program v C, ktery bude prelozen do strojoveho kodu a vykonan nebo jej bude interpretovat interpret napsany v JavaScriptu, porad to bude stejny jazyk, stejne urovne.

Pokud můžeš vzít dva jazyky, dát je vedle sebe (například jsi v obou programoval) a jasně vyhodnotit který z nich ti přijde „vysokoúrovňovější v použité abstrakci“, tak s tím nevidím žádný problém

Ano, muzes a to ani v nich nemusis programovat. Akorat ti z toho nevyjde rozdeleny do dvou skupin (nizko- a vysokourovnovy jazyk), ani ti z toho nevyjde uplne usporadani, ale nejspis jenom castecne usporadani.

Nevim, proc by na tom mela panovat nejaka vyslovena shoda. Kazdy kdo ma predstavu o programovacich jazycich, by mel byt schopen videt, ze co se tyce urovne abstrakce, kterou jazyky nabizi plati napr. usporadni ASM < C < C + preprocessor < C++ nebo ASM < Sinclair Basic < Visual Basic.

Pokud si dám na jednu stranu python, common lisp, nebo třeba smalltalk a na druhou javu, tak sorry jako, java je z hlediska abstrakce, použitých konstrukcí

Kdyby sis svet nedelil na cerny a bily, ale rozlisoval i odstiny, nemusel bys resit, jestli je neco vysokourovnove nebo nizkourovnove.

Navic casto zalezi na kontextu. Zatimco lepic JS aplikaci bude C++ povazovat za zoufale nizkourovnovy jazyk, v embedded svete te s tim vyzenou, ze neco tak vysokourovneho pouzivat nebudou.

a programátorské pohodlnosti nízkoúrovňový jazyk.

Ale to uz je jina charakteristika. Napr. CommonLISP spousta lidi nedava, i kdyz je to vysokourovnovy jazyk, protoze kod se zapisuje nepohodlne/nezvykle do zavorek.

Na Javě je „vysokoúrovňové“ asi tak to, že má GC a objekty.

Nebo treba uplne odstineni od bezici platformy.

Čímž nechci popírat vyspělost java platformy, jen poukázat na to, že pokud ti jde o abstrakci, tak java nějak zazáří asi jen ve srovnání s C/C++.

Nebo treba Go, Rust.

Čímž nechci popírat vyspělost java platformy, jen poukázat na to, že pokud ti jde o abstrakci, tak java nějak zazáří asi jen ve srovnání s C/C++.

A jsme zpatky u toho cernobileho videni sveta, kdy je neco pouze nizkourovnove nebo vysokourovnove, spatne a dobre. Navic vysokourovnost nemusi byt v praxi kyzena velicina, coz doklada popularita Go, kdy jeho autori zahodili poslednich dvacet let vyvoje programovacich jazyku a vytvorili jazyk vyrazne jednodussi, nez jsou soudobe jazyky a presto ten jazyk lidi radi pouzivaji.

[Bystroushaak]

Dulezita je i ta cast posuzovala podle toho, co ten jazyk bude provadet. Pokud budes mit program v C, ktery bude prelozen do strojoveho kodu a vykonan nebo jej bude interpretovat interpret napsany v JavaScriptu, porad to bude stejny jazyk, stejne urovne.

Souhlasím.

Ano, muzes a to ani v nich nemusis programovat. Akorat ti z toho nevyjde rozdeleny do dvou skupin (nizko- a vysokourovnovy jazyk), ani ti z toho nevyjde uplne usporadani, ale nejspis jenom castecne usporadani.

Jo, ale vyjde ti nějaké grupování, kde docela jasně uvidíš, že Java je někde v půlce. Pak nedává moc smysl tomu říkat vysokoúrovňový jazyk obecně, když je tam kopec ještě-víc-vysokoúrovňovějších. Ale subjektivně to tak může působit.

Nevim, proc by na tom mela panovat nejaka vyslovena shoda. Kazdy kdo ma predstavu o programovacich jazycich, by mel byt schopen videt, ze co se tyce urovne abstrakce, kterou jazyky nabizi plati napr. usporadni ASM < C < C + preprocessor < C++ nebo ASM < Sinclair Basic < Visual Basic.

Já jsem zmatený z toho jak prvně něco popřeš („Nevim, proc by na tom mela panovat nejaka vyslovena shoda.“) a pak napíšeš to samé („Kazdy kdo ma predstavu o programovacich jazycich, by mel byt schopen videt ..“).

Kdyby sis svet nedelil na cerny a bily, ale rozlisoval i odstiny, nemusel bys resit, jestli je neco vysokourovnove nebo nizkourovnove.

Eh. Doslova jsem tu tu škálu uvedl a definoval. Bavím se o tom, že z objektivního hlediska nemá moc smysl tvrdit že je java vysokoúrovňová, když se na ní nachází někde uprostřed, zatímco ze subjektivního uhlu pohledu to smysl dávat může, speciálně pokud se na ní mentálně nacházíš někde u C. Což je přesně to co uvádíš v druhém odstavci.

Ale to uz je jina charakteristika. Napr. CommonLISP spousta lidi nedava, i kdyz je to vysokourovnovy jazyk, protoze kod se zapisuje nepohodlne/nezvykle do zavorek.

_{[Kontext: já v lispu nedělám.]}

To dělají lidi, kteří v něm neprogramují. Lidi co v něm dělají jsem vždy viděl tvrdit opak, tedy že když použiješ strukturální editor, tak je to ve skutečnosti lepší než jazyky bez závorek.

Nebo treba uplne odstineni od bezici platformy.

Eh, na to si ještě někdo pořád hraje jo? Už se tu stokrát rozebíralo, že to není tak úplně pravda, jak se původně propagovalo.

Nebo treba Go, Rust.

Jo, speciálně rust.

A jsme zpatky u toho cernobileho videni sveta, kdy je neco pouze nizkourovnove nebo vysokourovnove, spatne a dobre.

To „špatné a dobré“ si tam dosazuješ sám. Já se například taky aktivně snažím vracet k jazykům, které jsou starší.

Navic vysokourovnost nemusi byt v praxi kyzena velicina, coz doklada popularita Go, kdy jeho autori zahodili poslednich dvacet let vyvoje programovacich jazyku a vytvorili jazyk vyrazne jednodussi, nez jsou soudobe jazyky a presto ten jazyk lidi radi pouzivaji.

To je validní argument. Z nedávné doby taky zaujal Vlang. Jinak osobně mi vyhovuje opak, tedy třeba přístup pythonu, nebo rustu, který se snaží cpát věci do syntaxe, než naopak. Ale chápu to kouzlo, ostatně si píšu vlastní jazyk inspirovaný Selfem, který má syntaxi naprosto minimální, až skoro lispovskou.

[deda.jabko]

Já jsem zmatený z toho jak prvně něco popřeš („Nevim, proc by na tom mela panovat nejaka vyslovena shoda.“)

Protoze tu shodu predpokladas ty, abychom se mohli bavit o vysokourovnovosti jako mire. Viz: Jestliže se takhle dokáže shodnout víc lidí, tak není důvod proč to nepoužívat v běžném mluveném jazyce jako „vysokoúrovňovější“.

Eh. Doslova jsem tu tu škálu uvedl a definoval. Bavím se o tom, že z objektivního hlediska nemá moc smysl tvrdit že je java vysokoúrovňová, když se na ní nachází někde uprostřed, zatímco ze subjektivního uhlu pohledu to smysl dávat může, speciálně pokud se na ní mentálně nacházíš někde u C. Což je přesně to co uvádíš v druhém odstavci.

Sorry, psal jsem tu odpoved delsi dobu a ty pozdejsi prispevky jsem uz nevidel.

Eh. Doslova jsem tu tu škálu uvedl a definoval. Bavím se o tom, že z objektivního hlediska nemá moc smysl tvrdit že je java vysokoúrovňová, když se na ní nachází někde uprostřed, zatímco ze subjektivního uhlu pohledu to smysl dávat může, speciálně pokud se na ní mentálně nacházíš někde u C. Což je přesně to co uvádíš v druhém odstavci.

Pripomenu, ze tato diskuze zacala tvrzenim: Protože Java není vysokoúrovňový jazyk! Je to nízkoúrovňový jazyk srovnatelný s C.

Eh, na to si ještě někdo pořád hraje jo? Už se tu stokrát rozebíralo, že to není tak úplně pravda, jak se původně propagovalo.

Bavime se tu porad o tom jazyku. Ze se jde dostat do situace, kdy aplikaci udelas platformove zavislou, je jina (a navic se musis trochu snazit).

[Bystroushaak]

Protoze tu shodu predpokladas ty, abychom se mohli bavit o vysokourovnovosti jako mire. Viz: Jestliže se takhle dokáže shodnout víc lidí, tak není důvod proč to nepoužívat v běžném mluveném jazyce jako „vysokoúrovňovější“.

Jo, ale jde mi o to že sice teda popřeš že na tom panuje shoda, ale pak napíšeš že „každý kdo ..“, čímž tu samou shodu vlastně taky předpokládáš.

Sorry, psal jsem tu odpoved delsi dobu a ty pozdejsi prispevky jsem uz nevidel.

V pohodě.

Pripomenu, ze tato diskuze zacala tvrzenim: Protože Java není vysokoúrovňový jazyk! Je to nízkoúrovňový jazyk srovnatelný s C.

Jasně, ale když se na to koukáš pohledem někoho, kdo dělá třeba v ocamlu, nebo co já vím, tak to tak skutečně z hlediska jazyka dost působí. Je to realtivně lowlevel imperativní oop jazyk, jehož nejvíc abstraktní feature je že má objekty, garbage collector a lambdu. Což pohledem někoho kdo dělá v něčem dost abstraktním jsou tak základní věci, že rozdíl mezi C je z hlediska funkcionalit jazyka jen malý.

Například s kamarádem jsem několikrát řešil ten pocit, kdy děláme v pythonu a máme pocit, jak kdyby jsme měli chapadla. Sem hodíš iterátor, zkombinuješ dva generátory, namapuješ je přes partial a celé to proženeš přes dvě list comprehensiony a celkově prostě děláš naprosto vysokoúrovňové věci, které by někde jinde mohly zabrat 10-100x tolik kódu, i když by teoreticky byly samozřejmě taky možné.

Ten samý kamarád mi pak vyprávěl, že to je hovno oproti tomu co dělá běžně v lispu, kdy má tohle všechno ještě, ale u toho provádí makrotransformace ast a různé další věci, které jsem některé ani nepochopil (funcionální záležitosti). Z jeho uhlu pohledu je java asi stejně lowlevel, jako to C, protože když tam budeš chtít udělat to samé, tak se upíšeš k smrti a budeš muset vybudovat zámek z křišťálu a patternů.

Bavime se tu porad o tom jazyku. Ze se jde dostat do situace, kdy aplikaci udelas platformove zavislou, je jina (a navic se musis trochu snazit).

Ok. Osobně mi to nepřijde jako zas tak kulervoucí věc, ale to je asi můj bias, protože to tak nějak +- měly všechny jazyky co jsem používal a navíc multiplatformní věci tak úplně nedělám.

[deda.jabko]

Jo, ale jde mi o to že sice teda popřeš že na tom panuje shoda, ale pak napíšeš že „každý kdo ..“

Ty zacinas vetu, jestlize se... tedy apriori predpokladas, ze ta shoda neexistuje, ale mohla by. Ja tvrdim, ze ta shoda neni potreba, protoze je to zjevne.

Což pohledem někoho kdo dělá v něčem dost abstraktním jsou tak základní věci, že rozdíl mezi C je z hlediska funkcionalit jazyka jen malý.

Vzhledem k tomu, ze aktivne (podle situace) pouzivam C, Javu i Lispove jazyky, mam docela jasnou predstavu, jake jsou ty moznosti abstrakce, ktere nabizi.

Sem hodíš iterátor, zkombinuješ dva generátory, namapuješ je přes partial a celé to proženeš přes dvě list comprehensiony a celkově prostě děláš naprosto vysokoúrovňové věci, které by někde jinde mohly zabrat 10-100x tolik kódu, i když by teoreticky byly samozřejmě taky možné.

Nechci vam brat iluze, ale az na ty generatory si v zasade ujizdite jen na syntaktickem cukru. Muzes si v Pythonu naprogramovat vlastni for?

[Bystroushaak]

Ty zacinas vetu, jestlize se... tedy apriori predpokladas, ze ta shoda neexistuje, ale mohla by. Ja tvrdim, ze ta shoda neni potreba, protoze je to zjevne.

Ok, já chápu tvojí pozici, jen se mi zdá, že pokud je to zjevné, tak ta shoda automaticky existuje. Ale whatever, asi nemá smysl to dál pitvat.

Nechci vam brat iluze, ale az na ty generatory si v zasade ujizdite jen na syntaktickem cukru.

Jako .. jo. Ale nechápu proč lidi používají ten termín takhle divně skoro jako pejorativně. Celý jazyk je syntaktický cukr (user interface spíš) nad kompilátorem / interpretrem a na tom jak moc je něco namáhavé a použitelné přece záleží. Python zrovna docela dobře vychytává sweet spot, kdy to má dost syntaktického cukru, ale zároveň jsou věci ještě dost čitelné a dělají se preferovaně jedním způsobem, aby z toho nebyl perl, nebo k.

Muzes si v Pythonu naprogramovat vlastni for?

V čistém ne (resp. jde to přes ast modul a load hook, ale je to jak drátem do oka), ale jsou na to samozřejmě knihovny. Akorát python se pro to moc nehodí.

[Josef Kufner]

Celý jazyk je syntaktický cukr (user interface spíš) nad kompilátorem / interpretrem …

To není pravda. Jazykové konstrukce odráží formální koncepty na kterých daný jazyk stojí. Syntaktický cukr pak "jen" zjednodušuje zápis častých případů. Například cyklus není jen syntaktický cukr nad instrukcemi CMP a JNZ, ale přináší koncept strukturovaného kódu (za cenu, že není možné skákat kam se zachce). Oproti tomu například async/await v Javascriptu jsou jen syntaktickým cukrem nad Promises, kdy celý koncept je implementován jako knihovna (později standardní) a syntaktický cukr "jen" zjednodušuje a zpřehledňuje použití, ale oproti té knihovně už nepřináší nic nového.

… a na tom jak moc je něco namáhavé a použitelné přece záleží.

To rozhodně. Na této pointě stojí všechny Domain-Specific Languages, které skrývají široké možnosti jejich interpretu, aby se v tom uživatelé vyznali a nemohli moc prasit.

[podlesh]

Proč prvně reaguješ sarkasticky na podleshe a pak tvrdíš v podstatě to samé co on?

Protoze to netvrdim. Za prve je absurdni, aby se uroven jazyka posuzovala podle toho, co ten jazyk bude provadet.

Nic takového jsem ale netvrdil. Tedy, rozhodně ne úmyslně.

Za druhe je to otazka miry, jak moc je jazyk nizko nebo vysoko urovnovy.

Což jsem naopak tvrdil a je to můj hlavní bod.

Podlesh manipulativne predefinovava pojmy, "aby mu to vyslo", ale Java je spise vysokourovnovy jazyk, vzhledem k tomu, jak ma reseny objekty, vyjimky, reflexi a dalsi veci.

Tady je jediná věc kde se rozcházíme - objekty a výjimky definuje JVM a Java jakožto jazyk je jen tupý převod 1:1 do bytecode.

A uznávám že tohle rozdělení je poněkud kontroverzní.

Na co jsem v tom odstavci primarne reagoval je veta: "Pravda, v posledních několika verzích se i Java významně posunula nahoru,". Coz neni pravda, protoze v poslednich verzich vazne nedoslo k pridani dalsich vyssich urovni abstrakce, ale to z Javy nedela nizkourovnovy jazyk.

Ok, beru zpět - poslední posun byl fakt docela dávno.

[podlesh]

Ale hlavně: To tvrzení "Java je nízkoúrovňový jazyk srovnatelný s C" je skutečně přehnané a rozhodně ho nemyslím opravdu vážně. Je to jen zrcadlo toho jak se v této (a jiných) diskusích hází termínem "vysokurovňové jazyky" a míní se tím Java, Python i Lisp.

Je celkem dobře že jste se toho chytli, alespoň se tady občas taky o něčem diskutuje.

Za tím, že Java a Lisp se těžko dají co do úrovně abstrakce srovnávat si ale 100% stojím!

[JS1]

Za tím, že Java a Lisp se těžko dají co do úrovně abstrakce srovnávat si ale 100% stojím!

Tim si nejsem tak jisty. Soudruzi z projektu Lombok a dalsich usilovne pracuji na vyvoji vlastni alternativy k Lispu v Jave. Ale misto toho, aby se poucili z historie, treba prave z Lispu nebo dokonce lambda kalkulu, kde jsou zakladnim stavebnim kamenem funkce, voli odvazne vlastni cestu, pres anotace a generovani kodu. Ja jejich usili sleduji se zatajenym dechem!

[xkucf03]

Tohle je jedna z věcí, která mi na Javě vadí – anotační procesory (které si může kdokoli psát), tak jak jsou oficiálně specifikované, jsou příliš slabé. Lombok to pak musí hackovat přes privátní rozhraní OpenJDK (podporovaný je ještě tuším Eclipse kompilátor), takže pak jsi v době kompilace závislý na konkrétním JDK (v době běhu už ne – výsledkem je standardní bajtkód, který běží všude).

Přijde mi, že to v Sunu/Oraclu pořád někdo blokuje, i když se na to lidi často ptají a i když by to ten jazyk podle mého udělalo ještě lepším. Možná se bojí, že by to otevřelo Pandořinu skříňku a vedlo k navýšení komplexity a nároků na programátory.

Tohle je vždycky otázka, co do jazyka ještě dát, kolik volnosti nechat, jak moc to mít univerzální… Jeden extrém je Go. Druhý extrém je třeba C++. Rust nebo D taky nejsou zrovna jednoduché, ale aspoň jsou mladší a čistěji navržené, měli šanci se poučit z cizích chyb (kdežto to C++ si nese historickou zátěž už od 80. let + ještě staršího Céčka). Java je někde mezi tím. A pak jsou jazyky, které jsou zdánlivě velmi jednoduché a zároveň extrémně obecné, jde v nich taky skoro všechno… ale jak moc je to užitečné pro praxi, je otázka.

[Bherzet]

Java bajtkód je vysokoúrovňový sám o sobě (automatická správa paměti, výjimky, virtuální metody, …), takže argumentovat, že pokud proti němu Java nepřidává příliš mnoho další abstrakce, je to „nízkoúrovňový jazyk srovnatelný s C“, je absurdní.

[Radovan]

Kdesi jsem se setkal s výrokem, že kdo tvrdí že C je nízkoúrovňový jazyk, ten nikdy neprogramoval v assembleru

Pokud si vzpomínám, prohlásil to člověk, který je assemblerový mág, takže bych mu to i věřil.

[Bystroushaak]

Například v komunitě lidí, co programují mikrokontrolery je pořád úplně běžné tvrdit, že C je vysokoúrovňový jazyk i dneska.

[podlesh]

Poznámka: ten "ukazovatel" jsem si nevymyslel, je to jedno z klasických témat docenta Bokra.

[kralyk z abclinuxu]

To zní, jakože nějakej docent si vymyslel pravidla, jak by lidi měli mluvit, a ono ejhle, jazyk je živá věc, která si žije vlastním životem...

[Bherzet]

Gratuluji docentu Bokrovi k nalezení jedné z nesčetných jazykových inkonzistencí. Ne, že by to nebylo zajímavé, a že by mě některé jazykové jevy nevytáčěly („pane Novák“), ale je to prostě důsledek vývoje jazyka.

[vencour]

Pan Bokr z Plzně? Nebo je ještě někde nějaký jiný?

[podlesh]

Ano, ZČU. Nedokážu si představit že jich bylo víc!

[vencour]

Jejda, pamatuju, jak nadával na použití slova nejoptimálnější. A na to, že do nás hustil řeckou abecedu. Hezký. Je to on, že?
Škoda, že jich nebylo víc ...

[Radovan]

Jak by asi reagoval na termín "nejpesimálnější", který používal Mel Kaye

[Bherzet]

Mně je jedno, jestli sekal dobrotu, nebo ne. Zatýkali ho tři policisté kvůli podezření, že zaplatil padělanou bankovkou ($20). Klečet na něm osm minut, když si opakovaně stěžoval, že nemůže dýchat, bylo naprosto neopodstatněné. Podle jednoho svědectví, které jsem četl, mu dokonce jeden policista po naléhání kolemstojících zkusil najít pulz a nepovedlo se mu to. Přesto z něj neslezli.

Pokud trojice policistů nedokáže zatknout a odvézt jednoho chlapa obviněného z nenásilného činu, který se trochu vzpouzí (ale nikoho neohrožuje), asi nemají u policie co dělat. V daném případě by bylo lepší ho nechat jít a přenechat ho na později schopnějším kolegům.

O tom, že by kladl odpor, kdyby se k němu ti policisté chovali normálně (úměrně tomu, z jakého činu je obviněn), si taky myslím svoje. Aspoň teda v civilizované zemi s rozumně nastaveným právním systémem, v USA s těmi jejich tresty je to holt těžké.

[Ovoce]

TVL... (doslova!)

Sorry jako, ale byli na něho čtyři(!) policajti, on byl sám, neozbrojenej. Co kurva chceš na tomhle hájit? Ti chlapi posrali svoje povinnosti a zabili člověka. Vzhledem k tomu, co ten hlavní aktér předvedl, to můžeme na 99 % mluvit o vraždě. Ani stopa přeměřenosti, a že máš potřebu kafrat proti většinovýmu názoru nebo co, na tom nic nezmění.

[Aleš Kapica]

Normální člověk si za takové situace rozhodně nevyskakuje.

Vzhledem k tomu co předvedl hlavní aktér – kterým není ten policajt, ale zesnulý černoch lze na 100% tvrdit, že si za to mohl sám!

Můžete se bavit o přiměřenosti zákroku jak chcete, ale rozhodně to není důvod, kterým by bylo možné ospravedlňovat následné pouliční nepokoje!

[Bherzet]

Byli tam na něj čtyři, dostali ho na zem a potřebovali ho naložit a odvézt.

1. Bylo nezbytné mu osm minut klečet na krku?

2. Bylo nezbytné mu na krku klečet i po opakovaných stížnostech, že nemůže dýchat?

3. Bylo nezbytné mu na krku klečet i poté, co přestal reagovat a jednomu ze zasahujících policistů se nepodařilo mu nahmatat pulz?

4. Schvaloval bys takový postup vůči sobě nebo osobě blízké, kdybys v obchodě nevědomky zaplatil padělanou pětistovkou, byl z tebe cítit alkohol a po nasazení pout bys při pokusu nastoupit za popostrkování policistou do auta udělal pohyb, který by si vyložil jako kladení odporu?

[trekker.dk]

Tak mě napadlo, co vlastně měli v plánu? Klečet mu na krku do konce roku? Čekat až přijede zásahovka, protože čtyři proti jednomu je málo?

[Bherzet]

Asi tak. I kdyby čekali na tu zásahovku, ve čtyřech by mu každý mohl držet jednu končetinu plnou vahou těla…

[Bystroushaak]

Vzhledem k tomu co předvedl hlavní aktér – kterým není ten policajt, ale zesnulý černoch lze na 100% tvrdit, že si za to mohl sám!

Myslíš to jak se nechal vytáhnout s auta a spoutat? To jak nekladl odpor? Nebo si to vysloužil tím že si dovolil zakopnout a nechat se pomalu udusit, zatímco prosil o svůj život a upozorňoval na to že nemůže dýchat?

Můžete se bavit o přiměřenosti zákroku jak chcete, ale rozhodně to není důvod, kterým by bylo možné ospravedlňovat následné pouliční nepokoje!

Upřímně když vidím psychopaty jako ty, tak se těm nepokojům nedivím.

[Agent]

Spíš je záázrak, že ty nepokoje nezačly mnohem dřív. Tohle někdo vytáhl, ještě, že máme ty internety..

RAW VIDEO: Officer Dustin Dillard's bodycam shows in-custody death of Tony Timpa

https://www.idnes.cz/zpravy/zahranicni/justine-damondova-smrt-policie-minneapolis.A170719_102339_zahranicni_amu?

Chápu vznik protestů, ale to co se děje teď, je hnus, nabalily se na to skupinky rabovačů, kteří si chtějí jen nakrást. To už fakt podporovat nelze.

Ještě jedno pěkné video, resp. záznam livestreamu - Michal Šopor a Petr Reif o nepokojích v USA | UKS Live stream

[Fluttershy, yay!]

Chápu vznik protestů, ale to co se děje teď, je hnus, nabalily se na to skupinky rabovačů, kteří si chtějí jen nakrást. To už fakt podporovat nelze.

Staletí nejen otrokářství nebyla rabování? Kde jste byli? Mark Twain k tomu má co říct. Jakožto i MLK.

Nebo má jít o to, když během protestů o pár bloků dál probíhají regulérní vloupačky a policie ignoruje – to druhé?

Proč to ignoruje? Protože probíhá koordinovaná strategie terorizovat občanský odpor. Používat např. slzný plyn (navíc útočně) je válečný zločin… když to není zrovna proti vlastnímu obyvatelstvu, že? O tohle rabování má jít?

[xxx]

Jo to uz jsem videl na CNN citovane. Nejaky tweet, ze kdyz teda bily vyhubily indiany, privezli otroky, tak ted black people muzou rabovat. IMHO to jen ukazuje na to, do jakejch sracek se tam ritej.

[Fluttershy, yay!]

Vlastně je tu ještě jedna poměrně aktuální instance rabování: nepodmíněných 4,5 trilionu dolarů velkým korporacím – ale obyvatelstvu (včetně živnostníků) všehovšudy prd

[kralyk z abclinuxu]

Spíš je záázrak, že ty nepokoje nezačly mnohem dřív. Tohle někdo vytáhl, ještě, že máme ty internety..

RAW VIDEO: Officer Dustin Dillard's bodycam shows in-custody death of Tony Timpa

https://www.idnes.cz/zpravy/zahranicni/justine-damondova-smrt-policie-minneapolis.A170719_102339_zahranicni_amu?

Mně přišlo dost hrozný Death of Kelly Thomas.

Chápu vznik protestů, ale to co se děje teď, je hnus, nabalily se na to skupinky rabovačů, kteří si chtějí jen nakrást. To už fakt podporovat nelze.

No, IMO je to plynulá škála. Že se někdo naštve a prohodí šutr výlohou Louis Vuton celkem chápu. ^{_{(A popravdě majiteli to tak trochu škodolibě přeju, i když vim, že to je amorální. Prodávaj IMO předražený íčoviny se záporným přínosem společnosti.)}}

Ale proč někteří ničí / rabují drobné podnikatele, to fakt nechápu a přijde mi to jako hrozná blbost, zejména pokud to jsou černoští drobní podnikatelé... To je normální kriminalita...

[Radovan]

https://en.wikipedia.org/wiki/The_Killing_of_Randy_Webster

https://www.csfd.cz/film/15343-jak-zemrel-randy-webster/komentare/

Kdybys na ten film někde narazil, dej mi vědět. Docela bych se na to po letech podíval znovu.

[Seržant]

Že se někdo naštve a prohodí šutr výlohou Louis Vuton celkem chápu. (A popravdě majiteli to tak trochu škodolibě přeju...

Tak zrovna úplně stejným způsobem může někdo chápat, když někdo zmlátí černocha nebo se k němu chová odmítavě po tom, co ho naštvalo, jak černoši kradou, znásilňují, vraždí nebo prodávají drogy a ještě k tomu jim to prochází nebo jsou protežováni ve filmech, televizi a novinách. (o rasistických "outreach" programech snad ani radši nemluvě)

Přijde mi dost zvláštní od některých lidí očekávat, že se budou chovat jako roboti, 100% racionálně, bez emocí, bez chyb, že budou ignorovat svoji předchozí zkušenost... a jiné omlouvat, že je to "lidské", že "jen udělali chybu", že "za to může společnost" atd.

Ale proč někteří ničí / rabují drobné podnikatele, to fakt nechápu

Ono je celkem jedno, jestli je to velký nebo malý obchod. Přijde mi, že lidem nedocházejí souvislosti a nevidí pod slupku a představují si, že velká společnost má spoustu peněz, takže o nic nejde, nebo že se to zaplatí z pojistky. Zničený majetek - ať už patřil komukoli - je prostě zničený majetek a společnost jako celek tím o část svého bohatství přišla a někde se to nevyhnutelně projeví. Platí zákon zachování energie a hmoty.

Pojišťovna nemá nějaký vlastní kouzelný zdroj peněz. Pojišťovna funguje úplně jednoduše jako průtokový ohřívač - lidi si platí pojistky a když má někdo smůlu a měl pojistnou událost, tak se mu vyplatí peníze ze společného účtu. Pokud tedy bude hodně pojistných událostí (např. hodně protestů, nepokojů a rabování), tak se musí zvednout cena pojištění. To znamená, že lidem (úplně běžným nebo chudým, ne jen těm "zlým bohatým") podraží pojistné a oni přijdou o část peněz, které mohli dát na vzdělání dětem, kvalitnější jídlo, zdravotní péči nebo cokoli jiného.

Podobné je to u těch "velkých korporací". Jednak je tedy zcestný už samotný argument, že když je někdo bohatý, tak ho lze okrádat a o nic nejde. A jednak jde o to, že ty firmy jsou většinou akciové společnosti a jejich spolumajiteli jsou (obvykle skrze různé fondy nebo jinak nepřímo) zase obyčejní lidé. Když si i nějaký chudý nebo průměrný člověk spoří na důchod, tak většinou (nepřímo) investuje právě do těchto velkých firem. Takže za každou rozmlácenou výlohou v rámci "poklidných protestů" nebo vykradeným obchodem v rámci "občanské neposlušnosti" je třeba vidět tu objektivní materiální škodu, která vyústí v to, že nějaký (úplně běžný a nevinný) člověk bude mít nižší důchod.

Když protestující vypálí poštu nebo policejní stanici, tak to má opět dopad na úplně běžné lidi - budou muset platit vyšší daně nebo dostanou horší služby od státu.

[Fluttershy, yay!]

To je absolutní nepochopení kontextu.

Nejblíž, co se Češi mohli dostat k podobné situaci, byla tři století Habsburské vlády, rekatolizace atd. Odtud např. strhnutí onoho mariánské sloupu (jehož replika v Praze teď zase stojí), což zřejmě bylo rovněž „rabování“ a „ničení majetku“.

Ale ani po Bílé Hoře nešlo o otroctví, segregaci či každodenní lynčování. Ten rozdíl je o několik úrovní i přes to, kde se vzali např. „sedláci u Chlumce“.

Je potřeba si uvědomit, že ten majetek většinou ani nebyl té místní komunity a veřejné služby, ač segregace formálně skončila, neoliberálové (ať už z té, či oné strany) po desetiletí omezovali škrty – ne však policejní rozpočty. Ten kontrast mezi vybavením militarizovaných policejních jednotek a nemocničního personálu s ad-hoc ochrannými pomůckami mj. z pytlů na odpadky je až absurdní.

I think America must see that riots do not develop out of thin air. Certain conditions continue to exist in our society which must be condemned as vigorously as we condemn riots. But in the final analysis, a riot is the language of the unheard. And what is it that America has failed to hear? It has failed to hear that the plight of the Negro poor has worsened over the last few years. It has failed to hear that the promises of freedom and justice have not been met. And it has failed to hear that large segments of white society are more concerned about tranquility and the status quo than about justice, equality, and humanity. And so in a real sense our nation’s summers of riots are caused by our nation’s winters of delay. And as long as America postpones justice, we stand in the position of having these recurrences of violence and riots over and over again. Social justice and progress are the absolute guarantors of riot prevention.

—MLK

[Aleš Kapica]

. Odtud např. strhnutí onoho mariánské sloupu (jehož replika v Praze teď zase stojí), což zřejmě bylo rovněž „rabování“ a „ničení majetku“.

Jo bylo. Já na rozdíl od tebe tu story přímo z pera inciátora stržení, Franty Sauera, četl. Z jeho strany to byla jen do důsledků dotažená recese, kdy sebral partu pitomců, které nabulíkoval, že jde o symbol habsburské monarchie co se má strhnout a ta navzdory marnému odporu několika jedinců ten sloup shodila dolů.

[Bherzet]

(A popravdě majiteli to tak trochu škodolibě přeju, i když vim, že to je amorální. Prodávaj IMO předražený íčoviny se záporným přínosem společnosti.)

WTF?

[kralyk z abclinuxu]

Vzhledem k tomu co předvedl hlavní aktér – kterým není ten policajt, ale zesnulý černoch lze na 100% tvrdit, že si za to mohl sám!

Jsi psychopat. E. T. Seton se v hrobě obrací. Měl by ses léčit nebo alespoň nějak pořádně zamyslet.

Btw. tady je zákrok policie v Buffalo před 10 hodinami.

[Aleš Kapica]

Ten by se obracel leda tak z tebe, kdyby v tom hrobě byl. Jenže on se tak maximálně převaluje ve větru, jelikož byl rozptýlen nad Seton Village. Nevíš o něm totiž vůbec nic!

Viz hned první zákon Woodcrafterských Indiánů z r. 1903:

Don't rebel. Rebelliona gainst any decision of the Council is punishable by expulsion. Absolute obedience is always enforced.

Kdybys tomu snad náhodou nerozuměl, tak ti to přeložím:

Neremcej. Vzpoura proti jakémukoli rozhodnutí Sněmu se trestá vyhoštěním. Je vyžadovánana absolutní poslušnost.

A ty ostatní si už přečti a přelož sám. I zpitomělý levičák jako ty, by měl ten dokázat ten text pochopit dostatečně na to, aby si uvědomil, že to co se v USA děje právě teď, je s tímto "zákoníkem" v naprostém rozporu.

[kralyk z abclinuxu]

Neremcej. Vzpoura proti jakémukoli rozhodnutí Sněmu se trestá vyhoštěním. Je vyžadovánana absolutní poslušnost.

Aha a proto už tady 3 měsíce remcáš proti rouškám, žejo, pokrytče.

A ty ostatní si už přečti a přelož sám. I zpitomělý levičák jako ty, by měl ten dokázat ten text pochopit dostatečně na to, aby si uvědomil, že to co se v USA děje právě teď, je s tímto "zákoníkem" v naprostém rozporu.

Rabování je s ním v rozporu, ale stejnětak je s ním v rozporu i policejní brutalita.

[Aleš Kapica]

Neremcej. Vzpoura proti jakémukoli rozhodnutí Sněmu se trestá vyhoštěním. Je vyžadovánana absolutní poslušnost.

Aha a proto už tady 3 měsíce remcáš proti rouškám, žejo, pokrytče.

Rozhodnutí o povinném plošném nošení roušek nebylo výsledkem demokratické volby.

A ty ostatní si už přečti a přelož sám. I zpitomělý levičák jako ty, by měl ten dokázat ten text pochopit dostatečně na to, aby si uvědomil, že to co se v USA děje právě teď, je s tímto "zákoníkem" v naprostém rozporu.

Rabování je s ním v rozporu, ale stejnětak je s ním v rozporu i policejní brutalita.

Pokud jde o policejní brutalitu, zaměňujete důsledek za příčinu. Ale nebojte, ono jim brzy dojde, že je něco špatně, pokud do toho policajti hodí vidle, aby snad náhodou někoho zase nepřišlápli k smrti.

Opravdu nevím, jaký bude výsledek voleb – protože jenom naivkům jako vy nedochází, že jde o předvolební kampaň, vedenou poněkud netradičnímu prostředky – ale domnívám se, že tím Trump jen posílí, protože mu to nahážou všichni, co se bojí o kejháky.

[trekker.dk]

Rozhodnutí o povinném plošném nošení roušek nebylo výsledkem demokratické volby.

Stejně tak jakékoliv rozhodnutí Sněmu není výsledkem demokratické volby, pokrytče.

Ale nebojte, ono jim brzy dojde, že je něco špatně, pokud do toho policajti hodí vidle

V USA má vlastní zbraň dost lidí na to, aby úlohu pořádkové policie mohli v případě nouze převzít ve formě domobrany.

[Aleš Kapica]

Nepřekvapí, že zrovna vy nemáte o demokracii a demokratických postupech ani potuchy.

A pokud jde o USA.

Ano, podle zpráv z posledních měsíců se místo roušek v USA hojně nakupovaly zbraně. Že by je nakupovali hlavně ti, co teď demonstrují proti policejní brutalitě? Pochybuji. Řekl bych, že zanedlouho budou demonstranti s láskou vzpomínat na policajty, jak nekompromisně zaklekávali zfetované darebáky dřív, než došlo na střelbu.

[trekker.dk]

Nepřekvapí, že zrovna vy nemáte o demokracii a demokratických postupech ani potuchy.

Potuchy o demokratických postupech mám, s Radou a absolutní poslušností jste přišel vy.

[Fluttershy, yay!]

Ten Kapicův popis Rady navíc zní jako demokratický centralismus…

[Aleš Kapica]

Koukám že ses pěkně odkopal. Takhle blbě to překládá jen google translator. To vysvětluje proč motáš dohromady pojmy, aniž bys tušil co znamenají.

Kromě toho, je to origo Setonův text. Seton razil přímou demokracii od nejútlejšího věku. Dospělí a ti co nebyli ještě přijati do rozhodování sněmu neměli co kecat. Jenže to bys musel něco vědět také o tom, jak to fungovalo u irokézů a od koho Američané obšlehli svoji ústavu.

[Fluttershy, yay!]

To je pojetí historie jak Don Vondrušquijote de la Mafra.

[Blaazen]

Příloha:

• arrested.jpg (54906 bytů)

Jsem si nemoh pomoct

[Aleš Kapica]

Dobrá práce

[kralyk z abclinuxu]

Jenže to bys musel něco vědět také o tom, jak to fungovalo u irokézů a od koho Američané obšlehli svoji ústavu.

No, to se tak traduje, ale moc reálný základ to nemá. To jsou spíš takové zakladatelské mýty, něco Praotec Čech nebo podobně, reálně to takhle u těch Irokézů nefungovalo...

[Aleš Kapica]

Na to, že se to jen traduje existuje na tohle téma několik tlustých knih, z nichž některé má doma. Počínaje knihoy Lewise H. Morgana Společenské zřízení amerických Indiánů, která vyšla v češtině. Po knihu The Six Nations of New York, která obsahuje autentické informace o tom, jak to u Irokézů fungovalo v praxi. Byla moje první kniha, kterou jsem koupil před dvaceti lety přes web z USA. Na tohle téma jsem totiž hodlal psát diplomku, než mě ekonomické důvody dohnaly k tomu, abych se studiem definitivně seknul. Na webu se dá najít třeba také tento tlustospisek Iroquois Confederacy of Nations.

[kralyk z abclinuxu]

Pochybuji. Řekl bych, že zanedlouho budou demonstranti s láskou vzpomínat na policajty, jak nekompromisně zaklekávali zfetované darebáky dřív, než došlo na střelbu.

Ok, dejme tomu, že za tebou přijde sfetlej člověk, bude se pokoušet platit falešnou bankovkou a bude vypadat nebezpečně, chovat se neslušně, ale nebude nikomo přímo ohrožovat na životě a nebude mít zbraň. Logickej krok je zavolat policajty. Otázka: Budeš chtít, aby toho člověka policajti na místě ukšrtili? Prosím odpověď ano/ne.

[Radovan]

Opravdu byla falešná? Už to je oficiálně potvrzené nebo to jenom všichni dokola opakují po tom trafikantovi?

Mě se kdysi povedlo vyprat peněženku, zapomenutou v kapse džínsů, a ty peníze potom také vypadaly poněkud falešně. Normálně jsem s nimi platil a nikdo mě neškrtil

[Radovan]

Žádné rozhodnutí státní moci není výsledkem demokratické volby.

"Demokratické" je jenom rozhodování voličů, kdo tu státní moc bude provádět.

Osobně bych tomuhle systému ani demokracie neříkal, protože skutečná demokracie je pouze všeobecné referendum. Vše ostatní jsou pouze různé formy diktatury.

[kralyk z abclinuxu]

Rozhodnutí o povinném plošném nošení roušek nebylo výsledkem demokratické volby.

To sice nebylo, ale ještě v dubnu s tím jednoznačná většina lidí souhlasila [1]. (V květnu už jich bylo míň IIRC.)

No nicméně míra síly zásahu policie v Minneapolis taky nebyla výlsedkem demokratické volby...

[skajrajdr]

Hele to chces hajit svuj nesmyslny nazor jen abys neztratil tvar a nebo ses fakt takovej psychopat?

Uvedom si, ze ten policista je presne na tohle cviceny. To neni nejakej trouba co se chlubi na netu tim, ze by "zfetovanyho bezdaka v metru ale fakt jako sejmul, jako jo kluci, jen by si neco zacnul, hned bych ho sundal, smejda, by dopadnul jak ten Floyd, voe". Presne takove typy by policiste byt nemeli (a vetsinou nejsou). Jemu NESMI rupnout nervy, i kdyby si to ten nasilnik 10x zaslouzil, znasilnil predtim zenskou, pak ho poplival, dal mu facku a nechtel se nechat zatknout.

On ho ma zpacifikovat - klidne klecenim na krku, kdyz se pri tom neco stane, ma nasilnik smulu. Ale jak ho ma pod kontrolou, a to zcela prokazatelne za tech 8 minut co ho vrazdi mel, musi prestat. A nejhorsi na tom je, ze pokud ruplo v bedne jednomu, tak ho meli srovnat ty tri dalsi co tam jsou.

Jeste jednou polopaticky - to jestli si to zaslouzil nebo ne je uplne irelevantni. Tohle byla vrazda.

P.S.: Nepokoje tim samozrejme obhajovat nechci a nebudu. Ale ten nesmysl s tim, ze si za to mohl 100% sam je fakt stupidita hodna diskuzi na novinkach...

[billgates]

Snazit sa na nieco take vycvicit policajta, je rovnake, ako sa snazit vycvicit kona, aby nesral v stajni. Teoreticky to ide, ale v praxi je takeho jedinca tazko najst. Treba si uvedomit, ze vacsina policajtov maju IQ menavky a podla toho sa aj spravaju. Ak by im IQ kleslo o jeden bod, tak by uz aj oni asi len srali na ulici a erdzali. Policajta ide robit len ten absolutny ludsky odpad, dno spolocnosti, preto sa na ich vsetky akcie treba takto aj pozerat a pristupovat k nim. Ak si clovek toto uvedomi, nie je ziadnou ich cinnostou nikdy prekvapeny a vlastne vsetko odrazu dava zmysel.

US Court Says it’s Okay for Police Departments to Refuse to Hire Someone who is Too Smart

[Bherzet]

Tímhle přístupem ty kvalitní lidi odrazuješ od toho, aby k policii šli. Defaultně předpokládej, že jsou schopní a na úrovni. Až když někdo není, změň taktiku vyjednávání.

„Absolutnímu lidskému odpadu a dnu společnosti“ bych asi neměl chuť zavolat, že mi pod okny volá nějaký ženský hlas o pomoc a že než jsem tam stihl doběhnout, nikdo už tam nebyl a asi by to chtělo projet autem okolí. Ale já nějak chci věřit (a docela věřím tomu), že to smysl má.

[Fluttershy, yay!]

V americkém kontextu stačí mít dokončenou střední školu, řidičák a čistý trestní rejstřík. Leze tam leckdo, kdo na to má žaludek a stojí o jakés takés sociální zabezpečení – protože mnoho Američanů je chudých a armáda/policie jsou jedny z mála možností, jak se z toho… možná… dostat.

Co je náplní práce – zvláště americké – policie? Udržovat status quo: rasový a třídní.

Viz kauzu Christiana Coopera. To je společnost, o níž je řeč.

[Radovan]

Tak teď jsem se zasmál. Městská rada v Minneapolisu prý dospěla k závěru že místní policie je banda psychopatických rasistů mlátících negry na potkání (podle statistiky sedmkrát častěji než bílé), a je potřeba jí okamžitě reformovat, ve smyslu jejího rozpuštění a zajištění bezpečnosti na "komunitní úrovni".

Možná je k tomu inspiroval fakt, že ve čtvrtích kde je větší počet lidí legálně držících zbraně se nerabuje, zatímco je spousta vyrabovaných obchodů v "bezpečně odzbrojeném" centru, a patřících právě afroameričanům. Až na pár výjimek: https://www.youtube.com/watch?v=Pqrnwdq3grE

Jo, americká střední škola (high school) přibližně odpovídá druhému stupni základní školy a kousku gymnázia u nás. Naší střední škole tam říkají college. Víc jak třicet milionů obyvatel USA žije v bídě a přes sto milionů je existenčně závislých na "stravenkách", včetně celkem dobře placených povolání jako jsou vojáci. Celkově mi to připomíná kombinaci mlýna a zapálené cigarety.

[Fluttershy, yay!]

Zvídavého čtenáře by mohla zajímat kniha The End of Policing (e-book nyní zdarma i oficiálně; popř. některý z mnoha rozhovorů s autorem včetně těch aktuálních). Nejde ani o nic moc radikálního, jde o velmi praktickou sadu přístupů sotva na hraně police abolition (specificky transformative justice).

[Bherzet]

tl;dr: Argumenty ve stylu, že vloupačky se dějou z části proto, že lidé fetují, a kdyby se změnil přístup společnosti ke drogám, tak by možná zmizely vloupačky a nebyla by potřeba ta policie. Tj. navzdory senzačnímu titulku dochází akorát k závěru, že kdyby se snížila kriminalita, byla by policie méně potřeba (přičemž některé způsoby, jak snížit tu kriminalitu, jsou dost očividné). Odpad, nečíst.

[Fluttershy, yay!]

Kniha (1) shrnuje studie, které popisují situaci, (2) navrhuje řešení jako financování sociálních služeb namísto militarizace policie (kontext), což v USA samozřejmost není (viz např. podíl na rozpočtech ukázaný tady).

[xkucf03]

Argumenty ve stylu, že vloupačky se dějou z části proto, že lidé fetují, a kdyby se změnil přístup společnosti ke drogám, tak by možná zmizely vloupačky a nebyla by potřeba ta policie.

Už jednou jsem tu na tohle téma s Davidem diskutoval a psal jsem o tom, že drogy (včetně výroby a distribuce) by klidně mohly¹ být legální, což by snížilo jejich cenu a odbouralo různé mafiánské prvky, které jsou na ně nabalené.

Jenže to se mu nelíbí – asi proto, že by jeho kámoši tak jako tak skončili ve vězení, ale tentokrát by se už nemohli vymlouvat na tu „zlou společnost“.

_{[1] ve zkratce ten důvod je: pokud neškodíš ostatním, tak by tě stát neměl omezovat ani trestat, takže si klidně fetuj, když myslíš, že je to dobrý nápad, a klidně si drogy i prodávej, pokud řádně zaplatíš daně jako všichni ostatní, ale jakmile začneš ostatním škodit (např. krást nebo napadat lidi), tak budeš bez milosti dle platných zákonů potrestán a půjdeš do vězení, kde si bez drog klidně chcípni (to už je tvoje věc – máš svobodu, ale i odpovědnost za svoje konání)}

[Fluttershy, yay!]

Poněkolikáté odkážu efektivní řešení problémů s drogami v Portugalsku skrze dekriminalizaci a „harm reduction“.

Jenže tebe řešení společenských problémů – některé souvisejí i s legalizací v komerčním prostředí – nezajímá.

A to pomíjím, že v americkém kontextu jde ještě o rasově motivovanou War on Drugs.

[Bherzet]

Však já jsem taky pro legalizaci drog, přesně z těchto důvodů. Ale potřeba policie prostě nezmizí a ani nevidím problém v její existenci.

[Odin1918]

Presne. Primerenost zakroku proti kriminalnikovi necht je posouzena. Poulicni nepokoje a rabovani nesmi byt legitimizovane domnelym neopravnenym zakromem, o kterem ani nebylo rozhodnuto.

V USA mam dlouholeteho kamerada, ktery je potomkem chudeho imigranta z kuby, ktery ryl hubou v zemi. Jeho syn se ale vlastni cinorodosti vypracoval a dnes je v podstate bohaty. Nevim, co dotycny protestujici od statu chteji. Davky? Pozitivni diskriminaci? Rasove kvoty? Vsechno toto naopak ve spolecnosti zivi rasismus a segregaci.

[kralyk z abclinuxu]

Nevim, co dotycny protestujici od statu chteji. Davky? Pozitivni diskriminaci? Rasove kvoty? Vsechno toto naopak ve spolecnosti zivi rasismus a segregaci.

Protestující nejsou jeden člověk nakopírovaný X-krát. Je to spousta lidí s různýma názorama a motivacema. Někteří si jen chtějí ukrást televizi v obchodu. Jiní chtějí, aby policie nezabíjela bezdůvodně lidi a minimálně alespoň dodržovala svá vlastní pravidla.

[Miriam]

Celá ta záležitost dokazuje pouze to, kam to dotáhla přehnaná hyperkorektnost v USA. A výsledkem bude pouze to, že to nažene další voliče do Trumpovy náruče. Bílé i černé.

Myslím, že Trump jako americký prezident selhal... nezahájil včas deportace.

[Ruža Becelin]

Hlavní problém je, ze jistá individua si najdou jakoukoli podobnou příležitost (čímž nechci vraždu Floyda jakkoli zlehčovat), aby se obohatila rabováním nebo aspoň zničila cizí majetek.

A to platí kdekoli, nejenom v USA, ale i v zapadni Evropě nebo ČR.

[Bherzet]

Rabování a ničení majetku taky nechápu. Přemýšlel jsem nad tím, jestli to nemůže být nějaká davová psychóza, ale upřímně nevím, co si o tom myslet.

Druhá věc je, jak se tam chová policie i vůči pokojným demonstrantům a reportérům. Jen tak z prdele po nich stříkají pepřák a střílí gumové projektily (klidně i do lidí, kteří se jen koukají z oken nebo zápraží domů). Viděl jsem, jak policista hodil ustupujícího reportéra do ohně (naštěstí se z něj vykutálel rychleji než mu začalo hořet oblečení, takže se mu snad nic moc nestalo). Existuje bezpočet záznamů, kde vyhledávají konflikty. Silou vrazí do ustupujícího člověka tak, že si rozbije hlavu o obrubník, pronásledují lidi s obušky a bijou do nich na zemi.

To není „crowd control“. Jistě, že když někde zblázněný dav hází dlažební kostky a rabuje obchody, tak je policie musí vytlačit. Ale viděl jsem opravdu bezpočet videí, která ukazují něco poněkud jiného.

Proto jsem zvědavý, jak se to bude dál vyvíjet. Sám někde pokojně demonstrovat a být svědkem nebo obětí takového bezdůvodného násilí ze strany policie, nevím, jak bych se zachoval.

[Bherzet]

Oprava dvojznačnosti:

s/pronásledují lidi s obušky/s obušky v ruce pronásledují lidi doprostřed davu/

[j]

Videl sem par fotek z tech aktualnich mejdanu a muzu ti rict, ze kdyz se podivas na par starsich filmu a srovnas to, tak ta jejich garda === kukluxklan v maskacich. A vopicajti nemlich to samy.

Ne ze by to tady bylo jiny, nedelej si iluze.

---

Dete s tim guuglem dopice!

[Bherzet]

Pokud neexistuje důvod myslet si něco jiného, nejedná se o iluze. Když tu policisté v neoznačeném voze bezdůvodně vyblokovali vůz jedoucí za nimi a jeden z nich vyběhl se zbraní v ruce, byl z toho celostátní skandál. V americké perpektivě nemyslitelné, tam by se nad tím nikdo nepozastavil.

Rasismus si taky nemám důvod myslet, že by byl horší.

[Seržant]

Bohužel ta "jistá individua" se do velké míry překrývají s tou skupinou, za jejíž práva se protestuje, což jaksi podrývá legitimitu celé té akce.

Představme si, že většinová společnost protestující vyslyší a nějak zařídí, aby k podobným nehodám nedocházelo. Přestanou tedy umírat černoši při policejním zatýkání.

Co se ale změní na straně černochů? Přestanou páchat trestnou činnost? Nebo se změní jen to, že budou zatčeni v rukavičkách a skončí ve vězení? (které za ně platí daňoví poplatníci - stejně jako jim platí policii a soudy)

V horším případě dojde k tomu, že se policajt bude bát černocha zatýkat i v těch rukavičkách a bude radši dělat, že danou trestnou činnost nevidí. Vezmou to černoši jako krok k usmíření a přestanou krást a jinak škodit? Nebo to budou brát spíš jako naši slabost a využijí toho k tomu, že budou beztrestně páchat více zločinů?

A jak se na to má dívat průměrný většinový volič, který poctivě chodí do práce, platí daně, dodržuje zákony a nerabuje? Bude pozorovat černochy, kteří si ledasco nakradli a prošlo jim to, černochy, kteří jsou protežování ve filmech, v televizi, v novinách, pro které se dělají různé programy "pozitivní" diskriminace... a kteří ale stejně stále kradou a znásilňují, fetují atd. Je úplně jedno, jestli já nebo ty uvažujeme podobně jako průměrný americký volič - na nás nezáleží - ale o výsledku voleb a podobě americké společnosti rozhoduje právě ten průměrný Joe Sixpack. A pokud Joe bude mít pocit nespravedlnosti, tak bude volit politiky, kteří si na černé došlápnou a udělají pořádek, a on sám černým nic neodpustí a nebude se k nim chovat vlídně, bude tolerovat či podporovat policejní násilí na černých nebo se k policii sám přihlásí.

[Odin1918]

Jakekoliv statem organizovane, financovane a vynucovane nadrzovani jakekoliv mensine je rodnou pudou pro rasismus a segregaci! Zakrok necht je posouzen a majetky danovych poplatniku a firem tvrde chraneny

[Fluttershy, yay!]

To je překvapivě trefný popis… typicky oligarchie.

[Odin1918]

Ne, to je vlada zakona a pravni stat trubko. Jak by se ti libilo, kdybych si se svymi kamarady prisel udelat party k tobe domu? Asi moc ne, co? Zkus se do toho vzit a treba to pochopis rakovino.

[Fluttershy, yay!]

Tyhle „party“ znám.

[Odin1918]

Tak libilo? Az by k tobe par protestujicich prislo, byl bys prvni, kdo bude volat policii, protoze zbrani se bojis a sam zadnou nemas

[Fluttershy, yay!]

A to víš zase jak? Počkat, nevíš.

[Odin1918]

Ale vim ty upiskany asteniku

[bsdbest]

to musi byt Cina

[trekker.dk]

Skoro se až nechce věřit, že vzlétly z téhle země.

Překvapení, u policie pracují sadisti a psychopati, kteří ví, že jim všechno projde.

Tohle by mohlo přerůst v občanskou válku

Tak určitě... na jedné straně vyzbrojená armáda a policie, na druhé protestující, kteří se nevzmůžou víc než na transparenty.

[Bherzet]

A car runs over a group of cops

"A protester shot my sister. It was not the police. Because of you, I lost my sister."

Latin kings on the south side of Chicago getting shot at by looters for protecting their neighborhood

Sociopath threatens protesters in Upland, California with a semi-automatic weapon

George Floyd protesters attempt to disrupt an Ohio Pizzeria; owners protect with firearms

[Bherzet]

Far-Right Extremists Are Hoping to Turn the George Floyd Protests Into a New Civil War

[Bherzet]

This is quickly spiraling out of control...

They sent NYPD flying in the air

Man on bike inciting violence. Yells “Start shooting”. Quickly taken down by police. WPB, FL

Gun sales surge 80%, division between right and left at all time high... This is a disaster waiting to happen

[Bherzet]

Looters Use Telescopic Forklift To Break Into Best Buy

[Blaazen]

Ale že ten dotyčný přestal natáčet, když probourali tu výlohu. Asi to vypnul a šel "nakupovat".

[Bherzet]

Retired Police Captain Shot Dead In St. Louis While Trying To Protect Store Against Looters

[trekker.dk]

Najděte si ve slovníku definici občanské války. Loupežná přepadení nejsou občanská válka, "doufáme v občanskou válku" není občanská válka a nutná obrana není občanská válka.

[Bherzet]

protestující, kteří se nevzmůžou víc než na transparenty

[trekker.dk]

A na základě toho tedy vyvozujete, že z toho bude občanská válka? Jo pardon, "mohlo by", univerzální pravdivý výrok.

[Bherzet]

Nevím, jak to nazvat jinak. O pouhé demonstrace už dávno nejde. Nepokoje jsou taky slabé slovo. Do občanské války tak, jak ji známe třeba z Jugoslávie, to má zatím taky daleko. To rasové, třídní a politické pnutí je ale velmi výrazné.

Myslím si, že smrt Floyda byl katalyzátor, který vyeskaloval dlouho trvající a pandemií ještě prohloubené sociální problémy. Moje predikce je, že současné šarvátky se sice asi nejprve podaří násilně potlačit, ale protože jsou příliš závažné než aby se na ně během pár týdnů zapomnělo, budou se vracet zpátky jako bumerang. Jestli ten trend bude mít sestupnou nebo vzestupnou tendenci je „million dollar question“ a odhadnout si to netroufám.

Za téhle situace se ostře zvyšuje pravděpodobnost, že někdo spáchá brutální rasově motivovanou vraždu a pak to může velmi rychle vygradovat do nehezkých rozměrů.

Also related: Why Unrest and Political Violence Is Predicted to Peak in the 2020s (2016 November 17)

[trekker.dk]

Also related: Why Unrest and Political Violence Is Predicted to Peak in the 2020s (2016 November 17)

Předpověď může udělat kdokoliv a ohledně čehokoliv. A když se někdo náhodou trefí, tak je slavný a lidi ho citují, i přestože si prostě tipnul a ono to vyšlo.

[vencour]

Taky mi přijde, že obecně se spousta lidí netrefila a jen těch pár štastných má popularitu.

[jiwopene]

PS: Tak co, kdo sledoval start a průběh letu? A co na to říkáte?

https://youtu.be/won6Ap9JnVw?t=15338

[Max]

Nejsi první. Odpověď máš výše #28, nebo i v blogu je link s vysvětlením.
Zdar Max

[ehmmm]

:)

Ale houby, je to stejné jako v mém oblíbeném vtipu o přistání na Měsíci. Prý to tenkrát točil Kubrick. (Akorát ten prevít trval na skutečných exteriérech.)

[vencour]

Co máte proti umění nejlepších pilotů? Co by nedokázali přistát, usměrnit nějaký vektor tak, aby nedošlo ani k minimálním škodám?
Ano, pro neználky to může vypadat jak magie, ale oni by to dali možná tak v 80% (nebo i víc?) případů tak bezpečně, jak na Měsíci přistáli.

[Michal Kolesa]

Zajímá mě ,jak se ženy myjí vskanfandru. Zda se proplachují vodou na jednom konci a vytečet to z nohavic

[Blaazen]

Hele, Kolesa píše ze záhrobí! Že by se šlo spojit s oním světem pomocí 5G sítě?

[Odin1918]

Nebyt Wernher von Braun, americane by se v zivote nedostali na mesic.

[Gréta]

Tak jsem myslela, že Braun byl jakože snědší a že to má dokazovat, že na černých životech taky záleží. Ale jak tak na to koukám, tak to byl běloch a ještě k tomu němec, hele To má jako dokazovat co?

[TechnikTom]

Byl to suchar - když se ho na tiskovce před startem Apolla 11 v narážce na jeho válečné V-2 zeptal novinář:

„Doktore von Braune, jak velká je pravděpodobnost, že vypuštěný Saturn 5 nedopadne na Londýn?“

Tak to nerozdýchal a beze slova odešel.

[j]

Vtipný, škoda že je to lež.

[PepaSFI]

i kdyby to lež nebyla, co odpovědět na blbou otázku pitomci? Snad možná něco jako "já se trefím přesně tam co chci a to rychlý co se blíží zleva, je moje bouchací pravačka"

[j]

Neragovat jak chtějí, to se tu ale troubové na ábíčku ještě nezlvádli naučit. Mohl se třeba rozpovídat, jak je mise naplánovaná tak aby raketa spadla do moře a ne na pevninu.

[Blaazen]

Nebo mohl říct, že mít za války tuhle techniku, tak by lítaly kusy židů z Londýna až do Calais.

[TechnikTom]

Tak psali o tom v srpnovém Time z roku 1969. Ale pravda, že už jako o tradované historce. Nicméně Von Braun byl na otázky ke své nacistické minulosti dost citlivý a asi věděl proč. A obyčejní lidé nezapomínají na tyhle týpky, kteří neváhají sloužit tomu, kdo je právě u moci a neohlížejí se na nic krom svých osobních ambicí. Proto v Anglii uváděli jeho životopisný film pod názvem "Wernher von Braun" místo původního "I Aim at the Stars", protože lidi si to upravili na: " I Aim at the Stars (But Sometimes I Hit London) "

v narážce na jeho nacistickou a SS minulost v Peenemünde.

[Odin1918]

Je mi spatne z toho rabovani a z kolibace a jemu podobnych. Proste policajt zaklekl kriminalnika, ten to nerozdychal a natahl backory. Primerenost zakroku a pripadnou vinu policajta necht je posouzena dle platnych zakonu. I kdyby byl vinen, nedava to nikomu zadne zakonne a moralni pravo k nazyvani bile majority rasisty a rabovani majetku. Z meho pohledu se jedna o zneuziti smrti onoho kriminalnika k dalsimu kriminalnimu jednani. Kazdy jiz nyni musi pochopit nutnost mit zbran k obrane sveho majetku a zivota sve rodiny!

[Fluttershy, yay!]

Kazdy jiz nyni musi pochopit nutnost mit zbran k obrane sveho majetku a zivota sve rodiny!

Proto se NRA jala v reakci na Black Panthers hlásat nutnost regulace držení zbraní.

Ale to jsi asi nemyslel, ty neonacistický syfle.

[Odin1918]

A hele, astenicky Che Guevara se nam rozohnil. Co je spatneho na tom branit si svuj zivot a majetek? Vazne. To jako sam podekujes tomu, kdo ti prijde pomoci od tveho majetku? Prijde mi, ze uz jsi totalne vymyty davide. Je mi lito tvych rodicu. Urcite je mrzi, co se z tebe stalo za mrzaka.

[Fluttershy, yay!]

The life of a single human being is worth a million times more than all the property of the richest man on earth.

—Che Guevara

The whole proletariat must be armed at once with muskets, rifles, cannon and ammunition, and the revival of the old-style citizens’ militia, directed against the workers, must be opposed. Where the formation of this militia cannot be prevented, the workers must try to organize themselves independently as a proletarian guard, with elected leaders and with their own elected general staff; they must try to place themselves not under the orders of the state authority but of the revolutionary local councils set up by the workers. Where the workers are employed by the state, they must arm and organize themselves into special corps with elected leaders, or as a part of the proletarian guard. Under no pretext should arms and ammunition be surrendered; any attempt to disarm the workers must be frustrated, by force if necessary.

—Karl Marx

[Odin1918]

Pekne umis citovat sve ideologicke vzory. Jinak omyl davide. Lidsky zivot ma cenu stejne jako vsechno.

[kralyk z abclinuxu]

Lidsky zivot ma cenu stejne jako vsechno.

Ale to přece nikdo nerozporuje. Spor je pouze v tom, jaká ta cena má být, kde ty tvrdíš, že tvůj má vysokou, zatímco život ostatních nízkou, což mnoha lidem vadí (celkem pochopitelně).

[Odin1918]

Cena zivota (ostatne vseho) je dana stretem nabidky a poptavky. Tedy tim, kolik v danem okamziku je ochoten dotycny clovek za zivot zaplatit. Samozrejme toto se meni v case a je to silne subjektivni. Cena kolibacova zivota je pro mne nulova. Naopak prijdu o ideologickeho nepritele, pokud dotycny zemre na rakovinu.

Pokud nekdo rabuje muj majetek a pripadne ohrozuje mou rodinu, musi pocitat s tvrdym odporem. Jeho zivot pro mne cenu nema. Tak by to melo byt i v pripade protestujicich. Je nepripustne, aby dav likvidoval cizi majetky pri zneuziti smrti nejakeho kriminalnika. Doufam, ze policie vuci temto kriminalnikum tvrde zasahne, jelikoz pokud sahnou na cizi majetek, jejich zivot nema mit cenu.

[kralyk z abclinuxu]

Klidně si cenu davkola nebo jakejchkoli jinejch lidí stanov na nulu nebo zápornou hodnotu, ale pro společnost to není vůbec nijak závazné. Úplně klidně může tu cenu stanovit o dost výš, což se vzhledem k tomu, že stále ještě máme relativně civilizovanou společnost, pravděpodobně stane a ty s tim naštěstí nemůžeš celkem nic moc dělat

[JiK]

The life of a single human being is worth a million times more than all the property of the richest man on earth.

—Che Guevara

A ten soudruh Che to rikal i kdyz tem, ktere osobne popravoval za to, ze s nim nesouhasili, zastrelenim do tyla, po sovetskem zpusobu?

[Radovan]

Ne, těm dezertérům, chyceným při rabování a znásilňování, tohle říkat nemělo smysl. Mnohem lépe jim to vysvětlila rána z Coltu 1911. A zcela jistě s tím nesouhlasili.

[JiK]

The life of a single human being is worth a million times more than all the property of the richest man on earth.

—Che Guevara

A revolutionary must become a cold killing machine motivated by pure hate.

—Che Guevara

Ajajaj, premyslim, jesli te nemam udat nejakym elfum a dobroserum pro cenzuru internetu, pripadne policii CR, ze tu verejne siris tuhletu predsudecnou nenavist a ruzne zakazane ideologie, lide jako vy preci tak moc stojite o ideopolicii a kadrovaky a potlaceni svobody slova, tak by sis mohl vyzrat svou vlastni medicinu...

ale rikam si, ze je to pod mou uroven, precijen, orel much nelapá...

[PepaSFI]

bohužel, to je to čeho se nedočkáme. Ten policajt je dopředu na objednávku odsouzen k smrti. Je jedno kolik dostane, jak se octne v base, bude to špatný. A že dostane hodně je jasný, nikdo si nedovolí dát mírný trest nebo dokonce osvobodit ikdyby se zjistilo že ten zakleknutej by umřel i doma u televize protože měl od drog pajšl na hadry a že měl v kapse dva atomový reaktory a mačetu s nabodnutým koťátkem. Tady jsme to v menším viděli na případu silničního "piráta" Laciny který dostal basu za to že "my mu sice vůbec nic nemůžem dokázat. experti blábolí nesmysly, důkazy nejsou ale s takovýma musíme zatočit".Trest jak kdyby s pistolí přepad poštu za možná by se dalo říct nesprávné předjíždění ale spíš ani to. Když si to média objednaly.... Pak ho sice pustili v tichosti mnohem dřív než původně měli ale co už potom.

[Odin1918]

Ja stale doufam a verim americkemu systemu. Obvineni z vrazdy je mozna k uklidneni davu, ale pokud ten clovek dostane exemplarni trest pro uklidneni protestujicich, bude to nechutne divadlo. Potom teprve budou na miste protesty.

[vencour]

Netvrdim, že jsem v obraze ... Hodní a milí lidé se většinou neperou s policisty a nemají v těle drogy - to mi zní tak nějak důvěryhodně? Oprávněně?
Blog na iDnesu, např.

Podle pitevní zprávy se však ukázalo že pan Floyd trpěl několika chorobami, mimo jiné vážnou arteriosklerózou a měl vysoký krevní tlak. Když k tomu připočteme, že měl v těle nalezeny látky jako syntetický opioid proti bolesti fentanyl a také metamfetamin, dále bohužel fakt, že jeden z policistů neměl dost rozumu, aby mu neklečel zbytečně na krku, není výsledek celé situace zase až tak překvapující.

Takže mi přijde, že se lidi chtějí hlavně vyřádit, ne změnit nebo přijmout odpovědnost za svůj životní styl.

[Fluttershy, yay!]

Lynčování je skutečně „životní styl“.

[vencour]

Já to komentuju tim způsobem proto, že lidi nezajímá, co se vlastně stalo. I když nebyl nevinný, stejně se tvrdí, že chyba je straně autorit.

[Fluttershy, yay!]

Tobě přijde normální, aby příslušník policie (státní monopol na násilí) někoho zavraždil tím, že mu bude přes osm minut klečet na krku?

No, běžné to v USA je. Dnes aspoň o některých případech (letos např. vražda Ahmauda Arberyho) víme díky kamerám (policistů, celé populace) a sociálním sítím.

A jak na to reaguje ten státní monopol na násilí? Dalším násilím, provokatéry, použitím chemických zbraní, tajnou policií/paramilicemi, výhrůžkami nasazením armády (která naštěstí odmítla, raději vraždí civilisty v zahraničí) a pokusem označit antifašismus za terorismus (nelegálně).

[Blaazen]

Aha, takže oni si Floyda podali za to, že jim ten jejich monopol na násilí narušil.

Floyd had landed five years behind bars in 2009 for an assault and robbery two years earlier, and before that, had been convicted of charges ranging from theft with a firearm to drugs, the Daily Mail reported.

[Fluttershy, yay!]

Tobě přijde normální, aby příslušník policie (státní monopol na násilí) někoho zavraždil tím, že mu bude přes osm minut klečet na krku?

[Blaazen]

Mně přijde normální, že policie je důraznější a opatrnější, když zatýká recidivistu a taky dokážou dobře odhadnout, jestli je dotyčný pod vlivem drog.
A představa, že ho těsně před otevřenýma dveřma policejního auta schválně povalili na zem, zatímco dotyčný se vůbec nevzpouzel a chtěl ochotně nastoupit dovnitř, to spíš uvěřím tý o Karkulce.

[Fluttershy, yay!]

Tobě přijde normální, aby příslušník policie (státní monopol na násilí) někoho zavraždil tím, že mu bude přes osm minut klečet na krku?

[Blaazen]

O tom, jestli to byla vražda, rozhodne nezávislý (snad) soud, ne diskutující na internetu.

BTW, teď jsem viděl na ČT 168 hodin. O stížnostech na policistu se zmínili, o kriminální minulosti Floyda ani slovo.

[Fluttershy, yay!]

Jak to, že byly potřeba masivní protesty, aby vůbec padlo obvinění a k soudu se to potenciálně dostalo? Protože jinak si o řešení těchto kauz fakticky rozhoduje policie sama.

Že jde o vraždu, je vcelku zjevné. Tvrdit opak je někde na úrovni „desetkrát zády naběhl na nůž“. Tvrdit, že vražda je výhradně záležitostí justice, je sémantický argument, který neobstojí při běžném použití jazyka: tedy např. vražda svatého Václava (který možná ani nežil).

[Blaazen]

Z části je to manipulace. Kdyby v médiích psali "zdrogovaný recidivista zemřel při zatýkání", nepůjde do ulic nikdo. Když napíšou "policista zavraždil Něžného obra, srdečného člověka a dobrého otce", tak se holt protestuje.

@ Že jde o vraždu, je vcelku zjevné.

U vraždy by měl být prokázán úmysl. I když na něm dlouho klečel, neměl úmysl ho zabít.

[Fluttershy, yay!]

Kdyby v médiích psali "zdrogovaný recidivista zemřel při zatýkání", nepůjde do ulic nikdo.

Média mají dlouhou historii inventing reality, resp. manufacturing consent, ale v roce 2020, kdy už nemají monopol na šíření informací, to přestává být udržitelné.

V této diskuzi i tak pozoruji řadu memů z produkce Faux News, ti se snaží usilovně.

U vraždy by měl být prokázán úmysl. I když na něm dlouho klečel, neměl úmysl ho zabít.

Je normální přes osm minut někomu klečet na krku, přestože si stěžuje, že nemůže dýchat?

[Bherzet]

Některé titulky v médiích byly dementní a manipulativní (ostatně jako vždy), to máš pravdu. Nicméně ten tvůj titulek je manipulativní taky: zamlčuje příčinu smrti, která je zde zásadní.

[Seržant]

letos např. vražda Ahmauda Arberyho

Co se nám to tu snažíš namluvit? Ten černoch napadl člověka - chtěl mu sebrat jeho legálně drženou zbraň. Kdyby nedělal problémy a počkal v klidu na příjezd policie, tak mohl být dnes naživu. A pokud byl nevinný a opravdu se šel jen proběhnout, tak by byl i na svobodě. Byla to jeho volba.

[vencour]

Chlapa přes 100 kilo, kterej se nechtěl nechat odvést na zaprotokolování a radši se válel po zemi ... s metamfetaminem v krvi ... čili ještě posilněnej.

Hele, Kolibáči, vnímáš tyhle fakta? O to mi jde, jestli v tom je chyba, v příčině. Jak tam píše Prouza, někdo chce podvádět, je tak drzej, že se nechá chytit, ne, že by vrátil cigarety a vzal si falešný peníze, místo toho zvýšil sázky ... a prohrál. Nebo ze sebe udělal obětního beránka.

Takže se zase řeší něco zástupného ... ne že lidi nemaj dětství, jsou nevychovaný, končí na ulici v gangu, berou drogy ... a už se z toho nevyhrabou.

[Fluttershy, yay!]

Chlapa přes 100 kilo, kterej se nechtěl nechat odvést na zaprotokolování a radši se válel po zemi ... s metamfetaminem v krvi ... čili ještě posilněnej.

Nezájem. Když v New Yorku fízli stávkovali (neprovozovali „proactive policing“), hlášení kriminality klesla. Takže ať se jdou vycpat.

že lidi nemaj dětství, jsou nevychovaný, končí na ulici v gangu, berou drogy

Proč myslíš, že se tohle děje ve státech s historií otrokářství a segregace? Přečti si něco o „redlining“.

[vencour]

Nezájem.

Jsme ve sporu v příčině nebo následku?

[Fluttershy, yay!]

Realita je taková, že policajt opět někoho zavraždil. Už to je alarmující (srovnání mezi různými státy, např. Island).

Nehodlám se pitvat v detailech nějakého konkrétního případu, to by mělo být na justici. Jenže k justici se to obvykle vůbec nedostane, protože fízli to tutlaj.

Moje agenda zde je (1) kontrastovat to s reakcí na protesty a (2) uvést to do společenského kontextu, který si tady skoro nikdo neuvědomuje.

Protože k sesmolení zápisku se asi v dohledné době nedostanu, ještě tu nechám několik odkazů…

Oč jde aktivistům? Viz Campaign Zero.

Proč je vůbec americká policie tak militarizovaná? Viz jednak Foucault's Boomerang, jednak např. knihy (potažmo související rozhovory s autory) So You Want to Talk About Race, Bring the War Home a Rise of the Warrior Cop.

[vencour]

Hezký, dík za delší post.

[Radovan]

Možná mi v tom rachotu unikla informace, ale už někdo potvrdil že ta dvacka byla skutečně falešná?

Protože zatím vidím pouze vraždu na základě falešného obvinění vymyšleného nějakým prodavačem v trafice, což je podle mě povolání na úrovni drogového dealera!

Plus policií zfalšovaná pitevní zpráva.

[Bherzet]

A vnímáš, že prostě klečet mu osm minut na krku bylo úplně zbytečné? Kdyby už nic jiného, mohl ten tlak aspoň uvolnit a znovu zvýšit při odporu. Já fakt nechápu tu utkvělou představu, že udržet na zemi ve čtyřech lidech jednoho chlapa je tak velký problém, že je prostě lepší ho preventivně udusit.

[vencour]

Řekněme, že je to podezřelé. S tím souhlasím.
Přesto jsem měl dojem, že protivit se Policii v USA je riziko.
Pardon, nemám tolik podkladů k diskusi.
Děkuji za Vaše odpovědi a názory.

[Bherzet]

Přijít v USA do kontaktu s policií je riziko samo o sobě. Já ty záběry nezkoumal vteřinu po vteřině a nehodnotím a nezpochybňuji, že možná kladl odpor a možná bylo použití síly na místě. Kritizuji klečení na krku velkou vahou a po dlouhou dobu, ke kterému nevidím důvod, ať už byl předchozí scénář jakýkoliv.

Kdyby to byl šílenec se zbraní v ruce a nebyli na něj čtyři policisté, ale jen jeden jediný a ten by ho musel zuby nehty udržet, aby nedosáhl na pistoli válející se metr od nich, tak jasně, proč ne. Ale tady by se ani nic nestalo, kdyby jim utekl. Byla to prostě úplně zbytečná smrt a úplně nepřiměřený zákrok.

[vencour]

Teda pánové, bylo to u zbraní SS a v Purpurových řekách, "účinkovali" tam lidi takhle posilnění metamfetaminem (aha, ověřit rozdíl amfetamin a metafetamin, no ... wikipedie v nich až tak nerozlišuje).
Já se nedivim, že se těžko diskutuje při takovéhle úrovni vnímání a vzdělanosti.
Mně přijde, že ty čtyři s tim obrem mohli mít pořád dost práce. I ve čtyřech.

[Radovan]

Bitva u Slivice, 11.-12. 5. 1945.

Ale tohle není ten případ. Stále postrádám informaci jestli opravdu platil padělanou bankovkou, nebo to bylo křivé obvinění.

[vencour]

Měl v krvi metamfetaminy. To snad potvrzený je?
To by mne taky zajímalo, jestli ji mají zajištěnou, tu bankovku.

[Radovan]

Potvrzené to je zfalšovanou policejní pitvou, tu druhou jsem nestudoval.

Nějakou tabletku do sebe mohl klidně hodit, to je tam normální. Američtí vojenští piloti tabletky fasují a zobou povinně.

[vencour]

I tak dík za komentář.
Když je normální tohle, tak je třeba normální i něco jiného.
Ti organizovaní by to měli zobat pod dohledem, tak trochu rozdíl.

[Radovan]

Ještě to mohly být nějaké léky, které mu předepsal psychiatr, ke kterému jako každý normální Američan pravidelně dochází

V kombinaci s alkoholem...

Ale to ber spíš jako vtip.

[vencour]

Jo hele, ani tohle neni sranda, Rowlingová měla kecy proti našim klecovým lůžkám, ale díky nim nemusej sestřičky do pacientů/dětí cpát tolik sraček, aby se zklidnily a neublížily si.
Ano, taky jsem zahlídl, že snad každej druhej Američan má svýho léčitele lidské duše. A že v ČR je ca 1/3 zralá na pomoc psychiatra. A na všechno nejsou prášky, případně to jsou jen nějaký šidítka, co to jen utlumujou a neřešej dlouhodobě.
Jak to vidim, jednou se k tomu budu muset, brzo asi, dostat, abych byl aspoň trochu v obraze. Teď se spíš snažim dohánět jiný resty, co mam kolem sebe.

[Bherzet]

Já se nedivim, že se těžko diskutuje při takovéhle úrovni vnímání a vzdělanosti.

Jo vole, nezapomeň ještě vytáhnout Pepka námořníka, ten by po exnutí plechovky špenátu taky neměl nejmenší problém přitisknutej na asfalt zvednout čtyři sta kilo živý váhy a vzít roha.

[vencour]

Jestli byli policajtama Asiati nebo co tak ti bývají drobnější postavy ...
Pouze hledám argumenty a fakta. Tady. Nesoudím.

[trekker.dk]

Pouze hledám argumenty a fakta.

Tak to byste se místo spekulací mohl třeba podívat na videozáznam. Určitě se tady bude válet nějaký odkaz.

[kralyk z abclinuxu]

Primerenost zakroku a pripadnou vinu policajta necht je posouzena dle platnych zakonu.

A v tom je právě ten problém - tohle se už zřejmě mnoho let neděje. Prostě policajt někde naprosto blatantně nepřiměřeně zabije nějakýho chudáka (ty případy jsou s černochy i bělochy) a následně se mu nestane vůbec nic nebo dostane jen nějakej směšně nízkej trest, protože šéfové policie a vůbec celej ten systém ty lidi kreje. Velká část protestujících (nemluvim o rabujících) chce přesně tohle - aby přiměřenost zákroku byla posouzena podle platných zákonů.

[Jendа]

Fascinuje mě, jak na to lidi furt skáčou. Po fiasku s ChronicPainem si Kapica nechal napsat Kapica'sRevengeBota, který měl ukázat, že ostatní jsou ještě hloupější a dokážou skočit na ještě větší kraviny než repostování náhodných vět z Odinovy historie, a nasadil ho místo sebe. Bot je krmen nesmysly z různých oblastí (epidemiologie, …), neustále je opakuje, a jak je vidět, stále to většina lidí neprokoukla.

[Fluttershy, yay!]

Na druhé straně, reakce na komentář nemusí být určená předřečníkovi, nýbrž ostatním čtenářům diskuze.

[Max]

To jsem nějak minul, díky za link :D.
Zdar Max

[trekker.dk]

Chcete říct, že v těch postech AK ze sebe nedělá blbce sám, ale má na to stroj?

[Jendа]

Stroj dělá blbce ze všech ostatních, co na něj pořád reagují.

[Aleš Kapica]

Z blbců blbce dělat netřeba.

[trekker.dk]

Ok

si Kapica nechal napsat Kapica'sRevengeBota

Citation needed.

[kralyk z abclinuxu]

Já si teda taky nemyslim, že by to byl bot. Viz tento legendární kotyzův výrok...

[Jendа]

Žádný člověk nemůže být tak blbý, aby matlal ty informace o rouškách, epidemii a dalších věcech tak, jako tady AK, ani tak vytrvalý, aby tohle dělal jako trolling.

[Jendа]

Teda, doufám.

[Bystroushaak]

Nice. Nemáme pro to už nějaké jméno? Ala argument ad-botum?

[Bherzet]

Máme. Turingův test. Ale vzhledem k tomu, že Kapica jím sám neprošel, je klidně možné, že ty komentáře myslí vážně.

[Marian]

Tak snad už i ti pomalejší pochopí, že multikulturalismus nefunguje. A ti, kteří nás ohlupovali ve školách a v televizi pohádkami o tom úžasném americkém melting-potu, se teď snad stydí a snad se trochu zamyslí nad tím, jaké zlo napáchali.

Nefunguje to ani v té slavné Americe, tak už se na to prosím vykašlete. Je to jen fikce z hollywoodských filmů a mylná představa lidí bez zkušeností.

[kralyk z abclinuxu]

S dovolením, já bych měl technickou otázku. Nechci teď rozporovat, jestli multikulturalisums funguje nebo nefunguje. Jen by mě zajímalo, jak by bylo možné v globalizovaném světě, kde obrovské množství lidí 24 hodin denně cestuje sem a tam přes celou planetu, nemít multikulturalismus. Doslova si můžu během snad jen nekolika minut koupit letenku na většinu míst světa. A výměna informací funguje ještě rychleji, je možné se celkem snadno, rychle a s malými náklady podívat, co se právě děje ve většině světa a komunikovat. Takže abych se přiznal úplně nerozumim tomu, jak by se jako mělo multikulturalismu zamezit. Napadají mě jen dvě metody: Buď zavřít hranice a udělat z většiny zemí něco jako Severní Koreu (včetně informačního embarga), nebo nastolit jednu univerzální kulturu pro všechny lidi globálně. Nemůžu říct, že by mě jedna nebo druhá možnost nějak nadchla.

[Aleš Kapica]

Doslova si můžu během snad jen nekolika minut koupit letenku na většinu míst světa.

To můžeš. Ovšem podíváš se tam, jen pokud je najdeš na Hamáčkově semaforu. 8-P

[kralyk z abclinuxu]

No to je ta první zmiňovaná metoda. Akorát v tomhle případě snad jen dočasná...

[xxxs]

zase je rozdiel dovolit niekomu prist na navstevu, alebo ho na vlastne naklady zivit s tym, ze si prinesie dedka, babku, sesternicu, 500 deti a predstavu o tom, ze chamurapi je prilisny novator.

[Fluttershy, yay!]

na vlastne naklady zivit

To je smůla, že po zavření hranic se místním nechtělo dělat ruční práce v zemědělství.

[xxxs]

sezonni robotnici a pracovne povolenia vs ja som prisel z afriky/azie a teraz mi dajte socialku.

[Fluttershy, yay!]

ja som prisel z afriky/azie a teraz mi dajte socialku

Hypotetických scénářů si dokážu navymýšlet…

[xxxs]

takze toto sa napr. v nemecku nedeje?

[kralyk z abclinuxu]

vs ja som prisel z afriky/azie a teraz mi dajte socialku

Ok, ale to už jsme se posunuli od multikulturalismu někam jinam ne?

[xxxs]

kam?

[kralyk z abclinuxu]

Sociální politika atd. ne?

[xxxs]

prilis spojene nadoby.

[Marian]

Ano, můžeš tvrdit, že multikulturalismus ve vakuu a za určité konstelace Jupiteru a Venuše bude fungovat. Ale pro praxi je to nepoužitelné.

V praxi v podstatě každý stát nějakou sociální politiku dělá - nehodnotím jestli je to dobře nebo špatně - ale je to prostě realita, kterou je potřeba brát v potaz. A zároveň existují tlaky, aby všechny osoby nacházející na daném území měly stejné sociální a další služby od státu. Pátá kolona používá gaslighting, různé manipulativní techniky a termíny ("občan druhé kategorie" atd.), snaží se v lidech vyvolat pocit viny ("jsi zlý bílý kolonialista")... a následně jim prodávat "odpustky" v podobě např. přijímání migrantů (kterým emotivně říkají "běženci" a "utečenci" - zajímavé je, že z těch "válečných zón" většinou "prchají" jen mladí muži, zatímco pro ženy, děti a starce je tam nejspíš bezpečno) nebo tzv. "pozitivní" diskriminace, penězovody pro "neziskovky"...

Pokud nejsi čistokrevný libertarián, který by chtěl trvale provozovat minimální stát, tak musíš vidět i tyto souvislosti a domýšlet důsledky.

[Fluttershy, yay!]

Tolik omáčky kolem prostého tvrzení, že chceš etnostát.

[kralyk z abclinuxu]

Ano, můžeš tvrdit, že multikulturalismus ve vakuu a za určité konstelace Jupiteru a Venuše bude fungovat. Ale pro praxi je to nepoužitelné.

Mně přijde, že minimálně do nějaké míry funguje celkem běžně už teď bez nutnosti exotických konstelací planet. Samozřejmě ne vždycky a problémy jsou značné, to nechci rozporovat.

Přijde mi, že to, co se tady kritizuje, není ani tak multikulturalismus, ale evropská imigrační a sociální politika + neefektivní vymáhání zákonů + tichá podpora pašeráků, a navíc se to omezuje typicky jen na migrační vlnu z Afriky a blízkýho východu. Zatímco třeba problematika 200k Ukrajinců nikoho netankuje. A když pak kvůli koronaviru nedorazí sběrači, tak Čechům se nechtějí sbírat jahody, to je až komický...

[Jendа]

TBH pokud za sbírání jahod dostaneš stejně málo nebo dokonce míň (protože si musíš zařídit dopravu na místo sběru, oblečení a další režii ze svého) než za nesbírání (různé sociální dávky a podpora v nezaměstnanosti, případně alternativní low-end brigády typu skládání housek v mekáči), tak asi motivace dost opadne. Nebo tohle je ten důvod, ne?

[Fluttershy, yay!]

Erntehelfer bei Spargel Ritter protestieren gegen Missstände

nebo taky

Are your tinned tomatoes picked by slave labour?

[kralyk z abclinuxu]

tak asi motivace dost opadne

Jasný no, tim jsem nechtěl ani tak kritizovat Čechy, je to daný asi hlavně ekonomickým nastavením...

[Marian]

Cestování, sdílení informací nebo obchod jsou něco úplně jiného než multikulturalismus.

[prqek]

Jo, ale v dnešním světě k němu celkem nevyhnutelně vedou.

[trekker.dk]

To teda ne. Když sem na týden přijedou turisté z islámských zemí, tak je to něco jiného, než když se tu usadí natrvalo a začnou s obřezáváním svých dcer. To první je dočasná návštěva příslušníků jedné kultury u jiné, to druhé je soužití - a v tomhle případě konflikt - dvou různých kultur, kde předpisy jedné jsou v přímém rozporu s předpisy druhé.

[kralyk z abclinuxu]

Když sem na týden přijedou turisté z islámských zemí, tak je to něco jiného, než když se tu usadí natrvalo a začnou s obřezáváním svých dcer.

Ok, jaká tedy maximální doba pobytu by měla být povolená? Já nebo lidi které znám např. v minulosti nemalou dobu pracovali / žili v zahraničí (od měsíců přes roky). Mělo by se tohle zakázat? Případně povolit pouze pod podmínkou, že gastarbeiter se minimálně na dobu pobytu zřekne své původní kultury?

Pozn. tím nechci vyjádřit podporu středověkým metodám, jako je ženská obřízka, pouze by mě zajímalo, jak to má v praxi bez toho multikulti fungovat.

[xxxs]

das pracovne povolenie. robotnik, alebo odbornik si moze priviest najblizsiu rodinu(deti, zena(jedna), manzel). skonci kontrakt, ide domov. kludne tu moze mat job cele roky. najlepsie by bolo, ak by po patdesiatke museli ist domov bez pardonu. este budu pri sile, svoje vedomosti tak mozu odovzdat v krajine povodu. nieco si zarobia, nieco sa naucia. win win. paraziti co pridu len tak, sa nasadia do lietadla, alebo na lodku a odvlecu domov. paseraci sa chytia a odoberie sa im majetok ziskany po zacati trestnej cinnosti. uplne jednoduche veci. lenze z nejakeho dovodu sa nechce.

[JS1]

V takto nedemokraticke spolecnosti bych tedy zit nechtel, ale kazdy mame nejake preference.

[JiK]

aniz bych to hodnotil, takhle to ale funguje treba v rasistickem japonsku. Tam se dokonce snazi udelat vse, co muzou, aby pripadny cizinec vypadl a nezustal jim tam na duchod.

[kralyk z abclinuxu]

Hm, a má ten člověk v tom případě o něco snížené daně? (Asi nemá smysl, aby si platil na důchod, když ho nebude moct využít.)

[JS1]

Japonsko neni az tak vyrazne demokraticky stat, co jsem slysel. A taky bych tam nechtel zit.

[xkucf03]

Jak je to v rozporu s demokracií? Nejde o občany našeho státu, přijeli sem dobrovolně, dočasně udělat nějakou práci a dostat za to peníze. Pokud se jim podmínky nelíbí, nemusí sem jezdit.

[trekker.dk]

Co by vám konkrétně mělo vadit, je, že je to v rozporu se smlouvou. Ve smlouvě se státem je, že ze své mzdy odvádím sociální daň a za to v důchodu dostávám peníze. Ty v tom návrhu na vyexpedování domů jaksi chybí.

[Aleš Kapica]

Co by vám konkrétně mělo vadit, je, že je to v rozporu se smlouvou. Ve smlouvě se státem je, že ze své mzdy odvádím sociální daň a za to v důchodu dostávám peníze. Ty v tom návrhu na vyexpedování domů jaksi chybí.

To je mi ale novinka. Nějak si nepamatuji, že bych se státem uzavíral nějakou smlouvu, která by mne k něčemu zavazovala. Jenom se mi různí lidé snaží neustále vnucovat, že jsem povinován poslušností jejich gangu, který nazývají státem.

To co ty nazýváš daní, považuji za výpalné, aby mě ten jejich gang nechal na pokoji – bohužel žiju v době, kdy už jako jednotlivec nemám jinou možnost.

[Fluttershy, yay!]

Chyba!

Bot Kapica byl spuštěn nad daty bota Odina.

[Aleš Kapica]

Jestli jsem já bot, tak ty seš reinkarnovaný Trocký. Taky skočíš na kdejakou blbost, kterou plácnou zdejší technokrati, co si myslí, že maj patent na rozum, jako on.

[trekker.dk]

Nějak si nepamatuji, že bych se státem uzavíral nějakou smlouvu, která by mne k něčemu zavazovala.

Žijete ve společnosti a ta se řídí nějakými pravidly. A jedním z nich je vztah občana a státu, což je smlouva existující implicitně. Může se vám to nelíbit, ale dokud nedojde k revoluci nebo změně zákonů, tak to nemůžete rozporovat. (Teda můžete, hubou, to je tak jediné, ale shodou okolností je to to jediné, co vám jde dobře.)

[xkucf03]

Žijete ve společnosti a ta se řídí nějakými pravidly. A jedním z nich je vztah občana a státu, což je smlouva existující implicitně.

Jednak každý stát má svoje vlastní pravidla. A jednak, jak i sám píšeš, jde o vztah občan-stát. Cizinec, který přijel navštívit nějakou zemi, není její občan.

což je smlouva existující implicitně

Např. z domova můžeš být zvyklý, že je dvakrát denně teplé jídlo a že se večer koukáš na televizi. Když ale přijdeš na návštěvu do jiné rodiny, tak tam to může fungovat jinak – je to tvoje volba, jestli tam na návštěvu půjdeš nebo ne.

Podraz by byl leda to, kdyby by ti předem závazně něco slíbili, a pak to nesplnili. Pokud ale předem znáš podmínky, žádný problém v tom nevidím.

[trekker.dk]

Cizinec, který přijel navštívit nějakou zemi, není její občan.

Nicméně je nucen tu smlouvu dodržovat také. Nebo snad cizinci a jejich zaměstnavatelé neplatí sociální daň?

Když ale přijdeš na návštěvu do jiné rodiny, tak tam to může fungovat jinak – je to tvoje volba, jestli tam na návštěvu půjdeš nebo ne.

Máte to s tím liberalismem zajímavě uspořádané. Takže cizinec si může vybrat, jestli na návštěvu přijede, ale pokud ano, tak musí dodržovat pravidla, tj. zákony, a to včetně povinnosti platit sociální daň. Ale stát ne. Není to trochu divné, že stát nemusí dodržovat vlastní pravidla jen ve vztahu k někomu?

Já bych navrhoval, aby stát nemusel dodržovat pravidla ani vůči třeba vám. Důvod je stejný a má stejnou váhu jako ten váš vůči cizincům, nelíbíte se mi.

[Aleš Kapica]

Já bych navrhoval, aby stát nemusel dodržovat pravidla ani vůči třeba vám. Důvod je stejný a má stejnou váhu jako ten váš vůči cizincům, nelíbíte se mi.

Už to z vás leze.. Ještě že tady systém jaký byste si přál nemáme. V demokratickém systému rozhodování na základě osobní sympatie či antipatie jednotlivce, který odmítá akceptovat jiný názor, nemá co dělat.

[trekker.dk]

V demokratickém systému rozhodování na základě osobní sympatie či antipatie jednotlivce, který odmítá akceptovat jiný názor, nemá co dělat.

Správně, šikula, nalepte si do deníčku hvězdičku. A pak to můžete vysvětlit předřečníkovi, který takový postup zjevně bere jako akceptovatelný. Narozdíl ode mě, čehož jste si měl všimnout, na tom by to chtělo ještě zapracovat.

[xkucf03]

Mám si tě přiřadit k pomatencům hlásajícím tzv. open borders? Nebo dokážeš přijmout, že občan státu a cizinec (občan jiného státu) můžou mít odlišná práva a může pro ně platit odlišná „smlouva“ s daným státem?

[Fluttershy, yay!]

Myslíš libertariánům?

[xkucf03]

Ne, myslím lidi, jako jsi ty.

Vztah libertariánů k migraci se tu už diskutoval. Najdi si to. Ve zkratce: v libertariánském minimálním státě je vše soukromé a je minimalizováno společné bohatství – není tedy co rozkrádat a na čem parazitovat¹ – proto se můžeš setkat s libertariány, kteří by občanství nebo právo pobytu dali kde komu.

Když jsem ti ale navrhoval, že ten minimální stát můžeš vzít jako framework, nad kterým si se svými soudruhy vybudujete (na smluvním a dobrovolném základě) ten svůj socialismus, tak jsi na to nereagoval nebo jsi byl proti.

Asi proto, že tušíš, že by ti to nefungovalo. Zřejmě jsi jako kterýkoli jiný komunista, který potřebuje nejdřív nakrást bohatství, které vzniklo mimo socialismus/komunismus. Ten pak následně „vybuduješ“ a budeš předstírat, že to krásně funguje. Až postupně všechno to původní bohatství prožerete a ten váš systém se zhroutí a dojde k návratu k přirozenému tržnímu hospodářství.

_{[1] byť nějaké negativní externality – např. problémy s navýšením kriminality po přílivu migrantů – asi zůstanou vždycky}

[Fluttershy, yay!]

libertariánském minimálním státě

Protimluv.

Můžeš se jít dohadovat s Walterem Blockem.

[kralyk z abclinuxu]

Ve zkratce: v libertariánském minimálním státě je vše soukromé a je minimalizováno společné bohatství – není tedy co rozkrádat a na čem parazitovat

Myšlenka, že soukromé bohatství se nedá rozkrást nebo se na něm nedá parazitovat, je tak moc naivní, že ani pořádně nevim, co na to říct...

tak jsi na to nereagoval nebo jsi byl proti

Vzhledem k tomu, že pokusy s anarcho-kapitalismem se v zásadě rozdělují do dvou kategorií - ty, co ještě nebyly realizovány, a ty, co selhaly - mi to přijde jako celkem pochopitelný postoj.

[kralyk z abclinuxu]

Ono teda nutno dodat, že (anarcho) kapitalismus v tomhle není nijak unikátní, většina systému tak nebo onak nefungujou A o systému, který by fungoval, moc nevim.

A davkol tady většinou až moc nepíše o tom, jak si představuje systém fungování společnosti on...

[Fluttershy, yay!]

A davkol tady většinou až moc nepíše o tom, jak si představuje systém fungování společnosti on...

Proč například tak často odkazuji rozhodování založené na konsenzu – a zahrnutí co nejvíce stakeholderů?

[kralyk z abclinuxu]

Zcela upřímně, nevim. Nemam zdaleka tolik načteno politické teorie, sociologie atd., takže nějaké náznaky nevstřebám...

[Fluttershy, yay!]

Mimochodem, místní samosprávy často připomínají ten „malý stát“, často v nich bují ta nejokatější korupce, ale na druhé straně jsou také zkušenosti s demokracií – od sněmů po participativní rozpočet.

[Bherzet]

Naopak by měl větší šanci, že by mu to tam v nějaké malé komunitě fungovalo. Zapamatovat si preferovaná oslovení u stovky lidí ještě jde, ale ve větší míře by ti z toho hráblo. Proč myslíš, že teď vznikla ta autonomní zóna v Seattlu? Zabralo to roky sporů a pár vystřelených očí, ale konečně se tam můžou všichni vzájemně milovat a přitom se neurážet ošklivými slovíčky.

[Jendа]

Když jsem ti ale navrhoval, že ten minimální stát můžeš vzít jako framework, nad kterým si se svými soudruhy vybudujete (na smluvním a dobrovolném základě) ten svůj socialismus, tak jsi na to nereagoval nebo jsi byl proti.

Třeba mu ten socialismus nefunguje bez násilí úplně stejně, jako nefunguje volný trh (který má jako jeden failure mode například sklouznutí k monopolům).

[Fluttershy, yay!]

Žádný minarchista (apod.) mi doposud nevysvětlil, jak zabránit převzetí malého státu silnou zájmovou skupinou.

Historický fakt: ve společnosti jsou různé zájmové skupiny s protichůdnými zájmy. Takže které z nich bude stát při posuzování jejich sporů preferovat?

[Bherzet]

Trik je v tom, že když to formuluješ dostatečně obecně, tak tomu v demokracii zabránit z principu prostě nejde. Stát je prostě nějaká banda lidí a pokud si hraješ na demokracii a necháváš je rozhodovat, tak vždycky může někdo přijít a majoritu jich zmanipulovat. Lokálně tomu můžeš zkoušet bránit, v globálním informačním prostoru jinak než cenzurou a firewally těžko.

[Fluttershy, yay!]

1. Nirvana fallacy

2. Proto máme mechanismy pro omezení vlivu jednotlivých zájmových skupin, které by koncentraly moc.

   V liberalismu je to dělba moci, antitrust aj. Akorát historie ukazuje, že liberalismus má tendence se zvrhnout – zdaleka není dostatečný.

   Odtud např. větší decentralizace moci v socialismu (kolektivní řízení výrobních prostředků). V případě marxismu-leninismu má tyhle kolektivy chránit předvoj („vanguard“), což je ovšem zase single point of failure, jak se ukázalo v některých (ale ne všech) případech. ML zdaleka není jediná forma socialismu, jiné (zvláště anarchistické) prostě centralizovaný stát zavrhují, popř. „stát“ nahrazuje federace těch jednotlivých komunit (municipalismus).

   V izolovaných tradičních komunitách jsou zase vyvinuté komunikační strategie… ano, když tam vlétnou např. misionáři, může to nadělat paseku, ale zase více komunit mezi sebou může komunikovat – jako federalismus (vedle byli zmíněni původní obyvatelé Ameriky), internacionalismus,…

[Bherzet]

A nevede svoboda podnikání a nízké legislativní bariéry vstupu za předpokladu nějakého (neřeším teď jakého) vyřešení těch obřích monopolů k přesně podobnému výsledku? K decentralizaci, rozdělení pravomocí mezi velké množství lidí.

On ani ten monopol není automaticky špatně. Já si nemyslím, že je úplně dobrý nápad růst firem např. nějak uměle zastropovat. Špatně je, když se to nechá úplně bez dohledu. Ale je nutné si tam ujasnit priority u případných regulačních zásahů a uplatňovat jasnou, pokud možno předem známou politiku.

[Fluttershy, yay!]

A nevede svoboda podnikání a nízké legislativní bariéry vstupu za předpokladu nějakého (neřeším teď jakého) vyřešení těch obřích monopolů k přesně podobnému výsledku? K decentralizaci, rozdělení pravomocí mezi velké množství lidí.

To opravdu předpokládal Adam Smith před nějakými 250 lety a v dobovém kontextu to skutečně vypadalo atraktivně, leč praxe následujících staletí ukázala selhání.

[Bherzet]

Praxe následujících staletí ukázala svobodu a prosperitu na straně jedné a chudobu a totalitu na straně druhé.

[Fluttershy, yay!]

Dokonce to má jméno: sociální nerovnost a v liberalismu konkrétně ekonomická nerovnost

[JiK]

Muzu se te zeptat jestli bys nam mohl vyjmenovat pet zemi, kterym socialismus nebo marx leninismus prinesl prosperitu? Nebo treba jen tri?

[Fluttershy, yay!]

To by byl dlouhý seznam. Pak by následoval skoro stejně dlouhý seznam zemí, kde zvláště USA podpořily vojenský puč (laskavého čtenáře by mohla zajímat Operation Condor nebo Jakarta Method) nebo intervenoval IMF.

Dále, Otto von Bismarck nezaložil sociální stát jen tak z rozmaru nebo dobré vůle, leč kvůli tlaku dělnického hnutí. Ani sociálně demokratické strany s četnými úspěchy napříč nejen Evropou se nezjevily z vakua. Cíle vyjednávání i kompromisu se musely někde vzít.

Ale chápu, že někteří si pod úspěchy nepředstavují dostupnost vzdělání a zdravotní péče nebo omezení chudoby, nýbrž volnou ruku zahraničního kapitálu v drancování nebo právo držet ostatní jako nevolníky.

[JS1]

No, ja nevim, ciste empiricky, jak psal David - zatim jsem nevidel pokus o minarchisticky stat nebo spolek, ktery by se rychle nezhroutil kvuli spatnym akterum. Ano, extremni komunismus nebo socialismus se sice taky hrouti, ale mnohem pomaleji. Existuji i ruzne komuny jako kibutzy a podobne, ktere se udrzi dekady. Takze oba jsou nestabilni systemy, ale minarchismus mi empriricky pripada nestabilni radove vic. Tim spis je ten argument komunismem u minarchistu dost pochybny, protoze komunismus je historicky vzato uspesnejsi system nez minarchismus.

Proste bud se v lidskych spolecenstvich musi moc udrzovat pevnou rukou (a to znamena nesvobodu), nebo demokratickou dohodou, nebo nejak mezi tim, coz je forma fasismu. Pokusy mimo toto spektrum zda se rychle selhavaji.

[Bherzet]

Minarchismus vnímám spíš jako proces, jako neustálou snahu o zeštíhlování státu, zjednodušování zákonů a maximalizaci individuálních svobod. Cesta je cíl. Programy se refactorují relativně běžně, zákony ne. Už jsem tu psal jak a v čem konkrétně mi pije krev třeba stavební zákon a jak bych si to představoval správně (tldr: povolení na polohu+tvar+rozměry stavby, u menších staveb buď zcela bez projektu, nebo jen s focusem na nejklíčovější nosné prvky a obecně bezpečnost [požární např.], průběžné fotodokumentování stavby a posílání na úřad, popř. občasné kontroly na místě).

Současný systém je dokonce mnohem benevolentnější než ten mnou navrhovaný. Říká se tomu černé stavby, staví se to úplně bez zájmu úřadů a pak se to v drtivé většině případů zpětně legalizuje. Akorát občas teda dojde na bourání, což je ta zásadní neefektivita tohoto systému.

[Fluttershy, yay!]

zeštíhlování státu

Zeštíhlování o co?

zjednodušování zákonů

Zjednodušování o které části?

maximalizaci individuálních svobod

Maximalizaci čích svobod?

---

V praxi skutečně pozorujeme zeštíhlování státu – např. formou privatizace. To znamená, že příslušné funkce jsou pak privátní (soukromé) a tudíž nikoliv předmětem veřejné kontroly.

Zeštíhlování – např. rozpočtů na sociální služby, ale silové složky nikoliv.

Zjednodušování zákonů? Jsou i jiné normy (vyhláška, výklad zákona různými orgány), popř. když se to přenechá smluvním vztahům – ten silnější si nadiktuje podmínky smlouvy, jaké chce.

…

---

tl;dr minarchismus je elegantní nástroj, jak podpořit spřátelené zájmové skupiny, zatímco na internetech tomu užiteční idioti tleskají, jak je to na papíře vypadá elegantně

[Bherzet]

Uvedl jsem zcela konkrétní příklad, co si pod tím představuji. Dokonce bys z minulých diskuzí mohl i znát třeba můj pohled na sociální systém (že bych nikoho nenechával umrznout/hladovět/bez přístupu ke zdravotní péči, ale jinak bych snahy směřoval jen k „žebříku sociální mobility“, tj. přístupu ke vzdělání/informacím; životní komfort je starost jednotlivce) atp.

[Fluttershy, yay!]

Slova, co znamenají?

Když se Martin Škabraha pokusil redefinovat konzervativismus, měl aspoň nějakou agendu. Vlastně by to nebylo bezprecedentní.

Ale snažit se legitimizovat minarchismus (sám o sobě vcelku bizár) tím, že se na něj napasuje něco jako Rawlsův liberalismus, přestože právě minarchismus a „malý stát“ byl stavěn jako protiklad k němu, to je fakt chucpe.

Protože stát je toliko nástroj – k prosazování hodnot, kterou jsou tedy jaké? To už není primární součástí sdělení.

Řeknu-li totiž v současném společenském uspořádání „malý stát“ („libertarián“, „minarchismus“,…), ta asociace je s privatizací a – korporatismem. Tzn. efekt přesně opačný, než když řeknu, že například chci, aby všichni měli kde bydlet… což také otevírá portfolio mnohem více nástrojů.

[Bherzet]

Přijde mi to podobně absurdní jako dnešní pravici a levici posuzovat podle historických měřítek (což zde také proběhlo). Když se podíváš na současné přebyrokratizované státy a mainstreamové politické směry a pak na lidi, kterým to vadí, a kteří volají po větší ekonomické i osobní svobodě, najednou ten pojem dává smysl. A je to jaksi relevantnější než encyklopedický pohled na to, kde se ten pojem poprvé historicky objevil; zvlášť, když se jedná spíš o drobné rozvinutí té myšlenky, ne naprostý ideologický rozpor.

[Fluttershy, yay!]

Levici/pravici, stejně jako kdykoliv jindy, definují hodnoty – co to znamená pro konkrétní lidi a skupiny lidí? (poznámka: uvědomuji si antropocentrismus dané formulace)

Formulace „volají po větší ekonomické i osobní svobodě“ je velmi dobrý příklad. Karl Marx v 19. století totiž pozoroval, že hesla francouzské revoluce („liberté, égalité, fraternité“) ve skutečnosti nebyla pro většinu lidí naplněna, a tak se zaobíral tím, jak je dotáhnout do praxe. (Řada nejen Marxových pozorování je dnes aktuální více než kdykoliv jindy, např. záležitost odcizení.)

Když dnešní pravicově liberální strany „volají po větší ekonomické i osobní svobodě“, říkají také: zavřete oči, zapomeňte na podmínky jednotlivých [skupin] lidí a historii, která k nim vedla. Méně pravicové liberální strany oči nezavírají, ale říkají: uděláme tady nějaký program, který tu historii nějak zkusí vykompenzovat. Neliberální levice (a někdy i pravice) pak přichází s pozorováním, že ne, liberalismus tenhle historický vývoj reprodukuje, tady je systémová změna.

[JS1]

Tak uznej, ze ti to proste David nandal a ani mu to zda se nedalo moc prace. Utahnout partnera v diskusi na neznalosti jim prosazovane teorie, pred tim se da jen smeknout.

[Bherzet]

Neutáhl mě na ničem. Prostě se mu nelíbí používané názvosloví. K tomu jsem řekl své a víc k tomu nemám co dodat.

[JS1]

Vzdycky, kdyz vidim nejakou diskusi s libertarianem, tak se mi vybavi ta Feynmanova historka o tom, jak se hadal s malirem, ze zlutou barvu nedostane z bile a cervene; nakonec malir uznal, ze trochu te zlute na to potreba je. Ty chces "maly stat", a "minimalni dane", ale kdyz se zacneme bavit konkretne, jake funkce statu bys tedy zrusil, tak najednou je toho dost malo, co se da najit.

[Bherzet]

Kdyby náš stávající stát byl třeba o, plácnu, 10 % větší než si myslím, že musí být, tak už po tom minimálním státu volat nemůžu?

Jinak ono se toho ve skutečnosti najde dost, ale jednak to trousím po příkladech, na které si zrovna vzpomenu, jednak se ve svých názorech držím relativně zkrátka, protože si nechci v hlavě stavět vzdušné zámky. Hledám zlepšení stávajícího stavu, o kterých se lze s velmi vysokou jistotou domnívat, že nezpůsobí džungli a chaos, a které lze případně snadno vrátit zpátky. Teoretické diskuze o stavění státu na zelené louce jsou sice hezké, ale reálně musíme vycházet z toho, co je. Takže to beru postupně a protože zatím nedošlo ani na ty „mělké“ věci, těm hlubším nevěnuji příliš pozornost. Ono to taky vyžaduje si to téma nastudovat a dělat to u věcí, které je nereálné, ne-li vysloveně destruktivní hned zavést, by mi nepochybně dalo hezké argumenty do diskuzí, ale jinak je to jaksi ztráta času.

[JS1]

Kdyby náš stávající stát byl třeba o, plácnu, 10 % větší než si myslím, že musí být, tak už po tom minimálním státu volat nemůžu?

Pak je to IMHO dost zavadejici oznaceni toho, co bys vlastne chtel, zvlast kdyz souslovi "minimalni stat" ma celkem jasne politicke konotace. Mozna "efektivnejsi stat" by bylo vystiznejsi, ale nejlepsi by asi bylo nazvat to podle konkretniho programu toho zmenseni.

[Fluttershy, yay!]

Mozna "efektivnejsi stat" by bylo vystiznejsi

Logická otázka: efektivnější v čem?

[Bherzet]

Já si nemyslím, že je to zavádějící. Minarchismus tak, jak je typicky popisován a definován, mi imponují a je to směr, kterým se dívám. To, že se na to dívám kriticky, beru v potaz nějaké přirozeně se nabízející otázky/obavy a uvědomuji si, že je extrémně složité jakýkoliv stát nakonfigurovat tak, aby nezkolaboval a prostě se v něm dobře žilo, takže k tomu přistupuji umírněně a spíš než po revoluci volám po evoluci, kde se budou různé principy postupně zkoušet uplatňovat, s tím podle mě není v rozporu.

[Fluttershy, yay!]

Lidé mají tendenci tíhnout k jednoduchosti a vnímat ji jako elegantní, ctnost… Snad protože jednoduché lze snáze uchopit

To jest, pokud se jedná o ideje sofistikovaných osobností – ve stejných společenských kruzích je jednoduchý člověk, ba dokonce primitiv až pejorativní označení.

Právě primitivismus jakožto myšlenkový směr ovšem cílí na zjednodušení společnosti (na uchopitelnou úroveň). Srovnej s minarchismem, jež tak nečiní, nýbrž toliko zjednodušuje stát, zatímco komplexitu přenechává na dalších částech společnosti.

Nabízí se otázka, zda je příčinou akademická masturbace, naivita, nebo jiné zájmy.

Praktický příklad: v industriální společnosti se potýkáme s toxickými látkami. Od doby, kdy jsme si to uvědomili (Silent Spring apod.), se to řeší tak, že regulační zákon tyto toxické látky vyjmenovává, potažmo – jelikož proces novelizace je pomalý a zákon bobtná – se tento seznam přenese např. na úřad pro ochranu životního prostředí, který seznam průběžně aktualizuje. Jenže – průmysloví znečišťovatelé různými metodami lobbují za deregulaci, restrikce se totiž podepisují na jejich ziskovosti. Tací jako Robert Nozick, od nějž stěžejní formulace minarchismu pochází, jsou pak logickými ideologickými spojenci.

Nebo jiný příklad, zmiňované „defunding the police“. To si lze vyložit různými, protichůdnými způsoby, pročež se nejedná o ideální motto. Když omezíme rozpočet instituce, co se stane? (a) příslušní lidé si budou toliko hledat práci (zvláště pokud ta předchozí byla skutečně zbytná), (b) vzniklý prostor vyplní něco jiného, ale co? Dotyčným aktivistům se jedná o „disinvestment“ a přesměrování zdrojů mj. do sociálních služeb (z pohledu minarchisty se tím stát nezmenší). Na druhé straně ale existují také tlaky na privatizaci v duchu např. Pinkerton Agency – stát je menší (minarchista plesá), instituce v principu stále existuje, prospívá to však veřejnému blahu?

[Bherzet]

z pohledu minarchisty se tím stát nezmenší

Už asi začínám chápat, v čem je problém. Lidé slyší „malý stát“, vyloží si to doslovně jako optimalizaci na velikost a nic než velikost (i kdybych to 100× zkoušel vysvětlit a prezentoval názory, které jsou proti tomuhle dost protichůdné), ale protože tedy minarchismus narozdíl od anarchismu připouští existenci státu, ideální minarchistický ráj asi vypadá tak, že je v něm 1 poslanec a 1 policajt a tím se dosáhlo dokonalosti a to, že třeba už ten stát není schopný plnit svou funkci (vymáhat zákony), je už jakože jedno.

[Fluttershy, yay!]

Moderní „malý stát“ je spojený s odkazovanou Nozickovou prací. Ve veřejném diskurzu jsou ty koncepty zjednodušené, ale teorie se nemění.

Což je klíčové pro diskuzi o společnosti jako takové.

[JiK]

... Ano, extremni komunismus nebo socialismus se sice taky hrouti, ale mnohem pomaleji. Existuji i ruzne komuny jako kibutzy a podobne, ktere se udrzi dekady...

Zkousel sis o tom neco precist? Treba rozhovory s pametniky, dobove dokumenty? Hnuti kibbutz bylo v dobach nejvetsiho rozmachu jen ~5% obyvatel Izraele. Zbytek (95% obyvatel) byla normalni trzni ekonomika. Kibbutznici sami behem jednotek let opustili ideu sdileneho kde ceho a krasne je to videt treba na ubytovani, ze zacatku byly jen chatky na prespani, a jedlo se ve spolecne jidelne, kde byly 24 hodin denne i zakusky, ovoce, kava a alhokol, treba. Behem par mesicu si to lide zacali nosit do chatek, aby meli individualni svobodu dat si pomerac bez dohledu cele komunity. Pak se zacaly delat individualni kuchynky v chatkach a rodiny si sami varily, tak jako tisice let predtim...

Presto to ocenuju, je to nejmene krvavy, a vicemene veskrze dobrovolny pokus o socialismus. Presto celkem rapidne selhal v okamziku, kdy mu izraelska vlada sebrala danove vyhody a vyjimky, a museli fungovat na bazi normalni konkurence a za stejnych podminek jako zbylych 95% obyvatel.

[trekker.dk]

rodiny si sami varily, tak jako tisice let predtim

No, pokud je "§1 dělalo se to tak vždycky" platným argumentem, nemělo by mít větší váhu to, že se desetitisíce let předtím vařilo a jedlo společně?

[JiK]

ja bych rekl, ze rodiny (jako spolecenske celky) bydli tak nejak spolu a vari v ramci jedne rodiny tak zhruba od dob, kdy ty celky prestaly byt tlupama, tedy od konce praveku. To ale neni dulezite.

Ja nikomu nezakazuji stat se kibbutznikem, naopak. To socialiste vsech odstinu rude se snazi srat sve zvracene ideologie do cim dal vice segmentu lidske existence, a pokud primo nezakazovat jine moznosti, tak aspon ostatni nutit, aby platili tu jejich...

[kralyk z abclinuxu]

ja bych rekl, ze rodiny (jako spolecenske celky) bydli tak nejak spolu a vari v ramci jedne rodiny tak zhruba od dob, kdy ty celky prestaly byt tlupama, tedy od konce praveku.

Ano. Akorát moderní doba vede k tomu, že ty celky se stále zmenšují. Tam, kde dřív jako celek fungovala širší rodina, funguje už dnes jen úzká rodina, případně třeba jen částečná rodina (jeden rodič + dítě), případně část lidí vůbec rodiny nezakládá a fungují stamostatně.

Oblíbenou kratochvílí tradicionalistů je tenhle jev házet na hlavu progresivistům, že propagují různé menšiny, LGBTQWIFIHDMI atd., kvůli kterým pak údajně dochází k erozi rodiny. Přitom ale když se člověk koukne do statistik, zjistí, že to reálně nijak moc nekoreluje a tradiční rodina má problém už delší dobu (minimálně u nás, hranice 30% rozvodovosti byla poprvé překonána r. 1975). Králem mezi těchto jednookých je potom V. Klaus ml., který po dvou rozvodoceh šéfuje straně bojující za tradiční hodnoty.

Můj osobní (subjektivní) názor je, že to je z velký části způsobený neustále se zrychlující ekonomikou a globalizací (v menším počtu lidí, nebo dokonce v jednom člověku je snazší dělat rychlý rozhodnutí a být mobilnější, a tedy se rychle přizpůsobovat trhu).

[JS1]

Můj osobní (subjektivní) názor je, že to je z velký části způsobený neustále se zrychlující ekonomikou a globalizací (v menším počtu lidí, nebo dokonce v jednom člověku je snazší dělat rychlý rozhodnutí a být mobilnější, a tedy se rychle přizpůsobovat trhu).

Ja nevim, mne spis prijde, ze je to dane hlavne tim, ze se mame lepe, a lide spolu proste zit ve skutecnosti moc nechteji, pokud nemusi. (Je to otrava, s nekym se delit a domlouvat a tolerovat jeho chyby.) A diky moderni spotrebni spolecnosti nemusi, protoze si proste jakoukoli sluzbu, co sami nezvladaji, mohou objednat odjinud. Takze ani neni duvodu lokalne spolupracovat, ani nejsou zadne krize, co by lidi timto zpusobem sblizily.

Zatimco historicky preziti lidstva zcela zaviselo na tom, jak spolu lide dokazali spolupracovat. Sam clovek prezit nemohl, tzv. tradicni rodina byla proste nevyhnutelna.

To je myslim i vysvetleni, proc si dnes tolik lidi mysli (jak rika Varoufakis), ze bohatstvi se vytvari individualne a pak jej treba ten zly stat kolektivne prerozdeluje. V drivejsich spolecenstvich to naopak bylo samozrejme vzdy tak, ze bohatstvi vytvarela spolecnost spolecne a teprve to se rozdelilo mezi jednotlivce.

[trekker.dk]

Nebo dokážeš přijmout, že...

Ne, takové uspořádání je neférové, neobhajitelné a dost možná protizákonné. Když někdo pracuje, tak na základě dohody dvou stran - zaměstnavatele a zaměstnance, ku prospěchu obou. Za to dostává mzdu. Pak přijde stát a od obou vyinkasuje nějaké peníze v kolonce sociální pojištění, a to za příslib sociální péče, tedy zajištění zaměstnance v nemoci a ve stáří. Nevidím žádný rozdíl v práci i penězích odvedených daným zaměstnancem a způsobený občanstvím zaměstnance, který by ospravedlňoval odejmutí tohoto příslibu.

Jinak inkasovat peníze a neposkytovat za ně protihodnotu je přinejmenším bezdůvodné obohacení.

Můžete si mě klidně přiřadit k pomatencům, co hlásají fair play - odlišná práva jsou přípustná pouze na základě odlišných povinností (podmínka nutná, nikoliv postačující.) To, co tady hlásáte vy, je ukázkové vykořisťování, morálně odporné jednání, které bolševici přisuzují kapitalistům. Moc mě netěší vidět, že se zjevně nepletli.

[xkucf03]

Pak přijde stát a od obou vyinkasuje nějaké peníze v kolonce sociální pojištění, a to za příslib sociální péče, tedy zajištění zaměstnance v nemoci a ve stáří.

Tohle dělení na různé daně (z příjmu, DPH, z nemovitosti…) a různá pojištění (sociální, zdravotní) nebo poplatky je jen taková obfuskace, aby to nebyla jedna velká částka a lidi se necukali ji platit. Možná trochu manipulace, aby měli pocit, že to má nějaký řád a hlubší smysl.

Ale není to důležité. Klidně by to mohla být jedna jediná daň.

Jinak inkasovat peníze a neposkytovat za ně protihodnotu je přinejmenším bezdůvodné obohacení.

Tak o tom si můžeš dlouze povídat třeba s Davidem a dalšími socialisty, kteří prosazují progresivní zdanění a další hrůzy. V takovém systému bohatí přispívají (výrazně) více, i když dostávají od státu méně služeb.

Rovná daň (všichni platí stejné procento), je sice v tomhle smyslu taky nespravedlivá, ale méně než to levicové progresivní zdanění.

odlišná práva jsou přípustná pouze na základě odlišných povinností

Ne. Podmínky si stanoví ten který stát. Jestli mu tam někdo bude dojíždět za prací, to už je druhá věc. Taky záleží, jak moc o to ten dotyčný stát stojí. Klidně se může rozhodnout (v demokracii o tom rozhodnou hlasováním občané), že cizinci nedostanou důchod, ale budou mít nižší daně. Pokud si ale občané odhlasují, že cizinci budou platit stejné daně a nebudou mít důchod, nebo že do dané země nebudou moci za prací jezdit vůbec, je to jejich legitimní rozhodnutí a není na tom nic špatného.

Důležité jen je, aby tahle dohoda byla známá předem, aby ten případný zahraniční pracovník věděl, do čeho jde a mohl se na základě toho rozhodnout. Pokud dobrovolně přijede, tak jde zjevně o oboustranně výhodný obchod a je to v pořádku.

[Fluttershy, yay!]

dalšími socialisty, kteří prosazují progresivní zdanění a další hrůzy. V takovém systému bohatí přispívají (výrazně) více, i když dostávají od státu méně služeb

Haha, ne.

[ve stávajícím liberalismu] Je to stát, co garantuje hodnotu peněz (tím, že v nich jdou zaplatit daně). Je to stát, co poskytuje nástroje pro vymáhání smluv.

Neboli: stát garantuje, že bohatí jsou bohatí. Bez něj by to bylo _explicitně_ o větším klacku. (Nebo počtu klacků.)

Jde říct, že každý si projde školní docházkou pouze jednou, takže bezprostředně je to na bohatství nezávislé – ovšem pouze do chvíle, kdy si člověk uvědomí, že má prospěch z toho, že do školy chodili i ostatní. Empiricky pak pozorujeme, že bohatství odpovídá využívání více těchto služeb.

[Fluttershy, yay!]

progresivní zdanění a další hrůzy … dostávají od státu méně služeb

Jiný úhel pohledu je, že nejde o platbu za služby, nýbrž o to, jaký způsob organizace společnosti chceme.

Koncentrace bohatství je v praxi koncentraci moci – vlivu. Tím se dostáváme od demokracie k oligarchii, plutarchii, tyranii.

Zdanění představuje jeden ze zdaleka nejmírnějších nástrojů, kterými se tomu lze bránit.

[trekker.dk]

Ale není to důležité. Klidně by to mohla být jedna jediná daň.

Klidně, v takovém případě dotyčný odvádí jedinou a docela vysokou daň, za kterou jsou mu přislíbeny služby integrovaného záchranného systému, provozu dopravní infrastruktury, sociální zajištění a další, ale některé z těchto služeb jsou následně odepřeny. Jste tam, kde jste byl.

Podmínky si stanoví ten který stát.

Ano, jeden stát si třeba stanovil, že když jste Žid, je vaše existence nežádoucí. V jiném státě si o něco desítek let později zase stanovili, že je potřeba pobít lidi se vzděláním. Náš stát si vcelku nedávno stanovil, že lidé, co mají majetek, patří do kriminálu nebo uranových dolů. To, že si něco občané (nebo jimi demokraticky zvolení zástupci) odhlasovali, není postačující podmínka pro to, aby to bylo v pořádku.

A uzavřít smlouvu, u které předem deklaruji, že v nějaké míře nebudu plnit svoji část, ale přesto budu vyžadovat celé plnění od protistrany, v pořádku prostě není.

nebo že do dané země nebudou moci za prací jezdit vůbec

To by bylo fér. Asi to trochu položí firmy, které jsou z desítek procent závislé na cizincích na dělnických pozicích, ale vy jim určitě dokážete odůvodnit, proč je to lepší varianta než pustit do toho našeho socialistického ráje pracující lidi

[xkucf03]

Ale není to důležité. Klidně by to mohla být jedna jediná daň.

Klidně, v takovém případě dotyčný odvádí jedinou a docela vysokou daň, za kterou jsou mu přislíbeny služby integrovaného záchranného systému, provozu dopravní infrastruktury, sociální zajištění a další, ale některé z těchto služeb jsou následně odepřeny. Jste tam, kde jste byl.

Tohle jsou takové dětské představy o tom, jak fungují daně. Ano, můžeme se bavit o tom, jak by to mělo či mohlo vypadat… Nicméně dnes daně fungují na úplně jiném principu a většinu lidí to nepřekvapí. Viz třeba heslo na Daň na Wikipedii:

Vyznačuje se neúčelovostí a neekvivalentností, tzn. ukládá se jako jednostranná povinnost bez nároku plátce na plnění ze strany vyhlašující autority.

Jak by měl vypadat daňový systém, to je na celou dlouhou diskusi, do které se teď asi nechci pouštět. Nicméně hádat se o tom, že nějaký zahraniční pracovník byl „podveden“, je bezpředmětné. To by pak byl „podveden“ i kterýkoli jiný občan, který zaplatil na daních více, než kolik služeb od státu dostal (o ti ostatní by se zase „bezdůvodně obohatili“).

A uzavřít smlouvu, u které předem deklaruji, že v nějaké míře nebudu plnit svoji část, ale přesto budu vyžadovat celé plnění od protistrany, v pořádku prostě není.

Jak nebudu plnit? Ta smlouva definuje nějaká práva a povinnosti. Pokud nesplním to, k čemu jsem se smlouvou zavázal, tak je to samozřejmě špatně. Ovšem to není ten případ, o který se tu pořád hádáš.

Stejně tak někdo může říct, že s cizinci jsou problémy, šíří nemoci, mají vyšší kriminalitu, je s nimi více administrativy atd. a že by proto měli platit vyšší daně než občan, aby ty svoje náklady pokryli, aby to bylo spravedlivé. Jestli je to tak či onak, to je na dohodě (v demokracii o tom budou hlasovat občané). A pak je na tom cizinci, jestli se mu za takových podmínek vyplatí sem přijet a takovou smlouvu uzavřít.

Ty rozdíly mohou být v jednom i druhém směru – v některém státě se mohou občané dohodnout, že cizinci oproti domácím nebudou platit „sociální pojištění“, zatímco v jiném to bude jinak.

To by bylo fér.

Nevím proč by mělo být „víc fér“ nedat nějakou nabídku než dát nějakou nabídku (které druhá strana může ale nemusí využít). Když např. v Praze na Pařížské existuje předražený obchod, ve kterém nikdy nenakoupíš, protože to je pro tebe nevýhodné, tak tě to nemusí nijak trápit – že tahle nabídka existuje, tě nijak nepoškozuje.

[trekker.dk]

Tohle jsou takové dětské představy o tom, jak fungují daně.

A jaké jsou teda ty správné představy? Že stát na jedné straně schlamstne peníze, ty zmizí, a na druhé straně se z ničeho objeví jiné peníze, ze kterých se platí státní výdaje?

Stejně tak někdo může říct, že s cizinci jsou problémy, šíří nemoci, mají vyšší kriminalitu, je s nimi více administrativy atd. a že by proto měli platit vyšší daně než občan, aby ty svoje náklady pokryli, aby to bylo spravedlivé.

Ano, to by někdo říct mohl. V takovém případě je ovšem otázka, proč je tu zaměstnáváme? Jestli ono to nebude tím, že ti, kteří tu legálně pracují, se na té vyšší kriminalitě, nemocech a problémech zase tolik nepodílí. Administrativu neberu ani náhodou, tu jsme si vymysleli my, ten cizinec o tři hodiny stání ve frontě na cizineckém určitě nestojí.

Když např. v Praze na Pařížské existuje předražený obchod, ve kterém nikdy nenakoupíš, protože to je pro tebe nevýhodné, tak tě to nemusí nijak trápit – že tahle nabídka existuje, tě nijak nepoškozuje.

A co když si můžu vybrat - a jiné možnosti nemám - jestli umřu hlady, nebo nakoupím v tom obchodě? To je, panečku, výběr.

Nevím proč by mělo být „víc fér“ nedat nějakou nabídku než dát nějakou nabídku

Úplně jednoduše: protože když se nedá žádná nabídka, tak žádná strana nemá prospěch. Když se dá nevýhodná nabídka, kde se zneužívá horšího postavení jedné strany - a postup "teď pro nás budeš třicet let pracovat, to se nám hodí, a když už moct pracovat nebudeš, tak tě vykopneme do chudé země bez fungujícího zdravotnictví a důchodového zabezpečení" je přesně to - tak to fér není. Je to nemorální a lidsky odporné. Stejně jako vy.

[Bherzet]

Takhle to ale funguje ve většině zemí světa. Po deseti letech práce (a placení daní) třeba v USA bych tam taky neměl nárok na důchod a nemusel bych mít ani zelenou kartu, natož občanství. Stačí pak nesehnat práci a člověk poputuje domů, ať se mu to líbí nebo ne. Liší se jen ta lhůta, z morálního hlediska je to ale v principu stejné.

Spíš je nutné si uvědomit, že dotyčný se tu může rozmnožit. Protože se v ČR občanství novorozencům uděluje podle zásady ius sanguinis, vyplývají z toho poměrně zábavné scénáře.

• Cizinec přijde se svou manželkou (cizinkou) a narodí se jim dítě, které získá jejich občanství. V ČR ovšem bude vyrůstat, chodit tu do školy apod. O občanství si po nějaké době požádá a:
  • dostane ho, jako za normálních okolností, ale jeho rodiče budou po těch 30 letech vyhoštěni;
  • nedostane ho a že třeba ani neumí jazyk země, které je občanem, je jeho problém;
• Cizinec zplodí dítě s Češkou a to tak nabyde českého občanství. Jsou-li
  • sezdaní, i sám otec nabyl českého občanství;
  • nesezdaní, rodina bude po dovršení oněch 30 let rozdělena (matka a – v té době už dospělé – dítě zde zůstanou, otec bude deportován);

tl;dr: pustit sem někoho na dlouhou dobu (30 let), ale neudělit mu ani občanství, ani povolení k trvalému pobytu, generuje divné scénáře.

Mám kamaráda, který tu chodil na střední a pak se s rodiči vrátil do Ruska. V té době měl šanci si požádat o povolení k trvalému pobytu/občanství, ale nevěděl o tom. Tím, že odjel, se mu přerušil zde hlášený pobyt a „counter“ se resetoval na nulu. Později se sem přes pracovní povolení vrátil, ale skončilo mu – pro firmy to prý je byrokracie, kterou nechtějí řešit. A protože tu teď nebyl dost dlouho v kuse, musel se odstěhovat. Což mi třeba nepřijde OK.

[Jendа]

Ne, takhle to nefunguje, ze sociální daně se platí současné státní důchody, a tvůj se bude platit ze sociální daně v-té-době-pracujících. Možná.

A tím se ten zdánlivý rozpor elegantně vyřešil!

[JS1]

Jak je to v rozporu s demokracií? Nejde o občany našeho státu, přijeli sem dobrovolně, dočasně udělat nějakou práci a dostat za to peníze. Pokud se jim podmínky nelíbí, nemusí sem jezdit.

Zakladnim principem demokracie je rovnost obcanu, zejmena v rozhodovani o verejnych zalezitostech. Kdo je obcan? Historicky se pouzivaly definice vyctem (nejaka privilegovana skupina lidi), moderni uzus je, ze zahrnujeme pokud mozno vsechny cleny prislusne spolecnosti. Hacek je samozrejme v tom slove "docasne". Pokud je to, rekneme, vic nez 5 let, tak uz to tak docela docasne neni, a ti lide by meli mit moznost ziskat obcanstvi, protoze po 5 letech jsou de fakto soucasti nasi spolecnosti. Ze sem prijeli dobrovolne atd. je jen trapna vymluva lidi, co chteji delit lidi na podradne a nadradne, IMHO. Jak jinak by sem meli prijet?

[xkucf03]

Ne. Občan státu je ten, o kom řekne zákon, že je občanem státu. A v demokratickém státě mají stávající občané právo rozhodnout, komu povolí stát se členem společnosti (dostat občanství). Když se obě strany (stát a cizinec) dobrovolně dohodnou, že sem ten cizinec smí dvacet let každý rok dojíždět na sezónní práce, nebo tu pracovat X let v kuse, aniž by se stal občanem, tak na tom není absolutně nic špatného a nelze vynucovat (v rozporu s původní dohodou), aby to občanství dostal.

Když budeš mít občanské sdružení, klub, akciovou společnost atd. tak taky o pravidlech přijímání nových členů rozhodují stávající členové. A ať rozhodnou jakkoli, je to legitimní rozhodnutí – i kdyby řekli, že už nepřijmou nikoho dalšího a právo na členství či podíl se bude např. dědit.

[Fluttershy, yay!]

Občan státu je ten, o kom řekne zákon, že je občanem státu.

To platí i naopak, tedy na koho se nevztahuje zákonná ochrana (např. právo na spravedlivý proces). Státy takto rozhodují o životě a smrti. Viz též Necropolitics.

V kontextu migrace viz také např. The Tragic Story of Jimmy Aldaoud, Deported From the Streets of Detroit to His Death in Iraq.

Before he was deported, Jimmy Aldaoud had never stepped foot in Iraq. Born in Greece to Iraqi refugee parents, he immigrated to the United States with his family via a refugee resettlement program 40 years ago, when he was just 15 months old. He considered himself American and knew hardly anything of Iraqi society. Still, on the afternoon of June 4, he found himself wandering the arrivals terminal of Al Najaf International Airport, about 100 miles south of Baghdad, with around $50, some insulin for his diabetes, and the clothes on his back.

[kralyk z abclinuxu]

das pracovne povolenie. robotnik, alebo odbornik si moze priviest najblizsiu rodinu(deti, zena(jedna), manzel). skonci kontrakt, ide domov. kludne tu moze mat job cele roky. najlepsie by bolo, ak by po patdesiatke museli ist domov bez pardonu.

Ok, a přesídlit někam natrvalo by teda bylo zakázané nebo nějak povolené?

[xxxs]

ak si ho nechas, tak okradnes krajinu jeho povodu. odliv mozgov ju poskodi. preto som navrhoval tu 50. to zostava este tak 15 rokov produktivneho zivota. vrati sa domov s peniazmi a know how. moze nieco doma rozbehnut a pomoct svojmu okoliu. to je podla mna viac fair ako si ho naturalizovat. zaroven motivujes pracovitych, aby pracovali.

[Fluttershy, yay!]

ak si ho nechas, tak okradnes krajinu jeho povodu

Už ten koncept je bizarní a popírá autonomii jednotlivce, ale dejme tomu…

preto som navrhoval tu 50. to zostava este tak 15 rokov produktivneho zivota. vrati sa domov s peniazmi a know how

Vedle je tu jmenovaný sběr ovoce a zeleniny.

Když pomineme, že mnoho gastarbeiterů průběžně posílá finance domů, tak v 50 na tom pravděpodobně nebude úplně zdravotně nejlépe a o našetřené sumě mám taky pochybnosti.

pomoct svojmu okoliu

Protože v místě, kde člověk zrovna žije a pracuje, si určitě žádné vazby nevytváří – a pak je jen tak opustí.

zaroven motivujes pracovitych, aby pracovali

Když se vrátím k té zelenině, tak místní jsou asi samá nemakačenka.

[xkucf03]

ak si ho nechas, tak okradnes krajinu jeho povodu

Už ten koncept je bizarní a popírá autonomii jednotlivce, ale dejme tomu…

Vadí ti, když velká firma přetáhne lidi menším firmám a tím zlikviduje konkurenci? Nebo když se dvě velké firmy spojí, aby vytvořili ještě větší a bylo těžší jim konkurovat? Neobšťastňuješ nás tu pravidelně teoriemi o koncentraci bohatství a návrhy, že je potřeba omezit práva lidí, aby se tomu zabránilo?

[Fluttershy, yay!]

Korporace jsou lidi?

[xxxs]

ak by sme riesili neodborny personal, tak si tu moze zarobit viac ako doma*. to, ze posle baksis rodine, aby bol king je v pohode. zlepsi fitness celej rodiny. nemusi predsa poslat vsetko, ak nie je dement. a ked bude stary, mozno ho bude zivit jeho synovec podobnym sposobom. alebo potom uz nebude fungovat pribezne zasielanie financii domov?

*ak nie, tak naco by sa snazil ziskat pracovne povolenie?

[Fluttershy, yay!]

O tom jsou ekonomické studie, jak to v reálu vypadá. Co si tak vzpomínám, je docela konsenzus na tom, že migrace je oboustranně prospěšná. BTW např. Mexičani se z USA skutečně vraceli.

Na druhé straně, kdyby si tady někteří tady poslechli, co říká třeba Mark Blyth mj. o EU, asi by jim explodovaly hlavy.

[JS1]

Marka mam rad, co rika o EU?

[Fluttershy, yay!]

Na TyTrubko je spousta debat s ním o brexitu. Tebe to asi nepřekvapí, ale jedince, kteří mají plná ústa „eurosojuzu“, pravděpodobně docela jo.

[kralyk z abclinuxu]

ak si ho nechas, tak okradnes krajinu jeho povodu. odliv mozgov ju poskodi. preto som navrhoval tu 50. to zostava este tak 15 rokov produktivneho zivota.

Vesměš víceméně souhlasim s tim, co tu píšeš, teda kromě tohohle - IMO by lidi měli mít možnost se někam přesunout natrvalo, např. skrz proces získání občanství (což klidně může mít nějaký podmínky).

Akorát si furt nemyslim, že by problém byl v multikulturalismu. Prostě jde akorát o pravidla imigrační a sociální politiky. Pokud jsou ta pravidla dobře nastavená, IMO to naopak multikulturalismus umožňuje.

Koneckonců, to, co mají třeba v Belgii nebo v Německu nebo jiných státech EU není multukulturalismus, to jsou ghetta a paralelní společnost.

[xxxs]

trvaly pobyt/obcianstvo cisto teoriticky ano, len potom treba davat naozaj pozor, aby sa to nezvrhlo. ked nastavis uzky vyber, tak v podstate zase harvestujes tych chytrych, takze nakoniec krajinu povodu poskodis.

[Jendа]

Já se obávám, že nějak nevidím to, že krajině, která je politicky FUBAR, pomůže vrácení padesátiletého vývojáře.

[xxxs]

napr. moze ucit, vyvijat soft pre statnu spravu, podnikat a dat robotu inym.

[Jendа]

Extrémní příklad: Nejlepší Korea. Nevím, fakt to pomůže? Doufáš, že nakazí „západními“ memy ostatní?

[xxxs]

severna? ak ho pustia, preco by sa nemohol vratit a pomoct? robotnik prinesie statu a rodine viac penazi ako keby zostal doma. odbornik sa nieco nauci a odovzda doma. kde je problem? za sociku sa obcas aj od nas takto niekto dostal von.

ak ho nepustia a pride, tak je to utecenec. skutocny utecenec, lebo zdrha z krajiny z ktorej mu nedovolia vycestovat.

[Jendа]

ak ho pustia, preco by sa nemohol vratit a pomoct?

wtf, vždyť jsi to před chvílí říkal opačně: ty ho chceš naopak do té Severní Korei deportovat.

kde je problem?

V tom, že scénář:

• Odejdu do zahraničí a budu tam opravdu užitečným člověkem.
• Mezitím se z ČR stane Severní Korea.
• V 50 letech mě sem povinně vrátí.

se mi jednak nelíbí osobně (ty jsi s tím fakt OK?), jednak mi není jasné, proč je tato situace obecně lepší, než kdybych zůstal v tom zahraničí.

[xxxs]

ked ho deportujem, tak sa tam vrati. nie? a de facto ho nechcem deportovat, chcem aby dodrzal kontrakt a odisiel sam. ak nie, potom ho chcem deportovat.

"Mezitím se z ČR stane Severní Korea." - toto je podla mna zaklad sporu medzi mnou a tebou + kopou milych a pozitivnych ludi. nerozlisuje sa utecenec a migrant. je kurva rozdiel, ked sa zdrha z diktatury a clovek by mohol dostat statut utecenca - ak je to unosne pre hostitela a ked iba tiahne za lahsim zivotom.

[xkucf03]

Tohle je podle mého cesta, jak jim pomoci. V první řadě neomezovat mezinárodní obchod a taky jim nabídnout třeba studijní pobyty nebo stáže (tzn. dočasné pobyty, kde se ten Korejec po předem definované době vrátí zpátky). Oni sami pak přijdou na to, že tržní hospodářství je pro ně lepší než plánované. A je lepší, když na to přijdou sami, než když jim to bude někdo nutit zvenčí a terorizovat je sankcemi (ty akorát zakládají na výmluvy typu: „daří se nám špatně kvůli sankcím, ne kvůli tomu, že tu máme socialismus“).

[xxxs]

a este k multikulti.

ono sa to naozaj casto zamiena aj(hlavne?) propagatormi.

a preco geta? to je to iste ako na slovenskej dedine. babky si budu odpluvat a ohovarat, lebo nechodis do kostola. tlak jak hovado. teraz pride moslim s celou rodinou, pride viac rodin a sme niekde uplne inde. tlak je uplne sialeny. cim viac pride naraz, tym je geto nevyhnutelnejsie - okolie ich proste nepusti. malo kto je dost silny na to, aby ostatnych vyslovene poslal do pice.

[kralyk z abclinuxu]

ono sa to naozaj casto zamiena aj(hlavne?) propagatormi.

Jo, s tim souhlasim...

[Bherzet]

Za sebe s imigrací natrvalo nemám problém, ale chci, aby imigrační politika byla konzervativní, tj. probíhala v malém počtu a na imigranty byly kladeny relativně vysoké nároky. Nechci, aby se tu prostředí nějak výrazně měnilo (vč. toho, jací lidé se tu pohybují, jak vypadají a jak se chovají), a na tuto svou preferenci mám výsostné právo. Kdybych zítra vyšel na ulici a každý druhý člověk byl černoch, asi bych se za pár týdnů až měsíců adaptoval a začal být schopný aspoň rozpoznávat jejich obličeje, ale i tak bych si asi občas nostalgicky posteskl, že prostředí, do kterého jsem se narodil, je prostě pryč a nemám možnost se do něj vrátit ani na okamžik na návštěvu. Starší lidi se nemusí být schopni adaptovat vůbec. A to předpokládám jen vizuální změnu, v praxi se toho mění mnohem víc (řeč/i, architektura, strava, zvyklosti, …).

Malá míra otevřenosti je naopak ku prospěchu a dlužno podotknout, že pokud se stavidla nezliberalizují do poměrně absurdních výšin, tak pesimistický scénář jako jsem naznačil fakt nehrozí (resp. nestane se to ze dne na den). Takže bych dal příležitost víceméně komukoliv, kdo projeví trochu snahy sem zapadnout, a pokud se osvědčí, dal bych mu trvalý pobyt. Ale to je můj názor; IMHO by se mělo v každém roce rozhodnout referendem kolik lidí přijmout a ať se každý vyjádří podle svého cítění tam. Konfrontovat potom na ulici lidi, kteří sem přijeli legálně, je ubohé, debilní a nebezpečné.

[Fluttershy, yay!]

A to předpokládám jen vizuální změnu, v praxi se toho mění mnohem víc (řeč/i, architektura, strava, zvyklosti, …).

„Já bych všechny ty internety a počítače zakázala.“

Starší lidi se nemusí být schopni adaptovat vůbec.

Nebo takové (ne)spalování fosilních paliv, že?

(Ty desítky milionů uprchlíků se ostatně nevzaly odnikud.)

[Bherzet]

„Já bych všechny ty internety a počítače zakázala.“

Tak je to taky stupidní, ale legitimní názor.

Já jsem liberální v dalších ohledech a jsem liberální i v tom, kdo se tu bude pohybovat po ulicích, pokud bude dodržovat pravidla. U našinců tuto podmínku uplatnit nemůžeme, leda vězením. A protože u cizinců nemůžeš předpokládat ani absolvování naší základní školy nebo ekvivalentního vzdělání a průpravy a výchovy, je logické tlačit na přísnější pravidla, resp. větší ochotu se uzpůsobit, čímž se ty rozdíly částečně vykompenzují.

(Ty desítky milionů uprchlíků se ostatně nevzaly odnikud.)

Asi by šlo diskutovat o tom, jak jim kompenzovat škody, které jim naše emise prokazatelně způsobily. Ale jednoznačný názor na to nemám: nebyl to úmyslný útok, od průmyslové revoluce někdy do minimálně ~70. let minulého století se o těch negativních dopadech vůbec nevědělo a oni proti tomu AFAIK v té době taky nijak neprotestovali. Takže je to spíš o nějaké naší dobré vůli než retroaktivním hledání viníka za zdánlivě nevinnou věc (spalování fosílií), kterou dělal každý, kdo mohl, a dělají ji samozřejmě i oni, byť míň, protože na to nemají peníze.

[Fluttershy, yay!]

A protože u cizinců nemůžeš předpokládat ani absolvování naší základní školy nebo ekvivalentního vzdělání a průpravy a výchovy, je logické tlačit na přísnější pravidla, resp. větší ochotu se uzpůsobit, čímž se ty rozdíly částečně vykompenzují.

Cílem základní školy je indoktrinace a konformismus?

od průmyslové revoluce někdy do minimálně ~70. let minulého století se o těch negativních dopadech vůbec nevědělo

Není pravda. Kromě toho, že skleníkový efekt byl popsán v 19. století…

Znáš třeba praktický příspěvek Mining Congress Journal, August 1966 – Air Pollution and the Coal Industry?

oni proti tomu AFAIK v té době taky nijak neprotestovali

Koloniální politika 101

[Aleš Kapica]

Cílem základní školy je indoktrinace a konformismus?

A cos myslel? Snad ne to, že by z ní měly vycházet vzdělané a samostatně myslící bytosti?

Proč by tam jinak byly takové předměty jako "Výchova k občanství", "Vlastivěda", "Výchova ke zdraví", "Člověk a svět práce", aj.

[Bherzet]

Cílem základní školy je indoktrinace a konformismus?

Někde děti musíš vychovávat. Jestli se tak děje ve školách nebo v rodinách, což bych preferoval, je z tohoto hlediska jedno. V obou případech je výsledkem společnost, kde je poměrně respektovaným pravidlem např. hlasitě nekrkat a neprdět v restauraci, nebo používat v dopravním prostředku sluchátka místo reproduktoru mobilního telefonu.

Kdyby sem začali hromadně a za velmi nízkých vstupních bariér imigrovat Číňané z horších sociálních poměrů nebo s nižším vzděláním, měli bychom s tím značné problémy.

Domnívám se, že stavět takové věci explicitně mimo zákon, abychom je mohli následně stíhat za jeho porušování, je dost nešťastné (mj. s ohledem na to, jak banální problémy to představuje za stávajícího stavu) a lepší je sem takové lidi na delší časový úsek vůbec nepouštět. Tzn. nutit je prokázat znalosti naší kultury, úctu k ní a ochotu se jí přizpůsobit.

Nevím, koho si ty zveš domů a je mi to upřímně jedno.

Kromě toho, že skleníkový efekt byl popsán v 19. století…

Nicméně se AFAIK nevědělo o tom, že emise skleníkových plynů mohou vést ke globálnímu oteplování tak zásadního rozsahu. Dnešní predikce ostatně vyžadují superpočítače a nesmírně sofistikované modely.

Znáš třeba praktický příspěvek Mining Congress Journal, August 1966 – Air Pollution and the Coal Industry?

To je o neuvěřitelné čtyři roky dříve než ~70. léta, která jsem (vč. té tildy) uváděl já.

[Fluttershy, yay!]

používat v dopravním prostředku sluchátka místo reproduktoru mobilního telefonu

To je funkce empatie. Ano, částečně naučená – pobytem ve společnosti.

(Ještě před pár generacemi nebylo mobilních sluchátek.)

Nicméně se AFAIK nevědělo o tom, že emise skleníkových plynů mohou vést ke globálnímu oteplování tak zásadního rozsahu. Dnešní predikce ostatně vyžadují superpočítače a nesmírně sofistikované modely.

Na přelomu století to bylo publikováno. Že se tyhle záležitosti nedostaly jako faktor do rozhodovacího procesu, to je druhá věc. Na to si bylo nutné počkat na Silent Spring atd.

To je o neuvěřitelné čtyři roky dříve než ~70. léta, která jsem (vč. té tildy) uváděl já.

IOWs před více než 50 lety.

Kdy tedy lidé z těchto generací vezmou realitu na vědomí?

[JiK]

Zvlastni, ze si Barrack Obama koupil za 12 milionu dolaru milionarskou usedlost v Martha's Vineyard, na pobrezi, ve vyscce 14 cm nad morem. Asi ma lepsi informace nez Fluttershy, yay!

[Fluttershy, yay!]

Co by sis bez toho Obamy počal?

Je to prostě další bohatý liberál. Jako Trudeau – fotí se s Gretou, zatímco staví ropovod.

[Aleš Kapica]

Kdyby sem začali hromadně a za velmi nízkých vstupních bariér imigrovat Číňané z horších sociálních poměrů nebo s nižším vzděláním, měli bychom s tím značné problémy.

Číňané to sice nejsou, ale 152 tisíc je dost na to, aby s nima jednou byly problémy taky. Tu jejich živelnou temperamentnost, jsme už mnozí měli možnost zažít na vlastní kůži. Třeba na Volyni.

[Bherzet]

Osobne jeste prekousnu, ze z dani platim studium kolibacovi, dadovu kycelni endoprotezu a kapicovy blogposty v pracovni dobe, ale naprosto odmitam prispivat na jidlo, bydleni a zdravotni peci imigrantu. To mne trosku desi v kontextu s tim, ze na vecny prispevek reagujes vulgarnostmi.

[Fluttershy, yay!]

Zapomněl sis přepnout účty.

[xxxs]

zamrzi.

[Bherzet]

Ne, jen double-checkuju. Člověk si pár nicků zapamatuje, tak by poznal, že něco nesedí. Bot ne. Ale kdo ví, protože naprogramovat tohle mi pořád hlava nebere.

[xxxs]

nie je to bot. ak tam nieco je, tak v malej miere.

[Jendа]

A jak si vysvětluješ #619?

[xxxs]

3 dni cakacka na odpoved? vacsinou odpoveda skor a zrazu na pascu odpovie v sulade s jej zamerom, ale nezvycajne neskoro. myslis, ze to potreboval strojovo prechrumat? nezda sa mi to. vela zvlastnych reakcii sa da vysvetlit mechanizmami ochrany osobnosti.

[Aleš Kapica]

To by mě fakt zajímalo, co ti na tom přišlo vulgární.

A mimochodem TY mě neplatíš, o mé pracovní době a její náplni nevíš ani zbla, tak že ti může šumák kdy a co píšu.

[trekker.dk]

Jste placen z daní (pokusy vykroutit se z toho přes granty a podobné argumenty typu "jiná kapsa" na tom nic nemění.) Takže ano, je vcelku oprávněné, když plátce těch daní má zájem na tom, abyste se v pracovní době neflákal.

[Aleš Kapica]

Už se to tu probíralo několikrát. Jste mimoň. Podle vašich kritérií se mi jevíte jako daňová vyžírka vy.

[vencour]

Dokud budou lidi žasnout, pozitivně, tak je naděje ... co třeba tohle (Daniel Stach - Jak myslí velikáni | Neurazitelny.cz | Večery na FF UK).
No a drobnost, jasně, že je fajn, když člověk umí napsat 10 odstavců. A mně se líbí, když tu samou myšlenku řeknu, dejme tomu, v pěti větách. Ale to asi neni taková zábava ... ani pro mne to dávat dohromady ani pro ostatní, protože to přečtou moc rychle a nenaladí je to. Vlastně jo, pak je ta moje myšlenka moc slabá, když to s nima nic neudělá. Taky postřeh.