Lambda the Ultimate

This recent article on nano-weaves seems relevant.

A program takes a systematic approach to something, right?

A programmer follows whatever best practices, prior results, and prior technology they know about to help systematically approach the creation of programs. They're taking a systematic approach to improve systematic approaches.

A programming language designer follows whatever best practices, prior results, and prior technology they know about to help programmers. They're taking a systematic approach to improve systematic approaches to improve systematic approaches.

Programming language theory helps programming language designers -- I mean, what else would it do? -- so it's one step further away in indirection. We could keep going meta and extend this ordinal as far as we like. Even circular reasoning can be valuable if it inspires someone to build a more useful line of reasoning in the same shape.

Your frustration that there's no feedback loop is valid. The feedback is as indirect as it can possibly be, with every step having its own statistical and methodological error which can impede the analysis of feedback. But the poor feedback loop is part of the essence of the field; if you don't want to work in spite of poor feedback loops, perhaps PL theory is indeed difficult to apply to your situation.

I find PL theory useful to the extent that if I want to improve feedback loops, I'm willing to get my hands dirty using relatively poor feedback loops on the way there. It's nice to know there are tools that make poor feedback loops more bearable, such as programming languages and typecheckers.

You mentioned building architecture as a field that's better at answering your list of questions. I can imagine there are indeed architecture approaches to improving architecture approaches to improving architecture. Some architects even design their own homes and workplaces. Is this self-serving regress of architecture called something, as a field? If someone doing machine knitting wanted to apply architectural architect architecture theory to their work, how would they find answers to those questions of yours?

I wouldn't say PL is deficient in this area... it's just that the tools that cover all relevant points are not something most PL designers are interested in using because performance has a huge priority. Also, because side-effects too deeply entangle a model with its execution.

When I was getting into PL, I did a lot of work with term rewriting languages like OBJ. Term rewriting is non-deterministic, in the sense that a specification (of a language and/or a model) can resolve in a variety of ways. But built into these tools, or at least those I used, was a way to explore the models - i.e. you could ask if there's a way to reach a specific outcome, or to trigger specific rules, etc..

Term rewrite systems (TRS) are easily augmented with soft or probabilistic logics, allowing one to begin asking about probabilities of cause or consequence. Joseph Goguen was a major developer on OBJ family languages, and had a related interest in fuzzy logics. TRS allows us a very rich and general approach to 'modeling' of things, and of building languages around models.

Shortly after Joseph Goguen died, I learned about BOBJ, which was OBJ with iterative refinements for performance (e.g. this model is a refinement of that one). The basic rule for refining a TRS is that you're free to reduce non-determinism. With direct approaches to probabilistic or fuzzy models, the idea of 'non-determinism' becomes unfortunately entangled with 'probability' so you'll need to separate those concepts and model the probabilistic programming more explicitly.

Avoiding side-effects (i.e. by modeling effects as an output language, to be handled by another program) is also essential to even get started with these models. The developments in purely functional programming seem very helpful here, offering systematic approaches to effects and generalizations over the 'output language' based on monadic composition, etc.. (whereas my understanding of how effects should be modeled was rather ad-hoc when I was learning about PL via TRS).

But if you want to exploit the commonalities between your chem and weaving programs, you might want to look for natural transformations between them in the category of stuff.

They're a common part of domain modeling - as part of a program for a specific task. Any competent programming team sits down with domain experts (and gradually become domain experts) to get a handle on the domain. It isn't part of PL education because it's a more general part of software development. (Whether it's deficient there is a separate question.)

What's missing is the ability to express domain concepts and domain models once and reuse them for many different purposes, different queries and different ways of thinking. This is a common coupling problem, just between "domain knowledge" and "task". If we want to effectively leverage domain knowledge, need to encode our knowledge of the domain apart from the accidental details of how we're using that knowledge for a specific purpose.

Most languages and paradigms aren't designed with that particular separation of concerns. Very few support effective encoding of knowledge, in general. They prioritize other features.

This missing feature is supported by TRS and perhaps other systems. Rewrite rules are effective at encoding how we express and think about a problem in multiple ways, and can be processed in multiple ways. BOBJ went an unusual extra step to support explicit refinements of knowledge into a more conventional program, while preserving a clear line back to the domain knowledge.

Ultimately, PL has several answers to the concerns you're raising. If you study enough PL, you'll find TRS and more esoteric answers. But those concerns aren't prioritized by most PL designers, so those answers aren't used, and aren't even widely known.

They're a common part of domain modeling - as part of a program for a specific task. It isn't part of PL education because it's a more general part of software development.

In the case of PLT specifically, all of the subject domains have something in common: the linguistic character. The PLT domains are all about human with humans and human with machine communication. Therefore, it would seem that sociology, linguistics, anthropology, psychology, and political economy are all fields that should be informing PLT.

What's missing is the ability to express domain concepts and domain models once and reuse them for many different purposes, different queries and different ways of thinking.

For that purpose I point to those adjacent fields (sociology, linguistics, anthropology, et al.).

If we want to effectively leverage domain knowledge, need to encode our knowledge of the domain apart from the accidental details of how we're using that knowledge for a specific purpose.

That seems pretty meaningless.

Again, this isn't unique to PL. Any expression of a domain knowledge in a programming language - as an API, a set of types or classes, EDSL syntax, etc. - has linguistic character. You express these things in language, manipulate them through language, and they become part of your language. Nothing you're arguing is unique to PL. Software, in general, communicates both human-to-human and human-to-machine.

If you believe that software in general should therefore be informed by anthropology, sure, whatever. But your attempt to discriminate PL on this particular aspect doesn't seem justified. The lines between API design and language design are fuzzy, especially in context of macros and EDSLs. PLT is at most a branch of software architecture or computer science, not a replacement for it. PLT "education" doesn't have any special need for sociology or psychology that isn't already more general to software development.

What's different, relative to human knowledge held by domain experts, is primarily the flexibilty of knowledge manipulation. We can comprehend our domains in many more ways than most PLs enable querying or processing domain knowledge encoded in an API or EDSL etc.. There are emergent consequences for alignment with human psychology etc. And there are answers in PL to address this difference, for those who can be bothered to study PL beyond shallow FP vs. OOP.

As far as "seems pretty meaningless" and "word salad" go, that is dismissive and abrasive. I won't bother with any effort to clarify my meaning further.

What's different, relative to human knowledge held by domain experts, is primarily the flexibilty of knowledge manipulation.

There and in an earlier comment where you spoke of encoding knowledge.

I think you are assuming an abstract category of "knowledge" which I gather has some kind of encodable structure and which can be, generally, "manipulated".

For, let's say, philosophical reasons I suspect there isn't really a clear concept of "knowledge" there, at least one that isn't trivializing.

I'm not making fine distinctions here. Just take 'knowledge' to refer to some human-level concept or comprehension or skill or whatever, and 'encoding' to be any representation or protocol through which we might attempt to communicate that knowledge. If you look outside, see the reflected sunlight, and say "heh, it's sunny", that's an encoding of knowledge, albeit not one that is especially easy to process (because natural language).

In computer science, we are restricted to manipulating knowledge through an encoding of it. When you argue that we should take psychology or sociology into account, that fundamentally must be handled at the encoding.

Whether this is "trivializing" the knowledge itself seems irrelevant to me, though I'm pretty well convinced that our brains and social systems (bureaucracies, etc.) can ultimately be understood as another encoding of knowledge so the entire 'psychology' argument reduces to alignment or impedance concerns between one encoding and another - something that we understand well in computer science and even in topographical mathematics (e.g. why isomorphism is not enough for modularity and maintenance concerns).

...

Regardless, I still don't understand why you've singled out PL theory. The issues of psychology, social barriers, economy, etc. are concerns for all software development. It isn't as though an intelligent PL designer will ignore the foundations underlying PL theory when leveraging it. It's almost as though you've got this straw-man understanding where PL theory is "just the math", where in reality PL theory is closer to "this math on top of this larger foundation of computer science".

And perhaps PL theory is more than that when you account for how many language experiments are designed to explore learnability (e.g. Alan Kay teaching Smalltalk to children, Seymour Papert exploring hypotheses on how languages affect learning, etc.), or the studies of cognitive dimensions of notations or usable security. Many 'paradigms' have hypotheses regarding psychology, economy, etc.. Those social and psychological and economic aspects are part of computer science and PL, and have been from the start (Babbage and Lovelace, if not the 'human computers' before them).

I suspect you've been making a straw man argument, assuming education of PL theory to be less than it really is and somehow independent from its foundations.

If you look outside, see the reflected sunlight, and say "heh, it's sunny", that's an encoding of knowledge,

Ah. Yes, I don't think that is right.

If you start from someplace like this ("language games", Wittgenstein):

https://en.wikipedia.org/wiki/Language-game_%28philosophy%29

it starts to be unclear that there is this "knowledge" that is "encoded".

As more of a literalist, if a speech act "encodes" something, I'm inclined to regard that as an information-theoretical statement.

Regardless, I still don't understand why you've singled out PL theory. The issues of psychology, social barriers, economy, etc. are concerns for all software development.

Yes, but PLT is about a specialized area that concerns communicating about programs and coordinating the manufacture of programs.

Another field "specialized" on the subject of communicating about and coordinating manufacture of programs is software engineering. And even software design patterns, or agile methods, could be described by the same phrase. I think your "yes, but" here is very weak.

And it isn't the nature or truth of "knowledge" that concerns me so much as the structure of its encoding. Active encodings are okay, I did explicitly mention protocols to include them. If you want to substitute the word 'information', I'm okay with that, though it lacks the right connotations for typical software development (e.g. a schema doesn't encode what most people would call information, but rather their knowledge about information).

Another field "specialized" on the subject of communicating about and coordinating manufacture of programs is software engineering.

The two fields are certainly related. For example, there is feedback between how software engineering theorists and how programming language theorists think about the division of labor.

Although I could just be a bit simple / naive.

Knowledge is simply an assertion that some information is a correct reflection of the state of a world. An encoding is implied: generally by the domain of discourse. The encoding describes how facts about the state of the world can be written as data.

Once an encoding has been agreed upon the only distinction between information and knowledge is whether or not we believe it to be true. Information (using the encoding) is simply a set of statements. Knowledge (using the same encoding) is a set of statements that we believe to be true about the domain of discourse.

Is there anything more complex to it than that?

Dave's example seems straight forward: we have a domain of discourse that involves the state of the weather, so beloved of Machine Learners. The encoding could be seen as a simple subset of English. Depending on how many different states we distinguish within this world it could even be encoded as a single integer from a bounded range.

It is an encoding of knowledge in the sense that it conveys an assertion of belief about the current state of the world. I'm side-stepping what you wrote slightly:

it starts to be unclear that there is this "knowledge" that is "encoded".

As I'm assuming that your meaning was that there is no separation between the encoding of knowledge and the encoding of information. That's something that I would agree with, although it does not (to me) seem to rule out that "knowledge" is a thing that can be "encoded". I would posit that it shares exactly the same informational encoding as information, but the additional meaning that we (the speaker) believe it to be true.

Knowledge is simply an assertion that some information is a correct reflection of the state of a world. [....]

Once an encoding has been agreed upon the only distinction between information and knowledge is whether or not we believe it to be true. Information (using the encoding) is simply a set of statements. Knowledge (using the same encoding) is a set of statements that we believe to be true about the domain of discourse.

So knowledge is a collection of true statements, abstracted from the syntax of those statements?

I believe that is roughly the concept behind dmbarbour's talk about term rewriting systems.

It is problematic, though. Social facts do not reduce to lists of statements.

Put a different way:

If a programmer (PL designer or otherwise) wants to know "How will my program effect people's lives?", generally they can't deduce the answer from some list of statements.

If a programmer (PL designer or otherwise) wants to know "How will my program effect people's lives?", generally they can't deduce the answer from some list of statements.

Sure, there are some AI-complete questions that we can't expect to receive answers. Emergent social consequences are beyond any theory at this time.

OTOH, you could certainly answer this question for, say, traffic control software. Via simulations.

Therefore, it would seem that sociology, linguistics, anthropology, psychology, and political economy are all fields that should be informing PLT.

I don't see why. PLT is to programming as mathematics and physics is to other engineering disciplines. The application of sociology, linguistics, anthropology, psychology and political economy has just as much relevance to mathematics as it does to PLT.

Those disciplines might have relevance to programming, to better understand and model domains as you describe, but not PLT specifically.

PLT is a social science in a way that mathematics is not.

Programming language design is always directly concerned with methods of social production. In other words, the PL designer is confronted with a hypothetical set of producers (aka workers, programmers). The PL design itself expresses a methodology for organizing the productive activity of those producers. Mathematics in general does not share this quality.

The social concern of the programming language design problem can be seen in researcher concerns such as expressiveness, modularity, safety, and compositionality. Those respectively concern communication, the division of labor, boundaries of institutional trust, and technological increase in the productivity of labor.

The relation of PL expressiveness to communication is, I think, widely acknowledged even if it is not a particularly developed topic. We speak, for example, of the role of programming languages as media for human to human expression. In the area of DSLs, where there are existing human jargons for the domain, we try to incorporate those. I speculate there is more to be usefully explored about the relation of language design to the conceptual models programmers form from the details of the language.

The topic of modularity is squarely concerned with the division of labor. Modularity mechanisms concern the joining of separately performed work. PLT work on modularity often implicitly concerns the joining of modules as a nexus of power -- of managerial control. Thus, modularity goes beyond the mere bookkeeping mechanics of resolving identifier names. It goes on to be central to how program specifications are developed; how program architectures are defined and divided up into tasks; and how responsibility for system failures is allocated among people.

At one time, programming language safety seemed mostly concerned about preventing bugs in general: Keeping systems from crashing. Keeping storage from being corrupted. Nowadays, attention is overwhelmingly focused on a related but not identical problem: The protection of systems from onslaughts of intentionally malicious inputs. In other words the modern concern with programming language safety is largely the PL theory contribution to computer security.

And my last example was compositionality which, I claim, is fundamentally a concern about labor productivity. Compositionality may contribute to expressiveness (see also) but on its own terms, it is about code re-use. Compositionality is the most abstract expression of the impulse to commodify partial programs and to reduce total labor requirements by increasing the stocks of earlier developed composable components.

Some might counter my argument in these or similar terms: That's all well and good, but Tom, you have conflated programming language design with programming language theory.

Modern programming language theory, this argument continues, mainly concerns a set of abstract mathematical tools that can be used by programming language designers, but which concern some more basic facts about programming languages in general -- fact that stand apart from the concerns of any particular language design.

For example, a typed lambda calculus is not itself about modularity. The calculus is thoroughly agnostic as to the division of labor. Nevertheless, when a programming language designer wants to reason rigorously about his proposed modularity features, PLT gives him the tools to module those features mathematically.

Further, the PLT-as-math argument might go: We are learning good ways to make the mathematical descriptions of programming languages directly executable. Thus, we can foresee a future in which the PL designer can precisely specify his design in mathematical terms, prove things about it, and test the design in various ways --- and at the same time his description will serve as a perfectly viable implementation.

I am not trying to put words in the mouths of PL theorists. I'm just saying that is how I understand much of what they are saying about the field.

My responses to those arguments, which I hope are not strawmen, are two-fold.

First, if you tell me that PLT's role is to provide language designers with a mathematical language for thinking about their designs, then I have to say modern PLT is ignoring key aspects of the problem. Programming Language Design is not suffering much if at all from a lack of an ultimate PLT mathematical language.

Here is an example: Every widely-used, long-lived programming language seems to have syntax that changes over time, gradually, and while maintaining some degree of upward compatibility. When syntax must change incompatibly, the designer is left imposing a substantial labor cost on all of society. Yet, I don't think PLT has noticed this issue. There is no PLT guidance about syntax design for the long term. There is no PLT guidance about how to change syntax over time. I think PLT turns it back on this issue in part because a strictly mathematical approach to the issue is probably not going to be helpful.

Here is another example: In practice, it doesn't seem that hard math problems arise around questions of modularity in practical languages like Python or Perl or C++. Where a deficit can be seen in modern PL design, though, is where modularity features fail to compartmentalize the knowledge needed to work on a program along the boundaries of modules. Thus if I grab a module from the repository and start to use it, more often than not, for anything at all tricky, I can't rely only on the module interface: I must explore and understand the "internals" of the module to avoid problems and obtain performance.

So in that case I see PLT neglecting a theoretical question about PL design that isn't specifically mathematical: What kinds of divisions of labor are both desirable and easy to support with modularity features that compartmentalize knowledge suitably for that division of labor?

In short the ambitions of modern PLT to establish a mathematical foundation for PL design seems to ignore a lot of key areas of PL design in general, where non-mathematical (or not-wholly-mathematical) theory could help.

Second, concerning the idea of PLT as converging on directly executable "ultimate" languages, in which all future PL designs might be expressed -- both mathematically and executably:

To me, that aspect of PLT seems more like a narrow hypothesis than a theory of programming languages. PLT struggles to say much about programming languages in general, beyond such simple equivocations as turing completeness. The hypothesis that most or all PL design can be usefully grounded these ways is highly speculative, at best.

Further, even while PLT claims to look for that kind of foundation, it implicitly and uncritically imports to itself naive assumptions about the social character of PL design such as assumptions about kinds of modularity and compositionality are important, and which aren't.

In short, where PLT tries to retreat furthest from recognition of PL design as a social science, it winds up proving that PL design is a social science in the course of taking on design problems blinded to their social character, rarely producing impactful results.

I agree with you: I see what I do (and would call PLT) as the discipline of trying to produce better programming languages, with no implicit restriction on the range of techniques, or the specifics of the scientific method, to achieve that end.

I do happen to personally prefer to use mathematics as a tool to study the questions I'm studying, and this certainly encourages me to look at problems that I know can be effectively attacked from this angle (for example, proving that a compiler is bug-free) rather that problems that I don't know how to work on this way, for example "what is a good syntax for a programming language".

I agree with you that the latter question is important, and that while we have *some* hints about it from the maths for the some things (alpha-equivalence, and I think the fact that shadowing is fundamental and must be accepted; I think the people using macros do more about syntax because theirs is more advanced), it does not answer many question that arise in practice when designing a programming language syntax.

I am ready to believe that because programming is a literary, human, communication, social activity, we may have valuable ideas to get from the other fields of science that have studied these topics in depth. I support that claim. If you come to me with a scientific method that is not mathematical at all, but is effective at solving this problem of "what is a good syntax" or any other important problem of programming language design, I hope to be open-minded enough to recognize it as what it is, and accept it as valuable programming language research.

The thing is, I don't have many good examples of this kind of decisive successes in mind. It may be that we haven't gotten the right people or the right toolset at the right place and time, or that it's just a fundamentally hard problem that is just beginning to be studied, and needs more time to get results at an applicable scale -- this could maybe be a way to think about the current user-studies-based approaches at programming language design.
I do, as many other people, get on a weekly basis in discussions about whether this or this syntax would be better for this programming construct. And I don't recall ever seeing someone decisively resolve such a debate using a secret technique that is not math-based but brings a strong sense of certainty (yes, this is the right decision). Part of the reason why I follow LtU is in the hope that someone would post there if a community of people able to better solve those problems emerged. I liked Harnessing Curiosity to Increase Correctness in End-User Programming and think it might be going in that direction.

A remark on modularity and labor division. I think there is a clear, strong link between the two, but I would not claim either that managerial division of labor is what modularity is "about". First, modularity has an inherently beautiful characteristic; people may be researching modularity in the search for elegance. Second, modularity is a property of system designs, and not merely of the humans that produce them; one may research modularity to understand how to better build systems (even at a personal level of just one person). Third, I think that speaking of "labor division" and "management" together suggests a point of view (namely: I'm the boss and I must dispatch programmers around to produce X and make profits off it) that is (polarizing and) relevant and applicable, but that I think is not necessarily the only possible point of view -- I think you use this vocabularity in a larger sense, but we readers may or may not be familiar with the nuance of it. The decomposition of a system in a way that enables collaborative production is not necessarily to be seen from the point of view of a "manager" that directs labor; it could also be seen from the perspective of the collaborators themselves that want to self-organize to contribute to a project they believe in. And indeed I would suspect that many aspects of unix systems that made them "modular" also happen to have facilitated the collaborative gift of labor that produced the free software ecosystems that we all benefit from today -- in a way that might be significantly more impactful, in the long term, than whatever organization of labor a given manager can set up its team by a good choice of programming language or system.

There is no PLT guidance about syntax design for the long term. There is no PLT guidance about how to change syntax over time. I think PLT turns it back on this issue in part because a strictly mathematical approach to the issue is probably not going to be helpful.

Clearly you haven't studied extensible languages and the theories and motivations behind them - Christiansen grammars, XML, etc. and efforts to model syntax as a library to avoid forward incompatible changes. Just because people frequently ignore guidance doesn't mean it hasn't been studied, explored, and offered to the few who seek it.

I certainly studied this aspect of PL theory before continuing with my own language design. Ultimately, I decided to separate the issues, replacing syntax by a newer 'lensing' (editable views) concept, where we sugar and desugar code to a more semantically aligned representation under the hood. A lot of recent PL design projects are taking this route (Lamdu, Unison, etc.) which also enables flexible changes in syntax (and use of specialized syntax for subprograms that need it).

Or are you somehow classifying this advice as outside of PL theory and study?

Clearly you haven't studied extensible languages and the theories and motivations behind them - Christiansen grammars, XML, etc. and efforts to model syntax as a library to avoid forward incompatible changes.

I know some work in this area fairly well, I think. Much I am not more than glancingly familiar with, I'm sure.

What you are describing are solutions to a problem different from the one I was trying to describe. I think you are naming technologies for implementing syntaxes designed to be extended in the field; or for managing the presence of multiple syntaxes sharing common processors.

What I was trying to point to is a question about the design of programming notations. How do we define "better" or "worse" notations? Are there notation design approaches that can maximize the chance of a notation remaining fixed for a long time? Are there notation design approach that can anticipate and prepare for future change?

If you hand me an extensible syntax, or a fancy macro system, or an extensible mark-up language like XML I'd still want to use these by defining particular notations. My questions pertain to specific notations -- not to the technical problem of how to manage a soup of related-but-different notations.

Or are you somehow classifying this advice as outside of PL theory and study?

No. I'm trying to point out things PLT is ignoring, but shouldn't be.

The study of 'better or worse' notations is indeed part of PL theory, or at least something that receives attention (not necessarily a 'theory' per se), e.g. cognitive dimensions of notation. And extensible grammars aren't just about managing a soup of notations. If you study the motivations behind them you learn that a big one is reifying maintenance of syntax into libraries. This enables explicit management of future change, reduces the problem to a better known one (library or API change), and enables coexistence of multiple versions of the same syntax for any language that supports coexistence of multiple versions of a library. Lens based approaches go an extra step of being retroactive.

I think PL theory, as a field, is tackling more questions than you're crediting to it. Even if you just look at PL conference papers, I think you'll see a lot of what you claim PLT ignores.

As an ignorant outsider, it sounds to me here like there are people who have investigated, researched, and advanced the "tooling" if you will. But there's probably even fewer people who have then done research into "well now that we have the tools, what actual syntaxes should we encourage?!" PPIG of course comes to mind.

I'm sure we all have our pet favourite sytnaxes, or at least know what we do not like. And since I'm selfish I am happy to have such opinions. But we have to admit that they do not guarantee that they really are good pedagogically, like for say "newbies learning to program". Some are hoping to change the connotations that usually come with that terrible phrase cf. Sean's McDirmid's work as a random name among several good folks forging ahead on behalf of us all. Please note that your own personal favorite one might even have real benefits to software engineering, but that doesn't mean it is e.g. anything approachable by newbies. So one has to know what the language is for. Is Logo actually good for getting kids into programming[1]? vs. say Awelon bytecode? Courses for horses. Now, ideally each horse would truly be the best for that particular course. But are we mostly using "faster horses" and still hand-producing "buggy whips" when instead we should have an automobile? (Of course, I'm a bleeding heart and kind of hate the automobile, but whatever.)

[1] "Secret Coders" really caught on with certain kids I know. The programming language they push is UCBLogo which is just about the worst piece of crap UX I have ever had to endure in my life. Especially on Linux. Whereas Blockly Turtle makes a lot more sense. (Funny that I never really groked the use of the visual-block approach until I went through this experience).

This enables explicit management of future change, reduces the problem to a better known one (library change)

Extensible syntaxes reduce the implementation of a change of syntax to a library change.

Such reduction does not answer questions like:

1. How can notations be designed to minimize the probability of a need for change? Are some notation choices more timeless than others? How can we recognize and even conjure up these?

2. What kinds of incremental changes to established notations are the least disruptive to social facts like accumulated literature, existing training, etc.?

PL and CS haven't been around long enough to test hypotheses of 'timeless' notation.

But I vaguely remember reading a discussion that pointed to Lisp and Forth as quite stable, and contemplating that consistency might be relevant. And IIRC, the efforts on Levy's call-by-push-value and John Shutt's vau calculus both aim to reduce the 'arbitrariness' of syntax, enabling a single notation to take over what would require keywords in other languages, thus reducing the need for changes in notation to accommodate new purposes. Lazy evaluation has similarly been observed to mitigate need for new keywords and syntax.

Your second question regarding social disruption isn't unique to PL by any means. It also applies to changes in APIs, and has been tackled and discussed extensively at that level. With notation reduced to an API, similar answers would apply and would be addressed at the software engineering level. So, if there are good answers to be had, they don't need to specifically be within PL theory.

That said, I believe it has also been addressed to some degree at the PL theory level. I before mentioned that some programming languages support coexistence of multiple versions of a library (this is non-trivial; it requires structural types or versioned nominative types, avoiding ambient state, etc.). A big motivation for this is to minimize social disruption when updating a library, enabling development without breaking existing services/apps/users. With extensible syntax, this extends again to notation.

And one of my own motivations for the lens-based syntax are also to reduce disruption, enabling different syntax to be used for different fragments of a codebase corresponding to different users, groups, or projects.

In any case, even where PLT lacks guidance for a question, that doesn't imply the question was ignored.

In any case, even where PLT lacks guidance for a question, that doesn't imply the question was ignored.

One way you can tell things like that are ignored by looking at the graph of citations and dearth of interdisciplinary work. Another way is the absence of PL courses with prerequisites in the humanities.

Show me this convincing graph of citations you're using. Does it include the works of PPIG and similar groups? Does it include Toomim's linked editing (Harmonia research project)? Seymour Papert's work on Logo and the Mindstorm book? VPRI FoNC? How do I know whether it's a valid representation of past and present PL theory work?

I might consider 'absence of PL courses with prerequisites in humanities' to be more relevant if PL wasn't post-graduate material in most universities, of the subset that even touch the subject. I'm not sure about other universities, but (IIRC) my CS degree required psychology 101, behavioral psychology, sociology 101, economics 101, and two humanities courses of choice. (It's difficult to squeeze even that much into a 4-year curriculum.) And we only had two or three post-graduate courses related to PL (depending on whether you count 'automated theorem proving', which is where I started using TRS). AFAICT, the field of PL theory is mostly self-study, and graduate students are already expected to be self-directing.

I think good evidence for 'ignoring the question' requires researching that particular question, knowing the literature well enough to at least know where to look for it, and finding no research on the subject. We could maybe reduce this burden if we had a good index, but we don't. Worse, the jargon has changed a lot over the decades (and from one coast to another) so it is hard to even find the right keywords without investing a lot of time.

maybe there's some agreement that it would be interesting if such things were more mainstream.

Good morning!

Show me this convincing graph of citations you're using. Does it include the works of PPIG and similar groups? Does it include Toomim's linked editing (Harmonia research project)? Seymour Papert's work on Logo and the Mindstorm book? VPRI FoNC?

No, those generally don't count.

Most of what you are pointing at is work that makes very narrow use of a few methods from cognitive psychology. The work you are pointing at does this mainly in the manner of Taylorism. The main objective is to train up labor having particular qualities, adjusting tools and pedagogy as needed.

No, I am looking for something broader than that. For example:

How do modularity features support or interfere with a programmer's capacity for moral agency in performing his work?

In particular, do modularity features induce in programmers a corresponding sense of how their personal moral responsibilities are delineated?

If so, how does what they believe to be their area of moral responsibility compare to their tested understanding of the relevant facts of what they are doing?

In other words: Is it possible for a language feature to help bring about technically proficient programmers who, nevertheless, completely misunderstand the moral implications of what they are doing?

Conversely, are there language design approaches that discourage such divergence between competence and capacity for moral agency?

I'm not sure about other universities, but (IIRC) my CS degree required psychology 101, behavioral psychology, sociology 101, economics 101, and two humanities courses of choice.

I am curious how any of those prerequistes were used in your PLT class(es).

I'm getting a strong impression of 'moving goalposts' from your arguments, e.g. we started with "There is no PLT guidance about syntax design for the long term." then when I pointed to such guidance, you moved to "timeless notations" and now to "moral agency".

Yet, I do understand that you might not think of this as moving goalposts if you're instead thinking of these questions as 'clarifying my real point'. “Its like a finger pointing away to the moon. Don't concentrate on the finger or you will miss all that heavenly glory.” - Bruce Lee.

If this analogy holds for your argument, I'm still looking at that finger, and (having been in the other position) I'm aware of how frustrating that must be. Yet, whatever 'broader' concept you're attempting to explain through examples, I'm still only seeing you point to things that are addressed in PL theory or design, if not more generally in CS. I'll concentrate on the finger once more:

are there language design approaches that discourage such divergence between competence and capacity for moral agency?

Ultimately, any question of moral agency will reduce to comprehension and control. You can't be a moral agent where you can't be reasonably expected comprehend how your actions or changes affect a system. You also can't be a moral agent if you lack the power, authority, or capability to execute an action in the first place. But, with comprehension and control together, you gain moral agency.

The concerns of comprehension and control align very nicely with two broad PL design concerns. Hence, PL has alignment with this subject even if nobody specifically thinks about it or makes the connection. How do we make code more comprehensible at scales used in real development today? How do we give developers more control over their codebase and software behavior? Arguably, those questions are sufficient. (Though, they still aren't easy to answer.)

How do modularity features support or interfere with a programmer's capacity for moral agency in performing his work?

I'd first make a distinction between modularity within the language (e.g. separate functions/classes/files - a single agent might develop many such modules), and modularity outside of it (e.g. shared libraries, software packages, versioning, distribution models). For the question of moral agency - comprehension and control - I think software packaging and distribution is the primary source of troubles today.

• Different agents are given ownership and authority over different packages or apps. When bugs can be traced back to a shared library, there is no easy way to take responsibility and directly fix it. One instead submits a bug report and hopes for a fast turnaround response.
• The mere possibility of tracing errors into code one cannot control can undermine a programmer's personal sense of control and responsibility. As humans, we're quick to shift blame when we have the opportunity - a well known cognitive bias in humans. So we get a lot of 'voodoo' programming.
• When packages are updated, it is difficult for the maintainer to track and understand how changes in a package affects existing systems and software or to repair such software. There is no easy way, for example, to run unit and integration tests for all software dependents.
• Because packages are versioned and maintained separately, we get combinatorial package sets. (Even worse if packages are also tuned by preprocessor flags etc.) This makes comprehension vastly more difficult.
• A lot of cross-project refactoring - e.g. development of reusable utility code - is hindered because one is only able to directly control the software for one project. (cf. redundancy vs dependencies)

We can potentially fix a software distribution model without changing the language directly, cf. efforts like Haskell stackage or Nix package manager.

But it also isn't difficult to design a PL to favor alternative distribution and packaging models. For example, an alternative I'm exploring is inspired by Wikis and DVCS, and curated Linux distributions. Projects would derive from cloning a few 'standard' distributions that include all dependencies. Updates may gradually be cherry-picked and folded back into the standard repositories, using conventional DVCS techniques. Both 'apps' and 'libraries' are distributed in the same repository, enabling better comprehension of how changes propagate, control over distributed fixes, etc..

I think DVCS-based software distribution models, including all dependencies and many dependents, has potential to greatly improve comprehension, control, and moral agency in software development.

Is it possible for a language feature to help bring about technically proficient programmers who, nevertheless, completely misunderstand the moral implications of what they are doing?

Sure. That isn't difficult at all.

Regarding modularity within the PL, some techniques PL has explored do seem to undermine local reasoning and comprehension. This includes many implementations of aspect-oriented programming, where it becomes difficult to locally reason about external 'join points', behavior, and implicit dependencies.

Pervasive non-determinism is another fine example of a PL feature that makes it extremely difficult to comprehend or control how one's changes to software will affect behavior. This results in combinatorial conditions that are never observed on the test machines (due to hardware races). And changes in one part of the code can affect scheduling in completely different parts of the code. Combine this with the earlier mentioned issues of code distribution and this problem is greatly amplified.

Consider a PL designer who has studied the principles of usable security and secure interaction design, the motivations surrounding development of E language, the unix philosophy including transparency and discoverability, and cognitive dimensions of notation.

Even with an understanding of these principles and properties, it can be difficult to balance them in a rubric that can actually be implemented.

Relevant to your question, it isn't difficult to intentionally undermine or subvert various properties or principles. One might simply hinder developers from controlling or comprehending their code (e.g. INTERCAL, or pervasive non-determinism). More subtly, one might create PLs that are designed to ensure job security of maintainers, protect 'intellectual property', or reduce agency of end-users to utilize applications in ways not controlled by the developers.

As a PL designer, one of my better tools is controlling the 'paths of least resistance' through notation and semantics. I can subtly push developers to favor one design or design principle over another. I try to use this for good. But bad principles, designed to harm an end user or future maintainer, can also be pushed.

curious how any of those prerequistes were used in your PLT class(es).

Behavioral psychology (metrics, mostly) was used several times, mostly in classes on software engineering and UI design. In one course we (as a class) had to study small groups of users working with example software, track their actions, propose and implement a set of changes to the UI to improve user performance, then retest. (We weren't downgraded for negative results, just on the quality of our analyses and implementation.)

I can't say I got nearly as much use from the other courses. I'm still not sure how to use sociology in any way that provides useful, timely feedback on a software or language design. But I did enjoy the class.

As a Regular Joe who mostly has to use Regular Joe programming languages, at least as final targets, I guess most introspective devs should already be well aware of this: a clear instantiation of it is 'death by boilerplate'. Hence I'm always looking for that meta-language (Shen, ATS, Scheme, Haxe, et. al.) that can give me a way to get up and out of such prisons. (Up until the point where I have to actually debug the whole stack, of course...) As Mr. Barbour references, an easy example is, 'does the ecosystem's grain lead to real honest to goodness working Security?'

Yet, whatever 'broader' concept you're attempting to explain through examples, I'm still only seeing you point to things that are addressed in PL theory or design.

I had a kind of "aha!" moment when you pointed to cog-psy-style time-study experiments as evidence of "psychology" informing CS and PLT. We just have very different frames of reference here.

The unwavering goalpost I'm pointing at has to do with understanding PLT in its relation to capitalist social relations, since that's what pays the bills. There is a kind of step-ladder of thinking that goes:

PLT is mostly math.

OK, but it is mostly math related to optimizing industrial production.

OK, really it *was* mostly related to optimizing industrial production but that is kind of maxed out. The transition from assembly to FORTRAN is done, for example. The theorists are aspiring for marginal improvements so small as to make nevermind.

OK, so if PL design is still going on but it isn't really any more about industrial efficiency, what IS it really about?

Where is the PL theory that has a convincing account of the role of PL design in society?

I don't think PL needs a "theory accounting for its role". That seems like a very weird standard if applied to fields of science in general. And I don't believe PL theory is mostly math - seriously, there are very few formulae that give useful answers in PL reasoning or design. And I disagree with the marginal improvements assumption, even by industry metrics. Probabilistic PLs have shrunk some classes of programs by two orders of magnitude, for example. And llvm has made PL development itself an order of magnitude easier.

So I guess I'd say your entire step-ladder is misplaced.

Regardless, PL is the past of HCI, and it is a good future for HCI. UX design principles should apply to PL, to make use casual. And PL principles should apply to UX, to empower and improve agency of the users. The walled-garden apps we use today are terrible by a lot of metrics and use cases. The real goal of PL, IMO, is to eliminate programming as a distinct career (e.g. from art or science or math or music or business). Programming would be conflated into computer literacy and the future-normal app use.

And PL principles should apply to UX, to empower and improve agency of the users.

What are these PL principles that would apply to UX?

Pursuit of expressiveness, reusability, modularity, composability, extensibility, simplicity, predictability, consistency, transparency, etc.. Some already are applied to UX. But those properties that empower users are not promoted by today's application models.

Today it's much harder to compose two GUI apps (e.g. taking form output from one as form input to another) than it is to compose two functions. It shouldn't be.

Are we talking about principles from PL design or PL theory? PL theory says little about what things ought to do and is rather just descriptive in the way things are. Obviously, PL theory != PL design, just like writing a compiler isn't the same as designing a language to be compiled.

On a side note, a colleague and I are thinking about writing an essay on the universal principles in programmer experience design in the next few months. Not to be exhaustive, but to set this up to be a thing.

PL theory isn't unopinionated. Just look at cognitive dimensions of notation, for example.

Following your analogy, it's like noting that some properties are desirable for all compilers: speed, predictability, easy to use, easy to add new optimization logic, high performance results, verifiably correct optimizations and compilation, good error detection and reporting, debuggable output, maintainable compiler codebase, etc... And we can draw on a long history of techniques or design fragments for some of these properties. But it might be difficult to maximize all of these desiderata at once in something we can actually implement.

I look forward to your article/essay.

I don't think anyone has argued that CD is a formal PL theory, definitely not Greene or Blackwell :). At best, it is a useful framework without any formally modelling behind it.

PL theory IS very close to math, in that it can't really make value judgements about what is desirable or not, it can only describe (or try to describe) the universe as it is. Theory might help us reason about some formal properties of say modularity, but to say it helps us actually understand why modularity is useful is pure unadulterated bull. What PL theory can give you is a proof of correctness, or a proof of time complexity, or a proof of whatever property can be formally specified, but it cannot say anything at all about the qualitative. So...modularity can decrease development time, support comprehension by humans, can reduce bugs, etc...none of that has any formal grounding, or even a slight analogue in a formal framework.

Why does a compiler need to be fast? Why does it need to be predictable, or easy to use? There is no formal reasoning for that, we think it is a good idea, just like we'd rather not have bridges fall down even though there is no theory that tells us bridges falling down is bad. In that sense, PL theory is more like implementation rather than design, it allows us to reach our goals, but doesn't advise us of what those goals are.

PL theory is not a theory; it's a field with conferences and ongoing research. Literature in this field ranges considerably in maturity and formality.

Sure, there are some parts of it that are math-heavy, that deal with formalizations of more-historically informal properties. But a lot of PL theory involves studying and understanding design motivations, roughly how features fit together or augment one another, or properties like 'cohesion' or 'transparency' for which we lack good metrics and formalizations.

And the field of PL theory is not merely descriptive. Sure, there might not be a formal assertion that modularity is better, but the informal literature isn't so neutral.

PL theory has a very well defined meaning, basically anything POPL worthy. It must be formal and rigorous, there is no such thing as informal theory in science.

Theory doesn't intersect with design, which is its own thing. There are occasional efforts made to sciencify design, but they all end in failure. PL theory, PL design, PL engineering/implementation are all separate fields concerned with different things. It is an abuse of terminilogy to put them all under the theory umbrella, which anyways conjures up nightmarish thoughts of POPL (which barely has anything to do with PLD these days).

Your first sentence contradicts itself, and the second is plainly false if you ever look into sciences like psychology, economics, or even historical evolution of 'hard' sciences like chemistry. Science is defined by its processes, not formalized results (though those are cherished). I agree that PL theory and design and implementation are different. I have not conflated them. But they aren't fully separate: they do inform each other.

And regarding your title: what I said is that PL theory is not *a* theory. It isn't even a particular set of theories. It's a living field with a few theories and a larger variety of strong and weak hypotheses. The field and science is embodied by variety of conferences and journals to handle different levels of rigor or different subtopics like modularity or adaptability or distribution or declarative.

PL theory is actually a pretty bad monicker by most metrics. I suppose that's why many just call it PL.

I guess before PL went on its science kick, it might have all been called PL theory, but now rigor and science firmly occupy the theory monicker. Design, engineering, science, theory all have meanings that conjure up different activities.

We are just arguing about a word here. I'm trying to avoid the awkward situation of someone actually thinking they'll find something applicable to UX in a POPL paper. And ya, to many of us, when we hear "PL theory", we think POPL and run away, nothing useful can come of it as inputs into design activities.

"nothing useful can come of it as inputs into design activities."

If somebody invents / finds / discovers something super keen that would help me write less broken software systems, then I want it, and I want it to be available in as best a UX way as possible. So if the design activity does not know what is out there in the POPL sense, then it is leaving money on the table.

If you want to implement and build things, then sure it is useful. If you want to design better user experiences, you are firmly in the design world since humans aren't very logical creatures. Well, you can benefit from a bit of empiricism (like say Fitts's Law) from experimental psychology, which isn't rooted in the POPL world.

seriously. We need more of that.

I've talked with them about it, and this is pretty much the actual way they control the knitting machine right now. They even use JavaScript! They've built DSLs for knitting shapes that are combinations of tubes this way, but their open question is whether there are approaches that are more convenient or less error-prone.

For an example of something that could be more convenient: If I understand correctly, the patterns can be implemented in a way that's folded, U-turning from one set of needles onto the other. This is usually inconsequential to the finished product, but it makes it possible to form tube shapes. This implementation detail matters at a global level because the entire pattern must be alloted to a limited supply of needles, and all the tubes must be planned for. However, it would be very nice for modularity to compile from a source language where we can ignore this detail; as long as folding is hardcoded even in the local, flat regions of the pattern, it's hard to extract reusable components.

The authors think this (hypothetical) compiler's needle allocation algorithm could have some commonalities with register allocation.