To jsou problemy.. vzdy, kdyz prectu nejaky clanek o Ruby, jsem rad, ze pouzivam Python. (ne ze bych chtel rozjidet flame), muj osobni strucny nazor na vec jmenem Ruby.
No to bude tym, ze z nejakeho dovodu sa tu v suvislosti s Ruby riesi uz dlho unicode (co je pre zmenu mne uplne ukradnute).
Python obcas pouzivam, zrovna nedavno som v nom pisal nieco dlhsie a oproti Ruby mi vadi/chyba (co ma zrovna momentalne napada):
hlavne slabsia podpora uzaverov (closures) v pythone, je tam sice lambda keyword na pisanie lambda funkcii, ale AFAIK sa daju pisat len funkcionalne a nie deklarativne, napr. python nezozere v lambda funkcii if/while (v ruby v uzaveroch v klude, podobne aj v perl).
python ma podivne pisanie tried/metod (self musi byt vzdy uvedeny explicitne, hacky typu __iter__, __str__, ohackovana podpora privatnych memberov - vyzera to ze vznikal podobne jak perl - objekty tam boli dohackovane neskor (old style classes/new style classes)
v dosledku toho v pythone raz syntax vyzera ako metoda objektu, inokedy ako globalna funkcia, napr.:
s = set()
t = set()
s.add(3) #"lokal"
s = s.union(t) #"lokal"
l = len(s) #"global", podobne str(), repr()
V ruby (bez miesanie niecoho co vyzera "globalne" a "lokalne", az na trik s Kernelom pre parriadkove skripty):
s = Set.new()
t = Set.new()
s.add(3)
s.merge(t)
l = s.length()
python nema ternarny operator (cond) ? a : b a nevedia sa dohodnut ci bude, a ak ano, jak bude vyzerat (silny zvyk z C++, Java apod.)
Len poznamka k tym uzaverom/lambda: hodi sa to trebars dost na visitorov (prechadzanie/manipulacia grafov, napr. syntax tree), staci par kratkych uzaverov miesto pisania kopu zbytocneho balastu okolo parriadkovych metod dedenim nejakej classy.
Ač se mi v mnoha věcech líbí víc Ruby, musím se zastat i Pythonu:
2) __str__ není vlastně nic jiného, než #to_s.
4) Ale má, sice trošku podivně, ale má: a ? b : c => c if a else b
5) Jo, tak to se líbí i mým kolegům pythonistům. :-) Vůbec by bylo skvělé, kdyby třeba PyPy mohl jednou podporovat alternativní knihovnu, tu bych si _velice_ rád udělal podle sebe. ;-)
2) jasne, str(x) vola x.__str__(), mne sa proste nepacia tie stvorpodtrzitkove metody (__iter__, __str__, __class__, ...) - vyzera to, ze nechceli name clash s existujucimi metodami (neviem, hadam ;-) - akurat viem, ze vyvoj tried tam zanechal nejake stopy)
4) aha dik, vedel som len o 'cond and a or b', ktore sa neda pouzit ak a aj b su vyrazy, ktore sa vyhodnotia na False (aj ked ide q=lambda a,b,c: (a and [b] or [c])[0], ale to je skor hack, aj ked funkcny). Ale python 2.4.4 mi 'c if a else b' zozrat nechce...je to az od 2.5?
Ad 1. Misto uzaveru ma Python proste funkce. Jde zkratka o dve moznosti jak implementovat tutez vec, pricemz obe moznosti maji stejnou silu. Podobne je to i s Ruby continuations vs. Python coroutines.
Ad 2. Ve skutecnosti tam byly objekty od zacatku. Akorat Python nebyl planovany jako ciste objektovy, a to ma sve vyhody (ja napriklad obvykle programuji pouze proceduralne, je to casto rychlejsi). O psani self lze vest spory, ale tezko najdete lepsi (a citelnejsi) reseni. __iter__, __str__ apod. neni hack, ale standardni konvence metod, kterym odpovida nejaka operace v syntaxi jazyka (viz tez odpoved na bod 3).
Ad 3. Muzete to chapat tak, ze len(), str() apod. jsou jen dalsi operatory (podobne +, -, <, ...). Akorat se nahodou pisou stejne jako funkce.
Ad 5. To je ponekud nekonkretni namitka (reflection muze znamenat mnoho vlastnosti jazyka). Ma Ruby metatridy nebo dekoratory?
1) Funkce nejsou totéž co uzávěry, a uzávěry nejsou totéž, co anonymní funkce. A Python má všechny tři. Budiž mu to připočteno k dobru (přestože bindingy v obklopujícím bloku jsou neměnné, ale to stejně zas až tolik nevadí, a navíc, jestli to chápu správně, se to změní s příchodem klíčového slova nonlocal).
2) Procedurálně programujete tak jako tak. Neprocedurálně byste programoval v Prologu s využitím predikátové logiky nebo v SQL. Osobně nevidím problém v tom, že člověk má možnost použít jak funkci, tak i přímo implementující metodu, jelikož funguje oboje, ale spíš v tom, že to přispívá k celkovému "bordelu". Pokud jde o implicitní self, rubí model mi rozhodně nepřijde špatný, ale na pythoní se dá zvyknout celkem bez problémů. :-) To zvyknutí mi usnadňuje značná podoba Pythonu a Lispu (resp. ten CLOSový feel z toho, že příjemce zprávy je parametr funkce, byť v případě Pythonu stále ještě ptrivilegovaný).
5) Jde o to, že Ruby má (dle soudu mnoha lidí, a nejen rubistů :-)) velmi pěkně ošetřené možnosti programového vrtání se v objektech a třídách. Ne že by Python tohle postrádal, to si samozřejmě také nemůže dovolit, jen je to podivně rozházené všude možně po standardní knihovně. Tohle Ruby podědilo ze Smalltalku, který by bez toho ani nefungoval, protože už třicet let mění za chodu sám sebe, aniž by kdy byl jakožto 24/7 program ukončen. :-))) Já to vidím tak, že Ruby reflexi v podstatě bezpracně zdědilo ze Smalltalku již vyřešenou a tak působí mírně konzistentnějším dojmem - však se podívejte sám do dokumentace, třeba na instanční a třídní metody třídy Class. Otázku na metatřídy si jistě zodpovíte sám, když Vám položím protiotázku: Objektový programovací jazyk, jehož třídy mají prvotřídní status, metatřídy mít může nebo musí?
