Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why C# is the best language for mobile development

blog.xamarin.com

Post reply on HN
Print view View original

111–120 of 125 posts

Re: Why C# is the best language for mobile development

#111

Post by corresation »

SideburnsOfDoom wrote: post #110
corresation wrote: post #46

Earlier quoted context omitted.

In the vast majority of cases it is nothing more than syntactical sugar around loops. And no, I'm not saying that loops are superior, but rather I'm saying that loops are usually a terrible solution, but LINQ has a way of essentially hiding those egregious violators. Take a block of code with LINQ in it and rewrite it minus LINQ but logically performing the same operations that the sugar is resolving to. To most deve…

> I'm saying that loops are usually a terrible solution, but LINQ has a way of essentially hiding those egregious violators So when you want to sort, search or transform a list, you prefer a technique which doesn't iterate over the items in the list at all? That makes no sense.

I prefer a technique where algorithms and computer science come into play. e.g. dictionaries, hashes, binary trees, structured data based upon the actual uses, etc. Having a giant array of memory objects and then treating every bit of code like it's some edge condition is not appropriate.

Re: Why C# is the best language for mobile development

#112

Post by jaegerpicker »

NateDad wrote: post #94
corresation wrote: post #46

Earlier quoted context omitted.

In the vast majority of cases it is nothing more than syntactical sugar around loops. And no, I'm not saying that loops are superior, but rather I'm saying that loops are usually a terrible solution, but LINQ has a way of essentially hiding those egregious violators. Take a block of code with LINQ in it and rewrite it minus LINQ but logically performing the same operations that the sugar is resolving to. To most deve…

95% of the time, what looks like a failed "loops 101" test actually doesn't matter at all. Maybe your list comparison function takes O(n^2) time... if your list never gets above 10-20 objects, who cares? Yes, if you're running LINQ over a list of 1,000,000 items, then you'll want to be careful what you're calling. But how often does that really happen in mobile apps? What LINQ does is make your code more concise and…

Depends on what kind of mobile apps you are writing. Most of the apps I've worked on written tend to deal with video/ pixel level image conversions. In these cases it's really common to say convert an rgb pixel array to yuv or simliar and a linq expression on one of those arrays would quite simply kill the app. Which I think is the best counter argument to the op. C# might be fine until you decide to do something beyond the normal performance wise. Then you are back to square one learning the native supported tools, IMO you are much better off learning the native environments from the ground up.

Re: Why C# is the best language for mobile development

#113

Post by pretoriusB »

MichaelGG wrote: post #62
benzor wrote: post #57

Earlier quoted context omitted.

Sorry, but you're really attacking a straw man here. Neither C# itself nor the OP's article sell C# as being a prime language for functional, dynamic, or systems programming. Rather, it has inherited some convenient little bits of each paradigm to make the language that much nicer to write. For example, don't want to redeclare that "List >" you're copying over because it has a scope of 2 lines? Just dynamically type…

"var" is not dynamic typing. It's just a way to enable type inference - it's still as static as can be. It also has a very limited useful scope in C#, as type inference isn't supported in most areas.

>"var" is not dynamic typing.

I think most people don't care about dynamic typing that much -- they mostly don't want to have to write types (that, an flexible containers).

Re: Why C# is the best language for mobile development

#114

Post by pretoriusB »

king_magic wrote: post #55
chc wrote: post #48

Earlier quoted context omitted.

> 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 langu…

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

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.

Re: Why C# is the best language for mobile development

#115

Post by SideburnsOfDoom »

corresation wrote: post #111
SideburnsOfDoom wrote: post #110

Earlier quoted context omitted.

> I'm saying that loops are usually a terrible solution, but LINQ has a way of essentially hiding those egregious violators So when you want to sort, search or transform a list, you prefer a technique which doesn't iterate over the items in the list at all? That makes no sense.

I prefer a technique where algorithms and computer science come into play. e.g. dictionaries, hashes, binary trees, structured data based upon the actual uses, etc. Having a giant array of memory objects and then treating every bit of code like it's some edge condition is not appropriate.

I agree that Dictionaries and the like are under-used.

But I don't agree that LINQ is bad because someone on your team didn't know how to use a Dictionary and thought that iteration would be fast on large in-memory lists.

In many cases there are efficient LINQ constructs, e.g lazy lists, and First() not enumerating past the matching item. Hand-coding these is prone to doing it worse than Linq would. Teach your team how to use .ToDictionary() if need be.

Re: Why C# is the best language for mobile development

#116

Post by migueldeicaza »

MichaelGG wrote: post #72
migueldeicaza wrote: post #63

Earlier quoted context omitted.

There is only one place where the type inferencing is not supported, field declarations. Not sure how that became "most areas".

Miguel I'm confused then - your experience with Mono certainly means you have a better understanding, but I thought I understood it pretty well, too. Places lacking type inference: - Parameter definitions - Method return types - Generic type parameters (sometimes) - Lambda expressions (due lack of syntax to indicate quoted code) - Field declarations The only place type inference works for declarations is in local var…

"var" is a shorthand to not declare the type when it can be inferred, in most cases to avoid Foo foo = new Foo(). The point is that it avoid repetitive typing, while still preserving type safety and everything that comes with it: compiler checking that right types are used in the right places.

[Digression While it is possible to use in var foo = GetIt() the practice is discouraged because it makes the type of "foo" opaque to the casual reader]

For a parameter definition, its use clearly makes no sense. What is the type for the following method?

void Demo (var x) {}

"var" in the above example would not really add much value, neither would the following example, where inference will oscillate from useless to fragile, depending on who you ask:

void Demo (var x) { var j = x.Parent; }

For method return types the reason is simple, it serves no useful purpose, in fact, it can be quite damaging as the public API contract can change during routine work. Consider a method:

var Demo (PointF f) { if (f.X The above method signature cal oscillate easily between float or double on the day that someone changes the 1 with 1.2. Reading a diff or a patch file wont catch the fact that you have accidentally changed the type of the function.

If this is the kind of code that you need to write (both cases above), then by all means, use the right tool and replace "var" with "dynamic". I would argue that using "dynamic" for the sake of not declaring the type there is a poor practice, but I am not about to lecture you on poor coding choices.

Generic type paramters: your comment makes no sense.

Lamdba expressions: makes no sense, the parameters are already inferred. Not sure what value (var x) adds over the already existing (x) syntax.

Which brings us to the very case I quoted "field declarations".

The ones that you skipped where it is supported: local variable declarations, for statements, using statements, consts locals and fixed statements.

Re: Why C# is the best language for mobile development

#118

Post by CodeCube »

king_magic wrote: post #60
chc wrote: post #59

Earlier quoted context omitted.

> 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 c…

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 - b…

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

Re: Why C# is the best language for mobile development

#119

Post by king_magic »

pretoriusB wrote: post #114
king_magic wrote: post #55

Earlier quoted context omitted.

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

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 sin…

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.

Re: Why C# is the best language for mobile development

#120

Post by redth »

natfriedman wrote: post #18
gte910h wrote: post #10

The vast majority of the code in most apps is not core code, it's display code. That's STILL entirely device specific. I think the C# advocates oversell how much it is reusable If you STARTED with a great pile of C# code, say, running on the desktop or server, then wanted to port that to an iOS device, then you have a point. One big problem with non-native code is that example code is almost always written in native…

That's actually not what we see with our customers and their apps. Here is a real-world example of code sharing percentages for an iOS, Android, and Mac app written in C#: http://lipsky.me/blog/2012/9/11/touchdraw-code-reuse-updated And here is another one across iOS, Android, Mac, and Windows, also in C#: http://praeclarum.org/post/31799384896/icircuit-code-reuse-t... Both of these apps are using 100% _native widget…

Let's not forget WshLst example which uses MvvmCross to achieve about 70% code reuse for UI heavy apps that use the specific UI bits on each platform:

https://github.com/Redth/WshLst

Post reply on HN