Ahoj, potřebovala bych poradit, jak vytisknout tabulku malé a velké násobilky v přehledném tvaru...Program by měl být samozřejmě napsaný v Javě Děkuji všem alespoň za malou radu.

Ano, jeden z 15 příkladů se kterým si nevím rady :)

perl -e 'do{$a=$_;printf"%2dx%2d=%3d ",$a,$_,$a*$_ foreach 1..10;print"\n"}foreach 1..20'

lists:foreach(fun(A)->lists:foreach(fun(B)->io:format("~2Bx~2B=~3B",[A,B,A*B])end,lists:seq(1,10)),io:put_chars([10])end,lists:seq(1,20))

dc -e '[[ ]n]sa[d10>an]sb[d100>albx]sc[dlbx[x]nrdlbx[=]n*lcxlax]sd[1+dlfldxd10>e]se[lf1+sf0lex10anlf20>g]dsg0sfx'

asi nějak takhle

for (int i=1;i<11;i++)
for (int j=1;j<21;j++)
System.out.println(" "+i+" x "+j+" = "+j*j);

samozřejmě to celé musíš obklopit formálním objektem... ale to už jistě znáš...


2Hynek: to jako myslíš, že OOP je celkově zastaralé, nebo že Java ho má zastaralé? V obou případech by mě zajímalo, jak jsi k takovému názoru došel.

Java je celkove absurdni jazyk, ktery se prilis zameruje na delani veci co nejsloziteji jak je jen mozne. Zrovna ohledne OOP je puvodni i dnesni predstava nekde uplne jinde.

Primarni rozdil spocivam v tom, ze jake metody lze nad objektem volat by nemelo byt zavisle na dedicnosti. Melo by mozne byt volat prakticky cokoli a objekt (pripadne nejaka jina cast beziciho programu) se za behu rozhodne jak s timto volanim nalozi. Je doufam na prvni pohled zrejme, ze toto je v primem rozporu s predstavou Javy, ze pri kompilaci musi byt zrejme, jestli takova metoda vubec existuje a jake muze zpusobovat vyjimky.

Detaily, jako ze jave chybi nektere pro efektivni programovani zasadni datove typy, jako je treba funkce, coz se pak musi obchazet neuveritelne rozsahlymi a necitelnymi konstrukcemi snad radeji zanedbam.

A vas prispevek, kde doporucujete trivialni usek programu "obklopit formalnim objektem", at uz to znamena cokoliv, to krasne ukazuje. Smyslem OOP je program zprehlednit, ne aby byl "objektovy", opet, at uz to znamena cokoliv.

Díky za obsáhlou odpověď, pokusím se také reagovat...

Java není stavěná na prográmky výpisu malé, či velké násobilky a jasně se shodneme, že existuje bambilion jiných (nejlépe skriptovacích) jazyků, kde to napíšu na jednu řádku bez nějakejch formálností. Na druhou stranu si těžko nějaký z těchto skriptovacích jazyků vybere banka XY na postavení robustní business aplikace. To co u programu na pár řádků vypadá znepřehledňující, to může být u velkých projektů výhodou - třeba i to, že každý kousek kodu musí být objektem.

Datový typ funkce bez problémů naimplementuju pomocí vnitřní anonymní třídy - no jasně, je to ukecanější, ale myslím, že nejde o rozsáhlé a nečitelné konsrukce. Nejsem si jist, jestli zrovna to prosazujete - ale rozhodně bych v Javě nechtěl možnost volání metody nějakého objektu, aniž bych k tomuto objektu měl regulerní přístup.

Myšlenka volání čehokoliv, kdy až objekt rozhoduje, jak s tím naloží je pro mě zajímavá, nemám žádnou zkušenost s jazykem takovéhoto typu a neumím v tuhle chvíli přesně domyslet všechny možné výhody/nevýhody. Není pak problematičtější hledání chyb?

Ze si Javu vybere banka ci neco podobneho na psani jakesi aplikace nerika nic o kvalitach Javy daleko vice to rika o beznem pristupu "kdyz projevim inciativu a bude to pruser, tak me vyhodej, kdyz udelam to co vsichni ostatni a bude to pruser, tak se vlastne nic nestane". Pri pouziti logiky "pouzivaji to banky" by bylo asi nejlepsi programovat v COBOLu. Pokud chcete robustni aplikace, nehledejte je v informacnich systemech u kterych vrcholem nebezpeci je, ze vam nejaky urad ci komise da pokutu.

Myslenka, ze nositeli chovani jsou objekty jako takove a ne nejaka trojice (compile-time typ, run-time typ, podivna tabulka) je celkem bezna. Jako priklad se da uvest Objective C a Smalltalk a prakticky vsechny "skriptovaci jazyky" (at uz to znamena cokoliv).

Ponekud jiny a extremnejsi pristup k tomuto konceptu predstavuje Self a jeho moderni derivat ECMAScript (a podle uhlu pohledu napriklad take Python).

Hledani jiste tridy chyb jiste slozitejsi je, nicmene pokud je hledani chyb, ktere by mohl odhalit nejaky kompilator pro nejaky projekt vaznym problemem, hledal bych pricinu uplne jinde nez v jazyku ci kompilatoru.

Předělat kód ve stylu C

typ11 funkce1(typ12 promena11, ...) {
/* */
}

typ21 funkce2(typ22 promena21, ...) {
/* */
}

int main(int argc, char **argv) {
/* */
}

na naprosto stejně neobjektové javovské

public class A {
public static typ11 funkce1(typ12 promena11, ...) {
/* */
}

public static typ21 funkce2(typ22 promena21, ...) {
/* */
}

public static void main(String[] args) {
/* */
}
};

ani nedá moc práce. Ne, to opravdu není vopruz ani pro tu kalkulačku. Já takhle v Javě normálně píšu, pokud řeším něco, kde objekty jen překáží.

Vopruz je, že v Javě není goto, preprocesor a bezznaménkové typy. Tyto velmi užitečné konstrukce, které se ovšem v C někdy silně nadužívají (někdy z blbosti programátora, někdy z blbosti návrhu C) a do Javy se nedostaly mi hodně chybí.
<P>
To, že v Javě místo krumpáče někdy dostanete továrnu na vytváření krumpáčů podle jejich jména, není obvykle chyba jazyka, ale stylu programování.

Ohledne tovaren na krumpace a podobnych veci se da jenom rict, ze je to opravdu vec spatneho stylu, ovsem spatneho stylu, ktery se mnohdy snazi obejit nedostatky jazyka a navic je jeho autory silne vyzdvyhovan.

Pokud se da formalizovat seznam casto pouzivanych konstrukci v podobe 600 strankove knihy, mohly by se tyto konstrukce stejne snadno nejak pridat do jazyka (treba tim preprocesorem), ovsem autori Javy rekli "ne! vetsi program se da prodat draz.".

Vetsina veci napsanych v Jave jsou monstrozni aplikace, ktere nemaji temer zadnou zajimavou vlastni funkcnost, ale zato se daji libovolne rozsirit, aby delali cokoli jineho. Je jiste pravda, ze je to celym tim prumyslem, co se okolo programovani a popisovani programovani "velkych enterprise aplikaci v Jave". Zajimave je, ze cele je to postavene na rigoroznim prosazovani nejruznejsich po ceste posbiranych a dost casto naprosto protichudnych pravidel.

Já si myslím, že takové ty zrůdnosti typu aplikační server s vlastní mezivrstvou připojení k databázi, který s HelloWorld příkladem užírá jeden a půl giga paměti (místo 20 kB), jsou z 99% produktem špatného stylu programování a jen z 1% nedostatkem javy jako takové. To 1% je režie JRE, int[] místo unsigned short[], if (debug) místo #ifdef _DEBUG, zbytečné new atd. Těch 99% pak je styl. Pravda, styl protěžovaný a doporučovaný lidmi okolo javy.

S tim se da do znacne miry souhlasit. Ovsem jeden z problemu toho stylu je, ze prosazuje veci, na ktere Java neni stavena.

K tem nedostatkum Javy jako takove bych jenom podotknul, ze JRE je sice strasna prasarna, nicmene prekvapive rychla (a navic je pomerne daleko za spickou vyvoje virtualnich stroju, takze by mohla byt jeste rychlejsi). Tak moc prekvapive rychla, ze HotSpot je casto schopny vygenerovat efektivnejsi kod nez je z principu mozne u ahead-of-time kompilatoru jazyka jako je C++. A to z vetsi casti proto, ze vicemene ignoruje informace, ktere je mozne ziskat staticky a pouziva data posbirana za dobu behu programu. Jednim ze zajimavych paradoxu potom je, ze JRE by teoreticky umelo stejne rychle provozovat i daleko volnejsi jazyky nez je Java.

Zajimave je, ze javovy bytecode umi zasat mnohe pomerne pokrocile konstrukce, ktere v Jave nezapisete. Popravde receno, myslim si, ze kdyby toto vsechno slo v Jave vyjadrit mnohe veci z onoho diskutabilniho stylu programovani v Jave by odpadly (ne vsechny, treba tu funkci odkazujici na uzavirajici lexikalni promenne JVM neumi, a anonymni trida to tak podivne simuluje, popravde z hlavy nevim, jak to vlastne funguje).

Jako priklad bych uvedl to, ze znat typy a pocet argumentu metody je potreba jenom kvuli syntakticke kontrole a pretezovani (coz je samo o sobe diskutabilni vlastnost). Znat typ objektu, na kterem se metoda vola je potreba z vetsi casti jenom aby se vybral spravne optimalni op-code pro volani metody, u kterych se da predpokladat, ze je dnesni JVM stejne vsechny chape vicemene stejne (argumentem vsech je nazev metody jako vicemene string a do nejake efektivni reprezentace to preklada az JVM).

Cele bych to uzavrel tim, ze ano, jde hlavne o styl, ale ten styl vychazi z misty zbytecne (a me nepochopitelne) omezenosti jazyka. (ono je dost mozne, ze za syntaxi Javy a nekterymi omezenimi jsou jakesi pravni duvody, coz by to vysvetlovalo).

Začnu od konce. Jak jsem k takovému názoru došel? Vzděláváním, programováním a zkušeností. Byly doby kdy bych na OOP přísahal. Jenže jak jsem objevoval jiné přístupy, tak jsem zjistil, že není všechno tak jak se o OOP tvrdí. Takže například, všechno je objekt a manipulace s nimi se děje přes metody. Tak je to ve světě kolem přirozené a proto používání OOP je přirozené, přehledné, unifikované, blablabla ... Hmm, kam se kolem sebe kouknu, tak vidím spíše pasivní objety (datové struktury) a ty žádná přirozená madla (metody) nemají. Naproti tomu mám kromě pasivních objektů, objekty aktivní, ale ty mezi sebou zase nekomunikují, přes metody (gorilla *pull* lever, gorilla get banana), ale spíš si zasílají zprávy (*push* princip - posunky, řeč, dopisy, ...). Takže tomu co kolem sebe pozoruji spíše odpovídá Smalltalk, když už bych měl zůstat u OOP. Jenže mimo OOP existují i jiné přístupy, jako funkcionální, zásobníkové, deklarativní, ... Když jsem si například přečetl Ph.D. práci Joe Armstronga, tak jsem najednou zjistil, že přírodě bližší jsou nikoliv objekty s metodami, ale neživé objekty (datové struktury) a živé objekty (procesy).

No a pak se k tomu přidala praxe. Nejstručnější program zpravidla napíšeš v zásobníkové notaci (viz dc verze včetně printf implementace, nebo nejkratší implementace největšího společného dělitele dc -e '?[dSarLa%d0<a]dsax+p'). A každý řádek programu musíš udržovat, to je neúprosná pravda každého reálného projektu. Pravda, není to zrovna čitelné a ne každý to pochopí. Kromě toho tu máme také funkcionální programování. Nevím čím to je, ale funkcionální verze téhož algoritmu mi vyjde tak 10x menší a 10x čitelnější než to samé v OOP. Kromě toho rekurze. 90% práce běžného programování je odstraňování rekurze v zastaralých a nedokonalých programovacích jazycích (viz tvoje verze v Javě), přitom dnes to za mě může udělat stroj, když použiji pořádný funkcionální jazyk. No a největší sranda jsou deklarativní jazyky. Prostě zapíšu definici problému a program je téměř hotov. Nejlepší to asi bude někde uprostřed, mezi deklarativními a funkcionálními jazyky. Jako třeba Erlang s funkcionálním jádrem, nepřekonatelným pattern matchingem a jako třešnička na dortu procesy a zasílání zpráv.

No a zkušenost. Ta je u mě taková, že OOP "svádí" k naprosto nesmyslným "design patterns". Jeden z těch, který se mi vrací pořád stále znova a znova, najdeš ho v 9 z 10 učebnic OOP, kolegové k němu znova a znova sklouzávají, jsem nazval "krompáč, který se sám zaskladní na polici do skladu". V reálném světě, to vypadá tak, že aktor A, vyšle zprávu, že chce objekt B jinému aktoru C, ten ho vydá, aktor A s ním něco dělá a pak ho B zase vrátí zprávou aktoru C. Tedy, přijdu do skladu osobně, nebo si pro ten krompáč pošlu, skladník ho z police vyzvedne ... No a v OOP máme takovou vymoženost, ORM se to jmenuje a primitivní verzi toho se učí naprogramovat každý OOP začátečník. Scénář vypadá asi takto, zavolám na krompáč jménem a on se mi zhmotní v ruce, udělám s ním co potřebuji a on se ve změněné podobě objeví v polici ve skladu. Srandovní na tom je, že ve stejný okamžik totéž může udělat kdokoli jiný a má "pocit", že ho má jen pro sebe. A tím to nekončí, takový krompáč má na sobě navěšenou například celou fabriku, která ho vyrobila. Ne její jméno a adresu, ale šáhnu a mám celou fabriku k tomu krompáči přivěšenou. Nádhera, ne? Že to zní šíleně a není to pravda? Stačí se kouknout do každého druhého fakturačního programu se zákazníkem přivěšeným k hlavičce faktury, nebo hlavička faktury k řádku faktury. Vezmeš řádek faktury a hle, přivěšená hlavička, k ní přivěšený zákazník a toho zákazníka můžeš modifikovat. Celé se to nějak magicky persistuje kamsi. Úžasné dokud to nemá škálovat a dělat něco složitějšího, třeba volitelná hloubka toho řetězce a volitelné typy objektů na ní. V LinkedIn by mohli vyprávět :-) No a na to všechno se namlátí desítky a stovky tisíc řádek kódu, přičemž stejná funkcionalita (schválně nepíšu "to samé") jde realizovat na pár stovkách řádek Lispu/Scheme, Haskellu, Ocamlu nebo Erlangu.

Tak tolik asi k OOP.

No, je to jistě zajímavý pohled, který jste tu popsal, nicméně nejsem si jistý, jestli jde absurdností něčeho ve fyz.světě dokazovat absurdnost ve světě virtuálním. Možná, kdybychom měli tu moc dát krumpáči ve fyz.světě život v poslušnosti člověku, tak by se nám krumpáče zhmotňovaly v rukách, samostatně se množily a vůbec by nám to divné nepřišlo. Úspěch OOP plyne zřejmě z toho, že mnoha lidem přijde přirozené mít zákazníka přivěšeného k hlavičce faktury, fakturu aktivně reagující apod.
Ta funkcionalita na pár řádek např.ve funkcionálním jazyce je jistě pravda - ale nejsem si jist, jestli je stručnější vyjadřování tak důležité. Také jsem asi na měsíc podlehl Haskellu a až bude více času, tak se k němu zase vrátím - ale spíš jako k hobby. Neumím si tak přímočaře představit týmovou práci na jednom projektu+pozdější úpravy a přiohýbání programu k novým funkcím, jako si to umím představit u OOP jazyků. Připouštím ovšem, že je to možná mým navyklým OOP uvažováním.

Dokážete si představit projekt s dvěma miliony řádek ve funkcionálním jazyku? A výsledný produkt se spolehlivostí devět devítek? Dokážete si totéž představit v Javě? Tedy totéž s asi dvaceti milióny řádek :-) a spolehlivostí padajících hrušek. Takovou spolehlivost v Javě dosáhnout je prakticky nemožné už jen kvůli sdílenému paměťovému prostoru a referenčnímu aliasingu. V Javě jde programovat spolehlivě, ale za obrovskou cenu. V jiných jazycích je to mnohem snadnější, spolehlivější, čitelnější a udržovatelnější. Chce to jen si to zkusit. Další věc je garbage collector a podobně, které Java už z principu nedokáže dostatečně škálovat na více CPU. Tím více myslím stovky. A co distribuovatelnost, migrace běžícího kódu ze stroje na stroj, hot code swap a podobně nativně v jazyce a ne obezličkami typu, když uděláte tohle a nesmíte udělat tohle a používat tohle a když se pomodlíte ... Přečtěte si například white paper Erlagu, najedou se ocitnete na jiné planetě.

Ne, ne, OOP přístup vás do 21. století nedopraví. Už na to přišlo víc lidí, že funkcionální jazyky mají v této oblasti mnohem více předpokladů.

přiznávám, že nedokážu :-). Ale stejně... existuje někde statistika o poměru použitých jazyků v nově vznikajících projektech? Jestli ano, nic bych za to nedal, že ten poměr bude pro funkcionální jazyky dost propadákovej :/...

Je mi to líto, také obdivuju nové myšlenky (nebo staronové?;) ala funkcionální přístup, ale sehnat dneska práci se znalostí Erlangu, nebo Haskellu jde o dost hůř (jestli vůbec;), než se znalostí C++ nebo Javy:( Ve 21.století už jsme, takže jestli máte pravdu, tak bych to posunul spíš do 22.;)

BTW: co si myslíte o F#?

jo...překliknul jsem se tam - ale určitě to najdeš sama...

jinak doporučuju si projít serial Java na tomhle serveru

To je v pohodě, děkuji moc :-)