Main Area and Open Discussion > General Software Discussion

Why the aversion to .NET Frameworks?

<< < (4/15) > >>

Eóin:
My observations:


* DLL-hell does not apply. It refers to when different versions of DLLs could coexist side by side and were not backward compatible. .NETs can sit side by side quite happily.
* Backward compatibility, also not an issue, with just .Net 3.5 installed I've been able to run any .NET programs which I've come across. Same goes for the compact .NET frameworks on phones, you only seem to need v 3.5.

mouser:
I have a different reason for so-far avoiding getting into dot net, as a programmer.

I really like a LOT of what they have done with it, but i'm not going to embrace a new giant powerful framework that doesn't have first-class cross platform support as one of it's main goals.

Eóin:
I share those sentiments mouser, but that's from my programmers perspective too.

widgewunner:
In a word...

C#
Microsoft had the unmitigated audacity (there I go using that phrase again!) to actually name their proprietary programming language C-sharp, thereby tarnishing (in my mind anyway) a very beautiful and sacred thing: The C programming language - by association. How dare they! Its as if the logical progression was from C to C++ to C#. NOT! Let me explain...

In the mid '80s I made the switch from FORTRAN to C and what a glorious transition that was. Like the C language itself, the original K&R book was a small and beautiful thing (which I proudly keep to this day). The second ANSI standard edition was even better. Then during the '90s I wanted to fiddle around with Windows, so purchased and read each revision of Charles Petzold's classic work: "Programming Windows". This book covers "low-level" programming for the Windows OS using C to directly access the Win32 API. My first copy was the third edition: Programming Windows 3.1, then later it was Programming Windows 95 and then finally, in 1998 I got Programming Windows - Fifth Edition. Here are a couple of short quotes from chapter one of the fifth edition:

To illustrate the various techniques of Windows programming, this book has lots of sample programs. These programs are written in C and use the native Windows APIs. I think of this approach as "classical" Windows programming. It is how we wrote programs for Windows 1.0 in 1985, and it remains a valid way of programming for Windows today.
...
Any software layer on top of the native Windows API necessarily restricts you to a subset of full functionality. You might find, for example, that Visual Basic is ideal for your application except that it doesn't allow you to do one or two essential chores. In that case, you'll have to use native API calls. The API defines the universe in which we as Windows programmers exist. No approach can be more powerful or versatile than using this API directly.

MFC is particularly problematic. While it simplifies some jobs immensely (such as OLE), I often find myself wrestling with other features (such as the Document/View architecture) to get them to work as I want. MFC has not been the Windows programming panacea that many hoped for, and few people would characterize it as a model of good object-oriented design. ...-Charles Petzold
--- End quote ---

The same could be said today. When I went to purchase Petzold's next book in 2001: Programming Windows with C#, I couldn't believe my ears (eyes?) when I saw that he had apparently set aside the importance of "classical" Windows programming and had taken the .NET/C# blue pill that Microsoft was starting to push. I guess he had to as he wanted to keep up with the latest technology and keep selling books. I did not buy that book and have not learned anything about .NET and C#.

But, there are a couple things that are not going away anytime soon and that is 1.) the C programming language and 2.) the native Win32 Application Programming Interface API. Other "great ideas" from Microsoft have come and gone out of favor (e.g. Object Linking and Embedding OLE, Dynamic Data Exchange DDE, Microsoft Foundation Classes MFC, etc). I could very well be wrong, (and living in the past, sticking to old outdated technologies), but I see .NET as yet another one of these bloated behemoths destined for obsolescence. Although .NET/C# is probably not as bad as MFC. I simply don't have time to spend learning a technology that may be gone in less than a decade.

I am an old school procedural (non-object oriented) programmer (dinosaur) who really appreciates well written, small, fast, robust and reliable programs that run on all 32 bit versions of Windows and don't require a giant supporting cast of libraries/frameworks. Hell, call me paranoid, but I don't even trust MSVCRT.DLL and statically link in the C library functions. Disclaimer: I don't write large, complex web apps under a deadline and it takes me approximately forever to get a program finished. For me Windows programming is just a hobby (I've actually written only one significant Windows program) - but I *do* know enough about how Win programs work to appreciate programmers who think as I do and produce small fast apps that happily run from a thumb drive on everything from Win98 to Win7. This is why I tend to shrink away from programs that say: "This program requires .NET".

I don't *hate* .NET. It certainly has its place, and I'm sure that C# is actually a pretty good language. I guess the bad taste in my mouth that I get with .NET (and C#!) is based on a gut feeling and, like rjbull, may be rooted in Some kind of snobbery. :)

f0dder:
First: I consider C++ my main language, and I still do raw Win32 API coding. But nonetheless:

C sucks. C++ is pretty nice, but lacks a lot of stuff that you'll have to go to 3rd party libraries to get support for, and portability can become a real problem -and there's so many ways to blow off your legs, and a bunch of things that are pretty clunky. Win32 API level programming s-u-c-k-s, it's such an incoherent jungle because of all the years of legacy and different teams designing different parts. The PlatformSDK headers are an absolutely abysmal hellish collection of turd that still use preprocessor magic for stuff that really should be enums and inline functions (ever tried creating a function named WriteFile in your own class/namespace? Won't work).

I haven't worked enough with .NET to comment much on the framework yet, but C# seems like a pretty nifty language, really. And part of what makes it nice wouldn't be easy achieving in a non-JIT language, and can't really be "bolted onto" an existing language like C++.

Navigation

[0] Message Index

[#] Next page

[*] Previous page