Slashdot Mirror
Mono and .NET - An Interview
all-of-the-dot writes "Would you use an open-source implementation of the .NET Framework? Ximian's Mono project enables you to build .NET apps that run on Linux and Unix as well as Windows. Check out the story from .NET Magazine's interview with Miguel de Icaza, Ximian cofounder and CTO" Added to which, AirLace writes "The Mono project has just achieved full self-hosting on Linux. While the C# compiler, itself written in C#, has been able to compile itself since March, Mono can now compile its own complete set of class libraries too. This announcement closely follows the release of the Phonic media player, the first .NET application for the GNOME desktop."
the other parts of .net such as passport, application services and MS web services are the troubling part. mono has nothing to do with these.
> And Mono is why I swtiched from Gnome to KDE.
.NET in GNOME.
> Any more questions?
Yes, I have the following question:
Why does a small group of developers (some of whom happen to also work on gnome) working on the mono project constitute a reason to abandon gnome?
Mono is in no way linked to the gnome desktop, and IMHO is unlikely to become thusly linked in the near future. The opinions of Miguel (sp?) may have misled you... there is no
But then I reconsidered. First, a little background. C# was, is, and always will be, a Micro$oft invention. Like it did with SMB and OLE, not to mention DirectX and ZIP, M$ will have no reservations about mucking with C# just to break Mono compatibility.
C# is an ECMA standard, like C++ which is an ISO standard unlike Java which is Sun Microsystem's property. Thus Sun has complete control over the future of Java while Microsoft does not have the same for C#. So claiming supporting C# is supporting Microsoft is way off base. Question: Were DirectX, OLE and SMB also international standards or are they technologies wholly owned by M$?
Developers in the Windows world that do not care about cross platform issues (which is, 99% of them) are tired of C++, and Visual Basic, and C# happens to be a nice language to move to delivered by the company that does their OS.
So people will be adopting C# as a programming language no matter what anyone does. The language is here, and the tools are here, and the community is rapidly growing.
So what we are enabling is to bring a number of things to Linux: we bring the people, the knowledge and we are reusing Microsoft's investment in documenting, promoting and producing training materials to benefit us.
So, I am fairly possitive that this is good.
And then, there is the added advantage of open source: now you got a compiler, a runtime and classes. If they serve your purposes, take it, improve it, extend it, change it, modify it, rip it, research, reuse what you feel like reusing.
Miguel
I co-authored an article that compares all the open source implementations of the .NET CLI. You can find it here.
We are not planning ourselves on writing one, but several people have expressed their interest on doing so.
There is already a proof that this can be done (Microsoft's JUMP), but it is not fundamentally a hard problem either.
There are three groups of people to my knowledge working on free software versions of such a tool.
Miguel
Already been done. It's called Rotor, and is a Shared Source project, meaning you can see the source and modify it for non-commercial uses, and it even has a nice clause saying that you can't taint yourself by looking at the code (oh, if only the GPL had such a clause. Instead, I can't look at GPL'ed software for fear of tainting my thought processes and inadvertantly ending up with GPL'ed code in software I write). Rotor is mostly meant for academic use and study, and is just a reference implementation (for instance, the GC is very primitive, and is much better in the .NET runtime from Microsoft). However, it builds for both Windows and FreeBSD (probably other BSDs).
Not from Microsoft. You could probably compile Rotor with minor changes on a Linux system, but it'll be completely unsupported by MSFT (well, more unsupported than Rotor already is, which doesn't have any official support but the dev team helps out when they can).
You'd be wrong, of course. The reason people bring this up is because Microsoft once used the reference implementation of the TCP/IP stack which just happened to come from a BSD (hrm ... the BSD license is very liberal, not forcing you into any specific license, which makes it perfect for providing reference implementations -- anybody can start with that implementation and change it how they please and not be stuck with the GPL). XP is based on Win2K, which is based on NT4, which is based on earlier NTs, which ultimately derived from the same people that wrote VMS, so you could say that XP is a descendant (several generations removed) of VMS, but you won't find much (any?) VMS code in XP since NT wasn't directly based on VMS (just the concepts and ideas). (Throw some OS/2 in there, just to be complete.) However, XP != BSD, nor would I expect Microsoft to release any BSD-backed (or other *nix-backed) OS in the near-to-mid future (who knows about the long term, really? It's probably safe to say "not likely" here).
You can call non .NET programs from within .NET. If you decide to use a library that only exists in Windows (like DirectX) or in Linux (like that version of GTK) then of course it only works in that system.
Once more of Mono is complete, you'll be able to do the whole of your program in it, including the libraries, and moving between Windows and Linux will be transparent.
My Journal
"We all know they're using .NET as a way to lock people into Windows servers and desktops."
.NET is platform independent on the client side.
Lock people into Windows servers, maybe, but not into Windows desktops. Although MS only supports running ASP.NET on a Windows server, the client receives pure HTML that can be viewed in any browser on any platform. Most of
I don't know about the HMTL-down-to-DB stuff.
.NET has nothing to do with "Microsoft plan", or locking yourself out of your own source code, or limiting what you can do with your code. You can work in as low a level you want and never touch a wizard/GUI-builder. They're just simple ideas that help you to write CODE faster, easier, AND better.
.NET, I expect the Java development tools dramatically, and I suspect the same will happen with other languages.
But I have to say the MSFT tools are really impressive, precisely because you don't have to choose between using the tools and designing and writing the program yourself.
Jumping back and forth between the code and the GUI is a breeze, and the code auto-generated by the GUI is amazingly clean, easy to modify by hand.
But it's the simple idea of #region what I have found makes the greatest difference in coding. I expect to see similar support for these in other tools, and I hope in other languages/platforms.
As a matter of fact, what I like about Visual Studio
There's no reason for other tools not to be able to copy VS.NET functionalities and provide decent IDEs for Java and other platforms. I fully expect them to do so, because I'm a Java programmer. As a result of
Freedom is the freedom to say 2+2=4, everything else follows...
Suppose that I decided to use .NET on Windows. I look around, and find that they support Perl. Cool, so I go and use some Perl libraries in various places. Perl is as cross-platform as it gets, I am fine. Right?
.NET sucks goat d*ck on handling dynamic languages. Since Perl on .NET was too slow, even by .NET standards, its "integration" is through a custom modification that exports a COM interface, that is imported into .NET. Works fine on Windows. But on Linux, what then?
No. I am utterly fscked.
Perl uses a dynamic programming model.
And once people get going, how many real applications are going to use Windows forms, or link in some other library, or link in a COM interface from a legacy app, or otherwise become unportable?
Care to guess whether future tools from Microsoft will "encourage" you to introduce such dependencies?
Thanks, but no thanks. I have had to work with Microsoft APIs too much for my taste. That is why I try not to now.
DotGNU is = Portable.NET + other_stuff.
Portable.NET and Mono are doing the same things. Mono is a lot more advanced than Portable.NET: JIT, a working compiler, large development team.
About the `other_stuff', I have never been able to figure out what it is, or what they are doing.
It is a duplicated effort as you very well point out. From the Ximian perspective, we did have the resources to work on this project, and we had our developers work on it.
There is very little emotion in either my post or my decision.
.NET Framework?"
.NET was not taken as the platform of choice and the reasons were not technical. I think .NET will certainly be competent, as the technical lead was the guy behind Delphi.
.NET. The possibilty of that occurring moves .NET to the back of the pack as their counterparts can already do what I need without that extra weight looming over the project.
The question posed by the article was "Would you use an open-source implementation of the
I listed the reasons why
I am a GPL software author. C# is an unproven new language to assess in my choices. I am absolutely going to judge the likely future of a language by looking at the past history of the company who will be managing its development.
Microsoft has quite openly stated that they think GPL is a virus, and there has been rumblings of making it illegal to use their development tools in the creation/conjunction of GPL software or libraries (which is their right to do).
However, a major software project is a large commitment of time--porting to another language down the road is unlikely to be trivial. if Microsoft takes their familar road with C#, and my code becomes illegal to compile, or I now everyone who wants to work on the software now has to fork over $500 a year for a MS-blessed C# compiler to be able to contribute to the GPL project, I will have regretted my choice of
But the results also matter. Here are some development snapshot screenshots, fresh off a clean compile on Linux and MSW, built with wxWindows with no MFCs, Microsoft dlls or anything else that can be made illegal or prohibitively expensive later on:
http://www.clinicalexam.com/pluckerdesktop/tour
-----
Cast a Cold Eye
On Life, on Death
Horseman, pass by
--W.B. Yeats' gravestone
C++ - write it and hook it in via JNI :-).
VB - You wanna code in VB?!?!?!?!
Python - run Jython (python 2.0 language on the Java VM)
Also, check out Languages that run on the Java VM for a surprising number of languages (including basic) that already run on top of the Java VM, on any platform that supports java, hell - even the GUI works properly