11 ms·

I don't see the point of this. Objective-C is not hard to learn, and with ARC, blocks, the new literals for NSArray and NSDictionary, etc, Objective-C has actua

I don't see the point of this. Objective-C is not hard to learn, and with ARC, blocks, the new literals for NSArray and NSDictionary, etc, Objective-C has actually become pleasant to write IMO. The example RubyMotion code also doesn't look very nice either. The problem with Rubyists (being one for the past 6 years I feel qualified to say this) is in general they want to use Ruby for everything. It's not always the best tool for the job.

tolmasky 15y ago
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.
- 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.
jballanc 15y ago
Objective-C's heritage as a strict superset of C means that it's great for doing high-level stuff while still keeping your hands in the low-level (necessary when performance becomes a main concern). Objective-C's heritage as a strict superset of C means that, ultimately, it's syntax is limited (why do you think all the new literal forms are prefixed with "@"). Ruby, on the other hand, excelles at constructing DSLs. I think you'll find that this strength of Ruby will make RubyMotion a compelling solution for a wide range of tasks in iOS development. That said, CocoaPod support is built in, so you really can have the best of both worlds.
chc 15y ago
I already know both languages — in fact, I've known Objective-C for 10 years and Ruby for only six — and I still see some reasons why this is interesting. Anecdote: When ARC was first released, I decided to turn it on for a small project. The very first method I wrote blew up with a memory error. The reason? I used the NSFontMatrixAttribute of NSFontDescriptor. For some reason, ARC doesn't handle it correctly. I've never had such a thing happen in Ruby. There is still a long way to go from where Objective-C is. It's moving in the right direction, but there's still a long road ahead of it. Ruby is closer to being there, though the lack of tool support (particularly autocomplete) makes it a much less compelling proposition than it would otherwise be. Also, Ruby can be considerably easier than Objective-C to read because there is a lot less line noise. Objective-C's method names read very smoothly out loud, but they can also be visually overwhelming at times and make code sort of melt together into a wall of text. It's maybe a little bit easier to read Objective-C quickly when you're being very deliberate about it, but it's much easier to skim Ruby in my experience. I probably won't be using this, and I think your criticism of Rubyists is kind of valid, but I think — for this particular project — you're dismissing it too readily.
exim 15y ago
I agree, language itself is not a problem. It is iOS API that matters (or needs to be fixed, in context of this thread). Actually, I can say the same regarding Java/Android API correlation.
coffee 15y ago
Speed is what you're missing. Not to denigrate you or your statement, and yes Objective-C is not that hard to learn, but it comes down to speed. If I've never programmed in Objective-C and if I'm experienced in Ruby my time from concept to live iPhone app can be FAR quicker by using the tools/language I'm already familiar with (regardless of which tools/language). Remove the concept of learning a new language, a new IDE, and only require that I learn a new lib to work against and I'm FAR quicker. Yes, there may be some limitations. But this is iterative development. Build something as solid and quick as possible, and give users the chance to play with it. If it works, and you need more flexibility, it's reasonable to spend the time on learning new tools/languages.
- chc 15y ago
  Compared to learning Cocoa (Touch), Objective-C is really nothing — especially since to use MacRuby you have to learn a bunch of kinda-awkward hacks they've stuck on top of Ruby to make it compatible with Objective-C (e.g. the "def foo(bar, baz:quux)" syntax and Pointers). It's a very simple language. Unless you are exceptionally bad at learning syntax, you're really not saving yourself a whole lot of time.
  - Argorak 15y ago
    def foo(bar, baz: "something") is perfectly valid ruby(1.9).
    - chc 15y ago
      Really? What on earth does it mean? The "baz: something" ought to parse as a hash literal, which isn't legal in a method declaration.
      - Argorak 15y ago
        Sorry, I really should get some sleep: i read "foo(a: b)", but wrote what you wrote and complained about it. :) You are right :).
      - 15y ago
spacemanaki 15y ago
Forgive my ignorance of iOS, but do the current Objective-C based tools deliver "An interactive shell [...] for introspection, live coding and debugging" ? If RubyMotion can actually deliver a real first-class REPL that works, that would be a pretty huge deal. Lack of a REPL is the biggest reason why I dislike mobile (Android) development.
- malyk 15y ago
  No, it doesn't, and it is the thing that I miss the most going from Ruby to Obj-C. All of the other benefits of ruby over obj-c are great, but it's the interactive shell that is the highlight of RubyMotion to me.
- jawngee 15y ago
  Yes, it's called GDB or LLDB, depending on your compiler. Not live coding though, but I don't know if that's a big deal.
  - YuriNiyazov 15y ago
    Yes, it's a big deal. Being able to live code completely changes (and dare I say, improves) one's ability to construct rather complicated structures that work because the small building blocks are live-tested. It's fantastic.
    - jawngee 15y ago
      And now I'm left wondering how Apple ships anything without a REPL. It's not a big deal* * former smalltalker
- jbrechtel 15y ago
  What are you looking for with an Android REPL? Asking because this is something I might be interested in building. Feel free to take the conversation to email (@gmail) or twitter (@jbrechtel) if you'd rather limit the off-topic discussion.
  - 15y ago
deleted 15y ago
[deleted]
heretohelp 15y ago
>problem with Rubyists...want to use Ruby for everything This is generally true of the Java community as well. There was a solid decade where there was a jSomethingOrOther for everything in development.
- Kudos 15y ago
  Now that typically means it's a jQuery plugin ;)
  - heretohelp 15y ago
    By all means, rub in further how old I am now :P
maercsrats 15y ago
In reference to your first paragraph, that's all your opinion. You are completely entitled to it and I respect it. My opinion is that this looks awesome and I really want to try it out. Especially since I know Ruby (and C) but I don't know any Obj-C. As for your second paragraph, you can say that about any '-ists'. I've met java, python and .Net people who all love their respective languages and just want to code in that. To me, Rubyists aren't better or worse in that respect.
- 38leinad 15y ago
  totally agree with you. just for your statement "I really want to try it out. Especially since I know Ruby (and C) but I don't know any Obj-C.": Would be interesting to really know what is the steeper/longer part of the learning curve: learning ObjC or learning the frameworks. To me, ObjC is a lean language (with an awful bracket syntax just like lisp) but learning the ins and outs of the frameworks is what took me the most time.
  - manmal 15y ago
    Yep - In times when ARC was not invented, memory management took some time to get used to (what with object ownership and such), but you can strike this from the list now. Another thing is that one has to get used to the ObjC way of doing stuff. E.g., Devs who are used to Java will make subclasses instead of categories, add comments instead of expressive method names, and make nil checks where they are not necessary. Or ask where all those open-source projects' unit tests have gone :)
- randomdata 15y ago
  Especially since I know Ruby (and C) but I don't know any Obj-C. Interestingly, from my point of view, Obj-C made perfect sense to me when I realized that it was basically Ruby with C syntax. Given the heritage of Ruby and Obj-C, they come out as very similar languages, so I found it a breeze to pick up the other. The hard part was learning the Cocoa (Touch) frameworks, but I'm not sure a Ruby API would have made that any easier. It's simply a massive amount of information to take in all at once.
Smudge 15y ago
> Objective-C has actually become pleasant to write IMO. Yeah, well, you know, that's just, like, your opinion, man.
- Flow 15y ago
  Haven't you heard? New shit has come to light man.
thibaut_barrere 15y ago
I use Ruby since 2004 (but not exclusively). I've been using Ruby to create pleasant to use APIs around more complicated (native) APIs in both Java and .Net and it has always been a very big win in my situations. I just bought a RubyMotion license and can see it going very far :)
phillmv 15y ago
> Rubyists in general want to use Ruby for everything. Well… why not? This is a relatively objective statement; the problem with ruby tends to be the crappy interpreter we're forced to suffer through - not the language itself. The Ruby language, in my biased opinion, as far as OO-functional languages go is pure awesome. My initial reaction was: "A Ruby to Obj-C ABI compiler? Fuck no, what is wrong with you." Upon learning it was the MacRuby dude: "Holy shit fuck yes". I really don't want to ditch my entire development workflow to pick up Xcode, and Objective C, and miss out on all of the development libraries and vibrant community that I already have access to. The problem with company led development environments is that they're tailored to the vendor's, and not the community's, needs. Development is rigid and low on innovation. If this framework is half as good as it seems to be, within a month we'll see a dozen libraries that abstract all sorts of pain away from iOS development. Abstracting the pain away is something the Ruby community tends to do well. I've gone from being totally uninterested in iOS development to being excited in what I can do inside UIWebviews. Naive, maybe, but it's probably significantly lowered the amount of investment I have to make into creating an iOS app.
- deeds 15y ago
  > Upon learning it was the MacRuby dude: "Holy shit fuck yes". Couldn't have said it better myself.
- 55pts 15y ago
  I like ruby but please, do not call it a functional language. Its not even remotely close.
  - bigfudge 15y ago
    Why not? Sure, neither ruby nor python emphasise immutability, and recursion isn't optimised, but both lend themselves to a functional style if you're so inclined. See http://stackoverflow.com/questions/159797/is-ruby-a-functional-language http://stackoverflow.com/questions/159797/is-ruby-a-function...
    - Lio 15y ago
bphogan 15y ago
In much the same way as JavaScript developers want to do everything in JavaScript, including write mobile apps (PhoneGap/Titanium) and server-side apps (Node.js). Learning is hard, and doubly so when you're in your comfort zone. You can deride that and make it about a person's "toughness" as a programmer, or you can think about exactly how much time it takes to learn a language and its idioms, highlights, lowlights, problems, and features. A person who's really good at C# or Java is not going to be really good at Obj-C without losing a significant amount of time. That's why these kinds of projects appear. There's only so much time in the day to learn a new language well. :)
aiscott 15y ago
For me, the REPL is the key that makes this interesting. I don't really know much ruby, but I would consider picking it up again just for the interactivity you get with a REPL tied to the app running in the simulator. This is a step in the right direction, a step toward getting immediate and interactive results when you code. The piece that I find a tiny bit lacking is disconnect between what you futz with in the REPL and what is your source. By that I mean, all the manual tinkering in the REPL isn't saved anywhere, you have to copy and paste. Emacs rectifies this sort of thing a little with swank and slime. Maybe there will be a mode for RubyMotion.
tubbo 15y ago
Objective-C sucks as a language. It's just awful to look at, isn't really that much more efficient than C++ or even C itself, and realistically the only reason we use it in the first place is because it's the language of iOS. Sure, it's not hard to learn. But in my spare time, am I really going to work with a language I can't stand to make my iPhone app or am I just going to want to make a web app in Ruby? The latter sounds a lot more fun, but the former is obviously more efficient. The fact that we can now combine both? Holy shit.
fleitz 15y ago
It might not be the best but it's good enough. Most of the heavy lifting GUI code is still in Obj-C, it's just going to be hitting ruby for microseconds. Sure if you're writing the unreal engine it's not going to be the best idea, but it should do fine for a Facebook/Three20 type app.
seclorum 15y ago
The point is that compared to Ruby, Objective-C is just aging, bloated, and incomprehensibly loaded with special traps designed to keep you wedded to the platform. Ruby skills: applicable across a very broad range of computing devices. Objective-C: not so much.
edwardtrunk 15y ago
a big different is, now the ruby eco-system is in play. the ability to write DSLs to further enhance the development effort.

tolmasky 15y ago

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.
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.

jballanc 15y ago

Objective-C's heritage as a strict superset of C means that it's great for doing high-level stuff while still keeping your hands in the low-level (necessary when performance becomes a main concern). Objective-C's heritage as a strict superset of C means that, ultimately, it's syntax is limited (why do you think all the new literal forms are prefixed with "@"). Ruby, on the other hand, excelles at constructing DSLs. I think you'll find that this strength of Ruby will make RubyMotion a compelling solution for a wide range of tasks in iOS development. That said, CocoaPod support is built in, so you really can have the best of both worlds.

chc 15y ago

I already know both languages — in fact, I've known Objective-C for 10 years and Ruby for only six — and I still see some reasons why this is interesting. Anecdote: When ARC was first released, I decided to turn it on for a small project. The very first method I wrote blew up with a memory error. The reason? I used the NSFontMatrixAttribute of NSFontDescriptor. For some reason, ARC doesn't handle it correctly. I've never had such a thing happen in Ruby. There is still a long way to go from where Objective-C is. It's moving in the right direction, but there's still a long road ahead of it. Ruby is closer to being there, though the lack of tool support (particularly autocomplete) makes it a much less compelling proposition than it would otherwise be. Also, Ruby can be considerably easier than Objective-C to read because there is a lot less line noise. Objective-C's method names read very smoothly out loud, but they can also be visually overwhelming at times and make code sort of melt together into a wall of text. It's maybe a little bit easier to read Objective-C quickly when you're being very deliberate about it, but it's much easier to skim Ruby in my experience. I probably won't be using this, and I think your criticism of Rubyists is kind of valid, but I think — for this particular project — you're dismissing it too readily.

exim 15y ago

I agree, language itself is not a problem. It is iOS API that matters (or needs to be fixed, in context of this thread). Actually, I can say the same regarding Java/Android API correlation.

coffee 15y ago

Speed is what you're missing. Not to denigrate you or your statement, and yes Objective-C is not that hard to learn, but it comes down to speed. If I've never programmed in Objective-C and if I'm experienced in Ruby my time from concept to live iPhone app can be FAR quicker by using the tools/language I'm already familiar with (regardless of which tools/language). Remove the concept of learning a new language, a new IDE, and only require that I learn a new lib to work against and I'm FAR quicker. Yes, there may be some limitations. But this is iterative development. Build something as solid and quick as possible, and give users the chance to play with it. If it works, and you need more flexibility, it's reasonable to spend the time on learning new tools/languages.

chc 15y ago
Compared to learning Cocoa (Touch), Objective-C is really nothing — especially since to use MacRuby you have to learn a bunch of kinda-awkward hacks they've stuck on top of Ruby to make it compatible with Objective-C (e.g. the "def foo(bar, baz:quux)" syntax and Pointers). It's a very simple language. Unless you are exceptionally bad at learning syntax, you're really not saving yourself a whole lot of time.
- Argorak 15y ago
  def foo(bar, baz: "something") is perfectly valid ruby(1.9).
  - chc 15y ago
    Really? What on earth does it mean? The "baz: something" ought to parse as a hash literal, which isn't legal in a method declaration.
    - Argorak 15y ago
      Sorry, I really should get some sleep: i read "foo(a: b)", but wrote what you wrote and complained about it. :) You are right :).
    - 15y ago

spacemanaki 15y ago

Forgive my ignorance of iOS, but do the current Objective-C based tools deliver "An interactive shell [...] for introspection, live coding and debugging" ? If RubyMotion can actually deliver a real first-class REPL that works, that would be a pretty huge deal. Lack of a REPL is the biggest reason why I dislike mobile (Android) development.

malyk 15y ago
No, it doesn't, and it is the thing that I miss the most going from Ruby to Obj-C. All of the other benefits of ruby over obj-c are great, but it's the interactive shell that is the highlight of RubyMotion to me.
jawngee 15y ago
Yes, it's called GDB or LLDB, depending on your compiler. Not live coding though, but I don't know if that's a big deal.
- YuriNiyazov 15y ago
  Yes, it's a big deal. Being able to live code completely changes (and dare I say, improves) one's ability to construct rather complicated structures that work because the small building blocks are live-tested. It's fantastic.
  - jawngee 15y ago
    And now I'm left wondering how Apple ships anything without a REPL. It's not a big deal* * former smalltalker
jbrechtel 15y ago
What are you looking for with an Android REPL? Asking because this is something I might be interested in building. Feel free to take the conversation to email (@gmail) or twitter (@jbrechtel) if you'd rather limit the off-topic discussion.
- 15y ago

deleted 15y ago

[deleted]

heretohelp 15y ago

>problem with Rubyists...want to use Ruby for everything This is generally true of the Java community as well. There was a solid decade where there was a jSomethingOrOther for everything in development.

Kudos 15y ago
Now that typically means it's a jQuery plugin ;)
- heretohelp 15y ago
  By all means, rub in further how old I am now :P

maercsrats 15y ago

In reference to your first paragraph, that's all your opinion. You are completely entitled to it and I respect it. My opinion is that this looks awesome and I really want to try it out. Especially since I know Ruby (and C) but I don't know any Obj-C. As for your second paragraph, you can say that about any '-ists'. I've met java, python and .Net people who all love their respective languages and just want to code in that. To me, Rubyists aren't better or worse in that respect.

38leinad 15y ago
totally agree with you. just for your statement "I really want to try it out. Especially since I know Ruby (and C) but I don't know any Obj-C.": Would be interesting to really know what is the steeper/longer part of the learning curve: learning ObjC or learning the frameworks. To me, ObjC is a lean language (with an awful bracket syntax just like lisp) but learning the ins and outs of the frameworks is what took me the most time.
- manmal 15y ago
  Yep - In times when ARC was not invented, memory management took some time to get used to (what with object ownership and such), but you can strike this from the list now. Another thing is that one has to get used to the ObjC way of doing stuff. E.g., Devs who are used to Java will make subclasses instead of categories, add comments instead of expressive method names, and make nil checks where they are not necessary. Or ask where all those open-source projects' unit tests have gone :)
randomdata 15y ago
Especially since I know Ruby (and C) but I don't know any Obj-C. Interestingly, from my point of view, Obj-C made perfect sense to me when I realized that it was basically Ruby with C syntax. Given the heritage of Ruby and Obj-C, they come out as very similar languages, so I found it a breeze to pick up the other. The hard part was learning the Cocoa (Touch) frameworks, but I'm not sure a Ruby API would have made that any easier. It's simply a massive amount of information to take in all at once.

Smudge 15y ago

> Objective-C has actually become pleasant to write IMO. Yeah, well, you know, that's just, like, your opinion, man.

Flow 15y ago
Haven't you heard? New shit has come to light man.

thibaut_barrere 15y ago

I use Ruby since 2004 (but not exclusively). I've been using Ruby to create pleasant to use APIs around more complicated (native) APIs in both Java and .Net and it has always been a very big win in my situations. I just bought a RubyMotion license and can see it going very far :)

phillmv 15y ago

> Rubyists in general want to use Ruby for everything. Well… why not? This is a relatively objective statement; the problem with ruby tends to be the crappy interpreter we're forced to suffer through - not the language itself. The Ruby language, in my biased opinion, as far as OO-functional languages go is pure awesome. My initial reaction was: "A Ruby to Obj-C ABI compiler? Fuck no, what is wrong with you." Upon learning it was the MacRuby dude: "Holy shit fuck yes". I really don't want to ditch my entire development workflow to pick up Xcode, and Objective C, and miss out on all of the development libraries and vibrant community that I already have access to. The problem with company led development environments is that they're tailored to the vendor's, and not the community's, needs. Development is rigid and low on innovation. If this framework is half as good as it seems to be, within a month we'll see a dozen libraries that abstract all sorts of pain away from iOS development. Abstracting the pain away is something the Ruby community tends to do well. I've gone from being totally uninterested in iOS development to being excited in what I can do inside UIWebviews. Naive, maybe, but it's probably significantly lowered the amount of investment I have to make into creating an iOS app.

deeds 15y ago
> Upon learning it was the MacRuby dude: "Holy shit fuck yes". Couldn't have said it better myself.
55pts 15y ago
I like ruby but please, do not call it a functional language. Its not even remotely close.
- bigfudge 15y ago
  Why not? Sure, neither ruby nor python emphasise immutability, and recursion isn't optimised, but both lend themselves to a functional style if you're so inclined. See http://stackoverflow.com/questions/159797/is-ruby-a-functional-language http://stackoverflow.com/questions/159797/is-ruby-a-function...
  - Lio 15y ago

bphogan 15y ago

In much the same way as JavaScript developers want to do everything in JavaScript, including write mobile apps (PhoneGap/Titanium) and server-side apps (Node.js). Learning is hard, and doubly so when you're in your comfort zone. You can deride that and make it about a person's "toughness" as a programmer, or you can think about exactly how much time it takes to learn a language and its idioms, highlights, lowlights, problems, and features. A person who's really good at C# or Java is not going to be really good at Obj-C without losing a significant amount of time. That's why these kinds of projects appear. There's only so much time in the day to learn a new language well. :)

aiscott 15y ago

For me, the REPL is the key that makes this interesting. I don't really know much ruby, but I would consider picking it up again just for the interactivity you get with a REPL tied to the app running in the simulator. This is a step in the right direction, a step toward getting immediate and interactive results when you code. The piece that I find a tiny bit lacking is disconnect between what you futz with in the REPL and what is your source. By that I mean, all the manual tinkering in the REPL isn't saved anywhere, you have to copy and paste. Emacs rectifies this sort of thing a little with swank and slime. Maybe there will be a mode for RubyMotion.

tubbo 15y ago

Objective-C sucks as a language. It's just awful to look at, isn't really that much more efficient than C++ or even C itself, and realistically the only reason we use it in the first place is because it's the language of iOS. Sure, it's not hard to learn. But in my spare time, am I really going to work with a language I can't stand to make my iPhone app or am I just going to want to make a web app in Ruby? The latter sounds a lot more fun, but the former is obviously more efficient. The fact that we can now combine both? Holy shit.

fleitz 15y ago

It might not be the best but it's good enough. Most of the heavy lifting GUI code is still in Obj-C, it's just going to be hitting ruby for microseconds. Sure if you're writing the unreal engine it's not going to be the best idea, but it should do fine for a Facebook/Three20 type app.

seclorum 15y ago

The point is that compared to Ruby, Objective-C is just aging, bloated, and incomprehensibly loaded with special traps designed to keep you wedded to the platform. Ruby skills: applicable across a very broad range of computing devices. Objective-C: not so much.

edwardtrunk 15y ago

a big different is, now the ruby eco-system is in play. the ability to write DSLs to further enhance the development effort.