Well, the ARM got ignored up to now, so here's a link to Jazelle, the (90% of) Java bytecode native to CPU trick. And the benchmarks are quite impressive too...
Interesting that we've had a bunch of different ideas for converging KDE and GNOME, e.g.
Unify theme, i.e. Look & Feel, e.g. base on OS X
Unify component models and/or protocols: KCOP and Bonobo
Unify APIs, e.g. layer Qt on GTK
but that the idea of producing a.NET work-alike hasn't come up again. Thank fsck for that you might be thinking. Well...
Bear in mind that moving from C/C++ APIs to a common VM and high-level class library would not just be unification of KDE and GNOME, but would add real, I would say critical, capabilities to Linux app development. To recap some earlier discussions, a VM would:
Allow cross-(hardware)-platform app distribution, so Linux apps can be installed by normal people without compilers on their PDAs etc.
Provide a platform that can compete with.NET and Java in ease of use (GC etc.), reliability (no pointers), security etc.
Can help unify the scripting languages Python, PERL, not forgetting the various LISPs and Schemes such as Sawfish's LISP engine and RMS's Guile.
Something like Parrot would be a great place to start (it's a JIT compiler as well as interpreter, before all the speed freaks leap on me).
This assumes of course that RMS can persuade Miguel away from his attempt to clone everything that comes out of Redmond...
My impression is that Parrot is going to be a VM for Perl only, thanks to somewhat less than wild enthusiasm from the Python contributors, plus the decline of TCL, the fragmented LISP world etc. But I would like to be wrong! any pointers to recent progress in this area?
<digression>
Although, having said that, I rather wish that Parrot was more than just another bytecode machine. It would have been nice to have embodied some programs as data capabilities, that general advance is surely long overdue. (Turing put modifiable code in the ACE design in, er, 1945, and LISP did it quite neatly back in 1960).
Algol seems to cast a long shadow, don't you think?
b) Incompatibilities with the standard are generally fixed by changing the standard or referring to the 'reference implementation' (DCE, Kerberos, C++...).
Wow, someone actually thinking about the requirements!
I'd like to stick my neck out and say that, if we're starting here in 2002, we should definitely avoid bytecode and go for an intermediate language based on ASTs, i.e. a representation of the actual program structure.
The reasons for this would normally be considered rather deep - stuff about reflection, meta-level programming, LISP-style macros etc. - but one angle is obvious to any Open Source hacker the code is the source! Just distribute the semi-compiled form and bingo! anyone else can read it, change it etc. Surely an "Intermediate" Language to warm the cockles of RMS's heart?
There should be references to this approach in LISP/Scheme research - if anyone knows a good paper I'd appreciate a pointer.
Probably true. Conversely, standalone compilers give up opportunities for dynamic (runtime) and cross-module optimization.
My impression is that as programming gets more abstract (EJBs, transparent RPCs etc.) the runtime optimizations become more significant as they're in a position to cut through a lot of code layering that, say, a C++ CORBA system would exhibit.
Well, we have had quite a lotto say about this but unfortunately, for Miguel-ites Dotnet is the one true way and by definition it cannot be modified or (gasp!) improved. Luckily, it has already addressed all Open Source / Linux application development requirements and so further debate on this subject is pointless, as you can see from the number of replies to the above posts.
I thought the (whole) sentence was clear, but in case it's not, let me repeat that I have no objection to leveraging MS R&D, or other good work done elsewhere, e.g. Anton Ertl's research, but there is absolutely no benefit in slavishly emulating the whole platform. (The 'portability' argument is completely specious, as has been pointed out numerous times elsewhere).
In fact, there are good reasons for not copying everything, such as the efficient provision of reflection and meta-level capabilities.
Anybody else think it's odd how both De Icaza and RMS are ignoring some key (I would say the key) issues? Neither has explicitly stated that
GNU/Linux/GNOME does need a cross-(hardware)-platform distribution capability equivalent to Dotnet and Java packages, otherwise uptake of apps for consumer devices will be seriously impeded. (My manager is not about to break out the C compiler in order to get a project mgmt app on his PDA)
There's a deep potential linkage between the right kind of Intermediate Language and Open Source. Just as it's possible to decompile Java classes and alter them today, with a GNU IL the distributed form could be semantically equivalent to the source, therefore you could only ever distribute open source
There are a lot of VMs being developed already - Java, Perl/Parrot, Python, Scheme etc. In fact, RMS has Guile and GNOME has Sawfish's LISP engine. Wouldn't people's efforts be better directed at consolidating some of these?
Lastly, though I despair of ever getting this point across to Miguel-ites, it is quite legitimate to covet some features of Dotnet and seek to offer them on Linux. These benefits, however, fall far short of what would be needed to justify a project to produce a complete clone of the platform on Linux - Miguel-ites are simply dumping their critical faculties and going into hero-worship mode to the detriment of GNOME and open source in general.
I'm having to do exactly that right now. I let Windows (2000) Update install the pre-SP3 patches and now Forte Agent won't start and my USB has stopped working. I've tried removing them (reboot needed after each one, even though they were installed as a batch!) but no luck.
SOAP has already been extended in the sense that a proprietary alternative with more features is there (Dotnet Remoting). In fact, all remote objects must using Remoting, since SOAP does not support object references as parameters. SOAP is therefore neither simple [UDDI, WSDL] nor does it provide object access [no objrefs]. Catchy name though.
Unfortunately Echidna seems to have gone quiet, but IBM are doing a lot on the 390s that enables JVMs to share heaps etc. - see references at the bottom of this article - this is probably the best hope for a consolidated desktop VM.
There is no 'either way' - whatever you want to call 'the standard.NET platform that I write my app to', MS has already extended it, as other posters have earlier pointed out but which you have chosen to ignore.
If you're in need of further examples, look no further than the open SOAP protocol which you proclaim is a 'core tenet' of Dotnet that MS is encouraging Dotnet developers to use. In fact, developers will prefer to use something called Dotnet Remoting, a proprietary protocol, since it does a couple of rather important things that SOAP doesn't - it can pass object references and serialize objects, just like Java's RMI. In fact, my.NET book (Thai and Lam) goes so far as to say that this capability "is the key to distributed computing in.NET" (p84). Clearly, SOAP isn't 'core' enough to support it.
However, based on what I've seen of recent debates, no matter
however many proprietary 'keys' are uncovered in Dotnet,
whatever other interesting technologies are out there in the open source world,
however mature Java platforms and tools are,
the Miguel-supporters will find it literally impossible to concieve that it is useful to make something like Dotnet without attempting to clone the whole product. They believe that there's something unique, unified and immaculate called Dotnet Technology which they must accept and implement in its entirety, not to be analysed, questioned or (gasp!) improved in any way.
Yes, Dotnet in the one and only true way of improving the Linux application development environment, and placing Microsoft in the driving seat is the price we must pay.
Sure, invest huge effort in cloning Microsoft CLR (when there are several other VM efforts already underway - Parrot, Python, Scheme, Java in various forms), put a huge political risk at the heart of Linux app development, for absolutely no guaranteed or unique benefit whatsoever!
Congratulations, the 'strategic technical visionary' award is in the mail.
So if Mono is entirely incompatible with Dotnet we have just introduced a huge political risk but gained precisely zero benefit over what we could have come up on our own.
There are good reasons to think that a merger of Java, Parrot, Scheme etc. VMs would be better than the CLI.
To take one relevant example, the intermediate language could be semantically equivalent to the source, just as you can nearly always reconstruct Java source from its bytecode. Then, bingo! No need to ship source and/or binaries - the program is the source!
But it's not just naivety - Miguel's technical arguments don't add up to a row of beans. There's no reason whatsoever for providing a C# development environment for Linux when Java is already established in a variety of forms, nor any reason to slavishly copy the CLI when a bunch of other VM developments are going on which could use help.
The point is not just that a huge political risk is being introduced to the heart of Linux development, but that no guaranteed and unique benefit from doing so has ever been identified.
What made you curious? As a Java developer, you'll be aware that there's nothing radically new in the Dotnet CLI or C# and you'll be highly sceptical about claims of portability between Dotnet and Mono, given the difficulties we have today with AWT, SWT, Swing, WebLogic vs. WebSphere etc.
It seems that you're most excited by the prospect of applying some pressure to Sun to open up its IPR. Well, I think there are many ways of doing that, most of which will not involve putting MS in the driving seat of Linux application development.
It measures up pretty well from what I've read. Parrot was specifically targeted as supporting Python too, as you say, but I believe the Python people haven't leapt to embrace it just yet.
My own preference would be to start with a syntax-tree form of an intermediate language rather than bytecode, since this would support more sophisticated dynamic capabilities.
Regardless of what I think though, the point is that there's plenty of room for innovation in existing open source projects, and no guranteed benefit whatsoever in slavishly cloning the Dotnet Framework.
Lots of insightful comments, but no one's actually picked out the yawning chasm of a non sequitur in the Mono programme:
If you like some of the Dotnet features, you have to clone the Dotnet Framework
I might like my mother, but I'm not about to clone her so I'll someone to marry in a few years - I know that her virtues can be found in other forms.
For example, we could develop a new CIL that was based on Scheme, but which could support programs originally written in Java syntax. This might be a better language superset - certainly many early LISP developers intended it to be an intermediate language, so the parens were always optional in essence.
Consequently, the only possible justification for cloning the Dotnet Framework is that MS tools will facilitate development of Mono apps, and that (equivalently) Dotnet apps will port to Mono. And on this point, it seems the crowd has spoken with one voice - it just ain't gonna happen.
I'm referring to the distributed code, which might be compiled. These sound like Qt-style compatible APIs which are built separately for each target hardware platform.
Java and Dotnet are not the only possible VMs - Perl has a new one, Python has one, even GNOME has one already in Sawfish.
I don't believe that porting real commercial apps from Dotnet to something on Linux is ever going to be realistic, therefore I'm proposing we might as well do something completely different but with the same general goals as Dotnet.
I can't see it happening, to be honest. I had a colleague who used J++ for developing normal Java apps, but the contortions he had to go through were pretty unpleasant. You can be pretty sure that automated/visual aspects of VS.NET will be Windows-only.
Just because you like Dotnet's features doesn't mean you need Dotnet to get them. Java has most of the key capabilities, for example.
I believe there's everything to be lost (because MS ends up in the driving seat), and nothing to be gained (because MS->Linux application porting won't happen) by trying to clone the Dotnet platform. I also think that a separate VM effort could add further good things for open source developers.
There are plenty of other posts giving the political reasons why we should not use Dotnet. I think we do need something like Dotnet, but I'd just like to sketch some of the technical reasons I'd prefer a completely separate VM to be developed:
1. Open Source is sometimes distributed (to client devices) as source, sometimes as binary. A well designed intermediate language could get rid of this duality - just ship this form. That way, all code is open code. (Java classes nearly do this - you can get nearly 100% of the source back by decompiling them).
2. If you believe that there's no fundamental distinction between code and data, you'd like to use a dynamic language that can manipulate itself. That way, something equivalent to ASPs or JSPs can be supported very neatly. Bytecode isn't quite optimal for this kind of model - code is better left in "tokenized" form (an AST).
3. If you want an extensible language so that e.g. persistence, transactions, access controls etc. can be provided automatically, without extra coding by the application developer, you want LISP-style macros or the meta-object protocol. Bytecode systems are bad at this, partly because fiddling with the bytecode makes it lose its correspondence to the original source.
4. Perl, Python, LISP, TCL etc. all have dynamic features that are possible to support in Dotnet and Java, but still a bit clunky. A VM starting from their design centres would result in a more flexible overall system. I certainly have some features in mind I'd like to see, hopefully others do too.
And perhaps Miguel might respond by asking if the rest of the Linux community really needs:
A Java VM
A Perl VM
A Python VM
Several LISP and Scheme "VMs", including RMS's and the Sawfish one
not to mention assorted scripting and configuration languages of baroque nature.
These developments exist because they address real requirements for portability, ease-of-use etc. - "Mono" doesn't need to justify itself in principle.
However, I will certainly admit that needing something like Dotnet is not the same as needing Dotnet. In fact, I'm sure we could do better.
Slashdot Mirror
Well, the ARM got ignored up to now, so here's a link to Jazelle, the (90% of) Java bytecode native to CPU trick. And the benchmarks are quite impressive too...
- Unify theme, i.e. Look & Feel, e.g. base on OS X
- Unify component models and/or protocols: KCOP and Bonobo
- Unify APIs, e.g. layer Qt on GTK
but that the idea of producing aBear in mind that moving from C/C++ APIs to a common VM and high-level class library would not just be unification of KDE and GNOME, but would add real, I would say critical, capabilities to Linux app development. To recap some earlier discussions, a VM would:
- Allow cross-(hardware)-platform app distribution, so Linux apps can be installed by normal people without compilers on their PDAs etc.
- Provide a platform that can compete with
.NET and Java in ease of use (GC etc.), reliability (no pointers), security etc.
- Can help unify the scripting languages Python, PERL, not forgetting the various LISPs and Schemes such as Sawfish's LISP engine and RMS's Guile.
Something like Parrot would be a great place to start (it's a JIT compiler as well as interpreter, before all the speed freaks leap on me).This assumes of course that RMS can persuade Miguel away from his attempt to clone everything that comes out of Redmond...
My impression is that Parrot is going to be a VM for Perl only, thanks to somewhat less than wild enthusiasm from the Python contributors, plus the decline of TCL, the fragmented LISP world etc. But I would like to be wrong! any pointers to recent progress in this area?
<digression>
Although, having said that, I rather wish that Parrot was more than just another bytecode machine. It would have been nice to have embodied some programs as data capabilities, that general advance is surely long overdue. (Turing put modifiable code in the ACE design in, er, 1945, and LISP did it quite neatly back in 1960).
Algol seems to cast a long shadow, don't you think?
</digression>
a) They have extended this standard already
b) Incompatibilities with the standard are generally fixed by changing the standard or referring to the 'reference implementation' (DCE, Kerberos, C++...).
Wow, someone actually thinking about the requirements!
I'd like to stick my neck out and say that, if we're starting here in 2002, we should definitely avoid bytecode and go for an intermediate language based on ASTs, i.e. a representation of the actual program structure.
The reasons for this would normally be considered rather deep - stuff about reflection, meta-level programming, LISP-style macros etc. - but one angle is obvious to any Open Source hacker the code is the source! Just distribute the semi-compiled form and bingo! anyone else can read it, change it etc. Surely an "Intermediate" Language to warm the cockles of RMS's heart?
There should be references to this approach in LISP/Scheme research - if anyone knows a good paper I'd appreciate a pointer.
Probably true. Conversely, standalone compilers give up opportunities for dynamic (runtime) and cross-module optimization.
My impression is that as programming gets more abstract (EJBs, transparent RPCs etc.) the runtime optimizations become more significant as they're in a position to cut through a lot of code layering that, say, a C++ CORBA system would exhibit.
Well, we have had quite a lot to say about this but
unfortunately, for Miguel-ites Dotnet is the one true way and by definition it cannot be modified or (gasp!) improved. Luckily, it has already addressed all Open Source / Linux application development requirements and so further debate on this subject is pointless, as you can see from the number of replies to the above posts.
I thought the (whole) sentence was clear, but in case it's not, let me repeat that I have no objection to leveraging MS R&D, or other good work done elsewhere, e.g. Anton Ertl's research, but there is absolutely no benefit in slavishly emulating the whole platform. (The 'portability' argument is completely specious, as has been pointed out numerous times elsewhere).
In fact, there are good reasons for not copying everything, such as the efficient provision of reflection and meta-level capabilities.
I'm having to do exactly that right now. I let Windows (2000) Update install the pre-SP3 patches and now Forte Agent won't start and my USB has stopped working. I've tried removing them (reboot needed after each one, even though they were installed as a batch!) but no luck.
SOAP has already been extended in the sense that a proprietary alternative with more features is there (Dotnet Remoting). In fact, all remote objects must using Remoting, since SOAP does not support object references as parameters. SOAP is therefore neither simple [UDDI, WSDL] nor does it provide object access [no objrefs]. Catchy name though.
Unfortunately Echidna seems to have gone quiet, but IBM are doing a lot on the 390s that enables JVMs to share heaps etc. - see references at the bottom of this article - this is probably the best hope for a consolidated desktop VM.
If you're in need of further examples, look no further than the open SOAP protocol which you proclaim is a 'core tenet' of Dotnet that MS is encouraging Dotnet developers to use. In fact, developers will prefer to use something called Dotnet Remoting, a proprietary protocol, since it does a couple of rather important things that SOAP doesn't - it can pass object references and serialize objects, just like Java's RMI. In fact, my
However, based on what I've seen of recent debates, no matter
the Miguel-supporters will find it literally impossible to concieve that it is useful to make something like Dotnet without attempting to clone the whole product. They believe that there's something unique, unified and immaculate called Dotnet Technology which they must accept and implement in its entirety, not to be analysed, questioned or (gasp!) improved in any way.
Yes, Dotnet in the one and only true way of improving the Linux application development environment, and placing Microsoft in the driving seat is the price we must pay.
The dumbest comment so far?
Sure, invest huge effort in cloning Microsoft CLR (when there are several other VM efforts already underway - Parrot, Python, Scheme, Java in various forms), put a huge political risk at the heart of Linux app development, for absolutely no guaranteed or unique benefit whatsoever!
Congratulations, the 'strategic technical visionary' award is in the mail.
So if Mono is entirely incompatible with Dotnet we have just introduced a huge political risk but gained precisely zero benefit over what we could have come up on our own.
There are good reasons to think that a merger of Java, Parrot, Scheme etc. VMs would be better than the CLI.
To take one relevant example, the intermediate language could be semantically equivalent to the source, just as you can nearly always reconstruct Java source from its bytecode. Then, bingo! No need to ship source and/or binaries - the program is the source!
But it's not just naivety - Miguel's technical arguments don't add up to a row of beans. There's no reason whatsoever for providing a C# development environment for Linux when Java is already established in a variety of forms, nor any reason to slavishly copy the CLI when a bunch of other VM developments are going on which could use help.
The point is not just that a huge political risk is being introduced to the heart of Linux development, but that no guaranteed and unique benefit from doing so has ever been identified.
What made you curious? As a Java developer, you'll be aware that there's nothing radically new in the Dotnet CLI or C# and you'll be highly sceptical about claims of portability between Dotnet and Mono, given the difficulties we have today with AWT, SWT, Swing, WebLogic vs. WebSphere etc.
It seems that you're most excited by the prospect of applying some pressure to Sun to open up its IPR. Well, I think there are many ways of doing that, most of which will not involve putting MS in the driving seat of Linux application development.
It measures up pretty well from what I've read. Parrot was specifically targeted as supporting Python too, as you say, but I believe the Python people haven't leapt to embrace it just yet.
My own preference would be to start with a syntax-tree form of an intermediate language rather than bytecode, since this would support more sophisticated dynamic capabilities.
Regardless of what I think though, the point is that there's plenty of room for innovation in existing open source projects, and no guranteed benefit whatsoever in slavishly cloning the Dotnet Framework.
Lots of insightful comments, but no one's actually picked out the yawning chasm of a non sequitur in the Mono programme:
If you like some of the Dotnet features, you have to clone the Dotnet Framework
I might like my mother, but I'm not about to clone her so I'll someone to marry in a few years - I know that her virtues can be found in other forms.
For example, we could develop a new CIL that was based on Scheme, but which could support programs originally written in Java syntax. This might be a better language superset - certainly many early LISP developers intended it to be an intermediate language, so the parens were always optional in essence.
Consequently, the only possible justification for cloning the Dotnet Framework is that MS tools will facilitate development of Mono apps, and that (equivalently) Dotnet apps will port to Mono. And on this point, it seems the crowd has spoken with one voice - it just ain't gonna happen.
I'm referring to the distributed code, which might be compiled. These sound like Qt-style compatible APIs which are built separately for each target hardware platform.
Java and Dotnet are not the only possible VMs - Perl has a new one, Python has one, even GNOME has one already in Sawfish.
I don't believe that porting real commercial apps from Dotnet to something on Linux is ever going to be realistic, therefore I'm proposing we might as well do something completely different but with the same general goals as Dotnet.
I can't see it happening, to be honest. I had a colleague who used J++ for developing normal Java apps, but the contortions he had to go through were pretty unpleasant. You can be pretty sure that automated/visual aspects of VS.NET will be Windows-only.
Just because you like Dotnet's features doesn't mean you need Dotnet to get them. Java has most of the key capabilities, for example.
I believe there's everything to be lost (because MS ends up in the driving seat), and nothing to be gained (because MS->Linux application porting won't happen) by trying to clone the Dotnet platform. I also think that a separate VM effort could add further good things for open source developers.
There are plenty of other posts giving the political reasons why we should not use Dotnet. I think we do need something like Dotnet, but I'd just like to sketch some of the technical reasons I'd prefer a completely separate VM to be developed:
1. Open Source is sometimes distributed (to client devices) as source, sometimes as binary. A well designed intermediate language could get rid of this duality - just ship this form. That way, all code is open code. (Java classes nearly do this - you can get nearly 100% of the source back by decompiling them).
2. If you believe that there's no fundamental distinction between code and data, you'd like to use a dynamic language that can manipulate itself. That way, something equivalent to ASPs or JSPs can be supported very neatly. Bytecode isn't quite optimal for this kind of model - code is better left in "tokenized" form (an AST).
3. If you want an extensible language so that e.g. persistence, transactions, access controls etc. can be provided automatically, without extra coding by the application developer, you want LISP-style macros or the meta-object protocol. Bytecode systems are bad at this, partly because fiddling with the bytecode makes it lose its correspondence to the original source.
4. Perl, Python, LISP, TCL etc. all have dynamic features that are possible to support in Dotnet and Java, but still a bit clunky. A VM starting from their design centres would result in a more flexible overall system. I certainly have some features in mind I'd like to see, hopefully others do too.
not to mention assorted scripting and configuration languages of baroque nature.
These developments exist because they address real requirements for portability, ease-of-use etc. - "Mono" doesn't need to justify itself in principle.
However, I will certainly admit that needing something like Dotnet is not the same as needing Dotnet. In fact, I'm sure we could do better.