Simulátor bystroushaakovho nezmyslu 2, tentokrát s videom.

28.12.2018 23:47 | Přečteno: 3445× | Žumpa | poslední úprava: 30.12.2018 16:50

Otvoril som Slivku, editor, prehliadač, zapol debugger a začal písať. Asi vyššie sily chceli, že by som dnes nič užitočnejšie nevytvoril. Vo vídeu nájdete osvetletnenie ako si to predstavujem, ukážka funkčného kódu a pár kecov okolo.

Online verziu nájdete tu. Sú tam len dva príkazy, uname a date. napíšete napr. uname a ten vám pošle objekt, s ním si môžete hrať cez príkaz ret. Vídeo má sedem minút, tam nájdete postup ako to funguje.

Zdrojáky sú tu, nie je to žiadna krása, proste proof of concept. Ťažko povedať, koľko budem ešte online, ale podte do mňa

>>> VIDEO <<<        

Komentáře

[_]

Proč mají objekty typ pole?

Např.

[Bedňa]

Pretože každý jazyk musí musí niečo pokašľať. V JavaScripte sú to premenné a je s tým dosť problém, keď oficiálny nástroj typeof nevracia relevantné údaje.

Dosť dobrý článok nie len o tom, nájdeš tu.

Vysporiadal som sa s tým podobne ako autor článok, len som si to trochu upravil:

function varType (obj) {
    var clas = Object.prototype.toString.call (obj).slice (8, -1);
    return clas;
}

Proste vraciam si priamo názov typu a na základe toho sa rozhodnem, čo s týmm ďalej. On tam vkladá typ a funkcia mu vracia TRUE/FALSE.

[_]

Prasárna. Array je objekt, proto typeof vrací string "object". Žádná chyba jazyka. A co takhle operátor instanceof? Slyšel jsi o něm? Miluju když si "expert" nenastuduje pořádně jazyk a pak dělá svoje "fixy špatného chování jazyka" a výsledkem je sračka.

[Bedňa]

Nech je to pole jednorozmerná, alebo viac rozmerné, stále je to pole.

Kámo kľud, toto sú hádky ktoré nikam nevedú, je to len názov, tak sa z toho nepicnem.

[Bedňa]

A somozrjme viem ako sa spávajú objekty v JavaScripte a ostatných veciach okolo objektov, nie len v JavaScripte.

[_]

Javascript je sracka sama o sobe, neni treba s nim nic delat

[_]

Ok, to do jisté míry chápu, ale vážně je to prasárna, jak říkal předřečník, pakliže někdo ten jazyk už zná - tzn. 99.9999% cílové skupiny.

Co budeš dělat, až budeš chtít ty nebo 3d-party aplikace vrátit skutečné pole? Např. seznam procesů. Budeš se z toho snažit za každou cenu vytvořit nějaký hash {PID1: {}, PID2: {}} namísto [{pid: PID1},{pid:PID2}]? Nebo půjdeš cestou PHP a pole implementuješ něco jako typ ArrayButThisTimeForReal

Pakliže ke všemu _ručně_ přiřazuješ typ, tak co vrací typeof či jiná tvá implementace tě snad nemusí vůbec zajímat, ne? Proč dělat práci dvakrát?

[_]

Nehledě na to, že kdybys ten typ generoval automaticky, tak ti varType() vyhodí Object a ne Array. No nevím, první věc, na kterou jsem kouknul, a jsem z toho dost znechucený. Volnost návrhu ti neberu, ale .. fujky.

[Bedňa]

OK berem, proste keď sa toho ešte niekedy chytím, je možné že to zmením. Ja som to myslel trochu inak, ako nápovedu pre užívateľa, že cca čo tam je, ale možno je to békovina.

[Bedňa]

Pokiaľ si to myslel, prečo je to u mňa pole, tak pretože to je fakt len pole dát, objektom by som to nenazýval.

[aaa]

Nie je to "len pole dát", napríklad má pribalené aj metódy, takže je to objekt aj keď ty by si to tak nenazýval, typeof funguje správne.

[Bedňa]

To "Array" patrí čiste k dátam aby si vedel približne čo dostaneš a dostaneš viacrozmené asociatívne pole ktoré je vložené do objektu. Takže objekt samotný je objekt.

[JS1]

Uz jsem to chtel zminit driv, ale ten Bystroushaakuv vynalez ma (proti Unixu) jeden zasadni nedostatek.

Vezmeme si treba klasicke "ls" jako priklad. V tom novem systemu mi "ls" proste vrati seznam objektu, dobra. Jenze kdyz ho pak budu chtit zobrazit uzivateli nejak rozumne (jako to dela klasicke ls), budu potrebovat novy prikaz, nejake ls-fmt, ktere z toho seznamu objektu, co vrati (specificky) ls, vyrobi citelny smysluplny text, ktery obsahuje informace, ktere hledam (napriklad casto lide pouzivali trideni podle data zmeny).

Takze vsude, kde jsme meli jeden prikaz - neco zjisti a nejak to vypis, ted budeme mit minimalne dva prikazy, jeden to zjisti a vyrobi z toho strukturu a druhy tu strukturu (kterou musi znat) nejak zformatuje, jak bychom asi chteli (jako lide).

Nehlede k tomu, mozna by bylo dobre i parametry tem prikazum predavat jako strukturu... a tudiz pak potrebujeme jeste treti sadu prikazu.

Ono to svym zpusobem souvisi s koncepci Model-View-Cokoliv, s kterou prisel taky myslim Smalltalk a je vlastne trochu divna, protoze jde trochu proti OOP. Protoze kazdy View musi casto tak nejak znat Model, a tim mezi nimi existuje vazba, nejsou to uplne samostatne objekty. A to neresime, co je vlastne to Cokoliv.. Nekdy se tam dava ViewModel, coz je neco jako urcity na zarizeni nezavisly report z Modelu, ktery pak zobrazuje View.

Takze pak ve finale, misto "ls -l /usr" bude clovek psat "path-arg "/usr" | ls | ls-fmt -l | display-stdout" nebo neco podobne hruzneho. Kdyz si k tomu uvedomime, ze je to opravdu jen skladani funkci, pak cele to OOP prestava IMHO davat velky smysl, a mozna by proste stacilo mit nejaky funkcionalni jazyk jako shell. (On Forth, stejne jako Lisp, k tomu ma blizko, ale tak trochu podivne. Ale na eleganci lambda kalkulu to nema.)

[Fluttershy, yay!]

Stejně se implicitně předpokládá, že prostředí interpretuje to, co přistane na standardním výstupu (barvičky, zvoneček,…). Tož tak ještě přihodí změnu formátování.

[JS1]

No jo, ale to neresi ten problem treba s tridenim podle data.. Jasne, mohl by existovat dotazovaci jazyk, kterym se to ztransformuje, jenze tim uz se zase dostavame k tomu Vietnamu pocitacove vedy.

[Bedňa]

Ty, alebo systém dostane celý objekt aj s metodami na prácu s dátami. Takže keď bude štandardizovaná metóda object.get(), tak nič ďalšie nepotrebuješ.

[JS1]

Nevim, jestli ti moc rozumim, ale zda se mi, ze rikas, ze vsechny (typicke) reporty nad tim vystupem budou soucasti toho objektu?

[kralyk z abclinuxu]

Pokud by daný jazyk / prostředí podporovalo interfaces / traits / něco na ten způsob, tak by vrácený objekt mohl implementovat interface/trait pro konzolový výstup. Něco jako má Rust Display trait.

[JS1]

Ano, to je neco jako ma Haskell typovou tridu Show. Ale v podstate je to jen funkce s urcitou typovou signaturou.

Zajimavejsi otazka je, jaky ma byt typ toho vystupu. V Haskellu je mozne definovat typovy alias, coz dava moznost s tim vystupnim typem dale pracovat pomoci generickych funkci. V OOP se vetsinou vystup definuje jako zcela novy typ, coz tuhle prirozenou moznost dost omezuje.

[kralyk z abclinuxu]

Jo, type classes, přesně tak.

Zajimavejsi otazka je, jaky ma byt typ toho vystupu.

Tak asi nejlépe použít existenciální typ, tj. shellu by mělo být jedno, co to je za typ, dokud je schopen ho zobrazit.

V OOP se vetsinou vystup definuje jako zcela novy typ, coz tuhle prirozenou moznost dost omezuje.

OOP je na tohle z mého pohledu blbé, zbytečně omezující.

[deda.jabko]

OOP je na tohle z mého pohledu blbé, zbytečně omezující.

Mne ta idea objektovosti (v tomto kontextu) nedava prilis smysl uz z principu. Kdyz si vemu, ze zakladem OOP jsou objekty jejichz stav je skryty a zpristupneny pres nejake rozhrani, melo by se primarne resit jake metody budou objekty mit (nebo chce-li nekdo, jake budou akceptovat zpravy). Takove uvazovani ale dava smysl, pokud nekdo navrhuje nejaky uzavreny celek jako je konkretni aplikace, treba informacni system, protoze to samo poskytuje kontext, ve kterem dava smysl urcit jednotlivym objektum jejich (vychozi) chovani.

Pokud chce nekdo vytvaret otevreny system, tj. system, ktery bude umoznovat resit ulohy, ktere autori systemu nepredpokladali, coz by operacni system mel splnovat, tak takovy kontext chybi. V takovem pripade dava mnohem vetsi smysl mit data (klidne strukturovana) a pak funkce provadejici transformace techto dat. Funkcionalni pristup, jak navrhuje JS, dava (dle meho) mnohem vetsi smysl.

Vzhledem k tomu, ze v tech predeslych diskuzich se mnohem vic resila struktura dat, nez problematika metod, myslim, ze ti, co by chteli nejaky ten OOP OS (jak se o nem v tomto kontextu mluvi), chteji jen strukturovany vstup/vystup a operace pracujici s temito vstupy. Coz ma teda fakticky mnohem bliz k funkcionalnimu nebo proceduralnimu programovani nez k OOP.

Jeste poznamka pod carou. Pokud by OS poskytoval API pro funkcionalni pristup ke svym sluzbam, bylo by vcelku primocare zavest transakce a vyresit tak celou velkou kategorii problemu, ktere dnesni OS maji. Ale kvuli dopadu na vykon si myslim, ze to je hodne nerealisticka predstava.

[xkucf03]

Mně by přišlo zajímavé mít objektové API k OS. Např. bych si vyžádal seznam USB zařízení a to by byly objekty a na nich bych mohl volat nějaké metody. Nebo seznam připojených souborových systémů, seznam procesů atd. Nebo možnost otevřít si soubor jako objekt a zapisovat do něj voláním metod, nikoli funkcí. Protože to současné API postavené na funkcích jazyka C je přeci jen hodně nízkoúrovňové a z dnešního pohledu nepohodlné.

Ovšem mít objektové API ještě neznamená, že ten objekt, který mi to vrátí, musí být ten samý objekt, jako vrátí tatáž metoda někomu jinému, a že oba musí být spravované jedním GC, který bude hlídat, kolik referencí si na ten objekt někdo drží. Ten objekt může ve skutečnosti existovat jen uvnitř mého procesu (tzn. není sdílený s jinými procesy a s OS) a fungovat jako proxy, která zprostředkovává komunikaci s OS.

[deda.jabko]

Mně by přišlo zajímavé mít objektové API k OS

V takovem pripade doporucuji vyzkouset Windows NT, ty maji objektove API.

Protože to současné API postavené na funkcích jazyka C je přeci jen hodně nízkoúrovňové a z dnešního pohledu nepohodlné.

To je docela zadana vlasnost, pokud chces mit system, ktery lze prizpusobovat ruznym potrebam, napr. ruznym programovacim jazykum.

Mně by přišlo zajímavé mít objektové API k OS

A jaky by to melo prinos? Jediny prinos to bude mit v podobe pohodlnejsiho rozhrani pro programatora, coz je ale dnes resitelne pomoci ruznych objektovych bindingu.

Vedle toho funkcionalni rozhrani s podporou transakci by potencialne resilo obri mnozstvi problemu jako jsou chyby soubehu. Ale vzhledem k tomu, jak i (relativne) drobna rezie, kterou maji mikrojadra, je schopna zabit jejich prakticke nasazeni, je to jen velice utopicka predstava.

[xkucf03]

Jediny prinos to bude mit v podobe pohodlnejsiho rozhrani pro programatora, coz je ale dnes resitelne pomoci ruznych objektovych bindingu.

Ano, to mám vlastně na mysli. Akorát by se jednalo o objektový model definovaný v nějakém standardu, který by byl implementovaný v různých OOP jazycích.

V kontextu GraalVM nebo Bystroushaakových vizí to není nereálné. Akorát by ten objekt nemusel být jen jeden uložený centrálně v paměti a spravovaný jedním centrálním GC, ale mohla by to být jen nějaká proxy, která komunikuje s OS, ale její objekt je spravovaný GC daného procesu. Což je výrazně jednodušší a bezpečnější.

Synchronizace/transakčnost je IMHO řešitelná jak v OOP, tak ve FP.

[kralyk z abclinuxu]

ale mohla by to být jen nějaká proxy

Ano, takhle to bylo v tom Solarisu, jak píšu níže. Typicky ses nejdříve připojil, tím jsi dostal objekt reprezentující spojení, ten jsi požádal o modul (třeba správce uživatelů) a ten jsi požádal o nějaký resource (třeba uživatele). Nazpět jsi dostal proxy-objekt (nebo kolekci), který např. při zavolání metody na pozadí provedl po síti RPC žádost na server a vrátil výsledek.

[deda.jabko]

V kontextu GraalVM nebo Bystroushaakových vizí to není nereálné

Ono je to realne i bez GraalVM a Bystroushakovych vizi. A rekl bych, ze je to realne trivialne, jenom si sednout a neco takoveho naprogramovat, neni v tom zadny komplikovany problem, ...

[xkucf03]

Šlo mi o to, jak to napasovat na různá pojetí OOP v jednotlivých jazycích -- ale když to zvládá GraalVM nebo ta Bystroushaakova vize, tak by to jít mělo :-)

[kralyk z abclinuxu]

A jaky by to melo prinos?

Automatizovaná / programatická manažovatelnost / konfigurovatelnost.

Přesně z toho důvodu to měl Solaris, bylo to modulární / objektové API k různým částem systému, jako třeba správa ZFS volumů, zón, boot environmentů, services apod. Poskytovalo to bindingy pro C, Python a Javu a taky se s tim dalo interagovat přes HTTP/REST. Takže jsi mohl třeba napsat Python skript, který se připojil na nějaké stroje a třeba na nich programaticky nabootoval zónu nebo povolil service nebo něco takového, aniž bys musel lézt přes SSH a parsovat výstup nějakých utilit.

Taky si do toho člověk mohl psát vlastní moduly v Pythonu nebo v C a vytvářet si tak vlastní API.

Taky to mělo ke konci* nějakou vestavěnou dokumentaci / něco jako HATEOAS, takže ses mohl připojit browserem a 'prohlížet' API.

*) Celá ta věc nebyla úplně dotažená a měla svoje historickým vývojem daná omezení, ale bylo to docela zajímavé a IMHO docela pokrokové. Snažili jsme se to co nejvíce dotáhnout, ale ultimátně Oracle ohledně Solarisu rozhodl tak jak rozhodl. Nenaděláš nic.

AFAIK na Linuxu podobné věci řeší třeba Puppet, ale není to úplně ono.

Jenom ještě poznámka k tomu OOP: IMHO se v tomhle případě o OOP v pravém slova smyslu nejedná. Bylo to sice uděláno tak, že člověk přístupoval k 'objektům' na kterých volal 'metody', ale neuplatňují se tam principy OOP jako v programování jako např. dědičnost, polymorphismus a podobně. Spíše bych tomu řekl pouze "struktury s metodami".

[xkucf03]

AFAIK na Linuxu podobné věci řeší třeba Puppet, ale není to úplně ono.

A co D-Bus?

[kralyk z abclinuxu]

Jo, D-Bus je podobný, nicméně tohle bylo primárně určeno na vzdálenou správu a D-Bus jako IPC, ačkoli oboje jde používat i tím druhým způsobem. D-Bus mi v porovnání přijde jako mnohem větší anarchie a pokud vím, ta odpovídající API na Linuxu ani neexistují, spíš se to AFAIK používá na desktopový věci.

Principielně by to ale asi šlo použít obdobně.

[deda.jabko]

Automatizovaná / programatická manažovatelnost / konfigurovatelnost.

Ok. Ale porad v tom nevidim nejaky zasadni zmenu/prinos, ktera by pred tim nebyla vubec dosazitelna. Vsechno, co chce uzivatel xkucf nebo se tobe libi na Solarisu, je realne dosazitelne i na linuxu, jen to k tomu chce napsat rozhrani.

[kralyk z abclinuxu]

Jasně, však já v tom nevidim nějaký zásadní posun nebo něco normálně nedosažitelného. A co se týče Solarisu, je to pro mě v této chvíli už spíš záležitost nostalgie...

[JS1]

Pokud by OS poskytoval API pro funkcionalni pristup ke svym sluzbam, bylo by vcelku primocare zavest transakce a vyresit tak celou velkou kategorii problemu, ktere dnesni OS maji. Ale kvuli dopadu na vykon si myslim, ze to je hodne nerealisticka predstava.

To by me docela zajimalo, muzes to nejak rozvest? Myslis neco jako transactional memory, treba? Dnes jsou i HW implementace.

Kde je ale potiz s transakcemi, treba u sitovych zarizeni. Pokud jednou posles paket, tezko se to vraci zpatky..

[xkucf03]

Zrovna u těch síťových operací by data mohla čekat ve frontě a odeslala by se až po dokončení transakce. Případně bys udělal ROLLBACK a z fronty by se zprávy odstranily. Ty by sis pak musel vybrat, jestli chceš data poslat až po COMMITu, nebo jestli danou síťovou operaci provedeš v autonomní transakci a data se odešlou hned.

Např. si dovedu představit, že kdybych měl druhé straně odpovědět, že jsem data přijal a zpracoval, tak bych udělal zápis na disk i odeslání potvrzovacího paketu v jedné transakci a víc bych to neřešil -- OS by se postaral o to, že proběhnou buď obě operace nebo ani jedna. I když je otázka, jestli tohle je úloha pro OS nebo pro nějaký framework...

Do toho ale ještě vstupuje fakt, že data se můžou ztratit cestou po síti, nebo třeba cílový systém bude mít zrovna výpadek napájení a data k němu sice dorazí, ale už se nezpracují. Tady je otázka, kam až ty transakce chceš hnát a jestli mají být distribuované.

[Heron]

Případně bys udělal ROLLBACK a z fronty by se zprávy odstranily. Ty by sis pak musel vybrat, jestli chceš data poslat až po COMMITu, nebo jestli danou síťovou operaci provedeš v autonomní transakci a data se odešlou hned.

Od toho jsou prepared transactions.

I když je otázka, jestli tohle je úloha pro OS nebo pro nějaký framework...

JJ a přesně k tomu to v tom pg je, aby se nad tím postavil nějaký framework.

[xkucf03]

Od toho jsou prepared transactions.

To je dvou-fázový COMMIT. Autonomní transakce je něco jiného -- ta se provede vždy, nezávisle na té vnější transakci. Používá se to např. pro logování, kdy chceš mít průběh procesu zalogovaný i v případě, že někde dojde k chybě a nakonec se udělá ROLLBACK.

Stejně tak u té síťové komunikace -- něco budeš chtít odeslat hned a netransakčně, zatímco u jiné komunikace využiješ distribuovanou transakci.

Nicméně tohle je už poměrně dost komplexní problematika (ty distribuované transakce), u které mi přijde, že by se měla řešit spíš na vyšších úrovních než je OS.

[deda.jabko]

Muzes vyjit z toho, ze zavest transakce nad souborovym systemem neni problem (ma to v nejake forme treba NTFS). Dale muzes vyjit z toho, ze souborovy system muze fungovat jako rozhrani k operacnimu systemu, prikladem budiz unix/plan9. Kdyz tyto dve veci spojis, dostanes reseni cele rady problemu v user space, zbavis se velkeho mnozstvi race conditions, ruznych zamykani, cela rada aplikaci se muze zjednodusit, protoze ziskas atomickou praci s FS, ktera bude transparentni vuci vsem procesum. Vse to jenom tim, ze vsechny zmeny budou ostatnim viditelne az po provedeni commitu.

Kde je ale potiz s transakcemi, treba u sitovych zarizeni. Pokud jednou posles paket, tezko se to vraci zpatky..

Se vstupy a vystupy je u transakci problem vzdycky. Tech reseni muze byt vic, treba zminene pripravene transakce (resp. dvoufazovy commit) nebo explicitni rizeni, jak to ma Haskell. Nebo k tomu muzes pristoupit inzenyrsky a resit ad hoc jen konkretni problematicke pripady... v tom nemam prilis jasno.

Myslis neco jako transactional memory, treba? Dnes jsou i HW implementace.

To zatim vidim jako takove krucky do neznama, jak by to mohlo fungovat, ale myslim, ze ty rozsireni jdou dobrym smerem... no vlastne, ... kdyz jsem loni v rijnu porizoval novy pocitac, byla to tezka volba mezi AMD RyZEN a Intelem. Nakonec jsem si vybral Intel kvuli lepsim rozsirenim ISA a konecne funkcni podpore transakcni pameti, abych si mel s cim hrat. Za odmenu mam diky te transakcni pameti nekolikanasobne rychlejsi Meltdown. ;-]

[JS1]

ak asi nejlépe použít existenciální typ, tj. shellu by mělo být jedno, co to je za typ, dokud je schopen ho zobrazit.

Mel jsem spis na mysli to, ze my chceme vedet, ze treba to "ls" vraci seznam veci, abychom je treba mohli tridit standardni tridici funkci. Takze, jak pise deda.jabko, chceme, aby do toho typu bylo videt, na jednu stranu, na druhou stranu to jde dost proti OOP v tom smyslu, ze v OOP bychom vratili uzavreny typ, do ktereho se da vstoupit jen tak, jak to dovoluji jeho metody.

I v Haskellu existuje tenhle rozpor. Muzu definovat typovy alias pomoci "type", coz se nechova jako novy typ z hlediska typecheckeru, coz znamena, ze lze pouzit vsechny standardni funkce pro praci se strukturou puvodnich typu. Ale to ma nevyhodu, ze se nad tim pak neda definovat ta instance typove tridy Show, treba. Muzeme to, alternativne, obalit pomoci "newtype", nad kterym se to Show pak da udelat, ale pokud je vystupem funkci ten obaleny typ, je s tim zase pak vic psani, pokud se chceme dostat dovnitr.

Ono, jelikoz typy hraji v programovani uz dnes tri ruzne role (struktura ulozeni v pameti, dispatch, typova kontrola - vyse uvedeny problem je rozporem mezi poslednimi dvema z nich) a pokud chceme mit navic typy jako objekty, ty maji jeste ctvrtou roli (nahrazuji v jistem smyslu moduly), tak se dostaneme jeste do dalsich problemu. (O tomhle problemu tusim mluvi Gilad Bracha ve sve prednasce "Types are anti-modular".) Pokud vim, tak se dosud nikomu nepodarilo to navrhnout primitiva programovaciho jazyka tak, aby vsechny ctyri vlastnosti byly rozumne uspokojene s minimem kolizi. (Haskell se tomu trochu blizi tim, ze ma "data/type/newtype", ale jejich pouziti neni uplne ortogonalni tem trem rolim, co typy hraji.)

[kralyk z abclinuxu]

Jo, je pravda, že skrývat ten typ asi není potřeba / žádoucí.

Ono stejně asi řešíme kraviny, protože ti, co tady tyhle systémy navrhují (Bystroušák a další) nejsou úplně nadšenci do typových systémů, spíše jsou na dynamické typování, duck typing a prototypy.

[xkucf03]

Mel jsem spis na mysli to, ze my chceme vedet, ze treba to "ls" vraci seznam veci, abychom je treba mohli tridit standardni tridici funkci. Takze, jak pise deda.jabko, chceme, aby do toho typu bylo videt, na jednu stranu, na druhou stranu to jde dost proti OOP v tom smyslu, ze v OOP bychom vratili uzavreny typ, do ktereho se da vstoupit jen tak, jak to dovoluji jeho metody.

Když použiješ JavaBeans (nebo jejich obdobu v jiném jazyce), tak máš všechno zapouzdřené v metodách a zároveň můžeš třídit pomocí standardních funkcí.

[deda.jabko]

Když použiješ JavaBeans (nebo jejich obdobu v jiném jazyce)

IMHO JavaBeans jsou slusny objektovy anti-pattern, ktery se ale natolik rozsiril, ze spouste lidi prijde uplne normalni.

Nejaky smysl dava divat se na JavaBeans jako na formu komponent (coz teda objektove programovani degraduje na proceduralni programovani s objekty, ale budiz).

Pokud to ale chapu spravne, chces, napr. jako vystup ls, posilat JavaBeans, coz mi prijde jako docela zhuverilost a nedava mi to moc smysl, protoze to nejsou ani komponenty, ani objekty, ale v podstate obycejne (o neco lepsi) struktury. Ale o tom jsem uz tu mluvil.

[xkucf03]

Jde o to, že tam, kde ti stačí strukturní pohled na věc (nebo je dokonce preferovaný vzhledem k řešené úloze), k tomu přistupuješ jako ke struktuře (byť to jsou metody, ale mají standardizované názvy, takže nad nimi můžeš např. provádět třídění nebo filtrování pomocí generických nástrojů) a jen tam, kde dává smysl objektový pohled, k tomu přistupuješ objektově.

Osobně mi nevadí ani ten strukturní pohled (výpis ls jakožto sada neživých záznamů), ale pokud s tím chce někdo pracovat objektově, tak není potřeba se vzdávat těch generických operací (viz výše) např. nad těmi názvy nebo velikostmi.

Tzn. tím předchozím komentářem jsem se snažil říct, ne to, že máme věc nutně řešit objektově, ale že ji lze řešit objektově (mít zapouzdření a např. některé hodnoty dopočítávat za chodu) a zároveň to půjde třídit nebo filtrovat.

[deda.jabko]

a jen tam, kde dává smysl objektový pohled, k tomu přistupuješ objektově.

A mne z teto formulace plyne, ze objektovost bude spis takova fetis, ktera vlastne neni ani moc potreba a v rade pripadu nebude davat ani smysl, ale nejak ji tam natlacime, protoze lidi to maji radi...

[xkucf03]

A jak by ses k tomu chtěl postavit jinak? Myslím obecně, ne jen v tomhle případě. Ono totiž mnoho entit, které modelujeme v informačních systémech, jsou ze své podstaty neživé struktury, které nemají chování, a přidávat k nim nějaké metody nemá smysl. Naopak jiné objekty žijící v tom informačním systému mají jak stav, tak chování, a OOP se pro ně hodí. Objektem z pohledu syntaxe jazyka je pak oboje, akorát ty první jsou spíš takové DTO struktury, zatímco ty druhé jsou živé objekty s nějakým netriviálním chováním.

[deda.jabko]

A jak by ses k tomu chtěl postavit jinak?

Uz jsem to sem psal.

[kralyk z abclinuxu]

Osobně mi nevadí ani ten strukturní pohled (výpis ls jakožto sada neživých záznamů), ale pokud s tím chce někdo pracovat objektově, tak není potřeba se vzdávat těch generických operací (viz výše) např. nad těmi názvy nebo velikostmi.

Tohle ale nemá s OOP ani JavaBeans vůbec nic společného. Viz co psal JS1. Tohle je záležitost typů, typových tříd / traits / interfaces / říkej si tomu jak chceš, ale jde o to, že o tom typu víš že má nějaké metody = lze ho předhodit nějakým generickým funkcím, které s ním můžou pracovat na základě té typové třídy / trait / interface (např. třídit, zobrazovat atd.). OOP ani beans ani žádné jiné javovské věci na to nejsou nijak potřeba.

[xkucf03]

Díky JavaBeans (a té konvenci getterů/setterů) a reflexi (nebo nadstavbám nad ní) ale můžeš pracovat s libovolnými objekty, tzn. i s těmi, o kterých předem nevíš, jaké mají metody/atributy. V době běhu se podíváš, zjistíš, že tam máš třeba název a velikost → a můžeš podle nich třídit, může to dynamicky vykreslit tabulku v GUI a příslušná tlačítka/formuláře pro třídění a filtrování.

Kromě těch standardizovaných/konvenčních metod tam můžou být i libovolné další metody a můžeš používat OOP. Tzn. k tomu, abychom mohli používat generické algoritmy, není nutné, aby to byly jen nějaké neobjektové struktury nebo pouhé datové typy, není to v rozporu s použitím OOP principů u těch samých objektů/entit.

Připomínám původní komentář, pod kterým se tahle diskuse rozvinula:

Mel jsem spis na mysli to, ze my chceme vedet, ze treba to "ls" vraci seznam veci, abychom je treba mohli tridit standardni tridici funkci. Takze, jak pise deda.jabko, chceme, aby do toho typu bylo videt, na jednu stranu, na druhou stranu to jde dost proti OOP v tom smyslu, ze v OOP bychom vratili uzavreny typ, do ktereho se da vstoupit jen tak, jak to dovoluji jeho metody.

který naznačuje nějaký údajný rozpor mezi objektovým přístupem a použitím generických algoritmů/funkcí.

[kralyk z abclinuxu]

Díky JavaBeans (a té konvenci getterů/setterů) a reflexi (nebo nadstavbám nad ní) ale můžeš pracovat s libovolnými objekty, tzn. i s těmi, o kterých předem nevíš, jaké mají metody/atributy.

Nevidim, jak se to liší od objektů třeba v Pythonu nebo JS nebo X dalších prostředích, kde se dá používat reflexe, dynamické typování a všechny tyhle srandy. Spojitost s OOP taky nevidim.

Kromě těch standardizovaných/konvenčních metod tam můžou být i libovolné další metody a můžeš používat OOP.

Já jsem nějak nezaznamenal z tvých komentářů, na co by podle tebe měly být užitečné/relevantní principy Java-like OOP pro téma diskuse. Znova ještě dodám, že za OOP nepovažuju "struktury/objekty s metodami". Řekl bys třeba o Rustu nebo Go, že mají OOP? IMHO ne, nebo jen v nějakém ořezaném smyslu, asi jako C.

Za relevantní považuju prototypové OOP, jak o tom psal Bystroušák, ale to hádám není to, co myslíš, jakožto Javista.

který naznačuje nějaký údajný rozpor mezi objektovým přístupem a použitím generických algoritmů/funkcí.

Já jsem to pochopil tak, že zapouzdření jde v podstatě proti tomu 'velkému' cíli popsaného Bystroušákem a dalšími a ze stejného důvodu mi JS1 odpověděl negativně na to použití existenciálních typů. Je to asi v zásadě dobrá pointa a nakonec souhlasím.

Mám celkově dojem, že jmenuješ nějaké featury z Java ekosystému, o kterých si myslíš, že jsou dané Javou nebo OOPčkem, ale přitom se jedná o obecnější vlastnosti.

[xkucf03]

Dobře, Javu jsem do toho asi neměl zatahovat a vůbec o ní mluvit, protože to je červený hadr, po kterém spousta lidí vystartuje... Zapomeň na to a bavme se o OOP obecně.

Shodneme se aspoň na tom, že objekty spojují data a chování a podporují zapouzdření? (kromě jiných vlastností, které ale v tomto kontextu nejsou až tak důležité)

Pokud ano, tak se můžeme vrátit k tomu komentáři, na který jsem reagoval:

Mel jsem spis na mysli to, ze my chceme vedet, ze treba to "ls" vraci seznam veci, abychom je treba mohli tridit standardni tridici funkci. Takze, jak pise deda.jabko, chceme, aby do toho typu bylo videt, na jednu stranu, na druhou stranu to jde dost proti OOP v tom smyslu, ze v OOP bychom vratili uzavreny typ, do ktereho se da vstoupit jen tak, jak to dovoluji jeho metody.

A psal jsem, že použití standardních generických funkcí není v rozporu s objektovým přístupem. Bylo by falešné dilema říkat, že můžeme mít jedno nebo druhé.

Ten objekt¹ se může chovat částečně jako struktura a zároveň mít nějaké chování (takže je to objekt, ne jen struktura). A pak na ten objekt můžeš uplatnit generické funkce (např. třídit podle názvu), přestože je to objekt, je tam zapouzdření a nějaké další chování.

_{[1] a je jedno, jestli je to instance nějaké třídy, JavaBean, jestli tam máš gettery a settery, nebo jestli si ty objekty "posílají zprávy" místo aby "volaly metody", jestli je to prototypové OOP atd.}

[kralyk z abclinuxu]

Shodneme se aspoň na tom, že objekty spojují data a chování a podporují zapouzdření? (kromě jiných vlastností, které ale v tomto kontextu nejsou až tak důležité)

No... jak se to vezme. Z mého pohledu to gro toho OOP á la Java je dynamic dispatch + dědičnost, tím se to reálně liší od struktur + funkcí, jinak IMHO ne. A bez té dědičnosti je to takové to "menší OOP" jako třeba v Gočku. Pak už se to od struktur + funkcí liší jen tím dynamic dispatchem, který se jinde (třeba obvykle v těch prototypových OOP) řeší pomocí first-class funkcí.

Zapoudření je s tím spojeno IMHO spíše historicky / kulturně, když se nad tím zamyslíš, tak je vlastně dost ortogonální. Jediná souvislost je, že protected je spojený s dědičností, ale to je specielní případ a jinak je zapouzdření spíš záležitost modulů/namespaces. Proto taky jazyky s tím "menším OOP" bez dědičnosti (Go, Rust) řeší přístup na úrovni modulů, nikoli objektů, víceméně protože prostě ta jediná reálná souvislost s objekty (protected) odpadla.

Já se o OOP obecně moc nechci bavit, protože v takhle obecné diskusi nevim, co se tim myslí (Javovské OOP? "Malé OOP"? Prototypové OOP?), spíš bych viděl jako lepší bavit se o těch jednotlivých fíčurách, které pojem 'OOP' dosti gulášovitě michá dohromady (dispatch, sdílení implementace, řízení přístupu, příp. moduly/namespaces, ...).

A psal jsem, že použití standardních generických funkcí není v rozporu s objektovým přístupem. Bylo by falešné dilema říkat, že můžeme mít jedno nebo druhé.

Já to pochopil tak, že to řazení byl jen příklad a IMHO do toho objektu můžeš chtít vidět z mnoha různých jiných důvodů. Nicméně i u toho řazení je ta zapouzdřená varianta více omezená v tom, že musíš použít tu řadící funkci, kterou ten objekt má definovanou, nemůžeš se do něj podívat a vytvořit si třeba ad-hoc nějakou vlastní, jinou.

V kontextu strukturovaných pajp mi to zapouzdření moc smysl nedává.

[xkucf03]

Nicméně i u toho řazení je ta zapouzdřená varianta více omezená v tom, že musíš použít tu řadící funkci, kterou ten objekt má definovanou, nemůžeš se do něj podívat a vytvořit si třeba ad-hoc nějakou vlastní, jinou.

Proč bys musel? Když budeš chtít řadit třeba podle velikosti, tak si zavoláš getLength() a podle toho objekty seřadíš. Před tím si zjistíš, jaké atributy jsou k dispozici a název metody si odvodíš podle daných konvencí nebo to za tebe udělá nějaká knihovna. Na ten objekt se v tu chvíli díváš spíš jako na strukturu -- přesto je to objekt, má zapouzdření a má i nějaké jiné chování, další metody. (tohle bylo na příkladu javovského OOP -- v jiném OOP by to vypadalo trochu jinak)

Případně nemusíš volat jen gettery, ale můžou to být jakékoli metody, můžeš nad tím dělat map/reduce (to pak považuješ za FP nebo pořád OOP? -- jsme pořád v tom samém jazyce).

Nicméně v téhle diskusi nevidím moc přínos -- původně jsem chtěl jen okomentovat jeden výrok a uvést ho na pravou míru (říct, že něco není v rozporu s objekty, že tam objekty nejsou na překážku) a snažil jsem se upozornit na falešné dilema.

[kralyk z abclinuxu]

Wat. Pokud ten objekt/struktura bude mít zvenčí nepřístupná data a přístup k nim nějak omezuje v getterech/setterech/atd., tak jsi více omezen oproti tomu, když do něj zcela vidíš, to by snad mělo být zřejmé. Nemůžeš např. třídit podle skrytého pole nebo jsi omezen chováním getteru. Nevidim na tom nic falešně dilematického.

To zapouzdření je zkrátka nějaký tradeoff mezi robustností a flexibilitou a někdy dává smysl (aplikační programování) a někdy méně...

[JS1]

To zapouzdření je zkrátka nějaký tradeoff mezi robustností a flexibilitou

Vidim to velmi podobne. Rikat, ze je neco zapouzdrene, a pritom k tomu dovolit pristup pres gettery/settery (a treba pak trideni) je znacny rozpor.

[Bedňa]

reporty nad tim vystupem budou soucasti toho objektu?

Áno, je to hádam jasné aj z toho videa.

[Bherzet]

V tom novem systemu mi "ls" proste vrati seznam objektu, dobra. Jenze kdyz ho pak budu chtit zobrazit uzivateli nejak rozumne (jako to dela klasicke ls), budu potrebovat novy prikaz, nejake ls-fmt, ktere z toho seznamu objektu, co vrati (specificky) ls, vyrobi citelny smysluplny text, ktery obsahuje informace, ktere hledam (napriklad casto lide pouzivali trideni podle data zmeny).

https://www.abclinuxu.cz/blog/bystroushaak/2018/12/programatorova-kritika-chybejici-struktury-os/diskuse#142

Ono to svym zpusobem souvisi s koncepci Model-View-Cokoliv, s kterou prisel taky myslim Smalltalk a je vlastne trochu divna, protoze jde trochu proti OOP. Protoze kazdy View musi casto tak nejak znat Model, a tim mezi nimi existuje vazba, nejsou to uplne samostatne objekty.

Jaký by mělo smysl vytvořit tři „úplně samostatné objekty“? Bez té vazby by nějaké MVC snad nemohlo ani existovat.

Mimochodem, co se přihlásit? Takhle si lámu hlavu nad tím, jestli se za registrovaného JS1 někdo poměrně dost zdařile vydává, a nebo ty drobné odlišnosti, které ve stylu psaní pozoruji, mají jinou příčinu.

[JS1]

Co používat jeden účet místo dvou? A chválit sám sebe také z jednoho, aby v tom nebyl nepořádek?

[JS1]

Jaký by mělo smysl vytvořit tři „úplně samostatné objekty“? Bez té vazby by nějaké MVC snad nemohlo ani existovat.

Ja nejsem fanousek OOP a MVC. Jenze pokud to nejsou nezavisle objekty, ale musi navzajem stejne znat svoji strukturu, nema moc smysl, aby byly (zrovna) tri. Treba v Unixu vsechny tri ulohy (zhruba odpovidajici tomu M, V a VM) dela rovnou jeden prikaz - ls.

Pripada mi, ze lepsi je se na objekty proste vykaslat a psat vsechno jako funkce, ktere si vymenuji nejake typy. A to co se deje v tech funkcich je plne skryto za typovou signaturou.

akhle si lámu hlavu nad tím, jestli se za registrovaného JS1 někdo poměrně dost zdařile vydává, a nebo ty drobné odlišnosti, které ve stylu psaní pozoruji, mají jinou příčinu.

Zbytecne si s tim lames hlavu. Tady jsou vsichni tak zbesile paranoidni.. Jsem mimo domov na svem malem notebooku a nemam tu po ruce kredence (castecne proto, ze je tu ani nechci mit), chtel jsem se puvodne prispivani sem vyhnout, ale pak mi to nedalo.

[Bherzet]

Jenze pokud to nejsou nezavisle objekty, ale musi navzajem stejne znat svoji strukturu, nema moc smysl, aby byly (zrovna) tri.

Myslím si, že návrhové vzory nelze brát jako neměnné dogma, ale spíš jako zdroj inspirace, jak vyřešit určitý problém. MVC vnímám jako jednoduchý a velmi obecný model, jak řešit rozdělení aplikační a renderovací logiky. V praxi tam nebudou právě tři objekty, ale spíše tři druhy objektů, které budou spadat do jedné z těch tří úrovní. Pokud víš, co děláš, můžeš nějaké úrovně přidat. Nebude to už MVC a možná ani jiný známý koncept ze stejné rodiny, ale to nemusí být nutně špatně. Ostatně nepanuje ani shoda, že právě MVC je to pravé ořechové. Pokud se nepletu, třeba Facebook ho nepoužívá (ačkoliv osobně bych si zrovna tuto firmu za vzor nebral).

Treba v Unixu vsechny tri ulohy (zhruba odpovidajici tomu M, V a VM) dela rovnou jeden prikaz - ls.

To bychom přece míchali dohromady vícero věcí. MVC nemusíš používat vůbec. Pokud ho ale použiješ, můžeš ho aplikovat jak na jeden program, tak třeba na celý systém.

Mimochodem, používat „MVC“ i pro jednoduché konzolové aplikace se mi mnohokrát osvědčilo. Samozřejmě ne tak, jak se to píše v učebnicích, ale prostě mám zvlášť logiku, která něco počítá (controller) a vrátí to ve strojově zpracovatelné struktuře (model), a pak teprve logiku, která to pěkně vypíše (view). Mnohem lépe se to debuguje, testuje a rozšiřuje.

Pripada mi, ze lepsi je se na objekty proste vykaslat a psat vsechno jako funkce, ktere si vymenuji nejake typy. A to co se deje v tech funkcich je plne skryto za typovou signaturou.

To si myslím, že přesně odpovídá tomu mému volnějšímu pojetí MVC, o kterém jsem se rozepsal v předchozím odstavci. Já objekty chápu především jako jakousi organizační strukturu, která ale sama o sobě nemá nutně vliv na to, jak řídíš samotný tok programu (programuješ). Hodně mě v tomhle ovlivnil profesor Odersky.

[xkucf03]

třeba Facebook ho nepoužívá (ačkoliv osobně bych si zrovna tuto firmu za vzor nebral).

Ono web je vůbec dost zvrácené prostředí a od té doby, co se "programuje" i na straně klienta, tak tam máš ty návrhové vzory dvakrát. Aplikace je pak rozseknutá na dvě části HTTP protokolem, ale nejde jen o protokol, jde i o to, že té části na straně klienta nemůžeš absolutně věřit -- a podle toho ji musíš psát a duplikovat řadu věcí na straně serveru.

Jako rozumné řešení (v rámci možností webu) mi tam přijde, když ta klientská strana je víceméně jen generický zobrazovač a je plně řízená ze serveru.

[Bherzet]

Souhlasím.

[JS1]

a podle toho ji musíš psát a duplikovat řadu věcí na straně serveru

Tohle se da dobre resit ve funkcionalnim programovani - definujes si logiku v nejake monade, a interpretace te monady muze byt pak ruzna pro server a klienta. (Ono by se skoro dalo rict, ze FP je jen do extremu dotazene IoC..)

[kralyk z abclinuxu]

IMHO to nemusíš nutně řešit monadicky, i když to má určitou elegnci, ale prostě sdílet kód mezi serverovou a klientskou částí. Tohle dneska lidi dělají třeba s JavaScriptem a asi to je faktor, proč někteří volí Node.js (viz třeba trochu moc vznešený pojem "isomorphic rendering" apod.). S příchodem webassembly by tohle mělo jít i v jiných jazycích.

[xkucf03]

Nevím, jestli tě dobře chápu, ale tohle přece není specifické pro funkcionální programování. To lze udělat pro jakýkoli jazyk (procedurální, objektový...), pro který existuje transpiler do JavaScriptu/WebAssembly.

Nicméně u triviálních věcí (např. omezení délky nebo formát data) je stejně lepší to řešit deklarativně, než se snažit volat ten samý kód na serveru i na klientovi, protože ta režie s voláním stejných metod/funkcí na obou stranách a hlavně to napojení na validované/transformované objekty bude větší než u toho deklarativního způsobu.

[JS1]

IMHO ten monadicky pristup je jednodussi nez jak transpiler tak i deklarativni pristup, ale nemam ted moc silu vysvetlovat, proc. Zkus si o tom neco precist.

[xkucf03]

Jenže monáda bude psaná v Haskellu nebo jiném jazyce, takže ji stejně musíš přeložit do JavaScriptu/WebAssembly, ne? (případně psát i server v JavaScriptu)

[kralyk z abclinuxu]

Monády se dají používat víceméně v jakémkoli jazyce. V non-FP jazcích o tom lidi typicky akorát nevědí.

Viz třeba Java Streams nebo Promises v JavaScriptu.

[xkucf03]

Kontext diskuse:

Ono web je vůbec dost zvrácené prostředí a od té doby, co se "programuje" i na straně klienta, tak tam máš ty návrhové vzory dvakrát. Aplikace je pak rozseknutá na dvě části HTTP protokolem, ale nejde jen o protokol, jde i o to, že té části na straně klienta nemůžeš absolutně věřit -- a podle toho ji musíš psát a duplikovat řadu věcí na straně serveru.

Ano, můžu si to napsat dvakrát v různých jazycích, můžu tomu klidně říkat monády nebo jakkoli jinak, ale to nemění nic na tom, že web tímto problémem trpí. A máš několik možností, které jsou vlastně všechny v něčem špatné:

• duplikuješ kód na klientovi a na serveru
• posíláš si častěji data sem a tam
• musíš vymýšlet nějaké transpilery nebo volit jazyk serveru podle toho, co umí prohlížeče
• napíšeš si nějaký interpret deklarativních pravidel, který poběží v prohlížeči

[kralyk z abclinuxu]

Mně přijde, že tohle už v dnešní době až tak relevantní není, protože ta úloha serveru a klienta se překrývá čím dál méně.

Navíc řešení v podobě wasm je na cestě, čiliže s tím problémem, že není možné programovat pro browser v jiných jazycích, se už nějakou dobu něco dělá.

[kralyk z abclinuxu]

Pokud se nepletu, třeba Facebook ho nepoužívá (ačkoliv osobně bych si zrovna tuto firmu za vzor nebral).

No však Facebook na MVC kritizoval víceméně to, co napsal JS1, tu přílišnou provázanost. React je pak odpovědí na tento problém, kde se k němu přistupuje funkcionálně.

Facebook bych jako za vzor taky úplně nebral, nicméně tenhle problém a v zásadě +/- i to řešení identifikovali IMO správně, alespoň principielně.

[JS1]

Myslím si, že návrhové vzory nelze brát jako neměnné dogma, ale spíš jako zdroj inspirace, jak vyřešit určitý problém.

Mne na navrhovych vzorech hodne vadi jejich neformalnost, ale pokud by to skutecne lide brali jen takto, tak by to jeste nebylo tak zle. Potiz s timhle pristupem je, ze pak se neda tvrdit, ze to nejak "usnadnuje komunikaci", coz bohuzel o navrhovych vzorech hodne jejich obhajcu tvrdi.

Ja uznavam vyhody toho "MVC" rozdeleni (v tom vyse uvedenem priklade), jenom jsem podotykal, ze to asi zrovna u shellu clovek moc nechce, z praktickych duvodu. Prakticke je proste mit dvouvrstvy system - low-level API a high-level operace nad nim (kde vstup i vystup je nejak snadno clovekem citelny) - coz fakticky temer presne Unix je. Svym zpusobem, co Bystroushaak chce, uz existuje, ale nikomu se dnes uz nechce programovat v C, takze..

Já objekty chápu především jako jakousi organizační strukturu

To muzes, ale je to IMHO dost odlisne od jak puvodni tak bezne predstavy, jak ma OOP fungovat. Viz moje odpoved Kralykovi vys. A hlavne to pak nedava vubec smysl, mit objekty - v podstate si pak vystacis primo s moduly.

[xkucf03]

Vezmeme si treba klasicke "ls" jako priklad. V tom novem systemu mi "ls" proste vrati seznam objektu, dobra. Jenze kdyz ho pak budu chtit zobrazit uzivateli nejak rozumne (jako to dela klasicke ls), budu potrebovat novy prikaz, nejake ls-fmt, ktere z toho seznamu objektu, co vrati (specificky) ls, vyrobi citelny smysluplny text, ktery obsahuje informace, ktere hledam (napriklad casto lide pouzivali trideni podle data zmeny).

Pointa je v tom, že nemusí existovat nějaké specifické ls-fmt, ale může se k tomuto účelu používat generický nástroj. Jde tedy udělat něco jako:

$ relpipe-in-ls() { ls -1 -- "${@}" | tr \\n \\0 | relpipe-in-cli generate-from-stdin ls 1 file_name string; }

$ relpipe-in-ls /etc/ssh/ | relpipe-out-tabular
ls:
 ╭──────────────────────────╮
 │ file_name       (string) │
 ├──────────────────────────┤
 │ moduli                   │
 │ ssh_config               │
 │ sshd_config              │
 │ ssh_host_ecdsa_key       │
 │ ssh_host_ecdsa_key.pub   │
 │ ssh_host_ed25519_key     │
 │ ssh_host_ed25519_key.pub │
 │ ssh_host_rsa_key         │
 │ ssh_host_rsa_key.pub     │
 │ ssh_import_id            │
 ╰──────────────────────────╯
Record count: 10

$ relpipe-in-ls /etc/ssh/ | relpipe-out-xml
<?xml version="1.0" encoding="UTF-8"?>
<pipe>
        <relation>
                <name>ls</name>
                <record>
                        <attribute>moduli</attribute>
                </record>
                <record>
                        <attribute>ssh_config</attribute>
                </record>
                <record>
                        <attribute>sshd_config</attribute>
                </record>
                <record>
                        <attribute>ssh_host_ecdsa_key</attribute>
                </record>
                <record>
                        <attribute>ssh_host_ecdsa_key.pub</attribute>
                </record>
                <record>
                        <attribute>ssh_host_ed25519_key</attribute>
                </record>
                <record>
                        <attribute>ssh_host_ed25519_key.pub</attribute>
                </record>
                <record>
                        <attribute>ssh_host_rsa_key</attribute>
                </record>
                <record>
                        <attribute>ssh_host_rsa_key.pub</attribute>
                </record>
                <record>
                        <attribute>ssh_import_id</attribute>
                </record>
        </relation>
</pipe>

$ relpipe-in-ls /etc/ssh/ | relpipe-out-<TAB><TAB>
relpipe-out-gui       relpipe-out-nullbyte  relpipe-out-ods       relpipe-out-tabular   relpipe-out-xml

Ono to svym zpusobem souvisi s koncepci Model-View-Cokoliv, s kterou prisel taky myslim Smalltalk a je vlastne trochu divna, protoze jde trochu proti OOP. Protoze kazdy View musi casto tak nejak znat Model, a tim mezi nimi existuje vazba, nejsou to uplne samostatne objekty.

Tady jde zase o to, že i když pohled většinou není generický a je nějak specificky vytvořen pro data, která bude zobrazovat, tak na druhé straně model není závislý na pohledu. Takže k jednomu modelu můžeš mít víc pohledů, můžeš pohledy v průběhu času různě vyměňovat, vylepšovat nebo jich provozovat víc současně. A na podstatnou část aplikace nemusíš sáhnout, zůstává nezměněná.

Takze pak ve finale, misto "ls -l /usr" bude clovek psat "path-arg "/usr" | ls | ls-fmt -l | display-stdout" nebo neco podobne hruzneho.

U rozhraní pro ad-hoc ovládání systému ručním zadáváním příkazů to přirozeně směřuje k vytváření různých zkratek a nástrojů, které dělají více než jednu věc. Je to otázka granularity. Příliš velká i příliš malá je špatně. Optimum se hledá někde mezi tím. Ty zkratky můžou být klidně aliasy nebo krátké skripty, které spojí více nízkoúrovňových příkazů do jednoho většího celku, jehož granularita odpovídá tomu, jak uživatel typicky pracuje se systémem.

[xsubway]

Stačí když bude mít program implicitně volanou funkci / metodu, např. toString v prostředí Console / Shell.

Takže se prostě napíše

$ ls

stejně jako v současném shellu. Pokud by bylo zapotřebí vracet objekt / strukturu, tak se změní nějaký kontextový přepínač (pnebo přepínač příkazů) a bude se vracet objekt místo výsledku toString.

Ve skutečnosti stačí když bude implementovat toString každý objekt na rozhraní všech příkazů / metod.

(Samozřejmě si uvědomují, že to na principu nic nemění, je to jen o způsobu použití, resp. syntaxe.)

[JS1]

To je v podstate to co navrhoval Kralyk s tim Display... potiz pak je, ze je trochu osklive, tu funkci, ktera provadi to toString, nelze aplikovat na nic jineho nez na vystup toho ls.

Napriklad kdybychom meli ls a nejake dejme tomu ls-remote, ktere mi vypise adresar ze vzdaleneho stroje (pod nejakym protokolem), tak musime to toString napsat dvakrat. Zatimco pokud existuje ls-fmt, tak uz to mame hotove. Je to do urcite miry michani tech dvou vrstev, jak jsem uz psal jinde.

[xsubway]

Ano, vidím taky výhodu více vrstev (ls a ls-fmt). Nicméně i v tomto případě by bylo možné (možná) spojit obě implementace / vrstvy dohromady, tedy pokud by to dávalo smysl a bylo by to užitečné.

[xkucf03]

Nevýhodou toString() a obecně takových metod je, že si musíš počkat, až se všechna data připraví/naformátují a pak je dostaneš najednou. V případě konzolového rozhraní se může zdát, že to nevadí, že těch dat je málo (aby se vešla na obrazovku a člověk je zvládl přečíst), ale představ si, že při tom formátování děláš operaci, která chvilku trvá, např. se dotazuješ DNS nebo počítáš hash. Pak dává smysl, aby se uživateli zobrazovaly první záznamy hned, jak jsou k dispozici, tzn. v době, kdy se ještě počítají ty další. Uživatel pak vidí výsledky průběžně, je spokojenější, nemá pocit, že se systém zasekl a může nad těmi prvními záznamy přemýšlet nebo je někam opisovat, kopírovat atd.

To průběžné zobrazování se dá řešit např. vrácením iterátoru nebo tím, že metoda přijímá jako parametr objekt, na kterém následně volá metody a předává mu průběžně data.

Další problém je s duplikací kódu. Pokud máš M výstupních formátů a N nástrojů, musíš udělat M×N implementací. To lze řešit znovupoužitelnými knihovnami pro výstupní formáty.

Nicméně pokud jde ten příkaz (řešící jak získání dat, tak jejich výpis) implementovat jako alias nebo krátký skript, přijde mi to zajímavé z toho důvodu, že uživatel se snadno podívá na zdroják toho skriptu/aliasu/funkce a může si z toho vytáhnout ty jednotlivé kroky a poskládat si je jinak. Když např. používám tento příkaz:

$ r-ls /etc/ssh/
ls:
 ╭──────────────────────────╮
 │ file_name       (string) │
 ├──────────────────────────┤
 │ moduli                   │
 │ ssh_config               │
 │ sshd_config              │
 │ ssh_host_ecdsa_key       │
 │ ssh_host_ecdsa_key.pub   │
 │ ssh_host_ed25519_key     │
 │ ssh_host_ed25519_key.pub │
 │ ssh_host_rsa_key         │
 │ ssh_host_rsa_key.pub     │
 │ ssh_import_id            │
 ╰──────────────────────────╯
Record count: 10

Tak se můžu podívat, jak je implementovaný:

$ type r-ls 
r-ls je funkce
r-ls () 
{ 
    ls --color=auto -1 -- "${@}" | tr \\n \\0 | relpipe-in-cli generate-from-stdin ls 1 file_name string | relpipe-out-tabular
}

a pak z něj můžu snadno vyjít a implementovat si vlastní funkci, která třeba vypisuje výsledek v jiném formátu nebo nějak filtruje data nebo k nim něco přidává. Na zdroják příkazu ls v C se sice taky můžu podívat a můžu z něj vyjít a nějak si ho upravit, ale je to řádově složitější než v rouře nahradit jeden krok jiným.

Pokud se podaří od sebe oddělit jednotlivé fáze (získání dat, jejich transformace, výstupní formátování) do samostatných programů, bude ten systém mnohem flexibilnější a hackovatelnější než je teď.

[xsubway]

Jak už jsem psal dříve pod příspěvkem JS1 - souhlasím s rozložením do více vrstev, pokud je to užitečné a vhodné.

S tím toString jsem zvolil samozřejmě nejběžnější výstup obsahu objektu. Nicméně si místo (a/nebo vedle) této metody / funkce lze představit i další, např. toStream, atd. apt. Kde výstupem je proud objektů ze kterého lze číst, pak už nemusí být všechna data připravena ihned. (Samozřejmě tím směřuji k rourám.) Ale, ještě jednou. Nemám nic rozdělení implementace logiky a dalších vrstev nad tím do více programů, struktur. Jak píšeš - je to flexibilnější.

[kralyk z abclinuxu]

Nevýhodou toString() a obecně takových metod je, že si musíš počkat, až se všechna data připraví/naformátují a pak je dostaneš najednou.

Nevim jak předřečník, ale to, co jsem psal já s tou Display traitou bylo myšleno pouze jako analogie, ne tak, že by ten výstup doslova měl implementovat to samé. To by přece ani nedávalo smysl, pajpy jsou v zásadě bufferované streamy, takže by dávalo smysl se tomu přizpůsobit a poskytnout nějaké streamové rozhraní.

[JS1]

Pointa je v tom, že nemusí existovat nějaké specifické ls-fmt

Ja ti rozumim, ale moje pointa byla prave v tom, ze specificke ls-fmt se dost hodi - protoze s tim vystupem ls chceme snadno delat veci, ktere s jinymi vystupy delat nechceme nebo to ani na zaklade jejich struktury neni mozne.

[xkucf03]

Jaké věci třeba? Napadá mne různé třídění a filtrování, případně projekce, ale to jsou generické operace, které závisí maximálně na datovém typu daného atributu. I kdyby šlo o stromová data, tak nad nimi se taky dají dělat generické operace.

Dejme tomu, že budu ke každému souboru chtít dopočítat jeho hash. Pak je mi ale jedno, odkud ten seznam souborů pochází, jestli z něčeho jako ls, grep -lr nebo find. Jde o to, aby tam byl atribut vhodného datového typu a v něm cesta k souboru. Pak to můžu transformovat a přidat další atribut obsahující např. ten hash, MIME typ, rozšířené atributy nebo délku.

Jako specifická operace by se mohlo zdát formátování přístupových práv do tvaru, na který jsme zvyklí (jako drwxr-x--x). Ale i tohle lze řešit generickou znovupoužitelnou funkcí. Na vstupu má čistá surová data, což je v tomto případě bitová mapa (posloupnost bitů/booleanů) a na výstupu má textový řetězec. Parametrem funkce bude i to, jak se mají booleany na jednotlivých pozicích naformátovat (false = -; true = d/r/w/x dle pozice).

[deda.jabko]

neco zjisti a nejak to vypis, ted budeme mit minimalne dva prikazy, jeden to zjisti a vyrobi z toho strukturu a druhy tu strukturu (kterou musi znat) nejak zformatuje, jak bychom asi chteli (jako lide)

V principu je to dobry napad -- mas jeden program, ktery dela prave jednu vec a dela ji poradne.

ls -l /usr

K tomu bysme si mohli pridat flame na klasicke tema: grep -c vs. grep | wc -l

bude clovek psat "path-arg "/usr" | ls | ls-fmt -l | display-stdout" nebo neco podobne hruzneho. Kdyz si k tomu uvedomime, ze je to opravdu jen skladani funkci, pak cele to OOP prestava IMHO davat velky smysl, a mozna by proste stacilo mit nejaky funkcionalni jazyk jako shell.

Tohle mam udelane v Schemikovi uz par let. Pekna vec, roury v podstate odpovidaji threading makru. ;-]

[Heron]

Vezmeme si treba klasicke "ls" jako priklad.

Následující text prosím neberte nějak útočně, chápu, že celá tato diskuse je ve stylu "kdo si hraje, nezlobí", ale tohle mě připadá už totálně absurdní.

Příkazy v shellu jsou určené zejména pro člověka a pro interaktivní práci. Umožňují snadno a rychle dělat snadné věci. Pro cokoliv složitějšího je lepší použít jiný jazyk.

Tj nedává smysl předělávat základní příkazy jako ls a find a grep apod. do nějaké strojově lépe použitelné podoby, protože v každém programovacím jazyku jsou k disposici (knihovní) funkce, které tyto základní příkazy více než nahradí. Tj ls je pro člověka, a pokud chceme pracovat s více soubory a něco nad nimi spouštět je lepší použít find a pro cokoliv složitějšího se pak přepnout do svého oblíbeného jazyka a použít třeba ekvivalent os.walk.

Jaký přínos má předělávat ls do podoby zde (hlavně Frantou) uvedené? Pro člověka to bude hůře použitelné (nebo si stejně vytvoří alias ls) a pro vyšší použití je to stejně zbytečné, protože funkci "seznam souborů v adresáři" mám k disposici v každém programovacím jazyce. (A pokud použiji nějaký silně objektový, tak ten výpis bude hromada objektů s hromadou atributů jako dalšími objekty.)

[xkucf03]

Pro cokoliv složitějšího je lepší použít jiný jazyk.

To má nevýhodu v tom, že přechod od "jednoduchého skriptování" nebo "používání shellu" k "opravdovému programování" je skokový a najednou se musíš naučit příliš mnoho věcí a úplně nový jazyk. I když třeba chceš jen o něco málo víc, než co jsi dělal v těch skriptech. Jasně, pokud chceš být programátor, tak tu hranici musíš překonat a ponořit se pořádně do nějakého programovacího jazyka tak jako tak. Ale pokud jsi jen pokročilý uživatel nebo správce systému, tak je překonávání té hranice poměrně zbytečná obtíž, protože ty možnosti shellu a skriptování se dají posunout dál, než kde jsou teď.

Pro člověka to bude hůře použitelné (nebo si stejně vytvoří alias ls)

Předpokládám, že takový alias by už existoval ve výchozí instalaci. Takže komplexita těch příkazů z pohledu uživatele by se měnit nemusela, jen by se lišila jejich vnitřní implementace -- byly by složené z několika menších příkazů, místo aby to byl celé jeden program psaný v C.

Neříkám, že je to univerzální recept -- někde by asi bylo lepší mít pořád jeden program a společnou funkcionalitu jen dát do knihovny, ale jinde by to skládání z více příkazů mohlo mít smysl.

Navíc, pokud bychom se dokázali dohodnout na nějakém standardu, mohlo by existovat více jeho implementací. Jedna by byla třeba vysoce optimalizovaná, kde by celý větší příkaz byl zkompilovaný do jedné binárky a data mezi jednotlivými kroky by neopustila jeden proces a nedocházelo k jejich serializaci a deserializaci. Zatímco jiná (asi referenční) implementace by byla složená z více menších příkazů pospojovaných dohromady. Rozhraní by bylo definované standardem a implementace by byly zaměnitelné. Přepínal by sis je třeba přes update-alternatives.

Jaký přínos má předělávat ls do podoby zde (hlavně Frantou) uvedené?

Příkaz ls je poněkud extrém.¹ Ale zkus se zamyslet nad tím, co píšu v #41. Jde o ten princip, ne o konkrétní příkaz ls.

Zdroják v C si většina lidí nepřečte, protože a) neumí programovat v C nebo b) programovat v něm sice umí, ale nemají dostatečně silnou motivaci. Ale podívat se na zdroják shellové funkce, kus si z něj vykopírovat a napojit výstup třeba do jiného výstupního filtru, to zvládne i pokročilejší uživatel a je to věc okamžiku. Jde o odstranění té hranice mezi "umím to použít" a "vím, jak to funguje uvnitř" (a následně "umím to změnit"). Resp. nějaká hranice tam bude pořád, ale může být snadnější ji překonat, než je tomu teď. Myslím, že k něčemu podobnému směřuje Bystroushaak, byť k tomu přistupuje objektově, ale ta snaha, aby do systému bylo víc vidět a šlo do něj zasahovat, je tam stejná.

P.S. Osobně zde vycházím hodně z Bashe a současného *NIXového přístupu, což beru jako takový konzervativnější způsob, kterým lze stav posupně zlepšovat. Jsou ale i jiné směry, které na to jdou více revolučním způsobem. Např. kolem GNU Guile je poměrně silná komunita a řada lidí se snaží používat funkcionální programování místo shellových skriptů. I když je to dost odlišný pohled na věc, jako společnou v tom vidím tu snahu o transparentnost systému a jeho hackovatelnost. Protože opět, podívat se na zdroják funkce v Guile je snadnější než si číst zdroják v C (a ten následně upravovat a překompilovávat). Stejně jako je snadnější se podívat na zdroják shellové funkce (viz type r-ls v #41) nebo použít reflexi a samopopisnost v Bystroushaakově objektovém světě.

_{[1] BTW: stejně tak mi přijde extrém, když si někdo stěžuje, že cat umí i číslovat řádky, a říká, že je to bloatware a že to odporuje myšlence že příkaz by měl dělat je jednu věc.}

[Heron]

To má nevýhodu v tom, že přechod od "jednoduchého skriptování" nebo "používání shellu" k "opravdovému programování" je skokový a najednou se musíš naučit příliš mnoho věcí a úplně nový jazyk. I když třeba chceš jen o něco málo víc, než co jsi dělal v těch skriptech. Jasně, pokud chceš být programátor, tak tu hranici musíš překonat a ponořit se pořádně do nějakého programovacího jazyka tak jako tak. Ale pokud jsi jen pokročilý uživatel nebo správce systému, tak je překonávání té hranice poměrně zbytečná obtíž, protože ty možnosti shellu a skriptování se dají posunout dál, než kde jsou teď.

Tak používání shellu je taky programování (je to Turingovsky úplný jazyk). I když se to tak běžně nenazývá. Tj je to jen přechod od jednoho jazyka k jinému. Navíc nikomu nic nebrání používat jako shell interaktivní interpretr třeba pythonu nebo php nebo čehokoliv. Problém je v tom, že shell byl vystavěn tak, že se v něm jednoduché a často používané věci dělají opravdu jednoduše a rychle. Už třeba jen to, že každé slovo napsané na začátku řádku bere jako interní nebo externí příkaz a ochotně jej spustí. Totéž v pythonu os.system("prikaz") (což je ještě navíc blbě) by se mi teda fakt psát nechtělo, a i kdyby někdo přišel s tím, že "os.system" nahradí znakem ♦ a uvozovky se psát nemusí a byl by na klávesnici, tak by se to stejně blbě používalo. Jinými slovy, shell jistě není nejkrásnější jazyk na světě, ale je to nejspíš nejlepší nástroj pro danou práci.

Předpokládám, že takový alias by už existoval ve výchozí instalaci.

Já jsem tam ten alias napsal schválně. Pokud by někdo používat interaktivní python jako shell, tak ls není nic jiného než "alias" kolem os.walk. Primitivní verze je na 3 řádky. ls ve skutečnosti není nic jiného, než formater nad daty z readdir. Tj rozdělit ls na část výkonnou a zobrazovací (propojenou nějakým protokolem) znamená, že to formátování nad readdir odebereme do druhého programu, místo toho tam bude generátor protokolu a na druhé straně zase čtení protokolu a formátování. Nepřijde mi to jako lepší varianta. Prostě příkaz ls je už sám o sobě atom. Uživatelsky přívětivý výstup readdir.

BTW: stejně tak mi přijde extrém, když si někdo stěžuje, že cat umí i číslovat řádky, a říká, že je to bloatware a že to odporuje myšlence že příkaz by měl dělat je jednu věc.

To jsem ani nevěděl. Tak podle mě bloatware jsou v podstatě všechny klasické GNU příkazy. Třeba proč proudové filtry (grep, sed) umí používat soubory? Ve skutečnost pouze extrémní minimum příkazů potřebuje umět pracovat se soubory. Od toho je cat, nebo ještě lépe < . Pro uložení do souboru je tu >. Takže: cat vstup | filter1 | filter2 ... > vystup. filterx nemají co umět nějaké soubory. Stejně tak síť. Ani nc by neměl mít přístup na síť (bash umí sám udělat tcp socket). Samozřejmě je to trochu recese, ale tento typ redukcionismu mám rád a ty stream filtry jsem snad nikdy nepoužil přímo nad souborem, i když pravda, i já si život často zjednoduším použitím grep "výraz" . -Rl.

[OldFrog {Ondra Nemecek}]

Jinými slovy, shell jistě není nejkrásnější jazyk na světě, ale je to nejspíš nejlepší nástroj pro danou práci (...) Prostě příkaz ls je už sám o sobě atom. Uživatelsky přívětivý výstup readdir.

To byla nejspíš původní myšlenka, jenže pak se pomocí toho „uživatelsky přívětivého výstupu“ začalo programovat (skriptovat v shellu) a to už zdaleka tak skvělé není.

Jinými slovy, málokdo chtěl používat C pro řešení drobných úloh a tak se propast mezi API systému a uživatelem dramaticky zvětšila. Otázka je, zda lze tu díru zas nějak zalepit.

To jsem ani nevěděl. Tak podle mě bloatware jsou v podstatě všechny klasické GNU příkazy. Třeba proč proudové filtry (grep, sed) umí používat soubory?

Ale to schizma stream vs. soubor je asi jen zdánlivé, neboť standardní vstup a výstup jsou taky jen soubory, ne?

Otázka je, jak by šlo při proudovém zpracování předat příkazu sadu streamů, tj. čím nahradit to zmíněné grep -r ? Asi nějakým funkcionálním stream api? Že bych si jedním příkazem prošel souborový systém a vytvořil z něj sadu streamů, tu předal grepu, který by je prohledával a vrátil by streamy se shodou, z nichž bych si pak vytáhnul buď jejich obsah nebo metainformace a vyplivnul je na standartdní výstup? Z toho pak nutně vychází, že by ty streamy musely obsahovat právě ty metainformace o umístění souboru v souborovém systému apod.

Pokud by byl návrh takového API dost dobrý, šlo by dosáhnout lepší konzistence a robustnosti při práci se systémem než při současném skriptování.

[Heron]

To byla nejspíš původní myšlenka, jenže pak se pomocí toho „uživatelsky přívětivého výstupu“ začalo programovat (skriptovat v shellu) a to už zdaleka tak skvělé není.

Jo, ale je otázka, jestli to vůbec jde udělat, tj mít jazyk, který nebude obtěžovat u opravdu jednoduchých věcí a současně v něm půjdou dělat i složitější. Shell se opravdu snaží strašně dlouho (se vzrůstající komplexitou řešeného problému) nezavazet za cenu toho, že u složitějších případů zavazí potom až příliš.

Je to ale skutečně na škodu? Není to naopak známka toho, že návrh daného systému je špatně a měl by se zjednodušit? V praxi vidíme, že při dobrém návrhu systému lze dělat v shellu i poměrně komplexní věci a přitom jednoduše (narážím třeba na rozdíl mezi sysv v linuxu a rc systémem v bsd, který je mocnější a přitom přehledně a jednoduše napsaný v shellu).

Otázka je, jak by šlo...

Tak moje představa je poměrně jednoduchá (neřešme konkrétní syntax a escapování):

find ... -printiftrue -exec 'cat {} | xgrep vyraz;'

Tj find by na každý soubor spustil ten skript a při určitém exit code by vypsal jméno souboru. Tohle je ekvivalent toho -Rl. Tj xgrep by vůbec nemusel mít podporu více streamů, pracoval by jen s jedním.

Pochopitelně by find mohl integrovat parallel a spouštět to ve více vláknech. Což se teda divím, že dodnes není, moje nejčastější konstrukce je find neco | parallel prikaz '{}' a když je potřeba něco dělat s uvedenými soubory (většinou pokud příkaz spouštěný parallel selže) tak je dost opruz ve skriptu zjišťovat jejich jména.

Tj ekvivalent by mohl vypadat:

find ... -parallel -printfailed -stream -exec 'prikaz;'

Přičemž prikaz by na stdin dostával stream přímo od findu a běželo by to paralelně nad množinou souborů.

[Fluttershy, yay!]

ELisp…

[xkucf03]

Na shellu je krásné to, že se ho učíš postupně. Nejdřív je to pro tebe jen řádek, kam píšeš název programu, který se má spustit. Pak přijdeš na to, že příkaz může mít parametry. Pak objevíš roury, pomocí kterých lze spojovat víc programů za sebou. Pak tam objevíš IFy a cykly atd. Jde o to, že ti to umožnilo se z pozice uživatele, který umí zapnout počítač a spustit jeden program, posunout mnohem dál. To se mi na shellu líbí. Samozřejmě tam jsou místa, kde to trochu vrže, ale IMHO se s tím dá žít, člověk se s tím vypořádá. Na druhé straně, kdybys používal od začátku nějaký akademicky čistě navržený dokonalý jazyk, tak by ses možná nedostal dál než k tomu spouštění programů, protože by ta vstupní bariéra byla příliš vysoká.

Tj find by na každý soubor spustil ten skript a při určitém exit code by vypsal jméno souboru. Tohle je ekvivalent toho -Rl. Tj xgrep by vůbec nemusel mít podporu více streamů, pracoval by jen s jedním.

Tohle lze řešit čistě v shellu:

find /etc/ssh/ -type f -readable -print0 | while read -d '' s; do grep -q "Passw" "$s" && echo "Nalezeno v: $s"; done

Případně pokud máš jistotu, že v názvech souborů nebude znak konce řádků:

find /etc/ssh/ -type f -readable | while read s; do grep -q "Passw" "$s" && echo "Nalezeno v: $s"; done

Nebo spuštění cyklu v témže shellu (většinou lepší, ale kvůli přehlednosti preferuji zápis výše):

while read -d '' s; do grep -q "Passw" "$s" && echo "Nalezeno v: $s"; done < <(find /etc/ssh/ -type f -readable -print0)

Tzn. nepotřebuješ k tomu xargs ani parallel.

Pokud se mají úlohy spouštět současně, už to není tak triviální. Jde o to, že musíš řešit synchronizaci, kolize souběhu -- nástroj neví, co se kde může potkat a co by na sebe mělo čekat a co může běžet v klidu vedle sebe, takže si to musíš nějak ošetřit sám. Další věc je posbírání jednotlivých výstupů -- pokud se ti všechny slijí do STDOUT, tak nevíš, co odkud pochází a můžeš být rád, když se ti nepomíchají části dat dohromady. Strojové zpracování takového výstupu je často nereálné (dát za xargs/parallel další rouru a v ní dělat další krok zpracování).

Ale tenhle problém by nemusel existovat, není to nic, co by bylo dané shellem a nešlo změnit. Proto bych chtěl mít nástroj, který spustí více příkazů (volitelně paralelně) a jejich výstupy posbírá a předá dál ve strojově čitelné podobě, tzn. bude tam hezky oddělené:

• kolikátý proces (z kolika)
• s jakými parametry byl spuštěn (pole řetězců)
• kdy začal, skončil (jak dlouho trval)
• jeho STDOUT
• jeho STDERR
• jeho návratový kód
• volitelně jeho STDIN
• případně by to mohlo měřit spotřebu paměti, cpu, počítat systémová volání... ale to už jdeme hodně daleko (a tohle by šlo vyčlenit do samostatného nástroje, který by tyhle statistiky např. vysypal na STDERR ve strukturovaném formátu a původní STDERR něčím obalil a přiložil ke strukturovaným datům)

[xkucf03]

P.S. oprava: grep by neměl to "$s" jako parametr a neotvíral by si sám soubor, ale dostal by jeho obsah na standardní vstup: < "$s"

[Heron]

Tzn. nepotřebuješ k tomu xargs ani parallel.

Já jsem to tam psal schválně, pro mě je paralelní spouštění úloh nad soubory z findu prakticky default už několik let. Jasně, v diskusi můžeme používat triviální příklady nad /etc/ssh, ale to jsem nikdy neměl potřebu aplikovat. Na druhou stranu běžně pracuju nad tisíci nezávislými soubory a na 16thread CPU.

Jde o to, že musíš řešit synchronizaci, kolize souběhu -- nástroj neví, co se kde může potkat a co by na sebe mělo čekat a co může běžet v klidu vedle sebe, takže si to musíš nějak ošetřit sám.

A ty pouštíš výše popsaným způsobem něco, kde reálně může nastat souběh? Ty úlohy spouštěné v xargs / parallel by měly být nezávislé.

Strojové zpracování takového výstupu je často nereálné (dát za xargs/parallel další rouru a v ní dělat další krok zpracování).

Ano, to je pravda. Tam už se většinou přepínám do pythonu a Pool.map, případně do vlastní fronty jobů.

[Bystroushaak]

Pak tam objevíš IFy a cykly atd. Jde o to, že ti to umožnilo se z pozice uživatele, který umí zapnout počítač a spustit jeden program, posunout mnohem dál. To se mi na shellu líbí. Samozřejmě tam jsou místa, kde to trochu vrže, ale IMHO se s tím dá žít, člověk se s tím vypořádá.

Pokud bereme jazyk jako man-machine interface, tak je nutné konstatovat, že bash je příšerná sračka z hlediska designu. Špatně se píše, špatně se čte, špatně se debuguje, je stringově orientovaný tak dementním způsobem, že oproti tomu jsou javascript i PHP jazyky svatá radost. Není multiplatformní (čti: věci v něm napsané nejsou) ani v rámci unixů. Je pomalý, ani nevím jestli na něj existuje aspoň nějaký linter. Jediné v čem tak nějak funguje je spouštění programů. Což je asi zároveň jeho nejhorší slabina, protože mi přijde, že neví, jestli chce být spouštěč programů a veškerou funkcionalitu delegovat na ně, nebo se snažit implementovat si věci po svém.

Bash mi trochu připomíná jak by to asi vypadalo, kdyby někdo implementoval ty nápady na objektově orientovaný systém jen ve filesystému. Vznikl by z toho přesně nějaký takový paskvil. Připomíná mi to proto, že sám je v podstatě meta-jazyk orientovaný jako jakási vrstva nad programy tvořenými binárkami, kde se míchají dohromady stringy a proměnné a návratové kódy a úplně jiné syntaxe pro funkce a vyhodnocení podmínek jako samostatný program test a kde co.

[xkucf03]

Tohle je zase věčný spor mezi evoluční a revoluční cestou. *nixové systémy procházejí evolucí a postupně se vyvíjejí. Kdykoli v průběhu může někdo přijít a říct, že je to blbě a že kdyby to navrhoval na zelené louce, že by to udělal lépe. Má pravdu, ale on nic nenavrhl, nevytvořil, jen říká, že by mohl...

Občas by asi měla přijít očista, revoluce a nové by mělo být nahrazeno starým. Ale dokud nemáš konkrétní implementaci nového, která je použitelná a prokazatelně lepší než to staré, tak jsou to pořád je slova a reálně to k ničemu není.

BeOS nebo Plan9 přicházely se zásadní změnou, ale neuspěly. Projekt GNU na to šel po malých částech a postupně nahradil staré proprietární programy. IMHO nahradit všechno najednou a přijít s velkou revolucí je takřka nereálné. Jako smysluplnější plán mi přijde: mít nějakou vizi a postupně nahrazovat nebo vylepšovat malé části -- postupně to do sebe začne zapadat. A až jich nahradíš dostatečné množství, tak se ta vize naplní.

[Bystroushaak]

BeOS nebo Plan9 přicházely se zásadní změnou, ale neuspěly.

Imho oba neuspěly čistě kvůli licencování a způsobu vývoje. Dalo by se totiž říct, že Windows na to šel revoluční cestou a uspěl. Takže to nebude o té revoluci tolik jako o schopnosti se prodat. Což měl GNU o dost lepší, než Plan9, který je opensource až od roku 2000, kdy už mu dávno ujel vlak. BeOS je imho podobný příběh.

Jako smysluplnější plán mi přijde: mít nějakou vizi a postupně nahrazovat nebo vylepšovat malé části -- postupně to do sebe začne zapadat. A až jich nahradíš dostatečné množství, tak se ta vize naplní.

To je iterativní vývoj, který tě nedostane z lokálního maxima, protože vede přes spoustu údolí lokálních minim. Tím nechci říct, že to vůbec nefunguje, ale nikdy tím nepřekleneš větší skok, protože uživatelé prostě nebudou používat něco, co je pro ně v tu chvíli objektivně horší. Má to ovšem svůj prostor ve chvíli, kdy máš nějaký konzistentní prototyp. Ostatně linux je pěknou ukázkou tohohle přístupu.

Osobně moc nevidím důvod, proč by nemohlo existovat obojí zároveň, pokud si to najde jiné cílové skupiny. Například u toho co jsem popsal by šlo krásně cílit na cloud a na developery a myslím, že by tam byla přidaná hodnota. Ostatně u platforem jako třeba OpenShift se to dá částečně vidět, že ta snaha hýbat se tímhle směrem je, i když neuvědomělá a připomínající tápání opilce.

[xkucf03]

Například u toho co jsem popsal by šlo krásně cílit na cloud a na developery a myslím, že by tam byla přidaná hodnota.

To jsi psal už víckrát, přemýšlel jsem nad tím už tehdy...

Proč by ale pro vývojáře (klienta) mělo být nějak výrazně lepší, že to běží na nějakém unikátním OS? Proč by si měl vybrat tohle místo PaaS běžící nad "běžným" OS? Pokud to ušetří zdroje, tak bych čekal, že to bude výrazně levnější, jinak mne to jako vývojáře nezajímá. Pokud to nabídne novou funkcionalitu, tak jakou?

Podobným směrem jde Serverless/FaaS, kde si necháš hostovat jen nějaké funkce. Ale tam nemáš ani data/stav a musíš si je ukládat zase někam jinam. Kromě specifických případů mi to přijde celkem na nic.

Zajímavé by možná bylo, kdyby někdo nabídl novou skvělou objektovou platformu, kde bys měl jak data, tak funkce/metody a celé by to dohromady fungovalo líp, než současné systémy (např. databáze + programovací jazyk).

[deda.jabko]

Zajímavé by možná bylo, kdyby někdo nabídl novou skvělou objektovou platformu, kde bys měl jak data, tak funkce/metody a celé by to dohromady fungovalo líp, než současné systémy (např. databáze + programovací jazyk).

Problem je, ze objekty mizerne skaluji. Kvuli nutnemu predpokladu: objekt = prave jedna instance, se asi neda dostat o moc dal nez je soucasny stav.

[Bystroushaak]

Pokud to ušetří zdroje, tak bych čekal, že to bude výrazně levnější, jinak mne to jako vývojáře nezajímá. Pokud to nabídne novou funkcionalitu, tak jakou?

Imho bys tím mohl vymáčknout větší rychlost vývoje komplexních systémů. V podstatě jsem o tom psal už v tom blogu - o co mi jde je nacpat některé často používané patterny do konzistentní knihovny nazvané „operační systém“.

Co se týče toho zbytku, tak je o tom blog a několik set příspěvků a nevím jestli to tu chci začít řešit odznova.

[xkucf03]

Já na jednu stranu chápu pohled autora nebo nějakého teoretika, který v tom vidí tu krásu a čistotu. Ale když se na to podívám z pohledu uživatele, což je v tomto případě programátor, který má za úkol implementovat aplikaci dle nějakého zadání, tak je mi celkem jedno, jestli je to a) objektový OS nebo b) klasický *nixový OS, nad kterým běží nějaký framework nebo třeba objektová databáze. Rozhodující jsou úplně jiné věci, než ty, zda jsou dané úlohy řešené na úrovni OS nebo na úrovni frameworku či běhového prostředí. Záleží tedy víc na tom, jak kvalitně to bude implementované, jak dobře se mi s tím bude dělat, jaká bude dokumentace, příklady, podpora... než to, zda se podařilo vynechat POSIXový FS a implementovat některé jeho části objektově a jako součást OS (a přesunout tam i část úloh, které jinde řeší frameworky a DBMS).

[deda.jabko]

Porad nechapu, proc si nesednes a nenapises funkcni prototyp nejakeho toho idealniho shellu/prostredi. Udelat jazyk (i objektovy) pro vyhodnocovani vyrazu/prikazu je na jeden vikend prace. Propojit to s necim jinym je otazka na dalsi vikend. Jako platformu poskytujici objektovou praci s daty muzes pouzit cokoliv existujiciho, napr. Javu, .NET Core, Python, Ruby, ... a mozna i Qt.

Ono je totiz jedna vec vymyslet a pak naprogramovat idealni reseni. A druha vec je, kdyz se pri dotahovani do produkcniho pouziti ukaze, ze se v praxi potrebuje neco jineho, nez si clovek ve svych predstavach idealizoval a musi se delat ustupky, aby to slo pouzit. Stalo se mi nejednou a mam takovy pocit, ze overeni s realitou by zaslouzily i jednotlive uvahy, ktere ve zdejsich diskuzich zaznely.

[JS1]

Porad nechapu, proc si nesednes a nenapises funkcni prototyp nejakeho toho idealniho shellu/prostredi.

Ja to chapu moc dobre - z vlastni zkusenosti - paralyza analyzou. (A taky chapu, ze zde jde jen o recnicky obrat.) Ale taky bych se za to primlouval.

Ja mam, podobne jako Bystroushaak, taky hodne napadu a taky nad nimi rad nezavazne premyslim. Snazim se o tom prilis nemluvit (coz se ne zcela dari), protoze ono se to bez te akce (ktera je casto zdlouhava a vyzaduje soustredeni) da opravdu mnoha lidmi vnimat jako narcismus.

[deda.jabko]

Ja to chapu moc dobre - z vlastni zkusenosti - paralyza analyzou

To moc dobre vim.

A taky chapu, ze zde jde jen o recnicky obrat.

Z me strany to byla spis takova call to action, protoze to, co si bystroushaak vysnil, je relativne snadno realizovatelne, minimalne do urovne pouzitelneho prototypu

Ja mam, podobne jako Bystroushaak, taky hodne napadu a taky nad nimi rad nezavazne premyslim. Snazim se o tom prilis nemluvit (coz se ne zcela dari), protoze ono se to bez te akce

V principu neni nic spatneho mit napady a rozvijet je. Ale bez te akce je to k nicemu. Ta akce ti totiz pomuze overit, jestli ty napady jsou zivotaschopne, nebo ne, a pripadne identifikovat v cem je problem. Z tohoto pohledu je mi sympaticky Snajpuv pristup, ktery sice ma taky velke vize, a pusobi trochu hyperaktivne, ale ma i tu silu veci posouvat vpred.

Udelat totiz neco zajimaveho (uzitecneho) neni jen to vymyslet, to je to nejjednodussi. Dal je potreba udelat funkcni prototyp, coz je sice narocne, ale muze to byt jeste zabavat. Nejhorsi je ta treti faze, kdy je potreba dotahnout veci do podoby pouzitelne i ostatnimi, coz casto predstavuje neuveritelne mnozstvi mravenci prace, do ktere se nikomu nechce.

[JS1]

Z me strany to byla spis takova call to action

Tak at mame v novem roce 2019 vsichni vic te akce!

[Bystroushaak]

Porad nechapu, proc si nesednes a nenapises funkcni prototyp nejakeho toho idealniho shellu/prostredi.

Tohle má dvě úrovně odpovědi;

Jedna je, že nechci tvořit OS, čistě protože vím, kolik by to stálo času a námahy a prostě mě to ani zas tak moc nezajímá. To že mě něco sere a na něco napíšu kritiku a pak ten názor obhajuju neznamená, že to půjdu udělat lépe. Samozřejmě kdybych to chtěl skutečně změnit, tak je to ta jediná správná cesta a souhlasím s tím, z časových důvodů ale prostě nechci. Kdybych mohl běžet ve více instancích se sdílenou pamětí a alokovat na to několik svých kopií, tak bych tomu věnoval asi něco mezi 1-3%. Takhle to prostě ani nepřijde hranici, kde bych se snažil naprogramovat nějaký prototyp, protože i kdybych si plánoval čas v rozvrhu, což teda bohužel zatím stále nedělám, tak 1-3% v něm prostě ani nebudou vidět.

Druhá úroveň odpovědi je, že na tom pracuji. Strávil jsem nějakou dobu psaní vlastního lehce odlišného klonu Selfu právě proto, abych mohl provést experimenty a proof-of-concepts na relevantní témata. Je to rozpracovaná práce, o které tu budou články. Cílem ovšem není napsat operační systém, nebo shell, ale spíš cosi jako „objektový kabinet na práci s informacemi“ v podobě něčeho, co je hybrid mezi osobní wiki, databází a programovacím jazykem zároveň. Momentálně má objektové jádro asi 362 commitů, je brutálně rozpracované a nepoužitelné kýmkoliv jiným, než mnou a to ještě jen k pokusům, ale práce pomalu postupuje. Co mě zpomaluje je rodina a práce. Momentálně kvůli tomu nejspíš ani jedno z toho nebudu eliminovat. Každopádně jak napovídá ten poslední blog, tohle není nějaký náhodný výkřik (blog jsem měl ve stashi asi 3/4 roku, nechal jsem si na něj napsat i kritiku od člověka co unixu dobře rozumí a pak jí zapracoval), přemýšlím na tohle téma asi tak pět let, mám na to napsané stohy poznámek a rozhodně se tomu chci věnovat. Přečetl jsem kvůli tomu cca desítku knih, spoustu paperů a naučil se čtyři programovací jazyky (rebol, lisp, smalltalk a Self).

Udelat jazyk (i objektovy) pro vyhodnocovani vyrazu/prikazu je na jeden vikend prace. Propojit to s necim jinym je otazka na dalsi vikend. Jako platformu poskytujici objektovou praci s daty muzes pouzit cokoliv existujiciho, napr. Javu, .NET Core, Python, Ruby, ... a mozna i Qt.

Imho budeš dobrý, když za ten víkend napíšeš parser. Překvapivě to není tak triviální, když chceš něco co není úplně stejné jako všechno ostatní. Mě to trvalo pár desítek hodin rozložených mezi pár měsíců hackování o volných chvílích sem a tam.

Ono je totiz jedna vec vymyslet a pak naprogramovat idealni reseni. A druha vec je, kdyz se pri dotahovani do produkcniho pouziti ukaze, ze se v praxi potrebuje neco jineho, nez si clovek ve svych predstavach idealizoval a musi se delat ustupky, aby to slo pouzit. Stalo se mi nejednou a mam takovy pocit, ze overeni s realitou by zaslouzily i jednotlive uvahy, ktere ve zdejsich diskuzich zaznely.

Určitě! Mám tu nodu zaměřenou jen na experimenty tímhle směrem, ze které budou časem články. Horizont je tak rok až dva.

[JS1]

Myslim, ze kdybys tohle napsal do uvodu toho blogpostu tak se predeslo znacnemu nedorozumeni. Jinak mi prijde, ze to co popisujes v blogpostu vlastne ani nepotrebujes. To co chces je IMHO system treba jako Emacs, a Emacs evidentne nepotrebuje, aby pod nim operacni system (nebo muzeme jit dal a pozadovat to po samotnem HW) byl nejak zasadne objektovy (nebo jinak elegantni).

v podobě něčeho, co je hybrid mezi osobní wiki, databází a programovacím jazykem zároveň

O necem takovem jsem uvazoval taky, ale bez toho lidskeho rozhrani. Pracovne tomu rikam jednotabulkova databaze (kazdy sloupec te velke tabulky ma nazev a typ, a kazdy radek jsou jednotlive instance objektu, a libovolny prvek muze byt null). A ta tabulka by optimalizovala zpusob ulozeni v pameti na zaklade struktury tech null. V podstate to ma dost blizko k ECS. Tady zase narazime na to, ze OOP zacina byt opravdu trochu zastarale - i hry (kde to je prirozeny pristup) od toho ustupuji, protoze to proste neni prilis prakticke.

[Bystroushaak]

Myslim, ze kdybys tohle napsal do uvodu toho blogpostu tak se predeslo znacnemu nedorozumeni. Jinak mi prijde, ze to co popisujes v blogpostu vlastne ani nepotrebujes.

Ten blogpost s tím taky nemá co dělat, to je obecná kritika. Nikde netvrdím, že to potřebuji.

Tady zase narazime na to, ze OOP zacina byt opravdu trochu zastarale - i hry (kde to je prirozeny pristup) od toho ustupuji, protoze to proste neni prilis prakticke.

No já nevím, jestli se bavíme o stejném oop. Přece jen ty prototypy jsou hodně jiné.

[deda.jabko]

Myslim, ze kdybys tohle napsal do uvodu toho blogpostu tak se predeslo znacnemu nedorozumeni. Jinak mi prijde, ze to co popisujes v blogpostu vlastne ani nepotrebujes. To co chces je IMHO system treba jako Emacs, a Emacs evidentne nepotrebuje, aby pod nim operacni system (nebo muzeme jit dal a pozadovat to po samotnem HW) byl nejak zasadne objektovy (nebo jinak elegantni).

+1

Pracovne tomu rikam jednotabulkova databaze (kazdy sloupec te velke tabulky ma nazev a typ, a kazdy radek jsou jednotlive instance objektu, a libovolny prvek muze byt null).

Mohl bys to trochu rozvinout, co by to mohlo umet, co by to resilo, atp.? Tento zpusob reprezentace dat je hodne podobny tomu, cemu se (mj.) venuju, tak by me to zajimalo.

[JS1]

Mohl bys to trochu rozvinout, co by to mohlo umet, co by to resilo, atp.? Tento zpusob reprezentace dat je hodne podobny tomu, cemu se (mj.) venuju, tak by me to zajimalo.

Muzu, ale ber to s rezervou, jde o uvahy teoreticke a nedotazene. V podstate me k tomu vedl soubeh vice veci, jedna byla, ze jsem pred casem zde uvazoval jazyk, ktery by automaticky volil datove struktury, dalsi pak, ze se mi zalibily "succinct data structures", take jsem hledal nejaky zpusob, jak si usnadnit programovani, a take by mohlo byt zajimave, kdyby nekdo znovuvynalezl (neco jako) IMS.. Takze jsem si chtel tak nejak, z prvotnich principu, vyjasnit, co by bylo potreba na tu "automatickou volbu datovych struktur".

Uvazoval jsem nad tim jako databazi v pameti, v podstate o uroven niz nez jsou tradicni databaze, ale zaroven trochu komplikovanejsi nez jen key-value store. U relacnich databazi je schema tabulek, ktere treba mohou mit dedicnost, a to komplikuje modelovani a navic to deleni na tabulky tak trochu omezuje, jak by ta databaze mohla ta data ukladat a delit. A mozna i fakt, ze existuji ruzne tabulky nakonec komplikuje psani dotazu.

Takze jsem si predstavoval, bude se to (formalne) chovat jako jedna tabulka, v ktere budou vsechny sloupce (ty budou mit typy), a nektere proste budou null. Dedicnost pak bude fungovat uplne prirozene. A je mozne jako typ sloupce treba identifikator (neco jako automaticky klic), nebo cizi klic (hodnota ciziho sloupce).

No a idea byla, ze se postavi takove API, ktere dovoli tuhle tabulku ruzne prochazet (treba najdi radek s temito sloupci, najdi dalsi radek k danemu radku, projdi vsechny tyhle sloupce tam, kde zadane sloupce nejsou null apod.). A ta struktura bude nejak sikovne zaznamenavat, jake typy "ukazatelu" (prechod na jiny radek v ramci sloupce, prechod na jiny sloupec v ramci radku, nahodne hledani radku podle sloupcu) se casto pouzivaji, a na zaklade techto statistik se pak zmeni reprezentace ulozeni tech dat (a dotazy s tim spojene), treba jestli se ukladaji po radcich nebo po sloupcich, jestli nad tim sloupcem potrebujeme index atd. Napriklad by se na zaklade techto vzoru pristupu automaticky shlukovaly jednotlive radky, a podle toho by se pak vybiralo, jak je ukladat (fakticky podle toho by se vlastne vytvarela realna struktura tabulek). A pak samozrejme bys taky tu databazi chtel menit, tim se to jeste dost komplikuje.

Samozrejme, obecne je to velice obtizny optimalizacni problem, ale rikal jsem si, ze i jenom pomerne malo informace by mohlo automaticky zoptimalizovat to, co dnes clovek musi udelat rucne. A v podstate jde o objektovy system - kazdy radek je objekt, ma nejake atributy.. Takze jsem si rikal, ze by to mohla byt cesta, jak optimalizovat objektove systemy (ktere jsou v podstate dnes dost neoptimalizovane, protoze casem vlastne nikdo nevi, jake jsou ty pristupove vzory k jednotlivym objektum, a i kdyz ano, tak je obtizne to refaktorovat).

Existuji treba jazyky, ktere umi prevest pole struktur (objektu) na strukturu poli, z duvodu lepsi lokality cache. To je v podstate analog radkoveho vs. sloupcoveho ukladani v databazi. Ja si myslim, ze pokud se opravdu zacne setrit, i na urovni jednotlivych bitu, muze to vykonu hodne pomoci. Takze jsem pak uvazoval treba o tom (ackoli predpokladam, ze to uz nektere experimentalni systemy umi), ze by se dala treba kazda hodnota kompresovat (zase volba algoritmu by mohla zalezet na zpusobu pristupu, po radcich nebo sloupcich), a aplikace nejake funkce, ktera meni ty hodnoty, by se pak dala zkombinovat primo s tou dekompresni-rekompresni funkci a poslat treba do nejakeho FPGA.

Pavel Stehule mi v puvodnim Bystroushaakovu blogpostu psal, ze staticka optimalizace dotazu do databaze se dnes nevyplati. Myslim, ze ma pravdu.. ale to predpoklada, ze zpusob ulozeni dat je predem dany. Pokud bychom spolecne optimalizovali oboji, muze to byt jinak.

Nakonec jsem dosel k tomu, ze vlastne nevim, jak to efektivne merit (tedy jak systematicky sbirat ty ruzne hodnoty). Navic merenim pocitacovych systemu se trochu zabyvam i v praci. Takze v soucasnosti me spis zajima, jak v pocitacich opravdu sikovne reprezentovat pravdepodobnost (trochu to souvisi s temi succinct strukturami a teorii informace), a to je pak taky hlavni duvod, proc se v soucasnosti opravdu intenzivne zabyvam otazkou zda P=NP. (Chapu, ze tohle asi pusobi dost blaznive, ale proste tam me zatim zavedla kralici nora.)

[deda.jabko]

V podstate me k tomu vedl soubeh vice veci, jedna byla, ze jsem pred casem zde uvazoval jazyk, ktery by automaticky volil datove struktury

To je dalsi docela zajimava vlastnost, kterou by si obecne programovaci jazyky mohly pujcit z databazi, protoze ty to uz pouzivaji, i kdyz v malinko skryte forme. Pouziti/nepouziti indexu v podstate odpovida automaticke volbe datove struktury (reprezentace dat), to same konverze na hash-tabulku nebo pomocne setrideni. Bylo by fajn mit neco takoveho v obecnych jazycich... jeden clovek od nas na necem takovem pracuje, ale jelikoz to nema jeste publikovane, prislo by mi nevhodne to (misto nej) rozebirat verejne.

take jsem hledal nejaky zpusob, jak si usnadnit programovani, a take by mohlo byt zajimave, kdyby nekdo znovuvynalezl (neco jako) IMS..

S IMS nemam zkusenost, slo by vypichnout nejake zajimave vlasnosti, ktere by stalo znovuvynalezt?

No a idea byla, ze se postavi takove API, ktere dovoli tuhle tabulku ruzne prochazet (treba najdi radek s temito sloupci, najdi dalsi radek k danemu radku, projdi vsechny tyhle sloupce tam, kde zadane sloupce nejsou null apod.). A ta struktura bude nejak sikovne zaznamenavat, jake typy "ukazatelu" (prechod na jiny radek v ramci sloupce, prechod na jiny sloupec v ramci radku, nahodne hledani radku podle sloupcu) se casto pouzivaji, a na zaklade techto statistik se pak zmeni reprezentace ulozeni tech dat (a dotazy s tim spojene), treba jestli se ukladaji po radcich nebo po sloupcich, jestli nad tim sloupcem potrebujeme index atd.

Mohl bys nastinit konkretni situace, kde by to mohlo mit prinos? Intuitivne bych rekl, ze to bude mit nezadbatelnou rezii, ktera nevyvazi prinos.

Samozrejme, obecne je to velice obtizny optimalizacni problem, ale rikal jsem si, ze i jenom pomerne malo informace by mohlo automaticky zoptimalizovat to, co dnes clovek musi udelat rucne. A v podstate jde o objektovy system - kazdy radek je objekt, ma nejake atributy..

To mi ponekud pripomina FCA. ;-] Nekteri lidi to pouzivaji i v oblasti SW inzenyrstvi, zpusobem, jak navrhujes ... ale je tu problem s tim, ze ty shluky (koncepty) tvori svaz, kdezto v OOP chces vetsinou hierarchii trid. Na druhou stranu to muze sympaticky licovat s tim ECS, jak jsi zminoval, ale to si musim nechat chvilku ulezet.

Pokud bychom spolecne optimalizovali oboji, muze to byt jinak.

Osobne si myslim, ze primarni je volba datove struktury (reprezentace dat) a volba algoritmu (zpusob samotneho zpracovani) je az sekundardni a plyne z te reprezentace. Oni to delaji i ti databazisti, jen si to prilis neuvedomuji.

[Josef Kufner]

Použití/nepoužití indexu má k automatické volbě datové struktury celkem daleko. Při volbě indexu má databáze k dispozici docela hodně metadat, která jí dají jen několik málo možností, jaký index použít. Koukne se, podle jakých sloupečků se filtruje, joinuje a řadí. Přihodí trochu statistik, který index by asi ušetřil nejvíce práce a má hotovo. Zajímavost tohoto problému je v tom to udělat rychle a mít šikovné heuristiky, které dobře odhadnou pracnost a možnou úsporu. V principu to však je docela přímočará záležitost.

Na druhou stranu, odvodit datovou strukturu z kódu programu je o docela jiném přístupu. Není důraz na rychlost volby, ale o to více možností je. Navíc je problém i se vstupními daty, neboť běžné programy nejsou zdaleka tak unifikované jako SQL dotazy. Otázka kde sehnat vstupní data pro volbu datové struktury je tady důležitější, než samotná volba té struktury (to je v podstatě jen nalezení nejmenšího společného typu).

[deda.jabko]

Použití/nepoužití indexu má k automatické volbě datové struktury celkem daleko.

Ale koncepcne to volba datove struktury je. V zakladnim pripade mas neusporadanou mnozinu zaznamu, s pouzitim indexu se ti z toho stane usporadana mnozina zaznamu. Jina struktura, jine algoritmy. Matouci muze byt to, ze jsi na tuto konverzi jiz pripraveny tim indexem. Vsimni si, ze vedle toho DB casto delaji to, ze neusporadanou mnozinu (pokud neni index, nebo i kdyz je) prevedou treba na hash tabulku nebo jako mezikrok setridi. Coz lze opet chapat jako zmenu reprezentace dat (resp. automatickou volbu datove struktury).

Na druhou stranu, odvodit datovou strukturu z kódu programu je o docela jiném přístupu.

Ale uloha nezni odvodit datovou strukturu z kódu programu, ale odvodit datovou strukturu z dostupnych dat (a na zaklade toho odvodit kod programu.)

Otázka kde sehnat vstupní data pro volbu datové struktury je tady důležitější, než samotná volba té struktury

Je nutne dodatecne doplnit data o metadata, nebo prostredky, ktere tato metadata poskytuji. To v podstate odpovida ruznym statistikam, ktere sbiraji databaze o tabulkach. V obecnych programech, pokud chces automatickou volbu datovych struktur, musis navic urcit vztah mezi metadaty o vhodnou reprezentaci. Na prvni pohled to vypada komplikovane, ale casto staci pracovat jen se zakladnimi vlastnostmi dat (napr. jejich velikosti), aby to davalo rozumne vysledky.

[Josef Kufner]

Příklad s volbou indexu není moc dobrý – je poněkud zavádějící, ale dává to smysl. Vstupem volby datové struktury je typ prohledávaných dat, způsob dotazování a vyhledávací algoritmus. Výstupem pak je optimalizovaná struktura pro ten daný algoritmus, která odkazuje na původní data. Otázkou je, jak moc se tento příklad dá zobecnit, neboť tu je příliš málo proměnných. V podstatě tu je sada algoritmů, které umí používat nějaké typy indexů nad nějakými typy dat. To zní spíš jako úloha pro typový systém a šablony (à la C++) – vybrat pasující dílky skládanky, a pokud je více možných řešení, tak podle statistik odhadnout to nejlepší.

Ale uloha nezni odvodit datovou strukturu z kódu programu, ale odvodit datovou strukturu z dostupnych dat (a na zaklade toho odvodit kod programu.)

To je jeden a ten samý problém, jen se díváš z trochu jiného úhlu.

Je nutne dodatecne doplnit data o metadata, nebo prostredky, ktere tato metadata poskytuji.

No to je právě ten problém. Jakmile tato metadata máš, je odvození struktur už relativně snadné. Další podstatná otázka je, zda taková metadata nebudou komplikovanější než prosté tradiční definování typů. Pak tu jsou věci, které jen tak neodvodíš – např. meze a vztahy mezi sloupečky (např. platnost záznamu od–do).

[deda.jabko]

Vstupem volby datové struktury je typ prohledávaných dat, způsob dotazování a vyhledávací algoritmus.

Mas od toho prilis maly odstup, divas se na to prilis pohledem implementace db. Ono uz ten pojem typ prohledávaných dat je zavadejici, protoze zahrnuje dva pojmy -- mnozinu pripustnych hodnot a reprezentaci tech hodnot. Z pohledu korektnosti programu je dulezite to prvni, z pohledu vykonavani programu to druhe. Tim, ze maji db volnou ruku v tom, jakou reprezentaci dat vyberou, mohou volit i vhodne algoritmy.

To zní spíš jako úloha pro typový systém a šablony (à la C++)

Je to uloha pro typovy system, ale sablony ala C++ nic neresi, protoze ty v dobe jejich zpracovani vubec nemaji predstavu, s jakymi daty se potkaji.

Otázkou je, jak moc se tento příklad dá zobecnit, neboť tu je příliš málo proměnných. V podstatě tu je sada algoritmů, které umí používat nějaké typy indexů nad nějakými typy dat.

Kdyz odstoupis od indexu a budes se na to divat pohledem ruznych reprezentaci, najdes podobne ulohy. Napr. treba ruzne reprezentace matic (ridke/huste/radkove/sloupcove) pro ruzne typy dat a uloh.

To je jeden a ten samý problém, jen se díváš z trochu jiného úhlu.

Ten uhel je dost podstatny.

Další podstatná otázka je, zda taková metadata nebudou komplikovanější než prosté tradiční definování typů.

Pro jednotlive ulohy je tradicni definovani typu dostatecne. V prostredi, kde apriori neznas povahu dat (podobne jako v databazich) uz to muze v konecnem dusledku znamenat vyznamny prinos.

Pak tu jsou věci, které jen tak neodvodíš – např. meze a vztahy mezi sloupečky (např. platnost záznamu od–do).

Nechapu, jak to s tim souvisi.

[Josef Kufner]

Ale v databázích tu povahu dat máš předem popsanou databázovým schematem. Sice to je až za běhu a nikoliv při kompilaci, ale to je jen implementační detail – klidně by se databáze mohla překompilovávat při každé změně schematu. Obdobně ty C++ šablony. Ty mají velice dobrou představu o datech se kterými pracují, neboť to při překladu do nich programátor zadrátoval. Z pohledu řešeného problému je úplně jedno, jestli se něco kompiluje trochu dříve tradičním kompilátorem či později interpretem.

Pak tu jsou věci, které jen tak neodvodíš – např. meze a vztahy mezi sloupečky (např. platnost záznamu od–do).

Nechapu, jak to s tim souvisi.

Tady ti totiž nestačí statické určení rozsahu přípustných hodnot. Máš dva sloupečky s časem a hodnota v druhém musí být větší než hodnota v prvním. Tedy aby konec platnosti byl až po začátku platnosti. Jak takové omezení odvodit? A z čeho by se to vůbec dalo odvodit?

[deda.jabko]

Ale v databázích tu povahu dat máš předem popsanou databázovým schematem.

To je pouze cast informace. Pri kompilaci dotazu se bere v potaz cela rada dalsich faktoru, pocet zaznamu, rozlozeni hodnot, atp. a na zaklade toho se voli reprezentace, se kterou algoritmy budou pracovat, napr. pro mala data se nactou do pameti do hash tabulky, jindy se budou prochazet sekvencne z disku, atp.

Ty mají velice dobrou představu o datech se kterými pracují, neboť to při překladu do nich programátor zadrátoval.

To ale znamena, ze programator musi znat, jak presne data budou vypadat, jak se s nimi bude presne pracovat. Jsou situace, kdy tyto podminky nejsou splneny a v takovem pripade se voli nejake standardni reseni, nebo odhad, jak to asi bude vypadat, co se bude pouzivat, coz muze byt v konecnem dusledku suboptimalni reseni.

Jak takové omezení odvodit? A z čeho by se to vůbec dalo odvodit?

Ja takove odvozeni ale nechci delat. Zopakuji se a doplnim:

pojem typ prohledávaných dat je zavadejici, protoze zahrnuje dva pojmy -- mnozinu pripustnych hodnot a reprezentaci tech hodnot. Z pohledu korektnosti programu je dulezite to prvni, z pohledu vykonavani programu to druhe.

Ty mluvis o te prvni casti, ja zase o te druhe.

[Josef Kufner]

Takže chceš do programu zabudovat automatizovaný profiler a JIT? Čas od času by se zkontrolovalo, že program nikde nedrhne a případně se změnil způsob reprezentace na něco vhodnějšího? Tedy že programátor pořád bude psát celý program, ale použije dostatečně vysokoúrovňové nástroje, aby ponechal prostor pro automatickou optimalizaci?

[JS1]

Nevim, jestli to chce deda.jabko, ale ja to rozhodne chci. Pokud budu mit o vikendu vic casu, pokusim se jeste nektere myslenky dale rozvinout.

[deda.jabko]

Tedy že programátor pořád bude psát celý program, ale použije dostatečně vysokoúrovňové nástroje, aby ponechal prostor pro automatickou optimalizaci?

Ano, presne toto.

Takže chceš do programu zabudovat automatizovaný profiler a JIT?

Ten profiler nechci/nepotrebuji (a JIT neni nutny).

Čas od času by se zkontrolovalo, že program nikde nedrhne a případně se změnil způsob reprezentace na něco vhodnějšího?

Relacni DB (v zakladnim rezimu prace) taky takto nepracuji.

Mne (a asi i JS) by se libilo, kdybys mel data a k tomu program (dotaz, algoritmus) a behove prostredi podle metadat zvoli vhodnou reprezentaci a algoritmus pro vraceni vysledku.

[okbob]

Aby se vůbec mohla navrhnout nějaká optimalizace, tak se musely databáze natlačit do hodně sevřeného konceptu - relační model, SQL. Když se nad tím člověk zamyslí, tak ta funkcionalita je hodně omezená (vůči obecnému programování), ale přitom dostatečná pro dost úloh. V podstatě databáze neumí nic jiného než SAVE, LOAD, SORT, FILTER, AGGREGATE, a JOIN. A s tím se dělá veškerá databázová paráda. Základem úspěchu je navrhnout relativně malý konzistentní kompaktní koncept. Všechno ostatní dopadá špatně.

V té diskuzi vidím určitou souvislost s GraphGL - kdy někde máte data, a pak knihovnu, která je schopná na základě popisu, co chcete, vygenerovat SQL, a poslat vám výsledek. Dovedu si představit masivnější nasazení GraphGL - jede to na jednoduchém protokolu, má to jednoduchý model.

[deda.jabko]

Aby se vůbec mohla navrhnout nějaká optimalizace, tak se musely databáze natlačit do hodně sevřeného konceptu - relační model, SQL.

Radu uloh jde redukovat na podobne omezeny koncept a sadu operaci, o kterych jde uvazovat podobnym zpusobem, napr. matice, vektory, mnoziny, ... Ze to neni uplne okrajove, jde videt i na rostouci oblibe knihoven/nastroju typu TensorFlow.

Základem úspěchu je navrhnout relativně malý konzoistentní kompaktní koncept.

To je dobry predpoklad, ale nerekl bych, ze je nutny.

Všechno ostatní dopadá špatně.

Jako protipriklad by slo vzit treba vektorove operace na urovni CPU. Maji uplatneni jen v urcitem typu omezenych uloh, i tak maji smysl. Mas pro ne explicitni podporu na urovni prekladace/jazyka formou specializovanych datovych typu. Rada prekladacu dokaze vhodne ulohy implicitne prevest tak, aby vyuzivaly vektorove instrukce. Je otazka, proc by to v principu nemohlo fungovat i jinde.

[okbob]

Z mého pohledu jsou téměř všechny věci kolem CPU hodně omezené - pořád je to kalkulačka. Na úrovni CPU obyčejně se nikdo nerozplývá nad tématy - naprogramujeme něco, nevíme co, nevíme jak.

[deda.jabko]

Na úrovni CPU obyčejně se nikdo nerozplývá nad tématy - naprogramujeme něco, nevíme co, nevíme jak.

Nevim, co presne myslis obratem na urovni CPU. Ale dnesni programovani je z principu stylem naprogramujeme něco, nevíme co, nevíme jak.

Kdyz si vezmes bezne aplikacni programatory Java/C#, tak ti z principu (diky bytecode) nemaji absolutne predstavu o tom, jak kod bude vykonavan nebo jak presne budou data ulozena v pameti.

Kdyz se posuneme o uroven niz, na uroven systemovych programatoru, kteri pisi kod v C, tak ti obvykle maji predstavu o tom, jak bude jejich kod provaden. Casto se jedna jen o iluzi. Dovolim si odkazat na muj pet let stary blog.

Je tam ukazka toho, co udela prekladac s vypoctem faktorialu rekurzivnim zpusobem (a neni to koncova rekurze). S prepinacem -O0 vypadne naivni kod, s prepinacem -O1 dostaneme uz vyladenejsi kod, ale odpovidajici kodu v C. Prepinac -O2 vygeneruje uplne jiny algoritmus, tj. prevede (nekoncovou) rekurzi na cyklus. A jako bonus, prepinac -O3 vygeneruje kod s cyklem a vyuzitim vektorovych instrukci.

Takze ani v C si nemuze byt clovek jisty tim, co se bude v prubehu vykonavani programu dit.

Ale klidne muzeme jit jeste o uroven niz. I kdyz se clovek pusti do programovani v assembleru, tak si provadenim instrukci nemuze byt vubec jisty. Mas tam prevod na mikrooperace, prejmenovani registru, preskladani operaci pro lepsi zaplneni pipeline, spekulativni vyhodnoceni, atd. coz jsou opet optimalizace, nad kterymi programator nema kontrolu. A Meltdown+Spectre jen dokazuji, ze ani navrhari procesoru nemaji nad vsim kontrolu.

[kralyk z abclinuxu]

Ale klidne muzeme jit jeste o uroven niz. I kdyz se clovek pusti do programovani v assembleru, tak si provadenim instrukci nemuze byt vubec jisty. Mas tam prevod na mikrooperace, prejmenovani registru, preskladani operaci pro lepsi zaplneni pipeline, spekulativni vyhodnoceni, atd. coz jsou opet optimalizace, nad kterymi programator nema kontrolu.

+1. Viz např. tento poučný blog a zejména nakonci to povídání o mov a xor jak mov rax, rbx nebo xor rax, rax se dekódují jen na přejmenování interních registrů a s nějakým kopírováním dat nebo ALU nemají nic společného.

Koneckonců, instrukce mov je turingovsky úplná.

Je pravda, že x86 je v tomhle asi trochu extrém, ale i tak, IMHO jiné rozšířené architektury na tom nebudou až tak lépe... Doby, kdy CPU byla fakt jen kalkulačka, jsou dávno dávno pryč.

[okbob]

To je zhruba analogie se zápisem SQL, a pak jeho vykonáním. Neříkám, že to je to jednoduchá úloha - nicméně je tam jasné zadání, programovací jazyk má relativně omezený počet instrukcí a překládá se to do něčeho, co má také jasně definovanou strukturovanou omezenou povahu. Rozhodně, když už se bavíme programu v programovacím jazyku, jako je C, tak rozhodně neplatí "nevíme co". Sémantika je daná Cčkem. Pak vlastní realizace je už je jen technologický detail. Ve výsledku je to posloupnost relativně jednoduchých byť extrémně rychlých operací.

[deda.jabko]

To je zhruba analogie se zápisem SQL, a pak jeho vykonáním.

V tom pripade, se evidentne jedna o problem/typ ulohy, ktery neni omezeny jen na SQL, ale v praxi se jednotlive jeho instance vyskytuji a maji vhodna prakticky pouzitelna reseni. Coz je dobry priznak.

Rozhodně, když už se bavíme programu v programovacím jazyku, jako je C, tak rozhodně neplatí "nevíme co". Sémantika je daná Cčkem. Pak vlastní realizace je už je jen technologický detail.

Ta semantika musi byt dana vzdy, to plati i v tom SQL, neni duvod, proc by nesla definovat semantika i pro jine oblasti a hlavne, proc by si ji nemohli definovat samotni programatori pro konkretni ulohy a ty technologicke detaily by vyresil prekladace/runtime

Pomohu si analogii. Z jazyku typu C, Java nebo Pascal, by clovek snadno nabyl dojmu, ze ridici struktury jazyka, treba for-cyklus, musi byt nezbytne nedilnou soucasti jazyka a prekladace, aby programator znal jejich semantiku a prekladac vedel, jake instrukce ma vlastne generovat.

A pak jsou tu jazyky, kde neco takoveho neni definovano a programator ma volnost si neco takoveho definovat, vcetne toho cyklu for. V Lispu k tomu jsou makra, ve Scale k tomu slouzi treba predavani parametru jmenem, pricemz prekladac je schopen generovat odpovidajici kod. V Lispu je dokonce dobrym zvykem vytvorit si nejdriv mini-jazyk pro reseni uloh z konkretni oblasti a az pak na tom stavet samotne programy.

A ted se vratim k puvodnimu problemu. Podobne jako nektere jazyky umoznuji implementovat for-cyklus vlastnimi prostredky (stejne jako dalsi ridici struktury, ktere programator chce/potrebuje), byly by hezke mit jazyk, ktery umozni vlastnimi prostredky implementovat zpracovani dat ala SQL (stejne jako dalsi ulohy z jinych oblasti.)

[Josef Kufner]

Zkus být trochu konkrétní a ukaž pár příkladů jiných než SQL, kde by se tohle dalo reálně využít.

[deda.jabko]

Zamerne nechci byt konkretni, protoze se to pak zvrhava v diskuze o partikularnich problemech resenich.

Jako priklad by sly pouzit treba analyza dat a prace s maticemi. Pro jeden typ dat se hodi huste matice, pro jine ridke, pro mala data se hodi jina reprezentace nez pro velka. Pro nektere operace je vhodnejsi mit data po radcich, pro jina po sloupcich. Pro mala data muze byt vhodnejsi data zpracovat na CPU pres SIMD instrukce, pro jina/velka data muze byt vhodnejsi to prehnat pres GPU. Tady pak zacne hrat roli, jestli pro nasledujici operace je vyhodnejsi data nechat na grafice a dal s nimi pracovat tam, nebo to presunout do operacni pameti a pokracovat s CPU.

U tohoto typu uloh to vetsinou skonci tak, ze se bud kod napise pro CPU nebo GPU a vysledek je pak do znacne miry suboptimalni, pokud mas data o ruznych charakteristikach. Nebo se to snazis napsat optimalne s existujicimi prostredky a znalostmi (resp. clovek je casto veden v podstate nejakou svou intuici, co by mohlo byt rychle), coz je teda dvoji prace, velice blbe/zdlouhave na ladeni a casto intuice cloveka zavede na blbou cestou.

[xkucf03]

Zní to jako takový lepší JIT :-) Užitečnost v tom vidím, ale IMHO bude dost problém v tom, že na optimální způsob přijdeš až ve chvíli, kdy už data máš, nebo spíš ve chvíli, kdy jsi jich už nějakou část zpracoval. Relační databáze mají v tomhle výhodu, že mají předem napočítané statistiky a vědí zhruba, jaká data v jednotlivých tabulkách mají. Ale v tvém případě data přicházejí „odkudsi zvenku“ a ty o nich nic moc předem nevíš. Musel bys je nějak prozkoumat, což ale znamená si je načíst a někam odložit. A nebo je začít zpracovávat nějakým výchozím způsobem, a pak případně přepnout na jiný. Ale tady je otázka, jak efektivně přehazovat rozdělanou úlohu třeba z toho procesoru na grafickou kartu. A pak taky: jak moc se dá spolehnout na to, že budoucí data budou mít podobné charakteristiky jako vzorek, který jsme načetli na začátku zpracování. A co když pracně zoptimalizuji způsob zpracování a vzápětí zjistím, že jsem na konci dat, která jsem měl zpracovat?

[deda.jabko]

Zní to jako takový lepší JIT

Rikej si tomu JIT, chces-li, ale podstatny rozdil od soudobych JIT by mel byt v tom, ze behove prostredi rozhoduje o strukture dat a zvolenych operacich na zaklade nejake charakteristiky dat, se kterymi se pracuje.

Užitečnost v tom vidím, ale IMHO bude dost problém v tom, že na optimální způsob přijdeš až ve chvíli, kdy už data máš, nebo spíš ve chvíli, kdy jsi jich už nějakou část zpracoval

V tom nevidim problem. Pokud s nejakymi daty pracujes delsi dobu, neni problem si drzet jejich metadata/charakteristiky podobne jako to dela RDBMS. Vedle toho rada uloh (a ty, se kterymi se obvykle setkavam) probihaji tak, ze se data nactou/namapuji do pameti, a pak se prevedou do nejake reprezentace, ktera se prohani serii transformaci. Neni duvod, proc neziskat charakteristiky pri nacteni a na zaklade toho nechat zvolit optimalni zpusob transformace.

Ale tady je otázka, jak efektivně přehazovat rozdělanou úlohu třeba z toho procesoru na grafickou kartu.

To neni zase tak zasadni otazka, to je prakticky implementacni detail. Mnohem zajimavejsi je, jak vyjadrovat ekvivalenci mezi typy, jak vyjadrit ekvivalenci mezi jednotlivymi operacemi, atp.

A co když pracně zoptimalizuji způsob zpracování a vzápětí zjistím, že jsem na konci dat, která jsem měl zpracovat?

To se ti klidne stane s beznym JITem, pokud ale naplanujes vypocet predem, tak to nehrozi.

[xkucf03]

V tom nevidim problem. Pokud s nejakymi daty pracujes delsi dobu, neni problem si drzet jejich metadata/charakteristiky podobne jako to dela RDBMS. Vedle toho rada uloh (a ty, se kterymi se obvykle setkavam) probihaji tak, ze se data nactou/namapuji do pameti, a pak se prevedou do nejake reprezentace, ktera se prohani serii transformaci. Neni duvod, proc neziskat charakteristiky pri nacteni a na zaklade toho nechat zvolit optimalni zpusob transformace.

Často ta data budou ležet na (pomalém) disku nebo síti a načtou se odtamtud později. Další věc je, že všechno může záviset třeba jen na jediném bitu, jehož hodnotu se dozvíš až na poslední chvíli, a tento bit přehodí výhybku a rozhodne o tom, že se v programu bude dít něco úplně jiného, než jsi původně myslel. V SQL tohle buď nejde napsat nebo se to běžně nedělá, protože autor SQL dotazu ví, že by tím škodil sám sobě a že by si to rozbil. U obecného algoritmu/programování se ale obávám, že se do takové situace dostaneš, aniž bys cokoli zlého tušil.

Neříkám, že to vůbec nejde, nebo že to není zajímavé… Jen mi to přijde řádově složitější než podobné optimalizace u relačních/SQL databází.

Ještě si dovedu představit, že by se automaticky rozhodlo o tom, zda se pro uložení dat použije LinkedList nebo ArrayList (ty bys všude pracoval jen s rozhraním List a instanci by sis nechal vytvořit nějakou továrnou). Pokud ten algoritmus bude jednoduchý, nebude tam reflexe nebo moc podmíněných kroků a výhybek, tak by to šlo. Nicméně i u takto triviálního případu se ti může stát, že data potřebuješ do seznamu nastrkat v okamžiku A, zatímco o optimálním způsobu uložení jsi schopný rozhodnout až v okamžiku B. Pokud to bude stát za to (což se ale můžeš dozvědět až v okamžiku C), tak můžeš data přesypat a začít pracovat s vhodnější strukturou a pořád se to ještě může vyplatit, i když jsi to netrefil napoprvé. Nicméně pokud jako programátor víš něco, co stroj neví, tak to můžeš zohlednit a vybrat vhodnou datovou strukturu předem sám. Ano, připomíná to situaci Assembler vs. C, kde si spousta lidí myslela, že dokáže optimálně poskládat instrukce a říct, jak se to má dělat, a nakonec se ukázalo, že kompilátor to udělá líp než oni. K něčemu takovému to zřejmě směřuje i na vyšších úrovních, ale asi to ještě chvíli potrvá…

[Josef Kufner]

Mám z toho už delší dobu pocit, že by se to dalo řešit knihovnou kolekcí, které by si automaticky vybíraly způsob uložení dat. Něco jako právě zde zmíněný seznam nebo níže zmíněný LINQ. Statickou analízou by se dalo odhadnout, co bude lepší použít. Za běhu by to šlo také, i kdyby se to mělo jednou spustit tak a podruhé jinak (nad různými daty), a pak nasbíranými statistikami nakrmit přepínací heuristiku.

Pokud by se něco takového mělo řešit na obecnější úrovni, než jsou kolekce s unifikovaným API, tak to bude vyžadovat napojit na nějaký (polo)automatický programovací nástroj a to jaksi nemáme.

[deda.jabko]

Mám z toho už delší dobu pocit, že by se to dalo řešit knihovnou kolekcí, ...

Proto jsem se nechtel poustet do nejakych konkretnich prikladu, protoze pak se vyroji reseni jednotlivych konkretnich problemu.

Pokud by se něco takového mělo řešit na obecnější úrovni, než jsou kolekce s unifikovaným API, tak to bude vyžadovat napojit na nějaký (polo)automatický programovací nástroj a to jaksi nemáme

No, a proto je to zajimava uloha...

[Josef Kufner]

A máš nějaký jiný příklad než SQL databázi a knihovnu kolekcí? Ono je mnohem jednodušší zobecnit pár konkrétních příkladů, kouknout co mají společného a vyházet nepodstatné blbosti, než vařit z vody a doufat, že něco bude a to něco k něčemu bude.

[deda.jabko]

Mam, ale nemam potrebu tu resit detaily.

[deda.jabko]

Další věc je, že všechno může záviset třeba jen na jediném bitu, jehož hodnotu se dozvíš až na poslední chvíli, a tento bit přehodí výhybku a rozhodne o tom, že se v programu bude dít něco úplně jiného, než jsi původně myslel.

Proc by se to melo dit?

V SQL tohle buď nejde napsat nebo se to běžně nedělá, protože autor SQL dotazu ví, že by tím škodil sám sobě a že by si to rozbil.

V SQL taky programator netusi, jak bude zpracovani dotazu probihat. I kdyz, jen tak bokem, hinting je oblibena ekvilibristika treba Oraclovskych adminu.

Nicméně pokud jako programátor víš něco, co stroj neví, tak to můžeš zohlednit a vybrat vhodnou datovou strukturu předem sám.

To je vyreseni problemu, ktery neni problem. Zajimavejsi je ta opacna cast, kdyz jako programator nevis neco, co stroj bude vedet. To je pripad toho SQL, kdy formulujes dotaz (pri tvorbe programu) a az stroj rozhodne, jak provede zpracovani dat (za behu programu).

[kralyk z abclinuxu]

A pak jsou tu jazyky, kde neco takoveho neni definovano a programator ma volnost si neco takoveho definovat, vcetne toho cyklu for. V Lispu k tomu jsou makra, ve Scale k tomu slouzi treba predavani parametru jmenem, pricemz prekladac je schopen generovat odpovidajici kod. V Lispu je dokonce dobrym zvykem vytvorit si nejdriv mini-jazyk pro reseni uloh z konkretni oblasti a az pak na tom stavet samotne programy.

Názory na tohle se různí, ale osobně si nemyslim, že by se LISPu podařilo ukázat, že tohle je dobré/žádoucí.

A ted se vratim k puvodnimu problemu. Podobne jako nektere jazyky umoznuji implementovat for-cyklus vlastnimi prostredky (stejne jako dalsi ridici struktury, ktere programator chce/potrebuje), byly by hezke mit jazyk, ktery umozni vlastnimi prostredky implementovat zpracovani dat ala SQL (stejne jako dalsi ulohy z jinych oblasti.)

LINQ? Případně nejsou různé MapReducy v podstatě taky tohle?

[deda.jabko]

Názory na tohle se různí, ale osobně si nemyslim, že by se LISPu podařilo ukázat, že tohle je dobré/žádoucí.

To je na nazoru kazdeho soudruha. Ja treba uznavam situace, kdy je tady to rozumne reseni a kdy nerozum.

Ze existuje poptavka po ruznych DSL (mini-jazycich), jde videt i v soudobem stylu programovani, i kdyz tam to neni tak vyrazne jako v tomu Lispu. I v takove ultrakonzervativni Jave se bezne pouzivaji ruzne formy DSL (zalozene na anotacich).

LINQ?

LINQ je priklad DSL a tedy toho, o cem se domnivas, ze to, co se pouziva v Lispu, by nebylo dobre nebo zadouci. V podstate to odpovida tomu vlastnimu "for". Jen trochu na steroidech.

Případně nejsou různé MapReducy v podstatě taky tohle?

Nerekl bych, to je jen zpusob, jak popsat operace s daty.

[kralyk z abclinuxu]

LINQ je priklad DSL a tedy toho, o cem se domnivas, ze to, co se pouziva v Lispu, by nebylo dobre nebo zadouci. V podstate to odpovida tomu vlastnimu "for". Jen trochu na steroidech.

Nemyslim si, že to je to samý. Konvenční jazyky mají typicky poměrně velkej zadrátovanej spoječnej základ, se kterým nic neuděláš. Metaprogramování mají typicky nějakým způsobem ohraničené a omezené, což Lisp považuje za velký špatný, ale IMHO je to reálně dobře, protože metaprogramované DSL se díky tomu používají opravdu až když ten společný základ nestačí. Není to taková ta metaanarchie. No a reálně používané lispy to koneckonců mají taky spíše tímhle směrem, ačkoli jsou asi stále flexibilnější...

LINQ je DSL, ale je daný jazykem.

Nerekl bych, to je jen zpusob, jak popsat operace s daty.

A to SQL není?

[deda.jabko]

A to SQL není?

Nerekl bych, to je jen zpusob, jak popsat operace s daty.

Map/Reduce bez problemu implementujes i v C a bude to na par set radku. S SQL to tak easy nebude, protoze to mnozstvi uloh, ktere resi je mnohem vetsi.

[kralyk z abclinuxu]

Aha, ok, to asi jo no...

[JS1]

Další podstatná otázka je, zda taková metadata nebudou komplikovanější než prosté tradiční definování typů. Pak tu jsou věci, které jen tak neodvodíš – např. meze a vztahy mezi sloupečky (např. platnost záznamu od–do).

Tohle se da ruzne resit.

Napriklad, mohlo by byt uzitecne vedet, ze ackoli data v nejakem sloupecku mohou formalne nabyvat ruznych hodnot (treba 64-bit integer), ve skutecnosti jde v drtive vetsine pripadu o mala cisla (nebo jejich delty jsou mala cisla). V takovem pripade by bylo mozne ukladat je male hodnoty, a velke ulozit v jine, specialni tabulce. A jelikoz je vnitrni rezie CPU mala v porovnani s pristupem do pameti, statisticky vzato se tim cas muze usetrit.

Nebo na retezcich - retezce mohou byt dlouhe, presto nektere mohou byt velmi caste. Slo by s nimi pracovat pomoci vhodneho Huffmanova kodovani, a teprve v pripade, kdy chceme dostat (tisknout) vysledek, by se prevedly na retezcovou reprezentaci.

Vztahy mezi sloupecky jsou daleko tezsi, ale zase, princip je stejny - postavit (automaticky) nejaky statisticky model nad tim, jak vypada bezny radek tabulky. Z nej pak takove veci, jako ze jedna hodnota je mirne vetsi nez druha (rozdil je male kladne cislo) mohou vypadnout.

Trochu to souvisi s kompresi, akorat my nechceme brat vsechny vystupni bity stejne, ale chceme jim take priradit nejake pravdepodobnosti na zaklade toho, jak s kterou hodnotou potrebujeme pracovat. Takze je to trochu obecnejsi uloha nez jen komprese.

Samozrejme disclaimer, jak tu zminil deda.jabko - tohle jsou takove dost teoreticke vize ceho by mohlo byt zajimave dosahnout, v praxi by se pak slo postupne po malych krocich nejak timto smerem, at uz inzenyrsky nebo teoreticky. Proto me tak zajima teorie pravdepodobnosti a informace aplikovana na datove struktury - mam pocit, ze je to velke otevrene pole (dokonce bych rekl, ze succinct data structures jsou jen pocatek velmi zasadni revoluce v computer science, jejiz obrysy tak nejak matne vnimam).

[kralyk z abclinuxu]

Nebo na retezcich - retezce mohou byt dlouhe, presto nektere mohou byt velmi caste. Slo by s nimi pracovat pomoci vhodneho Huffmanova kodovani, a teprve v pripade, kdy chceme dostat (tisknout) vysledek, by se prevedly na retezcovou reprezentaci.

Není to sice úplně to samé, ale už dnes se občas používají např. Tries pro uskladnění množství stringů a pak editory běžně používají Ropes.

dokonce bych rekl, ze succinct data structures jsou jen pocatek velmi zasadni revoluce v computer science, jejiz obrysy tak nejak matne vnimam

To téma je zajímavé a ty nápady, co tu píšeš, taky, nicméně úplně nejsem přesvědčen, že ta cesta CPU↔paměť je skutečně tak zásadní bottleneck a že to řešení je na místě.

Navíc je otázka, jestli ta optimalizace pomocí těch succint struktur je skutečně optimalizace. Např. u těch stringů, ve chvíli kdy budeš chtít s tím stringem nějak pracovat, může ta nutnost dekomprese způsobit, že přibudou zápisy do paměti.

IMHO tohle je něco, co se nedá vymyslet teoreticky, aniž bys předtím velmi důkladně měřil všelijaké výkonové charakteristiky reálného SW.

[JS1]

Ugh, tak snad konecne odpoved.

Predne jsem chtel podotknout, ze mam proste silny intuitivni pocit, vzhledem k tomu, jak funguji moderni procesory (jsou omezene datovym tokem mezi jadrem a pameti), ze bychom hodne vykonu ziskali proste jen extremne efektivnim ukladanim dat do pameti. Prikladem mohou byt prave ty succinct struktury (tohle me ohromilo). Takze jedna z motivaci, proc se tim zabyvat (ackoli se tim ted tedy nezabyvam) je prave v tom, mit opravdu dobry optimalizator, jak data ukladat do pameti, a to az na uroven jednotlivych bitu a adres (nemit je nahazene po pameti jako rozsypany caj).

Jinak samozrejme si muzes totez predstavit i s externi pameti a I/O, pak je to jen o vetsich databazich. Me tohle zajimalo spis pro in-memory databaze ci struktury, protoze tam si myslim, ze lze v soucasnosti ziskat vic (je vice aplikaci, co nesikovne pracuji s mensim mnozstvim dat).

To je dalsi docela zajimava vlastnost, kterou by si obecne programovaci jazyky mohly pujcit z databazi, protoze ty to uz pouzivaji, i kdyz v malinko skryte forme.

Castecne ano, ale porad mi prijde, ze ne dostatecne (a je to casto efemerni). To co si predstavuji je spis skutecne ze se na zaklade toho, co se zjisti statisticky treba i dost radikalne zmeni zpusob ulozeni dat, a to tak, aby se minimalizovala pametova narocnost v tech nejvytizenejsich transakcich. No a samozrejme se zmenou zpusobu ulozeni by se pak i znovu prekompiloval program, ktery k tem datum pristupuje.

S IMS nemam zkusenost, slo by vypichnout nejake zajimave vlasnosti, ktere by stalo znovuvynalezt?

Ani nemam na mysli IMS jako takovou, spis pristup k veci. IMS je v podstate KV store, kde klice jsou ulozeny hierarchicky, takze hledani podle vic klicu jsou jen prochazenim "stromu". Je to velice primitivni databaze, kde se musi premyslet, jake dotazy budes potrebovat, a na zaklade toho se navrhne struktura databaze primo vhodna pro ty dotazy (a treba se pouziji sekundarni indexy, denormalizace atd.). Napriklad se take resi, jestli potrebujes data prochazet sekvencne a na jake urovni, pak si treba muzes odpustit nejaky ten pointer a tak (driv se hodne setrilo pameti, a mam za to, ze to je jeden z duvodu, proc je to stale dost konkurenceschopne - viz vys). No a jakmile se to navrhne, tak se zkompiluje primo program, ktery provadi ten urcity dotaz nebo transakci. Shrnuto, je to slozite a strasne malo flexibilni, ale pokud si da clovek tu praci a navrhne to dobre, tak to bezi dabelsky rychle.

(Mimochodem pred par dny jsem koukal na prednasku o DynamoDB - s kterou jsem jako odpurce NoSQL dost nesouhlasil - a v podstate vynalezli IMS, akorat distribuovane.. Sranda je, ze uvadeji uplne totez co tady pisu o IMS jako vyhody. Stale to ovsem stoji na rucni optimalizaci.)

Co ja bych si predstavoval neni ozivovat IMS (ostatne, porad jsou firmy, co to pouzivaji), ale provadet ten optimalizacni krok automaticky. Abychom nemuseli volit mezi flexibilitou relacni databaze s SQL a rychlosti (vytunene) IMS.

Mohl bys nastinit konkretni situace, kde by to mohlo mit prinos? Intuitivne bych rekl, ze to bude mit nezadbatelnou rezii, ktera nevyvazi prinos.

Myslim, ze to prinos vyvazi jen tehdy, pokud se podari najit nejakou statisticky vyznacnou strukturu v tech pristupech k datum, ktera umozni ta data ulozit tak, aby se usetrilo maximum pameti a tim se zvysil vykon v tech nejcastejsich pripadech, na ukor ztraty vykonu v situacich, ktere nastavaji mene casto. Napriklad, muzeme zjistit, ze k nejakym sloupcum pristupujeme jen zridka, a pak ma smysl je mit ulozene v jine tabulce, a z te puvodni tabulky jen odkaz. Tim se snizi velikost zaznamu puvodni tabulky, snizi se spotreba pameti a zvysi se vykon. Jinak si muzes predstavit i dalsi optimalizace, ktere "umoznuje" treba prave KV store a hierarchicke ukladani, atd.

A k te rezii, to je samozrejme problem. Ja jsem si to (dost vizionarsky) predstavoval tak, ze se vyhradi urcita cast vykonu (treba 1%) a to se proste spotrebuje na monitoring (treba jen samplovanim). Pritom samotny zpusob, jak se to spotrebuje, muze byt adaptivni, a to dvema zpusoby. Jednak, u dotazu a udalosti, ktere probihaji statisticky mene casto, muzeme monitorovat mnohem vic (neztratime monitoringem takovou rezii). Druhy zpusob adaptace je pak ze samotny cil monitorovani muze byt zameren na ziskani urcitych konkretnich informaci, treba blizsi informace o statistickem rozlozeni urciteho konkretniho dotazu. Takovy "adaptivni monitoring" je velmi zajimave tema, i mimo tu oblast databazi, souvisi to i se strojovym ucenim a teorii informace, a vlastne tato aplikace pravdepodobnosti je duvod, proc me ted tak zajima P vs NP.

Shrnuto, jak by to probihalo v praxi. Urcime si limit, kolik vykonu chceme spotrebovat na monitoring (ve vyvoji vic, v produkci mene). Monitoring bude probihat a na jeho zaklade se zformuje nejaka predstava mozne optimalizace zpusobu ulozeni. Data se cas od casu prekonvertuji do te nove struktury, program se prekompiluje aby s tou strukturou mohl pracovat a monitorovat ji, a cyklus se bude opakovat. Tim bude mozne i reagovat na zmeny treba pouzivani dat v dusledku nejake zmeny (nebo nove funkcionality) programu - proste cas od casu se zpusob ulozeni automaticky prizpusobi prislusne zmene; to hodne zjednodusi velkou cast dnesniho programovani.

To mi ponekud pripomina FCA. ;-] Nekteri lidi to pouzivaji i v oblasti SW inzenyrstvi, zpusobem, jak navrhujes ...

Vidis, neco takoveho by se mozna dalo pouzit. Ale obecne to jsou asi dost obtizne optimalizacni ulohy. Napriklad volit vhodne podtabulky te jedne tabulky ma blizko tomu zjistit, jak usporadat radky a sloupce matice tak, aby se minimalizovala sirka pasu - chceme se zbavit zbytecnych nul - a to je tusim NP-uplny problem.

Osobne si myslim, ze primarni je volba datove struktury (reprezentace dat) a volba algoritmu (zpusob samotneho zpracovani) je az sekundardni a plyne z te reprezentace.

S tim naprosto souhlasim, a sel bych jeste dal zpatky k tomu, co jsem psal na zacatku. Pokud data ulozis efektivne do pameti, bude i algoritmus efektivnejsi.

Jeste si projdu vlakno, ale uz moc nemam, co bych k tomu dodal - prece jenom jsem nad tim zase tolik nepremyslel a v podstate ted se ani do nejakeho velkeho premysleni nad tim dal poustet nechci.

[deda.jabko]

Predne jsem chtel podotknout, ze mam proste silny intuitivni pocit, vzhledem k tomu, jak funguji moderni procesory (jsou omezene datovym tokem mezi jadrem a pameti), ze bychom hodne vykonu ziskali proste jen extremne efektivnim ukladanim dat do pameti.

Ta intuice v tomto smeru casto mate. Slozitejsi struktury casto znamenaji slozitejsi kod. Uz mockrat jsem se dostal do situace, kdy jsem sice mel chytrejsi/uspornejsi strukturu, ale usetreny cas byl spotrebovan na pomalejsi zpracovanim podminek, ktere se tam nevyhnutelne vyskytly.

(tohle me ohromilo)

Jo, to je dobre.

Ani nemam na mysli IMS jako takovou, spis pristup k veci. .... No a jakmile se to navrhne, tak se zkompiluje primo program, ktery provadi ten urcity dotaz nebo transakci. Shrnuto, je to slozite a strasne malo flexibilni, ale pokud si da clovek tu praci a navrhne to dobre, tak to bezi dabelsky rychle.

Tento pristup se mi moc nelibi. Chapu smysl a uzitecnost pro opravdu velka data, ale cele to posouva komplexitu od pocitace k programatorovi, pricemz si myslim, ze by to melo byt naopak.

Napriklad volit vhodne podtabulky te jedne tabulky ma blizko tomu zjistit, jak usporadat radky a sloupce matice tak, aby se minimalizovala sirka pasu - chceme se zbavit zbytecnych nul - a to je tusim NP-uplny problem.

To se da resit vhodnymi aproximacnimi algoritmy.

[JS1]

Ta intuice v tomto smeru casto mate. Slozitejsi struktury casto znamenaji slozitejsi kod. Uz mockrat jsem se dostal do situace, kdy jsem sice mel chytrejsi/uspornejsi strukturu, ale usetreny cas byl spotrebovan na pomalejsi zpracovanim podminek, ktere se tam nevyhnutelne vyskytly.

To mas asi pravdu. I kompilator ma heuristiky ktere treba zabranuji prilis velkemu inlinovani, protoze to muze v extremnich pripadech situaci uskodit.

Tento pristup se mi moc nelibi. Chapu smysl a uzitecnost pro opravdu velka data, ale cele to posouva komplexitu od pocitace k programatorovi, pricemz si myslim, ze by to melo byt naopak.

Ja s tebou souhlasim. Navrhovat databazi optimalne rucne bylo prave pouzitelne v 60. letech, kdy to vzniklo. Dneska jsme od toho ustoupili ale IMHO spis smerem, ze neoptimalizujeme vubec. To co chci je, aby to, co delal driv clovek, mohl delat pocitac.

To se da resit vhodnymi aproximacnimi algoritmy.

Asi jo, ale vzdycky mi prislo, ze aproximacni algoritmy jsou takove "hit or miss". Je snadne pridat si do problemu dodatecnou podminku, ktera zpusobi, ze najednou ten aproximacni algoritmus prestane fungovat.

Kez by aspon existoval nejaky systematicky postup, jak se vyhnout tem nejhorsim problemum.. ale mam za to, ze zatim v tomhle smeru dostatecne nerozumime problemu P vs NP.

[kralyk z abclinuxu]

(tohle me ohromilo)

Já teda nic moc extra ohromujícího nevidim... Přijde mi, že s tim JSONem tam porovnává jabka s hruškama. Operace zparsování JSON dokumentu není dost dobře porovnatelná s operací vytovření indexu (+ jednoduchá query), navíc když už předpokládáš syntaktickou správnost. Stejnětak není až tak překvapivé, že nějaká stlačená forma bude efektivnější. Koneckonců, něco velmi podobného už v praxi dělá např. Postgres v jsonb, ne?

Kdyby ukázali, že jsou třeba nějak znatelně rychlejší než ten jsonb, tak to by mohlo být zajímavé.

[JS1]

Asi by bylo dobre si to poslechnout znovu nebo cele - co mysli tim indexem je struktura, ktera umoznuje snadno navigovat ten JSON, jako kdyby byl rozparsovany.

Takze je to neco trochu jineho nez index v Postgresu nad jsonb.

Cele ta idea succinct struktur je postavena na tom, ze usetrime pamet (vymenou za slozitejsi algoritmus). Rychlejsi je to asymptoticky, protoze jak rikam - mene cteni z pameti znamena vyssi rychlost.

nicméně úplně nejsem přesvědčen, že ta cesta CPU↔paměť je skutečně tak zásadní bottleneck

Je to bottleneck. Treba IBM se v procesorech pro zSeries (v podstate jsou zalozene na POWER) snazi o to, aby kazdy prvek L1 cache byl dostupny v jednom taktu (v ramci vykonani jedne instrukce). To znamena fundamentalni kompromis mezi frekvenci procesoru a velikosti L1 cache. Pri prilis vysoke frekvenci uz totiz neni mozne (diky omezeni rychlosti svetla) obsahnout celou L1 cache v jednom taktu.

A tohle pak podobne plati na kazde urovni cache hierarche. Takze, cim mene veci behem zpracovani ulozime do prislusne cache, tim lepe.

Proto jsou succinct struktury zajimave - davaji teoretickou mez, kolik pameti musi struktura zabirat pro urcity zpusob, jakym s ni pracujeme. Jsou proste na hranici toho kompromisu mezi prostorem a casem.

succinct data structures jsou jen pocatek velmi zasadni revoluce v computer science

Jenom trochu dovysvetlim, co jsem tim chtel rict - bylo to ponekud krypticke. Hlavni idea (jak to chapu) tech succinct struktur spociva v tom, ze pointer je v podstate nahodna hodnota ulozena v pameti, tudiz kdyz zacneme premyslet nad tim, co to pointer je, k cemu ho potrebujeme, a jak jej reprezentovat pro dany algoritmus, znamena to, ze dost mozna usetrime pamet.

Ale ja mam za to, ze stejny pristup pujde aplikovat i na jine veci. Spousta algoritmu obsahuje nejruznejsi matematicke struktury (jako napriklad pointery), ktere vlastne existuji specifikovane jakoby mimo ten samotny algoritmus, a jejich konkretni implementaci voli ten, kdo ten algoritmus implementuje (fakticky prevadi na stavovy automat, protoze kazdy program v realnem pocitaci je nakonec jen stavovy automat), v podstate nezavisle na tom, co ten algoritmus dela.

Napriklad velke otevrene pole vidim v pravdepodobnosti. Je spousta algoritmu, co pracuje s pravdepodobnosti, ale malo z nich uvazuje nad tim, jak je ta pravdepodobnost pak v praxi ulozena (klasicky se ukladaji jako floaty treba). Muze nas treba napadnout, ze pokud uz je algoritmus pravdepodobnostni, pak pravdepodobnost tech mene pravdepodobnych hodnot lze ukladat treba s nizsi presnosti.. protoze u nich velka chyba ma jen pomerne maly vliv na celkovou chybu. Tim se usetri spousta bitu, protoze tech hodnot s malou pravdepodobnosti muze byt opravdu hodne. Pak se taky da najit souvislost s marginalnim problemem, atd.

[kralyk z abclinuxu]

Rychlejsi je to asymptoticky, protoze jak rikam - mene cteni z pameti znamena vyssi rychlost.

Počkat. Jestli porovnáváš čtení JSONu bez indexu versus čtení indexovaného JSONu, pak je opět triviálně vidět, že ta to druhé bude asymptoticky rychlejší - to je koneckonců celá definice indexu a důvod, proč se indexy používají (begging the question) - a nevidim souvislost se succint strukturami, leda by succint struktury byly jediná možnost, jak indexovat JSON. Z tohoto důvodu IMO z toho jejich benchmarku neplyne nic moc relevantního pro succint struktury, protože zřejmě (jak jsem to pochopil) porovnávají naivní čtení úplně bez indexu vs succint index. Relevantní by ale bylo porovnat succint index versus non-succint index / non-succint reprezentace (což je AFAIK např. ten jsonb). Pak by z toho třeba plynul nějaký závěr pro succint struktury.

Tak jak tomu zatím (ne)rozumím, použití succint struktur - ie. stlačení velikosti datových struktur při nezhoršení komplexity operací - IMHO může přinést právě pouze ne-asymptotické zrychlení. Tam docílíš toho, že ta křivka nepoleze nahoru tak rychle (díky vyšší propustnosti), nicméně bude mít stále stejný tvar, ne snad? Tj. to, jestli CPU vytáhne z L1 cache hodnotu ryclostí x nebo 2x, nepředstavuje rozdíl v asymptotické složitosti, i když samozřejmě v praxi to může být rozdíl významný.

[JS1]

Tak JSON je jen priklad aplikace succinct struktur, samozrejme.

Mas pravdu, slovo asymptoticky nebylo vhodne pouzite. Bude to zrychleni o konstantu (oproti srovnatelnemu ulozeni, ktere neni succinct).

Tou asymptoticnosti jsem myslel spis to, ze jelikoz je ten algoritmus slozitejsi, tak na male JSONy se to nevyplati vubec pouzit.

Ale mohl by jsi samozrejme nejspis najit i succinct analog toho indexu nad jsonb, a ten by pak mel mensi spotrebu pameti nez ten tradicni index.

Nicmene ja to ted z hlavy nevim - chci si to jeste nekdy v budoucnu vic nastudovat, ale momentalne mam jine zajmy. Pokud te to zajima, Erik Demaine ma velmi podrobnou prednasku o succinct strukturach na MIT.

[kralyk z abclinuxu]

Tou asymptoticnosti jsem myslel spis to, ze jelikoz je ten algoritmus slozitejsi, tak na male JSONy se to nevyplati vubec pouzit.

Aha, ok.

Jen dodám, že jsem z té přednášky viděl něco jako dvě třetiny (než jsem musel jít dělat něco jinýho) a jen ten příklad s tím JSONem mi přišel mimo, jinak celkově to bylo celkem zajímavé a aplikace se asi najdou...

[Bedňa]

Malá poznámka k Přemekovej kritike, ten ti napísal vlastne to čo aj ja.

Taky si můžeme všimnout, že FS jsou dostatečně silná abstrakce, nad kterou lze takovou věc postavit.

Unixové FS sa proste o vrstvách. Takže tú atomicitu stačí postaviť nad nejakým FS, tak ako to robia databázy. Pretože napr. linuxové FS robia prácu dobre a dostať atomicitu priamo do nich, by najskôr spôsobilo výkonostné problémy.

[deda.jabko]

Imho budeš dobrý, když za ten víkend napíšeš parser. Překvapivě to není tak triviální, když chceš něco co není úplně stejné jako všechno ostatní.

V tom pripade budu asi dobry. ;-] Ale asi hlavne proto, ze pouzivam ANTLR. Pravidla pro lexikalni analyzu muzes recyklovat (pouzivat s mensimi upravami) napric jazyky. Pravidla pro syntaktickou analyzu (resp. generovani AST) jsou u jednoduchych (elegantnich) jazyku taky docela snadna a rychle vytvorena. Kdyz si zkousim nejaky napad, tak s parserem obvykle zabiju tak hodku az dve.

Překvapivě to není tak triviální, když chceš něco co není úplně stejné jako všechno ostatní.

Byt jiny muze byt na skodu, protoze to komplikuje budouci adopci. Na druhou stranu, kdyz chces neco jineho nez vsichni ostatni, treba Lisp nebo Forth, je psani parseru desive rychle. ;-]

[Bystroushaak]

V tom pripade budu asi dobry. ;-] Ale asi hlavne proto, ze pouzivam ANTLR. Pravidla pro lexikalni analyzu muzes recyklovat (pouzivat s mensimi upravami) napric jazyky. Pravidla pro syntaktickou analyzu (resp. generovani AST) jsou u jednoduchych (elegantnich) jazyku taky docela snadna a rychle vytvorena. Kdyz si zkousim nejaky napad, tak s parserem obvykle zabiju tak hodku az dve.

Jo, lexer jsem měl během chvíle, ale parser mi v rply dal docela zabrat. Ale možná to bylo prostě tím, že jsem to dělal poprvé a taky se tam začaly projevovat podivnosti rpythonu a tohle bylo poprvé, kdy jsem se s nima potkal. Už o tom mám napsané články ze série „Jak se píše programovací jazyk“, tam to pak bude ještě rozebráno.

Na druhou stranu, kdyz chces neco jineho nez vsichni ostatni, treba Lisp nebo Forth, je psani parseru desive rychle. ;-]

Na lisp jsem měl parser taky za chvíli :]

[Bherzet]

Říkám si dlouho to samé, ale současně mám pochybnosti, jestli vlastně je možné vymyslet něco signifikantně lepšího. Naposledy jsem se díval na Elvish a po prvotním nadšení mě to velmi zklamalo.

On totiž možná není problém jen s tou implementací, ale s celým tím konceptem. Od shellu očekáváme, že bude v první řadě velmi expresivní (úsporný co do počtu zadávaných znaků). Z toho pak ale vcelku nezbytně nutně vyplývá, že nemůže být jednoduchý a nejspíš ani konzistentní. Buď všechno vyjadřuješ explicitně, a pak to není úsporné, a nebo toho hodně stanovuješ implicitně, a pak to není jednoduché.

Přemýšlel jsem nad tím, jestli vlastně potřebuji, aby shell byl plnohodnotný programovací jazyk. Skripty mohu psát v čemkoliv jiném, je to jen otázka vhodného frameworku/bindingů, který usnadní volání externích příkazů (vč. shellových konstrukcí). Jde tedy o to volání (zřetězených) příkazů, a tam by mohlo stačit něco podstatně skromnějšího.

Ten shell může být pro jednoduchost rovnou napsán v nějakém rozumném skriptovacím jazyce a může umět pracovat i s jeho nativními objekty. Např. to tedy může být napsané v Pythonu s tím, že při spuštění shellu se sourcne nějaká obdoba .bashrc, což by byl obyčejný skript v Pythonu. Veškeré v něm definované funkce by bylo možné ze shellu volat stejně jako ostatní programy. Z Pythonu by současně bylo možné vyhodnocovat shellovské stringy, a nebo (a lépe) rovnou volat ekvivalentní funkce, což kód nejen zpřehlední, ale i zrychlí (odpadne parsování). Třešničkou na dortu by pak ještě byla možnost vyhodnocovat přímo v shellu konstrukce v mateřském jazyce.

Čili zjednodušeně: Na takové to běžné volání různých utilit bych použil shell se speciální expresivní syntaxí, na cokoliv složitějšího (co se stejně typicky blbě zadává jako jeden one-liner) by se použil konvenční programovací jazyk. Na co vytvářet nějaký nový, že?

[Bystroushaak]

Co se pythonu týče, tak už celé roky používám pythonpy a sh. Bolest je s nimi trochu menší, ale nezmizí.

[Bystroushaak]

Vezmeme si treba klasicke "ls" jako priklad. V tom novem systemu mi "ls" proste vrati seznam objektu, dobra. Jenze kdyz ho pak budu chtit zobrazit uzivateli nejak rozumne (jako to dela klasicke ls), budu potrebovat novy prikaz, nejake ls-fmt, ktere z toho seznamu objektu, co vrati (specificky) ls, vyrobi citelny smysluplny text, ktery obsahuje informace, ktere hledam (napriklad casto lide pouzivali trideni podle data zmeny).

Nečetl jsem celou diskuzi, tak nevím, jestli už to nikdo nezmiňoval, ale tohle je prostě otázka implementace metod __repr__() či __str__() jak u těch objektů, tak u samotného objektu pole.

Například pošleš objektu složku zprávu ls a zpátky dostaneš pole, které má upravený repr tak, aby vypisovalo objekty co obsahuje na nových řádcích. A každý ten objekt je parametrizovaný tak, aby se vypsal na jednu řádku klidně ve formátu, v jakém je vypisuje ls.

To je jeden přístup. Druhý releativně zajímavý přístup, který mě napadl nedávno je prostě vypsat text a do něj vložit neviditelné řídící znaky tak, aby referencovaly konkrétní objekt, který si potom cílový program může zpět resolvnout, ale uživatel to může s klidem ignorovat.

[kralyk z abclinuxu]

Zajímavej nápad, nicméně to by mohlo zanechávat bordel v textu při copy-paste.

[JS1]

jestli už to nikdo nezmiňoval, ale tohle je prostě otázka implementace metod

Uz o tom vys psal xsubway.. A IMHO neni to jen otazka implementace tech metod, jak sam uznavas, nejak se ty metody musi zvenci konfigurovat.

Samozrejme, udelat muzes cokoli vselijak. Z meho pohledu tu nakonec vice lidi doslo k zaverum:

1. Jsou potreba dve vrstvy, jedna jako prime API k OS a druha jako lidsky pouzitelne API. V Unixu jsou to volani jadra a shell, v Gitu se tomu rika poeticky "plumbing" a "porcelain". Snazit se je spojit do jedne je pravdepodobne pomylene.

2. OOP se na to moc nehodi, lepsi je resit to skladanim funkci.

Podle me si potrebujes vyjasnit, co vlastne chces. Snenim o eleganci se moc daleko nedostanes, to vim z vlastni zkusenosti. A predevsim, jake pozitivni vlastnosti vysledneho systemu jsi ochoten obetovat. Inzenyrstvi jsou hlavne kompromsy.

Jinak doufam, ze te Thinking Forth (a Forth vubec) privede k funkcionalnimu programovani. Ono Forth je v podstate takovy predchudce, ale kdyz v tom zkusis programovat, zjistis, ze prestoze je to uzasne elegantni, staticke typovani by se fakt hodilo.

[Bystroushaak]

1. Jsou potreba dve vrstvy, jedna jako prime API k OS a druha jako lidsky pouzitelne API. V Unixu jsou to volani jadra a shell, v Gitu se tomu rika poeticky "plumbing" a "porcelain". Snazit se je spojit do jedne je pravdepodobne pomylene.

To je imho pravda jen pokud se podíváš na současný systém, který tak je prostě navržený. Pokud se podíváš třeba na Smalltalk, tak už to pravda není.

2. OOP se na to moc nehodi, lepsi je resit to skladanim funkci.

Já nevidím důvod, proč by to nešlo dělat skládáním funkcí v OOP.

Jinak doufam, ze te Thinking Forth (a Forth vubec) privede k funkcionalnimu programovani. Ono Forth je v podstate takovy predchudce, ale kdyz v tom zkusis programovat, zjistis, ze prestoze je to uzasne elegantni, staticke typovani by se fakt hodilo.

Já už jsem v něm kdysi dělal, když jsem se učil C a chvíli ujížděl na stack-based strojích okolo tekomatů. Ale nic signifikantního.

[JS1]

Nechci se zbytecne opakovat, ale mam pocit, ze oboji jsem tu uz rozebiral.

Pokud se podíváš třeba na Smalltalk, tak už to pravda není.

A co MVC pattern? To je v zasade dost podobne.

Já nevidím důvod, proč by to nešlo dělat skládáním funkcí v OOP.

Viz.

A na moji otazku jsi neodpovedel, coz by asi fakt tuhle diskusi mohlo nekam posunout. Zkus se zamyslet nad tim, ceho se vzdas. Ceho se Smalltalk vzdal?

[Bystroushaak]

A co MVC pattern? To je v zasade dost podobne.

Co konkrétně s ním?

Zkus se zamyslet nad tim, ceho se vzdas. Ceho se Smalltalk vzdal?

Jen pro pořádek, já netvrdím, že Smalltalk je řešením. Tvrdím, že Smalltalk naprostou většinu toho o čem jsem psal vyřešil už před cca 30 lety, stejně jako třeba ta lispová Genera. Netvrdím „pojďme udělat další Smalltalk“, ale „pokud chci dělat objektový systém, je asi dobré se jím inspirovat“.

[JS1]

To je naprosty nesmysl.

[kralyk z abclinuxu]

Je tohle pravý JS1 nebo zas nějakej troll?

[JS1]

To byl pravy troll. Ja jsem od utery vecer v Praze a od te doby pisu pod svym jmenem.

Zakladni informace pro ty, co me chteji napodobit, a neodvest spatnou praci, jako GP: Pokud reaguji, tak proto, ze mam pocit, ze je treba neco dodat. Snazim se vyhnout jen konstatovani, ze je neco chybne nebo nesmyslne, aniz bych podal dalsi vysvetleni, proc si to myslim. A snazim se i vyhnout kategorickymm soudum.

Zastavam nazor, ze pokud nekdo nekoho napodobuje, a je obtizne to poznat, pak to je pravdepodobne tim, ze ten original neni prilis zajimavy. A pokud je original nezajimavy, jaky smysl ma snazit se rozlisovat jej od trolla? A naopak, pokud nekdo napodobuje nekoho tak dobre, ze to neni poznat, a tudiz original i kopie jsou ve skutecnosti prinosne prispevky, je to win-win. (Samozrejme pokud nekomu zalezi na autorstvi jeho "originalnich" myslenek, pak je to jina situace a muze se zaregistrovat.)

[kralyk z abclinuxu]

Heh, to mi připomíná xkcd#810.

[Bedňa]

Si zabil

[Bedňa]

Google má dosť zaujímavé a zábavné video ako sa stretnú dve AI pri rozhovore a nedávno som čítal ako to dopadne ak väčšinu komentárov vytvorí AI (proste aby tam najebali reklamu na niečo). Toto je ale dosť chabý pokus :)

[Amigapower]

Tys to pustil ven, jo?