Ian Patrick Badtrousers

001 Discourse

This is the first in the series of notes on language and engineering, a write-up on discourse.

First, if you don’t know what proposition is, imagine proposition is like a sequence of words, some of which may or may not have sense, but it doesn’t matter anyway, what matters is that the sequence defines what the proposition means. There still can be some fuss about what elementary proposition means, and these are the only propositions that directly correspond to the state of the affairs, therefore they cannot possibly contradict each other. Elementary propositions are so unlike others, if you were to ask me to name one, I’d probably be lost.

I’ve used the word discourse multiple times in the past, but it never really occurred to me to explain precisely what I mean when I say it. probably overused the word to a certain extent in the Veritas Blackpaper, as well as in my last essay On language, history and system design. I don’t feel bad about it. It was very clear for me that with both attempts at writing, I entered a somewhat loosely, if at-all defined territory, and I gave in fully to the fact that I wasn’t even approximately aware as to where I was at in my own study of language. Then, having received some substantial feedback from my peers, specialists in the referred fields, and even from the academia people, I formed a much more solid understanding of what I found so appealing about Wittgenstein’s account of logic, and how it’s rooted, or I should say, can only be shown by grammar. My revelation came when I went on to think more about the following statement in TLP, and I believe it defines the object of discourse per se incredibly well:

[**4.51.**](http://tractatus-online.appspot.com/Tractatus/jonathan/D.html#c5.11) Suppose that I am given all elementary propositions: then I can simply ask what propositions I can build out of them. And there I have all propositions, and that fixes their limits.

My initial thought was that the limit here is solely determined by the grammar, which arises from the totality of elementary propositions. I long thought that, until I figured that the limit also clearly depends on the subject: the one who makes use of the language; and this logic is subtly predicated by “what I can ask” and “I can build” clauses, respectively. So I decided to go on and further extend this line of reasoning: suppose that I am given all propositions, is this now sufficient to realise all possible states of the affairs that can occur? It’s certainly sufficient to realise all possible texts that could be built using these propositions. However, the same text can paint many completely different states of the affairs, depending on the exact configuration of subjects. That is the reason why when talking of discourse, we usually differentiate between the object of it (language that is being used) and its subjects (the ones who use it.)

What discourse has to do with system architecture? The idea of discourse models perfectly well how language is used by people to realise states of the affairs, and how states change over time. The same concept can be applied to any system designed by humans. This is moreso the case for modern computer systems, which largely consist of very confusing, semi-baked imitations of linguistic practices, tediously framed into the syntaxic form of the fancied programming language. They call these imitations design patterns, and they truly are patterns: not naturally occuring, but hand-crafted and forced, at times desparately so. The sheer amount of abstract concepts, references, and relationships OOP patterns require to sustain themselves, has nothing to do with the nature of data, but everything—with clumsy theory of types, which admittedly reasonable and useful in the domain of its application, formed an unhealthy status quo in the programming language design community. They wouldn’t let “unorthodox”, or shall I say, simply alternative views be tried out.

Unfortunately, it’s not news that programming language design community is all just a bunch of assholes. I’m sorry, guys, but remember what you did to David M. Harland? The dude was doing some brave language research, and then you basically what, just disappointed him with your narrow-mindedness, so the guy went on to become to write a bunch of books about space?! Rekursiv squad, assemble! I mean, good for the space books business, but I sincerely need all that mad object-oriented CPU concurrency talk to sustain productive dialectical state of mind. Check this out:

“Realising that calculus has actually got nothing at all to do with either differentiation or integration, but is actually a set of rules for lexicographical transformations, with differential calculus and integral calculus being two examples, I came to the conclusion that there is a fundamental principle for the design of a programming language based on an interpretation of the process of abstraction in terms of a calculus of semantics-preserving transformations reflexive over the domain of syntactic clauses.

The problem for most languages, of course, is that not all the clauses in the grammar are abstractable over, and for many that are the semantics are not strictly preserved when abstraction is performed, which sort of ruins the point.

Abstraction is a calculus of semantics-preserving transformations reflexive over the domain of syntactic clauses.”

— David M. Harland

The above is not an exact quote, but rather a collage, which I’m not embarrassed to have found on Hacker News. You should check out the thread in full though, if you’re interested enough in this kind of stuff. I’m bringing this up because you must know that if that’s what happened to the talented, clever, and creative guy like him, I’m only left to wonder what they will do to me if my ideas ever get noticed.


When we talk of discourse, we differentiate between object of discourse—text, consisting of the language used in said text and the subject of discourse—a set of its partaking speakers.

Published: Monday, 30 Sep 2019

This post allows opt-in commentary, powered by Disqus.