Social Programming Language ConstructsAugust 2022<br>Social Programming Language Constructs

As programmers, we love to act as if everything is cut and dry, unaffected by social circumstances. The mindless execution of our code makes us believe that all aspects of coding practice are equally mindless, equally free from social influence and opinion. Perhaps we don’t consciously think this, we aren’t completely naive. And yet, I think, many of us would admit to that proclivity, that default assumption that code issues are cut and dry.<br>I want to call attention to one element of programming that is much more determined by our social situation than we generally recognize. A feature of programming that may feel set in stone that I believe is radically different depending on the social circumstances you find yourself in. These features of programming I want to dub “Social Programming Language Constructs”.<br>Let’s begin with the Wikipedia definition of language constructs:<br>A language construct is a syntactically allowable part of a program that may be formed from one or more lexical tokens in accordance with the rules of a programming language.<br>Here we find that cut and dryness we love about programming. We have two constraints placed on what makes something a language construct. It must be “syntactically allowable”, and must be used “in accordance with the rules of the programming language”. Perhaps this definition is lacking in some regards because these two rules don’t precisely identify what does and doesn’t count. It gives necessary, but not sufficient criteria for what is and isn’t a language construct.<br>And yet, I think most of us have a good grasp of this. Controls flow operators are language constructs. Classes (in java) are language constructs. Type Classes in Haskell are language constructs. As follows directly from the definition, what is and isn’t a language construct is language-dependent.<br>The Languages we use<br>My goal here is not to dispute this definition. Not in its wording nor even in spirit. There are of course these cut-and-dry language constructs, they are real. But what I want to call attention to is another notion of language construct that I think is equally real, and perhaps more impactful. The notion of a Social Language Construct. Simply put, it is the idea that what is and isn’t “syntactically allowable” depends not just on your compiler/interpreter, but on the social environment in which you write code.<br>Perhaps this claim seems ridiculous, let’s start by making it seem less so. What is and isn’t syntactically allowable depends on your language's compiler/interpreter. But not just the language in general, but the concrete version you use. If you are programming in K&R C, there are certain syntactic patterns that aren’t valid in more modern C implementations. If you are programming in plain vanilla, uncompiled javascript, what is and isn’t syntactically valid depends on what browsers you want to support.<br>But in real systems, syntactically valid often becomes more strict than just what the compiler/interpreter allows. We add extra layers onto our syntactic validity checking via linting. Once we have added errors to our linter, we have not added additional constraints on what is syntactically valid.<br>In other words, we have made a new language. If a programming language at a bare minimum decides what things are syntactically valid, our new restriction has made a new language that is a subset of our existing language. Now because it is a subset, it isn’t radically different. Hopefully, we have made the language simpler in some regards, eliminating certain foot guns.<br>What Counts as Syntactically Valid<br>Hopefully, a linter defining a new meaning of syntactically valid doesn’t seem too radical. But in what way is a linter social? Well if the linter's rules were not decided by you, but instead by other people, through some social negotiation process, or perhaps through a power relation, those lint rules owe their existence to social factors. Or in other words, absent that particular social situation, what is syntactically valid for you would change.<br>But are linter's the only way we can change what is “syntactically valid”? Is something only syntactically invalid if a process returns a non-zero exit value? Or can code review change what it means to be “syntactically valid”? If my code can never be merged to master, never be deployed because it doesn’t meet some check, is it meaningfully syntactically valid?<br>Trying to make a meaningful difference between these things seems to be a waste of time. Absent an automated linter, if my code won’t ever be merged if, for example, I use goto, the language I’m working with does not meaningfully have goto. goto is no longer syntactically valid for me.<br>A Socially Defined Language<br>If social structures can merely limit what is syntactically valid, and therefore limit what counts as a programming language construct, they might not be that interesting. But it goes beyond...