MacRuby / HotCocoa 能否取代对 Objective-C 的了解？
我刚刚发现了 MacRuby / HotCocoa，并且非常喜欢他们正在做的事情。
我基本上对自己制作 Cocoa GUI 应用程序的前景不以为然，因为我讨厌花时间和精力去开发 Cocoa GUI 应用程序。努力学习另一种基于 C 的语言，Objective-C。我并不是说这不好，只是不适合我。
现在或者在可能的未来，人们是否能够仅使用 MacRuby / HotCocoa 来制作具有实质性和一流性质的 Cocoa GUI 应用程序，而完全忽略 Objective-C？
（编辑：台式机 Mac，而不是 iPhone）
I just discovered MacRuby / HotCocoa and really like the sound of what they're doing.
I had essentially discounted the prospect of making Cocoa GUI applications myself because I have an aversion to spending time & effort learning yet another C-based language, Objective-C. I'm not saying it's bad, just not for me.
Is it the case now, or in the probable future, that one will be able to make Cocoa GUI applications of substantial and first-class nature with MacRuby / HotCocoa alone while ignoring Objective-C completely?
(Edit: Desktop Mac, not iPhone)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我确实在 RubyCocoa 上花了一些时间，但让我开始研究 Obj-C 的是，最终 Cocoa 和其他框架的所有文档都是用 Obj-C 语法编写的。在我看来，Obj-C 本身并不是一种非常大的语言，如果您有其他一些基于 C 的语言和 OOP 的经验，那么根本不需要花很长时间就能掌握。不过，框架的工作相当大，Cocoa 等，至少使用 rubyCocoa 你仍然需要学习框架。除此之外，我很难相信像 Ruby 这样的脚本语言能够提供与编译型 C 语言相同的性能。
I did spend some time on RubyCocoa, but what made me look into Obj-C was that in the end all documentation of Cocoa and other frameworks was written in Obj-C syntax. In it self Obj-C is not a very big language IMO, and should not take to long to pick up at all, if you have some experience in some other C based language and OOP. What is quite large is the frame works though, Cocoa etc. and at least with rubyCocoa you would still have to learn the frameworks. Besides this, I have a hard time believing that a scripting language like Ruby could ever give the same performance as a compiled C language.
可以使用 Apple 的框架编写 Ruby 应用程序，看起来就像本机 ObjC 应用程序一样。
但不要相信我的话，在此处查看此类应用程序的示例。它们的外观和执行都足够原生，以至于普通用户不可能区分原生 Ruby 和原生 ObjC。
It's possible to write a Ruby app using Apple's Frameworks that looks just like a native ObjC app.
But don't take my word for it, look here for examples of such apps. They look and perform native enough that it isn't possible for a casual user to distinguish between native Ruby and native ObjC.
嘿，我尝试了一下，然后放弃了，因为在看到它只是 ObjC 的替代品之后，ObjC 突然对我来说似乎是一种很棒的语言。我学了ObjC，我喜欢它。
Hey, I tried it, and give up, because after seeing it's all just replacement for ObjC, ObjC suddenly seemed to me as a fantastic language. I learn ObjC, and I like it.
MacRuby 是某人的宠儿项目。如果有人组装了一个编译器，可以从 Ruby 代码中生成本机二进制文件，那么它很可能有一天会取得一些进展。如果他们继续做他们现在正在做的事情，那么不会，它将仍然是一个利基产品，直到有人退出或被解雇，并将他们的工作与 Java Cocoa 绑定和 WebObject 一起埋葬。
MacRuby is somebody's pet project. If that somebody puts together a compiler that spews out native binaries from Ruby code, then it's a distinct possibility that it may gain some ground someday. If they just keep doing what they're doing now, then no, it's going to remain a niche product until that somebody either quits or gets fired and has their work buried alongside the Java Cocoa bindings and WebObjects.
MacRuby 并不是 Rob 所说的“翻译层”。它是与 Cocoa 使用相同对象系统的 Ruby。您当然可以用它构建“一流”的应用程序，并且还可以完成 Objective-C 不方便的事情。
请注意不要将 MacRuby 与 RubyCocoa 混淆。 Apple 并未为 MacRuby“提取所有模板”，因为它们从未默认发货。
此外，LLVM 与 Apple 平台的集成随着每个版本的发布而不断增强。 XCode 的下一个版本将依赖 LLVM 进行高级代码完成、检查和编译。如果说苹果公司不重视什么的话，那就是海湾合作委员会。
人们可能还会注意到，MacRuby 在 API 覆盖范围方面与 Objective-C 具有类似的限制：例如，创建经过身份验证的应用程序或访问钥匙串需要两种语言的包装类。
MacRuby isn't a 'translation layer' as Rob says. It's Ruby on the same object system that Cocoa is using. You can certainly build "first-class" applications with it, and also accomplish things that are inconvenient with Objective-C.
Be careful not to confuse MacRuby with RubyCocoa. Apple did not 'pull all the templates' for MacRuby, because they've never shipped by default.
Furthermore, LLVM's integration with Apple's platforms grows with each release. The next release of XCode will rely on LLVM for advanced code-completion, checking, and compilation. If Apple is deemphasizing anything it's the GCC.
One might also note that MacRuby has similar limitations in API coverage as Objective-C does: for instance, creating authenticated apps or accessing the keychain requires wrapper classes for both languages.
通过翻译层构建一流的应用程序将非常困难。获得本机所需的性能和行为已经够困难的了。 MacRuby 的方法给我留下了深刻的印象，特别是他们能够管理 Core Animation（一流 Mac 应用程序的关键部分）和 Core Data（这是一个棘手的东西）等内容。他们使用更惯用的 Ruby，而不是丑陋的 RubyCocoa，给我留下了深刻的印象。但苹果公司“不再强调”（他们是这样称呼的）他们在 Java、Ruby、Python 等方面的多语言调情是有原因的。用一种语言编写这些东西已经够难的了。当您不使用半支持的翻译层时，要使其正确就很难了。在实践中，你仍然需要学习 ObjC 语法来处理文档和所有现有代码。在实践中，你仍然需要学习 ObjC 模式来开发像样的 Mac 应用程序。
MacRuby 很有趣。即使作为一名经验丰富的 ObjC 程序员，我也可能会考虑使用 HotCocoa 来修改原型并尝试界面。但正如您所说，它不是我用来构建“具有实质性和一流性质的 Cocoa GUI 应用程序”的东西。
作为开发人员，我们工作的一部分就是拥有一包工具。就像一个好的木匠有几种不同的锤子，加上撬棒、钉子、几种角尺和十几种其他工具一样，程序员应该熟悉各种语言、编程范例、平台和环境。然后，她应该能够为工作选择正确的工具并有效地使用它们。对于 Mac 编程，适合该工作的正确工具包括 Xcode、IB、ObjC 和 Cocoa。避开它们就像木匠避开框架锤和速度尺一样。他们只是工作的一部分。
It will be extremely difficult to build first-class apps through a translation layer. It's hard enough to get the performance and behavior you need natively. I'm impressed with MacRuby's approach, and particularly impressed that they are able to manage things like Core Animation (a key piece of first-class Mac apps) and Core Data (which is tough stuff). I'm really impressed with their use of more idiomatic Ruby rather than the ugliness of RubyCocoa. But there are reasons that Apple has "deemphasized" (as they've called it) their multi-language dalliances in Java, Ruby, Python, etc. It's hard enough to write this stuff in one language. It's hard enough to get it right when you're not going through a semi-supported translation layer. In practice, you still have to learn the ObjC syntax to deal with the documentation and all the existing code. In practice, you still have to learn the ObjC patterns to develop decent Mac apps.
MacRuby is interesting. Even as a seasoned ObjC programmer, I might consider HotCocoa for hacking up prototypes and trying out interfaces. But it's not the kind of thing I'd use to build, as you say, "Cocoa GUI applications of substantial and first-class nature."
As developers, part of our job is to have a bag of tools. Like a good carpenter has several different hammers, plus pry bars, nail sets, several kinds of square and a dozen other tools, a programmer should be comfortable with a variety of languages, programming paradigms, platforms and environments. She then should be able to choose the correct tools for the job and employ them effectively. In the case of Mac programming, the correct tools for the job include Xcode, IB, ObjC and Cocoa. Avoiding them is like a carpenter avoiding a framing hammer and speed square. They're just part of the job.