Diskussion:Ruby (Programmiersprache)

aus Wikipedia, der freien Enzyklopädie

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.

-Ich kenne mich leider auch nicht mit Ruby aus aber es fehlt eindeutig ein Absatz in dem erklärt wird wofür Ruby primär eingesetzt wird und für welche Anwendungen es sich am besten eignet. (man vergleiche den Artikel Python) --82.83.102.36 12:17, 27. Jul. 2010 (CEST)

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)

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)

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)

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]

[Bezü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)

Bezgüglich?

Da hat wohl wer am Vortag vom Schreiben vom Beitrag zu stark zu viel was gegoogelt (was bei Google gesucht)? Oder war das ein Rechtschreibfehlerchen dann? Jedenfalls habe ich das nachkorrigiert dann. ...--2001:16B8:5734:4F00:F40A:18B9:2A6:1F82 18:14, 24. Aug. 2021 (CEST)

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)

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)

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.)

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)

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)

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.

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.

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.

Interpreter

Ich verzichte hier mal darauf, ein Programm zu schreiben, daß nicht kompilierbar 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 Argument 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, das ist ein Punkt über den man, wie bei scheinbar so vielen Dingen, trefflich streiten kann. Daniel Bovensiepen 22:42, 14. Dez. 2006 (CET)
Der Behauptung, daß BASIC von jedem als Interpreter-Sprache angesehen wird, möchte ich hier ganz energisch widersprechen. BASIC war von Anfang an eine kompilierte Sprache, erst mit der Einführung der Mikrocomputer Mitte der 1970er Jahre fanden die ersten BASIC-Interpreter größere Verbreitung. Microsoft und IBM waren ab 1981 hierbei äußerst aktiv, wodurch die heutige Popularität dieser Interpreter überhaupt erst erreicht werden konnte. Dies ändert jedoch nichts an der Tatsache, daß die Softwareindustrie bis heute die kompilierten Dialekte wie z.B. VisualBasic vorzieht. --YoSuwa (Diskussion) 17:08, 19. Nov. 2013 (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.

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.

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

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

Alles was man zu aspektorientierter Programmierung in Ruby benötigt ist alias_method_chain (Active Support). Zu dem Thema wäre aber vllt. auch ContextR interessant. -- FF-Wonko D•B 11:21, 14. Feb. 2009 (CET)
Habe es trotzdem eungebaut. -- FF-Wonko D•B 19:52, 16. Feb. 2009 (CET)

Ü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. --Blinry 19:58, 24. Mai 2008 (CEST)


Visitoren vs Iteratoren

Ich hab früher schon gelesen, dass hier beschrieben wird, dass ruby bei Blöcken "Iteratoren" benutzt und das dahingehend geändert, dass ruby Visitoren benutzt. Jetzt wurde das wieder dahin zurück geändert, dass da steht in Blöcken wird mit Iteratoren gearbeitet, mit der Begründung, dass das "treffender" sei. Entschuldigung, aber das ist quatsch. Könnte man das mal bitte einmal fest klären und dann soweit fest lassen? Meine Begründung warum in Ruby Visitoren genutzt werden:

Iteratoren: Mein geschriebener Code hat ein Element mit dem man das iterieren durch die Schleife steuert. Bei einem Iterator ruft mein Code auf wann der nächste Schritt gegangen wird. In Java z.b. über die "next()" Methode. Man muss erst über den Iterator das eigentliche Element holen und selber prüfen ob man weiter iterieren kann. Das heißt man kann auch gezielt zwei mal next() aufrufen und somit ein Element überspringen.

Visitoren: Mein geschriebener Code bekommt das Element, dass bei diesem Schleifendurchgang betrachtet wird und nur das Element. Die komplette Steuerung des iterierens kontrolliert anderer Code.

Codebeispiel bei Ruby: 

 5.times do |i|
   puts i+1;
 end

i ist *kein* Iterator, da ich bei i in keinster Weise bestimmen kann ob und wann das nächste Element geholt wird. Sondern i ist das Element auf dem ich direkt arbeite. Insofern wird hier das Visitor-Pattern verwendet, denn mein selbstgeschriebener Code (der Block in ruby) ist ein Visitor für die Liste (Im Beispiel 1 - 5). (Der vorstehende, nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von 88.79.80.98 (Diskussion • Beiträge) 17:23, 20. Okt. 2008)

Pickaxe 2nd Edition, Seite 49: "iterator -- a method that invokes a block of code repeatedly". Der Begriff bezieht sich nicht auf die Variable, sondern auf den von dir beschriebenen Code, der über den Block iteriert. Hab mal versucht, das im Artikel klarzustellen. --Blinry 19:39, 20. Okt. 2008 (CEST)


Zuerst mal: ich hab die Änderung zwar nicht gemacht, war aber derjenige, der den Änderer dazu angefacht hat ;). Ein lange Fassung der Hintergründe findest du hier: http://forum.ruby-portal.de/viewtopic.php?t=8166 (nur zur Sicherheit, falls ich in der folgenden Zusammenfassung was vergesse)
Also erstmal: #each, #map usw. objektorientiert zu beschreiben finde ich eher schlecht, da diese Features eindeutig von Lisp und anderen funktionalen Sprachen inspiriert sind. Es geht hier also durchaus um einen Iterator, aber im Sinne des allgemeingültigen Konzepts, nicht des Patterns, das in der Gang of Four mal beschrieben wurde.
Wenn mans trotzdem unbedingt versucht:
Blöcke sind eindeutig keine Visitoren. Visitor setzt voraus, dass das "besuchte" Objekt Besucher akzeptiert. Das heisst, mein Blockparameter würde den Block übergeben kriegen und darf ihn akzeptieren oder verwerfen, wäre also aktiv. Das ist in eindeutig nicht der Fall, Blockparameter sind passiv und können sich nicht gegen den Besuch "wehren". Andernfalls hast du ein Strategy-Pattern. Strategy ist aber in einer Sprache, die Lambda-Ausdrücke unterstützt relativ sinnlos. (Strategy beschreibt im Prinzip ein Objekt, das einfach nur "call" unterstützt und damit Code rumreichen kann)
Also: Iterator auf jeden Fall, Strategy wenn man unbedingt will, Visitor auf keinen Fall. Strategy wuerde ich in diesem Fall deshalb nicht unterschreiben, weil Blöcke in Ruby nur Laufzeitobjekte sind, wenn man den Interpreter dazu zwingt. Also in keinem der beiden beschriebenen Fälle.
Anmerkung: ich beziehe mich hier auf die Patterns beschrieben in "Design Patterns. Elements of Reusable Object-Oriented Software" von Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (die sogenannte Gang of Four). Die meisten Wikipedia-Definitionen machen den Unterschied zwischen Strategy und Visitor nicht richtig klar. --Florian Gilcher
Noch konkret zu deinem Beispiel: klar ist i kein Iterator. Der Iterator ist das interne Verhalten von #times. i ist das Element. Und times kann durchaus bestimmen, in welcher Reihenfolge es seine Elemente holt. In Ruby 1.9 kannst du dir dieses Objekt auch explizit holen. Code mit iterierendem Verhalten muss dem Nutzer auch nicht zwingend die Möglichkeit überlassen, die Elemente zu verwerfen, indem er zweimal next() aufruft. In Java macht das zum Beispiel die iterierende for-Schleife. --Florian Gilcher
Ok, sorum, ja, gut, kann ich nachvollziehen. Aber dann bitte ich darum beim Schreiben des Textes klar zu machen, dass mit der Aussage, dass Iteratoren verwendet werden nicht das Iterator nach GoF gemeint ist somit das "i" kein Iterator ist. Einfach um Missverständnisse auszuschließen. --88.79.80.98 11:48, 24. Okt. 2008 (CEST)
Ich schreib mal morgen noch was dazu. Wobei ich zugeben muss, dass Blöcke wirklich das Feature von Ruby sind, das am schlechtesten in kurze Worte gefasst ist.

Native Threads vs Green Threads, zum Punkt Kritik

Der Punkt "Ruby unterstützt keinen natives Threading" (vgl. 1.Punkt bei Kritik im Originalartikel) ist leicht missverständlich. Die Threads werden von Ruby selbst gemanaged, nicht vom Betriebssystem, das ist richtig, es unterstützt damit kein natives Threading, jedoch sehr wohl multithreading. Dass dadurch jedoch die Möglichkeiten eines Multiprozessors nicht ausgenutzt werden könnten kann ich nicht nachvollziehen. Ich dachte immer, sowohl das eine als auch das andere hätte seine Vor- und Nachteile. Wenn Sie der Autor oder ein Verfechter seiner Meinung und ich in Einklang kommen können, möchte ich die entsprechende Stelle korrigieren.

Grüße Wolfgang

Zudem stimmt es nicht, dass nur weil man Greenthreads auf Ruby-Ebene anbietet, dass man keine nativen Threads nutzen kann. Das eigentliche Problem mit Ruby < 1.9 ist, dass es nicht mehrere native Threads zum Ausführen von Ruby nutzt. Das hat aber eher mit dem Problem der Thread Safety zu tun, nicht aber mit den Threads auf Ruby-Ebene. Rubinius z.B. ist Thread-Safe, sodass in einem Prozess mehere VMs laufen können, auf die die Greenthreads dynamisch verteilt werden können, sodass ein n:m-Threading entsteht und sehrwohl mit Greenthreads mehrere Prozessoren verwendet werden können. Damit stimmt zwar der Kritikpunkt, dass Ruby 1.8 und davor die Threads in einem Prozess nicht auf mehreren Prozessoren parallel ausführen können, dies liegt aber nicht unbedingt daran, dass es sich dabei um Green Threads handelt. Native Threads bringen eher den Vorteil, dass das Scheduling vom Betriebssystem übernommen wird, und nicht auf höherer Ebene, was unter Umständen effizienter ist. Mehrere Prozessoren lassen sich durch mehrere Prozesse auch mit älteren Ruby-Versionen nutzen. -- FF-Wonko D•B 12:20, 7. Jan. 2009 (CET)

Kritikpunkte

Hi!

Habe bei den Kritikpunkten den ersten weggenommen, die Quelle war falsch. (Ah, trotzdem stehts noch bei stable...) "Da Variablen vor Gebrauch nicht deklariert werden müssen, können bei Tippfehlern unerwartete Laufzeitfehler auftreten.[13]" (in der Quelle steht _nichts_ von Tippfehlern) Nichtsdestotrotz ist dieses Argument falsch. Beispiel: C++-Code:

int foo() { 

 int m=9;
 string M="...";
 return M; // Tippfehler führt zu Typfehler!!

}

...

sqrt(foo()); Ruby-Code: def foo 

 m = 9
 M = "..."
 return M

end

...

sqrt foo # Tippfehler führt zu Laufzeitfehler

Übrigens gibt's auch umgekehrte Beispiele.

"Duck-Typing reduziert die Möglichkeit, statisch zur Übersetzungszeit Fehler im Programm zu finden. Etwaige Fehler treten erst zur Laufzeit auf." Hier steht keine Quelle bei, ich schlage vor das zu entfernen. Denn: 1. statische getypte Sprachen erzeugen oft - ungewollt - Übersetzungsfehler Beispiel: typedef std::vector<std::string>::const_itertor iter; // wer findet den Fehler? ;-) for (iter i; i=v.begin(); i!=v.end) cout << *i << endl; Nicht umsonst wird für diesen Fall in C++-0x das Keyword auto eingeführt, um Übersetzungsfehler durch Tippfehler zu minimieren (und natürlich die Tipparbeit). 2. Typisierung schützt nicht vor allen Typfehlern

struct A { 

 A() { b=true; }
 A(int k) { b=false; cout << k << endl; }
 bool operator==(A a) { return b==a.b; }
 bool b;

}; //... A z; int Z=7; A t=Z; // Tippfehler!! if (z==t) 

 cout << "wenn t=z gewesen wäre, wär das hier aufgerufen worden\n";

else 

 cout << "der Konstruktor hätte mit explicit modifiziert werden müssen :( \n";

}

in Ruby wäre zwar bei t=Z kein Fehler aufgetreten. Dafür aber bei dem IF-Statement, da zwei inkompatible Klassen miteinander verglichen wurden.

Daher ist obiger Punkt Theoriefindung und ich werde ihn deshalb jetzt entfernen... ;-)

--Haize 16:30, 27. Dez. 2008 (CET)

Sorry, war beim ersten Punkt zu voreilig... Verpeilt... Reverte es :-) --Haize 16:37, 27. Dez. 2008 (CET)

Spezifikation

RubySpec wird von allen gängigen Implementierungen (inklusive MRI) als Spezifikation anerkannt. Damit trifft der Kritikpunkt betreffs der Spezifikation nicht mehr zu. Ich habe ihn entfernt. -- FF-Wonko D•B 22:52, 6. Jan. 2009 (CET)

Korrektur "interpretiert" vs "ist interpretiert"

Diese Änderung ist keine Rechtschreibänderung, sondern eine inhaltliche Änderung. Was jetzt da steht macht nicht viel Sinn und die alte Aussage (auch wenn sie schlecht formuliert war) ist nicht mehr da. -- FF-Wonko D•B 21:33, 10. Mär. 2009 (CET)

Eignung als Skriptsprache im Browser

Zunächst mal: ich bin auf diesem Gebiet absoluter Laie. Aber eine Info, die mich als Laie interessiert hätte, habe ich nicht gefunden und das sollte im Artikel erwähnt werden. Nämlich, ob sich Ruby auch als clientseitige, in Webseiten integrierte Skriptsprache (als Ersatz für JavaScript) eignen würde. Ich weiß natürlich, dass JavaScript der Standard ist und es schwer wäre, das zu ersetzen, dennoch mag ich JavaScript nicht und mich würde interessieren, ob es beim Webdesign theoretisch durch Ruby ersetzt werden könnte. -- 82.113.121.50 15:26, 16. Aug. 2010 (CEST)

Man könnte natürlich alle möglichen Programmiersprachen zum Skripten im Browser benutzen. Problematisch dabei ist, dass dann halt alle Browser Interpreter für alle diese Skriptsprachen haben müssten. Ansonsten ist die Web-Anwendung, die man schreibt, auf die Browser angewiesen, die die Sprache unterstützen, die man gerne hätte. Da das vorwärts und rückwärts nicht viel Sinn ergibt, ist das sinnvollste eben eine Sprache. Der historische Zufall hat uns JavaScript beschert, und dort werden wir wohl vorerst steckenbleiben. (Wobei die Sprache an sich nicht soo schlecht ist — nahezu ein LISP im C-Syntax-Gewand. )
Wie dem auch sei, um auf den anderen Teil der Frage zurückzukommen (Erwähnung im Artikel): Nein, ob Ruby als Browser-Skriptsprache taugt, gehört m.E. nicht in den Artikel. Aufgrund von zwei Trivialitäten: 1) (Oben bereits erwähnt) Jede Turing-vollständige Sprache ist geeignet. 2) Ruby ist in allen denkbaren "Wirt"sprogrammen als Skriptsprache einsetzbar. --Daniel5Ko 23:25, 16. Aug. 2010 (CEST)
Ich schließe mich den Vorrednern an. JavaScript können heute alle Browser. Selbst wenn Ruby ab sofort unterstützt wird, sind noch über ca. 5 Jahre alte Browser unterwegs, so daß man trotzdem noch JavaScript zumindest als Alternative in der Webseite einbauen muß. Eine der populärsten Verwendungen von Ruby ist jedoch serverseitig bei Web-Applikationen, z.B. Ruby on Rails. Dort wird wiederum Ajax unterstützt, das heißt, man kann gewisse JavaScript-Funktionalität benutzen, indem man entsprechende Ruby-Befehle server-Seitig in die Web-Seiten einbaut und dann wird beim Aufruf der Web-Seite mit diesem Ruby-Code der entsprechende JavaScript-Code generiert. Am Ende bleibt es aber JavaScript und für speziellere Wünsche muß man das tatsächlich explizt verwenden.--Bk1 168 (D) 08:52, 18. Aug. 2010 (CEST)
Ich habe mir erlaubt, die Überschrift zu ändern, als allgemeine Skriptsprache, also anderswo als im Browser, ist Ruby durchaus gängig.--Bk1 168 (D) 08:52, 18. Aug. 2010 (CEST)

IDE's

Ich habe gerade gesehen, dass es bei Clojure eine Aufzählung der verfügbaren IDE's gibt. Ich habe selbst leider keinen hinreichenden Überblick, welche IDE's für Ruby zur Verfügung stehen. Netbeans, soweit ich weiss. Eclipse auch? Hat da jemand mehr Ahnung und könnte noch einen kleinen Abschnitt schreiben?

Vielen Dank und VG!

--Croco97 10:22, 22. Dez. 2010 (CET)

Prototypbasierte Objektorientierung

Ruby unterstützt von Haus aus nicht prototypbasierte Objektorientierung. Im üblichen Sprachgebrauch wird unter prototypischer Vererbung die Delegations-Methode verstanden (http://en.wikipedia.org/wiki/Prototype-based_programming#Delegation). Javascript z.B. nutzt diese Herangehensweise.

Der einleitende Text für das Codebeispiel erwähnt JavaScript (nutzt Delegation) und Io (scheint eher Konkatenation zu nutzen http://en.wikipedia.org/wiki/Prototype-based_programming#Concatenation).

Der Beispielcode passt eigentlich nur zur Konkatenationsmethode.

Aus meiner sicht sollte der Abschnitt lieber gelöscht werden. Er zeigt eigentlich nur dass in Ruby Objekte klonen kann. Wenn der Code unbedingt beibehalten werden soll, sollte daraufhin gewiesen werden, dass der Code eine Sonderform der prototypischen Objektorientierung zeigt und dass der weit geläufigere Ansatz (Delegation) mit Ruby auch möglich ist, aber diese Möglichkeit nicht Teil der Sprache ist. Ein Ansatz wie sich Delegation erreichen lässt findet sich hier: http://rubyquiz.strd6.com/quizzes/214-prototype-based-inheritance

Insgesamt wäre mir eine Löschung des Absatzes aber lieber.

Gruß, knarfotron

Kritik zum Abschnitt "Objektorientierung mit Mixins"

Zitiere: "Bis vor einiger Zeit wurden Mixins als reine Ergänzung zu klassenbasierter Objektorientierung angesehen. Spätestens aber seit Sprachen wie Potion ist klar, dass es sich hierbei um ein eigenes Konzept der Objektorientierung handelt."

  • Mixins müssen hier nicht erklärt oder gerechtfertigt werden.
  • Der Programmiersprache "Potion" wird hier eine signifikante Bedeutung zugemessen, ohne dass es für diese überhaupt einen Wikipedia-Artikel gibt. Das ist also in sich sehr unschlüssig und unseriös formuliert.

--217.91.209.122 11:51, 29. Mär. 2011 (CEST)

Beispiel Syntax/Besonderheiten (Abschnitt 2.3.1)

Hier fehlt das Ergebnis, dadurch ist das Beispiel sinnlos.--Mideal 13:12, 27. Mai 2011 (CEST)

Habe ich ergänzt. -- Klausb 20:07, 27. Mai 2011 (CEST)

Artikel viel zu lang und detailliert

Der Artikel ufert grauenhaft aus; was imho hier nicht reingehört:

  • Erklärung verschiedener OOP-Techniken. Das ist der Artikel zu Ruby, nicht der Artikel zur objektorientierten Programmierung.
  • Sämtliche Code-Beispiele, die sich nicht explizit auf erwähnenswerte Spracheigenschaften an sich beziehen oder einen (1) kurzen Überblick gewähren. Die Wikipedia ist kein Tutorial (für Programmieranfänger).
  • Firlefanz wie "Zeilenumbrüche markieren das Ende einer Anweisung, Semikolons bewirken dasselbe.", der zudem hier auch noch unter Besonderheiten aufgeführt wird... Ein Verweis auf die Dokumentation der Sprache reicht hier völlig aus. Das die Sprache Blöcke unterstützt interessiert wirklich niemanden, und falls doch: rubydocs.
  • "quietsch brumm brumm quak muh"? Hier hört jeder Spass auf, wir sind doch nicht im Kindergarten!

Ich werde hier in ein paar Tagen wieder reingucken um zu sehen ob sich überhaupt jemand für einen ordentlichen Ruby-Artikel interessiert, falls nicht, werde ich Ende Februar bis Ende März gnadenlos entschlacken. Das ist keinesfalls böse gemeint, ich respektiere die Mühe die sich hier jemand gemacht hat, und würde mich freuen wenn sich soviel Information wie möglich retten lässt (an anderen Stellen: Wikibooks, andere Artikel, etc) aber der Artikel ist ein furchtbares Durcheinander von (an dieser Stelle) unrelevanten Informationen. MfG, I.P. --84.151.141.243 01:56, 29. Jan. 2012 (CET)

Ich finde den Artikel nicht zu lang, aber man sollte die Information vielleicht anders strukturieren.
  • Idee 1: Wir schreiben eine relativ kurze Zusammenfassung am Anfang im ersten Abschnitt und dann die Details in den weiteren Abschnitten.
  • Idee 2: Wir machen für detaillierte Information separate Artikel, dann bleibt hier nur eine kurze Zusammenfassung und dann ein "siehe Hauptartikel..."
Vielleicht können wir auf der Basis den Artikel verbessern.
Ich glaube, Artikel sind fast nie zu lang, wohl aber oft zu langweilig. Machen wir ihn interessanter, strukturierter. Es lohnt sich vor allem, mal einen Blick in andere Sprachversionen zu werfen, auch wenn man die Sprache nicht perfekt kann. Die russische Version soll zum Beispiel sehr gut sein, hat jedenfalls ein Sternchen.--Karl Brodowsky 10:30, 29. Jan. 2012 (CET)
Ich verstehe kein Stück kyrillischer Schrift, aber die russische Version sieht trotzdem schon mal um einiges strukturierter aus, ja. Hier möchte ich allerdings noch dazusagen, daß eine derartige Anhäufung von Codebeispielen in deutschen Artikeln zu Programmiersprachen eher unüblich ist (siehe die Artikel zu C++, Java, Scala, um nur ein paar zu nennen), und eben hauptsächlich dazu dienen einen kurzen Einblick in die Sprache im Allgemeinen (das berühmte "Hallo Welt" und/oder ein "handelsüblicher" Algorithmus) oder speziellen Eigenschaften im Besonderen(z. B. die Monadenfähigkeit der For-Schleife in Scala) zu gewähren; bei letzterem sollte dann auch dabei stehen inwiefern sich die gezeigte Eigenschaft von der Standardkost unterscheidet. Und dann sind da natürlich noch die quietschenden Kühe und die muhenden Autos hier, da könnte man eventuell auf Vektoren/Koordinaten oder Ähnliches zurückgreifen *g* MfG, I.P. --84.151.139.11 15:59, 29. Jan. 2012 (CET)

Die angekündigte Entschlackung halte ich inzwischen für unangemessen radikal, und habe daher erstmal einen QS-Antrag gestellt. MfG, IP--84.151.128.100 11:13, 30. Mär. 2012 (CEST)

Kritik an der Kritik

"Da Variablen vor Gebrauch nicht deklariert werden müssen, können bei Tippfehlern unerwartete Laufzeitfehler auftreten." Was hat die Deklaration oder nicht-Deklaration von Variablen mit Laufzeitfehlern durch Tippfehlern zu tun? Wegen eines Tippfehlers kann einfach der Ausdruck, die Methode oder Variable nicht eindeutig identifiziert werden bzw. wird wegen des Tippfehlers als eine andere Variable als die gemeinte erkannt. Beispiel: "var1 = 'whatever'" der Variable mit der Bezeichnung "var1" wird die Zeichenkette "whatever" zugeordnet; wenn nun bei Verwendung der Variable "var1" "vra1" eingegeben wird, kann der Ruby Interpreter unmöglich eigenständig erkennen, dass "var1" statt "vra1" gemeint war. --2.206.0.42 07:49, 13. Apr. 2012 (CEST)

In C merkst Du den Tippfehler schon zur Compilezeit, wenn Du "vra1" einen Wert zuweist, aber "var1" deklariert hast. In Ruby knallt's aber erst zur Laufzeit, wenn Du "vra1" einen Wert zugewiesen hast, aber danach "var1" uninitialisiert verwendest. --AchimP (Diskussion) 16:08, 20. Jun. 2012 (CEST)
nagut, bin zu sehr an JIT und ähnliches gewohnt (nicht signierter Beitrag von 178.201.40.244 (Diskussion) 12:13, 22. Apr. 2013 (CEST))
um es abzukürzen: die Kritik müsste lauten: fehler im Script fallen nur bei der Laufzeit auf, da die Prüfung des Codes, die während einer Kompilierung getätigt würde, nicht notwendig ist.

Qualitätssicherung - wie lange noch?

Seit über drei Monaten befindet sich der QS-Baustein auf der Seite. Da der Baustein seinen Zweck offenbar nicht sehr gut erfüllt, nämlich schreibwillige Ruby-Experten zur Überarbeitung des Artikels zu animieren, schlage ich vor, ihn wieder zu entfernen.

Ich glaube, er lässt den Artikel unseriöser wirken, als er tatsächlich ist ("... inhaltliche Mängel ..."!) und fände es bedauerlich, wenn bei einem neugierigen Leser dieser erste Eindruck auch auf die Sprache selbst abfärben würde. -- 46.5.45.18 21:38, 3. Jul. 2012 (CEST)

Habe den Baustein entfernt, da ohne Reaktion bzw. Wirkung. --46.5.45.18 22:17, 17. Jul. 2012 (CEST)


Literatur

Die Literatur ist zum Teil deutlich veraltet bzw. bezieht sich auf alte Versionen von Ruby. --TobiasVetter (Diskussion) 21:08, 6. Apr. 2016 (CEST)

großes Lob

Artikel super gut lesbar und verständlich, prima Beispiele! --Dipl.Informatiker 11:23, 29. Jul. 2017 (CEST)

Komplette Überarbeitung des Haupttext

Ich war mit dem Haupttext nicht so recht zufrieden, da weniger die charakteristischen Eigenschaften von Ruby erwähnt, sondern mehr eine allgemeine Einführung in verschiedene Programmierparadigmen gegeben wurde. Selbstverständlich spielen diese in Ruby alle eine große Rolle, aber ich habe es umgeschrieben mit Fokus auf Ruby. Also mehr von Ruby zu den Paradigmen als von den Paradigmen zu Ruby. Alles (Text und Beispiele) basiert auf dem aktuellen Ruby 2.5.
Gegliedert habe ich es in die m.M.n. herausragendsten und meistgenutzten Bereiche Ruby: Objektmodell, Blöcke, Mixins (+MonkeyPatching), DSL, Standardbibilothek, Metaprogrammierung und Unixintegration. Danach folgt ein Absatz über (syntaktische) Eigenheiten, die Kenner anderer Programmiersprachen überraschen könnten. Hier kann eventuell gekürzt werden.

Letztendlich ist der Text recht lang geworden, aber ich denke auf einer für eine Enzyklopädie angemessenen Länge und Tiefe.

Möglicherweise zu ändernde Stellen:

  • Ich bin mir nicht ganz sicher ober der Absatz über Prototyp-basierte Programmierung nötig ist. Einerseits ist es interessant zu wissen dass das möglich ist, praktisch kenne ich aber keine Anwendung. Wie in einem vorherigen Kommentar kritisiert bietet der Ansatz keine Delegation, sondern bloße Kopie, Delegation lässt sich aber über Metaprogrammierung realisieren (gibt Bibliotheken dafür).
  • Mir fällt gerade auf dass ich Ducktyping gar nicht erwähnt habe. Ist das großartig relevant, oder ist das für objektorientierte Skriptsprachen nicht sowieso Standard.
  • Das Beispiel zur DSL ist nicht weiter beschrieben. Praktisch soll es nur zeigen, wie wenig Rubyquelltext nach einer Programmiersprache aussehen kann. Vielleicht ist das aber auch zu verwirrend?

Später werde ich noch den Abschnitt Implementierungen aktualisieren (ist ziemlich veraltet) und etwas zu den Gründen der Entstehung und den Mottos schreiben.

Ich würde mich über konstruktive Kritik freuen. --Jsowieso (Diskussion) 07:57, 5. Feb. 2018 (CET)

bitte Asiatenhasskommentare bei dem Beitrag löschen, danke (weil Japaner sind auch nur Asiaten)

Mir ist aufgefallen, dass die Sprache Ruby ein Japaner, also ein ASIATE erfunden hat. Es ist mir lieber, wenn die Wikipedia zudem auch Asiatenhass auf der Plattform löscht.

Bisher ist kein Hasskommentar dabei, aber man weiß ja nie bei dieser Ideologie. ... --2001:16B8:5734:4F00:F40A:18B9:2A6:1F82 18:08, 24. Aug. 2021 (CEST)

Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Ruby_(Programmiersprache)&oldid=215021453“