Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Marketing Forth
Message-ID: <330.UUL1.3#5129@willett.UUCP>
Date: 24 Jan 90 00:53:24 GMT
Organization: BoneHeads R Us
Lines: 56


 Date: 01-22-90 (20:52)              Number: 79 (Echo)
   To: GARY SMITH                    Refer#: 76
 From: JERRY SHIFRIN                   Read: NO
 Subj: MARKETING FORTH               Status: PUBLIC MESSAGE

 GS> From: usenet@cps3xx.UUCP (Usenet file owner)
 GS> Subject: Re: Marketing Forth (was Re: Thoughts on Forth)
 GS> How do you sell management on doing a project in Forth? That is the real
 GS> battle. Good technical articles would go a long way towards helping.
 GS> But, other than doing a project completely in Forth and then unveiling
 GS> to management later that it was done in Forth, what are some good ways
 GS> to go about changing the thinking of the decision makers?
 GS> Anyone with experience in this area care to comment?

 I have mixed feelings about this, but I was successful in selling
 my management on a Forth project a few years ago.  My entire
 pitch was "productivity". I was able to show evidence of improved
 Forth productivity by taking an existing application with a lot
 of problems and recoding it in Forth.

 The recoding was done in a couple of weeks; it resolved all the
 outstanding problems and was lots smaller and easier to maintain
 than the original assembler program. It ran a bit slower than the
 original, but not significantly so.  It was a dramatic
 demonstration of Forth's power in an ill-defined situation.

 Now, four or five years later, I'm still doing an offshoot of
 that project and still doing it in Forth. If I had it all to do
 over, I'd probably do it in C.  Not because C is better in any
 way, but that the selection of Forth caused numerous problems in
 maintaining credibility for the project and for myself.

 The project was (and still is) successful in terms of function,
 schedule, and performance. However, with the vast bulk of other
 development being done in C, my project sticks out like a sore
 thumb. It's difficult to recruit and train people since they
 perceive that it's not a "mainstream" system here (it's not) and
 that their careers might suffer.  It also suffers from its
 "oddball" reputation.

 Another difficulty is that my colleagues are developing a vast
 collection of tools, training facilities, CASE systems, and so on
 and we're left totally on our own.

 I think it's okay to be a "maverick" in a large organization, but
 in the long run, you either have to go along with the other folks
 or get them converted to your point of view.

 I don't suggest that this is typical of Forth systems, but only
 my one experience with a fairly large Forth application.
 ---
  * QDeLuxe 1.10 #214s
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'