Why C# is the best language for mobile development
blog.xamarin.com
Why C# is the best language for mobile development
1–10 of 125 posts
Re: Why C# is the best language for mobile development
#2While 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.
Re: Why C# is the best language for mobile development
#3While 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.
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.
Re: Why C# is the best language for mobile development
#4While 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.
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 performa…
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.
Re: Why C# is the best language for mobile development
#5While 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.
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.
Re: Why C# is the best language for mobile development
#6While 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.
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.
Re: Why C# is the best language for mobile development
#7Please 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.
Re: Why C# is the best language for mobile development
#8Please 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.
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)
Re: Why C# is the best language for mobile development
#9Obviously 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.
Re: Why C# is the best language for mobile development
#10The 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)