Re: What is wrong with OO ?

Re: What is wrong with OO ?

[Ell]

Ian Joyner (i.joyner@acm.org) wrote:

: What made me think of this was that Bill Gates stated in his book that
: Boeng designed the entire 777 aircraft using one gigantic electronic
: document! Physical engineering disciplines have made good use of
: computing technology, it's about time software engineers followed
: the same path... better and more productive languages and environments,
: and stop defending archaic 25 year old languages from another era.

I find some 25 year languages like C++ very useful even today.  A lot of
following a good OO paradigm is in how tools are used and approached.
 
: And this gets back to a point ...  made quite a while ago
: in this thread, that analysis and design is programming, and that
: these should not be done by different groups.

Because Boeing had a super diagram doesn't mean it's highest level was
predicated on a single, or even specific set of, technology, i.e. on one
or more specific languages, or distribution technologies in our case.

For more along these lines one should read Constantine's end column in
the latest Object magazine.  He advocates _delaying_ implementation as
much as possible.

Elliott

Re: What is wrong with OO ?

[Ian Joyner]

Ell wrote:
> 
> Ian Joyner (i.joyner@acm.org) wrote:
> 
> : What made me think of this was that Bill Gates stated in his book that
> : Boeng designed the entire 777 aircraft using one gigantic electronic
> : document! Physical engineering disciplines have made good use of
> : computing technology, it's about time software engineers followed
> : the same path... better and more productive languages and environments,
> : and stop defending archaic 25 year old languages from another era.
> 
> I find some 25 year languages like C++ very useful even today.  A lot of
> following a good OO paradigm is in how tools are used and approached.

And people can still drive model T Fords, and fly WWI planes. 

The most important tool is the compiler. The problem with C and C++
tools is that many of them are to make up for language deficiencies.
With a better designed language, which takes into account what modern
computers can do, the need for many of these tools simply disappears.
Also as I wrote in another thread, the need for most style rules
that programmers are encumbered with also disappears.

> : And this gets back to a point ...  made quite a while ago
> : in this thread, that analysis and design is programming, and that
> : these should not be done by different groups.
> 
> Because Boeing had a super diagram doesn't mean it's highest level was
> predicated on a single, or even specific set of, technology, i.e. on one
> or more specific languages, or distribution technologies in our case.

Correct. It would be using the compound document paradigm.

> For more along these lines one should read Constantine's end column in
> the latest Object magazine.  He advocates _delaying_ implementation as
> much as possible.

Exactly, the point! In fact the implementation should be left up to
the compiler. But too much with C++ you are forced to think of how
to implement things early. It is rather like flying the WWI plane,
where you must think to go left, I must adjust the tail to do so.

My paper at:

http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html

explains how C++ burdens the programmer with 'early implementation'
problems, and explains how good OO languages should remove this
burden from the programmer.
------------------------------------------------------------------------
Ian Joyner       | "for when lenity and cruelty play | All opinions are
Internet email:  |  for a kingdom, the gentler       | personal and are
i.joyner@acm.org |  gamester is the soonest winner"  | not Unisys
                 |       William Shakespeare Henry V | official comment
------------------------------------------------------------------------

Re: What is wrong with OO ?

[Robert C. Martin]

In article <32C88BE0.7F2B@acm.org>, i.joyner@acm.org wrote:

> The most important tool is the compiler. The problem with C and C++
> tools is that many of them are to make up for language deficiencies.
> With a better designed language, which takes into account what modern
> computers can do, the need for many of these tools simply disappears.
> Also as I wrote in another thread, the need for most style rules
> that programmers are encumbered with also disappears.

This is undoubtedly true.  As engineers we need a CAE system that combines
the CASE tool, editor, compiler, documentation tool, debugger, test plan
generator, simulator, etc into a single seamless facility.  We should be 
able to browse through our design diagrams, focusing into certain points,
double clicking on an adornment or icon to bring up a stretch of "source code"
which we could edit.  Then build and debug in the same environment.

Such a system maintain traceability between requirements, use cases, design
artifacts and modules.  It would maintain lists of programmer and analysts
notes that were germane to each other.  It would facilitate communcations
between engineers working on the project regardless of their location.  It would
facilitate configuration management and version control.  It would facilitat
project management.

No such tool exists today.  I think it will be a long time before such
a tool does exist.  But I can dream.

> Exactly, the point! In fact the implementation should be left up to
> the compiler. But too much with C++ you are forced to think of how
> to implement things early. It is rather like flying the WWI plane,
> where you must think to go left, I must adjust the tail to do so.

Of course, after a little practice, the notion of turning right immediately
translates into the corresponding pressures and velocity profiles for the
stick and the pedals.  No thought is required.  The appropriate responses become
wired into the brain.  

So it is with any computer language.  Once you have mastered it, its use
becomes wired in, and the struggle with the layer between design and 
implementation disappears.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Tom Bushell]

On Tue, 31 Dec 1996 09:28:08 -0600, rmartin@oma.com (Robert C. Martin)
wrote:

>This is undoubtedly true.  As engineers we need a CAE system that combines
>the CASE tool, editor, compiler, documentation tool, debugger, test plan
>generator, simulator, etc into a single seamless facility.  We should be 
>able to browse through our design diagrams, focusing into certain points,
>double clicking on an adornment or icon to bring up a stretch of "source code"
>which we could edit.  Then build and debug in the same environment.

Exactly.  And since we're dreaming, let's take it a bit further.  You
should be able to edit the system at whatever level of abstraction you
are viewing it.  For example, adding a new argument to a method call
would propagate through the whole system automatically, or create a
map of errors where more detailed fixing was required.

If the system was runnable before the high level change, and nothing
was broken by the change, it should still run - immediately!


>Of course, after a little practice, the notion of turning right immediately
>translates into the corresponding pressures and velocity profiles for the
>stick and the pedals.  No thought is required.  The appropriate responses become
>wired into the brain.  

Seems to me this kind of eye/body type of learning comes much more
naturally to humans than textual "book learning" does.  Presumably the
parts of our brain that deal with written language evolved much more
recently, and are less advanced.


>So it is with any computer language.  Once you have mastered it, its use
>becomes wired in, and the struggle with the layer between design and 
>implementation disappears.

Very true.  But my experience has been that "wiring in" to certain
languages is easier.  Smalltalk especially, Forth, and to a certain
extent Visual BASIC seem much more natural and comfortable than C/C++,
at least for me.  I believe this is because they were concieved as
_personal_ computer languages, so are highly interactive and open.
C/C++ are FORTRAN descendants, which evolved in a mainframe batch
environment.  Of course, the supporting development environment can
have a very large effect too - I'll take a GUI over a command line any
day.

It seems much easier to get into a state of flow when using these
languages - you just code and test, and everything seems to work.  I
can hardly ever achieve this happy state in C, even though it's one of
my most familiar languages - it's just too much like work.

Interestingly enough, this can often be done without a lot of up front
design, and rarely results in a mess.  

Many years ago, I read a very short article by a PC game developer.
He talked about programming as "jamming", using the term the same way
musicians do.  I thought it was a very good analogy - implies a very
smooth and natural process of creation.

IMO, the more "sensual" (ie see/hear/smell/touch/taste) we can make
our development tools, the more efficient and creative the development
process will become.  Visual programming is just a big step in this
direction.

-Tom


----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Thaddeus L. Olczyk]

rmartin@oma.com (Robert C. Martin) wrote:

>In article <32C88BE0.7F2B@acm.org>, i.joyner@acm.org wrote:

>This is undoubtedly true.  As engineers we need a CAE system that combines
>the CASE tool, editor, compiler, documentation tool, debugger, test plan
>generator, simulator, etc into a single seamless facility.  We should be 
>able to browse through our design diagrams, focusing into certain points,
>double clicking on an adornment or icon to bring up a stretch of "source code"
>which we could edit.  Then build and debug in the same environment.

>Such a system maintain traceability between requirements, use cases, design
>artifacts and modules.  It would maintain lists of programmer and analysts
>notes that were germane to each other.  It would facilitate communcations
>between engineers working on the project regardless of their location.  It would
>facilitate configuration management and version control.  It would facilitat
>project management.

>No such tool exists today.  I think it will be a long time before such
>a tool does exist.  But I can dream.

What? You mean emacs can't handle all this ? :)
---------------------------------------------
Thaddeus L. Olczyk

Net boy, net girl
Send your impulse 'round the world
Put your message in a modem
And throw it in the Cyber Sea

Case Tools for OO (was Re: What is wrong with OO ?)

[Mark Smith]

> rmartin@oma.com (Robert C. Martin) wrote:
> 
> >In article <32C88BE0.7F2B@acm.org>, i.joyner@acm.org wrote:
> 
> >This is undoubtedly true.  As engineers we need a CAE system that combines
> >the CASE tool, editor, compiler, documentation tool, debugger, test plan
> >generator, simulator, etc into a single seamless facility.  We should be
> >able to browse through our design diagrams, focusing into certain points,
> >double clicking on an adornment or icon to bring up a stretch of "source code"
> >which we could edit.  Then build and debug in the same environment.
I will probably get flamed for doing this, but we are beginning to use
Rational ROSE/C++,
and I _like_ it. If you buy Apex, ROSE, and SoDA, you get the case tool,
editor, compiler, documentation,debugger all in one. The test plan
generator could be wangled from SoDA & use cases. The browse through
diagrams, double click to code works. 
And it's SOOOO quick for doing design scratchings. 

However, you need to put a fairly disciplined process around it. We've
had problems with 
multiple solutions to the one problem, and how to combine them all into
the 'repository' model. It's a process thing, not a tool thing
necessarily.

It also does change management, which is very impressive.

> 
> >Such a system maintain traceability between requirements, use cases, design
> >artifacts and modules.  It would maintain lists of programmer and analysts
Ah, ok. Traceability is a process thing with 3.0.6. I don't know about
4.0.

> >notes that were germane to each other.  It would facilitate communcations
> >between engineers working on the project regardless of their location.  It would
> >facilitate configuration management and version control.  It would facilitat
> >project management.
I don't think so email, and ( erk) MS-Project?

> 
> >No such tool exists today.  I think it will be a long time before such
> >a tool does exist.  But I can dream.
> 
Give it a try...

Anybody else got comments?

APEX - WAS: Case Tools for OO (was Re: What is wrong with OO ?)

[Nigel Tzeng]

In article <32CC40F6.1FBC@ssd.neca.nec.com.au>,
Mark Smith  <mark@ssd.neca.nec.com.au> wrote:

[snip]

>I will probably get flamed for doing this, but we are beginning to use
>Rational ROSE/C++,

Okay, we aim to serve ;)

>and I _like_ it. If you buy Apex, ROSE, and SoDA, you get the case tool,
>editor, compiler, documentation,debugger all in one. The test plan
>generator could be wangled from SoDA & use cases. The browse through
>diagrams, double click to code works. 
 
[snip]

I like Rose too...but Apex is really horrid.  It literally cost us a
man year of development time.  The underlying paradigm of Apex is
flawed (imports) and I discovered today that the source code control
software (RCS) can't do tags because of the utterly braindead Apex
layer between us and RCS.  

Multiplatform development is possible but hardly fun and requires
massive duplication of source code...and some fancy rsh script
development...which if you have to write you could simply be using
normal makefiles.

The debugger may or may not be thread safe...I don't recall but there is
a reason we aren't using it.  That's sort of okay since GDB isn't really
supporting threads.  Sun's IDE does...

The editor isn't any better than emacs and not as good as lemacs.
Sniff++ has a much better editor and allows browsing of inheritance
trees.

And Apex is very expensive.

SoDA is based on Framemaker (?) and isn't even vaguely intuitive.
Powerful perhaps but not easy to use.  There are some very amusing
artifacts when you generate using SoDA as well.  You should also plan
on running SoDA overnight when trying to generate a new document.

[snip]

>However, you need to put a fairly disciplined process around it. We've
>had problems with 
>multiple solutions to the one problem, and how to combine them all into
>the 'repository' model. It's a process thing, not a tool thing
>necessarily.
>
>It also does change management, which is very impressive.

It does change management poorly...see the lack of TAG above.  DONT
use Rose with CVS.  Rose files cannot be merged and CVS does not lock.
You will clobber each other and end up with a mess (been there...done
that).

Oh, and Rose and Apex does not seem to really mesh together for CMVC.  I used
Rose to make my properties file (.prp) file writable and Apex simply ignored
it so when I did a save it failed...too bad I was exiting at the time.

Whee.

Don't select Apex as your CM tool...SCCS has more features as a
version control tool.  There's also no built in problem report tracking
or metrics tools.

>> >Such a system maintain traceability between requirements, use cases, design
>> >artifacts and modules.  It would maintain lists of programmer and analysts
>Ah, ok. Traceability is a process thing with 3.0.6. I don't know about
>4.0.

You can do some tracability with Rose and SoDA but it requires a bit of
hoop jumping.  You basically add text tags to your class descriptions 
and scenarios to associate them with requirement numbers.  Then someone
does some magic in SoDA (we had a Rational guy do this for us) to use the
tags in our document.

This hardly works all that well for multiple projects using the same
code base but it kinda sorta does the job if you're only dealing with
one set of requirements.

>> >No such tool exists today.  I think it will be a long time before such
>> >a tool does exist.  But I can dream.
>> 
>Give it a try...
>
>Anybody else got comments?

Yeah...don't use Apex unless you intent to slip 2-3 months on top of
the month you allocated for the change over.  For our next project
we're going back to Rose/SoDA, CVS/TkCVS, emacs/gmake and adding
either Visual C++ or SparcWorks Impact C++ depending on platform.

You are much better off spending money on Purify and Quantify than
Apex and if you really lack things to spend money on you're better off
hiring a temporary CM person than pouring money into Apex.

Nigel Tzeng

Software Development Environments (Was: What is wrong with OO ?)

[Stephen Riehm]

Robert C. Martin <rmartin@oma.com> wrote:

> As engineers we need a CAE system that combines the CASE tool,
> editor, compiler, documentation tool, debugger, test plan generator,
> simulator, etc into a single seamless facility.

> Such a system maintain traceability between requirements, use cases,
> design artifacts and modules.
> It would maintain lists of programmer and analysts notes that were
> germane to each other.
> It would facilitate communications between engineers working on the
> project regardless of their location.
> It would facilitate configuration management and version control.
> It would facilitate project management.

> No such tool exists today.  I think it will be a long time before
> such a tool does exist.  But I can dream.

Exactly, but there's more. The above system would also have to cope
with various languages. Especially when dealing with GUI's etc,
generators are used to generate C++ code, which then needs to be
compiled etc. In this case, you don't want to edit the generated code,
but the code that was used to generate it. (other examples include
lex and yacc files, scripts etc) Such an "all singing and dancing"
system can't possibly cater for ALL possibilities.

As Robert said, no such tool exists today, but there is no reason why
we can't move in that direction.

The Unix view of the world is not a bad one, but one which compiler
writer's seem to have discarded. Unix works because programs are
expected to communicate with each other, via well defined interfaces,
the principle being that the sum of many parts is much greater than
could ever be achieved by one whole. Robert's dream could be achieved
if the parts (compiler, editor, build system, debugger etc) could be
made to really fit together. Someone here said that this "isn't rocket
science", and he's right. It just takes a little logical thinking.

I'll try to identify some of the problems facing developers, regardless
of what language they are using. It would be nice to take the
suggested improvements below and integrate them into existing systems,
but the way I see it at the moment, the lack of communication from the
existing compilers provides a constant stumbling block. So, in classic
hacker style, I recommend that we "work around" the problem for the
time being, while constantly moving in the direction of Robert's
dream. (don't worry Robert - I share your dream too!)

One very large problem with software development practices is that
they aren't very scalable. What works for a 3 woman team almost
definitely doesn't work when you have 30 people working on a piece of
software. Unfortunately, in University, you learn the language, and
then you write a small program or two to prove that you know the
basics, but I have never seen a course where students are exposed to
practices which apply to software projects with many developers, huge
libraries of code, etc. Students enter the world thinking that they
can create a directory, start up their favorite editor and write a
program, possibly with the afterthought of doing a little design and
testing, documentation may also cross their minds if they've been
paying attention.

Languages aside, there is the problem of how software gets written. My
eyes have been opened by the (mis)fortune of working with teams of 50
developers or more, in which case problems such as code stability,
deterministic build mechanisms, communication between developers and
other factors become very apparent.

One step in the right direction is the introduction of Configuration
Management Systems (CMS), like CVS, RCS, SCCS, and the various
commercial
products available today (I know of 3 very good systems, but this is
not the place or time to advertise). These systems can be used to
force developers to think a little more carefully about what they are
doing, and above all, make it possible to trace what has been done,
and sometimes even why.

Another big help would be, in my view, the teaching of deterministic
development practices. Unfortunately I am yet to have found ANY
definitive work in this area, although some people are beginning to
see the relevance. I can best describe this with examples of what NOT
to do, but I am desperately searching for a mechanism to help improve
the situation.

In a small project, it is perfectly feasible for each developer to
have a complete copy of the software in her private domain
($HOME/project), where she can edit the code, and test it without
inadvertently effecting anybody else. When she's finished, she
publicises her changes, and moves on to the next task. In small
circles this works OK, as communication between developers is simple,
and normally verbal confirmation is adequate. Try this with more than
about 5 developers and you very soon get chaos. The chances that some
(or all!) developers are working with inconsistent code (because they
are working with copies) increases greatly. A big help in this regard
is the advent of CMS, which provides a central software repository,
and which allows no more than one developer to change a file at a time
(there are workable exceptions to this, but the CMS needs to be quite
clever). The developers still need to copy the files in order to
build (in most cases), but we're moving in the right direction.

The next problem is that of deterministic builds. Make (gmake etc) is
a tragic example of a hammer being used to build the Empire State
building (from digging the foundations, to installing the lights)!
Make works fine as long as all the files are neatly located in one
directory, and as long as no errors occur. In the real world of larger
software, source code is (sensibly) distributed throughout a tree of
directories, thus related software is kept together, while unrelated
code is kept well and truly apart. Errors often do occur (especially
during development) and parts of the system are often not even
complete. This is where large improvements can be made.

In the classic "make" environment, all files must be in the current
directory. A good enhancement of this is the introduction of gmake's
VPATH, where files can be found elsewhere, ie: in a central
repository, but in order to work out what is going to be done by make,
you need to be nothing short of a genius (OK, the rules are simple
enough, but if I had a cent for each time some one asked my "why did
make do that?" I would be a very rich man indeed). The next
improvement is to centralise the rules used for generating code. This
"can be achieved" via included makefiles, but there is still lots of
room for improvement.

At the moment I know of Christopher Siewald's "Jam" program, which is
a huge step in the right direction, and Bob Sidebotham's "Cons", which
extends on the ideas behind Jam, and adds some very interesting
concepts for determinability. Cons is still a little young, but when
it's completed it could be a major win.

So, my point is, that the language is a key factor when considering
software development, but the development environment is also very
important. What's the point of developing a program if you can't
reproduce what you've done? In my view, too much attention is being
given to the software lanuages and the source code itself, and not
enough to the environment in which the software is being written.
Class browsers, CASE tools, CM systems and deterministic build
environments can all greatly contribute to the reduction of bugs
written in the first place. Finding bugs takes up about half of the
software development cycle, and you will never get all of the bugs out
of a program, but if you don't put them there in the first place, you
end up with more stable, and easier to maintain software. (cheap and
reliable!)

I would like to hear your comments about production environments,
should shadow trees be used to provide simple access to a central
software repository? what about using hard or soft links? How do you
coordinate the work of 50+ developers all working on the same
project?

If anyone knows of any seminars, documents, research papers, web sites
etc etc that address these problems, I would be most grateful to hear
from you.

Thanks for your time, this article got a little longer than I had
expected. Sorry

Steve
Software Production Environment Analyst
pc-plus, Germany

//   __________________________ ._ o  ________________________________
\\\\ Stephen Riehm             /  //\.        Stephen.Riehm@pc-plus.de
//// pc-plus                  '  \>> |         Phone: +49 89 62030 148
  \\ 81539 Munich, Germany        \\ `           Fax: +49 89 62030 113

Re: Software Development Environments (Was: What is wrong with OO ?)

[Nigel Tzeng]

In article <32CD3495.14FE@pc-plus.de>, Stephen Riehm  <sr@pc-plus.de> wrote:
>Robert C. Martin <rmartin@oma.com> wrote:

[snip]

>the principle being that the sum of many parts is much greater than
>could ever be achieved by one whole. Robert's dream could be achieved
>if the parts (compiler, editor, build system, debugger etc) could be
>made to really fit together. Someone here said that this "isn't rocket
>science", and he's right. It just takes a little logical thinking.

It is really too bad that CenterLine is out of the C++ IDE market
because they had a great little product called CLIPC (Centerline
Interprocess Communication) that is effectively a "software bus" where
third party products can be "plug and play" with the core product.  It
it similar to ToolTalk but ran a lot faster with a much simpler 
interface.

I assume that the original plan was to publish the messages that
ObjectCenter used and allow any third party to develop an editor,
debugger, or whatever and replace ObjectCenter components.

It's too bad that ToolTalk never gained mass acceptance since it is
free on most platforms (unlike CORBA) and would do the job.  Of course
this is the same industry that opted for DCE RPC instead of the widely 
used and freely available ONC RPC.

[snip]

>Another big help would be, in my view, the teaching of deterministic
>development practices. Unfortunately I am yet to have found ANY
>definitive work in this area, although some people are beginning to
>see the relevance. I can best describe this with examples of what NOT
>to do, but I am desperately searching for a mechanism to help improve
>the situation.

I would think that SEI and PSP would fall into this category.  I think
that if you are an SEI level 3+ software house then your development 
process is fairly well documented and hopefully adhered to.  I suppose 
this is about as "deterministic" as one gets.

[snip]

>In the classic "make" environment, all files must be in the current
>directory. A good enhancement of this is the introduction of gmake's
>VPATH, where files can be found elsewhere, ie: in a central
>repository, but in order to work out what is going to be done by make,
>you need to be nothing short of a genius (OK, the rules are simple
>enough, but if I had a cent for each time some one asked my "why did
>make do that?" I would be a very rich man indeed). The next
>improvement is to centralise the rules used for generating code. This
>"can be achieved" via included makefiles, but there is still lots of
>room for improvement.

Um...we have a mulitplatform project based on a central CVS repository
using fairly simple makefiles (and gmake).  I'm certainly no Make guru
but we came up with it in an afternoon.  It correctly finds the right
include files and libraries from your local development directory or
the integration area or the release area using VPATH and -L.  It
correctly builds to the right object, library and binary areas.

On a previous project we did use included makefiles but we didn't
get that fancy this time around.

[snip]

>So, my point is, that the language is a key factor when considering
>I would like to hear your comments about production environments,
>should shadow trees be used to provide simple access to a central
>software repository? what about using hard or soft links? How do you
>coordinate the work of 50+ developers all working on the same
>project?

Be careful with soft links.  At one time we had an explosion of links
and a corresponding explosion of confusion.  I think that we have 2
left... beta which links to the current integration area and release
that points to the latest released tree.  Then we release the current
version we repoint release to the current beta tree and create a new
tree.  The old release tree gets moved offline.

before:  beta -> v2.3
         release -> v2.2

after:   beta -> v2.4
         release -> v2.3

>If anyone knows of any seminars, documents, research papers, web sites
>etc etc that address these problems, I would be most grateful to hear
>from you.

There are a couple of web sites that have some "best practices" info
and a host of books on the topic.  I tend to suggest buying Yourdon's
book simply to get his recommended reading list and he is an easy read
on the topic.

There is also a cm newsgroup that talks about a lot of CM tools (and
bugs with CM tools...)

[snip]
>
>Steve

Nigel

Re: Software Development Environments (Was: What is wrong with OO ?)

["Paul E. Bennett"]

In article <32CD3495.14FE@pc-plus.de> sr@pc-plus.de "Stephen Riehm" writes:

> I would like to hear your comments about production environments,
> should shadow trees be used to provide simple access to a central
> software repository? what about using hard or soft links? How do you
> coordinate the work of 50+ developers all working on the same
> project?
> 
> If anyone knows of any seminars, documents, research papers, web sites
> etc etc that address these problems, I would be most grateful to hear
> from you.
> 
> Thanks for your time, this article got a little longer than I had
> expected. Sorry
 
Steve,

The British Coputer Society have a Configuration Management Specialist Group 
which is doing work in this area. They held a seminar and tools fair at 
Heathrow recently. I will try and find out the web address for the group and 
post it later.

Newsgroups such as comp.document.management are also dealing with tis issue 
and may be a little more relevent. It may be that a comp.config.management 
group would be useful but that may depend on what others think.

A good book is "Configuration Management" by Marion Kelly published by McGraw 
Hill ISBN 0 07 707977 9 (hardback) UKP 29.95. To obtain direct from the author 
you can call +44 (0)1252-851448.

For one excellent product see SQL Software Ltd's product PCMS Elite. Contact 
John Palmer <j.palmer@sql.com>.

-- 
Paul E. Bennett <peb@transcontech.co.uk>
Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely

Key Abstraction that is coming

[Mark Smith]

Here's my key abstraction for the year

Stephen Riehm wrote:
> 
> The Unix view of the world is not a bad one, but one which compiler
> writer's seem to have discarded. Unix works because programs are
> expected to communicate with each other, via well defined interfaces,
> the principle being that the sum of many parts is much greater than
> could ever be achieved by one whole. Robert's dream could be achieved

The key abstraction here is a well defined interface to make apps talk.
ie like DDE, COM, CORBA, pipes and stdin/out etc. These are all fine
except they assume that everybody understands the format to start with.
Also they have varying levels of impact on your system. pipes/stdin/out
are extremely low cost to implement. CORBA - expensive. DDE/COM non
scalable. 

Anyone seen KQML? We need to start putting AI type reasoning into our
systems so that they can reason about how to communicate with other
apps. making everything talk together is the key thing we all need to
work toward, and reasoning about interfaces seems to be a good way of
looking at the problem.

Alternatively components, and Smalltalk PARTs? but that's interaction at
a different level.

What do you all think?

Re: Key Abstraction that is coming

[John Howard]

On Mon, 6 Jan 1997, Mark Smith wrote:
[deletions]
> Stephen Riehm wrote:
> > Unix works because programs are expected to communicate with each
> > other, via well defined interfaces, the principle being that the sum
> > of many parts is much greater than could ever be achieved by one
> > whole.
>
> What do you all think?

OpenDoc parts and part handlers.  Possibly created as portable Java 
applications (not applets or necessarily written in Java language).  The
OpenDoc environment is well suited for developing software.

OS/2 v4.0 has OpenDoc, a Java virtual machine, and IBM VoiceType dictation
& navigation.  These features should be combined to enable quick 
advancements in software engineering.

For instance, consider a GNU-like compiler system represented by OpenDoc 
components.  The compiler system would allow various programming languages
to be used for developing software products.  Vendors of OpenDoc parts and
part handlers could offer enhancements to the compiler system (unlike GNU 
this policy should not try to impoverish commercial vendors of compiler 
components).  And the integrated development environment is adaptable to 
satisfy each user.

In a few years it may become commonplace to create and maintain software 
by speaking a readable language such as Ada and interacting with OpenDoc.

------------------------------------------------------------------------
-- John Howard <jhoward@sky.net>               -- Team Ada  Team OS/2 --

Re: Key Abstraction that is coming

[Robert Dewar]

John Howard said

"OpenDoc parts and part handlers.  Possibly created as portable Java
applications (not applets or necessarily written in Java language).  The
OpenDoc environment is well suited for developing software."

Ouch, that's confusing terminology (a Java application not written in
Java). How about using the terminology "JVM application" to keep things
clear?

Re: Key Abstraction that is coming

[Robert Dewar]

"The key abstraction here is a well defined interface to make apps talk.
ie like DDE, COM, CORBA, pipes and stdin/out etc. These are all fine
except they assume that everybody understands the format to start with.
Also they have varying levels of impact on your system. pipes/stdin/out
are extremely low cost to implement. CORBA - expensive. DDE/COM non
scalable."

And since one of the newsgroups being cross-posted here is comp.lang.ada,
we should add (as another low cost option), the RPC interface provided
by the distributed systems annex of the Ada RM, which has been successfully
used for both homogenous and hetergenous distrbution, on single machines,
and on networks.

Re: Software Development Environments (Was: What is wrong with OO ?)

[Tom Bushell]

On Fri, 03 Jan 1997 17:32:21 +0100, Stephen Riehm <sr@pc-plus.de>
wrote:

>Another big help would be, in my view, the teaching of deterministic
>development practices. Unfortunately I am yet to have found ANY
>definitive work in this area, although some people are beginning to
>see the relevance. I can best describe this with examples of what NOT
>to do, but I am desperately searching for a mechanism to help improve
>the situation.

Have you seen the book "A Discipline for Software Engineering", by
Watts Humphrey?  This might be exactly what you're looking for.


>Class browsers, CASE tools, CM systems and deterministic build
>environments can all greatly contribute to the reduction of bugs
>written in the first place. Finding bugs takes up about half of the
>software development cycle, and you will never get all of the bugs out
>of a program, but if you don't put them there in the first place, you
>end up with more stable, and easier to maintain software. (cheap and
>reliable!)

This is Humphrey's approach - the major focus is on defect reduction.

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: Software Development Environments (Was: What is wrong with OO ?)

[drush]

OO-ps! I botched the attribution of the quoted text.

I was replying Stepehn Riehm's comments on Robert Martin....

YKYBHTL
	david rush
	mailto:kumo@intercenter.net

Re: Software Development Environments (Was: What is wrong with OO ?)

[drush]

Robert Martin wrote lots of really good stuff about configuration
management which is IMNSHO possibly *the* main problem facing large
software projects (well, one of the biggies anyway).

He also gave me a great straight line:
>The Unix view of the world is not a bad one, but one which compiler
>writer's seem to have discarded. Unix works because programs are
>expected to communicate with each other, via well defined interfaces,
>the principle being that the sum of many parts is much greater than
>could ever be achieved by one whole. Robert's dream could be achieved
>if the parts (compiler, editor, build system, debugger etc) could be
>made to really fit together. Someone here said that this "isn't rocket
>science"

No, its Emacs.

:)

Happy hackin'
	david rush
	mailto:kumo@intercenter.net

	I bill $100/min for reading commercial email.

Re: What is wrong with OO ?

[drush]

As a first comment this thread is diverging just like most
of the problematic software systems where "OO has failed".

However, I am going to continue to propagate the insanity.

Tom Bushell wrote in <32ca9f2d.174894569@news.nstn.ca>:

>Very true.  But my experience has been that "wiring in" to certain
>languages is easier. [snip]

This is so true *and* it explains the popularity of C++ (spit). At
first C++ feels like everything you ever wanted fixed in C. So
people feel "wired in" very quickly. Of course, the more you follow
its paradigms and explore its semantic space, you notice that it
is really really really really weird in there. Lots of irregularities,
insanities, and inanities. OTOH, I've been told that the committe
has been fixing some of the craziness. 

Gripping hand is that a simple, regular semantic basis in a language
will take you much further than a complex one.

>It seems much easier to get into a state of flow when using these
>languages - you just code and test, and everything seems to work.  I
>can hardly ever achieve this happy state in C, even though it's one of
>my most familiar languages - it's just too much like work.

Absolutely. I love Smalltalk. I spend almost no time working around
the language/coding test programs to check implementation behavior.
I must admit that "straight" C flows for me very well, too. It's the
simple semantic structure of the language, again. I just don't get
a sense of the tool inflicting itself upon my design with these
tools. 

Software development is hard enough. I have to design and explain
my work in such a way to keep managers, customers, and users all
happy (and the above are all whiny breeds of people). I sure don't
like dealing with a whiny compiler on top of it all.

In the usenet flow...
	david rush
	mailto:kumo@Intercenter.net

	I bill $100/min for reading commercial email

Re: What is wrong with OO ?

[Nigel Tzeng]

In article <5a9r1k$e74@news4.digex.net>, Ell <ell@access1.digex.net> wrote:

[snip]

>Because Boeing had a super diagram doesn't mean it's highest level was
>predicated on a single, or even specific set of, technology, i.e. on one
>or more specific languages, or distribution technologies in our case.

Actually I think that one can make the case that the highest level was
predicated on a specific set of technology.  I'm going to speculate a
little here since I know virtually nothing about the actual 777 design
but here goes:

Say they started with a specific weight goal for the airframe or they
couldn't get the performance they wanted out of the aircraft.  They
thought they could meet this goal through the use of composites.  The
choice of composites then bounds the high level airframe architecture
because of what you can and cannot do with composites (compare to say
conventional airframes made of metal).

Likewise they may have started with the assumption that they would use
a computer controlled fly-by-wire system.  This technology also
constrains the overall architecture of the aircraft.

I don't believe that you can completely separate the architecture from
the underlying technology as cleanly as you imply.

For a software example if you decide that your key technology is Java
then your overall structure better not be based on having access to
multiple inheritance.

>Elliott

Nigel