Slashdot Mirror
Microsoft Common Language Runtime To Be Cross-Platform
axlrosen alerts us to a Microsoft sleeper announcement from Mix07: a version of its Common Language Runtime will be available cross-platform. The Core CLR shows up as part of the Silverlight SDK that Redmond is open sourcing. From the blog posting: "The biggest Mix '07 announcement made on opening day of this week's show was one that Microsoft didn't call out in any of its own press releases: Microsoft is making a version of its Common Language Runtime available cross-platform. The CLR is the heart of Microsoft's .Net Framework programming model. So, by association, the .Net Framework isn't just for Windows any more."
That's exactly what Microsoft did with ActiveX. They pushed ActiveX as cross-platform, delivering an ActiveX SDK for the Mac and supporting ActiveX components in IE.
Then after a while, they dropped ActiveX support, saying it was too much effort to make it work on OS X.
Then after a while longer, they dropped IE too.
Same with WMV. Seen Windows Media Player for the Mac? No? That's because they dropped it a while back, and killed all support for DRM-protected Windows Media on the Mac. (Instead they suggest that people use a third party QuickTime plugin that only handles unprotected WMV.)
Jeez, lots of Microsoft fanboys or astroturfers moderating today.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Unfortunately, only the "Core CLR" will be ported, and only to the Mac OS (probably due in part to MS Office for Mac), not Linux, and not even older (PPC) Macs. I also seriously doubt there will be much in the way of developer tools for the(se) other platform(s).
.NET Framework by any stretch. There have been whispers about a Linux version of Silverlight as well (Flash has one, and Microsoft is trying to provide a superset of the Flash/Flex featureset).
A subset of the CLR similar to the Compact Framework is included in Silverlight; with a much simpler security model. It's not a replacement for the full
As for developer tools, while it's not exactly developing on a Mac, per se, you can use Visual Studio to do remote debugging on CLR code running in a Silverlight app on a Mac client.
NO CARRIER
Dude. CANVAS. Hello?
Microsoft pulled the wool over your eyes. They were showing you a DOM app that needed to modify the rendering tree in order to make a move. This is similar to a 3D Scene Graph, but without the hardware acceleration. When Microsoft showed you the Silverlight app, they were showing you a hardware-accelerated drawing program. The very purpose for which Canvas was created.
As for the AI speed (assuming that the performance issues weren't entirely being caused by the DOM manipulations), Silverlight still uses Javascript for scripting. If it can run so much faster in their CLR scripting why don't they use their new Javascript engine in Internet Explorer?
In case you think I'm joking, that is exactly what Mozilla is doing with their new Tamarin engine. The new engine is faster and more feature rich, ergo it's being integrated into the browser platform. To make matters even more interesting, Mozilla and Adobe are sharing the development of the engine, so that they can both use it. Mozilla in the browser, Adobe in Flash.
I'm sorry. Microsoft is pulling a fast one on you. There is no need for Silverlight other than to lock you into Microsoft technology.
Javascript + Nintendo DSi = DSiCade
Unfortunately neither of them actually knows what they are talking about.
For starters, a.k.a. why Chester K doesn't know what he's talking about, at MIX they showed JavaScript in the browser against C# in Silverlight v1.1 - not C# in JavaScript. The speed comparisons are correct.
why AKAIAmBatman is wrong is because this is absolutely not about the performance of rendering. The setup here is that you have one app, with whatever that infrastructure is running in, delegating to the player code. The player code being C#, JavaScript, or a human. This is how you typically do chess games and no surprise it's how they did it here. Therefore the JavaScript is doing no rendering of any kind. That is unless the game was implemented using JS, but even if it was it doesn't matter. The idea is to give each player 1 second to calculate and they give you the best move and how many calculations done. This is merely a measure of raw computational power: calls, either some array lookups, and simple math (potentially bitwise arithmetic, potentially not depending upon the implementation). Finally they used the same algorithm just implemented in the two different languages.
And because Chester K was misinformed this populates down into AKAIAmBatman's comments where things go wrong. The Tamarin engine has nothing on this. ActionScript has nothing on this. What we're talking about is approaching near native code speed in the browser. JavaScript, no matter what, just isn't going to get there and still be JavaScript. It's way too dynamic. Maybe you can do some whole program analysis but even that is going to be tough. It seems the goal for Tamarin is only a 10x improvement (http://simonwillison.net/2006/Nov/9/tamarin/) if you look at the source code. That means that C# will still be 1000 times faster than the improved Tamarin engine. It's just a fact - JavaScript sucks.
FUD more?
.NET that downloads the silverlight runtime, be it on mac or windows. You are a fool if you believe that the majority of windows users have any version of .NET installed, let alone 2.0, even today.
The CLR shipped with silverlight runtime is supported in IE, Firefox and Safari on windows and mac. It contains all CLR 2.0 features, and has all of the silverlight libraries. It does however only contain a subset of the BCL (Base Class Libraries), but that is the same for all the users without