Re: Up to date MFC Book
- From: Daniel James <wastebasket@xxxxxxxxxxxxxxxx>
- Date: Fri, 01 Sep 2006 10:39:46 +0100
In article news:<egYb6VTzGHA.1252@xxxxxxxxxxxxxxxxxxxx>, Ian Semmel wrote:
I think that too much can be made of what language a program is written in.
You're right ... up to a point.
To the end user what matters is that it works and doesn't cost the earth.
To the developers what matters is that they are comfortable with the language,
and with the tools that support the development in that language on the
development platform (which may not be the same as the target platform).
In any system, the main thing is that the requirements are clearly spelled out
from the start.
That's a given, yes.
Good programmers can implement a system in any language.
Yes ... and I've seen some very inventive uses of FORTRAN to process textual
data. Some languages do lend themselves better to certain types of problem than
others, I wouldn't chose FORTRAN to write a word-processor any more than SNOBOL
or perl would be my first choice of language for software to solve crystal
structures from X-Ray diffraction data -- that doesn't mean that you can't do it
(or that it hasn't been done).
C++, C#, Java, and others of that ilk make a claim to being "general purpose"
languages -- which means that they are not honed to perfection for any one class
of task, but should be adequate for most. My friends who write weather simulators
on vastly-parallel IBM supercomputers don't use C++ for it (with good reason).
While C++ is very clearly (to me) a vastly superior language to C# or Java it is
true that C# and Java (and Delphi, for that matter) have some very nice developer
support tools (especially for general GUI application development on common
desktop platforms) that C++ doesn't.
The solution is not to switch blindly to a less powerful language, but to demand
better tools for C++.
Part of the problem where C++ is concerned is that it has a rather complex
syntax, and so is difficult for tools to parse and process ... but if we can
write compilers for the language then surely it can't be that hard to write (say)
a decent refactoring tool?
[I've had this discussion before, and people have pointed out to me that the
parse the compiler has to do is different from the parse that a refactoring tool
would have to do because while the compiler can run the preprocessor as a
separate pass and then just work with the output a refactoring tool has to be
able to include preprocessor symbols in the parse tree and to be able to "look
inside" preprocessor macros. I don't think that makes the parsing significantly
more complex -- especially when you consider how complex C++ already is -- it
just makes it different. You need the same number of passes, but the first pass
is different and the parse tree you get at the end is more detailed than is
required for compilation alone. -- but I digress]
The main difference, in my opinion, is that in the .NET/C# world is that youtogether.
have Designer Mode, where the code is exposed at design time, and a multplicity
of wizards which allow you to drag objects around the place and link them
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.
This is what I call the "Delphi Syndrome". You can knock off a quick GUI app with
a really quite amazing amount of functionality in next-to-no time, but the
functionality you get isn't necessarily quite what you (or your requirements
spec.) want. From there on you have to fight the tools every inch of the way to
get them to do something that wasn't conceived of by the tool designer.
One of the great things about MFC (for all its shortcomings and poor adherence to
OO design principles) is that it wraps the Win32 API enough to let you do what
needs to be done with the minimum of faffing about, and without imposing any
design constraints on the programmer. The fact that MFC code that was written for
Win16 could be compiled with only minor changes for Win32, and can now be
recompiled with similarly minor changes for Win64, is a huge added bonus.
Once .NET is embedded in the OS, as will happen I presume, things might be
different.
No, not right away. Once .NET has been embedded in the OS for so long that it can
be taken for granted things will be different. The release of Vista won't mean
that suddenly, overnight, everyone has the .NET runtime preinstalled; and until
that can be assumed by the programmer there will continue to be reluctance to
build for CLI rather than native code unless there is a specific reason to
require it.
It's ironic that all this .NET stuff has come about just as MS has finally done
away with Windows for all non-intel platforms. Being able to distribute one
application binary and -- because it's a CLI app -- have it able to run on x86,
Alpha or PPC would have been incentive to develop for .NET.
Cheers,
Daniel
.
- Prev by Date: Re: Up to date MFC Book
- Next by Date: Re: How does this work?
- Previous by thread: Re: Up to date MFC Book
- Next by thread: Re: Up to date MFC Book
- Index(es):
Relevant Pages
|
