[TYPES] the possibly uselessness of semantics, was -- The type/object distinction and possible synthesis of OOP and imperative programming languages

[Matthias Felleisen]

On Apr 20, 2013, at 5:00 AM, Andreas Rossberg wrote:

> [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ]
> 
> On Apr 19, 2013, at 09:21 , Uday S Reddy <u.s.reddy at cs.bham.ac.uk> wrote:
>> Similarly, the mathematical models of programming languages help us to
>> obtain a deep understanding of how languages work and how to build systems
>> in a predictable, reliable way.  It seems too much to expect, at the present
>> stage of our field, that all programmers should understand the mathematical
>> models.  But I would definitely expect that programming language designers
>> who are trying to build new languages should understand the mathematical
>> models.  Otherwise, they would be like automotive engineers trying to build
>> cars without knowing any Mechanics.
> 
> Unfortunately, that has been the reality in the "Real World" for the last 40 years, and I'm pretty sure it will continue to be so for the next 40. In mainstream language design, formal training is the exception, not the rule. Most decision makers couldn't parse an operational semantics if their life depended on it. Let alone understand a denotational model or a type system.
> 
> I usually compare it to architects designing bridges without knowing the first thing about statics. It's sufficient qualification to have crossed bridges all your life. And if in doubt, a road sign always is an appropriate measure for preventing one from collapsing. Traffic participants are expected to bring parachutes.
> 
> To be fair, it took a few millennia before knowledge about statics prevailed among bridge builders, too.


A specific point: I am not really sure about this. I do know that the construction of temples and churches and other such buildings has been a driving force of applied mathematics for a couple of thousand years. I'd be happy to supply citations but since CS @ Rice was a descendant of App Math, I have heard this claim many times, I have read about it, and I have encountered it on tours (most recently in Istanbul last year concerning dome constructions. Also see the development of skyscrapers. We simply couldn't construct truly tall (greater than say a dozen or two dozen floors), stable buildings until a 120 or so years ago. The desire to do so forced us to figure out the materials (steel) and the mathematics. 

A general point, much more important. Even though I am as guilty as anyone on this list for working with mathematics and mathematical models of PLs, let me play the outsider for a moment. Let me raise three specific questions: 

Are we (theoretical PLers) developing tools and mechanisms that programming language developers truly need the way builders needed steel and the constructors of domes needed mathematics/static? I think the answer is obviously 'no' because few if any of our meta-tools make it into the tool set of working programming language designers. We may respond with "but they don't design languages the size of skyscrapers" and we'd be wrong again. When I look at the specs of CL or C++, I see skyscrapers :-) -- I will say that sometimes I think that working programming language developers don't even seem to understand interpreters, but who knows, perhaps I don't understand theirs. 

Are we (theoretical PL designers) developing linguistic mechanisms that programmers (software developers_ truly need the way builders needed steel and the constructors of domes needed mathematics/static? I think the answer is 'sometimes' but, and this is where your answer may apply -- it takes 20-30 years before most of our new mechanisms make it into the tool set of say, 1,000 working programmers. With good ones, it's faster. In this dimension, we're not the only ones who are guilty of making our ideas real, but we should question on occasion why it takes so long to get an idea from 'our side' to 'theirs'. 

Are we (theoretical PLers) using our tools and mechanisms the right way? Since very few languages have language designers on board who understand our work well (Meijer @ VB, Steele @ Java and Fortress are definitely exceptions) or perhaps the right phrase is 'appreciate it well enough', perhaps it is our obligation to show them how to use it on their languages.

-- We have done some of this work on our own production (reduction semantics for corners of Racket) and we find this exercise extremely useful (finding bugs, inconsistencies, etc). 

-- Shriram Krishnamurthi has applied this idea to JavaScript and Python, and he has also shown how to use these models to get useful work done for programmers. Also see his POPL 2013 talk on "programming languages as a natural phenomenon" or something like that. 

-- The K people around Grigore Rosu have tackled C and a range of other languages. 

I think if more of us did this kind of work, we would see two developments" 

1. Working programming language developers may figure out that our tools are useful and use them. 
2. We would figure out what kind of tools working language developers really need, and we might develop/change tools so that they are useful in the real world. 

I am sure there are other ways to go about closing the gap (e.g., working directly on commercial compilers/debuggers/bug finders), but we should share these ideas and work on them. 

-- Matthias