Názory k článku
Je perl ještě na pořadu dne?
-
anonymníperl je oproti ostatnym jazykom ovela narocnejsi na schopnosti programatora.
perl totiz ako jazyk sam o sebe nekladie programatorovi takmer ziadne predpisy, takmer ziadne bariery. vsetky si programator buduje sam.
chces modularny program?
- perl ma nastroj, pouzivaj ho ako uznas za vhodne
chces objekty?
- perl ma nastroj, pouzivaj ho ako uznas za vhodne
chces vynimky?
- perl ma nastroj, pouzivaj ho ako uznas za vhodne
najvacsi problem perlu je to, ze programatori su lenive svine (poznam podla seba :-) ), a ich manageri su slusne povedat idioti -
anonymníz dokumentacie ...
A Ruby class can have only one direct parent, and so Ruby is a single-inheritance language.
... vyplyva, ze ruby je (pre mna) takisto ako mnozstvo inych jazykov mrtve.
nech si vravi kto chce co chce, na viacnasobnu dedicnost clovek natrafi kazdu chvilu ... a simulovat to inak? sorry.
je to namet na poriadnu flamewar ... ma dakto zaujem ? :-))) -
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)? -
anonymní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
programator/ina kniznica definuje AUTOLOAD.
jeden z prikladov je v kniznici CGI.pm
sub AUTOLOAD { print meno-volanej-metody; ... }
a program moze vyzerat nasledovne:
html (
body ( {onLoad => 'alert (1)' },
table ( { border => 0 },
[ .... ]
)
)
)
(uvedene je priklad, osobne neprogramujem webove aplikacie takze nemam oblubeny sposob) -
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 -
anonymní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. -
anonymníNo, tak pokud vam neuveritelne vadi ty thready, muzete zkusit Sydney ( http://blog.fallingsnow.net/articles/2005/07/11/sydney-developer-preview-release-1-out nebo http://redhanded.hobix.com/inspect/syndeyTheNewPeopleSChoiceRuby.html ), coz je Ruby na steroidech :)
-
Wejn (neregistrovaný)No, tak pokud vam neuveritelne vadi ty thready, muzete zkusit Sydney ( http://blog.fallingsnow.net/articles/2005/07/11/sydney-developer-preview-release-1-out nebo http://redhanded.hobix.com/inspect/syndeyTheNewPeopleSChoiceRuby.html ), coz je Ruby na steroidech :)
-
Zajímavé, ale myslím, že lepší bude počkat na Ruby 2.0 využívající nový YARV VM. Dle jeho autora bude kromě jiných v nové verzi zahrnuta i podpora nativních threadů, viz: http://article.gmane.org/gmane.comp.lang.ruby.yarv.devel/57
Další info: http://www.atdot.net/yarv/
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. -
Wejn (neregistrovaný)No, tak kdo by se netesil na YARV :-)
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. -
da5id (neregistrovaný)Na základě probíhající diskuse jsem se na Rails kouknul a musím se přiznat, že mě oslovil ;-) Narazil jsem ale na newbie problém: nedaří se mi založit novou aplikaci jako non-root. Zde přikládám výstup:
~/public_html/test$ rails .
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.1/lib/active_support/dependencies.rb:186:in `const_missing': uninitialized constant ActiveRecordError (NameError)
from /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.11.1/lib/active_record/validations.rb:2
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require'
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.1.1/lib/active_support/dependencies.rb:200:in `require'
from /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.11.1/lib/active_record.rb:37
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:21:in `require'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:182:in `activate'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:181:in `each'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:181:in `activate'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:167:in `activate'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:166:in `each'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:166:in `activate'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:37:in `require_gem_with_options'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:31:in `require_gem'
from /usr/local/bin/rails:17
Pod rootem všechno projde v pohodě, osobně jsem to tipoval na práva, ale všechno vypadá v pohodě - tak nevím. Dělám něco úplně špatně? Dík za každou odpověď a hezké léto :-) -
Ondřej Tůma (neregistrovaný)Tedy v perlu zatim moc neprogramuji - neb co potrebuji vetsinou napisu uz v shellu, ale jinak jako back-end bych sel rozhodne do perlu - byt se zatim ucim. Nejvice se mi na perlu libi prave ten podobny pristup jako je v c(++). Dalsi a hodne silnym plusem je rozhodne rozsireni - snad vsechny mozne knihovny co jen znam pokud maji zastoupeni ve scriptovacim jazyce - tak je to perl. Na web zatim porad php - ono je to na to proste stavěné ;)
Ale co me děsí víc je python - tedy sem znám svým přístupem k pythonu. Prostě v něm musím programovat v práci a fakt mi nesedí. Ale bohužel, pokud bych chtěl dělat nějaká udělátka pro nejrůznější programy - jako automatické generování, pluginy apod. obávám se že mi zbývá jedině python. Jmenuji třeba jen: gnumeric, k3d, planner. Což mě příde jako škoda. -
ad rozsireni:
pro Perl se rozsireni pisou naprosti priserne, jeste ze existuje SWIG, ktery alespon cast prace udela za me.
pro Ruby to neni vubec ke srovnani, to je radost psat!
Kouknete na tento clanek: http://www.onlamp.com/pub/a/onlamp/2004/11/18/extending_ruby.html, ten mi mluvi z duse. Mmch: ta rozsireni se daji i cist!
Je pravda, ze so se tyce ruznych knihoven, vede Perl na cele care, ale s tim, jak se snadno wrappery Ruby pisi a jak rychle jich pribyva se neni treba bat, ze by s nimi byl v Ruby problem.
ad Python: taky mi nesedl, i kdyz si myslim, ze neni vubec spatny. Jsem rad, ze me kolega presvedcil zkusit Ruby, zkuste to taky, treba vam sedne lepe.
