Slashdot Mirror
De Icaza Responds on Mono and GNOME
miguel writes: "Here is my reply to the various questions on Mono, the future of GNOME and the Register statements." Linux Today has a copy of the email as well.
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Miguel himself responded to this point:
.NET Framework 1.0 is already out there, and we
.NET Framework compatible, it would still be an
"There is the issue that we might not be able to keep up (right
now, we dont, as
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%
improvement and would still help us move forward. So we can reuse
all the research and development done by Microsoft on these ideas,
and use as much as we can."
This applies just as much to being intentionally broken by Microsoft as it does to them simply outpacing Mono's development.
You do raise an interesting point. Some features are not available to all languages (for example, a LISP closure definition).
But there is a large subset that is. This subset is encapsulated in the Common Language Specification (CLS) which differentiates between:
* Consumer languages.
* Provider languages.
* Consumer/Provider languages.
You can find the details here:
here
Miguel
That doesn't help much. If it has patented yet unlicensed technology, then it can't be legally used in countries where the patent is recognized.
This is why free crypto software for a long time had an internal-RSA vs. external-RSAREF configuration switch for a long time, with the stipulation that RSAREF had to be used within the U.S.---as using internal RSA would leave you open to an infringement suit. (RSAREF was the only freely licensed implementation of RSA available, before the patent expired last year)
iSKUNK!
I think he does realise it. He pointed out that even if it isn't compatible, he'll still end up with a better development environment, at the expense of MSFT's R&D department.
.NET Framework 1.0 is already out there, and we
.NET Framework compatible, it would still be an
To quote:
* What if we never can keep up?
There is the issue that we might not be able to keep up (right
now, we dont, as
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%
improvement and would still help us move forward. So we can reuse
all the research and development done by Microsoft on these ideas,
and use as much as we can.
From the statement:
:)
:)
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.
Let's forget for a minute what the source of this new byte code language, or standard, is. If it truly delivers the above, that would be quite an accomplishment, and probably a good thing. Remember I said, forget about the source for a moment...
What I wonder is, how does for example parrot measure up against that? Parrot seems to be moving quite slowly, but I might be mistaken since I am not involved. Since it apparently is the new engine for perl 6, I'd say it must have something going behind it.
Anyhow, one of the things with parrot is at least said to be the possibility to compile a lot of other languages besides perl, such as python or java into parrot byte code - something that indeed would be a good thing for portability and the ease of running a little of whatever on any platform. I am not sure how deep these plans actually go, and how feasible it really is.
But parrot is where I would like to set my hopes, so can anyone tell me - do I wait in vain? Is CIL really the way to go? Or are we, in reality, simply stuck with different compilers and/or interpreters for different languages?
Of course, with Mono you get all that neat stuff while still being able to code in _whatever_ language(s) you want and have it work transparently and consistently.
Whatever language you like so long as its semantics and runtime behavior have been massaged to work with the CLR.
Really, the CLI/CLR is just like the Jave byte codes and JVM, except that CLR's is a bit less strict about security and in that the CLR's support for 'unmanaged' code allows for cleaner support of native machine code than does Java's JNI interface. It's a convenience thing, much as Visual C++'s helpful COM automation wizards are a convenience thing.
The biggest difference between Java and the .NET framework is that Java's bytecodes and VM are a bit more paranoid about things like security, and that Java is designed with portability as a first order concern. .NET code will probably never be as portable as Java, precisely because it is designed to make it super easy to interface with operating system level code. Java is designed to make it a pain to use any code that isn't itself portable.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Not true at all. Look at Apple's Cocoa framework, which allows you to write native Mac OS X applications in Java. Sun has no problem with that, because Mac OS X also includes the 100% compatible pure Java envrionment. Sun sued Microsoft not because MS added features, but because they deliberately introduced incompatibilities in the core Java classes.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
Craig: "But look: we're a business, okay? We're in the business of licensing intellectual property. So if it turns out that in the future that business says, "Okay, we should license the patents to people who use that in order to be compensated for the development of intellectual property," maybe we'll do that. You're always welcome to come and ask us to license anything from sources to patents. But I mean, we are a business. We're not --
...
Craig: Well, at the end of the day, if you have a patent, you enforce the patent if it's valuable to you. And so I think that Microsoft and other people who have patents will ultimately decide to enforce those patents.
Brian: Are there any patents that apply or that will apply to implementers of .Net or Hailstorm?
Craig: I expect there certainly will be. I mean, the patent process takes a long time.
Sun does charge fees for J2EE. What made you think otherwise? What makes you think Microsoft couldn't charge huge fees for Windows XP server? (Oh yeah they do...)
Remember - it was Sun that renegged on ISO and EMCA standardization - not Microsoft.
Right, except it wasn't "not Microsoft" it was "because of Microsoft".
Sun has always stated it won't opposed clones (including open source clones) of Java, as long as they aren't called "Java". Microsoft's Java escapades were completely different - it licensed Java from Sun then proceeded to release "embrace and extend" enhancements.
Sun's "Java Community Process" is a complete sham and everybody knows it. Sun's vote is the only one that matters.
This ignorant statement simply shows that you have no clue about the JCP. Do a little research.
Why are you posting anonymously anyhow...? ;-)
299,792,458 m/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
The patent issue could be a problem, but there are a few things to lessen the worry:
1)Mono is being conservative and only trying to implement things that are already in existence. See this quotation: "We are trying to stay on the safe side regarding patents. That means that we implement things in a way that has been used in the past and we are not doing tremendously elaborate or efficient things in Mono yet. We are still very far from that. But just using existing technologies and techniques." from MSDN.
2) You say: "My worst fear is everything would go incredibly well with mono: diverse compilers, robust libraries, etc. and we would all start to build code around it, and then about 5 years down the line Microsoft whips out a patent and demands royalties for all the labor that we have done under the illusion that it would be free." It is unlikely that a surprise patent is going to bite you 5 years down the line. It is true that until a patent application is finally accepted or rejected, the patent claims are secret. See 35 U.S.C.A. sec. 122(a). However, this period of secrecy is fairly short. MS submitted the API specs to the ECMA at least a year ago. Those specs are what the Mono libraries are being built on. Those specs will likely be described as "described in a printed publication." If MS wants to patent any of the API's, it has only 1 year in which to do so. See 35 U.S.C.A. sec. 102(b). Otherwise, there is a statutory bar on patentability, and the specs are in the public domain. See id. If MS has applied for those patents by now, there is a maximum 3-year time span for those claims to be reviewed and accepted or rejected by the PTO. See 35 U.S.C.A. sec. 154(b)(1)(B). Generally, however, MS would have to prosecute its patent within 6 months of the filing date. See 35 U.S.C.A. sec. 133. Therefore, "secret" patents are likely to be in hiding for less than 3 years.
I hope this allays some of your fears. Cheers!
P.S. IANAL (but I hope to be one some day), and anyone construing what I have said here as legal advice to their specific situation is an idiot.
~~~~~~~~~
dissertus scribendo latine videri volo.
The CIL idea is not new. If I remember correctly is used in Borkands C++ Builder & Delphi to some extent. C++ Builder compilers down to the same thing as Delphi and if I remember correctly they use the same linker. It has been a long time since I was delving into the depths of C++ Builder, but I do vaguely remember the common compilation. You can use Delphi Components in C++ Builder, and this is why. The only difference is that Borland never made this a big marketing issue.
If they haven't sold it, Microsoft used to, and probably still does, own a chunk of Borland (as reported here on 6/8/99). From the press release linked to in the slashdot article, "... announced the completion of a set of strategic technology and licensing agreements that will be the foundation for a long-term alliance between the two companies", and "... $25 million purchase by Microsoft of shares of Inprise [what Borland was called for a while] preferred stock". I beleive this is where they got this ideas behind CIL and combined it with the Java virtual Machine model.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
It may be worth noting that one of the chief architects of Delphi (Anders Hejlsberg, IRC) has been working for Microsoft for some time (And if I'm not mistaken, is one of the chief developers of the C# language)..
Yes, people have tried to realize the benefits using the Java VM. It's a compelling thought; it's tried and true and it's already available for many platforms.
The problem with the Java VM is really that it's written to run Java, and Java only. All features and optimizations are geared towards this. For a few languages that turn out to have much the same features, it is doable, but for other languages it results in some incredibly ugly - and slow - hacks. CIL:s advantage is solely - but importantly - that it's designed to accomodate multiple languages (sort of the difference between a FORTH processor or signal processor and a general-purpose CPU).
That said, implementing a Java compiler for CIL is a good idea; you'd get even more places to run Java programs.
/Janne
Trust the Computer. The Computer is your friend.
Keep in mind this is version one of the CLR. In a very informative interview with Anders Hejlsberg, the chief architect of C#, as well as Turbo Pascal and Delphi, he says that some of the higher-end language features such as generics were implemented in a research version of the CLR but were cut for the current release. After reading that interview, it looks to me like they will implement the more exotic language features in future releases of the CLR, but they just didn't have the time or resources to implement their entire language feature wish list.
Here are RMS's actual quotes:
"I can't believe it's Gnome you're talking about but if it is, I wouldn't like that,"
"I didn't know he was doing that, I find that very hard to believe,"
"We would like him to come to the free software community and explain himself to us about it."
Where exactly is the witch hunt? Where is the talk of 'sins'? Or the need to 'repent'? If anything, he says: "Um... I didn't know that. Are you sure? Well, I'd like to hear it from him before I comment on the matter".
BRUTAL words from him - an utterly horrible position, eh?
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
Right. A proof of concept was when other languages were compiled to java bytecode. There may have been earlier ones too.
If I remember correctly is used in Borlands C++ Builder & Delphi to some extent. C++ Builder compilers down to the same thing as Delphi and if I remember correctly they use the same linker. ... I beleive this is where they got this ideas behind CIL and combined it with the Java virtual Machine model.
Um. Nope. CIL stands for Common Intermediate Language.
Neither Delphi nor BCB are interpreted, JIT'd or run on virtual machine. Nor do they use an intermediate language of any kind.
The language that they have in common is in fact x86 assembly. The reason that the Delphi VCL can be used in BCB is that they share an object file format.
Maybe the idea of sharing a class library came over from Borland with Anders Heijsberg, but the method of achieving it is different.
My Karma: ran over your Dogma
StrawberryFrog