[HN Gopher] State and time are the same thing
___________________________________________________________________
State and time are the same thing
Author : BerislavLopac
Score : 41 points
Date : 2024-08-28 12:41 UTC (10 hours ago)
(HTM) web link (buttondown.com)
(TXT) w3m dump (buttondown.com)
| kstenerud wrote:
| 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.
| cma wrote:
| Stuff like Haskell I thought has the most of these kind of
| hidden state changes affecting space and time (e.g. a small
| code change throws off the magic optimizer and now it uses way
| more memory to try and efficiently support that immutability or
| takes exponentially more time).
| mrkeen wrote:
| Nah, but non-Haskellers love telling other non-Haskellers all
| about how Haskell works.
| wredue wrote:
| Jesus.
|
| Guys. State and change are not literally Hitler. Changes to
| state are what computers are made for. You will not write bug
| free programs. Haskell demonstrably does not reduce bugs over
| and above languages that allow direct state changes.
|
| Instead of fostering an environment of being afraid of your
| data. Embrace it. Write the code that needs to be written.
| Accept that bugs will happen (before you slippery slope this, I
| am not saying to write bugs for the sake of it, or to use state
| in unintended ways).
|
| You do not need to be afraid of your state. Join us on the
| light side.
| kstenerud wrote:
| Isn't that what I said?
|
| State is dangerous - it's an entropy multiplier, so keep it
| within reason and for gods sake don't ignore it or pretend it
| doesn't exist.
|
| We like to think that we have it all under control, but the
| time dimension multiplies everything, and has a tendency to
| ratchet them until suddenly you find that you actually don't
| have it under control anymore.
|
| The less state you have, the less your brain gets turned into
| a pretzel trying to keep track of it all over the time
| dimension.
| zerodensity wrote:
| If you care very much about not ever ending up in a bad
| state (which it seems that you do). Then just functional
| programming with immutable state is not going to cut it. In
| this realm you should look into methods of formal
| verification to prove that your code does what you want it
| to do.
|
| That being said, functional verification is a huge time
| sink and is really only economical if it's very important
| for the code to always be correct. That is, people die if
| your software has a bug. A few examples would be
| pacemakers, aircraft autopilots or your car brakes.
|
| If your not working one of these domains then maybe
| immutable and pure functional code can save you a few bugs?
| I have not read any peer reviewed study that shows this is
| the case. But if you have any such paper i would be happy
| to read it.
| tantalor wrote:
| A finger pointing at the moon is not the moon.
|
| The map is not the territory.
| strogonoff wrote:
| Your perception of the moon is not the moon. A map is not the
| territory, but maps is all we have. If a map is useful, then it
| is good.
| KaiserPro wrote:
| 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.
| taeric wrote:
| 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.
| senkora wrote:
| 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.
| IMTDb wrote:
| 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).
| lacy_tinpot wrote:
| Giving a whole new meaning to "what you see is what you get".
| jerf wrote:
| 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.
| 082349872349872 wrote:
| > _" changes in state are time"_
|
| If you go on beyond this to "changes in [the part of] state [in
| this frame] are time", then your specs don't need to make
| allowances for stuttering (a la Lamport).
| slowhadoken wrote:
| They're not the same but you could say that time is a special
| case of statefulness.
| gibsonf1 wrote:
| 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.
| DougN7 wrote:
| I like this definition more. The other way is basically to
| redefine the meaning of the word "time" to something more akin
| to "sequence".
| vehemenz wrote:
| This is a better explanation, but can't the state be measured
| at any time, unchanged or not? The measurable attribute could
| always be in flux, for example.
| BigParm wrote:
| OP should have said that change in state = time.
|
| Anyone who has worked on secure consensus has had the same
| thought. You can't derive time from pure math. You must observe
| some state change.
|
| It's a useful concept, but strictly speaking it's not true. If
| this universe was completely devoid of matter, time would still
| pass. "If a tree falls in the woods and nobody is around to
| hear it, does it make a sound?"
| nickdrozd wrote:
| 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...
| FrustratedMonky wrote:
| And this is good example for larger discussions in physics.
|
| Time does not exist at all, the Universe is itself just
| changing from one State to the Next State. There is no Time
| Dimension at all.
| zackmorris wrote:
| 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.
| sdenton4 wrote:
| Are you proposing functional programming? There's plenty of
| examples of languages going that route (including languages
| with varying levels of compromise on 'pure' functionality for
| performance).
| phkahler wrote:
| 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.
| lilyball wrote:
| This is reminding me of Functional Reactive Programming all those
| years ago
| rhelz wrote:
| Maybe change of state is the same thing as time?
| jmull wrote:
| 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.)
| yawnxyz wrote:
| 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)
___________________________________________________________________
(page generated 2024-08-28 23:01 UTC)