Microsoft Puts C# and the CLI Under "Community Promise" 465
FishWithAHammer writes "Peter Galli of Microsoft posted a blog entry on Port25 today, regarding the explicit placement of C# and the Common Language Infrastructure (the ECMA standard that underpins .NET) under their Community Promise: 'It is important to note that, under the Community Promise, anyone can freely implement these specifications with their technology, code, and solutions. You do not need to sign a license agreement, or otherwise communicate to Microsoft how you will implement the specifications. ... Under the Community Promise, Microsoft provides assurance that it will not assert its Necessary Claims against anyone who makes, uses, sells, offers for sale, imports, or distributes any Covered Implementation under any type of development or distribution model, including open-source licensing models such as the LGPL or GPL.'"
Adds reader anshulajain: "Understandably, Miguel De Icaza is jumping with joy."
No Really Definite Confirmation of This Yet (Score:5, Insightful)
"The Community Promise is an excellent vehicle and, in this situation, ensures the best balance of interoperability and flexibility for developers," Scott Guthrie, the Corporate Vice President for the .Net Developer Platform, told me July 6.
Ok, I certainly hope he received more than just that before he began proclaiming to the world that Microsoft is doing such a thing.
The optimist in me is excited. The skeptical in me is dubious, confused and does not trust blogs. It's not listed on Microsoft's list of products under the Community Promise so I'm going to refrain from breaking out the champagne until all the facts are finalized.
Anyone else got a better source for this than a loosely affiliated blog that bills itself as "Communication from the Open Source Community at Microsoft" ?
Re: (Score:2, Interesting)
And I can't find anything on that page that mentions C#. Perhaps I'm reading it wrong...
Re:No Really Definite Confirmation of This Yet (Score:5, Insightful)
Its not just that its 'promised' to be added to the Community Promise, its only the ECMA 334 and 335 standards that will be added (possibly).
According to TFA:
ECMA 334 specifies the form and establishes the interpretation of programs written in the C# programming language, while the ECMA 335 standard defines the Common Language Infrastructure (CLI) in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications to take into consideration the unique characteristics of those environments.
however.. later on, he says about Mono:
Astute readers will point out that Mono contains much more than the ECMA standards, and they will be correct.
In the next few months we will be working towards splitting the jumbo Mono source code that includes ECMA + A lot more into two separate source code distributions. One will be ECMA, the other will contain our implementation of ASP.NET, ADO.NET, Winforms and others.
So really, even if MS adds the 2 standards to their Community Promise, that still doesn't mean you get anything useful - if you write a simple app that does nothing, you're fine. If you want DB access, or web serving, or a GUI.. you're still in the same problem as before.
Re: (Score:2)
Re:No Really Definite Confirmation of This Yet (Score:4, Insightful)
They're letting you implement the specs, but in exchange you're not allowed to challenge their ownership of the patents or copyrights involved. I don't really know if you'd call this open source or just a benevolent gesture on their part.
Re:No Really Definite Confirmation of This Yet (Score:5, Insightful)
The fact that they worded it "Microsoft provides assurance that it will not assert its Necessary Claims" still freaks me out. It's either open, or it's your claim. It' can't be both.
Re:No Really Definite Confirmation of This Yet (Score:4, Insightful)
Yeah, the implied threat is quite menacing.
"We have this big hammer. Really big hammer, actually. Just acknowledge that it's our hammer, and that's it's a really big hammer, and that we are allowed to hit you with it at any time, and we promise not to hit you with it."
Makes me wanna rush right out and start developing Mono applications.
Re:No Really Definite Confirmation of This Yet (Score:5, Insightful)
Yeah, the implied threat is quite menacing.
"We have this big hammer. Really big hammer, actually. Just acknowledge that it's our hammer, and that's it's a really big hammer, and that we are allowed to hit you with it at any time, and we promise not to hit you with it."
Makes me wanna rush right out and start developing Mono applications.
As a huge fan of the GPL, I gotta say that's no different than the GPL. "We have the copyright to the software, and we allow you to copy, modify, and distribute the code, but if you ever violate our conditions, we still own the copyright and reserve the right to sue you for breaching." That's perfectly reasonable. So is microsoft's statement. They're basically saying, "you can reimplement this stuff without worrying about our patents, as long as you don't challenge our patents or don't sue us for violating yours. If you do, the claws are coming out." That's pretty defensive.
Honestly, a "promise not to sue" is legally binding. If they sued you without you violating the terms you literally could show that to the court and they would tell MS to fuck themselves. They have given you an expectation that you won't be sued, so the doctrine of Estoppel [wikipedia.org] applies.
Re:No Really Definite Confirmation of This Yet (Score:5, Informative)
Re: (Score:2, Insightful)
It's not FUD. One of the goals of the Mono project is compatibility with .NET applications and that means supporting things like Windows Forms.
Re:No Really Definite Confirmation of This Yet (Score:4, Informative)
You're right, but the most common criticism of Mono before this announcement was that free software distributed with Linux carried a patent risk. The Winforms stuff is still a goal of the Mono project, but there is no reason for Linux distributions to install it. The non-ECMA parts of Mono are still very useful for companies migrating existing Windows legacy apps to Linux, but nobody would write a new free application with Winforms starting from scratch (GTK# is a lot better).
So the Windows.Forms and other Microsoft APIs move to a separate 'Mono-non-ECMA' package, which can be treated a bit like Wine: you wouldn't really want to install it by default or develop against it, but it can be invaluable if you have existing Windows software you want to run.
Re: (Score:3, Insightful)
nobody would write a new free application with Winforms starting from scratch (GTK# is a lot better).
I think you're making a leap of faith there. Especially since Visual Studio doesn't have a GTK builder.
Re: (Score:3, Insightful)
Even for a Linux enthusiast, the Visual Studio/Winforms stack is much more tempting for ambitious projects. The MonoDevelop/GTK# stack has a way to go for stability and features... gets better every release, though.
I'm a Windows developer by day and a Linux user by night, and I've got probably half and half MonoDevelop and Visual Studio projects at home. Pick the best tool for the job, they say...
facts are different (Score:4, Informative)
Even for a Linux enthusiast, the Visual Studio/Winforms stack is much more tempting for ambitious projects.
All Mono desktop applications that ship with Ubuntu are based on Gtk#. Winforms isn't even usually installed.
I'm a Windows developer by day and a Linux user by night, and I've got probably half and half MonoDevelop and Visual Studio projects at home. Pick the best tool for the job, they say.
VisualStudio and Winforms are proprietary and simply aren't a choice for Linux desktop applications (even if they didn't suck).
Re: (Score:3, Interesting)
Now, rationally and factually, without your own personal bias and agenda, please explain to us why they aren't a choice for Linux apps and why they suck.
For VisualStudio: it's hard to learn, needlessly complex, commits numerous user interface sins (modal dialogs, bad layouts, etc.), and developers are not very productive in it. For Winforms: apart from numerous niggly technical issues, they are not native to Linux and don't work quite right on Linux. It's the same problem Java has on Linux (and then some)
Re: (Score:3, Interesting)
I have frequently had proprietary applications that I depended on stop being produced. Frequently it wasn't because the company went out of business, even, but merely because they wanted me to buy their latest product.
Now I generally prefer to avoid proprietary products. Moving to Linux has made this practical. This doesn't solve everything (I was appalled when I was switched to KDE4 from KDE3. KDE4 is abysmal by comparison. Fortunately there's Gnome, which while it isn't as good as KDE3 is better than
Re:No Really Definite Confirmation of This Yet (Score:5, Insightful)
it was said, "that still doesn't mean you get anything useful - if you write a simple app that does nothing, you're fine." and then goes on to mention doing a GUI, amongst other types of applications is going to require using some .Net tied libraries. While it was not _that_ clearly stated, the OP was really saying that using C# and the CLI to write more complex applications is very likely to be leveraging libraries instead of every aspect being written from scratch and those libraries are based on Microsoft's .Net patented designs.
The fact that Microsoft is mentioning this stuff about C# and the CLI while saying nothing about the .Net patents and libraries should be a red flag because the issue is Mono. Mono is C#, CLI and .Net libraries. They are dancing around the main issue and almost everyone is missing this.
LoB
Re:No Really Definite Confirmation of This Yet (Score:5, Informative)
Writing GUI-based GTK# applications does not require any libraries not covered by this promise. There are FOSS database access libraries available for Mono that interface with MySQL etc. without needing ADO.NET. In fact, none of the high profile C# complex(!) applications for Linux like FSpot, Banshee or Tomboy require any libraries not covered. And Mono is separating the source code into two parts in a future release so that you can run the libraries in doubt at your own discretion and risk. You're the one who's missing it, not everyone else. Here is a figure for clear delineation. http://primates.ximian.com/~miguel/tmp/two-stacks.png [ximian.com]
Re:No Really Definite Confirmation of This Yet (Score:5, Informative)
If you install libgdi+, Winforms works just find on FreeBSD.
As for looks that's a matter of taste, I never minded how Windows looks, but Gnome never really suited me. With libgdi+, winforms tend to look a lot like plain old Windows.
Re:No Really Definite Confirmation of This Yet (Score:5, Insightful)
I have very strong reservations against C#, not for the language itself but because it has this name of being a "dot-net language". Everywhere C# is promoted, dot-net is mentioned in the same breath. This is a real issue because if I know anything about Microsoft, it is that they like to keep targets moving. This means dot-net will evolve so quickly that there will only be one complete implementation: Microsofts own one. Combine that with the (wrong) assumption in the heads of many developers that dot-net will always be available, and you get a great recipe for a hell called lock-in. With C++, there is no vendor with this amount of power, and that's the way I like it.
Re:No Really Definite Confirmation of This Yet (Score:5, Informative)
If you want a GUI on Windows, or using the Windows libraries, sure.
GTK# [mono-project.com] is entirely developed by the Mono project, and requires none of the aforementioned Microsoft parts. That means applications like Tomboy [gnome.org] and Banshee [banshee-project.org] should now be fully RMS-friendly.
Mono is more than just 'running Windows applications on Linux'. There is a large ecosystem of utilities developed with it, because (a) a properly object-oriented language with native bindings is much better than the C-with-Gobject alternative, and (b) Java was not Free at the time.
The stench of microsoft (Score:4, Funny)
Re: (Score:3, Insightful)
As far as I understand it none of the Gnome Mono apps use those other libraries. Perhaps ADO.net, I'm not certain.
Certainly they don't use Winforms, they use the GTK bindings.
Re: (Score:2, Informative)
Re: (Score:2)
So really, even if MS adds the 2 standards to their Community Promise, that still doesn't mean you get anything useful - if you write a simple app that does nothing, you're fine. If you want DB access, or web serving, or a GUI.. you're still in the same problem as before.
I believe it means that if you want DB access, or web serving, or a GUI, you will have to use other libraries that Mono offers, such as GTK# for the GUI instead of WinForms etc. You don't have to use the windows libraries -- it's just convenient to have them available for Mono for cross-platform purposes.
Re:No Really Definite Confirmation of This Yet (Score:4, Insightful)
I'm sorry, but wasn't part of the point of Mono (and .NET, actually) compatibility and cross-platform independence? So if I require Mono-specific libraries to use Mono, and Microsoft-owned libraries to use .NET, what is the advantage of using the framework? It is then just another environment among myriad, more mature, others.
-dZ.
Re: (Score:2)
Re: (Score:2)
Not true. The main controversy recently (which presumably was what prompted this "promise") was after RMS warned people against using Mono to develop Gnome applications under Linux. This uses C# as a convenient high level language for Gno
Re:No Really Definite Confirmation of This Yet (Score:4, Informative)
Almost. I present to you, the Mono Project FAQ:
(my emphasis)
That was the main concern of RMS: that the attraction to the project was the promise of cross-platform .NET development, but that such development is ultimately encumbered by patented technologies.
-dZ.
Re: (Score:3, Insightful)
There are a few flaws with this argument. Firstly, if you want a GUI then Winforms is not the only choice. In fact, GTK# is a lot nicer, on Windows and Mac as well as on Linux, and all the free Mono apps such Banshee use GTK#, and C# bind
Re: (Score:3, Insightful)
I'm not aware that they hold enforceable swpats for more pedestrian things like database bindings
The Orwellian flavor of "swpats" is right on topic. Any other company will give you a license to use their patent, they don't. They give you a "promise not to use our necessary claims".
As if using Mono is technically illegal but they are nice enough not to sue.
Quite frankly
DO NOT WANT
Re: (Score:3, Interesting)
Only if there are enforceable patents held by Microsoft which are specific to C# (the language) version 3. You see, C# 3 compiles to the same bytecode as C# 2, and runs on the same virtual machine. The MS patents that people worry about are on implementation techniques for the virtual machine. You use the same ECMA-specified virtual machine to run bytecode compiled from C# 2 and C#
Re: (Score:3, Informative)
If you look closely at the announcement, you'll see that there are two separate promises, one for CLI spec, one for the language spec.
Re: (Score:3, Interesting)
That was my immediate reaction. Microsoft like to play "the version game"... remember when they traded a license to the Mac GUI in exchange for a specific version of Office, then immediately revved the version? (No, probably not-- that happened in the 80's and 90's.)
So now that they've come out with a new version, they're freeing up the previous version. While that's a nice step, it doesn't exactly make Mono free and clear, nor does it allow Mono to create a runtime that will run any .NET app on any plat
Re:No Really Definite Confirmation of This Yet (Score:4, Informative)
According to a comment by Miguel on his blog,
quickly, bash them. (Score:2, Funny)
Re: (Score:2)
Re: (Score:3, Funny)
Maybe it's just a sign the Microsoft think they can beat Mono. If Microsoft sets the standards they will have a more mature platform out at any point in time.
Or maybe they think that a little competition is a good thing?
Re: (Score:3, Insightful)
As I read in the antitrust documents, Microsoft feels that a "win" in the "war" is for the competition to use their standards. In several email messages and presentations given at MS, they outline this philosophy. They compare it to owning the competition by making them play the game by their rules.
http://antitrust.slated.org/www.iowaconsumercase.org/011607/3000/PX03096.pdf [slated.org]
Re:quickly, bash them. (Score:4, Insightful)
If you read that document and you still feel that a "win" for Microsoft isn't the worst thing that could happen to the computer industry, then I feel bad for you, your children, and society as a whole for raising you to think that it's a good thing.
The only "win" that would be beneficial to the world would be for Microsoft to quit playing these legal games and release the patents, open the spec up for input from the community and quit trying to "own" everything. They won't do that because they still have the patents up their sleeves and by not releasing the rights in full only shows me that they intend to use it if they suddenly see their monopoly hold start to dip below recovery.
They want to maintain control over the standard so they can always be ahead of everyone else. They keep the language under a veil of legal battles to discourage anyone from doing anything constructive with it. If the Linux/Mac desktop becomes dependent on .NET, you can kiss them goodbye. Why would anyone want to use the substandard protocols legally available to those systems if they can get first party cutting edge tech on Windows? That's what they want, and that's why I won't install Mono on my Linux machine until all patents are off or nullified by the courts. This is the same for Office document standards, the same for SQL standards, the same for Web standards...
That's why a "win" for Microsoft is a bad thing in this case. A majority market holder should not also be the standards designator. It's asking for antitrust violations out the wazoo. It doesn't matter what the credentials of the language are. It's solely on the credentials of the organizer.
Re: (Score:3, Funny)
It would be great to see Microsoft win and .Net win, because it is the best technology for a cross-platform future. With Microsoft moving towards the cloud it would be great to make Microsoft embrace cross-platform to resolve the remaining Java argument and indemnify developers from patent hassles, also ASP.NET and ADO.NET and Winforms. That would be a consequent move towards a cloud based architecture.
This shows (Score:5, Funny)
Microsoft love us and want us to be happy :-)
Re: (Score:2)
promise doesn't extent downstream (Score:4, Informative)
Re: (Score:3, Informative)
It does not apply to 'partial implementations' either.
From the FAQ
Q: What if I don't implement the entire specification? Will I still get the protections under the CP?
A: The CP applies only if the implementation conforms fully to required portions of the specification. Partial implementations are not covered.
Re: (Score:3, Informative)
The 'community promise' does not extend to commercial downstream recipients of open source MONO applications !
I think that is incorrect. Quoting from the community promise itself (linked in article)
Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation, to the extent it conforms to one of the Covered Specifications, and is compliant with all of the required parts of the mandatory provisions of that specification
It includes "using". So I do not receive the rights from the distributor of a MONO application, but I, as a user, am directly granted the right to use it from the microsoft community promise.
The fact that you have to conform to the standards is however a real restriction. It makes some sense, to avoid someone else playing an embrace-extend-hijack on them, like they tried with Java... however this also means that if I i
Sounds promising... (Score:3, Informative)
It sounds promising, and it may end up meaning Stallman was wrong all along and that it was safe to implement .Net/C# (which GNU have done anyway). It's be useful to have somewhere slightly more authoritative to hear it from (like Microsoft themselves) but at least people don't need to worry about "arrrghh, it's a patent trap" and can get on with "hurrah! I can focus on coding for the desktop in a decent language rather than having low-level memory concerns etc".
Not that I ever cared anyway. Stick to the registered standard definition of C# and Microsoft couldn't exactly kill off Mono anyway, as they'd probably have ended up breaching the "fair and non-discriminatory" part of the patent licensing or been forced to give Mono a free license anyway.
Re:Sounds promising... (Score:5, Insightful)
Re:Sounds promising... (Score:5, Informative)
Before that, he deprecated Java like he’s doing with Mono now.
Re: (Score:3, Insightful)
Yes. Stallman. Have you read his comments on Java lately?
Sheesh. The Stallman bashing gets really ridiculous at times.
Mart
Re:Sounds promising... (Score:5, Insightful)
It sounds promising, and it may end up meaning Stallman was wrong all along
You've got the causality exactly wrong. If it wasn't for Stallman and other FOSS people making a lot of noise about this recently, it wouldn't have happened. (Note that I'm not saying Stallman himself is to be thanked for this, it's the general noise about the topic, which he was a part of.)
There are always two levels to statements such as those Stallman etc. made about Mono. On the first level, they are meant to be taken at face value - their arguments are either valid or not, in and of themselves. On the second level, they are intended to cause an effect of some form, such as motivating certain people to do certain things. In this case, the second level was meant to motivate Microsoft to make the first level (the direct arguments against using Mono) invalid. That appears to have worked (well, once Microsoft formally announces this, presumably soon, but all we have so far is a blog post).
It's about time (Score:5, Informative)
Now Microsoft is estopped from going after people using c# and .net technologies.
This is the answer I've wanted from Miguel ever since the Novell brouhaha.
Promissory estoppel serves as a "consideration substitute" in contract law that renders certain promises otherwise lacking in consideration binding and enforceable. In such cases, the promisee's reliance is treated as an independent and sufficient basis for enforcing the promise. Promissory estoppel can be viewed as a legal device that prohibits the promissor from denying the existence of a contract for lack of consideration.
http://www.lawnix.com/cases/promissory-estoppel.html [lawnix.com]
Re: (Score:3, Insightful)
My first response to this news was: "assurance"? WTF? That's like, "My dear, I assure you that I will pull out in time."
But then I read the post about this action being promissory estoppel. And I am most definitely not a lawyer, but in the link provided, all the cases included "the court decided". So it is not some magical binding spell put on Microsoft. If it is in their best interest to suck portions of the community into their trap and then bring legal action later, they can. And probably will. And they
Re: (Score:3, Insightful)
You're not allowed to encourage a behavior and then sue because someone took you at your word later.
That is "setting us up the bomb" and what promissory estoppel is supposed to rectify.
And I'm not a lawyer. Maybe NYCL or someone else can come here and explain further.
--
BMO
Re: (Score:3, Informative)
So what you're saying is that it's a really well disguised trap?
Note that what Microsoft is stopped from doing has no bearing on what they can fund other companies to do on their behalf [cnet.com].
There's no legal basis for any third party to sue .NET implementers, you say? Well, gosh darn, I guess there's no way that Microsoft could fund them to file a bullshit case that drags on for year after year after year, tying up court time, costing the defendants millions in fees, and eating away at the hearts of souls o [groklaw.net]
Re: (Score:3, Funny)
Don't forget that backward compatibility is sacred to Microsoft. Similarly, I can't possibly imagine that it would be a good business decision for Microsoft to begin suing its own developers.
Re: (Score:3, Interesting)
It'd be easier for them to just upgrade .NET to be incompatible with everything they promised not to sue over. Then they can sue when people upgrade, because there's no promise covering the new versions.
Steps:
Re: (Score:3, Insightful)
Actually, it will be:
4. Mono forks the standard and implements their own, not patent-encumbered version.
We are actually already there with Gtk# and stuff. Using Mono as a platform to get existing .NET apps working isn't really viable anyway (even though they keep trying). The real issue at stake is being able to use the language, and the core class library, as a foundation for a FOSS stack, together with frameworks like Gtk and GStreamer. Compatibility with "C#+N" is not a big deal there.
Re: (Score:3, Informative)
C# is a language. There's no point in forking that, because it's completely covered by the promise. Same goes for the runtime (CLR).
What's not covered are all the libraries, and there, as I pointed out already, the "forks" are going on in form of various Mono.* libraries, and Gtk#/Gnome# stuff. Which is actually used to write decent Gnome apps.
They also work on WinForms, ADO.NET, ASP.NET etc because there is some interest in that as well, but it mostly doesn't intersect with people who use Gtk#.
Re:It's about time (Score:5, Informative)
The idea of embracing and extending is an old one. First, you offer to work with someone. Then, you slip in nonstandard extensions that aren't as widely available, but convince people they are an improvement. Then, you either pull out compatibility with the old standard or count on enough people using your new, non-standard version that people using the open version are left behind.
Microsoft has tried this with TCP/IP, name services (WINS rather than DNS), network protocols (NetBEUI), office suites (MS Office was once capable of opening and saving the formats of suites which were then more popular, but thanks to preloads and trial versions dropped support for the competition's file formats once it was the market leader), filesystems (it's still suing over variations of FAT), and even the joint development of operating systems (a cross-license and joint development agreement between Microsoft and IBM for Windows and OS/2 ran out just before Microsoft unleashed Windows 95, which was gratuitously incompatible with the Windows APIs in OS/2).
Re:It's about time (Score:4, Informative)
It isn't paranoia if they've done it to you more than once already to think they might do it again. And yes, I can name the "they" -- Microsoft. It's more than one person, after all. A corporation by definition is a "conspiracy", although not necessarily with the negative connotations that word carries. It's always one group of people working together for a common goal which furthers the interests of their group above and before the interests of others. Perhaps when looking for conspiracy nuts you find them easily when corporations are being discussed, but that doesn't mean anyone's actually paranoid.
...and this means? (Score:4, Insightful)
http://www.perfectreign.com/stuff/2009/20090312_secure_submitter.jpg
http://www.perfectreign.com/stuff/2008/20080912_JEDI_Vitals_Screen.png
http://www.perfectreign.com/stuff/2008/20081205_ie6_yoda_ii_ponte.jpg
My question is this - does MS moving to a new license change my current licensing? How does it interact with those running SLES or Virtualized Windows 2008 under XEN?
FYI, this IS legally binding (Score:5, Informative)
"Q: Is this Community Promise legally binding on Microsoft and will it be available in the future to me and to others?
.NET but not covered by the standard (like Winforms)
A: Yes, the CP is legally binding upon Microsoft. The CP is a unilateral promise from Microsoft and in these circumstances unilateral promises may be enforced against the party making such a promise. Because the CP states that the promise is irrevocable, it may not be withdrawn by Microsoft. The CP is, and will be, available to everyone now and in the future for the specifications to which it applies. As stated in the CP, the only time Microsoft can withdraw its promise against a specific person or company for a specific Covered Specification is if that person or company brings (or voluntarily participates in) a patent infringement lawsuit against Microsoft regarding Microsoft's implementation of the same Covered Specification. This type of "suspension" clause is common industry practice."
tl;dr they can't sue you, ever, unless you sue them over patents.
Also, Mono contains
1) parts that are covered by the ECMA standard (C# and the CLI)
2) original namespaces (like Mono.Simd)
3) open-sourced Microsoft stuff (like ASP.NET, under the OSI-approved MS-PL license)
4) parts that are in
which is why Miguel de Icaza says they'll be splitting their distribution up into now definitely safe (1 and 2) and potentially dodgy (3 and 4) packages, which is what already happens on Ubuntu for instance.
Re: (Score:3, Insightful)
Erm. No. He is saying he is now splitting potentially dangerous code from the main project. That means that there was potentially dangerous code before, something which Miguel and his fanbois were disclaiming all along.
Of course, pointing out that he made a one-eighty is considered Flamebait these days. Sigh.
Re: (Score:3, Insightful)
Seriously, who the fuck cares? (Score:3, Informative)
Why do people think C# is some new amazing language? Clearly MS took Java and gave it a MS framework.
If you would just use java you probably wouldn't have this fear of MS trying to undermine the OSS movement. When a multi-billion dollar company other than google tries to "help" OSS, you can only be suspicious.
http://www.javacamp.org/javavscsharp/getStarted.html [javacamp.org]
Re: (Score:2, Informative)
Re: (Score:2)
If I wanted to develop an app for Windows alone, you had C#/.NET, "Microsoft Java" with a complete native look-and-feel (although I do admit it took until .NET 2.0 to really get there), or "Java" with (at the time) looks-like-Java-on-all-platforms.
Not to mention the other languages on the CLR.
As to why Linux didn't pick it up, Java wasn't even really distributable until Sun released it under the GPL, and Mono was way ahead of the IcedTea (free JDK) project - Mono had ".NET does not exist on Linux" as a driv
Re:Seriously, who the fuck cares? (Score:5, Insightful)
C++ programmers and Java programmers can all feel quite at home after only a short time in C#. It was designed that way. Saying that, coming to it only knowing C/C++, it didn't take much longer for me to develop an initial familiarity with Java. In fact, pretty much by definition, and for obvious reasons of programmer portability, most strongly typed, high-level programming languages are remarkably similar.
To say that C# is identical to Java, though, is bollocks. There are some pretty significant differences, and in many cases I prefer C#'s implementation.
Re: (Score:3, Informative)
C++ programmers and Java programmers can all feel quite at home after only a short time in C#. It was designed that way. Saying that, coming to it only knowing C/C++, it didn't take much longer for me to develop an initial familiarity with Java. In fact, pretty much by definition, and for obvious reasons of programmer portability, most strongly typed, high-level programming languages are remarkably similar.
The only thing Java and C++ had in common were the C syntax and the object orientation.
In (the original) Java, compared to C++:
- Code is meant to be byte-compiled;
- There is no preprocessor;
- There are no pointers, and no pointers to function in particular;
- No explicit memory management is possible, and there are no destructors;
- You cannot declare isolated functions/procedures;
- There is no distinction between class declaration and class implementation;
- Multiple inheritance is forbidden;
- There a
Re: (Score:3, Interesting)
Let me show you how this works, fan boi o mine:
Person A makes statement, this in case, I said "Java and C# are very, very similar yet many uneducated folks seem to think they are radically different." This is a statement that can be refuted by another party, take Person B for example.
If Person B disagrees, (s)he can respond with "You're totally wrong, see X which is vastly different than Java and not some marketing feature."
However, in this case, Person B said "Oh no you di-int" and stopped there.
However, a
Re: (Score:3, Informative)
Unsigned numeric types. Delegates. Structs (stack-allocated complex data types that are passed by value). LINQ. The option of explicit memory management. No stupid restrictions like only one public class per file. Partial classes. Operator overloading (not always good, but occasionally just damn sensible). There's plenty more...
You can pretty much run a find-replace over Java and get legitimate C#. The reverse is not true. C# >= Java.
Re:Seriously, who the fuck cares? (Score:5, Informative)
I find it pretty amazing when you mention this to most C# programmers, they'll go on about how different C# is from Java.
"They" do? Really! Funny, as a C# programmer who has fairly extensive experience with Java, I've never said any such thing. Maybe you should try *not* stereotyping large groups of people, eh?
For the record, C# is really Java polished up. It provided generics and a foreach loop first, implements type-safe function pointers, lambdas (the absence of lambdas in Java always annoyed the hell out of me), a much better native call interface, and a few minor but handy language features (eg, safe ref and out parameters, using blocks, etc). And I very much prefer the native GUI of C# applications (although the nasty boilerplate necessary to build them makes a GUI builder absolutely required).
On the API side, they're about equivalent, though both have their warts... although, I must confess, some of the problems in the .NET API are a bit baffling (date handling in .NET 2.0, for example, is unbelievably primitive... there is simply no facility for doing arbitrary time zone conversions... seriously, what the hell?).
But anyone who argues that C# is basically the same as Java doesn't understand how some of those features can make a programmer's life *much* easier. Are they necessary? No, of course not. But they certainly are handy (honestly, without proper anonymous closures, I feel crippled as a programmer... as a tool for building clean, reusable, modular code, they're simply invaluable).
And as an aside, while I realize that Java is starting to take on a lot of these features, keep in mind, it probably never would have if it weren't for the competition that C# and .NET are offering. So, in the end, the Java fans out there can thank Microsoft for Java finally moving forward and gaining some of it's new, modern features (can we say "generics"?).
This makes no real difference! (Score:5, Interesting)
Here's why:
There is no mention of other components [nyud.net] the extend .NET!
From the document...
"...We introduce instructions newdata, lddata, stdata, castdata, isdata and
switchdata to create and manipulate classunion values..." (emphasis mine).
In fact, this announcement is not much different compared to the one 7 years ago!
Watch out folks. Microsoft's classic Embrace, Extend, Extinguish paradigm is very possible here.
Re:This makes no real difference! (Score:5, Informative)
That was a research paper on ILX from 2001.
The research work from ILX was folded into .NET 2.0 and is part of ECMA 4th edition.
All of the instructions that you listed are deprecated, they never really made it into .NET, their much improved, polished and battle field tested versions did. And they are the foundation for C#'s generics support and Don Syme's F# compiler, both which run just fine in Mono today.
So, let me get this straight... (Score:2)
Grab your ankles, folks, this will hurt us all in the end.
Nothing New, Doesn't Help Mono (Score:4, Insightful)
This is nothing new and nothing we didn't already know. It still says nothing about ASP.NET, Windows Forms and all the other parts of .NET that are not part of the ECMA standard. Mono implements many, many things outside the ECMA standard, so anybody but Novell who distributes or otherwise uses Mono is at risk of patent shenanigans.
why so happy? (Score:2, Interesting)
Why would Miguel De Icaza be so happy if his previous assertions that there is nothing to worry about mean anything?
Bidirectional promise not to sue? (Score:2)
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
Is that a patent retaliation clause? Interesting.
Anyhow, the way I read that, you can't sue Microsoft if they make use of one of your patents in their own implementations, albeit limited to the specifications covered
But they were all of them deceived.... (Score:4, Insightful)
Re: (Score:3, Interesting)
In part I agree with you. In designing C# (and .NET in general), Microsoft correctly identified a lot of the hiccups of Java development.
Unfortunately, IMO, their solutions were a disaster.
Erasure-based generics are annoying, but the CE-incompatible hacks of runtime generation are worse. Writing getter/setter for trivial properties is annoying, but limited and buggy syntactic sugar is worse. Having all objects be pointers is annoying, but making structs silently stack-allocated is worse. Needing to use arra
What is included? (Score:2)
Java or Mono or Both? (Score:5, Insightful)
I have been following Mono for a while but I am currently still using Java.
The question is which do I commit to?
The way I understand it is:
Java has less "patent liability" than Mono. .net are covered by the Communtiy Promise but not some of the supporting libraries (e.g. ado.net, winforms).
All of Java is under an open license including "essential" libraries (e.g. data access, gui).
Only the "core" (including the framework libraries?) of
I know that these .net libraries have been implemented in Mono but would we have to write new open-source libraries to replace thier functionality and remain "patent-threat" free?
If this is the case then I would imagine that Java would be the preferred choice IF you had to chose one.
What are the overheads of both the Java and Mono virtual machines running at the same time? Would we be better getting behind just one environment and using that.
For what it's worth I really like and prefer Mono - especially Banshee (is there an equivalent for Java?) and I want to develop for it but the Community Promise only covers the ECMA part of .net. Without the other libraries I fear Mono is hamstrung.
At least with Java I know where I stand, all the libraries are included and the functionality is already there.
get real (Score:4, Informative)
Java has less "patent liability" than Mono.
Sun has lots of patents on lots of aspects of Java. The only area where you *may* be safe is if you use Sun's own implementations.
I know that these .net libraries have been implemented in Mono but would we have to write new open-source libraries to replace thier functionality and remain "patent-threat" free?
Most people who develop with Mono develop using standard Linux libraries, libraries that are free of any hint of Microsoft patents. That's one of the things that makes Mono so attractive.
prefer Mono - especially Banshee ... Without the other libraries I fear Mono is hamstrung.
Banshee, like almost all Mono desktop apps, is based on Gtk#, not Winforms.
What are the overheads of both the Java and Mono virtual machines running at the same time? Would we be better getting behind just one environment and using that.
IKVM runs Java inside a CLR. It also neatly avoids Sun's patents.
Is C# / Mono + libraries really *that* good? (Score:4, Interesting)
OK, first off it's excellent news if MS are doing this. It would be nice if they did the same for the parts of Mono / .NET that are outside ECMA.
As far as motivation for this goes, they're a business for whom pure co-operation seems to have dubious benefits. I assume that they believe that in this case more people using .NET is good for them and that they can compete well on the quality of the implementation and debugging tools (probably true if only because they'll have a head start on new features).
But the question I'm really curious about: CLI / C# / Mono seems to have generated a massive amount of controversy and therefore a lot of noise. Some fairly popular new apps have been written using it. The whole situation seems to suggest that, whilst using the technology was generally considered to have many downsides, it must have pretty large benefits too: it's not just being suggested as a compatibility library but as a foundation for some pretty cool new stuff. So ... is this really the case? Is it that good that you'd want to write your note taking app in it (Tomboy) even though it's possible to write it in another language (i.e. Gnote)? Are the development tools that much better?
Or is it the case that a few "killer apps" happened to be written in C# as demonstrations of its abilities - even though another language would have done the job - and those apps are sufficiently desirable that Mono is getting pushed hard so that everyone can have these killer apps by default?
Personally, although I've not programmed in C#, I'm familiar with a variety of languages and implementation strategies. Different languages are certainly good for different things and more modern languages are typically less painful to work with. C# sounds quite nice. But what I'm wondering is: is the noise and push over Mono as a popular platform a result of it being particularly strong, or a result of a few particularly desirable apps depending on it? Obviously some (much!) of the noise generated is simply due to concerns over leveraging MS technology. But I do wonder how good the technology must be to justify this much noise and controversy!
Re:Is C# / Mono + libraries really *that* good? (Score:5, Interesting)
I've used both for serious commercial development and I personally prefer C# to Java. If it means anything, I consider myself pretty impartial, as Java and C# are just two of the dozen or so languages I've worked in and I consider neither to be the most interesting.
C# and Java are only really similar in the way that you would expect two garbage-collected, object-oriented, C-derived languages to be similar. People who say C# is 95% the same as Java are missing the point: it's the small differences that make one language nicer to use as a developer.
Your mileage may vary. You should give both a go and make up your own mind.
Re:Is C# / Mono + libraries really *that* good? (Score:5, Insightful)
Considering your entire "question" is basically slamming it, I doubt you'll care what people answer.
But for the record, yes, it is *that* good.
The controversy is all over political crap, not the quality of the language or runtime. If you want to write software, and don't care about political crap, there's virtually nothing out there better than C# and the CLI right now.
Re: (Score:3, Interesting)
C# sounds quite nice. But what I'm wondering is: is the noise and push over Mono as a popular platform a result of it being particularly strong, or a result of a few particularly desirable apps depending on it?
Interesting question. I don't think it's to do with the existence of a few desirable apps. I've had plenty of experience with C# / .NET through work, and it's really very nice to work with. The language, the libraries, the platform and even the development environment all add up to a whole which (to my disappointment) I find much easier to work with than any free alternative I have yet discovered.
I still try to stay away from proprietary technologies in my personal projects, but I can see why people are exc
Re: (Score:3, Interesting)
Simply put, C# is Java with true generics, RAII, full-featured lambdas with short syntax and ability to mutate captured variables, operator overloading, and opt-in low-level operations complete with pointer arithmetic and unions. (This is still a simplification, but it's close enough).
If you are a Java coder who understands what the above means, and it makes you go "wow gimme!", then welcome to the club (though you may also want to consider Scala in this case).
If you understand, but it makes you wince, then
Re: (Score:3, Funny)
I imagine that sane COBOL developers called Java the same thing. You only need to look around - Java is the only mainstream language that does not support proper lambdas, for example, and does not plan to in the next major revision.
When even C++ starts looking more modern than your language, it's definitely time to worry.
Re: (Score:3, Informative)
Sounds closer to the power I get with Python whilst still offering me the potential for efficient JIT and arguably better structuring / type-checking at development-time (though I have used tools that help with this issue in Python).
It's a fairly close assessment. Of course, dynamic languages offer a lot of power that no statically typed language could possibly offer (just consider the possibility of defining classes and methods inside "if" in Python); and C# is definitely a static language, even though it will get opt-in duck typing [microsoft.com] soon, mostly to improve interop with dynamic languages (such as IronPython).
If you want to take a look specifically at the features I've listed (and you're generally proficient with C++/Java language famil
Promissory estoppel ftw (Score:5, Informative)
The lawyers amongst us are leaping for joy. I happen to be a law convert. So ill try and explain why we're happy!
Promissory estoppel is a legal defence (a so called shield). When a party (A) intending legal relations promises not to assert their strict legal rights, and another party (B) moves to rely upon this promise, that party (A) is estopped from enforcing their rights (against B) by way way of promissory estoppel.
It goes something like this: Now MS has promised not to enforce their C#-rights , and people rely on this promise, such as start development/deploying C# applications because of this promise, if the case came to court, MS's argument would be estopped by a defence of promissory estoppel.
It's a little more complicated. For instance it must be inequitable for B if A reneges on their promise (fairly clear if they suffer a disadvantage or loss as 'one who comes into equity must come with clean hands'), the promise must be clear and unequivocal (I'd say yes), there must be a change in reliance on the promise (yes), and it is a shield not a cause of action (in other words, we can't sue MS for revoking the promise, we can simply aovid being sued).
However, things get a little confusing. MS have declared that this promise is unilateral, in other words, it is a promise to the world without the need for a formal agreement. Such things are valid in the eyes of the law, and enforced by the fact promissory estoppel acts as an equitable remedy - there is no need for consideration, a key ingreediant to the traditional offer/acceptance/consideration contractual model.
Promissory estoppel is a common law principle. It's basis in England is from Lord Denning's High Court decision in High Trees.
Law bit:
In High Trees, due to WW2, the claimant ("High Trees") agreed to reduce rent for a block of flats. After the war, the claimant brought action seeking the past and future rent. Lord Denning said "When a promise is made that is intended to be acted upon, and is acted upon, you are estopped from going back on it."
In High Trees Denning referred, not to a previous case of Foakes v Beer (about the part payment of debt), but Hughes v Metropolitan Railway to establish his basis for promissory estoppel. In Hughes, it was held that the opening of negotiations for sale of a property had an implied promise not to enforce an outstanding notice of repair that would forfeit the respondents lease.
Key to the criticism over Denning's decision is that Hughes only suspended rights, whereas High Trees may extinguish them. This position has recently been approved in the UK by the House of Lords in Tool Metal Manufacturing Co. Ltd - the promisor may revive rights by formal notice, unless it is impossible for the promisee to resume his original position.
Is it impossible to resume the original position prior to this agreement? We're talking about computers here. The agreement has come now, not several years ago. Consider Mono as it is now, as the original position. This is such a contentious area when you consider MS can revoke the promise, creating ambiguity, and because under Coombes v Coombes promissory estoppel is not a cause of action, the Mono community cannot sue MS to enforce this promise!
Matt
Re:Promissory estoppel ftw -- Not so fast (Score:3, Interesting)
those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement the required portions (which also include the required elements of optional portions) of the Covered Specification that are described in detail and not those merely referenced in the Covered Specification.
Of course, anyone who thinks they can "design-around" a patent will claim that the patent is not actually "necessary" to the desired function. In order to enjoy this "promise" you have to confess that the only way to achieve the standard is to infringe on a valid MS patent.
Another po
Mono is now free to follow it's own path. (Score:3, Informative)
Thinking about it, the Community Promise is a huge win for Mono.
The Patent Trap was always a concern when I used Mono. I knew the external libraries ado.net, asp.net and winforms were "tainted" but was always unsure about the "core" on Mono itself.
Now that the "core" of Mono seems to be free from the patent threat from Microsoft Mono can take a new "patentless" path and develop equivalent versions of the libraries not mentioned in the Community Promise.
You won't be able to run Windows .net stuff (legally/safely) on Linux but you would be able to run Linux .net stuff on Windows.
GTK# seems to be a mature gui frontend the only major missing part is .ADO library for data access (unless something is already out there).
Mono does not *have to* follow Microsoft's upgrade treadmill and keep up-to-date compatibility with the latest version of .net instead concentrate on delivering applications on other systems - Linux, non-windows arm-based processors and macs.
In the end Mono could embrace, extend and extinquish Microsoft's own implementation.
But of course... (Score:4, Insightful)
This isn't meant to be helping Microsoft's competitors, such as Linux. Quite the opposite - it's meant to be helping Microsoft.
Proprietary lock-in the key to Microsoft's business model, whether we're talking about Office document formats, proprietary Internet Explorer extensions and incompatabilities or C#/CLI.
In this case it seems Microsoft accrues multiple benefits from open source developers who can't resist the free candy being offered:
1) It helps spread adoption of Microsoft's proprietary standards
2) It stops open source developers from pushing and developing alternative open source standards
3) It sets anyone (Mono) reimplementing these standards up for the future rug-pull when they change and/or extend the standard in the future, which will be done according to the needs of Microsofts business model
There's a reason the document format for Microsoft's office applications often changes from release to release, and it's not simply because new features are added. This is to force people to upgrade - which is the basis of Microsoft's business model. You can be sure that C#/CLI will be managed in the same way - don't expect Microsoft to keep these standards static now that they have "kindly" encouraged you to adopt/reimplement them. Quite the contrary, once there is significant open-source reliant upon them, then they have more incentive than ever to churn them.
Re: (Score:2)
No he will not and here's why:
Mono, which is related to .NET and CLI is much more than what ECMA standards specify yet there is no reference to those.
If he makes noise, he will have a point.
Re: (Score:2)
At which point Mono does the simple open-source thing of implementing just the ECMA spec (plus its own extensions in its own namespace) and all is good again and RMS is back to the "nothing to complain about in C#/.Net" position :)
Re: (Score:2)
That'd make Mono pointless, though. It'd just be another implementation of a system nobody uses.
Implementations in progress appear not covered (Score:5, Insightful)
From the Microsoft Community Promise [microsoft.com], with my emphasis:
Free software is often distributed to the public while in an incomplete state. This Community Promise appears not to apply to such an implementation that is published before it is completely compliant.
Re:No more FUD (Score:5, Informative)