<p>The overall purpose of PLT is to make industrial software 
engineering (in a general sense) <strong>cheaper</strong> (also in a general sense), through optimising the most
important tool (programming languages) and associated tooling
ecosystem.</p>

<p>Some reasons why maths is involved:</p>

<ul>
<li><p>PLs are <em>highly</em> non-trivial, and it's not clear that  they
do the right thing without proof. The maths gives a <em>simplified</em> model
of real programming languages. This model lets us study real programming languages in a much simplified setting, removing (hopefully) most problems already at the model level. Real programming languages are currently mathematically intractable. In other words: <strong>lambda-calculus is the fruit-fly, the E.Coli, the <a href="https://en.wikipedia.org/wiki/Spherical_cow" rel="noreferrer"><em>spherical cow</em></a> of PLT.</strong></p></li>
<li><p>PLT lacks suitable empirical methods, which would be nice / better
to have, so maths is done as a substitute.</p></li>
<li><p>The maths is beautiful and deep.</p></li>
<li><p>The maths gives a simple, tried and tests research methodology, which  is  important for helping one's  PhD students graduate. Typically, some variant of e.g.:
Investigate PL feature XYZ through adding it to lambda-calculus. 
Add simple types for XYZ and prove type-soundness.
Add generics for XYZ and prove type-soundness.
Prove a parametricity theorem for XYZ generics.
Add dependent types for XYZ and prove type-soundness.
Develop a partial type-inference for XYZ dependent types.
Add gradual types for XYZ and prove type-soundness. 
Add contracts for XYZ.
Each of those is a paper.  You can stop if your PhD student or postdoc runs out of time.  Each of the above is interesting and will yield insight about generics, parametricity, type inference etc.  This pipeline is a <em>great</em> way of navigating the difficult waters of all possible programming languages. A second way of learning is implementing languages in a compiler, but that's less tractable for an individual.</p></li>
</ul>

<p>Whether PLT is needed is an interesting question. Most working
programmers seem to think it's not. They are wrong: most languages developed by
working programmers without a PLT background    (e.g. Javascript, PHP)
start out terrible, and make all the mistakes that PL theorists
long learned how to avoid. If a PL developed by an amateur hits the
mainstream, PL theorists need a decade or so fixing the obvious flaws
(e.g retrofitting a static typing system, see Typescript). Let me summarise this situation:</p>

<pre><code> Every successful programming language ends up being ML! Either because 
 it was designed by a PL theorist as ML from the start, or because a 
 decade of painful evolution removes all the obvious flaws, leaving ML. ;-)
</code></pre>

<p><sup><strong>Aside:</strong>
This state of affairs is entirely   the fault of PLT because because most of them have no industrial programming
experience, so don't really know what the pain points of working
software engineers are. In particular, for sociological reasons, most
PL theorists think that pure functional programming in languages like
Agda is the solution to all problems, which does not stand up to scrutiny.</sup></p>

CC BY-SA 4.0
2019-04-16T08:55:19.613Z
See also this related question on the [Use of Process Calculi and PL Theory for modern programming language development](https://cstheory.stackexchange.com/questions/24884/use-of-process-calculi-and-pl-theory-for-modern-programming-language-development?rq=1)
Martin Berger
CC BY-SA 4.0
2019-04-16T18:34:28.537Z
Please write in full what "ML" is. I only know ML as machine learning :)
Thatchaphol
CC BY-SA 4.0
2019-04-16T19:16:51.583Z
@Thatchaphol ML in this context is a [programming language, designed by Robin Milner and colleagues in the 1970s](https://en.wikipedia.org/wiki/ML_(programming_language)). These days ML proper is rarely used any more, but language in the ML tradition are widespread.
Martin Berger
CC BY-SA 4.0
2019-04-16T23:46:10.410Z
@MartinBerger - Thanks for the enlightening answer and the link to the other question. I sincerely admire the vehemence that oozes from your answers! Yes, I have always understood the theoretical models to be fruit-flys and I do see them that way. Perhaps, the greater "divide" that you've alluded to (here and elsewhere) can be summarized into a follow up question: What features from PLT have actually made it into mainstream languages? _That_ isn't easily apparent. E.g.: Garbage collection was invented for LISP AFAIK but not from PLT, corrrect?
PhD
CC BY-SA 4.0
2019-04-16T23:48:55.277Z
@MartinBerger - also, LISP _only_ borrowed the "function syntax" from lambda and threw out everything else IMO (loosely speaking). This "divide" between research and practice seems rather big for PLT IMHO. A good reference would be one that could walk through "time" from CL to Lambda to <something> and show _how_ it fed into a programming language. I don't mind if that reference culminates in `ML`. From ML I should be able to make the leap to other languages. I really struggle to "see" the big picture vs. guessing it. Any suggestions?
PhD
CC BY-SA 4.0
2019-04-16T23:52:28.243Z
@MartinBerger - it seems PLT is almost equivalent to "type theory" i.e., marrying type theory and programming. Creation of type systems, compilers, automatic inferencing of types etc., seems to make lot of sense for the application of PLT - but I'm yet to see something "radically more productive" than non-PLT informed languages like C/C++, Java, C# etc., I'm all for having a strong "type system" and I can see how PLT feeds into that. But that's _all_ "I" have been able to see and appreciate. Any existing references, papers, books that you could point to, would be greatly appreciated! _/\\_
PhD
CC BY-SA 4.0
2019-04-17T13:40:35.097Z
@MartinBerger: Does [CompCert](http://compcert.inria.fr) count as an example of being able to handle a real-world programming language "theoretically"? If not, how high are you setting the bar, because CompCert is pretty impressive.
Andrej Bauer
CC BY-SA 4.0
2019-04-17T13:42:43.560Z
@MartinBerger: Please consider watering down "most PL theorists think that pure functional programming in languages like Agda is the solution to all problems" because that's just your ranting and venting. For starters, even if you look at the topics that are currently present at ICFP and POPL, the majority is about *impure* programming languages.
Andrej Bauer
CC BY-SA 4.0
2019-04-17T13:43:28.250Z
@PhD: there is a lot more to PLT than type theory. It's just that type theory is the first thing that you notice because it is one of the main tools of PLT.
Andrej Bauer
CC BY-SA 4.0
2019-04-17T18:07:33.660Z
@AndrejBauer - totally agreed. See my response to your comment above to throw more light on my narrow POV. I was this close "(.)" to mailing you directly to seek some direction in this regard but then posted here first to get some initial insights before asking more pointed questions.
PhD
CC BY-SA 4.0
2019-04-17T21:46:18.853Z
@Thatchaphol Technically, ML written out in full is "Meta-Language", but that would probably leave you more confused. So, no, it's a proper noun like "C" and it doesn't stand for anything.
xrq
CC BY-SA 4.0
2019-04-17T21:52:49.870Z
@PhD A lot of interesting things in PLT have nothing to do with types, and there are many good PL theorists who prefer not to work with them. Control structures (call/cc and delimited continuations), hygiene macros, contracts, many forms of metaprogramming, logic programming, etc. You name it.
xrq
CC BY-SA 4.0
2019-04-18T08:46:47.183Z
@AndrejBauer CompCert, CakeML etc are impressive, but they are far away from widely used compilers like LLVM, GCC etc. Moreover, compilers, unlike just about any real world software, do have a  (kind-of / sort-of) specification, which you just don't get in normal industrial software engineering. Not to mention that a great part of Xavier's early work on CompCert consisted of precisifying the specification.
Martin Berger
CC BY-SA 4.0
2019-04-18T08:47:38.470Z
@AndrejBauer regarding "watering down", consider a spherical PL theorist in a vacuum ...
Martin Berger
CC BY-SA 4.0
2019-04-18T08:52:13.590Z
@PhD regarding "What features from PLT have actually made it into mainstream languages?" The list is way too long to spell out in full, most of which you take for granted. Here are but a few that come to mind:
Lexer and parser generators,
Type inferene (partial or full),
Parametric polymorphism,
Higher kinds,
Monadic approaches,
Higher order functions,
Pattern matching,
Exceptions,
Linear / affine typing systems (cf Rust),
Message passing,
Actors,
Module systems,
Unification of imperative, OO and functional programming ,
CPS transforms, continuations as a language construct ...
Martin Berger
CC BY-SA 4.0
2019-04-18T08:52:42.363Z
@PhD (continued from above) Intermediate representations,
SSA form,
Concepts like full abstraction (vital in security),
Secure information flow -- quantitative or qualitative,
Memory models,
Program extractiun from correctness proofs,
Program verification,
Program logics,
Static analysis,
Abstract interpretation,
Model checking,
Interactive proof assistants,
Program synthesis. Etc etc. All of the above are now research subfields of their own.
Martin Berger
CC BY-SA 4.0
2019-04-18T08:57:51.990Z
@PhD Regarding ""radically more productive" than
> non-PLT  C/C++, Java, C#", please bear in mind that if you look at those languages, more specifically, their evolution
over time, almost everything they've acquired over time, e.g. lambdas,
monads (LINQ), pattern matching, partial type inference comes from
PLT. The C# team has PLT PhDs. Indeed they tried to hire me at some point. The job interview was me trying to convince  Anders Heijlsberg that C# needs generics, which he didn't like at the time ...
Martin Berger
CC BY-SA 4.0
2019-04-18T09:00:06.027Z
@PhD I'm afraid there is no good history of PLT as far as I'm aware.  Regarding GC and Lisp, at the time computer science hadn't differentiated into subfields, it was "one". I understand PL as anything that you might want to know when writing compilers (in a wide sense).
Martin Berger
CC BY-SA 4.0
2019-04-18T09:02:38.217Z
@PhD Regarding "radically more productive", apart from the languages you mention being deeply influeced by PL research, there is a measurement problem: PLT has a major problem
in that there is no good way of empirically validating claims that PL
feature XYZ is more/less productive than feature ABC. We do little
more than trade anecdotes here. (Naturally PL is not the only field
that has this problem). It's unclear how to overcome this problem. At least we should be *honest* that we are trading non-reproducible anecdotes when 'evaluating' productivity of PLs.
Martin Berger
CC BY-SA 4.0
2019-04-18T22:27:22.440Z
@MartinBerger and xuq01 Thank you! I honestly feel kind of embarrassed ^^"
Thatchaphol
CC BY-SA 4.0
2019-04-16T08:51:46.283Z
2019-04-16T09:31:55.317Z
2019-04-16T09:31:55.317Z
Martin Berger
<p>I've been interested in various topics like Combinatory Logic, Lambda Calculus, Functional Programming for a while and have been studying them. However, unlike the "Theory of Computation" which strives to answer the question of "computability" i.e., things that can/cannot be computed with various constraints, I'm struggling to find the analog for "Theory of Programming"</p>

<p><a href="https://en.wikipedia.org/wiki/Programming_language_theory" rel="noreferrer">Wikipedia</a> describes it as:</p>

<blockquote>
  <p>Programming language theory (PLT) is a branch of computer science that
  deals with the design, implementation, analysis, characterization, and
  classification of programming languages and their individual features.</p>
</blockquote>

<p>This is like saying "everything" which isn't really specific.</p>

<p>The common progression of the topics is usually like so:</p>

<blockquote>
  <p>Combinatory Logic > Lambda Calculus > Martin Lof Type Theory > Typed Lambda Calculus > (Something happens here) > Programming languages developed - that have <em>very little</em> connection with CL/<span class="math-container">$\lambda$</span></p>
</blockquote>

<p>I can see the underlying "math" involved with CL/<span class="math-container">$\lambda$</span> and interesting proofs that come out as a result including the Church-Rosser theorem and that's neat. However, I'm struggling to understand the "end goal" of all this undertaking? What's the <em>holy grail</em> of PLT if you will? For now it seems to just be scratching an intellectual itch but I can't really cross the bridge from research/theory to anything practical.</p>

<p>Note: I do get it up until using the <span class="math-container">$\lambda$</span>-calc for undecidability proofs. But beyond its applicability to "computability" I just don't get it and am having a hard time even understanding the need for research in PLT from this narrow POV. Any existing books, references that can throw light on the "big picture" of PLT?</p>

CC BY-SA 4.0
2019-04-17T13:53:02.080Z
Your're totally ignoring whole swaths of PLT in your "common progression". For some reason your view seems to be skewed by $\lambda$-calculus and type theory. Let us have a look at the [POPL 2019 accepted papers](https://popl19.sigplan.org/track/POPL-2019-Research-Papers#event-overview): concurrent randomized programming, probabilistic programming, verifiable assembly, algebraic effects, certifying neural networks, PL and hardware weak-memory models, quantum programming, etc. Lots of things which are not "just type theory", wouldn't you say?
Andrej Bauer
CC BY-SA 4.0
2019-04-17T18:04:40.313Z
You're 100% correct. Hence I called out my "narrow POV". I am familiar with the "other topics" only by reading around here and checking out SIGPLAN/POPL Proceedings. I'm yet to find a "holistic reference/book" that gives a broad brush overview of PLT that *includes* the topics you mentioned. The type-theory bit is only from "my" POV of (creating?) programming languages. Would you have some pointers that could provide high-level introductions to the various areas of PLTto get a big picture overview? I'm curious to know what underlying "models" do they use and how? $\lambda$  everywhere?
PhD
CC BY-SA 4.0
2019-04-18T13:27:38.817Z
@PhD There is no  high-level introductions to the various areas of PLT that you want, *c'est la vie*! Maybe one day this will change. But don't hold your breath. The field is evolving fast, and differentiating itself into subfields. Other popular simple models include $\pi$-calculus, structural operational semantics, simple imperative calculi (like the WHILE language) and numerous others. Often one invents a toy calculus to suit one's application domain.
Martin Berger
CC BY-SA 4.0
2024-04-20T16:12:47.197Z
The question PLT tries to answer is "How to design a great programming language". A language that helps the programmer avoid errors, where code is short and readable, etc.etc. The approach is mathematical. The best answer so far is "some sort of functional programming language with a powerful type system".
winitzki
<soft-question><pl.programming-languages><lambda-calculus><big-picture><combinatory-logic>
What is the "question" that programming language theory is trying to answer?
PhD
# What is the "question" that programming language theory is trying to answer?

(Asked by: username_0 on 2019-04-16)

I've been interested in various topics like Combinatory Logic, Lambda Calculus, Functional Programming for a while and have been studying them. However, unlike the "Theory of Computation" which strives to answer the question of "computability" i.e., things that can/cannot be computed with various constraints, I'm struggling to find the analog for "Theory of Programming"

[Wikipedia](https://en.wikipedia.org/wiki/Programming_language_theory) describes it as:

> Programming language theory (PLT) is a branch of computer science that
> deals with the design, implementation, analysis, characterization, and
> classification of programming languages and their individual features.

This is like saying "everything" which isn't really specific.

The common progression of the topics is usually like so:

> Combinatory Logic > Lambda Calculus > Martin Lof Type Theory > Typed Lambda Calculus > (Something happens here) > Programming languages developed - that have *very little* connection with CL/$\lambda$

I can see the underlying "math" involved with CL/$\lambda$ and interesting proofs that come out as a result including the Church-Rosser theorem and that's neat. However, I'm struggling to understand the "end goal" of all this undertaking? What's the *holy grail* of PLT if you will? For now it seems to just be scratching an intellectual itch but I can't really cross the bridge from research/theory to anything practical.

Note: I do get it up until using the $\lambda$-calc for undecidability proofs. But beyond its applicability to "computability" I just don't get it and am having a hard time even understanding the need for research in PLT from this narrow POV. Any existing books, references that can throw light on the "big picture" of PLT?

**Tags:** soft-question, pl.programming-languages, lambda-calculus, big-picture, combinatory-logic
> **Comments:**
> **username_1**: Your're totally ignoring whole swaths of PLT in your "common progression". For some reason your view seems to be skewed by $\lambda$-calculus and type theory. Let us have a look at the [POPL 2019 accepted papers](https://popl19.sigplan.org/track/POPL-2019-Research-Papers#event-overview): concurrent randomized programming, probabilistic programming, verifiable assembly, algebraic effects, certifying neural networks, PL and hardware weak-memory models, quantum programming, etc. Lots of things which are not "just type theory", wouldn't you say?  
> **username_0**: You're 100% correct. Hence I called out my "narrow POV". I am familiar with the "other topics" only by reading around here and checking out SIGPLAN/POPL Proceedings. I'm yet to find a "holistic reference/book" that gives a broad brush overview of PLT that *includes* the topics you mentioned. The type-theory bit is only from "my" POV of (creating?) programming languages. Would you have some pointers that could provide high-level introductions to the various areas of PLTto get a big picture overview? I'm curious to know what underlying "models" do they use and how? $\lambda$  everywhere?  
> **username_2**: @PhD There is no  high-level introductions to the various areas of PLT that you want, *c'est la vie*! Maybe one day this will change. But don't hold your breath. The field is evolving fast, and differentiating itself into subfields. Other popular simple models include $\pi$-calculus, structural operational semantics, simple imperative calculi (like the WHILE language) and numerous others. Often one invents a toy calculus to suit one's application domain.  
> **username_3**: The question PLT tries to answer is "How to design a great programming language". A language that helps the programmer avoid errors, where code is short and readable, etc.etc. The approach is mathematical. The best answer so far is "some sort of functional programming language with a powerful type system".  

---

## 1 answers

### Answer by username_2 on 2019-04-16. Score: 19

The overall purpose of PLT is to make industrial software 
engineering (in a general sense) cheaper (also in a general sense), through optimising the most
important tool (programming languages) and associated tooling
ecosystem.
Some reasons why maths is involved:

PLs are highly non-trivial, and it's not clear that  they
do the right thing without proof. The maths gives a simplified model
of real programming languages. This model lets us study real programming languages in a much simplified setting, removing (hopefully) most problems already at the model level. Real programming languages are currently mathematically intractable. In other words: lambda-calculus is the fruit-fly, the E.Coli, the spherical cow of PLT.
PLT lacks suitable empirical methods, which would be nice / better
to have, so maths is done as a substitute.
The maths is beautiful and deep.
The maths gives a simple, tried and tests research methodology, which  is  important for helping one's  PhD students graduate. Typically, some variant of e.g.:
Investigate PL feature XYZ through adding it to lambda-calculus. 
Add simple types for XYZ and prove type-soundness.
Add generics for XYZ and prove type-soundness.
Prove a parametricity theorem for XYZ generics.
Add dependent types for XYZ and prove type-soundness.
Develop a partial type-inference for XYZ dependent types.
Add gradual types for XYZ and prove type-soundness. 
Add contracts for XYZ.
Each of those is a paper.  You can stop if your PhD student or postdoc runs out of time.  Each of the above is interesting and will yield insight about generics, parametricity, type inference etc.  This pipeline is a great way of navigating the difficult waters of all possible programming languages. A second way of learning is implementing languages in a compiler, but that's less tractable for an individual.

Whether PLT is needed is an interesting question. Most working
programmers seem to think it's not. They are wrong: most languages developed by
working programmers without a PLT background    (e.g. Javascript, PHP)
start out terrible, and make all the mistakes that PL theorists
long learned how to avoid. If a PL developed by an amateur hits the
mainstream, PL theorists need a decade or so fixing the obvious flaws
(e.g retrofitting a static typing system, see Typescript). Let me summarise this situation:
 Every successful programming language ends up being ML! Either because 
 it was designed by a PL theorist as ML from the start, or because a 
 decade of painful evolution removes all the obvious flaws, leaving ML. ;-)

Aside:
This state of affairs is entirely   the fault of PLT because because most of them have no industrial programming
experience, so don't really know what the pain points of working
software engineers are. In particular, for sociological reasons, most
PL theorists think that pure functional programming in languages like
Agda is the solution to all problems, which does not stand up to scrutiny.

> **Comments:**
> **username_2**: See also this related question on the [Use of Process Calculi and PL Theory for modern programming language development](https://cstheory.stackexchange.com/questions/24884/use-of-process-calculi-and-pl-theory-for-modern-programming-language-development?rq=1)  
> **username_4**: Please write in full what "ML" is. I only know ML as machine learning :)  
> **username_2**: @Thatchaphol ML in this context is a [programming language, designed by Robin Milner and colleagues in the 1970s](https://en.wikipedia.org/wiki/ML_(programming_language)). These days ML proper is rarely used any more, but language in the ML tradition are widespread.  
> **username_0**: @MartinBerger - Thanks for the enlightening answer and the link to the other question. I sincerely admire the vehemence that oozes from your answers! Yes, I have always understood the theoretical models to be fruit-flys and I do see them that way. Perhaps, the greater "divide" that you've alluded to (here and elsewhere) can be summarized into a follow up question: What features from PLT have actually made it into mainstream languages? _That_ isn't easily apparent. E.g.: Garbage collection was invented for LISP AFAIK but not from PLT, corrrect?  
> **username_0**: @MartinBerger - also, LISP _only_ borrowed the "function syntax" from lambda and threw out everything else IMO (loosely speaking). This "divide" between research and practice seems rather big for PLT IMHO. A good reference would be one that could walk through "time" from CL to Lambda to <something> and show _how_ it fed into a programming language. I don't mind if that reference culminates in `ML`. From ML I should be able to make the leap to other languages. I really struggle to "see" the big picture vs. guessing it. Any suggestions?  
> **username_0**: @MartinBerger - it seems PLT is almost equivalent to "type theory" i.e., marrying type theory and programming. Creation of type systems, compilers, automatic inferencing of types etc., seems to make lot of sense for the application of PLT - but I'm yet to see something "radically more productive" than non-PLT informed languages like C/C++, Java, C# etc., I'm all for having a strong "type system" and I can see how PLT feeds into that. But that's _all_ "I" have been able to see and appreciate. Any existing references, papers, books that you could point to, would be greatly appreciated! _/\\_  
> **username_1**: @MartinBerger: Does [CompCert](http://compcert.inria.fr) count as an example of being able to handle a real-world programming language "theoretically"? If not, how high are you setting the bar, because CompCert is pretty impressive.  
> **username_1**: @MartinBerger: Please consider watering down "most PL theorists think that pure functional programming in languages like Agda is the solution to all problems" because that's just your ranting and venting. For starters, even if you look at the topics that are currently present at ICFP and POPL, the majority is about *impure* programming languages.  
> **username_1**: @PhD: there is a lot more to PLT than type theory. It's just that type theory is the first thing that you notice because it is one of the main tools of PLT.  
> **username_0**: @AndrejBauer - totally agreed. See my response to your comment above to throw more light on my narrow POV. I was this close "(.)" to mailing you directly to seek some direction in this regard but then posted here first to get some initial insights before asking more pointed questions.  
> **username_5**: @Thatchaphol Technically, ML written out in full is "Meta-Language", but that would probably leave you more confused. So, no, it's a proper noun like "C" and it doesn't stand for anything.  
> **username_5**: @PhD A lot of interesting things in PLT have nothing to do with types, and there are many good PL theorists who prefer not to work with them. Control structures (call/cc and delimited continuations), hygiene macros, contracts, many forms of metaprogramming, logic programming, etc. You name it.  
> **username_2**: @AndrejBauer CompCert, CakeML etc are impressive, but they are far away from widely used compilers like LLVM, GCC etc. Moreover, compilers, unlike just about any real world software, do have a  (kind-of / sort-of) specification, which you just don't get in normal industrial software engineering. Not to mention that a great part of Xavier's early work on CompCert consisted of precisifying the specification.  
> **username_2**: @AndrejBauer regarding "watering down", consider a spherical PL theorist in a vacuum ...  
> **username_2**: @PhD regarding "What features from PLT have actually made it into mainstream languages?" The list is way too long to spell out in full, most of which you take for granted. Here are but a few that come to mind: Lexer and parser generators, Type inferene (partial or full), Parametric polymorphism, Higher kinds, Monadic approaches, Higher order functions, Pattern matching, Exceptions, Linear / affine typing systems (cf Rust), Message passing, Actors, Module systems, Unification of imperative, OO and functional programming , CPS transforms, continuations as a language construct ...  
> **username_2**: @PhD (continued from above) Intermediate representations, SSA form, Concepts like full abstraction (vital in security), Secure information flow -- quantitative or qualitative, Memory models, Program extractiun from correctness proofs, Program verification, Program logics, Static analysis, Abstract interpretation, Model checking, Interactive proof assistants, Program synthesis. Etc etc. All of the above are now research subfields of their own.  
> **username_2**: @PhD Regarding ""radically more productive" than > non-PLT  C/C++, Java, C#", please bear in mind that if you look at those languages, more specifically, their evolution over time, almost everything they've acquired over time, e.g. lambdas, monads (LINQ), pattern matching, partial type inference comes from PLT. The C# team has PLT PhDs. Indeed they tried to hire me at some point. The job interview was me trying to convince  Anders Heijlsberg that C# needs generics, which he didn't like at the time ...  
> **username_2**: @PhD I'm afraid there is no good history of PLT as far as I'm aware.  Regarding GC and Lisp, at the time computer science hadn't differentiated into subfields, it was "one". I understand PL as anything that you might want to know when writing compilers (in a wide sense).  
> **username_2**: @PhD Regarding "radically more productive", apart from the languages you mention being deeply influeced by PL research, there is a measurement problem: PLT has a major problem in that there is no good way of empirically validating claims that PL feature XYZ is more/less productive than feature ABC. We do little more than trade anecdotes here. (Naturally PL is not the only field that has this problem). It's unclear how to overcome this problem. At least we should be *honest* that we are trading non-reproducible anecdotes when 'evaluating' productivity of PLs.  
> **username_4**: @MartinBerger and xuq01 Thank you! I honestly feel kind of embarrassed ^^"  

---

