Think of it.
Think of it as Microsoft having a Visual Basic mindset here which is why the Community Edition of Visual Studio is included. I have absolutely no idea if/why that would work, but Hell, who does know?
Microsoft will make Xamarin tools and code, which enable compilation of Mac, Android and iOS applications using C#, free and open source, said corporate VP Scott Guthrie at the company's Build conference under way in San Francisco. Xamarin's origins are with Mono, a project created by Miguel de Icaza as an open source and …
As an hobbyist Android developer, I could never justify the cost of the tools related to porting software between platforms. I can only handle doing so much in Java before I just lose all will to live.
This does make me wonder, will Microsoft resurrect XNA, or perhaps embrace (in a positive way) MonoGame?
You do realize that Java (especially Java 8) and C# are pretty much identical from language standpoint right? So not sure why one would be viewed with distaste and the other not. Now you may want to argue about the JVM vs the CLR, but neither of those are found on Android/iOS.
In anycase, if you want to do crossplatform apps using Java checkout Codenameone.
yes, C# was originally J++, MS idea of how Java should develop. I've got a copy somewhere. Sun didn't like that idea. So MS morphed it as C#, which might be one of the last decent bit of development they did. VS + C# is certainly more pleasant to develop than Eclipse or NetBeans + Java.
Linux and Linux tools let you dev for Android for free, it's essentially writing in Java. You also can develop Java that runs fine on Mac OS X, Windows, Linux on Linux Free. I've not tried mono for developing C# on Linux, I write any c# I write on Windows, but not since early 2015. I'm abandoning windows for lack of a coherent version now that XP is nearly gone and Win7 is harder to get now. I have no HW less than 9 years old running windows. All the newer kit runs Linux.
To people who say "Java is just the same as C#": that might have been true ten or fifteen years ago, but while Java stagnated the language, and concentrated on bloating the standard library, C# has improved the core language, year after year.
It's not the big-name fatures like LINQ or async, but rather the small things, like 'var', that make life so much smoother for developers, especially when so many libraries depend on generics, and so many classes have descriptive, but long-winded names. Compare these two functionally-identical snippets:
Java WhizzoContainerWrapper<ComplicatedIndexType, BlobWithUnexpectedBehaviours> c = new WhizzoContainerWrapper<ComplicatedIndexType, BlobWithUnexpectedBehaviours>();
APIThing.StatusEnumeration s = api.callMethod();
C# var c = new WhizzoContainerWrapper< ComplicatedIndexType, BlobWithUnexpectedBehaviours>();
var s = api.callMethod();
This isn't dynamic typing: c and s have the same types in both examples. The difference is that the C# compiler writers realised a long time ago that the compiler usually knows, or can infer, the type of pretty much any variable in a piece of code, so there's not much point in asking the programmer to remember it. (C++11's repurposing of the auto keyword does the same thing)
Basically, C# is full of handy stuff like this; Java isn't.
Funny, I loved C# until it started adding the new features you talk about as the great advances. LINQ and var enable much of the easy-to-write-but-nearly-impossible-to-read code I see turning up on github. C# has taken many steps towards coolness-over-maintainability in recent years.
async, now, that's a different matter. Pure awesomeness. So of course people combine that with LINQ to, yes, write more unreadable, barely-maintainable code.
Sorry, just not impressed with the recent "advances" in C#.
Some LINQ-expressions can indeed become extremely cryptic.
But looking at my colleagues' code, I must say that LINQ have made our code much more maintainable.
Do you really shun:
var sub = Subfields.FirstOrDefault(s => s.Subfield == subfield);
when the alternative is this old-school piece of code:
Subfield sub = null;
foreach (var s in Subfields)
if (s.Subfield == subfield)
sub = s;
I hope I never have to work in a development language where I cannot simplify that foreach in a similar way as LINQ allows. I think I'd rather start selling ice cubes on the north pole first or cut off one of my toes with a pair of rusty pliers.
C# is fine if you want to work on windows, but proposing C# for cross platform work is misguided.
Both typenames are messy and both declarations allocate memory on the heap, being a little shorter is good but lets face it, it's the same pig with different lipstick.
C++11 auto is part of a *cohesive* set of features, which eases things like perfect function forwarding and allow concurrent code to be written more easily and cleanly.
Var lets you autocomplete a few less chars, which is meh especially in the land of intelisense or whatever Microsoft are calling ctags these days.
C# is perfectly capable of running on other platforms. Don't confuse C#, the language, with Microsoft .Net, the class library for Windows applications. There is a portable subset of .Net, the PCL, which I have used to run the same tools on MacOS, Linux and Windows. I'd rather use C# than python or Java for middleware. Mono/Xamarin has provided a very solid cross-platform runtime for C# - people only seem to remember that the first releases of Mono were slow, but frankly, I remember the first JVMs, and they weren't too hot either. Time passes, software improves. I don't imagine there will be much difference in performance between runtime performance of C# on Linux and C# on Windows in a year or so.
(If you really need speed, you can compile C# right down to native machine-code if needed - Microsoft's Windows10 app store does this for you on Windows: you submit a C# CIL app, but the customer receives an optimised, native ARM or x86 binary when they download)
If I need high performance, I'll always turn to C/C++, but there are very, very few times when anyone needs the highest-possible performance, and it's only ever in very small parts of the code. I've about 20 years experience with C++, and I like the language a lot, but I would prefer C# for anything with a UI, or anything that interacts with a web-based backend. It's about choosing the proper tool for the job: the right tools make work faster.
Incidentally, you might look at the C++11 spec again: the new use of the 'auto' keyword does not stack-allocate (although that was its original meaning in C): when used on its own in declarations it now means nothing more than "compiler, please work out the correct type based on the rvalue". In fact, the default object-allocator in C++ has been to use heap allocation for a very long time. This is one fundamental difference between how C99 and C++ work, and it's one that many C++ users are completely unaware of.
Fundamentally, though, I don't buy into the "language X is faster, therefore better" argument. It's more true to simply say that you're buying runtime performance with engineering effort - the languages that produce faster execution demand more effort from developers. Sometimes that extra effort isn't worth it, as sometimes it obscures the purpose of the code, and allows bugs to creep in more easily. After all, engineering is about making things as efficient as they need to be, not as efficient as humanly possible.
I'm a big believer in Dijkstra's maxim that "premature optimisation is the root of all evil". I write my code with clarity and maintainability as the overriding priorities. Once I've got it functionally correct, I analyse the performance, and only then do I optimise. I've been programming long enough to realise that using a good algorithm will beats any amount of runtime speed-boost on a bad one, and also that where I think the bottleneck might be when I'm writing the code, is rarely where it turns out to be when the users get to run it...
Hmmmm code completion in any IDE will reduce the amount of actual typing to the same in either case, also the C# approach may discourage good practices such as working to interfaces instead of fixed/concrete typing. Some things are a relative pain in Java e.g. no implicit accessors
Has MS got one or are they just doing anything they take a fancy to this year?
MS SQL on Linux
Their own Linux for Cloud Switches
Ubuntu subsystem instead of ancient MS Services For Unix
Various other Visual studio announcements (two others anyway for Linux, though I'd only use VS for developing of Windows, but after nearly 20 years I've stopped. 1996-2014).
Yah, I remember seeing Xamarin demoed at re:Invent, and for simplistic UI apps, it made a lot of sense. But then the price tag was something like $1,000 USD year per developer per year for businesses, and there was no way I could see justifying that to my fearless leaders. There's no way to make everybody happy with this sort of acquisition, but I hope that they will throw out credits to Azure or free MSDN subscription extensions or something as a consolation prize.
No surprise when you're a small company that actually fully develops a complex product (instead of selling someone else code) you need paying customers to survive. If you're a company making a lot of money somewhere else, you can try the open source way, if you're lucky you can also find naïve developers giving away their hard work for free... and you'll still make the money adding just the code to support your expensive services...
If I want to do cross platform development I can use Html 5 for most things. I can use Cordova and AngularJS to build and package an app on Windows, IOS and Android using a single set of code and still have access to the underlying OS.
I also get a website out of the deal.
Why would I choose C# to do this? Especially when I still have to buy a Mac to compile IOS code in this circumstance?
Not really. I'm a WPF developer by trade and have written several Windows Phone and Store apps. Having done this I've had to pretty much re-write the front end of the app to take into account different form-factor layouts.
Different form-factor layouts hare not fun to write in XAML. If you're looking to spend all your time writing different screens for different size views, go with Xamarin. if you want to write one app and then apply a bit of styling to manage different layout sizes, you'll go down the HTML 5 path and use something like AngularJS.They're embarrassingly easy to write in HTML.
Adding in employability: I know of nobody that writes all their mobile apps in C# or Xamarin. Most business doing LOB apps have gone down HTML 5 (no installs, no having to learn a device specific language). If you're writing apps for external customers your situation may be entirely different, but at that point I'd expect you to have experts who will write the app in app-specific languages where you have to or give you a Cordova app.
So, I'm going to say it again. Pointless.
"Different form-factor layouts hare not fun to write in XAML. "
I'll admit I've done no WPF C# development, but UWP XAML uses size-triggered Visual States that allow you to do this really easily. (it's pretty much the same mechanism as CSS's fluid stylesheets).
However, I'll happily concede a variation of your point: different form-factor layouts are not fun to design. Keeping a non-trivial view coherent at the three or four window sizes needed is considerably more work than implementing the thing.
"Because how else are you going to get their entire contact book, phone imei number, currently installed apps, bank details and location info?"
Assuming that's a reply to my comment
I think you're confusing developer intent with consumer choice. Why do consumers prefer native apps if HTML 5 is so finger likkin good?
The answer's because it isn't obviously but so many developers and (more importantly) project stakeholders don't see this and keep wasting money on one size fits all solutions for applications aimed at a long term user base.
Nobody cares about UX for a price comparison site if it gives them a good deal after 10 minutes use in a year.
An enterprise application with a 1000+ users punching data 7 hours a day on the other hand...
You may be looking in the wrong places. We've standardised on Xamarin allowing us to use a pretty huge developer base to create native cross-platform Apps.
Xamarin's allowed us to do things that simply wouldn't have been practical any other way and to create products that are unique in their market. So from my perspective, far from being pointless, it's the most significant thing to happen since Microsoft launched .NET.
Well I'm a small developer and I paid for a licence - not the IOS but Android and I've been writing code since VS1 - which morphed into VS6 allegedly to keep track with office versions. 10 years ago I was very impressed by what Mr Guthrie did to revitalise web development with c# (and I speak as an old VB 1-->6 developer).
And you know what - I ain't pissed off at all. Were I female I would be hounding Scott and saying: "I want to have your babies". And I still have about £400 of the £1000 it cost me for the licence outstanding. You look at the future - not the past. And this future looks like it's promises exceeded the stories of the past.
Go Go Go Scott
This is one way to get some apps for Windows devices. Nobody is doing it but if they can get their own Windows developers writing apps for iOS and Android then they'll also be providing apps for Windows too.
Let's see how they get their Windows developers to write iOS and Android apps.
Devil's in the detail. It appears not every VS user gets Xamarin, despite the announcements and slides and everything else. Pulled the installer down to read the T&Cs and basically Community Edition users get a free-for-all, those VS users with Enterprise and Professional with an MSDN subscription get a free-for-all, but those organisations who Xamarin define as an enterprise who bought Enterprise or Professional without MSDN don't actually get a free-for-all: they're constrained to limited use (open source and education only).
Unless of course T&C's are yet to be updated. The implication though seemed to be that everything was available now from what I can tell from blog posts and everything else I've seen.
Biting the hand that feeds IT © 1998–2022