Hacker News Reader

> 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.

> 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) 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.

> I put about as much effort into my critique as the original article's author did in arguing for C#'s superiority.

Not really. He stated an actual fact: Proper garbage collection allows for simpler memory management than retain counting. I agree that he didn't do enough to illustrate this, but he did go further than just "I like this thing." It is indeed true that there are a number of awkward situations where you can end up with immortalized objects with retain counting that would not have been so under garbage collection (see for example the "__block id uglyHack = self" idiom in Objective-C).

> 70% code reuse across iOS and Android (see 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.

I would rather rewrite 30% of my code than 100%. If you want to say it's imperfect and could be better, that's fine, but dismissing it entirely seems unreasonable to me.

RE: GC vs reference counting, I've found that writing code using ARC feels a lot like writing code using GC - 95% of the time, I never notice it. Still, I'd prefer to not have the overhead of GC.

> I would rather rewrite 30% of my code than 100%.

I agree with you on this. I'm not dismissing it - in my original post, I said the focus of the original article should have been the potential for reuse across platforms - but it was glossed over in a disappointing 3 sentences.

Chris Sells added reference counting to the open source "Rotor" release years ago. This was to test whether GC overhead was indeed an overhead over deterministic finalization.

http://www.sellsbrothers.com/writing/refcount_rotor.doc

I'll let you come to your own conclusions about the results :)

I'm all for Objective-C, but your arguments were weak in the first place, and you're dragging a dead horse here.

I mean: "I put about as much effort into my critique as the original article's author did in arguing for C#'s superiority." -- Why even write your critique then? At least the original article's author had a reason, it is marketing copy.

>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

The general consensus is hardly that type safety in large applications is something to not be concerned with that only bites you "once or twice" when you are a novice. So I don't see the reason for the anecdotal reference.

>70% code reuse across iOS and Android (see http://news.ycombinator.com/item?id=4998661) is hardly what I'd call "portable"

This is horribly mistaken in more than two ways.

1) Nat says: "Both of these apps are using 100% _native widgets_ for their user interface, and I think it's fair to say that both of them are fairly UI-heavy.". Which means it's a worst case scenario. For a less UI-heavy app, or one with a custom canvas based GUI etc, the percentage would be far higher.

2) 70% is far better than rewriting everything (or 0% re-use) if you use Objective-C. You could use C++ or C to write a common base, but then you're not using a single language anymore, whereas with C# you are.

3) 70% in itself is nothing to sneer at when discussing portability. Especially considering your own argument that "write once, deploy everywhere" is a pipe dream, then 70% is quite high level of reuse -- basically meaning you merely re-do the UI parts to tune it to each platform.

I direct you to my final statement in my original post (http://news.ycombinator.com/item?id=4998697):

> 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.

RE: "This is horribly mistaken in more than two ways."

Not all code is created equal. That 30% that needs to be rewritten for each device could be difficult to tune for each platform. Native widgets in iOS do not work the same as native widgets in Andoid. Unless there is some magical abstraction layer (which doesn't appear to exist), you're potentially rewriting the most difficult code for each platform.

But again, please see my original post. In my original post, I said the focus of the original article should have been the potential for reuse across platforms - but it was glossed over in a disappointing 3 sentences.

>Not all code is created equal. That 30% that needs to be rewritten for each device could be difficult to tune for each platform. Native widgets in iOS do not work the same as native widgets in Andoid. Unless there is some magical abstraction layer (which doesn't appear to exist), you're potentially rewriting the most difficult code for each platform.

Again, far better than writing ALL the code for each platform.

And in a lot of cases the GUI code is not the "most difficult", it's just the one that cannot be easily written once for all platforms (and still look native).

For example, if you make a music application, the sound engine, FFT, filters etc would be the difficult part (but it can be written just once) and the GUI layer is quite easy compared.

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

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.

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.

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.

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.

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.

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.

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.

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 :)

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#.

> 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.