Vlákno názorů k článku Mix posvátné validity a X od ee - Nejlepsi syntaxi ma python: def mojeFunkce(): ...

Nejlepsi syntaxi ma python:

def mojeFunkce():
    if  neco:
        delejNeco1()
    else:
        delejNeco2()

Zadne zbytecne slozene zavorky, zadne kulate zavorky v podminkach, zadne stredniky. Jeste by nemusel mit ty dvojtecky. Vsechny ostatni jazyky maji syntaxi prisernou, protoze predepisuji pouzivat spoustu zbytecnosti. mimochodem cestina je taky blby jazyk ma zbytecna diakriticka znamenka - vsak je mi rozumet i bez nich a bez velkych pismen a interpunkcnich znamenek bychom se taky obesli v naproste vetsine pripadu Tim chci rict, ze nemate pravdu. Nezalezi co gramatika predepisuje, ale jak jsou gramaticka pravidla slozita a kolik maji vyjimek. Kdo neni s to pochopit a naucit se syntaxi XHTML, nedokaze to ani u HTML. Na opak to vsak neplati, je spousta lidi, ktera jednoducha XML pravidla chapou a umi rozpoznat co je spravne a co ne, kdezto u HTML diky spouste vyjimek to rict nedovedou. Jednotnost zapisu cteni rozhodne neztezuje, naopak, dela text prehlednejsi. A myslim ze pro tech par znaku navic ani psani neni slozitejsi, jen je ho nepatrne vic, ale jen teoreticky, protoze vyvojove nastroje, treba editory nam praci zjednodusuji a naopak jednoduchost a jednotnost syntaxe umoznuje editorum a spol. nam praci ulehcovat mnohem lepe. Viz treba syntax hyglighting, ktery je mnohem snazsi implementovat u jednoduche XML syntaxe nez slozite HTML syntaxe.

Tim zarovnanim myslite asi odsazeni. To neni opruz, protoze to stejne kazdy programator dela. Zavorky jsou pro stroj, odsazeni pro cloveka. Proc by se stroj nemel prizpusobit cloveku? Python tak cini, stejne jako clovek se orientuje podle odsazeni. Je to super vec.

Za prvy kdo potrebuje nejaky SVG, kdyz je flash a kdo potrebuje MathML, kdyz je gif/jpeg/... A za druhy, jak si pak kazdy BFU vytvori validni stranky pomoci produktu toho, jehoz jmeno se nevyslovuje? Jo a ze to par procent lidi (postizeni) neni schopno vubec pomoci asistivnich technologii zpracovat, to je prece jen detail.

Netuším, jaký produkt myslíte, takže mohu psát jen obecně. Vytváří tento produkt validní HTML? Pokud ne, je další diskuze o validitě bezpředmětná. Gramatiku XHTML považuji za jednodušší než gramatiku HTML, takže si myslím, že pro stroje i pro lidi je XHTML stravitelnější.

No suhlasim, ze je dolezite sledovat strojovy cas. Ale teraz mi povedz co ti strojovy cas skrati. Jazyk s presnymi pravidlami alebo s velkou volou ?
Ja hlasujem za presne pravidla. Menej overovania, nie je nutnost sledovat vynimky, pretoze ti to hned vyhodi chybu. (Nemyslim teraz parsovanie XML, lebo niektori ludia na to radi kladu doraz, ktory chcu vypichnut do oci, lebo na lepsie sa nezmozu)

Samozrejme moznost jedna je spravna :)

Uz sa to tu raz preberalo, nechcite aby som zopakoval niekoho ineho nazor. Ale budiz

XHTML je ovela menej ohybnym jazykom co sa tyka spraskania hnusneho kodu. HTML pouzivalo slovo SHOULD, XHTML pouziva MUST. Vidite tam ten rozdiel ? Co som si v HTML mohol dovolit si v XHTML nedovolim a vyhodi mi chybu. Prave toto dava moznost lahkeho parsovania, pretoze je definovana presna postupnost, kde co ma byt a nie kde co moze byt.

Na to jak je HTML ohybny musim pocitat so vsetkymi vynimkami, ktore mi tento jazyk ponuka. XHTML ma tychto vynimiek ovela menej, co sa Vam teda bude lahsie parsovat ?

Nehovorte mi ze HTML, to by bolo slovo na flamewar a zbytocne utocenie na veci v ktorych sa mylite :)

A prosim vyhnite sa tomu ze spomeniete, ze ved napisem si pekne HTML. To je obycajna vyhovorka.

Spomenuli ste pravidla, tak som o nich hovoril. Nespominali sme nic o tom ako si napisem stranku, ale v com je cela "norma" zlozitejsia, pretoze mi ponuka "volnost".

Ja ta odkazem na kometare Pixyho v predchadzajuich a aj v tomto clanku. Myslim, ze on v tychto veciach ma vacsi prehlad ako my dvaja dohromady.

Těmi X technologiemi myslíte X-ray? Tedy rentgen? Ne nevím jak vy, ale já dávám na server webové stránky a nemám potřebu je propojovat s rentgenem ;-)

Na všelijaké importy-exporty dat je 'X technologie' použitelná, ale ve většině případů lze data přetáhnout jednodušeji, rychleji a s menší potřebou strojového času i jinak - CSV, SQL, klidně i TXT.

Nejedná se o importy a exporty dat, ale o jejich zpracování, což je činnost podstatně složitější. Již po několik let není nutné hlídat náročnost na strojový čas, ale na čas programátora. X technologie jsou v tomto ohledu k programátorům velice přátelské.

Nesouhlasím. Není přeci problém výstup v XML pár pravidly překonvertovat do korektního HTML4.

Na obrázek v SVG se přeci mohu odkázat jako na každý jiný.

A MathML? Darmo mluvit ... příšernější způsob zapisování formulí jde už sotva vymyslet.

Opravdu Vám přijde stravitelnější pro lidi muset například psát uvozorky na místa, kde jsou evidentně zbytečné?

Jistě, gramatika XHTML je jednodušší, ale text pomocí ní zapsaný určitě není čitelnější, alespoň co se lidí týká.

A pokud jde o optimalizaci pro stroje, je XHTML sice jednodušší, ale téhož lze dosáhnout ještě řádově jednoduššími prostředky, třeba pomocí s-expressions.

Jistě, ale to přeci neznamená, že k tomu má syntaxe jazyka každého nutit.

Ehm, přečtěte si, prosím, můj příspěvek ještě jednou. Neříkám nic o tom, že se syntaxe nemá dodržovat, nýbrž, že syntaxe nemá předepisovat zbytečnosti, které pouze ztěžují psaní a čtení.

Když už jste nadhodil syntaxi u programování, ta dává docela hezkou analogii: čísla či jména proměnných se v běžných programovacích jazycích také zapisují přímo a není důvod je psát do závorek nebo do uvozovek, i když by to zajisté bylo systematičtější a zjednodušilo by to parser :-)

Malá otázka. Je rýchlejšie parsovanie značkovania s presne stanovenými pravidlami alebo parsovanie značkovania s presne stanovenými pravidlami? :)

To problem je, xslt je pomerne narocny a slozity na pochopeni, tohle laicti tvurci webu rozhodne pouzivat nebudou. A stoji tu predevsim otazka, proc bych mel ty sloite a narocne konverze vlastne delat, kdyz prohlizec muze to xml zobrazit primo? To ze je prohlizec obecny xml klient nevazany na jeden konkretni jazyk je preci uzasna vec. Proc to chcete omezovat?

Na SVG obrazek ano, ale pracovat s obrazkem pomoci DOM muzete uz jen u toho SVG. A DOM je velmi silna a oblibena technologie, kterou weby intenzivne vyuzivaji. Proc to ale omezovat jen na dokument? Proc to neaplikovat i na obrazky? Proc to chcete omezovat?

Ad MathML, to je jen vas nazor, imho hloupy. Ostatne, cokoli je lepsiho, nez nutnost generovani desitek bitmapovych obrazku s nakreslenymi vzorci a vkladani je do html. Jestli vam tohle opravdu vyhovuje, protsim, generator MathML vzorecku neni problem. Proc ale chcete vsechny omezovat na nutnost generovani obrazku, kdyz tu jsou mnohem prijemnejsi moznosti?

Poslyste, nejste vy nejaky omezeny?

Ve chvíli, kdy jste prohlásil, že čeština je špatně navržený jazyk, protože Vám je rozumět i bez velkých písmen, diakritiky a interpunkce, jsem přestal číst a Váš názor zařadil do kolonky bezvýznamných.

Chcete důkaz, že nemáte ani v jednom případě pravdu, nebo se nad tím zamyslíte?

To nie je až také isté.

Děkuji vám za informaci, že jste se zařadil do skupiny bezvýznamných hlupáků nechápajících ironii.

A provádíte u CSV, SQL a TXT test, že jsou well-formed? Předpokládám, že nikoliv. Pro aplikace, kde zpracovávaná data putují mezi mnoha systémy různých dodavatelů je výborné vědět, že to co mi poslal systém XY je skutečně well-formed XML datový výstup a ne snůška chybových hlášení. A to nemluvím o tom, že by snad šlo SQL, CSV nebo TXT nějak rozumně validovat, tak abyste měl jistotu, že si do systému nezavlečete nějakou nepříjemnou chybu z důvodu nekonzistence či invalidity zasílaných dat. Můžete se na to dívat tak, že XML tu je jako univerzální jazyk výměny dat implementující standardní mechanismy kontroly jejich konzistence a validity. Tedy to, co by horko těžko v případě jeho neexistence programoval každý dodavatel samostatně a pravděpodobně ne zcela kompatibilně (potom, co by se analytici po mnoha měsících analýz domluvili na jednotné dokumentaci k formátu předávaných dat).

Váhám, jestli svůj příspěvek myslíte ironicky nebo vážně. Na otázky „kdo potřebuje“, s klidným svědomím mohu odpovědět, že já.

Pro vkládání matematického textu jako obrázku je prakticky použitelné pouze PNG. Jenže takový obrázek má spoustu nevýhod – nelze jej jednoduše editovat, vzhled nebude v souladu se zbytkem textu, nelze jej zvětšovat jako okolní písmo, není strojově zpracovatelný, není interní součástí stránky… (Pro generování matematických vzorců jako PNG obrázků doporučuji imgTeX. Mimochodem JPEG je na matematické vzorce naprosto nevhodný.)

SVG lze do HTML vložit pomocí elementu object, což je vhodné pro použití SVG jako vektorového obrázku. (Nyní jsou takto vytvořeny např. vlajky na wikipedii.) Jenže SVG má mnohem více možností, které lze použít jen pokud bude součástí XHTML stránky.

Flash se ani zdaleka nevyrovná SVG. Namátkou provázání se zbytkem stránky přes DOM, strojové zpracování (zejména indexování ve vyhledávačích a generování na serveru), jednoduchá editace, podpora 64b prohlížečů…

Když o tom teď přemýšlím, asi jste svůj příspěvek myslel vážně. Omluvou vám budiž nedostatečný rozhled, že jste se s řešením těchto problémů ještě nesetkal.

A proč by neměla? Člověk, který neumí napsat validní XHTML, to nemá a skoro určitě nebude psát ručně. Proč by, koneckonců, měl jazyk někoho nutit psát < a >, když v některých případech by si browser mohl tyto znaky domyslet, že?

A proc me ty osklive jazykarky na zakladni, stredni skole a vyskoe skole, dokonce pod hrozbou nutily dodrzovat syntaxi ruznych jazyku? Proc Vas prekladace tak strasne omezuji syntaxi pri programovani?

Co se mě týče, tak kdokoliv prohlásí, že není potřeba řešit strojový čas serveru si okamžite zaslouží pár facek...

Opravdu Vám přijde stravitelnější pro lidi muset například psát uvozorky na místa, kde jsou evidentně zbytečné?
Martine, pro průměrného člověka je jednodušší psát uvozovky všude, a ne si pamatovat, kdy je nemusí psát a kdy zase musí.

kdyz je tech dat opravdu hodne, hlida se strojovy cas i dnes

(zvlast kdyz se v ramci setreni zmrazi rozpocet na obnovu serveru)

Ehm, obvykle kdyz validujete XML, tak mate k dizpozici informace o polich, ktera obsahovat musi, o tech ktera muze, o jejich formatu .... a kdyz vam prijde snuska chybovych hlaseni, tak sice wellformed byt muze, ale asi tezko bude mit stejny format jako data, ktera ocekavate.

Komunikaci mezi ruzny systemy se castecne zabyvam a muzu vam garantovat, ze co fungovalo vcera bez problemu nebude dnes fungovat vubec. Trebas vas partner aktualizoval svuj IS, ktery ma novou genitalni funkcnost, a vam zacnou chodit data tak, ze v poli A je cislo a v poli B text, ac to jeste vcera bylo opacne.

Doporučuji pročíst až do konce, parsování už se tady probíralo a nemyslím si, že by jednoznačným výsledkem bylo, že parsování XHTML je jednodušší než parsování HTML.

I když se tváříte, že XHTML je zlo, tak není. Na serveru je XHTML nezastupitelné kvůli snadnému spojení s dalšími X technologiemi. Je zbytečné, aby stejná tematika byla pokrývána dvěma různými doporučeními, proto si myslím, že by HTML mělo být označeno za překonaná ve prospěch XHTML.

Bohužel pokroku bezdůvodně brání některé webové prohlížeče a jejich tvůrci. Posílání s XHTML se špatným MIME považuji v těchto případech za vyhovující a funkční kompromisní řešení. Na takto poslané stránce by se pochopitelně měla objevit výzva k upgradu prohlížeče.

Stále mně dlužíte odpověď, jak chcete HTML kombinovat s SVG (vektorovou grafikou) či MathML (matematickými vzorci).

Vsichni jste vedle :-). Sledovat narocnost na hw neboli vykon je bylo a bude nutne vzdycky. Co se meni je vyhodnoceni ziskanych poznatku. Kriteriem jsou penize. Je levnejsi upgradovat hw (treba upgrade z 1GB na 2 GB ram) nebo vyvijet program o tyden dele z duvodu pametovych optimalizaci? Na kolik prijde tyden prace tymu programatoru a na kolik unen upgrade? A budou mit ty programatori kdyz tak na praci neco jineho, nebo je budu platit tak jako tak? A jak na to specham? Co pro me bude mit nejvetsi ekonomicky prinos?

Abych na to jako manager dovedl zodpovedne odpovedet, musim mit relevantni udaje a tedy i znat vykon/pozadavky aplikace.