RubyCocoa: good idea to program 100% in ruby?

Discussion in 'Mac Programming' started by jstad, Oct 15, 2007.

  1. jstad macrumors regular

    jstad

    Joined:
    Jun 13, 2007
    #1
    I was curious if it was a good idea or not to program an entire program (lets say bank software) in RubyCocoa. I have had this debate for awhile with some of my fellow Comp Sci majors at my university. The part we are worried about is the overhead and memory management of Ruby. I know that with the next version of Ruby that it is going to get a speed increase but will that really matter? Also since ruby began and still somewhat is a scripting language, wouldnt it be a bad idea to use it as the base for a program?

    The reason we are not doing Objective-C is because we want to use the Cocoa framework on OSX but we want to use other GUI frameworks depending on the platform. We considered Java briefly but since Apple took it out of its update cycle for Cocoa, it was quickly abandoned.

    If not RubyCocoa, what would you use? (Trying to avoid Obj-C for minimal re-write per platform)
     
  2. kainjow Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #2
    If you are going to use Ruby, wait for Leopard.
     
  3. garethlewis2 macrumors 6502

    Joined:
    Dec 6, 2006
    #3
    The same rubbish argument about overhead and garbage was bandied about in the 80s with NextSTEP using Objective-C instead of C++.

    If you are writing a program with Cocoa, 90% of your computing time is going to be waiting for user input.
     
  4. HiRez macrumors 603

    HiRez

    Joined:
    Jan 6, 2004
    Location:
    Western US
    #4
    Nothing wrong with Ruby, like many former "scripting" languages, it is now a real programming language. But a few reasons why you might not want to go this route:

    1. I don't trust Apple to support Ruby in the future (see what happened to the Java bridge). This doesn't mean you can't use it, but some things you come to rely on could get complicated later.

    2. If you need to be cross-platform, you'll be losing a lot of what makes Cocoa great, such as Bindings, Core Data, and newer things like Core Animation. Sure, you could use these things on the Mac and write other solutions for other platforms, but your code could get messy.

    You might look into an all-web solution like RoR/Ajax, or Adobe Apollo/Flex. If your application fits it, you can do some pretty nice, dynamic interfaces with these nowadays and not have to deal with cross-platform headaches. Apollo will also let you deploy as a cross-platform, double-clickable desktop application.
     
  5. jstad thread starter macrumors regular

    jstad

    Joined:
    Jun 13, 2007
    #5
    I dont know if you can answer this or not, but what makes a language a scripting language or a "full-fledged" language? This is more of a techincal question than a general "scripting languages are used for quick development" stuff.
     
  6. HiRez macrumors 603

    HiRez

    Joined:
    Jan 6, 2004
    Location:
    Western US
    #6
    I can't say what the technically correct answer would be, but I would think things like advanced loop and iteration handling, direct byte access to binary data, objects, encapsulation, exceptions, extensive support for various common heterogenous collection classes (array, hashtable, set, tree) with a unified API, and good debugging capabilities, would all be factors. In fact, that actually makes C, which some would consider the mother of all modern "real" programming languages, seem rather feeble by comparison. I guess it depends on how you feel about garbage collection, as it might be a big positive for some folks and a big negative for others.

    Certainly each language has their specialty. C is fast and efficient. Ruby and Python are better at handling strings and collections natively. And much of what we think of when we think of a language is what APIs are available for it, although they're often separate. You can program in Objective-C without Cocoa, but very few people do nowadays. Personally I consider any language that you can use to program a complex, modern application to be a "real" programming language (that could be web-based or desktop-based). In that sense, I suppose there are very few "scripting" languages left. Ruby, Python, Perl, PHP, and others have all added features over the years to fill most of the holes they might have initially had. You can even program a complex application in AppleScript, although that one is still a unique oddball (alternatingly frustrating and wonderful for me).

    Anyway, that's one of the things I like about programming on the Mac in Xcode. I can take bits and pieces from a dozen different languages and APIs and rather easily use them all in the same application, if I have to.
     
  7. garethlewis2 macrumors 6502

    Joined:
    Dec 6, 2006
    #7
    This is another question that gets asked a lot and the answer is completely obvious, but so obvious that the thinker decides to ignore it.

    Scripting languages are full-fledged languages. They can do anything that a language like C, C++ or Objective-C can do. The biggest difference being the latter are interpreted and the former are compiled.

    What the question should be is. What makes language X more suitable for a problem domain than language Y. Would you attempt to write an OS in Ruby? Of course not. Where would the runtime that executes the interpreter be run?
     
  8. janey macrumors 603

    janey

    Joined:
    Dec 20, 2002
    Location:
    sunny los angeles
    #8
  9. garethlewis2 macrumors 6502

    Joined:
    Dec 6, 2006
    #9
    There's a language that is going to die horribly. 99% of the MacRumors developers will get excited. Download Nu. Realise they are horrendously underdeveloped in the academic programming area, and go back to <<insert language here>>
     
  10. WildPalms macrumors 6502a

    WildPalms

    Joined:
    Jan 4, 2006
    Location:
    Honolulu, HI
    #10
    Why wait for Leopard?
     
  11. kainjow Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #11
    Ruby will have an official bridge to Cocoa in Leopard.

    From Apple's website:
     
  12. WildPalms macrumors 6502a

    WildPalms

    Joined:
    Jan 4, 2006
    Location:
    Honolulu, HI
    #12
    Ahhhh. Gotcha. :)
     
  13. hhas macrumors regular

    Joined:
    Oct 15, 2007
    #13
    The "official" Ruby-Cocoa bridge is RubyCocoa. All Apple have done is get behind an existing OSS project, provide some assistance with developing and polishing it, and bundle a recent copy with Leopard. Ditto with PyObjC for Python.

    It's great that Apple are giving their official blessing to these projects, but let's not get carried away by Apple marketing pitch. The only direct technical benefit for developers is that they'll now have the extra option of using Leopard's bundled Ruby and RubyCocoa to produce more compact standalone applications, whereas previously they had no other choice than to include these dependencies in their application bundles, increasing distribution size by several MB.

    Developers who wish to use the latest and greatest Ruby/RubyCocoa releases, or who require their applications to be portable between OS versions, will no doubt continue to use the latter approach regardless, and an extra few MB of download is pretty much a non-issue for broadband users (and usually tolerable for dialup users) anyway.


    Either way, there's no reason why the OP shouldn't start using RubyCocoa today if they wish. That said, they may wish to consider other options as well; e.g. personally I prefer Python + PyObjC, which is a bit faster and more mature than Ruby + RubyCocoa, although the latter is catching up.

    If they really want to minimise per-platform rewrites, they may be better off using a cross-platform application framework such as wxWidgets (which has bindings for several languages), or Java (which is still fully supported by Apple; all they've done is drop support for their slightly dodgy, Mac-only Java-Cocoa bindings but that doesn't stop you using existing cross-platform Java application frameworks). The only tradeoff is that cross-platform framework may not give quite the same level of Mac look-n-feel, but depending on the type of application and audience this may be entirely acceptable.

    Also, w.r.t. speed concerns, don't forget that PyObjC and (IIRC) RubyCocoa are full two-way bridges while Python and Ruby both provide extensive C APIs as well, allowing you to write your initial version completely in Python/Ruby, then performance profile it and recode any performance-intensive portions using C or ObjC once you're happy with the overall design.

    HTH
     
  14. kainjow Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #14
    Cool, thanks for sharing. I didn't know this, although I kind of figured it was the case. I guess it's ok then to start with RubyCocoa since it's the same thing.

    This was my reason for waiting for Leopard, because the apps wouldn't be so bloated with the RubyCocoa libraries.
     
  15. ChrisA macrumors G4

    Joined:
    Jan 5, 2006
    Location:
    Redondo Beach, California
    #15
    If this is an interactive 'point and click" type desktop application the single most slow bottle neck is the user. He can only cause events to occur at a relativly low rate. As long as you can keep up with the mouse and keyboard why go faster?

    You can also argue that a Porshe is fater then my old pickup truck. But you know what? I don't get home from work faster in the Porshe. The car's top end speed is not what is determining my travel time. Same here. Nothing happens until the user clicks "OK" so what would a faster program do? Only spend more time in a idle loop sleeping. Once your software can "keep up with traffic" it does not need to go faster.

    OK there are exceptions, some user interface stuff is computationaly expensive. "Cover Flow" comes to mind. but banking is mostly not that.

    But on the other hand If that software ran at the bank you'd care a bit more about performance as it would be doing more then just waiting for the user to do something.

    Most of what happens on the desktop is just waiting for input from the user.
     
  16. hhas macrumors regular

    Joined:
    Oct 15, 2007
    #16
    FWIW, including Python and PyObjC in a 32-bit UB application adds approx 4MB to the .dmg size (e.g. 4.5MB vs 0.5MB), and I imagine the numbers are similar for a Ruby-based application. Whether or not this is a issue will depend on the type of project, audience and/or distribution method. e.g. I've written several standalone PyObjC-based utilities for Python/Ruby/AppleScript users and not had any complaints so far. OTOH, if just it's a ten-line script that folk'll run once and throw away, or a popular application that gets a million downloads and you're paying all your own hosting bills, distribution size may be more of an issue.

    HTH
     
  17. Alloye macrumors 6502a

    Joined:
    Apr 11, 2007
    Location:
    Rocklin, CA
    #17
    RubyCocoa has come a long way in recent months. In addition to minimizing the semantic differences between Ruby and Objective-C, they've also greatly reduced the performance penalty for crossing the bridge. My advice would be to do a little prototyping with it and see how you feel about the results.
     
  18. Alloye macrumors 6502a

    Joined:
    Apr 11, 2007
    Location:
    Rocklin, CA
    #18
    Been there, done that. ;)
     

Share This Page