Kvantová fyzika v Perlu

20.8.2009 19:36 | programování

use Modern::Perl;
use Perl6::Junction qw/any all/;
my @numbers = 1..5;
say "Yes" if any(@numbers) == 3;
say "Nope" if not all(@numbers) == 5;

Není to hezké? Viz Perl6::Junction a Exegesis 6.        

Komentáře

[Marek Bernát]

Ako je to implementované? Len trochu syntaktického cukru pre funkcionálne programovanie a lambdy? Vyzerá to (s trochou fantázie) rovnako ako lispovské (some (lambda (x) (= x 3)) list)

[zoul]

Tohle je verze pro Perl 5, která je implementovaná jednoduše přetížením operátorů – viz například zroják pro All. O implementaci v Perlu 6 vím pendrek. V šestce se ale junctions dají použít i v typech:

my Color::RGB | Color::CMYK $color;

…takže už to asi nebude tak úplně jednoduché.

[Marek Bernát]

Ugh, to je ale odporný zdroják -- všetky tie funkcie sú úplne identické To sa v Perle nedajú takéto veci abstrahovať? V Lispe by som si napísal makro a iteroval cez operátory, celý ten zdroják by sa mi zmestil na 10 riadkov Podobná vec ma nedávno naštvala v pythone. Keď chce človek preťažiť operátory + - *, atď. pre triedu, tak sa to tiež nejak rozumne nedá (aspoň ja o tom teda neviem), ale treba pre každý z nich (__add__, __sub__, atď) písať skoro identické funkcie, ktoré sa líšia len operátorom použitým vnútri (v mojom prípade dôsledok toho, že + sa nedá použiť vo funkciách ako map, lebo to nie symbol, ale syntax). Všeobecne sa mi zdá, že všetky jazyky so záplavou syntaxe nie sú schopné abstrahovať takéto veci. Ale počul som, že Perl 6 má mať nejaké makrá, takže tam to snáď bude lepšie.

[zoul]

Třeba num_eq a num_ne jsou až na operátor stejné, to ano, ale jinak se většina funkcí nějakým drobným a podstatným detailem liší. Kdyby je měl autor nějak abstrahovat, asi by to dalo víc práce než napsat takovýhle zdroják a výsledek by byl v některých ohledech méně srozumitelný než současná verze.

Keď chce človek preťažiť operátory (…) pre triedu, tak sa to tiež nejak rozumne nedá (aspoň ja o tom teda neviem), ale treba pre každý z nich (…) písať skoro identické funkcie, ktoré sa líšia len operátorom použitým vnútri (…)

No jo, ale tady je klíčové to slovo skoro identické. Příliš tomu nerozumím, ale připadne mi, že právě kvůli těmhle odchylkám je rychlejší a praktičtější nechat vyspělých stylistických vylomenin a prostě to napsat ručně.

[Marek Bernát]

Toť holt otázka, v každom to prípade to ale na prvý pohľad vyzerá ako strašne veľa duplikácií, ktoré sa správny programátor snaží abstrahovať. Že sa syntax vo väčšine jazykov abstrahovať nedá je už druhá vec. Preto ľudí, ktorí neprišli do kontatku s Lispom (alebo niečím ako Smalltalk, kde sa dá zasa skoro všetko abstrahovať pomocou objektov a posielania správ), takéto myšlienky asi ani nenapadnú -> jediná abstrakcia kódu je pre nich funkcia a nič vyššie nie je k dispozícií.

To je síce pravda, ale nie je to pointa. Ide o to, že keby napríklad "+" nebola len špeciálna syntax, ale normálny first-class object jazyka, tak sa nemusím so špeciálnou syntaxou pre __add__ srať. Takisto v tom Perle by nebol dôvod používať num_eq, ale proste by sa použilo "=" -- samozrejme teoreticky, lebo v praxi má Perl asi tak ozrutný a nevypočítateľný kompilátor, že by to nerozdýchal (čítaj nesparsoval)

A ďalej: predstavme si hypotetickú situáciu, že tie operátory chcem skutočne predefinovať podľa nejakej šablóny, ktorú len naplním nejakými dátami špecifickými pre každý operátor. Dá sa toto v Perle nejako urobiť, alebo to musím všetko datliť ručne? Dôvod je, že v Lispe by z takejto knižnice ako Junction nikto extra nadšený nebol, lebo si ju vyrobí na kolene za 5 minút V Perle je to asi iné, keď človek musí všetko písať ručne (a zrejme sa to nevyhne copy-pastu a zanášaniu chýb, proste klasická duplikácia...) a každý je nadšený z každého nového kúsku syntaxe, ktorý dá niekto krvopotne dohromady

[zoul]

Tohle si tak mocně koleduje o flamewar, až radši s dovolením nebudu odpovídat.

[Marek Bernát]

Nerozumiem, či sa vyjadrujem až tak strašne, ale takto to rozhodne nebolo myslené. O Perle sa často hovorí ako o veľmi mocnom jazyku, tak by som sa skrátka rád dozvedel, či v ňom môžem robiť to isté (alebo snáď viac) ako v Lispe a/alebo iných zaujímavých jazykoch a dúfal som, že na niektoré implicitne položené otázky zodpovieš. Ak som niekoho urazil, tak sa ospravedlňujem a nabudúce skúsim tie myšlienky formulovať trochu inak.

[default]

Ak som niekoho urazil, tak sa ospravedlňujem a nabudúce skúsim tie myšlienky formulovať trochu inak.

Tak to bych ti doporučoval. A nejen trochu jinak, ale úplně jinak.

[Marek Bernát]

Bah, tak to zas nie. Nebudem si otáčať osobnosť o 180 stupňov (aj keby sa to dalo)

[Michal Vyskočil]

(v mojom prípade dôsledok toho, že + sa nedá použiť vo funkciách ako map, lebo to nie symbol, ale syntax)

Kde přesně se to nedá použít? Nenapadá mě případ, kdy by to měl být problém. Ale i kdyby byl, vždycky se dá namísto a + b je vždy možné napsat a.__add__(b), což je obyčejný symbol.

[Marek Bernát]

>>> map(+, [1], [2])
...
SyntaxError...

 

Povieš mi, ako zrealizovať toto?

Btw, volať __add__ priamo je mi načo? To snáď zabíja celú pointu operátorov, nie? Ja by som bol rád, keby bol + gumený first-class objekt a mohol by som s ním robiť, čo sa mi zachce. Bez toho ma totiž python núti písať kopu balastu a rôzne obchádzať problémy (napríklad v tom map zabaliť plus do lambdy, čo je fakt úžasné riešenie...).

[Martin]

No, fanoušek funkcionálního programování si v Pythonu moc neužije. Bohužel. Kvído buď funkcionálnímu programování nerozumí nebo mu rozumí a v Pythonu jeho vlivy nechce. Osobně to vidím spíš na první případ, nechce se mi věřit, že by někdo vyměnil některé elegantní funkcionální konstrukce za hromádku balastu. I když, stačí se podívat na většinu "moderních" jazyků a jeden se hned divit přestane. V Pythonu holt spousta hezkých postupů nefunguje.

To, co jsi napsal má být asi něco jako haskellovský zipWith, ne? map bere funkci a jeden seznam.

Prelude> zipWith (+) [1, 2, 3] [4, 5, 6]
[5,7,9]
Prelude> :t map
map :: (a -> b) -> [a] -> [b]
Prelude>

Jinak máš ale samozřejmě pravdu.

[Martin]

Hm, tak jsem si map v Pythonu vyzkoušel a beru zpět svou námitku na ten tvůj kód výše. Sorry.

[Marek Bernát]

Nie, ja sa ospravedlňujem. V Haskelli je map samozrejme aplikácia unárnej funkcie, ale z CL som zvyknutý na map, ktorý berie n-árnu funkciu a n zoznamov

[Marek Bernát]

Btw, keď sme pri tom, ako by sa tých n argumentov riešilo v Haskelli? Funkcia zipWith napovedá, že nijak Alebo mu proste hodiť ako druhý argument zoznam zoznamov? To by snáď mohlo fungovať. Ale bol by to trochu menej pekný zápis než to CL a python (ktorý sa zjavne nejednou vecou z Lispu inšpiroval).

[Ondrej 'SanTiago' Zajicek]

> Alebo mu proste hodiť ako druhý argument zoznam zoznamov?

Pak by ale musel dostat funkci, ktera prijima seznam hodnot. A tedy by vsechny seznamy na vstuypu musely byt stejneho typu.

[Martin]

V Haskellu je proměnný počet argumentů vcelku problém a jsem v jeho učení teprv na začátku, takže nejsem schopen fundovaně odpovědět. Snad jen alespon citace z knihy.

Haskell's type system makes it an interesting challenge to write functions that take variable numbers of arguments[8]. So if we want to zip three lists together, we call zip3 or zipWith3, and so on up to zip7 and zipWith7.

...

[8] Unfortunately, we do not have room to address that challenge in this book. (a to má ta kniha 700 stran ).

V komentáři jeden z autorů knihy píše:

It's not possible in Haskell98. With the upcoming type families extension (and GADTs), you get enough of the power of dependent types to write zip(With)N without too much trouble:

http://hpaste.org/7116

But that's out of the scope of this chapter, and probably the entire book.

(It might be possible to do with the tricks used in HList, too, but that's still not going to be H98.)

Určitě by to šlo nějak obejít (i když nepochybně méně elegantně a transparentně jako v CL), zkusím se nad tím se svými velmi skromnými znalostmi zamyslet.

[Marek Bernát]

Hm, takže skutočne nijak. Hacky by možno šli, ale to neberiem A čo sa týka rozšírení jazyka, tak tadiaľ možno cesta vedie, ale otázka je, aký by to malo následok na odvoditeľnosť typov. A tam si netrúfam ani hádať, lebo ten Haskellovský type inference ovládam tak možno z rýchlika

[Martin]

Hm, jak nad tím tak uvažuju... Je možné, že teď budu psát úplné ptákoviny, jsem rád, že napíšu v Haskellu něco primitivního a jsem ještě radši, když tomu i doopravdy porozumím, ale stejně, aspoň bude zábava.

Haskell stojí na lambda kalkulu. V něm každá funkce bere jeden parametr a vrací jinou funkci. Takže když v Haskellu napíšu tuhle funkci

add :: (Num a) => a -> a -> a
add x y = x + y

tak se interně převede na něco jako

add' :: (Num a) => a -> a ->
add' = \x -> \y -> x + y

Prostě volání funkce více proměnných je cukr pro currying. Ostatně o tom už vypovídá i sama typová signatura původní funkce.

Není právě v tomhle problém s funkcemi o libovolném počtu argumentů? Jestli ona náhodou není u každé funkce potřeba přesná informace o počtu argumentů, právě kvůli curryování. I když teda netuším, jak vypadají vnitřnosti GHC nebo dalších kompilátorů/interpretů.

[Marek Bernát]

Podľa mňa v netypovanom lambda kalkule by s tým nemal byť problém. Skrátka, keď máš viac argumentov, tak curryuješ dovtedy, kým sa nedostaneš nakoniec. Ale jak je to s typovaným lambda kalkulom a hlavne s následným type inference, to je práve otázka.

[Martin]

Pravda. Někde tam možná bude v případě Haskellu potíž.

Zajímavé věci jsou to, štve mě, že o nich zatím moc nevím. Ale za poslední rok už jsem se stal tak frustrovaným C++, Javou a dalšími mainstreamovými jazyky, že tentokrát už se snad přes jistou kritickou hranici ve funkcionálním programování konečně přehoupnu. Haskell už jsem se v minulosti totiž "učil" asi třikrát a nikdy jsem neměl dostatek motivace.

[Marek Bernát]

Haha, ja som sa ho zatiaľ učil len 2x, z toho ten druhý krát už som si aj napísal jeden miniprogram a bol to celkom zážitok. Chvíĺu mi trvalo, kým mi došlo, že celý stav programu musím mať na stacku a event loopu ho stále znova rekurzívne posielať Dosť to zmení človeku pohľad na to, čo je to programovanie. Ale potom som s tým zas prestal, lebo som nenašiel rozumný spôsob ako rozumne pracovať s grafmi a viacrozmernými poľami -- opäť raz, imperatívne programovanie zabalené v monadoch neberiem -- a neskôr som zistil, že nie som sám, že téma funkcionálne grafy je predmetom moderného výskumu No a teraz mám zrovna Lispovské obdobie. A pri Lispe zostanem, až kým ho dokonale nepochopím; potom dostane šancu (znova) Smalltalk a Haskell

[Martin]

Pokud jde o to posílání stavu "za oponou", tak tam jsou opravdu odpovědí ty monády. Zatím tuhle problematiku jenom lehce nakusuju, autoři Real World Haskell kolem ní tancujou ze začátku jen zlehka, ale pomalu mi začíná docházet, k čemu to je. Oni to maj kucí vod Haskellu sakra dobře vymyšlený, jenom to občas chce pořádně zatnout zuby.

A pri Lispe zostanem, až kým ho dokonale nepochopím; potom dostane šancu (znova) Smalltalk a Haskel

Mám podobný plán: konečně dotlouct mou znalost Haskellu do použitelného stavu, do té doby nezačínat s ničím jiným (jak má moje přelétavá mysl ve zvyku). No a pak se uvidí, vidím to buď na Erlang, Lisp nebo Adu. Ten Lisp mi už dávno uhranul stejně jako Haskell, ale jelikož mě vcelku začaly zajímat safety-critical systémy, tak mi bude asi užitečnější ta Ada. Dal jsem si předsevzetí, že jestli se jednou budu opravdu živit programováním, tak budu programovat kosmické loďe. Jen proboha co nejdál od ubohého života běžného aplikačního nebo webového programátora a jeho Javy, PHP, C++ a dalších zrůdností.

Na Lisp se ale vždycky budu dívat s respektem. Mám dojem, že nic lepšího už se nevymyslí a lidi se budou pořád snažit vymyslet hranaté kolo, než jim dojde, že Lisp "got it right" už v roce 1958.

[Ladicek]

Existuje stařičký vtip, že vývoj programovacích jazyků pomalu a jistě konverguje k Lispu Já bych k tomu dodal: je možné, že po spirále.

[Marek Bernát]

Stavy "za oponou"? Čo si mám pod tým predstaviť? Tým myslíš tú reprezentáciu stavov monadmi?

Safra, čo je to tá Ada? Stále na ňu narážam v týchto diskusiách, ale vlastne o nej nič neviem. Takáto neznalosť je neznesiteľná, musím to ísť hneď naštudovať

Hm, tak ja sa tým úbohým PHP živým (teda živým nie je presné: je to viacmenej len cez leto na brigádu a navyše u známeho. Inak by ma k tomu nikto nedostal ani pod hrozbou smrti ) a ako som hovoril, snažím sa doňho pretlačiť myšlienky z normálnych jazykov kde sa dá. Dnes som však narazil na to, že je to extrémne pomalé (teda ešte viac ako bežne), takže budem musieť niektoré koncepty (domontoval som tam také pseudo meta triedy ala smalltalk, aby som mal väčšiu kontrolu nad triedami a vo výsledku si polovicu OOP robím sám, lebo to v PHP je pekne povedané na nič) možno nakoniec budem musieť zahodiť. Ach kiež by som radšej o tých jazykoch nič nevedel a všetko pekne prasil bez myslenia. O čo by bol život ľahší! Alebo sme mali už pred niekoľkými rokmi prejsť na iný systém v rozumnom jazyku -- nedávno som sa náhodou dočítal o Weblocks, ktorý je založený na call/cc (nádherný spôsob ako uviesť stateless HTTP protokol do života), a tiež UCW, v ktorom je zasa web reprezentovaný nejak funkcionálne. Čo tí ľudia nevymyslia... Lenže takéto prechody sú dobré len z dlhodobéno hľadiska a trvá dĺĺĺho, kým sa človek znova dostane tam, kde už bol so starým systémom, takže v praxi sa to nikdy nestane. Jediný systém, o ktorom naozaj viem, že ten prechod spravil, je KDE a trvalo to fakt dlho a aj tak je otázka, že kam presne sa to presunuli

Presne takto to vidím aj ja, preto sa mu venujem najprv, než sa budem snažiť vymyslieť to koleso v ostatných jazykoch Btw, poznáš Gang of Four a Design Patters pre Javu? Kedysi, keď som bol mladý a neskúsený a poznal som len C++ a začínal sa učiť Javu, tak som si myslel, že je to geniálna vec. Ale nikto mi vtedy nepovedal, že sú to všetko len techniky ako zakryť rôzne slabiny Javy a v silnom jazyku je väčšina tých techník buď priamo v jazyku a človek ani nemusí vedieť, že ich používa, alebo nie sú vôbec potrebné

[Marek Bernát]

s/živým/živím/g. Takáto chyba a hneď 2x. Občas si pripadám ako neandrtálec

[Martin]

Jo, něco takového jsem měl na mysli. Ale zatím jsem se k tomu nedostal v "reálném použití", takže jenom teoretizuju. Možná za pár týdnů budu schopen zapojit do diskuze o výhodách a nevýhodách monád, dříve ale raději ne. Mám v hlavě dva nebo tři projekty, pomocí kterých bych si rád v Haskellu "nabrousil zuby" a konečně si ho vyzkoušel v praxi. Už aby to bylo, po bakalářce v C++ a letošní traumatizující Javě potřebuju odreagování.

Ada je statický, silně typovaný imperativní jazyk navržený na začátku osmdesátých let pod taktovkou amerického ministerstva obrany. Je de facto standardem pro mission-critical aplikace v letectví, kosmonautice a dalších podobných oblastech. Pokaždé, když o něm čtu nebo v něm vidím napsaný nějaký kód, tak mě naprosto praští do očí (v dobrém smyslu) jeho bezpečnost. Díky své ukecanosti a pro někoho až přílišnému důrazu na nejen typovou bezpečnost na něj v běžném softwaru ale nenarazíš. Ale tam, kde opravdu záleží na neprůstřelnosti se vyskytuje velmi často. Zrovna včera jsem si přečetl článek vydaných pod ESA o jejím použití—mikročipy pro vesmírné satelity navržené přímo pro běh Ady a další vychytávky, moc zajímavé. Potřeboval bych se naklonovat.

ako som hovoril, snažím sa doňho pretlačiť myšlienky z normálnych jazykov kde sa dá

No, to je právě věc, která mě na představě "programování" děsí nejvíc. Tohle si můžeš dovolit, když děláš na nějakém víceméně komorním projektu. Jakmile se ale dostaneš do normální práce a musíš tu Javu nebo PHP bušit mezi desítkami dalších opiček, tak musíš poslušně sehnout hřbet a mlčet. Většina kolegů totiž o nějakých higher-order funkcích na funkcionální straně nebo meta-třídách na objektové straně nikdy neslyšela. Máš to jednoduchý, seš fyzik a tohlencto je pro tebe koníček. Já musím hledat cestičky, kde se dá.

Btw, poznáš Gang of Four a Design Patters pre Javu? Kedysi, keď som bol mladý a neskúsený a poznal som len C++ a začínal sa učiť Javu, tak som si myslel, že je to geniálna vec.

Ba, poslední rok jsem se s tímhle setkával. Myslel jsem, kdo ví jak tohle všechno není geniální. Těžce jsem narazil.

Mimochodem, jen tak pro zajímavost: nedávno jsem narazil na toto. Vcelku jsem čuměl.

[Marek Bernát]

Hm, tak podľa mňa monády nemajú nejaké veľké nevýhody a je to určite zaujímavý spôsob jak ochcať side-effecty Len čo mi na tom vadí, je, že Monády sú často (podľa toho kódu, čo som zatiaľ našiel na nete) zneužívané na písanie efektívne imperatívneho kódu. A to už môžeš rovno ten Haskell zahodiť, keď chceš písať takým spôsobom... Jasné, že občas sa tomu nedá vyhnúť a na nejaké jednoduché veci je to ok a lepší prístup ma ani nenapadá (napríklad generátor náhodných čísel, ktorý si efektívne pamätá posledný stav a tiež  IO), ale je škoda, že ľudia sa kvôli nim nesnažia vymyslieť niečo nové. Na druhej strane, v praxi je ti asi jedno, ako ten program vyzerá a hlavne, že bude fungovať a Monády dávajú aspoň akú takú šancu simulovať stav. Ale dúfam, že sa na to teda tiež pozrieš a pridáš potom svoje dva centy

Už som si to pozrel a prvé, čo ma praštilo do oči bolo "Pascal" Myslím, že takýto jazyk by som už nedokázal používať, akokoľvek je bezpečný a neviem čo všetko ďalšie Ale zlé to asi nebude, tie aplikácie, čo popisuješ sú celkom hardcore Btw, klonovanie ti nepomôže, keďže klon je separátna entita a takéto nápady väčšinou končia tým, že klon zabije originál, aby získal jeho miesto To sa už radšej staň kyborgom

Hehe, to je pravda. Ale raz som už bol zamestnaný asi mesiac aj v banke, písala sa nejaká aplikácia v Jave (IMHO vcelku triviálna pre jedného človeka na pár dní), ale bolo tam asi 20 ľudí, z ktorých väčšina nič nerobila (= písali analýzy). Ten prvý mesiac som mal tiež navrhnúť nejaké modely pre tú aplikáciu (= nakresliť UML diagram ) a fungovalo to tak, že som tam celý mesiac nič nerobil, každý deň som si nakreslil jeden boxík a išiel som zasa domov. Po mesiaci som dostal celkom slušnú výplatu. Od toho okamihu mi bolo jasné, že veľké firmy nie sú nič pre mňa a už ma tam nevideli S tou fyzikou to ale tiež nie je úplne ružové. Uplatnenie absolútne nulové, jediné moje šťastie je, že ma to baví, takže by som rád robil vedu, tj. študoval a vymýšľal sprostosti (to robím v hojnej miere už teraz ) a ešte by mi za to snáď mali platiť. Dúfam, že to vyjde

A čo je na tom Fragu prekvapujúce? Že Haskell má slušný FFI? To viem už dávno, od kedy mi tu beží xmonad Že sa v ňom parádne programuje, to je bez debaty a kód je často niekoľkokrát kratší, bezpečnejší a robustnejší ako v bežných jazykoch. A že to nie je vo výsledku ani pomalé je tiež celkom známa vec

[Martin]

No však jo, tak funguje i ten Pythonovský map, akorát jsem o tom nevěděl.

>>> list(map(lambda x: x, [1, 2, 3]))
[1, 2, 3]
>>> list(map(lambda x, y: x + y, [1, 2, 3], [4, 5, 6]))
[5, 7, 9]
>>> list(map(lambda x, y, z: x + y + z, [1, 2, 3], [4, 5, 6], [7, 8, 9]))
[12, 15, 18]

To volání list() je tam proto, že Pythonovské map, filter a další od verze 3 evidentně vrací iterátor. Další změna, o které jsem doteď nevěděl.

[Marek Bernát]

No veď ja o tom viem, tie lambdy som si pred pár dňami tiež sám skúšal a tak som narazil aj na ten samostatný +

Lazy evaluation je ďalšia dobrá vec z funkcionálnych jazykov; čudoval by som sa keby ju Python časom neprebral

[Michal Vyskočil]

>>> map(+, [1], [2])
 ...
 SyntaxError...

Povieš mi, ako zrealizovať toto?

Začal bych čtením dokumentace, bez toho se neobejdeš u žádného jazyka Pak by ses přestal rozčilovat, že nemůžeš použít syntaktický prvek jazyka v takovémto kontextu. V Lispu taky nemůžeš plácnout závorky a čárky kam tě napadne. A Pythno má halt té syntaxe víc.

[Marek Bernát]

To si ale úplne zmenil tému. Tu nejde o nejakú syntaktickú štruktúru jazyka (resp. len nepriamo), ale o to, že python je pre funkcionálne programovanie dosť nevhodný. A hoci to platí o mnohých iných jazykoch a nebolo by to nič zvláštne, keby nebolo faktu, že python polovicu vecí z funkcionálneho programovania podporuje, takže vo výsledku je to taký polofunkčný bordel. Proste môj výsledný dojem je, že autor(i) lepia do jazyka čo sa dá bez ohľadu na nejaký hlbší pohľad na vec. Ale radšej už končím, nemá moc cenu poukazovať fanatickým zástancom jazyka jeho nedostatky. Niekto holt nie je schopný pochopiť objektívnu kritiku, a radšej sa bude brániť svätým písmom (dokumentáciou)...

[zoul]

(…), takže vo výsledku je to taký polofunkčný bordel. Proste môj výsledný dojem je, že autor(i) lepia do jazyka čo sa dá bez ohľadu na nejaký hlbší pohľad na vec.

Myslím, že by neškodila trocha skromnosti a pokory. Zvlášť pokud nemáš s programováním větší praktické zkušenosti, což podle všeho nemáš. Vozit se po prakticky orientovaných jazycích s poukazem na Lisp nebo Haskell je ve většině případů čistě klukovina.

[Marek Bernát]

Neberiem pythonu, že je to zaujímavý jazyk a neprogramuje sa v ňom zle, ale na niektorých miestach to proste škrípe. Ja stále nedokážem pochopiť to neakceptovanie objektívnej kritiky. To nesmiem ani otvoriť hubu? Ak tú kritiku vieš vyvrátiť, tak ju vyvráť, ale nesnaž sa zviesť rozhovor úplne iným smerom. Ak ťa to uspokojí, tak programujem tak od 10 rokov, prešiel som za ten čas už vyše 10 jazykov, riešil som olympiády z programovania a informatické korešpondenčné semináre a ďalšie súťaže, vymyslel som kopu algoritmov a mám tiež dosť veľké skúsenosti s formálnymi jazykmi, kompilátormi, logikou a ďalšími pokročilými technikami + mám za sebou aj prax (=zamestnanie) v Pythone, C++, Jave a PHP. Je to dostatok na to, aby som mohol vyjadrovať svoj názor?

[podlesh]

No jo, jenomže Python byl dělaný tak aby funkcionální pokud možno nebyl. Nebo alespoň já z něj mám takový dojem. Především z celé lambda konstrukce ("tak to tam teda dáme když to tolik chtějí, ale pořádně jim to osladíme") a nebo třeba to že zjištění délky sekvence je prostá globální funkce a ne metoda (tedy já vím, že tam ta metoda je, ale přijde mi to docela jako obstrukce).

[Marek Bernát]

Yup, python je v tomto a ďalších veciach dosť zvláštny jazyk a napriek proklamovanej čistote a TIOOWTDI je to pekný bordel (ktorý sa snáď s každým releasom trochu učesáva). AFAIK tam tie map/filter/reduce/lambda boli takmer od začiatku, lebo je jasné, že je to mocný koncept (aj keď list comprehensions robia kopu z obyčajného funkcionálneho kódu zbytočným), ale je to len taký polodokončený nepodarok, takže sa to aj tak poriadne použiť nedá -- ako som už písal inde, funkcionálne programovanie, aby bolo efektívne, tak potrebuje všetko: higher-order functions, uzávery, currying a to všetko pekne integrované s jazykom. Tak ako je to v pythone, tak sa síce dajú použiť nejaké veci, ale nie je to zďaleka ono a výsledok je rozpačitý. Ostatne, funkcie map/filter si môžem napísať aj v C a budú brať void*, kam nacpem pointer na funkciu a výsledok bude podobný ako v pythone

[pht]

No, a taky

for all(@numbers) { ... }

se vykoná pokud možno paralelně.

A junctions jsou jen jedna z asi deseti takových hezkých věcí v Perlu 6.

[l4m4]

S kvantovou fyzikou to nemá nic společného. Kvantové superposice půjdou dělat nejdřív, až bude v Perlu fungovat

$s = "foo" + "bar"i;

kde i je imaginární jednotka.

Text u modulu Quantum::Superposition je buď špatný vtip, nebo ho psal idiot (nedovedu rozlišit).

[zoul]

Text Q::S je zjevně vtip, viz například závěrečný odstavec:

Unfortunately, the math required to design and use quantum algorithms on quantum computers is painfully hard. The Quantum::Superpositions module offers another approach, based on the superposition of entire scalar values (rather than individual qubits).

Mně to legrační přijde. A paralela s kvantovou fyzikou je též jen velká licence, podle mě opět celkem zábavná. Pokud je současná implementace v pětce dělaná přetížením operátorů, asi všichni chápeme, že to má do kvantové fyziky daleko. Stejně je ale hezké si představit výraz any(qw/…/) jako „součet stavů“. Proč si to trochu neužít – však od toho programujeme v Perlu a ne třeba v Javě :)

[l4m4]

Není to hezké, je to matoucí.

Rozdíl mezi alternativami (to, co implementuje ten Perl modul, jednoduchá klasická pravděpodobnost) a superposicí (aditivní stavy, kvantová pravděpodobnost) je asi jako rozdíl mezi dělením se zbytkem a pistáciovou zmrzlinou. Navzdory tomu, že to populární výklady běžně matlají do jednoho...

Takže taková představa nijak nepomáhá při programování.