Yukihiro Matsumoto: „Ruby ist für Menschen konzipiert, nicht für Maschinen“

Vorwort

Wir freuen uns sehr, unseren guten Freund Yukihiro Matsumoto, Entwickler der Programmiersprache Ruby, zum zweiten Mal als Speaker bei RubyRussia 2019 begrüßen zu dürfen, nachdem er dort bereits 2016 einen Vortrag hielt.

Seit wir diese Konferenz veranstalten – inzwischen sind es mehr als zehn Jahre – hat Ruby eine große Entwicklung durchgemacht, und Evrone ist mit ihr gewachsen und hat sich mit ihr weiterentwickelt.

Grigory Petrov, Developer Relations bei Evrone, hat sich mit Herrn Matsumoto zusammengesetzt, um aus erster Hand von ihm zu hören, wie es ist, ein Star zu sein, was die Philosophie hinter Rubys Design und Entwicklung ist, und um etwas über das Leben und die Kultur Japans zu erfahren.

Das Interview

Grigory: Dies ist nach dem ersten 2016 nun Ihr zweiter Besuch in Russland. Seither hat sich die Zahl der Menschen, die RubyRussia besuchen, verdoppelt. Vielen Dank für Ihren Vortrag, er hat mir sehr gefallen, und ich kenne jetzt die Antworten auf einige der Fragen, die ich Ihnen stellen wollte!

Ich habe gesehen, dass viele Menschen Ihnen nicht nur Fragen gestellt haben, sondern auch Bilder und Autogramme haben wollten – Sie sind ein Star! Wir Entwickler mögen natürlich die Sprache und sind dankbar für das, was Sie für die Community tun, aber denkt man überall auf der Welt so oder nur in Russland?

Yukihiro: Ich werde überall nach Fotos gefragt. In jedem Land und bei jeder Konferenz wollen die Besucher ein Foto mit mir machen. Aber ich glaube, das war das erste Mal, dass mich jemand um ein Autogramm gebeten hat!

Grigory: Als Schöpfer einer Programmiersprache wird man vermutlich mit vielen Fragen, Vorschlägen, Ideen usw. konfrontiert. Welche Frage stellt man Ihnen am häufigsten?

Yukihiro: Die beliebteste Frage ist: „Ich komme aus der XYZ-Community; können Sie nicht ein Feature der Sprache XYZ in Ruby einführen?“, oder so ähnlich. Und meine übliche Antwort auf diese Fragen ist … „Nein, das werde ich nicht“, denn wir verfügen über ein unterschiedliches Sprachdesign und eine unterschiedliche Sprachentwicklungspolitik.

Wir können nicht einfach ein Feature der Sprache XYZ nehmen und es in Ruby einbauen, obwohl wir in einigen Fällen natürlich Ideen aus anderen Sprachen wie Python, JavaScript und Elixir leihen. Diese Frage wird immer wieder gestellt, aber eine positive Reaktion darauf zu erhalten, ist sehr selten.

Grigory: Es ist toll, dass Sie nein sagen können. Ich bin der Meinung, dass Technologien, die „von der Community entworfen“ werden, am Ende nicht unbedingt die besten Ergebnisse erzielen. Es gibt so viele verschiedene Sprachen und Technologien, sodass wir den Luxus haben, nach den besten Praktiken zu suchen und nur die Dinge zu implementieren, die auch wirklich passen.

Wir erleben seit einiger Zeit eine Welle der „graduellen Typisierung“ dynamisch typisierender Sprachen wie JavaScript, Python und PHP. Was halten Sie von Typ-Annotationen und gradueller Typisierung? Warum sind sie so beliebt? Und wie sehen Ihre allgemeinen Ideen und Pläne für die Typprüfung in Ruby 3 und darüber hinaus aus?

Yukihiro: Rust und Go sind Beispiele für statisch typisierende Sprachen. Wenn die mit ihnen erstellte Software ziemlich schnell wächst, muss man sich am Ende mit enormen Codebasen herumschlagen, die möglicherweise Millionen von Codezeilen enthalten, an denen jeweils Hunderte von Teammitgliedern arbeiten. In diesen Fällen ist die Typprüfung eine sehr bequeme Methode, um Unstimmigkeiten zu entdecken.

Im Gegensatz dazu müssen wir bei dynamisch typisierenden Sprachen Tests schreiben, um Typabweichungen in unserem Code zu vermeiden. Mit dem Wachstum der Software wächst auch das Volumen der Tests (und die Bürde, sie zu schreiben), und das hat in der letzten Zeit viel dazu beigetragen, die Popularität des statischen und graduellen Typisierens zu fördern.

Gleichzeitig ist jedoch die statische Typdeklaration überflüssig, und mit einer Sprache wie Ruby wollen wir die Vorteile der statischen Typprüfung ohne die Redundanz manueller Typdeklarationen nutzen.

Als Ruby-Community und als Ruby-Sprache versuchen wir, beide Bedürfnisse gleichzeitig zu befriedigen: Wir werden die Typinformationsdatei vom Ruby-Programm trennen – das Ruby-Programm selbst enthält keine statischen Typinformationen. Stattdessen enthält eine separate Typinformationsdatei, die wir „Ruby-Signaturdatei“ nennen, die Typinformationen über die Bibliothek, Gems und Programme.

Wir werden ein Tool, den „Type Profiler“, zur Verfügung stellen, das die Typinformationen über Ihre Software sammeln kann. Nach dem Sammeln der Typinformationen für die Bibliothek und Ihre Software verfügt der Type Profiler über alle Informationen, die er zu allen Klassen und Methoden benötigt, so dass er dann Typwidersprüche bzw. Konflikte erkennen kann. Man kann die Typinformationen in der Signaturdatei sogar von Hand verfeinern, um eine bessere Typprüfung zu ermöglichen.

In zukünftigen Ruby-Versionen wird man die Typen bis zu einem gewissen Grad statisch überprüfen können – aber nur in sehr begrenztem Umfang. Es gibt dann das traditionelle Ruby-Verhalten, das zur Laufzeit eine Typprüfung durchführt. Mit einem „Level 1 Type Checker“ ist es möglich, zwischen 40–80 % der Typfehler zu finden, indem man die im Quellcode verfügbaren Typinformationen verwendet. Ein „Level 2 Type Checker“ kann zusätzliche Typinformationen auf der Grundlage der Analyse des Codes selbst erzeugen. Mit diesen Tools können spätere Versionen von Ruby statische Typüberprüfungen bereitstellen, ohne dass explizite Typ-Annotationen im Code erforderlich sind.

Grigory: Während des Vortrags auf der Konferenz haben Sie das bereits erwähnt, und die Idee ist ziemlich gut. Ich selbst bin C/C++-Entwickler, und daher ist statische Typisierung für mich selbstverständlich. Ich habe Typen immer als eine Möglichkeit betrachtet, meine Absichten zu deklarieren, um der Sprache und den Tools zu helfen, künftig mögliche Fehler zu finden.

Sie wollen also ein System schaffen, in dem man selbst Code schreibt und die Möglichkeit hat, aus diesem Code genügend Informationen abzuleiten, um Fehler zu erkennen, ohne auf explizite Typen zurückgreifen zu müssen. Das klingt für mich sehr hilfreich.

Es ist toll, dass Sie experimentieren und Ideen testen. Wie sieht die Zukunft für Ruby in Ihren Augen aus? In welcher Weise beeinflussen Sie die Richtung, die Ruby einschlägt?

Yukihiro: Eigentlich steuere ich weder die Sprache noch die Community. Ich stelle nur die Technologie zur Verfügung, und die Community entscheidet, wohin es geht. Zumindest haben wir in vielen Bereichen ausreichend Technologien zur Verfügung, um Ruby flexibel und produktiv zu machen. Ruby wird derzeit beispielsweise hauptsächlich zum Erstellen von Webanwendungen verwendet, aber ich würde mir wünschen, dass Ruby auch in der Forschung oder für KI und maschinelles Lernen eingesetzt wird. Wir versuchen, die Technologie in neuen Bereichen nutzbar zu machen.

Grigory: Wir Entwickler lieben es, Dingen einen Namen zu geben und sie zu kategorisieren. Ein Sportwagen ist beispielsweise eine andere Autokategorie als ein Familienwagen. Wir labeln auch Programmiersprachen: JavaScript ist eine „Websprache“, C ist eine „Low Level Systemsprache“, C# ist „für native Windows UI Anwendungen“. Wie würden Sie Ruby kategorisieren?

Yukihiro: Ich würde Ruby als eine produktive Programmiersprache einstufen. Produktivität ist eines der größten und wichtigsten Ziele von Ruby. Ich habe Ruby für Menschen konzipiert, nicht für Maschinen. Manchmal beschweren sich wichtige Mitwirkende über das Design der Sprache, weil es schwierig ist, sie effizient umzusetzen. Rubys Design konzentriert sich nicht primär auf die Leistung, sondern die Produktivität. Das bedeutet, dass man bei der Implementation vor einer größeren Herausforderung steht, der wir uns aber gerne stellen: Wir wollen Ruby für die Entwickler so produktiv wie möglich und gleichzeitig so performant wie möglich machen.

Grigory: Mit Python haben wir aufgrund von Implementierungsproblemen keine mehrzeiligen anonymen Callables. Es ist schön zu hören, dass Sie und die Kernentwickler sich trotz der technologischen Herausforderungen bei der Implementierung sehr darum bemühen, den Entwicklern das Leben zu erleichtern.

Wo wir gerade beim Thema Herausforderungen sind … Stellen Sie sich vor, Sie hätten die Möglichkeit, in der Zeit zurückzureisen und Ihrem jüngeren Ich nur einen einzigen Ratschlag zu geben. Etwa zu der Zeit, als Sie mit der Entwicklung von Ruby begonnen haben. Welchen Rat würden Sie sich geben?

Yukihiro: Nimm nicht zuviel aus anderen Skriptsprachen. Deine Programmiersprache ist die beste Allzweck-Programmiersprache. Funktionen, die nur eingeführt werden, um Ruby mehr wie Skriptsprachen aussehen zu lassen, werden in Zukunft nur einen „Anhang“ bilden – überwiegend nutzlos, bis sie Probleme verursachen – daher ist es am besten, sich nicht zu sehr auf sie zu konzentrieren.

Grigory: In der Vergangenheit gab es einen großen Unterschied zwischen „Skripting“ und „kompilierten“ Programmiersprachen. Heutzutage ist jedoch vieles anders: die Grenzen zwischen Maschinen, Bytecode und JIT-Compilern verschwimmen immer mehr.

Während dieser Entwicklung haben Sie viele Änderungen implementiert und viele Experimente mit Ruby durchgeführt. Einige waren erfolgreich, andere nicht. Was sehen Sie als den größten Designerfolg von Ruby? Wovon halten Sie am meisten?

Yukihiro: Wenn ich mich für eine Sache entscheiden müsste, würde ich Blöcke nehmen. Ein Ruby-Block ist eine recht einzigartige und sehr nützliche Abstraktion einer Funktion höherer Ordnung. Das Feature ist viel einfacher als in anderen Sprachen. Es hat zwar seine Grenzen, ist allerdings sehr bequem.

Grigory: Zufälligerweise sind Blöcke das, was ich an Ruby am meisten mag. In meinen eigenen Vorträgen und Interviews erwähne ich, dass es bei Ruby um DSL, Syntaxzucker und Blöcke geht. Blöcke sind großartig.

Yukihiro: In Sprachen wie Swift kann man, wenn das letzte Argument eine Funktion ist, für einen Ruby-Block Klammern darum setzen. Es gibt einen Vorschlag für eine ähnliche Funktion, die zu JavaScript hinzugefügt werden soll. Darauf bin ich sehr stolz.

Grigory: Ja, JavaScript kann Blöcke emulieren, indem es eine „Fat Arrow“-Funktion als letztes Argument übergibt, weil es (seit ES6) diese „Fat Arrow“-Syntax für mehrzeilige Funktionen besitzt. Blöcke sind super. Gibt es unterdessen Elemente im Design oder der Entwicklung von Ruby, die Ihnen nicht gefallen? Was ist für Sie der größte Designfehler, der behoben werden sollte oder bereits behoben ist?

Yukihiro: Da gibt es einige. Globale Variablen: Sie waren für eine „Skriptsprache“ nützlich, aber jetzt sind sie eher ein unbrauchbarer Anhang. Ich bedauere auch das Hinzufügen von Threads. Wir hätten uns um eine bessere Abstraktion der Parallelität kümmern sollen. Ein anderer Designfehler meinerseits sind einige Objekte, die unnötigerweise veränderbar sind. Es besteht z. B. die Möglichkeit, die Zeitzone für das existierende Zeitobjekt zu ändern, anstatt eine neue Zeitzone zu erstellen. Das bereue ich.

Grigory: Ja, Mutabilität ist eine heikle Sache und kann leicht zu Fehlern im Quellcode führen.

Nun zu den nichttechnischen Aspekten von Ruby: Wie organisieren Sie Ihre Arbeit an der Sprache? Wie sieht Ihr Arbeitsalltag aus?

Yukihiro: Ich bin Vollzeit-Ruby-Entwickler. Ich verbringe die Hälfte meiner Zeit damit, über das Design des zukünftigen Ruby 3 nachzudenken. Die restliche Zeit arbeite ich neben einigen anderen Projekten an einer weiteren Ruby-Implementierung, MRuby.

Die kanonische Ruby-Implementierung wird vom Kernteam vorgenommen, und so muss ich lediglich Entscheidungen treffen wie „diese Funktion sollte sich so verhalten“, „dieses Sprachfeature sollte so sein“, „die Syntax so“, „die Semantik auf diese Art“, und so weiter. Ich treffe nur Entscheidungen und die anderen Entwickler setzen sie um. Also bin ich halb Designer und halb Programmierer. Ich verbringe ungefähr ein Drittel meiner Zeit mit MRuby.

Grigory: Ich habe Ihr GitHub-Profil besucht und viele Commits gesehen, auch am Tag Ihres Fluges nach Russland. In letzter Zeit wurde viel über das Thema Burnouts bei Entwicklern gesprochen. Haben Sie Freizeit? Irgendwelche Hobbys? Was tun Sie für Ihr Wohlbefinden, um Burnouts zu vermeiden?

Yukihiro: Zum Glück verbringe ich die ganze Zeit mit Open-Source-Software. Ich habe keinen Zeitdruck durch irgendwelche Kunden. Ich habe keine Vorgesetzten. Ich verwalte alles selbst. Das ist der Grund, warum ich bei der Arbeit so entspannt bin. Ich habe außer dem Veröffentlichungsdatum keine spezifischen Fristen. Durch diese Freiheit kann ich entspannt arbeiten. Das ist das einzige Geheimnis. Hinzu kommt, dass ich versuche, Zeit auch abseits vom Computer und vom Programmieren zu verbringen. Zum Beispiel verbringe ich viel Zeit damit, mit meinem Hund spazieren zu gehen und meine Katze zu streicheln. Ich unterstütze meine Gemeindekirche. Ich verbringe Zeit mit meiner Familie. Zeit mit Familie und Freunden zu verbringen hilft in der Hinsicht enorm.

Grigory: Viele Ruby-Entwickler aus Russland mögen Japan und genießen die japanische Kultur. Sie schauen Animes, lesen Manga, und einige von ihnen reisen nach Japan. Welche Orte und Aktivitäten können Sie als gebürtiger Japaner und Software-Entwickler anderen Entwicklern, die Japan besuchen, empfehlen?

Yukihiro: Japan ist ein sehr vielfältiges Land. Sie können futuristische Metropolen wie Tokio besuchen. Wir haben dort eine Menge Popkultur wie Manga und Anime. Gleichzeitig haben wir viele Berge, Wälder und historische Orte wie alte Schreine und Tempel. Auch die schönen Kirschblüten und Blätter sind ein Highlight. Es kommt auf Ihren Geschmack und Ihre Vorlieben an. Essen, Natur und Technologie können überall in Japan genossen werden. Ich empfehle, die Vielfalt des Landes zu genießen!

Grigory: Wird Ruby in irgendeiner Weise durch die japanische Kultur und Geschichte beeinflusst?

Yukihiro: Ich bin nicht sicher. Im Japanischen verketten wir Sätze, die der Methode der Verkettung in Ruby ähnelt. Dahingehend wurde die Sprache vielleicht beeinflusst. Japan ist ein wohlhabendes Land, und einige von uns müssen nicht so hart arbeiten, um zu überleben. Dadurch kann ich an Open-Source-Software arbeiten, die überhaupt kein Geld einbringt. Wir verkaufen Open-Source-Software nicht. Wir Leben von unseren Tagesjobs oder unseren Sponsoren. Das hilft uns und unseren Mitwirkenden, an Ruby zu arbeiten und bessere Technologien zu entwickeln. Mehr fällt mir dazu nicht ein.

Grigory: Und noch eine letzte, knifflige Frage. Menschen wollen oft wissen, wie es ist, die Welt mit den Augen anderer zu sehen – zu wissen, was sie denken und was sie fühlen. Gibt es Dinge im Leben eines Sprachenentwicklers, die von außen nicht wirklich offensichtlich sind?

Yukihiro: Ja, gibt es. Ungeachtet dessen, was andere empfinden, ist das Entwickeln einer Sprache nicht wirklich eine schwierige Aufgabe. Studierende im Hauptfach Informatik belegen Kurse zur Sprachimplementierung, und fast jeder, der einen Abschluss hat, kann seine eigene Programmiersprache schreiben. Technisch gesehen ist das gar nicht so schwierig.

Gleichzeitig verstehen viele oft die grundlegenden Design-Prinzipien einer Sprache nicht. Eine Sprache ist eine Art Gerüst des Verstandes; eine Art, Gedanken zu strukturieren. Das gilt auch für menschliche Sprachen wie Russisch, Japanisch und Englisch.

Programmiersprachen wie Ruby, Python, JavaScript und so weiter helfen, den Verstand zu entwickeln, damit man Ideen in etwas Greifbares und Nützliches verwandeln kann. Das ist der primäre Zweck einer Programmiersprache.

Ich denke, eine Programmiersprache sollte eine Philosophie haben, die uns beim Denken unterstützt. Daher konzentriert sich Ruby auf Produktivität und Spaß beim Programmieren. Andere Programmiersprachen konzentrieren sich stattdessen auf Einfachheit, Leistung oder ähnliches. Hinter jeder Programmiersprache steckt eine andere Philosophie und ein anderes Design. Wer sich mit der Philosophie von Ruby wohl fühlt, hat darin seine Sprache gefunden.

Grigory: Danke! Liebe Grüße von Grigory Petrov und Yukihiro Matsumoto von der RubyRussia-Konferenz 2019! Arigato!

Yukihiro: Arigato!

Video interview with Yukihiro Matsumoto:

Aus dem Interview mit Yukihiro haben wir etwas über die Philosophie von Ruby und über die Zukunftspläne des Kernteams für die Entwicklung der Sprache erfahren. Wir schätzen unsere Freundschaft mit Yukihiro sehr. Er inspiriert uns, Ruby in einer Vielzahl von Software-Entwicklungsprojekten einzusetzen. Wenn Sie coole Ideen haben und Ruby so sehr lieben wie wir, lassen Sie uns gemeinsam ein neues Produkt schaffen!