RubyMotion - Ruby for iOS • Hacker News Board

Re: RubyMotion - Ruby for iOS

#171

Post by chc » Fri, May 04, 2012, 2:26 AM UTC

grey-area wrote: post #158

chc wrote: post #145

Earlier quoted context omitted.

> No hostility :) > You're just on the defensive, so it feels like hostility. It's understandable... Really, no. I don't know if it's intentional or not, but you come across as very passive-aggressive and condescending. I don't even know what it is I'm supposed to be "on the defensive" about — the fact that learning Objective-C takes much less time than learning Cocoa? I feel pretty secure in that knowledge. > But I…

Apparently the disconnect here comes because you think of a language as trivial (as compared to an API), however it's often hard to separate the language (syntax, and its built in methods), and the libraries which make up an API/standard library. In addition to the cost of learning a library/language, there is also a day to day cost in using it - a certain friction which encourages you to take some paths and not othe…

I don't understand how this relates to anything I've said. How is this meant to show that the time it would take to learn Objective-C while you're learning Cocoa is prohibitive?

Actually, I think your code examples support my point. You're not contrasting Ruby and Objective-C, you're contrasting Ruby's standard library with the Objective-C library Foundation, which is what you need to learn to get any real use out of MacRuby/RubyMotion. Here's the MacRuby/Cocoa version of that code:

  error = Pointer.new_with_type '@'
  regex = NSRegularExpression.regularExpressionWithPattern("foobar(\\d*\\w)", options: NSRegularExpressionCaseInsensitive error: error)
  match = regex.firstMatchInString(string, options: 0, range: NSMakeRange(0, string.length))
  NSLog "The limits of my language define the limits of my world - Wittgenstein" if match

Do you really feel that Objective-C is the biggest difference between the three examples?

BTW, if it sounds like I'm trying to say RubyMotion is pointless, I'm not. I'm just saying that "I don't want to go to the trouble of learning Objective-C" is a weak reason to use RubyMotion, because you'll have to do 99.95% of the same work anyway.

Re: RubyMotion - Ruby for iOS

#172

Post by cmelbye » Fri, May 04, 2012, 2:44 AM UTC

elsurudo wrote: post #74

cschneid wrote: post #72

Earlier quoted context omitted.

Different compilers will generate different compiled code, even on identical input (ie, clang vs. GCC). So the binary will be different.

I think he's commenting on why they wouldn't LOOK identical, as in UI. UI is a finicky thing, but assuming this allows you to use all Apple APIs, there is no reason you couldn't get an identical-looking UI using this.

I'm fairly sure that section is talking about compiled code, structure of the app, the archive, etc, considering it says "compiled ahead-of-time, never interpreted, and you access the entire set of iOS public APIs." the previous paragraph.

You're right though, there's no reason the UI wouldn't look identical as well.

Re: RubyMotion - Ruby for iOS

#173

Post by dmarkow » Fri, May 04, 2012, 2:56 AM UTC

hemancuso wrote: post #113

Anyone know if this comes with the ruby stdlib?

It doesn't look like it. You need to use the iOS alternatives (in this case, NSDate).

  (main)>> require 'date'
  => #
  (main)>> Date
  => #

Re: RubyMotion - Ruby for iOS

#174

Post by randomdata » Fri, May 04, 2012, 3:21 AM UTC

jawngee wrote: post #135

jballanc wrote: post #132

Earlier quoted context omitted.

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

Yes please do because you are making absolutely no sense whatsoever. I think you are over thinking things.

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:

    void animate(void (^block)(va_list), ...)
    {
        va_list args;
        va_start(args, block);
        block(args);
        va_end(args);
    }

    void (^first)(va_list) = ^(va_list args) {
        NSLog(@"%@", va_arg(args, id));
    };

    void (^second)(va_list) = ^(va_list args) {
        NSLog(@"%@", va_arg(args, id));
        NSLog(@"%@", va_arg(args, id));
    };

    animate(first, @"Hello World");
    animate(second, @"Hello", [[NSNumber alloc] initWithInt:10]);

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.

Re: RubyMotion - Ruby for iOS

#175

Post by davesims » Fri, May 04, 2012, 3:24 AM UTC

nupark2 wrote: post #98

jenius wrote: post #90

Earlier quoted context omitted.

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

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 h…

"polyglot programmers that choose the best language for the job"

You just described the majority of Ruby coders I've ever worked with. (mentally scrolls work history roster of Ruby devs...)

Yeah, in fact you've just described all of them.

I'm sorry your sampling of Ruby coders has been so poor, and I'm sure you could present examples to defend your prejudice. I know the stereotype you're talking about. I haven't worked with one of them, but I know they're out there.

Nevertheless, it seems to me you've become the thing you claim to despise: insular and closed off to experiences that would contradict your dogmas.

Re: RubyMotion - Ruby for iOS

#176

Post by christiangenco » Fri, May 04, 2012, 3:40 AM UTC

I love this. It looks like exactly what I've been looking for since the iPhone SDK was first announced. I've been a web/RoR developer since high school but could never find the motivation to get used to all of Objective C/XCode's quirks. I've tried everything from PhoneGap to Appcelerator to mimicking native feel in a browser, but it was never enough. This is perfect.

But quite frankly, I can't afford it. I'm a college student living on $25/week for food - I can't justify spending 6 weeks of food on an experiment.

If I could try it out? If I could build my killer app first and know that it works? It wouldn't hurt as much, but $150 is still a lot of money.

Re: RubyMotion - Ruby for iOS

#177

Post by sassafras » Fri, May 04, 2012, 3:58 AM UTC

Me1000 wrote: post #169

sassafras wrote: post #164

Earlier quoted context omitted.

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 - f…

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

Re: RubyMotion - Ruby for iOS

#178

Post by sanderjd » Fri, May 04, 2012, 4:19 AM UTC

nupark2 wrote: post #133

nupark2 wrote: post #98

Earlier quoted context omitted.

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 h…

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…

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.

Re: RubyMotion - Ruby for iOS

#179

Post by smparkes » Fri, May 04, 2012, 4:29 AM UTC

chc wrote: post #152

webjprgm wrote: post #63

Earlier quoted context omitted.

I still wonder how they did that. The classic problem with reference counting is correctly releasing cycles, which ARC handles by allowing "weak" references. How does MacRuby know when to insert a weak reference as opposed to the usual "strong" reference? If that could be automatically detected, why does Obj-C ARC not automatically do it for you?

"Object cycles, when two or more objects refer to each other, are currently not handled by the runtime, but will be in future releases." So, basically, you're stuck with retain cycles right now. My bet is that they implement a way of marking weak references rather than becoming more intelligent than ARC.

I wonder how big a deal this will be. Relying on GC feels like it goes hand in hand with dynamic languages. I'm used to not having to worry about cycles.

Of course, I guess I'm use to not having to worry too much about memory, either ...

Weak references aren't a panacea. It's not that uncommon to have cycles where all edges are equally strong. Any social graph ...

I use use counts to collect those cycles. ARC doesn't let you use use counts, but you don't have to use ARC everywhere. You do have to access to the underlying use counts ... MacRuby should allow access to that (it's just a standard Cocoa call) as long as it doesn't keep stray retains around that screw up my count balances ...

Re: RubyMotion - Ruby for iOS

#180

Post by kcbanner » Fri, May 04, 2012, 4:34 AM UTC

robomartin wrote: post #116

aiscott wrote: post #112

Earlier quoted context omitted.

I said this in another reply, but I'll reiterate here. It's not the lack of Objective-C that is the big deal here. Afterall you are still interfacing with cocoa, and are stuck with a lot of the verbosity in doing that. The real key to this is the REPL and interactivity between coding and the running app. Being able to edit bits of functionality and structure in the running app, and immediately see the results is AWES…

I don't know Ruby. Therefore, by my own admission, this comes out of complete ignorance. I am currently working on a project that uses a genetic solver and some fairly complex state machines driven by fairly involved databases. I can't possibly see how something like this could be made to be interactive in terms of the development process. Generally speaking you are writing a lot of code before you get to compile and…

Your application is something that doesn't lend itself to the problem that this solves. With UI related things, it is often very helpful to be able to tweak UI elements while the program runs, instead of the tweak, compile, run cyle.