První oficiální vydání Perlu 6

Po 15 letech vývoje oznámil Larry Wall vydání Perlu 6. Vánoční vydání Rakudo Perlu 6 aneb Rakudo Perl 6 #94 "коледа" bylo prohlášeno za první oficiální vydání Perlu 6.

26.12.2015 18:00 | Ladislav Hagara | Nová verze

Komentáře

[little.owl]

Hezke, ale pozde, prilis pozde.

[Radek Miček]

Proč pozdě? Je tu snad nějaká konkurence?

[tuk]

ruby.

[Radek Miček]

Přijde mi, že Perl 6 a Ruby 2.2 jsou poměrně vzdálené jazyky. Například Perl obsahuje vestavěnou podporu pro gramatiky, pro tzv. graduální typování, pro multimetody a pro další věci. V Ruby sice můžete tyto vlastnosti doplnit pomocí knihoven, otázkou ovšem je, zda existuje kombinace knihoven, jenž dohromady fungují a přináší vše, co má Perl 6. Navíc byste pro tyto knihovny chtěl alespoň takovou podporu, jakou bude mít Perl.

[tuk]

Jak jste již zmínil všechna tato funkcionalita se dá velmi jednoduše doplnit pomocí gemů. I GIL se dá obejít pomocí vhodně vybrané implementace jako JRuby nebo rubinius (o dalších jako MaGLev nemám zatím moc potuchy).

Jestli existuje kombinace gemů, která pokryje veškeré vastnosti perl6 zcela upřímně netuším, ale pro mne osobně je důležité, že pokud něco potřebuji udělat knihovna je tam nebo je zapotřebí malé změny existujících, abych mohl v klidu vyvíjet.

Perl6 bude muset dokázat, že je v něm zábava implementovat a hlavně, že dokáže nabídnout nejen vlastnosti, ale také infrastrukturu celého jazyka a na to je opravdu ještě hodně brzy hodnotit. Rozhodně budu programovat v ruby, protože mě to baví a uvidíme za nějakou dobu se možná podívám na perl6, ale nejspíše to bude Python.

[mj41]

Ruby? Nemyslím si. Ale až příští rok či dva ukáží, zda se performance Rakudo s MoarVM dostane, tam kde je to možné.

BTW. Má Ruby specifikaci a test suitu, tak aby bylo možné napsat 100% kompatibilní interpret? Nebo je to tak jako s Perlem 5, že když něco nefunguje podle dokumentace, tak je špatně dokumentace?

[tuk]

Měl RubySpec, ten je teď na chvíli dead, ale podle všeho se stane součástí MRI, ale to se ještě uvidí.

[dumblob]

Dao

[Radek Miček]

Vypadá polomrtvě.

[dumblob]

Nastesti neni. Aktualne je Dao plne pouzitelny (beta release) a resi se spise knihovna, dodelani dokumentace a v planu jsou i optimalizace VM a dalsi "detaily".

[xkucf03]

Akorát ta expirovaná doména je trochu smutná…

[dumblob]

Ju, to je fakt. Také se na nápravě pracuje (dle emailové neveřejné diskuze).

[little.owl]

Ano. Perl6 sice prinasi nekolik zajimavych konceptu, ale to uz IMHO nestaci k odklonu od jazyku jako Python ci Ruby, ktere se budou i nadale vyvijet.

Z hlediska novelity - je to jen dalsi pokus dostat se smerem k Lispu - coz rika i sam Larry Wall zde (na IRC pouziva nick TimToady):

to the first approximation, Perl 6 is Lisp with a decent syntax, and minus a lot of assumptions about how lists should be represented :)

Osobne mam pochybnosti jak o decetni syntaxi, tak i o vyhodach vzdani se jednoduche uniformni syntaxe, kdy ani s novymi rules/grammar se to nedostava na uroven moznosti Lisp maker a celkove to cini perl6 vic nez komplexni - a to plno veci neni jeste jasne specifikovano.

[tom]

Python a Ruby porad oba maji GIL, takze na spoustu veci se nehodi a nebo se museji kombinovat s C.

[tuk]

Doporučuji se podívat u ruby na jiné implementace jiné než MRI. Např. Jruby nebo rubinius, nemají tolik skloňovaný GIL.

[tom]

jj, jruby + concurrent-ruby znam, loni jsem na to prepisoval jeden program a prislo mi to dost WiP - musel jsem se koukat do implementace, abych vedel, kdy synchronizovat.

[Bystroushaak]

Python a Ruby porad oba maji GIL, takze na spoustu veci se nehodi a nebo se museji kombinovat s C.

Python a Ruby rozhodně GIL nemají, ne ve specifikaci jazyka. Mají ho jen některé jejich interpretry. Například pypy je pythonní interpretr, který místo GILu používá STM a zároveň přidává i kopu optimalizací, takže je mnohonásobně rychlejší, než cpython (referenční implementace pythonu).

[little.owl]

A nebo Jython, ktery take GIL nema.

[tom]

Jenze bez toho GILu neni jasne, co jsou atomicke operace - vubec to neni na urovni jazyka reseno.

[Bystroushaak]

No a?

[tom]

Takze je to vpodstate nepouzitelne.

[little.owl]

Rekl bych ze praxe a siroke nasazeni Pythonu ukazuje, ze pouzitelne je to vice nez dosti.

[tom]

Muzete uvest priklad rozisrene aplikace, ktera opravdu vyuziva vice vlaken?

[pavel]

Například pypy je pythonní interpretr, který místo GILu používá STM

Neni pravda. Implementace STM je zatim stale nepouzitelna a navic pridava nezanedbatelnou rezii a tim i dopad na celkovy vykon. Rozhodne neni samospasitelna, snad az bude sirsi podpora HTM se to zlepsi.

[Bystroushaak]

Ok, můj omyl. Kdysi jsem si implementaci pypy s STM stahoval a hrál si s ní, měl jsem tedy za to, že už to byla oficiálně vydaná verze.

[little.owl]

GIL je implementacni zalezitost, nikoliv problem jazyka. Hlavnim duvodem proc cpython stale pouziva GIL jsou knihovny tretich stran a to se bude menit pomalu, asi az v pristi zpetne nekompatibilni revizi.

[Radek Miček]

Může to být i problém jazyka. V případně Pythonu je hlavní problém v tom, že ohledně paralelismu nic (vůbec nic??) nespecifikuje (například žádný paměťový model, žádná primitiva pro psaní paralelních výpočtů, žádná sémantika pro paralelní výpočty). Tj. chování je závislé na konkrétní implementaci, což není moc praktické – tj. je lepší volit jiný jazyk.

[little.owl]

Vubec nic? Python ma specifikovany thread level parallelism, celkem rozumne popsany datovy model a postupne se pridavaji dalsi veci - treba ted na jare pridali do jazyka nativni coroutines s async/await syntaxi.

Skutecnost, ze nespecifikuji vice vitam. Cesta jakou zvolilo C++11, ale i Perl6, dela prilis mnoho predpokladu o implementaci HW ci VM, a to se IMHO negativne v budoucnu vrati, ostatne ne nahodou podobny pristup jako Python voli Go.

[mj41]

i Perl6, dela prilis mnoho predpokladu o implementaci HW ci VM

Máte něco konkrétního? Mně Parallelism, Concurrency and Asynchrony in Perl 6, Concurrency, hyperoperátory, junctions, ... připadá docela high level. Samozřejmě to není jednoduché, viz. Racing to writeness to wrongness leads a dodělané.

[little.owl]

MoarVM je prolezly perlismy do te miry, ze je narozdil od ParrotVM je tezko pouzitelny pro jiny jazyk, kdy pouzite third party knihovny jako libatomic_ops ci uthash vytvari silne pozadavky na semantiku pristupu k pameti ci thread locking operace. Oproti tomu CPythonVM je jednodussi, v podstate cele je to implementovano zde a ta relativni jednoduchost a portovatelnost jeho VM je dana hlavne designem jazyka. Je to rozdilny pristup dvou filozofii. Jedna preferuje minimalni jadro jazyka a jeho postupne opatrne rozsirovani, s tim, ze plno veci se presouva do knihoven, druha vytvari komplexni jazyk, ktery se snazi pokryt vse. Ja jsem zastance prvniho pristupu, splacat vsechno dohromady a myslet si, ze mame na 40 let vyreseno, je velmi naivni. Je to videt i na autorech, Guido van Rossum umi rikat ne, a Larry Wall pustil do Perl5/6 kde co a podle toho ty jazyky vypadaji.

[Radek Miček]

Jedna preferuje minimalni jadro jazyka a jeho postupne opatrne rozsirovani, s tim, ze plno veci se presouva do knihoven, druha vytvari komplexni jazyk, ktery se snazi pokryt vse.

Přijde mi, že Perl 6 je také instance prvního přístupu – vytvořit dostatečně silné jádro, aby se ostatní dalo udělat v knihovnách.

[little.owl]

To je relativni, ale podle me to jednoduchy jazyk neni. Dobrym meritkem je jak vypada parser ci BNF, a uz tam to vypada slozite.

[mj41]

Ano, je to všechno relativní. Ono Turingově kompletní je kde co.

Pro mě je dobrým měřítkem např. to jak vypadají chybové hlášky a to, že je pak implementace složitější mi nevadí.

[mj41]

O MoarVM přece vůbec nejde. Ono ani nejde o Rakudo Perl 6 implementaci. Bavíme se o jazyku, tj. specifikace a test suita. Tam problém nevidím.

To že, MoarVM zafungoval na rozdíl od Parrotu aspoň pro Perl 6 je zjevné. Možná časem dojde i na Parrot, ale je vzhledem k omezeným zdrojům dost nepravděpodobné.

Oproti tomu CPythonVM je jednodussi, v podstate cele je to implementovano zde ...

Tak třeba o hash funkci jsem se dočetl toto. Ať už je to jak chce, tak pro mě je to implementační detail jednoho z virtuálních strojů. Podobně to vidím u dalších third party knihoven. Je možné, že je v příští verzi vymění za jiné nebo přepíší. S jazykem to téměř výbec nesouvisí.

... splacat vsechno dohromady ...

Já 15 let vývoje, který začal 361 dokumenty s požadavky na změnu (ne všechny byly samozřejmě přijaty) nepovažuji za "splácání dohromady". Perl 6 je vpodstatě STD.pm6. A i když to není zrovna jednoduché, tak to za splácané nepovažuji.

Je to rozdilny pristup dvou filozofii. Jedna preferuje minimalni jadro jazyka a jeho postupne opatrne rozsirovani ...

Ale no tak. To je jako říkat, že signatury funkcí nemusí být v Perlu, protože na to existuje knihovna a před 25 lety to přece vymysleli dobře a jednoduše. Nebo na všechny požadavky na změnu jazyka je ok odpovídat "Napiš si na to knihovnu a neotravuj."?

Guido van Rossum umi rikat ne, a Larry Wall pustil do Perl5/6 kde co ...

Z čeho máte ten dojem? Zkušenost mých kamarádů adminů/ops je, že téměř každá Python aplikace/toola vyžaduje jinou verzi Pythonu a nedá se to rozumě nainstalovat a provozovat. Takže nevím co tím "kde co" myslíte. Ostatně proto je Perl 6 nový jazyk, zatímco Perl 5 drží zpětnou kompatibilitu a není to jak Python 2 vs. Python 3.

[little.owl]

O MoarVM přece vůbec nejde. Ono ani nejde o Rakudo Perl 6 implementaci. Bavíme se o jazyku, tj. specifikace a test suita. Tam problém nevidím.

Ne, reagoval jste na me "... predpokladu o implementaci HW ci VM, ...", a Perl6 bude vyzadovat pomerne komplexni VM [ci runtime].

Tak třeba o hash funkci jsem se dočetl toto.

A? To nema s uthash knihovnou nic spolecneho.

A i když to není zrovna jednoduché, tak to za splácané nepovažuji.

Subjektivni, ja spise ano. Tahle specifikace neni uplna, treba i onen parallelismus tam neni, stejne jako makra, ktera zdaleka nejsou vubec hotova.

Python aplikace/toola vyžaduje jinou verzi Pythonu a nedá se to rozumě nainstalovat a provozovat.

To rozhodne ne.

Ostatně proto je Perl 6 nový jazyk, zatímco Perl 5 drží zpětnou kompatibilitu a není to jak Python 2 vs. Python 3.

Naopak, je to tak, s tim ze narozdil od Python3 je Perl6 v podstate jiny jazyk.

Z čeho máte ten dojem?

Uz jen proto, ze to o sobe pripustil i sam Larry Wall, ostatne vyvoj Perl6 jsem sledoval pres 10 let, nez jsem to vzdal.

[mj41]

Uz jen proto, ze to o sobe pripustil i sam Larry Wall, ...

Taky sleduji Perl 6 přes 10 let a tohle mi teda uniklo. Sám Larry napsal (seznam na konci článku) např. toto:
* YAGNI. (You Ain’t Gonna Need It)
* Kill two birds with one stone.
* Avoid lists of exceptions the user has to memorize.
* Unifications can simplify things, sometimes at little cost.
* Major features should fix lots of things.

[little.owl]

To s tim nesouvisi. Spise jde o management projektu a Larry Wall neni skutecne prototyp cloveka pro roli benevolentniho diktatora. Staci se kouknout na vyvoj Perl6 od 2000 (mug throwing meeting), kdy se rozhodli v podstate zahodit vsechno co meli a zacit na zelene louce. Zemetreseni v 2007 a opet predelavani vseho. Cyklus opetovneho nekompatibilni refaktoringu cca kazde dva roky, nekomunikace mezi teamy vyvijejicimi Parrot a Perl6 frontendy, spory mezi Rakudo a Parrot vyvojari, takze Rakudo nakonec bezi nad MoarVM a JVM. I tenhle release Perl6 je jen proto, ze uz neco vydat museli, a k produkcnimu nasazeni to ma stale velmi daleko.

K tem citacim - pro Perl6 stale plati TIMTOWTDI a dusledkem je splacani vseho dohromady, s notnou davkou second-system effectu.

[Radek Miček]

Perl6 stale plati TIMTOWTDI

A v Pythonu (nebo i jiných mainstreamových jazycích) tohle snad neplatí? Nyní je například nemalý překryv mezi generátory a async a await.

Navíc, když jste mluvil o té implicitní paralelizaci, tak async a await je krok spíše opačným směrem – je to nízkoúrovňový přístup.

[mj41]

Silny kognitivni bias u me nebo u vas?

Pozadali komunitu o napady co dal s Perlem 5. Prislo 361 RFC - zadosti o zmenu. Vysledek je rozhodnuti, kteremu vy rikate "na zelene louce". Neudelal jej jen Larry. Coz nic nemeni na tom, ze Larry podle nekterych panu muze take za globalni oteplovani a smog v Pekingu.

Parrot - Zacli delat na VM na kterem pobezi Perl 5 a Perl 6 a pritom specifikace Perlu 6 jeste neexistovala. Roky experimentu. "Uz neco vydat museli" -> Parrot 1.0 -> deprecation policy. Parrot foundation. Drzeni se myslenky "VM pro vsechny dynamicke jazyky".

Jake zemetreseni v 2007 mate na mysli? Ja o zadnem nevim [1], [2]. "Navrat" od Pugsu zpet k Parrotu? Nebo to, ze se konecne pridal Jonathan, ktery ten Perl 6 nakonec temer cely udelal?

... je jen proto, ze uz neco vydat museli, ...

Proc by museli? Larry uz minimalne od 2002 rika, ze projekt nema casovy plan a ze Perl 6 chce udelat spavne a ne rychle. Po 15 letech by se zase tolik nestalo, kdyby to bylo o rok nebo dva vice. Proste specifikace, Rakudo i MoarVM uz jsou pripraveny.

Navic je to OpenSource, coz ma sve vyhody i nevyhody. Vzpomenme v techto dnech treba na Javu. Vyvojari maji sve zivoty, placenou praci, zapnuty -Ofun, ...

... a k produkcnimu nasazeni to ma stale velmi daleko....

.

Slepice-vejce. Uz se najdou takovi, kteri to v produkci pouzivaji a vydelavaji na Perlu 6 penize.

... pro Perl6 stale plati TIMTOWTDI ...

.

To uz jsem tu probirali. Je to dusledek a ne pricina. Nebo ne? Dejte nejake priklady, kdy se Larry rozhodl neco pridat a Guido nepridavat.

[Radek Miček]

Vubec nic?

To byla otázka.

celkem rozumne popsany datovy model

Co máte na mysli datovým modelem? To, co si představuji já, nijak nesouvisí s paralelismem.

IMHO negativne v budoucnu vrati, ostatne ne nahodou podobny pristup jako Python voli Go.

Mně to přijde spíše naopak. Když to není specifikované, programy se budou spoléhat na stávající chování, čímž se dále ztíží přechod k rozumnějšímu paralelismu.

[little.owl]

Když to není specifikované, programy se budou spoléhat na stávající chování, čímž se dále ztíží přechod k rozumnějšímu paralelismu.

Ja naopak doufam, ze u vysokourovnoveho jazyka se programator v budoucnu nebude muset vubec starat o nizkourovnovy parallelismus. Jadrem by mela byt concurrency na urovni designu, bez explicitniho lockovani ci podobnych zvrhlosti a parallelni beh na HW a souvisejici scaling by mel byt zalezitosti runtime.

[Radek Miček]

Právě se obávám, že tohle s tím přístupem Pythonu nemůže fungovat.

V Pythonu to bude "specifikované" aktuální implementací, jenž bude pravděpodobně plná prapodivných speciálních případů – tj. nikdo tomu nebude dost dobře rozumět, aby napsal runtime s implicitní paralelizací bez toho, aniž by rozbil existující programy.

Naopak, když je to pěkně specifikované, runtime přesně ví (nebo autoři runtimu), co si může dovolit implicitně paralelizovat a co už ne (ví jaká chování daného programu jsou přípustná).

[little.owl]

Právě se obávám, že tohle s tím přístupem Pythonu nemůže fungovat.

Az to bude potreba specifikovat, tak se to udela, i treba v dalsi nekompatibilni iteraci Pythonu.

V Pythonu to bude "specifikované" aktuální implementací, jenž bude pravděpodobně plná prapodivných speciálních případů – tj. nikdo tomu nebude dost dobře rozumět, aby napsal runtime s implicitní paralelizací bez toho, aniž by rozbil existující programy.

Python je velmi dobry ve vynucovani si 'jedne spravne cesty', takze tak horke to neni.

[Bedňa]

S tým sa nedá než súhlasiť, je fakt zbytočná práca stále to isté písať dookola, keď sa o to môže postarať jazyk(prekladač/kompilátor/JIT). To isté si myslím aj o pintrovej matematike a správcovi pamäte, keď sa to napr. v C++ musí riešiť cez frameworky aby programátor nezabíjal čas znovuobjavovaním kolesa.

[Radek Miček]

treba ted na jare pridali do jazyka nativni coroutines s async/await syntaxi.

IMO to také nesouvisí s paralelismem.

[mj41]

Některé samozřejmosti pro 21.století jako

perl6 -e'say 1 / (.1 + .2 - .3)' 
# Attempt to divide 1 by zero using div. Try your language .

(viz. 0.30000000000000004.com) nebo Unicode stringy prostě do Ruby či Pythonu bez porušení zpětné kompatibility nedostanete.

I kdyby se samotný Perl 6 neuchytil, tak z něj budou čerpat další dynamické jazyky tak jak to dělaly z předchozích verzí Perlu.

Pokud vás to zajímá více, tak doporučuji: Why would you want to use Perl 6? Some answers.
Should I be interested in Perl 6 ? (quora.com)
Parallelism, Concurrency and Asynchrony in Perl 6 + 6guts blog, slides
Perl 6 Features Matrix (trochu neaktuální)
RosettaCode - Category:Perl 6"
Perl 6 Advent Calendar blog
design.perl6.org

[xkucf03]

BTW: jak dobré je to MoarVM? Šlo by to použít jako obecné VM a postavit nad tím nějaký vlastní jazyk?

[Radek Miček]

Šlo by to použít jako obecné VM a postavit nad tím nějaký vlastní jazyk?

Myslím, že ano. Například oproti JVM a CLR to má alespoň částečnou podporu kontinuací.

[mj41]

Ano, ale primární určení je pro Perl 6 a žádné větší ústupky (další kód, který Rakudo Perl 6 nepotřebuje) asi Jonathan dělat nebude.
Vpodstatě tady je návod pro něco jako Ruby
Rakudo and NQP internals (na githubu)
NQP: rubyish
course - examples

a Python pokus je tady GitHub - snake
MoarVM
IRC Perl 6 search rubyish
IRC MoarVM search rubyish

[Bystroushaak]

(viz. 0.30000000000000004.com) nebo Unicode stringy prostě do Ruby či Pythonu bez porušení zpětné kompatibility nedostanete.

Tohle nevím jak si vysvětlit - unicode stringy jsou v pythonu někdy od verze 2.

[tuk]

Také netuším. V ruby bylo přechodné období v 1.9x, ale s 2.0 je to už konečně unicode. Kdyby tam nebyla ta čínština tak by ti japončíci to implementovali mnohem dříve .).

[mj41]

Já podporu v Ruby a Pythonu neznám, ale v Perlu 6 se tím myslí "Full grapheme based Unicode support, including Annex #29, meaning almost unparalleled excellent Unicode support." tj. graphemes, code points, bytes, normalizace, ...

Ve zkratce je to popsáno tady [1], [2], [3], [4], [5].

say "नि".chars;    # returns  1
say "नि".codes;    # returns  2

my $str = "D\c[COMBINING DOT ABOVE]\c[COMBINING DOT BELOW]";
say $str;           # Ḍ̇
say $str.chars;     # 1
say $str.NFC.codes; # 2

my $str = "D\c[COMBINING DOT ABOVE]";
say $str;       # Ḋ
say $str.chars; # 1
$str ~= "\c[COMBINING DOT BELOW]"; # ~ je spojovani stringu
say $str;       # Ḍ̇
say $str.chars; # 1

say "0".uniprop("Numeric_Type") # Decimal

say "\r\n".chars;               # returns 1
say "नि\r\n".substr(1,1).perl;   # returns "\r\n"

[little.owl]

Některé samozřejmosti pro 21.století jako

perl6 -e'say 1 / (.1 + .2 - .3)' 
# Attempt to divide 1 by zero using div. Try your language .

21 stoleti!? Jednoznacne minule stoleti, nebot tohle umi Common Lisp/PLT Scheme uz nekolik desetileti, viz i vas odkaz.

Unicode stringy prostě do Ruby či Pythonu bez porušení zpětné kompatibility

Python3 ma unikode nativne od sameho pocatku, Python2 unikod podporuje take jiz roky bez poruseni zpetne kompatibility.

I kdyby se samotný Perl 6 neuchytil, tak z něj budou čerpat další dynamické jazyky tak jak to dělaly z předchozích verzí Perlu.

Nemyslim, v realu novych konceptu je minimum.

[mj41]

21 stoleti!?

Ano, pro běžné dynamické programovací jazyky - Perl 5, Python, Ryby, PHP, ...

Python3 ma unikode nativne od sameho pocatku ...

Jop, je docela možné, že přeháním. Tohle není zase tak špatné. Co příklad z commentu s Normalization Form Graphemes (NFG)

my $str = "D\c[COMBINING DOT ABOVE]\c[COMBINING DOT BELOW]";
say $str; # Ḍ̇

my $str = "D\c[COMBINING DOT ABOVE]";
say $str;       # Ḋ
say $str.chars; # 1
$str ~= "\c[COMBINING DOT BELOW]"; # ~ je spojovani stringu
say $str;       # Ḍ̇
say $str.chars; # 1

?

[mj41]

Odpovím si sám. Viz NFG - slajd 54 Python 3 vs. slajd 63 Perl 6. Na slajdu 79 je vysvětlení.

[little.owl]

A? To ze nacpacili grafemy primo do jazyka jako zasadni vyhodu nevidim. Iterace pres grafemy by v Pythonu mela byt mozna v dalsich revizich, zatim se to resi treba pres knihovny jako uniseg.

[mj41]

Takže se shodneme, že Python 3 nemá takovou podporu Unicode jako Perl 6. A já jen přidávám, že nejspíše ani nikdy nebude mít kvůli držení zpětné kompatibility. Zásadní to určitě pro mnoho projektů není, ale plusový bodík pro Perl 6 to IMHO je. Hlavně třeba v Číně, Indii či Japonsku, kde chtějí, aby jim substr, length, ... fungovalo.

O knihovnách se nemá smysl bavit. Ano, jako workaround nebo experiment, zda se to ujme. Ostatně podobně to zafungovalo s Moose v Perlu 5. Aby to bylo obecně vhodné řešení, tak by všechny ostatní knihovny co pracují se stringy musely být nad touto knihovnou postaveny. A to už pak dává smysl, aby to bylo součástí jazyka.

[little.owl]

Takže se shodneme, že Python 3 nemá takovou podporu Unicode jako Perl 6.

Nema ji vestavenou v jazyku a neni to IMHO dobry napad.

A já jen přidávám, že nejspíše ani nikdy nebude mít kvůli držení zpětné kompatibility.

Proc? Jde opet o rozdilny pristup. Python oddeluje kodovani uzite na urovni jazyka a vnitrni reprezentace a kodovani na urovni zpracovani dat. Implementace Pythonu muze pouzivat nativni kodovani at se jedna o utf8/16/32 a na program zpracovavajici treba utf8 to nebude mit vliv. To co jste demonstroval vy, je ze Perl6 ma vestavenou funkci na pocitani grafemu, ale tohle neni problem dodelat, pokud bude poptavka. Jenze to zacne IMHO borit onu izolaci.

[mj41]

Asi si nerozumíme. Unicode je o grafemech. Říkat, že jazyk podporuje Unicode, ale nemá pro to funkce si protiřečí. Prostě, když si neuvědomuji, že je rozdíl stringy sekat po code-pointech nebo po grafemech, tak to samo fungovat nebude. To, že někde existuje knihovna, která to umí po grafemech na tom nic nezmění.

Bavíme se o high-level jazyku. Samozřejmě, že nakonec to jsou všechny bajty/bity a každý, kdo píše funkci/knihovnu co dělá něco se stringy by těmhle věcem měl rozumět a ošetřit je, ale jak často tohle nastává? A jaká je šance, že to někdo dodatečné vyřeší?

Unicode včetně grafémů, normalizace/ekvivalence do stringů high-level jazyka pro 21. století patří. Tohle je jedna z těch věcí, které Perl 6 právě teď diktuje.

[Miloslav Ponkrác]

perl6 nic nediktuje, na perl6 sere pes

[Miloslav Ponkrác]

Tento komentář nade mnou nepsal Miloslav Ponkrác, ale někdo za mě se vydávající. Ostatně poznáte to jednoduše, já už od včerejška na abclinuxu.cz komentáře nepíši a nikdy psát nebudu. Jakýkoli komentář pod jménem „Miloslav Ponkrác“ tedy bude na abclinuxu.cz pouze falešný a nikoli ode mě.

Netušil jsem, že bude někomu stát za to psát pod mým jménem.

Miloslav Ponkrác

[mj41]

Nemyslim, v realu novych konceptu je minimum.

A máte příklad jazyka, který přinesl více nových konceptů?

[Bystroushaak]

Tak zrovna třeba common lisp.

[mj41]

Myslel jsme samozřejmě bez Lispu . Po něm tj. po 90. létech minulého století toho už moc nebude.

BTW. Greenspun's tenth rule určitě znáte.

[Radek Miček]

Jaké nové koncepty CL přinesl? Nebylo téměř všechno již v nějakých jiných lispech a CL to jen trochu upravil a sjednotil?

[mj41]

Z hlediska novelity...

Tak ono nic nového se už vymyslet nedá. Vpodstatě všechno už je v nějakých 20+ let starých akademických paperech. Zbytek jsou už jen inženýrské problémy, tj. dostat to na stůl normálních smrtelníků v použitelné a konzistetní podobě.

Co se týče těch Lisp maker, tak obtíže s tím dostat makra do Perlu 6 jsou hezky sumarizovány v Carl Mäsak: Double-oh seven.

[little.owl]

Tak ono nic nového se už vymyslet nedá.

Tak to je kardinalni pitomost.


Perl6 a jeho tvurci mi prijdou jako generalove pripravujici se na minulou valku.

[mj41]

Bylo to se smajlíkem. Ale jak se píše v jiném vlákně. Všechno už bylo v Lispu před 30 lety.

... jako generalove pripravujici se na minulou valku.

Když nevíte jak ta příští válka bude vypadat, tak na co jiného se chcete připravovat? Nebo máte něco konkrétního? Např. ukázky z jiných jazyků. Na co se ty připravují a proč zrovna tohle je ta "budoucí válka".

[little.owl]

Pokud nevite jak to bude vypadat, je smesne vykrikovat cosi o jazyku pro 21.stoleti ci pro pristich 40 let.

Obecne si myslim, ze lepsi strategie je mit minimalni jazyk, ktery se bude konzervativne a opatrne rozsirovat jak zmeny budou prichazet a nebude pak tolik limitovan zpetnou kompatibilitou s predchozim over-engineeringem, s podstatnou casti funkcionality v externich knihovnach, ktere bych lze naopak rychle menit ci uplne nahradit.

[mj41]

Ja si myslim ze Perl 6 je vysledkem zpracovani nekolika stovek pripominek k Perlu 5, coz neslo udelat nejakemy minimalnim jazykem. To by pak nebyl Perl, ale treba Lua.

Je to jazyk pro pristich 100 let. Behem 40 lety by mel nahradit Perl 5. Multiple dispatch, gramatiky, slangs, zmeny jen v lexikalnim kontextu, ... to vse by to melo umoznovat. Perl 6 za par desitek let mozna nebude stejny Perl 6, ale ten jazyk je navrzen, tak aby se mohl vyvijet a nebylo potreba delat Perl 7.

Larry tusim nekde s usmevem rikal, ze Python/Ryby/PHP atd jsou vlastne jen jine slang/gramatiky Perlu 6 .

Uz se bavime moc hypoteticky. Proste si pockame a uvidime jak to dopadne. Shodneme se asi jen na tom, ze ja mam rad Perl a vy Python.

Kdyz to vezmu s velkou nadsazkou, tak ja nechapu jak muze nekdo programovat ve starem fasistickem jazyku se signifikatnimi whitespaces a pokladat jej za vrchol high-level jazyku. Vy zase nechapete jak muze nekdo o takhle komplexni jazyku, ktery ma v nazvu Perl a jeden z hlavnich autoru je Larry Wall tvrdit, ze je to pokrok a jazyk pro 21. stoleti a ze je lepsi nez Python. S koncem roku bych to takhle z me strany silvestrovsky zakoncil.

Diky za diskusi.

[mimi.vx]

protože se sekli jen o 10 let , a konkurence je tu tolik ze po perlu 6 nikdo ani nestekne a perl 5 pomalicku umre na upadajici zajem

[mj41]

To se teprve ukáže. Konkurence má teď co dohánět.

Zatím z Perlu 6 těží hlavně Perl 5. Viz. moje přednáška na Brno Perl Mongers.

Stejně tak bych mohl říct, ze Python 3 je fiasko, protože spousta programátorů a firem dále preferuje Python 2 a ten tady bude ještě dalších 10 let.

[⧠ A = 0]

Python 2 jsem opustil kvůli absenci podpory unicode identifikátorů a dnes bych si o něj ani kolo neopřel. To už bych to mohl rovnou prasit VE FORTRANU JAKO VSICHNI OSTATNI.

[kolcon]

to je otazkou perspektivy - Larry sam nekde rikal, ze Perl6 predbehne v pouziti Perl5 tak za 40 let ;)

bude zajimave sledovat, co se stane s CPANem - kdyby toho nekdo vyuzil a ten bordylek trochu procistil, mohlo by to pomoci. Zaroven by mohl nejaky guru zacit publikovat "the right way to do things in Perl6", ackoliv to jde proti TIMTOADY filozofii... (jakoze by se novacci nemuseli prohrabat stovkami podobnych knihoven na CPANu, delajicich skoro to same).

[little.owl]

to je otazkou perspektivy - Larry sam nekde rikal, ze Perl6 predbehne v pouziti Perl5 tak za 40 let ;)

Ja doufam, ze za 40 let bude programovani vypadat radikalne jinak. Stavajici "nove" jazyky, vcetne Perl6, jsou spise recyklovani znamych konceptu, s naivni virou, ze tentokrat se to udela spravne. Asi proto mira adopce, pokud to nema za zadkem silne hrace jako Microsoft, Google ci Apple je u nich mala.

Zaroven by mohl nejaky guru zacit publikovat "the right way to do things in Perl6", ackoliv to jde proti TIMTOADY filozofii...

Right way .... vyhoda Perl5 je, ze jeho vyvoj se fakticky zastavil, takze to co bylo napsano bude roky fungovat a co se clovek naucil bude moci roky pouzivat. Perl6 mi prijde navic cilen na jine uzivatele nez ktere ma Perl5.

[xkucf03]

vyhoda Perl5 je, ze jeho vyvoj se fakticky zastavil, takze to co bylo napsano bude roky fungovat a co se clovek naucil bude moci roky pouzivat.

V Javě se vývoj nezastavil, v každé verzi přibývají užitečné nové věci – a přesto je tam zpětná kompatibilita na luxusní úrovni.

[Jindra]

Perl6 bezi v JavaVM, to je to zlomove. Nyni je mozno pouzit 'normalni' jazyk ve vyzkousenem virtualnim stroji a kdyz neco nepobezi, tak je mozno pozadat 'cesky' pana Tisnovskeho, aby se na to podival.

[tom]

Todle porovnani je nesmysl, perl je mnohem flexibilnejsi nez java - novy syntakticky prvek je mozne pridat formou modulu. Priklad: Java ani perl nemely switch. Do javy se pridal switch pri aktualizaci jazyka, do perlu se nacetl modul (nez ho pridali do core interpretu).

[lojza]

ja doufam ze za 20 let bude programovani vypadat jinak, bude to vlastne modularni skladacka, milion modulu kazdy s vlastni funkcionalitou , kazdy s vice mustky na vstup a vystup a ja ja jen je budu pretahovat k sobe, samo se to pospojuje ani lepic nebude potreba ... takove puzzle nebo lego

[mj41]

To je docela možné, ale ty krabičky/moduly budou v Perlu 6 .

[xkucf03]

Na to nemusíš čekat dvacet let – to máš v Javě (volitelně s OSGi) už dneska.

[balki]

Dalsia istota padla, este Hurd 1.0 a moze nastat koniec sveta.

[mankind_boost]

Zapomněl jsi na Windows pod GPL.

[Michal2]

Jazyky bazirujici na odsazeni jsou zle. Pokazde, kdyz to pouzijete buh zabije kotatko.

[xkucf03]

A co když někdo onanuje nad Pythonem?

[⧠ A = 0]

Tak Hospodin zabije přímo jeho, to je zjevné [Gn 38, 1-10].

[Radek Miček]

IMO odsazování je přirozené, nevidím tedy důvod, proč toho nevyužít – z kódu se odstraní duplicitní informace a navíc se kód i zpřehlední.

Pokud strukturu kódu vyjadřujete pomocí odsazení v jazyce, jenž není citlivý na odsazení, porušujete vlastně DRY princip. Navíc mohou vznikat i následující chyby, kdy je duplicitní informace chybná:

if (x)
  if (y)
    foo();
else
  bar();

Ano, Python vás na rozdíl od Fortress nezachrání od následující chyby: a+b * c

BTW v Pythonu můžete psát:

if x:
  foo()
#endif

Je to ovšem opět duplicitní informace, která může být chybná.

[Josef Kufner]

Jen počkej, až budeš refaktorovat nějaký starší kód, nebo se snažit použít nějaký příklad z webu. To pak je rekonstrukce odsazování hotové peklo. Schválně si představ, že při překopírování se z tohoto:

if (x)
  if (y)
    foo();
else
  bar();

stane toto:

if (x)
if (y)
foo();
else
bar();

A teď jak ono to vlastně bylo? A co když foo není na jeden řádek, ale na dvacet? Není pak lepší mít něco jako:

if (x) {
if (y) {
foo();
}
} else {
bar();
}

Neboť z toho lze snadno kód naformátovat zpět?

[kyknos]

to se mi tedy jeste nestalo :D

[Bystroushaak]

A nebo ti při kopírování z webu přijdou uvozovky ala „“ (to dělá wordpress). Řešení je buďto nekopírovat sračky z webu, nebo si zobrazit zdroják a kopírovat to z něj, ne nadávat na jazyky. A zrovna refactoring v pythonu není žádný problém, dělám to každou chvíli.

[xkucf03]

A nebo ti při kopírování z webu přijdou uvozovky ala „“ (to dělá wordpress)

Nechápu, jak může někdo redakční systém takhle zprasit. Když jsem tohle¹ implementoval já, tak jsem použil XSLT a jednoduše tam rozlišuji, jestli jsem uvnitř <p>…</p> nebo naopak <pre>…</pre> či <code>…</code> a podle toho se k tomu chovám buď jako k přirozenému textu nebo zdrojovému kódu.

_{[1] resp. já tam neřeším uvozovky, ale přidávám nedělitelné mezery – princip je stejný}

[Heron]

Ve Wordpressu je především problém nějaký kód vůbec vložit. Ve standardní nabídce není ani podpora pro <code> a <pre> je uvedeno v menu odstavce (což nevadí, ale ne každý kus kódu je vhodné vkládat na samostatný odstavec - např samostatný příkaz nebo parametr uvedený v textu).

Takže je nutno spoléhat na pluginy, pokud nejsou k disposici, tak je ve WP docela těžké dobře naformátovat technický článek.

[Radek Miček]

Optimalizovat jazyk na kopírování kódu z pochybných zdrojů mi nepřijde jako přesvědčivý argument. Kód se minimálně stejně často čte jako se zapisuje, tedy optimalizoval bych spíše na čtení (pokud je k dispozici jen jedna reprezentace kódu).

Nepříjemné ovšem je, že citlivost na odsazování může jazyk zkomplikovat (a to i výrazně).