Slashdot Mirror
Nothing of .Net in Longhorn?
turnitover writes "We've been waiting for Longhorn before we really get on the .Net train, but should we bother at all? According to Mary Jo Foley at Microsoft Watch, Longhorn won't be based on .Net at all. Foley, who's usually right on target, calls this MS's 'dirty little secret'." From the article: "We're guessing that Microsoft will maintain that nothing has changed-that no one ever promised that the .Net Framework 2.0 would be the foundation for Longhorn. But developer types we've been chatting with seem to find this update a newsworthy revelation."
Do you actively develop for .NET?
I do and have been for 2 years now.
Been playing with 2.0 since beta2 was released, and am now 1 month into active development using 2.0.
I'm sorry, but you are _completely_ full of shit. So much so that it'd just be feeding a troll to try to counter all of your points.
No Comment.
.Net is the biggest load of crap to hit computing ever since Java. While java was perfect for applets and net security, now it's bastardized into an everyday programming platform. Java is slow, .Net is slow, unless they are preloaded-precompiled and provided with a ton of resources. Remember the speed, size and efficiency of C? Java and .Net do not remove enough complexity from C to justify the speed decrease, Basic used to do that a lot better. The only good thing about Java is being a good teaching tool of abstract concepts. .Net is that now you can better monitor and yank the rug out from under competing apps, because the bytecode instructions are more detailed now. Back in the days if you wanted to throttle your competitor's app running on your OS, you couldn't simply slow down CPU instructions like MOV, ADD, because they are too generic. Now you can have a few targeted instructions that get slowed down unless the app can properly "authenticate" itself with the OS, all in the name of security. Now sysadmins can monitor "managed code" based on what instructions it tries to execute, even without having commented sourcecode, and forbid/allow it to run, all in the name of security. Come on, having original commented sourcecode to review and compile beats the pants off any other way of "trusting" Something is either obfuscated or it ain't, whether it's sourcecode, managed code, or assembler. If it's not obfuscated, then you can't really say it's not open source. Yes, there is an upside to this too, when an app crashes and tells you the contents of the CPU registers, the bytcode stuff is at least more descriptive. Trying to make sense out of compiler generated assembler and why it's crashing, that's a major undertaking. But still, if you got the original human written, commented, human readable sourcecode, nothing even comes close to that. Fixing the bytecode portion without fixing the sourcecode that generated that bytecode shouldn't be the way. So what's the point of having bytecode in the first place? C/C++ is portable enough, as mozilla and other projects show, and instead of compiling on the fly each time, compile once for each platform and distribute the binaries. Compiling on the fly is for small applets of 200 KB or so, not 30 MB apps.
The other thing with Java and