Eclipse a Java: Automatická tvorba zdrojových kódů

Pavel Tišnovský pokračuje na Fedora.cz v seriálu o vývojovém prostředí Eclipse a programování v jazyce Java. Čtvrtý díl se zabývá tématem automatické tvorby zdrojových kódů.

2.4.2012 18:10 | Robert Krátký | Zajímavý článek

Komentáře

[BostX]

Keby bola java tym cim nie je tak by mala okrem mnohych inych veci, vlastny makrosystem. http://clojure.org/ (Welcome to the real world Neo)

[Filip Jirsák]

Naštěstí Java je tím, čím je, takže se v ní makra v drtivé většině případů nepoužívají. Díky tomu se může v plné síle používat refaktoring nebo asistence při psaní kódu. Java pak má jiné prostředky, které se používají v případech, kde je v jiných jazycích nutné použít makra.

[BostX]

Oh boze. Bavime sa o makrach vyssich radov - makrach ktore vytvaraju makra. A o makrach transformujucich kod z jedneho Domain Specific Language do ineho DSL. Alebo o makrach rozsirujucich dany jazyk o nove syntakticke konstrukty. Predpokladam ze paradigmou 'Code as Data' ste sa zatial zaoberali minimalne. Bavit sa o refaktoringu v jave pod eclipsom je ako diskutovat o matematickych funkciach zabudovanych v MS Worde

[Filip Jirsák]

Tak proč něco komentujete, když o tom nevíte ani ň?

[cronin]

Tak ja som teda už s jedným makro-rozšírením pre Javu mal tú česť, a veru si nechcem tú skúsenosť zopakovať. Týždne som upravoval kód tak, aby som makrá obmedzil na minimálnu možnú mieru, izoloval ich od zbytku kódu a čo najrýchlejšie ich funkcionalitu "preložil" do čistej Javy. Fungujúc na syntaktickej úrovni, úspešne zabraňovali rozumnej údržbe kódu, refaktoringu i prostému vyhľadávaniu tried, metód a premenných.

[atarist]

jj to tak byva, kdyz prijde nekdo s minimalnimi zkusenostmi a pritom s prave ziskanymi znalostmi Lispu nebo Haskellu. Potom se snazi to paradigma nacpat na Javu a na problem je zadelano - typicky to ale musi opravit nekdo jiny nez puvodni autor :-|

[jehovista]

Kod, ktery se da automaticky vygenerovat, je zbytecny.

[jekub]

richtig. ja si dycinky myslel, ze ten bison(yacc) a (f)lex je uplne ku hounu.

j.

[jehovista]

Myslel jsem to takto: http://projectlombok.org/

[Ladicek]

Je jenom málo generátorů parserů/lexerů, které jsou horší než bison/yacc a (f)lex.

[loki]

Tak a proto vsechny programy delejme v dogmatickem uml a na programovaci jazyky vlastne muzeme zapomenout.

[Ladicek]

Dej pozor, Executable UML se blíží!

[Martin Petr]

Co je to za blbost. Automaticky vygenerovaný kód != boilerplate. Když už chceš něco říct, tak nejprv uvažuj a až potom piš (nebo radši ne).

[pavlix]

Tak, ač o tom možná sám neví, svým způsobem má pravdu. Automaticky generovaný „zdrojový“ kód je mezivýsledek a v podstatě zbytečný je. Stačí, když se různé kódy dají kombinovat do smysluplného výsledku.

Nepopírám, že může být občas praktičtější mít i ten mezivýsledek.

[jehovista]

Uvazuju a porad mi to nedochazi. Muzes to trochu rozvest?

[atarist]

Jednoduse, ten automaticky generovany kod je vytvoreny na prani programatora - neni tam uplne "automaticky" vlozen ne? Dam priklad souvisejici s tim clankem:

Udelam tridu a nasekam do ni 10 atributu - fajne. Potom si necham vygenerovat gettery a popripade i settery - fajne - ale navic rucne (a jak jinak?) do setteru nastavim ruzne asserty, automaticke prevody typu atd. atd. Takze Eclipse mi pomuze v zakladnim vygenerovani kodu (stejne by se to muselo nekde pomoci anotace urcit, kde dat getter a kde ne) ale potom do toho muzu hrabat a upravovat.

[jehovista]

No dobre, ale muze to byt udelane tak, ze na zakladni chovani staci treba anotace a jen kdyz clovek potrebuje neco specialniho, tak ten getter napise. Moc prostoru tam pro generovani kodu neni. Ja jsem ten prispevek ale nemiril na Javu(ktera je zbytecne ukecana), ale vseobecne. Lepsi nez mit nastroje na generovani stovek radek kodu mi prijde mit nastroje(a jazyk), ktere mi umozni psat jen uzitecne veci. Uzitecnost automatickeho generovani kodu je dana jen neefektivnim zapisem jazyka.

[Filip Jirsák]

Mít dva různé zápisy pro gettery a přepisovat je pokaždé, když ze základního potřebuju něco speciálního nebo opačně, považuju za mnohem větší zlo. Jaká by vůbec byla výhoda toho řešení? Stručnější zápis, který si programátor v hlavě stejně musí převést na ten vygenerovaný kód, to je pro mne nevýhoda, ne výhoda.

[stativ]

Otázka je, nakolik jsou vůbec takové gettery a settery u datové třídy potřeba a proč nepoužít rovnou veřejné proměnné. Tady vidím obrovskou výhodu C# (teď se tu na mě všichni vrhnete jako kobylky…), protože tam se ke getteru/setteru přistupuje stejným způsobem, jako by to byla proměnná. Není tedy problém na začátku udělat datovou třídu, kde jsou datové proměnné veřejné a pak později v případě potřeby udělat pro některou proměnnou explicitně getter/setter aniž by se nějak změnilo API.

[Filip Jirsák]

S gettery a settery to vypadá víc jako objekt. Kdyby tam nebyly, těžko už by se zamaskovalo, že jde o obyčejnou strukturu a že pak často jde o procedurální a ne objektové paradigma. I když mnohdy by to věci prospělo, protože by pak bylo snazší si uvědomit, že neduhy procedurálního paradigmatu se daného projektu mohou týkat.

[Radek Miček]

Není tedy problém na začátku udělat datovou třídu, kde jsou datové proměnné veřejné a pak později v případě potřeby udělat pro některou proměnnou explicitně getter/setter aniž by se nějak změnilo API.

Na úrovni zdrojáku ano, na úrovni IL kódu ne.

C# má automaticky implementované vlastnosti, takže stačí napsat

public Typ Vlastnost { get; set; }

a kompilátor automaticky vytvoří privátní proměnnou a implementuje getter i setter.

[jehovista]

Tohohle se da v Jave taky docilit(vyse jsem daval odkaz)

[Ladicek]

Není tedy problém

Je to problém z hlediska binární kompatibility.

[stativ]

Pak lze použít automaticky generované gettery a settery jak psal výše Radek. Spousta datových tříd je často jen interní záležitosti projektu, takže pak ani binární nekompatibilita při použití veřejných proměnných není problém (prostě se to překompiluje).

[Ladicek]

Jasně.

[cronin]

Dúfam, že dobu primitívnych Java fazuliek, kde trieda bola len množina premenných pristupovaných triviálnymi gettermi a settermi je už za nami. S výnimkou protected final premenných v podtriedach veľmi zriedkavo pristupujem k inštančným fieldom tried priamo, a napriek tomu mám vo svojom kóde relatívne málo triviálnych getterov a skoro žiadne triviálne settery. Settery buď nemám, lebo objekty, pokiaľ je to čo len trochu možné, sú immutable, alebo settery mám, ale v drvivej väčšine prípadov kontrolujú validitu vstupu. Public API tak v drvivom prípade pozostáva z metód "zasielania správ" medzi objektami. Tak, ako sa to učí na prvej prednáške OOP: objekty sú zapúzdrené dáta spolu s operáciami, ktoré sa nad týmito dátami vykonávajú. Toto je zároveň ten najúčinejší návrhový vzor triedy v objektovom programovaní. Všetky ostatné design patterns sú síce fajn, ale mali by prísť k slovu až vtedy, keď je základná paradigma z nejakého dôvodu nedostatočná.

Všetko, čo som napísal, je myslené pre programovací jazyk Java. Filozofov hľadajúcich ideálny všeobjímajúci jazyk, alebo géniov, ktorí ho náhodou už našli, prosím, aby sa nič z vyššie uvedeného nesnažili extrapolovať mimo platformy Java.

[Filip Jirsák]

Dúfam, že dobu primitívnych Java fazuliek, kde trieda bola len množina premenných pristupovaných triviálnymi gettermi a settermi je už za nami.

Obávám se, že doufáte marně. Vždyť JPA, různé JAX-* a různé další moderní technologie jsou postavené právě na těch strukturách nazývaných JavaBeany. A vůbec celá tří- a vícevrstvá architektura nebo SOA vedou v nejjednodušším případě právě k takovýmto řešením.

[dooku]

Pavel Tišnovský má skvělé články a opravdu velký rozhled v počítačových technologiích (viz jeho profil na rootu). Netušil jsem, že dělá i do Javy.

Ale jsem opravdu jediný, kdo Javu ze srdce nesnáší? Je to obrovský moloch, kód v ní napsaný je nevzhledný, nepřehledný a zbytečně obsáhlý. Počítač je dokonalý nástroj, má obrovský výpočetní výkon. A Java a software v ní napsaný využívá jeho prostředky s takovou účinností, jaké dosahoval snad jen parní stroj. Kód je možná rychleji napsaný (což jistě občas potřeba je), ale v dlouhodobém hledisku se vyplatí udělat to "pořádně". A ta její blbuvzdornost je taky k vzteku. Abych použil další nevhodné přirovnání: sekera se taky neprodává tupá, aby si její uživatel neusekl prsty...

[Smazáno]

... využívá jeho prostředky s takovou účinností, jaké dosahoval snad jen parní stroj.

Vážně? Tak to je java mnohem lepší, než jsem si o ní myslel...

[Ladicek]

Je to obrovský moloch, kód v ní napsaný je nevzhledný, nepřehledný a zbytečně obsáhlý. Počítač je dokonalý nástroj, má obrovský výpočetní výkon. A Java a software v ní napsaný využívá jeho prostředky s takovou účinností, jaké dosahoval snad jen parní stroj.

BS.

[dooku]

BS? Předpokládám že to znamená "be specific" (musel jsem zagooglit, tohle mi připadá nejpravděpodobnější. "Bisexual" ani "britney spears" jste asi nemyslel).

Tak abych byl přesnější - interpretovaný jazyk už z principu bude vždycky pomalejší než strojový kód. Jde jen o to, o kolik bude pomalejší. Možná nebudete souhlasit s tím, že Java je interpretovaná. V jejím případě to asi není úplně přesný termín, ale v podstatě to tak je. Možná se nejdřív překládá do bytecode, ale nakonec to dopadne stejně.

[Ladicek]

Ne, myslel jsem bullshit. Java interpretovaná opravdu není, dokonce ani ten bajtkód, do kterého se kompiluje, není interpretovaný (tedy ve většině případů; některá JVMka kompilují vždycky všechno, některá jenom často používaný kód). Ano, vysokoúrovňový jazyk bude vždycky pomalejší než nízkoúrovňový jazyk, ale zdaleka to není tak hrozné.

[dooku]

Možná jsem jen někde něco špatně pochopil. Pokud ano, tak budu rád pokud mě opravíte. Ale bytecode nelze "spustit" (vykonávat) přímo na procesoru (jako strojový kód). A vzhledem k tomu, že procesor umí zpracovávat pouze strojový kód, musí někde dojít k překladu; možná ani tento termín není přesný. Ale ať tak nebo tak, JVM musí v konečném důsledku vykonat program napsaný v bytecodu na procesoru; musí tedy použít strojový kód -> musí tedy v podstatě dojít k vykonání bytecodu ve formě strojového kódu.

Tady nejde o to, jestli jsou vyšší jazyky pomalejší nebo ne, jasné že když napíšu něco v assembleru (a dám si s tím dost práce), bude to rychlejší než co vyplodí gcc ze zdrojáku v C. Tady jde o to, že stejný program v C a Jave bude vždycky o něco pomalejší právě díky tomuto rysu Javy (té interpretaci, co vlastně není interpretace. Nenašel jsem žádný vhodnější výraz)

[Ladicek]

Jasně že musí dojít k vykonání nějakého strojového kódu. To se v případě virtuálních mašin děje v zásadě dvěma způsoby: interpretací (virtuální stroj vlastně simuluje procesor, prochází instrukce bajtkódu a pro každou instrukci zavolá připravenou rutinu) nebo kompilací (bajtkód se přeloží přímo do nativního kódu procesoru, na kterém virtuální mašina běží).

V případě Javy je to v naprosté většině případů ten druhý způsob (např. v případě JRockitu) nebo kombinace obou (např. v případě HotSpotu, kde se do nativního kódu kompilují jen často vykonávané metody). Ten překlad typicky probíhá za běhu (JIT), ale může proběhnout i předem (AOT). To pochopitelně má určitou režii (zejména počáteční, proto programy v Javě tak pomalu startují), ale mnohem větší režii má zajištění těch vlastností "vyšší úrovně" (dynamické nahrávání kódu, které se teda taky významně podílí na počáteční režii, různé běhové kontroly, automatická správa paměti atd.).

[dooku]

Děkuji za vysvětlení. Je to, pravda, trochu jinak než jsem myslel (domníval jsem se že vždy jde o onen první, pomalejší, způsob). No, prostě zůstanu u C a Javu vám všem ostatním rád přenechám :D jen kdyby nás do ní na škole nenutili, pak bych byl úplně spokojený.

[Filip Jirsák]

Ani ten první způsob ovšem nemusí být v praxi pomalejší. Vy totiž uvažujete jen ideální případ, kdy přeložený program nejlépe využívá všechny instrukce procesoru, má správně optimalizované skoky atd. To ale v reálném světě není vždy pravda. Navíc málokterý program opravdu jen drtí algoritmus na procesoru. Drtivá většina programů, se kterými se uživatelé běžně setkávají (přímo nebo nepřímo, jako třeba webový server) rozhodně nevázne na tom, zda se nějaký algoritmus provede na 10 nebo 15 instrukcí procesoru.

[okbob]

Co tak vidím kolem sebe, tak u Java aplikací většinou není problém s výkonem - jako spíš sem tam s pamětí (ale to samé se děje u datově náročnějších aplikací v Perlu, Pythonu). Při programování v C musíte na paměť neustále myslet - což by mělo vést k tomu, že aplikace budou ohledně přístupu k paměti hodně zdrženlivé - a i z principu ochrany vůči memory leakům se snažíte uvolnit paměť co nejdříve. S pomalým startem Javy asi souvisí snaha vytvářet poměrně dost těžká a monolitická prostředí - která komplikují provoz, vývoj, ladění.

[atarist]

Popravde receno, ten preklad z bajtkodu do strojaku je to nejmensi, optimalizace pravda neco vezmou, ale jsou jine veci, ktere musi JVM delat: kontrola toho bajtkodu, coz neni moc jednoduche (treba konstrukce grafu dostupnosti ma blbou slozitost) atd. Kdyz se kontroly vypnou, tak pro dlouhobezici aplikaci je JIT nekdy (casto lepsi nez GCC nebo LLVM, protoze ma k dispozici runtime informace.

[Ladicek]

kontrola toho bajtkodu, coz neni moc jednoduche (treba konstrukce grafu dostupnosti ma blbou slozitost)

Od toho přece překladače (od verze 6) generují StackMapy. A budoucí JVMka (snad od verze 8?) budou kód bez nich už odmítat, mám pocit.

[atarist]

Jo ale kdyz tam nejsou a pouzivaji se instrukce JSR napriklad, tak to hodne zdrzuje. Jsme na to resili i security bug, kdy se povrzenym JARem dal zaDOSovat klient nebo i server I presto je to stale hodne dobra ficura JVM.

[Ladicek]

Ale tak jo, DOS útok na verifikátor byl popsaný už někdy před deseti lety

[atarist]

No a nedavno byl fixlej dalsi potencialni podobny typ utoku Problem je, co delat se starsimi bajtkody treba generovanymi z 1.4.2 nebo 1.5, proste se ten checker neustale musi vylepsovat, coz je jen dobre.

[Ladicek]

Odmítnout načíst Jak jsem říkal, mám pocit, že se o tom mluvilo. Nejsem si jistý do které verze, pokud vůbec, ale mluvilo se o tom.

[BostX]

Podla tejto logiky je aj strojovy kod "len" interpretovany

[dooku]

Nechápu. Prosím popište, jak jste k tomu došel. Strojový kód je přímo vykonáván v procesoru, zatímco bytecodu musí projít JVM a pak být vykonán v procesoru (ve formě strojového kódu).

[Ladicek]

Protože strojový kód je přece "interpretován" mikrokódem

[dooku]

Jo takhle. Až tak do hloubky mé myšlenky nešly.

[Erbureth]

Jistě. A mikrokód je interpretován logickými hradly :P

[Solitary]

We need to go deeper!

[cronin]

...interpretovaný jazyk už z principu bude vždycky pomalejší než strojový kód.

Staticky kompilovaný jazyk nikdy neurobí escape analysis, on stack replacement ani runtime dead code elimination, na rozdiel od virtuálneho stroja.

[dooku]

Ano. Ale to jsou všechno vychytávky které potřebují zejména vyšší programovací jazyky, které jsou "abstraktnější" a vzdálenější tomu, jak počítač pracuje. Ne že by to co vyleze z gcc bylo vždy dokonalé, ale je to z velké části na programátorovi. V Javě už nemáte takovou kontrolu nad tím, co se děje. A ještě jedna věc - všechny tyto algoritmy samy nějaké procento výkonu berou. A není úplně jasné, jestli jsou v každém případě prospěšné.

[Filip Jirsák]

V Javě máte docela dobrou kontrolu nad tím, co se děje v JVM – Java je dost nízkoúrovňový jazyk nad JVM. Samozřejmě JVM má pod sebou další úrovně, ale ty má dnes pod sebou i strojový kód. Vzhledem třeba k vícejádrovým počítačům je myslím „vzdálenost“ programu v C a v Javě od prováděných instrukcí víceméně stejná. C samozřejmě snáze umožňuje jít blíž k procesoru, ale u běžného programu bude mít programátor stejně zanedbatelný vliv na prováděné instrukce, ať bude psát v Javě nebo v C.

[Sešívaný]

Netušil jsem, že dělá i do Javy.

Ano, dělá. Je totiž jeho hlavní pracovní náplní. V Red Hatu dělá na OpenJDK.

[dooku]

Aha, to je pro mě o to překvapivější. Snad to s Javou nebude až tak zlé, když do ní dělá člověk tohoto formátu :) (ale osobně ji stejně nemám rád :D)

[Michal Vyskočil]

Pavel Tišnovský má skvělé články a opravdu velký rozhled v počítačových technologiích (viz jeho profil na rootu). Netušil jsem, že dělá i do Javy.

http://cz.linkedin.com/in/paveltisnovsky

Quality Assurance Engineer, OpenJDK team.

[atarist]

"Je to obrovský moloch, kód v ní napsaný je nevzhledný, nepřehledný a zbytečně obsáhlý."

To je nejake tvrzeni podeprene dukazy, nebo jen tak pocity nekoho, kdo v Jave napsal parsetradkovy program do skoly?

Java jako jazyk zadny moloch imho neni, i kdyz samozrejme zalezi na tom, s cim se porovnava ze (C++ - tam je to jasny, Python - ten zase par veci neumi a jako dynamicky jazyk ma o dost jinou oblast pouziti ...)

[pavlix]

Python - ten zase par veci neumi a jako dynamicky jazyk ma o dost jinou oblast pouziti ...)

A já myslel, že jsou programovací jazyky ekvivalentní.

[Ladicek]

Všechny programovací jazyky mají stejnou výpočetní sílu, ano. (Prosil bych lidi, co se zabývají automatickým dokazováním teorémů, aby přestali svoje nástroje vydávat za programovací jazyky, protože v nich nikdo neprogramuje!) Co je rozdílné jsou vyjadřovací prostředky a tímpádem vhodnost pro konkrétní účel.

[pavlix]

Dobře. Prostě věta typu „Python zase neumí pár věcí.“ je dle mého názoru mlácení prázdné slámy. Pokud mi v Pythonu něco chybí a nejsem totální srab, tak napíšu co. V nejhorším s v příštím komentáři přečtu že to tam je a jak se to realizuje.

[atarist]

Tak se teda - kdyz je ten svatek - omlouvam, ze jsem ti sahl na oblibeny jazyk Ale kdyz uz jsme v tehle diskusi zacali tak napriklad se tezko tvori _spravne_ singleton, privatni metody jsou AFAIK (mozna se to zmenilo?) reseny pres "magicke prejmenovani". Jiste, jde to naprogramovat, Python je v tomto ohledu hodne dynamicky jazyk, ale neni zase tak odlisne od tvorby getteru a setteru, ktere nekdo nazval boilerplate code.

[stativ]

singleton je obvykle znak špatného designu.

[pavlix]

Až na to že neobvyklost případu se špatně posuzuje :). Kolikrát může singleton docela pomoci, zvlášť pokud se jedná o objekt starající se o něco, co je mimo samotnou aplikaci a existuje to jen v jednom exempláři.

[Radek Miček]

Kolikrát může singleton docela pomoci, zvlášť pokud se jedná o objekt starající se o něco, co je mimo samotnou aplikaci a existuje to jen v jednom exempláři.

Takový kód pak člověk nemůže normálně otestovat.

[pavlix]

Takový kód pak člověk nemůže normálně otestovat.

Okolnosti bývají různé.

[Radek Miček]

Mnohem lepší řešení je předat potřebné závislosti jako parametr.

Například kód, který pracuje s aktuálním datem a nenechá si toto datum injectovat zvenčí, používá singleton "stav světa" a je těžko testovatelný. Jiný příklad je třída, která k logování používá singleton a nenechá si logger injectovat zvenčí – co když chci v jedné instanci logovat a v druhé ne?

V prvním případě je IMO rozumné řešení použít singleton "stav světa" jako default, ale dovolit předat i jiné datum.

[pavlix]

Tak já jsem taky neříkal, že by singletonem mělo být datum.

[stativ]

Napadají mě jen dva případy, kdy použití singletonu může být užitečné – správce paměti a logování. Jinak přináší jen samé potenciální problémy, jako je problematické testovaní nebo chybějící řízení přístupu (tím myslím to, že každý může na singleton hrabat).

Spousta lidí si to neuvědomuje, ale jsou to jen zakuklené globální proměnné. Už jsem se setkal s takovými jedinci, kteří brojili proti globálním proměnným a vyzdvihovali singleton do nebes.

[pavlix]

Napadají mě jen dva případy, kdy použití singletonu může být užitečné – správce paměti a logování.

Napadají tě z fleku dva, to znamená, že je velká šance, že se v praxi najde takových případů docela dost.

Spousta lidí si to neuvědomuje, ale jsou to jen zakuklené globální proměnné.

V podstatě. Až na to, že je jejich použití kousek hladčí v tom, že inicializaci lze provést kdykoli a odpadne testování, jestli je globální proměnná inicializována nebo ne.

Už jsem se setkal s takovými jedinci, kteří brojili proti globálním proměnným a vyzdvihovali singleton do nebes.

Tak ono je docela dobré si na řešení okrajových případů vybrat pokud možno jeden z těch způsobů.

[Ladicek]

Já bych se vykašlal na slova jako obvykle a design, singleton je prostě antipattern. Kill singleton!

[stativ]

V 99% případů souhlasím, ale pro věci jako je správce paměti a logování je singleton docela užitečný (zvláště pokud člověk používá jazyk, který nemá globální proměnné)

[pavlix]

Tak se teda - kdyz je ten svatek - omlouvam, ze jsem ti sahl na oblibeny jazyk

Neomlouvej se, to je plytké a nezajímavé. Mně právě zajímají ty faktické rozdíly :).

Ale kdyz uz jsme v tehle diskusi zacali tak napriklad se tezko tvori _spravne_ singleton,

Nepřijde mi, že by se tvořil těžko, stačí vcelku triviální funkce new. Navíc jde vyřešit v nadřazené třídě, takže všechny odvozené od singletonu jsou singletony. Dělal jsem to. Tedy ne, že neumí :).

privatni metody jsou AFAIK (mozna se to zmenilo?) reseny pres "magicke prejmenovani".

Žádné magické přesměrování, prostě jmenná konvence se dvěma podtržítkama. Co je schováno za tím, nemusí programátora až tolik zajímat. Někomu může použití dvojtého podtržítka připadat zvláštní, ale není pravda, že se to neumí.

Python je v tomto ohledu hodne dynamicky jazyk, ale neni zase tak odlisne od tvorby getteru a setteru, ktere nekdo nazval boilerplate code.

Já nemám nic proti tomu, když se člověku některé vlastnosti Pythonu nelíbí. Taky bych nějaké své neoblíbené našel. Ale pokud někdo tvrdí, že Python něco neumí, stálo by za to říci co.

To platí o každém nástroji, bez ohledu na to, jestli je můj oblíbený nebo neoblíbený.

[atarist]

Ano singleton lze vytvorit tak, ze se predeklaruje funkce __new__ ale to vubec neni jednoducha zalezitost (pozor jednoduchost != maly pocet radku a uvadel jsem to schvalne prave pod diskusi o boilerplate code (coz predeklarovani __new__ taky je). Btw bych chtel tu vasi implementaci skutecne videt, jestli tam nenastanou problemy s vicenasobnym volanim init napriklad (dost casty problem, kdyz se to z netu "opise" bez premysleni

Ad privatni metody: zaprve nepsal jsem "presmerovani" ale "prejmenovani" a uz vubec jsem nemyslel ona dve podtrzitka, s temi se da samozrejme bez problemu vyzit - kazdy jazyk ma sve postupy a ja je samozrejme respektuju. Mel jsem na mysli to, ze se privatni metoda interne prejmenuje, da se pred ni jmeno tridy, takze puvodni jmeno jakoby neni viditelne. Nicmene vygenerovane jmeno lze snadno zjistit (dir apod.) a pouzit.

[pavlix]

Ano singleton lze vytvorit tak, ze se predeklaruje funkce __new__ ale to vubec neni jednoducha zalezitost

Mně osobně to připadá naprosto triviální.

Btw bych chtel tu vasi implementaci skutecne videt, jestli tam nenastanou problemy s vicenasobnym volanim init napriklad (dost casty problem, kdyz se to z netu "opise" bez premysleni

No, zaprvé v Pythonu k vytvoření singletonu vůbec není nutné předefinovávat __new__, viz například zde.

A i kdybys to chtěl řešit předefinováním __new__, tak je v dokumentaci přesně napsáno, jak __new__ funguje. Ten popis má pár řádků a je velice srozumitelný. Opakování __new__ se dá rovněž triviálně zabránit.

Pokud ti řešení __new__ a __init__ přijde složité, doporučuju první postup. Pokud ti i ten přijde složitý, nemůžeš se považovat za zkušeného Pythoního programátora, a budeš mít mnohem větší problémy s jinými věcmi.

[atarist]

Hehe fajn, potom prestanme nadavat na Javu/C++/Perl whatever a zacneme vsichni makat v Brain*ku Ten je taky Turingovsky kompletni...

[Martin Petr]

Je to obrovský moloch, kód v ní napsaný je nevzhledný, nepřehledný a zbytečně obsáhlý.

Kód je přesně takový, jaký napíšeš.

A ta její blbuvzdornost je taky k vzteku.

Já třeba taky Javu nerad, můj oblíbený jazyk je Common Lisp, ale pro psaní jistého typu aplikací asi zatím lepší jazyk neexistuje. Ano, není nic, co by skupina lisperů-superhrdinů nezvládla (přece jenom, debugovali kód a opravili kód - za běhu - běžící 160 miliónů kilometrů od Země na hardwaru za 100 miliónů dolarů ), ale to není to, co chceš v korporátním prostředí. A i kdybys to chtěl, tak toho nedosáhneš, protože je to utopie.

V takovém prostředí potřebuješ blbuvzdorný, staticky typovaný a neohebný jazyk (i za cenu toho, že bude efektivní jako parní stroj - mimochodem, děsná blbost), protože přesně takové jsou požadavky na korporátní software. 90% programátorů nejsou žádní géniové, 90% programovací práce je naprostá repetitivní nuda, která se ale prostě musí udělat, a musí za každou cenu běžet, protože je v ní investován obrovský kapitál.

Ano, Lisp je cool, Haskell je cool, spousta dalších jazyků je cool, ale

1. průměrný programátor na ně nemá
2. programátor, který na ně má, by v nich tyhle nudné věci ani programovat nechtěl

Ostrá sekera je ti tady kolikrát na nic, když nepotřebuješ nic než kladivo.

[Radek Miček]

průměrný programátor na ně nemá

IMO je to jen o zvyku.

[Martin Petr]

Ne, není to jen o zvyku. Zbožňuju Haskell, ale zároveň si uvědomuju, že je to jazyk pro horních pár procent (já mezi ně nepatřím, aby mě někdo neobvinil z elitismu).

Pozor: mluvím o zvládnutí jazyka na profesionální úrovni, se všemi jeho vychytávkami, jež jsou pro psaní efektivních a robustních velkých aplikací naprosto nezbytné. Že je každý programátor schopen Haskell ovládnout tak na úrovni Learn You A Haskell... není pochyb, a nehádám se o tom. Ale to je pouhá špička ledovce, naprosto nedostačující pro psaní velkých reálných aplikací.

Jedna věc je psaní menších (ne nutně jen hobby) programů. Druhá věc je psaní velkých aplikací, o kterých píšu v příspěvku výše. Kvanta kódu interagujícího se světem, proti kterým jsou základní ukázky monád v programech směšně triviální, monad transformers, kam se člověk podívá, a kdesi cosi... I XMonad, výstavní skříň haskellovského kódu je co se velikosti a komplexnosti aplikace v podstatě jenom hračkou.

[Radek Miček]

Pozor: mluvím o zvládnutí jazyka na profesionální úrovni, se všemi jeho vychytávkami, jež jsou pro psaní efektivních a robustních velkých aplikací naprosto nezbytné.

Co konkrétně máte na mysli? Co konkrétně by mělo být težké?

Pokud se bavíme o praktickém používání, tak si člověk vystačí se standardním Haskellem a pár jednoduchými rozšířeními, co má Hugs i GHC. Stejně tak člověk nemusí používat monad transformers (v GHC je nepoužívají) nebo arrows nebo skládání funkcí nebo doplňte si sám, když si myslí, že je to nepřehledné.

[lmb]

Nevím, nevím … Bez kompozice funkcí, která je základním stavebním kamenem funkcionálních jazyků Haskell nevyjímaje, byste nic kromě trivialit nenapsal. Stavovým monádám se v praktických aplikacích také málo kdy vyhnete a I/O už vůbec ne. Analogicky ke kompozicím se dostanete do situace, kdy budete potřebovat složit monády z rozdílných tříd a ty transformery byste si stejně musel napsat. Navíc není na nich nic nestandardního, jsou napsány v souladu s definicí jazyka Haskell 98 report, na rozdíl od zmíněných extensions. Většina známých haskell-aplikací je používá - darcs, happstack, xmonad, parsec, pugs (knihovny mtl nebo transformers).

IMHO zvládnutí Haskellu na profesionální úrovni vyžaduje na programátorovi daleko vyšší schopnosti abstrakce než je běžné u mainstreamových imperativních jazyků vč. Javy. Není to jen o schopnosti plynně rozumět a efektivně kombinovat standardní typové třídy, ale už samotná implementace výpočtu definičním popisem výsledku místo mechanického zápisu kroků algoritmu vyžaduje hodně nadprůměrné IQ.

[Radek Miček]

Bez kompozice funkcí, která je základním stavebním kamenem funkcionálních jazyků Haskell nevyjímaje, byste nic kromě trivialit nenapsal.

Mám na mysli operátor skládání funkcí, a ten v řadě funkcionálních jazyků není – například v OCamlu a F# není, neboť value restriction značně snižuje jeho užitečnost.

Stavovým monádám se v praktických aplikacích také málo kdy vyhnete a I/O už vůbec ne.

Standardní monády jsou jednoduché a užitečné. Nestandardní monády typu obrácená stavová nebo líná stavová už jsou IMO těžké, protože je nepoužívám.

Analogicky ke kompozicím se dostanete do situace, kdy budete potřebovat složit monády z rozdílných tříd a ty transformery byste si stejně musel napsat.

Ty monády si mohu napsat přímo a nemusím je skládat – jak už jsem psal výše v GHC to takto dělají nebo alespoň dělali. V F# je prakticky nutnost udělat si nové workflow, protože transformery tam jsou kvůli slabému typovému systému dost těžkopádné (a F# 3.0 to nezlepší).

samotná implementace výpočtu definičním popisem výsledku místo mechanického zápisu kroků algoritmu vyžaduje hodně nadprůměrné IQ

Proč? Naopak si myslím, že použít nějaký EDSL a popisovat problém jazykem, který mu je bližší, je jednodušší.

IMHO zvládnutí Haskellu na profesionální úrovni vyžaduje na programátorovi daleko vyšší schopnosti abstrakce než je běžné

Není hlavní překážkou jen nezvyk?