State and time are the same thing

For anyone who finds this sort of discussion interesting, I highly recommend reading Chapter 3 of The Structure and Interpretation of Computer Programs. There is quite a bit of philosophical musing about the connection between time and state. For example:

> The basic phenomenon here is that synchronizing different processes, establishing shared state, or imposing an order on events requires communication among the processes. In essence, any notion of time in concurrency control must be intimately tied to communication. It is intriguing that a similar connection between time and communication also arises in the Theory of Relativity, where the speed of light (the fastest signal that can be used to synchronize events) is a fundamental constant relating time and space. The complexities we encounter in dealing with time and state in our computational models may in fact mirror a fundamental complexity of the physical universe.

https://mitp-content-server.mit.edu/books/content/sectbyfn/b...

State changes that are internal to a function and not visible are sometimes called "benign effects" in functional programming. A function can be considered "pure" if it has only benign effects, which is a relaxation on the stricter requirement that a pure function have no (side) effects at all.

This is a dangerous way to think about it. State and time are different things, and if you think of them as the same, then your mental model glosses over some parts of reality that will become important as your software grows more complex.

State is inherently dangerous BECAUSE a program runs TEMPORALLY. As the number of state changes increases, the dangers of an unwanted state increase (particularly insidious are the state combinations you thought weren't even possible). This is why functional programmers favor immutability and idempotent functions.

Also: Just because the EXTERNAL observability of state hasn't changed is no reason to assume that no state changes have occurred. Hidden state changes are the most dangerous of all.

For the room, yes, state and time happen to be the same thing.

However for a lot of systems thats not the case. Worrying about hidden state is the enemy of joy.

Sure, if you are doing shared things, or exposing the internals of something to the world, then yes, you need to be paranoid. But, marshalling things so that state is in a known and guarded place is a much better way to think about things.

State is basically the computer science version of an egg drop. There are many ways to make it work, some more complex than others. but worrying about sudden cross winds[0] isn't the way to make sure your egg doesn't shatter when it hits the floor.

[0] unless your arena has active cross winds of substance.

I'd argue that the way we define "state" as being "a set of things that matter to us". In the context of the article, if we define state as being a "state vector of (hours, minutes, seconds)" we explicitly exclude everything but these three value (miliseconds, date, etc). The two pictures with the hands pointing to the same umber then by definition are the same. We can even consider them as being the same "every 24 hour".

The distinction between single threaded or multi threaded is moot; the world is in perpetual mutation anyway; even is two lines of code are being executed at exactly the same time in a multithreaded fashion, one is executed on CPU A and one on CPU B so their "environment" is different and there will never be two lines of code that are executed in exactly the same environment - regardless of what tools and techniques you use to try and enforce reproducibility.

What matters is to explicitly define what you consider as having an impact (which you add in the "state") and what you don't (which you leave out).

A finger pointing at the moon is not the moon.

The map is not the territory.

It might be better to say "changes in state are time".

This is a deeper understanding of what time is than the common one we have... but... since "the common one we have" is the result of living in a universe that is absolutely constantly pounding state changes into us every Planck-time of our lives, and I don't know about you but I'm not building anything that I expect to exist in some sort of ontologically different state, you can do rather a lot of work with the "intuitive" concept of time. Even complicated server communications which are fast enough that the fact that relativity bans "simultaneous" becomes relevant can be understood just fine in an intuitive framework.

I do find it helpful to conceive of time as "state changes occurring" for a particular case, though, which is multithreaded programming. It is helpful to conceive of threads as "perceiving" time not as ticks on a clock, but changes in the state (which can be to a first approximation be 'lines of code executed'). From this point of view, threads do not experience time as a clock ticking onward, but as "a particular value that exists but only when they look". That is to say, if a thread "consults the clock" and determines that it is noon on Jan 1st, it can be helpful as a programmer to understand that that does not particularly mean that three lines later, it will be noon on Jan 1st. Arbitrary amounts of universe-time can progress between any two lines of code. Threads really relate to each other not across universe-clock time, but by what observable effects other threads cause on them, and only on what observable effects other threads have on them. In principle, two threads that cause no effects visible to the other are essentially running in different universes. This is a place that a mathematical mindset can really help.

But, again, this is just a sort of helpful thing for relatively advanced mental modeling, but you can get a long way just based on assuming a monotonic universe-clock.

This is why I assert, with some vigor but without much persistence (since it's obviously a massively uphill battle), that a clock-simulating library really should not be based on assuming threads will witness a monotonic universe clock, and a clock-simulating library ought to make it possible to test that a task nominally scheduled to come after some other task actually runs to completion before the first task even starts, because that can happen in the real world. In an imperative language, you can assume that one statement within a thread will follow another, and that the external threads you can see are also operating in that order, but the slip between those "ticks" can be arbitrarily large.

I realized this around 2016 while working in PHP/Laravel and realizing that mutation=state=time.

I use higher-order methods like map/reduce/filter now, storing temporary results in variables when needed (although PHP's lack of const variables is a travesty). PHP's functional model of receiving data, transmuting it with the help of copy-on-write arrays, and returning it with a possible side effect stored in a database, all in an independent process, is one of the best around IMHO. It's too bad that legacy mistakes/features in the language and performance inefficiencies in operating system multiprocessing implementations (Windows, cough) obfuscate how powerful this model is.

Most/all of the complexity in debugging comes from mutation and side effects. Unfortunately nearly every language gets this wrong. Python has a huge emphasis on mutating variables rather than returning values that can be piped to the next function. Rust goes to great lengths with its borrow checker to allow mutation when copy-on-write would negate most of the need for that. I'd like to see a language and even an operating system that piped data around rather than mutating it in place, with an accepted cost of taking about twice as much memory to accomplish it. Then code could be mapped directly to spreadsheet form, and code execution could be mapped to diffs between state transitions to provide rewind functionality and debugging for free.

I would love to work on a paradigm like this if I had any spare money and time at all to do it. I've waited since the 90s for what I consider basic features, but sadly almost no language got this stuff right in the time since. Which leaves me with the unfortunate impression that probably 90% of the work we do in programming is a waste of time. Imagine if that wasted effort had gone towards solving foundational problems in programming for the benefit of all, instead of internet lottery winners just rolling their profits into their next venture.

I think a more useful way to put it is:

State is a value in a system that may change over time.

I would like to add “… that can be accessed from more than one scope”, but that doesn’t quite match common usage of the term so might just cause confusion.

The distinction is useful, though, because values that change over time but only exist in one scope are easy to reason about and handle correctly, while ones shared across scopes can cause no end of problems if not well organized. Maybe we can use terms something like “trivial state” and “significant state”.

(And, yes, we’d also need to define “scope”. I think the intuitive/common meaning is enough to get the point across though.)

I know it's about programming, but I have a thought experiment I think about occasionally. Imagine a universe with one point particle. There's no time or space. Add another particle. The particles can either be separate or at the same point. So in some sense there is time, since we can go between separate and together states. There still isn't space, I think? Is this a philosophical subject I can read about?

Actually, a state is when a measurable attribute of an object remains unchanged for a period of time. So saying state = time completely misses what a state is.

I think this is a useful way to model a simulation. Probably a good way to reason about bugs and how a program works.

However, I question if you want to try and embrace this on anything that takes on user input. It would be one thing if we had temporal logic based programming models. But I don't know if any program that does.

I think about it this way:

A state is an identifier for a sequence of "atomically" changing values.

By "atomically" I mean before/after an event is handled end-to-end.

Completely disagree with the title. A system - especially software - can return to the same state at a later time. It makes no sense to conflate the two. It's telling that the author deliberately starts with a clock as an example - something whose state is supposed to reflect time.

The main point seems to be one about hidden state or unobservable internal state, and I'm all in favor of having that. One of my preferred ways to make software subsystems (particularly in embedded devices) is to use a state machine. To the outside software there may be only a handful of visible states - NOT_READY, READY, MODE1, MODE2, MODE3, FAULTED. But internally there may be any number of intermediate states - several startup states hidden behind NOT_READY, several transitional steps in mode changes, etc. When switching modes I prefer to report the old mode until a transition is complete and then show the new mode as the current state to the outside world. IMHO you don't want to report "in transition" or anything like that, the outside may need to tolerate some time going by before getting what it wants, but it's not needed to know what's happening internally. You either get there or fault. The simplification from what's happening to what's reported is important to reduce the spread of complexity.

They’re not the same but you could say that time is a special case of statefulness.

Are they saying I just need to let the universe reach the desired state I want it in as a totally deterministic universe,then merely record that timestamp?

To read my data, I wait for the gnab gib to restart the phone universe?

from having built a bunch of tiny indie games in a prior life (in Flash :P), time = state, and time = world

and depending on what games we're building, either we record actions as state changes (eg chess / turn based games: if no moves are made, time didn't elapse), or "real-time" games (eg chess w/ a world state like a clock)

This is reminding me of Functional Reactive Programming all those years ago

Maybe change of state is the same thing as time?