
A Path to Programming Language Theory - rspivak
https://github.com/steshaw/plt
======
krat0sprakhar
I've been taking a PLT[0] class in school and while the list above is
extremely comprehensive and thorough, I'd argue that you do not need to read
up all of it to get a good idea of programming languages.

Without even learning all the theory, you can get pretty far ahead (IMHO) in a
building your own programming language (if that's the goal). The two resources
that I've found invaluable are - the prog lang course[1] by Dan Grossman and
PLAI[2] by Shriram. Lastly, there's also a whole bunch of interesting
university courses that you can refer to -
[https://github.com/prakhar1989/awesome-
courses#programming-l...](https://github.com/prakhar1989/awesome-
courses#programming-languages--compilers)

[0] -
[http://www.cs.columbia.edu/~sedwards/classes/2016/4115-sprin...](http://www.cs.columbia.edu/~sedwards/classes/2016/4115-spring/index.html)

[1] -
[https://www.coursera.org/course/proglang](https://www.coursera.org/course/proglang)

[2] -
[http://cs.brown.edu/courses/cs173/2012/book/](http://cs.brown.edu/courses/cs173/2012/book/)

~~~
tikhonj
There's a difference between learning about _programming languages_ and
learning about _programming language theory_. The class you linked is squarely
in the former camp. It's a bit confusing because they use PLT to stand for
"Programming Languages and Translators" where I usually see it referring to
"Programming Language Theory".

Honestly, "programming language theory" is a bit of a misnomer. It's less a
theory _for_ programming languages and more _a theory of CS from a language
perspective_. (Where theoretical CS is a theory of CS from a _computational_
point of view.)

Programming language theory is interesting in and of itself and is fairly
distinct from the sorts of things you'd learn in a normal programming
languages course or by implementing your own language. I'm not saying either
of those is useless—I'm a big fan of doing both!—just that they accomplish
fundamentally different things. Your advice is good if you just want to
implement a programming language; the linked repository is good if you want to
explore PL _theory_.

PL theory shares a lot with formal logic and the foundations of mathematics.
The main areas are things like type theory (a special approach to formal
logic) and semantics (akin to proof theory or model theory).

What you'll learn by reading the books linked above is almost completely
disjoint from what the class you linked covers.

------
cousin_it
I've spent a lot of time on learning these ideas. They are interesting in
themselves, but also because they come with a tantalizing promise of
usefulness. For me, that promise was never fulfilled. I suspect that's not
just bad luck. Creating programming languages is mostly a practical problem,
not a research problem. For example, type theory will never tell you that
garbage collection is a good idea, or which kind you should use.

My advice to younger folks looking at this field would be to turn back and
instead solve some practical problem by creative programming. Git or
BitTorrent would be good examples to emulate. Even a smaller project could
have more impact than the whole field of PL research combined.

------
infodroid
One thing that is sorely missing here is a section on motivation, which is
arguably the first step on the journey. Because I can see that learning PLT
will be hard. Yet most people are not going to learn PLT just because it is
hard. There must be _something more_ that makes it worthwhile. But I struggle
to appreciate why any programmer would want to learn PLT.

~~~
Xophmeister
Why does anyone learn anything? An intellectual pay-off is, to many, just as
valuable as the practical (and ultimately, presumably, economic) pay-off that
comes from learning a new skill. That might be seen by many others to be
"learning for learning's sake", but any research could potentially lead to
wider benefits.

That said, for die-hard-pragmatists, it seems reasonable to assume that
learning PLT might make one a better programmer.

------
Smaug123
I was struck by the category theory section, which starts with two fairly easy
books (Cheng and Awodey), a book I've never heard of, and then Mac Lane. Mac
Lane is a _fearsome_ book, which takes a lot of concerted effort and study for
me to read. I have had four years of the Cambridge Maths Tripos, so I am
(ahem) probably quite a bit more highly trained in mathematics than most
readers of this list, and Mac Lane is just barely on the edge of things I can
read. It should come with a health warning for its extreme difficulty and
abstraction; there's a reason it's in the "Graduate Texts" series.

~~~
thechao
I had the same feeling when Ben Pierce's introductory text was tossed casually
into the same list as HOTT. I mean... more power to you, but a few lines of
text are casually glossing over probably a decade of study for the reader.

------
gravypod
I know this might be a stupid question for some, but I have to ask anyway
because this will drive me crazy trying to figure this out on my own.

Why is this a 'theory', what makes this different from a documentation
different design patterns in programming languages?

~~~
rntz
It's basically a _certain kind_ of documentation of design patterns in
programming languages. PLT emphasizes the use of formal logic and mathematics.
It focuses on systems that can be rigorously defined, and theorems that can be
proven about them; as opposed to software engineering, which focuses on the
issues and patterns that crop up in the practice of developing software, or
HCI, which focuses on human factors.

Of course, all of these are overly broad generalizations, and it's not as if
there aren't points of intersection between these different ways of looking at
programming languages.

But the kind of stuff you'll see in a book like Types and Programming
Languages is super-different in approach from the kind of stuff you'd see in,
say, the Gang of Four book, both of which are different again from Bret
Victor's approach.

~~~
seanmcdirmid
> It's basically a certain kind of documentation of design patterns in
> programming languages.

PLT has become its own thing, and work in the area is not necessarily related
to PL. If you scan current papers at POPL, you'll see a trend of applying
language-oriented theory to problem X where X has nothing to do with
implementing/designing a programming language.

We can apply theory to PL, but many of the factors in a PL design today (or
yesterday) are not rooted in theory.

> But the kind of stuff you'll see in a book like Types and Programming
> Languages is super-different in approach from the kind of stuff you'd see
> in, say, the Gang of Four book, both of which are different again from Bret
> Victor's approach.

It is not even just the approach that is different, but the goals and
outcomes.

~~~
gravypod
Would you mind describing some of the goals, current problems, and some "must-
read" papers on the topic?

I'm in a university so I have access to most journals.

I'm very interested in learning more about this.

~~~
seanmcdirmid
PL is vastly huge, so you have to be more specific about "topic." What are you
interested in learning? I personally specialize in experience, and could list
many (what I consider seminal) papers that are not even on the radar for other
PL researchers.

------
Normal_gaussian
This is exactly what it says on the tin.

A path to enlightenment.

I've read a lot on these subjects already, but I am certainly saving this for
two reasons:

* Including papers and sections of books in my weekly reading

* I find it quicker to understand if I can grab a handful of explanations and critique them (often rewriting the confusing parts of several explanations once understood)

If you want an easy list, or a minimal list, this isn't it - and I am glad.

------
mpweiher
This seems very one-sided, skewing towards type-theory and functional
programming.

Is that what is taught these days? No wonder people think that's all there is.
:-(

~~~
mathetic
And what would be the omitted part of programming language theory?

~~~
chrisseaton
mpweiher could mean implementation theory, so things like how to write better
compiler analysis and optimisations and things like that, but in the academic
and research community I think that just isn't thought of as coming under the
term 'programming language theory'. It's not thought unimportant, it's just a
different topic, more grouped under 'systems'.

Looking at mpweiher's profile it looks like he might be interested in things
like metaprogramming and object protocols - again they're seen as either part
of the software engineering or systems disciplines rather than PLT.

~~~
chrismonsanto
I disagree that compiler analysis/optimizations would be considered under
'systems', I would expect that kind of work to be published in PLDI, which is
definitely the PL community. Systems is more OSDI/NSDI/SOSP.

Metaprogramming also has a rich history in traditional PL venues like POPL and
ICFP, such as the Scheme/Racket work on macros, Template Haskell and friends,
staged computation work a-la MacroML.

~~~
chrisseaton
I think POPL is PLT and PLDI is systems.

I say that I'm a systems person to signify that I want to talk about ASTs, IRs
and compiler output rather than core language models and formal semantics.

But you could argue about definitions all day.

The relevant observation is that the reason this list focuses on formalisms
like type theory and models we can reason about formally like FP is that this
is what we mean by PLT.

~~~
seanmcdirmid
You mean, systems in the OSDI/SOSP sense? Systems and PL implementation
(compilers) communities have always overlapped quite a bit, maybe more so a
decade ago than today (e.g. see Sanjay Ghemawat and Jeff Dean as PL people who
did systems who are now doing machine learning...).

------
paxcoder
I (and I'm sure others) would appreciate references to the minimal set of
things necessary to absorb to easily participate in the PLT discussion.

This is the opposite of that.

