Yukihiro Matsumoto: Ruby und das Glück der Programmierenden
Erfahre, wie Yukihiro Matsumoto Ruby als ausdrucksstarke objektorientierte Sprache entwarf und seine gemeinschaftliche Entwicklung vor und nach dem Aufstieg von Ruby on Rails begleitete.
Veröffentlicht 24. August 2026Lesezeit : 10 minVon Yann Bastien
Yukihiro Matsumoto, in der Community als Matz bekannt, entwarf Ruby aus einer konkreten Unzufriedenheit heraus. Anfang der 1990er-Jahre schätzte er die Schnelligkeit von Skriptsprachen, fand aber keine, die diese Flexibilität mit einem ausreichend kohärenten und angenehmen Objektmodell verband.
Ruby entstand aus dieser Suche. Die Sprache übernimmt Ideen aus Smalltalk, Lisp, Perl, Eiffel und Ada, ohne sie einfach nebeneinanderzustellen. Matsumoto stellt die menschliche Erfahrung in den Mittelpunkt: Ein Programm soll Absichten flüssig ausdrücken, Wiederholungsarbeit verringern und Formen anbieten, die dem Problem nahekommen.
Diese Ausrichtung wird oft als „Glück der Programmierenden“ zusammengefasst. Sie bedeutet weder, dass Ruby immer einfach ist, noch dass die Sprache Fehler verhindert. Gemeint ist eine Architekturentscheidung: Eine komplexere Implementierung ist akzeptabel, wenn sie den Schreibenden eine natürlichere Schnittstelle bietet.
Sprachen lernen, bevor man eine eigene schafft
Yukihiro Matsumoto wurde 1965 in der Präfektur Osaka geboren und wuchs in Tottori auf. Schon als Jugendlicher interessierte er sich für Programmierung, obwohl der lokale Zugang zu Computern und Fachliteratur begrenzt war.
1984 begann er an der Universität Tsukuba. Dort konnte er Rechner nutzen, internationale Dokumentation lesen und über Netzwerke Gemeinschaften außerhalb seines unmittelbaren Umfelds kennenlernen. Er studierte Informationswissenschaft, Programmiersprachen und Compiler und schloss 1990 sein Studium ab.
Matsumoto untersuchte zahlreiche Sprachen und entwickelte unter anderem Werkzeuge in Emacs Lisp. Daraus entstand eine Überzeugung: Sprachdesign besteht nicht darin, eine einzige Eigenschaft zu maximieren. Kohärenz, Leistungsfähigkeit, Vertrautheit und Lernaufwand müssen gegeneinander abgewogen werden.
Er wollte schon lange eine eigene Sprache entwickeln. Konkret wurde das Vorhaben, als er eine wirklich objektorientierte Skriptsprache suchte, die für alltägliche Aufgaben praktisch war und Objekte nicht nur als nachträgliche Erweiterung behandelte.
24. Februar 1993: der Beginn von Ruby
Matsumoto datiert Rubys Geburt auf den 24. Februar 1993, als er mit einem Kollegen über eine objektorientierte Skriptsprache sprach. Perl 4 war leistungsfähig bei Textverarbeitung, bot aber nicht das Objektmodell, das Matz suchte. Python existierte bereits, doch seine Objektorientierung erschien ihm damals wie eine Ergänzung eines Kerns, der nicht alles einheitlich behandelte.
Er begann deshalb einen Interpreter, der mehrere Eigenschaften verbinden sollte:
die schnelle Entwicklung einer Skriptsprache;
ein Modell, in dem Werte Objekte sind;
von Lisp und Smalltalk inspirierte Iteratoren und Closures;
Exceptions und automatische Speicherverwaltung;
praktische Werkzeuge für Zeichenketten und reguläre Ausdrücke.
Der Name Ruby spielt auf Perl an: ein Edelstein nach einer „Perle“. Er verweist auf den Einfluss der Sprache von Larry Wall und markiert zugleich eine eigene Identität.
Matsumoto entwickelte das Projekt neben seiner Hauptarbeit. Nach einigen Monaten lief der Interpreter, wurde aber vor der Veröffentlichung weiterentwickelt. Im Dezember 1995 erschien Ruby 0.95 in japanischen Newsgroups, im Dezember 1996 folgte Ruby 1.0.
Alles ist ein Objekt, aber Objekte müssen praktisch bleiben
Ruby wendet Nachrichtenversand homogener an als viele hybride Sprachen. Zahlen, Zeichenketten, Klassen und boolesche Werte sind Objekte, auf denen Methoden aufgerufen werden. 3.times fordert buchstäblich das Objekt 3 auf, einen Block dreimal auszuführen.
3.times do |index| puts "Schritt #{index + 1}"end
Der Code vermeidet eine Schleife mit expliziter Initialisierung, Bedingung und Inkrement. Die Ganzzahl stellt den Iterator bereit; der Block beschreibt nur, was bei jedem Durchlauf geschieht.
Diese Syntax zeigt Rubys Priorität: Die eigentliche Absicht soll sichtbar sein, während wiederkehrende Mechanik in wiederverwendbare Methoden wandert. Bibliotheken können dadurch Vokabulare schaffen, die ihrem Fachgebiet nahekommen.
Das Modell bleibt dynamisch. Der Typ einer Variablen wird nicht statisch deklariert; ein Methodenfehler kann daher erst auftreten, wenn der betreffende Pfad ausgeführt wird. Tests, Analysewerkzeuge und API-Konventionen sind in großen Projekten entsprechend wichtig.
Blöcke, Closures und Iteratoren
Blöcke gehören zu Rubys charakteristischsten Merkmalen. Eine Methode kann einen Codeblock empfangen, sofort ausführen, als Proc aufbewahren oder ihm Werte übergeben.
map steuert die Erzeugung der neuen Sammlung; der Block liefert die Transformation. Dadurch müssen Index, Größe oder Mutation der Struktur nicht sichtbar werden, wenn die Aufgabe lediglich lautet: „jeden Preis transformieren“.
Ein Block ist zugleich eine Closure und kann Variablen aus seiner Umgebung erfassen. Das erleichtert Callbacks, eingerahmte Ressourcen und kleine interne Sprachen. Das klassische File.open zeigt den praktischen Nutzen: Die Methode öffnet eine Datei, übergibt sie an den Block und kann anschließend ihre Schließung sicherstellen.
Blöcke sind keine isolierte Erfindung Matsumotos. Sie passen Ideen von Closures und Funktionen höherer Ordnung aus Lisp und anderen Sprachen an. Rubys Besonderheit liegt in ihrer syntaktischen Integration in gewöhnliche Methodenaufrufe.
Einfache Vererbung und Mixins
Eine Ruby-Klasse kann nur von einer anderen Klasse erben. Um querliegendes Verhalten zu teilen, ohne künstliche Hierarchien aufzubauen, verwendet Ruby Module als Mixins.
Ein Modul kann Methoden bündeln und in mehrere Klassen eingebunden werden. Enumerable bietet etwa Sortierung, Filterung und Suche, sobald eine Klasse eine Möglichkeit bereitstellt, ihre Elemente zu durchlaufen.
Damit trennt Ruby zwei Beziehungen: „ist eine Art von“ für Vererbung und „besitzt dieses Verhalten“ für Mixins. Einige Mehrdeutigkeiten multipler Vererbung werden vermieden, ohne auf ausdrucksstarke Codekomposition zu verzichten.
Mixins brauchen dennoch einen klaren Vertrag. Erwartet ein Modul Methoden, die eine Klasse nicht bereitstellt, zeigt sich der Fehler erst zur Laufzeit. Dokumentation und Tests müssen diese Erwartungen sichtbar machen.
Ruby bevorzugt häufig Duck Typing: Entscheidend ist weniger das deklarierte Etikett eines Objekts als seine Fähigkeit, auf die benötigten Nachrichten zu reagieren. Das erleichtert Substitutionen und leichtgewichtige Objekte, verschiebt aber einen Teil der Prüfung in die Nutzung.
Offene Klassen und Metaprogrammierung
Ruby-Klassen bleiben offen: Ein Programm kann nach ihrer Erstellung Methoden hinzufügen oder neu definieren, sogar bei Klassen der Standardbibliothek. Das ermöglicht lokale Anpassungen, deklarative Abstraktionen und die Integration fremder Objekte.
Metaprogrammierung geht weiter. Code kann Methoden definieren, Nachrichten abfangen und Klassen untersuchen. Bibliotheken verwandeln damit knappe Deklarationen in Validierungen, Assoziationen, Serialisierung oder Befehle. Konfigurationsdateien können wie Fachbeschreibungen wirken und dennoch ausführbarer Code bleiben.
Der Preis ist real. Globale Änderungen an Klassen – oft Monkey Patching genannt – können Abhängigkeiten unerwartet verändern. Dynamisch erzeugte Methoden sind schwerer per Textsuche zu finden oder in Stacktraces zu verstehen.
Erfahrene Ruby-Teams begrenzen deshalb globale Änderungen, isolieren Metaprogrammierung und bevorzugen manchmal eine explizite Methode gegenüber einer brillanten, aber undurchsichtigen Abstraktion. Das Glück beim Schreiben muss mit dem Glück beim Lesen sechs Monate später vereinbar bleiben.
„Natürlich“, nicht bloß minimal
Matsumoto erklärt, Ruby solle natürlich statt nur einfach sein. Die Sprache darf mehrere Formulierungen, Aliase oder kontextabhängige Syntax anbieten, wenn der Code dadurch flüssiger wird.
send_report if ready?
Diese Form stellt die Hauptaktion in den Vordergrund und behandelt die Bedingung als Ergänzung. Sie erinnert an natürliche Sprache, bleibt aber eine präzise syntaktische Regel.
Es geht nicht darum, überall Englisch nachzuahmen. Ruby richtet sich an eine internationale Gemeinschaft und braucht eine programmierbare Grammatik. Formen sollen vielmehr dazu passen, wie Entwicklerinnen und Entwickler eine Operation gedanklich strukturieren.
Wie bei Larry Wall rechtfertigt der Einfluss natürlicher Sprachen eine gewisse Redundanz. Ruby strebt jedoch eine homogenere Ästhetik als Perl an: Häufige Operationen laufen weitgehend über Methodenaufrufe, Blöcke strukturieren Variationen.
Eine zunächst japanische Community
Die frühen Diskussionen fanden überwiegend auf Japanisch in der Liste ruby-list statt. Mitwirkende meldeten Fehler, schlugen Bibliotheken vor und beteiligten sich an der Entwicklung. Matsumoto behielt die letzte Entscheidung über Rubys Kohärenz, doch das Projekt war bald keine Einzelleistung mehr.
Diese Herkunft ist für die Geschichte freier Sprachen bedeutsam. Ruby wurde zu einem der ersten großen in Japan entstandenen Sprachprojekte mit weltweiter Verbreitung. Freie Lizenz und internationales Vokabular ließen den Code zirkulieren, während englische Dokumentation zunächst begrenzt blieb.
Die Liste ruby-talk und das 2000 erschienene, online verfügbare Programming Ruby von Dave Thomas und Andy Hunt machten die Sprache außerhalb Japans zugänglicher. Benutzergruppen und Konferenzen entstanden. Internationalisierung bedeutete dabei mehr als Übersetzung: Sie erforderte lokale Vermittler, leicht installierbare Pakete und passende Beispiele.
Ruby on Rails: Beschleuniger, nicht Ursprung
2004 extrahierte David Heinemeier Hansson Ruby on Rails aus der Arbeit an Basecamp von 37signals. Das Framework nutzt Rubys Blöcke, Konventionen, offene Klassen und Metaprogrammierung, um die Konfiguration von Webanwendungen zu reduzieren.
Rails popularisierte insbesondere convention over configuration und don’t repeat yourself. Klassen- und Tabellennamen folgen Konventionen; Entwickler müssen weniger Dateien schreiben, die Beziehungen beschreiben, die das Framework ableiten kann.
Demonstrationen, in denen in wenigen Minuten funktionierende Anwendungen entstanden, verschafften Ruby weltweite Sichtbarkeit. Viele lernten zuerst Rails kennen und danach die Sprache hinter seinen deklarativen APIs.
Die Urheberschaft muss getrennt bleiben: Matsumoto schuf Rails nicht; Hansson und seine Community sind dafür verantwortlich. Ruby existierte fast ein Jahrzehnt vorher und wird ebenso für Skripte, Systemwerkzeuge, Tests, Website-Generatoren und eingebettete Software eingesetzt.
Die Referenzimplementierung heißt MRI (Matz’s Ruby Interpreter) oder CRuby, weil sie in C geschrieben ist. Mit wachsender Nutzung wurden Leistung und Ausführungsmodell wichtiger.
Ruby 1.9 integrierte YARV, eine hauptsächlich von Koichi Sasada entworfene virtuelle Maschine. Sie übersetzt Code in Zwischeninstruktionen und verbessert die Ausführungsarchitektur. Andere Implementierungen erschließen weitere Plattformen: JRuby auf der JVM, TruffleRuby auf GraalVM und mruby für eingebettete Systeme.
Diese Projekte zeigen, dass Matz die Sprache lenkt, ohne jede Komponente selbst zu schreiben. Sasada, Core-Maintainer, Bibliotheksautoren und alternative Implementierungen erweitern die Einsatzbereiche und prüfen die implizite Spezifikation an realen Unterschieden.
Ruby muss zugleich kompatibel bleiben und schneller werden. Dynamische Verhaltensweisen wie Methodenneudefinition, Introspektion und Codeerzeugung erschweren Optimierungen, weil die Laufzeit mit Veränderungen rechnen muss. Moderne Versionen ergänzen daher JIT-Compiler, Profiling und Optimierungen, ohne das dynamische Grundmodell aufzugeben.
Kohärenz durch Diskussion steuern
Matsumoto bleibt Hauptdesigner und wichtiger Schiedsrichter von Ruby. Seine Aufgabe besteht weniger darin, jeden Patch selbst zu schreiben, als zu beurteilen, ob ein Vorschlag zur Identität und Entwicklung der Sprache passt.
Diese Governance bietet eine erkennbare Richtung, braucht aber organisierte Rückmeldungen. Öffentliche Issue-Tracker, Mailinglisten, Konferenzen und Core-Teams konfrontieren Ideen mit den Bedürfnissen von Implementierenden und Nutzenden.
Die von Matsumoto geleitete Ruby Association verbindet zudem freie Community und Organisationen, die Stabilität benötigen. Daraus entsteht eine dauerhafte Spannung: Eine Sprache muss sich entwickeln, darf aber das Vertrauen bestehender Anwendungen nicht durch abrupte Änderungen zerstören.
Ruby begegnet dem mit Versionen, Deprecation-Warnungen, Experimenten und gelegentlich revidierten Entscheidungen. Kohärenz ist fortlaufende Arbeit, keine 1993 endgültig erreichte Eigenschaft.
Warum Yukihiro Matsumoto weiterhin wichtig ist
Ruby zeigte, dass eine dynamische Sprache die Erfahrung der Programmierenden in den Mittelpunkt stellen kann, ohne auf ein Lehrwerkzeug beschränkt zu bleiben. Blöcke, Iteratoren und ausdrucksstarke APIs beeinflussten, wie andere Communities über Lesbarkeit und interne Sprachen sprechen.
Matsumoto demonstrierte außerdem den Wert einer klaren gestalterischen Haltung. Eine Sprache entsteht nicht allein aus einer per Abstimmung zusammengestellten Funktionsliste. Jemand muss entscheiden, welche Kombinationen ein erkennbares Ganzes bilden und welche Komplexität in der Implementierung verborgen bleiben kann.
Ruby liefert zugleich eine Warnung: Angenehme Syntax und mächtige Metaprogrammierung steigern Produktivität, wenn Konventionen geteilt werden. Sie können Wartbarkeit verschlechtern, wenn Verhalten implizit oder global wird.
Das „Glück der Programmierenden“ bedeutet daher nicht, möglichst wenige Zeichen zu tippen. Es ist ein Gleichgewicht aus Schreiben, Lesen, Werkzeugfeedback und der Fähigkeit, eine Idee ohne unnötigen Kampf mit der Sprache in Software zu verwandeln.
Chronologie
1965: Geburt von Yukihiro Matsumoto in der Präfektur Osaka.
1984: Beginn des Informationswissenschaft-Studiums an der Universität Tsukuba.
1990: Abschluss in Tsukuba und anschließende Tätigkeit in der Softwareentwicklung.
1993: Beginn des Ruby-Entwurfs am 24. Februar.
1995: Veröffentlichung von Ruby 0.95 in japanischen Newsgroups im Dezember.
1996: Veröffentlichung von Ruby 1.0.
2000: Programming Ruby trägt zur internationalen Verbreitung bei.
2003: Ruby 1.8 stabilisiert den Zweig, der während des weltweiten Wachstums genutzt wird.
2004: David Heinemeier Hansson schafft Ruby on Rails.
2006: Starkes internationales Wachstum von Ruby-Gruppen und -Konferenzen.
2007–2009: Übergang zu Ruby 1.9 und Integration von Koichi Sasadas YARV.
2011: Matsumoto erhält den Preis der Free Software Foundation für freie Softwareentwicklung.
2013: Ruby 2.0 erscheint zwanzig Jahre nach Projektbeginn.
2020: Ruby 3.0 erscheint mit großen Anstrengungen bei Leistung und Nebenläufigkeit.
Häufige Fragen
Warum schuf Yukihiro Matsumoto Ruby?
Er wollte eine praktische Skriptsprache, in der das Objektmodell zentral und nicht nachträglich ergänzt war. Keine ihm bekannte Sprache verband genau die Flexibilität, Objekte, Iteratoren und Schreiberfahrung, die er suchte.
Ist Ruby nur von Smalltalk inspiriert?
Nein. Smalltalk prägte das Objektmodell stark, doch Matsumoto nennt auch Perl, Lisp, Eiffel und Ada. Ruby kombiniert diese Einflüsse und formt daraus eine eigene Identität.
Was bedeutet „für das Glück der Programmierenden optimieren“?
Es bedeutet, ausdrucksstarke Schnittstellen, schnelles Feedback und Konstruktionen nahe an menschlichen Absichten zu bevorzugen. Komplexität verschwindet nicht; die Sprache versucht, den repetitiven Teil davon zu verbergen.
Hat Matsumoto Ruby on Rails geschaffen?
Nein. David Heinemeier Hansson entwickelte Rails 2004 aus Basecamp heraus. Das Framework machte Ruby deutlich sichtbarer und nutzt intensiv Blöcke, Konventionen und Metaprogrammierung.
Was sind die wichtigsten Grenzen von Ruby?
Seine Dynamik kann manche Fehler bis zur Laufzeit verschieben, und offene Klassen können schwer diagnostizierbare Wechselwirkungen erzeugen. Auch die Leistung war lange eine Herausforderung. Tests, Konventionen und moderne Werkzeuge reduzieren diese Risiken, beseitigen sie aber nicht.
Wie Alan Kay objektorientierte Programmierung, Smalltalk, Dynabook und grafische Oberflächen zu einer Vision des formbaren persönlichen Computers verband.
Erfahre, wie Guido van Rossum aus den Erfahrungen mit ABC Python entwickelte, seine Evolution prägte und aus einem persönlichen Projekt ein Gemeinschaftswerk machte.
