Názory k článku Ruby a unicode: co přinese chystané Ruby 1.9?
-
LO (neregistrovaný)Japonci nemají rádi Shift-JIS & co., protože uprostřed streamu ani nepoznáte, jestli jste na začátku znaku, nebo ne. Takže 'A' může být prosté A, nebo kus nějakého japonského znaku.
Japonci také nemají rádi UTF-16. Z důvodu výše popsaných zkušeností se jim vůbec nelíbí myšlenka rozšiřování Unicode nad 16 bitů. Ani nevím, jestli se japonské verze Windows dodávají se zapnutou podporou Surrogate Pairs. -
LO (neregistrovaný)V Linuux se round tripům nelze vyhnout. Například Qt používá UTF-16, kdežto glibc používá UTF-8 a omezeně i UTF-32. Efektivně se překládá všechno pořád dokola mezi jednotlivými prezentacemi Unicode.
Japonci to ale řešit nemusí. Znaky z Shift-JIS jsou podmnožinou Unicode (viz http://www.microsoft.com/globaldev/reference/dbcs/932.mspx), a Japonci dnes používají Windows. Windows jedou komplet v UTF-16 (Win32, .NET, aplikace). Shift-JIS se používá stejně, jako u nás ANSI 1250 - tedy pro importy starých věcí, a v pár prehistorických aplikacích. -
Rejpal (neregistrovaný)
Například Qt používá UTF-16, kdežto glibc používá UTF-8 a omezeně i UTF-32.
To ale nejsou znakové sady.Japonci to ale řešit nemusí. Znaky z Shift-JIS jsou podmnožinou Unicode (viz http://www.microsoft.com/globaldev/reference/dbcs/932.mspx), a Japonci dnes používají Windows. Windows jedou komplet v UTF-16 (Win32, .NET, aplikace). Shift-JIS se používá stejně, jako u nás ANSI 1250 - tedy pro importy starých věcí, a v pár prehistorických aplikacích.
Děláš si srandu? "Japonci dnes používají Windows"? Víš, jaký je absolutně nejrozšířenější OS v Japonsku (co do počtu instalací) a jakou znakovou sadu a kódování používá? Ne, Windows to opravdu nejsou, a Microsoft proti tomu systému bojuje někdy od roku 1989, ale zatím se mu to nepovedlo. -
Taky si myslím, že tohle řešení je poněkud, no poněkud - zkrátka ne moc dobré. Není nad to držet to uvnitř v rozumném Unicode formátu. Tento recept Ruby - vyřešíme to 50x složitěji, než je to potřeba, je poněkud no poněkud nic moc. Ale uznávám, že fungovat to bude, ale o eleganci a efektivitě se tedy rozhodně mluvit nedá. -
Inkvizitor (neregistrovaný)Překlad Bible Kralické mám doma a je vytištěný normálním fontem a obsahuje výhradně písmena české abecedy. Jestliže máš konkrétní vysvětlení, proč nelze ty znaky prostě nahradit novými a obalit je tagem <dynastieming>, budu rád. Vycházel jsem z informací, které byly napsané v té Wikipedii, na kterou odkazoval Rejpal. Tam psali, že se mimo jiné jedná o ekvivalenty dnešních znaků (stejná sémantika, jiný tvar).
-
Makovec (neregistrovaný)myslim ze ten stub ve wiki je zavadejici... ty archaicka, stara nebo alternativni verze znaku ma i posunutou semantiku.... s fonty to nejde take proto, ze u kazdeho znaku existuje jiny pocet historicky variant z jinych obdobi (nejde tedy treba udelat font pro "kazdou dynastii")...
v principu jde o rozpor toho, co znamena "psat" u nas a u nich. -
LO (neregistrovaný)Jednak mi přijde problém poněkud teoretický (jaký má TRON obchodní potenciál?), a potom OpenType umožňuje pro jeden znak více alternativních reprezentací. Viz třeba zde (v latince): http://www.typophile.com/node/8122
-
anonymní
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.)
- reflection v ruby sa mi zda lepsia
-
Rejpal (neregistrovaný)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 b5) 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. ;-)
-
anonymní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? -
JS (neregistrovaný)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? -
Rejpal (neregistrovaný)
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í?
