Live data from Hacker News

MonoTouch for iPhone - C# bindings for native APIs

monotouch.net

11–20 of 23 posts

Re: MonoTouch for iPhone - C# bindings for native APIs

#11
post #4

Earlier quoted context omitted.

Consider toying around with Objective-C. I was pleasantly surprised. I had never used SmallTalk, and I had a good time with the idea of "message passing". This doesn't take away the requirement of having to own a Mac, so it's free to try it out anyway. If you have already tried it out and hate it, then I'm glad there is a new option!

I've been doing Objective-C for a long time, and I can barely stand the language. I use it because it's the most pragmatic choice for Mac (and now iPhone) development, but if I could I'd have dropped it in a heartbeat. It's incredibly verbose and almost the antithesis of "don't repeat yourself" -- as an arbitrary example, declaring an Objective-C 2.0 properties requires three different declarations: 1) Declare the in…

If you think ObjC is verbose, take a look at this example of MonoTouch: http://img.skitch.com/20090914-cuu9mkrnjg864k88ywijur5ebk.jp...

The equivalent ObjC code is:

  IBOutlet UIWindow *window;
  IBOutlet UILabel *label;
Also, your example isn't quite accurate. With the iPhone runtime, you only have to make the @property declaration in your interface and then @synthesize the variable in your implementation. #1 in your example isn't required. However, the Mac runtime doesn't support this — so by doing this, you're limited to only testing on a physical device (iPhone or iPod directly). Stick this class into a .m and compile it in Xcode targeting your iPhone and the Simulator respectively:

  @interface Foo : NSObject {
  //	id bar; // Only required on Mac runtime or if you want to use the iPhone Simulator
  }
  @property (nonatomic, retain) id bar;
  @end
  
  @implementation Foo
  @synthesize bar;
  - (void) doSomethingWithBar {
  	self.bar = @"baz";
  	NSLog (@"%@", self.bar);
  }
  @end
@synthesize is useful to have because, well, what if you want @dynamic?

As for the rest of the verbosity? To take a canonical example,

  string = [someString stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceCharacterSet]]; 
is much clearer to me then

  string.strip();
Or is there another example of its verbosity that you don't like? I don't find myself writing code that repeats itself very often. If I do, I'll refactor the code.

And I like that it has a tendency to have explicit method names: I can actually read my code months later when I need to go fix a bug. But thats my personal preference. If you disagree, its not my place to tell you otherwise.

Re: MonoTouch for iPhone - C# bindings for native APIs

#12
post #11

Earlier quoted context omitted.

I've been doing Objective-C for a long time, and I can barely stand the language. I use it because it's the most pragmatic choice for Mac (and now iPhone) development, but if I could I'd have dropped it in a heartbeat. It's incredibly verbose and almost the antithesis of "don't repeat yourself" -- as an arbitrary example, declaring an Objective-C 2.0 properties requires three different declarations: 1) Declare the in…

If you think ObjC is verbose, take a look at this example of MonoTouch: http://img.skitch.com/20090914-cuu9mkrnjg864k88ywijur5ebk.jp... The equivalent ObjC code is: IBOutlet UIWindow *window; IBOutlet UILabel *label; Also, your example isn't quite accurate. With the iPhone runtime, you only have to make the @property declaration in your interface and then @synthesize the variable in your implementation. #1 in your ex…

string.strip() is a convenience, you can find a horribly verbose way to do it C# as well.

Re: MonoTouch for iPhone - C# bindings for native APIs

#13
post #11

Earlier quoted context omitted.

I've been doing Objective-C for a long time, and I can barely stand the language. I use it because it's the most pragmatic choice for Mac (and now iPhone) development, but if I could I'd have dropped it in a heartbeat. It's incredibly verbose and almost the antithesis of "don't repeat yourself" -- as an arbitrary example, declaring an Objective-C 2.0 properties requires three different declarations: 1) Declare the in…

If you think ObjC is verbose, take a look at this example of MonoTouch: http://img.skitch.com/20090914-cuu9mkrnjg864k88ywijur5ebk.jp... The equivalent ObjC code is: IBOutlet UIWindow *window; IBOutlet UILabel *label; Also, your example isn't quite accurate. With the iPhone runtime, you only have to make the @property declaration in your interface and then @synthesize the variable in your implementation. #1 in your ex…

The equivalent ObjC code is: ...

MonoTouch appears to support Interface Builder as well.

Also, your example isn't quite accurate. With the iPhone runtime, you only have to make the @property declaration in your interface and then @synthesize the variable in your implementation. However, the Mac runtime doesn't support this ...

The reduction of three duplicate entries to two is admirable, but still ridiculous. Moreover, "However, the Mac runtime doesn't support this ..." is the key point here. You can't use them on the simulator or the Mac 32-bit runtime (which are the same).

Additionally, prior to being corrected in 10.6, you couldn't access the synthesized ivars directly.

@synthesize is useful to have because, well, what if you want @dynamic?

Set an attribute on the @property declaration.

Or is there another example of its verbosity that you don't like? I don't find myself writing code that repeats itself very often. If I do, I'll refactor the code out to its own method. Just like I would with any other language.

I've never had trouble reading my Java, OCaml, or F# code years after I wrote it, but YMMV. In addition to the syntax, which stands on its own as a testament to monstrous verbosity, here are a few more off the top of my head:

1) Delegate/target pattern -- alerts, timers, etc. Your classes become a morass of delegate methods and hinky hijinks to pass what should be closure-captured state across disparate method calls. I don't want to make a mess of my classes by refactoring code to a distinct method if it doesn't belong in a distinct method.

2) Initializers. You wind up writing 3-6 different init methods, and then have to write 3-6 different class method short-cuts so you don't have to write '[[[Class alloc] initWithEverything: everything] autorelease]' everywhere.

3) Repeating myself. All the time. Why do I have to write header files? Java, C#, F#, OCaml, Python, Ruby -- none of them require me to duplicate my interface and implementation in two places. I understand that this is Objective-C, but in 2009, perhaps Apple should reconsider the C part?

Re: MonoTouch for iPhone - C# bindings for native APIs

#14
post #11

Earlier quoted context omitted.

I've been doing Objective-C for a long time, and I can barely stand the language. I use it because it's the most pragmatic choice for Mac (and now iPhone) development, but if I could I'd have dropped it in a heartbeat. It's incredibly verbose and almost the antithesis of "don't repeat yourself" -- as an arbitrary example, declaring an Objective-C 2.0 properties requires three different declarations: 1) Declare the in…

If you think ObjC is verbose, take a look at this example of MonoTouch: http://img.skitch.com/20090914-cuu9mkrnjg864k88ywijur5ebk.jp... The equivalent ObjC code is: IBOutlet UIWindow *window; IBOutlet UILabel *label; Also, your example isn't quite accurate. With the iPhone runtime, you only have to make the @property declaration in your interface and then @synthesize the variable in your implementation. #1 in your ex…

The code that you showed is automatically generated from the XIB file, the user never has to type it.

When you discuss the @property compiler directive, you did not show the generated code, instead you opted to show the shortcut.

With MonoTouch there is no need for any shortcuts; The entire backing store to any outlets are compiler generated.

Re: MonoTouch for iPhone - C# bindings for native APIs

#15
post #5

This gets my vote simply because I won't be forced to use an otherwise unmarketable language like Objective C. Not that I hate the syntax...it's not that bad really...but I hate that I'm forced to learn it just for iPhone or OS X development. I can't really use it elsewhere. With Mono/C# that's not the case, and it's immediately worth it. I hope they'll target other phones and make it at least possible to migrate you…

We are looking at fixing this.

There will be a free eval that will not require you to buy until you are ready to test/deploy on the device.

Re: MonoTouch for iPhone - C# bindings for native APIs

#16
post #5

This gets my vote simply because I won't be forced to use an otherwise unmarketable language like Objective C. Not that I hate the syntax...it's not that bad really...but I hate that I'm forced to learn it just for iPhone or OS X development. I can't really use it elsewhere. With Mono/C# that's not the case, and it's immediately worth it. I hope they'll target other phones and make it at least possible to migrate you…

We are looking at fixing this. There will be a free eval that will not require you to buy until you are ready to test/deploy on the device.

Great news thanks...that is the way to do it!

Re: MonoTouch for iPhone - C# bindings for native APIs

#17
post #5

This gets my vote simply because I won't be forced to use an otherwise unmarketable language like Objective C. Not that I hate the syntax...it's not that bad really...but I hate that I'm forced to learn it just for iPhone or OS X development. I can't really use it elsewhere. With Mono/C# that's not the case, and it's immediately worth it. I hope they'll target other phones and make it at least possible to migrate you…

We are looking at fixing this. There will be a free eval that will not require you to buy until you are ready to test/deploy on the device.

Not being able to measure on-device performance and stability during evaluation is a pretty big deal. The simulator is only useful as a smoke test, even when using the native tools.

Re: MonoTouch for iPhone - C# bindings for native APIs

#18
post #11

Earlier quoted context omitted.

I've been doing Objective-C for a long time, and I can barely stand the language. I use it because it's the most pragmatic choice for Mac (and now iPhone) development, but if I could I'd have dropped it in a heartbeat. It's incredibly verbose and almost the antithesis of "don't repeat yourself" -- as an arbitrary example, declaring an Objective-C 2.0 properties requires three different declarations: 1) Declare the in…

If you think ObjC is verbose, take a look at this example of MonoTouch: http://img.skitch.com/20090914-cuu9mkrnjg864k88ywijur5ebk.jp... The equivalent ObjC code is: IBOutlet UIWindow *window; IBOutlet UILabel *label; Also, your example isn't quite accurate. With the iPhone runtime, you only have to make the @property declaration in your interface and then @synthesize the variable in your implementation. #1 in your ex…

I sure would hate to have things like "stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceCharacterSet]" in my programming life.

Re: MonoTouch for iPhone - C# bindings for native APIs

#19

Earlier quoted context omitted.

We are looking at fixing this. There will be a free eval that will not require you to buy until you are ready to test/deploy on the device.

Not being able to measure on-device performance and stability during evaluation is a pretty big deal. The simulator is only useful as a smoke test, even when using the native tools.

Actually, that's a very good point. I guess my wish is that one could deploy to a device, but not actually upload to the appstore or sell without a license. Testing on a device is absolutely crucial...

Re: MonoTouch for iPhone - C# bindings for native APIs

#20

It looks like you have to develop in MonoDevelop to use this, which is a bit of a shame. After all, the reason most teams use C# in the first place is that you get to use the best IDE around. Outside the context of VS.NET, C# doesn't have nearly as much going for it. Still, if it lets me avoid Objective C, I think I'll give this a shot.

Jason, I have a lot of respect for you but saying that C# doesn't have anything going other than the IDE is completely wrong. With LINQ, lambda expressions, continuations, reflection, extension methods, automatic properties, I believe that C# is the no.1 strongly typed language.
Post reply on HN