"We need innovation, not amalgamation. We need new features and a proliferation of languages, not loss of features and one language."
We completely agrees with this statement. The way to get new languages and features is to let people get in and monkey with the runtime machine, the opcode set that feeds the JIT, the metadata representations of types, and the compilers that produce the metadata and opcodes! This, plus providing support for the ECMA standards and people who want to better understand them, is precisely why we are releasing this code.
People will do very cool stuff with the Rotor codebase - I sincerely hope that it is straightforward to build, understand, port, and modify. I have been involved with the design and implementation of programming languages for a long time, and I love to see new ideas populate the landscape.
I'm very willing to concede that Miguel and crew might do a more efficient job than us:)
A large portion of the files counted are small tests, each to its own file. And in the last two weeks, we've managed to pull 1500 files (mostly redundant files used for generating documentation) from the distro.
A quick scan this morning shows me that the CLI itself is around 300Kloc.
I've found it useful to think of the libraries that are included as part of the ECMA spec as a "modern" equivalent of the C runtime. They form a base set of capabilities for programmers that is obviously useful and not too controversial, and they do this without straying into areas where consensus might be harder to find.
There will be many different forms libraries implemented - Windows Forms will be one of many choices. On KDE, wouldn't you rather see the features of KDE in your forms? On GNOME? On small devices that have different UI models altogether?
As part of Rotor, we made sure to provide support for both calling native code from "managed code," and vice versa. To demonstrate that, I hope that we will be able to show a simple sample class that wraps Tcl/Tk as part of our distribution.
Our license will speak for itself when we make the code available, but our intentions are that the Rotor code be there to help CLI implementors.
The reason that we've chosen the non-commercial route is that we are in the software business to produce revenue, and we will certainly encourage people to use our commercial CLR on Windows, either from Visual Studio, or from the freely downloadable.NET Framework SDK. There will be a number of CLI implementations to choose from, and will be very happy to compete on the merits of our own implementations.
Once we release the Rotor code, I think that it is very likely that Microsoft will be approached by developers who might want to use Rotor in a commercial setting. I have no doubt that licensing this code for commercial use would be a possibility, but I'll leave discussing this topic until we actually make the code available and people get a chance to see what we are talking about in more detail...
[I'm the guy on the Rotor team who presented at this BOF.]
We absolutely welcome slashdot "community input." I'm pretty sure that a lot of slashdotters will be interested in taking a look at this implementation; it is a pretty fascinating piece of technology, both in terms of the abstract approach to virtualizing resources that the ECMA CLI uses, and in terms of the implementation choices that have been made.
Anyone who wants to better understand how the.NET Framework works will be interested. Likewise, anyone who wants to better understand Mono or PNET or the Microsoft "Compact Framework" will also be interested!
Many of the comments on this thread might be summarized as follows: why is Microsoft doing this? The answer is that we really want the ECMA standard to succeed (and that includes success for non-Microsoft CLI implementations!) and we also want to seed the use of the CLI over the long haul. The only way to do this is by participating in the community that moves computer languages and runtimes forward - we believe that many experimentally minded folk will find Rotor a great base from which to work.
Slashdot Mirror
We completely agrees with this statement. The way to get new languages and features is to let people get in and monkey with the runtime machine, the opcode set that feeds the JIT, the metadata representations of types, and the compilers that produce the metadata and opcodes! This, plus providing support for the ECMA standards and people who want to better understand them, is precisely why we are releasing this code.
People will do very cool stuff with the Rotor codebase - I sincerely hope that it is straightforward to build, understand, port, and modify. I have been involved with the design and implementation of programming languages for a long time, and I love to see new ideas populate the landscape.
A large portion of the files counted are small tests, each to its own file. And in the last two weeks, we've managed to pull 1500 files (mostly redundant files used for generating documentation) from the distro.
A quick scan this morning shows me that the CLI itself is around 300Kloc.
There will be many different forms libraries implemented - Windows Forms will be one of many choices. On KDE, wouldn't you rather see the features of KDE in your forms? On GNOME? On small devices that have different UI models altogether?
As part of Rotor, we made sure to provide support for both calling native code from "managed code," and vice versa. To demonstrate that, I hope that we will be able to show a simple sample class that wraps Tcl/Tk as part of our distribution.
Thank you for your thoughtful feedback.
The reason that we've chosen the non-commercial route is that we are in the software business to produce revenue, and we will certainly encourage people to use our commercial CLR on Windows, either from Visual Studio, or from the freely downloadable .NET Framework SDK. There will be a number of CLI implementations to choose from, and will be very happy to compete on the merits of our own implementations.
Once we release the Rotor code, I think that it is very likely that Microsoft will be approached by developers who might want to use Rotor in a commercial setting. I have no doubt that licensing this code for commercial use would be a possibility, but I'll leave discussing this topic until we actually make the code available and people get a chance to see what we are talking about in more detail...
[I'm the guy on the Rotor team who presented at this BOF.]
We absolutely welcome slashdot "community input." I'm pretty sure that a lot of slashdotters will be interested in taking a look at this implementation; it is a pretty fascinating piece of technology, both in terms of the abstract approach to virtualizing resources that the ECMA CLI uses, and in terms of the implementation choices that have been made.
Anyone who wants to better understand how the .NET Framework works will be interested. Likewise, anyone who wants to better understand Mono or PNET or the Microsoft "Compact Framework" will also be interested!
Many of the comments on this thread might be summarized as follows: why is Microsoft doing this? The answer is that we really want the ECMA standard to succeed (and that includes success for non-Microsoft CLI implementations!) and we also want to seed the use of the CLI over the long haul. The only way to do this is by participating in the community that moves computer languages and runtimes forward - we believe that many experimentally minded folk will find Rotor a great base from which to work.