Python jako systémový skriptovací jazyk

Autor se v článku na svém blogu zabývá použitím Pythonu jako skriptovacího jazyku pro systém a porovnává ho s BASHem. Jako jeden z důvodů pro použití Pythonu popisuje vznikající knihovnu interpipes, která umožňuje použít v Pythonu "roury" tak jak je známe ze shellu.

25.12.2009 13:28 | Martin Stiborský | Zajímavý článek

Komentáře

[Milan Lajtoš]

Odporúčam sa pozrieť na linuxové distro Pardus, ktoré má init skripty písané v Pythone a celkovo si myslím, že je to jedna z naj distribúcií, ktoré nejdú podľa tradícií.

[Amarok]

To bych do Turku teda nerekl :) Pockam si na live-cd a zkusim, podle www stranek to vypada zajimave.

[Pemnic]

Tak ten priklad s find a xargs je presne vec, kterou neumim resit.

udelam si podivne pojmenovane soubory:

touch ' a : '

touch \'\"b

jak mam korektne napsat "find | xargs program"? (program nechci poustet jednotlive ale na co nejvetsi mnozinu vstupu kvuli tomu, ze jeho inicializace trva dlouho).

Nikdy mi nebylo jasne, proc programy nemaji ruzne vystupy pro zobrazeni uzivateli a pro strojove zpracovani (respektive proc zobrazeni uzivateli neni vicemene libovolnou /rozumej uzivatelsky definovanovatelnou/ transformaci strojoveho vystupu).

Vzdyt unix ma byt postaven na programcich, jejich spojenim lze udelat velke veci. Problem je, ze se mi nezda, ze by bylo neco udelano proto, aby vstupy a vystupy sly dobre napojit i tehdy, pokud nejsou trivialni (musi se poradat sedove orgie, z toho pak plynou chyby).

[Josef Kufner]

fint -print0 | xargs -0

Ruzne vystupy programy mají, viz funkce isatty() a barevné zvýrazňování u ls a dalších programů.

[Amarok]

Je nutna oprava v clanku: iterpipes misto interpipes.

Jinak i pro jednoduche shell skripty (> 5 radku) pouzivam vetsinou uz jen Python, mohu doporucit (hlavne pokud nekdo neumi dobre bash a musi se tedy stejne prohrabavat dokumentaci).

[Robo]

ja v praci na unixe zase perl; ten shell co tam na tych strojoch je (ksh), je otras a ne-GNU utility saju

[R]

Videl som skript, co robilo nejake prasa, co nevie ani bash ani python. Bolo to v pythone, vygenerovalo to bash skript a ten spustalo, malo to mozno 200 riadkov. V skutocnosti by stacilo asi 5 riadkov v bashi.

[Ruža Becelin]

>>> So, come on, people, we are in the 21st century, and shell scripting sucked in the 20th already.

Tenhle pristup se mi nelibi, az me budou distribuce nutit skriptovat v Pythonu, pujdu delat neco jineho

Nahrazovat UNIXovou filozofii malych jednoucelovych utilitek monolitickym Pytnonem je podle me cesta do pekel, chyba v klicovych knihovnach Pythonu muze v tomto pripade srazit system na kolena. Navic to buduje zavilost instalace na Pythonu.

Je to pouze muj nazor, ale myslim si, ze systemove veci se maji resit systemovymi nastroji, pokud je BASH moloch, muzeme pouzit jiny shell, ale ne Python s nestabilnim API.

[AsciiWolf]

+1

[kouby]

Nestabilni API. To me take hned trklo.

..a ve verzi Python 4.x+ prepiseme vsechny startovaci skripty a balickove skripty znovu od zacatku

[xurpha]

holt některý lidi nemaj nic jinýho na práci, než dělat pýčoviny

[vencas]

To je vtip že velmi zřídkavé backwards-nekompatible změny (tj. jedou za 10 let) označíte za nestabilní API? (Vedle možností u 2.6 lze zapnout varování o budoucí nekompatibilitě a utilitky 2to3, a několika letech další podpory 2.6 a 2.7).

Initscripty (a vůbec skritpy) se v debianu se taky nedávno přepisovaly, protože se změnilo /bin/sh na dash místo bashe.

[Michal Kubeček]

Uvědomte si, že bash je de facto jednosměrně kompatibilní přes 30 let zpátky. Z tohoto úhlu pohledu těch "jen jednou za 10 let" dostává úplně jiný rozměr.

Initscripty (a vůbec skritpy) se v debianu se taky nedávno přepisovaly, protože se změnilo /bin/sh na dash místo bashe.

Je-li tomu tak, je to chyba autora těch skriptů. Pokud jako specifikaci interpreteru napíše /bin/sh, pak by v tom skriptu žádná rozšíření bashe (ani jiného rozšíření Bourne shellu) neměl používat. Naopak, pokud je chce použít, měl by do specifikace napsat ten shell, který používá.

[thingie]

Jenže to si často nedokáže ohlídat ani člověk s velmi dobrou znalostí bashe i shellu obecně. Ten jazyk je prostě běs. Je to sice chyba autora, ale těžko ji někomu moc vyčítat. To je zoufale náročný úkol. mnohem více než by být měl.

[Semo]

Neprehanaj. Sh ma celkom jednoduchu syntax a celkom male moznosti. A mnozina oboch sa uz aspon 25 rokov nezmenila. Da sa to celkom lahko naucit. A cokolvek navyse znamena, ze ako shebang napises /bin/bash (alebo to co pouzivas). Na rozoznanie dvoch mnozin, kde jedna je podmnozinou druhej sa nemusis ucit obe, staci ked sa naucis tu mensiu (v tomto pripade vyrazne mensiu).

[thingie]

Já to ale fakt nepřeháním. Ohlídat si bashismy skutečně není žádná sranda. Kdyby byla, proč by kdy kdo psal ten dash?

[m;)]

mas to cele popletene ..

[Amarok]

Bash moloch kazdopadne je, ono vyjde snad nastejno, jestli pro skript spustim bash nebo python nebo perl, vse je to dost nafoukle, ale aspon je moznost vyberu a nemusim se prekousavat naprosto silenym syntaxem bashe (podle me jeden z nejhorsich jazyku vubec). S nestabilnim API jsem se zatim nesetkal, takze nemuzu posoudit.

[Robo]

bash ma IMHO jednoduchu a velmi prehladnu syntax, ktora sa velmi dobre cita (na rozdiel od mnoha inych jazykov)

[thingie]

No to je docela odvážné tvrzení.

[cronin]

Problem je, ze bash ma LEN syntax. Pristup "vsetko je string" je casto dost limitujuci.

[stybla]

limitujici iritujici :)

[vencas]

Doporučuju The UNIX-HATERS Handbook str. 147 (pdfková 185), přes 20 stran povídání o shellu a příkazu find. Krásné čtení.

[Michal Kubeček]

Akorát že tuhle knihu by v žádném případě neměli číst lidé, kteří mají tendenci uvažovat stylem "co je psáno, to je dáno". Ne že by něco z toho nebyla pravda, ale podstatná část argumentů už dávno neplatí a ještě větší je silně účelová a zavádějící. Za některé perly by se pak nestyděl ani Steve Ballmer.

[Robo]

hehe, no ako na zasmiatie je ta kniha fakt dobra; ale ako pisal kolega vyssie, plno veci uz neplati a za taku argumentaciu by sa nemusel hanbit ani Steve B.

[dustin]

Také jsem si tu kapitolu přečetl a také mi to nepřišlo zrovna aktuální. Např. pád shellu - za 10 let používání linuxu se mi to ještě nestalo.

[Michal Kubeček]

Bourne shell (a v důsledku tedy i bash) má především naprosto nekonzistentní syntaxi, která silně připomíná Čapkovu pohádku o tom, jak pejsek a kočička vařili dort (k dokonalosti ovšem tento přístup dotáhl až perl). Ke cti autorů bashe slouží, že se snažili o logičtější a konzistentnější postup, ale vzhledem k tomu, na čem museli stavět, uspěli jen ve velmi omezené míře.

Na druhou stranu si také nemyslím, že python plně nahradí shellové skripty nebo že by něco takového vůbec bylo rozumné.

[ikarlos]

+1

[pozortucnak]

Jů, já chci luu... nebo javascript...
A nebo jako ve windows scripting host.... VBscript

[dark]

Ten javascript by se mi líbil

[pozortucnak]

Nebyl by špatný... vzhledem k tomu že máme rychlé implementace jako V8...

[Grunt]

To není žádná rychlá implementace, to je pořádný kus hacku. To už radši zdrojáky v Céčku a před každým spuštěním na ně gcc.

[Ladicek]

Please elaborate.

[Grunt]

zdrojak.root.cz, V8 Documentation, SVN, Google, …

[Ladicek]

Prosím k tomu pořádnému kusu hacku. Konkrétně co je hackoidního na implementaci programovacího jazyka virtuálním strojem?

[Grunt]

Nic. Já se bavím především o v8 a o adresářích src/ia32,src/x64 a src/arm a jejich obsahu. Já jen tak k té implementaci.

[Ladicek]

Jo ták, to už tak u překladačů bývá, že část jejich kódu je spefická pro každou podporovanou cílovou architekturu. Jako třeba, hmm… popis registrové sady a volacích konvencí, alokátor registrů, generátor kódu, podpora pro ladění… a tak. Jestli je tam něco, co by na první pohled nemuselo dávat smysl, tak implementace regulárních výrazů. Jenže ty se na webu používají tak často, že jejich kompilace do nativního kódu je výborná optimalizace (pokud se dobře pamatuju, dělá ji i SquirrelFish).

Hm, takže hack. Virtuální mašiny s plným JIT překladačem a bez přenositelného interpretu nejsou nic nového. JRockit dělá pro Javu to samé, nějaká implementace Lispu s podobnou architekturou by se určitě taky našla (SBCL?).

[Grunt]

Jo ták, to už tak u překladačů bývá, že část jejich kódu je spefická pro každou podporovanou cílovou architekturu.

Až na ten detail, že ta část je nezbytná nutnost pro provoz, protože bez překladu do cílové architektury se to ani nehnulo. Jako by je ten jeden switch pro generickou architekturu zabil. No Jarídkove kecy tady snad nemusím připomínat. Až se budou dělat systémové skripty opravdu v JavaScriptu a bude je interpretovat v8, tak ani nechci domyslet co se stane, až budu chtít rozbíhat takové OpenWRT na nějakém MIPSu.

Hm, takže hack.

Má to ještě keš pro snapshoty toho vygenerovaného kódu. Přeloží se to jednou a při dalších spuštěních, pokud se skript nezmění se dává řízení čistě binární formě. To už je IMHO víc překladač než interpret. A tomu říkám ten hack (a určitě jich tam bude spousta i v samotném kódu).

Virtuální mašiny s plným JIT překladačem a bez přenositelného interpretu nejsou nic nového.

Ale rozhodně ani nic pěkného. IMHO se tim zabíjí jedna z výhod interpretovaných jazyků.

[Ladicek]

Tak o V8 snad nikdy nikdo jako o interpretu nemluvil (Teda jo, pamatuju se, že na místní wiki jsem to opravoval.) Ano, cachování přeloženého JavaScriptu se používá, pokud se dobře pamatuju, u základní knihovny (protože V8 má základní knihovnu implementovanou z velké části v JavaScriptu) to vede ke zrychlení asi tak o řád (ani to není žádná novinka, minimálně v Monu a v Suní Javě je něco takového taky) Nejdůležitější vlastností V8 je výkon. Což ho, pravda, rovnou diskvalifikuje při výběru "interpretu" systémových skriptů, s tím bych souhlasil – tam by se asi líp hodil ten SquirrelFish, který má čistě céčkovou (resp. GNU céčkovou) variantu. Na druhou stranu, who cares? Distribuce se systémovými skripty v JavaScriptu můžu s klidem existovat vedle těch se skripty v shellu.

[Grunt]

Tak o V8 snad nikdy nikdo jako o interpretu nemluvil

#96:

vzhledem k tomu že máme rychlé implementace jako V8...

A to stejné si myslím o Chromiu.

[Ladicek]

Čtu tu samou #96? To, co čtu já, obsahuje slovo interpret přesně… moment… ano, nulakrát. V8 je rychlá implementace JavaScriptu, ano. A Chromium je rychlý prohlížeč, to teda sakra ano. Když to má být rychlé, musí to být specializované pro konkrétní běhové prostředí (to ti potvrdí i Jarda se svým kreslítkem grafů či co to bylo ). Když to má být specializované, nemůže to být univerzální, to dá celkem rozum Jinak už celkem nevím, o čem je řeč; mně už je jasné, co ti na V8 vadí, a tobě je hádám jasné, že já to za vady nepovažuju, je to v oboru běžná praxe

[Ladicek]

Nemám rád Python, ale jako shell bych ho oproti bashi a podobným zvratkům vyloženě miloval. Obviously – jsem programátor a bash je jazyk pro magory, ne pro lidi zvyklé na nějaké zákonitosti. Možná Ruby by mi vyhovovalo víc, ale naučit se Python by mi snad netrvalo víc než pár měsíců. Zato bash neumím doteď, a to už jsem v něm pár skriptů napsat musel. Já jsem rozhodně pro.

[R]

Kopa ludi si mysli, ze vie programovat v pythone. A potom tie programy aj tak vyzeraju.

[cronin]

To plati pre lubovolny programovaci jazyk.

[Ladicek]

To určitě platí. Zkuste si ovšem namísto Pythonu do svojí věty vsadit bash – to dostává úplně nový rozměr. Začněte třeba zpracováním chyb.

[deda.jabko]

bash i python jsou jako prog. jazyky docela hruza... ale maji jednu nespornou vyhodu---bezi vsude. coz je jeden z duvodu, ktery me primel zabyvat se programovanim i v pythonu... sice neni to takovy zazrak, jak vsichni tvrdi, ... ale mam aspon pribliznou jistotu, ze kdyz dojdu k nejakemu unixovemu stroji, nakopiruji si tam skripty v pythonu, tak to pobezi... a ve srovnani s bashem, to pobezi aspon trochu svizne...

ale mohlo to byt horsi... moc nechybelo a na miste dnesniho pythonu mohl byt perl...

[thingie]

A no tak on ten perl 5 je taky relativně všude.

[pozortucnak]

Lua beží i na 16-bitových microprocesorech...

[pozortucnak]

Objektový shell pro Linux

[partizann]

No pokial viem tak postupne nove distra nahradzaju init scripty upstartom, takze uz tam nemusite mat hromadu bash/perl/python scripty. Inac ja uprednostnujem bash vseobecne na scriptovanie ako ine programovacie jazyky - lahsie sa mi pametaju mena a syntax binariek ako sed,awk,ls,grep,atd ako nazvy modulov a ich funkcii.

[Michal Kubeček]

No pokial viem tak postupne nove distra nahradzaju init scripty upstartom

To je dost optimistický výklad. Tedy optimistický z pohledu fandů upstartu.

[Miloslav Ponkrác]

Základní rozdíl mezi bashem a pythonem:

1) bash je navěky stejný shell, co napíšete jednou, to chodí (aspoň snaha)

bash nenutí čas od času programátory zahodit všechny skripty a napsat je znovu ve změněné syntaxi, aniž by jim to vůbec něco přineslo. ani nevykládá všem linuxákům a dminsitrátorům, že je skvělý nápad zahodit zpětnou kompatibilitu, přepsat vše od nuly (bez jakéhokoli benefitu pro ně) a zanést si tam znovu tím pádem chyby vyplývají z neodladěných skriptů

2) python si myslí, že vše to co bash nedělá může dělat. python považuje za skvělý nápad nekompatibilně změnit syntaxi a donutit v určitém časovém horizontu přepsat všechny python skripty na světě (aniž by to lidem přineslo vůbec nějaký benefit, když už to mají dělat). zpětná kompatibilita je nemoderní a výsměch, tak to propaguje pythonovská komunita včetně autora a samozřejmě vývoje pythonu v poslední době

Z důvodu 2) bych osobně nikdy nenasadil python jako systémový jazyk, ani jako amisnitrátorský jazyk a nerval bych ho na skripty. Není to seriózní jazyk, bez záruk zpětné kompatiblity je to hračka.

[Marián Kyral]

Mám takový pocit, že oba body jsou stejné (jen trochu jinak napsané)

[miso]

Naviac pisane viac emotivne ako racionalne (Python si mysli)

[Miloslav Ponkrác]

Zkuste konkrétně napsat, kde jsem napsal něco co není pravda.

Nehleďte na formu, ale na obsah sdělení.

Před několika lety zkrátka proběhla módní vlna zvaná, překopeme nekompatibilně programovací jazyky a přehnala se přes Perl (iniciátor té vlny), Python, Ruby. Všechny jazyky, které uvěřili tomuto módnímu výstřelku to odnesou snížením své používanosti a rozšířenosti.

To, že se systémovým jazykem nestal Perl, jak tu kdosi prohlásil, za to může Perl sám, že nastoupil do této vlny a tím zastavil rozšiřování Perlu.

Python nastoupil do této módní vlny přesně v okamžiku, kdy se Python začala zajímat obrovská spousta lidí a začal se objevovat a rozšiřovat. Díky překopání řada lidí od Pythonu ustoupila, zabrzdil se vývoj i rozšiřování – a Python sám si podetnul svůj růst.

Ruby je v zásadě dosti okrajový jazyk (procentem používanosti), řekněme před růstem, takže ten to relativně může ustát asi nejlépe.

[miso]

Nechcem sa rozpisovat, mam radsej vecnu argumentaciu.

[Miloslav Ponkrác]

Mě by zajímalo, co je podle Vás věcná argumentace, když ne to co píšu. Můžete se třeba rozepsat a dát příklad věcné argumentace? Tedy za vysoce nepravděpodobného předpokladu, že nějaké věcné argumenty vůbec máte.

[miso]

Mě by zajímalo, co je podle Vás věcná argumentace, když ne to co píšu. Můžete se třeba rozepsat a dát příklad věcné argumentace? Tedy za vysoce nepravděpodobného předpokladu, že nějaké věcné argumenty vůbec máte.

Ale kludne . Vecna arguemtacia je zhrnutie faktov bez snahy ovplyvnit usudok. Toto evidentne nie je pripad vasho prispevku. Mna napriklad nezaujima Vas traumaticky zazitok s Pythonom (ktory sa s vysokou pravdepodobnostou stal). Prosim neberte ako osobny utok ani nechcem byt ironicky, citam to medzi riadkami.

Python po 10 rokoch zmenil cast API (podobne ako napriklad Qt) a migracne skripty nefunguju na 100%.

Takto podla mna ma vyzerat vecna argumentacia. O nestabilnom API sa mozme bavit, ak vieme, ze sa v buducnosti necakane zmeni. Tu by som suhlasil, ze nemame zaruku stability (ani potvrdene ani vyvratene).

Vidim ze reagujete trosku podrazdene (...za vysoce nepravděpodobného předpokladu, že nějaké věcné argumenty vůbec máte) a do debaty uz vstupujete s tym, ze mate pravdu prave vy. Preto dalsie pokracovanie v tomto threade vidim ako zbytocne. Snad sa pocasie umudri a bude sa dat lyzovat ...

[thingie]

To s tou módní vlnou by se při použití trochu barvitějšího jazyka dalo směle zařadit do Starého zákona jako první (no, kéž by, už jsme jich četli) kniha Ponkrácova. Módní vlna je sice v podstatě mytologie ať už to řešíme tak či onak, ale tam v tom příspěvku je fakt postavená na vodě. Bez citací, faktů, dat.

[mj41]

Má reakce je v Zpětná kompatibilita a dynamické programovací jazyky na abclinuxu.cz/blog/mj41.

[cedrik]

Ještě bych doplnil: Otevřené až vulgární odsuzování některých (čti většinu) pythonistů autory těch skriptů, kteří si dovolili napsat něco v jiném jazyce, zejména v Perlu. S tím čeho jsem se setkal ze strany fanatických vyznavačů pythonu dodnes nemohu uvěřit. Ano, používám pro skripty (da)sh a perl (a občas i grep a sed) a to i pod Windows.

Asi to přichází s užíváním pythonu, protože jinak jsou to normální a většinou i tolerantní lidé.Tak a teď si mě třeba kamenujte.

[Nick]

Tady se někdo opakuje a začíná být už dost nudný. Je nutné smířit se s tím, že spousta problémů se dá daleko jednodušeji a elegantněji řešit např. v Pythonu než v tom nesmyslně složitém C++ i za cenu, že se po nějaké dobu kód upraví, podle nové syntaxe, pokud nebude vyhnutí.

Za sebe bych jako hlavní systémový jazyk chtěl Luu, která je geniálně jednoduchá a její implementace běhá v dané kategorii neskutečně rychle při nízkých systémových nárocích. Navíc je její vývoj velmi konzervativní, teda ve srovnání s Pythonem určitě. Bohužel není v *nixových prostředích tak rozšířená jako Perl nebo teď i Python. Asi nedostatek hype

[tom]

Lua neni pruzna, zkuste si v lue napsat treba program, ktery otoci radky vsech plain souboru s prvociselnou delkou, predanych mu jako parametry. V perlu to zabere tak minutu a vejde se to na jeden radek

[miso]

To by som rad vedel, ci by potom aj niekto dokazal "uhadnut", co ten perl one-liner robi

[Jakub Lucký]

to se lépe dělá reverzním inženýrstvím...

[Miloslav Ponkrác]

Tady se někdo opakuje a začíná být už dost nudný. Je nutné smířit se s tím, že spousta problémů se dá daleko jednodušeji a elegantněji řešit např. v Pythonu než v tom nesmyslně složitém C++ i za cenu, že se po nějaké dobu kód upraví, podle nové syntaxe, pokud nebude vyhnutí.

Ach jo, na blbosti je třeba upozorňovat i opakovaně. Já vím, že řada lidí to nepřijme, ale moudří, kteří tu třeba ani nediskutují se poučí a ušetří si spoustu starostí.

Poznámka o C++ je něco co je v tomto vlákně off topic.

Jinak už vidím, jak třeba milión, nebo deset miliónů řádků kódu upravíte podle nové syntaxe. Ono to může také stát třeba miliardu dolarů tahle sranda.

A zejména enterprise svět (a nejen ten) potřebuje záruky, že šaukle se zpětnou kompatibilitou se mu pod rukama dít nebudou, protože jednak on jen tak miliardy na tyhle srandy nemá, a jednak potřebuje aby to fungovalo, což se po změně syntaxe zaručit nedá.

[tom]

100$ na radek tezko.

[Miloslav Ponkrác]

Je třeba vše zkontrolovat, prohnat novými testy, znovu označit kód za alfa/beta verzi, odladit případně nalezené chyby, znovu výsledek prohnat testy. Pokud se nějaká chyba přeleje do verze distribuované zákazníky, což se v 10 miliónech řádcích kódu vždy stane, pak je oprava chybu daleko dražší, navíc znamená i případnou ztrátu na jméně a pověsti firmy.

Něco jiného je psát program o desítkách tisíc řádkách, což v podstatě je sranda, ale velké projekty se píší a vyvíjí jinak. Je to dražší, protože musíte organizovat projekt jinak.

Všechny ty vývojáře, testery, buildery, manažery musíte platit. Musíte platit kanceláře, otop, elektřinu.

Ona miliarda v nákladech na projekt o deseti miliónech řádků, který musíte celý znovu projet, zkontrolovat a nepovažovat žádnou část za stabilní od té chvíle není přehnaný odhad.

[Grunt]

Je třeba vše zkontrolovat, prohnat novými testy, znovu označit kód za alfa/beta verzi, odladit případně nalezené chyby, znovu výsledek prohnat testy,…

A nebo co třeba zkusit si dát pár piv a pustit se do práce? Proboha, snad se tu bavíme o systémových skriptech a ne o Black-Box^© Enterprise Edition, ne?

[Libor Chocholaty]

Enterprise svet vam zvysoka kasle na nove verze nejakeho jazyka/programu. Jedou je neco odladene v Pythonu 1.2.3 tak to v tom bude behat na veky veku, amen. Uplne stejny problem byste totiz v enterprise svete mel i s bashem ci jinym interpretem.

Jakmile by tech vasich milion ci deset milionu radek kodu bylo odladeno a OTESTOVANO v bashi 2.01beta, tak si nikdo, kdo ma pud sebeachovy, to nedovoli pustit v produkcnim prostredi v bashi 3.02. Proto, ze jakakoli chyba by se nejdriv posuzovala, zda to bezi ve spravnem prostredi a pokud ne, pak by se zjistovalo, kdo schvalil zmenu bez otestovani a posveceni PV tymem.

Proste v realnem enterprise svete vami zminovana moznost nemuze prakticky nastat. Protoze jakakoli zmena behoveho prostredi si vyzada kompletni pretestovani produktu. Bez ohledu na to, zda se do kodu sahne nebo ne.

[Amarok]

Pane Ponkraci, bod 2 tady na abc stale opakujete dokola :) Nevim co je na tom tak spatneho, kdyz vyvojari Pythonu zacli logicky sjednocovat a predelavat nektere casti jazyka po nekolika letech vyvoje (ano, meli to delat hned od zacatku, ale lepsi ted, nez nikdy). Tvrdit, ze se jim ted uz neda verit a ze verze 4 bude urcite zase naprosto zpetne nekompatibilni k verzi 3 je ciste Vas nazor, ja si to nemyslim. Kazda nova hlavni verze jazyka prinasi spoustu novinek, takze se budto programatori svezou na vlne nebo zustanou u stare verze.

Mimochodem ma tady nekdo zkusenosti s konvertovanim Python skriptu pomoci te utilitky 2to3? Zajimalo by me, jestli je to opravdu tak strasne moc prace, jak pan Ponkrac tvrdi. Ja zacinam rovnou s verzi 3 (+ minimum 2.6), takze me cely ten proces jaksi minul - napr. Python od verze 2.6 povoluje uz psat "print" ve stejnem syntaxi jako Pythonu 3, cili je videt, ze ten prechod tak prudky nebyl.

[Miloslav Ponkrác]

No a co, že se opakuji?

Vidím hodně špatného na jazyce, který po 17 letech stabilní existence se rozhodl udělat něco, co ho vyřadilo ze seriózních jazyků.

Je to čistě můj názor, a já ho dávám ostatním k tomu, aby si zvážili, jestli chtějí toto absolvovat.

Nehodlám dále argumentovat, protože:

a) ta utilitka na převod nefunguje na 100% (tvrzení přímo autora Pythonu, kdybyste chtěl napadat mě, stejně tak jako základní top komunity Pythonu). tudíž stejně je převod ruční práce, a nikdy si nemůžete být jistí, co za chybu to přinese.

b) řada pythonu 2 samozřejmě po pár letech skončí (tak je to plánováno v python vývoji) a už daleko dříve řada knihoven přestane být v praxi pro to portována

c) tvrzení, že nutnost přepsat a znovu odladit všechen kód (protože po změně syntaxe jazyka se jakýkoli odladěný kód musí znovu považovat za neodladěný a je nutné ho znovu testovat) je príma a super je stejně blbé jako tvrzení zahoďme linux kernel a napišme a odlaďme ho znovu

Každý jazyk, který se udržel delší dobu vždy splnil jednu podmínku: zpětná kompatibilita pro něj byla zákon a o tom se nediskutuje.

Zkuste si třeba v Javě prosadit myšlenku totální změny základní syntaxe (zpětně nekompatibilní změny) některých základních konstrukcí Javy. Budete vykopán a skopán ze schodů dřív, než to dořeknete.

I hloupé jazyky jako C, Cobol, Fortran, Ada, Java, C++ a další se používají na seriózní vývoj mimo jiné právě proto, že zpětná kompatibilita je něco o čem se nediskutuje. Jakýkoli zásah do této kompatibility musí být velmi vážně a tvrdě zdůvodněn.

Důvodem, proč Python může zpětnou kompatibilitu bagatelizovat je ten, že se v něm nepíše nic důležitého. Takže na tom ani moc nesejde, jestli Python potopí sám sebe, je to fuk. A ani se v něm díky Pythonu 3 a zrušení zpětné kompatibility obecně důležité programy psát nebudou, protože ten člověk, co by Python do toho pustil by musel být blázen.

[Amarok]

Trochu si protirecite. Python dle meho nazoru nikdy nebyl staven na to, aby se v nem delaly projekty s delkou 10 milionu radku (jak uvadite v prikladu nekde o vlakno nahore), zaroven ale pisete, ze se v P. nepise nic duleziteho. Na obrovske projekty mame Javu, Adu apod., u nich je samozrejme naprosto nemyslitelne zrusit zpetnou kompatibilitu.

Pro ucely, pro ktere byl Python vytvoren, se bude v budoucnu prece hodit minimalne stejne dobre jako doposud, obliba napr. u webhostingu stoupa (kdyby nebyla poptavka, tak by zcela zmizel). Programatori nejsou sochy, tudiz se kazdym rokem "rodi" dalsi a je jim uplne jedno, jak vypadal Python pred par lety. Kdyz se bude dobre hodit na reseni aktualniho problemu (+ bude dostatecne rozsiren, bude pro nej dostatek knihoven atd), tak se eventuelne pouzije.

[Miloslav Ponkrác]

Python dle meho nazoru nikdy nebyl staven na to, aby se v nem delaly projekty s delkou 10 milionu radku (jak uvadite v prikladu nekde o vlakno nahore), zaroven ale pisete, ze se v P. nepise nic duleziteho.

To je pravda. Ani autor Pythonu se nesnaží tvrdit, že Python je programovací jazyk a důsledně používá termín skriptovací jazyk.

Nicméně problémy se zrušením zpětné kompatibility jsou. Jistě nepodstatné v projektu s 50 řádky zdrojového kódu a v projektech sestávajícím z jednoho modulu, v tom se také shodneme

Pro ucely, pro ktere byl Python vytvoren, se bude v budoucnu prece hodit minimalne stejne dobre jako doposud, obliba napr. u webhostingu stoupa (kdyby nebyla poptavka, tak by zcela zmizel).

Mimohodem, i web už dostal facku, která ho upozorňuje, že zpětná kompatibilita je důležitá. Největší pokus zrušit zpětnou kompatibilitu, jaký kdy u webu nastal – tedy XHTML – totálně zkrachoval. Nemohl jinak. Svět se opět vrátil k HTML a pro XHTML skončil vývoj a W3C přiznala, že XHTML je a byla slepá větev. Já to říkal několik let, že XHTML nedopadně dobře a říkal jsem v době, kdy XHTML bylo víc, než Bůh a na vrcholu své slávy.

Selský rozum je nejlepší prognostik.

I webu se týkají podobné zákonitosti a je čím dál těžší pro kohokoli rušit webovou zpětnou kompatiblitu.

Programatori nejsou sochy, tudiz se kazdym rokem "rodi" dalsi a je jim uplne jedno, jak vypadal Python pred par lety.

Problém je, že kvalitu jazyka mimo jiné dělají i knihovny, a to i externí. POkud budete vše překopávat, pak nikdy nebudete mít tak efektivní jazyk. Jednak budete mít plus mínus plain jazyk, a jednak efektivita kompilátoru/interpretru bude mizerná. Viz Python, který má asi nejpomalejší interpretr co existuje.

Kdyz se bude dobre hodit na reseni aktualniho problemu (+ bude dostatecne rozsiren, bude pro nej dostatek knihoven atd), tak se eventuelne pouzije.

Což jsou věci, které jsou trochu v rozporu s překopáváním, viz výše.

[Amarok]

Jen kratce k tomu XHTML. Pokud jste cetl to same jako ja a neprokopal se ale uz k dalsim informacim (jako ja), tak jste zrejme byl oklaman informaci, ze XHTML skoncilo. Ano, skoncilo XHTML 1.1 a vyvoj v teto vetvi dal nepokracuje, nicmene se existujici zaklad prebira do (X)HTML 5, ve kterem se dal bude moci psat v syntaxi XHTML, bez cehoz se taky nemuzeme uz obejit (klicove slovo XML). Ze se rozpadla skupina vytvarejici XHTML 1.x podle me neznamena, ze byl projekt spatny, byl proste jen nadbytecny (2x se delala skoro ta sama vec). V (X)HTML 5 nastalo nekolik zjednoduseni a pro webdevelopery je cely vyvoj jedine pozitivni. Predelani stranek bude vetsinou znamenat jen zmenit hlavicku, nejdulezitejsi zmeny a novinky jsem uz vyzkousel a vse OK.

[Ladicek]

Jen krátce k tomu XHTML. XHTML 1.0 byl přepis HTML 4 do XML a v XHTML 1.1 byly odstraněny deprecated elementy (plus nějaký pokus o modularitu, to jsem nikdy moc nekoumal). Pak si pár chytrých hlav ve W3C řeklo, že je na čase to zahodit a začít od začátku – a tak vzniklo XHTML 2. O tom, hádám, mistr Ponkrác mluví, protože jednou z klíčových vlastností XHTML 2 byla nulová zpětná kompatibilita. Trvalo to dlouho, ale s tím, jak se začalo hlasitěji mluvit o HTML 5, muselo W3C uznat, že XHTML 2 je slepá vývojová větev. Odtud taky pochází to krásné 5 > 2 XHTML 5 je jen XML serializace HTML 5, podle mne nic moc důležitého, sice jsou lidi, kteří staví weby na XML technologiích, ale svůj masochismus si musí každý vyřešit sám

[thingie]

No, tak on to hlavně byl úplně nový jazyk, to bych zase nesrovnával. A jako důvod krachu bych neuváděl tolik nulovou kompatibilitu (to ostatně jednou přijde tak jako tak), jako spíš neschopnost přijít s něčím jiným, než nedokončeným a věčně měněným návrhem úplně nového divného jazyka, o kterém nikdo soudný nemohl mít pocit, že ho vlastně potřebuje.

[Ladicek]

Důvodem krachu bylo to, co jsi napsal v poslední větě, určitě – já nulovou kompatibilitu uváděl jako důvod, proč XHTML zmiňuje M. P.

Úplně nový jazyk to byl – ale proč mu potom říkali XHTML 2? Možná kdyby se Python 3 nejmenoval Python, tak máme od podobných debat pokoj…

[okbob]

Pokud je mi známo, tak v Javě se několikrát objevily zpětně ne zcela kompatibilní verze, a totéž se stalo i v .NETu. Snad jediné zpětně 100% kompatibilní prostředí je Fortran. Python má smůlu v tom, že zrovna si jej oblíbil a následně zavrhl Miloslav Ponkrác.

[Amarok]

Jee, zdravim :) To je nahoda. Zrovna mam na stole vytisk Vasi prirucky PostgreSQL, moje aktualni domaci zabava...

[Miloslav Ponkrác]

v Javě se několikrát objevily zpětně ne zcela kompatibilní verze, a totéž se stalo i v .NETu

Za které se Javisti styděli a považovali je za špatnou a velmi špatnou věc. Tudíž komunita javistů je zdravá a ví, co je potřeba. Neviděl jsem nikdy fanatické jásání pro překopání jazyka. Navíc Java se snažila jakýkoli zásah do kompatibility (a byly to vždy jen drobnosti) dostatečně obhájit benefity, které to přináší.

Na rozdíl od Pythonu, který překopal syntaxi a nulový benefit z toho. Prostě autor má jiné estetické cítění syntaxe, než je v Pythonu a tak to překopal. Vždyť je to jeho hračka, tak co by to neudělal. On přeci nemůže za to, že v tom někdo programuje, to je jeho problém.

Python má smůlu v tom, že zrovna si jej oblíbil a následně zavrhl Miloslav Ponkrác.

Python má smůlu v tom, že Ponkrác nebude lhát, a po 25 letech zkušeností, co se pohybuje kolem programování, nebude mlčet o módních vlnách, které dopadnou špatně.

Viz třeba odstavec výše – Ponkrác nemá moc rád Javu, nicméně nemá problém ocenit kladný přístup tohoto jazyka.

[okbob]

Tady si dovolím nesouhlasit.

Ty změny, které způsobovaly nekompatibilitu přišly neohlášeny, neprodiskutovány (byla to mnohem větší katastrofa než ukončení 2.x řady Pythonu) - bylo to v době, kdy byl vývoj Javy čistě interní záležitostí Sunu. Změny v Pythonu byly diskutovány v komunitě s dlouhodobým plánem přechodu.

Nikdo po Vás nechce abyste lhal. Na druhou stranu, a je to možná pouze můj dojem, mám z vašich zápisků pocit, že si na něco uděláte svůj názor, který pak prezentujete pomalu za pravdu boží bez ohledu na skutečnost, bez ohledu na vývoj, bez ohledu na souvislosti - a je jedno jestli se jedná o Python, PostgreSQL nebo SQLite.

V případě Pythonu to neumím natolik posoudit jako v případě PostgreSQL nebo SQLite, kde si myslím, že obě databáze jste si letmo vyzkoušel před třemi roky a od té doby jste je neviděl - nicméně s oblibou je komentujete.

[Filip Jirsák]

Ty změny, které způsobovaly nekompatibilitu přišly neohlášeny, neprodiskutovány (byla to mnohem větší katastrofa než ukončení 2.x řady Pythonu) - bylo to v době, kdy byl vývoj Javy čistě interní záležitostí Sunu.

Který to byl přibližně rok nebo verze Javy? Marně přemýšlím, co konkrétně myslíte.

[okbob]

myslím, že se jednalo o verze 1.0, 1.1 - možná 1.2.

Z dnešního pohledu se asi o katastrofu nejednalo - když vezmu v úvahu téměř pravidelné problémy PHP - spíš to bylo asi poprvé, kdy s určitým vývojovým prostředím přišlo varování ohledně problémů se zpětnou kompatibilitou.

Tehdy jsem to vnímal ostřeji, nejspíš proto, že jsem si s Javou letmo hrál - v podstatě jsem si nedovedl představit, že bych dokázal překopávat svoje zdrojáky (i když jsem jich měl minimum), nechápal jsem důvody, a koneckonců mi to bylo jedno.

Napadá mne ještě ostřejší zlom - a to přechod od COMu k .NETu - přechod od Visual Basicu k VB.NETu. Tehdy jsme z toho byli docela v šoku - v podstatě nikdo nedokázal pochopit proč Microsoft, když konečně odladil COM, s COMem končí. No a co se stalo - nic. Staré věci se dotáhnou v původních prostředích, nové se začínají v nových.

V podstatě až na výjimky většina aplikací zastará dřív morálně než technologicky. A pokud potřebujete vytesat kód do kamene, pak je tu C, C++ a Fortran.

[Filip Jirsák]

Jediné, co mne napadlo, byly právě tyhle verze – ale i tam se jednalo pouze o označení metod a tříd jako zastaralých, ale ty metody a třídy jsou v API dodnes. Na úrovni zkompilovaného kódu by měla být Java kompatibilní od počátku do dnes, na úrovni zdrojových kódu občas vzniknou nekompatibility rozšířením nějakého rozhraní (které pak musíte ve svém kódu doimplementovat) – to je u Javy považováno za „vážné“ porušení zpětné kompatibility. Ale to se pořád týká knihoven, ne samotného jazyka.

[Ladicek]

Tak na úrovni samotného jazyka, říkáte? Co takhle klíčové slovo assert ve verzi 1.4 nebo klíčové slovo enum ve verzi 5?

[Filip Jirsák]

No vidíte, na ty jsem úplně zapomněl, protože s tím nikdy nebyl žádný problém. Nicméně i to se týká jen zdrojového kódu, a kód napsaný pro verzi 1.3 můžete pořád spustit pod JRE 1.6 a pořád jej můžete s JDK 1.6 přeložit jako kód verze 1.3. Což samozřejmě není zásluha jazyka, ale platformy a toho, že můžete určit verzi Javy použitou ve zdrojáku a běhové prostředí umí interpretovat zatím všechny verze zpět.

[Ladicek]

protože s tím nikdy nebyl žádný problém

Nikdy jste neměl proměnnou nazvanou enum?

[dark]

který pak prezentujete pomalu za pravdu boží

a někdy se jedná opravdu o ničím nepodložené bludy.

...

Já osobně jsem od pythonu upustil, ale ty změny v trojkové řadě se mi zdají jako dobrý směr, hlavně unicode.

[Michal Kubeček]

Tak, jak je zprávička formulovaná, vyznívá dost divně. Převyprávím-li to volně, říká zhruba toto: "Jeden z důvodů, proč místo A použít B, je to, že B právě implementoval něco, co měl A hned od začátku (což bylo mimochodem dávno před vznikem B)."

[stybla]

neda mi to - ROFL

[JS]

Me by se spis libilo, kdyby nekdo predelal celou tu Unixovou koncepci jednoduchych utilit ovladanych z prikazove radky, ale misto vstupu a vystupu do textu by umely zrat nejaka strukturovana data (treba Lispove s-vyrazy, nebo Pythonske datove struktury, nebo JSON, co ja vim). Proste, aby se clovek nemusel stale parsovat s textem a resit escapovani.

Takze, kdyby nekdo timto zpusobem navrhl novou sadu takovych malych utilit, byl by to rozhodne pokrok.

[Semo]

Az budu maily chodit ako Lispove vyrazy, az tak budu servirovane HTML stranky, a az tak ludia budu zapisovat text, potom to bude mat vyznam. Dovtedy budu nastroje na spracovanie obecneho textu daleko uzitocnejsie ako Lispovsky shell.

[Radek Miček]

Vždyť není problém napsat utilitu, která z HTML/mailu vytvoří stromovou strukturu, s níž pak další programy budou pracovat.

[Libor Chocholaty]

Já ten povzdech chápu, protože textový výstup vhodný pro člověka nebývá příliš často vhodný pro strojové zpracování. Vemte si třeba locales, to je vám schopno těmi textovými výstupy pěkně zamíchat...

[Ondrej 'SanTiago' Zajicek]

Nicmene lispovy shell umi bez potizi pracovat i s textem. Oproti tomu 'unixovy' shell neumi pracovat se strukturovanyma datama.

[okbob]

Všiml jsem si, že admini neradi programují - nicméně za programování neberou lepení skriptů v bashi. Tím si vysvětluji, proč se skriptování na systémové úrovni nikdy nerozšířilo ve světě Microsoft Windows, kde byl k dispozici vbscript, který byl sice jeden z nejhorších jazyků - co se týče syntaxe a diagnostiky, nicméně ve spolupráci s COM se toho dalo udělat docela hodně. Problém COMu je ovšem v tom, že s ním dokáže pracovat už jen programátor. COM nemá "human interface". Kdežto skripty v bashi v podstatě lepí dohromady standardně volané aplikace, kde si stačí přečíst uživatelský manuál. V tom je genialita shell skriptů a zároveň omezení - je to interface pro neprogramátory.

[JS]

No, nechtel jsem to rozepisovat v puvodnim prispevku, ale podle me by nebylo zas tak obtizne navrhnout ten shell tak, aby se vystup do terminalu vypisoval lidsky a nekam jinam (do pipy) strukturovane. Tak by se "vlk nazral a koza zustala cela".

Jinak, nevidim v te necitelnosti zase az tak zavazny problem. Vezmete si takove netpbm - to je mocny nastroj na zpracovani obrazku v radce. Kdyby bylo mozne zpracovavat obrazky jako strukturovana data, napriklad volit operace nad nimi podle jejich vlastnosti, byl by jeste mocnejsi.

Proste, libilo by se mi, kdybychom misto cut, sort, uniq, sed a podobnych prikazu meli treba prikazy na setrideni nejake posloupnosti zaznamu, jejich selekci a prehazeni a podobne (map, filter a reduce). Treba pro netpbm by byla utilita ktera z posloupnosti vstupnich obrazku vytvori posloupnost zaznamu s jejich velikostmi, atd. Mozna by si na zacatku zpracovani mohly ty utility vymenit informaci o tom, v jakem formatu si poslou data. Je to IMHO proste prostor k inovaci.

[okbob]

Pak je otázka, proč rovnou nepoužít klasický programovací jazyk - když jsou k dispozici strukturovaná data. Primárně by se musely změnit aplikace, které by museli umět poskytnout a přijmout data ve strukturovaném formátu. A tady si myslím, že by byla první překážka - kdo určí ten vhodný formát? XML, JSON? Budou aplikace, které se domlouvají na formátu ještě ty jednoduché jednoúčelové aplikace respektující tradici unixu?

[JS]

No, klasicke jazyky nejsou integrovany se shellem. Nejde v nich pracovat se soubory (tak snadno), nemaji pipy a podobne.

Format, jakym se mezi sebou domluvi ty utility by urcil autor toho hypotetickeho shellu (a tech zakladnich utilit, protoze v jistem smyslu lze unixovy shell a utility povazovat za jednotny system). Ja osobne bych se binarnimu formatu nebranil (a naopak dost bych se branil XML), protoze zde jde o vymenu dat mezi aplikacemi; ale hodne lidi by se mnou asi nesouhlasilo.

Co se tyce jednoduchosti utilit, pointa Unixu je IMHO spise v jednoucelovosti (ostatne, staci se podivat, co umi obycejne ls pri formatovani vystupu). Nikde neni napsane, ze treba takove ls nemuze poslat nejdrive informaci typu "nasleduje sekvence zaznamu nezname delky, kazdy zaznam obsahuje retezec filename, cislo uid a gid" (napriklad). A pak by ls uz posilalo jednotlive zaznamy. Takze by se prislusna prijimaci utilita, napr. sort, mohla rozhodnout, ha, chci to tridit podle pole filename. Stejne tak by bylo dobre mit utilitu, ktera vam vypise, v jakem formatu dana data prichazi, nebo dokonce pekne (treba tabulkove) vypise ta data.

Naopak, ortogonalita a jednoduchost by se mozna zlepsila, protoze misto toho, aby dnes ps i ls musely umet tridit zaznamy, v novem systemu by na oboji stacila utilita sort.

[happy barney]

ako program rozlíši, čo je za tou "pipe" ? ... príklad: program | less
áno, dá sa to vyriešiť ... napr ls --output-format=xml. Každý program však má vlastnú množinu datových typov (rôzne namespaces), každý formát má rôzne utility ...

Navyše, programy by medzi sebou tak či onak fungovali cez serializáciu, t.j. textový interface ... nikto vám nebráni vytvoriť si vlastnú sadu nástrojov a k nim input/output filtre

Môžete argumentovať tým, že by to vlastne neboli programy, ale len dynamicky načítavané knižnice, no tým zase stratíte oddelenie na úrovni procesov. Všetko má pre a proti.

[JS]

Moje predstava byla takova, ze kazda utilita by mela svuj vlastni format vystupu (ktery by na zacatku ohlasila), ale ten metaformat (a datove typy) by byly spolecne. Serializace neznamena nutne textovy interface (viz tez Protocol Buffers).

Samozrejme, krome casu a zajmu o jine veci, mi nic nebrani si to naimplementovat. Nechci se tim zkratka zabyvat, presto si myslim, ze by to inovace byla.

[:::]

ja si zase myslim, ze by to byla katastrofa... ;)

[happy barney]

Moje predstava byla takova, ze kazda utilita by mela svuj vlastni format vystupu (ktery by na zacatku ohlasila), ale ten metaformat ...

Toto spĺňa aj súčasný textový formát
Pre rôzne predstaviteľné metaformáty existujú rôzne spôsoby spracovania (príklad: text - grep; xml - xslt). Preto, ak to už urobiť inteligentne, boli by treba buď filtre (vstup/výstup), alebo každá aplikácia by mala podporu pre dynamické filtre (default text). Za týchto podmienok je možné uvažovať o tom, že by to pre určitú skupinu problémov bola inovácia.

Serializace neznamena nutne textovy interface (viz tez Protocol Buffers).

Potrebuješ parser. Aj napr bzip/gzip textové data chápem textové.

Samozrejme, krome casu a zajmu o jine veci, mi nic nebrani si to naimplementovat. Nechci se tim zkratka zabyvat, presto si myslim, ze by to inovace byla.

z toho vyplýva, že navrhovaná invácia nemá pre teba praktický význam.

[JS]

Nevim, asi si nerozumime. Co mi na textovem formatu vadi je, ze ja jako uzivatel musim resit parsovani. Napr. pokud chci setridit seznam souboru z "ls -l" podle data (to ze to umi ls ted pomineme kvuli pointe), musim rict sortu, na ktere pozici je prislusna hodnota, a to jeste se modlit, aby v nazvech souboru nebyly mezery. Misto toho bych si predstavoval, aby mi "ls -l" vratil seznam zaznamu (neco jako tabulku) a ja mohl jen rict "chci to setridit podle pole datum" a on to udelal, popripade mi rekl, pole datum v datech neni. A to nemluvim o vecech typu - mate 2 mnoziny udaju (treba seznamu souboru) a chcete nalezt jejich mnozinovy rozdil (coz se da dnes udelat trikem "cat list1 list1 list2 | sort | uniq -u"). Dalsi zjevna vyhoda by byla, ze pokud by pozdeji nekdo chtel rozsirit format dat vracenych ls, nerozboural by muj skript.

Zkratka, Unix byl navrzen v dobe, kdy textova vymena dat stacila, protoze to je jednodussi koncept nez navrhuji ja, i implementacne. Fakt, ze pipou mohou lezt i binarni data s tim nesouvisi - podstatne je, ze pomocne utility pro prikazovou radku (jako sort, uniq, atd.) neumi rozebirat binarni data, jen textova.

Jestli by ta inovace pro nekoho mela prakticky vyznam, to nevim, to je pointou inovace, ze muze selhat (ale asi ano, je to asi jako rozdil mezi makry v C a makry v Lispu). Kazdopadne, chce to dost usili na to, abych se tim zacal zabyvat. To, ze me to prakticky nezajima (je to takove vynalezani Unixu 2.0) ovsem vubec neznamena, ze by to pro me bylo neuzitecne.

[happy barney]

stále je tam parser, je jedno, či textový, alebo binárny.

popisovaná modelová situácia má však muchy ... hlavnou je použitie nesprávneho nástroja. Áno, bolo by pekné, keby vedeli medzi sebou programi komunikovať na XML úrovni, ale načo? Na podobné veci sú tu iné nástroje, (takisto by niekto mohol požadovať zotriediť súbory podľa dňa v týždni alebo intervalu od vopred zadaného dátumu ...). A na rozdiel od shell prístupu tento prístup neťahá množstvo informácii zbytočne.

[Mintaka]

To je mi ale plamenů. A proč by se nemělo dát používat obojí. Kdo chce s Bashit nechť si bashí, kdo chce Pyhonit nechť si pythoní (perluje, javascriptuje, visuálbasicuje, ....)

Každý přístup má své klady a zápory, proč se omezovat jedním řešením?

[yac]

Rozhodně. Vždy jde o poměr mocnosti(která je subjektivní) a kompatibility/rozšířenosti. Přicházejí a budou přicházet nová mocnější řešení, proto hledat jedno ultimátní je hloupé. Jednoho dne bude v kontextu s alternativami python smrdět stejně jako dnes bash.

[Mintaka]

Tak tak, všechno se mění, něco pomalu, něco rychleji.