There seem to be a lot of untold assumptions that a lot of people appear to be making about Mono, that I cannot quite see as being correct, but are nevertheless important points for discussion. Here are the more important ones:
Assumption 1: Mono will have good performance
I am labeling this as an "assumption", because for some strange reason Mono's expected performance is not discussed here, even though there are multitudes of people consistently bashing Java for being slow.
Since the CLR is essentially identical to a Java VM in terms of high-level design, the execution of CLI code would be performed by using much the same approaches that are used for executing Java bytecode. If you look at Ximian's CLR implementation roadmap, you will see that it follows exactly the same path that the Java implementations took, except that it stops short before the last step -- runtime optimization. (Just to note that this last step is the most difficult one, but it is exactly what allowed Java to get close to C/C++ in terms of performance. JIT helps, but it simply does not cut it -- it is not enough).
Now, it took more than 5 years of intensive work for the JVMs to reach their current level of performance. How long will it take for Ximian's CLR impelementation to become fast enough and not be branded by the people on/. as slow? Obviously they can benefit from some of the Java work, but personally I feel that it would be very unlikely if that happens within less than 3 years. (although it would be nice if it did)
Assumption 2:.NET is standardized, so we can do multi-platform development
By now we all know that C# and the CLR have been submitted for ECMA standartization. What is important to realize is that while the C# language may be standardized, most of its libraries would not be. if you look at the list of libraries that are submitted for standartization, you can count 257 entities (classes, interfaces, delegates, etc.) defined in there. On the other hand, if you count the entities provided by the libraries in.NET beta1, and exclude the server-specific stuff, the OS-specific stuff, and even WinForms, you will get a number that is very close to 2000. So in effect Microsoft is standardizing at most 13% of the libraries it provides to Windows developers (the figure would be even lower if we include WinForms and other libs that might also be of interest).
What are the implications of this fact? The standardized libraries might allow OSS developers to build more extensive libraries base on pure CLI (w/o native code) and thus create an environment for multi-platform development. The suggestion to use the.NET libraries for this purpose, however, would fly in the face of everything that we have learned about Microsoft in the past -- as long as they have a monopoly, they will play games with the API, and will turn the whole endevour into a perpetual tail chasing.
It seems to me that Ximian do recognize this fact, but I am not very clear how they plan to counter the problem. In the article Nat said "I hope it doesn't happen" in reference to Microsoft changing the API, and that an open source version would "reduce the chance that Microsoft will be able to do that". If that is their strategy, well... good luck.
Assumption 3: You need.NET (Mono) to implement or use Web services
This is one of the reasons given in the article as to why Mono is necessary, and I am sorry to say this, but it is complete bull. The Web services that MS is advocating are based almost entirely on SOAP and XML, which are completely platform-agnostic and language-agnostic -- that's what MS has been touting as an advantage all along. You can communicate to a Web service using C and a set of SOAP libraries if you want to. If Ximian wanted to have a safe development environment to implement and use Web services, there is already a very mature one in existence that provides superb SOAP and XML support -- Java.
There is only one objective reason that I see for selecting.NET over Java, and it is not mentioned in the article at all: the CLR is designed to support multiple languages, unlike the JVM. The catch here is that the JVM already supports a hell of a lot of languages other than Java and that languages have to be bastardized to be used on the CLR, but still, I guess it does hold some marginal advantage.
Finally, as you can see above, the whole supposed licensing advantage of.NET vs. Java is a complete red herring. In fact, Java holds some practical advantages in that respect: In Java concrete specifications are provided not only the main libraries, but also for many optional ones. Changes in the Java API must be approved via a fairly democratic process as part of the Java Community Process, of which OSS groups such as the Apache foundation are also members, and is open to entry by others as well. All this has allowed a lot of implementations of the various Java libraries by a lot of independent vendors. Will this happen with.NET? Anyone willing to bet money on that one?
The very basic parts of.NET (the ones that are absolutely essential for the languages) _are_ submitted for standartization. However, they are not nearly enough for writing portable code. Mono would most likely have to implement parts of.NET that are not standardized to satisfy developers' demands.
Show me the specification of the standard C# library. There isn't such. Microsoft is doing a very clever thing -- standardizing the language, but not _the libraries_ that programs written in C# (and the other CLI languages) would use. That's what.NET is all about -- libraries.
This essentially means that the C# "standard libraries" would be forever a moving target, with the state of the art being defined by MS. Welcome to Wine all over again.
SMS is hardly the only way to lock up your GSM, although it is certainly the most accessible. The WAP-capable phones appear to open a whole new can (no, make that a barrel) of worms.
Earlier in the year we were working on a WAP application for a major automibile company. We actually had to put special effort in to ensure that the application *did not* lock up the phones. We tested the app with a number of phones from different manifacturers, including Nokia (I think the model used was 7110). The shocking part was that _almost all_ could be locked up, usually in different ways (which made things all the more frustrating, of course), and the problems occurred even when using the most basic WML. (the design of WML is another interesting discussion topic, but I guess I would have to leave that rant for another time)
A particularly interesting side of all that was that a lot of the ways in which the problems occurred pointed out to possible buffer overflow problems, something that would explain the lockups (one of the most obvious ones was lockups on some phones when the encoded and compressed WML pages, together with the POST data were above a certain size). Given this observation, I have been pondering since then whether those problems are actually exploitable. If they are, that would be majorly cool, or majorly scary, depending on what side of the fence you are on. Pity I don't have the zeal to delve into phone hacking at this point:).
Sun does something like that in their MAJC microprocessor by running speculative threads that execute different branches of the original thread. The results of those threads are either used or thrown out, depending on whether violations (RAW hazards, etc.) have been detected. Sun calls this technique Space-Time Computing. According to their (hopefully objective) benchmarks it can improve the execution performance of single-threaded code by up to 70%. That is a fairly significant figure.
To get back on topic, however, this approach clearly requires fast synchronization between the speculative threads and the "main" thread to be effective. So while it would work rather well on a single machine, it is hard for me to imagine getting it to run efficiently over a network. I suppose it is possible, but the amount of additional processing time needed to achieve a marginal performance improvement would be huge. But you never know, someone might come up with a bright idea...
Slashdot Mirror
Perhaps they should have used SOAP instead. Sending display data over XML would be something to see :-)
Assumption 1: Mono will have good performance
I am labeling this as an "assumption", because for some strange reason Mono's expected performance is not discussed here, even though there are multitudes of people consistently bashing Java for being slow.
Since the CLR is essentially identical to a Java VM in terms of high-level design, the execution of CLI code would be performed by using much the same approaches that are used for executing Java bytecode. If you look at Ximian's CLR implementation roadmap, you will see that it follows exactly the same path that the Java implementations took, except that it stops short before the last step -- runtime optimization. (Just to note that this last step is the most difficult one, but it is exactly what allowed Java to get close to C/C++ in terms of performance. JIT helps, but it simply does not cut it -- it is not enough).
Now, it took more than 5 years of intensive work for the JVMs to reach their current level of performance. How long will it take for Ximian's CLR impelementation to become fast enough and not be branded by the people on /. as slow? Obviously they can benefit from some of the Java work, but personally I feel that it would be very unlikely if that happens within less than 3 years. (although it would be nice if it did)
Assumption 2: .NET is standardized, so we can do multi-platform development
By now we all know that C# and the CLR have been submitted for ECMA standartization. What is important to realize is that while the C# language may be standardized, most of its libraries would not be. if you look at the list of libraries that are submitted for standartization, you can count 257 entities (classes, interfaces, delegates, etc.) defined in there. On the other hand, if you count the entities provided by the libraries in .NET beta1, and exclude the server-specific stuff, the OS-specific stuff, and even WinForms, you will get a number that is very close to 2000. So in effect Microsoft is standardizing at most 13% of the libraries it provides to Windows developers (the figure would be even lower if we include WinForms and other libs that might also be of interest).
What are the implications of this fact? The standardized libraries might allow OSS developers to build more extensive libraries base on pure CLI (w/o native code) and thus create an environment for multi-platform development. The suggestion to use the .NET libraries for this purpose, however, would fly in the face of everything that we have learned about Microsoft in the past -- as long as they have a monopoly, they will play games with the API, and will turn the whole endevour into a perpetual tail chasing.
It seems to me that Ximian do recognize this fact, but I am not very clear how they plan to counter the problem. In the article Nat said "I hope it doesn't happen" in reference to Microsoft changing the API, and that an open source version would "reduce the chance that Microsoft will be able to do that". If that is their strategy, well... good luck.
Assumption 3: You need .NET (Mono) to implement or use Web services
This is one of the reasons given in the article as to why Mono is necessary, and I am sorry to say this, but it is complete bull. The Web services that MS is advocating are based almost entirely on SOAP and XML, which are completely platform-agnostic and language-agnostic -- that's what MS has been touting as an advantage all along. You can communicate to a Web service using C and a set of SOAP libraries if you want to. If Ximian wanted to have a safe development environment to implement and use Web services, there is already a very mature one in existence that provides superb SOAP and XML support -- Java.
There is only one objective reason that I see for selecting .NET over Java, and it is not mentioned in the article at all: the CLR is designed to support multiple languages, unlike the JVM. The catch here is that the JVM already supports a hell of a lot of languages other than Java and that languages have to be bastardized to be used on the CLR, but still, I guess it does hold some marginal advantage.
Finally, as you can see above, the whole supposed licensing advantage of .NET vs. Java is a complete red herring. In fact, Java holds some practical advantages in that respect: In Java concrete specifications are provided not only the main libraries, but also for many optional ones. Changes in the Java API must be approved via a fairly democratic process as part of the Java Community Process, of which OSS groups such as the Apache foundation are also members, and is open to entry by others as well. All this has allowed a lot of implementations of the various Java libraries by a lot of independent vendors. Will this happen with .NET? Anyone willing to bet money on that one?
My previous message is a bit misleading.
.NET (the ones that are absolutely essential for the languages) _are_ submitted for standartization. However, they are not nearly enough for writing portable code. Mono would most likely have to implement parts of .NET that are not standardized to satisfy developers' demands.
The very basic parts of
Show me the specification of the standard C# library. There isn't such. Microsoft is doing a very clever thing -- standardizing the language, but not _the libraries_ that programs written in C# (and the other CLI languages) would use. That's what .NET is all about -- libraries.
This essentially means that the C# "standard libraries" would be forever a moving target, with the state of the art being defined by MS. Welcome to Wine all over again.
The information it provides is exactly what you appear to require, assuming that you are genuinely interested in the topic.
SMS is hardly the only way to lock up your GSM, although it is certainly the most accessible. The WAP-capable phones appear to open a whole new can (no, make that a barrel) of worms.
:).
Earlier in the year we were working on a WAP application for a major automibile company. We actually had to put special effort in to ensure that the application *did not* lock up the phones. We tested the app with a number of phones from different manifacturers, including Nokia (I think the model used was 7110). The shocking part was that _almost all_ could be locked up, usually in different ways (which made things all the more frustrating, of course), and the problems occurred even when using the most basic WML. (the design of WML is another interesting discussion topic, but I guess I would have to leave that rant for another time)
A particularly interesting side of all that was that a lot of the ways in which the problems occurred pointed out to possible buffer overflow problems, something that would explain the lockups (one of the most obvious ones was lockups on some phones when the encoded and compressed WML pages, together with the POST data were above a certain size). Given this observation, I have been pondering since then whether those problems are actually exploitable. If they are, that would be majorly cool, or majorly scary, depending on what side of the fence you are on. Pity I don't have the zeal to delve into phone hacking at this point
To get back on topic, however, this approach clearly requires fast synchronization between the speculative threads and the "main" thread to be effective. So while it would work rather well on a single machine, it is hard for me to imagine getting it to run efficiently over a network. I suppose it is possible, but the amount of additional processing time needed to achieve a marginal performance improvement would be huge. But you never know, someone might come up with a bright idea...