Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »
Malý testík vašeho oblíbeného programovacího jazyka zaměřený na jeho vysokoúrovňovost a míru abstrackce.
Lze zjišťovat a ošetřovat přetečení při počítání s celými čisly?
Jaká bude hodnota proměnné a v kódu odpovídajícím následujícímu:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
a = 0;
b = 1/3;
for (i=0; i<30000; i++)
a += b
Jaký je součet všech číslic ve faktoriálu čísla 5000?
Má automatickou správu paměti?
Lze při definování funkce pracovat s jejím neznámým výsledkem? (Pozn.: Nevím, jestli je tato otázka položena úplně správně, funkcionální programátoři snad pochopí její smyl. Není tím myšlena rekurze.)
Má multimetody?
Dokážete zpaměti výjmenovat všechna jeho klíčová slova?
Má jmenné prostory nebo jejich obdobu?
Má podporu regulárních výrazů?
Lze za běhu vyhodnotit kód v něm napsaný?
Lze skládat entity sdíleného chování a struktury z více nezávislých entit? (nějaká obdoba násobné dědičnosti)
Lze za běhu modifikovat entity definující sdílené chování a strukturu (typy, třídy apod.)?
Lze za běhu modifikovat příslušnost proměnné/objektu k entitě definující sdílené chování a strukturu?
Lze za běhu modifikovat strukturu proměnné/objektu nezávisle na její sdílené struktuře (např. přídání instanční proměnné jen pro jeden objekt)?
Má uzávěry?
Má skutečné nezávislé uzávěry?
Lze používat libovolné národní znaky v řetězcích?
Lze používat libovolné národní znaky v identifikátorech?
Podporuje výjimky?
Lze při zpracování výjimky vyhodnotit znovu celý ošetřovaný blok kódu?
Lze při zpracování výjimky pokračovat v provádění kódu s alternativní hodnotou chybného výrazu?
Máte přístup k zásobníku volání a možnost ho měnit?
Lze ze zásobníku volání získávat údaje, jako je jméno funkce, její parametry, jména a hodnoty proměnných? Jde tyto hodnoty upravovat?
Má podporu paralelních výpočtů?
Hodnocení:
0 a více bodů: Váš jazyk je nejlepší!
Další vhodné otázky směle uveďte v diskusi.
Tiskni
Sdílej:
irb(main):014:0> (1..5000).inject(1){|a,b| a*b}.to_s.split(//).inject(0){|a,b| a+b.to_i}
=> 67698
Asi bych si měl rozšířit knihovnu standardních helper metod. Jak by to bylo ve Smalltalku? Neříkej, že jsem ve Squeaku přehlédnul metodu, která k celému číslu vrátí pole jeho číslic.
5000 factorial asString inject: 0 into: [:sum :char | sum + char asString asInteger]
Collection>>inject:into: pro aString, už chápu. Hmm, Ruby by fakt v něčem potřebovalo trošku dotáhnout do konce, to je pravda.
Tak jsem vykouomal kratší verzi
(5000 factorial asString asByteArray - 48) sum
Taky mně totiž ex post napadlo rubí řešení v tomhle stylu. Tohle je taky úplně zbytečná pakárna, ale naprosto k sežrání:
(5000 factorial asString asByteArray - 48) asBag valuesAndCounts
Zatím mají řetězce v Ruby jen málo sémantiky vyšší, než jakou má pole bajtů, počínaje 1.9.1 by součástí řetězce měla být informace o kódování obsahu.
irb(main):004:0> 273016.to_s.each_byte{|x| puts x-48}
2
7
3
0
1
6
Prozatím to funguje a ještě nějakou dobu bude.
Bude nějaká? Je to moc fajn věc, ale to, na čem staví, už je dnes trošku zastaralé, zvláště po vší té internacionalizaci – nebo jsem to tak aspoň pochopil. Nechtělo se mi prozatím moc replikovat námahu, kterou pravděpodobně už podstoupil někdo jiný, kdo se v tom prostředí vyzná lépe.
Rád bych dělal v Seaside, ale přijde mi, že s backendy je to trošku tristní. Netušíš, v čem vlastně ukládá data Bryant v tom svém online vynálezu? Předpokládám, že do image se mu všichni ti lidé nevejdou.
Takže to se importuje do standardního 3.9kového image?
Přesně tak.
Avi dřív používal Goods, ale pokud vím, tak momentálně preferuje prostou image persistency. Ale asi mu taky přestává vyhovovat, protože se nedávno sháněl po někom, kdo by mu pomohl s implementací ImageSegmentů mimo hlavní image.
Zkus se podívat na Magmu, třeba ti bude vyhovovat.
Nicméně zkusím driver pro PostgreSQL: Mám v plánu jednu aplikaci, u které bych byl rád, aby její datový zdroj byl přístupný i odjinud (třeba přes ODBC). Jsem sice těžký firebirdista a nestydím se za to, ale pokud by ta webovka měla být v Seaside, musel bych si napsat driver a zrovna wire protokol Firebirdu není dvakrát srandovní 
, takže ovladač není a já si na to moc netroufám. Přeci jen myšlenka na neplacenou metapráci se mi moc nelíbí.
fact :: Integer -> Integer fact n = product [1..n] numc :: Integral a => a -> a numc 0 = 0 numc a = (a `mod` 10) + numc (a `div` 10) pak v interpretu: Main> ( numc . fact ) 5000 67698
$ python >>> reduce(lambda a,b: int(a)+int(b), str(reduce(lambda a,b: a*b, range(2, 5001)))) 67698
xrange místo range, ale v tomhle se to ztratí. Tady má perl co závidět v rychlosti.
BigInteger fact = BigInteger.ONE;
for(int k=1;k<=5000;k++)
fact = fact.multiply(BigInteger.valueOf(k));
int digitSum = 0;
BigInteger ten = BigInteger.valueOf(10);
while(!fact.equals(BigInteger.ZERO))
{
digitSum += fact.mod(ten).intValue();
fact = fact.divide(ten);
}
System.out.println(digitSum);
(foldl1 (+) . map (\s -> (read [s])::Int) . show . product) [1..5000]
(sum . map (\s -> (read [s])::Int) . show . product) [1..5000], samozřejmě :)
Perl ad1)
$ perl -le '$b=1/3; for($i=0; $i<30000; $i++) {$a +=$b} print $a;'
10000.0000000003
Až jsem byl sám překvapen. Jinak typově (netransparentně) a pomalu:
perl -mMath::BigRat -le '$b=new Math::BigRat "1/3"; for($i=0; $i<30000; $i++) {$a +=$b} print $a;'
10000
ad2)
perl -mMath::BigInt -le '$a=new Math::BigInt 1; for($i=2; $i<=5000; $i++) {$a *= $i}; $b=0; $b+=$_ for split "", $a; print $b'
67698Nesplněno, musí se otypovat.
ad3) Samozřejmě
ad4) Nerozumím otázce, alo co bych si pod tím představil, tak to určitě ne.
Dál je to celkem nuda, většinu z toho levou zadní.
Máte přístup k zásobníku volání a možnost ho měnit? Lze ze zásobníku volání získávat údaje, jako je jméno funkce, její parametry, jména a hodnoty proměnných? Jde tyto hodnoty upravovat?
Máte přístup k zásobníku volání a možnost ho měnit?Čtení ano, měnit ne. Jestli jsem teda dobře pochopil otázku, tak by se jednalo o změnu návratové adresy ze
sub. Dobrej joke, ale až to někdy budu potřebovat, tak si na to udělám nějakej modul
Lze ze zásobníku volání získávat údaje, jako je jméno funkce, její parametry, jména a hodnoty proměnných? Jde tyto hodnoty upravovat?Lze získat jméno funkce, a zjistit všechny globální proměnné a měnit je, modifikovat lexikální proměnné nejde a ani zjišťovat jejich jména.
Čtení ano, měnit ne. Jestli jsem teda dobře pochopil otázku, tak by se jednalo o změnu návratové adresy ze sub. Dobrej joke, ale až to někdy budu potřebovat, tak si na to udělám nějakej modul
Primárně bylo myšleno ho část stornovat, vyvolat návrat v dané hloubce s určenou hodnotou, serializovat ho apod., takže užitečné operace pro vytváření debuggeru, kontinuací apod.
Dokážete zpaměti výjmenovat všechna jeho klíčová slova?Nevím (to bych si musel otestovat), ale zpaměti vím, jak je zjistit:
python -c 'import keyword; print keyword.kwlist'To se taky počítá?
BTW: vcelku hezký test. Existuje jazyk, který dostane plný počet bodů?
„Existuje jazyk, který dostane plný počet bodů?“Tipuju, že se bude jmenovat Eintopf++ …
To se taky počítá?
Nejsem proti
Existuje jazyk, který dostane plný počet bodů
Asi libovolný přirozený
„Asi libovolný přirozenýPichi bude rád, že jeho Perl vyhrál.
A já budu rád za Englisc Spræc.
Test článek je moc hezký, ale zapomněl si položit základní otázku ve vesmíru, a to :
K čemu chceme ten jazyk používat a jaký problém chceme řešit.
Všechny ty body v článku jsou pak plus mínus nepodstatná omáčka.
To je ovšem otázka směřovaná na neomezenou aritmetiku, ne na faktoriál jako takový.
Ono taky třicet let existence se už dá za stabilitu docela považovat.
You want to hire a new programmer and you have the perfect candidate in mind, your old college roommate, Guillaume Portes. Unfortunately you can't just go out and offer him the job. That would get you in trouble with your corporate HR policies which require that you first create a job description, advertise the position, interview and rate candidates and choose the most qualified person. So much paperwork! But you really want Guillaume and only Guillaume.
So what can you do?
The solution is simple. Create a job description that is written specifically to your friend's background and skills. The more specific and longer you make the job description, the fewer candidates will be eligible. Ideally you would write a job description that no one else in the world except Guillaume could possibly match. Don't describe the job requirements. Describe the person you want. That's the trick.
So you end up with something like this:
* 5 years experience with Java, J2EE and web development, PHP, XSLT
Copak podle hodnocení váš jazkyk neskončil nejlepší?
Pro pořádek, můj favorit není Smalltalk, zde jsou jeho výsledky:
1) Smalltalku nepotřebuje, Java nelze, C# lze
2) test na přesnou aritmetiku se zlomky, ANO
3) test na neomezenou aritmetiku, ANO
4) přítomnost GC, ANO
5) NE
6) NE
7) test jednoduchosti. Jednoduších jazyků je celá řada
8) NE
9) ANO
10) částečně
11) ANO
12) NE
13) NE
14) "Programovací jazyk bez closures není programovací jazyk!" -- Ladicek. ANO
15) záleží na implementaci, Squeak ne
16) záleží na implementaci
17) záleží na implementaci
18) ANO
19) 20) pokročilé zpracování výjimek, ANO
21) 22) pokročilá reflexe, pro Smalltalk zásadní vlastnost
23) ANO, snadná automatická paralelizace ne
Ale následující otázka
„Je to jazyk, kde se věci zapisují přímo, a nebo je nutné ďábelské trikování a psaní přes ruku?“
mi přijde dost subjektivní. Pro mě třeba od objevu funkcí vyššího řádu přestal být přímým zápisem Cčkovký for cyklus – přesunul se pro mě do kategorie „psaní přes ruku“.
Co na to říct, snad jen citaci z textu:
Malý testík vašeho oblíbeného programovacího jazyka zaměřený na jeho vysokoúrovňovost a míru abstrackce.
Proto nic neříká o výběru jazyka.
Takže jako ošetření přetečení při počítání s celými čísly je vysokoúrovňost. Aha tak sorry. Já myslel, že high level jazyk mě s takovými věcmi otravovat nebude.
Nebude, ale pro hodně jazyků to samozřejmost není.
Stejně tak nechápu co používání libovolných národních znaků v identifikátorech má společného s vysokoúrovňovostí třeba.
Vypovídá to o obecnosti internacionalizace.
Abych tuhle lehkou konfrontaci trochu odlehčil, tak jsem pro vás vymyslel vtip, ve kterém byste se mohl najít
Smalltalk má velice úsporné běhové prostředí. Například na mém počítači nezabírá ani bajt místa.
Spousta dnešních "moderních" jazyků totiž má spoustu sofistikovaných featurek, ale jejich autoři jaksi zapomněli na to, že jednoduché věci by měly jít napsat jednoduše. A to je v životě často daleko důležitější než vícenásobná dědičnost či multimetody.
9.2.2007 15:53
cat /*dev/null; echo "Hello world"\!
cat <<c*/ /dev/null | cat > /dev/null
c */ () {} /*
c */ main()( cat(); printf("Hello world\n"); } /*
17 format( 'Happy New Year!')
write (6, 17)
stop
end
o Vadim Antonov, avg@hq.demos.su
*/
Akorát se mi zdá, že tam chybí #include <stdio.h>, ale ten by možná mohl být na začátku (podle toho, jak se Fortran staví ke znaku #)
cat, pak začne komentář, skončí na následujícím řádku a hned za ním je /dev/null. Přehlédl jsem něco? Pokud ano, tak i preprocesor od GCC
Zkusil jsem to předělat, takže to teď zbaští jak gcc, tak bash. Ale nevim, co na to Fortran. Není mezi přítomnými fortranista?
cat /*dev/null; echo "Hello, world"\!
cat <<c*/ /*dev/null | cat > /dev/null
c / () {} /*
c */ ;main(){ printf("Hello, world!\n"); } /*
17 format( 'Hello, world!')
write (6, 17)
stop
end
o Vadim Antonov, avg@hq.demos.su
*/
$ gcc -o hello hello.c
hello.c: In function 'main':
hello.c:1: warning: incompatible implicit declaration of built-in function 'printf'
$ ./hello
Hello world
$ sh hello.c
Hello world!
$ cat hello.c
cat /*dev/null; echo "Hello world"\!
cat <<c*/ /*dev/null | cat > /dev/null
c */ () {} /*
c */ main(){ cat(); printf("Hello world\n"); } /*
17 format( 'Happy New Year!')
write (6, 17)
stop
end
o Vadim Antonov, avg@hq.demos.su
*/
Teď ještě nějaký fortranista aby rozchodil tu fortranovou čáast.
cat /*dev/null; echo "Hello world"\!
cat <<c*/ /*dev/null | cat > /dev/null
c */ () {} /*
c */ main(){ cat(); printf("Hello world\n"); } /*
17 format('Happy New Year!')
write (6, 17)
stop
end
c Vadim Antonov, avg@hq.demos.su
*/
(loop for i = (fact 5000) then (truncate i 10)
for n = (mod i 10)
sum n
until(zerop i))
67698
nebo
(reduce #'+ (format nil "~D" (fact 5000))
:key (lambda (n) (- (char-code n) (char-code #\0))))
67698
(Common Lisp)
(reduce #'+ (format nil "~D" (fact 5000))
:key #'(lambda (n) (parse-integer (string n))))
Přijde mi to přenositelnější. Přinejmenším mám pocit, že podle CLHS ani kódování standardních znaků nemusí být nutně ASCII.
(position n "0123456789")
Takže máš asi pravdu. Jen si nejsem jist, jestli „the numeric characters as a group are not interleaved with alphabetic characters“ dává záruku, že nebudou promíchané s něčím jiným…i když to by asi byla velmi bizarní implementace.
1.0 nebo 1f odpovídající, pokud daný jazyk takhle zapisuje desetinná čísla?
A vzhledem ke dvěma otázkám na closures a tomu, že se closures vehementně derou do Javy 7 – může mi někdo vysvětlit, k čemu je to dobré? Zatím všechny příklady, které jsem viděl, se dají stejně dobře nahradit virtuální třídou s jednou metodou (v Javě nejspíš anonymní třída implementující interface). A obdoba closures v JavaScriptu, kdy stejný kód můžete volat i jako funkci i jako metodu mi připadá jako nejhorší věc na tomhle skriptovacím jazyku. Existuje tedy takové využití closures, které opravňuje zavedení nové konstrukce do jazyka?
Vypozoroval jsem, že že čím je nějaká konstukce jazyka v zápisu úspornější, tím víc se používá. Věř tomu nebo ne, ale spoustě lidí vadí že místo
(lambda (x) (* 2 x))nebo nedejbože
[:x | 2*x]musejí psát
new IUnaryOpFloatFloat {
float compute(float z) {
2*z
}
}
nebo jak že to musíte psát v Kafi. To asi bude důvod, proč „abstrakce“ přes třídu spoustu lidí štve.
Existuje taková hypotéza, kterou mají na svědomí pánové Sapir a Whorf. Ta říká, že myšlení člověka je ovlivňováno jazykem, kterým se vyjadřuje. (Orwell se toho taky pěkně chytil. ) Když to řeknu jinak, pokud budou lidé vyrůstat v prostředí omezeného jazyka, stanou se z nich…no, Orwellovi omezenci. Prostě je nikdy nenapadnou některé věci, které by člověka mluvícího jiným jazykem napadly třeba i přirozeně. V kontextu programování si třeba dost dobře nedokážu představit, že by javista dokázal vynalézt MapReduce. To musel v Googlu vymyslet nějaký lisper.
Představ si, že by se jiný Filip Jirsák, známý to programátor v BASICu , ptal, k čemu že jsou ty místní proměnné, pojmenované procedury (a dokonce i funkce), k čemu je rekurze a OOP. A že to nechápe. Určitě by ses ho zeptal, jak on bez toho může žít. Taky jsem před patnácti lety po BASICu objevil Pascal a taky jsem zprvu nechápal. No, ale dnes mi nezbývá, než se Tě zeptat: Jak jsi mohl dodnes přežít bez uzávěrů?
A žádné řeči o závorkách, nebo Tě s jednou přetáhnu po zadku! Je to zadarmo a lidem to stejně nevoní.
A kdyz si nekdo vybere Javu proto, ze si mysli, ze jeho zamestnanci jsou prasata... tak taky dobre mu tak, ale pro takoveho bych delat nechtela.
A vubec... proste v zasade souhlasim s timhle.
n! a spočítání součtu číslic. Když půjdete řádek po řádku a budete popisovat, co ten řádek dělá, dostanete zpět popis toho algoritmu v přirozeném jazyce. Produktivita práce myslím delším kódem nijak neutrpěla, protože ten kód je prostě přepsaný algoritmus, nebylo nad čím přemýšlet. Už jenom z toho, že se zde sešlo několik postupně vylepšovaných příkladů z jednoho skriptovacího jazyka je zřejmé, že ty konstrukce je nutné promýšlet, ověřovat si, jak se chovají které operace, zda to nebude mít nějaké vedlejší efekty…
Původně programovalo pár hackerů, kteří měli na to vymýšlet velice optimalizované programy. Dnes jsou ale daleko větší požadavky na velké množství kódu, ale opravdových hackerů je pořád stejně. Takže logicky vyvstane požadavek na programovací jazyk pro masy těch, kteří dokáží psát průměrný kód. A takovým jazykem je právě třeba Java. Samozřejmě je pak nutné, aby u každého projektu byl někdo, kdo rozpozná, které části v programu nemohou být napsány průměrným programátorem, ale které musí napsat hacker.
Takhle je to se vším. Většina lidí se třeba přepravuje osobními auty, přestože ta umí jenom jezdit z místa na místo. Ale pokud je potřeba nějaká speciální věc, použije se nákladní auto, traktor, jeřáb… A nikoho nenapadne do práce jezdit bagrem, přestože ten jej umí také přepravit z místa na místo, ale pro městský provoz je zkrátka nevhodný. A stejně tak nikoho nenapadne pokoušet se dělat výkop felicií.
Jsem docela rád, že průměrní programátoři píší weby a informační systémy v PHP a v Javě, a ovládací software jaderných elektráren, letadel nebo vlaků píšou hackeři. Pokud by všichni psali v asembleru a vývoj software pro jadernou elektrárnu by jednou připadl na hackera a podruhé na průměrného programátora, necítil bych se zrovna bezpečně.
Prasit se dá samozřejmě v libovolném programovacím jazyce, tomu nezabrání nic. Poměrně častý způsob prasení v Javě je, že v tom někdo píše jako by to bylo C nebo C++. Ale to zase už záleží na programátorském týmu – pokud na nějaký zprasený kód narazím, opravím ho a autorovi se pokusím vysvětlit, co udělal špatně a jak to příště udělat lépe.
(A to úplně pomíjím skutečnost, jak zásadní jsou z teoretického pohledu.) Ono s tím dodržováním štábní kultury…věř mi, že si blbec cestu najde. Kamarád dělal cosi v bance a povídal takové věci, že jsem se nestačil divit. Spíš mám pocit, že Java některým lidem umožní tou „vnější štábní kulturou“ ve skutečnosti jen zakrýt nulovou programátorskou kompetenci. Java umožňuje vyrovnat masy kodŕů do latě, nebo se tak aspoň tváří, ale z šedi prostředka se nikdy žádná historie moc nepsala. K pokrokům dochází na okrajích.
A ohledně ukecanosti…pokud existují tuny statistických důkazů, že počet chyb v SW na tisíc řádků je v podstatě nezávislý na jazyku, opravdu chceš psát co nejdelší programy? Aby v nich bylo co nejvích chyb? To mi nějak uniká…
A ohledně ukecanosti…pokud existují tuny statistických důkazů, že počet chyb v SW na tisíc řádků je v podstatě nezávislý na jazyku, opravdu chceš psát co nejdelší programy? Aby v nich bylo co nejvích chyb? To mi nějak uniká…To by pak stačilo chyby v programu opravovat tím, že by se odstranily konce řádků. Takže bych výrok o počtu řádků poupravil, že počet chyb v SW na tisíc programových instrukcí je v podstatě nezávislý na jazyku, čímž se ony úsporné zápisy na jeden řádek hned natáhnout, protože tam je instrukcí zpravidla několik. No a ne každá instrukce je stejně složitá, takže by se jim měla přidat ještě nějaká váha (instrukce přičti číslo je rozhodně jednodušší než instrukce pro každý prvek seznamu proveď následující kód) – čímž se dostaneme k závěru, že počet chyb na tisíc vážených instrukcí je vpodstatě nezávislý na jazyku. Já taky před pár lety napsal parser bez omáčky okolo na 7 řádků, ale když jsem to pak musel upravovat, došlo mi, že tudy cesta nevede.
do {
$REcount = ($text =~ s/\?\{([^}:]*)\}/&_nahraditGlobals($1)/ge);
$REcount += ($text =~ s/\?\{([^}:]*):([^{}]*(?:(?:\$|\*)\{[^{}]*(?:\*\{[^}]*\}[^{}]*)*[^{}]*\}[^{}]*)*[^{}]*)\}/&_nahraditGlobalsParametr($1,$2,$blok)/ge);
} while ($REcount > 0);
$text =~ s/\$\{([^}:\|]*)(?:\|[^\}]*)?\}/$lokalniPromenne{$1}/ge;
$text =~ s/\$\{([^}:\|]*):([^{}]*(?:\*\{[^}]*\}[^{}]*)*[^{}]*)(?:\|[^}]*)?\}/&_nahraditLokalniPromenne($1,$2)/ge;
$text =~ s/\*\{([^}:]*)(?:\|[^\}]*)?\}/_odkaz($1)/ge;
$text =~ s/\*\{([^}:]*):([^}]*)(?:\|[^\}]*)?\}/&_odkazSParametrem($1,$2)/ge;
return $text;
Java umožňuje vyrovnat masy kodŕů do latě, nebo se tak aspoň tváří, ale z šedi prostředka se nikdy žádná historie moc nepsala. K pokrokům dochází na okrajích.Souhlas, ale tu šeď prostředka také potřebujeme, nemůžeme mít pouze okraje. Ale samozřejmě je důležité rozpoznat, kde už průměr nestačí a je potřeba nějaké lepší řešení. Ono i při programování v Javě narazí programátor na problémy, nad kterými je nutné přemýšlet a nedokáže je správně napsat každý. Jenže pokud je někdo napíše špatně, nebere se to u Javy jako problém programátora, ale problém platformy. Třeba pokud má někdo utkvělou představu, že konstrukce objektu je atomická operace, a napíše celý článek o tom, jak se to chová špatně. A najde se spousta lidí, kteří mu na to skočí
Jestli jsi ho ještě neviděl, podívej se na tohle video poměrně detailně a velice hezky popisující IDE Smalltalku z přelomu sedmdesátých a osmdásátých let (napsané samozřejmě také ve Smalltalku).
Smalltalk totiž není jen jazyk, je to komplexní objektový systém včetně vývojových nástrojů a musí se brát jako celek. Nemusí používat složité statické analýzy kódu k tomu, aby měl efektivní IDE. Tam, kde Java musí používat složité berličky, Smalltalk nabízí jednoduchý uniformní přístup a absolutní otevřenost (i právě díky uzávěrům). http://www.squeak.org/
Ale také čím úspornější je nějaká konstrukce, tím více je write-only.S tím si dovoluji nesouhlasit. Důležité je, nakolik se v daném jazyce dá programovat přímočaře. Řekněme, že chci zjistit maximum posloupnosti čísel. To je operace, kterou většina z nás považuje za něco elementárního, nad čím není potřeba dál přemýšlet (když vymýšlím algoritmus, řeknu si "a teď z těch čísel najdu maximum" a hned je jasné, co to znamená). Takže dává velice dobrý smysl chtít po programovacím jazyku, aby v něm taková operace šla také přímočaře napsat. Tím "přímočaře" myslím, aby nebylo nutné psát několik řádků popisujících do posledního detailu, co se má přesně stát, nad kterýmiž řádky pak bude každý, kdo vám kouká přes rameno, několik sekund přemýšlet, než mu dojde, že to je opravdu nalezení maxima. A takový ukecaný jazyk rozhodně nezachrání, když bude mít na hledání minima kdovíjakou knihovní funkci, protože si ji sotva mezi tisícovkami funkcí budete pamatovat a ani ji okamžitě nepozná čtenář. Jistě, můžete namítnout, že existují nástroje, které Vám pomohou funkci najít nebo když ji vidíte, vysvětlit, co znamená, ale to jsou pouze berličky snažící se problém zmírnit. Mnohem lepší je jazyk, který má dostatečně silný repertoár základních operací, na jednu stranu tak malý, že si jej každý může pamatovat, na druhou stranu tak bohatý, aby pomocí něj vše, co si představujeme jako snadné, šlo také snadno napsat. Tomu je Java na hony vzdálena, blíží se spíš Haskell a některé další, obvykle také funkcionální jazyky. V takovém jazyku lze pak psát daleko přehledněji, už proto, že nad tím, co se vejde na obrazovku, se daleko snáz přemýšlí. A (pokud zrovna neprogramujete něco strašlivě rozsáhlého) sotva budete potřebovat statický analyzátor sofistikovanější než grep
max() a může se rozhodnout, zda chce vidět i detaily implementace, nebo se spokojí s tím, že to bude chápat jako elementární operaci.
Programátor si nemusí knihovní funkci pamatovat, stačí, když ví, že nějaká taková knihovní funkce existuje, nebo dokonce mu stačí podle struktury knihoven tušit, že taková funkce by mohla existovat. Pak má dokumentaci, která není žádnou berličkou, ale zásadní součástí vývoje softwaru. Navíc dokumentace je potřeba úplně stejně, pokud by ten prvek byl elementární součástí jazyka. Programovat bez dokumentace lze pouze v případě, že znám detailně implementaci – a to pak už není nic přímočarého, protože už nemám žádnou operaci maximum posloupnosti čísel, ale musím vědět, jak je tato operace implementována.
Otázka je, co počítáte do repertoáru základních operací, standardní knihovny Javy do něj podle mne patří, a to je repertoár velmi bohatý. Požadavek na to, aby si repertoár základních operací mohl každý pamatovat neberu, moc operací si pamatovat nechci, ale nevidím jediný důvod, proč všechno co si nepamatuju, mám implementovat znova – daleko lepší je, pokud si umím najít již hotovou spolehlivou a ověřenou implementaci.
S tím, že popis nějaké operace by se měl vejít na jednu obrazovku souhlasím, v Javě s tím nemám problém. Programovat s grepem je sice hezké, ale efektivita vůbec nejde srovnávat s tím, pokud máte plnou podporu vývojového prostředí, které neustále analyzuje kód, vypisuje varování, nabízí možnosti a umožňuje procházet kódem dle jeho struktury.
Myslím, že elementárních operací stačí desítky.Pokud maximum ze seznamu patří k takovým operacím, budou těch operací přinejmenším stovky, ne-li tisíce. Software nejsou jen vědecké výpočty nebo automatizace a řízení. Software je třeba také to, co stojí v pozadí „informační společnosti“ – tedy nejrůznější informační systémy. A tam jsou vám elementární operace typu maximum ze seznamu hodnot k ničemu, protože se tam žádné takové operace neprovádějí. To samé s jinými operacemi nad seznamem, než je vkládání a odebírání prvků, průchod seznamem a vyhledání prvku. I takovéhle systémy bankovní aplikace, vyhledávání jízdních řádů, informační kiosek, podnikové účetnictví) ale musí někdo naprogramovat a je dobré, pokud k tomu má vhodné nástroje.
Kolik procent průměrných javistů si uvědomuje, jak hluboký vztah (když se to aspoň nepřesně pokusím přiblížit) je mezi deklarací (a přiřazením do) proměnné a voláním funkce?Vzhledem ke snaze prosadit nějaký zjednodušený zápis properties se tím možná budou muset i průměrní javisté začít zabývat.
Je prostě užitečnější mít nástroje, které (nejlépe ortogonálně) spolupracují, než mít kupu specializovaných funkcí. V tomhle ohledu Java připomíná Windows (+ software ze serveru typu slunecnice.cz, prostě kupa jednoúčelových nástrojů), zatímco inteligentnější jazyky (povětšinou ty funkcionální) připomínají Unix.Hezký způsob, jak dát najevo, že o Javě nevíte vůbec nic. Můžu pak věřit tomu, co píšete o Pythonu nebo Smalltalku, když je s klidem srovnáváte s něčím, o čem skoro nic nevíte?
Tohle je v příkrém konstrastu s nároky, které vidím kladené na uchazeče o prgání. Tohle by měl zvládnout středoškolák s trochou praxe a oni chtějí absolventy univerzitní CS… Chápu, že takhle je to levnější…nebo aspoň se to zdá být levnější. (Docela by mně zajímalo, jaké nákladové kalkulace měli v Orbitzu. A jaké měl Paul Graham.)
Ono se to nezdá levnější, ono je to jediná možná cesta. Hackerů není nazbyt a ti, kteří jsou, musí psát Linuxové jádro a podobné věci. Pohyby skladových zásob klidně může psát někdo jiný. A aby to nevyznělo negativně vůči těm, kteří jsou zde v diskuzi nazváni slepovači kódu – ono to třeba taky znamená kromě toho průměrného programování ještě aspoň trochu rozumět třeba tomu účetnictví, které ten člověk programuje (nebo lepí).
Nebo tak nějak to bylo.
Podobně jako se na stavbu paneláku používají o hodně jiné nástroje než když stavíte katedrálu, i na ty softwarové paneláky se často hodí spíš různá klikátka a pseudojazyky než ty, ve kterých se programuje doopravdy.
A i webovou aplikaci někdy stojí za to napsat pořádně, jestli nevěříte, přečtěte si Hackers and Painters od Paula Grahama.
Ovšem to složení není zrovna intuitivní, takže je nutné si ještě pamatovat, jak že se to má dělat.Neintuitivní přijde spíš jen lidem zkaženým imperativními jazyky
Těm, kdo aspoň pár hodin programovali v čemkoliv funkcionálním (což může znamenat třeba i APL), takové konstrukce obvykle přicházejí naprosto přímočaré.
„Pokud maximum ze seznamu patří k takovým operacím, budou těch operací přinejmenším stovky, ne-li tisíce. … A tam jsou vám elementární operace typu maximum ze seznamu hodnot k ničemu, protože se tam žádné takové operace neprovádějí.“No právě, proto to píšu. A přesto Java v java.utils.Collections takovou operaci má.
A tisíce dalších podobných de facto specializovaných věcí.
„Hezký způsob, jak dát najevo, že o Javě nevíte vůbec nic. Můžu pak věřit tomu, co píšete o Pythonu nebo Smalltalku, když je s klidem srovnáváte s něčím, o čem skoro nic nevíte?“Dobře, co přesně nevím a přehlédl jsem? Funkcí vyššího řádu jsem tam moc nenašel, a když jo, bylo to hóódně přes ruku, hodně zamotané do rozhraní a nepoužitelné na malé věci typu „aplikuj „plus 1“ na všechny prvky“. A jak už jsem psal, nepohodlné konstrukce se nepoužívají, protože jsou nepohodlné, i když teoreticky jdou, a myšlení uživatelů pak zakrňuje. Upřímně, o Javu jsem ztratil zájem někdy kolem verze 1.0.8 nebo 1.1. Nadšení z appletů a „internetového Cčka s bajtkódem“ ve mně tehdy pominulo a pár inkrementálních vylepšení v 1.2 a dalších to už zachránit nedokázalo. Naštěstí se prgáním neživím a tak nemusím dělat něco, co musí většina kodérů z povolání a co by mi bylo nepříjemné.
Ano, ale v tom je právě ten vtip. Elementární operace jsou sčítání, odčítání, násobení a dělení, vytvoření objektu a volání metody, ošetření výjimek, podmíněné příkazy. Všechno ostatní jsou knihovní funkce, tady je programátore máš, stačí si vybrat. Není to jediný možný nebo správný přístup, ale je to legitimní přístup.„Pokud maximum ze seznamu patří k takovým operacím, budou těch operací přinejmenším stovky, ne-li tisíce. … A tam jsou vám elementární operace typu maximum ze seznamu hodnot k ničemu, protože se tam žádné takové operace neprovádějí.“No právě, proto to píšu. A přesto Java v java.utils.Collections takovou operaci má.
„Hezký způsob, jak dát najevo, že o Javě nevíte vůbec nic. Můžu pak věřit tomu, co píšete o Pythonu nebo Smalltalku, když je s klidem srovnáváte s něčím, o čem skoro nic nevíte?“
Dobře, co přesně nevím a přehlédl jsem? Funkcí vyššího řádu jsem tam moc nenašel, a když jo, bylo to hóódně přes ruku, hodně zamotané do rozhraní a nepoužitelné na malé věci typu „aplikuj „plus 1“ na všechny prvky“. A jak už jsem psal, nepohodlné konstrukce se nepoužívají, protože jsou nepohodlné, i když teoreticky jdou, a myšlení uživatelů pak zakrňuje. Upřímně, o Javu jsem ztratil zájem někdy kolem verze 1.0.8 nebo 1.1. Nadšení z appletů a „internetového Cčka s bajtkódem“ ve mně tehdy pominulo a pár inkrementálních vylepšení v 1.2 a dalších to už zachránit nedokázalo. Naštěstí se prgáním neživím a tak nemusím dělat něco, co musí většina kodérů z povolání a co by mi bylo nepříjemné.„aplikuj „plus 1“ na všechny prvky“ je ale už řečeno hodně „programátorsky“. V přirozeném jazyce člověk řekne spíš „všechny prvky zvětši o jedničku“. Pokud člověk zjistí, že počítač s „všechny prvky“ neumí pracovat, přeformuluje to na „každý prvek zvětši o jedničku“. A to už jde přímo přepsat – „každý prvek“ je for cyklus, „zvětši o jedničku“ je sčítání. Je to jednoduché, odpovídá to věcem, které známe z reálného světa. Ony kolekce „zamotané do rozhraní“ právě díky těm rozhraním umožňují pracovat s čímkoli – přesně v duchu Unixové koncepce se poskládají jednotlivé jednoduché díly. Java 1.4 je oproti 1.0 nebo 1.1 dost výrazný rozdíl, generiky, které skoro odstranily problém s netypovostí kolekcí jsou až v Javě 5. Zrovna kolekce jsou myslím silnou stránkou Javy, protože jsou to jednoduché stavební kameny, se kterými se toho ale dá hodně udělat. Šablony v C++ jsou sice určitě efektivnější, ale taky mnohem náročnější na pochopení – a už to není onen Unixový styl jednoduchých jednoúčelových nástrojů, ale spíš je to továrna na ty nástroje. Uzávěry nebo konstrukce, které s kolekcemi nebo mapami umožňují provádět třeba Python nebo Perl by samozřejmě taky byly hezké – ale jímá mne hrůza při představě, co by s tím páchali programátoři, kteří skládají Stringy po částech a to tak, že to kompilátor nemůže optimalizovat, kteří klidně do konstruktoru objektu napíšou čtení a parsování XML souboru, kteří mají hrůzu z regulárních výrazů nebo když už je pochopí, používají je i tam, kde můžou použít indexovaný přístup k pár znakům… Ano, nepíšu tady o programátorské elitě ale o lidech, kteří píší programy proto, že jinak si ten počítač nenechá vysvětlit, co má dělat. Vím, že to znamená, že je spousta neefektivních programů, spousta programů, které se občas náhodně hroutí, protože programátor poslepoval nějaký kód aniž by mu bylo zcela jasné, jak funguje. Ale to je holt daň za to, že máme těch programůlačných počítačů všude tolik.
Elementární operace jsou sčítání, odčítání, násobení a dělení, vytvoření objektu a volání metody, ošetření výjimek, podmíněné příkazy.To je silně subjektivní. Třeba objekty jsou pro mně už odvozená konstrukce, zatímco kompozice funkcí nebo iterace funkce přes seznam daleko základnější.
V přirozeném jazyce člověk řekne spíš „všechny prvky zvětši o jedničku“. Pokud člověk zjistí, že počítač s „všechny prvky“ neumí pracovat, přeformuluje to na „každý prvek zvětši o jedničku“.Jenže tady jde právě o to, že s "všechny prvky" počítač umí pracovat bez problémů, jen Java jaksi ne
Všimněte si, že "aplikuj funkci +1 na všechny prvky seznamu" je tomu přirozenému jazyku daleko blíž než nějaký for-cyklus.
(mapcar #'1+ seznam)
On for cyklus vlastně nedokáže říct „aplikuj funkci na všechny prvky“. On dokáže říct jen: „Přiřaď do proměnné počáteční hodnotu. Pak proveď nějaký kus kódu. Ten kód může provést s tou proměnnou cokoliv, přesto ji pak aktualizuj ještě podle výrazu. Pak proveď test dalším výrazem, jestli to smíš celé zopakovat znovu.“ V první řadě to není jediná věta ani akce, z pohledu jazyka. A navíc, těžký low-level – prostě kapotovaný assembler. Není divu, že se pak dodatečně vývojáři Intelu a GCC moří s psaním autovektorizéru aspoň pro základní příkazy, aby aspoň nějak ty SSE instrukce šly využít z jazyka, aniž by člověk musel zabředávat do assembleru. Otázka je, co tohle v Javě (nebo jakémkoli jazyku, co si dělá nároky na označení „vyšší jazyk“) dělá? (Já vím, když jsem v druhé polovině 80. let začínal programovat, znamenalo „vyšší jazyk“ totéž, co „strojově nezávislý“, takže v podstatě i Cčko – stačí jen dbát na velikosti datových typů.)
Otázka je, co tohle v Javě (nebo jakémkoli jazyku, co si dělá nároky na označení „vyšší jazyk“) dělá?Není to náhodou důsledek faktu, že byla vyvíjená pro embeded zařízení? Ze stejného soudku bude i trojice int, Integer a BigInteger, což by vysokoúrovňový jazyk vůbec neměl mít (ovšem daleko víc nechápu, proč je to v C#. Ono na těch vtipech, že na .NETu 1.0 vykonalo nejvíc práce oddělení pro přejmenování Javy, asi něco bude
).
assert seznam instanceof Iterable;
for (Prvek prvek: seznam) {
prvek.aplikujFunkci();
}
Jak píše Michal Vyskočil, původně byla Java myšlena i jako platforma třeba pro řízení mikrovlnné trouby, proto má i klasický Cčkový for cyklus. Ostatně mikročipy s podporou Javy se vyrábějí. Ale je pravda, že by bylo fajn, kdyby bylo možné kompilátor instruovat, aby u některých konstrukcí dával varování. Třeba takový autoboxing měl taky zakrýt pozůstatky po zaměření Javy na embeded zařízení (rozdíl mezi int a Integer), bohužel je z něj víc škody než užitku.
A přečíst, ne jen odfrknout. A to byl, prosím, rok 1979.
sablony su tazke na pochopenie? to moze povedat len samouk.
jímá mne hrůza při představě, co by s tím páchali programátořiprave ste vyjadrili zakladnu myslienku navrhu javy
) A je na tom snad něco špatného? Pro práci v Linuxu se taky všude doporučuje nepracovat neustále pod rootem, ale pod běžným uživatelem – aby toho člověk nemohl moc napáchat. A na roota se přepnu teprve v okamžiku, když potřebuju opravdu udělat něco s rootovskými právy. Vzhledem k tomu, že jazyků s rootovskými právy k počítači už zda bylo dost (assembler, C, C++), mohli se tvůrci Javy klidně soustředit na vývoj jazyka s uživatelskými právy – každý má možnost, pokud je to potřeba, přepnout třeba do C nebo C++. A o tom je celá tahle diskuze. Někdo tvrdíjímá mne hrůza při představě, co by s tím páchali programátořiprave ste vyjadrili zakladnu myslienku navrhu javy
root je ten nejlepší uživatel, který může všechno, nic jiného není potřeba. A já tvrdím, že je dobře, že roota máme, ale někdy se hodí mít i jiného uživatele, se kterým se nemusím tolik bát, že si špatným příkazem smažu celý harddisk. A stejně jako je nemálo těch uživatelů, kteří mají na počítači roota ale zároveň na něm běžně pracují pod jiným účtem, je jistě i nemálo těch programátorů v Javě, kteří, když je to potřeba, se mohou vydat i do „nebezpečných“ míst programování – ať už s Javou, nebo s nějakým jiným jazykem.
Ono, skor si myslim, ze java bola navrhnuta stylom "zoberieme C++ a vypustime, comu nerozumieme".
To nie je len overload-ovanie operatorov, to je aj viacnasobna dedicnost, abstraktne triedy (v jazyku javy: interface s implementovanou metodou). Sablony uz pochopili
to, comu vravite "programator v jave", tomu je lepsie vraviet (ako v tejto diskusii odznelo) "lepic kodu". Typicky americky styl, "nepouzivaj rozum, konzumuj". Ale netreba zufat, este tak 10-20 rokov studia a snad sa z javy stane objektovy jazyk pre programatorov, nielen pre managerov.
Hmm, a kde v tom case bude Larry, to si radsej ani netrufam predstavovat
Vase prirovnanie (praca pod rootom) pokrivkava, Tam kde C++ pouziva vyjadrenie "vstup sa nedoporucuje", java pouziva "vztup zakazany".Já když pod běžným uživatelem zkusím spustit
rm -rf /etc tak mi to nenapíše hlášku, že mi rm nedoporučuje to dělat, ale neumožní mi to udělat.
Ono, skor si myslim, ze java bola navrhnuta stylom "zoberieme C++ a vypustime, comu nerozumieme". To nie je len overload-ovanie operatorov, to je aj viacnasobna dedicnost, abstraktne triedy (v jazyku javy: interface s implementovanou metodou). Sablony uz pochopiliJestli potřebujete přetížené operátory nebo vícenásobnou dědičnost, nepoužívejte Javu. Javistům to evidentně nechybí. V čem se liší javovské abstraktní třídy od těch z C++?
Hmm, a kde v tom case bude Larry, to si radsej ani netrufam predstavovatDokáže jako program interpretovat už opravdu libovolný výstup z
/dev/random?
sablony su tazke na pochopenie? to moze povedat len samouk.Šablony jsou proklatě těžké na pochopení, pokud jimi zkusíte zapsat něco netriviálního (ostatně pochybuji, že kdyby byly snadné, potřebovala by norma C++ 70 stránek na jejich definici
). Často je to horší, než když na totéž použijete Céčkový preprocesor. (Obojí je mimochodem samo o sobě turingovsky úplné.)
Tohle mi zatim pripada, rekneme, jako dobry pokus jak zakryt, ze zadny neni...
...protoze si myslim, ze Kyosuke ma pravdu. (Prestoze jsem v Jave psala vic nez malicko naposledy pred nekolika lety a nejradsi bych na to zapomnela...)
Co se vývojového prostředí týče: jistě je to užitečná věc, ale pomůže vám hlavně v případě, že píšete desítky tisíc řádků nejrůznější otročiny.Pomůže to už pro případ, kdy projekt sestává z více než několika málo souborů. Třeba zorientovat se ve zdrojácích Samby a najít to správné místo pro úpravu je s grepem otázka třeba dvou tří hodin. Pokud bych používal pro C++ nějaké vývojové prostředí, byla by to otázka třeba dvaceti minut. A to je podstatný rozdíl. Dnešní programy nejsou myšlenkově složité, ale jsou rozsáhlé, musejí implementovat nejrůznější standardy atd. Kolik je třeba i v jádru Linuxu myšlenkově složitých částí, a kolik je všeho toho kódu, který zajišťuje modularitu, abstrakci, kompatibilitu, jednotlivé ovladače zařízení…
Pomůže to už pro případ, kdy projekt sestává z více než několika málo souborů.Proto jsem také radil grep a ne search v
${EDITOR}u.
Třeba zorientovat se ve zdrojácích Samby a najít to správné místo pro úpravu je s grepem otázka třeba dvou tří hodin. Pokud bych používal pro C++ nějaké vývojové prostředí, byla by to otázka třeba dvaceti minut. A to je podstatný rozdíl.Inu, proti gustu žádný dišputát. Ale proč mi přijde, že takřka v čemkoliv se mi to s grepem daří za řádově minuty?
Dnešní programy nejsou myšlenkově složité, ale jsou rozsáhlé, musejí implementovat nejrůznější standardy atd.To musí, samozřejmě, ale i tak je divné, když implementace standardu zabere řádově víc místa než standard sám
Docela se proslavil jeden citát Phila Greenspuna, takzvané Greenspunovo desáté pravidlo programování:
„Jakýkoli dostatečně složitý program v C nebo ve Fortranu obsahuje ad-hoc vytvořenou, formálně nespecifikovanou a chybami prolezlou polovinu Common Lispu.“To už patří skoro k folklóru.
Nedávno jsem ale objevil perličku, tzv. Seibelův důsledek Greenspunova pravidla:
„Jakýkoli dostatečně složitý program v Javě, který neobsahuje vlastní implementaci poloviny Common Lispu, ke svému vytvoření vyžaduje programovatelné IDE, které ji bude suplovat.“
Jedine, co vim, je to, ze kdyby to bylo v Jave, musela bych pri debugovani precist asi tak petkrat vic kodu a upadla by mi z toho hlava Nastesti muzu javovsky software prenechat svym trpelivejsim kolegum...
Jenom mi v objektovém programovacím jazyce připadá poněkud ujetý ten koncept, že v this může být cokoliv.
[K] čemu je to dobré? Zatím všechny příklady, které jsem viděl, se dají stejně dobře nahradit virtuální třídou [...] Existuje tedy takové využití closures, které opravňuje zavedení nové konstrukce do jazyka?A jsme u jádra pudla. V zásadě kterákoliv pokročilejší konstrukce se dá docela snadno nahradit těmi jednoduššími. Cokoliv naprogramujete v Javě, napíšete s daleko jednoduššími prostředky Céčka také. A cokoliv zvládnete v Céčku, půjde provést i na Turingově stroji. Jen to dá o trochu více práce a člověk se pak občas cítí jako příslovečný mořený osel. Takže closures nejsou nic převratného, jen je to další způsob, jak některé věci zapisovat elegantněji. Stejně jako objekty. Kdybych si měl vybrat mezi těmi dvěma, jistě zvítězí closures
(Mimochodem, když už jsme u objektů, ono se dá docela pěkně objektově programovat i v obyčejném Céčku (tak jsou například udělané některé kusy Linuxového jádra). Jak říkal Alan Cox: "Object orientation is in the mind, not in the compiler." Samozřejmě, objektová syntaxe vám někdy může ulehčit práci, ale jak už to bývá, někdy také ztížit, když váš jazyk má objekty slabší, než jaké potřebujete.)
Takže closures nejsou nic převratného, jen je to další způsob, jak některé věci zapisovat elegantněji. Stejně jako objekty. Kdybych si měl vybrat mezi těmi dvěma, jistě zvítězí closures
Closure je přece jen pouhá syntaktická zkratka pro zápis dvou objektů...