Version française
Home     About     Download     Resources     Contact us    
Browse thread
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 <steve@c...>
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 (really "D. E.") Stevenson           Assoc Prof
Department of Computer Science, Clemson,   (864)656-5880.mabell
Support V&V mailing list:


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
\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.

      {\em Agreed. You might add academic support. In fact, I'm not
      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

      {\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
\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

      {\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."}

Best regards,

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