4 ms·

Sigh. Okay, let's play this game. 1. "Cutting edge", first thing listed is asynchronous programming. Okay, don't get me wrong, I like C#, I like the Task Paral

Sigh. Okay, let's play this game. 1. "Cutting edge", first thing listed is asynchronous programming. Okay, don't get me wrong, I like C#, I like the Task Parallel Library, but Grand Central Dispatch in OS X/iOS is beautifully simple and incredibly powerful. It does everything I need it to do. 2. "Powerful features" - OOP. Really? And Java/Objective-C don't support OOP/encapsulation? You can't do dependency injection in Java/Objective-C? lol. 3. "Advanced runtime" - garbage collection. I'd rather use ARC in Objective-C instead of depending on a garbage collector. 4. "Reliability" – type safety. Really? And Java/Objective-C aren't type safe? I seriously doubt that anyone considers Java or Objective-C to not be reliable languages when it comes to type safety. This is almost laughable, IMO. 5. "Easy to adopt" - easy to learn. Ok, I'll give you this one over Objective-C. But frankly, I expect a good programmer worth his salt to be able to learn another platform, and I don't consider iOS or Android to be conceptually more difficult than Windows. 6. "Fast execution. C# on iOS is powered by the LLVM optimizing compiler." Uh, I think I'd rather use Objective-C compiled with LLVM. And the bit about "performance of a low-level language"? I don't consider Objective-C to be a "low-level language". 7. "Native access" - sweet, I can use some fragile interface that breaks when Apple decides to deprecate half of their stuff. Can't wait! I love waiting for libraries to catch up. 8. "Portability" - this is a decent point, but let's be realistic - we're talking "minimally portable" here. Write-once run-anywhere is a pipe dream, IMO (at least at this point). There are always platform-specific considerations that need to be taken, and they are not always compatible with other platforms. But even still, this point should have been the main focus of the article. Points 1-7 are minor compared to this. This just doesn't feel like a serious discussion of C#'s potential for mobile development. Edit: just for the record, I'm not necessarily trying to refute all or some of the OP's points. I think the original article was poorly written, and the case for C# was poorly made. Hence my "let's play this game" comment.

CodeCube 14y ago
for #1, there's a bit more to asynchronous programming in C# these days than the TPL. Take a look at the new async/await keywords in C# 5. Lets you write asynchronous code without having to deal with callbacks.
- king_magic 14y ago
  True. That being said, I don't really feel like I am hugely more productive with C#'s asynchronous support than Obj-C's. I'm a huge fan of GCD's serial/parallel queues. I haven't found anything in C# with similar functionality that is as simple as GCD.
  - CodeCube 14y ago
    GCD is very similar to writing against the TPL ... so you have the choice of writing async/await code which makes the execution flow very easy to grok; or if that doesn't make sense in a given scenario you can just fire of a task. Best of both worlds :)
pfisch 14y ago
LINQ is pretty sick and if obj-c has a similar feature I have never seen it.
- king_magic 14y ago
  It's nice. I lived and breathed LINQ for many years. It's certainly useful; though I've been able to live without it fairly comfortably. It's just not a deal-breaker for me. But it is nice. I do love LINQ-to-objects.
- MatthewPhillips 14y ago
  Eh, disagree. It's confusing for a number of reasons, firstly because instead of choosing the common functional names -- map, filter, reduce, flatten, etc. they choose to go with SQL-like naming. Just an annoyance. Secondly, Expressions are a clever hack on top of the language, but they are not intuitive for the person using them and requires you to know too much about the particular implementation you are using (for example, if using Microsoft's ORM, string concantenation inside an Expression is disallowed). It's not their fault, C# isn't really functional, and Expressions allow them to make it look functional and have some laziness built in, but there are still enough gotchas that make using it a pain.
  - MichaelGG 14y ago
    Is there any other quotation-based system that _doesn't_ require you to understand the implementation? Or any language/runtime/library? SQL is different from one DB to the next, and a lot of C APIs are not implemented identically on all OSes. As to the names, I'm not sure it's safe to assume that "Map" would result in better usability than "Select", for MS's target audience.
chc 14y ago
> 3. "Advanced runtime" - garbage collection. I'd rather use ARC in Objective-C instead of depending on a garbage collector. I'd rather eat a burrito than a salad. This is not a very good technical critique of the nutritional benefits of salad vs. burritos. > "Reliability" – type safety. Really? And Java/Objective-C aren't type safe? I seriously doubt that anyone considers Java or Objective-C to not be reliable languages when it comes to type safety. This is almost laughable, IMO. I like Objective-C, but objectively speaking, Objective-C is horrible for type-safety. The id type is used in a lot of places (e.g. every collection class), and you can magically convert anything to anything else without a peep from the compiler through the id type. There is no easy way to say "This is an array of Foo" and have that checked. A cursory glance at the Objective-C tag on Stack Overflow will show you a lot of programmers coming from safer languages like Java or C# who are confused by Objective-C's lack of type safety. In practice this is not generally a huge problem once you get into the "Objective-C way of thinking," but static type checking really wasn't a huge consideration in the design of the language. It was designed with the Smalltalk philosophy of "a bunch of things sending messages to each other and responding with messages of their own," which heavily de-emphasizes the importance of concrete types in favor of interfaces. > "Fast execution. C# on iOS is powered by the LLVM optimizing compiler." Uh, I think I'd rather use Objective-C compiled with LLVM. This is another "I like burritos" argument. > "Portability" - this is a decent point, but let's be realistic - we're talking "minimally portable" here. Write-once run-anywhere is a pipe dream, IMO (at least at this point). While there will always be platform-specific debugging and often some platform-specific code required, it is indeed quite possible and even common to write portable programs. You probably use many of them. Ever used Clang? GCC? Emacs? Ruby? The Bash shell? None of these programs have a completely different codebase for different platforms. They might have some platform-specific code, but having a common, portable base is hardly a pipe dream.
- king_magic 14y ago
  > I'd rather eat a burrito than a salad. This is not a very good technical critique of the nutritional benefits of salad vs. burritos. I put about as much effort into my critique as the original article's author did in arguing for C#'s superiority. > I like Objective-C, but objectively speaking, Objective-C is horrible for type-safety. The id type is used in a lot of places (e.g. every collection class), and you can magically convert anything to anything else without a peep from the compiler through the id type. There is no easy way to say "This is an array of Foo" and have that checked. This is a problem that has bit me in the ass maybe once or twice since I started developing in Obj-C several years ago. You could magically cast things to whatever you wanted in C++, and that was never a serious problem for me back when I was developing in C++ either. As an avid JavaScript developer as well, I've had no problem with a lack of type safety. It's just not the huge demon (for me) that it's made out to be - at least in my experience. > They might have some platform-specific code, but having a common, portable base is hardly a pipe dream. 70% code reuse across iOS and Android (see http://news.ycombinator.com/item?id=4998661 http://news.ycombinator.com/item?id=4998661) is hardly what I'd call "portable". Does the Bash shell do better than 70% code reuse across Linux / BSD / etc? I certainly hope it does.
danabramov 14y ago
I like MonoTouch so far but I must admit these are all valid points. There are more downsides Xamarin doesn't like to advertise, like problems with AOT compiler you can't anticipate until they bite you in the ass, the-GC-won't-collect-some-stuff problems that basically force you to always dispose native objects manually, and horribly buggy IDE that MonoDevelop is.
- migueldeicaza 14y ago
  I dont think I have your email address, but would love to share with you a tool I have been prototyping to identify the hard cycles in Objective-C that are causing the above leak problem. In short, you should not need to manually Dispose, but you might need to use weak references from children to parents.
redstripe 14y ago
3. So you like ARC? Do you prefer it over endless retain/release calls? a. because it reduces the chances of memory leaks in your code? Because in this case you negate your "every programmer worth his salt" point in #5 which we've all seen thousands of times when people explain why c++ is really the best language to be writing all software. b. because it greatly reduces the repeated boilerplate code? Which is pretty much how I define objective c in a single word: tedium. It's been a few years but all I remember from my brief foray is comparing every tutorial to how much shorter everything would be if it were written in another language. Pretty much any language other than c++ not just c#. If you think ARC is a great step forward then maybe you are honest enough to admit that objective c could make several giant other leaps and it might even end up looking a lot more like c#.
- chc 14y ago
  > because it greatly reduces the repeated boilerplate code? Which is pretty much how I define objective c in a single word: tedium. It's been a few years but all I remember from my brief foray is comparing every tutorial to how much shorter everything would be if it were written in another language. Pretty much any language other than c++ not just c#. Do you mean "shorter" in the sense of fewer characters, or "shorter" in the sense of fewer tokens? I've found both to be true to some degree (the state of text processing in Cocoa is positively barbaric), but what people usually complain about is the former, and I can't agree that it's a problem. I can understand why too much typing gets tedious, but I think as a criticism it's a red herring, because it's essentially the complaint that Objective-C tends to be descriptive. That's normally considered a good thing! With autocomplete, typing Objective-C isn't harder than typing code in any other language, and the descriptive names help when reading unfamiliar code. I can come across a method call in somebody else's Objective-C codebase and instantly understand what each argument is and does without having to jump around and look at definitions. If you actually mean you have to do more, though, I think that's one of those things that varies a lot from program to program. It's not really inherent to the language.

CodeCube 14y ago

for #1, there's a bit more to asynchronous programming in C# these days than the TPL. Take a look at the new async/await keywords in C# 5. Lets you write asynchronous code without having to deal with callbacks.

king_magic 14y ago
True. That being said, I don't really feel like I am hugely more productive with C#'s asynchronous support than Obj-C's. I'm a huge fan of GCD's serial/parallel queues. I haven't found anything in C# with similar functionality that is as simple as GCD.
- CodeCube 14y ago
  GCD is very similar to writing against the TPL ... so you have the choice of writing async/await code which makes the execution flow very easy to grok; or if that doesn't make sense in a given scenario you can just fire of a task. Best of both worlds :)

pfisch 14y ago

LINQ is pretty sick and if obj-c has a similar feature I have never seen it.

king_magic 14y ago
It's nice. I lived and breathed LINQ for many years. It's certainly useful; though I've been able to live without it fairly comfortably. It's just not a deal-breaker for me. But it is nice. I do love LINQ-to-objects.
MatthewPhillips 14y ago
Eh, disagree. It's confusing for a number of reasons, firstly because instead of choosing the common functional names -- map, filter, reduce, flatten, etc. they choose to go with SQL-like naming. Just an annoyance. Secondly, Expressions are a clever hack on top of the language, but they are not intuitive for the person using them and requires you to know too much about the particular implementation you are using (for example, if using Microsoft's ORM, string concantenation inside an Expression is disallowed). It's not their fault, C# isn't really functional, and Expressions allow them to make it look functional and have some laziness built in, but there are still enough gotchas that make using it a pain.
- MichaelGG 14y ago
  Is there any other quotation-based system that _doesn't_ require you to understand the implementation? Or any language/runtime/library? SQL is different from one DB to the next, and a lot of C APIs are not implemented identically on all OSes. As to the names, I'm not sure it's safe to assume that "Map" would result in better usability than "Select", for MS's target audience.

chc 14y ago

> 3. "Advanced runtime" - garbage collection. I'd rather use ARC in Objective-C instead of depending on a garbage collector. I'd rather eat a burrito than a salad. This is not a very good technical critique of the nutritional benefits of salad vs. burritos. > "Reliability" – type safety. Really? And Java/Objective-C aren't type safe? I seriously doubt that anyone considers Java or Objective-C to not be reliable languages when it comes to type safety. This is almost laughable, IMO. I like Objective-C, but objectively speaking, Objective-C is horrible for type-safety. The id type is used in a lot of places (e.g. every collection class), and you can magically convert anything to anything else without a peep from the compiler through the id type. There is no easy way to say "This is an array of Foo" and have that checked. A cursory glance at the Objective-C tag on Stack Overflow will show you a lot of programmers coming from safer languages like Java or C# who are confused by Objective-C's lack of type safety. In practice this is not generally a huge problem once you get into the "Objective-C way of thinking," but static type checking really wasn't a huge consideration in the design of the language. It was designed with the Smalltalk philosophy of "a bunch of things sending messages to each other and responding with messages of their own," which heavily de-emphasizes the importance of concrete types in favor of interfaces. > "Fast execution. C# on iOS is powered by the LLVM optimizing compiler." Uh, I think I'd rather use Objective-C compiled with LLVM. This is another "I like burritos" argument. > "Portability" - this is a decent point, but let's be realistic - we're talking "minimally portable" here. Write-once run-anywhere is a pipe dream, IMO (at least at this point). While there will always be platform-specific debugging and often some platform-specific code required, it is indeed quite possible and even common to write portable programs. You probably use many of them. Ever used Clang? GCC? Emacs? Ruby? The Bash shell? None of these programs have a completely different codebase for different platforms. They might have some platform-specific code, but having a common, portable base is hardly a pipe dream.

king_magic 14y ago
> I'd rather eat a burrito than a salad. This is not a very good technical critique of the nutritional benefits of salad vs. burritos. I put about as much effort into my critique as the original article's author did in arguing for C#'s superiority. > I like Objective-C, but objectively speaking, Objective-C is horrible for type-safety. The id type is used in a lot of places (e.g. every collection class), and you can magically convert anything to anything else without a peep from the compiler through the id type. There is no easy way to say "This is an array of Foo" and have that checked. This is a problem that has bit me in the ass maybe once or twice since I started developing in Obj-C several years ago. You could magically cast things to whatever you wanted in C++, and that was never a serious problem for me back when I was developing in C++ either. As an avid JavaScript developer as well, I've had no problem with a lack of type safety. It's just not the huge demon (for me) that it's made out to be - at least in my experience. > They might have some platform-specific code, but having a common, portable base is hardly a pipe dream. 70% code reuse across iOS and Android (see http://news.ycombinator.com/item?id=4998661 http://news.ycombinator.com/item?id=4998661) is hardly what I'd call "portable". Does the Bash shell do better than 70% code reuse across Linux / BSD / etc? I certainly hope it does.

danabramov 14y ago

I like MonoTouch so far but I must admit these are all valid points. There are more downsides Xamarin doesn't like to advertise, like problems with AOT compiler you can't anticipate until they bite you in the ass, the-GC-won't-collect-some-stuff problems that basically force you to always dispose native objects manually, and horribly buggy IDE that MonoDevelop is.

migueldeicaza 14y ago
I dont think I have your email address, but would love to share with you a tool I have been prototyping to identify the hard cycles in Objective-C that are causing the above leak problem. In short, you should not need to manually Dispose, but you might need to use weak references from children to parents.

redstripe 14y ago

3. So you like ARC? Do you prefer it over endless retain/release calls? a. because it reduces the chances of memory leaks in your code? Because in this case you negate your "every programmer worth his salt" point in #5 which we've all seen thousands of times when people explain why c++ is really the best language to be writing all software. b. because it greatly reduces the repeated boilerplate code? Which is pretty much how I define objective c in a single word: tedium. It's been a few years but all I remember from my brief foray is comparing every tutorial to how much shorter everything would be if it were written in another language. Pretty much any language other than c++ not just c#. If you think ARC is a great step forward then maybe you are honest enough to admit that objective c could make several giant other leaps and it might even end up looking a lot more like c#.

chc 14y ago
> because it greatly reduces the repeated boilerplate code? Which is pretty much how I define objective c in a single word: tedium. It's been a few years but all I remember from my brief foray is comparing every tutorial to how much shorter everything would be if it were written in another language. Pretty much any language other than c++ not just c#. Do you mean "shorter" in the sense of fewer characters, or "shorter" in the sense of fewer tokens? I've found both to be true to some degree (the state of text processing in Cocoa is positively barbaric), but what people usually complain about is the former, and I can't agree that it's a problem. I can understand why too much typing gets tedious, but I think as a criticism it's a red herring, because it's essentially the complaint that Objective-C tends to be descriptive. That's normally considered a good thing! With autocomplete, typing Objective-C isn't harder than typing code in any other language, and the descriptive names help when reading unfamiliar code. I can come across a method call in somebody else's Objective-C codebase and instantly understand what each argument is and does without having to jump around and look at definitions. If you actually mean you have to do more, though, I think that's one of those things that varies a lot from program to program. It's not really inherent to the language.