Use of Process Calculi and PL Theory for modern programming language development For a while now, I have been very interested in programming language theory and process calculi and have started to study them. To be honest, it something that I wouldn't mind going into for a career. I find the theory to be incredibly fascinating. One constant question I keep running into is if either PL Theory or Process Calculi have any importance at all in modern programming language development. I see so many variants on the Pi-calculus out there and there is a lot of active research, but will they ever be needed or have important applications? The reason why I ask is because I love developing programming languages and the true end goal would be to use the theory to actually build a PL. For the stuff I have written, there really has not been any correlation to theory at all.
My answer is really just an elaboration of Gilles', that I had not
read before I wrote mine. Maybe it's nevertheless helpful.

Let me begin my attempt at answering your question with a distinction
between two dimensions of programming languages work that relate quite
differently to programming language theory in general and process
calculus in particular.


Pure research.
Product focused research and development.


The latter typically takes place in industry with the aim of providing
programming languages as a product. The teams developing Java at
Oracle and C# at Microsoft are examples.  In contrast, pure research
is not tied to products. Its aim is to understand programming
languages as objects of intrinsic interest and to explore the
mathematical structures underlying all programming languages.

Because of divergent goals, Different aspects of programming language
theory are relevant in pure research and in product focused R&amp;D The
picture below may give an indication what's important where.



One may ask at this point why the two dimensions are so seemingly
different and how they nevertheless relate.

The key insight is that programming language research and development
has multiple dimensions: technical, social and economic.  Almost by
definition, industry is interested in the economic payoff of
programming languages. Microsoft et al don't develop languages out of
the goodness of their hearts but because they believe programming
languages give them an economic advantage.  And they have investigated
deeply why some programming languages succeed, and others, seemingly
similar or with more advanced features, don't.  And they found that
there isn't a single reason. Programming languages and their
environments are complex, and so are the reasons for adopting or
ignoring any specific language.  But the single biggest factor for the
success of a programming language is the preferential attachment of
programmers to languages that are already widely used: the more people
use a language, the more libraries, tools, teaching material are
available, and the more productive a programmer can be using that
language. This is also called the network effect. Another reason is
the the high cost switching languages for individuals and
organisation: mastering language, especially to a not-so-experienced
programmer, and when the semantic distance to familiar languages is
large, is a serious, time-consuming effort.  Given these facts, one
may ask why do new languages get traction at all?  Why do companies
develop new languages at all? Why don't we just stay with Java or
Cobol?  I think there are several key reasons for whey a language does
succeed, and displaces the originally more popular incumbents.


A new domain of programming opens up that has no incumbents to
displace.  The primary example is the web with its concomitant rise
of Javascript.
Language stickiness. By this I mean the high price of changing
language. But sometimes programmers move into different fields,
taking a programming language with them, and being successful with
the old language in the new field.
A language is pushed by a big company with serious financial
firepower. This backing reduces the risk of adoption, because early
adopters can be reasonably sure that the language will still be
supported in a few years. A good example of this is C#.
A language might come with compelling tools and eco-system. Here too
C# and it's .Net and Visual Studio eco-system could be mentioned as
an example.
Old languages pick up new features. Java comes to mind, which, in
each iteration, picks up more good ideas from the functional
programming tradition.
Finally, a new language might have intrinsic technical advantages,
e.g. be more expressive, have nicer syntax, typing systems that
catch more errors, etc.


Given this background, it should not come as a surprise that there is
somewhat of a disconnect between pure programming language research,
and commercial programming language development. While both aim to
make software construction and evolution more efficient, especially
for large-scale software, industrial programming language work must be
more interested in facilitating quick adoption to reach a critical
mass and get the network effect.  This leads to a research focus on
things that working programmers care about. And that tends to be
things like library availability, compiler speed, quality of compiled
code, portability and so on.  Process calculus as we practise it today
is of little use to programmers working on mainstream projects
(although I believe that will change in the future).

Pure programming language research is quite different. It works with
simplified models of programming languages: the $\lambda$-calculus is
a massive simplification of functional programming. In the same way
the $\pi$-calculus is a massive simplification of concurrent
programming. These massive simplifications are the key to successful
research. They enable us to focus on core computational mechanisms
(e.g. $\beta$-reduction for functional programming,
resolution/unification for logic-programming, name-passing for
concurrent computation). To understand if a language like Scala can
have viable full type-inference, we don't need to worry about the JVM.
Indeed thinking about the JVM will detract from a better understanding
of type-inference. That's why abstraction of computation into tiny
core calculi is vital and powerful.

So you can think of programming language research as a massive sandbox
where people play with toys, and if they find something interesting
when playing with a specific toy, and have investigated the toy
thoroughly, then that interesting toy begins its long march towards
mainstream industrial acceptance. I say long march because language
features first invented by programming language researcher tend to
take decades before becoming widely accepted. For example garbage
collection was conceived in the 1950s and became widely available with
Java in the 1990s. Pattern matching harks back to 1970 and is widely
used only since Scala.

Process calculus is an especially interesting toy.  But it's too new
to be investigated thoroughly. That will take another decade of pure
research.  What currently going in process theory research is to take
the single biggest success story of programming language research, the
theory of (sequential) types and develop the theory of types for
message passing concurrency.  Typing systems of moderate expressivity
for sequential programming, say Hindley-Milner, are now
well-understood, ubiquitous and accepted by working programmers.  We'd
like to have moderately expressive types for concurrent programming.
Research on this started in the 1980s by pioneers like Milner,
Sangiorgi, Turner, Kobayashi, Honda, and others, often based,
explicitly or implicitly, on the idea of linearity which comes from
linear logic.  The last few years have seen a major increase in
activity and I expect this upwards trajectory to continue for the
foreseeable future. I also expect this work to start leaking into
product focused R&amp;D, in parts for the pragmatic reason that young
researchers who have been trained in process calculus will go and work
in industrial R&amp;D labs, but also because of the evolution of CPU and
computer architecture away from sequential forms of computation.

In summary, I would not worry that you don't find cutting edge
programming language theory such as process calculus useful in your
own work of building languages. That's simply because cutting edge
theory does not address the concerns of current programming
languages. It is about future languages. It will take a while for the
'real world' to catch up. The knowledge you use to build languages for
today is the programming language theory of the past.  I encourage you
to learn more about process calculus because it's one of the most
exiting areas of all of theoretical computer science.