I'm not confused. A JIT does a once-off [1] conversion from bytecode to native code. An interpreter within a VM does it every time. The VM has in effect a "software processor", the JIT does not.
[1]: It may convert more than once, for instance if it discards the converted form due to memory constraints, or to create a better optimized form, but it still generally converts fewer times than it calls each piece of code.
The CLR supports whatever you want it to do. The CLR supports MI inheritance if your compiler does. It supports prototype-based OO. It supports runtime code-generation. What doesn't support such things is the CTS, which is (necessarily) a subset of functionality common to numerous languages. A compiler does not have to constrain itself to the CTS, and some (for instance, the C++ and JScript compilers) do no such thing.
Re:I honestly can't figure out
on
What is .NET?
·
· Score: 2, Insightful
Standard ECMAScript manipulating the DOM in standard ways works pretty much identically (except for implementation bugs) all over the place. This requires version 5.5 of MS's engine or Mozilla (maybe others, don't know, don't care), but it works well.
Browser detection code exists primarily because of people using version 4.x browsers
IMO, this is a demonstration of the standard working. The biggest problem is that it requires people to stop using the fatally flawed implementations (IE 4.x, NS 4.x). If they could be *forced* to upgrade, no-one would have to do that kind of crap any more.
Re:Classes and APIs more important than language
on
What is .NET?
·
· Score: 2, Interesting
Except it doesn't.
The restrictions are imposed *by the CTS*.
If you want your class to be exposed to other classes it must conform to the CTS's rules.
If you merely want to make use of.NET's features -- compiling to IL, a nice class library, and so on -- you can use MI and case-sensitive identifiers and all that lovely stuff. Provided that your compiler supports it, of course. The C++ compiler does, and it works just like it does in native code. The CLR has no problem with multiple inheritance (it doesn't really *know* about it, but it doesn't really know a great deal about single inheritance, either, so that doesn't matter at all).
If you want to use those features but also expose them to other languages (thus, you need to conform to the CTS), you can wrap your non-compliant code in CTS-compliant code.
What you see as a major problem is seen as others by a major benefit. Some languages are more suited to some kinds of development than others..NET levels the playing-field somewhat, by ensuring that they have equal access to a fairly rich class library -- it means that the *only* distinguishing feature is the language, rather than the choice one used to have to make, of "which language and library do I want to use?".
Re:Actually excited about .NET
on
What is .NET?
·
· Score: 1
"whilst" is perfectly normal in modern english the UK. Which is where I am from.
Whilst it might not be common in the US, I couldn't give a tinker's cuss, as I'm not a septic, and don't pretend to speak like one.
Re:dll hell
on
What is .NET?
·
· Score: 4, Informative
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.
Re:My Biggest Problems with .Net
on
What is .NET?
·
· Score: 1
VB.NET has pissed off a lot of VB programmers. I'm not sure why, they should be used to it by now. But it has.
The VS.NET interface is great. I finally can use the same interface for work (VB, C#) as I can for play (C++, C#). If you want the help window in a separate window, BTW, you can do that just fine and dandy. Tools... Options... Environment... Help. "External Help".
Re:Not explicitly OS independant...
on
What is .NET?
·
· Score: 2, Informative
FWIW, MS's JVM was 100% conformant, and Visual J++ produced 100% conformant binaries; the problem was that it supported some extra bits and pieces (P/Invoke, most notably, which essentially exists in.NET as the wonderful DllImport attribute).
OS independence is brought about by compiling to bytecode (which frees you from hardware constraints) and sticking to the core class library (which frees you from platform constraints), or using classes common to multiple implementations (for instance, WinForms, which are available on both Mono and.NET, and maybe even the shared-source FreeBSD implementation).
Re:Article is inaccurate.
on
What is .NET?
·
· Score: 5, Informative
Read the first part of the article more closely. I acknowledge that there's more than just the Framework. But I haven't covered them in this article, as it's long enough already. This is what I meant when I said:
.NET is also the collective name given to various bits of software built upon the.NET platform. These will be both products (Visual Studio.NET and Windows.NET Server, for instance) and services (like Passport, HailStorm, and so on).
A follow-up will talk about such things as, VS.NET, Passport, Hailstorm, and so on.
I feel that there are broadly two parts -- the framework itself (your first bullet point), and things that use it or manipulate it (your second, third, fourth, and fifth bullet points).
I realize I glossed over them, but I will talk about them at a later date.
Re:Is this article acurate?
on
What is .NET?
·
· Score: 1
Perhaps you need to re-read the article.
It talks about language independence, amongst other things.
Re:If it ain't new...it ain't news...
on
What is .NET?
·
· Score: 2, Informative
OK.
That's interesting to know.
Given that, I, ah, wrote the article, and can guarantee that it wasn't finished, let alone posted, "over two weeks" ago.
Slashdot Mirror
I'm not confused. A JIT does a once-off [1] conversion from bytecode to native code. An interpreter within a VM does it every time. The VM has in effect a "software processor", the JIT does not.
[1]: It may convert more than once, for instance if it discards the converted form due to memory constraints, or to create a better optimized form, but it still generally converts fewer times than it calls each piece of code.
The CLR supports whatever you want it to do. The CLR supports MI inheritance if your compiler does. It supports prototype-based OO. It supports runtime code-generation. What doesn't support such things is the CTS, which is (necessarily) a subset of functionality common to numerous languages. A compiler does not have to constrain itself to the CTS, and some (for instance, the C++ and JScript compilers) do no such thing.
Standard ECMAScript manipulating the DOM in standard ways works pretty much identically (except for implementation bugs) all over the place. This requires version 5.5 of MS's engine or Mozilla (maybe others, don't know, don't care), but it works well.
Browser detection code exists primarily because of people using version 4.x browsers
IMO, this is a demonstration of the standard working. The biggest problem is that it requires people to stop using the fatally flawed implementations (IE 4.x, NS 4.x). If they could be *forced* to upgrade, no-one would have to do that kind of crap any more.
Except it doesn't.
The restrictions are imposed *by the CTS*.
If you want your class to be exposed to other classes it must conform to the CTS's rules.
If you merely want to make use of .NET's features -- compiling to IL, a nice class library, and so on -- you can use MI and case-sensitive identifiers and all that lovely stuff. Provided that your compiler supports it, of course. The C++ compiler does, and it works just like it does in native code. The CLR has no problem with multiple inheritance (it doesn't really *know* about it, but it doesn't really know a great deal about single inheritance, either, so that doesn't matter at all).
If you want to use those features but also expose them to other languages (thus, you need to conform to the CTS), you can wrap your non-compliant code in CTS-compliant code.
What you see as a major problem is seen as others by a major benefit. Some languages are more suited to some kinds of development than others. .NET levels the playing-field somewhat, by ensuring that they have equal access to a fairly rich class library -- it means that the *only* distinguishing feature is the language, rather than the choice one used to have to make, of "which language and library do I want to use?".
"whilst" is perfectly normal in modern english the UK. Which is where I am from.
Whilst it might not be common in the US, I couldn't give a tinker's cuss, as I'm not a septic, and don't pretend to speak like one.
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.
VB.NET has pissed off a lot of VB programmers. I'm not sure why, they should be used to it by now. But it has.
The VS.NET interface is great. I finally can use the same interface for work (VB, C#) as I can for play (C++, C#). If you want the help window in a separate window, BTW, you can do that just fine and dandy. Tools... Options... Environment... Help. "External Help".
FWIW, MS's JVM was 100% conformant, and Visual J++ produced 100% conformant binaries; the problem was that it supported some extra bits and pieces (P/Invoke, most notably, which essentially exists in .NET as the wonderful DllImport attribute).
OS independence is brought about by compiling to bytecode (which frees you from hardware constraints) and sticking to the core class library (which frees you from platform constraints), or using classes common to multiple implementations (for instance, WinForms, which are available on both Mono and .NET, and maybe even the shared-source FreeBSD implementation).
Perhaps you need to re-read the article. It talks about language independence, amongst other things.
OK. That's interesting to know. Given that, I, ah, wrote the article, and can guarantee that it wasn't finished, let alone posted, "over two weeks" ago.