The Physics of Software
an investigation into the true nature of software
  • The idea
  • The story so far
  • Papers
  • Random notes
  • Me

Time in the Physics of Software

6/15/2016

 
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.

From theory to practice to... more practice

6/14/2016

 
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.

Picture

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.

​

Video for my talk "On Growth and Software" at nCrafts Paris 2016

6/12/2016

 
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 :-)
    Some random thoughts that
    I'm not smart enough to keep to myself.


    RSS Feed

    Archives

    September 2019
    February 2018
    July 2016
    June 2016
    May 2016
    April 2016
    February 2016
    January 2016
    August 2015
    November 2014
    October 2014

Powered by Create your own unique website with customizable templates.