Mono Poises to Take Over the Linux Desktop
Edd Dumbill writes "Miguel de Icaza and the Mono team recently hosted a two day open meeting in Boston. O'Reilly have just published
my report of the meeting. Highlights include
Miguel's view that 'C is dead!' and the Mono approach
to dealing with Microsoft patents on .NET."
This falls under the "I can't believe what I'm hearing" category...Mono is *not* ready as a plug in replacement for .NET, and it won't catch up before MS releases 1.2...for the foreseeable future, it's trailing behind the Windows implementation and is not likely to catch up.
I see PyGTK as a much more reasonable (and WORKING) alternative to C programming for people who want to write Gnome apps. Or GTK--, for that matter. Mono currently has crappy System.Windows.Forms support (even with Gnome#), broken serialization support, the list goes on and on.
I've been playing around with the Mono implementation of C#, and it's pretty good. It's not quite as good at RAD tasks as Python, but it has some advantages, and the syntax is much easier to play with than C or Java (but again, not quite as easy as Python, but I'm biased in that regard).
However, Mono suffers from the fact that they're trying to play follow the leader by following Microsoft's implementation rather than creating a system of libraries from scratch. Microsoft has a history of pulling the old "embrace and extend" trick, and I fear something similar may happen here.
My guess is that Microsoft will significantly alter the .NET APIs for Longhorn, leaving Mono behind with older legacy libraries that are no longer interoperable with the Microsoft compiler and the rest of the Windows-using world. Needless to say, that would be bad for the Mono team.
Still, if Mono can remain independent, it could very well have a bright future. The Mono team has done a great job of implementing most of the 1.0 .NET API, and the mcs compiler is pretty fast. The GTK bindings are quite nice for such an early release.
Still, the cognitive dissonance of compiling a Linux program and getting a file with an .exe extension is rather difficult...
A very good illustration of this is in the attempt to create a Python.NET implementation by the folks at ActiveState. The report on the lessons learned is rather enlightening.
the growth in cynicism and rebellion has not been without cause
How?
.NET except for the Microsoft namespace of the class library. They have given up their right to sue people who use .NET or make .NET compatible implementations. The evidence isn't on their side.
MS has given everyone license to implement every part of C# and
Hint: ECMA.
====
Crudely Drawn Games
Put in a GTK or QT library interface instead of the slow and huge Swing (that Smalltalkers foisted on Java) and you're golden -- there's every reason to use Java, especially for applications.
SWT is a crossplatform UI toolkit that feels like a native app, unlike Swing. In Linux it's just a wrapper over GTK or Motif.
" Microsoft didn't just dream this up overnight..."
.NET was *purchased*, not created, by Microsoft.
.NET when they
purchased Colusa Software on on March 12, 1996. .NET CLR?).
Like most/all of Microsoft's "innovations",
Microsoft inherited what become
At this time C/C++ and VB environments already existed for Colusa's "OmniVM" (which became the
To clarify - I do alot of work with C# and find it to be the least unpleasant Microsoft development environment I have experienced.
Score 5, Troll?
Well, if we can get to the point where we can do things like those shown in this Longhorn video, development for Linux will definitely increase.
By the way, the video is worth watching not only for the cool technology but also to hear two Microsoft programmers ragging on each other. Totally opposite the kind of atmosphere you'd expect at Microsoft, I suppose.
Operator overloading could redefine the equal sign to mean something else (such as compare if a equals 2).
Property You can think of this as a wrapper around a variable. When the variable is accessed, you can do some automated processing before returning (or storing) the value. In code, you can treat a property just like a variable.Game over.
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
The first programming language(s) were coded in ASM, Assembly Language. Although ASM is a "language", it doesn't need to be translated and compiled like something like C. Each operation corresponds to opcodes, which are usually one or two bytes, that the CPU can directly read and interpret. Once powerful and stable C compilers (written usually in ASM) started to appear, new languages were usually directly written in C, but always containing some ASM.
The main problem that confuses people (such as the argument that C# was written in C#) are the IDEs (the Integrated Developpement Environment), which is merely a graphical frontend to do your work. So yes, the VS NET 2003 UI was made in C#, but the compiler for C# was written in C and ASM.
I hope this makes sense...it's 2:30AM...lol
Best regards,
Alex Ionescu
Relsoft Technologies
I believe you have boxing & unboxing reversed. I didn't know the definitions before this, but the ones you gave didn't seem intuitive to me, so I searched google for "autoboxing", and found several definitions that are the reverse of yours.
Miguel said, "C is dead", sure.
But how about some context. This is what he actually says: "To me C is dead. Except for the JIT!" (emphasis mine).
He's not saying C is gone, that nobody is going to use it anymore. He's saying that he's not using it anymore, except to write the JIT compiler for mono.
So the quote is accurate, but the meaning is completely changed once you put it into context!
I take that to mean, "As far as the world of Mono/.Net goes, C is dead."