David Majda se ve své prezentaci o alternativních implementacích Ruby ptá, kdy bude některá z alternativních implementací tak silná, že se odváží být s MRI nekompatibilní. Zdá se, že tento okamžik nadešel – Rubinius definuje metodu Fixnum#/, tedy dělení tak, že výsledkem dělení je vždy objekt třídy Float, reálné číslo. Dle Evana budou další metody následovat. Začíná to být zajímavé …
Je dobře, že se Rubinius odchyluje od kompatibility s MRI?
Podle mě je každé takové rozštěpení dost nebezpečné. Někdy to vyjde a lidé si vyberou rozumnější implementaci (X.org vs XFree86), ale jindy je z toho jen roztrhnutí trhu (Compiz, Beryl) nebo složitá a nepřehledná situace (například štěpení některých window managerů).
[1]: osobne se take trochu bojim. Jiste to ma sva pozitiva, a sam bych to v nekterych ohledech udelal, ale kdyz vezmu v potaz stav nekterych programovacich jazyku, ktere prave takto diverzifikovaly, tak bych byl spise opatrny. Nevim, zda zrovna deleni je tak nutne resit jinak, zda to Evan povazuje za tak dulezity problem. Druha vec je, ze pokud Rubinius nahradi MRI, tak bude reseni Rubiniu patrne vzano za vychozi ...
Uááá, chápal bych spoustu věcí, ale podíl dvou celých čísel má přeci být buď celé číslo, nebo zlomek, ne? Obávám se, že tohle Lisp a Scheme a jiné jazyky z "přirozenou aritmetikou" nejenže vychytaly líp než i MRI, ale Evansův krok je krok stranou, nikoli krok vpřed.
? (/ 10 2)
5
? (/ 10 3)
10/3
BTW, není to tu příliš intuitivní, proč blogy nemají totéž vstupní rozhraní jako samotný Root? Že bych si vybral XHTML a měl jistotu, že mi to RS nerozhází. :-]
ohlasy na tuto investici byly celkem pozitivni, ovsem je tu jedno ale:
"In discussing the benefits of taking VC money at this time, Engine Yard CEO Lance emphasized the fact that unlike hosting, Rubinius development is a longer-term play, which along with Merb may eventually become part of a commercially-available technology stack."
tedy EY sponzoruje vyvoj Rubinia nejenom kvuli svemu good will, ale i proto, ze chce z Rubinia udelat "part of a commercially-available technology stack"
v teto souvislosti se mi zavadeni nekompatibilit do Rubinia moc nezda...
nehlede na to, ze Rubinius bude vzdy narocnejsi na systemove prostredky (hlavne RAM) nez ciste ceckova implementace (coz muze byt pro spolecnosti typu EY vyhodnejsi, protoze si mohou uctovat vyssi castky, jelikoz potrebuji drazsi hw)
jina zajimava zprava je, ze Rails 2.1 uz maji bezet na Ruby 1.9 (link bohuzel nemam)
tak uvidime, kazde implementaci Ruby z principu fandim, ale bych byl opatrny...
Mám pocit, že jsi to špatně pochopil. V tom Evanově blogpostu se píše o tom, že jedna z knihoven (mathn.rb), která je mezi knihovnami bundlovanými s MRI, předefinovává operaci dělení tak, že nevrací celé číslo. Jde nejspíš o tyto řádky:
class Fixnum
alias / quo
end
Problém s Rubiniem je ten, že interně předpokládá "rozumné" chování Fixnumu a takováhle definice ho zmate, vzhledem k tomu, že ovlivní i jeho vnitřnosti, napsané ve stejném Ruby jako uživatelský kód.
Nic v tom postu nenaznačuje, že by Rubinius tuhle definici dělení zavedl jako standardní. K jejímu aplikování je potřeba napsat "require 'mathn'", funguje to tedy úplně stejně jako v MRI.
Jinak řečeno, post neříká "předefinováváme definici dělení celých čísel", ale "když si někdo usmyslí předefinovat dělení celých čísel (nebo udělá nějakou jinou obdobnou opičárnu), náš runtime se s tím v tuto chvíli nesrovná a něco s tím do budoucna budeme muset udělat".
ČLÁNKY DO MAILU