Android Ported To C# 351
New submitter Eirenarch writes "Xamarin has just announced that they got the Java part of Android ported to C# via machine translation. The resulting OS, called XobotOS, is available on Github. They claim some serious performance gains over Dalvik. For them, this is an experiment that they are not planning to focus on, but they will be using some of the technologies in Mono for Android."
Re:Android (Score:5, Interesting)
I can already tell you how that will turn out: Microsoft won't be suing anyone.
C# and the core runtime are ECMA standards with strong patent promises, meaning Microsoft explicitly gives everyone in the world the right to implement their own C# compiler and version of the System.* libraries.
Their open-ness with regard to the CLR and C# is far and away better than Sun did with Java. They even contributed DLR code to mono itself.
Not to mention how much better the language is... With real co/contra variant generics (type erasure? GTFU), first-class functions with delegates, closures, lambda expressions, and LINQ. Plus the new async/await stuff. On and type inference just makes things easier on a day to day coding basis.
Meanwhile Java has spent the last 10 years standing still. They couldn't even get closures into the latest release and from my understanding of the docs they aren't going to do true first-class closures anyway. It's a freakin joke of a language at this point.
Re:Android (Score:4, Interesting)
1. The Microsoft patent grant for C# is more permissive than the patent grant for Java.
Aaa.... No it's not. There is a defensive termination clause(I will be corrected if I'm wrong...) in Microsoft's grant, but not in Oracle's.
Re:Android (Score:4, Interesting)
1. The Microsoft patent grant for C# is more permissive than the patent grant for Java.
Are you a lawyer? I've been reading the promise Microsoft made, and it's all gibberish to me. And I doubt that even the original lawyer who drafted it would actually understand what he had written.
Re:Android (Score:4, Interesting)
What are closures main advantage over anonymous class referring to final identifiers ?
Verbosity ?
Re:Can I run Android or iOS on my PC? (Score:2, Interesting)
At the moment, yes. That might change, though.
There's now at least one phone available (in India, anyway) which runs an x86 (Intel Medfield) version of Android:
http://arstechnica.com/gadgets/news/2012/04/the-first-intel-smartphone-comfortably-mid-range-eminently-credible.ars
It can run most apps that contain ARM native code, by using a JIT. I don't know if the source code for that is available anywhere, but it'd be useful for running Android on x86. It's also not that hard to port an Android on ARM app over to Android on x86 (generally, it's just a recompile), so if Intel make any headway with x86 phones, developers might start simply compiling all their apps for both ARM and x86.
I don't know if Intel will get very far with this. Right now, their solution is OK, but not competitive with high-end ARM SoCs. Give them a couple of iterations, and given Intel's enormous lead in manufacturing process, they might become competitive soon enough. Then it's a question of whether any phone manufacturer decides to use Intel over ARM, whether people actually buy such a phone, and whether developers decide to bother supporting both ARM and x86.
Re:Android (Score:5, Interesting)
So the fact that Oracle has sued someone over their language while Microsoft hasn't doesn't matter, it's still Microsoft that is more evil.
I mean, what exactly does matter, then?
Re:Android (Score:4, Interesting)
P.S. get Resharper and NUnit.
Performance improvements indeed (Score:2, Interesting)
The chart from TFA:
http://tirania.org/s/71de890b.png [tirania.org]
Whoa. Those benchmarks show Java/JVM about 7 times slower than C#/DLR. (I thought "DLR" in TFA was a typo, but it's correct. DLR stands for Dynamic Language Runtime [wikipedia.org].)
I'm not entirely surprised. I remember reading the history of IronPython [voidspace.org.uk], where Jim Hugunin (the original author of Jython, which is Python running on the JVM) did some experiments with the CLR, intending to prove how sucky and lousy the CLR was; instead, he found that the CLR was faster than the JVM, and he went ahead and created IronPython to run on the CLR.
steveha
Re:Android (Score:4, Interesting)
their developer tools have always been first class
This is what I have noticed about Visual Studio users, and I will preface the list with this; it may be that someone just doesn't know how to use the tool, but with C#, VB.NET, C++.NET, etc... Microsoft has very clearly made the .NET platform to be developed using their tools, so knowing how to use the tool (Visual Studio) is a key requirement to knowing how to program anything for .NET (which has a lot of cons in my opinion but that's getting off topic.) [PS: In case you need an example of how absolutely dependent .NET and Visual Studio are to each other look no further than the Entity Framework]
.NET APIs is usually rampant with Visual Studio people.
.NET, Java, RPG, C++, etc... However, the people who use Visual Studio tend to have (for lack of a better term) an addiction to the "Visual" part of VS. Now there are a couple of people I've met that have written some quality code using VS, but I'd hate myself trying to convince myself that I wasn't seeing a pattern here.
1. Visual studio users tend to be autocomplete hunters. I agree autocomplete is a handy tool, but lack of knowledge of the
2. Auto-generated boiler plates *usually* makes it to production and *usually* remains until version three or four. Again, it's handy that a lot of work is done for you, in this fast pace world we live in, it can be a life saver. However, sometimes it's time to retire the boiler plate code for something that is a better fit for your solution. Visual Studio coders tend to not even realize that this is going on behind the GUI.
3. Kill diff and commit new. I can't put my finger on it, but Visual Studio coders then to forego working on already committed branches and just start fresh every time or at least every other time. For the life of me, I simply don't understand why they don't tend to follow the "dozen little gears" approach... (which leads me into)
4. If Visual Studio didn't break up the functionality, VS coders tend to cobble everything into a handful of classes. Coders tend to have a single class that handles every, single, stinking, GUI event and possible combination thereof. Really?! Why?!
5. Visual Studio coders don't seem to build components, if they do, the component isn't very focused on task. Usually the library is something along the lines of "AllTheUsefulFunctionsThatWeKeepTypingOverAndOverForOurCompany.dll" As opposed to say, "FunctionsForASingleCustomer.dll" This makes rebuilding libraries, for me, a pain in the ass because every department has to approve the changes. I have no idea why Visual Studio coders feel that everything plus a chicken is a great idea for everything and the chicken?!
6. Exceptions! Catch them please! No one is immune to this, granted. However the forgot to catch an exception for Visual Studio coders is quite higher than say the guys that write C++ or Java and use Eclipse.
I've worked at several places coding on everything from
I like Visual Studio but the most frustrating thing is it always seems to get in my way, it always wants to think for me (usually doing a pretty bad job at it), and it really does so many things behind the scene that it tends to breed a "ignorance is bliss" attitude that carries over into actual user written code.
Now before you pick up the rock and bash my head in!! I totally understand that VS is just the tool. I get that and trust me, some of the coders that I'm talking about are some of my best drinking buddies, so I really don't want to think badly of them. But I just keep seeing this wherever I go when it comes to Visual Studio coders, not just my buddies, but others too. I can't help but feel that, "if the soldiers keep dying, it may not be the soldiers' fault." Like wise, if the code keeps coming from VS, in an ugly state, it may not be the coders' fault.
Okay I'm ready to hear reasons as to why I'm just crazy and dreaming all this up.