Slashdot Mirror
Mercury Researchers Explain Microsoft .NET
Bob.Smart writes "Microsoft's .NET is clearly explained in
this article on the Mercury web site. The input from various important research
groups is also interesting."
← Back to Stories (view on slashdot.org)
.Net is built on an open source protocol SOAP. which enables anyone to write his own version on any language he please. It wouldnt be long before someone build the .Net framework for different platforms like Linux or Unix. Microsoft is just trying to pry the control out of Java's cold dead hands. It makes sense too.
.Net holds up against Java.
The world is not gonna communicate in pure java. Its not about one language, its all about interoperability across platforms. The Framework is pretty flexible so as to allow anyone to write the same framework for any platform and it wouldnt be too late before someone does.
Microsoft is attacking both Sun in its Server market (by pushing Windows 2000 Advanced Servers) and Java in its pedestal by pushing forward the notion of interoperability through diverse languages using the same framework. It would be interesting to see the benchmarks.
SOAP got me all warmed up, and I am looking forward to see how
Rapid Nirvana
The reasons for the lack of working Java applets are simple: hubris on the part of Netscape and malice on the part of MS. When Java first appeared, Netscape thought they could write 22(!) different JVMs and have them all stay compatible, and easily updated when Sun updated the Java spec. Didn't happen. Then MS tried to hijack Java and basically killed the idea of easy applet portability.
Now that there are teams specializing in Java for different platforms (Sun does Win32, Solaris, and Linux/x86, IBM does IBM operating systems, Win32, and Linux, Apple does Mac OS and Mac OS X, etc.), the problems will sort themselves out. But the damage that Netscape did with their crappy implementations and MS did with their deliberate wrench in the works won't be undone for a long time, if ever. Java on the client is not doing so well, outside of in-house corporate applications.
Meanwhile, server-side Java is very, very portable. So, just start working on server-side Java and you'll see how good JVMs can be ;-)
-jon
Remember Amalek.
And those languages are C# (copy of Java), C++ (ugh) and VB (no comment necessary).
10. With Java, you have to learn Java. Plus, statistics show that 70% of all Java developers target APIs that are native to their platform.
That doesn't sound right, do you have a source? Most server-side Java is very portable.
With .NET, you can write in *any* of over 15 already-announced languages.
Languages for the Java VM.
If you actually want to speak intelligently about this, you really owe it to yourself to try it out.
Which I can't do, since I don't own any Windows systems.
The sad thing is, you'll be talking it down, when in fact, it's one of the coolest things I've ever seen in this industry.
It very well may be. But, at this point I don't see how anyone can trust Microsoft to put stability and sound architecture ahead of marketing concerns. Microsoft talking about standards compliance and cross-platform technologies has about as much credibility as Al Gore talking about campaign finance reform. Maybe in a year
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
Required: 5 years experience developing with Microsoft .NET
Here's a go.
Microsoft .NET is basically a virtual machine, kinda like the Java virtual machine. The virtual machine works with several different languages. This makes debugging and development easier than before.
Of course the big problems with virtual machines are that you get a performance hit, and your code will only run on those platforms which have an implementation of the machine. I'm not holding my breath for Microsoft to port the .NET machine to Solaris or Linux anytime soon, or to release the specs so that others can do it, either.
Basically, it looks to me like a Java ripoff.
Hope this helps.
The Tyrrany Begins....
Finding God in a Dog
Ok, as applications, as computing in general, becomes more distributed, I see this type of "Grand Unification" stuff going on. We are no longer in a world of standalone, network independent applications. We're not even in simple client server. As Sun puts it, "the network is the computer", We are in a many to many world, many clients, many servers, many pieces of code which are both, in an arbitrarily teired environment.
.NET matters: migrating a humongous amount of legacy code to this new unified network-centric world, making this migration as painless as possible for C/C++, MSVC, and VB heads, and those already sunk to the waist in other Microsoft legacy crap. If you're in a Microsoft-oriented world, well, yeah, .NET is some hot sh*t because it now allows you to join everybody else. On the other hand, if you are starting from scratch building some core enterprise infrastructure, I'd go with J2EE. It supports (embraces but doesn't extend or extinguish!) pretty much every important standard out there, and is quick to support new ones (e.g., XML). And there is a lot of Open Source support for Java-oriented stuff (Apache's Java and Jakarta umbrella projects for instance).
I'm a full-time Java programmer, so I think J2EE is an excellent "unification". You have everything you need: full featured, cross-platform applications, RPC via RMI or CORBA, "mobile code" via serialization and reconstitution on the other side, full-blown web application support, (pretty) seamless database connectivity, message-oriented middleware, network-aware device capability, Java on portable or embedded devices, myriad well-written libraries and projects under review for addition (generalized preferences, logging, assertions...)...it just goes on and on. Sun's one fault, if it can be considered that, which Microsoft seems to be trying to take care of, is support for multiple languages *within* the VM. Well, technically there is nothing stopping you from writing a compiler for a language that compiles to Java bytecode, but the VM spec and the Java language spec are in some parts interdependent. But I can't blame Sun too much for this...after all, their ability to control Java is what has brought us these solid standards and libraries.
Here is where I think
Ok, I suppose that's enough of a plug from me. I just wanted to give the perspective of someone who is already where Microsoft wants us to go tomorrow.
It's 10 PM. Do you know if you're un-American?
"It's Microsoft's groundbreaking new technology that lets any language call objects written in any other language!"
"Wow! So what's DCOM?"
"It's Microsoft's groundbreaking new technology that lets any language call objects written in any other language over a network!"
"Wow! So what's ALT?"
"It's Microsoft's groundbreaking new technology that lets any language call objects written in any other language so you perform do automation!"
"Wow! So what's an OCX control?"
"It's Microsoft's groundbreaking new technology that lets any language call objects written in any other language through controls that can be manipulated with a GUI tool!"
"So, what's
"It's Microsoft's groundbreaking new technology that lets any language call objects written in any other language through a virtual machine abstraction!"
Is it just me, or does Microsoft keep inventing the same thing over and over again trying to get it right? Soon enough .NET will turn out to be kinda like COM and DCOM and OCX but not really and then some hot, new, ground-breaking three letter acronym will come out and we will do it all again.
I'm a funny guy. I like it when things are thought out ahead of time so they can become a stable standard instead of yet-another-half-assed-attempt.
As far as other languages being supported, that's what .net is all about. It will work with Perl, Python, VB, C/C++/C#, Cobol, Eiffel, Mercury, etc. The only programming language I know about that doesn't have .net support is Java, but I don't see why support couldn't be built for it. I imagine MS will leave that to Sun and IBM to do themselves, however.
I watch the sea.
I saw it on TV.
No, Thursday's out. How about never - is never good for you?
Unfortuntely, Mercury appears to be highly uninformed as to how the JVM vs .Net work. The JVM is first of all separate from a language. It can and does support other languages including COBOL, a Visual Basic implementation, Python, Perl, Javascript, and a host of others. The one major difference that makes the JVM not very suitable for languages such as C & C++ is that it has a security model that (intentionally) gets in the way. JVM code cannot access the underlying hardware, it cannot format your hard drive, it cannot infect you with a virus. These are all things that .Net is capable of doing. Plain and simple, Java is meant to be a secure web platform that is capable of running all the users programs without exposing them to unnecessary security risks. All M$ did is steal much of the JVM code for their vaunted C# and then expand it into .Net.
What does this mean to Joe Schmo? To put it simply, does anyone remember web-enabled ActiveX applets? I rest my case.
Javascript + Nintendo DSi = DSiCade
This is a little tongue-in-cheek... but maybe the reason MS threw money at Corel was to distract it.
.NET is! Let's write our apps in C# and port our apps to it!
You know Corel: always fascinated by the latest gegaw. Ooh, look at how sparkly Java is! Let's write our Office product in Java! Ooh, look at how sparkly Kylix is! Let's buy the company! Ooh, look at how sparkly Linux is! Let's port our apps to it!
And now... OOOOooh! Look how sparkly
Corel, with it's attention-deficit disorder, could very well forget that they've got a Linux project on the go. D-oh!
Like I said, slightly tongue-in-cheek...
--
--
Don't like it? Respond with words, not karma.
Microsoft is brilliant at stealing other's work right away from them (I'm not neccesarily flaming them for this, mind you). Look at how well they poisoned any attempt at operability with their extended Kerberos by distributing the specs for it, allowing thousands of geeks to crack and distribute it and then send out a few weak letters saying "now, stoppit...". I'm sure they only had to seed /. by posting it once or twice, and we did the rest of it for them. Now anyone working on compatibility has to be completely sure that their work won't be called into question, and that they haven't even glanced at the 'stolen' IP before writing code.
Look for more of this type of "hiding in the open" as Microsoft begins playing with open source groups and companies. Hopefully we've learned our lesson on that last one, don't go being contrary about their restrictions just because they say not to. You'll hurt yourselves in the long run.
Fist Prost
"We're talking about a planet of helpdesks."
Fist Prost
"We're talking about a planet of helpdesks."
-Jaron Lanier
I saw a bunch of the .NET stuff at a recent conference. It's some cool stuff, and I was WAY impressed, especially on the ASP+ side, but as far as client apps, it's not a painless upgrade from vb6. Way different. This is in stark contrast with ASP+, which will run side-by-side with ASP pages (new file extension).
:)
.net languages. Write a form in C#, inherit it in VB, modify it, inherit the interface back into C#. Not only that, but when you run in debug mode in the IDE, it seamlessly steps into and out of the bits of code.
.NET language. Also linux, obviously.
Most interesting thing is definitely the CLR (common languange runtime). It gives common data types, and a (beautiful) common object model for system stuff. Also, common performance (it's the same runtime). As he put it "Microsoft (this guy wasn't m$) "Your language is a lifestyle choice" also "Microsoft has been putting 80% of it's R&D budget into it. If you think you can write better c++ garbage colleciton, go ahead, but early tests show even VB.NET and c#.NET written against the CLR outperforms the vast majority of C++ code today." Not sure whether I believe all that
Also, you can do full inheritance, etc. AMONG THE DIFFERENT
An old VB head had an interesting point too. By abstracting the API into an object model, it really paves the way for platform independence. After all, he said, if wrote a CLR for the mac, for instance, it would be trival to port a program from any
Anyway, those are my thoughts.
---
DO NOT DISTURB THE SE
A couple things that I feel should at least be put out in the open:
.NET has been in development for over 3 years.
.NET application at http://www.ibuyspy.com/ where it has been running without fail for approximately 6 months.
.NET, you can write in *any* of over 15 already-announced languages.
1.
2. You can visit a sample
3. You can download the pre-beta SDK and develop in three languages *today*, and it all just works. I've played with it extensively.
4. The Common Language Runtime compiles only the functions that are called, and it uses an optimizing compiler to do it. When other functions are called, they are compiled just-in-time (saves a lot of system resources).
5. All languages are on equal footing. They all share the same GC and debugging features. You can spawn threads in VB just as easily as in C++.
6. You can inherit a VB class into C# into C++ and back into C++ if you want to.
7. Everything is strongly typed...no more figuring out what kind of string that function in C++ expects. Just call it natively. It just works.
8. The Common Language Infrastructure (which includes the CLR) is being submitted to ECMA (a standards body).
9. So is C#.
10. With Java, you have to learn Java. Plus, statistics show that 70% of all Java developers target APIs that are native to their platform. Thus, the "write once, run anywhere" promise never comes true except in the most simple of situations. With
11. Although I could go on, I have to mention that it just kicks major ass.
If you actually want to speak intelligently about this, you really owe it to yourself to try it out. Or, you can complain that the ".NET" term doesn't make any sense, thus, because of that severe brain blockage, you can't actually talk about the technology and its merits, because you've never even given it a chance.
The sad thing is, you'll be talking it down, when in fact, it's one of the coolest things I've ever seen in this industry. Linux or not.
www2.hursley.ibm.com/tc39/mins-28sep00.html has some minutes of a ECMA meeting that talks about the standardization of the CLI and C#. Obviously we don't know what they mean by open-source and it isn't clear whether they want to release their non-Windows implementation, but I think there's nothing in the platform itself that is Windows specific. The apps written on it might be a different matter.
I think the important thing to do when trying to guess Microsoft's motives here is try to understand how they are trying to improve on Sun's offering. And remember that Microsoft might not care too much about giving away a platform that runs on all OSs (after all, Windows earnings aren't the cash cow they used to be) if it means they can make money on the platform.
Of course this is looking on the bright side, perhaps their plan is much more nefarious and evil in intent. My point is simply that because Sun has been a bit closed and static with Java and the JVM, perhaps Microsoft has something to gain by being open with the CLR.
Disclaimer: I'm a former Mercury developer. I left the project before Microsoft approached the Mercury guys, but after a fairly scary dinner with James Plomondon, whose job title at the time was "Principal Java Evangelist, Microsoft Corporation". It's a long story, which can be told some other time.
Anyway, .NET has, as part of the system, a common language runtime (CLR) for different programming languages (and I mean very different programming languages; C++, ML, Perl, Haskell and Mercury are about as mutually different as languages can get). This distinguishes it from COM/CORBA where objects must be "marshalled" and "demarshalled" (i.e. serialised and deserialised) when communicating between different languages, even on the same machine. With .NET, different languages use the same binary layout and so can just share the memory.
This represents a unique opportunity for language researchers to get their language used. Software is increasingly being written based on a component model, but implementations of technologies like COM and CORBA impose a significant overhead when moving from one language to another. The .NET system means that you can mix and match languages without the associated performance impact. If you think it's easier to write your GUI in Java, your AI engine in Mercury and your time-critical data logging stuff in C++, you can do that, and you don't pay such a huge price for the mix. This means that programmers can try out new programming languages in their projects without having to go "all the way".
The Open Source community must take note of this! Admittedly we haven't seen much in the way of actual technical detail about .NET yet, and Microsoft's implementation might turn out top be hopeless, but the CLR is a good idea.
And now, the obligatory conspiracy theory for the day: As operating system kernels get smaller, moving data between OS components efficiently becomes trickier. The Hurd uses the Mach IDL, which is not unlike the CORBA IDL only much more lightweight, to marshall and demarshall data for the various components, for example. The CLR might represent the first part of a new operating system from Microsoft; one which will eventually replace NT, because it provides a way to build an object oriented OS in multiple languages without the serialisation costs.
Microsoft already has a suitable microkernel which could support CLR. It's called Windows CE.
They also have a motive. As we all know, Microsoft only "innovates" when they're trying to kill off competition. (For example, IE to kill off Netscape, Win9X to kill off OS/2, NT to kill off Netware and other similar systems.)
Watch carefully.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
I also question the need to abandon platform independence in order to get some perceived language independence. MS has absolutely no motivation to implement an architecture that would provide BOTH language independence AND OS indepence and guess what JVM already does that!.
Of course all the MS shops will use
A Dick and a Bush .. You know somebody's gonna get screwed.
War is necrophilia.
But that cross-platform bit makes me wonder how any of this is an improvement over the JVM. Code for the JVM compiles to JVM bytecodes which are turned at runtime into native code. How and when this happens depends on the JVM (HotSpot, JIT, TowerJ, etc.), but the net result is the same.
People have ported other languages to the JVM (JPython being the best known example), and it's pretty easy to hook Java code up to DCOM (Take a look at J/Integra from Linar Systems). Granted, it sounds like MS added VM opcodes to .NET's VM to improve performance for languages besides C#, but that's just a nice addition.
So, can anyone give me an objective reason why this is better than the JVM? Or is .NET only MS' version of the JVM with C# being its version of Java?
-jon
Remember Amalek.
The real question is, how stable will it be? Every software vendor out there is rushing to develop new architectures, technologies, etc., but they don't spend nearly enough time testing. True, garbage collection should improve stability, but that's only if garbage collection is implemented properly. People are likely to just jump on the .NET ship and hope that it will cure all their problems.
.NET, Java is a mature technology, yet it's still not very good. I'd rather see developers put their energy into making Java mature and bug-free, even if .NET is technically superior (not saying that it is).
When will people realize that there is no silver bullet? More than all these fancy technologies and buzzwords, we need good software engineering and extensive testing. Customers share part of the blame for not shunning companies that produce crappy software. Capitalism only works if customers use their brains.
Here's a quick question for you: How many broken Java applets have you seen? How many have you seen that work perfectly? I almost never see Java applets that work perfectly (may be my JVM, but what good is the cross-platformness of Java if you can only get a working JVM for one platform?). In comparison to
This is my rant for the day. Yes, good architectures help, but good software engineering and thorough testing will always be most important. Too bad they aren't sexy enough to get the attention they deserve.
Yet another example of how immature the slashdot audience is. Microsoft has come up with a winnning technology here, it's going to be the future of computing as we know it. Just because its not GNU licensed and powered by Linux doesn't mean that we can't appreciate their work. Microsoft has plenty of programmers who have the same ideas as we do, and they're implementing them, better. If the Linux side of things wants to bash MS, they should at least find some real problem of theirs, such as Bill Gate's alleged affair with an intern, rather than bash a wonderful and proven product such as .NET which has been out for years and is succeeding beyond Microsoft's wildest dreams. MS's Windows Terminal Server performs over 30x as quick as XFree does, while providing even more functionality, such as a way to save files on Microsoft's core server with the touch of a button. Linux lovers watch out, the future of computing is already here, and its name is .NET
Shine on, you crazy diamond.