Proč je Parrot důležitý (diskuse)

[Miloslav Ponkrác]

Parrot je velmi důležitý a díky čekání na Parrot se podařilo snížit penetraci Perlu a zastavit jeho rozmach. Takže své zásluhy na prosazení dobře udržovatelných jazyků nesporně má.

[happy barney]

to si mierne mýlite "pojem" a "prujem" (tuším má byť s krúžkom) ... a názor, že existuje dobre udržovateľný jazyk, ten necháme odborníkom v bielych plášťoch

V prípade perl 6 sa nečakalo na Parrot, ale hlavne na uzavretie špecifikácie Perl 6. Parrot je samostatný projekt, Perl 6 (Rakudo) je len jedna z nadstavieb a len jedna z možných implementácii.

[Miloslav Ponkrác]

Uznávám, že jsem se nevyjádřil přesně. Ve skutečnosti je to asi takto:

Autor Perlu se rozhodl, že si může dovolit vše, a namísto evoluce udělá revoluci. Tímto dnem, kdy se rozhodl už začalo nevyhnutné podseknutí pozice Perlu. Bohužel se sčuchnul i s autorem Pythonu, kterého revolučním duchem a myšlením nadchnul a ten se opět rozhodl zlikvidovat kompatibilitu i v Pythonu.

V době kolem roku 2000, což je tak někdy doba, kdy se rozhodl Larry Wall zlikvidovat pozici Perlu (on tomu tak neříkal), byl Perl naprosto všude myšleno ve smyslu, že nebylo možné se Perlu vyhnout, nerozumět mu, nesetkávat se s ním a často o něm s nikým nemluvit – ať už chcete, nebo ne. Pozice Perlu byla poměrně silná, a Perl měl slušně našlápnuto. Myslím (samozřejmě se můžu mýlit), že kdyby se neobjevil Perl6, dnes má Perl velmi slušnou penetraci.

Od té doby ale pozice Perlu klesala a po pár letech už jsem se s ním vlastně vůbec nemusel nikde potkávat. Mohl jsem odinstalovat Perl úplně, protože perlovské skripty přestaly přicházet. Matně si vzpomínám, že v těch letech se neustálo omílalo čekání na Perl6 a na Parrot. Postupně všichni čekali a čekali a Perl tak nějak bylo méně a méně vidět.

Python udělal revoluci taktéž, jen o krapítek rychleji, takže to v řadách Pythonu nadělalo menší škody, nicméně z odstupem času se ukáže, jak moc to neprospělo. Mít v životopise „po 17 letech stabilní syntaxe jsme jí nekompatibilně překopali – a donutili postupně programátory revidovat, či přepisovat zdrojáky, přičemž jsme jim nedali do ruky 100% funkční konverzní nástroj“ je vizitka, která spolehlivě zavírá cestu do mnoha nasazení.

Postupně od Larryho nápadu tak nějak se k sobě historicky začaly přibližovat události kolem Perlu6, Parrotu a Pythonu. A troufám si říct, že nikomu tento nápad nepomohl a bude to časem znát.

Neznám, respektive už si nepamatuji detaily. Ale linka je zhruba viz výše.

Ohledně udržovatelného jazyka – určitě Perl nasadil tak nízkou laťku, že v zásadě každý běžný jazyk je rozhodně udržovatelnější, najmě pokud mluvíme o týmu lidí a alespoň středně velkém projektu.

[happy barney]

ad názor: ok, to už je trochu lepšie rozpísané ohľadne perlu vám v niečom dávam za pravdu, v niečom nie.

rozhodne nesúhlasím s tvrdením "nízka laťka" ... vždy je to o luďoch, nie o jazyku.

[volca]

Myslite zmeny v Pythonu 2.6 -> 3.0? Odbornik na python nejsem ale zda se mi ze jde o naopak velice chvalihodnou snahu. Srovnejte napriklad s Javou kde se zpetnou kompatibilitou obhajuji dosti casto nevhodna reseni v navrhu jazyka (napr. generika, spekulativne taky anotace) a specifikace se zanasi. Stejne tak v pripade Win32 API... A vubec - ty jazyky/projekty ktere se snazi drzet zpetnou kompatibilitu i za cenu udrzeni kompatibilini hovadiny dopadaji spatne/hur.

 

Co se tyce udrzovatelnosti - perl ma vysokou informacni hustotu, to je vse. Jak s tim kdo naklada je jeho vec. Navrhovat udrzovatelny jazyk je casto cesta do pekla lemovana dobrymi umysly - zde zminim opet Javu.

[Petr Šmíd]

Tak to s Vámi rozhodně nesouhlasím.

Řekněme, že již několik let vyvíjíte v jazyku X velký projekt pro své zákazníky. Pokud v jazyku X dojde k revoluci (a zpětným nekompatibilitám), musíte se rozhodnout pro jednu ze dvou špatných možností:

1) Buďto začnete přepisovat stávající kód do nové verze jazyka, strávíte na tom třeba rok času a mezitím Vás předběhne konkurence, která ve svých produktech mezitím přidala spoustu nových vlastností, zatímco Vy jste se musel patlat s přepisem. Ztratíte zákazníky a můžete mít existenční potíže.

2) Nebo zůstanete u staré verze jazyka, ale pak máte do budoucna problém s inovacemi, protože nové knihovny jsou už pro novou verzi (a staré už nikdo nebugfixuje). V té chvíli vás předběhne konkurence, která s inovacemi nemá problém a Vy zase ztratíte zákazníky.

 

To si pak rozmyslíte, s jakým jazykem budete vyvíjet - málokomu se chce spálit ohromné množství peněz a času na přepisu na novou verzi.

Mimo jiné práve proto se Java používá, protože je vyzrálá a zpětné nekompatibility se nemusí nikdo obávat. Je tedy stále možné používat v kódu staré knihovny, vývoj se nikdy nezastavil tím, že někdo byl nucen něco přepisovat, nedochází ke štěpení sil atp.

Zákazníky opravdu nezajímá, jestli programujete v krásném revolučním anebo starém a škaredém jazyku.

[Filip Jirsák]

Ani Java v tomhle není úplně dokonalá, protože třeba mezi 1.4 a 1.5 přibyly do DOM API do stávajících rozhraní nové metody pro DOM 3. Takže staré knihovny sice můžete použít a staré aplikace můžete spustit, ale už je nepřeložíte, a musíte ty nově přidané metody nějak implementovat.

[Petr Šmíd]

Ano, to je bohužel pravda. Ten samý problém najdeme třeba v rozšiřování rozhraní JDBC.

Mimochodem, trochu OT, ale způsobů, jak nevědomky rozbít zpětnou kompatibilitu je opravdu hodně Mohu doporučit přednášku Jardy Tulacha (architekt NetBeans). Myslím, že to je velice zajímavé počtení.

 

[xm]

Ale prosim vás, ten přechod na novou zpětně nekompatibilní major verzi jazyka zdaleka není (nemusí být) tak složitý. Např. přechod na Python 3 je vyřešen velmi dobře a je jednoduchý - spoustu mechanických věcí za vás vyřeší konverzní nástroj 2to3 a zbytek upravit ručně už není nic složitého a zdlouhavého, ani u velkého projektu. V žádném případě práce na rok

[Michal Vyskočil]

Tohle je fundamentální rozdíl mezi dvěma pohledy. Zatímco technický, či opensource pohled je ten, že na čím větším množství architektur, platforem, knihoven, ... to běží, tím lépe a pokud ne, prostě někdo udělá patch.

Korporátní pohled je přesně obrácený a množství externích závislostí se redukuje běžbě na minimum - základní mantra je hlavně nic neměnit. Extrémním příkladem mohou být třeba nástroje od Oracle, které si sebou zhusta tahají i vlastní JVM. Pro takové prostředí jsou i drobné změny v Pythonu 3.0 katastrofou.

Navíc těžko říct, který pohled je lepší, protože i když korporátní podporuje tvorbu strašných bastlů, tak na druhou stranu zjednodušuje (a hlavně zlevňuje) údržbu takového celku.

[Michal]

Korporátní balasty ať si klidně hnijou na Javě. Python 3.x vítám, pročištění jazyka do budoucna spoustu práce usnadní. Nikdo vás přeci nenutí na něj hned přecházet, předpokládám, že dvojková řada bude udržovaná ještě velmi dlouho.

[mj41]

OpenSource projekty se vyvíjí, tak jak to chtějí lidé, kteří tam tu reálnou práci dělají. Nikdo Vám předem záruky nedával, že to pojede věčně. Kdyby jste je chtěl a zaplatil, tak to asi nebude problém. Ti programátoři co to dělají většinou dobře vědí jaké to přinese plusy a mínusy.

Co se týká Oracle, tak mi při pohledu na chyby, které občas hlásíme připadá, že by se kluci mohli trochu porozhlédnout a učit se např. od Perlu, co je to testování. Navíc software jako Oracle se taky vyvíjí. Zákazníci neustále hlásí nové chyby a požadavky a proto nezbývá než věci měnit.

Já to vidím hlavně u toho Perlu. Prostě jazyk, který by zůstal u 100% kompatibility s jeho první verzí , by něměl šanci. U Perlu jsou tyto diskuse teď dost aktuální, viz. např. What does "Stable" Mean? What is "Support" Anyway?  Perl Long Term Support and "The GreyPAN" .

 

[Michal Vyskočil]

Ale já korporátní vývoj vůbec neobhajoval, jenom jsem řekl, že z jejich hlediska mohou i tak drobné změny, jako provádí Python, problematické. Prostě opensource a korporátní pohled na software jsou v přímém protikladu.

Co se týká Oracle, tak mi při pohledu na chyby, které občas hlásíme připadá, že by se kluci mohli trochu porozhlédnout a učit se např. od Perlu, co je to testování. Navíc software jako Oracle se taky vyvíjí. Zákazníci neustále hlásí nové chyby a požadavky a proto nezbývá než věci měnit.

No a to je o tom mluvím, protože zatímco teď musí Oracle "jenom" fixovat bugy a přidávat nové vlastnosti, tak to poslední, co si chce/může dovolit, je věnovat se přepisováním různých černých skříněk jenom proto, že nová verze něčeho už funguje trošku jinak a nejde to vyřešit další vrstvou.

BTW: nikde jsem taky netvrdil, že korporátní způsob vede k software bez chyb

[Radim Kolář]

Presne tak. Ja jsem kdysi delal v Pythonu a po zkusenostech s postupem jeho vyvojaru - t.j. vyraz x vraci jine ruzne hodnoty podle pouzite verze Pythonu jsem ho opustil. Tyhlety veci se dost spatne v programu hledaji a navic to stoji hodne casu, to jest i penez.

Navic nebyli schopni dodnes udelat poradny multithreading a maji memory leaky v nekterych standardnich knihovnach, takze se musel server napsany v pythonu casto restartovat. Byla to pro mne dulezita zkusenost, dneska bych si vzal spis vzal jeho Java port, kdybych mermomoci chtel python.

[mektige]

Můžete říct, co vás "donutilo" přepisovat kód do nové verze? Ta stará bude totiž použítelná ještě hodně dlouho.

[mj41]

> Autor Perlu se rozhodl.

Kterého autora myslíte? Kdyby se autor Linuxu rozhodl pro něco podobného, tak by ho všichni slepě následovali? Nebo jsou takhle vadní jen vývojáři Perlu?

Navíc původní hrnek hodil o zeď někdo úplně jiný než Larry.

 

> ... namísto evoluce udělá revoluci ...

Perl 6 bude pořád Perl. A kdyby Larry nedělal to co dělá, tak možná všichni ještě používají sed a awk.

 

> ... Perl měl slušně našlápnuto ...

Jasně. Všichni, kdo pracují na Perlu 6 vědí, kam má z dlouhodobého hlediska Perl našlápnuto.

 

> ... v těch letech se neustálo omílalo čekání na Perl6 a na Parrot

Je fakt, že lidi dělají špatná rozhodnutí v očekávání zázraku, ale až ten zázrak začne působit naplno, tak to bude bomba .

 

> ... v řadách Pythonu nadělalo menší škody, nicméně z odstupem času se ukáže, jak moc to neprospělo.

No právě. Pojďme dělat něco užitečného. Třeba jazyk pro příštích nejméně 20 let. Za 10 let se sejdem a můžem se bavit s argumenty za zády a ne věštit z křišťálové koule nebo zpětně vykládat své interpretace historie.

 

> ... jim nedali do ruky 100% funkční konverzní nástroj

To mám nejraději. Oni jsou ti špatní, oni to nedělají tak jak chci a potřebuji. Možná je třeba nechat tlachání a poslat patch, založit novou větev nebo něco v tom duchu? Pokud je pravda co si myslíte, tak vám spousta lidí pomůže.

 

> ... nikomu tento nápad nepomohl ...

Nápad? Léta práce  mnoha lidí a vy tomu říkáte nápad? řekl bych, že kvalita myšlenky/nápadu se pozná podle činů lidí, kteří ji následují.

 

> ... pokud mluvíme o týmu lidí a alespoň středně velkém projektu.

Pro týmy lidí musíte mít nástroje [1] , [2] , [3] atd. Spoléhat se na syntaxi jazyka je téměř k ničemu. Navíc nevím co v dynamických jazycích píšete, ale mám raději kvalitu kódu, který používám než krásu jeho syntaxe.

 

 

 

[mj41]

Podařilo se snížit penetraci Perlu? Z čeho tak soudíte?  

• z Tiobe indexu ?
• z klesající kvality ?
• z toho, že se nic neděje ?

Nebo nějaké nové mýty o kterých nevím ?

Dobře udržovatelných jazyků? Ono něco takového existuje? Není to spíše o hrdinství autorů kódu? O psaní čitelného kódu, vhodných komentářů, dokumentace a testů? Co takhle porovnat kvalitu modulů na CPANu s ... aha ono vlastně není s čím.

Uff. Omlouvám se, že jsem se nechal unést duchem předchozího příspěvku .

 

 

[Filip Jirsák]

Dobře udržovatelných jazyků? Ono něco takového existuje? Není to spíše o hrdinství autorů kódu? O psaní čitelného kódu, vhodných komentářů, dokumentace a testů?

Pokud jsou všechny jazyky stejné co do čitelnosti a udržovatelnosti kódu, pak nechápu, proč se postupně většina programátorů přesunula k procedurálním jazykům a později k objektovým, když mohli zůstat u assembleru.

[volca]

To nebude citelnosti a udrzovatelnosti, ale spis komplexnosti pozadovanych reseni, prepouzitelnosti  a tlakem na casovou nenarocnost reseni.

[Filip Jirsák]

To vše ale vychází právě z té udržovatelnosti a čitelnosti.

[volca]

Na tom neco je - ale z druhe stranky - tu nakonec stejne ovlivnuje programator. Jestli ten kod pise "prase", jazyk mu v tom stejne nezabrani.

[Filip Jirsák]

Jazyk samozřejmě nezabrání psát programátorovi jako prase, na druhou stranu i ve špatném jazyce dokáže psát dobrý programátor v rámci možností srozumitelný kód. Ale je přeci jen zajímavé, že write-only zdrojáky se v některých jazycích vyskytují častěji než v jiných a že jsou to zrovna jazyky, které nemají čistý návrh jazyka, ale je to spíš poslepované všechno, co se zrovna hodilo.

[happy barney]

Napísať skutočný "obfuscated" kód je umenie, vyššia úroveň ovládania ... je zaujímavé, že tie, podľa vás "zrozumiteľné" jazyky nemajú ľudí, takto ovládajúcich jazyk.

[happy barney]

<joke>pretože väčšina sa snaží neodlišovať sa od priemeru</joke>

jazyk je len vyjadrovací prostriedok a je na človeku, ako ho využije. Ono nie je problém písať v assembleri "rýchlo", "udržovateľne", "objektovo" ... len skončíte pri makrách, ktoré generujú stále rovnaké obálky a pri dosiahnutí istej hranice je efektívnejšie používať iba "makrá" (a to už je znova nový jazyk).

Osobne považujem množstvo wizardov používaných pri tvorbe v jazyku za signalizáciu schopnosti/neschopnosti jazyka vyjadriť myšlienky a postupy (a jeho zastaralosti). Nevraviac o modifikácii výsledku wizardu, vazbách ...

[volca]

souhlas. Neexistuje sice zlaty jazyk kde se vyjadruje jednoduse kazdy problem, ale kdyz musim pouzit nadstavbu abych nemusel koukat na osklivy kod (vinou vlastnosti jazyka), je tam neco prohnile.

[zoul]

To Randálovic děvče je mazec, že? Kdyby na závěr videa z přednášky nezmínili benchmarky, tipoval bych si, že na Parrotu poběží tak akorát tahové strategie. Celé je to nějaké prapodivné kouzlo…

[Robo]

jj neni zla ;) ale kameraman mohol radsej zaberat plochu, na ktoru sa premietala prezentacia :))

[zoul]

Myslel jsem obsah přednášky, nikoliv slečnu samotnou Taky mě překvapilo, že kameraman důsledně sledoval jen ji – ale pokud jsem si dobře všiml, říkala, že slajdy budou na webu. Tím by se to vysvětlovalo.

[mj41]

Slajdy jsou tady. Ty benchmarky jsou ale z několik let starého Parrotu.

[zoul]

Tj. dneska je Parrot rychlejší, pomalejší, nebo zkrátka jiný?

[mj41]

Měl by být rychlejší . Zatím si nikdo nenašel čas, aby to otestoval a sepsal. Ty testy na Computer Language Benchmarks Game jsou z hodně starého Parrotu [1] , [2].

[pozortucnak]

Parrot není jenom Perl!!!

[zdenek-hbr]

tusite nekdo v jakem je to vlastne stavu? da se perl6 a parrot pouzit k vyvoji?

[JoHnY2]

Tak pokud jsem to dobre pochopil, tak by v nejblizsi dobe mel vyjit stabilni release Rakudo Perl 6ky a v nem by se teoreticky dalo vyvijet.

[mj41]

V Rakudo Perlu 6 už něco funguje. Pokroky jsou vidět nejlépe z blogu. Je to, ale zatím jen na hoodně pomalé hraní.

Parrot je možná o kousek dál, ale u toho mě nenapadá k čemu by jste ho potřeboval. Je to virtuální stroj s dalšími nástroji pro implementaci dynamických jazyků.

[zdenek-hbr]

ok priznavam ze kdyz jsem si vcera procetl ten web o parrotu tak jsem zjistil, ze vlastne nechapu k cemu je to dobry. proc bych mel napriklad misto intrepretu ruby instalovat parrot a cardinal. to preci vzdycky musi bejt penalizovany na vykonu ne? jinou vyhodu nez tu, ze jdou vzajemne mezi ruznejma jazykama pouzivat jejich knihovny nejak nevidim.

[mj41]

Zatím jsou Parrot a hlavně implementace jazyků neúplné. Výkon? Předpokládám, že to bude právě jeden z pádných argumentů pro Parrot (náznak je vidět v tomhle dva roky starém porovnání). Další důvody jsou vidět z článku. Např. jeden mod_parrot pro Apache na kterém budou ostatní jazyky stavět. Ale asi si musíme počkat, než hádat z karet.

[zoul]

Doporučuju mrknout na tu přednášku, nebo alespoň na slajdy – Parrot je podle všeho mnohem rychlejší než výchozí interpret Ruby. Taky mi to intuitivně přijde podezřelý, no ale holt jsou asi vážně dobří :)

[JoHnY2]

Neni to tak divny, staci se podivat na JRuby a IronPython a to nebezej na VM navrzenejch pro dinamicky jazyky.

[mj41]

Tak včera ke konci dne vyšel Rakudo Perl 6 development release #18 ("Pittsburgh"). Umí 11,536 spectests, což je 68% z existujících testů specifikace Perlu 6.

 

Má někdo představu kolik testových případů existuje v Pythonu, Ruby, Javě? Já našel jen tohle dva roky staré srovnání. Kde se píše, že JRuby (nejvíce testované Ruby) má 2,747 test případů. Standardní make test u Ruby jich spouští 867. Počet u Pythonu (včetně základních knihoven je 11,437). Perl 5 jich měl v té době 64,793, se základními knihovnami dodavánými s jazykem 121,873 . K tématu je i novější článek stejného autora, který jsem uváděl někde výše.

[Michal Vyskočil]

Perl 5 jich měl v té době 64,793, se základními knihovnami dodavánými s jazykem 121,873.

Zajímalo by mě, kolik z nich funguje (nebo bylo upraveno) i s 5.10

Navíc pouhé mechanické sečtení testů nemusí být pro srovnání nejvhodnější. Když se vezme v úvahu obrovská flexibilita Perlu jako jazyka, tak počet testů musí být obrovský, protože je potřeba pokrýt každý případ. V případě Pythonu s jeho - dělej jednu věc jedním způsobem, pro podobné pokrytí stačí v ideálním případě test jeden.

[mj41]

Fungovat by měly všechny ne? Resp. v dokumentaci by mělo být uvedeno co funguje a co ne. I u CPANU se taky hodně [1] , [2] testuje.

Každý případ samozřejmě pokrýt nelze. Musíte správně vytvořit množiny ekvivaletních případů. Abych pravdu řekl, tak vývoj Perlu 5 nesleduji. Předpoklámám, že to funguje stejně jako u Parrotu a Perlu 6. U něj se předpokládá, že je třěba zdvojnásobit počet testových případů a pak se teprve uvidí jestli je pokryta celá specifikace nebo ne.

Nevěřím, že je to dáno flexibilitou. Ta podle mně neudělá ani 2x tolik. Prostě v Perlu se testuje mnohem víc. Kdyžtak najděte nějaký konkrétní příklad .

 

 

[Michal Vyskočil]

Fungovat by měly všechny ne? Resp. v dokumentaci by mělo být uvedeno co funguje a co ne.

No když jsem viděl, co všechno 5.10 rozbila u nás a kolik s tím měla anička práce, tak nevím - 5.10 byl poměrně výrazný skok.

Ad zbytek - netvrdil jsem, že všechno jde na vrub flexibilitě jazyka, ale nějaký vliv to určitě má.

[mj41]

Nějak zvlášť jsem po tom nepátral, kromě známých věcí jsou tady i určitě regrese (asi třeba tyto). Každopádně je to na Vás. Buď se člověk zapojí do vývoje, píše testy pro ty vlastnosti, které používá, nadává, když mu plánují vzít to co potřebuje, nebo se hold modlí, aby tam ty věci zůstaly i v další verzi .

[skim]

No když jsem viděl, co všechno 5.10 rozbila u nás a kolik s tím měla anička práce, tak nevím

To je zajimavé. Ja jsem asi nenarazil u svého kódu na případ, že by se něco rozbilo. Co si vzpomínám, možná jsem narazil na jednu drobnost. Klasické chyby se mi vyskytuji několikanásobně více než toto.

5.10 byl poměrně výrazný skok.

To ano.

[happy barney]

jediné, na čo som ja pri 5.10 narazil, bolo použitie [] miesto fields::new

[Lukáš Zapletal]

Kvantita není vše.

[mj41]

Kvantita není vše. Ale v případě, že testy správně píšete/navrhujete, což se díky revizím kódu ohlídát dá, tak prostě více testů znamená kvalitněji otestovaná implementace jazyky.

Navíc Perl 5 má jen jednu implementaci jazyka. Jak hodně je pokryta specifikace Pythonu testy? Jak hodně se liší např. Jython a CPython implementace?

Soulad mez specifikací, testy a implementací je úplným minimem pro zajištění kvality. Nebo se pletu?