Potěšení v Nepálu - hory a optimalizující kompilátory

3.1.2020 15:45 | Přečteno: 6067× | procesory a roboti | | poslední úprava: 5.1.2020 20:40

Zápisek o radosti z chůze i sdílení znalostí s lidmi, kteří o ně projevili zájem.

Na podzim roku 2019 mě kamarád a cestovatel Vladimír Weigner informoval, že organizuje procházku kolem osmitisícovky Manaslu a byl by rád, pokud by se ke skupině přidal ještě někdo další. Tak jsme v šesti vyjeli a prošli si pěkný okruh kolem Manaslu přes sedlo Larkha La.

Zde na technickém serveru se (minimálně v této rubrice) o vlastním výletu nebudu rozepisovat, určitě uspořádám promítání a povídání o putování pro své kamarády, ale bude-li větší počet zájemců tak zkusím dohodnout promítání v některé posluchárně na Elektrotechnické Fakultě. Pár obrázků z výletu jako ochutnávka je k dispozici na Rajčeti.

Tři týdny jsem byl dokonale odpojený od všech komunikací (v horách sice GSM signál na mnoha místech byl, ale bez možnosti roamingu a speciální místní SIM jsem si nekupoval) a začalo mi chybět s někým sdílet i své technické znalosti. Zároveň jsem měl chuť se dozvědět o tom, jak se třeba i mladým lidem v zemi žije. Ale i po této stránce jsem si výlet nakonec užil a přivezl si pozitivní náboj a i zajímavé kontakty a nabídky do budoucna.

Pomohla mi v tom na konci výletu zátěží a místní stravou urychlená výměna střevní flory a fauny. Když jsem se musel vzdálit od kamarádů, kteří se věnovali nákupům v Kathmandu, tak jsem s nimi ztratil kontakt. Zároveň nakupování nebylo nikdy moje hobby. Po třech týdnech technické abstinence se mi zastesklo po studentech, tak jsem v internet kafé zjistil, že v Kathmandu je jedna soukromá a jedna veřejná technická univerzita. Rozhodl jsem se se svojí návštěvou podpořit tu veřejnou - Tribhuvan University.

Jak cesta přeplněným autobusem tak i hledání katedry počítačů v rozsáhlém areálu přiděleném univerzitě (rozloha okolo 150 hektarů) měla svoje kouzlo. Jen tak na ochutnávku, špatné nasměrování na IT Oddělení mě dovedlo před budovu opatřenou kódovými zámky a čtečkami otisků prstů a hlídanou vojákem, který nechtěl nic slyšet o tom, že bych rád mluvil s profesorem, jehož jméno jsem si přečetl vygravírované na zlatě se lesknoucí tabuli.

Nakonec jsem ale úspěšně v jedné z mnoha budov objevil dvě asi tak dvacetičlenné skupinky studentů, kteří tentokrát řekli, že jedni jsou magisterští studenti a druzí studují jeden z oborů bakalářského studia zaměřeného na počítačové systémy.

Jeden z magisterských studentů se se mnou se zájmem začal bavit o tom, že sám Manaslu trek také šel. Další, že šetří na to, aby se do hor příští prázdniny vypravil. Protože přestávka končila a měl jsem chuť se ještě o studentech něco dozvědět, tak jsem přijal návrh jejich koordinátora ať si sednu na hodinu a půl do přednáškové místnosti.

Tak jsem se ocitl na přednášce o optimalizujících kompilátorech v nepálštině. Projektor měli sice rozbitý, ale lektorka, která přišla, ho nepotřebovala. V ruce nesla knihu Ken Kennedy:Optimizing Compilers for Modern Architectures. Na tabuli v jedné čtvrtině udělala svislou čáru, vlevo napsala hlavní body přednášky a vpravo vždy jeden bod vytáhla a psala k němu algoritmy (dead code elimination, use chains, atd). Přednáška byla na velmi pěkné úrovni, nebyl problém jí sledovat, algoritmy totiž psala anglicky, studenti jí pozorně sledovali, psali si do sešitů algoritmy anglicky a pak dopisovali nepálsky její vysvětlení. Na konci přednášky ve skupinkách řešili zadaný příklad a ona je obcházela. Slzel jsem dojetím a srovnáním s naší přednáškou. Studenti mi později říkali, všichni mají mobily (lepší než já, otevřený librem 5 ještě nedorazil) i laptopy, ale na stolech byly tak dva počítače a na nich pouze scan knihy. Nikdo nehledal nic po Internetu. Když jsem seděl na našich přednáškách vzadu, abych mohl na kolegy navázat, tak vidím jen facebook, youtube, chaty, maximálně pak práci na úkolu do jiného předmětu. V Nepálu jsem si připadal podobně, jako když jsme chodili na přednášky v devadesátých letech, kdy na Internetu materiály nebyly, v nejlepším případě se někdy podařilo přednášejícího přesvědčit, aby nám půjčil slidy (fyzické průsvitné fólie).

Po skončení výuky měli studenti zájem zjistit, co se zajímavého mohou dozvědět ode mě. Začal jsem seznámením s Google Summer of Code. Myslím, že pro studenty z chudších zemí se jedná ještě o větší příležitost než pro naše a i z pohledu vedoucího pěti úspěšných projektů jsem jim mohl o přihlašování a organizaci něco povědět. Pak měli zájem slyšet něco o RISC procesorech, tak jsem začal bez přípravy přehledem od MISP, SPARC po PowerPC, ARM 32 a 64 bitů a RISC-V.

Když se začali ptát na kompilaci do strojového kódu, tak jsem na tabuli rozepsal kódování MIPS a odkázal je na náš simulátor, který jsme pro naše studenty připravili s Karlem Kočím (mým bývalým diplomantem, nyní v CZ.NIC zodpovědným za aktualizace software routeru Turris)

• https://github.com/cvut/QtMips/
• https://pretalx.linuxdays.cz/media/linuxdays19-qtmips.odp
• https://pretalx.linuxdays.cz/media/linuxdays19-qtmips.pdf
• https://youtu.be/fhcdYtpFsyw

Instalační soubory

• https://github.com/cvut/QtMips/releases

Online verze

• http://cmp.felk.cvut.cz/~pisa/apo/qtmips/qtmips_gui.html

Počítal jsem s tím, že bych ho z něčího počítače předvedl na projektoru. Řekli mi, že je rozbitý, tak zkoušeli nahrát simulátor na jeden z jejich laptopů. Po 20 minutách se jim to podařilo a nadšeně zkoumali, jak procesor vykonává instrukce. Ostatní mi pak řekli, že doma mají internet rychlejší a náš projekt si s chutí vyzkouší, protože jim pomůže v chápání jejich aktuálního předmětu zaměřeného na kompilátory.

Někdo z učitelského sboru pak zařídil, že mi donesli pro zvlhčení hrdla kalíšek čaje. Na konci výkladu reagujícího na dotazy studentů přinesli kalíšky s čajem i jim, tak jsme si připili a jeden ze studentů mě vyvedl z areálu univerzity a přes rýžová pole jsme zamířili zpět do přeplněných ulic jeden a půl milionového Kathmandu. Na zakončovací večeři s kamarády a průvodci jsem došel s velkým zpožděním, ale vůbec toho nelituji. Podle reakcí se zdá, že společně stráveného času nelitují ani vyučující a studenti o sedmdesát poledníků východním směrem https://www.facebook.com/pg/cdcsit/posts/

       

Komentáře

[_]

Pěkné.

[Max]

Moc pěkné počtení, nebránil bych se ani pokračování.
Díky
Zdar Max

[Petr]

+1

[Gréta]

cestu kolem světa!! :D :D

[Aleš Kapica]

Proč ne? Když někdo může kolem světa cestovat aby zjistil jak se kde vaří, tak stejně tak by mohl podniknout s někým cestu jak se kde ve světě učí IT. Myslím, že by to mohlo být zajímavé.

[Bystroushaak]

Moc pěkné počtení, nebránil bych se ani pokračování.

Taky se mi to líbilo a rád bych si početl klidně mnohem víc.

[vatoz]

Díky za krásný příběh.

[OldFrog {Ondra Nemecek}]

hezké... :)

[Bedňa]

Pekné, fakt moc pekné.

[Josef Kufner]

To opravdu jen tak člověk přijde z hor a zaklepe na dveře, že bude přednáška o procesorech?

[snajpa]

Kdyz jsi p. Pisa a mas se studentama odzito tolik, co on, tak je to asi tak nejak samozrejmy

Mne by se libilo tyhle nase nejlepsi pedagogy takhle sdilet s rozvojovejsim svetem na pravidelne bazi. Hledal jsem jen chvilku, ale takovy nejaky program jsem nenasel. Rad bych si koupil i knizku s vypravenim o takovych zazitcich, kdyby byla :)

[odin]

Mne by se libilo tyhle nase nejlepsi pedagogy takhle sdilet s rozvojovejsim svetem na pravidelne bazi.

Nevím, proč bychom z našich daní měli podporovat nějaké země třetího světa. Stačí, že musím přispívat na třicetiletého věčného studenta s. Kolibáče, který je stále ještě naživu a čerpá ze společného. Pokud o ty zahraniční cesty někdo stojí, tak ať se založí fond a lidi do něj můžou dobrovolně přispívat. V případě čistě soukromého školství je to pak věc té které univerzity, tam je mi to jedno, když to nemusím platit já.

[Radovan]

Také jedno vyprávění z rozvojové země: https://neil.fraser.name/news/2013/03/16/

[Pavel Píša]

Díky za odkaz na návštěvu Vietnamu od vývojáře z Google.

Jak jsem jinak příznivcem zápisu, který se edituje a je verzovatelný v textové formě, tak výsledek jeho příspěvku k prvnímu seznámení s algoritmy mě uchvátil

https://blockly.games/

Co se týče popisu, tak jsou vynechané jen detaily, nic zásadního. Prostě jsem měl půl dne času, kamarádka, také cestovatelka a průvodkyně, kterou jsem na výlet přizval, si chtěla užít den sama, naplánovala si masáže a nákupy. Ostatní si naplánovali procházet obchody a pak do programu naplánoval Vláďa projít Garden of Dreams. Tu by se mi vidět líbilo, ale procházet sám obchody a pak tam čekat až přijdou se mi nechtělo.

Co se týče návštěvy univerzity, tak jsem měl jen obavy, že třeba nebude výuka (budou prázdniny, studenti jinde atd.). Jinak mohly nastat jen tři možnosti

1. pedagogové, studenti nebudou mít čas.
2. budou to lidé bez zájmu, a tak o nich nemá smysl uvažovat a i při nějakém příštím výletu do oblasti se této univerzitě vyhnu
3. budou mít zájem komunikovat, něco se dozvědět, něčím prezentovat sebe

Vlastní cesta autobusem a procházka kampusem i tak bude zajímavá a projdu se po okolí a nebo zpátky dojdu pěšky. To poslední jsem sice vzhledem k pozdnímu času po skončení povídání zavrhl, ale z návrhu studenta, který se vracel do města, jsem na začátek nepochopil, že půjde domů na druhou stranu města pěšky. Když jsme došli na první hlavní a nechali autobusy za sebou, tak mi potvrdil, že jde pěšky. Jak jsem šel s ním, tak jsem si trochu zašel a po 17 km došel na večeři později. Ale během cesty jsme byli zabraní do rozhovoru jak a za kolik bydlí, vaří si, chtěl by pracovat v New Yorku, že jeho otec pracuje na ministerstvu, které se zabývá zemědělstvím atd. Jak on sám si během magisterského studia přivydělává výukou na střední škole atd.

To že návštěva vyšla tak pěkně byla sice trochu náhoda, ale dopředu jsem měl velkou víru, že je velmi pravděpodobné, že si to užijeme. I kdyby k nám na FEL někdo z ciziny náhodou jen tak dorazil, tak přednášky na veřejné univerzitě jsou (minimálně podle zvykového práva, když ne ze zákona) veřejná vystoupení, přijít může kdokoliv, třeba i z ulice, když není překročena kapacita a nehrozí ohrožení zdraví. Proč by pak neměli mít studenti zájem se něco dozvědět o někom, kdo se jejich oborem zajímá jinde, nebo když by neměli zájem o svůj obor, tak alespoň jak se jinde žije. Nepál má výhodu, že všichni trošku vzdělaní lidé umí anglicky a i sběračky dříví v horách vám na dotaz na cestu na sedlo mimo trasu ukážou rukou a řeknou "bridge". S průvodci jsme se také dokázali bavit o jejich rodinách, dětech, jak je jejich prioritou zajistit jim vzdělání a kolik jim na školném v soukromé střední škole platí.

Trochu netaktní to bylo bez varování vzhledem k vyučujícím. Také jakmile mi řekli, že končí přestávka a trochu zvažovali, jestli nenechají mojí debatu se studenty pokračovat i tak, tak jsem jim řekl, že v žádném případě nebudu výuku narušovat, a když mě pozvali na přednášku, tak jsem byl 1.5 hodiny zcela zticha. I když bych asi i k tomuto tématu měl sem tam nějakou poznámku nebo se zúčastnil řešení příkladu. Jen jsem se díval studentovi vedle mě přes rameno, co si píše do sešitu a pak jak se snaží do kategorií blok input, output, atd. přiřadit jednotlivé proměnné.

Po skončení mi dala lektorka prostor. Představení jsme sice nezvládli podle nějakého protokolu. Ona neznala, koho představuje atd... Tak jsem se představil sám atd.

Pokud bych nenašel studenty, hledal bych vyučující předmětů podobným našim, abych se něco přiučil, nebo jim nabídl naše materiály, nápady, používaný SW. Nebo adminy a popovídal si s nimi o školní síťové infrastruktuře a laboratořích. Zde máme hodně, co nabídnout. Znalosti sice nevyučujeme v žádném předmětu, ale díky úsilí Aleše Kapici je infrastruktura, která pohání možná 150, 200 počítačů, kvalitně zdokumentovaná dce.felk.cvut.cz Diskless.

Pokud lidé mají zájem komunikovat, tak se dohodnou. Jak na Installfestu, LinuxDays založených studenty ČVUT, tak třeba na Google Summer of Code 2016 Mentor Summit. U chocholate table jsem si dohodl schůzku s Eduardem ze Španělska. Ozval se mi na zaslanou zprávu do mailing-listu setkání (ono mezi 240 lidmi jen tak najít neznámou tvář podle jména je potíž), že byh po akci pořádné Google někam na chvíli také zašel. Byl jsem tam za RTEMS, ale Joel Sherril neměl čas a Chris Johns se vracel do Austrálie. Bavil jsem se s lidmi z QEMU a mnoha dalšími, ale v Google najatém autobuse jsem si všiml dvojice, u které jsem podle vzhledu/intuice odhadl, že by mohly mít podobné horské spády jako já. Tak jsem se jich zeptal, a odpověď byla, já jsem Kat, tohle je Dave King a po summitu se půjdeme podívat do King's Valley a jestli chci, tak ať se přidám. Můj Španěl s tak velkým výletem nepočítal, ale zajeli jsme pro něj dokoupit spací pytel a batoh a prošli asi 90 km. Bylo tam trochu zábavy s půjčením auta, dohledáním druhé dvojice ve dvě ráno v kempu o několik set kilometrů jinde atd. Pak jsem musel Eduarda vrátit do San Franciska, trochu se plácal sám a pak zamířil do Yosemit (dalších 120 km tentokrát často sám na desítkách km čtverečních). Ale to je opět na delší povídání.

Podobné to bylo, když jsem vzal našeho vrchního síťaře FEL Martina Samka a bývalého diplomanta a kolegu Michala Sojku před RTLWS 14 za Joelem Sherillem do Hutnstwillu do OAR corporation. Do RTEMSu jsem přispíval od studií a pak v rámci firemních projektů (elektronika a firmware Infúzních pump) tak jsme s Joelem pět dnů před návštěvou dohodli přednášku RTEMS Executive and XML Based GUI in Medical Instrument Firmware na University of Alabama in Huntsville přišlo také asi 30 studentů a zaměstnanců a rozproudila se živá diskuze, provedli nás laboratořemi, ukázali velmi zajímavé své a studentské projekty, například taktilní rukavice jako klávesnice k mobilnímu telefonu atd.

Tam, kde je o sdílení radosti, výsledků, zkušeností a znalostí zájem tam je dobře. Tam, kde jsem se víc jak půl roku musel zdržet komunikace s lidmi, které jsem vychoval, aby nepřišla hysterická reakce, tam je zle. Takže vyhledávám lidi a místa, kde je mi dobře.

Na druhou stranu stále věřím, že pro pokračování oboru alespoň významná část našich studentů, má o znalosti zájem a že jim mám stále co nabídnout a tak bych rád podporoval naší zemi a naše studenty, než odjel třeba do Kathmandu. I když nabídka, že mě vezmou jako místní do hor, je lákavá. Mnoho treků vyžaduje ze zákona místního průvodce.

[Gréta]

Jak jsem jinak příznivcem zápisu, který se edituje a je verzovatelný v textové formě, tak výsledek jeho příspěvku k prvnímu seznámení s algoritmy mě uchvátil https://blockly.games/

si myslim že tomorrow corporation uďála dvě supr programovací hry ;D jsou teda placený upozorňuju

human resource machine hele a videjko hraní

7 billion humans hele a taky videjko

jo a taky redstone v minecraftu je uplně supr hele ;D

[ehmmm]

Dekuji za clanek.

[johnyK]

take dekuji za zajimavy clanek. Rad bych se pri te prilezitosti zeptal Vas predevsim ale i ostatnich kolegu, co si myslite/i o praktickem vyuziti compileru v praxi.

Pamatuji si, ze pred 30-40 lety byl nekdo, kdo umel napsat prekladac takovy exot. Nic divneho, teprve zacatkem 80. let vysly ty prvni knihy o prekladacich (Ahos's Dragon book) a i v nemcine se objevily prvni publikace o stavbe prekladacu za pomoci lexu a yaccu. Tehdy jem ocekaval, ze za 10 mozna za 20 let vyjdou ze skoly studenti, kteri pak v praxi napisi ve firme podle potreby za 1 den nejaky prekladac nebo interpreter, ktery bude samozrejme orientovan na nejakou specifickou - firemni - problematiku.

35 let uteklo jak voda a ja si myslim, ze se moje predstava nenaplnila. Samozrejme, ze nevidim do vsech firem, zejmena v tech mensich nikoho takoveho nepotkavam. Ale i u tech velkych (Daimler, Bosch, Porsche), kde mam nejake zname neni nikdo, kdo by ty nabyte znalosti v teto oblasti mohl uplatnit.

Vy pripravujete u vas na skole takove odborniky, kteri tu stavbu prekladacu slyseli a cvicili. Kam odchazeji? Co delaji?

Pozn:

Aby to nekdo nepochopil spatne. Ja si vubec nemyslim, ze by stavba prekladacu bylo nepouzitelne tema, ktere by se melo vyskrtnout z ucebnich planu, kdyz uz se to v praxi neuplatnuje. Prave naopak, ja si myslim, ze je to skoda a dokonce se domnivam, ze se studentum neukazuuje v mnohem vetsi mire ta moznost uplatneni techto hlubokych znalosti v praxi. Obavam se, jestli ta cela vyuka neprobiha pouze v takove te 'vysokoskolske teoreticke rovine'?

[xkucf03]

Tehdy jem ocekaval, ze za 10 mozna za 20 let vyjdou ze skoly studenti, kteri pak v praxi napisi ve firme podle potreby za 1 den nejaky prekladac nebo interpreter, ktery bude samozrejme orientovan na nejakou specifickou - firemni - problematiku.

Ve své praxi (cca 15 let) jsem se setkal jen jednou s tím, že si někdo v rámci firmy definoval vlastní gramatiku a napsal k tomu nástroj.

Mnohem častěji se používá to, že se definuje nějaký vlastní formát třeba nad XML a k němu se napíší nástroje nebo se udělá nějaké šikovné API ve stávajícím jazyce (např. Java), kde se skládají metody (často tzv. fluent interface). To pak slouží jako takové DSL.

U svobodného softwaru je definování vlastních gramatik častější. Ale tam jde o obecný opakovaně používaný software s mnoha uživateli.

Zřejmě v těch firmách mají pocit, že nemá cenu vyvíjet a definovat vlastní gramatiku jen pro vlastní potřeby, zřejmě se očekává, že to bude nákladnější než původní odhady (ten, kdo s návrhem přichází, je většinou hodně optimistický) nebo že příští generace programátorů s tím nebude umět pracovat a navázat na to.

Ve firmách se šíří různé nálady a představy a funguje tam akce a reakce. Špatné zkušenosti z minula vedou k averzi k určitým řešením a postupům, často je to dost ode-zdi-ke-zdi, extrémní a v důsledku iracionální. Ale traduje se to ještě dlouho, až se ani neví proč. A samozřejmě se ty zkušenosti přenáší i mezi firmami. Např. jsem zažil to, že po neúspěšném interním vývojovém projektu firma utlumila jakýkoli rozvoj a šlo to až na úroveň mikro-managementu a blokovalo to běžnou denní práci (protože prostě do ničeho „navíc“ investovat nebudeme a budeme dělat jen to, co výslovně chce a zaplatí zákazník). Tyhle extrémy ničemu neprospívají (na jedné straně se propálí miliony v nesmyslném projektu, který se měl zastavit po prvních dvou měsících, a na druhé straně se blokuje užitečná práce, která by stála třeba jen pár hodin navíc). V (dávnější) minulosti se běžně stávalo, že si programátoři (a obecně lidi od počítačů) hráli s technologiemi, aniž by jejich nadřízení pořádně věděli, na čem se pracuje, a hlavně aniž by to mělo nějaký reálný přínos pro firmu a zákazníky. A reakcí na to je (už déletrvající) trend, kdy se naopak vše pečlivě vykazuje, měří a řídí a je až nesmyslná snaha nedělat nic „navíc“ co nepovede k plnění explicitně definovaných požadavků a k příjmům. Vedle toho samozřejmě existují výjimky, které jdou záměrně proti proudu, nebo jim ty zkušenosti chybí a žijí tak nějak mimo čas a prostor po svém.

Aby to nekdo nepochopil spatne. Ja si vubec nemyslim, ze by stavba prekladacu bylo nepouzitelne tema, ktere by se melo vyskrtnout z ucebnich planu, kdyz uz se to v praxi neuplatnuje.

+1

Podle mého k vyššímu vzdělání prostě patří (a je to tak správně) i to, že se člověk naučí mj. spoustu věcí, které v každodenní praxi používat nebude. Jednak jde o udržování a rozvoj těch znalostí, aby o ně společnost nepřišla. A jednak to pomáhá, i když člověk danou věc jen používá (hodí se vědět, jak to funguje uvnitř). Já si např. rád čtu v knížce The Linux Programming Interface, i když se jinak čistému C snažím vyhýbat a píši převážně ve vyšších jazycích aplikace, které s Jádrem přímo neinteragují.

[Bystroushaak]

Zřejmě v těch firmách mají pocit, že nemá cenu vyvíjet a definovat vlastní gramatiku jen pro vlastní potřeby, zřejmě se očekává, že to bude nákladnější než původní odhady (ten, kdo s návrhem přichází, je většinou hodně optimistický) nebo že příští generace programátorů s tím nebude umět pracovat a navázat na to.

Ono hlavně proč psát gramatiku? To nejen že nutí tebe psát pro ní taky implementaci, ale zároveň k tomu nutíš i všechny ostatní. Kde je ten benefit z cost-benefit analýzy? Přijde mi, že ti tam zbývá jen ten cost (psát vlastní parser, ast a všechno kolem, nutit k tomu i ostatní, dělat dokumentaci, implementaci a debugging klidně desítky let, ideálně funkční na vícero prostředích a programovacích jazycích). Aby tam vůbec mohl být nějaký benefit, tak to imho znamená, že musí platit alespoň jedna z následujících možností:

1. Musíš vyjadřovat nějaké dostatečně abstraktní myšlenky, které nejde vyjádřit nad nějakým jiným "nostným substrátem", jako je JSON, nebo XML.
2. Vyjádření těhle myšlenek je v tomhle o hodně levnější co do námahy pro uživatele.
3. Celé je to o hodně rychlejší na parsování.

A první dvě se vztahují prakticky jen na programovací jazyky, třetí si ani nějak neumím představit, že by dávala v dnešní době smysl, když existují věci jako protobuffs a messagepack, které provádějí serializaci a deserializaci rychleji než zápis (SSD) disku. Když je to navíc něco, co uživatelé nevytvářejí přímo, ale komponuje to nějaký program, tak v podstatě naprosto nedává smysl si vymýšlet vlastní formát.

[xkucf03]

Ono hlavně proč psát gramatiku? To nejen že nutí tebe psát pro ní taky implementaci, ale zároveň k tomu nutíš i všechny ostatní. Kde je ten benefit z cost-benefit analýzy?

Záměrně jsem se v tom komentáři zdržel vlastních hodnocení a neříkal, zda je dobře nebo špatně vytvářet vlastní gramatiky. :-)

Přijde mi, že ti tam zbývá jen ten cost (psát vlastní parser, ast a všechno kolem, nutit k tomu i ostatní, dělat dokumentaci, implementaci a debugging klidně desítky let, ideálně funkční na vícero prostředích a programovacích jazycích).

S tímhle souhlasím. Ono totiž nestačí definovat gramatiku a napsat parser, ale chce to i tu dokumentaci, podporu v editorech (zvýrazňování a kontrola syntaxe, napovídání…), ladění atd.

V tomhle je právě skvělé XML – napíšeš si XSD a máš hotovo – je v něm dokumentace, editory na základě něj umí validovat a napovídat, automaticky si ho namapuješ na objekty, takže máš parser. A ta druhá volba (udělat si nějaké to šikovné API třeba v Javě) vychází velice podobně – dokumentaci napíšeš přímo k těm metodám, validuje ti to IDE a kompilátor, zvýrazňování syntaxe a napovídání tam máš automaticky taky.

Vývoj vlastní gramatiky přináší komplikace – ten proces je složitější, vstupují do toho nové nástroje, nové znalosti, postupy… čím víc nových (běžně nepoužívaných) věcí, tím víc se toho může pokazit. Už to není tak jednoduché, jako když máš všechno jen v Javě.

Ale musí to tak být? Když už definuješ gramatiku v nějakém strojově čitelném formátu, tak by z toho přece šla generovat i podpora v editorech (zvýraznění syntaxe a napovídání). Těch nástrojů by nemuselo být tolik a nemusely by být tak cizorodé ke zbytku programu (tady můžou dost pomoci PEG parsery, které ten proces výrazně zjednoduší). Teoreticky by neměl být problém dostat se (v jednoduchosti vývojového procesu, nákladech, stabilitě/předvídatelnosti) na úroveň XML, které se, alespoň dle mého pozorování, v běžné firemní praxi používá výrazně častěji než klasické gramatiky (v obou případech se bavíme o tom, že si vytváříme vlastní, ne že se používají nějaké hotové vytvořené někým jiným). Asi je to tedy o dostupnosti a kvalitě nástrojů.

[Josef Kufner]

Je to hezká představa, ale ještě jsem neviděl nic praktického, co by se tomu jen blížilo.

Další krutě chybějící věc je podpora vizuálních syntaxí, tedy možnost kreslit si diagramy a ty pak zakompilovat do programu či nějak jinak strojově zpracovávat.

[xkucf03]

Příloha:

• protocol.pdf (24977 bytů)

Je to hezká představa, ale ještě jsem neviděl nic praktického, co by se tomu jen blížilo.

To já taky ne. Proto jsem to asi reálně nikdy nepoužil. Nenapsal jsem si vlastní gramatiku, protože by s tím bylo příliš mnoho práce.

Další krutě chybějící věc je podpora vizuálních syntaxí, tedy možnost kreslit si diagramy a ty pak zakompilovat do programu či nějak jinak strojově zpracovávat.

Tak zrovna třeba BPEL takhle funguje, že si nejdřív „kreslíš“ a pak se to zkompiluje a spouští. Ale to nejsou gramatiky.

Jinak souhlasím, že ten grafický pohled je důležitý, ale tvořit to můžeš klidně textově s tím, že se z toho grafický výstup průběžně generuje – není zase takový rozdíl, jestli někde klikneš myší nebo někam připíšeš řádek. A tohle jde jednoduše už teď bez nějakých pokročilých nástrojů. Zrovna teď něco takového dělám, viz příloha – generuje se to ze dvou CSV souborů.

[Josef Kufner]

Jednou jsem si takový nástroj na kreslení napsal a výrazně to práci zrychlilo. Psaní s náhledem je lepší než nic, ale jedním tahem myši jede nahradit docela hodně psaní.

[Bystroushaak]

Další krutě chybějící věc je podpora vizuálních syntaxí, tedy možnost kreslit si diagramy a ty pak zakompilovat do programu či nějak jinak strojově zpracovávat.

Jo, asi jediný systém který jsem to kdy viděl používat byl TempleOS od Terryho Davise.

[Bystroushaak]

Ale musí to tak být? Když už definuješ gramatiku v nějakém strojově čitelném formátu, tak by z toho přece šla generovat i podpora v editorech (zvýraznění syntaxe a napovídání). Těch nástrojů by nemuselo být tolik a nemusely by být tak cizorodé ke zbytku programu (tady můžou dost pomoci PEG parsery, které ten proces výrazně zjednoduší). Teoreticky by neměl být problém dostat se (v jednoduchosti vývojového procesu, nákladech, stabilitě/předvídatelnosti) na úroveň XML, které se, alespoň dle mého pozorování, v běžné firemní praxi používá výrazně častěji než klasické gramatiky (v obou případech se bavíme o tom, že si vytváříme vlastní, ne že se používají nějaké hotové vytvořené někým jiným). Asi je to tedy o dostupnosti a kvalitě nástrojů.

Jo, tohle stojí za zamyšlení. Sám jsem se nad tím taky párkrát zamýšlel, hlavně když jsem řešil že třeba chybí podpora syntaxe nějakého hipsterského jazyka v různých editorech. Taky mě ještě napadlo generovat takhle X11 bindingy.

[j]

"Podle mého k vyššímu vzdělání prostě patří..."

Ne, nepatri. Proc? Protoze to zacina snad uz v mateskych skolkach ... vyuka hovadin k nicemu. A vysledek? On sice umi vyjmenovany slova (naco ...), ale myslis si, ze 10% urok = zaplatim o 10% vic. Umi pojmenovat mesta a reky na slepy mape (naco ...), ale vubec mu neprijde divny, kdyz mu navigace v 1/2 dalnice rekne "sjedte, dalnice zde konci" a vpohode najede na sotva viditelnou pesinu, protoze ho tam prece navigace poslala.

A takhle to pokracuje pres stredni a vysoky skoly - vyuka hovadin a nesmyslu, na ukor vyuky veci, ktery vetsina dotycnych bude kazdodenne potrebovat.

Pak to vypada tak, ze absolvent VS s prislusnym titulem neumi poslat email. Asi za tech 15 let nebylo tech 10 minut casu.

A nebo trebas ... viz aktualne elektronicky neschopenky. To by blbec co vysel ze 3ti tridy ZS nevymyslel, ten by to udelal za 10 piv a fungovalo by to, to musel delat nekdo s aspon 3ma titulama pred a 5ti za jmenem. Coze? V roce 2020 mam cekat ... 2-3 dny, nez se (mozna) dovim, jestli teda zamestnanec marodi nebo ne? loooool A protoze socialka neumi pocitat do 14ti, tak ji mam po 14ti dnech oznamovat, ze dotycnej jeste porad marodi? Megalol ...

[Heron]

A nebo trebas ... viz aktualne elektronicky neschopenky.

Já zatím ještě nemůžu ani naznačovat.

Na tomhle je pikantní to, jak se to liší resort od resortu. Na MF naprosto brutální přísun dat do EET zvládli dá se říct zatím bez jediného problému (a to i banky měly problém s náporem na platby kartama) a jiná ministerstva mají neustále problém. Někdy ta zakázka záhadně jde hladce, někdy i menší zakázka, záhadně zhavaruje...

[Pavel Píša]

+1

Ač mi EET především pro drobnější připadá jako celkem zásadní klacek pod nohy, tak provedení je podle dotazů perzonálu v hospodách i jinde v pořádku.

Naopak registr motorových vozidel mi připadá jako zásadní ostuda způsobená nasazením nedoků, kteří škálovatelnost databází spojení atd vůbec nezvládají, mluvit třeba o optimalizaci na NUMA, cache, c10k pak vůbec u takových lidí nejde. Prostě Ti, co studovali jen na diplom a nikdy neviděli dál.

Zkuste si vyhledat, co stát za jednotlivé služby platí a porovnat to s počty transakcí a uživatelů takové OpenSteetMap https://wiki.openstreetmap.org/wiki/Stats (téměř 6 milionů uživatelů, 7 miliard bodů, každý s kompletní historií editace, 5 tisíc uživatelů editujících v každém dnu, vyřizování požadavků na zobrazení map 2 terabity dat za sekundu). Systém dala dohromady parta nadšenců. Náklady na provoz a vývoj podle mého počítání menší než 3 milióny korun (asi bez CDN atd., ale mohu být o řád mimo, zkusil jsem to jen tak spočítat a možná je tam něco jinde) https://wiki.osmfoundation.org/wiki/Finances/Treasurer%27s_Report_for_the_December_2019_AGM

Veškerý software a služby plně otevřené.

Takže záleží kdo, a jak, to dělá. naučte se základy (třeba pro optimalizace přístupů ke cache u nás), abyste alespoň dokázali uvažovat o tom, která řešení jsou od základu špatně, a jak třeba zoptimalizovat zpracování obrázku, aby bylo energeticky (počty přístupů do hlavní paměti) i na čas únosné, když ne již zcela optimální (viz naše domácí úloha práce s pamětí).

[Heron]

Ač mi EET především pro drobnější připadá jako celkem zásadní klacek pod nohy,

Politickou stránku věci jsem raději vůbec nehodnotil.

mluvit třeba o optimalizaci na NUMA, cache, c10k pak vůbec u takových lidí nejde. Prostě Ti, co studovali jen na diplom a nikdy neviděli dál.

Při počtu obyvatel Česka je tohle zcela zbytečné. Těch lidí, vozidel, budov a prostě všeho je tady tak málo, že tyhle vysoké optimalizace reálně vůbec nejsou potřeba. Ono to stačí napsat standardně dobře, dodržovat třeba normální formy, mít ten server rozumně dimenzovaný a není to žádný problém. Dělal jsem to posledních 11let a vím, že není potřeba mít HW za desítky milionů, aby se něco takového zvládlo (na úrovni počtů čehokoliv v Česku). Mluvím o nějakých úředních záznamech třeba na úrovni centrálních registrů vozidel, obyvatel a tak, pochopitelně třeba mobilní operátoři před Silvestrovskou půlnocí to vidí dost jinak.

Zkuste si vyhledat, co stát za jednotlivé služby platí

Ano, to je dost katastrofa a já to měl těch 11 let z první ruky. Ale opět, je vhodné se podívat, kdo kolik a komu za co platí. Opravdu se to hodně liší a někdy za rozumné peníze je rozumný produkt a jindy ani miliarda nepomůže (a asi si nebudeme vykládat o tom, že celá miliarda šla na vývoj toho něčeho).

[Pavel Píša]

mluvit třeba o optimalizaci na NUMA, cache, c10k pak vůbec u takových lidí nejde. Prostě Ti, co studovali jen na diplom a nikdy neviděli dál.

Při počtu obyvatel Česka je tohle zcela zbytečné.

No právě, ukazuje to, jak vypadá řešení opravdových výpočetně, na databáze a komunikace náročných problémů za řádově méně peněz. Při stejné kvalitě návrhu by celý takový systém, za který se ze státního platí miliardy mohl běžet na hardware běžného mobilního telefonu z 5 tisíc kč, trochu přeháním, co se týče spolehlivosti, za tu je třeba zaplatit, třeba i placené podpory OS (RHEL, Suse, ...) a konektivity. Ale co se týče aplikace a procesorového výkonu, tak ve většině případů ne.

[Heron]

No právě, ukazuje to, jak vypadá řešení opravdových výpočetně, na databáze a komunikace náročných problémů za řádově méně peněz.

Tomu rozumím a nijak to nerozporuji. Sám se rád podívám na přednášky o optimalizaci na ns, nebo ušetření několik cyklů výletů do paměti. Je to skvělé.

Při stejné kvalitě návrhu by celý takový systém, za který se ze státního platí miliardy

Jenže on se platí úplně zbytečně a ty peníze rozhodně netečou ani do návrhu ani do HW. Naše firma, to asi můžu říct, v roce 2012 udělala jako první tzv elektronické tržiště. Ten projekt už je dávno po své koncesní fázi, takže asi neprozradím žádné tajemství.

Mělo to share 60% u všech zadatavelů v ČR, byl to systém s největším počtem zakázek (soutěžených na tržišti). Byla to prachobyčejná LAMPA, linux, apache, php, postgresql. Běželo to na HW za cca 1MKč a jako jeho tehdejší admin vím, jak se ten systém nudil a ve skutečnosti by stačil tak šestinový výkon. Na půlku ČR.

Existují jiné systémy od jiných dodavatelů (NEN), ta cena je dneska vejš než 600mil Kč.

Registr vozidel za 66M netřeba komentovat.

Problematika vývoje těchto systémů vůbec není v brutálních optimalizacích, tyhle systémy jsou prachobyčejné číselníkové databáze a k tomu formuláře. A na to stačí dodržení pár základních vývojových pravidel. Pokud to teda chce někdo dělat poctivě. Zkrátka i na HW za 400tis lze provozovat appku pro celou ČR.

Problém je, že "všude musí být Oracle" (před nedávnem proběhla zpráva, že Oracle po ČR požaduje cca 400M za licence a to mělo být ještě po slevě). Jako na co státní správa potřebuje DB za 400M? 99% z nich lze strčit do PG a pokud se tam najdou nějaké brutálně kritické, tak tam může být něco lepšího. (Otázkou je, které jsou vlastně ty kritické, když ani sociální správa, registr vozidel, erecepty a eneschopenky to evidentně nejsou.)

[sigma]

Jako na co státní správa potřebuje DB za 400M? 99% z nich lze strčit do PG a pokud se tam najdou nějaké brutálně kritické, tak tam může být něco lepšího.

Já jsem tedy velký příznivce PostgreSQL, ale nedávno jsem u zákazníka musel dělat celkem jednoduché napojení na Oracle. Už instalace testovacího serveru s free verzí Oracle Express byl zážitek, i když jsem nakonec skončil u VM s Oracle Linuxem, protože dostat to kamkoliv jinam je ještě větší hell. Nevěřil jsem, kolik věcí může být u DB úplně jinak vč. úplně posunuté terminologie - srovnáním s Postgres, MySQL ale i MSSQL.

Na druhou stranu je tam spousta funkcí a vlastností, za které může mít smysl si připlácet - skutečně funkční clustering (RAC), nebo takový Flashback (možnost přepnout se na libovolný starší čas a pracovat s DB tak jak byla v tomto čase - u Postgresu sice umím ukládat logy, ale pro návrat do určitého času není jiná možnost než druhá instance vedle, což je u větší DB docela problém). Dále např. nevím, jak je na tom aktuálně PostgreSQL s audit logy, což je v enterprise segmentu dost důležitá věc, a ne vždy je průchozí to řešit až na aplikační úrovni.

Oracle navíc není jen DB, ale celá aplikační platforma, na které se historicky dělala spousta GUI aplikací nad DB. Další věc jsou třeba integrované nástroje pro DWH data pumps. Tam, kde je tohle zakořeněné se těžko přechází. Otázka je, kolik je takových případů v segmentu, o kterém se bavíme.

Jinak viz blogy Maxe zde na abclinuxu. I v korporaci, kde se teoreticky kouká na peníze a efektivitu se Oraclu platí miliony ročně. Nějakou hodnotu to má, ta firma nezaměstnává 50000 lidí jen tak. Ve státním je nějaká licence na Oracle u 10x nafouklého rozpočtu celkem nepodstatná, naopak se může hodit, protože se dá nakoupit se slevou a prodat přinejhorším za list price.

[Heron]

Dále např. nevím, jak je na tom aktuálně PostgreSQL s audit logy

Audit logy jsme si psali sami a PG k tomu poskytuje dostatek triggerů.

Jinak viz blogy Maxe zde na abclinuxu.

No však já jsem je komentoval.

u 10x nafouklého rozpočtu

A to má být v pohodě?

Jinak já rozumím, co chceš říct. Ale z mojí dosavadní praxe plyne, že peníze vynaložené za jakékoliv takové řešení je lépe vzít a udělat to in house pomocí OSS. I kdyby to mělo být dražší (což většinou není), tak se to vyplatí v dlouhodobějším horizontu. Nezažil jsem případ, kdy by tomu tak nebylo.

[deda.jabko]

u 10x nafouklého rozpočtu

Ale z mojí dosavadní praxe plyne, že peníze vynaložené za jakékoliv takové řešení je lépe vzít a udělat to in house pomocí OSS. I kdyby to mělo být dražší (což většinou není), tak se to vyplatí v dlouhodobějším horizontu.

To je normalni uvazovani. Jen to ma ten problem, ze neni kompatibilni s uvazovanim uredniku a zamestnancu korporatu (od urcite velikosti spolecnosti je to v podstate to same).

Cilem urednika neni efektivne vynakladat penize, ale hlidat si prdel. Taky jsem zazil projekt pro statni spravu, kde by v pohode stacil Postgres na desktopu, ktery by jeste soupal nohama, ale byla tam naslapana masina s Oraclem za miliony, protoze pry nikdo jiny vam neda takove zaruky. Jinymi slovy: no one ever got fired for buying IBM, ehm, Oracle.

A cokoliv vyvijet in-house ve statni sprave? Ano, bylo by to levnejsi, jenomze to chce mit penize ve spravne kolonce a samozrejme, programatori dostanou tarifni plat. Takze absolutne nerealne...

[sigma]

A to má být v pohodě?

Nemá, ale taková je teď většinou realita. Najdou se i světlé výjimky.

Ale z mojí dosavadní praxe plyne, že peníze vynaložené za jakékoliv takové řešení je lépe vzít a udělat to in house pomocí OSS. I kdyby to mělo být dražší (což většinou není), tak se to vyplatí v dlouhodobějším horizontu. Nezažil jsem případ, kdy by tomu tak nebylo.

Já bych i souhlasil. Ale vyžaduje to řadu dalších kompetencí, než jaké jsou potřeba na současný businnes-as-usual - obvykle vágní zadání firmě, která se o to postará za 10x nafouklý rozpočet. Nejde jen o to najmout programátory, ale i další profese s doménovou znalostí, a pak také o udržení toho týmu. Tabulkové platy jsou obvyklá mantra, něco na tom je, ale kde je zájem, jsou i cesty jak je obcházet (byť opět to není něco, co by bylo správně / "v pohodě").

Ale jak píše deda.jabko, znamená to zejména převzetí zodpovědnosti, čehož se ve velkých korporacích (a velký úřad k tomu není daleko) příslušní lidé bojí nejvíc. Takže se zaplatí consoluting u big4, kde se nedozvíme nic moc nového, ale máme na to papír, a pak si najmeme velkého dodavatele se "zárukou".

U těch korporací často o peníze vůbec nejde, u typické české pobočky "montovny" s pár tisíci zaměstnanci je pár Mio CZK ročně za licence Oracle nezajímavá položka. Často se o vývoj těch aplikací nad DB starají nepříliš kvalifikovaní lidé, jsou to totální bastly, a ten Oracle je nakonec jediná solidní věc, která to drží pohromadě, protože to nakonfiguroval někdo, kdo věděl co dělá. A na tuto standardní core část vždycky seženu někoho, kdo s tím bude umět pracovat bez větších komplikací.

Po letech provozu několika systémů, které jsem různým zákazníkům nakonfiguroval nad OSS to nevidím úplně jasně. Ať už to je systém pro webhosting nebo Samba doména pro Windows, vždy to vyžadovalo dost kreativity v konfiguaci a pomocných skriptech, nebo vývoj trochu rozsáhlejší aplikace pro management. Dělá to co má, efektivně, slouží roky bez problémů za velmi dobré náklady. Ale přestože k většině věcí je slušná dokumentace, neumím si moc představit, jak by správu těchto věcí přebíral někdo po mě bez mé aktivní asistence. Jako šlo by to, ale sám bych to dělat moc nechtěl. U takovýchto OSS-based řešení mi přijde, že velikost "configuration / customization space" je oproti komerčním enterprise systémům obrovská. Samozřejmě by měla být nějaká zastupitelnost - u malého zákazníka je to otázka aspoň 2 lidí a více peněz, což lze, ale u velkého zákazníka je to už spíš otázka více nezávislých dodavatelů, a to už moc nejde.

Takže buď mám tohle konfigurační know-how plně inhouse, což je docela nákladné ne-li nereálné, nebo to na někoho outsourcuju. A korporace v tomto celkem logicky věří zase spíš jiné dost velké korporaci. Takže to možná není až tak otázka OSS vs. komerčního SW, ale velikosti (a tím z pohledu korporace důvěryhodnoti) těch externích dodavatelů supportu. Jako dobrý příklad mi přijde Red Hat, který už té nadkritické velikosti podle mě dosáhnul.

[Josef Kufner]

To je velice pěkná úloha.

[deda.jabko]

Pamatuji si, ze pred 30-40 lety byl nekdo, kdo umel napsat prekladac takovy exot.

I dnes clovek, ktery umi napsat prekladac je spis rarita nez neco bezneho. A proc? Protoze vetsina vyvoje se soustredi na vyrazne vyssi uroven abstrakce (python, node.js, electron, aplikacni servery) a prekladac je hluboka na urovni operacniho systemu.

Tehdy jem ocekaval, ze za 10 mozna za 20 let vyjdou ze skoly studenti, kteri pak v praxi napisi ve firme podle potreby za 1 den nejaky prekladac nebo interpreter, ktery bude samozrejme orientovan na nejakou specifickou - firemni - problematiku.

I dneska vychazi studenti, kteri to dokazi. V dobe, kdy lze cilit na JVM nebo LLVM napsat prekladac, to neni vubec nic narocneho. Jen to po tech studentech nikdo nechce. A je to dobre. Navrhnout dobre jazyk, pro konkretni domenu, vyzaduje vic nez znalost navrhu jazyka, ale predevsim znalost te domeny a sirsich souvislosti. V opacnem pripade vznikne misto jazyka splacanina, ktera bude casem hazet klacky pod nohy.

35 let uteklo jak voda a ja si myslim, ze se moje predstava nenaplnila.

Napsat prekladac je jenom jedna cast skladacky. Dneska uz nerozhoduje jazyk, ale predevsim ekosystem okolo, zejmana tooling, dokumentace/priklady a support na stackoverflow.

Ukazuje se proto, ze nez vyvijet vlastni DSL je pohodlnejsi vytvaret Embedded DSL (EDSL) v ramci hostitelskeho jazyka. A jazyky tomu prichazeji velkou merou vstric.

Fluent interface nebo makra (LISP, C) jsou takovym zakladem. K vytvareni EDSL lze elegantne pouzit anotace (napr. Java, Ceylon) nebo se da vyuzit rozvolnena syntaxe a call-by-name predavani parametru (Scala, Swift, Kotlin). Vsechny tyto reseni umoznuji vytvorit pekne EDSL bez toho, aniz by clovek prisel o nastroje k hostitelskemu jazyku. Nemluve o tom, ze takto jsou automaticky vyreseny i dalsi slozitejsi veci jako je typovy system.

Vy pripravujete u vas na skole takove odborniky, kteri tu stavbu prekladacu slyseli a cvicili. Kam odchazeji? Co delaji?

Nejspis programuji neco, za co je nekdo jiny plati.

Aby to nekdo nepochopil spatne. Ja si vubec nemyslim, ze by stavba prekladacu bylo nepouzitelne tema, ktere by se melo vyskrtnout z ucebnich planu, kdyz uz se to v praxi neuplatnuje.

...

Obavam se, jestli ta cela vyuka neprobiha pouze v takove te 'vysokoskolske teoreticke rovine'?

Vysoka skola neni ucnak, kde se clovek jen nahrka, jak neco delat a pak to bude v zivote pouzivat do zblbnuti. Vysoka skola ma dat cloveku mimo jine sirsi rozhled v oboru a naucit ho principy, na kterych dany obor stavi. Na skolach vychazejicich z tradice SICP se napriklad konstrukce interpretu uci uz v prvnim rocniku. A neni to z toho duvodu, aby se studentni naucili delat interpret, ale aby pochopili proces vyhodnocovani, lexikalni vazby, uzavery nebo aby si vyzkouseli, jak se bude chovat jazyk s dynamicky vazanymi promennymi (to dneska aby clovek pohledal).

Ma proto smysl ucit prekladace, i kdyz to dany clovek v zivote mozna pouzije maximalne jednou nebo dvakrat, protoze tak muze pochopit, jak funguji nastroje, se kterymi denne prichazi do styku. Podobne jako ma smysl ucit principy, na kterych funguji operacni systemy, i kdyz si myslim, ze operacni system v zivote bude psat jeste o nekolik radu min absolventu VS.

[xkucf03]

Celkově s komentářem souhlasím. Jen pár poznámek:

Navrhnout dobre jazyk, pro konkretni domenu, vyzaduje vic nez znalost navrhu jazyka, ale predevsim znalost te domeny a sirsich souvislosti.

Tohle platí i třeba pro ten návrh XSD nebo API v jazyce typu Java. Přijde mi, že spousta lidí, kteří tvrdí, že dělají API, si pod tím představuje obsluhu toho nástroje/generátoru nebo techniku vystavení nějakých metod/funkcí někam. Ale přitom podstata tvorby API by měla vycházet právě ze znalosti dané domény a logiky věci – to je to nejdůležitější. (ono se to dost překrývá s prací analytika, ale ten většinou na úroveň metod nejde)

K vytvareni EDSL lze elegantne pouzit anotace (napr. Java

A i tohle API (či SPI) se dá navrhnout špatně a nešikovně. Stejně jako ta gramatika. Podle mého to tedy o těch znalostech překladačů (přiznávám, že já taky spíš navrhnu javovské API nebo XSD než gramatiku) je jen z menší části. Zatímco z větší části je to o těch chybějících nebo nepřívětivých nástrojích.

Jestli tu jsou nějací pamětníci, tak prosím o upřesnění či opravu, ale pokud vím, tak v 80. letech se těm gramatikám a překladačům dávala větší váha a lidé v tom viděli budoucnost a mělo to být něco, co se stane všudypřítomné a součást každodenní praxe programátorů. A místo toho se dnes používají spíš ty EDSL, XSD atd. zatímco vlastní gramatiky si definuje málokdo. Nicméně pozůstatky tehdejších představ potkáváme dodnes – obrovské množství různých (byť podobných) formátů konfiguračních souborů různých programů.

[Josef Kufner]

V 80. letech nebyly nástroje, takže slušná gramatika dokázala zpříjemnit práci. Dnes máme spousty nástrojů, které umí existující jazyky a neumí DSL, takže použití DSL je méně přívětivé než použití API.

[okbobcz]

Nejsem pamětník, resp. v IT se pohybuji od začátku 90 let. Tehdy vznikalo dost velké množství jazyků zejména ze třech důvodů: 1. opravovaly se nedostatky, omezení zjištěných praxí, 2. na stávající jazyky se roubovaly nové koncepty, 3. zkoušela se úplně jiná paradigmata. Nebylo XML, nebyl JSON. XML bylo ve své době neskutečnou revolucí. V těch 90 a 80 letech byl vidět ohromný progres v programovacích jazycích - s každou další verzí se mohlo psát efektivněji, čitelněji. Všechny nástroje byly z dnešního pohledu primitivní - ale ve své době znamenaly ohromnou změnu. V podstatě každých pár let byla k dispozici výrazně lepší technologie.

Ty starší formáty, starší jednoúčelové jazyky jsou docela dobře pochopitelné. XML je univerzální, ale zas není až tak triviální si napsat úplný parser XML. Takže aby se mohlo efektivně s jazykem typu XML pracovat, tak potřebuji dostatek paměti, kam by se mi vešla knihovna už s hotovým parserem. Ještě začátkem 80 let se používaly víceprůchodové překladače (kvůli paměti), a podle mne nešlo vymýšlet nějaké příliš obecné koncepty.

Já si myslím, že si nikdo nedovedl v 80 letech, a skoro i v 90 letech představit, co všechno se dá udělat v XML. A velká část představ o vývoji bylo docela zmatené fantazie - šlo se cestou pokus omyl, případně opisování a rozvíjení konkurenčních konceptů.

[Bystroushaak]

XML je univerzální, ale zas není až tak triviální si napsat úplný parser XML.

Pokud to chceš brát skutečně podle specifikace a podporovat DTD a všechno co kolem XML je, tak nejen že to není triviální, ale je to tak brutálně náročné, že skutečně korektně to dělá jen několik knihoven.

[okbobcz]

juju - XML je neskutečný bazmek - asi by se to dalo hodně redukovat - ale i tak, tsv nebo csv jsou výrazně jednodušší.

Koncem 90 let, začátkem nultých let mělo XMLko velkou výhodu v tom, že hromadu kontrolních a CPU náročných činností se mohly přesunout z pomalého skriptovacího jazyka (a že některé skriptovací jazyky jako např. vbscript byly brutálně pomalé) do knihovny napsané v C++. Formátování tabulek se mohlo místo pomalého ASP udělat na straně klienta nativní knihovnou. Tam byl i hodně zajímavý výkonnostní benefit. Dnes díky JITu skriptovací jazyky jsou výrazně rychlejší, ale i tak.

[j]

Jak v csv overis, jestli to pole (a vubec jak zjistis, co je oddelovacem) ma spravny format, rozsah ... naopak, na vsechny ty jednodussi formaty se prave v posledni dobe roubuje presne to, co xml davno umi. Tzn moznost kontroly struktury a datovych typu.

[kralyk z abclinuxu]

naopak, na vsechny ty jednodussi formaty se prave v posledni dobe roubuje presne to, co xml davno umi

Na XML to bylo naroubováno úplně stejně ošklivě, akorát se to stalo už někdy dávno a XML bylo masivně tlačeno všude možně, takže už si na to všichni taknějak zvykli, ať už chtěli, nebo ne.

Původně to je jazyk pro značkování dokumentů a perverzním historickým vývojem se z toho stal formát na serializaci dat a vůbec general purpose. XML nemá samo o sobě ani žádné základní datové typy, kromě vágně definovaného stringu (což je pochopitelné vzhledem k zaměření - textový markup formát), takže XML schema je tam víceméně ad-hoc dodefinovává.

Osobně kdybych tohle chtěl nějak řešit jinak než v aplikace, tak se v téhle chvíli podívám spíš na ten Dhall jak už někdo zmínil nebo podobného...

[xkucf03]

LOL, ty se tu pohoršuješ nad složitostí XML a pak přijdeš s Dhallem, což je nějaký mix serializačního formátu, šablonovacího systému a programovacího jazyka?

[JS1]

Dhall neni serializacni format, je to konfiguracni jazyk. S velmi dobre navrzenym typovym systemem, aby byl typove bezpecny.

[xkucf03]

Dhall neni serializacni format, je to konfiguracni jazyk.

Konfigurace je jen strom objektů (na základě kterých se pak aplikace nějak chová) případně posloupnost událostí (na základě kterých se aplikace dostane do nějakého stavu, typicky si vytvoří nějaké objekty, na základě kterých se pak nějak chová).

A konfigurační soubor je serializovaná konfigurace. Běžně se to serializuje deklarativně a jsou to jen (neživá) data. Ano, může to být pojaté i formou nějakého spustitelného programu, skriptu, ale ta deklarativní serializace bývá jeho podmnožinou. Proto píšu, že je to mix serializačního formátu, šablonovacího systému a programovacího jazyka.

Zrovna šablonovací systém sám o sobě je netriviální záležitost a spousta lidí si na tom už vylámala zuby. Časem totiž zjistí, že jim nestačí jen nahrazovat textové zástupky a pokud mají vkládat hodnoty do šablony, která je v nějakém formátu, musí tomu formátu rozumět a znát jeho syntaxi, aby byli schopní do něj vložit libovolnou hodnotu a nerozbít ho (escapování a jiná pravidla).

A ono vůbec je dost diskutabilní, zda mít takto „živou“ konfiguraci nebo ne (nebo jen neživá deklarativní data). A když už to má být „živé“, tak je otázka, co všechno umožnit – má to např. umět číst soubory z disku nebo komunikovat po síti? Má to mít nějaký omezený počet výpočetních cyklů a paměti nebo to může libovolně vytěžovat moje zdroje?

[kralyk z abclinuxu]

Konfigurace je jen strom objektů (na základě kterých se pak aplikace nějak chová) případně posloupnost událostí (na základě kterých se aplikace dostane do nějakého stavu, typicky si vytvoří nějaké objekty, na základě kterých se pak nějak chová).

Ještě jednodušeji: Konfigurace jsou strukturovaná (typovaná) data.

Proto píšu, že je to mix serializačního formátu, šablonovacího systému a programovacího jazyka.

To si myslím, že je naprosté nepochopení, viz citace z dokumentace Dhallu:

Dhall is a total programming language that forbids arbitrary side effects.

Dhall is not a Turing-complete programming language, which is why Dhall’s type system can provide safety guarantees on par with non-programmable configuration file formats.

V zásadě o tom můžeš uvažovat jako o stejně 'neživé' konfiguraci jako XML.

[kralyk z abclinuxu]

LOL, ty se tu pohoršuješ nad složitostí XML a pak přijdeš s Dhallem, což je nějaký mix serializačního formátu, šablonovacího systému a programovacího jazyka?

Možná to z toho nebylo jasné, ale Dhall přímo nedoporučuju, neznám ho nijak do hloubky, nepoužíval jsem ho v praxi. Zmiňuju ho jen jako možnost, na kterou bych se podíval / evaluoval, pokud bych chtěl tenhle usecase řešit. Líbí se mi na tom minimálně to, že to někdo navrhl právě za tímhle účelem (verifikovatelná konfigurace), tj. není to jen víceméně náhodně ohnutá věc k tomu účelu.

Co se týče složitosti, nepřijde mi na první pohled nijak extra složitý. Minimálně mi ale přijde, že ta složitost, i když by třeba byla vyšší, má nějaký rozumný důvod, narozdíl od XML, kde je často pouze náhodná/historicky daná...

[JS1]

Ja bych to taky nikomu do produkce s klidnym svedomim nedoporucil, prave proto, ze to povazuju za inovaci. U pocitacu jsou technologie, co jsou inovacemi - vetsinou nejsou vhodne pro produkcni pouziti. A pak jsou technologie, co jsou spis takovou vhodnou (a obcas strasidelnou) syntezou technologii, ktere prave inovativni jsou.

Druhy pripad je treba prave CBOR (XML by bylo mozne povazovat za podobnou inovaci pro svuj use case, tj. ukladani textovych dat). To je asi 4. pokus (rekneme cca po JSONu, ruznych jeho binarnich variantach a Msgpacku), kdy uz se jasne vedelo, co je potreba a kde jsou kompromisy navrhu.

[JS1]

On nemuze existovat jeden datovy metaformat uz proto, ze existuji 3 ruzne use cases:

1. Konfigurace

2. Vymena kvazistrukturovanych dat mezi systemy

3. Ukladani textovych dokumentu

Kazdy z tech use cases vede na diametralne odlisne pozadavky navrhu. 1 musi byt textovy format, 3 muze byt textovy format, u 2 je byt textovy dost pochybne. U 3 chceme primarne zapisovat text a escapovat anotace, u 1 a 2 naopak chceme escapovat text. Kazdy z tech pripadu pouziti znamena jinou formu normalizace. Atd.

[xkucf03]

Chyba podle mého je, že se spojují dohromady dvě věci, které jsou na sobě nezávislé. 1) datový model a 2) jeho konkrétní převod na posloupnost bajtů a zpět (serializace/deserializace).

Datový model může být pro velkou množinu aplikací společný. A díky tomu lze používat i společné nástroje.

Zatímco ta serializace se může lišit podle toho, zda to má editovat člověk nebo zda chceme optimalizovat na co nejmenší náročnost na CPU nebo na paměť nebo na síťovou/diskovou kapacitu.

V tomhle se mi líbí ASN.1, která právě tyto dvě roviny odlišuje – abstraktní datový model na jedné straně a různé serializace dle využití (BER, DER, CER, XER, PER). Klidně si můžeš vymyslet i kódování do CBORu, JSONu, YAMLu atd.

[JS1]

Ja je nespojuji dohromady - ja mluvim predevsim o te serializaci. Treba otazka jestli escapovat text nebo metadata je ciste otazka serializace. Datovy model je samozrejme jeste dalsi vec, ale zase zalezi na konkretnim use case.

[xkucf03]

Ja je nespojuji dohromady - ja mluvim predevsim o te serializaci.

Ty možná ne, ale většina těch truc-formátů ignoruje datové modely XML nebo ASN.1 a v zápalu boje za lepší textovou syntaxi a kulatější/hranatější závorky jen tak mimochodem definuje vlastní datový model, nekompatibilní s těmi stávajícími. Místo toho, aby se soustředili jen na tu serializaci (když už mají neodbytný pocit, že je tak nutně potřeba nějaká jiná).

Např. JSON nebo CBOR mohly klidně vzniknout jako alternativní serializace/kódování pro XML nebo ASN.1. A to API směrem k aplikacím a knihovnám mohlo zůstat stejné a většina stávajících nástrojů se mohla beze změny použít. Časem mohla vzniknout nějaká verze 2.0, která by API a datový model pročistila nebo vylepšila. Mohlo se to vyvíjet evolučním způsobem bez prudkých změn. Ale to asi nejde a spousta lidí ráda zahazuje stávající technologie a znovu-vynalézá kolo.

Treba otazka jestli escapovat text nebo metadata je ciste otazka serializace.

Tak zrovna XML umožňuje smíšený obsah (text na stejné úrovni promíchaný s elementy) a díky tomu dobře podporuje oboje, dají se jím psát jak dokumenty, tak serializovat strukturovaná data. Pokud bys např. umožnil uzavírat element pomocí </>, tak odpadne i ta nevýhoda s redundantním názvem elementu, ale pro smíšený obsah to bude použitelné stále stejně dobře.

[JS1]

IMHO JSON nebo CBOR proste nechteji podporovat mixed content, takze pokud ho chces ukladat v tech formatech, musis si nejak poradit jinak. Stejne tak nemaji {IMHO nadbytecne) rozliseni mezi textem v elementu a textem v atributu.

Ty mas proste rad jeden konkretni datovy model, a to ten z XML. Ale jini lide maji jiny nazor, z ruznych duvodu. Ja si treba myslim, ze CBOR je nejlepsi kompromis pro ten use case 2.

[xkucf03]

Ty mas proste rad jeden konkretni datovy model, a to ten z XML.

Ne, já mám rád XML celkově jako ekosystém. Neříkám, že je dokonalé, ale v rámci toho, co máme… A taky mám určité sympatie k ASN.1, které si to ve svých počátcích trochu pokazilo a lidi ho moc nebrali (a pak už přišlo XML), ale v mnoha ohledech je to pořád takový svatý grál datových formátů a modelů.

Stejne tak nemaji {IMHO nadbytecne) rozliseni mezi textem v elementu a textem v atributu.

O tomhle už jsem tu taky někdy psal. Souhlasím, že atributy jsou nadbytečné a teoreticky by stačily jen elementy, ale je to takový ústupek praktičnosti a stručnějšímu zápisu. Na jednu stranu lidé XML vyčítají, že je ukecané, a na druhé straně mu vyčítají, že jim vychází vstříc a umožňuje jednodušší a přívětivější textový zápis.

IMHO JSON nebo CBOR proste nechteji podporovat mixed content

A je smíšený obsah takový problém a komplikace, aby bylo potřeba hodit přes palubu celou velkou množinu případů užití?

Smíšený obsah vlastně znamená, že místo objektu (tak nějak intuitivně vnímaného jako mapa) máš seznam uzlů, kde uzel může být buď textový nebo to může být dvojice klíč=hodnota. Já v tom až takový problém/zesložitění nevidím – zvlášť když mám schéma a můžu říct, že v tomhle mém formátu textové uzly nejsou (resp. není smíšený obsah).

A zvlášť vtipné je to v souvislosti s tím, že JSON může dle specifikace obsahovat duplicitní klíče. Takže to vlastně žádné klíče nejsou i tady máš tedy ten seznam uzlů místo nějakého objektu (byť si většina lidí mylně JSON jako nějaký objekt/mapu představuje).

[kralyk z abclinuxu]

většina těch truc-formátů ignoruje datové modely XML nebo ASN.1 a v zápalu boje za lepší textovou syntaxi a kulatější/hranatější závorky jen tak mimochodem definuje vlastní datový model, nekompatibilní s těmi stávajícími.

Stávající? Datový model JSONu, tedy datové typy JavaScriptu, je IIRC starší než celé XML.

Jinak musim říct, že je pro mě matoucí, když v komentářích mluvíš o XML, protože mi z toho není jasné, kdy mluvíš o XML jako takovém (které AFAIK žádný datový model nemá) a kdy je to takový umbrella termín pro XML + XML Infoset + XML Schema + XPath/XQuery + XSLT + kdovíco dalšího. Ale třeba Relax NG pokud vim do toho nepočítáš.

XML žádný datový model nemá, takže by bylo možná dobré říct, co tím datovým modelem vlastně myslíš. Hádám, že máš na mysli datové typy z XML Schema? Nebo XML Infoset? To asi ani ne, protože Infoset není datový model, spíš je to AST pro XML.

Např. JSON nebo CBOR mohly klidně vzniknout jako alternativní serializace/kódování pro XML

To je IMO nereálná představa... JSON vznikl mj. s ohledem na maximální kompatibilitu s JavaScriptem, for better or worse, to by jen s alternativní syntaxí pro XML šlo hůř. Problémy XML nejsou jen v syntaxi. Kdyby to měla být jen jiná syntaxe pro XML, tak bys tam musel přidat nějak atributy, processing instructions a kdovíco dalšího, což je všechno mimo scope JSONu.

[xkucf03]

To je IMO nereálná představa... JSON vznikl mj. s ohledem na maximální kompatibilitu s JavaScriptem, for better or worse, to by jen s alternativní syntaxí pro XML šlo hůř. Problémy XML nejsou jen v syntaxi. Kdyby to měla být jen jiná syntaxe pro XML, tak bys tam musel přidat nějak atributy, processing instructions a kdovíco dalšího, což je všechno mimo scope JSONu.

Můžeš si z toho vzít podmnožinu. V extrémním případě třeba jen elementy a textové uzly, používat to pro serializaci datových struktur a mít syntaxi podobnou dnešnímu JSONu. Ale díky stejnému datovému modelu (resp. jeho podmnožině) můžeš používat již hotové nástroje jako XPath, XSLT, XQuery, RelaxNG a cokoli dalšího – a nemusíš je pracně znovu-vynalézat.

[kralyk z abclinuxu]

Tomu nerozumim, pokud stačí podmnožina, tak to dnešní JSON splňuje, ne?

Ad RelaxNG, myslel jsem, že má jinej datovej model.

[JS1]

Stejne tak by se dalo rict, CBOR ma uzivatelsky definovane "typy" (tagy), takze muze definovat libovolnou nadmnozinu typu a tim padem je jeho datovy model rozsiritelny.

[Josef Kufner]

Naneštěstí však nemá jmenné prostory, takže to není až tak univerzálně použitelné.

[JS1]

V tom nevidim moc problem. Od otazky "komu patri tag" prejdes k otazce "komu patri jmenny prostor".

[xkucf03]

Která je triviálně řešitelná. Jmenné prostory se typicky odvozují od internetových domén, které patří jednomu konkrétnímu subjektu. Případně je můžeš odvozovat od věcí jako Private Enterprise Numbers (OID) nebo jiných identifikátorů. A pokud použiješ Tag URI scheme (což je nejlepší možnost), tak v tom máš i tu časovou složku (doména nebo identifikátor může změnit vlastníka, ale v jeden časový okamžik patří právě jednomu subjektu).

A i kdybys nic z toho neměl, můžeš si vygenerovat UUID, pár soukromého a veřejného klíče nebo třeba .onion adresu (Tor) a svoje URI odvodit od toho.

Asi bych měl dopsat ten článek, který na tohle téma mám rozmyšlený, protože to zjevně potřebuje nějakou osvětu. Nepoužívat jmenné prostory je čirá retardace.

[JS1]

Ja si myslim, ze zakladat to na domenach je nesmysl, a krasne se to ukazalo prave v momente, kdy se Sun prejmenoval na Oracle. Pokud se tvoje data citi byt natolik slavna, muzes si u CBORu zaregistrovat tag toho typu u IANA registry. Pokud ne, tak se s tou kolizi proste nejak vyporadas, ten program, co generuje ty tagy, musi vedet, ze jsou v konfliktu, a zaridit se podle toho.

Proste prijde mi to jako umely problem - rad bych videl scenar u vymeny dat, v kterem to skutecne problem je, a neresi to ten centralni registr typu.

[Josef Kufner]

Ten program to pozná těžko. Tagy mu jen nebudou dávat smysl.

[JS1]

Zkus mi nastinit konkretni scenar. Treba v programovani muze nastat situace, kdy dve knihovny maji stejne jmeno. Pak je mozne do tveho programu, ktery potrebuje obe knihovny, typicky zadat, ze jedno nebo obe ty jmena budu odkazovat jinym jmenem (jestli je kvalifikovane nebo ne se mi zda nepodstatne).

Stejne tak tady, pokud mam vlastni aplikaci, ktera nejakym zpusobem dostava dva ruzne zdroje dat, kde ty tagy koliduji, pak neni prece problem za kazdy ten zdroj zaradit filtr, ktery ty tagy prejmenuje. Ano, je to opruz, ale je to opravdu v praxi tak casta situace? Ja to narozdil od tech knihoven nevidim moc realne (protoze znovupouzitelnost typoveho modelu je daleko nizsi a mene zadouci nez znovupouzitelnost funkci), ale mozna se pletu.

[xkucf03]

Zkus mi nastinit konkretni scenar. Treba v programovani muze nastat situace, kdy dve knihovny maji stejne jmeno.

A proto Java nebo C++ používají jmenné prostory, abys tomuto problému předešel. A proto bys měl třeba hlavičkové soubory dávat aspoň¹ do:

#include <js1/funkce.h>

a ne do:

#include <funkce.h>

abys předešel kolizím a nezaneřádil globální jmenný prostor.

Ano, je to opruz, ale je to opravdu v praxi tak casta situace?

Když už se snažíš uvažovat „jestli to stojí za to“, tak je dobré se podívat, jaké jsou náklady těch jiných řešení – a pak teprve si můžeš říct, že jsou moc vysoké a raději to nějak ošidíš, protože dělat to pořádně se ti nechce.

Jenže ty náklady těch lepších řešení se jmennými prostory jsou naprosto minimální (viz komentáře níže).

I ta prehistorická ASN.1 (a tím pádem SNMP, X.509, LDAP a další technologie) je v pohodě rozšiřitelná. Sice si tam musíš požádat centrální autoritu o přidělení čísla pro svoji organizaci (to dostane každý a zadarmo), ale pak už máš vlastní jmenný prostor a v něm si můžeš dělat, co chceš, a nemusíš se s nikým dohadovat, jestli tenhle atribut nebo tenhle datový typ či hodnota číselníku může vzniknout nebo ne. A máš globálně unikátní názvy, které nebudou s ničím kolidovat.

_{[1] lepší by bylo i sem dát globálně jedinečný název odvozený např. od tvé domény}

[JS1]

Pokud to nebylo jasny, tak znova. Ja chapu scenar v programovani, nechapu ten scenar ve vymene dat.

To co popisujes jde i v CBORu, muzes ty tagy kombinovat a predradit svym tagum nejaky jeden, co sis nechal zaregistrovat.

[xkucf03]

Oproti XML mi to ale přijde jako krok zpátky. Tam si nic registrovat nemusíš a můžeš si globálně unikátní jmenný prostor klidně vygenerovat sám. A existují i binární serializace XML (ať tu nesrovnáváme textové a binární formáty).

[JS1]

Pokud pro to neexistuje use case, tak ten krok zpatky nejak nevidim.

[xkucf03]

Zakládat to můžeš na čem chceš. Třeba si ten jmenný prostor odvodíš od otisku veřejného klíče a nepotřebuješ k tomu žádnou centrální autoritu nebo registr. A kdykoli pomocí soukromého klíče dokážeš, že ten jmenný prostor patří tobě (většinou není potřeba to řešit až takhle přísně/technokraticky, ale ta možnost tu je).

V dnešní době je lepší se při návrhu systémů/protokolů/formátů těm centrálním autoritám vyhnout a udělat to flexibilní a distribuované. I za cenu toho, že to může mírně zvýšit nároky na přenosovou kapacitu nebo paměť (řetězec URI je přeci jen delší než pár bajtů nějakého kódu, nicméně se to dá udělat i tak, že se celé URI předá jen jednou, a pak se na něj jen odkazuje, takže obsazené místo navíc je minimální). Zatímco dřív tohle byl problém, výpočetních zdrojů bylo málo (zlomek oproti současnoti) a spíš byla tendence použít nějaký ten krátký identifikátor z centrálního registru (na úkor flexibility). A politická situace té centralizaci taky moc nepřeje… ono i ty domény jsou dost na hraně a v podstatě jako koncept dožívají.

[Josef Kufner]

XML pro jmenné prostory používá URI specifikace (dokumentace) toho prostoru a při jeho zavedení se definuje alias. Je to asi nejlepší řešení, co jsem viděl.

[xkucf03]

Ano. A stejně to jde dělat i v binárních protokolech nebo formátech – na začátek dáš číselník mapující použité URI na nějaké krátké¹ kódy.

_{[1] což může být klidně jediný bajt – 256 jmenných prostorů ti bude většinou stačit, nebo můžeš použít třeba ULEB128 a do prvního bajtu se vejde 128 jmenných prostorů a volitelně jich můžeš mít libovolné množství}

[Josef Kufner]

V tomhle je mnohem lepší JSON. Dokonce k tomu existuje i JSON Schema právě po vzoru XML. Jen tam není možnost jmenných prostorů, takže se to těžko rozšiřuje nad rámec záměrů autora.

[JS1]

XML a JSON neexistoval do 90. let predevsim z duvodu rychlosti. Dneska se na rychlost kasle, ale tehdy bylo kodovani/dekodovani do textu a zpet pomerne drahe. Proto se data ukladala binarne (a nativne).

Ja si myslim, ze XML a JSON nejsou pokrok, ale kazdemu co jeho jest. Naopak, CBOR a Dhall lze povazovat pokrok.

[j]

XML pokrok je, je to zpusob jak zapsat definici struktury + vlastni data tak, aby to slo precist kdekoli, pripadne aby to zvlad i clovek bez dalsich nastroju a aby to cely bylo samopopisny. JSON uz zadny pokrok neni, to je jen pokus z XML odstranit to co je na tom "slozity", aby se to tam nasledne opet roubovalo zpet.

Co pro XML bylo problematicky tak predevsim to, ze vychazi z html, a v html se v dobe vytvareni xml uz prasilo ve velkym. Tak nejak se pak cekalo, ze stejne prasit pujde i xml.

[xkucf03]

+1

[JS1]

XML pokrok je, je to zpusob jak zapsat definici struktury + vlastni data tak, aby to slo precist kdekoli, pripadne aby to zvlad i clovek bez dalsich nastroju a aby to cely bylo samopopisny.

S tim neprislo XML, to uz existuje od dob Lispu.

Co pro XML bylo problematicky tak predevsim to, ze vychazi z html

Ne, XML vychazi primo ze SGML, proto je take s HTML nekompatibilni. (HTML take vyslo ze SGML.)

[kralyk z abclinuxu]

XML pokrok je, je to zpusob jak zapsat definici struktury + vlastni data tak, aby to slo precist kdekoli

Jo... Půjde to přečíst úplně kdekoli, pokud cílový čtecí program používá stejné kódování, stejné schéma nebo v případě použití bez schématu stejnou serializaci datových typů do stringu, stejným způsobem se chová k trailing whitespace atd.

JSON uz zadny pokrok neni, to je jen pokus z XML odstranit to co je na tom "slozity", aby se to tam nasledne opet roubovalo zpet.

Minimálně má základní datové typy a lépe vyřešené kódování a escapování. Má samozřejmě i svoje nevýhody.

[Josef Kufner]

A co udělat XML2, které by mělo typy jako JSON a vyházely by se z něj zbytečně složité vymoženosti?

[xkucf03]

které by mělo typy jako JSON

JSON „má typy“ v tom smyslu, že tam zapisuješ číslo jinak než text. Jak by sis to představoval v XML? Dneska píšeš: <text>ahoj</text> a <číslo>123</číslo>. Jak bys ty typy chtěl odlišovat? Přidávat tam nějaké uvozovky je nesmysl. Ale už dnes můžeš dá ten typ do atributu. A díky jmenným prostorům bude mít tento atribut pro vyznačení typu globálně unikátní název a nebude docházet ke kolizím s jinými atributy.

JSON má sedm datových typů: objekt, pole, text, číslo, true, false, null. Objekt a pole máš nativně v XML – objekt je element s dalšími vnořenými elementy a pole je opakující se element. Null máš v XML taky: xsi:nil="true" (pokud ti nestačí vynechat element). Takže zbývá vlastně jen odlišení čísel a booleanů.

Čísla v JSONu jsou desetinná a parsery je většinou převádějí na float dle IEEE 754, což je nepoužitelné např. pro peněžní a jiné aplikace, kde potřebuješ přesná desetinná čísla, takže se často číslo do JSONu stejně kóduje jako string. Datum v JSONu pro jistotu není, takže se opět kóduje jako string a musíš si nějak bokem říct, v jakém formátu to bude.

Ale hlavně: datové typy bez schématu jsou víceméně k ničemu. Co je ti platné, když víš, že 123 ve "foo" : 123 je číslo, když nevíš, co je foo? I když tam budeš mít napsáno třeba "teplota" nebo "rychlost", pořád je ti to číslo k ničemu, protože nevíš, jestli to jsou ° C nebo ° F, jestli to jsou megabajty nebo megabity nebo snad baudy či kilometry v hodině. Data vs. informace. A když je to takové dynamické, tak nemáš zaručeno vůbec nic, klidně tam můžeš mít pětkrát true nebo false, tak si budeš myslet, že máš boolean, ale prásk, šestá položka v tom políčku bude mít 123 nebo "hovno" a je to perfektně validní JSON, klidně to v rámci té aplikace může mít nějaký definovaný význam, akorát ty ho neznáš, protože nemáš schéma. Typy bez schématu jsou v textových formátech bezcenné. Smysl to má tak leda v binárních formátech, kde díky tomu ušetříš pár bajtů, protože čísla a booleany nemusíš ukládat jako řetězce v ASCII.

A co udělat XML2, … vyházely by se z něj zbytečně složité vymoženosti?

Docela bych uvítal XML 2.0, které by bylo podmnožinou XML 1.0, oproti kterému by nemělo DTD a entity (nad rámec těch standardních/číselných). To je tak asi všechno, co by mělo smysl tam měnit.

Dalo by se uvažovat i nad zjednodušení uzavíracích značek, místo <element>obsah</element> by se teoreticky mohlo psát <element>obsah</>, protože ta informace, co budeme uzavírat, je redundantní. Na druhou stranu určitá míra redundance není na škodu, zvlášť když to píše nebo čte člověk. Nicméně v programovacích jazycích běžně máme složené závorky a člověk si to musí uhlídat sám, co kde končí. Na tohle nemám úplně vyhraněný názor.

[kralyk z abclinuxu]

Přidávat tam nějaké uvozovky je nesmysl.

Ironické je, že XML už uvozovkovou syntaxi má - v syntaxi atributů.

pole je opakující se element

Není. Opakující se element je pouze konvence. Nic ti nebrání do sekvence elementů např. vložit jiný element, formát bude stále validní.

Null máš v XML taky: xsi:nil="true"

Tohle není součástí XML, nýbrž XML Schema. Takže už se bavíme o XML + XML Schema.

Čísla v JSONu jsou desetinná a parsery je většinou převádějí na float dle IEEE 754, což je nepoužitelné např. pro peněžní a jiné aplikace, kde potřebuješ přesná desetinná čísla, takže se často číslo do JSONu stejně kóduje jako string. Datum v JSONu pro jistotu není, takže se opět kóduje jako string a musíš si nějak bokem říct, v jakém formátu to bude.

Ano, JSON obsahuje pouze několik základních datových typů. Cokoli nad to je potřeba vyjádřit nějakým způsobem pomocí základních typů. Nemusí se to nutně serializovat do stringu, např. zlomky by se daly serializovat do pole dvou čísel (u toho taky narazíš na to, že JS a JSON bohužel nemají integery, což je další problém).

Všimni si, že Java ani většina běžných jazyků taky nemají primitivní typ pro fixed-point aritmetiku, taky si na to musí vytvořit nějaký newtype / kompozit.

Ale hlavně: datové typy bez schématu jsou víceméně k ničemu.

S tím souhlasim, ale IMO jak tohle dobře udělat je stále otevřená otázka. XML Schema nebo JSON Schema se používat v praxi dají, ale přijde mi to oboje jako hack - snaha našroubovat do těch formátů něco, na co nejsou dělané, zejména zápis typů.

V tomhle je IMO právě přínos toho přístupu á la Dhall - ten jazyk podporuje tvorbu vlastních typů stejně dobře jako zápis literálů, narozdíl od XML, JSONu atd.

[kralyk z abclinuxu]

Tady je diskuse o použití Dhallu pro validaci jinejch formátů.

[xkucf03]

Yes, you can do this using the json-to-dhall utility

Thank you, but can this also be done entirely inside the application as part of loading the configuration?

If your application is written in Haskell then you can use the dhall-json package which exposes the same functionality as a Haskell API.

Althought for my purposes it would probably be enough that the implementation exposes data types for AST / in-memory representation and allows validating that against a schema, I could then load data from arbitrary formats, convert/map them to Dhall AST and validate.

Totéž jsem ti říkal pro XML, viz #174. Tzn. buď si a) zavoláš příkaz alt2xml a převedeš si jeden proud bajtů na proud bajtů v XML a pak si to v libovolném jazyce/nástroji zvaliduješ proti XML schématu (či Relax NG, či Schematronu atd.). Nebo b) napíšeš to v Javě a použiješ alt2xml jako knihovnu (ne jako program/proces) implementující SAX parser a načtení i validaci máš v jednom procesu. Nebo c) implementuješ si tenhle koncept v libovolném jazyce¹, a pak máš to máš v jednom procesu (nevoláš externí program) a zároveň to nemusí být v Javě, když ji tak nemáš rád, a uděláš si to ve svém oblíbeném jazyce.

_{[1] jde v podstatě jen o napsání adaptéru, který přeloží volání parseru jiného formátu na rozhraní SAX parseru, což bývá triviální}

[kralyk z abclinuxu]

Ale jo, já chápu, jaks to myslel a jak to funguje. Ale XML schémata ani JSON schémata používat na tohle nechci. Přijde mi to hnusný - ani XML ani JSON nejsou na tohle určený, a podle toho pak výsledek vypadá.

Oproti tomu Dhall má normální příčetný ML-style typový systém, který je i na tohle navržen a bylo by z mého pohledu supr mít možnost ho na tohle použít, i kdybych přímo Dhall pro konfiguráky nechtěl použít. Proto jsem se jich na to ptal.

Jinak tohle není problém, který bych teď aktuálně potřeboval řešit, klidně si počkám, až bude Dhall trochu víc dokončený, existovat víc implementací atd. Řešim to spíš ze zájmu.

[Josef Kufner]

Hlavní problém XML je v tom, že nedokáže rozlišit mezi null a prázdným stringem, nebo mezi nenastaveným atributem a false. Tím, že je všechno string, je potřeba do XML ještě definovat další gramatiky na prakticky všechno. JSON díky základním typům nemá problém vyjádřit nullable hodnoty a pokud jazyk rozlišuje null a undefined, tak umí i nenastavené hodnoty, i když to v praxi není nijak podstatné (null obvykle stačí).

Vlastně by možná stačilo, kdyby se hodnoty atributů v XML nahradily JSON hodnotami:

<element key="foo" value=10 exists=true polovina=[1, 2] />

[xkucf03]

Hlavní problém XML je v tom, že nedokáže rozlišit mezi null a prázdným stringem

Tohle nedokáží ani některé databáze a lidé je vesele používají. Naopak jsem nejednou slyšel lidi si stěžovat, že např. v Javě je null a prázdný String něco jiného a že by to mělo být totéž, že je to nelogické atd. A spousta lidí si píše vlastní kód, kterým se to snaží napravit/ohnout tak, aby se null a prázdný řetězec považoval za totéž (prostě chybějící hodnota). Tzn. místo String.equals() používají nějakou vlastní metodu.

nebo mezi nenastaveným atributem a false

Pokud máš jen dvoustavový boolean (true, false, bez null, což je docela běžné) a nechceš vyhazovat výjimky resp. ukončit předčasně běh programu, tak je tohle víceméně jediná možnost, jak se k tomu postavit.

Třístavový boolean je trochu kontroverzní záležitost (neříkám, že ho občas nepoužívám) a spousta lidí by proti němu protestovala. Vyhazovat výjimky resp. předčasně skončit jen proto, že někde chybí položka, taky není žádoucí. Tak se za výchozí hodnotu prohlásí false a je hotovo. Pokud chceš, aby tam lidi to políčko nezapomínali vyplňovat, tak z něj uděláš povinný element/atribut ve schématu.

JSON díky základním typům nemá problém vyjádřit nullable hodnoty a pokud jazyk rozlišuje null a undefined, tak umí i nenastavené hodnoty, i když to v praxi není nijak podstatné (null obvykle stačí).

V praxi je většinou lepší použít nějaký enum s explicitně definovaným významem, než se spoléhat na tohle. Ještě se to dá u toho null, který znamená chybějící hodnotu a je to celkem intuitivní, ale přisuzovat nějaký odlišný význam tomu, že políčko s hodnotou null bude něco jiného, než chybějící políčko, je dost ošemetné. Podobné je rozlišování prázdné kolekce a chybějící kolekce (případně null kolekce). Někdy se to používá, ale není to asi úplně nejlepší praktika, zakládat na tomhle logiku programu.

A přijde mi to poměrně zcestné používat jako argument proti XML to, že nemá nějakou celkem obskurní funkcionalitu s diskutabilním využitím.

Vlastně by možná stačilo, kdyby se hodnoty atributů v XML nahradily JSON hodnotami

Stačilo k čemu? Aby byl ten parser a API složitější? A ty hranaté závorky by se měly interpretovat jak? Atributy jsou v XML atomické hodnoty. Navrhuješ ten model překopat, aby hodnotou atributu mohlo být pole? Může být i hodnotou elementu? Nebo snad povolit duplicitní atributy a překopat to SAX a DOM API?

Oproti tomu ten návrh, kdy by se jen vypustilo DTD a nestandardní entity, by přinesl zjednodušení (parser by mohl být výrazně jednodušší), ale přitom API směrem k aplikacím by zůstalo stejné, takže by se nic nemuselo přepisovat a většina dokumentů by se do té podmnožiny vešla nebo by šla triviálně převést.

[Josef Kufner]

Rozlišovat null je užitečné, pokud je například potřeba pracovat s defaultními hodnotami, přepsat obecněji nastavenou hodnotu, nebo vyjádřit chybějící hodnotu (např. boolean senzor, který zrovna nemá data).

Návrh vypustit DTD a nestandardní entity je rozumné zjednodušení, které by asi stálo za pokus, ale neřeší to ty ostatní problémy. Povolit objekty a pole v atributech by bylo zesložitění, ale dát tam jen skalární hodnoty JSONu by větsinu potíží řešilo a formálně nic nerozbilo. Jen ta API by musela počítat s pár typy navíc. Povolení pole a objektu by nijak nemuselo narušit atomicitu atributu – XML by to zkrátka stále bralo jako jednu hodnotu. Umožnilo by to kultivovaně zadávat komplexní čísla, souřadnice a podobné věci. V těle elementů asi nemá smysl uvažovat o ničem jiném než o textu, neboť syntaxe by jinak docela utrpěla.

[Heron]

Tohle nedokáží ani některé databáze a lidé je vesele používají.

Tak se za výchozí hodnotu prohlásí false a je hotovo.

Což je taky fajn zdroj silent data corruption, kdy po chvíli není jasné, zda je hodnota nezadaná, nebo je skutečně nulová.

Tohle mě trochu štve právě na golangu, kdy typy mají defaultní nulové hodnoty, 0, "", false a pokud člověk chce ještě rozlišit null, tak je nutné všude používat pointer (nebo vlastní struct s indikací null), což je docela opruz. Ostatní jazyky tohle mají vyřešené líp, kdy i proměnná s hodnotou může být klidně null.

[JS1]

Kdybych mohl zmenit historii pocitacu, tak bych definoval integer x'80000000' jako NaN, ale to je jen osobni nazor.

[xkucf03]

Tak zrovna v číslech s plovoucí desetinnou čárkou (IEEE 754) těch NaN máš spoustu (někdy se jim přisuzují i jiné zvláštní významy a něco se do nich kóduje, což je docela mešuge) a máš tam i plus a mínus nekonečno :-)

[JS1]

Proto mluvim o integerech.

[Radovan]

Mě by se to hodilo spíš jako INF

[xkucf03]

Tohle mě trochu štve právě na golangu, kdy typy mají defaultní nulové hodnoty, 0, "", false a pokud člověk chce ještě rozlišit null, tak je nutné všude používat pointer (nebo vlastní struct s indikací null), což je docela opruz. Ostatní jazyky tohle mají vyřešené líp, kdy i proměnná s hodnotou může být klidně null.

Tohle je zase dané tím, že část lidí má chorobný strach z NullPointerException a propadají panice, kdykoli nějaký null vidí, tak se rozhodli to řešit tím, že null vůbec existovat nebude.

Dá se to řešit přes Optional nebo přes kolekce/posloupnosti, které můžou být prázdné… ale jestli je to výrazně lepší než null, je sporné. Asi jak kdy. Ale to už mi často přijde lepší to řešit přes nějaké anotace, kde řekneš, že tahle hodnota nebude nikdy null, a ten, kdo ji konzumuje pak ví, že může být v klidu – a naopak když tam ta anotace není, tak ví, že může přijít i null a je to legitimní stav, se kterým má počítat.

[Heron]

Tak u toho golangu toto určitě není důvod. Ten je silně a staticky typovanej, takže i

type Jmeno string
type Prijmeni string

jsou dva zcela různé datové typy. Stejně tak hodnota a pointer je něco zcela jiného. Takže to vlastně dává smysl a kdo chce rozlišit null, má použít pointer. Ale syntakticky by to šlo ošetřit, podobně jako pointer na struct:

type Stuktura struct {a, b, int}

v := Struktura{1, 2}
p := &v

// tak můžeš psát:
p.a = 3

// na místo očekávaného (což funguje také)
(*p).a = 3

Tj někde je ta dereference tvrdě vyžadována a někde ne.

Ale to je asi součástí tradice, ještě jsem nenarazil na jazyk, kde by nebyla žádná podobná nelogičnost.

[JS1]

Hlavni problem null je v tom, pokud je to implicitne jako mozna hodnota "mimo" typovy system. Tj. treba jak to ma Java (pripadne u pointeru v C). Nejde tedy o null jako takovy, ale jestli se pouziva explicitne.

Optional jenom rika - hodnota muze byt bud skutecnou hodnotou, nebo nedefinovana. Coz je z hlediska typovani korektnejsi. Tvoje reseni pres anotaci je jenom simulace typoveho systemu.

Dokonce ani implicitni null jako soucast typu neni sam o sobe problem, pokud se operace nad tim typem dokazi vyrovnat s tou hodnotou. Treba u retezcu resp. cisel neni problem brat "" resp. NaN jako null.

Zkus si precist neco o typovych systemech, treba naucit se trochu Haskell. Pak uvidis ten smysl.

[deda.jabko]

Hlavni problem null je v tom, pokud je to implicitne jako mozna hodnota "mimo" typovy system.

Ja radsi na null nahlizim jako na priznak absence hodnoty. (Neni to hodnota per se.)

Optional jenom rika - hodnota muze byt bud skutecnou hodnotou, nebo nedefinovana.

To ma v principu tu vyhodu, ze to programatora nuti prirozene (a explicitne) resit mezni situace. NPE je implicitni nedokonale ale efektivni (z pohledu rychlosti) reseni.

Tvoje reseni pres anotaci je jenom simulace typoveho systemu.

To neni v zasade nic spatneho. Nekdy se to oznacuje jako pluggable type system.

Dokonce ani implicitni null jako soucast typu neni sam o sobe problem, pokud se operace nad tim typem dokazi vyrovnat s tou hodnotou.

Problem je, jak ty operace spravne definovat. Napr. pokud mas NaN (u double) a nebo NULL (v SQL), relace porovnani na rovnost neni reflexivni... to neni vubec hezke.

[JS1]

Ja radsi na null nahlizim jako na priznak absence hodnoty. (Neni to hodnota per se.)

Ja asi nesouhlasim s touhle interpretaci. Prijde mi to matematicky neelegantni, narozdil od toho Optional (nebo Maybe).

Chovani, ktere odpovida tomu "absence hodnoty" pak muzes snadno dostat z Maybe monady, ale naopak mi to prijde slozitejsi. To bys musel pak vsechny hodnoty zasunout do nejake implicitni monady, ktera by byla schopna tu situaci rozeznat (coz vlastne dela ta Java tim, ze vyhazuje NPE).

Problem je, jak ty operace spravne definovat. Napr. pokud mas NaN (u double) a nebo NULL (v SQL), relace porovnani na rovnost neni reflexivni... to neni vubec hezke.

Hm, to mas pravdu, neni to hezke. Ja osobne bych dal prednost tomu, aby se proste NaN choval jako -INF pro porovnani, a zachovalo se tak uplne usporadani "realnych" cisel. Porovnani NULL by se melo interpretovat jako porovnani dvou hodnot Maybe typu, tedy jako alternativy mez null a jinou hodnotou.

[xkucf03]

BTW: neexistuje v nějakém jazyce něco jako výchozí null metody? Tzn. něco jako statické metody definované na třídě/typu, které by se volaly ve chvíli, kdy se někdo pokusí volat metodu na null proměnné. Takže by šlo napsat:

String s = null;
int l = s.length();

a místo toho, aby to spadlo na NPE, by to nastavilo l = 0, protože ve třídě String by bylo definováno, že chybějící String má délku 0 znaků.

Ale ono je to asi blbost, protože tady dost záleží na kontextu a operaci, jakou nad těmi hodnotami chci dělat. Tzn. to chování je součást definice té operace nikoli třídy/typu. Např. když budu počítat průměr, tak si tuhle operaci můžu definovat tak, že chybějící/neznámé (null) hodnoty vynechám a spočítám průměr z těch známých. Zatímco jiná operace může v případě byť jediné null hodnoty vyhodit výjimku, protože nedává smysl. Případně by výstupem mohl být nějaký složený typ, který by kromě té hodnoty (např. průměru) říkal i něco o jistotě a pravděpodobnosti dané agregované hodnoty (např. průměr ze sto hodnot, kde jen dvě jsou null, by byl dost pravděpodobný, zatímco průměr ze sto hodnot, kde známých je jen pár by byl vysoce nepravděpodobný/nejistý).

[kralyk z abclinuxu]

BTW: neexistuje v nějakém jazyce něco jako výchozí null metody? Tzn. něco jako statické metody definované na třídě/typu, které by se volaly ve chvíli, kdy se někdo pokusí volat metodu na null proměnné. Takže by šlo napsat:

String s = null;
int l = s.length();

a místo toho, aby to spadlo na NPE, by to nastavilo l = 0, protože ve třídě String by bylo definováno, že chybějící String má délku 0 znaků.

Ale ono je to asi blbost, protože tady dost záleží na kontextu a operaci, jakou nad těmi hodnotami chci dělat.

Přesně tak. A proto se na tohle ve funkcionálních (a příbuzných) jazycích naprosto běžně používá mapování, monadické operace atd., přičemž ta operace není nijak svázána s nějakou třídou, definuješ si ad-hoc, jaký chceš mít ten default. (Případně pokud bys ho ctěl sdílet/exportovat, na to jsou zase jiné postupy.)

Tady máš příklad v Rustu a v Haskellu. (Podotákám, že Haskell moc neumim, tak to asi není zapsáno tak elegantně, jak by to zapsal skutečný Haskellista.)

[kralyk z abclinuxu]

Jo a kdyby ti přišlo neelegantní, že to není metoda na tom stringu, tak to se dá udělat taky, viz tady.

V Haskellu by se to udělalo podobně, akorát se tam tomu říká typeclasses (a je to o něco mocnější koncept). Kdyby se někomu chtělo to pro ukázku napsat, tak nebudu proti, bych se třeba taky něco přiučil

[xkucf03]

Ja asi nesouhlasim s touhle interpretaci. Prijde mi to matematicky neelegantni, narozdil od toho Optional (nebo Maybe).

„Matematicky neelegantní“ to možná je, ale víc to odpovídá realitě. Chybějící nebo neznámá hodnota není nějaká jedna konkrétní hodnota, se kterou by se dalo počítat, ale značí, že tam může být cokoli, kladné číslo, záporné číslo, nula, nevíme. Může to značit jakýsi nesoulad počítačového systému (který má modelovat realitu) s realitou jako takovou – ta modelovaná entita má nějakou vlastnost, ale my ji akorát neznáme, nebo někdo tu hodnotu zapomněl zadat do systému, nebo se někde cestou ztratila, nebo nám ji někdo nechce říct.

Bez ohledu na to, jestli si to v programovacím jazyce popisuješ jako Optional nebo třeba ukazatel ukazující do nikam, tak se nad tím těžko definují nějaké operace. U některých agregací můžeš tyto neznámé hodnoty přeskočit a říct si, že ti to stačí přibližně. Lepší by bylo si k výsledku poznamenat i ten údaj o pravděpodobnosti/nepravděpodobnosti.

V podstatě jediné zcela správné a přesné řešení je, že výsledkem je zase null, aneb neznámá hodnota. Cokoli jiného je vlastně kompromisem mezi přesností a snahou získat alespoň nějaké (přibližné) výsledky v případě nekompletního vstupu.

[kralyk z abclinuxu]

Bez ohledu na to, jestli si to v programovacím jazyce popisuješ jako Optional nebo třeba ukazatel ukazující do nikam, tak se nad tím těžko definují nějaké operace. U některých agregací můžeš tyto neznámé hodnoty přeskočit a říct si, že ti to stačí přibližně. Lepší by bylo si k výsledku poznamenat i ten údaj o pravděpodobnosti/nepravděpodobnosti.

V podstatě jediné zcela správné a přesné řešení je, že výsledkem je zase null, aneb neznámá hodnota.

No takže víceméně konverguješ k těm monádám. Myslimže bys opravdu udělal lépe, kdyby ses na nějaký to funkcionální programování podíval, jak už ti radil JS1, protože v tomhle komentáři i v tom výše se zřejmě snažíš vymyslet věci, které už jsou dobře popsané, objevené.

[deda.jabko]

Ja asi nesouhlasim s touhle interpretaci. Prijde mi to matematicky neelegantni, narozdil od toho Optional (nebo Maybe).

Taky je null inzenyrske nikoliv matematicke reseni.

Chovani, ktere odpovida tomu "absence hodnoty" pak muzes snadno dostat z Maybe monady, ale naopak mi to prijde slozitejsi.

V tomto miste nejsme ve sporu.

To bys musel pak vsechny hodnoty zasunout do nejake implicitni monady, ktera by byla schopna tu situaci rozeznat (coz vlastne dela ta Java tim, ze vyhazuje NPE).

Nebo se na to divat tak, ze null je instrument stojici u vetsiny realne pouzivanych jazyku mimo typovy system.

Hm, to mas pravdu, neni to hezke. Ja osobne bych dal prednost tomu, aby se proste NaN choval jako -INF pro porovnani, a zachovalo se tak uplne usporadani "realnych" cisel.

To ti pak rozbije dalsi veci, v takovem pripade by pak 0/0 = +INF/+INF = -INF/+INF = -INF + INF = INF - INF = -INF.

Coz taky neni zrovna hezke reseni.

Pokud se ale na NaN divas jako na priznak absence/nedefinovatelnosti hodnoty, tak to chovani je konzistentni.

[JS1]

Tak zavest si null primo do cisla (NaN) nebo retezce ("") mi pripada spis pragmaticke z hlediska ukladani te hodnoty a jednoduchosti zpracovani. Z tohoto pohledu povazuji za optimalni, aby to (mylne) zpracovani tech null nenadelalo zbytecnou skodu. Tj. nakonec nekdo stejne prijde, uvidi NaN a rekne si, hm, to nedava smysl.

[deda.jabko]

Tak zavest si null primo do cisla (NaN) nebo retezce ("")

Brzdi. Prazdny retezec neni nedefinovana/neznama hodnota. Prazdny retezec je validni hodnota, pro kterou jsou konzistentne definovane ostatni operace. To je v principu stejna chyba, jako kdybys prazdnou mnozinu (z nejakeho duvodu) nepovazal za mnozinu.

Z tohoto pohledu povazuji za optimalni, aby to (mylne) zpracovani tech null nenadelalo zbytecnou skodu.

V tom pripade ale NaN jako priznak absence hodnoty dava vetsi smysl nez, kdyby to byla hodnota jako kazda jina.

[JS1]

No mozna se na to prave divam z toho statistickeho hlediska, tj. ja vidim jako neznamou hodnotu to, co neobsahuje zadnou informaci. Takze NaN neberu jako priznak toho, ze nejaka operace selhala, ale jako priznak toho, ze ta hodnota proste nebyla zadana.

Ale stale tu hodnotu chci povazovat za clena toho typu.

Duvod, proc jsem OK s tim, aby se ty nedefinovane hodnoty chovaly jinak u cisel nez u retezcu, je pak v tom, ze cisla a retezce se chovaji jinak z hlediska informace, kterou obdrzim.

Vezmi si, ze mam funkci, ktera neco dela s cislem. Pokud zadam NaN, mel bych dostat zase NaN, protoze pokud dostanu zpet cislo, pak jsem dostal vic informace na vystupu nez na vstupu. (Jiny priklad je pokud mam funkci, ktera pracuje s kladnymi integery, a ta vraci -1 pokud doslo k chybe. Tam se to -1 bere implicitne jako null.) Pokud mam ale funkci na retezci, treba prijmeni, tak ten program typicky nevytvori uplne nove prijmeni. Pokud neco dela, tak to treba pripoji k tomu retezci, pripadne ho nejak zpracuje, a typicky dostanu neco, z ceho je zase zrejme, ze to neobsahuje zadnou informaci.

To co chci asi zduraznit je, ze to "nedostal jsem zadnou informaci" se lisi podle typu. Dokonce si myslim, ze na souctove typy to ani nejde definovat. A proto to nemuze byt obecna hodnota pro kazdy typ (at uz je soucasti typu nebo ne), ale muze byt (a je prakticke), aby byla uzusem stanovena pro konkretni typy.

Samozrejme teoreticky korektne bychom tohle resili pres prave to Maybe, ale z praktickych duvodu to tak nedefinujeme, protoze by nam to casto vyslo jako jeden prebytecny bit navic. (Jelikoz typy v programovani historicky slouzily predevsim k urceni zpusobu ulozeni dat.)

[deda.jabko]

No mozna se na to prave divam z toho statistickeho hlediska, tj. ja vidim jako neznamou hodnotu to, co neobsahuje zadnou informaci.

Toto je velmi spatny pohled. NULL/Nil/NaN/etc. byly zavedeny pro situace, kdy je hodnota nedefinovana nebo neznama (s timto rozlisenim to zacina byt jeste zasmodrchanejsi). V momente, kdy to zacnes chapat jako hodnotu, ktera nenese informaci, pridelavas si jeste vic problemu. Typicky scenar (predpokladam, ze neznama hodnota, co nenese informaci u retezce, je prazdny retezec):

Map<String, String> map = new HashMap<>();
map.put("foo", "");
map.get("foo") -> // ""
map.get("bar") -> // ""

Jinymi slovy nejsi s to rozlisit, jestli se jedna o skutecnou hodnotu (prazdny retezec) nebo nedefinovanou hodnotu.

Vezmi si, ze mam funkci, ktera neco dela s cislem. Pokud zadam NaN, mel bych dostat zase NaN, protoze pokud dostanu zpet cislo, pak jsem dostal vic informace na vystupu nez na vstupu. (Jiny priklad je pokud mam funkci, ktera pracuje s kladnymi integery, a ta vraci -1 pokud doslo k chybe. Tam se to -1 bere implicitne jako null.)

Toto jsou ad hoc reseni problemu, ktere vzniknou, pokud je operace pro nektere hodnoty nedefinovana. V matematice se to resi proste, ze reknes, ze vysledek neni definovan. Pocitac si takto rict nemuze a musi to nejak resit. Reseni s NaN nebo -1 je technicky rozsireni mnoziny hodnot o dalsi prvek, ktery signalizuje neplatnost operace. Maybe je pak systematicke reseni, ktere umoznuje rozsirit libovolnou mnozinu hodnot o takovy prvek.

[JS1]

Ale v tom tvem pripade vysledek te funkce get() nese informaci, jaky byl spravny retezec. Navratovy typ by pak melo byt Optional<String>. Z hlediska te funkce get() je spravne to, co je ve slovniku, prave proto, ze ja chapu nedefinovanou hodnotu nikoli univerzalne, ale jako zavislou na konkretnim typu.

Takze ta nedefinovana hodnota muze slouzit jako identifikator chyby, ale nemusi, zalezi na kontextu.

Je to podobne jako kdyz pujdes na urad a na formular nenapises svoje jmeno. Taky si nebudou myslet, ze tvoje jmeno je prazdny retezec, ale pochopi, ze je to chybejici informace. Tak se na to divam.

[JS1]

Jinak receno, neni to vlastnost toho retezce, ze neni v tom slovniku pod tim klicem (pokud uz neceho, je to vlastnost toho slovniku).

[Josef Kufner]

Je to podobne jako kdyz pujdes na urad a na formular nenapises svoje jmeno. Taky si nebudou myslet, ze tvoje jmeno je prazdny retezec, ale pochopi, ze je to chybejici informace. Tak se na to divam.

Ale to jen kvůli tomu, že neumíš napsat prázdný řetězec.

[JS1]

Ja ale nechci! Kdybych umel do formulare napsat null, jeste mi urednice spadne na NPE.

Ale vazne - o tom to tak nejak je. Pokud do vstupu programu zadam prazdny retezec (nebo NaN), casto tim rikam, tohle je prazdna hodnota, ale nechci aby to ten program resil, ze je prazdna, a nekde mi nepredlozene spadl na NPE.

[xkucf03]

Programy ale běžně řeší obsah hodnot, ostatně často je to jejich práce a důvod, proč se používají – nejsou to pouhé přeposílače netransparentních (opaque) hodnot. Program se běžně podívá dovnitř a řekne ti třeba, že řetězec je moc dlouhý, číslo moc velké nebo nečekaně záporné, hodnota neodpovídá číselníku nebo jde o již nepodporovanou hodnotu z výčtu, která tam je jen kvůli starým záznamům, ale nové se s ní už zakládat nemají, nebo ti program řekne, že kombinace hodnot/parametrů nedává smysl (přestože jednotlivé hodnoty samy o sobě jsou OK).

[JS1]

Z tveho prispevku neni jasne, jake tvrzeni se snazis argumentovat. Ne vsechny programy to resi, treba statistickemu programu nijak nevadi, pokud mas data plna NaNu.

[xkucf03]

Z tveho prispevku neni jasne, jake tvrzeni se snazis argumentovat.

Byla to reakce na tu tvoji poslední větu:

Pokud do vstupu programu zadam prazdny retezec (nebo NaN), casto tim rikam, tohle je prazdna hodnota, ale nechci aby to ten program resil, ze je prazdna, a nekde mi nepredlozene spadl na NPE.

Když program data jen přeposílá někam dál, tak může ty nestandardní/chybné/chybějící hodnoty prostě ignorovat a poslat to dál, tak jak to je. Ale pokud program má na základě těch dat něco počítat nebo rozhodovat, tak se k tomu musí nějak postavit a je potřeba tam implementovat nějakou logiku, co s těmito hodnotami.

Ne vsechny programy to resi, treba statistickemu programu nijak nevadi, pokud mas data plna NaNu.

Tak zrovna tady mi to docela důležité přijde. Protože když budu mít nějaký agregovaný výsledek vypočtený z dat, kde půlka hodnot chyběla (někdo nám je nechtěl poskytnout, došlo k chybě měření atd.), tak to má úplně jinou váhu než výpočet z dat, která jsou přesná a úplná. O tom jsem psal už v #124, že má smysl sledovat i tu pravděpodobnost či míru pravdivosti agregovaného výsledku.

Jestli kódovat příznak null do nějakého bitu uvnitř hodnoty nebo si ho udržovat někde bokem, je otázka. Z hlediska složitosti a čistoty návrhu je to asi v podstatě jedno.¹ Stejně nakonec někde musí být nějaký ten IF, kterým se ty speciální případy ošetří.² Čistější mi přijde mít ten příznak bokem (ať už jako ukazatel do nikam nebo prázdný Optional, nebo bit v DB tabulce, ať už jako součást pole atributu nebo vedle něj atd.), protože to funguje jako obecný princip, který funguje pro všechny datové typy stejně, je to generické, univerzální – když budu zjišťovat, zda chybí textový řetězec, použiji k tomu stejný mechanismus, jako když bubu zjišťovat, zda chybí číselná hodnota. Na druhou stranu ale nepůjdu stávkovat nebo držet hladovku kvůli tomu, že existují i typy, které ten null kódují dovnitř hodnoty. Nemám s tím zásadní problém.

_{[1] Spíše jde o tu praktickou stránku, jestli raději obětujeme jeden bit uvnitř hodnoty, nebo přidáme nějaký příznak vedle.
[2] v případě toho IEEE 754 může někdy zafungovat ta magie zadrátovaná do toho typu, ale obecně bych nespoléhal na to, že automaticky fungovat tak, jak v dané aplikaci zrovna potřebuji}

[kralyk z abclinuxu]

Ale v tom tvem pripade vysledek te funkce get() nese informaci, jaky byl spravny retezec. Navratovy typ by pak melo byt Optional<String>. Z hlediska te funkce get() je spravne to, co je ve slovniku, prave proto, ze ja chapu nedefinovanou hodnotu nikoli univerzalne, ale jako zavislou na konkretnim typu.

No, běžně to je tak, že Maybe / Option / Optional / nullable reference je efektivně supertyp obalovaného typu. Což má za následek tu dychotomii, když ten obalovaný typ už má něco jako prázdnou hodnotu ve své množině hodnot.

Oproti tomu ty bys asi raději, aby ty typy měly nějakou asociovanou triviální hodnotu, něco jako je neutrální prvek v grupě...

[xkucf03]

Pak je ale řada případů, kdy je hodnota povinná, a pak je jakákoli forma neznámých hodnot zabudovaná do typu samotného na škodu. Např. těžko v hlavičce metody řekneš, že chceš IEEE 754 desetinné číslo, ale bez NaN a +/- nekonečna, když tvůj jazyk má jako datový typ jen IEEE 754 a neumí ho ani nijak zúžit (třeba anotacemi).

Trochu lépe to mají řešení některé relační databáze, kde si můžeš definovat vlastní doménu (podmnožinu nějakého typu).

Co se týče těch neznámých hodnot, mně přijde lepší je mít mimo samotný typ, ať už jako null nebo Optional. Ono to null sice samo o sobě není typem ani typ nemá, ale my o tu informaci o typu stejně nepřijdeme, protože typ má proměnná, ve které ta hodnota chybí. A i když bude metoda přetížená, tak to stejně vleze do té správné metody a předá se null do ní. Alespoň tedy ve staticky typovaných jazycích. I když teoreticky můžeme mít nějaké pole/kolekci obecných objektů a v nich nějaký ten null – pak víme, že něco chybí, ale nevíme, jakého typu to chybí… ale to už je trochu přitažené za vlasy. Každopádně se to dá řešit obalením těch objektů do něčeho, co kromě hodnoty ponese i informaci o typu.

[kralyk z abclinuxu]

Pak je ale řada případů, kdy je hodnota povinná, a pak je jakákoli forma neznámých hodnot zabudovaná do typu samotného na škodu. Např. těžko v hlavičce metody řekneš, že chceš IEEE 754 desetinné číslo, ale bez NaN a +/- nekonečna, když tvůj jazyk má jako datový typ jen IEEE 754 a neumí ho ani nijak zúžit (třeba anotacemi).

To je IMO ortogonální existenci neutrální hodnoty, to je prostě validace vstupních dat. Některé metody nesnesou NaN, některé nesnesou záporná čísla, některé nesnesou čísla mimo rozsah (0; 1] a podobně.

Případně některé jazyky mají typ, od kterého nemůže existovat hodnota. Wikipedia tvrdí, že se to jmenuje Bottom type, já to znám jako never type (Rust, TypeScript). Je to specielní typ, od kterého fakt nemůžeš vytvořit hodnotu ani když se o to pokusíš - cesta kódem, která by vedla k vytvoření takové hodnoty, není validní. Příklad použití je návratová hodnota funkce exit() a taky právě jako typ pro situace, kdy nechceš, aby nějaký generický typ efektivně existoval.

Co se týče těch neznámých hodnot, mně přijde lepší je mít mimo samotný typ, ať už jako null nebo Optional.

To se nevylučuje. Dokonce se to může i spojit... V Rustu například typ Optional<NonZeroI32> odpovídá co do reprezentace typu i32. Akorát se v každém tom případě člověk jinak chová k nule.

Používá to třeba kompilátor k tomu, aby např. typ Optional<&Foobar>> (tj. optional reference na Foobar) vevnitř reprezentoval pomocí jednoho pointeru (bez přidaného flagu), protože reference nemůže být null pointer. IIRC ale jinak tohle není moc často používané...

Ono to null sice samo o sobě není typem ani typ nemá

Nóó... V kontextu Javy null literál implicitně konvertuje na pointer daného typu (podle kontextu), takže efektivně IMO typ má... Může toho být zneužito k prolomení typového systému v Javě, podrobnosti tady (což nemá být kritika Javy, takové věci se afaik stávaji jazykům celkem běžně).

[JS1]

Presne tak. V typovem systemu muzeme mit typ A, Optional[A], Optional[Optional[A]], atd.

To co ja rikam je, ze treba double je efektivne typu SpecialniOptional[skutecny_float], tedy skutecne realne cislo nebo NaN (ve skutecnosti je to slozitejsi, jsou tam nekonecna, ale pro ucely teto diskuse). Takze, slovnik, ktery uklada double, uz uklada v nejake forme Optional typ, ale funkce get() ho obali jeste dalsi urovni Optional. Pro ucely prakticnosti jsme operace s tim skutecnym_floatem rozsirili na operace i nad temi specialnimi hodnotami; je to analogicke u toho prikladu s get() treba slovniku s defaultni hodnotou, ten to Optional proste skryva.

No a pro retezce z lidskeho hlediska je to podobne. Taky je muzeme brat jako Optional[retezec_nenulove_delky]. Svym zpusobem je to pro lidi takto prirozene, vsimni si, jak dlouho to lidem trvalo, nez pochopili koncept nuly. Jako lide proste vnimame "nic" jako specialni pripad a nikoli soucast samotneho typu. (A proto mimochodem argumentuji, ze bychom meli i u celych cisel mit hodnotu typu NaN, konkretne treba 0x80000000, podle bitove sirky.)

Ale je duvod (a to je odpoved Frantovi), proc v praxi v programovacich jazycich nezavadime, aby kazdy retezec nebo cislo bylo Optional[neco], ackoliv je to vlastne to, co chceme. Ten duvod je hlavne historicky, ale i dnes, definovat to takto granularne by u drtive vetsiny systemu znamenalo, ze bychom ukladali k dane hodnote minimalne jeden bit navic. A to je velmi neprakticke, protoze my opravdu chceme jen nekam vtesnat jednu dalsi moznou hodnotu, ktera navic typicky nenastava. (Samozrejme, mozna ze v budoucnosti nekdo navrhne jazyk, ktery to bude schopen pochopit, a pak budeme moci konecne float definovat skutecne jako Optional[cosi], a kompilator nam to pak korektne ulozi jako IEEE754 double.)

[Josef Kufner]

Takze, slovnik, ktery uklada double, uz uklada v nejake forme Optional typ, ale funkce get() ho obali jeste dalsi urovni Optional.

To záleží na překladači, jak se s tím vypořádá a jak to optimalizuje. V některých případech to obalení může úplně zmizet, v jiných se bude přistupovat přes pointer a ten to pořeší. To Optional je čistě formální záležitost, která v první řadě má vyjádřit záměr programátora a zajistit bezchybný kód (v rámci možností).

[JS1]

S tim bych souhlasil, to druhe Optional muze zmizet. A jak pisu dal, samozrejme by mohlo zmizet i to prvni Optional, ktere je inherentni treba v tom IEEE754 doublu (treba z programu nejak vyplyva, ze nikdy nedeli nulou). Ale jednak to zalezi na konkretnim programu a druhak neznam kompilator, ktery by to druhe dokazal.

[Josef Kufner]

Optional se může rozpustit do struktury kódu, který s takovou volitelnou hodnotou pracuje. V takových případech nepotřebuješ reprezentovat null, ani ho schovat do nějaké hodnoty dané proměnné (to opravdu překladače moc neumí). Překladači pak stačí vědět, že to či ono už nemůže nastat a v ten okamžik může optimalizovat a zjednodušovat. Samozřejmě to není obecný případ, ta informace tam někde musí být, ale může být relativně daleko od té volitelné hodnoty.

[deda.jabko]

Navratovy typ by pak melo byt Optional<String>

Tak uz se rozhodni, jestli prazdny retezec nese, nebo nenese informaci.

Navratovy typ by pak melo byt Optional<String>.

Spravne, prave jsi efektivne rozsiril mnozinu hodnot typu retezec o dalsi hodnotu, ktera neni z dane mnoziny hodnot a slouzi k indikaci, ze se nejedna definovanou hodnotu.

Je to podobne jako kdyz pujdes na urad a na formular nenapises svoje jmeno. Taky si nebudou myslet, ze tvoje jmeno je prazdny retezec, ale pochopi, ze je to chybejici informace.

To je stejny pripad, jak s tou matematikou, kdy si clovek rekne, to je nedefinovana/neznama hodnota.

... prave proto, ze ja chapu nedefinovanou hodnotu nikoli univerzalne, ale jako zavislou na konkretnim typu.

To ale celou vec zbytecne komplikuje.

Takze ta nedefinovana hodnota muze slouzit jako identifikator chyby, ale nemusi, zalezi na kontextu.

V momente, kdy to budes vnimat jako priznak absence hodnoty, nemusis resit kontext a veci se zjednodusi.

Tato cela diskuze mi prijde takova trosku mimobezna, trochu jako s xkucf o politice. Jestli te spravne chapu, ty se snazis popsat "idealni" svet, jak by to melo vypadat, zatim co ja, jak to realne funguje. V takovem pripade, ale nemuzeme prirozene dojit k nejakemu kloudnemu vysledku.

[JS1]

Tak uz se rozhodni, jestli prazdny retezec nese, nebo nenese informaci.

Prazdny retezec ji nenese, to co nese informaci (a proc get() vraci Optional) je ten slovnik.

Spravne, prave jsi efektivne rozsiril mnozinu hodnot typu retezec o dalsi hodnotu, ktera neni z dane mnoziny hodnot a slouzi k indikaci, ze se nejedna definovanou hodnotu. [..] To je stejny pripad, jak s tou matematikou, kdy si clovek rekne, to je nedefinovana/neznama hodnota. [..]

Na tohle odpovim Kralykovi.

To ale celou vec zbytecne komplikuje. [..] V momente, kdy to budes vnimat jako priznak absence hodnoty, nemusis resit kontext a veci se zjednodusi.

Naopak, zpracovani se tim nekdy zjednodusi, protoze pocitac v danem kontextu "nevi", ze ta hodnota je ve skutecnoti neznama, a zbytecne mi nepada na NPE (viz odpoved Josefovi).

[Josef Kufner]

Vlastnosti Null závisí hodně na interpretaci s jakou se pracuje. Hezky je to vidět v porovnání Łukasiewicz a Kleene logik, kde Kleene definuje implikaci Null ⇒ Null jako Null, kdežto Łukasiewicz ji definuje jako True. V důsledku Kleene logika nemá tautologie, kdežto Łukasiewicz logika definuje ekvivalenci Null = Null. Takže sice tautologie máme a matematika funguje, avšak pokud máme dány proměnné a = Null a b = Null, tak to implikuje, že a = Null = Null = b, tedy že a = b. Pokud však intepretujeme Null jako chybějící hodnotu, tak to zavádí vztah, který není platný. Tolik k trojhodnotové logice.

Lepší řešení je použít množiny. Pak můžeme říct, že a ∈ {True, False} a b ∈ {True, False}, tedy že a a b jsou buď True nebo False, ale nevíme které z těch dvou. Tady žádný vztah mezi a a b nevzniká. Pak už jen stačí prohlásit množinu za typ typového systému a dostaneme Maybe (formální detaily ponechme stranou, s teorií kategorií to komplikovat nebudeme).

Z praktického inženýrského hlediska je však mnohem snažší použít Null a podle kontextu mu definovat ty správné vlastnosti.

[JS1]

V logice nejsem zase tak zdatny, ale prijde mi, ze typovy ekvivalent te Kleene interpretace (chybejici hodnoty) null je prazdny typ, coz je treba v Haskellu undefined. Ale v moji interpretaci null skutecne je hodnota.

Epistemologicky, pro me jsou dva elektrony (bez specifikace polohy a rychlosti) totozne, protoze maji stejne vsechny atributy. Abych je mohl povazovat za ruzne, musim jim priradit nejaky dalsi rozlisujici identifikator, treba prvni elektron a druhy elektron.

[kralyk z abclinuxu]

Dá se to řešit přes Optional nebo přes kolekce/posloupnosti, které můžou být prázdné… ale jestli je to výrazně lepší než null, je sporné.

Optional začne dávat mnohem větší smysl ve chvíli, kdy můžeš trochu více pracovat s hodnotovými typy. Např. si představ, jak bys v Javě vyjádřil volitelnou položku typu int (tj. hodnotový typ, nikoli Integer). Opověď je, že bez Optional těžko, protože int není reference, a nemůže tedy být null. Musel bys leda ten Optional emulovat tím, že bys vedle toho intu měl ještě nějakej bool flag, ale to je ošklivé (nezapouzdřené).

Primární smysl Optionl-like typů je právě pro použití s hodnotovými typy. Pro nullable pointery (tj. např. javovské reference) to samozřejmě dává smysl pramalý.

Jednoho krásného dne bych rád postavil autory Javy před soud za deformaci myšlení lidí.

[Josef Kufner]

Optional implementovaný typovým systémem je k dispozici jen ve zdrojovém kódu a kompilací se převede na uspořádání instrukcí, případně na nějakou skrytou interní reprezentaci, o kterou se nestaráš. Jakmile data serializuješ, tak Optional nemáš vůbec a potřebuješ null jako hodnotu.

[JS1]

Zase, tohle je diskuse o tom, do jake miry chces skutecne modelovat data (treba pomoci typu), a do jake miry ne. Zalezi na situaci.

Jsou situace, treba statisticka analyza (obecne vystup dat ze systemu), kdy si skutecne vystacis se dvema typy - cislo a retezec, pricemz oba maji uz null v sobe (floating pointy maji NaN a prazdny retezec se bere jako null).

No a pak jsou jine situace, treba prave konfigurace (obecne vstup dat do systemu), kde se hodi byt vic explicitni, kvuli kontrole.

Predstava, ze tyto ruzne use cases vyresi nejaky jednotny format je IMHO mylna.

[JS1]

Ono je to s tim "je to text, da se to precist kdekoli" dost fikce. Stare Unixy by dnes textove soubory nezvladaly, protoze se pouziva Unicode. Ja mam treba problem precist Kamenickych texty, co mam jeste nekde v pocitaci. O EBCDICu ani nemluve. Vsechno je nejake kodovani a je potreba standardni nastroj.

[xkucf03]

Stare Unixy by dnes textove soubory nezvladaly, protoze se pouziva Unicode.

Nástroj iconv je součást standardního API. A portovat do starých systémů současný iconv s podporou „nových“ kódování jako je UTF-8 by neměl být problém (spíš bych čekal, že to už dávno někdo udělal).

Ja mam treba problem precist Kamenickych texty, co mam jeste nekde v pocitaci.

Zkus nástroj enconv.

[johnyK]

ja proste musim k tomu velkemu povidani o tom XML, ktere tady vzniklo jeste pridat ten znamy vtip:

programator stoji pred problemem a rozhodne se ho resit za pomoci XML.

Nasledne ma 2 problemy.

Jinak my mame bohuzel hodne co cinit s Amazonem a minimalne 2 x za rok panove neco zmeni na tech jejich XML strukturach a vsichni uzivatele zacnou programy predelavat.

[xkucf03]

Jinak my mame bohuzel hodne co cinit s Amazonem a minimalne 2 x za rok panove neco zmeni na tech jejich XML strukturach a vsichni uzivatele zacnou programy predelavat.

Za což samozřejmě může XML :-D

[johnyK]

no, ja presne nevim ?

Sam se primo s temi problemy nezabyvam, ale od kolegu vim, ze se stane napr. nasledujici: Amazon uverejni XML interface pro objednavku. Nekde v tom stromu se naleza tedy <order> a o uroven nize pak ty atributy te objednavky jako

<order-id><12345>

<name1><John> atd.

a cele je to pak uzavreno

</order>

V programu se ten predany XML soubor nacte do nejake hashe (perl, php ... parsrem, ktery v tom kterem interpretru prave existuje) a udaje se zpracovavaji. Programator na zaklade informaci od Amazonu predpoklada, ze <order>...</order> se bude vyskytovat v souboru jen jednou.

Po nejake dobe Amazon zjisti, ze je dobre zaslat VICE objednavek najednou. XML se opet nacte do hashe a pri pokusu o precteni atributu objednavky to spadne, protoze se v te hashi najednou nachazi array of orders. Samozrejme , ze by na to mel programator pamatovat, a pri jakemkoliv pristupu k nejakym datum zkontrolovat, jestli pristupuje k hashi, array a nebo i jinak strukturovanym datum. To by byl idealni stav, jenom neznam nikoho kdo by to tak delal. A i kdyby, tak vsechny ty mozne alternativy musi pak program zohlednit a navic taky musi programatora VSECHNY mozne alternativy napadnout.

Ja se priznam, ze v tom XML nejsem tak kovany, ja mam celkem dost starosti abych zvladnul i ty jine problemy u zakaznika a u te interface bych rad, kdyby ta data priletela v nejake forme, na kterou se mohu spolehnout. Jestlize se to prani da zaridit jen tak, ze si musim zapsat 2 semestry na uni, tak pak to pro mne neni tak privetive.

[Josef Kufner]

Když to API budeš používat kultivovaně, tak se to zkontroluje samo – viz Using Symfony Serializer to consume REST APIs in OOP way.

[xkucf03]

Normální postup je takový, že dostaneš XML schéma (XSD) a z něj si vygeneruješ třídy. Např. v Javě se k tomu používá JAXB. A protože v XSD je napsáno, kolikrát se který element smí opakovat, generátor ví, jestli má v té třídě vygenerovat kolekci (pole) nebo jeden objekt.

I kdybys to psal ručně, tak bys měl vycházet z toho schématu (specifikace) a ne to programovat jen na základě nějakých příkladů (ukázek dat), protože to vede přesně na takové chyby, jako se vám staly.

Tohle platí obecně pro jakýkoli formát nebo protokol, není to nic specifického pro XML (jestli vyvíjíš tímto stylem, tak budeš mít problémy i s jinými formáty, ať už textovými nebo binárními, či protokoly).

[kralyk z abclinuxu]

Tohle platí obecně pro jakýkoli formát nebo protokol, není to nic specifického pro XML (jestli vyvíjíš tímto stylem, tak budeš mít problémy i s jinými formáty, ať už textovými nebo binárními, či protokoly).

Njn, z toho důvodu by se mi třeba nechtělo psát XML schéma mj. proto, že tím mám efektivně lock-in do XML. (Nevim, jestli se dají XML schématem validovat jiný formáty, ale počítám, že buď ne nebo tam budou gotchas.)

[kralyk z abclinuxu]

Akorát teda alternativy moc nejsou nebo nejsou lepší (json schema) nebo jsou příliš mladé (dhall).

[xkucf03]

Njn, z toho důvodu by se mi třeba nechtělo psát XML schéma

Nechtělo? To to radši napíšeš vedle na papír a nedáš druhé straně strojově čitelnou specifikaci? Ať si to z toho papíru opíší a ručně implementují?

Ze stejného důvodu taky můžeš nechtít používat počítač a dělat radši všechno ručně, abys neměl závislost na počítači.

Nevim, jestli se dají XML schématem validovat jiný formáty

V zásadě můžeš, v alt2xml mám např. ukázku validace .properties souboru pomocí XSD. Stejně tak můžeš validovat INI nebo JSON soubory pomocí XSD. Případně libovolný jiný formát (je to modulární a dá se do toho podpora snadno dopsat). V tom příkladu se pro validaci používá xmllint, ale alt2xml můžeš použít místo XML SAX parseru a validovat to přímo v Javě (v rámci téhož procesu, nikde se z toho proud bajtů/textu se špičatými závorkami negeneruje – ani v paměti).

Nebo, jestli chceš nějaké zralejší řešení, tak je tu ASN.1, což je přesně to, po čem se ptáš – abstraktní notace, kterou popíšeš model/schéma a je nezávislá na konkrétní serializaci/kódování tohoto modelu do posloupnosti bajtů. Těch dostupných serializací/kódování je pak několik, jak binárních, tak textových.

[kralyk z abclinuxu]

Nechtělo? To to radši napíšeš vedle na papír a nedáš druhé straně strojově čitelnou specifikaci? Ať si to z toho papíru opíší a ručně implementují?

Nah. Řešim to proto, že používáme různé formáty na různé věci v několika jazycích. Není všude XML (popravdě nevim, jestli vůbec někde XML máme).

V zásadě můžeš, v alt2xml mám např. ukázku validace .properties souboru pomocí XSD. Stejně tak můžeš validovat INI nebo JSON soubory pomocí XSD. Případně libovolný jiný formát (je to modulární a dá se do toho podpora snadno dopsat). V tom příkladu se pro validaci používá xmllint, ale alt2xml můžeš použít místo XML SAX parseru a validovat to přímo v Javě (v rámci téhož procesu, nikde se z toho proud bajtů/textu se špičatými závorkami negeneruje – ani v paměti).

Nedělám Javu, takže tohle se mě netýká...

Nebo, jestli chceš nějaké zralejší řešení, tak je tu ASN.1, což je přesně to, po čem se ptáš – abstraktní notace, kterou popíšeš model/schéma a je nezávislá na konkrétní serializaci/kódování tohoto modelu do posloupnosti bajtů.

Jo, to by asi šlo, ačkoli o asn.1 moc nevim a hlavně vůec neznám tooling (tam bude možná problém).

Zajímalo by mě, jestli je možné použít dhall jen jako "schéma" (lépe řečeno spíše type checker) pro použití jiných formátů. Vim, že určitě umí exportovat data do všeho možnýho. Možná se jich na to zeptám...

[xkucf03]

Nedělám Javu, takže tohle se mě netýká...

Jde o obecný princip a jeho implementace je na pár řádků v libovolném jazyce. SAX parser máš všude a všude si můžeš napsat jeho vlastní implementaci tak, že bude číst libovolný formát (INI, YAML, JSON, .properties atd.) a bude emitovat SAX události. Na základě těch událostí se pak buď staví DOM nebo se zpracovávají proudově – a tohle všechno už je stejné jako u XML, tudíž tam můžeš používat existující XML knihovny a nástroje. Bez ohledu na programovací jazyk – tohle můžeš dělat kdekoli.

[xxx]

Meh. Kdyby ti Franta napsal, ze si mas nakreslit specifikaci protokolu v malovani, tak by to bylo to same. Kdyby ti napsal, ze mas mit tu specifikaci v EBNF, tak by znelo vic cool, ale porad by to bylo to same. Ale kdyz ti napsie, ze to mas pouzit ASN.1, tak je to porad to same... ale muzes to prodat do banky.

[xkucf03]

Řešení založené na ASN.1 bys prodal spíš do nějakého telekomu. Ale jinak mi není moc jasné, co se tím komentářem snažíš říct.

[deda.jabko]

Ale přitom podstata tvorby API by měla vycházet právě ze znalosti dané domény a logiky věci – to je to nejdůležitější. (ono se to dost překrývá s prací analytika, ale ten většinou na úroveň metod nejde)

Oddelovani role analytika a programatora je priserny mor (nejen) pri navrhu programovaciho rozhrani. Na jednu stranu programator nerozumi domene, na druhou stranu analytik nema potuchy, jak se s tim rozhranim bude pracovat.

A i tohle API (či SPI) se dá navrhnout špatně a nešikovně. Stejně jako ta gramatika.

Gramatika je taktez rozhrani, resp. jeho cast.

Jestli tu jsou nějací pamětníci, tak prosím o upřesnění či opravu, ale pokud vím, tak v 80. letech se těm gramatikám a překladačům dávala větší váha a lidé v tom viděli budoucnost a mělo to být něco, co se stane všudypřítomné a součást každodenní praxe programátorů.

Osmdesata leta nepamatuju, ale o tom, jak vypadaly tehdejsi predstavy o programovani, svedci jazyky ctvrte generace (4GL), ktere sice mely neco do sebe, ale v realu byly vytlaceny jazyky treti generace.

[xkucf03]

Oddelovani role analytika a programatora je priserny mor (nejen) pri navrhu programovaciho rozhrani. Na jednu stranu programator nerozumi domene, na druhou stranu analytik nema potuchy, jak se s tim rozhranim bude pracovat.

Ano, navíc ta režie spojená s tím, že se ti dva musí domluvit. Jasně, že je efektivnější, když si něco sám vymyslíš hned si to sám naprogramuješ. Ale kde chceš najít jednoho člověka, který umí oboje? A k tomu navíc i jednat s lidmi (zákazníky, ostatními dodavateli atd.)? Takových lidí je prostě málo.

[Bystroushaak]

Ano, navíc ta režie spojená s tím, že se ti dva musí domluvit. Jasně, že je efektivnější, když si něco sám vymyslíš hned si to sám naprogramuješ. Ale kde chceš najít jednoho člověka, který umí oboje? A k tomu navíc i jednat s lidmi (zákazníky, ostatními dodavateli atd.)? Takových lidí je prostě málo.

Osobně jsem dřív zastával podobnou pozici jako deda.jablko, ale od té doby co dělám ve větší korporaci (čtyři země, tisíce poboček), kde se potkává několik týmů (frontend, backend, middleware, desktopáři, databázisti a infráci) jsem si přestal dělat iluze, že by to bez architektů mohlo jít. Dohromady je to několik set lidí, do toho různé zákony, požadavky managementu a tak. Jsem rád, že ke mě se od architektů dostávají ty technické požadavky a nemusím do toho řešit zároveň ještě co si navymýšlí management. Navíc taky fungují jako fajn bariéra proti neustálým nesmyslným změnám co si management vymyslí, protože vyžadují dodržení nějakého schvalovacího procesu, takže lze garantovat, že máme (většinou) čas dodělat první věc, než se jde na druhou.

Na druhou stranu jsem ochotný uznat, že to neplatí plošně a určitě budou korporace, kde to nedává smysl.

[j]

Nevim jak ty, ale pokud by mi dodavatel tlacil nekoho, komu budu vysvetlovat co chci, s tim, ze on to pak prevypravi nekomu, kdo to nakodi, tak snim vyrazim dvere driv, nez stihne rict nashledanou.

Neexistuje lepsi zpusob jak dostat presne to, co se tu nekde kolem povaluje v podobe komixu s vyrobou houpacky. A doslova kralovsky se zrovna ted bavim tim, ze na my slova (jako vzdy) doslo a presne tohle se stalo. Zakaznik si objednal a dostal ... uplne neco jinyho nez chtel. Ted se s dodavatelem (po roce schuzovani a vyroby) dohaduje, jestli to co dodal je to co si objednal ...

[xkucf03]

Nevim jak ty, ale pokud by mi dodavatel tlacil nekoho, komu budu vysvetlovat co chci, s tim, ze on to pak prevypravi nekomu, kdo to nakodi, tak snim vyrazim dvere driv, nez stihne rict nashledanou.

Pokud dokážeš formulovat zadání tak, aby ho pochopil programátor a vytvořil podle něj to, co chceš, tak nepotřebuješ dodavatele, ale stačí ti personální agentura, ve které si koupíš programátory na určitou dobu, nebo, když je to dlouhodobější, tak si je seženeš sám a uzavřeš s nimi vlastní smlouvu.

Kupovat služby od dodavatelské firmy má smysl právě pro toho, kdo ty požadavky takto formulovat neumí a potřebuje pomoci i s tou analýzou a návrhem.

[j]

Takze si najmu programatora, a ten bude 10let zkoumat kod toho dodavatele, aby mi na nem proved hodinovou upravu? To se vyplati.

Vis mam tu takovou vec, ma to nejspis par stovek tisic radku kodu (a neni to opensource), ale ty zdrojaky jsou videt. A ja proste s dodavatelem komunikuju tak, ze pichnu do toho kodu a reknu, ze tady chci aby to delalo neco nejak. Upravu mam vetsinou hotovou do druhyho dne.

Jo jasne, v principu si to umim napsat sam, to snad kazdej admin ne? Ale jde o efektivitu, zatimco ja bych stravil tejden instalaci a pripravou nejakyho prostredi ve kterym to pak prekompiluju a zkoumanim syntaxe nejaky hruzy, tak on to udela za clovekohodinu k fakturaci. Tudiz mnohem levnejs.

---

A pro toho, kdo neumi neco zadat, to ma presne ten smysl co sem psal, jen neumim najit ten obrazek s tou houpackou. Zkus si predstavit, ze ti reknu, ze potrebuju neco, nevim vlastne co, co me nejak, nevim jak dopravi ... ke znamymu a jezdej na tom deti. To je cely tvoje zadani.

Ty nevis co chci, a des to tlumocit delnikovi, kterej netusi o cem sme se bavili.

Delnik vyrobi cojavim trikolku, ale ja chtel kolobezku. A vis proc? Protoze ten vul vejs netusi ze existuje trikolka a kolobezka, tak se samozrejme nemuze zeptat, jestli chci trikolku nebo kolobezku.

Navic tech prostredniku bude nejspis vic, takze nedostanu trikolku pro dospelyho, ale pro mimino, mozna i s tim, ze na riditkach bude mit primontovanou sesli, aby to mimino toho dospelyho mohlo vozit.

[Heron]

jen neumim najit ten obrazek s tou houpackou

Co bych pro tebe neudělal:

https://i.iinfo.cz/images/482/vyvoj-software-houpacka.png

A ještě česky:

https://media.loupak.cz/soubory/obrazky/_vlastni/3_2014/6c2e094698023fb998be74faf167cedc.jpg

Btw jsou to 2 z 4 prvních výsledků na Google v obrázcích na výraz "IT houpačka".

[xkucf03]

Já to znám právě z té druhé strany. Nechci sem vypisovat celé příběhy, ale stává se, že nějaký příliš aktivní admin u zákazníka upraví (dle svých slov: vylepší) program a nikomu o tom neřekne. A pak se zákazník diví, že jim po upgradu něco přestalo fungovat a začne obviňovat dodavatele, že jim to rozbil. Upgradem se přepsaly změny, o kterých nikdo nevěděl, a které šly mimo standardní proces.

Pak se z toho dotyční „poučí“ a svoje změny si ukládají bokem a po upgradu je zase aplikují. Ale pořád o tom nikomu neřeknou. A ty tam pak jako dodavatel přijdeš a dlouze zjišťuješ, proč se ta jejich instance chová divně a jsou v ní chyby, když u nás to fungovalo a prošlo všemi testy.

Třetí a už správnější postup je, že se jedná na rovinu, lidi si mezi sebou řeknou, co dělají, a netají to před druhou stranou. Tady si můžou sdílet svoje představy klidně i technickou formou, lze se odkazovat na zdrojáky a posílat si ukázky kódu. Nemusí to být jen nějaká abstraktní mluva byznysových analytiků… ale ani tady si tu spolupráci a zavádění změn nelze představovat takto jednoduše:

A ja proste s dodavatelem komunikuju tak, ze pichnu do toho kodu a reknu, ze tady chci aby to delalo neco nejak. Upravu mam vetsinou hotovou do druhyho dne.

Dodavatel má (měl by mít) nějakou koncepci a plán příštích verzí, má i nějakou rozpracovanou verzi, kterou zatím jako zákazník nevidíš. (primárně se tu budu bavit o softwaru, který se dodává více zákazníkům, ne o čistě zakázkovém vývoji na míru) Dodavatel má taky trochu jiné priority než zákazník resp. než jedntlivé osoby na straně zákazníka. Tyto osoby chtějí často jen vyřešit jeden konkrétní problém, mít to co nejrychleji/nejlevněji hotové, nevidí nic kolem a moc je nezajímá, co bude za rok za dva nebo jestli to bude fungovat i jinde než v jejich firmě/oddělení. Zatímco pro dodavatele je (mělo by být) důležité, aby ten software byl dlouhodobě udržovatelný a aby si zachoval svoji obecnost a flexibilitu a šlo ho dodávat do různých prostředí, různým zákazníkům; aby se nedělala krátkozraká rozhodnutí jen proto, že to řeší nějaký akutní problém a je to nejlevnější.

Takže ty sice můžeš navrhovat konkrétní technické změny, klidně i na úrovni kódu, ale nemůžeš se divit, když to dodavatel nakonec implementuje jinak. V konečném důsledku je to i v zájmu zákazníka, protože nekoncepční a krátkozraké změny by vedly k tomu, že dodavatel zkrachuje, ukončí či utlumí produkt nebo bude „jen“ pracovat neefektivně (a tedy pro zákazníka draze), protože bude mít problémy s údržbou nekvalitního kódu nebo s tím, že se mu produkt „rozjel“ do několika zákaznických verzí, které se od sebe postupem času liší víc a víc a vede to na duplikaci práce a chybovost.

A pak tu máme i obchodní stránku věci. Existují různé formy spolupráce. Někdo chce platit za čas vývojářů a do všeho vidět (pak se role dodavatele redukuje víceméně na personální agenturu), ale pak musí nést i riziko (např. že věci budou dražší a budou trvat déle, než se plánovalo). A někdo chce zase záruky a znát předem termín a cenu, alespoň v nějakém rozmezí. A k tomu různé další možnosti někde mezi tím. V pořádku jsou všechny varianty, na kterých se zúčastněné strany dobrovolně dohodnou. Ale nelze mít výhody obou přístupů, aniž bys měl i nevýhody (např. ta rizika). A tady jde právě o to, že cena vyřešení určitého požadavku v tom dodavatelském modelu není jen funkcí počtu hodin, které na tom nějaký programátor strávil, nebo dokonce počtu řádků. V tomto modelu ta cena zohledňuje širší souvislosti a zároveň vychází i z užitku, který přinese zákazníkovi (když vám nová funkce ušetří spoustu peněz nebo přinese zisky, tak je v pořádku za ni účtovat víc). Jindy zase dodavatel může udělat něco levněji, vzít nějaká rizika na sebe nebo říct, že je to v ceně příští verze. Ale nemůžeš čekat, že dodavatel ponese všechna rizika, bude ti ručit za termíny a ceny (i když předem neví, jak přesně pracné to bude), a pak ti k tomu dá cokoli, na co si vzpomeneš, za cenu pár řádků kódu nebo hodiny práce (protože jsi mu přece přesně řekl, co jeho programátor má udělat a on to jen opíše a zaverzuje) a ještě si tím nechá zprasit svůj software a zadělá si na problémy v budoucnu nebo u jiných zákazníků.

[JS1]

A ja proste s dodavatelem komunikuju tak, ze pichnu do toho kodu a reknu, ze tady chci aby to delalo neco nejak. Upravu mam vetsinou hotovou do druhyho dne.

To funguje skvele, pokud ma ten zadavatel pravdu, a pro to co chce staci skutecne zmenit tu cast kodu. Kdo ti to pak vlastne testuje?

Ale ty mas vzdycky pravdu, jak jsem si vsiml, takze to samozrejme neni problem. S lidmi kteri maji vzdycky pravdu je radost pracovat.

[j]

"Pamatuji si, ze pred 30-40 lety byl nekdo, kdo umel napsat prekladac takovy exot. "

A jak se zovou ti, co psali kod primo hexa pro danej CPU ? 30 let = 1990 = rekneme konec 8 bitu zacatek 16bit a PC.

Nebo dokonce ti, kteri programovali ... "sroubovakem" (ja teda nevim, jestli to ma nejaky nazev, byla to takove vec, s dutym koncem nasaditelna na pin, na kterej se tim natocil drat a spojovanim tech pinu se programovalo)

BTW: Ja si naopak myslim, ze podobny veci by se ve skolach (natoz verejnych) vubec vyucovat nemely. Prave proto, ze v praxi jsou naprosto nepouzitelny. Je to stejny, jako kdyby se studenti ucili pilotovat Apolo. At se klidne ucej, ale ve svym volnu (a za svy). Prave vyuka doslova megatun hovadin vede k vysledkum, ktery pak chodej zadat o misto, a divej se, kdyz se jim zamestnavatel boji sverit koste a lopatu.

[OldFrog {Ondra Nemecek}]

Mezi tím učit megatun hovadin a učit fundamentální principy oboru je propastný rozdíl. A kudy hranice vede záleží na typu školy a studia, což pak rozhoduje o tom, zda z ní vyjdou praktičtí řemeslníci nebo lidé pracující v teoretičtějších oblastech. Své opodstatnění má určitě oboje a je nesmysl protěžovat jedno na úkor druhého...

[j]

Poptej se zamestnavatelu ... co si o tom mysli. Vetsinou nejsou ani moc narocni. Stacilo by, kdyby se dotycnej zvladnul podepsat (aspon otiskem palce) a trefil se do misy ...

Myslis ze prehanim? Ze 150 lidi si ani JEDEN neumi na svym VLASTNIM telefonu nastavit email. Proste nezvladnou pridat ucet. Je mezi nima nekolik ing, nekolik mgr ... OK, slozity, ja vim ... takze ... ze 150 lidi ani JEDEN, nezvladne rozbalit balik papiru, a tak jak je ho celej strcit do zasobniku tiskarny. Jo ja vim, taky slozity ... ze 150 lidi ani JEDEN nezvladne pri odchodu z prace bouchnout do ty krabky ktery se vetsinou rika vypinac ... a zhasnout.

Co s takovejma? Masokostni moucka a zkrmit.

Ve skutecnosti je dokonce lepsi, kdyz nedelaji nic, protoze kdyz delaji neco, tak tim jeste pridelavaji praci tem nekolika malo lidem, kteri to pak musi jeste po nich vsechno opravovat.

BTW: Skola je (ze zakona) pripravou na budouci povolani, tudiz je vyuka cehokoli mimo tuto pripravu defakto nelegalni.

[Fluttershy, yay!]

Poptej se zamestnavatelu … BTW: Skola je (ze zakona) pripravou na budouci povolani, tudiz je vyuka cehokoli mimo tuto pripravu defakto nelegalni.

Ale škola na budoucí povolání u zaměstnavatele připravuje – učí držet hubu a krok. Jinak by lidé třeba přišli na to, že „zaměstnavateli“ nemusí sloužit, nýbrž se jimi mohou společně stát.

[Agent]

Ale škola na budoucí povolání u zaměstnavatele připravuje – učí držet hubu a krok. Jinak by lidé třeba přišli na to, že „zaměstnavateli“ nemusí sloužit, nýbrž se jimi mohou společně stát.

V zásadě souhlas, jen s tim rozdílem, že školy neučí držet hubu a krok kvuli zaměstnavatelům, ale primárně kvuli státu. Konec konců jsou to státní školy.

[Fluttershy, yay!]

Technická: Které školy že to jsou státní? Já jich moc neznám.

Ale i kdyby skutečně šlo o státní školy, tak v čím zájmu jedná ten stát? Nejsou to náhodou opět – zaměstnavatelé?

[kralyk z abclinuxu]

Ale škola na budoucí povolání u zaměstnavatele připravuje – učí držet hubu a krok. Jinak by lidé třeba přišli na to, že „zaměstnavateli“ nemusí sloužit, nýbrž se jimi mohou společně stát.

V zásadě souhlas, jen s tim rozdílem, že školy neučí držet hubu a krok kvuli zaměstnavatelům, ale primárně kvuli státu. Konec konců jsou to státní školy.

IMO je tahle myšlenka spíše kravina. Zaměstnavatelé v tom mají malý vliv. IMO je to prostě tím, že studentů je moc a učitelů málo. Učitelé pak nemají možnost a/nebo motivaci se studentům pořádně věnovat.

[Fluttershy, yay!]

Pak vysvětli, proč tolik průmyslníků – a politiků – volá po více učilištích a více absolventech.

[kralyk z abclinuxu]

To mi nepřijde nijak v rozporu (psal jsem, že studentů je moc na učitele, ne na průmyslníky/trh/politiky).

[Fluttershy, yay!]

Studenti/učni/žáci jsou na těch školách, které je přijmou, podléhají tamním plánům/osnovám/… atd.

Kdo stanovuje vzdělávací politiku a financování?

(Mimochodem předřečník je jako obvykle mimo, protože české soukromé školy jsou na tom vesměs ještě hůř než ty veřejné.)

[kralyk z abclinuxu]

Kdo stanovuje vzdělávací politiku a financování?

Velký Kapitál skrz své nohsledy, samozřejmě. Tudíž bychom z toho měli vyvodit jasný závěr, že je potřeba svrhnout Velký Kapitál a ztlemit se do anarcho-syndikalistických organických organizací.

Teď vážněji: Který zaměstnavatel motivuje vyučujícího zkoušet plošně studenty primitivním automatem ze psaní nízkoúrovňových cache-optimálních programů v C? Neměl by je podle tvé teorie spíš nutit psát bussiness patterny v Javě a C#? (Což se v některých předmětech a/nebo na některých školách taky děje, ne že, ale není to jenom o tom.)

[Fluttershy, yay!]

Přečti si ještě jednou, co jsem napsal.

V tomto případě je zásadní pojetí „vzdělávacího procesu“ tak, že student drží hubu a krok, přičemž toliko krmí různé progtesty apod. kvanty úloh z tuctu různých předmětů. (Ostatně viz komentáře pod navazujícím blogískem.)

Výchova lopat – nebo odfiltrování nekonformních jedinců, kteří by nedělali poslušné lopaty.

[kralyk z abclinuxu]

V tomto případě je zásadní pojetí „vzdělávacího procesu“ tak, že student drží hubu a krok, přičemž toliko krmí různé progtesty apod. kvanty úloh z tuctu různých předmětů.

Výchova lopat – nebo odfiltrování nekonformních jedinců, kteří by nedělali poslušné lopaty.

Můj argument jest toliko ten, že na vznik stavu tohoto (studenti krmí progtesty kvanty úloh a jsou vedeni k lopatství) není zapotřebí nižádného převelikého vlivu zaměstnavatelů (i když ten dozajista též existuje, netvrdím, že nikolivěk). To jest, na vznik stavu onoho stačí toliko masivní mnosžví studentů, kterých jest na jednohož učitele přespříliš, a tento je rád, že stihne toliko odpřednášeti a toliko zadati úkolů mnohých do progtestů přemocných.

Co jiného může učitel se ~stovkou studentů provésti, než progtesty jim zadávati a k lopatě je vésti? Poměr takový těžko ke kvalitní výuce směřovati bude, není-liž pravda?

[Fluttershy, yay!]

Možná si vzpomeneš na praxi z matfyzu, kde cvičení někdy vedli studenti – dokonce ani ne doktorandi. Lze to vnímat jako šetření univerzitních zdrojů, nebo taky krok směrem ke kolektivnímu učení se.

[kralyk z abclinuxu]

Jo, o zdrojích to určitě je. Kolektivní učení může být fajn, ale musí být od koho / podle čeho. Na těhle školách to kolikrát je spíš kolektivní tápaní než kolektivní učení...

[Radovan]

Protože staří fachmani odešli do důchodu, a noví nejsou. Těch pár mladých co se vyučí jsou takoví lemplové, že za nimi stejně musí stát jeden starý a opravovat to po nich.

No a tihle vyžírkové, tedy průmyslníci a politici, si najednou uvědomili že na ně brzy nebude mít kdo dělat, a pomalu začínají panikařit. Zdroje se prostě vyčerpaly.

Ale není to jen o výrobě, podívej se třeba, jaký je věkový průměr řidičů autobusů. Hromada z nich jsou přesluhující důchodci, doplňují to Poláci a Ukrajinci, jiné neseženou.

[Fluttershy, yay!]

protěžovat

FYI protežovat (z francouzštiny: protéger)

Mezitím tady „j“ vystupuje jako grammar antifa.

[xxx]

Tak to mas pravdu, ze pro lopatu co ma misto lopaty klavesnici je to nepouzitelny. Pro takove je tu Unicorn.

[xxx]

Když jsem seděl na našich přednáškách vzadu, abych mohl na kolegy navázat, tak vidím jen facebook, youtube, chaty, maximálně pak práci na úkolu do jiného předmětu.

Já to vydržel rok. Brouzdat na netu a nebo psát semestrálky na přednáškách. Pak mi došlo, že to je pohlnější dělat v bufetu nebo doma. Extrémem byla matematika. Možná se někdo učí dobře poslechem nebo opisovaním v 7:30 v pondělí ráno, ale já ne. Takže na vyprávění "definice, věta, důkaz", které jsou stejné jak na tabuli, tak ve skriptech jsem se velmi rychle vybod.

Ostatní minimálně polovina přednášek na tom byla dost podobně. Témata často lépe zpracovaná ve skriptech, na internetu, a občas i na YT z jakési technické univerzity v Dilí. Ony ty hodinu a půl dlouhé přednášky měli možná význam v době opisovací, kdy na Internetu materiály nebyly, v nejlepším případě se někdy podařilo přednášejícího přesvědčit, aby nám půjčil slidy (fyzické průsvitné fólie).

Utáhnout kvalitně hodinu a půl dlouhou přednášku zvládne málokdo. Tím kvalitně myslím, tak aby měla přesah přes skripta. Kór třínáctkrát za sebou. A je otázka, zda-li to má v řadě předmětů vůbec smysl. Jestli je vůbec možné připravit dostatečně zajímavý obsah, který není pro studenta snažší nasát jinou formou.

Jinou možností u tak dlouhých přednášek je asi interakce s posluchači. Což ale zase znamená posluchače připravená a se zájmem.

A to je druhá strana problému, studenti a jejich motivace. Jestliže na cvikách, v prváku v základech programování, jsou dva co to mají v malíku a můžou z fleku odevzat semestrálku. Dva co to zajímá, neumí to, a skutečně mají nějaký zájem o to se to naučit. No a zbytek, co na VŠ jde z principu (peníze, maminka by byla smutná, ...) a na tu trojku to nakonec nějak dodělaj. V podstatě tam máte (myšleno na VT) 80% studentů, jejichž motivaci by odpovídala spíše Fachhochschule. Případně klidně roční kurz. A ti fakt budou raději surfovat na internetu.

Tak snad se to časem změní. Ale bez participace na obou stranách to nepůjde. Budete muset do KTM vyhnat i nějaké další kolegy.

[xkucf03]

Já jsem tedy na přednášky chodil a jsem rád, že jsem to mohl naživo slyšet. A ten výklad měl často dost jiný obsah/záběr než skripta.

[xxx]

A proto vsichni vejraj do notebooku s Facebookem...

[Rezza]

Tak já jsem byl jeden z mála, který chodil, ne na všechny, ale na valnou většinu. Někdy to opravdu smysl němelo, někdy se to dalo, ale skutečně dobrých přednášejících moc není. A nejhorší jsou často ti, které to přednášení vyloženě otravuje. A pak bylo pár výjimek, kde jsem ani nedutl. Vždy záleží. Nakonec nejzajímavější byly dějiny. Povinně volitelný, tak si to člověk musel odsedět. Nejdřív to ignoruje, sedí na netu (tenkrát ani na kolejích nebyl, takže člověk doháněl resty). Pak jedním ouškem začal poslouchat, pak druhým. A pak jsem jen seděl s otevřenou pusou a hltal každé slovo. Neslyšel jsem ani jeden letopočet, ale dostal jsem poprvé v životě kontext v dějinách.

[xkucf03]

Tak tohle jsem taky zažil – na gymnáziu jsem dějepis nesnášel. A na VŠ to byl jeden z mých nejoblíbenějších předmětů a zapisoval jsem si ty kurzy dobrovolně navíc.

[Agent]

Já teď poslouchám "historika" Vávru...

Prostor Ondřeje Tesárka #8 - Daniel Vávra

[JS1]

Prednasky (a psat si vlastni poznamky) maji smysl. Nevim, jestli jsi nekdy zkousel ucit se sam z nejake treba knihy. Je to obtizne, protoze clovek je rozptyleny, a obcas se prilis zasekne.

[xxx]

Metod jak se ucit je spousta. Maji sve plusy a minusy. Netvrdim, ze obecne prednasky nemaji smysl. Ale pokud si nekdo smutni, ze na nich studenti sedi jen formalne, pak ta uzitecnost asi neodpovida predpokladu.

Jiste muzes se zaseknout, pak se ti treba hodi nejaka konzultace a je to spis zpusobeno nadmernou koncentraci. Stejne tak prednasejici nema talcitko PAUSE a FF, takze se ti zase celej vyklad muze slit jen do sumu nebo do ukrutne nudy.

[JS1]

Dobre na prednaskach je, ze te tim proste nekdo protahne.. jak se ukazuje, schopnost lidi absolvovat treba online kurzy je miziva. No offense ale mozna na tebe proste nektere prednasky byly prilis rychle.

Ja jsem zjistil, ze existuje urcity "sweet spot" v rychlosti vykladu. Pokud byla prednaska prilis rychla/obtizna, tak jsem vypnul a nezvladal to. (Ale i tak pomaha psani prave tech poznamek.) Pokud byla prilis pomala, tak jsem usinal nudou - to se mi stavalo hlavne na prednaskach na FELu. Optimalni obtiznost byla zhruba jako prednasky pro prvaky na FJFI.

[Pavel Píša]

S tím, že soustředění se na 1.5 hodyny výkladu je náročné, souhlasím. Studenti pak mají často blok několika náročných přednášek za sebou. Na druhou stranu dokázat se soustředit je právě vemi důležité umění nutné pro budoucí práci. Ať již při nějaké technické debatě, která může někdy trvat i několik hodin a nebo třeba i pro to, aby byli schopní vyjet na konfrence a načerpat nové znalosti. A tam se často jedná o úplně jiný level úsilí, kdy jsem si i já často sáhl na hranici výdrže a pil kafe (to normálně nepiji), protože často nic jiného není k dispozici a i mi to pomáhalo udržet pozornost.

Při studiu na VŠ jsem občas také útlumy u monotóních přednášek měl. Ale u těch náročnějších a nejlepších na procvičení myšlení jako je matematika nebo teorie pole nikdy.

Asi nejlepším tělocvikem bylo na gymnáziu soustředění k fyzikální olympiádě v Jevanech, čtyři (středoškolské) vyučovací hodiny dopoledne, a čtyři odpoledne pět dnů za sebou. Počítání příkladů, přednášky. Pamatuji si na spolužáka zrovna také z našeho gymnázia, jehož psací písmo vypadal jako EKG záznam (kličkami a peaky modulovaná linka) a v určitou chvíli ho přepadla únava a tužka dále pokračovala k okraji papíru a za ní zůstávala rovná čára. Ale všichni, i on, jsme se moc ze semináře těšili, ve volném čase se s profesory procházeli kolem rybníků, obdivovali motorky atd.

Další vrchol byla cvičení ze statisticky s profesorem Havrdou. Byl tenkrát již zkrocený a nenechali ho přednášet. Když jsem přišel na cvičení, tak většina spolužáků našla výmluvu, jak se přehlásit do jiného cvičení. Nás, co jsme zbyly, vyhodnotil jako nehodné počítání u tabule a během cvičení pak vždy zvládl výklad přednášky (oficiální přednášky jeho žáka mu nepřipadaly na dostatečné úrovni) a poté kompletně teorii. Přes definice, věta, důkaz demonstroval přes náročné příklady a odvozování. S vypětím maximálního soustředění jsem zvládl vše zapisovat, ale chápání mi zůstávalo o dva, tři příklady, pozadu. Ale většinou jsem se v tomto závěsu udržel a pan profesor byl opravdu kapacita a když jsem se ho na cokoliv o dvě smazané tabule zpět zeptal, tak okamžitě odpověděl. Story o zápočtové písemce a dalším by byla opět na delší vyprávění.

Zpět k předmětu, který mám na starosti. Jedná se o předmět Architektura počítačů.

Na LinuxDays jsem se pokusil o zcela alternativní přístup, kdy každý účastník mohl zkoušet vše, co jsem předváděl, na svém počítači paralelně se mnou s tím, že pokud nestíhal psát, tak si mohl stahovat to, co píši sám, z webu, kam jsem obsah editoru integrovaného do QtMIPS ukládal přes sshfs. Bylo to náročné a zároveň i velká zábava i pro mě. Udělal jsem tři chyby:

• připojil jsem se přes WiFi a ne přes kabel, jak účastníci v prohlížečích mačkali na reload, tak se mi občas při save na desítky sekund zatuhl QtMIPS
• nepustil jsem si záznam obrazovky a tak jsem při postprocessing neměl k dispozici dobrý záznam obrazovky, tím trpí z editované video
• při popisu rozsahu immediate jsem jednou řekl 32 byte místo 32 KILObyte

Jak moc se od klasického 1.5 hodinového výkladu odvážím přejít k nějakému experimentování v tomto běhu nevím. Ono látky je opravdu hodně, schopnosti studentů mezi sebou se liší o řády. Pokud máte chuť, tak založím další zápisek, kde můžeme o výuce diskutovat. Protože si pan profesor Hanzálek v roce 2017 všechny Ph.D. studenty, které jsem jako diplomanty a studenty vychovával a do týmu přivedl, odvedl do jiného institutu a vzkázali mi, že je nemám kontaktovat s výukou, protože by nestíhali svůj vědecký růst, tak jsem sháněl a i nyní sháním cvičící mimo univerzitu.

Asi přidám zápisek, pod kterým můžeme o výuce diskutovat. Nečekal jsem na ABClinuxu tak velkou a zapálenou odezvu. Zpětně hodnotím, že jsem měl začít diskutovat o řešení problémů, kterými se vlastně nikdo na škole zabývat včas nechtěl, na ABClinuxu dříve.

Pokud se někdo z vás chce do výuky zapojit jako cvičící, tak dveře jsou otevřené. naopak, protože ne všichni cvičící budou mít čas na návštěvu mých přednášek, tak zařídím, jestli to bude technicky možné, aby byly nahrávané a případně přenášené online pro mé kolegy a nakonec i pro kohokoliv dalšího.

Naopak, pokud si chcete znalosti z architektur zopakovat, tak se můžete do kurzu zapsat. V rámci celoživotního vzdělávání by snad měl být k dispozici jeden předmět za 3000 kč za semestr.

Moc velké díky všem diskutujícím za věcné a podmětné příspěvky.

[odin]

Protože si pan profesor Hanzálek v roce 2017 všechny Ph.D. studenty, které jsem jako diplomanty a studenty vychovával a do týmu přivedl, odvedl do jiného institutu a vzkázali mi, že je nemám kontaktovat s výukou, protože by nestíhali svůj vědecký růst, tak jsem sháněl a i nyní sháním cvičící mimo univerzitu.

Tohle by bylo téma na další velkou diskusi - střet zájmů v akademické sféře. Tohle se bohužel stává, že někdo za veřejné peníze vystuduje, rozjede výzkum, sestaví tým a nasbírá kontakty... a ve chvíli, kdy to jde zpeněžit, tak odejde a nechá si zisk pro sebe.

V soukromé sféře je běžné podepisovat konkurenční doložky, je zakázáno zneužívat svoje kontakty, databáze, odlákávat* zákazníky nebo zaměstnance svému bývalému zaměstnavateli.

Stát by se k tomu jako řádný hospodář měl postavit podobně a zajistit, aby podobní vykukové netunelovali akademické (a tím pádem veřejné a naše, nás daňových poplatníků) rozpočty a když už se do jejich výzkumu a osobního růstu investovalo z veřejných peněz, tak by z toho měla mít zisk veřejnost.

*) kontrola pravopisu mi to tu podtrhává červeně a nabízí jako správné slovo "ohlodávat"

[xxx]

CURAK, nebo jak se to jmenuje, je soucasti CVUT.

[j]

PRESNE!

Drtiva vetsina prednasek = prednasejici opisuje na tabuly scripta. Jmenovite prave FEL CVUT. Tech nekolik malo vyjimek nestoji za hovor.

Zaroven ... vazeni mate deti? Myslim opravdu maly (naivni a hloupy ... ;D), proste takovy, co se rady chlubej vsemoznejma basnickama a rikankama? Tak honem, poslete je na nejakou VS ... driv nez zmoudrej. To pak budou trebas chtit vedet a porozumet a to je zasadne spatne. Ale naucit se zpameti = cerveny diplom zarucen.

Ona ta prednaska je predevsim levna vis? Potrebujes jednoho duchodce a obslouzis 400 volu. (pardon, ale devcata byla v paralelce presne 2). To kdybys mel poradat jeste nejaky laborky, tak potrebujes ty laborky a hromadu hodin a lidi ...

A ne, nezmeni se to. Jakozto prumyslovaci jsme byli pro nektery vyucujici "ten povl, kterej je treba eliminovat", a pritom gymplaci o laborkach cumeli na voltmetr jak na masinu ze startreku. Pri fyzice (na felu !!!!) se merily ulohy ktery tam byly stejny snad 50 let (a verim ze tam sou furt), a pak se vsichni strasne divi, ze jen blbec to neopise (ten si to 10x prepise, protoze to nema tak jako ti pred nim).

Pricemz presne jak pises s tim programovanim, akorat tenkrat to bylo jeste horsi. Tenkrat totiz jeste i ten, kdo si jen chtel zahrat hru, musel lecos umet a vedet, takze tak 1/4 zucastnenych toho umela srovnatelne nebo vic, co vyucujici ... a 1/4 prozmenu nezvladala ani helo world.

[xxx]

Spsi dost nepresne...

[johnyK]

Drtiva vetsina prednasek = prednasejici opisuje na tabuly scripta.

bylo na strojni bohuzel take tak ...

[V.]

Pohladilo, děkuji.

[kralyk z abclinuxu]

Příloha:

• uloha-nosniky.txt (3705 bytů)

Díky za pěkný zápisek. Ten výlet vypadá opravdu parádně, stejnětak návštěva místní školy.

Zastavil bych se u tohohle:

Přednáška byla na velmi pěkné úrovni, nebyl problém jí sledovat, algoritmy totiž psala anglicky, studenti jí pozorně sledovali, psali si do sešitů algoritmy anglicky a pak dopisovali nepálsky její vysvětlení. Na konci přednášky ve skupinkách řešili zadaný příklad a ona je obcházela. Slzel jsem dojetím a srovnáním s naší přednáškou. (...) Když jsem seděl na našich přednáškách vzadu, abych mohl na kolegy navázat, tak vidím jen facebook, youtube, chaty, maximálně pak práci na úkolu do jiného předmětu. V Nepálu jsem si připadal podobně, jako když jsme chodili na přednášky v devadesátých letech, kdy na Internetu materiály nebyly, v nejlepším případě se někdy podařilo přednášejícího přesvědčit, aby nám půjčil slidy (fyzické průsvitné fólie).

Rozumím tvým pocitům a přemýšlím, v "čem je chyba". Nabízí se jednoduchá odpověď, že ve studentech, což je asi jedna z validních odpovědí. Případně v chování společnosti "v dnešní době" atd., která je neuvěřutelně rozlítaná a člověk má problém se na cokoli soustředit.

No nicméně přístup školy bych z toho taky úplně nevynechával S ČVUTem mam zkušenost jen jeden semestr (FEL), moje dojmy byly dost smíšený. Některý předměty byly dobrý a bavily mě, jiný hrozný, a tomu víceméně odpovídaly i výsledky. Jeden s těch, co mě štvaly, byl Pokročilá algoritmizace, kde mě hrozně ubíjelo to, jak přednášky byly v non-synchronizaci se cvikama, který byly stejnětak v non-synchronizaci s úkolama (který bylo potřeba mít na zápočet), takže člověk musel sledovat 3 různý linie výuky téhož. Taky mě štvaly ty programátorské úkoly odevzdávané do takovéhotoho automatizovaného systému, který je vyhodnocuje a plive jen výsledek ve stylu dobře/špatně, a poraď si s tim sám jak umíš. Takže výuková interakce je pak redukovaná na interakci s nějakým dost tupým automatem, ze kterého jde zpětná vazba s nejmenším možným detailem.

Přikládám do přílohy úlohu, kterou dostal před časem můj brácha na ČVUT/FITu a která mi přijde úplně mimo mísu co se týče obtížnosti, vzhledem k tomu, že to dostali zadáno někdy v půlce prvního semestru. Tohle pak IMO vede k tomu, že tu úlohu vymyslí jeden dva lidi z ročníku díky štěstí nebo genialitě a ostatní to pak od nich obšlehnou.

Rozumim tomu, že škola musí studenty nějakým způsobem testovat a člověk nedostane vzdělání úplně jen tak na stříbrným podnose, ale přijde mi, že v některých předmětech se učitelé soustředí na tu testovací část nepoměrně víc než na tu vzdělávací a mění se pak na něco jako certifikační autoritu (jako jsou třeba u jazykových certifikátů). Člověk si pak přijde pro certifikát a jak se to naučí nebo nenaučí je jeho věc...

Že by přednášející po přednášce obcházel studenty a nějak s nima interagoval při řešení praktické úlohy, to jsem zažil na české technické VŠ opravdu jen velmi vzácně, jestli vůbec někdy...

Dodávám ještě jen znova, aby to nevypadalo, že kritizuju úplně všechno, že tyhle problémy se týkaly jen některých předmětů. Jiné předměty probíhaly pěknější formou, v ucelenějším formátu atd.

[Fluttershy, yay!]

Nabízí se jednoduchá odpověď, že ve studentech, což je asi jedna z validních odpovědí. Případně v chování společnosti "v dnešní době" atd., která je neuvěřutelně rozlítaná a člověk má problém se na cokoli soustředit.

Ironie: pak ti skutečně pilní studenti odejdou dělat do Facebooku, aby to příští generaci ještě víc ztížili.

[xxx]

He he, slavnej Progtest. Ne ze bych ho chtel nejak hajit, ale taky nevznikl na zelene louce. Jsem mel cvika u jeho autoru jeste pred jeho vznikem. Operacni systemy, ci co to bylo. Nejaka trochu slozitejsi uloha na thready.

Na zactku rekl cvicici neco ve smyslu, ze to nema leakovat, ze pocet threadu nema byt umele omezen, ze to bude testovat na skolnich SunRayich a ze tam nesmi byt zadny sleep a ze to ma mit nejak definovany vstup. Zadna hruza, ale ani uplnej bordel. Behem semestru se odcvicilo vse potrebne, vcetne zakladu. No a pak prislo odvezdavani semestralky, kdy se lidi divili, ze jim to bez sleepu nebo na Sunrayich nefunguje (protoze vice nez 1 CPU). Nebo ze to leakuje, kdyz tam nikde neni free(). Nutno jeste podotkout, ze semestralku bylo mozne odevzdat ke konzultaci v predstihu.

No a nejvice se samozrejme hadaji nejvetsi lempli, ne ti co tam maji blbe nejaky detail (ti ho radsi opravi). Takze vysledkem je progtest, ktery to resi krute ale spravedlive. Navic to skaluje s poctem studentu. Takze ne ze by se mi takovy pristup libil, ale jeho vznik chapu.

Pises, ze to je pristup jak v tovarne na certifikaty. Je. Ale co chces delat se studenty, jejichz cileme je neco se nadrtit, nikoliv pochopit, a pak jit delat nekam lopatu.

[j]

Ve studentech (a zacich) chyba neni!!

Chyba je ve skolstvi (jako celku) skolach a vyucujicich.

Sorry vazeni obhajovaci neobhajitelnyho, ale prednasky typu definice/veta/dukaz nikoho nezajimaj. Navic vsichni zucastneni (vcetne toho vyucujiho) vedi, ze je to vlastne uplne khovnu, ze to je jen takova hra, na to ze ja (prednasejici) vam tu neco rikam, a vy (posluchaci) se neco ucite.

Pak vas z toho jako prezkousime, kdyz je vac moc, tak vas zredukujem (=budem bazirovat na tom, kde ve vete je ta tecka a kde carka) a nakonec, tem nejhloupejsim z vas (ti chytri mezi tim davno utecou) dame lejstro s razitkem aby ste si nekde u statu (protoze nikoho jinyho nezajima) mohli rict o teply mistecko.

Mno a zatimco vasi chytrejsi vrstevnici maji uz mozna vlastni byt, vy mate (v +-25) holou rit.

BTW: Jak bys asi tak chtel diskutovat s prednasejicim po prednasce, kdyz za 10 mit mas dalsi uplne stejne "hodnotnou" prednasku (nebo jeste lepe povina cvika), v pripade FELu pak jeste klidne s bonusem, ze v tom intervalu musis zvladnout presun z kulataku na karlak ...

Jinak receno, na ty prednasky prestanes chodit uz jen proto, ze prece nejses magor a nenechas si pokazdy nadavat ze uz jdes zas pozde.

BTW2: "jak se to naučí nebo nenaučí je jeho věc" Ale takhle je to vubec nejlevnejsi vis? To mas takhle vysokou skolu, ktera ma hromadu vlastnich lidi (a jeste vetsi hromadu studentu). Ta skola si za nehorazny penize necha vyrobit KOS ... kterej pochopitelne (a jak jinak) prvni den lehne. Po dalsich stovkach tisic investic mas polonefunkcni jak reseto deravy system, do kteryho se muze prihlasit 150 lidi (na skole, kde jich je 10k+). Tomuhle systemu pak nedela problem vypsat pro 4x400 lidi 30 zkouskovych terminu po 20. Nebo taky jedno dvacetimistny (poviny) cviceni. Mno na druhou stranu si do nej proste znamky muzes zapsat sam, a pak si je dojdes na studijni nechat zapsat do indexu. Jestli tu je pametnik, tak jiste potvrdi.

Idealni student svoji alma mater neobtezuje svoji existenci.

[JS1]

Mohl jsi jit na FJFI CVUT jako ja, tam byla vzdycky rodinna pohoda. Nemusel bys mit pak mindrak z toho, ze jsi nedodelal FEL.

[Radovan]

KOS? První díl dole: https://www.bugemos.com/?q=taxonomy/term/228

[Gréta]

Přikládám do přílohy úlohu...

nóóóóóóóóóó až na druhej pokus teda no. ale vomlouvá mě že sem v životě neviděla nosník a vlastně ani pořádně nevim co to jako je ;D neni to taková ta železná tyčka jak se schovává do betonu když se jako třeba staví mrakodrap??

zadání samotný je dobrý psycho :D :D :D :D si myslim že šéf nařídil učitelskýmu aby vymyslel nějakej reálnej praktickej problém ze života a dopadlo to takle divným autistickým outem kde se jako střídá nosník s EOFem a popis problému se míchá s popisem algoritmu :O si to musíš přečíst aspoň třikrát s otevřenou pusou abys jako vubec pochopil co se po tobě jako chce a eště nemáš uplně vyhráno :O :O i když ten problém samotnej je celkem jednoduchej si teda myslim ;D

jo a mínusy a jiný neplatný zadání ať si jako hlídaj sami v tom testovacím prostředí nebo čemto. je to jako úkol z algoritmů nebo lepení v nějakým programovacím jazyku??!! >:C

zadani=[([1,2,3,4,5],33),([3,6,4,7],40),([1,1,1,1,1,1,1,1,1,1,1,1],44),([2,9,8,124,31,71,45,21,3,1,9],849)]

#jak nato jako?? žeby krájet to v +- v půlce????

#vygooglíme si jak udělat z pole dvě +- stejně velký půlky
#https://prismoskills.appspot.com/lessons/Arrays/Divide_into_two_equal_sums.jsp
def split_array(arr):
    
    arr_a=[]
    arr_b=[]
    sum_a=0.0
    sum_b=0.0
    
    dylka_pulky=int(len(arr)/2)
    
    while len(arr_a)<dylka_pulky and len(arr_b)<dylka_pulky:
        val=arr[-1]
        if sum_a<sum_b:
            sum_a+=val
            arr_a.append(val)
        else:
            sum_b+=val 
            arr_b.append(val)
        del arr[-1]
        
    #sesipat zbytek na dorovnání počtu
    # TODO de určitě zlepšit
    if len(arr)>0:
        
        arr.reverse()
        for c in arr:
            if sum_a<sum_b:
                sum_a+=c
                arr_a.append(c)
            else:
                sum_b+=c
                arr_b.append(c)

    return (arr_a,arr_b,sum_a+sum_b)

def step(arr):
    arr=sorted(arr)
    split=split_array(arr)
    price=split[2]
    a=split[0]
    b=split[1]
    if len(a)>1:
        price+=step(a)
    if len(b)>1:
        price+=step(b)
    return price


for z in zadani:
    print()
    print()
    print(z[0])
    price=step(z[0])
    print("greta ma: "+str(price)+" voni maj: "+str(z[1]))
    print()
    
# aha vono to jako takle jednoduše nefunguje :D :D :D :D
# skoro všechy to udělá ale to s výsledkem 849 tajemě odolává!!!!! :O :O :O :O
# si myslim že budem muset použít mozek ;D
#
# nejlacinější půlka je ze dvou nejmenších kusů
# začnem jakoby odkonce a
# budem spojovat ty nejprťavější půlky jakože toho dělení v párky
# hotovo až zbyde jenom jedna velká půlka ;D

print()
print("pozor lepim!!!!!!")
print()

def slepit(arr):
    price=0.0
    while(len(arr)>1):
        arr=sorted(arr)# TODO sort de asi vylepšit pro přidávání tý jedný půlky
        new=arr[0]+arr[1]
        del arr[0]
        del arr[0]
        price+=new
        arr.append(new)
    return price

for z in zadani:
    print()
    print()
    print(z[0])
    price=slepit(z[0])
    print("greta ma: "+str(price)+" voni maj: "+str(z[1]))
    print()