I'm trying to get an overview of application frameworks. The kind of
framework I have in mind is exemplified by MFC, OpenStep, MacApp.
Basically they provide an "empty" application shell that does nothing in
particular, but offers hooks to insert specific functionality.
My knowledge so far is somewhat skewed by the mainstream, but I take it
there are lots of frameworks floating around that were written in
languages other than a C-derivative.
I am particularly interested in pointers to frameworks that are
independent of a specific programming language.
Thanks
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
In article <······················@port203.bonn.ndh.net>,
········@acm.org (Michael Schuerig) wrote:
>
> I'm trying to get an overview of application frameworks. The kind of
> framework I have in mind is exemplified by MFC, OpenStep, MacApp.
> Basically they provide an "empty" application shell that does nothing in
> particular, but offers hooks to insert specific functionality.
Hmm, I thought the concept of *application* frameworks failed more
or less in that they provided too less generalization to be helpful
for any non-trivial applications!?
Today, it seems *domain-specific* frameworks are filling their gap.
Frank
--
Frank Westphal | "The difference between theory and practice is
········@acm.org | in theory somewhat smaller than in practice."
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Frank Westphal <··········@elmshorn.netsurf.de> wrote:
> In article <······················@port203.bonn.ndh.net>,
> ········@acm.org (Michael Schuerig) wrote:
> >
> > I'm trying to get an overview of application frameworks. The kind of
> > framework I have in mind is exemplified by MFC, OpenStep, MacApp.
> > Basically they provide an "empty" application shell that does nothing in
> > particular, but offers hooks to insert specific functionality.
>
> Hmm, I thought the concept of *application* frameworks failed more
> or less in that they provided too less generalization to be helpful
> for any non-trivial applications!?
Are you sure? I think, it is a pretty generic requirement of a lot of
applications to manage multiple documents, whatever their contents. Not
to speak of event dispatching. Comfortable handling of UI building
blocks and visual UI tools are mostly facilitated by generic frameworks.
> Today, it seems *domain-specific* frameworks are filling their gap.
Are you sure? Are those frameworks usually coded directly to the native
platform API? Say, the Windows SDK, Mac OS managers, low-level X-Window?
I don't think so.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
Michael Schuerig <········@acm.org> wrote:
>
> Frank Westphal <··········@elmshorn.netsurf.de> wrote:
>
> > Hmm, I thought the concept of *application* frameworks failed more
> > or less in that they provided too less generalization to be helpful
> > for any non-trivial applications!?
>
> Are you sure?
Nope, just my personal impression. :-)
> I think, it is a pretty generic requirement of a lot of
> applications to manage multiple documents, whatever their contents. Not
> to speak of event dispatching. Comfortable handling of UI building
> blocks and visual UI tools are mostly facilitated by generic frameworks.
Yeah, of course.
But how many code/prebuilt functionality can you really expect to be
reused from a generic application framework? Seriously, most of 'em are
either overly general, of no big help and increasing the learning curve
or more of a straight jacket and increasing the learning curve even more.
[Did your classes ever have to inherit from a common base class? Ick ;-]
> > Today, it seems *domain-specific* frameworks are filling their gap.
>
> Are you sure? Are those frameworks usually coded directly to the native
> platform API? Say, the Windows SDK, Mac OS managers, low-level X-Window?
> I don't think so.
Sorry, I do not follow you, Michael. See my reply to Keith Ray's post.
I'd like to see more domain-specific frameworks like Ralph Johnson's
User-defined Product or Accounts frameworks, Doug Schmidt's ACE etc. etc.
Frank
--
Frank Westphal | "The difference between theory and practice is
········@acm.org | in theory somewhat smaller than in practice."
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Frank Westphal <··········@elmshorn.netsurf.de> wrote:
> But how many code/prebuilt functionality can you really expect to be
> reused from a generic application framework? Seriously, most of 'em are
> either overly general, of no big help and increasing the learning curve
> or more of a straight jacket and increasing the learning curve even more.
I have the impression we're having in mind applications of vastly
differing sizes. I'm thinking of around 30 kLOC, whereas seem to be
considering 300+ kLOC. Would that explain our different judgments?
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
Michael Schuerig <········@acm.org> wrote:
>
> Frank Westphal <··········@elmshorn.netsurf.de> wrote:
>
> > But how many code/prebuilt functionality can you really expect to be
> > reused from a generic application framework? Seriously, most of 'em are
> > either overly general, of no big help and increasing the learning curve
> > or more of a straight jacket and increasing the learning curve even more.
>
> I have the impression we're having in mind applications of vastly
> differing sizes. I'm thinking of around 30 kLOC, whereas seem to be
> considering 300+ kLOC. Would that explain our different judgments?
Well, I wasn't thinking in concrete LOC numbers but in development
efforts that involve extensive business rules, many business objects
and largely distributed business processes, so you're right we had
vastly different things in mind. :-)
Application frameworks do not and cannot support the business or
domain layer, that's not their major intent. And since there are
sooo many infrastructure toolkits around, I think domain-specific
frameworks will be the next big step to take...
Frank
--
Frank Westphal | "The difference between theory and practice is
········@acm.org | in theory somewhat smaller than in practice."
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
I have to disagree pretty vigorously with Frank here. I have
to admit, i'm a little biased on this since our company produces
such frameworks, however i'll try to address the issue(s) objectively...
I think the point that frank is arguing is that you can't
package generic functionality because applications use
specific functionality. Therefore, while it's possible
to make a framework specific for making let's say telecom network
planning applications, it's not possible (or i should say
useful) to make a generic application framework that let's
say shows graphs but which can be extended to make a
network planning application. (Do i have the argument right?)
Let me say first off that there are certainly many bad application
frameworks out there. And that could lead one to conclude that
since it hasn't been successfully done (often), that it's not
possible. However, this really just speaks to the difficulty
of writing extensible, reusable code. The more general the
framework, the more extensible and flexible it needs to be.
While OO has focused on reusability in the general sense,
it hasn't differentiated in degrees of reusability. (There
should be an entire Patterns book written on "patterns for
maximal reusability.") And so I think the lack of good
application frameworks is an indication of the ability of
most companies to produce these good frameworks, not the
theoretical feasability of the task.
Example: you can think of all of an OS's graphics toolkit
as a remedial application framwork.
Example: Our company produces a product called The Dynamic
Diagram Framework (DDF)
http://www.appliedreasoning.com/products.html
which allows users to quickly and
easily assemble diagram based application (that's pretty
general). It's been used in telco (network planning,
network monitoring), manufacturing (process monitoring,
process control, configuration management), pharmaceutical
(drug synthesis), etc. There are many patterns that are
used throughout DDF to ensure that it is easy to do simple
things (no learning curve) while it is still possible
to do very complex, domain specific things (extensible,
flexible.) [I'll be happy to go into more details on
the product and/or the methods/patterns that are used.]
The point of all of this is that virtually every customer
has found the product to drastically reduce that effort
taken to develop their application. So it can be done -
but not without a lot of care and attention.
Dan
Frank Westphal wrote:
>
> Michael Schuerig <········@acm.org> wrote:
> >
> > Frank Westphal <··········@elmshorn.netsurf.de> wrote:
> >
> > > But how many code/prebuilt functionality can you really expect to be
> > > reused from a generic application framework? Seriously, most of 'em are
> > > either overly general, of no big help and increasing the learning curve
> > > or more of a straight jacket and increasing the learning curve even more.
> >
> > I have the impression we're having in mind applications of vastly
> > differing sizes. I'm thinking of around 30 kLOC, whereas seem to be
> > considering 300+ kLOC. Would that explain our different judgments?
>
> Well, I wasn't thinking in concrete LOC numbers but in development
> efforts that involve extensive business rules, many business objects
> and largely distributed business processes, so you're right we had
> vastly different things in mind. :-)
>
> Application frameworks do not and cannot support the business or
> domain layer, that's not their major intent. And since there are
> sooo many infrastructure toolkits around, I think domain-specific
> frameworks will be the next big step to take...
>
> Frank
> --
> Frank Westphal | "The difference between theory and practice is
> ········@acm.org | in theory somewhat smaller than in practice."
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
--
Daniel Drasin Applied Reasoning
······@appliedreasoning.com 111 Corning, Suite 220
(919)-851-7677 Cary, NC 27511
http://www.appliedreasoning.com
Daniel Drasin wrote:
>
> I have to disagree pretty vigorously with Frank here. I have
> to admit, i'm a little biased on this since our company produces
> such frameworks, however i'll try to address the issue(s) objectively...
Maybe this is rather a communication problem due to terminology
than a disagreement?
See my reply to Keith Ray <············@nnrp1.dejanews.com> for
my definitions of a general, horizontal and vertical framework.
> I think the point that frank is arguing is that you can't
> package generic functionality because applications use
> specific functionality.
You can do so, but often the outcome has been too general. More
than once, it has been reported that a framework supported sooo
many hook methods that the learning curve was hard to overcome.
In these cases, it would have been darn easier for the developer
if she could use only a small subset of those huge frameworks.
I don't see that developers can spend the time to learn several
thousand classes, their mechanisms and collaborations in IBM
San Francisco, for example. I'm a strong believer and I loved
to see more such efforts, however, I'm pretty convinced that
the concept of overly general *application* frameworks has more
costs than benefits and had to fail in this respect to deliver
the long-awaited large-scale reuse of code *and* design.
> Therefore, while it's possible
> to make a framework specific for making let's say telecom network
> planning applications, it's not possible (or i should say
> useful) to make a generic application framework that let's
> say shows graphs but which can be extended to make a
> network planning application. (Do i have the argument right?)
I'm afraid one of the first frameworks I have heard of was such a
generic framework. Its name was Hot Draw. ;-) It was amazingly
easy to extend and do amazing things. There's also a Java port
called JHotDraw at Erich Gamma's site.
> Let me say first off that there are certainly many bad application
> frameworks out there. And that could lead one to conclude that
> since it hasn't been successfully done (often), that it's not
> possible. However, this really just speaks to the difficulty
> of writing extensible, reusable code.
Wholeheartedly agreed (!)
> The more general the
> framework, the more extensible and flexible it needs to be.
OTOH, it's always a balancing act, too. Do I have to learn all of
the framework's abstract interactions to make effective use of it,
or is it possible to start with a small subset only? Does it scale?
How much functionality can I reuse vs. have to build? That's costs
and benefits I have to take in consideration in the first place.
> While OO has focused on reusability in the general sense,
> it hasn't differentiated in degrees of reusability. (There
> should be an entire Patterns book written on "patterns for
> maximal reusability.")
That's all very well, but doesn't reusability start with reuse?
> And so I think the lack of good
> application frameworks is an indication of the ability of
> most companies to produce these good frameworks, not the
> theoretical feasability of the task.
Agreed, bearing in mind that application frameworks in your book
would be horizontal or vertical frameworks in mine, respectively.
> Example: you can think of all of an OS's graphics toolkit
> as a remedial application framwork.
I think, I disagree. Without an inversion of control flow this
would be more of a collection of collaborating classes, wouldn't it?
> Example: Our company produces a product called The Dynamic
> Diagram Framework (DDF)
>
> http://www.appliedreasoning.com/products.html
>
> which allows users to quickly and
> easily assemble diagram based application (that's pretty
> general). It's been used in telco (network planning,
> network monitoring), manufacturing (process monitoring,
> process control, configuration management), pharmaceutical
> (drug synthesis), etc.
...which sounds impressive.
> There are many patterns that are
> used throughout DDF to ensure that it is easy to do simple
> things (no learning curve) while it is still possible
> to do very complex, domain specific things (extensible,
> flexible.)
Interesting. Is it more of a black-box or white-box framework?
> [I'll be happy to go into more details on
> the product and/or the methods/patterns that are used.]
I'm all ears. :-)
> The point of all of this is that virtually every customer
> has found the product to drastically reduce that effort
> taken to develop their application. So it can be done -
> but not without a lot of care and attention.
That's a nice conclusion to put it to an end, Dan.
Thanks for replying!
Frank
--
Frank Westphal | "The difference between theory and practice is
········@acm.org | in theory somewhat smaller than in practice."
I think we mostly agree except with our conclusions.
We both agree it's hard to to write vertical frameworks.
My position is that the solution is to teach/learn
techniques that make these kind of frameworks usable.
I think this is very doable (like i mention, this is a key
emphasis at our company, we teach internal courses on it...)
I've scattered some comments below...
Frank Westphal wrote:
>
> Daniel Drasin wrote:
>
> > I think the point that frank is arguing is that you can't
> > package generic functionality because applications use
> > specific functionality.
>
> You can do so, but often the outcome has been too general. More
> than once, it has been reported that a framework supported sooo
> many hook methods that the learning curve was hard to overcome.
> In these cases, it would have been darn easier for the developer
> if she could use only a small subset of those huge frameworks.
>
> I don't see that developers can spend the time to learn several
> thousand classes, their mechanisms and collaborations in IBM
> San Francisco, for example. I'm a strong believer and I loved
> to see more such efforts, however, I'm pretty convinced that
> the concept of overly general *application* frameworks has more
> costs than benefits and had to fail in this respect to deliver
> the long-awaited large-scale reuse of code *and* design.
>
I totally agree that there are many really bad "frameworks" out
there. I think one of the keys is that there is a difference
between a "library" and a "framework." However, about 5 years
ago it became advantageous ($s) to call any piece of junk a
"framework." In fact, often the term "framwork" became
synonomous with "unfinished" or "takes a lot of work to get
it to do anything."
In fact, most things that are called frameworks are pieces of
junk. The reason that this is more severe with horizontal
frameworks than vertical ones is because it's easier to hide
junk with fancy marketing material that talk about general
infrastructure that you don't actually have demonstrate features.
> > Therefore, while it's possible
> > to make a framework specific for making let's say telecom network
> > planning applications, it's not possible (or i should say
> > useful) to make a generic application framework that let's
> > say shows graphs but which can be extended to make a
> > network planning application. (Do i have the argument right?)
>
> I'm afraid one of the first frameworks I have heard of was such a
> generic framework. Its name was Hot Draw. ;-) It was amazingly
> easy to extend and do amazing things. There's also a Java port
> called JHotDraw at Erich Gamma's site.
>
We're very familiar with Hot Draw. (An excellent product.) But
Hot Draw demonstrates one of the problems with a flexible framework -
ease of use. There is quite a learning curve with HD (please don't
flame me on this HD lovers, i'm comparing learning HD to learning
how to use a GUI builder or something like that...) However, all
things being equal Hot Draw is still an excellent framework. In
fact what DDF (our product) provides is not only functionality
similar to HD, but also an "ease of use" layer that allows a
user to get a fully functioning application up and running on
his/her particular domain/model by defining only 7 methods.
In fact, over 50% of the framework is in these ease of use
layer.
> > The more general the
> > framework, the more extensible and flexible it needs to be.
>
> OTOH, it's always a balancing act, too. Do I have to learn all of
> the framework's abstract interactions to make effective use of it,
> or is it possible to start with a small subset only? Does it scale?
> How much functionality can I reuse vs. have to build? That's costs
> and benefits I have to take in consideration in the first place.
>
I think you can have your cake and eat it too. You can have both
extensibility, scalability, lots of functionality, and ease of
use. It just takes effort and know-how.
> > While OO has focused on reusability in the general sense,
> > it hasn't differentiated in degrees of reusability. (There
> > should be an entire Patterns book written on "patterns for
> > maximal reusability.")
>
> That's all very well, but doesn't reusability start with reuse?
>
True. But there are different levels of reuse (whole books on
this subject, so i won't go off on a tangent here...) Are you
simply reusing a couple of lines of code. Are you reusing the
fundamental design, etc.
> > There are many patterns that are
> > used throughout DDF to ensure that it is easy to do simple
> > things (no learning curve) while it is still possible
> > to do very complex, domain specific things (extensible,
> > flexible.)
>
> Interesting. Is it more of a black-box or white-box framework?
>
BOTH! That's how it can be both flexible and easy to use.
see below.
> > [I'll be happy to go into more details on
> > the product and/or the methods/patterns that are used.]
>
> I'm all ears. :-)
>
OK, i'll start, but excuse me if i leave out a lot...
There are many different levels of reuse (depending on
how you count it, 5 - 15 different levels...) What a framework
needs to do is provide mechanisms for achieving and leveraging
each of these different levels of reuse. By fortunate
coincidence, these different levels of reuse also roughly
corespond to increasing levels of skill and understanding
on the part of the developer(s). E.g. a new developer
may only feel comfortable making API calls to invoke some
utility behavior. As the developer becomes more experienced
he'll learn that he can use call backs/hooks to change the way
the the framework itself operates.
There are two main different types of framework interactions -
Application Programming Interface (API) and Framework
Programming Interface (FPI). Operationally, these are
invocation and call-backs. Each category can be further
divided in terms of the semantics of each of the classes
and methods. E.g. if you have a method that the user
defines to return the name of the application (an FPI),
this might be referred to as a "data-hook" and is
the simplest level of interaction for an FPI (very
easy to learn and understand - in fact can be easily
set up through a GUI front end.) On the other
hand if you have a method that is invoked whenever
the mouse if pressed on a certain area, this might
be referred to as a "behavior-hook" and requires more
sophistication to use (it's easier to break the application
by misusing the behavior-hook.)
There are many more breakdowns that explain who and how
the classes and methods should be used. A framework should
be built with this in mind. There should be a balance between
the various levels of interaction so that the learning curve
to move between levels is never too severe.
DDF reliese on this breakdown pretty extensively.
Again, i'll be happy to go into more details...
> --
> Frank Westphal | "The difference between theory and practice is
> ········@acm.org | in theory somewhat smaller than in practice."
--
Daniel Drasin Applied Reasoning
······@appliedreasoning.com 111 Corning, Suite 220
(919)-851-7677 Cary, NC 27511
http://www.appliedreasoning.com
Daniel Drasin wrote:
> I totally agree that there are many really bad "frameworks" out
> there.
Daniel,
This is an very significant statement. Please, enumerate some of the
characteristics that make a framework "bad."
Allyn
Allyn M. Shell escribi�:
>Daniel Drasin wrote:
>
>> I totally agree that there are many really bad "frameworks" out
>> there.
>
>Daniel,
>
>This is an very significant statement. Please, enumerate some of the
>characteristics that make a framework "bad."
Would holding MFC up as a bad example help the thread, or is this subject so
beat that we'd have to look for a "real but bad" framework to dissect?
-- Phlip at politizen dot com (address munged)
======= http://users.deltanet.com/~tegan/home.html =======
On 22 Dec 1998 14:33:46 PST, "Phlip" <·······@web.page> wrote:
>Allyn M. Shell escribio:
>>Daniel Drasin wrote:
>>
>>> I totally agree that there are many really bad "frameworks" out
>>> there.
>>
>>Daniel,
>>
>>This is an very significant statement. Please, enumerate some of the
>>characteristics that make a framework "bad."
>
>
>Would holding MFC up as a bad example help the thread, or is this subject so
>beat that we'd have to look for a "real but bad" framework to dissect?
>
MFC is OK. Rather, MFC is not OK.
As long as there are people out there stupid
enough^H^H^H^H^H^H^H^H^H^H^H^H^H foolish enough
to believe that MFC is an example of good design, it is OK to trash
it.
In article <··················@nntp.interaccess.com>,
······@interaccess.com says...
[snip]
> MFC is OK. Rather, MFC is not OK.
Yea, I try to avoid it if I can. A good alternative, one that I have been
using for years, is Zinc Application Framework http://www.zinc.com/
--
<<<<<<<<<< Blue Skies >>>>>>>>>>>
< Michael J. Tobler >
< ·······@no-spam-ibm.net >
< remove "no-spam-" when replying >
<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>
Phlip <·······@web.page> wrote in message
···············@journal.concentric.net...
>Would holding MFC up as a bad example help the thread, or is this subject
so
>beat that we'd have to look for a "real but bad" framework to dissect?
MFC get's a really bad rap, but in reality, it does it's job pretty well.
No, it's not an example of perfection in either framework or OO principles,
but it does help to speed up and make developers more productive. In that
respect, it's "good" at what it does.
Sure, better frameworks have been and still could be written, but most
frameworks fail in different ways. At least MFC doesn't pretend to be
something it's not. It advertises itself as a thin C++ wrapper around the
MFC API, along with some minimal framework classes for basic program
structure and serialization.
Millions of people get their work done a lot faster because of MFC. It's
arguable wether it could be done faster or better with another framework,
but the fact remains. MFC does have value, and it is "good" to the people
that use it to do their jobs.
>Daniel Drasin wrote:
>
>> I totally agree that there are many really bad "frameworks" out
>> there.
I think all frameworks out there are "bad" from one aspect to another. I
believe it is just as possible to build a perfect framework as it is to
create a perfect human being. A framework is built to fill a specific need,
and it may not fill needs adequately that wern't anticipated. No framework
can anticipate all the needs, so thus all frameworks are "bad". However,
the best frameworks are the ones that are elegantly designed, have no more
than you need and no less than you want! By elegance, we mean we rate the
ability to extend and reuse the framework for it's intended use. By "bad"
we may often mean it is REALLY darn tricky to make modifications to the
underpinnings of the system because it is overly complex with a high number
of interdependancies between the objects that make modification and
extensibility practically a rewrite. Thank god for the refactory browser,
and have yourself a very merry xmas. :)
Ian
----------------------------------------------------------------------------
One Accord Technologies ···@oneaccordinc.com
----------------------------------------------------------------------------
http://www.oneaccordinc.com/ian/home.html
Daniel Drasin wrote:
>
> I think we mostly agree except with our conclusions.
> We both agree it's hard to to write vertical frameworks.
> My position is that the solution is to teach/learn
> techniques that make these kind of frameworks usable.
> I think this is very doable (like i mention, this is a key
> emphasis at our company, we teach internal courses on it...)
Now, that's an interesting topic. How do you document the framework
itself and, specifically, how do you document (or teach, if you will)
the way the framework is actually (to be) used by a systems developer?
> I totally agree that there are many really bad "frameworks" out
> there. I think one of the keys is that there is a difference
> between a "library" and a "framework." However, about 5 years
> ago it became advantageous ($s) to call any piece of junk a
> "framework." In fact, often the term "framwork" became
> synonomous with "unfinished" or "takes a lot of work to get
> it to do anything."
>
> In fact, most things that are called frameworks are pieces of
> junk. The reason that this is more severe with horizontal
> frameworks than vertical ones is because it's easier to hide
> junk with fancy marketing material that talk about general
> infrastructure that you don't actually have demonstrate features.
Very well put (!)
Just curious, how do you see the appearance of component-based
development related to the development of OO frameworks?
> We're very familiar with Hot Draw. (An excellent product.) But
> Hot Draw demonstrates one of the problems with a flexible framework -
> ease of use. There is quite a learning curve with HD (please don't
> flame me on this HD lovers, i'm comparing learning HD to learning
> how to use a GUI builder or something like that...) However, all
> things being equal Hot Draw is still an excellent framework. In
> fact what DDF (our product) provides is not only functionality
> similar to HD, but also an "ease of use" layer that allows a
> user to get a fully functioning application up and running on
> his/her particular domain/model by defining only 7 methods.
> In fact, over 50% of the framework is in these ease of use
> layer.
I seem to recall an article in the Smalltalk Report called along the
lines 'Frameworks aren't build, they are grown': How many iterations
did it take to arrive at your present design? I mean, "defining only
7 [hook] methods" sounds reasonable to me. That's a good balance.
Could you please elaborate on those "ease of use layers".
> > That's all very well, but doesn't reusability start with reuse?
>
> True. But there are (whole books on
> this subject, so i won't go off on a tangent here...) Are you
> simply reusing a couple of lines of code. Are you reusing the
> fundamental design, etc.
Do you have a (book) pointer to these "different levels of reuse"?
> There are many different levels of reuse (depending on
> how you count it, 5 - 15 different levels...) What a framework
> needs to do is provide mechanisms for achieving and leveraging
> each of these different levels of reuse. By fortunate
> coincidence, these different levels of reuse also roughly
> corespond to increasing levels of skill and understanding
> on the part of the developer(s). E.g. a new developer
> may only feel comfortable making API calls to invoke some
> utility behavior. As the developer becomes more experienced
> he'll learn that he can use call backs/hooks to change the way
> the the framework itself operates.
> [...]
> There are many more breakdowns that explain who and how
> the classes and methods should be used. A framework should
> be built with this in mind. There should be a balance between
> the various levels of interaction so that the learning curve
> to move between levels is never too severe.
>
> DDF reliese on this breakdown pretty extensively.
Does this mean that your framework really adapts to the developer's
skill level in that she can increase the level of reuse in 15 steps,
as she pleases? That would be "Wow!".
Troll: How come that there are sooo many ideas widespread in the
Smalltalk community for years now that C++ or Java developers have
never heard of? ;-)
BTW, I really liked the informative DDF whitepaper at a your site!
Frank
--
Frank Westphal | "The difference between theory and practice is
········@acm.org | in theory somewhat smaller than in practice."
This is a multi-part message in MIME format.
--------------44D193C75C88A512BF384587
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I'll put my two cents in on this one - it has to do with the simplicity of
Smalltalk. The language is much, much easier to learn than either java or
C++ - and I don't want to hear any moans about 'the library' either ! You
have to learn 'the library (or libraries in the case of C++) in any event -
The simplicity of Smalltalk allows you start in on that learning curve
earlier, and to be distracted from it much less.
Frank Westphal wrote:
> Troll: How come that there are sooo many ideas widespread in the
> Smalltalk community for years now that C++ or Java developers have
> never heard of? ;-)
>
>
> Frank
> --
> Frank Westphal | "The difference between theory and practice is
> ········@acm.org | in theory somewhat smaller than in practice."
--
Talk Small and Carry a Big Class Library
<Opinions expressed are not necessarily those of ObjectShare>
--------------44D193C75C88A512BF384587
Content-Type: text/x-vcard; charset=us-ascii;
name="jamesr.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for James Robertson
Content-Disposition: attachment;
filename="jamesr.vcf"
begin:vcard
n:Robertson;James
x-mozilla-html:FALSE
org:ObjectShare, Inc.
adr:;;6510 River Run;Columbia;MD;21044;USA
version:2.1
·····················@objectshare.com
title:Senior Sales Engineer
tel;fax:410 531-0705
tel;work:410 730-6579
x-mozilla-cpt:;0
fn:James Robertson
end:vcard
--------------44D193C75C88A512BF384587--
Frank Westphal wrote:
> [ snip ]
>
> Troll: How come that there are sooo many ideas widespread in the
> Smalltalk community for years now that C++ or Java developers have
> never heard of? ;-)
Well, Smalltalk's been around longer than C++ or Java. And...
Smalltalk has a rare combination of simplicity and flexibility.
Objects, messages, classes, (single) inheritance, and blocks
allow an amazing range of expression.
Most languages have more stuff, but it's directed at a
specific problem area and doesn't provide a greater range of
expression in a general sense.
C/C++'s low level capabilities address performance issues and
the need for software to deal with the concrete details of hardware.
Java's type checking and security features address issues stemming
from the ability to transport executable code from one machine to
another. These are useful things, but the problems they solve are not
general ones and the problems they introduce are (general).
Beyond the language, Smalltalk systems have traditionally had
reflection, incremental compilation, image paradigm, rich class
libraries, and integrated interactive tool sets; all of which facilitate
exploratory or experimental programming.
Simple language, great expressiveness, few constraints,
experiment-friendly environment. That's why.
FWIW:
* Multiple inheritance (like many things) does increase the general
range of expression, but IMO the accompanying increase in complexity isn't
worth it.
* Classes are not part of the Smalltalk language but they have been
an integral part of Smalltalk systems for (at least) as long as Smalltalk
has
been unleashed from the research labs. There's not much support for
implementing systems without classes. On the one hand
classes could be seen as an unnecessary constraint. On the other hand
they greatly aid the organization of a system and overall seem to
be a simplifying force.
...Mike
Michael Schuerig wrote in message
<······················@port245.bonn.ndh.net>...
>I have the impression we're having in mind applications of vastly
>differing sizes. I'm thinking of around 30 kLOC, whereas seem to be
>considering 300+ kLOC. Would that explain our different judgments?
It also depends on WHAT the application is doing. For a graphics editing or
gaming program where the only thing that the framework MIGHT handle is
menuing and input device event management, the framework may well be too
much overhead. For applications that look more like a standard MDI sort
o'thing, it might look a bit better. Also, for those apps where you're
trying to look like a prior domain object (e.g., medical EMR's that sort of
want to look like a chart, etc.) or something completely different, the app
framework may actively get in the way.
The tool should fit the need. When it doesn't, don't blame the tool, blame
the fool who chose the tool. In most cases there are more suitable
replacements available...
--
Frank A. Adrian
First DataBank
············@firstdatabank.com (W)
······@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
Michael Schuerig wrote:
>
> I'm trying to get an overview of application frameworks. The kind of
> framework I have in mind is exemplified by MFC, OpenStep, MacApp.
> Basically they provide an "empty" application shell that does nothing in
> particular, but offers hooks to insert specific functionality.
>
> My knowledge so far is somewhat skewed by the mainstream, but I take it
> there are lots of frameworks floating around that were written in
> languages other than a C-derivative.
>
> I am particularly interested in pointers to frameworks that are
> independent of a specific programming language.
Michael:
Take a look at the IBM San Francisco Project.
URL: http://www.ibm.com/Java/Sanfrancisco/
--
Alan Gunderson
Spring Street Software
Eagle River, Alaska
e-mail: ··········@acm.org