This article wraps up the series started in my previous two blog articles (here and here) with the goal of explaining why we are pursuing the development of the Chapel parallel programming language at Cray Inc. In those articles, I advocated for the pursuit of productive new languages like Chapel. In this article, I’ll cover reasons for developing a new language rather than extending an existing one.
Why create a new language? Why not extend C, C++, Fortran, … ?
People who ask this question are typically referring to one or more of the following perceived benefits.
By extending a language you don’t have to reinvent the wheel and can build on what’s come before. While this is true, conventional languages also tend to carry baggage that can be undesirable in the scalable computing setting. Sometimes this is due to the use-cases for which they were defined — for example, sequential, system-level programming rather than scalable parallel computing. In other cases, they may simply betray the era in which they were created; modern programming languages have had opportunities to innovate and improve upon those of the past, making programmers more productive. There’s no inherent reason to believe that scalable parallel programmers shouldn’t benefit from similar productivity features.
To take a specific example, C++ (particularly C++11) can serve as a very strong foundation for implementing embedded domain-specific languages. However, other features make it less attractive as the basis for an HPC-oriented language: its lack of support for multidimensional and associative arrays, its pointer-array equivalence, its aliasing concerns, and the semantics and awkward syntax of its templates. These are compelling reasons to consider starting from scratch rather than extending C++.
All that said, it’s worth noting that implementing new languages does not require completely reinventing the wheel, since you can still implement the new language and its libraries in terms of the old.
Extending a language will make it easier for programmers to learn. While there is certainly some merit to this argument, I also think that it overstates its case. In any new programming notation, whether it’s a library-based one like MPI, a pragma-based one like OpenMP or a brand-new language, the intellectual effort required to learn it stems less from learning its syntax, and more from learning the new concepts and their semantics — how parallelism is created and scheduled, how synchronization is expressed, how to reason about locality, etc. Often, moving to a new language can help programmers as they wrestle with these challenges by providing a cleaner, simpler notation for expressing the concepts rather than couching them as “just another” function call, pragma or operator overload. Moreover, new languages can facilitate a mental shift that can be helpful — for example, “When I’m using C syntax, I’m writing system-oriented code; when I’m writing Python, I’m doing scripting for my desktop; when I’m programming in Chapel, I’m writing parallel code for distributed memory execution.”
It’s also worth noting that creators of extension-based parallel languages often find that they need to redefine or remove existing language features as a means of working around past choices made for the sequential setting. Such changes can undermine the benefits of familiarity, since traditional features no longer behave as the programmer expects. In other cases, new languages may hobble themselves in some way in order to remain backward compatible with the original language rather than making the best choices for the scalable parallel context. In either case, these compromises can undermine the value proposition of extending the language in the first place.
By extending a language, programmers don’t have to throw existing code away. The key observation here is that new languages don’t require programmers to throw code away either, as long as they have sufficient support for interoperability. Java and Python are two languages that gained widespread adoption years after naysayers were claiming that designing new languages was a waste of time. Both languages support strong interoperability stories, and I believe this contributed greatly to their success. Java and Python programmers do not throw out all of their previous C/C++ code when adopting these languages. They simply wrap it or call out to it. To lower barriers to adoption, new parallel languages must support similar interoperability stories, and this is a focus area in Chapel’s design.
Wrapping this question up, there is certainly merit in extending existing languages, and the Chapel team does not object to groups that do so. Yet, we believe that new languages bring additional benefits in expressiveness, productivity and optimization opportunities, which is why we designed Chapel from a clean slate. In doing so, we’re building on previous languages and technologies while also striving to interoperate with them in order to preserve earlier investments by developers and users.
To summarize this series, the Chapel team believes that scalable parallel programmers (and desktop parallel programmers, for that matter) would benefit greatly from a productive new language supporting better syntax, features and optimizations than today’s parallel notations offer. HPC has a rich set of lower-level technologies upon which to build and numerous failed parallel languages from which to learn. Despite naysayers and the inherent challenges, the Chapel team is driven by our desire for a better language and our interest in helping bring it about. We believe that the parallel computing community should absolutely continue striving for productive parallel languages. Today’s parallel programmers deserve better. And if we do our job right, we should have a whole lot more of them tomorrow.
So … flipping this series’ title back on you: “Why not a new language? Why not Chapel?”
For more information
For a longer-form version of this style of manifesto, please refer to a series of articles published on the IEEE TCSC blog under the title [Ten] Myths About Scalable Parallel Programming Languages. It addresses a similar series of opinions commonly expressed by those who are (understandably) skeptical about new languages, and it wrestles with them using a combination of counterarguments and evidence. You’ll find an index to the series here.
For a general introduction to Chapel, the best resource is A Brief Overview of Chapel, which provides a reasonably complete overview of Chapel—from history to motivating themes and features. Further information — including tutorials, presentations and papers — can be found on the Chapel project website. To download Chapel or subscribe to various community mailing lists, visit our SourceForge page. Ongoing Chapel development is taking place on our GitHub repository.