
Chapel: a parallel programming language designed for productivity at scale - luu
http://chapel.cray.com/
======
myrryr
Chapel (from Cray), x10 (from IBM, and fortress (from sun) were all created to
solve this problem (and all got funding from DARPA to do so). Fortress (which
was way out there and very cool!) Died a horrid death. I think x10 still
exists.

Of all the languages out there, Julia may be the one to be used for this
eventually.

~~~
shrugger
I really enjoy Julia, and I see such amazing potential from it but I talk to
so many people who hate it, or complain about it. I know most people haven't
had the pleasure (/s) of programming in MATLAB and so some of decisions might
not make sense, but that aside it's a damn good language.

I really see Julia 'winning' in the longevity sense, but it makes me nervous
sometimes seeing people misunderstand that. Do you think that similar
misunderstandings have prevented Chapel and company from a more widespread
success?

Also, Erlang is fairly successful. According to Wikipedia, Chapel was started
in 2009, and Erlang was around back then too, what does Chapel provide that
obsoletes Erlang? What problem does DARPA think that Chapel/x10/etc could
solve that Erlang couldn't?

~~~
EdwardCoffin
Chapel and the other two languages were part of the HPCS project. An HPCS goal
[was] to create a multi petaflop systems [1]. Erlang is not really the kind of
language you can use to build such systems. It's not that Chapel (or the other
two) 'obsolete' Erlang, it's that they were built with completely different
goals in mind.

[1]
[https://en.wikipedia.org/wiki/High_Productivity_Computing_Sy...](https://en.wikipedia.org/wiki/High_Productivity_Computing_Systems)

------
nickpsecurity
Brings back memories as I followed the three languages for a while. Good to
see a link to one plus arthurcolle's great link to a summary of Fortress's
strong points. A recent foray into this theme is ParaSail language below.

[http://www.embedded.com/design/other/4375616/ParaSail--
Less-...](http://www.embedded.com/design/other/4375616/ParaSail--Less-is-more-
with-multicore?page=0)

Meanwhile, functional approaches like Erlang and Haskell have been most
impressive. Still a need to improve with languages already there. Cilk (below)
was one for C. I've also included a list on Wikipedia for people interested in
this topic.

[http://supertech.csail.mit.edu/cilk/](http://supertech.csail.mit.edu/cilk/)

[https://en.wikipedia.org/wiki/Category:Concurrent_programmin...](https://en.wikipedia.org/wiki/Category:Concurrent_programming_languages)

------
kazinator

         config const n = 100000;    // override default using ./a.out --n=<val>
    

What? I smell anti-pattern. `const` should promise or specify to the compiler
that this value doesn't change, so it can be baked into code.

Automatic translation of command line arguments to variables is useful (I have
implemented this in shell scripts past as a nicer alternative to getopts). But
the variables which receive command line overrides should be set apart in some
way for that purpose.

~~~
TylerE
That's not what const means, in any language I've seen with a const qualifier.

~~~
nightski
In C# it is exactly what it means. const values are substituted directly
during compilation. This is why sometimes it makes sense to declare a variable
as static readonly instead of const.

~~~
kedean
I'd argue that you are conflating implementation with semantics. The semantic
meaning of const is 'this value will not change from here on out'. The C#
compiler implements this by doing a substitution, but that is not mandated by
nature of it being 'const'. Calling these variables 'config const' says 'this
will be instantiated by some configuration parameter, but from here on it it
will cannot change'.

If someone were to patch your C# compiler such that it didn't substitute, and
instead pulled from a read-only memory location, would it in any way harm the
correctness of your code?

~~~
nightski
Actually I think it's the other way around. Since there is no guarantee that
it is not copied, you can't assume either way. const means just that - const
at compile time. As you say how the compiler chooses to utilize that
information is up to the implementation.

In C# you can't assign a const to a value not known at compile time for this
very reason. However, you can assign a variable value to a static readonly
field.

~~~
kedean
That's because of the implementation details of C#. If I make a const pointer
in C, it's obviously not a compile-time value, because the memory location
can't be guaranteed at compile time. Const values in C are definitely able to
be assigned from variables. Very few languages share C#'s requirement that the
assignment be known at compile-time (the only other one I can find is Nim).

~~~
kazinator
Nitpick: (scoped) const variables in C can be _initialized_ from run-time
values, not _assigned_.

RAAI: Really, assignment ain't initialization.

A file scope const object in C can have a value which is not known at the
point of declaration.

    
    
        extern const int var;
    

This one is not known until either a definition is supplied later in the same
translation unit, or else not until linkage with another translation unit
which supplies a definition.

    
    
        static const int var;
    

In this case, the value is not determined until either a definition is seen
which provides an initializer, or else the the end of the translation unit is
reached (whereupon the tentative definition becomes actual, with a value of
zero).

In this situation, though, the static value can be propagated as a true
literal constant into code which precedes the point where the value is known.
Just not in a "one-pass compiler".

This is also the case when a block-scoped const is initialized with a literal
constant:

    
    
       { const int x = 5; /* almost "true" constant */ ... }
    

In C, x isn't considered a constant expression, but _de facto_ it is, which is
good enough for optimizing.

------
vass
Hi - I am a member of the Chapel team at Cray. I will be happy to answer your
questions about Chapel.

