>|Now, how about addressing the point: if you agree that it is possible to
>|write an efficient class library that does a good job of abstracting the
>|problem domain, why didn't Microsoft do it?
>The MFC people did do so, you just disagree with them as to what "the
>job" is.

I guess so.

>I argue simply: if MFC isn't doing a good job, then why are several
>other C++ compiler houses licensing it for distribution with their compilers?

Hmm, I'm not sure you want to make this argument.  Carried to its
extreme, we could say, why are so many people using OWL?

Chris

In article <1992Jul23.020241.11513@cmcl2.nyu.edu> checker@acf3.nyu.edu (Christopher Hecker) writes:
|Hmm, I'm not sure you want to make this argument.  Carried to its
|extreme, we could say, why are so many people using OWL?

How many people ARE using it?  If many people are using it, why aren't the
other compiler vendors licensing it?

>In article <1992Jul23.020241.11513@cmcl2.nyu.edu> checker@acf3.nyu.edu (Christopher Hecker) writes:
>|Hmm, I'm not sure you want to make this argument.  Carried to its
>|extreme, we could say, why are so many people using OWL?

>How many people ARE using it?  If many people are using it, why aren't the
>other compiler vendors licensing it?

I have no clue how many people are using it.  I do know that the BIX
Borland forum is clogged with OWL questions, and MEWEL supports it (and
mentions that in their advertisements) among other things.  Add that to
the fact that Borland's share of the DOS C++ market approaches monopoly
and I'd say that there are more people writing OWL applications than
there are using MSC7 as a C++ compiler, but I have no way of proving
that.

Anyway, the real answer to, `How many people ARE using it?' is, `Too
many.'  Of course, that answer holds whether the `it' in the question is
OWL or MFC.

Chris

In article <1992Jul11.202006.23342@cmcl2.nyu.edu>, checker@acf3.nyu.edu
(Christopher Hecker) wrote:
>
>
> Yeah, writing those _insane_ macros must have been HARD.  Golly, how do
> you guys debug those puppies?  Again, MFC is such a thin layer that I
> would hope there are no efficiency problems (besides the normal win3
> ones).
>

Here a litte story you might be interested in.

Back in Feb, I was at the MacApp developers conference (MacApp is an very
nice application framework for the Mac).  One of the (Wednesday??) evening
BOF sessions was a presentation by Microsoft describing the MFC.  I don't
remember the guy's name but he was involved with the MFC.  His talk was
quite interesting....

MFC is Microsoft's second try at writing an application framework.  The MS
rep described how a group within Microsoft spent 1+ years putting together
a framework.  Management started asking for result but when people looked
at this framework, decided it was not usable by anyone outside of the group
that wrote it and threw it away.  Then they put a simpler framework
together, the MFC.

My initial impression of MFC was that it provides little more than a
wrapper around the standard Windows system calls.  When I started figuring
out timelines, I realized that the original framework work probably started
when Borland first announced OWL for Turbo Pascal (OWL for Turbo Pascal was
out about 6 months before the C++ version).  This leads me to believe that
MFC is little more than a marketing gimmick.  If Microsoft C/C++ 7.0 did
not have an application framework, it wouldn't be considered a
"professional" developers package.

The assertion used by Microsoft is that the MFC provides a clean interface
to Windows and it provides a simple way for developer to port C code
directly to C++.  They "prove" this show how most of the methods have the
same name and take the same argument as the Windows system calls.  Hmmmm, I
wonder what those methods do??  Maybe just call the system call?

Maybe it is just me, but I find having a high level of abstraction very
useful.  A lot of people state the prefer MFC, but I would really like to
know how long they have been doing object oriented programming.  When I
first started out, my code was little more that standard C code with a
hapzard grouping of functions into a class.  I personally believe that MFC
will promote this style of programming.  Developers who use C will love it
because they can tell their boss that they are using C++ but they won't see
the benefits of using an object oriented language and their boss won't see
any productivity increase and there will yet another "knowledgable"
executive stating the object oriented methodolgy is just a bunch of hot
air.

-------------------------------------------------------------------------
Heeren Pathak                      | Television is a device that permits
pathak@mitre.org                   | people who haven't anything to do to
Mitre Corporation                  | watch people who can't do anything.
(617) 271-7465                     |                 -- Fred Allen
-------------------------------------------------------------------------
Disclaimer: Mine not Mitre's.

>Here a litte story you might be interested in.
>MFC is Microsoft's second try at writing an application framework.  The MS
>rep described how a group within Microsoft spent 1+ years putting together
>a framework.  Management started asking for result but when people looked
>at this framework, decided it was not usable by anyone outside of the group
>that wrote it and threw it away.  Then they put a simpler framework
>together, the MFC.

Actually, this is exactly the same story I heard from none other that
Charles Petzold.  He spoke at a user's group meeting here in NYC a while
back.  I proposed that Microsoft wrote MFC to tie people to the Windows
SDK and he didn't argue with the idea.

>This leads me to believe that
>MFC is little more than a marketing gimmick.  If Microsoft C/C++ 7.0 did
>not have an application framework, it wouldn't be considered a
>"professional" developers package.

I agree, but as I say above, MFC does a bit more than allow Microsoft to
put `includes MFC' on the box.  Anybody who uses it is instantly tied to
the windows SDK.  Of course, Borland is just as bad, if not worse: OWL
not only ties people to windows by its lack of encapsulation, but it
also ties them to the Borland compiler because of the langauge extension.

>Maybe it is just me, but I find having a high level of abstraction very
>useful.

I don't think it is `just you.'  The idea of abstracting the problem
domain is central to object oriented programming and design, as far as
I'm concerned.  The problem domain here isn't windows.h or the SDK, it
is writing a windowing application.  There are far more similarities
between windowing systems like PM, Windows, and X than there are
differences; we need a class library that abstracts out those
similarities.  Obviously you are only going to get the lowest common
denominator, but that would be more than enough for most applications,
and those that needed more could go to the API, knowing that they were
writing non-portable code.

>A lot of people state the prefer MFC, but I would really like to
>know how long they have been doing object oriented programming.  When I
>first started out, my code was little more that standard C code with a
>hapzard grouping of functions into a class.  I personally believe that MFC
>will promote this style of programming.  Developers who use C will love it
>because they can tell their boss that they are using C++ but they won't see
>the benefits of using an object oriented language and their boss won't see
>any productivity increase and there will yet another "knowledgable"
>executive stating the object oriented methodolgy is just a bunch of hot
>air.

I think you are right on the money.  I listen to some industry
luminaries talk about different class libraries, and I cringe.  These
guys have been programming in C so long that any change is out of the
question.  MFC caters to that mindset perfectly.

Chris

>|Hmm, abstraction vs. efficiency.  I really didn't think you (someone who
>|likes C++ and OOP a lot, as far as I can tell) would try this argument.
>You equate abstraction with inefficiency.  I do not.

Actually, this is untrue.  When I originally said that MFC was a `paper
thin' layer over the SDK you said something along the lines of, `yeah,
so it isn't a fat and slow class library like the competition, it is
lean an mean.'

>But the source to MFC is given to you, so if you don't like this,
>you can port it.  Some people have already, more are sure to follow.

You are saying that they have ported MFC to work with other windowing
systems, like X or PM?  That, I'd love to see.  Can you provide
references?

>I am not saying that it is *impossible* to do so, I am merely stating
>that when people abstract-away efficiency then they have abstracted away
>the abstraction.  Because an abstractions that you cannot afford to use
>is an abstraction that you cannot use transparently, but rather is an
>abstraction that one has to program around -- making it a restriction rather
>than an abstraction.  The point of abstracting is to make the job as
>simple as possible -- not simpler!  Otherwise one finds after the first
>couple of weeks of programming that one has exhausted the abstraction,
>and the abstracted picture of the world is insufficient to meet real
>world needs.  At which point at time you have to say: "Okay, now how
>am I going to program around this abstraction which is getting in my way??"

Uh, I'm not sure I understand the above `paragraph,' but I'll make a go
at synopsizing it: if you write a poor class library it won't be easy to
use.  No argument there.

Now, how about addressing the point: if you agree that it is possible to
write an efficient class library that does a good job of abstracting the
problem domain, why didn't Microsoft do it?  I'll make no argument that
MFC is as fast as windows itself, but there is no way you can argue that
it does a good job of abstraction.  On the other hand, if you don't
agree, what are you using C++ for?

Chris

In article <1992Jul17.215414.15202@cmcl2.nyu.edu> checker@acf3.nyu.edu (Christopher Hecker) writes:
>
>You are saying that they have ported MFC to work with other windowing
>systems, like X or PM?  That, I'd love to see.  Can you provide
>references?

 But But But ... Windows does thing you can't POSSIBLY do
with X -- and vice versa. Applications that exploit unique features
of an OS simply aren't portable.

 Even Windows 3.1 is not compatible with 3.0. 3.1 has
lots of new features you can't get in 3.0.

>
>>than an abstraction.  The point of abstracting is to make the job as
>>simple as possible -- not simpler!  Otherwise one finds after the first
>>couple of weeks of programming that one has exhausted the abstraction,
>>and the abstracted picture of the world is insufficient to meet real
>>world needs.  At which point at time you have to say: "Okay, now how
>>am I going to program around this abstraction which is getting in my way??"

 Yes. I looked at OWL for example (Borland framework)
and decided to stick to my own classes. OWL just got in the
way.

>Now, how about addressing the point: if you agree that it is possible to
>write an efficient class library that does a good job of abstracting the
>problem domain, why didn't Microsoft do it?

 They did. Just that their 'problem domain' was ALREADY
abstracted by the Pascal interface to Windows.

>I'll make no argument that
>MFC is as fast as windows itself, but there is no way you can argue that
>it does a good job of abstraction.  On the other hand, if you don't
>agree, what are you using C++ for?
>
>Chris
>
 Its up to the USERS of the system to design
their own classes.

 If you want a portable windowing package,
you must stick to the common things. But Microsoft is try
to promote Windows features, not what it has in
common with other windowing systems: what it DOESNT
have in common.

 Why: you can bet they have their eyes on the
market currently cornered by X.



--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
 Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------

This is getting off topic for comp.std.c++...

> But But But ... Windows does thing you can't POSSIBLY do
>with X -- and vice versa. Applications that exploit unique features
>of an OS simply aren't portable.

This is clear.  Of course, applications that exploit unique features of
a computer language aren't standard either.  The point is, you weigh
your options, and make a decision.  In my opinion, the vast majority of
windowing applications could be written using features common to all
modern GUIs.

Chris

In article <1992Jul17.215414.15202@cmcl2.nyu.edu> checker@acf3.nyu.edu (Christopher Hecker) writes:
|You are saying that they have ported MFC to work with other windowing
|systems, like X or PM?  That, I'd love to see.  Can you provide
|references?

I cannot provide the references, but the people doing these kinds of ports can,
if they so choose.

|Now, how about addressing the point: if you agree that it is possible to
|write an efficient class library that does a good job of abstracting the
|problem domain, why didn't Microsoft do it?

The MFC people did do so, you just disagree with them as to what "the
job" is.

|I'll make no argument that
|MFC is as fast as windows itself,

Actually, a number of people have found that MFC runs about 20% faster
than "C" Windows API in their apps.

|but there is no way you can argue that
|it does a good job of abstraction.

I can and do argue it does a good job of abstracting.  We just disagree as
to what the job is that it should be abstracting.

I argue simply: if MFC isn't doing a good job, then why are several
other C++ compiler houses licensing it for distribution with their compilers?

|On the other hand, if you don't
|agree, what are you using C++ for?

Fast, small, cleaner, easier to use code.  Code that makes "the job" as
simple as possible -- NOT simpler.

>No.  Several other compiler vendors have already licensed MFC to work
>with their compilers.  Another compiler vendor has "vendor specific"
>"interpretations" of parts of ARM that keeps their particular compiler
>from compiling MFC, but even they now allow a compiler-switch to invoke
>the alternative "interpretation" of this issue that the other compilers
>agree to.

Could you give an example of the pointer problem?  I'm not clear on what
it is.

>The result is that C++ programs written
>in MFC can be ported easily to the large majority of machines that
>"real world" customers use GUI on around the world.

Do you mean it can easily be ported to other machines running win3 with
a compiler that supports MFC?  If that's the case, I wouldn't call it
portability with a straight face.  The classes that I have seen are
almost one to one mappings of SDK calls with little or no encapsulation.

>MFC is "paper thin"
>because that thinness results in small fast GUI programs.

Hmm, abstraction vs. efficiency.  I really didn't think you (someone who
likes C++ and OOP a lot, as far as I can tell) would try this argument.

> MFC could have
>invented its own yet-another programming paradigm in order to try to lock
>people using MFC into MFC, at the expense of making those people learn
>yet-another paradigm, and at the expense of making those people's code
>big fat and slow, but such an approach was not taken.

Huh?  Not only are people locked into MFC (by the very nature of any
class library; you write code using the classes) but they are also
locked into Microsoft Windows.  Sounds like a lose-lose situation to me.

>Its EASY to write big fat slow layers over existing code, layers that
>only do part of the job.  Its HARD to write something lean and mean.

Yeah, writing those _insane_ macros must have been HARD.  Golly, how do
you guys debug those puppies?  Again, MFC is such a thin layer that I
would hope there are no efficiency problems (besides the normal win3
ones).

>I think the people on MFC did the right thing and the hard thing,
>in deciding to make a lean and mean "real world programmer" interface.
>"Real World" programmers don't want their GUI apps burdened by fat slow code.
>"Real World" programmers don't want their GUI apps restricted to using
>only part of their GUI environment.

I can't believe you are really arguing against abstraction here.  I see
you argue about casting from const, operator., etc., but when it comes
to arguing about object oriented design you go for the `abstraction =
inefficiency' cliche.  Are you really trying to say that it isn't
possible to write good, efficient, yet abstract, class libraries?

Chris

In article <1992Jul11.202006.23342@cmcl2.nyu.edu> checker@acf3.nyu.edu (Christopher Hecker) writes:
|Do you mean it can easily be ported to other machines running win3 with
|a compiler that supports MFC?

No, I meant what I said.

|Hmm, abstraction vs. efficiency.  I really didn't think you (someone who
|likes C++ and OOP a lot, as far as I can tell) would try this argument.

You equate abstraction with inefficiency.  I do not.  One can have
a good abstraction that has good efficiency.  One can also have
abstractions that "simplify" the job to the point of not allowing the
job to be done.

|Huh?  Not only are people locked into MFC (by the very nature of any
|class library; you write code using the classes) but they are also
|locked into Microsoft Windows.  Sounds like a lose-lose situation to me.

If you write software using some kind of standard libraries then one
is locked into those standard libraries.  So choose your standards
carefully.  One is not locked into "Microsoft" Windows, one is "locked" into
MFC.  But the source to MFC is given to you, so if you don't like this,
you can port it.  Some people have already, more are sure to follow.
Further, unlike other organizations that ship source, the MFC license
allows you to make executables to distribute as you see fit.

|I can't believe you are really arguing against abstraction here.  I see
|you argue about casting from const, operator., etc., but when it comes
|to arguing about object oriented design you go for the `abstraction =
|inefficiency' cliche.  Are you really trying to say that it isn't
|possible to write good, efficient, yet abstract, class libraries?

I am not saying that it is *impossible* to do so, I am merely stating
that when people abstract-away efficiency then they have abstracted away
the abstraction.  Because an abstractions that you cannot afford to use
is an abstraction that you cannot use transparently, but rather is an
abstraction that one has to program around -- making it a restriction rather
than an abstraction.  The point of abstracting is to make the job as
simple as possible -- not simpler!  Otherwise one finds after the first
couple of weeks of programming that one has exhausted the abstraction,
and the abstracted picture of the world is insufficient to meet real
world needs.  At which point at time you have to say: "Okay, now how
am I going to program around this abstraction which is getting in my way??"