I’ve been asked on twitter about “foundational readings” in the physics of software, besides my papers.
That’s either an easy question or a very hard question, depending on how you want to answer.
On one side, I pretty much came up with all the ideas in what I called “the physics of software”. So I could say that beyond the papers on this website, on carlopescio.com, my talks, random notes like this one, and a few conversations in the forum, there is nothing else to read. Well, there is in fact a talk by Jérémie Chassaing on the Thermodynamics of Software which is inspired by the general conceptual framework of the physics of software (watch it on youtube), but that would be it.
That’s not a great answer though. One may want to investigate things on their own, and of course I based my reasoning on previous knowledge, so there has to be some foundational reading somewhere. Strictly speaking, it would not be about “the physics of software”, but about notions that are relevant for the physics of software. In fact, I have hundreds of those works filed under “references”.
Listing hundreds of papers / books isn’t helpful either, so I’ve put together this list (some are papers / books, but some are just topics). In many cases, you would find references and links to more specific works inside my papers / posts. I’ve classified the relevant works in a few categories, which should be self-describing enough: General knowledge; Inspirational; Failed attempts; Decision Space; Artifact Space; Run-Time space.
 
General knowledge:
A working knowledge of math, science, engineering, computer science / formal methods, software design / programming is needed. Some epistemology would help. Some psychology helps too; I’ve found the Gestalt approach (particularly the sub-field of Productive Thinking) quite useful.
Information theory: classical entropy-centric stuff by Shannon (“A Mathematical Model of Communications”), but also Kolgomorov Complexity and the Constructor Theory perspective on information; generally speaking, learning about Constructor Theory would provide an interesting point of view.
Symmetry in software: there are many works by Jim Coplien, and Liping Zhao, like “Symmetry Breaking in Software Patterns”.
Learning about Intensional vs. Extensional definitions, Nominative vs. Structural type systems, etc. will help. These should be covered in a master-level CS education, but I’m a bit out of touch with what is being taught today.
It would also help to have some understanding of theory building, the role of a scientific theory, the history of science.
 
Inspirational Works
Many early ideas came from reading Christopher Alexander’s works, more exactly:

• Notes on the Synthesis of Form (this is also the book that inspired Coupling / Cohesion back in the 70s)
• The Nature of Order
• Harmony-Seeking Computations

I’ve found some inspiration also in “On Growth and Form” by D’Arcy, and in “The Reflective Professional” by Schon.
Early ideas on software as executable knowledge came from Phillip Armour’s “The Laws of Software Process”.
More recently, a few unpublished ideas came from “Concepts of Force” by Jammer.
 
Failed Attempts
One could argue that the most prominent failed attempt is mine : ), but along with that, I would list:

• “software science” by Halstead
• Most of the literature on metrics

Understanding why is a long journey, which should start with measurement theory. I’m trying to ground most of my recent work in the representational theory of measurement to avoid most of those issues. Reading the original works above and their criticism is an interesting lesson on what we should not do.
A couple of CS papers that are relevant if we want to avoid mistakes made while defining metrics are “Property-based software engineering measurement” by Briand / Morasca / Basili and  "Software Measurement: A Necessary Scientific Basis” by Fenton.
 
Decision space
There isn’t much on decisions that is somewhat aligned with their model in the decision space. Sure, one has to learn Conway’s law and a few other “laws”. Reading “Systemantics” by Jon Gall would also help. A different model, but with some points of contact, is being carried out by Mark Burgess as part of Promise Theory, which would not hurt to read about.
Conceptual spaces are also explored in “The Geometry of Meaning: Semantics Based on Conceptual Spaces” by Peter Gärdenfors, which I haven’t fully read yet : )
 
Artifact space
Here, to be fair, there isn’t much that closely resembles my perspective. I would suggest to read the early papers on coupling and cohesion, also to appreciate how different those were from what we’re hearing now. Connascence (Meilir Page-Jones ) is close enough to entanglement (which however I consider a better concept) and it would deserve to be known.
Generally speaking, understanding principles, patterns etc. would help, not in the sense that they form the physics of software, but that deep under many principles we do have phenomena in the physics of software. Reading about power laws and how they manifest in software is also useful.
Reading the rationale papers / books on programming language design helps too. Languages ultimately influence the way we structure our artifacts, and understanding the design choice of language designers helps quite a bit. I would also suggest to investigate unpopular paradigms (like AOP) which offer affordances not usually found in mainstream programming.
 
Run-Time space
I have left many references in my blog (especially when talking about distance and friction), so I won’t repeat them here. Generally speaking, understanding CPU/computer architecture, cache/memory architecture, known laws like the Amdahl law and the CAP Theorem is necessary to get a grip on the run-time space.
 
This is not a definitive list, and any suggestion is welcome. Remember: it’s not about being a classic, it’s about being relevant for someone learning the physics of software.
 
 

​A little over one year ago, I posted this short thought to twitter:

While I’ve largely abandoned my work on the physics of software, a few days ago I stumbled on some notes and I somehow felt a small push to write down a little on this subject. No big deal, but perhaps some of you will find it interesting.

Most languages have a notion of identifiers; in the common conceptual framework of denotational semantics, identifiers are syntactic elements, and they denote something[*] in the semantic world. That denotation is said to give meaning to the identifier. [*] “something” can be a value, but also a function, a procedure, etc.

Most languages also have a notion of scope. The scope is again a syntactic notion, through which a specific binding from identifiers to value takes place. This is commonly modeled in denotation semantics through the notion of environment. 

What is the notion of scope actually accomplishing? It’s creating a way to make meaning local, in this case local within a scope. [I won’t go into the different ways one can define locality and distance; it would take too much and I think the ideas here can be followed without that piece of the puzzle.]

Late binding (dynamic binding), usually experienced these days through inheritance + polymorphism, allows (e.g.) a derived class to create a new locus of meaning. Note that in this case the new locus includes all the parent classes, when the target object is of a specific derived class. It’s through this ability to create locality of meaning that run-time polymorphism (late binding in general) becomes useful.

Meaning is not restricted to values. Generic types have a denotation as well, and some languages allow once again to locally redefine a generic type, where locality is not defined by scoping but by type specialization. Consider good old C++:

template< typename T > class Vector { … } ;

That would model a Vector of T, for any type T. Unlike many other languages, C++ allows partial and total specialization on T, so you could say:

template<> class Vector<bool> { … } ;

And define an optimized version of Vector when T is bool, or

Template< typename T > class Vector< T* > { … }

And define an ad-hoc version of Vector when a pointer type is involved, etc.

There are somewhat complicated rules to choose the “best option” when Vector<Something> is used, which can really be seen as finding the specialization that is closer to Something, given the right notion of distance. Again, however, it is in its ability to define new loci of meaning that template specialization gets most of its power.

In most imperative languages, the sequencing of operations is specified as part of the denotational semantics, but is a language-level choice that cannot be altered. The meaning of syntactical sequencing is sequential execution. That is not true in functional, lazy languages, where evaluation is carried out on demand, and order is determined by needs. Still, other parts are usually hard-coded in functional languages, like the meaning of function composition. Monads get their real power because they allow the programmer to define a new locus[*] of meaning for sequencing, providing local semantics for what it means to chain operations together. [*] Note how the vernacular "lifting into the monad" implicitly recognizes the locus.

Every paradigm / language gets power from constructs that allow to create locality of meaning (not just for identifiers, as we have just seen).
Consider Aspect Orientation. A pointcut implies a binary distance measure - either you match with the pointcut or not. An advice provides redefined meaning for a number of things within the locus falling inside a pointcut.
Consider DCI. The entire point of DCI is that the Context defines the available methods on the objects[*] - once they get inside the context (the context being, of course, our locus of meaning for the objects). [*] Yes, it’s the context not the class. 

Why is this worth understanding? Two reasons:

- when you see something powerful in a language, if it fits within this notion, you gain an interesting perspective by understanding in depth what is the distance at play, and which kind of meaning is possible to [re]define locally.

- as one of the central themes in the Physics of Software, a solid understanding of this notion, even better if backed up by an extensive review of existing programming languages, can lead to better material engineering, that is, better programming language design, less focused on grandiose thinking and more focused on which reactions we want from our artifacts when a certain stimulus is applied.

Of course, that’s the missing part in this post: why are all of the above useful? Which stimuli do the handle well, and how? Questions to which I can only answer by copying here another tweet of mine:

So, go make it a better world, thanks!

​I recently came to one of those incredibly simple conclusions (in hindsight) that nonetheless I think will help creating a better conceptual model (and ultimately a better formal model) of many notions in the physics of software.

You probably remember Newton’s Third Law of motion: when one body exerts a force on a second body, the second body simultaneously exerts a force equal in magnitude and opposite in direction on the first body. This is often called action-reaction. The two forces actually happens simultaneously.

Even outside motion laws, most physical phenomena are still based on the idea that you apply a force / differential / stimulus / whatever and something happens pretty much instantaneously as a direct consequence. You apply a difference of potential to a conductor, and you have current flowing according to Ohm’s law. You apply electrostatic charges to a couple of bodies, and a force (of interaction) appears as a direct consequence, according to Coulomb’s law. We come to expect this sort of stimulus -> response relationship to be direct and in many cases immediate (on a human scale).

There are, of course, cases where the more macroscopic phenomenon is not immediate, although it’s still a direct consequence of the stimulus. If you add heat to water, it stays liquid until the boiling point is reached. But of course that’s just one macroscopic view. At a different level, temperature is still increasing as a direct consequence of adding heat up to the boiling point. You do more of the same, and then a phase transition also happens.

Oversimplifying things to the point that I’m bordering on being wrong :-), I could say that by and large (but not always, see later) our models of the physical world are based on a direct Stimulus -> Response relationship (sometimes extremely complex, but still direct).

This does not translate well to the physics of software, which is probably why we get many expectations wrong (it does not conform to “naïve physics” expectations about how things work in our universe).

In software, you apply a stimulus and in most cases nothing noticeable happens. (Yes, I may have said otherwise before. I was imprecise. Read on for a better model.) You duplicate code. Nothing really happens. You keep duplicating. Nothing happens. You map an open set into a single artifact through a more or less glorified switch/case. Nothing happens.

Nothing happens until the next relevant event. You change a decision embodied in the code you’ve duplicated. Now you have to change all the copies. You add an entry to the open set. Now your artifact grows bigger.

Following this observation, the physics of software is better modeled as Stimulus -> Trigger -> Response. That is, if you apply a force (as I tend to call any kind of stimulus, waiting for a better term), and in most cases nothing happens as an immediate effect. It’s only when a subsequent event (trigger) happens that you get a specific response – possibly in a distant future, maybe never.

That’s why most non-functional properties are potentials. They’re the result of a stimulus, waiting for an event to happen.

Note: some chemical processes work in a similar way. You mix nitric acid and glycerin, and if you’re careful enough, nothing noticeable happens but a lot of potential energy is accumulated. The energy is released when triggered (for instance by a mechanical shock). So, in a sense, software is like explosives :-).
 
A more precise model
[This section might be hard to follow if you don’t have a good grasp of the difference between the essential interpreter of code (the computer) and the contingent interpreter (the human). Unfortunately I don’t have any introductory material. Sorry for that. See Gabriel and also some ideas in a previous random note of mine. If it sounds “wrong”, there is a chance that we’re not really understanding each other here.]

Let’s say that our models of the physical world (oversimplified as above) are based on a function Stimulus -> Response. According to the above, phenomena in the physics of software would be better modeled by a function (Stimulus, Trigger) -> Response. As the (contingent) interpreter of reality, we see a separation in time between Stimulus and Trigger, and therefore we tend to mentally curry the function. We apply a stimulus, and by doing so we set up our artifact to become, de facto, a function from Trigger to Response (do not mistake this as the function encoded into the artifact, to be executed by the essential interpreter [the computer]; I’m talking about the function as seen by the human contingent interpreter, or the function encoded in the shape of the artifact). In fact, a potential is exactly that: the ability to do something when triggered.

This model is still imprecise, in that is capturing only part of the reality; it might be more than adequate in some cases, but if we’re after a general form that can capture most phenomena in the physics of software, we need to cater for the (less apparent) immediate reaction as well.

Why do people duplicate code? Well, many reasons, but one is that it’s the path of least energy. Energy spent immediately, not later on. Therefore there must be a resisting force when we do something else, a force that makes us waste more energy. That’s happening immediately, so it’s not captured in the model above, and it’s in fact closer to what happens in the physical world.

So a more comprehensive model for most phenomena in the physics of software would be a function like:

Stimulus -> ( Immediate Response, Trigger -> Potential Response )

​Stimulus and Triggers originate in the decision space. It is possible that we may have to model a number of immediate and potential responses, in which case a trivial extension of the model would be

Stimulus -> ( { Immediate Response }, Trigger -> { Potential Response } )

Phenomena in the physics of software should therefore be simply pairs in the domain / codomain of such function, like:

(Artifact cloned, ( { low resistance, U/U entanglement }, { (Update, { Scattered Update } ) } )

[where the function Trigger -> { Potential Response }  is represented extensionally]

That’s expressing the idea that if you clone artifact, the immediate response is that you get low resistance and Update/Update entanglement between clones, and when triggered by an update in one artifact, you get a scattered update to all the U/U entangled clones. 

I think this better model will become useful as I try to bring more clarity into the work I’ve done so far and hopefully will provide a better foundation for future works.

As usual, I welcome your feedback. So far, the only person to whom I’ve told the story in real life has spent all his time trying to convince me that I was wrong, so maybe I am.

Recently Emilien Pecoul has posted an interesting commentary on the physics of software (Coding in N dimensions). He makes two major points:

  - the need to introduce time along with the 3 spaces in the physics of software 

  - the ability of a software professional to move through the 3 spaces (run-time / artifact / decision)

I added a comment on the latter on his blog (so if you’re interested just go there and read his post too :-) but I thought I could add something about Time here, because I’d like to keep most of the “core stuff” in one place.

Emilien is right that I didn’t talk about time in my DDDEU presentation. I only had 45 min, and there was no time for Time. However, time plays an important role in the physics of software; also, we’ll see that it extends beyond our conventional notion of time.

Let’s start with the run-time space, because things are always easier there. We already know that we often deal with two notions of time when we think about the run-time space:

  - conventional time, or “elapsed time”. When we think about a timeout, especially if it concerns communicating with something outside our system, we think about conventional time.

  - CPU / process time. When we want to measure the “efficiency” of CPU-bound code, elapsed time is not a good measure. If our process was not scheduled for some (elapsed-time) interval, CPU time actually *didn’t change* in our reference frame. I tend to say “Machine Time” instead of “CPU time” to avoid dragging in terminology like CPU, scheduler and so on.

Machine Time is quantized / discrete, as it normally moves in clock ticks. Its relationship with elapsed time depends primarily on scheduling, and it’s non-deterministic in any architecture with interrupts.

Interestingly, there are / have been clockless CPUs, although they never really got traction. They fall in the more general category of asynchronous, self-timed circuit (see the wikipedia page for an introduction). Now, with an asynchronous CPU, Machine Time “flows” depending on availability of data / need to compute, and that’s logically close to a data-flow model, but (this would be a long story) you can also see it as unfolding according to run-time entanglement. Information enters the run-time space, and it’s propagated and transformed along the path set by run-time entanglement.

Now let’s move to the artifact space. Here too we can consider two notions of time. One is again the conventional time. It’s what allows us to say that we made a change or created an artifact at a specific moment in (conventional) time. It’s useful in some scenarios, but it’s not the most relevant notion of time we need to consider when we think about the artifact space.

I’ll take a short diversion to explain why. There is a common phenomenon known as “software aging” or even “software rot” (see for instance wikipedia again). Now, as usual in software, many different notions are conflated into that single, vague concept. So some people consider degradation through cumulative insertion of defects a component of software rot; others consider the misalignment with current requirements a component, and so on. If we stay at this level of vagueness, the concept is bound to remain an interesting metaphor and nothing more.

If we decompose it, we may notice a component that is particularly relevant here. Say that at some time T1 you have a set of (technical and business) decisions {D1,…,Dn} and that your set of artifacts {A1,…,Ak} is in perfect alignment with those decisions (yes, that’s not possible in practice, but it’s ok for the reasoning). Say that {D1,…,Dn} do not change for a long (conventional) time. Your software won’t experience any aging / decay / rot. It’s perfectly fine and functional. It’s only when one of those decisions changes that the knowledge encoded inside your artifacts is no longer aligned with the decision space. That’s a “clock tick” in the artifact space, that is really making it age / rot / decay. Once again, the tick is carried over through a form of entanglement, this time by the decision -> artifact (cross-space) entanglement.
I tend to call this dimension the “Decision Time”, even though it’s advancing time in the reference frame of the Artifact space. As usual, I’m open to better names. BTW: it easily follows from the above that every model of decay based on conventional time makes little sense. Your FFT code ain’t going to decay any time soon (with relevant decisions here being only the language or HW that may have influenced the code; the algorithm itself is quite stable). Of course, the decision of using an FFT is still open to change.

Finally we have time in the decision space, and we normally consider conventional time here, because we are outside the realm of encoded information and in close contact with humans, society, regulations, etc.

There are many other places where time plays a role in the physics of software. For instance, my talk “On Growth and Software” was about software growing… over time, of course. So time is a pervasive notion in the physics of software, and this short post can only be considered as a proxy for a much larger chapter of an unwritten book.

Feedback is welcome as usual; go ahead and open a Time topic in the forum under “discussion on concepts”  if you can’t find one yet.

My nCrafts talk (On Growth and Software) is, in a sense, applied physics of software, that is, it's an example of the reasoning style that is supported and inspired by an understanding of forces and reactions. That's one step from theory into practice.

At the end of the talk, I quickly proposed a simple way to break symmetry in a traditional OO language (C# in this case) and how we can make it completely type-safe through an extension to the language, that is, the ability to impose constraints on the type systems in the form of (logical) implications.

The straightforward way to do so is to modify the language / compiler, but it turns out that with the latest C# compiler you can extend the compiler pipeline to some extent, through so-called Code-Aware Libraries. You can't add new keywords, but if you can reframe your extension in terms of the existing language, the big win is that a Code-Aware Library will work with the standard C# compiler.

I decided to do yet one more step into practice and implement my extension as a CAL. It was relatively straightforward and it worked well in practice, although I had to accept a slightly less minimal syntax. Here is an example of the error messages you get when:

- you try to safely cross-cast between interfaces not related by an implication.
- you state an implication between interfaces, but then have a concrete class that does not respect the implication.

The code/extension is not public yet and you'll have to watch the presentation to understand the reasoning behind it.

So this is a double step into practice, or as I mentioned in my DDDEU talk, an example of how understanding forces can ultimately lead to create materials (language constructs) on purpose, pretty much like material engineering.

​

A recording of my talk  "On Growth and Software" at ncrafts Paris 2016 is now online. Some supplemental material:

- slides for the talk.

- an old blog post somewhat related to what I discussed there; more as an "historical" reference as my perspective changed over years.

- a few reflections I jot down after coming back from the conference

Feedback is welcome, as usual. I've already set up a topic in the physics of software forum. See you there :-)

(pic taken and twitted from Dragoş Dreptate)

I had the chance to talk on what I consider “Applied Physics of Software” at ncrafts 2016 in Paris, where I presented “On Growth and Software” on may 12th. This is a short report on the experience; it’s a bit self-centered (sorry) and won’t say much about the other talks I’ve attended, but I still want to take the time to thank a few people: Romeu Moura (who invited me) and Peter Even were super-nice and handled all the travel arrangements swiftly. Cyrille Martraire was my local best friend :-) and even if I didn’t collect my conference bag of goodies (so no stickers!) he still got me the brilliant Arolla dice ​(they should probably set up a side business selling those on eBay or Amazon)

 The entire staff ensured everything worked like a charm. Thanks guys :-).
​
A great chance to talk to people
This was hands-down the conference where I had more chances to chat with other speakers and attendees. We actually skipped a few talks as we kept talking, but as Rui Carvalho said in the opening speech, you can always find the videos on the internet in the end, so the real reason in going to a conference is your chance to exchange ideas with interesting people. I had a long conversation with Jérémie Chassaing, overdue and of course much more productive than short messages on twitter.

My talk
I could have done better on my talk - although I had of course rehearsed it, I was slower than expected. I just felt that I needed to stay on some concepts a little longer. On retrospect, I could have probably skipped some of the initial stuff about physical objects, or asked for a slightly longer time slot, or both. The bottom line is that I had to skip quite a few slides, which is never nice, but I do hope the overall message came through well enough.

There was a time slot for open sessions / unconference on day 2 (my talk was on day 1). I choose to take part in that (expecting to listen and watch) but Cyrille proposed “DDD and the Physics of Software” which got just enough votes that I got dragged :-) into talking more about PHOS in general. Cyrille also managed to grab Laurent Bossavit whose reservations about the entire approach I was in fact eager to know better.

Looking back
To be honest, I came back both happy to have done the talk and somewhat tempted to quit this work :-).

On one side, a few people were genuinely interested, and a couple of speakers even made a reference to my talk during theirs, which was nice, and felt almost as some concepts could have a chance to become mainstream [names of the speakers omitted to protect them from those who hate this idea with a passion :-)].

The conversations I had are definitely pushing me to write down some preliminary ideas on the notion of “flexibility”, which like many others in our field is being used to mean whatever we want at that moment, but I think could be characterized more precisely. While doing so, I could also take the chance to explain why I said that the growth model of our code should follow the growth model of our decisions (when we want what is normally called “ease of extension / contraction”), but also why the shape of our code itself should not be an exact mirror of the decision space (following a remark by Cyrille that if decisions and artifacts get somewhat isomorphic, it makes little sense to distinguish between the two; but in a departure from Alexander’s idea of form being in “frictionless contact” with context, the notion of “flexibility” should prove that we need some slack there).

On the other side, many comments seemed to point toward a general sentiment (also echoed in private emails etc.) that yeah, maybe, if this theory was complete, better, more quantitative / comprehensive / immediately applicable / to the point, then it would make sense to play with it, but given that the community has many other larger problems and is anyway happy going by the seat of its collective pants, and that I won’t be able to complete this work in my lifespan, and that even if I do it may turn out to be completely irrelevant (a risk that I have admitted to accept), well, I might be better off spending my time hiking instead.

My standard answer is that we already have a ton of quantitative metrics but nobody uses them, and that it also took some time for the theory of gravity to go from Aristotle to Galileo to Newton to Einstein, but every step was still useful and although imprecise, incorrect, and initially largely qualitative, even the early steps were probably necessary to build up enough awareness to inspire, support and challenge the next generation. But that’s just rationalizing the fact that I’m probably setting myself up for failure :-).
​
TL;DR
All the talking moved me to a higher position, yet also closer to precipice :-). I definitely need to take some time to process the feedback; I’ll see what comes out of it. The talk was recorded (but of course the unconference discussion wasn’t, so you just missed it). I’ll keep you guys posted when it gets available online. 

Near the end of my presentation at DDD EU, I mentioned that I was working on a precise / useful / paradigm-independent definition for some of the terms we use daily (like abstraction and indirection), based on the notion of entanglement. Later on the same day, the great Jim Coplien observed in his talk that we already have a proper definition of abstraction in the dictionary - selectively remove details (information).

However, I still find that definition almost useless, because it allows us to define everything as an abstraction, which we routinely do. It also allows any removal of information - like shortening every identifier to a single letter - to be classified as abstraction. It’s then a simple step to conclude that abstraction is “evil”.

To be honest, I’m not really interested in investigating the philosophical side of abstraction in software, nor the poetic side. I appreciate both, but I’m looking for a physics of software, and therefore I’m looking for useful definitions.
We use the term “abstraction” in a number of contexts; some are classic CS terms like Abstract Data Type, Abstract Interface, Abstract Interpretation, Abstract State Machine, but most people would also say “introduce an abstraction” when they “introduce a concept”, and so on.
Of course, under the dictionary definition, everything is OK, except that when a giant like David Parnas says “I have not found a relation, "more abstract than," that would allow me to define an abstraction hierarchy” (in his classic paper “Designing Software for Ease of Extension and Contraction”) we should perhaps stop and think on how we define our terminology.

Again at DDD EU, I made the point that we often use a single, broad and therefore ambiguous / imprecise term where many would be needed to provide a precise and useful characterization. This, I think, it’s also the case with “abstraction”. However, before stepping in with my own little contribution, I wanted to cross-check my ideas with a number of sources. Unsurprisingly, that turned out to be a lot of work, but that's probably the difference between trying to approach the problem from a scientific perspective vs. being another guy ranting on the internet.

This is the list of papers / books / etc. that I’ve rounded up. I’ve chosen both classic and obscure papers, some coming from AI and Psychology, but most are CS / IS centric as that’s the target of my work. I’ve mixed theoretical papers with papers dealing with specific usages of the term that I want to harmonize well. I've also included a few informal but popular blog posts, because they (partially) represent how the non-academic side of the world is looking at these notions.
I’ve already been through many of these references, but since some are already attempting to provide a review and a definition, they will necessarily spur more reading. Most will be only marginally relevant in the end, and I will end up citing just a few, but all will provide some angle that I’ll try to account for.

So here is the list; it’s not in a particular order (files in my folder or memos of files to download), and I haven’t provided links for most. Trust me, if you’re not motivated enough to right click and search with google, you don’t want to read them either :-). Some might be available only behind a paywall (mostly ACM/IEEE). Some are listed with more details than others (and no, I do not consider that as “abstraction” :-), it’s just a byproduct of laziness, copy & paste, non-uniform data sources).  If your favorite paper on abstraction is missing, tell me on twitter!

Academic Papers and Technical Reports

• Theories of abstraction, Fausto Giunchiglia, Adolfo Villafiorita, Toby Walsh, AI Communications archive, Volume 10 Issue 3,4, December 1997
• Data Abstraction and Hierarchy, Barbara Liskov
• Behavioral Abstraction is Hiding Information, Grigore Rosu, J. of TCS, Volume 327(1-2), pp 197-221. 2004
• Abstraction and concretizing in information systems and problem domains: Implications for system descriptions, Jens Kaasbøll
• Abstraction Descant, in Patterns of Software,  Richard P. Gabriel
• Information-Based Selection of Abstraction Levels, Stephan Schulz, Proceedings of the Fourteenth International Florida Artificial Intelligence Research Society Conference, AAAI Press, 2001 
• Data abstraction and information hiding, K. Rustan M. Leino Greg Nelson
• Breaking Abstractions and Unstructuring Data Structures, Christian Collberg Clark Thomborson Douglas Low, Department of Computer Science, The University of Auckland
• Types, Abstractions, and Parametric Polymorphism, Part 2, QingMing Ma John C. Reynolds, Proceedings of the 7th International Conference on Mathematical Foundations of Programming Semantics, Springer-Verlag London, UK 1992 
• Abstraction and Approximate Decision Theoretic Planning, Richard Dearden and Craig Boutiliery, Department of Computer Science University of British Columbia
• A Functional Abstraction of Typed Contexts, Olivier Danvy & Andrzej Filinski
• DIKU – Computer Science Department, University of Copenhagen
• Abstracting control, Olivier Danvy    Andrzej Filinski, LFP '90 Proceedings of the 1990 ACM conference on LISP and functional programming
• Information Model: From Abstraction to Application, Jean SCLAVOS - Noëmie SIMONI - Simon ZNATY
• Separation Logic and Abstraction, Matthew Parkinson Gavin Bierman
• Towards Abstract Interpretation for Recovering Design Information, Coen De Roover, Kris Gybels 1, Theo D’Hondt, Programming Technology Lab Vrije Universiteit Brussel
• Abstract Argumentation, ROBERT A. KOWALSKI and FRANCESCA TONI, Department of Computing, Imperial College of Science, Technology and Medicine, London 
• Object-Oriented Programming Versus Abstract Data Types, William R. Cook
• Abstract behavior types: a foundation model for components and their composition, F. Arbab, REPORT SEN-R0305 JULY 31, 2003
• Abstract Information Appliances, METHODOLOGICAL EXERCISES IN CONCEPTUAL DESIGN OF COMPUTATIONAL THINGS, Lars Hallnäs and Johan Redström
• Lazy abstraction, Thomas A. Henzinger, Ranjit Jhala, Rupak Majumdar, Grégoire Sutre, POPL '02 Proceedings of the 29th ACM SIGPLAN-SIGACT symposium on Principles of programming languages
• On Understanding Types,Data Abstraction, and Polymorphism, Luca Cardelli, Peter Wegner
• Quantum information-flow, concretely, abstractly, Bob Coecke, Oxford University Computing Laboratory
• On the proper definition of information, Andras Kornai, ETHICOMP 2008
• Patrick Cousot, Radhia Cousot: "Abstract Interpretation: A Unified Lattice Model for Static Analysis of Programs by Construction or Approximation of Fixpoints", Conference Record of the Fourth ACM Symposium on Principles of Programming Languages, January 1977
• Generating Finite State Machines from Abstract State Machines, Wolfgang Grieskamp, Yuri Gurevich, Wolfram Schulte, Margus Veanes
• Abstraction Based Information Technology, Jacques Calmet, University of Karlsruhe
• Abstraction in perceptual symbol systems, Lawrence W. Barsalou, Department of Psychology, Emory University
• Abstractions and Implementations for Architectural Connections, Mary Shaw, Robert DeLine, Gregory Zelesnik, Computer Science Department Carnegie Mellon University
• Scalable Component Abstractions, Martin Odersky, Matthias Zenger
• On Abstraction and Interpretability: a Behavioural Perspective, Raphael Pfaff, Keith J Burnham, Control Theory and Applications Centre, Coventry University
• A Definition of "Abstraction Level" for Metamodels, Martin Monperrus, Antoine Beugnard, Joël Champeau, DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/ECBS.2009.41
• Making Abstraction Concrete, Bran Selic, DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/WICSA.2011.10
• A Semantic Characterization Of Full Abstraction For Typed Lambda Calculi, K. Mulmuley , Carnegie-Mellon University, DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/SFCS.1984.715926
• The cognitive processes of abstraction and formal inferences, Yingxu Wang , Dept. of Electr. & Comput. Eng., Calgary Univ., DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/COGINF.2005.1532611
• Tutorial: Data Structures, Types, and Abstractions, K. S. Shankar, IEEE Computer 13(4): 67-77 (1980)
• Abstraction Techniques in Modern Programming Languages, M. Shaw, IEEE Software Volume 1 Issue 4, October 1984 
• A Theory of Architecture for Spatial Abstraction, Juyang Weng, DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/DEVLRN.2009.5175545
• Work in progress: Abstraction as a vector: Distinguishing engineering and science, Gregory Bassett , Department of Philosophy Aquinas College Grand Rapids, Michigan, DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/FIE.2012.6462373
• The Influence of the Level of Abstraction on the Evolvability of Conceptual Models of Information Systems, Jan Verelst , University of Antwerp, DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/ISESE.2004.1334890
• System-Level Abstraction Semantics, Daniel D. Gajski Andreas Gerstlauer , University of California, Irvine, DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/ISSS.2002.1227183
• A taxonomy of model abstraction techniques, F.K. Frantz , Computer Sci. Corp., Syracuse, DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/WSC.1995.479055
• Modularization around a suitable abstraction, Stephen N. Zilles, DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/AFIPS.1975.99
• Ubiquitous Abstraction: A New Approach to Mechanized Formal Verification, John Rushby , SRI International, DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/ICFEM.1998.730581
• Lisp: A Language for Stratified Design, Abelson, Harold; Sussman, Gerald Jay
• SOFTWARE ENGINEERING FOUNDATIONS: A SOFTWARE SCIENCE PERSPECTIVE, YINGXU WANG, Auerbach Publications
• Recognizing Design Decisions in Programs, Spencer Rugaber, Stephen Omburn, and Richard J. LeBlanc
• Using Function Abstraction to Understand Program Behavior, Philip A. Hausler, Mark G. Pleszkoch, Richard C. Linger, Alan R. Hevner
• Abstraction and Variation, Diomidis Spinellis ,IEEE Software September/October 2007, DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/MS.2007.127
• Software Evolution based on Formalized Abstraction Hierarchy, Timo Aaltonen, Tommi Mikkonen
• On Abstraction and Interpretability: a Behavioural Perspective, Raphael Pfaff, Keith J Burnham, Control Theory and Applications Centre, Coventry University

Non-academic writings, blog posts, rants

• Abstraction page from Wikipedia
• Indirection Is Not Abstraction
• Abstraction Considered Harmful
• ABSTRACTION VS COMPRESSION

​

Video of my talk "Software Design and the Physics of Software" at #DDDEU is online http://dddeurope.com/2016/carlo-pescio.html (look at the slides, listen to the message, just don't look at the speaker :-)

Overall, I would say my talk at DDDEU was well received, especially considering that it was the first time I tried to talk about the physics of software to a large audience, as opposed to a few like-minded colleagues. 

It was not really easy to choose a reasonable subset to present. I felt I had to provide some background on why this theory is "needed", give at least a simple example of a force, and hint to the fact that there is much more than what I could show in 45m, so something about entanglement had to be there. In the end, I had to sacrifice many details and some amount of precision.

It was only reasonable that someone would call me out for my own lack of precision. While I intended to say something like "I'm using the term 'force' in a broad sense, like any kind of stimulus", in the end I didn't, and someone pointed out that my "forces" were not vectors etc. Which is right, and I don't think they'll ever be. I don't like the term stimulus and I'll keep saying force until I come up with a better term :-).

Another important notion I had no time to explain is that, just like in physics we have different types of friction (static and kinetic, but the whole field of tribology describes many different cases), so in software we have different types of resistance to motion. I described one of those cases (moving part of a function), where we move a portion of code with no identity . Different forces are at play when we move code with identity. Since I could not present the notion of identity in the artifact space, I've discussed only the simplest case.

I also left a few things unexplored, so here are a few pointers:

- I mentioned porting the CAP theorem from the run-time space, where it has been originally defined (the CAP theorem is about the behaviour of software) to the artifact space, that is, to make it about your code itself. I originally discussed that in The CAP Theorem, the Memristor, and the Physics of Software, back in 2011. There would be more to say about the techniques we can use to bring eventual consistency in the artifact space. The Postel Law, for instance, is also hinting in that direction. In fact, many software "principles" and "laws" are encoding heuristics in dealing with tacit forces that my work on the physics of software is trying to make (more) explicit.

- I also mentioned "code that is hard or inconvenient to move". An example of such code is in Notes on Software Design, Chapter 11: Friction in the Artifacts world, which was more about a notion of viscosity than friction, but the two notions are very close and at this stage I'm leaning on unifying them in a single concept.

The talk has been recorded and at some point will be available online. I'll keep you guys posted.