Big projects 
Author Message
 Big projects

I've started to notice that many of the people who have an interest
in OO techniques, aren't convinced that they really work.  The data
is hard to collect.  Ideally you'd do parallel trials, but who's
going to replicate giant projects to see which way works worse?  If
your management believes in OO you use it, and otherwise you don't.
So:

1*  Handling large projects looks like an unsolved problem.  (Or
anyway, it looks like nobody knows how to do it as fast and as cheap
as management insists.)  Forth doesn't have a magic solution
for that.  People who get very quick results for small Forth
projects, start to slow down when the namespace reaches 20,000 words.

2*  Managements seem to very often want to do large projects.

3*  Forth is marginal in the most visible direction that things are
headed.

Here's a quote from Donald Kenney, in FD15(1):24 (May 1993)

  Much as I like Forth, I'm by no means convinced that Forth is a
  good choice for a big system language. Yes, the code will probably
  be great and the pieces will be beautiful to behold. But the system
  design (if any) will probably have been bungled. It usually is
  (generally because of management impatience, not designer
  ineptitude). Those pretty pieces are probably going to have to be
  trimmed and reworked to build a working system.  That means people
  working with each other's code. Forth is often hard to read, and
  I'd be concerned about ending up with people blowing each other out
  of the water with ill-considered, low-level changes to each other's
  code. I'm not sure how to handle shared data in a large Forth
  system. Not that I can't devise a way. But how do I know it will
  work?

Liz Rather responded admirably in the next issue:

  "The system design will probably have been bungled." Yes, sigh, it
  usually is. But even a lot of Forth detractors admit that it's
  great for developing by "successive prototyping," the fall-back
  path of choice when the design is fuzzy or non-existent. Often it's
  easier to do a prototype of, say, a user interface, than to get
  somebody to try to imagine on paper how it should look. And when
  the design decisions are being reconsidered, Forth's interactivity
  and flexibility really shine.

  As to the large project issue, we've been involved in numerous 5-20
  programmer teams over the years. The main difference between these
  and similar projects using other languages is that each programmer
  is so productive that you have to be on your toes making sure
  they're being productive in the right directions. Communication and
  coordination is even more important (and there is never enough of
  it in any project!) But is this a liability? Somehow I've never
  heard managers wishing their programmers were slower or less
  productive!

  Also, since you can do a particular job quicker and with a smaller
  team in Forth, some team-management issues solve themselves.

  Readability is an issue in every language, as are other subjective
  style issues. We have had great success by establishing in-house
  coding standards that everyone follows. As a result, you can't look
  at any of our code and guess who wrote it--and programmers never
  feel the discomfort of having to cope with someone else's
  idiosyncratic style. Other successful large shops do the same. It
  matters less what those styles are than that they exist and are
  observed.

  Shared data and other technical issues are handled pretty much the
  same in Forth as in other languages. The details are all diffrent,
  but the principles are the same.

I think her answer was very good, but some ways it was a FORTH Inc.
answer, not a Forth answer.  (Quite appropriate, of course.)  FORTH
Inc. can handle readability with extensive training.  If Manager X
wants to do a Forth project, he must hire or train his own Forth
programmers and do his own extensive readability training.

His core problem is communication and coordination -- Forth offers no
solutions, just makes that issue "even more important".

When the coordination goes wrong, or early decisions prove wrong, the
system design may be bungled and must be fixed.  OK, Forth is good
for late, fundamental changes -- but that was one of Donald's issues
for a large team, with people changing each other's unreadable code.
FORTH Inc has it handled, but just anyone can't expect to go out and
manage a large successful Forth project, even though anyone can go
out and learn Forth.

The small-team thing is good.  That's a solid plus.  But it's a
one-shot.  If a 50,000 line C program can be written with 5000 Forth
lines, that's good.  But the 500,000 line C program might take 20,000
Forth lines, and things start to get out of hand.

Here's a quote from Dean Sanderson, from GEnie on 2/21/91, quoted in
FD13(3):39 Sept 1991:

  Because of the power that Forth has given us (to keep projects
  small and quick), we have been able to avoid learning what others
  have had to about software development. Those who have grown up
  with Forth do management by intuition. We have trouble
  communicating with those who've been successful using fortran, C,
  or assembler. It's as if we speak different languages. As projects
  escalate, we find we have not killed the dragon, only maimed him.
  As we ready for battle, we find our pride has left us with few new
  weapons.

  For Forth to survive as a respected language, it must prove its
  adaptibility and change enough to support the concerns of
  management. These include: Integration, Maintenance, Documentation,
  Declining cost, Q.A, Configuration, and Scheduling.

  Though we've started late, we can survive by capitalizing on what
  others have learned.

4* Here is an unsolved problem, that many people with very deep
pockets want solved.  Forth hasn't solved it.  Maybe Forth could.



Mon, 12 Jan 1998 03:00:00 GMT  
 Big projects

Quote:
> I've started to notice that many of the people who have an interest
> in OO techniques, aren't convinced that they really work.  The data
> is hard to collect.  Ideally you'd do parallel trials, but who's
> going to replicate giant projects to see which way works worse?  If

        much good stuff deleted

IMHO:

        The promise of OO programming techniques was code (object)
        re-useability.  The failure, was to consider C++ to be the
        epitome of object oriented languages ... C++ is conceptually
        difficult for those not weaned on OO techniques, but a mere
        increment to C -- thus allowing the C programmer to become
        `object capable' (though not literate) very quickly.  C++ makes it
        incredibly easy for the great unwashed to write VERY bad code.
        The result is, that objects are so badly designed, they cannot
        be re-used in most cases -- and in future work, are re-developed.

        Things like the STL class library offer some small hope here.  Also
        well designed commercial class libraries make sense in some cases,
        but generally are too generic to be immediately effective.  The
        problem here is that most of the commercial vendors are focused on
        getting around the difficulties of GUI programming rather than any
        significant business problems (me_too alternatives to MFC etc.).

        Other languages, such as Smalltalk and Eiffel have not come into
        the mainstream, simply because there was no leverage on the skills
        of the large body of C programmers -- To gain the benefit of OO
        techniques, you MUST go through a learning curve, and although
        management can see the immediate benefits of code re-use, going too
        far from the mainstream is career threatening.

        The failure of FORTH was to be sufficiently different as to
        prevent the re-use of the huge base of existing libraries (C,
        C++, ASM ... whatever), nor to position itself in the OO arena.  In
        any event FORTH is so far from mainstream as to not merit
        consideration by those same managers who embrace C++, and ignore
        truely OO languages.

        Ms. Rather describes FORTH as an incremental prototyping tool.  I
        tend to agree, that if FORTH is to enjoy commercial success it must:

                o use standard C libraries transparently.
                o use C++ class libraries transparently.
                o respect standards (ANS, CORBA, SOM, ODBC, OLE (ugh) etc.)
                o support GUI's
                o have good development tools (de{*filter*}s, code managers etc.)
                o generate C++ equivalent code
                o be called something else ;-)

        and be positioned as an aid to mainstream development.  Perhaps once
        a toehold is obtained, people will begin to see the benefits.  Stealth
        is, however, required to sneak FORTH into the developers toolbox.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robert Sciuk    Director, Technical Services,                   (905) 529-8117
Innovus Inc.    204-200 James St S. Hamilton, Ont. Can. L8P 3A9 VMail: ext 203



Tue, 13 Jan 1998 03:00:00 GMT  
 Big projects

.
.
.

Quote:
>    `object capable' (though not literate) very quickly.  C++ makes it
>    incredibly easy for the great unwashed to write VERY bad code.

.
.
.

Call it meatball code.  :-)



Wed, 14 Jan 1998 03:00:00 GMT  
 Big projects
Quote:

> 2*  Managements seem to very often want to do large projects.

And a high percentage of large projects fail in various ways.  When the
buyer wants something that is impractical, it is the job of marketing
work to alter the buyer's perceptions so as to change what the buyer
wants.

There are many large, relatively incompatible systems out there.  The
result is not what any buyer or user *really* wanted.

Surely, looking back at most large projects, what was needed was
a less ambitious, more modular approach, that targeted some existing
software interfaces that anyone can see will dominate for the next
5-10 years at least.  More cooperation and less code.




Wed, 14 Jan 1998 03:00:00 GMT  
 Big projects

writes:

Quote:

> Here's a quote from Dean Sanderson, from GEnie on 2/21/91, quoted in
> FD13(3):39 Sept 1991:

 [snip ]
>   ... It's as if we speak different languages. As projects
>   escalate, we find we have not killed the dragon, only maimed him.
>   As we ready for battle, we find our pride has left us with few new
>   weapons.

It is I suppose true that most good warriors do know something about
their weapons, but has it ever been true that warriors always make
all their own weapons ?
Quote:

>   For Forth to survive as a respected language, it must prove its
>   adaptibility and change enough to support the concerns of
>   management. These include: Integration, Maintenance, Documentation,
>   Declining cost, Q.A, Configuration, and Scheduling.

But why should one language do all this ?  C++ doesn't do all this, yet
it is standard stuff for CS and engineering graduates.




Wed, 14 Jan 1998 03:00:00 GMT  
 Big projects

Quote:

>I think her answer was very good, but some ways it was a FORTH Inc.
>answer, not a Forth answer.  (Quite appropriate, of course.)  FORTH
>Inc. can handle readability with extensive training.  If Manager X
>wants to do a Forth project, he must hire or train his own Forth
>programmers and do his own extensive readability training.

>His core problem is communication and coordination -- Forth offers no
>solutions, just makes that issue "even more important".

What we do is in no way peculiar to FORTH, Inc., nor anything that
well-managed shops can't or don't do.  We do no "extensive training", we
just provide some written standards, a lot of good examples, and a
culture that expects compliance as it clearly makes life better for
everyone.  We frequently provide 5-day training courses in Forth, to
which our customers can come or send folks.  It helps a lot, and isn't
really "extensive."  And it isn't necessary, either.

You are correct that "the core problem is communication and
coordination", problems that _no_programming_language_ addresses in any
way.  The ability to address these problems is a management skill --
taught in various management courses, and learned independently by many
more.  Good managers find and use good tools, but what makes them good
is mostly their recognition of the need for good communication and
coordination, and the will to make it happen.



Thu, 15 Jan 1998 03:00:00 GMT  
 Big projects

Quote:


(Jonah Thomas)
>writes:
>> Here's a quote from Dean Sanderson, from GEnie on 2/21/91, quoted in
>> FD13(3):39 Sept 1991:
> [snip ]
>>   ... It's as if we speak different languages. As projects
>>   escalate, we find we have not killed the dragon, only maimed him.
>>   As we ready for battle, we find our pride has left us with few new
>>   weapons.
>It is I suppose true that most good warriors do know something about
>their weapons, but has it ever been true that warriors always make
>all their own weapons ?

Yes, sometimes, but the occasional precedent doesn't matter -- we
needn't do so when we can find good tools ready-made.

Quote:
>>   For Forth to survive as a respected language, it must prove its
>>   adaptibility and change enough to support the concerns of
>>   management. These include: Integration, Maintenance,
>>   Documentation, Declining cost, Q.A, Configuration, and
>>   Scheduling.
>But why should one language do all this ?  C++ doesn't do all this,
>yet it is standard stuff for CS and engineering graduates.

I regard this as a wish-list.  It might have come from an
anti-wish-list.

  "I want to use Forth."  
  "Oh, you do, do you?  Well, does Forth support Integration?"  
  "Yes, it does."  
  "Humph.  Well, does it support Maintenance?"  
  "Yes, very well, provided you can get someone to do the work.  But
there are Forth programmers out there."  
  "Huh.  What about Documentation.  Forth is notoriously bad for that."
  "Only because there were a lot of Forth programmers back when
everything was bad for that.  _My_ code is very well documented."  
  "What about Declining Cost?"  
  "Huh?"  
  "That's what I thought.  No, don't use Forth, use what everybody else
uses."

Suppose we learned how to address all these management concerns, and we
gave it a new name.  If we could somehow then get a very good success
story, we might get some management interested enough that we'd have he
chance to get another success story.



Fri, 16 Jan 1998 03:00:00 GMT  
 Big projects

Quote:

>I regard this as a wish-list.  It might have come from an
>anti-wish-list.

>  "I want to use Forth."  
>  "Oh, you do, do you?  Well, does Forth support Integration?"
>  [more dialog deleted]  

Forth _as_a_language_ supports all these things as well as any language
does: not at all.

These things (integration, maintenance, documentation, etc.) are all
responsibilities outside _any_ language specification.  However, just as
some language _implementations_ offer useful additional tools, so do some
Forth implementations -- generally, the more expensive ones designed for
professional use.

When you buy, for example, MS C++ you get more than a compiler, you get a
"development system" including a complex of tools.  And often you then buy
more (editors, SDKs, etc.).  When considering Forth, you have to consider
what support aids are relevant (not necessarily the same list as for C,
because Forth's intrinsic interactivity simplifies some of the chores at
which some of those tools are aimed), and then look at various specific
product offerings.

There are Forths on the market that are very full development systems,
including compiler, assembler, editor(s), de{*filter*}s (stepper, decompiler,
disassembler), libraries, documentation aids, on-line helps, etc.  
Therefore, it is inappropriate to say "Forth doesn't have..."  Such a
statement is relevant only to specified implementations.



Sun, 18 Jan 1998 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. VW: Big projects

2. Managing big projects in Clarion

3. for big projects, declarative or OO?

4. Big Project with BCC 2.0

5. Anyone use REXX for big projects?

6. I need some big projects...

7. Why can pyhton deal with a big project?

8. How to handle sys.path in bigger projects?

9. Severe Limitation of Smalltalk for Big Projects

10. Big J projects

11. Big J projects

12. Big J projects

 

 
Powered by phpBB® Forum Software