Rubinius 1.0 již klepe na dveře

Zhrniem tvoj clanok

- aktualna verzia je 0.9
- nie je plne kompatibilny s ruby
- rails na nom nebezia
- je vyrazne pomalsi ako ruby 1.9

[1]: dekuji za laskavost, nicmene to nebylo nutne. Ze neni plne kompatibilni s Ruby je pravda tak napul - Rubinius ma byt zcela kompatibilni s Ruby, akorat neni zatim vse implementovano. Nejedna se tedy od zamerny odklon od MRI.

Ad anketa: chybí možnost Můj oblíbený jazyk nemá alternativní implementace, protože není definován oficiální implementací, ale popisem toho co a jak má umět a i které chování není specifikováno. (A je celkem jedno o který jazyk se jedná)

Pokud napíše někdo virtuální stroj z větší části v Ruby a ne v Asm/C/C++, pak se dá celkem slušně prorokovat, že to bude pomalé jako prase, nehledě na to, že to taky pravděpodobně bude žrát více prostředků systému (paměti, zátěže cpu, atd.). A že ta pomalost je prostě důsledek takto zvolené architektury virtuální mašiny, a těžko se nějak výrazně zlepší.

Proto si myslím, že Rubinius zase za čas zapadne a neštěkne po něm ani pes. Je totiž úplně jedno, jestli se budu bavit o Javě, o .NET frameworku, o Perlu, o Pythonu - totiž to hlavní co člověk čeká od virtuální mašiny (interpreteru) takového jazyka je především na prvním místě spolehlivost a v těsném závěsu za tím maximální rychlost. Což je přesně to, na co Rubinius dojede.

Mezi námi - co Vy byste si vybrali ze dvou virtuálních strojů, která (až bude Rubinius dokončen) umí to samé, akorát Rubinius bude pomalejší a oficiální Ruby jádro bude rychlejší? Myslím, že volba je jasná.

Čistý Ruby kód ve virtuální mašině ocení 0,000001% lidí (mimo jiné i autor článku), rychlou virtuální mašinu ocení 99,999999% lidí. Podle mě Rubinius nemá s touto architekturou šanci se prosadit.

[3] Ano souhlasím, naprostá většina jazyků je definována normou/standar­dem/popisem a dost mě to spojení "alternativní implementace" vystrašilo.

Jaká je alternativní implementace pro C, pro C++, pro Asm, pro Adu, pro Fortran, pro LISP, pro unixový shell, pro Haskell, pro Smalltalk, pro APL, pro COBOL, pro Logo, ... - to jen co mě tak hned napadlo.

Já osobně s jazyky, které mají "oficiální implementaci" mám dost špatné zkušenosti - většinou to svádí k tomu, že autor tohoto jazyka začne kašlat na zpětnou kompatibilitu, začne dřív, nebo později upravovat sysntaxi jazyka způsobem, že Vás donutí existující zdrojové kódy přepsat, nebo alespoň trochu upravit. Že v tom máte milión řádek ve zdrojovém kódu, a že si tam novým přepisem můžete do perfektně odladěného kódu zanést i obtížně hledatelné chyby, tak daleko tvůrce takového jazyka většinou nedohlédne.

Pokud jazyk má "oficiální implementaci", autor jazyka nikdy nezvládne nepoužít tu moc k totálnímu rozkopání viz odstavec výše. Pokud existuje popis jazyka, nebo norma, či standard, většinou se toto neděje. Dostatečný počet běhový prostředí a mnoho napsaného kódu většinou udrží autora na uzdě, nehledě na to, že autor jazyka, který stvoří popis, nebo dotáhne jazyk k normě, většinou svůj jazyk míní seriózněji.

Jako příklad si vemte jazyky, které mají "oficiální implementaci": Python - autor deklaruje, že ve verzi 3 bude Python nekompatibilní a změní se zdrojové kódy. Ruby - autor deklaruje, že změní a překope nekompatibilně syntaxi jazyka. Perl - autor ve verzi 6 nekompatibilně změní syntaxi jazyka. Atd..

Závěr: Pokud chcete napsat velké sw dílo, které chcete mnoho let udržovat při životě - vyberte si jazyk, který nemá "oficiální implementaci" - ušetříte si hodně nervů, času, chyb, atd.. Vyberte si seriózní jazyk, který na Vás myslí, a který chrání Vaše investice do zdrojových kódů v něm napsaných.

[4] Záleží na tom, jak je takový projekt koncipovaný. Třeba na takový projekt PyPy vaše definice rozhodně neplatí.

[5] Myslím, že je to celé jinak. V principu jde rozkopat stejně dobře implementace jazyka, jako jeho specifikace. Jde mnohem víc o to, jakou má autor jazyka odpovědnost vůči jeho uživatelům.

U open source projektů je tato odpovědnost relativně nízká, proto jazyk klidně překope - přednější je pro něj konvergence ke stavu, o kterém si myslím že je lepší. U komerčních projektů je odpovědnost naopak vysoká, protože ze stability jazyka a platformy plynou peníze - kdyby platforma nebyla stabilní, zákazníci by utekli jinam.

Fakt, že jazyky vzešlé z open source projektů jsou často specifikovány implementací a jazyky vzniklé v komerčním prostředí naopak specifikaci typicky mají není podle mě v příčinném vztahu se stabilitou jazyka, obojí je to důsledek stylu a priorit vývoje v daném prostředí.

[6] Ale no tak. Srovnáváte jabka s hruškami. Projekt PyPy se snaží (pokud je mi známo, když tak mě opravte) o JIT kompilaci, tedy jinak lapidárně řečeno o kompilátor Pythonu do strojového kódu.

[7] Zkuste si překopat specifikaci jazyka a zkuste si překopat implementaci jazyka.

To první je daleko těžší, protože změníte-li jednu věc v pětisetstránkové dokumentaci, většinou musíte k tomu najít příslušné odkazy a souvislosti a hodně přemýšlet, kde se to všude promítne. Po několika takových změnách musíte de facto pečlivě pročíst celou dokumentaci a bedlivě sledovat, kde je potřeba dokumentaci opravit o změny.

To druhé je relativně snadné, 90% změn dosáhnete změnou jedné konstanty v programu, či úpravou několika řádků programu, máte-li imlplementaci dobře udělanou s dobrou architekturou. A ono to tak svádí, je to tak jednoduché a prstíky jsou mršky nenechavé...

Takže souhlasím s Vámi, máte naprostou pravdu, ale přeci jenom je pravda, že opravit oficiální implementaci je mnohonásobně snadnější a i to má velký vliv.

S čím naprosto nesouhlasím je spojování s open source projekty. Ano, odpovědnost open source projektů je většinou nízká, přímo pod bodem mrazu. Ale musíte si uvědomit, že na stvoření domyšleného vlastního programovacího jazyka nemá každý programátor, který včera poprvé napsal Hello world program. Takže potřebujete zkušeného člověka - má-li ten jazyk za něco stát. A tam už jsou jiné zákonitosti.

Ale jinak s Vámi v podstatných myšlenkách souhlasím, v čem se lišíme jsou jen nepodstatné drobnosti.

Jen bych dodal, že každý člověk se vyvíjí a mění názory. Stejně tak jako básníci, jak se učí v českém jazyce procházejí životními zlomy a podstatně tak mění svůj náhled na svojí tvorbu, tak i návrháři jazyků procházejí změnami svých názorů. Je na 100% jisté, že pokud autorovi jazyka dáte možnost vládnout neomezeně nad svým jazykem třeba dvacet let, že ho několikrát zcela překope, a to i tehdy pokud původní verze byla geniálně domyšlená. Je to proto, že každému člověku se v každém období života líbí něco jiného - a nemá to s kvalitou vždy tak moc společné.

Zkrátka, seriózní jazyk poznáte podle toho, že

a) Zachovává zpětnou kompatibilitu co to jenom jde. Pokud se úchýlí přeci jen k nepatrným změnám zpětné kompatibility, je to z velmi vážného důvodu a mnoho měsíců se zvažuje, zda je skutečně, byť i nepatrné porušení zpětné kompatibility opravdu potřeba.

b) Jazyk je dán popisem - tj. normou, nebo standardem - tedy dokumentem, či sadou dokumentů naprosto přesně, do detailu a normativně popisují každý bod jeho chování.

Jazyky, které nezachovávají body a) a b) (Python, Perl, Ruby, ...) se nepoužívají pro vážnější a dlouhodobější projekty, nazývají se "skriptovací", nikoli "programovací".

Představte si třeba, že by někoho napadlo udělat nekompatibilní unix shell. Nebo se rozhodl změnit programovací jazyk C a vývojářům Linux jádra vzkázal: sorry, je mi líto, ale musíte ty milióny řádek kernelu prostě přepsat, protože jsem se dnes špatně vyspal a rozhodl jsem se nekompatibilně změnit syntaxi C. Utopie? V Pythonu, Perlu a Ruby se to obhajuje jako ta nejlepší věc, co se dá udělat.

proboha, vzdyt nikdo nebude chtit jadro kernelu psat v Ruby!, takze to prirovnani je docela mimo, nemyslite?

navic to nevypada, ze by autori Ruby, Perl Python chteli kazdych par let svuj jazyk totalne prekopat - ty zmeny, co se ted chystaji asi budou platit hodne dlouho, coz samozrejme souvisi s tim, ze uvedene jazyky dospivaji

navic No.2, zmeny v Ruby jsou v porovnani hlavne s Perlem, kde se jedna o uplne novy jazyk, ale i s pythonem, docela male

velke projekty v techto jazycich samozrejme existuji, v Ruby je to treba Rails

nerekl bych, ze odpovednost autoru open source projektu je 'pod bodem mrazu'. Asi jak kterych. V pripade tech uspesnych je odpovednost naopak velice velka

i vzhledem k vyse uvedenym bodum se 'skriptovaci' (ale spise Dynamicke) jazyky stavaji v oblasti rekneme aplikacniho programovani vaznymi konkurenty pro Javu (plati hlavne pro Ruby), coz je proste realita

[10] Naprosto všechno v Ruby napsat nejde, na to je ten jazyk málo mocný, proto se rozumí samo sebou, že něco málo musí být psáno třeba v Céčku. Považoval jsem to za tak zřejmý fakt, že jsem ho nezdůrazňoval. Ale už snaha přesunout co nejvíce věcí do Ruby ve virtuální mašině je obrovsky na škodu rychlosti.

Problém je, že jste napsal "nevypadá to, že by autoři chtěli" - je to jenom domněnka, a pokud postavíte svůj byznys na domněnkách, tak poznáte jak se trestá naivita. Nikdo žádný slib nedal, že to později nepřekope - tu jistotu nemáte, takže až to budou překovápat znovu, nikdo jim v tom nemůže zabránit. Ono bohatě stačí, že někdo překope jazyk, který je tu mnoho let, docela slušnou kupici let, a je mu u zadnice, že se v tom napsalo spoustu kódu, a že tím způsobí problémy mnoha programátorům. Tohle není seriózní přístup - a lidé by neměli naivně svěřovat cenné věci a programovat cokoli důležitějšího v jazycích s neseriózním jednáním.

to No 2: Je jedno, že se jedná o malé změny - pořád je to změna - a pořád to implikuje projít zdrojáky a opravit je, a znovu otestovat. Představte si, že by třeba TCP protokol pro internet udělal "docela malou změnu", která by jenom způsobila, že stávají síťové programy od telenetu, ssh, mailových a webových klientů, serverů, jádra Linuxu a dalších programů nefungovaly a musely se přepsat. Asi cítíte, že by to nikdo neobhajoval, že?

Velké projekty v jazycích samozřejmě existují - ale jedna vlaštovka jaro nedělá.

Předposlední odstavec je subjektivní věc, tudíž nekomentuji.

Tak jestli je Ruby vážným konkurentem pro Javu, tak jděte velké bankovní a enterprise systémy programovat v Ruby. Až uvidíte tu zodpovědnost, záruky a další věci co tam musíte dát, tak budete muset být hodně věřící, použijete-li Ruby. A pokud by se stal zázrak a přesto jste nějaký náročný enterprise projekt v Ruby rozjel, tak zkrachujete brzy díky tomu, že Vám Matz změní syntaxi a překope chování jazyka. A to ještě dopadnete dobře, protože nejspíš to odnesete ještě velkým penále a náhradou škody.

Pane Ponkrac, proc pod skoro kazdym clakem o nejakem programovacim jazyku musite neustale kazdemu vysvetlovat jak ten jazyk je spatny nebo jak je pomaly. Potom zacnete tlacit kecy o C/C++ apod. Koho to zajima. Pouzivate to snad? Proc to vas tak vzrusuje? Proc musite neustale omilat C/C++. Nechcete si radsi venovat vasemu oblibenmu C/C++ a ostatni neotravovat?

[12] Nemám-li argumenty, začnu útočit na člověka.

[13] Ano, je hezke priznat vlastni slabost. Za to mate ode me poklonu, chtelo to odvahu.

[9] "Jazyky, které nezachovávají body a) a b) (Python, Perl, Ruby, ...) se nepoužívají pro vážnější a dlouhodobější projekty"

Myslím, že až příliš zobecňujete. Pokud bych já vybíral platformu pro implementaci nějakého "vážného projektu", v první řadě bych se pokusil odhadnout, kolik mi použití (třeba) Ruby místo Javy ušetří práce a kolik mi ji naopak kvůli nekompatibilitám při upgradech na nové verze a jiným neduhům přidělá.

Pokud by mi vyšlo, že výsledný systém bude mít v Ruby poloviční velikost, a tedy náklady na něj budou méně než 50 % původních nákladů (náklady s velikostí projektu nerostou lineárně), přičemž náklady na upgrade budou něco jako "spustit unit testy a fixnout všechny bugy, na které se při tom narazí" - což i u velkého projektu není příliš práce - projekt bych šel dělat v Ruby, ať už je "vážný" nebo "nevážný". Naopak, pokud by byly úspory na velikosti zanedbatelné a upgrade problematický (nebudou unit testy, systém je mission-critical,...), volil bych stabilitu.

Myslím, že podobné pragmatické, ekonomicky orientované uvažování je lepší než jakékoliv vzletné obhajování jednoho nebo druhého přístupu.

(Samozřejmě jsem si vědom, že odhad velikosti projektu a nákladů na upgrade je jen odhad, dělá se těžko, vyžaduje znalosti srovnávaných jazyků/platforem, apod. - čili že v praxi to vůbec není tak jednoduché, jak tady teď maluju. Ale jde mi o princip.)

[13] Nic, nemáte-li argumenty, přestanu na Vás reagovat. Chcete-li někoho očernit, nechám Vám tu volné pole, budu reagovat jen na ostatní, Vás budu ignorovat.

[11]
srovnani s kernelem, TCP protokolem a dalsimi je IMHO docela nevhodne, protoze neni treba vymyslet stale nove kernely, nove protokoly, atd, takze zpetna kompatibilita je desne dulezita. U aplikacniho programovani je situace uplne jina - programiji se stale nove aplikace, a na vyber je z mnoha technologi.

Matz na jedne z minulych konferenci zahlasil, ze si dovede predstavit, ze tu vedle sebe budou koexistovat dve implementace Ruby - 1.8ckova a nova, 1.9. A mohou koexistovat vlastne libovolne dlouho, protoze, na coz zapominate, je tu i komunita. Takze opet zadne velke, nasilne, revolucni zmeny. Tak tomu v open source komunite neni pravidlem - tim je spise zmena potupna, evolucni

pokud sleduji vyvoj daneho jazyka (vcetne jeho konkurentu, a pokud si navic treba sam zkusim nejaky jazyk, cvicne, nadesignovat), mohu si vytvorit dojem o zmenach, ktere bude jeho autor, po konzultaci s komunitou, chtit uskutecnit. Takze sice dojem, ale docela dost urcity

Ruby pro Javu konkurentem zcela jiste je, at se vam to libi nebo nebo. Sice nikde netvrdim, ze v pripade treba prave onech bankovnich aplikaci, ale treba v pripade webovych aplikaci zcela urcite.

ze Vy si tak trochu delate srandu, nebo umyslne provokujete s tou Vasi argumentaci ("cely ten odstavec o ...jazycích s neseriózním jednáním")? Prece tomu, jak funguje open source rozumite, ne?

[15] Ano, tady s Vámi musím naprosto souhlasit, napsal jste to lépe, než já.

Velmi záleží na projektu, který děláte a na rozvaze kolem toho. Nutno si ale přidat, několik věcí:

1) Spuštění unit testů není, nebyla a nikdy nebude záruka bezchybnosti programu. Pečlivě odladěný kód nevyrobíte pouhým spuštěním unit testů. Z hlediska teorie i praxe je dokonce nemožné udělat unit testy, které projedou všechny možné stavy sytému. Tudíž takto nezískáte odladěný projekt. Unit testy jsou velmi užitečná věc, o tom žádná.

2) Velmi důležité kritérium pro náklady projektu je udržovatelnost - skoro jsem ochoten tvrdit, že začátečníka od profesionála poznáte podle toho jak moc klade váhu a důležitost na udržovatelnost programu. Zkušený harcovník už ví, že ušetřená hodina práce na vývoji se mu může bohatě vymstít stovkami hodin práce navíc na údržbě. Začínající programátor toto velmi podceňuje a nevysvětlíte mu to.

Pak je to také o tom, jak moc hrozí, že program budete udržovat. Pokud píšete jednorázový, nabo krátkodobě používaný program, tak náklady na údržbu lze zanedbat.

Velmi důležité pro tento moment jsou kromě kvalit jazyka a jeho neměnnosti také existující knihovny, které určiují někdy ekonomickou stránku projektu více, než jazyk.

Hodně často vidím ve firmách scénář: Nějaký programátor naprogramuje program v rekordním čase - všichni ho plácají po zádech, je to borec, šéf se na něho usmívá. Pak se program používá, či prodá a zákonitě nastane potřeba prvních úprav - a najednou borec ne a ne úpravu dokončit, či pokud je nemorální, snaží se to shodit na někoho jiného pod libovolnou záminkou, aby ten průser odnesl někdo jiný. Pokud je programátorský tým zkušený, tak to padne na původního autora, pokud ne, najde se někdo, kdo se to snaží opravit a velmi často skončí pro "neschopnost" dodat opravu v termínu. Prostě co se ušetřilo v rychlosti vývoje původního programu, to je 1000x více prodraží v údržbě a program nejde rozumně dlouhodobě udržovat. A samostatnou kapitolou jsou multithreadové programy takových borců sdílejících mezi thready stovky i tisíce globálních proměnných a objektů bez jakékoli synchronizace.

Závěr: Vše je třeba posuzovat v kontextu daného problému - co chcete dělat a co s tím v budoucnu chcete dělat atd.. Neexistuje žádný nejlepší programovací jazyk, proto jsem tu ani žádný neuváděl. Jen jsem uvedl kontext "serióznosti". Rozhodně dlouhodobý projekt bych nedělal v jazycích bez seriózních záruk jak jsem psal výše. Vždy najdete srovnatelný jazyk podobné úrovně, který je seriózní a dává nějaké záruky do budoucna, pokud budete opravdu objektivně hledat.

"srovnani s kernelem, TCP protokolem a dalsimi je IMHO docela nevhodne, protoze neni treba vymyslet stale nove kernely, nove protokoly, atd, takze zpetna kompatibilita je desne dulezita."

Ne, je to zcela vhodné přirovnání, protože naprosto jasně demonstruje, že kdyby se vše stavělo se stejným přístupem jako Python, či Ruby, byli bychom nic neměli.

Jinak jestli Vám to připadá nevhodné, představte si jazyk C, který by se rozhodl, že od teď nebude možné přeložit starý C kód, protože se rozhodlo, že C bude mít nekompatibilní syntaxi. Dochází Vám co by to způsobilo?

"U aplikacniho programovani je situace uplne jina - programiji se stale nove aplikace, a na vyber je z mnoha technologi."

Ano, akorát že spousta aplikací je poněkud starší a trvalo by řadu let je přeprogramovávat. Já bych si někdy přál, aby třeba Matzovi někdo sdělil: "Tak holánku, rozhodli jsme se změnit syntaxi Céčka, takže odteď tu svojí mašinu pro Ruby nepřeložíš, ale hezky to napíšeš znovu, nebo alespoň přepíšeš. Co na tom, že jsi se chtěl věnovat Ruby a vylepšit ho, my jsme rozhodli, že svůj čas budeš věnovat minimalizaci škod po změně našeho Céčka a basta.".

"Matz na jedne z minulych konferenci zahlasil, ze si dovede predstavit, ze tu vedle sebe budou koexistovat dve implementace Ruby - 1.8ckova a nova, 1.9."

Já si taky dokážu představit, že jsem naftový magnát, mám plný harém asi tak pětistovky nejnádhernějších, po mě toužících žen a plavu v pohádkovém bohatství a topím se ve zlatě a všichni mě budou mít rádi. A taky to klidně někde veřejně prohlásím. Něco prohlásit nic nestojí.

"A mohou koexistovat vlastne libovolne dlouho, protoze, na coz zapominate, je tu i komunita."

Ano? Opravdu? A myslíte, že všichni vývojáři Ruby, všichni autoři knihovne pro Ruby a další svorně do jednoho budou ještě mnoho let poté poctivě psát od všech svých knihoven a nástrojů dvě verze - pro starší a pro novější? V praxi se tohle ještě nikomu nepodařilo, ale teorie je to hezká.

"pokud sleduji vyvoj daneho jazyka (vcetne jeho konkurentu, a pokud si navic treba sam zkusim nejaky jazyk, cvicne, nadesignovat), mohu si vytvorit dojem o zmenach, ktere bude jeho autor, po konzultaci s komunitou, chtit uskutecnit."

Ano a pokud autor dá záruku, že bude držet zpětnou kompatibilitu, mohu si naprosto ušetřit čas sledováním záškodnických akcí autora jazyka a namísto toho naprogramovat v ušetřeném čase lepší program, případně jej strávit s přáteli, láskami, nebo si jít zalyžovat do Alp.

"Ruby pro Javu konkurentem zcela jiste je, at se vam to libi nebo nebo. Sice nikde netvrdim, ze v pripade treba prave onech bankovnich aplikaci, ale treba v pripade webovych aplikaci zcela urcite."

Mě se nemá co líbit, všimněte si, že jsem tu nikde neuvedl jaký jazyk je "nejlepší", protože takový není. Mě je to jedno. Prostě Ruby kromě webu nic moc :-(

"ze Vy si tak trochu delate srandu, nebo umyslne provokujete s tou Vasi argumentaci ("cely ten odstavec o ...jazycích s neseriózním jednáním")? Prece tomu, jak funguje open source rozumite, ne?"

Nedělám si srandu a open source s tím nemá co do činění. Navíc je rozdíl mezi tím "jak open source funguje" a mezi "propagačními letáky od zastánců open source, jak by si přáli aby to fungovalo".

Jinak open source jsou prostě otevřené zdrojáky, nic víc a nic míň. Stále i u open source platí naprosto vše jako pro jakýkoli jiný způsob programování, jsou tam potřeba stejné znalosti, stejné algoritmy. Nic open source nemění.

:-)

cas usetrite predevsim diky tomu, ze budete programovat (== psat udrzovatelny kod; a ano v dynamickych jazycich samozrejme lze psat udrzovatelny kod) ve 'vysokourovnovem', dynamickem jazyce, a ne v jazyce, ktery je zjednodusemym, vycistenmym C++. Tech par veceru, ktere clovek stravi studiem (novych jazyku) za to urcite stoji.

"...záškodnických akcí autora jazyka..." ? Znovu opakuji, kdybyste sledoval vyvoji onech tzv. dynamickych jazyku v poslednich par letech, muselo by Vam byt jasne, ze ony jazyky opravdu dospivaji a ze do budoucna zadne "zaskodnicke akce autoru" nelze ocekavat, uz proto ze ony jazyky se velice pravdepodobne budou dale rozsirovat, takze bude tlak na jejich stabilitu, atd.

takze znovu - v soucasnosti se v oblasti dynamickych jazyku deje "neco velkeho" a urcite stoji za to minimalne sledovat, co se z toho vyvrbi

a open source neni jenom o otevrenych zdrojacich, ale i o komunite - komunite, v jejimz zajmu rozhodne nejsou NEUSTALE zpetne nekompatibilni zmeny

"cas usetrite predevsim diky tomu, ze budete programovat (== psat udrzovatelny kod; a ano v dynamickych jazycich samozrejme lze psat udrzovatelny kod) ve 'vysokourovnovem', dynamickem jazyce"

No jak kdy. Při psaní driverů operačního systému mi moc "vysokoúrovňový dynamický jazyk" nepomůže, ba se odvážně dovolím napsat, že tam bude přímo škodit. Stejně tak kodek do videa bych v Ruby moc nerad viděl. A psát počítačovou hru, která se bude snažit ohromit super grafickou a maximalizovat fps - v tom bych taky "vysokoúrovňový dynamický jazyk" neviděl jako správnou volbu. Matematický program se složitými výpočty řešící praktickou úlohu po mnoho hodin času také přepisem do "vysokoúrovňového dynamického jazyka" nijak nezlepšíte, pokud jste tedy nechtěl získat více času pro svačinu a čekání. Stejně tak třeba jádro databázového systému, třeba Oracle asi žádná rozumná firma, která není na hlavu padlá do "vysokoúrovňového dynamického jazyka" nebude přepisovat.

Jinak udržovatelnost je zcela odlišná od pojmu "vysokoúrovňový dynamický jazyk" - a lze napsat naprosto perkektně udržovatelný program v jakékoli jazyce. A stejně tak prasečinu, kterou nepochopí ani sám autor lze napsat v čemkoliv, Ruby nevyjímaje.

"Znovu opakuji, kdybyste sledoval vyvoji onech tzv. dynamickych jazyku v poslednich par letech, muselo by Vam byt jasne, ze ony jazyky opravdu dospivaji"

Jak víte, že nesleduji? Já jsem v dynamickém vysokoúroňovém jazyce programoval dvacet let před Vámi!! Pro Vaší informaci, LISP a Smalltalk, který jsem honil, jsou velmi vysokoúrovňové a velmi dynamické! Koneckonců Ruby není nic jiného, než slabší odvar Smalltlaku, ze kterého byla spousta čistých věcí zaprasena Perlem.

Jeslti si myslíte, že dynamické jazyky jsou trend posledních pár let, tak doporučuji se probrat.

Mimochodem, třeba LISP je plně multiplatformní a plně standardizován se zárukou seriózní neměnnosti kódu a to už po hezkou řádku desítek let!!! LISP jde dokonce přímo zkompilovat do strojáku, pokud ho nechcete honit na virtuální mašině!!!

"a ze do budoucna zadne "zaskodnicke akce autoru" nelze ocekavat, uz proto ze ony jazyky se velice pravdepodobne budou dale rozsirovat, takze bude tlak na jejich stabilitu, atd."

Jak jsem výše, vzhledem k tomu, že dynamické vysokoúrovňové jazyky tu máme od roku 1958 (tedy příští rok to bude rovných 50 let) - tak Vaše záruky zní dost nevěrohodně.

"takze znovu - v soucasnosti se v oblasti dynamickych jazyku deje "neco velkeho" a urcite stoji za to minimalne sledovat, co se z toho vyvrbi"

Přes Vaše přání se nic velkého neděje.

"a open source neni jenom o otevrenych zdrojacich, ale i o komunite - komunite, v jejimz zajmu rozhodne nejsou NEUSTALE zpetne nekompatibilni zmeny"

Přesto jak vidíte se dějou zpětně nekompatibilní změny, a nejen dějí, ony se i plánují. Mě už tahle propaganda, kdy se o open source něco jiného píše, a něco jiného se dělá ani nebaví.

ze mam na mysli programovani aplikaci, a ne treba programovani driveru, jsem ve svem poslednim prispevku nenapsal, protoze jsem predpokladal, ze vam to vzhledem ke kontextu cele nasi diskuse dojde. Na nutnost rozlisovani aplikacniho a systemoveho programovani koneckoncu poukazuji hned v nekterem ze svych prvnich prispevku

LISP se IMHO nikdo moc neprosadil kvuli te svoji podivne zavorkovaci synaxi (ktera je desna) plus mozna dalsi veci, ktere tu ted nechci rozebirat. Smalltalk zase nemel nadeji kvuli tomu, ze mel moc velke oci (chtel byt celym operacnim systemem). Ruby, ktere je smalltalku podobny, se prosazuje a IMHO prosadi prave proto, ze kod v Ruby je mozne zapsat normalne do stareho dobreho souboru, a k jeho zapsani nepotrebujete nic vic nez nejaky normalni, multifukcni editor. Takze dynamicke jazyky se v minulosti ani nemohly prosadit - vedle nedostatecne vykonneho hardwaru i proto, ze proste nebyly dost dobre (pro prumerneho programatora)

nevim, jak Perl zasira Ruby. Jestli mate na mysli ty globalni dolarove promenne, tak ty se moc nepouzivaji

a jestli Ruby dorazil i ke me - donedavna naproste lame a amaterovi (to uz si myslim, ze neplati :)) - tak to uz je co rict

nazor, ze az ted se dynamicke jazyky zacinaji pomalu ale jiste prosazovat rozhodne vice, nez tomu bylo v minulosti, sice je mym subjektivnim nazorem, ale to neznamena, ze nemuze odpovidat skutecnosti

tou skutecnsti je treba Ruby on Rails, Mongrel, Ruby 1.9, i ten Rubinius, podpora Ruby od Sunu (netbeans), rubyforge, atd. A konkurence urcite take nespi.

[15] Otazka v tomto pripade asi znie: co je to dlhodoby projekt ? Ja by som navrhol 10 rokov ako minimalnu hranicu.

Pri dlhodobom projekte je prioritou maintainovatelnost, nie rychlost prvotnej implementacie. Staci si pozriet konkretne statistiky, ze kolko $ ide do udrziavania starych projektov a kolko na vyvoj v pripade velkych a dlhodobych projektov.

Ake zmeny a nekompatibility priniesol napr. Python za 10 rokov ? Ruby ? Uz len zmena z 1.6 na 1.8 vyziadala znovu zasah do .rb (skoro som napisal 'zdrojakov', ale zase by sa strhol flejm, ze .rb su 'len skripty' :-P )

PS: Rubinius ma zaujal uz v minulosti, ale napriek tomu ho pokladam za akademicku hracku.

[23]
jak velky ten zasah byl, kolika zmen se tykal, jak slozite bylo ty zmeny provest?

Milý pán Ponkrác (alias LO?):

[18]
1) "Spuštění unit testů není, nebyla a nikdy nebude záruka bezchybnosti programu. [...]" O tom žádná. Na to obecne nestačí ani model checking (Gődelova/Riceova veta, halting problem). To skôr vyžaduje "osvietenie" jak písať dobré testy.

2) Udržovateľnosť je rozhodne dôležitá. Napriek tomu, pri C/C++ to neni o moc ružovejšie (oproti Perl/Python/Ruby). Koľko prekladačov dodržuje C99 normu (napriek nejednoznačnos­tiam)? Snáď ani jeden. V tomto je msvc horšie než gcc/icc (plus nás čaká ďalšia C norma, ktorú ešte AFAIK žiadny prekladač neimplementuje). Tak pri prechode na novší prekladač sa rozbijú veci, ktoré "náhodou" (napriek nesprávnosti/ne­jednoznačnosti) fungovali na starších prekladačoch, gcc >=4.1 sú v tomto o dosť striktnejšie (dalo by sa povedať, že je to chyba programátora, ale keď ide o nejednoznačnosť normy, tak koho je to chyba?).

Spätná kompatibilita je dobrá vec, ale "there is no such thing as a free lunch". Napr. MS, Intel kvôli tomu museli dosť obetovať. Občas je lepšie zmeniť normu - BTW u MS samozrejme nemáte žiadnu záruku že to napr. u .NET normu nezmení. Na druhej strane, ako tu už niekto spomínal, je možné (možno dokonca bežné?) udržovať dve vetvy softwaru (pr. Linux kernel 2.4, 2.6), to platí aj u komerčného SW. U jazykov typu Python/Ruby nič nebráni používať staršiu veziu alebo udržovať dve verzie/zaplatiť za udržovanie verzie (komerčný prístup, spomínate?)

PS k inému postu: vyvíjame už niekoľko rokov multiplatformný soft (Linux/win), overhead je cca 5-10% oproti single-platform. Na druhej strane sa šetrí tým, že každý môže používať svoje obľúbené nástroje. Naviac sme empiricky zistili, že to, čo sa preloží a funguje na Linuxe opatchovanom s grsecurity a inými hardened patchami, takmer na 100% funguje aj na win (inak je najskôr problém s msvc alebo bug vo vendor library).

Pro ty, co se hadaji o konkurenci Java vs. Ruby - u velkych systemu/projektu (desitky a vice MKc) jsou naklady na "samotne programovani" nekde v radu 20-30%. Takze i kdyz dokazu v Ruby psat 2x efektivneji nez v Jave (coz dost pochybuju), tak zlevnim projekt z (napr.) 10 MKc na 8.5 MKc pri neumernem narustu rizika (zcela novy programovaci jazyk, malo zkusenych programatoru, chybi ruzne analyticke nastroje, musim prepsat svoje existujici frameworky apod. apod.)

[1] +1

[8] Nemáte pravdu, PyPy se nesnaží o JIT (ačkoliv je JIT pro PyPy k dispozici). Cíle projektu jsou poněkud jiné. PyPy je implementace Pythonu v Pythonu (respektive v RPythonu) určená k snadné portaci a "experimentům" s jazykem (existuje řada rozšíření a modifikací, např. implementace řetězců jako "ropes", taint object space, skutečný sandbox, již zmíněný JIT apod.). PyPy primárně běží nad CPythonem, ale je schopný sám sebe (nebo libovolný kód v RPythonu) emitovat i pro jiné implementace nebo platformy (existuje např. emitor pro .NET, Javu, JavaScript apod.). Např. takový PyPy emitovaný pro .NET je rychlostně srovnatelný s CPythonem nebo IronPythonem.

No, já snad jen dodám:
1./ Ruby už takhle je dost pomalý. Přechod na SmallTalk VM ho ještě zpomalý.
2./ Věta o nefunkčnosti Ruby on Rails mi připoměla opakované zvolání "neznámého idiota" na abclinuxu při každé nové verzi VINE: zase v tom nejdou Bulánci:(

[21]: "Mimochodem, třeba LISP je plně multiplatformní a plně standardizován se zárukou seriózní neměnnosti kódu a to už po hezkou řádku desítek let!!! LISP jde dokonce přímo zkompilovat do strojáku, pokud ho nechcete honit na virtuální mašině!!!"

Pokud vím, jediná existující implementace, která nekompiluje do strojového kódu, je CLISP, a i ta je o něco rychlejší než třeba Python - autor je Cčkovský mág (o tom, jestli to je dobře, nebo špatně, radši nediskutovat - já ten kód moc nepřečtu, bohužel) a vymyslel velmi kompaktní bytekód, co moc nezacpává I-cache. (Celý Common Lisp plus pár extenzí se v něm vejde do image o velikosi ~2MB).

[22]: "LISP se IMHO nikdo moc neprosadil kvuli te svoji podivne zavorkovaci synaxi (ktera je desna) plus mozna dalsi veci, ktere tu ted nechci rozebirat."

Tak tak, radši to nerozebírej, Lisp syntaxi nemá, přestože ji umožňuje napsat. :-) (I takové pokusy tu byly...)

"Takze dynamicke jazyky se v minulosti ani nemohly prosadit - vedle nedostatecne vykonneho hardwaru i proto, ze proste nebyly dost dobre (pro prumerneho programatora)"

Spíš myslím, že průměrný programátor není dost dobrý pro pokročilé programovací jazyky. ;-)

"nevim, jak Perl zasira Ruby. Jestli mate na mysli ty globalni dolarove promenne, tak ty se moc nepouzivaji"

Spíš je škoda, že nemají sémantiku speciálních promenných v Lispu. Sice se to dá asi (zčásti!) dopsat uzávěrem, ale z hlavy si nevybavím, jestli Ruby má něco jako unwind-protect (tu bude ten háček...).