Názory k článku
Groovy v příkladech: úvod do jazyka

Navrhujem, aby kazde 3 mesiace vysiel novy programovaci jazyk, v ktorom sa nasledne budu zacinat vsetky projekty az kym nevyjde dalsi programovaci jazyk. :-)

proboha proc? to vypada jak PHP liznute trochou ruby a jeste je to nad javou. - komentar "zlepsovak" je na miste no :)

Tak PHP bych do toho netahal, to je totiž naprosto neskutečný nekoncepční bastl.

Groovy je prostě "Ruby nad Javou", je to s Javou provázené mnohem líp než JRuby. A to je v pořádku, Ruby je moc dobrý jazyk a javisti po něčem takovém evidentně vytváří poptávku.

Ja bych treba uvital porovnani Groovy s "konkurenci", v tomto pripade asi s Jythonem, ktery je v nekterych aspektech lepe svazany s Javovskymi knihovnami nez samotna Java :-)

mimochodem, opravdu je null v Groovy chapane jako logicka hodnota? To se trosku podoba Lispu, ale ten se zase nezatezuje zbytecnostmi typu true/false :-)

>Co se týče silného vs. slabého typování, Groovy je slabě typovaný jazyk. Někomu to může vyhovovat, ale dle mého názoru to bohužel omezuje vhodnost Groovy pro použití na větší projekty.

Já si myslím, že to vadit nemusí. Ono _jsou_ velké projekty v dynamických jazycích. Typová kontrola jistě má své plusy, to se nehádám, ale u velkých projektů se často stává, že podstatná část kódu se stará o *obcházení* typové kontroly (dokonce je na to design pattern: Adaptér).

Jinak viz http://www.abclinuxu.cz/blog/alblog/2007/6/3/182293

Vzdycky se najdou velke projekty psane i v dynamickych jazycich. Jako priklad bych mohl uvest napriklad software Apple, ktery je psany v Objective-C. Ale faktem je, ze na vetsi projekty je obecne lepsi silne typovany jazyk.

Je pravda, ze silna typovost jeste nezaruci spravnost behu aplikace. Nicmene uz behem psani kodu eliminuje moznost vyskytu spousty zbytecnych (a nekdy tezko nalezitelnych) chyb. Stejne jako unit testy nezaruci bezchybnou funkci aplikace, ale eliminuji obrovske mnozstvi regresivnich chyb.

Hezkou "novinkou" je v IntelliJ IDEA staticka inspekce kodu. Tohle funguje tak, ze hleda krome syntaktickych chyb i konstrukce, ktere napriklad mohou snizit vykon. Pomaha odhalit nejake potencialni chyby jako je nekonecna rekurze, vecne bezici cykly, podminky ktere vzdyky nabidou hodnoty true/false, mista kde hrozi NullPointerException, mista kde se misto pouziti logovani pise do konzole, pripady zbytecne silneho typovani, cyklicke zavislosti, spatne abstrakce apod. Tech testovanych konstrukci jsou tam snad stovky a muzete si nastavit na co vas bude podtrhavanim upozornovat. Tohle je vec, ktera vam taky nezajisti bezchybnost aplikace, ale pomuze vam najit mista potencialnich problemu, bez jedineho spusteni aplikace s minimalni namahou a minimem zabiteho casu.

U malych aplikaci se to nezda, ale cim vic aplikace roste, tim se stava debugovani narocnejsi a cim vic problemu se odhali automaticky tim lip.

Já v podstatě souhlasím, dřinu strojům.

Já jsem bývalý zastánce Ady, pak jsem dost dělal v Javě/C#, no a teď mi vyhovuje spíš Python/Ruby. No a čím víc v tom Pythonu dělám, tím víc mám pocit, že se typová kontrola přeceňuje. Spíš ocením, když je můj program o polovinu kratší.

jak rikam zalezi na velikosti projektu ... kdyz bude potreba nascriptovat chovani jednohe postavy ve hre pouziju ruby, kdyz budu delat neco vetsiho pouziju javu

stejne vetsinu kodu doplnuje IDE takze realna delka psani je podstatne kratsi ... pri cteni kodu pak naopak typy pomahaji pochopit o co v kodu jde (obzvlaste u ciziho) ... navic sani kodu pri vyvoji aplikace je jen velmi kratkou etapou ... myslim, ze drtivou cast vyvoje zabira premysleni, ne?

jen takove poznamky k ADA, uz kdyz vysla, tak byla experty hodnocena jako "fat, but not strong" (nabobtnaly, ale slaby jazyk) ... nevim, jak je to s ADA 2005 (ktera vychazi z udajne z Javy) ... python zase prodelava prechod na python 3000, ktere odstranuje chyby v jazyce a neni zpetne kompatibilni

co se mi libi na Jave je, ze toho umi "malo" a to je presne to co clovek potrebuje ... neni tam moc specialnich konstruktu apod. ... ale celkem se strachem se divam na navrhy k Jave 7 ... z nekterych navrhu mi vstavaji vlasy na hlave

Java byla v prvních verzích fakt hezký minimalistický jazyk, ale od té doby, co tam přidali enum (nic proti enumům, ale ten javovský z jazyka čouhá jak smeták ze zadku znásilněného vězně). C# nabobtnal ještě mnohem hůř.

"fat, but not strong" jsem tedy fakt neslyšel a rozhodně se s tímto názorem neztotožňuji. Ada je super, až na pár věcí: strašlivá práce s řetězci, neuvěřitelně toporné OOP. Ale jinak ten typový systém, to je fakt namáklost. Jakmile to jednou překladač zkompiloval, tak to fungovalo :-). Ada 95 byla tak na hranici přerostenosti, Ada 2005 (vlastně ani nevím, jestli ten standard schválili) trochu napravuje to OOP, s Javou to IMO souvislost nemá.

Že typování zlepšuje čitelnost, s tím souhlasím. Občas jsem v Pythonu ztracený, když nevím, jestli je ten parametr string nebo int nebo ňejaký šílený objekt. Že program se jednou napíše a pak X-krát čte, to je taky pravda. Že s psaním pomáhá IDE je taky pravda, ale problémem může být spravování takového "vygenerovaného" kódu. Třeba takové gettery settery, to je v Javě mor - hromada balastu, co nemá žádný význam.

Osobně skutečně směřuji k tomu, jazyky, kde je víc abstrakce a míň psaní. Ano, přiznám se, nedělám na velkých projektech...

Gettery a settery jsou obecne "problem" a mnoho jazyku je resi mnoha zpusoby. Na tohle jsou prave v Jave 7 navrzeny properties. Me osobne se, ale tento navrh nelibi, protoze zavadi jeste neco dalsiho krome metod a fieldu. Treba v ActionScriptu je to uplne peklo a vubec neni jasne co je co.

C# syntax na getter a setter mi jako zkratka obecne neprijde nejlepsi a to, ze clovek jakoby prirazuje promenne, ale realne se provadi cokoliv jineho mi neprijde idealni.

Faktem je, ze vyrobeni getteru a setteru je zalezitost stisku jedne klavesove zkratky na jejich vygenerovani pro field, na kterem mam kurzor. Tezko rict jak to vyresit obecne a nejlip, ale mozna je dobre, ze se to resi tim, ze to IDE udela.

Tak já mám na to docela jasný názor. O co v těch getterech/setterech vlastně jde? Mít tam mermomocí volání metody? Ne, jde o to mít možnost pověsit na čtení/změnu proměnné nějakou akci bez toho, aby se musel předělávat zbytek programu. Proto se tam rovnou prskne metoda, i když ve většině případů bude naprosto triviální.

Když tyhle triviální metody vygeneruje IDE, tak je sice nemusíš psát, ale musíš je číst, protože prostě sou součástí kódu. To mi vadí.

Naopak nemám problém, když se getter-setter používá jako obyčejné proměnné (tedy property). Někteří programátoři chtějí být falešnými pány situace a vidět, kdy se fakt jenom čte proměnná a kdy se fakt volá metoda, chtějí rozlišovat "levné" čtení a "drahé" volání metody. Ale to je jen takové nutkání, v Javě přece normálně používáš gettery a spoléháš na to, že jejich provedení je rychlé, ale ono nemusí.

Takže nejlíp to má IMO Ruby. U každé členské proměnné se uvede, jestli se pro ni má generovat getter/setter, tím, že se uvede do seznamu attr_reader nebo attr_accessor. Takže tam není žádný vygenerovaný balast. No a když potřebuješ netriviální g-s, tak si ho tam prostě připíšeš. To řešení v C# je takové polovičaté.

V Pythonu g-s zadrátované nejsou, ale díky dynamičnosti jazyka jdou vytvářet automaticky, tekže lze dosáhnout stejné efektnosti jako u Ruby.

Jak rikam, ani jedno z uvadenych reseni mi neprijde idealni. Nebyl by problem funkcionalitu podobnou Ruby pridat pomoci anotaci:

@Read
private int size;

@Read @Write
private String name;


... ale jak rikam. Nejsem moc velky priznivce takoveho postupu. Pak je otazka, jestli zapouzdreni pomoci "private" ma vubec vyznam (u dynamickych jazyku vlastne neexistuje, ale Java diky bohu neni dynamicka).

Dalsi dulezity aspekt je ten, ze podle principu OOP byste spravne mel mit na vsechno interfacy, kvuli oddeleni implementace. Coz zrovna properties neumoznuji. Proto se podle me opravdu hodi jen do mensich projektu a/nebo scriptovacich jazyku. U vetrsich projektu casti existuje API (hlavne interfacy) uplne oddelene od implementace (tridy). Obe casti se pak spojuji pomoci depencency injection (usnadneni testovani a nasazeni).

Myslim, ze properties jsou v _Jave_ na skodu a prinesli by jen zbytecnou funkcionalitu do jazyka. Myslim, ze z dlouhodobeho hlediska nejsou pro Javu perspektivni. Ve scriptovacich jazycich podle me vyznam maji.

Dalsi dulezity aspekt je ten, ze podle principu OOP byste spravne mel mit na vsechno interfacy, kvuli oddeleni implementace. Coz zrovna properties neumoznuji. Proto se podle me opravdu hodi jen do mensich projektu a/nebo scriptovacich jazyku.

No to je dobrý humor. Property není interface? A čím přesně? Accessory (ekvivalent properties) jsou i v Common Lispu. To určitě není "skriptovací jazyk" a statisíce řádků v projektu bych neoznačil za "malé projekty". :-) Myslím, že jako všichni javisté máte představu o OOP řádsky pokroucenou. To byste mohl popřít existenci Smalltalku. :-D Ale to vám nepomůže, Smalltalk prokazatelně existuje a funguje.

Ano, doporuceni ja "spravne" pristupovat k OOP je nekolik a nektere si i vzajemne odporuji (statika vs. dynamika). Zase programatori SmallTalku budou rikat, ze Java neni dobra na OOP, protoze ne vsechno je v ni objekt (podle me, ale napriklad _1_ je hodnota, ale ne objekt).

SmallTalk v podstate interface nezna (sice tam nekdy prubezne pribily protokoly), takze opravdu tam nemohlo existovat doporuceni na udelani interface a potom tridy.

Ad property neni interface: nejsem si jisty, protoze property je v podstate field s automatickym getterem a setterem. G+S by sice mohli byt v definici nejakeho interfacu, ale ten field podle me dost tezko. Takze, kdyz si nekde v interfacu nadefinuji property, tak bych mel byt schopen implementovat G+S, i tak ze prakticky nebude "property" pouzivat. Napriklad nastavi 4 jine fieldy, ktere v dane implementaci zastupuji property. Pouziti v interfacu mi teda prijde podivne/matouci. To tam radsi hodim "getter" a "setter" misto jedne "property".

PS: jak jsem uvedl v nekterem z predchozich prispevku, vzdy se da najit velky projekt skoro v jakemkoliv jazyce (uvadel jsem Apple v Objective-C). To ale zdaleka neznamena, ze je to ten nejvhodnejsi jazyk pro dane projekty. Neco podobneho bych mohl rict o Lispu, ale tam neznam zadny velky projekt (ale verim, ze byt muze).

RTFM !

println 1.plus(1)

coz se cte *mnohem* vic 'objektove'!