5 ms·

What makes Cocoa and Cocoa Touch really nice isn't that parts of them are delightful, it's that all of the parts work really well together. They were written t

by amock 17y ago

What makes Cocoa and Cocoa Touch really nice isn't that parts of them are delightful, it's that all of the parts work really well together. They were written to take advantage of Objective-C and the tools were built for using them. Interface builder makes UIs really easy and CoreData makes persistence almost automatic. You should try building an iPhone app and see how it compares.

orangecat 17y ago
You should try building an iPhone app and see how it compares. I have, and Android wins for me. Cocoa Touch is a decent API (in most cases; what's with NSImage vs CGImage vs CIImage?), but Objective-C is seriously outdated. It usually needs more boilerplate than even Java, and manual memory management, lack of namespaces, and header files are silly in 2010.
- KirinDave 17y ago
  Well ObjC straddles a very interesting place. It's as low-level as C++ but has high level message passing method dispatch as well. If it seems a little crufty, it's because it's living in a very peculiar place trying to serve a variety of masters. Hopefully 4.0 will start to pave the way for the ObjC2.0 stuff to come to iPhone. They are really big improvements to the language. Also, rule-based syntax translators could give you a ton of stuff as a preprocessing pass to your code. Write something for NSArray literals and you'll be a hero.
  - crux_ 17y ago
    Isn't one of the big problems here that "rule-based syntax translators" are kind of disallowed?
    - KirinDave 17y ago
      Not if they produce straightforward objective c. How would one even separate such code generation from the use of regular #define?
      - daeken 17y ago
        You're right, they couldn't tell. But that doesn't mean they're not disallowed -- unless you're writing C, C++, Obj-C, or Javascript, it's disallowed, period. But that doesn't mean people won't do it.
        KirinDave 17y ago
        I'm not sure I agree that code translation is entirely disallowed. Part of the problem, though, is that the legalese in the iphone 4 revision is maddeningly obscure and unhelpful. We're not even sure if embedded Lua interpreters are really banned. I'm sure Apple is considering that very question.
  - elai 17y ago
    Yes, something to replace the super crufty NSArray / NSMutableArray / NSSet / NSDictionary, syntax would be really good. Small talk message passing was meant to have short, small one symbol binary operators, but unfortunately that elegance is not there in objective c.
    - glhaynes 17y ago
      Over the life of the code, I'm only gonna type it once; I may read it a hundred times.
      - elai 16y ago
        To be honest with you [[stuff objectAtIndex:5] objectForKey:@"name"] is less readable than stuff[5][@"name"]. And you type this kind of code constantly over and over again, it can really stack up and create something that would be simple to read in other languages.
        cpr 16y ago
        Except that if you're used to Smalltalk, this is just standard fare. I agree that a Python-like shorthand would be great at the object level, but then you'd have a mixture of shorthand and longhand, and that would be ugly.
  - cpr 17y ago
    Yes, looks like Obj-C blocks made it to 4.0. GC is probably a ways off for obvious reasons.
  - irons 17y ago
    To be pedantic, "Objective-C 2.0" features are things the iPhone always had, like properties and fast enumeration, and/or had first, like the modern runtime (which solves the fragile base class problem, and which Mac apps still only get if they're 64-bit). Blocks were a Snow Leopard feature, implemented as a C extension, and sprinkled throughout Apple's APIs; no direct relationship to Obj-C.
    - KirinDave 17y ago
      I was thinking more along the lines of the garbage collector. That's sort of the "tent pole" feature of the last cycle of objc revisions.
      - irons 17y ago
        With the first iPad model still at 256 MB RAM, and no sign of GC in the iPhone OS 4 preview, memory management will be with the platform for a long time. I think we'll see multi-core first.
        KirinDave 16y ago
        There are collectors that work very well in space constrained, processor constrained environments. It's not impossible.
- swannodette 17y ago
  > more boilerplate than Java whatever. Objective-C is far closer to the elegant dynamism of SmallTalk than Java. > manual memory management Makes sense. This is a resource constrained device. > lack of namespaces This is a phone not an enterprise server. > header files On a device with an underpowered processor the focus on C-based languaged has been paying back serious dividends as far as the responsiveness of the platform's applications.
- umjames 17y ago
  Assuming we're only talking about the iPhone APIs, then there's no NSImage or CIImage (Mac OS X desktop only). As for UIImage and CGImageRef, which are on the iPhone, UIImage is an Objective-C class, whereas CGImageRef is a C opaque struct. CGImageRef comes from the CoreGraphics (aka Quartz) lower-level 2D drawing APIs (implemented using C functions). This framework was around before the iPhone as it is also found in the Mac OS X APIs. UIImage gives you the ability to use a CGImageRef as an object. It doesn't expose all of the functionality found at the CoreGraphics layer, but it can be easier to use with other ObjC classes.
  - orangecat 17y ago
    You're right, I was thinking of desktop Mac OS X there, and an especially annoying section of code where I was trying to get those three image APIs to talk to each other. Apple did in fact remove a lot of cruft and duplication in the iPhone API, and that's good. Still, there are a number of cases like that where you have to switch between ObjC method calls and straight C functions. Not a huge deal, but it's clearly not the SmallTalk-style pure OO.
vito 17y ago
I would try it out, but right now my iPhone is on Craigslist and a Nexus One is in the mail. :) I run Linux so that wouldn't be very easy to do anyway. Re: Interface Builder, I agree, but I don't think anything like that would work well for Android. It targets all kinds of devices and screen sizes; it really has to be flexible and that'd be harder to do with a WYSIWYG UI tool. That being said, someone made one for Android, but I still prefer coding it by hand: http://droiddraw.com/ http://droiddraw.com/ (it ain't the prettiest thing but it seems to work; you can even load up your own layouts). I don't question the rest, and I simply don't know enough about the iPhone APIs to compare it to Android, but I will say this: everything certainly works together in the Android APIs. I'm not 100% sure what the purpose of CoreData is - preferences? generic data storage? - but they are both part of Android as well. Funny that you mentioned everything working together (albeit in a different context); that's the biggest difference I noticed between how iPhone apps work and how Android apps work. See Activities (Android) vs. Apps (iPhone), Content Providers, Intents -- just about everything about Android apps is designed around working together. For example, in every iPhone app I've used that has a browser in it, it's always essentially a WebKit view with some primitive controls, or it says "Halt app and switch to Safari?". In Android most apps open up the native Browser app's main activity, and hitting Back will close it and go right back to where you were. It's not really based on multitasking or switching apps, it just reuses the Browser's Activity to accomplish the same task. Applications are all on the same level, even built-in ones, and can all work together beautifully by simply calling Activities of other apps for performing specific tasks, or controlling them through Intents, etc. iPhone apps tend to be much more isolated.
- catch23 17y ago
  You know, interface builder existed before the iPhone. Developers used it to build out interfaces for Mac applications which could run on devices with a big variety of screen sizes. Interface builder is screen size agnostic for the most part. When apple first released 3rd party app support, their iphone sdk didn't even support interface builder.
  - vito 17y ago
    I never said IB was iPhone-specific or made for it. I'd used it myself before that. Why are iPhone apps upscaled or letterboxed on the iPad, though?

by amock 17y ago

orangecat 17y ago

You should try building an iPhone app and see how it compares. I have, and Android wins for me. Cocoa Touch is a decent API (in most cases; what's with NSImage vs CGImage vs CIImage?), but Objective-C is seriously outdated. It usually needs more boilerplate than even Java, and manual memory management, lack of namespaces, and header files are silly in 2010.

KirinDave 17y ago
Well ObjC straddles a very interesting place. It's as low-level as C++ but has high level message passing method dispatch as well. If it seems a little crufty, it's because it's living in a very peculiar place trying to serve a variety of masters. Hopefully 4.0 will start to pave the way for the ObjC2.0 stuff to come to iPhone. They are really big improvements to the language. Also, rule-based syntax translators could give you a ton of stuff as a preprocessing pass to your code. Write something for NSArray literals and you'll be a hero.
- crux_ 17y ago
  Isn't one of the big problems here that "rule-based syntax translators" are kind of disallowed?
  - KirinDave 17y ago
    Not if they produce straightforward objective c. How would one even separate such code generation from the use of regular #define?
    - daeken 17y ago
      You're right, they couldn't tell. But that doesn't mean they're not disallowed -- unless you're writing C, C++, Obj-C, or Javascript, it's disallowed, period. But that doesn't mean people won't do it.
      - KirinDave 17y ago
        I'm not sure I agree that code translation is entirely disallowed. Part of the problem, though, is that the legalese in the iphone 4 revision is maddeningly obscure and unhelpful. We're not even sure if embedded Lua interpreters are really banned. I'm sure Apple is considering that very question.
- elai 17y ago
  Yes, something to replace the super crufty NSArray / NSMutableArray / NSSet / NSDictionary, syntax would be really good. Small talk message passing was meant to have short, small one symbol binary operators, but unfortunately that elegance is not there in objective c.
  - glhaynes 17y ago
    Over the life of the code, I'm only gonna type it once; I may read it a hundred times.
    - elai 16y ago
      To be honest with you [[stuff objectAtIndex:5] objectForKey:@"name"] is less readable than stuff[5][@"name"]. And you type this kind of code constantly over and over again, it can really stack up and create something that would be simple to read in other languages.
      - cpr 16y ago
        Except that if you're used to Smalltalk, this is just standard fare. I agree that a Python-like shorthand would be great at the object level, but then you'd have a mixture of shorthand and longhand, and that would be ugly.
- cpr 17y ago
  Yes, looks like Obj-C blocks made it to 4.0. GC is probably a ways off for obvious reasons.
- irons 17y ago
  To be pedantic, "Objective-C 2.0" features are things the iPhone always had, like properties and fast enumeration, and/or had first, like the modern runtime (which solves the fragile base class problem, and which Mac apps still only get if they're 64-bit). Blocks were a Snow Leopard feature, implemented as a C extension, and sprinkled throughout Apple's APIs; no direct relationship to Obj-C.
  - KirinDave 17y ago
    I was thinking more along the lines of the garbage collector. That's sort of the "tent pole" feature of the last cycle of objc revisions.
    - irons 17y ago
      With the first iPad model still at 256 MB RAM, and no sign of GC in the iPhone OS 4 preview, memory management will be with the platform for a long time. I think we'll see multi-core first.
      - KirinDave 16y ago
        There are collectors that work very well in space constrained, processor constrained environments. It's not impossible.
swannodette 17y ago
> more boilerplate than Java whatever. Objective-C is far closer to the elegant dynamism of SmallTalk than Java. > manual memory management Makes sense. This is a resource constrained device. > lack of namespaces This is a phone not an enterprise server. > header files On a device with an underpowered processor the focus on C-based languaged has been paying back serious dividends as far as the responsiveness of the platform's applications.
umjames 17y ago
Assuming we're only talking about the iPhone APIs, then there's no NSImage or CIImage (Mac OS X desktop only). As for UIImage and CGImageRef, which are on the iPhone, UIImage is an Objective-C class, whereas CGImageRef is a C opaque struct. CGImageRef comes from the CoreGraphics (aka Quartz) lower-level 2D drawing APIs (implemented using C functions). This framework was around before the iPhone as it is also found in the Mac OS X APIs. UIImage gives you the ability to use a CGImageRef as an object. It doesn't expose all of the functionality found at the CoreGraphics layer, but it can be easier to use with other ObjC classes.
- orangecat 17y ago
  You're right, I was thinking of desktop Mac OS X there, and an especially annoying section of code where I was trying to get those three image APIs to talk to each other. Apple did in fact remove a lot of cruft and duplication in the iPhone API, and that's good. Still, there are a number of cases like that where you have to switch between ObjC method calls and straight C functions. Not a huge deal, but it's clearly not the SmallTalk-style pure OO.

vito 17y ago

I would try it out, but right now my iPhone is on Craigslist and a Nexus One is in the mail. :) I run Linux so that wouldn't be very easy to do anyway. Re: Interface Builder, I agree, but I don't think anything like that would work well for Android. It targets all kinds of devices and screen sizes; it really has to be flexible and that'd be harder to do with a WYSIWYG UI tool. That being said, someone made one for Android, but I still prefer coding it by hand: http://droiddraw.com/ http://droiddraw.com/ (it ain't the prettiest thing but it seems to work; you can even load up your own layouts). I don't question the rest, and I simply don't know enough about the iPhone APIs to compare it to Android, but I will say this: everything certainly works together in the Android APIs. I'm not 100% sure what the purpose of CoreData is - preferences? generic data storage? - but they are both part of Android as well. Funny that you mentioned everything working together (albeit in a different context); that's the biggest difference I noticed between how iPhone apps work and how Android apps work. See Activities (Android) vs. Apps (iPhone), Content Providers, Intents -- just about everything about Android apps is designed around working together. For example, in every iPhone app I've used that has a browser in it, it's always essentially a WebKit view with some primitive controls, or it says "Halt app and switch to Safari?". In Android most apps open up the native Browser app's main activity, and hitting Back will close it and go right back to where you were. It's not really based on multitasking or switching apps, it just reuses the Browser's Activity to accomplish the same task. Applications are all on the same level, even built-in ones, and can all work together beautifully by simply calling Activities of other apps for performing specific tasks, or controlling them through Intents, etc. iPhone apps tend to be much more isolated.

catch23 17y ago
You know, interface builder existed before the iPhone. Developers used it to build out interfaces for Mac applications which could run on devices with a big variety of screen sizes. Interface builder is screen size agnostic for the most part. When apple first released 3rd party app support, their iphone sdk didn't even support interface builder.
- vito 17y ago
  I never said IB was iPhone-specific or made for it. I'd used it myself before that. Why are iPhone apps upscaled or letterboxed on the iPad, though?