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
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. :)