4 ms·

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

chrisseaton 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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...).
mpweiher 10y ago
Apologies for being a bit brief, it was late. First, I don't have specific things that were left out (well, maybe a few), it was more a sense of there is so much more, especially that I would want to know and feel I should know when creating a computer language. The important bits. First and foremost, programming languages are for people and for building systems. Except for CTM, that seems to be almost completely missing (and I had initially missed that it was actually on the list, so my bad). So anyway, if you want to have theory of programming languages, you have to have something about how people think and work and how that affects programming language design. As an example, I found John Pane's HANDS system very illuminating, or maybe the "Smalltalk: Bits of History, Words of Advice", which talks about iterating on language usability, or Henrik Gedenryd's thesis "How Designers Work". Not saying these are it, but just the flavour I'd be looking for. On the systems front, I think I'd want to see how problems building systems lead to features in programming languages, what the tradeoffs are etc. Again, without this, what's the point of a theory of programming language? And I do hope features in programming languages are trying to address actual problems building systems. Otherwise, it would be like having theories of engineering without talking about real world objects that we are trying to build such as airplanes, bridges or buildings. As a tiny and obvious example, what are the tradeoffs between more compile-time checking with longer compile times and more inscrutable errors and a more dynamic approach with much faster cycle times but less checking? And yes, there are tradeoffs. When you look at Hennessy/Patterson for Computer Architecture, you see (well understood?) tradeoffs that matter in terms of application. Yes, more registers are good, but then you have encode them in the ISA, and your path lengths increase and you need to save/restore more on a context switch, etc. One thing that should also definitely be on there is HOPL. Histories of people actually designing programming languages, trying to solve specific problems and then figuring out what worked, what didn't and why. Without some sort of reflection like this (=evidence), again, what's the point of even beginning to talk about a "theory" of programming language? Unless it's a definition of the word "theory" that I am not aware of.

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 10y ago
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 10y ago
  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 10y ago
    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...).

mpweiher 10y ago

Apologies for being a bit brief, it was late. First, I don't have specific things that were left out (well, maybe a few), it was more a sense of there is so much more, especially that I would want to know and feel I should know when creating a computer language. The important bits. First and foremost, programming languages are for people and for building systems. Except for CTM, that seems to be almost completely missing (and I had initially missed that it was actually on the list, so my bad). So anyway, if you want to have theory of programming languages, you have to have something about how people think and work and how that affects programming language design. As an example, I found John Pane's HANDS system very illuminating, or maybe the "Smalltalk: Bits of History, Words of Advice", which talks about iterating on language usability, or Henrik Gedenryd's thesis "How Designers Work". Not saying these are it, but just the flavour I'd be looking for. On the systems front, I think I'd want to see how problems building systems lead to features in programming languages, what the tradeoffs are etc. Again, without this, what's the point of a theory of programming language? And I do hope features in programming languages are trying to address actual problems building systems. Otherwise, it would be like having theories of engineering without talking about real world objects that we are trying to build such as airplanes, bridges or buildings. As a tiny and obvious example, what are the tradeoffs between more compile-time checking with longer compile times and more inscrutable errors and a more dynamic approach with much faster cycle times but less checking? And yes, there are tradeoffs. When you look at Hennessy/Patterson for Computer Architecture, you see (well understood?) tradeoffs that matter in terms of application. Yes, more registers are good, but then you have encode them in the ISA, and your path lengths increase and you need to save/restore more on a context switch, etc. One thing that should also definitely be on there is HOPL. Histories of people actually designing programming languages, trying to solve specific problems and then figuring out what worked, what didn't and why. Without some sort of reflection like this (=evidence), again, what's the point of even beginning to talk about a "theory" of programming language? Unless it's a definition of the word "theory" that I am not aware of.