Slashdot Mirror
Perl and .NET
Kaufmann writes "Good old Perl guru Nathan Torkington has an article on O'Reilly's perl.com about "What every Perl programmer needs to know about .NET". It's quite short and, unsurprisingly, favourable to .NET (although not to Microsoft). Points to the SOAP module on CPAN and a bunch of other stuff. It contains a nasty error, though: claims that Java is the only language that compiles to the JVM. Check it out anyway."
It's already released (well, as beta at least). MS sent out the beta kit for Visual Studio .NET about a month ago, anyone can get it and try it out. A few weeks ago, ActiveState released the Visual Perl plugin for VS.NET, along with Perl for .NET.
I'd say .NET already has a strong presence, for better or for worse. The Question really is when it's actually going to be released as a final product.
"We obviously need a new moderation category: (-1, Woo-fucking-hoo)" --Mr. AC
This page: http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht ml offers a nice overview of languages built on top of Java. Some of them (e.g. AspectJ and JPython) are very interesting. The JVM can already interoperate with COM (i.e. embedding java in visual basic is dead easy) so consequently all the languages on top of Java can use it as well. Assuming .Net builds on top of com, java .net interoperability is already there. No doubt Sun or someone else (voyager?) will fill in the missing pieces (if any) soon after .net is released.
Jilles
I suspect you don't understand the value of firewalls.
You can still stop external computers from initiating connections to local computers. No need for the whole world to see my intranet web server. So blocking incoming port 80 is still valuable. Maybe I have a public web server behind my firewall, I can block incoming port 80 for all destinations except my public web server. The rule of thumb that you should firewall all incoming ports you don't need remains useful.
This leaves outgoing ports. If you open HTTP, a desperate enough program or user can always sneak out through the port. If it's possible to tunnel IP over DNS, it's darn well possible to tunnel IP over HTTP.
All you've lost is your false sense of security.
Search 2010 Gen Con events
"impossibly inefficient"? It's a "serious abuse"? I beg to differ. It's not like building an XML document and sending it in an HTTP request is an O(n) algorithm or something. Yeah, maybe you can preserve CPU and bandwidth with some pure binary stream protocol, maybe even direct marshalling of your internal data structures. Like, say... many other similar protocols in the past. But you lose intercompatibility, convenience, blah blah blah.
Seriously, it's not that heavy weight. And you DO NOT need to build a DOM tree, there are myriad alternatives, such as event-driven processing of XML for one. XML-RPC is very easy and very simple. I can't speak for SOAP, not having used it, but XML-RPC has performed great in my work. It crosses OS'es, crosses languages, crosses platforms, and leverages protocols and knowledge we already have. This is great stuff.
Honestly, CPU power is cheap. In comparison to my hours producing something and diagnosing problems, CPU power is nothing. People are expensive, computers are getting ever cheaper and more powerful. Hell, cut back on bandwidth by using some of that cheap CPU power to gzip the XML stream as it goes across the network. As far as I'm concerned, fretting over the performance hits (which are really close to negligible from what I see) is silly when faced with how easy things can get.
The perfect article to unveil my new .sig!
"And like that
Why are you assuming people want what Linux has to offer over what Windows does? If you truly believe that Linux is a better OS then you are completely unaware of what most people want in an OS. The power user and developer community is very small.
.NET may become cross-platform, but that won't stop people from using Windows. You should really stop bashing MS just for the sake of it. .NET is an amazing platform to develop for and if it does become cross-platform it will revolutionize the way most professional developers write web applications. If .NET doesn't become cross-platform then it will be neglected by all but VB and ASP developers.
The global economy is a great thing until you feel it locally.
Where Microsoft betters Sun is that while Java is the only real language that compiles to the JVM, Microsoft intends IL to be cross-language.
It's already been pointed out that this statement isn't true. Here's why, for those of y'all that don't already know. :)
First off, Java isn't the only programming language (or even the only "real" programming language) which works with JVM. One can point to JPython as an example of a language which works with JVM. (Of course there are many out there who think Java isn't a "real" programming language. I'm not going to argue with them too vigorously, execpt to say that if BASIC on the Apple was a real language, then there's no reason why Python shouldn't be, either.)
The second reason, which is more substantial, is that JVM, while not exactly an open standard, is pretty much available to the public. In particular, the byte codes are well-known. While it's not trivial to port a language to a new instruction set, it's far from impossible. The only reason why there isn't, for example, a JPerl, JSmalltalk or JOberon, is because nobody's done the port.
Microsoft does have a vested interest in making .NET as widely useable as possible. That will probably include porting other languages to .NET, and maybe the unthinkable, porting .NET to other operating systems. Then all they'd have to do is keep .NET proprietary (but sell, for example, a standardized .NDK for people who want to port their favorite languages to .NET) and they could make a killing off the platform. Then it would be Microsoft versus Sun. A very ugly battle indeed.
ObJectBridge (GPL'd Java ODMG) needs volunteers.
Finding God in a Dog
"Not Real" languages: Tcl, Haskell, Lisp, Scheme, BASIC, LOGO, Eiffel, Smalltalk, COBOL, Ada. More at Programming Languages for the Java Virtual Machine
How long did you think blocking a port would sustain security? Ultimately, all traffic coming across the wire will have to be scanned, likely by highly adaptive heuristics that will attempt to discern the intention of the bits coming across. In this sense, SOAP may be useful - at least with a standard for encapsulating RPC over HTTP, we can strengthen this heuristics pre-emtoively, as the standard is being advanced.
Uh no. The standard libs are VERY platform dependent as they wrap around things such as sockets, the windows gui with buttons, windows, scrollbars etc., graphics, sound, threads.. All of that is completely different on each platform. It will NOT fall into place in fact it's the exact opposite.
It would also be a great way to introduce a lot of people to free software. Once they saw the alternatives to Micro$oft bloatware, they would never go back.
They are plowing ahead so quickly that they will cause their own destruction, and Linux will step in to pick up the pieces and allow people to get work done better.
Even Slashdot wants to hide some things
Here is a good definition of .NET the basis of it I found on a messageboard somewhere but I've modified it a bit:
What is .NET? In a nutshell, it is an architecture for allowing multiple languages to create executables which work on any platform (like Java, though with more multi-language emphasis). It is built with internet protocols as a foundation for intercommunication (SOAP is simply a technology to allow objects to be called over HTTP using XML as a serialization protocol).
The framework includes standards for code packaging and distribution as well as security, something made easier by the completely self-describing nature of MSIL (Microsoft's analog to Java bytecodes(stand for Intermediate language)).
Practically on windows this works much the same as activeX components. except instead of being registered.dll's they are code compiled into the IL with and XML wrapper exposing their methods/properties.
Technologies such as ASP+ and WinForms are BUILT on .NET technologies, but are NOT .NET, something which is often confused in the Microsoft documentation.
I don't know much about DOM,COM,SOAP,.NET,C#, but I'm sure if it's Microsoft it's
1) A new, improved & innovative implementation of something someone else created 15 years ago
2) A new, improved & innovative implementation with lots of fresh undebugged code that nobody is responsible for, least of all Microsoft
3) A new, improved & innovative scheme to ensure that each cpu is running licensed code by 'phoning home' to central control, somewhat like a grand global version of the old Netware "there another server with my serial #" alarm (Office is already starting to do this, with a "you MUST electronically register this product, or it will cease to run after 50 times")
4) The usual code to "detect and complain" about foreign, non-Microsoft products via complex, baffling error messages to give the impression that the OTHER code is at fault and how wonderful everying would be if you would only use genuine, interlocking, Msft products.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
If I may make myself look smart after other people have corrected my mistakes on other fora: .NET has, at present count over 15 languages that work with it. To be sure, C#, Java and VB are not that different in principle, but languages like Scheme and ML have been integrated as well. This is no mean feat. Legacy code is catered for with COBOL and others. PERL and Python to round up the internet/scripting programmers.
They are so well integrated that an object in one language can be subclassed in another. Early reports are favorable - it remains to be seen if this amount of multi-language integration is a good thing (tm), but it's definitely an experiment to watch.
BTW, .net is thought to be more portable than win32 so it's not inconcievable that MS are contemplating cross-platform as well as cross-language.
MS is allowing third parties to plug in thier own languages, but comercial windows programming language vendors won't exactly be thrilled by the prospect of thier tool being reduced to a plugin for visual studio.
I'm thinking specifically of my favorite toy, Borland Delphi, here - are there any other major Windows programming tool vendors besides Borland any more? Microsoft's genius is that whilst other people may get good at thier game, they are in a postion to change the rules, and periodically they do. This is one of those. No wonder Boland are running for the safety of Linux.
BTW, one of the languages in .net is component-pascal, an OO descendant of Oberon, Modula and Pascal. I have no idea what's really like, or if it's ready to leave the safety of academia yet, but it's a carrot - from a brief glimse it looks nice. Oberon was used to implement an OS, so it can't be that constrictive.
My Karma: ran over your Dogma
StrawberryFrog
My guess is sooner or later we'll get binary XML encoding, then some "preparsed SOAP", and then finally something similar to CORBA - or M$ would switch to CORBA, which is unlikely because it means, gods forbid, Java compatibility
Opinions are mine only and could change without notice.
Obama 2012: our incompetent asshole is slightly less of an incompetent asshole than the other incompetent asshole !
Doing more with less is a good philosophy for a sustainable human existance. SOAP is the opposite. SOAP does the same shit and uses more resources in the process.
Think for a minute on my point. What if you could reduce the number of computers in use in the world by half, and along with that reduce the amount of energy and human effort needed to design, build, and operate those computers, simply by using more efficient software? Would that still pale next to the awesome value of your personal time?
I can see where this would have it's uses. For the majority of my stuff, XML-RPC is best because I need to format it to XML anyways, so the RPC pretty much just passes through an XSLT based on the accept mime-types of the caller. That being said, there are definately circumstances that streaming would be preferable.
I'm not too sure about the "mounting" metaphor. It seems like an extra bit of complexity if it is necessary (i.e. there's no automount for rare RPCs). I can understand why it would be needed for highly used RPCs, just for the efficiency of it. There may also be connection pooling aspects to consider. But I don't know if I agree with keeping the memory overhead of that many mounts.
Anyways, cool stuff. I'll have to look into it more.
-no broken link
There goes the neighborhood.
Note that ActivePerl isn't entirely free software:
ActivePerl is freely distributable. However, ActiveState puts considerable time, effort and resources into developing and further enhancing ActivePerl. Charges for commercial redistribution of ActivePerl reflect our time in establishing the agreement and, if you have difficulty meeting our marketing requirements, any lost opportunities that we have in our market.
This would seem to be a clear violation of the GPL.
To get rid of the problems of resizing (different graphics resolutions, different fonts and font sizes), layout managers as used in Java's AWT or Swing are a good solution. You specify how items like buttons, text fields etc. are laid out in a visual component and the rendering is done automatically by the manager. You'll need a while to get used to it, but then you never want to go back to pixel-based GUI construction.
Microsoft may be better on public relations there but no on substance. Perl could easily be compiled into Java byte codes (in fact, there is a project around to do just that), just like Python, Smalltalk, Scheme, Basic, Modula, Pascal, and lots of other languages are. While the JVM is most natural as a target for a Java compiler, it is a pretty universal runtime for safe languages, and most of them can be compiled into it without major problems.
And when it comes down to the one area where Microsoft could genuinely differ, compilation of C++, they fail to deliver what they promise: only a restricted subset of C++ is compiled into their intermediate language; you could do the same for compiling a restricted subset of C++ into the JVM.
If you want more information on language for the Java VM, look here. It lists about 130 systems that implement existing languages based on the JVM.
Poor choice of words on my part, sorry for the confusion. See http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht ml for a great list of languages that compile to the JVM.
--Nathan Torkington
Before XML was buzzworded, I had developed a XML-like structure for saving data in a program I was writing (no, I'm not going to apply for a patent on it :-P). The program used plug-ins, and as the final version would have allowed user-created plug-ins, I needed to be able to account for versioning of the plug-ins. But I also needed to recognize what to do when a plug-in couldn't be found, if it didn't critically affect the program.
The XML structure allowed me to do this easily:
the data was in a tree, with keywords that started and ended each 'branch'. Certain keywords were guarenteed to work (ie not part of the plugin part), and data for a plugin identified itself as a string. If that string couldn't be matched with a plugin, the file was 'forwarded' until the end of the plugin data was id'ed. Same thing with versioning in plugins... if data from a newer plugin was not understood by the older one, then the plugin could fastforward into the file to get past that extraneous data.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
Heh! This will make all current firewalls obsolete as not there will be all of your data going thru the 80 port. To me, this means that the firewall is now useless....
DTDs are extinct
coupled with the meaningless complexity of the DOMs
qualify this statement. How is the DOM overly complex? Are you aware of SAX, literally a Simple API for XML??
I don't understand this - SAX and DOM parsers are canned by various vendors already.
Semantics is what is interesting, but after parsing XML, DOM does not provide rich or useful semantics for manipulating hierarchical data.
You should look at the Sun project to bind elements directly to objects. This is presume is your holy grail - binding arbitrarily complex data types to fully maleable objects directly.
Keep in mind that .NET "can" use SOAP for talking between objects. That does not mean that you MUST make this your protocol of choice. You CAN also use other commnications plugins, and send the data in various binary formats over various protocols. And if none of them meet your needs, write your own plugin for it. Read up on the remoting section at MSDN. Don't flame without the facts.
KDE already has a decent browser. You can also use Netscape, if you are so civic minded.
.Net is important. That's why Microsoft is supporting it, and that's why Linux needs to support it.
.Net, that's where the money is.
Just so you know, Microsoft is very concerned about the state of Windows. If they weren't they would be dumping hundreds of millions of dollars into it every year. Even Microsoft realizes though that eventually the OS will do pretty much all that it can on an individual machine. It's not there yet, but soon it will be.
.Net is Microsofts answer to the death of enforced obsolescence. The Linux community needs to get on this particular bandwagon because they are, in essence, in the same boat as Microsoft. Eventually the market for Linux won't grow anymore because people will find that these machines already do everything that they want them to do.
.Net is the strategy that gets OS companies and platforms around this because it allows companies to group computers and information together in ways that nobody has ever done. That's why
Forget about the browser crap, the browser isn't anything really important, and it will get better. Dump more time and efort into interfacing with
Beware the wood elf!!!
You may or may not like .NET, but SOAP web services are very likely to be the architecture for distributed, cross-platform, firewall-friendly development in the near future.
Check out XMethods for live examples.
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
Thanks for the quotage, but, uhhh... Why should I or my company care?
Seriously. Not flaming or trolling. Sounds great and all, but what we have is a description of the means, not the ends. (An all too common situation in technology.)
For example: I chose Gnome over KDE (back during KDE 1.1 or 1.2, so this probably is no longer valid) because Gnome was prettier and had better themes. Who gives a crap about CORBA?
Will any of this make things easier for the end-user?
(Sorry, just read Mythical Man-Month and am starting on the Lunatics are in Charge of the Asylum. I'm beginning to feel that the end users are REALLY being left out)
Jesus was all right but his disciples were thick and ordinary. -John Lennon
... Microsoft ActivePerl shows up in Visual Studio.
--
I'll agree that XML-RPC is inefficient compared to CORBA, but you would be surprised at how useable it is. A long time ago I decided that I wouldn't shun a technology because it was billed as slow until benchmarks show it really is too slow for what I am using it for. I used XML-RPC in enterprise medical systems, and it was never shown to be an important bottleneck.
Plus, you can do so much more with it. The area I found it to excel the greatest in was in security. When you are bulding the XML response, you can be choosy as to what fields you include beased on the user in the session. Contrast this to passing an object by value. It becomes an all or nothing prospect.
Then there is the small bonus that testing your client involves writing a static XML file served to it when it makes the call. It makes automated tests a lot easier. This is a good thing for an XPer, like myself.
Another thing is that is does greatly simplify a design. You don't have to force everything into terms of object models. You just think of it as formatted data, formatted however is logical for the call. This really is a great, and better experienced than explained.
One final note (although there are other good things about XML-RPC), if you are making a web applications, using XML-RPC to distribute the system, gives a homogeny to the model. This is a good thing, because it also makes the overall metaphor for the architecture easier to understand.
It is important to note that XML-RPC is not intrinsic to .NET. The systems I've worked on with it have all been J2EE systems. I just finished a JSP taglib, that, among other things, allows you to select blocks of JSP to include based on the Accept tag. It also does XML/XSLT with xalan. With this, you can use the same application logic for HTML, WML, and XML agents. You can use XMl-RPC to call into .NET (I've done this calling into ASPs before .NET) and .NET can call into J2EE systems. And Sun is a large SOAP supporter.
-no broken link
You obviously haven't tried to get high speed net connectivity 30,000 feet from a phone company central office...
The end user gets applications written faster, that do more, install easier, and have fewer bugs. That's about it - the same benefits the end user gets with every big improvement in developer tools and back-end tech.
-- Jeff Paulsen
I'm not at all convinced the .NET stuff has anything going for it other than whatever marketing millions Microsoft can throw at it.
.NET really is. It's a framework! No, it's a protocol! No, it's a platform! No, it's a floor cleaner! No, it's a dessert topping!
.NET These are universalized "solutions" to problems which cannot be addressed on a universal scale. The component frameworks (CORBA, COM and, it seems, .NET) try to resolve an essentially unresolvable issue, which is that the network world is complex. The inability of any of these frameworks to conclusively address latency, replicability, security and other problems in the realm of distributed network resources is indicated in their rapid and unstable evolution, and eventual diversion to one of two fates: either oblivion (SAA) or some localizable usage that does not correspond to the original dramatic claims made for universality.
.NET will make a lot of money for Microsoft and a whole generation of programmers, consultants and hypesters. But what value does it offer that less tightly coupled, less rigidly doctrinaire approaches don't?
For one thing, nobody can describe what
Frankly, if something like this can't be described so ordinary mortals can understand what it is, maybe it isn't anything to begin with.
I think Microsoft has finally reached the point where IBM was in the mid-1980s wth SAA. Anyone here remember the late unlamented SAA, the framework/protocol/platform/etc. that was Finally Going To Tie All the Pieces Together? "Just say LU 6.2 and run like hell, baybee."
Sure, there are parts of ".NET" that might actually be useful. But the notion of some kind of universal intermediate level language is JUST PLAIN HOOEY.
If someone else like, you know, IBM or Sun, were trying to do this, I could say, "OK, nothing to see here, time to move along."
But this is Microsoft we're talking about, the same company that didn't put real arrays into Visual Basic until release 6. And Microsoft has a crappy, crappy track record for these framework exercises. Let me illustrate with a little example series:
ODBC
DAO
ODBCDirect
RDO
OLE DB
ADO
RDS
Do I make myself clear? This way lies madness.
CORBA and COM are both bad enough. I reach diametrically opposed conclusions to those of Miguel de Icaza concerning CORBA, component frameworks in general, and the overall thrust of
Really, the whole approach is just wrong. These are top-down "solutions" being imposed on already complex and messy landscapes, not even on blank tablets. Even a cursory understanding of self-evolving systems shows that this simply won't work.
No doubt,
--------
Bill Gates Is My Evil Twin.
ActivePerl has all the problems you'd expect from a Microsoft-oriented product, requring forced upgrades of Microsoft software. (Requires NT Service Pack 5, Internet Exploder 5, Microsoft Installer 1.1, etc.) The pure Perl release for Win32 seems to have been killed off, unless you build it from the sources. No current pure Perl binary distribution for Windows is available from the main Perl site or from CPAN.
Now the "ActivePerl" books will start to appear, seducing programmers into using the Windows-only features. It's Microsoft's "engulf and devour" as usual.
If .NET gains strong market share, MS is then in a position to say "Well, for version 6, we're supporting this special, enhanced Perl, called PerlMS."
But like I said, I'll believe it when I see it.
--
--
You sure got a purty mouth...
The above is what turns me off of SOAP, XML-RPC, and the like. The actual implementation is impossibly inefficient. To make a SOAP call, one's software must build an XML document and an HTTP request, and send them together. To handle a SOAP request, the software must not only handle the HTTP protocol, but also build a DOM tree from the request body and act on the nodes of that tree. This is a serious abuse of CPU power, and not the way to build a performant system.
I like systems that are easy for programmers, but I also like those systems to have advanced, efficient, performant implementations. The two goals need not conflict.
Smart companies put their external web server in a "DMZ" (neither fully inside or fully outside) where it is protected from the Internet (except port 80 of course) and has limited or no access to the internal network.
Just because it CAN be done, doesn't mean it should!
With any remote call the following sequence need to occur:
- marshal parameters on client
- Open a socket to server
- Receive / unmarshal params on the server
- Create/invoke object
- Marshal return values and write to socket
- Unmarshal on the client.
Marshalling becomes negligible. Web servers and XML parser are being further optimized by the day. XML can be very efficiently parsed without creating a DOM using SAX checkout http://xml.apache.org. Combine an apache module with Xerces parser and you will have one fast socket listener (web server)/ marshaler(SAX parser) that is very easy to use. Write some test code an you too will be a SOAP believerOn what horribly broken network are your CORBA calls taking 100ms? Across the public internet at peak time, perhaps, but with CORBA calls using OmniORB on a 100mbps local network I get echo responses in about 1ms.
ObPythonPostInPerlThread:
.NET along with Perl, and it can do SOAP as well. Moreover, JPython already makes Python a Java platform language. In other words, it doesn't matter who "wins" the cross-platform war, Python is already there.
Python will also be part of
Why is putting words between angle brackets
.PDF.
revolutionary? Did we want a way to represent
hierarchical information in a way that it
could be easily manipulated and checked for
validity?
Maybe I am wrong, but couldn't you do that with
LISP? Just send your data across in lists and
let a tiny lisp interpreter figure out what to
do with it.
And HTTP? This is our lightning fast protocol
for object communication? Next thing you know
we'll be drawing to our screens with
Oops.
Comment removed based on user account deletion
I recently saw a presentation by Microsoft about .NET and they said something along the lines of:
.NET standard libraries.. However, until they do, any app you wrtite on .NET will not work on another platform since the libraries you depend on are not available for that other platform.
.NET is definitely showing a lot of promise and I think it warrants some attention on all fronts; even by the most die-hard GNU & open source & Linux fans.
"Interestingly, because we [Microsoft] are standardizing the common language runtime with a standards body [ECMA], they will *require* us to do two reference implementations. One of them will obviously be Windows (NT + 9x) but the other will be some 'open source' operating system, such as BSD."
Then he stopped, paused for 10 seconds and said "or Linux..". Paused for another 10 seconds and said "or possibly even both".
I asked if standardizing and thus implementing the common language runtime on BSD/Linux would mean just the runtime or also the standard libraries and to that, he replied that it just meant the common language runtime (the equivalent of having the JVM standardized and ported but not the Java core API). He continued that he was very sure the open source community would quickly write their own version of the
Seems to me Java still has an edge but
Are you honestly telling me we should drop all the progress made with XML and think of some newfangled LISP mechanism??? Ever heard of DSSSL? Know anyone who uses it???? There's your answer.
As for HTTP, sure its showing age, but you show me a protocol that has become as succesful as quickly as HTTP.
No one cares how whiz bang your technology is if no one adopts it - hence CORBA and LISP.
100ms+ is for a full text search or database query that returns 100+ records that requires post processing takes at least that long. I would agree that CORBA is faster than SOAP for an echo, but for calls that take any sort of process time like a LDAP or DB query SOAP would come out in the wash, especially when the HTTP connection is kept open.
People from application server companies such as BEA recommend kepting the objects on the same server as the serverlets.
I'll have to check out OmniORB, thanks. What are the differences between calls that do processing other than echo?
Since many firewalls are setup to not allow CORBA ports so we have two ways of calling out search service, one via CORBA for intranet, and one via SOAP for internet.
People might also read this and get the impression that you can't do SOAP with Java. There's a couple of SOAP implementations for Java, most notably the one from IBM alphaWorks.
.Net looks pretty interesting to me, and Perl support gets me even more interested. But I Don't Do Windows(TM). I'm a Mac OS and Unix guy, currently using the OS X beta quite a bit. Am I going to be able to do serious .Net development? Is there even going to be a .Net implementation for non-MS OSes? All of this .Net stuff is rather irrelevant to me and I imagine to most of the open source community if .Net is going to be just another way to write Windows apps.
--
This space unintentionally left unblank.
What is it? (according to Jim Farley of O'Reilly)
.NET in various forums are reminiscent of the fable of the three blind men attempting to identify an elephant: It's perceived as very different things, depending on your perspective. Some see .NET as Microsoft's next-generation Visual Studio development environment. Some see it as yet another new programming language (C#). Some see it as a new data-exchange and messaging framework, based on XML and SOAP. In reality, .NET wants to be all of these things, and a bit more.
.NET platform:
.NET and J2EE compare?
t ml
Current ruminations about
First, let's get some concrete details. Here's one cut at an itemized list of the technical components making up the
C#, a "new" language for writing classes and components, that integrates elements of C, C++, and Java, and adds additional features, like metadata tags, related to component development.
A "common language runtime", which runs bytecodes in an Internal Language (IL) format. Code and objects written in one language can, ostensibly, be compiled into the IL runtime, once an IL compiler is developed for the language.
A set of base components, accessible from the common language runtime, that provide various functions (networking, containers, etc.).
ASP+, a new version of ASP that supports compilation of ASPs into the common language runtime (and therefore writing ASP scripts using any language with an IL binding).
Win Forms and Web Forms, new UI component frameworks accessible from Visual Studio.
ADO+, a new generation of ADO data access components that use XML and SOAP for data interchange.
How do
quoted from : http://java.sun.com/features/2000/11/dotnetvsms.h