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.
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?
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.
Newcomers approach a language from different places, and depending on where they're coming from, the same language can seem like a blessing or a curse.
I love Julia--it's so thoughtfully constructed, incorporating parallelism as a fundamental, and expressive but performant. Compared to something like MATLAB or R, it solves all my problems.
But for someone coming from Python or C, Julia can seem unnecessary and crippled by odd conventions. To someone used to the expressiveness and libraries of Python, why would you need Julia? To someone coming from C, which can do everything and is the speed standard, why would you need Julia?
Languages do really serve different roles, but we often assume otherwise. That assumption is often implicit, though, which leads to discussions where people are talking past one another.
I watched and toyed with all the HPCS languages for awhile, along with OCaml, and saw that they never got the traction I was hoping for, and none seemed to become something I could just use, practically speaking. Fortress was amazing in concept, but maybe bit off more than it could chew, at least with the support at hand and situation at Sun. Things seemed dormant for awhile, and then Julia showed up, which seemed like what everyone was looking for all along.
Honestly, Stanza seems really promising as well, but I wonder if it's too late to the party (although I thought that about Python long ago as well and was obviously wrong about that).
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.
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.
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.
kenko is correct that the 'config' keyword is what indicates that a symbol can receive a command-line override in Chapel. As others have suggested, we followed C's lead in interpreting 'const' as "Cannot be re-assigned after initialization" rather than "Value must be known at compile-time."
To specify values that must be known at compile-time, Chapel uses the 'param' keyword, where 'config param' symbols can be set on the compiler's command-line (as can 'config type' symbols, used to specify type aliases). 'param's and 'type' symbols tend to lead to compile-time specialization, similar to C++ template variables.
That just leaves 'config var' which indicates that a symbol can be set on the execution-time command-line and re-assigned over its lifetime.
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.
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?
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.
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).
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.
It was an exception to your blanket statement (no language uses this definition of const). Apparently the only language that you consider relevant is C, which is fine. But I wouldn't take many cues from C in reference to modern language design and proper semantics. As useful as it is C has many holes and broken semantics.
Er, in both C and C++ it means that in static context for (at least) integral types, though it does also generate a symbol that can be used if needed (ie if you take its address).
Of all the languages out there, Julia may be the one to be used for this eventually.