Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
Programming

'Can a Programming Language Implement Time Travel?' (stackoverflow.blog) 89

Posted by EditorDavid from the back-to-the-future dept.
Stack Overflow's blog reports on a new programming language called Mariposa.

They call it a "toy" programming language, "created as a way to play around with a novel or odd feature, like variable assignment outside of the normal order of execution — more colloquially, time travel." Computer science has long sought to reason about time in electronic systems, thanks to a consistent interest in concurrency and real-time messaging... Mariposa allows you to manipulate the order of execution by assigning an instant to a variable, then setting the context of that instance. Here's a basic example, taken from the Mariposa readme:

x = 1
t = now()
print(x)
at t:
x = 2

According to the normal order of operations, this code should print "1". But because t is assigned to the instance in the second line, any modifications specified within an at t: block are applied immediately, and this code prints "2"...

While Mariposa caught a fair amount of attention recently, it's not the first implementation of time travel in programming. There is a Haskell package appropriately called tardis, which creates two state transformers: one travels forward in time and one backward. As the docs explain, "The most concise way to explain it is this: getPast retrieves the value from the latest sendFuture, while getFuture retrieves the value from the next sendPast." One function's past is another one's future.
The article explores "the history and future of other programming paradigms" applying logic to time, including interval temporal logic systems as well as "modeling, analysis, and verification languages/tools that allow temporal and state modeling without requiring temporal logic understanding."
This discussion has been archived. No new comments can be posted.

'Can a Programming Language Implement Time Travel?' More

'Can a Programming Language Implement Time Travel?'

Comments Filter:

  • This is just a fancy way of bloating memory usage (Score:3)

    by RedK ( 112790 ) on Saturday February 24, 2024 @12:42PM (#64265512)

    With multiple tagged instances of a variable. Instead of a clean 64 bit int, now your "int" is a hashtable.

    This isn't time travel.

  • if speed=88MPH then enable unit.fluxcapacitor

  • Seriously? (Score:3)

    by backslashdot ( 95548 ) on Saturday February 24, 2024 @01:03PM (#64265540)

    This should be fun to debug. Are they trying to increase programmer suicides or something?

    • Just what I was thinking. This sort of paradigm would make BASIC "goto" sphagehetti code seem like something Knuth would be proud of.

      • Don't bash on Basic. Besides the nostalgia c64 Basic invokes in me, it was rather okay as a language, not much worse than another procedural language.

        But GOTO: c have it and even though I hardly ever use it, it is there and it has its own specific use cases, like exiting a loop and do something specific* for that case that can happen multiple times in that loop. Sure, it's an ugly hack, useful nonetheless, and should never be recommended to use.

        * like unlocking mutexes, and "break" might not exit the loop b

  • Novel or odd feature? (Score:3)

    by SchroedingersCat ( 583063 ) on Saturday February 24, 2024 @01:03PM (#64265544)
    "created as a way to play around with a novel or odd feature, like variable assignment outside of the normal order of execution" - obviously, someone never dealt with C++ static initialization.

    • There are a lot of younger people out there (especially in the blog-o-verse) who have messed around with python for a few years and think that's made them coding experts. When they learn something new, they assume it's novel for everyone.

      • Removed the semi colons and curly braces?

        Well right! It used to be you couldn't do a code review without confusing the control flow over some curly braces that weren't indented properly.

        The libraries?

        Right again. I don't know how we ever got anything done without the libraries.

        The Legions of inexperienced coders?

        Well, everyone know you can drive costs down by hiring coders at low wages. That goes without saying.

    • Re: (Score:2)

      by kmoser ( 1469707 )
      In other words, asynchronously. So, yeah, not new.

  • Race conditions as a features? (Score:3)

    by Anubis IV ( 1279820 ) on Saturday February 24, 2024 @01:08PM (#64265550)

    I mean, to each their own, and I’m all for playful languages, but why the coverage on this? They’ve made a class of bugs a first class feature.

    • Every programming language ever created has a grammar policy that causes x to be one or the other or the next. There is usually a rule or intermediary function to stop this. But yea, your linker and compiler is having fun with it's version of x over time....

    • Fatal error: temporal decoherence: User has never been born. Quit to press any key.

  • INTERCAL? (Score:5, Interesting)

    by The1stImmortal ( 1990110 ) on Saturday February 24, 2024 @01:18PM (#64265564)
    This looks almost like a more serious implementation of INTERCAL's COME FROM or the CLC-INTERCAL extension of NEXT FROM/RESUME. A reverse goto/return elsewhere that triggers on a line which has no obvious indication that it triggers anything.

  • Is this not just a hard to debug method of creating a function for x=2?

  • How is this useful or interesting? This seems both stupid and a waste of time in both developing and "playing" with it.

    • I've seen applications where it was important to be able to know what conditions existed at a particular time in the past - forensics for example or retrospective billing. Generally the application is quite specific about only needing to retain a subset of the data, but it may become more important as we try to trace what AI knew and when as it formulated its output.

      • Re: (Score:2)

        by Bahbus ( 1180627 )

        Ok. But that doesn't mean someone should create an inherently terrible programming language. A new programming language isn't needed to accomplish these tasks. I'm not even sure it would necessarily be good at doing any of that.

        • Re: (Score:2)

          by PPH ( 736903 )

          But that doesn't mean someone should create an inherently terrible programming language.

          I felt a great disturbance in the Force, as if millions of CS graduate students voices cried out in terror and were suddenly silenced.

      • You can very easily know that, you record it with a time tag, then look up the record when necessary. Any common language can do that very easily.

      • I've seen applications where it was important to be able to know what conditions existed at a particular time in the past ...

        In future news: Republicans ban programming language. :-)

    • If we can simulate it can we build it, or did the universe already?

    • Yes, you could easily make these sorts of mistakes in any other programming language. This seems like someone fiddling around with ancient bugs, but they have so little knowledge of the topic that they think they are new.

  • In the given context, the right term is "stupid".

    • Hey, anything can implement time travel... for sufficiently loose definitions of "time travel".

      • Luckily you are the "Futurama quotes" person so it is funnier.
        A "sufficient definition of time travel" could be that the language can only affect future variables, i.e. go forward in time. But time is a loop so it can affect variables in previous executions of the ".exe" or whatever.
        That must have been in the last season why the characters did that.

  • function == timeless (Score:3)

    by wormbin ( 537051 ) on Saturday February 24, 2024 @02:08PM (#64265638)

    Whenever I do imperative programming I'm always conscious of time. Each statement may change state and I'm aware of how that can affect the system. I'm very aware of "time".

    When I do functional programming (like Scala) I feel like I'm writing mathematical statements that aren't causing actions but just stating truths. It feels like time doesn't exist.

    I know it's just a feeling and under the hood there's still a Von Neumann engine chugging away, but it's a feeling I can't seem to shake.

    • Re: (Score:2)

      by wormbin ( 537051 )
      whoops. I meant "functional == timeless"

    • Functional programming is just a fancy name for polymorphism-by-value and recursion as a first class construct. It makes a small number of simple algorithms easier to implement at the expense of making all the others a damn site harder.

  • I tried making an infinite loop by reading data from the future, but the compiler wouldn't let me. "Assignment would lead to time paradox."

  • A better alternative (Score:2, Interesting)

    by reanjr ( 588767 )

    I've been working on a language where there is a focus on immutability. In this language, "variable" (actually constants) assignments can come anywhere in the scope. The compiler figures out the dependency graph for each line of code and orders them accordingly.

    A better refined, and more useful approach IMO.

  • Why only inside an at block? Let the compiler search the entire codebase for any possible change to x.

    Better yet, let it do a quantum search for past and future changes in the codebase. Now we're talking about real time travel.
    And a compiler with a severe case of burnout.

  • I guess this give a whole new meaning to realtime debugging. I think this language will be going on my avoid list.
  • Bobby Tables has come unstuck in time

  • The example in TFS seems more like using snapshots with variable values.

  • You could do this in Fortran. The computer still has to read all of the instructions and then execute, there is no time travel. It's just like giving someone bad instructions and saying oh yeah in between the 3rd and 4fth step, you're supposed to do x...

  • ... implement a time travel routine using this language to go back and convince Lennart Poettering to major in art history?

  • Not time travel, just bog-standard asynchronous programming. When dealing with async constructs, or even just callbacks, the order instructions appear when printed is not the order of execution. Any competent software engineer ought to grok that.

    If you want a brain-bender, look up Intercal's computed COME FROM construct and ponder the fact that someone actually worked out how to implement this elder horror.

    • Re: (Score:2)

      by drnb ( 2434720 )

      Not time travel, just bog-standard asynchronous programming. When dealing with async constructs, or even just callbacks, the order instructions appear when printed is not the order of execution. Any competent software engineer ought to grok that.

      In short it's a thread unsafe call in a thread environment. 'print' running in a separate thread than 'x'. A parameter pass by reference rather than pass by value.

      I suppose a thread being able to block itself until print completion would have worked.

      • It happens in a single-thread environment too. After the assignment "t = now()" completes, the "at t:" trigger causes control to transfer there and the assignment "x = 2" executes. Control then returns to where it was before the trigger and the print statement outputs the current value of x. One thread, no simultaneous execution, just the trigger code executing when the trigger is satisfied rather than when it's declared.

  • SQL Server has something like this, called "temporal tables." With these tables, it's possible to query the values of records in that table as they were at a specified time.

    I'm not sure what this language does that has a practical use, but maybe there's something I'm missing.

  • Time travel in the sense of a bootstrap paradox (the classic example being, I go back in time and Bach hears my iPod playing BWV-565 and writes it down, now where did the Toccata & Fugue in D Minor come from?) is not actually paradoxical and, at the quantum level, this sort of self-consistent time travel occurs infinitely often. A prototypical example is the photon's self-interaction via an electron loop: A virtual electron going back in time (a positron) hits the photon and gets turned into an electron

  • If the microprocessor cannot natively do a thing, then no programming language (which is, itself, just a blob of code) can do that thing with that processor.

    What we have here is a poorly designed and implemented toy computer language. That's it. Nothing more, and not actually article-worthy.

  • other than creating impossible-to-find bugs

  • t = now()
    print(t)
    at t:
    t = 2

  • Check out the Lucid programming language:

    https://en.wikipedia.org/wiki/... [wikipedia.org]

    It made the time sequence of each variable explicit. It also treated time as multidimensional, with nested time lines corresponding to nesting levels of loops in a more conventional language. It didn't catch on, but it's a good example to stimulate thinking about alternative views of programming.

  • x = 1
    goto t;
    back:
    print(x)
    t:
    x = 2
    goto back;

  • No, this is just perfectly logical.

    I really cant see how anyone would think this is time travel, it just another way of altering the flow of a program. If it were tim travel the I'd expect X to still be set to 1 after 2 was printed, but thats not the case as X was 1 when t was set, but a code block that sets X to 2 is to be extecuted at time t. T being now() makes that code block execute when t is set, which sets X to 2 (totally logical so far) and RETURNS EXECUTION to the line before the block executed a

Slashdot Top Deals

Brain fried -- Core dumped

Close