Q: Why do you say Microsoft's C# is Java without the reliability, productivity or security?
A: You find stuff in it that has essentially loopholes for everything. They had this problem in their design rules that they had to support C and C++, which means you have to have a memory model where you can access everything at all times. It's the existence of those loopholes that is the source of security, reliability and productivity problems for developers. So on the one hand, they copied Java, and on the other hand, they added gratuitous things and other things that are outright stupid. That's amusing.
Article Link: http://news.com.com/...082-817522.html
Very interesting read. I actually like C#.
C# isn't Java
Started by
Guest_NeedHelp_*
, May 16 2006 11:03 PM
3 replies to this topic
#1
Guest_NeedHelp_*
Posted 16 May 2006 - 11:03 PM
Guest_NeedHelp_*
|
|
|
#2
Posted 20 May 2006 - 11:42 AM
Nice Post. C# does seem a lot like java. I've never liked Java so much only because you have to have the Java engine installed in order to run the applications you make.
#3
Posted 21 May 2006 - 09:29 PM
Well they are similar, but of course its not Java.
Java coders will know its totally different. C# is its own language.
Both languages borrow strongly from C++ hence their comparison to each other.
Java coders will know its totally different. C# is its own language.
Both languages borrow strongly from C++ hence their comparison to each other.
#4
Posted 22 May 2006 - 10:14 AM
Well, this was published in 2002, but I think we can agree that he was mistaken on the uptake of C#, and probably a little too "dismissive" about it.
As for the "[CLR] had to support C and C++", I think he's misinformed. Except for managed C++, there's no C or C++ code running on the CLR.
Maybe he's referring to PInvoke or being able to run unsafe code. But, PInvoke is one of the things that makes .NET useful - not only do you have the BCL, but you also have the full Win32 API. As for unsafe code, the CLR has ways of controlling that - none of which have had huge exploits discvovered, AFAIK.
So, assuming he means you can use managed C++, P/Invoke, and unsafe code (pointers) - how do they affect productivity? Sometimes, it's a hell of a lot faster to use pointers or P/Invoke than look for a managed solution. And some people actually like coding in C++. As for reliability and security, I'm not aware of any serious problems with either as far as C# or the CLR is concerned. I really doubt he was either, back in 2002. I'd chalk it up to Sun FUD.
As for the "[CLR] had to support C and C++", I think he's misinformed. Except for managed C++, there's no C or C++ code running on the CLR.
Maybe he's referring to PInvoke or being able to run unsafe code. But, PInvoke is one of the things that makes .NET useful - not only do you have the BCL, but you also have the full Win32 API. As for unsafe code, the CLR has ways of controlling that - none of which have had huge exploits discvovered, AFAIK.
So, assuming he means you can use managed C++, P/Invoke, and unsafe code (pointers) - how do they affect productivity? Sometimes, it's a hell of a lot faster to use pointers or P/Invoke than look for a managed solution. And some people actually like coding in C++. As for reliability and security, I'm not aware of any serious problems with either as far as C# or the CLR is concerned. I really doubt he was either, back in 2002. I'd chalk it up to Sun FUD.


Sign In
Create Account

Back to top










