7 ms·

I've never understood this logic: The existence of this project is not an attack on Objective-C. Objective-C is not hard to learn and awesome, I agree. But what

I've never understood this logic: The existence of this project is not an attack on Objective-C. Objective-C is not hard to learn and awesome, I agree. But what does that have to do with providing an alternative? There can exist multiple good solutions to one problem. You said it yourself: Ruby is not always the best tool for the job, perhaps Objective-C is also not always the best tool for the job. Perhaps the use of UIKit through Ruby will provide interesting insights that will later be used to make Objective-C better: all the Objective-C 2.0 additions (including the ones you mention) were certainly a response to modern languages that made a lot of things easier for programmers. As an Objective-C programmer myself, I was initially really turned off by this attitude from the JavaScript community: (Why do we need we need a LISP implementation in JS? It's already a functional language! Why do we need Objective-J? JS already kind of has classes!). Hilariously enough, the only language that was "accepted" by the JS community was the one that specifically promised that it wouldn't add any new features: CoffeeScript. I missed the Objective-C community precisely because I had always found it quite unreligious and practical: to each his own when it comes to development -- I hope that with its latest success it hasn't become more dogmatic and insular.

nupark2 15y ago
I am personally concerned that the Rubyists will flood the iOS development space, bringing their culture and introducing a dogmatic and insular environment. We already have -- and without great fanfare -- Lua, JavaScript, C# (MonoTouch), et al. This seems somehow different.
- jeremymcanally 15y ago
  How ridiculous. You do realize that every programming community has "dogmatic and insular" people, right? There are Cocoa people I've talked with who were, seriously, the rudest human beings I've ever had the displeasure of talking to. Douchebags are everywhere and it's sort of silly to paint an entire community with a broad brush. We're doing lots of good things, too, despite our own share of jerks.
- danneu 15y ago
  Rest assured that your attitude is far more insufferable and real than the "culture invasion" you're concerned about.
- jenius 15y ago
  Goodness - what a hateful, stereotyping, and narrow-minded comment. I'm enjoy ruby and spend a lot of time writing it, but would never pass judgement like this on anyone who uses another language. I've never interacted with anyone writing in any language that has an attitude like this - let's hope that you are an edge case...
  - nupark2 15y ago
    Honestly, I'm part of the mostly-silent majority of polyglot programmers that choose the best language for the job and have grown increasingly weary of Rubyists wheel invention and focus on rock star programming and rock star rants. It's the only community that I find socially insufferable, and while an unpopular opinion here, I don't relish the notion of Rubyist culture. Culture aside, simply technologically, Ruby has nothing significant to offer as compared to the many existing languages and technology stacks, especially those pushing forward language and runtime research. The only argument for Ruby here seems to be opening the market to developers unwilling to move beyond it.
    - nupark2 15y ago
      Following up to note that: - Despite the opinion clearly being unpopular here, I stand by it: the ruby community is toxic-at-best, and totally technogically uninteresting. Individual Ruby developers may be very nice people, but that doesn't make the technology any more notable or novel, and doesn't change the general tenor of the Ruby community, which seems to be driven by larger than life personalities and a general lack of solid applied computer science.
      - sanderjd 15y ago
        Though you seem completely uninterested in anything but repeating your toxic, dogmatic, and insular refrain, I may as well add my voice to the chorus of those who see a different community than the one you do. But I also want to respond to the somewhat more interesting portions of your argument - is ruby "technically interesting", "notable", "novel", and/or lacking in "solid applied computer science", and to what extent do those things matter? I think it is technically interesting because you can do much with little, notable because it combines the elegant OO of Smalltalk and the weak functional programming of Lisp with an intuitive syntax reminiscent of though dissimilar to Python, not at all novel because it prefers to embrace good ideas from its predecessors, and quite thankfully lacking in leakage of hard computer science into mundane programs. It is wrong for many jobs, but right for many others, and for that it is interesting. It is one of a multitude of languages for which the same can be said.
- deeds 15y ago
  Don't be scurrrreed
- deleted 15y ago
  [deleted]
- wtn 15y ago
  Many Mac devs who attended WWDC before the iPhone shipped say the same thing now about iOS developers…
sassafras 15y ago
I can't speak for the parent, but my take on it is that Ruby is considerably slower than Objective-C and one of the slower scripting languages in common use, IIRC. I wouldn't go out on a limb and suggest that it's unsuitable for iOS development without having a chance to see it myself, but it's something to keep in mind. As I'm sure you've seen, even Objective-C is too slow for many things when developing for iOS - for instance, if you want to get halfway decent UITableView performance it's best to write a custom UIView where instead of laying out nested subviews, you drop into C and do all your layout in drawRect using only CoreGraphics API calls. If you're attempting to do anything more complicated than hooking together pre-fab components, your performance is probably going to suck if your views are written in Ruby. And it's the silky smooth graphics people have come to expect that give iOS the reputation it's earned for slick UI. It doesn't mean you shouldn't necessarily use a framework like this, but you don't get all that convenience for free. I've often felt that the reason Objective-C remains in use (aside from the fact that it's kept alive by Apple) is that it sits in a really practical middle ground between the bare metal performance of C and the convenience (and tradeoffs) of "nicer" languages. As I said above, though, this is just my default reaction, and I'd love to see this stuff in action if it's truly usable for a reasonable subset of use cases.
- Me1000 15y ago
  I can only assume you didn't read up on the technology at all. RubyMotion does not use a Ruby VM, instead it's a static compilation to machine code. So any previous Ruby performance benchmarks are invalid in this instance. Also, Objective-C is not the slow bit in the example you described. There is a lot of logic overhead in laying out views in Cocoa. While it's true Objective-C (the language) may have some overhead, it's not much. And it's certainly not anything compared to laying out a complex view tree.
  - sassafras 15y ago
    It's true, I didn't read up on the tech at all. That was just my initial reaction. If it's fast, great! I'd love to see some performance benchmarks. As for Objective-C, whether the language in and of itself is the source of the slowness I was talking about is somewhat beside the point, IMHO. I'm aware that laying out views in Cocoa involves a lot of overhead, and that it's as much to do with the complexity of what's going on under the hood as anything. The fact of the matter remains though that you take a performance hit when laying out non-trivial views that need to be updated as fast as possible (e.g. when a table view scrolls by even one pixel and all the views have to be redrawn). You could probably convince me that Objective-C isn't the reason this is the case, but in any event, when you find the need to drop down into direct drawing API calls in order to get the performance you need, the "not much" overhead you're talking about can become much more noticeable. In a tight loop, a factor of 2 can make a huge difference, even though "2x slower than C" would be an enviable benchmark for many languages. Again, I'm certainly not denigrating Ruby or other languages, but to me, that aspect of iOS development is a reminder that one needs to choose tools carefully for the job at hand. Hence my hesitation at the announcement of alternative toolkits for iOS apps, the vast majority of which I have yet to see any stellar examples of. Here's hoping this will break the mold.

nupark2 15y ago

I am personally concerned that the Rubyists will flood the iOS development space, bringing their culture and introducing a dogmatic and insular environment. We already have -- and without great fanfare -- Lua, JavaScript, C# (MonoTouch), et al. This seems somehow different.

jeremymcanally 15y ago
How ridiculous. You do realize that every programming community has "dogmatic and insular" people, right? There are Cocoa people I've talked with who were, seriously, the rudest human beings I've ever had the displeasure of talking to. Douchebags are everywhere and it's sort of silly to paint an entire community with a broad brush. We're doing lots of good things, too, despite our own share of jerks.
danneu 15y ago
Rest assured that your attitude is far more insufferable and real than the "culture invasion" you're concerned about.
jenius 15y ago
Goodness - what a hateful, stereotyping, and narrow-minded comment. I'm enjoy ruby and spend a lot of time writing it, but would never pass judgement like this on anyone who uses another language. I've never interacted with anyone writing in any language that has an attitude like this - let's hope that you are an edge case...
- nupark2 15y ago
  Honestly, I'm part of the mostly-silent majority of polyglot programmers that choose the best language for the job and have grown increasingly weary of Rubyists wheel invention and focus on rock star programming and rock star rants. It's the only community that I find socially insufferable, and while an unpopular opinion here, I don't relish the notion of Rubyist culture. Culture aside, simply technologically, Ruby has nothing significant to offer as compared to the many existing languages and technology stacks, especially those pushing forward language and runtime research. The only argument for Ruby here seems to be opening the market to developers unwilling to move beyond it.
  - nupark2 15y ago
    Following up to note that: - Despite the opinion clearly being unpopular here, I stand by it: the ruby community is toxic-at-best, and totally technogically uninteresting. Individual Ruby developers may be very nice people, but that doesn't make the technology any more notable or novel, and doesn't change the general tenor of the Ruby community, which seems to be driven by larger than life personalities and a general lack of solid applied computer science.
    - sanderjd 15y ago
      Though you seem completely uninterested in anything but repeating your toxic, dogmatic, and insular refrain, I may as well add my voice to the chorus of those who see a different community than the one you do. But I also want to respond to the somewhat more interesting portions of your argument - is ruby "technically interesting", "notable", "novel", and/or lacking in "solid applied computer science", and to what extent do those things matter? I think it is technically interesting because you can do much with little, notable because it combines the elegant OO of Smalltalk and the weak functional programming of Lisp with an intuitive syntax reminiscent of though dissimilar to Python, not at all novel because it prefers to embrace good ideas from its predecessors, and quite thankfully lacking in leakage of hard computer science into mundane programs. It is wrong for many jobs, but right for many others, and for that it is interesting. It is one of a multitude of languages for which the same can be said.
deeds 15y ago
Don't be scurrrreed
deleted 15y ago
[deleted]
wtn 15y ago
Many Mac devs who attended WWDC before the iPhone shipped say the same thing now about iOS developers…

sassafras 15y ago

I can't speak for the parent, but my take on it is that Ruby is considerably slower than Objective-C and one of the slower scripting languages in common use, IIRC. I wouldn't go out on a limb and suggest that it's unsuitable for iOS development without having a chance to see it myself, but it's something to keep in mind. As I'm sure you've seen, even Objective-C is too slow for many things when developing for iOS - for instance, if you want to get halfway decent UITableView performance it's best to write a custom UIView where instead of laying out nested subviews, you drop into C and do all your layout in drawRect using only CoreGraphics API calls. If you're attempting to do anything more complicated than hooking together pre-fab components, your performance is probably going to suck if your views are written in Ruby. And it's the silky smooth graphics people have come to expect that give iOS the reputation it's earned for slick UI. It doesn't mean you shouldn't necessarily use a framework like this, but you don't get all that convenience for free. I've often felt that the reason Objective-C remains in use (aside from the fact that it's kept alive by Apple) is that it sits in a really practical middle ground between the bare metal performance of C and the convenience (and tradeoffs) of "nicer" languages. As I said above, though, this is just my default reaction, and I'd love to see this stuff in action if it's truly usable for a reasonable subset of use cases.

Me1000 15y ago
I can only assume you didn't read up on the technology at all. RubyMotion does not use a Ruby VM, instead it's a static compilation to machine code. So any previous Ruby performance benchmarks are invalid in this instance. Also, Objective-C is not the slow bit in the example you described. There is a lot of logic overhead in laying out views in Cocoa. While it's true Objective-C (the language) may have some overhead, it's not much. And it's certainly not anything compared to laying out a complex view tree.
- sassafras 15y ago
  It's true, I didn't read up on the tech at all. That was just my initial reaction. If it's fast, great! I'd love to see some performance benchmarks. As for Objective-C, whether the language in and of itself is the source of the slowness I was talking about is somewhat beside the point, IMHO. I'm aware that laying out views in Cocoa involves a lot of overhead, and that it's as much to do with the complexity of what's going on under the hood as anything. The fact of the matter remains though that you take a performance hit when laying out non-trivial views that need to be updated as fast as possible (e.g. when a table view scrolls by even one pixel and all the views have to be redrawn). You could probably convince me that Objective-C isn't the reason this is the case, but in any event, when you find the need to drop down into direct drawing API calls in order to get the performance you need, the "not much" overhead you're talking about can become much more noticeable. In a tight loop, a factor of 2 can make a huge difference, even though "2x slower than C" would be an enviable benchmark for many languages. Again, I'm certainly not denigrating Ruby or other languages, but to me, that aspect of iOS development is a reminder that one needs to choose tools carefully for the job at hand. Hence my hesitation at the announcement of alternative toolkits for iOS apps, the vast majority of which I have yet to see any stellar examples of. Here's hoping this will break the mold.