Why is .NET so popular? (Serious Question)
-
I love writing assembly, just can't find an excuse too. I really do believe assembly should be learned by all CS students very early on. It sheds a whole lot of light on what's really going on with the computer and makes you very jaded about claims of new technology (since you know that it's all just assembly in the end.)
I only did any assembly at Uni, but really enjoyed doing it. No-one else in the class (it was a crap course at a crap university) could get to grips with it at all, to the extent that the lecturer gave everyone his solution. He marked mine wrong simply because it was different to his, then I pointed out that not only did my solution work, it was more efficient than his was.
Every man can tell how many goats or sheep he possesses, but not how many friends.
-
I have some limited experience with C# and VS 2008 and I don't understand why the .Net framework is so popular. It is a meta environment running on top of the operating system just like Java and the non-Windows implementations do not have all of the capabilities of the Windows version so it's not truly cross platform. I don't see why -- other than Microsoft's semi-forcing the issue -- someone would choose to use this. Shouldn't Win32/64 code run just as well, if not better, since there is no runtime between the code and the system? I can't help thinking of Java or even UCSD P-System Pascal when I look at this. I realize .Net has a large amount of built-in functionality but the same thing could be implemented in native code as well. What am I not seeing here?
b_dunphy wrote:
meta environment running on top of a GUI on top of the operating system
I can only speak for myself. Because no one is hiring for DEC-C on OpenVMS anymore. :sigh: Because it lets me write Windows (WinForms) apps -- I completely failed to understand OWL and VB2. Because of ADO.net. (Does SQL Server 2008 support esql?) Because C# is a great language. It's only major fault is its dependency on .net X| . Oh, and because of garbage collection and Reflection. I should probably try writing a Windows-Service-hosted WCF service in C. :cool:
-
b_dunphy wrote:
Shouldn't Win32/64 code run just as well, if not better, since there is no runtime between the code and the system? I
Shows a bit of ignorance on your part. Unlike java or UCSD Pascal, .Net JITs to native code, optimized for the particular OS and hardware it is running on, so it can in many cases actually be faster than pre-compiled Win32/64 code, since it can take advantage of OS specific and processor specific optimizations. Java and UCSD Pascal compile to p-code which must be then executed by an interpreter.
b_dunphy wrote:
realize .Net has a large amount of built-in functionality but the same thing could be implemented in native code as well. What am I not seeing here?
That most people would rather not have to implement all that functionality themselves? that a large, robust framework really speeds application development be not forcing developers to re-invent the wheel every time?
Rob Graham wrote:
.Net JITs to native code, optimized for the particular OS and hardware it is running on, so it can in many cases actually be faster than pre-compiled Win32/64 code, since it can take advantage of OS specific and processor specific optimizations.
Baloney. The JIT compiler is still saddled with the constructs of .NET. I've done extensive benchmarking and have found that purely algorithmic code is 4x slower on average with .NET than native C++. When using the framework, there are portions of .NET that are faster, though once you figure out what they're doing, you can get almost always get better performance with C/C++. (A common trap is file i/o. .NET can make this look so fast until you realize that they are often caching the entire file!)
Rob Graham wrote:
not forcing developers to re-invent the wheel every time?
Laziness. There are plenty of libraries out there that offer fantastic functionality for C++. They are just as easy to learn as .NET and sometimes easier. The difference is that .NET puts all this massive amount of code (35MB of mostly native C++) in one place with one runtime. If you gave yourself a budget of even half that, you can easily build a list of fantastic C++ libraries that aren't very expensive. I will openly and totally conceded that dealing with COM is much easier in .NET. One reason is that the objects are actually documented (using undocumented objects in .NET is as big a pain as in C++ and Microsoft still has way too many undocumented "must use" COM objects.)
-
b_dunphy wrote:
Shouldn't Win32/64 code run just as well, if not better, since there is no runtime between the code and the system? I
Shows a bit of ignorance on your part. Unlike java or UCSD Pascal, .Net JITs to native code, optimized for the particular OS and hardware it is running on, so it can in many cases actually be faster than pre-compiled Win32/64 code, since it can take advantage of OS specific and processor specific optimizations. Java and UCSD Pascal compile to p-code which must be then executed by an interpreter.
b_dunphy wrote:
realize .Net has a large amount of built-in functionality but the same thing could be implemented in native code as well. What am I not seeing here?
That most people would rather not have to implement all that functionality themselves? that a large, robust framework really speeds application development be not forcing developers to re-invent the wheel every time?
Rob Graham wrote:
Unlike java
Java had JIT compilation for a long time.
-
I have some limited experience with C# and VS 2008 and I don't understand why the .Net framework is so popular. It is a meta environment running on top of the operating system just like Java and the non-Windows implementations do not have all of the capabilities of the Windows version so it's not truly cross platform. I don't see why -- other than Microsoft's semi-forcing the issue -- someone would choose to use this. Shouldn't Win32/64 code run just as well, if not better, since there is no runtime between the code and the system? I can't help thinking of Java or even UCSD P-System Pascal when I look at this. I realize .Net has a large amount of built-in functionality but the same thing could be implemented in native code as well. What am I not seeing here?
This is the only bus has destination and moving to correct direction, also the bus driver is Microsoft. so do you wanna get in or left behind? because you cannot rely on other buses they might broke down in the middle of no where, or taken over by someone as hostage... :rolleyes: This is as serious as I can get right now ;P
-
Why not assembly while you're at it? :laugh:
Wout
That's not really a helpful response. It is valid to ask "at what level of abstraction should I be working?" The answer to this question is not, as many people seem to assume, that we ought to work at the highest level of abstraction possible. Abstraction is not necessarily an absolute good. At the lowest level of abstraction, we have machine language (NOT assembly language, as anyone who's ever hand-assembled code can tell you), followed by assembly language, and then by languages like C and Pascal, and then by newfangled technologies like .NET and Java, and finally by "code free" quasi-development technologies. As one moves among these levels of abstraction, there are tradeoffs. Moving up in abstraction reduces the speed of the object application and (more subtly, but importantly) the speed of the development tools. It also reduces the depth with which the developer can claim to understand his or her code; again, this is a subtle and oft-overlooked drawback to abstraction, but it's real. At each level, the returns to greater abstraction diminish. Assembly is much easier than machine language, which doesn't correspond to even the most basic human expectations of what a "language" should be. C is significantly easier than assembly, although the difference is less dramatic. C++ and C# offer benefits compared to C, but, again, these are not as dramatic as the previous steps up the abstraction ladder. I would submit that C#, Java, etc. may reside at a level of abstraction that is too high for many projects. Garbage collection is, for me, an example of why this is so. Look at what good C++ programmers do with automatic smart pointer variables, and then ask yourself whether an non-deterministic, out-of-thread system is really necessary to reclaim heap objects. Such "magic" definitely abstracts away some troublesome details... but are we sure (given the neat alternatives) that this is a good thing...? I can imagine plausible arguments both ways. Finally, let me assure you that for someone with a good basic understanding of digital computers, working with assembly language is easy. Personally, I do not find it to be any harder than much of the .NET work I do. Sure, assembly requires me to know about things like how numbers are represented, how looping and decision structures are implemented, etc., but it will also never present me with one of those head-scratching, out-of-the-blue errors that make it so difficult to work with high-level frameworks, e.g. "Failed set trust point in ssl context" or "P
-
I have some limited experience with C# and VS 2008 and I don't understand why the .Net framework is so popular. It is a meta environment running on top of the operating system just like Java and the non-Windows implementations do not have all of the capabilities of the Windows version so it's not truly cross platform. I don't see why -- other than Microsoft's semi-forcing the issue -- someone would choose to use this. Shouldn't Win32/64 code run just as well, if not better, since there is no runtime between the code and the system? I can't help thinking of Java or even UCSD P-System Pascal when I look at this. I realize .Net has a large amount of built-in functionality but the same thing could be implemented in native code as well. What am I not seeing here?
b_dunphy wrote:
What am I not seeing here?
Well, it's classic VB's replacement. It makes things easier for your typical biz app and takes it a one step further too. And MS has a pretty good stronghold on this market segment so if they push it for Windows dev, then it's gonna get popular in the business world. And, I say this as a die-hard C/C++ fan with a day job in .NET.
Jeremy Falcon
-
Rob Graham wrote:
Unlike java
Java had JIT compilation for a long time.
It does not however, compile to native code, which was my point.
-
Because ASP.NET is so much better than any alternative. Due to having .NET developers and the mistaken belief that .NET is good for anything, it gets used for everything. For internal one off tools, .NET can be very useful, though I have enough experience with C++ and MFC that that usefulness is marginal (and I have a few tools which I was able to write much faster in C++; I know because to entertain myself, I wrote them in both.) Almost all my production code that ships to customers is in C++. It comes down to experience. I'm continually surprised at the number of veteran developers who really don't know the Windows API all that well. I've also run across too many developers who aren't very good programmers and jump to any new technology claiming it's better in an attempt, I believe, to mask their overall incompetence. With .NET, for example, the could give a good presentation and sound like they knew what they were talking about, but actually wrote worse C# code than C++ mostly because they got so damn lazy.
Joe Woodbury wrote:
I've also run across too many developers who aren't very good programmers and jump to any new technology claiming it's better in an attempt, I believe, to mask their overall incompetence.
5!
Jeremy Falcon
-
I have some limited experience with C# and VS 2008 and I don't understand why the .Net framework is so popular. It is a meta environment running on top of the operating system just like Java and the non-Windows implementations do not have all of the capabilities of the Windows version so it's not truly cross platform. I don't see why -- other than Microsoft's semi-forcing the issue -- someone would choose to use this. Shouldn't Win32/64 code run just as well, if not better, since there is no runtime between the code and the system? I can't help thinking of Java or even UCSD P-System Pascal when I look at this. I realize .Net has a large amount of built-in functionality but the same thing could be implemented in native code as well. What am I not seeing here?
b_dunphy wrote:
why the .Net framework is so popular.
Depends on whom you ask? How many*desktop* applications which you use on a day to day basis are written in .NET? Let' see:- 1. Internet Browsers - Chrome, IE, FF, Opera -> None of them are in .NET 2. Microsoft Office - Not .NET (though some add-ons can be .NET) 3. Windows Live Messenger, Yahoo messenger, Google Talk etc - Not .NET 4. Notepad, Paint, Calculator - Not .NET 5. Visual Studio - Mainly .NET 6. SQL Server - Not.NET but portions of Management studio/BI Studio are .NET 7. Task Manager - Not .NET I am just talking about Windows here. Mac and Linux users may survive even without knowing about .NET. The place where .NET is popular is in Websites developed for IIS (lot of intranet sites). ASP.NET is almost the de-facto choice. Now again, IIS is a very small percent of total websites out there. The only other place where .NET is popular is enterprise applications or custom developed enterprise apps.
-
That's not really a helpful response. It is valid to ask "at what level of abstraction should I be working?" The answer to this question is not, as many people seem to assume, that we ought to work at the highest level of abstraction possible. Abstraction is not necessarily an absolute good. At the lowest level of abstraction, we have machine language (NOT assembly language, as anyone who's ever hand-assembled code can tell you), followed by assembly language, and then by languages like C and Pascal, and then by newfangled technologies like .NET and Java, and finally by "code free" quasi-development technologies. As one moves among these levels of abstraction, there are tradeoffs. Moving up in abstraction reduces the speed of the object application and (more subtly, but importantly) the speed of the development tools. It also reduces the depth with which the developer can claim to understand his or her code; again, this is a subtle and oft-overlooked drawback to abstraction, but it's real. At each level, the returns to greater abstraction diminish. Assembly is much easier than machine language, which doesn't correspond to even the most basic human expectations of what a "language" should be. C is significantly easier than assembly, although the difference is less dramatic. C++ and C# offer benefits compared to C, but, again, these are not as dramatic as the previous steps up the abstraction ladder. I would submit that C#, Java, etc. may reside at a level of abstraction that is too high for many projects. Garbage collection is, for me, an example of why this is so. Look at what good C++ programmers do with automatic smart pointer variables, and then ask yourself whether an non-deterministic, out-of-thread system is really necessary to reclaim heap objects. Such "magic" definitely abstracts away some troublesome details... but are we sure (given the neat alternatives) that this is a good thing...? I can imagine plausible arguments both ways. Finally, let me assure you that for someone with a good basic understanding of digital computers, working with assembly language is easy. Personally, I do not find it to be any harder than much of the .NET work I do. Sure, assembly requires me to know about things like how numbers are represented, how looping and decision structures are implemented, etc., but it will also never present me with one of those head-scratching, out-of-the-blue errors that make it so difficult to work with high-level frameworks, e.g. "Failed set trust point in ssl context" or "P
In languages like C, C++, C#, Java etc you still "have to" know how numbers are represented - ok you might get away with ignoring issues like that, but then your code is likely to suck. Such as this, I never want to see this, if I see this I will tell you in your face that you suck and I will tell your boss to fire you:
bool IsPowerOf2(int x)
{
for (int i = 0; i < 32; i++)
if ((int)Math.Pow(2, i) == x)
return true;
return false;
}And yes, I saw that one in the wild. Suggested replacement:
return (x & (x - 1)) == 0;edit: the replacement treats 0 as power of 2, of course, usually not a problem in my experience and easy enough to change. -
I have some limited experience with C# and VS 2008 and I don't understand why the .Net framework is so popular. It is a meta environment running on top of the operating system just like Java and the non-Windows implementations do not have all of the capabilities of the Windows version so it's not truly cross platform. I don't see why -- other than Microsoft's semi-forcing the issue -- someone would choose to use this. Shouldn't Win32/64 code run just as well, if not better, since there is no runtime between the code and the system? I can't help thinking of Java or even UCSD P-System Pascal when I look at this. I realize .Net has a large amount of built-in functionality but the same thing could be implemented in native code as well. What am I not seeing here?
Look at the alternatives and you will get your answer. 0. MFC is a poor framework with a Spartan visual components library. 1. Java libraries are a complete duck-typed mess of poor and good technologies, most of them with an insane learning curve. 2. Delphi is not what it used to be in the late 90s. 3. Nokia’s Qt Developer – I see a spark here, but I can’t comment on it yet because I’m looking on this IDE only from a week. Am I missing some other popular framework?
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
modified on Wednesday, December 1, 2010 2:55 PM
-
b_dunphy wrote:
why the .Net framework is so popular.
Depends on whom you ask? How many*desktop* applications which you use on a day to day basis are written in .NET? Let' see:- 1. Internet Browsers - Chrome, IE, FF, Opera -> None of them are in .NET 2. Microsoft Office - Not .NET (though some add-ons can be .NET) 3. Windows Live Messenger, Yahoo messenger, Google Talk etc - Not .NET 4. Notepad, Paint, Calculator - Not .NET 5. Visual Studio - Mainly .NET 6. SQL Server - Not.NET but portions of Management studio/BI Studio are .NET 7. Task Manager - Not .NET I am just talking about Windows here. Mac and Linux users may survive even without knowing about .NET. The place where .NET is popular is in Websites developed for IIS (lot of intranet sites). ASP.NET is almost the de-facto choice. Now again, IIS is a very small percent of total websites out there. The only other place where .NET is popular is enterprise applications or custom developed enterprise apps.
Rama Krishna Vavilala wrote:
5. Visual Studio - Mainly .NET
And see how frequently people here bitch about it being buggy and slow. Now whether or not that's the fault of .NET, or the developers, or some combination, who knows, but it's not exactly a positive endorsement. Personally VS 2008 drives me up the wall, since I do a mix of C# and C++ coding, and I really long for the days of VS6.
¡El diablo está en mis pantalones! ¡Mire, mire! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Personal 3D projects Just Say No to Web 2 Point Blow
-
Rob Graham wrote:
.Net JITs to native code, optimized for the particular OS and hardware it is running on, so it can in many cases actually be faster than pre-compiled Win32/64 code, since it can take advantage of OS specific and processor specific optimizations.
Baloney. The JIT compiler is still saddled with the constructs of .NET. I've done extensive benchmarking and have found that purely algorithmic code is 4x slower on average with .NET than native C++. When using the framework, there are portions of .NET that are faster, though once you figure out what they're doing, you can get almost always get better performance with C/C++. (A common trap is file i/o. .NET can make this look so fast until you realize that they are often caching the entire file!)
Rob Graham wrote:
not forcing developers to re-invent the wheel every time?
Laziness. There are plenty of libraries out there that offer fantastic functionality for C++. They are just as easy to learn as .NET and sometimes easier. The difference is that .NET puts all this massive amount of code (35MB of mostly native C++) in one place with one runtime. If you gave yourself a budget of even half that, you can easily build a list of fantastic C++ libraries that aren't very expensive. I will openly and totally conceded that dealing with COM is much easier in .NET. One reason is that the objects are actually documented (using undocumented objects in .NET is as big a pain as in C++ and Microsoft still has way too many undocumented "must use" COM objects.)
It's still compiling to native code. Algorithmic code is slower because that native code includes a lot of extra checks that you would have to do manually in C++ (Or just know they aren't needed). You sacrifice runtime speed for better stability and less chance of nasty little buffer overruns and the like. Personally, I find that C# is absolutely perfect for my current (professional) situation. I'm a solo developer writing in-house software to support a small trading desk. I have no QA staff and no other programmers to divide up the work. Bugfixes and added features need to be done and deployed to the end users quickly (Talking minutes or hours, not days). If I desperately need a performance boost somewhere, I either drop to unmanaged code or move the functionality into a Managed C++ assembly... Otherwise, I use C# for rapid development and easy maintenance, and WPF for good-looking and responsive interfaces (WPF's data binding is incredibly useful, once you get used to it). Now, if I was at a game development shop, or a mainstream commercial developer, and they were using C#/WPF, I'd probably be saying much the same things as you are. The name of the game is using the right tools in the right situations.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
It does not however, compile to native code, which was my point.
Rob Graham wrote:
It does not however, compile to native code,
May be I am not following you. Java HotSpot VM always compiled to native code and it works almost the same way as the .NET JIT compiler. Are you talking about "ngen" pre-compiler? I am not sure if there is a Java equivalent of that.
-
Look at the alternatives and you will get your answer. 0. MFC is a poor framework with a Spartan visual components library. 1. Java libraries are a complete duck-typed mess of poor and good technologies, most of them with an insane learning curve. 2. Delphi is not what it used to be in the late 90s. 3. Nokia’s Qt Developer – I see a spark here, but I can’t comment on it yet because I’m looking on this IDE only from a week. Am I missing some other popular framework?
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
modified on Wednesday, December 1, 2010 2:55 PM
Deyan Georgiev wrote:
0. MFC is a poor framework with a Spartan visual components library.
Not entirely true. MFC is not well designed as Windows API or .NET classes, but it still has its place. Who, on MSVC environment would use VCL ?
-
Look at the alternatives and you will get your answer. 0. MFC is a poor framework with a Spartan visual components library. 1. Java libraries are a complete duck-typed mess of poor and good technologies, most of them with an insane learning curve. 2. Delphi is not what it used to be in the late 90s. 3. Nokia’s Qt Developer – I see a spark here, but I can’t comment on it yet because I’m looking on this IDE only from a week. Am I missing some other popular framework?
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
modified on Wednesday, December 1, 2010 2:55 PM
Deyan Georgiev wrote:
Am I missing some other popular framework?
Yes, WX Widgets, for instance! ;)
-
Rob Graham wrote:
It does not however, compile to native code,
May be I am not following you. Java HotSpot VM always compiled to native code and it works almost the same way as the .NET JIT compiler. Are you talking about "ngen" pre-compiler? I am not sure if there is a Java equivalent of that.
I misspoke, having forgotten about the VM hotspot compiler. After actually checking on the facts :-O I note that Java now also has several precomilers like ngen available on various platforms...
-
Deyan Georgiev wrote:
Am I missing some other popular framework?
Yes, WX Widgets, for instance! ;)
Is it popular and well supported? I’ll give it a look.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
-
It does not however, compile to native code, which was my point.
Of course it does. Bytecode and IL are basically equivalent concepts, and both get compiled just-in-time to whatever the CPU needs to execute them, i.e. native code. Unless you are using an interpreter on purpose. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.