Programming a Time Machine

Programming a Time Machine

An overview of the Timeline programming language with some backstory on how time travel works, along with thoughts about how to design a programming language and write clear code.

F74253f4a099258870157426b4cdb2dc?s=128

David Copeland

June 08, 2019
Tweet

Transcript

  1. PROGRAMMING A TIME MACHINE WITH AN EVENT-BASED LANGUAGE THAT USES

    RISK-BASED TESTING DAVE COPELAND • @davetron5000
  2. OUR GOALS • Intro to time travel using the Timeline

    Programming Language • Understand Timeline's design decisions so you can apply them: • To your API or Library Designs • To your own programming languages • To the way you approach developer or user experience
  3. TIMELINE BASICS • An event-based programming language to program a

    one-time flight plan for a specific journey • Eschews unit tests for a risk-assessment based on Monte Carlo simulations • An extreme focus on observability - what will the program do? what did the program do?
  4. HELLO TIMELINE on vortex established [] { send disconnect []

    now }
  5. WHAT PROBLEM DOES TIMELINE SOLVE?

  6. REMEDIAL TEMPORAL MECHANICS HOW DOES TIME TRAVEL WORK?

  7. TIME TRAVEL IS SPACE TRAVEL NOW THEN

  8. DRS NEIL BELL & CHRIS CLARKE • 10 years validating

    the approach • 5 more to make it practicable • Dr. Bell focused on hardware • Dr. Clarke on firmware & software • Result is the Time Space Manifold (TSM)
  9. THE PROBLEM

  10. TRAVEL HAPPENS THROUGH A VORTEX THAT INTERSECTS SPACE

  11. THE PROBLEM SPACE HAS A LOT OF STUFF IN IT

  12. AND IT COULD BE IN OUR WAY

  13. THE PROBLEM AND HITTING IT WOULD BE BAD

  14. AND…THE TRIP IS JUST MILLI- SECONDS

  15. DR. CLARKE'S FIRST SOLUTION A GENERAL PURPOSE AUTOMATED PILOT

  16. ONE PROBLEM THE 2043 BAN ON NEURAL NETWORKS AND MACHINE

    LEARNING "Flags and offices" by 4nitsirk is licensed under CC BY-SA 2.0
  17. BUT REAFFIRMS THE REASON FOR THE BAN THE FIRST WAIVER

    IS GRANTED • A generalized pilot was created based on vast training data about our universe • First flight was a success, however the second was disasterous • Machine Learning algorithms are inherently incomprehensible and unpredictable • Impossible to explain the behavior observed • And therefore impossible to predict
  18. FORGET THE GENERAL AND FOCUS ON THE SPECIFIC - SOLVE

    THE PROBLEM IN FRONT OF US EACH TIME
  19. CONSEQUENCES • Instead of a general pilot, write a flight

    plan for each flight • Use a language that makes it obvious how the system will behave when flight happens • Use simulation instead of specification to understand the risks with a given flight plan • Produce comprehensive output about what actually happened.
  20. — Timeline's Core Value THE MOST IMPORTANT THING ABOUT A

    PROGRAM IS WHAT IT WILL DO. THE SECOND IS WHAT IT DID. ” “
  21. SUCCESS! 100 YEAR BOTTLE AGED RUM FIRST FLIGHT WITH A

    SINGULAR FLIGHT PLAN
  22. HELLO (AGAIN) TIMELINE on vortex established [] { send disconnect

    [] now } ALL CODE IS IN RESPONSE TO AN EVENT NO RETURN VALUES OR I/O - YOU CAN ONLY SEND EVENTS
  23. LET'S TRY IT > timeline plan.timeline Success..............98.00% Failure..............02.00% Hardware failure..........02.00%

    Failed connection..............01.23% Disconnect failed..............00.77% Seed: 98798798743 98% CHANCE EVERYTHING WORKS AS EXPECTED FUNNY STORY
  24. TESTING IN PRODUCTION 5 minutes ago disconnect failed office chair

  25. TO THE MOON AS OF LAST MONTH A REAL TRIP

  26. CHARTING A COURSE • A destination in space • A

    length of time to go back • The size and mass of what is traveling
  27. INTERNATIONAL CELESTIAL REFERENCE FRAME

  28. INTERGALACTIC CELESTIAL REFERENCE FRAME

  29. REMEMBER, THERE IS NO I/O—ONLY EVENTS on start [] {

    send trip details [ destination:[ ascension:60º23'42" declination:75º02'12" distance:384,402km duration:1,296,000s ] traveler:[ weight:90kg dimensions: [ width:1m height:2m depth:0.3m ] ] ] now } ICRF COORDINATE HOW FAR BACK CUBE THAT COMPLETELY ENCLOSES THE TRAVELER STANDARD LIBRARY - TRIGGERS THE VORTEX
  30. OK, WHAT IS GOING ON? HOW IS THAT A PROGRAM?

  31. on start [] { } KEYWORD EVENT NAME PARAMS LIST

    (THIS ONE IS BLANK)
  32. send trip details [ destination:[ … ] traveler:[ … ]

    ] now KEYWORD EVENT NAME WHEN TO TRIGGER THE EVENT PARAMS TO THE EVENT - NAMED
  33. destination:[ ascension:60º23'42" declination:75º02'12" distance:384,402km duration:1,296,000s ] BRACKETS ARE A CONSTRUCTOR

    THESE ARE TYPED LITERALS type Destination [ ascension:Angle declination:Angle distance:Distance duration:Time ]
  34. OK, BUT WHY IS IT LIKE THAT?

  35. LANGUAGE CHOICES send trip details [ destination:[ … ] traveler:[

    … ] ] now send disconnect [] now ALWAYS USE BRACKETS - CONSISTENCY ALWAYS USE BRACKETS - CONSISTENCY ALSO, THEY ARE EASIER TO TYPE THAN PARENS NO NEED FOR QUOTES - IT'S OBVIOUS WHAT THE EVENT NAMES ARE
  36. LANGUAGE CHOICES destination:[ ascension:60º23'42" declination:75º02'12" distance:384,402km duration:1,296,000s ] LITERALS ARE

    TRUE LITERALS, NOT NUMBERS WE ASCRIBE MEANING TO - NO AMBIGUITY LARGE VALUES ARE EASY TO MISTYPE, SO WE REQUIRE COMMAS - THIS CODE IS FOR HUMANS 60º 23' 42" 1,296,000 S
  37. NOT "TDD" BUT "RDD" - RISK DRIVEN DEVELOPMENT WORKFLOW 1.

    Provide plan details 2. Simulate the plan 3. Assess the risk of failure 4. Add code only to reduce risk 5. When risk is acceptable - Go!
  38. LET'S SIMULATE OUR PLAN > timeline plan.timeline Success..............00.00% Failure.............100.00% Hardware

    failure..........01.23% Failed connection..............01.23% Large Object Collision....98.77% Known Object Collision..........90.45% unknown Object Collision........08.32%
  39. WHAT ARE WE COLLIDING WITH? > timeline -seed 98798798743 \

    --details="Known Object Collision" \ plan.timeline Success..............00.00% Failure.............100.00% Hardware failure..........01.23% Failed connection..............01.23% Large Object Collision....98.77% Known Object Collision..........90.45% Satellite 4F76......................90.45% collision at 86ms unknown Object Collision........08.32% 86MS INTO OUR JOURNEY, WE HIT A SATELLITE
  40. None
  41. None
  42. CONSULT THE STANDARD LIBRARY // Triggered when traveler enters the

    // vortex to start the trip on traveler entered [] {} // Trigger a change in the vortex heading send adjust vortex direction [ // angle relative to our // current heading direction:Angle ]
  43. 80MS IN, WE ADJUST TO AVOID THE SATELLITE ALLOW 35MS

    TO PASS IT, THEN ADJUST BACK
  44. SOME REAL CODE on traveler entered [] { direction is

    45º send adjust vortex direction [ direction:direction ] in 80ms reverse-direction is 360º - direction send adjust vortex direction [ direction:reverse-direction ] in 115ms }
  45. SOME REAL CODE on traveler entered [] { direction is

    45º send adjust vortex direction [ direction:direction ] in 80ms reverse-direction is 360º - direction send adjust vortex direction [ direction:reverse-direction ] in 115ms } "=" IS AMBIGUOUS, SO INSTEAD BE VERY CLEAR SINCE "-" IS DEFINED ON ANGLES, THE RESULT IS AN ANGLE DASHES ARE EASY TO TYPE AND EASY TO READ
  46. YOU CANNOT INLINE EXPRESSIONS on traveler entered [] { direction

    is 45º send adjust vortex direction [ direction:direction ] in 80ms send adjust vortex direction [ direction:360º - direction ] in 115ms
  47. YOU CANNOT INLINE EXPRESSIONS on traveler entered [] { direction

    is 45º send adjust vortex direction [ direction:direction ] in 80ms send adjust vortex direction [ direction:360º - direction ~~~~~~~~~~~~~~~~ \-- must be literal or variable ] in 115ms INLINING INCREASES DENSITY, WHICH REDUCES COMPREHENSIBILITY THIS ALSO FORCES ALL EXPRESSIONS TO HAVE NAMES
  48. VARIABLE NAMES MUST BE DEFINED WORDS on traveler entered []

    { direction is 45º send adjust vortex direction [ direction:direction ] in 80ms rev-direction is 360º - direction send adjust vortex direction [ direction:rev-direction
  49. VARIABLE NAMES MUST BE DEFINED WORDS on traveler entered []

    { direction is 45º send adjust vortex direction [ direction:direction ] in 80ms rev-direction is 360º - direction ~~~~~~~~~~~~~ \-- “rev” is not a word send adjust vortex direction [ direction:rev-direction ABBREVIATIONS OR NON- WORDS HURT COMPREHENSION. ALL VARIABLES MUST BE COMPRISED OF DEFINED WORDS YOU CAN ADD NEW WORDS TO THE DICTIONARY, BUT MUST DEFINE THEM
  50. HOW'S OUR PLAN LOOK NOW? > timeline plan.timeline Success..............62.00% Failure..............38.00%

    Hardware failure..........02.23% Failed connection..............01.23% Failed midstream...............01.00% Small Object Collision....34.70% Large Object Collision....01.07% SPACE IS FILLED WITH LOTS OF STUFF WE DON'T TRACK
  51. WE DON'T KNOW THE SIZE, SHAPE, OR POSITION OF THIS

    OBJECT
  52. WE CAN SEND A "PING" TO SEE WHAT'S AHEAD OF

    US
  53. IF SOMETHING'S THERE, WE'LL GET TELEMETRY BACK

  54. STANDARD LIBRARY AGAIN // ask for telemetry send ping []

    // When a ping detects an object ahead on collision imminent [ // How many ms ahead of us? distance:Time // Angle inside vortex position:Angle // cube that encompasses // the object's intersection dimensions:Dimension ]
  55. SEND A PING ONCE WE ENTER on traveler entered []

    { «previous code» send ping [] now }
  56. RESPOND TO THE IMMINENT COLLISION on collision imminent [ distance:

    position: dimensions: ] { «???» }
  57. None
  58. VIEW STRAIGHT AHEAD INSIDE THE VORTEX OBJECT DETECTED BY PING

    ANGLE OF WHERE IT INTERSECTS
  59. WE NEED TO MOVE OPPOSITE OF THE ANGLE OF INTERSECTION

  60. MOVING BY JUST ENOUGH TO AVOID COLLISION

  61. None
  62. IF THE OBJECT IS TOO CLOSE, THERE'S NO TIME TO

    REACT
  63. STANDARD LIBRARY YET AGAIN // Adjust our speed through the

    vortex send adjust vortex speed [ speed: Percent ]
  64. COMPLEX LOGIC 1. If the object is too close, slow

    down 2. Avoid the object 3. Correct our course 4. If we had to slow down, speed back up
  65. SAME ALGORITHM, MORE GENERAL adjustment is distance - 2ms adjustment-back

    is adjustment + 4ms direction is 180º + position « SLOWDOWN LOGIC TBD » send adjust vortex direction [ direction:direction ] in adjustment send adjust vortex direction [ direction:direction ] in adjustment-back send ping [] in adjustment-back
  66. SLOWING DOWN too-close? = distance < 10ms if too-close? {

    speed-adjustment is 90% speed-adjustment-back is 110% object-distance-after-speed-adjustment is speed-adjustment-back x distance adjustment is now 1ms adjustment-back is now object-distance-after-speed-adjustment + 5ms send adjust vortex speed [ speed:speed-adjustment ] now send adjust vortex speed [ speed:speed-adjustment-back ] in adjustment-back } else { do nothing } BOOLEANS ARE SPECIAL, SO THEY MUST END IN A "?" REASSIGNMENT IS ERROR- PRONE, SO MUST BE DONE EXPLICITLY BOTH CASES OF AN IF MUST BE HANDLED EXPLICITLY
  67. INLINE EXPRESSIONS IN CONTROL STATEMENTS? too-close? = distance < 10ms

    if distance < 10ms { speed-adjustment is 90% speed-adjustment-back is 110% « etc »
  68. ALL EXPRESSIONS MUST BE NAMED too-close? = distance < 10ms

    if distance < 10ms { ~~~~~~~~~~~~~~~ \--- must be literal or variable speed-adjustment is 90% speed-adjustment-back is 110% « etc » ALL EXPRESSIONS MUST BE NAMED, EVEN IN CONTROL STRUCTURES
  69. COMPOUND EXPRESSIONS object-distance-after-speed-adjustment is speed-adjustment-back x distance adjustment is now

    1ms adjustment-back is now 110% x distance + 5ms
  70. COMPOUND EXPRESSIONS - NOT ALLOWED object-distance-after-speed-adjustment is speed-adjustment-back x distance

    adjustment is now 1ms adjustment-back is now 110% x distance + 5ms ~~~~~~~~~~~~~~~~~~~ \--- All expressions must be named COMPOUND EXPRESSIONS INCREASE DENSITY
  71. HOW ABOUT NOW? > timeline plan.timeline Success..............95.00% Failure..............05.00% Hardware failure..........02.23%

    Failed connection..............01.23% Failed midstream...............01.00% Small Object Collision....01.70% Large Object Collision....01.07% 95% CHANCE SUCCESS + 1.23% CHANCE WE CAN'T CONNECT = 96.23% CHANCE OF NOT DYING 95% CHANCE SUCCESS + 1.23% CHANCE WE CAN'T CONNECT = 96.23% CHANCE OF NOT DYING CAN'T FIX THIS
  72. THE LAST 2.77% • Handling more edge cases requires a

    lot of complexity • Unit Tests could let us drive that • Early versions of Timeline supported unit testing… • …but it allowed the creation of complex code whose behavior could not be understood or explained • Instead, we focused on observability
  73. WHAT HAPPENS IN A FAILURE? > timeline plan.timeline \ --black-box-for="Small

    Object Collision" Success..............95.00% Failure..............05.00% Hardware failure..........02.23% Failed connection..............01.23% Failed midstream...............01.00% Small Object Collision....01.70% Large Object Collision....01.07% Black Box in: small-object-collision.blackbox
  74. THE BLACK BOX IS…DETAILED Time Trip Time Type Event Source

    Params 0 0 Trigger start TSM [] 1 0 Handle start plan.timeline:1 [] 2 0 Trigger trip details plan.timeline:2 [ … ] 3 0 Handle trip details TSM [] 5 0 Trigger vortex established TSM [] 6 0 Handle vortex established plan.timeline:5 [] 10 0 Trigger traveler entered TSM [] 11 0 Handle traveler entered plan.timeline:8 []
  75. THE BLACK BOX IS…DETAILED Time Trip Time Type Event Source

    Params 13 2 Schedule adjust vortex direction plan.timeline:10 [ direction: 45º ] 14 2 Schedule adjust vortex direction plan.timeline:14 [ direction: 315º ] … … … … … … 90 80 Trigger adjust vortex direction TSM [ direction: 45º ] 125 115 Trigger adjust vortex direction TSM [ direction: 315º ]
  76. THE BLACK BOX IS…DETAILED Time Trip Time Type Event Source

    Params 125 115 Trigger adjust vortex direction TSM [ direction: 315º ] 127 117 Trigger vortex adjusted TSM [] 128 118 Trigger collision TSM [ … ] WE ADJUSTED RIGHT INTO SPACE JUNK :(
  77. NEXT STEPS • Is this a risk we want to

    mitigate? ➡ Write code to try to mitigate it • Otherwise, decide if we want to go…or not • While testing gives assurance, risk assessment gives confidence
  78. — Timeline's Core Value THE MOST IMPORTANT THING ABOUT A

    PROGRAM IS WHAT IT WILL DO. THE SECOND IS WHAT IT DID. ” “
  79. TAKE AWAYS • Learn more about time travel and Timeline

    at timeline-lang.com • When designing APIs or languages, consider both the problem you are solving as well as what you value: • Timeline solves a very specific problem • Timeline values observability and predictability, so: • reduce density • require readability/comprehensibility • testing as simulation instead of verification
  80. THANKS! •Dave Copeland •@davetron5000 on Twitter •davetron5000.com •timeline-lang.com