Prvotřídní Java (diskuse)

[Kyosuke]

Mě hlavně fascinuje, jak je možné, že tyhle věci v Javě už dávno nejsou, když prakticky od začátku se kolem ní motal Guy L. Steele Jr. Od autora úplné reference Common Lispu a spolutvůrce Scheme bych čekal, že nad Javou bude neustále skřípět zuby.

[Kníže Ignor]

Docela by mě zajímalo, kolik programů je v nějakém dialektu lispu a kolik v javě, proč tomu tak je a v jakých oborech se ty jazyky prosazují.

[Kyosuke]

Poslední velká studie, o které vím, je tahle:

http://www.upgrade-cepis.org/issues/2005/3/up6-3Amor.pdf

[Heron]

Mě spíš překvapuje, že něco podobně neobjektového, jako odkaz na funkci, chtějí dávat do jazyka, kterému součastně chtějí říkat objektový. Navíc, když už jazyk umožnuje nahradit předávání funce parametrem pomocí objektu a z anonymní třídy.

[Kyosuke]

A povedztě mi, Heron, čo vy si představujetě pod takým slovom „neobjektový“? Ve Smalltalku je to úplně normální objekt, v Lispu je to objekt, v C# je to objekt – neuraž se, ale viděl jsem už příliš mnoho lidí metat tvrzení jako „tohle je objektový“ a „tohle rozhodně není objektový“ na všechny strany, aniž by se nad tím zamysleli, než abych po téhle poznámce nezpozorněl.

[Michal Vyskočil]

No Java to má takto - třída != objekt, metoda != objekt, int != objekt, ... prostě v Javě je defakto objekt jenom to, co se vytvoří pomocí new (jedinou výjimkou jsou snad jenom řetězce). Potom se nemůžeš divit, že se představy, tebe jako Smalltalkera a Herona jako Javisty, o tom co je a není objektové, tak zásadně odlišují

[Heron]

Heron je především jednoduchý člověk a jako takový má rád pořádek a nesnáší, když se zavádí něco, co už lze elegantně řešit jinak. Javu mám rád pro její jednoduchou syntax ve které lze řešit vše to, na co je jinde spousta dalších "dodělávek". Enum, delegate apod. Teď v Java5 už jsou anonymní třídy, no dejme tomu, že na GUI se to hodí, ale proč tam je konstrukce enum opravdu nevím.

[Michal Vyskočil]

No, nezlob se, ale pořádek, jednoduchá syntaxe a Jave v jedné větě (pro mě) skutečně nejdou dohromady. Jednoduchou syntax mají jazyky jako Lisp, Smalltalk, nebo třeba Python. Java, protože vyšla z C, má syntaxi daleko složitější.

Anebo jinak, napiš parser Lispu/Smalltalku a potom parser Javy a porovnej je

Navíc, za pořádek považuji spíše přístup ... všechno je seznam (Lisp), všechno je objekt (Smalltalk). Kdežto v Javě si pořád musím uvědomovat, zda pracuji s číslem, zda s metodou, zda s třídou, anebo s objektem - ne, jednoduchý přístup to opravdu není.

Taky máme zcela jiné představy o eleganci (jak už jsem dávno zjistil ), protože to, co se v Javascriptu napíše na 4 řádky, v Javě vyžaduje rozhraní, anonymní třídy a podobně. Nemůžu si pomoci, ale pro mě je stručnost zápisu (do jisté míry) znakem elegance. Zrovna v případě closures takový Python elegantní není, protože vyžaduje pár řádků navíc, jen k obejití interpreteru.

[Heron]

Taky máme zcela jiné představy o eleganci (jak už jsem dávno zjistil ),

Pravda pravda. Je teda fakt, že syntaxně chudé jazyky jako např. Scheme poněkud na eleganci taky ztrácí . Mě nejde ani tak o stručnost zápisu (vždyť od toho je tu IDE), jako spíš o přehlednost (opět se neshodneme ). Nevím. Píšu trochu jinak, rád mám ve věcech jasno a podobně jako nyní v Javě jsem psal už i v C++ (přesná, dopředu promyšlená hierarchie objektů a jejich důsledné dodržování vs. spoluprogramátoři, kteří mi přenesli C kód, kde využili jeden objekt a říkali tomu program v C++ -- dle mého názoru bastl plný odkazů, pointrů, několika způsobů předávání parametů + nějaké konstrukce pro tvoření tříd apod.).

[tomm]

Kdybych byl verici, rekl bych amen Ta jednoduchost je dulezita - cim komplikovanejsi konstrukce mi jazyk umoznuje, tim vetsi sance na nasekani chyb je. A nikdo mi to nevymluvi. To mizive procento pripadu, kdy mi to mozna usetri cas kodovani, mi za to nestoji.

[Michal Vyskočil]

Čím komplikovanější konstrukce mě jazyk nutí dělat, abych obcházel jeho (umělá) omezení, tím je větší šance pro nasekání chyb (anebo něco nezvládnu vůbec)

[Miloslav Ponkrác]

Moje asi osmnáctileté zkušenosti mi naopak říkají, že v jednoduchých jazycích se naseká obvykle více algoritimických chyb a musí se to mnohem více hlídat, než v jazycích s komplikovanějšími konstrukcemi.

Je to proto, že při bohatosti konstrukcí jazyka je také jasně vidět, co chtěl autor říci, zatímco u jednoduchých konstrukcí se musí strašně obcházet a myšlenka algoritmu je pak zamlžená.

Schválně, komu budete víc rozumět? Člověku v češtině s bohatými jazykovými konstrukcemi, a nebo křovákovi v jazyce bonga-bonga (nebo jak se to jmenuje), který má pouhých třista slov? Obávám se, že jednoduchost tady nezvítězí.

Navíc u složitějších konstrukcí hraje do noty i to, že jim kromě programátora nevíc často rozumí i kompilátor a má mnohem větší šanci zjistit chybu, protože ví o záměru programátora mnohem více. Proto také u jazyků, které se používají pro kritické užití se objevuje značná ukecanost a bohatost konstrukcí, neboˇˇt je tam mnohonásobně větší šance, že kompilátor, ale i programátor uhlídá chybu.

Prosím pane tomme, abyste mi nějak prakticky dokázal, kde jednoduchost a chudost konstrukcí působí méně chyb. Dlouhou dobu jsem se zabýval programovacími jazyky pro kritické aplikace a tendence všech byla právě opačná - co nejvíce konstrukcí zaimplementovat do jazyka aby se snížila možnost chyb a kompilátor dostal šanci chyby poznat.

[tomm]

Velmi zajimavy pohled z druhe strany. S high-critical aplikacemi zkusenosti nemam, pohybuji se v oblasti vyvoje enterprise aplikaci. Predpokladam, ze jste se svoji praxi setkal s praci vice lidi na stejnem kodu. Mne osobne prijde kod, ktery nepouziva prilis slozite struktury, vyrazne citelnejsi a pochopitelnejsi. Je tom tim, ze pokud autor kodu pouziva konstrukce, nad kterymi je nutne se zamyslet, trha me to od pochopeni kodu jako celku a toho, co vykonava. Navic si v techto konstrukcich nemusim vsimnout nejake drobnosti, ktera zpusobuje, ze kod pochopim spatne. Kdyz zustaneme u javy, tak to neni chudy jazyk, ale nazval bych to primy jazyk (nechci rikat jednoduchy) - i kdyz me nuti vice psat, ale od toho mam IDE, aby mi to usnadnilo. Ja si te cistoty javy opravdu cenim. Drzim se hesla "hlavne jednoduse" a to vsude, od jazyka, po navrh architektury. Ve chvili, kdy se podivam zbezne na kod a rychle do nej neproniknu, tak to "smrdi" Jestlipak vite, kolik chyb naleznete v kodu, ktery je psan C-like jazyku, chyby uplne banalni, ale protoze jazyk to umoznuje a prekladac Vam to neodhali, a to pouziti prirazeni misto porovnani - takovy to jedno krasne zapomenute rovnitko ... kolega ho objevil v kodu, ktery byl prohlasen za plne otestovany a funkcni a nasazeny v produkcnim prostredi. Pak se ptate "proc to tam sakra je?".

Prave me napadl jeste jeden priklad, kdy je jednoduchost lepsi. Vzpomnel jsem si na assembler na proceroech Alpha. Meli jenom par jednoduchych operaci, za to vsechny stejne delky (co do doby zpracovani instrukce) a procesor je tudiz umel zpracovavat "proudove" a paralelismu to take dost pomohlo. x86 procesory maji tunu instrukci provadejici i velmi komplikovane operace, ale nez jsem se takovou instrukci naucil pouzivat, natoz kdyz jsem mel takovy kod po sobe za pul roku precist ... to jsem zase lovil v manualu

[Miloslav Ponkrác]

Je tom tim, ze pokud autor kodu pouziva konstrukce, nad kterymi je nutne se zamyslet, trha me to od pochopeni kodu jako celku a toho, co vykonava.

Jenomže mě odtrhává od kódu, když musím přemýšlet, že tato třída v Javě vlastně není třída, ale autor tím nasimuloval výčtový typ. A že tahle třída vlastně taky není třída, protože autor nasimuloval closure. A třída tři vlastně taky není třída, ale autor simuluje něco jiného.

Prostě nezlobte se, ale mě trhá od pochopení kód, který pořád něco simuluje. Daleko pochopitelnější pro mě je, když výčtový typ prostě je výčtovým typem, closure je prostě closure, a tak dále.

Je tom tim, ze pokud autor kodu pouziva konstrukce, nad kterymi je nutne se zamyslet

Nad čím se chcete zamýšlet? Jako že třeba se zamýšlíte co je to výčtový typ? Ale kdeže.

zustaneme u javy, tak to neni chudy jazyk, ale nazval bych to primy jazyk

Java je IMHO nejhůř navržený jazyk, který jsem poznal, ale nechci Vám to cpát. Má celkem dost kontrukcí ale tak očesaných, že je to vlastně chudý jazyk. A přímým bych ho rozhodně nenazval, protože jsem ještě nezažil jazyk, u kterého bych musel víc ohýbat algoritmy a víc očůrávat co se dá, abych to vyjádřil jaksi polopaticky.

kdyz me nuti vice psat, ale od toho mam IDE, aby mi to usnadnilo

Teď jste mi nahrál na smeč Takže Java je jazyk, který Vám nevyhovuje, protože potřebujete IDE, abyste mohl efektivně dělat. IDE je vlastně nadjazyk nad Javou, které Vám doplňuje konstrukce, které Vám v Javě nestačí. Vím, trochu přeháním, ale pokud IDE potřebuje zastírat nedokonalosti jazyka ...

Jestlipak vite, kolik chyb naleznete v kodu, ktery je psan C-like jazyku, chyby uplne banalni, ale protoze jazyk to umoznuje a prekladac Vam to neodhali, a to pouziti prirazeni misto porovnani - takovy to jedno krasne zapomenute rovnitko ... kolega ho objevil v kodu, ktery byl prohlasen za plne otestovany a funkcni a nasazeny v produkcnim prostredi. Pak se ptate "proc to tam sakra je?".

Jestli si myslíte, že v Javě takové rovnítko zapomenout nemůžete jste na omylu. A neznám kód, který by byl bez hromady chyb, byť funkční a nasazený a byl psát v jazyce s jednoduchými konstrukcemi, ať už je to C, Java, Pascal, atd..

Vzpomnel jsem si na assembler na proceroech Alpha. Meli jenom par jednoduchych operaci, za to vsechny stejne delky (co do doby zpracovani instrukce) a procesor je tudiz umel zpracovavat "proudove" a paralelismu to take dost pomohlo. x86 procesory maji tunu instrukci provadejici i velmi komplikovane operace, ale nez jsem se takovou instrukci naucil pouzivat, natoz kdyz jsem mel takovy kod po sobe za pul roku precist ... to jsem zase lovil v manualu

Jenže má to drobnou vadu, Alpha neprorazila. Stejně tak jako LISP, Smalltalk, Simula, a řada pěkných kvalitních jazyků. A namísto toho prorazilo hnusné C, příšerná Java, trochu kvalitnější, atd.. To je holt život, taky mě to štve, ale co nadělám.

[Ladicek]

Pak to dopadá jako u Ady, kde má frontend překladače půl milionu řádků (GNAT) Je to jasné, jazyky pro kritické aplikace musí co nejvíc možných chyb odchytit už při překladu.

Na druhou stranu existují jazyky, které bych neváhal nazvat brutálně dynamicky typovanými (kde slovo brutálně znamená, že neexistuje principiální rozdíl mezi daty a algoritmy), jejichž počet syntaktických konstrukcí je mnohem menší, ale vyjadřovací schopnosti mnohem větší. (On je to sice stejně všechno Turingáč, ale víme, o čem mluvím.) Takže provádět některá zajímavá kouzla (teď mne napadá třeba runtime modifikace kódu) může být mnohem méně náchylné na chyby právě v nich. Je to samozřejmě proto, že tohle je zase jejich nedílná součást – i když žádnou syntaxi nemá.

Je zřejmé, že intention revealing závisí na rozmanitosti jazyka, a automatické odhalování chyb taktéž. Ale některé věci se prostě líp (a s méně chybami) píšou v jazycích, které něčím takovým nedisponují a disponovat nemohou. Ne že bych to byl někdy dělal, ale myslím, že to tak musí být

[Miloslav Ponkrác]

Pak to dopadá jako u Ady, kde má frontend překladače půl milionu řádků (GNAT) Je to jasné, jazyky pro kritické aplikace musí co nejvíc možných chyb odchytit už při překladu.

Jenže Ada se Vám taky snaží pomoct, i když to na první pohled nevypadá. A mnohé věci v Adě miluju, třeba už jen to, že v C/C++, Javě, C# a dalších se plácám s tím, že musím zvolit správný integer správné délky, a občas jiný abych to měl rychlejší, tyhle věci se v Adě neřeší. Prostě řeknu jaké hodnoty tam chci cpát a zbytek je na Adě. Nebo neřeším jestli se proměnná předává hodnotou, nebo odkazem, protože to skoro nikdy řešit nechci. Ada vystihla, že mě zajímá, že chci vědět, jestli je parametr in, nebo out. A podpora multitheadingu a dalších věcí přímo konstrukcemi jazyka je docela blaho oproti tomu, když to musíte mastit na low level os api.

Prostě Ada vystihla, co chce programátor říct a nenutí ho říkat něco jiného. I když je to jazyk složitý, rozvláčný a ukecaný.

Na druhou stranu existují jazyky, které bych neváhal nazvat brutálně dynamicky typovanými

To je ale něco jiného, tam se tyje z toho, že data a kód jedno jsou a bezpečnost je v háji. Na druhé straně jsou to jazyky elegantní, jednoduché, a přitom velmi bohaté co do možností.

[Kyosuke]

Ano, a proto je Smalltalk mnohem lepší než Java - celý se vejde na půl stránky.

[Heron]

Předávání odkazu na funkci je přece jasným "obcházením" objektů. Pravda, neznám žádný návrh, jak by to mělo vypadat v Javě, ale pokud vezmu klasický odkaz na funkci, jak ji známe z C, je pak možné tohle:

Trida1 obj1 = new Trida1 ();
Trida2 obj2 = new Trida2 ();

obj1.metoda(obj2.jinaMetoda);

A včem je problém: metoda() z obj1 má přístup k jinaMetoda() z obj2 aniž by měla referenci na objekt obj2. Tedy volá metodu nějakého objektu, aniž by měla přístup k danému objektu. Tohle jsem myslel tím neobjektové a na tom trvám. Něco takového tuším umožňují i delegáty v C#.

[Kyosuke]

Tak teď to už vůbec nechápu. Čím přesně se ukazatel na členskou funkci (a.k.a. delegát, a.a.k.a. vázaná metoda ) liší od rozhraní s jedinou metodou? Tedy kromě toho, že člověk nemusí psát stupidní referenceNaRohraní.Zavolej(parametr), ale napíše jen referenceNaMetodu(parametr), protože u jednometodového rozhraní není co specifikovat. Viz třeba java.awt.event.ActionListener.

Pořád nevím, co na tom je neobjektové, když to podporují Smalltalk, Ruby, Python i další. Smalltalk dokonce zapouzdřuje do objektu i samotné zavolání metody, které se dá odchytit. ^_^ Kromě toho je to docela běžný vzor a osobně mi parametrizace kódu funkcí nebo literálem kódu vyhovuje natolik, že jazyk bez téhle funkce už prostě neberu. (Smalltalk by bez toho ani nefungoval…)

[Heron]

Tak teď to už vůbec nechápu. Čím přesně se ukazatel na členskou funkci (a.k.a. delegát, a.a.k.a. vázaná metoda ) liší od rozhraní s jedinou metodou?

Pozor, ne rozhranní s jedinou metodou (v rozhranní nelze nic implementovat), ale třída. No a liší se právě tím, že místo odkazu na jednu jedinou metodu (tedy vlastně funkci) má k disposici celý objekt. Nemůžu si pomoct, ale přijde mi trochu nesystémové, když se s objektem manipuluje "mimo objekt". Prostě se mi příčí, že někdo bude "jen tak" volat metody, aniž by k tomu objektu měl přístup jako celku. Nevím jestli si rozumíme, už se do těch slovíček trochu zamotávám. Ale myslím, že ten ukázkový kód byl jasný.

Jinak máš pravdu v tom, že pokud se bavíme o třídě implementující pouze jednu metodu tak není větší rozdíl mezi vázanou metodou a touto třídou (nebo anonymní třídou).

[Pavel Křivánek]

Když se podíváte, jak jsou uzávěry implementovány v Selfu (dialekt Smalltalku založený na prototypech a asi objektově nejčistší jazyk), tak zjistíte, že se jedná od dva až tři obyčejné objekty, které nijak nevyčnívají z jeho objektového modelu a které si udržují referenci na svého lexikálního rodiče a komunikují s ním pouze pomocí zpráv jako kdokoliv jiný. Podobně u metod. K manipulaci "mimo objekt" lze dodat ještě to, že objekty jsou v Selfu zapouzdřeny dokonce i samy před sebou.

Na uzávěrech tedy není vůbec nic nesystémového ani neobjektového. To, že Java má potíže se k nim takto postavit, je její problém.

[Miloslav Ponkrác]

To je přesně ono. Spousta lidí něco ukazuje na Javě aniž by konečně pochopila, že Java je tak ořezaný a nemotorný jazyk, že se na něm v podstatě nedá ukázat ani to objektové programování v celé kráse. Snažit se ukazovat věci na Javě je fakt dost přes ruku. Při programování v Javě se musíte velmi mnoho přizpůsobit minimálním možnostem tohoto jazyka a určitě se to nedá brát jako etalon. Já jsem před dvaceti lety programoval ve Smalltalku a vždycky mi zatrne, když někdo dává Javu za vzor objektového jazyka a neřku-li když se píše o neobjektovosti tam, kde jiné, opravdu objektové jazyky bez problémů objektově zvládají.

Prostě, když se Java navrhla neobjektově včetně primitivních typů a řadě dalších neobjektovostí, tak to už holt nikdy nenapraví. Garbage při návrhu se prostě úplně eliminovat nedá.

[happy barney]

ale toto predsa už java má a to veľmi dlho ... java.lang.reflect.Method.

[thingie]

Ano, nevím čím to je, ale pokaždý když v Javě něco potřebuju, tak skončím u slavného The reflection API

[Ladicek]

Přesně tenhle názor jsem ještě nedávno zastával, ale ona ta parametrizace kódu funkcí je skutečně velmi užitečná. Po pár skriptících v Ruby jsem reference na metody (a hlavně na anonymní metody) definitivně rehabilitoval. Náhrada objektem anonymní třídy je sice možná, ale co mi vadí snad ještě víc než ta hromada zbytečného kódu pro vytvoření instance je nutnost deklarovat extra rozhraní, tohle by se mělo dát udělat na místě použití.

[alblaho]

Jen taková poznámka na okraj: dávám přednost tomu slíznout smetanu (tj použít uzávěry v Ruby, při práci s kontejnery), než abych vědomě vymýšlel, kde parametrizovat javovskou metodu metodou.

Asi napíšu post o příliš mocných jazycích. Java je úspěšná i proto, že se v ní programuje nějakým zaběhlým způsobem. Třebaže neohrabaně.

V Ruby je možné dělat kouzla hraničící s černou magií. Třeba dodělat tam plnohodnotné AOP na padesáti řádcích. Ale nechci udržovat kód, kde každý programátor dělá takovéhle state-of-the-art vymyšlenosti. Ne, je to od toho, aby se udělal pořádný framework (RoR), který nějakých kouzel využívá (elegantní ActiveRecord) a na tom frameworku se buší bez vymyšleností, naprosto tupě s ohledem na jednoduchou business logiku.

[Ladicek]

Jen taková poznámka na okraj: dávám přednost tomu slíznout smetanu (tj použít uzávěry v Ruby, při práci s kontejnery), než abych vědomě vymýšlel, kde parametrizovat javovskou metodu metodou.

Já jsem to teď zrovna potřeboval. Pochopitelně jsem mohl mít vedle sebe čtyři metody, každou na dvacet nebo třicet řádek, které by se lišily jedním voláním kdesi uprostřed, ale to jsem radši překousl to rozhraní a anonymní vnitřní třídy. A dal bych přednost tomu, kdybych i v Javě konečně mohl slíznout takovou smetanu. Vývoj Javy dost konzervativní na to, aby to dnešní Javisti, na které ze všech stran útočí RoRýsi, v klidu překousli.

Pokud jde o AOP, tak bych zase preferoval tohle

[alblaho]

Od AOP v Javě se držím dál, pač mám rád standardy.

A tohle vyžaduje buď vlastní preprocesor jazyka, postprocesor bajtkódu nebo upravená JVM. Ani jedma možnost se mi nelíbí.

[Ladicek]

Já bych se od něj držel dál, kdybych narazil na situaci, kde by bylo vhodné, spíš proto, že současné způsoby nedovolují používání bez neustálého přemýšlení, kdy a kde to nebude fungovat. Řešení s upraveným virtuálním strojem je systémové a netrpí ani žádným z dalších neduhů, které existující řešení na bázi dynamických proxy tříd nebo speciálních ClassLoaderů a instrumentace mají. Ale než to bude někdo veřejně podporovat, nebo dokonce než na to vznikne JSR, to bude doba…