8 ms·

Why C# is the best language for mobile development

77 points by natfriedman 14y ago

corresation 14y ago
While a bit of an aside, personally I find LINQ to have been a horrendous misstep in the evolution of the language. While the argument that it makes code more concise and easy to maintain holds in the small, once a project grows it becomes a terrible cancer -- everything becomes an amorphous blob of stuff, unintuitive, performance-disaster LINQ filters applied everywhere to bend it into shape.
- sourc3 14y ago
  Yes, but it's not specific to LINQ or MS or C#. If you give a tool to mediocre developers to make things easier they will use it right away. If you don't supervise its usage (how it fits into the architectural goals of the project you are on) you will end up with a mess. Anonymous methods, unnamed classes, try catch blocks are all examples of these type of tools that when used improperly will kill the system performance, code readability, maintainability and extensibility.
  - corresation 14y ago
    Yes, but it's not specific to LINQ or MS or C# We are specifically talking about C#. LINQ was specifically held as one of the improvements to the language. I am not quite sure what your point is relative to that. There are shockingly few examples where LINQ is superior to alternatives. LINQ is the brute force technique of avoiding proper collections/algorithms.
    - taumeson 14y ago
      The point is relevant in relation to the fact that you held LINQ out as a misstep, but the reasons you cite can be applied to many features of many different languages.
      - weareconvo 14y ago
        Yes, but rather than actually arguing with his point, you are showing how it could also be used to criticize some other language features not in an attempt to prove him wrong, but rather to pander to anybody reading the argument who likes those language features.
    - abolibibelot 14y ago
      I don't understand. Are you saying that map, filter, reduce and al. on lazy sequences in functional languages are inferior to loops, or that Python list comprehensions and generators are inferior to loops? That's basically LINQ to objects. Maybe you're refering to LINQ-to-whatever (LINQ to SQL, etc.), a LINQ generalization where you can quote your expressions, rewrite the AST and emit something else (a very constrained kind of macros, if you will). MS is probably to blame here, but people keep conflating the two.
      - corresation 14y ago
        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 developers it would offend the sensibilities of construction, but somehow in LINQ-land all seems fine.
        recursive 14y ago
        Most developers I know seem to prefer the loop version. I'm not sure what you mean by "sensibilities of construction", but I'm a big advocate of LINQ. If your concern is that certain linq calls iterate an entire sequence, that could apply to all kinds of scenarios that have nothing to do with LINQ like string concatenation. You should always be aware of the performance characteristics of methods you are calling. LINQ is not special in that regard.
        NateDad 14y ago
        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 readable. It makes it easier to find bugs and easier to understand by someone else (even if someone else is you, 6 months down the road). It also just takes a lot less time to write.
- gjulianm 14y ago
  Could you give an example of that? Personally, I like LINQ a lot. I don't use it very much in my code (and usually it's for things like light filter or ordering), but it has these little things that save a lot of time.
  - taumeson 14y ago
    Be careful what you ask for -- you have to admit that it is possible to create some horrendous "code" with Linq. Also I have a hunch that OP is thinking of L2S or Linq2Entities or somesuch.
    - gjulianm 14y ago
      Well, horrendous code can be created with anything: LINQ, C#, Objective-C... But yes, such easy-to-use tools like LINQ are easily overused and you end up with real monstrous code.
- dos1 14y ago
  LINQ is just another tool in the toolbox. Like any tool it has the potential for misuse. Ultimately the skill of the person wielding the tool will decide whether the outcome is good or bad. It sounds like you've mostly seen the bad. In the right hands, LINQ can make things more readable and concise. Take another example, anonymous functions in Javascript. I've seen plenty of tremendously horrible JS code bases that were just a deep series of nested anonymous functions. Almost impossible to debug or maintain. However, when used appropriately the anonymous function is very powerful and can make certain things much easier.
- joelangeway 14y ago
  This is a fundamental place where the worlds of C# and Java differ. Where the Java world would say, "developers might misuse this, better not have it in the language," the C# world says, "developers could really use this, better put it in the language."
  - meaty 14y ago
    And if you've worked on a large project with a lot of cats to herd for both platforms, you will appreciate java very quickly.
    - JanJansen 14y ago
      I work on a pretty huge C# code base. Use of LINQ is the least of it's problems. If anything I'd say one problem is people not knowing about things like lambda expressions, linq, generics or whatever. It can really make code harder to parse when it's written in ways that don't take advantage of the full power of the platform.
      - ams6110 14y ago
        How much of that C# code pre-dates the availablilty of those features?
        JanJansen 14y ago
        Some of the code was certainly written before those features was available, especially some C# 4 features. I'm sure someone might look at my code someday and wonder why I didn't use async and await. I'm talking about code written today though.
      - meaty 14y ago
        Yes until we get to: List<List<Tuple<int, Dictionary<string, object>, string>>>
        MichaelGG 14y ago
- meaty 14y ago
  This times a million. The amount of shit I have to deal with where people have used it in criminal ways is unreal. Fine examples: .ToList() materialization multiple times in a call graph. Ok so the thread is eating 200mb of ram?!?!?! Generic method hell. complete lack of understanding regarding IEnumerable, ICollection, IList etc. O(log N) that doesn't go bang until you stick a production dataset in it. The specification pattern - bottled rape is the only way I can quantify this. Sounds great until you have 2500 specifications and are stacking them 20 deep and your ORM decides it has had enough of clauses (EF4 bug). My favourite: junior developer turns up and says "I wrote this awesome linq query - come and look!". Get there: all of the above.
  - taumeson 14y ago
    These are great concrete examples that are very Linq specific. I cringed reading a few of them. The .ToList() materialization can easily be avoided by using a little skill, but the realities of late binding that don't show up until you hit production -- this can catch anybody.
- gigantor 14y ago
  You don't even have to use LINQ at all with C#, it's an extension library and not one that needs to be referenced or is even included as a default namespace. LINQ is very convenient to use on in memory objects where there's no noticable performance hits. Even LINQ->SQL produces somewhat optimized SQL. How else would you bend data into shape without an ORM layer? Writing custom stored procedures, adding a whole bunch of new service methods, or manipulating data tables directly? This 'cancer' is simply a data layer; if you use proper design patterns and seperate your layers correctly, you can surgically remove this tumour and replace it with another ORM.
  - corresation 14y ago
    LINQ is indeed optional, but this discussion is about the evolution of the language, with LINQ being held as an improvement. And because it is new and shiny, C# code across the globe quickly became infected with it. Your comment on "where there is no noticeable performance hits" strikes a chord because when first used there are no noticeable performance hits. But then that application grows and scales and suddenly it is death by a million paper cuts, thousands of grossly inefficient set operations devastating performance. That's aside from the fact that LINQ is often a short-circuit saving from having to think about appropriate algorithms of object-methods to deal with the likely uses.
- kvb 14y ago
  Can you expand on what exactly you mean by LINQ? Do you mean the .NET library support (extension methods on IEnumerable/IQueryable)? Do you mean the language features added to C# (anonymous types, expression trees, nicer lambdas, query syntax)? The language features, with the possible exception of query syntax, seem like hugely beneficial additions, to me.
- pbz 14y ago
  We need to separate LINQ, the C# language feature, from the library implementation, LINQ to SQL or Entity Framework. The later does tend to cause issue because it offers a rather leaky abstraction over your database and poor performance. But it doesn't have to be this way. Case in point BLToolkit, a lesser known database access library that uses LINQ. It is light and almost as fast as native access. Very close to Dapper in performance or pretty much the same in performance if you compile your expression trees, but of course you have type-safety. Of course it doesn't have all the bells and whistles of L2S or EF, but you gain speed and simplicity.
- SideburnsOfDoom 14y ago
  > I find LINQ to have been a horrendous misstep ... grows it becomes a terrible cancer -- everything becomes an amorphous blob of stuff, unintuitive, performance-disaster LINQ filters I couldn't agree less. Any language construct can be abused, but LINQ is not particularly susceptible to abuse, unless you try very hard.
  - corresation 14y ago
    LINQ is from the outset designed for abuse, and you don't have to try hard whatsoever.
    - SideburnsOfDoom 14y ago
      That hasn't been my experience, I'm glad to say. And given the amount of c# code I've worked on already, it's unlikely to ever be.
RyanZAG 14y ago
Please don't actually do this - or if you do this, use the C# code only for the backend, and write the UI code natively for each platform. Nothing is worse than a 'not quire right' 'seems almost the same but isnt' UI.
- dos1 14y ago
  As I understand it the mobile SDKs Xamarin releases use the native UI widgets for each platform - allowing you to get native look and feel with one code base. (I may be wrong on this, but I thought this was one of their major selling points. However, never having used the SDKs I don't know how well it works in practice)
- segphault 14y ago
  One of the major advantages of Xamarin's approach is that the Xamarin frameworks expose access to all of the native APIs and standard user interface controls of the underlying platform. The apps are fully native, they are just written with C#. (Disclosure: I work for Xamarin)
- danabramov 14y ago
  If you have read the article, you would have known Xamarin products expose native iOS and Android APIs. MonoTouch apps feel exactly the same as UIKit apps because they are UIKit apps. From my perspective, MonoTouch UIKit bindings are more convenient than original Objective C library because C# is nicer (think events, typed arrays and dictionaries, etc.)
- natfriedman 14y ago
  You have misunderstood. iOS and Android apps built using C# have access to 100% of the native API of the underlying platform. So all of the UI is fully native. Take a look at our API documentation on iOS, for example: http://iosapi.xamarin.com/?link=root%3a%2fMonoTouch-lib http://iosapi.xamarin.com/?link=root%3a%2fMonoTouch-lib You can see thousands of iOS APIs bound, including all of UIKit: http://iosapi.xamarin.com/?link=N%3aMonoTouch.UIKit http://iosapi.xamarin.com/?link=N%3aMonoTouch.UIKit
taumeson 14y ago
Obviously a bit one-sided (it's from Xamarin, after all) but I'm a big believer in C# and what it offers compared to what else is out there. I think the biggest weakness is dealing with another single-vendor-of-failure (in this case, Xamarin themselves) in order to cross-compile to Android/iPhone.
gte910h 14y ago
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 code, and can be hard/impossible to get new features working once you try to translate across the language barrier (mobile gets REALLY finicky about when X or Y is called, especially for things like animations)
- natfriedman 14y ago
  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 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-the-fourth-edition http://praeclarum.org/post/31799384896/icircuit-code-reuse-t... 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. And yet they average >70% code sharing. It should also be pointed out that these apps were written from scratch. In fact, Jon Lipsky didn't even know C# before he started writing TouchDraw (the first app I linked).
  - king_magic 14y ago
    Not all code is created equal. That 30% that needs to be rewritten for each device could be difficult to tune for each platform. Personally, I'd like to see some more information on what exactly was reused.
  - gte910h 14y ago
    Those charts need 3 wedges: Shared non-interop layer code, interop layer code, and non-shared code. If 50% of that green wedge is interop layer code, you see why this isn't good. Additionally, you really want "Time spent per area", which is very different from LOC in some cases. But thanks for showing real data for named projects. Mine is from some LOC counts on customer projects (and not directly sharable), and from Mono____ advocates in the Atlanta iOS group.
jordan0day 14y ago
As languages go, C# may be the ultimate "middle ground" because it really excels and providing a middling implementation of [your-favorite-language-feature]. That is, if you're a functional programming enthusiast, you can do a lot of functional programming in C#. Sure, it's often more painful than haskell or lisp or F#, but it's workable. If you're a dynamic programming enthusiast, C# has a perfectly workable (but ultimately unsatisfying) implementation of dynamic. Systems programmer? Mark your code as "unsafe" and twiddle bits to your hearts content! It's not as quick or necessarily easy as C, but it's there! Even its' OOP, which is C#'s "official" paradigm, is probably disappointing to smalltalk guys, but hey, it's better than Java, right?! It's not glamorous or flashy, it's a workhorse language. And at being a workhorse language, I'd say it really is one of "the best".
- nnq 14y ago
  Why is C#'s OOP disappointing to Smalltalk guys?
  - bigdubs 14y ago
    Well, off the top of my head C# doesn't support mixins or multiple inheritance. You can get around the lack of mixins with extension methods and tight scoping but it's messy.
    - SeanLuke 14y ago
      > Well, off the top of my head C# doesn't support mixins or multiple inheritance. I was not aware that Smalltalk provided either.
      - dfox 14y ago
        There are libraries that add both of these features at once (either by defining new (meta)metaclasses or by simulating same effect through simple copying of methods from base classes.) On the other hand, Smalltalkers are quite keen on adding new methods to almost any existing system class, so mixins are not often as useful. Also Smalltalk development often relies on IDEs that do pretty extensive code generation behind the scenes and I think that this image based development with no real source code to speak of, and lots of reflection based development tools, is more important aspect of Smalltalk than any OO features.
king_magic 14y ago
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.
  - 14y ago
Nitramp 14y ago
What is he comparing to? Arguments #2-#5 & #7 seem to apply to Java as well, and #6 just quotes an extremely lopsided benchmark exploiting one specific feature of their C# implementation. Most of the arguments would apply to Objective C too, I presume (though I haven't really used that outside of toying around). I'd personally expect we'll see a lot more JS for mobile apps: a terrible language compared to C#, but a very well understood UI layer (HTML).
- chc 14y ago
  I don't think each point is meant to show that it's better in that respect than every other competitor. I think it's meant to be sort of like those feature grids on software packaging, where some of the competitors may have some combination of the features, but only Our Product has the complete set.
deleted 14y ago
[deleted]
wyuenho 14y ago
Assuming all 8 points are valid. I still will not use MonoTouch on anything ever because it costs $999 apiece while everything else is free.
- georgemcbay 14y ago
  Same here. I'm not opposed to paying for quality tools even when free alternatives exist, but I'd pay like $99 for this, not $399 (or $999).
azakai 14y ago
> Their data shows that C# popularity grew by 2.3 percent in 2012, more than any other programming language during the same period. As many pointed out when that story came out, that datapoint is highly suspicious. There are plenty of smaller languages that have surely grown much more than that (it's easier to grow more when you are small). Also, the actual popularity is what really matters, not the increase. If C# increased 2.3% from 1000 to 1023, but say Java was at 1,000,000 and stayed there at 0% growth, then the conclusion is obvious. (Not saying those are the numbers, the point is that actual popularity trumps a few percent of growth in a year.) > What accounts for the growth of C# in 2012? Well, the launch of Windows 8 has probably played a role — C# remains the dominant language of third-party application development on Windows devices. Doubtful. Windows 8's launch has been a failure, even compared to Vista according to the latest figures. And is C# even the "dominant language" for Windows 8? It seems JavaScript might be just as important if not more so for Metro apps.
- rprasad 14y ago
  C# is a dominant language for indie games: Unity, and almost all games using the Unity engine; Magicka, Terraria, Breath of Death, Weapon of Choice, and Sol Survivor, which use the XNA framework; Eufloria, which was originally written in C# prior to the cross-platform release, AI War, which uses C# and Mono, and Bastion, which uses MonoGame.
  - azakai 14y ago
    Yeah, exactly, indie games would have been a much better example than Windows 8 in that article.
MichaelGG 14y ago
"Async support as a first-class feature" - that's actually a flaw. C#'s async implementation would be better served by having e.g. a generic monad system that allows async to be done in a library. Instead, it's another baked-in compiler feature, like C#'s duck typing and LINQ's query operators. Calling it "cutting-edge" is an exaggeration, too.
- rbanffy 14y ago
  > Calling it "cutting-edge" is an exaggeration, too. What is "cutting-edge" varies from person to person. Some people are easily impressed.
- kvb 14y ago
  It's not a flaw. Arguably it's worse than having a generic mechanism, but it's certainly not worse than having to use explicit callbacks, as in essentially all other popular languages (and previous versions of C#).
martinced 14y ago
Mobile development issue is not the language. It's the API. And how would using C# help me deal with the fragmentation issue ?
- migueldeicaza 14y ago
  It does not. And nobody claimed it did.
martinced 14y ago
I can't stress enough how I think being able to do SQL queries is a must have for cellpones. Because we all know all the top-selling iPhone / Android apps do ship with an embedded SQL DB right!?
erick23 14y ago
Read this article for me to waste time because a programmer that program in a programming language that dominates more he soon comes to post here trying to convince others to learn the same...
erick23 14y ago
after not ashamed to post an article saying that C# is the best language for developing mobile ... must have little shame .. I'm sure you still not programs Naive Code Android, HTML5 + CSS3 and other top mobile development languages

77 points by natfriedman 14y ago

While a bit of an aside, personally I find LINQ to have been a horrendous misstep in the evolution of the language. While the argument that it makes code more concise and easy to maintain holds in the small, once a project grows it becomes a terrible cancer -- everything becomes an amorphous blob of stuff, unintuitive, performance-disaster LINQ filters applied everywhere to bend it into shape.

sourc3 14y ago
Yes, but it's not specific to LINQ or MS or C#. If you give a tool to mediocre developers to make things easier they will use it right away. If you don't supervise its usage (how it fits into the architectural goals of the project you are on) you will end up with a mess. Anonymous methods, unnamed classes, try catch blocks are all examples of these type of tools that when used improperly will kill the system performance, code readability, maintainability and extensibility.
- corresation 14y ago
  Yes, but it's not specific to LINQ or MS or C# We are specifically talking about C#. LINQ was specifically held as one of the improvements to the language. I am not quite sure what your point is relative to that. There are shockingly few examples where LINQ is superior to alternatives. LINQ is the brute force technique of avoiding proper collections/algorithms.
  - taumeson 14y ago
    The point is relevant in relation to the fact that you held LINQ out as a misstep, but the reasons you cite can be applied to many features of many different languages.
    - weareconvo 14y ago
      Yes, but rather than actually arguing with his point, you are showing how it could also be used to criticize some other language features not in an attempt to prove him wrong, but rather to pander to anybody reading the argument who likes those language features.
  - abolibibelot 14y ago
    I don't understand. Are you saying that map, filter, reduce and al. on lazy sequences in functional languages are inferior to loops, or that Python list comprehensions and generators are inferior to loops? That's basically LINQ to objects. Maybe you're refering to LINQ-to-whatever (LINQ to SQL, etc.), a LINQ generalization where you can quote your expressions, rewrite the AST and emit something else (a very constrained kind of macros, if you will). MS is probably to blame here, but people keep conflating the two.
    - corresation 14y ago
      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 developers it would offend the sensibilities of construction, but somehow in LINQ-land all seems fine.
      - recursive 14y ago
        Most developers I know seem to prefer the loop version. I'm not sure what you mean by "sensibilities of construction", but I'm a big advocate of LINQ. If your concern is that certain linq calls iterate an entire sequence, that could apply to all kinds of scenarios that have nothing to do with LINQ like string concatenation. You should always be aware of the performance characteristics of methods you are calling. LINQ is not special in that regard.
      - NateDad 14y ago
        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 readable. It makes it easier to find bugs and easier to understand by someone else (even if someone else is you, 6 months down the road). It also just takes a lot less time to write.
gjulianm 14y ago
Could you give an example of that? Personally, I like LINQ a lot. I don't use it very much in my code (and usually it's for things like light filter or ordering), but it has these little things that save a lot of time.
- taumeson 14y ago
  Be careful what you ask for -- you have to admit that it is possible to create some horrendous "code" with Linq. Also I have a hunch that OP is thinking of L2S or Linq2Entities or somesuch.
  - gjulianm 14y ago
    Well, horrendous code can be created with anything: LINQ, C#, Objective-C... But yes, such easy-to-use tools like LINQ are easily overused and you end up with real monstrous code.
dos1 14y ago
LINQ is just another tool in the toolbox. Like any tool it has the potential for misuse. Ultimately the skill of the person wielding the tool will decide whether the outcome is good or bad. It sounds like you've mostly seen the bad. In the right hands, LINQ can make things more readable and concise. Take another example, anonymous functions in Javascript. I've seen plenty of tremendously horrible JS code bases that were just a deep series of nested anonymous functions. Almost impossible to debug or maintain. However, when used appropriately the anonymous function is very powerful and can make certain things much easier.
joelangeway 14y ago
This is a fundamental place where the worlds of C# and Java differ. Where the Java world would say, "developers might misuse this, better not have it in the language," the C# world says, "developers could really use this, better put it in the language."
- meaty 14y ago
  And if you've worked on a large project with a lot of cats to herd for both platforms, you will appreciate java very quickly.
  - JanJansen 14y ago
    I work on a pretty huge C# code base. Use of LINQ is the least of it's problems. If anything I'd say one problem is people not knowing about things like lambda expressions, linq, generics or whatever. It can really make code harder to parse when it's written in ways that don't take advantage of the full power of the platform.
    - ams6110 14y ago
      How much of that C# code pre-dates the availablilty of those features?
      - JanJansen 14y ago
        Some of the code was certainly written before those features was available, especially some C# 4 features. I'm sure someone might look at my code someday and wonder why I didn't use async and await. I'm talking about code written today though.
    - meaty 14y ago
      Yes until we get to: List<List<Tuple<int, Dictionary<string, object>, string>>>
      - MichaelGG 14y ago
meaty 14y ago
This times a million. The amount of shit I have to deal with where people have used it in criminal ways is unreal. Fine examples: .ToList() materialization multiple times in a call graph. Ok so the thread is eating 200mb of ram?!?!?! Generic method hell. complete lack of understanding regarding IEnumerable, ICollection, IList etc. O(log N) that doesn't go bang until you stick a production dataset in it. The specification pattern - bottled rape is the only way I can quantify this. Sounds great until you have 2500 specifications and are stacking them 20 deep and your ORM decides it has had enough of clauses (EF4 bug). My favourite: junior developer turns up and says "I wrote this awesome linq query - come and look!". Get there: all of the above.
- taumeson 14y ago
  These are great concrete examples that are very Linq specific. I cringed reading a few of them. The .ToList() materialization can easily be avoided by using a little skill, but the realities of late binding that don't show up until you hit production -- this can catch anybody.
gigantor 14y ago
You don't even have to use LINQ at all with C#, it's an extension library and not one that needs to be referenced or is even included as a default namespace. LINQ is very convenient to use on in memory objects where there's no noticable performance hits. Even LINQ->SQL produces somewhat optimized SQL. How else would you bend data into shape without an ORM layer? Writing custom stored procedures, adding a whole bunch of new service methods, or manipulating data tables directly? This 'cancer' is simply a data layer; if you use proper design patterns and seperate your layers correctly, you can surgically remove this tumour and replace it with another ORM.
- corresation 14y ago
  LINQ is indeed optional, but this discussion is about the evolution of the language, with LINQ being held as an improvement. And because it is new and shiny, C# code across the globe quickly became infected with it. Your comment on "where there is no noticeable performance hits" strikes a chord because when first used there are no noticeable performance hits. But then that application grows and scales and suddenly it is death by a million paper cuts, thousands of grossly inefficient set operations devastating performance. That's aside from the fact that LINQ is often a short-circuit saving from having to think about appropriate algorithms of object-methods to deal with the likely uses.
kvb 14y ago
Can you expand on what exactly you mean by LINQ? Do you mean the .NET library support (extension methods on IEnumerable/IQueryable)? Do you mean the language features added to C# (anonymous types, expression trees, nicer lambdas, query syntax)? The language features, with the possible exception of query syntax, seem like hugely beneficial additions, to me.
pbz 14y ago
We need to separate LINQ, the C# language feature, from the library implementation, LINQ to SQL or Entity Framework. The later does tend to cause issue because it offers a rather leaky abstraction over your database and poor performance. But it doesn't have to be this way. Case in point BLToolkit, a lesser known database access library that uses LINQ. It is light and almost as fast as native access. Very close to Dapper in performance or pretty much the same in performance if you compile your expression trees, but of course you have type-safety. Of course it doesn't have all the bells and whistles of L2S or EF, but you gain speed and simplicity.
SideburnsOfDoom 14y ago
> I find LINQ to have been a horrendous misstep ... grows it becomes a terrible cancer -- everything becomes an amorphous blob of stuff, unintuitive, performance-disaster LINQ filters I couldn't agree less. Any language construct can be abused, but LINQ is not particularly susceptible to abuse, unless you try very hard.
- corresation 14y ago
  LINQ is from the outset designed for abuse, and you don't have to try hard whatsoever.
  - SideburnsOfDoom 14y ago
    That hasn't been my experience, I'm glad to say. And given the amount of c# code I've worked on already, it's unlikely to ever be.

RyanZAG 14y ago

Please don't actually do this - or if you do this, use the C# code only for the backend, and write the UI code natively for each platform. Nothing is worse than a 'not quire right' 'seems almost the same but isnt' UI.

dos1 14y ago
As I understand it the mobile SDKs Xamarin releases use the native UI widgets for each platform - allowing you to get native look and feel with one code base. (I may be wrong on this, but I thought this was one of their major selling points. However, never having used the SDKs I don't know how well it works in practice)
segphault 14y ago
One of the major advantages of Xamarin's approach is that the Xamarin frameworks expose access to all of the native APIs and standard user interface controls of the underlying platform. The apps are fully native, they are just written with C#. (Disclosure: I work for Xamarin)
danabramov 14y ago
If you have read the article, you would have known Xamarin products expose native iOS and Android APIs. MonoTouch apps feel exactly the same as UIKit apps because they are UIKit apps. From my perspective, MonoTouch UIKit bindings are more convenient than original Objective C library because C# is nicer (think events, typed arrays and dictionaries, etc.)
natfriedman 14y ago
You have misunderstood. iOS and Android apps built using C# have access to 100% of the native API of the underlying platform. So all of the UI is fully native. Take a look at our API documentation on iOS, for example: http://iosapi.xamarin.com/?link=root%3a%2fMonoTouch-lib http://iosapi.xamarin.com/?link=root%3a%2fMonoTouch-lib You can see thousands of iOS APIs bound, including all of UIKit: http://iosapi.xamarin.com/?link=N%3aMonoTouch.UIKit http://iosapi.xamarin.com/?link=N%3aMonoTouch.UIKit

taumeson 14y ago

Obviously a bit one-sided (it's from Xamarin, after all) but I'm a big believer in C# and what it offers compared to what else is out there. I think the biggest weakness is dealing with another single-vendor-of-failure (in this case, Xamarin themselves) in order to cross-compile to Android/iPhone.

gte910h 14y ago

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 code, and can be hard/impossible to get new features working once you try to translate across the language barrier (mobile gets REALLY finicky about when X or Y is called, especially for things like animations)

natfriedman 14y ago
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 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-the-fourth-edition http://praeclarum.org/post/31799384896/icircuit-code-reuse-t... 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. And yet they average >70% code sharing. It should also be pointed out that these apps were written from scratch. In fact, Jon Lipsky didn't even know C# before he started writing TouchDraw (the first app I linked).
- king_magic 14y ago
  Not all code is created equal. That 30% that needs to be rewritten for each device could be difficult to tune for each platform. Personally, I'd like to see some more information on what exactly was reused.
- gte910h 14y ago
  Those charts need 3 wedges: Shared non-interop layer code, interop layer code, and non-shared code. If 50% of that green wedge is interop layer code, you see why this isn't good. Additionally, you really want "Time spent per area", which is very different from LOC in some cases. But thanks for showing real data for named projects. Mine is from some LOC counts on customer projects (and not directly sharable), and from Mono____ advocates in the Atlanta iOS group.

jordan0day 14y ago

As languages go, C# may be the ultimate "middle ground" because it really excels and providing a middling implementation of [your-favorite-language-feature]. That is, if you're a functional programming enthusiast, you can do a lot of functional programming in C#. Sure, it's often more painful than haskell or lisp or F#, but it's workable. If you're a dynamic programming enthusiast, C# has a perfectly workable (but ultimately unsatisfying) implementation of dynamic. Systems programmer? Mark your code as "unsafe" and twiddle bits to your hearts content! It's not as quick or necessarily easy as C, but it's there! Even its' OOP, which is C#'s "official" paradigm, is probably disappointing to smalltalk guys, but hey, it's better than Java, right?! It's not glamorous or flashy, it's a workhorse language. And at being a workhorse language, I'd say it really is one of "the best".

nnq 14y ago
Why is C#'s OOP disappointing to Smalltalk guys?
- bigdubs 14y ago
  Well, off the top of my head C# doesn't support mixins or multiple inheritance. You can get around the lack of mixins with extension methods and tight scoping but it's messy.
  - SeanLuke 14y ago
    > Well, off the top of my head C# doesn't support mixins or multiple inheritance. I was not aware that Smalltalk provided either.
    - dfox 14y ago
      There are libraries that add both of these features at once (either by defining new (meta)metaclasses or by simulating same effect through simple copying of methods from base classes.) On the other hand, Smalltalkers are quite keen on adding new methods to almost any existing system class, so mixins are not often as useful. Also Smalltalk development often relies on IDEs that do pretty extensive code generation behind the scenes and I think that this image based development with no real source code to speak of, and lots of reflection based development tools, is more important aspect of Smalltalk than any OO features.

king_magic 14y ago

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.
- 14y ago

Nitramp 14y ago

What is he comparing to? Arguments #2-#5 & #7 seem to apply to Java as well, and #6 just quotes an extremely lopsided benchmark exploiting one specific feature of their C# implementation. Most of the arguments would apply to Objective C too, I presume (though I haven't really used that outside of toying around). I'd personally expect we'll see a lot more JS for mobile apps: a terrible language compared to C#, but a very well understood UI layer (HTML).

chc 14y ago
I don't think each point is meant to show that it's better in that respect than every other competitor. I think it's meant to be sort of like those feature grids on software packaging, where some of the competitors may have some combination of the features, but only Our Product has the complete set.

deleted 14y ago

[deleted]

wyuenho 14y ago

Assuming all 8 points are valid. I still will not use MonoTouch on anything ever because it costs $999 apiece while everything else is free.

georgemcbay 14y ago
Same here. I'm not opposed to paying for quality tools even when free alternatives exist, but I'd pay like $99 for this, not $399 (or $999).

azakai 14y ago

> Their data shows that C# popularity grew by 2.3 percent in 2012, more than any other programming language during the same period. As many pointed out when that story came out, that datapoint is highly suspicious. There are plenty of smaller languages that have surely grown much more than that (it's easier to grow more when you are small). Also, the actual popularity is what really matters, not the increase. If C# increased 2.3% from 1000 to 1023, but say Java was at 1,000,000 and stayed there at 0% growth, then the conclusion is obvious. (Not saying those are the numbers, the point is that actual popularity trumps a few percent of growth in a year.) > What accounts for the growth of C# in 2012? Well, the launch of Windows 8 has probably played a role — C# remains the dominant language of third-party application development on Windows devices. Doubtful. Windows 8's launch has been a failure, even compared to Vista according to the latest figures. And is C# even the "dominant language" for Windows 8? It seems JavaScript might be just as important if not more so for Metro apps.

rprasad 14y ago
C# is a dominant language for indie games: Unity, and almost all games using the Unity engine; Magicka, Terraria, Breath of Death, Weapon of Choice, and Sol Survivor, which use the XNA framework; Eufloria, which was originally written in C# prior to the cross-platform release, AI War, which uses C# and Mono, and Bastion, which uses MonoGame.
- azakai 14y ago
  Yeah, exactly, indie games would have been a much better example than Windows 8 in that article.

MichaelGG 14y ago

"Async support as a first-class feature" - that's actually a flaw. C#'s async implementation would be better served by having e.g. a generic monad system that allows async to be done in a library. Instead, it's another baked-in compiler feature, like C#'s duck typing and LINQ's query operators. Calling it "cutting-edge" is an exaggeration, too.

rbanffy 14y ago
> Calling it "cutting-edge" is an exaggeration, too. What is "cutting-edge" varies from person to person. Some people are easily impressed.
kvb 14y ago
It's not a flaw. Arguably it's worse than having a generic mechanism, but it's certainly not worse than having to use explicit callbacks, as in essentially all other popular languages (and previous versions of C#).

martinced 14y ago

Mobile development issue is not the language. It's the API. And how would using C# help me deal with the fragmentation issue ?

migueldeicaza 14y ago
It does not. And nobody claimed it did.

martinced 14y ago

I can't stress enough how I think being able to do SQL queries is a must have for cellpones. Because we all know all the top-selling iPhone / Android apps do ship with an embedded SQL DB right!?

erick23 14y ago

Read this article for me to waste time because a programmer that program in a programming language that dominates more he soon comes to post here trying to convince others to learn the same...

erick23 14y ago

after not ashamed to post an article saying that C# is the best language for developing mobile ... must have little shame .. I'm sure you still not programs Naive Code Android, HTML5 + CSS3 and other top mobile development languages