Opinions
Sympathies:
- Standardized languages.
- Few lines of code, drawing heavily on (huge) commercial object-based
libraries.
- Standard notation, standard terminology, standard naming conventions
Antipathies:
- Proprietary, non-standardized, non-portable languages/language-extensions: Borland
Pascal not mentioned.
- 'Small' languages/macro-languages/special purpose languages/university
languages: Using good base-classes, it's almost always possible to do the
task using OO in as few lines as in any specialized language - all it takes is in-depth knowledge
and understanding of C++ and maybe more books - and concentration. The end result -
the actual source - is more valuable if written in universally accepted and known
C++, than in some obscure dialect, like Smalltalk or Dylan or Borland
Pascal with Objects (derived from/subset of C++) or Basic or Comal
or Java (derived from/subset of C++) or PL/M or Cobol
or...[list goes on]
- Using the "right" tool (language) for the specific task at
hand: We have all-round C/C++, which can be used for anything from
bit-shifting to floating point number crunching and creating huge, complex, extendable
networked systems just as well as any number of specialized languages combined can. Why
bother with more syntax's [languages] that necessary?
- Non-Hungarian: Hungarian is highly expressive - and it's
well-established. Using a standard always beats rolling your own. All objections to
Hungarian stems from a naive dream of code as readable as plain English. Which is a really
bad idea.
Preferred tools and why:
- As should be obvious above, my preferred "tools" are: Windows NT and
MFC. NT is highly portable and might be the most robust and versatile OS ever.
MFC is the standard, like it or not, supported by vendors of great compilers
like Symantec, Watcom, Borland and even Microsoft. Using MFC with compilers and tools by
Microsoft and other vendors, MFC apps gets portable too, and will compile to,
among others, Windows 3.1+95+NT+CE (i80386+, Alpha etc.), Mac (PowerPC, 64K) and plus the Unix flavor of your taste.
MFC is fast and thin where it matters, i.e. utilizing C++ inlining
("what is inlining?", Pascal programmers will ask) all over the place, and
mature, having been used for commercial apps for years on end, something that one
sometimes doubts that OWL, Visual Age or Visual Basic are or ever will be - this really
makes the difference. Sad with only one safe 'alternative'? Maybe, but software
development should converge - too much otherwise ok software is discontinued and lost due
to it being implemented in kooky languages/tools.
MFC is big and fat where appropriate, taking the drudgery out of the
networking- and OLE-horrors etc.
Q/A:
- Q: "Why do you praise MFC? Using Delphi [/Visual Basic/Java] you
can do everything you can do with MFC, only it doesn't take so long..."
A: You hit a button and the program writes itself, right? You should know
that you don't get anything for free - especially not in computing. First, the
higher the level you code in is, the more freedom and control you lose. The larger the
building blocks you use as foundation of your code are, the less likely it is that you're
really able to change the building blocks basic functionality or build a 'real' building
block on your own. You get stuck all the time. Using MFC, there's always a way to do what
you want, and much more literature exists to tell you how, because it's in fact generally
used. Most contemporary Windows applications are actually made using MFC. It's open and
flexible. It's not made to conceal the complexity of computer programming; it's made to
enable you to do whatever you want to do - in an OO manner. It's hard to get into at
first, granted, but it pays off handsomely in the end. With Visual C++/MFC, you get the
highbrow, academic features of e.g. C++ STL, and the lowbrow features you need in daily
programming life for coping with Windows. Windows! Needless to say, MFC - made by
Microsoft, a software development company actually living off C++-code - tracks new
Windows features far quicker, more precisely and more naturally than any other framework.
And, no seasoned Borland-followers will believe this, a basic [trivial] MFC 1.0 Windows
app from 1991 targeting Windows 3.1 will normally compile for Win32 with no MFC-related
errors. Talk about a nice upgrade path, and a sound foundation. Second,
build times. Compilation speed as such means nothing. But experience tells us that fast
Borland-compilers encourage developers to build huge monolithic applications:
huge, fat .exe's. Bad. Slow Microsoft compilers on the other hand, makes developers think
of fragmentation, of ways to cut the apps up in smaller, manageable, logical modules:
satellite .dll's. What you want to do anyway, to enable team efforts, partial
releases/testing, or to do COM.
- Q: "Why do you place COM above Corba? Corba at least is created by
several companies in togetherness [IBM, IBM, IBM...]."
A: I'm not paid to work against, or compete with Microsoft. Are you? Do
your boss want you to crusade against some company, in working hours? I myself am paid to
get some programming job done, to produce code. Code that sometimes (often) needs to lean
heavily on other people's code. Again and again, Microsoft proves their will and ability
to deliver products that actually works, is available. E.g. OLE (and
later on, COM) were running and working on millions of Windows 3.1 PC's, while Corba were
nowhere to be seen, not out of the laboratory. Have anything changed since? Or
the move from 16-bit cooperative multitasking (Windows 3.1) to 32-bit preemptive
multitasking (Windows 95/NT). Apple's MacOS ought to be what Windows NT is, but is
fundamentally closer related to Windows 3.1, than to Windows 95 - which is pushing 5 years
of age!) Not to mention dreadful OS/2 "Lousier Windows than Windows ever was".)
Something Borland followers will never know: the Win16/singletasking to Win32/multitasking
transition were beautifully orchestrated, it was extremely easy for users of Microsoft
tools to port. Back in '93-95 they did what Apple hardly have bitten into today.
- Q: "What's wrong with Delphi?"
A: Anyone who knows both Borland Pascal and ANSI C++, will confirm that
BP always have mimicked C/C++, lagging behind on major fundamental features. If that only
meant no preprocessor. I need only mention details like lack of multiple inheritance,
'protected'-keyword, real constructors, and amazingly, up to Delphi 4.0, unsigned 32 bit
integer type - DWORD!
- Q: "What's wrong with Windows 95?"
A: Windows 95 is designed to run a word processor - or a
game. Generally it's made for office work. If your work goes anywhere beyond this,
e.g. if you're a software developer, and you're using 95, you're abusing it. You
must choose Windows NT for 'real' computing. Or Linux.
(Win95 is unstable, unreliable and hard to maintain, it's behavior non-deterministic in
the extreme. Unstable - it crashes all the time, as we all know. Unreliable
and hard to maintain - due to the legacy stuff (.ini-files, 16 and 32-bit .dll's
in same \system-directory etc.). )
- Q: "What's so great about C/C++?"
A: The greatest asset of C/C++ is also what frightens people the most:
The almost endless range of liberty, liberty to do almost anything. To make brilliant
code, to make a mess, e.g. using the powerful preprocessor.
The power of the preprocessor is hard to overestimate, in fact it's what enabled the
language to move and evolve in a sensible way: Bjarne Stroustrup initially applied his OO-ideas in C using only the
preprocessor. What other language is flexible enough to enable you to introduce and try
out a 'new' programming paradigm just like that?! Not Borland Pascal, for sure.
This page © Troels Knakkergaard. Updated nov. 23rd 1998