Názory k článku
Groovy: Java má vzdáleného bratrance

Groovy bych rozhodne doporucil k vyzkouseni. Pokud chcete zacit programovat, tak rovnou preskocte javu a zacnete s timto.

Groovy je skvele na mensi projekty nebo prototypy. Take bych o nem uvazoval pokud mate v tymu neJavare, ma o dost rychlejsi start.

A je to porad bytecode, takze je to o dost pouzitelnejsi nez bastl zacinajici na R.

Groovy ma ale dve vady:
1) je pomalejsi nez klasicka Java, hlavne casti pracujici s dedicnosti a typy. Udava se 2x az 50x, je to zpusobene slozitejsi dedicnosti/typeless...
2) kompilator neumi soucasne kombinovat kod groovy a javy.

Moje doporuceni je tedy nabusit objektovy model v klasicke jave a ostatni veci v groovy.

1)Zvysi se tim rychlost (jen 2x az 5x pomalejsi).
2)ORM, annotace a podobne opicarny jsou jednodussi (jde to ale i promo z Groovy)
3)Dvere do javy zustanou otevrene.

PS: idealni doplnek pro data storage http://www.db4o.com/about/productinformation/

"A je to porad bytecode, takze je to o dost pouzitelnejsi nez bastl zacinajici na R"

Tak tady bych s výběrem slov byl opatrnější, a to nejen kvůli osobě autora. :-) To už bych rovnou mohl říct, že je mnohem lepší použít Common Lisp, protože "je to pořád poctivý nativní kód, takže je to o dost použitelnější, než bastl začínající na J." ;-) (A možná by to byla pravda, vzhledem k existenci léty prověřených objektových systémů, které s "dědičností a typy" umějí mnohem víc a přitom nejsou tak pomalé. :-) Tohle jen ukazuje, že suní Java je nejlepší implementace Javy, ale znásilňovat do ní jiné jazyky nemá až takový smysl.)

A JR snad není bytecode?

Co se tyce bytekode, dobre, pokud se Vam nelibi MRI (coz docela chapu), porad je tu nekolik dalsich implementaci. JRuby uz je skvele pouzitelne, Rubinius zanedlouho bude, prave jsem ho zkousel, klape dost slusne, jsou dve nadejne dotnetí implementace a vlastni problem naivni interpretace vyresi YARV, ktery ma byt v Ruby 1.9.1 ... vice o tom psal David Majda na http://www.majda.cz/download/alternativni-implementace-ruby.html

JetBrains uvolnili cross compiler, ktery zkompiluje najednou jak javu, tak groovy.

...není funkcionální jazyk ;)

Jojo, pěknej úlet :-)

Chyba je opravena. Jakuba pravděpodobně zmátlo, že Smalltalk má některé funkcionální rysy, ale to z něj ještě nedělá funkcionální jazyk.

Smalltalk opravdu, ale opravdu není funkcionální jazyk. Naopak se snaží být krystalicky čistým naplněním objektového paradigmatu.
Funkcionální jazyky jsou např. Lisp, Scheme nebo Haskell.

Tak už mě předběhli...

Dik za upozorneni ... ve Smalltalku jsem nikdy nepsal, jen vim, co z nej je prejato do Ruby :)) Co to teda je za typ jazyku?

Doporucuji serial na root.cz, pane redaktore ;) http://www.root.cz/clanky/squeak-navrat-do-budoucnosti/

Sakrys, jsem to dneska ale otravny :-)

Mě taky. Ale chtěl jsem to určitě napsat první. :-D

objektove orientovany ;)

A kdybysme chteli byt puntickari, tak ani lisp a scheme nejsou tak docela funkcionalni, i kdyz se mezi ne obecne radi ;-) Tedy alespon ne ciste funkcionalni, coz znamena, ze je mozne v nich psat programy ciste imperativnim zpusobem. Stejne tak muzu psat napr. v pythonu tim stejnym stylem, jakym pisu v lispu (nemam na mysli syntaxi, ta je vedlejsi), muzu tedy rict, ze python je funkcionalni jazyk?

Python je multiparadigmatický jazyk. Podobně jako třeba C++.
(Totéž lze samozřejmě říct i třeba o zmíněném Scheme, ale v něm funkcionální paradigma hraje natolik klíčovou roli, že je obvykle považován za funkcionální.)

Já to s oblibou formuluju tak, že Lisp/Scheme je univerzální, nejen proto, co všechno umí sám, ale i proto, co všechno ho lze naučit. ;-)

Nezdá se mi, že zrovna Smalltalk by byl brán jako jeden z funkcionálních jazyků. Ikdyž, samozřejmě, nějaké funkcionální prvky obsahuje; ale to se dá říci i o C, ne?

Groovy je asi fajn, možná lepší než lámat přes koleno Ruby k JRuby.

Ale ty Grails, to fakt nevím. Sice ten kód připomíná RoR, ale oproti RoR/Djangu je to monstrum (Hibernate...). Prostě hlavní výhoda těch lehkých frameworků - a to zero turnaround time tam není. Pokud to běží na Tomcatu, tak bych to nechtěl... Chce to lehký server, bez cachování, bez deployingu.

Jako je to tak, Grails jsou dost kolos a kdyz se clovek kouka na ta demonstracni videa, kde tam bastli neco ve vimu na consoli bez zapleho :syntax on, tak je videt, ze se od Rails meli poucit daleko vic, ale napad je to zajimavy.

-Groovy je dynamicky jazyk, ne skriptovaci - muzete sice spoustet zdrojaky primo, ale ony se stejne vzdy na pozadi kompiluji do bytekodu.
-Groovy umoznuje jak staticke, tak dynamicke typovani

Jinak skvely jazyk na prototypy, webove roboty, praci s textem a ruzne testovaci veci. Na vetsi projekty bych z duvodu udrzby nedoporucoval.

S tim bych si dovolil nesouhlasit. Ze je jazyk skriptovaci urcite neznamena, ze nemuze byt kompilovan do bytecode. Ano, Groovy umoznuje i staticke typovani, kladl jsem duraz na to dynamicke typovani, ktere je v kontextu s urcenim Groovy dle meho nazoru podstatnejsi.

Kdyz to berete takhle, tak si muzete klidne vystacit s assemblerem ... ktery je navic rychly, proste prima jazyk ;)

+1

Plny souhlas. Prijde mi uplne zbytecne, ze nekdo porad vymysli nove a nove programovaci jazyky s novou syntaxi. Kdo si to ma taky pamatovat.
Ti co programuji ve vice nez 2. jazycich zjisti, ze se jim neustale plete syntaxe z jednoho do druheho. Jinymi slovy - at uz konecne nekdo vymysli Java skriptovaci jazyk se zcela stejnou syntaxi jako ma klasicka Sun Java (ale ne strasne omezeny JavaScript !).

hh, groovy. To budou zase Script Kiddies mit radost, co? Jediny script, ktery mam rad je ten, co si poctive vygeneruji pomoci kompilovaneho jazyka :-D

Programovaci jazyky se rozdeluji na kompilovane a interpretovane, funkcionalni a objektove, low-level a high-level, reknete mi tedy jaktoze si myslite, ze existuji staticke a dynamicke? To si pravdepodobne pletete webove prezentace (staticke a dynamicke) s jazyky ;)

Jen spete dal, scripting je vhodny presne pro takove jako jste vy, tedy abych byl konkretni nemusite znat vubec nic a stejne muzete scriptovat od rana do vecera v cemkoliv od Ruby az po Lisp

Ááá, zdá se, že pán je skutečně odporník. :-D http://www.root.cz/clanky/staticka-dynamicka-typova-kontrola/ ty webová prezentace BTW: kompilovany a interpretovany jazyk je otazkou implementace jazyka. Existuje interpret jazyka C (tcc) a naopak, najit cisty interpret Lispu neni snadne, protoze vetsina implementaci jsou kompilatory.

A proč v Lispu skriptovat a ne rovnou programovat? Zvlášť když to je výkonný, kompilovaný, dynamický a univerzální (jako protiklad ke všem těm čistě objektovým, čistě funkcionálním a dalším) jazyk. ;-)

V komplexnych projektoch ma syntax marginalny vplyv na citatelnost vysledku. Citatelnost a lahkost porozumiet kodu a schopnost ho udrzovat je o rozumnej a prehladnej architekture, cistej implementacii algoritmov a dokumentacii. Programy v Jave napr. casto umelo rozbiju celu logiku programu medzi mnozstvo neprehladnych ad-hoc tried - kodu je vela a je nepriamociary. V Perle je to iste riesenie problemu casto implementovane v jednom subore v ktorom sa da lahko orientovat a casto ma 10x menej riadkov. Syntax Perlu je bohata - ale ked sa ju naucite, tak zistite, ze sa viete efektivne a cisto vyjadrovat. Mne sa lahsie udrzuje kratky a prehladny kod - tiez riziko chyb je v takom kode mensie.

Souhlasím s Vámi. Kritikům bych rád připoměl, že nepřehlednost kódu není vlastností programovacího jazyka ale vlastností programátora! Je sice fakt, že v Perlu si různí autoři mohou oblíbit natolik rozdílné konstrukce, že výsledek nepřipomíná společný jazyk. Pak je na šéfovi projektu, aby je umravnil a stanovil nějaká společná pravidla. A i když je mnohá kritika Perlu oprávněná, jedno se Larrymu upřít nedá. Perl je opravdu diagonální jazyk. Diagonální v tom smyslu, že lze přímo - po diagonále - řešit to, co v mnoha jiných jazycích musím řešit oklikou - po odvěsnách . Tam mě vždy rozčilovalo, že když konečně vymyslím schopnej algoritmus, musím další hodiny věnovat tomu, jak ho vlastně implementovat, protože díky mnoha omezením to přímo nejde. (Larry mluví o narážení do skleněných stěn). Nakonec se to sice přez různé objížďky a finty povede, ale logika původního algoritmu je ta tam. Co je platné, že elementární instrukce jsou jasné a čitelné, když smysl celku potom uniká.

Hodil by se nějaký diagonální příklad, aby například pythonista poznal, co diagonálního Perl umí.

Vymena obsahu premennych bez pomocnej premennej?

($a, $b) = ($b, $a)

Python: a, b = b, a
Ruby: a, b = b, a
Ocaml: let a, b = b, a

Ten Python a Ruby beriem (syntax inspirovana Perlom). Priklad v OCaml robi nie co ine; definuje nove premenne, ktore zakryju v danom rozsahu povodne a, b. Premenne (okrem ref) su v OCaml predsa konstantne.

Ok, vymena premennych nevysla. Co tak parsovanie URL argumentov do hash/map premennej?

$urlArgs = 'key1=value1&key2=value2';

%params = map { $$_[0] => $$_[1] }
          map { [ split /=/, $_ ] }
          split /\&/, $urlArgs;

Ako nieco podobne bude vyzerat v Python/Ruby?

V Pythonu treba:

urlArgs = 'key1=value1&key2=value2'

params = dict(oneParam.split('=') for oneParam in urlArgs.split('&'))

Ok. A co ak by som chcel do toho slovniku zapisat len parametre, kde kluc aj hodnota zacina velkym pismenom. Do slovnika ich chcem ale pridat s malymi pismenami.

params = dict((key[0].lower() + key[1:], value[0].lower() + value[1:]) for key, value in
(oneParam.split('=') for oneParam in urlArgs.split('&'))
if (key[0].isupper() and value[0].isupper()))

Tahle konstrukce uz je ale dost krkolomna a nemyslim, ze tohle je nutne resit jednim prikazem. Bylo by to v Perlu strucnejsi a hlavne citelnejsi?

Redakcni system sezral odsazeni, ale v tomto pripade neni z hlediska funkce nutne.

Redakcni system sezral odsazeni, ale v tomto pripade neni z hlediska funkce nutne.

Tiez jeden z dovodov, preco mi to vynutene odsadzovanie nesedi :)

No, svoje nevýhody jistě má. Ale to je věc názoru.

V Perle mozem jednoducho doplnit tuto logiku to povodneho riesenia:

%params = map  { +"\l$_->[0]" => "\l$$_[1]" }
          grep { $$_[0] =~ /^\p{IsUpper}/ && $$_[1] =~ /^\p{IsUpper}/ }
          map  { [ split /=/, $_ ] }
          split '&', $urlArgs;

Vsimite si ako je ten kod linearizovany - ziadny vnoreny "for" a cely kod neprehladne uzaverety do volania dict(). Moje riesenie je uplne standardny Perl - vas Python kod by ste v normalnom projekte takto nezapisali pretoze ten vnoreny for je neprehladny.

Dajme si este jedno kolo - ake je hodnota parametra vo formate YYYY-MM-DD a rok je nizsi ako 2000, tak nech je zapisany ako rok 2000.

Pre referenciu predkladam riesenie v Perle:

#!/usr/bin/perl

$urlArgs = '=Value1&Key2=Value2&Key3=1999-12-02';

%params = map  { +"\l$$_[0]" => "\l$$_[1]" }
          map  { $$_[1] =~ s/^(\d{4})/$1 < 2000 ? 2000 : $1/e; $_ }
          grep { $$_[0] =~ /^\p{IsUpper}/ &&
                 $$_[1] =~ /^(\p{IsUpper}|\d{4}(-\d\d){2}$)/ }
          map  { [ split /=/, $_ ] }
          split '&', $urlArgs;

print "$params{key3}\n";

Opat linearne pridanie zopar prikazov do existujuceho kodu. Standardny Perlovsky text-processing.

Zeleny caj mam rad :)
Niekto kompetentny by sa mohol pokusit prepisat to do Groovy pre porovananie.

ako perlista si dovolim este jedno male stuchnutie: ktory z uvedenych prikladov je citatelnejsi?
zdanlivo lepsi python, preto nuti odsadzovat, alebo perl, ktory vam dava volnost?

v mojich ociach vitazi jednoznacne perl.

Filosofie Perlu je, ze existuje mnoho cest k jednomu cili, Python tvrdi, ze v mnoha pripadech existuje jedna spravna.

Ten priklad, ktery kolega dal, je asi citelnejsi; zvlast kdyz clovek zna syntaxi Perlu. Ja bych ale uvedeny "one-line" pristup pro slozitejsi zpracovani nikdy nepouzil - to je lepsi pouzit cyklus nebo vnorene funkce. Bez ohledu na pouzity programovaci jazyk.

Tiez som si vsimol, ze vo vasom kode ak zadam nespravny vstup; napr:

urlArgs = '=Value1&Key2=Value2'

tak to hodi, vynimku. Moja Perl verzia nespravne hodnoty korektne odfiltruje/ignoruje.

Vyjimku to hodi, protoze dela presne to, co jsem chtel a nic vic, nic min.

Tak skuste chciet aj osetrit nespravny vstup. Google na vas tiez nevyhodi vynimku ked zadate:

http://www.google.com/search?abc&&q=root.cz&abc=abc=abc

V Perle to bolo osetrene hned na prvy krat.

No a?

No a to je odpoved na vasu povodnu otazku o diagonalnich schopnostiach Perlu :)

Python se na stavbu robustních aplikací určitě hodí, ale někteří pythonisté ne. ;-) A tak to bude asi se vším.

Ja len zopakujem velku pravdu, ze na kvalitu vysledku maju najvacsi vplyv schopnosti programatora. Ak niekto dobre ovlada Python/Ruby/Perl/PHP tak nema dovod prechadzat na iny jazyk len preto, ze ten je dnes "in". Napokon TeX napisal D.Knuth v archaickom jazyku WEB (nieco ako obmedzeny pascal - Knuth si ho napisal sam) a dodnes ten typesetting engine nie je v mnohych aspektoch prekonany. Tiez je dolezite, ci programovanie v danom jazyku je pre kodera dostatocna zabava.

Rejpale, nerejpej. Mně bylo samozřejmě od začátku jasné, že ten kód neošetřuje špatně formátovaný vstup. Ale chtěl jsem ukázat co nejjednodušší řešení daného úkolu. To se ví, že v praxi bych si to nelasnul.

Dobrá tedy, Perl má nadprůměrně rozvinuté prostředky pro práci s textem, na tom se shodneme. Koneckonců to vyplývá i z názvu.

A k tomu Ocaml: ten (pokud vynechame reference atd.) v podstate promenne nema. Let pouze provadi substituci v danem vyrazu.

A chapeme slovo premenna doslovne ako nieco co sa da menit (ignoruc vyraz "konstantna premenna"), tak okrem refs ma OCaml skutocne len konstanty. Az jednu nepeknu vynimku - retazce:


let s = "hello world" in s.[0] <- 'H'; print_string s;;

Toto je jeden z dovodov preco preferujem Perl. Idioti sa ho nenaucia a tak ak mam po niekom udriavat kod, tak viem, ze si nebudem trhat vlasy - pretoze ho pisal skutocny programator.

Perl pouziva rozne specialne znaky pre dobry dovod. Napr. podla

%var = funkcia();

viem, ze funkcia vratila hash/dictionary. V Pythone podla:

var = funkcia()

Neviem o premennej var absolutne nic.

V Pythonu je mozne zjistit typ promenne pomoci type(var) nebo treba isinstance(var, dict). Zajistit spravny typ navratove hodnoty se da prikazat pomoci assertu, dekoratoru a v Pythonu 3000 asi nejlepe anotace. Co promenna obsahuje, by zejmena mel rikat nazev promenne a dokumentace te funkce (docstring). Tohle je "malinko" univerzalnejsi, protoze v praxi se clovek neomezuje na par typu, ktere lze oznacit nejakym znakem pred nazvem.

Pravda, nie je to celkom univerzalne ale zvysuje to citatelnost kodu dost zasadne v mnohych situaciach. type(var) (obdoba ref(EXPR) v Perle) je pekna vec ale tu ide o citalenost kodu a nie jeho debuggovanie.

Inak zvlastne, ze ked niekto kritizuje v Pythone vynutene odsadzovanie - tak argument je, ze to zvysuje citatelnost kodu a teda to nemoze byt ponechane na slobodnom uvazeni programatora. Ale ak niekto poukaze, ze jazyk nevynucuje lahke odlisenie zakladnych datovych typov, tak argument je, ze je na programatorovi aby uvazene nazval premenne :)

Ach jaj. Kolko z Vas robi projekty od piky ? Velmi malo ludi. su to 3 skupiny:

1. ti co ovladaju programovat a chcu sa nieco naucit sami
2. ti co programovat nevedia a myslia si, ze to zvladnu (nepoznaju dostupnost frameworkov)
3. to iste ako skupina cislo 1, ak maju tvorit nejake presne aplikacie na mieru a dostupne frameworky neposkytuju vsetko potrebne, pricom upravit ich by bolo zlozitejsie.

Ak si sa stretol s ludmi zo skupiny 2 tak to chapem, lebo podobne kody nikdy nebudes musiet vediet naspamat a tebe bude stacit volat iba metodu, ktora to vsetko spravi za teba.

Žádný skript přeci nemůžete pochopit, pokud netušíte, co dělají standartní funkce jazyka. A to zdaleka neplatí pouze pro Perl. A pokud chcete skript upravovat, musíte se jazyk alespoň trochu naučit. Člověk neznalý Angličtiny také neupravuje Shakespeara. Něco jiného je nesrozumitelnost textu pro jeho nelogičnost a něco jiného je nesrozumitelnost textu pro neznalost jazyka. Je snad Maďarština nepoužitelná?

Pokus o Ruby: :-)

$urlArgs = 'key1=value1&key2=value2'

$params = Hash[*$urlArgs.split(/&/).map{|kv| kv.split(/=/)}.flatten]

Pekna linearna verzia. Dokonca zvlada aj urcite nekorektne vstupy. Avsak nie takyto:

$urlArgs = 'key0&&key1=value1&key2=value2'

Co naplat, musím na to složitěji: :-)

$params = Hash[*$urlArgs.split(/&/).grep(/([^=]+)=([^=]+)/){[$1,$2]}.flatten]

Hehe, tak to je skvela finta! V Perle by som to zapisal takto:

%params = map { @$_ } grep { /([^=]+)=([^=]+)/ && ($_=[$1,$2]) } split /&/, $urlArgs;

my %params = map { split /=/, $_, 2 } grep { /=/ } split /&/, $urlArgs;

Pekne riesenie. Nie je to sice presne to iste ako predtym uvedene riesenie. Napr. vstup ako:

$urlArgs = 'Key1=Value1a=Value1b&Key2=Value2';

To spracuje inak, ale myslim, ze spravnejsie.

Podobna "priamociara" verzia, ktora neosetruje vsetky nekoretkne vstupy vyzera takto

%params = map { split /=/ } split /&/, $urlArgs;

No jo, no - mně golf nikdy nešel. :-)

Kyosuke, Tialko, Kubo, prosime, ozvi se. Jsme uplne vydeseny, co je s tebou. Pripominam muj mail: j.vysata@centrum.cz

Radi bychom se dozvedeli, ze jeste zijes.

Jirka Vysata (Arrendo)

Indexovat můžete i seznam:

my %params = map { ( split /=/, $_ )[ 0, 1 ] } split /&/, $urlArgs;

To ma nanapadlo - ale teraz ked to vidim, tak je to uplne logicke. Dik! Cesta k osvieteniu v Perle je dlha...

Common Lisp: (rotatef a b) - a funguje to s libovolným počtem proměnných - nebo spíš "places", mohou to být i přístupy do datových struktur.

"Vymena obsahu premennych bez pomocnej premennej?" To je neco, co vetsinou neexistuje, ve skutecnosti se nejaka mezipromenna pouzije a kdyz uz trvam na tom aby se nepouzila, chci presne vedet, jak se to stane a proto jedine C++ a b=a^b, a=b^a, b=a^b;
:-) :-) :-)

a nebo

b=a+b;
a=b-a;
b=b-a;

nebo

void swap(int &a,int &b)
{
try
{
throw a;
}
catch(int falling)
{
a=b;
b=falling;
}
}

nebo dokonce :-)

void swap(int &a,int &b)
{
if(a<b)
{
--b;
swap(a,b);
++a;
}
else
if(a>b)
{
--a;
swap(a,b);
++b;
}
}

lepsi jsou ty XORy, protoze funguji vzdy. Ona totiz operace + a - nedela v mnoha pripadech to, co v matematice. Napriklad pro floaty. Ale ta verze s vyhazovanim vyjimky se mi dost libi, to je spravny rychly pristup :-)

Zjevně jsi nikdy neslyšel o assemblerovském XCHG... ;-)

Jo jo, to mě napadlo jako první. Hlavně si ale myslím, že uvažovat na takto nízké úrovni (co se přesně děje, když programovací jazyk prohodí obsah dvou proměnných), je nesmysl i v C. Pokud nemám např. zaručeno, že se pro dané proměnné použije registr (a to C++ zajistit nemůže), může se dít docela dost různých věcí. Proto v aplikacích používám raději vyšší jazyky, abych nemusel řešit kraviny typu alokace paměti atd.

Nesmysl je tvrdit něco takového obecně. Když programuješ například na úrovni jednotlivých pixelů, tak prostě nemáš možnost si zjednodušovat práci jakýmkoliv vyšším jazykem.

Jsou případy, kdy to neplatí, souhlasím.

Nu. takřka na cokoliv se dá napsat vyšší jazyk, obzvlášť pokud je doména úzce omezená. Třeba RenderMan Shading Language pracuje s miliony barvových hodnot, a je to specializovaný vysokoúrovňový (relativně :-)) jazyk navržený právě pro manipulaci s barvami milionů mikropolygonů.

Nejlepší je umět specializované jazyky dělat, tím si člověk ušetří nejvíc práce, pokud se nějaké aplikační doméně chce věnovat trvale. ;-)

Co si představuješ pod pojmem "vyšší jazyk"? RenderMan Shading Language? Moc o tom nevím, ale mám pocit, že to jsou krátké rutinky, které se kompilují a pak rovnou spouští. A teď se dívám, že to má oholený C zápis, nejsložitější datový typ je jednosměrné pole a velikost všech dat musí být známa v době kompilace. Tohle bych řekl, že je spíš klasická ukázka hodně low-level jazyka.

Ani xchg se neobejde bez pomocne promenne (nejakeho temporary registru), protoze se jedna o cteni a zapis probihajici na jedne sbernici, ktery je nutno rozdelit do dvou kroku. Zalezi na tom, na jake urovni (vzdalenosti od HW) se budeme pohybovat, ale prohozeni dvou hodnot lezicich na jinem miste se bez pomocne promenne nebo nejakych obezlicek typu +-- ci ^^^ (viz prechozi kody) neobejde.

To sice jo, ale minimálně v případě místních proměnných v registrech by to měl ošetřit rovnou register renaming, ne? ;-)

to ano, pokud se nesaha do pameti, tak by s tim procesor mohl neco udelat (protoze moderni CPU uz klasickou interni datovou sbernici ani nemaji, cest mezi ruznymi jednotkami tam existuje vic a sbernice by vsechno zdrzovala).

Však já architekturu procesorů nějakou dobu studoval... ;-)

to je dobre, vzdycky je dobre tusit, co se vlastne uvnitr toho svaba deje :-) i kdyz mam dojem, ze ty nejlepsi technicke figle si stejne vyrobci chrani.

Mimochodem, nejlepe se swap dvou hodnot zapise v C--, protoze na to ma krasny operator >< (to je posledni kombinace znaku < a >, ostatni kombinace jsou "zabrane")

Skoda, ze se C-- uz moc nevyviji, jako lepsi makroassembler to bylo takrka dokonale.

No, ono by to << nebo >> stejne moc dobre nevystihovalo podstatu akce. ;-)

Zrovna Python jsem na mysli neměl. Je to velice dynamický, logický a "pedagogický" jazyk a i když mému naturelu je Perl bližší, Python bych rozhodně nehaněl. (Nemám ve zvyku nadávat na něco jen proto, že můj favorit je jiný). Co mě od Pythonu odrazuje je výlučné předávání parametrů pomocí odkazů. (I když to mnozí chválí). Nechci aby mi modul zničil data, která má poze číst, jen proto, že jsem já nebo někdo jiný udělal v modulu chybu.

Jinak na Vaši otázku nedokážu dost dobře odpovědět, protože Pytnon neznám tak detailně abych mohl srovnávat a navíc zrovna Pytnon velké překážky neklade.
Snad jen toto:

*funkce='_zpracuj'.$klic;
$vysledek=funkce($parametr);

Vysvětlení: Chci volat jednu z deklarovaných funkcí ale její název musím ze znalosti vstupních dat teprve poskládat. Odkaz tedy použít nemohu, funkci eval pro vyhodnocování za běhu použít nechci a nepřímý odkaz je zakázán jako riskantní.

V Pythonu napriklad muzu napsat

funkce = locals('nazev')

Oprava:

funkce = locals()['nazev']

No, já se bez mučení přiznám, že Perl mi k srdci nepřirostl, ale zajímalo mě (jako mě to zajímá u ostatních jazyků), co jeho fanoušci vypíchnou jako hlavní výhody. Kromě CPANu, samozřejmě. ;-)

Moj zoznam vyhod:

• mod_perl2
• vela kvalitnych a stabilnych CPAN modulov
• dostupnost na kazdom UNIX-like systeme
• dobra podpora regularnych vyrazov
• podpora unicode
• rychlost
• mne viac-menej vyhovujuca syntax
• programovat v Perle je zabava
• lamy v Perle nekoduju

Nevyhody:

• objektove programovanie je hack (funkcny ale stale hack)
• obmedzena moznost explicitnej typovej kontroly
• primitivny GC

Vsetky nevyhody su opravene v Perl6 - ale ked ten bude hotovy a pouzitelny, tak ja uz budem v dochodkovom veku ;)

Z hlediska programátora zaměstnance přidám ještě jednu nevýhodu - rozšíření. V nabídkách práce se Perl příliš často nevyskytuje. Ve svém okolí (Brno) znám jedinou firmu, kde Perl používají jako hlavní jazyk pro vývoj aplikací a v té pracuju.

Tuto nevýhodu ovšem Perl sdílí s většinou jazyků jmenovaných na této stránce - nevzpomínám si, kdy jsem naposledy četl inzerát hledající programátora v Lispu.

No, programátora v Pythonu hledá Centrum na Rootu (přes jobs.cz) už nějakou dobu. A inzerát na perlistu jsem už taky párkrát viděl. Dokonce někde nedávno hledali i odborníky na Ocaml/F#. Ne každému se samozřejmě poštěstí dělat v jazyce, který se mu líbí nejvíc a pravý profík používá pravý nástroj na pravém místě, ne? Perlista/pythonista/rubista/etc.ista pravděpodobně má i zkušenosti s C/C++/C#/Javou atd. O groovistech nemluvě. ;-)

A ne kazdemu se chce delat v Seznamu. ;-)

Job inzerat na OCaml/F# v Cechach alebo na Slovensku? To by ma zaujimalo. Viem, ze Xen Source hlada OCaml koderov - ale rozhodne nie u nas.

Ne, tohle byla, myslím, konkrétně nějaká firma v Budapešti a zabývají se nějakými finančními systémy.

"Schopný mladý muž místo nehledá, ale vytváří." :-) (Nebo tak nějak to v těch Básnících bylo? ;-))

Musim sa tiez priklonit k opacnym nazorom. Moja osobna skusenost je, ze Perl je vyborny jazyk na spracovanie textov. Nie je problem pisat v nom zrozumitelny kod. Ked porovnam syntax tu prezentovaneho Groovyho s Perlom, tak ten Perl sa mi predsa len zda omnoho zrozumitelnejsi :-)

Vidim v moznosti volneho mixovani *.java *.groovy v jednom projektu/modulu. V Groovy proste pisete mnohem rychleji, v Jave zase je moznost napsat veci efektivneji. Vetsinou je potreba optimalizovat tak 10% kodu (= java), zbytek muze zustat v Groovy. Java, groovy cross compiler ktery bude od verze 1.1 a podpora pro mixovani v dobrem vyvojovem prostredi (prvni je podpora v IDEA 7.0) je mozna to, co vystreli Groovy daleko pred JRuby, JPython apod. Potencial je zde obrovsky.