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

Look, if you're going to troll that's fine. But at least make your trolling remarks internally consistent; first you complain that Mono requires Windows to run, then you claim it's unnecessary to create a fully FOSS CLR runtime.

Well, Windows is obviously not FOSS, so your two claims are mutually exclusive.

This may not matter. If the litigious bastards at Oracle have their way, future Android builds will migrate to "all native code" just like on the iPhone and other non-vm based devices. They'll just sadly set aside Dalvik and declare ARM to be the official ISA of Android phones, or do some crazy thing where applications are compiled (perhaps in the cloud?) before installation to a device.
I don't see C#/CLR/Mono becoming part of the Android stack, not now, not ever. Google wouldn't abandon one third-part

And in this market, you really think Google could actually afford to do that? To have the next android update remove Davlik and break every non native app? To fragment their app market into "old devices" and "new devices"? Not to mention reducing their developer pool to people who can actually write native Linux binaries.

If it was as easy as "sadly setting aside" they'd have done it by now and saved themselves the cost of a lawsuit.

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 t

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.

There is a termination clause:

If you file, maintain, or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of any Covered Specification, then this personal promise does not apply with respect to any Covered Implementation made or used by you.

I.e. you can sue Microsoft for infringement of your own patents by SQL Server or Windows, but if you sue claiming that one of the specifications/implementations covered under the open specification promise infringes your patents, Microsoft reserved their right to countersue you for infringement of the same specifications.

This is a standard defensive mechanism. Sun/Oracle has one as well:

b. With respect to any patent claims owned by Sun and covered by the license granted under subparagraph 2, whether or not their infringement can be avoided in a technically feasible manner when implementing the Specification, such license shall terminate with respect to such claims if You initiate a claim against Sun that it has, in the course of performing its responsibilities as the Specification Lead, induced any other entity to infringe Your patent rights.

c. Also with respect to any patent claims owned by Sun and covered by the license granted under subparagraph 2 above, where the infringement of such claims can be avoided in a technically feasible manner when implementing the Specification such license, with respect to such claims, shall terminate if You initiate a claim against Sun that its making, having made, using, offering to sell, selling or importing a Compliant Implementation infringes Your patent rights.

If you were to rely on these specifications for a product you are building, it actually benefits you that there is a defensive mechanism in there to deter against crippling lawsuits.

So, not much difference. Standard defensive mechanism in the common interest of the users of the products.

I am following the Oracle suite very much, because I'm myself a Java developer (and I searched long [Python, C#, C, C++, Php, Ruby] but I can't find any other language that suites my needs better). So this statement is just wrong, because Oracle is not suing over Java, but the use of the Java API and the structure, sequence and organization (SSO).

For me, the whole suite is just a stupid attempt by Oracle to get a piece of the mobile pie from Google and such a suite can only happening in the USA with it's mo

The (irrevocable, legally binding) promise Microsoft made was not just related to C#, but the.NET framework. So long as it's implemented properly (eg. all elements Microsoft deems "required" for the implementation is implemented), Microsoft will not peruse any legal action on anyone using the technology. That includes the API. The reason Microsoft did this was so people would not be afraid to use it. They want people to use it.

The two situations are not comparable at all. Microsoft would not sue over someone implementing the API.

IANAL but unless they did a clean room conversion to C#, then Oracle's patent, if valid, would still apply. In otherwords, if Android is found to infringe on Oracle's IP and they programmers examined the infringing code and converted it to C#, the the C# implimentation still infringes.

Both are "Do No Good". Theres a Google rap sheet a mile long stemming from the last 4 years.

"Do No Good"? Isn't there anything they might have done recently that might earn them a little karma? Like say, pulling out of China when every other corporation is busy sucking Comrade Dick for the mere hint of market access.

It's costing them, too. For instance, the PRC government has been threatening to disrupt the Motorola merger -- since Motorola has a major presence in China (including a lot of development and manufacturing), they could seriously work Google over using their regulatory agencies.

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.

Freaking joke of a language? It's the number 1 or 2 language in use today (along with C) if you consult language ranking sources... The reason it stood still for a few years is due to Sun going under. But we can't complain. Sun created Java and languages directly inspired by it (such as C#) owe a lot to them.

I don't know about you, but at this point, I consider a general-purpose language without closures to be a joke. In my experience, they are very useful and I would find it hard to work on a large project without them.

I must admit that I don't use Java, so I wasn't aware that you can refer to final local variables from anonymous classes.

But yeah, verbosity is a big deal. If LINQ used anonymous classes instead of lambdas, it would be almost unusable (and unreadable). A lambda that can be written in about a dozen characters in C# requires five lines when written as a Java anonymous class.

C# 2.0 had anonymous methods, which were already less verbose than anonymous classes. Then C# 3.0 introduced lambdas, with the main diffe

I am biased by my years of enterprise java so while I sometime do read lines and lines of lines consisting of }, the representation given by my IDE is quite ordered,Also I do not type that stuff in, I know my IDE well. To achieve a fake lambda (copy the variable to a final identifier in a new scope in an anonymous class) I need about 15 key stroke and no mouse interaction. While I would love the have the lambda expression, I don't feel bad about resorting to lines of generated }.

But yes, this isn't actually a big deal. Verbosity is, though. You can write code in map/filter/fold style in Java, but it'll be insanely verbose with anon inner classes - whereas C# lambdas are as compact as those in, say, Scala or Ruby (thanks to type inference).

The proposals for closures in Java 8 are very similar to the proposals for closures in Java 7. These, in turn, were strikingly similar to proposals for closures in Java 6. There have been proof-of-concept implementations around for years and several other languages running on the JVM have had closures for as long, so I'm not really holding my breath...

Wow, where did you get that opinion from? Using a beta version of VS2005? VS2001?. The team I'm in right now is coding Java for Android in NetBeans because Eclipse sucked hard. But coding in C# in Visual Studio 2008/2010 is way better, way more productive. Hell even coding Javascript / HTML in VS2010 is better than this.

The team I'm in right now is coding Java for Android in NetBeans because Eclipse sucked hard.

A couple of years ago I tried out Eclipse on Ubuntu and I thought it sucked horribly.

Recently I started doing some Android development , and based on the tutorials and references and such I started using Eclipse again. I was pleased to find that the current Eclipse, "Indigo", is much better than what I tried out in the past.

So now I'm wondering what version of Eclipse you were using before. I'm also wondering if I

Sorry but Visual Studio >>> Eclipse. It may be proprietary and not support the 100 languages Eclipse does, but for the languages does support, it is hands down 100 times better than Eclipse. Hate Microsoft all you want, but their developer tools have always been first class - which is why their OS had such widespread adoption (its about getting applications on your platform, not the quality of your platform itself).

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]

1. Visual studio users tend to be autocomplete hunters. I agree autocomplete is a handy tool, but lack of knowledge of the.NET APIs is usually rampant with Visual Studio people.

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.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.

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.

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 think you're conflating two different approaches here. On the class library side of things, I'm strongly against catching all except

Not trying to bash your head in, but I think you may just have encountered the wrong developers. One thing about Visual Studio is its ease of use (as opposed to Eclipse). This makes the barriers for entry much much smaller, allowing non-developers to write simple but very bad WinForms applications, which grow into monolithic and dear-god-kill-me-now bad applications.

This is similar to how Javascript in the late 90s was used by so many laymen (who wanted to call themselves web developers) to write the mo

Maybe the language (C#) is better (with is a personal opinion anyway, for example I don't like C# with the class/struct distinction, the unsafe delegates, the clumsy syntax for properties, the two collection frameworks [one with generics, one without] and many more issues)

But where it counts, Java is clearly the better choice, it's not for nothing the #1 used language now.

Where it counts is the Open Source Community, the build tools (is there any equivalent of maven for C#?), the libraries, the IDEs. There

Microsoft grossly overestimated the cardinality of the intersection between the set of programming nerds and the set of music nerds.

I think you might be underestimating it. It turns out that the creative minds that enjoy programming also enjoy other creative things. I almost went to music school, actually. I wouldn't consider myself a "music nerd" even though I play guitar occasionally, but I certainly know what a C sharp is.

C# (pronounced "C sharp") is a programming language that is designed for building a variety of applications that run on the.NET Framework. C# is simple, powerful, type-safe, and object-oriented. The many innovations in C# enable rapid application development while retaining the expressiveness and elegance of C-style languages.

Given that, in the parent's location, a "Pound" refers to the symbol £ (Pounds sterling), the symbol # is referred to as a "Hash" or "Hash mark" (possibly derived from the word "Hatch", as in "Crosshatch" or "hatchmark").

It compares the performance of Dalvik to Mono. Java's Hotspot has been shown in the past to beat dalvik on most performance benchmarks, so if the Oracle suit ruled in their favour, Android might get a real JVM.:)

Mono (Xamarin) is now more about a way to write mobile apps once, and have them run on both iPhone and Android with minimal porting. If you are a.NET shop (my company is), this is a good way to get efficient use of programmers rather than forcing them to context switch between C#, objective C and java. We have been very happy with the performance of several mobile apps developed on this platform, and have plans for more.

There doesn't seem to be a perfect option to write cross platform, and this does requ

I searched mono on synaptic. There are a lot of mono packages listed. The change logs show activity from April 4th, 2012, and the person listed as making that change has an ubuntu.com email address. The mono packages aren't on the CD, but the CD has only 28 packages.

I agree this is off-topic, but I really like WPF. It has a steep learning curve and a lot of quirks, but data binding, templates, and the layout system save a lot of time and make things look nice. The people complaining about WPF in your link often called themselves old; maybe that's the real problem (I'm quite young).

you think that's bad... the current design pattern du jour for WPF is the MVVM pattern - that's Model, View, Viewmodel. (like they couldn't even come up with a good name... model, view. umm, err. I know! ViewModel!)

You know you got problems when the creator of the pattern says that the overhead involved is too great for simple projects, and the complexity is too great for large projects, and in any case you have to be really careful or you end up using massive amounts of memory in the middle bit.

MVVM is so damn close to MVC that if you know MVC it is not too hard to understand MVVM....besides that, you should probably get in the habit of getting it working, then refactoring it into the pattern...it is a lot faster.

There are shops out there that actual utilize the principles of software engineering to get the job done. You get much better, more reusable software packages with a whole lot fewer bugs and those bugs are discovered at a much earlier point in the development life cycle....Software patterns are part of that....avoiding fads is one thing...not all patterns are fads....most patterns are not designed to be a development template, but a refactoring template to allow ease of maintenance.

The design pattern for WPF apps is often MVVM, but WPF itself does not impose it on you, and its data binding is flexible enough to handle direct binding to a well written model (with custom converters, and custom markup extensions for brevity) - which is what I personally recommend.