This site is updated infrequently. For up-to-date information, please visit the new OCaml website at ocaml.org.

When functional languages can be accepted by industry?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
 Date: -- (:) From: Steve Stevenson Subject: Re: When functional languages can be accepted by industry?
I may have missed some of the below ideas in the discussion.

Let me pass along the notes from a discussion that I had with Jim
McGraw who was one of the true guiding lights of the Sisal effort. You
can huff and puff at this, but in my experience (11 years at the old
Bell Labs), these ideas ring true. FYI, ASCI is the Accelerated
Strategic Computing Intitiative (simulation support for the US nuclear
weapons program.)

Best regards,

steve
-----
Steve (really "D. E.") Stevenson           Assoc Prof
Department of Computer Science, Clemson,   (864)656-5880.mabell
Support V&V mailing list: ivandv@cs.clemson.edu

============================================================

The following information is drawn from an exchange with Jim McGraw of
LLNL on the whys and wherefores of the failure of SISAL to win the
hearts and minds of the programmerate. This is a LaTeX file. The
paragraphs in \em are my comments --- steve

\begin{outline}
\item No Commerical Support*\footnote{
Items marked with an asterisk (*) identified by Jim as key
issues. Italicized text is my response to his comments.
}%
Code developers want assurance that their codes can be moved to
different platforms and the language will be supported there.
This requires vendor concurance and support that Sisal never
achieved.  This is the standard chicken and egg problem, because
vendors want to see apps users demanding a product before they
support it.  This is a very real and very difficult hurdle for
anyone -- nothing specific to Sisal or functional languages.

sure that isn't first sometimes. The grads coming out are not
going to change languages and systems unless they have to.}

\item We want Fortran*:  Until the ASCI demands came along, there was a
clear preferance to evolving current codes, which were all
written in Fortran.  The argument was that we had too much
invested to rewrite codes and to really get the benefit of
Sisal, you need to rewrite and rethink your code design.
Interestingly, the new breed of programmers and the ASCI demands
have overcome this argument.  Programmers are using many
variants of Fortran and C.  C++ is coming into vogue and also
many different front-end control languages, like Eiffel and
JAVA.  Moreover, many first wanted MPI as the model for
parallelism, but now they are being forced to use threads and
OpenMP, to get concurrency within these nodes.  They chose MPI,
not because it was good, but because it was perceived as the
ONLY option that would give them long term portability (even
though to this day, the performance cost of such portability is
still in serious doubt).  So what they really want is minimal
change.

{\em This last sentence would seem to capture it all. We see it
when we try  to get the students to add a new language.}

\item Unstable compilers for Sisal*:  This is a very legitimate
argument.

\item The programming model did have some serious weaknesses.
Foremost was I/O.  The whole concept of streams was included to
have some way of doing I/O, but it was an awkward hack at best.

{\em I must admit, I find the current spate of implementations
of streams unintuitive. However, CAML and OCAML seem a bit
easier to use. Much of this is experience, though, isn't it?
Streams are really natural for some problems.}

We ended up making more progress by permitting calls from Sisal
to C, where we did I/O.  But that approach has some severe
technical difficulties that programmers must use with great
care.  Another example of model weaknesses is parallel
operations like bucket-sort that we could not easily express
with their natural concurrency.  There were a whole set of
issues about what we should or should not allow in the language,
relative to things that were determinant.

{\em It seems to me that this problem of how to write
parallelism is ubiquitous and I'm not sure I understand what the
real problem is from either a cognitive or conceptual
viewpoint. I did a lot of discrete event simulation work at BTL
and I find that experience the key to understanding parallelism
but I don't see the linguistic solution either. }

\item *Programmers did not want to turn control of key things over to a
compiler, because they did not trust the compiler to do the
right thing.  One good example is data layout.  For parallel
machines with distributed memories, we did not have a good
solution, although our most likely idea was to use some form of
pragma from users.  They did not like The idea that the compiler
would decide where in memory things would go or when various
thing would be scheduled for execution.  Interestingly, they are
now discovering that for these complex cache-based machines,
they must have the compiler do more, or the performance of the
codes drops through the floor even on single processors.  The
best performance is achieved by setting up data layout on a node
based on the exact variable reference patterns across different
(unnested) loops.

{\em I wrote a preprocessor for a biophysics group. It took
chemical stoichiometry notation and developed the functions. I
realized later that they were using it to generate the code and
then handchecking the Fortran. Is the problem that we're too
opaque to the scientists? A more collaborative effort?}

\item I think there is no doubt that the functional programming style
caused concern among possible programmers.  They are accustomed
to thinking sequentially and this change was awkward.  Even now,
many folks still want to stick to SPMD mode, where everything
has a vector view.  for some kinds of code, this works great.
However, when we get to codes that need more concurrency and
require effective load-balancing, the solutions will be very
hard.  Right now, programmers want to manage their concurency in
understandable ways.  Sisal did not permit much of this type of
control.

{\em My academic colleagues don't seem to be able to make the
switch to functional, either.}

\item Determinant behavior.  The language definition for Sisal
required determinacy.  However, to insure this property, we had
to make sure we had the exact replicatable order of execution
followed.  This was a VERY high cost in terms of performance.
Morever, when we went to compare performance with other codes
that did not guarantee determinacy, we would lose badly.  So our
implementations had an option to ignore the determinacy
constraint.  When we did that, we got better performance than
our competition, but we had lost a key feature, because now we
could get race conditions.

{\em How much of this should be fodder for academic
research. Good old computability theory?}

\item *And the ever present: Politics.  <Understand the points>

\item I am not sure this is all of the reasons for our problems, but
it is certainly the overwhelming majority of them.  It's
impossible for me to rank their importance, because no one else
ever tried.

\item The totality of the issues just weighed us down too much to
change things.  The key point to me is that many of these issues
are not unique to Sisal.  ASCI and even the President's PITAC
report say that "software" is the issue and that we still need
to consider new programming models and styles.

\item The roots of MPI have been around for a lot longer than that.
This is any area that moves at a snail's pace and yet users
demand robust and reliable tools and upward compatibility from
their current codes.  I am not sure there is any technically
good solution possible.

\item {\em You may be exactly correct. The problem is not a technical
one. The desire to change languages seems worse now than ever
before. Maybe that's how one get ones project out of trouble:
"We're in the wrong language, let's rewrite."}
\end{outline}
\end{document}

--
Best regards,

steve
-----
Steve (really "D. E.") Stevenson           Assoc Prof
Department of Computer Science, Clemson,   (864)656-5880.mabell
Support V&V mailing list: ivandv@cs.clemson.edu