Thanks for continuing the topic! This article is quite lengthy, so I will try to concentrate on the descriptive / performative.

I tend to always generalize, and generalize big. So please excuse me if what I say goes way outside “coding something in C++, X-something” or even beyond methodologies.

But first, a note about modelling. I can’t now find the reference (it was a video I saw on Safari Learning from one software modelling guru, years ago). Scientists and programmers understand “model” differently. While concept of model has common ancestor, understanding is quite different, so one can’t mechanically transfer knowledge about math models to software models. My impression is, this difference is silently ignored in the article.

It is also interesting to look at how descriptive / performative. There are paradigms with very blurred boundaries. For example, in some programming languages code and data can be indistinguishable: Code can be both executed and be input and output of execution. There are systems we can program in logic, so the “v1 = v + 2” is no longer an operation, but description, and the whole operation boils down to finding solution, which satisfies description. And of course von Neumann architecture is about storing instructions and data together, though processor as always “aware” what to execute next with a special register — program counter / instruction pointer.

As for the modelling, if we take “scientific” model, it does not have anything “performative”. Even though apple (possibly) fall on Newton’s head, which we can stretch to describe as something performative, physical laws and models for physical systems are usually modeled by equations. And equations do not care much which direction one takes to compute something.

I am sure that the author is not speaking about such kinds of models, because without them certain kinds of software are impossible to do. No amount of linguistics and human “common sense” can replace an algorithm (and a model it is based on), which calculates space craft coordinates given sensor measurements.

This means, that claimed modelling bias and reasoning in the article is really about software models. In other words, models of software. (Again, not to be confused with software development models, such as waterfall, iterative, etc).

And yes, of course, model of software can’t (and it’s not it’s purpose!) to grasp all details of the software. It’s a model after all! It may depict higher level architectural details (for example, which components are dependent on which other components), or some well-understood low-level mechanism (for example, finite state automation can be good abstraction to describe classic traffic lights behavior), or the model can even be there to ensure properties of the software being written, for example, file system operation can be described in TLA⁺ specifications, and certain good properties can be thus semi-automatically verified (or course, the model in this case almost becomes the code). Some systems, heavily using declarative programming of some sort, can even rely on desired system state description to figure out what is there to perform. For example, Salt (software configuration management tool) uses description of system state and then brings the system to that state when told to do so: Performative side is deduced from the difference in current and desired state. (Perhaps, that is ideal and easiest for entrepreneurs: current state -> “I am multimillionaire” )

I agree to the main conclusions of the article (making a software product is a language activity), but I can’t agree modelling has no place in software development, even if we understand model as model of software [being built]. My answer to that is: Certain aspects of software systems are better communicated as models, expressed visually. Certain (and quite many) problems of software systems can be solved using representations other than text initially. Certain properties of the systems we deal with can be noticed only in “alternative” ways: Visualizations, sonifications, maybe even mechanizations. Which actually is not different from how we produce speech or written text. “I see …”, “I told you…”, “I can almost smell …” in natural utterances gives hints where “facts” (objective or subjective) come from. Same with software development: While the final product is expressed in some formal languages, the method to create that product is not necessarily consisting only of manipulation of symbols and words or digging logic from words meaning.

Now back to ontologies (and vocabularies). Those are lower level tools. They are more like source of first (second, third) approximation of the knowledge about domain. If one never played chess, then starting with chess’s ontology makes a lot of sense: How pieces are called? How to refer to a certain place on the board? How certain situations are called? Etc. Of course, some domains are more flexible, but then other domains are strictly standardized, so while “static” ontologies can’t be converted to software as such, they can serve as a good approximations, leveraging widely acknowledged (standardized) meanings. These constitute backbone of domain knowledge. If not for them, people will not be able to agree on anything. It does not mean that in order to make software we should make explicit ontology. No. Those can be implicit or explicit, but they always are present, be it a novel in natural language or a code module, which deals with business rules.

OOP (in most cases, even when misused) is one way to express ontologies. It should not even mean that is we have class User, then that class is 1-to-1 with a user, no, it’s still UserInSomeContext: Maybe, from IAM system point of view, or as an owner of some content, or tens of other contexts, which software system can refer to some global identity of the User, but store data and behavior in multiple micro-services. (In other words, naive modelling will lead to god-classes — known anti-pattern.)

Of course, I am sorry for programmers who try to decipher ontologies by “reverse engineering” impenetrable legacy code (getting the meaning from “use”). But in my opinion, regardless of whether we use OOP or FP or some other P, we deal with ontologies. This is basic mode, so fundamental, that it came originally from philosophy (actually, like many other concepts in linguistics).

I think one important moment is missing from the discussion. One of meta-theory a la Rudolf Carnap dealt with in formalizing scientific language. Programming at it’s core is formalization, but it’s so multi-layered, that levels become meta for levels. Name of a function (and what is needed to call it) at upper layer gets all gory details inside function implementation. But this is property of any design, not necessarily designing software.