Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Microsoft

Mercury Researchers Explain Microsoft .NET 197

Posted by Hemos from the getting-the-skinny dept.
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."
This discussion has been archived. No new comments can be posted.

Mercury Researchers Explain Microsoft .NET More

Mercury Researchers Explain Microsoft .NET

Comments Filter:

  • Forget C# .NET provides more than just C# (Score:4)

    by cOdEgUru ( 181536 ) on Wednesday October 04, 2000 @03:08PM (#731003) Homepage Journal
    .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.

    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 .Net holds up against Java.
  • True, but you can do the same with Java.
    There is little difference (in terms of open-ness) between Jikes (or JPython) for the JVM, and Mercury for .NET

    Jikes is free software (GPL I think...?) translates it's language (Java) into the platform's implementation language (java byte code). JPython is the same, but for a different language.
    As far as I could tell, that is all that the open-ness of mercury will give you (unless you're actually interested in the mercury language).

    --

  • Like Mac OS X doesn't have a hefty hardware spec? Something like a top-end G4 and 128Mb as a bare *minimum* ?
  • I saw Gates talk about .NET a few weeks ago and I remember him saying that you can write an app in a language but you will have to "minimally adjust" the code to suit the platform. This sounds a lot like Java. And isn't this what led to Java's dimise?
  • Looks like someone was at the ASP/VB/C++ Connections conference in Phoenix.
  • If a language is worth using, the syntax is the least of your worries!
    Corollary: If a language's syntax is a nontrivial worry, the language is not worth using.

    For some reason, though, people continue to use sendmail and procmail, both of which use configuration languages whose syntax is decidedly nontrivial and nonobvious. Moreover, people continue to invent new programming languages with take-offs on well-understood existing syntax.

  • > Also, you can do full inheritance, etc. AMONG THE DIFFERENT .net languages. > Write a form in C#, inherit it in VB, modify it, inherit the interface back into C#. Have you ever looked at Borland Delphi and C++ builder !?! They ave been doing this for ages ...
  • Unless you want to count our assumption that lines are terminated with "\n".

    We don't even rely on that. I can't imagine 70% using a native API either. Whatfor?

    We develop a large applet/servlet app in IBM's visualage on windows, which will be deployed within netscape (applet) and unix/jrun (servlet), talking over Corba to mainframe-PL/1 programs.

    We can move from development (visualage/windows) to deployment (unix/jrun) without any problems or changes. The platform independence really is a crucial advantage.

    As long as .net isn't available for other platforms, its useless.

  • Yes, Perl and Python are there. ActiveState was at the MS PDC. There's even a mailing list about it at ActiveState (though I've seen no traffic on it).
  • I can seem them all coming now, with COM and .NET, there is going to be an era of ORG jokes.
    The technology is neat. I want to see what it looks like post-release.
    Beta is bostonian for "Its Beta then Alpha"
    heh
    --jay
  • just a note, this mercury thing has been developed by the School of Electrical Engineering and Computer Science http://www.cs.mu.oz.au ( My faculty ) of The University of Melbourne. :)
  • 5. All languages are on equal footing. They all share the same GC

    Please direct me to the chapter in Stroustrup where it says that C++ uses a GC.

    Why would I want to develop speed-critial parts in C or C++ when the program gets compiled into bloody byte-code for a VM?

    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 .NET,
    you can write in *any* of over 15 already-announced languages.

    You're mixing up language-independence and platform-independence here. While I agree that language-independence and fast and efficient language mixing is a great thing, I've yet to hear of any platform-independence for .NET. Where is that link to the Linux executable?

    Besides, I seriously doubt that TogetherSoft's development tools qualify as "most simple"...

    Cheers, patrick
  • I think the cross-language features of the CLR are very innovative. I think a really interesting aspect of the CLR is whether Java (the language) will ever be supported on it. I'm sure Microsoft would love to support it, think of all the developers cut out of using the CLR otherwise! It would be quite a shame if the still pending Microsoft vs. Sun suit over Microsoft's Java implementation were preventing this from happening.
  • As far as I know C++ code will always be 'unsafe'.
    I mean there will be no possibility to write 'safe' code even using managed C++. Managed C++ just adds extensions for garbage collected classes and such.
  • This is a pretty much correct analysis of the situation.

    You can always implement any feature on the JVM, but it might not be very efficient, and it might not be very interoperable (that is, other languages and tools can't use it because they don't understand your implementation fully).

    While the CLR doesn't support every language feature yet, it supports more than the JVM, and has a view to changing in future versions.

    Microsoft is differentiating themselves from Sun by providing a multi-language product that changes, instead of a single language product that is very rigid (or solid -- depending on your preferences). Both had pros and cons, but for 3rd party language folks and researchers CLR is much more attractive in theory (but of course success of it as a product when launched is a factor).

  • As far as I know C++ code will always be 'unsafe'.

    Well, you're wrong. C++ that is compiled to run on native processors is generally unsafe but security is traded in for efficiency, but there isn't any 'unsafety' built into the language.

    There are a few C++ interpreters that use a byte-code virtual machine similar to Java that are just as safe as Java (in both cases, you have to assume the VM programmers did a good job on implementing the security sandbox).

    Of course, with interpreted C++, you lose efficiency vs compiled C++, but that's no different than with Java.

  • Sorry for vague posting. I tried to say that there is no way now for you to write 'safe' (in .Net terms) code using Microsoft C++ compiler which is available through http://msdn.microsoft.com/net/
    even using so-called Managed Extensions for C++.
  • So, can anyone give me an objective reason why this is better than the JVM?

    No objective reason, but a supposition...

    Suppose they wrote a VM that doesn't use a stack for the registers and everything else. Wouldn't it scream? Stacks are actually kinda slow...
  • Not necacasarrililly http://www.microsoft.ad/ (also one of the best pages I've seen for a long time) at least doesn't seem to be theirs (I was going to go through them all with the aid of my rather funky map from Nominet, but when you take into account all the .co.ccTLD .com.ccTLD etc probably not a good idea).

    anyone with even less of a life than me (is such a thing possible???) should easily be able to find a list of international registrars and spend a few happy hours finding out.

    What was the topic again?

  • If MS was able to get the Merc folks to cooperate, what about the poobahs of other languages? Have they been working on .net ports and we haven't heard about it because of NDA's. Were they approached?

    Jonathan Moran
  • 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.
    Only time will tell if it's a winning technology or not. It's far too new to make that claim at this time.

    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.
    Over 30x "as quick"? Somehow I doubt that. I've seen both XFree86 and Microsoft Terminal Services run quickly, and I've seen both run slowly. It depends on what's going on on the client machine, and the bandwidth you have available. I also fail to see how it provides more functionality, as both are merely a way to run programs remotely over a network.

  • Re:Will it be stable? (Score:3)

    by TWR ( 16835 ) on Wednesday October 04, 2000 @03:13PM (#731024)
    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 .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).

    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

  • kuro5hin is already old, it sucks, and how do you pronounce it anyway?

    Try this DotSlash [hell.com].
  • Suppose they wrote a VM that doesn't use a stack for the registers and everything else. Wouldn't it scream? Stacks are actually kinda slow...

    The stack architecture in the JVM is an abstraction; when the JVM compiles to native code, values that should be in registers are in registers (and register coloring and other optimizations are probably easier to do with live profiling information). If you think of the stack as an infinite suppy of registers, then it starts to make more sense. Using a stack-based architecture lets the VM pretend it has infinite registers, and then the native compilation step does the Right Thing.

    -jon

  • Yah, I think the Plan 9/Inferno group over at Bell Labs is planning a Limbo port. And to think Bob Pike thought systems research was dead.

  • In the article at Red Herring, on the second page, the interviewer asks:

    And is Dot.net a platform-independent strategy?

    Bill Gates replies:

    No. No. Dot.net is a Microsoft platform. Just like the Windows platform. Windows was built on common standards, like standard character sets like TCP/IP. It was all built on standards. But it was a Microsoft platform, too. The Dot.net is a Microsoft platform. We haven't decided that Microsoft is a zero-revenue company.

    No. No. Dot.net is a Microsoft platform. Just like the Windows platform... Don't anyone kid themselves into thinking that Microsoft is interested in playing nicely with others.

    One way to lead is to walk in front of the marching crowd. When the crowd changes direction you can either run faster in the new direction and get in front again or you can stop claiming to be the leader.

    The software industry "crowd" has changed direction. Watch Microsoft run to be in front again.

    The article is here: http://www.redherri ng. com/mag/issue82/mag-gates-82-home.html [redherring.com]

    PS: When is this damn little textarea going to be tweaked to a reasonable size?


    OpenSourcerers [opensourcerers.com]
  • ASP is basically it's own programming language (albeit a small one), and ASP+ works by generating interfaces on the fly into your language. You need to implement a code-generation API to do this.

    BUT this code only gets run once -- to generate the interfacing code. A few methods get generated on the fly, then they get JITed and run as native code from then on.

    So you need to implement an API to plugin to the ASP+, but that's just to interface ASP stuff to your backend, once the code is actually running it all runs as native and that API is no longer used.

    I hope that explains it better. There is no per-call interface to go through (although you are doing stuff over the web so of course things have to be turned into representations suitable for sending over the network).

    For web services you don't even need to do any of this, you just mark the service as a web service and edit some configuration files.

    For embedded languages you just edit some config files to tell it where to find your compiler.

    Only ASP+ needs "real" work to be done.

  • Plus, statistics show that 70% of all Java developers target APIs that are native to their platform.

    Say again? We're writing a fairly heavy-duty AppServiceProvider-model application with JSPs and servlets hosted on IIS/JRun and I don't believe we've had any temptation whatsoever to use "native APIs" (whatever that is). Unless you want to count our assumption that lines are terminated with "\n".

    Where did you get that 70% figure?

  • Well, there's MS bashing and then there's sucking MS's cock. Are you deliberately going the other way to prove a point, or do you really think .NET is "the future of computing as we know it"?

    Oh, hold on, you just said .NET is a "wonderful and proven product which has been out for years". Dammit, I've been trolled ;)

    --
    It's a .88 magnum -- it goes through schools.

  • Microsoft didn't come up with it. They just recognized a possibly good thing and are trying to be first on the bandwagon to adopt it.

    What theese people have here sounds interesting. It needs to be studied more and explained better.

    Besides, this thing _is_ GNU licensed. That's why I won't reject it out of hand and/or try to build a duplicate that is.

  • Netcraft [netcraft.co.uk], has a service to find web servers with addresses matching an expresion like "*.microsoft.*"
    __
  • actually, someone at the conf. mentioned that you could do this. Pretty neat. We use a lot of Delphi for our product here (I do web stuff, don't work on the actual software) and a lot of guys really like it.
    ---
  • Right but the object model, data types, etc. is documented. All you would have to do is build your own. If you support the objects, methods, properties, and data types for those, it should work. As long as the program doesn't directly call the windows API (in other words, is completely .NET compliant).
    ---

  • Re:Here's The Thing (Score:3)

    by bnenning ( 58349 ) on Wednesday October 04, 2000 @05:20PM (#731050)
    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.

    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 [tu-berlin.de].

    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

  • So all .NET code is supposed to use the common type system? But isn't the differences among type systems one of the main reasons for choosing a particular language for a particular job? This sounds like "use whatever language you want, just be sure to smoosh it into the .NET paradigm".
  • You can't even quote from Sun webpages about this. How can you even begin to prove these outrageous claims?

  • Seen in employment ad this week (Score:3)

    by the eric conspiracy ( 20178 ) on Wednesday October 04, 2000 @05:35PM (#731059)
    Required: 5 years experience developing with Microsoft .NET
  • From the article, "except for NDAs no contracts were signed"

    A few years ago when I was working on my MS, their head of Microsoft Research visited and asked our research group what he could do to help. They were extremely generous with software and documentation but as far was grants went they wouldn't even buy pizza let alone provide meaningful funding without specific strings attached. At one point they actually offered less than $2000 for code that took me an entire summer to write. Ugh...

  • Yup, and they gave IE away free for gods sake! why is everyone bashing MS??? (PS: for the hard of thinking, j/k) (PPS: altogether in fact, apart from the fact that it really needs more than my puny 128M of RAM W2K isn't that bad...) (PPS: ok ok I admit it I'm just going for the Greatest Amount of Karma Points Lost in 24 Hours world record)

  • 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.... [fearbush.com]

  • Grand Unification (Score:3)

    by Hard_Code ( 49548 ) on Thursday October 05, 2000 @05:29AM (#731067)
    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.

    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 .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).

    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.
  • On the other hand, .NET is their big enterprise play, so hopefully they will be using it to fix their security partitioning problems.

    Interesting, but I think that Microsoft's track record has been to favor added features over security.

  • I've whipped up some managed code with Python, so there's more than 3 out there, with more on the way. It'll just be another tool. Similar hype with Java, right?

    -beme
  • Also, you can do full inheritance, etc. AMONG THE DIFFERENT .net languages.

    Sounds like a complete maintenance nightmare.

  • In that case it would be:

    koo-row-five-hin

  • Wait till they start holding data hostage. so you don't want to pay the new licensing fee? Here's how much it will cost to get your companies data back.

    Yep, I have seen scenarios like this, most often because a company adopted a propritary format in a vertical market. They are the only ones that know how to get your data out of their weird files, and the market is too small for anyone else to be motivated to break the system. Allows mini-monopolies.
    -

  • Diskless workstations from Microsoft? When they put how much code on a hard disk for an OS install?

    Hehe, well when bandwidth gets as fast as your PCI bus is today, it won't matter much, now will it?
    -

  • Wow, Innovation (Score:4)

    by stuce ( 81089 ) on Wednesday October 04, 2000 @03:35PM (#731082)
    "So, what's COM?"

    "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 .NET?"

    "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.

  • SOAP could be a good idea, but I'm not exactly sure that I like the security holes that it opens up. Counterpane [counterpane.com] points out that Microsoft's own security analysis faults SOAP for being able to "hide" protocol commands from firewalls. That basically means that you either prevent SOAP from at all functioning across your firewall, or go without a firewall. Granted, firewalls aren't the best security policy in the world, but I'd rather be assured that they'll work as advertised than have to worry about a brand new hole.



    The Tyrrany Begins.... [fearbush.com]

  • Re:Other languages? (Score:5)

    by Pinball Wizard ( 161942 ) on Wednesday October 04, 2000 @03:38PM (#731084) Homepage Journal
    methinks Microsoft is starting to change its tune. Almost everything I've read about them lately shows that they want to ditch the "evil monopolist" image they created for themselves. They apologized to the Linux/NTFS developers, for example. They are funding open source development companies like Corel. I am open minded enough to ditch my stereotypes about them if they continue to behave as citizens in the corporate world.

    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.

  • 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.

  • No, they probably won't, but this platform on top of .NET will be. And since it will be, you can look at it and see how .NET works.

    Maybe they'll try to cover that with other forms of IP, like patents. I don't know.

    All I know is that I read the article, and my brain wants to shut down into 'your subconcious is thinking hard about something' mode. Something about it is intriguing.

  • Corel .NET (Score:4)

    by FFFish ( 7567 ) on Wednesday October 04, 2000 @04:07PM (#731090) Homepage
    This is a little tongue-in-cheek... but maybe the reason MS threw money at Corel was to distract 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 .NET is! Let's write our apps in C# and port our apps to it!

    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...


    --
  • You thought diskless workstations sucked in the past? Just wait until MS builds one.

    Diskless workstations from Microsoft? When they put how much code on a hard disk for an OS install?

  • Re:Will it be stable? (Score:3)

    by Fist Prost ( 198535 ) on Wednesday October 04, 2000 @04:08PM (#731093) Homepage
    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."

  • Both CORBA and COM/DCOM are horrible answers to the cross-language communication problem. A function call should be a function call, not a network message. They aren't the same thing. That's why microkernels aren't such a hot idea either.

    Since RPC style methods are so bad for cross-language communication, why not do something different, and just standardize on data representations instead. Then function calls work like they're supposed to. It's an interesting idea.

  • I can do better.

    Microsoft FuCKiNG sucks!! In every thing this corporation does, not one bit of concern is shown for the end user - unless it means more money, power, and control for Microsoft. Why do people keep falling for it?

    --

  • .net (Score:5)

    by Pfhreakaz0id ( 82141 ) on Wednesday October 04, 2000 @04:09PM (#731096)
    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).

    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 .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.

    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 .NET language. Also linux, obviously.

    Anyway, those are my thoughts.
    ---
  • Microsoft is trying to take over all of Java's functions without using Java. Why would they put forth such effort to reinvent something which already exists and is in use by virtually everyone? Because Microsoft wants to control you, your future, and the world. It is time for an end to Microsoft.

    --
  • hope that deprecation hasn't removed anything you need to run an older applet.

    No part of the Java API has actually been REMOVED yet (except for the "private protected" visibility modifier, and I don't think that even survived beta). An applet written for JDK 1.0 will work just fine under JDK1.3.

    I didn't know about the 22 VMs. Where did you learn that?

    There were something like 22 different versions of Netscape for the different OSes (Solaris, AIX, Linux, Mac OS, Win16, Win32, xBSD, IRIX, HP-UX, I'm forgetting a few) and different hardware (Sparc, x86, MIPS, 68K, PowerPC, Alpha) Netscape ran on. There was no way to use any other JVM except for the Netscape one until the Java Plug-in.

    Apple still gets complaints about the poor quality of Java under Netscape, even though Apple had NOTHING to do with the JVM, and has no way to fix it.

    -jon

  • This appears to be a way to get cross-language call compatibility without resorting to RPC ugliness like CORBA or COM/DCOM. Despite RPC protocol's attractiveness, they are bad solutions to the problems they purport to solve.

    The 'R' in RPC stands for REMOTE it purports to solve the problem of calling a function in a different machine. Back in the early days of things like Xerox Courier, you would usually be using the same language at both ends.

    CORBA is about DISTRIBUTED Object Based Computing. It purports to sove the problem of invoking methods in a different machine. They did this in a way that explicitly caters for different languages at each end, but that is not the primary objective.

    The 'D' in DCOM stands for DISTRIBUTED, it is about doing COM between machines, and I would prefer not to talk about that.

    RPC is inherently slow. It forces a process context switch, and it forces data to be mangled into a standard streamed format, and the worse thing is that it makes all this look like an innocuous simple function call. I've felt RPC was ugly every since I first saw it.

    Doing anything between machines is slow compared with a function call. One reason why CORBA was invented was because old-fashioned RPC made you rewrite your code if you wanted to change which pieces were remote. The advance was to make it possible to get back some of the performance if the thing you were calling happened to be in the same place as you.

    This takes a very different approach from RPC. Instead of literally sending messages to one another, languages hand eachother datatypes that they can mutually agree on the interpretation of. Much cleaner and quicker. A function call becomes a function call again. No context switch, no data mangling.

    Except that if you want to be able to do "remoting" as MS calls it, you inherit from MarshalByRefObject, and all the stuff you hate comes back again. Fields and attributes automagically become methods (get/set pairs), and a whole stack of marshalling and transport stuff kicks in as soon as the object you are calling is remote. What looks like an access to a field of some object gets mangled into a streamed format, by default using XML which is verbose and expensive compared to your average RPC, but not standardised to that so you have no guarantee of interoperability (like CORBA before the customers screamed and screamed and SCREAMED and the vendors finally gave in and implemented IIOP).

    Maybe we'll get back to the nice old days of C, FORTRAN and Pascal where you could call the other languages functions in the same address space.

    If you want to limit your programs to one process in one machine then that's OK, but it is not what Microsoft are doing with .NET.

    BTW, this is all a guess. The article is kind of vague.

    The article is just one item in a mass of data about .NET that is sloshing around the web. The difficulty is in extracting information from that mass of data, acquiring knowledge from that information, and finally achieving wisdom in the light of that knowledge. Ill-informed speculation is the stone in your shoe as you tread that long and weary road.

  • You're confusing VMs and library implementations notably the AWT. Netscape did screw up the VM (that actually runs the bytecode) among other things by coupling it too tightly to the rest of their browser because they failed to understand that implementing a language runtime is really quite hard. This causes most of the crashes, especially when combined with glibc's rather over-sensitive malloc implementation. There are only small differences in VM implementations on different platforms (threading, mostly), and none of these should be user visible.

    However, the cause of most of the incompatibility is the large number (actually its 3, Mac, Windows and Motif/Unix) of AWT and standard library implementations. Netscape tried to do it all themselves without licensing Sun's code. Given the speed Sun changed early versions of the platform at, that was fatal.
  • CE to replace NT???? You are kidding, right?

    It's only a conspiracy theory, of course, but the suggestion was half serious.

    CE is the only operating system that Microsoft has worked on (unless you count OS/2) which could be called truly "innovative". The only way that you can get Office (even if it is the cut down edition) to run on a palmtop is to use an OS with almost no bloat. CE has almost no bloat. All you need is a bloatless OS and the CLR and you have a nice framework for a new OS.

    Besides, the issue as I see it is not "CE to replace NT", but "something new to try to kill off competing OSes". It might not be CE. CE would, after all, need some extensive modification (at the moment it is targeted to architectures without MMUs, for example) to compete. They might decide it's better to buy a company with a suitable microkernel.

  • Stroustrup has always claimed C++ can use a GC, and it is almost true. There are conservative garbage collectors implemented by ignoring attempts to free memory, or regarding as mere hints, that will work both with C and C++. Its helpful to compile applications with a tendency to leak memory against these things, as it does reduce the problem.

    However, most of the advantage of a garbage collector is that it saves developer time, and allows applications to have a structure more natural to what they actually do, rather than one twisted by the need to track memory usage, or by crufty reference counting schemes written by people who do not understand memory allocation (its rather a black art).

    To be portable, C++ applications must assume they need to call delete, and that they need to take care of housekeeping. C++ programs written assuming a garbage collector are very unlikely to be portable. It must also be noted that conservative garbage collectors have rather poor performance characteristics compared to state-of-the-art GCs for languages without ad-hoc pointers.
  • Mercury is a research project at the University of Melbourne, not a company. The funding we got from Microsoft came with no strings attached.

    Sure, it benefits MS to be able to say they have lots of languages supporting .net. But it has also benefitted Mercury by enabling us to write a new backend with which we can easily target many other VMs, including the JVM, thus increasing the usefulness of our language.
  • Yep. Since ML supports paramteric polymorphism but not subtyping, and CLR supports subtyping but not parameteric polymorphism, I'll bet they had a great time fitting ML in there.

    I also noticed that the "Eiffel#" port amounted to "throw away the bits of Eiffel (e.g. MI) that don't fit into C#".
  • I think it's a little late for that scenario. You won't need to explain to the newest of newbies more than once that no hard drive = no storing stuff that the man doesn't want you to. Diskless workstations are going to go over like a led zeppelin, and MS knows it.

    More likely they will attempt to end piracy of *their* apps by slowly phasing out physical copies. Certainly you won't need to install 800 megs of bloat in order to use office, provided you maintain your subscription all the popular apps will be piped on-demand to your screen. Maybe an operating system kernel that immediately connects to the net and updates itself and vital system files to the latest version, provided your account is still active. Think Microsoft Windows Update around the clock. Of course companies that choose not to partner with microsoft.net could very well be patented away from adopting the same types of schemes, and will continue to distribute there wares in a pirate-freindly, copy to the hardrive edition only.

    Fist Prost

    "We're talking about a planet of helpdesks."
  • Sure, it does hide it from the Firewall. But you could use Firewall to look at SOAP Packets and then stream them inside. Its possible. Look at the new Spec for SOAP. Another thing is SOAP is a Simple protocol. It leaves pretty much everything else like Garbage collection, Security etc to the person who implements the solution. Thats the beauty of it and thats its flexibility and thats why its not cumbersome like IIOP or RMI or DCOM
  • Basically, it looks to me like a Java ripoff.

    He answered the question crackhead.

    --

  • Re:Wow, Innovation (Score:3)

    by cpeterso ( 19082 ) on Wednesday October 04, 2000 @03:57PM (#731122) Homepage
    Don't forget Microsoft's succession of redundant and incompatible database APIs:
    1. ODBC (Open Database Connectivity)
    2. OLEDB (OLE Database)
    3. DAO (Data Access Objects)
    4. ADO (ActiveX Data Objects)
    5. XDO (XML Data Objects, not yet released?)


  • Preliminary Analysis

    This appears to be a way to get cross-language call compatibility without resorting to RPC ugliness like CORBA or COM/DCOM. Despite RPC protocol's attractiveness, they are bad solutions to the problems they purport to solve.

    RPC is inherently slow. It forces a process context switch, and it forces data to be mangled into a standard streamed format, and the worse thing is that it makes all this look like an innocuous simple function call. I've felt RPC was ugly every since I first saw it.

    This takes a very different approach from RPC. Instead of literally sending messages to one another, languages hand eachother datatypes that they can mutually agree on the interpretation of. Much cleaner and quicker. A function call becomes a function call again. No context switch, no data mangling.

    Maybe we'll get back to the nice old days of C, FORTRAN and Pascal where you could call the other languages functions in the same address space.

    BTW, this is all a guess. The article is kind of vague.

  • And before COM, there was OLE. Before OLE, there was DDE. Lots of Windows is still held together by DDE - in particular, that's how Explorer manages file type associations. I think Windows 3.1 had something before DDE called the Object Packager, too, but I never really looked at it hard enough to figure out what it was all about.

  • Here's The Thing (Score:5)

    by MSwanson ( 99458 ) on Wednesday October 04, 2000 @04:20PM (#731131)
    A couple things that I feel should at least be put out in the open:

    1. .NET has been in development for over 3 years.

    2. You can visit a sample .NET application at http://www.ibuyspy.com/ where it has been running without fail for approximately 6 months.

    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 .NET, you can write in *any* of over 15 already-announced languages.

    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.
  • I'm pretty sure ODBC was invented by Microsoft. I used it for a while in '93-'94. They might have submitted it to X/Open later.

  • More information on .NET (Score:3)

    by tyse ( 38850 ) on Wednesday October 04, 2000 @06:45PM (#731139)
    Since I wrote the linked to article (I came in to work and everyone just said "read slashdot!"). I thought I might elaborate a little on what information has surfaced since I wrote the Mercury and .NET page.

    www2.hursley.ibm.com/tc39/mins-28sep00.html [ibm.com] 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.

  • hmm it's more that i've seen a LOT of pages that i like that one....

    a full stop is nice after the incessant stream of information from other sites.

    admittedly the code sucks

  • Somebody on this thread had a link (too bad I did not bookmark it) that showed a BUNCH of languages that ran on the JVM. Including odd things like LOGO!.

    A Dick and a Bush .. You know somebody's gonna get screwed.

  • I posted the question as a 1 (ie without the +1 bonus). All I wanted was a simple answer :)

    I too fail to see how my question is insightful- *shrug*

    At this rate I could be a real karma whore if I post more insightful questions such as ... Can someone please explain (in plain English) what the whole meaning behind the Natalie Portman and hot grits posts are about? ;-)

  • And why should MS care? They get to collect .NET subscription fees from everyone.

    That alone sounds like a damn good reason to forget about this thing. I'll stick with Java for now. Don't like feeding the MS beast any more than necessary.

  • This appears to be a way to get cross-language call compatibility without resorting to RPC ugliness like CORBA or COM/DCOM. Despite RPC protocol's attractiveness, they are bad solutions to the problems they purport to solve.

    RPC is inherently slow. It forces a process context switch, and it forces data to be mangled into a standard streamed format, and the worse thing is that it makes all this look like an innocuous simple function call. I've felt RPC was ugly every since I first saw it.

    This takes a very different approach from RPC. Instead of literally sending messages to one another, languages hand eachother datatypes that they can mutually agree on the interpretation of. Much cleaner and quicker. A function call becomes a function call again. No context switch, no data mangling.

    Maybe we'll get back to the nice old days of C, FORTRAN and Pascal where you could call the other languages functions in the same address space.

    BTW, this is all a guess. The article is kind of vague.

  • ODBC is, I believe, an X/Open specification, not a Microsoft one.
  • "They asked for no special intellectual property rights, and indeed except for NDAs no contracts were signed. However, they requested that we provide feedback on what would make the platform better for Mercury, and what criticism (or praise) we (as language designers and implementors) could give on their work."

    Microsoft invited programmers from Melbourne to Redmond without having them sign contracts; only a NDA which is commonplace in any software company. So, from now on, if I catch anyone else blindly claiming that Microsoft is evil, I will show them this evidence!

    One argument that Microsoft is evil is that they "tainted" Sun's Java source. The truth is, they optimized it for speed and performance. It seems that Microsoft was only trying to take Java in the right direction.

  • There's an accessible description of .NET [microsoft.com] in the MSDN magazine.
  • I think this would be a tremendous boon for free software.

    I know many people who would be much more likely to try out Linux/Star Office/Gimp etc. if they actually had to pay for the software that they use.

    If MS's tactic is to allow piracy until they own the market, then try to stop the pirates and soak up the profits, it may just backfire on them.
  • 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.
    Development, perhaps. Debugging? Maybe not. As the Mercury folks mentioned, .NET encourages the mixing of garbage-collectable and non-garbage-collectable pointers, and "verifiability goes out the window pretty quickly."

    Meanwhile, there already exist cross-language network object-model environments [bagfors.nu], some of which support far more languages than Mercury mentions .NET supporting. No, GNOME isn't VM-based, and for good reason; however, it doesn't need to be to support C, C++, Objective C, Perl, Python, Guile, Ruby, Ada, Eiffel, Dylan, Pike, Pascal, Haskell, et al.

  • Mercury and .NET (Score:4)

    by Pseudonym ( 62607 ) on Wednesday October 04, 2000 @04:36PM (#731166)

    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.

  • 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.

    As far as COM goes, this is in error. Marshalling is only necessary for inter-process calls. For intra-process calls, there is no marshalling, and very little COM overhead - even if the language is mixed.

    Thanks for picking the nit.

    Incidentally, I have no reason to disbelieve you (I'm sure you know more about COM than I do), but I'm puzzled: How do you mix C++ and Java data types (to pick two examples) without marshalling?

  • Don't know why I bother to make the 200th post to a Slashdot discussion, but I felt the urge to speak to this...
    But, at this point I don't see how anyone can trust Microsoft to put stability and sound architecture ahead of marketing concerns.
    Mostly, I trust that the people that actually pay Microsoft for software are actually putting stability higher on their priority lists.

    Used to be that the business value of (Windows 3.x + Excel 5.0 - three reboots daily) was clearly higher than (DOS + Lotus 1-2-3), so Microsoft sold like crazy even with reboots. Then (Windows 95 + custom VB app + storebought components + three app restarts daily) had clear business value over (greenscreen apps), so MS dev tools were hot. It was/is Hard to get stability among VB code, twelve VBXs/OCXs, and the inevitable poorly-implemented Win32 hacks, so coders (like, oh, me) did as much as the business value would justify, and then stuff just crashed.

    I think MS's large customers have made it clear that Inter/intranet development means there is business value in 24/7/no hassles plus all "the other stuff" MS dev tools are good at (commodity business app development from prebuilt tools). Microsoft runs harder to stay ahead of Darwin than any other commercial entity - they'll find a way to deliver on 24/7/no hassles if that's what the Very Visible Hand Of Customer Dollars is pushing towards.

    Microsoft may take a platypus-ugly route to evolve to what their paying customers want, but they tend to get there.
  • Taken from the Mercury article...
    "We decided to accept their offer, for two main reasons. First, we have always tried to make Mercury available to the largest possible number of programmers compatible with our means..."
    Taken from the Corel Acquisition Press Release...
    "By leveraging Corel's development expertise and popular product line with Microsoft's .NET platform, we believe we have found a great combination to accelerate this process. .NET promises to be a robust platform that we can use to build innovative, easy-to-use and reliable Web applications and services that will benefit our customers."
    Taken from the Bungie acquisition FAQ...
    "...this move will bring us much closer to domination of the world of gaming than we were ever likely to get as an independent publisher. Halo and our future games are likely to reach an astronomically larger audience than they would have if we published them ourselves."
    You know, the way these companies say it, you'd think Microsoft was doing them a favour by absorbing them into the collective, talking about their long-term goals and strategies (not MS's) and totally avoiding the fact that this is ultimately to Microsoft's benefit, being the primary conduit for their work. Meanwhile, these news items are pretty conspicuous by their absence from the news sections of www.microsoft.com, www.msn.com, www.msnbc.com ... Toning down the "We got another one!" brag factor keeps them from looking like a monopoly, I suppose.

  • Re:Here's The Thing (Score:3)

    by YoJ ( 20860 ) on Wednesday October 04, 2000 @07:14PM (#731182) Journal
    Seeing that description really makes me want to try out the .NET system. Where's the link to the source so I can compile it on my platform? There isn't one? Nevermind, just show me the link to the Linux binary version. Not one of those either? OK, I also have a Mac. No Mac version? Wow, that's really cross-platform. I'm impressed.
  • I'm one of the Mercury developers who was involved in porting Mercury to .net. "Chokolad" is basically correct on this point.

    There's two separate concepts involved here:

    • managed code
    • safe (verified) code

    "Managed code" provides information to the run-time system that lets the run-time system trace the stack. Managed code is required for garbage collection, but managed code is not necessarily safe.

    Verified code is code which is managed and which in addition passes the runtime loader's verification checks. Verified code is safe.

    Microsoft's .net supports both of these: you can have code which is managed but not verifiable, or you can have code which is managed and verifiable. Code which is only managed but not verifiable is not safe, and so can't be run unless trusted. So for unverifiable code the security model is like the security model for Active-X controls (with all that that implies...). Code which is verifiable can be run in a sandbox like Java applets, and so it can be safe to run untrusted code in a sandbox as long as it is verifiable.

    AFAIK you are correct that Microsoft's managed C++ code will not be verifiable, and hence not safe. If you want to write code which is safe, then AFAIK you will need to use a different language, e.g. C# or Mercury.

  • ML programs are hard to compile to Java bytecodes, since Java functions aren't tail recursive. There exists ML to Java byte code compiler (MLj) but it suffers from this limitation. The MLj Compiler [ed.ac.uk]

  • Two points. (Score:3)

    by Malcontent ( 40834 ) on Wednesday October 04, 2000 @10:49PM (#731189)
    First of all the Java Virtual machine already supports more languages then the MS virtual machine. So far the MS virtual machine supports only c# and some derivative of eiffel. The JVM meanwhile supports PERL, Python, TCL, and a bunch of less popular languages. Your premise that the JVM ties you to java is not correct. I will grant of course that java runs better in the VM then say python.

    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 .NET (they always retrain their people with whatever MS is doing at any given time) and I don't see any Java shops abandoning their investment either. The real question is which platform will the new users choose and which platform will be thought in schools.

    A Dick and a Bush .. You know somebody's gonna get screwed.

  • CLR won't be ported to other platforms unless if fails miserably. As long as .net is successful MS has zero insentive to give people both a choice of OS and a choice of language. What would they get out of it. Oddly enought SUN does do that. The JVM runs on any platform and supports a bunch of languages including perl, python, tcl etc.

    A Dick and a Bush .. You know somebody's gonna get screwed.

  • They are redundant, but not incompatible

    ODBC/DAO : They have OLEDB Providers and work just fine under OLEDB / ADO

    ADO : VB Friendly version of OLEDB

    I don't know about XDO, unless that's another name for ADO+. The emphasis on XML is for interoperability between systems. Knowing MS EEE, I don't know if it will really work that way though.

  • How is .NET VM going to be better than Java VM? (Score:3)

    by TWR ( 16835 ) on Wednesday October 04, 2000 @03:00PM (#731195)
    So, there's a cross-platform (and cross-language) VM at the heart of .NET. That's all well and good; IBM was doing research on a Universal Virtual Machine back in the mid 90's.

    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

  • Can someone explain (in plain english) what .net is all about?

  • Will it be stable? (Score:5)

    by tbo ( 35008 ) on Wednesday October 04, 2000 @03:03PM (#731197) Journal
    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.

    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 .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).

    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.

  • MS bashing (Score:3)

    by linuxonceleron ( 87032 ) on Wednesday October 04, 2000 @03:03PM (#731198) Homepage
    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
  • Well, I think you see the power of Microsoft's financial resources at work: without it, a platform like .NET would probably not be particularly attractive to researchers yet. After all, why expend much effort on porting to a platform whose commercial viability is uncertain and that is still bleeding edge compared to the available alternatives?

    What this comes down to is that Microsoft is giving money to a research group and getting feedback on the language independent features of their runtime. That's good because it helps support programming language research, a chronically underfunded area. And if .NET ends up being a good, usable, open runtime after all because of the feedback, even better for everybody.

Slashdot Top Deals

"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs

Close