Is Cocoa/ObjC really worth it?

Discussion in 'Mac Programming' started by chelsel, Jan 7, 2008.

  1. chelsel macrumors 6502

    Joined:
    May 24, 2007
    #1
    Coming from a Java, and prior to that C background I find learning Objective-C quite easy. However, it feels like I've gone back in time 10 years. I mean, header files... and this retain, release concept is a pain once you're used to a good garbage collector (Java).

    Is programming in Cocoa/Objective-C worth it for applications, what can't you do in Java for example?
     
  2. jsw Moderator emeritus

    jsw

    Joined:
    Mar 16, 2004
    Location:
    Andover, MA
    #2
    I agree that the language is a step backwards. But Leopard brought it a few years forward, and Xcode 3.0 is also now pretty competitive with where eclipse was 2-3 years ago. ;)

    However, Java can't access all the cool new Leopard frameworks, so, if you're writing apps for Macs, you more or less need to learn Cocoa/Objective-C. The frameworks do so much for you that you'd be foolish to use Java unless you were going for cross-platform.
     
  3. HiRez macrumors 603

    HiRez

    Joined:
    Jan 6, 2004
    Location:
    Western US
    #3
    Well, with Leopard it now has garbage collection and while I agree that header files seem inconvenient, it's a small price to pay. I used to code in Java and after using Objective-C, I'll never go back. In hindsight Java seems so primitive and frustrating to me now. Objective-C is much more dynamic.

    It's not just Java vs. Objective-C, it's also the Java APIs vs. the Cocoa APIs. Java's are more complete in some aspects, but Cocoa offers a lot as well, such as very rich multimedia using QuickTime. The Cocoa APIs are also better-designed at the core, IMO. Javas have many layers of cruft and many inconsistencies.

    Finally, Cocoa simply blows away Java when it comes to rich, high-performance user interfaces, assuming you can limit yourself to running on a Mac that is. Interface Builder is a great tool and Java doesn't have anything like Nibs to my knowledge.

    Java is not terrible but it would be painful to go back.
     
  4. ppc_michael Guest

    ppc_michael

    Joined:
    Apr 26, 2005
    Location:
    Los Angeles, CA
    #4
    I'm a huge fan of ObjC + Cocoa. I actually like the header files: you have more control and it gives you more of an understanding of exactly what's going on.

    Plus I just think it looks really cool with all the square brackets and such.

    But that's just me.
     
  5. jhande macrumors 6502

    Joined:
    Sep 20, 2006
    Location:
    Denmark
    #5
    Maybe it's just my age showing, but I enjoy header files as well (regardless of whether it's ObjC or plain C). Whenever I have to work with something I haven't developed, I make a cup of coffee, sit down, and read/browse through the relevant header files. After a while I have a pretty good model in my head of the different interfaces and probable methods involved. After that I can go look at the code.

    Works for me, and only needs command-line access.
     
  6. kainjow Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #6
    IMHO Java is only useful for cross platform if you're targeting desktop applications. Anything Mac specific, unless you're trying to whip up something quickly, should be Cocoa.

    Someone mentioned it being a step backwards... well according to Wikipedia Objective-C is 9 years older than Java, so duh :p ;)
     
  7. Catfish_Man macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #7
    Lack of header files drives me up the wall in Java code. GC is nice though.
     
  8. chelsel thread starter macrumors 6502

    Joined:
    May 24, 2007
    #8
    I guess I don't really see the point of header files... they don't contain source... they separate instance variables from the source code that does use them and they duplicate information which can be readily found in the source itself... they seem, to me, quite redundant.
     
  9. Gelfin macrumors 68020

    Gelfin

    Joined:
    Sep 18, 2001
    Location:
    Denver, CO
    #9
    If you don't see the point of using a header file, then you probably don't need it. They aren't mandatory. Generally speaking you're saying you don't see the point in separating interface from implementation, which says more about the scope of the coding you're doing than the languages you're doing it in.

    Objective-C has a lot going for it. Contrary to what most Java programmers think, it is not a failing for a programming language to be Not Java. With a single exception, all the programming languages in the world are Not Java (well, two exceptions if you count C#).

    Java is such a big sandbox lots of programmers don't ever feel the need to play elsewhere, but it's still a sandbox. Imagine a kid playing in a sandbox who refuses to leave, insists everything outside the sandbox is stupid and demands that grown-ups bring him his juice and cookies there. That's exactly the image a lot of Java programmers present while complaining that some other language is Not Java. The way they tend to cop a superior attitude while doing so is the source of a lot of the disrespect sometimes heaped on Java programmers as a species. The fact that many schools have shifted to a Java-only curriculum and are turning out such programmers by the truckload is a source of much consternation in some quarters.

    Don't be one of those. You've seen a small corner of the world. Go see more of it. Languages aren't automatically "better" or "more advanced" just because they're newer.

    Especially be aware of characterizing languages as "good" or "bad" on the basis of whether they include a garbage collector. This is not a measure of language quality; it is a measure of programmer quality. A garbage collector can be a convenience, an optimization or a crutch depending on the programmer wielding it. For most it's a crutch. They feel entitled to one because Java has one, and they think a "modern" language shouldn't require them to know anything about memory management. If you want to see some good "deer in headlights" reactions, respond to criticisms that C++ doesn't have a garbage collector with "so write one."
     
  10. Catfish_Man macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #10
    In general, I only want to know what a class does, not how it does it. Thousands of files are (barely) manageable. Having to browse through hundreds of thousands of lines of source probably wouldn't be.

    However, the Java world has gotten around the lack of header files by making its IDEs smarter, so it's not all bad :) Class outlines, really good autocomplete, and code folding all go a long way towards addressing it.

    Writing a *good* GC for C++ (or any language with raw pointers) is pretty much an unsolved problem, so that's a little unfair, I'd say. If you look at the crash logs for apps that crash on your system, check out the frequency of memory management related ones; even in "good" apps (Apple's, Omni's, etc...) it still accounts for probably >50% of all crashes. I think the expectation of GC is basically a sound one, even if a lot of inexperienced programmers want it for silly reasons. Myself, I want it because I'm imperfect. Even though I *can* do manual memory management, eventually I'll slip up, and if it's not caught in testing or code review... that's a crash or a leak I just shipped.
     
  11. yeroen macrumors 6502a

    yeroen

    Joined:
    Mar 8, 2007
    Location:
    Cambridge, MA
    #11
    Until your GC kicks in at the worst possible time. Better to use programming idioms that obviate the need for GC.

    Perhaps I'm showing my age too, but I'm also largely indifferent to IDE's. They're a nice slick productivity boost sometimes, but it's good to know what they're hiding from you. I view IDE's as the legacy of a piss-poor MS Windows environment that never had a proper command line interface. I've had to interview too many younger fresh-out-of-school programmers suckled on the IDE teat who don't know the language, the API's, or the system independent of what the IDE tells them.
     
  12. Gelfin macrumors 68020

    Gelfin

    Joined:
    Sep 18, 2001
    Location:
    Denver, CO
    #12
    Well, if you're going to go to all the trouble to write a garbage collector, you'll establish rules for using it and discipline yourself not to break them. That makes the problem a little more tractable. Having to choose to use it would be the minor downside of having the choice at all. Besides, this criticism could be leveled equally as well against strong typing in C++, but nobody would suggest we abandon the attempt simply because the programmer has the power to intentionally break it.

    I don't really hold to the school of thought that says GC is good for protecting a programmer from himself. The ways in which you can shoot yourself in the foot in a GC system are different, not absent. For basic self-protection, smart pointers in various incarnations provide similar results, not that I'm pushing those as a panacea either.

    As far as I'm concerned the efficiency argument is the potentially good argument for using GC, and really you might consider implementing a GC scheme only for the objects that will truly benefit from it.
     
  13. iSee macrumors 68040

    iSee

    Joined:
    Oct 25, 2004
    #13
    This is out of line. You're making sweeping generalizations about Java programmers and likening them to peevish children playing in a sandbox. Sorry to be blunt, but you need to realize you shouldn't characterize programmers as "good" or "bad" on the basis of whether or not they use a language that includes a garbage collector.
     
  14. Catfish_Man macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #14
    Actually, by "good" here I meant "fast". Copying collectors don't like raw pointers.

    So because it doesn't completely solve all the problems it's not useful? That's nonsensical. I'm arguing that GC is safer, not that it's safe.

    Although in theory (and in certain microbenchmarks) GC can be faster, in the real world I don't know of any systems that demonstrate this. CPU efficiency seems like a reason to avoid GC, not to use it.

    Memory efficiency is probably another story though; Mozilla's new cycle collector in Firefox 3 has apparently led to some improvements there, and Instruments has GC tracing tools that might help in debugging that sort of thing.

    Naturally, having good tools is no excuse for not knowing how the system works. However, I fail to see why I should avoid helpful things just because fools use them.
     
  15. Palad1 macrumors 6502a

    Palad1

    Joined:
    Feb 24, 2004
    Location:
    London, UK
    #15
    Java / C# vs ObjC : It's all about the runtime

    I'd gladly have a proper port of the obj-c message passing runtime on Java or mono.

    Just realize that obj-c
    Code:
    [obj foo :withbar=42];
    is not equivalent to c#
    Code:
    obj.foo(42);
    but rather something along the lines of...
    Code:
    MessageController.Send(obj, new Message("foo",new Arg<int>("withBar",42));
    
    The message passing framework is what makes Obj-c really shine, IMHO.

    Just out of curiosity, I'd really appreciate seeing some obj-c++ code, as that's what obj-(c#|java) would look like.

    Cheers,
    Palad1
     
  16. AlmostThere macrumors 6502a

    #16
    Quite right. In fact, a programmer that insists on using manual memory management when it is not needed is a bad programmer. A good programmer focuses on solving a problem, using tools appropriate to the domain and not delving into unnecessary complexity.

    If you genuinely find that automated memory management is causing bottle necks, then sure, go ahead and customise your allocation / de-allocation mechanism.
     
  17. Catfish_Man macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #17
    ObjC++ is not what you seem to think; It's literally just putting C++ and ObjC in the same file, taking advantage of the common heritage of C between them. Nothing terribly interesting, although certainly useful at times.
     
  18. gnasher729 macrumors P6

    gnasher729

    Joined:
    Nov 25, 2005
    #18
    1. I myself hate, absolutely hate, Java's insistence on mixing interface and implementation. I don't want to see your code, I want to know how to call it.

    2. Objective C 2.0 has garbage collection. And it can give you the best of both world, giving you garbage collection where you want it, or manual memory management where you prefer that.

    3. Objective C had features 20 years ago that C++ and Java don't have today.

    4. Objective C gives you all the goodness of C and interfacing with C and C++ for free. Look at a project like Handbrake, which is written in Objective C and links to half a dozen open source libraries that are written in C or C++. With Java, that would be an absolute nightmare.
     
  19. gnasher729 macrumors P6

    gnasher729

    Joined:
    Nov 25, 2005
    #19
    Just for fun, open "Files.h" in the carbon framework. 9,300 lines of header file. Now can you imagine what that would be like if you had the source code added to it? Would you want to figure out how to call a function by looking at a 100,000 line source file? (And there is me hoping that they split it up into more than one file :eek:)
     
  20. Gelfin macrumors 68020

    Gelfin

    Joined:
    Sep 18, 2001
    Location:
    Denver, CO
    #20
    You're absolutely right that these things are completely out of line, and all I can say in my own defense is that it's a good thing I didn't say any of them.

    I do some work in Java myself. I know a great number of talented, skilled, experienced programmers, many more so than myself, who work primarily in Java. Maybe if I had said so explicitly in the first post you would have been inclined to read the rest more closely, so I apologize for that oversight. Those people are not remotely who I am talking about.

    If there can be said to be a problem with Java itself in all this, it's the two-edged sword that it's a high-torque language. It allows novice programmers to accomplish a lot fairly quickly. It does, however, lead a great number of them to think they know very much more than they do, and when they run into situations not covered by their Java experience, they blame the tools for not matching their expectations. Many of them paradoxically cop this strange superior attitude on the basis of what they don't know, like their language makes them better for not having to know it. God knows computer scientists aren't known for their humility, but bragging about not knowing what your program is doing is beyond the pale.

    To reiterate, I don't hold this attitude against Java programmers generally, but the attitude is common enough that there are those who do.

    I only called out memory management specifically because it's the example I see most consistently. Really the debate about when one strategy works better than another is beside the point, because the point is that schools are turning out graduates with CS degrees who are unable to even have such a discussion to begin with. Again, calling a language bad or primitive because it doesn't have a garbage collector says more about the programmer than it does about the language.

    And, again, for the benefit of those inclined to misread between the lines, I am not claiming that languages with collectors are bad. I admit I don't care for being forced to use one, but they certainly can be useful. I actually really like the way Objective-C 2 has approached GC, and one of these days I'll get around to experimenting with it (perhaps using some of the time I otherwise use posting here, eh?).

    It goes without saying, in most cases the standard memory management model is sufficient. Whether garbage collected or explicitly managed, allocation performance is not a bottleneck in most programming situations. When it is, though, it pays to know why such bottlenecks might happen in your given paradigm and what you might do differently to address it, whether you're talking about collection overhead in GC or heap fragmentation using malloc. That's the depth of skill a lot of the "only GC languages are good" crowd lack, and frequently seem proud to lack.
     
  21. Gelfin macrumors 68020

    Gelfin

    Joined:
    Sep 18, 2001
    Location:
    Denver, CO
    #21
    Well, if rule #1 of your hand-rolled GC is "no unmanaged pointers in GC objects" it'll help.

    I wasn't saying it's not useful, just that the "protect me from myself" argument doesn't hold much positive sway with me. I'm more interested in what a feature allows me to do than what it stops me from doing. I am concerned that overly GC-reliant programmers who run into such problems are more likely to throw up their hands and say it's a bug with the collector beyond their control.

    I've seen a few fairly compelling papers showing recent Hotspot GC outperforming native malloc for certain not so far-fetched application profiles, and absent having reproduced the tests myself I'm more than willing to presume good faith on the part of their authors.

    I'll still be partial to C and family because I prefer the fine-grained control that would allow me to recognize similar situations and, if it's worth it, put together a targeted collection scheme for only the objects that would benefit from it, which seems like a net win all around.

    You were not responding to me here, but we are in complete agreement on this point, and this is as concise a bottom line as I can imagine for this discussion.
     
  22. Catfish_Man macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #22
    Heh, good point.

    Interesting stuff. Did you see http://www.cs.umass.edu/~emery/pubs/f034-hertz.pdf ? I suppose it's less important in today's machines with tons of ram, but it still seems like a clever and potentially useful improvement.
     
  23. MacConvert macrumors newbie

    Joined:
    Dec 28, 2006
    Location:
    Seattle, WA
    #23
    You indeed can have a separation of the implementation from the interface in Java - write the interface as an interface "public interface MyAPI { ... }" and the implementation as "public class MyAPIImpl implements MyAPI { ... }" - so I'm not sure what forces you to see the code (versus the API alone). Yes, there's a lot of programmers that don't create the interface separate of the implementation, or don't even think much of what the interface means or its importance in keeping these concerns separate and the interface hardened and defined as much as possible, but this is by choice. The language does allow you to keep the API separate from the implementation (and a lot of good source code I've seen, e.g. JBoss AS, does do this indeed for every class they produce).

    Java does not insist you mix the code w/the interface - the programmer does however :) (unwittingly or not).

    You can have Java interface with either C or C++, without a problem, via JNI, and it works quite well.

    The point of Java was, however, to be WORA - write once, run anywhere. This, in theory, is a good ideal - and Java largely achieves it, except for where it can not or should not - and that's where JNI steps in.

    For apps that Java or another interpreted/VM language can not cut it, C or C++ is always there. And neither are going away anytime soon (I know, 'cause we still have production apps in C and C++ that have been in production for over 19 years and counting).
     
  24. jsw Moderator emeritus

    jsw

    Joined:
    Mar 16, 2004
    Location:
    Andover, MA
    #24
    I'm not sure how that matters - if they can produce the results you need. It's like complaining that few write in assembly language anymore. It's true - because few people need to. If tools produce faster and more uniform results, then everyone wins.

    Most people today can't forge steel, machine metal into complex shapes, generate AC power, or wire heating elements properly. Doesn't mean they can't make damned good toast.
     
  25. sord macrumors 6502

    Joined:
    Jun 16, 2004
    #25
    I complain that few people are learning assembler because they are also not learning how computers truly work, and have very little respect for optimization and how to properly organize code to get the job done without constantly faulting.

    You're missing something there... Its true that I don't know how to do most of those things, and I can make good toast, HOWEVER I am not in the field of producing toasters. If you are making toasters, you probably know quite a bit about those things. Similarly, programmers SHOULD understand how to get to their end result.

    Remember, tools are nice, but if you replace your education/knowledge with your tools and drop the first part, your worth and ease of getting a better job goes way down.
     

Share This Page