Komentarz do konferencji Snakes & Rubies
Posted by Jarosław Zabiełło Thu, 19 Jan 2006 20:08:00 GMT
DHH, twórca Ruby on Rails w swoim blogu opisał różnicę między Django i RoR Generalnie podsumował swoje stanowisko, które wyraził na konferencji. Szkoda, że Adrian (ani nikt z developerów Django) nie napisał w swoim blogu żadnego komentarza. :(
Pod artykułem DHH jest sporo ciekawych komentarzy. Warto je poczytać.
Generalnie DHH został zaatakowany za niedocenianie roli umiędzynarodowienia RoR. Ludzie tego potrzebują i dobrze by było aby do RoR zostało dodane i18n. Jest kilka gotowych modułów, które do tego celu się nadają, np. Globalize (Być może DHH powstrzymuje wdrożenie i18n z powodu słabej implementacji UTF-8 (Unicode w ogólności) w Ruby? W przeciwieństwie do Rubiego Python ma wzorcową obsługę Unicode, więc wszelkie konwersje znaków nie są żadnym problemem.) Oczywiście nie ma nawet co mówić o kompletnie nędznym supporcie Unicode i UTF-8 w PHP gdzie nie ma nawet jak przeprowadzić konwersji z latin2 do utf8 a podpieranie się kulawym modułem iconv tylko ucina teksty w wypadku znaku który nie da się poddać konwersji. Ale co ja będę kopał leżącego… ;)
Nie mogłem się powstrzymać ;) i dodałem także swój komentarz do tego tekstu i w ogóle do kwestii rzekomej wyższości Rubiego nad Pythonem. Wiekszość osób które wpisały się do blogu Davida najwyraźniej ma mikre pojęcie o Pythonie. To prawda, że Ruby ma kilka cech lepszych od Pythona, ale prawdą jest także że Python posiada kilka cech lepszych od Rubiego. Postaram się później to jakoś podsumować w oddzielnym tekście.


Kanały IRC![[Dilber w Onecie]](/images/larry.png)


Rails nie ma wspierać UTF, to jest kwestia platformy/interpretera/YARV. Dlatego wszyscy czekają na Ruby 2.0 no i oczywiście na YARV, gdzie również zniknie problem wątków (ruby ma własną implementację, dlatego wątki działają nawet pod dosem – niestety to jest wada). Nie będzie wtedy problemu z global interpreter lock (który jest w Pythonie niestety) będą fine grained threads.
No to pewnie poczekamy całe wieki zanim będzie zarówno Ruby 2 jak i jego wirtualna maszyna coś powoli się rozwija. Python już od dawna ma bytecode, ale rozumiem, że YARV ma być chyba czymś więcej. Tylko nie wiadomo kiedy powstanie i jakiej jakości będzie. (Java ma dobrze zaimplementowaną, wydajną JVM bo wpompowano w to miliony dolarów.)
Jest też inny projekt: Parrot. Też jest tworzony od dawna i końca nie widać. Może przesadzili z ilością docelowych języków które ma obsługiwać… No i nie wiadomo co będzie ze wsteczną kompatybilnością Rubiego 2, bo np. mają chyba wylecieć klasy otwarte. Matz przyznaje że są zbyt niebezpieczne.
Co do Unicode, to mogliby po prostu to dorze zaimplementować w Rubym i już. Jest duże ciśnieni ze strony społeczności międzynarodowej aby to porządnie zrobiono i aby RoR w końcu miał i18n.
Nie inaczej. Wspomnę tylko że java jest maszyną stosową i trudniej w takich zaimplpementować wydajne domknięcia (można sie odwołać tylko do zmiennych lokalnych final w klas anonimowych) Parrot i YARV (później RITE) są rejestrowe (Cardinal upadł). Mimo wszystko YARV jakoś się tam rozwija (przykłady z head 1.9 działają), może będzie w następnym roku :(.
W PHP6 będzie pełne wsparcia dla Unicode, jednak developerzy zostawiają sobie furtkę umożliwiającą włączenie/wyłączenie wsparcia ponieważ nagłe dodanie supportu spowoduje spowolnienie funkcji (z tego co piszą niektóre nawet do 300%) a całe aplikacje do około 25%.
Python jest jednak mniej dostępny na serwerach providerów, a Ruby już się tu i tam pojawia.