Nevím, ale od té doby, co jsem objevil Ruby, nemám chuť už napsat ani jediný řádek v Perlu.
A poté, co jsem zkusil udělat pár aplikací v Rails, je pro mě mrtvé i PHP.
Ruby toto resi pomoci mixinu, coz mi prijde o dost lepsi nez treba javove interfaces. Pomoci mixinu udelate prakticky vcechno, co vas napadne. Navic to muzete provadet v run-time a treba jen na konkretni instanci.
Pokud byste chtel vicenasobnou dedicnost tak, jak ji zname treba z C++, s virtualnimi bazovymi tridami a dalsimi super vlastnostmi, tak potom musim rici, ze bohudik Ruby nic takoveho nema.
Jeste k C++: cetl jsem Design Patterns od gangu 4 a snazil jsem si predstavovat, jak by to asi vypadalo v Ruby. Prislo mi, ze polovina patternu byla vymyslena proto ze v C++ se musi nektere veci delat tak, jako kdyz si sedim na obou rukach a chci pri tom psat na klavesnici.
p.s. V cem pisete (jestli jsem s C++ strelil vedle)?
hej hej, to som si cital, nepripada mi to to prave orechove.
jeden z prikladov:
class Socket;
class HostSocket : Socket;
class InetSocket : Socket;
class InetHostSocket : InetSocket, HostSocket;
class UnixSocket : Socket;
class UnixHostSocket : UnixSocket, HostSocket;
ako som uz raz napisal, kazdy silny nastroj je dobry nastroj, ale odsudzovat ho preto, ze niekto ho nevie pouzivat ?
prestanete pouzivat cirkularku, pretoze vas ozraty sused si odpilil dva prsty? :-)))
ad design patterns: ono je to trochu o inom, hlavnym zamerom je zvysit znovupouzitelnost kodu (objektov).
priklad:
AbstractFactory ... v Rails je to nieco typu (db-driver: mysql).
to je ten objekt (skryty), ktory robi transpartny pristup k db.
Decorator ... nie je to "nahodou" vas mixin ? :-)))
v com programujem? momentalne cisto perl, byvali casy aj javy a c++.
btw, ked chcete flamewar ... ako je na tom Ruby a autoload?
(pre vysvetlenie)
programator: volam funkciu/metodu do_something
perl: aha, ta metoda neexistuje, zavolam radsej AUTOLOAD
Memam mic proti design patterns, prave naopak. Vubec me nemrzi, ze jsem si to precetl.
Chtel jsem se navazet do C++, protoze jsem si tipoval, ze kdyz mluvite o vicenasobne dedicnosti, budete si v nem libovat a ze si pekne zaflamujeme ;-)
ad autoload: v Ruby se takove veci delaji pomoci method_missing: http://www.rubycentral.com/ref/ref_c_object.html#method_missing
cili pro vysvetleni:
volam metodu, ktera neexistuje na nejake instanci I cehosi,
ruby: aha, takze toto neumime, takze volame I.method_missing( :jmeno_volane_funkce, *argumenty)
btw: Jedna vyhoda Ruby proti Perlu je, ze se to da cist. Delat v perlu v teamu vice lidi, to chce prisnou disciplinu a dlouhy bic. Perl nebyl navrzen, je to vytvor sileneho lingvisty.
Proti C++: nemusime jednoduche veci delat slozite, od myslenky k zapisu je jen krucek.
PHP: Pejsek s kocickou varili dort, placli tam toto a pak toto, pak se jim to nejak nezdalo, tak to zkouseli nejdriv osolit a pak osladit, nakonec to neslo zrat.
Python: to je tezky, Python je dobrej, moc pythonistu k Ruby neprechazi, nemaji motivaci
Ruby je velice kvalitni programovaci jazyk a pokud si muzu vybrat mezi perlem nebo rubym, tak ruby je jasna volba :-)
co mi ale neuveritelne ohledne ruby vadi je implementace vlaken je li tedy nejaka sance ze se neco podobneho bude pouzivat a zalezi na rychlosti a spolehlivosti obchazim ruby velikym obloukem. Pokud je nutne psat neco distribuovanyho, velkyho a komplexniho, tak python je stale neporazena jednicka.
Kdyz uz jsem si vydelal na chleba psanim v hruzach jako perl, tak se rad necham unaset uzivanim opravdu skvostnych jazyku jako haskell, ocaml a scheme.
YARV by měl ale hlavně přinést výrazné zrychlení, v některých případech až 10x oproti dnešnímu Ruby. Právě rychlost je asi hlavní věc, ve které Ruby zatím zaostává za Perlem i Pythonem.
Jenze ja mam pocit, ze stabilni verze je jeste peknych par mesicu v budoucnosti.
A pokud jde o tu rychlost -- no, pokud v Ruby nepisete zrovna realtime veci a nebo zpracovani grafiky, da se docela dobre pracovat i s 1.8.X. :-) Nehlede na to, ze napriklad Rails tohle dobre resi pomoci fragment/page/action cachovani.