Kurcze … przecież w Railsach można używac gettext … Koleś trochę przesadza:
Co o tym sądzicie?
pozdr
Zasadniczo ma racje …
Unicode jest skopane w ruby (chyba 2.0 ma to naprawic). Opsluga unicode itd. powinna byc wbudowana w jezyk a nie jakies dodatk. biblioteki.
10x to bzdura, ale 2x jest blizsze prawdzie i jest to b. dobry wynik! Oczywiscie w niekt. sytuacjach Rails nie jest zadna opcja, tak jak w innych uzycie serwera aplikacji i jsf/ejb3 jest czystym kretynstwem.
Ta prezentacja z NetBeans to zadna nowosc bo w javie od dawna ide/frameworki generuja cale fragm. kodu aplikacji wrecz z UML-a (AndroMDA).
Lepiej wyglada np. Trails czy RIFE i RIFE/Crud gdzie interfejs adm. crud jest gen. dynamicznie. Dodatkowo uwzglednia asocjacje!
RIFE ma tez kontynuacje!
Niestety niekt. developerzy java maja zwyczaj pogardzania innymi technologiami bo w glowach im sie nie miesci, ze to na co oni wlozyli 1.5 roku z nosem w ksiazkach jest w stanie wykonac zoltodziob z 2 mies. doswiadczeniem i to czesto w krotszym czasie.
Art czlowieka, ktory godzine posiedzial przy tutorialu. Troche powagi 
Co do przyspieszenia 10x to moze przesada ale gdy wezmiemy osobe znajace narzedzia na takim samym poziomie to 2x to moim zdaniem troche malo (choc porownuje tu doswiadczenia z PHP).
Troche OT. Wiesz kiedy doceniłem Rubiego (uwaga - Rubiego, nie Rails) ? Podczas pisania pewnego serwera (jak ktoś chce poznać szczegóły zapraszam na moją stronę). Pisząc tylko w oparciu o RubyOnRails nie wydobywasz większości “smaczków” na które pozwala Ruby. Oczywiście pominę łatwość refaktoringu kodu w Ruby (nie wiem jak to wygląda w Javie - opowie ktoś ?).
Więc rzeczywiście po tutorialu ciężko coś stwierdzić.
to opowiadam… moje doświadcznia wskazują iż niemal jedyną słabością developerki w Ruby (ale także innych dynamicznych jezyków - no może poza Smalltalkiem gdzie refactoring się narodził) jest własnie słabe wsparcie refactoringu przez narzędzia. Java jest statycznie typowana - co powoduje, że dużo prościej jest zrealizować narzędzia refactorujące. Dziś praktycznie każde IDE do Javy ma moduł refactoringu - to jest rzeczywiście ekstremalnie przydatne narzędzie - szczególnie jeżeli rozmiary projektu przekroczą graniczna ilość kodu albo zaangażowanych developerów.
Temat refactoringu pojawiał sie tu i ówdzie w ciagu ostatnich kilku miesięcy, niestety zadanie nie jest proste do realizacji (w porównaniu np. do Javy), więc chyba niestety troche jeszcze przyjdzie nam poczekać na narzędzia wspomagające refactoring o opcjach porównywalnych do tych znanych z Javy 
Dodam na koniec, że Refactoring Browser stworzony w Smalltalku dla Smalltalka ndal jest bardziej zaawansowany od tych znanych z Javy, wiec jak widać jest nadzieja … dopisałem to zdanie żeby nie kończyć zbyt pesymistycznie
Moim zdaniem Ruby ma w tym temacie jedna przewage: tzw ruby-way w jakis sposob wymusza DRY (a Rails zdecydowanie) we ksiazkach, tutorialach, przykladach klada na to nacisk i czlowiek w trakcie tworzenia wie, ze cos “jest nie tak” i po chwili zastanowienia to poprawia.
Nie wiem jak to dokladnie opisac ale odnosze wlasnie takie wrazenie.
Do tego wierzylbym w jakosc programistow a nie narzedzi do poprawiania po nich pracy.
[quote=Adamh]Moim zdaniem Ruby ma w tym temacie jedna przewage: tzw ruby-way w jakis sposob wymusza DRY (a Rails zdecydowanie) we ksiazkach, tutorialach, przykladach klada na to nacisk i czlowiek w trakcie tworzenia wie, ze cos “jest nie tak” i po chwili zastanowienia to poprawia.
Nie wiem jak to dokladnie opisac ale odnosze wlasnie takie wrazenie.
Do tego wierzylbym w jakosc programistow a nie narzedzi do poprawiania po nich pracy.[/quote]
Zgadzam sie z Tobą, z dwoma uwagami:
-
miękkie zasady są super w małym i zgranym zespole o w miare wyrównanym poziomie, jeżeli jednak np pojawia się ktoś nowy to zanim dobije do poziomu jego kod nie bedzie takiej jakości - wiec refactoring narzedziowy nie ‘mentalny’
bedzie konieczny (inna sprawa ze jak sie napisze te swoje 200 tysięcy lini kodu to zasady stosuje sie już nieświadomie). oczywiscie całe ruby-way jest jak najbardziej istotne niezależnie od narzędzi czy wielkości zespołu… -
refactoring bardzo często jest podyktowany nie tyle wrażeniem estetycznym zwiazanym z wyprodukowanym kodem ale np ze zmianą warunków zewnętrznych które wpływają na działanie tworzonego kodu - wówczas metoda znajdz zamień (czyli refactoring jaki mamy dzis) bywa ułomna…
Przewage Ruby’ego w tym kontekście upatruję w ilości kodu jaki jest potrzebny do realizacji danego zadania - mało kodu to i znajdz i zamien wystarczy.
Co do jakości programistów to dobre narzędzia + dobrzy programiści to jest dopiero prawdziwe TNT