Re: Up to date MFC Book

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance



Ajay Kalra wrote:
"Ian Semmel" <isemmelNOJUNK@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:egYb6VTzGHA.1252@xxxxxxxxxxxxxxxxxxxxxxx


This is all well and good for producing simple programs quickly, but I

reckon

that in developing large and complex applications, when the requirements

fall

outside what wizards produce, the advantages of these procedures diminish.

C#

then tends to be not as simple as first portrayed.


I dont buy this at all. I hardly ever used wizard in MFC and it was fine.
Similarly, wizard in .Net only helps in doing WinForms kind of work.
Developing classes which are non WinForm (and thats a majority for a large
project) have nothing to do wizard(or dont have to be). Its same as C++.
There are just design issues which are identical to what you had to deal
with in C++. In a large project, product development is never driven by what
is or is not offered by wizard. I see *nothing* wrong in using C# in a very
large project. I suspect VB.Net is the same way. These are drastically
different languages than VB.

--
Ajay Kalra [MVP - VC++]
ajaykalra@xxxxxxxxx

Sure, you don't have to use the wizards in C#, but when you don't, one of the major selling points disappears.

It is not just WinForms, it is the integration of the forms with Data Sources that is pushed in a major way. Drag a table onto a form and you get a DataGridView with a fancy toolbar, forward/next buttons rtc allowing you to scroll and update a dataset. However, no one would use the produced code in a real app, so you then have to delve deeper into the wizard code to work out its functionality etc.

So in the real world, you probably wouldn't use the wizards much at all. Much of what is done with C# could have been implemented into an advanced MFC except that MS has built a brick wall in the path of any further development.

Forty years ago, it was predicted that programmers would die out as there would be no need for them. This is why COBOL was designed with sentences and paragraphs etc. Your average clerk would write something like

IF STOCK-ON-HAND IS GREATER THAN AMOUNT-ORDERED THEN SUBTRACT AMOUNT ORDERED FROM STOCK-ON-HAND OTHERWISE ADD AMOUNT-ORDERED TO AMOUNT-ON-BACKORDER.

(I actually saw an example like this which went on for several paragraphs in an NCR-315 COBOL manual).

Since then, there have been many attempts (unsuccessful) to "dumb down" programming. Remember 4GL's ?

On a couple of occasions, I have had people come to me with Access database systems that they have designed themselves with a query like "I have designed this great system. All I want you to do is package it up so that I can sell it commercially". When I say something like "Yes, I can do that for $20,000" they think I am ripping them off because it it so easy to do in Access.

Watch some of the promotional videos on C#. Anyone can be a programmer with no training whatsoever. "It's fun".

My point is that whether you are using C#.NET or C++.MFC or anything, the techniques of programming and the attributes required of programmers don't change. Good programmers write good programs, bad programmers write bad programs and non-programmers usually produce garbage.


.

Quantcast