Interview mit Aaron Patterson, Sprecher der RubyRussia-Konferenz 2018

Hallo! Wir setzen eine Reihe von Interviews mit Rednern auf der RubyRussia- Konferenz fort. Aaron Patterson (auch bekannt als Tenderlove ) ist Mitglied des Ruby-Kernteams und des Rails-Kernteams, einem führenden Softwareentwickler in einem kleinen Startup namens GitHub. Pavel Argentov sprach vor seiner zweiten Reise nach Russland mit Aaron.



Beginnen wir mit der Standardfrage. Was ist deine persönliche Rubingeschichte? Wie haben Sie diesen Zug erwischt? Erzähl mir von deinen Erfolgen? Hast du die Welt zu einem besseren Ort gemacht?

Ich habe Ruby 2006 entdeckt. Ich war damals ein Java-Programmierer. Fangen wir noch früher an: Ich war ein Perl-Programmierer und wurde dann ein Java-Programmierer, aber ich wollte kein Javist sein.

Warum?

Als ich in Perl schrieb, hatten wir bereits ein eigenes Webframework. Rails hatte vieles zu bieten: Sie konnten einfach den Code ändern, die Seite neu laden und überprüfen, was passiert ist. Alles hat einfach funktioniert. Als wir zur Java-Entwicklung wechselten, wurde es so: Sie müssen alles neu kompilieren - es dauert 10 Minuten, bis Sie alle gerade vorgenommenen Änderungen überprüfen können. Ich mag dynamische Sprachen wie Perl mehr als Java. Perl 6 wurde erwartet. Während ich auf Perl 6 wartete, erfuhr ich etwas über Ruby. Gedanke: „Wow! Das brauche ich! “ Also habe ich angefangen, Ruby zu machen - in meiner Freizeit zum Beispiel für Nebenprojekte. Weißt du, nur zum Spaß. Damit fing alles an. Schließlich bekam ich 2008 bereits einen Job bei Ruby.

War es schon Rails?

Ja, mein Freund hat beschlossen, ein Startup zu starten. - Wir werden Rails verwenden. Möchten Sie mit uns in derselben Firma arbeiten? Ich bin so: - Ja, natürlich arbeite ich gerne an den „Schienen“! So habe ich angefangen.

Ehrlich gesagt hat mir meine Arbeit in dieser Firma nicht gefallen. Deshalb habe ich bei jeder Gelegenheit direkt am Arbeitsplatz Open Source geschrieben. Dies wurde wie folgt durchgeführt: - Ok, das Projekt wird 2 Tage dauern. Dann beendete ich die Angelegenheit in ein paar Stunden und nutzte den Rest der Zeit für Open Source.

Was wir genannt haben: "Schlagen Sie nicht die Bremsschwelle!" Ich sitze hier ruhig und repariere den Primus. Lass mich in Ruhe, Pliz!

Ja! Also habe ich hier angefangen, viel mit Open Source zu arbeiten. In dieser Arbeit habe ich angefangen, Nokogiri zu schreiben und allgemein an meinem Ruby Open Source zu arbeiten. Also ging ich generell in Open Source. Er hat einfach „einen Beitrag geleistet“, bis er eines Tages den Teams Ruby Core und Rails Core beigetreten ist.

Wie bist du zum Rails Core Team gekommen?

Wir haben gerade Fehler gefunden und Rails-Anwendungen entwickelt. Ich habe Fehler gefunden, sie behoben und Patches gesendet. Ich habe gerade Patches gesendet. Am Ende sind sie es leid, dass ich nur Pull-Anfragen fahre.

Nehmen Sie die Sache jetzt selbst in die Hand, oder?

Ja, genau! Alles in allem war es wie ein Brute-Force-Angriff!

Klingt vernünftig! Was ist Ihr Gesamtbeitrag zu Rails?

Ich habe viel an fast allen Teilen des Frameworks gearbeitet. Meistens über Active Record. Ich mache besonders gerne Fehlerbehebungen und verbessere die Leistung. Der Grund für diesen Anhang ist, dass dadurch die Anwendungen von Personen verbessert werden. Jeder freut sich, wenn die Anwendung besser wird und Sie dafür nichts tun müssen. Deshalb arbeite ich gerne daran.

Sie machen einige „kleine“ Verfeinerungen, mit denen alles funktioniert. Aber mussten Sie nicht „große“ Dinge entwerfen?

Wenn ich in Rails etwas Architektonisches mache, ist es normalerweise etwas drinnen. Zum Beispiel die Architektur der Arbeit mit URLs, Assoziationen und Dingen im Router - so ähnlich. Keines dieser Dinge wird notwendigerweise auffallen. Sie können vom Benutzer gesehen werden, aber dies ist nicht in der Form: "Hier ist es, die wahre Sache!" Ich versuche, mich an diesen Stil zu halten. Ich denke, dass dies tatsächlich gut ist, weil David ( DHH - P.A.) gerne New Brilliant Fine Features macht. Ich sage mir vielmehr: „Dann machen wir diese zu Ihren Feinheiten. Du siehst aus und die Wahrheit wird wunderschön herauskommen! “

Ja, jemand muss die ganze manuelle Arbeit erledigen. In Ihrer Präsentation auf der Konferenz geht es beispielsweise um bestimmte Deep-Engineering-Teile von Ruby im Allgemeinen und Rails im Besonderen. Worum geht es in der Präsentation wirklich?

In der Tat werde ich über Ruby-Interna sprechen. Ich habe die ganze Rede nicht bis zum Ende erfunden.

GC, Leistung, all das, Leben, Universum, 42?

Ich denke über den Garbage Collector, den Ruby-Kompilierungsprozess und den Bytecode nach. Grundsätzlich geht es um Bytecode in einer virtuellen Maschine und wie sich dieser auf den Garbage Collector bezieht. Über einige der Leistungsverbesserungen, die ich in GC vorgenommen habe. Ich erwarte nicht viel über Rails zu reden.

Unsere Konferenz hieß früher Rails Club. Unsere Organisatoren dachten nach und benannten die ganze Idee um, hauptsächlich weil Matz sagte, dass er niemals an Konferenzen mit dem Wort „Rails“ im Titel teilnimmt. Jetzt sind wir also "Ruby Russia"!

Also werde ich über Ruby-Interna sprechen!

Was sollten Rails-Programmierer Ihrer Meinung nach tun, um eine bessere Leistung in ihrem Code zu erzielen?

Es gibt verschiedene Strategien. Erstens, machen Sie im Allgemeinen nichts Besonderes. Schreiben Sie einfach Ihre Bewerbung. Starten Sie es, erhalten Sie Kunden, Feedback usw. Analysieren Sie sofort die festgestellten Engpässe. Arbeiten Sie niemals mit Engpässen, bis die echte Arbeit mit Kunden sie aufdeckt. Wenn Sie mit Engpässen umgehen, die es wirklich nicht sind, ist dies Zeitverschwendung. Diese Zeit könnte für neue Funktionen verwendet werden. Ich denke jedoch, dass viele dasselbe sagen würden. Sprechen wir also darüber, was die Leistung wirklich beeinflusst. Schauen Sie sich zunächst die Datenbankabfragen an, die auf der Seite durchgeführt werden. Dies ist die erste Verteidigungslinie - versuchen Sie, den Zeitaufwand für bestimmte Anforderungen zu reduzieren. Abfragen selbst - automatisieren und reduzieren. Sie werden nicht glauben, wie oft wir vergessen, nur einen Index hinzuzufügen. Ha! Machen Sie also mindestens den Index an der richtigen Stelle.

Ich führe technische Interviews und stelle mir vor, wie die Leute vergessen, was Indizes im Allgemeinen sind. Warum müssen Sie sich überhaupt darum kümmern ... Nun, was sagen Sie zu anderen Dingen, die Rubisten wissen sollten? Welche technischen Dinge sollte ein Rubist wissen, um seine Arbeit besser zu machen?

Es gibt ein paar solcher Stücke. Ich denke, die erste besteht darin, die Ruby-Sprache selbst zu kennen. Lerne die Sprache sehr sorgfältig. Das zweite ist, UNIX gut zu verstehen.

Sie sind der erste "mein" Sprecher, der sagt, dass Sie UNIX kennen müssen. Also bin ich persönlich aus der UNIX-Welt zu Ruby gekommen. Ich habe an Linux, FreeBSD und tonnenweise Perl-Code gearbeitet. Ich kam als ein anderer Perl zu Ruby, um meine Sysadmin-Angelegenheiten zu erledigen, und erst dann stellte ich fest, dass es sich auch um eine Web-Sprache handelte. Sie sagen also, Sie müssen UNIX kennen. Wie und warum?

Es ist wichtig, die POSIX-Standards und ihre Interaktion mit dem Betriebssystem zu studieren, da Sie dies feststellen werden, sobald Sie mit der Skalierung beginnen. Sie ...

... sollte wissen, wer General Feiler ist und warum er meine Akte liest?

Haha ja! Sie müssen wissen, was die Leistung verändert. Vielleicht müssen Sie sich das nicht auswendig merken, aber Sie sollten wissen, dass es sie gibt (Systemaufrufe - P.A.) und wie man sie googelt, denn Sie werden definitiv auf diese Wirtschaft stoßen. Sie sind wichtig, da die Anwendung auf einem UNIX-Server bereitgestellt wird. Sie müssen daher wissen, wie die Anwendung mit dem Betriebssystem interagiert, auf dem sie ausgeführt wird. Ein weiterer wichtiger Punkt ist, dass Sie diese Fähigkeit unter UNIX beispielsweise in anderen Sprachen anwenden können. Wenn Sie auf Probleme stoßen, können Sie immer an diesem Punkt beginnen. Dies ist vielleicht die Hauptsache, die ich Programmierern zum Lernen empfehle.

Halten Sie es für nützlich, wenn der Rubist eine andere Sprache beherrscht? Ist es möglich, ein guter Programmierer in Ruby zu sein, ohne etwas außerhalb von Ruby zu wissen?

Gute Frage. Ehrlich gesagt weiß ich es nicht. Alle guten Rubisten, die ich kenne, kennen andere Sprachen. Ich weiß jedoch nicht, ob es notwendig ist, andere Sprachen zu lernen, um ein guter Ruby-Programmierer zu werden. Ich denke, es kommt einfach vor, dass Leute andere Sprachen lernen.

Gute Beobachtung! Aus medizinischer Sicht verzögert sich der Beginn der Alzheimer-Krankheit umso mehr, je mehr Sprachen eine Person kennt.

Ha ha!

Nach 40 muss man über solche Dinge nachdenken ...

Ich nähere mich 40 Jahren! Es ist gut für mich zu wissen!

Reden wir über Ruby selbst. Ruby ist eine Sprache mit einer großen Vergangenheit. Hat er eine Zukunft? Vor nicht allzu langer Zeit war ich in St. Petersburg auf einer der größten IT-Konferenzen, die ich in Russland gesehen habe. Die lokale Rubingemeinschaft war auf dieser Konferenz nicht vertreten. Ich musste ständig Ruby-Apologetik machen: Ruby ist nicht so tot, sie schreiben immer noch Ruby. Ruby hat übrigens das bekannteste Webframework - und das alles. Jede große Sprache auf dem Markt verfügt jetzt über eine Art Webentwicklungstool. Geh, Rust, was auch immer. Was ist der Platz von Ruby in diesem Ökosystem und hat „Ruby mit einer großen Vergangenheit“ eine Zukunft?

Ich denke, die Antwort auf diese Frage hat mehrere Aspekte. Es gibt viele verschiedene Sprachen, für die es Web-Frameworks gibt, aber ich denke immer noch, dass Ruby, wenn man sie unter dem Gesichtspunkt der Ergonomie des Entwicklers betrachtet, sowieso ganz oben steht. Es ist einfach zu bedienen und leicht zu verkaufen. Das Problem ist, dass Ruby nicht mehr "brandneu und brillant" ist. Die Leute wollen sich von etwas Neuem mitreißen lassen. Sie wollen den nächsten Zug nach Rails nehmen.

Sie wollen den Geruch eines neuen Autos!

Ja! Über die Zukunft ... Es gibt viele neue Entwicklungen in Ruby, insbesondere über JIT und das, womit Koichi: Guilds arbeitet. Ich würde sagen, dass Ruby definitiv eine Zukunft hat, aber jeder wird hart dafür arbeiten müssen. Wenn wir die richtigen Anstrengungen unternehmen, wird die Zukunft sicherlich sein.

Hat Ruby eine Perspektive in anderen Bereichen als der Webentwicklung? Oder kennen Sie Beispiele, bei denen Ruby jetzt außerhalb der Webentwicklung verwendet wird?

Gute Frage! Es ist schwer zu beantworten, da ich mich nur mit Webentwicklungsproblemen befasse.

Ich frage, weil es mein persönliches Interesse ist. Leute aus der Python-Community zum Beispiel prahlen gerne mit ihren Erfolgen im wissenschaftlichen Rechnen.

Ich weiß, dass es in Ruby eine Gruppe gibt, die an wissenschaftlichen Werkzeugen arbeitet. Aber ich denke, die echte Alternative für Ruby ist die Systemadministration.

Wie können wir Entwickler aus anderen Sprachen in unsere Community bringen?

Das ist eine wirklich gute Frage! Ich denke, wir müssen uns nur auf die Ergonomie der Entwicklung konzentrieren, darauf, was die Entwicklung von Webanwendungen so einfach wie möglich macht. Wir müssen uns darauf konzentrieren, die Einstiegsschwelle für neue Entwickler zu senken, die Webanwendungen einbinden und schreiben. Wir werden also mehr neue Programmierer anziehen.

Es ist Zeit für die Hollywood-Frage zu JavaScript. Sie wissen, es gibt ein Sprichwort: "Alles, was in JavaScript umgeschrieben werden kann, wird notwendigerweise in JavaScript umgeschrieben." Denken Sie, dass Rails auch in JavaScript neu geschrieben wird? Wir haben über die Ergonomie der Entwicklung von Ruby gesprochen. Das ist das Beste an Rails. Einer der sehr berühmten russischen Programmierer sagte, dass "viele Sprachen gut sind, aber nur Ruby Rails hat". JavaScript-Entwickler neigen jedoch dazu, dies in Frage zu stellen. Wie können wir mit JavaScript konkurrieren? Oder sollten wir eine Symbiose mit ihm vereinbaren?

Es ist wahr, dass nur Ruby Rails hat. Wenn Sie sich Web-Frameworks für JavaScript ansehen, denke ich nicht, dass sie in Bezug auf die Entwicklungsergonomie mit Rails vergleichbar sind. Tatsache ist, dass wir, da wir Webanwendungen schreiben, mit JavaScript arbeiten müssen. Wir müssen Teil der JavaScript-Community sein. Es ist nützlich für uns, eine Symbiose zu haben. Wenn Sie eine Sprache auf dem Server ausführen können, warum sollte es dann JavaScript sein? Aber die Sprache ist gut und ich denke, wir müssen symbiotisch arbeiten. Die einfache Entwicklung ist immer noch auf unserer Seite und wird besonders in der Rails-Community geschätzt. Sie sind also zur IT-Konferenz gekommen und mussten dort als Vertreter von Ruby arbeiten?

Es war ziemlich informell, weil ich nicht einmal T-Shirts über meine Firma oder Sprache hatte. Also habe ich gerade die klügste Gruppe junger Leute gefunden, die sich als Pythonisten herausstellten, und wir haben angefangen zu plaudern.

Für uns ist es gut, wenn wir mit anderen Sprachen zusammenarbeiten und nicht mit ihnen konkurrieren. Persönlich denke ich, dass das Programmieren in Ruby viel einfacher und unterhaltsamer ist als in anderen Sprachen. Warum nicht? Wir sprechen über andere Programmiersprachen und ob wir sie kennen sollten. Ich halte es für wichtig, dass Rubisten andere Sprachen lernen. So etwas wie Java, Haskell oder etwas anderes wie Elixir oder Lisp, so etwas. Ich denke, es ist nützlich, verschiedene Paradigmen zu studieren, denn wenn Sie neue Dinge lernen, können Sie diese wegnehmen und in Ihrer eigenen Sprache verwenden. Eine gute Eigenschaft von Ruby ist, dass wir in unseren Programmen Techniken aus verschiedenen Sprachen verwenden können.

Ja, wir haben zum Beispiel Tools für die funktionale Programmierung oder das Durchführen von Map / Reduce oder etwas anderem.

Ja, wir können das alles nutzen. Wenn Sie eine Sprache verwenden, die diese Techniken fördert, finden Sie möglicherweise einen besseren Weg, um das Problem zu lösen. Ich bin mir nicht sicher, ob es notwendig ist, andere Sprachen zu lernen, um ein guter Rubist zu sein, aber diese Studie hilft mir definitiv. Ehrlich gesagt verbringe ich 50% meiner Zeit mit Programmieren in C.

C macht die Finger stärker!

Ich programmiere in C, damit andere in Ruby programmieren können.

Sind Ruby-Interna in reinem C geschrieben, nicht in ++?

Auf eine saubere. Es wäre schön, wenn mehr von diesem Code in Ruby geschrieben wäre, aber ehrlich gesagt sollten einige der wichtigsten Dinge aus Leistungsgründen in C geschrieben werden. Eines der Dinge, die ich tue ... Wir müssen das Speicherprofil verbessern. Daher arbeite ich an Tools zur Speicherprofilerstellung in Ruby. Da alle Innenseiten in C geschrieben sind, muss ich Werkzeuge in C schreiben. Bei der Arbeit schreibe ich viel Code.

Wie geht es Ruby mit FFI und dergleichen?

FFI funktioniert gut genug, wenn Sie eine C-Bibliothek in Ihrer Arbeit haben, die eine oder zwei Funktionen benötigt. Wenn etwas komplizierter ist ... dann ist alles komplizierter. Wenn Sie mit FFI arbeiten, schreiben Sie im Grunde C-Code, der Ruby ähnelt. Sie müssen jedoch noch mysteriöse Dinge wie die Speicherverwaltung ausführen. Ich persönlich finde es einfacher, zwischen diesen Welten zu wechseln, wenn Sie C zum Verwalten des Speichers usw. verwenden. In anderen Fällen wechsle ich zu Ruby.

Haben wir in Ruby Schnittstellen zu anderen Sprachen?

Einige Schnittstellen zu JavaScript. Ich habe einen Mann gesehen, der mit wissenschaftlichen Aufgaben beschäftigt war, also hat er sich mit Python verbunden.

Hat es direkt mit der Sprachlaufzeit interagiert?

Ja genau. Nicht wie Beschuss oder so etwas ... Das Projekt ist immer noch sehr experimentell. Wenn er eine Demo gibt, sagt er, dass "alles funktioniert, aber es kann fallen!"

Ich kenne eine Reihe berühmter Rubisten, die Rust kreiert haben. Warum haben die Leute das wohl gemacht und wie geht es ihnen?

Ich mag Rust, ich denke es ist eine sehr gute Sprache. Der Grund, warum Leute zu Rust gehen ... sie wollen eine Sprache, die mehr Sicherheitsfunktionen bietet als C bietet. Es wäre wirklich großartig, Ruby in Rust neu zu schreiben. Ich persönlich bin ein großer Fan von Rust, ich liebe ihn.

Wie kann es nützlich sein? Ist es sicherer, schneller oder was?

Ich denke, es ist sicherer. Ich bin nicht sicher, ob es optimierter als C ist, aber es ist definitiv sicherer. Das mag ich an ihm. Wenn ich C-Code schreibe, bin ich mir fast sicher, dass es nicht SEGV ist, aber es ist nicht 100% sicher. Aber wenn ich in Rust schreibe, bin ich mir sicher viel mehr. Wenn ich in C schreibe, bin ich mir ziemlich sicher, dass es keinen Speicherverlust geben wird. Mit Rust ist es als weißer Tag klar, dass es keinen Speicherverlust geben wird. Deshalb bevorzuge ich persönlich Rust gegenüber C. Ich habe auch angefangen, Rust zu lernen, weil ich Erweiterungen für Ruby darauf schreiben möchte. Es gibt ein ganzes Projekt namens "Helix" - speziell dafür. Wenn ich in C schreibe, lautet das oft wie folgt: "OK, ich habe eine C-Bibliothek, und ich muss von Ruby aus darauf zugreifen, indem ich ein paar Krücken schreibe." Die Verwendung von Rust ist eine Spatzenkanone. In meiner idealen Welt wird alles, das gesamte System, eines Tages in Rust neu geschrieben. Rust wird unser neues C. sein. Wenn Sie ein Problem schnell lösen müssen, schreiben Sie in Ruby. Und das Betriebssystem wird auf Rust erstellt. Und jeder wird glücklich sein.

Ist Rust dafür reif genug?

Nun, ich weiß es nicht. Ich denke ganz. Bei Mozilla nutzen sie es - und sind zufrieden.

Was ist die Chance, Register zu sehen, indem Sie ein Programm in Rust ausführen?

Haha, ich weiß es nicht! Hoffe niedrig! Das zu sehen ist überhaupt nicht lächerlich.

Vor allem, wenn Sie etwas im Browser starten.

Ja Eine Meldung über einen Absturz wird angezeigt, und Sie sagen: "OK." Ha! Bei der Arbeit haben wir einige Dinge in C ++, und manchmal, wenn ich abstürze, gefällt mir einfach Folgendes: "Hmm ..."

Ich möchte in einer Sprache programmieren, nicht in einem Makro-Assembler! - Es war mein Lieblingswitz, als ich von C zu Ruby wechselte ...

Du hast tatsächlich recht. Wann immer ich in C schreibe, ist die Frage, woran ich denken soll. Ich denke wirklich nicht daran, dass das Problem gelöst wird. Bei Ruby muss ich nicht über all das nachdenken (Low-Level-Economy - P.A.). Ich konzentriere mich nur auf die Logik des Programms und mache Geschäfte. Dies ist einer der Gründe, warum ich Ruby so sehr liebe! Als ich während Java 1.3 ein Javist war, war das bevor Generika dort erschienen. Jedes Mal, wenn ich so etwas wie eine Karte schreiben musste - zum Beispiel Sammlungen oder Iteratoren - musste ich "iterator.next ()" ausführen und dann den resultierenden Wert umwandeln ... Erst dann die erforderliche Operation ausführen. Dann fing ich an, Ruby zu lernen, wo sich die Karte bereits in Perl befand ...

... Oh, ein Wunder! Direkt in meinen Händen habe ich ein Objekt genau des Typs, den ich brauche!

Ja, genau. In Java müsste ich 15 Codezeilen schreiben, um das zu erreichen, was ich als einzelne Zeile in Ruby tun kann. Ich würde in Ruby schreiben, ich würde den Job viel schneller beenden! Anstatt all diesen Müll zu schreiben! Das zu verstehen hat mich bei diesem Job sehr verärgert. Ich habe Stunden mit zusätzlichem Verkehr verbracht!

Existenzieller Horror!

Genau! Es war ein Wendepunkt. Ich musste Arbeit an Ruby finden. Ich kann Java erst am Ende meines Lebens schneiden!

Kann man argumentieren, dass Ruby den Verstand des Programmierers verbessert?

Ich denke, wenn Sie mehr Zeit für hochrangige Aufgaben und die eigentlichen Ziele des Programms verwenden können, wird dies dazu beitragen, das abstrakte Denken zu verbessern. Sie üben immer mehr, über das System als Ganzes nachzudenken und nicht über die winzigen Zahnräder des Programms. Ich möchte Sie daran erinnern, dass ich in C ständig über all diese Kleinigkeiten nachdenken muss und nicht über das Problem, das ich löse. Tatsächlich lernen Sie genau das Lösen von Problemen, dh Aufgaben der obersten Ebene. Ich denke, es kann Sie als Programmierer verbessern.

Ich erinnere mich an meinen eigenen Eindruck, als ich in den 90ern anfing. Ich habe versucht, OOP zu meistern. Ich habe versucht, C ++ zu machen. Ich las Bücher, lernte die "heilige Dreifaltigkeit der PLO". Und dann bin ich wieder dabei, dieselben „Makroassembler“ -Tricks zu beherrschen. Dann habe ich versucht, in Java zu arbeiten, ich habe etwas Geld in Perl verdient. Und erst in Ruby habe ich endlich verstanden, wie OOP funktioniert.

Du sagst das Ding. Wenn Sie an andere OOP-Sprachen wie C ++ oder Java denken, haben nicht alle ein Objekt. Zum Beispiel gibt es immer noch nur Ints. Es gibt immer noch Primitive, und sie müssen anders behandelt werden als mit Objekten. In Ruby ist eigentlich alles ein Objekt. Es muss nur OOP behandelt werden. Mehr Bewegung, mehr Bedeutung. Ich habe wirklich nicht viel darüber nachgedacht, bis du gefragt hast.

Die Sprache ist so sorgfältig gestaltet, dass Sie nur in die richtige Richtung denken. Es formt den Geist. Die Syntax selbst erklärt, was Sie tun.

Ich habe mit OOP in Perl gearbeitet. Dies ist im Allgemeinen nur ein Hack für OOP-ähnliche Dinge. Java implementiert natürlich OOP. Aber sie hat unter anderem keine Objekte. Ruby auf unserer Liste ist die erste Sprache, in der alles wirklich ein Objekt ist.

Mit welchen Worten würden Sie sowohl junge als auch alte Programmierer inspirieren?

Gute Frage! Ich denke, das ist es, was für junge und alte Rubisten funktioniert: Ich persönlich glaube, dass Ruby die einzige Sprache ist, die Fans bei der Verwendung gibt. Junge Programmierer, die bereits andere Sprachen beherrschen, probieren Ruby aus, weil es wirklich Spaß macht. Alte Programmierer mit solider Erfahrung in anderen Sprachen können alles vergleichen und verstehen, wie gut Ruby ist. Wenn Sie anfangen, etwas anderes zu verwenden, werden Sie sich sagen: Wow, aber Ruby ist nichts!

Am Wochenende mache ich einige kleine Übungen in anderen Sprachen. Nach dem Wochenende kehre ich zur Arbeit zurück, öffne meine Emacs mit Ruby und sage mir: "Oh mein Gott, wie schön ist es, in deine Heimat zurückzukehren!"

Ja, ich denke, es ist gut, in andere Sprachen zu wechseln, dort zu arbeiten und einige Beobachtungen zu sammeln. Ich freue mich immer wieder zurückzukehren. Ich fühle mich wie zu Hause in Ruby.

Es wird möglich sein, Aaron am 6. Oktober persönlich Fragen zu stellen. Wir sehen uns also auf der Konferenz! Alle Details auf der Website .

Sie können das Original in englischer Sprache unter hype.codes lesen .

Und vielen Dank an die Unternehmen, die das Ruby-Hauptereignis in Russland unterstützen:

Komplementärin - Toptal
Gold Partner - Gett und Cookpad
Silberpartner - Instamart , UCHi.ru , JetBrains und Qlean
Afterparty- Partner - Teachbase
Bronze Partner - Bookmate und InSales