Mity na temat Rubiego
70 komentarzy | Kategorie: Ruby, Techblog | trackbackTagi: myths ruby
Język Ruby i różne rozwiązanie mu towarzyszące (np. Ruby on Rails) istnieją już na tyle długo, by dorobić się wielu opinii, sądów i zdań na jego temat. Zarówno tych pozytywnych jak i negatywnych. Sprawa jest o tyle niewygodna, gdyż wiele z nich to na dzień dzisiejszy po prostu mity. Dziś zajmę się nimi. Mity zwykle nie są łatwe do obalenia, ale postaram się sprostać postawionemu zadaniu.
Oto kilka, według mnie mitów, nieprawdziwych opinii, które wciąż powtarzane są w wypowiedziach różnych ludzi:
1. Ruby jest wolny
To chyba jeden z częstszych zarzutów. Jest to bardzo delikatna kwestia. Programiści lubią się pokłócić, że to ich 'język' jest najszybszy. Wymyślają przeróżne, często specyficzne benchmarki, które mają udowodnić kto jest najszybszy. Nie chcę podawać takich śmiesznych przykładów, bo to się mija z celem. Dla mnie sprawa jest oczywista. Jeśli wybieram język Ruby, który z jednej strony daje mi niesamowite konstrukcje językowe, pełną obiektowość, dynamizm, domknięcia oraz wiele innych elementów, to jasne jest, że nie ma nic za darmo (i często płaci się utratą wydajności). Jeśli dla Ciebie kluczowym czynnikiem jest wydajność - patrzysz w złą stronę przyjacielu. Potrzebujesz prawdopodobnie C, C++ lub Java, a więc języki typowane statycznie, kompilowane. Języki takie jak Python, Php, Perl a także i Ruby to inna kategoria. Programy w nich działają przeważnie 10-100 razy wolniej niż w tych wcześniej wymienionych. No tak, a jakby porównać języki Python, Perl, Ruby, Php? W końcu to języki o podobnych założeniach (interpretowane, dynamiczne). Bardzo proszę, nie mamy nic do ukrycia i czego się wstydzić:
Ruby vs Python
Ruby vs PHP
Ruby vs Perl
Jak widać Ruby jest trochę wolniejszy od pozostałej trójki. A co powiesz jeśli najnowsza wersje Rubiego (1.9) będzie około 3-4 razy szybsza od poprzedniej? Nie wierzysz?
Ruby 1.9 vs Python
Ruby 1.9 vs PHP
Ruby 1.9 vs Ruby
Benchmarki pokazują, że nowe wersje Rubiego są tak samo szybkie jak pozostałe z wymienionych, a wierzcie mi, że na tym nie koniec. Czy ciągle uważasz, że Ruby jest wolny?
Jednakże należy te kwestie traktować bardzo uważnie. Szybkość implementacji języka to często drugorzędna kwestia. Najczęściej prędkość aplikacji (powiedzmy webowej) zależy także od bazy, połączenia internetowego, użytych algorytmów, mechanizmów cachowania. Prędkości procesorów w ostatnich latach nie idą tak w górę jak dawniej (prawo Moora przestało działać), jednak wciąż rosną. Czy zatem 5 lat temu nie warto było użyć PHP bo procesory były X razy wolniejsze (a więc i sam PHP)? Czy jeśli nagle PHP stanie się 5 razy szybsze od Pythona to porzucisz go dla tego języka? Czy kupując samochód kierujesz się tylko kwestiami prędkości i jadąc wolniejszym samochodem od jakiegoś innego czujesz się z tym źle? Dlaczego nie programujemy w asemblerze swoich aplikacji?
Odpowiedź jest jedna: dopóki prędkość nie jest najważniejszym czynnikiem, a prędkość samej implementacji języka nie odstaje aż tak bardzo od pozostałych, to nie jest ona aż tak istotna. Najczęściej właśnie liczy się to jak się w danym języku pisze, czytelność kodu (tu także jest ważny język), rozszerzalność, łatwość utrzymania kodu. Ruby ma tą dodatkową cechę, że bardzo łatwo pisze się w nim rozszerzenia w C. Jeśli masz jakiś szczególny algorytm, strukturę danych, wąskie gardło, które powstrzymują Cię przed napisaniem tego w Rubym to możesz napisać to w C i powiązać z Rubym. Wierzcie mi, że w tej kwestii Ruby także jest po prostu świetny.
2. Ruby nie nadaje się do pisania w większej grupie programistów, gdyż pozwala np na dodawanie nowych elementów do istniejących klas, redefinicję istniejących metod, przedefiniowanie operatorów +, - dla liczb oraz inne równie niebezpieczne operacje!
To jedna z cech odróżniające Rubiego od innych języków. Jedni twierdzą, że to jest fajne, użyteczne, inni zaś, że to kompletna głupota. Ci pierwsi widzą miejsca, gdzie można to efektownie zastosować, Ci drudzy ciągle powtarzają jakie to jest "bee". Pozwólcie, że użyję porównania (bardzo je lubię :)). Każdy z nas ma w domu nóż. Nóż to tylko narzędzie, możesz nim pokroić chleb, albo zabić bliźniego. Wybór należy do Ciebie. Jeśli jesteś człowiekiem myślącym, prawdopodobnie poprzestaniesz na tym pierwszym. Jeśli jednak coś jest z Tobą nie tak i chcesz kogoś zabić, to prawdopodobnie nie pomoże nawet schowanie wszystkich noży (bo zrobisz to młotkiem). Czyli przekładając to na nasz język. Ruby daje Ci wiele różnych ciekawych możliwości, ale to od Ciebie zależy do czego użyjesz. Nikt nie każe Ci przedefiniować metody Fixnum#+ tak aby zwracała wynik mnożenia... (jeśli jednak tego chcesz - proszę bardzo).
Gdy programujesz w grupie musisz mieć zaufanie do swoich kolegów. Czy to zaufanie będzie większe, gdy język będzie zabraniać co popadnie? Komu miałoby służyć takie ograniczanie? Tym lepszym programistom, czy tym gorszym? Profesjonaliści pracują tylko ostrymi nożami, gdyż tylko one pozwalają im uzyskać pożądany efekt szybko i sprawnie. Pozostali używają tych tępych, które nie zrobią im krzywdy, ale by pokroić zwykły chleb będą musieli się sporo namęczyć...
3. Kod Rubiego jest podobny do Perla ("tego się nie da czytać!")
Z tym stwierdzeniem spotykam się niestety bardzo często. Jest takie powiedzenie "You can write FORTRAN in any language". Gdzie za FORTRAN możesz tak na prawdę podstawić nazwę dowolnego języka. Matz (twórca języka), wziął najlepsze (według niego) cechy ówcześnie znanych mu i lubianych języków. Stąd między zapożyczenie tzw "perlizmów" (perlism). Pozwala to na pisanie "dziwnego" kodu, czasem przypominającego Perla:
# programista Perla napisałby tak
while gets
if /Ruby/ # nie wiadomo co tu się dzieje, magia?
print # a to co takiego?
end
end
# programista Rubiego zdecydowanie tak
ARGF.each_line do |line|
print line if line.match(/Ruby/) # nie wymaga komentarza
end
Matz chciał by innym programistom łatwiej pisało się w Rubym, stąd te konstrukcje. Dzisiaj jednak nie jest wskazane używać takich konstrukcji, a Ruby zgłasza ostrzeżenia w większości przypadków ich użycia. Widziałem wystarczająco dużo kodu w Ruby i Perlu by jednoznacznie stwierdzić, że dobrze napisany kod tego pierwszego nijak ma się do tego drugiego.
4. Ruby wcale nie jest taki dobry, to Ruby on Rails czyni z niego coś więcej niż kolejny, skryptowy język programowania. Gdyby nie ten framework nikt nie programowałby w Rubym!
To jeden z ulubionych argumentów tych, którzy za wszelką cenę chcą przekonać pozostałych, że Ruby to jakiś przypadkowo stworzony język, a popularność zawdzięcza tylko i wyłącznie Ruby on Rails. Ludzie Ci często poprzestali na obejrzeniu reklamowych screencastów RoR, które pokazują jakie to cuda można z nim wyczyniać. Niestety Panie i Panowie gdyby nie ogromne możliwości języka, RoR nie istniałby. Magia RoR to przede wszystkim magia Rubiego. Przekonali się już Ci, którzy znając RoR, próbowali jego klonów choćby i w PHP. Jak zwykle kończy się na znanym haśle "prawie robi wielką różnicę".
5. Kod Rubiego jest nieczytelny
To podobny zarzut do podobieństwa z Perlem, ale bardziej ogólny. Jeśli tylko chcesz to napiszesz piękny/brzydki kod w każdym języku. Ruby jednak ma tą cechę, że przy pewnej wprawie, bardzo często kieruję programistę (choć często o tym nie wie) do ładnego DSL'a. Ruby to jeden z nielicznych języków, który pozwala Ci na pisanie takiego kodu:
class Project < ActiveRecord::Base
belongs_to :portfolio
has_one :project_manage
has_many :milestones
has_and_belongs_to_many :categories
end
##########################################
# definiowanie stanów obiektów
class User
acts_as_state_machine :initial => :inactive
state :inactive
state :active
state :blocked
event :accept do
transitions :from => :inactive, :to => :active
end
event :block do
transitions :from => :active, :to => :blocked
end
event :unblock do
transitions from => :blocked, :to => :active:
end
end
u = User.new
u.accept! # akceptacja uzytkownika
u.block! # zablokowanie
##########################################
# rake - czyli Ruby make
desc "delete all *.o files"
task :delete_files do
sh "rm *.o"
end
##########################################
# piszesz grę?
class Dragon < Creature
life 1340
strength 451
charisma 1020
weapon 939
end
class Rabbit < Creature
traits :bombs
life 10
strength 2
charisma 44
weapon 4
bombs 3
end
rabbit = Rabbit.new
dragon = Dragon.new
dragon.fight_with!(rabbit)
##########################################
# definicja tabeli SQL
crate_table :users do |t|
t.column :login, :string, :limit => 60
t.column :created_at, :datetime, :null => false
end
##########################################
a = [4, 5, 1, 4, 5, 2, 6, 7, 2, 1, 7, 1]
puts a.uniq.sort #=> [1, 2, 4, 5, 6, 7]
Ciągle twierdzisz, że Ruby jest nieczytelny?
6. Ruby (RoR) nie skaluje się
Ten zarzut może nie jest bezpośrednio kierowany do samego języka, ale bardzo często do Ruby on Rails, a to z kolei rzutuje na sam język. Ileż to ja się naczytałem dyskusji na ten temat. Co ciekawe, jeśli ktoś rozważa kwestię skalowania, to zakładam, że prezentuje pewien poziom wiedzy. A taki człowiek, po wcześniejszym zapoznaniu się ze sposobem działania RoR powinien wiedzieć, że: Ruby (RoR) skaluje się praktycznie w taki sam sposób jak PHP, Java, Python. W wielkim skrócie (chodzi o aplikacje webowe): kilka serwerów aplikacyjnych, memcached dla sesji, load balancer. Ruby i RoR mają tak na prawdę niewiele tu do powiedzenia. Aplikacje skaluje się w bardzo zbliżony sposób, niezależnie od użytego języka (frameworka).
7. Ruby ma mało bibliotek
Rubyforge: Hosted Projects: 4,693. RAA: 1637 projects. Nie chcę przez te liczby powiedzieć, że znajdziesz każdą bibliotekę jaką sobie tylko wymyślisz. Jednakże powinny Ci dać pewien obraz, że nie jest tak źle jak niektórzy mówią. A wiesz, że w Rubym możesz także wykorzystać całe API Javy? Umożliwia to JRuby, czyli implementacja Rubiego w Javie.
8. Ruby nie nadaje się do dużych projektów
To jedna z pierwszych reakcji, zwłaszcza programistów pracujących z "cięższymi" technologiami (j2ee, .net). Gdy słyszą o ciekawych cechach języka (otwarte klasy, duck typing i inne) w pierwszej chwili nawet im się to podoba, a potem przychodzi szybka refleksja. "Jak nad tym da się zapanować? To nie możliwe żeby dało się w tym zrobić duży projekt. Po pierwsze czym jest dla Ciebie duży projekt? Wg mnie 80% projektów jakie zrobisz w życiu są jak najbardziej w zasięgu Rubiego. Zwłaszcza dlatego, że to co jest bardzo dużym projektem w Javie, w Rubym może być tylko średnim. W Rubym piszesz mniej kodu, a więc potrzeba mniej zasobów (szczególnie ludzkich). Bardzo często też ten "jeden duży projekt" w praktyce dzieli się na kilka dosyć niezależnych modułów, które są praktycznie oddzielnymi projektami. Pamiętaj, że zasady gry ciągle się zmieniają. Aplikacje, które dawniej pisało się tygodniami w kilkuosobowej grupie programistów, dzisiaj można napisać samemu w kilka wieczorów (porównaj pisanie aplikacji korzystającej z surowych socketów, a np z Java RMI. W Rubym odpowiednik RMI to DRb, który jest jeszcze prostszy w użyciu).
Z drugiej strony, trzeba wiedzieć, że zawsze jest pewna granica. Języki takie jak C/C++/Java zostały stworzone do pisania dużych systemów i użycie Rubiego w takich projektach nie zawsze jest wskazane.
9. Ruby jest mało popularny, to niszowy język
W Polsce - dopiero dociera do nas fala popularności. W USA, UK i Japonii jest bardzo popularny. W rankingu Tiobe Ruby znów zaliczył skok, tym razem na 9 miejsce (poprzednie 10). Sun i Microsoft zainwestowały w projekty JRuby i IronRuby. Ludzie tacy jak Martin Fowler, Chad Fowler, Bruce Tate i wielu innych znanych ludzi IT programuje w Rubym. Amazon bił rekordy sprzedanych książek o Rubym w 2006 roku w dziale "Programowanie". Nawet nasz polski helion jeszcze rok temu miał w swojej ofercie bodajże 1-2 książki. Teraz jest ich ponad 10.
Jakiego innego dowodu potrzebujesz bo uwierzyć, że Ruby to nie jest niszowy język?
10. Wciąż brakuje narzędzi, a przede wszystkim IDE z prawdziwego zdarzenia dla Rubiego
Oczywiście, że są takie narzędzia! Jednakże porównanie z takimi narzędziami jak Java, .Net nie ma po prostu sensu. To dwa różne światy. Ruby nie potrzebuje dziesiątek narzędzi, które robią za programistę jakieś cuda. Do efektownej pracy z Rubym potrzebujesz przede wszystkim dobrego IDE. Najlepszym według mnie takim środowiskiem dla Rubiego jest Netbeans z modułem do Rubiego. Tor Norbye's, autor tego modułu dokonał niezwykłej rzeczy w przeciągu ostatnich kilku miesięcy. Netbeans nie jest jedynym takim IDE. O kilku innych możesz poczytać na blogu Sabona. O braku porządnego IDE powiedzieć nie można. Oto kilka filmów prezentacyjnych tego środowiska (więcej dostępnych na stronach Netbeans wiki oraz Netbeans.tv):
Tworzenie Webloga używając Netbeans IDE
Praca z edytorem, podpowiadanie nazw metod, klas, zmiennych
Debugowanie aplikacji RoR
Na pewno znalazłyby się kolejne mity, ale te powtarzają się dosyć często. Jestem otwarty na dyskusję. Proszę tylko o kulturę, flame wara nie zamierzam tu prowadzić :). Czekam na Wasze komentarze!
Jeśli spodobał Ci się wpis to może umieścisz ten blog w swoim czytniku RSS?
To biadolenie na temat wydajności to oznaka że ktoś na siłę chce się już do czegoś przyczepić a jaranie się jakimiś bencharkami to oznaka niedojrzałości (programistycznej lub innej :) .
Z resztą wydajność w dzisiejszych czasach kiedy po prostu dokłada się kolejny serwer do szafy nie jest sprawą najistotniejszą. Priorytetem jest szybkość powstawania i jakość kodu.
Jeśli zaś mówimy o pehapowych klonach Railsa to cóż – są ok, ułatwiają znacznie pracę (tam gdzie trzeba użyć PHP), ale nadal są to tylko klony, wolę oryginał :)
Super post, kawal dobrej roboty. Bez zastanowanienia moge odsylac tutaj ludzi rozsylajacych niedokonca sluszne opinie o Ruby. Celne porownanie z nozamia w kuchni, trzeba to puscic w miasto :)
@wijet, o to właśnie chodzi. Dużo jest szumu w okół Rubiego, na pewno w Polsce jesteśmy na etapie „dużo o nim słyszało, ale do końca nie wie co w trawie piszczy”. Wiele opinii, buzzu, a przy tym bardzo dużo mitów. To ciekawe, że programiści innych języków, którzy ledwo usłyszeli o Rubym, mają często bardzo silnie wyrobione zdanie. Dla nich jest ten wpis, bo community Rubiego prawdopodobnie podpisze się pod wszystkimi punktami.
Co do wydajności – to kwestia szybkości rozwoju aplikacji. Internet rozwija się bardzo szybko i mało jest udanych przykładów, gdzie wielkie serwisy powstały w językach stałotypowanych, jak java czy C/C++. Amazon to perl (potem weszła java, równolegle), Facebook to PHP itd. itd.
Języki dynamiczne są po to, by łatwiej wprowadzać zmiany w projektach, wymagają jednak większej samodyscypliny – to jak wolna i bezpieczna jazda autobusem (java,C) a sportowym autem lub motorem (php/perl/ruby/python). Co komu potrzeba.
Normalne jest też, że wąskie gardła programowe w razie potrzeby przepisuje się do C/C++/javy, dużo łatwiej to jednak zrobić mając działający projekt w języku wyższego poziomu.
Witam.
Tekst stara się zachować pozory obiektywizmu, ale niestety widać, że autor postawił sobie cel „pokazać, że Ruby jest super” i pod ten cel pisze artykuł. Brak konkretów. Najczęstrzy wywód prowadzi do stwierdzenia „W prównaniu do innych skryptowych języków tak samo źle/dobrze”.
Nie mam uprzedzeń do Ruby, tylko pytam – jaki będzie zysk mojej „przesiadki” z innych języków skryptowych. Artykuł ten pokazuje, że „nie będę stratny”. Dla mnie to za mało. Zwłaszcza, że inne języki, jako starsze, podparte są większym doświadczeniem/zapleczem.
Ups. Przepraszam za orta w moim komentarzu:(
O, sympatyczny wpis.
Ad 1. Programistów prędkość języka nie obchodzi aż tak bardzo. Benchmarki to specjalność onanistów sprzętowych, którzy nie dostrzegają całego problemu tworzenia oprogramowania.
Ad 2. Co do noża, to… W amerykańskich korporacjach pracownicy są jednym z największych zagrożeń. Większym nawet niż np. szpiegostwo przemysłowe, włamywacze itp. Zabawne, ale prawdziwe.
No i „Ci pierwsi widzą miejsca, gdzie można to efektownie zastosować”. I w tym problem. Efekciarstwo w programowaniu jest równie głupie, jak onanizm benchmarkowy z punktu 1.
Ad 3,4,5,6 – tak to wygląda. Z tym że czytelność kodu to śliski temat, bo dość subiektywny. Czy Ruby ma jakiś przewodni model formatowania kodu, jakiś przyjęty standard branżowy?
Ad 7. W OpenSource liczba bibliotek nie przekłada się na ich dopracowanie czy możliwości. Jeśli np. potrzebuję biblioteki do operowania na EXIF, to znajdę pewnie z 10 projektów na rubyforge. 3 będą skrajnie niestabilne, 3 będą niezłe, ale nie poradzą sobie np. z tagami EXIF wstawianymi przez Canona, dwa będą całkiem całkiem, ale nie będą miały funkcji edytowania tagów, no i tylko jeden będzie obsługiwał od razu IPTC i EXIF w TIFF-ach itp. I jest to wariant optymistyczny ;) Ale jak by nie patrzeć Ruby ma sporo bibliotek do obróbki praktycznie wszystkich podstawowych rzeczy i bindingi do popularnych bibliotek OpenSource.
Ad 8. W wielu językach masz wyrafinowane frameworki które zdejmują z Ciebie ciężar kodowania. Jeśli w Rubym nie znajdziesz akurat równie pomocnego narzędzia (co się często zdarza w dużych projektach), to będziesz klepać kod który w innym języku byś po prostu wziął w postaci jakiejś biblioteki. Faktycznie w Rubym pewna klasa aplikacji będzie dużo prostsza do napisania, niż w innych językach. No ale to wiadomo już od dawna – dobieraj język do zadania. Jeśli mam przetwarzać dużą ilość plików tekstowych, to pewnie skrobnę sobie coś szybko w Perlu czy Pythonie, nie będę się bawił z Javą czy C.
Ad 9. Święta prawda.
Ad 10. „Ruby nie potrzebuje dziesiątek narzędzi, które robią za programistę jakieś cuda”.
Żaden język tego nie potrzebuje. W Javie też mogę pisać przy użyciu choćby Notatnika. Ale nie można zaprzeczyć, że wszystkie te udogodnienia znane z „dużych” środowisk są cholernie przydatne.
Najlepiej to widać w sukcesie ruby’owego modułu do netbeans. Wcześniej zealoci ruby’ego wciskali wszystkim kit, że nie potrzebują w ogóle IDE, bo Ruby to zupełnie inny paradygmat kodowania, że wszystko jest proste i nieskomplikowane (i nagrywali filmiki z kodowania przykładowego webappa CRUD w jakimś prostym edytorze tekstowym). Jeśli kiedyś pojawią się do Ruby’ego automaty potrafiące robić za programistę różne „cuda”, to nagle okaże się, że jednak fajnie jest mieć takie dodatki.
Nie ma czegoś takiego jak „zbyt wiele” wspomagaczy :)
@Felippe, przyznaję, czasem trudno jest pozostać całkowicie obiektywnym. Ale zauważ, że ja nie porównuję Ruby z jakimś konkretnym językiem. Owszem, pojawiły się pewne porównania, ale nie na zasadzie „Ruby ma fajniejsze coś, czego nie ma język X”. Nie mam nic do Perla, PHP czy też Pythona. Tekst nie jest o wywyższaniu Rubiego ponad te języki. A tym bardziej nie ma przekonać Cię do przesiadki na ten język. Przeczytaj go proszę jeszcze raz ;)
@Hopke:
Ad1. Chciałbym żeby takie było zdanie wszystkich programistów, ale niestety tak nie jest. Tak jak programiści mają skłonność do przedwczesnej optymalizacji, tak robią to już na poziomie samego języka.
Ad7. Oczywiście, że ilość nie przekłada się na jakość. Aczkolwiek byłoby dziwne, gdyby wszystkie te projekty (liczone w tysiącach) okazywały się bezużyteczne :). Bardzo dużo pojawia się bindingów bilbiotek z C, gdyż łatwo (relatywnie) się je pisze.
Ad8. Framework jest bardzo ważny. Jednakże często czytam o zarzutach bezpośrednio do Rubiego, że nie bardzo go można użyć do „dużych” (pojęcie bardzo względne) projektów. Niektórzy widzą wykorzystanie go w prostych shellowych skryptach…
Ad10. Narzędzia są ważne, nie zamierzam twierdzić inaczej. Jednakże java, .net w dużej mierze są nastawione na przeróżne narzędzia. Ruby zdecydowanie nie (aczkolwiek dobre narzędzie mu nie zaszkodzi ;)).
Szczerze mówiąc chyba nie, ale widziałem wystarczająco dużo kodu by powiedzieć Ci jak powinno, a jak nie powinno się w nim pisać :).
Mi bardziej pasuje kod pythona, ale do rubiego chyba też się przekonam, argumenty dałeś naprawdę dobre ;)
Pisanie programów GTK w Ruby to coś wspaniałego…
Ten kod jest taki… przyjemny :) .
Ale nie ma IDE typu RAD do tworzenia aplikacji GUI w Rubym :/ .
Livio: a jak się obsługuje gtk+ w rubym? To są zwykłe bindingi, czy może przerobione na obiektowość? A może masz porównanie z gtk pod pythonem…?
BTW, jeśli GUI robisz w GTK+, to chyba postępujesz tak samo jak w każdym innym języku – interfejs wyklikać w Glade, a potem w aplikacji tylko wczytywać opis GUI z XML-a…
Inna sprawa, że projektowanie GUI w RAD ciężko jest dobrze zrobić (sądząc po tym, co do tej pory widziałem w różnych językach). Z jednej strony trzeba mieć klikane „coś” do konstruowania GUI i integrowania tego z kodem, z drugiej strony nic nie powinno się rozjechać jeśli programista coś ręcznie „nagrzebie” w kodzie. NetBeans ma to chyba nieźle zrobione, jeśli dobrze kojarzę, ale całościowo to chyba narzędzia Qt najlepsze wrażenie na mnie robiły.
@marcins: nie ma problemu by umieć oba języki :).
@Livio: chętnie bym dowiedział się coś więcej o tym, gdyż generalnie Ruby z aplikacjami GUI nie stoi za dobrze. Widziałem tylko film pokazujący tworzenie prostej aplikacji Gtk w Rubym. Czy glade, który jest użyty nie podchodzi pod takie proste narzędzie RAD?
#Hoppke: Poszukaj u mnie o Rubym, znajdziesz przykładowy kod.
#Radarek: Glade pozwala stworzyć plik .glade i nic więcej, a narzędzie RAD pozwala w łatwy sposób stworzyć zdarzenie i z GUI przejść do odpowiedniego miejsca w kodzie. Takie pół GUI-pół kod.
@Linio: dlatego użyłem określenia „proste narzędzie RAD” ;). Wydaje mi się, że sytuację (choćby trochę) zmieni JRuby. Możesz sobie wyklikać w Netbeans GUI, a potem logikę dopisać w Rubym. Powstają także biblioteki opakowujące Swing API, które w znaczny sposób ułatwiają pisane ręcznie takich aplikacji.
JRuby? Znaczy miałbym pisać kodem Ruby… ale w Javie?
JRuby to implementacja Rubiego, ale w Javie. Jedną z korzyści jest dostęp do całego API Javy.
Pisałem o tym jakiś czas temu:
http://radarek.jogger.pl/2007/07/12/java-i-ruby-w-jednym-stali-domku/
Nie wiem, czy opłaca mi sie zabawa w Javie, ale NetBeans, Swing – to wszystko brzmi zachęcająco, ale myśl o .jarach, classach itede odstrasza. Naprawdę
Jeśli nie masz za bardzo do czynienia z Javą to nie ma sensu się zmuszać. Siła JRubiego m.in. tkwi w tym, że jeśli ktoś do tej pory zainwestował sporo w Javę to nie rezygnuje ze swojej wiedzy i może ją wykorzystywać w Rubym.
Ja chciałbym zostać programistą, ale nauka tych wszystkich static, void itd. nie podoba mi się...
Livio z czasem prawie nie zwracasz na to uwagi, po prostu samo się pisze ;-)
Jako programista Rails mogę powiedzieć, że pisanie w Rubym jest cholernie wygodne. W tym momencie nie wyobrażam sobie przesiadki na coś innego.
Jednak nawet w najlepszym języku można napisać crap code.
Pisanie w Rubym, wiem, że jest przyjemne, ale ja nie chce się babrać w Rubym w opisywanie całego interfejsu. Tj. kolejno tworzenie i dodawanie komponentów GUI. Tę część i sygnały wolałbym sobie nieco ułatwić.
@Livio, ale to właśnie umożliwia Ci wspomniany glade. Zobacz sobie film video. Nie jest to może dokładnie takie jak Ty chcesz, bo nie masz możliwości podpięciu od razy event handlera, ale nie jest tak źle. Jak dobrze sobie to rozbijesz to nie będzie problemu z przegenerowaniem pliku .glade -> .rb i nadpisywaniem tego co do tej pory napisałeś (kwestia dziedziczenia po klasie wygenerowanej). Spróbuj, powinno Ci spasować :).
Co to jest Glade, to ja wiem, ale składania, gdy używany jest ruby-libglade a nie ruby-gtk2, komplikuje się.
co do predkosci i zasobozernosci, to tutaj troche zaOTuje, ale ona JEST wazna. np taki Python jest swietnym jezykiem, bla bla bla, ale pozera pamiec niczym nie waz, a smok ;)
D4rky, to zależy, np. taki Gajim, klient XMPP. Potrafi szybciej otworzyć okno rozmowy niż taki Pidgin w C. Ale z kolei oferuje mniej. Sonata – klient MPD. Właściwie wiele nie robi, bo tylko korzysta z daemona odwalającego czarną robotę, ale mimo wszystko jest szybka. Można wykopać masę innych przykładów, ale wiele zależy od sprzętu i [uży]szkodnika ;> .
Artykuł na pewno się przyda aby uzmysłowić innym, że niektóre kwestie dot. Rubiego to tylko stereotypy, a prawda jest całkiem inna :) W każdym bądź razie, dzięki za ten tekst :D
Ja stereotypy usłyszałem dopiero jak się za Rubiego dla zabawy zabrałem :P .
Metoda na ruby-glade-create-template nie działa… Tylko się natworzyłem pięknego GUI i „GUI*NO” z tego.
Ad 3. Kod Rubiego jest podobny do Perla („tego się nie da czytać!”)
Kod programu jest na tyle czytelny, na ile postara się o to autor. Niektóre języki wymuszają ładne formatowanie, inne nie – ale w każdym da się stworzyć składniowego potworka, którego działanie trudno będzie zrozumieć. Podobnie – w każdym da się ładnie i czytelnie pisać, jeśli tylko autor tego chce.
Brainfucki i inne wynalazki będące celem samym w sobie pomijam.
Są również czynniki niemerytoryczne. Średni programista ROR za chińskiego boga nie zarobi tyle co przeciętny koder J2EE. Jakoś tak ciężko w imię dynamizmów, elastyczności i innych takich obciąć sobie zarobki o połowę.
To prawda. Sam kocham pythona (i pewnie bardzo polubiłbym też Ruby), ale zawodowo dłubię w Javie. Bo tu mogę do woli przebierać w ofertach…
Świetny artykuł, choć wątpie czy przekona on watpiących
szyder,Hoppke: średnie zarobki programisty Javy zapewne są większe niż PHP czy też Rubiego (chociaż jest relatywnie mało ludzi, którym płacą za programowanie w tym języku). Ale.. Czasem można też dobrze trafić. Mój kolega ostatnio zmienił pracę ze znanego portalu na literkę „O”, gdzie pisał od Javy, przezp PHP, Perl do Javascript. Teraz programuje w Pythonie i na początek dostał 100% tego co zarabiał do tej pory. Także nie ma jakiejś konkretnej reguły. Mówi się, że zarabiasz tyle na ile się cenisz.@Doniek: ależ on nie miał przekonać wątpiących, tylko przestawić tych co głupoty na około gadają ;-).
Radarek: nie myślałem tu akurat o pieniądzach (jeśli chcesz kosić naprawdę szybką kasę, to najlepiej wejść w C++ i pracować na kontraktach dla banków), a po prostu o wyborze firmy.
Pisząc w Javie mogę sobie wybrać firmę o odpowiadającej mi w danej chwili wielkości (20-70 pracowników), z odpowiadającą mi metodologią tworzenia softu (agile/xp/test-driven), pracującą z odpowiadającymi mi technologiami (Java 5, Spring, Hibernate, bez EJB, JSP i reszty antycznego złomu J2EE) , w sektorze który mi pasuje (ryzyko/finanse), no i oczywiście za pasujące mi pieniądze i w sensownej lokalizacji. Bo po prostu zapotrzebowanie jest tak wielkie, że nawet ze szczegółowym „filtrem” znajduję sporo potencjalnie pasujących firm.
Ruby by mnie w życiu zawodowym pewnie zmusił do paru kompromisów (np. pisania w RoR).
imo programista perla napisal by tak:
while ( <> ) # zamiast <> mozna dac <STDIN>
{
print if /Perl/
}
ewentualnie tak:
map { print if /Perl/ } <>;
Ewentualnie jeszcze inaczej :) . Najwydajniejszy sie wydaje sposob numer 1. To co napisales, to jest programista Javy / C / C++ albo jakiegos pseudokodu.
ha znow nie doczytalem ;> tylko spojrzalem na kod i komentarz … ehhh, a byl na tyle lakoniczny, ze nie domyslilem sie o co chodzi. huh, niedobrze.
Pobawiłem się trochę rubim i powiem tyle: na starcie ładuje wiele modułów których się w danej chwili nie używa. W pythonie aby pobrać ARGV należy załadować lib „sys”, do wyrażeń regularnych potrzeba „re”.
Prosze, to jednak istnieja normalni ludzie :) Gratuluje tekstu.
@Marcins: a co Ci Ruby załadował na starcie? A co do wyrażeń regularnych to ,,Ruby zapewnia wbudowaną dopasowania wzorców i ich podmiany’‘.
@marcins: uważasz, że to czyni jeden język gorszym od drugiego? ARGV i regexpy to chleb powszedni, nie widzę powodu by nie były to elementy wbudowane w język.
No to choćby te wyrażenia załadował na starcie ;)
Ale do mnie akurat ten argument nie przemawia. Ruby nie jest przeznaczony do zastosowań w których liczy się każdy kilobajt pamięci, więc taki narzut nie jest chyba istotny?
Zresztą, o jakim narzucie mówimy? Ile KB zajmuje uruchomione „hello world” w ruby? Jak długo startuje?
Hoppke – w takich wypadkach to sie liczy ASM ;)
Seban, Radarek: powiedzcie mi gdzie napisałem że ruby jest gorszy? Stwierdziłem że python nie ładuje pewnych rzeczy, co ruby robi. Nie napisałem nawet że to, że tak ładuje jest złe.
Wy wszędzie widzicie językowych fanatyków i próbę krytyki? ;>
@marcins: napisałeś coś z czego ciężko było cokolwiek wywnioskować. Zapytałem więc czy uważasz, że to czyni jeden język od drugiego lepszym (gorszym). Jak widzisz sam zinterpretowałeś moje pytanie jako stwierdzenie „Ruby jest lepszy!”, a przecież nic takiego nie napisałem :).
Ok, to teraz wytłumacz nam co chciałeś powiedzieć przez „na starcie ładuje wiele modułów których się w danej chwili nie używa. W pythonie aby pobrać ARGV należy załadować lib „sys”, do wyrażeń regularnych potrzeba „re”.” Bo nie wiem czy to jakiś zarzut, czy też zwykłe stwierdzenie typu „programowałem w Javie, aby dodać klasę z innego pakiety należy użyć konstrukcji import” ;).
Po prostu głośno wypowiedziałem swoje myśli ;) Przeczytałem o rubim na wikibooks i zaznaczyłem tą różnicę między pythonem.
Być może to jest jedną z przyczyn, że ruby uznawane jest za wolne , ale jeden mały moduł w tą czy w tą wiosny nie czyni.
@marcins: tutaj nie ma mowy o żadnych modułach (just built in features), poza tym wspomniane przez Ciebie ficzery są lazy i nie mają żadnego wpływu na start/wydajność interpretera. Główną bolączka 1.8 jest to, że to jest zwykły AST walker z powolnym dispatchem metod.
Brak tu justowania tekstu i komentarzy. To poprawi czytelność! ;-)
@Litania: możesz używać składnie Textile (chociaż przyznaję że ta joggerowa jest momentami ciężka do zastosowania).
Rubiego poznałem chyba jakies 6 lat temu. Od tego czasu przydawał mi się w różnych skryptach i do tworzenia prototypów. W Rails piszę dosyć intensywnie od ponad roku. Jedyną zaletą Rubiego i RoR jest chyba to że programuje się w nich bardzo szybko i wygodnie. Poza tym nic czego by nie byłoby w innych językach.
Co do wydajności, to gdybym mój główny projekt nie był aplikacją, którą odwiedza jedynie wąskie grono klientów, to pewnie pracodawca szybko wybiłby mi z głowy rzeczy w stylu RoR. A muszę przyznać, że włożyłem (i ciągle wkładam) dużo wysiłku w poprawę wydajności.
Co do bibliotek to niby jest ich dużo, ale niestety wiele z nich to szybkie projekty zawierające błedy, i/lub minimum funkcjonalności. Wyglada to kiepsko w porównaniu do Perla i Pythona nie wspominając o Javie lub C/C++.
W każdym razie mam nadzieję, że RoR i Ruby 2.0 poprawią tą sytuację i Ruby nie skończy jak Lisp.
Pozdrawiam,
Kyku
Ludzie! ASP.NET na frameworku 3.5 – z tym można porównywać, a nie ze starym php czy pearlem….
MS ze swoimi rozwiązaniami może w USA jest popularny, ale Polacy wiedzą co dobre i tego nie używają.
puts ARGF.grep(/Ruby/) :P
5. Nie zgadzam się. Ruby, Python i podobne to czysty bełkot.
A jaki język uważasz za czytelny?
@T2: tekst nie miał na celu porównania języków, aczkolwiek pojawiły się nazwy języków, które w jakiś sposób są najbliższe Rubiemu.
@Moarc/J-23: Przecież takie stwierdzenie nie pojawiło się w tekście.
W takim razie i ja Wam coś powiem. Artykuł jest ok i sam miałem go dodać do wykopu gdyby ktoś tego wcześniej nie zrobił. Ruby się rozpędza i zyskuje coraz szersze grono zwolenników. A jeśli chodzi o artykuł:
1) Jeśli szybkość działania jest problemem to jest to tylko kwestia czasu. Odsyłam do: http://antoniocangiano.com/2007/12/03/the-great-ruby-shootout/
2) Masz rację – absurd, bo to od dobrze zgranej grupy w większości zależy czy program będzie dobrze napisany.
3) Napisałem kiedyś fragment kodu ruby i dałem do przeczytania laikowi. Bez problemu powiedział do czego służy. Ludzie, jeden problem można w Rubym napisać na wiele sposobów.
4) Rails jest integralną częścią Ruby. Rails jest napisany w Ruby:D. Nic dziwnego że dobrze ze sobą współgrają
5) Zamiast używać polskiego możemy pisać w Ruby:), pewnie byśmy się zrozumieli, (ale to byłoby już chyba zboczenie zawodowe;)
6) Racja! Kolejny błąd. Rails jest szybszy od php-owego symphony. A skalowanie poziome jest szybkie(chodzi o dołączenie kolejnego serwera)
7) Bez komentarza. Wyśmiać i napiętnować:). Biblioteki ciągle powstają!
8) Ojej. Jeżeli w tym problem to chodzi tylko o szybkość, ale to kwestia czasu. MVC rulez – czytaj ład i porządek – chaos opanowany.
9) Poczekamy zobaczymy, ale ktoś tu źle obstawił. Rubin jest ciągle szlifowany no i ma to coś.
10) NetBeans świetne środowisko, bo sam go używam. Ide nie brakuje, brak za to dystansu krytykom:)
No i powstała piękna mitologia. Ludzie mają dużą wyobraźnię, za to brak rozwagi. Art. pierwsza klasa.
Ja Rubiego po prostu nie lubie. Nawet nie bede wymyslal ku temu racjonalnych podstaw czy krytykowal jakichs cech jezyka.
De gustibus non cośtam.
@Hoppkke: Wszystkie niewcięciowe i niejavowe, i nieMS-owe – C, CPP, Perla, Assemblera, Basha, PHP, Delphi, Pascala…
To ja chyba wolę bardziej czytelną czytelność. Taką z wcięciami.
Nie bez powodu IOCC czy perlgolf dotyczą określonych języków.
Dobra, nie będę się użerał, bo JAPH jestem ;)
Co do edytorów – może kogoś zainteresuje dodatek do Aptana IDE – RadRails. Prezentacje można obejrzeć na http://www.aptana.tv/
Gratulacje Radar, fajny tekst.
To ja dorzucę coś od siebie. Używam Rubiego, gdyż czasami trzeba przeformatować logi jakiejś aplikacji, wygenerować z nich jakieś statystyki itd. itp. Proste zadania do których trzeba coś zaprogramować, nie ma gotowej aplikacji która to „coś” zrobi.
„Perl sie w 100% nadaje do tego” ktoś pewnie powie, ale sprawa jest taka, że ja NIE POTRAFIĘ pisać w Perlu, tak samo jak nie potrafię w Rubym. Nie chce mi sie uczyć języków programowania po to tylko, żeby przeglądać logi jakieś, dlatego wybieram to co działa i coś w czym pisanie nie sprawi mi problemu.
Nauczyłem się jednak jednej rzeczy, jak coś próbowałem pisać w „moim Perlu” i „moim Ruby”, to wynik był zawsze taki: – program w „moim Rubym” działał rzędy wielkości szybciej – program w „moim Rubym” pisałem rzędy wielkości szybciej/krócej – program w „moim Rubym” wygląda ładnie i widać na pierwszy rzut oka co robi
W „moim Perlu” napisałem tylko 3 skrypty, jeden z nich nigdy się nie doczekał końca wykonywania dla pliku 50MB (program w „moim Rubym” obrabiał go w mniej niż sekundę).
Kumplom, którzy piszą w „Perlu” a nie „moim Perlu” jak pokazałem co wyprodukowałem, uśmiechali się tylko :)
I za to lubię Rubiego, nie umiem w nim pisać a piszę i to co napiszę działa, w przeciwieństwie do Perla.
I chyba niedługo zacznę się bawić RoR :) Bo ciekawi mnie o co to chodzi, że wszyscy sie tak cieszą jak słyszą to słowo :)
Jestem zawodowym programistą Java. Na ten blog trafilem splotem linków. Nie zamierzam tutaj charakteryzować poszczególnych języków, ich wad i zalet. Jedno co mogę powiedzieć to, że Ruby można narazie traktować jako hobby i moim zdaniem troszkę tracenie czasu pod względem atrakcyjności na rynku pracy. Bo na rynku nie ma za dużo ofert dla Ruby, a jak już się zdarzają to raczej jest to testowe zastosowanie języka w projektach. Warto też zwrócić uwagę, iż wybór technologii w wielu companiach wyznacza strategię na wiele, wiele lat. I tak jak giganci typu Oracle, IBM, HP, SAP, Sun Microsystems tworzą rozwiązania związane z Java lub Microsoft C# (.Net), to można zadać pytanie kiedy Ruby osiągnie tak mocną pozycję na rynku? Na to pytanie, każdy powinien odpowiedzieć sobie sam.
Pozdrawiam!
@Programmer, cenię Twoją opinię, jednakże nie zgodzę się z Tobą. Gdyby iść Twoim tokiem rozumowania to nie ma sensu próbować nowych rozwiązań, języków, frameworków, zwłaszcza tych, które są mało znane.
Uważasz, że zainteresowanie Sun (JRuby), Microsoft (IronRuby – Silverlight będzie wspierać)
Praca? Idąc do firm jakie wymieniłeś stajesz się tak na prawdę niewolnikiem. Nie masz prawie głosu co do wyboru technologii, robisz w tym czym każą Ci inni. Sorry, ale to nie dla mnie. Nie muszę pracować w Google, IBM czy innej znanej firmie by spełnić się zawodowo.
Wspomniałeś także o pozycji na rynku. http://www.tiobe.com/tpci.htm – ten link już podałem w artykule. Ruby obecnie jest na 9 miejscu. I wiesz co? Mnie to w zupełności wystarcza. Nie zależy mi na tym, żeby cały świat używał tego języka.
Myślę, że wychodzisz ze złego założenia. Prawdopodobnie nie będzie już „wielkiej zamiany” (jak C/C++ -> Java). Jednakże są obszary, w których Java okazuje się po prostu zbyt kobylasta, np. web. I tu Ruby (on Rails) pokazuje swoją siłę. Uważam, że przyszłość to takie połączenia jak JRuby i Java.
Ok pisząc poprzedni komentarz miałem na myśli, iż osobiście nie doradzam wszystkim Tym osobom, którzy chcą zostać profesjonalnymi programistami, a nie tylko hobbystami, którym wydaje się, że wiedzą coś o programowaniu, stawianie Ruby na pierwszym miejscu języków programowania. Natomiast nie miałem na myśli, aby nie interesować sie nowinkami technologicznymi, lub nie interesować sie Ruby. Wszyscy Ci, którzy chcą utrzymywać się z programowania i rozwijać się, narazie powinni na pierwszym miejscu postawić na inny język, bo największy rozwój związany jest z prawdziwymi projektami, podczas których powinno się wyciągać wnioski uczyć pokory i nabierać profesjonalizmu i cech pożądanych dla tego zawodu.
Narazie sam Ruby raczej nie daje takich możliwości jest to technologia stosowana rzadko i traktowana jako suplement, bez którego można z całą pewnością się obejść.
Pisząc o firmach typu Oracle, IBM itp. nie miałem na myśli pracy w tych firmach, ale możliwość w pełni korzystania z produktów tych firm, a co za tym idzie wykorzystanie konkretnej technologii zaimplementowanej w produkcie.
A co do stwierdzenia bycie niewolnikiem danej technologii, to niestety profesjonalne podejście do developmentu powoduje, w wielu przypadkach/firmach iż raz wybrana technologia wyzwala potrzebę wykorzystania tej technologii przez wiele, wiele lat. To już jest mocno związane z zarządzaniem projetkami, a nie tylko z programowaniem.
Podobnie jest z ofertami pracy, teraz firmy z profesjonalnym podejściem do programowania szukają na dane stanowisko specjalisty w jednym konkretnym języku programowania plus ewentualnie SQL i bazy danych.
W większości przypadków pracodawcy zrozumieli, iż szukanie osób ze znajomością kilku języków programowania jest równoznaczne z tym iż szukają osoby, która nie umie nic konrentego na wysokim i profesjonalnym poziomie.
Ja obecnie jestem programistą i project managerem, który odpowiada za konkretny, duży project i tutaj kolejny raz mogę powiedzieć, że z punktu widzenia zarządzania projektami, oceny rentowności i ryzyka stwierdzenie, że dana technologia jest zbyt kobylasta jest jak największym atutem bo jest to technologia kompleksywna. A to czy Java jest kobylasta dla aplikacji web to już zależy od projektanta i architekta danej aplikacji z jakich framework`ów i biliotek zadecydują, aby korzystać w konkretnym przypadku.
(Niejednokrotnie zwracałem uwagę moim współpracownikom iż wykorzystują Struts itp do aplikacji składających się z kilkunastu stron i o których wiadomo, że nie będą się rozrastać – a to jest ewidentyny błąd wynikający ze złego projetkowania aplikacji a nie z problemu technologii).
Pisząc o JRuby i Java nie trudno oprzeć się wrażeniu, że JRuby traktowane jest jako kolejna specyfikacja dla języka Java niż język, który miałby zastąpić Java.
Pozdrawiam!
@Programmer – widze ze jestes apostolem Javy.
Masz racje ze w developerce podejmuje sie decyzje dlugofalowe i dlatego Java 10 lat temu przegrala jako mlody niedorobiony nieprzenosny i kosztowny produkt, kiedy podejmowalem decyzje czy nadal pisac w C i Perl czy zastosowac Jave.
I przegrywa dzisiaj z C a nawet z starym TCLem ;-) w wielu zastosowaniach.
Duzo na temat Javy to tylko mit stworzony przez sprzedawcow serwerow (SUN,IBM) bo im to drastycznie zwieksza zyski. Jak juz ktos kupil to JEE to musi brnac dalej w uzasadnienia i kupowac coraz drozsze serwery.
I tu masz racje ze programista niewiele ma do powiedzenia w duzej korporacji bo decyzje zapadaja na szczeblu biznesowym. Sa to decyzje czesto tak samo dobre jak gdyby programista podejmowal decyzje finansowe i dyktowal ksiegowym co maja robic.
Osobiscie lubie Perla bo dziala i jest prawie wszedzie oraz ma CPAN.
Bardzo polubilem od kilku lat Ruby bo wiekszosc potrzebnych bibliotek ma juz zazwyczaj zainstalowanych w standardzie (istotne w shared hosting) oraz ma bardzo czysty kod.
To niesamowicie zwieksza produktywnosc.
Coraz wiecej programow narzedziowych mam w Ruby, dobrze sie skaluja idealne w konserwacji, dobra dokumentacja.
Zreszta jak czegos zabraknie to mozna sobie dopisac w C.
Z pomiarów wydajnosci w wersji 1.9 wynika ze szybkosc nie stanowi zadnego problemu, zarowno w aplikacjach desktopowych jak i w webowych.
Jak ktos pisze w jednym jezyku programowania (wszystko jedno jakim) kazda aplikacje to chyba mu sie zdrowo cos pomylilo albo uwierzyl tym co go zatrudnili.
To tak jak kierowca i prawojazdy B, nie ma prawa jazdy np. na Peugeota tylko na samochody do 3,5 tony.
@Programmers. Javy zastapic sie nie da, żaden inny jezyk programowania nie zamula serwera wystarczajaco dobrze ;-)
@Slawek, dzięki za komentarz :). Ja dokładnie staram się prezentować postawę „wybór odpowiedniego narzędzia do odpowiedniego zadania”. Owszem, czasem można by pomyśleć, że wszędzie widzę tylko Ruby, ale tak nie jest :). Javę w pewnych zastosowaniach także używam/lubię, ale w całe to bagno z etykietą „j2ee” nie chcę brnąć. Zbyt głębokie, a potem ciężko z tego wybrnąć...