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.
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.
I think you'll find the difference between working with Cocoa APIs in Obj-C vs Ruby is that it's much easier in Ruby to turn what you've learned into a simple, boiled-down, easier to digest set of helper methods/objects/modules.
For example, in using the RubyMotion beta, after I understood the UIView animation flow, I created a helper method using "yield" to do the actual animation. If I were working in Obj-C, it would've been a lot more work to do the equivalent (and I probably would've just copy-pasted existing code around instead).
def animate(*args)
UIView.begin_animation
yield(*args)
UIView.commit_animation
end
animate(myButton, &buttonAnimateBlockFromSomewhereElse)
animate(myView, myOtherView, &genericAnimateBlockFromSomewhereElseWithTwoArgs)
animate do
# Do something locally ignoring args
end
And, yes, you can do the same thing with Obj-C and some creative casts...but it's nicer in RubyMotion! (ymmv)
But what if I want to have my animations in one object, and my elements to animate in another? Yes, you can have an Obj-C method return a block, but you're going to have to do some nasty casting if you want to be able to call those blocks with an arbitrary number of arguments. (That, or box everything up in an NSArray, which kinda sucks.)
I think I'll try and write up a demo app to explain what I mean...
He wants to be able to pass any Proc to his method, and any arguments supplied to the method are yielded onto target. A rough Objective-C equivalent would be something like this:
I would like to see the real-world code too. The frameworks in question revolve around Obj-C-isms, so to see something that completely deviates from those patterns will be interesting.
One of the weirdest, but oft repeated, "criticisms" I hear of Ruby is how much "weird punctuation" it uses. A groundless claim compared to most other languages, though, as this snippet illustrates.
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.
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 :)
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.