Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

Is .NET dead?

I have just read an article at http://www.freeroller.net/page/ceperez/20030518#the_imminent_demise_of_net

It says something like:

So now it's April 2003 and I'm hearing that .NET is dead--that Microsoft will continue downplaying both the name .NET and the technologies behind it. You can find hints all around that this ".NOT" strategy might be happening right now. The 64-bit versions of Windows Server 2003 (once called Windows .NET Server, by the way) contain absolutely no .NET bits at all: No .NET Framework and no ASP .NET. Exchange Server 2003, the company's next major messaging server, contains no .NET. Office 2003, the premier office productivity suite, contains XML functionality only in the high-cost business versions and contains few native .NET features. In the biggest year ever of new product introductions from Microsoft, few if any of its products promote .NET, its supposed vision for the future.

Is .NET dead, or is Microsoft simply going through yet another round of growing pains as it attempts to figure out just what, exactly, its customers want? Frankly, I'm as confused as you probably are.



I am very concerned about this. Is this true?

I have started learning C# and .NET and made a major time and effort investment...

Will .NET and C# succeed, or fail? What is your opinion?

Thank you!

Gill
Tuesday, June 24, 2003

.NET isn't dead, and anyone who says it is, is either confused or an ass.

The change is that Microsoft is focusing the .NET name on the coding side of things, rather than using it as server branding too.

This is just a marketing change. Nothing to do with whether the .NET environment will continue to grow and be improved.

Mike Gunderloy
Tuesday, June 24, 2003

Exactly as Mike said. Microsoft thought that their customers were getting confused between Windows .NET Server, the .NET enterprise servers, and the .NET framework.

Giampiero
Tuesday, June 24, 2003

It's just ActiveX (TM) all over again.... no need to worry.

Rick Childress (www25.brinkster.com/rchildress)
Tuesday, June 24, 2003

Isn't Microsoft working on a new version of Windows with the shell written entirely using .NET?

SomeBody
Tuesday, June 24, 2003

There is .NET "in" Office 11, there is .NET "in" the next version of SQL Server (Yukon), and there is .NET "in" the next version of Windows (Longhorn, which has a .NET-based shell, among other things). None of these things will be purely .NET, of course, because what a waste of manpower it would be to throw away all that well-tested code just to claim a .NET-based product.

Would you throw away every bit of your code every time a new development environment is available?

The reason that Windows 2003 64-bit didn't ship with .NET is because there isn't a shipping 64-bit .NET at all yet, for any OS.

Would you have delayed shipment of Windows 2003 64-bit for a finalized version of .NET 64-bit?

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, June 24, 2003

The whole .NET marketing campaign was/has been a fiasco. Everyone was going around slapping a ".NET" sticker on their product because it supposedly fitted in with some incredibly vague "vision". And then there was the Passport fiasco (remember the "vision" for "My Services": "My This" and "My That" blah, blah federated services, yawn).

"...what not to do in a high-profile marketing campaign"
http://www.joelonsoftware.com/news/20020819.html

Microsoft Goes Bonkers:
http://www.joelonsoftware.com/articles/fog0000000049.html

So finally they're going back to defining .NET as just the CLR, which is a huge relief. .NET defined as C#, the runtime, the libraries etc, is fantastic and it's definitely NOT going away any time soon!

Duncan Smart
Wednesday, June 25, 2003

I don't think there's any significan amount of .NET in Office 2003. I'd be happy to be wrong, but even the Web Services story there is pretty lame.

Mike Gunderloy
Wednesday, June 25, 2003

"Would you throw away every bit of your code every time a new development environment is available?"

Wasn't the whole premis of Java that you would? *grin*

Just me (Sir to you)
Wednesday, June 25, 2003

Not only would they not throw away all the code they've done, it would be incredibly idiotic to take highly tuned, highly efficient C++ code and replace it with what is basically an interpreted language.

Yes, I understand the nuances of .NET, however .NET is _not_ a performance competitor to C++ in anything but the most ridiculous of contrived situations-- It isn't meant to be. .NET is the evolution of programming for Visual Basic programmers, and I'll just save the insults there (the fact that anyone used Visual Basic when Delphi was available discredits every single one of them. If you're a VB programmer who has never touched Delphi, save your retort because it's quite simply grossly misinformed and ignorant), and for web application development where it was a fully interpreted environment, mishmashed with an incongruous COM+ middleware environment. In those environments .NET is a revolutionary step forward.

Having said all of that, you will not see the new Windows shell in .NET. You will not see SQL Server written in .NET. You will not see a major Office suite written in .NET. What you will see is SQL Server allowing the .NET framework to be used from within stored procedures (instead of, or in addition to, T-SQL), Office scriptable by .NET languages rather than VBScript, etc. Those are the facts folks.

Jimmy Chonga
Friday, June 27, 2003

While C# isn't as fast as C++ it's not that much slower either -- I've measured 50-80% of C++ speed for computational benchmarks.  Whether that difference matters or not depends entirely on your application.  Sure, you wouldn't use C# to do matrix inversion or write a device driver but I don't think that a desktop shell or a word processor written in C# is far-fetched.

Chris Nahr
Saturday, June 28, 2003

"You will not see the new Windows shell in .NET"

Uh, you're too late on this one. The new shell in Longhorn _is_ written in .NET. As for the others, there's no technical reason they couldn't written in .NET (the reason is economic, not technical).

Bytecode languages that are JITted can be just as fast as C++. In fact, with a heavy optimizer and re-optimizer, they can be much faster in some situations. There's no major performance barrier in .NET. I say that as someone who's written C++ code for all but 1 year of my professional career.

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, June 28, 2003

Oh goodie, discredited again, I guess. How about if I'm a VB programmer who used Delphi and then switched back to VB? How about if VB and Delphi are just two among dozens of languages I've used? Oh, never mind; I've written VB so I'm one of those discredited VB programmers.

Mike Gunderloy
Saturday, June 28, 2003

"In fact, with a heavy optimizer and re-optimizer, they can be much faster in some situations."

...but only in theory as far as .NET is concerned. Both the C# and the JIT compiler do little static optimization, and there's no dynamic optimization at all.  There's a lot to do for Microsoft in this area.

Obligatory nitpick: You could re-implement any VM in C++, ergo any VM language is never going to be "faster" than C++ in an absolute sense.  Conversely, you can never get rid of the speedbumps set up by the VM to produce code that is as fast as the best possible C++ code. Your statement only makes sense when we're looking at programs of comparable length, which I realize is your intention but I just love nitpicking. ;-)

Chris Nahr
Saturday, June 28, 2003

"Uh, you're too late on this one. The new shell in Longhorn _is_ written in .NET. As for the others, there's no technical reason they couldn't written in .NET (the reason is economic, not technical)."

Really...could you point out some credible sources of this piece of information? Oh, wait, this is similar to how the "Next version of Office will be written in .NET!": It's fanboy rhetoric to justify their decisions. .NET is a tremendous environment, and for web development it is tremendous.

"Bytecode languages that are JITted can be just as fast as C++. In fact, with a heavy optimizer and re-optimizer, they can be much faster in some situations."

This just takes the cake as far as blatant ignorance goes...you couldn't stop with "can be as fast as" (which is still hard to believe, but is possible in some scenarios), but you had to go for the gusto and proclaim that it could be "much faster". Do you realize how ridiculous that sounds? C++ compilers produce optimized code specifically geared for the hardware they're targetting. JIT compilation produces "best guess" `compilations' that at absolute best still introduce one more layer between the application and the hardware. How in the world will the, err, "re-optimizers" produce better code than machine code? Must be one of those magic things, huh? Don't worry, though, Java fanatics have been claiming the same sort of nonsense for years, though strangely the Java revolution hasn't happened yet...

Jimmy Chonga
Saturday, June 28, 2003

http://www.winsupersite.com/images/reviews/4015_151.png

Suck it!
Saturday, June 28, 2003

Boy, you got me good there. I mean, there's no possible way that explorer.exe is instantiating the framework for shell extensions (which is a WORLD different from the shell being managed code), now is it? No, that would be just crazy...

Hilariously every single sputtering "But .NET revolutionizes everything!" claim points to that same crash picture... You'd think someone would have some code analysis/reverse engineering skills beyond a messagebox. Given that I'm not big in the whole pirate world, I can't verify this myself.

Jimmy Chonga
Saturday, June 28, 2003

"Really...could you point out some credible sources of this piece of information?"

Attend the PDC, or wait for the post-PDC articles to talk about what they show of Longhorn. Of course, you probably won't believe that, either, because those people will also be fanboys. You probably wouldn't even believe it if you were running it. *shrug* I'm not interested in feeding your puerile anger.

Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, June 29, 2003

"...but only in theory as far as .NET is concerned. Both the C# and the JIT compiler do little static optimization, and there's no dynamic optimization at all.  There's a lot to do for Microsoft in this area."

Agreed. The JIT in .NET is nowhere near where it could be, and it's already producing some quite fast code.

You can see some of where these things can go by looking at the Hotspot VM for Java, which can dynamically re-optimize code as well as do so nearly impossible things for C++ compilers: unrolling short loops is one example that can provide a huge performance boost (branching is an expensive operation for CPUs, even when the branch is properly predicted).

Something else that the .NET JIT doesn't yet do, but likely will in the future: exact targetting of the hardware. Take precise advantage of the CPU and any extension instructions. C++ compilers here, again, fall down, because you must compile for the lowest common denominator (except when the end user compiles their own code, which is basically unheard of in the Windows world).

Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, June 29, 2003

Carlos Perez is a no good Java loving hump.

Guy Incognito
Tuesday, July 01, 2003

Just kinda testing these boards.  I hope that is ok.

Christopher Holmes
Friday, August 01, 2003

*  Recent Topics

*  Fog Creek Home