Jazyky a překladače - 7 (sémantika a typy 2) (diskuse)

[Ladicek]

Ehm, mno… hezké, že… trochu jako článek Pavla Křivánka onehdá na rootu… ale ten ho aspoň nevydával za součást seriálu o překladačích

[Bluebear]

Bohužel tenhle konkrétní díl opravdu vyznívá spíš jako chvalozpěv na dynamické jazyky než jako racionální výklad.

Aby bylo srovnání jednotlivých jazyků (přesněji řečeno filozofií) relevantní, bylo by třeba u každého jazyka uvést, za jakých okolností vznikal, k čemu byl původně určen a co vedlo jeho autor(y) k volbě právě takových a ne jiných postupů. Pak by se dalo diskutovat o tom, zda tyto důvody jsou stále platné nebo už pominuly.

[Kyosuke]

Místo amean(list&ltT;>* lst) tam určitě melo být amean(list<T>* lst), že? Jinak v Ruby by to bylo takhle:

def amean(l)
    l.inject(0){|a, x| a+x/l.size}
end

[jard]

# efektivnejsia verzia ? naco ruby dalej zbytocne spomalovat...

def amean(l)
    l.inject(0){|a, x| a+x} / l.size
end

[Kyosuke]

Chachá, čekal jsem, kdo nepochopí skrytý fígl. Napiš si pořádný unit test.

[rane]

Tak potom takto (síce bez skrytého sexy fígľa, ale aspoň je to efektívnejšie):

def amean(l)
    begin
        l.inject(0){|a, x| a+x} / l.size
    rescue ZeroDivisionError
        nil
    end
end

[Kyosuke]

OMG, výjimku na tohle? To je ještě horší. Kdepak, já se naučil oceňovat kouzlo kódu, ve kterém se nemusejí řešit řídicí konstrukce a speciální případy. Vektor délky 0 řešený IFem je pro mě prostě speciální případ a je na funkci vyššího řádu, aby se poprala s tím, jestli se vůbec něco bude dělit nebo ne. Pro mně to snižuje složitost kódu v hlavě. Chuck Moore jednou napsal 20 stránek kódu bez jediné řídicí konstrukce, skoku, podmínky nebo podobného větvení! (Sakra, začínám si uvědomovat, že Chuck Moore je počítačový Chuck Norris, teda s tím rozdílem, že jeho šílené výkony jsou realita – viz OKAD, F21 a podobně. ) Mmch, není na to taky nějaká ta metrika? McCabe nebo jak se tomu to.

[Tom.š Ze.le.in]

Mně zase přijde horší definovat na náhodnou hodnotu (zde 0) matematicky nedefinovaný případ, a vyhození výjimky mi přijde jako druhé nejkorektnější řešení. Hint: když ke každému prvku sekvence přičtu 5, očekávám, že se průměr zvedne o pět, ne že zůstane stejný. Ať si tu výjimku zachytí a zpracuje ten, kdo to tak blbě volá.

Možná jako ještě korektnější mi přijde předávat jako další parametr funkce požadovanou návratovou hodnotu funkce pro ten speciální případ (což lze implementovat oběma způsoby, chytáním výjimky i zadáním výchozí hodnoty pro reduce či ekvivalent a přičítáním podělené věci), včetně možnosti určit že to má řvát^H^H^H^Hvyvolat výjimku.

A kromě efektivity pro to nejdřív sčítat, pak celé dělit možná mluví také obavy ze zaokrouhlovacích problémů u sekvencí s hodně prvky a nepřesnými čísly.

[Kyosuke]

Trošku jsem nepochopil, kde definuju něco nedefinovaného. Jinak tedy pokud jde o zaokrouhlování, počítám s typem Rational. Počítal jsem s tím, že u celých čísel na vstupu to stejně vede na zlomek. A nějakou opravdu hromadnou matematiku nota bene s floaty bych stejně asi dělal jinak, chci si udělat něco malého runtimového na generování SSE kódu, abych se naučil trošku assembler.

[Tom.š Ze.le.in]

Přišlo mi, že tou nulou za inject definujete, že pro prázdnou sekvenci bude výsledek nula. Průměr prázdné množiny čísel je IMHO neučitý výraz typu 0/0, tedy pro běžné účely nedefinované. Ale kód jsem nespouštěl a daný jazyk pořádně neznám, takže se můžu plést.

[rane]

Ok. Je to proste boj medzi zložitosťou a zložitosťou

[Filip Jirsák]

Ten [Slava Pestov, autor jEditu] měl tu "čest" nahlédnout do zdrojáků JVM.

Čest nahlédnout do zdrojáků JVM má už nějaký ten pátek každý – Java SE Downloads – J2SE 5.0 JDK Source Code. This community source release contains all the source code and makefiles required for building JDK 5.0…

[Marek Bernát]

Máš zle zarovnaný pythonovský amean.

[Michal Kubeček]

Autoři programovacích jazyků, které jsou citlivé na formátování whitespace, by zasloužili pár facek…

[petr]

alespon se dodrzuje vsude stejna konvence a je to pak lip citelny

[David Watzke]

Souhlas... ale jak souvisí programovací jazyk s Pythonem?

[Marek Bernát]

Teda, tomu hovorím tvrdý postoj človeka ťažko skúšaného takýmito jazykmi

Inak, je pravda, že na formátovanie si treba dať pozor pri písaní článku, ale to je ostatne pravda pri všetkých jazykoch. Síce to v nich bude syntakticky správne bez ohľadu na formátovanie, ale nebude sa to dať prečítať a pochopiť, čiže taká ukážka kódu je de facto na nič.

[Marek Bernát]

Po kontrole zarovnania prichádza kontrola kódu.

 return __getattr__(self,name):

chcelo byť

 def __getattr__(self,name):

však?

Množstvo chýb ma začína znepokojovať. Ostatné jazyky máš bez chyby? :-P

[Michal Kubeček]

Ani ne, naštěstí žádný takový jazyk ve větší míře nepoužívám. Bohatě mi stačí problémy s copy and paste z/do Makefile…

[Marek Bernát]

No tak to hej, Makefile to je kapitola sama o sebe. Hlavne, keď s ním človek začína a po hodine lámania si hlavy nad jeho nefunkčnosťou príde na to, že má na jednom riadku tab

Ale v pythone sa mi to nikdy nestalo. Neviem z akého dôvodu, ale je to tak.

[Marek Bernát]

A tiež ten univerzálny handler je zle zarovnaný. Ráno som to nedočítal, preto to píšem až teraz. Nabudúce si ten článok raz prezri, kým ho uverejníš

[razor]

U dynamických jazyků je nutné psát testy, které projdou všechny větve a kód spustí, protože vlastní překlad prakticky žádnou kontrolu neprovádí.

Řekl bych, že to ve stejné míře platí i pro staticky typované jazyky.

[Tom.š Ze.le.in]

Zcela drobnost: v původních lispech byl afaik opravdu COND special form a if macro, ale třeba v Common Lispu to už je obrázeně: http://www.lisp.org/HyperSpec/Body/mac_cond.html, http://www.lisp.org/HyperSpec/Body/speope_if.html#if

Možná méně drobnost:

Výhoda dynamického provádění kódu je zřejmá. Je možné za běhu sestavovat kód přesně na míru požadavkům, což kompilované jazyky (snad s výjimkou assembleru) neumožňují. Respektive umožňují, ale za cenu přibalení překladače a linkeru k programu a také za cenu starostí s IPC nebo sdílenou pamětí. Nevýhoda je ta, že se dynamické jazyky nedají kompilovat. Respektive dají... až na všechny výskyty podobných konstrukcí, které musí překládat interpret. Ale protože je u těchto jazyků fáze kompilace a spuštění stejná, není to tak markantní.

Tady aspoň u mne při prvním čtení došlo k matení rozdělení statické/dynamické typování a kompilovaný/interpretovaný (včetně bytekódu) jazyk. Každopádně moderní Lisp má odlišnou fázi kompilace a spuštění, obyčejně má v programu přibalený kompilátor (ať už do čehokoliv), a takovéto konstrukce kompiluje vždy (sbcl) nebo za určitých okolností (dynamicky tvořený kód je obalen do makra a efektivně jej známe v době kompilace nebo je voláno compile). Takže tady je lisp najednou spíše na druhé straně než ve zbytku článku.

Mimochodem, používání přímého eval doporučuje z dobrých důvodů většina novějších praktických knih o Lispu asi stejně jako Wirth goto :)

[deda.jabko]

ten vztah if a cond me taky zarazil... ono je lepsi mit if jako spec. formu spis nez cond... mnohem lip se to preklada do mezikodu. ikdyz to makro pro prepis cond->if neni tak trivialni jak v opacnem gardu.

[Marek Bernát]

Skutočne je to až také ťažké? Nestačilo by zabaliť if pre každú vetvu do progn a na koniec každej vetvy dať goto koniec? Je to samozrejme krapátko ťažšie ako ten if, ale načo implementovať zložité veci ako cond priamo v jazyku; to je úplne nelispovské. Rovnako nezmyselné by bolo when ako špeciálna forma a pomocou neho vytvárať if.

[Tom.š Ze.le.in]

načo implementovať zložité veci ako cond priamo v jazyku

Odpověď možná zní, že v době, kdy McCarthy cond navrhoval, nečekal, že by se někdo pokusil tu teoretickou úvahu z axiomatizace algoritmů implementovat, a pak se to chvíli vezlo.

[deda.jabko]

prave, ze kdyz se implementuje if jako zaklad a cond jako doplnek... lze se v mezikodu obejit urcite bez instrukce goto... ono ani pro ten cond by to vlastne nemuselo byt treba

[Marek Bernát]

Veď ja som hovoril o prípade s if ako špeciálnou formou a cond ako makrom. A tie vetvy cond sa dajú samozrejme zreťaziť bez goto – (if a1 b1 (if a2 b2 (if...(if an bn)...))) – a ako sa tak teraz na to pozerám, tak mi to pripadá elegantnejšie, ale nejakú podstatnú výhodu oproti verzii s goto tam nevidím.

[deda.jabko]

podstatna vyhoda verze bez goto je zaprve v tom, ze jazyk VM je o jednu instrukci mensi ;-] a za druhe jdou s tim delat optimalizace (pul roku uz nedalam nic jineho ;]) a vic to odpovida teoretickemu pohledu na vec... taky goto nevypada moc funkcionalne

[Marek Bernát]

Akože je jazyk menší? Veď bez goto sa nezaobídeme inde. Ako chceš napísať napríklad do bez goto, alebo bez nejakej inej jump inštrukcie?

Ale inak uznávam, že sa mi to naozaj páči bez toho goto viac z čisto estetického pohľadu

[deda.jabko]

:-]] naprosto jednoduse, stejne jako v kazdem funkcionalnim jazyku... pomoci rekurze a tail-callu.

(define-macro (do times . exprs)
        `(letrec ((iter (lambda (times)
                        ,@exprs
                        (if (> times 1) (iter (- times 1))))))
                (iter ,times)))
(do 5 (display "x") (newline))

ono to nejde moc videt (ale ptal jste se jak se udela do), takze ve sve podstate je to neco takoveho

(define (cycle times)
        (define (iter times)
                (display "blah")
                (newline)
                (if (> times 1) (iter (- times 1))))
        (iter times))
(cycle 5)

diky tomu, ze volani "iter" je v koncovem postaveni, tak jde pouzit tail-call a hodnoty na zasobniku prepsat, tudiz se to chova jako takovy jump bez goto. vic info na http://www.sidhe.org/~dan/blog/archives/000211.html

a pokud pisete zasobnikovi vm, tak tam to goto opravdu zavazi.

[Marek Bernát]

Pekné a jednoduché, páči sa mi to

Asi ma to nenapadlo preto, lebo zatiaľ som sa venoval hlavne common lispu a tam to nie je zďaleka také čisté. Zrejme je čas pozrieť sa na Scheme

[Tom.š Ze.le.in]

V Common Lispu? Najděte pět rozdílů :)

(defmacro do2 (times &body body)
        `(labels ((iter (times)
           ,@body
           (if (> times 1) (iter (- times 1)))))
       (iter ,times)))
DO2

(do2 5 (print x))

Pozn: do je obsazené, proto do2; a možná bych v reálu místo názvu iters použil nějaký gensym, abych nemusel přemýšlet, zda nehrozí klasický problém maker. To u scheme není nutné.

[Marek Bernát]

Samozrejme, že je to to isté, to som nemal na mysli

Išlo mi o to, že keď človek bežne expandne v common lispe nejaké makro, tak je to samé goto a tak som si na to celkom zvykol. Napríklad spomínané do.

[Tom.š Ze.le.in]

Hmm, to je vlastně pravda. Zajímavý postřeh :) Je fakt, že optimalizace tail callu ve Scheme povinná je a v CL ne, to může být důvod (aspoň u standardních maker v clispu)

[Marek Bernát]

Presne tak.

[deda.jabko]

pozor na to... i ve schemu hrozi v tomto pripade name clash... teda v pripade tohoto makra, ale davat tam dalsi let a gensym me prislo, ze by to smrdelo moc cernou magii a ztratila by se ta pointa. a hygiencke makra, kde to nehrozi, moc nepouzivam...

[Marek Bernát]

Od čiernej mágie to má ďaleko, ale je fakt, že by ten príklad stratil na kráse

[Michal Hocko]

[Šablony tedy nejsou nic jiného než způsob, jak do statických jazyků přinést prvky těch dynamických. Sémantická kontrola v tom případě nekontroluje typy, ale to, zda existují příslušné operátory (metody). Hezkým důsledkem zavedení šablon je, že se typová kontrola neoslabila. Naopak, použitím šablon se v Javě (i v C++) typový systém naopak posiluje, protože před tím se používal typ Object (v C++ by se používal void*).]

Myslim, ze uvedeny text nie je velmi presny a skor zamlzuje.

Jednak Java nema sablony, ale generiksy. Druhak sablony su v C++ konstruktivnou zalezitostou a teda kompiler vytvara instancie sablon v momente, ked sa pouziju (to napr. znamena, ze ak sa sablona neinstanciuje - teda nepouzije, nerobi sa ziadna semanticka kontrola). Za runtimu sa uz nepozna, ze dana trieda, funkcia... bola vytvorena zo sablony. Takze dynamicnost asi nie je najlepsie pomenovanie, kedze konci s prekladom.

V Jave generiksy funguju len ako silna typova kontrola, ktora navyse v case runtimu neexistuje vobec (prekadac informacie o generickych typoch zahodi). Takze bavit sa o dynamicnosti asi tiez nie je velmi stastne.

[Kyosuke]

Huh, přirozené jazyky nám kulhají? Generikum, bez generika, generiku, generikum…no, až se nakonec dostaneme k inkriminovanému nominativu plurálu. Ale možná, že jen neumím slovensky. (Totiž, disclaimer: Prznění jazyka v malé míře by mi bylo ukradené, ale tady k dokonalosti opravdu chybí už jen s/ksy/xy/ )

[Ladicek]

Nominativ plurálu je v tomhle případě generika. A to jsou, sakra, léky, ne? Já generické typy zkracuju na generiky a trpím, kdykoli ze sebe nějaký programátor začne dělat farmakologa

[Kyosuke]

Nejen léky, někteří považují generika za všelék, i když všichni víme, že všelék jsou makra.

[Ladicek]

Jasně, generiky jsou makra chudých

[Jan Švec]

Ahoj, nejprve ti musím poděkovat za citaci mého překladu rozhovoru s Guido van Rossumem.

Dále bych tě chtěl upozornit na několik věcných chyb týkajících se pouze příkladů v Pythonu uvedených ve tvém článku:
1. Příklad s longPrint(): voláš metodu x.longPrint(), mělo by být print x.toLongString()
2. Obdobně s dalším voláním x.__repr__(), metoda __repr__ pouze vrátí řetězcovou reprezentaci objektu, pro její vytisknutí musíš použít příkaz print.
3. Použití příkladu foo.__dict__ v části o reflexi je poněkud nešťastné, nejen, že některé atributy nemusí být v dict (zrovna ty dynamické, které vracíte pomocí getter, setter metod), ale i samotné foo.__dict__ nezasvěcenému moc neřekne. Spíše bych reflexi v Pythonu ilustroval pomocí funkcí hasattr(), getattr(), dir(), modulu inspect atd.
4. Příklad amean má špatné odsazení (podobně jako příklad s třídou C). Dále komentář říká, že průměr lze vypočítat ze všeho, co lze procházet iterátory. Zároveň však prvky tohoto iterovatelného objektu musí podporovat operátor + (tj. nesečtete si třeba pole asociativních polí ).
5. Poslední příklad interaktivního sezení určitě není kopírovaný z Pythonu, protože v Pythonu se výzva interpretru značí >>> a nikoli <<<.

Článek je jinak vcelku povedený, jen tak dále. Pouze Python se trochu přiučte a občas si zkuste spustit i interpretr.

[Tom.š Ze.le.in]

To, co se mi osobně na dynamických jazycích líbí nejvíce, je úspornost zápisu. Jádro celého kódu je díky funkcionálnímu reduce kratší než definice cyklu for v C++, přičemž je ten kód ve výsledku daleko obecnější. Oproti C++ verzi s iterátory ten kód není tak zatemněný (ovšem jenom pro lidi, kteří znají lambda funkce). A to je Python poměrně ukecaný jazyk, stejný příklad třeba v Ruby by mohl být ještě o něco kratší.

Další příjemná věc na použití abstrakcí jako reduce je to, že umožňují snadnější přechod k škálovatelnějším implementacím algoritmu. Mimochodem, Googlí MapReduce je pokud vím v C++.

[mydlo]

Clanok sa mi paci, len v texte a v prvom priklade s pythonom su zamenene funkcie longPrint() a x.toLongString.

Okrem toho v Pythone sa vyhybame zbytocnym zatvorkam a bodkociarkam v style C++ ako napr. catch (AttributeError e): alebo print "default"; , lebo to spomaluje program. Namiesto toho staci catch AttributeError: a print "default".

[Jan Martinek]

Článek je úplně skvělý (stejně jako všechny jeho předchozí díly). Jen mám dotaz k tomu prvnímu příkladu - nepatří tam spíš

except AttributeError:

namísto "catch" (které IMHO v Pythonu není)? A co se týče výpočtu toho aritmetického průměru, ortodoxní Pythonista by to možná napsal takhle:

def amean(lst):
    try:
        return sum(lst)/len(lst)
    except ZeroDivisionError:
        return 0

(Možná tu výjimku ani není třeba odchytávat - však jen ať si probublá).
Oba příklady (jak můj, tak ten v článku) se zachovají trochu nezvykle, když bude seznam obsahovat pouze celá čísla. Ale to je detail.