Diskussion:Ruby (Programmiersprache)

message: -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)
thread_title: Verbreitung und Nutzung

message: 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)
replies: text: wer lesen kann ist klar im vorteil - siehe programmierbeispiele, das letzte.. -- ∂ 10:26, 16. Sep 2004 (CEST)
replies: text:  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)

text:  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)
replies: text: Diese Variante macht exakt das gleiche Zeilenweise:
IO.readlines("text.txt").map {|l| puts l} Daniel Bovensiepen 19:42, 9. Feb. 2007 (CET)
thread_title: Bsp: Datei Zeile für Zeile einlesen

message: Abgesehen davon gibt es aber sozusagen keine Doppelspurigkeiten wie in Perl.
:Was soll das heissen? --zeno 09:50, 10. Okt 2005 (CEST)
replies: text: 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)
thread_title: Keine Doppelspurigkeiten?

message: 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)
replies: text: 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)
thread_title: Unicode-Support

message: 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)
thread_title:  Bezgüglich? 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: Finde ich gut. Gruß --Sprezz 00:47, 30. Apr 2006 (CEST)
thread_title:  ungetype Variablen? Wohl eher dynamisch typisiert 

message: 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)
replies: text: 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)
replies: text: Hab mich mal der Kommasetzung angenommen ;)--BeatePaland 22:39, 8. Aug 2006 (CEST)
replies: text: Echt verrrückt wieviele Kommas man in der deutschen Sprache vergessen kann (-: Daniel Bovensiepen 00:59, 9. Aug 2006 (CEST)
thread_title:  Artikel Redesign 

message: 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)
replies: text: 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)
thread_title:  Logo 

message: 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)
replies: text: Habe es trotzdem eungebaut. -- FF-Wonko D•B 19:52, 16. Feb. 2009 (CET)
thread_title:  AspectR 

message: 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)
replies: text: 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)
thread_title:  Überarbeitung 

message: 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)
thread_title: Native Threads vs Green Threads, zum Punkt Kritik

message: 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)
replies: text: Sorry, war beim ersten Punkt zu voreilig... Verpeilt... Reverte es :-) --Haize 16:37, 27. Dez. 2008 (CET)
thread_title:  Kritikpunkte 

message: 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)
thread_title:  Spezifikation 

message: 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)
thread_title:  Korrektur "interpretiert" vs "ist interpretiert" 

message: 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)
thread_title:  IDE's 

message: 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)
thread_title:  Kritik zum Abschnitt "Objektorientierung mit Mixins" 

message: Hier fehlt das Ergebnis, dadurch ist das Beispiel sinnlos.--Mideal 13:12, 27. Mai 2011 (CEST)
replies: text: Habe ich ergänzt. -- Klausb 20:07, 27. Mai 2011 (CEST)
thread_title:  Beispiel Syntax/Besonderheiten (Abschnitt 2.3.1) 

message: 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)
replies: text: Habe den Baustein entfernt, da ohne Reaktion bzw. Wirkung. --46.5.45.18 22:17, 17. Jul. 2012 (CEST)
thread_title:  Qualitätssicherung - wie lange noch? 

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

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

message: 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)
thread_title:  Komplette Überarbeitung des Haupttext 

message: 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)
thread_title:  bitte Asiatenhasskommentare bei dem Beitrag löschen, danke (weil Japaner sind auch nur Asiaten)