Metaphors we Program By: Space, Action and Society in Java

It is usually unknown that it exists a Conference of Psychology of Programming .

A lot of papers concern firstly educational problematics. But certain of these are more originals.

It's the case of the Alan Blackwell's paper "Metaphors we Program By: Space, Action and Society in Java".

Blackwell analyses how the authors of Java.lang and Java.bean library understand, in a cognitive way, their code.
To do that, he analyses the javadoc of these two librarys. After describing his methodology, he state some aphorisms he extract from his study. Some of these are remind here.

Firstly, programmers understand components as agent :

  • Components are agents of action in a causal universe
  • Components have communicative intent
  • Components are members of a society
  • A component has beliefs and intentions

It is here interesting to think about AgentSpeak which is a well-known Belief-Desire-Intention Agent oriented language.

Moreover, agents are proactives :

  • Method calls are speech acts
  • Programs can author texts

These agents live in a deontic world :

  • Components are subject to legal constraints
  • Components are subject to moral and aesthetic judgment.

These agents live in a time/space world :

  • Components observe and seek information in the execution environment
  • Components own and trade data
  • Programs operate in historical time
  • Programs operate in a spatial world with containment and extent
  • Execution is a journey in some landscape.
  • Program logic is a physical structure, with material properties and subject to decay
  • Data is a substance that flows and is stored.

To Conclude, it seems programmers doesn't think their code in a mathematical, object, functional way, but in a world where Belief-Intention-Agents live in a deontic and temporal and geographic world.
It is interesting to see how it looks like our daily world.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Mathematical origin

Early in the paper it is noted that the language of the documentation considered in the study was mostly influenced by CS textbooks on OOP and to some degree by mathematical jargon. It would be interestind to (a) have a similar study on the theoretical/mathematical side of things (concurrency related research would probably provide a fascinating corpus) and (b) have a study like this done in a functional setting. What mental models are common to funtional, imperative, OO, etc. programmers, i.e. what ere the fundamental metaphors and where do they come from? It would probably be interesting as well to interview programmers who have done library design and written a fair bit of documentation where they picked up some of the frequently used terms and how the "feel" about them.

Not considered in this paper

The paper's authors expressly state that they chose to disregard conceptual metaphors which were known already from mathematical and philosophical discourse; instead, they focused on novel metaphors arising from Java programming.

The paper itself gives a reference for conceptual metaphors in philosophy; as for math, the seminal text is Lakoff & Núñez, Where Mathematics Comes From.

It seems that Dijkstra was

It seems that Dijkstra was right when he talked about the dangers of anthropomorphism.

There should be no novel metaphors unless they are extensions of mathematical concepts. These metaphors may confuse other people who use the code and may obscure potential analysis of it. If you're told to think of a program as a person, you might not realize that it can do a ton of things that a person can't do because you're stuck within the broken metaphor or analogy.

Metaphors are a part of

Metaphors are a part of human thinking. Some people can use math as a metaphor, but they can't escape them completely.

A classic paper in this area would be Randall Smith's "Experiences with the alternate reality kit: an example of the tension between literalism and magic" paper.

Dijkstra was wrong

I think software programming in the little world of Dijkstra was just about scientific calculus and mathematic reasoning or artificial intelligence.

For all theses subjects, he was absolutely right, particularly for mathematical reasoning.
Adding that all these software are designed and programmed by strongly skilled programmers.

But the main part of the programming industry is just about business software, wrote by average programmers (2 years technical degree for most of them). It's the reason of the success of poor languages like Java.

In fact, computer language are just the evolution of patch cables of the early computers.

So I think Dijkstra was wrong and made a lot of damage to all the research around natural language programming, metaphorical programming and so on. He mistook his limited world of maths and logic with business software industry.

I work and worked in the two world, and if i'm agree with him a language such as haskell is perfect to write a prolog reasoner, Haskell is absolutely a wrong language to write a small business stock managing software.

Today's language are like dumb, amnesic and stupid agents. There is no time semantic.

The future of business software industry, amha, will be metaphorical language, which will permit the programmer to write software with space and time semantically fit in the language.

Today, it's a real pain to write a simple concept like "if client ordered several goods in one day then gather them together and sent them in the same pack".
A software can be viewed as a collaboration between stupid workers, which are Belief-Desire-Intention agents. These agents, if they would be human, especially when they make a stupid task, would be all able to think in term of space, of time, and rules.
So why not for software which are made to automatize tasks previously made by humans ?

The problem of software language is the inability to integrate Artificial Intelligence, to help the programmer to formalize his ideas, to help him to build complex behavior of the software.
Why ? Because AI's researcher work on their topic, language researcher are focused to type safety (which is a very good topic), and they don't talk with others.

Conclusion, for some topics, metaphors are good.

Anyone read this? Geary J.,

Anyone read this? Geary J., "I Is an Other: The Secret Life of Metaphor and How It Shapes the Way We See the World." (2011)

Not a valid conclusion

To Conclude, it seems programmers doesn't think their code in a mathematical, object, functional way, but in a world where Belief-Intention-Agents live in a deontic and temporal and geographic world.

The implication here is that the metaphors of geography, temporality and deontology are opposed to mathematical thinking. That would be to confuse the stylistics of formal mathematical writing with mathematical thinking.

Informal mathematical writing is full of metaphors and even in the most formal mathematical writing, the terminology leaks clues that mathematicians are thinking in metaphor. Who studies differential equations without thinking of the passage of time? Who thinks about manifolds without thinking of the manifolds living in a space? Who studies algebra without talking about laws or rules?

Book

People interested in this thread might enjoy a remarkably interesting book I've been reading recently. While it is about the history of chemistry, and scientific realism, notation plays a significant role in the story. The book is Alan J. Rocke, _Image & Reality - Kekule, Kopp, and the Scientific Imagination_ (Chicago, 2010). Highly recommended.

Interesting

What diagrams does it pick to demonstrate the role of notation in chemistry? Is it well-balanced, written from several viewpoints (e.g., physical chemistry, organic synthesis, etc...)?

The book is a very detailed

The book is a very detailed look at a particular time in the history of chemistry (the origin of structure theory in organic chemistry; the benzene ring). A significant portion of the discussion is devoted to the sausage notation of Kekule, though other notations of that period are discussed as well (Crum Brown, Lochschmidt, Couper).