This is not surprising at all. I've been wondering if/when Microsoft would just buy Xamarin. Perhaps this is the first step?
This scenario leads to the following: C# wins as the "cross platform mobile language," window phone is the default first environment for cross platform apps, and as developers we get an elegant "write once* run everywhere" that's based on c#.
The asterisk: once plus ui customizations on each platform, so more like write (1 + (.1 * num_non_wp8_platforms)) times
Unfortunately, though I think these moves would make ms a dominating player in mobile and web for decades, I doubt they'll do this.
If they did that, they would very likely, as you say, dominate mobile for a long time. Nothing is more frustrating than jumping between android XML, Java, and eclipse (or whatever) and XCode, OBJ-C, and the iOS UI, while trying to not go insane.
I think this because I believe that platform-level ui look and feel differences are going to be with us for a long time.
I think you can standardize "what it does" and "how it does it", but you'll have to keep platform specific "how to invoke" and "how it looks" for a long time.
Maybe a MVCP paradigm is what we need, where the controller is split into common controller and platform controller
It looks like Xamarin uses .AXML for Android (maybe a XAML flavor) but has to adhere to Interface Builder for iOS (http://docs.xamarin.com/guides/cross-platform/application_fu..., specifically the Visual Designer section). XAML likely won't gain any traction on those platforms though due to NiH on all sides. HTML/CSS is likely as close as we get for now but that isn't a "native view" in any of the platforms mentioned.
Xamarin's Android interface builder is actually remarkably decent.
I couldn't easily associate .xml with the designer in VS since everyone uses .xml.
Because of continued platform fragmentation WORA has been, is, and always will be a pipe-dream. People have been attempting to create WORA technologies since the beginning of time and they have all failed.
The nice thing about Xamarin's model is your UI code uses native constructs, allowing for the best possible, most natural (to the user) experience. But you get to stick with one language (if you want) and your core code is very portable.
[1] http://ceklog.kindel.com/2013/02/21/james-gosling-screwed-us...
Nice straw-man. Unity 3D does WORA very, very well. It's been used successfully for cross-platform development by many shipped products. To my initial astonishment, all built on Mono/C#.
This doesn't absolve the developer from QA for the targeted platforms, and this is where fragmentation is the killer IMO. That said, Unity provides a huge amount of leverage and tooling in support of seamless cross-platform deployment.
Unity is also notoriously painful when it comes to 2D UI style work as well, which is why there's a tools ecosystem around it just to deal with that problem.
Saying that the apps generated don't look "native" doesn't support the assertion that WORA is a "failure". Doubly so considering the ubiquity of Java.
Otherwise it sucks.
Well the web doesn't have a native UI. But iOS and Android DO have one.
While the applications are other way around. New customers do not want to spend more than a minute to get familized with the interface. Moreover, your custom UI interface will be competing with Apple/Google designer's budget.
Not true. Unity engine is made using c/c++. You control those components using Mono/c#, which is totally different.
If Unity was made in Mono, it would be 1 frame per second. We made lots of experiments using mono for doing 3d and animation in our company as it is fast to program with, but with all the market machine of MS, c# is not designed for some things, but some people just can't stop trying to use the only hammer they have.
You mean QML?
Much more likely; Xamarin is acquired, monodevelop development halts and the Xamarin offerings become VS pro features, giving Microsoft a foot hold in the mobile space (which they desperately need) and maintain VS revenue.
It's arguably not a terrible direction for things to go... If, unlike me, you dont passionately despise VS. :p
The irony is, they'll give you $200 of swag at every event to grow their ecosystem 1 dev at a time, but they won't open source to grow their ecosystem 10x.
And instead of reinventing libraries like they used to they started to embrace some open source libraries like modernizr, jQuery, Bootstrap, and Json.NET.
And to promote their Windows Azure initiative they released a platform installer that allows you to install open source products like PHP, MySQL, and Wordpress on your Windows box with just a few clicks.
Microsoft is a big company with many different clashing cultures. As a result some divisions shower you with software goodness and others with patents and lawyers.
Which I commented on here: https://news.ycombinator.com/item?id=6727423
At best, they are under a free commercial license. They are not available under FOSS licenses.
http://aspnetwebstack.codeplex.com/license
http://entityframework.codeplex.com/license
http://weblogs.asp.net/scottgu/archive/2012/03/27/asp-net-mv...
I suggest updating your comment.
I'm glad to see they're moving more of these technologies over to truly FOSS.
Which pieces are on which license if you get it from which place?
I'll update the linked comment with that blog post -- I seriously scoured the other press release and couldn't find which license these were released under.
The licences of the projects (EntityFramework, ASP.NET) are opensource, but the licence only applies to the sources.
Nuget packages, however, are binary. And they might have a different licence. So to avoid the latter, you just need to compile the sources yourself instead of using the Nuget packages.
EDIT: actually, the last paragraph is not true anymore, thanks to this: http://blogs.msdn.com/b/dotnet/archive/2013/11/13/pcl-and-ne...
Another problem is that they don't run their open source projects in an open manner. Contributing requires a CLA and a signature from your boss. Issues and planning are often behind closed doors, but that seems to be slowing changing too (see KatanaProject / signalr).
If they really wanted to grow their ecosystem 10x, and give windows phone the possibility of a fighting chance, making VS Pro free would be the required.
EDIT: Apparently they haven't updated their nuget packages and some of these components truly are licensed under FOSS, per: http://weblogs.asp.net/scottgu/archive/2012/03/27/asp-net-mv... and https://news.ycombinator.com/user?id=adolfojp
The license that used to cover all of these, and that may still cover some of the components is this:
http://www.microsoft.com/web/webpi/eula/aspnetcomponent_rtw_...
I like to think of things as copyright, copyleft and copy middle. This looks like an entirely new beast: copyquagmire
A few pieces of the license:
* For any Distributable Code you distribute, you must · add significant primary functionality to it in your programs; ... · indemnify, defend, and hold harmless Microsoft from any claims, including attorneys’ fees, related to the distribution or use of your programs. *
So, if you redistribute these libraries, you agree to be on the hook for MS legal bills.
* Distribution Restrictions. You may not · modify or distribute the source code of any Distributable Code so that any part of it becomes subject to an Excluded License. An Excluded License is one that requires, as a condition of use, modification or distribution, that
· the code be disclosed or distributed in source code form; or
· others have the right to modify it. *
So it is anti-GPL. I personally think this is a good thing, I hate the copy-virus in the GPL. Maybe this is even a poison pill that invalidates GPL code in a project, thereby protecting you from inadvertently letting your code fall under GPL (which I would consider to be a good thing). Whichever clause wins, this is a quagmire.
Lets continue.
* you must comply with any technical limitations in the software that only allow you to use it in certain ways. You may not
· work around any technical limitations in the software;
· reverse engineer, decompile or disassemble the software, except and only to the extent that applicable law expressly permits, despite this limitation;
· publish the software for others to copy;
· rent, lease or lend the software;
· transfer the software or this agreement to any third party; or
· use the software for commercial software hosting services. *
So, basically you can't modify it or change it.
* BACKUP COPY. You may make one backup copy of the software. You may use it only to reinstall the software. *
Why the hell is this in an "open source" license?
This isn't an open source license, this is a free commercial license with a bit of lipstick, a wink, and a head-fake towards openness.
Thankfully, it seems other divisions of msft (F# for instance) use the Apache License V2 which is in fact a copy-middle free as in beer and freedom open source license.
Microsoft's open source software repository is codeplex. If you go to codeplex you'll find out that the projects that you mention are Apache 2 licensed too.
I don't think it is unreasonable to believe that the license in the package manager operated by the company who is granting the license would be accurate.
Oh wait, you want to make modifications, and then sue people who then dare to copy, modify or redistribute your version? Pity you can't use that GPL compatible Apache 2 licensed code. Better use that non-compliant free commercial license instead.
To me, perfect licences are: BSD, MIT, Apache2, WTFPL
I like copy middle far far better than copy right or copy left.
My entire comment was about how bad the MS free commercial license was and how I wished it was a real FOSS license. There was a tangent in there about hating the copy-virus of the GPL, but that was an aside.
It takes away from your main arguments and distracts.
If Microsoft does buy Xamarin, I'd like the following to happen:
Xamarin and TestCloud become much cheaper. More attention given to the IDE - fix the hell out of it Better documentation
I also think it's a fantastic way of encouraging developers to work on WP 8. The less code you need to port from Objective-C/Java to .net, the better.
I predict Xamarin Build Cloud.
Devs who want to make WP apps on Mac or Linux have exactly thr same problem, just the other way around. A well integrated, "it just works" cross-platform build solution, straight from the IDE, has a lot of market value and fits perfectly in Xamarin's portfolio, Microsoft or not.
C# is a pretty weak language[1], and .NET is layers of bad design choices (both of these problems stem from a aggressive OO design methodology combined with poor API taste + a policy of "never break".
Not only that, Microsoft is a monopolist by character, and an unpleasant competitor. It would be a disaster for the world if they regained dominance (much like other companies, but MS brings a particularly domineering flavor).
[1] It's adequate. It gets the job done, adequately. It doesn't shine except in being adequate. I would rather use pretty much any open source language than a .NET one.
That not being an option, C# is decently close to python in expressiveness, certainly better than the other two, and in my appraisal actually a pretty nice language.
Apart from that, why is C# a weak language? I think it shines in features: dynamic typing, code by contracts, runtime code generation (you can generate assemblies in execution time with System.Reflection.Emit), LINQ... you can even use it as a functional programming language. I wouldn't say C# is pretty weak.
I suspect it will still lead to many lowest common denominator apps, but it's not like Android doesn't suffer from iOS-portitis and hordes of shoddy apps for other reasons, anyway.
So legitimate question, is the CLR better than the JVM at cross language support and if so what makes it better?
Yes in the early days, because JVM was initially designed just for Java and many bytecodes are directly related to Java semantics.
Meaning any language that targets the JVM has to adapt their semantics to Java semantics at the bytecode level, hence the tricks mapping closures to anonymous classes as one example from many.
This got better with the introduction of new bytecodes in Java 7 and the upcoming Java 8, but it is still a Java VM at heart.
The CLR was designed as language agnostic, meaning its design had to support a good implementation of VB, C# and C++ on day one, alongside other languages from Microsoft partners like Eiffel and COBOL as two possible examples.
There is inclusive a .NET ABI for interoperability between languages, CLS (Common Language Specification).
So the bytecode is much more generic and more low level than the JVM bytecode is.
Then thanks to the work done on IronPython and IronRuby, it got the DLR part with allows for better performance of dynamic languages implementations. Since initially CLR was mostly targeted for strong typed languages.
Nowadays both platforms are quite similar in terms of language support.
I can count on one hand the programs written in C# that I use in Linux, and those projects have to explicitly support Linux. Compared to JVM targeting projects where the experience is typically "Linux? Well shit, I don't know. Here's the jar, try it out. Oh, it works? Great!"
If I were writing a new language and had to pick one to target, from a technical perspective the CLR would seem to be the clear choice. But I don't think that is the perspective most people are coming from.
1) On top of the JVM we've got Scala, Clojure, JRuby, Jython, Groovy, Fantom, very successful, very active, with big communities.
2) On top of the CLR, we've got IronRuby dead, IronPython dead, Clojure.NET almost dead, Scala.NET dead. VB is C# with a different syntax. The only partial success story is F#, executed by Microsoft and I say partial because its impact is less than Clojure, Scala or JRuby, in spite of Microsoft promoting it.
So you see, something is wrong with your assessment and you've been listening too much to marketing pamphlets.
The CLR is definitely not full of design mistakes, it's actually quite awesome. But in terms of technical arguments, the JVM is better for dynamic languages, as it can do all sorts of optimizations at runtime that the CLR is not capable of. It's not that Microsoft couldn't improve it, but C# would have nothing to gain as it was designed to not need runtime optimizations (e.g. on the JVM, AOT compiler optimizations can actually get in the way, whereas the C# engineers focus on optimizing the compiler). And the new InvokeDynamic from JDK 7 is amazing. Starting with Java 8, it will even have benefits for static languages, like Scala. Scala for example has the notion of "lazy val", which are final references initialized on first access. In the current implementation, lazy vals have a performance penalty on access, as the generated code implies synchronization on the underlying reference, however Java 8 will make it possible to declare the generated values as being effectively constants.
The JVM also has a more capable garbage collector(s) for more wasteful languages. It makes a world of difference for languages like Scala or Clojure (e.g. functional languages use a lot of persistent immutable data-structures which generate a lot more junk than their imperative counterparts).
On the community side, for the JVM there are more capable libraries for generating bytecode. Also the ECMA standard has been kind of incomplete. For example Mono had to use for a long time their own format for the debugging symbols, while slowly reverse-engineering Microsoft's format. The debugging symbols on the JVM are documented and directly a part of the generated bytecode. Sun made many good choices here too. A JAR is just a zip containing .class files and other resources. It's definitely easier to generate JARs than it is to generate DLLs. I think language developers have a much easier time generating code for the JVM.
There is one feature of the CLR that stands in the way of dynamic languages and that is the reified generics support. The JVM has fewer restrictions, although in truth both suck for languages that are not Java or C#.
So in a head to head on tools + community + buyin from multiple vendors, the JVM wins, hard.
I like how you give a citation then cite yourself
So, they are collaborating, writing blog posts and sharing stages. Of course, Xamarin is also shipping more code, which is what impresses me about these guys.
Miguel has already said Xamarin has had some links (maybe more information sharing than collaboration) with engineers at Microsoft. How is this much different?
This seems like a weak thread. The sort of thing which could quickly cool down or die altogether. There doesn't seem to be any solid commitments here. Of course, we still have the assurance that Xamarin will continue to be impressive.
I just think it's a pretty big leap from this blog post to "maybe Microsoft will buy Xamarin."
Edit: Fixed errors.
That said, I still think Amazon will buy Xamarin.