What is .NET?
CyberBry writes "There's a great technical overview of Microsoft .NET over at arstechnica: "In a remarkable feat of journalistic sleight-of-hand, thousands of column inches in many "reputable" on-line publications have talked at length about .NET whilst remaining largely ignorant of its nature, purpose, and implementation. Ask what .NET is, and you'll receive a wide range of answers, few of them accurate, all of them conflicting. Confusion amongst the press is rampant. The more common claims made of .NET are that it's a Java rip-off, or that it's subscription software. The truth is somewhat different.""
I haven't seen this mentioned here yet, but they actually released the dev stuff for .NET. Article here
Bwahahahahaha...
"I will take the Ring," he said, "though I do not know the way."
Unfortunately, no one can be told what the .NET is. You have to see it for yourself.
There are some good .NET development books coming out now. Even O'Reilly has had one out for a while (which I have), so the publishing companies seem to be eager to sell .NET.
.NET framwork development tools, and it seemed much faster (probably because my hand-written code was much smaller).
.NET runtime and classes for FreeBSD. I have talked with the lead engineer of this project over e-mail, and he said that it's due to be out in late Spring. I asked him about the Windows Forms stuff, and he said it will be based on Tk (could someone explain the implications of this?). He also said that there are going to be very few UNIX-specific classes, but they hope people will develop those on their own.
Right now I am downloading the seven CD Visual Studio.NET Enterprise final version (yep, already warezed), a $2500 program. It even has a version of Visio bundled for doing application modeling, and that somehow automatically starts producing code, from what I understand. This is going to be interesting to try.
I have had the VS.NET Beta 2 for a few months, and it's generally easy to use, but very slow. I mean, a general "Hello World" application takes several seconds to compile, and also at least 3 seconds to execute! I have done the same thing using the raw
Microsoft is developing a version of the
When your friends ask, just tell them "It's a language-neutral Java knock-off..."
Why do people try to make it more complicated? Ok,
Others like to confuse the application that can be written by
The Platform != It's Applications
It's Simple: It's a Java rip off!
"Communism is like having one [local] phone company " - Lenny Bruce
You obviously didn't read the article.
.NET programs.
Microsoft themselves is developing a runtime for FreeBSD. When I say 'runtime' here I mean the CLR and the *BASIC* class libraries. You see, that is the standard that Microsoft has released to the EMCA as a standard, soon to be certified by ISO. It is completely open, non-patented, etc. Anyone can develop a compatible implementation.
However, a few key components are Windows-only: ADO.NET (universal data access) and WindowsForms (the GUI toolkit.) That is where Mono comes in with the development of compatible class libraries on Linux. Please understand: **the interfaces are the same as the Microsoft interfaces**, even though the implementation details are different.
Microsoft is fully aware of the Mono project and is taking no efforts to stop them. It doesn't really matter if they wanted to. The CLS (Common Language Specification) is part of the OPEN STANDARD. This is the definition of how classes and datatypes interact among languages and the IL; unless Microsoft managed to get a copyright on all the method names in WindowsForms, they can't stop me from creating a compatible implementation because I am simply using the CLS to write my classes that run on the CLR to provide objects for use by
(Short Version: go back and actually read the article, then try posting again.)
Natural != (nontoxic || beneficial)
>That being said, it does seem like MS is trying to wean themselves out of a strictly x86 world
.NET and write a CLR for it.
Has anyone thought that perhaps Intel (being somewhat friendly with Microsoft) has been pushing this initiative so they can finally put x86 instructions to rest? If Intel has a new processor that doesn't allow x86 instructions (because backward compability would slow it down), all they'd need is Microsoft to force everyone to compile with
Of course, this may not necesarilly be a bad thing. Imagine the speed improvements any processor would have if it didn't require backward compability. The downside is that it'd require a fully-compability CLR.
Sam
IMHO, that is probably pretty darn accurate. Nobody knows exactly how just yet. Yeah, it sounds like I am paranoid, I have good reason to be.
Microsoft^H^H^H^Hpoly
My beliefs do not require that you agree with them.
Stability before performance, every time.
Or he'd rather be writing, "The JIT produces fast code, but sometimes crashes."? Or, ".NET is vaporware, still three to five years on the horizon."?
The reviewer should recognize and applaud the focus of the developers. Because you know they were sitting around saying, "Wouldn't it be nice if we did this fancy optimization...". Instead, they put first things first.
"Premature optimization is the root of all evil," D.E. Knuth. Learn it. Live it.
Just coincidental that Windows XP drops default Java support.
First, Java works fine in XP -- you just have to (automatically) download the VM or get it from Sun.
Secondly, the real advantage of .NET is that you can write in whatever language you want to and use components from other languages in your .NET programs. Those are hardly minor advances. Java has had a six-year head start, not to mention a vast amount of hype, and if it's the better technology, it'll hang in there. If developers like the .NET stuff better, they'll use that. In all likelihood, there will be a lot of different competing languages which will be good at different things. Nothing wrong with that, IMHO.
You can't believe it? It's a natural part of their onslaught on the "viral" GPL. And it makes a Mac version just moments away.
Yours Sincerely, Michael.
> Anyone who wants to develop for .NET needs to shell out at least $1,079 for Visual Studio
.Net Framework Software Development Kit for free (*connection charges apply) at this link
.NET Framework Software Development Kit (SDK) includes the .NET Framework, as well as everything you need to write, build, test, and deploy .NET Framework applications--documentation, samples, and command-line tools and compilers.
Or... you can go out to MSDN and download the
From the description:
The Microsoft®
I'm excited about
And really, Microsoft.com is the only one that could manage to make this a reality. As much as I hate the company, I can't help but feel grateful that I'll finally be able to write apps in a nice high-level type safe garbage collected language and have that be the most well-supported method. (And if others start using high-level languages, maybe my computer will not crash so much, or have so many buffer overflow sercurity holes.)
(As an aside... I fucking hate when people (like the author of this otherwise good article) use the word 'whilst'. Just say 'while'. It's not like we live in Medieval Britain.)
Well, you can use any language that happens to look very similar to C#, and which has a CLR compiler. Take a look at some of the languages that have been ported to .NET, and you'll see what I mean. They are modified to look like C# with different syntaxes. Example: Smalltalk# (or whatever it's called). Forget about dynamic typing anymore. Basically, you can use any language so long as it's mauled to look like C# (static typing, etc.) This multiple-language thing is not a big win, really.
Well.
The GAC is reference-counted -- if you no longer have any applications using an assembly in the GAC, it'll get removed (there are some provisos, but that's more or less how it works).
And the GAC does have shared libraries -- it just provides a mechanism for having different versions of those shared libraries. If a bunch of applications all use the same version of the same assembly, then they'll use the same file. So there's still a benefit over static libraries. It just also fixes the problems that have ocurred with dynamic libraries. When they *can* be shared, they will be, but unlike Windows' previous DLL implementations, it doesn't _require_ them to share the same version, even if they're not compatible.
So basically it's like the Kaffe version of Java. Kaffe supports the JDK 1.1 without AWT (soon with some 1.2 support). And guess what, not too many people use it. Maybe a couple, but most people are using a fully functional implementation with Swing/AWT and 1.3 libraries.
,tweak your pages and balh blah blah. Java may not be perfect, but all the 'SUN certified JVMs' work. If you run your code on the Sun JVM, it will work on the IBM one. If not then you can call up IBM and report a bug. With a 'standard' language/runtime, there is no controlling entity to guarentee compatability.
I think that the whole C# is a standard argument is BS. Look at JavaScript, it's a standard, has been for a number of years now. Why is it then, that I can write 'standard JavaScript' and IE will interpret it one way, while Mozilla, Netscape and Opera interpret it a slightly different way ( maybe it works, maybe not ). Why are web programmers still writing browser detection code into web pages? I'll tell you why, because it doesn't matter if someone makes a standard if nobody follows it. Not one browser follows the standard perfectly. Mozilla (IMO) comes the closest, but even that is not perfect. You still have to go back
They are developing a FreeBSD port of that incomplete and nearly useless portion that they are submitting as a standard. Real .NET apps will in fact be confined to the Windows platform, unless Mono is much more successful than I suspect it can be.
But it's not "any language". It's a collection of languages that are nearly isomorphic with C#. In fact, there are currently many more languages, and more diverse languages, targetted to the JVM than there are to the .NET VM. See, for example, this list, which contains about 160.
This reminds me of something...
One of the early premises behind the Guile project was that all languages are essentially Scheme, modulo their different syntaxes. Guile was thus to become a Scheme interpreter with various syntax front ends on it to translate from Perl, Tcl, etc. Essentially achieving language independence in a unified runtime. The Guile team has largely abandoned these efforts, however, and concentrated on making Guile a practical workhorse Scheme for standalone use or embedded in a larger program.
I'm a big Scheme and Guile fan, and a part of me is disappointed... Scheme, being self-extensible, would make for a much more robust base upon which to construct a language-neutral runtime than the C# and VB-oriented CLR.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
For what its worth, Javascript has been effectively standardized for, oh, I'd say the last five years, even before the ECMA standard. (Note the word 'effectively', it's a critical one to my point.)
.NET?" What use, indeed? The greatest challenge facing those who would implement the CLR is not in writing the class libraries, it's matching them bug-for-bug. (One of the reasons Mozilla and IE still don't work identically is that Mozilla was forced to abandon its plans for bug-for-bug compatibility with IE, due to the feature's excessively high "pie in the sky" factor.)
What you're complaining about (justifiably) is the DOM, or Document Object Model. The DOM was standardized much more recently, and unfortunately contains a few holes large enough to drive a truck through, necessitating the need for non-standard extensions in practice. (One of the most-commonly-used of these is the "innerHTML" attributes, which is *not defined* in the standard, despite the fact that it is wonderfully useful. Mozilla actually explicitly added it many milestones ago because people were screaming for it. The 'standardized' way of doing that was upwards of 10-20 lines of rather difficult-to-read code, involving walking the tree and regenerating the HTML, then nearly-manually parsing the given HTML back into a tree, then swapping the newly-parsed Node tree into the document! Is anyone surprised nobody, even those who understood it, wanted to do that?)
The DOMs are inconsistent, partially because they're hard to get write. But Javascript itself is nearly unchanged since Netscape 3.0. That's not a typo. Yes, a few nice things have been added (for instance, I think an exception mechanism has been added since then), but effectively all of the language anyone uses on a web page script was there in Netscape 3.0. (How many people here have created their own objects in Javascript, or fiddled with the prototypes? IIRC, this feature was in 3.0, and it's still too-advanced to be necessary in most web scripts. Short scripts don't need a lot.)
This works out on topic nicely... because you're very likely looking at the future of Mono. "What use is Mono when the same code doesn't *quite* run on