Hi Gary,
 
Below are my responses to your questions. Since we don't know each other, my
apologies if in some areas I tell you what you already know. It appears I
have now provided enough information to put out a special issue, "What
Barrett thinks", but I hope you can find something useful. I'm happy to
answer any follow-up questions you might have.
 
> 1. How extensively have you used Chapel?
 
I downloaded the initial release of the compiler (v0.41) as soon as it was
made available on December 15, 2006. Prior to that I read about Chapel, read
the spec, saw a couple of talks. However, until I actually use a language, I
really don't understand it. Note that the current Chapel compiler does not
yet run across parallel processes; it was released so that we could become
familiar with the syntax and semantics, and to provide hands-on based
feedback to the developers. We've submitted a paper on our initial
difference stencil study. BTW, we have also begun working hard on Fortress
and X10.
 
> 2. What major observations do you have -- strengths, weaknesses, etc. Is there
any one feature that you feel is  really cool, really helpful?
 
The "global view" of the program (somewhat analogous to a serial program
view) is a big deal with regard to "ease-of-use". That said, we've seen this
before, so runtime performance becomes the concern. The Chapel, Fortress,
and X10 developers are all keenly aware of this, and are focusing their
efforts on it.
 
In particular, the data structure plays a huge role in the development and
execution of a program. Many attempts at making code development easier have
focused on this issue using constraints that result in poor runtime
performance. Chapel addresses this issue at a level that has thus far made
sense to my uses, and yet combines flexibility with information so that a
compiler writer may implement the code efficiently.
 
This is my segue to an important issue. The driver for these languages is
reducing the time from "idea to solution". This means different things to
different users. The applications I'm familiar with will be used for several
years, if not decades. A scientist who has an idea will perhaps add some
functionality to the code base, but then will run a set of experiments, each
of which may consume days, weeks, or months of computer time, even when
using the most powerful machines in the world. (Our motto is "bigger,
better, faster, more! And even that is not enough!") The few machines with
these capabilities are quite popular, so an experiment may sit in the queue
for hours, days, or even weeks. Once access is acquired, only a few hours is
allocated, so only a portion of the experiment may complete, so the code
writes out its state (to a "checkpoint" file), then goes back in the queue
to await restarting. This is a long winded way of saying that strong
performance is crucial to success in my opinion. Easy-to-write code that
runs significantly slower than "harder-to-write" code is not acceptable.
We'll simply apply greater effort (time, people, money) in writing the code.
And depending upon the perceived importance of the work, funding agencies
will pay for this.
 
> 3. What language are you using primarily?
 
During my ten years at Los Alamos, I worked on several large code projects,
which were mostly based on Fortran with MPI. Much of the code I wrote for
them was in C, some Fortran, a little C++. Small use of OpenMP. Since coming
to ORNL two years ago, I've found a similar situation, though perhaps a
little more C++ (again with MPI).
 
> How much of a software development productivity gain might you ultimately gain
from Chapel?
 
Although we're not attempting to quantify the "ease-of-use" issue, I've
found Chapel only slightly more involved than writing serial code. However,
until we can fully evaluate the performance of this code (the current
compiler does not yet run on a parallel computer) we really can't make
strong statements. However, if all goes well, this will be a significant
contribution to computational science.
 
> 3. In your view, does it have the potential to become an important language in
the realm of HPC? Could you be tempted to switch to it from whatever you are
currently using?
 
I'm a strong believer in using the "right" tool for the job at hand. Fortran
and C, with MPI for parallelism, aren't going away. Co-Array Fortran, UPC,
and OpenMP have proven useful in some situations. We have several options
for serial programming languages; parallel computing is inherently more
complex, so it seems reasonable to expect to require a similar breadth of
tools. 
 
We are implementing and evaluating some key kernels used in a variety of
application areas. I expect to implement some key components of codes in the
application teams I'm working with. These teams will then make their
decision based on a variety of factors (some analytic, some pragmatic, some
emotional, etc.). Other important factors in acceptance are groups
considering new applications as well as those just learning about this scale
of computation. One hope, as you probably know, is that by making it easier
to write effective applications, a greater breadth and depth of
participation will be induced.
 
Due to many previous failed efforts, acceptance is an uphill battle. We are
a skeptical (I hope not cynical) bunch, and by nature we can be brutally
critical. However, we are always in search of a better way. My group is
intent on giving Chapel, as well as X10 and Fortress (and other
languages/models) a thorough evaluation, and will share our experiences as
fairly as possible. Close interaction with the very sharp people developing
these languages is a crucial component to the outcome. Our experience with
the Chapel developers has been excellent, and we also have strong
relationships with the Fortress and X10 developers, and expect the same with
them.
 
We also need to be patient, where "we" includes evaluators, potential users,
developers, and funding agencies. A compiler is also a computer program,
which like any program, can be done well or poorly. And things get better
the more times we do them. (I'm told Fortran was met with great skepticism
in the late 1950's!) Also, the compiler does not operate in a vacuum. It
cannot turn poorly written code into an effective code. It also needs
hardware, operating system, and other support. This is the great thing about
the DARPA program: it addresses all of these issues in a coordinated manner.
So we stand a better chance of success than for any previous effort that I'm
familiar with. 
 
We just submitted a paper on the use of Chapel in finite difference methods,
will submit one shortly on another important scientific kernel, and soon
hope to produce a report comparing Chapel, Fortress, and X10 used in a
breadth of areas. Others in the community are doing the same. There is great
interest in this effort.

Richard
-- 
  Richard Barrett 
  Future Technologies Group, Computer Science and Mathematics Division, and
  Scientific Computing Group, National Center for Computational Science
  Oak Ridge National Laboratory

  http://www.csm.ornl.gov/~rbarrett