Könnte MacRuby / HotCocoa die Notwendigkeit, Objective-C zu kennen, verdrängen?

Es wird extrem schwierig sein, erstklassige Apps über eine Übersetzungsebene zu erstellen. Es ist schwer genug, um die Leistung und das Verhalten zu erreichen, die Sie nativ benötigen. Ich bin beeindruckt von MacRubys Ansatz und besonders beeindruckt, dass sie in der Lage sind, Dinge wie Core Animation (ein Schlüsselelement erstklassiger Mac-Apps) und Core Data (was harte Sachen sind) zu verwalten. Ich bin wirklich beeindruckt von der Verwendung von mehr idiomatischem Ruby als von der Hässlichkeit von RubyCocoa. Aber es gibt Gründe dafür, dass Apple ihre mehrsprachigen Dallianzen in Java, Ruby, Python usw. "deemphasiert" hat. Es ist schwer genug, diese Sachen in einer Sprache zu schreiben. Es ist schwer genug, um es richtig zu machen, wenn Sie nicht durch eine halbunterstützte Übersetzungsschicht gehen. In der Praxis müssen Sie immer noch die ObjC-Syntax erlernen, um mit der Dokumentation und dem gesamten vorhandenen Code umgehen zu können. In der Praxis müssen Sie immer noch die ObjC-Muster lernen, um anständige Mac-Apps zu entwickeln.

MacRuby ist interessant. Selbst als erfahrener ObjC-Programmierer könnte ich HotCocoa für das Hacken von Prototypen und das Ausprobieren von Schnittstellen in Betracht ziehen. Aber es ist nicht die Art von Sache, die ich verwenden würde, um zu bauen, wie Sie sagen, "Cocoa GUI-Anwendungen von wesentlicher und erstklassiger Natur."

Als Entwickler gehört es zu unserer Aufgabe, eine Tasche mit Werkzeugen zu haben. Wie ein guter Zimmermann hat mehrere verschiedene Hämmer, plus Brechstangen, Nagel-Sets, verschiedene Arten von Quadraten und ein Dutzend anderer Werkzeuge, sollte ein Programmierer mit einer Vielzahl von Sprachen, Programmierparadigmen, Plattformen und Umgebungen vertraut sein. Sie sollte dann in der Lage sein, die richtigen Werkzeuge für den Job zu wählen und sie effektiv einzusetzen. Im Falle der Mac-Programmierung sind die richtigen Werkzeuge für den Job Xcode, IB, ObjC und Cocoa. Sie zu meiden, ist wie ein Zimmermann, der einen Rahmenhammer meidet und das Quadrat beschleunigt. Sie sind nur ein Teil des Jobs.

  

"Es ist das Ziel von MacRuby zu ermöglichen   die Erstellung von vollwertigen Mac OS X   Anwendungen, die nicht opfern   Leistung, um das zu genießen   Vorteile der Verwendung von Ruby. "    - die MacRuby README

MacRuby ist keine "Übersetzungsschicht", wie Rob sagt. Es ist Ruby auf dem gleichen Objektsystem, das Cocoa verwendet. Sie können damit sicher "erstklassige" Anwendungen erstellen und auch Dinge erreichen, die mit Objective-C unpraktisch sind.

Achten Sie darauf, MacRuby nicht mit RubyCcoa zu verwechseln. Apple hat nicht alle Vorlagen für MacRuby "gezogen", weil sie standardmäßig nicht ausgeliefert wurden.

Darüber hinaus wächst die Integration von LLVM mit Apples Plattformen mit jedem Release. Die nächste Version von XCode wird LLVM für erweiterte Code-Vervollständigung, Überprüfung und Kompilierung verwenden. Wenn Apple nichts betont, ist es der GCC.

Es kann auch sein, dass MacRuby ähnliche Einschränkungen in der API-Abdeckung aufweist wie Objective-C: Zum Beispiel erfordert die Erstellung authentifizierter Apps oder der Zugriff auf den Schlüsselbund Wrapper-Klassen für beide Sprachen.

Ich habe einige Zeit mit RubyCocoa verbracht, aber was mich dazu gebracht hat, in Obj-C zu schauen, war, dass am Ende die gesamte Dokumentation von Cocoa und anderen Frameworks in Obj-C-Syntax geschrieben wurde. In sich selbst ist Obj-C keine sehr große Sprache IMO, und sollte nicht lange dauern, um überhaupt aufzuheben, wenn Sie etwas Erfahrung in einer anderen C-basierten Sprache und OOP haben. Was ziemlich groß ist, ist der Frame funktioniert, Cocoa etc. und zumindest mit RubyCocoa müsste man noch die Frameworks lernen. Außerdem fällt es mir schwer zu glauben, dass eine Skriptsprache wie Ruby jemals die gleiche Leistung wie eine kompilierte C-Sprache bieten könnte.

MacRuby ist jemandes Lieblingsprojekt. Wenn dieser jemand einen Compiler zusammenstellt, der native Binärdateien aus dem Ruby-Code spuckt, dann ist es eine deutliche Möglichkeit, dass er irgendwann ein Stück weit an Boden gewinnt. Wenn sie einfach weiter machen, was sie gerade tun, dann wird es ein Nischenprodukt bleiben, bis jemand entweder aussteigt oder entlassen wird und seine Arbeit neben den Java Cocoa Bindings und WebObjects begraben wird.