3 ms·

Yuck! After all these years of high level languages, having to use a mid-level language like objective-c to develop for iPhone feels like a step backwards! If o

Yuck! After all these years of high level languages, having to use a mid-level language like objective-c to develop for iPhone feels like a step backwards! If only HTML5 / phonegap was more of a viable option.

jasongullickson 16y ago
What's not viable about HTML5/phonegap?
- al_james 16y ago
  Speed and user experience! Fullscreen Webkit animations are normally jerky and slow. Trying to do any form of complex graphics (canvas bitmap data for example) is a no hoper. Overall phonegap applications (at least the ones I have seen) are just not as polished as native ones.
  - cmelbye 16y ago
    Interesting, a lower level programming language (Objective-C) is faster than a higher level programming language (Javascript). Who would've guessed?
glhaynes 16y ago
If I had to choose between Objective-C + Cocoa Touch vs. HTML5 + the-best-HTML-framework(s)-that-exist-in-2010, I'd certainly choose the former.
xsmasher 16y ago
I'm finding Objective-C to be a powerful addition to C and refreshingly simple compared to C++. What are you comparing it to, and what should I be missing?
- chrisa 16y ago
  I mostly program in ruby, but have been working with objective-c more lately, so I can try to summarize what my thinking with a few examples: - Why do I have to begin every string with @? I know the technical reason why, and the difference between having it and not having it, but I don’t want to type it all the time. - Every time I type CGRectZero as an argument, I think "the method should just assume I want a CGRectZero, and if not, then I’ll tell it otherwise" - It's distracting to my thought process to surround everything with []. That could just be a result of not spending enough time in the language - Typing the name of every argument becomes tiresome after a while. Auto-complete does help some. - I don’t see it in this example, but I often see cases which alloc an object, set another object to that object (usually doing some data massaging in the process), and then release the first object. In ruby, it would be a single (short) line. I think (hope) that as I get better with the language, many of those annoyances fade away. Looking at it now, I think I could summarize it all with: The default of objective-c is to be verbose, and the default for ruby is to be terse. edit: the "alloc, set, release" paradigm can be found in part 2, step 1.
- probablycorey 16y ago
  You are right, compared to C++ and C ObjC has advantages. But compared to other langues it has major drawbacks. Here are some reasons I don't like Objective-C (these mostly apply to iPhone dev only) - Header Files: These are archaic and require you to repeat code unnecessarily. Don't require humans to do something that computers are better at. - No Automatic Garbage Collection: On the ObjC 2.0 we have this, but not on the iPhone. Unless you are making a high performance game, there is no reason the phone can't handle Automatic GC. - No NSDictionary/NSArray literals: [[NSDictionary alloc] initWithObjectsAndKeys:@"value", @"key", @"value2", @"key2", nil]; // Enough said - No regex: You kind of get regex's in 3.2, but they are very limited. Regex literals are much more powerful - Xcode: You are pretty much required to use Xcode and I don't like Xcode. Even if you use the "xcodebuild" command-line script, you still have to create the project through Xcode. - Closures: I guess we will be able to use these soon, but it is going to take awhile for all the API's to get updated to accommodate them. - No dynamic variables: It's handy to be able to shove data into objects sometimes. It's a hack, but as long as you treat it as such you can save a lot of needless code. (You can do this via the ObjC runtime, but it's messy) - No namespacing: ObjC handles namespaces by prefixing class names. Blah, that is so 1978. - Unit Testing: ObjC has the poorest excuse for unit testing out of any language I've ever used.
  - wrs 16y ago
    It's not technically a language thing, but I can't get used to the unbelievable verbosity of the method names. (And for calibration purposes: I used to do a lot of Common Lisp.) In a language inspired by Smalltalk, they turned "at:" into "objectAtIndex:"?
mhd 16y ago
I think the "feels" is your main problem. Looking at the code samples here, there's not much you could cut out in more high-level languages. In a direct comparison with e.g. MacRuby, F-Script or Objective-J, not much is gained (mostly the header files and some manual memory management). Objective-C usually looks a bit messier than it actually is. Lisp programmers don't notice parens, Objective-C programmers don't notice anything but the messages (unless they have to). Generic GUI code always seems a bit messy. Yes, for simple apps your usual JQuery functions are small enough, but that gets messy quick enough -- it's like handling X11 events in a switch loop, easy enough when you have to react to a couple of simple events, but once you got enough going on. Cocoa is mostly made for bigger applications. There might be some slightly easier way for mobile apps, but the gain would be minute and is really offset by having one paradigm for GUIs that stretches device classes.
- al_james 16y ago
  I think you have hit my main point. Objective-C feels too heavyweight for (typically) small iOs apps.

jasongullickson 16y ago

What's not viable about HTML5/phonegap?

al_james 16y ago
Speed and user experience! Fullscreen Webkit animations are normally jerky and slow. Trying to do any form of complex graphics (canvas bitmap data for example) is a no hoper. Overall phonegap applications (at least the ones I have seen) are just not as polished as native ones.
- cmelbye 16y ago
  Interesting, a lower level programming language (Objective-C) is faster than a higher level programming language (Javascript). Who would've guessed?

glhaynes 16y ago

If I had to choose between Objective-C + Cocoa Touch vs. HTML5 + the-best-HTML-framework(s)-that-exist-in-2010, I'd certainly choose the former.

xsmasher 16y ago

I'm finding Objective-C to be a powerful addition to C and refreshingly simple compared to C++. What are you comparing it to, and what should I be missing?

chrisa 16y ago
I mostly program in ruby, but have been working with objective-c more lately, so I can try to summarize what my thinking with a few examples: - Why do I have to begin every string with @? I know the technical reason why, and the difference between having it and not having it, but I don’t want to type it all the time. - Every time I type CGRectZero as an argument, I think "the method should just assume I want a CGRectZero, and if not, then I’ll tell it otherwise" - It's distracting to my thought process to surround everything with []. That could just be a result of not spending enough time in the language - Typing the name of every argument becomes tiresome after a while. Auto-complete does help some. - I don’t see it in this example, but I often see cases which alloc an object, set another object to that object (usually doing some data massaging in the process), and then release the first object. In ruby, it would be a single (short) line. I think (hope) that as I get better with the language, many of those annoyances fade away. Looking at it now, I think I could summarize it all with: The default of objective-c is to be verbose, and the default for ruby is to be terse. edit: the "alloc, set, release" paradigm can be found in part 2, step 1.
probablycorey 16y ago
You are right, compared to C++ and C ObjC has advantages. But compared to other langues it has major drawbacks. Here are some reasons I don't like Objective-C (these mostly apply to iPhone dev only) - Header Files: These are archaic and require you to repeat code unnecessarily. Don't require humans to do something that computers are better at. - No Automatic Garbage Collection: On the ObjC 2.0 we have this, but not on the iPhone. Unless you are making a high performance game, there is no reason the phone can't handle Automatic GC. - No NSDictionary/NSArray literals: [[NSDictionary alloc] initWithObjectsAndKeys:@"value", @"key", @"value2", @"key2", nil]; // Enough said - No regex: You kind of get regex's in 3.2, but they are very limited. Regex literals are much more powerful - Xcode: You are pretty much required to use Xcode and I don't like Xcode. Even if you use the "xcodebuild" command-line script, you still have to create the project through Xcode. - Closures: I guess we will be able to use these soon, but it is going to take awhile for all the API's to get updated to accommodate them. - No dynamic variables: It's handy to be able to shove data into objects sometimes. It's a hack, but as long as you treat it as such you can save a lot of needless code. (You can do this via the ObjC runtime, but it's messy) - No namespacing: ObjC handles namespaces by prefixing class names. Blah, that is so 1978. - Unit Testing: ObjC has the poorest excuse for unit testing out of any language I've ever used.
- wrs 16y ago
  It's not technically a language thing, but I can't get used to the unbelievable verbosity of the method names. (And for calibration purposes: I used to do a lot of Common Lisp.) In a language inspired by Smalltalk, they turned "at:" into "objectAtIndex:"?

mhd 16y ago

I think the "feels" is your main problem. Looking at the code samples here, there's not much you could cut out in more high-level languages. In a direct comparison with e.g. MacRuby, F-Script or Objective-J, not much is gained (mostly the header files and some manual memory management). Objective-C usually looks a bit messier than it actually is. Lisp programmers don't notice parens, Objective-C programmers don't notice anything but the messages (unless they have to). Generic GUI code always seems a bit messy. Yes, for simple apps your usual JQuery functions are small enough, but that gets messy quick enough -- it's like handling X11 events in a switch loop, easy enough when you have to react to a couple of simple events, but once you got enough going on. Cocoa is mostly made for bigger applications. There might be some slightly easier way for mobile apps, but the gain would be minute and is really offset by having one paradigm for GUIs that stretches device classes.

al_james 16y ago
I think you have hit my main point. Objective-C feels too heavyweight for (typically) small iOs apps.