Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Miguel Explains Himself

By avdi in Op-Ed
Wed Feb 06, 2002 at 03:11:16 PM EST
Tags: Software (all tags)
Software

Miguel has written a superb reply to those who have questioned his recent statements regarding the future of GNOME, .NET, and Mono. In the process, he makes some excellent points about language interoperability and code reuse.


Recently Miguel de Icaza (founder of the GNOME project) made some remarks about his hopes for basing future GNOME software on Mono and C# which drew a lot of surprise and ire. In this email to gnome developers, Miguel explains his statements, clears up some misconceptions, and makes some excellent points about software development.

Miguel starts by pointing out that his statements were taken out of context; and that regardless, he has no ultimate control over whether GNOME adopts his ideas or not.

GNOME is not adopting Mono or .NET as an implementation technology. The headline from the Register is misleading
I am not the GNOME foundation or control GNOME like Linus controls his kernel, I am just its founder and a contributor.

He goes on to talk about .NET, and software reuse (emphasis mine):

The CIL has one feature not found in Java though: it is byte code representation that is powerful enough to be used as a target for many languages: from C++, C, Fortran and Eiffel to Lisp and Haskell including things like Java, C#, JavaScript and Visual Basic in the mix....

This technology allows programming languages to be considered on the basis of how they will perform for a given task, and not based on the runtime libraries that you will depend...

So no longer should a software engineer pick Fortran, because that is the only language where his math libraries are available: he can now pick the right language for the problem at hand.

He points out that UNIX and windows share the problems of code duplication and API inconsistancy (emphasis mine):
Microsoft has terrible APIs to code against...

To make things worse, an evolution of APIs, components, memory management contracts and patched up versions of COM have made the platform horrible.

Microsoft has injected fresh air into their platform by building and designing a new programming platform that addresses all these pains...

Now, the Unix platform, GNOME included has some of these problems: our APIs have been evolving. Libraries have been built by disconnected groups (PNG, JPEG, Gtk+, Xml, Bonobo, CORBA spec apis, etc) and the end result is that a developer eventually has to learn more than he wanted to in the course of developing a large application.

And now we get to the crux of the matter:

Large software projects expose a set of problems that can be ignored for smaller projects. Programs that have long life times have different dynamics when it comes to memory management than smaller programs.

There is a point in your life when you realize that you have written enough destructors, and have spent enough time tracking down a memory leak, and you have spend enough time tracking down memory corruption, and you have spent enough time using low-level insecure functions, and you have implemented way too many linked lists.

He continues, explaining that GNOME is not going to be re-written in C# or anything silly like that. He does make the point that using .NET, it is very simple to extend existing applications in any language you want to use.

Finally, he reminds the audience that GNU itself was originally all about re-implementing proprietary technology; and that even if MS extends .NET beyond the ECMA-standard compnents, the Free Software community will still have a useful new development framework. Nothing will be lost by writing a free implementation of .NET.

GNU is a free re-implementations of Unix. Linux is a re-implementation of the Unix kernel. Before the advent of Linux and the Berkeley Unix, Unix was a proprietary technology, built by ATT (which back in the day, was a monopoly).

Still, developers took what was good from Unix, and reimplemented a free version of it. Down to the Unix programming language: C...

Think of Mono as following the same process: we are bringing the best technology out there to our beloved free software platform...

There is the issue that we might not be able to keep up (right now, we dont, as .NET Framework 1.0 is already out there, and we are, well still underway). Also, theoretically there is the risk of a given API being unimplementable on Unix.

Even if that is the case, we still win, because we would get this nice programming environment, that althought might not end up being 100% .NET Framework compatible, it would still be an improvement and would still help us move forward.

Now, as a hacker, I believe that being able to pick a language based on it's basic merits and your own proclivities, rather than the libraries available for it, is one of the greatest holy grails of software engineering. I don't know how many times I've thought to myself "gee, I'd love to code this in Ruby", only to wind up coding it in Perl because Perl was the only language with the existing libraries I needed for the job. As a dyed-in-the-wool OO programmer, it's sickening to see every new language reimplement hundreds of basic libraries from scratch. Just look at the scripting languages: Perl, Python, TCL, Guile, Ruby, etc... each one has it's own, incompatible set of libraries which do effectively the exact same things. And the developer communites for the newer languages, rather than spending their energy on creating brand-new, never-before-thought-of libraries, are busily re-doing all the work that went into something like CPAN, making the same mistakes, finding the same bugs, writing the same code.

One would think that NIH syndrome would be something only encountered in the competitive corporate world, what with Free Software's ideals of share-and-share-alike and being able to build on other people's ideas. But the amount of code duplication is staggering - just search on freshmeat for Gtk+/GNOME mail readers sometime. I've encountered the attitude myself in the Ruby community. I've brought up the subject of creating a Ruby-to-Perl bridge, so that Ruby code could use CPAN libraries (similar to the Perl Inline::* libraries), to be met with blank disinterest. Instead, I was told to add the libraries I needed to a public wishlist, so that Ruby developers could tackle re-implementing them when they have the time.

I'm sorry, but this is not the attitude of a Pragmatic Programmer. In accordance with the First Virtue of a programmer, Laziness, hackers reuse code whenever possible. I don't want some poor developer to have to go and recode and debug some boring library, making all the same mistakes the original implementor made all over again; I want to pull in an existing library from whatever language it was written in, and use it as if it were a native library. I want to write libraries in C++, back-end server code in Java, a web interface in PHP, a desktop GUI in Python, and have it all work together seamlessly, without having to write reams of interfacing code. This is the dream that Miguel and his Mono coders are in the process of making reality; and I say, more power to them.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Do you think programming languages should be more interoperable?
o Yes. Language choice should be independant of library availability. 55%
o Yes, but we can achieve it with existing standards like CORBA and SOAP 15%
o I don't care, I do all my coding in $FAVORITE_LANGUAGE 8%
o UNIX pipes give me all the interoperability I need 13%
o Code reuse is for wimps! 6%

Votes: 79
Results | Other Polls

Related Links
o Freshmeat
o superb reply
o recent statements
o GNOME
o Mono
o remarks
o C#
o surprise
o ire
o this email
o Ruby
o Perl
o Python
o TCL
o Guile
o CPAN
o NIH syndrome
o freshmeat
o Inline::* libraries
o Pragmatic Programmer
o Also by avdi


Display: Sort:
Miguel Explains Himself | 35 comments (32 topical, 3 editorial, 0 hidden)
Give CLR a chance (3.83 / 12) (#2)
by Eloquence on Wed Feb 06, 2002 at 02:32:36 PM EST

Here's what I wrote on Slashdot:

I think it's clear that using common bytecode offers some advantages to developers, as outlined by Miguel. It also seems like CLR can offer performance advantages over Java since it basically just maps native API calls to functions in the .NET framework, much like wxWindows or anyGui do for GUIs. If the classes are properly documented, it should be possible to match their functionality on other operating systems.

So what is Microsoft aiming for? Probably two things:

- Kill Java. They need to kill it before it becomes too wide-spread. They have a really good shot at doing so given Java's performance problems [insert thousands of flames from Java developers here] and C#'s advanced features like better encapsulation (you don't need to call set() and get() methods, you can map them to the = operator, for example).

- "Write once, run on Microsoft". In order to run .NET apps on another platform you would have to virtually re-implement (or substitute) the entire Win32 API, which will probably be modified at an ever-increasing pace. No company can keep up -- only open source may be able to do that, but Microsoft's opinion might be that open source is no real threat for the platforms where they want to deploy .NET. (After all, even the average Slashd^H^H^H^H^H^HKurobot seems to think that Linux will never be ready for the desktop -- quite idiotic, IMHO, but the more people believe that, the better.)

Insofar Ximian's Mono project may be a good thing as it offers a migration path where previously none existed (from Windows to Linux), even if .NET apps don't run properly on Mono (think about all the GUI stuff that can go wrong, for example). Besides, Java has never really been a mature technology IMHO and it's about time to replace it with something better, even if superficially less cross-platform.

Now the advantages of having a modular architecture become clear. Mono cannot break Linux, it cannot break X, it can probably not even break GNOME. There are more alternatives than you can throw a kernel image at if something goes wrong. Let's just wait and see what the Mono guys come up with. The only people who should worry about this are Sun and their followers. And maybe RMS.

Oh baby, real-time Slashdot comment recycling. Now I can finally decide which moderation system I find more effective ;-).
--
Copyright law is bad: infoAnarchy Pleasure is good: Origins of Violence
spread the word!

A Flame From A Java Developer (4.63 / 11) (#5)
by Simon Kinahan on Wed Feb 06, 2002 at 03:34:23 PM EST

Well, not really. I just thought I offer my thoughts on Microsoft's strategy and their chances of success.

I do not believe Microsoft can kill Java, whatever they do. It is already extremely widely used. Banks use it. Even Microsoft cannot kill a product used by banks. Just look at Sybase. The question is to what extent they can displace Java as the language of choice for new project starts in the critical middle tier arena. I appreciate that if you don't move in the right circles, its probably not clear just how far Java has spread, but I assure you it has.

The battleground is in the middle tier of enterprise applications. At present Java has a near-stranglehold there, and .NET is going in as the challenger. It is interesting how long it took MS to see where the competitive threat was really going to come from, and how long it took them to take it seriously. Remember all that "XML as a rival to Java" nonsense a few years back ? Java performance in this arena is more than adequate, because the network is the bottleneck, and because the only part of Java that is actually slow is Swing. Since the CLR's implementation technology is similar, and more likely than not more primtive, performance is a total irrelevance.

In some respects C# is a nicer language, although in others it is less good. They are extremely similar, though (as is Delphi, under the covers), so much so that the language itself is going to be decisive in very few cases. Similarly, the VM is not an issue. It is possible to compile other languages to both VMs (although with some obscure functional languages, the CLR is more efficient - big deal). It is also possible to compile both Java and C# to native code, although its easier with C#. Noone in their right mind is going to do this with their business critical applications, though.

Portability of the code itself will matter to some degree, and here Java does have the slight edge. People with really demanding applications remain suspicious of both NT and Linux. They want to run on Unix, probably Solaris, and there's not going to be a .NET CLR for Solaris for some time to come.

The crucial thing, at least to me, is the libraries. I am the kind of person Miguel describes. I have no desire ever to write quicksort again, or implement another linked list. I want libraries, and most importantly, I want the same libraries everywhere. This is the crucial area where I suspect Microsoft have defeated their purpose with .NET. J2EE is an excellent platform for what it does. Its this - Java's class library - which has really attracted people to it.

It is this which is the real essence of Java's portability: at least across the 3 fully supported platforms, it doesn't matter what OS you use, what VM you use, what database you use, or what application server you deploy on, the API is always the same. Its also the key reason for Java's success: a Java developer can work on any common combination of technologies, including Windows NT with SQL Server, and be equally productive. Not only that, but Java's library is actually *better* than most of the platform specific ones (GUI stuff aside).

Microsoft's problem, I think, is that they want to keep selling Windows. Thus they have to keep doing what has served them so well in the past: creating dependencies on Windows-specific APIs. Even though its dressed up in Microsoft's new "open standard, closed platform" clothes, its very clearly the same game. Therefore .NET has no class library of its own, and there is no prospect of Mono applications being cross portable with .NET applications the way Java apps are between platforms. At least for the true enterprise customers, this is going to be enough to put them off. Its also going to be enough to put developers off C#: no language has ever succeeded without at least a moderately rich standard library of its own.

If Microsoft were to give C# its own class library, one big enough to isolate the underlying platform, then I'd put the effort into learning it. Until that time, I don't think I'm going to have any serious problem finding Java work.

Simon

If you disagree, post, don't moderate
[ Parent ]
class libraries (4.00 / 3) (#6)
by avdi on Wed Feb 06, 2002 at 03:57:42 PM EST

Therefore .NET has no class library of its own, and there is no prospect of Mono applications being cross portable with .NET applications the way Java apps are between platforms

Er, as I understand it there is a .NET class library, it's one of the major elements of .NET. It's also one of Mono's main projects - implementing the standardized .NET class libraries (which encompass everything from I/O to XML processing) in terms of glib/Gtk+/GNOME. Read over Miguel's email, as well as the Mono site, and you'll see what I mean.

--
Now leave us, and take your fish with you. - Faramir
[ Parent ]

There is something ... (3.00 / 1) (#7)
by Simon Kinahan on Wed Feb 06, 2002 at 05:09:06 PM EST

... but I can't find anything on MS's website to indicate libraries on the scale of Java's. Even if there are, I would imagine they contain MS-specificities that would make them hard to port (Thread.stop() and so on). I'm prepared to be corrected on this, however, if anyone knows better for sure.

Simon

If you disagree, post, don't moderate
[ Parent ]
Some links (3.00 / 1) (#8)
by avdi on Wed Feb 06, 2002 at 05:32:35 PM EST

You can find the list of classes Mono is implementing, along with their current status here, and here is a list of classes Mono hasn't implemented, linked to their MSDN reference pages.

--
Now leave us, and take your fish with you. - Faramir
[ Parent ]
Class Library (3.00 / 1) (#9)
by mold on Wed Feb 06, 2002 at 05:44:13 PM EST

From the MSDN site. Took me a bit of digging to find it, but here is the .NET Framework Class Library

I could be wrong, but from the way this is all described, I don't see a huge Win dependency, excepting a couple of the libraries. Even then, if you look at them, a lot of the features could still be ported, with relative simplicity.

---
Beware of peanuts! There's a 0.00001% peanut fatality rate in the USA alone! You could be next!
[ Parent ]
Remember... (none / 0) (#12)
by blues is dead on Wed Feb 06, 2002 at 07:16:42 PM EST

Java class libs weren't large in versions 1.x.

[ Parent ]
good post with one nit to pick... (none / 0) (#22)
by ChannelX on Wed Feb 06, 2002 at 10:56:45 PM EST

Not only that, but Java's library is actually *better* than most of the platform specific ones (GUI stuff aside).
Actually the only part of the Java GUI where one suffers using Swing is speed and IMHO its still totally useable. Its not a speed-demon mind you but its useable. And its far more flexible than anything else I've ever used save for maybe the Smalltalk GUI stuff (VisualWorks). Swing is amazingly adaptable. That is one place though were people criticize it (overengineered which I agree with in some respects). JDK 1.4 seems to be much better from my working with it.

[ Parent ]
Anyone Remember AWT? (4.00 / 1) (#13)
by dadams on Wed Feb 06, 2002 at 07:22:23 PM EST

It also seems like CLR can offer performance advantages over Java since it basically just maps native API calls to functions in the .NET framework, much like wxWindows or anyGui do for GUIs. If the classes are properly documented, it should be possible to match their functionality on other operating systems.

How is this any different then AWT? So, maybe CLR does native calls a little faster, but this costs the language in terms of the overall security and portability it can provide. If I want fast native execution, I write native code. If I want portable, secure stuff, I'll go with a VM.

C#'s advanced features like better encapsulation (you don't need to call set() and get() methods, you can map them to the = operator, for example).

Wow. C#'s finally has one of the features of Dylan circa 1994. Still no closures, dynamic dispatch, or multimethods. Oh well. Maybe next language.



[ Parent ]
good post overall but... (4.50 / 2) (#23)
by ChannelX on Wed Feb 06, 2002 at 11:03:06 PM EST

I see someone else repeating the same mistakes that so many others have when you write:
- Kill Java. They need to kill it before it becomes too wide-spread. They have a really good shot at doing so given Java's performance problems [insert thousands of flames from Java developers here] and C#'s advanced features like better encapsulation (you don't need to call set() and get() methods, you can map them to the = operator, for example).
The space where Microsoft needs to take on Java, the server-side and J2EE, Java doesn't have a speed problem. People have mixed up crappy performance of early Java along with a helping of Swing performance and now all of Java is slow and it just isnt so. Java is being used all over the place and M$ had their chance to try to kill it and blew it. They simply don't have a good chance of killing it like you say they will. There are too many people using J2EE and too many heavyweights behind Java now. Hell...I just read an email from a mailing list where the guy saw JSP being used in a gas pump at one of the new BP gas stations here in the US. No...M$ had their chance and blew it. However that doesn't mean that .NET can't also be successful.

[ Parent ]
My thoughts (4.00 / 2) (#10)
by DJBongHit on Wed Feb 06, 2002 at 05:45:10 PM EST

When I first heard about Miguel's plan to reimplement a C# compiler and .NET-compatible class libraries, I was a little worried. I remember Microsoft's previous behavior when it comes to somebody competing with them, and I can envision a scenario where Mono is to .NET as Wine is to Windows (i.e. an only barely-useful alternative environment to run stuff in, where nothing ever works right).

But then I got to thinking - is Mono really competing with .NET? What does Microsoft have to lose from their applications being able to run on other platforms? A bit of revenue from their OS sales, of course, but that's really just a drop in the bucket compared to their revenue from, say, Office. Microsoft is, after all, a publicly-traded company, and we all know that they jump through hoops to make as much money as possible. It seems to me that Mono will help Microsoft more than it will hurt them, and if Miguel and others succeed (and they plan to port to OS X, as well, thereby providing nearly the entire desktop computing world with the ability to run .NET apps), Microsoft will be able to sell their Office suites and other cash cow software to people who run "alternative" operating systems without losing face by releasing a flaky Linux port (and let's face it - all commercial (closed-source) software tends to be flaky on Linux because of the wide variety of libraries and kernel versions).

The runtime environment would be open source and would be able to be recompiled/reconfigured to deal with different library versions, while maintaining compatibility with the .NET bytecode. End result? Microsoft makes a pile of money, and people running other operating systems can use Office, VC++, etc. It seems to me that everybody wins.

~DJBongHit

--
GNU GPL: Free as in herpes.

Mono is good for Microsoft, in the short term (5.00 / 1) (#26)
by Secret Coward on Thu Feb 07, 2002 at 03:39:55 AM EST

But then I got to thinking - is Mono really competing with .NET? What does Microsoft have to lose from their applications being able to run on other platforms?

Microsoft has a lot to lose from other peoples' software running on other platforms. Having an Operating System monopoly has allowed Microsoft to sabotage non-Microsoft products1, insure that Microsoft products function better than their competitions', and to leverage their monopoly power in countless other ways. Microsoft is not going to promote a product which poses a threat to that monopoly.

Microsoft supports mono for one reason, and one reason only: to make people believe that .NET is an open, competitive standard. You can rest assured that Microsoft has got patents pending on .NET. Once .NET becomes well established, Microsoft will utilize those patents (among other tricks) to strangle any competing platform.

It seems to me that Mono will help Microsoft more than it will hurt them

This is true for the short term. Once developers lock themselves into .NET, the illusion of openness will no longer be of any use to Microsoft.

---

1 Microsoft can create two versions of an API. A well-known published API that has a bug in it, and a secret version that works correctly. While tracking down a bug, my former employer reverse engineered part of Windows to discover that this indeed is the case.

[ Parent ]

Poll option (3.40 / 5) (#11)
by zephc on Wed Feb 06, 2002 at 05:48:52 PM EST

you forgot "I write my own languages" ;)

Hrm... (1.45 / 11) (#14)
by SkullRape on Wed Feb 06, 2002 at 07:46:56 PM EST

Wonder how much a sould is going for now....
This gui is spewing 100% microsoft propaganda....



Don't know about language agnosticism in the VM (4.00 / 2) (#15)
by martingale on Wed Feb 06, 2002 at 07:50:16 PM EST

I think that the goal of making it easier to mix and match library functions written in different languages is great, but I doubt it is the panacea that it is made up to be. Besides the fact that we can already make multilanguage library calls with a bit of effort (parameter calling conventions etc.), the basic problem I foresee is about granularity.

What happens when you pull in a function from a library is that your executable also pulls in lots of other related code, which that function may or may not depend upon. Granularity is a measure of how much extra, immediately useless code gets pulled in just because you use that one function.

Now let's say you write your mixed language hello world program in the .NET VM, and use three different functions coming from three different libraries written in three different languages. Each of these functions is going to pull in its own language dependent environment, ie all the code that's required for the function to work, plus some extra stuff due to granularity. In a big program, you'll have several, language dependent, api's for file handling, string handling, and so on, included in the code you run in the VM, because each is used by some function you call or a function you called calls.

If memory's cheap, will the resulting bloat matter? Certainly on a single user, single task machine, I'd have to say no. But what about multiuser machines and servers? That's where you'll see people restricting themselves to a single language.



You're missing something.... (4.00 / 1) (#17)
by spcmanspiff on Wed Feb 06, 2002 at 08:28:20 PM EST

Mono / .NET have a standardized library as well as runtime.

It provides a standard way to do stuff, regardless of language. The problem you mention is the exact one that Mono is attempting to solve, not worsen as you suggest.

Stuff like "file handling", "string handling", and so on is the other half of what Mono brings to the table.

I'm not sure Mono will be successful or fail, nor am I interested in rushing to judgement on it. It should prove to be a fascinating expirement to watch at the very least, and hopefully it can bring to Gnome everything Miguel is promising. If not, there's always KDE -- not to mention all the non-Ximian Gnomers.


[ Parent ]

still not convinced... (5.00 / 1) (#18)
by martingale on Wed Feb 06, 2002 at 09:55:30 PM EST

Isn't that in some way the crux of it? Where does the strength of your language of choice come into the equation if you use exclusively the standardized library?

For example, I like to use Perl for text matching and manipulation with regular expressions. The language is designed so that these operations "slip off the tongue" so to speak. If the standardized library offers a class hierarchy for regular expressions (couldn't find one on your link, but someone will write one I'm sure, like the GNU regexp class for java), then either

  • I use it, obtaining the benefit of a standardized api and foregoing the advantages of Perl's language integration of pattern matching.
  • I use Perl's own language integrated regular expression processing, ignoring the standardized library.
Now I might use a Perl module in some other part of my code, which was written say before .NET, and uses the Perl regexp facilities. Somewhere else in my code, I'm writing a C# subroutine and I need a quick pattern match, so I need to use the standardized regexp class hierarchy there.

Of course, this type of problem would be solved by redesigning Perl to take advantage of the standardized libraries, but that's not going to happen. So instead, people may decide to somewhat "standardize" on the language to be used for the project.

I'm not dismissing Mono / .NET, just like you I think it'll be great to watch things unfold. But I think my point is relevant, and I'd like to know how it can be addressed.



[ Parent ]
More questions (4.00 / 1) (#24)
by rusty on Wed Feb 06, 2002 at 11:31:35 PM EST

That's an interesting point. What if, for example, there's a great module in perl do do a Foobar Transform. I'm used to using it, and it's clearly the fastest one out there. But it was written before Mono, so naturally it uses all of perl's native facilities for things like file handling and strings and so on.

So your problem crops up. In order to avoid that, you'd have to rewrite the perl Foobar Transform module to use the Mono "standard" stuff. In which case you still have the same problem we've always had -- that code in one language doesn't like to work with code in another language.

Unless compiling the module for a Mono (.NET) platform would trick old code into using these standards, without any rewriting necessary?

This article made it much clearer to me what .NET is actually supposed to be. Hopefully someone who knows more about it can make this point clearer too.

____
Not the real rusty
[ Parent ]

Answers (sort of) to both of ya... (none / 0) (#25)
by spcmanspiff on Thu Feb 07, 2002 at 02:06:39 AM EST

While I'm kinda reapeating saleshype and not basing this off of any true research/use, I think that the deal here is that before using a lanugage with Mono, a compiler for the common runtime needs to be built.

That compiler would (presumably) translate native language facility calls like regexps/file access into standard library calls.

As far as the Foobar Transform.... using your Perl->.Net compiler, you compile the module into a Mono package -- thus making it available not only from your Mono-perl implementation, but also from any Mono language you like (with runtime reflection, automagic and consistent garbage collection, hype hype hype :)... So yes, 'trick', maybe :)

I think it would get difficult if the module itself depended on, say, a bunch of CPAN things. You may well have to rewrite the Foobar to use the standard library features instead, and yeah, that would be a pain in the ass. But I still think the neat benefit in the paragraph above is worth it.

Caveats: AFAIK Perl doesn't have a compiler to .Net yet (no real research, though, just don't remember seeing it on the list).

Interesting stuff -- I hope it works as promised, but right now waiting and seeing.


[ Parent ]
clarifications semi-OT (none / 0) (#30)
by martingale on Thu Feb 07, 2002 at 07:22:20 PM EST

I've just gotten around to reading the quoted Meyer article, and while it doesn't directly address the questions raised earlier in this thread, I think it's quite an eyeopener. Let me give a rough summary of what it says, bearing in mind it's focused on object oriented technology:

Meyer starts out by stating that .NET is really an object model framework. Think of it like the Java class hierarchy on its own, without the Java language. The idea of complying with .NET is that languages (Java#, C#, Eiffel#) must integrate the class hierarchy seamlessly. So for example, fundamental concepts like integers and characters are objectified (just like in Java, there are object wrappers Integer, Character) and become fundamental .NET objects . Your compliant language, when it manipulates integers, really now manipulates .NET Integer objects.

Now this is a major undertaking, to retrofit a whole class hierarchy into a language, especially if the language is not object oriented to begin with. So there's the idea of levels of compliance. I'll quote Meyer:

  • Compliant producer: this ensures that your components (by avoiding non-universal mechanisms) can be used by anyone.
  • Consumer: if your compiler satisfies this, your classes can reuse, as clients, components written in any compliant-producer language.
  • Extender: if your compiler satisfies this, your classes can extend classes from any compliant producer language, that is to say, inherit from these classes and redefine (override) their operations.
This all works because there's a common bytecode for all .NET languages, which means you can pick up a bytecode class X and use it in your program exaclty as if you had defined it yourself. Your language can read its internal structure because when it was compiled, the component was given some extra metadata.

There's also a concept of how to deal with non-compliance. I'll quote Meyer again:

Not all applications will want to rely on these [.NET] services. This is where the notion of managed code comes in. Code is managed if it relies on the runtime s services, unmanaged otherwise. Managed and unmanaged code can coexist; as noted above, C++ will only let you enjoy the benefits of full managed code if you limit your use of the language to a subset that roughly corresponds to a C#/Java style of programming (no multiple inheritance except from interfaces , no friends ).


[ Parent ]
Thanks (2.00 / 1) (#16)
by e9ki on Wed Feb 06, 2002 at 08:08:10 PM EST

Thank you, Miguel, for clearing that up.

I was a bit worried, well, as worried as someone with only two years of Gnome and Linux usage under his belt could get.

This changes everything.

You've done a fantastic job thus far, and most of us trust your instincts on this project.
Thanks Again.
~~~~~~~~~~~~~~~~~~~~~~~~~
"Wit is educated insolence." - Aristotle (384-322 B.C.)
~~~~~~~~~~~~~~~~~~~~~~~~~
Alan Cox (4.25 / 4) (#19)
by blues is dead on Wed Feb 06, 2002 at 09:57:04 PM EST

The interesting part is with Alan Cox.

I'm curious why Alan thinks C can be implemented efficiently on the JVM (without "cheating" optimizations that slow everything else down), but more telling is when Miguel did not respond to one of Alan's points...

He has clearly thought about the issue, and I can see an answer he'd rather keep mum about.

What's so great about all this? (none / 0) (#20)
by enterfornone on Wed Feb 06, 2002 at 10:09:26 PM EST

Apart from the odd bit of PHP I'm not really a programmer, so perhaps I just don't get it. From what I can see .NET is just another virtual machine like Java. As popular as Java might be it hasn't really put a dent in native code and it's never likely to. Why would .NET be any different? I really can't see MS or anyone else scrapping native code for major apps like Office. From what I've seen of the MS .NET strategy, it's more about creating web components. And I can't see too many people learning C# when they can just use Flash.

--
efn 26/m/syd
Will sponsor new accounts for porn.
not quite (none / 0) (#21)
by ChannelX on Wed Feb 06, 2002 at 10:45:26 PM EST

the whole idea of .NET is a lot larger than just a virtual machine. I think its more akin to J2EE then just the Java language.

As to scrapping native code: if C# apps are as fast as native (I have no clue what the speed is) there is no reason *not* to scrap C++/native code. Easier to write something complex in a language like C# rather than C++. Its a safer and much more robust OO-wise than C++ ever will be.

[ Parent ]

Wow. (none / 0) (#31)
by DeadBaby on Thu Feb 07, 2002 at 10:09:51 PM EST

You are SO wrong.

-C# has nothing to do with Flash. Not even a little. That's like comparing Crayons to a Crayon factory. The .NET GDI+ libs are quite useful for graphics but at very best they'd be implemented using ASP.NET and not C#.

-.NET isn't a virtual machine. It does however use bytecode to allow portabiltiy using managed code. If you have a full .NET implementation on another platform, .NET bytecode (IL) files will run on it. Java uses a VM + a managed lib, .NET relies fully on compatible managed libs.


"Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity -- in all this vastness -- there is no hint that help will come from elsewhere to save us from ourselves. It is up to us." - Carl Sagan
[ Parent ]
re: bytecode (none / 0) (#32)
by martingale on Thu Feb 07, 2002 at 10:46:21 PM EST

Just a small clarification, if you please. Are you saying that unmanaged code is not goind to be portable at all? See my earlier comment titled "clarifications semi OT". If some C++ constructs, such as multiple inheritance, means that the resulting code is classified as unmanaged, does it still get compiled into bytecode? If yes, then I don't see why unmanaged code cannot be portable. If no, then how's all that legacy code we have going to be .NETified?



[ Parent ]
So far.. (none / 0) (#34)
by DeadBaby on Fri Feb 08, 2002 at 07:35:48 AM EST

Well, this is my understanding to this point:

-MSIL is advanced enough to run most legacy C++ code. However, the .NET runtime simply doesn't support some features of C++ so those aspects of your code will need to be re-written if you want fully portability. As you mentioned, multiple inheritance in C++ is a good example of this.

-I believe that the compiler WILL generate MSIL code, even for unmanaged code but those parts of the code that are unmanaged won't be fully .NET-ized but if you understand the parts of your code that are effected, it might not be a huge problem.

-There's also a set of Managed Extensions that are supposed to allow you to continue using unmanaged code while still accessing all .NET features.

There definitely seems to be a middle ground for developers though, to this point I've mostly used C# so I'm not positive how useful these features are outside of theory.

"Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity -- in all this vastness -- there is no hint that help will come from elsewhere to save us from ourselves. It is up to us." - Carl Sagan
[ Parent ]
Not virtual machines (4.00 / 2) (#27)
by Snagged Umbra on Thu Feb 07, 2002 at 01:30:07 PM EST

[Addressing some of the commentors, not the original article.]

There seems to be widespread misunderstanding about the use of virtual machines (VMs) for Java and .Net.

Early implementations of Java used virtual machines. The JVM implementations of interest were the "reference implementation" from Sun, early production implementations from Sun, and the proprietary implementations for the MSIE and Netscape browsers.

All modern implementations of Java, except for embedded systems and Sun's "reference implementation", are done using Just-in-Time (JIT) compilation to native code. This includes the production version of Java from Sun. It is fairly safe to assume that any Java2 (Java 1.2, 1.3, or 1.4) implementation for a general-purpose computing platform (Windows, Linux, Unix, Mac, etc.) is a JIT compiler.

AFAIK, Microsoft has no plans to create a VM for MSIL/CIL, which is the .Net equivalent of Java bytecode. MSIL was explicitly designed for compilation to native code, and all planned implementations are JIT compilers.

The advantages and disadvantages of VMs are therefore irrelevant to the discussion at hand.

Not virtual machines? (none / 0) (#28)
by martingale on Thu Feb 07, 2002 at 06:26:40 PM EST

Now you've confused me a bit. What do you call the piece of code which understands and executes the Java bytecode or MSIL/CIL, which keeps track of which line of the program we're currently running, which makes the system calls on our program's behalf?



[ Parent ]
There isn't one (5.00 / 2) (#29)
by Snagged Umbra on Thu Feb 07, 2002 at 07:16:50 PM EST

There is no such animal.

As your program runs, the JIT compiler translates the bytecode or CIL coding into native machine code (Intel, for most of us). The exact amount that is compiled at a time varies among JIT compilers; it could be an entire program, a class, a method, a piece of a method, or whatever. For Microsoft's CLR implementation, they compile method by method.

This paper contains this description of .Net's JIT compilation process:

Before a method can be executed, it must be compiled to processor specific code. Each method for which MSIL has been generated is JIT compiled when it is called for the first time, then executed. The next time the method is executed, the existing JIT compiled native code is executed. ... The recompilation can be avoided by compiling the code during installation into native executable code.
This article contains an overview of how Mono plans to do the same thing:
Mono's JIT translates CIL instructions into native code at run time. The JIT compiles an entire assembly in one pass, or one method at a time the first time each method is invoked.
That article also notes that:
[A] virtual machine does not exist in any ECMA-compliant implementation of .NET. This is because the ECMA specification stipulates that all CIL be Just-In-Time (JIT) compiled into native code before it's executed.
Here is a very technical overview of .Net's JIT compilation process (PDF).

[ Parent ]
Not what Miguel recons.. (none / 0) (#33)
by enterfornone on Thu Feb 07, 2002 at 11:06:27 PM EST

From the Mono FAQ:

Question 3: What technologies are included in Mono?

Mono contains a number of components useful for building new software:

A Common Language Infrastructure (CLI) virtual machine that contains a class loader, Just-in-time compiler, and a garbage collecting runtime.

A class library that can work with any language which works on the CLR.

A compiler for the C# language. In the future we might work on other compilers that target the Common Language Runtime.

--
efn 26/m/syd
Will sponsor new accounts for porn.
[ Parent ]

most do (none / 0) (#35)
by Pink Daisy on Fri Feb 08, 2002 at 09:23:10 PM EST

Most JVM's have an interpreter as well as a JITer. For example, both the Sun Hotspot JVM and IBM's JDK have an interpreter and don't compile until a threshold is reached. The Jalapeno research JVM from IBM uses a compile-only approach, but that is highly unusual.

Most of the research suggests that it is better to interpret before compiling, and to compile selectively. An excruciatingly well-written interpreter executes one to three times slower than a very fast (ie. non-optimizing) compiler. Much code is executed once (for initialization) or not at all (for handling errors that don't occur).

I can believe that Microsoft would do that, since it is not much slower to use a very cheap compiler even on the run only once code. If the .NET bytecodes are more easily compiled than Java bytecodes (I don't really see how they could be in the simplest case; being easier to optimize wouldn't make a difference there) then there might be a win every time. Problem is, even though the time difference isn't much, it's most visible when the program starts; to the user the compilation delay for this stuff looks like the program is sluggish when starting.

[ Parent ]
Miguel Explains Himself | 35 comments (32 topical, 3 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!