OO design (was Re: StarOffice 5.2: no OS/2 version?) 
Author Message
 OO design (was Re: StarOffice 5.2: no OS/2 version?)


<snip -- the parts I can't comment on>

Quote:
>The problem, ultimately, is one of managing complexity.  These
>days, both the programmers and the users are drowning in complexity. One
>obvious symptom: we keep hearing complaints that people can't find things in
>the on-line documentation, because the documentation has grown too big and
>too complex.

I hear this and see it too. The problem isn't complexity per se, but the
clumsy design of the writing tools.  -- Most software writers are expected to
use MS word and is simply the most inefficient tool available (with the
exception of Word perfect which is used much anymore).  

What the writer needs is a structured document tool that starts with an
outline and automatically handles everything from numbering to
cross-referencing across sections, along with a few other things so the writer
can focus on the task of writing -- not on making the software work. There
isn't one current word processor that does this and produces files that can be
run through Robo whatever to produce the help files.  The closest is probably
Framemaker and it has some design flaws that inhibit efficiency.

Quote:
>Clearly, big monolithic programs are not the answer.  Two of my
>most-hated programs are StarOffice and Netscape, which bring
>misery into an otherwise well-behaved system, and their faults
>are all because they're TOO BIG.  We do need small components
>that plug together nicely, but we need to do it right.  And,
>frankly, I'm not sure that we have enough good programmers to
>do it right.

This has also carried over to writing tools.  We need programmers who first
study how writers work, or should be working or want to work -- who then
develope the tools.  Instead we get something that was once good enough for
writing letters to Mommy -- and should have stopped there rather then adding
on everything someone in marketing think is cool.

--
-----------------------------------------------------------

-----------------------------------------------------------



Sat, 14 Dec 2002 03:00:00 GMT  
 OO design (was Re: StarOffice 5.2: no OS/2 version?)
Warning: I've cross-posted this from an OS/2 group to a Modula-2
group, because there's an issue here that's of interest to both groups.
I'd suggest, though, that followups if any be posted only to your
"home" newsgroup, because it's possible that this discussion could
head off in two different directions.

Quote:

>Did anyone really, I mean *really*, give the initial concept of OS/2 a try ?
>I mean a *real* try -- you know, apps built of smaller blocks that should all
>work well together so the user could have all the advantages of integrated
>programs but total customization to his/her individual needs ?

>Seems like we've totally lost the REAL point of OS/2 and object-oriented
>programming. I like fortran fine, but there are better methods of designing
>a versatile desktop. Star Office and MS Works (does it really ?) are popular
>with programmers becasue they are a lot less trouble - "buy our program
>or go jump" - they don't have to worry about standards or interoperatibility
>at all. However, in the last five years we, as users, have gone seriously
>backwards in capabilities while places like Microsoft rake in the shekels.
>Even sophisticated OS/2 users are now happy to get monolithic single-threaded
>single-purpose apps instead of the "co-operative customizable desktop workspace"
>paradigm we were e{*filter*}d about five years ago. [...]

While I agree with every word that h?rad has said above, I believe
that the "object model" approach to design has been hurt by people
failing to address the drawbacks.  For a number of years now we've
been hearing about the virtues of object-oriented programming -- to
the point where it's the only approach taught in some CS departments
-- but everyone's keeping quiet about one significant problem.
When the approach goes wrong, it can go disastrously wrong.  I suspect
that a number of people have been badly bitten by project failures,
and have quietly snuck back into monolithic design because that's
the only other thing they know.

Windows developers know all about project failures.  Sooner or later,
every Windows developer is going to come across a thing called MFC
(Microsoft foundation classes).  At first it looks attractive enough;
by the time you've found out how bad it is you're committed.  Use
MFC and you'll learn a lot about cost overruns and time overruns
and mysterious bugs which are never tracked down.  I suspect that
some companies have gone into bankruptcy because of MFC.

That's at the programmer level.  At the user interface level OS/2
users have seen more of a mixed bag.  The "component" approach
has worked spectacularly well in things like OpenDoc and IBM
Works.  (Both of these fell victim to the IBM disease of
abandoning successful projects, but that's a management problem
rather than a software design problem.)  But we've also seen some
examples of grotesquely bad user interface design: things like
Ultimail Lite and NR/2 and VisualAge C++.  Ultimail, all by
itself, could stand as a case study in why one shouldn't use
object-oriented approaches to design.  After experiencing something
like that, one tends to run screaming back to a more traditional
approach.

In my advanced programming classes, I let the students choose
their own preferred programming language and programming paradigm.
What I've found, over and over again, is that the least readable
software comes from those using an object-oriented approach.
In addition, I often get the impression that those students don't
fully understand what their own code is doing.

The problem, ultimately, is one of managing complexity.  These
days, both the programmers and the users are drowning in complexity.
One obvious symptom: we keep hearing complaints that people can't
find things in the on-line documentation, because the documentation
has grown too big and too complex.

The notions of object inheritance and reusable components were
supposed to help in managing complexity, but it looks to me as
if they've failed in that goal.  A big problem with inheritance is
that you pick up all the detritus of inherited properties that you
didn't need and/or didn't know you were getting.  After three or
four layers of inheritance, programmers simply don't know the
properties of the objects they create.  They can't predict what
will happen in scenarios they haven't yet tested.  Software
design turns into an exercise of "let's try this, and see what
happens".  The OO philosophy tries to manage complexity by
hiding details, but it hides them in the wrong way.  The hidden
things are going to reappear some time, it's just that the
programmer didn't realise that.

Clearly, big monolithic programs are not the answer.  Two of my
most-hated programs are StarOffice and Netscape, which bring
misery into an otherwise well-behaved system, and their faults
are all because they're TOO BIG.  We do need small components
that plug together nicely, but we need to do it right.  And,
frankly, I'm not sure that we have enough good programmers to
do it right.

--

See http://www.*-*-*.com/ for OS/2 information and software



Sun, 15 Dec 2002 03:00:00 GMT  
 OO design (was Re: StarOffice 5.2: no OS/2 version?)

Quote:

><snip -- the parts I can't comment on>

>>The problem, ultimately, is one of managing complexity.  These
>>days, both the programmers and the users are drowning in complexity. One
>>obvious symptom: we keep hearing complaints that people can't find things in
>>the on-line documentation, because the documentation has grown too big and
>>too complex.

>I hear this and see it too. The problem isn't complexity per se, but the
>clumsy design of the writing tools.  -- Most software writers are expected to
>use MS word and is simply the most inefficient tool available (with the
>exception of Word perfect which is used much anymore).  

>What the writer needs is a structured document tool that starts with an
>outline and automatically handles everything from numbering to
>cross-referencing across sections, along with a few other things so the writer
>can focus on the task of writing -- not on making the software work. There
>isn't one current word processor that does this and produces files that can be
>run through Robo whatever to produce the help files.  The closest is probably
>Framemaker and it has some design flaws that inhibit efficiency.

LaTeX?


Sun, 15 Dec 2002 03:00:00 GMT  
 OO design (was Re: StarOffice 5.2: no OS/2 version?)

[...]

Quote:
> Windows developers know all about project failures.  Sooner or later,
> every Windows developer is going to come across a thing called MFC
> (Microsoft foundation classes).  At first it looks attractive enough;
> by the time you've found out how bad it is you're committed.  Use
> MFC and you'll learn a lot about cost overruns and time overruns
> and mysterious bugs which are never tracked down.  I suspect that
> some companies have gone into bankruptcy because of MFC.
[...]
> In my advanced programming classes, I let the students choose
> their own preferred programming language and programming paradigm.
> What I've found, over and over again, is that the least readable
> software comes from those using an object-oriented approach.
> In addition, I often get the impression that those students don't
> fully understand what their own code is doing.

I like the way you are relating some of the problems with OO programms
to the "human aspect": This is exactly the experience I have from our
company. We are developing software for all kinds of customers, and our
programmer's team is rather heterogeneous: I am originally a scientist,
for example. But even with those that have learned or studied IT to a
certain extent I get the impression: Most of them simply don't
*understand* the concept of OO programming, not to mention the possible
dangers!

One of the "advantages" of the MFC classes in this context is the fact
that they are so badly designed that you soon give it up trying to
really construct any sophisticated class tree using them. Most of my
colleagues who are working with them are using them just taking what the
"wizards" of the VisualStudio produce (i.e., one level of inheritance
from the MFC base classes) and adding some code. They do never use any
container classes, just simple arrays (or even worse: pointer arrays),
don't know what "virtual" or "static" really means, etc.

But all this code goes of course as "OO programming" these days!

[...]

Quote:
> The notions of object inheritance and reusable components were
> supposed to help in managing complexity, but it looks to me as
> if they've failed in that goal.  A big problem with inheritance is
> that you pick up all the detritus of inherited properties that you
> didn't need and/or didn't know you were getting.  After three or
> four layers of inheritance, programmers simply don't know the
> properties of the objects they create.  They can't predict what
> will happen in scenarios they haven't yet tested.  Software
> design turns into an exercise of "let's try this, and see what
> happens".  The OO philosophy tries to manage complexity by
> hiding details, but it hides them in the wrong way.  The hidden
> things are going to reappear some time, it's just that the
> programmer didn't realise that.

You call it "managing complexity", I would call it simply abstraction.
The OO paradigm is one step more abstract than the "structured" paradigm
etc., each abstraction layer adding more power to the programming tools,
but also making them more dangerous *and* safer at the same time: If I
don't have a type-aware compiler I will make many errors because I
forgot how I defined my data in the first place, etc.

For me one point that comes in in this place is again the "human
aspect": How far do developer's tools (or any other program) have to
adapt to the *habits* of the developer (user) and how much is the latter
able and ready to *learn* something new and change his/her habits in
order to master a more evolved concept?

A good example is simpe text writing in my eyes, but I think it applies
to programming as well:

If you write by hand or with a typewriter, you just have to ask
yourself: Do I want to have this bold, on a new line, or whatever, and
just do it.

Now one user interface philosophy is to simply let the user do "like he
is used to". Ok, so you mark a piece of text and press the "bold"
button, and your text is in bold face.

If you are strict now, the user shouldn't be asked to learn anything
new. But then he will never understand the concept of "styles" for
example, because that is an abstraction with no "physical" meaning if
you are writing by hand, except in your head: You decided how to do all
your titles all in the same way.

Now "somehow" all users of a text program get an idea of styles anyway,
but most of the time they just use them "intuitively", not in a
systematic way. The result is that you are getting documents as an
editor with e.g. bold titles, nice on paper, but some of them are
created by just making "plain text" bold face, others created using a
"title" style, so at this level the text is a pure mess, and you will
have to reformat everything as an editor from scratch.

If the author had understood the concept of "styles" in the first place,
he would have produced an equally nice document on paper and,
furthermore, you would have much less work as an editor! But we are told
that programs have to work "intuitively", learning and thinking being
almost forbidden!

And now back to the OO design issue: I don't think the OO paradigm is
"intuitive", but it needs some real learning in the first place and only
*then* it becomes one of the most powerful programming concepts
available these days!

Greetings,
Cornelis

--

Author of "PmAs - Astronomy for the Presentation Manager"
New version 1.11 at http://home.datacomm.ch/cbockem

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 15 Dec 2002 03:00:00 GMT  
 OO design (was Re: StarOffice 5.2: no OS/2 version?)

Quote:

> What the writer needs is a structured document tool that starts with an
> outline and automatically handles everything from numbering to
> cross-referencing across sections, along with a few other things so the writer
> can focus on the task of writing -- not on making the software work. There
> isn't one current word processor that does this and produces files that can be
> run through Robo whatever to produce the help files.

I'm afraid I can't speak to "Robo" but DeScribe certainly can perform
what you are describing. I have used it with a handful of macros to
produce structured HTML pages, and have to believe there isn't any
organizational format that it cannot be tailored to handle.

--
Good luck,
    Buddy      



Sun, 15 Dec 2002 03:00:00 GMT  
 OO design (was Re: StarOffice 5.2: no OS/2 version?)

Quote:
> Use
> MFC and you'll learn a lot about cost overruns and time overruns
> and mysterious bugs which are never tracked down.  I suspect that
> some companies have gone into bankruptcy because of MFC.

ROFLMAO!   (...and our two top "technology officers" - hired away from CheckFree, but far from "free", are none other than Mike Oliver and Fred Pandolfi - I will, for the sake of my short-term employment, refrain from commenting on the status of either our project schedule or financial condition..)

=Dwight=
X1=L, X2=L & the domain is phonetic



Sun, 15 Dec 2002 03:00:00 GMT  
 OO design (was Re: StarOffice 5.2: no OS/2 version?)

Quote:

>> What the writer needs is a structured document tool that starts with an
>> outline and automatically handles everything from numbering to
>> cross-referencing across sections, along with a few other things so the writer
>> can focus on the task of writing -- not on making the software work. There
>> isn't one current word processor that does this and produces files that can be
>> run through Robo whatever to produce the help files.
>I'm afraid I can't speak to "Robo" but DeScribe certainly can perform  what
>you are describing. I have used it with a handful of macros to  produce
>structured HTML pages, and have to believe there isn't any  organizational
>format that it cannot be tailored to handle.

I looked at Describe years ago. It failed the writer test (mine ). -- I don;t
remember why, but I do remember spending hours on the phone with their support
people about different things.

You point one of the things I was speaking of in general. -- If the writer has
use macros to accomplish something simple, like exporting a file into an HTML
file, then the program fails as a writers tool.   The writer should not have
to spend time with basic {*filter*}that the machine should be able to do
automatically.

Now I know that that running a macro doesn't seem like a big deal, but if you
had do it all the time, during a crush period -- say making final check on one
hundred 10-30 pages documents going out a CD next week that all suppose to be
5-Star documents (no errors) -- Having to{*filter*}around with manual tasks
(macros) to accomplish  simple formatting is pure bullshit.

I don't remember if Describe had an underlying structural mode or not, but it
doesn't matter since it has become, lets say, a personal use product, that is
not accepted in the corporate world. -- In fact there are only two programs
that are; Word [which sucks for everything] and FrameMaker, mainly because it
can read Word files.

Going back; when I say structured mode I want I program that works as the
writer thinks and doesn't make me do busy-work to keep up with me. For
example, when starting a new project in the old days (before the PC) the
writer would go over blue prints, vendor and engineering data and then begin
to develope outlines of systems and the major things that the eventual reader
will have to know.  On paper there would be a lot of erasing, scratching out
and such before it was ready to be typed.  -- During this process the writers
head is filled the inter-relationships of the systems, the human factors, the
potential emergencies, etc. that have to be addressed -- and the paper outline
is a distraction from that task, and busy-work maker because he has to change
gears to keep the even flow of concepts onto the paper.

Enter the world of the PC.  It essentially makes the writer do the same thing
on the screen. He may create the outline in his head, but its just a bunch of
lines on the screen until he applies styles to them.  -- Again diverting his
attention from the real work to be done. And if it changes along the way, and
it always does, it becomes a set of manual tasks that require manual checking
and rearranging, formatting, etc.

On the other hand a real writing tool would let the writer think! And work
with a hierarchical structure from step one (not something added as a style
after), permit global formatting -- where one can assign the formats for all
levels once (and not for each level as it is with the style approach),  allow
formatting changes to ripple through the document when made (and not have to
applied as with styles), allow a collapsible structure with just a couple of
key strokes (not 15 mouse clicks), etc.

The old Lotus Manuscript came close to the idea, and FrameMaker +SGML (with
its rules) sort of accomplishes the same thing from a different direction, but
neither are perfect.  -- What the writing world needs is something like
Manuscript for a front-end,  and FM+SGML for the second-half of the work, and
hundred other things.  

-- People talk about the next Killer Application, and no real gains in
efficiency with the PC -- and yet fail to see that the basic tool keeps people
working in the same way it has always been done, e.g., the electronic
typewriter, instead of making a tool that becomes integral to the thoughts of
the writer. (This also makes me wonder if programmers and marketing
departments ever take a look at Lotus 123 and realize that it wasn't a killer
app. because it was a spread sheet. It was a killer app. because it allowed
people to make changes and play with "what ifs," without having to redo all
the busy work every time. -- It allows them to simplify the way they had
always worked.

Going beyond the tools, the other major problem with Word and such, is that
they have created the  illusion that anyone with a PC word processor can
write. They can't and management in too many companies, refuses to think about
that idea. Its probably a reflection of general trends of society as a whole,
but the shear number of those who have the same limitations sometimes make me
think that the line that goes: "the most common element in the universe is
stupidity" -- is on the mark.

-----------------------------------------------------------

-----------------------------------------------------------



Sun, 15 Dec 2002 03:00:00 GMT  
 OO design (was Re: StarOffice 5.2: no OS/2 version?)

Quote:

> While I agree with every word that h?rad has said above, I believe
> that the "object model" approach to design has been hurt by people
> failing to address the drawbacks....
> When the approach goes wrong, it can go disastrously wrong.

Even when it doesn't go wrong, I've got reservations. As you say later
the proliferation of properties can be undesirable, but the real thing I
see as a problem is the difficulty of predicting or tracking the flow of
control- anybody who doesn't believe me should try single-stepping a
Delphi program that uses Winsock.

Quote:
> At the user interface level OS/2 users have seen more of a mixed bag.

Yes, like OS/2 utilities that died with a whimper about a container error.
What does that mean to the average user?

Quote:
> The problem, ultimately, is one of managing complexity.

Yes, I agree that's a problem but I'd like to point the finger at one or
two concrete issues.

i)      When Xerox released an early version of Smalltalk for review
('78?) I believe it was HP that pointed out that it was far too easy to
make underlying changes that broke subsequently-installed software.

ii)     When the DLL concept was first mooted in the early 80s nobody
pointed out to MS that the DLL format lacked (a) version and dependency
management and (b) exposed descriptions of the entry points.

-- Mark Morgan Lloyd

--
-- [Opinions above are the author's, not those of his employers or
colleagues]



Sun, 15 Dec 2002 03:00:00 GMT  
 OO design (was Re: StarOffice 5.2: no OS/2 version?)


Quote:
> LaTeX?

LyX? http://www.lyx.org/

-- Mark Morgan Lloyd

--
-- [Opinions above are the author's, not those of his employers or
colleagues]



Sun, 15 Dec 2002 03:00:00 GMT  
 OO design (was Re: StarOffice 5.2: no OS/2 version?)

Quote:

> What the writer needs is a structured document tool that starts with an
> outline and automatically handles everything from numbering to
> cross-referencing across sections, along with a few other things so the writer
> can focus on the task of writing -- not on making the software work. There
> isn't one current word processor that does this and produces files that can be
> run through Robo whatever to produce the help files.  The closest is probably
> Framemaker and it has some design flaws that inhibit efficiency.

XML-based solution perhaps?

J.Neuhoff



Tue, 24 Dec 2002 03:00:00 GMT  
 OO design (was Re: StarOffice 5.2: no OS/2 version?)

Quote:


>> What the writer needs is a structured document tool that starts with an
>> outline and automatically handles everything from numbering to
>> cross-referencing across sections, along with a few other things so the writer
>> can focus on the task of writing -- not on making the software work. There
>> isn't one current word processor that does this and produces files that can be
>> run through Robo whatever to produce the help files.  The closest is probably
>> Framemaker and it has some design flaws that inhibit efficiency.

>XML-based solution perhaps?

XML has a lot of possibilities, but is not yet a mature solution. In
other words, there is a real dearth of good tools for it yet:). I
think{*filter*}would be a better place to start from. You can go from it
to .pdf or something for a solution that needs to be implemented
now...

--
----------------------------------------------------------
* Jack Troughton              jake at jakesplace.dhs.org *
* http://www.*-*-*.com/     ftp://jakesplace.dhs.org *

----------------------------------------------------------



Wed, 25 Dec 2002 03:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. StarOffice 5.2

2. Clipper 5.2 and OS/2

3. clipper 5.2 apps and os/2

4. Building on IRIX 5.2 and Sun OS 4 -- problems and solutions

5. Which version of 5.2?

6. Corruption Detected Error on NTX with 2 versions of Clipper 5.2

7. Version 5.2 no longer links

8. dBase Version With Clipper 5.2

9. Looking for Version 5.2 Clipper

10. ANNOUNCE: VAD 5.2 (Visual Ada Developer) version Leonid Dulman

11. Gnat 3.10p (.rpm version) + Redhat 5.2 = Not working (I'm new to this)

12. Bug in expectk version 5.2 ?

 

 
Powered by phpBB® Forum Software