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.

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
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: ] { «???» }
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
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