August 8th, 2003, 12:10 PM
I think in programming Windows the language doesn't matter. It is still the Windows flat C API that is making everything possible. Frameworks like .NET are written very tricky to represent it a fully object oriented way. Even MFC is tricky but it is just a thin layer over the API. .NET is slow. Have you ever seen how many .dll's is loading your .NET app. I 've written a small program and it shows that they are over 20!!! Compare with 3-6 system dll's that is loading a program written to the API. Those libraries are all those layers that sit between you and the OS and are trying to represent thinks the way they are NOT. When your .NET app crashes (and i've seen more .NET app's crashing than app'c written to the API) it is still showing you thinks like IntPtr, WndProc, etc. And if you don't know what is that, shame on you, you are not a Windows programmer!!! .NET and any other very high level framework doesn't give freedom to choose your own application architecture and that produces bad programmers and a bad programmer can't write a good program.
For example I have written my own dialog data exchange system using plain ANSI C and the Windows API that is simpler to use and more powerfull than the frameworks provide and i use it in my API programs. Of course using a framework is easier but it doesn't produce good programmers.
I think the more frameworks simplify things the more confusing things become, the more overhead is added. Simple is beautiful.
August 8th, 2003, 04:44 PM
While loading a .NET application is a fair bit slower then say a C application (due to all the DLLís and that fact that .NET uses JIT compiling) .NET applications typically perform quite well and have the potential to perform better then most C applications that ARENíT compiled for a specific system. Unlike Java (quite possibly the worlds slowest language) .NET does not generate assembly as it runs but all at once during application startup with a fairly impressive assortment of optimization capabilities that can only improve. This allows it to take advantage of the fact that the JIT compiler knows information about the CPUís registers and additional instruction sets (i.e. MMX etc.) and thus can tailor its assembly for that specific machine.
Now while Linux is a good example of how you can improve system performance by compiling source code with optimizations for that specific system, when developing commercial software you really donít want to 1) distribute your source and 2) have to worry about non computer savvy clients not knowing why they are getting .c files instead of an .exe.
Iím not going to argue with you that C isnít a great language, Iím a big fan of it the elegance of its pointers and that fact that it does not require a large runtime in a huge plus. But there is no way the productivity of writing an application in C can compare to that of C#, and for a lot of office applications having the most optimized code possible is not a requirement.
There is also a certain elegance to OOD in C# (not to say that Object C isnít elegant) but I find C# OOD code far more easier to maintain and write then in C or C++ and in the hands of someone who understands OOD it can produce far more manageable, elegant and logical code with out the redundancies or procedural programming. Iíve written a fair deal of large applications in several different languages and nothing quite compares to how C# handles OOD and how everything just, well, works out so (I hate to overuse this word but) elegantly.
I should also point out that I doubt there is a runtime out there as comprehensive as the .NET framework. Virtually anything you could ever want to do is built into it and while it does come with a huge size cost, you know that as long as you have it installed and youíre competent at writing code youíll be dependency problem free.
.NET is also very stable as long as you know what youíre doing. The last application I developed in it I sent to my client just under a month ago. They run it pretty much all day long and have never once complained of it crashing or any other bugs. It ran without a hitch the first time they launched it.
Well Iíve written a great deal more then I had originally panned to, but donít think for a minute that Iím trying to say that C# is better than C. I still use C because there are many situations where it shines and just makes sense to use, but the same can be said for C#. They are two different languages for a reason; they both have their strong and week points. If you donít like C# thatís fine but there is no reason to attack it and yes, you can still be a good programmer and make use of the .NET framework.
August 20th, 2003, 08:17 AM
Well, i am not saying that C# is a bad language. After all the language is the compiler that sits behind it. And Microsoft produces good compilers. They embedded in the compiler all the OO goodies they promised for years. Here my point is on the framework. I think the Win32API is already a good framework. Compared with the Macintosh it is really more low level, but it is not the lowest level in Windows and, like some people say, hard to program. In fact there is no lowest level in Windows, even drivers are insulated from the hardware, if you know the API you know how to write drivers, the same principles are involved. The Windows API is fully object oriented.
OOP is not a technical issue but a general paradigm.What is an object?: A region in memory. You can say everything is an object in computers. You can do a good object oriented programming in C and the Windows API. There are no limits, you can do anything you want. In fact i am writing my apps just like that. Yes sometimes the API is hard, but that's why it is an API. It provides the basic building blocks for any application. If you want, say, a docking toolbar you will need to write one with all the logic and handling messages. It is just what the frameworks do. And i am really surprised when somebody says ".NET framework is a replacer for the Windows API.". NET framework is a framework. It simplifies things, but under the hood there is the OS.
I think when it comes to develop something that the framework doesn't provide in any case the code become huge. It is only a matter of how you will architecture your code so that you can understand it after 3 moths or a year and it is a matter of thinking not of frameworks. Here is an example: i needed a customized updown control for my app, but it was harder to customize the Windows common control than to write my own, so i decided to write one from the scratch - with the RegisterClass, WndProc and handling all the messages needed, painting and logic. Now this control can be used from any development tool because you create it like any Windows control with CreateWindow. You can write any wrapper around it or even make it an OCX or .NET control (because it is an OS control). If i write it using .NET it would be usefull in the .NET environment and the code would be bigger in any case.
Another very important thing is the development environment. If I had a good C API development environment that helps me while I write, shows me detailed info about my variables, structures , functions and files, something like what the Visual C++ for MFC programmers does, my work would be very simplified and the times it takes to me to build an app would be short. In fact there is such an envorinment Ė the LccWin32, but at the moment it has many bugs so I canít use it efficiently.
So my point here is: i am not against frameworks or high level programming, i am against the lack of knowledge that leads to wrong understanding of the reality.
(Thank you spending your time on for reading this huge article).