How EuroDSL differentiates from other parallel programming approaches, and how we deliver the vision.
The goal is a common one: make it easy and more productive to write code that takes advantage of parallel hardware, and do so in a way that gets naturally adopted and rapidly spreads. Past approaches have focused on the technical aspects and attempted to create a "one size fits all" parallel language. That approach has been tried hundreds of times, with no success. It is a hard problem to solve, and has eluded researchers for decades.
The reason it is so hard is that it involves more than just technical aspects. It also involves human social factors. Other approaches ignore real world aspects of how people make decisions and what it is that is difficult for average programmers. That is where the DSL approach differentiates.. in the human side of things.
To be more specific, the human factors are related to adoption:
- Adoption -- people make the decision of whether to use a new language, so the language has to satisfy the decision making process. Briefly, it needs to be easy and fast to learn, it needs to fit with existing practices, and it needs to either solve an immediate and intense pain or else be trusted to give a strong advantage, without failing in any critical way (Ex failures: can't debug, or poor performance, or fits only a few kinds of problems),
DSLs as "langlets" that mix together in base sequential code fit all of these (when implemented as we propose in this project).
- On easy to learn.. DSL langlets have at most 10 constructs each, and they are natural to the domain the programmer is already familiar with. Hence, there is little to learn, no new concepts (those are part of the domain), just a few constructs. Typical time is an hour.
- Also on easy to learn, a DSL is designed by first watching what a typical programmer does, and collecting common patterns that they use that are related to the domain. Then, those patterns are turned into constructs. The code that used to embody those patterns is removed and replaced with the DSL construct. This means that the constructs are totally natural for the programmers.. no new concepts to learn.
- One big advantage is that productivity is increased, over sequential programming! Even though they are now writing parallel code, they get more done, faster, than if they were writing sequential code (that's because the chunks of sequential that embody the pattern don't have to be written anymore, that code is replaced by a single construct)
- Programmers don't need to modify their existing practices. By making the DSLs be "langlets" which embed into sequential code, an existing code base can be incrementally modified, and built using the same existing build system and development practices. They just start adding DSL constructs in, and linking to the dynamic libraries that embody the DSL langlet behavior. They have the option of either using API based invocations of the DSL behavior, or using custom syntax (with a source level debugger inside Eclipse).
- The pains that are solved include the pain of falling behind by not taking advantage of existing compute resources, and the pain of having to write difficult parallel code. This is where the technology behind the scenes comes in. This pain might be solvable by multiple different technical approaches. But it is the above four things that make the DSL approach adoptable by typical programmers, and differentiates it from "one size fits all" language approaches.
- The hundreds of "One size fits all" languages suffer critical flaws.. first, they have a high learning curve. Then the concepts are tuned to particular kinds of applications, whatever type the creator of the language was familiar with when they designed it. They don't play well with other languages, so the idea of mixing and matching isn't even an idea people entertain these days. Applications that don't fit the language's patterns require mental gymnastics from the programmer (they aren't free to switch to a different language that does fit the application). Languages that try to cover all bases, like X10, are a kitchen sink approach, that becomes bloated and confusing (and difficult to learn!).
The DSL langlet approach side-steps all of these critical flaws, while the technology behind delivers high performance. (The technology behind is the hard part that we will be solving in the project!)