🚀 go-pugleaf

In article <8903291813.AA10019@uk.ac.ox.prg>, IAN@vax1.esprit.southampton.ac.uk writes:
[much text deleted]
> I can't really argue that occam has not been an obstacle to the general
> acceptance of transputer systems, but I would argue that this is really a
> problem of education of the consumers.

Whenever I see someone use the phrase a "problem of education of  consu-
mers"  I  immediately wonder why it's a problem in the first place. As a
person who has attempted "education of consumers" with  respect  to  the
advantages  of  occam,  I  feel that what really needs to happen in this
case is "education of vendors." (And I believe  this  is  true  of  just
about  every  other case where "education of consumers" is the purported
to be the "problem").

In my case, I suffered through learning the folding  editor,  ODS,  TDS,
OCCAM  1,  OCCAM 2, five hour compiles, etc. because I was paid to do it
by my company (In fact, I'm about to go do it again  GAG  :-).   In  the
process,  despite  all  the shortcomings of the software, I came to love
the idea of the transputer.

I then took on the duty of attempting to  convince  our  customers  that
they  should  make the same effort on their own time, without much luck.
Most of them decided that they'd wait for "real languages" (C  and  FOR-
TRAN) before they'd try the transputer.  The one scientist I worked with
who attempted to use OCCAM worked for over six months on his application
and  never got it to work (and he knew what he was doing). We eventually
got a C compiler for our system, and a similar application was up in two
weeks.

The root of the real "problem" as I see it is that any vendor of  a  new
product  (languages,  chips, software) needs to keep in mind the follow-
ing:

1) Most of the people who program and use  computers  are  not  computer
   scientists.   They  are not interested in learning new languages, new
   hardware, or in the intricacies of  formal  transforms  of  programs.
   They have a real world problem that they want to solve using the com-
   puter. In the scientific and engineering marketplace (the traditional
   users of new experimental systems) the lingua franca is FORTRAN, and,
   to a much lesser extent, C.

2) There is a "threshold of pain" that a person will not  go  beyond  in
   his  efforts  to  achieve  a  goal  unless the benefit is clear. With
   respect to a new language, typically a scientist will not go  to  the
   effort to learn it unless his problem will be solved much much faster
   than his currently available familiar options. Most  scientists  I've
   talked with quote that their application must run 10 times faster be-
   fore they'll go to a major effort. Also, the scientist  won't  go  to
   the effort unless your option is 10 times faster FOR THE SAME COST as
   his fastest available familiar option. The  only  exception  to  this
   rule  that  I've seen is when the problem simply can't be solved with
   available familiar options.

3) Before expending the effort of learning a  new  language/product/chip
   to  solve  a problem, it must be demonstrable that the item will have
   long term utility. e.g. will what I learn be valid 2 years from  now,
   will my application be able to run on new wowie machine XYZ without a
   similar learning effort, etc. This is why UN*X, FORTRAN, and C are so
   successful,  and  why most people only program in assembler when they
   have to.

[more deleted]
> I tend to think it would
> benefit them (INMOS) in to invest a little effort in making occam available on
> machines other than transputers. If people got hooked, they would surely want
> to buy transputer chips, since they make such good occam engines, and make
> distributing occam programs so easy.

[a very good description of the computer  science  advantages  of  occam
deleted]

I very much agree with the above statement, however I don't know of  any
instance  of  a  VENDOR SPECIFIC and VENDOR DRIVEN language having long-
term utility as a programming vehicle for general  users.  (People  only
program  in  assembler if they have to, and, official definitions aside,
if it only runs on platform X, it's assembler, OCCAM  included).   Also,
I'd contend that what would sell is transputer based systems, not chips,
and it's highly unlikely that the systems would  sell  well  unless  the
transputer  world  can  agree  on a paradigm for system software. Again,
this is why UN*X is so popular. People love being able to run the  exact
same  software  on  many  different  platforms. UN*X provides the system
software paradigm that makes this possible.

In my opinion, INMOS has fallen down on all three of the points  I  made
above.

In the case of point 1, the OCCAM "time to solution" is  far  too  high.
(Who  cares if your problem is solved in 10 hours instead of 10 days, if
it took you six months to port the application?) To use OCCAM,  you  not
only  have to learn a new language, but a new editor, execution environ-
ment, linker, YOU HAVE TO BUY A TRANSPUTER BOARD just  to  develop  code
and,  there's  no  system  software  to  speak of available (e.g. no de-
bugger). In my opinion, TDS is a lousy design for  implementing  an  in-
teresting new language (are you listening David May? :-). INMOS tried to
roll far too many "neat ideas" into the package. Each idea taken on  its
own  (e.g.   the  folding editor) has merit, but adding learning them to
the task of learning a new language was a mistake (IMHO :-).

In the case of point 2: The items above make the "level  of  pain"  very
high  for  a non computer scientist, and INMOS has not adequately demon-
strated the necessary performance improvements to induce people to cross
the  threshold.  (I'm sorry, but one of those toy PC boards just doesn't
run 10X faster than a CRAY :-). I'd suggest that, in addition to promot-
ing  OCCAM  on  other platforms, INMOS ought to build and market product
out of transputers a little larger than boards to go into PCs.  Make  it
big enough that it's 10x faster than the fastest Cray out there now. The
world would drool for it.

In the case of point 3: It's not at all clear here in the  US  that  the
transputer  has  a  future  (please  no  flames, I am a true believer in
parallel processing as represented by the transputer).  INMOS  has  been
scaling  back it's US efforts. No one has built a big transputer machine
that made a big splash. OCCAM only runs on transputers. INMOS appears to
be  uninterested  in  promoting  OCCAM  as  a  more  general programming
language.  It's very difficult to demonstrate to a  non-computer  scien-
tist how OCCAM is better than, say, C with some extensions for parallel-
ism (and frankly, I'm not convinced that it is, I'd like to see  threads
(a la MACH from CMU) implemented in C for the transputer).


-- 
_    /| The opinions here are my own, and even I don't agree with me :-)
\'o.O'  I am not an employee of LANL, I just use their computers.
=(___)= I stole the .sig file, but I did not shoot no deputeeee.
   U    Bill sez: AAAAK! PHHHT!   jxdl@lanl.gov