Jaký programovací jazyk zvolit?

7.1.2009 13:30 | Přečteno: 2414× | GNU/Linux | poslední úprava: 7.1.2009 13:33

Chtěl bych si rozšířit trochu znalosti a naučit se nějaký nový programovací jazyk. Ale jaký zvolit?

V poslední době mám hodně volného času.. Většinu dne jen tak sedím a brouzdám na netu a je úplný hřích nevyužít toho času k vyzkoušení (naučení) nějakého nového programovacího jazyka.

Zrovna když jsem odcházel od jedné firmy nastupovala tam éra .NETu, která se mi tedy tímto vyhla

Na vysoké se do nás pro změnu pokoušeli dostat Javu, která vzhledem k náročnosti na HW nepřipadá pravděpodobně v úvahu.

A zrovna teď jsem narazil na docela zajímavý multiplatformní jazyk "MONO," (otevřený .NET?) ke kterému ale marně hledám nějakou českou dokumentaci..

Zkrátka moje kritéria: Chtěl bych se naučit nějaký jazyk, který by se dal v součané době dobře využít při tvorbě on-line aplikací, stejně jako například pro nějakou desktopovou hříčku. Jinak vlastně nemám páru a do čeho mě navrtáte, to se pokusím nastudovat.

       

Anketa

Komentáře

[Václav "Darm" Novák]

Předpokládám že místo C/C# mělo být C/C++ :)

[Let_Me_Be]

S ohledem na kontext bych rekl ze myslel opravdu C/C# :)

[zde]

Doporučoval bych naučit se nějaký, který ještě neznáš :)

[repli]

Angličtinu ;)

(čekat u relativně nových projektů hned českou dokumentaci...)

[...............23]

+1

Bez znalosti angličtiny to proste nejde

[freshmouse]

 

(čekat u relativně nových projektů hned českou dokumentaci...)

Čekat u relativně nových projektů hned dokumentaci...

 

[Jakub Lucký]

Čekat dokumentaci...

[freshmouse]

Číst nebo dokonce studovat dokumentaci...

[anicka]

ocaml?

(Nemyslim to jako vtip. Pokud neznas nic podobneho, naucis se uvazovat novym zpusobem, a to je daleko lepsi nez ucit se dalsi jazyk podobajici se tem, ktere uz znas.)

[CiV]

Nebo ze stejného (funkcionálního) soudku můžes zkusit třeba Erlang. Ten je vhodný zvlášť na síťování (viz Ejabberd, atd)

 

[Miloslav Ponkrác]

Případně si vytvořit svůj vlastní programovací jazyk

[Bluebear]

Případně si vytvořit svůj vlastní programovací jazyk

Velmi poučné, ale také velmi zdlouhavé

[Ladicek]

Momentálně čtu knihy Programming Language Pragmatics a Virtual Machines a musím říct, že po těch asi šesti letech, co se zajímám o překladače, konečně dostávám odvahu nějaký programovací jazyk napsat

[deda.jabko]

tak virtual machines mne prisla docela slaba... od kazdeho neco a dohromady nic. pokud jsi ujety smerem k programovacim jazykum, tak urcite zajimave ctivo je anatomy of lisp

[Ladicek]

Díky za tip. Největší průšvih Virtual Machines je, že ukázky kódu obsahují strašně moc chyb z přehlédnutí, jinak mi to na úvod přijde docela dobré.

[deda.jabko]

chyby z prehlednuti jsem tam ani moc neresil... na te knizce me nastvalo, ze se docela vyrazne orientuje na javu... a ja jsem cekal, ze bude trochu vic obecnejsi... a taky me na nekolika mistech nastvalo to, ze kdyz jsem cekal, ze to konecne bude zajimave, tak tam bylo napsane neco ve smyslu: ,,pro nedostatek mista to preskocime''

[Ladicek]

Je dost krátká, aby to bylo něco víc než úvod. Já k ní tak přistupuju, takže mi to nevadí. Nepřítomnost pokročilejších témat je znát, stejně jako relativní stáří: v poslední době se dost rozmáhají registrové stroje (SquirrelFish, Dalvik), ale tady se mluví jenom o Parrotu. Určitě to není nejlepší kniha na dané téma, na Amazonu v diskusi k této zmiňují třeba tuhle, která vypadá podrobněji (ale zase tam jsou i témata, která mne nezajímají, třeba hardwarová virtualizace).

[deda.jabko]

poucne ano... ale zdlouhave ani ne... svuj prvni interpreter (,,sveho jazyka'') jsem napsal asi za dva dny. pak jsem ho nekolikrat prepsal... a po dvou letech prace natrhova konkurenci triko. (mimochodem ma to asi jenom 5000 radku v cecku)

[Deleted [8409]]

Tak ukažte

[deda.jabko]

,,ne, ted ne, az jindy...''

nechci vypadat jak tluchuba (jak nekteri mistni diskuteri)... ale pockejte si cca 3 mesice.

mame docela promysleny release plan... nejdriv se musim dokopat k tomu, abych muj krasny, rucne psany, makefile predelal na kombinaci autoconf/make/a-kdo-vi-co-jeste a taky cekame az o tom vyjde prvni clanek, ktery pujde citovat...

ale kdyz budete chvilku hledat, mozna tu nekde najdete odkaz na starsi verzi, vcetne skici evaluatoru...

[Deleted [8409]]

Mě osobně celkem zajímá JIT kompilace matematických výrazů. Už jsem i prostudoval nějaké zdrojáky z V8 a časem chci udělat malou knihovnu právě pro ty matematické výrazy.

Takže až to vydáte tak hoďte zápisek do blogu, rád se mrknu;)

PS: Zkuste cmake, mi tento nástroj funguje skvěle;)

[deda.jabko]

tak treba JIT nepouzivam, i kdyz po nem delsi dobu pokukuju... ja si hraju s jinyma aspektama nez je vykon, takze by mi to asi malinko pokazilo koncepci...

jako zajimavy start pro tu vasi knihovnu by mohl byt LLVM.

nejake poznamky, o tom jak to vypada uvnitr mojeho interpretru mam i na mistnim blogu... kazdopadne za tu dobu, se vyvoj pohnul trochu kupredu...

na cmake jsem se dival... a taky se mi moc nelibil. dela to za me az prilis moc veci... a vetsinou jinak, nez bych chtel...

[Josef Kufner]

Jo, jednou jsem takle omylem napsal interpret čehosi, co se, jak jsem o nemálo měsíců později zjistil, podobalo TCL.

[Daniel Kvasnička ml.]

Pro me to byla jedna z casti VS studia, kterou bych oznacil za opravdu obohacujici.

[M. Lox]

Další krásný (a poučný) jazyk je LISP, resp. Scheme. Ke Schemu navíc existuje výborný manuál, který si, pokud jsi to dosud neudělal, určitě přečti, i když hodláš programovat v čemkoliv jiném.

[Ladicek]

No, SICP není ani tak manuál ke Schemu, jako spíš učebnice programování Asi nejlepší co existuje, pravda.

[M. Lox]

Jistě, ale je to učebnice programování, která tě jako vedlejší efekt naučí Scheme.

[Ladicek]

To jo, ale manuál to není Tuhle jsem ji tak chtěl použít, tuším mi šlo o letrec*, a bylo to tam zmíněné jen letmo jako nějaké cvičení. A nejsem si jistý, jestli tam jsou třeba makra (možná v páté kapitole, tu jsem ještě nečetl ).

[M. Lox]

Já toho tedy zase tak moc nenaprogramuji, ale zatím jsem nenarazil na vlastnost Schemu, která by v SICP nebyla dostatečně popsaná. Asi to bude tím, že co není v SICP, o tom se nikdy nedozvím

[deda.jabko]

SICP tusim vubec neresi makra... a pritom je to takova uzasna featura se kterou scheme/lisp natrhne prdel kdejakemu obskurnimu ,,modernimu'' jazyku (vcetne toho bajecneho C++, Javy, Pythonu i C#)

navic si nejsu ani jisty, jestli se tam nekde do hloubky resi call/cc... takove goto na steroidech

[Miloslav Ponkrác]

Tak kdybyste měli tip na učebnici programování, při které jako vedlejší efekti pohádkově zbohatnu, dejte mi, prosím vědět! Finanční odměna pro funkční tip!

[M. Lox]

Taková neexistuje, protože je to právě naopak: kdokoliv si kdy přečte nějakou učebnici programování, nikdy nezbohatne. Podívejte se například na pana Gatese a na jeho programy

[Miloslav Ponkrác]

A sakra! Proč mi o téhle chybě neřekl nikdo dřív!

[Jirka]

Ještě horší je to u těch, kteří napíšou knihu o programování. Tam je to beznadějné ...

[Miloslav Ponkrác]

uáááááááááááá!

[M. Lox]

A co teprve ti, co tu knihu nejen napíšou, ale ještě si ji po sobě přečtou!

[Josef Kufner]

Nebo třeba Haskell. Rozhodně je dobré si funkcionální jazyky aspoň oťukat.

[Ilfirin]

Mono není jazyk. Pro něj bys hlas tedy dostat neměl žádný. Jazyky jsou www.mono-project.com/Languages.

[Ilfirin]

Nicméně, ač jsem Pythonista, tak teď nejvíce frčí jazyk C# (.net/mono) se mi zdá.

[Andrei Badea]

Ne tak podle TIOBE.

[mikezt]

Assembler. Ten sa hodí vždy.

[Algi]

Online aplikaci v assembleru jsem ještě neviděl. Mohl bys prosím zaslat ukázku?

[Miloslav Ponkrác]

A proč myslíte, že by to nešlo?

[Daniel Kvasnička ml.]

A z ceho usuzujete, ze si to mysli?

[Algi]

Přesně tak. Neříkám, že by to nešlo. Jenom, že je to poměrně nezvyklé a že jsem žádnou takovovou neviděl. Buď si dělá původní autor komentáře legraci (což asi), nebo nějakou takovou viděl/naprogramoval. A potom bych se rád na ní podíval...

Pro mě by osobně bylo mnohem větší blaho, kdybych mohl dělat webové aplikace v Objective-C (ideálně 2.0)... A mít tak ještě grafický návrhář pro web podobný Interface Builderu. Omlouvám se, to už příliš sním

[Miloslav Ponkrác]

Je to nezvyklé, ale i takové aplikace existují. Jsou mimochodem někdy v jednočipových mikroprocesorech, kde je vyžadován nějaký webový výstup. Programování v asm pak umožňuje použít levnějšího švába.

Ale jinak – pokud byste se pohyboval v asm kruzích, zjistil byste co vše se v asm dělá.

A můj osobní názor je, aniž bych Objective C upíral jeho místo na slunci je, že jsem rád, že tento jazyk je v ústraní (pokud je člověk mimo Apple svět). Nemyslím si, že je to taková paráda. A dobré IDE se dá postavit nad jakýmkoli jazykem, to není ani tak věc jazyka samotného.

[Daniel Kvasnička ml.]

A mít tak ještě grafický návrhář pro web podobný Interface Builderu.

nib2cib: Use Interface Builder to design your Ajax apps

[franta]

ja spis jiz dlouhou dobu premyslim jake drogy brali ti jenz objective-c navrhli... nejspise budou velmi podobne tem jenz berou lidi jimz se objective-c libi

[Vin]

 

Proč vy židé vždycky odpovídáte na otázku otázkou?

A proč bychom měli odpovídat jinak?

 

[kralyk z abclinuxu]

To je imho širokej pojem. Spíš druh jazyka než jazyk jako takovej...

V rámci RCE jse si vyzkoušel různý druhy (x86 , ppc, psp(mips)...). Zvlášť ten psp byl pozoruhodnej - mips procesor psp má 32 základních registrů + dost dalších různejch systémovejch a VFPU registrů, sada instrukcí několikanásobně větší než na x86.
Assembler prostě může bejt hodně různorodej...

[alblaho]

Python (na desktop s PyGtk).

Ale je jedno, co se naučíš, třeba ten Ocaml (nebo Haskell), hlavně se do něčeho pusť. Python je dobrý v tom, že je hezký, elegantní, prakticky a reálně opravdu použitelný.

[Heron]

Na vysoké se do nás pro změnu pokoušeli dostat Javu, která vzhledem k náročnosti na HW nepřipadá pravděpodobně v úvahu.

Především tisíckrát napiš: "Nebudu šírit bludy o Javě!" a můžeš to rovnou naprogramovat jako cyklus. Třeba právě v té Javě, kterou tímto vřele doporučuji.

[freshmouse]

No, ono je potřeba tu Javu mít v kontextu...

Když člověk používá nějakou grafickou aplikaci v Javě, tak ta aplikace prostě je (bývá) "pomalejší" (a tím myslím "na první pohled viditelně") než srovnatelná aplikace třeba v C. Týká se to hlavně rychlosti náběhu aplikace a množství potřebné RAM. Na druhou stranu, Java (platforma Java) není jediná "pomalá" technologie -- např. .NET ji v tomto "skvěle" konkuruje. A když půjdeme ještě dále, tak ani technologie typu Python nejsou takovou výhrou...

Druhou věcí je, že někdy výhody platformy Java výrazně převáží nevýhody. To se týká třeba nějakých velmi speciálních grafických aplikací (typicky určených do firemního prostředí), jejichž základním požadavkem je přenositelnost (např. mezi unixovými systémy a Microsoft Windows). Nebo to může být např. nějaká věc z oblasti JEE (avšak pozor, aby výsledný produkt nebyl kanónem na vrabčí mládě, což se v především případě JEE může velmi lehko stát).

Nejsou dobré a špatné technologie, ale jen dobře a špatně použité technologie...

Koneckonců: naučit se Javu znamená co? Naučit se syntaxi, podmínky a cykly? Otázka půl hodiny. Nicméně člověk toho v reálu bude potřebovat "trošku víc". Jen učení se Java API (a hlavně zorientování se v něm) je otázka minimálně týdnů. Např. vývoj nějaké větší webové aplikace v JEE podle mě není téměř nikdy věcí jednoho člověka, zejména kvůli tomu, že každý ovládá něco. Někdo třeba výstupní část, další hlavní logiku aplikace, další se stará o databáze. Nemluvě o analyticích, koordinátorech (v případě většího týmu) a dalších lidech...

A jinak, autor by si měl ujasnit co chce. Ani nevíme, jaké jazyky již ovládá (nebo do jaké míry). Dále, Mono není programovací jazyk. Česká dokumentace u svobodného SW? Haha, buďmě rádi aspoň za tu (velmi často mizernou) anglickou...

[Heron]

Týká se to hlavně rychlosti náběhu aplikace a množství potřebné RAM.

Mno, nedávno jsem se koukl k vůli něčemu na htop a vidím, že jeden můj prográmek (v javě) má po dvou dnech běhu zabraných 760MB v RAM (resp. to běhové prostředí). Tak jsem se koukl do jconsole a opravdu, heap byl hodně velký. Popřemýšlel jsem samozřejmně nad leakama apod., to by asi udělal každý. No klepl jsem na Perform GC a heap spadla na 2MB. Za dva dny totiž nedošlo ani k jednomu automatickému GC, prostě to nebylo potřeba (volné paměti bylo ještě 6GB). No takže jsem dal zkusmo max heap na 4MB. Program jede, GC to dělá často, ale žere to málo paměti - teď je otázkou, co je lepší. GC každou minutu, nebo 800MB v RAM, když jí ještě šestinásobně víc zbývá? Takže asi tak.

Bylo to napsáno již mnohokrát, java nežere moc paměti. Ale chová se k ní tak, jako linux k ram. Každému tázajícímu se na otázku proč linux žere 100% RAM odpovídá, že ji používá jako cache. JVM paměť používá pro běh programu. Daleko rychleji (než klasický malloc) pak přidělí pamět pro nové objekty a jejich vytváření je pak rychlé (než by bylo pokud se dělal malloc pro každý nový). Pochopitelně, pokud někdo chce, může si nastavit JVM tak, aby používalo nezbytné minimum paměti.

[Let_Me_Be]

No to je od nich hezke, ale ja bych moc radsi mel v pameti cache disku nez nejaky bordel od GC ktery uz nikdo nikdy nebude pouzivat.

[Filip Jirsák]

Do té doby, než bude pro JVM implementována křišťálová koule, aby mohla poznat, co vy chcete, máte možnost ovlivnit spotřebu paměti parametry při startu Java programu. Kolik dalších programů vám tohle umožňuje nastavit?

[Let_Me_Be]

Ja zadnou kristalovou kouli nepotrebuji kazdy normalni program pouziva prave tolik pameti kolik potrebuje. Pokud ne, je to regulerni chyba software, kterou je potreba opravit.

[Heron]

Amen.

Toto je klasické dilema rychlost vs. spotřeba paměť. Co je lepší? Uvolňovat každý kB zpět a pak o ms později si zase žádat drahým (na čas) mallocem od OS další paměť, nebo tu paměť prostě nevracet (navíc když systému ani nechybí) a mít tak možnost ji velmi rychle opět použít pro nový objekt?

[Let_Me_Be]

Oba pripady jsou samozrejme spatne. Tohle je znalost, kterou ma jedine a jedine tvurce programu. Zadny GC tohle nedokaze nijak odhadnout. Proto musi byt program naprogramovan tak aby fungoval rychle a nepotreboval na to 50x vic pameti nez realne vyuzije.

[Heron]

No takže ještě třetí otázka , je lepší to naprogramovat za víkend, nebo se stejnou funkčností za měsíc? Ano, program, kterém, u věnuješ 1 měsíc na optimalizace určitě pojede rychleji a s nižší spotřebou pamětí, ale je jen velmi málo programů, kde tohle skutečně potřebuješ a kde je někdo ochotný ti to zaplatit. Obvykle je fakt jedno, jestli ten program žere 140MB místo 100MB a je o 5% pomalejší (když se stejně 99.9% času čeká na uživatele).

[Miloslav Ponkrác]

Jak kdy. Ale někdy se sakra vyplatí ten měsíc, a je takových případů více. Pokud odmyslíte desktop (kde je stejně čím dál méně příležitostí vydělat), a přesunete se do spotřební elektroniky, do palubních počítačů, do embedded zařízení, různých krabiček, atd.. – může být optimalizace ve výsledku velmi zisková.

Všechno chce své. Ale nedělejte si iluze, C++ má ještě jednu výhodu – nikdy neuděláte tak spolehlivý program, jako je možné v C++. V C++ se dostanete a korektně ošetříte a dokonce můžete pokračovat bez problémů i tehdy, když dochází paměť. Pro Javu, C#, Python, Ruby, LISP, Scheme, atd.. – je to situace fatální a program se prostě složí, nejde to korektně ošetřit. Totéž je třeba s docházející pamětí na zásobníku. Program v C++ má daleko více věcí pod kontrolou.

Jinak rozdíl ve spotřebě paměti a ve výkonu je v reálně napsaných programech mezi Javou a C/C++ je mnohem větší, než 40% pro pamět a 5% pro rychlost. Tolik bych zase Javě nefandil.

Ale tím nepíšu nic proti Javě – pro řadu případů je to nejlepší volba. Všechno chce své.

[Let_Me_Be]

Jake optimalizace? Staci nebyt prase a naucit se programovat. A taky si treba ten program pred tim nez ho pustim do sveta alespon jednou spustit a zjistit jestli tech 500MB kterou si veme JVM neni zbytecne moc.

[Ladicek]

To jsou mi silná slova. Přitom jde jen o to, že JVM nevrací systému jednou naalokovanou paměť, takže se může stát, že pokud program ve špičce využije půl giga, ačkoliv mu normálně stačí desetina, proces programu bude vlastnit celý ten půlgigabajt. Který bude po většinu času ležet na swapu. Od čeho máme virtuální adresování paměti?

[Miloslav Ponkrác]

Pokud ovšem dá program možnost to odswapovat. On stačí jediný využitý bajt ve stránce a odswapovat nemožno. A dynamická alokace většinou rozesype data hodně nerovnoměrně, takže zase tak růžové to nebude. Takže se klidně může stát, že programu stačí desetina paměti, než alokuje, ale jako na potvoru zrovna všechny používané pointery míří skoro do všech stránek – takže swapování ničemu moc nepomůže (a není to tak častý případ, proto také dynamická alokace paměti hodně rozhoduje i o efektivitě).

[Ladicek]

To by se snad dalo řešit garbage collectorem, který všechny objekty sesype na jedno místo. Teď si nejsem jistý, jestli tohle javovský GC dělá, ale tuším jsem v logu nějaké slůvko compacting zahlédl.

[Miloslav Ponkrác]

Java se snaží GC nepouštět, a klidně Vám GC nepustí týden.

GC má totiž značné, přímo kruté nevýhody. První věc je, že zastaví celý program – funkčnost GC vyžaduje zastavený program, zastavené všechny thready a ještě všechny thready zaparkované v tzv. bezpečných bodech. Pro programy, které třeba každou setinu sekundy něco sledují a nesmí vypadnout, je puštění GC tragické, proto často GC zakazují úplně.

Druhá věc je, že řada činností GC se děje souběžně s během programu a nějakou aktivitu také vyžaduje, takže de facto snižuje výkon.

V zásadě je to jenom o tom, že každý algoritmus je možné zrychlit za cenu nehorázného plýtvání pamětí – a Java se dala přesně touhle cestou.

[deda.jabko]

a je to tu zas... GC se spousti podle toho kolik ma povolene pameti a jak jsou nastavene dalsi parametry.

funkčnost GC vyžaduje zastavený program,

uz jsem vam jednou rikal, ze to staci jenom na mark fazi (ktera navic muze bezet paralelne)

zastavené všechny thready a ještě všechny thready zaparkované v tzv. bezpečných bodech.

a to je problem? na soucasnych pocitacich (max. 2-4 jadra) stejne vetsina vlaken spi (protoze nemaji cpu na kterem by bezely) a zastavit je neni zase takovy problem.

Pro programy, které třeba každou setinu sekundy něco sledují a nesmí vypadnout, je puštění GC tragické, proto často GC zakazují úplně.

a tento nesmysl jste nasel zase kde? RT aplikace jsou velice specificke... a resi se jinak... muzete mi ukazat, kde se vypina GC, aby se dosahlo RT vlastnosti?!

Druhá věc je, že řada činností GC se děje souběžně s během programu a nějakou aktivitu také vyžaduje, takže de facto snižuje výkon.

dival jste se nekdy do vnitrnosti beznych alokatoru? to byste se divil, kolik se provede ,,zbytecneho'' kodu a tak snizuje vykon...

[Filip Jirsák]

Zapomněl jste ovšem dodat, že píšete o Sunovské Javě 1.3 někdy z roku 2000. Od té doby vyšly již verze 1.4, 5 a 6, které mají trošku jiné možnosti – inkrementální GC, paralelní GC nebo concurrent mark-sweep GC.

[Miloslav Ponkrác]

A přesto se občas musí zastavit vše, byť na daleko kratší dobu, než v 1.3.

[Ladicek]

Už tady na váš příspěvek bylo odpovězeno, ale neodpustím si vlastní pokus. Jsem totiž přesvědčen, že vaše argumenty nejsou tak úplně platné a minimálně ve druhém a třetím odstavci si i odporujete

Java se snaží GC nepouštět, a klidně Vám GC nepustí týden.

Ano, pokud neběží program, JVM se nesnaží pouštět ani GC

GC má totiž značné, přímo kruté nevýhody. První věc je, že zastaví celý program – funkčnost GC vyžaduje zastavený program, zastavené všechny thready a ještě všechny thready zaparkované v tzv. bezpečných bodech.

To jednoduše není pravda. Existuje řada (implementovaných!) algoritmů GC, které jsou schopné běžet současně s programem (a zastavení celého programu vyžadují pouze v přesně definovaných situacích, které zahrnují řádově jednotky procent doby, po kterou GC běží, tedy řádově nejvýš desítky milisekund) a u kterých dokonce lze nastavovat nejvyšší povolenou dobu pauzy, běhu GC a podobně. Pro soft realtime použití docela dobře akceptovatelné.

Pro programy, které třeba každou setinu sekundy něco sledují a nesmí vypadnout, je puštění GC tragické, proto často GC zakazují úplně.

Proto také realtime Java disponuje možnostmi ruční správy paměti. Ale víc o tom nevím, nezajímal jsem se o to. Kromě toho existují knihovny navržené právě pro realtime použití (Javolution třeba).

Druhá věc je, že řada činností GC se děje souběžně s během programu a nějakou aktivitu také vyžaduje, takže de facto snižuje výkon.

Což je přesně tvrzení, o kterém si myslím, že odporuje větě "zastaví celý program" Ano, paralelní GC běží v samostatném vlákně, takže teoreticky snižuje výkon tím, že na určitou dobu spustí jedno vlákno navíc. Prakticky bude mít na výkon vyšší vliv ta řada dalších procesů v systému, nemyslíte?

V zásadě je to jenom o tom, že každý algoritmus je možné zrychlit za cenu nehorázného plýtvání pamětí – a Java se dala přesně touhle cestou.

První věta je samozřejmě pravdivá, ale tou druhou částí si nejsem úplně jistý. Jo, Java má určitě významný overhead pokud jde o paměť, ale jestli je nehorázný? Netroufám si být tak jednoznačný. Java zvětšuje velikost heapu vždycky na dvojnásobek, což si myslím, že u běžných desktopových programů se neprojevuje nijak špatně (defaultní maximální velikost heapu je tuším 64 MB) a pro specializované věci (serverové aplikace) to nevadí.

Je zcela zřejmé, že v jazycích nižší úrovně je možné napsat paměťově i časově úspornější software. Ale nepovažuju za správnou argumentaci, že Java je v tomto horší o celé řády, dnešní situace tomu prostě neodpovídá.

[Miloslav Ponkrác]

To jednoduše není pravda. Existuje řada (implementovaných!) algoritmů GC, které jsou schopné běžet současně s programem (a zastavení celého programu vyžadují pouze v přesně definovaných situacích, které zahrnují řádově jednotky procent doby, po kterou GC běží, tedy řádově nejvýš desítky milisekund) a u kterých dokonce lze nastavovat nejvyšší povolenou dobu pauzy, běhu GC a podobně. Pro soft realtime použití docela dobře akceptovatelné.

Takže vlastně mi dáváte za pravdu, že je potřeba zastavit program. Já přeci nikde nepíšu, že je třeba celý algoritmus GC projet se zastaveným programem, dokonce se o tom i zmiňuji. Chce to pozorného čtenáře.

Což je přesně tvrzení, o kterém si myslím, že odporuje větě "zastaví celý program" Ano, paralelní GC běží v samostatném vlákně, takže teoreticky snižuje výkon tím, že na určitou dobu spustí jedno vlákno navíc. Prakticky bude mít na výkon vyšší vliv ta řada dalších procesů v systému, nemyslíte?

Nemyslím, protože automatické GC vyžaduje v určitých momentech, aby všechny thready kromě GC threadu stály. Tomu se nikdy nevyhnete.

Je zcela zřejmé, že v jazycích nižší úrovně je možné napsat paměťově i časově úspornější software. Ale nepovažuju za správnou argumentaci, že Java je v tomto horší o celé řády, dnešní situace tomu prostě neodpovídá.

Java je významně horší, daleko více, než o pár desítek procent. Znovu dodávám, že v řadě případů to může být nepodstatné, ale ve velké řadě případů to Javu může úplně odstavit.

[Ladicek]

Nemyslím, protože automatické GC vyžaduje v určitých momentech, aby všechny thready kromě GC threadu stály. Tomu se nikdy nevyhnete.

Jednoduchý dotaz do Googlu a vidím, že existuje minimálně jeden algoritmus, kterému stačí postupně zastavovat jednotlivá vlákna a nemusí všechna najednou. Je pravda, že v Javě zatím nic takového není, ale co není, může být.

Vliv zastavení programu na jeho výkon bych nepřeceňoval. Ostatně garbage collectory už jsou s námi padesát let a po celou dobu jsou předmětem intenzivního vývoje. Ale nějakou studii na tohle téma bych si přečetl. Můžete něco doporučit?

[Jirka]

Na druhou stranu. Už jste viděl programátora, který by se obtěžoval v C/C++ volat free()?

[Let_Me_Be]

Obcas bych rad potkal ty, kteri to nedelaji abych jim mohl udelat malou plastickou operaci tvare (moji pesti).

[Ivan]

No treba v C++ by se free nemelo volat nikdy. Dokonce i delete a new by se melo pouzivat co nejmene. Stejne tak by se v C++ nemely pouzivat ani pointery. V "modernim" C++, by se mely pouzivat tovarny, automaticke pointery a kontenery(ne pole) - ted jsem to hrozne zjednodusil. Kdyz v C++ nebudete pouzivat pointery, tak vas pragram nebude mit memory leaky a nebude segfaultovat. C++ je neco uplne jineho nez C-cko s tridama.

[Jirka]

Program by neměl segfaultovat ze zcela jiných důvodů, než nepoužívání pointerů. A pak, když si nemůžete "sáhnout" na cizí paměť, tak nikdy neucítíte tu sílu, která vám probíhá v žilách. (po dvou týdnech marného hledání chyby)

[Luk]

Kdo chce cítit sílu v žilách, ať programuje věci do kernelu. Tam je to teprve ta správná síla, když se dá sahat přímo do fyzické paměti a do paměti zařízení

[JS]

Tento problem ma pomerne jednoduche, ale zatim neimplementovane reseni. Stacilo by, kdyby operacni system dokazal aplikaci pozadat, aby se zmirnila ve spotrebe pameti (napr. udelala GC), protoze jemu samotnemu dochazi pamet. A aby ta aplikace teto zadosti mohla vyhovet a ponekud zmirnit. Soucasne OS jsou psany za predpokladu, ze aplikace nebudou navzajem spolupracovat co se tyka ziskavani zdroju. Tohle by umoznilo spolupraci a tedy daleko lepsi alokaci zdroju.

[Miloslav Ponkrác]

Operační systém vychází z předpokladu, že zdroje daleko lépe dokáže použít pro své účely. A obvykle má tento předpoklad pravdu. Ve spolupráci s administrátorem, který některé konstanty nastaví je to téměř dokonalé.

Bohužel śám operační systém řídí zdroje na základě pohledu do křišťálové koule (tedy určitých heuristicky nastavených algoritmů), a není s to přesně říci, jaká bude potřeba paměti příští milisekundu, ani jestli jiná aplikace uvolní 3 GB paměti, nebo naopak bude chtít alokovat.

Každá aplikace má možnost si zjistit, kolik z její části je odswapováno a kolik je ve fyzické paměti, kdyby už chtěla spolupracovat. Takže operační systém tuto informaci dává.

[JS]

S prvnimi dvema odstavci bych souhlasil.

S tim tretim ne. Operacni system tuto informaci nedava - korektne fungujici aplikace by nemela nejak pokoutne zjistovat, co operacni system dela s pameti, ale melo by na to existovat API, ktere by aplikaci umoznilo spolupracovat a volitelne se chovat slusne. Duvod, proc by to nemela zjistovat aplikace, kolik je na swapu a volne pameti je v tom, ze chovani aplikace by nemelo byt zavisle na tom, jake existuje okolni prostredi, podobne jako by nemelo byt zavisle na tom, kolik ma system CPU, jak ma rychly disk nebo kolik aplikaci prideli CPU. To uz by si pak kazda aplikace mohla implementovat vlastni OS.

Naopak, s tim API by to fungovalo opacne. System naznaci aplikaci, kolik by idealne mela spotrebovavat zdroju, a  ta se tomu bud prizpusobi (pobezi pomaleji nebo omezeneji), nebo neprizpusobi, a v takovem pripade OS zasahne tvrdeji a prislusne zdroje ji napriklad neposkytne. Aplikace totiz nemuze vedet, v jakem prostredi bezi, jaka je jeji priorita vzhledem k ostatnim aplikacim, takze nemuze sama od sebe (bez rady od OS) rozhodnout, kolik by mela optimalne spotrebovavat zdroju.

Ale toto je zatim hudba velmi vzdalene budoucnosti, tedy, ze by aplikace byly schopne menit sve algoritmy (v zasade, jak spravne rika Heron, existuje urcita volba mezi rychlosti a spotrebou pameti) a obecnou strategii, jak moc spotrebovavat ten ktery zdroj na zaklade hintu od operacniho systemu. Patrne bude pro takovou technologii treba vyvinout nove programovaci techniky (rozhodne si nemyslim, ze by napr. stacilo to, co umi Java nebo jiny jazyk s GC).

[Heron]

Jasně, takové API by existovat mohlo to je asi bez debat. Ale ani dnes nejsou aplikace zcela bezradné a funguje to tak jak píše p. Ponkrác. App. může zjišťovat, velikost volné paměti (a třeba JVM a všiml jsem si i vmware a vlastně i hodně dalších serverových app. toto dělá. V momentě, kdy je paměti dostatek je to takový nenažraný budulínek a ve chvíli, kdy dochází, tak pamět pro OS uvolní. U JVM je toto dobře pozorovatelné i v jconsole. I na grafech paměti to je vidět. V noci, když se spustí spousta zálohovacích skriptů jde spotřeba paměti nahoru, ale pak, až to všechno skončí, je volné paměti víc, než před začátkem zálohy. Přitom služby běží stále stejné.

Na druhou stranu mi není úplně jasné, jak bych jako programátor měl ošetřit hlášení od OS, že dochází paměť. Pominu-li, že to za mě řeší jvm, tak fakt nevím. Zahodit cache? No to ale situaci ještě zhorší, protože pak se prudce zvedne zátěž CPU nebo počet dotazu do DB (která si zase řekne o další paměť). Běžně naalokovanou paměť program vrací hned zpět, tady se ušetřit nedá (resp. to si řeší běhové prostředí) a pro datové struktury tu paměť zase potřebuje, zahození keší to ještě zhorší (no jak kdy). Takže toto řešení by bylo vlastně informace pro běhové prostředí (a programy, které si drží naalokovanou paměť pro nějaké budoucí použití), které mají naalokovanou paměť pro případ, že by ji app. někdy potřebovala. Ale v běžném programu se to tak stejně nedělá, takže zpravidla ani není co uvolňovat.

[JS]

No, ja si uvedomuji, ze popisovane "kooperativni" spravovani zdroju je radove slozitejsi problem, nez nekooperativni, ktere pouzivaji OS dnes.

To, ze se pusti GC, je jedna vec. Co by jinak zchroustlo GC je zcela zjevne nepotrebne. Ale OS by skrze to API mohl vynutit GC cyklus i drive nez uplne dojde pamet, coz by mohlo byt prave z hlediska zatizeni CPU vyhodnejsi (napriklad by v tom momente bylo mozne vytizit CPU vice nez pozdeji, kdy by bezela konkurencni aplikace, ktera by tu pamet zrala).

A navic, jde mi o trochu neco dalsiho, u mnoha datovych struktur to vubec neni cernobile, ze ta pamet je potreba nebo neni. Napr. aplikace by v reakci na tu zadost operacniho systemu mohla upravit svoji cachovaci politiku a zmensit buffery, vyprazdnit ty stare nepotrebne veci treba jen z poloviny. Takze to je na otazku, jak by na to programator mel asi zareagovat. A pak by treba OS zjistil - a sakra, DB ted potrebuje prilis mnoho CPU, a vyslal by pozadavek opacnym smerem - pokud muzete snizit spotrebu CPU na ukor spotreby pameti, udelejte to.

[Ivan]

Tohle fungje treba na AIXu. OS posle vsem aplikacim signal SIGDANGER a JVM spusti GC. Na linuxu se o tom uz nekolikrat diskutovalo, ale reseni se nikdo nedobral.

[Filip Jirsák]

V tom případě se má OS chovat jako každý jiný normální program a neplýtvat pamětí pro diskovou keš, když ji nepotřebuje. Pokud pro vás OS není normální program, pak vězte, že aplikace může kolikrát vědět daleko lépe než OS, jaká data potřebuje mít nakešovaná a která ne.

Vemte si jako příklad webový server. Některý klient podporuje kompresi přenášených souborů, jiný ne. Je několik možností – mít na disku soubory zkomprimované i nekomprimované, mít na disku soubor v jednom tvaru a podle požadavku ho případně za letu (de)komprimovat, kašlat na přenosové pásmo a posílat vše nekomprimovaně. Která varianta je podle vás správná? Podle mne ani jedna – podle mne je správné, pokud si server drží druhou variantu souboru v paměti, pokud je jí dost volné. Jenže to je podle vás chyba, kterou je třeba opravit.

[Let_Me_Be]

V tom případě se má OS chovat jako každý jiný normální program a neplýtvat pamětí pro diskovou keš, když ji nepotřebuje. Pokud pro vás OS není normální program, pak vězte, že aplikace může kolikrát vědět daleko lépe než OS, jaká data potřebuje mít nakešovaná a která ne

Mam takovy pocit ze absolutne netusite jak funguje strankovani, jinak si nedokazu vysvetlit tenhle blablol.

podle mne je správné, pokud si server drží druhou variantu souboru v paměti, pokud je jí dost volné. Jenže to je podle vás chyba, kterou je třeba opravit.

Ne, pak tu pamet samozrejme potrebuje ke sve cinnosti. Tady se bavime o necem uplne jinem. Bavime se o tom ze program, ktery potrebuje 2MB pameti (stabilne) bude mit po tydnu alokovany 1GB, protoze java proste neuzna za vhodne provest uvolneni pameti. Zcela trivialni memory leaking, ktery se ale maskuje jako GC.

[Filip Jirsák]

Mam takovy pocit ze absolutne netusite jak funguje strankovani, jinak si nedokazu vysvetlit tenhle blablol.

Ne, to vy považujete swap a kešování diskových bloků (kterému ještě chybné říkáte stránkování) za legitimní způsob využití paměti, ale jiné metody práce s pamětí, které mají třeba i stejný výsledek, považujete za jednoznačně chybné.

Když už jste zmínil to stránkování – pokud JVM tu nevyužitou paměť nuluje, může na některých platformách teď nebo v budoucnosti celá ta nepotřebná alokovaná paměť představovat jediný ukazatel na začátek „vynulované paměti“. To je opravdu tragické plýtvání prostředky.

Jistě, dá se vylepšovat JVM, aby dlouhodobě nepoužívanou paměť vracela, dá se vylepšovat OS, aby si uměl při nedostatku paměti říci programům, aby vrátily, co mohou postrádat. Ale taky každý, kdo provozuje jakoukoli aplikaci, která potřebuje nárazově řádově více paměti než „normálně“, umí nastavit parametry dostupné paměti RAM, swapu a limitů pro aplikaci (pokud to ta aplikace umožňuje, Sunovské JRE to umožňují), aby ta aplikace dobře fungovala. Pokud někdo provozují víc takovýchhle aplikací, jejichž špičky se navzájem nepřekrývají a mohou tak nějakou paměť sdílet, musí holt obětovat pár giga prostoru na disku pro swap. JVM původně nebyla pro takovýto druh provozu navržena, a asi je tak výjimečný, že se nevyplatí kvůli němu dělat nějaké optimalizace.

Ne, pak tu pamet samozrejme potrebuje ke sve cinnosti. Tady se bavime o necem uplne jinem. Bavime se o tom ze program, ktery potrebuje 2MB pameti (stabilne) bude mit po tydnu alokovany 1GB, protoze java proste neuzna za vhodne provest uvolneni pameti. Zcela trivialni memory leaking, ktery se ale maskuje jako GC.

Kdo rozhoduje, jakou paměť program potřebuje ke své činnosti? Memory leak znamená neuvolněnou paměť, kterou by programátor chtěl uvolnit, kdyby o ní věděl. JVM tu paměť ale evidentně uvolňovat nechce. Dělení na chce/nechce dává smysl, protože to lze jednoznačně rozhodnout, dělení na potřebuje/nepotřebuje je ošemetné, protože to často rozhodnout nejde (příkladů už tady zaznělo několik).

[Let_Me_Be]

Ne, to vy považujete swap a kešování diskových bloků (kterému ještě chybné říkáte stránkování) za legitimní způsob využití paměti, ale jiné metody práce s pamětí, které mají třeba i stejný výsledek, považujete za jednoznačně chybné.

Ja jsem rikal ze se v tom vubec nevyznate. Zjistete si co udela Linux kdyz dojde k vypadku stranky a pamet je plna vinou cache disku a co kdyz je plna diky JVM.

Ale taky každý, kdo provozuje jakoukoli aplikaci, která potřebuje nárazově řádově více paměti než „normálně“, umí nastavit parametry dostupné paměti RAM, swapu a limitů pro aplikaci (pokud to ta aplikace umožňuje, Sunovské JRE to umožňují), aby ta aplikace dobře fungovala.

Ja si muzu nastavit tak leda velky h.... Mam aplikaci, ktera si pri startu vyzere 500MB. Zmenit to nejde. Pustim podobnych aplikaci vic a mam po cele ramce a cely pocitac se vlece, protoze se mi vyswapovali dulezite veci na disk.

Kdo rozhoduje, jakou paměť program potřebuje ke své činnosti? Memory leak znamená neuvolněnou paměť, kterou by programátor chtěl uvolnit, kdyby o ní věděl. JVM tu paměť ale evidentně uvolňovat nechce. Dělení na chce/nechce dává smysl, protože to lze jednoznačně rozhodnout, dělení na potřebuje/nepotřebuje je ošemetné, protože to často rozhodnout nejde (příkladů už tady zaznělo několik).

Rozhoduje o tom programator a nemel by prenechavat toto rozhodnuti na GC a to jeste bez jakehokoliv nastaveni. Bohuzel presne takhle se chova bezny Java programator.

[Filip Jirsák]

Ja jsem rikal ze se v tom vubec nevyznate. Zjistete si co udela Linux kdyz dojde k vypadku stranky a pamet je plna vinou cache disku a co kdyz je plna diky JVM.

Když je paměť plná kvůli tomu, že ji má nějaký program alokovanou, zapíše se do swapu, čímž se to převede na předcházející případ (keš disku). Ovšem zapomněl jste napsat, kdy k takovému případu dojde. Jediný postup je následující: spustíte Java aplikaci, která provede nějakou činnost, na kterou je potřeba velké množství paměti (více jak polovinu dostupné RAM), ale aplikace běží dál a paměť již potřebovat nebude (zjistí se pohledem do křišťálové koule). Pak spustíte jinou aplikaci, která také potřebuje hodně paměti (také více jak polovinu dostupné RAM), takže systém musí sahnout do té paměti, kterou si předtím alokovala JVM, a její data jednou odswapovat na disk. Nevím, jak vám, ale mně ta hrozba odswapování nepoužívané paměti připadá jako rozumné riziko, když v drtivé většině případů lze předpokládat, že když aplikace jednou požadovala určité množství paměti, bude ji vyžadovat znova.

Ja si muzu nastavit tak leda velky h.... Mam aplikaci, ktera si pri startu vyzere 500MB. Zmenit to nejde. Pustim podobnych aplikaci vic a mam po cele ramce a cely pocitac se vlece, protoze se mi vyswapovali dulezite veci na disk.

V tom případě změňte operační systém za takový, který důležité věci nechává v paměti.

Rozhoduje o tom programator a nemel by prenechavat toto rozhodnuti na GC

V Javě o tom rozhoduje programátor -- pokud na nějaký objekt nevede reference, je to známka, že jej nechce používat, a GC tu paměť uvolní. Tolik k pohledu, kdy javovský program je onen "program" a JVM je správce paměti. Pak je zde druhý případ, kdy JVM je "program" a správce paměti je OS -- a v tomto případě programátoři JVM paměť evidentně uvolňovat nechtějí. Mimochodem, jak se chovají jiné virtuální stroje -- třeba VMware nebo VirtualBox? Vracejí hned všechnu paměť, kterou bezprostředně nepotřebuje jimi hostovaný program?

[Heron]

takže systém musí sahnout do té paměti, kterou si předtím alokovala JVM, a její data jednou odswapovat na disk.

Toto v praxi nenastane. JVM (co jsem vypozoroval) hlídá volnou systémovou paměť a pokud se mu zdá (opět křišťálová koule), že dochází, tak zavolá GC (kterému se jinak brání) a paměť uvolní. Takže pokud jsou v systému dva takové programy z tvého příkladu, tak k odswapování zpravidla nedojde, protože JVM paměť vrátí. Každopádně, jak správně píšeš, pokud k odswapování dojde, tak se odswapuje paměť, kterou jvm při nejbližším GC stejně prakticky celou zahodí, takže výkonností dopad tohoto swapu je pro ten program prakticky nulový.

Mimochodem, jak se chovají jiné virtuální stroje -- třeba VMware nebo VirtualBox? Vracejí hned všechnu paměť, kterou bezprostředně nepotřebuje jimi hostovaný program?

Jak který vmware. ESXi to řeší následovně: v běžném provozu přiděluje virtuálce tolik paměti, kolik reálně potřebuje a nic tedy nevrací. V případě, že se paměti nedostává, tak ESX zavolá vmware-tools ve vybraných virtuálkách (hádáním z karet ), tento vmware-tools si vemze tolik paměti, kolik mu OS dá (címž dojde k odswapování ostatních programů v rámci toho virtuálního OS) a ESXi pak tuto paměť použije jinde. Pro ten virtuální OS je to (vmware-tools) jen obyčejný program, který chce moc paměti, ale ESXi tuto paměť použije pro další virtuální stroje. Dělá to docela šikovně, pokud "nějak" (další křišťál), pozná, že ta odswapovaná virtuálka potřebuje paměť, tak to přes vmware-tools zase uvolní. vmware (i server) umí sdílet paměť mezi virtuálkama (nějak, to jsem moc nezkoumal), takže zpravidla je spotřeba paměti nižší, než je aritmetický součet paměti přidělené virtuálkám (v praxi tedy o hodně nižší, protože ne všechny stroje potřebují tolik paměti, kolik mají). Toto je velmi rychlé, nepředstavujte si spousty minut čekání na swap a tak podobně, v praxi v momentě, kdy dostanete sms od nagiosu o nedostatku paměti, tak po přihlášení už ji ten stroj má zase zpět. Uživatel, který si prohlíží web z toho stroje toto ani nepozná.

[Filip Jirsák]

Myslím, že spor je o tom, že JVM ani po GC paměť nevrátí zpět systému (nikdy jsem to nijak neověřoval, ale všichni tvrdí, že to tak je, a já jsem nikdy nezaznamenal nic, co by s tím tvrzením bylo v rozporu). Ale i tak se opravdu bavíme pouze o tom, že v případě potřeby volné paměti se ty stránky paměti, které GC uvolnil (ale nevrátil systému) musí zbytečně zapsat do swapu. Řešení je několik -- JVM uvolněnou paměť vrátí systému, a když ji příště bude znova potřebovat, znova o ni požádá. Nevýhodou je vyšší fragmentace paměti. Druhá možnost je dynamické sdílení paměti a nulování "nepoužívaných" stránek. V takovém případě nemusí JVM žádnou paměť vracet, jenom jí vynuluje -- jádro ji pak nebude muset (až bude dynamické sdílení implementováno) zapisovat na swap několikrát, ale zapíše se tam pouze poprvé. A podle mne je pak jen otázkou času, kdy se to sdílení paměti rozšíří o to, že vynulovaná stránka se ani na ten swap nezapíše.

[deda.jabko]

nic vezlem... ale klasicke alokatory se taky zrovna nehrnou vracet pamet zpatky operacnimu systemu.

[Miloslav Ponkrác]

Problém je, že operační systém běží na počítači jeden (virtualitu pomiňme), a proto je v pořádku, když se chová, jako by tam byl jeden.

Zato více programů, které se chovají jako operační systém a zabírají si podle toho paměť je už docela méně příjemné jednání. Mě obvykle na počítači, když pracuje běží několik desítek  programů.

Jinak take it easy, neberte to jako útok proti Javě, nic proti ní nemám, ale aplikace v Javě chtějí poněkud lepší hw. Pokud máte nadupané dělo, je to jedno, a ani mě by to žíly netrhalo nicméně Java prostě tuhle větší rozežranost má.

Java není špatný jazyk, má své výhody, které mohou převážit její nevýhody.

[Heron]

Zato více programů, které se chovají jako operační systém a zabírají si podle toho paměť je už docela méně příjemné jednání. Mě obvykle na počítači, když pracuje běží několik desítek programů.

Jasně, tak toto je dáno (původním) určením javy. Na server, pro dlouhodobý provoz. Obvykle na serveru běží jen jedna výkonná aplikace, takže ať si vezme co potřebuje.

Pokud máte nadupané dělo, je to jedno, a ani mě by to žíly netrhalo nicméně Java prostě tuhle větší rozežranost má.

Tak prográmky v javě mi běží i ve virtuálkách s 256MB RAM a omezeným procesorem a na ještě slabších fyzických strojích. Takže s tím nadupaným HW, bych byl opatrnější.

[Ladicek]

Jasně, tak toto je dáno (původním) určením javy. Na server, pro dlouhodobý provoz.

Lidi hrozně rychle zapomínají. Vyhledejte si The Java Language Environment: A White Paper, Sun Microsystems, May 1995, dozvíte se například, že Java is designed to support applications that will be deployed into heterogeneous networked environments.

Já osobě ty hádky o Javě nechápu. Java má jediný průšvih: Swing. Vzdor všem optimalizacím (a kdyby někdo řekl, že Swing kreslí GUI řádově stejně rychle jako ostatní toolkity, jsem tomu i ochoten věřit) je uživatelský zážitek s ním přímo otřesný. Vyšší nároky na paměť už snad dneska lze ve většině případů pominout. Nemáte někdo zkušenosti s QtJambi?

[houska]

760MB cache pro 2MB program?!

neprogramuju, ale tohle mi pripada jako hodne velka drzost ...

[Heron]

Jak jsem psal, to se dá nastavit. Je to drzost, není to drzost ... tak paměť tam prostě leží ladem, JVM si to vzít může, ničemu to nevadí, vlastně kromě čísla v htop to nic neznamená, když se tam paměť bude potřebovat, tak jvm spustí GC. Fakt v tom nevidím problém. Paměť není něco, co má být neustále volné. Paměť je prostě HW, který má být používán software a ne být v PC na okrasu.

[tom]

Vzdyt to je pravda, narocnost na hw je ale zase vyvazena narocnosti na programatora.

Neni problem navrhnout test (typu vyres nejaky problem), ktery v jave vyjde klidne i 1000x hure nez v C, ale opacne se vam to nepodari.

[Heron]

Neni problem navrhnout test (typu vyres nejaky problem), ktery v jave vyjde klidne i 1000x hure nez v C, ale opacne se vam to nepodari.

No to není. Ale dokazuje to jedině jen neznalost toho, kdo ten test takto udělá (a toho, kdo mu takový výsledek sežere). Java se nehodí na programy s dobou běhu v desítkách ms, protože než se nastartuje JVM, tak to má nativní program už dávno hotové. Ale při dlouhodobém běhu, kdy JIT má už zoptimalizované všechno co se volá, je ta rychlost zcela srovnatelná.

[Miloslav Ponkrác]

Bohužel není. Stále se ještě v Javě nic rychlostně kritického nepíše, a to ani když to běží dlouhodobě. A to proto, že rychlostně srovnatelná je tak maximálně v syntetických testech.

[tom]

Nechapu, jak jste prisel na to, ze pisi o testech trvajicich par vterin. Vzdyt jsem se o tom nikde nezminil!

Ja mel na mysli testy, kdy se program v C vejde o vrstu blize k procesoru v pametove hiearchii nez program v jave.

A zcela srovnatelna ta rychlost neni ani v pripade, kdy jsou programy stejne rozlezle po hierchii v pameti, pokud teda nemate v prekladaci C nastavenou jako cilovou architekturu 386.

[Chameleon]

Asi jsem se špatně vyjádřil. Ale tou náročností na HW jsem myslel stroj na kterém bych programoval (733 MHz, 386 MB RAM).

[Heron]

V C# (.Net Framework) (tehdy jsem Javu neznal), jsem programoval na horším (ale měl více paměti). A jelo to. Java taky pojede, není důvod proč by ne. Všechno jen záleží na tom, co chceš psát. Jestli ten program sám bude potřebovat 256MB, tak to moc dobře nepůjde v ničem.

[Jirka]

Ve starším zápisku rozjíždíš "hyper, mega, revoluční" katalog software, spoustu závazků a najednou píšeš, že máš fůru volného času a nemáš do čeho rýpnout?

Tož jak to s tebou vlastně je?

[Miloslav Ponkrác]

Nevychází tolik sw, aby mu to zabíralo tolik času. Zatím stačí úspěšně plnit databáze. Holt lidi málo programujou.

[Chameleon]

Vzhledem k výsledkům ankety se zdá, že takový projekt není potřeba. Proto aktuálně vložím čas do něčeho jinačího a projekt načasuji na "vhodnější" dobu.

 

[mirec]

Nechýba tam náhodou C++? Osobne by som rozhodoval medzi pythonom a C++ (teda vlastne v súčasnosti robím jednu aplikáciu ktorá je písaná v c++ ale pre pluginy využíva python, je to trochu divoké keďže nepoužívam boost ...).

[Rezza]

Neni spis lepsi zacit nejaky projekt, vybrat nejvhodnejsi prostredek na takovy projekt a ucit se na nem, nez ucit se jen pro uceni (coz cloveka prestane brzy bavit a hlavne jeste driv zapomene).

 

[Michal Fecko]

Ak zvladnes brainfuck tak ti bude putna aky dalsi budes studovat...

[Miloslav Ponkrác]

Osobně si myslím, že anketa i rozhodování je postaveno špatně.

Co vlastně chceš dokázat? K čemu Ti ten jazyk bude?

Univerzální jazyk neexistuje, jazyk, ve kterém by se dobře a efektivně programovalo vše. Vždy bude v něčem skvělý a v jiném horší, než jiný jazyk.

Když to rozeberu – mono a potažmo tedy C# – manuály hledej u Microsoftí a Windowsí komunity, vychází jich spoustu. Silně doporučuji jako autora Jeffrey Richtera, ten chlap podle mě píše geniální knížky. Ale já osobně bych se tomu vyhnul díky silné vazbě na MS a divokému neřízenému vývoji. A mono je napůl stejně emulátor Windows behaviors.

Python – dobrá volba, ale časté změny syntaxe i rozhraní. Čas od času se připrav na to, že budeš přepisovat, viz poslední verze 3. Pokud máš nadbytek času a hrozí Ti ukousání nudou a chceš řešit tyhle problémy, je Python vynikající volba (stejně tak spolu s MS Office makrováním, které se také intenzívně mění pod rukama).

Ruby – nemám zkušenosti, ale jazyk je bohužel nakažen nenávistí japonského tvůrce k Unicode, a řeší se tam řetězce poněkud divně (jazyk neodstiňuje od bajtové a binární reprezentace řetězce, je povinnost se jí zabývat), dále neumí nativní thready, namísto toho má vlastní, takže výkon threadů ponechám na fantazii. Dále se tam vyskytují nekompatibility a změny v syntaxi jazyka podobně jako viz výše. Na rozdíl od Pythonu, PHP, je v ní minimum použitelných webových frameworků, známější prakticky jen Ruby on Rails.

Java – pro některé lidi je to Bůh a když řeknete cokoli proti Javě, je to horší, než když mu zabijete bratra. Takže informace o Javě jsou dosti tímto prodchnuté, a je třeba zapojit zdravý rozum a některé informace protřídit. Java není špatná, ale troufám si říci, že kromě enterprise záležitostí vždy existuje prostředek, se kterým snáze dosáhnete cíle. Na desktop aplikace určitě najdete technologie, kterým dosáhnete výsledek rychleji a jednodušeji. Na web je Java poněkud megalomanská, automaticky předpokládá, že děláte velký, nebo alespoň středně velký projekt – což pro velký projekt je samozřejmě výhoda. Ale na web to není jinak špatná volba.

[Let_Me_Be]

Univerzální jazyk neexistuje, jazyk, ve kterém by se dobře a efektivně programovalo vše.

Ale existuje, je to C++. V tom se da delat uplne vsechno. Od embeded pres desktop, skriptovani az po web.

[Miloslav Ponkrác]

S dobrou knihovnou a po určitých zkušenostech v C++ ano.

Jenže C++ nemá dobrou knihovnu (pro šťouraly – Qt není C++ knihovna (viz moc) a je právně vadná, tedy omezená).

 

[Let_Me_Be]

Jednu univerzalni urcite ne. Coz je jenom dobre.

Jenom pro zajimavost, proc ze by Qt nemelo byt C++ knihovnou?

[Miloslav Ponkrác]

Protože Qt používá speciální preprocessor z důvodů, že autoři se shlédli v Objective C.

Protože Qt nepoužívá téměř nic z C++, využívá max. pár procent možností C++, a to jsem ještě optimista.

Protože kromě využívání tříd a občasného sem tam fičury je to vlastně psané Céčkovým zpsobem a Céčkovými metodami (například vracení chyb návratovou hodnotou), nebo Objective C metodami (moc a jeho překlad některých fičur Qt).

[Let_Me_Be]

No to je hezke, ale pak neni C++ knihovnou ani Boost. Docela zajimave pak je zamysleni zda je knihovnou pro nejaky jazyk knihovna, ktera je pro tento jazyk vytvorena, nebo zda je to knihovna ktera je v tomto jazyku naprogramovana.

[Miloslav Ponkrác]

Boost je C++ knihovnou, ale Boost je hlavně laboratoří, kde se zkouší co jde z C++ vymáčknout a co by bylo dobré mít v příštím standardu C++.

[Let_Me_Be]

Boost je hlavně široce používanou enterprise C++ knihovnou.

[Miloslav Ponkrác]

Univerzální základní knihovna pro C++ by nebyla špatná. Bohužel standardní knihovna spoustu věcí neřeší, neřeší totiž skoro nic.

Proč by nemohla být ve standardu, nebo v jedné univerzální knihovně věci jako třídy pro datum, čas, thready, práce s velkými čísly, unicode stringem, a dalšími?

[Let_Me_Be]

Vsechno tohle bude v C++0x a uz ted to je Boostu.

[Miloslav Ponkrác]

V C++0x nebude nic, co by se dalo nazvat dobrou univerzální knihovnou.

[kralyk z abclinuxu]

protože všechny tyhle věci jsou platform dependant (a to i unicode stringy - v různých systémech jsou chápány jinak). Můžeš to pořešit stejně jako boost, což znamená že to bude fungovat na většině platforem, ale nebude to obecné, univerzální, což by C++ mělo být.

[Let_Me_Be]

Tak zrovna kocne vyresny problem unicode v C++0x bude. Jen tak mimochodem pomoci locale se da s unicode pracovat relativne rozumne i ted.

 

[kralyk z abclinuxu]

Ok, ten unicode beru, ale věci jako datum/čas, velká čísla a thready jsou rozhodně platform-dependent.

[Let_Me_Be]

To ano, ale to je prave ukol knihovny aby tohle odstranil. Datum a cas je v C++ uz ted pres locale, velmi dobra knihovna je v Boostu, thready jsou v Boostu a budou v C++0x. Velka cisla nevim (zatim jsem nepotreboval).

[Luboš Luňák]

Jenom pro zajimavost, proc ze by Qt nemelo byt C++ knihovnou?

Protoze Miloslav Ponkrac se rozhodl vydat na krizovou vypravu proti Qt a umyslne uz roky siri lzi (protoze uz byl nekolikrat mnou upozornen na ruzne nespravnosti v tvrzenich o Qt vcetne odkazu na dukazy, tak dalsi opakovani jsou proste umyslne lzi). Qt je C++ knihovnou minimalne tak jako Gtk je C knihovnou a program vyuzivajici Qt jde prelozit jako C++ program bez problemu (plus minus bugy).

[Miloslav Ponkrác]

Nemáte argumenty, tak se snažíte potopit diskutujícího? Jak ubohé.

Je snad lež, že Qt knihovna má právní omezení?

Je snad lež, že Qt není psána v čistém jazyku C++, ale vyžaduje moc preprocessor?

Je snad lež, že Qt vrací chybové kódy a ne výjimky?

Je snad lež, že Qt využívá maximálně pár procent z C++?

Qt bez preprocessoru nemůže být. Ok, v tom případě je i zdroják v Adě programem v C++, protože určitě ho lze přeložit bez problémů jako C++ ´´- stačí k tomu preprocessor, který převede Ada zdroják na C++ zdroják.

[Luboš Luňák]

Nemáte argumenty, tak se snažíte potopit diskutujícího? Jak ubohé.

Mám. Už jsem to nimi několikrát zkoušel, ale nefungovalo to, protože bez ohledu na ně se to pořád opakuje. Jak ubohé.

Je snad lež, že Qt není psána v čistém jazyku C++, ale vyžaduje moc preprocessor?

Ano, je to lež. Už jsem to tu minimálně jednou vysvětloval.

Qt bez preprocessoru nemůže být. Ok, v tom případě je i zdroják v Adě programem v C++, protože určitě ho lze přeložit bez problémů jako C++ ´´- stačí k tomu preprocessor, který převede Ada zdroják na C++ zdroják.

Já nechápu, proč některé lidi tak strašně baví se tvářit moudře o něčem, o čem nic pořádně neví. Já s Qt dělám prakticky denně, dělám občas i věci přímo do Qt a dělal jsem i přímo změny pro moc. Vysvětlovat mi dokolečka, jak to funguje, a přitom ani nevědět základní věci, to je prostě drzost a já už na to nehodlám plýtvat časem. Tímto naposledy žádám, abyste přestal šířit svoje pomýlené představy o Qt.

[Deleted [8409]]

+1

moc v Qt je velice dobře vymyšlená věc, která naopak jazyk C++ obohacuje.

Docela by mě zajímalo, jestli by chtěl někdo udělat něco podobného pod BSD licencí.

[Luk]

je právně vadná, tedy omezená

Pěkný flamebait

[Miloslav Ponkrác]

Qt je licenčně omezená - tedy je právně omezená pro účel, kdy by měla být nazvána univerzální knihovnou.

[Luk]

Ano, není právně způsobilá být univerzální knihovnou. Ovšem termín "právně vadná" je dobrá nahrávka na rozpoutání flamewaru.

[Miloslav Ponkrác]

Qt je pro mnoho projektů právně vadná.

Možná je to slovo vadná termínem vyvolávajícím trochu emoce, ale je to tak.

[kralyk z abclinuxu]

Knihovnu tak rozsáhlou a kvalitní, jako je Qt, vám nikdo zadarmo (jinak než pod GPL) prostě nedá. Programování není charita. Imho to je jako chtít zadarmo kvalitní auto, který nepotřebuje benzín

[Deleted [8409]]

Jen aby někdo neudělal kvalitnější

[Luk]

Knihovnu tak rozsáhlou a kvalitní, jako je Qt, vám nikdo zadarmo (jinak než pod GPL) prostě nedá.

Nedá?

[kralyk z abclinuxu]

No nějak se to zaplatit musí, Sun na to má...

[Miloslav Ponkrác]

Lidé, kteří nechtějí právně závadné a omezené věci používají kvalitní a rozsáhlé knihovny, které jsou free. Například wxWidgets je velice pěkná knihovna.

[kralyk z abclinuxu]

Na Qt nemá... zdaleka ne...

[Ilfirin]

Což je i plus.

[freshmouse]

> časté změny syntaxe i rozhraní

Tohle bude to poslední, co by tazatele trápilo...

> Java – pro některé lidi je to Bůh a když řeknete cokoli proti Javě, je to horší, než když mu zabijete bratra.

Což teprve říct rubistům něco proti Ruby!

[Miloslav Ponkrác]

Tohle bude to poslední, co by tazatele trápilo...

Zatím …

Což teprve říct rubistům něco proti Ruby!

A sakra, vidím, že jsem o něco přišel. S Rubysty přicházím do styku spíše statistickou chybou, takže jsem neměl čest.

[alblaho]

Nekřivdíte tomu Pythonu trochu? Jistě, verze 3.0 je nekompatibilní, neběží v ní v podstatě žádný dvojkový program.

Ale to je první velká nekompatibilita po nějakých patnácti letech, ne? Nezažil jsem přechod z 1.x na 2.x, ale co jsem tak četl, tak tam žádné zezmětřesení nebylo. Takže přeháníte.

[Let_Me_Be]

Z toho co pises se hodne nabizi nejaky skriptovaci jazyk. Problem je v tom, ze pokud neznas nejaky zakladni jazyk jakym je napriklad Cecko, dokaze studium takoveho dynamickeho jazyka docela trvale poskodit tvoje programatorske schopnosti.

Ze skriptovacich jazyku dnes vede jednoznacne Python (Perl nepocitam, to uz radsi ten brainfuck), nicmene mne osobne prijde hodne neprijmeny na cteni. Ruby na druhou stranu je takove trochu okrajove, ale zase se velmi prijemne cte. V obou muzes jednoduse delat desktopovy i webovy SW.

[Jakub Lucký]

Python a Perl...

[kralyk z abclinuxu]

Na desktopové hříčky určitě C++
Pro tento účel to je nejlepší volba a tento jazyk je široce používaný a uznávaný. Koneckonců, je to nejlepší programovací jazyk vůbec

Na online aplikace si nejsem už tak jistej, ale tou Javou imho nic nezkazíš.

Na volovinky jako MONO,.NET apod. bych se vykašlal...

[Pavel]

Hm, podivej se na devexpress.com a pak tu neco vykladej o C++ jako nej. jazyku pro desktop. V .NETu udelam fungujici desktop app (obecne) s minimem chyb 10x rychleji, nez ty v C++

[kralyk z abclinuxu]

Možná tak proto, že umíš rychlejc psát. Když budu mít setjně rychlí ruce, udělám stejně rychle desktop app (třeba v Qt) a pojede stejně spolehlivě na Windows, Linuxu i Macu, navíc nativně bez potřeby nějakýho MS frameworku

Nevím, z čeho usuzuješ, že .NET/C# je lepší pro desktop než C++. Procento aplikací v .NET tomu nenasvědčuje...

[Michal Vyskočil]

Na vysoké se do nás pro změnu pokoušeli dostat Javu, která vzhledem k náročnosti na HW nepřipadá pravděpodobně v úvahu.
A zrovna teď jsem narazil na docela zajímavý multiplatformní jazyk "MONO," (otevřený .NET?) ke kterému ale marně hledám nějakou českou dokumentaci..

1.) Javu jsem poprvé viděl a spouštěl na 486 a byla to verze 1.1. Počítám, že lidi bez tohoto zážitku nevědí, co je to pomalá Java ve skutečnosti je (i když snížit paměť na minimum a vypnout JIT by mohlo tohle taky slušně emulovat). Současná Java je rychlá obstojně, problém jsou zvýšení nároky na IO během nahrávání a paměťové nároky jsou obecně vyšší, než u nativních ekvivalentů. 2.) Pokud se ti nezdá Java, tak proč zkoušet .NET? .NET a Java je plus mínus to samé včetně nároků.

[Deleted [8409]]

Viděl jsem srovnání Java generics a .NET (C#) generics (jestli se tomu tak říká) a .NET to má vymyšlené líp. Obecně se mi zdá, že .NET aplikace pod Windows běží celkem dobře.

To nic nemění ale na tom, že se Java a .NET aplikace snažím nepoužívat - U té javy je to ale těžké, třeba Eclipse prostě potřebuju :)

[Ladicek]

Jo jo, mezi generiky v Javě a .NETu jsou dva rozdíly: 1. v .NETu je typový parametr známý i za běhu, 2. v Javě jsou ty generiky zpětně kompatibilní Sofiina volba.

[=^..^= AmigaPower®]

Jednoznačně bych zvolil tohle....

BEGINNING-OF-PROGRAM
 DEFINE turnright AS
 BEGIN
   turnleft
   turnleft
   turnleft
 END
 BEGINNING-OF-EXECUTION
   ITERATE 3 TIMES
     turnright
   turnoff
 END-OF-EXECUTION
END-OF-PROGRAM

[Ladicek]

Co to kurňa je? Karel v angličtině?! Kam jsme se to dostali…

[Michal Fecko]

...to se tak někdo má, jezdit si šukat na Slovač za moje prachy...

Co to?

[=^..^= AmigaPower®]

Patička ...ještě bych tam měl dopsat: "..a ani neotěhotnět!" (koťátka zatím nebudou)

[xxxs]

v mene vsetkych, ktori uz za slovensko sukali, sa ti ospravedlnujem.

[=^..^= AmigaPower®]

[Jakub Lucký]

Lepší je v češtině, dělali jsme v něm asi půl roku ve škole...

a KROK;KROK;VLEVOBOK;KROK;VLEVOBOK;VLEVOBOK se vám prostě vryje do paměti...

[=^..^= AmigaPower®]

...to se pak hodilo i na vojně

[anicka]

Ten nas podratovy umel oba jazyky. Zato ma ale omezenou instrukci sadu

[JS]

Ze seznamu bych doporucil Python. Ja sam ho jiz ovladam a pouzivam.

Pres vanoce jsem se chtel naucit Haskell, ale nelibil se mi. Ale me zklamani netrvalo dlouho - narazil jsem na prednasku/knizku Practical Common Lisp, coz vypada slibneji, tak se ted ucim Common Lisp.

 

[Chameleon]

Tak zatím mě nejvíce nadchl ten Python... Vytvořít v něm "Hello World" je prostě úžasné

print "Hello, World!"

[kouzer]

Chybí ti tam závorky. Musíš si pomalu zvykat.

[Chameleon]

No jak se to vezme  

podle verze 2.5 je to:

print "Hello world"

Verze 3:

print ("Hello world")

 

[AHAHA]

Na co asi tak Kouzer narazel?

[...............23]

A v najnovšej verzii pythonu to samozrejme nebude fungovať

[...............23]

sakra, neskoro

[Chameleon]

V nejnovější to bude:

print ["Hello world"]

[frEon]

a zkousel jsi ruby?

puts "hello world"

[YYY]

Coz awk nebo brainfuck?

[Fluttershy, yay!]

Nějaký dobrý. Nebo jsi myslel "který jazyk"? Pak záleží na tom, k čemu to má být dobré. Obecně bych doporučil angličtinu a Python, případně ještě C nebo C++. Mezi námi, exoty, není od věci ani japonština, ani Ruby, ani Lua, ani něco pořádně funkcionálního.

[Fluttershy, yay!]

Jo a dneska to vypadá, že JavaScript už by nemusel být takovým zlem jako dříve.

[User682]

zadny.

Dokud nevite, co chcete presne programovat, tak zadny jazyk. Analyza se da delat delat nastesti bez programovaciho jazyka a svet je usetren mnoha problemum......

[AHAHA]

Kazdy programator musel nejak zacit. Ti stastnejsi si mohli svuj prvni jazyk i vybrat ...

[Deleted [8409]]

C/C++, C#, Java

[Bluebear]

Tenhle výběr má jednu chybu: všechny tyto jazyky patří víceméně do stejné rodiny (já vím, není to tak úplně, ale skutečnost není zcela škatulkovatelná), takže si tolik nerozšíří obzor.

Já bych navrhoval se navíc podívat alespoň na Python jako zástupce skriptovacích jazyků s netypickou, ale čistou syntaxí; Perl jako jazyk, ve kterém byla už napsána spousta spolehlivě fungujícího a efektivního, i když na pohled hodně odpudivého kódu; LISP, protože je to součást všeobecného vzdělání, a například Haskell jako zástupce funkcionálních jazyků.

Neříkám, že v tom všem musí umět programovat, to by měl hlavu jako škopek; jen se na ně podívat a ochutnat.

[Fluttershy, yay!]

A SmallTalk a nějaký shell.

[Deleted [8409]]

Pokud to berete takto, ale zkuste se podívat na pracovní místa

Já osobně používám Python asi rok, ale na tu syntax si jako dlouhodobý programátor v C++ prostě nemůžu zvyknout. Jasně, napíšu co potřebuju, ale připadá mi to divné

Navíc jazyky jako Python jsou logicky mnohem víc náročnější a pomalejší než třeba Java nebo C#. Ale na druhou stranu, třeba takové skriptování, tam nemám s pythonem problém.

[Fluttershy, yay!]

Zrovna spolupráce Pythonu s C/C++ je hodně dobrá.

[Deleted [8409]]

Spolupráce C/C++ s Java/.NET není dobrá ?

[Fluttershy, yay!]

S Javou nevím, ale Python také s Javou/.NET spolupracuje.

[Bluebear]

Navíc jazyky jako Python jsou logicky mnohem víc náročnější a pomalejší než třeba Java nebo C#

Myslím, že to tak docela není. Souhlasil bych, že určité zpomalení ve srovnání s čistým C-čkem tam bude vždycky, ale rozdíl mezi Pythonem a Javou už bych neviděl tak jasně, alespoň ne principiálně. Python je rychlostně znevýhodněn tím, že je dynamicky typovaný, ale to se dá řešit, třeba just-in-time kompilací s několika variantami dané funkce dle typů.

A primárně záleží na typu úlohy. Pokud píšu věc, kde záleží na každé mikrosekundě a každé zmeškané přerušení znamená průser, tak jedině čistý assembler, C (což je, jak praví zlí jazykové, taky assembler) nebo C++, zkrátka něco, co se překládá do strojáku přímo a hned.

Ale pokud není úloha primárně závislá na procesoru, ale zdržuje ji něco jiného (třeba komunikace po síti nebo s diskem), tak je vcelku jedno, v čem je napsaná, protože prostě rychlost-určující-člen je jinde.

[Miloslav Ponkrác]

Python nemusí být až tak náročnější, ale nemá dobrý interpretr. Teď budu trochu ironický – když autor Pythonu akorát překopává syntaxi, nemá čas udělat pořádný interpretr. Dynamické typování sice Python mírně znevýhodňuje, ale daleko více ho znevýhodňuje současný velmi primitivní interpretr. Nemá nic, než překlad do byte kódu a přímou interpretaci. Přičemž překlad do byte kódu není optimalizovaný, je prostě jen zparsovaný zdroják. Kdyby si někdo dal práci, myslím, že současný Python by šel radikálně zrychlit, ale to mu zase autor Pythonu hází klacky pod nohy jeho rozrýváním v době, kdy měl být Python už aspoň desetiletý stabilizovaný.

[Deleted [8409]]

Spíš by stačilo, kdyby se tomu někdo začal fakt věnovat. Když se třeba podívám, jak byli lidi schopní zoptimalizovat javascript (TraceMonkey, V8), tak můžu jen říct - dobrá práce.

Mi osobně Python na některé věci stačí, ale rozsáhlejší projekt bych v něm asi nezačal.

[Fluttershy, yay!]

Martin Hassman na LinuxAltu zmiňoval, že by mohl někdo udělat interpreta Pythonu v Javascriptu.

[Ilfirin]

Pokud chceš dostat python interpreter do prohlížeče, jsou na to způsoby již dnes.

[Fluttershy, yay!]

Tam šlo hlavně o výkon, protože výkon interpretů JS v poslední době dramaticky roste a mohl by se hodně přiblížit strojovému kódu.

[Ilfirin]

Ach tak. No, to potom jo.

[Bluebear]

Já osobně používám Python asi rok, ale na tu syntax si jako dlouhodobý programátor v C++ prostě nemůžu zvyknout. Jasně, napíšu co potřebuju, ale připadá mi to divné

Samozřejmě, někdo radši holky, někdo vdolky A je to tak správně - kdybychom měli všichni stejný vkus, tak je veškerá myšlenková variabilita v pr... a tím i lidstvo.

Já taky nejsem s Pythonem moc kompatibilní.

[Bluebear]

Doporučil bych zkusit si očichat několik co nejodlišnějších jazyků; tím získáš jednak přehled o různých jazycích a tím také o různých přístupech k řešení problémů, a potom si budeš moci vybrat, co ti nejlépe vyhovuje.

[AHAHA]

Nemyslim si, ze je to nejstastnejsi rada ... pokud programovani nerozumi, rozdily neoceni a spis z toho bude zmateny ...

Zacal bych s nejakym proceduralnim (objektovym) jazykem, ktere jsou na rozdil od tech ostatnich (funkcionalnich, napr.) i dobre pouzitelne pro realne aplikace (no flame please, muj nazor).

[frEon]

tak pak je idealni lisp. Muzes si psat proceduralne, objektove a kdyz je chut, tak i funkcionalne.

[Fluttershy, yay!]

To mi připomíná, kam se poděl Kyosuke?

[Bluebear]

To mi připomíná, kam se poděl Kyosuke?

To kdybych věděl. Také se mi stýská.

[Bluebear]

Vím, že je to strašně starý a ohraný vtípek, ale prostě mi to nedá...

Pravý programátor dokáže programovat ve Fortranu v libovolném jazyce.

[Jakub Lucký]

Ale je dobrý... skoro tak dobrý jako:

Programování bez Fortranu a Cobolu je jako dort bez kečupu a hořčice

[PMD]

Nauč se ActionScript 3, ten má perspektivu :)

[x]

Cetl jsi SICP? Proste zkus LISP, Scheme anebo Haskell. Bohuzel pak jiz skoro neni cesty zpet. ;)

[depka]

kup si olejove barvy a stetce a uc sa radsi malovat

[YYY]

Hlavne nezacinej phpkem