See also ebooksgratis.com: no banners, no cookies, totally FREE.

CLASSICISTRANIERI HOME PAGE - YOUTUBE CHANNEL
Privacy Policy Cookie Policy Terms and Conditions
Diskussion:Ruby (Programmiersprache) – Wikipedia

Diskussion:Ruby (Programmiersprache)

aus Wikipedia, der freien Enzyklopädie

Inhaltsverzeichnis

[Bearbeiten] Verbreitung und Nutzung

-saf Ich denke es wäre wchtig, etwas mehr +ber die Verbreitung und Nutzung gerade IN Europa und Amerika zu wissen, Y2K ist ja nun schon ein paar Jahre her und den deutschen Betrachter interessiert es sicher wenig, dass es davor nur in Japan zu finden war. Ich hab leider keine Infos parat aber viellecht jemand anderes und ich werde auch sicher mal recherchieren.

[Bearbeiten] Bsp: Datei Zeile für Zeile einlesen

Wie sieht ein Beispiel aus, das eine Datei zeile für Zeile einliest? Im On-Line-Ruby-Buch gibt es nichts derartiges. --HHK 23:42, 14. Sep 2003 (CEST)

wer lesen kann ist klar im vorteil - siehe programmierbeispiele, das letzte.. -- ∂ 10:26, 16. Sep 2004 (CEST)
# Gibt die Datei text.txt Zeile für Zeile auf der Standardausgabe (Bildschirm) aus
File.open("text.txt") do |file|
        file.each_line do |line|
                puts line
        end
end
sehe ich auch so, drum sollte man besser lesen, bevor man den Mund aufmacht... (das hat zu dem Zeitpunkt nämlich noch nicht drin gestanden hat, siehe dazu Versionen) --Milanx 20:58, 16. Sep 2004 (CEST)
obwohl diese comments schon so alt sind - ich kann es mir nicht verkneifen, ein beispiel anzugeben, das genau das gleiche ergebnis hat (die datei allerdings nicht zeile für zeile ausgibt): -- Blinry 14:06, 9. Feb. 2007 (CET)
puts IO.readlines("text.txt")
Diese Variante macht exakt das gleiche Zeilenweise:
IO.readlines("text.txt").map {|l| puts l}

Daniel Bovensiepen 19:42, 9. Feb. 2007 (CET)

[Bearbeiten] Keine Doppelspurigkeiten?

Abgesehen davon gibt es aber sozusagen keine Doppelspurigkeiten wie in Perl.

Was soll das heissen? --zeno 09:50, 10. Okt 2005 (CEST)
Vermutlich ist $_ und $1-$9 gemeint. Aber dann versteh ich den Satz nicht, weil Ruby durchaus ein $_ hat. --LuckyStarr 21:45, 11. Nov 2005 (CET)

[Bearbeiten] Unicode-Support

Der Unicode-Support von Ruby sei nur begrenzt vorhanden.

Funktionier ein Bsp. wie das folgende?

>> "abcαβγ".index("α")    
=> 3

Was muss dabei beachtet werden (Einstellungen)?

Ja tut es, Wenn auch noch mit etwas Handarbeit. Aber bei der nächsten Version wird alles besser (hoff ich und glaube 'Matz' mal(http://redhanded.hobix.com/inspect/futurismUnicodeInRuby.html)  :- )
$KCODE = "u"
require 'jcode' # bzw. statt jcode vielleicht unicode(sihe http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/197946)
puts  "abcαβγ".index("α")
=>3
--KleinerPinguin 12:58, 27. Jul 2006 (CEST)
Relativ neu ist diese UTF Bibliothek: http://redhanded.hobix.com/inspect/nikolaiSUtf8LibIsAllReady.html. Funktioniert schon ziemlich gut. Daniel Bovensiepen 15:21, 27. Jul 2006 (CEST)

[Bearbeiten] Code-Bsp: Assoziativer Array / Hash / Dictionary

Der Artikel erwähnt, dass Ruby Konzepte von Smalltalk übernimmt. Wie sieht der Code für die in Smalltalk häufig verwendete Datenstruktur des Dictionary aus?

Smalltalk:

  d := Dictionary new.
  d at: 'grün' put: 'green'.
  d at: 'blau' put: 'blue'.
  d at: 'rot'  put: 'red'.
 
  Transcript show: (d at: 'blau').

Ruby

  ???

Meinst Du das?

   d = Hash.new
   d[:grün] = 'green'
   d[:blau] = 'blue'
   d[:rot] = 'red'
   
   puts d['blau']

kann auch so geschrieben werden:

   d = { :grün => 'green', :blau => 'blue', :rot => 'red' }
   
   puts d[:blau]


Das wirkt eher wie von Perl als von Smalltalk übernommen. Vergleich:

   %hash = ( 'grün' => 'green', blau => 'blue', rot => 'red' };

bzw.

   my %hash;
   $hash{ 'grün' } = 'green';
   ...

Ruby hat von Smalltalk Objekt-Semantik und Methodennamen übernommen, aber kaum Syntax. Die kommt in der Tat eher von Perl und anderen Sprachen. [murphy]

[Bearbeiten] Bezgüglich Weblinks

Ich habe gerade die Änderungen teilweise rückgängig gemacht. Grund ist folgender: Ich sehe zwar ein, dass hier teilweise zuviele Links drinne stehen aber die Löschung war wohl ziemlich planlos. Wenn ich mir einen Lesenswerten Artikel wie Perl anschaue, finde ich dort auch einen Link zu einem Userforum. Und da es sich bei rubyforen.de um das größte deutsche Rubyforum handelt sollte dieser Link hier auch erscheinen. Weiterhin verstehe ich nicht wieso man Why's ergreifenden Guide rausschmeißt und die ganzen anderen halbfertigen Einführungen drinne lassen kann. Es existieren genau zwei Ruby Bücher die in der Community unumstritten als gut angesehen werden. Da wäre zum einen das PickAxe und zum anderen der Poignant Guide. Und wenn der Benutzer der für die Löschung verantwortlich war, glaubt das es sich bei der Seite um eine Werbeschleuder handelt, würde ich Ihm dringend nochmal empfehlen sich die Seite erneut anzuschauen. Bei dem dritten Link, den ich wieder eingefügt habe, handelt es sich um eine elegante Möglichkeit Ruby direkteinmal auszuprobieren. Wenn ich ohne Vorwissen diesen Artikel lese, würde ich es schon begrüßen wenn ich die Codebeispiele direkt mal ausprobieren kann ohne gleich den Interpreter zu installieren. Sollte der User der die Löschung durchgeführt hat eine Begründung für diese Aussonderung haben so bitte ich um eine Info diesbezüglich. Daniel Bovensiepen 20:55, 13. Apr 2006 (CEST)

Nützliche Links gehören in ein Webverzeichnis, nur enzyklopädisch relevante Information, die über das im Artikel gebotene hinausgeht, gehören in die Wikipedia. Welche Information bieten denn Foren und Portale? Heute dieses und morgen jenes.
Die Popups sind übrigens weg. Hmmm.
Die Links im Einzelnen:
Aus relativ einsichtigen Gründen akzeptabel finde ich:
Den Rest ersetze ich jetzt durch den Link zur deutschen dmoz-Kategorie, das ist zwar auch nicht die Reine Lehre, aber eine gängige pragmatische Lösung.
Pjacobi 01:36, 14. Apr 2006 (CEST)
Hi Pjacobi. Danke für diese Informationen. Ich selbst habe nicht gewusst, dass in der Wikipedia ein solch strikter Vorhalt gegen Community Portale besteht. Da ich bei anderen Artikeln des öfteren solche Links vorfinde, hat mich deine Löschung halt nur ein wenig verwirrt. Ich werde den Link zum Ruby Garden auch noch raushauen da eine der Vorschriften ja auh heißte 'Bitte vom Feinsten' und das kann man ja von einer Seite kaum sagen, dessen letzte Aktualisierung knapp ein Jahr her ist. Danke aufjedenfall für die Infos, ich hatte mir die Richtlinien von der Wikipedia zwar bereits durchgelesen aber scheinbar die wichtigen Punkte übersehen (-: Daniel Bovensiepen 01:56, 14. Apr 2006 (CEST)

[Bearbeiten] ungetype Variablen? Wohl eher dynamisch typisiert

Hallo zusammen, es wurde gerade das Merkmal 'dynamisch typisiert' in 'untypisierte Variablen' von Benutzer:D geändert. Ich würde gerne Wissen wie das gemeint ist? In Ruby gibt es keine Variablen im eigentlichen Sinne. Es gibt nur Referenzen auf Objekte. Und diese Referenzen sind typisiert. Man kann zu jeder Zeit über :class den 'Typ' herausfinden. Das besondere ist halt das dieser Typ geändert werden kann. Bitte klärt mich auf wie dieser Wortlaut zu verstehen ist. Daniel Bovensiepen 11:49, 25. Apr 2006 (CEST)

Ich glaube mit 'untypisierte Variablen' soll zum Ausdruck gebracht werden, dass es keine statische Typsicherheit gibt, d.h. eine Typisierung, die bereits zur Übersetzungszeit validiert wird. Zur Laufzeit haben die Verweise natürlich Typen. Insgesamt würde ich auch eher die Bezeichnung dynamische Typisierung bevorzugen. So stehts auch im englischen Artikel. Ein Verweis auf Duck Typing wäre an der Stelle wohl auch nicht schlecht. --Sprezz 12:28, 25. Apr 2006 (CEST)
Hi Sprezz, sehe ich genauso. Duck Typing könnte man natürlich noch als zusätzlichen Punkt aufnehmen. Ich warte jetzt noch ein wenig bis ich die Änderung vornehme. Ich hoffe ja mal, dass der Benutzer:D nochmal vorbeischaut, eventuell hat er noch einen anderen Beweggrund. Daniel Bovensiepen 23:46, 25. Apr 2006 (CEST)
Da der Benutzer:D keine Begründung abgeliefert hat, habe ich nun die dynamische Typisierung wieder aufgenommen. Diesmal mit dem Hinweis auf Duck Typing. Dies sollte hoffentlich verständlicher sein. Daniel Bovensiepen 22:26, 29. Apr 2006 (CEST)
Finde ich gut. Gruß --Sprezz 00:47, 30. Apr 2006 (CEST)

[Bearbeiten] Artikel Redesign

Hallo zusammen, ich habe Interesse diesen Artikel komplett zu überarbeiten. Eine erste Version existiert bereits. Wenn es strukturelle Änderungswünsche gibt, sind sie dort gerne gesehen. Ansonsten würde ich in nächster Zeit diesen Artikel hier ersetzen. Daniel Bovensiepen 15:41, 21. Jul 2006 (CEST)

Da sich in den letzten zwei Wochen niemand gemeldet hat, habe ich den Artikel so ebend komplett ersetzt. Die aktuelle Version wurde bereits von mehreren Leute quergelesen, es schadet natürlich nix wenn trotzdem der eine oder andere nochmal drüber schaut. Wenn es aufeinmal doch Gegenstimmen gegen die neue Version geben sollte, bitte melden Daniel Bovensiepen 15:48, 7. Aug 2006 (CEST)
Hab mich mal der Kommasetzung angenommen ;)--BeatePaland 22:39, 8. Aug 2006 (CEST)
Echt verrrückt wieviele Kommas man in der deutschen Sprache vergessen kann (-: Daniel Bovensiepen 00:59, 9. Aug 2006 (CEST)

Ihr solltet am Ende nochmals wiederholen, wer die Sprache entwickelt hat und wo sie populär ist; das habe ich nach den vorherigen Doppelnennungen bereits wieder vergessen ;) --Sanoj :)~ 19:43, 9. Aug 2006 (CEST)

[Bearbeiten] Anpassung von Duck Typing

Es wurde ebend folgender Text für den Bereich Duck Typing eingefügt: Ruby ist dynamisch und stark getypt, genauer ist es "duck typed", duck-getypt. Eine Variable kann somit Objekte beliebiger Klasse halten. Bei einem Aufruf wird zur Laufzeit der Typ bestimmt und überprüft, ob die Ausführung möglich ist. Hierbei wird die Introspektion von Ruby eingesetzt, um Objekte auf Kompatibilität zu überprüfen. Auf Basis dieses Paradigmas können Methoden geschrieben werden, die mit Objekten von unterschiedlichen Klassen kompatibel sind:

Ich hätte nun ein paar Fragen. Erstens würde ich gerne wissen wieso der erste Teil (welcher ersetzt wurde) als Halbwahrheit angesehen wird. Zweitens ist Ruby nicht von Haus aus duck-getypt. Duck Typing ist nur ein Paradigma welches in Ruby einen Namen erhalten hat und bei Bedarf eingesetzt werden kann. Im Allgemein hört sich die neue Formulierung so an als ob Ruby das ganze Duck Typing + Reflektion zur Überprüfung selbstständig macht. Daniel Bovensiepen 23:26, 9. Aug 2006 (CEST)

Hallo!
Halbwahr, weil Ruby ganz duck typed ist, nicht ein bisschen. Der deutsche Artikel Duck Typing scheint mir nicht das geläufige Verständnis von Duck-Typing wiederzugeben, wie es auf http://en.wikipedia.org/wiki/Duck_typing beschrieben ist. Ich hatte gerade eine vermutlich ähnlich fruchtlose Diskussion über den Artikel Strongtalk, und nachdem da einige Quellen gesichtet wurden hat sich bei mir manifestiert, dass die Art dynamischer, starker Typung, die Ruby und Smalltalk durchführen eben "duck typed" heißt. Das ist also keine Alternative, das ist halt die Art, wie Ruby Variablen verwaltet.
Deinen Nachsatz verstehe ich nicht: Ruby, genau wie Smalltalk, treiben halt keinen statisches Typsystem und benutzen stattdessen den lieben langen Tag Reflection. Automatisch, wenn man so will.
ABER, da ich keine gescheiten Quellen habe und die online auffindbaren Quellen alle windig finde würde ich auch einen Revert locker verkraften. igel+- 23:41, 9. Aug 2006 (CEST)
Hi igel, danke für deine schnelle Reaktion. Ich hoffe nicht das diese Diskussion fruchtlos beendet wird (-: Also mein Problem sieht wiefolgt aus:
def methode obj
 obj.tolle_methode
end
Dieser Codeschnippsel führt keine automatische Reflection durch und wird unweigerlich eine NoMethode Exception werfen wenn die Methode :tolle_methode nicht verfügbar ist. Ruby und auch Smalltalk bieten die Möglichkeit den Code einer Introspektion zu unterwerfen, sie tun dies jedoch nicht automatisch. Genau das gleiche mit dem Duck Typing:
def methode obj
  raise ArgumentError if obj.respond_to? to_s
end
Diese Methode hätte eine Prüfung bezüglich Duck Typing. Die folgende Methode jedoch:
def methode obj
  raise ArgumentError unless obj.class == String
end
Würde einen Typcheck ähnlich wie in Java, C oder anderen nicht duck getypten Sprachen (der Ausdruck ist einfach zu geil (-:) durchführen.
Aufgrund dieser Punkte bin ich nun ein wenig verwundert, dass Ruby auf Duck Typing reduziert wird. Wenn du die Quellen findest bitte lass sie mir zukommen, ich sterbe für dieses Thema und möchte eventuelle Bildungslücken meinerseits gerne entfernen. Daniel Bovensiepen 23:51, 9. Aug 2006 (CEST)
*Schauder* Schon wieder ... Naja, ich kann ja kaum mal eine Bitte abschlagen, wahrscheinlich hast du mich so weit und heute abend google ich eine Runde, vielleicht werde ich ja auch "Programmierparadigmen" von Wagenknecht fündig, das habe ich noch nicht ganz durch.
Aber, mal ganz aus der Lamäng, ich denke mir jetzt eine sehr wenig optimierende VM wie die Squeak-VM. Und jetzt rufe ich deine Methode mit Zusatz
def methode obj
  raise ArgumentError unless obj.class == String
  puts obj.to_xml
end
auf. Die erste Zeile sorgt dafür, dass das obj wirklich ein String ist, da hört also das Duck-Typing mal einen Moment auf, wenn man so will. Aber schon in der nächsten Zeile hört der Spaß wieder auf, bei der Suche nach Methode to_xml wird der eben noch durchgeführte Typcheck völlig ignoriert, und es wird ins method dictionary geguckt, was obj denn so kann.
Man könnte auch ein künstliches Beispiel bauen, bei dem ein nebenläufiger Thread obj alle paar Millisekunden durch ein Objekt zufälliger Klasse tauscht, ich will sagen: schon ein paar Takte später ist die Variable unweigerlich wieder "duck typed".
Wenn einem duck typing also nicht gefällt und man Typ-Sicherheit für eine gewisse Zeitspanne haben möchte, dann kommt man, von merkwürdig gekünstelten Beispielen abgesehen, mit deinem Beispiel schon sehr weit. Es ist aber nicht die Art Typsicherheit, die sich ein Haskell-Programmierer oder Java-Programmierer wünschen würde, denn - und das ist jetzt weit weniger künstlich - man könnte in obigem Beispiel einen nebenläufigen Thread bauen, der die Methode to_xml alle paar Millisekunden zu String hinzufügt und gleich anschließend wieder entfernt. Will heißen: von der Kenntnis des Typs einer Variablen hast du im Hinblick auf ihr Interface eigentlich gar nichts. So gesehen könnte man schon sagen, Ruby ist immer und ständig "duck typed". igel+- 09:49, 10. Aug 2006 (CEST)
PS: Habe noch einmal durch den Artikel geguckt, ich glaube, dir geht es um so etwas:
if auto.respond_to?(:bremsen)
    auto.bremsen

Das ist nicht so recht der Kerngedanke des Duck-Typing. Typischer fände ich so etwas:

def rennen_fahren(auto)
auto.beschleunigen
auto.bremsen
end
Klar, wenn auto jetzt nicht bremsen kann, dann gibt es eine Fehlermeldung, es sei denn, man unterdrückt das in der Klasse (Smalltalk, aber iirc kann ruby das auch:)
! WildesAutoKannNichtBremsen addMethod: #doesNutUnderstand !
^ self ! !
Das tolle ist also, dass du der Methode rennen_fahren alles übergeben kannst, das bei bremsen und beschleunigen keine Fehler wirft (und ungefähr so reagiert, wie du es dir vorstellst). Dieses hinauszögern der Typprüfung weit in die Methode hinein hat "duck typing" den Namen gegeben. igel+- 10:06, 10. Aug 2006 (CEST)
So, da ich mich gerade durch ein paar Dokus gewühlt habe, hier eine offizielle Beschreibung von Duck Typing in Ruby:
# Say bye to everybody
def say_bye
  if @names.nil?
    puts "..."
  elsif @names.respond_to?("join")
    # Join the list elements with commas
    puts "Goodbye #{@names.join(", ")}.  Come back soon!"
  else
    puts "Goodbye #{@names}.  Come back soon!"
  end
end
The say_bye method doesn’t use each, instead it checks to see if @names responds to the join method, and if so, uses it. Otherwise, it just prints out the variable as a string. This method of not caring about the actual type of a variable, just relying on what methods it supports is known as “Duck Typing”, as in “if it walks like a duck and quacks like a duck…”. The benefit of this is that it doesn’t unnecessarily restrict the types of variables that are supported. If someone comes up with a new kind of list class, as long as it implements the join method with the same semantics as other lists, everything will work as planned.
Also in Gewisser Weise hast du also recht. Es geht bei Duck Typing darum, Code zu schreiben bei dem der Typ vollkommen irrelevant ist. Um diesen Code aber trotzdem halbwegs abzusichern, verwendet man zum Beispiel Reflektion. Ich werde bei Gelegenheit mal schauen wie man das schön in Worte fassen könnte. Daniel Bovensiepen 16:29, 12. Sep 2006 (CEST)
Nein, es geht bei Duck Typing darum, daß der Typ durch die Fähigkeiten festgelegt wird! In Ruby ist Typ nicht gleich Klasse und kann sogar zur Laufzeit geändert werden. Ruby ist nicht typlos, Typen sind aber hochdynamisch.
Wie schon im anderen Abschnitt brauche ich unbedingt eine Definition was für dich der Unterschied zwischen Typ und Klasse ist. Das ein Objekt nicht so aussehen muss, wie die Klasse es vorgegeben hat, ist klar aber Singleton Patterns sind wohl Besonderheiten die unabhängig von einem bestimmten Type oder auch Klasse sind. Deshalb verstehe ich deine Unterscheidung nicht. Welcher Typ kann zur laufzeit geändert werden? Meinst du vielleicht die Methoden Signaturen? Ich hab echt keinen Schimmer wie du das meinst )-: Daniel Bovensiepen 00:04, 15. Dez. 2006 (CET)
Lies halt die einschlägigen Artikel oder glaub' es halt einfach: Die beiden sind in Ruby nicht deckungsgleich. (In Java übrigens auch nicht, cf. Interface.)

[Bearbeiten] Logo

Sollen wir der englischen Wikipedia folge leisten und das Ruby-Logo, das u. a. auf der neuen Ruby-Website verwendet wird, statt des Textmate-Screenshots abbilden? Gissi 21:46, 9. Nov. 2006 (CET)

Hui, hab garnicht gesehen dass sie das Logo in der englischen Version geändert haben. Also von mir aus gerne. Gegenstimmen irgendwo? Daniel Bovensiepen 22:29, 9. Nov. 2006 (CET)

[Bearbeiten] Mehrapradigmigkeit

Die Mehrparadigmigkeit (gerade erfunden, das Wort) von Ruby war übertrieben. Ruby ist vor allem eine OO-Sprache, alle weiteren Paradigmen sind nur das Ergebnis der hohen Flexibilität (Funktional) bzw. langweilig (gibt es eine OO-Sprache, die man nicht zu einer prozeduralen umbiegen kann?).

Das Beispiel "Funktionen höherer Ordnung" sehe ich besonders kritisch. Ich bin bei funktionalen Sprachen nicht so zuhause: Kann bitte jemand erklären, was an diesem Beispiel so besonders funktional ist? --217.235.238.230

Ruby ist weder vor allem objektorientiert noch ist sie besonders funktional oder prozedural. Die Syntax erlaubt unterschiedliche Sprachparadigmen zu verwenden. Dabei ist es vollkommen egal ob die Basistypen halbwegs Objektorientiert sind, denn ich kann genausogut nicht objektorientierten Code mit Ruby schreiben. Daniel Bovensiepen 23:45, 13. Dez. 2006 (CET)
Ja, das stimmt ein Stück weit alles; Ausnahme ist der erste Satz, Ruby wird eben doch zum einen vor allem als OO-Sprache wahrgenommen, zum anderen wird eben das auch durch die Sprache nahegelegt. Ich kann auch mit C objektorientiert programmieren, darum würde ich C aber nicht gleich als multi-paradigmatische Sprache bezeichnen.
(Übrigens hatte ich eine Quelle angegeben. Es wäre nett, wenn Du Deine Argumentation gleichermaßen belegtest.)
(Bitte verteile die Diskussion auf die entsprechenden Themen, das macht sie leserlich.)
Du hast mindestens die Hälfte meiner Argumentation ignoriert. Nimm bitte dazu Stellung!
Du behauptest, daß die allgemeine Wahrnehmung "vollkommen irrelevant" sei, argumentierst aber zwei Sätze weiter damit, daß es "einige" Skripte gibt, die prozedural geschrieben sind. Wie erklärst Du diesen Widerspruch?
Weiterhin ist Ruby natürlich eine Multiparadigmen Sprache. Die allgemeine Warnehmung ist hierbei vollkommen irrelevant, da die meißten Leute die sich zu der dogmatischen OO-Aussage hinreißen lassen wenig praktische Erfahrung mit Ruby haben. OO ist sicherlich kein unwichtiges Paradigma bei der Verwendung von Ruby. Wenn du dir aber mal praktisch z.B. einige Skripte anschaust, welche in Ruby geschrieben wurden, wirst du kaum Unterschiede zu Shell oder Perl Skripten finden, welche ja wohl Allgemein eher in Richtung prozedurale Programmierung gehen. Daniel Bovensiepen 22:15, 14. Dez. 2006 (CET)
Das ich mir hier rethorisch Wiederspreche ist mir auf Anhieb nicht aufgefallen, zeigt aber nur, dass ich nicht gut schreiben kann. Der Punkt das Ruby viele Arten der Programmierung unterstützt und diese auch praktisch verwendet werden, sollte die Aussage unterstreichen. Daniel Bovensiepen 22:18, 14. Dez. 2006 (CET)
Daß Du Dir widersprichst zeigt, daß Deine Argumentation nichts taugt.
Ruby kann viele Arten der Programmierung unterstützen und trotzdem vor allem eine OO-Sprache sein.
Ein paar Zitate aus Pickaxe2:
"I wanted a language (...) more object-oriented than Python" (Matz in Foreword to the First Edition)
"No one in 1993 would have believed that an object-oriented language created by an amateur language designer would end up used worldwise (...)" (Matz in Foreword to the Second Edition)
"Ruby Is an Object-Oriented Language" (Überschrift des ersten Abschnitts des zweiten Kapitels)
"Let me say it again: Ruby is a genuine object-oriented language" (Der nächste Satz)
"Function see Method" (aus dem Index)

[Bearbeiten] Duck Typing

Daran habe ich auch etwas auszusetzen: Die Benutzung von Introspection ist typischerweise nicht die Art, mit der man Duck Typing umsetzt. Beim Duck Typing geht es um Vereinfachung, das kann man so wohl nicht bekommen.

Stattdessen erlaubt Ruby, Objekte einfach unabhängig von ihrer Klasse zu benutzen (was bei zB. Java der Compiler verhinderte), indem man ihnen einfach die Nachrichten schickt, die man für passend hält. Wenn man sein Programm auch nur einigermaßen im Griff hat, liegt man damit richtig.

Wenn man sich doch einmal nicht sicher ist, gilt Pythons "It's easier to ask for forgiveness than permission".

(Ach so, ja: Object#method_missing kann möglicherweise auch nützlich sein.) --217.235.238.230

Das ist eine vollkommen andere Betrachtungsweise, die aber irrelevant ist. Natürlich erlaubt Ruby eine Menge. Aber Duck Typing ist laut Literatur genau über Introspektion definiert. Sicherlich ist es ein schwammiger Begriff aber in der Ruby Community ist :respond_to? u.a. ein Teil von Duck Typing. Wie die Philosophie in anderen Sprachen aussieht kann ich nicht sagen. Daniel Bovensiepen 23:43, 13. Dez. 2006 (CET)
siehe Duck Typing
siehe en:Duck Typing
siehe Daves Definition von Duck Typing
Klar ist Introspection ein Teil von Duck Typing, aber eben kein so elementarer, wie in dem Artikel geschreiben stand.
(Bitte verteile die Diskussion auf die entsprechenden Themen, das macht sie leserlich.)
Deine Aussage ist unbelegt. Ich hatte Dich schon vorher gebeten, Deine Aussagen bitte zu belegen.
Hier ein Zitat aus Pickaxe2 über Duck Typing und Introspection: "However, before going down this path, make sure you're getting a real benefit - it's a lot of extra code to write an to maintain." Klingt das für Dich, als würde Dave Thomas, der Erfinder des Begriffs Duck Typing, Introspection an dieser Stelle für einen wesentlichen Bestandteil von Duck Typing halten?
Duck Typing ist ein in der Ruby Community entstanden Begriff. In dem in Artikel erwähnten Werk (Programming Ruby) wird das Thema Duck Typing mit der Introspektion von Ruby nicht nur in Verbindung gebracht sondern praktisch verwendet. Pickaxe2 Kapitel 23 Abschnitt 'Coding like a Duck' zeigt klar ein Codebeispiel das die entsprechende Introspektion verwendet. Daniel Bovensiepen 22:15, 14. Dez. 2006 (CET)
Doh. Hier der Satz, der unmittelbar hinter dem Beispiel steht (übrigens nachdem schon fünfeinhalb Seiten über Duck Typing gesprochen wurde, ohne daß Introspection thematisiert wird): "However, before going down this path, make sure you're getting a real benefit - it's a lot of extra code to write an to maintain."
Na sowas, das ist ja genau der Satz, den ich bereits oben zitiert habe!!!
Sag mal, hast Du das Buch eigentlich gelesen oder nur gerade eine Volltextsuche im PDF gemacht?
Der Begriff Duck Typing ist nicht einfach "in der Ruby Community" entstanden, sondern von Dave Thomas erdacht. Siehe oben für seine Definition, die komplett ohne Introspection auskommt.

Hier nochmal ein Erklärungsversuch: Introspection ist für die Definition von Duck Typing schlicht irrelevant. DT beschreibt einfach nur, wie in Ruby Typen definiert sind: Nämlich lediglich durch ihre Funktionalität, nicht durch ihre Klasse (die gibt nur den Anfangsbestand and Funktionalitäten vor). In zB. Java kannst Du ein Objekt nur ansprechen, wenn Du die Klasse kennst. In Ruby reicht es zu wissen, daß eine bestimmte Methode unterstützt wird.

So, und jetzt kannst Du Introspection benutzen, um Dich abzusichern. Wie oben schon geschrieben, halte ich Exceptions (oder sogar Object#method_missing) für deutlich praktischer; das ist letztlich eine Frage der persönlichen Vorliebe, macht aber klar, daß man auch für "sicheres" Duck Typing kein Introspection braucht.

[Bearbeiten] Bezüglich Revert der Änderung von 217.235.238.230

Ich habe gerade die gesamten Änderungen von 217.235.238.230 rückgängig gemacht. Nicht etwa weil sie alle falsch waren, sondern weil wichtige Teile aus Ihrem Kontext gerissen oder sogar entfernt wurden. Wenn es fachliche Mängel gibt, so würde ich empfehlen diese hier erst zu diskutieren anstatt diese einfach auf gut Glück aus dem Artikel zu löschen. Daniel Bovensiepen 23:48, 13. Dez. 2006 (CET)

Ich habe gerade die gesamten Änderungen von Daniel Bovensiepen rückgängig gemacht. Ebensowenig wie Daniel habe ich Bock, richtig und falsch auseinanderzusortieren, also mache ich ebenso wie er einfach alles rückgängig, was mir irgendwie nicht in den Kram paßt. Wenn es fachliche Mängel gibt, so würde ich empfehlen diese hier erst zu diskutieren anstatt diese einfach auf gut Glück aus dem Artikel zu löschen. --62.225.37.69
Hi du, wie du sicherlich bemerkt hast, hab ich die Änderung natürlich wieder rückgängig gemacht. Es sollte doch im Allgemeinen verständlich sein, dass der Status Quo in einem gereiften Artikel erst mal zu wiederlegen ist, bevor man fachlich Falsche Änderungen vornimmt. Dann ist natürlich noch zu erwähnen, dass die Sprache Ruby nicht zwangsläufig Interpretierbar sein muss. Weitere Informationen diesbezüglich, gibt es im Implementationsabschnitt. Weiterhin ist mir unklar was an deinem Beispiel im funktionalen Bereich nun wirklich funktional sein soll. Es geht doch um eine Art der Programmierung wo Funktionen (in Ruby über Methoden simuliert) im Mittelpunkt stehen und sich gegenseitig Werte übermitteln. Dies gelingt, wie du schon richtig beschrieben hast, dadurch das Rubys Ausdrücke selbst in den meißten Fällen sinnvolle Werte zurückliefern. Weiterhin ist es mir unbegreiflich, weshalb du Vergleiche mit artverwandten Sprachen (wie z.B. Haskell) aus dem Text rausschmeißt. Wie soll der Leser das Ganze denn im Kontext verstehen wenn Ihm keine Vergleichsbeispiele geliefert werden? Und was ich beinahe vergessen habe: Die Aussage das Ruby nicht streng typisiert sei ist ja wohl nen Gag oder? Ich habe bisher noch kein Objekt in der Rubywelt gefunden, was sich zwischendurch mal entschied seine Klasse zu ändern. :to_s! existiert nicht und würde wohl einige logische Lücken in das Sprachdesign reißen. Daniel Bovensiepen 22:19, 14. Dez. 2006 (CET)
Zunächst mal solltest ein wenig vorsichtiger sein. Ich habe verstanden, daß Du große Teile des Artikels geschrieben hast, das bedeutet aber nicht, daß Deine Fehler nicht verbessert werden dürfen. Laß es mal ruhiger angehen und faß die Möglichkeit ins Auge, daß Du Unrecht hast.
Solange Du zugibst, daß meine Änderungen teilweise richtig sind ("Nicht etwa weil sie alle falsch waren"), Du aber trotzdem blindwütig alles revertierst, muß ich leider von bösen Absichten ausgehen.
WP:AGF! Nur weil ich als IP arbeite, heißt das noch nicht, daß ich weniger von Ruby verstehe als Du.
Habe nie behauptet, dass du weniger qualifiziert bist, einen Artikel in der Wikipedia zu schreiben. Trotzdem finde ich es interessant, dass eine IP von heute auf Morgen durch die WikiP streift und sämtliche Artikel die bezogen auf Programmiersprachen sind editiert und dabei (wie z.b. beim Java Artikel) ziemliche kontroversen auslöst. Ich behaupte weiterhin auch nicht, dass ich frei von Fehlern bin und jede Änderung am Artikel negative folgen hat. Ganz im Gegenteil. das Problem ist nur, wenn du vorbeikommst und hier was rausstreichst und da was einfügst, dann entsteht ein riesiger Flickenteppich der im großen Kontext fachlich falsch und/oder unverständlich ist. Zum Thema Duck Typing haben wir hier schon mit vielen/vielen Leuten diskutiert und die bisherige Version war ein Kompromis der durch viele Köpfe gegangen ist. Nun löscht du diesen Kompromis und belegst das ganze mit Dingen die alle schonmal durchgesprochen wurden. Weiterhin gehst du bei und änderst so fundamentale Dinge wie die Typisierung und ignorierst damit allgemein anerkannte Dinge. Ich möchte ja durchaus das du dein fachliches Wissen einbringst. Aber dieser Artikel wurde nun von sovielen qualifizierten Leuten gelesen und verbessert und nun nimmst du für dich selber heraus alles besser zu wissen? Also ich will mich echt nicht streiten ich hänge nur sehr daran, dass die Informationen die hier stehen ein sinnvolles Bild abgeben. Daniel Bovensiepen 23:07, 14. Dez. 2006 (CET)
Ich glaube kaum, daß Du begeistert wärst, wenn jemand behauptest, Du würdest "fachlich falsch rumkritzeln". (WP:KPA lassen wir mal außen vor.) Da würde ich schon sagen, daß Du erstmal von geringer Qualifikation ausgegangen bist.
Wenn ich das richtig verstehe, war das Ergebnis in Java (Programmiersprache), daß meine Version Bestand hat. Was bedeutet das für meine Änderungen hier?
Die Diskussion über Duck Typing habe ich nur überflogen, die werde ich gleich nochmal lesen. Wichtig ist aber, daß die Erklärung im Artikel falsch oder zumindest irreführend war.
Ich habe inzwischen gelernt, daß Matz die Sprache als Strongly Typed betrachtet. Trotzdem muß der Widerspruch aufgelöst werden, der hier in der Wikipedia besteht.
Übrigens: Wenn ich ein wenig genervt bin, dann wegen der Art, wie ich hier ausschließlich vervorurteilt werde. Dazu mag ich es einfach nicht, wenn falsche Belege benutzt werden, um Argumente zu untermauern.
Also wenn du dir einen Account holen würdest, könnte man dich auch persönlich ansprechen und würde sicherlich nicht so ruppig sein. Zum Thema KPA etc. darfst du hier jetzt aber nicht die beleidigte Leberwurst spielen. Wenn man bei seinen Änderungen erwähnt, dass die Leute welche an den Informationen arbeiten, geistig umnebelt sind, sollte man auch mit einer anderen Art von Konversation rechnen. Aber ich möchte mich bei dir entschuldigen, wenn ich dich herablassend behandelt habe. Zum Thema Duck Typing, strong Typing und so weiter haben wir wohl ein riesiges Problem. Und zwar das jeder etwas anderes darunter versteht. Duck Typing macht für mich persönlich nur eingeschränkten Sinn, wenn man nicht die Sicherungsmaßnahmen erwähnt, welche ja vom ursprünglichen Autoren auch beschrieben wurden. Sicherlich sehe ich ein, dass er im nächsten Satz, sein Konzept in frage stellt aber wer macht das nicht? Testen ist auch eine tolle Sache trotzdem schreiben viele Leute exakt das gleiche => Vorteile abwägen und bei Bedarf verwenden. Sollte man deshalb Softwaretests aussen vor lassen? Ich würde sagen Nein und genauso würde ich die Sicherungsmaßnahme als sauberes Duck Typing ebenfalls mit in den Artikel nehmen. Du hast wahrscheinlich recht wenn du sagst, dass es wichtigere Aspekte bei diesem Thema gibt aber vielleicht kann man die erwähnung ja auch irgendwie kürzen. Wichtig finde ich sie trotz alldem. Daniel Bovensiepen 23:36, 14. Dez. 2006 (CET)
Ich habe meine Gründe, warum ich mich nicht anmelde.
Ich nehme mal an, die "geistige Umnebelung" bezieht sich auf meinen Satz "Keine Ahnung, was die geraucht haben." Das bezieht sich nicht auf die Wikipedia, also sehe ich kein gesteigertes Problem.
"Zum Thema Duck Typing, strong Typing und so weiter" sollten wir lieber in den passenden Abschnitten diskutieren.

[Bearbeiten] Strongly Typed

Als erstes schlage ich mal vor, daß Ihr Starke Typisierung lest. Da paßt so ziemlich garnichts auf Ruby.

Dann zu Daniels Aussage: "Die Aussage das Ruby nicht streng typisiert sei ist ja wohl nen Gag oder? Ich habe bisher noch kein Objekt in der Rubywelt gefunden, was sich zwischendurch mal entschied seine Klasse zu ändern." Antwort: Klasse != Typ

Daß Du die beiden Dinge hier durcheinanderbringst ist entweder Ausdruck von fehlendem Verständnis für Ruby oder eine, sagen wir mal freundlich, abenteuerliche Art der Argumentation.

Willst du darauf hinaus, dass in Ruby Referenzen keinen Typ besitzen und deshalb eine Starke Typisierung (eigentlich garkeine Typisierung) nicht möglich erscheint? Diese Denkweise halte ich persönlich für viel abenteuerlicher. Typen existieren in Ruby in Form von Objektklassen, die zu einem bestimmten Zeitpunkt einen bestimmten Speicherbereich und eine bestimmte Identität besitzen. Wenn wir nun ein Objekt der Klasse Fixnum erstellen, z.B. 2, so gibt es keine Möglichkeit dieses Objekt in einen String "2" zu verwandeln. Aber ich glaube darauf willst du überhaupt nicht hinaus. Könntest du mir kurz erklären, wie du Klasse und Typ definierst? Daniel Bovensiepen 22:34, 14. Dez. 2006 (CET)
Der zweite Satz im Abschnitt über Duck Typing, aus dem Du anderswo zitierst, lautet: "an object's type is determined by what it can do, not by its class."
Das wird mir zu dumm, lies bitte erstmal das maßgebliche Werk, bevor Du mir vorwirfst, daß ich "fachlich falsch rumkritzele".
Nochmal für Diskussionteilnehmer, die unangenehme Tatsachen ignorieren: In Starke Typisierung paßt so ziemlich garnichts auf Ruby. Nimm bitte dazu Stellung.
Ich habe immer noch das Problem, dass ich nicht weiß wie du die Dinge definierst. Unabhängig davon erzähle ich dir, wie ich die Dinge sehe. Wenn ich ein Objekt von einer bestimmten Klasse erbe, gibt es eine Beziehung zwischen Klasse und Objekt die sich nicht auflösen lässt. Es besteht also eine ähnliche Beziehung wie zu einem Datentyp. Sicherlich treffen nicht sämtliche aspekte eines regulären Datentyps auf eine Klasse zu aber es gibt doch Ähnlichkeiten wie z.B. die Kategorisierung und die Verwaltung von Speicher der halt in manchen Sprachen Typabhängig ist aber in Ruby Klassenabhängig. Wenn ich nun eine Klasse als eine Art Typ sehe, treffen einige der Punkte aus Starke Typisierung durchaus zu. Zum Beispiel ist es, wie bereits erwähnt, unmöglich einem Objekt eine andere Typidentifikation zu geben. In Rubyland also unmöglich einem Objekt eine andere Klasse zuzuordnen. Ich verstehe natürlich deine Argumentation. Und die Dinge sind nicht so einfach wie ich sie hier formuliere. Zum Beispiel können Klassen zur laufzeit ja geändert werden und für manche verlieren Sie dadurch Ihren Typcharakter. Ich kann mich dieser Meinung nicht anschließen, da es doch eigentlich vollkommen wurscht ist, wann ein Typ definiert wird. In Ruby ist ein Objekt immer an eine spezielle Klasse gebunden und das lässt sich nicht aufheben, folglich definiere ich Ruby als stark typisiert oder auch (um es passender zu sagen) stark klassifiziert. Daniel Bovensiepen 23:55, 14. Dez. 2006 (CET)

Wir sprechen von objekt-orientierten Sprachen, nicht von klassen-orientierten. JavaScript zB. kennt keine Klassen; Ruby benutzt Klassen, um ein Objekt anzulegen, der Typ des Objektes bleibt aber nicht zwingend darauf beschränkt, was von der Klasse vorgegeben wird. Lies Starke Typisierung nochmal, vergiß aber diesmal Deine Gleichstellung von Klasse und Typ (die ist nämlich falsch). Ich kann in Ruby einem Objekt sehr einfach einen neuen Typ geben:

foo = String.new("Hallo Welt")
def foo.bar
    puts "Nicht sinnvoll, aber möglich"
end

(Ich habe jetzt keine Lust, auszuprobieren, ob auch def foo.bar = nil oder so geht.)

Vielleicht noch relevanter:

collection.each do |thing|
    if ! thing.respond_to?(:foo)
        def thing.foo
            puts "Now I know how to foo!"
        end
    end
end

(Laß Dich bitte nicht davon ablenken, daß ich Reflection benutze: Ich habe nie abgestritten, daß das nützlich ist.)

Auch nett (und wie alles andere ungetestet):

def Object.method_missing(symbol)
    if "Daniel" == symbol.id2name[1..6]
        def self.symbol.id2name
            puts "Daniel ist der Größte!"
        end
    end
end
foo = String.new
foo.Danielbar

Ne, klappt nicht, ich habe jetzt keine Lust, das zu debuggen.

[Bearbeiten] Interpreter

Ich verzichte hier mal darauf, ein Programm zu schreiben, daß nicht compilierbar ist, aber sehr wohl interpretierbar. Tatsache ist, daß Ruby Möglichkeiten hat, die einen traditionellen Compiler überfordern und einen Interpreter oder wenigstens Jitter erfordern.

Zweitens: Bitte liste mal alle wichtigen Ruby-Implementierungen auf, die nicht interpretiert sind.

Hi, sorry für die Verwirrung. Ich wollte mit dem Argumten zum Interpreter sicherlich nicht behaupten, dass Ruby dafür prädestiniert ist, kompilierbar zu sein. Aber nur weil es mit traditionellen Compilern und Prozessoren schwierig erscheint ist es nicht unmöglich. Ich habe mich hierbei nur z.B. an dem BASIC Artikel orientiert. Wobei BASIC wohl die Sprache ist, die jeder als interpretiert ansieht. Trotzdem wird dieser Fakt im Artikel nicht in der Einleitung erwähnt. Solche spezifischen Informationen stehen deshalb auch im Implementationsbereich. Aber nun gut, dass ist ein Punkt über dem man, wie bei scheinbar sovielen Dingen, trefflich streiten kann. Daniel Bovensiepen 22:42, 14. Dez. 2006 (CET)
Ruby ist zur Zeit interpretiert, durch seine Eigenschaften ist ein Interpreter naheliegend. Wenn jemand einen relevanten Compiler schreibt, wird der Artikel geändert, so einfach ist das. Bis dahin muß der Artikel nicht auf Details verzichten, die möglicherweise vielleicht irgendwann mal falsch sein könnten.

[Bearbeiten] Funktionalität

(Bist Du ein Troll? Ich wundere mich gerade darüber, daß ich Grundlagenwissen über Ruby vermitteln muß.)

Das if ist funktional. Das ist zB. bei C nicht so.

"Funktionen, die sich gegenseitig Werte übermitteln"? Huh? Warum paßt das nicht auf C, Perl oder Java? Sind die auch alle funktional?

Haskell habe ich rausgeworfen, weil eine Erklärung fehlt, was an dem Beispiel funktional sein soll. Nur weil Sprache A funktional ist Eigenschaft E aufweist, ist ein Vorkommen von E noch kein Hinweis auf funktionalität.

Schön das du mir Ruby endlich mal so richtig näher bringst. Dir ist aber schon bewusst, dass wenn man sich den Hut aufsetzt und behauptet, dass eine Sprache XY z.B. funktionale Eigenheiten bietet man dies am Besten an schon bestehenden Beispielen tut. :map ist in diesem Fall gerade deshalb erwähnt worden, weil es ähnliche Beispiele bei anerkannten funktionalen Sprachen gibt. Wie auch z.B. Haskell (deshalb der Link). Wenn sich eine funktionale Sprache also dadurch auszeichnet, dass man mit Funktionen selbst logisch hantieren kann, so ist es doch ein sinnvolles Beispiel dies so auch in Ruby zu zeigen. Dein Beispiel mag dabei vielleicht aus Implementationssicht funktional arbeiten aber springt das dem Leser auch so direkt ins Auge? Mir persönlich nicht aber das ist natürlich wieder Subjektiv. Daniel Bovensiepen 22:51, 14. Dez. 2006 (CET)
War das eine Antwort? Nochmal: Nur weil Sprache A funktional ist und Eigenschaft E aufweist, ist ein Vorkommen von E noch kein Hinweis auf Funktionalität. Google mal nach "Cum hoc ergo propter hoc".
Mein Beispiel ist nicht optimal. Bitte finde ein besseres.

[Bearbeiten] Ruby Game Scripting System

Erwähnenswert?WilhelmHH 02:16, 9. Mai 2007 (CEST)

würde ich sagen. RGSS gesitzt Klassen über die Ruby leider nicht verfügt. (Beispiel: Color Class)--212.202.231.117

[Bearbeiten] AspectR

Damit kann ruby um Aspekte erweitert werden ohne das es eine gesonderten Compiler wie unter Java nötig wäre. --217.5.205.2

[Bearbeiten] Überarbeitung

Bin gerade dabei, den Artikel vollständig zu überarbeiten: Benutzer:Blinry/Ruby (Programmiersprache), vielleicht ist der Diff zur aktuellen Version hilfreich.

Dabei habe ich nichts weggeworfen, sondern erweitert, ergänzt und umstrukturiert. Wenn keine größeren Einwände kommen, werde ich den Artikel in ein, zwei Wochen ersetzen. Offensichtliche Schnitzer könnt ihr ja direkt ändern.

Wesentliche Änderungen:

  • Vereinfachung der Codebeispiele, man kann nicht erwarten, dass jeder Leser die Syntax von Ruby draufhat
  • generell verständlichere Formulierungen, omatauglicher erster Satz
  • Angabe von einigen Quellen, Links aufgeräumt und Formatierungen angepasst
  • Umstrukturierung der Abschnitte

Worüber ich noch unzufrieden/unsicher bin:

  • Das Logo weist in den Farbübergängen Streifen auf (getestet mit Firefox 3.0b5 und Opera 9.27). Lohnt es, ein png in der richtigen Größe draus zu rendern?
  • Besserer Ausdruck für die Überschrift "Bestandteile"?
  • Gehört eine Beschreibung der Syntax überhaupt in den Artikel? Von wegen Anleitung? Oder - auf der anderen Seite - kann es weiter ausgebaut werden, wie in Perl oder Python?

Was ich noch vorhabe:

  • Literatur und Quellen ergänzen
  • Nachteile/Kritik
  • Mehr über aktuelle Entwicklung (2.0)

--Blinry 16:04, 12. Mai 2008 (CEST)

Nach knapp zwei Wochen und einigen zusätzlichen Verbesserungen ersetzte ich jetzt den Artikel. Die oben genannten Fragen sind noch offen. Vielleicht klärt ein Blick in die Versionsgeschichte einige Fragen bezüglich der Änderungen. --Blinry 19:58, 24. Mai 2008 (CEST)


aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -