Main Area and Open Discussion > General Software Discussion
Why the aversion to .NET Frameworks?
daddydave:
Microsoft has made .NET the path of least resistance at least for their express versions of their compilers/IDEs, so by avoiding .NET you are weeding out a lot of hobbyist programmers as well, which is a good thing or bad thing depending on how you look at it.
I assume that people who hate .NET hate it on the Windows Mobile platform as well. If I wanted to try my hand at developing an app for Windows Mobile, I'd probably install SharpDevelop which is non-Microsoft IDE for .net/mono apps simply because I have no clue how I would do it otherwise and I have been able to get a "Hello World" running at least that way. (Microsoft's express versions do not support compiling to the mobile versions the last time I checked, you need the full Visual Studio for that).
As a user, which I am 99% of the time, it is weird to have 4 versions of .NET installed at all times but it does seem superior to getting notified of a Java update every week. But I assume the .NET haters hate Java even more than I do.
oldfogie:
I don't know if I would qualify it as hate so much toward Microsoft as much as, instead, Microsoft hates me. My beef with Microsoft is their horrible, horrible solution to DLL Hell: Fusion - better known as Side-by-Side assemblies - that whole WinSxS directory thing. .NET further propagated that abomination. Manifests, etc. have made life as a Windows programmer a living hell. At least I could deal with DLL hell. Most people don't even know where to begin when Fusion craps out - with the only "solution" being to reinstall the OS, which is hardly a solution.
And don't get me started on MSI. The slowest, second most bug-ridden piece of junk installer technology on the planet - second only to InstallShield. Take a good long look at how package managers for Linux work (esp. Ubuntu) and then tell me that MSI is anywhere on par. (Hint: It isn't even in the ballpark let alone the parking lot of the ballpark.) I dislike *NIX for various reasons too but the latest package managers completely blow away MSI. Yeah, I'm still waiting for someone intelligent to come up with an OS that isn't horrible.
You mention Paint.NET. Photoshop starts faster than Paint.NET. Like Java's early days, .NET, overall, has serious performance problems. The startup time for any .NET app is magnitudes slower than any equivalent native solution. .NET is interpreted bytecode - but without the decade or so of refinement that Java has. I dislike Java too but for different reasons. But some really popular apps are written in Java and those years of refinement are finally paying off. Barely - but not in time - Oracle had to buy out Sun to keep them from going completely bankrupt. I can't name a single .NET application that is recognized by major publications that ordinary users might use beyond Paint.NET. That's because they don't exist - even Stack Overflow can't seem to come up with a list beyond Paint.NET and Visual Studio.
I've seen a few mentions of Mono. But who actually USES Mono? Even among my *NIX friends I don't know anyone who actually USES it. They've played with it but there is a significant difference between playing with something and USING something. They'd rather write the application in C++ (yay!), Java (meh), or Flex (bleh). Mono has an unfortunate name too - being named after the "kissing disease", IMO. Performance is supposedly comparable to .NET but since no one uses it, it doesn't matter. People who write for .NET are writing for Windows users. If it HAPPENS to work elsewhere, great...but no support for you!
When it first came out, .NET was touted as having fewer (crash) bugs per application and was advertised as needing fewer try-catch/error checking blocks (because .NET would do the heavy-lifting) but about half the time I fire up .NET applications they crash on me in unexpected ways. Applications written in Delphi, C++, and even Java seem to be more stable overall. Then again, I don't run many .NET applications but when a .NET application crashes, it leaves a rather sour taste in my mouth. I've seen some code in C# and while the stuff I've seen wasn't terribly well written, I didn't see ANY benefits to learning a whole new language to discover new ways to crash software. We simply don't need a new language.
The real reason I "hate" .NET is Microsoft clearly favors the .NET languages instead of REAL programming languages like C and C++ but then turns around and hypocritically pronounces how much they cater to software developers. Oh, you're a C++ developer who wants to use the Ribbon interface? Yeah, you get to wait a few months to do that while .NET developers get extra loving from us. That's my real problem: I want to be able to write code in whatever damn language I please and don't tell me you cater to me (developers, developers, developers, developers!) if you aren't actually going to cater to me. Ribbon was only added to MFC after enough people yelled at Microsoft for favoritism. And, even then, Ribbon support was incomplete. .NET was and is a slap in the face to all the C/C++ developers out there. We knew Microsoft made a huge mistake but they keep pushing it like we will accept it. Fortunately there are enough C/C++ developers out there to FORCE Microsoft to (grudgingly) conform to our wants and needs. That's the sole reason Visual C++ still exists as a product that developers can use. If Microsoft had their way, they would only offer VC++ internally.
And then there is the abomination of Fusion-based Visual C/C++ runtimes that have to be deployed with the application. Ugh. And, guess what? There is NO REASON WHATSOEVER for the Fusion requirement. In fact, the Fusion "requirement" is a complete lie. The runtimes check for Fusion-capable OSes (2000 and later) but then never actually do anything Fusion-based whatsoever. Removing Fusion is a one-byte change. Fortunately, developers now have legal allowances from the U.S. Copyright Office to make small changes to binaries. A literal two byte modification is the difference that keeps the VC++ runtimes from operating under Windows 95 and later. That last sentence is hardly a complaint though but more of an observation that someone at Microsoft actually wrote code to intentionally cripple modern VC++ applications from running on older OSes. It is a slap in the face of developers who WANT to target Windows 95 for whatever reason. It isn't Microsoft's place to decide that developers can't target ridiculously outdated OSes.
Also, Microsoft deploys .NET through Windows Update but refuses to deploy the VC++ runtimes the same way so VC++ developers have to bundle the runtimes with their application but .NET developers do not have to bundle .NET. Another slap in the face.
And it continues on: Microsoft refuses to provide a C/C++ route on Windows Mobile 7. Want to write programs? You've got to use XNA Game Studio and learn C#. {vomit} I don't want to learn C#, Java, or any other crappy interpreted bytecode/scripting language. Especially on mobile devices. Got that? Good. The first mobile OS vendor for smartphones that provides a 100% NATIVE C/C++ interface - NOT the Android NDK, which still requires me to write Java - wins my development $$$ and time.
Here's the ironic kicker: The important parts of .NET, Java, et al are written in...C/C++ and assembler. In other words, even the authors of those languages admit that C/C++ is better.
I don't mind that Microsoft has .NET with one caveat: As long as they don't treat us long-time developers who write C/C++ as second-class citizens, they can do whatever they want that they think they can make money off of. However, this is NOT the case, so, as a C++ software developer, I feel like I've been slapped in the face a number of times and treated as a second-class citizen. .NET is pointless. Fusion is even more pointless. There is no need for either technology and both should simply vanish.
f0dder:
Can't really speak about the SxS implementation, as I haven't dived into it - but having the ability to have several versions of a component installed is A Good Thing(TM). Theoretically, components should stay backward binary compatible except when major-versions are relased - but that's not always done. And installing an older minor-version on top of a newer minor-version-but-same-major-version can cause trouble... but so can installing a newer component, if an application depended (willingly or not) on a bug in an older version!
Can't recall when I've been bitten by "DLL hell" except for a really old game that needed a really old msvcrt version, but I know there's a lot of crap software around. Never experienced SxS crapping out... but I can imagine it happens when people go messing with "cleaner" style applications or muck around in %SystemDir% without knowing what they're doing.
While I don't particularly enjoy MSI, you can't just compare it to linux package managers and say that the linux way is better - MSI offers a lot more flexibility. I haven't seen a linux package manager that lets you configure subcomponents of a package... if you'er offered any of that flexibility, either it's ports/portage-style compile-from-source, or you have to choose between several differently named packages - one package per featureset, ugh. Too bad MSI is so slow.
You mention Paint.NET. Photoshop starts faster than Paint.NET.-oldfogie
--- End quote ---
Perhaps if what you're comparing to is Photoshop 2, but definitely not the newer versions :)
.NET is interpreted bytecode - but without the decade or so of refinement that Java has.-oldfogie
--- End quote ---
It's JIT'ed (and interpreted for the codepaths that don't make sense to JIT). .NET hasn't been around as long as java, sure, but it's not like .NET hasn't benefited from research done before it was invented. As for speed wrt. Java, you can be sure that supports of either language will be able to come up with syntehtic benchmarks beating the opponent - but in the real world, the Java apps I've used feel slow and clunky compared to the .NET apps I've used. The reason most probably being the GUI toolkits used rather than the core VM speed, though.
I can't name a single .NET application that is recognized by major publications that ordinary users might use beyond Paint.NET. That's because they don't exist - even Stack Overflow can't seem to come up with a list beyond Paint.NET and Visual Studio.-oldfogie
--- End quote ---
Probably because a lot of the end-user desktop apps in use are old codebases, and a lot of new development is done for the web platform. Rest assured that a lot of business development is being done i .net :)
I didn't see ANY benefits to learning a whole new language to discover new ways to crash software. We simply don't need a new language.-oldfogie
--- End quote ---
While it might not be your impression, C# and the .NET platform definitely makes it faster to develop than C/C++, and definitely easier to avoid a lot of common crash opportunities. Especially people clinging on to C (and using the insecure libc functions) really shouldn't be doing any sort of networked code, please.
Oh, you're a C++ developer who wants to use the Ribbon interface? Yeah, you get to wait a few months to do that while .NET developers get extra loving from us.-oldfogie
--- End quote ---
Heh. The Ribbon was introduced to MFC first, and not added to .NET until 4.0... so come again :). Also, saying that C# isn't a "REAL" language is bullshit - it's a pretty damn fine language, even if the .NET framework isn't perfect.
If Microsoft had their way, they would only offer VC++ internally.-oldfogie
--- End quote ---
And that's why they've spent an enormous amount of time doing a lot of VC++ specific features in VS2010? Riiiiight.
A literal two byte modification is the difference that keeps the VC++ runtimes from operating under Windows 95 and later.-oldfogie
--- End quote ---
It takes more than that - there's imports for "recent OS" APIs, there's the PE header image/subsystem version fields, there's the loader config data section which Win9x barfs on, and iirc a couple of things more. But hey, you get the CRT sourcecode with Visual Studio... my biggest beef is that the recent linkers won't let you set an image version of 4, everything else is fixable.
Also, Microsoft deploys .NET through Windows Update but refuses to deploy the VC++ runtimes the same way so VC++ developers have to bundle the runtimes with their application but .NET developers do not have to bundle .NET. Another slap in the face.-oldfogie
--- End quote ---
I thought VC++ runtime updates were distributed through wupd as long as you use the recommended (MSI merge module) way of installing it? There's no proper way it can be done if you simply bundle the .DLLs in your own installer - sucks, but that's the way it is.
Microsoft refuses to provide a C/C++ route on Windows Mobile 7.-oldfogie
--- End quote ---
Pretty much every phone company has One True Way to program their devices, and it's usually with a managed language. I think Symbian is one of the few exceptions?
Here's the ironic kicker: The important parts of .NET, Java, et al are written in...C/C++ and assembler. In other words, even the authors of those languages admit that C/C++ is better.-oldfogie
--- End quote ---
Pretty minor parts, really - especially the assembly (*y, not *er). And yes, that is partly because there are performance-critical code pieces where it does make a difference - and partly because of the chicken-and-egg problem of doing a new language.
As much as I like C++, it's a super quirky language with a boatload of problems (language as well as standard libraries). C++0x came too late, and doesn't address all of the problems. There's definitely a need for a richer language than C++, and a more comprehensive standard library - C# and .NET class libraries are pretty decent (even if the .NET class libraries definitely aren't perfect). And it's a helluva lot easier using p/invoke than JNI when you need to dip into native code :)
widgewunner:
... Especially people clinging on to C (and using the insecure libc functions) really shouldn't be doing any sort of networked code, please. ...-f0dder (November 16, 2010, 05:09 PM)
--- End quote ---
You mean people writing such non-networked code as; Linux, Apache and PHP? (all of which are still "clinging" to straight C).
Truth is, C (and asm) simply can't be beat for systems level programming where size and speed (i.e. performance) really matter.
Eóin:
Truth is, C (and asm) simply can't be beat for systems level programming where size and speed (i.e. performance) really matter.
-widgewunner (November 17, 2010, 12:45 PM)
--- End quote ---
Thanks to templates, C++ offers the compiler much more opportunities for generating optimized code than pure C. And much as I love Asm, it really has no place in systems programming, and in high performance computing the professional world uses Fortran.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version